This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH] Revert to defining __extern_inline only for g++-4.3+
- From: Allan McRae <allan at archlinux dot org>
- To: "Carlos O'Donell" <carlos at redhat dot com>, Siddhesh Poyarekar <siddhesh at redhat dot com>, libc-alpha at sourceware dot org
- Cc: jakub at redhat dot com
- Date: Tue, 16 Sep 2014 13:39:39 +1000
- Subject: Re: [PATCH] Revert to defining __extern_inline only for g++-4.3+
- Authentication-results: sourceware.org; auth=none
- References: <20140813182334 dot GA3507 at spoyarek dot pnq dot redhat dot com> <5417A59F dot 3090700 at redhat dot com>
On 16/09/14 12:51, Carlos O'Donell wrote:
> On 08/13/2014 02:23 PM, Siddhesh Poyarekar wrote:
>> The check for only __GNUC_STDC_INLINE__ and __GNUC_GNU_INLINE__ may
>> not be sufficient since those flags were added during initial support
>> for C99 inlining semantics. There is also a problem with always
>> defining __extern_inline and __extern_always_inline, since it enables
>> inline wrapper functions even when GNU inlining semantics are not
>> guaranteed. This, along with the possibility of such wrappers using
>> redirection (btowc for example) could result in compiler generating an
>> infinitely recusrive call to the function.
>> In fact it was such a recursion that led to this code being written
>> the way it was; see:
>> The initial change:
>> commit b7bfe116e6304da848759b69a6d713da3e93e936
>> Author: Marek Polacek <email@example.com>
>> Date: Wed Sep 26 12:58:36 2012 +0200
>> Fix up definitions for older compilers.
>> was to fix bugs 14530 and 13741, but they can be resolved by checking
>> if __fortify_function and/or __extern_always_inline are defined, as it
>> has been done in this patch.
>> I have tested this with gcc 3.2, 3.4 and 4.1. In addition, I have
>> done a quick audit of uses of __extern_always_inline and
>> __extern_inline to make sure that none of the uses can result in
>> compilation errors.
>> There is however a regression in this patch for llvm, since it reverts
>> the llvm expectation that __GNUC_STDC_INLINE__ or __GNUC_GNU_INLINE__
>> definition imply proper extern inline semantics.
>> If we don't want this fixed in 2.20 at this stage, I'd like to know if
>> we can backport to the 2.20 branch after release.
> I think this *should* be backported to 2.20.
> OK for master with one comment expansion and [BZ #17266] in ChangeLog.
I agree. Either give me a ping once it is committed or go ahead with
the backport yourself.