[llvm-bugs] [Bug 35141] New: reconsider when we automatically define _GNU_SOURCE
via llvm-bugs
llvm-bugs at lists.llvm.org
Mon Oct 30 16:24:06 PDT 2017
https://bugs.llvm.org/show_bug.cgi?id=35141
Bug ID: 35141
Summary: reconsider when we automatically define _GNU_SOURCE
Product: clang
Version: unspecified
Hardware: PC
OS: Linux
Status: NEW
Severity: enhancement
Priority: P
Component: C++
Assignee: unassignedclangbugs at nondot.org
Reporter: richard-llvm at metafoo.co.uk
CC: dgregor at apple.com, llvm-bugs at lists.llvm.org
Currently, Clang follows GCC in automatically defining _GNU_SOURCE when
compiling C++ on a glibc platform. We should revisit this.
We need _GNU_SOURCE for the following:
1) GNU extensions used by user code.
2) GNU extensions used in the implementation of libstdc++.
3) C99 and C11 extensions.
For case #1, we could ask the user to provide -D_GNU_SOURCE explicitly on the
command line when compiling C++, as they are required to when compiling C. This
would break compatibility with GCC, though, so isn't obviously a win, but would
equally allow us to accept valid code that -D_GNU_SOURCE rejects. Perhaps a
separate flag for controlling this would be best.
For case #2, we may be able to get away with a smaller set of extensions. In
particular, _ISOC99_SOURCE and _ISOC11_SOURCE appear to be sufficient to
support most or all of libstdc++, and also appear to be sufficient for libc++.
Case #3 just needs _ISOC99_SOURCE / _ISOC11_SOURCE. (glibc should really be
able to figure this one out for itself based on the value of __cplusplus, but
it doesn't seem to do so today.)
At the very least, we should define _ISOCxx_SOURCE automatically based on the
C++ language mode, so that users need only pass -U_GNU_SOURCE to get a working
C++ compilation without the extensions. (Unfortunately, even this is not easy
right now, as the code adding this define is scattered throughout our target
definitions.)
--
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20171030/889c901c/attachment.html>
More information about the llvm-bugs
mailing list