sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:24:26Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1139Nested array design problems and bugs2017-11-19T20:24:26ZRobert BerneckyNested array design problems and bugs| | |
| --- | --- |
| Bugzilla Link | [1030](http://bugs.sac-home.org/show_bug.cgi?id=1030) |
| Created on | Oct 09, 2012 15:46 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [convonEach.sac](/uploads/76847da0...| | |
| --- | --- |
| Bugzilla Link | [1030](http://bugs.sac-home.org/show_bug.cgi?id=1030) |
| Created on | Oct 09, 2012 15:46 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [convonEach.sac](/uploads/76847da05e240c3a2e42a2d36908ef0c/convonEach.sac) |
## Extended Description
<pre>Created an attachment (id=936)
source code to reproduce fault
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18245:MODIFIED linux-gnu_x86_64
(Mon Oct 8 15:37:33 EDT 2012 by sac)
The nested array code has a number of distinct problems:
1. The generated code does not use _type_conv for enclose and
disclose. Instead, it uses new primitives:
sac2c convonEach.sac -O3 -v1 -wls_aggressive -doawlf -nowlf -bopt >crud.awlf
_pinl_8311_result = _enclose_( double[.], hidden(11), _pinl_8320__icc_3577);
_pinl_8223_result = _disclose_( hidden(11), double[.], _pinl_8311_result);
Bodo expressed a preference for use of _type_conv() here. I am not
sure of his exact reasoning, so perhaps he can expand this comment with
his rationale.
2. The type of _pinl_8311_result is "hidden(11)". I do not know what
this means. Can someone please provide appropriate documentation for
same, so that we can make CF and other optimizations work on
nested arrays?
3. This is a more fundamental design problem: All AVIS son information
about the _enclose_() argument is lost in its result, from what I
can see.
This means that AWLF and even WLF are unable to operate on disclosed
array elements, resulting in dismal performance.
Consider the convolution example in convonEach.sac: It is effectively
doing:
matmul( filter, take(shape(filter), drop(k, trace)));
In order to perform WLF, it at least needs to know the shape of trace
(the disclosed signal vector). This information has been lost.
In this degenerate case of enclose/disclose, once (1) and (2) have
been solved, then CF should be able to eliminate the enclose/disclose
pair, which would solve this particular problem.
However, consider the more general case of something like:
traces = ( enclose( trace0) ++ enclose( trace1) ++ enclose(trace2)...);
z = matmulEach( (enclose( filter), traces);
We now have no guarantee that the shapes of the traces are the same.
Worse yet, in the generalvector-matrix multiply case, we need to
know only that shape(filter)== take(1, shape(trace)) for all traces.
As a result of the absence of vital information for WLF/WLF to operate,
performance of the convonEach benchmark is dismal: roughly 130sec,
versus less than 1sec for the non-enclosed version.
What this tells me is that we need to rethink the whole idea of invariant
properties, in the light of nested arrays, and how we can apply optimizations
on such arrays.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1240LACS unit test bugipbb.sac produces very different results, depending on sac2...2017-11-19T20:33:01ZRobert BerneckyLACS unit test bugipbb.sac produces very different results, depending on sac2c options| | |
| --- | --- |
| Bugzilla Link | [1028](http://bugs.sac-home.org/show_bug.cgi?id=1028) |
| Created on | Oct 03, 2012 16:37 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bugipbb.sac](/uploads/d45259943a9...| | |
| --- | --- |
| Bugzilla Link | [1028](http://bugs.sac-home.org/show_bug.cgi?id=1028) |
| Created on | Oct 03, 2012 16:37 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bugipbb.sac](/uploads/d45259943a90f5ba6e740625bd6869d8/bugipbb.sac) |
## Extended Description
<pre>Created an attachment (id=933)
source code to reproduce fault
After attempting to repair Bug #1027, I ran the LACS unit test bugipbb.sac
and got an odd completion code. So, I tried to isolate the fault.
Here are my findings thus far:
sac2c bugipbb.sac -v1
sac@rattler:~/sac/testsuite/optimizations/lacs$ a.out; echo $?
192
sac@rattler:~/sac/testsuite/optimizations/lacs$ sac2c bugipbb.sac -v1 -noopt
WARNING: With-Loop unrolling (WLUR) was disabled using the command line.
WARNING: However, unrolling of single-trip with-loops is required for code
WARNING: generation. Therefore, WLUR will be re-enabled with the maximum
WARNING: number of unrolling steps set to 1.
wltransform/wltransform.c:7138 Assertion "FALSE" failed!
with-loop with empty iteration space found!
sac@rattler:~/sac/testsuite/optimizations/lacs$ sac2c bugipbb.sac -v1 -nols
sac@rattler:~/sac/testsuite/optimizations/lacs$ a.out; echo $?
248
sac@rattler:~/sac/testsuite/optimizations/lacs$ sac2c bugipbb.sac -v1 -nols -nocf
sac@rattler:~/sac/testsuite/optimizations/lacs$ a.out; echo $?
208
sac@rattler:~/sac/testsuite/optimizations/lacs$ sac2c bugipbb.sac -v1 -nocf
sac@rattler:~/sac/testsuite/optimizations/lacs$ a.out; echo $?
208
sac@rattler:~/sac/testsuite/optimizations/lacs$ sac2c bugipbb.sac -v1
sac@rattler:~/sac/testsuite/optimizations/lacs$ a.out; echo $?
192
sac@rattler:~/sac/testsuite/optimizations/lacs$ sac2c bugipbb.sac -v1 -dolacsi
sac@rattler:~/sac/testsuite/optimizations/lacs$ a.out; echo $?
192
sac@rattler:~/sac/testsuite/optimizations/lacs$ sac2c bugipbb.sac -v1 -dolacsi -dolacso
sac@rattler:~/sac/testsuite/optimizations/lacs$ a.out; echo $?
192
sac@rattler:~/sac/testsuite/optimizations/lacs$ sac2c bugipbb.sac -v1 -dolacsi -dolacso -nols
sac@rattler:~/sac/testsuite/optimizations/lacs$ a.out; echo $?
248
sac@rattler:~/sac/testsuite/optimizations/lacs$ sac2c bugipbb.sac -v1 -dolacsi -dolacso -nols -nocyc
stdopt/withloop_invariant_removal.c:861 Assertion "AVIS_DEFDEPTH(ID_AVIS(arg_node)) != DD_UNDEFINED" failed!
reference to undefined identifier _lacso_3074
The last crash is certainly my doing. Not sure about the others.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1138First nested array bug: modarray does not work on nested arrays2017-11-19T20:24:23ZRobert BerneckyFirst nested array bug: modarray does not work on nested arrays| | |
| --- | --- |
| Bugzilla Link | [1025](http://bugs.sac-home.org/show_bug.cgi?id=1025) |
| Created on | Oct 01, 2012 21:05 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>sac2c -V
sac2c v1.0...| | |
| --- | --- |
| Bugzilla Link | [1025](http://bugs.sac-home.org/show_bug.cgi?id=1025) |
| Created on | Oct 01, 2012 21:05 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18236:MODIFIED linux-gnu_x86_64
(Mon Oct 1 11:57:46 EDT 2012 by sac)
This simple example of nested array code fails, due to TC not
liking non-simple array arguments:
cat crud2.sac
/*
* Simple example of nested array use in sac2c:
* Construct (iota(3), iota(4), iota(5)...).
*
*/
use Array:all;
nested int[.] vec;
int main()
{
hole = enclose_vec ( [42] );
x = 3 + iota(10);
z = [ hole, hole, hole, hole, hole, hole, hole, hole, hole, hole];
for( i=0; i<20; i++ ) {
z = _modarray_AxVxS_( z, [i], enclose_vec( iota( x[i])));
}
StdIO::print(z);
return(0);
}
The problem is that NTCCTprf_modarray_AxVxS calls TEassureSameSimpleType,
which wants, oddly enough, a SimpleType. Which z is not.
Question for Dr. TC: Can we simply relax that test (handwave, handwave)
to a make it a call to the (non-existent) TCassureSameType?
Or is the pit deeper than that?</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1137Catch-22: LIR won't lift2017-11-19T20:24:19ZRobert BerneckyCatch-22: LIR won't lift| | |
| --- | --- |
| Bugzilla Link | [1022](http://bugs.sac-home.org/show_bug.cgi?id=1022) |
| Created on | Sep 11, 2012 22:32 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I just traced an AW...| | |
| --- | --- |
| Bugzilla Link | [1022](http://bugs.sac-home.org/show_bug.cgi?id=1022) |
| Created on | Sep 11, 2012 22:32 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I just traced an AWLF failure partway back to this loopfun code:
int loopfun( int _lacs_2325) {
...
_uprf_1573, _uprf_1574 = _non_neg_val_S_( _lacs_2325);
loopfun( _uprf_1573);
There are two distinct problems here:
a. LACS won't propagate AVIS_MINVAL( _lacs_2325) = 0 into the loopfun,
because the variable is not loop-invariant.
b. DLIR won't lift the guard expression out of the loopfun, for the
same reason, I think.
As I write this, I realize that, in this particular case, I may
be able to resolve the issue this enhancement to LACS:
In the calling environment, _lacs_2325 has AVIS_MINVAL = 0;
In the recursive call, _uprf_1573 has AVIS_MINVAL = 0.
In that case, LACS can happily set AVIS_MINVAL( _lacs_2325) = 0,
and the code should get better.
However, I suspect this is not the case in general, so welcome
ideas on better ways to tackle this problem.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18218:MODIFIED linux-gnu_x86_64
(Tue Sep 11 16:07:19 EDT 2012 by sac)
cd ~/sac/testsuite/optimizations/lacs$
sac2c simpleLoopAKD.sac -bopt:saacyc:lof:5 -doawlf -nowlf -v1 -#d,LIR,WLIR,DLIR &> crud</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1136type checker reports wrong parameter count2017-11-19T20:24:15ZRobert Berneckytype checker reports wrong parameter count| | |
| --- | --- |
| Bugzilla Link | [1021](http://bugs.sac-home.org/show_bug.cgi?id=1021) |
| Created on | Sep 10, 2012 21:02 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>ABORT: line 12 fil...| | |
| --- | --- |
| Bugzilla Link | [1021](http://bugs.sac-home.org/show_bug.cgi?id=1021) |
| Created on | Sep 10, 2012 21:02 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>ABORT: line 12 file: parserbug.sac
ABORT: No definition found for a function "StdIO::print" that accepts an
ABORT: argument of type "int{0}" as parameter no 3. Full argument types are
ABORT: "( Terminal::Terminal, TermFile::TermFile, int{0}, int{20})".
*** Compilation failed ***
*** Exit code 44 (Running type inference system)
*** 1 Error(s), 0 Warning(s)
sac@rattler:~/sac/testsuite/optimizations/lacs$ cat parserbug.sac
/*
* Wrong element number for error message.
*
*/
use Array:{*,--,-,genarray,iota,sum,+,take,++,<};
int main()
{
i = 0;
lim = 20;
StdIO::print( i, lim);
return( 0);
}
sac@rattler:~/sac/testsuite/optimizations/lacs$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18218:MODIFIED linux-gnu_x86_64
(Mon Sep 10 13:25:23 EDT 2012 by sac)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1239WLBSC causes loss of GENARRAY_SHAPE in LACS unit test simpleLoopAKD.sac2017-11-19T20:32:56ZRobert BerneckyWLBSC causes loss of GENARRAY_SHAPE in LACS unit test simpleLoopAKD.sac| | |
| --- | --- |
| Bugzilla Link | [1020](http://bugs.sac-home.org/show_bug.cgi?id=1020) |
| Created on | Sep 07, 2012 20:43 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/0e2190a89a0e6c...| | |
| --- | --- |
| Bugzilla Link | [1020](http://bugs.sac-home.org/show_bug.cgi?id=1020) |
| Created on | Sep 07, 2012 20:43 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/0e2190a89a0e6ce8a12b86cd4f2bd313/crud.sac) |
## Extended Description
<pre>Created an attachment (id=930)
source code to reproduce fault
This is probably not a new bug, but it showed up in my LACS unit tests.
sac2c crud.sac -bopt:uglf -v1 -doawlf -nowlf >crud2
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 18215:MODIFIED linux-gnu_x86_64
(Thu Sep 6 17:32:00 EDT 2012 by sac)
Basically, we have this expression in a LOOPFUN:
ZZ = ZZ + ( scalar * BBB);
It should be AWLF'd, but that does not happen, because the
GENARRAY_SHAPEs do not match. We have, between them, essentially this:
_pinl_284__wlbsc_186_sc_e = _idx_sel_( _wlbsc_409_sc_e, shape(BBB));
shapeZZnew = [ _pinl_284__wlbsc_186_sc_e ];
This is a case for IVUTarrayFromProxySel. It will have to appear
in AWLF, but should also appear in LACS and WLPROP, because
the effect of the above is to make loop-independent variables
look to be loop-dependent, because ID_AVIS(shapeZZnew) !- ID_AVIS(shape(BBB)).</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1221LIR misses WL in CONDFUN2017-11-19T20:31:55ZRobert BerneckyLIR misses WL in CONDFUN| | |
| --- | --- |
| Bugzilla Link | [1019](http://bugs.sac-home.org/show_bug.cgi?id=1019) |
| Created on | Aug 31, 2012 23:04 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbb.sac](/uploads/f1d4cc814ec280...| | |
| --- | --- |
| Bugzilla Link | [1019](http://bugs.sac-home.org/show_bug.cgi?id=1019) |
| Created on | Aug 31, 2012 23:04 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbb.sac](/uploads/f1d4cc814ec28049cfa0cdb68796237f/ipbb.sac) |
## Extended Description
<pre>Created an attachment (id=929)
source code to reproduce fault
Recently, I loosened up the rules for WLPROP, in
the hope of making a number of benchmarks run
better, as well as making WLPROP work on CONDFUNs.
However, I see today that some benchmarks, e.g., apex/ipbb/ipbb.sac,
run a LOT slower, and the cause is a WL that is being
WLPROP'd into a CONDFUN, but is not being LIR'd back
out when AWLF/WLF fail to gobble up that WL.
I tried tightening up the WLPROP rules to their previous
state, with no luck. Running with -nowlprop avoids
the problem, but that takes all the fun out of things.
It may be that LIR never dealt with CONDFUNs. If so, that
would certainly explain the problem.
The failure definitely happens with Build #18200.
I'll look into the problem over the weekend. After all,
it IS Labor Day here, so I may as well be laboring.</pre>Jing GuoJing Guohttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1029Nested arrays don't work as advertised2017-11-19T20:17:54ZRobert BerneckyNested arrays don't work as advertised| | |
| --- | --- |
| Bugzilla Link | [1015](http://bugs.sac-home.org/show_bug.cgi?id=1015) |
| Created on | Aug 27, 2012 17:42 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [pl.sac](/uploads/cb81e4115eb5aa5d...| | |
| --- | --- |
| Bugzilla Link | [1015](http://bugs.sac-home.org/show_bug.cgi?id=1015) |
| Created on | Aug 27, 2012 17:42 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [pl.sac](/uploads/cb81e4115eb5aa5ddca42f305bae2a28/pl.sac) |
## Extended Description
<pre>Created an attachment (id=925)
source code to reproduce fault
I tried to make a simple demo of nested array code, to see how
well it performs, but she no work:
sac2c pl.sac -irr_arr -O3
** 1: Loading SAC program ...
**** Locating source code ...
Reading from file "./pl.sac" ...
**** Running C preprocessor ...
**** Parsing input file ...
./pl.sac error:11:16 token `;' expected, `char' token found
./pl.sac error:13:8 type expected, `word' found
ABORT: Failed to construct a syntax tree for `pl.sac'
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18159:18167:MODIFIED linux-gnu_x86_64
(Mon Aug 27 09:25:14 EDT 2012 by sac)
The compiler complains about this line:
typedef nested char[.] word;
I'm assigning this to Clemens, inasmuch as he directed
Roland's work, and I don't see any other documentation or
code examples kicking around.</pre>Artem ShinkarovArtem Shinkarovhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1135DFC incorrectly dispatches multithreaded XT call to a SEQ implementation2023-04-25T16:48:57ZJaroslav SýkoraDFC incorrectly dispatches multithreaded XT call to a SEQ implementation| | |
| --- | --- |
| Bugzilla Link | [1014](http://bugs.sac-home.org/show_bug.cgi?id=1014) |
| Created on | Aug 10, 2012 17:43 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The DFC (Dispatch F...| | |
| --- | --- |
| Bugzilla Link | [1014](http://bugs.sac-home.org/show_bug.cgi?id=1014) |
| Created on | Aug 10, 2012 17:43 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The DFC (Dispatch Fun Calls) optimization in sac4c incorrectly dispatches multithreaded XT calls to a SEQ implementation, thus blowing up the private heap manager.
Code before dfc: See that the wrapper:gigo:_XT::gen( _btf_4) call correctly points to an XT variant:
/****************************************************************************
* Cond function:
* gigo:_XT::gen__Cond_8(...) [ body ]
****************************************************************************/
sacprelude::SACarg gigo:_XT::gen__Cond_8( bool _btf_2 { ,NN } , sacprelude::SACarg hnd { ,NN } )
/*
* gen__Cond_8 :: ---
*/
{
sacprelude::SACarg _btf_0__SSA0_2 { , NN } ;
sacprelude::SACarg _btf_0__SSA0_1 { , NN } ;
sacprelude::SACarg _btf_0 { , NN } ;
SNet::SNet _btf_4 { , NN } ;
SNet::SNet _btf_5 { , NN } ;
int _btf_6 { , NN } ;
if (_btf_2)
{
_btf_4 = wrapper:SNet::unwrapSNet( hnd) ;
_btf_5 = wrapper:gigo:_XT::gen( _btf_4) ;
_btf_6 = 20;
_btf_0 = wrapper:SNet::wrapSNet( _btf_6, _btf_5) ;
}
else
{
_btf_0__SSA0_1 = _dispatch_error_( 1, sacprelude::SACarg, "gen", hnd);
}
_btf_0__SSA0_2 = ( _btf_2 ? _btf_0 : _btf_0__SSA0_1 );
return( _btf_0__SSA0_2);
}
Code after DFC: the call was incorrectly dispatched to a SEQ implementation.
/****************************************************************************
* Cond function:
* gigo:_XT::gen__Cond_8(...) [ body ]
****************************************************************************/
sacprelude::SACarg gigo:_XT::gen__Cond_8( bool _btf_2 { ,NN } , sacprelude::SACarg hnd { ,NN } )
/*
* gen__Cond_8 :: ---
*/
{
sacprelude::SACarg _btf_0__SSA0_2 { , NN } ;
sacprelude::SACarg _btf_0__SSA0_1 { , NN } ;
sacprelude::SACarg _btf_0 { , NN } ;
SNet::SNet _btf_4 { , NN } ;
SNet::SNet _btf_5 { , NN } ;
int _btf_6 { , NN } ;
if (_btf_2)
{
_btf_4 = SNet::unwrapSNet( hnd) ;
_btf_5 = gigo::gen( _btf_4) ;
_btf_6 = 20;
_btf_0 = SNet::wrapSNet( _btf_6, _btf_5) ;
}
else
{
_btf_0__SSA0_1 = _dispatch_error_( 1, sacprelude::SACarg, "gen", hnd);
}
_btf_0__SSA0_2 = ( _btf_2 ? _btf_0 : _btf_0__SSA0_1 );
return( _btf_0__SSA0_2);
}
The program then rightfully crashes in an assertion check in PHM:
gigo-lpel: fun2.c:725: SACf_gigo__gen__SACt_SNet__SNet: Assertion `SAC_MT_globally_single && "An ST/SEQ top-arena call in the MT/XT context!!"' failed.
(gdb) bt
#0 0x00144410 in __kernel_vsyscall ()
#1 0x05056df0 in raise () from /lib/libc.so.6
#2 0x05058701 in abort () from /lib/libc.so.6
#3 0x0505026b in __assert_fail () from /lib/libc.so.6
#4 0x007c607c in SACf_gigo__gen__SACt_SNet__SNet (SACl_hnd__p=0x298fce70, SACl_hnd__desc__p=0x298fce6c) at fun2.c:725
#5 0x00146cc8 in SACcw_gigo_CL_XT__gen1 (SAC_MT_self=0x8ce76a8, SAC_arg_1__p=0x298fcefc, SAC_arg_1__desc__p=0x298fcec0, SACl_hnd=0x8ceaf38, SACl_hnd__desc=0x8ceaf18) at fun1.c:1964
#6 0x00146f61 in gigo__gen1 (ret0=0x298fcefc, arg0=0x8ceaf38) at interface.c:44
#7 0x0804a076 in SNetCall__gen (hnd=0x298fcf44) at gigo.c:61
#8 SNet__gigo__gen (hnd=0x298fcf44) at gigo.c:76
#9 0x004ad46c in BoxTask (ent=0x89e2568, arg=0x89e25a8) at src/runtime/stream/entity/box.c:112
#10 0x004ade06 in SNetEntityCall (ent=0x89e2568) at src/runtime/stream/entity/entities.c:133
#11 0x004c04a2 in EntityTask (arg=0x89e2568) at src/threading/lpel/lpelif/glue_snet.c:75
#12 0x00cae18a in TaskStartup (data=0x290fd000) at src/task.c:283
#13 0x0018ae58 in co_runner () at pcl.c:377
#14 0x05066b9b in makecontext () from /lib/libc.so.6</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1134ISAA generates NULL LET_EXPRS nodes2017-11-19T20:24:09ZRobert BerneckyISAA generates NULL LET_EXPRS nodes| | |
| --- | --- |
| Bugzilla Link | [1013](http://bugs.sac-home.org/show_bug.cgi?id=1013) |
| Created on | Aug 08, 2012 21:57 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [snprank.sac](/uploads/0af2acbe3a3...| | |
| --- | --- |
| Bugzilla Link | [1013](http://bugs.sac-home.org/show_bug.cgi?id=1013) |
| Created on | Aug 08, 2012 21:57 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [snprank.sac](/uploads/0af2acbe3a3b9cb249e16af08318bb48/snprank.sac) |
## Extended Description
<pre>Created an attachment (id=924)
source code to reproduce fault
****** _MAIN::main( hidden(1), hidden(2), hidden(0)): ...
Inserting symbolic array attributes ...
-> Running syntax tree checks
WARNING: mandatory son LET_EXPR is NULL
WARNING: mandatory son LET_EXPR is NULL
Eliminating index vectors (split selections) ...
Insufficient symbolic shape information available. Using explicit
information to split index operation.
Insufficient symbolic shape information available. Using explicit
information to split index operation.
Insufficient symbolic shape information available. Using explicit
information to split index operation.
-> Running syntax tree checks
Eliminating common subexpressions ...
tree/traverse.c:67 Assertion "arg_node" failed!
OOOOOOOPS: TRAVdo() called with a NULL node!
apex@rattler:~/apex3/benchmks/snp$
apex@rattler:~/apex3/benchmks/snp$ sac2c snprank.sac -O3 -v1 -doawlf -nowlf -maxwlur 1 -d treecheck -chkfreq 4 -v4
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18135 linux-gnu_x86_64
(Tue Aug 7 17:55:58 EDT 2012 by sac)
snprank.sac is new, so I suspect this bug may have been around for
Many Moons.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1133valgrind dies with sac2c2017-11-19T20:24:06ZRobert Berneckyvalgrind dies with sac2c| | |
| --- | --- |
| Bugzilla Link | [1012](http://bugs.sac-home.org/show_bug.cgi?id=1012) |
| Created on | Aug 08, 2012 04:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Not sure who is to ...| | |
| --- | --- |
| Bugzilla Link | [1012](http://bugs.sac-home.org/show_bug.cgi?id=1012) |
| Created on | Aug 08, 2012 04:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Not sure who is to be the winner here:
valgrind sac2c -doawlf -nowlf -v1 realrelaxAKD.sac
==14943== Memcheck, a memory error detector
==14943== Copyright (C) 2002-2010, and GNU GPL'd, by Julian Seward et al.
==14943== Using Valgrind-3.6.0.SVN-Debian and LibVEX; rerun with -h for copyright info
==14943== Command: sac2c -doawlf -nowlf -v1 realrelaxAKD.sac
==14943==
WARNING: AWLF is enabled: -ecc enabled.
WARNING: AWLF is enabled: -extrema enabled.
WARNING: AWLF is enabled: -maxoptcyc=20
^Z==14943== Conditional jump or move depends on uninitialised value(s)
==14943== at 0x55157AA: vfprintf (vfprintf.c:1614)
==14943== by 0x551C657: fprintf (fprintf.c:33)
==14943== by 0x6125BEF: PrintGlobalSettings (gen_startup_code.c:469)
==14943== by 0x61260E0: GSCprintFileHeader (gen_startup_code.c:608)
==14943== by 0x61CF308: PrintTRAVdo (print.c:5952)
==14943== by 0x61CF5EE: PRTdoPrint (print.c:6063)
==14943== by 0x5DB0DD7: PHrunSubPhase (phase.c:251)
==14943== by 0x5DAA0DB: PHDdrivePhase_cg (phase_sac2c.mac:2496)
==14943== by 0x5DB0A18: PHrunPhase (phase.c:169)
==14943== by 0x5DAACC8: PHDdriveSac2c (phase_sac2c.mac:2474)
==14943== by 0x5D8D6F2: SACrunSac2c (main.c:116)
==14943== by 0x400B41: main (sac2c.c:16)
==14943==
==14943== Conditional jump or move depends on uninitialised value(s)
==14943== at 0x6125C03: PrintGlobalSettings (gen_startup_code.c:472)
==14943== by 0x61260E0: GSCprintFileHeader (gen_startup_code.c:608)
==14943== by 0x61CF308: PrintTRAVdo (print.c:5952)
==14943== by 0x61CF5EE: PRTdoPrint (print.c:6063)
==14943== by 0x5DB0DD7: PHrunSubPhase (phase.c:251)
==14943== by 0x5DAA0DB: PHDdrivePhase_cg (phase_sac2c.mac:2496)
==14943== by 0x5DB0A18: PHrunPhase (phase.c:169)
==14943== by 0x5DAACC8: PHDdriveSac2c (phase_sac2c.mac:2474)
==14943== by 0x5D8D6F2: SACrunSac2c (main.c:116)
==14943== by 0x400B41: main (sac2c.c:16)
==14943==
==14943== Conditional jump or move depends on uninitialised value(s)
==14943== at 0x6125C77: PrintGlobalSettings (gen_startup_code.c:483)
==14943== by 0x61260E0: GSCprintFileHeader (gen_startup_code.c:608)
==14943== by 0x61CF308: PrintTRAVdo (print.c:5952)
==14943== by 0x61CF5EE: PRTdoPrint (print.c:6063)
==14943== by 0x5DB0DD7: PHrunSubPhase (phase.c:251)
==14943== by 0x5DAA0DB: PHDdrivePhase_cg (phase_sac2c.mac:2496)
==14943== by 0x5DB0A18: PHrunPhase (phase.c:169)
==14943== by 0x5DAACC8: PHDdriveSac2c (phase_sac2c.mac:2474)
==14943== by 0x5D8D6F2: SACrunSac2c (main.c:116)
==14943== by 0x400B41: main (sac2c.c:16)
==14943==
==14943== Invalid read of size 1
==14943== at 0x4009B1B: check_match.12467 (dl-lookup.c:134)
==14943== by 0x400A643: do_lookup_x (dl-lookup.c:251)
==14943== by 0x400A861: _dl_lookup_symbol_x (dl-lookup.c:736)
==14943== by 0x55F1325: do_sym (dl-sym.c:177)
==14943== by 0x4E2F0C3: dlsym_doit (dlsym.c:51)
==14943== by 0x400ED35: _dl_catch_error (dl-error.c:178)
==14943== by 0x4E2F2AB: _dlerror_run (dlerror.c:164)
==14943== by 0x4E2F079: dlsym (dlsym.c:71)
==14943== by 0x5FB0208: LIBMgetLibraryFunction (libmanager.c:106)
==14943== by 0x5FAFC62: GetDependencyTableFunction (modulemanager.c:401)
==14943== by 0x5FAFD0E: MODMgetDependencyTable (modulemanager.c:420)
==14943== by 0x5FB9B92: BuildDepClosFoldFun (dependencies.c:126)
==14943== Address 0x167c is not stack'd, malloc'd or (recently) free'd
==14943==
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 "./realrelaxAKD.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 < realrelaxAKD.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.
==14943==
==14943== HEAP SUMMARY:
==14943== in use at exit: 1,526,127,404 bytes in 47,720,617 blocks
==14943== total heap usage: 317,978,405 allocs, 270,257,788 frees, 10,403,580,350 bytes allocated
==14943==
==14943== LEAK SUMMARY:
==14943== definitely lost: 377,140,741 bytes in 9,480,858 blocks
==14943== indirectly lost: 1,148,759,989 bytes in 38,237,665 blocks
==14943== possibly lost: 1,820 bytes in 46 blocks
==14943== still reachable: 224,854 bytes in 2,048 blocks
==14943== suppressed: 0 bytes in 0 blocks
==14943== Rerun with --leak-check=full to see details of leaked memory
==14943==
==14943== For counts of detected and suppressed errors, rerun with: -v
==14943== Use --track-origins=yes to see where uninitialised values come from
==14943== ERROR SUMMARY: 4 errors from 4 contexts (suppressed: 7 from 7)
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18135 linux-gnu_x86_64
(Tue Aug 7 17:55:58 EDT 2012 by sac)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1132-printfun option is limited to one function2017-11-19T20:24:02ZClemens Grelck-printfun option is limited to one function| | |
| --- | --- |
| Bugzilla Link | [1010](http://bugs.sac-home.org/show_bug.cgi?id=1010) |
| Created on | Jul 31, 2012 19:06 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This is admittedly ...| | |
| --- | --- |
| Bugzilla Link | [1010](http://bugs.sac-home.org/show_bug.cgi?id=1010) |
| Created on | Jul 31, 2012 19:06 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This is admittedly rather a feature request than a bug, but we use SacZilla for both.
It would be very helpful if one could select multiple functions for printing. The easiest implementation would probably be to support multiple occurences of the -printfun option on one command line and store a list of function names internally.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1131-printfun option fails to print LaC funs2017-11-19T20:23:59ZClemens Grelck-printfun option fails to print LaC funs| | |
| --- | --- |
| Bugzilla Link | [1009](http://bugs.sac-home.org/show_bug.cgi?id=1009) |
| Created on | Jul 31, 2012 19:03 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The -printfun optio...| | |
| --- | --- |
| Bugzilla Link | [1009](http://bugs.sac-home.org/show_bug.cgi?id=1009) |
| Created on | Jul 31, 2012 19:03 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The -printfun option fails to print LaC funs. Looking into the code, there seems to be steps taken to print LaC funs while they are grouped as local functions, but this holds for hardly more than optimisation cycles. Thus for large parts of the compilation process, subordinate loop and conditional functions are not printed.</pre>BugZillaBugZillahttps://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/1130AWLF unit test UTReshapebug2.sac generates 6WLs instead of one2017-11-19T20:23:56ZRobert BerneckyAWLF unit test UTReshapebug2.sac generates 6WLs instead of one| | |
| --- | --- |
| Bugzilla Link | [1005](http://bugs.sac-home.org/show_bug.cgi?id=1005) |
| Created on | Jul 17, 2012 22:42 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This innocent code ...| | |
| --- | --- |
| Bugzilla Link | [1005](http://bugs.sac-home.org/show_bug.cgi?id=1005) |
| Created on | Jul 17, 2012 22:42 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This innocent code generates 6 WLs:
use Array: all;
int main()
{
A_45=iota( 24);
A_46= _reshape_VxA_([2, 3, 4],A_45);
A_47=reverse( A_46);
A_48=reverse( A_47);
z = Sel( [ 1,2,3], A_48);
z = _sub_SxS_( z, 7);
return(z);
}
int Sel( int[.] iv, int[*] y)
{ /* Hide _sel_() from the ravages of AWLF */
z = _sel_VxA_( iv, y);
return( z);
}
unless you compile it with -wls_aggressive, in which case all
but the iota() disappear, as you would desire.
The basic problem is that the reverse() is a WL working along the first
axis, and within there is another WL to do the row selection.
I don't think this is exactly a bug, but it would be nice if
it generated better code.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1220AKD arrays introduce unknown types in CUDA kernels2017-11-19T20:31:52ZMiguel Sousa DiogoAKD arrays introduce unknown types in CUDA kernels| | |
| --- | --- |
| Bugzilla Link | [1003](http://bugs.sac-home.org/show_bug.cgi?id=1003) |
| Created on | Jul 10, 2012 22:42 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [bug.sac](/uploads/947f7fb79d8afcc32...| | |
| --- | --- |
| Bugzilla Link | [1003](http://bugs.sac-home.org/show_bug.cgi?id=1003) |
| Created on | Jul 10, 2012 22:42 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [bug.sac](/uploads/947f7fb79d8afcc3296c306b733c3c7a/bug.sac) |
## Extended Description
<pre>Created an attachment (id=916)
Source code to reproduce fault
Please see attached source program.
Current sac2c rev 18056 and pre-DevCamp rev 17875 fails assertion when compiling the attached source code with CUDA:
sac2c -target cuda64 bug.sac
...
** 19: Preparing C code generation ...
**** CUDA Prepare kernel generation ...
cuda/cuda_utils.c:54 Assertion "0" failed!
Simple type conversion found undefined host simple type!
Specifying the shape of the array on the signature of function process like this:
color[.,.] process(color[1200,1600] image) {
no longer fails.</pre>Jing GuoJing Guohttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1129apex benchmark crcAKD.sac crashes in WLF2017-11-19T20:23:53ZRobert Berneckyapex benchmark crcAKD.sac crashes in WLF| | |
| --- | --- |
| Bugzilla Link | [999](http://bugs.sac-home.org/show_bug.cgi?id=999) |
| Created on | Jul 09, 2012 16:12 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crcAKD.sac](/uploads/de9e93d0a145d8...| | |
| --- | --- |
| Bugzilla Link | [999](http://bugs.sac-home.org/show_bug.cgi?id=999) |
| Created on | Jul 09, 2012 16:12 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crcAKD.sac](/uploads/de9e93d0a145d8bb8ee3dd453bf5041f/crcAKD.sac) |
## Extended Description
<pre>Created an attachment (id=912)
source code to reproduce fault
This one looks new to me. Perhaps a DevCamp leftover?
Applying with-loop folding ...
arrayopt/SSAWLF.c:1181 Assertion "(dim-1 < 0) || (target_ig->l && target_ig->u && whole_ig->l && whole_ig->u)" failed!
OOOOOOOPS: I seem to be missing something here!
[1]+ Done ddd sac2c (wd: ~/apex3/benchmks/UTCompress)
(wd now: ~/apex3/benchmks/crcAKD)
apex@rattler:~/apex3/benchmks/crcAKD$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18052:MODIFIED linux-gnu_x86_64
(Mon Jul 9 09:52:52 EDT 2012 by sac)
apex@rattler:~/apex3/benchmks/crcAKD$ sac2c crcAKD.sac -v4</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1128UTCompress.sac unit test crash in phase 13 with -noopt2017-11-19T20:23:50ZRobert BerneckyUTCompress.sac unit test crash in phase 13 with -noopt| | |
| --- | --- |
| Bugzilla Link | [996](http://bugs.sac-home.org/show_bug.cgi?id=996) |
| Created on | Jul 09, 2012 15:54 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTCompress.sac](/uploads/dd63ed4bc4...| | |
| --- | --- |
| Bugzilla Link | [996](http://bugs.sac-home.org/show_bug.cgi?id=996) |
| Created on | Jul 09, 2012 15:54 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTCompress.sac](/uploads/dd63ed4bc4ff3407fc5afb0330b980a8/UTCompress.sac) |
## Extended Description
<pre>Created an attachment (id=909)
source code to reproduce fault
** 13: Transforming with-loop representation ...
**** Simplifying with-loops ...
**** Transforming with-loop representation ...
Naive compilation of multi-generator with-loop activated
Naive compilation of multi-generator with-loop activated
Naive compilation of multi-generator with-loop activated
Naive compilation of multi-generator with-loop activated
Naive compilation of multi-generator with-loop activated
Naive compilation of multi-generator with-loop activated
Naive compilation of multi-generator with-loop activated
Naive compilation of multi-generator with-loop activated
Naive compilation of multi-generator with-loop activated
Naive compilation of multi-generator with-loop activated
wltransform/wltransform.c:7138 Assertion "FALSE" failed!
with-loop with empty iteration space found!
apex@rattler:~/apex3/benchmks/UTCompress$ sac2c UTCompress.sac -v4 -noopt
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18052:MODIFIED linux-gnu_x86_64
(Mon Jul 9 09:52:52 EDT 2012 by sac)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1127Explicit accumulator insertion failure2017-11-19T20:23:46ZRobert BerneckyExplicit accumulator insertion failure| | |
| --- | --- |
| Bugzilla Link | [995](http://bugs.sac-home.org/show_bug.cgi?id=995) |
| Created on | Jul 09, 2012 15:51 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [upgradeHIMAKD.sac](/uploads/65fd7aa...| | |
| --- | --- |
| Bugzilla Link | [995](http://bugs.sac-home.org/show_bug.cgi?id=995) |
| Created on | Jul 09, 2012 15:51 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [upgradeHIMAKD.sac](/uploads/65fd7aa61114b5a9d953bde25c0c53bf/upgradeHIMAKD.sac) |
## Extended Description
<pre>Created an attachment (id=908)
source code to reproduce fault
sac2c upgradeHIMAKD.sac -v4 -noopt
** 10: Enhancing with-loops ...
**** Introducing explicit accumulators ...
flatten/ExplicitAccumulate.c:271 Assertion "eq_funap != NULL" failed!
sacprelude::eq not found
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18052:MODIFIED linux-gnu_x86_64
(Mon Jul 9 09:52:52 EDT 2012 by sac)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1126WLIR repeatedly updates optimization counts in SSE2017-11-19T20:23:42ZRobert BerneckyWLIR repeatedly updates optimization counts in SSE| | |
| --- | --- |
| Bugzilla Link | [994](http://bugs.sac-home.org/show_bug.cgi?id=994) |
| Created on | Jul 09, 2012 15:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [logd3AKD.sac](/uploads/5b0ffb0a5588...| | |
| --- | --- |
| Bugzilla Link | [994](http://bugs.sac-home.org/show_bug.cgi?id=994) |
| Created on | Jul 09, 2012 15:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [logd3AKD.sac](/uploads/5b0ffb0a558872d76e240f65d047839a/logd3AKD.sac) |
## Extended Description
<pre>Created an attachment (id=907)
source code to reproduce fault
SimplifySymb: SSE: DLIR= 0, WLIR= 3, INL=0, CSE=0, TUP=0, CF=0, VP=0, AS=0, AL=0, DL=0
SimplifySymb: SSE: Cycle interation 14 (fun function _dup_18031_divDDD__Cond_1)
sac2c logd3AKD.sac -doawlf -nowlf -v4 -#d,SSE
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18052:MODIFIED linux-gnu_x86_64
(Mon Jul 9 09:52:52 EDT 2012 by sac)
This repeats, with WLIR= 3, until maxoptcyc freezes over.
The net results are:
- excessive compilation times
and,in this case,
- crash due to running out of memory, presumably due to a memory
leak in one (or more) of the micro-cycle OPTS.</pre>BugZillaBugZilla