sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:23:10Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1117EDFA crashes SSAT2017-11-19T20:23:10ZRobert BerneckyEDFA crashes SSAT| | |
| --- | --- |
| Bugzilla Link | [957](http://bugs.sac-home.org/show_bug.cgi?id=957) |
| Created on | May 20, 2012 17:23 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Build #17829 contains...| | |
| --- | --- |
| Bugzilla Link | [957](http://bugs.sac-home.org/show_bug.cgi?id=957) |
| Created on | May 20, 2012 17:23 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Build #17829 contains my latest -doedfa code, which attempts
to eliminate duplicate arguments from LACFUNs.
The generated code for the failing example looks OK to me,
but it does not look OK to SSAT, which crashes in RN_top in
SSATid: (SSATransform.c):
case RN_top:
new_avis = AVIS_SSASTACK_TOP( ID_AVIS( arg_node));
AVIS_SSASTACK_TOP has a pointer of some sort in it, but *AVIS_SSASTACK_TOP
is 57. Homage to Mr. Heinz?
Suggestions welcome.
This should break it:
sac2c -v1 -doedfa -nowlf -doawlf ~/sac/testsuite/optimizations/edfa/bug907BAKD.sac</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1116-d treecheck node set membership tests are wrong2017-11-19T20:23:07ZRobert Bernecky-d treecheck node set membership tests are wrong| | |
| --- | --- |
| Bugzilla Link | [956](http://bugs.sac-home.org/show_bug.cgi?id=956) |
| Created on | May 17, 2012 18:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This code is generate...| | |
| --- | --- |
| Bugzilla Link | [956](http://bugs.sac-home.org/show_bug.cgi?id=956) |
| Created on | May 17, 2012 18:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This code is generated in check.c:
/*
* Attribute check: AVIS_DECL
*/
if( ( FALSE)|| ( TRUE)){
CHKexistAttribute( AVIS_DECL( arg_node), arg_node, "mandatory attribute AVIS_DECL is NULL");
if( AVIS_DECL( arg_node)!= NULL){
if( !(( FALSE)|| ( NODE_TYPE( AVIS_DECL( arg_node))== N_vardec))){
CHKcorrectTypeInsertError(arg_node,"AVIS_DECL hasnt the right type."" It should be: ""N_vardec");
}
}
}
else if( ( FALSE)|| ( TRUE)){
CHKexistAttribute( AVIS_DECL( arg_node), arg_node, "mandatory attribute AVIS_DECL is NULL");
if( AVIS_DECL( arg_node)!= NULL){
if( !(( FALSE)|| ( NODE_TYPE( AVIS_DECL( arg_node))== N_arg))){
CHKcorrectTypeInsertError(arg_node,"AVIS_DECL hasnt the right type."" It should be: ""N_arg");
}
}
}
else {
CHKnotExist( AVIS_DECL( arg_node), arg_node, "attribute AVIS_DECL must be NULL");
The set membership test is incorrect, in that it will report
an error( expected N_vardec) if AVIS_DECL is an N_arg node,</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1115SISI is disabled by default, and crashes if enabled2017-11-19T20:23:03ZRobert BerneckySISI is disabled by default, and crashes if enabled| | |
| --- | --- |
| Bugzilla Link | [954](http://bugs.sac-home.org/show_bug.cgi?id=954) |
| Created on | May 15, 2012 14:22 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I just discovered tha...| | |
| --- | --- |
| Bugzilla Link | [954](http://bugs.sac-home.org/show_bug.cgi?id=954) |
| Created on | May 15, 2012 14:22 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I just discovered that SISI is NOT enabled by default, and
that it crashes (in SISI) if you enable it:
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17818:MODIFIED linux-gnu_x86_64
(Tue May 15 09:02:34 EDT 2012 by sac)
I was going to extend it to simplify LACFUN arguments
by removing duplicate shapes, but that pit has just grown a
bit deeper... Poop.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1114CSE repeats same job, perhaps caused by ESD2017-11-19T20:22:58ZRobert BerneckyCSE repeats same job, perhaps caused by ESD| | |
| --- | --- |
| Bugzilla Link | [953](http://bugs.sac-home.org/show_bug.cgi?id=953) |
| Created on | May 14, 2012 20:03 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>CSE, at least in the ...| | |
| --- | --- |
| Bugzilla Link | [953](http://bugs.sac-home.org/show_bug.cgi?id=953) |
| Created on | May 14, 2012 20:03 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>CSE, at least in the AWLFI micro-cycle, appears to be
repeating the same work over and over again.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17817:MODIFIED linux-gnu_x86_64
(Mon May 14 13:38:24 EDT 2012 by sac)
SimplifySymb: SSE: DLIR= 0, WLIR= 0, INL=0, CSE=25, TUP=0, CF=0, VP=0, AS=0, AL=0, DL=0
SimplifySymb: SSE: Cycle interation 19...
This repeats until we reach maxoptcyc.
If I disable the call to ESD in the cycle, the problem does
not occur.
The fault can be seen with this call:
cd sac/apex/ipape
sac2c ipape.sac -doawlf -nowlf -v4 -#d,SSE</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1113integer overflows: -2 < maxint() is false in sac2017-11-19T20:22:55ZJaroslav Sýkorainteger overflows: -2 < maxint() is false in sac| | |
| --- | --- |
| Bugzilla Link | [951](http://bugs.sac-home.org/show_bug.cgi?id=951) |
| Created on | May 04, 2012 14:29 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [cmp.sac](/uploads/a7b9777eb4762350c...| | |
| --- | --- |
| Bugzilla Link | [951](http://bugs.sac-home.org/show_bug.cgi?id=951) |
| Created on | May 04, 2012 14:29 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [cmp.sac](/uploads/a7b9777eb4762350c42e437f425da2e9/cmp.sac) |
## Extended Description
<pre>Comparing (-2 < maxint()) returns false. See the attached source: it should print [true,true,true], but gives [true,false,false]. Tested on sac2c r17796.
_flat_3 = Constants::maxint() ; // 2147483647
_ctz_77 = _sub_SxS_( -2, _flat_3); // -2-2147483647 overflows to 2147483647
_pinl_48__flat_59 = _lt_SxS_( _ctz_77, 0); // compares 2147483647 < 0, giving false</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1112masterrun does not terminate due to ArrayFormatUT running forever2017-11-19T20:22:52ZSven-Bodo Scholzmasterrun does not terminate due to ArrayFormatUT running forever| | |
| --- | --- |
| Bugzilla Link | [949](http://bugs.sac-home.org/show_bug.cgi?id=949) |
| Created on | May 01, 2012 19:13 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>using sac2c rev.17794 a...| | |
| --- | --- |
| Bugzilla Link | [949](http://bugs.sac-home.org/show_bug.cgi?id=949) |
| Created on | May 01, 2012 19:13 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>using sac2c rev.17794 and
stdlib rev. 1624 and
sac rev 1664
the file testsuite/stdlib/modules/structures/ArrayFormatUT.sac compiles -mt fine but
the generated ArrayFormatUT_mt runs forever......</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1264crash in WLF, triggered by specialized+inline function that fails to inline2017-11-19T20:34:26ZJaroslav Sýkoracrash in WLF, triggered by specialized+inline function that fails to inline| | |
| --- | --- |
| Bugzilla Link | [943](http://bugs.sac-home.org/show_bug.cgi?id=943) |
| Created on | Mar 30, 2012 16:51 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [inline-wlf.tar.gz](/uploads/04eaa78...| | |
| --- | --- |
| Bugzilla Link | [943](http://bugs.sac-home.org/show_bug.cgi?id=943) |
| Created on | Mar 30, 2012 16:51 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [inline-wlf.tar.gz](/uploads/04eaa7843ce4ae0d2941bd40c67d5cd0/inline-wlf.tar.gz) |
## Extended Description
<pre>Created an attachment (id=873)
demo for the bug
Compiler crashes in WLF; disabling WLF (-nowlf) makes it run...
Possibly there is more than one problem here. The shape of x=iota(4) is not inferred to be int[4], it stays simply int[.] (why?). Therefore, cwc:dfc pass cannot inline function 'suma', because it cannot statically match int[.] (from iota) and int[4] (from suma() specialization). Afterwards it crashes in wlf. Interestingly, it works when 'inline' on suma is removed. Perhaps there is a confusion somewhere that a function marked 'inline' is not actually inlined?
Amusingly, when you modify the source code below in *any* *one* of the following ways it works!
* removing inline on function 'suma'
* removing the shape specialization on 'suma', i.e. replacing 'int[SZ]' by 'int[.]'. This enables cwc:dfc to inline the function completely.
* replacing the iota() call with (currently commented out) direct assignment x=[0,1,2,3]; This also enables to inline suma().
/**********************************************************************
*
* SAC bug report: spec-inlined.sacbugreport
*
**********************************************************************
*
* Automatically generated on Fri Mar 30 16:20:45 BST 2012
*
* using sac2c v1.00-beta (Haggis And Apple) rev 17776:MODIFIED for linux-gnu_i686
* built Fri Mar 30 16:09:20 BST 2012.
* by user js308 on host lxjs308 for linux-gnu.
*
* The compiler was called by
* sac2c -o spec-inlined spec-inlined.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 spec-inlined.sac.
*
**********************************************************************/
use Array: all;
use StdIO: all;
#define SZ 4
inline
int suma(int[SZ] x)
{
y = with {
(0*shape(x) <= iv < shape(x)) : x[iv];
} : fold(+, 0);
return y;
}
int main()
{
x = iota(SZ);
// x = [0, 1, 2, 3];
// print(x);
y = suma(x);
print(y);
return 0;
}
/**********************************************************************
*
* End of bug report
*
**********************************************************************/</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2204Printf crashes nvcc on CUDA targets2017-11-23T23:24:38ZMiguel Sousa DiogoPrintf crashes nvcc on CUDA targets| | |
| --- | --- |
| Bugzilla Link | [941](http://bugs.sac-home.org/show_bug.cgi?id=941) |
| Created on | Mar 27, 2012 15:21 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>Using the printf functi...| | |
| --- | --- |
| Bugzilla Link | [941](http://bugs.sac-home.org/show_bug.cgi?id=941) |
| Created on | Mar 27, 2012 15:21 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>Using the printf function and compiling SaC for CUDA generates invalid CUDA code, which crashes the nvcc compiler. A simple hello-world program is enough to cause this crash:
----------------------------
$ sac2c -target cuda world.sac
...
** 22: Creating binary code ...
**** Handling dependencies ...
**** Invoking C compiler ...
a.out.cu(204): error: more than one instance of overloaded function "printf" has "C" linkage
a.out.cu(685): warning: variable "SACp_tcp_924__emal_696__flat_1__shp0" was set but never used
a.out.cu(686): warning: variable "SACp_tcp_924__emal_696__flat_1__sz" was set but never used
a.out.cu(687): warning: variable "SACp_tcp_924__emal_696__flat_1__dim" was declared but never referenced
1 error detected in the compilation of "/tmp/tmpxft_00009db2_00000000-4_a.out.cpp1.ii".
ABORT: System failed to execute shell command
...
with exit code 2
*** Compilation failed ***
*** Exit code 373 (Creating binary code)
*** 1 Error(s), 4 Warning(s)
----------------------------
Contents of world.sac:
----------------------------
use StdIO: all;
use Array: all;
int main() {
printf( "Hello World!\n");
return(0); }
----------------------------
Using sac2c from svn, nvcc version 4.1, and gcc version 4.5.3.</pre>Jing GuoJing Guohttps://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/1025heap manager fails under valgrind and error reports are uninformative2017-11-19T20:17:38ZBep Rintoheap manager fails under valgrind and error reports are uninformative| | |
| --- | --- |
| Bugzilla Link | [932](http://bugs.sac-home.org/show_bug.cgi?id=932) |
| Created on | Mar 10, 2012 10:36 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>When testing SAC...| | |
| --- | --- |
| Bugzilla Link | [932](http://bugs.sac-home.org/show_bug.cgi?id=932) |
| Created on | Mar 10, 2012 10:36 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>When testing SAC programs with valgrind I get the following error message:
*** SAC runtime error
*** SAC heap manager failed to obtain 2097152 Bytes of memory from operating system !
The problems are that this message is unhelpful for the developer:
It doesn't report which operating system's function returned an error
and it doesn't report the errno or the error message using strerror(errno)
or the printf %m.
Also, could SAC be made to work under valgrind?
This is a great debugging aid for developers,
which helps in making SAC and SAC programs more reliable.</pre>Clemens GrelckClemens Grelckhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1015sac2c crashes while parsing nested if-else with multi-return calls2017-11-19T20:17:04ZBep Rintosac2c crashes while parsing nested if-else with multi-return calls| | |
| --- | --- |
| Bugzilla Link | [928](http://bugs.sac-home.org/show_bug.cgi?id=928) |
| Created on | Mar 04, 2012 08:15 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>/***************...| | |
| --- | --- |
| Bugzilla Link | [928](http://bugs.sac-home.org/show_bug.cgi?id=928) |
| Created on | Mar 04, 2012 08:15 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>/**********************************************************************
*
* SAC bug report: testpnm.sacbugreport
*
**********************************************************************
*
* Automatically generated on Sun Mar 4 09:01:14 CET 2012
*
* using sac2c v1.00-beta (Haggis And Apple) rev 17729 for linux-gnu_x86_64
* built Mon Feb 13 10:00:22 GMT 2012.
* by user fpz on host dogmatix for linux-gnu.
*
* The compiler was called by
* sac2c -check tb -v 1 -g -mt -o testpnm_mt testpnm.sac
*
* The compiler crashed in
* phase: pc (Preparing C code generation)
* sub phase: dvr (Removing obsolete variable declarations)
*
* What follows is the contents of testpnm.sac.
*
**********************************************************************/
/* Test driver for PGM module. */
use StdIO: { printf, fopen, fclose, ftell, fseek };
use RuntimeError: { error };
use CommandLine: { argc, argv };
use File: { File, fgetc, fscanf, feof, ungetc };
use SysErr: { fail };
import String: { string, == };
import ScalarArith: all;
import Array: all;
void skip(File f)
{
}
int, int, int, int read_PNM_header(string name)
{
int kind, widths, height, maxval;
File f;
e, f = fopen(name, "rb");
if (fail(e)) {
error( (:int) e, "Could not open %s for reading", name);
}
kind = 0;
widths = 0;
height = 0;
maxval = 0;
if (fgetc(f) == 'P') {
T = fgetc(f);
if (T >= '1' && T <= '6') {
kind = toi(T) - toi('0');
skip(f);
n, widths = fscanf(f, " %u");
if (n == 1) {
skip(f);
n, height = fscanf(f, " %u");
}
if (kind == 1 || kind == 4) {
maxval = 1;
}
else if (n == 1) {
skip(f);
n, maxval = fscanf(f, " %u");
}
if (n == 1) {
skip(f);
}
}
}
fclose(f);
return (kind, widths, height, maxval);
}
int main()
{
if (argc() < 2) {
error(1, "Need at least one arg");
}
for (i = 1; i < argc(); ++i) {
s = argv(i);
kind, widths, height, maxval = read_PNM_header(s);
}
return 0;
}
/**********************************************************************
*
* End of bug report
*
**********************************************************************/</pre>Artem ShinkarovArtem Shinkarovhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1314Sac2c product version fails to build sacprelude2017-11-19T20:37:57ZMiguel Sousa DiogoSac2c product version fails to build sacprelude| | |
| --- | --- |
| Bugzilla Link | [924](http://bugs.sac-home.org/show_bug.cgi?id=924) |
| Created on | Feb 27, 2012 13:12 |
| Version | svn |
| OS | MacOS X |
| Architecture | PC |
| Attachments | [sac2c_2012-02-27-130504_MBP-Migas...| | |
| --- | --- |
| Bugzilla Link | [924](http://bugs.sac-home.org/show_bug.cgi?id=924) |
| Created on | Feb 27, 2012 13:12 |
| Version | svn |
| OS | MacOS X |
| Architecture | PC |
| Attachments | [sac2c_2012-02-27-130504_MBP-Migas.crash](/uploads/aaebbf09fa145ba2d6a8632e122f742c/sac2c_2012-02-27-130504_MBP-Migas.crash), [xsacprelude.sacbugreport](/uploads/2515ee68594dfa112455bcff86a14e9b/xsacprelude.sacbugreport), [sac2c_2012-04-23-155505_MBP-Migas.crash](/uploads/d32308b1d4d3059e1331669358cb3f2c/sac2c_2012-04-23-155505_MBP-Migas.crash), [sacprelude.sacbugreport](/uploads/2f9bb6619d5de9d9ab130b919b1fb3e5/sacprelude.sacbugreport) |
## Extended Description
<pre>Created an attachment (id=855)
sac bug report
Running "make prod" from svn fails compiling sacprelude.sac. It's crashing on the constant folding subphase of enhancing with-loops.
I came across this on OS X, I'm not sure if this is a platform specific issue or not. I'm attaching the sac bug report.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1022Can not print from a fold function2017-11-19T20:17:28ZBugZillaCan not print from a fold function| | |
| --- | --- |
| Bugzilla Link | [914](http://bugs.sac-home.org/show_bug.cgi?id=914) |
| Created on | Feb 21, 2012 20:07 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | Other |
| Reporter | snowgoon2003 |
## Extended Des...| | |
| --- | --- |
| Bugzilla Link | [914](http://bugs.sac-home.org/show_bug.cgi?id=914) |
| Created on | Feb 21, 2012 20:07 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | Other |
| Reporter | snowgoon2003 |
## Extended Description
<pre>From Bodos mail in the tread "using fold on vectors in a matrix"
----------------*****------------------------------
If you write something like this:
use Array: all;
int[.] american(int[.] a, int[.] b){
StdIO::print(b);
return (b);
}
int main()
{
a = [1,2,3,4,5,6];
c = american( a, a);
return( 0);
}
Then, in principle, you might think that print is just a side effect.
But no, in reality, SaC is very much aware of these things and print
operates on a global object named TheTerminal.
As a consequence, the compiler makes this explicit by converting the code into:
use Array: all;
int[.], Terminal american(int[.] a, int[.] b, Terminal TheTerminal){
TheTerminal' = StdIO::print(b, TheTerminal);
return (b, TheTerminal');
}
int, Terminal main(Terminal TheTerminal)
{
a = [1,2,3,4,5,6];
c, TheTerminal' = american( a, a, TheTerminal);
return( 0, TheTerminal');
}
This works fine as long as both sides, the function definition AND the function call are
being modified consistently.
Now, by using american within the fold operation, the function call is implicit, at least
in the beginning. Later in the compiler, we make it explicit. Seemingly, at that stage,
we have forgotten that we may have to adjust the call by any potentially affected objects :-((((
As a consequence, the compiler looks for a function american that only has two parameters,
which, at that stage no longer exists as the signature of american has been expanded into 3
arguments!</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1111buildv.sac AWLF blocked by failure to simplify guard on catenate2017-11-19T20:22:49ZRobert Berneckybuildv.sac AWLF blocked by failure to simplify guard on catenate| | |
| --- | --- |
| Bugzilla Link | [911](http://bugs.sac-home.org/show_bug.cgi?id=911) |
| Created on | Feb 15, 2012 21:52 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The APEX buildv.sac b...| | |
| --- | --- |
| Bugzilla Link | [911](http://bugs.sac-home.org/show_bug.cgi?id=911) |
| Created on | Feb 15, 2012 21:52 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>The APEX buildv.sac benchmark constructs the vector:
(iota(0)),(iota(1)),(iota(2))...(iota(n))
by means of a fold WL. The result is generated
within the WL body by ++. The indexing operations
use this sort of guard when AWLF and/or -ecc/-check c are invoked:
_dup_2716__uprf_1576, _dup_2717__uprf_1577 =
_val_le_val_SxS_( _dup_2712__uprf_1581, _dup_2715__pinl_1144__flat_880);
currentshape[0] currentshape[0] + i
The right way to handle this is to perform comparison against zero,
as is done in min/max:
tmp = PRF_ARG - PRF_ARG1
val_le_val_SxS_( 0, tmp);
I hope this can be done by ICC, directly.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1110Buildv.sac appears to be missing reuse code2017-11-19T20:22:46ZRobert BerneckyBuildv.sac appears to be missing reuse code| | |
| --- | --- |
| Bugzilla Link | [910](http://bugs.sac-home.org/show_bug.cgi?id=910) |
| Created on | Feb 14, 2012 17:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [a.out.awlf](/uploads/9b1b800fd6a53c...| | |
| --- | --- |
| Bugzilla Link | [910](http://bugs.sac-home.org/show_bug.cgi?id=910) |
| Created on | Feb 14, 2012 17:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [a.out.awlf](/uploads/9b1b800fd6a53ca327c7cd0064367c47/a.out.awlf), [a.out.wlf](/uploads/5dd20850e28e470dc91a32e48c7270da/a.out.wlf), [crud.awlf](/uploads/aabbea776bb9fe76cfd594ac171dc2ce/crud.awlf), [crud.wlf](/uploads/2a8fdf9c28900897805ee82d549dc2e8/crud.wlf) |
## Extended Description
<pre>Created an attachment (id=848)
C code generated by sac2c -doawlf -nowlf -bopt
This code runs about twice as slow with -doawlf -nowlf as without:
use Array:all;
int main()
{
x = with {
([0] <= iv=[i] < [2000]) : iota(i);
} : fold( ++, [:int]);
z = sum(x);
StdIO::show(z);
return(0);
}
The IL codes at -bopt look, to my not-tutored-enough eyeballs, to be
almost identical. However, the generated C code shows that
the -doawlf version contains 15 for()-loops, whereas the -doawlf
version has only 13.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17729:MODIFIED linux-gnu_x86_64
(Mon Feb 13 09:44:42 EST 2012 by sac)
This is not a new bug. Attached are the generated C codes and
the -bopt codes.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1109-profile dies in fun2lac.2017-11-19T20:22:40ZRobert Bernecky-profile dies in fun2lac.| | |
| --- | --- |
| Bugzilla Link | [908](http://bugs.sac-home.org/show_bug.cgi?id=908) |
| Created on | Feb 10, 2012 17:00 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>No idea how long this...| | |
| --- | --- |
| Bugzilla Link | [908](http://bugs.sac-home.org/show_bug.cgi?id=908) |
| Created on | Feb 10, 2012 17:00 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>No idea how long this has been broken. The problem lies in fun2lac,
but I have no idea how to fix it.
cat crud2.sac
use Array:{<,++,+};
int main()
{
x = [2,3,5];
z = 0;
for( i=0; i<3; i++) {
z = z + _sel_VxA_([i], x);
}
StdIO::print(z);
return(0);
}
sac2c crud2.sac -v1 -profile l
flatten/fun2lac.c:293 Assertion "FALSE" failed!
Control flow should not reach here
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17728 linux-gnu_x86_64
(Fri Feb 10 11:48:32 EST 2012 by sac)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1108Livermore Loop09 poor performance with sparse-vector/matrix multiply2017-11-19T20:22:37ZRobert BerneckyLivermore Loop09 poor performance with sparse-vector/matrix multiply| | |
| --- | --- |
| Bugzilla Link | [907](http://bugs.sac-home.org/show_bug.cgi?id=907) |
| Created on | Jan 22, 2012 21:50 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [loop09.sac](/uploads/ec6b1360cee8e6...| | |
| --- | --- |
| Bugzilla Link | [907](http://bugs.sac-home.org/show_bug.cgi?id=907) |
| Created on | Jan 22, 2012 21:50 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [loop09.sac](/uploads/ec6b1360cee8e6b0a7bb29708f7bd64b/loop09.sac), [crud.simple.sac](/uploads/272cf9eec0975000542d117cac2242e6/crud.simple.sac), [condfun.sac](/uploads/8c98f518133505d73778103cd24f7633/condfun.sac) |
## Extended Description
<pre>Created an attachment (id=845)
source code to reproduce failure
I rewrote loop09 to use a sparse-vector vs. dense matrix inner product
function, which made the code much more readable and maintainable.
Unfortunately, it's also much slower than the scalar-oriented C code.
It should not be, so I had a look into it. There are several
LACFUN-related problems, and AWLF suffers from all of them:
1. The loop09 code uses a FOR-loop of the form: (i=0; i<lim; i++).
We currently have no way to provide i with extrema. This causes
a number of problems with AWLF, guards, CF, etc.
I was going to pass extrema into/out of LACFUNs, but that would
not help here, because there are no steenking extrema.
Some ways we might deal with this problem:
a. Provide a "serial-WL" that offers a stricter format for
induction variable specification.
b. Provide kludge code to analyze FOR-loop induction variables,
when the patterns are simple (as above).
c. Since the FOR-loop can actually be performed in parallel,
we could design a "conditional-WL" that allows some
iterations to provide no result cell. In the case of a fold-WL,
this means that those cells do not enter into the
reduction step. For a genarray, those cells are not in the result.
These all would not have any benefit until I get AVIS_MIN/MAX
passed in and out of LACFUNs.
2. Shape analysis within LACFUNs suffers, because AVIS_SHAPE
information is passed into a LACFUN as an N_id. This means that
useful information, such as (shape(vec)[0]) == (shape(mat)[0])
is lost. This cripples AWLF and some guard CF.
I don't know a good way to fix this. Perhaps AVIS_SHAPE should
be allowed to be an N_array of N_id nodes? I think that would work.
3. All of the above contribute to another problem: AWLF ends up slicing
cubes when it is not needed. Worse yet, it then fails to do
the folding on the sliced cube. Fixing this might be messy
for higher-dimensional cubes, but I'm not sure.
Suggestions and comments are very welcome.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1204if() going wrong way on (-2)^31, sometimes. UTDScalarI.sac2017-11-19T20:30:04ZRobert Berneckyif() going wrong way on (-2)^31, sometimes. UTDScalarI.sac| | |
| --- | --- |
| Bugzilla Link | [906](http://bugs.sac-home.org/show_bug.cgi?id=906) |
| Created on | Jan 19, 2012 17:20 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud3.sac](/uploads/fe2026c44652376...| | |
| --- | --- |
| Bugzilla Link | [906](http://bugs.sac-home.org/show_bug.cgi?id=906) |
| Created on | Jan 19, 2012 17:20 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud3.sac](/uploads/fe2026c446523768561bfe9c7fe66e68/crud3.sac), [xcrud3.sac](/uploads/c43922c6305edce3c5a787a858c2580e/xcrud3.sac) |
## Extended Description
<pre>Created an attachment (id=843)
source code to reproduce failure
The attached code is extracted from a failed apex unit test,
UTDScalarI.sac.
Depending on how (-2)^31 is generated, conditionals are
either true or false. This produces wrong answers, which
is not a good thing, IMO.
If you compile with -noinl, the answers change.
If you compile with -nocf, it crashes, this way:
**** Optimization cycle pass: 2
****** Optimizing regular function:
****** _MAIN::main( hidden(1), hidden(2), hidden(0)): ...
Applying common subexpression elimination ...
Inferring loop invariant variables ...
Applying type upgrade ...
ERROR: line 10 file: crud3.sac
ERROR: loop variable "_flat_28" is being used inconsistently in function
ERROR: _dup_262_mpyXII__Cond_2; conflicting types are bool{1} and #1352: in
ERROR: [ --, bool{0}] le <> ge <>
*** Compilation failed ***
*** Exit code 89 (Running SAC optimizations)
*** 1 Error(s), 0 Warning(s)
apex@rattler:~/apex2003/benchmks/UTDScalarI$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17723 linux-gnu_x86_64
(Fri Jan 13 16:39:25 EST 2012 by sac)
apex@rattler:~/apex2003/benchmks/UTDScalarI$ sac2c crud3.sac -v1 -nocf -nosaacyc -noive -v4</pre>Clemens GrelckClemens Grelckhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1235Livermore Loop 03,12,07 LACFUNs need AVIS_MIN and AVIS_MAX for AWLF2017-11-19T20:32:43ZRobert BerneckyLivermore Loop 03,12,07 LACFUNs need AVIS_MIN and AVIS_MAX for AWLF| | |
| --- | --- |
| Bugzilla Link | [905](http://bugs.sac-home.org/show_bug.cgi?id=905) |
| Created on | Jan 18, 2012 21:26 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>A number of the Liver...| | |
| --- | --- |
| Bugzilla Link | [905](http://bugs.sac-home.org/show_bug.cgi?id=905) |
| Created on | Jan 18, 2012 21:26 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>A number of the Livermore Loops and, presumably, lots of other codes,
fail to handle AWLF properly. Here is one reason why:
drop( [i], vec) - drop( [-i], vec)
This does not AWLF, because the drop() code is unable to ensure that:
G1: (i <= shape(vec)[0]) && ( (-i) <= shape(vec)[0])
I see two ways around this:
A. Introduce AVIS_MIN and AVIS_MAX into LACFUN headers, a la AVIS_DIM.
This will catch some of the failures, when the drop() code is
within a LACFUN, and vec is defined without an intervening
user-defined fun (which would lose AVIS_MIN).
B. Introduce guards into stdlib code to handle G1. This would work
in many circumstances, and would be CF'd out of existence in
case A.
I am going to beat up on IVEXI and make it do the job, unless
ISAA can be make to do it.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1107Livermore Loop09 ast corrupted by EBT at end of -bopt2017-11-19T20:22:32ZRobert BerneckyLivermore Loop09 ast corrupted by EBT at end of -bopt| | |
| --- | --- |
| Bugzilla Link | [904](http://bugs.sac-home.org/show_bug.cgi?id=904) |
| Created on | Jan 17, 2012 16:53 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/7c6ba4ff06b4bc7c...| | |
| --- | --- |
| Bugzilla Link | [904](http://bugs.sac-home.org/show_bug.cgi?id=904) |
| Created on | Jan 17, 2012 16:53 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/7c6ba4ff06b4bc7cc2fbcfa933e8a452/crud.sac) |
## Extended Description
<pre>Created an attachment (id=842)
source code to reproduce failure
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17723 linux-gnu_x86_64
(Fri Jan 13 16:39:25 EST 2012 by sac)
sac@rattler:~/sac/demos/benchmarks/livermore_loops/for_comparison/loop09$ sac2c crud.sac -bopt:ebt -d treecheck -chkfreq 4 -v1 -nosaacyc -noive >crud
The failure mode is this:
If left to itself, things crash in: IVESLIdoIVESplitLoopInvariants,
with:
tree/infer_dfms.c:312 Assertion "N_avis == NODE_TYPE(avis)" failed!
avis expected
However, -bopt:ebt shows that the damage has occurred much earlier.
The bug appeared with the rewrite of vecmatmul, as follows:
inline double[N] vecmatmul( double[25] wts, double[N,25] PX)
{
colsx = shape(wts)[0];
colsy = shape(PX)[dim(PX)-1];
z = genarray([colsy], 0.0d);
for (colx=0; colx<colsx; colx++) {
if (0.0 != wts[colx]) { /* Skip iteration if it's an f identity */
z = z + wts[colx] * PX[colx];
}
}
return(z);
}</pre>BugZillaBugZilla