-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