sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T22:02:46Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2152Make does not terminate upon error2017-11-19T22:02:46ZPhilip HolzenspiesMake does not terminate upon error| | |
| --- | --- |
| Bugzilla Link | [412](http://bugs.sac-home.org/show_bug.cgi?id=412) |
| Created on | Apr 07, 2008 15:56 |
| Resolution | FIXED |
| Resolved on | Jul 28, 2011 16:48 |
| Version | svn |
| OS | MacOS X |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [412](http://bugs.sac-home.org/show_bug.cgi?id=412) |
| Created on | Apr 07, 2008 15:56 |
| Resolution | FIXED |
| Resolved on | Jul 28, 2011 16:48 |
| Version | svn |
| OS | MacOS X |
| Architecture | Macintosh |
## Extended Description
Unsure of the version: the version used was the "beta 1.0" tarball downloaded from the webpage on April 7th. When the SACBASE and SAC2CBASE variables are properly set, but the PATH variable is not updated to include $SAC2CBASE/bin running make does produce errors about sac2c not being found, but it does not terminate. This would be the default behaviour (if not the availability of sac2c should already be checked in the configure stage).Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2151ArrayFormat cannot be compiled2017-11-19T22:02:41ZStephan HerhutArrayFormat cannot be compiled| | |
| --- | --- |
| Bugzilla Link | [392](http://bugs.sac-home.org/show_bug.cgi?id=392) |
| Created on | Aug 06, 2007 14:04 |
| Resolution | FIXED |
| Resolved on | Aug 13, 2007 17:58 |
| Version | svn |
| OS | SunOS |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [392](http://bugs.sac-home.org/show_bug.cgi?id=392) |
| Created on | Aug 06, 2007 14:04 |
| Resolution | FIXED |
| Resolved on | Aug 13, 2007 17:58 |
| Version | svn |
| OS | SunOS |
| Architecture | PC |
| Attachments | [tutu.sac](/uploads/6de73d6d5f57256e0d149405ab07b4fb/tutu.sac) |
## Extended Description
ArrayFormat cannot be compiled with sac2c rev 15540 and stdlib rev 1026.Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2150unibench loses benchmarks, but they're still there2017-11-19T22:02:34ZRobert Berneckyunibench loses benchmarks, but they're still there| | |
| --- | --- |
| Bugzilla Link | [352](http://bugs.sac-home.org/show_bug.cgi?id=352) |
| Created on | Mar 16, 2007 19:11 |
| Resolution | INVALID |
| Resolved on | Nov 26, 2008 15:58 |
| Version | unspecified |
| OS | Linux |
| Ar...| | |
| --- | --- |
| Bugzilla Link | [352](http://bugs.sac-home.org/show_bug.cgi?id=352) |
| Created on | Mar 16, 2007 19:11 |
| Resolution | INVALID |
| Resolved on | Nov 26, 2008 15:58 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
Unibench "benchmarks" page fails to see "implementation" of benchmarks if they
are not on page 1 of benchmarks. However, if you "Add an implementation" of said
benchmark, it says that it has replaced the earlier version.
We also need an additional Component for saczilla to indicate "unibench".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/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/2147kp1 yields a runtime error in recent versions of the stdlib2017-11-19T22:02:18ZStephan Herhutkp1 yields a runtime error in recent versions of the stdlib| | |
| --- | --- |
| Bugzilla Link | [322](http://bugs.sac-home.org/show_bug.cgi?id=322) |
| Created on | Nov 14, 2006 16:47 |
| Resolution | WORKSFORME |
| Resolved on | Nov 15, 2006 10:47 |
| Version | svn |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [322](http://bugs.sac-home.org/show_bug.cgi?id=322) |
| Created on | Nov 14, 2006 16:47 |
| Resolution | WORKSFORME |
| Resolved on | Nov 15, 2006 10:47 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>When compiling kp1 from demos/numerical with sac2c rev 15081, one gets
*** SAC runtime error
*** line 94
*** one generator body expression and another generator body expression
*** should have identical shapes; types found: double[0] and
*** double[400]
*** line 94
*** one generator body expression and another generator body expression
*** should have identical shapes; types found: double[0] and
*** double[400]
*** line 345
*** -- in _MAIN::_dup_1249_main__Loop_0( int[1]{0}, int{2}, int{0},
*** int{3}, double{0.0...}, double[500,400], double[500,3],
*** double[500,3], double[500,3], double[500,3], double[500,3], int,
*** int{1})
It worked fine with revision 15072.</pre>Florian BütherFlorian Bütherhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2146graphics demos don't work2017-11-19T22:02:12ZRobert Berneckygraphics demos don't work| | |
| --- | --- |
| Bugzilla Link | [297](http://bugs.sac-home.org/show_bug.cgi?id=297) |
| Created on | Oct 04, 2006 19:11 |
| Resolution | FIXED |
| Resolved on | Oct 24, 2006 11:33 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [297](http://bugs.sac-home.org/show_bug.cgi?id=297) |
| Created on | Oct 04, 2006 19:11 |
| Resolution | FIXED |
| Resolved on | Oct 24, 2006 11:33 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Failure 1:
** 1: Setting up sac2c compiler environment ...
**** Analyzing command line options ...
**** Processing sac2c configuration file ...
Parsing configuration file "/home/sac/sac/BASE/runtime/sac2crc" ...
**** Initializing data structures ...
** 2: Loading SAC program: ...
**** Parsing input file ...
Parsing file "./imtest.sac" ...
**** Resolving axis control and dot notation ...
**** Resolving pragma annotations ...
**** Generating generic types and functions ...
** 3: Running module system: ...
**** Processing use and import statements ...
**** Annotating namespaces ...
ERROR: Symbol `color' used more than once
ERROR: ... from module `Structures'
ERROR: ... from module `Color8'
*** Compilation failed ***
*** Exit code 3 (Running module system)
*** 1 Error(s), 0 Warning(s)
ac2c -V
sac2c v1.00-beta (Codename Wooden Shoes) rev 15020 linux-gnu_x86_64 (Wed Oct 4
11:46:08 EDT 2006 sac)
Failure 2:
the Mandelbrot code compile w/-noPHM, but crash at execution, due to
memory corruption.</pre>Stephan HerhutStephan Herhuthttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2145Funny business with new print()2017-11-19T22:02:07ZRobert BerneckyFunny business with new print()| | |
| --- | --- |
| Bugzilla Link | [220](http://bugs.sac-home.org/show_bug.cgi?id=220) |
| Created on | May 17, 2006 19:08 |
| Resolution | INVALID |
| Resolved on | May 19, 2006 17:53 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [220](http://bugs.sac-home.org/show_bug.cgi?id=220) |
| Created on | May 17, 2006 19:08 |
| Resolution | INVALID |
| Resolved on | May 19, 2006 17:53 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTQuadFI.sac](/uploads/ab33851e5d7f8818990a60d990815b0b/UTQuadFI.sac) |
## Extended Description
<pre>print(character vector) displays ONCE only, a shape
of <a 2 3>. Probably trivial. No big deal.</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/2143Simplicity vs confusion2017-11-19T22:01:55ZRobert BerneckySimplicity vs confusion| | |
| --- | --- |
| Bugzilla Link | [130](http://bugs.sac-home.org/show_bug.cgi?id=130) |
| Created on | Oct 09, 2005 16:27 |
| Resolution | WONTFIX |
| Resolved on | Oct 10, 2005 18:00 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [130](http://bugs.sac-home.org/show_bug.cgi?id=130) |
| Created on | Oct 09, 2005 16:27 |
| Resolution | WONTFIX |
| Resolved on | Oct 10, 2005 18:00 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud](/uploads/85403422f1e71ac333db432e7e918b8d/crud), [sel.sac](/uploads/80399ecf416264660363dd611c12bbf1/sel.sac), [foo](/uploads/04e900520ad6abcd7833c8bb50ae418c/foo) |
## Extended Description
<pre>I'm either bit confused here or there's something funny with imports (USEs)
in the stdlib modules.
If I do, for example, "use Array.sac:all;", then "use String.sac:all;",
sac2c complains about duplicate definitions for various
primitives. I can get around this specific failure by careful
inclusion/exclusion, but suspect there is a general problem
here where I could get into a situation where the conflict can not
be resolved at the source program level, and I'd have to make
custom copies of stdlib modules to circumvent the problem.
Here are two proposals for solutions to this problem:
1. Allow multiple USEs of the same module, and throw away
the duplicates fairly early in the compilation process.
2. Remove ALL "use *.sac" statements from modules. Perhaps leave
them as comments, so the user of a module can add them, if needed.</pre>Stephan HerhutStephan Herhuthttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2142missing rules in sac2c/Makefile2017-11-19T22:01:47ZRobert Berneckymissing rules in sac2c/Makefile| | |
| --- | --- |
| Bugzilla Link | [108](http://bugs.sac-home.org/show_bug.cgi?id=108) |
| Created on | Aug 02, 2005 23:19 |
| Resolution | INVALID |
| Resolved on | Oct 27, 2005 16:20 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [108](http://bugs.sac-home.org/show_bug.cgi?id=108) |
| Created on | Aug 02, 2005 23:19 |
| Resolution | INVALID |
| Resolved on | Oct 27, 2005 16:20 |
| Version | svn |
| OS | Linux |
| Architecture | PC |Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2141TC ignores type error in dead code2017-11-19T22:01:42ZClemens GrelckTC ignores type error in dead code| | |
| --- | --- |
| Bugzilla Link | [796](http://bugs.sac-home.org/show_bug.cgi?id=796) |
| Created on | Dec 08, 2010 15:35 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>In the code from the ...| | |
| --- | --- |
| Bugzilla Link | [796](http://bugs.sac-home.org/show_bug.cgi?id=796) |
| Created on | Dec 08, 2010 15:35 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>In the code from the latest SAC user:
import Array: all;
import StdIO: all;
typedef int[1] array;
int main()
{
array x;
x = 10;
#ifndef EXCLUDE_ERRORS
print(x);
#endif
return(0);
}
the obvious type error goes away if x becomes dead code.
I traced this in so far as until the tc there is a proper
type conversion, which in my view should lead to an error
message, but after type checking this is gone.
This is very counter-intuitive for the user and an error
for me.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2140LIR apparently failing to operate on APEX Floyd benchmark2017-11-19T22:01:39ZRobert BerneckyLIR apparently failing to operate on APEX Floyd benchmark| | |
| --- | --- |
| Bugzilla Link | [1008](http://bugs.sac-home.org/show_bug.cgi?id=1008) |
| Created on | Jul 20, 2012 16:40 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/94b1bf45c55c07...| | |
| --- | --- |
| Bugzilla Link | [1008](http://bugs.sac-home.org/show_bug.cgi?id=1008) |
| Created on | Jul 20, 2012 16:40 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/94b1bf45c55c0700abb1c245c3e8491b/crud.sac), [floyd.sac](/uploads/b7503563d5a065a86cc8f079aa47aac1/floyd.sac), [floyd2.sac](/uploads/731f3a5ebc00728d28503a95aaeca227/floyd2.sac) |
## Extended Description
<pre>Created an attachment (id=920)
source code to reproduce fault
The APL version of a Floyd's shortest path benchmark
runs VERY slowly. When I looked at the IL, I saw that we generate
WLs within the LACFUNs. The offending APL code looks like this:
[4] siz←⍴D
[5] :For k :In ⍳siz[0]
[6] :For i :In ⍳siz[0]
[7] :For j :In ⍳siz[1]
[8] D[i;j]←(D[i;k]+D[k;j])⌊D[i;j]
[9] :EndFor
[10] :EndFor
[11]:EndFor
The IL generates ⍳siz[0] WITHIN the LOOPFUNs, and although at
least one of them has been touched by LIR,they have not been lifted
entirely out of the LOOPFUNs. The result is extremely slow code.
When I rewrote the Floyd code, it ran quick like a bunny:
inline double[.,.] floydXDD(double[.,.] D ,int QUADio)
{
siz = shape(D)[0];
for( k=0; k<siz; k++) {
for( i=0; i<siz; i++) {
for( j=0; j<siz; j++) {
D[i,j] = min(D[i,k]+D[k,j], D[i,j]);
}
}
}
return( D);
}
However, the underlying problem in LIR is needs fixing here.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18091:MODIFIED linux-gnu_x86_64
(Thu Jul 19 18:26:07 EDT 2012 by sac)
I'm assigning this to Jara, on the assumption that it's still his
kettle of fish.
BTW, perhaps it's time to svn rm SSALIR.c, now that its functionality
lies elsewhere?</pre>Jaroslav SýkoraJaroslav Sýkorahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2139APEX benchmark shortened snp.sac gets stuck in WLUR during opt cycle 22017-11-19T22:01:34ZRobert BerneckyAPEX benchmark shortened snp.sac gets stuck in WLUR during opt cycle 2| | |
| --- | --- |
| Bugzilla Link | [1050](http://bugs.sac-home.org/show_bug.cgi?id=1050) |
| Created on | Mar 06, 2013 16:17 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/8f0267bd90f82b...| | |
| --- | --- |
| Bugzilla Link | [1050](http://bugs.sac-home.org/show_bug.cgi?id=1050) |
| Created on | Mar 06, 2013 16:17 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/8f0267bd90f82bb97a3b5c43dfccef3f/crud.sac) |
## Extended Description
<pre>Created an attachment (id=951)
source code to reproduce fault
Summary says it all:
**** Optimization cycle pass: 2
****** Optimizing regular function:
****** _MAIN::main( hidden(1), hidden(2), hidden(0)): ...
...
WLUR: -maxwlur 3 would unroll genarray with-loop
WLUR: -maxwlur 3 would unroll genarray with-loop
^CAborted
apex@rattler:~/apex3/benchmks/snp$ vi crud.sac
apex@rattler:~/apex3/benchmks/snp$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18061 linux-gnu_x86_64
(Fri Mar 1 17:24:54 EST 2013 by sac)
apex@rattler:~/apex3/benchmks/snp$ sac2c crud.sac -doawlf -nowlf -v1 -O3 -v4 -maxwlur 1</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2138three dots as arguments unsafer than expected2021-08-30T15:56:59ZSven-Bodo Scholzthree dots as arguments unsafer than expected| | |
| --- | --- |
| Bugzilla Link | [521](http://bugs.sac-home.org/show_bug.cgi?id=521) |
| Created on | Jul 07, 2009 14:45 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu.sac](/uploads/6e449df16f5...| | |
| --- | --- |
| Bugzilla Link | [521](http://bugs.sac-home.org/show_bug.cgi?id=521) |
| Created on | Jul 07, 2009 14:45 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tutu.sac](/uploads/6e449df16f5940c2e6e5d42fd468ef60/tutu.sac) |
## Extended Description
<pre>Created an attachment (id=549)
source code
compile with -maxspec 0 and the 5.0 will be printed as 0.0000.
The reason for this is that the scalar value comes as AUD and therefore
in boxed form. As it is in ... position of printf, precompile cannot
insert appropriate casts to make sure an unboxed double is passed to the
actual printf implementation.
inlining or specialisations obviously make this problem go away....</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2137AKD compiler error2021-05-26T20:22:49ZSven-Bodo ScholzAKD compiler error| | |
| --- | --- |
| Bugzilla Link | [33](http://bugs.sac-home.org/show_bug.cgi?id=33) |
| Created on | Dec 11, 2003 13:21 |
| Resolution | FIXED |
| Resolved on | Dec 11, 2003 20:10 |
| Version | 1.00beta |
| OS | SunOS |
| Architect...| | |
| --- | --- |
| Bugzilla Link | [33](http://bugs.sac-home.org/show_bug.cgi?id=33) |
| Created on | Dec 11, 2003 13:21 |
| Resolution | FIXED |
| Resolved on | Dec 11, 2003 20:10 |
| Version | 1.00beta |
| OS | SunOS |
| Architecture | Sun |
| Attachments | [error5.sac](/uploads/6b4f93089297acfb016b12378b6e97dc/error5.sac) |
## Extended Description
<pre>there seems to be a serious AKD bug.
Compiling the attached program with
sac2c -O3 -sbs -fun2lac 7 -ssa -noTSI -noAP -maxlur 3 -maxwlur 12 -check tb -o
error5 error5.sac
yields:
** 21: Invoking C compiler: ...
error5.c: In function `SACf_main':
error5.c:323: warning: implicit declaration of function `SAC_ND_A_MIRROR'
error5.c:323: `AKD' undeclared (first use in this function)
error5.c:323: (Each undeclared identifier is reported only once
error5.c:323: for each function it appears in.)
error5.c:323: `NHD' undeclared (first use in this function)
error5.c:323: `NUQ' undeclared (first use in this function)
error5.c:323: parse error before `)'
SYSTEM::ERROR: System failed to execute shell command
:ERROR: gcc -Wall -Wno-unused -fno-builtin -DTAGGED_ARRAYS
:ERROR: -I$SACBASE/runtime/ -L$SACBASE/runtime/
:ERROR: -L/tmp/SAC_AAAd9aGnU -O3 -o error5 error5.c -lsac_heapmgr
:ERROR: -lsac
:ERROR: with exit code 1 !</pre>Dietmar KreyeDietmar Kreyehttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2136wrong code generation for reshape2021-05-26T20:22:34ZDietmar Kreyewrong code generation for reshape| | |
| --- | --- |
| Bugzilla Link | [20](http://bugs.sac-home.org/show_bug.cgi?id=20) |
| Created on | Jun 19, 2003 14:28 |
| Resolution | FIXED |
| Resolved on | Dec 01, 2003 19:09 |
| Version | 1.00beta |
| OS | All |
| Architectur...| | |
| --- | --- |
| Bugzilla Link | [20](http://bugs.sac-home.org/show_bug.cgi?id=20) |
| Created on | Jun 19, 2003 14:28 |
| Resolution | FIXED |
| Resolved on | Dec 01, 2003 19:09 |
| Version | 1.00beta |
| OS | All |
| Architecture | All |
| Attachments | [bug.sac](/uploads/5272df65148e2fd951225c55a8e77f63/bug.sac) |
## Extended Description
<pre>The compiler backend generates wrong code the primitive operation reshape().
Example:
B = reshape( sv, A)
If the rc of A is 1 (A is the last reference of the array) B can reuse the data
vector of A. For the time being the following code is generated:
CHECK_REUSE( B, A)
ALLOC_BEGIN( B, ...)
PRF_RESHAPE__SHAPE( B, ...)
ALLOC_END( B, ...)
INC_RC( B)
IS_NOT_REUSED( B, A)
COPY_DATA( B, A)
The problem is about the CHECK_REUSE icm which is defined as follows:
if (RC(B) == 1)
ASSIGN( B, A)
else
/* allocation of B */
Unfortunately, ASSIGN is not correct here since A and B may have incompatible
descriptors! Instead, the following code should be generated:
if (RC(B) == 1)
ASSIGN_DESC( B, A)
ASSIGN_DATA( B, A)
PRF_RESHAPE__DIM( B, ...)
PRF_RESHAPE__SHAPE( B, ...)
else
ALLOC_BEGIN( B, ...)
PRF_RESHAPE__SHAPE( B, ...)
ALLOC_END( B, ...)
INC_RC( B)
IS_NOT_REUSED( B, A)
COPY_DATA( B, A)
or:
if (RC(B) == 1)
ASSIGN_DESC( B, A)
else
ALLOC_BEGIN( B, ...)
PRF_RESHAPE__SHAPE( B, ...)
ALLOC_END( B, ...)
INC_RC( B)
IS_REUSED( B, A)
PRF_RESHAPE__DIM( B, ...)
PRF_RESHAPE__SHAPE( B, ...)
ASSIGN_DATA( B, A)
ELSE
COPY_DATA( B, A)
A SAC program for reproducing the bug will be given as attachment.</pre>Dietmar KreyeDietmar Kreyehttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2135vanishing with-loop2021-05-26T20:16:30ZKai Trojahnervanishing with-loop| | |
| --- | --- |
| Bugzilla Link | [2](http://bugs.sac-home.org/show_bug.cgi?id=2) |
| Created on | Mar 05, 2003 09:53 |
| Resolution | FIXED |
| Resolved on | Mar 05, 2003 18:51 |
| Version | 1.00beta |
| OS | Linux |
| Architectur...| | |
| --- | --- |
| Bugzilla Link | [2](http://bugs.sac-home.org/show_bug.cgi?id=2) |
| Created on | Mar 05, 2003 09:53 |
| Resolution | FIXED |
| Resolved on | Mar 05, 2003 18:51 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Hallo allerseits,
bei einem erneuten Versuch, die FFT mithilfe der WLS eleganter zu
implementieren, bemerkte ich, dass das anghängte (stark verkürzte)
Beispielprogramm fft_cpx.sac mit der Einstellung -wls_aggressive falsche
Ergebnisse liefert. Da ich offen gestanden nicht weiß, wo der Fehler liegen
könnte, bitte ich um eure Hilfe.
Eine genauere Untersuchung ergab, dass das Fehlverhalten in der Funktion
FFT1d_Slice zu finden ist.
Nach der Compilerphase -b14 sieht alles so aus, wie ich es von der aggressiven
WLS erwarten würde:
_MAIN:cpx[16,16,16] _MAIN:FFT1d_Slice( _MAIN:cpx[16,16,16] a)
/*
* FFT1d_Slice :: */
{
double _wls_78;
int _wls_77;
int _wls_76;
int _wls_75_16_2__;
_MAIN:cpx[16,16,16] result;
_MAIN:cpx[16] slice;
_MAIN:cpx[16] _flat_24;
int _type_45;
int _type_44;
int[2] _flat_23_iv:VECT:$;
int[4] _wls_79:VECT:$;
result = with ([ 0, 0, 0, 0 ] <= _wls_79=[_type_44, _type_45, _wls_77, _wls_76]
< [ 16, 16, 16, 2 ])
{
_flat_23_iv:VECT:$ = [ _type_44, _type_45 ];
_wls_75_16_2__:IDX(_MAIN:cpx[16]):$ = ((_wls_77 * 2) + _wls_76);
_flat_24 = _MAIN:sel( _flat_23_iv, a);
slice = _MAIN:add( _flat_24);
_wls_78 = idx_sel( _wls_75_16_2__, slice);
}
modarray( a, dummy, _wls_78);
return( result);
}
Breche ich den Vorgang jedoch nach Phase 15 ab, ist von der gesamten With-Loop
nichts mehr zu sehen und das eingegebene Array wird unverändert zurückgegeben:
_MAIN:cpx[16,16,16] _MAIN:FFT1d_Slice( _MAIN:cpx[16,16,16] a)
/*
* FFT1d_Slice :: */
{
double _wls_78;
int _wls_77;
int _wls_76;
int _wls_75_16_2__;
_MAIN:cpx[16,16,16] result;
_MAIN:cpx[16] slice;
_MAIN:cpx[16] _flat_24;
int _type_45;
int _type_44;
int[2] _flat_23_iv;
int[4] _wls_79;
result = a;
return( result);
}
Interessant ist auch, dass ein ähnliches Programm mit Doubles statt Complex
perfekt übersetzt wird (nobug.sac).
Könnt ihr mir weiterhelfen?
Kai
--- nobug.sac ---
import Array:all;
import StdIO:all;
double[+] test(double[+] a)
{
return(a+1d);
}
double[+] hallo(double[+] A)
{
res = with([0,0] <= iv < [shape(A)[[0]],shape(A)[[1]]]) {
vi = test(A[iv]);
}
modarray(A,iv,vi);
return(res);
}
int main()
{
U = genarray([16,16,16,2],0d);
V = hallo(U);
/* print 1 if U==V */
print(with (0*shape(U) <= iv < shape(U)) fold(&&,true,V[iv]==U[iv]));
return (0);
}
--- fft_cpx.sac ---
import Array: all;
import StdIO: all;
import Math: all;
import ArrayIO: all;
typedef double[2] cpx;
/**** complex *****/
inline
double[2] cpx2dbl(cpx c)
{
return((:double[2]) c);
}
inline
double[+] cpx2dbl(cpx[+] c)
{
return((:double[+]) c);
}
inline
cpx dbl2cpx(double[2] d)
{
return((:cpx) d);
}
inline
cpx[+] dbl2cpx(double[+] d)
{
return((:cpx[+]) d);
}
inline cpx + (cpx a, cpx b)
{
res = with(. <= iv <= .)
genarray([2], a[iv] + b[iv]);
return(res);
}
inline cpx[+] + (cpx[+] X1, cpx X2)
{
res = with (. <= iv <= .)
genarray( drop([-1],shape(X1)), ((:cpx)((:double[+])X1)[iv]) + X2);
return(res);
}
cpx[+] sel(int[+] iv, cpx[+] a)
{
ad = cpx2dbl(a);
rd = ad[iv];
return( dbl2cpx(rd));
}
/*** FFT core ***/
cpx[+] add(cpx[+] v)
{
return( v+((:cpx)[1d,0d]));
}
/* slices array in direction (k), calculates fft(), */
/* reassebles slices to array */
cpx[+] FFT1d_Slice(cpx[+] a)
{
result = with( [0,0] <= iv < [shape(a)[[0]],shape(a)[[1]]] )
{
slice = add(a[iv]);
}
modarray( a, iv, slice);
return( result);
}
/*** MAIN ***/
int main()
{
U = dbl2cpx(genarray([16,16,16,2],0d));
V = FFT1d_Slice(U);
/* print 1 if U==V */
print(with (0*shape(U) <= iv < shape(U))
fold(&&,true,((:double[+])V)[iv]==((:double[+])U)[iv]));
return(0);
}</pre>Dietmar KreyeDietmar Kreyehttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2134swlf cost function crashes sac2c2021-05-27T12:54:12ZRobert Berneckyswlf cost function crashes sac2c| | |
| --- | --- |
| Bugzilla Link | [363](http://bugs.sac-home.org/show_bug.cgi?id=363) |
| Created on | May 14, 2007 18:55 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [buildv.sac](/uploads/ac0139a2d...| | |
| --- | --- |
| Bugzilla Link | [363](http://bugs.sac-home.org/show_bug.cgi?id=363) |
| Created on | May 14, 2007 18:55 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [buildv.sac](/uploads/ac0139a2ddc56e9c9028366ecb0348b7/buildv.sac) |
## Extended Description
<pre>Attached dies if you compile with -doswlf.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2133Parser does not propely recognise dots in generators2017-11-19T22:01:11ZClemens GrelckParser does not propely recognise dots in generators| | |
| --- | --- |
| Bugzilla Link | [748](http://bugs.sac-home.org/show_bug.cgi?id=748) |
| Created on | Sep 19, 2010 18:42 |
| Resolution | FIXED |
| Resolved on | Sep 27, 2010 04:42 |
| Version | svn |
| OS | All |
| Architecture |...| | |
| --- | --- |
| Bugzilla Link | [748](http://bugs.sac-home.org/show_bug.cgi?id=748) |
| Created on | Sep 19, 2010 18:42 |
| Resolution | FIXED |
| Resolved on | Sep 27, 2010 04:42 |
| Version | svn |
| OS | All |
| Architecture | All |
## Extended Description
<pre>The following code is not accepted:
int main( )
{
x = with {
(.<= iv <=.): 1;
}: genarray( [100]);
return( 0);
}
while this is:
int main( )
{
x = with {
(. <= iv <= .): 1;
}: genarray( [100]);
return( 0);
}
The spaces should under no circumstances affect the correctness of the code.
It is unclear what caused the bug as the upper code used to work, but it
may have to do with the use of the dot in the record extension. This needs
further investigation.</pre>Santanu Kumar DashSantanu Kumar Dash