In CF vs. PRFUNR battle, CF loses, in SCSprf_add2.sac
|
|
Bugzilla Link |
685 |
Created on |
Mar 18, 2010 16:36 |
Resolution |
FIXED |
Resolved on |
Jan 23, 2014 14:52 |
Version |
svn |
OS |
Linux |
Architecture |
PC |
Attachments |
SCSprf_add2.sac |
Extended Description
Created an attachment (id=678)
source code to reproduce fault
I'm not sure why this bug does not occur more often,
but there appears to be a race between CF and PRFUNR,
where PRFUNR makes it more difficult for CF to do its job.
In the SCSprf_add2.sac sac CF unit test suite, the
code is attempting to replace the expression:
z = vec + _neg_V_( vec);
by:
z = vec * 0;
[It actually builds a vector of zeros, but that's harder to spell here.]
If PRFUNR runs before CF, we end up with this sort of code,
potentially made more complicated by the intrusion of guards and,
perhaps, extrema, if we are compiling with -ecc/check c and/or -extrema:
negV = _neg_V_( v1);
_uprf_546 = [ 0 ];
_uprf_547 = _sel_VxA_( _uprf_546, v1);
_uprf_549 = _sel_VxA_( _uprf_546, negV);
_uprf_550 = _add_SxS_( _uprf_547, _uprf_549);
I could add more code to this CF function to handle the
vector indexing, but I'd prefer a more general, or at least
cleaner, solution.