On Tue, 17 Nov 2015 13:47:29 +0100 Miroslav Urbanek <m...@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.