From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from gate.crashing.org (gate.crashing.org [63.228.1.57]) by sourceware.org (Postfix) with ESMTP id 034453858C50 for ; Thu, 7 Apr 2022 11:10:53 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 034453858C50 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=kernel.crashing.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=kernel.crashing.org Received: from gate.crashing.org (localhost.localdomain [127.0.0.1]) by gate.crashing.org (8.14.1/8.14.1) with ESMTP id 237B9rUc013492; Thu, 7 Apr 2022 06:09:53 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 237B9qNf013491; Thu, 7 Apr 2022 06:09:52 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Thu, 7 Apr 2022 06:09:52 -0500 From: Segher Boessenkool To: "Kewen.Lin" Cc: GCC Patches , David Edelsohn , Bill Schmidt , Peter Bergner Subject: Re: [PATCH] rs6000: Guard bifs {un, }pack_{longdouble, ibm128} under hard float [PR103623] Message-ID: <20220407110952.GM614@gate.crashing.org> References: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.2 required=5.0 tests=BAYES_00, JMQ_SPF_NEUTRAL, KAM_DMARC_STATUS, SPF_HELO_PASS, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 07 Apr 2022 11:10:55 -0000 Hi! On Thu, Mar 03, 2022 at 10:11:32AM +0800, Kewen.Lin wrote: > As PR103623 shows, it's a regression failure due to new built-in > function framework, previously we guard __builtin_{un,}pack_{longdouble, > ibm128} built-in functions under hard float, so they are unavailable > with the given configuration. While with new bif infrastructure, it > becomes available and gets ICE due to incomplete supports. > > Segher and Peter pointed out that we should make them available with > soft float, I agree we can extend them to cover both soft and hard > float. But considering it's stage 4 now and this regression is > classified as P1, also the previous behavior requiring hard float > aligns with what document [1] says, I guess it may be a good idea to > fix it with the attached small patch to be consistent with the previous > behavior. Then we can extend the functionality in upcoming stage 1. Or you could just not take away the existing functionality. What makes it ICE on (at least some configurations of) 32-bit now? Can you exclude just 32-bit soft float? Segher