sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:52:07Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1453Bug in AKD with-loop code generation2017-11-19T20:52:07ZRobert BerneckyBug in AKD with-loop code generation| | |
| --- | --- |
| Bugzilla Link | [381](http://bugs.sac-home.org/show_bug.cgi?id=381) |
| Created on | Jun 28, 2007 18:25 |
| Resolution | FIXED |
| Resolved on | Nov 09, 2007 23:09 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [381](http://bugs.sac-home.org/show_bug.cgi?id=381) |
| Created on | Jun 28, 2007 18:25 |
| Resolution | FIXED |
| Resolved on | Nov 09, 2007 23:09 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu.sac](/uploads/073465436882d26d49bc24862467328e/tutu.sac) |
## Extended Description
<pre>sac2c tutu.sac gives warning on pointer to int conversion.
The * C compiler crash does away with -nocf, but the warning sticks around.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1452Compilation dies in "Marking memval identifiers"2017-11-19T20:52:01ZTorben Gerhards Compilation dies in "Marking memval identifiers"| | |
| --- | --- |
| Bugzilla Link | [379](http://bugs.sac-home.org/show_bug.cgi?id=379) |
| Created on | Jun 27, 2007 12:04 |
| Resolution | FIXED |
| Resolved on | Nov 09, 2007 15:03 |
| Version | 1.00beta |
| OS | SunOS |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [379](http://bugs.sac-home.org/show_bug.cgi?id=379) |
| Created on | Jun 27, 2007 12:04 |
| Resolution | FIXED |
| Resolved on | Nov 09, 2007 15:03 |
| Version | 1.00beta |
| OS | SunOS |
| Architecture | PC |
| Attachments | [Fifo.sac](/uploads/b6ce195fdf1f884dbd5e6ed593c3b335/Fifo.sac), [genarray_withloop_nested_object.sac](/uploads/2001fb4f321ab91f5f9875e9ad2adc82/genarray_withloop_nested_object.sac) |
## Extended Description
<pre>sac2c rev #15402
The compilation dies since today when compiling a program with a nested
with-loop (propagate).
It seems to me that an avis gets lost somewhere.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1451increased occurance of "may be used uninitialized in this function"2017-11-19T20:51:55ZSven-Bodo Scholzincreased occurance of "may be used uninitialized in this function"| | |
| --- | --- |
| Bugzilla Link | [378](http://bugs.sac-home.org/show_bug.cgi?id=378) |
| Created on | Jun 25, 2007 16:02 |
| Resolution | FIXED |
| Resolved on | Jun 26, 2007 14:33 |
| Version | 1.00beta |
| OS | SunOS |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [378](http://bugs.sac-home.org/show_bug.cgi?id=378) |
| Created on | Jun 25, 2007 16:02 |
| Resolution | FIXED |
| Resolved on | Jun 26, 2007 14:33 |
| Version | 1.00beta |
| OS | SunOS |
| Architecture | PC |
| Attachments | [tutu2.sac](/uploads/9a52417817040caa52923b83bfe5344c/tutu2.sac), [xtutu2.sac](/uploads/ff91138a8843f7b7487c14991f64745b/xtutu2.sac) |
## Extended Description
<pre>since quite a while (maybe 3 months??) we see a rather significant
increase in warnings of the kind: "may be used uninitialized in this function"
It was anticipated that theese stem from the inlining bug (110). However,
that anticipation is wrong. It has something to do with the code that is created
whenever an AUD variable is assigned to a scalar value. See the attached example.
In essence, the compiler creates a for loop for extracting the values which,
in case the AUD value would be empty, results in an un-initialised variable.
If we turn on -check tb the check comes in a rather diguised form so that the
C compiler fails to find out that an empty for-loop in fact cannot happen.
I am not sure what to do here. As a starting point one may try to find out
why this problem did not occur earlier. Looking into the history of the
masterrun might be a starting point to get an idea which compiler version
did not yet suffer from the flooding by warnings.....</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1450During the compilation the hand-written propagete get lost2017-11-19T20:51:48ZTorben Gerhards During the compilation the hand-written propagete get lost| | |
| --- | --- |
| Bugzilla Link | [377](http://bugs.sac-home.org/show_bug.cgi?id=377) |
| Created on | Jun 18, 2007 14:24 |
| Resolution | FIXED |
| Resolved on | Jun 19, 2007 13:47 |
| Version | 1.00beta |
| OS | SunOS |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [377](http://bugs.sac-home.org/show_bug.cgi?id=377) |
| Created on | Jun 18, 2007 14:24 |
| Resolution | FIXED |
| Resolved on | Jun 19, 2007 13:47 |
| Version | 1.00beta |
| OS | SunOS |
| Architecture | PC |
| Attachments | [foldfix_prop_bug2.sac](/uploads/75e5192a380036e5f2acb7a30c65aacf/foldfix_prop_bug2.sac) |
## Extended Description
<pre>sac2c rev #15357
While compiling a program with a foldfix-withloop and a propagate where the
foldfix is written in front of the propagate, it doesn't compile with the error
message
ABORT: Inconsistent with loop: 3 operator(s) but 4 value(s) specified in the
ABORT: body
It seems to be that the hand-written propagate get lost during the compilation.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1449Segfault while applying random-function2017-11-19T20:51:42ZTorben Gerhards Segfault while applying random-function| | |
| --- | --- |
| Bugzilla Link | [375](http://bugs.sac-home.org/show_bug.cgi?id=375) |
| Created on | Jun 14, 2007 16:52 |
| Resolution | DUPLICATE |
| Resolved on | Jun 14, 2007 17:33 |
| Version | 1.00beta |
| OS | SunOS |
| Arc...| | |
| --- | --- |
| Bugzilla Link | [375](http://bugs.sac-home.org/show_bug.cgi?id=375) |
| Created on | Jun 14, 2007 16:52 |
| Resolution | DUPLICATE |
| Resolved on | Jun 14, 2007 17:33 |
| Version | 1.00beta |
| OS | SunOS |
| Architecture | PC |
| Attachments | [random-2d.sac](/uploads/6875dd4383f6e457ed5a523c2eae87e5/random-2d.sac) |
## Extended Description
<pre>Program produces segmentation fault when trying to apply the random-function to
a two or three dimensional array.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1448with-loop partition generation cannot handle width = [0]2017-11-19T20:51:36ZSven-Bodo Scholzwith-loop partition generation cannot handle width = [0]| | |
| --- | --- |
| Bugzilla Link | [366](http://bugs.sac-home.org/show_bug.cgi?id=366) |
| Created on | May 29, 2007 18:47 |
| Resolution | FIXED |
| Resolved on | Nov 19, 2009 00:25 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [366](http://bugs.sac-home.org/show_bug.cgi?id=366) |
| Created on | May 29, 2007 18:47 |
| Resolution | FIXED |
| Resolved on | Nov 19, 2009 00:25 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | All |
| Attachments | [tutu.sac](/uploads/c0d5a75023c544f660dab66cda7345e1/tutu.sac) |
## Extended Description
<pre>sac2c v1.00-beta (Codename Wooden Shoes)
developer rev 15319 linux-gnu_x86_64
(Fri May 18 17:46:31 BST 2007 by sbs)
sac2c tutu.sac yields:
ABORT: line 7 file: tutu.sac
ABORT: Component of width less than zero</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1447mkttempus fugit - warnings from C compiler.2017-11-19T20:51:31ZRobert Berneckymkttempus fugit - warnings from C compiler.| | |
| --- | --- |
| Bugzilla Link | [365](http://bugs.sac-home.org/show_bug.cgi?id=365) |
| Created on | May 15, 2007 21:50 |
| Resolution | FIXED |
| Resolved on | Jun 21, 2007 11:33 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [365](http://bugs.sac-home.org/show_bug.cgi?id=365) |
| Created on | May 15, 2007 21:50 |
| Resolution | FIXED |
| Resolved on | Jun 21, 2007 11:33 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This just started appearing on my system in the last day or so. Not sure
who should own it:
** 17: Creating binary code ...
**** Handling dependencies ...
**** Invoking C compiler ...
/home/sac/sac/BASE/stdlib/world/system/lib/libFileSystem.a(tmpnam.o): In
function `SACtmpnam':
world/system/src/FileSystem/tmpnam.c:16: warning: the use of `tmpnam' is
dangerous, better use `mkstemp'
/home/sac/sac/BASE/stdlib/world/system/lib/libFileSystem.a(tempnam.o): In
function `SACtempnam':
world/system/src/FileSystem/tempnam.c:17: warning: the use of `tempnam' is
dangerous, better use `mkstemp'
/home/sac/sac/BASE/stdlib/world/system/lib/libFileSystem.a(fun0.o): In function
`SACwf_FileSystem__mktemp__SACt_String__string_S':
fun0.c:(.text+0xa3c): warning: the use of `mktemp' is dangerous, better use
`mkstemp'</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1446type error causes assert failure in UESDprf2017-11-19T20:51:25ZRobert Berneckytype error causes assert failure in UESDprf| | |
| --- | --- |
| Bugzilla Link | [362](http://bugs.sac-home.org/show_bug.cgi?id=362) |
| Created on | May 14, 2007 16:55 |
| Resolution | FIXED |
| Resolved on | Jul 11, 2007 18:24 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [362](http://bugs.sac-home.org/show_bug.cgi?id=362) |
| Created on | May 14, 2007 16:55 |
| Resolution | FIXED |
| Resolved on | Jul 11, 2007 18:24 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTReplicate.sac](/uploads/1426716d18e9acae55b76252360e4ee3/UTReplicate.sac) |
## Extended Description
<pre>The attached hss (at least) one bug, arising from:
vector ++ matrix.
However, UESDprf ends up receiving a type error which
causes an assertion on argument #2 of _div_SxS_ being non-zero.
I'll fix the ++ bugs and see if things change.
I'm not sure of the design rationale here. Perhaps anything
which introduces a type error could issue a warning that might
point upstream enough that a user could fault-isolate at the
sac source code level?</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1445Array reuse failure: threat or menace?2017-11-19T20:51:19ZRobert BerneckyArray reuse failure: threat or menace?| | |
| --- | --- |
| Bugzilla Link | [360](http://bugs.sac-home.org/show_bug.cgi?id=360) |
| Created on | May 10, 2007 20:50 |
| Resolution | REMIND |
| Resolved on | May 15, 2007 11:52 |
| Version | 1.00beta |
| OS | Linux |
| Archit...| | |
| --- | --- |
| Bugzilla Link | [360](http://bugs.sac-home.org/show_bug.cgi?id=360) |
| Created on | May 10, 2007 20:50 |
| Resolution | REMIND |
| Resolved on | May 15, 2007 11:52 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The following function has the interesting property that, when compiled
with -DFAST, it runs about 100X faster. Visual inspection at -b11 suggests
that the problem appears to be, at least
in part, a failure of the "r = r + val" code to see that it could work in place
on r, rather than allocating a new array.
--------------cut here------------
use Array: all;
use String: {tochar,to_string,strtod,sprintf};
use StdIO: all;
int main()
{
n = 1000000;
r=[0];
vec = iota( n) ;
lim = (shape(vec)[[0]])-1;
for(i=0; i <= lim; i++){
val = vec[i];
#ifdef FAST
r = modarray(r, [0], r[0] + val);
#else
r = r + val;
#endif
}
print(sum(r));
return(0);
}</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1444DCR doesn't remove dead parameters from functions2017-11-19T20:51:13ZRobert BerneckyDCR doesn't remove dead parameters from functions| | |
| --- | --- |
| Bugzilla Link | [355](http://bugs.sac-home.org/show_bug.cgi?id=355) |
| Created on | Apr 24, 2007 19:35 |
| Resolution | INVALID |
| Resolved on | Apr 25, 2007 08:36 |
| Version | 1.00beta |
| OS | Linux |
| Archi...| | |
| --- | --- |
| Bugzilla Link | [355](http://bugs.sac-home.org/show_bug.cgi?id=355) |
| Created on | Apr 24, 2007 19:35 |
| Resolution | INVALID |
| Resolved on | Apr 25, 2007 08:36 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Summary says it all. I expected that some phase or another of sac2c would
remove the dead variable "junk" from the function prototype and call of foo.
However, this does not seem to be the case.
use Array: all;
use StdIO: all;
int[*] id(int[*] x)
{ return(x);
}
int[*] foo (int[*]x, int[*] junk2)
{
return(x*10);
}
int main()
{
junk = id(23);
x = iota(id(55));
z = foo(x,junk);
print(z);
return(1);
}</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1443Pawn to king 232017-11-19T20:51:08ZRobert BerneckyPawn to king 23| | |
| --- | --- |
| Bugzilla Link | [354](http://bugs.sac-home.org/show_bug.cgi?id=354) |
| Created on | Apr 08, 2007 18:38 |
| Resolution | INVALID |
| Resolved on | Apr 10, 2007 17:09 |
| Version | 1.00beta |
| OS | Linux |
| Archi...| | |
| --- | --- |
| Bugzilla Link | [354](http://bugs.sac-home.org/show_bug.cgi?id=354) |
| Created on | Apr 08, 2007 18:38 |
| Resolution | INVALID |
| Resolved on | Apr 10, 2007 17:09 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [indexerror.sac](/uploads/591a306d8bfa2181482fe71317011d9f/indexerror.sac) |
## Extended Description
<pre>SAC's array bounds checking is broken. Specifically, although it
may check that an array offset lies within the ravel of an array,
egregious programming errors can slip through. Consider an
array X, of shape [20,30]. These expressions produce results, instead
of index errors, even in the presence of -check b:
X[ [4, 31] ]
X[ [4, -3] ]
This behavior is, IM(oh, so H)O, unacceptable semantics for an array language.
Presumably, the bounds checking is being performed in idx_sel, when it should
be performed as an explicit operation earlier. If IVEO did not split
vect2offset operations, then vect2offset would be an ideal place to
do this.
One possible way to resolve this problem is to leave vect2offset along,
introduce an array-bounds Checker-O-Meter node, which can be optimized out
of existence when static information allows that.
The IVEO split problem remains, as does the "iv - cv" overflow-on-split
problem. More coffee is required.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1442foldfix: rhs yields 1 value; 2 vars specified on the lhs2017-11-19T20:51:02ZRobert Berneckyfoldfix: rhs yields 1 value; 2 vars specified on the lhs| | |
| --- | --- |
| Bugzilla Link | [353](http://bugs.sac-home.org/show_bug.cgi?id=353) |
| Created on | Mar 19, 2007 15:30 |
| Resolution | DUPLICATE |
| Resolved on | May 31, 2007 16:58 |
| Version | 1.00beta |
| OS | Linux |
| Arc...| | |
| --- | --- |
| Bugzilla Link | [353](http://bugs.sac-home.org/show_bug.cgi?id=353) |
| Created on | Mar 19, 2007 15:30 |
| Resolution | DUPLICATE |
| Resolved on | May 31, 2007 16:58 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu.sac](/uploads/a4ac0a61079d13e5d0f65029e4463c1c/tutu.sac), [crud2.sac](/uploads/75a37cce3be07724ed3aec0044c996d2/crud2.sac) |
## Extended Description
<pre>WHile trying to fault-isolate the false index error in dtb.sac, I came
across this failure. Compiling with no options produces this failure.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1441improper treatment of empty modarray2017-11-19T20:50:55ZFlorian Bütherimproper treatment of empty modarray| | |
| --- | --- |
| Bugzilla Link | [344](http://bugs.sac-home.org/show_bug.cgi?id=344) |
| Created on | Feb 07, 2007 12:52 |
| Resolution | FIXED |
| Resolved on | May 08, 2007 11:17 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [344](http://bugs.sac-home.org/show_bug.cgi?id=344) |
| Created on | Feb 07, 2007 12:52 |
| Resolution | FIXED |
| Resolved on | May 08, 2007 11:17 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [wlfsbug.sac](/uploads/1bb566d5837488440aabe7bba23f1ad7/wlfsbug.sac), [bug344.sac](/uploads/dbc3b564d37eab7f4ba992b8ab79be81/bug344.sac) |
## Extended Description
<pre>Cheer up, folks, for i am bringing you not only one, but two bugs today, which
although maybe closely related.
The bugs are encountered specifically when specifing a with-loop with no
generators applied to a modarray, like this:
A = with : modarray( B );
the compiler dies with a SIGSEGV in TYgetProductSize, at phase 6: Running type
inference system.
--
If you now place the with:modarray inside a do-loop, like this:
do {
A = with : modarray( B );
} while ( true );
the compiler dies with a SIGSEGV at HZGWLassign, in phase 2:Handling
zero-generator with-loops.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1440CF makes me a man of constant sorrow2017-11-19T20:50:48ZRobert BerneckyCF makes me a man of constant sorrow| | |
| --- | --- |
| Bugzilla Link | [339](http://bugs.sac-home.org/show_bug.cgi?id=339) |
| Created on | Jan 04, 2007 22:14 |
| Resolution | LATER |
| Resolved on | Jan 05, 2007 22:27 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [339](http://bugs.sac-home.org/show_bug.cgi?id=339) |
| Created on | Jan 04, 2007 22:14 |
| Resolution | LATER |
| Resolved on | Jan 05, 2007 22:27 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [BUGswlf.sac](/uploads/9f88c5bd74a3a278a1932502dbedf7e0/BUGswlf.sac), [xBUGswlf.sac](/uploads/56b70d5fb6de56788a74417802b80f86/xBUGswlf.sac) |
## Extended Description
<pre>I've found an interesting anomaly in one of the APEX benchmarks.
If I use:
z = iota(N);
instead of:
z = 0 + iota(N);
it runs slower when I compile with -O3 -check b -maxwlur 3 -doswlf.
Without swlf, both run at the same speed (because my shiny new SxA, AxS
CF code disappears the "0 +").</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1439sac2c -v and sac2c -h don't work any more2017-11-19T20:50:42ZRobert Berneckysac2c -v and sac2c -h don't work any more| | |
| --- | --- |
| Bugzilla Link | [338](http://bugs.sac-home.org/show_bug.cgi?id=338) |
| Created on | Jan 04, 2007 14:21 |
| Resolution | FIXED |
| Resolved on | Jan 04, 2007 19:02 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [338](http://bugs.sac-home.org/show_bug.cgi?id=338) |
| Created on | Jan 04, 2007 14:21 |
| Resolution | FIXED |
| Resolved on | Jan 04, 2007 19:02 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I'd tell you which version of sac2c it is, but sac2c -v doesn't work...</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1438#crashes for the price of 1 with UTThornInt.sac2017-11-19T20:50:36ZRobert Bernecky#crashes for the price of 1 with UTThornInt.sac| | |
| --- | --- |
| Bugzilla Link | [337](http://bugs.sac-home.org/show_bug.cgi?id=337) |
| Created on | Dec 13, 2006 23:57 |
| Resolution | FIXED |
| Resolved on | May 10, 2007 15:56 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [337](http://bugs.sac-home.org/show_bug.cgi?id=337) |
| Created on | Dec 13, 2006 23:57 |
| Resolution | FIXED |
| Resolved on | May 10, 2007 15:56 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTThornInt.sac](/uploads/47813a4f30d202d6e15f4f17c8c7415e/UTThornInt.sac) |
## Extended Description
<pre>The attached has some interesting properties, but I have not had time to
fault-isolate the problem - it's dinnertime. So:
1. If you compile the attached with -noopt, it dies at run-time complaining about
a dispatch problem on TRANSPOSE. It's not clear to me exactly what its problem is...
2. If you compiled it with -DBUG -noopt, sac2c crashes in phase 6, splitting
wrappers. Perhaps this is the two-copies of same function problem? I got into
this while trying to deal with (1).
3. If you compile with -O3, it ... well, it's using 2.3GB and it's still
running... Damn benchmark is about 40 lines of very simple APL.
I'll file this and amend this when/if it finishes...</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1437optimisation cycle on fundefs screwed up due to inconsistent LaC fun treatment2017-11-19T20:50:30ZSven-Bodo Scholzoptimisation cycle on fundefs screwed up due to inconsistent LaC fun treatment| | |
| --- | --- |
| Bugzilla Link | [336](http://bugs.sac-home.org/show_bug.cgi?id=336) |
| Created on | Dec 12, 2006 19:08 |
| Resolution | FIXED |
| Resolved on | Feb 24, 2009 15:30 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [336](http://bugs.sac-home.org/show_bug.cgi?id=336) |
| Created on | Dec 12, 2006 19:08 |
| Resolution | FIXED |
| Resolved on | Feb 24, 2009 15:30 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [error.sac](/uploads/da63c191c786f7da855fc6b2cd1dcd12/error.sac) |
## Extended Description
<pre>some opts do traverse LaC only in the context of the calling function
(e.g. the typechecker)
others just go ahead on ANY function (e.g. Constant Folding)
(as of rev 15124)
As a consequence, the actual order in which the optimisations are
applied varies between non-LaC funs and LaC funs.
This leads to "strange" behaviours such as crashes in CF although the
source for the crash seemingly disappears when breaking a subphase earlier.
the attached example demonstrates this nicely.
The solution for this problem is to enforce "top-level" function entries on
non-LaC functions only and to map those functions that do not follow all the
LaC funs to the static call graph of these....</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1436runtime pointer error when invoking print on an array which is the return val...2017-11-19T20:50:24ZMarkus Weigelruntime pointer error when invoking print on an array which is the return value of a function| | |
| --- | --- |
| Bugzilla Link | [328](http://bugs.sac-home.org/show_bug.cgi?id=328) |
| Created on | Nov 23, 2006 16:33 |
| Resolution | INVALID |
| Resolved on | May 08, 2007 11:44 |
| Version | 1.00beta |
| OS | Linux |
| Archi...| | |
| --- | --- |
| Bugzilla Link | [328](http://bugs.sac-home.org/show_bug.cgi?id=328) |
| Created on | Nov 23, 2006 16:33 |
| Resolution | INVALID |
| Resolved on | May 08, 2007 11:44 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>In the following code example, the print statement will result in a runtime
error similar to
"*** glibc detected *** free(): invalid pointer: 0x080540d0 ***".
use StdIO: all;
import Array: all;
int[*] foo(int[.] shp) {
return(genarray(shp,0));
}
int main() {
shp = [64,64];
A = foo(shp);
print(A[[2,2]]);
return(0);
}</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1435modarray does not work on color[.,.]2017-11-19T20:50:19ZMarkus Weigelmodarray does not work on color[.,.]| | |
| --- | --- |
| Bugzilla Link | [324](http://bugs.sac-home.org/show_bug.cgi?id=324) |
| Created on | Nov 15, 2006 12:31 |
| Resolution | INVALID |
| Resolved on | Nov 15, 2006 13:54 |
| Version | 1.00beta |
| OS | Linux |
| Archi...| | |
| --- | --- |
| Bugzilla Link | [324](http://bugs.sac-home.org/show_bug.cgi?id=324) |
| Created on | Nov 15, 2006 12:31 |
| Resolution | INVALID |
| Resolved on | Nov 15, 2006 13:54 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>for images of type color[.,.], neither
image = modarray(image,[x,y],black());
nor
image[x,y] = black();
seem to be implmented.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1434wl partition generation fails on akd outer aud inner modarray wl2017-11-19T20:50:13ZSven-Bodo Scholzwl partition generation fails on akd outer aud inner modarray wl| | |
| --- | --- |
| Bugzilla Link | [319](http://bugs.sac-home.org/show_bug.cgi?id=319) |
| Created on | Nov 10, 2006 14:10 |
| Resolution | FIXED |
| Resolved on | Nov 19, 2009 00:18 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [319](http://bugs.sac-home.org/show_bug.cgi?id=319) |
| Created on | Nov 10, 2006 14:10 |
| Resolution | FIXED |
| Resolved on | Nov 19, 2009 00:18 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | Other |
| Attachments | [bug.sac](/uploads/8b7c6f1cce2957ea6bfa806d0f6e7fab/bug.sac) |
## Extended Description
<pre>with sac2c rev 15081 we obtain
ASSERTION FAILED: file 'src/flatten/WLPartitionGeneration.c', line 1534
With-loop with non-AKS elements encountered.
Default-element is required!
EXECUTION TERMINATED
Abort
for the attached example program.</pre>BugZillaBugZilla