sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:35:36Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1284WLFS acts despite data dependency2017-11-19T20:35:36ZKai TrojahnerWLFS acts despite data dependency| | |
| --- | --- |
| Bugzilla Link | [325](http://bugs.sac-home.org/show_bug.cgi?id=325) |
| Created on | Nov 17, 2006 13:14 |
| Version | 1.00beta |
| OS | All |
| Architecture | Macintosh |
| Attachments | [cgwlfs.sac](/uploads/addc...| | |
| --- | --- |
| Bugzilla Link | [325](http://bugs.sac-home.org/show_bug.cgi?id=325) |
| Created on | Nov 17, 2006 13:14 |
| Version | 1.00beta |
| OS | All |
| Architecture | Macintosh |
| Attachments | [cgwlfs.sac](/uploads/addcad513cf316ab4432346eafdc5369/cgwlfs.sac) |
## Extended Description
<pre>Attached is a condesed example from Sonias work in which WLFusion behaves wrong.
for( i=0; i<25; i++) {
z = z + p;
r = r - a;
beta = sum(r);
p = r + (beta * p);
}
In this code fragment, WLFS fuses the computation of r into the computation of p, rendering the r in sum
(r) a dead reference.</pre>Clemens GrelckClemens Grelckhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1281WLIR bug2017-11-19T20:35:25ZSven-Bodo ScholzWLIR bug| | |
| --- | --- |
| Bugzilla Link | [1186](http://bugs.sac-home.org/show_bug.cgi?id=1186) |
| Created on | Jan 12, 2017 16:22 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>anything loop invaria...| | |
| --- | --- |
| Bugzilla Link | [1186](http://bugs.sac-home.org/show_bug.cgi?id=1186) |
| Created on | Jan 12, 2017 16:22 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>anything loop invariant is being lifted out of partitions, even if the partition potentially is empty!
This does not only potentially generate more work but it can also affect termination:
noinline int forever( int x)
{
if( _eq_SxS_( x,0))
res = forever(x);
else
res = x;
return res;
}
noinline int[.] foo( int n)
{
res = with {
([1] <= iv <[n]) : forever(0);
} : genarray([n], 0);
return res;
}
int main() {
res = foo( 1);
return _sel_VxA_( [0], res);
}
Here the call to forever is lifted out of the WL inhibiting the optimised program to terminate :-(</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/1277WLSIMP elides type relevant generators without adding type_conv2017-11-19T20:35:12ZSven-Bodo ScholzWLSIMP elides type relevant generators without adding type_conv| | |
| --- | --- |
| Bugzilla Link | [1157](http://bugs.sac-home.org/show_bug.cgi?id=1157) |
| Created on | May 05, 2015 20:47 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [bug1157.wlt.sac](/uploads/61dc5a6fc...| | |
| --- | --- |
| Bugzilla Link | [1157](http://bugs.sac-home.org/show_bug.cgi?id=1157) |
| Created on | May 05, 2015 20:47 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [bug1157.wlt.sac](/uploads/61dc5a6fccded735838391d8df36df11/bug1157.wlt.sac), [bug1157.nostdlib.sac](/uploads/5a81c341e182248e58d4d40e9c41e375/bug1157.nostdlib.sac) |
## Extended Description
<pre>This bug is related to 1147.
Consider the following code:
module crud;
export {g};
int[.] g( int[0] a, int[+] b)
{
res = with {
( [0] <= iv < _shape_A_(a)): _sel_VxA_( iv, a);
} : modarray( b);
return res;
}
Despite being empty, the generator conveys the info that res in fact is a vector (int[.]).
Once the empty generator is elided, this info is gone and the type checker complains that it no longer can infer int[.] but reverts to int[+] instead......
Whenever we elide a generator we need to insert a type assertion, i.e.,
rather than replacing the above with
res = with {} : modarry(b);
we need to replace it by
res' = with {} : modarry(b);
res = type_conv( res', int[.]);</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/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/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/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/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/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/1259Stack overflow and segfault in DCRvardec when compiling with -check ctb2017-11-19T20:34:09ZDaniel RollsStack overflow and segfault in DCRvardec when compiling with -check ctb| | |
| --- | --- |
| Bugzilla Link | [613](http://bugs.sac-home.org/show_bug.cgi?id=613) |
| Created on | Dec 06, 2009 01:10 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>sac2c product version 1...| | |
| --- | --- |
| Bugzilla Link | [613](http://bugs.sac-home.org/show_bug.cgi?id=613) |
| Created on | Dec 06, 2009 01:10 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>sac2c product version 16651
From the sac repository compile demos/numerical/tvd/tvd_abstract.sac (version 1171) with the following command:
sac2c-p -O3 -v1 -maxlur 10 -L fluid tvd2d_abstract.sac -check ctb
and it segfaults in DCRvardec (stdopt/deadcoderemoval.c:506).
Run
sac2c-d -O3 -v1 -maxlur 10 -L fluid tvd2d_abstract.sac -check ctb
and stack overflow warnings are produced:
WARNING: dbug-maxdepth 40000 too low
I enabled the automatic tracing in _db_enter_ in dbug.c and saved the output. The file is quite large so I haven't uploaded it. It is here:
obelix:/home/dsr/tvdabstract-autotrace</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1252WRCI can't handle AKD arrays2017-11-19T20:33:44ZRobert BerneckyWRCI can't handle AKD arrays| | |
| --- | --- |
| Bugzilla Link | [1094](http://bugs.sac-home.org/show_bug.cgi?id=1094) |
| Created on | Oct 02, 2013 21:47 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [wrciOffsetAKD.sac](/uploads/8dec6...| | |
| --- | --- |
| Bugzilla Link | [1094](http://bugs.sac-home.org/show_bug.cgi?id=1094) |
| Created on | Oct 02, 2013 21:47 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [wrciOffsetAKD.sac](/uploads/8dec64b73def638b9bcdbcc125567f89/wrciOffsetAKD.sac) |
## Extended Description
<pre>Created an attachment (id=989)
source code to reproduce fault
The wrci unit test suite now includes wrciOffset.sac and wrciOffsetAKD.sac;
these are intended to show array reuse on AKS and AKD arrays, respectively.
WRCI does not support AKD arrays, which really sucks.
Here's an example of AKD code, where a reference with offset (to
another partition) to the reuse candidate array could work, but does
not.
AAA = _reshape_VxA_( id( [ 25, 10]), iota( id( 250)));
gw = shape( AAA) - [ 15, 0]; // AKA [10 10]
AAA = with {
([0,0] <= iv < gw): AAA[iv + [ 10, 0]] + 1000;
} : modarray(AAA);
I intend to move IVEXC after WRCI, and then "should" be able to
extend WRCI/RWO to do the job.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1231UTIndexSet.sac in masterrun2017-11-19T20:32:30ZCarl JoslinUTIndexSet.sac in masterrun| | |
| --- | --- |
| Bugzilla Link | [847](http://bugs.sac-home.org/show_bug.cgi?id=847) |
| Created on | Jun 01, 2011 14:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [847.sac](/uploads/b4d26e97d1dbe52d4...| | |
| --- | --- |
| Bugzilla Link | [847](http://bugs.sac-home.org/show_bug.cgi?id=847) |
| Created on | Jun 01, 2011 14:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [847.sac](/uploads/b4d26e97d1dbe52d4fcd7c17c824b36e/847.sac) |
## Extended Description
UTIndexSet.sac falls over in the masterrun as it tries to read memory where an avis node is expected however the memory at that location is not valid for a node.
I have reduced the bug down, however it is very unperdictable. For example there are 2 dead functions in the reduced version that are needed to trigger the bug.
The bug shows up in variable propergation, so is eather a problem with variable propergation or just before.Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1228how to deal with array constructors and selections2017-11-19T20:32:20ZSven-Bodo Scholzhow to deal with array constructors and selections| | |
| --- | --- |
| Bugzilla Link | [747](http://bugs.sac-home.org/show_bug.cgi?id=747) |
| Created on | Sep 17, 2010 07:43 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>This bug relates to bug...| | |
| --- | --- |
| Bugzilla Link | [747](http://bugs.sac-home.org/show_bug.cgi?id=747) |
| Created on | Sep 17, 2010 07:43 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>This bug relates to bug 746 but is of a more specific nature.
The overall question is:
- when to lift an array constructor out of loops/conditionals
- when to push it in
and
- how to steer that behaviour advantageously
Naively, one might argue that arrays should always be lifted as far as possible.
Unfortunately, that does not hold for index vectors that are used in selections or
modarray operations. There, it is often (not always!) advantageous to propagate them
down as they may avoid a vect2offset.
A thorough analysis of the situation is asked for.....</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1065Crash in Applying Loop Scalarization on tvd2d_abstract2017-11-19T20:20:02ZDaniel RollsCrash in Applying Loop Scalarization on tvd2d_abstract| | |
| --- | --- |
| Bugzilla Link | [677](http://bugs.sac-home.org/show_bug.cgi?id=677) |
| Created on | Feb 05, 2010 17:43 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [tvd2d_abstract.sac](/uploads/5779b9e2...| | |
| --- | --- |
| Bugzilla Link | [677](http://bugs.sac-home.org/show_bug.cgi?id=677) |
| Created on | Feb 05, 2010 17:43 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [tvd2d_abstract.sac](/uploads/5779b9e2a2145c8d08ceaa9960c21d8a/tvd2d_abstract.sac), [fluid.tar.bz2](/uploads/cf720010034eaff2820cbc1d339e3b99/fluid.tar.bz2) |
## Extended Description
<pre>Created an attachment (id=668)
sac source code (large)
developer rev 16752:MODIFIED
Carl's build on Obelix as of 5/2/10.
sac2c tvd2d_abstract.sac -Lfluid -maxoptcyc 2
Crash when Applying Loop Scalarization.
This code is large and I may need to reduce its size before this bug can be investigated.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1038left-over ASSIGN_INDEX error in WLI due to glf being the default2017-11-19T20:18:25ZSven-Bodo Scholzleft-over ASSIGN_INDEX error in WLI due to glf being the default| | |
| --- | --- |
| Bugzilla Link | [505](http://bugs.sac-home.org/show_bug.cgi?id=505) |
| Created on | Jun 05, 2009 17:56 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [BlasLevel1.sac](/uploads/79a74...| | |
| --- | --- |
| Bugzilla Link | [505](http://bugs.sac-home.org/show_bug.cgi?id=505) |
| Created on | Jun 05, 2009 17:56 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [BlasLevel1.sac](/uploads/79a740b30a937c43dcc35a9df1b6f3d4/BlasLevel1.sac) |
## Extended Description
<pre>Created an attachment (id=533)
source code
In several files we see this error popping up. BlasLEvel1 being one of them.
In the attached source code (a compressed version of BlasLevel1, we obtain:
nferring foldable with-loops ...
ASSERTION FAILED: file 'arrayopt/SSAWLI.c', line 677
left-over ASSIGN_INDEX found.
EXECUTION TERMINATED
Abort
in round 5
when calling sac2c BlasLevel1.sac -noprelude -v4
with sac2c -V :
sac2c v1.00-beta (Buchette d'Anjou)
developer rev 16108 linux-gnu_i686
(Fri Jun 5 14:52:38 BST 2009 by sbs)</pre>BugZillaBugZilla