sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:29:09Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1189release version of master branch does not build under ubuntu 16.04LTS2017-11-19T20:29:09ZRobert Berneckyrelease version of master branch does not build under ubuntu 16.04LTS| | |
| --- | --- |
| Bugzilla Link | [1194](http://bugs.sac-home.org/show_bug.cgi?id=1194) |
| Created on | Jun 02, 2017 16:59 |
| Resolution | DUPLICATE |
| Resolved on | Jul 18, 2017 22:16 |
| Version | svn |
| OS | Linux |
| Archit...| | |
| --- | --- |
| Bugzilla Link | [1194](http://bugs.sac-home.org/show_bug.cgi?id=1194) |
| Created on | Jun 02, 2017 16:59 |
| Resolution | DUPLICATE |
| Resolved on | Jul 18, 2017 22:16 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Can't build the release version with current master. debug version
builds okay:
[ 4%] Building C object src/libsac-seq/CMakeFiles/libsac-seq.dir/cachesim/access_detailed.c.o
Internal compiler error
Assertion "sacargudt != UT_NOT_DEFINED" failed at /home/sac/sac2c/src/libsac2c/generics/generate_generic_type_conversions.c:370 -- Cannot find sacarg udt!
Please file a bug at: http://bugs.sac-home.org
src/libsacprelude-seq/CMakeFiles/libsacprelude-seq.dir/build.make:62: recipe for target 'lib/prelude/host/seq/libsacprelude_pMod.so' failed
make[5]: *** [lib/prelude/host/seq/libsacprelude_pMod.so] Error 1
CMakeFiles/Makefile2:438: recipe for target 'src/libsacprelude-seq/CMakeFiles/libsacprelude-seq.dir/all' failed
make[4]: *** [src/libsacprelude-seq/CMakeFiles/libsacprelude-seq.dir/all] Error 2
make[4]: *** Waiting for unfinished jobs....
sac2c 1.2-beta-BlackForest-519-gae719
build-type: DEBUG</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1190version manager does not work in Linux2017-11-19T20:29:16ZRobert Berneckyversion manager does not work in Linux| | |
| --- | --- |
| Bugzilla Link | [1197](http://bugs.sac-home.org/show_bug.cgi?id=1197) |
| Created on | Jun 29, 2017 15:15 |
| Resolution | FIXED |
| Resolved on | Jul 17, 2017 21:29 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [1197](http://bugs.sac-home.org/show_bug.cgi?id=1197) |
| Created on | Jun 29, 2017 15:15 |
| Resolution | FIXED |
| Resolved on | Jul 17, 2017 21:29 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [0001-Find-python-2.x.x-and-use-it-in-the-version-manager.patch](/uploads/9f4e1b1c1c25320cc41d93b704f405d7/0001-Find-python-2.x.x-and-use-it-in-the-version-manager.patch) |
## Extended Description
<pre>The version manager script does not work under linux, because
it does not find the proper version of python2:
~/sac2c/build_d$ scripts/sac2c-version-manager
-bash: scripts/sac2c-version-manager: /bin/env: bad interpreter: No such file or directory
sac@rattler:~/sac2c/build_d$ which env
/usr/bin/env
sac@rattler:~/sac2c/build_d$ sac2c -V
sac2c 1.2-beta-BlackForest-541-g154ab
build-type: DEBUG
built-by: "sac" at 2017-06-28T17:35:14
Patching the script works, but only until the next build, at which
point you have to patch it again.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1304DFR appears not to be working2017-11-19T20:37:11ZRobert BerneckyDFR appears not to be working| | |
| --- | --- |
| Bugzilla Link | [983](http://bugs.sac-home.org/show_bug.cgi?id=983) |
| Created on | Jun 19, 2012 19:08 |
| Resolution | FIXED |
| Resolved on | Sep 29, 2017 15:02 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [983](http://bugs.sac-home.org/show_bug.cgi?id=983) |
| Created on | Jun 19, 2012 19:08 |
| Resolution | FIXED |
| Resolved on | Sep 29, 2017 15:02 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>One of the CF unit tests now crashes in the -NOCF mode:
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17951:MODIFIED linux-gnu_x86_64
(Tue Jun 19 13:34:21 EDT 2012 by sac)
cd ~/sac/testsuite/optimizations/constantfolding
sac2c SCSprf_toi.sac -v0 -maxwlur 1 -doawlf -v4 -noewlcf -nocf
gets a segfault from running out of memory. What seems to be happening
is that the code volume grows on each iteration (also slowing things down
a whole lot), and we end up with many copies of dead Loop() functions.
The code is fairly simple: cat SCSprf_toi.sac
/* Unit test for SCSprf_toi() */
/* RESULT: _toi_S_ 1 0 -maxwlur 1 */
/* FILTER: no-no */
int main ()
{
x = 0;
for (ib=0; _le_SxS_( ib, 3); ib = _add_SxS_( ib, 1)){
x = with { ([0] <= [ix] <= [8])
/* CF should make this toi go away */
: _toi_S_( _mul_SxS_( 2, _div_SxS_( ix, 2))); }
: genarray([9], 0);
}
z = _sel_VxA_([7], x);
z = _sub_SxS_(z, 6);
return(z);
}</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1317DBUG_ASSERT works too well2017-11-19T20:38:12ZRobert BerneckyDBUG_ASSERT works too well| | |
| --- | --- |
| Bugzilla Link | [233](http://bugs.sac-home.org/show_bug.cgi?id=233) |
| Created on | Jul 06, 2006 16:17 |
| Resolution | INVALID |
| Resolved on | Aug 07, 2006 17:52 |
| Version | 1.00beta |
| OS | Linux |
| Archi...| | |
| --- | --- |
| Bugzilla Link | [233](http://bugs.sac-home.org/show_bug.cgi?id=233) |
| Created on | Jul 06, 2006 16:17 |
| Resolution | INVALID |
| Resolved on | Aug 07, 2006 17:52 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTIndexRef.sac](/uploads/d9b59858913a66fae0bcdd4f5dc8961d/UTIndexRef.sac) |
## Extended Description
<pre>If I compile the attached with
-O3 -#d,XXX UTIndexRef.sac
an assertion kills sac2c in Phase 9.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1318modarray within loop goes wrong2017-11-19T20:38:18ZSven-Bodo Scholzmodarray within loop goes wrong| | |
| --- | --- |
| Bugzilla Link | [454](http://bugs.sac-home.org/show_bug.cgi?id=454) |
| Created on | Aug 27, 2008 18:11 |
| Resolution | DUPLICATE |
| Resolved on | Mar 18, 2009 20:29 |
| Version | 1.00beta |
| OS | Linux |
| Arc...| | |
| --- | --- |
| Bugzilla Link | [454](http://bugs.sac-home.org/show_bug.cgi?id=454) |
| Created on | Aug 27, 2008 18:11 |
| Resolution | DUPLICATE |
| Resolved on | Mar 18, 2009 20:29 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [roots.sac](/uploads/41ea3b3753e7ed09264ea97e4d3ce9c9/roots.sac) |
## Extended Description
<pre>Created an attachment (id=493)
source code
compiling the attached code using
sac2c v1.00-beta (Buchette d'Anjou)
product rev 15775 linux-gnu_i686
(Fri Aug 22 14:36:34 BST 2008 by sbs)
yields an executable which delivers:
-sbs-obelix-> ./a.out
Dimension: 2
Shape : < 32, 1>
| 0 |
|31 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |
| 0 |</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1319misspelled module name crashes sac2c2017-11-19T20:38:24ZBep Rintomisspelled module name crashes sac2c| | |
| --- | --- |
| Bugzilla Link | [916](http://bugs.sac-home.org/show_bug.cgi?id=916) |
| Created on | Feb 22, 2012 10:52 |
| Resolution | FIXED |
| Resolved on | Jun 06, 2012 20:33 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [916](http://bugs.sac-home.org/show_bug.cgi?id=916) |
| Created on | Feb 22, 2012 10:52 |
| Resolution | FIXED |
| Resolved on | Jun 06, 2012 20:33 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>/**********************************************************************
*
* SAC bug report: t.sacbugreport
*
**********************************************************************
*
* Automatically generated on Wed Feb 22 10:30:33 CET 2012
*
* using sac2c v1.00-beta (Haggis And Apple) rev 17729 for linux-gnu_x86_64
* built Mon Feb 13 10:00:22 GMT 2012.
* by user fpz on host dogmatix for linux-gnu.
*
* The compiler was called by
* sac2c -M -check tb -v 1 -g t.sac
*
* The compiler crashed in
* phase: mod (Running module system)
* sub phase: pdp (Printing dependencies)
*
* What follows is the contents of t.sac.
*
**********************************************************************/
use Stdio: { printf };
int main()
{
printf("Hello!\n");
return 0;
}
/**********************************************************************
*
* End of bug report
*
**********************************************************************/</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1320wlsd does not support [i] notation in with loops2017-11-19T20:38:30ZCarl Joslinwlsd does not support [i] notation in with loops| | |
| --- | --- |
| Bugzilla Link | [509](http://bugs.sac-home.org/show_bug.cgi?id=509) |
| Created on | Jun 09, 2009 23:59 |
| Resolution | FIXED |
| Resolved on | Jun 10, 2009 16:32 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [509](http://bugs.sac-home.org/show_bug.cgi?id=509) |
| Created on | Jun 09, 2009 23:59 |
| Resolution | FIXED |
| Resolved on | Jun 10, 2009 16:32 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [t.sac](/uploads/df74ee9978a1d602aa15259bd032efa7/t.sac) |
## Extended Description
<pre>with {
([0] <= [i] <= [5]) : i;
} : genarrary([10], 1);</pre>Carl JoslinCarl Joslinhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1321NEUTRAL != INITIAL2017-11-19T20:38:37ZCarl JoslinNEUTRAL != INITIAL| | |
| --- | --- |
| Bugzilla Link | [714](http://bugs.sac-home.org/show_bug.cgi?id=714) |
| Created on | May 27, 2010 17:48 |
| Resolution | FIXED |
| Resolved on | Jun 11, 2010 08:23 |
| Version | svn |
| OS | All |
| Architecture |...| | |
| --- | --- |
| Bugzilla Link | [714](http://bugs.sac-home.org/show_bug.cgi?id=714) |
| Created on | May 27, 2010 17:48 |
| Resolution | FIXED |
| Resolved on | Jun 11, 2010 08:23 |
| Version | svn |
| OS | All |
| Architecture | All |
| Attachments | [fold.11.sac](/uploads/772fe1abafe762ad37217d0d51ba73bd/fold.11.sac), [fold.sac](/uploads/a7353aaf52f274bd701af9c17a609ed2/fold.sac) |
## Extended Description
<pre>Created an attachment (id=719)
Code that causes bug
Jing has located a bug that I am very concerned about as it seems so fundamental.
The problem is with:
b = with{
([0,0] <= iv < [100,50]) :a[iv]+tof(iv[0]+iv[1]);
([0,50] <= iv < [100,100]):a[iv] *tof(iv[0]-iv[1]);
}:fold( +, 0f);
With the sequential backend we get a result of:
250099
I have no reason to think this is wrong.
Now how about mt with one thread:
250099
still fine.
Now mt with two threads:
625198
that does not seem correct and if I run it again I get:
625198
so seems consistent
So lets look at more threads
3 1.0003e+06
4 1.3754e+06
5 1.7505e+06
Now it seems to have a pattern add a thread and increase the result by 375099.
If we look at -b11 we can see the problem:
_hwlg_0 = with /** FOLDABLE (all gen's const) **/
/** REFERENCED: 1 (total num refs) **/
{
([ 0, 0 ] <= iv=[_eat_37, _eat_36] < [ 100, 50 ])
{
...
} : _al_1166 ;
} :
fold( ScalarArith::+, _flat_5);
b = with /** FOLDABLE (all gen's const) **/
/** REFERENCED: 1 (total num refs) **/
{
([ 0, 50 ] <= iv__SSA0_1=[_eat_39, _eat_38] < [ 100, 100 ])
{
...
} : _pinl_447__flat_205 ;
} :
fold( ScalarArith::+, _hwlg_0);
If one looks at the generator of _hwlg_0, "handle_with_loop_generators" it even clams that it is doing it
* This traversal transformes Multi-Generator With-Loops into sequences of
* Single-Generator With-loops. To understand the basic principle, let us look
* at the three base cases:
* Expressions of the forms:
*
* with { with { with {
* ( <p1> ) : e1; ( <p1> ) : e1; ( <p1> ) : e1;
* ( <p2> ) : e2; ( <p2> ) : e2; ( <p2> ) : e2;
* ( <p3> ) : e3; ( <p3> ) : e3; ( <p3> ) : e3;
* } genarray( shp, def) } modarray( a) } fold( fun, neutr)
*
* are semantically equivalent to
*
* with { with { with {
* ( <p3> ) : e3; ( <p3> ) : e3; ( <p3> ) : e3;
* } modarray( tmp) } modarray( tmp) } fold( fun, tmp)
*
* provided the variable tmp is defined as
*
* tmp = with { tmp = with { tmp = with {
* ( <p2> ) : e2; ( <p2> ) : e2; ( <p2> ) : e2;
* } modarray( tmp2); } modarray( tmp2); } fold( fun, tmp2);
*
* and tmp2 is defined as
*
* tmp2 = with { tmp2 = with { tmp2 = with {
* ( <p1> ) : e1; ( <p1> ) : e1; ( <p1> ) : e1;
* } genarray( shp, def); } modarray( a); } fold( fun, neutr);
So does this mean that hwlg is wrong with its long description of what it does and not being touched since 2007-11-13 or is the ast with its bad name and mutc and mt backends that do not expect this to happen.
One would expect the neutral element of the fold to have the following properties:
tutu = foldop( neutral, tutu);
tutu = foldop( tutu, neutral);
neutral = foldop( neutral, neutral);</pre>Carl JoslinCarl Joslinhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1322Major issue in loop handling2017-11-19T20:38:44ZKai TrojahnerMajor issue in loop handling| | |
| --- | --- |
| Bugzilla Link | [110](http://bugs.sac-home.org/show_bug.cgi?id=110) |
| Created on | Sep 01, 2005 08:24 |
| Resolution | FIXED |
| Resolved on | Jun 16, 2008 13:08 |
| Version | 1.00beta |
| OS | All |
| Architect...| | |
| --- | --- |
| Bugzilla Link | [110](http://bugs.sac-home.org/show_bug.cgi?id=110) |
| Created on | Sep 01, 2005 08:24 |
| Resolution | FIXED |
| Resolved on | Jun 16, 2008 13:08 |
| Version | 1.00beta |
| OS | All |
| Architecture | All |
| Attachments | [tutu2.sac](/uploads/12f8128356c2851ce9c571e75a6ab67d/tutu2.sac), [rotate.sac](/uploads/4200f33b3bbd4206cd3f7dc837578f10/rotate.sac), [test.sac](/uploads/19d456db98212e18b2df21d62e90284b/test.sac) |
## Extended Description
<pre>The attached example behaves differently depending on whether or not Loop Invariant Removal is
activated or not. As I am yet not sure where this bug does actually stem from, I will shortly discuss what
I found out.
The example looks like this:
use Array: all;
use SimplePrint: all;
int main() {
A = with (.<=iv=[x,y]<=.) {
i = 0;
do {
i = i+1;
} while ( i+x<10);
}
genarray( [10,10],i);
c = print( A);
return(c);
}
When stopping the compilation after the optimizations (currently -b13) the relevant part of the code
looks like this:
i = 0;
A = with ( _flat_7_iv )
([ 0, 0 ] <= _flat_7_iv=[_flat_5_x, _flat_6_y] (IDXS:_wlidx_88_A) < [ 10, 10 ]) {
do
{
i__SSA0_1 = (i + 1);
_pinl_90___flat_88 = (i__SSA0_1 + _flat_5_x);
_pinl_91___flat_45 = (_pinl_90___flat_88 < 10);
i = i__SSA0_1;
}
while (_pinl_91___flat_45);
} : i__SSA0_1 ;
genarray( [ 10, 10 ]) /* IDX: _wlidx_88_A */;
As we can now clearly see, the errornous behaviour stems from i being overwritten in the with-loop
body. However, the problem IS NOT caused by Loop Invariant Removal as i = 0 does certainly not
depend on the index vector and is thus moved out of the with-loop correctly.
The issue becomes even more dramatic in this slightly modified example whose execution does not
terminate at all:
int main() {
i = 0;
A = with (.<=iv=[x,y]<=.) {
do {
i = i+1;
} while ( i+x<10);
}
genarray( [10,10],i);
c = print( A);
return(c+i);
}
My guess is that this bug is caused by lac2fun. What do you think?
Cheers,
Kai</pre>Clemens GrelckClemens Grelckhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1323Compilation of the old backend aborts at gen_startup_code.c.2017-11-19T20:38:50ZKai TrojahnerCompilation of the old backend aborts at gen_startup_code.c.| | |
| --- | --- |
| Bugzilla Link | [21](http://bugs.sac-home.org/show_bug.cgi?id=21) |
| Created on | Aug 05, 2003 17:00 |
| Resolution | FIXED |
| Resolved on | Aug 05, 2003 18:22 |
| Version | 1.00beta |
| OS | All |
| Architectur...| | |
| --- | --- |
| Bugzilla Link | [21](http://bugs.sac-home.org/show_bug.cgi?id=21) |
| Created on | Aug 05, 2003 17:00 |
| Resolution | FIXED |
| Resolved on | Aug 05, 2003 18:22 |
| Version | 1.00beta |
| OS | All |
| Architecture | All |
## Extended Description
<pre>Compiler compilation with the old backend aborts at compilation of
gen_startup_code.c.
make reports:
gen_startup_code.c: In function `GSCPrintMain':
gen_startup_code.c:922: `mythread_nt' undeclared (first use in this function)
gen_startup_code.c:922: (Each undeclared identifier is reported only once
gen_startup_code.c:922: for each function it appears in.)
make[1]: *** [gen_startup_code.o] Error 1</pre>Dietmar KreyeDietmar Kreyehttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1324crc2.sac kills sac2c inserting SAA into concrete args2017-11-19T20:38:56ZRobert Berneckycrc2.sac kills sac2c inserting SAA into concrete args| | |
| --- | --- |
| Bugzilla Link | [364](http://bugs.sac-home.org/show_bug.cgi?id=364) |
| Created on | May 15, 2007 15:40 |
| Resolution | FIXED |
| Resolved on | Jun 12, 2007 15:03 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [364](http://bugs.sac-home.org/show_bug.cgi?id=364) |
| Created on | May 15, 2007 15:40 |
| Resolution | FIXED |
| Resolved on | Jun 12, 2007 15:03 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crc2.sac](/uploads/838333d43970910359d12e63dc9758e0/crc2.sac) |
## Extended Description
The attached crashes sac2c in PrependSAAInConcreteArgs.Florian BütherFlorian Bütherhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1325SSAWLT.c does not handle fold-with-loops correctly2017-11-19T20:39:03ZDietmar KreyeSSAWLT.c does not handle fold-with-loops correctly| | |
| --- | --- |
| Bugzilla Link | [35](http://bugs.sac-home.org/show_bug.cgi?id=35) |
| Created on | Mar 10, 2004 02:48 |
| Resolution | FIXED |
| Resolved on | May 11, 2004 14:56 |
| Version | 1.00beta |
| OS | All |
| Architectur...| | |
| --- | --- |
| Bugzilla Link | [35](http://bugs.sac-home.org/show_bug.cgi?id=35) |
| Created on | Mar 10, 2004 02:48 |
| Resolution | FIXED |
| Resolved on | May 11, 2004 14:56 |
| Version | 1.00beta |
| OS | All |
| Architecture | All |
| Attachments | [tutu.sac](/uploads/b41e7f1d9b44c457c0cec5560e87a532/tutu.sac), [simple.sac](/uploads/4612d8fc0c9c2b88d74a7c5afd236787/simple.sac) |
## Extended Description
<pre>The function 'CreateFullPartition' in file 'SSAWLT.c' can not handle fold-WLs
(see code line 436). However, this function is in fact called for fold-WLs which
causes a DBUG_ASSERT...
Note: This bug does not occur until revision 1.25 of the file 'SSAWLT.c'! This
revision contains an explicit check whether the WL is a fold-WL in order to
prevent the call of 'CreateFullPartition' in this case!
A SAC-file for reproducing this bug will be given as attachment.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1326printing new type signature fails2017-11-19T20:39:09ZDietmar Kreyeprinting new type signature fails| | |
| --- | --- |
| Bugzilla Link | [49](http://bugs.sac-home.org/show_bug.cgi?id=49) |
| Created on | Aug 26, 2004 01:25 |
| Resolution | LATER |
| Resolved on | Aug 26, 2004 13:11 |
| Version | 1.00beta |
| OS | All |
| Architectur...| | |
| --- | --- |
| Bugzilla Link | [49](http://bugs.sac-home.org/show_bug.cgi?id=49) |
| Created on | Aug 26, 2004 01:25 |
| Resolution | LATER |
| Resolved on | Aug 26, 2004 13:11 |
| Version | 1.00beta |
| OS | All |
| Architecture | All |
| Attachments | [bug_print.sac](/uploads/f00700ad6275e1aa84e35c577fd2a8c4/bug_print.sac) |
## Extended Description
<pre>During print-traversal the function PrintFunctionHeader() fails in printing the
new type signature in certain situations.
An example SAC program will be given as attachment.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1327tmpnam deprecated warning linux2017-11-19T20:39:15ZStephan Herhuttmpnam deprecated warning linux| | |
| --- | --- |
| Bugzilla Link | [9](http://bugs.sac-home.org/show_bug.cgi?id=9) |
| Created on | Mar 25, 2003 21:09 |
| Resolution | FIXED |
| Resolved on | Apr 11, 2003 11:59 |
| Version | 1.00beta |
| OS | Linux |
| Architectur...| | |
| --- | --- |
| Bugzilla Link | [9](http://bugs.sac-home.org/show_bug.cgi?id=9) |
| Created on | Mar 25, 2003 21:09 |
| Resolution | FIXED |
| Resolved on | Apr 11, 2003 11:59 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>On linus systems using newer versions of glibc, a warning is emitted, that
tmpnam should be avoided for security reasons. The reason is, that some
application could hijack the temporary sac2c directory and thus get sac2c user
privileges and change files.
As sac2c is a compiler and does no security relevant things this is a minor bug.
A solutions would be mkdtemp, which directly creates the directory and by thus
avoids any race-conditions (this solutions is proposed by glibc developers).
mkdtemp is no common unix function and thus not portable.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1328new TC does not accept dim( [] )2017-11-19T20:39:21ZKai Trojahnernew TC does not accept dim( [] )| | |
| --- | --- |
| Bugzilla Link | [37](http://bugs.sac-home.org/show_bug.cgi?id=37) |
| Created on | Jun 18, 2004 11:17 |
| Resolution | FIXED |
| Resolved on | Jun 21, 2004 22:47 |
| Version | 1.00beta |
| OS | SunOS |
| Architect...| | |
| --- | --- |
| Bugzilla Link | [37](http://bugs.sac-home.org/show_bug.cgi?id=37) |
| Created on | Jun 18, 2004 11:17 |
| Resolution | FIXED |
| Resolved on | Jun 21, 2004 22:47 |
| Version | 1.00beta |
| OS | SunOS |
| Architecture | Sun |
| Attachments | [bug37_a.sac](/uploads/071581a800ba96631b935f5cc9cc3a28/bug37_a.sac) |
## Extended Description
<pre>The new TC does not accept a program like the following:
#include "NTCtemplates.mac"
#define SCALAR_SEL
int main() {
return (dim( [] ));
}
or
int main() {
}</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1329SSA renaming scheme is dangerous2017-11-19T20:39:27ZKai TrojahnerSSA renaming scheme is dangerous| | |
| --- | --- |
| Bugzilla Link | [42](http://bugs.sac-home.org/show_bug.cgi?id=42) |
| Created on | Aug 04, 2004 17:19 |
| Resolution | FIXED |
| Resolved on | Aug 05, 2004 23:15 |
| Version | 1.00beta |
| OS | All |
| Architectur...| | |
| --- | --- |
| Bugzilla Link | [42](http://bugs.sac-home.org/show_bug.cgi?id=42) |
| Created on | Aug 04, 2004 17:19 |
| Resolution | FIXED |
| Resolved on | Aug 05, 2004 23:15 |
| Version | 1.00beta |
| OS | All |
| Architecture | Sun |
| Attachments | [ssabug.sac](/uploads/35573ef6b45e366c39af5ace6e48b80c/ssabug.sac) |
## Extended Description
<pre>Multiple SSA transformations can lead to multiple declarations of variables due
to SSATransforms renaming scheme.
Take a look at the following example:
int[.], int[.] buggy( int[.] z)
{
unew = with (. <= iv <= .)
{
zsum = 2 * z[iv];
}
genarray ([1024], zsum);
unew = with ([0] <= iv <= [0])
modarray (unew, iv, unew[[1023]]);
vnew = with (. <= iv <= .)
{
zsum = 2 * z[iv];
}
genarray ([1024], zsum);
return (unew, vnew);
}
As the syntaxtree is converted in and out of SSA form during WLEnhancement
(activated via -khf), zsum in the second with-loop is renamed into zsum__SSA1.
After UndoSSATransform in WLEnhancment, zsum__SSA1 is not re-renamed into zsum.
Now, with-loop folding folds the first two with-loops, yielding a new with-loop
with two generators whose results are both names zsum. The subsequent call of
RestoreSSAOneFunction will rename the second result into zsum__SSA1 which
already exists!</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1330Invalid fold-funs can lead to memory leaks in EMM2017-11-19T20:39:33ZKai TrojahnerInvalid fold-funs can lead to memory leaks in EMM| | |
| --- | --- |
| Bugzilla Link | [43](http://bugs.sac-home.org/show_bug.cgi?id=43) |
| Created on | Aug 08, 2004 14:28 |
| Resolution | FIXED |
| Resolved on | Aug 08, 2004 15:52 |
| Version | 1.00beta |
| OS | SunOS |
| Architect...| | |
| --- | --- |
| Bugzilla Link | [43](http://bugs.sac-home.org/show_bug.cgi?id=43) |
| Created on | Aug 08, 2004 14:28 |
| Resolution | FIXED |
| Resolved on | Aug 08, 2004 15:52 |
| Version | 1.00beta |
| OS | SunOS |
| Architecture | Sun |
| Attachments | [leak.sac](/uploads/b86d42a826631ea1c35e6017a59b07b1/leak.sac) |
## Extended Description
<pre>In the livermore-loops examples, often the following fold function is used:
inline int[.] second( int[.] a, int[.] b) {
return(b);
}
Using this fold function allows to abuse the fold-withloop as some kind of
iteration construct. Unfortunately this will lead to memory leak if accumulation
is made explicit.
Have a look at the following example:
inline int[.] second( int[.] a, int[.] b) {
res = b;
return(res);
}
int[.] f( int[.] iv, int[.] A) {
return( A);
}
int main() {
A = with (. <= iv <= .) genarray( [1024], 1);
n = with (. <= iv <= .) genarray( [1024], 0);
F = with ([0] <= iv < [10])
fold ( second, n, f(iv,A));
return( F[[0]]);
}
After b14 the fold withloop looks like this:
F = with ( _flat_6_iv )
(_flat_4 <= _flat_6_iv=[_type_12] < _flat_5)
{
_ea_15_F = accu( _flat_6_iv);
_flat_7 = _MAIN:f( _flat_6_iv, A);
_ea_16__flat_7 = _FOLD:_type_13__MAIN__second( _ea_15_F, _flat_7);
} : _ea_16__flat_7 ;
fold/*fun*/( _FOLD:_type_13__MAIN__second, n);
After inlining the fold function we get:
F = with ( _flat_6_iv )
(_flat_4 <= _flat_6_iv=[_type_12] < _flat_5)
{
_ea_15_F = accu( _flat_6_iv);
_flat_7 = _MAIN:f( _flat_6_iv, A);
_inl_20__flat_7 = _flat_7;
_inl_19_F = _ea_15_F;
_inl_23_b = _inl_20__flat_7;
_inl_22_a = _inl_19_F;
_inl_21_res = _inl_23_b;
_inl_17__type_14_F = _inl_21_res;
_inl_18_F__SSA0_1 = _inl_17__type_14_F;
_ea_16__flat_7 = _inl_18_F__SSA0_1;
} : _ea_16__flat_7 ;
fold/*fun*/( _FOLD:_type_13__MAIN__second, n);
And finally, after the first application of DCR we obtain:
F = with ( _flat_6_iv )
([ 0 ] <= _flat_6_iv=[_type_12] < [ 10 ])
{
_flat_7 = _MAIN:f( _flat_6_iv, A);
} : _flat_7 ;
fold/*fun*/( _FOLD:_type_13__MAIN__second, n);
This seems to be a great optimization result, but unfortunately, we lost the
handle to the last intermediate fold result which was represented by accu().</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1331assertion failure in tree_compound.c2017-11-19T20:39:39ZRobert Berneckyassertion failure in tree_compound.c| | |
| --- | --- |
| Bugzilla Link | [50](http://bugs.sac-home.org/show_bug.cgi?id=50) |
| Created on | Sep 02, 2004 16:33 |
| Resolution | WONTFIX |
| Resolved on | Jun 27, 2005 11:50 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [50](http://bugs.sac-home.org/show_bug.cgi?id=50) |
| Created on | Sep 02, 2004 16:33 |
| Resolution | WONTFIX |
| Resolved on | Jun 27, 2005 11:50 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug_50a.sac](/uploads/5a6d50773c67891be05176ba457d3085/bug_50a.sac) |
## Extended Description
<pre>** 7: Running type inference system: ...
Assertion 'expr' failed: file 'tree_compound.c', line 1213
** Failed attempt to look up typedef
Code appears as comment later I hope.
rbe</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1332DupTree handles no ntype types2017-11-19T20:39:45ZStephan HerhutDupTree handles no ntype types| | |
| --- | --- |
| Bugzilla Link | [64](http://bugs.sac-home.org/show_bug.cgi?id=64) |
| Created on | Sep 27, 2004 11:17 |
| Resolution | FIXED |
| Resolved on | Dec 19, 2004 13:54 |
| Version | 1.00beta |
| OS | SunOS |
| Architect...| | |
| --- | --- |
| Bugzilla Link | [64](http://bugs.sac-home.org/show_bug.cgi?id=64) |
| Created on | Sep 27, 2004 11:17 |
| Resolution | FIXED |
| Resolved on | Dec 19, 2004 13:54 |
| Version | 1.00beta |
| OS | SunOS |
| Architecture | All |
## Extended Description
The DupTree traversal does not handle ntype type attributes! They are not copied
at all. This leads to a type information loss during SSATransform, as there
nodes are copied and then loose their respective new type.
For Avis nodes this has already been fixed (to solve the problem with ssa
transform). Due to lack of time, I give the bug to the public to prevent it from
beeing forgotten!BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1333Missing documentation2017-11-19T20:39:50ZRobert BerneckyMissing documentation| | |
| --- | --- |
| Bugzilla Link | [66](http://bugs.sac-home.org/show_bug.cgi?id=66) |
| Created on | Oct 05, 2004 20:18 |
| Resolution | FIXED |
| Resolved on | Oct 15, 2004 17:28 |
| Version | 1.00beta |
| OS | Linux |
| Architect...| | |
| --- | --- |
| Bugzilla Link | [66](http://bugs.sac-home.org/show_bug.cgi?id=66) |
| Created on | Oct 05, 2004 20:18 |
| Resolution | FIXED |
| Resolved on | Oct 15, 2004 17:28 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The "component" above should read "documentation" or
"reference manual" or "Bobbo can't RTFM."
1. I can't find where the format of floating and double
constants is defined. I want a scientific notation
form such as: 1E-13
2. I can't find any definition of acceptable character constants.
Or unacceptable ones, for that matter.
The specific problem I ran into was/is building a constant vector
of the entire 256-element 8-bit ASCII character set.
The compiler appears to complain about:</pre>BugZillaBugZilla