sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T21:28:43Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1815LACINLING loses AVIS_MAXVAL info2017-11-19T21:28:43ZRobert BerneckyLACINLING loses AVIS_MAXVAL info| | |
| --- | --- |
| Bugzilla Link | [682](http://bugs.sac-home.org/show_bug.cgi?id=682) |
| Created on | Feb 25, 2010 15:58 |
| Resolution | DUPLICATE |
| Resolved on | Apr 26, 2010 17:37 |
| Version | svn |
| OS | Linux |
| Architec...| | |
| --- | --- |
| Bugzilla Link | [682](http://bugs.sac-home.org/show_bug.cgi?id=682) |
| Created on | Feb 25, 2010 15:58 |
| Resolution | DUPLICATE |
| Resolved on | Apr 26, 2010 17:37 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bugCF.sac](/uploads/9ea99dffa8009734c36096a5aafe33b0/bugCF.sac) |
## Extended Description
<pre>Created an attachment (id=676)
source code to reproduce fault
The attached, when compiled with almost any version of sac2c
(e.g., Build #16392 - #16770:MODIFIED), with options:
sac2c bugCF.sac -v4 -extrema -nocyc -noprelude
dies in one of several ways, all related to AVIS extrema not being
handled properly when a LACFUN is inlined at the end of CF.
The N_avis node pointed to by the non-inlined LACFUN extrema
end up pointing to junk, so the failure occurs only when
some other traversal looks at the extrema. Hence, the failure
may occur in VP, CSE, DCR, etc., depending on the phase of
the moon and the will of Loki.
I think the problem demonstrates a design problem in AVIS_MINVAL/MAXVAL:
These fields are defined as attributes, so they are not traversed
at all during DUP or other traversals.
The current flattened representation of extrema has AVIS_MINVAL/MAXVAL
pointing to an appropriate N_avis node, as an attribute.
I am coming to the conclusion that this is wrong, and that
AVIS_MINVAL/MAX should be son nodes, either NULL or pointing to
an N_id, which would then point to the same N_avis node as
at present.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1816Scalar constraints crash memory allocator2017-11-19T21:28:48ZRobert BerneckyScalar constraints crash memory allocator| | |
| --- | --- |
| Bugzilla Link | [683](http://bugs.sac-home.org/show_bug.cgi?id=683) |
| Created on | Mar 01, 2010 16:26 |
| Resolution | FIXED |
| Resolved on | Mar 01, 2010 18:16 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [683](http://bugs.sac-home.org/show_bug.cgi?id=683) |
| Created on | Mar 01, 2010 16:26 |
| Resolution | FIXED |
| Resolved on | Mar 01, 2010 18:16 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>My changes to propagate N_array constraint function results
via scalarization (prfunr) crash the memory allocator.
If you compile almost any problem with -ecc, you get this:
** 15: Introducing memory management instructions ...
**** Propagating constants ...
**** AUD/SCL distinction ...
**** Making copy operations explicit ...
**** Introducing explicit allocation statements ...
ASSERTION FAILED: file 'memory/alloc.c', line 304
alloc requires a dim expression!
EXECUTION TERMINATED
Aborted
sac@rattler:~/sac/testsuite/optimizations/constantfolding$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 16771 linux-gnu_x86_64
(Sun Feb 28 17:34:29 EST 2010 by sac)
I am guessing that scalar and vector versions of the constraint
functions need different treatment in alloc.c (which they
currently don't get), but could use a pointer in which direction to
look for a working example.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1817In CF vs. PRFUNR battle, CF loses, in SCSprf_add2.sac2017-11-19T21:28:54ZRobert BerneckyIn CF vs. PRFUNR battle, CF loses, in SCSprf_add2.sac| | |
| --- | --- |
| Bugzilla Link | [685](http://bugs.sac-home.org/show_bug.cgi?id=685) |
| Created on | Mar 18, 2010 16:36 |
| Resolution | FIXED |
| Resolved on | Jan 23, 2014 14:52 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [685](http://bugs.sac-home.org/show_bug.cgi?id=685) |
| Created on | Mar 18, 2010 16:36 |
| Resolution | FIXED |
| Resolved on | Jan 23, 2014 14:52 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCSprf_add2.sac](/uploads/46c0eaf793ed6e767fc24dc94f344a81/SCSprf_add2.sac) |
## Extended Description
<pre>Created an attachment (id=678)
source code to reproduce fault
I'm not sure why this bug does not occur more often,
but there appears to be a race between CF and PRFUNR,
where PRFUNR makes it more difficult for CF to do its job.
In the SCSprf_add2.sac sac CF unit test suite, the
code is attempting to replace the expression:
z = vec + _neg_V_( vec);
by:
z = vec * 0;
[It actually builds a vector of zeros, but that's harder to spell here.]
If PRFUNR runs before CF, we end up with this sort of code,
potentially made more complicated by the intrusion of guards and,
perhaps, extrema, if we are compiling with -ecc/check c and/or -extrema:
negV = _neg_V_( v1);
_uprf_546 = [ 0 ];
_uprf_547 = _sel_VxA_( _uprf_546, v1);
_uprf_549 = _sel_VxA_( _uprf_546, negV);
_uprf_550 = _add_SxS_( _uprf_547, _uprf_549);
I could add more code to this CF function to handle the
vector indexing, but I'd prefer a more general, or at least
cleaner, solution.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1818prfunr stumbles over SUB_VxS_( id, 1) in wrapper2017-11-19T21:29:01ZSven-Bodo Scholzprfunr stumbles over SUB_VxS_( id, 1) in wrapper| | |
| --- | --- |
| Bugzilla Link | [687](http://bugs.sac-home.org/show_bug.cgi?id=687) |
| Created on | Mar 24, 2010 18:08 |
| Resolution | FIXED |
| Resolved on | Mar 26, 2010 17:33 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [687](http://bugs.sac-home.org/show_bug.cgi?id=687) |
| Created on | Mar 24, 2010 18:08 |
| Resolution | FIXED |
| Resolved on | Mar 26, 2010 17:33 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu.sac](/uploads/eb9d2dd662eaa4db9aea3f556626eb73/tutu.sac) |
## Extended Description
Created an attachment (id=679)
source code
this may be a genuine bug that just happens to occur in a wrapper
or it is a wrapper only problem....
compiler w/o options rev 16781:16782BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1819main() return code wrong if -noopt2017-11-19T21:29:07ZRobert Berneckymain() return code wrong if -noopt| | |
| --- | --- |
| Bugzilla Link | [692](http://bugs.sac-home.org/show_bug.cgi?id=692) |
| Created on | Mar 30, 2010 20:09 |
| Resolution | FIXED |
| Resolved on | Apr 11, 2010 08:33 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [692](http://bugs.sac-home.org/show_bug.cgi?id=692) |
| Created on | Mar 30, 2010 20:09 |
| Resolution | FIXED |
| Resolved on | Apr 11, 2010 08:33 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [foldersliceneeded.sac](/uploads/1e1beaf0aef6e241655a750ff0c0416d/foldersliceneeded.sac) |
## Extended Description
<pre>Created an attachment (id=683)
source code to reproduce fault
The attached, if compiled with -noopt, prints the correct value of z (zero),
but the return value from main, printed with:
a.out; echo $?
returns 177. Which isn't even close to zero.
The -b11 code, as far as I can see, is harmless.
If compiled with no options, the code operates correctly.
This on my HEAVILY modified version:
developer rev 16776:MODIFIED linux-gnu_x86_64
(Tue Mar 30 14:20:28 EDT 2010 by sac)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1820DL introduces non-flattened scalars into AST PRF_ARG positions2017-11-19T21:29:13ZRobert BerneckyDL introduces non-flattened scalars into AST PRF_ARG positions| | |
| --- | --- |
| Bugzilla Link | [693](http://bugs.sac-home.org/show_bug.cgi?id=693) |
| Created on | Apr 04, 2010 20:53 |
| Resolution | FIXED |
| Resolved on | Oct 05, 2010 13:05 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [693](http://bugs.sac-home.org/show_bug.cgi?id=693) |
| Created on | Apr 04, 2010 20:53 |
| Resolution | FIXED |
| Resolved on | Oct 05, 2010 13:05 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [prdreverseAKDNoStdlib.sac](/uploads/14e2015d63f59033213c8f903397c387/prdreverseAKDNoStdlib.sac) |
## Extended Description
<pre>Created an attachment (id=685)
source code to reproduce fault
I just stumbled onto this one. It looks like DL makes no attempt
to flatten the PRF_ARG elements it generates.
The attached code does not fail on obelix today, as it depends,
apparently, on AWLF changes that I'm making locally. Hence, it will
likely come back to haunt us later on.
Fails on my:
rev 16776:MODIFIED
with sac2c -ecc -extrema -doawlf -nowlf prdreverseAKDNoStdlib.sac -v1</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1821format string attack on dbug.c2017-11-19T21:29:18ZClemens Grelckformat string attack on dbug.c| | |
| --- | --- |
| Bugzilla Link | [694](http://bugs.sac-home.org/show_bug.cgi?id=694) |
| Created on | Apr 07, 2010 21:33 |
| Resolution | FIXED |
| Resolved on | Apr 09, 2010 13:56 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [694](http://bugs.sac-home.org/show_bug.cgi?id=694) |
| Created on | Apr 07, 2010 21:33 |
| Resolution | FIXED |
| Resolved on | Apr 09, 2010 13:56 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Some of my students from the compiler course found a flaw in the current
implementation of the dbug package (formerly known as Fred Fish).
http://en.wikipedia.org/wiki/Format_string_attack
In essence, function arguments are directly used as printf format strings,
which is a security hole and at least bad programming practice.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1822-d treecheck fails to detect bad AVIS_SSAASSIGN2017-11-19T21:29:25ZRobert Bernecky-d treecheck fails to detect bad AVIS_SSAASSIGN| | |
| --- | --- |
| Bugzilla Link | [702](http://bugs.sac-home.org/show_bug.cgi?id=702) |
| Created on | Apr 29, 2010 22:30 |
| Resolution | INVALID |
| Resolved on | May 01, 2010 20:12 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [702](http://bugs.sac-home.org/show_bug.cgi?id=702) |
| Created on | Apr 29, 2010 22:30 |
| Resolution | INVALID |
| Resolved on | May 01, 2010 20:12 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I had a problem in PM with SSAASSIGN chain corruption, so
ran with -d treecheck to isolate the fault. No problems reported,
yet the crash still happens.
Then, I manually entered CHKdoTreeCheck(arg_node) calls
at IVEXIfundef entry and exit: Bingo! The bad SSAASSIGN
nodes were detected properly.
This is in my local code, so no idea if this hits the
live system:
rev 16795:16812:MODIFIED
I got it to fail with sac/testsuite/optimizations/awlf/duplhs.sac.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1823CTS appears to be broken2017-11-19T21:29:31ZRobert BerneckyCTS appears to be broken| | |
| --- | --- |
| Bugzilla Link | [703](http://bugs.sac-home.org/show_bug.cgi?id=703) |
| Created on | May 03, 2010 14:35 |
| Resolution | FIXED |
| Resolved on | May 10, 2010 14:48 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [703](http://bugs.sac-home.org/show_bug.cgi?id=703) |
| Created on | May 03, 2010 14:35 |
| Resolution | FIXED |
| Resolved on | May 10, 2010 14:48 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SAACFprf_lt_SxV.sac](/uploads/ac385ef0f23718f9a96baf1c70c5dcf4/SAACFprf_lt_SxV.sac) |
## Extended Description
<pre>Created an attachment (id=690)
source code to reproduce fault
When I compile the attached with no options, I get this:
(_wlbsc_160_sc_bound <= iv=[i] < _flat_8 genwidth [ _wlsimp_247 ])
{
_ctz_255 = _sub_SxV_( i, _flat_8);
_flat_11 = _lt_SxS_( _ctz_255, _flat_0);
_flat_9 = _sel_VxA_( _wlpg_119_zeros, _flat_11);
Note that ctz_255 is a vector, and is used, incorrectly, in the following
line.
I suggest running the sac/testsuite/optimizations scripts when
releasing optimizer code, as one of those tripped this failure.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1824Significant performance loss in code containing LACFUNS after Loch Ness2017-11-19T21:29:45ZRobert BerneckySignificant performance loss in code containing LACFUNS after Loch Ness| | |
| --- | --- |
| Bugzilla Link | [705](http://bugs.sac-home.org/show_bug.cgi?id=705) |
| Created on | May 06, 2010 17:27 |
| Resolution | FIXED |
| Resolved on | May 13, 2010 19:41 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [705](http://bugs.sac-home.org/show_bug.cgi?id=705) |
| Created on | May 06, 2010 17:27 |
| Resolution | FIXED |
| Resolved on | May 13, 2010 19:41 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [xa.out](/uploads/d37cf89766b566415e89ed67619537b8/xa.out), [xxa.out](/uploads/d515121654077c30a8e9234f9d3641c1/xxa.out), [xxxa.out](/uploads/f17dd0c0f011c6bf9e48f86e099f5395/xxxa.out), [apexperformance.ods](/uploads/6069ae78ed2845132e4b110c78f2e5d3/apexperformance.ods), [crud.noinnerloop.breaks.sac](/uploads/93ab441b7027532feb53f7d940d2f8ab/crud.noinnerloop.breaks.sac), [crud.post](/uploads/98467b90156c91d483ebaaefe49a28ba/crud.post), [crud.pre](/uploads/ec46d419b1c651f7c6626d176355ece8/crud.pre), [xcrud.post](/uploads/f03698db6a40395fc1e3e2cbf85ec098/xcrud.post), [xcrud.pre](/uploads/dbcb3a3f36483ff79fa7600bee5c18bc/xcrud.pre), [crud.pre.b14cp](/uploads/b52e2f86d7e8a306dfd6fc6c9fccd2cb/crud.pre.b14cp), [crud.post.b14cp](/uploads/ca3870fa0f99239f5335e7355d031ea8/crud.post.b14cp), [crud.me.after](/uploads/98e1b8149874eead50c0100b10203429/crud.me.after), [a.out](/uploads/b9b71036759fc0c65ff58753b615c74a/a.out) |
## Extended Description
<pre>Created an attachment (id=692)
source code to reproduce fault
As discussed in an email sent to sacdev 2010-05-06, and in a subsequent
sacdev meeting later that day, we discovered that a number of apex
benchmarks suffered significant performance losses as a result of compiler
changes made between Builds:
pre-Loch Ness: sac2c_16543_sac_1208
post-Loch Ness: sac2c_16810_sac_1350
I conjectured that the cause was a failure of LIR to lift
a WL from a LACFUN body into the calling function.
Several changes were made to SSALIR.c in the timeframe above.
In order to isolate the problem, I backed off SSALIR as follows
and reran the apex/testforAKD/testforAKD.sac benchmark:
svn update SSALIR.c -r16405
G SSALIR.c
Updated to revision 16405.
sac@rattler:~/sac2c/src/libsac2c/stdopt$ make
No change in performance was observed (crud.sac reflects
performance with the backed-off version of SSALIR.c.):
testforAKD.sac.exe.O3.LochNess.16543.papiex.rattler.10437:PAPI_TOT_INS: 74503669
testforAKD.sac.exe.O3.PostLochNess.16810.papiex.rattler.16456:PAPI_TOT_INS: 456534574
crud.sac.exe.O3.PostLochNess.16810.papiex.rattler.21309:PAPI_TOT_INS: 456534609</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1825WLT WLBSC call introduces sel() operations that are not optimized away.2017-11-19T21:29:55ZRobert BerneckyWLT WLBSC call introduces sel() operations that are not optimized away.| | |
| --- | --- |
| Bugzilla Link | [706](http://bugs.sac-home.org/show_bug.cgi?id=706) |
| Created on | May 07, 2010 15:47 |
| Resolution | DUPLICATE |
| Resolved on | May 13, 2010 19:41 |
| Version | svn |
| OS | Linux |
| Architec...| | |
| --- | --- |
| Bugzilla Link | [706](http://bugs.sac-home.org/show_bug.cgi?id=706) |
| Created on | May 07, 2010 15:47 |
| Resolution | DUPLICATE |
| Resolved on | May 13, 2010 19:41 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [xcrud.noinnerloop.sac](/uploads/79df8b093855c11b2774d4e67e221db4/xcrud.noinnerloop.sac), [crud.noinnerloop.sac](/uploads/764c68db5737f6ad1d4f1961d55e8023/crud.noinnerloop.sac) |
## Extended Description
<pre>Created an attachment (id=702)
source code to reproduce fault
See also Bug#705.
The newly introduced WLT (now phase 13) includes a WLBSC call, resulting
in this code in the attached SAC code, if I break at -b13:wlbsc:
int[1] _wlbsc_992_sc_iv { } ;
...
_wlbsc_992_sc_iv = [ 0 ];
_wlbsc_993_sc_e = _sel_VxA_( _wlbsc_992_sc_iv, _wlbsc_288_sc_iv);
_wlbsc_994_sc_bound = [ _wlbsc_993_sc_e ];
Note that _wlbsc_992_sc_iv has type AKS.
Unfortunately, there is no call to TC after WLBSC, which would
turn that type into AKV. There is also no call to
CF after that, which would remove that operation
and replace it by something sensible, in this case a constant.
What is the purpose of the WLBSC call? Why was it introduced?
I think that my AWLF changes may make it redundant, but need to
know more about why the WLBSC was introduced.
In the absence of better knowledge, I would guess that its presence there
is not the optimal solution in the long run.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1826-d treecheck gives false positive2017-11-19T21:30:01ZRobert Bernecky-d treecheck gives false positive| | |
| --- | --- |
| Bugzilla Link | [712](http://bugs.sac-home.org/show_bug.cgi?id=712) |
| Created on | May 16, 2010 15:44 |
| Resolution | INVALID |
| Resolved on | Jun 08, 2010 15:14 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [712](http://bugs.sac-home.org/show_bug.cgi?id=712) |
| Created on | May 16, 2010 15:44 |
| Resolution | INVALID |
| Resolved on | Jun 08, 2010 15:14 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I changed my local copy of phase.c to perform -d CHKdoTreeCheck between
each traversal of the syntax tree, rather than at the end of each optimization
cycle, because any AST damage incurred in a specific traversal is detected
far too late in an end-of-cycle check.
However, my IVEXI code leaves the syntax tree with damaged
SSAASSIGN nodes after the traversal of IVEXIwith's sons, until
it calls TUremoveUnusedCodes, after which all is well.
I spent a few hours chasing a non-problem here, and would like
to have a nice way to avoid these false alarms, but have no bright
ideas....</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1827-d treecheck fails to detect multiple pointers to same son2017-11-19T21:30:06ZRobert Bernecky-d treecheck fails to detect multiple pointers to same son| | |
| --- | --- |
| Bugzilla Link | [713](http://bugs.sac-home.org/show_bug.cgi?id=713) |
| Created on | May 24, 2010 13:48 |
| Resolution | FIXED |
| Resolved on | Jun 08, 2010 15:10 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [713](http://bugs.sac-home.org/show_bug.cgi?id=713) |
| Created on | May 24, 2010 13:48 |
| Resolution | FIXED |
| Resolved on | Jun 08, 2010 15:10 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I have been scratching my head, and possibly other places, for
several days chasing a crash in FREElet(), which turned out to
be, I believe, a failure of -d treecheck to detect the case
when more than one node points to the same son node.
In my case on my local code, I ran into the problem when generator nodes
became N_array nodes. Although the generated IL LOOKS ok,
it is definitely damaged, because when either node tree
is freed, it takes the (illegally shared) son with it.
I think a fix might work along these lines, in check.c and
friends:
- introduce a HasParent flag in the common part of each node.
I don't know, offhand, where that part is defined, but I
suppose a grep of NODE_TYPE would be a good start.
- anonymous traversal over ALL nodes, at the front end of CHK,
that does:
HasParent(node) = FALSE;
- the regular CHK traversal following would then do:
complain if HasParent(son).
HasParent( son) = TRUE;
How do I code an anonymous traversal over all nodes?
I thought, based on conversations in the dim past, that this was supposed
to work already, but apparently, that is not the case.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1828compiling with -static crashes unless you use -nophm2017-11-19T21:30:12ZRobert Berneckycompiling with -static crashes unless you use -nophm| | |
| --- | --- |
| Bugzilla Link | [717](http://bugs.sac-home.org/show_bug.cgi?id=717) |
| Created on | Jun 03, 2010 19:54 |
| Resolution | WONTFIX |
| Resolved on | Sep 26, 2015 17:30 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [717](http://bugs.sac-home.org/show_bug.cgi?id=717) |
| Created on | Jun 03, 2010 19:54 |
| Resolution | WONTFIX |
| Resolved on | Sep 26, 2015 17:30 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Compilation with -static in sac2crc LDFLAGS dies this way:
sac2c -O3 loopisAKD.sac -o loopisAKD.asterix.O3
/usr/lib/gcc/i586-suse-linux/4.3/../../../libc.a(malloc.o): In function `__libc_free':
/usr/src/packages/BUILD/glibc-2.11.1/malloc/malloc.c:3692: multiple definition of `free'
/home/rbe/sac2c/lib//libsacphm.seq.a(malloc.p.seq.o):/home/rbe/sac2c/src/libsacphm/compat/malloc.c:201: first defined here
/usr/lib/gcc/i586-suse-linux/4.3/../../../libc.a(malloc.o): In function `__libc_malloc':
/usr/src/packages/BUILD/glibc-2.11.1/malloc/malloc.c:3615: multiple definition of `malloc'
/home/rbe/sac2c/lib//libsacphm.seq.a(malloc.p.seq.o):/home/rbe/sac2c/src/libsacphm/compat/malloc.c:91: first defined here
/usr/lib/gcc/i586-suse-linux/4.3/../../../libc.a(malloc.o): In function `__libc_realloc':
/usr/src/packages/BUILD/glibc-2.11.1/malloc/malloc.c:3748: multiple definition of `realloc'
/home/rbe/sac2c/lib//libsacphm.seq.a(malloc.p.seq.o):/home/rbe/sac2c/src/libsacphm/compat/malloc.c:284: first defined here
collect2: ld returned 1 exit status
I worked around the crash by compiling with -nophm, but papi does
not report any output at all.Whether that is due to -nophm or -static,
or 32-bit vs. 64-bit binaries, I do not know.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1829AVIS_SSAASSIGN attributes not cleared after fun2lac2017-11-19T21:30:17ZClemens GrelckAVIS_SSAASSIGN attributes not cleared after fun2lac| | |
| --- | --- |
| Bugzilla Link | [719](http://bugs.sac-home.org/show_bug.cgi?id=719) |
| Created on | Jun 09, 2010 22:03 |
| Resolution | FIXED |
| Resolved on | Jun 12, 2010 18:38 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [719](http://bugs.sac-home.org/show_bug.cgi?id=719) |
| Created on | Jun 09, 2010 22:03 |
| Resolution | FIXED |
| Resolved on | Jun 12, 2010 18:38 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>AVIS_SSAASSIGN attributes not cleared after fun2lac.
This creates zillions of warnings when running with -d treecheck.
Unfortunately, this is not so simple and there is already a documented
error in undo_ssatransform. One problem among others is that some codes
(lac-inlining, prepare_inlining, etc) run both in SSA and non-SSA form.
So, sometimes they must set AVIS_SSAASSIGN and sometime not.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1830Excessive UTDScalarB compile times2017-11-19T21:30:24ZRobert BerneckyExcessive UTDScalarB compile times| | |
| --- | --- |
| Bugzilla Link | [721](http://bugs.sac-home.org/show_bug.cgi?id=721) |
| Created on | Jun 13, 2010 21:23 |
| Resolution | FIXED |
| Resolved on | Jul 29, 2010 08:12 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [721](http://bugs.sac-home.org/show_bug.cgi?id=721) |
| Created on | Jun 13, 2010 21:23 |
| Resolution | FIXED |
| Resolved on | Jul 29, 2010 08:12 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTDScalarB.sac](/uploads/9fd18a3324e3b983165753dc9b9e64aa/UTDScalarB.sac) |
## Extended Description
<pre>Created an attachment (id=734)
source code to reproduce fault
This is from Build #16884:MODIFIED, but this problem has been around
for many moons:
sac2c UTDScalarB.sac
AL and CSE take very long time to execute. Inlining is fast, unlike
bug report #612.
If compiled with -ecc -extrema -doawlf -nowlf, AL is much, much slower.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1831AS no longer present, but is still required2017-11-19T21:30:34ZRobert BerneckyAS no longer present, but is still required| | |
| --- | --- |
| Bugzilla Link | [722](http://bugs.sac-home.org/show_bug.cgi?id=722) |
| Created on | Jun 13, 2010 22:17 |
| Resolution | FIXED |
| Resolved on | Dec 21, 2010 19:46 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [722](http://bugs.sac-home.org/show_bug.cgi?id=722) |
| Created on | Jun 13, 2010 22:17 |
| Resolution | FIXED |
| Resolved on | Dec 21, 2010 19:46 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug722.sac](/uploads/4722532aef2face4c544bbfdf26647bf/bug722.sac), [gauss.sac](/uploads/65f354a892da1a3198579991dbc582f3/gauss.sac) |
## Extended Description
<pre>Created an attachment (id=735)
source code to reproduce fault
Arithmetic Simplification was removed from sac2c a while back, apparently
due to some miscommunication(s) among sacdev members.
The following is extracted from sac/testsuite/optimizations/awlf/gauss.sac,
from: sac2c gauss.sac -extrema -ecc -doawlf -nowlf -b11
_uprf_1249 = _add_SxS_( n, 1);
_pinl_1073_dif = _sub_SxS_( n, _uprf_1249);
This should have been reduced by AS to:
_pinl_1073_dif = -1;
However, it was not, because AS is gone. CF is not able to handle
this case.
I'm assigning this to to CG, since he removed AS, but as he is on
holidays, I'll take a crack at reintroducing AS...</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1832IVE misses case when vector IV is an N_arg in condfun2017-11-19T21:30:42ZRobert BerneckyIVE misses case when vector IV is an N_arg in condfun| | |
| --- | --- |
| Bugzilla Link | [735](http://bugs.sac-home.org/show_bug.cgi?id=735) |
| Created on | Jul 30, 2010 22:52 |
| Resolution | INVALID |
| Resolved on | Aug 05, 2010 23:25 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [735](http://bugs.sac-home.org/show_bug.cgi?id=735) |
| Created on | Jul 30, 2010 22:52 |
| Resolution | INVALID |
| Resolved on | Aug 05, 2010 23:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.awlf](/uploads/1bf0ecd111ad5e1035100610950e2f34/crud.awlf), [meshWithMesh.sac](/uploads/dfd344cbd70ae993cf488b0e907572e6/meshWithMesh.sac), [crudMeshAKD.sac](/uploads/303e95eea85f1c37e21499589db0a56c/crudMeshAKD.sac), [crud.O3](/uploads/41156e053f588a487841a415d85fd0a7/crud.O3) |
## Extended Description
<pre>Created an attachment (id=749)
source code to reproduce fault
[I think the condfun part is not important here.]
In the following, if iv1 and iv2 are scalars, IVE
works properly. If they are vectors (as below), IVE
fails to convert the vect2offset into an idxs2offset.
use Array:{sel};
int[*] id( int[*] y)
{ return(y);
}
int main()
{
v1 = id([1,0,3]);
v2 = id([4,5,6]);
iv1 = id([1]);
iv2 = id([2]);
z = _eq_SxS_( 2, id(2)) ? v1[ iv1] : v2[iv2];
return(z);
}
IVERASprf is probably the culprit. iv does not have an SSAASSIGN,
because it's an N_arg, so it does not call ReplaceByIdx2Offset.
I think what we could do here is the following:
For the N_arg case, if iv is AKS, we could build an N_array
of the iv elements, forming iv'. That would make IVERASprf happy,
because iv' would have an SSAASSIGN of an N_array, at which
point ReplaceByIdx2Offset would be able to do the replace.
This is slowing things down a bit, here and there!
In particular, stdlib where() gets nailed by it.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1833stdlib documention on website2017-11-19T21:30:47ZCarl Joslinstdlib documention on website| | |
| --- | --- |
| Bugzilla Link | [743](http://bugs.sac-home.org/show_bug.cgi?id=743) |
| Created on | Sep 09, 2010 17:00 |
| Resolution | FIXED |
| Resolved on | Nov 03, 2010 11:14 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [743](http://bugs.sac-home.org/show_bug.cgi?id=743) |
| Created on | Sep 09, 2010 17:00 |
| Resolution | FIXED |
| Resolved on | Nov 03, 2010 11:14 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>+-----------------------------------------------------------------------------+
> Item: sac2tex problem
>
> It's not that no-one knows what it is supposed to do: turn SAC code
> into a nice latex description, which could then be turned in html via
> tex2html. The point is that sbs needs to find out whether it still
> works. Clemns just checked and it doesn't seem to work any more. Then
> we can see how to use it for documentation purposes in the future.
>
> More Info: sbs
> Action By: sbs
sac2tex was working correctly just no one new how to call it. New
stdlib documentation has been created and added to the website.
currently there is no way of updating this on the webserver unless you
have an account on the web server (berlix). It would be nice to have a
simple script to upload a tarball of the documentation so that it is
simple and no account is needed except internal section of the website.
This would help to improve the regularity of updates.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1834constant propagation issue2017-11-19T21:30:53ZSven-Bodo Scholzconstant propagation issue| | |
| --- | --- |
| Bugzilla Link | [746](http://bugs.sac-home.org/show_bug.cgi?id=746) |
| Created on | Sep 17, 2010 07:27 |
| Resolution | FIXED |
| Resolved on | Oct 05, 2010 13:33 |
| Version | svn |
| OS | All |
| Architecture |...| | |
| --- | --- |
| Bugzilla Link | [746](http://bugs.sac-home.org/show_bug.cgi?id=746) |
| Created on | Sep 17, 2010 07:27 |
| Resolution | FIXED |
| Resolved on | Oct 05, 2010 13:33 |
| Version | svn |
| OS | All |
| Architecture | All |
## Extended Description
<pre>Our current optimisation cycle ( rev 17026) triggers
some rather obscure non-intentional constant propagation.
Look at the following code:
int main()
{
a = with {
} : genarray([200], 42);
iv = [22];
if( id( true) ) {
sum = _sel_VxA_( iv, a);
} else {
sum = 0;
}
return( sum);
}
This is compiled rather straight-forwardly.
Now, let us replace
sum = _sel_VxA_( iv, a);
by
jv = iv;
sum = _sel_VxA_( jv, a);
.
One would expect no change, right?
WRONG! What happens is that our constant folder
"computes" jv and, thus propagates [22] into
the conditional.
Although this, in this particular case, is what we want,
it may, in general, lead to unexpected constant propagations.
How to fix this properly is not obvious to me.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1835esdcse destroys guard dataflow in CF unit test SCCFprf_modarray5.sac2017-11-19T21:30:59ZRobert Berneckyesdcse destroys guard dataflow in CF unit test SCCFprf_modarray5.sac| | |
| --- | --- |
| Bugzilla Link | [758](http://bugs.sac-home.org/show_bug.cgi?id=758) |
| Created on | Oct 08, 2010 17:35 |
| Resolution | INVALID |
| Resolved on | Oct 08, 2010 19:16 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [758](http://bugs.sac-home.org/show_bug.cgi?id=758) |
| Created on | Oct 08, 2010 17:35 |
| Resolution | INVALID |
| Resolved on | Oct 08, 2010 19:16 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCCFprf_modarray5.sac](/uploads/0b8bb3e13c4e6e87e6874c01ec0ad0cd/SCCFprf_modarray5.sac) |
## Extended Description
<pre>Created an attachment (id=760)
source code to reproduce fault
Summary says it all.
Build #17084:17087:MODIFIED
Using: sac2c SCCFprf_modarray5.sac -ecc
After -bopt:cyc:esdcf, we have:
_flat_7 = [:int];
_idc_40, _icc_30_pred = _shape_matches_dim_VxA_( _flat_7, cltwo);
_uprf_512 = true;
_icc_31_pred = _uprf_512;
_idc_41 = [:int];
_idc_42, _icc_32_pred = _val_lt_shape_VxA_( _idc_41, cltwo);
_uprf_511 = true;
_icc_35_pred = _uprf_511;
_idc_43 = [:int];
_icc_33 = _modarray_AxVxS_( cltwo, _idc_43, _idc_39);
After -bopt:cyc:esdcse, we have (look at _flat_7):
_flat_7 = [:int];
_idc_40, _icc_30_pred = _shape_matches_dim_VxA_( _flat_7, cltwo);
_uprf_512 = true;
_icc_31_pred = _flat_1;
_idc_41 = [:int];
_idc_42, _icc_32_pred = _val_lt_shape_VxA_( _flat_7, cltwo);
_uprf_511 = true;
_icc_35_pred = _flat_1;
_idc_43 = [:int];
_icc_33 = _modarray_AxVxS_( cltwo, _flat_7, _idc_39);
This destroys the dataflow, which is A Bad Thing.
Probable cause is overly enthusiastic PM in CSE.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1836type coercion unit test SCSprf_toc.sac dies when compiled w/-nocf and sac2c-p2017-11-19T21:31:04ZRobert Berneckytype coercion unit test SCSprf_toc.sac dies when compiled w/-nocf and sac2c-p| | |
| --- | --- |
| Bugzilla Link | [780](http://bugs.sac-home.org/show_bug.cgi?id=780) |
| Created on | Nov 20, 2010 21:44 |
| Resolution | FIXED |
| Resolved on | Oct 13, 2011 19:26 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [780](http://bugs.sac-home.org/show_bug.cgi?id=780) |
| Created on | Nov 20, 2010 21:44 |
| Resolution | FIXED |
| Resolved on | Oct 13, 2011 19:26 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>If compiled with sac2c-d, this unit test works fine w/ -docf or -nocf.
If compiled with the production compiler, sac2c-p -nocf, sac2c gets
a segfault in a deep TRAVsons traversal under IIPIfundef.
These tests are in:
~/sac/testsuite/optimizations/constantfolding
Build #: product rev 17200:MODIFIED linux-gnu_x86_64
Several related tests fail:
SCSprf_toc.sac
SCSprf_tod.sac
SCSprf_tof.sac
SCSprf_toi.sac</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1837Building simple program on snowleopard fails2017-11-19T21:31:11ZBugZillaBuilding simple program on snowleopard fails| | |
| --- | --- |
| Bugzilla Link | [789](http://bugs.sac-home.org/show_bug.cgi?id=789) |
| Created on | Nov 30, 2010 16:53 |
| Resolution | FIXED |
| Resolved on | Dec 05, 2010 19:21 |
| Version | 1.00beta |
| OS | MacOS X |
| Archi...| | |
| --- | --- |
| Bugzilla Link | [789](http://bugs.sac-home.org/show_bug.cgi?id=789) |
| Created on | Nov 30, 2010 16:53 |
| Resolution | FIXED |
| Resolved on | Dec 05, 2010 19:21 |
| Version | 1.00beta |
| OS | MacOS X |
| Architecture | Macintosh |
| Attachments | [bug789.tar](/uploads/e128ef3cedf2e7694c0d3f6487cfe04b/bug789.tar) |
| Reporter | holm |
## Extended Description
<pre>I installed SAC beta for snowleopard on my MacBook.
After the stdlib build is finished, compiling hello.sac fails with the message:
ABORT: The module 'StdIo'
ABORT: (/Users/holm/Documents/Courses/ASCI/parallelprog/sac2c-1.00-beta-snowleopard-i386/stdlib/world/stdio/lib/libStdIoTree.so) is either corrupted or uses an outdated file format.
*** Compilation failed ***
*** Exit code 15 (Running module system)
*** 1 Error(s), 0 Warning(s)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1838sac2c calls rm incorrectly after a segfault2017-11-19T21:31:17ZDaniel Rollssac2c calls rm incorrectly after a segfault| | |
| --- | --- |
| Bugzilla Link | [791](http://bugs.sac-home.org/show_bug.cgi?id=791) |
| Created on | Nov 30, 2010 22:52 |
| Resolution | FIXED |
| Resolved on | Nov 30, 2010 23:38 |
| Version | svn |
| OS | All |
| Architecture |...| | |
| --- | --- |
| Bugzilla Link | [791](http://bugs.sac-home.org/show_bug.cgi?id=791) |
| Created on | Nov 30, 2010 22:52 |
| Resolution | FIXED |
| Resolved on | Nov 30, 2010 23:38 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>After the all too familiar "OOOOOOOPS, your program crashed the compiler 8-((" message a new message has been appearing:
rm: invalid option -- '/'
Try `rm --help' for more information.
Aborted
It can be seen in the testsuite output on any recent masterrun.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1839Type coercion primitives crash LIR when compiled with -nocf2017-11-19T21:31:22ZRobert BerneckyType coercion primitives crash LIR when compiled with -nocf| | |
| --- | --- |
| Bugzilla Link | [794](http://bugs.sac-home.org/show_bug.cgi?id=794) |
| Created on | Dec 05, 2010 22:42 |
| Resolution | FIXED |
| Resolved on | Oct 13, 2011 19:29 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [794](http://bugs.sac-home.org/show_bug.cgi?id=794) |
| Created on | Dec 05, 2010 22:42 |
| Resolution | FIXED |
| Resolved on | Oct 13, 2011 19:29 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>sac2c-p SCSprf_toi.sac -nocf -v4
...
**** Optimization cycle pass: 2
****** Optimizing regular function:
****** _MAIN::main( ): ...
Applying common subexpression elimination ...
Inferring loop invariant variables ...
Segmentation fault
sac2c v1.00-beta (Haggis And Apple)
product rev 17225 linux-gnu_x86_64
(Sun Dec 5 17:27:14 EST 2010 by sac)
This affects ONLY the production compiler, and only when -nocf is used.
Failing code:
int main ()
{
x = 0;
for (ib=0; _le_SxS_( ib, 3); ib = _add_SxS_( ib, 1)){
x = with { ([0] <= [ix] <= [8])
/* CF should make this toi go away */
: _toi_S_( _mul_SxS_( 2, _div_SxS_( ix, 2))); }
: genarray([9], 0);
}
z = _sel_VxA_([7], x);
z = _sub_SxS_(z, 6);
return(z);
}</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1840struct declaration crashes sac2c2017-11-19T21:31:28ZDávid Juhászstruct declaration crashes sac2c| | |
| --- | --- |
| Bugzilla Link | [801](http://bugs.sac-home.org/show_bug.cgi?id=801) |
| Created on | Dec 15, 2010 16:20 |
| Resolution | FIXED |
| Resolved on | Dec 15, 2010 22:37 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [801](http://bugs.sac-home.org/show_bug.cgi?id=801) |
| Created on | Dec 15, 2010 16:20 |
| Resolution | FIXED |
| Resolved on | Dec 15, 2010 22:37 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [struct.sacbugreport](/uploads/b772f48e2310e90bc85866d7ff27546c/struct.sacbugreport) |
## Extended Description
<pre>Created an attachment (id=783)
automatically generated bug report
* Automatically generated on 2010. dec. 15., szerda, 14.28.29 CET
*
* using sac2c v1.00-beta (Haggis And Apple) rev 17157 for linux-gnu_i686
* built Thu Nov 4 14:31:01 GMT 2010.
* by user dsr on host obelix for linux-gnu.
*
* The compiler was called by
* sac2c -o struct struct.sac
*
* The compiler crashed in
* phase: cwc (Creating Wrapper Code and Eliminating User-Defined Types)
* sub phase: cse (Applying common subexpression elimination)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1841multi-generator with-loop with fold crashes sac2c2017-11-19T21:31:35ZDávid Juhászmulti-generator with-loop with fold crashes sac2c| | |
| --- | --- |
| Bugzilla Link | [802](http://bugs.sac-home.org/show_bug.cgi?id=802) |
| Created on | Dec 15, 2010 16:24 |
| Resolution | FIXED |
| Resolved on | Dec 15, 2010 19:12 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [802](http://bugs.sac-home.org/show_bug.cgi?id=802) |
| Created on | Dec 15, 2010 16:24 |
| Resolution | FIXED |
| Resolved on | Dec 15, 2010 19:12 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [multigen.sacbugreport](/uploads/76dc8f355920a11b4f4abdd2189dd395/multigen.sacbugreport) |
## Extended Description
<pre>Created an attachment (id=784)
automatically generated bug report
* Automatically generated on 2010. dec. 15., szerda, 17.21.28 CET
*
* using sac2c v1.00-beta (Haggis And Apple) rev 17157 for linux-gnu_i686
* built Thu Nov 4 14:31:01 GMT 2010.
* by user dsr on host obelix for linux-gnu.
*
* The compiler was called by
* sac2c -o multigen multigen.sac
*
* The compiler crashed in
* phase: pre (Preprocessing SAC program)
* sub phase: mgwl (Handling multi-generator with-loops)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1842AL is broken still/again2017-11-19T21:31:42ZRobert BerneckyAL is broken still/again| | |
| --- | --- |
| Bugzilla Link | [805](http://bugs.sac-home.org/show_bug.cgi?id=805) |
| Created on | Dec 16, 2010 19:49 |
| Resolution | INVALID |
| Resolved on | Dec 31, 2010 21:53 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [805](http://bugs.sac-home.org/show_bug.cgi?id=805) |
| Created on | Dec 16, 2010 19:49 |
| Resolution | INVALID |
| Resolved on | Dec 31, 2010 21:53 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [prdreverseAKD.sac](/uploads/6971f46e4bed4306d080fa0785fcd5d1/prdreverseAKD.sac) |
## Extended Description
<pre>Created an attachment (id=785)
source code to reproduce fault
AL fails to reorder these expressions:
_flat_12 = 50;
_flat_11 = _MAIN::id( _flat_12) ;
_isaa_1744__flat_11 = 0;
_isaa_1745__flat_11 = [:int];
_isaa_1746__flat_11 = _saabind_( _isaa_1744__flat_11, _isaa_1745__flat_11, _flat_11);
_uprf_1347 = [ 0 ];
_uprf_1349, _uprf_1350 = _non_neg_val_S_( _isaa_1746__flat_11);
...
_esd_1361 = -1;
_pinl_1039_lim = _add_SxS_( _uprf_1349, _esd_1361);
_esd_2698 = _neg_S_( _uprf_1349);
_pinl_1035__flat_3 = 1;
_esd_1922 = _add_SxS_( _pinl_1035__flat_3, _esd_2698);
_ivexp_1815 = _add_SxS_( _pinl_1039_lim, _esd_1922);
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 17228:MODIFIED linux-gnu_x86_64
(Wed Dec 15 12:30:57 EST 2010 by sac)
NB. Note compiler options. With no options, it works properly.
I am looking into the fault now.
sac2c-d -v0 prdreverseAKD.sac -ecc -extrema -doawlf -nowlf -bopt:saacyc:al:2 -#d,AL &>crud2</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1843fft_cpx fails to compile on developer sac2c2017-11-19T21:31:47ZRoeland Doumafft_cpx fails to compile on developer sac2c| | |
| --- | --- |
| Bugzilla Link | [807](http://bugs.sac-home.org/show_bug.cgi?id=807) |
| Created on | Dec 21, 2010 18:28 |
| Resolution | DUPLICATE |
| Resolved on | Oct 13, 2011 16:16 |
| Version | svn |
| OS | Linux |
| Architec...| | |
| --- | --- |
| Bugzilla Link | [807](http://bugs.sac-home.org/show_bug.cgi?id=807) |
| Created on | Dec 21, 2010 18:28 |
| Resolution | DUPLICATE |
| Resolved on | Oct 13, 2011 16:16 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>When compiling fft_cpx (FT benchmark) the sac2c compiler (developer version) fails at stage 10. The same code compiles fine on the product version.
** 10: Creating Wrapper Code and Eliminating User-Defined Types ...
**** Creating Wrapper Bodies ...
**** Eliminating conditionals in wrapper code ...
**** Establishing static single assignment form in wrapper code ...
**** Trying to dispatch functions statically ...
**** Removing all structs ...
**** Eliminating User-Defined Types ...
ASSERTION FAILED: file 'typecheck/elim_alpha_types.c', line 492
new element type of array does not match old type!
EXECUTION TERMINATED
make: *** [fft_cpx] Aborted
rm -rf ./fft_cpx.c
The assert is generated in sac2c/src/libsac2c/typecheck/elim_alpha_types.c:491.
The reason this show up in the developer version is that the DBUG_ASSERT line is inside an #ifndef DEBUG_OFF.
This assert also occurs for me with other sac files (the Mandelbrot tutorial for example).</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1844Empty structs or unions in sac2c2017-11-19T21:31:53ZRoeland DoumaEmpty structs or unions in sac2c| | |
| --- | --- |
| Bugzilla Link | [809](http://bugs.sac-home.org/show_bug.cgi?id=809) |
| Created on | Jan 05, 2011 16:15 |
| Resolution | FIXED |
| Resolved on | Jan 12, 2011 15:56 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [809](http://bugs.sac-home.org/show_bug.cgi?id=809) |
| Created on | Jan 05, 2011 16:15 |
| Resolution | FIXED |
| Resolved on | Jan 12, 2011 15:56 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>When compiling sac2c on solaris (with suncc) the compilation fails on empty structs or unions.
Typically these are empty ARG_INFO structs.
Emptry structs or unions are not allowed in C99 so this probably should be fixed.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1845ISO C forbids conversion of function pointer to object pointer type2017-11-19T21:32:00ZRoeland DoumaISO C forbids conversion of function pointer to object pointer type| | |
| --- | --- |
| Bugzilla Link | [813](http://bugs.sac-home.org/show_bug.cgi?id=813) |
| Created on | Jan 06, 2011 11:50 |
| Resolution | FIXED |
| Resolved on | Jan 10, 2011 08:45 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [813](http://bugs.sac-home.org/show_bug.cgi?id=813) |
| Created on | Jan 06, 2011 11:50 |
| Resolution | FIXED |
| Resolved on | Jan 10, 2011 08:45 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [813.patch](/uploads/8caebef89ceb9a7e98960187de104b5f/813.patch) |
## Extended Description
<pre>This seems like "bad" casting. However I am not sure (or know how to fix this).
typecheck/ct_prf.c: In function ‘ApplyCF’:
typecheck/ct_prf.c:33: warning: ISO C forbids conversion of object pointer to function pointer type
typecheck/ct_prf.c:36: warning: ISO C forbids conversion of object pointer to function pointer type
typecheck/ct_prf.c:40: warning: ISO C forbids conversion of object pointer to function pointer type
In file included from typecheck/type_errors.c:72:
tree/prf_info.mac:188: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:196: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:204: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:212: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:220: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:228: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:236: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:244: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:252: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:260: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:268: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:276: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:291: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:299: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:308: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:316: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:324: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:332: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:341: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:349: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:357: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:365: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:380: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:388: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:396: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:404: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:413: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:421: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:429: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:437: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:446: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:454: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:462: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:470: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:479: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:487: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:495: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:503: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:512: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:520: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:528: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:536: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:551: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:559: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:568: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:576: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:585: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:593: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:601: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:609: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:618: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:626: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:634: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:642: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:657: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:665: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:673: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:681: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:690: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:698: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:706: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:714: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:723: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:731: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:739: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:747: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:756: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:764: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:772: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:780: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:789: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:797: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:805: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:813: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:822: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:830: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:838: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:846: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:860: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:868: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:876: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:885: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:893: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:902: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:910: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:918: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:1010: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:1018: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:1026: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:1118: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:1507: warning: ISO C forbids conversion of function pointer to object pointer type
tree/prf_info.mac:1515: warning: ISO C forbids conversion of function pointer to object pointer type</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1846ISO C forbids conversion of object pointer to function pointer type2017-11-19T21:32:06ZRoeland DoumaISO C forbids conversion of object pointer to function pointer type| | |
| --- | --- |
| Bugzilla Link | [814](http://bugs.sac-home.org/show_bug.cgi?id=814) |
| Created on | Jan 06, 2011 11:53 |
| Resolution | FIXED |
| Resolved on | Jan 10, 2011 11:28 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [814](http://bugs.sac-home.org/show_bug.cgi?id=814) |
| Created on | Jan 06, 2011 11:53 |
| Resolution | FIXED |
| Resolved on | Jan 10, 2011 11:28 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Similar to bug #813 but the other way around.
modules/modulemanager.c: In function ‘checkMixedCasesCorrect’:
modules/modulemanager.c:54: warning: ISO C forbids conversion of object pointer to function pointer type
modules/modulemanager.c: In function ‘checkHasSameASTVersion’:
modules/modulemanager.c:84: warning: ISO C forbids conversion of object pointer to function pointer type
modules/modulemanager.c:99: warning: ISO C forbids conversion of object pointer to function pointer type
modules/modulemanager.c: In function ‘checkWasBuildUsingSameFlags’:
modules/modulemanager.c:127: warning: ISO C forbids conversion of object pointer to function pointer type
modules/modulemanager.c: In function ‘checkWhetherDeprecated’:
modules/modulemanager.c:158: warning: ISO C forbids conversion of object pointer to function pointer type
modules/modulemanager.c: In function ‘addNamespaceMappings’:
modules/modulemanager.c:184: warning: ISO C forbids conversion of object pointer to function pointer type
modules/modulemanager.c: In function ‘GetSymbolTableFunction’:
modules/modulemanager.c:335: warning: ISO C forbids conversion of object pointer to function pointer type
modules/modulemanager.c: In function ‘GetDependencyTableFunction’:
modules/modulemanager.c:372: warning: ISO C forbids conversion of object pointer to function pointer type
modules/modulemanager.c: In function ‘MODMgetDeSerializeFunction’:
modules/modulemanager.c:404: warning: ISO C forbids conversion of object pointer to function pointer type</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1847sac2c generates zero-sized struct/union2017-11-19T21:32:11ZRoeland Doumasac2c generates zero-sized struct/union| | |
| --- | --- |
| Bugzilla Link | [817](http://bugs.sac-home.org/show_bug.cgi?id=817) |
| Created on | Jan 07, 2011 12:48 |
| Resolution | FIXED |
| Resolved on | Feb 23, 2011 15:40 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [817](http://bugs.sac-home.org/show_bug.cgi?id=817) |
| Created on | Jan 07, 2011 12:48 |
| Resolution | FIXED |
| Resolved on | Feb 23, 2011 15:40 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>When compiling the standard library with -target ultrat3 the compiler fails.
One example of the error is generated by the following command:
cd modules/structures
sac2c -v0 -O3 -linksetsize 0 -target ultrat3 -mt ScalarArith.sac -o lib
The resulting error is:
"fun1.c", line 3: zero-sized struct/union
This is not allowed by the C99 standard and thus sac2c should not generate such code.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1848ISO C forbids conditional expr with only one void side2017-11-19T21:32:17ZRoeland DoumaISO C forbids conditional expr with only one void side| | |
| --- | --- |
| Bugzilla Link | [827](http://bugs.sac-home.org/show_bug.cgi?id=827) |
| Created on | Feb 18, 2011 08:39 |
| Resolution | FIXED |
| Resolved on | Oct 13, 2011 16:13 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [827](http://bugs.sac-home.org/show_bug.cgi?id=827) |
| Created on | Feb 18, 2011 08:39 |
| Resolution | FIXED |
| Resolved on | Oct 13, 2011 16:13 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>sac2c: r17315
Now that -pedantic is enabled by default on the default target the code in the testsuite generates a lot more warnings. They are all the same warning:
ISO C forbids conditional expr with only one void side
This is a pretty vague warning.
However it seems we are doing something that is not allowed ;)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1849sacphm.seq not found when compiling with sac2c on a mac2017-11-19T21:32:23ZDaniel Rollssacphm.seq not found when compiling with sac2c on a mac| | |
| --- | --- |
| Bugzilla Link | [836](http://bugs.sac-home.org/show_bug.cgi?id=836) |
| Created on | Mar 16, 2011 15:10 |
| Resolution | FIXED |
| Resolved on | Mar 30, 2011 15:12 |
| Version | svn |
| OS | All |
| Architecture |...| | |
| --- | --- |
| Bugzilla Link | [836](http://bugs.sac-home.org/show_bug.cgi?id=836) |
| Created on | Mar 16, 2011 15:10 |
| Resolution | FIXED |
| Resolved on | Mar 30, 2011 15:12 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>The error after compiling with sac2c is:
ld: library not found for -lsacphm.seq
Most likely this is going wrong because code in modules/dependencies.c no longer takes into account that some modules might not be there. I suspect this problem came from this commit:
r17348 | caj | 2011-03-10 17:34:08 +0000 (Thu, 10 Mar 2011) | 2 lines
Make -M support cross compilation
I also suspect these warnings came with that commit too and the reason for them is the same:
ld: warning: directory '/Users/dsr/uni/checkouts/stdlib/utrace/lib' following -L not found
ld: warning: directory '/usr/local/dislin' following -L not found
As a work around until this is fixed the -nophm option can be explicitly passed when working on a mac.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1850A "reverse" function bug2017-11-19T21:32:28ZPavel ZaichenkovA "reverse" function bug| | |
| --- | --- |
| Bugzilla Link | [848](http://bugs.sac-home.org/show_bug.cgi?id=848) |
| Created on | Jun 30, 2011 11:35 |
| Resolution | FIXED |
| Resolved on | Jun 06, 2012 20:36 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [848](http://bugs.sac-home.org/show_bug.cgi?id=848) |
| Created on | Jun 30, 2011 11:35 |
| Resolution | FIXED |
| Resolved on | Jun 06, 2012 20:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Here is a reduced 2.16 listing code from the tutorial (see p.25).
use StdIO: all;
use Array: all;
int main()
{
vect = [0,1,2,3];
arr3d = { [i,j] -> vect[[i]]*4 + vect[[j]]*16 + vect };
print( reverse(arr3d));
return (0);
}
This code craches during compilation with such an error:
TRAVERSE ERROR: node of type N_tfvertex found where N_avis was expected!</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1851TULSisFullGenerator dies when WL generator or genarray shape is N_array2017-11-19T21:32:34ZRobert BerneckyTULSisFullGenerator dies when WL generator or genarray shape is N_array| | |
| --- | --- |
| Bugzilla Link | [849](http://bugs.sac-home.org/show_bug.cgi?id=849) |
| Created on | Jul 01, 2011 18:16 |
| Resolution | FIXED |
| Resolved on | Jul 02, 2011 21:07 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [849](http://bugs.sac-home.org/show_bug.cgi?id=849) |
| Created on | Jul 01, 2011 18:16 |
| Resolution | FIXED |
| Resolved on | Jul 02, 2011 21:07 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Summary says it all.
Fails on developer rev 17450 linux-gnu_x86_64 in AWLF test suite,
as follows:
cd ~/sac/testsuite/optimizations/awlf
sac2c relax.breaks.sac
This could be related to my recent wlbsc change in saacyc,
but am not sure. Are genarray shapes supposed to be flattened
or non-flattened?</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1852UTReshapebug2.sac gets corrupt N_avis in N_return statement after -bopt:etv22017-11-19T21:32:41ZRobert BerneckyUTReshapebug2.sac gets corrupt N_avis in N_return statement after -bopt:etv2| | |
| --- | --- |
| Bugzilla Link | [851](http://bugs.sac-home.org/show_bug.cgi?id=851) |
| Created on | Jul 02, 2011 23:38 |
| Resolution | FIXED |
| Resolved on | Oct 12, 2011 09:24 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [851](http://bugs.sac-home.org/show_bug.cgi?id=851) |
| Created on | Jul 02, 2011 23:38 |
| Resolution | FIXED |
| Resolved on | Oct 12, 2011 09:24 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [loop18crud.sac](/uploads/8c312900af7fc171e16ec00f162c1b92/loop18crud.sac) |
## Extended Description
<pre>The above unit test, in ~/sac/testsuite/optimizations/awlf, dies in VPid
trying to look at the first (only) argument of an N_return.
I suspect someone may have failed to DUP an N_id node. I tried
compiling with:
sac2c UTReshapebug2.sac -d treecheck -chkfreq 4
but that did not show any failures. [Clemens: Is that
check supposed to turn up shared N_id nodes?]
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17452 linux-gnu_x86_64
(Sat Jul 2 16:06:04 EDT 2011 by sac)
Break at -bopt:etv2 does not crash, but it does
crash if we break at -bopt:ebt2.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1853AWLF broken on production sac2c2017-11-19T21:32:47ZRobert BerneckyAWLF broken on production sac2c| | |
| --- | --- |
| Bugzilla Link | [854](http://bugs.sac-home.org/show_bug.cgi?id=854) |
| Created on | Jul 12, 2011 20:55 |
| Resolution | FIXED |
| Resolved on | Jul 13, 2011 19:05 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [854](http://bugs.sac-home.org/show_bug.cgi?id=854) |
| Created on | Jul 12, 2011 20:55 |
| Resolution | FIXED |
| Resolved on | Jul 13, 2011 19:05 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I have been attempting to construct new pre-Loch Ness instruction counts
for the APEX benchmarks, using "perf stat". In doing so, I came
across an oddity which I can not yet explain.
cd sac/apex/iotan
sac2c-d iotan.sac -doawlf -nowlf -O3
executes roughly 178E6 instructions, and generates
one WL for the test, which is "sum(iota(N))".
sac2c-p iotan.sac -doawlf -nowlf -O3
executes roughly 601E6 instructions,
and generates two WLs!
Compiling with "-O3" only executes
about 178E6 with both compilers, and
one WL each.
This is with:
product rev 17482:MODIFIED</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1854AL failing in fairly simple code -not quite2017-11-19T21:32:54ZRobert BerneckyAL failing in fairly simple code -not quite| | |
| --- | --- |
| Bugzilla Link | [855](http://bugs.sac-home.org/show_bug.cgi?id=855) |
| Created on | Jul 20, 2011 21:24 |
| Resolution | FIXED |
| Resolved on | Aug 14, 2011 12:56 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [855](http://bugs.sac-home.org/show_bug.cgi?id=855) |
| Created on | Jul 20, 2011 21:24 |
| Resolution | FIXED |
| Resolved on | Aug 14, 2011 12:56 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug722.sac](/uploads/9c44605aeaed96c981945e4f65cbf2fd/bug722.sac), [crud](/uploads/1599de453f6766b802adc016d72b8064/crud) |
## Extended Description
<pre>Created an attachment (id=806)
source code to reproduce failure
On Build #
sac2c v1.00-beta (Haggis And Apple)
developer rev 17501 linux-gnu_x86_64
(Wed Jul 20 15:06:30 EDT 2011 by sac)
the attached code does not get this relatively simple
sequence of expressions simplified by AL/AS/DL:
_esd_1669 = -1;
_uprf_3430 = _sub_SxS_( _esd_1669, n__SSA0_1);
_uprf_3427 = _add_SxS_( n__SSA0_1, _uprf_3430);
Not sure what's going on; I have not traced the
execution of AS here. However, it is a killer for AWLF,
just as the guards problem is a killer.
sac2c -doawlf -nowlf bug722.sac -bopt:uglf >crud</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1855WL partition breeding in WLPG2017-11-19T21:32:59ZRobert BerneckyWL partition breeding in WLPG| | |
| --- | --- |
| Bugzilla Link | [858](http://bugs.sac-home.org/show_bug.cgi?id=858) |
| Created on | Aug 19, 2011 17:36 |
| Resolution | WORKSFORME |
| Resolved on | Oct 13, 2011 19:07 |
| Version | svn |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [858](http://bugs.sac-home.org/show_bug.cgi?id=858) |
| Created on | Aug 19, 2011 17:36 |
| Resolution | WORKSFORME |
| Resolved on | Oct 13, 2011 19:07 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I came across this while trying to up the AL unit test directory
for Clemens. I am not sure if this is just something I've done
locally, or if the compiler is really doing this "for" everybody:
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17562:MODIFIED linux-gnu_x86_64
(Fri Aug 19 11:06:12 EDT 2011 by sac)
cd ~/sac/testsuite/optimizations/al
sac2c wlir.sac -bewl:cse >crud
Now, look at the WL in foo():
_flat_3 = [ 90, 90 ];
_flat_2 = [ 10, 10 ];
_flat_1 = 0;
_flat_0 = [ 100, 100 ];
r = with {
/*** Partition ***/
(_flat_2 <= _flat_4=[i, j] < _flat_3)
{
_flat_5 = _add_SxS_( i, c);
q = _add_SxS_( b, _flat_5);
} : q ; ,
/*** Partition ***/
default partition( _flat_4=[i, j] ):
{
/* empty */
} : _flat_1 ;
} :
genarray( _flat_0, _flat_1);
Fairly reasonable, I think. Now, let's break the compiler
at the next traversal and see what we get:
sac2c wlir.sac -bewl:wlpg >crud
_flat_3 = [ 90, 90 ];
_flat_2 = [ 10, 10 ];
_flat_1 = 0;
_flat_0 = [ 100, 100 ];
_wlpg_34_zeros = [ 0, 0 ];
_wlpg_35_axis = 0;
_wlpg_36_lmax, _wlpg_37_umin, _wlpg_38_nmin, _wlpg_39_nmax = wrapper:sacprelude::partitionSlicer( _wlpg_34_zeros, _flat_0, _wlpg_35_axis, _flat_2, _flat_3) ;
_wlpg_40_axis = 1;
_wlpg_41_lmax, _wlpg_42_umin, _wlpg_43_nmin, _wlpg_44_nmax = wrapper:sacprelude::partitionSlicer( _wlpg_38_nmin, _wlpg_39_nmax, _wlpg_40_axis, _flat_2, _flat_3) ;
r = with {
/*** Partition ***/
(_wlpg_37_umin <= _flat_4=[i, j] < _flat_0)
{
/* empty */
} : _flat_1 ; ,
/*** Partition ***/
(_wlpg_34_zeros <= _flat_4=[i, j] < _wlpg_36_lmax)
{
/* empty */
} : _flat_1 ; ,
/*** Partition ***/
(_wlpg_42_umin <= _flat_4=[i, j] < _wlpg_39_nmax)
{
/* empty */
} : _flat_1 ; ,
/*** Partition ***/
(_wlpg_38_nmin <= _flat_4=[i, j] < _wlpg_41_lmax)
{
/* empty */
} : _flat_1 ; ,
/*** Partition ***/
(_flat_2 <= _flat_4=[i, j] < _flat_3)
{
_flat_5 = _add_SxS_( i, c);
q = _add_SxS_( b, _flat_5);
} : q ;
} :
genarray( _flat_0, _flat_1);
These partitions do NOT go away by -bopt time, either.
All I can think of is that I have somehow managed to bust
sacprelude with recent changes.
At any rate, perhaps somebody with an older sac2c can try
this same test and see what happens.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1856AWLF defeated by unknown array shape2017-11-19T21:33:06ZRobert BerneckyAWLF defeated by unknown array shape| | |
| --- | --- |
| Bugzilla Link | [861](http://bugs.sac-home.org/show_bug.cgi?id=861) |
| Created on | Aug 25, 2011 18:13 |
| Resolution | FIXED |
| Resolved on | Sep 12, 2011 21:17 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [861](http://bugs.sac-home.org/show_bug.cgi?id=861) |
| Created on | Aug 25, 2011 18:13 |
| Resolution | FIXED |
| Resolved on | Sep 12, 2011 21:17 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This is unit test ~/sac/testsuite/optimizations/awlf/subarray1dAKD.sac:
use Array: {drop,iota,sum};
int[*] id(int[*] y)
{
return(y);
}
int main()
{
XXX = iota(id (50));
YYY = drop([20], XXX);
ZZZ = sum(YYY);
z = _sub_SxS_(ZZZ, 1035);
return(z);
}
-----------------------------------------------------
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17569:MODIFIED linux-gnu_x86_64
(Thu Aug 25 13:10:01 EDT 2011 by sac)
AWLF should be able to fold this into a single WL, but it
fails to do so, because it can't determine if:
( 20 - id(50)) < 0
This leaves the value behind a CONDfun, which defeats AWLF.
Although this is a contrived unit test, I can conceive
of such code arising in practice.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1857WHILE() failing to detect FALSE case2017-11-19T21:33:12ZRobert BerneckyWHILE() failing to detect FALSE case| | |
| --- | --- |
| Bugzilla Link | [862](http://bugs.sac-home.org/show_bug.cgi?id=862) |
| Created on | Aug 25, 2011 20:23 |
| Resolution | FIXED |
| Resolved on | Oct 10, 2011 17:39 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [862](http://bugs.sac-home.org/show_bug.cgi?id=862) |
| Created on | Aug 25, 2011 20:23 |
| Resolution | FIXED |
| Resolved on | Oct 10, 2011 17:39 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/93b6bf03d8b8fc0575011ff5a93dc37d/crud.sac) |
## Extended Description
<pre>Created an attachment (id=813)
source code to reproduce failure
A binary search code used in various fundamental APEX primitives
(set membership, indexof...) seems to have gone haywire, some
time ago, but I only had a chance to look at it now.
Specifically, a while() loop starting off this way:
while ((first <= last) && !found) {
if( first > last) {
StdIO::show( tochar( "Bad!"));
}
manages to print "Bad". That's bad.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17569:MODIFIED linux-gnu_x86_64
(Thu Aug 25 13:10:01 EDT 2011 by sac)
apex@rattler:~/apex2003/benchmks/UTEpio$ sac2c crud.sac -v0
a.out apex@rattler:~/apex2003/benchmks/UTEpio$ a.out |more
Entering BinarySearch while()
0 3 99
2
[first,last]=
0 2
[first,last]=
0 0
Bad!
[first,last]=
1 0
Bad!
[first,last]=
1 0
Bad!
[first,last]=
1 0
Bad!
I was going to let it run to completion, but the nine billion names
aren't going to be done for a while yet...
The guts of the loop includes a conditional or two which, if removed,
make the code work OK.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1858-mt broken for matmul() and other things2017-11-19T21:33:17ZRobert Bernecky-mt broken for matmul() and other things| | |
| --- | --- |
| Bugzilla Link | [876](http://bugs.sac-home.org/show_bug.cgi?id=876) |
| Created on | Sep 28, 2011 13:54 |
| Resolution | FIXED |
| Resolved on | Sep 28, 2011 19:19 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [876](http://bugs.sac-home.org/show_bug.cgi?id=876) |
| Created on | Sep 28, 2011 13:54 |
| Resolution | FIXED |
| Resolved on | Sep 28, 2011 19:19 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>As you can see by this report, multithreading support appears to be
broken today:
cd ~/sac/demos/numerical/misc
sac2c matmul.sac -O3 -v1 -mt -numthreads 6
/tmp/ccwkN9iZ.o: In function `SACf__MAIN_CL_ST_CL_INIT__init':
a.out.c:(.text+0x2f): undefined reference to `SACf_World_CL_ST_CL_INIT__init_TheWorld__SACt_World__World'
a.out.c:(.text+0x3e): undefined reference to `SACf_Terminal_CL_ST_CL_INIT__init_TheTerminal__SACt_Terminal__Terminal'
/tmp/ccwkN9iZ.o: In function `SACf__MAIN_CL_ST__main':
a.out.c:(.text+0x738): undefined reference to `SACf_World_CL_ST_CL_INIT__init_TheWorld__SACt_World__World'
a.out.c:(.text+0x747): undefined reference to `SACf_Terminal_CL_ST_CL_INIT__init_TheTerminal__SACt_Terminal__Terminal'
a.out.c:(.text+0x756): undefined reference to `SACf_TermFile_CL_ST_CL_INIT__init_stdout__SACt_TermFile__TermFile'
/tmp/ccwkN9iZ.o: In function `SACf__MAIN_CL_ST_CL_INIT__init':
a.out.c:(.text+0x51): undefined reference to `SACf_TermFile_CL_ST_CL_INIT__init_stdout__SACt_TermFile__TermFile'
collect2: ld returned 1 exit status
ABORT: System failed to execute shell command
ABORT: gcc -pedantic -Wall -Wno-unused -fno-builtin -std=c99 -ldl
ABORT: -lpthread -I$SAC2CBASE/include/ -L$SAC2CBASE/lib/ -L/tmp/SAC_ErQK6v
ABORT: -O3 -o a.out a.out.c -L. -Wl,-rpath,. -L/home/sac/sac2c/lib
ABORT: -Wl,-rpath,/home/sac/sac2c/lib
ABORT: -L/home/sac/sac/BASE/stdlib/modules/structures/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/modules/structures/lib
ABORT: -L/home/sac/sac/BASE/stdlib/modules/numerical/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/modules/numerical/lib
ABORT: -L/home/sac/sac/BASE/stdlib/modules/numerical/blas/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/modules/numerical/blas/lib
ABORT: -L/home/sac/sac/BASE/stdlib/modules/unibench/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/modules/unibench/lib
ABORT: -L/home/sac/sac/BASE/stdlib/modules/auxiliary/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/modules/auxiliary/lib
ABORT: -L/home/sac/sac/BASE/stdlib/modules/mutc/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/modules/mutc/lib
ABORT: -L/home/sac/sac/BASE/stdlib/world/mutc/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/world/mutc/lib
ABORT: -L/home/sac/sac/BASE/stdlib/world/system/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/world/system/lib
ABORT: -L/home/sac/sac/BASE/stdlib/world/stdio/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/world/stdio/lib
ABORT: -L/home/sac/sac/BASE/stdlib/world/stdio/dislin/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/world/stdio/dislin/lib
ABORT: -L/home/sac/sac/BASE/stdlib/world/stdio/gnuplot/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/world/stdio/gnuplot/lib
ABORT: -L/home/sac/sac/BASE/stdlib/classes/random/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/classes/random/lib
ABORT: -L/home/sac/sac/BASE/stdlib/classes/auxiliary/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/classes/auxiliary/lib
ABORT: -L/home/sac/sac/BASE/stdlib/utrace/lib
ABORT: -Wl,-rpath,/home/sac/sac/BASE/stdlib/utrace/lib -L. -Wl,-rpath,.
ABORT: -L/usr/local/dislin -Wl,-rpath,/usr/local/dislin -L/opt/local/lib
ABORT: -Wl,-rpath,/opt/local/lib -lStdIOMod -lBinFileMod -lFibreIOMod
ABORT: -lListIOMod -lComplexIOMod -lColor8IOMod -lGreyIOMod -lArrayIOMod
ABORT: -lScalarIOMod -lStringArrayMod -lRuntimeErrorMod -lIOresourcesMod
ABORT: -lArrayFormatMod -lStructuresMod -lBitsMod -lComplexMod -lListMod
ABORT: -lColor8Mod -lGreyMod -lFileMod -lTermFileMod -lTerminalMod
ABORT: -lFileSystemMod -lArrayMod -lMathArrayMod -lComplexArrayTransformMod
ABORT: -lComplexArrayArithMod -lArrayTransformMod -lSysErrMod -lWorldMod
ABORT: -lStringMod -lConstantsMod -lArrayArithMod -lComplexScalarArithMod
ABORT: -lComplexArrayBasicsMod -lComplexBasicsMod -lBoolMod -lCharMod
ABORT: -lArrayBasicsMod -lMathMod -lm -lScalarArithMod -lsacpreludeMod
ABORT: -lsacphm.mt -lsac.mt.pth -pthread -ldl
ABORT: with exit code 1
*** Compilation failed ***
*** Exit code 367 (Creating binary code)
*** 1 Error(s), 0 Warning(s)
Build#
developer rev 17642:MODIFIED linux-gnu_x86_64
(Tue Sep 27 19:08:41 EDT 2011 by sac)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1859-doivecyc increased entropy kills StructOpSel in CF2017-11-19T21:33:23ZRobert Bernecky-doivecyc increased entropy kills StructOpSel in CF| | |
| --- | --- |
| Bugzilla Link | [880](http://bugs.sac-home.org/show_bug.cgi?id=880) |
| Created on | Oct 19, 2011 19:08 |
| Resolution | FIXED |
| Resolved on | Oct 21, 2011 15:50 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [880](http://bugs.sac-home.org/show_bug.cgi?id=880) |
| Created on | Oct 19, 2011 19:08 |
| Resolution | FIXED |
| Resolved on | Oct 21, 2011 15:50 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The advent of -doivecyc shows up a problem in CF or, more properly,
in the reduced semantic information available to CF.
Consider this code (trimmed SCCFprf_selivecyc.sac) from the CF unit test suit:
int[*] id(int[*] y)
{ return(y);
}
int main()
{
two = id(2);
three = id(3);
four = id(4);
five = id(5);
XX = [[two, three],[four, five]];
/* CF should turn this into "three" */
z = _add_SxS_(z, _sel_VxA_([0,1], XX));
z = _sub_SxS_(z,8); /* 0 = success */
return(z);
}
StructOpSel in SCCF turns:
z = _sel_VxA_( [0, 1], XX);
into:
z = _sel_VxA_( [1], [two, three]);
and a subsequent CF turns that into:
z = three;
This optimization requires, at present, the index vector
to be available as a constant.
With -doivecyc, the original code is converted into:
offset = _vect2offset( shape(XX), [ 0, 1]);
z = _idx_sel( offset, XX);
The first line quickly becomes:
offset = 1;
However, we are unable to index into the ravel of XX
using "offset", as it is a structural constant. At present,
CF dies with a rank error.
I see two ways to resolve this problem:
1. Introduce a function to perform the mixed-radix inverse
of vect2offset:
iv' = offset2vect( shape(XX), offset);
If StructOpSel is the only victim of -doivecyc, then
this approach makes sense.
2. Replace idx_sel( offset, mat) within the opt cycle, with
a new N_prf function that preserves iv and lets optimizations take
their choice of representation:
z = _idxiv_sel( offset, mat, iv);
This function would be turned back into idx_sel() by a post-optimization
traversal.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1860CF SelProxyArray damages AST in APEX rle.sac2017-11-19T21:33:29ZRobert BerneckyCF SelProxyArray damages AST in APEX rle.sac| | |
| --- | --- |
| Bugzilla Link | [881](http://bugs.sac-home.org/show_bug.cgi?id=881) |
| Created on | Oct 23, 2011 21:38 |
| Resolution | FIXED |
| Resolved on | Mar 16, 2012 21:33 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [881](http://bugs.sac-home.org/show_bug.cgi?id=881) |
| Created on | Oct 23, 2011 21:38 |
| Resolution | FIXED |
| Resolved on | Mar 16, 2012 21:33 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.breaks.sac](/uploads/00707dc763da59f0e49ae24fb8515f99/crud.breaks.sac) |
## Extended Description
Failing Build: developer rev 17687:17688:MODIFIED
sac2c apex/rle/rle.sac
This has apparently been with us for a while.
It seems to have worked properly in rev 17603.
Unfortunately, SelProxyArray is somewhat opaque,
so fixing it may take a while...BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1861LIR fails to remove WL from apex/ipbb/ipbb.sac2017-11-19T21:33:42ZRobert BerneckyLIR fails to remove WL from apex/ipbb/ipbb.sac| | |
| --- | --- |
| Bugzilla Link | [899](http://bugs.sac-home.org/show_bug.cgi?id=899) |
| Created on | Jan 05, 2012 19:59 |
| Resolution | FIXED |
| Resolved on | Mar 25, 2012 19:55 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [899](http://bugs.sac-home.org/show_bug.cgi?id=899) |
| Created on | Jan 05, 2012 19:59 |
| Resolution | FIXED |
| Resolved on | Mar 25, 2012 19:55 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [xipbb.sac](/uploads/be3b5012509c7a01ae69fd139d7444dd/xipbb.sac), [ipbbAKD.sac](/uploads/547e4331aa3dde156bdbfbc8a7e56467/ipbbAKD.sac), [notes-20120321.tar.gz](/uploads/890c5f3872e89ae4dc89981e6423701c/notes-20120321.tar.gz), [xcrudd](/uploads/5e60fc17acc7fb70995a8f57be2c341d/xcrudd), [ipbb.sac](/uploads/c8dc5138b400de346fc43918273ff559/ipbb.sac), [bug870.sac](/uploads/8378cfb33f32d028b51493240a4a5903/bug870.sac), [crudd](/uploads/252fa32125923ad0040f9c6e695bd929/crudd), [bug870-awlf-opt_dcr3](/uploads/45f35abf070499963d9a1da6bb7d6838/bug870-awlf-opt_dcr3) |
## Extended Description
<pre>Created an attachment (id=838)
source code to reproduce failure
I have two very similar codes for Boolean inner products.
The AKS version differs from the AKD version only in the sense
that the matrix sizes are a run-time parameter.
The AKD version runs 16 times faster than the AKS version, which
seems a trifle unfair.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17718:MODIFIED linux-gnu_x86_64
(Wed Jan 4 17:41:14 EST 2012 by sac)
This resembles some of the LIR failures we have seen.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1862_toc_S_() very slow2017-11-19T21:33:47ZRobert Bernecky_toc_S_() very slow| | |
| --- | --- |
| Bugzilla Link | [909](http://bugs.sac-home.org/show_bug.cgi?id=909) |
| Created on | Feb 10, 2012 19:36 |
| Resolution | INVALID |
| Resolved on | Feb 10, 2012 23:13 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [909](http://bugs.sac-home.org/show_bug.cgi?id=909) |
| Created on | Feb 10, 2012 19:36 |
| Resolution | INVALID |
| Resolved on | Feb 10, 2012 23:13 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Execution of the above primitive seems excessively slow.
Build #17728 shows the following test to run about 7.3X slower
if _toc_S_() is used, over that of using a scalar character constant.
Here's the code:
use Array: all;
use String:{tochar};
int main()
{
n = 40000000;
A_27=rhoICC(n,' ');
r_0 = _sel_VxA_( [2], A_27);
StdIO::print(r_0);
return(0);
}
char[.] rhoICC(int n, char y)
{
z = with{
([0] <= [i] < [n]) :
#ifdef SLOW
_toc_S_( i);
#else // SLOW
' ';
#endif //SLOW
} : genarray( [n], ' ');
return(z);
}
sac2c -v1 -O3 crud3.sac
Instructions Completed ....................... 12687574
Vector Instructions .......................... 2500040
sac2c -v1 -O3 crud3.sac -DSLOW
Instructions Completed ....................... 92687612
Vector Instructions .......................... 82500048
That seems like a lot of instructions for a cast().</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1863-ecc reports wrong error2017-11-19T21:33:53ZRobert Bernecky-ecc reports wrong error| | |
| --- | --- |
| Bugzilla Link | [913](http://bugs.sac-home.org/show_bug.cgi?id=913) |
| Created on | Feb 16, 2012 20:16 |
| Resolution | INVALID |
| Resolved on | Feb 16, 2012 20:44 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [913](http://bugs.sac-home.org/show_bug.cgi?id=913) |
| Created on | Feb 16, 2012 20:16 |
| Resolution | INVALID |
| Resolved on | Feb 16, 2012 20:44 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This is in my enhanced CTZ code that handles this guard
a la comparisons against zero.
ERROR: line 119 in file ArrayArith.sac:
ERROR: argument #1 of "_val_lt_val_SxS_" should be less than argument #2;
ERROR: types found: int{-1} and int{0}
What's going on here is that the TC code for guard has a hidden additional
check: PRF_ARG1( arg_node) >= 0
This does not work at all with my shiny new code, so I
intend to remove that check from the guard. We may have to
insert ANOTHER guard to cover that unstated check, but I think that
they are already covered by _non_neg_val().
This code is not checked in, so don't be surprised if you can't reproduce
the fault.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1864SAC program fails to read PGM array data2017-11-19T21:33:58ZBep RintoSAC program fails to read PGM array data| | |
| --- | --- |
| Bugzilla Link | [917](http://bugs.sac-home.org/show_bug.cgi?id=917) |
| Created on | Feb 22, 2012 12:22 |
| Resolution | FIXED |
| Resolved on | Mar 04, 2012 17:14 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [917](http://bugs.sac-home.org/show_bug.cgi?id=917) |
| Created on | Feb 22, 2012 12:22 |
| Resolution | FIXED |
| Resolved on | Mar 04, 2012 17:14 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The following code tests the SAC PGM library.
When run on this small test PGM file:
P2
2 2
255
0 255
0 255
it crashes with this message:
Reading pat2_2x2.pgm ...
Writing /dev/null as binary ...
Writing /dev/null as text ...
*** SAC runtime error
*** Memory access violation on reading from array SACp_pinl_2316_ret
*** with size 0 at index position 0 !
use StdIO: { printf };
use RuntimeError: { error };
use CommandLine: { argc, argv };
use SysErr: { fail };
use PGM: { readPGM, printPGM };
import Grey: all;
import ScalarArith: all;
import Array: all;
use ArrayIO: { print };
int main()
{
if (argc() < 2) {
error(1, "Need at least one file arg");
}
for (i = 1; i < argc(); ++i) {
name = argv(i);
printf("Reading %s ...\n", name);
g = readPGM(name);
printf("Writing /dev/null as binary ...\n");
printPGM(g, "/dev/null", true);
printf("Writing /dev/null as text ...\n");
printPGM(g, "/dev/null", false);
shp = Grey::shape(g);
// print(shp);
w = shp[0];
h = shp[1];
min = maxint();
max = minint();
for (y = 0; y < h; ++y) {
for (x = 0; x < w; ++x) {
if (min > (:int) g[y,x]) {
min = (:int) g[y,x];
}
if (max < (:int) g[y,x]) {
max = (:int) g[y,x];
}
}
}
printf("Minimum is %d, maximum is %d\n", min, max);
}
return 0;
}
I</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1865sac2c fails to compile empty while loop2017-11-19T21:34:04ZBep Rintosac2c fails to compile empty while loop| | |
| --- | --- |
| Bugzilla Link | [919](http://bugs.sac-home.org/show_bug.cgi?id=919) |
| Created on | Feb 22, 2012 18:27 |
| Resolution | FIXED |
| Resolved on | Feb 27, 2012 11:56 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [919](http://bugs.sac-home.org/show_bug.cgi?id=919) |
| Created on | Feb 22, 2012 18:27 |
| Resolution | FIXED |
| Resolved on | Feb 27, 2012 11:56 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [919.sac](/uploads/70028feda266f87930d1224dbe39a950/919.sac) |
## Extended Description
<pre>sac2c fails to compile the following program with the empty while loop.
Compilation succeeds after adding a statement to the while loop.
The sac2c message is:
ERROR: line 10 file: t.sac
ERROR: Identifier 'stop` used without previous definition
import ScalarArith: all;
use StdIO : all;
int main()
{
if (argc() < 2) {
printf("Need at least one arg\n");
} else {
stop = false;
while (stop == false) {
}
}
return 0;
}</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1866strange or inconsistent parsing of multiple return values2017-11-19T21:34:09ZBep Rintostrange or inconsistent parsing of multiple return values| | |
| --- | --- |
| Bugzilla Link | [925](http://bugs.sac-home.org/show_bug.cgi?id=925) |
| Created on | Mar 01, 2012 13:11 |
| Resolution | WORKSFORME |
| Resolved on | Apr 21, 2012 18:46 |
| Version | 1.00beta |
| OS | Linux |
| Ar...| | |
| --- | --- |
| Bugzilla Link | [925](http://bugs.sac-home.org/show_bug.cgi?id=925) |
| Created on | Mar 01, 2012 13:11 |
| Resolution | WORKSFORME |
| Resolved on | Apr 21, 2012 18:46 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The multiple-return value parsing feels strange in several respects.
First it requires parentheses. C doesn't require parentheses for
a return value. One can write:
return value;
But in SAC this doesn't work for multiple return values:
ABORT: line 11 file: testcomma.sac
ABORT: syntax error at pos 13: ',`
ABORT: return a, b;
ABORT: ^
This code works when it is changed to "return (a, b);".
Second the multiple return value cannot be used
in combination with the ternary conditional operator:
ABORT: line 13 file: testcomma.sac
ABORT: syntax error at pos 26: ',`
ABORT: return ((k <= 1) ? (a, b) : (c, d));
ABORT: ^
To make this code work one has to revert to tedious code like:
e = (k <= 1) ? a : c;
f = (k <= 1) ? b : d;
return (e, f);</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1867APEX logd3.sac slower with AWLF than with WLF, due to WLUR2017-11-19T21:34:17ZRobert BerneckyAPEX logd3.sac slower with AWLF than with WLF, due to WLUR| | |
| --- | --- |
| Bugzilla Link | [926](http://bugs.sac-home.org/show_bug.cgi?id=926) |
| Created on | Mar 01, 2012 16:39 |
| Resolution | FIXED |
| Resolved on | Jul 06, 2012 20:45 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [926](http://bugs.sac-home.org/show_bug.cgi?id=926) |
| Created on | Mar 01, 2012 16:39 |
| Resolution | FIXED |
| Resolved on | Jul 06, 2012 20:45 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [logd3.sac](/uploads/95bad1760f06ecffa7262d3bfc2ca46d/logd3.sac), [logd3.sac.boptuglf.awlf.17747_MODIFIED](/uploads/0c5aec02e304573c8f09c210dff16722/logd3.sac.boptuglf.awlf.17747_MODIFIED), [logd3.sac.boptuglf.O3.17747_MODIFIED](/uploads/ff48814670933ab58629c03329e39a38/logd3.sac.boptuglf.O3.17747_MODIFIED) |
## Extended Description
<pre>Created an attachment (id=857)
source code to reproduce failure
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17747:MODIFIED linux-gnu_x86_64
(Wed Feb 29 17:00:50 EST 2012 by sac)
The benchmark above runs significantly slower ( nearly 2X)
with -doawlf -nowlf
than with -noawlf -dowlf. The apparent cause is a failure
to perform AWLF fast enough to beat WLUR to the punch:
The AWLF version shows an unrolled (1-element) WL selecting one
element from an otherwise unreferenced (and big) WL.
In the WLF version, WLF apparently folds the two WLs before
WLUR can take action.
I do not see a swell, simple way to resolve this problem.
One slightly unpleasant approach might be to extend
AWLF to operate on an unrolled consumer-WL, as if it
were a WL.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1868sac2c fails to compile classtype referenced more than once2017-11-19T21:34:23ZBep Rintosac2c fails to compile classtype referenced more than once| | |
| --- | --- |
| Bugzilla Link | [929](http://bugs.sac-home.org/show_bug.cgi?id=929) |
| Created on | Mar 06, 2012 19:23 |
| Resolution | WORKSFORME |
| Resolved on | Mar 07, 2012 04:21 |
| Version | 1.00beta |
| OS | Linux |
| Ar...| | |
| --- | --- |
| Bugzilla Link | [929](http://bugs.sac-home.org/show_bug.cgi?id=929) |
| Created on | Mar 06, 2012 19:23 |
| Resolution | WORKSFORME |
| Resolved on | Mar 07, 2012 04:21 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I have this great idea how to write SAC image format parsing code.
Really great! However, my road to progress and fame is continuously
hindered by the bugs in sac2c... Here's another one. I simplified
the code as much as a I could to help you fix it as fast as you can,
because I need it! :-)
sac2c complains thus:
sac2c -v0 -g -O3 -linksetsize 0 -mt X.sac -o lib
ERROR: line 13 file: X.sac
ERROR: Unique var x of type X referenced more than once
ERROR: line 11 file: X.sac
ERROR: Previous reference was here
*** Compilation failed ***
*** Exit code 66 (Checking uniqueness property of objects)
*** 2 Error(s), 0 Warning(s)
About the code from the file X.sac which you can find below.
I varied with pragma's like refcounting, etc. All without help.
Here comes the code:
class X;
external classtype;
export all;
void readX()
{
x = openX();
readHeader( x);
readData( x);
}
external X openX();
#pragma effect FileSystem::TheFileSystem
#pragma linkobj "x.o"
#pragma linkname "SAC_X_open"
external void readHeader( X x);
#pragma effect FileSystem::TheFileSystem
#pragma linkobj "x.o"
#pragma linkname "SAC_X_read_header"
external void readData( X x);
#pragma effect FileSystem::TheFileSystem
#pragma linkobj "x.o"
#pragma linkname "SAC_X_read_data"</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1869New parser broken on Build #177612017-11-19T21:34:29ZRobert BerneckyNew parser broken on Build #17761| | |
| --- | --- |
| Bugzilla Link | [935](http://bugs.sac-home.org/show_bug.cgi?id=935) |
| Created on | Mar 19, 2012 17:58 |
| Resolution | FIXED |
| Resolved on | Apr 21, 2012 20:52 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [935](http://bugs.sac-home.org/show_bug.cgi?id=935) |
| Created on | Mar 19, 2012 17:58 |
| Resolution | FIXED |
| Resolved on | Apr 21, 2012 20:52 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [patch-sac-oper.diff](/uploads/89ce4da4a61cd6359de5349c8a30d58b/patch-sac-oper.diff) |
## Extended Description
<pre>sac2c dtb.sac -doawlf -nowlf -v4 -O3
WARNING: AWLF is enabled: -ecc enabled.
WARNING: AWLF is enabled: -extrema enabled.
WARNING: AWLF is enabled: -maxoptcyc=20
** 1: Loading SAC program ...
**** Locating source code ...
Reading from file "./dtb.sac" ...
**** Running C preprocessor ...
**** Parsing input file ...
./dtb.sac error:102:17: token `)' expected, `++' token found
./dtb.sac error:102:17: token `;' expected, `++' token found
./dtb.sac error:105:1: token `}' expected, `inline' token found
./dtb.sac error:107:17: token `)' expected, `++' token found
./dtb.sac error:107:17: token `;' expected, `++' token found
./dtb.sac error:110:1: token `}' expected, `inline' token found
./dtb.sac error:160:18: binary function expected
./dtb.sac error:250:24: token `;' expected, `++' token found
note: finished parsing.
note: 8 error(s) found.
ABORT: Failed to construct a syntax tree for `dtb.sac'
Here's the offending line:
return(toI(x)++[toI(y)]);
And...
#define toI(x) toi((x))</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1870New parser breaks Livermore Loop 09 with Build #177602017-11-19T21:34:35ZRobert BerneckyNew parser breaks Livermore Loop 09 with Build #17760| | |
| --- | --- |
| Bugzilla Link | [938](http://bugs.sac-home.org/show_bug.cgi?id=938) |
| Created on | Mar 21, 2012 19:12 |
| Resolution | FIXED |
| Resolved on | Mar 21, 2012 20:48 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [938](http://bugs.sac-home.org/show_bug.cgi?id=938) |
| Created on | Mar 21, 2012 19:12 |
| Resolution | FIXED |
| Resolved on | Mar 21, 2012 20:48 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Build #17758 works OK.
Basically, what happens is that Build #17760 eliminates just about
all the code except for the print() statement. The resulting code runs
amazingly fast, but the results are wrong. Aside from that, no problem.
cd ~/sac/demos/benchmarks/livermore_loops/for_comparison/loop09
sac2c -v1 loop09.sac -bopt >crud</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1871LIR misses lifting WL2017-11-19T21:34:42ZRobert BerneckyLIR misses lifting WL| | |
| --- | --- |
| Bugzilla Link | [940](http://bugs.sac-home.org/show_bug.cgi?id=940) |
| Created on | Mar 25, 2012 21:16 |
| Resolution | INVALID |
| Resolved on | Mar 25, 2012 21:54 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [940](http://bugs.sac-home.org/show_bug.cgi?id=940) |
| Created on | Mar 25, 2012 21:16 |
| Resolution | INVALID |
| Resolved on | Mar 25, 2012 21:54 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [buildv.sac](/uploads/249b0f38e1a2f2d88df563b008b3dad6/buildv.sac), [buildv.sac.boptuglf.awlf.17770](/uploads/152b7913d12dad84d6f5a51affa9bae7/buildv.sac.boptuglf.awlf.17770), [buildv.sac.boptuglf.O3.17770](/uploads/e260f0a7c68bb19297b6bff5ad38f837/buildv.sac.boptuglf.O3.17770) |
## Extended Description
<pre>Created an attachment (id=869)
source code to reproduce fault
The new LIR (Build #17770), which is quite an improvement over the old one,
still misses at least one case: A WL( A_32= iota(2000)) is not lifted
out of a Loop() function.
In apex/build/buildv.sac, this can be seen with:
sac2c buildv.sac -bopt -v1 >crud</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1872ulam.sac: BitAND' cannot be used as a binary operation2017-11-19T21:34:48ZRobert Berneckyulam.sac: BitAND' cannot be used as a binary operation| | |
| --- | --- |
| Bugzilla Link | [947](http://bugs.sac-home.org/show_bug.cgi?id=947) |
| Created on | Apr 21, 2012 21:00 |
| Resolution | FIXED |
| Resolved on | Apr 22, 2012 20:12 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [947](http://bugs.sac-home.org/show_bug.cgi?id=947) |
| Created on | Apr 21, 2012 21:00 |
| Resolution | FIXED |
| Resolved on | Apr 22, 2012 20:12 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ulam.sac](/uploads/2b5788ec28b52ce419e8146897c5cdab/ulam.sac) |
## Extended Description
<pre>Created an attachment (id=880)
source code to reproduce fault
This problem appears to have surfaced with the new parser, as it
definitely appears in Build #developer rev 17791:MODIFIED linux-gnu_x86_64
(Sat Apr 21 14:36:43 EDT 2012 by sac)
The offending code is this, in ulam.sac:
z = (rad - 1) BitAND BitShiftRight((( numpasses - 1) - pas) * radixbase, v);
BitAND is defined in stdlib:bits;
sac2c ulam.sac
is enough to bring on the complaint.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1873apex/ipbb/ipbb.sac 2X slower in Build#177852017-11-19T21:34:56ZRobert Berneckyapex/ipbb/ipbb.sac 2X slower in Build#17785| | |
| --- | --- |
| Bugzilla Link | [948](http://bugs.sac-home.org/show_bug.cgi?id=948) |
| Created on | Apr 25, 2012 16:51 |
| Resolution | FIXED |
| Resolved on | May 04, 2012 15:31 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [948](http://bugs.sac-home.org/show_bug.cgi?id=948) |
| Created on | Apr 25, 2012 16:51 |
| Resolution | FIXED |
| Resolved on | May 04, 2012 15:31 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbb.sac](/uploads/06817b65ec7780d2774a617379eacdeb/ipbb.sac), [fix948-wlir-assert.patch](/uploads/debff8fdb2459453a21d93febf649cb0/fix948-wlir-assert.patch) |
## Extended Description
<pre>Created an attachment (id=883)
source code to reproduce fault
One of the apex benchmarks started running 2X slower, as of Build #17785.
(Build # at end of Executable name):
Executable: /home/apex/apex3/benchmks/ipbb/crud.sac.exe.awlf.17785
Instructions Completed ....................... 80331925
Executable: /home/apex/apex3/benchmks/ipbb/crud.sac.exe.awlf.17784
Instructions Completed ....................... 48596540
This with sac2c -v1 -doawlf -nowlf ipbb.sac
However, sac2c -v1 ipbb.sac runs twice as fast, so the problem
likely is in either to algebraic_wlfi.c or constraint-related
code.
svn log -r17785 -v
------------------------------------------------------------------------
r17785 | jsa | 2012-04-16 08:25:58 -0400 (Mon, 16 Apr 2012) | 8 lines
Changed paths:
M /trunk/src/libsac2c/arrayopt/algebraic_wlfi.c
M /trunk/src/libsac2c/global/phase_sac2c.mac
M /trunk/src/libsac2c/stdopt/SSALIR.c
M /trunk/src/libsac2c/stdopt/loop_invariant_removal.c
M /trunk/src/libsac2c/stdopt/optimize.mac
M /trunk/src/libsac2c/stdopt/withloop_invariant_removal.c
M /trunk/src/libsac2c/stdopt/withloop_invariant_removal.h
Separate DLIR and WLIR opts. from the SSALIR module
WLIR = With-Loop Invariant Removal, in withloop_invariant_removal.c
DLIR = Do-Loop Inv.Rem., in loop_invariant_removal.c
The file SSALIR.c is obsolete now.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1874-v0 produces non-essential output2017-11-19T21:35:02ZFrank Penczek-v0 produces non-essential output| | |
| --- | --- |
| Bugzilla Link | [950](http://bugs.sac-home.org/show_bug.cgi?id=950) |
| Created on | May 02, 2012 13:44 |
| Resolution | FIXED |
| Resolved on | Jun 03, 2012 13:41 |
| Version | svn |
| OS | All |
| Architecture |...| | |
| --- | --- |
| Bugzilla Link | [950](http://bugs.sac-home.org/show_bug.cgi?id=950) |
| Created on | May 02, 2012 13:44 |
| Resolution | FIXED |
| Resolved on | Jun 03, 2012 13:41 |
| Version | svn |
| OS | All |
| Architecture | All |
## Extended Description
<pre>sac2c rev. 17798
Admittedly a minor issue: when called with "-v0" the compiler still prints "note: finished parsing."</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1875Parser failure on CF unit test2017-11-19T21:35:09ZRobert BerneckyParser failure on CF unit test| | |
| --- | --- |
| Bugzilla Link | [959](http://bugs.sac-home.org/show_bug.cgi?id=959) |
| Created on | May 31, 2012 18:56 |
| Resolution | FIXED |
| Resolved on | Jun 18, 2012 14:36 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [959](http://bugs.sac-home.org/show_bug.cgi?id=959) |
| Created on | May 31, 2012 18:56 |
| Resolution | FIXED |
| Resolved on | Jun 18, 2012 14:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCCFprf_modarray4ivecyc.sac](/uploads/b82afae0d8563c29b6f8ef1a82ec5023/SCCFprf_modarray4ivecyc.sac) |
## Extended Description
<pre>Created an attachment (id=890)
source code to reproduce fault
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17855:17856:MODIFIED linux-gnu_x86_64
(Thu May 31 13:45:30 EDT 2012 by sac)
sac@rattler:~/sac/testsuite/optimizations/constantfolding$ sac2c -noopt SCCFprf_modarray4ivecyc.sac -v4
WARNING: With-Loop unrolling (WLUR) was disabled using the command line.
WARNING: However, unrolling of single-trip with-loops is required for code
WARNING: generation. Therefore, WLUR will be re-enabled with the maximum
WARNING: number of unrolling steps set to 1.
** 1: Loading SAC program ...
**** Locating source code ...
Reading from file "./SCCFprf_modarray4ivecyc.sac" ...
**** Running C preprocessor ...
**** Parsing input file ...
./SCCFprf_modarray4ivecyc.sac error:19:5: invalid function name `!'
ABORT: Failed to construct a syntax tree for `SCCFprf_modarray4ivecyc.sac'
Failing code attached.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1876sac2c fails to compile because of error in phase_sac2c.mac2017-11-19T21:35:15ZFrank Penczeksac2c fails to compile because of error in phase_sac2c.mac| | |
| --- | --- |
| Bugzilla Link | [961](http://bugs.sac-home.org/show_bug.cgi?id=961) |
| Created on | Jun 01, 2012 17:37 |
| Resolution | FIXED |
| Resolved on | Jun 01, 2012 17:57 |
| Version | svn |
| OS | All |
| Architecture |...| | |
| --- | --- |
| Bugzilla Link | [961](http://bugs.sac-home.org/show_bug.cgi?id=961) |
| Created on | Jun 01, 2012 17:37 |
| Resolution | FIXED |
| Resolved on | Jun 01, 2012 17:57 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>rev. 17857
Compilation of sac2c fails with this error:
[...]
Compiling developer code: phase_drivers.c
In file included from global/phase_drivers.c:39:
global/phase_sac2c.mac: In function ‘PHDdriveCycleFun_saacyc’:
global/phase_sac2c.mac:1101: error: ‘optimize_flags_t’ has no member named ‘dopetl’
make[2]: *** [global/phase_drivers.d.o] Error 1
make[1]: *** [make_devel] Error 2
make: *** [default] Error 2</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1877CWLE fails to find copy-WL when -ecc/-check c/-doawlf enabled2017-11-19T21:35:21ZRobert BerneckyCWLE fails to find copy-WL when -ecc/-check c/-doawlf enabled| | |
| --- | --- |
| Bugzilla Link | [963](http://bugs.sac-home.org/show_bug.cgi?id=963) |
| Created on | Jun 01, 2012 20:02 |
| Resolution | FIXED |
| Resolved on | Jun 07, 2012 19:44 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [963](http://bugs.sac-home.org/show_bug.cgi?id=963) |
| Created on | Jun 01, 2012 20:02 |
| Resolution | FIXED |
| Resolved on | Jun 07, 2012 19:44 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug870.sac](/uploads/b741c551611c461f8722422c904f7a9b/bug870.sac) |
## Extended Description
<pre>Created an attachment (id=891)
source code to reproduce fault
Build #17858 fails here:
sac2c bug870.sac -bopt:uglf -v1 -#d,CWLE -doawlf -nowlf
This is apex benchmark gewlfAKD.sac in disguise. It runs 3X slower
than if compiled with -dowlf -noawlf</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1878TC does not simplify AKV expression in CONDFUN in PETL unit test condfun.sac2017-11-19T21:35:27ZRobert BerneckyTC does not simplify AKV expression in CONDFUN in PETL unit test condfun.sac| | |
| --- | --- |
| Bugzilla Link | [966](http://bugs.sac-home.org/show_bug.cgi?id=966) |
| Created on | Jun 03, 2012 15:03 |
| Resolution | FIXED |
| Resolved on | Jun 03, 2012 22:08 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [966](http://bugs.sac-home.org/show_bug.cgi?id=966) |
| Created on | Jun 03, 2012 15:03 |
| Resolution | FIXED |
| Resolved on | Jun 03, 2012 22:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I have this PETL unit test:
bool[*] cond( bool[*] y)
{
z = false;
if( y) {
z = true;
}
return(z);
}
int[*] akd( int[*] y)
{ return(y);
}
int main ()
{
rep = akd( 25);
rep = _max_SxS_( rep, 42);
if( cond(true)) {
z = _gt_SxS_( rep, 25);
} else {
z = false;
}
z = _toi_S_(z);
z = _sub_SxS_( z, 1);
return(z);
}
My expectation is that, within the COND_0 function's TRUE leg, that we
would eliminate the _gt_SxS_() because, with PETL, we know that rep has
a value of of at least 42.
However, what I see after several rounds of this:
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17861 linux-gnu_x86_64
(Sat Jun 2 17:16:14 EDT 2012 by sac)
sac@rattler:~/sac/testsuite/optimizations/petl$ sac2c condfun.sac -doawlf -nowlf -dopetl -doedfa-v1 -bopt:saacyc:etv:3 > lof3
is this, within the CONDFUN:
bool _MAIN::main__Cond_1( int{42} _petl_744_rep__SSA0_1 { dim: 0, shape: [:int],NN } , int rep { dim: 0, shape: [:int],NN, minval: _petl_744_rep__SSA0_1 } , bool _flat_2 { dim: 0, shape: [:int],NN } )
/*
* main__Cond_1 :: ---
*/
{
int _ivexp_1865 { , NN } ;
int{-25} _esd_461 { dim: 0, shape: [:int], NN } ;
int _ctz_458 { dim: 0, shape: [:int], YN, minval: _ivexp_1865 } ;
int{0} _ctz_459 { dim: 0, shape: [:int], NN } ;
bool z__SSA0_2 { dim: 0, shape: [:int], NN } ;
bool{0} z__SSA0_1 { dim: 0, shape: [:int], NN } ;
bool z { dim: 0, shape: [:int], NN } ;
if (_flat_2)
{
_esd_461 = -25;
_ivexp_1865 = _add_SxS_( _petl_744_rep__SSA0_1, _esd_461);
_ctz_458 = _add_SxS_( rep, _esd_461);
_ctz_459 = 0;
z = _gt_SxS_( _ctz_458, _ctz_459);
...
The computation of _ivexp_1865 is on AKV arguments, but TC is
not seeing that, apparently, as the result is AKS.
What's up?</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1879Guarded AS code broken on matmul() and other benchmarks2017-11-19T21:35:38ZRobert BerneckyGuarded AS code broken on matmul() and other benchmarks| | |
| --- | --- |
| Bugzilla Link | [969](http://bugs.sac-home.org/show_bug.cgi?id=969) |
| Created on | Jun 04, 2012 14:13 |
| Resolution | FIXED |
| Resolved on | Jun 18, 2012 13:52 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [969](http://bugs.sac-home.org/show_bug.cgi?id=969) |
| Created on | Jun 04, 2012 14:13 |
| Resolution | FIXED |
| Resolved on | Jun 18, 2012 13:52 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [cfbug.sac](/uploads/3e1f8014afd5e8c71069239f25cc3d38/cfbug.sac), [bodomatmulbug2AKD.sac](/uploads/4acf568ac01bea6137076c206f418e62/bodomatmulbug2AKD.sac) |
## Extended Description
<pre>Created an attachment (id=894)
source code to reproduce fault
I have not looked into this closely, but observe the following:
Applying associative law ...
stdopt/associative_law.c:908 Assertion "exprs != NULL" failed!
Syntax tree broken: Left hand side of prf guard application must be longer than argument list
sac@rattler:~/sac/testsuite/optimizations/awlf$ sac2c bodomatmulbug2AKD.sac -v4 -doawlf -nopetl -noedfa
The latter two opts were disabled in the interest of fault isolation.
If I compile with -noawlf, the compile goes OK, so the problem
may lie in AWLF, in which case it's my doing, most likely.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1880CTZ does not maintain optimization counter2017-11-19T21:35:44ZRobert BerneckyCTZ does not maintain optimization counter| | |
| --- | --- |
| Bugzilla Link | [970](http://bugs.sac-home.org/show_bug.cgi?id=970) |
| Created on | Jun 04, 2012 21:05 |
| Resolution | FIXED |
| Resolved on | Jun 07, 2012 19:45 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [970](http://bugs.sac-home.org/show_bug.cgi?id=970) |
| Created on | Jun 04, 2012 21:05 |
| Resolution | FIXED |
| Resolved on | Jun 07, 2012 19:45 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
Hence, it may do something, but because the optimization
counter is not incremented, phase.c will not run any further
optimizations on the updated function.
I'll fix it. I have to work in that area anyway.BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1881CSE breakage handling N_return statement in bugidxshapesel.sac CF unit test2017-11-19T21:35:49ZRobert BerneckyCSE breakage handling N_return statement in bugidxshapesel.sac CF unit test| | |
| --- | --- |
| Bugzilla Link | [980](http://bugs.sac-home.org/show_bug.cgi?id=980) |
| Created on | Jun 18, 2012 21:35 |
| Resolution | FIXED |
| Resolved on | Jul 07, 2012 22:17 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [980](http://bugs.sac-home.org/show_bug.cgi?id=980) |
| Created on | Jun 18, 2012 21:35 |
| Resolution | FIXED |
| Resolved on | Jul 07, 2012 22:17 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Starting program: /home/sac/bin/sac2c bugidxshapesel.sac -nopetl -doawlf -nowlf -v1
WARNING: AWLF is enabled: -ecc enabled.
WARNING: AWLF is enabled: -extrema enabled.
WARNING: AWLF is enabled: -maxoptcyc=20
Program received signal SIGSEGV, Segmentation fault.
0x00007ffff6c67d04 in GetApAvisOfArgAvis (return_exprs=<value optimized out>, fundef=0x1b311d8, ext_assign=<value optimized out>) at stdopt/SSACSE.c:730
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17934:MODIFIED linux-gnu_x86_64
(Mon Jun 18 16:22:11 EDT 2012 by sac)
This fault occurs in the constantfolding unit test suite with the above
options. The -nopetl does not appear to be related to the failure.
I am not sure if this is a DevCamp-related failure or not, but I did
not observe that failure last week.
I hope someone at DevCamp will undertake to reproduce & isolate the fault
on one your systems there.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1882CTZ generates vector int[3] N_type for scalar 02017-11-19T21:35:55ZRobert BerneckyCTZ generates vector int[3] N_type for scalar 0| | |
| --- | --- |
| Bugzilla Link | [981](http://bugs.sac-home.org/show_bug.cgi?id=981) |
| Created on | Jun 18, 2012 21:53 |
| Resolution | FIXED |
| Resolved on | Jun 22, 2012 18:00 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [981](http://bugs.sac-home.org/show_bug.cgi?id=981) |
| Created on | Jun 18, 2012 21:53 |
| Resolution | FIXED |
| Resolved on | Jun 22, 2012 18:00 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This compiles with an ntype of int[3] for the scalar 0:
int[3] _ctz_2959 { , NN } ;
int[3] _ctz_2960 { , NN } ;
...
_flat_1100 = _shape_A_( arr_a);
_esd_2964 = [ -3, -3, -4 ];
_ctz_2959 = _add_VxV_( _flat_1100, _esd_2964);
_ctz_2960 = 0;
_flat_1099 = _eq_VxS_( _ctz_2959, _ctz_2960);
cd sac/testsuite/optimizations/constantfolding
sac2c -v1 bug652.breaks.sac -nopetl -nols
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17934:MODIFIED linux-gnu_x86_64
(Mon Jun 18 16:22:11 EDT 2012 by sac)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1883stdlib: UTrace.sac compile crashes in code generation phase2017-11-19T21:36:00ZRobert Berneckystdlib: UTrace.sac compile crashes in code generation phase| | |
| --- | --- |
| Bugzilla Link | [982](http://bugs.sac-home.org/show_bug.cgi?id=982) |
| Created on | Jun 19, 2012 14:06 |
| Resolution | FIXED |
| Resolved on | Jun 21, 2012 20:07 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [982](http://bugs.sac-home.org/show_bug.cgi?id=982) |
| Created on | Jun 19, 2012 14:06 |
| Resolution | FIXED |
| Resolved on | Jun 21, 2012 20:07 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>** 20: Generating Code ...
**** Tag preparation ...
**** Converting to old type representation ...
**** Creating intermediate code macros ...
ABORT: line 224 file: ArrayArith.sac
ABORT: cannot infer default element for with-loop
*** Compilation failed ***
*** Exit code 362 (Generating Code)
*** 1 Error(s), 0 Warning(s)
sac@localhost:~/sac/BASE/stdlib/utrace$ sac2c UTrace.sac -v4 -g -linksetsize 0 -o lib -mt -O3
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 17939:17940:MODIFIED linux-gnu_x86_64
(Tue Jun 19 08:29:44 EDT 2012 by sac)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1884Inlining loses guard-generated extrema2017-11-19T21:36:06ZRobert BerneckyInlining loses guard-generated extrema| | |
| --- | --- |
| Bugzilla Link | [990](http://bugs.sac-home.org/show_bug.cgi?id=990) |
| Created on | Jul 06, 2012 22:21 |
| Resolution | FIXED |
| Resolved on | Jul 07, 2012 10:40 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [990](http://bugs.sac-home.org/show_bug.cgi?id=990) |
| Created on | Jul 06, 2012 22:21 |
| Resolution | FIXED |
| Resolved on | Jul 07, 2012 10:40 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bugxxx.sac](/uploads/ff31ad7f2a3d764ef509268824c00217/bugxxx.sac) |
## Extended Description
<pre>Created an attachment (id=905)
source code to reproduce fault
Guards are introduced very early in the compilation process, and AWLF/CF
use the extrema information they provide to drive certain optimizations.
In the AWLF unit test suite, bugxxx.sac provides a good test case.
After -bopt:cwc:dcr, we have this iota():
inline
int[.] ArrayBasics::iota( int shp { ,NN } )
/*
* iota :: ---
*/
{
int[.] res { , NN } ;
int i { , NN } ;
int[1] _flat_115 { , NN } ;
int[1] _flat_109 { , NN } ;
int{0} _flat_110 { , NN } ;
int[1] _flat_111 { , NN } ;
int{0} _flat_112 { , NN } ;
int[1] _flat_113 { , NN } ;
int[1] _flat_114 { , NN } ;
_flat_114 = [ shp ];
_flat_113 = [ shp ];
_flat_112 = 0;
_flat_111 = _mul_SxV_( _flat_112, _flat_113);
_flat_110 = 0;
_flat_109 = [ shp ];
res = with {
(_flat_111 <= _flat_115=[i] < _flat_114)
{
} : i ;
} :
genarray( _flat_109, _flat_110);
return( res);
}
The next traversal inserts guards, and we end up with:
_flat_114 = [ shp ];
_idc_383, _icc_375_pred = _non_neg_val_V_( _flat_114);
_flat_113 = [ shp ];
_flat_112 = 0;
_flat_111 = _mul_SxV_( _flat_112, _flat_113);
_idc_384, _icc_374_pred = _non_neg_val_V_( _flat_111);
_flat_110 = 0;
_flat_109 = [ shp ];
_idc_385, _idc_386, _icc_376_pred = _same_shape_AxA_( _idc_384, _flat_109);
_idc_387, _icc_377_pred = _val_le_val_VxV_( _idc_385, _idc_386);
_idc_388, _idc_389, _icc_378_pred = _same_shape_AxA_( _idc_383, _idc_386);
_idc_390, _icc_379_pred = _val_le_val_VxV_( _idc_388, _idc_389);
_idc_391, _icc_380_pred = _non_neg_val_V_( _idc_389);
_icc_382 = with {
(_idc_387 <= _flat_115=[i] < _idc_390)
{
_idc_392, _idc_393, _icc_381_pred = _same_shape_AxA_( i, _flat_110);
} : _idc_392 ;
} :
genarray( _idc_391, _flat_110);
res = _afterguard_( _icc_382, _icc_380_pred, _icc_379_pred, _icc_378_pred, _icc_377_pred, _icc_376_pred, _icc_375_pred, _icc_374_pred);
return( res);
}
That explains how values such as "shp" appear to be creeping above
their guarded values.
What is odd is that CSE has not done its job. Perhaps the fact
that iota() lives in stdlib is related to this problem?</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1885UTCompress.sac crash in WLSBwith2017-11-19T21:36:13ZRobert BerneckyUTCompress.sac crash in WLSBwith| | |
| --- | --- |
| Bugzilla Link | [997](http://bugs.sac-home.org/show_bug.cgi?id=997) |
| Created on | Jul 09, 2012 15:59 |
| Resolution | FIXED |
| Resolved on | Nov 15, 2012 21:08 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [997](http://bugs.sac-home.org/show_bug.cgi?id=997) |
| Created on | Jul 09, 2012 15:59 |
| Resolution | FIXED |
| Resolved on | Nov 15, 2012 21:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTCompress.sac](/uploads/ecfe01c309a7e53dac096012f6ca1762/UTCompress.sac) |
## Extended Description
<pre>Created an attachment (id=910)
source code to reproduce fault
Applying with-loop scalarization ...
tree/traverse.c:67 Assertion "arg_node" failed!
OOOOOOOPS: TRAVdo() called with a NULL node!
apex@rattler:~/apex3/benchmks/UTCompress$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18052:MODIFIED linux-gnu_x86_64
(Mon Jul 9 09:52:52 EDT 2012 by sac)
apex@rattler:~/apex3/benchmks/UTCompress$ sac2c UTCompress.sac -v4
We crash in WLSBwith, looking at this rather sad WL:
with
genarray( [ 0 ])
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18052:MODIFIED linux-gnu_x86_64
(Mon Jul 9 09:52:52 EDT 2012 by sac)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1886AWLFI crashes on Morgan-Stanley benchmark, unable to find inverse function2017-11-19T21:36:19ZRobert BerneckyAWLFI crashes on Morgan-Stanley benchmark, unable to find inverse function| | |
| --- | --- |
| Bugzilla Link | [1000](http://bugs.sac-home.org/show_bug.cgi?id=1000) |
| Created on | Jul 09, 2012 16:15 |
| Resolution | FIXED |
| Resolved on | Jul 09, 2012 20:14 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1000](http://bugs.sac-home.org/show_bug.cgi?id=1000) |
| Created on | Jul 09, 2012 16:15 |
| Resolution | FIXED |
| Resolved on | Jul 09, 2012 20:14 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [morgan.sac](/uploads/78d847447b09600d0576429cbeea0182/morgan.sac), [crud.breaks.sac](/uploads/067d34399e248561a44be35f4e7a8db7/crud.breaks.sac) |
## Extended Description
<pre>Created an attachment (id=913)
source code to reproduce fault
Inferring algebraically foldable with-loops ...
arrayopt/algebraic_wlfi.c:975 Assertion "( NULL == z) || N_avis == NODE_TYPE( z)" failed!
failed to gen inverse
apex@rattler:~/apex3/benchmks/morgan$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18052:MODIFIED linux-gnu_x86_64
(Mon Jul 9 09:52:52 EDT 2012 by sac)
apex@rattler:~/apex3/benchmks/morgan$ sac2c morgan.sac -v4 -doawlf -nowlf</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1887Hui scheduler benchmark schedr.sac has undefined AVIS_SHAPE in loopfun2017-11-19T21:36:26ZRobert BerneckyHui scheduler benchmark schedr.sac has undefined AVIS_SHAPE in loopfun| | |
| --- | --- |
| Bugzilla Link | [1004](http://bugs.sac-home.org/show_bug.cgi?id=1004) |
| Created on | Jul 13, 2012 22:05 |
| Resolution | FIXED |
| Resolved on | Aug 07, 2012 23:26 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1004](http://bugs.sac-home.org/show_bug.cgi?id=1004) |
| Created on | Jul 13, 2012 22:05 |
| Resolution | FIXED |
| Resolved on | Aug 07, 2012 23:26 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [schedr.sac](/uploads/9bd9a4d77210a0d494a1d4adab432604/schedr.sac) |
## Extended Description
<pre>Created an attachment (id=917)
source code to reproduce fault
This one took a lot of digging to isolate, and I'm still not done...
**** Final round of constant folding ...
-> Running syntax tree checks
**** Generating full with-loop partitions ...
-> Running syntax tree checks
**** Inferencing with-loop reuse candidates ...
tree/DataFlowMask.c:1147 Assertion "i<mask->mask_base->num_ids" failed!
Identifier not present in mask: _dl_35688
apex@rattler:~/apex3/benchmks/schedr$ sac2c schedr.sac -v4 -doawlf -nowlf -d treecheck -chkfreq 4
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18066 linux-gnu_x86_64
(Thu Jul 12 16:08:09 EDT 2012 by sac)
The problem lies elsewhere: _dl_35688 is defined outside a LOOPFUN,
but is referenced inside it.
The real problem is that AWLF has converted a modarray-WL into
a genarray-WL in the course of doing its job, but the AVIS_SHAPE
value that it uses is undefined in the loop function.
More to come...</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1888CHK of FUNDEF_RETURN code faulty2017-11-19T21:36:32ZRobert BerneckyCHK of FUNDEF_RETURN code faulty| | |
| --- | --- |
| Bugzilla Link | [1018](http://bugs.sac-home.org/show_bug.cgi?id=1018) |
| Created on | Aug 29, 2012 16:47 |
| Resolution | FIXED |
| Resolved on | Aug 31, 2012 22:59 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1018](http://bugs.sac-home.org/show_bug.cgi?id=1018) |
| Created on | Aug 29, 2012 16:47 |
| Resolution | FIXED |
| Resolved on | Aug 31, 2012 22:59 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I recently introduced CHK code to vet FUNDEF_RETURN, but it has a flaw:
* 17: Converting from static single assignment form ...
**** Converting from SSA form ...
-> Running syntax tree checks
**** Reintroducing loops and conditionals ...
-> Running syntax tree checks
TRAVERSE ERROR: node of type 59810128:!invalid! found where 26:N_ap was expected!
The problem here is that FUNDEF_RETURN is no longer valid
once we no longer have loops as LACFUNS.
Similarly, it should not be valid before we have LACFUNS.
I am going to update ast.xml to reflect this situation and
will amend check_lib.c as well.
~/sac/testsuite/optimizations/constantfolding$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18189:MODIFIED linux-gnu_x86_64
(Wed Aug 29 11:33:27 EDT 2012 by sac)
sac2c bug897.sac -d treecheck -chkfreq 4 -v4
It is too bad we do not have any automated mechanism for vetting
AST attributes...</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1889LACSO/LACSI cripple DLIR removal of WL from loopfun in apex b/m downgradePV.sac2017-11-19T21:36:39ZRobert BerneckyLACSO/LACSI cripple DLIR removal of WL from loopfun in apex b/m downgradePV.sac| | |
| --- | --- |
| Bugzilla Link | [1029](http://bugs.sac-home.org/show_bug.cgi?id=1029) |
| Created on | Oct 04, 2012 23:00 |
| Resolution | FIXED |
| Resolved on | Nov 08, 2012 22:57 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1029](http://bugs.sac-home.org/show_bug.cgi?id=1029) |
| Created on | Oct 04, 2012 23:00 |
| Resolution | FIXED |
| Resolved on | Nov 08, 2012 22:57 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [upgradePV.sac](/uploads/a2bbd6079cdd1e5e157a6ba9d5523469/upgradePV.sac), [downgradePV.sac](/uploads/6ffc7c403777260533de00788b37b4a6/downgradePV.sac) |
## Extended Description
<pre>Created an attachment (id=934)
source code to reproduce fault
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 18243:MODIFIED linux-gnu_x86_64
(Thu Oct 4 15:24:40 EDT 2012 by sac)
sac2c downgradePV.sac -v1 -O3 -dolacsi -dolacso -bopt >crud
shows a loop-invariant WL sitting quietly inside the loopfun,
making the whole shebang run a brazillion times slower.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1890make sac2c no longer provides revision level information2017-11-19T21:36:44ZRobert Berneckymake sac2c no longer provides revision level information| | |
| --- | --- |
| Bugzilla Link | [1031](http://bugs.sac-home.org/show_bug.cgi?id=1031) |
| Created on | Nov 03, 2012 21:15 |
| Resolution | FIXED |
| Resolved on | Nov 12, 2012 11:04 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1031](http://bugs.sac-home.org/show_bug.cgi?id=1031) |
| Created on | Nov 03, 2012 21:15 |
| Resolution | FIXED |
| Resolved on | Nov 12, 2012 11:04 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I just got the git stuff on my development box here, compiled
everything with no apparent problems, but it appears we have
lost the revision information in the -V data:
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev exported linux-gnu_x86_64
(Sat Nov 3 16:33:30 EDT 2012 by sac)
This is crucial information for tracking bugs, etc., so please
fix it asap.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1891stdlib make loses track of already-made items2017-11-19T21:36:50ZRobert Berneckystdlib make loses track of already-made items| | |
| --- | --- |
| Bugzilla Link | [1033](http://bugs.sac-home.org/show_bug.cgi?id=1033) |
| Created on | Nov 06, 2012 16:22 |
| Resolution | FIXED |
| Resolved on | Jul 10, 2014 23:41 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1033](http://bugs.sac-home.org/show_bug.cgi?id=1033) |
| Created on | Nov 06, 2012 16:22 |
| Resolution | FIXED |
| Resolved on | Jul 10, 2014 23:41 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I just ran a "make -j6 mtfast", which eventually crashed making ArrayFormat.sac.
When I restarted the make, it rebuilt all the object files that had already
been built. Perhaps this has something to do with the move to git?
I.e.:
make -j6 mtfast
make -f buildfile "MTSAC2CFLAGS=-mt " MODE=fat
Module JPEG cannot be built because libjpeg was not found
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt ScalarArith.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Bool.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Constants.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Bits.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt List.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt World.sac -o lib
cd modules/numerical/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt SaCMath.sac -o lib
cd modules/auxiliary/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Interval.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt RTClock.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt TimeStamp.sac -o lib
cd classes/random/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Rand48.sac -o lib
cd classes/random/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Rand.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Terminal.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt RTimer.sac -o lib
cd modules/numerical/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt FixedPoint.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt ArrayBasics.sac -o lib
cd modules/numerical/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Math.sac -o lib
cd classes/auxiliary/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Counter.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt ArrayArith.sac -o lib
cd modules/numerical/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt MathArray.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Char.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt ComplexBasics.sac -o lib
cd classes/random/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt RandLC.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt String.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt ComplexScalarArith.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt ComplexArrayBasics.sac -o lib
cd modules/numerical/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt ComplexMath.sac -o lib
cd modules/numerical/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Numerical.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt RuntimeError.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt SysErr.sac -o lib
cd world/stdio/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt TermFile.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Clock.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt CommandLine.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Environment.sac -o lib
cd world/stdio/dislin/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt DislinPage.sac -o lib
cd world/stdio/gnuplot/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt GnuPlotSystem.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt FileSystem.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt GetOpt.sac -o lib
cd world/stdio/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt File.sac -o lib
cd world/stdio/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt BinFile.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Dir.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt System.sac -o lib
cd world/stdio/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt IOresources.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Process.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt ArrayTransform.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Array.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt ComplexArrayArith.sac -o lib
cd world/stdio/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt PGM.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt ArrayFormat.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Color8.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Grey.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt StringArray.sac -o lib
cd modules/numerical/blas/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt BlasLevel1.sac -o lib
cd modules/numerical/blas/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt SacBlasLevel1.sac -o lib
cd modules/auxiliary/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Hiding.sac -o lib
cd world/stdio/dislin/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt DislinSystem.sac -o lib
OOOOOOOPS, your program crashed the compiler 8-((
Please, send a bug report to bugs@sac-home.org,
or file a bug in the SaC-Zilla bug management system.
For your convenience, the compiler has pre-fabricated a bug report
in the file "./ArrayFormat.sacbugreport" !
Besides some infos concerning the compiler version and its
usage it contains the specified source file.
If you want to send that bug report to us, you may simply type
mail bugs@sac-home.org < ArrayFormat.sacbugreport
If you decide to file a bug in SaC-Zilla, please go to
http://bugs.sac-home.org/.
When filing a bug report, please copy/paste the initial comment section of
the bug report into the plain text comment section of SaC-Zilla, and add
the whole bug report file as an attachment.
Aborted
make[1]: *** [modules/structures/lib/libArrayFormatTree@SHARED_LIB_EXT@] Error 134
make[1]: *** Waiting for unfinished jobs....
make: *** [mtfast] Error 2
sac@rattler:~/sac/BASE/stdlib$ make -j6 mtfast
make -f buildfile "MTSAC2CFLAGS=-mt " MODE=fat
Module JPEG cannot be built because libjpeg was not found
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt ScalarArith.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Bool.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Constants.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Bits.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt List.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt World.sac -o lib
cd modules/numerical/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt SaCMath.sac -o lib
cd modules/auxiliary/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Interval.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt RTClock.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt TimeStamp.sac -o lib
cd classes/random/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Rand48.sac -o lib
cd classes/random/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Rand.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Terminal.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt RTimer.sac -o lib
cd modules/numerical/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt FixedPoint.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt ArrayBasics.sac -o lib
cd modules/numerical/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Math.sac -o lib
cd classes/auxiliary/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Counter.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt ArrayArith.sac -o lib
cd modules/numerical/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt MathArray.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Char.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt ComplexBasics.sac -o lib
cd classes/random/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt RandLC.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt String.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt ComplexScalarArith.sac -o lib
cd modules/structures/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt ComplexArrayBasics.sac -o lib
cd modules/numerical/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt ComplexMath.sac -o lib
cd modules/numerical/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Numerical.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt RuntimeError.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt SysErr.sac -o lib
cd world/stdio/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt TermFile.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Clock.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt CommandLine.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Environment.sac -o lib
cd world/stdio/dislin/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt DislinPage.sac -o lib
cd world/stdio/gnuplot/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt GnuPlotSystem.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt FileSystem.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt GetOpt.sac -o lib
cd world/stdio/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt File.sac -o lib
cd world/stdio/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt BinFile.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Dir.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt System.sac -o lib
cd world/stdio/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt IOresources.sac -o lib
cd world/system/lib/..; sac2c -v0 -g -O3 -linksetsize 0 -mt Process.sac -o lib
...
Customary sac2c-V, even though it is currently useless:
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev exported linux-gnu_x86_64
(Mon Nov 5 16:28:13 EST 2012 by sac)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1892sac2c doesn't know beans from scientific notation2017-11-19T21:36:55ZRobert Berneckysac2c doesn't know beans from scientific notation| | |
| --- | --- |
| Bugzilla Link | [1064](http://bugs.sac-home.org/show_bug.cgi?id=1064) |
| Created on | Apr 19, 2013 21:05 |
| Resolution | FIXED |
| Resolved on | Jul 11, 2014 08:45 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1064](http://bugs.sac-home.org/show_bug.cgi?id=1064) |
| Created on | Apr 19, 2013 21:05 |
| Resolution | FIXED |
| Resolved on | Jul 11, 2014 08:45 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>int main()
{
A = iota( 1000000);
B = iota( 1e6);
StdIO::print( shape( A));
StdIO::print( shape( B));
return( 0);
}
This prints the following, when compiled:
sac2c crud2.sac -v1
sac@rattler:~/sac/demos/benchmarks/livermore_loops/for_comparison/loop15$ a.out
Dimension: 1
Shape : < 1>
<1000000 >
Dimension: 1
Shape : < 1>
< 1 >
sac@rattler:~/sac/demos/benchmarks/livermore_loops/for_comparison/loop15$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18093 linux-gnu_x86_64
(Fri Apr 19 15:27:48 EDT 2013 by sac)
I consider the second result to be incorrect.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1893WLPROP introduces dead CONDFUNs2017-11-19T21:37:01ZRobert BerneckyWLPROP introduces dead CONDFUNs| | |
| --- | --- |
| Bugzilla Link | [1065](http://bugs.sac-home.org/show_bug.cgi?id=1065) |
| Created on | Apr 19, 2013 21:11 |
| Resolution | FIXED |
| Resolved on | May 19, 2013 22:06 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1065](http://bugs.sac-home.org/show_bug.cgi?id=1065) |
| Created on | Apr 19, 2013 21:11 |
| Resolution | FIXED |
| Resolved on | May 19, 2013 22:06 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I am not sure if this is intentional behavior, or if it's entirely
wrong. WLPROP generates new COND_FUNs, leaving the old one in the syntax
tree, bereft of any callers.
This makes the syntax tree grow. And grow. And grow.
What I see happening is that we have the following calling tree:
main() -> Loop() -> Cond()
GLF is putting Cond() onto FUNDEF_NEXT( Loop), rather than
on FUNDEF_NEXT( main).
Not what we were hoping for. Likely a day-0 bug in GLF.
A typical failing example is the LACS unit test bugipbb.sac,
but I'll bet they all do this.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1894Code generator fails to generate guard code for AL unit test guardSimple.sac2017-11-19T21:37:07ZRobert BerneckyCode generator fails to generate guard code for AL unit test guardSimple.sac| | |
| --- | --- |
| Bugzilla Link | [1071](http://bugs.sac-home.org/show_bug.cgi?id=1071) |
| Created on | Apr 27, 2013 20:42 |
| Resolution | FIXED |
| Resolved on | Oct 01, 2013 20:21 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1071](http://bugs.sac-home.org/show_bug.cgi?id=1071) |
| Created on | Apr 27, 2013 20:42 |
| Resolution | FIXED |
| Resolved on | Oct 01, 2013 20:21 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The following program dies in alloc.c when compiled with no options:
int main()
{
v1 = id( [ 42]);
gV, p2 = _non_neg_val_V_( v1);
gS = _sel_VxA_( [0], gV);
z = _sub_SxS_(gS , 42);
return( z);
}
int[*] id( int[*] y)
{
return(y);
}
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18120 linux-gnu_x86_64
(Sat Apr 27 15:38:47 EDT 2013 by sac)
Failure mode:
** 16: Introducing memory management instructions ...
**** Unshare index vectors in WL-folds ...
**** Propagating constants ...
**** AUD/SCL distinction ...
**** Making copy operations explicit ...
**** Introducing explicit allocation statements ...
memory/alloc.c:308 Assertion "als->dim != NULL" failed!
alloc requires a dim expression!
If someone can tell me how to write an alloc.c thingy for
a function that has two results, I'll fix it.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1895-bopt:scc corrupts predicates for some guards2017-11-19T21:37:12ZRobert Bernecky-bopt:scc corrupts predicates for some guards| | |
| --- | --- |
| Bugzilla Link | [1074](http://bugs.sac-home.org/show_bug.cgi?id=1074) |
| Created on | May 01, 2013 19:48 |
| Resolution | FIXED |
| Resolved on | May 01, 2013 19:55 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1074](http://bugs.sac-home.org/show_bug.cgi?id=1074) |
| Created on | May 01, 2013 19:48 |
| Resolution | FIXED |
| Resolved on | May 01, 2013 19:55 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>If you compile with -ecc (this does not apply to -check c, because
SCC doesn't run then...), guard removal for some guards sets
the result predicate variable to PRF_ARG2, rather than to TRUE.
This is generally a bad idea, especially since PRF_ARG2 is usually
integer and the predicate is Boolean.
Fix underway.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 18126 linux-gnu_x86_64
(Wed May 1 14:40:08 EDT 2013 by sac)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1896WLF crashes: SSAWLI thinks a WL generator is AKV, but SSAWithloopFolding does...2017-11-19T21:37:18ZRobert BerneckyWLF crashes: SSAWLI thinks a WL generator is AKV, but SSAWithloopFolding does not| | |
| --- | --- |
| Bugzilla Link | [1075](http://bugs.sac-home.org/show_bug.cgi?id=1075) |
| Created on | May 02, 2013 18:50 |
| Resolution | FIXED |
| Resolved on | May 02, 2013 19:07 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1075](http://bugs.sac-home.org/show_bug.cgi?id=1075) |
| Created on | May 02, 2013 18:50 |
| Resolution | FIXED |
| Resolved on | May 02, 2013 19:07 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [twopartoffsetWL.sac](/uploads/a91588050ff97634cc536a929b57c821/twopartoffsetWL.sac) |
## Extended Description
<pre>Created an attachment (id=973)
source code to reproduce fault
The above arose sometime between Build #18091 and Build #18130.
I think what is going on is this:
Assume we have a generator definition such as:
B = [0];
LB = B;
Previously, when we got to WLF, LB was AKV, so WLF's use of TYisAKV( LB)
returned TRUE. I think that SSAWLI.c uses PM to decide whether to fold
or not, so it would claim that LB was (sort of) AKV.
Now, when we get to WLF, LB is AKS, because TC has not run in the interim.
Rather than go back through a bunch of old builds to see who did this
( and because it could arise otherwise, I think...), I just made the
function WLFarrayST2ArrayInt use a PM to look for the N_array it expects
to be passed.
That appears to have fixed things, but I'm going to run the AWLF unit tests
to make sure.
The current Build #18130, dies in -bopt:cyc:wlf:2, with a less-than-obvious
fault.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1897AWLF catenate() unit test gives wrong answers2017-11-19T21:37:24ZRobert BerneckyAWLF catenate() unit test gives wrong answers| | |
| --- | --- |
| Bugzilla Link | [1082](http://bugs.sac-home.org/show_bug.cgi?id=1082) |
| Created on | May 15, 2013 14:35 |
| Resolution | FIXED |
| Resolved on | May 15, 2013 19:40 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1082](http://bugs.sac-home.org/show_bug.cgi?id=1082) |
| Created on | May 15, 2013 14:35 |
| Resolution | FIXED |
| Resolved on | May 15, 2013 19:40 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug1082.sac](/uploads/753f817f2686e4a6aa84a2c034126f1b/bug1082.sac) |
## Extended Description
<pre>sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18145 linux-gnu_x86_64
(Wed May 15 09:23:39 EDT 2013 by sac)
The attached unit test, if compiled this way:
sac2c bugtuesday.sac -doawlf -nowlf -DBROKEN
produces incorrect answers.
The culprit appears to be CF, in particular,
SCCFprf_idx_modarray_AxSxS and its friends in the
indexed-assign business.
We start with an N_array of N_num (or equivalent):
arr = [ 1, 2];
and are doing:
arr[1] = flatid;
The code then replaces one element of arr by an N_id, producing a
mongrel that is partially flattened:
arr = [ 1, flatid];
This appears to bring on the fault. So, the actual
problem, I think, lies elsewhere, in code that is unable
to tolerate mongrels.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1898parser failure on roundc.sac benchmark2017-11-19T21:37:30ZRobert Berneckyparser failure on roundc.sac benchmark| | |
| --- | --- |
| Bugzilla Link | [1083](http://bugs.sac-home.org/show_bug.cgi?id=1083) |
| Created on | May 15, 2013 21:29 |
| Resolution | INVALID |
| Resolved on | Oct 24, 2013 09:25 |
| Version | svn |
| OS | Linux |
| Architec...| | |
| --- | --- |
| Bugzilla Link | [1083](http://bugs.sac-home.org/show_bug.cgi?id=1083) |
| Created on | May 15, 2013 21:29 |
| Resolution | INVALID |
| Resolved on | Oct 24, 2013 09:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/2a94d9485a55e818f9a37a50614095d4/crud.sac) |
## Extended Description
<pre>Created an attachment (id=980)
source code to reproduce fault
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 18147 linux-gnu_x86_64
(Wed May 15 15:32:16 EDT 2013 by sac)
apex@rattler:~/apex3/benchmks/roundc$ sac2c -v4 crud.sac
** 1: Loading SAC program ...
**** Locating source code ...
Reading from file "./crud.sac" ...
**** Running C preprocessor ...
**** Parsing input file ...
Segmentation fault
apex@rattler:~/apex3/benchmks/roundc$ sac2c-d -v4 crud.sac
** 1: Loading SAC program ...
**** Locating source code ...
Reading from file "./crud.sac" ...
**** Running C preprocessor ...
**** Parsing input file ...
Segmentation fault</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1899UIP produces wrong answers2017-11-19T21:37:36ZRobert BerneckyUIP produces wrong answers| | |
| --- | --- |
| Bugzilla Link | [1085](http://bugs.sac-home.org/show_bug.cgi?id=1085) |
| Created on | Sep 18, 2013 15:44 |
| Resolution | FIXED |
| Resolved on | Sep 23, 2013 20:57 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1085](http://bugs.sac-home.org/show_bug.cgi?id=1085) |
| Created on | Sep 18, 2013 15:44 |
| Resolution | FIXED |
| Resolved on | Sep 23, 2013 20:57 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [buguip.sac](/uploads/5b6e74e0a3d04bb39ea6db56ebcb0308/buguip.sac) |
## Extended Description
<pre>Created an attachment (id=983)
source code to reproduce fault
If the attached is compiled this way, it produces incorrect answers:
sac2c buguip.sac
If compiled this way, it runs correctly:
sac2c buguip.sac -nouip
I believe the problem is that UIP uses the wrong
criterion to decide whether update-in-place (RC(xxx))
can be used. Compiling with -bopt | grep RC shows
this difference.
The fault is related to multiple partitions in a single WL.
The criterion used for any partition is this:
CRIT: X[ iv] = f [ x[iv]];
That is, the modarray does not require access to any element
of X other than X[iv].
The criteria for the entire WL is:
any (CRIT)
but it should be:
all (CRIT)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1900sac2c very brokennow on Ubuntu 13.042017-11-19T21:37:42ZRobert Berneckysac2c very brokennow on Ubuntu 13.04| | |
| --- | --- |
| Bugzilla Link | [1100](http://bugs.sac-home.org/show_bug.cgi?id=1100) |
| Created on | Oct 16, 2013 13:29 |
| Resolution | FIXED |
| Resolved on | Nov 08, 2013 17:49 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1100](http://bugs.sac-home.org/show_bug.cgi?id=1100) |
| Created on | Oct 16, 2013 13:29 |
| Resolution | FIXED |
| Resolved on | Nov 08, 2013 17:49 |
| Version | svn |
| OS | Linux |
| Architecture | PC |BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1901Some bright light is denormalizing GENERATOR_BOUND22017-11-19T21:37:49ZRobert BerneckySome bright light is denormalizing GENERATOR_BOUND2| | |
| --- | --- |
| Bugzilla Link | [1101](http://bugs.sac-home.org/show_bug.cgi?id=1101) |
| Created on | Nov 08, 2013 18:51 |
| Resolution | INVALID |
| Resolved on | Nov 08, 2013 21:34 |
| Version | svn |
| OS | Linux |
| Architec...| | |
| --- | --- |
| Bugzilla Link | [1101](http://bugs.sac-home.org/show_bug.cgi?id=1101) |
| Created on | Nov 08, 2013 18:51 |
| Resolution | INVALID |
| Resolved on | Nov 08, 2013 21:34 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bugmul.sac](/uploads/25857a3f970e9811d0b5ee1acb815ccd/bugmul.sac) |
## Extended Description
<pre>Created an attachment (id=994)
source code to reproduce fault
The code in -bpre:acn turns this WL:
/****************************************************************************
* *(...) [ body ]
****************************************************************************/
inline
int[.] *( int[.] a { ,NN } , int[.] b { ,NN } )
/*
* * :: ---
*/
{
return( with {
/* Partn */
(. <= iv < .)
{
} : ( sel( iv, a) *sel( iv, b) ) ;
} :
genarray( _shape_A_( a), 0));
}
into this one:
/****************************************************************************
* *(...) [ body ]
****************************************************************************/
inline
int[.] *( int[.] a { ,NN } , int[.] b { ,NN } )
/*
* * :: ---
*/
{
return( with {
/* Partn */
(_mul_SxV_( 0, _shape_A_( a)) <= iv < _sub_VxS_( _shape_A_( a), 1))
{
} : ( sel( iv, a) *sel( iv, b) ) ;
} :
genarray( _shape_A_( a), 0));
}
Not exactly what we were hoping for. I am guessing this is another
feechur of DecCamp 2013.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1902sac2c doesn't like fold early on...2017-11-19T21:37:54ZRobert Berneckysac2c doesn't like fold early on...| | |
| --- | --- |
| Bugzilla Link | [1106](http://bugs.sac-home.org/show_bug.cgi?id=1106) |
| Created on | Dec 28, 2013 22:59 |
| Resolution | FIXED |
| Resolved on | Jan 10, 2014 19:14 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1106](http://bugs.sac-home.org/show_bug.cgi?id=1106) |
| Created on | Dec 28, 2013 22:59 |
| Resolution | FIXED |
| Resolved on | Jan 10, 2014 19:14 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18415 linux-gnu_x86_64
(Fri Dec 27 16:07:39 EST 2013 by sac)
sac@rattler:~/sac/testsuite/optimizations/awlf$ sac2c crud.sac
warning: AWLF is enabled: -ecc enabled.
warning: AWLF is enabled: -extrema enabled.
warning: AWLF is enabled: -maxoptcyc=20
** 1: Loading SAC program ...
**** Locating source code ...
Reading from file "./crud.sac" ...
**** Running C preprocessor ...
**** Parsing input file ...
** 2: Preprocessing SAC program ...
**** Hiding struct definitions behind typedefs and accessors ...
**** Handling zero-generator with-loops ...
**** Handling multi-generator with-loops ...
TRAVERSE ERROR: node of type 95:N_spid found where 72:N_spfold was expected!
------------------------------------------
cat crud.sac
int main ()
{
pwl = with {
( [ 0, 20] <= iv=[j,k] < [ 20, 40 ] ) : 42;
( [ 15, 0] <= iv=[j,k] < [ 20, 20 ] ) : 666;
( [ 0, 0 ] <= iv=[j,k] < [ 15, 20 ] ) : k;
} : fold( plus, 0);
StdIO::print( pwl);
return(0);
}
inline
int plus( int x, int y)
{
z = _add_SxS_( x, y);
return( z);
}</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1903Build #18422 IVEXP produces wrong answers for mod() & aplmod()2017-11-19T21:37:59ZRobert BerneckyBuild #18422 IVEXP produces wrong answers for mod() & aplmod()| | |
| --- | --- |
| Bugzilla Link | [1108](http://bugs.sac-home.org/show_bug.cgi?id=1108) |
| Created on | Jan 17, 2014 14:13 |
| Resolution | FIXED |
| Resolved on | Jan 17, 2014 14:18 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1108](http://bugs.sac-home.org/show_bug.cgi?id=1108) |
| Created on | Jan 17, 2014 14:13 |
| Resolution | FIXED |
| Resolved on | Jan 17, 2014 14:18 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
Summary says it all. I'm fixing it now.
stdlib::rotate() is definitely affected, at least when the array being
rotated is empty.
Relevant git number is probably
97b8984941b4d583fe091fdbd7e78e250125b8b4BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1904WLPG doesn't leave partitions in obviously contiguous order2017-11-19T21:38:05ZRobert BerneckyWLPG doesn't leave partitions in obviously contiguous order| | |
| --- | --- |
| Bugzilla Link | [1111](http://bugs.sac-home.org/show_bug.cgi?id=1111) |
| Created on | Jan 24, 2014 19:21 |
| Resolution | INVALID |
| Resolved on | Jan 24, 2014 20:18 |
| Version | svn |
| OS | Linux |
| Architec...| | |
| --- | --- |
| Bugzilla Link | [1111](http://bugs.sac-home.org/show_bug.cgi?id=1111) |
| Created on | Jan 24, 2014 19:21 |
| Resolution | INVALID |
| Resolved on | Jan 24, 2014 20:18 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I would expect that WLPG would leave partition elements in some
sort of continuous chain, such as:
p0: k1 <= iv < k2
p1 0 <= iv < k1
p2 k2 <= iv < n
genarray( [n])...
However, this does not seem to be the case. Consider this code:
use Array: {<,<=};
int id( int x)
{
return( x);
}
int main()
{
n = id( 20);
shp = _add_SxS_( n, 2);
AAA = with {
( [0] <= iv < [n]) : 1;
( [n] <= iv <= [n]) : 2;
( [ _add_SxS_( n, 1)] <= iv < [shp]) : 3;
} : genarray( [ shp]);
StdIO::print( AAA);
return( 0);
}
After -b9:wlpg, we have this:
_flat_2 = 20;
n = _MAIN::id( _flat_2) ;
_flat_3 = 2;
shp = _add_SxS_( n, _flat_3);
_flat_7 = [ n ];
_flat_6 = 0;
_flat_5 = [ _flat_6 ];
_flat_4 = [ shp ];
_wldp_72 = 0;
_wlpg_91_zeros = [ 0 ];
_wlpg_92_axis = 0;
_wlpg_93_lmax, _wlpg_94_umin, _wlpg_95_nmin, _wlpg_96_nmax = wrapper:sacprelude::partitionSlicer( _wlpg_91_zeros, _flat_4, _wlpg_92_axis, _flat_5, _flat_7) ;
_hwlg_0 = with {
/* Partn */
(_wlpg_94_umin <= iv=[_eat_22] < _flat_4)
{
} : _flat_6 ; ,
/* Partn */
(_wlpg_91_zeros <= iv=[_eat_22] < _wlpg_93_lmax)
{
} : _flat_6 ; ,
/* Partn */
(_flat_5 <= iv=[_eat_22] < _flat_7)
{
_flat_8 = 1;
} : _flat_8 ;
} :
genarray( _flat_4);
These do not, from all appearances, form a chain from 0..._flat_4.
Am I missing something obvious here?</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1905Can't compile anything on Intel box Ubuntu 13.102017-11-19T21:38:11ZRobert BerneckyCan't compile anything on Intel box Ubuntu 13.10| | |
| --- | --- |
| Bugzilla Link | [1114](http://bugs.sac-home.org/show_bug.cgi?id=1114) |
| Created on | Jan 31, 2014 21:10 |
| Resolution | FIXED |
| Resolved on | Jun 16, 2014 21:28 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1114](http://bugs.sac-home.org/show_bug.cgi?id=1114) |
| Created on | Jan 31, 2014 21:10 |
| Resolution | FIXED |
| Resolved on | Jun 16, 2014 21:28 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>STDLIB was compiled with -mt.
Same failure whether I compile with -mt or without...
warning: AWLF is enabled: -ecc enabled.
warning: AWLF is enabled: -extrema enabled.
warning: AWLF is enabled: -maxoptcyc=20
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `sqrt'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `asinh'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `floor'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `log1p'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `ceil'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `cosh'
/home/sac/sac2c/lib//libsac.mt.pth.so: undefined reference to `pthread_key_create'
/home/sac/sac2c/lib//libsac.mt.pth.so: undefined reference to `dlsym'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `tan'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `tanh'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `powf'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `sqrtf'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `asin'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `expf'
/home/sac/sac2c/lib//libsac.mt.pth.so: undefined reference to `dlerror'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `atanh'
/home/sac/sac2c/lib//libsac.mt.pth.so: undefined reference to `pthread_getspecific'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `cbrt'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `log'
/home/sac/sac2c/lib//libsac.mt.pth.so: undefined reference to `pthread_create'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `atan'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `log2'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `expm1'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `sinh'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `fmod'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `acos'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `exp'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `sin'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `hypot'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `acosh'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `rint'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `pow'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `atan2'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `cos'
/home/sac/sac2c/lib//libsac.mt.pth.so: undefined reference to `dlopen'
/home/sac/sac/BASE/stdlib/shared-libs/libMathArrayMod.so: undefined reference to `fabs'
/home/sac/sac2c/lib//libsac.mt.pth.so: undefined reference to `pthread_setspecific'
/home/sac/sac/BASE/stdlib/shared-libs/libArrayFormatMod.so: undefined reference to `log10'
/home/sac/sac2c/lib//libsac.mt.pth.so: undefined reference to `pthread_join'
collect2: error: ld returned 1 exit status
abort: System failed to execute shell command
abort: gcc -std=gnu99 -pedantic -Wall -Wno-unused -fno-builtin
abort: -I$SAC2CBASE/include/ -O3 -I$SAC2CBASE/include/ -o a.out a.out.c -ldl
abort: -lpthread -L$SAC2CBASE/lib/ -L/tmp/SAC_S8xDdT -L. -Wl,-rpath,.
abort: -L/home/sac/sac2c/lib -Wl,-rpath,/home/sac/sac2c/lib
abort: -L/home/sac/sac/BASE/stdlib/shared-libs
abort: -Wl,-rpath,/home/sac/sac/BASE/stdlib/shared-libs -L. -Wl,-rpath,.
abort: -L/usr/local/dislin -Wl,-rpath,/usr/local/dislin -L/opt/local/lib
abort: -Wl,-rpath,/opt/local/lib -lStdIOMod -lBinFileMod -lFibreIOMod -lListIOMod
abort: -lComplexIOMod -lColor8IOMod -lGreyIOMod -lArrayIOMod -lScalarIOMod
abort: -lStringArrayMod -lRuntimeErrorMod -lIOresourcesMod -lArrayFormatMod
abort: -lStructuresMod -lBitsMod -lComplexMod -lListMod -lColor8Mod -lGreyMod
abort: -lFileMod -lTermFileMod -lTerminalMod -lFileSystemMod -lArrayMod
abort: -lMathArrayMod -lComplexArrayTransformMod -lArrayTransformMod
abort: -lComplexArrayArithMod -lSysErrMod -lWorldMod -lStringMod
abort: -lComplexScalarArithMod -lComplexArrayBasicsMod -lConstantsMod
abort: -lArrayArithMod -lBoolMod -lComplexBasicsMod -lCharMod -lArrayBasicsMod
abort: -lMathMod -lm -lScalarArithMod -lsacpreludeMod -lsacphm.mt -lsac.mt.pth
abort: -ldl
abort: with exit code 1
compilation failed while Creating binary code, 3 warning(s).
rbe@rattler:~/texsrc/DrDobbs/innerproduct$
rbe@rattler:~/texsrc/DrDobbs/innerproduct$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 18427 linux-gnu_x86_64
(Fri Jan 31 16:05:00 EST 2014 by sac)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1906#pragma for WL no longer works in matmul()2017-11-19T21:38:17ZRobert Bernecky#pragma for WL no longer works in matmul()| | |
| --- | --- |
| Bugzilla Link | [1117](http://bugs.sac-home.org/show_bug.cgi?id=1117) |
| Created on | Feb 24, 2014 17:32 |
| Resolution | FIXED |
| Resolved on | Feb 24, 2014 20:20 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1117](http://bugs.sac-home.org/show_bug.cgi?id=1117) |
| Created on | Feb 24, 2014 17:32 |
| Resolution | FIXED |
| Resolved on | Feb 24, 2014 20:20 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [matmul.sac](/uploads/a145871792aa7e5c5b1fa4e8556271f9/matmul.sac) |
## Extended Description
<pre>Created an attachment (id=1005)
source code to reproduce fault
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18429 linux-gnu_x86_64
(Mon Feb 24 11:22:37 EST 2014 by sac)
In my modified copy of ~/sac/demos/applications/numerical/misc/matmul.sac,
the pragma is ignored. More to the point, WITH_PRAGMA disappears
from the AST during the DCR after -bopt:cyc:wlf:2.
I modified the test because the only reference to the result of the
matmul is: C[0,0]. SCWLF does a fold on this, which effectively
evaporates the entire benchmark. If I compile with -noscwlf,
then the pragma works as expected.
I replaced the C[0,0] with sum(C). AWLF/WLF fold the pragma-marked WL
into the sum WL, at which point the WITH_PRAGMA is sitting in dead code.
There are a few problems here, IMO:
1. Any pragma in a producer-WL disappear when that WL is folded into
a consumer-WL. Since sum() is a stdlib function, we would have to
give the sum() a pragma, which doesn't seem quite right.
We might consider copying the WITH_PRAGMA from the producer-WL into
a NULL WITH_PRAGMA for the consumer-WL. I don't know whether this
is a good or bad idea. Comments welcome.
2. A pragma is only effective at the outermost level of WL nesting,
if WLF/AWLF can occur.
I have added a comment to matmul.sac re -noscwlf.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1907sac2c -check tc generates illegal C code2017-11-19T21:38:23ZSven-Bodo Scholzsac2c -check tc generates illegal C code| | |
| --- | --- |
| Bugzilla Link | [1121](http://bugs.sac-home.org/show_bug.cgi?id=1121) |
| Created on | Jun 17, 2014 17:59 |
| Resolution | FIXED |
| Resolved on | Jun 17, 2014 21:56 |
| Version | svn |
| OS | All |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [1121](http://bugs.sac-home.org/show_bug.cgi?id=1121) |
| Created on | Jun 17, 2014 17:59 |
| Resolution | FIXED |
| Resolved on | Jun 17, 2014 21:56 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [imageCore.sac](/uploads/2ad4333a698d74aca21dc646eeabadb6/imageCore.sac), [bug1121.sac](/uploads/70a8176132c8e3a2fe4568a26420066a/bug1121.sac) |
## Extended Description
<pre>Created an attachment (id=1006)
source code
product rev 18484 compiles the library fine unless it is compiled with -check c</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1908state in WL problem2017-11-19T21:38:30ZSven-Bodo Scholzstate in WL problem| | |
| --- | --- |
| Bugzilla Link | [1132](http://bugs.sac-home.org/show_bug.cgi?id=1132) |
| Created on | Sep 18, 2014 14:14 |
| Resolution | FIXED |
| Resolved on | Sep 18, 2014 17:30 |
| Version | svn |
| OS | All |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [1132](http://bugs.sac-home.org/show_bug.cgi?id=1132) |
| Created on | Sep 18, 2014 14:14 |
| Resolution | FIXED |
| Resolved on | Sep 18, 2014 17:30 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [1130.sac](/uploads/2e93e159c2d3232f0b3913beb22ea804/1130.sac), [out](/uploads/76b489deb5e937d460e9c08f1193ec5b/out), [bound.sac](/uploads/8597f2427b4885ca5974916bd8ca9694/bound.sac) |
## Extended Description
<pre>Created an attachment (id=1016)
source code that fails; requires further class
This bug may be the same as 1130; but it shows a different symptom.
Error message is related to low-level code generation actual message in attachment.</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/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/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/1912Post-Black Forest sac2c-follow problems on Ubuntu 14.04LTS2017-11-19T21:38:54ZRobert BerneckyPost-Black Forest sac2c-follow problems on Ubuntu 14.04LTS| | |
| --- | --- |
| Bugzilla Link | [1161](http://bugs.sac-home.org/show_bug.cgi?id=1161) |
| Created on | Sep 24, 2015 19:25 |
| Resolution | FIXED |
| Resolved on | Sep 26, 2015 15:00 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1161](http://bugs.sac-home.org/show_bug.cgi?id=1161) |
| Created on | Sep 24, 2015 19:25 |
| Resolution | FIXED |
| Resolved on | Sep 26, 2015 15:00 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I just got back home, and tried a checkout and build of
sac2c-follow, on the above platform.
I did:
git checkout sac2c-follow
./configure
make clean
make
This produced a number of failures that I did not expect:
1. sacislinterface is, oddly enough, an interface between SAC and ISL.
It is single-thread, and does not care about PHM or RTSPEC.
I'd like to kill off the warnings here, but am not sure how to do that.
Linking bin/sacislinterface (developer version)
MT_MODE = 0 in target, forcing -numthreads to 1.
MT_MODE = 0 in target, forcing -numthreads to 1.
MT_MODE = 0 in target, forcing -numthreads to 1.
MT_MODE = 0 in target, forcing -numthreads to 1.
MT_MODE = 0 in target, forcing -numthreads to 1.
MT_MODE = 0 in target, forcing -numthreads to 1.
MT_MODE = 0 in target, forcing -numthreads to 1.
** INFO: target 'seq' does *not* support PHM.
** INFO: target 'seq' does not support RTSPEC.
2. This one is a show stopper. Suggestions for fixing it are welcome.
LD bin/csima
lib/host/seq/libsac.so: undefined reference to `SAC_DISTMEM_rank'
lib/host/seq/libsac.so: undefined reference to `SAC_DISTMEM_Abort'
lib/host/seq/libsac.so: undefined reference to `SAC_DISTMEM_trace_profile_rank'
collect2: error: ld returned 1 exit status</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1913Link failures with Black Forest sac2c on Ubuntu 14.04LTS2017-11-19T21:39:00ZRobert BerneckyLink failures with Black Forest sac2c on Ubuntu 14.04LTS| | |
| --- | --- |
| Bugzilla Link | [1164](http://bugs.sac-home.org/show_bug.cgi?id=1164) |
| Created on | Sep 27, 2015 19:11 |
| Resolution | DUPLICATE |
| Resolved on | Nov 04, 2015 14:59 |
| Version | svn |
| OS | Linux |
| Archit...| | |
| --- | --- |
| Bugzilla Link | [1164](http://bugs.sac-home.org/show_bug.cgi?id=1164) |
| Created on | Sep 27, 2015 19:11 |
| Resolution | DUPLICATE |
| Resolved on | Nov 04, 2015 14:59 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This is an attempt to separate the bugs in #1163 from one another. This
looks like a repeat of the link-order problem that we saw in
Bad Wildbad, but it looks okay to me. Here's what gcc thinks of it:
~/sac/testsuite/optimizations/pogorelationals$ sac2c WhileFunUp.sac
/usr/local/lib/sac2c/1.2.beta-BlackForest-39-e7b01/rt/host/seq/libsac.so: undefined reference to `SAC_DISTMEM_rank'
/usr/local/lib/sac2c/1.2.beta-BlackForest-39-e7b01/rt/host/seq/libsac.so: undefined reference to `SAC_DISTMEM_Abort'
/usr/local/lib/sac2c/1.2.beta-BlackForest-39-e7b01/rt/host/seq/libsac.so:
undefined reference to `SAC_DISTMEM_trace_profile_rank'
/usr/local/lib/sac2c/1.2.beta-BlackForest-39-e7b01/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_d6VcCj/a.out.o
abort: -L/usr/local/lib/sac2c/1.2.beta-BlackForest-39-e7b01/modlibs/host/seq
abort: -Wl,-rpath,/usr/local/lib/sac2c/1.2.beta-BlackForest-39-e7b01/modlibs/host/seq
abort: -L/usr/local/lib/sac2c/1.2.beta-BlackForest-39-e7b01/modlibs/host/seq
abort: -Wl,-rpath,/usr/local/lib/sac2c/1.2.beta-BlackForest-39-e7b01/modlibs/host/seq -L./host/seq
abort: -Wl,-rpath,./host/seq -L/usr/local/lib/sac2c/1.2.beta-BlackForest-39-e7b01/rt/host/seq
abort: -Wl,-rpath,/usr/local/lib/sac2c/1.2.beta-BlackForest-39-e7b01/rt/host/seq -lArrayMod
abort: -lArrayTransformMod -lConstantsMod -lArrayArithMod -lArrayBasicsMod -lBoolMod -lScalarArithMod
abort: -lsacpreludeMod -L/usr/local/dislin -Wl,-rpath,/usr/local/dislin -L/opt/local/lib
abort: -Wl,-rpath,/opt/local/lib -lsacphmc -lsac -lsacdistmem -lsacphmc -o a.out
abort: with exit code 1
compilation failed while Creating binary code.
My observations:
1. There is no /opt/local on this system.
2. The offending symbols, e.g., SAC_DISTMEM_rank, appear to be properly defined
in libsacdistmem.so.
3. I do not see any references to the offending symbols in libsacphmc. I.e,:
cd /usr/local/lib/sac2c/1.2.beta-BlackForest-39-e7b01/rt/host/seq$
nm libsacdistmem.so
...
00000000000007e0 T SAC_DISTMEM_Abort
0000000000201038 D SAC_DISTMEM_rank
0000000000201030 D SAC_DISTMEM_trace_profile_rank
nm libsacphmc.so |grep rank
(nothing)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1914sac2c program.sac -o foo adds foo to the rpath2017-11-19T21:39:05ZRaphael 'kena' Posssac2c program.sac -o foo adds foo to the rpath| | |
| --- | --- |
| Bugzilla Link | [1169](http://bugs.sac-home.org/show_bug.cgi?id=1169) |
| Created on | Nov 04, 2015 09:48 |
| Resolution | FIXED |
| Resolved on | Nov 04, 2015 14:39 |
| Version | svn |
| OS | All |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [1169](http://bugs.sac-home.org/show_bug.cgi?id=1169) |
| Created on | Nov 04, 2015 09:48 |
| Resolution | FIXED |
| Resolved on | Nov 04, 2015 14:39 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
This makes no sense, and should be removed.BugZillaBugZilla