* GCC 12 miscompiles libm @ 2021-12-20 16:18 H.J. Lu 2021-12-20 21:49 ` Joseph Myers 0 siblings, 1 reply; 11+ messages in thread From: H.J. Lu @ 2021-12-20 16:18 UTC (permalink / raw) To: GNU C Library, Joseph S. Myers, Richard Biener 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: GCC 12 miscompiles libm 2021-12-20 16:18 GCC 12 miscompiles libm H.J. Lu @ 2021-12-20 21:49 ` Joseph Myers 2021-12-20 21:53 ` H.J. Lu 2021-12-29 14:35 ` Szabolcs Nagy 0 siblings, 2 replies; 11+ messages in thread From: Joseph Myers @ 2021-12-20 21:49 UTC (permalink / raw) To: H.J. Lu; +Cc: GNU C Library, Richard Biener 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: GCC 12 miscompiles libm 2021-12-20 21:49 ` Joseph Myers @ 2021-12-20 21:53 ` H.J. Lu 2021-12-20 21:59 ` Joseph Myers 2021-12-29 14:35 ` Szabolcs Nagy 1 sibling, 1 reply; 11+ messages in thread From: H.J. Lu @ 2021-12-20 21:53 UTC (permalink / raw) To: Joseph Myers; +Cc: GNU C Library, Richard Biener 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: GCC 12 miscompiles libm 2021-12-20 21:53 ` H.J. Lu @ 2021-12-20 21:59 ` Joseph Myers 2021-12-20 22:05 ` Joseph Myers 0 siblings, 1 reply; 11+ messages in thread From: Joseph Myers @ 2021-12-20 21:59 UTC (permalink / raw) To: H.J. Lu; +Cc: Richard Biener, GNU C Library 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: GCC 12 miscompiles libm 2021-12-20 21:59 ` Joseph Myers @ 2021-12-20 22:05 ` Joseph Myers 2021-12-20 22:11 ` Joseph Myers 0 siblings, 1 reply; 11+ messages in thread From: Joseph Myers @ 2021-12-20 22:05 UTC (permalink / raw) To: H.J. Lu; +Cc: Richard Biener, GNU C Library 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: GCC 12 miscompiles libm 2021-12-20 22:05 ` Joseph Myers @ 2021-12-20 22:11 ` Joseph Myers 2021-12-20 23:20 ` H.J. Lu 0 siblings, 1 reply; 11+ messages in thread From: Joseph Myers @ 2021-12-20 22:11 UTC (permalink / raw) To: H.J. Lu; +Cc: Richard Biener, GNU C Library 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: GCC 12 miscompiles libm 2021-12-20 22:11 ` Joseph Myers @ 2021-12-20 23:20 ` H.J. Lu 0 siblings, 0 replies; 11+ messages in thread From: H.J. Lu @ 2021-12-20 23:20 UTC (permalink / raw) To: Joseph Myers; +Cc: Richard Biener, GNU C Library 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: GCC 12 miscompiles libm 2021-12-20 21:49 ` Joseph Myers 2021-12-20 21:53 ` H.J. Lu @ 2021-12-29 14:35 ` Szabolcs Nagy 2021-12-29 14:54 ` H.J. Lu 1 sibling, 1 reply; 11+ messages in thread From: Szabolcs Nagy @ 2021-12-29 14:35 UTC (permalink / raw) To: Joseph Myers; +Cc: H.J. Lu, Richard Biener, GNU C Library 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). ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: GCC 12 miscompiles libm 2021-12-29 14:35 ` Szabolcs Nagy @ 2021-12-29 14:54 ` H.J. Lu 2021-12-29 15:37 ` Szabolcs Nagy 0 siblings, 1 reply; 11+ messages in thread From: H.J. Lu @ 2021-12-29 14:54 UTC (permalink / raw) To: Szabolcs Nagy; +Cc: Joseph Myers, Richard Biener, GNU C Library 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: GCC 12 miscompiles libm 2021-12-29 14:54 ` H.J. Lu @ 2021-12-29 15:37 ` Szabolcs Nagy 2021-12-30 22:28 ` Joseph Myers 0 siblings, 1 reply; 11+ messages in thread From: Szabolcs Nagy @ 2021-12-29 15:37 UTC (permalink / raw) To: H.J. Lu; +Cc: Richard Biener, GNU C Library, Joseph Myers 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: GCC 12 miscompiles libm 2021-12-29 15:37 ` Szabolcs Nagy @ 2021-12-30 22:28 ` Joseph Myers 0 siblings, 0 replies; 11+ messages in thread From: Joseph Myers @ 2021-12-30 22:28 UTC (permalink / raw) To: Szabolcs Nagy; +Cc: H.J. Lu, Richard Biener, GNU C Library 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2021-12-30 22:28 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2021-12-20 16:18 GCC 12 miscompiles libm H.J. Lu 2021-12-20 21:49 ` Joseph Myers 2021-12-20 21:53 ` H.J. Lu 2021-12-20 21:59 ` Joseph Myers 2021-12-20 22:05 ` Joseph Myers 2021-12-20 22:11 ` Joseph Myers 2021-12-20 23:20 ` H.J. Lu 2021-12-29 14:35 ` Szabolcs Nagy 2021-12-29 14:54 ` H.J. Lu 2021-12-29 15:37 ` Szabolcs Nagy 2021-12-30 22:28 ` Joseph Myers
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).