sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T22:01:42Zhttps://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/2184Excluded APEX code2017-11-19T22:05:35ZDaniel RollsExcluded APEX code| | |
| --- | --- |
| Bugzilla Link | [793](http://bugs.sac-home.org/show_bug.cgi?id=793) |
| Created on | Dec 01, 2010 11:46 |
| Version | unspecified |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>I have excluded...| | |
| --- | --- |
| Bugzilla Link | [793](http://bugs.sac-home.org/show_bug.cgi?id=793) |
| Created on | Dec 01, 2010 11:46 |
| Version | unspecified |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>I have excluded the source code from APEX for the failures listed below. I am raising this bug so that these actions are not forgotten. Do what you want with it. My commit log follows.
------------------------------------------------------------------------
r1410 | dsr | 2010-12-01 11:37:04 +0000 (Wed, 01 Dec 2010) | 57 lines
I have excluded the sac files for all these errors from APEX in the
Masterrun. Hopefully now we will be able to clearly see any new problems
that are introduced!
************************************************************
Errors apex (product version):
************************************************************
OOOOOOOPS, your program crashed the compiler 8-((
OOOOOOOPS, your program crashed the compiler 8-((
OOOOOOOPS, your program crashed the compiler 8-((
OOOOOOOPS, your program crashed the compiler 8-((
make[6]: [dtb] Error 87 (ignored)
make[6]: [dtb_mt] Error 87 (ignored)
make[6]: [dtb2] Error 87 (ignored)
make[6]: [dtb2_mt] Error 87 (ignored)
make[6]: *** [mdiv2] Aborted
make[6]: *** [mdiv2_mt] Aborted
make[6]: *** [mdiv2AKD] Aborted
make[6]: *** [mdiv2AKD_mt] Aborted
make[6]: [tomcatv2] Error 87 (ignored)
make[6]: [tomcatv2_mt] Error 87 (ignored)
make[6]: [UTClock] Error 51 (ignored)
make[6]: [UTClock_mt] Error 51 (ignored)
make[6]: [UTReverse] Error 87 (ignored)
make[6]: [UTReverse_mt] Error 87 (ignored)
make[6]: [UTRotate234] Error 87 (ignored)
make[6]: [UTRotate234_mt] Error 87 (ignored)
************************************************************
Warnings apex (product version):
************************************************************
.nmo.d:
-- OTHER WARNINGS FOUND
nmo.sac:
-- OTHER WARNINGS FOUND
nmo.sac:
-- OTHER WARNINGS FOUND
.tomcatv.d:
-- OTHER WARNINGS FOUND
tomcatv.sac:
-- OTHER WARNINGS FOUND
tomcatv.sac:
-- OTHER WARNINGS FOUND
.tomcatv2.d:
-- OTHER WARNINGS FOUND
tomcatv2.sac:
-- OTHER WARNINGS FOUND
tomcatv2.sac:
-- OTHER WARNINGS FOUND
.UTTranspose.d:
-- OTHER WARNINGS FOUND
UTTranspose.sac:
-- OTHER WARNINGS FOUND
UTTranspose.sac:
-- OTHER WARNINGS FOUND</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1088Undeclared variable in SACf_aud_propagate__prop_only__i_S2017-11-19T20:21:27ZDaniel RollsUndeclared variable in SACf_aud_propagate__prop_only__i_S| | |
| --- | --- |
| Bugzilla Link | [792](http://bugs.sac-home.org/show_bug.cgi?id=792) |
| Created on | Dec 01, 2010 11:27 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>sac2c: 17213
From the t...| | |
| --- | --- |
| Bugzilla Link | [792](http://bugs.sac-home.org/show_bug.cgi?id=792) |
| Created on | Dec 01, 2010 11:27 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>sac2c: 17213
From the testuite go to ./objects/withloops and run
sac2c -O3 -check tb -v0 -mt -o . aud_propagate.sac
This is the error
fun1.c: In function ‘SACf_aud_propagate__prop_only__i_S’:
fun1.c:561: error: ‘SACl_out__p’ undeclared (first use in this function)
fun1.c:561: error: (Each undeclared identifier is reported only once
fun1.c:561: error: for each function it appears in.)
fun1.c: In function ‘SACf_aud_propagate__fold_prop__i_S’:
fun1.c:988: error: ‘SACl_out__p’ undeclared (first use in this function)
fun1.c: In function ‘SACf_aud_propagate_CL_ST__fold_prop__i_S’:
fun1.c:1532: error: ‘SACl_out__p’ undeclared (first use in this function)
fun1.c: In function ‘SACf_aud_propagate_CL_ST__prop_only__i_S’:
fun1.c:1954: error: ‘SACl_out__p’ undeclared (first use in this function)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1216cuda crashed in mandelbrot2017-11-19T20:31:37ZSven-Bodo Scholzcuda crashed in mandelbrot| | |
| --- | --- |
| Bugzilla Link | [790](http://bugs.sac-home.org/show_bug.cgi?id=790) |
| Created on | Nov 30, 2010 18:15 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [mandelbrot_sbs2.sac](/uploads/37b91...| | |
| --- | --- |
| Bugzilla Link | [790](http://bugs.sac-home.org/show_bug.cgi?id=790) |
| Created on | Nov 30, 2010 18:15 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [mandelbrot_sbs2.sac](/uploads/37b9141e8227dc6ab0a7359997c1d728/mandelbrot_sbs2.sac) |
## Extended Description
<pre>Created an attachment (id=776)
source code
This is the real bug 784 :-) It now crashes in the Cuda phases when compiled with -t cuda in rev 17212</pre>Jing GuoJing Guohttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1215matmul computes errorneous result2017-11-19T20:31:34ZSven-Bodo Scholzmatmul computes errorneous result| | |
| --- | --- |
| Bugzilla Link | [787](http://bugs.sac-home.org/show_bug.cgi?id=787) |
| Created on | Nov 30, 2010 08:25 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
in experimental/cuda/numeric...| | |
| --- | --- |
| Bugzilla Link | [787](http://bugs.sac-home.org/show_bug.cgi?id=787) |
| Created on | Nov 30, 2010 08:25 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
in experimental/cuda/numerical/misc
matmul on 3kx3kx3k returns 0 rather than 3000
when using cuda BE
(rev 17212)Jing GuoJing Guohttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1295mt on mandelbroty crashes....2017-11-19T20:36:23ZSven-Bodo Scholzmt on mandelbroty crashes....| | |
| --- | --- |
| Bugzilla Link | [786](http://bugs.sac-home.org/show_bug.cgi?id=786) |
| Created on | Nov 30, 2010 07:42 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [mandelbrot_sbs2.sac](/uploads/ace462b...| | |
| --- | --- |
| Bugzilla Link | [786](http://bugs.sac-home.org/show_bug.cgi?id=786) |
| Created on | Nov 30, 2010 07:42 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [mandelbrot_sbs2.sac](/uploads/ace462b425dfc3ac2a83168c38688a3c/mandelbrot_sbs2.sac) |
## Extended Description
<pre>Created an attachment (id=774)
source (needs libs in L8)
sac2c rev 17212 crashes when trying to execute the attached program (in L8 of the tutorials)
after compilation with -mt</pre>Clemens GrelckClemens Grelckhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1087cannot declare variables of user-defined types2017-11-19T20:21:24ZSven-Bodo Scholzcannot declare variables of user-defined types| | |
| --- | --- |
| Bugzilla Link | [785](http://bugs.sac-home.org/show_bug.cgi?id=785) |
| Created on | Nov 30, 2010 06:54 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>complex[256,384] plane;...| | |
| --- | --- |
| Bugzilla Link | [785](http://bugs.sac-home.org/show_bug.cgi?id=785) |
| Created on | Nov 30, 2010 06:54 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>complex[256,384] plane; isillegal :-(</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1298Cuda related warining in sac2c2017-11-19T20:36:34ZDaniel RollsCuda related warining in sac2c| | |
| --- | --- |
| Bugzilla Link | [783](http://bugs.sac-home.org/show_bug.cgi?id=783) |
| Created on | Nov 26, 2010 15:20 |
| Version | svn |
| OS | Solaris |
| Architecture | Sun |
## Extended Description
<pre>These warnings are...| | |
| --- | --- |
| Bugzilla Link | [783](http://bugs.sac-home.org/show_bug.cgi?id=783) |
| Created on | Nov 26, 2010 15:20 |
| Version | svn |
| OS | Solaris |
| Architecture | Sun |
## Extended Description
<pre>These warnings are all cuda related and appear on Asterix.
************************************************************
Warnings sac2c (dbug version):
************************************************************
tree/tree_basic.c:224: warning: return makes pointer from integer without a cast
tree/tree_basic.c:271: warning: return makes pointer from integer without a cast
cuda/shared_memory_reuse.c:106: warning: return makes pointer from integer without a cast</pre>Jing GuoJing Guohttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1086tomcatv2 dies in memory management generation and in tup2017-11-19T20:21:21ZRobert Berneckytomcatv2 dies in memory management generation and in tup| | |
| --- | --- |
| Bugzilla Link | [779](http://bugs.sac-home.org/show_bug.cgi?id=779) |
| Created on | Nov 20, 2010 13:27 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [tomcatv2.sac](/uploads/8152a2227c04...| | |
| --- | --- |
| Bugzilla Link | [779](http://bugs.sac-home.org/show_bug.cgi?id=779) |
| Created on | Nov 20, 2010 13:27 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [tomcatv2.sac](/uploads/8152a2227c04b0aa803c6c3e5eeb490b/tomcatv2.sac) |
## Extended Description
<pre>Created an attachment (id=773)
source code to reproduce fault
sac2c apex/tomcatv2/tomcatv2.sac -noopt -O3
** 16: Introducing memory management instructions ...
**** AUD/SCL distinction ...
-----------------------------------------------
It also dies this way:
sac2c tomcatv2.sac -O3 -v4
OOOOOOOPS, your program crashed the compiler 8-((
**** Optimization cycle pass: 5
****** Optimizing regular function:
****** _MAIN::main( hidden(1), hidden(2), hidden(0)): ...
Applying common subexpression elimination ...
Inferring loop invariant variables ...
Applying type upgrade ...
ABORT: line 491 file: tomcatv2.sac
ABORT: with loop returns 3 value(s) but 1 variable(s) specified on the lhs
*** Compilation failed ***
*** Exit code 87 (Running SAC optimizations)
*** 1 Error(s), 34 Warning(s)
sac@rattler:~/sac/apex/tomcatv2$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
product rev 17200:MODIFIED linux-gnu_x86_64
(Fri Nov 19 17:52:54 EST 2010 by sac)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1085CF fails to kill modarray in constantfolding/SCCFprf_modarray5.sac2017-11-19T20:21:18ZRobert BerneckyCF fails to kill modarray in constantfolding/SCCFprf_modarray5.sac| | |
| --- | --- |
| Bugzilla Link | [778](http://bugs.sac-home.org/show_bug.cgi?id=778) |
| Created on | Nov 19, 2010 19:57 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>If the above unit tes...| | |
| --- | --- |
| Bugzilla Link | [778](http://bugs.sac-home.org/show_bug.cgi?id=778) |
| Created on | Nov 19, 2010 19:57 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>If the above unit test is compiled with:
-maxwlur 1 -docf -extrema -nowlf -doawlf -ecc
the modarray() call in tghe code is left there. Although CF properly
eliminates the modarray() from the result-using part of the code,
we are left with guards that refer to the modarray result, in order
to get its shape:
_flat_1 = true;
_flat_0 = 1;
one = _MAIN::id( _flat_0, _flat_1) ;
_isaa_49_one = _dim_A_( one);
_isaa_50_one = _shape_A_( one);
_isaa_51_one = _saabind_( _isaa_49_one, _isaa_50_one, one);
_idc_38, _icc_27_pred = _type_constraint_( int, _isaa_51_one);
_icc_28 = _add_SxS_( _idc_38, _flat_0);
_flat_2 = _afterguard_( _icc_28, _icc_27_pred);
cltwo = _MAIN::id( _flat_2, _flat_1) ;
_isaa_52_cltwo = _dim_A_( cltwo);
_isaa_53_cltwo = _shape_A_( cltwo);
_isaa_54_cltwo = _saabind_( _isaa_52_cltwo, _isaa_53_cltwo, cltwo);
_flat_5 = 5;
five = _MAIN::id( _flat_5, _flat_1) ;
_isaa_55_five = _dim_A_( five);
_isaa_56_five = _shape_A_( five);
_isaa_57_five = _saabind_( _isaa_55_five, _isaa_56_five, five);
_idc_39, _icc_29_pred = _type_constraint_( int, _isaa_57_five);
_flat_7 = [:int];
_idc_40, _icc_30_pred = _shape_matches_dim_VxA_( _flat_7, _isaa_54_cltwo);
_idc_42, _icc_32_pred = _val_lt_shape_VxA_( _flat_7, _isaa_54_cltwo);
_icc_33 = _modarray_AxVxS_( _isaa_54_cltwo, _flat_7, _idc_39);
x3 = _afterguard_( _icc_33, _icc_32_pred, _icc_30_pred, _icc_29_pred);
_idc_44, _icc_34_pred = _shape_matches_dim_VxA_( _flat_7, x3);
_idc_45, _icc_36_pred = _val_lt_shape_VxA_( _idc_44, x3);
z = _afterguard_( _idc_39, _icc_36_pred, _icc_34_pred);
_esd_48 = -5;
z__SSA0_1 = _add_SxS_( z, _esd_48);
return( z__SSA0_1);
I think the best approach here is to replace guards that refer to
dim or shape by new guards that use _shape_A_ or _dim_A_.
Other CF code would then replace those by the SAA shape/dim
of the array.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1084Masterrun failures2017-11-19T20:21:15ZDaniel RollsMasterrun failures| | |
| --- | --- |
| Bugzilla Link | [777](http://bugs.sac-home.org/show_bug.cgi?id=777) |
| Created on | Nov 19, 2010 11:24 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
This is a tracker bug to mon...| | |
| --- | --- |
| Bugzilla Link | [777](http://bugs.sac-home.org/show_bug.cgi?id=777) |
| Created on | Nov 19, 2010 11:24 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
This is a tracker bug to monitor those bugs which cause sac2c, stdlib or testcases to fail or produce wrong results in a masterrun. This bug is for failures only, not warnings.BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1083APEX masterrun failures2017-11-19T20:21:12ZRobert BerneckyAPEX masterrun failures| | |
| --- | --- |
| Bugzilla Link | [774](http://bugs.sac-home.org/show_bug.cgi?id=774) |
| Created on | Nov 16, 2010 20:33 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This is a summary of ...| | |
| --- | --- |
| Bugzilla Link | [774](http://bugs.sac-home.org/show_bug.cgi?id=774) |
| Created on | Nov 16, 2010 20:33 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This is a summary of masterrun failure modes for APEX benchmarks, as of 2010-11-16.
In the "runs forever, or close to it" category, we have crc*, ipape*
ipplusand*, ipopne*, ulam*, UTReduce,
---------------------------
OOOOOOOPS, your program crashed the compiler 8-((
OOOOOOOPS, your program crashed the compiler 8-((
OOOOOOOPS, your program crashed the compiler 8-((
OOOOOOOPS, your program crashed the compiler 8-((
Not much of clue here. Perhaps sac2c should give some more hints as
to what program was running?
--------------------------------
ERROR: unknown user defined type `_MAIN::time'.
ERROR: unknown user defined type `_MAIN::time'.
ERROR: unknown user defined type `_MAIN::time'.
ERROR: unknown user defined type `_MAIN::time'.
This reflects an undocumented (as far as I can tell) change to
stdlib contents.
UTClock suffers from a related problem.
--------------------------
make[6]: [dtb] Error 87 (ignored)
make[6]: [dtb_mt] Error 87 (ignored)
make[6]: [dtb2] Error 87 (ignored)
make[6]: [dtb2_mt] Error 87 (ignored)
These are WLF failures. See Bug# 773 and perhaps others.
Caused by subtraction in an index vector.
UTReverse suffers from same bug.
UTRotate234.sac ditto.
ABORT: line 290 file: ArrayBasics.sac
ABORT: Array access to _pinl_9586_z out of range in dimension 1
-----------------------------------------
make[6]: *** [.ipapeijk.d] Error 1
This is a hand-coded variant of the ipape inner product benchmark.
It needs fixing.
Or, perhaps, as the hillbilly murder defense was put: He needed killin'.
Fixed in sac/apex/ipape build #1316.
-----------------------------------------
logd*, mconv*, metaph*, nmo* failures: APEX compiler problems.
----------------------------------------
mdiv*: sac2c crashes. Cause not investigated.
-----------------------------------------------
UTEpio, rle3AKD: excessive compile time.
-----------------------------------------------
UTThornInt: excessive compile time.
-------------------------------------
UTThornReal: perhaps sac2c problem introduced when
new integer types arrived. I crippled it, because it
took forever to compile.
--------------------------------------
In general, things are, despite how this looks, improving!</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1082dtb* failures in WLF2017-11-19T20:21:09ZRobert Berneckydtb* failures in WLF| | |
| --- | --- |
| Bugzilla Link | [773](http://bugs.sac-home.org/show_bug.cgi?id=773) |
| Created on | Nov 16, 2010 19:52 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
sac/apex/dtb/dtb.sac and f...| | |
| --- | --- |
| Bugzilla Link | [773](http://bugs.sac-home.org/show_bug.cgi?id=773) |
| Created on | Nov 16, 2010 19:52 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
sac/apex/dtb/dtb.sac and friends all fail in WLF due to subtractions
in index vectors operating in a consumerWL on data from a producerWL.
I thought we had a bugzilla entry for this, but none are showing
up, so here go again. This one goes WAY back.BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1081LUR can not handle Compare to zero2017-11-19T20:21:06ZCarl JoslinLUR can not handle Compare to zero| | |
| --- | --- |
| Bugzilla Link | [772](http://bugs.sac-home.org/show_bug.cgi?id=772) |
| Created on | Nov 09, 2010 15:16 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
Loop unrolling can not mat...| | |
| --- | --- |
| Bugzilla Link | [772](http://bugs.sac-home.org/show_bug.cgi?id=772) |
| Created on | Nov 09, 2010 15:16 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
Loop unrolling can not match the code patten that is produced when compare to zero.
More details to follow.BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1229AWLF fails to propagate extrema for mixed N_array node2017-11-19T20:32:23ZRobert BerneckyAWLF fails to propagate extrema for mixed N_array node| | |
| --- | --- |
| Bugzilla Link | [766](http://bugs.sac-home.org/show_bug.cgi?id=766) |
| Created on | Nov 01, 2010 22:56 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>If an N_array node, i...| | |
| --- | --- |
| Bugzilla Link | [766](http://bugs.sac-home.org/show_bug.cgi?id=766) |
| Created on | Nov 01, 2010 22:56 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>If an N_array node, iv, used in a sel(iv, producerWL) contains
a mix of constants and WITHIDS, e.g, iv = [ 2, j, k], then
iv does not obtain extrema, which defeats AWLF on the producerWL.
Here is failing code, to be compiled with:
sac2c -ecc -extrema -doawlf -nowlf mixedIV.sac
use Array: {-,transpose,genarray,++,*,iota,sum};
int main()
{
shp = [ 6, 10];
AAA = with {
( . <= iv=[i,j] <= .) :
_add_SxS_( j, _mul_SxS_( i, _sel_VxA_( [1], shp)));
} : genarray( shp, 42);
b = with {
( . <= IV=[JJ] <= .) :
_sel_VxA_( [ 1, JJ], AAA);
} : genarray( [8], 666);
z = sum(b) - 108;
return(z);
}</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1080Dimension of array lost?2017-11-19T20:21:02ZCarl JoslinDimension of array lost?| | |
| --- | --- |
| Bugzilla Link | [762](http://bugs.sac-home.org/show_bug.cgi?id=762) |
| Created on | Oct 19, 2010 14:00 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [loop8p.sac](/uploads/608c9a8c030125...| | |
| --- | --- |
| Bugzilla Link | [762](http://bugs.sac-home.org/show_bug.cgi?id=762) |
| Created on | Oct 19, 2010 14:00 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [loop8p.sac](/uploads/608c9a8c030125fa9c67485b6dde5e53/loop8p.sac), [loop8.inp](/uploads/91af819caff05e8de577ed50640c5d3a/loop8.inp) |
## Extended Description
<pre>When running loop8 with icc the following error is produced
*** SAC runtime error
*** No appropriate instance of function "_MAIN::Loop8 :: int[*] int[*] double[*] double[*] double[*] double[*] double[*] -> double[.,.,.] " found!
*** Shape of arguments:
*** [ 1]
*** []
*** [ 5, 2, 101]
*** [ 5, 2, 101]
*** [ 5, 2, 101]
*** [ 5, 2, 101]
*** [ 10, 13, 3, 1010, 5, 2, 101, 4209518, 0, 25415280, 0, 1125511200, 32767, 25407152, 0, 1125511168, 32767, 1125511152, 32767, 500001, 1, 25445888, 0, 1125511136, 32767, 100, 32632, 25407248, 0, 25407280, 0, 500001, 1, 24747728, 0, 24866928, 0, 100, 0...]
To me it appears that the dimensionality of the last argument to _MAIN::Loop8 has been lost/uninitialized. However from the source code this argument should be AKS, double[10]
This does not seem to happen for gcc which makes this quite strange.
Detail of how to reproduce will be added by dsr</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1079-ecc makes AWLF ineffective for cubeslice1dbeta.sac2017-11-19T20:20:58ZRobert Bernecky-ecc makes AWLF ineffective for cubeslice1dbeta.sac| | |
| --- | --- |
| Bugzilla Link | [761](http://bugs.sac-home.org/show_bug.cgi?id=761) |
| Created on | Oct 16, 2010 14:27 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud](/uploads/5588efbe6b5037d2c0e4...| | |
| --- | --- |
| Bugzilla Link | [761](http://bugs.sac-home.org/show_bug.cgi?id=761) |
| Created on | Oct 16, 2010 14:27 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud](/uploads/5588efbe6b5037d2c0e488eacd03ee88/crud), [cubeslice1dbeta.sac](/uploads/1fadd3388841f6975915d9d259159bc8/cubeslice1dbeta.sac) |
## Extended Description
<pre>Created an attachment (id=764)
Output from sac2c cubeslice1dbeta.sac -ecc -extrema -nowlf -dowlf -bopt:uglf
The attachment is from:
sac2c cubeslice1dbeta.sac -ecc -extrema -nowlf -dowlf -bopt:uglf</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1078scc constraint removal can produce empty WL block!2017-11-19T20:20:54ZRobert Berneckyscc constraint removal can produce empty WL block!| | |
| --- | --- |
| Bugzilla Link | [756](http://bugs.sac-home.org/show_bug.cgi?id=756) |
| Created on | Oct 03, 2010 21:45 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/94c77dc95aea2196...| | |
| --- | --- |
| Bugzilla Link | [756](http://bugs.sac-home.org/show_bug.cgi?id=756) |
| Created on | Oct 03, 2010 21:45 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/94c77dc95aea21967a33d34fcf6cad63/crud.sac) |
## Extended Description
<pre>In the attached, compiling with:
sac2c-d crud.sac -O3 -doawlf -nowlf -extrema -ecc -v1
for build #developer rev 17069:MODIFIED
causes a crash in EBT after SCC. It looks like the problem
is that SCC blindly eliminates code from a block, but
this can (and does, in this case) result it removing the
last piece of code from an N_with code block, which is
verboten.
I think the fix is to put some code in SCCblock to check
for this and insert the canonical EMPTY marker if the
block does become empty.</pre>BugZillaBugZillahttps://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/1077First axis reduction of tensor runs 10X slower than reduction of entire tensor2017-11-19T20:20:50ZRobert BerneckyFirst axis reduction of tensor runs 10X slower than reduction of entire tensor| | |
| --- | --- |
| Bugzilla Link | [754](http://bugs.sac-home.org/show_bug.cgi?id=754) |
| Created on | Sep 30, 2010 19:46 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/7129bd81622fc598...| | |
| --- | --- |
| Bugzilla Link | [754](http://bugs.sac-home.org/show_bug.cgi?id=754) |
| Created on | Sep 30, 2010 19:46 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/7129bd81622fc5989704708be7bdf606/crud.sac) |
## Extended Description
<pre>Created an attachment (id=758)
source code to reproduce fault
The attached code performs a sum reduction over the first axis of
a rank-3 array, if compiled with:
sac2c -O3 crud.sac -DSLOW
The resulting code executes in roughly 7 seconds on a 3GHz Opteron.
If I have the Ubuntu system monitor running, I see that memory usage
creeps up DURING the execution of the reduction. This is surprising,
as I would naively expect that all allocations would be done before
we enter the loop.
If compiled with:
sac2c -O3 crud.sac
The resulting code performs a sum() over the entire tensor, and executes in
about 0.85 seconds.
The offending function is likely this one:
inline int[+] plussl1XBIFOLD(bool[+] y)
{ /* first-axis reduce rank-3 or greater matrix */
yt = transpose(y);
zrho = drop([-1], shape(yt));
z = with {
(. <= iv <= .)
: sum(toi((yt[iv])));
} : genarray(zrho, 0);
return(z);
}
Perhaps there is a better way to express such a reduction?
The idea here is that an argument of shape [ 10,20,30] will
give a result shape of [20,30].
Part of the problem is that the reduction array shape is AKD,
which is causing some WLF opportunities to be missed.
However, declaring the reduce argument this way:
bool[3000, 15000,3] A_23;
still leaves the -DSLOW code running about 6X slower than
the other code.
This on: product rev 17069:MODIFIED linux-gnu_x86_64</pre>BugZillaBugZilla