This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: PATCH: fix for parsing hex floats
- From: "Joseph S. Myers" <joseph at codesourcery dot com>
- To: Ulrich Weigand <uweigand at de dot ibm dot com>
- Cc: Ben Elliston <bje at au1 dot ibm dot com>, gcc-patches <gcc-patches at gcc dot gnu dot org>, Ulrich Weigand <Ulrich dot Weigand at de dot ibm dot com>
- Date: Fri, 2 Nov 2007 17:50:07 +0000 (UTC)
- Subject: Re: PATCH: fix for parsing hex floats
- References: <200711021700.lA2H0Pgd012456@d12av02.megacenter.de.ibm.com>
On Fri, 2 Nov 2007, Ulrich Weigand wrote:
> Actually, the problem isn't visible in current mainline; it only occurs
> after switching the literal parser to respect the SPU's round-towards-zero
> mode as done by Trevor's patch (still under discussion):
> http://gcc.gnu.org/ml/gcc-patches/2007-10/msg01459.html
>
> With this patch, the test case below starts to fail. The patch posted
> by Ben will fix it again.
>
> The problem is how constants like __FLT_MIN__ are parsed. On the SPU
> (like with IEEE single-precision float), __FLT_MIN__ has the value 2^-126,
> i.e. sign bit is 0, (biased) exponent is 1, and mantissa is 0.
>
> This value in decimal is about 1.175494350822287508e-38, which gets
> rounded by the default logic in builtin_define_with_hex_fp_value to
> 1.17549435e-38F. Note that is is slightly smaller than the real
> value.
In that case, I think that real_to_decimal should have an option to
generate a string that rounds to the correct value after allowing for this
target-specific rounding mode. The C front-end changes would then be
limited to passing the option to real_to_decimal to require it to produce
a string that rounds correctly, and the assertion that it does indeed
round correctly; the other logic would go in real.c (it might also be
possible for the assertion to go there).
--
Joseph S. Myers
joseph@codesourcery.com