sac2c issueshttps://gitlab.sac-home.org/sac-group/sac2c/-/issues2017-11-19T21:51:15Zhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2033CF shortcoming inhibits AWLF2017-11-19T21:51:15ZRobert BerneckyCF shortcoming inhibits AWLF| | |
| --- | --- |
| Bugzilla Link | [934](http://bugs.sac-home.org/show_bug.cgi?id=934) |
| Created on | Mar 16, 2012 15:15 |
| Resolution | FIXED |
| Resolved on | Mar 16, 2012 15:38 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [934](http://bugs.sac-home.org/show_bug.cgi?id=934) |
| Created on | Mar 16, 2012 15:15 |
| Resolution | FIXED |
| Resolved on | Mar 16, 2012 15:38 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SAACFprf_reshapeAKD.sac](/uploads/8b7a921d61397c5bd681b59ed072401c/SAACFprf_reshapeAKD.sac) |
## Extended Description
<pre>Created an attachment (id=860)
source code to reproduce fault
This is a long-standing problem, which only came to my attention yesterday,
while looking at performance problems in the apex/logd3/logd3.sac benchmark.
Basically, a simple CF optimization is needed to eliminate the guard below,
when PRF_ARG1(arg_node) matches AVIS_SHAPE( ID_AVIS( PRF_ARG2( arg_node))):
int[.] v1 { dim: 1, shape: _pinl_684__idc_52, NN } ;
int v { , NN } ;
...
_idc_22, _icc_19_pred = _prod_matches_prod_shape_VxA_( _pinl_684__idc_52, v1);
_icc_20 = _reshape_VxA_( _idc_22, v1);
The failure occurs in Build #17751, in unit test
~/sac/testsuite/optimizations/constantfolding/SAACFprf_reshapeAKD.sac</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2032_nonnegval() needs to be smarter - buildv.sac2017-11-19T21:51:09ZRobert Bernecky_nonnegval() needs to be smarter - buildv.sac| | |
| --- | --- |
| Bugzilla Link | [912](http://bugs.sac-home.org/show_bug.cgi?id=912) |
| Created on | Feb 15, 2012 22:06 |
| Resolution | FIXED |
| Resolved on | Feb 15, 2012 22:47 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [912](http://bugs.sac-home.org/show_bug.cgi?id=912) |
| Created on | Feb 15, 2012 22:06 |
| Resolution | FIXED |
| Resolved on | Feb 15, 2012 22:47 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Another cause of the APEX buildv.sac benchmark AWLF failure is this:
XX = _add_SxS_(
currentshape, iv);
XX', p = _non_neg_val_S_( XX);
XX has an AVIS_MIN, but it is not constant:
currentshape is the running result shape, which is growing by
catenation. So, it has AVIS_MIN of zero, which is good.
iv is the WL index vector, and it has an AVIS_MIN of zero,
which is also good.
Normally, the guard would be removed if AVIS_MIN(XX)<=0.
But, that value is not constant, so the guard is not removed, at present.
However, we CAN remove the guard, with this observation:
Assume we are looking for a constant AVIS_MIN(XX).
If M=AVIS_MIN(XX) is not constant, look at AVIS_MIN(M)
to see if it's constant. Iterate this until we no longer
have an AVIS_MIN or until we hit a constant.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2031utak() very slow if transpose() is inlined in rle.sac (and other places)2017-11-19T21:51:04ZRobert Berneckyutak() very slow if transpose() is inlined in rle.sac (and other places)| | |
| --- | --- |
| Bugzilla Link | [898](http://bugs.sac-home.org/show_bug.cgi?id=898) |
| Created on | Dec 29, 2011 19:51 |
| Resolution | FIXED |
| Resolved on | Dec 29, 2011 21:54 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [898](http://bugs.sac-home.org/show_bug.cgi?id=898) |
| Created on | Dec 29, 2011 19:51 |
| Resolution | FIXED |
| Resolved on | Dec 29, 2011 21:54 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud2.sac](/uploads/d74b3e10eabbb2611bf6001b9455a65b/crud2.sac) |
## Extended Description
<pre>Created an attachment (id=837)
source code to reproduce failure
sac2c crud2.sac -O3 -v1 -doawlf -nowlf -DSLOW
WARNING: AWLF is enabled. Therefore, -ecc is set.
WARNING: AWLF is enabled. Therefore, -extrema is set.
time apex@rattler:~/apex2003/benchmks/rle$ time a.out
0
real 0m0.993s
user 0m0.930s
sys 0m0.060s
apex@rattler:~/apex2003/benchmks/rle$ sac2c crud2.sac -O3 -v1 -doawlf -nowlf
WARNING: AWLF is enabled. Therefore, -ecc is set.
WARNING: AWLF is enabled. Therefore, -extrema is set.
apex@rattler:~/apex2003/benchmks/rle$ time a.out
0
real 0m0.409s
user 0m0.330s
sys 0m0.070s
apex@rattler:~/apex2003/benchmks/rle$ cp crud2.sac crud2.breaks.sac
apex@rattler:~/apex2003/benchmks/rle$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17716:MODIFIED linux-gnu_x86_64
(Wed Dec 28 15:46:36 EST 2011 by sac)
The -DSLOW inlines TRANSPOSE(). I'm looking at it...</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2030CF selModarray(?) causes wrong answers in rle.sac (and other APEX benchmarks)2017-11-19T21:50:58ZRobert BerneckyCF selModarray(?) causes wrong answers in rle.sac (and other APEX benchmarks)| | |
| --- | --- |
| Bugzilla Link | [897](http://bugs.sac-home.org/show_bug.cgi?id=897) |
| Created on | Dec 24, 2011 16:03 |
| Resolution | FIXED |
| Resolved on | Dec 28, 2011 22:49 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [897](http://bugs.sac-home.org/show_bug.cgi?id=897) |
| Created on | Dec 24, 2011 16:03 |
| Resolution | FIXED |
| Resolved on | Dec 28, 2011 22:49 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud2.sac](/uploads/0ca9743769d9753c9a4140585dfbf163/crud2.sac) |
## Extended Description
<pre>Created an attachment (id=836)
source code to reproduce failure
I chased this bug just this far, but am out of town until Monday; will
fix it then. Basically, indexed assigns of the form:
x[iv] = 42;
z = 10+x[iv];
leaves x unchanged. Not exactly what we want...
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17714:MODIFIED linux-gnu_x86_64
(Tue Dec 20 16:34:06 EST 2011 by sac)
sac2c crud2.sac -v0
a.outapex@rattler:~/apex2003/benchmks/rle$ a.out
4 30
0 0 0 0 30
3 -90
0 0 0 -90 30
2 180
0 0 180 -90 30
1 -180
0 -180 180 -90 30
0 0
0 -180 180 -90 30
0 -180 180 -90 30
apex@rattler:~/apex2003/benchmks/rle$ sac2c crud2.sac -v0 -DBREAKME
apex@rattler:~/apex2003/benchmks/rle$ a.out
4 30
0 0 0 0 0
3 -90
0 0 0 0 0
2 180
0 0 0 0 0
1 -180
0 0 0 0 0
0 0
0 0 0 0 0
0 0 0 0 0</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2029SCCF bug causes wrong answers on idx_modarray_AxVxA()2017-11-19T21:50:52ZRobert BerneckySCCF bug causes wrong answers on idx_modarray_AxVxA()| | |
| --- | --- |
| Bugzilla Link | [892](http://bugs.sac-home.org/show_bug.cgi?id=892) |
| Created on | Dec 20, 2011 20:53 |
| Resolution | FIXED |
| Resolved on | Dec 20, 2011 21:34 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [892](http://bugs.sac-home.org/show_bug.cgi?id=892) |
| Created on | Dec 20, 2011 20:53 |
| Resolution | FIXED |
| Resolved on | Dec 20, 2011 21:34 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Summary says it all; Build # sac2c v1.00-beta (Haggis And Apple)
developer rev 17712:MODIFIED linux-gnu_x86_64
(Mon Dec 19 13:11:35 EST 2011 by sac)
sac2c crud.sac -doawlf -nowlf -v4 -nocyc -bopt:cfls >crud.cfls
Here is the code that fails:
use Array : {genarray,take,-,sel};
inline int[+] rotrXII(int[+] y)
{ /* Last axis reverse on rank>1 */
cellshape = take([-1], _shape_A_(y));
cell = genarray(cellshape, 0);
z = with {
( . <= iv <= .)
: (y[iv]);
} : genarray( [2], cell);
return(z);
}
int main()
{
M =_reshape_VxA_([2, 3],[0,1,2,3,4,5]);
A_354=rotrXII( M);
StdIO::print(A_354);
return(0);
}</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2028_mask_VxVxV_() is very broken2017-11-19T21:50:46ZRobert Bernecky_mask_VxVxV_() is very broken| | |
| --- | --- |
| Bugzilla Link | [891](http://bugs.sac-home.org/show_bug.cgi?id=891) |
| Created on | Nov 18, 2011 19:48 |
| Resolution | FIXED |
| Resolved on | Nov 28, 2011 23:19 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [891](http://bugs.sac-home.org/show_bug.cgi?id=891) |
| Created on | Nov 18, 2011 19:48 |
| Resolution | FIXED |
| Resolved on | Nov 28, 2011 23:19 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>Summary says it all!
sac2c crud.sac -v0 -noopt
sac@rattler:~/sac/testsuite/optimizations/constantfolding$ cat crud.sac
int[*] id( int[*] y)
{
return(y);
}
int main()
{
N = id( 3);
b = _gt_SxV_( N, [ 1,2,3,4,5]) ;
StdIO::print(b);
z = _mask_VxVxV_( b, [10,20,30,40,50], [11,12,13,14,15]);
StdIO::print(z);
return(0);
}
sac@rattler:~/sac/testsuite/optimizations/constantfolding$ a.out
Dimension: 1
Shape : < 5>
< 1 1 0 0 0 >
Dimension: 1
Shape : < 5>
< 0 0 0 0 0 >
We wanted to get: [ 10, 20, 13, 14, 15]!</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2027CF fails on _sel_VxA_( iv, [true, true, true], due to N_array element content...2017-11-19T21:50:41ZRobert BerneckyCF fails on _sel_VxA_( iv, [true, true, true], due to N_array element contents problem| | |
| --- | --- |
| Bugzilla Link | [887](http://bugs.sac-home.org/show_bug.cgi?id=887) |
| Created on | Nov 13, 2011 17:31 |
| Resolution | FIXED |
| Resolved on | Nov 16, 2011 20:08 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [887](http://bugs.sac-home.org/show_bug.cgi?id=887) |
| Created on | Nov 13, 2011 17:31 |
| Resolution | FIXED |
| Resolved on | Nov 16, 2011 20:08 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17702:MODIFIED linux-gnu_x86_64
(Sun Nov 13 11:20:25 EST 2011 by sac)
Cf should produce "true" for the above, but there is some
confusion (at least in my head!) about what node types can
appear legally in an N_array node.
I thought we had agreed that ALL N_array elements should
be N_id nodes, at least within -bopt, but have asked
Bodo and Clemens to confirm that.
If this is the case, then I'll make -d treecheck complain
about constants in N_array nodes. And, fix CF while I'm at it.
In the attached example, the code should eliminate the
sel() and ALL WLs from the code, but it does not do so.
Part of this is due to the fact that SelArrayOfEqualElements
has an (unrelated) bug in it, and part is due to the
fact that it is expecting N_id nodes as N_array elements.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2026WLF/AWLF fails to work when -ecc used on bugVP.sac2017-11-19T21:50:36ZRobert BerneckyWLF/AWLF fails to work when -ecc used on bugVP.sac| | |
| --- | --- |
| Bugzilla Link | [885](http://bugs.sac-home.org/show_bug.cgi?id=885) |
| Created on | Nov 06, 2011 22:01 |
| Resolution | FIXED |
| Resolved on | Nov 12, 2011 16:36 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [885](http://bugs.sac-home.org/show_bug.cgi?id=885) |
| Created on | Nov 06, 2011 22:01 |
| Resolution | FIXED |
| Resolved on | Nov 12, 2011 16:36 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bugVP.sac](/uploads/2bee798612578bfff8c18c45ae0a0bd7/bugVP.sac) |
## Extended Description
<pre>Created an attachment (id=830)
source code to reproduce failure
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17700:MODIFIED linux-gnu_x86_64
(Fri Nov 4 18:16:10 EDT 2011 by sac)
sac2c bugVP.sac -bopt -v1 |grep with |wc
13 128 744
sac2c bugVP.sac -bopt -v1 -ecc |grep with |wc
15 146 966
With any luck, the problem will be in CF or
one of its friends. I've assigned this to myself,
on the assumption that this is the case.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2025AWLFI crashes with bad _same_shape_AxA_() when producerWL cell shape non-scalar2017-11-19T21:50:28ZRobert BerneckyAWLFI crashes with bad _same_shape_AxA_() when producerWL cell shape non-scalar| | |
| --- | --- |
| Bugzilla Link | [884](http://bugs.sac-home.org/show_bug.cgi?id=884) |
| Created on | Nov 02, 2011 22:03 |
| Resolution | FIXED |
| Resolved on | Nov 04, 2011 22:19 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [884](http://bugs.sac-home.org/show_bug.cgi?id=884) |
| Created on | Nov 02, 2011 22:03 |
| Resolution | FIXED |
| Resolved on | Nov 04, 2011 22:19 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug884.sac](/uploads/e9e935e83d8f7dacb370435bc7d90637/bug884.sac) |
## Extended Description
<pre>Summary says it all.
sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17699:MODIFIED linux-gnu_x86_64
(Wed Nov 2 17:11:32 EDT 2011 by sac)
The AWLF unit test UTReshape.sac causes the failure.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2024Bugs in AWLFI and in -doivecyc2017-11-19T21:50:22ZRobert BerneckyBugs in AWLFI and in -doivecyc| | |
| --- | --- |
| Bugzilla Link | [873](http://bugs.sac-home.org/show_bug.cgi?id=873) |
| Created on | Sep 18, 2011 23:39 |
| Resolution | FIXED |
| Resolved on | Sep 19, 2011 22:16 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [873](http://bugs.sac-home.org/show_bug.cgi?id=873) |
| Created on | Sep 18, 2011 23:39 |
| Resolution | FIXED |
| Resolved on | Sep 19, 2011 22:16 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/38b5b685616ce55e1886206ba24a0ae1/crud.sac) |
## Extended Description
<pre>Build #17622:MODIFIED (modified to enable -doivecyc by default) produces
at least TWO different problems.
1. CF unit test bugidxshapesel.sac runs out of memory if compiled with latest
version of AWLFI. It works "better" with -r17592.
2. sac2c apex/ipbb/ipbb.sac
gets wrong result, unless compiled with -noivecyc, in which case it
works fine.
I'm working on isolating the problems.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2023CF in LACFUN fails to catch _idx_sel_( 0, [ X, Y])2017-11-19T21:50:16ZRobert BerneckyCF in LACFUN fails to catch _idx_sel_( 0, [ X, Y])| | |
| --- | --- |
| Bugzilla Link | [870](http://bugs.sac-home.org/show_bug.cgi?id=870) |
| Created on | Sep 06, 2011 23:53 |
| Resolution | FIXED |
| Resolved on | Oct 14, 2011 17:46 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [870](http://bugs.sac-home.org/show_bug.cgi?id=870) |
| Created on | Sep 06, 2011 23:53 |
| Resolution | FIXED |
| Resolved on | Oct 14, 2011 17:46 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [crud.sac](/uploads/1e1b98207438a8ea840dad60e3f0d398/crud.sac) |
## Extended Description
<pre>Created an attachment (id=817)
source code to reproduce failure
sac@rattler:~/sac2c$ sac2c -V
sac2c v1.00-beta (Haggis And Apple)
developer rev 17603:MODIFIED linux-gnu_x86_64
(Tue Sep 6 18:29:51 EDT 2011 by sac)
CF misses this one, which should be simplified to X.
Here's how ya do it:
sac2c crud.sac -doawlf -nowlf -bopt -v1 >crud2
Loop_3 contains the offending code, which happens to
make the -doawlf version of this AKD test run 3X slower
than it should.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2022CUBSL puts vardecs in wrong fundef2017-11-19T21:50:10ZRobert BerneckyCUBSL puts vardecs in wrong fundef| | |
| --- | --- |
| Bugzilla Link | [856](http://bugs.sac-home.org/show_bug.cgi?id=856) |
| Created on | Aug 10, 2011 22:37 |
| Resolution | FIXED |
| Resolved on | Aug 10, 2011 22:57 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [856](http://bugs.sac-home.org/show_bug.cgi?id=856) |
| Created on | Aug 10, 2011 22:37 |
| Resolution | FIXED |
| Resolved on | Aug 10, 2011 22:57 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bugipbbDUP.sac](/uploads/dd3e7be4ceeb01595717c1bfface7cbe/bugipbbDUP.sac) |
## Extended Description
<pre>Created an attachment (id=809)
source code to reproduce failure
Summary says it all:
Build #developer rev 17539 linux-gnu_x86_64
sac2c -doawlf -nowlf buildvsmall.sac
AST is damaged after bopt:saacyc:cubsl:5:
int _dup_8959__ivexi_6216_ext { dim: 0, shape: [:int], NN } ;
is defined in main(), but used in Loop().
I'll look at it tomorrow morning, unless I get Very Keen.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2021Master run has a warning2017-11-19T21:50:04ZCarl JoslinMaster run has a warning| | |
| --- | --- |
| Bugzilla Link | [769](http://bugs.sac-home.org/show_bug.cgi?id=769) |
| Created on | Nov 03, 2010 17:47 |
| Resolution | FIXED |
| Resolved on | Nov 15, 2010 15:18 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [769](http://bugs.sac-home.org/show_bug.cgi?id=769) |
| Created on | Nov 03, 2010 17:47 |
| Resolution | FIXED |
| Resolved on | Nov 15, 2010 15:18 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
The following warning is in the masterrun:
arrayopt/cubeslicer.c:561: warning: ‘isIotaN’ defined but not used
This is a bug for it!!!Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2020DL produces illegal code which causes TC to fail2017-11-19T21:49:59ZCarl JoslinDL produces illegal code which causes TC to fail| | |
| --- | --- |
| Bugzilla Link | [760](http://bugs.sac-home.org/show_bug.cgi?id=760) |
| Created on | Oct 15, 2010 13:15 |
| Resolution | FIXED |
| Resolved on | Mar 26, 2013 13:54 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [760](http://bugs.sac-home.org/show_bug.cgi?id=760) |
| Created on | Oct 15, 2010 13:15 |
| Resolution | FIXED |
| Resolved on | Mar 26, 2013 13:54 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug760.sac](/uploads/18f899c31cd8f604501f115780a0bc74/bug760.sac), [bug760.out](/uploads/fdf6d5e6b3f9ba03fab3240bc8e8cc69/bug760.out) |
## Extended Description
<pre>sac/testsuite/constraints/prf/type_constraint.sac should be able to compile unless sac can optimize function arguments at the AKV level.
This bug has existed for quite some time and can be seen in the Masterrun.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2019PM followId tries to follow predicate results past guards2017-11-19T21:49:51ZRobert BerneckyPM followId tries to follow predicate results past guards| | |
| --- | --- |
| Bugzilla Link | [728](http://bugs.sac-home.org/show_bug.cgi?id=728) |
| Created on | Jun 22, 2010 18:34 |
| Resolution | FIXED |
| Resolved on | Jun 22, 2010 20:03 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [728](http://bugs.sac-home.org/show_bug.cgi?id=728) |
| Created on | Jun 22, 2010 18:34 |
| Resolution | FIXED |
| Resolved on | Jun 22, 2010 20:03 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCCFprf_reshape.sac](/uploads/2cbd5e5eb67d6b39f8c67940a95ef658/SCCFprf_reshape.sac) |
## Extended Description
<pre>Created an attachment (id=737)
source code to reproduce fault
This code fault is similar in spirit to Bug #727:
In SCCFprf_reshape.sac, we eventually find this IL:
_uprf_116, _uprf_117 = _val_lt_val_SxS_( _uprf_113, _uprf_115);
_uprf_118 = _and_SxS_( _uprf_111, _uprf_117);
CF (MatchConstantZero) comes along and tries to trace, via PM, _uprf_117
back to a constant, merrily skipping any guards it meets along
the way. Unfortunately, PM should only skip a guard if the variable
it is tracing is one of the primary results of the primitive, and
should never attempt to trace the resulting predicates, which this is.
I'll get on it right away.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2018PM strays from SSAASSIGN trail on _same_shape_AxS followPrf2017-11-19T21:49:45ZRobert BerneckyPM strays from SSAASSIGN trail on _same_shape_AxS followPrf| | |
| --- | --- |
| Bugzilla Link | [727](http://bugs.sac-home.org/show_bug.cgi?id=727) |
| Created on | Jun 21, 2010 19:51 |
| Resolution | FIXED |
| Resolved on | Jun 21, 2010 23:47 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [727](http://bugs.sac-home.org/show_bug.cgi?id=727) |
| Created on | Jun 21, 2010 19:51 |
| Resolution | FIXED |
| Resolved on | Jun 21, 2010 23:47 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>PM has a small, but serious bug in the followPrf code.
When tracing back an N_id/guard/extrema chain, the code blindly
follows PRF_ARG1 of any suitable N_prf node it encounters.
This is generally correct, but in the case of _same_shape_AxA, there
are TWO array results, as well as a guard result:
x', y', p = _same_shape_AxA_( x, y);
If we are chasing the second result, y', we end up chasing x,
rather than y. This can lead to very exciting optimizations,
such as CF deciding that [0] >= [50] is TRUE.
1. Stephan: Can you please confirm that _same_shape_AxA is
the only guard that returns two array results?
2. The fix in PM is going to be somewhat ugly. Another approach
would be this one:
- Make _same_shape_AxA_ return only PRF_ARG1 as its primary
result.
- Change -ecc to emit two _same_shape_AxA_ calls, on
(x, y) and on (y', x').
This would eliminate the problem, but it does lack a certain
elegance...
No nice test case, as this is breaking on 16524:16896:MODIFIED
with tinkered CF code (rattler).</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2017-ecc breaks CF _take_SxV_( shape(vec)[0], vec)2017-11-19T21:49:40ZRobert Bernecky-ecc breaks CF _take_SxV_( shape(vec)[0], vec)| | |
| --- | --- |
| Bugzilla Link | [684](http://bugs.sac-home.org/show_bug.cgi?id=684) |
| Created on | Mar 17, 2010 19:49 |
| Resolution | FIXED |
| Resolved on | Jan 23, 2014 14:50 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [684](http://bugs.sac-home.org/show_bug.cgi?id=684) |
| Created on | Mar 17, 2010 19:49 |
| Resolution | FIXED |
| Resolved on | Jan 23, 2014 14:50 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [SCSprf_take2.sac](/uploads/ee56a0af5357e4833585adc651600e27/SCSprf_take2.sac) |
## Extended Description
<pre>Created an attachment (id=677)
source code to reproduce fault
This would not be so serious, except for the fact that we now
require -ecc in order to make AWLF operate in a post-Loch Ness environment.
Here's the code of interest:
z2 = _take_SxV_( _isaa_175_siz, vec);
With:
AVIS_SHAPE(vec) = _ivexp_201;
And this:
_uprf_136, _uprf_137 = _non_neg_val_S_( _isaa_175_siz);
_ivexp_198 = [ _uprf_136 ];
_ivexp_201 = _noteminval_( _ivexp_198, _uprf_134);
SAACFprf_take_SxV properly pattern-matches its way back to find
_uprf_136, but it gets stuck there.
I am going to enhance(?) this CF code to then perform
a third, guard-skipping operation on _uprf_136, which should
do the trick, but I am not convince that this is the
correct solution, because:
(a) It feels ad hoc.
(b) It would be nice to have a cleaner mechanism for doing this.
(c) I am not sure how many such situations of this nature are
still lurking in the CF (and other) code.
sac2c -ecc -b11:ebt SCSprf_take2.sac >crud
does the trick, on my VERY private build here:
developer rev 16776:MODIFIED linux-gnu_x86_64</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2016CWLE improvements show up fault in AWLF F_intersect analysis2017-11-19T21:49:33ZRobert BerneckyCWLE improvements show up fault in AWLF F_intersect analysis| | |
| --- | --- |
| Bugzilla Link | [652](http://bugs.sac-home.org/show_bug.cgi?id=652) |
| Created on | Jan 07, 2010 15:30 |
| Resolution | FIXED |
| Resolved on | Jan 07, 2010 16:49 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [652](http://bugs.sac-home.org/show_bug.cgi?id=652) |
| Created on | Jan 07, 2010 15:30 |
| Resolution | FIXED |
| Resolved on | Jan 07, 2010 16:49 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
| Attachments | [bug652.sac](/uploads/97aabfc28ce710ef184d1f254fc05290/bug652.sac) |
## Extended Description
<pre>This one took a while to isolate...
AWLFI inserts F_attachintersect data flow function calls to hold
the results of partition-bounds/index-vector set computations for AWLF's
use, in replacing a following _sel_VxA_( iv, producerWL).
In today's adventure, the producerWL is a copy-WL, so all is well,
at first (as in all adventures). Eventually, CWLE replaces
the copy-WL by its predecessor (is there a better word for this?),
which, in this case, happens to be a multi-op WL, producing two
results.
AWLF then comes along and blindly does the folding job, giving us
an unpleasant goulash that also makes the _sel_VxA_ produce
a non-scalar result. Things go downhill from there.
I had a hard time finding a tiny example that fails.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2015Many sac/apex bugs broken due to byte numerics, etc.2017-11-19T21:49:27ZRobert BerneckyMany sac/apex bugs broken due to byte numerics, etc.| | |
| --- | --- |
| Bugzilla Link | [645](http://bugs.sac-home.org/show_bug.cgi?id=645) |
| Created on | Dec 30, 2009 20:28 |
| Resolution | FIXED |
| Resolved on | Jan 04, 2010 21:48 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [645](http://bugs.sac-home.org/show_bug.cgi?id=645) |
| Created on | Dec 30, 2009 20:28 |
| Resolution | FIXED |
| Resolved on | Jan 04, 2010 21:48 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>sac2c Build #16697, or earlier, has broken many sac/apex/*/*.sac
benchmarks with errors such as:
ABORT: line 24 file: UTThornBoolean.sac
ABORT: No definition found for a function "ArrayArith::!" that accepts an
ABORT: argument of type "byte" as parameter no 1. Full argument types are
ABORT: "( byte)".
ABORT: line 156 file: UTShapeCl.sac
ABORT: No definition found for a function "ArrayArith::&" that accepts an
ABORT: argument of type "byte" as parameter no 1. Full argument types are
ABORT: "( byte, byte)".
ABORT: line 165 file: UTReplicate.sac
ABORT: No definition found for a function "Structures::==" that accepts an
ABORT: argument of type "byte[*]" as parameter no 3. Full argument types
ABORT: are "( Terminal::Terminal, bool{1}, byte[*])".
Please be sure to run the apex test suite when changing this stuff.</pre>Robert BerneckyRobert Berneckyhttps://gitlab.sac-home.org/sac-group/sac2c/-/issues/2014Missing CF code causes AWLFI to produce unresolvable mesh_VxVxV() computation2017-11-19T21:49:21ZRobert BerneckyMissing CF code causes AWLFI to produce unresolvable mesh_VxVxV() computation| | |
| --- | --- |
| Bugzilla Link | [643](http://bugs.sac-home.org/show_bug.cgi?id=643) |
| Created on | Dec 29, 2009 17:58 |
| Resolution | FIXED |
| Resolved on | Dec 30, 2009 22:10 |
| Version | svn |
| OS | Linux |
| Architecture...| | |
| --- | --- |
| Bugzilla Link | [643](http://bugs.sac-home.org/show_bug.cgi?id=643) |
| Created on | Dec 29, 2009 17:58 |
| Resolution | FIXED |
| Resolved on | Dec 30, 2009 22:10 |
| Version | svn |
| OS | Linux |
| Architecture | PC |
## Extended Description
<pre>I think this bug arose out of Loch Ness work, but am not completely sure,
not that it matters...
The basic problem is that AWLFI produces an expression of the form:
_add_VxS_( [0], scalar)
but CF (symbolic_constant_simplification.c) never got support
written to handle those cases.</pre>Robert BerneckyRobert Bernecky