the error on the part of the optimizer could be:
an unsigned int value shifted right by 32 is always zero
(which is right, if there are no 64 bit values around,
but wrong in this case).
Could this be the reason for the optimizer deciding here
that the argument in this case will always be zero?
That is: optimizer's fault?
Kind regards
Bernd
Am 25.07.2013 17:06, schrieb Bernd Oppolzer:
Hello Charles,
when looking at this code:
+@32L1395 DS 0H
+ LM r15,r0,&EPA_&WSA(r1,8)
+ LGHI r2,H'0'
+ ST r0,_CEECAA_(,r12,500)
+ ST r2,#MX_TEMP32(,r13,196)
+ LA r1,#MX_TEMP32(,r13,196)
+ BASR r14,r15
+ AHI r15,H'32'
it looks to me as if the optimizer decided to always call ffs with a
constant zero argument in the second case, see the LGHI to R2,
and ST R2 into the argument list - which is wrong IMO.
in the C code we have:
if ( testWord != 0 )
{
// _BitScanForward returns base 0
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+1;
#else
return ffs(testWord);
#endif
}
else
{
testWord = valueToTest >> 32;
#ifdef WIN32
unsigned long index;
_BitScanForward(&index, testWord);
return index+33;
#else
return ffs(testWord) + 32;
#endif
}
that is: if testWord is zero, then
it is computed to be the result of the shift,
but the generated machine code acts as if it stays as zero;
the shift and assignment to testWord is - for some reason -
moved out of the if - which is wrong, I believe.
What do others on the list who read ASSEMBLER and C think of this?
Maybe indeed a compiler problem?
Kind regards
Bernd
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
