sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:29:31Zhttps://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/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/1192wlsd can not handle MG2017-11-19T20:29:25ZCarl Joslinwlsd can not handle MG| | |
| --- | --- |
| Bugzilla Link | [579](http://bugs.sac-home.org/show_bug.cgi?id=579) |
| Created on | Oct 27, 2009 15:56 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [mg_rotate_sl.sac](/uploads/12c...| | |
| --- | --- |
| Bugzilla Link | [579](http://bugs.sac-home.org/show_bug.cgi?id=579) |
| Created on | Oct 27, 2009 15:56 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [mg_rotate_sl.sac](/uploads/12c823c1961b3fb971d3c6ab53466d25/mg_rotate_sl.sac) |
## Extended Description
<pre>LWSD has problems processing a grid:
ASSERTION FAILED: file 'wltransform/wl_split_dimensions.c', line 2120
neither code nor nextdim?
EXECUTION TERMINATED
Aborted
sac2c v1.00-beta (Buchette d'Anjou)
developer rev 16497 linux-gnu_i686
(Tue Oct 27 13:17:09 GMT 2009 by caj)</pre>Carl JoslinCarl Joslinhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1191WLSD does not upgrade types2017-11-19T20:29:22ZCarl JoslinWLSD does not upgrade types| | |
| --- | --- |
| Bugzilla Link | [558](http://bugs.sac-home.org/show_bug.cgi?id=558) |
| Created on | Aug 28, 2009 12:48 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [fold.sac](/uploads/79a1adf2fd8...| | |
| --- | --- |
| Bugzilla Link | [558](http://bugs.sac-home.org/show_bug.cgi?id=558) |
| Created on | Aug 28, 2009 12:48 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [fold.sac](/uploads/79a1adf2fd8cafe6acb02c9a46201998/fold.sac) |
## Extended Description
<pre>Created an attachment (id=564)
Example code to produce error.
WLSD does not produce the most precise types possible for inner with3s this then affects RW3.
Problem happens when the set of with3s produce an akd but when sub with3s can produce aks.
int[.] _anonymous_2220 { } ;
int[.] res { } ;
res = with3 {
(0 <= _wlsd_2211 < _flat_843 in 1 (IDXS: _wlsd_2212) ) /* (BS: 0) */ {
...
_anonymous_2220 = with3 {
(0 <= _wlsd_2215 < 1 in 1 (IDXS: _wlsd_2216) ) /* (BS: 0) */ {
...
} : _flat_853;
} : ( genarray( [ 1 ] , genarray( [:int] ,_flat_849)));
} : _anonymous_2220;
...
} : ( genarray( [ _flat_842 ] , genarray( [:int] ,_flat_849)));
In the above example _anonymous_2220 should be [1] not [.]. This seems to stem from the type of _anonymous_2220 coming from res and not the with3 that it is defined from.</pre>Carl JoslinCarl Joslinhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1187User requested specializations don't work on functions behind object wrappers2017-11-19T20:29:00ZHeinz WiesingerUser requested specializations don't work on functions behind object wrappers| | |
| --- | --- |
| Bugzilla Link | [1180](http://bugs.sac-home.org/show_bug.cgi?id=1180) |
| Created on | May 17, 2016 17:43 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>A user can request ...| | |
| --- | --- |
| Bugzilla Link | [1180](http://bugs.sac-home.org/show_bug.cgi?id=1180) |
| Created on | May 17, 2016 17:43 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>A user can request a function to be specialized for certain input data by using the specialize directive:
specialize double[100,100,100] foo (double[100,100,100] A);
This would instruct sac2c to create a specialized version of the function foo() that gets a 100x100x100 array as input.
For "simple" functions this works fine, but when you use modules from stdlib inside foo(), the objects holding the functions used are being passed as hidden arguments to the function foo(), in front of the declared arguments. So if for example you'd user timers to measure the execution duration of something inside foo(), the function signature would internally be rewritten to look like this:
RTClock::RTClock double[100,100,100] foo( RTClock::RTClock _rso_11_TheRTClock { ,NN }, double[100,100,100] A { ,NN })
If foo() is declared within the module the specialize directive is in, this too works just fine.
However, if foo() is imported, sac2c generates an object wrapper around it (ptc:gon). This happens before we generate specializations (tc:esp). As a consequence, when trying to determine the best function to use for generating the specialization (at least I believe that is what TYdispatchFunType() does) we pick the generated object wrapper instead of the real foo(), and subsequently generate a specialization of that object wrapper, which is pretty useless and definitely not what the user intended.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1186sac2c cannot compile files with escaped characters2017-11-19T20:28:58ZSven-Bodo Scholzsac2c cannot compile files with escaped characters| | |
| --- | --- |
| Bugzilla Link | [1177](http://bugs.sac-home.org/show_bug.cgi?id=1177) |
| Created on | Mar 11, 2016 17:45 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
The compiler breaks when p...| | |
| --- | --- |
| Bugzilla Link | [1177](http://bugs.sac-home.org/show_bug.cgi?id=1177) |
| Created on | Mar 11, 2016 17:45 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
The compiler breaks when passing the filename to the C compilerBugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1185inlining of functions with reference parameters considered harmful2017-11-19T20:28:55ZHans-Nikolai Viessmanninlining of functions with reference parameters considered harmful| | |
| --- | --- |
| Bugzilla Link | [1172](http://bugs.sac-home.org/show_bug.cgi?id=1172) |
| Created on | Nov 05, 2015 18:58 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [Indent.sacbugreport](/uploads/f41...| | |
| --- | --- |
| Bugzilla Link | [1172](http://bugs.sac-home.org/show_bug.cgi?id=1172) |
| Created on | Nov 05, 2015 18:58 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [Indent.sacbugreport](/uploads/f41b9419ec00bffeaa3af72569c2d9b0/Indent.sacbugreport), [Indent.sac](/uploads/9630567e6d0c03de2fd018c49190f2ba/Indent.sac) |
## Extended Description
<pre>Created an attachment (id=1047)
Source code
Inlining the function in the attached source code (except from the Indent class within the stdlib) causes the compiler to crash at the code generations phase. Breaking before that phases doesn't seem to reveal much. Any ideas? Could it be related to bug http://bugs.sac-home.org/show_bug.cgi?id=986 ?</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1184Uninitialized field "appendelse" in SSA transformation2017-11-19T20:28:51ZRaphael 'kena' PossUninitialized field "appendelse" in SSA transformation| | |
| --- | --- |
| Bugzilla Link | [1171](http://bugs.sac-home.org/show_bug.cgi?id=1171) |
| Created on | Nov 05, 2015 17:23 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>Detected by valgrind:...| | |
| --- | --- |
| Bugzilla Link | [1171](http://bugs.sac-home.org/show_bug.cgi?id=1171) |
| Created on | Nov 05, 2015 17:23 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>Detected by valgrind:
==46755== Conditional jump or move depends on uninitialised value(s)
==46755== at 0x68459D3: USSATassign (UndoSSATransform.c:312)
==46755== by 0x66D72CB: TRAVdo (traverse.c:94)
==46755== by 0x6845955: USSATassign (UndoSSATransform.c:300)
==46755== by 0x66D72CB: TRAVdo (traverse.c:94)
==46755== by 0x6845955: USSATassign (UndoSSATransform.c:300)
==46755== by 0x66D72CB: TRAVdo (traverse.c:94)
==46755== by 0x66D7617: TRAVopt (traverse.c:152)
==46755== by 0x6845254: USSATblock (UndoSSATransform.c:167)
==46755== by 0x66D72CB: TRAVdo (traverse.c:94)
==46755== by 0x68450C9: USSATfundef (UndoSSATransform.c:139)
==46755== by 0x66D72CB: TRAVdo (traverse.c:94)
==46755== by 0x6845195: USSATfundef (UndoSSATransform.c:147)
The offending code:
/******************************************************************************
*
* function:
* node* USSATassign(node *arg_node, info *arg_info)
*
* description:
* traverses instruction and removes tagged assignments.
*
******************************************************************************/
node *USSATassign(node *arg_node, info *arg_info)
{
...
if ( ( INFO_APPENDELSE( arg_info))) { // <--- HERE, appendelse uninitialized
arg_node = TCappendAssign( INFO_ELSEASS( arg_info), arg_node);
INFO_ELSEASS( arg_info) = NULL;
INFO_APPENDELSE( arg_info) = FALSE;
}</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1183There is no way to resolve relative paths in linkobj's pragma unless one cd i...2017-11-19T20:28:48ZArtem ShinkarovThere is no way to resolve relative paths in linkobj's pragma unless one cd into the source tree| | |
| --- | --- |
| Bugzilla Link | [1170](http://bugs.sac-home.org/show_bug.cgi?id=1170) |
| Created on | Nov 04, 2015 14:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The output for Raph...| | |
| --- | --- |
| Bugzilla Link | [1170](http://bugs.sac-home.org/show_bug.cgi?id=1170) |
| Created on | Nov 04, 2015 14:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The output for Raphael:
gcc: error: src/test.o: No such file or directory
abort: System failed to execute shell command
abort: gcc -std=gnu99 /tmp/SAC_N1B09J/fun1.o /tmp/SAC_N1B09J/globals.o src/test.o
abort: -Ltest
abort: -L/usr/local/lib/sac2c/1.2.beta-BlackForest-54-8d30-dirty/modlibs/host/seq
Source tree:
test
├── main.sac
├── mod.sac
└── src
├── test.c
└── test.o
test.c:
int SACfoo (int a)
{
return a + 1;
}
mod.sac:
module mod;
export all;
external int foo (int x);
#pragma linkname "SACfoo"
#pragma linksign [0,1]
#pragma linkobj "src/test.o"
A call from test's parent directory:
sac2c test/mod.sac -Xl -Ltest</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1182MT performance lacking2017-11-19T20:28:45ZSven-Bodo ScholzMT performance lacking| | |
| --- | --- |
| Bugzilla Link | [1166](http://bugs.sac-home.org/show_bug.cgi?id=1166) |
| Created on | Oct 07, 2015 15:23 |
| Version | svn |
| OS | All |
| Architecture | All |
| Attachments | [tutu.sac](/uploads/0b405ae329ee26a...| | |
| --- | --- |
| Bugzilla Link | [1166](http://bugs.sac-home.org/show_bug.cgi?id=1166) |
| Created on | Oct 07, 2015 15:23 |
| Version | svn |
| OS | All |
| Architecture | All |
| Attachments | [tutu.sac](/uploads/0b405ae329ee26a341cb6646b8185c66/tutu.sac) |
## Extended Description
<pre>Created an attachment (id=1043)
source code used
When compiling the attached code with sac2c 1.2.beta-BlackForest-41-7dc65 (sac2c-follow branch)
I find two problems:
1) sequential execution is twice as fast as mt execution with one thread
2) scaling is virtually non existant
Here the exact data on a 24 core Intel Intel(R) Xeon(R) CPU X5650 @ 2.67GHz:
Sequential time:
-bash-4.1$ sac2c tutu3.sac
-bash-4.1$ /usr/bin/time ./a.out
1.04user 0.00system 0:01.07elapsed 96%CPU (0avgtext+0avgdata 1504maxresident)k
1504inputs+0outputs (0major+422minor)pagefaults 0swaps
=> 1.07 sec
Parallel times:
-bash-4.1$ sac2c -tmt_pth tutu3.sac
-bash-4.1$ /usr/bin/time ./a.out -mt 1
2.83user 0.00system 0:02.93elapsed 96%CPU (0avgtext+0avgdata 3296maxresident)k
3344inputs+0outputs (3major+363minor)pagefaults 0swaps
=> 2.93 secs
-bash-4.1$ /usr/bin/time ./a.out -mt 2
4.92user 0.19system 0:03.37elapsed 151%CPU (0avgtext+0avgdata 4184maxresident)k
0inputs+0outputs (0major+600minor)pagefaults 0swaps
=> 3.37 secs
-bash-4.1$ /usr/bin/time ./a.out -mt 4
4.16user 0.65system 0:01.52elapsed 316%CPU (0avgtext+0avgdata 5512maxresident)k
0inputs+0outputs (0major+510minor)pagefaults 0swaps
=> 1.52 secs</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1181Circular dependencies between RT libs breaks link on single-pass linkers2017-11-19T20:28:41ZRobert BerneckyCircular dependencies between RT libs breaks link on single-pass linkers| | |
| --- | --- |
| Bugzilla Link | [1165](http://bugs.sac-home.org/show_bug.cgi?id=1165) |
| Created on | Sep 30, 2015 16:00 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I just tried compil...| | |
| --- | --- |
| Bugzilla Link | [1165](http://bugs.sac-home.org/show_bug.cgi?id=1165) |
| Created on | Sep 30, 2015 16:00 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I just tried compiling Bodo's post-Black Forest parallel slowdown
code. It won't even compile under Ubuntu 14.04LTS:
sac2c bodobug.BlackForest.sac -O3 -v1 -tseq
/usr/local/lib/sac2c/1.2.beta-BlackForest-41-7dc65/rt/host/seq/libsac.so: undefined reference to `SAC_DISTMEM_rank'
/usr/local/lib/sac2c/1.2.beta-BlackForest-41-7dc65/rt/host/seq/libsac.so: undefined reference to `SAC_DISTMEM_Abort'
/usr/local/lib/sac2c/1.2.beta-BlackForest-41-7dc65/rt/host/seq/libsac.so: undefined reference to `SAC_DISTMEM_trace_profile_rank'
/usr/local/lib/sac2c/1.2.beta-BlackForest-41-7dc65/rt/host/seq/libsac.so: undefined reference to `SAC_HM_ShowDiagnostics'
collect2: error: ld returned 1 exit status
abort: System failed to execute shell command
abort: gcc -std=gnu99 /tmp/SAC_iw3D7C/a.out.o
abort: -L/usr/local/lib/sac2c/1.2.beta-BlackForest-41-7dc65/modlibs/host/seq
abort: -Wl,-rpath,/usr/local/lib/sac2c/1.2.beta-BlackForest-41-7dc65/modlibs/host/seq
abort: -L/usr/local/lib/sac2c/1.2.beta-BlackForest-41-7dc65/modlibs/host/seq
abort: -Wl,-rpath,/usr/local/lib/sac2c/1.2.beta-BlackForest-41-7dc65/modlibs/host/seq
abort: -L./host/seq -Wl,-rpath,./host/seq
abort: -L/usr/local/lib/sac2c/1.2.beta-BlackForest-41-7dc65/rt/host/seq
abort: -Wl,-rpath,/usr/local/lib/sac2c/1.2.beta-BlackForest-41-7dc65/rt/host/seq
abort: -lArrayMod -lArrayTransformMod -lConstantsMod -lArrayArithMod -lArrayBasicsMod
abort: -lBoolMod -lScalarArithMod -lsacpreludeMod -L/usr/local/dislin
abort: -Wl,-rpath,/usr/local/dislin -L/opt/local/lib -Wl,-rpath,/opt/local/lib -lsacphmc
abort: -lsac -lsacdistmem -lsacphmc -o a.out
abort: with exit code 1
compilation failed while Creating binary code.
This is using an installed sac2c:
sac2c -V
sac2c 1.2.beta-BlackForest-41-7dc65
product
(Wed Sep 30 10:43:27 EDT 2015 by sac)
sac@rattler:~/sac2c$ which sac2c
/usr/local/bin/sac2c</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1180-o oh! Can't find libsac.so if -o is used2017-11-19T20:28:35ZRobert Bernecky-o oh! Can't find libsac.so if -o is used| | |
| --- | --- |
| Bugzilla Link | [1163](http://bugs.sac-home.org/show_bug.cgi?id=1163) |
| Created on | Sep 26, 2015 20:28 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [config.log](/uploads/894da6ce09e2...| | |
| --- | --- |
| Bugzilla Link | [1163](http://bugs.sac-home.org/show_bug.cgi?id=1163) |
| Created on | Sep 26, 2015 20:28 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [config.log](/uploads/894da6ce09e265a2ffd071c43475b2b2/config.log) |
## Extended Description
<pre>I am confused by the behavior of -o in Ubuntu 10.04LTS with the
current sac2c:
sac2c SCSprf_toi.sac -o a.out
a.out; echo $?
a.out: error while loading shared libraries: libsac.so: cannot open shared object file: No such file or directory
127
sac2c SCSprf_toi.sac
a.out; echo $?
0
My naive expectation is that -o merely gives the binary file a different
name. It appears to be doing something else, though...
sac2c -V
sac2c 1.2.beta-BlackForest-35-78466
product
(Sat Sep 26 11:35:29 EDT 2015 by sac)
Here are the diffs from -d cccall:
3c3
< gcc -std=gnu99 -pedantic -fPIC -DPIC -Wall -Wextra -Wstrict-prototypes -Wno-unused-parameter -Wno-unused-but-set-variable -march=native -mtune=native -pedantic -Wall -Wno-unused -fno-builtin -I. -DSAC_TARGET_STRING=\"default_sbi\" -DSAC_MODEXT_STRING=\".so\" -DSAC_TARGET_ENV_STRING=\"host\" -DSAC_SBI_STRING=\"seq\" -DSAC_RC_METHOD=SAC_RCM_local -DSAC_BACKEND_C99 -DSAC_MT_LIB_ -DSAC_MT_MODE=0 -DSAC_DO_RTSPEC=0 -I/usr/local/include/sac2c/1.2.beta-BlackForest-35-78466 -c -o /tmp/SAC_jZ85El/a.out.o ./a.out.c
---
> gcc -std=gnu99 -pedantic -fPIC -DPIC -Wall -Wextra -Wstrict-prototypes -Wno-unused-parameter -Wno-unused-but-set-variable -march=native -mtune=native -pedantic -Wall -Wno-unused -fno-builtin -I. -DSAC_TARGET_STRING=\"default_sbi\" -DSAC_MODEXT_STRING=\".so\" -DSAC_TARGET_ENV_STRING=\"host\" -DSAC_SBI_STRING=\"seq\" -DSAC_RC_METHOD=SAC_RCM_local -DSAC_BACKEND_C99 -DSAC_MT_LIB_ -DSAC_MT_MODE=0 -DSAC_DO_RTSPEC=0 -I/usr/local/include/sac2c/1.2.beta-BlackForest-35-78466 -c -o /tmp/SAC_UtQc4H/crud.exe.o ./crud.exe.c
5c5
< gcc -std=gnu99 /tmp/SAC_jZ85El/a.out.o -L/usr/local/lib/sac2c/1.2.beta-BlackForest-35-78466/modlibs/host/seq -Wl,-rpath,/usr/local/lib/sac2c/1.2.beta-BlackForest-35-78466/modlibs/host/seq -L/usr/local/lib/sac2c/1.2.beta-BlackForest-35-78466/modlibs/host/seq -Wl,-rpath,/usr/local/lib/sac2c/1.2.beta-BlackForest-35-78466/modlibs/host/seq -L./host/seq -Wl,-rpath,./host/seq -L/usr/local/lib/sac2c/1.2.beta-BlackForest-35-78466/rt/host/seq -Wl,-rpath,/usr/local/lib/sac2c/1.2.beta-BlackForest-35-78466/rt/host/seq -lsacpreludeMod -L/usr/local/dislin -Wl,-rpath,/usr/local/dislin -L/opt/local/lib -Wl,-rpath,/opt/local/lib -lsacphmc -lsac -lsacdistmem -lsacphmc -o a.out
---
> gcc -std=gnu99 /tmp/SAC_UtQc4H/crud.exe.o -Lcrud.exe/host/seq -Wl,-rpath,crud.exe/host/seq -L/usr/local/lib/sac2c/1.2.beta-BlackForest-35-78466/modlibs/host/seq -Wl,-rpath,/usr/local/lib/sac2c/1.2.beta-BlackForest-35-78466/modlibs/host/seq -L/usr/local/lib/sac2c/1.2.beta-BlackForest-35-78466/modlibs/host/seq -Wl,-rpath,/usr/local/lib/sac2c/1.2.beta-BlackForest-35-78466/modlibs/host/seq -L./host/seq -Wl,-rpath,./host/seq -L/usr/local/lib/sac2c/1.2.beta-BlackForest-35-78466/rt/host/seq -Wl,-rpath,/usr/local/lib/sac2c/1.2.beta-BlackForest-35-78466/rt/host/seq -lsacpreludeMod -L/usr/local/dislin -Wl,-rpath,/usr/local/dislin -L/opt/local/lib -Wl,-rpath,/opt/local/lib -lsacphmc -lsac -lsacdistmem -lsacphmc -o crud.exe</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1179Runtime error: corrupted / missing heap administration data encountered2017-11-19T20:28:27ZThomas MachtRuntime error: corrupted / missing heap administration data encountered| | |
| --- | --- |
| Bugzilla Link | [1158](http://bugs.sac-home.org/show_bug.cgi?id=1158) |
| Created on | Jun 01, 2015 17:00 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [modarray_reuse.sac](/uploads/5d01...| | |
| --- | --- |
| Bugzilla Link | [1158](http://bugs.sac-home.org/show_bug.cgi?id=1158) |
| Created on | Jun 01, 2015 17:00 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [modarray_reuse.sac](/uploads/5d014ea663a87ca6f9b32627fa7ce978/modarray_reuse.sac) |
## Extended Description
<pre>*** SAC runtime error
*** Corrupted / missing heap administration data encountered upon memory de-allocation in arena 5
when compiling the attached example program with
sac2c -v0 -check hc modarray_reuse.sac
-check Incorporate runtime checks into executable program.
h: Use diagnostic heap manager.
c: Perform conformity checks.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1178WLS corrupts AST if STEP != 12017-11-19T20:28:23ZRobert BerneckyWLS corrupts AST if STEP != 1| | |
| --- | --- |
| Bugzilla Link | [1154](http://bugs.sac-home.org/show_bug.cgi?id=1154) |
| Created on | Apr 18, 2015 21:21 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud2.sac](/uploads/fae4c0c30fe46...| | |
| --- | --- |
| Bugzilla Link | [1154](http://bugs.sac-home.org/show_bug.cgi?id=1154) |
| Created on | Apr 18, 2015 21:21 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud2.sac](/uploads/fae4c0c30fe46108f746b1e1adb633ab/crud2.sac) |
## Extended Description
<pre>Created an attachment (id=1035)
source code to cause failure
This bug can be created several ways. The key seems to be to get WLS
to run in SAACYC, with a non-unit WL_STEP.
This crash relies on extrema being present, allowing the LT function to
be optimized away, after which WLS does its thing (incorrectly).
** 12: Transforming with-loop representation ...
**** Simplifying with-loops ...
**** Transforming with-loop representation ...
Internal compiler error
Assertion "! WLSTRIDE_ISMODIFIED( stride1)" failed at wltransform/wltransform.c:3849 -- stride was modified
Please file a bug at: http://bugs.sac-home.org
sac@rattler:~/sac/testsuite/optimizations/pogorelationals$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18554 linux-gnu_x86_64
(Sat Apr 18 16:02:33 EDT 2015 by sac)
sac@rattler:~/sac/testsuite/optimizations/pogorelationals$ sac2c crud2.sac -v4 -extrema
I can also reproduce it using the pogo/pogorelational unit tests, which
also evaporate the relational. Those tests do not use extrema, so that
lets them out of the picture.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1177-dopra may break on non-convex polyhedra if non-unit STEP2017-11-19T20:28:19ZRobert Bernecky-dopra may break on non-convex polyhedra if non-unit STEP| | |
| --- | --- |
| Bugzilla Link | [1152](http://bugs.sac-home.org/show_bug.cgi?id=1152) |
| Created on | Apr 05, 2015 20:12 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I am just beginning...| | |
| --- | --- |
| Bugzilla Link | [1152](http://bugs.sac-home.org/show_bug.cgi?id=1152) |
| Created on | Apr 05, 2015 20:12 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I am just beginning to learn about this polyhedral stuff, but I think
there may be the potential for at least one more bug in PRA:
PRA calls PolyLib, which apparently only supports convex polyhedra.
As I understand it, an affine expression tree describing a consumerWL
in which the producerWL has non-unit STEP (or maybe if either of
them have non-unit STEP) turns into a non-convex polyhedron, essentially
one with holes through it.
Intersecting the PWL and CWL (or multiple partitions of the same WL)
could erroneously produce an OKAY result, despite the fact that
they are NOT okay.
I do not have a test case to prove this. At present, it is just
a conjecture.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1176CUDA polyhedral binaries are not generated by sac2c make!2017-11-19T20:28:16ZRobert BerneckyCUDA polyhedral binaries are not generated by sac2c make!| | |
| --- | --- |
| Bugzilla Link | [1149](http://bugs.sac-home.org/show_bug.cgi?id=1149) |
| Created on | Mar 10, 2015 18:42 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>You have to go into...| | |
| --- | --- |
| Bugzilla Link | [1149](http://bugs.sac-home.org/show_bug.cgi?id=1149) |
| Created on | Mar 10, 2015 18:42 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>You have to go into the tools/cuda directory, and do the "make" there.
I'm not sure of the proper way to fix this, so am not even going to try.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18531 linux-gnu_x86_64
(Tue Mar 10 14:41:02 EDT 2015 by sac)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1175Missing symbols in product version of libsac.seq.so2017-11-19T20:28:13ZHans-Nikolai ViessmannMissing symbols in product version of libsac.seq.so| | |
| --- | --- |
| Bugzilla Link | [1144](http://bugs.sac-home.org/show_bug.cgi?id=1144) |
| Created on | Nov 20, 2014 17:15 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>## System Details #...| | |
| --- | --- |
| Bugzilla Link | [1144](http://bugs.sac-home.org/show_bug.cgi?id=1144) |
| Created on | Nov 20, 2014 17:15 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>## System Details ##
uname -a - Linux 2.6.32-431.20.3.el6.x86_64
#1 SMP Thu Jun 19 14:01:59 CDT 2014 x86_64 GNU/Linux
distro - Scientific (RedHat) Linux 6.5
## SAC Details ##
revision - 18508 devel
stdlib - compiled as 'MODE=lean make mt'
## Problem ##
I was having problems with a demo (bug 1143) and was looking for the
'SACARGfreeDataInternal' and 'SACARGcopyDataInternal' symbols in
'libsac.seq.so'. I noticed that these are present in the developer
version but not in the product version. Why is this?
## Devel Output ##
000000000000d59f T SACARGfree
000000000000d57e t SACARGfreeDataInternal
000000000000d2ea t SACARGfreeDataT_bool
000000000000d11c t SACARGfreeDataT_byte
000000000000d32c t SACARGfreeDataT_char
000000000000d36e t SACARGfreeDataT_classtype
000000000000d3b0 t SACARGfreeDataT_dots
000000000000d2a8 t SACARGfreeDataT_double
000000000000d434 t SACARGfreeDataT_double_dev
000000000000d4fa t SACARGfreeDataT_double_dist
000000000000d497 t SACARGfreeDataT_double_shmem
000000000000d266 t SACARGfreeDataT_float
000000000000d3f2 t SACARGfreeDataT_float_dev
000000000000d4b8 t SACARGfreeDataT_float_dist
000000000000d455 t SACARGfreeDataT_float_shmem
000000000000d287 t SACARGfreeDataT_floatvec
000000000000d34d t SACARGfreeDataT_hidden
000000000000d15e t SACARGfreeDataT_int
000000000000d413 t SACARGfreeDataT_int_dev
000000000000d4d9 t SACARGfreeDataT_int_dist
000000000000d476 t SACARGfreeDataT_int_shmem
000000000000d17f t SACARGfreeDataT_long
000000000000d2c9 t SACARGfreeDataT_longdbl
000000000000d1a0 t SACARGfreeDataT_longlong
000000000000d55d t SACARGfreeDataT_nothing
000000000000d53c t SACARGfreeDataT_rc
000000000000d13d t SACARGfreeDataT_short
000000000000d30b t SACARGfreeDataT_str
000000000000d51b t SACARGfreeDataT_sync
000000000000d1c1 t SACARGfreeDataT_ubyte
000000000000d203 t SACARGfreeDataT_uint
000000000000d224 t SACARGfreeDataT_ulong
000000000000d245 t SACARGfreeDataT_ulonglong
000000000000d0fb t SACARGfreeDataT_unknown
000000000000d3d1 t SACARGfreeDataT_user
000000000000d1e2 t SACARGfreeDataT_ushort
000000000000d38f t SACARGfreeDataT_void
## Prod Output ##
000000000000b640 T SACARGfree</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1174modarray WL on user defined types and dot notation2017-11-19T20:28:11ZSven-Bodo Scholzmodarray WL on user defined types and dot notation| | |
| --- | --- |
| Bugzilla Link | [1142](http://bugs.sac-home.org/show_bug.cgi?id=1142) |
| Created on | Nov 11, 2014 11:32 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [modarray.sac](/uploads/2c654b529b12...| | |
| --- | --- |
| Bugzilla Link | [1142](http://bugs.sac-home.org/show_bug.cgi?id=1142) |
| Created on | Nov 11, 2014 11:32 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [modarray.sac](/uploads/2c654b529b126bd3b429211d7fdeba93/modarray.sac) |
## Extended Description
<pre>Created an attachment (id=1030)
source code
The code generated for the dot notation in modarray With-Loops goes wrong when used on non-scalar user defined types.
sac2c modarray.sac
error: line 10 in file ./modarray.sac:
error: index variables (shape: int[1]) and generator boundaries (shape: int[2]) must have identical shapes.
compilation failed while Preparing for code optimization.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1173sac2crc information confusing or missing2017-11-19T20:28:07ZRobert Berneckysac2crc information confusing or missing| | |
| --- | --- |
| Bugzilla Link | [1139](http://bugs.sac-home.org/show_bug.cgi?id=1139) |
| Created on | Sep 30, 2014 22:44 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I am trying to make...| | |
| --- | --- |
| Bugzilla Link | [1139](http://bugs.sac-home.org/show_bug.cgi?id=1139) |
| Created on | Sep 30, 2014 22:44 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I am trying to make sac2c use a gcc linker option, but am not
having much luck. Here's what I tried:
sac2c time2code.sac -v1
/usr/local/lib/sac2c/18614/rt/host/seq/libsac.so: undefined reference to `SAC_HM_ShowDiagnostics'
collect2: error: ld returned 1 exit status
abort: System failed to execute shell command
abort: gcc -std=gnu99 /tmp/SAC_0XIPol/a.out.o
abort: -L/usr/local/lib/sac2c/18614/modlibs/host/seq
abort: -Wl,-rpath,/usr/local/lib/sac2c/18614/modlibs/host/seq
abort: -L/usr/local/lib/sac2c/18614/modlibs/host/seq
abort: -Wl,-rpath,/usr/local/lib/sac2c/18614/modlibs/host/seq -L./host/seq
abort: -Wl,-rpath,./host/seq -L/usr/local/lib/sac2c/18614/rt/host/seq
abort: -Wl,-rpath,/usr/local/lib/sac2c/18614/rt/host/seq -lArrayMod
abort: -lArrayTransformMod -lConstantsMod -lArrayArithMod -lArrayBasicsMod -lBoolMod
abort: -lScalarArithMod -lsacpreludeMod -L/usr/local/dislin
abort: -Wl,-rpath,/usr/local/dislin -L/opt/local/lib -Wl,-rpath,/opt/local/lib
abort: -lsacphmc -lsac -lsacphmc -o a.out
abort: with exit code 1
compilation failed while Creating binary code.
This looks like the changed gcc linker behavior, where it no longer
does the "as-needed" inclusion of .so files.
I tried to fix this by creating /home/sac/.sac2crc, as follows:
target add_seq:
CFLAGS += " --Wl,--no-as-needed "
Compiling with this file produces the above result. I.e.,
it looks like the flags are NOT being used in the command line.
I know that the file IS being read, because if I spell the first
line as "xtarget" rather than "target", then the sac2c parser complains.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18614</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1172Ubuntu can't see libArray.so using sac2c-follow2017-11-19T20:28:04ZRobert BerneckyUbuntu can't see libArray.so using sac2c-follow| | |
| --- | --- |
| Bugzilla Link | [1138](http://bugs.sac-home.org/show_bug.cgi?id=1138) |
| Created on | Sep 30, 2014 16:20 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I just recompiled s...| | |
| --- | --- |
| Bugzilla Link | [1138](http://bugs.sac-home.org/show_bug.cgi?id=1138) |
| Created on | Sep 30, 2014 16:20 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I just recompiled sac2c and the stdlib from scratch, under sac2c-follow
on Ubuntu 14.04 LTS.
At this point, I am unable to compile anything that uses the standard
library:
ls /usr/local/libexec/sac2c/18614
comslc ctest libsac2c.so sac2c-p saccc tree
csima libsac2c.d.so sac2c sac2tex sacpolylibisnullintersect
csimt libsac2c.p.so sac2c-d sac4c sacprapolyhedral
sac@rattler:~/sac/testsuite/optimizations/awlf$ sac2c time2code.sac
MT_MODE = 0 in target, forcing -numthreads to 1.
** 1: Loading SAC program ...
**** Locating source code ...
Reading from file "./time2code.sac" ...
**** Running C preprocessor ...
**** Parsing input file ...
abort: Cannot find library `tree/host/libArrayTree.so' for module `Array'
compilation failed while Loading SAC program.
sac@rattler:~/sac/testsuite/optimizations/awlf$ ls /usr/local/libexec/sac2c/18614/tree/host/
libsacpreludeTree.so
I see that there is nothing under tree/host except the sacprelude, so
the abort makes sense.
I looked for some help on the sac-home web site, here:
http://www.sac-home.org/index.php?p=.%2F55_Download%2F41_Installation%2F41_Trouble_Shooting
cat $SAC2CBASE/sac2crc
# Circumvent ubuntu linker problem.
target seq:
CFLAGS += " --Wl,--no-as-needed "
There is an empty .sac2crc in /home/sac.
I am guessing something is wrong with the install of the generated
stdlib.
sudo make install
for the stdlib shows, in part, this:
Making install for target mt_pth
** Note: modules Dislin DislinBars DislinQuick DislinCanvas DislinPage DislinPlot3d DislinSystem disabled due to configuration.
make[3]: Entering directory `/home/sac/sac/BASE/stdlib'
/usr/bin/install -c -d /usr/local/libexec/sac2c/18604/tree/host
/usr/bin/install -c -d /usr/local/lib/sac2c/18604/modlibs/host/mt-pth
sac2c-p -V
sac2c v1.00-beta (Haggis And Apple)
product rev 18614
(Mon Sep 29 16:03:13 EDT 2014 by sac)
sac@rattler:~/sac/testsuite/optimizations/awlf$ sac2c-d -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18614
Eventually, I did a .configure in the stdlib before building
and installing the stdlib. That resolved the above problem,
but things then die in the linker, as noted in an earlier bug report.
This strikes me as something that is going to break a lot
of attempts to work with sac2c. Perhaps the makefile
can be fancied up so that it detects when sac2c has been changed,
and force a rerun of configure, or else abort with a suitable
error message?</pre>BugZillaBugZilla