This is the mail archive of the
glibc-bugs@sourceware.org
mailing list for the glibc project.
[Bug libc/14952] New: sys/cdefs.h does not define __extern_inline for Clang++
- From: "matti.niemenmaa+sourcesbugs at iki dot fi" <sourceware-bugzilla at sourceware dot org>
- To: glibc-bugs at sourceware dot org
- Date: Thu, 13 Dec 2012 11:27:47 +0000
- Subject: [Bug libc/14952] New: sys/cdefs.h does not define __extern_inline for Clang++
- Auto-submitted: auto-generated
http://sourceware.org/bugzilla/show_bug.cgi?id=14952
Bug #: 14952
Summary: sys/cdefs.h does not define __extern_inline for
Clang++
Product: glibc
Version: unspecified
Status: NEW
Severity: enhancement
Priority: P2
Component: libc
AssignedTo: unassigned@sourceware.org
ReportedBy: matti.niemenmaa+sourcesbugs@iki.fi
CC: drepper.fsp@gmail.com
Classification: Unclassified
sys/cdefs.h defines __extern_inline as '__inline __attribute__
((__gnu_inline__))' for C++ only when __GNUC_PREREQ(4,3) holds. Clang claims to
be only GCC 4.2 and thus it doesn't get this definition, which means that it
also doesn't see e.g. the optimizing stdio functions in bits/stdio.h.
Clang has supported __attribute__((__gnu_inline__)) since its first stable
release, as far as I can tell: a related bug (
http://llvm.org/bugs/show_bug.cgi?id=4536 ) was fixed before said release.
Small tests with current Clang (both the 3.1 release and trunk) show that
'clang++ -D__extern_inline=__inline __attribute__((__gnu_inline__))' doesn't
seem to break stdio.h or string.h, and performance predictably improves.
Clang can't reasonably bump up its __GNUC_MINOR__ due to not having support for
the rest of GCC 4.3's functionality (see e.g.
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2012-May/021389.html ), which is why
I suggest simply defining __extern_inline for Clang the same way as for GCC >=
4.3. Allowing only stable Clang releases would mean allowing Clang >= 2.6.
Conservatively allowing only the latest release would also be fine: that's
currently 3.1, but even 3.2, which has had its third release candidate and so
should be out "soon", should be fine. Here's an example patch on top of the
current glibc git master (commit 4641d57e1e), generously allowing all released
Clang versions, i.e. >= 1.0:
diff --git i/misc/sys/cdefs.h w/misc/sys/cdefs.h
index fb6c959..b3ae9d8 100644
--- i/misc/sys/cdefs.h
+++ w/misc/sys/cdefs.h
@@ -319,8 +319,11 @@
#endif
/* GCC 4.3 and above with -std=c99 or -std=gnu99 implements ISO C99
- inline semantics, unless -fgnu89-inline is used. */
-#if (!defined __cplusplus || __GNUC_PREREQ (4,3)) && defined __GNUC__
+ inline semantics, unless -fgnu89-inline is used. Clang also does, but it
+ doesn't report GCC 4.3 compatibility so we check for it separately. */
+#if (!defined __cplusplus \
+ || __GNUC_PREREQ (4,3) \
+ || (defined __clang__ && __clang_major__ >= 1)) && defined __GNUC__
# if defined __GNUC_STDC_INLINE__ || defined __cplusplus
# define __extern_inline extern __inline __attribute__ ((__gnu_inline__))
# define __extern_always_inline \
--
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.