sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:34:43Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1269-doipc is apparently not an adequate replacement for -dowls: ktrvariant.sac2017-11-19T20:34:43ZRobert Bernecky-doipc is apparently not an adequate replacement for -dowls: ktrvariant.sac| | |
| --- | --- |
| Bugzilla Link | [1086](http://bugs.sac-home.org/show_bug.cgi?id=1086) |
| Created on | Sep 24, 2013 19:53 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ktrvariant.sac](/uploads/e78bb3ce...| | |
| --- | --- |
| Bugzilla Link | [1086](http://bugs.sac-home.org/show_bug.cgi?id=1086) |
| Created on | Sep 24, 2013 19:53 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ktrvariant.sac](/uploads/e78bb3ce60de65d46f0988db45c5e8dd/ktrvariant.sac) |
## Extended Description
<pre>Created an attachment (id=984)
source code to reproduce fault
This was observed on Build #18308, in the ipc unit test suite:
sac2c ktrvariant.sac -O3
sac@rattler:~/sac/testsuite/optimizations/ipc$ time a.out; echo $?
real 0m0.608s
user 0m0.600s
sys 0m0.000s
0
sac@rattler:~/sac/testsuite/optimizations/ipc$ sac2c ktrvariant.sac -O3 -nowls
sac@rattler:~/sac/testsuite/optimizations/ipc$ time a.out; echo $?
real 0m1.978s
user 0m1.240s
sys 0m0.730s
0
sac@rattler:~/sac/testsuite/optimizations/ipc$ sac2c ktrvariant.sac -O3 -noipc
sac@rattler:~/sac/testsuite/optimizations/ipc$ time a.out; echo $?
real 0m0.608s
user 0m0.590s
sys 0m0.010s
0
sac@rattler:~/sac/testsuite/optimizations/ipc$ sac2c ktrvariant.sac -O3 -noipc -nowls
sac@rattler:~/sac/testsuite/optimizations/ipc$ time a.out; echo $?
real 0m2.180s
user 0m1.490s
sys 0m0.680s
0
Bodo claimed, earlier today, that IPC should (my words) be able to
supplant WLS. The above timings show that, for this test, at least:
1. If WLS is enabled, IPC does nothing more for us.
2. If WLS is disabled, IPC is not able to do generate code that
performs as well as WLS.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1270Naked selection from multi-partition WL does not work2017-11-19T20:34:46ZRobert BerneckyNaked selection from multi-partition WL does not work| | |
| --- | --- |
| Bugzilla Link | [1087](http://bugs.sac-home.org/show_bug.cgi?id=1087) |
| Created on | Sep 24, 2013 23:02 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [buglacso.nakedselbug.sac](/upload...| | |
| --- | --- |
| Bugzilla Link | [1087](http://bugs.sac-home.org/show_bug.cgi?id=1087) |
| Created on | Sep 24, 2013 23:02 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [buglacso.nakedselbug.sac](/uploads/51e0d28247411dd0e780ed1db2e403ff/buglacso.nakedselbug.sac) |
## Extended Description
<pre>Naked selection from a single-partition WL works fine, e.g.:
vec = iota(N);
z = _sel_VxA_( iv, vec);
However, if vec has multiple WL partitions, then AWLF can not always
statically pick a partition from which to fold.
Bodo suggested, a few weeks ago, that we should generate
conditionals on the partition bounds to support this capability.
E.g., if vec has three partitions, and generator bounds of:
P0: lb0 ub0
P1: lb1 ub1
P2: lb2 ub2
z = ( member( iv, lb0, ub0) ? indexfrom( iv, P0) :
member( iv, lb1, ub1) ? indexfrom( iv, P1) :
member( iv, lb2, ub2) ? indexfrom( iv, P2) :
indexerror);
where:
member( iv, lb, ub) = (iv<=lb) && (iv<ub);
indexfrom( iv, partn) = _sel_VxA_( iv, codeblock from partn goes here).
Question: Can we legally introduce funconds for this dynamically, or must
we go for a condfun chain?</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1271WRCI fails for blocked_cholesky.sac2017-11-19T20:34:50ZRobert BerneckyWRCI fails for blocked_cholesky.sac| | |
| --- | --- |
| Bugzilla Link | [1093](http://bugs.sac-home.org/show_bug.cgi?id=1093) |
| Created on | Oct 01, 2013 17:43 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The code below is p...| | |
| --- | --- |
| Bugzilla Link | [1093](http://bugs.sac-home.org/show_bug.cgi?id=1093) |
| Created on | Oct 01, 2013 17:43 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The code below is patched for big AAA...
sac2c -v0 -O3 bodoDatareuseBug.sac -douip -maxwlur 2 -nowlf -noawlf -bopt:wrci >crudn
sac@rattler:~/sac/testsuite/optimizations/dr$ sac2c -v0 -O3 bodoDatareuseBug.sac -douip -maxwlur 2 -dowlf -noawlf -bopt:wrci >crudd
sac@rattler:~/sac/testsuite/optimizations/dr$ grep RC crudn
genarray( [ _pinl_272__wlbsc_222_sc_e ], _flat_14, RC(_flat_11));
modarray( AAA ,RC(AAA));
sac@rattler:~/sac/testsuite/optimizations/dr$ grep RC crudd
sac@rattler:~/sac/testsuite/optimizations/dr$ cat bodoDatareuseBug.sac
/*
* This is a fault reported by Bodo on a Blocked Cholesky
* benchmark.
*
* He says:
*
* It's two problems: one in wrci, and one in dr:
*
* wrci cannot deal with idxsels
* and dr cannot deal with additions of idxs
*
*/
/* RESULT: noop 0 6 */
/* FILTER: no-no */
use Array: all;
int main()
{
AAA = genarray([10000,10],1);
for( i=0; i<1000000; i++) {
AAA = with {
([3] <= iv < [88]): AAA[[3]] + 2;
} : modarray(AAA);
}
z = sum( AAA);
StdIO::print( z);
z = z - 1700001000;
return( z);
}</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1272WRCI with -dopra allows array reuse on same-partition indexing2017-11-19T20:34:54ZRobert BerneckyWRCI with -dopra allows array reuse on same-partition indexing| | |
| --- | --- |
| Bugzilla Link | [1095](http://bugs.sac-home.org/show_bug.cgi?id=1095) |
| Created on | Oct 03, 2013 19:47 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug980.breaks.sac](/uploads/05617...| | |
| --- | --- |
| Bugzilla Link | [1095](http://bugs.sac-home.org/show_bug.cgi?id=1095) |
| Created on | Oct 03, 2013 19:47 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug980.breaks.sac](/uploads/0561780e18581c70e55792679564783f/bug980.breaks.sac), [wrciOffsetTooSmall.sac](/uploads/913792fccdf9e3e3916225cd9bd92097/wrciOffsetTooSmall.sac) |
## Extended Description
<pre>Created an attachment (id=990)
source code to reproduce fault
Indexed references within a modarray that refer to the current
partition should prohibit array reuse. Compiling with -dopra,
however, thinks it can operate in place. This causes
wrong answers in the wrci unit test bug980.breaks.sac
and also can be seen here:
sac@rattler:~/sac/testsuite/optimizations/wrci$ sac2c wrciOffsetTooSmall.sac -v1 -dopra -bopt:wrci -nowlf |grep RC
modarray( AAA ,RC(AAA));
sac@rattler:~/sac/testsuite/optimizations/wrci$ sac2c wrciOffsetTooSmall.sac -v1 -bopt:wrci |grep RC
sac@rattler:~/sac/testsuite/optimizations/wrci$ cat wrciOffsetTooSmall.sac /*
* Attempt to unit test RWO (Reuse With Offset), based
* on zero documentation in the C code.
*
* AAA should NOT be a datareuse candidate, because
* the index offset refers to data in the same partition.
* See RWOprf for this case.
*
*/
/* RESULT: RC(AAA) 0 0 */
use Array: all;
int main()
{
AAA = _reshape_VxA_( [ 25, 10], iota( 250));
AAA = with {
([0,0] <= iv < [10,10]): AAA[iv + [ 9, 0]] + 1000;
} : modarray(AAA);
//StdIO::print(AAA);
z = sum( AAA);
//StdIO::print(z);
z = _sub_SxS_( z, 140125);
return( z);
}
sac@rattler:~/sac/testsuite/optimizations/wrci$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 18312 linux-gnu_x86_64
(Thu Oct 3 14:40:19 EDT 2013 by sac)</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1273-nowlf beats -doawlf2017-11-19T20:34:58ZRobert Bernecky-nowlf beats -doawlf| | |
| --- | --- |
| Bugzilla Link | [1097](http://bugs.sac-home.org/show_bug.cgi?id=1097) |
| Created on | Oct 08, 2013 16:04 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug1096B.sac](/uploads/23f080a104...| | |
| --- | --- |
| Bugzilla Link | [1097](http://bugs.sac-home.org/show_bug.cgi?id=1097) |
| Created on | Oct 08, 2013 16:04 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug1096B.sac](/uploads/23f080a10498e1ea44a788295968d2d6/bug1096B.sac) |
## Extended Description
<pre>Created an attachment (id=992)
source code to reproduce fault
This is an outgrowth of Bug #1096, but is likely unrelated to it.
The apparent problem with that -nowlf is beating -dowlf.
Here are some code fragments showing relative performance
and AST code:
sac2c bug1096.sac -v1 -O3 -dowlf
sac@rattler:~/sac/testsuite/optimizations/wrci$ time a.out; echo $?
Dimension: 0
Shape : < >
3550
real 0m7.928s
user 0m7.910s
sys 0m0.010s
82
sac@rattler:~/sac/testsuite/optimizations/wrci$ sac2c bug1096.sac -v1 -O3
-nowlf
sac@rattler:~/sac/testsuite/optimizations/wrci$ time a.out; echo $?
Dimension: 0
Shape : < >
3550
real 0m5.203s
user 0m5.180s
sys 0m0.020s
82
Now, if we look at the with2 in Loop_0, we have this for -nowlf:
AAA__SSA0_1 = with2 (_wlsb_495=[_eat_26, _eat_465]
(IDXS:_wlidx_1275_AAA__SSA0_1))
/********** operators: **********/
op_0 =
{
_emal_1442__dup_508__wlsw_494 = _alloc_( 1, 0, [:int]);
_dup_508__wlsw_494 = _fill_( _idx_sel_( _eat_465,
_dup_472__pinl_314_res), _emal_1442__dup_508__wlsw_494);
_emal_1443_val = _wl_assign_( _dup_508__wlsw_494,
_emal_1441_AAA__SSA0_1, _wlsb_495, _wlidx_1275_AAA__SSA0_1);
_free_( _dup_508__wlsw_494);
} : _emal_1443_val ; ,
op_1 =
{
_emdr_1662 = _noop_( _wlsb_495);
} : _emdr_1662 ;
and this for -dowlf (note that op0 and op1 are swapped from the previous code):
op_0 =
{
_emdr_1616 = _noop_( _wlsb_492);
} : _emdr_1616 ; ,
op_1 =
{
_emal_1398__ivesli_1265 = _alloc_( 1, 0, [:int]);
_ivesli_1265 = _fill_( _idxs2offset_( [ 100, 10 ], _iveras_1365,
_eat_462), _emal_1398__ivesli_1265);
_ivesli_1266 = _fill_( _add_SxS_( 30, _ivesli_1265), _ivesli_1265);
_emal_1396__dup_472__pinl_297__flat_23__SSA2_1__SSA3_1 = _alloc_( 1,
0, [:int]);
_dup_472__pinl_297__flat_23__SSA2_1__SSA3_1 = _fill_( _idx_sel_(
_ivesli_1266, _dup_539_AAA),
_emal_1396__dup_472__pinl_297__flat_23__SSA2_1__SSA3_1);
_free_( _ivesli_1266);
_dup_473__pinl_313__flat_107__SSA3_1 = _fill_( _add_SxS_(
_dup_472__pinl_297__flat_23__SSA2_1__SSA3_1, 3),
_dup_472__pinl_297__flat_23__SSA2_1__SSA3_1);
_emal_1399_val = _wl_assign_( _dup_473__pinl_313__flat_107__SSA3_1,
_emal_1391_AAA__SSA0_1, _wlsb_492, _wlidx_1254_AAA__SSA0_1);
_free_( _dup_473__pinl_313__flat_107__SSA3_1);
} : _emal_1399_val ;
-doivecyc and -doive are not, apparently, part of the problem:
sac2c bug1096.sac -v1 -O3 -dowlf -noivecyc
sac@rattler:~/sac/testsuite/optimizations/wrci$ time a.out; echo $?
Dimension: 0
Shape : < >
3550
real 0m7.874s
user 0m7.870s
sys 0m0.000s
82
sac@rattler:~/sac/testsuite/optimizations/wrci$ sac2c bug1096.sac -v1 -O3 -dowlf -noivecyc -noive
sac@rattler:~/sac/testsuite/optimizations/wrci$ time a.out; echo $?
Dimension: 0
Shape : < >
3550
real 0m28.403s
user 0m28.400s
sys 0m0.000s
82
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18394 linux-gnu_x86_64
(Tue Oct 8 10:24:38 EDT 2013 by sac)</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1274TC isn't much help in error reporting2017-11-19T20:35:01ZRobert BerneckyTC isn't much help in error reporting| | |
| --- | --- |
| Bugzilla Link | [1102](http://bugs.sac-home.org/show_bug.cgi?id=1102) |
| Created on | Nov 10, 2013 19:16 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipddStar.sac](/uploads/929ac54e22...| | |
| --- | --- |
| Bugzilla Link | [1102](http://bugs.sac-home.org/show_bug.cgi?id=1102) |
| Created on | Nov 10, 2013 19:16 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipddStar.sac](/uploads/929ac54e22e8c59af850da692e3a97e3/ipddStar.sac) |
## Extended Description
<pre>Created an attachment (id=995)
source code to reproduce fault
sac2c ipddStar.sac -v1
typecheck/new_types.c:904 Assertion "(NTYPE_CON(array) == TC_aks) || (NTYPE_CON(array) == TC_akv) || (NTYPE_CON(array) == TC_akd) || (NTYPE_CON(array) == TC_audgz) || (NTYPE_CON(array) == TC_aud)" failed!
TYgetScalar applied to other than array type!
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18410 linux-gnu_x86_64
(Sat Nov 9 16:39:54 EST 2013 by sac)
The problem is in this line:
Crow = plusDDD( toD( y[colx]), Crow );
plusDDD() exists, but only for scalar-scalar arguments;
the code wants a vector-vector function, but it does not
exist. It would be nice if it told us that.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1275ipbb.sac: POGO fails to remove guard due to no extrema on induction variable2017-11-19T20:35:05ZRobert Berneckyipbb.sac: POGO fails to remove guard due to no extrema on induction variable| | |
| --- | --- |
| Bugzilla Link | [1129](http://bugs.sac-home.org/show_bug.cgi?id=1129) |
| Created on | Sep 04, 2014 22:05 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbb.sac](/uploads/1bb72846bec0cf...| | |
| --- | --- |
| Bugzilla Link | [1129](http://bugs.sac-home.org/show_bug.cgi?id=1129) |
| Created on | Sep 04, 2014 22:05 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbb.sac](/uploads/1bb72846bec0cfc6a16c3acb44a5b8ca/ipbb.sac) |
## Extended Description
<pre>Created an attachment (id=1012)
Source code to reproduce fault
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18604
(Thu Sep 4 16:26:21 EDT 2014 by sac)
The ipbb.sac test case in the polylib unit tests fails, because
PETL does not compute extrema for the induction variable, colx.
The polylib UnitTestRunGreps otherwise runs clean.
UnitTestRunWorks fails due to linker problems, still unresolved.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1278#pragma noinline not working as expected2017-11-19T20:35:15ZHans-Nikolai Viessmann#pragma noinline not working as expected| | |
| --- | --- |
| Bugzilla Link | [1175](http://bugs.sac-home.org/show_bug.cgi?id=1175) |
| Created on | Nov 23, 2015 23:54 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Given a function id...| | |
| --- | --- |
| Bugzilla Link | [1175](http://bugs.sac-home.org/show_bug.cgi?id=1175) |
| Created on | Nov 23, 2015 23:54 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Given a function id():
int[*] id(int[*] a)
{ return a; }
#pragma noinline
Using `#pragma noinline' to prevent any inlining (via AINL) does not have the
intended effect - id() is selected for inlining.
Tracing though the compilations steps, the issue arises from libsac2c/scanparse/resolvepragma.c where the traversal (called RSP) does *not* traverse into ordinary N_fundef, only those linked to MODULE_FUNDECS, which means that the pragma is never resolved and the FUNDEF_NOINLINE flag is never set.
Looking through the RSP reversal, it becomes clear that it is only designed to handle external declarations, with asserts existing within RSPfundef() to ensure that only fundefs with ISEXTERN are traversed/modified.
My questions is, why are the pragmas of external declarations only 'resolved' and not all function declarations?</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1279LUR fails if FOR-loop condition reversed2017-11-19T20:35:18ZRobert BerneckyLUR fails if FOR-loop condition reversed| | |
| --- | --- |
| Bugzilla Link | [1178](http://bugs.sac-home.org/show_bug.cgi?id=1178) |
| Created on | Apr 14, 2016 17:58 |
| Version | svn |
| OS | Linux |
| Architecture | PC || | |
| --- | --- |
| Bugzilla Link | [1178](http://bugs.sac-home.org/show_bug.cgi?id=1178) |
| Created on | Apr 14, 2016 17:58 |
| Version | svn |
| OS | Linux |
| Architecture | PC |Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1280Intermittent failure with -check c2017-11-19T20:35:22ZRobert BerneckyIntermittent failure with -check c| | |
| --- | --- |
| Bugzilla Link | [1182](http://bugs.sac-home.org/show_bug.cgi?id=1182) |
| Created on | Dec 21, 2016 21:13 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [time2code.sac](/uploads/18118ccfd...| | |
| --- | --- |
| Bugzilla Link | [1182](http://bugs.sac-home.org/show_bug.cgi?id=1182) |
| Created on | Dec 21, 2016 21:13 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [time2code.sac](/uploads/18118ccfd02c7d0424b6e0b8e72a2c00/time2code.sac) |
## Extended Description
<pre>Created an attachment (id=1052)
source code to reproduce failure
****** Optimizing regular function:
****** _MAIN::main( ): ...
Inserting symbolic array attributes ...
Eliminating index vectors (split selections) ...
Eliminating common subexpressions ...
Applying prf unrolling ...
Inferring loop invariant variables ...
Applying type upgrade ...
Eliminating type variables ...
Eliminating bottom types ...
compilation failed while Running SAC optimizations, 1 warning(s).
This failure occurs very sporadically, and it always seems to
go away upon rerunning the compile. It has been around for many
moons.
sac2c -V
sac2c 1.2.beta-BlackForest-348-72a4d
developer
(Wed Dec 21 15:12:02 EST 2016 by sac)
It looks to be related to the use of -check c.
I now have what appears to be a solid failure with -dopogo -check c.
sac2c time2code.sac -v1 -noainl -v4 -check c -dopogo</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1282Floating point fractions must have leading zero, or wrong answer2017-11-19T20:35:29ZRobert BerneckyFloating point fractions must have leading zero, or wrong answer| | |
| --- | --- |
| Bugzilla Link | [1196](http://bugs.sac-home.org/show_bug.cgi?id=1196) |
| Created on | Jun 26, 2017 15:49 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [0001-Fixes-1196.patch](/uploads/3...| | |
| --- | --- |
| Bugzilla Link | [1196](http://bugs.sac-home.org/show_bug.cgi?id=1196) |
| Created on | Jun 26, 2017 15:49 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [0001-Fixes-1196.patch](/uploads/332ca7ffc0f283db8e49ff1e0759731e/0001-Fixes-1196.patch) |
## Extended Description
<pre>The difference in behavior between these two examples seems
very wrong to me.
If it's a bug, it should be fixed. If it's part of the language
definition, the definition is wrong and should be fixed.
cat bugparser.sac
int main()
{
y = 0.0012;
StdIO::print(y);
y = .0012;
StdIO::print(y);
return(0);
}
sac@rattler:~/sac/testsuite/optimizations/pwlf$ sac2c bugparser.sac -v1
sac@rattler:~/sac/testsuite/optimizations/pwlf$ a.out; echo $?
Dimension: 0
Shape : < >
0.0012
Dimension: 0
Shape : < >
0
0
sac2c -V
sac2c 1.2-beta-BlackForest-542-g022cd
build-type: DEBUG
built-by: "sac" at 2017-06-25T17:37:57
I think it's a parser bug:
cat bugparser.sac
int main()
{
x = 0.0012;
StdIO::print(x);
y = .0012;
StdIO::print(y);
z = _sub_SxS_( x, y);
StdIO::print(z);
return(0);
}
sac@rattler:~/sac/testsuite/optimizations/pwlf$ sac2c bugparser.sac -v1
./bugparser.sac 1 error: All instances of "main" contain type errors
error: line 10 in file ./bugparser.sac:
error: Element types of argument #1 and argument #2 of "_sub_SxS_" should be
error: identical; types found: double{0.0...} and int{0}
compilation failed while Running type inference system, 1 error(s).</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1283Are you suffering from Too Much DRAM in mdiv2.sac? Use wlfs!2021-05-26T20:33:03ZRobert BerneckyAre you suffering from Too Much DRAM in mdiv2.sac? Use wlfs!| | |
| --- | --- |
| Bugzilla Link | [312](http://bugs.sac-home.org/show_bug.cgi?id=312) |
| Created on | Oct 24, 2006 18:24 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tjck.sac](/uploads/bd10fbad431...| | |
| --- | --- |
| Bugzilla Link | [312](http://bugs.sac-home.org/show_bug.cgi?id=312) |
| Created on | Oct 24, 2006 18:24 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tjck.sac](/uploads/bd10fbad4312a1cf11992013603eb60b/tjck.sac) |
## Extended Description
<pre>If you compile sac/apex/mdiv2.sac with these parameters,
With-loop fusion gets its knickers in a knot and eats all the memory, eventually.
sac2c -check b -maxwlur 3 -dowlfs apex/mdiv2.sac
rev 15060 gets this...</pre>Clemens GrelckClemens Grelckhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1286problem with saa insertion and modarray WLs2021-05-27T14:01:02ZSven-Bodo Scholzproblem with saa insertion and modarray WLs| | |
| --- | --- |
| Bugzilla Link | [387](http://bugs.sac-home.org/show_bug.cgi?id=387) |
| Created on | Jul 07, 2007 10:04 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [saabug.sac](/uploads/e7738c031...| | |
| --- | --- |
| Bugzilla Link | [387](http://bugs.sac-home.org/show_bug.cgi?id=387) |
| Created on | Jul 07, 2007 10:04 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [saabug.sac](/uploads/e7738c031afffcf4d4649ad1c50bab66/saabug.sac) |
## Extended Description
This is a tricky one...
the type checker takes into account the entire WL for finding out the best
possible return type. SAA insertion uses this info but shortcuts the definition
of the shapes attribute which prevents a successive TC run to be able to verify
that.Florian BütherFlorian Bütherhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/12872D array assignment in for loops2021-09-06T19:43:52ZRobert Stewart2D array assignment in for loops| | |
| --- | --- |
| Bugzilla Link | [1141](http://bugs.sac-home.org/show_bug.cgi?id=1141) |
| Created on | Oct 29, 2014 15:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This code compiles ...| | |
| --- | --- |
| Bugzilla Link | [1141](http://bugs.sac-home.org/show_bug.cgi?id=1141) |
| Created on | Oct 29, 2014 15:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This code compiles just fine:
int main()
{
xs = [1,2,3];
for( i=0; i<3; i++) {
xs[i] = 5;
}
return 1; }
The following very similar code does not compile. The only difference is that it is assigning to a 2D array, rather than a 1D array as before.
int main()
{ xss = [[1,2,3],[4,5,6]];
for( i=0; i<2; i++) {
for( j=0; j<2; j++) {
xss[i][j] = 5;
}
}
return 1; }
The compile error is:
$ sac2c test.sac
./test.sac 5:35 error:
=> token `;' expected, `=' token found
abort: Failed to construct a syntax tree for `test.sac'
compilation failed while Loading SAC program, 1 error(s).
Line 5 is `xss[i][j] = 5;`.</pre>Artem ShinkarovArtem Shinkarovhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1288Buggy AUD code crashes C compiler2021-05-31T12:05:11ZRobert BerneckyBuggy AUD code crashes C compiler| | |
| --- | --- |
| Bugzilla Link | [486](http://bugs.sac-home.org/show_bug.cgi?id=486) |
| Created on | Apr 24, 2009 16:22 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug486.sac](/uploads/857e4581b...| | |
| --- | --- |
| Bugzilla Link | [486](http://bugs.sac-home.org/show_bug.cgi?id=486) |
| Created on | Apr 24, 2009 16:22 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug486.sac](/uploads/857e4581b3cdaa7673dd6ccf46747402/bug486.sac) |
## Extended Description
<pre>I created the attached code in an attempt to see how/if
sac2c deals with multi-partition WLs whose generator bounds
are of different lengths (hence, the program is broken!).
If you compile it with -DAKS or -DAKD, sac2c nicely detects the
problem and reports it in phase 6.
If you compile it with -DAUD, the C compiler dies:
**** Invoking C compiler ...
a.out.c: In function ‘SACf__MAIN__main’:
a.out.c:872: error: ‘SACp_emal_610_x__shpSAC_d’ undeclared (first use in this function)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1290Failure to move invariant WL out of FOR loop kills ipbb performance2017-11-19T20:36:02ZRobert BerneckyFailure to move invariant WL out of FOR loop kills ipbb performance| | |
| --- | --- |
| Bugzilla Link | [524](http://bugs.sac-home.org/show_bug.cgi?id=524) |
| Created on | Jul 14, 2009 04:10 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbb5.slow.sac](/uploads/8d7e3...| | |
| --- | --- |
| Bugzilla Link | [524](http://bugs.sac-home.org/show_bug.cgi?id=524) |
| Created on | Jul 14, 2009 04:10 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbb5.slow.sac](/uploads/8d7e3284e351038555e32585e81d58f7/ipbb5.slow.sac), [bug.funcond.sac](/uploads/510d31f8fba7844dbf4f0fbee5906001/bug.funcond.sac), [bug.compress.breaks.sac](/uploads/828cbca7dac5c005d9f146e53b821e5e/bug.compress.breaks.sac), [iotaonly7.sac](/uploads/f5ee8367f580cbb69881f909b89fc95d/iotaonly7.sac), [crud.slow](/uploads/2cecdb609f665609e8d7170337f12222/crud.slow), [crud.fast](/uploads/4755e5b361dd6e17fbb26472a2aff788/crud.fast) |
## Extended Description
<pre>Created an attachment (id=551)
Shorter source code to reproduce fault
I've been chasing a problem with the performance of a Boolean-Boolean
inner product code, apex/ipbb/ipbb.sac.
Although I think there are some problems with my extrema code in
this area, due to differences in performance in the current system,
the attached shorter example has the interesting property that
the compiler does not appear to be moving a loop-invariant Wl out of a
FOR-loop.
I say this because, if I move the loop out by hand, everything
runs bags faster in both the extrema and non-extrema world.
I am off to bed, so have not looked into this yet...
This all with Build #16193.
With xrow inside FOR-loop:
sac2c -O3:
ipbb5.slow.sac.exe.O3.papiex.rattler.28893:PAPI_TOT_INS: 99065594
sac2c -O3 -extrema -nowlf -doswlf:
ipbb5.slow.sac.exe.swlf.papiex.rattler.28928:PAPI_TOT_INS: 1003065073
With xow outside FOR-loop:
sac2c -O3:
ipbb5.slow.sac.exe.O3.papiex.rattler.28998:PAPI_TOT_INS: 765065354
sac2c -O3 -extrema -nowlf -doswlf:
ipbb5.slow.sac.exe.swlf.papiex.rattler.28970:PAPI_TOT_INS: 765065175</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1291masterrun dies in SCCFprf_modarray1/2 w/production compiler2017-11-19T20:36:05ZRobert Berneckymasterrun dies in SCCFprf_modarray1/2 w/production compiler| | |
| --- | --- |
| Bugzilla Link | [829](http://bugs.sac-home.org/show_bug.cgi?id=829) |
| Created on | Feb 23, 2011 17:12 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Two CF unit tests hav...| | |
| --- | --- |
| Bugzilla Link | [829](http://bugs.sac-home.org/show_bug.cgi?id=829) |
| Created on | Feb 23, 2011 17:12 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Two CF unit tests have been broken on SOME hosts with the production
compiler, for some time now. This from nkk's masterrun of 2011-02-21 21:45:00:
sac2c: Checked out revision 17323.
stdlib: Checked out revision 1495.
Changed behavior when testsuite_res (product version):
************************************************************
/tmp/MASTERR_NzHmu10213/sac/testsuite/optimizations/constantfolding/SCCFprf_modarray1:
base : > /bin/sh: ./SCCFprf_modarray1: No such file or directory
/tmp/MASTERR_NzHmu10213/sac/testsuite/optimizations/constantfolding/SCCFprf_modarray2:
base : > /bin/sh: ./SCCFprf_modarray2: No such file or directory
/tmp/MASTERR_NzHmu10213/sac/testsuite/unibench/ubgraphtestcase/exportdata:
actual: < /bin/sh: ./exportdata: not found
This does not break on my X86 GCC system, with either production or
development compilers.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1292AINL changes mark main() and other user-defined fns as "inline"2017-11-19T20:36:09ZRobert BerneckyAINL changes mark main() and other user-defined fns as "inline"| | |
| --- | --- |
| Bugzilla Link | [1174](http://bugs.sac-home.org/show_bug.cgi?id=1174) |
| Created on | Nov 23, 2015 21:13 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Recent changes to A...| | |
| --- | --- |
| Bugzilla Link | [1174](http://bugs.sac-home.org/show_bug.cgi?id=1174) |
| Created on | Nov 23, 2015 21:13 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Recent changes to AINL result in over-exuberant inlining directives
being inserted for user-defined functions.
E.g.:
sac2c SCSprf_reshape.sac -v1 -bopt:cyc:ainl:1 >crud.ainl1
sac@rattler:~/sac/testsuite/optimizations/constantfolding$ vi crud.ainl1
sac@rattler:~/sac/testsuite/optimizations/constantfolding$
sac@rattler:~/sac/testsuite/optimizations/constantfolding$ sac2c SCSprf_reshape.sac -v1 -bopt:cyc:cse:1 >crud.cse1
sac@rattler:~/sac/testsuite/optimizations/constantfolding$ vi crud.cse1
sac@rattler:~/sac/testsuite/optimizations/constantfolding$ diff crud.cse1 crud.ainl1
1325a1326
> inline
5289a5291
> inline
The new inline directives are for main() and id(), neither of which
should be inlined.
sac2c -V
sac2c 1.2.beta-BlackForest-89-fd249
developer
(Mon Nov 23 11:48:14 EST 2015 by sac)
The above resulted in 91 grep failures for the CF unit test suite, far more
than we should see there.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1293rc cases descriptor to be freed2017-11-19T20:36:15ZCarl Joslinrc cases descriptor to be freed| | |
| --- | --- |
| Bugzilla Link | [582](http://bugs.sac-home.org/show_bug.cgi?id=582) |
| Created on | Oct 29, 2009 11:37 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug582.sac](/uploads/0005ad76e...| | |
| --- | --- |
| Bugzilla Link | [582](http://bugs.sac-home.org/show_bug.cgi?id=582) |
| Created on | Oct 29, 2009 11:37 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug582.sac](/uploads/0005ad76eed54073a7bb73ad1b58e33f/bug582.sac), [bunzip2.sac](/uploads/9420e3b3a08d5a598c1963d09b9e7e43/bunzip2.sac) |
## Extended Description
<pre>The attached code produces the function:
SACf__MAIN__decode__i_488__i
this function passes a pointer to an uninitialised descriptor and array to the function:
SACf__MAIN__get_bits__i_488__i__i
for use as the return value.
SACf__MAIN__get_bits__i_488__i__i seems to create the needed descriptor and array and passes them to:
SACf__MAIN__compare__i_X__i_6
The first time it does this every thing seems fine the rc goes up and back down however when it calls:
SACf__MAIN__compare__i_X__i_6
the second time it just goes down and not up.
As a result the descripter is freeded and there for not returned by:
SACf__MAIN__get_bits__i_488__i__i
and then when SACf__MAIN__decode__i_488__i uses the memory the program segfalts.</pre>Carl JoslinCarl Joslinhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1294default required in genarray2017-11-19T20:36:20ZCarl Joslindefault required in genarray| | |
| --- | --- |
| Bugzilla Link | [755](http://bugs.sac-home.org/show_bug.cgi?id=755) |
| Created on | Oct 01, 2010 15:43 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
A default element is neede...| | |
| --- | --- |
| Bugzilla Link | [755](http://bugs.sac-home.org/show_bug.cgi?id=755) |
| Created on | Oct 01, 2010 15:43 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
A default element is needed in the genarray of non aks with loops. This requirement does not exist for the c99 backend.Carl JoslinCarl Joslinhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1299Optimization phase pessimizes2017-11-19T20:36:37ZRobert BerneckyOptimization phase pessimizes| | |
| --- | --- |
| Bugzilla Link | [482](http://bugs.sac-home.org/show_bug.cgi?id=482) |
| Created on | Apr 17, 2009 17:51 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>prd.sac is a sim...| | |
| --- | --- |
| Bugzilla Link | [482](http://bugs.sac-home.org/show_bug.cgi?id=482) |
| Created on | Apr 17, 2009 17:51 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>prd.sac is a simple benchmark that essentially does +/⍳n.
If I compile sac/apex/prd.sac with -dowlf, I get this fold-WL
as the inner loop in main():
_pinl_773__z = with {
([ 0 ] <= _pinl_769__iv=[_pinl_774___eat_64] < [ 10000000 ])
{
_pinl_775___ea_466_z = _accu_( _pinl_769__iv);
_al_1542 = _sub_SxS_( _pinl_775___ea_466_z, _pinl_774___eat_64);
_al_1543 = _add_SxS_( 9999999, _al_1542);
} : _al_1543 ;
} :
fold( _MAIN::plusIII, _isaa_1569__rso_56_TheWorld);
But, if I compile it with -nowlf -doswlf, I get this:
_pinl_773__z = with {
([ 0 ] <= _pinl_769__iv=[_pinl_774___eat_64] < [ 10000000 ])
{
_pinl_775___ea_466_z = _accu_( _pinl_769__iv);
_pinl_784_____flat_69 = _add_SxS_( _pinl_775___ea_466_z, _pinl_774___eat_64);
} : _pinl_784_____flat_69 ;
} :
fold( _MAIN::plusIII, _isaa_1556__rso_56_TheWorld);
Note that the first example has an _sub_SxS_ in it?
I have not had time to look into where it's being introduced,
except that it's in b11:cyc.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1300WLSIMP broken2017-11-19T20:36:42ZRobert BerneckyWLSIMP broken| | |
| --- | --- |
| Bugzilla Link | [492](http://bugs.sac-home.org/show_bug.cgi?id=492) |
| Created on | May 15, 2009 20:17 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [emptygeneratorModarray.sac](/u...| | |
| --- | --- |
| Bugzilla Link | [492](http://bugs.sac-home.org/show_bug.cgi?id=492) |
| Created on | May 15, 2009 20:17 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [emptygeneratorModarray.sac](/uploads/4791896cf6760fe2941d5a28666877a4/emptygeneratorModarray.sac), [emptygeneratorFold.sac](/uploads/7f9faf2e59228edb9ea413088ab8b665/emptygeneratorFold.sac) |
## Extended Description
<pre>WLSIMP claims to remove/replace at least one class of degenerate WLs.
Specifically, ones generated by this sort of code:
use Array: {genarray,<=,-,+,iota,sel};
int[*] id(int[*] y)
{ return(y);
}
int main()
{
x = id(genarray([10,10],4));
z = with {
(. <= iv <= .) : x[iv] + iota(3);
} : genarray(_shape_A_(x), [1,2, 3]);
return(z[0,0,0]-4);
}
----------------------------------------------
sac2c nested.sac -b11:ivext -nowlur
Produces the following. Note the flat_10 WL bounds:
([ 0, 0 ] <= iv=[_eat_18, _eat_17] < [ _cf_548_x, _cf_547_x ] genwidth [ _cf_548_x, _cf_547_x ])
{
_pinl_227__flat_95 = _sel_VxA_( iv, x);
_flat_10 = with {
([:int] <= _pinl_225_iv < [:int])
{
/* empty */
} : _pinl_227__flat_95 ;
} :
genarray( [:int], _pinl_224__flat_92);
_pinl_237_res = with {
([ 0 ] <= _pinl_234_iv=[_pinl_238__eat_19] < [ 3 ] genwidth [ 3 ])
{
_pinl_236__flat_1072 = _add_SxS_( _flat_10, _pinl_238__eat_19);
} : _pinl_236__flat_1072 ;
} :
genarray( [ 3 ], _pinl_233__flat_1067);
} : _pinl_237_res ;
} :
genarray( [ _cf_548_x, _cf_547_x ], _flat_4);
-------------------------------
It looked to me that WLSIMPwith has a backwards conditional
for this check, but there's more to it than than, because inverting
the test produces poorly flavored goulash.
Not sure how bad these are affecting performance #s.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1301EWLF can lose AVIS_SHAPE/DIM information in N_ap invocation2017-11-19T20:36:49ZRobert BerneckyEWLF can lose AVIS_SHAPE/DIM information in N_ap invocation| | |
| --- | --- |
| Bugzilla Link | [514](http://bugs.sac-home.org/show_bug.cgi?id=514) |
| Created on | Jun 23, 2009 22:02 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug514.breaks.sac](/uploads/a0...| | |
| --- | --- |
| Bugzilla Link | [514](http://bugs.sac-home.org/show_bug.cgi?id=514) |
| Created on | Jun 23, 2009 22:02 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug514.breaks.sac](/uploads/a01bc6855aeac1c5be0008037256a58a/bug514.breaks.sac), [crud3.sac](/uploads/c1baeae82c3769f27f33321906a9e38f/crud3.sac) |
## Extended Description
<pre>Created an attachment (id=543)
Source code to reproduce fault
If I compile the attached with: sac2c -nowlf -extrema -doswlf,
ive_split_selections complains because it does not have
AVIS_SHAPE/DIM information for Loop_4 argument x.
The calling environment DOES have that information, so something
in saacyc and EWLF is doing bad stuff.
This is noticable inasmuch as it causes your basic factor-of-50
slowdown in the binary search code used in APEX set membership,
indexof, and elsewhere.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1302Code slowdown depending on where scalar comes from2017-11-19T20:37:00ZRobert BerneckyCode slowdown depending on where scalar comes from| | |
| --- | --- |
| Bugzilla Link | [522](http://bugs.sac-home.org/show_bug.cgi?id=522) |
| Created on | Jul 08, 2009 16:53 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [slow2.breaks.sac](/uploads/f38...| | |
| --- | --- |
| Bugzilla Link | [522](http://bugs.sac-home.org/show_bug.cgi?id=522) |
| Created on | Jul 08, 2009 16:53 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [slow2.breaks.sac](/uploads/f38ee1bee9c044bb767c95d69c70e0d9/slow2.breaks.sac), [iotaonly4.sac](/uploads/16e3842a7592d98a1f60bff4449cbd7d/iotaonly4.sac), [crud.breaks.sac](/uploads/61f4b374c6c3433f7d2dcf91adfa61b0/crud.breaks.sac), [iotaonly4.fast.O3.c](/uploads/2aa1529941780c95d3e4a8f7e5f3c242/iotaonly4.fast.O3.c), [iotaonly4.slow.O3.c](/uploads/55d9c175ae8ab695f5e1a96e0c157b05/iotaonly4.slow.O3.c), [iotaonly8.sac](/uploads/f5d701be0d4ed5775ce7e0e27a41a5b5/iotaonly8.sac), [iotaonly8.slow.b11](/uploads/f3d6b0ca3d2a08a09e6ad35b23d8f10d/iotaonly8.slow.b11), [iotaonly8.fast.b11](/uploads/a84616ed216c1cecd72f38c7b08ad150/iotaonly8.fast.b11), [iotaonly9.sac](/uploads/0506eb9821afebe8d3f201dd80175eef/iotaonly9.sac) |
## Extended Description
<pre>Created an attachment (id=550)
Shorter source code to reproduce fault
The attached code presents, I think, two problems:
The code performs +/⍳n; i.e., sum the first n integers.
1. If n comes from an id() function, both codes perform alike
when compiled with:
-O3
and
-O3 -nowlf -doswlf -extrema
2. If n comes from reading the command line, the code compiled with -O3
performs about 15% faster than the SWLF code.
Eyeballing the -b11 output did not give me any hints as to a difference
in generated code, EXCEPT that the WLF code contains TWO WLs, but
the SWLF code contains only one WL, it having folded the two WLs together.
Also, the second WL in the WLF-generated code has an RC(xxx) in its
WITHOP genarray clause. What does this RC field mean? Could that be
relevant?
I saw this problem before, but don't see any bugzilla entry for it.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1303ArrayFormat dies dismally on double data2017-11-19T20:37:04ZRobert BerneckyArrayFormat dies dismally on double data| | |
| --- | --- |
| Bugzilla Link | [555](http://bugs.sac-home.org/show_bug.cgi?id=555) |
| Created on | Aug 14, 2009 22:49 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bugformat.sac](/uploads/e1277f...| | |
| --- | --- |
| Bugzilla Link | [555](http://bugs.sac-home.org/show_bug.cgi?id=555) |
| Created on | Aug 14, 2009 22:49 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bugformat.sac](/uploads/e1277f223ffe2eb57565bd227950cd86/bugformat.sac) |
## Extended Description
<pre>sac2c Build #16335
int main()
{
v = [ 9.884995e+06, 1.031330e+14, 9.885003e+06, 1.082900e+14 ];
StdIO::print(v);
StdIO::show(v);
return(0);
}
produces this:
a.out
Dimension: 1
Shape : < 4>
<9.884995e+06 1.031330e+14 9.885003e+06 1.082900e+14 >
*** SAC runtime error
*** line 152
*** argument #1 of "_sel_VxA_" should be legal index into argument #2;
*** types found: int[1]{1} and char[1]
Clearly, double vector formatting code needs work.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1305Failed to make by adding long type in Templates.mac2017-11-19T20:37:16ZSalem ReyenFailed to make by adding long type in Templates.mac| | |
| --- | --- |
| Bugzilla Link | [739](http://bugs.sac-home.org/show_bug.cgi?id=739) |
| Created on | Aug 18, 2010 10:01 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [Templates.mac](/uploads/7ebdd4...| | |
| --- | --- |
| Bugzilla Link | [739](http://bugs.sac-home.org/show_bug.cgi?id=739) |
| Created on | Aug 18, 2010 10:01 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [Templates.mac](/uploads/7ebdd47fc52790511eb4c46abcc32d8b/Templates.mac), [ArrayBasics.sacbugreport](/uploads/ce56eab2c8558074b48e0393e0bbedf6/ArrayBasics.sacbugreport) |
## Extended Description
<pre>Since I need the long type for stdlib, I add the long types you really need to the list in the CPP else case in /modules/structures/Templates.mac.
linux@linux-desktop:~/sac2c-1.00-beta-linux-x86_64/stdlib$ make mtfast
make -f buildfile "MTSAC2CFLAGS=-mt" MODE=lean
Module SDLisplay cannot be built because libSDL was not found
Module Gnuplot cannot be built because gnuplot was not found
Module Dislin cannot be built because DISLIN was not found
Module PNG cannot be built because libpng was not found
cd modules/structures/lib/..; sac2c -v0 -O3 -linksetsize 0 -mt ArrayBasics.sac -o lib
OOOOOOOPS, your program crashed the compiler 8-((
Please, send a bug report to bugs@sac-home.org,
or file a bug in the SaC-Zilla bug management system.
For your convenience, the compiler has pre-fabricated a bug report
in the file "./ArrayBasics.sacbugreport" !
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 type
mail bugs@sac-home.org < ArrayBasics.sacbugreport
If you decide to file a bug in SaC-Zilla, please go to
http://bugs.sac-home.org/.
When filing a bug report, please copy/paste the initial comment section of
the bug report into the plain text comment section of SaC-Zilla, and add
the whole bug report file as an attachment.
Aborted
make[1]: *** [modules/structures/lib/libArrayBasicsTree.so] Error 134
make: *** [mtfast] Error 2</pre>Santanu Kumar DashSantanu Kumar Dashhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1307Adding a WL speeds up loopfsAKD.sac2017-11-19T20:37:23ZRobert BerneckyAdding a WL speeds up loopfsAKD.sac| | |
| --- | --- |
| Bugzilla Link | [495](http://bugs.sac-home.org/show_bug.cgi?id=495) |
| Created on | May 17, 2009 19:52 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/07908461968...| | |
| --- | --- |
| Bugzilla Link | [495](http://bugs.sac-home.org/show_bug.cgi?id=495) |
| Created on | May 17, 2009 19:52 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/0790846196816b4884be9fe6912d9d18/crud.sac) |
## Extended Description
<pre>Created an attachment (id=522)
Source code to reproduce fault
The attached code has the interesting property that it runs faster if you
introduce an extra WL into the mix, via #define CRUD.
The resulting code is NOT folded by WLF, so there is an extra WL at the end of phase 11.
However, the resulting code executes about 5% FASTER than if you remove the
extra WL. Very puzzling.
I'm guessing some strangeness in the back end, because eyeballing the code
did not turn up any other differences that I could see.
Perhaps some backendian type can look at this?
PAPI output:
without extra loop:
crud.sac.exe.O3.papiex.rattler.6186:PAPI_TOT_INS: 105104480
with extra loop:
crud.sac.exe.O3.papiex.rattler.6353:PAPI_TOT_INS: 100104533</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1308UTCompress crashes in WLBnodeOrIntGetNameOrVal2017-11-19T20:37:28ZRobert BerneckyUTCompress crashes in WLBnodeOrIntGetNameOrVal| | |
| --- | --- |
| Bugzilla Link | [552](http://bugs.sac-home.org/show_bug.cgi?id=552) |
| Created on | Aug 13, 2009 23:20 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTCompress.sac](/uploads/a77c7...| | |
| --- | --- |
| Bugzilla Link | [552](http://bugs.sac-home.org/show_bug.cgi?id=552) |
| Created on | Aug 13, 2009 23:20 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [UTCompress.sac](/uploads/a77c7b0b6d1b98f808a67d5948b7a79f/UTCompress.sac) |
## Extended Description
<pre>Created an attachment (id=557)
Source code to cause crash
If compiled this way:
sac2c v1.00-beta (Buchette d'Anjou)
developer rev 16326 linux-gnu_x86_64
(Thu Aug 13 16:01:15 EDT 2009 by sac)
apex@rattler:~/apex2003/benchmks/UTCompress$ sac2c -extrema -nowlf -doswlf -v3 UTCompress.sac
the attached sac program dies generating intermediate code macros
inside WLBnodeOrIntGetNameOrVal.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1310WLPG introduces default partition in phase 10 even when full generators are p...2017-11-19T20:37:36ZRobert BerneckyWLPG introduces default partition in phase 10 even when full generators are present| | |
| --- | --- |
| Bugzilla Link | [680](http://bugs.sac-home.org/show_bug.cgi?id=680) |
| Created on | Feb 15, 2010 20:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug676.sac](/uploads/6f3be6c54a2386...| | |
| --- | --- |
| Bugzilla Link | [680](http://bugs.sac-home.org/show_bug.cgi?id=680) |
| Created on | Feb 15, 2010 20:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug676.sac](/uploads/6f3be6c54a2386e2031527034f5f354a/bug676.sac) |
## Extended Description
<pre>Created an attachment (id=673)
source code to reproduce fault
And here's why, taken from the IL generated for Array::iota( int[.] shp):
sac2c -v0 -nowlf -doawlf -extrema -ecc bug676.sac -b10:cse >crud
_flat_10 = 0;
_flat_9 = _mul_SxV_( _flat_10, shp);
res = with {
(_flat_9 <= iv < shp)
{
/* empty */
} : iv ; ,
default partition( iv ):
{
/* empty */
} : _flat_9 ;
} :
genarray( shp, _flat_9);
shp is an int[.] until it gets inlined, so CF can't resolve the shape
of _flat_9. Extrema won't help here, for the same reason. By the
time that inlining has happened, the damage has been done by WLPG.
Array::iota(int shp) has a different problem: if compiled with -ecc,
TULSisFullGenerator fails to see the [0] lower bound, because it does not
look past the guards created by -ecc.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1311LS does not support SAA; LACFUN headers result are missing AVIS_SHAPE2017-11-19T20:37:41ZRobert BerneckyLS does not support SAA; LACFUN headers result are missing AVIS_SHAPE| | |
| --- | --- |
| Bugzilla Link | [700](http://bugs.sac-home.org/show_bug.cgi?id=700) |
| Created on | Apr 21, 2010 22:37 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbbAKD.sac](/uploads/13bd5800f1162...| | |
| --- | --- |
| Bugzilla Link | [700](http://bugs.sac-home.org/show_bug.cgi?id=700) |
| Created on | Apr 21, 2010 22:37 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbbAKD.sac](/uploads/13bd5800f116238f77dabc85fff1d815/ipbbAKD.sac) |
## Extended Description
<pre>Created an attachment (id=688)
source code to reproduce fault
In the ongoing battle to kill CYC, we need to extend LS to make it
support SAA. When it moves a value from within a LACFUN to outside it,
it fails to move the AVIS_SHAPE/DIM information for that.
This results in unpleasant failure modes, such as VPid dying.
The attached will fail if compiled with rbe's local sac2c
(the post-Loch Ness fixerupper that is not checked in yet), with these options:
sac2c -ecc -extrema -doawlf -nowlf ipbbAKD.sac
This is partly a place marker so that we remember to do this work.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1313CSE crash in tjck.sac2017-11-19T20:37:51ZRobert BerneckyCSE crash in tjck.sac| | |
| --- | --- |
| Bugzilla Link | [992](http://bugs.sac-home.org/show_bug.cgi?id=992) |
| Created on | Jul 07, 2012 23:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/394041f63aa86da3...| | |
| --- | --- |
| Bugzilla Link | [992](http://bugs.sac-home.org/show_bug.cgi?id=992) |
| Created on | Jul 07, 2012 23:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/394041f63aa86da3a3211fbf60bd399d/crud.sac) |
## Extended Description
<pre>We crash in CSE during SAACYC, with Build #18045:
cd sac/apex/tjck
svn update .
sac2c tjck.sac -doawlf -nowlf -v4
****** Optimizing regular function:
****** _MAIN::slBII( bool[3], int[.,.]): ...
Inserting symbolic array attributes ...
Eliminating index vectors (split selections) ...
Eliminating common subexpressions ...
OOOOOOOPS, your program crashed the compiler 8-((
I have not looked into this, other than to compile it
with no options; that compiles OK.</pre>Clemens GrelckClemens Grelckhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1315matmul Star algorithm crashes in Phase 152017-11-19T20:38:02ZRobert Berneckymatmul Star algorithm crashes in Phase 15| | |
| --- | --- |
| Bugzilla Link | [1107](http://bugs.sac-home.org/show_bug.cgi?id=1107) |
| Created on | Jan 08, 2014 22:31 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug1107redux.sac](/uploads/2a6ec2...| | |
| --- | --- |
| Bugzilla Link | [1107](http://bugs.sac-home.org/show_bug.cgi?id=1107) |
| Created on | Jan 08, 2014 22:31 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug1107redux.sac](/uploads/2a6ec20a4d3bc38eaea46df67cb97377/bug1107redux.sac), [1107.sac](/uploads/f5e9844406d5bd29da67e5d29eebdbf8/1107.sac) |
## Extended Description
<pre>sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18415 linux-gnu_x86_64
(Wed Jan 8 09:37:41 EST 2014 by sac)
cat bugrc.sac
use Array:all;
inline double[+] plusdotmpyDDDStar(double[+]x, double[+]y)
{ /* CDC STAR-100 APL Algorithm for inner product */
rowsx = drop([-1],shape(x));
colsx = shape(x)[[dim(x)-1]];
colsy = shape(y)[[dim(y)-1]];
Zrow = genarray([colsy],0.0d);
/* Parallel over rows of x */
z = with {
(. <= [row] <= .) {
Crow = with {
( [0] <= col < [colsy]) {
newrow = x[row] * y[col];
StdIO::show(newrow);
} : newrow;
} : fold( +, Zrow);
StdIO::show(Crow);
} : Crow;
}: genarray( rowsx, Zrow);
return(z);
}
int main()
{
siz = 5;
x = reshape( [siz,siz], 0.50* tod(iota(siz*siz)));
y = reshape( [siz,siz], 0.75* tod(iota(siz*siz)));
A_31=plusdotmpyDDDStar(x, y);
r = sum( A_31);
StdIO::print( r);
r = ( r== 732904294933574912.000000) ? 0 : 1;
return(r);
}
sac2c bugrc.sac -v1
**** Optimizing reference counting instructions ...
TRAVERSE ERROR: node of type 31:N_id found where 32:N_num was expected!
Compiling with -maxwlur 1 makes this crash not happen.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://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/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/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/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/2174Livermore Loop 13 SAC vs. C code not equivalent2017-11-19T22:04:41ZRobert BerneckyLivermore Loop 13 SAC vs. C code not equivalent| | |
| --- | --- |
| Bugzilla Link | [708](http://bugs.sac-home.org/show_bug.cgi?id=708) |
| Created on | May 11, 2010 19:19 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The repositor...| | |
| --- | --- |
| Bugzilla Link | [708](http://bugs.sac-home.org/show_bug.cgi?id=708) |
| Created on | May 11, 2010 19:19 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The repository copy of SAC Loop 13 code reads its input from a file;
the C version has the input hard-coded into the source program.
The entire SAC benchmark executes in about 36msec, and the C
version in 7msec.
One of the benchmarks should be changed, so that they are equivalent.
Until that time, any performance measurements on Loop13 should be considered
bogus.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2187stdlib won't compile with the SUN compiler2017-11-19T22:05:51ZRoeland Doumastdlib won't compile with the SUN compiler| | |
| --- | --- |
| Bugzilla Link | [816](http://bugs.sac-home.org/show_bug.cgi?id=816) |
| Created on | Jan 07, 2011 12:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
This is a tracker bug to a...| | |
| --- | --- |
| Bugzilla Link | [816](http://bugs.sac-home.org/show_bug.cgi?id=816) |
| Created on | Jan 07, 2011 12:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
This is a tracker bug to allow compilation of the stdlib with suncc.Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2189compiler crashed - WLF bug when folding across different frame-shapes2017-11-23T23:23:19ZNilesh Karavadaracompiler crashed - WLF bug when folding across different frame-shapes| | |
| --- | --- |
| Bugzilla Link | [820](http://bugs.sac-home.org/show_bug.cgi?id=820) |
| Created on | Jan 25, 2011 09:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [slice.sacbugreport](/uploads/324848...| | |
| --- | --- |
| Bugzilla Link | [820](http://bugs.sac-home.org/show_bug.cgi?id=820) |
| Created on | Jan 25, 2011 09:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [slice.sacbugreport](/uploads/3248489b063509ead2c7838faf3ac4ea/slice.sacbugreport), [bug820.sac](/uploads/60bf77a4d8f8a49dacff819415632f22/bug820.sac) |
## Extended Description
<pre>Created an attachment (id=792)
Bug Report
/**********************************************************************
*
* SAC bug report: slice.sacbugreport
*
**********************************************************************
*
* Automatically generated on Tue Jan 25 09:19:38 GMT 2011
*
* using sac2c v1.00-beta (Haggis And Apple) rev 17286 for linux-gnu_i686
* built Mon Jan 24 17:32:53 GMT 2011.
* by user nkk on host obelix for linux-gnu.
*
* The compiler was called by
* sac2c -o slice slice.sac
*
* The compiler crashed in
* phase: opt (Running SAC optimizations)
* sub phase: cyc (Optimization cycle)
* cycle phase: wlf (Applying with-loop folding)
* cycle instance: 1
*
* What follows is the contents of slice.sac.
*
**********************************************************************/</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2202ArrayFormat show() fails on double scalar/vector (at least)2017-11-23T23:24:29ZRobert BerneckyArrayFormat show() fails on double scalar/vector (at least)| | |
| --- | --- |
| Bugzilla Link | [936](http://bugs.sac-home.org/show_bug.cgi?id=936) |
| Created on | Mar 19, 2012 21:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Array formatting fail...| | |
| --- | --- |
| Bugzilla Link | [936](http://bugs.sac-home.org/show_bug.cgi?id=936) |
| Created on | Mar 19, 2012 21:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Array formatting fails to print double scalars and vectors correctly,
in both show() and format() flavors. This is a long-standing bug.
This function: cat crud.sac
use Array: all;
use StdIO : all;
use ArrayFormat: all;
int main()
{
print(format(42.5));
show( 42.5);
print( 42.5);
show( [42.5]);
return(0);
}
produces this output:
a.out
Dimension: 1
Shape : < 22>
< >
Dimension: 0
Shape : < >
42.5
4
Not even close.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2208gaussFilter delivers only values of 2552017-11-23T23:24:59ZVolkmar WiesergaussFilter delivers only values of 255| | |
| --- | --- |
| Bugzilla Link | [1105](http://bugs.sac-home.org/show_bug.cgi?id=1105) |
| Created on | Dec 10, 2013 13:57 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I've tried ...| | |
| --- | --- |
| Bugzilla Link | [1105](http://bugs.sac-home.org/show_bug.cgi?id=1105) |
| Created on | Dec 10, 2013 13:57 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I've tried to execute the gaussFilter example in sac/tutorial/L7_case_study_image-filter. I am using the compiler from the repository and I compiled the program as follows:
sac2c -DSOBEL -DSIMPLECLOCK -DRAWIMAGE image_filter.sac -o image_filter
and execution
./image_filter -c 2 -i ./testimages/sail.fibre -o ./outimage
After execution the outimage only contains values of 255</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2209Demo 'sac_from_c' does not compile2018-11-23T14:46:58ZHans-Nikolai ViessmannDemo 'sac_from_c' does not compile| | |
| --- | --- |
| Bugzilla Link | [1143](http://bugs.sac-home.org/show_bug.cgi?id=1143) |
| Created on | Nov 20, 2014 16:53 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>## System D...| | |
| --- | --- |
| Bugzilla Link | [1143](http://bugs.sac-home.org/show_bug.cgi?id=1143) |
| Created on | Nov 20, 2014 16:53 |
| Version | unspecified |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>## System Details ##
uname -a - Linux 2.6.32-431.20.3.el6.x86_64
#1 SMP Thu Jun 19 14:01:59 CDT 2014 x86_64 GNU/Linux
distro - Scientific (RedHat) Linux 6.5
## SAC Details ##
revision - 18508 devel
stdlib - compiled as 'MODE=lean make mt'
## Problem ##
Tried to compile the 'sac_from_c' demo application (sac/demos/basics/sac_from_c).
Both the sac2c and sac4c processes completed without error. An error was given
when compiling the C program which links to the SAC C-lib.
## Additional ##
I had to edit the Makefile somewhat due to errors regarding the private heap
manager. The relevant line that I changed is 11; it now reads as:
$(CC) -o $* $*.c `sac4c -nophm Sum -ccflags` `sac4c -nophm Sum -ldflags` -pthread
## Error Message ##
gcc -o summarizer summarizer.c `sac4c -nophm Sum -ccflags` `sac4c -nophm Sum -ldflags` -pthread
./libcwrapper.so: undefined reference to `SACARGcopyDataInternal'
./libcwrapper.so: undefined reference to `SACARGfreeDataInternal'
collect2: error: ld returned 1 exit status
## Steps to Reproduce ##
1. cd sac/demos/basics/sac_from_c/
2. make
## Workaround (why?) ##
I wrapped the Structures::sum function in another function, 'mysum':
module Sum;
import Structures : {sum};
export {mysum};
int[] mysum(int[*] vector)
{
a = sum(vector);
return(a);
}
and changed the relevant line in summarizer.c. Doing this there are no errors
reported and the resulting binary runs.
## Extra ##
The output of 'nm -a libcwrapper.so':
0000000000202398 b .bss
0000000000000000 n .comment
00000000002020c0 d .ctors
0000000000202390 d .data
00000000002020d0 d .dtors
00000000002020e8 d .dynamic
00000000000006e0 r .dynstr
00000000000002a8 r .dynsym
0000000000001fe0 r .eh_frame
0000000000001fa0 r .eh_frame_hdr
0000000000001e58 t .fini
0000000000000a64 r .gnu.version
0000000000000ac0 r .gnu.version_r
0000000000202268 d .got
0000000000202298 d .got.plt
0000000000000158 r .hash
0000000000000e28 t .init
00000000002020e0 d .jcr
0000000000000e40 t .plt
0000000000000ae0 r .rela.dyn
0000000000000b88 r .rela.plt
0000000000001e70 r .rodata
0000000000001010 t .text
U SACARGcopyDataInternal
0000000000001d44 T SACARGcopyDataUdt
U SACARGfreeDataInternal
0000000000001dbc T SACARGfreeDataUdt
U SACARGisDouble
U SACARGisFloat
U SACARGisInt
U SACARGisUdt
U SACARGunwrapDouble
U SACARGunwrapFloat
U SACARGunwrapInt
U SACARGunwrapUdtDouble
U SACARGwrapDouble
U SACARGwrapFloat
U SACARGwrapInt
U SACARGwrapUdtDouble
U SAC_HM_MallocAnyChunk_at
U SAC_HM_MallocAnyChunk_mt
U SAC_HM_MallocAnyChunk_st
0000000000001f20 r SAC_HM_thread_status.2426
U SAC_MT_globally_single
U SAC_RuntimeError
U SAC_RuntimeError_Mult
00000000002023a8 B SAC___CWRAPPER__another_dummy_value_which_is_completely_useless
00000000002023ac B SAC___CWRAPPER__dummy_value_which_is_completely_useless
0000000000001158 T SACcw_Sum__sum1
U SACf_ArrayTransform__sum__d_S
U SACf_ArrayTransform__sum__f_S
U SACf_ArrayTransform__sum__i_S
U SACf_ComplexArrayTransform__sum__SACt_ComplexArrayTransform__complex_S
0000000000001cfd T Sum__sum1
00000000002020e8 a _DYNAMIC
0000000000202298 a _GLOBAL_OFFSET_TABLE_
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
w _Jv_RegisterClasses
00000000002020c8 d __CTOR_END__
00000000002020c0 d __CTOR_LIST__
00000000002020d8 d __DTOR_END__
00000000002020d0 d __DTOR_LIST__
00000000000020b8 r __FRAME_END__
00000000002020e0 d __JCR_END__
00000000002020e0 d __JCR_LIST__
0000000000001f10 r __PRETTY_FUNCTION__.2498
0000000000001f3a r __PRETTY_FUNCTION__.2631
0000000000202398 d __TMC_END__
U __assert_fail@@GLIBC_2.2.5
0000000000202398 A __bss_start
w __cxa_finalize@@GLIBC_2.2.5
0000000000001e20 t __do_global_ctors_aux
00000000000010a0 t __do_global_dtors_aux
0000000000202390 d __dso_handle
w __gmon_start__
0000000000202398 A _edata
00000000002023b0 A _end
0000000000001e58 T _fini
0000000000000e28 T _init
0000000000001010 t call_gmon_start
0000000000202398 b completed.6301
0000000000000000 a crtstuff.c
0000000000000000 a crtstuff.c
0000000000001030 t deregister_tm_clones
00000000002023a0 b dtor_idx.6303
0000000000001120 t frame_dummy
U free@@GLIBC_2.2.5
0000000000001c8f t freeScalarDesc
0000000000000000 a fun1.c
0000000000000000 a fundummy.c
0000000000000000 a globals.c
0000000000000000 a interface.c
0000000000001c18 t makeScalarDesc
U malloc@@GLIBC_2.2.5
0000000000001060 t register_tm_clones
0000000000000000 a sacargcopy.c
0000000000000000 a sacargfree.c
The output of 'nm -a libsac.seq.so | fgrep SACARGfree':
000000000000d59f T SACARGfree
000000000000d57e t SACARGfreeDataInternal
000000000000d2ea t SACARGfreeDataT_bool
000000000000d11c t SACARGfreeDataT_byte
000000000000d32c t SACARGfreeDataT_char
000000000000d36e t SACARGfreeDataT_classtype
000000000000d3b0 t SACARGfreeDataT_dots
000000000000d2a8 t SACARGfreeDataT_double
000000000000d434 t SACARGfreeDataT_double_dev
000000000000d4fa t SACARGfreeDataT_double_dist
000000000000d497 t SACARGfreeDataT_double_shmem
000000000000d266 t SACARGfreeDataT_float
000000000000d3f2 t SACARGfreeDataT_float_dev
000000000000d4b8 t SACARGfreeDataT_float_dist
000000000000d455 t SACARGfreeDataT_float_shmem
000000000000d287 t SACARGfreeDataT_floatvec
000000000000d34d t SACARGfreeDataT_hidden
000000000000d15e t SACARGfreeDataT_int
000000000000d413 t SACARGfreeDataT_int_dev
000000000000d4d9 t SACARGfreeDataT_int_dist
000000000000d476 t SACARGfreeDataT_int_shmem
000000000000d17f t SACARGfreeDataT_long
000000000000d2c9 t SACARGfreeDataT_longdbl
000000000000d1a0 t SACARGfreeDataT_longlong
000000000000d55d t SACARGfreeDataT_nothing
000000000000d53c t SACARGfreeDataT_rc
000000000000d13d t SACARGfreeDataT_short
000000000000d30b t SACARGfreeDataT_str
000000000000d51b t SACARGfreeDataT_sync
000000000000d1c1 t SACARGfreeDataT_ubyte
000000000000d203 t SACARGfreeDataT_uint
000000000000d224 t SACARGfreeDataT_ulong
000000000000d245 t SACARGfreeDataT_ulonglong
000000000000d0fb t SACARGfreeDataT_unknown
000000000000d3d1 t SACARGfreeDataT_user
000000000000d1e2 t SACARGfreeDataT_ushort
000000000000d38f t SACARGfreeDataT_void
Output of 'nm -a libsac.seq.so | fgrep SACARGcopy':
000000000000e0bc T SACARGcopy
U SACARGcopyDataUdt</pre>Hans-Nikolai ViessmannHans-Nikolai Viessmann