From patchwork Tue Sep 16 11:26:18 2014 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Siddhesh Poyarekar X-Patchwork-Id: 2857 Received: (qmail 16131 invoked by alias); 16 Sep 2014 11:26:31 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Delivered-To: mailing list libc-alpha@sourceware.org Received: (qmail 16117 invoked by uid 89); 16 Sep 2014 11:26:30 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL, BAYES_00, RP_MATCHES_RCVD, SPF_HELO_PASS, SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Date: Tue, 16 Sep 2014 16:56:18 +0530 From: Siddhesh Poyarekar To: Jakub Jelinek Cc: libc-alpha@sourceware.org, David Sommerseth , carlos@redhat.com, allan@archlinux.org Subject: [PATCH v2] Make __extern_always_inline usable on clang++ again Message-ID: <20140916112618.GO6586@spoyarek.pnq.redhat.com> References: <20140916102016.GM6586@spoyarek.pnq.redhat.com> <20140916104146.GX17454@tucnak.redhat.com> MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: <20140916104146.GX17454@tucnak.redhat.com> User-Agent: Mutt/1.5.22.1-rc1 (2013-10-16) On Tue, Sep 16, 2014 at 12:41:46PM +0200, Jakub Jelinek wrote: > s/fot/for/; why are you using a separate hunk for clang instead of using the > earlier one? I thought it looked ugly when I wrote the entire conditional in one place but I notice now (since you pointed it out) that it actually makes things wrong. > > +#if !defined __extern_always_inline && defined __clang__ > > +# if defined __GNUC_STDC_INLINE__ || defined __GNUC_GNU_INLINE__ > > +# define __extern_inline extern __inline __attribute__ ((__gnu_inline__)) > > +# define __extern_always_inline \ > > + extern __always_inline __attribute__ ((__gnu_inline__)) > > +# else > > +# define __extern_inline extern __inline > > +# define __extern_always_inline extern __always_inline > > This doesn't look right. If you have clang that doesn't have gnu_inline > support, in C++ extern __inline definitely is not the right semantics. > You don't want to define the macros then. Here's the updated patch, again tested with the same program. Siddhesh [BZ #17266] * misc/sys/cdefs.h: Define __extern_always_inline for clang 4.2 and newer. diff --git a/misc/sys/cdefs.h b/misc/sys/cdefs.h index d8ee73c..6a789e7 100644 --- a/misc/sys/cdefs.h +++ b/misc/sys/cdefs.h @@ -318,8 +318,14 @@ #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) + inline semantics, unless -fgnu89-inline is used. + + clang++ identifies itself as gcc-4.2, but has support for GNU inlining + semantics, that can be checked for by using the __GNUC_STDC_INLINE_ and + __GNUC_GNU_INLINE__ macro definitions. */ +#if (!defined __cplusplus || __GNUC_PREREQ (4,3) \ + || (defined __clang__ && (defined __GNUC_STDC_INLINE__ \ + || defined __GNUC_GNU_INLINE__))) # if defined __GNUC_STDC_INLINE__ || defined __cplusplus # define __extern_inline extern __inline __attribute__ ((__gnu_inline__)) # define __extern_always_inline \