sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2018-11-23T14:46:58Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2209Demo 'sac_from_c' does not compile2018-11-23T14:46:58ZHans-Nikolai ViessmannDemo 'sac_from_c' does not compile| | |
| --- | --- |
| Bugzilla Link | [1143](http://bugs.sac-home.org/show_bug.cgi?id=1143) |
| Created on | Nov 20, 2014 16:53 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>## System D...| | |
| --- | --- |
| Bugzilla Link | [1143](http://bugs.sac-home.org/show_bug.cgi?id=1143) |
| Created on | Nov 20, 2014 16:53 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>## System Details ##
uname -a - Linux 2.6.32-431.20.3.el6.x86_64
#1 SMP Thu Jun 19 14:01:59 CDT 2014 x86_64 GNU/Linux
distro - Scientific (RedHat) Linux 6.5
## SAC Details ##
revision - 18508 devel
stdlib - compiled as 'MODE=lean make mt'
## Problem ##
Tried to compile the 'sac_from_c' demo application (sac/demos/basics/sac_from_c).
Both the sac2c and sac4c processes completed without error. An error was given
when compiling the C program which links to the SAC C-lib.
## Additional ##
I had to edit the Makefile somewhat due to errors regarding the private heap
manager. The relevant line that I changed is 11; it now reads as:
$(CC) -o $* $*.c `sac4c -nophm Sum -ccflags` `sac4c -nophm Sum -ldflags` -pthread
## Error Message ##
gcc -o summarizer summarizer.c `sac4c -nophm Sum -ccflags` `sac4c -nophm Sum -ldflags` -pthread
./libcwrapper.so: undefined reference to `SACARGcopyDataInternal'
./libcwrapper.so: undefined reference to `SACARGfreeDataInternal'
collect2: error: ld returned 1 exit status
## Steps to Reproduce ##
1. cd sac/demos/basics/sac_from_c/
2. make
## Workaround (why?) ##
I wrapped the Structures::sum function in another function, 'mysum':
module Sum;
import Structures : {sum};
export {mysum};
int[] mysum(int[*] vector)
{
a = sum(vector);
return(a);
}
and changed the relevant line in summarizer.c. Doing this there are no errors
reported and the resulting binary runs.
## Extra ##
The output of 'nm -a libcwrapper.so':
0000000000202398 b .bss
0000000000000000 n .comment
00000000002020c0 d .ctors
0000000000202390 d .data
00000000002020d0 d .dtors
00000000002020e8 d .dynamic
00000000000006e0 r .dynstr
00000000000002a8 r .dynsym
0000000000001fe0 r .eh_frame
0000000000001fa0 r .eh_frame_hdr
0000000000001e58 t .fini
0000000000000a64 r .gnu.version
0000000000000ac0 r .gnu.version_r
0000000000202268 d .got
0000000000202298 d .got.plt
0000000000000158 r .hash
0000000000000e28 t .init
00000000002020e0 d .jcr
0000000000000e40 t .plt
0000000000000ae0 r .rela.dyn
0000000000000b88 r .rela.plt
0000000000001e70 r .rodata
0000000000001010 t .text
U SACARGcopyDataInternal
0000000000001d44 T SACARGcopyDataUdt
U SACARGfreeDataInternal
0000000000001dbc T SACARGfreeDataUdt
U SACARGisDouble
U SACARGisFloat
U SACARGisInt
U SACARGisUdt
U SACARGunwrapDouble
U SACARGunwrapFloat
U SACARGunwrapInt
U SACARGunwrapUdtDouble
U SACARGwrapDouble
U SACARGwrapFloat
U SACARGwrapInt
U SACARGwrapUdtDouble
U SAC_HM_MallocAnyChunk_at
U SAC_HM_MallocAnyChunk_mt
U SAC_HM_MallocAnyChunk_st
0000000000001f20 r SAC_HM_thread_status.2426
U SAC_MT_globally_single
U SAC_RuntimeError
U SAC_RuntimeError_Mult
00000000002023a8 B SAC___CWRAPPER__another_dummy_value_which_is_completely_useless
00000000002023ac B SAC___CWRAPPER__dummy_value_which_is_completely_useless
0000000000001158 T SACcw_Sum__sum1
U SACf_ArrayTransform__sum__d_S
U SACf_ArrayTransform__sum__f_S
U SACf_ArrayTransform__sum__i_S
U SACf_ComplexArrayTransform__sum__SACt_ComplexArrayTransform__complex_S
0000000000001cfd T Sum__sum1
00000000002020e8 a _DYNAMIC
0000000000202298 a _GLOBAL_OFFSET_TABLE_
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
w _Jv_RegisterClasses
00000000002020c8 d __CTOR_END__
00000000002020c0 d __CTOR_LIST__
00000000002020d8 d __DTOR_END__
00000000002020d0 d __DTOR_LIST__
00000000000020b8 r __FRAME_END__
00000000002020e0 d __JCR_END__
00000000002020e0 d __JCR_LIST__
0000000000001f10 r __PRETTY_FUNCTION__.2498
0000000000001f3a r __PRETTY_FUNCTION__.2631
0000000000202398 d __TMC_END__
U __assert_fail@@GLIBC_2.2.5
0000000000202398 A __bss_start
w __cxa_finalize@@GLIBC_2.2.5
0000000000001e20 t __do_global_ctors_aux
00000000000010a0 t __do_global_dtors_aux
0000000000202390 d __dso_handle
w __gmon_start__
0000000000202398 A _edata
00000000002023b0 A _end
0000000000001e58 T _fini
0000000000000e28 T _init
0000000000001010 t call_gmon_start
0000000000202398 b completed.6301
0000000000000000 a crtstuff.c
0000000000000000 a crtstuff.c
0000000000001030 t deregister_tm_clones
00000000002023a0 b dtor_idx.6303
0000000000001120 t frame_dummy
U free@@GLIBC_2.2.5
0000000000001c8f t freeScalarDesc
0000000000000000 a fun1.c
0000000000000000 a fundummy.c
0000000000000000 a globals.c
0000000000000000 a interface.c
0000000000001c18 t makeScalarDesc
U malloc@@GLIBC_2.2.5
0000000000001060 t register_tm_clones
0000000000000000 a sacargcopy.c
0000000000000000 a sacargfree.c
The output of 'nm -a libsac.seq.so | fgrep SACARGfree':
000000000000d59f T SACARGfree
000000000000d57e t SACARGfreeDataInternal
000000000000d2ea t SACARGfreeDataT_bool
000000000000d11c t SACARGfreeDataT_byte
000000000000d32c t SACARGfreeDataT_char
000000000000d36e t SACARGfreeDataT_classtype
000000000000d3b0 t SACARGfreeDataT_dots
000000000000d2a8 t SACARGfreeDataT_double
000000000000d434 t SACARGfreeDataT_double_dev
000000000000d4fa t SACARGfreeDataT_double_dist
000000000000d497 t SACARGfreeDataT_double_shmem
000000000000d266 t SACARGfreeDataT_float
000000000000d3f2 t SACARGfreeDataT_float_dev
000000000000d4b8 t SACARGfreeDataT_float_dist
000000000000d455 t SACARGfreeDataT_float_shmem
000000000000d287 t SACARGfreeDataT_floatvec
000000000000d34d t SACARGfreeDataT_hidden
000000000000d15e t SACARGfreeDataT_int
000000000000d413 t SACARGfreeDataT_int_dev
000000000000d4d9 t SACARGfreeDataT_int_dist
000000000000d476 t SACARGfreeDataT_int_shmem
000000000000d17f t SACARGfreeDataT_long
000000000000d2c9 t SACARGfreeDataT_longdbl
000000000000d1a0 t SACARGfreeDataT_longlong
000000000000d55d t SACARGfreeDataT_nothing
000000000000d53c t SACARGfreeDataT_rc
000000000000d13d t SACARGfreeDataT_short
000000000000d30b t SACARGfreeDataT_str
000000000000d51b t SACARGfreeDataT_sync
000000000000d1c1 t SACARGfreeDataT_ubyte
000000000000d203 t SACARGfreeDataT_uint
000000000000d224 t SACARGfreeDataT_ulong
000000000000d245 t SACARGfreeDataT_ulonglong
000000000000d0fb t SACARGfreeDataT_unknown
000000000000d3d1 t SACARGfreeDataT_user
000000000000d1e2 t SACARGfreeDataT_ushort
000000000000d38f t SACARGfreeDataT_void
Output of 'nm -a libsac.seq.so | fgrep SACARGcopy':
000000000000e0bc T SACARGcopy
U SACARGcopyDataUdt</pre>Hans-Nikolai ViessmannHans-Nikolai Viessmannhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2208gaussFilter delivers only values of 2552017-11-23T23:24:59ZVolkmar WiesergaussFilter delivers only values of 255| | |
| --- | --- |
| Bugzilla Link | [1105](http://bugs.sac-home.org/show_bug.cgi?id=1105) |
| Created on | Dec 10, 2013 13:57 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I've tried ...| | |
| --- | --- |
| Bugzilla Link | [1105](http://bugs.sac-home.org/show_bug.cgi?id=1105) |
| Created on | Dec 10, 2013 13:57 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I've tried to execute the gaussFilter example in sac/tutorial/L7_case_study_image-filter. I am using the compiler from the repository and I compiled the program as follows:
sac2c -DSOBEL -DSIMPLECLOCK -DRAWIMAGE image_filter.sac -o image_filter
and execution
./image_filter -c 2 -i ./testimages/sail.fibre -o ./outimage
After execution the outimage only contains values of 255</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2202ArrayFormat show() fails on double scalar/vector (at least)2017-11-23T23:24:29ZRobert BerneckyArrayFormat show() fails on double scalar/vector (at least)| | |
| --- | --- |
| Bugzilla Link | [936](http://bugs.sac-home.org/show_bug.cgi?id=936) |
| Created on | Mar 19, 2012 21:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Array formatting fail...| | |
| --- | --- |
| Bugzilla Link | [936](http://bugs.sac-home.org/show_bug.cgi?id=936) |
| Created on | Mar 19, 2012 21:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Array formatting fails to print double scalars and vectors correctly,
in both show() and format() flavors. This is a long-standing bug.
This function: cat crud.sac
use Array: all;
use StdIO : all;
use ArrayFormat: all;
int main()
{
print(format(42.5));
show( 42.5);
print( 42.5);
show( [42.5]);
return(0);
}
produces this output:
a.out
Dimension: 1
Shape : < 22>
< >
Dimension: 0
Shape : < >
42.5
4
Not even close.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2189compiler crashed - WLF bug when folding across different frame-shapes2017-11-23T23:23:19ZNilesh Karavadaracompiler crashed - WLF bug when folding across different frame-shapes| | |
| --- | --- |
| Bugzilla Link | [820](http://bugs.sac-home.org/show_bug.cgi?id=820) |
| Created on | Jan 25, 2011 09:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [slice.sacbugreport](/uploads/324848...| | |
| --- | --- |
| Bugzilla Link | [820](http://bugs.sac-home.org/show_bug.cgi?id=820) |
| Created on | Jan 25, 2011 09:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [slice.sacbugreport](/uploads/3248489b063509ead2c7838faf3ac4ea/slice.sacbugreport), [bug820.sac](/uploads/60bf77a4d8f8a49dacff819415632f22/bug820.sac) |
## Extended Description
<pre>Created an attachment (id=792)
Bug Report
/**********************************************************************
*
* SAC bug report: slice.sacbugreport
*
**********************************************************************
*
* Automatically generated on Tue Jan 25 09:19:38 GMT 2011
*
* using sac2c v1.00-beta (Haggis And Apple) rev 17286 for linux-gnu_i686
* built Mon Jan 24 17:32:53 GMT 2011.
* by user nkk on host obelix for linux-gnu.
*
* The compiler was called by
* sac2c -o slice slice.sac
*
* The compiler crashed in
* phase: opt (Running SAC optimizations)
* sub phase: cyc (Optimization cycle)
* cycle phase: wlf (Applying with-loop folding)
* cycle instance: 1
*
* What follows is the contents of slice.sac.
*
**********************************************************************/</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2187stdlib won't compile with the SUN compiler2017-11-19T22:05:51ZRoeland Doumastdlib won't compile with the SUN compiler| | |
| --- | --- |
| Bugzilla Link | [816](http://bugs.sac-home.org/show_bug.cgi?id=816) |
| Created on | Jan 07, 2011 12:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
This is a tracker bug to a...| | |
| --- | --- |
| Bugzilla Link | [816](http://bugs.sac-home.org/show_bug.cgi?id=816) |
| Created on | Jan 07, 2011 12:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
This is a tracker bug to allow compilation of the stdlib with suncc.Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2174Livermore Loop 13 SAC vs. C code not equivalent2017-11-19T22:04:41ZRobert BerneckyLivermore Loop 13 SAC vs. C code not equivalent| | |
| --- | --- |
| Bugzilla Link | [708](http://bugs.sac-home.org/show_bug.cgi?id=708) |
| Created on | May 11, 2010 19:19 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The repositor...| | |
| --- | --- |
| Bugzilla Link | [708](http://bugs.sac-home.org/show_bug.cgi?id=708) |
| Created on | May 11, 2010 19:19 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The repository copy of SAC Loop 13 code reads its input from a file;
the C version has the input hard-coded into the source program.
The entire SAC benchmark executes in about 36msec, and the C
version in 7msec.
One of the benchmarks should be changed, so that they are equivalent.
Until that time, any performance measurements on Loop13 should be considered
bogus.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2141TC ignores type error in dead code2017-11-19T22:01:42ZClemens GrelckTC ignores type error in dead code| | |
| --- | --- |
| Bugzilla Link | [796](http://bugs.sac-home.org/show_bug.cgi?id=796) |
| Created on | Dec 08, 2010 15:35 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>In the code from the ...| | |
| --- | --- |
| Bugzilla Link | [796](http://bugs.sac-home.org/show_bug.cgi?id=796) |
| Created on | Dec 08, 2010 15:35 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>In the code from the latest SAC user:
import Array: all;
import StdIO: all;
typedef int[1] array;
int main()
{
array x;
x = 10;
#ifndef EXCLUDE_ERRORS
print(x);
#endif
return(0);
}
the obvious type error goes away if x becomes dead code.
I traced this in so far as until the tc there is a proper
type conversion, which in my view should lead to an error
message, but after type checking this is gone.
This is very counter-intuitive for the user and an error
for me.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2140LIR apparently failing to operate on APEX Floyd benchmark2017-11-19T22:01:39ZRobert BerneckyLIR apparently failing to operate on APEX Floyd benchmark| | |
| --- | --- |
| Bugzilla Link | [1008](http://bugs.sac-home.org/show_bug.cgi?id=1008) |
| Created on | Jul 20, 2012 16:40 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/94b1bf45c55c07...| | |
| --- | --- |
| Bugzilla Link | [1008](http://bugs.sac-home.org/show_bug.cgi?id=1008) |
| Created on | Jul 20, 2012 16:40 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/94b1bf45c55c0700abb1c245c3e8491b/crud.sac), [floyd.sac](/uploads/b7503563d5a065a86cc8f079aa47aac1/floyd.sac), [floyd2.sac](/uploads/731f3a5ebc00728d28503a95aaeca227/floyd2.sac) |
## Extended Description
<pre>Created an attachment (id=920)
source code to reproduce fault
The APL version of a Floyd's shortest path benchmark
runs VERY slowly. When I looked at the IL, I saw that we generate
WLs within the LACFUNs. The offending APL code looks like this:
[4] siz←⍴D
[5] :For k :In ⍳siz[0]
[6] :For i :In ⍳siz[0]
[7] :For j :In ⍳siz[1]
[8] D[i;j]←(D[i;k]+D[k;j])⌊D[i;j]
[9] :EndFor
[10] :EndFor
[11]:EndFor
The IL generates ⍳siz[0] WITHIN the LOOPFUNs, and although at
least one of them has been touched by LIR,they have not been lifted
entirely out of the LOOPFUNs. The result is extremely slow code.
When I rewrote the Floyd code, it ran quick like a bunny:
inline double[.,.] floydXDD(double[.,.] D ,int QUADio)
{
siz = shape(D)[0];
for( k=0; k<siz; k++) {
for( i=0; i<siz; i++) {
for( j=0; j<siz; j++) {
D[i,j] = min(D[i,k]+D[k,j], D[i,j]);
}
}
}
return( D);
}
However, the underlying problem in LIR is needs fixing here.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18091:MODIFIED linux-gnu_x86_64
(Thu Jul 19 18:26:07 EDT 2012 by sac)
I'm assigning this to Jara, on the assumption that it's still his
kettle of fish.
BTW, perhaps it's time to svn rm SSALIR.c, now that its functionality
lies elsewhere?</pre>Jaroslav SýkoraJaroslav Sýkorahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2139APEX benchmark shortened snp.sac gets stuck in WLUR during opt cycle 22017-11-19T22:01:34ZRobert BerneckyAPEX benchmark shortened snp.sac gets stuck in WLUR during opt cycle 2| | |
| --- | --- |
| Bugzilla Link | [1050](http://bugs.sac-home.org/show_bug.cgi?id=1050) |
| Created on | Mar 06, 2013 16:17 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/8f0267bd90f82b...| | |
| --- | --- |
| Bugzilla Link | [1050](http://bugs.sac-home.org/show_bug.cgi?id=1050) |
| Created on | Mar 06, 2013 16:17 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/8f0267bd90f82bb97a3b5c43dfccef3f/crud.sac) |
## Extended Description
<pre>Created an attachment (id=951)
source code to reproduce fault
Summary says it all:
**** Optimization cycle pass: 2
****** Optimizing regular function:
****** _MAIN::main( hidden(1), hidden(2), hidden(0)): ...
...
WLUR: -maxwlur 3 would unroll genarray with-loop
WLUR: -maxwlur 3 would unroll genarray with-loop
^CAborted
apex@rattler:~/apex3/benchmks/snp$ vi crud.sac
apex@rattler:~/apex3/benchmks/snp$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18061 linux-gnu_x86_64
(Fri Mar 1 17:24:54 EST 2013 by sac)
apex@rattler:~/apex3/benchmks/snp$ sac2c crud.sac -doawlf -nowlf -v1 -O3 -v4 -maxwlur 1</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2138three dots as arguments unsafer than expected2021-08-30T15:56:59ZSven-Bodo Scholzthree dots as arguments unsafer than expected| | |
| --- | --- |
| Bugzilla Link | [521](http://bugs.sac-home.org/show_bug.cgi?id=521) |
| Created on | Jul 07, 2009 14:45 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu.sac](/uploads/6e449df16f5...| | |
| --- | --- |
| Bugzilla Link | [521](http://bugs.sac-home.org/show_bug.cgi?id=521) |
| Created on | Jul 07, 2009 14:45 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu.sac](/uploads/6e449df16f5940c2e6e5d42fd468ef60/tutu.sac) |
## Extended Description
<pre>Created an attachment (id=549)
source code
compile with -maxspec 0 and the 5.0 will be printed as 0.0000.
The reason for this is that the scalar value comes as AUD and therefore
in boxed form. As it is in ... position of printf, precompile cannot
insert appropriate casts to make sure an unboxed double is passed to the
actual printf implementation.
inlining or specialisations obviously make this problem go away....</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1315matmul Star algorithm crashes in Phase 152017-11-19T20:38:02ZRobert Berneckymatmul Star algorithm crashes in Phase 15| | |
| --- | --- |
| Bugzilla Link | [1107](http://bugs.sac-home.org/show_bug.cgi?id=1107) |
| Created on | Jan 08, 2014 22:31 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug1107redux.sac](/uploads/2a6ec2...| | |
| --- | --- |
| Bugzilla Link | [1107](http://bugs.sac-home.org/show_bug.cgi?id=1107) |
| Created on | Jan 08, 2014 22:31 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug1107redux.sac](/uploads/2a6ec20a4d3bc38eaea46df67cb97377/bug1107redux.sac), [1107.sac](/uploads/f5e9844406d5bd29da67e5d29eebdbf8/1107.sac) |
## Extended Description
<pre>sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18415 linux-gnu_x86_64
(Wed Jan 8 09:37:41 EST 2014 by sac)
cat bugrc.sac
use Array:all;
inline double[+] plusdotmpyDDDStar(double[+]x, double[+]y)
{ /* CDC STAR-100 APL Algorithm for inner product */
rowsx = drop([-1],shape(x));
colsx = shape(x)[[dim(x)-1]];
colsy = shape(y)[[dim(y)-1]];
Zrow = genarray([colsy],0.0d);
/* Parallel over rows of x */
z = with {
(. <= [row] <= .) {
Crow = with {
( [0] <= col < [colsy]) {
newrow = x[row] * y[col];
StdIO::show(newrow);
} : newrow;
} : fold( +, Zrow);
StdIO::show(Crow);
} : Crow;
}: genarray( rowsx, Zrow);
return(z);
}
int main()
{
siz = 5;
x = reshape( [siz,siz], 0.50* tod(iota(siz*siz)));
y = reshape( [siz,siz], 0.75* tod(iota(siz*siz)));
A_31=plusdotmpyDDDStar(x, y);
r = sum( A_31);
StdIO::print( r);
r = ( r== 732904294933574912.000000) ? 0 : 1;
return(r);
}
sac2c bugrc.sac -v1
**** Optimizing reference counting instructions ...
TRAVERSE ERROR: node of type 31:N_id found where 32:N_num was expected!
Compiling with -maxwlur 1 makes this crash not happen.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1313CSE crash in tjck.sac2017-11-19T20:37:51ZRobert BerneckyCSE crash in tjck.sac| | |
| --- | --- |
| Bugzilla Link | [992](http://bugs.sac-home.org/show_bug.cgi?id=992) |
| Created on | Jul 07, 2012 23:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/394041f63aa86da3...| | |
| --- | --- |
| Bugzilla Link | [992](http://bugs.sac-home.org/show_bug.cgi?id=992) |
| Created on | Jul 07, 2012 23:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/394041f63aa86da3a3211fbf60bd399d/crud.sac) |
## Extended Description
<pre>We crash in CSE during SAACYC, with Build #18045:
cd sac/apex/tjck
svn update .
sac2c tjck.sac -doawlf -nowlf -v4
****** Optimizing regular function:
****** _MAIN::slBII( bool[3], int[.,.]): ...
Inserting symbolic array attributes ...
Eliminating index vectors (split selections) ...
Eliminating common subexpressions ...
OOOOOOOPS, your program crashed the compiler 8-((
I have not looked into this, other than to compile it
with no options; that compiles OK.</pre>Clemens GrelckClemens Grelckhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1311LS does not support SAA; LACFUN headers result are missing AVIS_SHAPE2017-11-19T20:37:41ZRobert BerneckyLS does not support SAA; LACFUN headers result are missing AVIS_SHAPE| | |
| --- | --- |
| Bugzilla Link | [700](http://bugs.sac-home.org/show_bug.cgi?id=700) |
| Created on | Apr 21, 2010 22:37 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbbAKD.sac](/uploads/13bd5800f1162...| | |
| --- | --- |
| Bugzilla Link | [700](http://bugs.sac-home.org/show_bug.cgi?id=700) |
| Created on | Apr 21, 2010 22:37 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbbAKD.sac](/uploads/13bd5800f116238f77dabc85fff1d815/ipbbAKD.sac) |
## Extended Description
<pre>Created an attachment (id=688)
source code to reproduce fault
In the ongoing battle to kill CYC, we need to extend LS to make it
support SAA. When it moves a value from within a LACFUN to outside it,
it fails to move the AVIS_SHAPE/DIM information for that.
This results in unpleasant failure modes, such as VPid dying.
The attached will fail if compiled with rbe's local sac2c
(the post-Loch Ness fixerupper that is not checked in yet), with these options:
sac2c -ecc -extrema -doawlf -nowlf ipbbAKD.sac
This is partly a place marker so that we remember to do this work.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1310WLPG introduces default partition in phase 10 even when full generators are p...2017-11-19T20:37:36ZRobert BerneckyWLPG introduces default partition in phase 10 even when full generators are present| | |
| --- | --- |
| Bugzilla Link | [680](http://bugs.sac-home.org/show_bug.cgi?id=680) |
| Created on | Feb 15, 2010 20:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug676.sac](/uploads/6f3be6c54a2386...| | |
| --- | --- |
| Bugzilla Link | [680](http://bugs.sac-home.org/show_bug.cgi?id=680) |
| Created on | Feb 15, 2010 20:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug676.sac](/uploads/6f3be6c54a2386e2031527034f5f354a/bug676.sac) |
## Extended Description
<pre>Created an attachment (id=673)
source code to reproduce fault
And here's why, taken from the IL generated for Array::iota( int[.] shp):
sac2c -v0 -nowlf -doawlf -extrema -ecc bug676.sac -b10:cse >crud
_flat_10 = 0;
_flat_9 = _mul_SxV_( _flat_10, shp);
res = with {
(_flat_9 <= iv < shp)
{
/* empty */
} : iv ; ,
default partition( iv ):
{
/* empty */
} : _flat_9 ;
} :
genarray( shp, _flat_9);
shp is an int[.] until it gets inlined, so CF can't resolve the shape
of _flat_9. Extrema won't help here, for the same reason. By the
time that inlining has happened, the damage has been done by WLPG.
Array::iota(int shp) has a different problem: if compiled with -ecc,
TULSisFullGenerator fails to see the [0] lower bound, because it does not
look past the guards created by -ecc.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1308UTCompress crashes in WLBnodeOrIntGetNameOrVal2017-11-19T20:37:28ZRobert BerneckyUTCompress crashes in WLBnodeOrIntGetNameOrVal| | |
| --- | --- |
| Bugzilla Link | [552](http://bugs.sac-home.org/show_bug.cgi?id=552) |
| Created on | Aug 13, 2009 23:20 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTCompress.sac](/uploads/a77c7...| | |
| --- | --- |
| Bugzilla Link | [552](http://bugs.sac-home.org/show_bug.cgi?id=552) |
| Created on | Aug 13, 2009 23:20 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTCompress.sac](/uploads/a77c7b0b6d1b98f808a67d5948b7a79f/UTCompress.sac) |
## Extended Description
<pre>Created an attachment (id=557)
Source code to cause crash
If compiled this way:
sac2c v1.00-beta (Buchette d'Anjou)
developer rev 16326 linux-gnu_x86_64
(Thu Aug 13 16:01:15 EDT 2009 by sac)
apex@rattler:~/apex2003/benchmks/UTCompress$ sac2c -extrema -nowlf -doswlf -v3 UTCompress.sac
the attached sac program dies generating intermediate code macros
inside WLBnodeOrIntGetNameOrVal.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1307Adding a WL speeds up loopfsAKD.sac2017-11-19T20:37:23ZRobert BerneckyAdding a WL speeds up loopfsAKD.sac| | |
| --- | --- |
| Bugzilla Link | [495](http://bugs.sac-home.org/show_bug.cgi?id=495) |
| Created on | May 17, 2009 19:52 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/07908461968...| | |
| --- | --- |
| Bugzilla Link | [495](http://bugs.sac-home.org/show_bug.cgi?id=495) |
| Created on | May 17, 2009 19:52 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/0790846196816b4884be9fe6912d9d18/crud.sac) |
## Extended Description
<pre>Created an attachment (id=522)
Source code to reproduce fault
The attached code has the interesting property that it runs faster if you
introduce an extra WL into the mix, via #define CRUD.
The resulting code is NOT folded by WLF, so there is an extra WL at the end of phase 11.
However, the resulting code executes about 5% FASTER than if you remove the
extra WL. Very puzzling.
I'm guessing some strangeness in the back end, because eyeballing the code
did not turn up any other differences that I could see.
Perhaps some backendian type can look at this?
PAPI output:
without extra loop:
crud.sac.exe.O3.papiex.rattler.6186:PAPI_TOT_INS: 105104480
with extra loop:
crud.sac.exe.O3.papiex.rattler.6353:PAPI_TOT_INS: 100104533</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1305Failed to make by adding long type in Templates.mac2017-11-19T20:37:16ZSalem ReyenFailed to make by adding long type in Templates.mac| | |
| --- | --- |
| Bugzilla Link | [739](http://bugs.sac-home.org/show_bug.cgi?id=739) |
| Created on | Aug 18, 2010 10:01 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [Templates.mac](/uploads/7ebdd4...| | |
| --- | --- |
| Bugzilla Link | [739](http://bugs.sac-home.org/show_bug.cgi?id=739) |
| Created on | Aug 18, 2010 10:01 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [Templates.mac](/uploads/7ebdd47fc52790511eb4c46abcc32d8b/Templates.mac), [ArrayBasics.sacbugreport](/uploads/ce56eab2c8558074b48e0393e0bbedf6/ArrayBasics.sacbugreport) |
## Extended Description
<pre>Since I need the long type for stdlib, I add the long types you really need to the list in the CPP else case in /modules/structures/Templates.mac.
linux@linux-desktop:~/sac2c-1.00-beta-linux-x86_64/stdlib$ make mtfast
make -f buildfile "MTSAC2CFLAGS=-mt" MODE=lean
Module SDLisplay cannot be built because libSDL was not found
Module Gnuplot cannot be built because gnuplot was not found
Module Dislin cannot be built because DISLIN was not found
Module PNG cannot be built because libpng was not found
cd modules/structures/lib/..; sac2c -v0 -O3 -linksetsize 0 -mt ArrayBasics.sac -o lib
OOOOOOOPS, your program crashed the compiler 8-((
Please, send a bug report to bugs@sac-home.org,
or file a bug in the SaC-Zilla bug management system.
For your convenience, the compiler has pre-fabricated a bug report
in the file "./ArrayBasics.sacbugreport" !
Besides some infos concerning the compiler version and its
usage it contains the specified source file.
If you want to send that bug report to us, you may simply type
mail bugs@sac-home.org < ArrayBasics.sacbugreport
If you decide to file a bug in SaC-Zilla, please go to
http://bugs.sac-home.org/.
When filing a bug report, please copy/paste the initial comment section of
the bug report into the plain text comment section of SaC-Zilla, and add
the whole bug report file as an attachment.
Aborted
make[1]: *** [modules/structures/lib/libArrayBasicsTree.so] Error 134
make: *** [mtfast] Error 2</pre>Santanu Kumar DashSantanu Kumar Dashhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1303ArrayFormat dies dismally on double data2017-11-19T20:37:04ZRobert BerneckyArrayFormat dies dismally on double data| | |
| --- | --- |
| Bugzilla Link | [555](http://bugs.sac-home.org/show_bug.cgi?id=555) |
| Created on | Aug 14, 2009 22:49 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bugformat.sac](/uploads/e1277f...| | |
| --- | --- |
| Bugzilla Link | [555](http://bugs.sac-home.org/show_bug.cgi?id=555) |
| Created on | Aug 14, 2009 22:49 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bugformat.sac](/uploads/e1277f223ffe2eb57565bd227950cd86/bugformat.sac) |
## Extended Description
<pre>sac2c Build #16335
int main()
{
v = [ 9.884995e+06, 1.031330e+14, 9.885003e+06, 1.082900e+14 ];
StdIO::print(v);
StdIO::show(v);
return(0);
}
produces this:
a.out
Dimension: 1
Shape : < 4>
<9.884995e+06 1.031330e+14 9.885003e+06 1.082900e+14 >
*** SAC runtime error
*** line 152
*** argument #1 of "_sel_VxA_" should be legal index into argument #2;
*** types found: int[1]{1} and char[1]
Clearly, double vector formatting code needs work.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1302Code slowdown depending on where scalar comes from2017-11-19T20:37:00ZRobert BerneckyCode slowdown depending on where scalar comes from| | |
| --- | --- |
| Bugzilla Link | [522](http://bugs.sac-home.org/show_bug.cgi?id=522) |
| Created on | Jul 08, 2009 16:53 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [slow2.breaks.sac](/uploads/f38...| | |
| --- | --- |
| Bugzilla Link | [522](http://bugs.sac-home.org/show_bug.cgi?id=522) |
| Created on | Jul 08, 2009 16:53 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [slow2.breaks.sac](/uploads/f38ee1bee9c044bb767c95d69c70e0d9/slow2.breaks.sac), [iotaonly4.sac](/uploads/16e3842a7592d98a1f60bff4449cbd7d/iotaonly4.sac), [crud.breaks.sac](/uploads/61f4b374c6c3433f7d2dcf91adfa61b0/crud.breaks.sac), [iotaonly4.fast.O3.c](/uploads/2aa1529941780c95d3e4a8f7e5f3c242/iotaonly4.fast.O3.c), [iotaonly4.slow.O3.c](/uploads/55d9c175ae8ab695f5e1a96e0c157b05/iotaonly4.slow.O3.c), [iotaonly8.sac](/uploads/f5d701be0d4ed5775ce7e0e27a41a5b5/iotaonly8.sac), [iotaonly8.slow.b11](/uploads/f3d6b0ca3d2a08a09e6ad35b23d8f10d/iotaonly8.slow.b11), [iotaonly8.fast.b11](/uploads/a84616ed216c1cecd72f38c7b08ad150/iotaonly8.fast.b11), [iotaonly9.sac](/uploads/0506eb9821afebe8d3f201dd80175eef/iotaonly9.sac) |
## Extended Description
<pre>Created an attachment (id=550)
Shorter source code to reproduce fault
The attached code presents, I think, two problems:
The code performs +/⍳n; i.e., sum the first n integers.
1. If n comes from an id() function, both codes perform alike
when compiled with:
-O3
and
-O3 -nowlf -doswlf -extrema
2. If n comes from reading the command line, the code compiled with -O3
performs about 15% faster than the SWLF code.
Eyeballing the -b11 output did not give me any hints as to a difference
in generated code, EXCEPT that the WLF code contains TWO WLs, but
the SWLF code contains only one WL, it having folded the two WLs together.
Also, the second WL in the WLF-generated code has an RC(xxx) in its
WITHOP genarray clause. What does this RC field mean? Could that be
relevant?
I saw this problem before, but don't see any bugzilla entry for it.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1301EWLF can lose AVIS_SHAPE/DIM information in N_ap invocation2017-11-19T20:36:49ZRobert BerneckyEWLF can lose AVIS_SHAPE/DIM information in N_ap invocation| | |
| --- | --- |
| Bugzilla Link | [514](http://bugs.sac-home.org/show_bug.cgi?id=514) |
| Created on | Jun 23, 2009 22:02 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug514.breaks.sac](/uploads/a0...| | |
| --- | --- |
| Bugzilla Link | [514](http://bugs.sac-home.org/show_bug.cgi?id=514) |
| Created on | Jun 23, 2009 22:02 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug514.breaks.sac](/uploads/a01bc6855aeac1c5be0008037256a58a/bug514.breaks.sac), [crud3.sac](/uploads/c1baeae82c3769f27f33321906a9e38f/crud3.sac) |
## Extended Description
<pre>Created an attachment (id=543)
Source code to reproduce fault
If I compile the attached with: sac2c -nowlf -extrema -doswlf,
ive_split_selections complains because it does not have
AVIS_SHAPE/DIM information for Loop_4 argument x.
The calling environment DOES have that information, so something
in saacyc and EWLF is doing bad stuff.
This is noticable inasmuch as it causes your basic factor-of-50
slowdown in the binary search code used in APEX set membership,
indexof, and elsewhere.</pre>Robert BerneckyRobert Bernecky