GCC 12 miscompiles libm
Joseph Myers
joseph@codesourcery.com
Mon Dec 20 21:49:37 GMT 2021
On Mon, 20 Dec 2021, H.J. Lu via Libc-alpha wrote:
> Hi,
>
> GCC 12 miscompiles libm:
>
> https://sourceware.org/bugzilla/show_bug.cgi?id=28713
>
> due to the fix for
>
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57245
>
> which changes the behavior of -frounding-math on
> conversion from constant double and integer to float.
> However float codes in libm compiled with -frounding-math
> depend on the previous behavior in GCC 11. I added this
> to the glibc 2.35 blocker list.
>
> Joseph, Richard, do you have any suggestions how
> to fix it?
1. What specific constant conversion from double to float in the source
code is changed with GCC 12 so that it now occurs at runtime?
2. Does that conversion get executed in the abstract machine in the qNaN
path through the function (given that the test failures you report are for
qNaN inputs, and I'd generally expect those only to do arithmetic with
qNaN operands)?
3. If it does get executed in the abstract machine, why? It might well be
better to change the functions not to execute the conversion in that case.
4. Alternatively, maybe the conversion doesn't get executed in the
abstract machine in the qNaN path through the function, but the compiler
scheduled it to occur unconditionally because it doesn't model the side
effects of raising exceptions from the conversion.
5. Whether or not the conversion gets executed in the abstract machine, in
any case where a double constant in the source code is immediately
converted to float, it probably makes sense to change the source code to
use a corresponding float constant instead, and so avoid the runtime
conversion (unless the code actually expects a rounding-mode-dependent
result or an exception at runtime).
6. If M_* constants are involved, I suppose we need to add corresponding
float macros.
--
Joseph S. Myers
joseph@codesourcery.com
More information about the Libc-alpha
mailing list