sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:50:19Zhttps://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/1686conv. to/from scalar if maxwlir>12017-11-19T21:15:40ZRobert Berneckyconv. to/from scalar if maxwlir>1| | |
| --- | --- |
| Bugzilla Link | [326](http://bugs.sac-home.org/show_bug.cgi?id=326) |
| Created on | Nov 19, 2006 05:03 |
| Resolution | DUPLICATE |
| Resolved on | May 11, 2007 12:34 |
| Version | 1.00beta |
| OS | Linux |
| Arc...| | |
| --- | --- |
| Bugzilla Link | [326](http://bugs.sac-home.org/show_bug.cgi?id=326) |
| Created on | Nov 19, 2006 05:03 |
| Resolution | DUPLICATE |
| Resolved on | May 11, 2007 12:34 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud2.sac](/uploads/1773998b342e715f9be96212a74332c4/crud2.sac), [UTJotDot.sac](/uploads/96cc02394bc78cfaa68ba6331cd8109a/UTJotDot.sac), [crud.sac](/uploads/b18386c2d1d9399ef805d1e232fe5573/crud.sac), [UTReduce.sac](/uploads/879ff6fb4064de1e1848cd417977512f/UTReduce.sac) |
## Extended Description
<pre>The attached compiles and executes OK with -noopt or with -maxwlur 1 or 0.
If compiled with default options, phase 15 dies with "conv. to/from scalar".</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1621set notation does not handle nested scopes correctly2017-11-19T21:08:53ZStephan Herhutset notation does not handle nested scopes correctly| | |
| --- | --- |
| Bugzilla Link | [327](http://bugs.sac-home.org/show_bug.cgi?id=327) |
| Created on | Nov 21, 2006 20:11 |
| Resolution | FIXED |
| Resolved on | Feb 28, 2007 15:59 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [327](http://bugs.sac-home.org/show_bug.cgi?id=327) |
| Created on | Nov 21, 2006 20:11 |
| Resolution | FIXED |
| Resolved on | Feb 28, 2007 15:59 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [setnotation.sac](/uploads/ae85f2afa829cf65a5c3587450b74025/setnotation.sac) |
## Extended Description
test case coming soon....Stephan HerhutStephan Herhuthttps://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/1486Different -xxphm setting in stdlib and program lead to memory corruption2017-11-19T20:55:27ZKai TrojahnerDifferent -xxphm setting in stdlib and program lead to memory corruption| | |
| --- | --- |
| Bugzilla Link | [329](http://bugs.sac-home.org/show_bug.cgi?id=329) |
| Created on | Nov 24, 2006 10:21 |
| Resolution | FIXED |
| Resolved on | May 10, 2007 16:03 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [329](http://bugs.sac-home.org/show_bug.cgi?id=329) |
| Created on | Nov 24, 2006 10:21 |
| Resolution | FIXED |
| Resolved on | May 10, 2007 16:03 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This tiny program crashes, if I compile the stdlib with -dophm and the program
itself with -nophm
use ScalarIO: {print};
int main()
{
print(2);
return(0);
}</pre>Clemens GrelckClemens Grelckhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1587product version loops in lVEI loop4p.sac2017-11-19T21:05:33ZSven-Bodo Scholzproduct version loops in lVEI loop4p.sac| | |
| --- | --- |
| Bugzilla Link | [330](http://bugs.sac-home.org/show_bug.cgi?id=330) |
| Created on | Nov 29, 2006 09:39 |
| Resolution | FIXED |
| Resolved on | Nov 30, 2006 18:42 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [330](http://bugs.sac-home.org/show_bug.cgi?id=330) |
| Created on | Nov 29, 2006 09:39 |
| Resolution | FIXED |
| Resolved on | Nov 30, 2006 18:42 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The masterrun applies the product version in the following way to loop4p.sac of
the livermoore_loops:
sac2c -O3 -v1 -maxlur 3 -noCSE -o loop4p loop4p.sac
on asterix this has been running since 10 days now!
attaching gdb yields: it seems to loop in IVEI!
This inhibits the full masterrun!!</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1687memory intensive wrapper type representation2017-11-19T21:15:45ZRobert Berneckymemory intensive wrapper type representation| | |
| --- | --- |
| Bugzilla Link | [331](http://bugs.sac-home.org/show_bug.cgi?id=331) |
| Created on | Nov 29, 2006 23:48 |
| Resolution | REMIND |
| Resolved on | Nov 30, 2006 09:35 |
| Version | 1.00beta |
| OS | Linux |
| Archit...| | |
| --- | --- |
| Bugzilla Link | [331](http://bugs.sac-home.org/show_bug.cgi?id=331) |
| Created on | Nov 29, 2006 23:48 |
| Resolution | REMIND |
| Resolved on | Nov 30, 2006 09:35 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
I'm trying to test a fix to IVE performance problems, and tried to
compile demos/livermore/loop8p.sac. It eventually used up about 3.5GB of dram,
then ran out of system memory.
This using standard make options.
For such a dinky program, this is not good news...Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1563compiotad slowdown after switch from SCI to SAA; LIR not being performed any ...2017-11-19T21:03:11ZRobert Berneckycompiotad slowdown after switch from SCI to SAA; LIR not being performed any more| | |
| --- | --- |
| Bugzilla Link | [332](http://bugs.sac-home.org/show_bug.cgi?id=332) |
| Created on | Dec 02, 2006 15:15 |
| Resolution | FIXED |
| Resolved on | Nov 19, 2007 04:30 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [332](http://bugs.sac-home.org/show_bug.cgi?id=332) |
| Created on | Dec 02, 2006 15:15 |
| Resolution | FIXED |
| Resolved on | Nov 19, 2007 04:30 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>As I noted two days ago, I saw some performance loss in a few
benchmarks after I released the IVE->SSA changes (build#15110), compared
to build#15093. As an example, compiotad.sac ran about 750msec
before, and 950msec afterwards.
I backed up to build #15093, and that version ran in 736-764msec.
I then compared various versions, as noted later. I also broke the
compiler at -b11 for #15111 (today) and #15100.
I have not looked at everything in detail, but I did note that,
near the end of the code, the computation of y[i] is no
longer being LIR'd upwards.
In fact, the computation of y[i] is invariant up to main, yet
y and i are passed through several laters of cond/loop fns...
Along the way, I noted other build times:
- 15093 736-764msec
- 15100 684-804msec
- 15101 2156-2244msec (could be related to not doing -doisv?)
- 15102 2160-2268msec (ditto)
- 15104 916-960msec
- 15109 908-996msec (w/ -doisv! Otherwise 4 seconds!
- 14111(today) 900-940msec
Clearly, things slowed down after 15100.
The change at version 15101 was to replace SCI with SAA as the driving
force behind IVE. That suggests that SAA is missing some inference
here, but both codes have replaced all sel() ops with _idx_sels.
But I don't see the connection between LIR and my shape_cliques.c
change.
---- later on ----
I again reverted to 15104(the one where I switched from using SCI to
using SAA).
I then ran the compiotad.sac test, then patched the return value in
shape_cliques.c to use SCI rather than SAA as the IVE driver, and got
this interesting result:
IVE w/SAA: 864-1024msec
IVE w/SCI: 732-816msec
Clearly, SAA is missing an inference. A diff at phase -b11 tells the
tale clearly (I've also attached the two .out files):
196a197
> int _ive_6988__pinl_6505__iv;
197a199
> int _ive_6986__pinl_3483__iv;
211c213,214
< _pinl_3512____flat_127 = idx_sel( _wlidx_6982__pinl_3487__z,
_pinl_3521___res);
---
> _ive_6986__pinl_3483__iv = idxs2offset( [ 40000000 ],
_pinl_3488___eat_218);
> _pinl_3512____flat_127 = idx_sel( _ive_6986__pinl_3483__iv,
_pinl_3521___res);
229c232,233
< _pinl_6845___flat_721__SSA7_1__SSA8_1 =
idx_sel( _wlidx_6984__pinl_6448_intx, _pinl_6852__z);
---
> _ive_6988__pinl_6505__iv = idxs2offset( [ 40000000 ],
_pinl_6508___eat_210);
> _pinl_6845___flat_721__SSA7_1__SSA8_1 =
idx_sel( _ive_6988__pinl_6505__iv, _pinl_6852__z);
This explains why compiotad is running slower, but it does not
explain why LIR is not being performed.</pre>Kai TrojahnerKai Trojahnerhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2148strange compile error when using modules instead of include files2017-11-19T22:02:24ZMarkus Weigelstrange compile error when using modules instead of include files| | |
| --- | --- |
| Bugzilla Link | [333](http://bugs.sac-home.org/show_bug.cgi?id=333) |
| Created on | Dec 05, 2006 15:13 |
| Resolution | FIXED |
| Resolved on | Dec 07, 2006 11:04 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [333](http://bugs.sac-home.org/show_bug.cgi?id=333) |
| Created on | Dec 05, 2006 15:13 |
| Resolution | FIXED |
| Resolved on | Dec 07, 2006 11:04 |
| Version | svn |
| OS | Linux |
| Architecture | Other |
## Extended Description
<pre>I observed a strange compile error (actually a linker error) when separating
some of my own sac functions (in this example: double2GrayLevels) from the file
containing the main function. I created a new module (in the following examples
"MyModule") in which I placed double2GrayLevels. When trying to "use" MyModule
in the main file, I get several similar error messages of the form
: In function `SACwf_String__tos__b_S':
: undefined reference to `SACbtos'
Using an include file instead of the module will cause these error messages to
vanish, which seems rather strange to me.
Additionally, when exchanging some statements in function main, the error will
also vanish. I added some special comments on those lines in the source code.
compiler flags: -O3 -nophm -E/opt/local/lib
Files: MyModule.sac, MyModule_incl.sac, module_xmpl.sac
------------------------------------------------------------------------
MyModule.sac:
module MyModule;
use Structures: all;
/* export all; */
provide {double2GrayLevels};
/* Converts an array of double values to an array of
* graylevel colors ranging from 0 to 255 */
color[*] double2GrayLevels(double[*] image) {
/* determine minimum and maximum values */
min = minval(image);
max = maxval(image);
/* normalize double values */
image = (image - min)*(255.0/(max-min));
/* convert image to array of color values */
image_gray =
with {
( . <= iv <= . ): newColor(genarray([3],toi(image[iv])));
} : genarray(shape(image),black());
return(image_gray);
}
/* Converts an array of doubles to an array of
* graylevels unsing a Hounsfield window. Values below
* winMin will be set to zero, values above winMax will
* be set to 255. All intermediate values will be scaled
* between 0 and 255. */
color[*] double2GrayLevels(double[*] image, double winMin, double winMax) {
/* Scale double values */
image = (image - winMin)*(255.0/(winMax-winMin));
/* convert image to array of color values */
image_gray =
with {
( . <= iv <= . ) { color = toi(image[iv]);
if (color < 0) color=0;
if (color > 255) color=255;
}: newColor(genarray([3],color));
}: genarray(shape(image),black());
return(image_gray);
}
------------------------------------------------------------------------
MyModule_incl.sac:
/*module MyModule;
use Structures: all;*/
/* export all; */
/*provide {double2GrayLevels}; */
/* Converts an array of double values to an array of
* graylevel colors ranging from 0 to 255 */
color[*] double2GrayLevels(double[*] image) {
/* determine minimum and maximum values */
min = minval(image);
max = maxval(image);
/* normalize double values */
image = (image - min)*(255.0/(max-min));
/* convert image to array of color values */
image_gray =
with {
( . <= iv <= . ): newColor(genarray([3],toi(image[iv])));
} : genarray(shape(image),black());
return(image_gray);
}
/* Converts an array of doubles to an array of
* graylevels unsing a Hounsfield window. Values below
* winMin will be set to zero, values above winMax will
* be set to 255. All intermediate values will be scaled
* between 0 and 255. */
color[*] double2GrayLevels(double[*] image, double winMin, double winMax) {
/* Scale double values */
image = (image - winMin)*(255.0/(winMax-winMin));
/* convert image to array of color values */
image_gray =
with {
( . <= iv <= . ) { color = toi(image[iv]);
if (color < 0) color=0;
if (color > 255) color=255;
}: newColor(genarray([3],color));
}: genarray(shape(image),black());
return(image_gray);
}
------------------------------------------------------------------------
module_xmpl.sac:
use StdIO: all;
import Array: all;
import Structures: all;
use SDLdisplay: all;
/* compile error arises if we use the module MyModule. If we use
* the include file instead, the error vanishes */
use MyModule: all;
/* #include "MyModule_incl.sac" */
double[*] foo(int[.] shp) {
return(genarray(shp,0d));
}
void foo2(color[*] arr) {
/* do not do anything interesting */
a = 1;
}
int main() {
shp = [64,64];
/* open file */
errcode, fd = binfopen("/any/file/you/like",
O_RDONLY());
/* read 2D image as an array of doubles */
image_2D = binfReadDoubleArray(fd,shape(shp)[[0]],shp);
/* uncomment one of the following lines and
* the compiler error will vanish */
/* image_2D = foo(shp); */
/* image_2D = genarray(shp,1d); */
/* initialize display */
disp = initDisplay(take([2],shp));
gl = double2GrayLevels(image_2D);
/* unsing foo2 here instead of drawArray will cause the
* compile error to vanish */
/* foo2(gl); */
drawArray(disp,gl);
destroyDisplay(disp);
return(0);
}</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2149segmentation fault when reading from streams2017-11-19T22:02:29ZMarkus Weigelsegmentation fault when reading from streams| | |
| --- | --- |
| Bugzilla Link | [335](http://bugs.sac-home.org/show_bug.cgi?id=335) |
| Created on | Dec 11, 2006 18:06 |
| Resolution | FIXED |
| Resolved on | Dec 12, 2006 10:46 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [335](http://bugs.sac-home.org/show_bug.cgi?id=335) |
| Created on | Dec 11, 2006 18:06 |
| Resolution | FIXED |
| Resolved on | Dec 12, 2006 10:46 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I encountered a segmentation fault when trying to read a string from a text file
and sending it to StdIO. I am not sure wether this is my mistake (am I required
to allocate memory for strings?) or the compiler's.
Try this example:
use StdIO: all;
/* input example:
filename: 2DBild1.dat
dimension: 2
omega1: 64
omega2: 64
m1: 64
m2: 64
representation format: double
*/
int main() {
err, stream = fopen("text1.txt","r");
/* Try to read "filename:" */
s = fscans(stream,20);
printf(s);
fclose(stream);
return(0);
}</pre>Clemens GrelckClemens Grelckhttps://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/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/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/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/1509saa relies on dcr but is not suppressed if noDCR!2017-11-19T20:57:45ZSven-Bodo Scholzsaa relies on dcr but is not suppressed if noDCR!| | |
| --- | --- |
| Bugzilla Link | [340](http://bugs.sac-home.org/show_bug.cgi?id=340) |
| Created on | Jan 18, 2007 14:11 |
| Resolution | FIXED |
| Resolved on | Jan 23, 2007 10:23 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [340](http://bugs.sac-home.org/show_bug.cgi?id=340) |
| Created on | Jan 18, 2007 14:11 |
| Resolution | FIXED |
| Resolved on | Jan 23, 2007 10:23 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>try to compile:
int main()
{
a = "huhu";
return(0);
}
sac2c -noDCR
=> DBUG_ASSERT in alloc.c (rev 15153)
I think saa should be turnd off in that case and a warning issued (as done for
several other cases...)</pre>Florian BütherFlorian Bütherhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1510silly bugger kills IVE w/dosaacyc2017-11-19T20:57:53ZRobert Berneckysilly bugger kills IVE w/dosaacyc| | |
| --- | --- |
| Bugzilla Link | [341](http://bugs.sac-home.org/show_bug.cgi?id=341) |
| Created on | Jan 24, 2007 17:17 |
| Resolution | FIXED |
| Resolved on | Apr 03, 2007 18:51 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [341](http://bugs.sac-home.org/show_bug.cgi?id=341) |
| Created on | Jan 24, 2007 17:17 |
| Resolution | FIXED |
| Resolved on | Apr 03, 2007 18:51 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug341.sac](/uploads/aff1ea5ddd8213c99a989e5925875c79/bug341.sac), [bug341_patch.diff](/uploads/a5c8bcab28da851303b3ce7ecf64b5f7/bug341_patch.diff), [bodoive.sac](/uploads/6947f0ad84d28ac2b058cd638d47d59d/bodoive.sac) |
## Extended Description
<pre>The attached dies in IVESPLITprf when compiled with
sac2c -dosaacyc silly.sac
because the second argument to a sel() has AVIS_SHAPE of 0X0.</pre>Florian BütherFlorian Bütherhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1622out of range array access during WLFS in apex/dtb/dtb.sac2017-11-19T21:09:01ZRobert Berneckyout of range array access during WLFS in apex/dtb/dtb.sac| | |
| --- | --- |
| Bugzilla Link | [342](http://bugs.sac-home.org/show_bug.cgi?id=342) |
| Created on | Jan 31, 2007 20:52 |
| Resolution | DUPLICATE |
| Resolved on | May 07, 2007 21:43 |
| Version | 1.00beta |
| OS | Linux |
| Arc...| | |
| --- | --- |
| Bugzilla Link | [342](http://bugs.sac-home.org/show_bug.cgi?id=342) |
| Created on | Jan 31, 2007 20:52 |
| Resolution | DUPLICATE |
| Resolved on | May 07, 2007 21:43 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/a6aa978f1e3cac2b3a0f9a82bb6b798c/crud.sac), [xcrud.sac](/uploads/e1d3500b187aa93d1f76a370b46fc0ce/xcrud.sac) |
## Extended Description
<pre>sac2c -dosaacyc sac/apex/dtb/dtb.sac
dies w/segfault in the above function, trying to set AVIS_SHAPE( newshp).</pre>Stephan HerhutStephan Herhuthttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1487WL fusion fizzles frequently on AKD2017-11-19T20:55:34ZRobert BerneckyWL fusion fizzles frequently on AKD| | |
| --- | --- |
| Bugzilla Link | [343](http://bugs.sac-home.org/show_bug.cgi?id=343) |
| Created on | Feb 01, 2007 22:46 |
| Resolution | FIXED |
| Resolved on | Apr 29, 2007 23:04 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [343](http://bugs.sac-home.org/show_bug.cgi?id=343) |
| Created on | Feb 01, 2007 22:46 |
| Resolution | FIXED |
| Resolved on | Apr 29, 2007 23:04 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [wlfsbug.sac](/uploads/1eba724a960f1513dd523afed4d1dc82/wlfsbug.sac) |
## Extended Description
<pre>The attached does not WL fuse the WLs for x and y when compiled
with: sac2c -dowlfs wlfsbug.sac
[Oh, you need: -noive or saa bugs will kill sac2c].
--------------------------------------
use Array: all;
use StdIO: all;
int[.] id( int[.] y)
{ return(y);
}
int main()
{
y = iota((id([20]))[0]);
x = y%2;
z = x+y;
print(z);
return(0);
}</pre>Clemens GrelckClemens Grelckhttps://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/1511_accu_ returns 1 instead of two return values2017-11-19T20:57:59ZRobert Bernecky_accu_ returns 1 instead of two return values| | |
| --- | --- |
| Bugzilla Link | [345](http://bugs.sac-home.org/show_bug.cgi?id=345) |
| Created on | Feb 12, 2007 19:58 |
| Resolution | INVALID |
| Resolved on | Jun 12, 2007 08:42 |
| Version | 1.00beta |
| OS | Linux |
| Archi...| | |
| --- | --- |
| Bugzilla Link | [345](http://bugs.sac-home.org/show_bug.cgi?id=345) |
| Created on | Feb 12, 2007 19:58 |
| Resolution | INVALID |
| Resolved on | Jun 12, 2007 08:42 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/2e4e339ed0f17224b65e1f45cda28c7d/crud.sac) |
## Extended Description
<pre>The attached, when compiled in build#15222 with these options, dies with Summary
error in ArrayTransform:
sac2c -dowlfs -dosaacyc crud.sac
Removing EITHER of the above compiler options allows the code to compile OK.</pre>Florian BütherFlorian Büther