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

[Carlos O'Donell <carlos@redhat.com>]

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.