sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:21:33Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1090-ecc inhibits WLF2017-11-19T20:21:33ZRobert Bernecky-ecc inhibits WLF| | |
| --- | --- |
| Bugzilla Link | [806](http://bugs.sac-home.org/show_bug.cgi?id=806) |
| Created on | Dec 19, 2010 19:34 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This bug probably dat...| | |
| --- | --- |
| Bugzilla Link | [806](http://bugs.sac-home.org/show_bug.cgi?id=806) |
| Created on | Dec 19, 2010 19:34 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This bug probably dates back to the inception of -ecc, but I never
noticed it until today.
:~/sac/testsuite/optimizations/awlf$ sac2c -ecc -bopt prd.sac >crud
If you look at main(), you'll see that the WLs are not folded.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 17228:17239:MODIFIED linux-gnu_x86_64
(Fri Dec 17 15:08:56 EST 2010 by sac)
----------------------------------------
cat prd.sac
/*
* This is a short version of the APEX prd.sac benchmark.
*
*/
/* RESULT: with 1 1 */
use Array: {iota,sum};
int main()
{
XXX = iota(50);
ZZZ = sum(XXX);
z = _sub_SxS_(ZZZ, 1225);
return(z);
}</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1200sac2c cachesim feature2017-11-19T20:29:50ZDávid Juhászsac2c cachesim feature| | |
| --- | --- |
| Bugzilla Link | [808](http://bugs.sac-home.org/show_bug.cgi?id=808) |
| Created on | Jan 04, 2011 16:18 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I tried to use t...| | |
| --- | --- |
| Bugzilla Link | [808](http://bugs.sac-home.org/show_bug.cgi?id=808) |
| Created on | Jan 04, 2011 16:18 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I tried to use the cache simulation feature of the compiler, used options '-cs -csdefaults sagf'. Unfortunately the executable doesn't create any memory trace file.</pre>Clemens GrelckClemens Grelckhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1201Defines with non static values2017-11-19T20:29:53ZRoeland DoumaDefines with non static values| | |
| --- | --- |
| Bugzilla Link | [815](http://bugs.sac-home.org/show_bug.cgi?id=815) |
| Created on | Jan 07, 2011 11:58 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>In sac.h serveral sym...| | |
| --- | --- |
| Bugzilla Link | [815](http://bugs.sac-home.org/show_bug.cgi?id=815) |
| Created on | Jan 07, 2011 11:58 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>In sac.h serveral symbols are not defined statically. Which (on Solaris at least) generates linker warnings.
Warnigns:
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/world/stdio/lib/libStdIOMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/world/stdio/lib/libBinFileMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/world/stdio/lib/libScalarIOMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/world/stdio/lib/libArrayIOMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/world/stdio/lib/libFibreIOMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/world/stdio/lib/libListIOMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/world/stdio/lib/libComplexIOMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/world/stdio/lib/libIOresourcesMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_last_taskend' has differing sizes:
(file a.out.o value=0x4; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libStringArrayMod.so value=0xc);
a.out.o definition taken and updated with larger size
ld: warning: symbol `SAC_MT_act_tasksize' has differing sizes:
(file a.out.o value=0x4; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libStringArrayMod.so value=0xc);
a.out.o definition taken and updated with larger size
ld: warning: symbol `SAC_MT_Task' has differing sizes:
(file a.out.o value=0x80; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libStringArrayMod.so value=0x180);
a.out.o definition taken and updated with larger size
ld: warning: symbol `SAC_MT_Taskcount' has differing sizes:
(file a.out.o value=0x4; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libStringArrayMod.so value=0xc);
a.out.o definition taken and updated with larger size
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libStringArrayMod.so value=0x900);
a.out.o definition taken
ld: warning: symbol `SAC_MT_LAST_Task' has differing sizes:
(file a.out.o value=0x80; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libStringArrayMod.so value=0x180);
a.out.o definition taken and updated with larger size
ld: warning: symbol `SAC_MT_rest_iterations' has differing sizes:
(file a.out.o value=0x4; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libStringArrayMod.so value=0xc);
a.out.o definition taken and updated with larger size
ld: warning: symbol `SAC_MT_TS_Tasklock' has differing sizes:
(file a.out.o value=0x18; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libStringArrayMod.so value=0x48);
a.out.o definition taken
ld: warning: symbol `SAC_MT_TS_Tasklock' has differing sizes:
(file a.out.o value=0x18; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayFormatMod.so value=0x48);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayFormatMod.so value=0x900);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libStructuresMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libBitsMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libComplexMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libListMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_LAST_Task' has differing sizes:
(file a.out.o value=0x180; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libColor8Mod.so value=0x100);
a.out.o definition taken
ld: warning: symbol `SAC_MT_rest_iterations' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libColor8Mod.so value=0x8);
a.out.o definition taken
ld: warning: symbol `SAC_MT_act_tasksize' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libColor8Mod.so value=0x8);
a.out.o definition taken
ld: warning: symbol `SAC_MT_TS_Tasklock' has differing sizes:
(file a.out.o value=0x18; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libColor8Mod.so value=0x30);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libColor8Mod.so value=0x600);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Task' has differing sizes:
(file a.out.o value=0x180; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libColor8Mod.so value=0x100);
a.out.o definition taken
ld: warning: symbol `SAC_MT_last_taskend' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libColor8Mod.so value=0x8);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Taskcount' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libColor8Mod.so value=0x8);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/world/system/lib/libRuntimeErrorMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/world/stdio/lib/libFileMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/world/stdio/lib/libTermFileMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/world/system/lib/libTerminalMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/world/system/lib/libFileSystemMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/modules/numerical/lib/libMathArrayMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libComplexArrayTransformMod.so value=0x600);
a.out.o definition taken
ld: warning: symbol `SAC_MT_last_taskend' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libComplexArrayTransformMod.so value=0x8);
a.out.o definition taken
ld: warning: symbol `SAC_MT_LAST_Task' has differing sizes:
(file a.out.o value=0x180; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libComplexArrayTransformMod.so value=0x100);
a.out.o definition taken
ld: warning: symbol `SAC_MT_TS_Tasklock' has differing sizes:
(file a.out.o value=0x18; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libComplexArrayTransformMod.so value=0x30);
a.out.o definition taken
ld: warning: symbol `SAC_MT_act_tasksize' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libComplexArrayTransformMod.so value=0x8);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Task' has differing sizes:
(file a.out.o value=0x180; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libComplexArrayTransformMod.so value=0x100);
a.out.o definition taken
ld: warning: symbol `SAC_MT_rest_iterations' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libComplexArrayTransformMod.so value=0x8);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Taskcount' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libComplexArrayTransformMod.so value=0x8);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libComplexArrayArithMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_LAST_Task' has differing sizes:
(file a.out.o value=0x180; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayTransformMod.so value=0x100);
a.out.o definition taken
ld: warning: symbol `SAC_MT_TS_Tasklock' has differing sizes:
(file a.out.o value=0x18; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayTransformMod.so value=0x30);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Taskcount' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayTransformMod.so value=0x8);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Task' has differing sizes:
(file a.out.o value=0x180; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayTransformMod.so value=0x100);
a.out.o definition taken
ld: warning: symbol `SAC_MT_last_taskend' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayTransformMod.so value=0x8);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayTransformMod.so value=0x600);
a.out.o definition taken
ld: warning: symbol `SAC_MT_act_tasksize' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayTransformMod.so value=0x8);
a.out.o definition taken
ld: warning: symbol `SAC_MT_rest_iterations' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayTransformMod.so value=0x8);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/world/system/lib/libSysErrMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/world/system/lib/libWorldMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_act_tasksize' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libStringMod.so value=0x4);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Taskcount' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libStringMod.so value=0x4);
a.out.o definition taken
ld: warning: symbol `SAC_MT_rest_iterations' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libStringMod.so value=0x4);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Task' has differing sizes:
(file a.out.o value=0x180; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libStringMod.so value=0x80);
a.out.o definition taken
ld: warning: symbol `SAC_MT_LAST_Task' has differing sizes:
(file a.out.o value=0x180; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libStringMod.so value=0x80);
a.out.o definition taken
ld: warning: symbol `SAC_MT_last_taskend' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libStringMod.so value=0x4);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libConstantsMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_LAST_Task' has differing sizes:
(file a.out.o value=0x180; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayArithMod.so value=0x80);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Task' has differing sizes:
(file a.out.o value=0x180; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayArithMod.so value=0x80);
a.out.o definition taken
ld: warning: symbol `SAC_MT_last_taskend' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayArithMod.so value=0x4);
a.out.o definition taken
ld: warning: symbol `SAC_MT_rest_iterations' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayArithMod.so value=0x4);
a.out.o definition taken
ld: warning: symbol `SAC_MT_act_tasksize' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayArithMod.so value=0x4);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Taskcount' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayArithMod.so value=0x4);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libComplexScalarArithMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libComplexArrayBasicsMod.so value=0x900);
a.out.o definition taken
ld: warning: symbol `SAC_MT_TS_Tasklock' has differing sizes:
(file a.out.o value=0x18; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libComplexArrayBasicsMod.so value=0x48);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libComplexBasicsMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libBoolMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libCharMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Task' has differing sizes:
(file a.out.o value=0x180; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayBasicsMod.so value=0x80);
a.out.o definition taken
ld: warning: symbol `SAC_MT_LAST_Task' has differing sizes:
(file a.out.o value=0x180; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayBasicsMod.so value=0x80);
a.out.o definition taken
ld: warning: symbol `SAC_MT_rest_iterations' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayBasicsMod.so value=0x4);
a.out.o definition taken
ld: warning: symbol `SAC_MT_last_taskend' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayBasicsMod.so value=0x4);
a.out.o definition taken
ld: warning: symbol `SAC_MT_act_tasksize' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayBasicsMod.so value=0x4);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Taskcount' has differing sizes:
(file a.out.o value=0xc; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libArrayBasicsMod.so value=0x4);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/modules/numerical/lib/libMathMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_MT_Tasklock' has differing sizes:
(file a.out.o value=0x300; file /scratch/rdouma/suncc//stdlib/modules/structures/lib/libScalarArithMod.so value=0x18);
a.out.o definition taken
ld: warning: symbol `SAC_HM_arenas' has differing sizes:
(file a.out.o value=0x8400; file /scratch/rdouma/suncc//sac2c//lib//libsac.mt.pth.so value=0x420);
a.out.o definition taken</pre>Clemens GrelckClemens Grelckhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2187stdlib won't compile with the SUN compiler2017-11-19T22:05:51ZRoeland Doumastdlib won't compile with the SUN compiler| | |
| --- | --- |
| Bugzilla Link | [816](http://bugs.sac-home.org/show_bug.cgi?id=816) |
| Created on | Jan 07, 2011 12:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
This is a tracker bug to a...| | |
| --- | --- |
| Bugzilla Link | [816](http://bugs.sac-home.org/show_bug.cgi?id=816) |
| Created on | Jan 07, 2011 12:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
This is a tracker bug to allow compilation of the stdlib with suncc.Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2189compiler crashed - WLF bug when folding across different frame-shapes2017-11-23T23:23:19ZNilesh Karavadaracompiler crashed - WLF bug when folding across different frame-shapes| | |
| --- | --- |
| Bugzilla Link | [820](http://bugs.sac-home.org/show_bug.cgi?id=820) |
| Created on | Jan 25, 2011 09:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [slice.sacbugreport](/uploads/324848...| | |
| --- | --- |
| Bugzilla Link | [820](http://bugs.sac-home.org/show_bug.cgi?id=820) |
| Created on | Jan 25, 2011 09:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [slice.sacbugreport](/uploads/3248489b063509ead2c7838faf3ac4ea/slice.sacbugreport), [bug820.sac](/uploads/60bf77a4d8f8a49dacff819415632f22/bug820.sac) |
## Extended Description
<pre>Created an attachment (id=792)
Bug Report
/**********************************************************************
*
* SAC bug report: slice.sacbugreport
*
**********************************************************************
*
* Automatically generated on Tue Jan 25 09:19:38 GMT 2011
*
* using sac2c v1.00-beta (Haggis And Apple) rev 17286 for linux-gnu_i686
* built Mon Jan 24 17:32:53 GMT 2011.
* by user nkk on host obelix for linux-gnu.
*
* The compiler was called by
* sac2c -o slice slice.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 slice.sac.
*
**********************************************************************/</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1194PEW removes copy partitions2017-11-19T20:29:31ZCarl JoslinPEW removes copy partitions| | |
| --- | --- |
| Bugzilla Link | [821](http://bugs.sac-home.org/show_bug.cgi?id=821) |
| Created on | Feb 10, 2011 16:22 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
Removing copy partitions i...| | |
| --- | --- |
| Bugzilla Link | [821](http://bugs.sac-home.org/show_bug.cgi?id=821) |
| Created on | Feb 10, 2011 16:22 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
Removing copy partitions is incorrect in some cases for example fft.Carl JoslinCarl Joslinhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1091UTThornInt aka ArrayFormat woes2017-11-19T20:21:38ZRobert BerneckyUTThornInt aka ArrayFormat woes| | |
| --- | --- |
| Bugzilla Link | [822](http://bugs.sac-home.org/show_bug.cgi?id=822) |
| Created on | Feb 10, 2011 16:33 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTThornInt.sac](/uploads/207cc24060...| | |
| --- | --- |
| Bugzilla Link | [822](http://bugs.sac-home.org/show_bug.cgi?id=822) |
| Created on | Feb 10, 2011 16:33 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTThornInt.sac](/uploads/207cc24060fcec2f9a3f202bd7dfe1c2/UTThornInt.sac) |
## Extended Description
<pre>Created an attachment (id=794)
source code to reproduce fault
I just tried compiling apex/UTThornInt/UTThornInt.sac, with:
sac2c v1.00-beta (Haggis And Apple)
product rev 17290:17300:MODIFIED linux-gnu_x86_64
(Wed Feb 9 16:58:44 EST 2011 by sac)
No compiler options.
Compilation time is excessive - 5-10 minutes on a 3.2GHz machine.
Sorry, but I did not time it.
DL takes a long time on several iterations.
Memory footprint grows constantly, but no single optimization
(based on compiling with -v4 and watching system monitor in linux)
seems at fault.
The compile maxes out at about 3.9GB-ish for sac2c, but then
cc1 comes along and drives that up to 5.8GB.
Perhaps some kcachegrind person can look into this and see
if we have a memory leak there? [Not sure what we can do
about the cc1 part, though.]</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1092Sac2c compilation fails on asterix2017-11-19T20:21:42ZNilesh KaravadaraSac2c compilation fails on asterix| | |
| --- | --- |
| Bugzilla Link | [824](http://bugs.sac-home.org/show_bug.cgi?id=824) |
| Created on | Feb 14, 2011 19:27 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>masterrun results for...| | |
| --- | --- |
| Bugzilla Link | [824](http://bugs.sac-home.org/show_bug.cgi?id=824) |
| Created on | Feb 14, 2011 19:27 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>masterrun results for asterix.stca.herts.ac.uk [i686-solaris] started Mon Feb 14 08:45:00 GMT 2011 by dsr
sac2c: Checked out revision 17307.
reported failure, following error seems to be a cause
ERROR: Cannot load shared library '/home/nkk/temp/sac/sac2c/lib/libsac2c.so'... aborting.
The system returned the following error message: ld.so.1: sac2c: fatal: relocation error: file /home/nkk/temp/sac/sac2c/lib/libsac2c.so: symbol CHKMmodule: referenced symbol not found</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1291masterrun dies in SCCFprf_modarray1/2 w/production compiler2017-11-19T20:36:05ZRobert Berneckymasterrun dies in SCCFprf_modarray1/2 w/production compiler| | |
| --- | --- |
| Bugzilla Link | [829](http://bugs.sac-home.org/show_bug.cgi?id=829) |
| Created on | Feb 23, 2011 17:12 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Two CF unit tests hav...| | |
| --- | --- |
| Bugzilla Link | [829](http://bugs.sac-home.org/show_bug.cgi?id=829) |
| Created on | Feb 23, 2011 17:12 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Two CF unit tests have been broken on SOME hosts with the production
compiler, for some time now. This from nkk's masterrun of 2011-02-21 21:45:00:
sac2c: Checked out revision 17323.
stdlib: Checked out revision 1495.
Changed behavior when testsuite_res (product version):
************************************************************
/tmp/MASTERR_NzHmu10213/sac/testsuite/optimizations/constantfolding/SCCFprf_modarray1:
base : > /bin/sh: ./SCCFprf_modarray1: No such file or directory
/tmp/MASTERR_NzHmu10213/sac/testsuite/optimizations/constantfolding/SCCFprf_modarray2:
base : > /bin/sh: ./SCCFprf_modarray2: No such file or directory
/tmp/MASTERR_NzHmu10213/sac/testsuite/unibench/ubgraphtestcase/exportdata:
actual: < /bin/sh: ./exportdata: not found
This does not break on my X86 GCC system, with either production or
development compilers.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1230SCCFprf_reshapeScalar.sac dies w/-doawlf2017-11-19T20:32:26ZRobert BerneckySCCFprf_reshapeScalar.sac dies w/-doawlf| | |
| --- | --- |
| Bugzilla Link | [830](http://bugs.sac-home.org/show_bug.cgi?id=830) |
| Created on | Feb 24, 2011 22:47 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The above CF unit tes...| | |
| --- | --- |
| Bugzilla Link | [830](http://bugs.sac-home.org/show_bug.cgi?id=830) |
| Created on | Feb 24, 2011 22:47 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The above CF unit test dies on version:
sac2c v1.00-beta (Haggis And Apple)
product rev 17333 linux-gnu_x86_64
(Thu Feb 24 17:25:33 EST 2011 by sac)
when compiled with -doawlf -nowlf -ecc -extrema
This will break in the masterrun, I suspect.
It dies in CSE, but the problem lies in
the current, half-implemented AWLFI code
to compute inverse projections of WL indices.
I'll try to work on this while I'm away,
but it's unlikely to get repaired before
the end of next week.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1021fibspawn not very concurrent2017-11-19T20:17:25ZCarl Joslinfibspawn not very concurrent| | |
| --- | --- |
| Bugzilla Link | [832](http://bugs.sac-home.org/show_bug.cgi?id=832) |
| Created on | Mar 10, 2011 22:49 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I have tuned on mss f...| | |
| --- | --- |
| Bugzilla Link | [832](http://bugs.sac-home.org/show_bug.cgi?id=832) |
| Created on | Mar 10, 2011 22:49 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I have tuned on mss for the mutc backend in 17349. However it does not resolve the problem.
On 10/03/11 22:12, Stephan Herhut wrote:
> The propagation of sync through the dataflow should be handled by a
> phase mss (move_sync_statements os similar) written by Aram. I
> basically pick up whatever he generated.
>
> The wrong looking code after PC is intentional. After PC, print uses
> the argtabs to print function invocations. These correspond to what
> the SL spawn will look like. In SL, the spawn aleady receives the
> result variable.
>
> First check whether MSS is actually running. If that does not help,
> ask Aram to fix it. If he cannot, I might try and find some time.
>
> Cheers
> Stephan
>
> On Thu, Mar 10, 2011 at 12:33 PM, Carl A Joslin
> <carl.joslin@joslinfamily.co.uk> wrote:
>> Hi Dan
>>
>> I had a quick look at your fibspawn test benchmark, to get an overview of
>> what the intermediate code looks like with functional parallelism.
>>
>> One thing that jumped out at me is that your program will not make use of
>> many threads as the syncs are right after the spawns:
>>
>> After mt ( a main phase that is not run in this case):
>>
>> _dec_rc_( _pinl_51__flat_183, 1);
>> _pinl_889__emal_653__pinl_52__flat_212 = _alloc_( 1, 0, [:int]);
>> _pinl_882__flat_212 = _fill_( _add_SxS_( i, -1),
>> _pinl_889__emal_653__pinl_52__flat_212);
>> _pinl_886__syn_638 = spawn _MAIN::fibworker( _pinl_882__flat_212) ;
>> n = _sync_( _pinl_886__syn_638);
>> _dec_rc_( _pinl_886__syn_638, 1);
>> _pinl_888__emal_652__pinl_53__flat_212 = _alloc_or_reuse_( 1, 0, [:int],
>> i);
>> _pinl_881__flat_212 = _fill_( _add_SxS_( i, -2),
>> _pinl_888__emal_652__pinl_53__flat_212);
>> _dec_rc_( i, 1);
>> _pinl_887__syn_639 = spawn _MAIN::fibworker( _pinl_881__flat_212) ;
>> m = _sync_( _pinl_887__syn_639);
>> _dec_rc_( _pinl_887__syn_639, 1);
>>
>> After pc right before the code is generated:
>>
>> _dec_rc_( SACp_emal_660__pinl_56__flat_183, 1);
>> SACp_pinl_906__emal_663__pinl_57__flat_212 = _add_SxS_( SACl_i, -1);
>> SACstf__MAIN__fibworker__i( SACl_n,
>> SACp_pinl_906__emal_663__pinl_57__flat_212) ; /* <- out in */
>> SACl_n = _sync_( SACp_pinl_903__syn_640);
>> _dec_rc_( SACp_pinl_903__syn_640, 1);
>> SACp_pinl_905__emal_662__pinl_58__flat_212 = _alloc_or_reuse_( 1, 0,
>> [:int], SACl_i);
>> SACp_pinl_905__emal_662__pinl_58__flat_212 = _add_SxS_( SACl_i, -2);
>> _dec_rc_( SACl_i, 1);
>> SACstf__MAIN__fibworker__i( SACl_m,
>> SACp_pinl_905__emal_662__pinl_58__flat_212) ; /* <- out in */
>> SACl_m = _sync_( SACp_pinl_904__syn_641);
>> _dec_rc_( SACp_pinl_904__syn_641, 1);
>>
>> I do not happened to the spawn keywords or the setting of the sync keywords.
>> I presume that that is just a printing problem.
>>
>> Carl
>>
>
>
></pre>Aram VisserAram Visserhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1195lw3 can not handle with3 in with or with22017-11-19T20:29:34ZCarl Joslinlw3 can not handle with3 in with or with2| | |
| --- | --- |
| Bugzilla Link | [841](http://bugs.sac-home.org/show_bug.cgi?id=841) |
| Created on | Apr 07, 2011 21:04 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
The addShareds function of...| | |
| --- | --- |
| Bugzilla Link | [841](http://bugs.sac-home.org/show_bug.cgi?id=841) |
| Created on | Apr 07, 2011 21:04 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
The addShareds function of lw3 does not traverse into with or with2 as it must not pass the accus in fold versions of them. However this will not work if there is a fold with3 inside the with/with2.Carl JoslinCarl Joslinhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1196mutc local malloc uses malloc2017-11-19T20:29:37ZCarl Joslinmutc local malloc uses malloc| | |
| --- | --- |
| Bugzilla Link | [842](http://bugs.sac-home.org/show_bug.cgi?id=842) |
| Created on | Apr 14, 2011 14:10 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
As there is currently a bu...| | |
| --- | --- |
| Bugzilla Link | [842](http://bugs.sac-home.org/show_bug.cgi?id=842) |
| Created on | Apr 14, 2011 14:10 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
As there is currently a bug in the underlying alloca of sl malloc is used for local allocations. This creates a memory leak.Carl JoslinCarl Joslinhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1026Masterrun failure cannot be reproduced2017-11-19T20:17:42ZJing GuoMasterrun failure cannot be reproduced| | |
| --- | --- |
| Bugzilla Link | [846](http://bugs.sac-home.org/show_bug.cgi?id=846) |
| Created on | Jun 01, 2011 10:57 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The masterrun shows t...| | |
| --- | --- |
| Bugzilla Link | [846](http://bugs.sac-home.org/show_bug.cgi?id=846) |
| Created on | Jun 01, 2011 10:57 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The masterrun shows the following errors:
sac2c: Checked out revision 17411.
stdlib: Checked out revision 1521.
sac: Checked out revision 1478.
/tmp/MASTERR_tXWFB22273/sac/testsuite/optimizations/constantfolding/SCCFprf_modarray1:
base : > /bin/sh: ./SCCFprf_modarray1: No such file or directory
/tmp/MASTERR_tXWFB22273/sac/testsuite/optimizations/constantfolding/SCCFprf_modarray2:
base : > /bin/sh: ./SCCFprf_modarray2: No such file or directory
/tmp/MASTERR_tXWFB22273/sac/testsuite/unibench/ubgraphtestcase/exportdata:
actual: < /bin/sh: ./exportdata: not found
It seems that the errors are caused by the fact that programs SCCFprf_modarray1.sac, SCCFprf_modarray2.sac and exportdata.sac fail to compile. To reproduce the error, I've run the following commands on both my local machine (Ubuntu 9.10 32bit) and clustix (where the masterrun is originally run) with production and development versions of sac2c:
sac2c -O3 -check tb -v0 -DEXCLUDE_ERRORS -o SCCFprf_modarray1 SCCFprf_modarray1.sac
sac2c -O3 -check tb -v0 -DEXCLUDE_ERRORS -o SCCFprf_modarray2 SCCFprf_modarray2.sac
sac2c -O3 -check tb -v0 -DEXCLUDE_ERRORS -o exportdata exportdata.sac
However, all compilations succeed without errors. Therefore, I cannot reproduce the errors on either the local machine or clustix.</pre>Jing GuoJing Guohttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1231UTIndexSet.sac in masterrun2017-11-19T20:32:30ZCarl JoslinUTIndexSet.sac in masterrun| | |
| --- | --- |
| Bugzilla Link | [847](http://bugs.sac-home.org/show_bug.cgi?id=847) |
| Created on | Jun 01, 2011 14:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [847.sac](/uploads/b4d26e97d1dbe52d4...| | |
| --- | --- |
| Bugzilla Link | [847](http://bugs.sac-home.org/show_bug.cgi?id=847) |
| Created on | Jun 01, 2011 14:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [847.sac](/uploads/b4d26e97d1dbe52d4fcd7c17c824b36e/847.sac) |
## Extended Description
UTIndexSet.sac falls over in the masterrun as it tries to read memory where an avis node is expected however the memory at that location is not valid for a node.
I have reduced the bug down, however it is very unperdictable. For example there are 2 dead functions in the reduced version that are needed to trigger the bug.
The bug shows up in variable propergation, so is eather a problem with variable propergation or just before.Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1197Reference counting modes expected to fail when run in parallel should refuse ...2017-11-19T20:29:40ZDaniel RollsReference counting modes expected to fail when run in parallel should refuse to run in parallel| | |
| --- | --- |
| Bugzilla Link | [850](http://bugs.sac-home.org/show_bug.cgi?id=850) |
| Created on | Jul 01, 2011 18:24 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
This is more of a suggeste...| | |
| --- | --- |
| Bugzilla Link | [850](http://bugs.sac-home.org/show_bug.cgi?id=850) |
| Created on | Jul 01, 2011 18:24 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
This is more of a suggested feature than a bug. When somebody selects a referencing counting mode that is not expected to work correctly in parallel and tried to run the program in parallel it would be helpful if the program immediately terminated with an error rather than running and returning nonsense or maybe even running for ever!Carl JoslinCarl Joslinhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1217LIR ineffective in opt cycles2017-11-19T20:31:42ZClemens GrelckLIR ineffective in opt cycles| | |
| --- | --- |
| Bugzilla Link | [860](http://bugs.sac-home.org/show_bug.cgi?id=860) |
| Created on | Aug 21, 2011 09:44 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [lir.sac](/uploads/5c979f5350a7614ca...| | |
| --- | --- |
| Bugzilla Link | [860](http://bugs.sac-home.org/show_bug.cgi?id=860) |
| Created on | Aug 21, 2011 09:44 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [lir.sac](/uploads/5c979f5350a7614ca7e32b76f2166192/lir.sac) |
## Extended Description
<pre>When compiling the unit test testsuite/optimizations/al/lir.sac
AL identifies the loop invariant variables in the first opt cycle
and rearranges the multi-operand expression accordingly.
However, none of the LIRs in the two opt cycles actually removed the
loop invariant expression and, hence, it is identified again and again
by AL. Only the final off-cycle application of LIR does its job. In a
less trivial example that, of course, would be too late for other
optimisations to benefit.
Funny enough, despite the fact that lir and wlir go together (as they
should not) the similar wlir.sac unit test works fine.</pre>Jing GuoJing Guohttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1094TC can't simplify AKV _idxs2offset()2017-11-19T20:21:49ZRobert BerneckyTC can't simplify AKV _idxs2offset()| | |
| --- | --- |
| Bugzilla Link | [868](http://bugs.sac-home.org/show_bug.cgi?id=868) |
| Created on | Sep 02, 2011 18:31 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This isn't really a b...| | |
| --- | --- |
| Bugzilla Link | [868](http://bugs.sac-home.org/show_bug.cgi?id=868) |
| Created on | Sep 02, 2011 18:31 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This isn't really a bug, inasmuch as it's
desired new functionality for TC.
However, the CF unit test here:
cd ~/sac/testsuite/optimizations/constantfolding
UnitTestRunGrep1 SCCFprf_sel4ivecyc.sac
UnitTestRunGrep1 testing: SCCFprf_sel4ivecyc.sac
Greptest: SCCFprf_sel4ivecyc.sac -noewlcf -docf -doawlf failed with 3 hits on phrase "NESTEDSTRUCTCON". Wanted 0 hits
CF is unable to simplify the idx_sel() below, because
_ivesplit_472 is not AKV, although it should be:
_isaa_466_vec = 1;
_ivesplit_473 = [ 3, 2 ];
_iveras_475 = 0;
_ivesplit_472 = _idxs2offset_( _ivesplit_473, _iveras_475, _isaa_466_vec);
_icc_28 = _idx_sel_( _ivesplit_472, NESTEDSTRUCTCON);
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17585:MODIFIED linux-gnu_x86_64
(Thu Sep 1 22:23:35 EDT 2011 by sac)
I looked at ct_prf.c, and it does contain code, likely
produced by yrs trly, for _idxs2offset. However, nowhere in
ct_prf.c is there anything I can find that actually evaluates
primitive expressions like "2+3", to produce an AKV result.
Ah, I am beginning to see a light, perhaps: It looks as if
there may be calls from TC to entries such as those
in constants_struc_ops.c, probably driven by the (also
undocumented) co_fun table entries in prf_info.mac.
Perhaps Mr. TC can either confirm this conjecture,
or provide the correct answer?</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1095mixedIV3part.sac needs -maxoptcyc 11 to converge w/-doawlf2017-11-19T20:21:52ZRobert BerneckymixedIV3part.sac needs -maxoptcyc 11 to converge w/-doawlf| | |
| --- | --- |
| Bugzilla Link | [869](http://bugs.sac-home.org/show_bug.cgi?id=869) |
| Created on | Sep 05, 2011 19:57 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Summary says it all.
...| | |
| --- | --- |
| Bugzilla Link | [869](http://bugs.sac-home.org/show_bug.cgi?id=869) |
| Created on | Sep 05, 2011 19:57 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Summary says it all.
cd ~/sac/testsuite/optimizations/awlf
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17603:MODIFIED linux-gnu_x86_64
This folds to a single WL:
sac2c mixedIV3part.sac -doawlf -nowlf -bopt:saacyc:lof:11 -v1 -maxwlur 1 -maxoptcyc 11
This does not:
sac2c mixedIV3part.sac -doawlf -nowlf -bopt:saacyc:lof:11 -v1 -maxwlur 1 -maxoptcyc 10
This shows up a design problem in AWLF. Or maybe a few of them...
1. CUBSL only cuts a cube once along any dimension, even if more
cuts are clearly needed. In this case, the cwl has bounds ([0] [8]),
but the pwl has bound ([0],[2]), ( [2],[5]), [5],[8]).
2. Several SAACYC opts are required to satisfy AWLF after a cut
has been made.
I am not happy with this, but at least it's not a bug!</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1096Absence of canonical form for N_array elements cripples CWLE2017-11-19T20:21:56ZRobert BerneckyAbsence of canonical form for N_array elements cripples CWLE| | |
| --- | --- |
| Bugzilla Link | [871](http://bugs.sac-home.org/show_bug.cgi?id=871) |
| Created on | Sep 08, 2011 16:41 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/88d79ade60e85fee...| | |
| --- | --- |
| Bugzilla Link | [871](http://bugs.sac-home.org/show_bug.cgi?id=871) |
| Created on | Sep 08, 2011 16:41 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/88d79ade60e85feef950a5f02ea0cb84/crud.sac) |
## Extended Description
<pre>Created an attachment (id=818)
source code to reproduce failure
The attached code fails to remove a copy-WL, when compiled with:
sac2c -bopt crud.sac -v0 -DEXTRA >crud
The -DEXTRA introduces a X= toi(X); which turns into a copy-WL,
because X is already int[.].
This is with Build #rev 17603:MODIFIED, heavily modified by rbe
in CWLE shape comparators.
The problem boils down to this:
One of the criteria that CWLE uses to detect a copy-WL is to
compare the BOUND2 of the consumer-WL with the shape of
the producer (which may be a WL or not...).
In this case, we have:
_flat_0 = 50;
GENERATOR_BOUND2( cwl) = [ _flat_0, siz ];
_flat_1 = [ 50, siz ];
shape(mat) = _flat_1;
This causes PM to fail, because it is unable to compare the
two N_array nodes. Although they are identical in value,
they differ in structure.
The problem appears to be a failure to have a canonical
representation of an N_array, due to different treatment
of AKV elements in an N_array.
PROPOSAL 1: Define and implement a canonical representation
of N_array nodes.
PROPOSAL 2: Within optimization cycles, all N_array
nodes elements will be N_id nodes. I.e., ARRAY_AELEMS are
all flattened.
In the above, _flat_1 would be illegal; we would
expect to see [ _flat_0, siz];
I have several reasons for proposing this behavior:
1. Having a canonical representation ensures that
PM can match N_array nodes easily and reliably.
2. It also ensures that CSE, VP, etc., will work as expected.
3. Within the optimizers, we observe several sorts of operations
on N_array nodes, particularly those that are shape vectors,
generator bounds, etc. These are typified by:
narray1 ++ narray2;
take( [n], narray);
drop( [n], narray);
Having ALL elements as N_id nodes allows these operations,
and similar ones, to act simply and consistently.
In contrast, any representation that attempts to unflatten
array elements, whether in whole or in part, makes a huge
amount of work for the optimizers:
- A change in element type MUST force a review of all of
its references. E.g., if _flat_0 started out as AKS,
[say from _flat_0 = ( 3 - 2)], and became AKV later on,
then SOME piece of code has to unflatten all N_array references
to _flat_0.
- If flattening/unflattening is based on an analysis of all
array elements, rather than independently on each element,
then SOME piece of code must review the N_arrays resulting
from catenate, take, drop, etc.
Having said all this, I note that _flat_1 appears very
early in compilation (by -bewl), and is due to the way the
function was coded...
PROPOSAL 2: With</pre>BugZillaBugZilla