-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
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information