-ecc breaks CF _take_SxV_( shape(vec)[0], vec)
|
|
Bugzilla Link |
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 |
Extended Description
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