sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:23:36Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1124val_lt_val guard causes AWLF failure2017-11-19T20:23:36ZRobert Berneckyval_lt_val guard causes AWLF failure| | |
| --- | --- |
| Bugzilla Link | [989](http://bugs.sac-home.org/show_bug.cgi?id=989) |
| Created on | Jul 06, 2012 18:54 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This is a day-0 probl...| | |
| --- | --- |
| Bugzilla Link | [989](http://bugs.sac-home.org/show_bug.cgi?id=989) |
| Created on | Jul 06, 2012 18:54 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This is a day-0 problem with guards, affecting those guards having
two arguments. As an example, this AWLF unit test:
use Array: {iota,sum};
int[*] id(int[*] y)
{
return(y);
}
int main()
{
N = _max_SxS_( 1, id(20));
ZZ = with { ([1] <= iv=[i] <= .)
{ temp = iota( i);
offset = _sub_SxS_( i, 1);
el = _sel_VxA_( [offset], temp);
} : el;
} : genarray( [ N], 42);
ZZZ = sum(ZZ);
z = _sub_SxS_(ZZZ, 213);
return(z);
}
If compiled with:
sac2c ~/sac/testsuite/optimizations/awlf/selInWL.sac -doawlf -nowlf -bopt:uglf
this fails to AWLF the iota() out of existence, because we have, essentially:
offset = i - 1;
p, offset' = val_lt_val( offset, i);
This can not be rewritten a la CTZ, because the guard result must be
PRF_ARG1, so we must not tinker with offset.
We can, however, rewrite it as:
p = offset < i;
offset' = guard( offset, all(p));
I'll put it on my list to write a traversal for this, unless someone
is keen to do it first.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1238-check c defeats WLF and AWLF2017-11-19T20:32:53ZRobert Bernecky-check c defeats WLF and AWLF| | |
| --- | --- |
| Bugzilla Link | [988](http://bugs.sac-home.org/show_bug.cgi?id=988) |
| Created on | Jun 30, 2012 20:48 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The summary says it a...| | |
| --- | --- |
| Bugzilla Link | [988](http://bugs.sac-home.org/show_bug.cgi?id=988) |
| Created on | Jun 30, 2012 20:48 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The summary says it all. WLF is well-known to be broken WRT -ecc and
-check c, but I was not aware that -check c would also break AWLF.
Consider the AWLF unit test prdAKD.sac, which basically does
sum(iota(id(N)). It can be seen here:
int[*] id(int[*] y)
{
return(y);
}
int main()
{
XXX = iota(id (50));
ZZZ = sum(XXX);
z = _sub_SxS_(ZZZ, 1225);
return(z);
}
If we compile it with -doawlf -nowlf -ecc, we get one WL, as desired.
If we compile it with -doawlf -nowlf -check c, we get two WLs, as not
desired.
The problem may be merely inadequate tests in the compiler for
-check c vs. -ecc. At any rate, I'll look into it: I was operating
under the apparently mistaken impression that they were
identical, except that -ecc ripped out the guards after optimization,
and -check c did not.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1205AWLF unit test UTReshape.sac crashes if compiled with -ecc2017-11-19T20:30:07ZRobert BerneckyAWLF unit test UTReshape.sac crashes if compiled with -ecc| | |
| --- | --- |
| Bugzilla Link | [987](http://bugs.sac-home.org/show_bug.cgi?id=987) |
| Created on | Jun 22, 2012 21:57 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>sac2c -V
sac2c v1.00-...| | |
| --- | --- |
| Bugzilla Link | [987](http://bugs.sac-home.org/show_bug.cgi?id=987) |
| Created on | Jun 22, 2012 21:57 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18017:MODIFIED linux-gnu_x86_64
(Fri Jun 22 11:17:42 EDT 2012 by sac)
cd ~/sac/testsuite/optimizations/awlf
sac2c UTReshape.sac -ecc
...
Applying associative law ...
stdopt/associative_law.c:925 Assertion "TYeqTypes( IDS_NTYPE( ids), ID_NTYPE( EXPRS_EXPR( exprs)))" failed!
Bug in guards: result id '_idc_3246' and arg id '_flat_1100' do have different types
This is in main(). Although tripped up by AL, I suspect the problem
occurs much earlier, during IDC. Here is the relevant IL after -b9:
int[3] _idc_3247 { , NN } ;
int[3] _idc_3246 { , NN } ;
bool _icc_3244_pred { , NN } ;
bool _hce_1__SSA0_2 { , NN } ;
bool{0} _hce_1__SSA0_1 { , NN } ;
int[.] _flat_1101 { , NN } ;
int[3]{2,3...} _flat_1100 { , NN } ;
bool[3] _flat_1099 { , NN } ;
bool _hce_1 { , NN } ;
bool[3] _icc_3245 { , NN } ;
if (_flat_1096)
{
_flat_1101 = _shape_A_( arr_b);
_flat_1100 = _shape_A_( arr_a);
_idc_3246, _idc_3247, _icc_3244_pred = _same_shape_AxA_( _flat_1100, _flat_1101);
Note that the type of _idc_3247 is int[3], whereas its corresponding
argument, PRF_ARG2, is int[.]. I think this is what AL is griping about.
I am assigning this to the keeper of IDC and the type checker.</pre>Clemens GrelckClemens Grelckhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1123Type gets lost on inlining2017-11-19T20:23:33ZRobert BerneckyType gets lost on inlining| | |
| --- | --- |
| Bugzilla Link | [986](http://bugs.sac-home.org/show_bug.cgi?id=986) |
| Created on | Jun 20, 2012 21:58 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu2](/uploads/2bdbcd6a2659d5c90da...| | |
| --- | --- |
| Bugzilla Link | [986](http://bugs.sac-home.org/show_bug.cgi?id=986) |
| Created on | Jun 20, 2012 21:58 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu2](/uploads/2bdbcd6a2659d5c90da5e62495be5483/tutu2), [tutu1](/uploads/23427cb23a371fba6afe87ccd738c518/tutu1) |
## Extended Description
<pre>This happens on this code:
ABORT: line 87 file: ipbbAKD.sac
ABORT: Cannot infer type of "n" as it corresponds to "..." return type --
ABORT: missing type declaration
looking at this:
_pinl_3272_junk, n = String::sscanf( _pinl_3271__flat_76, _pinl_3270__flat_78) ;
The relevant source code is:
use CommandLine: all;
use String: {to_string,tochar,sscanf};
#ifdef FIXED
#else //FIXED
inline
#endif // FIXED
int scanme(int n)
{
int z;
junk, z = sscanf(argv(1), "%d");
return(z);
}
int main()
{
n = 4.5;
z = scanme(1);
StdIO::print(z);
return( 0);
}
Compiling with sac2c -DFIXED works OK.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1122LS does not maintain global optimization counter2017-11-19T20:23:29ZRobert BerneckyLS does not maintain global optimization counter| | |
| --- | --- |
| Bugzilla Link | [985](http://bugs.sac-home.org/show_bug.cgi?id=985) |
| Created on | Jun 20, 2012 19:46 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
I just noticed this now.
I...| | |
| --- | --- |
| Bugzilla Link | [985](http://bugs.sac-home.org/show_bug.cgi?id=985) |
| Created on | Jun 20, 2012 19:46 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
I just noticed this now.
I do not plan to fix it, as I am in the process of replacing LS
by LACS.BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1121buildvAKD.sac compiles very slow, due to garbage introduced into AST during m...2017-11-19T20:23:26ZRobert BerneckybuildvAKD.sac compiles very slow, due to garbage introduced into AST during microcycle| | |
| --- | --- |
| Bugzilla Link | [979](http://bugs.sac-home.org/show_bug.cgi?id=979) |
| Created on | Jun 18, 2012 18:41 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [buildvAKD.sac](/uploads/76401133f17...| | |
| --- | --- |
| Bugzilla Link | [979](http://bugs.sac-home.org/show_bug.cgi?id=979) |
| Created on | Jun 18, 2012 18:41 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [buildvAKD.sac](/uploads/76401133f174de47b6919522781ce8dd/buildvAKD.sac) |
## Extended Description
<pre>Created an attachment (id=902)
source code to reproduce fault
As of the latest ( 17920:MODIFIED) update, this
takes a LONG time to compile:
cd apex/buildvAKD
sac2c buildvAKD.sac -doawlf -nowlf -#d,SSE
If you look at the SSE output, you'll see that WLIR and
CSE keep doing the same thing over and over again
in the AWLFI micro-cycle, OR else some other optimization
is introducing garbage that they run into repeatedly.
Here is a sample:
SimplifySymb: SSE: Cycle interation 14: running UESD
SimplifySymb: SSE: Cycle interation 14: running DCR
SimplifySymb: SSE: DLIR= 0, WLIR= 3, INL=0, CSE=2360, TUP=0, CF=0, VP=0, AS=0, AL=0, DL=0
SimplifySymb: SSE: Cycle interation 15 (fun function _dup_7892_buildvXID__Loop_1) begins.
SimplifySymb: SSE: Cycle interation 15: running DLIR
SimplifySymb: SSE: Cycle interation 15: running WLIR
SimplifySymb: SSE: Cycle interation 15: running INL
SimplifySymb: SSE: Cycle interation 15: running ISAA
SimplifySymb: SSE: Cycle interation 15: running CSE
SimplifySymb: SSE: Cycle interation 15: running NTC
SimplifySymb: SSE: Cycle interation 15: running EAT
SimplifySymb: SSE: Cycle interation 15: running EBT
SimplifySymb: SSE: Cycle interation 15: running DFC
SimplifySymb: SSE: Cycle interation 15: running CF
SimplifySymb: SSE: Cycle interation 15: running VP
SimplifySymb: SSE: Cycle interation 15: running ESD
SimplifySymb: SSE: Cycle interation 15: running AS
SimplifySymb: SSE: Cycle interation 15: running CF
SimplifySymb: SSE: Cycle interation 15: running CSE
SimplifySymb: SSE: Cycle interation 15: running AL
SimplifySymb: SSE: Cycle interation 15: running DL
SimplifySymb: SSE: Cycle interation 15: running UESD
SimplifySymb: SSE: Cycle interation 15: running DCR
SimplifySymb: SSE: DLIR= 0, WLIR= 3, INL=0, CSE=2428, TUP=0, CF=0, VP=0, AS=0, AL=0, DL=0
SimplifySymb: SSE: Cycle interation 16 (fun function _dup_7892_buildvXID__Loop_1) begins.
SimplifySymb: SSE: Cycle interation 16: running DLIR
I think this is new since the DevCamp started, so hope</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1120apex UTCompress unit test dies in -bopt:cyc:wls:1 if -dowlsimp2017-11-19T20:23:21ZRobert Berneckyapex UTCompress unit test dies in -bopt:cyc:wls:1 if -dowlsimp| | |
| --- | --- |
| Bugzilla Link | [975](http://bugs.sac-home.org/show_bug.cgi?id=975) |
| Created on | Jun 07, 2012 21:13 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTCompress.sac](/uploads/c2fd69366e...| | |
| --- | --- |
| Bugzilla Link | [975](http://bugs.sac-home.org/show_bug.cgi?id=975) |
| Created on | Jun 07, 2012 21:13 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTCompress.sac](/uploads/c2fd69366e320f192774632f9ace36b6/UTCompress.sac) |
## Extended Description
<pre>Created an attachment (id=898)
source code to reproduce fault
This fails in Build #17873, but likely has been around for a while.
sac2c UTCompress.sac -noctzg -noedfa -nopetl -v4 -noal -nolur -nodlir -nocwle -nowlir -v1 -bopt:cyc:wls:1 >crudtree/traverse.c:67 Assertion "arg_node" failed!
OOOOOOOPS: TRAVdo() called with a NULL node!
The immediate cause of the crash is that WITH_PART is NULL.
Now, we disable WLSIMP and try again:
apex@rattler:~/apex3/benchmks/UTCompress$ sac2c UTCompress.sac -noctzg -noedfa -nopetl -v4 -noal -nolur -nodlir -nocwle -nowlir -v1 -bopt:cyc:wls:1 -nowlsimp >crud
Compiling with -d treecheck -chkfreq 4 did not provide me with any
more enlightenment.
The failure occurs in the first pass of CYC, I am not sure where to point
fingers on this one.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1119apex benchmark crc2AKD.sac runs out of memory2017-11-19T20:23:17ZRobert Berneckyapex benchmark crc2AKD.sac runs out of memory| | |
| --- | --- |
| Bugzilla Link | [974](http://bugs.sac-home.org/show_bug.cgi?id=974) |
| Created on | Jun 07, 2012 19:29 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crc2AKD.sac](/uploads/53dcbe3be23c5...| | |
| --- | --- |
| Bugzilla Link | [974](http://bugs.sac-home.org/show_bug.cgi?id=974) |
| Created on | Jun 07, 2012 19:29 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crc2AKD.sac](/uploads/53dcbe3be23c570bab0b962c012ba11c/crc2AKD.sac) |
## Extended Description
<pre>Created an attachment (id=897)
source code to reproduce fault
This one has been with us for a while (months or more)
I see several problems here:
sac2c -doawlf -nowlf -v4 crc2AKD.sac -#d,SSE,CSE &> crud
1. After we get into SSACYC, and AWLFI, we enter a micro-cycle
in AWLFI, which has this debug output:
CSEfundef: CSE: leaving (fundef) table32XBB
SimplifySymb: SSE: Cycle interation 17: running AL
SimplifySymb: SSE: Cycle interation 17: running DL
SimplifySymb: SSE: Cycle interation 17: running UESD
SimplifySymb: SSE: Cycle interation 17: running DCR
SimplifySymb: SSE: DLIR= 0, WLIR= 0, INL=0, CSE=25, TUP=0, CF=0, VP=0, AS=0, AL=0, DL=0
SimplifySymb: SSE: Cycle interation 18 (fun function table32XBB) begins.
SimplifySymb: SSE: Cycle interation 18: running DLIR
SimplifySymb: SSE: Cycle interation 18: running WLIR
SimplifySymb: SSE: Cycle interation 18: running INL
SimplifySymb: SSE: Cycle interation 18: running ISAA
SimplifySymb: SSE: Cycle interation 18: running CSE
and then, this:
CSEfundef: CSE: leaving (fundef) table32XBB
SimplifySymb: SSE: Cycle interation 18: running AL
SimplifySymb: SSE: Cycle interation 18: running DL
SimplifySymb: SSE: Cycle interation 18: running UESD
SimplifySymb: SSE: Cycle interation 18: running DCR
SimplifySymb: SSE: DLIR= 0, WLIR= 0, INL=0, CSE=25, TUP=0, CF=0, VP=0, AS=0, AL=0, DL=0
SimplifySymb: SSE: Cycle interation 19 (fun function table32XBB) begins.
SimplifySymb: SSE: Cycle interation 19: running DLIR
SimplifySymb: SSE: Cycle interation 19: running WLIR
SimplifySymb: SSE: Cycle interation 19: running INL
SimplifySymb: SSE: Cycle interation 19: running ISAA
SimplifySymb: SSE: Cycle interation 19: running CSE
Note that CSE keeps doing 25 "optimizations", but none of the other
ops claim to have done anything. However, CSE does remove
(different names each time) ESD-generated variables, e.g,.
SetSubstAttr: CSE: substitute ids _esd_117587 with _esd_113978
CSElet: CSE: Common subexpression eliminated for _esd_117587 in line 136
Perhaps the opts in SimplifySymbioticExpression are
poorly chosen, or perhaps their ordering is bad. Here it is, from AWLFI.
Not my macro...
RUNOPT(DLIR, global.optimize.dodlir, countDLIR = global.optcounters.dlir_expr, DLIRdoLoopInvariantRemoval);
RUNOPT(WLIR, global.optimize.dowlir, countWLIR = global.optcounters.wlir_expr, WLIRdoLoopInvariantRemoval);
RUNOPT(INL, global.optimize.doinl, countINL = global.optcounters.inl_fun, INLdoInlining);
RUNOPT(ISAA, global.optimize.dosaa, , ISAAdoInsertShapeVariables);
RUNOPT(CSE, global.optimize.docse, countCSE = global.optcounters.cse_expr, CSEdoCommonSubexpressionElimination);
RUNOPT(NTC, global.optimize.dotup, countTUP = global.optcounters.tup_upgrades, NTCdoNewTypeCheck);
RUNOPT(EAT, global.optimize.dotup, , EATdoEliminateAlphaTypes);
RUNOPT(EBT, global.optimize.dotup, , EBTdoEliminateBottomTypes);
RUNOPT(DFC, TRUE, , DFCdoDispatchFunCalls);
RUNOPT(CF, global.optimize.docf, countCF = global.optcounters.cf_expr, CFdoConstantFolding);
RUNOPT(VP, global.optimize.dovp, countVP = global.optcounters.vp_expr, VPdoVarPropagation);
RUNOPT(ESD, global.optimize.dosde, , ESDdoElimSubDiv);
RUNOPT(AS, global.optimize.doas, countAS = global.optcounters.as_expr, ASdoArithmeticSimplification);
RUNOPT(CF, global.optimize.docf, countCF = global.optcounters.cf_expr, CFdoConstantFolding);
RUNOPT(CSE, global.optimize.docse, , CSEdoCommonSubexpressionElimination);
RUNOPT(AL, global.optimize.doal, countAL = global.optcounters.al_expr, ALdoAssocLawOptimization);
RUNOPT(DL, global.optimize.dodl, countDL = global.optcounters.dl_expr, DLdoDistributiveLawOptimization);
RUNOPT(UESD, global.optimize.dosde, , UESDdoUndoElimSubDiv);
RUNOPT(DCR, global.optimize.dodcr, , DCRdoDeadCodeRemoval);
However, this should just make compiles take longer (maxoptcyc, for
instance...).
2. Memory usage grows as saacyc runs, until we exhaust memory.
I tried running with -d treecheck, and got this:
Applying loop unrolling ...
LUR: -maxlur 3 would unroll loop
-> Running syntax tree checks
tree/check_lib.c:331 Assertion "NULL == AVIS_SSAASSIGN( ARG_AVIS( arg_node))" failed!
Non-NULL AVIS_SSAASSIGN in N_arg node
apex@rattler:~/apex3/benchmks/crc2AKD$ sac2c -doawlf -nowlf -v4 crc2AKD.sac -d treecheck -chkfreq 4 -noctzg -noedfa -nopetl
I do not know if this is the problem or not; I have my doubts, but will
let the keeper of LUR fix this particular bug.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1237PETL assertion failure on condfun within loopfun2017-11-19T20:32:50ZRobert BerneckyPETL assertion failure on condfun within loopfun| | |
| --- | --- |
| Bugzilla Link | [972](http://bugs.sac-home.org/show_bug.cgi?id=972) |
| Created on | Jun 05, 2012 15:40 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [condfunInLoopFLmin.breaks.sac](/upl...| | |
| --- | --- |
| Bugzilla Link | [972](http://bugs.sac-home.org/show_bug.cgi?id=972) |
| Created on | Jun 05, 2012 15:40 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [condfunInLoopFLmin.breaks.sac](/uploads/f086cb19c89349a14567e6db04a5721e/condfunInLoopFLmin.breaks.sac) |
## Extended Description
<pre>Created an attachment (id=896)
source code to reproduce fault
Summary says it all... I'll fix it.
sac2c -v1 condfunInLoopFLmin.breaks.sac -doawlf
WARNING: AWLF is enabled: -ecc enabled.
WARNING: AWLF is enabled: -extrema enabled.
WARNING: AWLF is enabled: -maxoptcyc=20
arrayopt/propagate_extrema_thru_lacfuns.c:541 Assertion "NULL ==
INFO_NEWOUTERAPARGS( arg_info)" failed!
outer apargs wrong
sac@rattler:~/sac/testsuite/optimizations/petl$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17861:17867 linux-gnu_x86_64
(Tue Jun 5 09:00:56 EDT 2012 by sac)
This should only cause trouble if people compile with -doawlf.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1236PETL assertion failure on condfun within loopfun2017-11-19T20:32:46ZRobert BerneckyPETL assertion failure on condfun within loopfun| | |
| --- | --- |
| Bugzilla Link | [971](http://bugs.sac-home.org/show_bug.cgi?id=971) |
| Created on | Jun 05, 2012 15:38 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [condfunInLoopFLmin.breaks.sac](/upl...| | |
| --- | --- |
| Bugzilla Link | [971](http://bugs.sac-home.org/show_bug.cgi?id=971) |
| Created on | Jun 05, 2012 15:38 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [condfunInLoopFLmin.breaks.sac](/uploads/53a06a63a1b24d7112e10c72993d0bf3/condfunInLoopFLmin.breaks.sac) |
## Extended Description
<pre>Created an attachment (id=895)
source code to reproduce fault
Summary says it all... I'll fix it.
sac2c -v1 condfunInLoopFLmin.breaks.sac -doawlf
WARNING: AWLF is enabled: -ecc enabled.
WARNING: AWLF is enabled: -extrema enabled.
WARNING: AWLF is enabled: -maxoptcyc=20
arrayopt/propagate_extrema_thru_lacfuns.c:541 Assertion "NULL == INFO_NEWOUTERAPARGS( arg_info)" failed!
outer apargs wrong
sac@rattler:~/sac/testsuite/optimizations/petl$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17861:17867 linux-gnu_x86_64
(Tue Jun 5 09:00:56 EDT 2012 by sac)</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1027UTmstruct parse error lacks fault isolation info: "illegal shape spec..."2017-11-19T20:17:46ZRobert BerneckyUTmstruct parse error lacks fault isolation info: "illegal shape spec..."| | |
| --- | --- |
| Bugzilla Link | [968](http://bugs.sac-home.org/show_bug.cgi?id=968) |
| Created on | Jun 04, 2012 14:05 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/354a4c02f154f720...| | |
| --- | --- |
| Bugzilla Link | [968](http://bugs.sac-home.org/show_bug.cgi?id=968) |
| Created on | Jun 04, 2012 14:05 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/354a4c02f154f7201f528f8b9b15bcc1/crud.sac) |
## Extended Description
<pre>Created an attachment (id=893)
source code to reproduce fault
**** Parsing input file ...
error: illegal shape specification
ABORT: Failed to construct a syntax tree for `crud.sac'
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17866 linux-gnu_x86_64
(Mon Jun 4 08:50:18 EDT 2012 by sac)
A source code line number would help here.</pre>Artem ShinkarovArtem Shinkarovhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1118Error messages from hell: foldfix stopper value causes confusion2017-11-19T20:23:13ZRobert BerneckyError messages from hell: foldfix stopper value causes confusion| | |
| --- | --- |
| Bugzilla Link | [967](http://bugs.sac-home.org/show_bug.cgi?id=967) |
| Created on | Jun 04, 2012 00:11 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/eaab446cc40e51d3...| | |
| --- | --- |
| Bugzilla Link | [967](http://bugs.sac-home.org/show_bug.cgi?id=967) |
| Created on | Jun 04, 2012 00:11 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/eaab446cc40e51d3947c001f1000af33/crud.sac) |
## Extended Description
<pre>Created an attachment (id=892)
source code to reproduce fault
** 11: Enhancing with-loops ...
**** Introducing explicit accumulators ...
flatten/ExplicitAccumulate.c:252 Assertion "eq_funap != NULL" failed!
sacprelude::eq not found
The problem is here:
inline bool andslXBBQUICKSTOP(bool[.] y)
{ /* First/last axis reduction of vector with quick stop*/
z = with {
(0*shape(y) <= iv < shape(y))
: BtoB(y[iv]);
} : foldfix( andBBB, true, 0);
return(z);
}
The "0" in the foldfix is wrong, but the error message
is not exactly informative.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1265PM not skipping guard when asked to, in2017-11-19T20:34:28ZRobert BerneckyPM not skipping guard when asked to, in| | |
| --- | --- |
| Bugzilla Link | [964](http://bugs.sac-home.org/show_bug.cgi?id=964) |
| Created on | Jun 01, 2012 21:34 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I have this code, and...| | |
| --- | --- |
| Bugzilla Link | [964](http://bugs.sac-home.org/show_bug.cgi?id=964) |
| Created on | Jun 01, 2012 21:34 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I have this code, and I want PM to get me to _pinl_2005_idc_1362:
_pinl_2005__idc_1362 = [ _flat_27, _uprf_2801 ];
...
_pinl_2007__idc_1363, _pinl_2006__icc_1360_pred = _prod_matches_prod_shape_VxA_( _pinl_2005__idc_1362, _pinl_2008__icc_1447);
Here is the pattern used by IVUTisShapesMatch:
pat1 = PMvar( 1, PMAgetNode( &shp), 0);
pat2 = PMvar( 1, PMAisNode( &shp), 0);
z = ( PMmatchFlatSkipExtremaAndGuards( pat1, AVIS_SHAPE( pavis)) &&
PMmatchFlatSkipExtremaAndGuards( pat2, AVIS_SHAPE( cavis)));
AVIS_SHAPE( pavis) points to _pinl_2007__idc_1363.
I expected that the search should skip the guard, and then stop.
However, I set breakpoints at PMMisInGuards, and we never
stop there. Which seems odd to me.
The code in pattern_match_modes.c has a plausible look to it.
Ergo, I are confused.
Compiled on Build #17858 with these options:
sac2c -v1 crud.sac -doawlf -nowlf -bopt:uglf >crud
Here is the offending crud.sac:
use Array:{+,-,sum,prod,toi,genarray,<,iota};
inline int[*] rhoIII(int[.] x, int y)
{ /* Vector reshape scalar to matrix) */
zxrho = prod(toi(x)); /* Result element count */
z = genarray([zxrho], y); /* allocate result */
z = _reshape_VxA_(toi(x),z);
return(z);
}
int[*] id( int[*] y)
{ return(y);
}
int main()
{
siz = id( 50);
mat=rhoIII([ 50,siz],42);
z = sum(mat);
StdIO::print(z);
return(0);
}</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1117EDFA crashes SSAT2017-11-19T20:23:10ZRobert BerneckyEDFA crashes SSAT| | |
| --- | --- |
| Bugzilla Link | [957](http://bugs.sac-home.org/show_bug.cgi?id=957) |
| Created on | May 20, 2012 17:23 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Build #17829 contains...| | |
| --- | --- |
| Bugzilla Link | [957](http://bugs.sac-home.org/show_bug.cgi?id=957) |
| Created on | May 20, 2012 17:23 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Build #17829 contains my latest -doedfa code, which attempts
to eliminate duplicate arguments from LACFUNs.
The generated code for the failing example looks OK to me,
but it does not look OK to SSAT, which crashes in RN_top in
SSATid: (SSATransform.c):
case RN_top:
new_avis = AVIS_SSASTACK_TOP( ID_AVIS( arg_node));
AVIS_SSASTACK_TOP has a pointer of some sort in it, but *AVIS_SSASTACK_TOP
is 57. Homage to Mr. Heinz?
Suggestions welcome.
This should break it:
sac2c -v1 -doedfa -nowlf -doawlf ~/sac/testsuite/optimizations/edfa/bug907BAKD.sac</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1116-d treecheck node set membership tests are wrong2017-11-19T20:23:07ZRobert Bernecky-d treecheck node set membership tests are wrong| | |
| --- | --- |
| Bugzilla Link | [956](http://bugs.sac-home.org/show_bug.cgi?id=956) |
| Created on | May 17, 2012 18:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This code is generate...| | |
| --- | --- |
| Bugzilla Link | [956](http://bugs.sac-home.org/show_bug.cgi?id=956) |
| Created on | May 17, 2012 18:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This code is generated in check.c:
/*
* Attribute check: AVIS_DECL
*/
if( ( FALSE)|| ( TRUE)){
CHKexistAttribute( AVIS_DECL( arg_node), arg_node, "mandatory attribute AVIS_DECL is NULL");
if( AVIS_DECL( arg_node)!= NULL){
if( !(( FALSE)|| ( NODE_TYPE( AVIS_DECL( arg_node))== N_vardec))){
CHKcorrectTypeInsertError(arg_node,"AVIS_DECL hasnt the right type."" It should be: ""N_vardec");
}
}
}
else if( ( FALSE)|| ( TRUE)){
CHKexistAttribute( AVIS_DECL( arg_node), arg_node, "mandatory attribute AVIS_DECL is NULL");
if( AVIS_DECL( arg_node)!= NULL){
if( !(( FALSE)|| ( NODE_TYPE( AVIS_DECL( arg_node))== N_arg))){
CHKcorrectTypeInsertError(arg_node,"AVIS_DECL hasnt the right type."" It should be: ""N_arg");
}
}
}
else {
CHKnotExist( AVIS_DECL( arg_node), arg_node, "attribute AVIS_DECL must be NULL");
The set membership test is incorrect, in that it will report
an error( expected N_vardec) if AVIS_DECL is an N_arg node,</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1115SISI is disabled by default, and crashes if enabled2017-11-19T20:23:03ZRobert BerneckySISI is disabled by default, and crashes if enabled| | |
| --- | --- |
| Bugzilla Link | [954](http://bugs.sac-home.org/show_bug.cgi?id=954) |
| Created on | May 15, 2012 14:22 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I just discovered tha...| | |
| --- | --- |
| Bugzilla Link | [954](http://bugs.sac-home.org/show_bug.cgi?id=954) |
| Created on | May 15, 2012 14:22 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I just discovered that SISI is NOT enabled by default, and
that it crashes (in SISI) if you enable it:
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17818:MODIFIED linux-gnu_x86_64
(Tue May 15 09:02:34 EDT 2012 by sac)
I was going to extend it to simplify LACFUN arguments
by removing duplicate shapes, but that pit has just grown a
bit deeper... Poop.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1114CSE repeats same job, perhaps caused by ESD2017-11-19T20:22:58ZRobert BerneckyCSE repeats same job, perhaps caused by ESD| | |
| --- | --- |
| Bugzilla Link | [953](http://bugs.sac-home.org/show_bug.cgi?id=953) |
| Created on | May 14, 2012 20:03 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>CSE, at least in the ...| | |
| --- | --- |
| Bugzilla Link | [953](http://bugs.sac-home.org/show_bug.cgi?id=953) |
| Created on | May 14, 2012 20:03 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>CSE, at least in the AWLFI micro-cycle, appears to be
repeating the same work over and over again.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17817:MODIFIED linux-gnu_x86_64
(Mon May 14 13:38:24 EDT 2012 by sac)
SimplifySymb: SSE: DLIR= 0, WLIR= 0, INL=0, CSE=25, TUP=0, CF=0, VP=0, AS=0, AL=0, DL=0
SimplifySymb: SSE: Cycle interation 19...
This repeats until we reach maxoptcyc.
If I disable the call to ESD in the cycle, the problem does
not occur.
The fault can be seen with this call:
cd sac/apex/ipape
sac2c ipape.sac -doawlf -nowlf -v4 -#d,SSE</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1113integer overflows: -2 < maxint() is false in sac2017-11-19T20:22:55ZJaroslav Sýkorainteger overflows: -2 < maxint() is false in sac| | |
| --- | --- |
| Bugzilla Link | [951](http://bugs.sac-home.org/show_bug.cgi?id=951) |
| Created on | May 04, 2012 14:29 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [cmp.sac](/uploads/a7b9777eb4762350c...| | |
| --- | --- |
| Bugzilla Link | [951](http://bugs.sac-home.org/show_bug.cgi?id=951) |
| Created on | May 04, 2012 14:29 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [cmp.sac](/uploads/a7b9777eb4762350c42e437f425da2e9/cmp.sac) |
## Extended Description
<pre>Comparing (-2 < maxint()) returns false. See the attached source: it should print [true,true,true], but gives [true,false,false]. Tested on sac2c r17796.
_flat_3 = Constants::maxint() ; // 2147483647
_ctz_77 = _sub_SxS_( -2, _flat_3); // -2-2147483647 overflows to 2147483647
_pinl_48__flat_59 = _lt_SxS_( _ctz_77, 0); // compares 2147483647 < 0, giving false</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1264crash in WLF, triggered by specialized+inline function that fails to inline2017-11-19T20:34:26ZJaroslav Sýkoracrash in WLF, triggered by specialized+inline function that fails to inline| | |
| --- | --- |
| Bugzilla Link | [943](http://bugs.sac-home.org/show_bug.cgi?id=943) |
| Created on | Mar 30, 2012 16:51 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [inline-wlf.tar.gz](/uploads/04eaa78...| | |
| --- | --- |
| Bugzilla Link | [943](http://bugs.sac-home.org/show_bug.cgi?id=943) |
| Created on | Mar 30, 2012 16:51 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [inline-wlf.tar.gz](/uploads/04eaa7843ce4ae0d2941bd40c67d5cd0/inline-wlf.tar.gz) |
## Extended Description
<pre>Created an attachment (id=873)
demo for the bug
Compiler crashes in WLF; disabling WLF (-nowlf) makes it run...
Possibly there is more than one problem here. The shape of x=iota(4) is not inferred to be int[4], it stays simply int[.] (why?). Therefore, cwc:dfc pass cannot inline function 'suma', because it cannot statically match int[.] (from iota) and int[4] (from suma() specialization). Afterwards it crashes in wlf. Interestingly, it works when 'inline' on suma is removed. Perhaps there is a confusion somewhere that a function marked 'inline' is not actually inlined?
Amusingly, when you modify the source code below in *any* *one* of the following ways it works!
* removing inline on function 'suma'
* removing the shape specialization on 'suma', i.e. replacing 'int[SZ]' by 'int[.]'. This enables cwc:dfc to inline the function completely.
* replacing the iota() call with (currently commented out) direct assignment x=[0,1,2,3]; This also enables to inline suma().
/**********************************************************************
*
* SAC bug report: spec-inlined.sacbugreport
*
**********************************************************************
*
* Automatically generated on Fri Mar 30 16:20:45 BST 2012
*
* using sac2c v1.00-beta (Haggis And Apple) rev 17776:MODIFIED for linux-gnu_i686
* built Fri Mar 30 16:09:20 BST 2012.
* by user js308 on host lxjs308 for linux-gnu.
*
* The compiler was called by
* sac2c -o spec-inlined spec-inlined.sac
*
* The compiler crashed in
* phase: opt (Running SAC optimizations)
* sub phase: cyc (Optimization cycle)
* cycle phase: wlf (Applying with-loop folding)
* cycle instance: 1
*
* What follows is the contents of spec-inlined.sac.
*
**********************************************************************/
use Array: all;
use StdIO: all;
#define SZ 4
inline
int suma(int[SZ] x)
{
y = with {
(0*shape(x) <= iv < shape(x)) : x[iv];
} : fold(+, 0);
return y;
}
int main()
{
x = iota(SZ);
// x = [0, 1, 2, 3];
// print(x);
y = suma(x);
print(y);
return 0;
}
/**********************************************************************
*
* End of bug report
*
**********************************************************************/</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2202ArrayFormat show() fails on double scalar/vector (at least)2017-11-23T23:24:29ZRobert BerneckyArrayFormat show() fails on double scalar/vector (at least)| | |
| --- | --- |
| Bugzilla Link | [936](http://bugs.sac-home.org/show_bug.cgi?id=936) |
| Created on | Mar 19, 2012 21:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Array formatting fail...| | |
| --- | --- |
| Bugzilla Link | [936](http://bugs.sac-home.org/show_bug.cgi?id=936) |
| Created on | Mar 19, 2012 21:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Array formatting fails to print double scalars and vectors correctly,
in both show() and format() flavors. This is a long-standing bug.
This function: cat crud.sac
use Array: all;
use StdIO : all;
use ArrayFormat: all;
int main()
{
print(format(42.5));
show( 42.5);
print( 42.5);
show( [42.5]);
return(0);
}
produces this output:
a.out
Dimension: 1
Shape : < 22>
< >
Dimension: 0
Shape : < >
42.5
4
Not even close.</pre>Robert BerneckyRobert Bernecky