https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78605
--- Comment #1 from joseph at codesourcery dot com <joseph at codesourcery dot com> --- On Tue, 29 Nov 2016, msebor at gcc dot gnu.org wrote: > As an independent issue, since the type of the arguments to the %f directive > is > float (not double), the checker should use -FLT_MAX rather than -DBL_MAX to > determine the output. That may not be safe in general, because of excess range and precision. In the -fexcess-precision=standard case, the front end will have dealt with the excess precision as needed, involving wider types explicitly and truncating anything wider than double to double for the variable arguments. Given that these checks are done in the middle end, it will see IR where the excess precision is explicit and shouldn't have problems with it. In the -fexcess-precision=fast (default) case, however, the fact that a float value might have long double range and precision is invisible to the middle end. On 32-bit x86 the truncation to double will happen as a result of storing the argument on the stack, but the double value could be outside the range of float without anything in the IR indicating this. (Remember that with -fexcess-precision=fast, even values stored in variables can have excess range and precision, not just direct results of arithmetic. Generally, the issue is where there is implicit excess precision in the back end; explicit excess precision inserted in the IR by the front end shouldn't be an issue, except for affecting portability of testcases.)
