From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 60321 invoked by alias); 27 Nov 2017 22:41:03 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 60310 invoked by uid 89); 27 Nov 2017 22:41:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.3 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KB_WAM_FROM_NAME_SINGLEWORD,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=no version=3.3.2 spammy=HContent-Transfer-Encoding:8bit X-HELO: mail-ot0-f181.google.com Received: from mail-ot0-f181.google.com (HELO mail-ot0-f181.google.com) (74.125.82.181) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 27 Nov 2017 22:41:02 +0000 Received: by mail-ot0-f181.google.com with SMTP id 18so25728181oty.9 for ; Mon, 27 Nov 2017 14:41:01 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding; bh=naQV9YZA+wlDtCc8bkv5ErQvUIpVr9JY5Is76WnFHyo=; b=JKZnSsx1EFG/kqEHcF4gtcl/9UR9qYQG52vRELG/q9oPiaPjbxqoB/S2THDlfKjJER Fv6rNpR7MpDpUrkcnS8oV+9/bLYLxmXP8ypq3lexLupHP0vCHo/RoYnd+FsFwJBZePSv THfK5jT9a6u1Z/auWcc80UwKrZrSJGBh5L51Fsgx9+CcCC0csuh16n/2b53LnPj/VQw8 dvjdmmRiTB3gb7OuP0+hhDMnqhaqI4hiq10RwZlo8VwiAvIPFdWqTLhJjszGjtFHKEBI 1xxNwPTppsUyc1PNTXDLIE65gVZSk9az/5hpxUuOY9Qi5ZN2jSmcll+k7Pa9YdjupXAO T1TA== X-Gm-Message-State: AJaThX7jzxiA+nuzNzSQM3KqgNnubtygnIP0YIveiLe1zPfPlKIIp5aD SAsrP0WHTChztTQr5QvKSCc= X-Google-Smtp-Source: AGs4zMYLh722uGdVip9GUhQqHPTx1bQWvkdHO+8+HOn592vgdI7mm3hUQPOMthAOb/XQGeDpIU8tEQ== X-Received: by 10.157.15.186 with SMTP id d55mr29120965otd.262.1511822460307; Mon, 27 Nov 2017 14:41:00 -0800 (PST) Received: from localhost.localdomain (75-171-240-43.hlrn.qwest.net. [75.171.240.43]) by smtp.gmail.com with ESMTPSA id v126sm12180891oif.4.2017.11.27.14.40.58 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Mon, 27 Nov 2017 14:40:59 -0800 (PST) Subject: Re: [PATCH] PR libgcc/83112, Fix warnings on libgcc float128-ifunc.c To: Michael Meissner , GCC Patches , Segher Boessenkool , David Edelsohn , Bill Schmidt References: <20171127192131.GA15914@ibm-tiger.the-meissners.org> From: Martin Sebor Message-ID: Date: Mon, 27 Nov 2017 22:55:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0 MIME-Version: 1.0 In-Reply-To: <20171127192131.GA15914@ibm-tiger.the-meissners.org> Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 8bit X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg02341.txt.bz2 On 11/27/2017 12:21 PM, Michael Meissner wrote: > The new -Wattribute-alias option now issues warnings for old-style ifunc > declarations that coerce the pointer to the function to void *. The > float128-ifunc.c module in libgcc/config/rs6000 now gets a lot of warnings of > the form: > > ../float128-ifunc.c:109:1: warning: ‘ifunc’ resolver for ‘__negkf2’ should > return ‘TFtype (*)(TFtype) {aka _Float128 (*)(_Float128)}’ [-Wattribute-alias] > > This patch fixes these warnings. I have done a full bootstrap build and test > suite run. I have verified that the ifunc handler works correctly, using > software emulation on a power8 and the hardware instructions on power9. Can I > check this into the trunk? Just as a side note, a convenient way to deal with this is to use typeof to deduce the return type of the resolver from the type of the function it returns. I would expect something like the following untested change to do it and make the typedefs unnecessary: -static void * +static __typeof__ (__addkf3_sw) * __addkf3_resolve (void) { - return (void *) SW_OR_HW (__addkf3_sw, __addkf3_hw); + return SW_OR_HW (__addkf3_sw, __addkf3_hw); } Martin