sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:36:49Zhttps://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/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/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/1290Failure to move invariant WL out of FOR loop kills ipbb performance2017-11-19T20:36:02ZRobert BerneckyFailure to move invariant WL out of FOR loop kills ipbb performance| | |
| --- | --- |
| Bugzilla Link | [524](http://bugs.sac-home.org/show_bug.cgi?id=524) |
| Created on | Jul 14, 2009 04:10 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbb5.slow.sac](/uploads/8d7e3...| | |
| --- | --- |
| Bugzilla Link | [524](http://bugs.sac-home.org/show_bug.cgi?id=524) |
| Created on | Jul 14, 2009 04:10 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbb5.slow.sac](/uploads/8d7e3284e351038555e32585e81d58f7/ipbb5.slow.sac), [bug.funcond.sac](/uploads/510d31f8fba7844dbf4f0fbee5906001/bug.funcond.sac), [bug.compress.breaks.sac](/uploads/828cbca7dac5c005d9f146e53b821e5e/bug.compress.breaks.sac), [iotaonly7.sac](/uploads/f5ee8367f580cbb69881f909b89fc95d/iotaonly7.sac), [crud.slow](/uploads/2cecdb609f665609e8d7170337f12222/crud.slow), [crud.fast](/uploads/4755e5b361dd6e17fbb26472a2aff788/crud.fast) |
## Extended Description
<pre>Created an attachment (id=551)
Shorter source code to reproduce fault
I've been chasing a problem with the performance of a Boolean-Boolean
inner product code, apex/ipbb/ipbb.sac.
Although I think there are some problems with my extrema code in
this area, due to differences in performance in the current system,
the attached shorter example has the interesting property that
the compiler does not appear to be moving a loop-invariant Wl out of a
FOR-loop.
I say this because, if I move the loop out by hand, everything
runs bags faster in both the extrema and non-extrema world.
I am off to bed, so have not looked into this yet...
This all with Build #16193.
With xrow inside FOR-loop:
sac2c -O3:
ipbb5.slow.sac.exe.O3.papiex.rattler.28893:PAPI_TOT_INS: 99065594
sac2c -O3 -extrema -nowlf -doswlf:
ipbb5.slow.sac.exe.swlf.papiex.rattler.28928:PAPI_TOT_INS: 1003065073
With xow outside FOR-loop:
sac2c -O3:
ipbb5.slow.sac.exe.O3.papiex.rattler.28998:PAPI_TOT_INS: 765065354
sac2c -O3 -extrema -nowlf -doswlf:
ipbb5.slow.sac.exe.swlf.papiex.rattler.28970:PAPI_TOT_INS: 765065175</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/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/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/1191WLSD does not upgrade types2017-11-19T20:29:22ZCarl JoslinWLSD does not upgrade types| | |
| --- | --- |
| Bugzilla Link | [558](http://bugs.sac-home.org/show_bug.cgi?id=558) |
| Created on | Aug 28, 2009 12:48 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [fold.sac](/uploads/79a1adf2fd8...| | |
| --- | --- |
| Bugzilla Link | [558](http://bugs.sac-home.org/show_bug.cgi?id=558) |
| Created on | Aug 28, 2009 12:48 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [fold.sac](/uploads/79a1adf2fd8cafe6acb02c9a46201998/fold.sac) |
## Extended Description
<pre>Created an attachment (id=564)
Example code to produce error.
WLSD does not produce the most precise types possible for inner with3s this then affects RW3.
Problem happens when the set of with3s produce an akd but when sub with3s can produce aks.
int[.] _anonymous_2220 { } ;
int[.] res { } ;
res = with3 {
(0 <= _wlsd_2211 < _flat_843 in 1 (IDXS: _wlsd_2212) ) /* (BS: 0) */ {
...
_anonymous_2220 = with3 {
(0 <= _wlsd_2215 < 1 in 1 (IDXS: _wlsd_2216) ) /* (BS: 0) */ {
...
} : _flat_853;
} : ( genarray( [ 1 ] , genarray( [:int] ,_flat_849)));
} : _anonymous_2220;
...
} : ( genarray( [ _flat_842 ] , genarray( [:int] ,_flat_849)));
In the above example _anonymous_2220 should be [1] not [.]. This seems to stem from the type of _anonymous_2220 coming from res and not the with3 that it is defined from.</pre>Carl JoslinCarl Joslinhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1044AES tries to read freed memory2017-11-19T20:18:46ZCarl JoslinAES tries to read freed memory| | |
| --- | --- |
| Bugzilla Link | [573](http://bugs.sac-home.org/show_bug.cgi?id=573) |
| Created on | Oct 16, 2009 14:12 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [xaes.sac](/uploads/c1e7893e05c...| | |
| --- | --- |
| Bugzilla Link | [573](http://bugs.sac-home.org/show_bug.cgi?id=573) |
| Created on | Oct 16, 2009 14:12 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [xaes.sac](/uploads/c1e7893e05c5a2a6f362c52ef4777b22/xaes.sac), [aes.sac](/uploads/be83614bc9e9766f67a400586db52ce7/aes.sac) |
## Extended Description
<pre>AES tries to read memory at runtime where the memories reference count has reached 0. This is at the end of for loop (do/while).
sac2c v1.00-beta (Buchette d'Anjou)
developer rev 16478 linux-gnu_i686
(Fri Oct 16 12:16:56 BST 2009 by caj)
sac2c -target sl -DITERATE -DSACSL aes.sac</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1192wlsd can not handle MG2017-11-19T20:29:25ZCarl Joslinwlsd can not handle MG| | |
| --- | --- |
| Bugzilla Link | [579](http://bugs.sac-home.org/show_bug.cgi?id=579) |
| Created on | Oct 27, 2009 15:56 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [mg_rotate_sl.sac](/uploads/12c...| | |
| --- | --- |
| Bugzilla Link | [579](http://bugs.sac-home.org/show_bug.cgi?id=579) |
| Created on | Oct 27, 2009 15:56 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [mg_rotate_sl.sac](/uploads/12c823c1961b3fb971d3c6ab53466d25/mg_rotate_sl.sac) |
## Extended Description
<pre>LWSD has problems processing a grid:
ASSERTION FAILED: file 'wltransform/wl_split_dimensions.c', line 2120
neither code nor nextdim?
EXECUTION TERMINATED
Aborted
sac2c v1.00-beta (Buchette d'Anjou)
developer rev 16497 linux-gnu_i686
(Tue Oct 27 13:17:09 GMT 2009 by caj)</pre>Carl JoslinCarl Joslinhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1293rc cases descriptor to be freed2017-11-19T20:36:15ZCarl Joslinrc cases descriptor to be freed| | |
| --- | --- |
| Bugzilla Link | [582](http://bugs.sac-home.org/show_bug.cgi?id=582) |
| Created on | Oct 29, 2009 11:37 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug582.sac](/uploads/0005ad76e...| | |
| --- | --- |
| Bugzilla Link | [582](http://bugs.sac-home.org/show_bug.cgi?id=582) |
| Created on | Oct 29, 2009 11:37 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug582.sac](/uploads/0005ad76eed54073a7bb73ad1b58e33f/bug582.sac), [bunzip2.sac](/uploads/9420e3b3a08d5a598c1963d09b9e7e43/bunzip2.sac) |
## Extended Description
<pre>The attached code produces the function:
SACf__MAIN__decode__i_488__i
this function passes a pointer to an uninitialised descriptor and array to the function:
SACf__MAIN__get_bits__i_488__i__i
for use as the return value.
SACf__MAIN__get_bits__i_488__i__i seems to create the needed descriptor and array and passes them to:
SACf__MAIN__compare__i_X__i_6
The first time it does this every thing seems fine the rc goes up and back down however when it calls:
SACf__MAIN__compare__i_X__i_6
the second time it just goes down and not up.
As a result the descripter is freeded and there for not returned by:
SACf__MAIN__get_bits__i_488__i__i
and then when SACf__MAIN__decode__i_488__i uses the memory the program segfalts.</pre>Carl JoslinCarl Joslinhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1045Weird with-loops2017-11-19T20:18:49ZRobert BerneckyWeird with-loops| | |
| --- | --- |
| Bugzilla Link | [589](http://bugs.sac-home.org/show_bug.cgi?id=589) |
| Created on | Nov 11, 2009 17:02 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud2.sac](/uploads/d9d5750d11...| | |
| --- | --- |
| Bugzilla Link | [589](http://bugs.sac-home.org/show_bug.cgi?id=589) |
| Created on | Nov 11, 2009 17:02 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud2.sac](/uploads/d9d5750d11355dbf267059c5830bbd8d/crud2.sac) |
## Extended Description
<pre>Created an attachment (id=596)
Source code to reproduce fault
The attached (unlikely) code exhibits several interesting properties.
When compiled with Build #16534 (and probably many earlier ones...),
sac2c -b11 crud2.sac
produces this function:
-----------------------------------------------------
_pinl_622__flat_792 = true;
_pinl_624_res__SSA0_1 = with {
([ 0 ] <= _pinl_623_iv__SSA0_1=[_pinl_626__eat_11] (IDXS:_wlidx_1240__pinl_624_res__SSA0_1) < [ 8 ])
{
/* empty */
} : _pinl_622__flat_792 ; ,
([ 8 ] <= _pinl_623_iv__SSA0_1=[_pinl_626__eat_11] (IDXS:_wlidx_1240__pinl_624_res__SSA0_1) < [ 16 ])
{
/* empty */
} : _pinl_622__flat_792 ;
} :
genarray( [ 16 ], IDX(_wlidx_1240__pinl_624_res__SSA0_1));
----------------------------------------------------------------
I am not sure if this gets merged back into a single WL in the back end
or not. However, it does look weird.
Even weirder is what we get when compiled with:
sac2c -b11 -extrema -doawlf -nowlf crud2.sac
------------------------------------------------------
_pinl_612_res = with {
(_flatg_982 <= _pinl_610_iv=[_pinl_625__eat_10] (IDXS:_wlidx_1375__pinl_612_res) < _flatg_980)
{
/* empty */
} : _pinl_611__flat_784 ; ,
(_flatg_980 <= _pinl_610_iv=[_pinl_625__eat_10] (IDXS:_wlidx_1375__pinl_612_res) < _flatg_981)
{
/* empty */
} : _pinl_513__flat_780 ;
} :
genarray( [ 16 ], _pinl_513__flat_780, IDX(_wlidx_1375__pinl_612_res));
_pinl_624_res__SSA0_1__SSA4_1 = _idx_modarray_AxSxS_( _pinl_612_res, _pinl_598__flat_777, _pinl_611__flat_784);
_ivesplit_1382 = 9;
_pinl_624_res__SSA0_1__SSA4_2 = _idx_modarray_AxSxS_( _pinl_624_res__SSA0_1__SSA4_1, _ivesplit_1382, _pinl_611__flat_784);
_ivesplit_1383 = 10;
_pinl_624_res__SSA0_1__SSA4_3 = _idx_modarray_AxSxS_( _pinl_624_res__SSA0_1__SSA4_2, _ivesplit_1383, _pinl_611__flat_784);
_ivesplit_1384 = 11;
_pinl_624_res__SSA0_1__SSA4_4 = _idx_modarray_AxSxS_( _pinl_624_res__SSA0_1__SSA4_3, _ivesplit_1384, _pinl_611__flat_784);
_ivesplit_1385 = 12;
_pinl_624_res__SSA0_1__SSA4_5 = _idx_modarray_AxSxS_( _pinl_624_res__SSA0_1__SSA4_4, _ivesplit_1385, _pinl_611__flat_784);
_ivesplit_1386 = 13;
_pinl_624_res__SSA0_1__SSA4_6 = _idx_modarray_AxSxS_( _pinl_624_res__SSA0_1__SSA4_5, _ivesplit_1386, _pinl_611__flat_784);
_ivesplit_1387 = 14;
_pinl_624_res__SSA0_1__SSA4_7 = _idx_modarray_AxSxS_( _pinl_624_res__SSA0_1__SSA4_6, _ivesplit_1387, _pinl_611__flat_784);
_ivesplit_1388 = 15;
_pinl_624_res__SSA0_1__SSA4_8 = _idx_modarray_AxSxS_( _pinl_624_res__SSA0_1__SSA4_7, _ivesplit_1388, _pinl_611__flat_784);
return( _pinl_624_res__SSA0_1__SSA4_8);
}
-----------------------------------
Doesn't look very healthy from a performance viewpoint.
I'm not going to be able to look into it right away, but
wanted to note the problem, while it's fresh in my mind.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1046Odd behavior of and()2017-11-19T20:18:52ZRobert BerneckyOdd behavior of and()| | |
| --- | --- |
| Bugzilla Link | [592](http://bugs.sac-home.org/show_bug.cgi?id=592) |
| Created on | Nov 13, 2009 22:09 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I was looking at...| | |
| --- | --- |
| Bugzilla Link | [592](http://bugs.sac-home.org/show_bug.cgi?id=592) |
| Created on | Nov 13, 2009 22:09 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I was looking at match() code, and noted that it uses
fold. At that point, I began to wonder if foldfix was
working not working, or integrated into fold.
So, I wrote this here function:
use Array:all;
use StdIO:{print};
int main()
{
b = genarray([200000000], true);
z = any (b);
print(z);
return(0);
}
It generates this WL:
_pinl_225_res = with {
([ 0 ] <= _pinl_223_iv=[_pinl_226__eat_12] < [ 200000000 ])
{
_pinl_227__ea_165_res = _accu_( _pinl_223_iv);
_pinl_233__217__flat_13 = _or_SxS_( _pinl_227__ea_165_res, _flat_1);
} : _pinl_233__217__flat_13 ;
} :
fold( ScalarArith::|, _pinl_222__flat_6);
From what I can tell, that the fold WL does not quick-stop, suggesting
that foldfix is broken, non-existent, or something else.
However, more interesting is the slight variant on the above, when you change
the "true" to false. Then, it generates this:
_pinl_225_res = false;
This suggested to me that the typechecker might be detecting
one possible reduction identity case, but not the other.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1225UTMScalarI.sac breaks under AWLF2017-11-19T20:32:09ZRobert BerneckyUTMScalarI.sac breaks under AWLF| | |
| --- | --- |
| Bugzilla Link | [593](http://bugs.sac-home.org/show_bug.cgi?id=593) |
| Created on | Nov 13, 2009 23:04 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/4f60685f279...| | |
| --- | --- |
| Bugzilla Link | [593](http://bugs.sac-home.org/show_bug.cgi?id=593) |
| Created on | Nov 13, 2009 23:04 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/4f60685f27901934c14b4f7f5eb3cc61/crud.sac) |
## Extended Description
<pre>The attached abbreviated version of UTTakeDrop.sac has
at least two problems when compiled with Build#16545:MODIFIED
and -nowlf -doawlf -extrema
1. match(x,y) returns the wrong answer, although x==y works properly.
2. The fold WL that is the cause of the problem (It happens to be
indexing into a 20-element array that is only 10 elements long,
for example...) has two results, but one of the results is
dead code.
WLF works properly.
I'll look at it tomorrow.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1309WLS screws up default partition2017-11-19T20:37:32ZSven-Bodo ScholzWLS screws up default partition| | |
| --- | --- |
| Bugzilla Link | [596](http://bugs.sac-home.org/show_bug.cgi?id=596) |
| Created on | Nov 18, 2009 02:01 |
| Version | 1.00beta |
| OS | All |
| Architecture | PC |
| Attachments | [CalcCohCoefs.sac](/uploads/cc8c6...| | |
| --- | --- |
| Bugzilla Link | [596](http://bugs.sac-home.org/show_bug.cgi?id=596) |
| Created on | Nov 18, 2009 02:01 |
| Version | 1.00beta |
| OS | All |
| Architecture | PC |
| Attachments | [CalcCohCoefs.sac](/uploads/cc8c6e22ca9785a7aa075ad11a8ffc73/CalcCohCoefs.sac) |
## Extended Description
<pre>Created an attachment (id=606)
source file
compilation with sac2c rev 16578 calling
sac2c CalcCohCoefs.sac
yields
ERROR: line 43
ERROR: Shape of argument #1 of "_sel_VxA_" should match dimensionality of
ERROR: argument #2; types found: int[1] and double[28,2]
which is wrong!
However, before WLS, eg after b10, the code was still correct.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1047Someone (WLF?) still propagates constants into WL generator bounds2017-11-19T20:18:55ZRobert BerneckySomeone (WLF?) still propagates constants into WL generator bounds| | |
| --- | --- |
| Bugzilla Link | [609](http://bugs.sac-home.org/show_bug.cgi?id=609) |
| Created on | Nov 26, 2009 22:30 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>sac2c slice.sac -b11
...| | |
| --- | --- |
| Bugzilla Link | [609](http://bugs.sac-home.org/show_bug.cgi?id=609) |
| Created on | Nov 26, 2009 22:30 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>sac2c slice.sac -b11
where slice.sac is:
use Array: all;
int main()
{
shp = [25];
ylo = [5];
yhi = [25];
xlo = ylo - [8];
xhi = yhi + [20];
z = with {
( xlo <= iv <= xhi) : _sel_VxA_( [0], iv);
( ylo <= iv <= yhi) : _sel_VxA_( [0], iv);
} : genarray ( shp, 42);
StdIO::print(z);
return(0);
}
produces:
z = with {
([ 5 ] <= iv__SSA0_1=[_eat_23] < [ 26 ] genwidth [ _wlsimp_627 ])
{
/* empty */
} : _eat_23 ; ,
([ 0 ] <= iv__SSA0_1=[_eat_23] < [ 5 ] genwidth [ _wlsimp_626 ])
{
/* empty */
} : _eat_23 ;
} :
genarray( [ 25 ]);
I'm guessing WLF because if I compile with -nowlf, we get N_id nodes in
the generator bounds.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1049UTIndexSet.sac function inlining takes 4 minutes, 21 seconds on 1.8GHz 2-hole...2017-11-19T20:19:03ZRobert BerneckyUTIndexSet.sac function inlining takes 4 minutes, 21 seconds on 1.8GHz 2-holer Opteron| | |
| --- | --- |
| Bugzilla Link | [612](http://bugs.sac-home.org/show_bug.cgi?id=612) |
| Created on | Nov 27, 2009 15:03 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTIndexSet.sac](/uploads/59e4d7d16d...| | |
| --- | --- |
| Bugzilla Link | [612](http://bugs.sac-home.org/show_bug.cgi?id=612) |
| Created on | Nov 27, 2009 15:03 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTIndexSet.sac](/uploads/59e4d7d16d61cd19281387aa10f7df79/UTIndexSet.sac), [UTThornBoolean.sac](/uploads/17c326b57111db9c7fc7ea0aed6d87e3/UTThornBoolean.sac), [crud.sac](/uploads/3eec18b85236f9fced2bc9c922394939/crud.sac) |
## Extended Description
<pre>Created an attachment (id=616)
Source code to reproduce fault
Build #developer rev 16638. Summary says it all.
This amount of time to copy some code
seems a trifle excessive.
Otherwise, no problem.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1259Stack overflow and segfault in DCRvardec when compiling with -check ctb2017-11-19T20:34:09ZDaniel RollsStack overflow and segfault in DCRvardec when compiling with -check ctb| | |
| --- | --- |
| Bugzilla Link | [613](http://bugs.sac-home.org/show_bug.cgi?id=613) |
| Created on | Dec 06, 2009 01:10 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>sac2c product version 1...| | |
| --- | --- |
| Bugzilla Link | [613](http://bugs.sac-home.org/show_bug.cgi?id=613) |
| Created on | Dec 06, 2009 01:10 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>sac2c product version 16651
From the sac repository compile demos/numerical/tvd/tvd_abstract.sac (version 1171) with the following command:
sac2c-p -O3 -v1 -maxlur 10 -L fluid tvd2d_abstract.sac -check ctb
and it segfaults in DCRvardec (stdopt/deadcoderemoval.c:506).
Run
sac2c-d -O3 -v1 -maxlur 10 -L fluid tvd2d_abstract.sac -check ctb
and stack overflow warnings are produced:
WARNING: dbug-maxdepth 40000 too low
I enabled the automatic tracing in _db_enter_ in dbug.c and saved the output. The file is quite large so I haven't uploaded it. It is here:
obelix:/home/dsr/tvdabstract-autotrace</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1198Corrupt AST detected in code-generation with MT "if-clause condition is neith...2017-11-19T20:29:43ZDaniel RollsCorrupt AST detected in code-generation with MT "if-clause condition is neither a N_id nor a N_bool node!"| | |
| --- | --- |
| Bugzilla Link | [614](http://bugs.sac-home.org/show_bug.cgi?id=614) |
| Created on | Dec 07, 2009 22:39 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [tvdnd_abstract.sac](/uploads/09e10ee3...| | |
| --- | --- |
| Bugzilla Link | [614](http://bugs.sac-home.org/show_bug.cgi?id=614) |
| Created on | Dec 07, 2009 22:39 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [tvdnd_abstract.sac](/uploads/09e10ee3e911accaffebc5f78ad5d3ca/tvdnd_abstract.sac) |
## Extended Description
<pre>Created an attachment (id=617)
source code
sac2c-d revision 16651
Compile tvdnd_abstract with:
sac2c-d -O3 -v1 -maxlur 10 -L fluid -mt tvdnd_abstract.sac -DDIM=2 -o tvdndnd_abstract_mt -v3 -dtreecheck
I need to add the -mt switch to get the error:
** 19: Generating Code ...
**** Tag preparation ...
**** Converting to old type representation ...
**** Creating intermediate code macros ...
ASSERTION FAILED: file 'codegen/compile.c', line 7087
if-clause condition is neither a N_id nor a N_bool node!
EXECUTION TERMINATED
The sac source file is attached.</pre>Clemens GrelckClemens Grelckhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2171Potential memory leak in StringArray2021-08-31T11:47:07ZDaniel RollsPotential memory leak in StringArray| | |
| --- | --- |
| Bugzilla Link | [616](http://bugs.sac-home.org/show_bug.cgi?id=616) |
| Created on | Dec 11, 2009 00:07 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [testStringArray3.sac](/uploads/9943d5...| | |
| --- | --- |
| Bugzilla Link | [616](http://bugs.sac-home.org/show_bug.cgi?id=616) |
| Created on | Dec 11, 2009 00:07 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [testStringArray3.sac](/uploads/9943d571604e4ae398fe1431648afb4d/testStringArray3.sac) |
## Extended Description
<pre>Created an attachment (id=619)
testcase (SaC source)
The attached test case when run with
sac2c -check ctb testStringArray3.sac && a.out
triggers a segfault in the first call to free in
modules/structures/src/StringArray/sel.c. Carl and I fixed this for now by
commenting out this line but don't know how this works. We may have even
inadvertently created a memory leak. To reproduce the problem first uncomment
the call to SAC_ND_DEC_RC_FREE and run the test case as described above.</pre>Sven-Bodo ScholzSven-Bodo Scholz