From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 129730 invoked by alias); 19 Sep 2017 17:07:41 -0000 Mailing-List: contact libc-alpha-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: libc-alpha-owner@sourceware.org Received: (qmail 129670 invoked by uid 89); 19 Sep 2017 17:07:40 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-1.9 required=5.0 tests=BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=ham version=3.3.2 spammy=HContent-Transfer-Encoding:8bit X-HELO: mx1.redhat.com DMARC-Filter: OpenDMARC Filter v1.3.2 mx1.redhat.com 1311852779 Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; dmarc=none (p=none dis=none) header.from=redhat.com Authentication-Results: ext-mx05.extmail.prod.ext.phx2.redhat.com; spf=fail smtp.mailfrom=fweimer@redhat.com Subject: Re: [PATCH] have ifunc resolver's return type match target To: Martin Sebor , GNU C Library References: <43124c3a-907c-3a55-4162-25cc714835c2@redhat.com> <75c41915-f805-16f5-a920-3f0bc6ccbdd7@gmail.com> From: Florian Weimer Message-ID: Date: Tue, 19 Sep 2017 17:07:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.3.0 MIME-Version: 1.0 In-Reply-To: <75c41915-f805-16f5-a920-3f0bc6ccbdd7@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit X-SW-Source: 2017-09/txt/msg00750.txt.bz2 On 08/23/2017 04:48 PM, Martin Sebor wrote: > On 08/23/2017 03:28 AM, Florian Weimer wrote: >> On 08/21/2017 12:30 AM, Martin Sebor wrote: >>> The following GCC patch has been submitted for review.  It >>> helps detect mismatches between the type of an ifunc or alias >>> declaration and the type of the resolver or alias. >>> >>>   https://gcc.gnu.org/ml/gcc-patches/2017-08/msg01103.html >>> >>> To let Glibc take advantage of this type checking and avoid >>> warnings when using the patched GCC when the change above is >>> committed, the patch below adjusts the Glibc __ifunc_resolver >>> macro to declare the ifunc resolver so that its return type >>> matches that of the target.  (I was going to wait to submit it >>> until after the GCC patch has been accepted but per Joseph's >>> suggestion I'm posting it here ahead of time.) >> >> Do we have to backport both patches to older releases, too, so that they >> keep building with a newer GCC? > > It would make sense to me if that's how Glibc usually deals with > these sorts of things (i.e., changing code to avoid new warnings). > The other (obvious) alternative is for people to suppress the > warnings when using the new compiler. Okay, I backported a few toolchain enablement patches to the 2.26 branch. Thanks, Florian