From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 127355 invoked by alias); 30 Jan 2019 16:30:45 -0000 Mailing-List: contact libc-help-help@sourceware.org; run by ezmlm Precedence: bulk List-Subscribe: List-Post: List-Help: , Sender: libc-help-owner@sourceware.org Received: (qmail 127344 invoked by uid 89); 30 Jan 2019 16:30:45 -0000 Authentication-Results: sourceware.org; auth=none X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,RCVD_IN_DNSWL_NONE autolearn=no version=3.3.2 spammy=accident, HTo:U*libc-help, Bergmann, undef'ed X-HELO: mail-vs1-f45.google.com Received: from mail-vs1-f45.google.com (HELO mail-vs1-f45.google.com) (209.85.217.45) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Jan 2019 16:30:44 +0000 Received: by mail-vs1-f45.google.com with SMTP id x64so88099vsa.5 for ; Wed, 30 Jan 2019 08:30:43 -0800 (PST) Return-Path: Received: from [10.150.73.190] (144.sub-174-228-146.myvzw.com. [174.228.146.144]) by smtp.gmail.com with ESMTPSA id j95sm2059675uad.6.2019.01.30.08.30.41 (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 30 Jan 2019 08:30:41 -0800 (PST) Subject: Re: math_errhandling getting undef'ed for -std=gnu11? To: Stephan Bergmann , libc-help@sourceware.org, "Joseph S. Myers" References: From: Carlos O'Donell Openpgp: preference=signencrypt Message-ID: Date: Wed, 30 Jan 2019 16:30:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2019-01/txt/msg00059.txt.bz2 On 1/30/19 4:18 AM, Stephan Bergmann wrote: > My understanding is that C11 requires 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 >> 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 "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.