sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T21:59:07Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2112IVE in SSACYC gets Cond-fun confused when -nocf2017-11-19T21:59:07ZRobert BerneckyIVE in SSACYC gets Cond-fun confused when -nocf| | |
| --- | --- |
| Bugzilla Link | [872](http://bugs.sac-home.org/show_bug.cgi?id=872) |
| Created on | Sep 08, 2011 23:41 |
| Resolution | DUPLICATE |
| Resolved on | Oct 10, 2011 18:39 |
| Version | svn |
| OS | Linux |
| Architec...| | |
| --- | --- |
| Bugzilla Link | [872](http://bugs.sac-home.org/show_bug.cgi?id=872) |
| Created on | Sep 08, 2011 23:41 |
| Resolution | DUPLICATE |
| Resolved on | Oct 10, 2011 18:39 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [funny.sac](/uploads/36df31ef7bb8e82965d5b65c991d90a5/funny.sac) |
## Extended Description
<pre>Created an attachment (id=819)
source code to reproduce failure
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17609:MODIFIED linux-gnu_x86_64
(Thu Sep 8 17:11:09 EDT 2011 by sac)
sac2c -nocf funny.sac -nocyc
**** Symbolic array attribute cycle 2 pass: 1
****** Optimizing regular function:
****** _MAIN::main( ): ...
Inserting symbolic array attributes ...
Eliminating index vectors (split selections) ...
Eliminating common subexpressions ...
Inferring loop invariant variables ...
Applying type upgrade ...
ERROR: line 32 file: funny.sac
ERROR: loop variable "_isaa_1428_X" is being used inconsistently in function
ERROR: _dup_1280_indsx1__Cond_3; conflicting types are int[.] and #2174: in
ERROR: [ --, int[2]] le <> ge <>
In Cond_3, _isaa_1428_X is int[.]. In the calling environment, it is
int[.].
To be continued...</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2111TC appears to be confused about constant-valued CONDfun in SCSprf_idx_sel3.sac2017-11-19T21:59:00ZRobert BerneckyTC appears to be confused about constant-valued CONDfun in SCSprf_idx_sel3.sac| | |
| --- | --- |
| Bugzilla Link | [864](http://bugs.sac-home.org/show_bug.cgi?id=864) |
| Created on | Aug 28, 2011 20:12 |
| Resolution | FIXED |
| Resolved on | Oct 10, 2011 18:48 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [864](http://bugs.sac-home.org/show_bug.cgi?id=864) |
| Created on | Aug 28, 2011 20:12 |
| Resolution | FIXED |
| Resolved on | Oct 10, 2011 18:48 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCSprf_idx_sel3.sac](/uploads/bba26851a37f0c4ed7725aee52282060/SCSprf_idx_sel3.sac) |
## Extended Description
<pre>Created an attachment (id=815)
source code to reproduce failure
Summary says it all; failure in CF unit test, when testing with CF disabled:
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17576:MODIFIED linux-gnu_x86_64
(Sun Aug 28 13:47:43 EDT 2011 by sac)
cd :~/sac/testsuite/optimizations/constantfolding
sac2c SCSprf_idx_sel3.sac -nocf
ERROR: line 165 file: sacprelude.sac
ERROR: loop variable "p" is being used inconsistently in function
ERROR: _dup_112_partitionMax__Cond_0; conflicting types are bool and #481:
ERROR: in [ --, bool{0}] le <> ge <>
What is interesting here is that the entire function is constants:
/****************************************************************************
* Cond function of _MAIN::main(...):
* sacprelude::_dup_112_partitionMax__Cond_0(...) [ body ]
****************************************************************************/
int{2} sacprelude::_dup_112_partitionMax__Cond_0( bool{0} p { dim: 0, shape: [:int],NN } , int{2} y { dim: 0, shape: [:int],NN } , int{0} x { dim: 0, shape: [:int],NN } )
/*
* _dup_112_partitionMax__Cond_0 :: ---
*/
{
int{2} _hce_0__SSA0_2 { dim: 0, shape: [:int], NN } ;
if (p)
{
}
else
{
}
_hce_0__SSA0_2 = ( p ? x : y );
return( _hce_0__SSA0_2);
}</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2110ICC gets confused across WLs when inserting guards2017-11-19T21:58:54ZRobert BerneckyICC gets confused across WLs when inserting guards| | |
| --- | --- |
| Bugzilla Link | [863](http://bugs.sac-home.org/show_bug.cgi?id=863) |
| Created on | Aug 26, 2011 17:30 |
| Resolution | FIXED |
| Resolved on | Oct 10, 2011 22:24 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [863](http://bugs.sac-home.org/show_bug.cgi?id=863) |
| Created on | Aug 26, 2011 17:30 |
| Resolution | FIXED |
| Resolved on | Oct 10, 2011 22:24 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCCFprf_sel5.sac](/uploads/e813f6c9f6ea696d5d5744d2b6f28be2/SCCFprf_sel5.sac) |
## Extended Description
<pre>Created an attachment (id=814)
source code to reproduce failure
In the following unit test, a guard result, located
within a WL, is used as a guard argument within a subsequent
WL, even though the result should be out of scope for
any reference outside the first WL.
cd ~/sac/testsuite/optimizations/constantfolding
sac2c SCCFprf_sel5.sac -ecc -bcwc:icc >crud
Some extracts from crud's main():
In first WL ( _icc_53):
_idc_95, _idc_96, _icc_52_pred = _same_shape_AxA_( _flat_5, _flat_1);
In second WL ( _icc_66):
_idc_100, _idc_101, _icc_65_pred = _same_shape_AxA_( _flat_10, _idc_96);
Note the reference to _idc_96 in second WL!
This causes MANY failures in the CF unit test suite! It also
cripples AWLF (via crashes) in many cases, because AWLF
is reliant on -ecc being enabled.
This fails on:
sac2c v1.00-beta (Haggis And Apple)
developer rev 17572:MODIFIED linux-gnu_x86_64
(Fri Aug 26 11:36:11 EDT 2011 by sac)</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2109compiler crashed: compiling aes.sac in masterrun2017-11-19T21:58:47ZNilesh Karavadaracompiler crashed: compiling aes.sac in masterrun| | |
| --- | --- |
| Bugzilla Link | [845](http://bugs.sac-home.org/show_bug.cgi?id=845) |
| Created on | May 30, 2011 14:39 |
| Resolution | FIXED |
| Resolved on | Oct 11, 2011 09:54 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [845](http://bugs.sac-home.org/show_bug.cgi?id=845) |
| Created on | May 30, 2011 14:39 |
| Resolution | FIXED |
| Resolved on | Oct 11, 2011 09:54 |
| Version | svn |
| OS | Linux |
| Architecture | HP |
## Extended Description
<pre>/**********************************************************************
*
* SAC bug report: aes.sacbugreport
*
**********************************************************************
*
* Automatically generated on Mon May 30 14:16:06 BST 2011
*
* using sac2c v1.00-beta (Haggis And Apple) rev 17415 for linux-gnu_i686
* built Sat May 28 20:36:18 BST 2011.
* by user nkk on host obelix.stca.herts.ac.uk for linux-gnu.
*
* The compiler was called by
* sac2c -o aes aes.sac
*
* The compiler crashed in
* phase: opt (Running SAC optimizations)
* sub phase: vp (Propagating variables)
*
*
**********************************************************************/
Stdlib: 1521</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2108PM module fails on functions with more than one return value2017-11-19T21:58:41ZSven-Bodo ScholzPM module fails on functions with more than one return value| | |
| --- | --- |
| Bugzilla Link | [843](http://bugs.sac-home.org/show_bug.cgi?id=843) |
| Created on | Apr 26, 2011 14:01 |
| Resolution | FIXED |
| Resolved on | Apr 26, 2011 14:08 |
| Version | svn |
| OS | All |
| Architecture |...| | |
| --- | --- |
| Bugzilla Link | [843](http://bugs.sac-home.org/show_bug.cgi?id=843) |
| Created on | Apr 26, 2011 14:01 |
| Resolution | FIXED |
| Resolved on | Apr 26, 2011 14:08 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [kernel.sac](/uploads/98837321300e502a1cfc31a8c7190467/kernel.sac) |
## Extended Description
<pre>Created an attachment (id=801)
source code
This is a hair-raising bug that stems from the way implicit expression flattening is being implemented.
Compiling the attached code in rev 17384 leads to:
-sbs-idefix2-> sac2c kernel.sac
ABORT: line 119 file: ArrayArith.sac
ABORT: SCSprf_div_XxS: Division by zero encountered
*** Compilation failed ***
*** Exit code 89 (Running SAC optimizations)
*** 1 Error(s), 0 Warning(s)</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2107Corrupt tree after wrongly striping out variables of type bottom2017-11-19T21:58:36ZDaniel RollsCorrupt tree after wrongly striping out variables of type bottom| | |
| --- | --- |
| Bugzilla Link | [831](http://bugs.sac-home.org/show_bug.cgi?id=831) |
| Created on | Mar 08, 2011 14:14 |
| Resolution | FIXED |
| Resolved on | Oct 11, 2011 09:29 |
| Version | svn |
| OS | All |
| Architecture |...| | |
| --- | --- |
| Bugzilla Link | [831](http://bugs.sac-home.org/show_bug.cgi?id=831) |
| Created on | Mar 08, 2011 14:14 |
| Resolution | FIXED |
| Resolved on | Oct 11, 2011 09:29 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [831.sac](/uploads/74897eadcd0903445abe6616b1570807/831.sac) |
## Extended Description
<pre>This failure can be seen in axis_control_rev_cat.sac. See any recent Masterrun.
The following summary is from Stephan and lazily pasted from an email:
I have looked at axis_control_rev_cat.sac. The problem there seems to be
with the type checker. We end up in a situation where after opt:tup2 [type upgrade] return values of main become bottom, however the return type of main does not. Thus, compilation is not aborted. Instead, all bottom variables are stripped out, including the return value. This leads to a corrupted tree.
On the one hand, one should never just strip away a vardec node without
checking its use. On the other hand, if a bottom vardec node would
contribute directly to the result of a function, then that entire function
should have been marked as bottom.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2106NAS FT with complex numbers fails in type system2021-05-27T14:09:53ZClemens GrelckNAS FT with complex numbers fails in type system| | |
| --- | --- |
| Bugzilla Link | [826](http://bugs.sac-home.org/show_bug.cgi?id=826) |
| Created on | Feb 17, 2011 09:48 |
| Resolution | DUPLICATE |
| Resolved on | Oct 13, 2011 16:14 |
| Version | svn |
| OS | Linux |
| Architec...| | |
| --- | --- |
| Bugzilla Link | [826](http://bugs.sac-home.org/show_bug.cgi?id=826) |
| Created on | Feb 17, 2011 09:48 |
| Resolution | DUPLICATE |
| Resolved on | Oct 13, 2011 16:14 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [x826.sac](/uploads/d072a2e3d93200a5e37c493cd917a3b8/x826.sac), [826.sac](/uploads/e86730c264500fb1d8566faa6a713fda/826.sac) |
## Extended Description
<pre>sac2c fft_cpx.sac
(in sac/demos/nas_parallel_benchmarks/FT)
fails with
** 10: Creating Wrapper Code and Eliminating User-Defined Types ...
**** Creating Wrapper Bodies ...
**** Eliminating conditionals in wrapper code ...
**** Establishing static single assignment form in wrapper code ...
**** Trying to dispatch functions statically ...
**** Removing all structs ...
**** Eliminating User-Defined Types ...
ASSERTION FAILED: file 'typecheck/elim_alpha_types.c', line 456
new element type of array does not match old type!
EXECUTION TERMINATED
Aborted</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2105Intermittent failures in scanparse2017-11-19T21:58:23ZDaniel RollsIntermittent failures in scanparse| | |
| --- | --- |
| Bugzilla Link | [788](http://bugs.sac-home.org/show_bug.cgi?id=788) |
| Created on | Nov 30, 2010 11:23 |
| Resolution | FIXED |
| Resolved on | Feb 02, 2011 16:08 |
| Version | svn |
| OS | All |
| Architecture |...| | |
| --- | --- |
| Bugzilla Link | [788](http://bugs.sac-home.org/show_bug.cgi?id=788) |
| Created on | Nov 30, 2010 11:23 |
| Resolution | FIXED |
| Resolved on | Feb 02, 2011 16:08 |
| Version | svn |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>The following error is from a clustix masterrun (HEAD:HEAD:1398)
scanparse/sac.tab.h:37:1: error: unterminated #ifndef
scanparse/sac.tab.h:37:1: error: unterminated #ifndef
scanparse/sac.tab.h:37:1: error: unterminated #ifndef
scanparse/sac.tab.h:37:1: error: unterminated #ifndef
scanparse/sac.tab.h:37:1: error: unterminated #ifndef
scanparse/sac.tab.h:37:1: error: unterminated #ifndef
scanparse/sac.tab.h:37:1: error: unterminated #ifndef
global/resource.c:88: error: expected identifier before ‘static’
make[6]: *** [global/resource.p.o] Error 1
make[5]: *** [make_prod] Error 2
make[4]: *** [prod] Error 2
We've seen similar errors from the scanner/parser on Gutemine and Asterix. The makefile is run with "-j" so this could be a missing dependency in the Makefile somewhere.
The file sac.tab.h is generated by Bison so it may be being read before bison has finished writing to the file?</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2104mandelbrot in tutorials/L8 suffers from UDT loss of precision problem2021-05-27T14:09:01ZSven-Bodo Scholzmandelbrot in tutorials/L8 suffers from UDT loss of precision problem| | |
| --- | --- |
| Bugzilla Link | [784](http://bugs.sac-home.org/show_bug.cgi?id=784) |
| Created on | Nov 30, 2010 06:26 |
| Resolution | DUPLICATE |
| Resolved on | Oct 11, 2011 19:54 |
| Version | svn |
| OS | All |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [784](http://bugs.sac-home.org/show_bug.cgi?id=784) |
| Created on | Nov 30, 2010 06:26 |
| Resolution | DUPLICATE |
| Resolved on | Oct 11, 2011 19:54 |
| Version | svn |
| OS | All |
| Architecture | PC |
| Attachments | [mandelbrot_sbs2.sac](/uploads/121eb78ff1e420011ea02ad9a09c4b62/mandelbrot_sbs2.sac) |
## Extended Description
<pre>check sac2c -t cuda mandelbrot.sac -DTIER=1
in sac/tutorial/L8_case-study_mandelbrot
yields segfault using sac2c rev 17212 and sac rev 1406</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2103IVE leaves broken syntax tree2017-11-19T21:58:12ZClemens GrelckIVE leaves broken syntax tree| | |
| --- | --- |
| Bugzilla Link | [775](http://bugs.sac-home.org/show_bug.cgi?id=775) |
| Created on | Nov 17, 2010 17:17 |
| Resolution | FIXED |
| Resolved on | Jan 25, 2011 04:34 |
| Version | svn |
| OS | All |
| Architecture |...| | |
| --- | --- |
| Bugzilla Link | [775](http://bugs.sac-home.org/show_bug.cgi?id=775) |
| Created on | Nov 17, 2010 17:17 |
| Resolution | FIXED |
| Resolved on | Jan 25, 2011 04:34 |
| Version | svn |
| OS | All |
| Architecture | All |
| Attachments | [SCCFprf_modarray1.sac](/uploads/6637dfecf2a1573e66e9b07c6c5b83ea/SCCFprf_modarray1.sac) |
## Extended Description
<pre>sac2c segfaults in Variable Propagation when compiling the attached code from the testsuite. Reason is a broken syntax tree left by IVE as properly detected using the treecheck facility:
**** Generating full with-loop partitions ...
**** Inferencing with-loop reuse candidates ...
**** Annotating offset variable at with-loops ...
**** Eliminating index vectors (split selections) ...
**** Eliminating index vectors (split loop invariants) ...
WARNING: mandatory son LET_EXPR is NULL
**** Propagating variables (for IVE) ...
OOOOOOOPS, your program crashed the compiler 8-((</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2102Mother Earth doesn't like the G20, either2017-11-19T21:58:05ZRobert BerneckyMother Earth doesn't like the G20, either| | |
| --- | --- |
| Bugzilla Link | [729](http://bugs.sac-home.org/show_bug.cgi?id=729) |
| Created on | Jun 23, 2010 19:06 |
| Resolution | FIXED |
| Resolved on | Jun 23, 2010 19:07 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [729](http://bugs.sac-home.org/show_bug.cgi?id=729) |
| Created on | Jun 23, 2010 19:06 |
| Resolution | FIXED |
| Resolved on | Jun 23, 2010 19:07 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
At 13:44EDT, rattler.snakeisland.com was rattling, as
was the galactic headquarters of Snake Island Research Inc.
The cause was traced to an earthquake that hit eastern Canada,
including Toronto and Ottawa.
Compiler development was interrupted briefly.Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2101WLPG generates wrong vardec type2017-11-19T21:58:00ZRobert BerneckyWLPG generates wrong vardec type| | |
| --- | --- |
| Bugzilla Link | [698](http://bugs.sac-home.org/show_bug.cgi?id=698) |
| Created on | Apr 18, 2010 21:08 |
| Resolution | FIXED |
| Resolved on | Oct 13, 2011 18:36 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [698](http://bugs.sac-home.org/show_bug.cgi?id=698) |
| Created on | Apr 18, 2010 21:08 |
| Resolution | FIXED |
| Resolved on | Oct 13, 2011 18:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>If I compile the following code with these options, PINL generates bum
vardec for axis:
PINLavis: PINL: renaming _wlpg_27_axis to _pinl_47__wlpg_27_axis
PINLavis: PINL: renaming _pinl_47__wlpg_27_axis to _pinl_68__wlpg_27_axis
int[.], int[.], int[.], int[.] sacprelude::partitionSlicer( int[.] min { } , int[.] max { } , int axis { } , int[.] lb { } , int[.] ub { } )
external int[.], int[.], int[.], int[.] sacprelude::partitionSlicer( int[*] min { } , int[*] max { } , int[*] axis { } , int[*] lb { } , int[*] ub { } )
int[1] _pinl_68__wlpg_27_axis { } ;
_pinl_68__wlpg_27_axis = 0;
Note that the latter variable is an int, but is declared int[1].
sac2c inlbug.sac -v1 -nocyc -b11:inl -nocf -noprelude -#d,PINL &>crud
inlbug.sac is:
use Array : {iota,-};
inline int[.] lltopXII(int n )
{
z=iota( n);
return(z);
}
int main()
{
A_60=lltopXII( 40000);
StdIO::print(_sel_VxA_( [23], A_60));
return(0);
}
This version of sac2c on obelix:
sac2c v1.00-beta (Haggis And Apple)
developer rev 16794:MODIFIED linux-gnu_i686
I stumbled onto this one while fault-isolating a few others.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2100WLTR grumps about empty WL iteration space when compiled with -noopt2017-11-19T21:57:54ZRobert BerneckyWLTR grumps about empty WL iteration space when compiled with -noopt| | |
| --- | --- |
| Bugzilla Link | [696](http://bugs.sac-home.org/show_bug.cgi?id=696) |
| Created on | Apr 16, 2010 17:57 |
| Resolution | FIXED |
| Resolved on | Jul 15, 2010 08:40 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [696](http://bugs.sac-home.org/show_bug.cgi?id=696) |
| Created on | Apr 16, 2010 17:57 |
| Resolution | FIXED |
| Resolved on | Jul 15, 2010 08:40 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/1c324e4844a3363375d763695083cfc5/crud.sac) |
## Extended Description
<pre>Created an attachment (id=687)
source code to reproduce fault
The attached dies this way when compiled with:
sac2c -noopt -noprelude lltoploop.sac
ASSERTION FAILED: file 'wltransform/wltransform.c', line 7227
with-loop with empty iteration space found!
The WL's iteration space is [:int], so it would normally be
removed, as being degenerate. However, with -noopt, it stays around
until WLTR trips over it.
Build: developer rev 16794 linux-gnu_i686
Assigned to sbs, as he seems to be Mr. Empty-WL remover of late.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2099new type inference problem on sac/apex/tjckrbe/tjckrbe.sac and others2017-11-19T21:57:48ZRobert Berneckynew type inference problem on sac/apex/tjckrbe/tjckrbe.sac and others| | |
| --- | --- |
| Bugzilla Link | [653](http://bugs.sac-home.org/show_bug.cgi?id=653) |
| Created on | Jan 07, 2010 17:34 |
| Resolution | FIXED |
| Resolved on | May 06, 2010 19:39 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [653](http://bugs.sac-home.org/show_bug.cgi?id=653) |
| Created on | Jan 07, 2010 17:34 |
| Resolution | FIXED |
| Resolved on | May 06, 2010 19:39 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [tjkcrbe.sac](/uploads/78dafdf2bdc3fc93344bf755c9b38e00/tjkcrbe.sac), [tjckrbe.sac](/uploads/7fa63239fafa366561b0dcf2b70f19da/tjckrbe.sac) |
## Extended Description
<pre>Created an attachment (id=646)
Source code to cause crash
** 6: Running type inference system ...
**** Enforcing Specializations ...
**** Running type inference system ...
ABORT: line 355 file: tjckrbe.sac
ABORT: No definition found for a function "_MAIN::plusDDD" that accepts an
ABORT: argument of type "double" as parameter no 1. Full argument types are
ABORT: "( double, double[*])".
I think this is failure appeared recently.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2098WLS fails on simple codes, e.g., ktr.sac2017-11-19T21:57:41ZRobert BerneckyWLS fails on simple codes, e.g., ktr.sac| | |
| --- | --- |
| Bugzilla Link | [646](http://bugs.sac-home.org/show_bug.cgi?id=646) |
| Created on | Dec 30, 2009 22:14 |
| Resolution | FIXED |
| Resolved on | Jan 03, 2010 21:46 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [646](http://bugs.sac-home.org/show_bug.cgi?id=646) |
| Created on | Dec 30, 2009 22:14 |
| Resolution | FIXED |
| Resolved on | Jan 03, 2010 21:46 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/5f5adcbef2c341d473cea62eac429f63/crud.sac) |
## Extended Description
<pre>Build #16697 fails to perform WLS on this code (and many others):
int main()
{
A = with {
(. <= iv=[i] <= .) {
B = with {
(. <= jv=[j] <= .) {
VAL = _add_SxS_( i, _mul_SxS_( 2, j));
} : VAL;
} : genarray([4], 42);
} : B;
} : genarray([4], [10,20,30,40]);
StdIO::print(A);
return(0);
}
sac2c -d#,WLS gives this:
with {
(_flat_2 <= iv=[i] < _flat_5 genwidth [ _wlsimp_115 ])
{
B = with {
(_flat_2 <= jv=[j] < _flat_5 genwidth [ _wlsimp_116 ])
{
_flat_12 = _mul_SxS_( _flat_13, j);
VAL = _add_SxS_( i, _flat_12);
} : VAL ;
} :
genarray( _flat_5, _flat_7);
} : B ;
} :
genarray( _flat_5, _flat_1)
-----------------------------------------------
WLSCdoCheck: WLS: A: Checking whether with-loop can be scalarized.
WLSCwith: WLS: A: Outer with-loop has no full partition
WLSCdoCheck: WLS: A: With-loop cannot be scalarized.
I'm looking into it now, to see if there's a simple fix.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2097WLPG introduces duplicate partition2017-11-19T21:57:34ZRobert BerneckyWLPG introduces duplicate partition| | |
| --- | --- |
| Bugzilla Link | [611](http://bugs.sac-home.org/show_bug.cgi?id=611) |
| Created on | Nov 26, 2009 23:28 |
| Resolution | INVALID |
| Resolved on | Nov 30, 2009 20:29 |
| Version | svn |
| OS | Linux |
| Architectu...| | |
| --- | --- |
| Bugzilla Link | [611](http://bugs.sac-home.org/show_bug.cgi?id=611) |
| Created on | Nov 26, 2009 23:28 |
| Resolution | INVALID |
| Resolved on | Nov 30, 2009 20:29 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [emptycodeblock.sac](/uploads/25756ebbb422fdff1a8789e0780cf4a0/emptycodeblock.sac) |
## Extended Description
<pre>Created an attachment (id=615)
Source code to reproduce fault
The attached produces what looks to me like a 3-partition WL for
rotate() with Build # developer rev 16638, when compiled with:
sac2c emptycodeblock.sac -b11 >crud
Specifically, I see that the second WL looks like this:
_pinl_679_result = with {
(_pinl_731__wlbsc_512_sc_bound <= _pinl_676_iv=[_pinl_692__eat_31] (IDXS:_wlidx_1665__pinl_679_result) < _pinl_540__flat_5)
{
_ivesplit_1674 = _wlidx_1665__pinl_679_result;
_pinl_950__flat_134 = _idx_sel_( _ivesplit_1674, XXX);
} : _pinl_950__flat_134 ; ,
(_pinl_548__wlpg_366_zeros <= _pinl_676_iv=[_pinl_692__eat_31] (IDXS:_wlidx_1665__pinl_679_result) < _pinl_740__wlbsc_521_sc_bound)
{
_ivesplit_1674 = _wlidx_1665__pinl_679_result;
_pinl_950__flat_134 = _idx_sel_( _ivesplit_1674, XXX);
} : _pinl_950__flat_134 ; ,
(_pinl_740__wlbsc_521_sc_bound <= _pinl_676_iv=[_pinl_692__eat_31] (IDXS:_wlidx_1665__pinl_679_result) < _pinl_540__flat_5)
{
_pinl_753__flat_1123 = _sub_SxS_( _pinl_692__eat_31, _pinl_689_count__SSA0_3);
_ivesplit_1673 = _pinl_753__flat_1123;
_pinl_678__flat_16 = _idx_sel_( _ivesplit_1673, XXX);
} : _pinl_678__flat_16 ;
} :
modarray( XXX ,IDX(_wlidx_1665__pinl_679_result));
If I'm reading that right, we have these partition bounds:
r = rotatecount;
N = array shape
P0: [ max(0, r) ] --> [ N]
P1: [ 0 ] --> [ r ]
P2: [ r ] --> [ N ]</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2096WLF non-effective in non-trivial case2017-11-19T21:57:28ZClemens GrelckWLF non-effective in non-trivial case| | |
| --- | --- |
| Bugzilla Link | [607](http://bugs.sac-home.org/show_bug.cgi?id=607) |
| Created on | Nov 25, 2009 18:29 |
| Resolution | FIXED |
| Resolved on | Oct 20, 2010 15:50 |
| Version | svn |
| OS | All |
| Architecture |...| | |
| --- | --- |
| Bugzilla Link | [607](http://bugs.sac-home.org/show_bug.cgi?id=607) |
| Created on | Nov 25, 2009 18:29 |
| Resolution | FIXED |
| Resolved on | Oct 20, 2010 15:50 |
| Version | svn |
| OS | All |
| Architecture | All |
| Attachments | [bug22.sac](/uploads/f02cb7d157842dbf4d5bc6c19d041682/bug22.sac) |
## Extended Description
<pre>Created an attachment (id=613)
code to reproduce failure
After the DevCamp revamp of the flattening status of with-loop generator
expressions, WLF is no longer effective in folding the 3 with-loops in the
attached code, which it was before the latest changes.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2095Explicit specialisation rejected on complex2017-11-19T21:57:22ZFrank PenczekExplicit specialisation rejected on complex| | |
| --- | --- |
| Bugzilla Link | [595](http://bugs.sac-home.org/show_bug.cgi?id=595) |
| Created on | Nov 14, 2009 17:23 |
| Resolution | FIXED |
| Resolved on | Nov 17, 2009 21:21 |
| Version | 1.00beta |
| OS | All |
| Architect...| | |
| --- | --- |
| Bugzilla Link | [595](http://bugs.sac-home.org/show_bug.cgi?id=595) |
| Created on | Nov 14, 2009 17:23 |
| Resolution | FIXED |
| Resolved on | Nov 17, 2009 21:21 |
| Version | 1.00beta |
| OS | All |
| Architecture | PC |
| Attachments | [specbug.tar.gz](/uploads/863bc79871b7c472aceab529d5785ecc/specbug.tar.gz), [tutu2.sac](/uploads/730131f538c18c19b75b67f0ffb5cdcf/tutu2.sac) |
## Extended Description
<pre>Created an attachment (id=603)
Source code to reproduce behaviour (archive contains both modules)
sac2c rev. 16550
The following code leads to an "inferred types out of bounds" error:
---
module Star;
use Structures : all;
export all;
complex[*] star( complex[*] input)
{
res = genarray( shape( input), toc( 0.0d));
return( res);
}
---
---
module Spec;
use Structures : all;
import Star: all;
export all;
specialize complex[.,.,.] star( complex[3,3,3] input);
---
sac2c Star.sac; sac2c Spec.sac leads to:
[...]
** 6: Running type inference system ...
**** Enforcing Specializations ...
**** Running type inference system ...
ABORT: line 6 file: Star.sac
ABORT: Component #0 of inferred return type (ComplexBasics::complex[*]) is
ABORT: not within #18: in [ --, Structures::complex[.,.,.]] le < 0> ge <></pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2094Inferred type not within bounds2017-11-19T21:57:15ZFrank PenczekInferred type not within bounds| | |
| --- | --- |
| Bugzilla Link | [556](http://bugs.sac-home.org/show_bug.cgi?id=556) |
| Created on | Aug 20, 2009 16:51 |
| Resolution | FIXED |
| Resolved on | Nov 18, 2009 04:12 |
| Version | 1.00beta |
| OS | All |
| Architect...| | |
| --- | --- |
| Bugzilla Link | [556](http://bugs.sac-home.org/show_bug.cgi?id=556) |
| Created on | Aug 20, 2009 16:51 |
| Resolution | FIXED |
| Resolved on | Nov 18, 2009 04:12 |
| Version | 1.00beta |
| OS | All |
| Architecture | PC |
| Attachments | [tmp.sac](/uploads/d44a8ff069c44b12b52f0bfaab8b04a3/tmp.sac), [bug556_tiny.sac](/uploads/c0623e3c7f1cef0b3690e6d62dae7f4a/bug556_tiny.sac) |
## Extended Description
<pre>Created an attachment (id=561)
Source code to reproduce behaviour
Using rev16340 of sac2c, compilation of the following program aborts reporting an error about inferred types being out of bounds:
---
module badbounds;
use Structures : all;
use Numerical : all;
export {badbounds};
complex[.,.,.,.] badbounds( complex[.,.,.] input)
{
result =
with
{
( [0,0,0,0] <= [i,j,k,l] < [1,1,1,1]) : input[0,0,0];
} : genarray( [1,1,1,1], toc(0,0));
return( result);
}
---
The (clipped) compiler output reads:
---
[...]
**** Optimization cycle pass: 3
****** Optimizing wrapper function:
****** bounds::bounds( double[+]): ...
****** Optimizing wrapper function:
****** bounds:Structures::sel( int[*], double[+]): ...
****** Optimizing regular function:
****** bounds::bounds( double[.,.,.,.]): ...
****** Optimizing regular function:
****** ComplexArrayBasics::sel( int[.], double[+]): ...
****** Optimizing regular function:
****** ComplexArrayBasics::sel( int, double[+]): ...
****** Optimizing regular function:
****** sacprelude::eq( int[*], int[*]): ...
****** Optimizing regular function:
****** sacprelude::eq( float[*], float[*]): ...
****** Optimizing regular function:
****** sacprelude::eq( double[*], double[*]): ...
****** Optimizing regular function:
****** sacprelude::eq( bool[*], bool[*]): ...
****** Optimizing regular function:
****** sacprelude::eq( char[*], char[*]): ...
****** Optimizing regular function:
****** bounds:ComplexArrayBasics::shape( double[.,.,.,.]): ...
****** Optimizing regular function:
****** bounds:Structures::sel( int[3], double[.,.,.,.]): ...
ABORT: line 62 file: ComplexArrayBasics.sac
ABORT: Component #0 of inferred return type (double[.]) is not within
#380:
ABORT: in [ --, double[2]] le <> ge <>
*** Compilation failed ***
*** Exit code 73 (Running SAC optimizations)
*** 1 Error(s), 1 Warning(s)
---</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2093tvd2d.sac dies in type upgrade2017-11-19T21:57:09ZClemens Grelcktvd2d.sac dies in type upgrade| | |
| --- | --- |
| Bugzilla Link | [543](http://bugs.sac-home.org/show_bug.cgi?id=543) |
| Created on | Aug 05, 2009 23:50 |
| Resolution | FIXED |
| Resolved on | Oct 13, 2011 16:09 |
| Version | 1.00beta |
| OS | Linux |
| Archite...| | |
| --- | --- |
| Bugzilla Link | [543](http://bugs.sac-home.org/show_bug.cgi?id=543) |
| Created on | Aug 05, 2009 23:50 |
| Resolution | FIXED |
| Resolved on | Oct 13, 2011 16:09 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.breaks.sac](/uploads/580d5857467141ba7d94ea8a6f37521e/crud.breaks.sac) |
## Extended Description
<pre>compiler says:
****** Optimizing regular function:
****** _MAIN::xmuscl2( double[+], double, double, int, int): ...
Applying common subexpression elimination ...
Inferring loop invariant variables ...
Applying type upgrade ...
ERROR: line 174 file: tvd2d.sac
ERROR: loop variable "b" is being used inconsistently; conflicting types are
ERROR: double[*] and #47720: in [ --, double] le <> ge <>
*** Compilation failed ***
*** Exit code 73 (Running SAC optimizations)
*** 1 Error(s), 0 Warning(s)
cg@milos:~/sac/test> sac2c -V
sac2c v1.00-beta (Buchette d'Anjou)
developer rev 16290 linux-gnu_i686
(Wed Aug 5 23:16:08 CEST 2009 by cg)</pre>Sven-Bodo ScholzSven-Bodo Scholz