math_errhandling getting undef'ed for -std=gnu11?

math_errhandling getting undef'ed for -std=gnu11?

[Stephan Bergmann]

My understanding is that C11 requires <math.h> to define 
math_errhandling (as macro or identifier with external linkage), and my 
assumption is that GCC's -std=gnu11 (vs. -std=c11), while it might 
enable language extensions, would not remove from that.

However, at least with glibc-headers-2.28-26.fc29.x86_64,

> $ cat test.c
> #include <math.h>
> int main() { return math_errhandling; }

fails for

> $ gcc -m32 -O -std=gnu11 test.c
> test.c: In function ‘main’:
> test.c:2:21: error: ‘math_errhandling’ undeclared (first use in this function)
>  int main() { return math_errhandling; }
>                      ^~~~~~~~~~~~~~~~
> test.c:2:21: note: each undeclared identifier is reported only once for each function it appears in

while it succeeds for

> $ gcc -m32 -O -std=c11 test.c

What causes the difference is apparently the block

> /* Disable x87 inlines when -fpmath=sse is passed and also when we're building
>    on x86_64.  Older gcc (gcc-3.2 for example) does not define __SSE2_MATH__
>    for x86_64.  */
> #if !defined __SSE2_MATH__ && !defined __x86_64__
> # if ((!defined __NO_MATH_INLINES || defined __LIBC_INTERNAL_MATH_INLINES) \
>      && defined __OPTIMIZE__)
> 
> /* The inline functions do not set errno or raise necessarily the
>    correct exceptions.  */
> #  undef math_errhandling
[...]

in /usr/include/bits/mathinline.h.

Now, my question is whether that is by design (implying that -std=gnu11 
is deliberately non-conforming here) or by accident.

(But seeing 
<https://sourceware.org/git/?p=glibc.git;a=commit;h=da75c1b180f9355a8b2b2584ecf1fcfe03f7107e> 
"Remove x86 mathinline.h" completely dropping 
sysdeps/x86/fpu/bits/mathinline.h from later glibc probably makes the 
question somewhat moot.)

Re: math_errhandling getting undef'ed for -std=gnu11?

[Carlos O'Donell]

On 1/30/19 4:18 AM, Stephan Bergmann wrote:
> My understanding is that C11 requires <math.h> to define math_errhandling (as macro or identifier with external linkage), and my assumption is that GCC's -std=gnu11 (vs. -std=c11), while it might enable language extensions, would not remove from that.
> 
> However, at least with glibc-headers-2.28-26.fc29.x86_64,
> 
>> $ cat test.c
>> #include <math.h>
>> int main() { return math_errhandling; }
> 
> fails for
> 
>> $ gcc -m32 -O -std=gnu11 test.c
>> test.c: In function ‘main’:
>> test.c:2:21: error: ‘math_errhandling’ undeclared (first use in this function)
>>  int main() { return math_errhandling; }
>>                      ^~~~~~~~~~~~~~~~
>> test.c:2:21: note: each undeclared identifier is reported only once for each function it appears in

This looks like a bug.

> 
> while it succeeds for
> 
>> $ gcc -m32 -O -std=c11 test.c
> 
> What causes the difference is apparently the block
> 
>> /* Disable x87 inlines when -fpmath=sse is passed and also when we're building
>>    on x86_64.  Older gcc (gcc-3.2 for example) does not define __SSE2_MATH__
>>    for x86_64.  */
>> #if !defined __SSE2_MATH__ && !defined __x86_64__
>> # if ((!defined __NO_MATH_INLINES || defined __LIBC_INTERNAL_MATH_INLINES) \
>>      && defined __OPTIMIZE__)
>>
>> /* The inline functions do not set errno or raise necessarily the
>>    correct exceptions.  */
>> #  undef math_errhandling
> [...]
> 
> in /usr/include/bits/mathinline.h.
> 
> Now, my question is whether that is by design (implying that -std=gnu11 is deliberately non-conforming here) or by accident.

I do not think this was deliberate.
 
> (But seeing <https://sourceware.org/git/?p=glibc.git;a=commit;h=da75c1b180f9355a8b2b2584ecf1fcfe03f7107e> "Remove x86 mathinline.h" completely dropping sysdeps/x86/fpu/bits/mathinline.h from later glibc probably makes the question somewhat moot.)

The gnu11 standard should be C11 + GNU extensions, and should not remove
extensions that are part of the standard (unless there is some kind of
conflict in which case the GNU standard wins out since you requested
that).

However, as you say, the point is moot, but may effect downstream
distributions based on glibc 2.28. I would file a bug with your
distribution if you observe this bug.

Joseph,

Do you remember ever seeing this issue?

-- 
Cheers,
Carlos.

Re: math_errhandling getting undef'ed for -std=gnu11?

[Joseph Myers]

On Wed, 30 Jan 2019, Carlos O'Donell wrote:

> Joseph,
> 
> Do you remember ever seeing this issue?

No.  It looks like that #undef should have been in a fast-math-only 
section of bits/mathinline.h, as only relating to fast-math inlines (but 
then it wouldn't have served any purpose, because math/math.h avoided 
defining math_errhandling for fast-math, before commit 
3c7d03129498e7426855b5d4cdd5b7109ecc2172, and defines it to 0 for 
fast-math, since then.

-- 
Joseph S. Myers
joseph@codesourcery.com