GCC 12 miscompiles libm

GCC 12 miscompiles libm

[H.J. Lu]

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?

Thanks.


-- 
H.J.

Re: GCC 12 miscompiles libm

[Joseph Myers]

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

Re: GCC 12 miscompiles libm

[H.J. Lu]

On Mon, Dec 20, 2021 at 1:49 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> 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.

I don't have answers to these questions.  After I reverted the -frounding-math
change in GCC 12, all libm tests passed.


-- 
H.J.

Re: GCC 12 miscompiles libm

[Joseph Myers]

On Mon, 20 Dec 2021, H.J. Lu via Libc-alpha wrote:

> I don't have answers to these questions.  After I reverted the -frounding-math
> change in GCC 12, all libm tests passed.

These questions form my suggestion for how to determine where to fix the 
failures.  Either there is a constant conversion that was previously 
executed at compile time but is now (correctly) executed at runtime (even 
if, in the abstract machine, it wouldn't get executed for a NaN argument 
to the function), and we should fix it in glibc by changing the constant 
from a double constant to a float constant, or something else is going on 
which suggests a GCC bug.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: GCC 12 miscompiles libm

[Joseph Myers]

On Mon, 20 Dec 2021, Joseph Myers wrote:

> On Mon, 20 Dec 2021, H.J. Lu via Libc-alpha wrote:
> 
> > I don't have answers to these questions.  After I reverted the -frounding-math
> > change in GCC 12, all libm tests passed.
> 
> These questions form my suggestion for how to determine where to fix the 
> failures.  Either there is a constant conversion that was previously 
> executed at compile time but is now (correctly) executed at runtime (even 
> if, in the abstract machine, it wouldn't get executed for a NaN argument 
> to the function), and we should fix it in glibc by changing the constant 
> from a double constant to a float constant, or something else is going on 
> which suggests a GCC bug.

In the cosf case, I suspect

  if (abstop12 (y) < abstop12 (pio4))

where abstop12 takes a float argument, but pio4 is static const double.  
I don't think that pio4 definition is ever used in arithmetic, only in 
calls to abstop12, so changing it to a static const float should be fine.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: GCC 12 miscompiles libm

[Joseph Myers]

On Mon, 20 Dec 2021, Joseph Myers wrote:

> In the cosf case, I suspect
> 
>   if (abstop12 (y) < abstop12 (pio4))
> 
> where abstop12 takes a float argument, but pio4 is static const double.  
> I don't think that pio4 definition is ever used in arithmetic, only in 
> calls to abstop12, so changing it to a static const float should be fine.

And for the Bessel function cases, e.g. math/w_j0f_compat.c has references 
to (float) X_TLOSS which should become references to a corresponding 
constant of type float.

-- 
Joseph S. Myers
joseph@codesourcery.com

Re: GCC 12 miscompiles libm

[H.J. Lu]

On Mon, Dec 20, 2021 at 2:12 PM Joseph Myers <joseph@codesourcery.com> wrote:
>
> On Mon, 20 Dec 2021, Joseph Myers wrote:
>
> > In the cosf case, I suspect
> >
> >   if (abstop12 (y) < abstop12 (pio4))
> >
> > where abstop12 takes a float argument, but pio4 is static const double.
> > I don't think that pio4 definition is ever used in arithmetic, only in
> > calls to abstop12, so changing it to a static const float should be fine.
>
> And for the Bessel function cases, e.g. math/w_j0f_compat.c has references
> to (float) X_TLOSS which should become references to a corresponding
> constant of type float.

Hi Joseph,

You are right on all counts.  I submitted 2 patches to fix GCC 12 build.

Thanks.

-- 
H.J.

Re: GCC 12 miscompiles libm

[Szabolcs Nagy]

The 12/20/2021 21:49, Joseph Myers wrote:
> 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.

in aarch64 libm.so i see new 'fcvt s*, d*' instructions
comparing building it with gcc-11 and gcc-trunk (i.e.
new runtime conversion from double- to single-precision).

number of new 'fcvt s*, d*' per symbol (as reported by
objdump):

