Re: [PATCH] libstdc++: Fix for non-constexpr math_errhandling

[Jonathan Wakely <jwakely.gcc@gmail.com>]

On Wed, 19 Jan 2022 at 15:46, Matthias Kretz <m.kretz@gsi.de> wrote:
>
> On Wednesday, 19 January 2022 16:21:15 CET Jonathan Wakely wrote:
> > On Wed, 19 Jan 2022, 12:45 Matthias Kretz, <m.kretz@gsi.de> wrote:
> > > On Wednesday, 19 January 2022 13:07:26 CET Jonathan Wakely wrote:
> > > > So is it a macro or not?
> > >
> > > I agree the quote I used is unclear. The complete paragraph:
> > >
> > > The macros
> > >
> > > MATH_ERRNO
> > > MATH_ERREXCEPT
> > >
> > > expand to the integer constants 1 and 2, respectively; the macro
> > >
> > > math_errhandling
> > >
> > > expands to an expression that has type int and the value MATH_ERRNO,
> > > MATH_ERREXCEPT, or the bitwise OR of both. The value of math_errhandling
> > > is
> > > constant for the duration of the program. It is unspecified whether
> > > math_errhandling is a macro or an identifier with external linkage. If a
> > > macro
> > > definition is suppressed or a program defines an identifier with the name
> > > math_errhandling, the behavior is undefined. If the expression
> > > math_errhandling & MATH_ERREXCEPT can be nonzero, the implementation shall
> > > define the macros FE_DIVBYZERO, FE_INVALID, and FE_OVERFLOW in
> > > <fenv.h>.
> >
> > But that still says "the macro math_errhandling" and then says it might not
> > be a macro.
>
> There's also [cmath.syn] https://eel.is/c++draft/cmath.syn which says:
>
> #define math_errhandling see below
>
> So, FWIW, libstdc++ is required to define math_errhandling as a macro in
> <cmath>. Thus, the original error (that math_errhandling wasn't defined even
> after <cmath> was included) really needs a fix in <cmath>. :-P

No, because we get it from libc:

#include_next <math.h>