sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:34:09Zhttps://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/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/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/1256Corrupted N_assign node after WLSIMP on ipbb.sac2017-11-19T20:33:58ZRobert BerneckyCorrupted N_assign node after WLSIMP on ipbb.sac| | |
| --- | --- |
| Bugzilla Link | [1145](http://bugs.sac-home.org/show_bug.cgi?id=1145) |
| Created on | Feb 18, 2015 19:51 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbb.sac](/uploads/7dd58faf11656e...| | |
| --- | --- |
| Bugzilla Link | [1145](http://bugs.sac-home.org/show_bug.cgi?id=1145) |
| Created on | Feb 18, 2015 19:51 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbb.sac](/uploads/7dd58faf11656ee30e3a36c4d9084aee/ipbb.sac) |
## Extended Description
<pre>Created an attachment (id=1031)
source code to cause failure
[May be related to Bug #487]
This dies in treecheck, after wlsimp runs the first time:
sac2c ipbb.sac -chkfreq 4 -d treecheck
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18521 linux-gnu_x86_64
(Wed Feb 18 10:48:33 EST 2015 by sac)
This failure mode requires the above build, which includes
validation of node type for AVIS_SSAASSIGN nodes.
Earlier builds still fail, but later on, probably in VPid,
due to the above node being corrupted.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1255CF failure: SCSprf_val_lt_val_SxS evaporates val_lt_val_SxS_( const, const) g...2017-11-19T20:33:54ZRobert BerneckyCF failure: SCSprf_val_lt_val_SxS evaporates val_lt_val_SxS_( const, const) guard| | |
| --- | --- |
| Bugzilla Link | [1127](http://bugs.sac-home.org/show_bug.cgi?id=1127) |
| Created on | Jul 23, 2014 21:22 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I just stumbled acr...| | |
| --- | --- |
| Bugzilla Link | [1127](http://bugs.sac-home.org/show_bug.cgi?id=1127) |
| Created on | Jul 23, 2014 21:22 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I just stumbled across this failure.
The offending code had been copy/pasted from the val_le_val_SxS code,
and I missed Case 2 now being rubbish. There is also at least two COlt calls
that are also rubbbish.
Fix to come over the weekend.
Failing code:
int[*] id(int[*] y)
{
return( y);
}
int main()
{
x = 0;
y = id(1);
y, p = _non_neg_val_S_( y);
z, p = _val_lt_val_SxS_( x, y);
return( z);
}</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1254sac2c fails to WLF in AKD case2017-11-19T20:33:51ZSven-Bodo Scholzsac2c fails to WLF in AKD case| | |
| --- | --- |
| Bugzilla Link | [1116](http://bugs.sac-home.org/show_bug.cgi?id=1116) |
| Created on | Feb 21, 2014 15:00 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [tutu.sac](/uploads/40ae0f334ea3a708...| | |
| --- | --- |
| Bugzilla Link | [1116](http://bugs.sac-home.org/show_bug.cgi?id=1116) |
| Created on | Feb 21, 2014 15:00 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [tutu.sac](/uploads/40ae0f334ea3a708a83379abfac91ff7/tutu.sac) |
## Extended Description
Created an attachment (id=1004)
source code
Naively, I would assume that both functions eulerTotient and sumTotient should fold into individual
WLs. However, breaking after the optimisations reveals sac2c in both cases does not do so.Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1253Compiling partitionslicerFailure.simpler.sac AWLF unit with -noctz gives wron...2017-11-19T20:33:48ZRobert BerneckyCompiling partitionslicerFailure.simpler.sac AWLF unit with -noctz gives wrong answer| | |
| --- | --- |
| Bugzilla Link | [1098](http://bugs.sac-home.org/show_bug.cgi?id=1098) |
| Created on | Oct 10, 2013 16:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [partitionslicerFailure.simpler.sa...| | |
| --- | --- |
| Bugzilla Link | [1098](http://bugs.sac-home.org/show_bug.cgi?id=1098) |
| Created on | Oct 10, 2013 16:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [partitionslicerFailure.simpler.sac](/uploads/86614eddb7430476520945d1abd68432/partitionslicerFailure.simpler.sac) |
## Extended Description
<pre>Created an attachment (id=993)
source code to reproduce fault
sac2c partitionslicerFailure.simpler.sac -v1 -doawlf -nowlf
warning: AWLF is enabled: -ecc enabled.
warning: AWLF is enabled: -extrema enabled.
warning: AWLF is enabled: -maxoptcyc=20
sac@rattler:~/sac/testsuite/optimizations/awlf$ a.out; echo $?40000
0
sac@rattler:~/sac/testsuite/optimizations/awlf$ sac2c partitionslicerFailure.simpler.sac -v1 -doawlf -nowlf -noctz
warning: AWLF is enabled: -ecc enabled.
warning: AWLF is enabled: -extrema enabled.
warning: AWLF is enabled: -maxoptcyc=20
sac@rattler:~/sac/testsuite/optimizations/awlf$ a.out; echo $?-nan
255
sac@rattler:~/sac/testsuite/optimizations/awlf$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 18396 linux-gnu_x86_64
(Wed Oct 9 16:38:56 EDT 2013 by sac)
I'm not sure what's going on here: I eyeballed some -bopt code
last night, to no avail.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1252WRCI can't handle AKD arrays2017-11-19T20:33:44ZRobert BerneckyWRCI can't handle AKD arrays| | |
| --- | --- |
| Bugzilla Link | [1094](http://bugs.sac-home.org/show_bug.cgi?id=1094) |
| Created on | Oct 02, 2013 21:47 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [wrciOffsetAKD.sac](/uploads/8dec6...| | |
| --- | --- |
| Bugzilla Link | [1094](http://bugs.sac-home.org/show_bug.cgi?id=1094) |
| Created on | Oct 02, 2013 21:47 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [wrciOffsetAKD.sac](/uploads/8dec64b73def638b9bcdbcc125567f89/wrciOffsetAKD.sac) |
## Extended Description
<pre>Created an attachment (id=989)
source code to reproduce fault
The wrci unit test suite now includes wrciOffset.sac and wrciOffsetAKD.sac;
these are intended to show array reuse on AKS and AKD arrays, respectively.
WRCI does not support AKD arrays, which really sucks.
Here's an example of AKD code, where a reference with offset (to
another partition) to the reuse candidate array could work, but does
not.
AAA = _reshape_VxA_( id( [ 25, 10]), iota( id( 250)));
gw = shape( AAA) - [ 15, 0]; // AKA [10 10]
AAA = with {
([0,0] <= iv < gw): AAA[iv + [ 10, 0]] + 1000;
} : modarray(AAA);
I intend to move IVEXC after WRCI, and then "should" be able to
extend WRCI/RWO to do the job.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1251CTZ not quite dead yet2017-11-19T20:33:41ZRobert BerneckyCTZ not quite dead yet| | |
| --- | --- |
| Bugzilla Link | [1091](http://bugs.sac-home.org/show_bug.cgi?id=1091) |
| Created on | Sep 27, 2013 18:31 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [cubslcrash.sac](/uploads/f124a11e...| | |
| --- | --- |
| Bugzilla Link | [1091](http://bugs.sac-home.org/show_bug.cgi?id=1091) |
| Created on | Sep 27, 2013 18:31 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [cubslcrash.sac](/uploads/f124a11e3ccc05b522c00db738ddd42b/cubslcrash.sac) |
## Extended Description
<pre>Created an attachment (id=988)
source code to reproduce fault
I am trying to kill off -doctz, but there are still a few outstanding
problems in doing so. One of them can be seen in the CF unit test
cubslcrash.sac (wlcondoAKD in disguise).
If I compile it under Build #18310 with these options:
sac2c cubslcrash.sac -doawlf -nowlf -bopt -noctz > crud
I get this:
* Partn */
([ _pinl_2639__flat_33 ] <= _pinl_4008_iv=[_pinl_4011__eat_53] < [ N__SSA0_1 ] genwidth [ _wlsimp_18791 ])
{
_dup_15405__pinl_4022__ea_2463__icc_2038 = _accu_( _pinl_4008_iv);
_dl_17285 = _mul_SxS_( 2, _pinl_4011__eat_53);
_dl_17286 = _add_SxS_( _dl_17285, _dl_17423);
_dup_15420__pinl_2650__flat_507 = _eq_SxS_( _pinl_4011__eat_53, _pinl_2639__flat_33);
_dup_15421__pinl_2697__flat_507 = _eq_SxS_( 0, _pinl_4011__eat_53);
_dup_15422__pinl_2746__flat_995 = _or_SxS_( _dup_15420__pinl_2650__flat_507, _dup_15421__pinl_2697__flat_507);
_dup_15423__pinl_3708__flat_1002 = _not_S_( _dup_15422__pinl_2746__flat_995);
_dup_15424__pinl_3754__flat_1282 = _toi_S_( _dup_15423__pinl_3708__flat_1002);
_dup_15425__pinl_3803__flat_21 = _mul_SxS_( _dl_17286, _dup_15424__pinl_3754__flat_1282);
_dup_15426__pinl_3855__flat_1282 = _toi_S_( _dup_15422__pinl_2746__flat_995);
_dup_15427__pinl_3904__flat_21 = _mul_SxS_( _dup_15426__pinl_3855__flat_1282, _pinl_4011__eat_53);
_dup_15428__pinl_3959__flat_5 = _add_SxS_( _dup_15425__pinl_3803__flat_21, _dup_15427__pinl_3904__flat_21);
_dup_15429__pinl_4027__flat_32 = _add_SxS_( _dup_15405__pinl_4022__ea_2463__icc_2038, _dup_15428__pinl_3959__flat_5);
} : _dup_15429__pinl_4027__flat_32 ; ,
If I compile it this way:
sac2c cubslcrash.sac -doawlf -nowlf -bopt > crud
I get this much more delightful code:
/* Partn */
([ 1 ] <= _pinl_4008_iv=[_pinl_4011__eat_53] < [ _pinl_2639__flat_33 ] genwidth [ _wlsimp_19688 ])
{
_dup_18517__pinl_4022__ea_2463__icc_2038 = _accu_( _pinl_4008_iv);
_dup_18521__dl_18404 = _mul_SxS_( 2, _pinl_4011__eat_53);
_dup_18534__pinl_4027__flat_32 = _add_SxS_( _dup_18517__pinl_4022__ea_2463__icc_2038, _dup_18521__dl_18404);
} : _dup_18534__pinl_4027__flat_32 ; ,
I'll go see if this is fixable. My desire is to disable CTZ (or kill it)
as CF and some of its friends are supposed to have enough smarts to
handle the sort of functional compositions that arise...</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1250shift() function folds with hidden constant count, but not with constant!2017-11-19T20:33:37ZRobert Berneckyshift() function folds with hidden constant count, but not with constant!| | |
| --- | --- |
| Bugzilla Link | [1081](http://bugs.sac-home.org/show_bug.cgi?id=1081) |
| Created on | May 14, 2013 14:42 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [shifttest.sac](/uploads/0324ef1c5...| | |
| --- | --- |
| Bugzilla Link | [1081](http://bugs.sac-home.org/show_bug.cgi?id=1081) |
| Created on | May 14, 2013 14:42 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [shifttest.sac](/uploads/0324ef1c5410fddf49d3229ea2331305/shifttest.sac) |
## Extended Description
<pre>This is weird:
I have a hand-rolled version of the stdlib shift() function,
which will AWLF if I give it a hidden constant count, eg. id( 5),
but not if I give it a constant - 5.
I'm looking into it now.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 18145 linux-gnu_x86_64
(Tue May 14 09:34:10 EDT 2013 by sac)
sac2c -doawlf -nowlf shifttest.sac -bopt >crud
Also, the non-constant version ends up with two partitions,
and the constant version has three!</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1249AWLF unit test dropAKDrank2.sac fails in several ways, depending on prod/dev ...2017-11-19T20:33:34ZRobert BerneckyAWLF unit test dropAKDrank2.sac fails in several ways, depending on prod/dev version| | |
| --- | --- |
| Bugzilla Link | [1080](http://bugs.sac-home.org/show_bug.cgi?id=1080) |
| Created on | May 05, 2013 23:07 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [dropAKDrank2.sac](/uploads/d2d273...| | |
| --- | --- |
| Bugzilla Link | [1080](http://bugs.sac-home.org/show_bug.cgi?id=1080) |
| Created on | May 05, 2013 23:07 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [dropAKDrank2.sac](/uploads/d2d273e3334997c315414b0df967d128/dropAKDrank2.sac) |
## Extended Description
<pre>Created an attachment (id=977)
source code to reproduce fault
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 18133 linux-gnu_x86_64
(Sun May 5 11:30:39 EDT 2013 by sac)
The above unit test fails in at least two nasty waya:
1. Production version of sac2c:
sac2c dropAKDrank2.sac -v1 -doawlf -nowlf -v4
,,,
** 18: Preparing C code generation ...
**** Marking memval identifiers ...
OOOOOOOPS, your program crashed the compiler 8-((
2. Development version of sac2c:
* 13: Transforming with-loop representation ...
**** Simplifying with-loops ...
**** Transforming with-loop representation ...
wltransform/wltransform.c:7159 Assertion "strides != NULL" fa
3. And, we get wrong answers, too!
sac2c dropAKDrank2.sac -v1
sac@rattler:~/sac/testsuite/optimizations/awlf$ a.out
Dimension: 2
Shape : < 0, 10>
<>
sac@rattler:~/sac/testsuite/optimizations/awlf$ sac2c dropAKDrank2.sac -v1 -nodl
sac@rattler:~/sac/testsuite/optimizations/awlf$ a.out
Dimension: 2
Shape : < 1, 10>
|5.000000e-01 1.500000e+00 2.500000e+00 3.500000e+00 4.500000e+00 5.500000e+00 6.500000e+00 7.500000e+00 8.500000e+00 9.500000e+00 |
I'm assigning this one to myself, because of (3). However, there might
be refs to undefined variables in that back end code...</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1248UTCompress.sac benchmark generates wrong answer2017-11-19T20:33:30ZRobert BerneckyUTCompress.sac benchmark generates wrong answer| | |
| --- | --- |
| Bugzilla Link | [1077](http://bugs.sac-home.org/show_bug.cgi?id=1077) |
| Created on | May 03, 2013 22:23 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/74e1e74e3a5c4a...| | |
| --- | --- |
| Bugzilla Link | [1077](http://bugs.sac-home.org/show_bug.cgi?id=1077) |
| Created on | May 03, 2013 22:23 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/74e1e74e3a5c4acd91ec80b691bb5e8c/crud.sac) |
## Extended Description
<pre>Created an attachment (id=975)
source code to reproduce fault
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 18133 linux-gnu_x86_64
(Fri May 3 16:23:38 EDT 2013 by sac)
apex@rattler:~/apex3/benchmks/UTCompress$ sac2c crud.sac -nodl
apex@rattler:~/apex3/benchmks/UTCompress$ a.out
Dimension: 3
Shape : < 1, 3, 4>
< 0 1 2 3 > < 4 5 6 7 > < 8 9 10 11 >
Dimension: 3
Shape : < 2, 3, 4>
< 0 1 2 3 > < 4 5 6 7 > < 8 9 10 11 >
<12 13 14 15 > <16 17 18 19 > <20 21 22 23 >
The first output is what we get; the second output is what we
are supposed to get!
This is not related to DL, as -nodl gives us the same fault.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1247No error message from typechecker on failure2017-11-19T20:33:27ZRobert BerneckyNo error message from typechecker on failure| | |
| --- | --- |
| Bugzilla Link | [1076](http://bugs.sac-home.org/show_bug.cgi?id=1076) |
| Created on | May 03, 2013 20:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [relaxAKDnotake.sac](/uploads/0d38...| | |
| --- | --- |
| Bugzilla Link | [1076](http://bugs.sac-home.org/show_bug.cgi?id=1076) |
| Created on | May 03, 2013 20:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [relaxAKDnotake.sac](/uploads/0d380580250fdae8947adc67b75f1da2/relaxAKDnotake.sac) |
## Extended Description
<pre>Created an attachment (id=974)
source code to reproduce fault
This on an AWLF unit test.
...
Inferring algebraically foldable with-loops ...
*** Compilation failed ***
*** Exit code 82 (Running SAC optimizations)
*** 1 Error(s), 3 Warning(s)
[Not much help, eh?]
sac@rattler:~/sac/testsuite/optimizations/awlf$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 18133 linux-gnu_x86_64
(Fri May 3 10:26:21 EDT 2013 by sac)
sac@rattler:~/sac/testsuite/optimizations/awlf$ sac2c-d relaxAKDnotake.sac -v4 -doawlf -nowlf
The actual failure is in EBTfundef, at the line:
CTIabortOnBottom( TYgetBottomError( bottom));
The failure arises from something to do with my recent DL extension, but
the failure mode of the compiler is most unpleasant.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1246DL fails on non-int argument if subtraction involved2017-11-19T20:33:23ZRobert BerneckyDL fails on non-int argument if subtraction involved| | |
| --- | --- |
| Bugzilla Link | [1055](http://bugs.sac-home.org/show_bug.cgi?id=1055) |
| Created on | Mar 30, 2013 15:32 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug1046double.sac](/uploads/c8f99...| | |
| --- | --- |
| Bugzilla Link | [1055](http://bugs.sac-home.org/show_bug.cgi?id=1055) |
| Created on | Mar 30, 2013 15:32 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug1046double.sac](/uploads/c8f99e8619205ec5f0fd0030f460ee3f/bug1046double.sac), [bug1046G.sac](/uploads/ee3b4631ccb6113de2507ca57812e835/bug1046G.sac) |
## Extended Description
<pre>Created an attachment (id=954)
source code to reproduce fault
~/sac/testsuite/optimizations/dl$ UnitTestRunGrep1 bug1046double.sac
ERROR: line 23 in file bug1046double.sac:
ERROR: Element types of argument #1 and argument #2 of "_add_SxS_" should be
ERROR: identical; types found: double{2.0...} and int{-1}
rbe@rattler:~/texsrc/phd/dissertation$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 18086 linux-gnu_x86_64
(Fri Mar 29 17:41:13 EDT 2013 by sac)
This resulted from my recent DL changes. I'm heading out of town,
but will see if I can get it fixed in the next few minutes.
If not, I'll get to it first Tuesday.
Workaround until then: -nodl</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1245Livermore Loop loop09 sparse matrix multiply performance problem w/ -dolacsi2017-11-19T20:33:19ZRobert BerneckyLivermore Loop loop09 sparse matrix multiply performance problem w/ -dolacsi| | |
| --- | --- |
| Bugzilla Link | [1052](http://bugs.sac-home.org/show_bug.cgi?id=1052) |
| Created on | Mar 14, 2013 15:27 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [loop09A.sac](/uploads/9fae5685b6d...| | |
| --- | --- |
| Bugzilla Link | [1052](http://bugs.sac-home.org/show_bug.cgi?id=1052) |
| Created on | Mar 14, 2013 15:27 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [loop09A.sac](/uploads/9fae5685b6d70500f2132b44a2a85af4/loop09A.sac) |
## Extended Description
<pre>Created an attachment (id=952)
source code to reproduce fault
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 18069 linux-gnu_x86_64
(Wed Mar 13 17:40:45 EDT 2013 by sac)
I have made the SAC and C versions of loop09 match again, in the sense
that they return the same results. I have also reverted loop09 to the
earlier, imperative version, and created loop09A, a version that uses
the sparse vector-matrix multiply that I use in APEX.
Results are good, Almost... Here are the CPU times and cache miss rates
for same:
sac2c loop09A.sac -O3 -dolacsi -doawlf -nowlf -O3
CPU (usec) L1miss L2miss
loop09.c 2210390 20547020 1304
wlf loop09.sac 5228058 20041898 5567
awlf loop09.sac 2388230 19047599 2421
wlf loop09A.sac 10575784 64461221 6619
awlf loop09A.sac 4779216 105809057 3539
It is the last line that is puzzling. IMO, its performance should be
extremely close to that of the third line. But, it ain't.
What is going on is, essentially, this:
- Originally, Cond_0() in the inner loop is passed a 1-element vector V.
It uses V0=V[0] as GENERATOR_BOUND2( [V0]) and GENARRAY_SHAPE( [ V0]).
- -dolacsi allows elimination of the sel V0 = V[0],
- Someone (SAA?) generates V' = [ V0] as the result shape of the
Cond_0 result.
- Eventually, we end up with a funcond at the end of Cond_0(),
roughly of this form:
V' = [ V0];
shp = flat_1 ? V' : V;
Both legs of the funcond match, so this is really just: shp = V.
That should get shp lifted out of Cond_0(), but nothing has
enough smarts to do that.
We end up, therefore, with all this baggage in the inner loop,
of which the building of V' is causing most of the harm.
Possible actions:
1. I do not think we can do much in LACSI about these things.
The shp-related code goes through a lot of optimization before
we get to the point above.
2. We do happen to have AVIS_SCALARS( V) = [ V0]. It should be possible
to make CF or one of its buddies that looks at funconds check to see
if one funcond argument is an N_array that matches the AVIS_SCALARS
of the other and, if so, replace things appropriately:
shp = flat_1 ? V : V;
[Premature replacement by: shp = V; is bad, because of the delicate
nature of the funcond structure. That will get done elsewhere.]
The latter is fairly straightforward, so I'm going to try that approach.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1244Livermore Loop loop09.sac sparse matrix multiply sensitive to argument ordering2017-11-19T20:33:15ZRobert BerneckyLivermore Loop loop09.sac sparse matrix multiply sensitive to argument ordering| | |
| --- | --- |
| Bugzilla Link | [1051](http://bugs.sac-home.org/show_bug.cgi?id=1051) |
| Created on | Mar 08, 2013 18:44 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This sparse matrix ...| | |
| --- | --- |
| Bugzilla Link | [1051](http://bugs.sac-home.org/show_bug.cgi?id=1051) |
| Created on | Mar 08, 2013 18:44 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This sparse matrix kernel in loop09.sac exhibits an undesirable sensitivity to
argument ordering:
inline double[.] vecmatmul( double[.] wts, double[.,.] PX) {
/* Sparse wts matrix multiply: wts f.g PX */
colsx = shape(wts)[0];
colsy = shape(PX)[1];
z = genarray([colsy], 0.0d);
for (colx=0; colx<colsx; colx++) {
if (0.0 != wts[colx]) { /* Skip iteration if it's an f identity */
z = z + wts[colx] * PX[colx];
}
}
return(z);
}
In particular, AWLF fails for the computation of z within the if(),
because the stdlib dyadic scalar function code was depending on
shape(z), rather than the shape of its right argument. Comments:
1. The array shapes are conformable for inner product, but LIR and
friends make it difficult for AWLF to deduce that the two genarray
shapes do, indeed, match.
2. I changed the stdlib dyadic scalar template to use the right argument
shape, because I think that should improve the chances of AWLF working
in typical function compositions, such as A + ( B * C).
3. Compiling with -dolacsi and/or -dolacso did not help.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1243APEX benchmark UTCompress.sac dies in EBT2017-11-19T20:33:11ZRobert BerneckyAPEX benchmark UTCompress.sac dies in EBT| | |
| --- | --- |
| Bugzilla Link | [1049](http://bugs.sac-home.org/show_bug.cgi?id=1049) |
| Created on | Mar 01, 2013 22:31 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>With this version o...| | |
| --- | --- |
| Bugzilla Link | [1049](http://bugs.sac-home.org/show_bug.cgi?id=1049) |
| Created on | Mar 01, 2013 22:31 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>With this version of SAC:
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18061 linux-gnu_x86_64
(Fri Mar 1 17:24:54 EST 2013 by sac)
and this command line:
sac2c-d crud.sac -doawlf -nowlf -v4
use Array: all;
int main()
{
y=genarray([2, 3, 4],5);
sy = shape(y);
Z = (true == (false)) ? y : genarray(drop([-1],sy)++[0],0);
StdIO::print( Z);
return(0 );
}
sac2c dies in -bopt:cyc:ebt:3.
Since it compiles OK if you leave off the -doawlf, I presume this is
my doing.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1242AWLF unit test failure with rotate2017-11-19T20:33:08ZRobert BerneckyAWLF unit test failure with rotate| | |
| --- | --- |
| Bugzilla Link | [1036](http://bugs.sac-home.org/show_bug.cgi?id=1036) |
| Created on | Nov 18, 2012 18:07 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud3.sac](/uploads/7889a64e94b93...| | |
| --- | --- |
| Bugzilla Link | [1036](http://bugs.sac-home.org/show_bug.cgi?id=1036) |
| Created on | Nov 18, 2012 18:07 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud3.sac](/uploads/7889a64e94b9303b12760ba4b7a02eb7/crud3.sac) |
## Extended Description
<pre>Created an attachment (id=939)
source code to reproduce fault
AWLF was working, but stopped working some time around/after July, on
some cases where (I think) the consumer WL is using a subtraction
on its index vector. The immediate failure is inability to compute
the predicate WLINTERSECTION1PART.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18028 linux-gnu_x86_64
(Thu Nov 15 16:04:14 EST 2012 by sac)
sac2c crud3.sac -doawlf -nowlf -v1 -bopt:uglf >crud</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1241rle.sac failure: LACSO vs. DCR causes crash in WLIR2017-11-19T20:33:04ZRobert Berneckyrle.sac failure: LACSO vs. DCR causes crash in WLIR| | |
| --- | --- |
| Bugzilla Link | [1034](http://bugs.sac-home.org/show_bug.cgi?id=1034) |
| Created on | Nov 08, 2012 23:05 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.breaks.sac](/uploads/64beb41...| | |
| --- | --- |
| Bugzilla Link | [1034](http://bugs.sac-home.org/show_bug.cgi?id=1034) |
| Created on | Nov 08, 2012 23:05 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.breaks.sac](/uploads/64beb41c52528b84bbd678a69c225ad0/crud.breaks.sac) |
## Extended Description
<pre>cd sac/apex/rle
sac@rattler:~/sac/apex/rle$ sac2c rle.sac -v1
stdopt/withloop_invariant_removal.c:861 Assertion "AVIS_DEFDEPTH(ID_AVIS(arg_node)) != DD_UNDEFINED" failed!
reference to undefined identifier _lacso_17413
sac@rattler:~/sac/apex/rle$ sac2c rle.sac -v1 -nolacso
sac2c -V
sac@rattler:~/sac/apex/rle$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18019 linux-gnu_x86_64
(Thu Nov 8 17:08:16 EST 2012 by sac)
I believe what is going on is this:
1. LACSO introduces a new scalar result value, which
is never used in the calling context, but it IS used
as an AVIS_SHAPE element in the called context.
2. DCR comes along, sees that the result value is unused in
the caller, so deletes the N_funcond after the recursive
call, which then marks the recursive call result dead.
3. Things eventually die in WLIR.
I think the correct fix is to make DCR check for
uses of the result value in AVIS son nodes, and mark
the avis as live if that is the case. I don't like this
approach, but have no better ideas yet.</pre>Robert BerneckyRobert Berneckyhttps://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 Bernecky