1 __j0f_finite@GLIBC_2.17
1 __y0f_finite@GLIBC_2.17
1 __j1f_finite@GLIBC_2.17
1 __y1f_finite@GLIBC_2.17
1 __jnf_finite@GLIBC_2.17
2 gammaf_positive
1 __gammaf_r_finite@GLIBC_2.17
1 __log1pf
1 __lgamma_negf
1 cacosf
4 cacoshf
1 casinhf
1 __kernel_casinhf
4 catanhf
4 catanf
2 clogf
3 __clog10f

i did not analysed these in detail but at least some of
them are because of code like

  (FLOAT) M_MLIT (M_*)

i.e. double precision M_* constant is used as single
precision const (that i think is supposed to be compile
time const and not rounding mode dependent).

Re: GCC 12 miscompiles libm

[H.J. Lu]

On Wed, Dec 29, 2021 at 6:36 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
>
> The 12/20/2021 21:49, Joseph Myers wrote:
> > 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.
>
> in aarch64 libm.so i see new 'fcvt s*, d*' instructions
> comparing building it with gcc-11 and gcc-trunk (i.e.
> new runtime conversion from double- to single-precision).
>
> number of new 'fcvt s*, d*' per symbol (as reported by
> objdump):
>
> 1 __j0f_finite@GLIBC_2.17
> 1 __y0f_finite@GLIBC_2.17
> 1 __j1f_finite@GLIBC_2.17
> 1 __y1f_finite@GLIBC_2.17
> 1 __jnf_finite@GLIBC_2.17
> 2 gammaf_positive
> 1 __gammaf_r_finite@GLIBC_2.17
> 1 __log1pf
> 1 __lgamma_negf
> 1 cacosf
> 4 cacoshf
> 1 casinhf
> 1 __kernel_casinhf
> 4 catanhf
> 4 catanf
> 2 clogf
> 3 __clog10f
>
> i did not analysed these in detail but at least some of
> them are because of code like
>
>   (FLOAT) M_MLIT (M_*)

Replace it with AS_FLOAT_CONSTANT?

> i.e. double precision M_* constant is used as single
> precision const (that i think is supposed to be compile
> time const and not rounding mode dependent).



-- 
H.J.

Re: GCC 12 miscompiles libm

[Szabolcs Nagy]

The 12/29/2021 06:54, H.J. Lu via Libc-alpha wrote:
> On Wed, Dec 29, 2021 at 6:36 AM Szabolcs Nagy <szabolcs.nagy@arm.com> wrote:
> > 1 __j0f_finite@GLIBC_2.17
> > 1 __y0f_finite@GLIBC_2.17
> > 1 __j1f_finite@GLIBC_2.17
> > 1 __y1f_finite@GLIBC_2.17
> > 1 __jnf_finite@GLIBC_2.17
> > 2 gammaf_positive
> > 1 __gammaf_r_finite@GLIBC_2.17
> > 1 __log1pf
> > 1 __lgamma_negf
> > 1 cacosf
> > 4 cacoshf
> > 1 casinhf
> > 1 __kernel_casinhf
> > 4 catanhf
> > 4 catanf
> > 2 clogf
> > 3 __clog10f
> >
> > i did not analysed these in detail but at least some of
> > them are because of code like
> >
> >   (FLOAT) M_MLIT (M_*)
> 
> Replace it with AS_FLOAT_CONSTANT?

M_* in math.h has M_*f32 variants that may be more reliable.
i'm fine with AS_FLOAT_CONSTANT too since math.h macros are
under glibc control.

Re: GCC 12 miscompiles libm

[Joseph Myers]

On Wed, 29 Dec 2021, Szabolcs Nagy via Libc-alpha wrote:

> > > i did not analysed these in detail but at least some of
> > > them are because of code like
> > >
> > >   (FLOAT) M_MLIT (M_*)
> > 
> > Replace it with AS_FLOAT_CONSTANT?
> 
> M_* in math.h has M_*f32 variants that may be more reliable.
> i'm fine with AS_FLOAT_CONSTANT too since math.h macros are
> under glibc control.

I think it would be better to define proper M_*f constants in math.h 
(conditional on __USE_GNU), and then redefine M_MLIT in 
math-type-macros-float.h accordingly to use those (and remove the (FLOAT) 
casts on M_MLIT calls).

-- 
Joseph S. Myers
joseph@codesourcery.com