public inbox for glibc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libc/14952] New: sys/cdefs.h does not define __extern_inline for Clang++
@ 2012-12-13 11:28 matti.niemenmaa+sourcesbugs at iki dot fi
  2013-05-03  1:16 ` [Bug libc/14952] " allan at archlinux dot org
  2014-06-14  5:37 ` fweimer at redhat dot com
  0 siblings, 2 replies; 3+ messages in thread
From: matti.niemenmaa+sourcesbugs at iki dot fi @ 2012-12-13 11:28 UTC (permalink / raw)
  To: glibc-bugs

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.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug libc/14952] sys/cdefs.h does not define __extern_inline for Clang++
  2012-12-13 11:28 [Bug libc/14952] New: sys/cdefs.h does not define __extern_inline for Clang++ matti.niemenmaa+sourcesbugs at iki dot fi
@ 2013-05-03  1:16 ` allan at archlinux dot org
  2014-06-14  5:37 ` fweimer at redhat dot com
  1 sibling, 0 replies; 3+ messages in thread
From: allan at archlinux dot org @ 2013-05-03  1:16 UTC (permalink / raw)
  To: glibc-bugs

http://sourceware.org/bugzilla/show_bug.cgi?id=14952

Allan McRae <allan at archlinux dot org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |allan at archlinux dot org
         Resolution|                            |FIXED

--- Comment #1 from Allan McRae <allan at archlinux dot org> 2013-05-03 01:16:30 UTC ---
Fixed in:

commit 0695940b8ab4b7e69492e8ea071d19fc17dda092
Author: Richard Smith <richard@metafoo.co.uk>
Date:   Wed May 1 20:32:38 2013 +1000

    Use __gnu_inline__ for __extern_always_inline in g++-4.2

-- 
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.


^ permalink raw reply	[flat|nested] 3+ messages in thread

* [Bug libc/14952] sys/cdefs.h does not define __extern_inline for Clang++
  2012-12-13 11:28 [Bug libc/14952] New: sys/cdefs.h does not define __extern_inline for Clang++ matti.niemenmaa+sourcesbugs at iki dot fi
  2013-05-03  1:16 ` [Bug libc/14952] " allan at archlinux dot org
@ 2014-06-14  5:37 ` fweimer at redhat dot com
  1 sibling, 0 replies; 3+ messages in thread
From: fweimer at redhat dot com @ 2014-06-14  5:37 UTC (permalink / raw)
  To: glibc-bugs

https://sourceware.org/bugzilla/show_bug.cgi?id=14952

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.


^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2014-06-14  5:37 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2012-12-13 11:28 [Bug libc/14952] New: sys/cdefs.h does not define __extern_inline for Clang++ matti.niemenmaa+sourcesbugs at iki dot fi
2013-05-03  1:16 ` [Bug libc/14952] " allan at archlinux dot org
2014-06-14  5:37 ` fweimer at redhat dot com

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).