Bug#799953: gcc-4.9: incorrect double to integer conversion on i386
On Tue, 17 Nov 2015 13:47:29 +0100 Miroslav Urbanek <mu@miroslavurbanek.com> wrote:
> > What's the result type of float * int ? Definitively not double, but
> > float. (Just the intermediate result in the x87 fpu has extended
> > precision.)
>
> True, according to C11 standard, section 6.3.1.8, the result type of
> float * int is float.
You seem to misunderstand the consequences of this fact.
> > So I don't think the compiler is wrong considering d and g to
> > contain the same information, since the same *float* value was
> I think the compiler is wrong. C11 standard, section 6.5.1, says:
>
> "The type of an assignment expression is the type the left operand
> would have after lvalue conversion."
This is true, but you don't seem to understand what it actually means.
Yes, the type of the assignment expression is double. But it's a value
converted from float, and the calculation in floats may already have or
have not lost precision prior to that conversion.
> I couldn't find any GNU extensions that change arithmetic conversion
> rules.
The switch you failed to find is likely -fexcess-precision ("enabled by
default for C if a strict conformance option such as -std=c99 is
used").
> The bug PR323 is caused by excess precision of some
> values. Here, it's the opposite case. Value in d is double, but in the
> expression "int i = d", GCC uses a floating approximation to this
> value, which has obviously lower precision. I think it's clearly a
> bug.
No, it is not in any sense "opposite". Your test code calculates
"f*atoi(argv[1])" at float precision. That any following calculation
based on that value may use more precision than a standard float is an
example of excess precision, exactly the known issue in PR323.
In summary: I don't think there is anything new or unexpected here.
Overall this behavior is just another example of the well-known excess
precision issue. This bug report should likely be closed without any
other action.
Reply to: