sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T20:36:20Zhttps://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/1293rc cases descriptor to be freed2017-11-19T20:36:15ZCarl Joslinrc cases descriptor to be freed| | |
| --- | --- |
| Bugzilla Link | [582](http://bugs.sac-home.org/show_bug.cgi?id=582) |
| Created on | Oct 29, 2009 11:37 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug582.sac](/uploads/0005ad76e...| | |
| --- | --- |
| Bugzilla Link | [582](http://bugs.sac-home.org/show_bug.cgi?id=582) |
| Created on | Oct 29, 2009 11:37 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug582.sac](/uploads/0005ad76eed54073a7bb73ad1b58e33f/bug582.sac), [bunzip2.sac](/uploads/9420e3b3a08d5a598c1963d09b9e7e43/bunzip2.sac) |
## Extended Description
<pre>The attached code produces the function:
SACf__MAIN__decode__i_488__i
this function passes a pointer to an uninitialised descriptor and array to the function:
SACf__MAIN__get_bits__i_488__i__i
for use as the return value.
SACf__MAIN__get_bits__i_488__i__i seems to create the needed descriptor and array and passes them to:
SACf__MAIN__compare__i_X__i_6
The first time it does this every thing seems fine the rc goes up and back down however when it calls:
SACf__MAIN__compare__i_X__i_6
the second time it just goes down and not up.
As a result the descripter is freeded and there for not returned by:
SACf__MAIN__get_bits__i_488__i__i
and then when SACf__MAIN__decode__i_488__i uses the memory the program segfalts.</pre>Carl JoslinCarl Joslinhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1292AINL changes mark main() and other user-defined fns as "inline"2017-11-19T20:36:09ZRobert BerneckyAINL changes mark main() and other user-defined fns as "inline"| | |
| --- | --- |
| Bugzilla Link | [1174](http://bugs.sac-home.org/show_bug.cgi?id=1174) |
| Created on | Nov 23, 2015 21:13 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Recent changes to A...| | |
| --- | --- |
| Bugzilla Link | [1174](http://bugs.sac-home.org/show_bug.cgi?id=1174) |
| Created on | Nov 23, 2015 21:13 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Recent changes to AINL result in over-exuberant inlining directives
being inserted for user-defined functions.
E.g.:
sac2c SCSprf_reshape.sac -v1 -bopt:cyc:ainl:1 >crud.ainl1
sac@rattler:~/sac/testsuite/optimizations/constantfolding$ vi crud.ainl1
sac@rattler:~/sac/testsuite/optimizations/constantfolding$
sac@rattler:~/sac/testsuite/optimizations/constantfolding$ sac2c SCSprf_reshape.sac -v1 -bopt:cyc:cse:1 >crud.cse1
sac@rattler:~/sac/testsuite/optimizations/constantfolding$ vi crud.cse1
sac@rattler:~/sac/testsuite/optimizations/constantfolding$ diff crud.cse1 crud.ainl1
1325a1326
> inline
5289a5291
> inline
The new inline directives are for main() and id(), neither of which
should be inlined.
sac2c -V
sac2c 1.2.beta-BlackForest-89-fd249
developer
(Mon Nov 23 11:48:14 EST 2015 by sac)
The above resulted in 91 grep failures for the CF unit test suite, far more
than we should see there.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1291masterrun dies in SCCFprf_modarray1/2 w/production compiler2017-11-19T20:36:05ZRobert Berneckymasterrun dies in SCCFprf_modarray1/2 w/production compiler| | |
| --- | --- |
| Bugzilla Link | [829](http://bugs.sac-home.org/show_bug.cgi?id=829) |
| Created on | Feb 23, 2011 17:12 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Two CF unit tests hav...| | |
| --- | --- |
| Bugzilla Link | [829](http://bugs.sac-home.org/show_bug.cgi?id=829) |
| Created on | Feb 23, 2011 17:12 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Two CF unit tests have been broken on SOME hosts with the production
compiler, for some time now. This from nkk's masterrun of 2011-02-21 21:45:00:
sac2c: Checked out revision 17323.
stdlib: Checked out revision 1495.
Changed behavior when testsuite_res (product version):
************************************************************
/tmp/MASTERR_NzHmu10213/sac/testsuite/optimizations/constantfolding/SCCFprf_modarray1:
base : > /bin/sh: ./SCCFprf_modarray1: No such file or directory
/tmp/MASTERR_NzHmu10213/sac/testsuite/optimizations/constantfolding/SCCFprf_modarray2:
base : > /bin/sh: ./SCCFprf_modarray2: No such file or directory
/tmp/MASTERR_NzHmu10213/sac/testsuite/unibench/ubgraphtestcase/exportdata:
actual: < /bin/sh: ./exportdata: not found
This does not break on my X86 GCC system, with either production or
development compilers.</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1290Failure to move invariant WL out of FOR loop kills ipbb performance2017-11-19T20:36:02ZRobert BerneckyFailure to move invariant WL out of FOR loop kills ipbb performance| | |
| --- | --- |
| Bugzilla Link | [524](http://bugs.sac-home.org/show_bug.cgi?id=524) |
| Created on | Jul 14, 2009 04:10 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbb5.slow.sac](/uploads/8d7e3...| | |
| --- | --- |
| Bugzilla Link | [524](http://bugs.sac-home.org/show_bug.cgi?id=524) |
| Created on | Jul 14, 2009 04:10 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipbb5.slow.sac](/uploads/8d7e3284e351038555e32585e81d58f7/ipbb5.slow.sac), [bug.funcond.sac](/uploads/510d31f8fba7844dbf4f0fbee5906001/bug.funcond.sac), [bug.compress.breaks.sac](/uploads/828cbca7dac5c005d9f146e53b821e5e/bug.compress.breaks.sac), [iotaonly7.sac](/uploads/f5ee8367f580cbb69881f909b89fc95d/iotaonly7.sac), [crud.slow](/uploads/2cecdb609f665609e8d7170337f12222/crud.slow), [crud.fast](/uploads/4755e5b361dd6e17fbb26472a2aff788/crud.fast) |
## Extended Description
<pre>Created an attachment (id=551)
Shorter source code to reproduce fault
I've been chasing a problem with the performance of a Boolean-Boolean
inner product code, apex/ipbb/ipbb.sac.
Although I think there are some problems with my extrema code in
this area, due to differences in performance in the current system,
the attached shorter example has the interesting property that
the compiler does not appear to be moving a loop-invariant Wl out of a
FOR-loop.
I say this because, if I move the loop out by hand, everything
runs bags faster in both the extrema and non-extrema world.
I am off to bed, so have not looked into this yet...
This all with Build #16193.
With xrow inside FOR-loop:
sac2c -O3:
ipbb5.slow.sac.exe.O3.papiex.rattler.28893:PAPI_TOT_INS: 99065594
sac2c -O3 -extrema -nowlf -doswlf:
ipbb5.slow.sac.exe.swlf.papiex.rattler.28928:PAPI_TOT_INS: 1003065073
With xow outside FOR-loop:
sac2c -O3:
ipbb5.slow.sac.exe.O3.papiex.rattler.28998:PAPI_TOT_INS: 765065354
sac2c -O3 -extrema -nowlf -doswlf:
ipbb5.slow.sac.exe.swlf.papiex.rattler.28970:PAPI_TOT_INS: 765065175</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1288Buggy AUD code crashes C compiler2021-05-31T12:05:11ZRobert BerneckyBuggy AUD code crashes C compiler| | |
| --- | --- |
| Bugzilla Link | [486](http://bugs.sac-home.org/show_bug.cgi?id=486) |
| Created on | Apr 24, 2009 16:22 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug486.sac](/uploads/857e4581b...| | |
| --- | --- |
| Bugzilla Link | [486](http://bugs.sac-home.org/show_bug.cgi?id=486) |
| Created on | Apr 24, 2009 16:22 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug486.sac](/uploads/857e4581b3cdaa7673dd6ccf46747402/bug486.sac) |
## Extended Description
<pre>I created the attached code in an attempt to see how/if
sac2c deals with multi-partition WLs whose generator bounds
are of different lengths (hence, the program is broken!).
If you compile it with -DAKS or -DAKD, sac2c nicely detects the
problem and reports it in phase 6.
If you compile it with -DAUD, the C compiler dies:
**** Invoking C compiler ...
a.out.c: In function ‘SACf__MAIN__main’:
a.out.c:872: error: ‘SACp_emal_610_x__shpSAC_d’ undeclared (first use in this function)</pre>BugZillaBugZillahttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/12872D array assignment in for loops2021-09-06T19:43:52ZRobert Stewart2D array assignment in for loops| | |
| --- | --- |
| Bugzilla Link | [1141](http://bugs.sac-home.org/show_bug.cgi?id=1141) |
| Created on | Oct 29, 2014 15:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This code compiles ...| | |
| --- | --- |
| Bugzilla Link | [1141](http://bugs.sac-home.org/show_bug.cgi?id=1141) |
| Created on | Oct 29, 2014 15:25 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>This code compiles just fine:
int main()
{
xs = [1,2,3];
for( i=0; i<3; i++) {
xs[i] = 5;
}
return 1; }
The following very similar code does not compile. The only difference is that it is assigning to a 2D array, rather than a 1D array as before.
int main()
{ xss = [[1,2,3],[4,5,6]];
for( i=0; i<2; i++) {
for( j=0; j<2; j++) {
xss[i][j] = 5;
}
}
return 1; }
The compile error is:
$ sac2c test.sac
./test.sac 5:35 error:
=> token `;' expected, `=' token found
abort: Failed to construct a syntax tree for `test.sac'
compilation failed while Loading SAC program, 1 error(s).
Line 5 is `xss[i][j] = 5;`.</pre>Artem ShinkarovArtem Shinkarovhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1286problem with saa insertion and modarray WLs2021-05-27T14:01:02ZSven-Bodo Scholzproblem with saa insertion and modarray WLs| | |
| --- | --- |
| Bugzilla Link | [387](http://bugs.sac-home.org/show_bug.cgi?id=387) |
| Created on | Jul 07, 2007 10:04 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [saabug.sac](/uploads/e7738c031...| | |
| --- | --- |
| Bugzilla Link | [387](http://bugs.sac-home.org/show_bug.cgi?id=387) |
| Created on | Jul 07, 2007 10:04 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [saabug.sac](/uploads/e7738c031afffcf4d4649ad1c50bab66/saabug.sac) |
## Extended Description
This is a tricky one...
the type checker takes into account the entire WL for finding out the best
possible return type. SAA insertion uses this info but shortcuts the definition
of the shapes attribute which prevents a successive TC run to be able to verify
that.Florian BütherFlorian Bütherhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1285One stone. Two birds. UTExpand kills with-loop fusion2017-11-19T20:35:39ZRobert BerneckyOne stone. Two birds. UTExpand kills with-loop fusion| | |
| --- | --- |
| Bugzilla Link | [358](http://bugs.sac-home.org/show_bug.cgi?id=358) |
| Created on | May 02, 2007 21:54 |
| Version | 1.00beta |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>If you compile sac...| | |
| --- | --- |
| Bugzilla Link | [358](http://bugs.sac-home.org/show_bug.cgi?id=358) |
| Created on | May 02, 2007 21:54 |
| Version | 1.00beta |
| OS | All |
| Architecture | PC |
## Extended Description
<pre>If you compile sac/apex/UTExpand/UTExpand.sac with "-dowlfs",
it gets stuck in WL-fusion. Or if not stuck, at least way too slow.
If you compile it with "-O3", it dies in phase 15,
"applying type conversions" with "Conversion to or from
scalar detected."
If you compile with "-noopt", it compiles and executes properly.</pre>Clemens GrelckClemens Grelckhttps://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/1283Are you suffering from Too Much DRAM in mdiv2.sac? Use wlfs!2021-05-26T20:33:03ZRobert BerneckyAre you suffering from Too Much DRAM in mdiv2.sac? Use wlfs!| | |
| --- | --- |
| Bugzilla Link | [312](http://bugs.sac-home.org/show_bug.cgi?id=312) |
| Created on | Oct 24, 2006 18:24 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tjck.sac](/uploads/bd10fbad431...| | |
| --- | --- |
| Bugzilla Link | [312](http://bugs.sac-home.org/show_bug.cgi?id=312) |
| Created on | Oct 24, 2006 18:24 |
| Version | 1.00beta |
| OS | Linux |
| Architecture | PC |
| Attachments | [tjck.sac](/uploads/bd10fbad4312a1cf11992013603eb60b/tjck.sac) |
## Extended Description
<pre>If you compile sac/apex/mdiv2.sac with these parameters,
With-loop fusion gets its knickers in a knot and eats all the memory, eventually.
sac2c -check b -maxwlur 3 -dowlfs apex/mdiv2.sac
rev 15060 gets this...</pre>Clemens GrelckClemens Grelckhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/1282Floating point fractions must have leading zero, or wrong answer2017-11-19T20:35:29ZRobert BerneckyFloating point fractions must have leading zero, or wrong answer| | |
| --- | --- |
| Bugzilla Link | [1196](http://bugs.sac-home.org/show_bug.cgi?id=1196) |
| Created on | Jun 26, 2017 15:49 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [0001-Fixes-1196.patch](/uploads/3...| | |
| --- | --- |
| Bugzilla Link | [1196](http://bugs.sac-home.org/show_bug.cgi?id=1196) |
| Created on | Jun 26, 2017 15:49 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [0001-Fixes-1196.patch](/uploads/332ca7ffc0f283db8e49ff1e0759731e/0001-Fixes-1196.patch) |
## Extended Description
<pre>The difference in behavior between these two examples seems
very wrong to me.
If it's a bug, it should be fixed. If it's part of the language
definition, the definition is wrong and should be fixed.
cat bugparser.sac
int main()
{
y = 0.0012;
StdIO::print(y);
y = .0012;
StdIO::print(y);
return(0);
}
sac@rattler:~/sac/testsuite/optimizations/pwlf$ sac2c bugparser.sac -v1
sac@rattler:~/sac/testsuite/optimizations/pwlf$ a.out; echo $?
Dimension: 0
Shape : < >
0.0012
Dimension: 0
Shape : < >
0
0
sac2c -V
sac2c 1.2-beta-BlackForest-542-g022cd
build-type: DEBUG
built-by: "sac" at 2017-06-25T17:37:57
I think it's a parser bug:
cat bugparser.sac
int main()
{
x = 0.0012;
StdIO::print(x);
y = .0012;
StdIO::print(y);
z = _sub_SxS_( x, y);
StdIO::print(z);
return(0);
}
sac@rattler:~/sac/testsuite/optimizations/pwlf$ sac2c bugparser.sac -v1
./bugparser.sac 1 error: All instances of "main" contain type errors
error: line 10 in file ./bugparser.sac:
error: Element types of argument #1 and argument #2 of "_sub_SxS_" should be
error: identical; types found: double{0.0...} and int{0}
compilation failed while Running type inference system, 1 error(s).</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/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/1280Intermittent failure with -check c2017-11-19T20:35:22ZRobert BerneckyIntermittent failure with -check c| | |
| --- | --- |
| Bugzilla Link | [1182](http://bugs.sac-home.org/show_bug.cgi?id=1182) |
| Created on | Dec 21, 2016 21:13 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [time2code.sac](/uploads/18118ccfd...| | |
| --- | --- |
| Bugzilla Link | [1182](http://bugs.sac-home.org/show_bug.cgi?id=1182) |
| Created on | Dec 21, 2016 21:13 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [time2code.sac](/uploads/18118ccfd02c7d0424b6e0b8e72a2c00/time2code.sac) |
## Extended Description
<pre>Created an attachment (id=1052)
source code to reproduce failure
****** Optimizing regular function:
****** _MAIN::main( ): ...
Inserting symbolic array attributes ...
Eliminating index vectors (split selections) ...
Eliminating common subexpressions ...
Applying prf unrolling ...
Inferring loop invariant variables ...
Applying type upgrade ...
Eliminating type variables ...
Eliminating bottom types ...
compilation failed while Running SAC optimizations, 1 warning(s).
This failure occurs very sporadically, and it always seems to
go away upon rerunning the compile. It has been around for many
moons.
sac2c -V
sac2c 1.2.beta-BlackForest-348-72a4d
developer
(Wed Dec 21 15:12:02 EST 2016 by sac)
It looks to be related to the use of -check c.
I now have what appears to be a solid failure with -dopogo -check c.
sac2c time2code.sac -v1 -noainl -v4 -check c -dopogo</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/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/1278#pragma noinline not working as expected2017-11-19T20:35:15ZHans-Nikolai Viessmann#pragma noinline not working as expected| | |
| --- | --- |
| Bugzilla Link | [1175](http://bugs.sac-home.org/show_bug.cgi?id=1175) |
| Created on | Nov 23, 2015 23:54 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Given a function id...| | |
| --- | --- |
| Bugzilla Link | [1175](http://bugs.sac-home.org/show_bug.cgi?id=1175) |
| Created on | Nov 23, 2015 23:54 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Given a function id():
int[*] id(int[*] a)
{ return a; }
#pragma noinline
Using `#pragma noinline' to prevent any inlining (via AINL) does not have the
intended effect - id() is selected for inlining.
Tracing though the compilations steps, the issue arises from libsac2c/scanparse/resolvepragma.c where the traversal (called RSP) does *not* traverse into ordinary N_fundef, only those linked to MODULE_FUNDECS, which means that the pragma is never resolved and the FUNDEF_NOINLINE flag is never set.
Looking through the RSP reversal, it becomes clear that it is only designed to handle external declarations, with asserts existing within RSPfundef() to ensure that only fundefs with ISEXTERN are traversed/modified.
My questions is, why are the pragmas of external declarations only 'resolved' and not all function declarations?</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/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/1274TC isn't much help in error reporting2017-11-19T20:35:01ZRobert BerneckyTC isn't much help in error reporting| | |
| --- | --- |
| Bugzilla Link | [1102](http://bugs.sac-home.org/show_bug.cgi?id=1102) |
| Created on | Nov 10, 2013 19:16 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipddStar.sac](/uploads/929ac54e22...| | |
| --- | --- |
| Bugzilla Link | [1102](http://bugs.sac-home.org/show_bug.cgi?id=1102) |
| Created on | Nov 10, 2013 19:16 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [ipddStar.sac](/uploads/929ac54e22e8c59af850da692e3a97e3/ipddStar.sac) |
## Extended Description
<pre>Created an attachment (id=995)
source code to reproduce fault
sac2c ipddStar.sac -v1
typecheck/new_types.c:904 Assertion "(NTYPE_CON(array) == TC_aks) || (NTYPE_CON(array) == TC_akv) || (NTYPE_CON(array) == TC_akd) || (NTYPE_CON(array) == TC_audgz) || (NTYPE_CON(array) == TC_aud)" failed!
TYgetScalar applied to other than array type!
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 18410 linux-gnu_x86_64
(Sat Nov 9 16:39:54 EST 2013 by sac)
The problem is in this line:
Crow = plusDDD( toD( y[colx]), Crow );
plusDDD() exists, but only for scalar-scalar arguments;
the code wants a vector-vector function, but it does not
exist. It would be nice if it told us that.</pre>Sven-Bodo ScholzSven-Bodo Scholzhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/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 Scholz