sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T21:13:33Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1666Presence of automatically derived AKS instance prevents dispatch to AKD instance2017-11-19T21:13:33ZKai TrojahnerPresence of automatically derived AKS instance prevents dispatch to AKD instance| | |
| --- | --- |
| Bugzilla Link | [181](http://bugs.sac-home.org/show_bug.cgi?id=181) |
| Created on | Jan 05, 2006 11:05 |
| Resolution | FIXED |
| Resolved on | Aug 09, 2006 10:08 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [181](http://bugs.sac-home.org/show_bug.cgi?id=181) |
| Created on | Jan 05, 2006 11:05 |
| Resolution | FIXED |
| Resolved on | Aug 09, 2006 10:08 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [selbug.sac](/uploads/f40635862fb8fdb46489b73e5459acc2/selbug.sac) |
## Extended Description
rev 14508, see attachmentSven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1369Performance of sel sucks big time due to lack of AKD IVE2017-11-19T20:43:38ZKai TrojahnerPerformance of sel sucks big time due to lack of AKD IVE| | |
| --- | --- |
| Bugzilla Link | [182](http://bugs.sac-home.org/show_bug.cgi?id=182) |
| Created on | Jan 05, 2006 11:52 |
| Resolution | REMIND |
| Resolved on | Jan 11, 2006 12:19 |
| Version | 1.00beta |
| OS | Linux |
| Archit...| | |
| --- | --- |
| Bugzilla Link | [182](http://bugs.sac-home.org/show_bug.cgi?id=182) |
| Created on | Jan 05, 2006 11:52 |
| Resolution | REMIND |
| Resolved on | Jan 11, 2006 12:19 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [selbug.sac](/uploads/5d0efe44cec89fe198a7f53a40673209/selbug.sac) |
## Extended Description
<pre>rev 14508. The performance of the attached example is seriously degraded due
argument a being AKD. With no with-loops present, the sole reason for the bad
performance is IVE's inability to optimize accesses to array a.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1370Strange compiler diagnostic2017-11-19T20:43:45ZRobert BerneckyStrange compiler diagnostic| | |
| --- | --- |
| Bugzilla Link | [183](http://bugs.sac-home.org/show_bug.cgi?id=183) |
| Created on | Jan 09, 2006 04:54 |
| Resolution | DUPLICATE |
| Resolved on | Jan 09, 2006 15:43 |
| Version | 1.00beta |
| OS | Linux |
| Arc...| | |
| --- | --- |
| Bugzilla Link | [183](http://bugs.sac-home.org/show_bug.cgi?id=183) |
| Created on | Jan 09, 2006 04:54 |
| Resolution | DUPLICATE |
| Resolved on | Jan 09, 2006 15:43 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTBaseRep.sac](/uploads/8152d2faf55a1fc5e6088a50fa9bb1d8/UTBaseRep.sac), [crud.sac](/uploads/fe0ef53d6f3859776cd9bfff87033e99/crud.sac), [crud.txt](/uploads/672d270ab4da736be9280c291dbbbc07/crud.txt) |
## Extended Description
<pre>When I compile the attached .sac program, several interesting things happen:
1. If I compile UTBaseRep.sac, it spends a LONG time trying to optimize
main(), then eventually dies, complaining about _sel_ conformability
requrirements, which is very likely a legitimate source program bug.
2. If I compile crud.sac, I get the grumpy compiler failure noted in crud.txt.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1371loss of type precision due to fun2lac + lac2fun2017-11-19T20:43:52ZSven-Bodo Scholzloss of type precision due to fun2lac + lac2fun| | |
| --- | --- |
| Bugzilla Link | [184](http://bugs.sac-home.org/show_bug.cgi?id=184) |
| Created on | Jan 09, 2006 15:30 |
| Resolution | FIXED |
| Resolved on | Nov 20, 2009 01:22 |
| Version | 1.00beta |
| OS | All |
| Architect...| | |
| --- | --- |
| Bugzilla Link | [184](http://bugs.sac-home.org/show_bug.cgi?id=184) |
| Created on | Jan 09, 2006 15:30 |
| Resolution | FIXED |
| Resolved on | Nov 20, 2009 01:22 |
| Version | 1.00beta |
| OS | All |
| Architecture | PC |
| Attachments | [tutu.sac](/uploads/ce66d1966b1fecb5231b67c1034d1d9b/tutu.sac) |
## Extended Description
<pre>This is a spin off bug from #180.
We potentilly loose type precision when converting
from and to SSA form.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1549sac2c crashes during C code generation2017-11-19T21:01:43ZRobert Berneckysac2c crashes during C code generation| | |
| --- | --- |
| Bugzilla Link | [185](http://bugs.sac-home.org/show_bug.cgi?id=185) |
| Created on | Jan 10, 2006 21:35 |
| Resolution | FIXED |
| Resolved on | Jan 12, 2006 16:07 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [185](http://bugs.sac-home.org/show_bug.cgi?id=185) |
| Created on | Jan 10, 2006 21:35 |
| Resolution | FIXED |
| Resolved on | Jan 12, 2006 16:07 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [primes.sac](/uploads/e5e0bde7c49ae43916eb602779460472/primes.sac), [xprimes.sac](/uploads/48a3e20d65844ebb85fafcc90457f33a/xprimes.sac) |
## Extended Description
Code gen crashKai TrojahnerKai Trojahnerhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1667confusing error message2017-11-19T21:13:39ZRobert Berneckyconfusing error message| | |
| --- | --- |
| Bugzilla Link | [186](http://bugs.sac-home.org/show_bug.cgi?id=186) |
| Created on | Jan 11, 2006 22:46 |
| Resolution | WONTFIX |
| Resolved on | Nov 19, 2009 00:13 |
| Version | 1.00beta |
| OS | Linux |
| Archi...| | |
| --- | --- |
| Bugzilla Link | [186](http://bugs.sac-home.org/show_bug.cgi?id=186) |
| Created on | Jan 11, 2006 22:46 |
| Resolution | WONTFIX |
| Resolved on | Nov 19, 2009 00:13 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This message comes from sac2c now and then, when my coding fingers haven't been
sharpened recently:
line 196
ERROR: argument #2 of "_modarray_" should be legal index into argument #1;
ERROR: types found: int[1]{0} and bool[0]
The problem is that the argument numbers are #2, #1, so it is not at
all clear (particularly when the line number is completely wrong) whether
the types are in order #2 #1 or #1 #2. Perhaps something along these
lines would be less confusing:
ERROR: Argument #2 ( int[1]{0} ) of "_modarray_" should be legal
index into argument #2 ( bool[0] ).</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1668inconsistent type terminates sac2c w/extreme predjudice2017-11-19T21:13:45ZRobert Berneckyinconsistent type terminates sac2c w/extreme predjudice| | |
| --- | --- |
| Bugzilla Link | [187](http://bugs.sac-home.org/show_bug.cgi?id=187) |
| Created on | Jan 11, 2006 23:57 |
| Resolution | FIXED |
| Resolved on | Jan 12, 2006 11:48 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [187](http://bugs.sac-home.org/show_bug.cgi?id=187) |
| Created on | Jan 11, 2006 23:57 |
| Resolution | FIXED |
| Resolved on | Jan 12, 2006 11:48 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTCompress.sac](/uploads/6377e698898e01acd28c5a9cbcf00fef/UTCompress.sac), [xUTCompress.sac](/uploads/0ac22f1fc133600937d2d841e12a1627/xUTCompress.sac) |
## Extended Description
<pre>****** main( ): ...
ASSERTION FAILED: file 'ct_basic.c', line 92
inconsistent type in NTCCTcomputeType!
EXECUTION TERMINATED
./foo: line 6: 2696 Aborted sac2c -O3 -o $1 $1.sac
Source file is attachment.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1550the compilation of in/out parameters is screwed up2017-11-19T21:01:49ZStephan Herhutthe compilation of in/out parameters is screwed up| | |
| --- | --- |
| Bugzilla Link | [188](http://bugs.sac-home.org/show_bug.cgi?id=188) |
| Created on | Jan 13, 2006 10:37 |
| Resolution | FIXED |
| Resolved on | Jan 13, 2006 17:08 |
| Version | 1.00beta |
| OS | Solaris |
| Archi...| | |
| --- | --- |
| Bugzilla Link | [188](http://bugs.sac-home.org/show_bug.cgi?id=188) |
| Created on | Jan 13, 2006 10:37 |
| Resolution | FIXED |
| Resolved on | Jan 13, 2006 17:08 |
| Version | 1.00beta |
| OS | Solaris |
| Architecture | Sun |
| Attachments | [inout.sac](/uploads/40fa0b2647ac4e3f6a0447428ed2eba5/inout.sac) |
## Extended Description
<pre>The (soon to be) attached module gives an example. In/out args of the form
a = foo( b)
are compiled to
foo( &b)
which is quite a rude change to the semantics if a != b...</pre>Kai TrojahnerKai Trojahnerhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1669subtle dispatch problem for modarray2017-11-19T21:13:51ZRobert Berneckysubtle dispatch problem for modarray| | |
| --- | --- |
| Bugzilla Link | [189](http://bugs.sac-home.org/show_bug.cgi?id=189) |
| Created on | Jan 13, 2006 21:38 |
| Resolution | FIXED |
| Resolved on | Jan 20, 2006 12:32 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [189](http://bugs.sac-home.org/show_bug.cgi?id=189) |
| Created on | Jan 13, 2006 21:38 |
| Resolution | FIXED |
| Resolved on | Jan 20, 2006 12:32 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTExpand.sac](/uploads/deec73fdf81b68ea056437e46e916fda/UTExpand.sac) |
## Extended Description
<pre>The attached example kills sac2c with one of those grumpy, incomprehensible
messages about types.
If you look at the computation of shpz in bslBBB, you'll see an expression
along the lines of:
z=genarray (shape(x)++drop([1],shape(y)), false);
If you replace this with:
shpz = shape(y);
shpz[0] = shape(x)[0];
z = genarray(shpz,false);
that works. I don't understand why one approach works and the other does not.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2144take code sucks dead bears on overtake.2017-11-19T22:02:01ZRobert Berneckytake code sucks dead bears on overtake.| | |
| --- | --- |
| Bugzilla Link | [190](http://bugs.sac-home.org/show_bug.cgi?id=190) |
| Created on | Jan 13, 2006 22:51 |
| Resolution | FIXED |
| Resolved on | Jan 19, 2006 15:10 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [190](http://bugs.sac-home.org/show_bug.cgi?id=190) |
| Created on | Jan 13, 2006 22:51 |
| Resolution | FIXED |
| Resolved on | Jan 19, 2006 15:10 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud2.sac](/uploads/6e180d857931f987c38eef2ef2eee01e/crud2.sac) |
## Extended Description
<pre>The code in ArrayTransform.sac ain't quite there.
I'll try to look at it tomorrow and come up with something
a bit more betterer than what's there.
The attachment shows some of what's wrong with it.
Computation of "offset", at least, looks dicey, and
the WL indexing is plain wrong for overtake.
take([-3,4], reshape([2,2],[12, 13, 14,15]))
should produce:
0 0 0 0
12 13 0 0
14 15 0 0</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1611bug code kills sac2c uniqueness thingy2017-11-19T21:07:51ZRobert Berneckybug code kills sac2c uniqueness thingy| | |
| --- | --- |
| Bugzilla Link | [191](http://bugs.sac-home.org/show_bug.cgi?id=191) |
| Created on | Jan 18, 2006 18:21 |
| Resolution | FIXED |
| Resolved on | Jan 20, 2006 12:36 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [191](http://bugs.sac-home.org/show_bug.cgi?id=191) |
| Created on | Jan 18, 2006 18:21 |
| Resolution | FIXED |
| Resolved on | Jan 20, 2006 12:36 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTIndexSet.sac](/uploads/65c0f97682997d239f1d816e0820213f/UTIndexSet.sac) |
## Extended Description
<pre>Attached kills sac2c in phase 8 with sac2c -O3.</pre>Stephan HerhutStephan Herhuthttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1372type checker dies with useless error messaege2017-11-19T20:43:58ZRobert Berneckytype checker dies with useless error messaege| | |
| --- | --- |
| Bugzilla Link | [192](http://bugs.sac-home.org/show_bug.cgi?id=192) |
| Created on | Jan 18, 2006 23:39 |
| Resolution | INVALID |
| Resolved on | Jan 20, 2006 23:30 |
| Version | 1.00beta |
| OS | Linux |
| Archi...| | |
| --- | --- |
| Bugzilla Link | [192](http://bugs.sac-home.org/show_bug.cgi?id=192) |
| Created on | Jan 18, 2006 23:39 |
| Resolution | INVALID |
| Resolved on | Jan 20, 2006 23:30 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTIndexSet.sac](/uploads/ede7a16f8f90630515cea761afd35248/UTIndexSet.sac), [xUTIndexSet.sac](/uploads/f9bf1167aeb199d6debef9058774868b/xUTIndexSet.sac) |
## Extended Description
<pre>I've griped about this before, but here I have a typechecker
complaint about a typing problem in a 947-line sac program.
There is NO information about where I might try starting to locate the
fault.
Even a teensy, weensy suggestion from the compiler as to what function(s)
it might have been looking at would help a LOT!</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1373Two bugs for the price of one2017-11-19T20:44:05ZRobert BerneckyTwo bugs for the price of one| | |
| --- | --- |
| Bugzilla Link | [193](http://bugs.sac-home.org/show_bug.cgi?id=193) |
| Created on | Jan 20, 2006 19:03 |
| Resolution | INVALID |
| Resolved on | Jan 24, 2006 22:49 |
| Version | 1.00beta |
| OS | Linux |
| Archi...| | |
| --- | --- |
| Bugzilla Link | [193](http://bugs.sac-home.org/show_bug.cgi?id=193) |
| Created on | Jan 20, 2006 19:03 |
| Resolution | INVALID |
| Resolved on | Jan 24, 2006 22:49 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTIndexSet.sac](/uploads/3b68522edb3170404d5ca00b292abc5d/UTIndexSet.sac) |
## Extended Description
<pre>The attached fails in phase 9 of sac2c with illegal prf, if compiled with -O3.
If you compile it this way:
sac2c -DBUG UTIndexSet.sac
you get a failure due to someone not noticing that Y has been reassigned in
the function body.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1580WLPROP problem2017-11-19T21:04:50ZRobert BerneckyWLPROP problem| | |
| --- | --- |
| Bugzilla Link | [194](http://bugs.sac-home.org/show_bug.cgi?id=194) |
| Created on | Jan 20, 2006 19:46 |
| Resolution | FIXED |
| Resolved on | Jan 27, 2006 14:22 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [194](http://bugs.sac-home.org/show_bug.cgi?id=194) |
| Created on | Jan 20, 2006 19:46 |
| Resolution | FIXED |
| Resolved on | Jan 27, 2006 14:22 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [SACbugreport](/uploads/e1b729d3a63b92a59d5f3eb01dc85f63/SACbugreport) |
## Extended Description
This merely kills sac2c somewhere in or after WLUR happenings.Michael WernerMichael Wernerhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1551reference counting dies on loop1.sac2017-11-19T21:01:54ZStephan Herhutreference counting dies on loop1.sac| | |
| --- | --- |
| Bugzilla Link | [195](http://bugs.sac-home.org/show_bug.cgi?id=195) |
| Created on | Jan 20, 2006 21:37 |
| Resolution | DUPLICATE |
| Resolved on | Jan 20, 2006 23:24 |
| Version | 1.00beta |
| OS | Linux |
| Arc...| | |
| --- | --- |
| Bugzilla Link | [195](http://bugs.sac-home.org/show_bug.cgi?id=195) |
| Created on | Jan 20, 2006 21:37 |
| Resolution | DUPLICATE |
| Resolved on | Jan 20, 2006 23:24 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
sac2c dies with a segfault in referencecounting.c:207Kai TrojahnerKai Trojahnerhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1552refcounting crash kills several demos2017-11-19T21:02:00ZSven-Bodo Scholzrefcounting crash kills several demos| | |
| --- | --- |
| Bugzilla Link | [196](http://bugs.sac-home.org/show_bug.cgi?id=196) |
| Created on | Jan 20, 2006 23:21 |
| Resolution | FIXED |
| Resolved on | Jan 26, 2006 10:32 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [196](http://bugs.sac-home.org/show_bug.cgi?id=196) |
| Created on | Jan 20, 2006 23:21 |
| Resolution | FIXED |
| Resolved on | Jan 26, 2006 10:32 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Masterrun from Fri Jan 20 17:35:07 GMT 2006 shows several crashes.
Quick check shows:
** 14: Introducing explicit memory management instructions ...
**** AUD/SCL distinction ...
**** Making copy operations explicit ...
**** Introducing explicit allocation statements ...
**** Removing dead code ...
**** Inferring reuse candidates ...
**** Interface aliasing analysis ...
**** Applying loop reuse optimization ...
**** Aliasing analysis ...
**** Filtering reuse candidates ...
**** Static reuse ...
**** Introducing reuse branches ...
**** Identfying in-place updates ...
**** Exploiting data reuse ...
**** Removing dead code ...
**** Reference counting ...
OOOPS your program crashed the compiler 8-((
Please send a bug report to bugs@sac-home.org.
For your convenience, the compiler has pre-fabricated a bug report in
the file "SACbugreport" which was created in the current directory!
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 use
for several cases....
most likely the origin of several new bugs (#19x)</pre>Kai TrojahnerKai Trojahnerhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1670conceptual problem with ... return values2017-11-19T21:13:56ZStephan Herhutconceptual problem with ... return values| | |
| --- | --- |
| Bugzilla Link | [197](http://bugs.sac-home.org/show_bug.cgi?id=197) |
| Created on | Jan 26, 2006 13:26 |
| Resolution | FIXED |
| Resolved on | Jan 27, 2006 14:49 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [197](http://bugs.sac-home.org/show_bug.cgi?id=197) |
| Created on | Jan 26, 2006 13:26 |
| Resolution | FIXED |
| Resolved on | Jan 27, 2006 14:49 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Compiling module ScalarIO lead to the following error message:
ABORT: line 643 file: ScalarIO.sac
ABORT: Cannot infer type of "result" as it corresponds to "..." return type
ABORT: -- missing type declaration
This is due to the fact that the source code of function scanchar, which
includes a declaration for the type of result, is transformed in phase 5. The
original code looks like:
inline bool, char scanchar()
{
char result;
success, result=TermFile::scanf("%c");
return(success==1, result);
}
After transformation we get:
inline
#189: in [ --, Terminal::Terminal] le <> ge <>, #190: in [ --,
TermFile::TermFile] le <> ge <>, #191: in [ --, bool[*]] le <> ge <>, #192: in [
--, char[*]] le <> ge <> ScalarIO::scanchar( Terminal::Terminal
_rso_322_TheTerminal, TermFile::TermFile _rso_321_stdin)
/*
* scanchar :: ---
*/
{
unknown[*] _flat_9__SSA0_1; /* (null) */
unknown[*] result__SSA0_2; /* (null) */
unknown[*] result__SSA0_1; /* (null) */
unknown[*] _rso_321_stdin__SSA0_1; /* (null) */
unknown[*] _rso_322_TheTerminal__SSA0_1; /* (null) */
unknown[*] _flat_9; /* (null) */
unknown[*] _flat_10; /* (null) */
unknown[*] success; /* (null) */
unknown[*] _flat_6; /* (null) */
unknown[*] _flat_7; /* (null) */
unknown[*] _flat_8; /* (null) */
unknown[*] result; /* (null) */
_flat_8 = 2;
_flat_7 = [ '%', 'c', '\0' ];
_flat_6 = wrapper:String::to_string( _flat_7, _flat_8);
_rso_322_TheTerminal__SSA0_1, _rso_321_stdin__SSA0_1, success, result =
wrapper:TermFile::scanf( _rso_322_TheTerminal, _rso_321_stdin, _flat_6);
result__SSA0_1 = type_conv( char, result);
_flat_10 = 1;
_flat_9 = wrapper:ScalarArith::==( success, _flat_10);
result__SSA0_2 = type_conv( char, result__SSA0_1);
_flat_9__SSA0_1 = type_conv( bool, _flat_9);
return( _rso_322_TheTerminal__SSA0_1, _rso_321_stdin__SSA0_1, _flat_9__SSA0_1,
result__SSA0_2);
}
The original declaration has thus been transformed into a type_conv. This leads
to the given error message, as no declared type is available for result...</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1374errorneous bottom type propagation2017-11-19T20:44:10ZRobert Berneckyerrorneous bottom type propagation| | |
| --- | --- |
| Bugzilla Link | [198](http://bugs.sac-home.org/show_bug.cgi?id=198) |
| Created on | Jan 30, 2006 01:56 |
| Resolution | FIXED |
| Resolved on | Jan 30, 2006 16:23 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [198](http://bugs.sac-home.org/show_bug.cgi?id=198) |
| Created on | Jan 30, 2006 01:56 |
| Resolution | FIXED |
| Resolved on | Jan 30, 2006 16:23 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud2.sac](/uploads/6936d3da5932ad79e700700b7e6c64ea/crud2.sac) |
## Extended Description
<pre>The attached "times-scan" fails under sac2c -O3.
I'm not sure how to fix it. Basically, the function
should return all partial times-reductions for
the argument. It works OK on non-empty arrays, but fails for
empties.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1375error message needs help2017-11-19T20:44:16ZRobert Berneckyerror message needs help| | |
| --- | --- |
| Bugzilla Link | [199](http://bugs.sac-home.org/show_bug.cgi?id=199) |
| Created on | Jan 30, 2006 18:36 |
| Resolution | INVALID |
| Resolved on | May 11, 2006 19:21 |
| Version | 1.00beta |
| OS | Linux |
| Archi...| | |
| --- | --- |
| Bugzilla Link | [199](http://bugs.sac-home.org/show_bug.cgi?id=199) |
| Created on | Jan 30, 2006 18:36 |
| Resolution | INVALID |
| Resolved on | May 11, 2006 19:21 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTBaseRep.sac](/uploads/6e3c7c7eb11352a2c2730cf8bb4533a5/UTBaseRep.sac) |
## Extended Description
<pre>The attached, compiled with -O3, complains about
negative shape elements in a with-loop. However, the
source code line# it gives is not correct.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1553Mystery memory-eater in for loop?2017-11-19T21:02:07ZRobert BerneckyMystery memory-eater in for loop?| | |
| --- | --- |
| Bugzilla Link | [200](http://bugs.sac-home.org/show_bug.cgi?id=200) |
| Created on | Jan 31, 2006 00:18 |
| Resolution | FIXED |
| Resolved on | Feb 02, 2006 17:00 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [200](http://bugs.sac-home.org/show_bug.cgi?id=200) |
| Created on | Jan 31, 2006 00:18 |
| Resolution | FIXED |
| Resolved on | Feb 02, 2006 17:00 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [rle.sac](/uploads/4b6354d2dc50aa8ef72c3c5c64f5e441/rle.sac), [mdiv.sac](/uploads/c53ea308178285dc2b5e0db9f4643fbf/mdiv.sac), [crud5.sac](/uploads/007ec460adfced1038f5695c080b5256/crud5.sac), [sliii.sac](/uploads/8bbf3cce40ca7d2e1f002ae2f3c7bc6c/sliii.sac) |
## Extended Description
<pre>I'm not sure what's going on with the attached, but
it dies at run-time, apparently in the middle of what
looks like an innocent FOR loop, unable to allocate
about 1 MB of memory, or so says the SAC run-time.
The function slIII is the apparent villain, with sac2c -O3.
Compiling with -check tb -noOPT fails in a similar way,
but the system gets in a memory thrash (1.3 GB and rising)
before the FOR loop completes.
The slIII function starts, but never finishes, if the embedded
print statements are to be believed.</pre>Kai TrojahnerKai Trojahner