This is the mail archive of the glibc-bugs@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug libc/14952] New: sys/cdefs.h does not define __extern_inline for Clang++


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]