I am looking at bug #497 (https://bugs.open64.net/show_bug.cgi?id=497) and
created this small test case to show the problem:
#include <stdio.h>
#include <stdint.h>
int main() {
unsigned long long qw;
float f;
qw = 0xFEA8C3DFBB282B2Dull;
f = (float)qw;
printf ("f = %e\n", f);
return 0;
}
Gcc prints "f = 1.835013e+19" and Opencc prints "f = -9.661203e+16".
I then tracked the problem down to this code in wgen/wgen_expr.cxx where
we generate an ICVT instead of a UCVT:
#if !defined(TARG_SL)
// bug 14430: Generate a CVT with the same signedness.
else if (MTYPE_signed(WN_rtype(wn0)) != MTYPE_signed(mtyp) &&
MTYPE_bit_size(WN_rtype(wn0)) > MTYPE_bit_size(mtyp)) {
wn = WN_Cvt(Mtype_TransferSign(mtyp, WN_rtype(wn0)), mtyp, wn0);
}
#endif
I assume bug 14430 is in the old pathscale database we don't have
access to? The problem here is that when converting a 64 bit unsigned
integer to a 32 bit float, this code is triggered and we generate an
ICVT instead of a UCVT and get the wrong answer.
I would like to either remove this code (like is done for TARG_SL) or
restrict it to integer type conversions only (based on a guess that
the original bug involved only integer types). It is hard to know what
the right thing to do is without knowing what bug 14430 is.
Does anyone know what the original bug was? Does anyone have an
opinion on the correct fix?
Steve Ellcey
s...@cup.hp.com
------------------------------------------------------------------------------
Free Software Download: Index, Search & Analyze Logs and other IT data in
Real-Time with Splunk. Collect, index and harness all the fast moving IT data
generated by your applications, servers and devices whether physical, virtual
or in the cloud. Deliver compliance at lower cost and gain new business
insights. http://p.sf.net/sfu/splunk-dev2dev
_______________________________________________
Open64-devel mailing list
Open64-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/open64-devel
