sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:28:27Zhttps://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/1277WLSIMP elides type relevant generators without adding type_conv2017-11-19T20:35:12ZSven-Bodo ScholzWLSIMP elides type relevant generators without adding type_conv| | |
| --- | --- |
| Bugzilla Link | [1157](http://bugs.sac-home.org/show_bug.cgi?id=1157) |
| Created on | May 05, 2015 20:47 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [bug1157.wlt.sac](/uploads/61dc5a6fc...| | |
| --- | --- |
| Bugzilla Link | [1157](http://bugs.sac-home.org/show_bug.cgi?id=1157) |
| Created on | May 05, 2015 20:47 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [bug1157.wlt.sac](/uploads/61dc5a6fccded735838391d8df36df11/bug1157.wlt.sac), [bug1157.nostdlib.sac](/uploads/5a81c341e182248e58d4d40e9c41e375/bug1157.nostdlib.sac) |
## Extended Description
<pre>This bug is related to 1147.
Consider the following code:
module crud;
export {g};
int[.] g( int[0] a, int[+] b)
{
res = with {
( [0] <= iv < _shape_A_(a)): _sel_VxA_( iv, a);
} : modarray( b);
return res;
}
Despite being empty, the generator conveys the info that res in fact is a vector (int[.]).
Once the empty generator is elided, this info is gone and the type checker complains that it no longer can infer int[.] but reverts to int[+] instead......
Whenever we elide a generator we need to insert a type assertion, i.e.,
rather than replacing the above with
res = with {} : modarry(b);
we need to replace it by
res' = with {} : modarry(b);
res = type_conv( res', int[.]);</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1210-b option does not accept override2017-11-19T20:30:30ZRobert Bernecky-b option does not accept override| | |
| --- | --- |
| Bugzilla Link | [1156](http://bugs.sac-home.org/show_bug.cgi?id=1156) |
| Created on | May 01, 2015 13:44 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The sac2c unit test...| | |
| --- | --- |
| Bugzilla Link | [1156](http://bugs.sac-home.org/show_bug.cgi?id=1156) |
| Created on | May 01, 2015 13:44 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The sac2c unit test script UnitTestRunGrep1 and UnitTestRunWorks1
are supposed to allow a specific unit test to override the
default compiler breakpoint by specifying their own breakpoint.
Rationale: The default might be -bopt, but a failure in WLT
required me to add my own breakpoint of -bwlt, so the
compiler invocation looks like:
sac2c bugWLT.sac -bopt -bwlt
The -bwlt breakpoint is ignored. It looks like the compiler breaks
at the earliest breakpoint specified, which is a nuisance.
Is this behavior intentional or accidental?</pre>Clemens GrelckClemens Grelckhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1911inlining problem?2017-11-19T21:38:48ZSven-Bodo Scholzinlining problem?| | |
| --- | --- |
| Bugzilla Link | [1155](http://bugs.sac-home.org/show_bug.cgi?id=1155) |
| Created on | Apr 30, 2015 21:20 |
| Resolution | FIXED |
| Resolved on | May 01, 2015 10:05 |
| Version | svn |
| OS | All |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [1155](http://bugs.sac-home.org/show_bug.cgi?id=1155) |
| Created on | Apr 30, 2015 21:20 |
| Resolution | FIXED |
| Resolved on | May 01, 2015 10:05 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [diffn_bug.sac](/uploads/4d1d25712988cbb3d626a13464dcccbd/diffn_bug.sac) |
## Extended Description
<pre>Created an attachment (id=1036)
source code that fails
The attached code leads to wrong sharing when compiled naively (wo flags).
When compiled with -noLUR, it produces the right results.
Expected output:
-----------loop start:
Dimension: 1
Shape : < 1>
< 0 >
Dimension: 1
Shape : < 1>
< 0 >
Dimension: 1
Shape : < 1>
< 0 >
Dimension: 1
Shape : < 1>
< 1 >
-----------loop start:
Dimension: 1
Shape : < 1>
< 0 >
Dimension: 1
Shape : < 1>
< 1 >
Dimension: 1
Shape : < 1>
< 1 >
Dimension: 1
Shape : < 1>
< 2 >
Errorneous output:
-----------loop start:
Dimension: 1
Shape : < 1>
< 0 >
Dimension: 1
Shape : < 1>
< 0 >
Dimension: 1
Shape : < 1>
< 0 >
Dimension: 1
Shape : < 1>
< 1 >
-----------loop start:
Dimension: 1
Shape : < 1>
< 1 >
Dimension: 1
Shape : < 1>
< 1 >
Dimension: 1
Shape : < 1>
< 1 >
Dimension: 1
Shape : < 1>
< 2 ></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/1276stdlib won't compile2021-05-27T12:55:58ZRobert Berneckystdlib won't compile| | |
| --- | --- |
| Bugzilla Link | [1153](http://bugs.sac-home.org/show_bug.cgi?id=1153) |
| Created on | Apr 18, 2015 15:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I encounter the sam...| | |
| --- | --- |
| Bugzilla Link | [1153](http://bugs.sac-home.org/show_bug.cgi?id=1153) |
| Created on | Apr 18, 2015 15:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I encounter the same problem. I use repeated "make -j8" invocations
get the rest of the stdlib to compile to the point where it is usable by sac2c.
The damage happens very early, as can be seen when I tried to fault-isolate the
problem:
sac2c UnibenchCSV.sac -v1 -bptc:rso >crud
Internal compiler error
Assertion "TCcountExprs( exprs) == 1" failed at print/print.c:1136 -- operator application with wrong number of arguments encountered!
This is an area of the compiler that I know nothing about, so my investigation stopped
here. Perhaps Artem will look into it, as it might be a parser problem.
Bob
On 15-04-18 07:01 AM, Heinz Wiesinger wrote:
> Hi all,
>
> I tried to update to sac2c master today, and found that it is unfortunately
> again broken, in the sense that it can't compile stdlib. This is the error I'm
> getting:
>
> cd modules/unibench/; sac2c -v0 -linksetsize 0 -O3 UnibenchInput.sac -o
> /mnt/progs/projects/UvA/sac//stdlib/shared-libs
> Internal compiler error
> Program reached impossible state at arrayopt/lacfun_utilities.c:466 -- Could
> not find relational for predicate
> Please file a bug at: http://bugs.sac-home.org
> make: *** [libUnibenchInputTree.so] Error 1
>
> I can finish compiling as much as possible with "make -k", but eventually I hit
> the same bug in my test application. I would appreciate if someone could take
> a look at this because I have no idea what's going on here.
>
> As a sidenote, is it somehow possible to get continuous integration back for
> sac2c/stdlib? I'm developing on top of a 2 month old sac2c simply because
> everytime I try master it's broken in one way or another.
>
> Grs,
> Heinz
This has been broken for some time now, but it definitely breaks with:
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18553 linux-gnu_x86_64
(Fri Apr 17 16:28:28 EDT 2015 by sac)</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://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/1222LIR fails to lift loop-invariant N_arg used only in GENARRAY_DEFAULT2017-11-19T20:31:59ZRobert BerneckyLIR fails to lift loop-invariant N_arg used only in GENARRAY_DEFAULT| | |
| --- | --- |
| Bugzilla Link | [1151](http://bugs.sac-home.org/show_bug.cgi?id=1151) |
| Created on | Apr 01, 2015 20:57 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [buglur.sac](/uploads/2123cdafa821...| | |
| --- | --- |
| Bugzilla Link | [1151](http://bugs.sac-home.org/show_bug.cgi?id=1151) |
| Created on | Apr 01, 2015 20:57 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [buglur.sac](/uploads/2123cdafa821cd85dc8d4f6c391ff935/buglur.sac) |
## Extended Description
<pre>Created an attachment (id=1034)
source code to cause failure
This failure causes a performance loss in the attached, because LIR fails to detect that a constant LOOPFUN argument is referenced only by
a WL GENARRAY_DEFAULT.
DLIR_WITH was traversing WITH_WITHOP, but it did not look at any
of its sons. I introduced DLIRgenarray, with a TRAVsons, which does
get us to DLIRid, where the offending variable is marked as
AVIS_SSALPIV, but it still does not get removed, so I am missing
something else. I'll check in this change in a day or so, unless
somebody is keen to look at the fault.</pre>Jing GuoJing Guohttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1719scanparse fails on WL, but does not report anything about problem.2017-11-19T21:19:02ZRobert Berneckyscanparse fails on WL, but does not report anything about problem.| | |
| --- | --- |
| Bugzilla Link | [1150](http://bugs.sac-home.org/show_bug.cgi?id=1150) |
| Created on | Mar 24, 2015 19:16 |
| Resolution | FIXED |
| Resolved on | Mar 26, 2015 19:25 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1150](http://bugs.sac-home.org/show_bug.cgi?id=1150) |
| Created on | Mar 24, 2015 19:16 |
| Resolution | FIXED |
| Resolved on | Mar 26, 2015 19:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>sac2c bug.sac
** 1: Loading SAC program ...
**** Locating source code ...
Reading from file "./bug.sac" ...
**** Running C preprocessor ...
**** Parsing input file ...
abort: Failed to construct a syntax tree for `bug.sac'
compilation failed while Loading SAC program.
sac@rattler:~/docs/papers/2015/PLDI2015-Arrays-wlcondo$ cat bug.sac
int main() {
N = 4000000;
a = genarray( [N+1], 2d);
a[N/2] = 500d;
res = a;
res = with {
(. <= [i] <= .) : {
if(i==0) {
el = a[0];
} else {
if(N==i) {
el = A[N];
} else {
el = (a[i-1] + a[i+1])/2.0;
}
}} : el;
} : modarray( a);
z = sum(res);
StdIO::print(z);
return( 0);
}
sac@rattler:~/docs/papers/2015/PLDI2015-Arrays-wlcondo$
sac@rattler:~/docs/papers/2015/PLDI2015-Arrays-wlcondo$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18540 linux-gnu_x86_64
(Mon Mar 23 08:30:07 EDT 2015 by sac)</pre>Artem ShinkarovArtem Shinkarovhttps://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/1910WRCI crashes in isValidIndexHelper if el is N_num.2017-11-19T21:38:42ZRobert BerneckyWRCI crashes in isValidIndexHelper if el is N_num.| | |
| --- | --- |
| Bugzilla Link | [1148](http://bugs.sac-home.org/show_bug.cgi?id=1148) |
| Created on | Mar 10, 2015 16:21 |
| Resolution | FIXED |
| Resolved on | Mar 10, 2015 18:20 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1148](http://bugs.sac-home.org/show_bug.cgi?id=1148) |
| Created on | Mar 10, 2015 16:21 |
| Resolution | FIXED |
| Resolved on | Mar 10, 2015 18:20 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SAACFprf_lt_VxS.sac](/uploads/0895e154fdea08a8f8c19b4425173d8b/SAACFprf_lt_VxS.sac) |
## Extended Description
<pre>Created an attachment (id=1032)
source code to cause failure
:~/sac/testsuite/optimizations/pogorelationals$ sac2c -nopogo -v1 SAACFprf_lt_VxS.sac -nocf -noewlcf -v4 -nopogo
**** Inferencing with-loop reuse candidates ...
Internal compiler error
Assertion "NODE_TYPE( *PATTR_N1(attr)) == N_id" failed at tree/pattern_match_attribs.c:255 -- var in PMAisVar points to a non N_id node
Please file a bug at: http://bugs.sac-home.org
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18530 linux-gnu_x86_64
(Mon Mar 9 17:42:21 EDT 2015 by sac)
This problem occurs when we are doing _idx_sel_( 0, iv), and are
running with -nocf. [Hence, the "minor" nature of the fault.]
The code contains a PM that has PMisVar(), which fails because 0 is not
an N_id.
It also looks like the FREEdoFreeNode(idsid) should be inside the
while loop that creates the N_id used by PM.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1909stdlib build fails in UnibenchInput.sac due to type check failure triggered b...2017-11-19T21:38:36ZRobert Berneckystdlib build fails in UnibenchInput.sac due to type check failure triggered by a bug in copywlelim| | |
| --- | --- |
| Bugzilla Link | [1147](http://bugs.sac-home.org/show_bug.cgi?id=1147) |
| Created on | Feb 22, 2015 19:48 |
| Resolution | FIXED |
| Resolved on | May 05, 2015 23:12 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1147](http://bugs.sac-home.org/show_bug.cgi?id=1147) |
| Created on | Feb 22, 2015 19:48 |
| Resolution | FIXED |
| Resolved on | May 05, 2015 23:12 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>On 15-02-22 09:14 AM, Heinz Wiesinger wrote:
> Hi Robert,
>
> I updated to sac2c master today and found stdlib no longer compiling with
> it. This is the error I'm seeing:
>
> cd modules/unibench/; sac2c -v0 -linksetsize 0 -O3 UnibenchInput.sac -o
> /mnt/progs/projects/UvA/sac//stdlib/shared-libs
> ./ArrayTransform.sac 596 abort: Function ++: Component #0 of inferred
> return type (int[+]) is not within #66813: in [ --, int[.]] le <> ge <>
> compilation failed while Running SAC optimizations.
> make: *** [libUnibenchInputTree.so] Error 82
>
> according to git bisect this was introduced in either
> 5500f14f6f2bae6d106d25f132c786fd02e316ed or
> 91cf5fda16e8edaeb2b0f132a8056e3f7301c3c4, both from you. Can you have a
> look at this please?
>
> Grs,
This problem was, indeed, introduced by my above changes. The exact
cause of the fault remains unknown, but it was triggered by a call
to VP (pvp) that I introduced into SAACYC. [None of the other code
from that commit should be invoked if you don't use -doawlf or -dopwlf.]
It is (relatively) unlikely that VP has a fault, so the problem is more
likely a corruption in the AST that is triggered by that VP, or something
more subtle.
I am checking in a patched version of phase_sac2c.mac to avoid this
failure.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2210stdlib make dies2017-11-23T23:25:07ZRobert Berneckystdlib make dies| | |
| --- | --- |
| Bugzilla Link | [1146](http://bugs.sac-home.org/show_bug.cgi?id=1146) |
| Created on | Feb 18, 2015 20:07 |
| Resolution | FIXED |
| Resolved on | Feb 20, 2015 21:01 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1146](http://bugs.sac-home.org/show_bug.cgi?id=1146) |
| Created on | Feb 18, 2015 20:07 |
| Resolution | FIXED |
| Resolved on | Feb 20, 2015 21:01 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>On Linux, I get this failure when trying to rebuild the stdlib,
after git pull; ./configure; make clean; make:
~/sac/BASE/stdlib$ make
note: modules BMP, SDLisplay and SDL2 were disabled in configure.
note: module Dislin was diabled in configure.
cd modules/structures/; sac2c -v0 -linksetsize 0 -O3 ScalarArith.sac -o /home/sac/sac/BASE/stdlib/shared-libs
cd modules/structures/; sac2c -v0 -linksetsize 0 -O3 ArrayBasics.sac -o /home/sac/sac/BASE/stdlib/shared-libs
/home/sac/sac/BASE/stdlib/shared-libs.c: In function ‘main’:
/home/sac/sac/BASE/stdlib/shared-libs.c:923:3: warning: implicit declaration of function ‘SACf__MAIN__main’ [-Wimplicit-function-declaration]
SAC_INVOKE_MAIN_FUN( SACf__MAIN__main, SAC_ND_ARG_out( (SAC_res, (SCL, (NHD, (NUQ, (INT, (GLO, (NON, (NOT, )))))))), int));
^
/usr/bin/ld: cannot open output file /home/sac/sac/BASE/stdlib/shared-libs: Is a directory
collect2: error: ld returned 1 exit status
abort: System failed to execute shell command
abort: gcc -std=gnu99 -pedantic -Wall -Wno-unused -fno-builtin -march=native -mtune=native -I$SAC2CBASE/include/ -O3
abort: -I$SAC2CBASE/include/ -o /home/sac/sac/BASE/stdlib/shared-libs /home/sac/sac/BASE/stdlib/shared-libs.c -ldl
abort: -pthread -Wl,--no-as-needed -L$SAC2CBASE/lib/ -L/tmp/SAC_mYLJtv -L. -Wl,-rpath,. -L/home/sac/sac2c/lib
abort: -Wl,-rpath,/home/sac/sac2c/lib -L/home/sac/sac/BASE/stdlib/shared-libs
abort: -Wl,-rpath,/home/sac/sac/BASE/stdlib/shared-libs -L. -Wl,-rpath,. -L/usr/local/dislin -Wl,-rpath,/usr/local/dislin
abort: -L/opt/local/lib -Wl,-rpath,/opt/local/lib -lsacphm.seq -lsac.seq -ldl
abort: with exit code 1
compilation failed while Creating binary code.
make: *** [libArrayBasicsTree.so] Error 150
I suspect the failure is some environment variable being set incorrectly,
but am not sure where to go from here.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18521 linux-gnu_x86_64
(Wed Feb 18 10:48:33 EST 2015 by sac)</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1256Corrupted N_assign node after WLSIMP on ipbb.sac2017-11-19T20:33:58ZRobert BerneckyCorrupted N_assign node after WLSIMP on ipbb.sac| | |
| --- | --- |
| Bugzilla Link | [1145](http://bugs.sac-home.org/show_bug.cgi?id=1145) |
| Created on | Feb 18, 2015 19:51 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbb.sac](/uploads/7dd58faf11656e...| | |
| --- | --- |
| Bugzilla Link | [1145](http://bugs.sac-home.org/show_bug.cgi?id=1145) |
| Created on | Feb 18, 2015 19:51 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbb.sac](/uploads/7dd58faf11656ee30e3a36c4d9084aee/ipbb.sac) |
## Extended Description
<pre>Created an attachment (id=1031)
source code to cause failure
[May be related to Bug #487]
This dies in treecheck, after wlsimp runs the first time:
sac2c ipbb.sac -chkfreq 4 -d treecheck
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18521 linux-gnu_x86_64
(Wed Feb 18 10:48:33 EST 2015 by sac)
This failure mode requires the above build, which includes
validation of node type for AVIS_SSAASSIGN nodes.
Earlier builds still fail, but later on, probably in VPid,
due to the above node being corrupted.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/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/2209Demo 'sac_from_c' does not compile2018-11-23T14:46:58ZHans-Nikolai ViessmannDemo 'sac_from_c' does not compile| | |
| --- | --- |
| Bugzilla Link | [1143](http://bugs.sac-home.org/show_bug.cgi?id=1143) |
| Created on | Nov 20, 2014 16:53 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>## System D...| | |
| --- | --- |
| Bugzilla Link | [1143](http://bugs.sac-home.org/show_bug.cgi?id=1143) |
| Created on | Nov 20, 2014 16:53 |
| Version | unspecified |
| 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 ##
Tried to compile the 'sac_from_c' demo application (sac/demos/basics/sac_from_c).
Both the sac2c and sac4c processes completed without error. An error was given
when compiling the C program which links to the SAC C-lib.
## Additional ##
I had to edit the Makefile somewhat due to errors regarding the private heap
manager. The relevant line that I changed is 11; it now reads as:
$(CC) -o $* $*.c `sac4c -nophm Sum -ccflags` `sac4c -nophm Sum -ldflags` -pthread
## Error Message ##
gcc -o summarizer summarizer.c `sac4c -nophm Sum -ccflags` `sac4c -nophm Sum -ldflags` -pthread
./libcwrapper.so: undefined reference to `SACARGcopyDataInternal'
./libcwrapper.so: undefined reference to `SACARGfreeDataInternal'
collect2: error: ld returned 1 exit status
## Steps to Reproduce ##
1. cd sac/demos/basics/sac_from_c/
2. make
## Workaround (why?) ##
I wrapped the Structures::sum function in another function, 'mysum':
module Sum;
import Structures : {sum};
export {mysum};
int[] mysum(int[*] vector)
{
a = sum(vector);
return(a);
}
and changed the relevant line in summarizer.c. Doing this there are no errors
reported and the resulting binary runs.
## Extra ##
The output of 'nm -a libcwrapper.so':
0000000000202398 b .bss
0000000000000000 n .comment
00000000002020c0 d .ctors
0000000000202390 d .data
00000000002020d0 d .dtors
00000000002020e8 d .dynamic
00000000000006e0 r .dynstr
00000000000002a8 r .dynsym
0000000000001fe0 r .eh_frame
0000000000001fa0 r .eh_frame_hdr
0000000000001e58 t .fini
0000000000000a64 r .gnu.version
0000000000000ac0 r .gnu.version_r
0000000000202268 d .got
0000000000202298 d .got.plt
0000000000000158 r .hash
0000000000000e28 t .init
00000000002020e0 d .jcr
0000000000000e40 t .plt
0000000000000ae0 r .rela.dyn
0000000000000b88 r .rela.plt
0000000000001e70 r .rodata
0000000000001010 t .text
U SACARGcopyDataInternal
0000000000001d44 T SACARGcopyDataUdt
U SACARGfreeDataInternal
0000000000001dbc T SACARGfreeDataUdt
U SACARGisDouble
U SACARGisFloat
U SACARGisInt
U SACARGisUdt
U SACARGunwrapDouble
U SACARGunwrapFloat
U SACARGunwrapInt
U SACARGunwrapUdtDouble
U SACARGwrapDouble
U SACARGwrapFloat
U SACARGwrapInt
U SACARGwrapUdtDouble
U SAC_HM_MallocAnyChunk_at
U SAC_HM_MallocAnyChunk_mt
U SAC_HM_MallocAnyChunk_st
0000000000001f20 r SAC_HM_thread_status.2426
U SAC_MT_globally_single
U SAC_RuntimeError
U SAC_RuntimeError_Mult
00000000002023a8 B SAC___CWRAPPER__another_dummy_value_which_is_completely_useless
00000000002023ac B SAC___CWRAPPER__dummy_value_which_is_completely_useless
0000000000001158 T SACcw_Sum__sum1
U SACf_ArrayTransform__sum__d_S
U SACf_ArrayTransform__sum__f_S
U SACf_ArrayTransform__sum__i_S
U SACf_ComplexArrayTransform__sum__SACt_ComplexArrayTransform__complex_S
0000000000001cfd T Sum__sum1
00000000002020e8 a _DYNAMIC
0000000000202298 a _GLOBAL_OFFSET_TABLE_
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
w _Jv_RegisterClasses
00000000002020c8 d __CTOR_END__
00000000002020c0 d __CTOR_LIST__
00000000002020d8 d __DTOR_END__
00000000002020d0 d __DTOR_LIST__
00000000000020b8 r __FRAME_END__
00000000002020e0 d __JCR_END__
00000000002020e0 d __JCR_LIST__
0000000000001f10 r __PRETTY_FUNCTION__.2498
0000000000001f3a r __PRETTY_FUNCTION__.2631
0000000000202398 d __TMC_END__
U __assert_fail@@GLIBC_2.2.5
0000000000202398 A __bss_start
w __cxa_finalize@@GLIBC_2.2.5
0000000000001e20 t __do_global_ctors_aux
00000000000010a0 t __do_global_dtors_aux
0000000000202390 d __dso_handle
w __gmon_start__
0000000000202398 A _edata
00000000002023b0 A _end
0000000000001e58 T _fini
0000000000000e28 T _init
0000000000001010 t call_gmon_start
0000000000202398 b completed.6301
0000000000000000 a crtstuff.c
0000000000000000 a crtstuff.c
0000000000001030 t deregister_tm_clones
00000000002023a0 b dtor_idx.6303
0000000000001120 t frame_dummy
U free@@GLIBC_2.2.5
0000000000001c8f t freeScalarDesc
0000000000000000 a fun1.c
0000000000000000 a fundummy.c
0000000000000000 a globals.c
0000000000000000 a interface.c
0000000000001c18 t makeScalarDesc
U malloc@@GLIBC_2.2.5
0000000000001060 t register_tm_clones
0000000000000000 a sacargcopy.c
0000000000000000 a sacargfree.c
The output of 'nm -a libsac.seq.so | fgrep SACARGfree':
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
Output of 'nm -a libsac.seq.so | fgrep SACARGcopy':
000000000000e0bc T SACARGcopy
U SACARGcopyDataUdt</pre>Hans-Nikolai ViessmannHans-Nikolai Viessmannhttps://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/12872D array assignment in for loops2021-09-06T19:43:52ZRobert Stewart2D array assignment in for loops| | |
| --- | --- |
| Bugzilla Link | [1141](http://bugs.sac-home.org/show_bug.cgi?id=1141) |
| Created on | Oct 29, 2014 15:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This code compiles ...| | |
| --- | --- |
| Bugzilla Link | [1141](http://bugs.sac-home.org/show_bug.cgi?id=1141) |
| Created on | Oct 29, 2014 15:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This code compiles just fine:
int main()
{
xs = [1,2,3];
for( i=0; i<3; i++) {
xs[i] = 5;
}
return 1; }
The following very similar code does not compile. The only difference is that it is assigning to a 2D array, rather than a 1D array as before.
int main()
{ xss = [[1,2,3],[4,5,6]];
for( i=0; i<2; i++) {
for( j=0; j<2; j++) {
xss[i][j] = 5;
}
}
return 1; }
The compile error is:
$ sac2c test.sac
./test.sac 5:35 error:
=> token `;' expected, `=' token found
abort: Failed to construct a syntax tree for `test.sac'
compilation failed while Loading SAC program, 1 error(s).
Line 5 is `xss[i][j] = 5;`.</pre>Artem ShinkarovArtem Shinkarovhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2131Scan/parse does not believe in some forms of scientific notation2017-11-19T22:00:59ZRobert BerneckyScan/parse does not believe in some forms of scientific notation| | |
| --- | --- |
| Bugzilla Link | [1140](http://bugs.sac-home.org/show_bug.cgi?id=1140) |
| Created on | Oct 14, 2014 21:33 |
| Resolution | FIXED |
| Resolved on | Nov 05, 2015 19:53 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1140](http://bugs.sac-home.org/show_bug.cgi?id=1140) |
| Created on | Oct 14, 2014 21:33 |
| Resolution | FIXED |
| Resolved on | Nov 05, 2015 19:53 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Specifically, this example fails on the line assigning to z:
cat scientificnotationbug.sac
int main()
{
x = 1.2e+3;
StdIO::print();
y = 1.2e-3;
StdIO::print(y);
z = 1.2e3; // This should work.
StdIO::print(z);
return(0);
}
sac@rattler:~/sac/testsuite/optimizations/awlf$ sac2c scientificnotationbug.sac
./scientificnotationbug.sac 9:11 error:
=> + or - expected after exponent
./scientificnotationbug.sac 9:7 error:
=> token 1.2e cannot start an expression.
abort: Failed to construct a syntax tree for `scientificnotationbug.sac'
compilation failed while Loading SAC program, 2 error(s).
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 18509 linux-gnu_x86_64
(Tue Oct 14 15:48:09 EDT 2014 by sac)
This did work, once upon a time, I believe.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://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>BugZillaBugZilla