sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:29:28Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1193msa and data reuse do not play nice2017-11-19T20:29:28ZCarl Joslinmsa and data reuse do not play nice| | |
| --- | --- |
| Bugzilla Link | [753](http://bugs.sac-home.org/show_bug.cgi?id=753) |
| Created on | Sep 30, 2010 18:09 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
The nop partitions that ar...| | |
| --- | --- |
| Bugzilla Link | [753](http://bugs.sac-home.org/show_bug.cgi?id=753) |
| Created on | Sep 30, 2010 18:09 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
The nop partitions that are created with data reuse are not need in the mutc backend and should be removed.
These partitions also contain code that makes needless use of the descriptor of suballoced memory so msa removed desc's are used but they can not be used as they are not there. This is not a problem with msa because the code created for the nop of data reuse partitions is dead code and should be removed. ( Note dcr can not find this code/is not run at this point)Carl JoslinCarl Joslinhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1306Type relation syntax incompatible with language2017-11-19T20:37:19ZClemens GrelckType relation syntax incompatible with language| | |
| --- | --- |
| Bugzilla Link | [751](http://bugs.sac-home.org/show_bug.cgi?id=751) |
| Created on | Sep 27, 2010 04:50 |
| Version | svn |
| OS | All |
| Architecture | All |
## Extended Description
<pre>The syntax invented fo...| | |
| --- | --- |
| Bugzilla Link | [751](http://bugs.sac-home.org/show_bug.cgi?id=751) |
| Created on | Sep 27, 2010 04:50 |
| Version | svn |
| OS | All |
| Architecture | All |
## Extended Description
<pre>The syntax invented for type relations using operators like .* .< .+
is incompatible with essential parts of the language otherwise, like
for instance the dots in generators.
I suggest to use a different syntax for type relations, e.g. ".*.".
That would be easy to scan and should avoid conflicts with existing
uses of the dot.
Currently, the parser allows spaces in between the dot and the combinator
to resolve conflicts. This can't be anything but a temporary fix.</pre>Santanu Kumar DashSantanu Kumar Dashhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1076modarray causes LIR failure2017-11-19T20:20:46ZRobert Berneckymodarray causes LIR failure| | |
| --- | --- |
| Bugzilla Link | [750](http://bugs.sac-home.org/show_bug.cgi?id=750) |
| Created on | Sep 26, 2010 17:48 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.reallyslow.sac](/uploads/4676d...| | |
| --- | --- |
| Bugzilla Link | [750](http://bugs.sac-home.org/show_bug.cgi?id=750) |
| Created on | Sep 26, 2010 17:48 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.reallyslow.sac](/uploads/4676d7b3e8db97b994da7456c0b66fb9/crud.reallyslow.sac) |
## Extended Description
<pre>Created an attachment (id=757)
source code to reproduce fault
The attached SAC code, if compiled with -DGOSLOW, ends up recomputing
the Boolean vector on every iteration through the indexof (iotaBBI) loop.
This is A Bad Thing, if you have any interest in (good) performance.
I just came across thie by accident, while lamenting the compiler's
inability to fold a WL into a FOR-loop.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1228how to deal with array constructors and selections2017-11-19T20:32:20ZSven-Bodo Scholzhow to deal with array constructors and selections| | |
| --- | --- |
| Bugzilla Link | [747](http://bugs.sac-home.org/show_bug.cgi?id=747) |
| Created on | Sep 17, 2010 07:43 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>This bug relates to bug...| | |
| --- | --- |
| Bugzilla Link | [747](http://bugs.sac-home.org/show_bug.cgi?id=747) |
| Created on | Sep 17, 2010 07:43 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>This bug relates to bug 746 but is of a more specific nature.
The overall question is:
- when to lift an array constructor out of loops/conditionals
- when to push it in
and
- how to steer that behaviour advantageously
Naively, one might argue that arrays should always be lifted as far as possible.
Unfortunately, that does not hold for index vectors that are used in selections or
modarray operations. There, it is often (not always!) advantageous to propagate them
down as they may avoid a vect2offset.
A thorough analysis of the situation is asked for.....</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1305Failed to make by adding long type in Templates.mac2017-11-19T20:37:16ZSalem ReyenFailed to make by adding long type in Templates.mac| | |
| --- | --- |
| Bugzilla Link | [739](http://bugs.sac-home.org/show_bug.cgi?id=739) |
| Created on | Aug 18, 2010 10:01 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [Templates.mac](/uploads/7ebdd4...| | |
| --- | --- |
| Bugzilla Link | [739](http://bugs.sac-home.org/show_bug.cgi?id=739) |
| Created on | Aug 18, 2010 10:01 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [Templates.mac](/uploads/7ebdd47fc52790511eb4c46abcc32d8b/Templates.mac), [ArrayBasics.sacbugreport](/uploads/ce56eab2c8558074b48e0393e0bbedf6/ArrayBasics.sacbugreport) |
## Extended Description
<pre>Since I need the long type for stdlib, I add the long types you really need to the list in the CPP else case in /modules/structures/Templates.mac.
linux@linux-desktop:~/sac2c-1.00-beta-linux-x86_64/stdlib$ make mtfast
make -f buildfile "MTSAC2CFLAGS=-mt" MODE=lean
Module SDLisplay cannot be built because libSDL was not found
Module Gnuplot cannot be built because gnuplot was not found
Module Dislin cannot be built because DISLIN was not found
Module PNG cannot be built because libpng was not found
cd modules/structures/lib/..; sac2c -v0 -O3 -linksetsize 0 -mt ArrayBasics.sac -o lib
OOOOOOOPS, your program crashed the compiler 8-((
Please, send a bug report to bugs@sac-home.org,
or file a bug in the SaC-Zilla bug management system.
For your convenience, the compiler has pre-fabricated a bug report
in the file "./ArrayBasics.sacbugreport" !
Besides some infos concerning the compiler version and its
usage it contains the specified source file.
If you want to send that bug report to us, you may simply type
mail bugs@sac-home.org < ArrayBasics.sacbugreport
If you decide to file a bug in SaC-Zilla, please go to
http://bugs.sac-home.org/.
When filing a bug report, please copy/paste the initial comment section of
the bug report into the plain text comment section of SaC-Zilla, and add
the whole bug report file as an attachment.
Aborted
make[1]: *** [modules/structures/lib/libArrayBasicsTree.so] Error 134
make: *** [mtfast] Error 2</pre>Santanu Kumar DashSantanu Kumar Dashhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1031CTS generates wrong type scalar2017-11-19T20:18:01ZRobert BerneckyCTS generates wrong type scalar| | |
| --- | --- |
| Bugzilla Link | [718](http://bugs.sac-home.org/show_bug.cgi?id=718) |
| Created on | Jun 09, 2010 21:11 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/2b3a65750ab53263...| | |
| --- | --- |
| Bugzilla Link | [718](http://bugs.sac-home.org/show_bug.cgi?id=718) |
| Created on | Jun 09, 2010 21:11 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/2b3a65750ab53263275ee6db64541598/crud.sac) |
## Extended Description
<pre>Created an attachment (id=732)
source code to reproduce fault
If I compile the attached with "sac2c crud.sac", sac2c
Build #16882:MODIFIED crashes with:
ASSERTION FAILED: file 'typecheck/new_types.c.old', line 647
TYgetSimpleType applied to nonsimple-type!
EXECUTION TERMINATED
The cause is an incorrect type declaration
for the scalar 0 in the following code:
bool _MAIN:Structures::_dup_23711_match__Cond_9( bool _flat_77 { ,NN } , int[.,.] arr_b { ,NN } , int[+] arr_a { ,NN } )
/*
* _dup_23711_match__Cond_9 :: ---
*/
{
int[2] _ctz_23227 { , NN, } ;
int[2] _ctz_23228 { , NN, } ;
...
_ctz_23227 = _sub_VxV_( _flat_81, _flat_82);
_ctz_23228 = 0;
_flat_80 = _eq_VxS_( _ctz_23227, _ctz_23228);</pre>Aram VisserAram Visserhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1075Numerical constants printed without qualifier2017-11-19T20:20:42ZClemens GrelckNumerical constants printed without qualifier| | |
| --- | --- |
| Bugzilla Link | [715](http://bugs.sac-home.org/show_bug.cgi?id=715) |
| Created on | May 28, 2010 08:45 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Numerical constants o...| | |
| --- | --- |
| Bugzilla Link | [715](http://bugs.sac-home.org/show_bug.cgi?id=715) |
| Created on | May 28, 2010 08:45 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Numerical constants of the new built-in types short/long/unsigned/etc
are printed without the agree character extension. That makes them difficult
to distinguish from standard int constants and is incompatible to the
parser.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1199AL causes CYC,SAACYC to run until maxoptcyc on prd.sac AWLF unit test2017-11-19T20:29:47ZRobert BerneckyAL causes CYC,SAACYC to run until maxoptcyc on prd.sac AWLF unit test| | |
| --- | --- |
| Bugzilla Link | [711](http://bugs.sac-home.org/show_bug.cgi?id=711) |
| Created on | May 14, 2010 20:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [prd.sac](/uploads/8ae0ce0008be269ab...| | |
| --- | --- |
| Bugzilla Link | [711](http://bugs.sac-home.org/show_bug.cgi?id=711) |
| Created on | May 14, 2010 20:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [prd.sac](/uploads/8ae0ce0008be269aba92c7c4063188d4/prd.sac) |
## Extended Description
<pre>Created an attachment (id=715)
source code to reproduce fault
It looks to me that AL has gone for a burton. sac2c prd.sac (and everything else...) runs for maxoptcyc in both CYC and SAACYC.
I took a look at the prdreverseAKD.sac unit test, and observed these
differences around cycle 23.
After esdcse (right before AL):
_al_2410 = _add_SxS_( _pinl_672__ea_584__icc_450, _ivexp_1865_aeb);
_al_2411 = _add_SxS_( _ivexp_1868_is, _al_2410);
After AL:
_al_2410 = _add_SxS_( _pinl_672__ea_584__icc_450, _ivexp_1865_aeb);
_al_2440 = _add_SxS_( _pinl_672__ea_584__icc_450, _ivexp_1865_aeb);
_al_2441 = _add_SxS_( _ivexp_1868_is, _al_2440);
_al_2411 = _al_2441;
Doesn't hardly seem worth it, eh? _al2410 is now dead code.
This is the behavior on 16836:MODIFIED, on rattler (not checked in).
It is NOT, however, the sole cause of the opt loop, because running with
-noal still runs for maxoptcyc cycles.
Build #16794:MODIFIED, on obelix, exhibits the same behavior.</pre>Clemens GrelckClemens Grelckhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1074ipbdAKD.sac peformance problems w/ AWLF, extrema2017-11-19T20:20:39ZRobert BerneckyipbdAKD.sac peformance problems w/ AWLF, extrema| | |
| --- | --- |
| Bugzilla Link | [710](http://bugs.sac-home.org/show_bug.cgi?id=710) |
| Created on | May 14, 2010 14:11 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/288e6db606a55863...| | |
| --- | --- |
| Bugzilla Link | [710](http://bugs.sac-home.org/show_bug.cgi?id=710) |
| Created on | May 14, 2010 14:11 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/288e6db606a55863dceebcb964947815/crud.sac), [xcrud.sac](/uploads/95f6705d751325e2d8b226b1d5bf577b/xcrud.sac), [crud.ecclir.gz](/uploads/78cd2711a3c4f51c09277f897ef46dbc/crud.ecclir.gz) |
## Extended Description
<pre>Created an attachment (id=712)
source code to reproduce fault
Recent code changes on rattler, either due to my AWLF/extrema work, the WLBSC
changes of yesterday, other repository changes, or some combination thereof,
have clobbered the performance of some APEX benchmarks. The Boolean-double
matrix product ipbdAKD is typical of these.
The Loop_1 function contains this unpleasantness:
_ivesplit_16330 = 0;
_ivesplit_16331 = 1;
_ = with {
([ 0 ] <= _pinl_9242_iv=[_eat_11993] (IDXS:_wlidx_16309__pinl_9233__icc_4507) < [ _uprf_12172 ])
{
_pinl_9243_new_idx = _cat_VxV_( row, _pinl_9242_iv);
_uprf_12161 = _idx_sel_( _ivesplit_16330, _pinl_9243_new_idx);
_uprf_12166 = _idx_sel_( _ivesplit_16331, _pinl_9243_new_idx);
_ivesplit_16332 = _idxs2offset_( _isaa_12791_x, _uprf_12161, _uprf_12166);
_pinl_9232__icc_4505 = _idx_sel_( _ivesplit_16332, x);
} : _pinl_9232__icc_4505 ;
} :
genarray( [ _uprf_12172 ], _pinl_9241__flat_68, IDX(_wlidx_16309__pinl_9233__icc_4507));
_ivesplit_16333 = colx;
_pinl_9276__icc_3294 = _idx_sel_( _ivesplit_16333, _pinl_9233__icc_4507);
Note that:
1. _pinl_9233__icc_4507 is copying a row from x.
2. The following reference to that result selects a single element from
that row.
I'll try to come up a short example of this, but the code base
exists only on rattler at this juncture, so you won't easily be able to
try it.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/10734.79X post-Loch Ness performance loss in histlp.sac2017-11-19T20:20:34ZRobert Bernecky4.79X post-Loch Ness performance loss in histlp.sac| | |
| --- | --- |
| Bugzilla Link | [709](http://bugs.sac-home.org/show_bug.cgi?id=709) |
| Created on | May 13, 2010 20:20 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/db69aa9ad2a097ab...| | |
| --- | --- |
| Bugzilla Link | [709](http://bugs.sac-home.org/show_bug.cgi?id=709) |
| Created on | May 13, 2010 20:20 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/db69aa9ad2a097ab48f3cfb2b9dd668e/crud.sac), [crud.b11](/uploads/f4213fcb925dab91a86458034d8886f1/crud.b11), [crud.prelochness](/uploads/f86d4eddbb1511444df856db7285aefe/crud.prelochness), [xcrud.prelochness](/uploads/6c80201793b29dc48abd37ecd7f3d7c1/xcrud.prelochness) |
## Extended Description
<pre>Created an attachment (id=710)
Dan's pre-Loch Ness -b13 output
This is the most egregious of the remaining performance loss problems
introduced at Loch Ness. apex/histlp/histlp.sac now executes about 5X slower
than pre-Loch Ness.
The Loop_0 functions before and after look nearly identical, except for
these two lines:
_pinl_3552__wlbsc_2356_sc_e = _idx_sel_( _ivesplit_5497, _isaa_4840_r_2);
_pinl_3553__wlbsc_2357_sc_bound = [ _pinl_3552__wlbsc_2356_sc_e ];
ivesplit_5497 is 0, but the Loop_0 function header doesn't see that; it
sees it as an AKS int.
Similarly, _isaa_4840_r_2 is a parameter, but it is int[1], and
_pinl_3553__wlbsc_2357_sc_bound becomes that parameter in the recursive call.
So, the two lines are, effectively, a no-op.
The picture is made a bit murkier by the fact that
_pinl_3553__wlbsc_2357_sc_bound is also one of the results of
Loop_0.
I can see how LIR might have trouble pulling these lines out of the loop
function. If we can't fancy up LIR enough to do the job, perhaps we
can do an UNWLBSC traversal somewhere around the end of Phase 11.
This, however, would not work in the current code, because _ivesplit_5497
is not AKV.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2174Livermore Loop 13 SAC vs. C code not equivalent2017-11-19T22:04:41ZRobert BerneckyLivermore Loop 13 SAC vs. C code not equivalent| | |
| --- | --- |
| Bugzilla Link | [708](http://bugs.sac-home.org/show_bug.cgi?id=708) |
| Created on | May 11, 2010 19:19 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The repositor...| | |
| --- | --- |
| Bugzilla Link | [708](http://bugs.sac-home.org/show_bug.cgi?id=708) |
| Created on | May 11, 2010 19:19 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The repository copy of SAC Loop 13 code reads its input from a file;
the C version has the input hard-coded into the source program.
The entire SAC benchmark executes in about 36msec, and the C
version in 7msec.
One of the benchmarks should be changed, so that they are equivalent.
Until that time, any performance measurements on Loop13 should be considered
bogus.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1072Performance anomaly in Livermore Loops when declarations are used2017-11-19T20:20:27ZRobert BerneckyPerformance anomaly in Livermore Loops when declarations are used| | |
| --- | --- |
| Bugzilla Link | [707](http://bugs.sac-home.org/show_bug.cgi?id=707) |
| Created on | May 11, 2010 18:13 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I've been running per...| | |
| --- | --- |
| Bugzilla Link | [707](http://bugs.sac-home.org/show_bug.cgi?id=707) |
| Created on | May 11, 2010 18:13 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I've been running performance measurements of the Livermore Loops in sac.
When I compiled loop10.sac, I got a gazillion complaints about:
WARNING: Insufficient symbolic shape information available. Using explicit
WARNING: information to split index operation.
Looking at the code, we see in main():
rep = FibreScanInt( stdin );
n = FibreScanInt( stdin );
I looked at n and rep, and noted that they are not declared,
but are passed to the Loop() function, where they are NOT referenced or set.
In the spirit of cleaning things up, I tried some simple tests:
(This is op counts, compiling with AWLF options on rbe's private code.)
Original:
6715137927
n and rep removed from Loop() call:
7905664809 !! WORSE !!
n and rep removed from Loop() call; "int rep; int n;" added to main():
7850187292 slightly better
When compiled with -O3...
Original:
loop10.sac.exe.O3.16831:MODIFIED.papiex.rattler.18553:PAPI_TOT_INS: 965058436
n and rep removed from Loop() call:
loop10.sac.exe.O3.16831:MODIFIED.papiex.rattler.18633:PAPI_TOT_INS: 947804966
n and rep removed from Loop() call; "int rep; int n;" added to main():
loop10.sac.exe.O3.16831:MODIFIED.papiex.rattler.18753:PAPI_TOT_INS: 934451791
I do not understand what's going on here.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1071SelModArray() in CF broken when using -ecc/ -check c (SCCFprf_modarray11.sac)2017-11-19T20:20:24ZRobert BerneckySelModArray() in CF broken when using -ecc/ -check c (SCCFprf_modarray11.sac)| | |
| --- | --- |
| Bugzilla Link | [701](http://bugs.sac-home.org/show_bug.cgi?id=701) |
| Created on | Apr 26, 2010 16:49 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCCFprf_modarray11.sac](/uploads/94...| | |
| --- | --- |
| Bugzilla Link | [701](http://bugs.sac-home.org/show_bug.cgi?id=701) |
| Created on | Apr 26, 2010 16:49 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCCFprf_modarray11.sac](/uploads/94a6d183d8bf629560c0dbeb4a3bb8c3/SCCFprf_modarray11.sac) |
## Extended Description
<pre>Created an attachment (id=689)
source code to reproduce fault
The SelModArray optimization in CF is intended to take this
common set of expressions:
X = idx_modarray_AxVxS_( M, iv, q);
z = idx_sel_VxA( iv, X);
and turn it into:
z = q;
This optimization is of fundamental importance in loop
fusion/array contraction, and WLF/AWLF, because it allows
us to eliminate intermediate array results.
When a function is compiled with -ecc (or -check c), however,
with my local mods to unroll guards, we end up with this sort
of pattern:
lim = ...;
p0... = {earlier guard(s)}
iv = [ i ];
q = 42;
M' = _modarray_AxVxS_( M, iv, q);
X = _afterguard_( M' , p0...);
i' , p1 = _val_lt_val_SxS_( i, lim);
iv' = [ i'];
z' = _sel_VxA_( iv', X);
z = _afterguard_( z', p1);
We want to map this into:
z = _afterguard( q, p0, p1, ...);
There are several problems here:
1. We don't want to lose the afterguards on p0, p1.
In fact, finding the afterguard on z is a bit of
a problem, if we're looking at the z' computation...
2. We have to chase X back to the M' modarray computation,
through the X afterguard.
3. We have to somehow match iv' and iv, through guards.
This is a unit test from CF, which fails reliably in my local code, if
compiled with:
sac2c -docf -extrema -nowlf -doawlf -ecc SCCFprf_modarray11.sac
This with Build #rev 16795:16801:MODIFIED, which I hope to check in
soon, and fix this one later.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1311LS does not support SAA; LACFUN headers result are missing AVIS_SHAPE2017-11-19T20:37:41ZRobert BerneckyLS does not support SAA; LACFUN headers result are missing AVIS_SHAPE| | |
| --- | --- |
| Bugzilla Link | [700](http://bugs.sac-home.org/show_bug.cgi?id=700) |
| Created on | Apr 21, 2010 22:37 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbbAKD.sac](/uploads/13bd5800f1162...| | |
| --- | --- |
| Bugzilla Link | [700](http://bugs.sac-home.org/show_bug.cgi?id=700) |
| Created on | Apr 21, 2010 22:37 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbbAKD.sac](/uploads/13bd5800f116238f77dabc85fff1d815/ipbbAKD.sac) |
## Extended Description
<pre>Created an attachment (id=688)
source code to reproduce fault
In the ongoing battle to kill CYC, we need to extend LS to make it
support SAA. When it moves a value from within a LACFUN to outside it,
it fails to move the AVIS_SHAPE/DIM information for that.
This results in unpleasant failure modes, such as VPid dying.
The attached will fail if compiled with rbe's local sac2c
(the post-Loch Ness fixerupper that is not checked in yet), with these options:
sac2c -ecc -extrema -doawlf -nowlf ipbbAKD.sac
This is partly a place marker so that we remember to do this work.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1227ISAA introduces non-flattened nodes into PRF_ARG positions2017-11-19T20:32:16ZRobert BerneckyISAA introduces non-flattened nodes into PRF_ARG positions| | |
| --- | --- |
| Bugzilla Link | [699](http://bugs.sac-home.org/show_bug.cgi?id=699) |
| Created on | Apr 18, 2010 23:10 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Found by running with...| | |
| --- | --- |
| Bugzilla Link | [699](http://bugs.sac-home.org/show_bug.cgi?id=699) |
| Created on | Apr 18, 2010 23:10 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Found by running with -nocyc and a few other things turned off.
I'm working on it.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1070Eyeballs suggest that LS never traverses LOCALFUNS2017-11-19T20:20:20ZRobert BerneckyEyeballs suggest that LS never traverses LOCALFUNS| | |
| --- | --- |
| Bugzilla Link | [697](http://bugs.sac-home.org/show_bug.cgi?id=697) |
| Created on | Apr 18, 2010 17:05 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
I just noted this while in...| | |
| --- | --- |
| Bugzilla Link | [697](http://bugs.sac-home.org/show_bug.cgi?id=697) |
| Created on | Apr 18, 2010 17:05 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
I just noted this while introducing LS into SAACYC.
I don't have a failing case, but will adjust the code to
do what I think it should do...BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1069-ecc inhibits CF in SCCFprf_modarray5.sac - need to separate shape vector fro...2017-11-19T20:20:17ZRobert Bernecky-ecc inhibits CF in SCCFprf_modarray5.sac - need to separate shape vector from array| | |
| --- | --- |
| Bugzilla Link | [695](http://bugs.sac-home.org/show_bug.cgi?id=695) |
| Created on | Apr 09, 2010 18:06 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCCFprf_modarray5.sac](/uploads/e06...| | |
| --- | --- |
| Bugzilla Link | [695](http://bugs.sac-home.org/show_bug.cgi?id=695) |
| Created on | Apr 09, 2010 18:06 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCCFprf_modarray5.sac](/uploads/e06689128120b58da46bab7039b93066/SCCFprf_modarray5.sac) |
## Extended Description
<pre>Created an attachment (id=686)
source code to reproduce fault
I've made some improvements (I hope) in constant folding when -ecc/-check c
are active. The CF unit test SCCFprf_modarray5.sac is intended to eliminate
a sel/modarray pair of operations. This is of fundamental importance in
operations such as loop fusion/array contraction.
When the attached is compiled ( in my version of code with -ecc:
(rev 16776:16792:MODIFIED)), we end up with this IL:
_flat_1 = true;
_flat_0 = 1;
one = _MAIN::id( _flat_0, _flat_1);
_ivexp_92_is = 0;
_isaa_54_one = _dim_A_( one);
_isaa_55_one = _shape_A_( one);
_isaa_56_one = _saabind_( _isaa_54_one, _isaa_55_one, one);
_idc_38, _icc_27_pred = _type_constraint_( int, _isaa_56_one);
_icc_28 = _add_SxS_( _idc_38, _flat_0);
_flat_2 = _afterguard_( _icc_28, _icc_27_pred);
cltwo = _MAIN::id( _flat_2, _flat_1);
_isaa_57_cltwo = _dim_A_( cltwo);
_isaa_58_cltwo = _shape_A_( cltwo);
_isaa_59_cltwo = _saabind_( _isaa_57_cltwo, _isaa_58_cltwo, cltwo);
_flat_5 = 5;
five = _MAIN::id( _flat_5, _flat_1);
_isaa_60_five = _dim_A_( five);
_isaa_61_five = _shape_A_( five);
_isaa_62_five = _saabind_( _isaa_60_five, _isaa_61_five, five);
_idc_39, _icc_29_pred = _type_constraint_( int, _isaa_62_five);
_flat_7 = [:int];
_idc_40, _icc_30_pred = _shape_matches_dim_VxA_( _flat_7, _isaa_59_cltwo);
_icc_33 = _modarray_AxVxS_( _isaa_59_cltwo, _flat_7, _idc_39);
x3 = _afterguard_( _icc_33, _icc_30_pred, _icc_29_pred);
_idc_44, _icc_34_pred = _shape_matches_dim_VxA_( _flat_7, x3);
_icc_37 = _afterguard_( _idc_39, _icc_30_pred, _icc_29_pred);
z = _afterguard_( _icc_37, _icc_34_pred);
_esd_50 = -5;
z__SSA0_1 = _add_SxS_( z, _esd_50);
return( z__SSA0_1);
Note that the function result does not refer to s3 nor to _icc_33, but they are
still with us, because of the presence of guards.
This suggests to me that we might want to change _shape_matches_dim_VxA_()
into something like this:
temps = _idx_shape_sel_( _flat_7);
tempd = _dim_A_( x3);
..._val_matches_val_SxS_(_flat_7, temps, tempd);
What this would do is to eliminate the need to materialize the value
of x3. With any luck, other optimizations would remove the references
to x3 and _Flat_7, and allow them to be removed from the picture as well.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1068Adding CSE,DCR before ICC breaks ICC2017-11-19T20:20:14ZRobert BerneckyAdding CSE,DCR before ICC breaks ICC| | |
| --- | --- |
| Bugzilla Link | [690](http://bugs.sac-home.org/show_bug.cgi?id=690) |
| Created on | Mar 27, 2010 22:31 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCSprf_drop2.sac](/uploads/94edbad5...| | |
| --- | --- |
| Bugzilla Link | [690](http://bugs.sac-home.org/show_bug.cgi?id=690) |
| Created on | Mar 27, 2010 22:31 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCSprf_drop2.sac](/uploads/94edbad51cace814af14ca3796a88598/SCSprf_drop2.sac) |
## Extended Description
<pre>Created an attachment (id=682)
source code to reproduce fault
I've been tracing a -ecc code problem, and it turns out to be
introduced by a change I made at Rev #16762, to introduce CSE and DCR
immediately before ICC (Phase 9), to eliminate a problem described
in Bug #679.
What happens (Rev #16762 onwards) is that ICC stutters. We get code like this
coming out of -b9:icc:
_idc_68, _icc_44_pred = _val_le_val_VxV_( _idc_66, _idc_67);
_idc_69, _icc_50_pred = _non_neg_val_V_( _idc_68);
_idc_70, _icc_54_pred = _non_neg_val_V_( _idc_69);
_idc_71, _icc_58_pred = _non_neg_val_V_( _idc_70);
This is more or less harmless, but not a good thing to have around.
I'll look into it eventually, but not before April Fools' Day, at the
earliest.
sac2c -ecc SCSprf_drop2.sac -b9:icc > crud
will reproduce the fault. More interesting is that compiling with
-noCSE makes the problem disappear.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1261folding of two consecutive set-notations triggers a bug in WLF2017-11-19T20:34:16ZStephan Herhutfolding of two consecutive set-notations triggers a bug in WLF| | |
| --- | --- |
| Bugzilla Link | [689](http://bugs.sac-home.org/show_bug.cgi?id=689) |
| Created on | Mar 26, 2010 10:39 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [bug_tx.sac](/uploads/504439c18e4f6127...| | |
| --- | --- |
| Bugzilla Link | [689](http://bugs.sac-home.org/show_bug.cgi?id=689) |
| Created on | Mar 26, 2010 10:39 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [bug_tx.sac](/uploads/504439c18e4f61278ae2895572612df6/bug_tx.sac) |
## Extended Description
The attached code is an excerpt from a matrix multiplication testcase provided by Michael Bullington at TTU.Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1067overloading with different return types only breaks2017-11-19T20:20:10ZSven-Bodo Scholzoverloading with different return types only breaks| | |
| --- | --- |
| Bugzilla Link | [688](http://bugs.sac-home.org/show_bug.cgi?id=688) |
| Created on | Mar 24, 2010 19:01 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu2.sac](/uploads/7f15ba742300038...| | |
| --- | --- |
| Bugzilla Link | [688](http://bugs.sac-home.org/show_bug.cgi?id=688) |
| Created on | Mar 24, 2010 19:01 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu2.sac](/uploads/7f15ba74230003812f2649b41bde8ae3/tutu2.sac) |
## Extended Description
Created an attachment (id=680)
source code
this may be considered illegal; but if so we should give a proper error message
in the compiler.....BugZillaBugZilla