sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:37:28Zhttps://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/1043CFfuncond can't handle matching legs2017-11-19T20:18:42ZRobert BerneckyCFfuncond can't handle matching legs| | |
| --- | --- |
| Bugzilla Link | [526](http://bugs.sac-home.org/show_bug.cgi?id=526) |
| Created on | Jul 16, 2009 22:45 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [iotaonly8.sac](/uploads/1527ca...| | |
| --- | --- |
| Bugzilla Link | [526](http://bugs.sac-home.org/show_bug.cgi?id=526) |
| Created on | Jul 16, 2009 22:45 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [iotaonly8.sac](/uploads/1527cae5c5a342495efb390ced8f66ac/iotaonly8.sac) |
## Extended Description
I was dusting off the constant folder today, and noted that CFfuncond
doesn't catch the case of:
z5 = id(true) ? t1 : t1;
The problem is that. by the time CF looks at the expression, it is a lacfn,
so t1 and t1 have become t1 and t2, and they will never match.BugZillaBugZillahttps://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 Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1041Loop fn contains superfluous parameters, causing 2.5X slowdown2017-11-19T20:18:35ZRobert BerneckyLoop fn contains superfluous parameters, causing 2.5X slowdown| | |
| --- | --- |
| Bugzilla Link | [512](http://bugs.sac-home.org/show_bug.cgi?id=512) |
| Created on | Jun 19, 2009 16:38 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This is a care o...| | |
| --- | --- |
| Bugzilla Link | [512](http://bugs.sac-home.org/show_bug.cgi?id=512) |
| Created on | Jun 19, 2009 16:38 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This is a care of the APEX apex/testlcv/testlcv.sac versus the
apex/testlcvAKD/testlcvAKD.sac benchmarks. Here is the inner loop code
for both of them; the only difference is whether n is statically known:
inline double testlcvXID(int n)
{
r_0=tod(( false));
j_0=( 9);
A_40=iota( n);
A_CTR41_= 0;
A_CTR41z_ = (shape(A_40)[[0]])-1;
r_2=tod(r_0);
j_2=tod(j_0);
for(; A_CTR41_ <= A_CTR41z_; A_CTR41_++){
i_0 = A_40[[A_CTR41_]];
A_44=r_2, + i_0;
r_2=( A_44);
A_46=r_2 + 1.0;
j_2=( A_46);
}
A_49=r_2 + j_2;
r_3=( A_49);
return(r_3);
}
In the AKD version, we find this function:
* Loop function:
* _MAIN::_dup_659__testlcvXID__Loop_0(...)
****************************************************************************/
#3194: in [ double, double] le < 3203> ge < 3205>, #3195: in [ double, double] le < 3204> ge < 3206> _MAIN::_dup_659__testlcvXID__Loop_0( #3189: in [ int[1], int[1]] le <> ge <> _isaa_2231_A_40 { dim: 1, shape: [ 1 ] } , #3190: in [ int[.], int[.]] le <> ge <> A_40 { dim: 1, shape: _isaa_2231_A_40 } , #3191: in [ int, int] le <> ge <> A_CTR41_ { dim: 0, shape: [:int] } , #3192: in [ int, int] le <> ge <> A_CTR41z_ { dim: 0, shape: [:int] } , #3193: in [ double, double] le <> ge <> r_2 { dim: 0, shape: [:int] } )
...
_cf_2498_A_40 = _idx_shape_sel_( 0, A_40);
_cf_2499 = [ _cf_2498_A_40 ];
if (_pinl_2014__flat_41)
{
_lirmov_711_A_46, r_2__SSA0_2 = _MAIN::_dup_659__testlcvXID__Loop_0( _cf_2499, A_40, _pinl_2013__flat_69, A_CTR41z_, _pinl_2006___flat_53);
The only notable differences in the two codes is the _cf_2499 set,
the _cf_2498_A_40 set, and the fact that _cf_2499 is passed into each
call, even though it is never explicitly referenced.
I am guessing that the SAA code is generating the extra parameter, but it would be nice if we could get rid of it in cases like this.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1040CSE misses cases on LACFNS in apex/mconvout2017-11-19T20:18:32ZRobert BerneckyCSE misses cases on LACFNS in apex/mconvout| | |
| --- | --- |
| Bugzilla Link | [511](http://bugs.sac-home.org/show_bug.cgi?id=511) |
| Created on | Jun 17, 2009 23:41 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The following is...| | |
| --- | --- |
| Bugzilla Link | [511](http://bugs.sac-home.org/show_bug.cgi?id=511) |
| Created on | Jun 17, 2009 23:41 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The following is a fragment of code generated by the apex/mconvout/mconvout.sac benchmark. I see several problems with this code:
1. CSE (I think) fails to note that _flat_134 and _flat_137 are
identical, as are the sel() operations that follow them.
I would expect, as a first step, to move the common code out of
the conditional and into the code that dominates it.
2. As a second step, the indexing operation should be totally
lifted out of Cond_3 and into the calling environment.
This would eliminate the need for k, and i,
to be passed into Cond_3.
I am not sure how much this might affect run-time performance, but I stumbled
across this while searching for your basic factor-of-4 slowdown.
This isn't it, sadly enough, because it appears in both my fast and slow
cases.
-----------------------------------------------------------------------------
int _MAIN::_dup_13852______rotrIDD__Cond_3( int[100] k { } , int i { } , int j { } , bool _flat_129 { } )
/*
* _dup_13852______rotrIDD__Cond_3 :: ---
*/
{
int _pinl_10860__flat_95 { } ;
int _pinl_10861__flat_69 { } ;
int _pinl_10862__flat_68 { } ;
int _pinl_10855__flat_95 { } ;
int _pinl_10856__flat_69 { } ;
int _hce_1__SSA0_2 { } ;
int[1] _flat_134 { } ;
int[1] _flat_137 { } ;
if (_flat_129)
{
_flat_134 = [ i ];
_pinl_10855__flat_95 = _sel_VxA_( _flat_134, k);
_pinl_10856__flat_69 = _add_SxS_( j, _pinl_10855__flat_95);
}
else
{
_flat_137 = [ i ];
_pinl_10860__flat_95 = _sel_VxA_( _flat_137, k);
_pinl_10861__flat_69 = _add_SxS_( j, _pinl_10860__flat_95);
_pinl_10862__flat_68 = _sub_SxS_( _pinl_10861__flat_69, 350099);
}
_hce_1__SSA0_2 = ( _flat_129 ? _pinl_10856__flat_69 : _pinl_10862__flat_68 );
return( _hce_1__SSA0_2);
}</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1039GLF: Generally Lousy FLOPs rate?2017-11-19T20:18:28ZRobert BerneckyGLF: Generally Lousy FLOPs rate?| | |
| --- | --- |
| Bugzilla Link | [506](http://bugs.sac-home.org/show_bug.cgi?id=506) |
| Created on | Jun 06, 2009 22:49 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/79660830e09...| | |
| --- | --- |
| Bugzilla Link | [506](http://bugs.sac-home.org/show_bug.cgi?id=506) |
| Created on | Jun 06, 2009 22:49 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/79660830e097434fc5739a4e5abe1ba6/crud.sac) |
## Extended Description
<pre>-glf as default turned out to show up several problems.
Among them were several APEX benchmarks, including compiotaAKD.sac,
which started running 10X slower and eating all the memory on my system.
Here's a trimmed version excised from here, limited to just the
APL reshape (genarray-ish) that shows the problem.
With Build #16124 (containing many Bodo fixes already), the code leaves
some sacprelude::sel() wrapper functions in the code. This not
only slows things down, but inhibits WLF and EWLF.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1037_div_SxS_" must not contain a zero in /UTRepresentation2017-11-19T20:18:22ZRobert Bernecky_div_SxS_" must not contain a zero in /UTRepresentation| | |
| --- | --- |
| Bugzilla Link | [498](http://bugs.sac-home.org/show_bug.cgi?id=498) |
| Created on | May 19, 2009 23:20 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.breaks.sac](/uploads/7ae8...| | |
| --- | --- |
| Bugzilla Link | [498](http://bugs.sac-home.org/show_bug.cgi?id=498) |
| Created on | May 19, 2009 23:20 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.breaks.sac](/uploads/7ae8797a24334531bf564b32d8c454df/crud.breaks.sac) |
## Extended Description
<pre>Created an attachment (id=525)
Source code to cause crash
The attached fails when compiled with "sac2c crud.sac".
It works properly when compiled with "sac2c crud.sac -noopt".
The typechecker doesn't like some divide in the code,
but I think it's lying.
I have whittled the code example down a fair bit from the original..</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/1300WLSIMP broken2017-11-19T20:36:42ZRobert BerneckyWLSIMP broken| | |
| --- | --- |
| Bugzilla Link | [492](http://bugs.sac-home.org/show_bug.cgi?id=492) |
| Created on | May 15, 2009 20:17 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [emptygeneratorModarray.sac](/u...| | |
| --- | --- |
| Bugzilla Link | [492](http://bugs.sac-home.org/show_bug.cgi?id=492) |
| Created on | May 15, 2009 20:17 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [emptygeneratorModarray.sac](/uploads/4791896cf6760fe2941d5a28666877a4/emptygeneratorModarray.sac), [emptygeneratorFold.sac](/uploads/7f9faf2e59228edb9ea413088ab8b665/emptygeneratorFold.sac) |
## Extended Description
<pre>WLSIMP claims to remove/replace at least one class of degenerate WLs.
Specifically, ones generated by this sort of code:
use Array: {genarray,<=,-,+,iota,sel};
int[*] id(int[*] y)
{ return(y);
}
int main()
{
x = id(genarray([10,10],4));
z = with {
(. <= iv <= .) : x[iv] + iota(3);
} : genarray(_shape_A_(x), [1,2, 3]);
return(z[0,0,0]-4);
}
----------------------------------------------
sac2c nested.sac -b11:ivext -nowlur
Produces the following. Note the flat_10 WL bounds:
([ 0, 0 ] <= iv=[_eat_18, _eat_17] < [ _cf_548_x, _cf_547_x ] genwidth [ _cf_548_x, _cf_547_x ])
{
_pinl_227__flat_95 = _sel_VxA_( iv, x);
_flat_10 = with {
([:int] <= _pinl_225_iv < [:int])
{
/* empty */
} : _pinl_227__flat_95 ;
} :
genarray( [:int], _pinl_224__flat_92);
_pinl_237_res = with {
([ 0 ] <= _pinl_234_iv=[_pinl_238__eat_19] < [ 3 ] genwidth [ 3 ])
{
_pinl_236__flat_1072 = _add_SxS_( _flat_10, _pinl_238__eat_19);
} : _pinl_236__flat_1072 ;
} :
genarray( [ 3 ], _pinl_233__flat_1067);
} : _pinl_237_res ;
} :
genarray( [ _cf_548_x, _cf_547_x ], _flat_4);
-------------------------------
It looked to me that WLSIMPwith has a backwards conditional
for this check, but there's more to it than than, because inverting
the test produces poorly flavored goulash.
Not sure how bad these are affecting performance #s.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1258non-integer result from constant folding2017-11-19T20:34:06ZRobert Berneckynon-integer result from constant folding| | |
| --- | --- |
| Bugzilla Link | [491](http://bugs.sac-home.org/show_bug.cgi?id=491) |
| Created on | May 14, 2009 17:58 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [relax.sac](/uploads/38e555214a...| | |
| --- | --- |
| Bugzilla Link | [491](http://bugs.sac-home.org/show_bug.cgi?id=491) |
| Created on | May 14, 2009 17:58 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [relax.sac](/uploads/38e555214a19f3bbba1bb295a528f715/relax.sac) |
## Extended Description
<pre>Created an attachment (id=520)
Source code to cause crash
The following fails with above error, trying to do _add_VxV_(9, 0) !!!
in arrayopt/SSAWLI. Compile it this way:
sac2c -O3 -noprfunr relax.sac</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1036tvd2d crashes sac2c due to corrupted N_assign node2017-11-19T20:18:18ZRobert Berneckytvd2d crashes sac2c due to corrupted N_assign node| | |
| --- | --- |
| Bugzilla Link | [487](http://bugs.sac-home.org/show_bug.cgi?id=487) |
| Created on | Apr 27, 2009 13:56 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>sac@rattler:~/sa...| | |
| --- | --- |
| Bugzilla Link | [487](http://bugs.sac-home.org/show_bug.cgi?id=487) |
| Created on | Apr 27, 2009 13:56 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>sac@rattler:~/sac/demos/numerical/tvd$ make
sac2c -O3 -v1 -maxlur 10 -L fluid -L /usr/local/dislin -wls_aggressive -o tvd2d_abstract tvd2d_abstract.sac
This crash occurs in WLSBgenerator, due to a corrupted N_assign
node: the AVIS_SSAASSIGN pointer does not point to an N_assign node.
I have not chased this bug any further than this.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1288Buggy AUD code crashes C compiler2021-05-31T12:05:11ZRobert BerneckyBuggy AUD code crashes C compiler| | |
| --- | --- |
| Bugzilla Link | [486](http://bugs.sac-home.org/show_bug.cgi?id=486) |
| Created on | Apr 24, 2009 16:22 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug486.sac](/uploads/857e4581b...| | |
| --- | --- |
| Bugzilla Link | [486](http://bugs.sac-home.org/show_bug.cgi?id=486) |
| Created on | Apr 24, 2009 16:22 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug486.sac](/uploads/857e4581b3cdaa7673dd6ccf46747402/bug486.sac) |
## Extended Description
<pre>I created the attached code in an attempt to see how/if
sac2c deals with multi-partition WLs whose generator bounds
are of different lengths (hence, the program is broken!).
If you compile it with -DAKS or -DAKD, sac2c nicely detects the
problem and reports it in phase 6.
If you compile it with -DAUD, the C compiler dies:
**** Invoking C compiler ...
a.out.c: In function ‘SACf__MAIN__main’:
a.out.c:872: error: ‘SACp_emal_610_x__shpSAC_d’ undeclared (first use in this function)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1257Inner product-like code eats memory2017-11-19T20:34:02ZRobert BerneckyInner product-like code eats memory| | |
| --- | --- |
| Bugzilla Link | [481](http://bugs.sac-home.org/show_bug.cgi?id=481) |
| Created on | Apr 15, 2009 19:22 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [audwlf.sac](/uploads/17ee70d76...| | |
| --- | --- |
| Bugzilla Link | [481](http://bugs.sac-home.org/show_bug.cgi?id=481) |
| Created on | Apr 15, 2009 19:22 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [audwlf.sac](/uploads/17ee70d767fd6b1f7351c374ad25988e/audwlf.sac), [crud.sac](/uploads/5b97c7352f10f213f49c695ccd93acfc/crud.sac) |
## Extended Description
<pre>Created an attachment (id=511)
source code to reproduce failure
If the attachment is compiled this way:
sac2c crud.sac -O3 -nowlur -v1 -DBUG -DBUG2
It eats increasing amounts of memory, until it completes, or
destroys the known universe. Note that replacing the eqCCB with
"x==y" circumvents the problem, but doesn't repair it.
I also see this at -b11:
xel = with {
([:int] <= _pinl_1547_iv (IDXS:_wlidx_5196_xel) < [:int])
{
/* empty */
} : _pinl_1549__flat_63 ;
} :
I would expect that some part of optimizer would replace the WL
by a simple assign of ...flat_63, but perhaps I've managed to bust that without
knowing it.
There is definitely something funny happening with types, because
eqCCB and some condfns have arguments of type [*].</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1285One stone. Two birds. UTExpand kills with-loop fusion2017-11-19T20:35:39ZRobert BerneckyOne stone. Two birds. UTExpand kills with-loop fusion| | |
| --- | --- |
| Bugzilla Link | [358](http://bugs.sac-home.org/show_bug.cgi?id=358) |
| Created on | May 02, 2007 21:54 |
| Version | 1.00beta |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>If you compile sac...| | |
| --- | --- |
| Bugzilla Link | [358](http://bugs.sac-home.org/show_bug.cgi?id=358) |
| Created on | May 02, 2007 21:54 |
| Version | 1.00beta |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>If you compile sac/apex/UTExpand/UTExpand.sac with "-dowlfs",
it gets stuck in WL-fusion. Or if not stuck, at least way too slow.
If you compile it with "-O3", it dies in phase 15,
"applying type conversions" with "Conversion to or from
scalar detected."
If you compile with "-noopt", it compiles and executes properly.</pre>Clemens GrelckClemens Grelckhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1019Dead code continues to live in tut5.sac over wlfs2021-05-27T12:49:12ZRobert BerneckyDead code continues to live in tut5.sac over wlfs| | |
| --- | --- |
| Bugzilla Link | [334](http://bugs.sac-home.org/show_bug.cgi?id=334) |
| Created on | Dec 06, 2006 17:19 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu5.sac](/uploads/14df526129...| | |
| --- | --- |
| Bugzilla Link | [334](http://bugs.sac-home.org/show_bug.cgi?id=334) |
| Created on | Dec 06, 2006 17:19 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu5.sac](/uploads/14df526129a739f18b36c6a415809e10/tutu5.sac) |
## Extended Description
<pre>The attached, compiled with:
sac2c -doisv -doswlf -dowlfs tutu5.sac -b14
shows that "x" is still there, even though it looks dead to me.
DCR doesn't appear to work properly here.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1018UTEpio.sac asserts in WLFS2017-11-19T20:17:14ZRobert BerneckyUTEpio.sac asserts in WLFS| | |
| --- | --- |
| Bugzilla Link | [323](http://bugs.sac-home.org/show_bug.cgi?id=323) |
| Created on | Nov 14, 2006 23:00 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu0.sac](/uploads/e57a6e61cf...| | |
| --- | --- |
| Bugzilla Link | [323](http://bugs.sac-home.org/show_bug.cgi?id=323) |
| Created on | Nov 14, 2006 23:00 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu0.sac](/uploads/e57a6e61cfa91c007f2a267ee8222514/tutu0.sac), [UTEpio.sac](/uploads/40b9f1824875f66f12c192f17e3359f0/UTEpio.sac) |
## Extended Description
<pre>There may be several bugs here.
sac2c -noopt tutu0.sac dies in the linker. WIth opts turned on, it appears to
work properly. See bugtutu0 for gcc/linker output.
UTEpio.sac dies same way. If you compile UTEpio.sac with: sac2c -dowlfs,
you kill sac2c this way:
*** Applying loop invariant removal ...
ASSERTION FAILED: file 'src/optimize/SSALIR.c', line 1409
usage of undefined identifier
EXECUTION TERMINATED
./foo: line 1: 19369 Aborted sac2c -check b -maxwlur 3 -dowlfs
-O3 $1.sac -o $1.exe $2 $3 $4</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1283Are you suffering from Too Much DRAM in mdiv2.sac? Use wlfs!2021-05-26T20:33:03ZRobert BerneckyAre you suffering from Too Much DRAM in mdiv2.sac? Use wlfs!| | |
| --- | --- |
| Bugzilla Link | [312](http://bugs.sac-home.org/show_bug.cgi?id=312) |
| Created on | Oct 24, 2006 18:24 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tjck.sac](/uploads/bd10fbad431...| | |
| --- | --- |
| Bugzilla Link | [312](http://bugs.sac-home.org/show_bug.cgi?id=312) |
| Created on | Oct 24, 2006 18:24 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tjck.sac](/uploads/bd10fbad4312a1cf11992013603eb60b/tjck.sac) |
## Extended Description
<pre>If you compile sac/apex/mdiv2.sac with these parameters,
With-loop fusion gets its knickers in a knot and eats all the memory, eventually.
sac2c -check b -maxwlur 3 -dowlfs apex/mdiv2.sac
rev 15060 gets this...</pre>Clemens GrelckClemens Grelck