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 6D7AF3858D1E for ; Fri, 2 Sep 2022 17:45:36 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6D7AF3858D1E 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 282HiZGg019815; Fri, 2 Sep 2022 12:44:35 -0500 Received: (from segher@localhost) by gate.crashing.org (8.14.1/8.14.1/Submit) id 282HiZWs019813; Fri, 2 Sep 2022 12:44:35 -0500 X-Authentication-Warning: gate.crashing.org: segher set sender to segher@kernel.crashing.org using -f Date: Fri, 2 Sep 2022 12:44:35 -0500 From: Segher Boessenkool To: "Kewen.Lin" Cc: Peter Bergner , GCC Patches , David Edelsohn Subject: Re: [PATCH] rs6000/test: Fix bswap64-4.c with has_arch_ppc64 [PR106680] Message-ID: <20220902174435.GX25951@gate.crashing.org> References: <69277846-f587-b79e-f741-a2942d326778@linux.ibm.com> <20220831152412.GP25951@gate.crashing.org> <8bf4ef90-8162-0f12-2128-f2b25ffc3240@linux.ibm.com> <20220901150414.GD25951@gate.crashing.org> <84cb6132-d9a3-6410-2b86-27e78d7afcec@linux.ibm.com> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <84cb6132-d9a3-6410-2b86-27e78d7afcec@linux.ibm.com> User-Agent: Mutt/1.4.2.3i X-Spam-Status: No, score=-3.1 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: On Fri, Sep 02, 2022 at 08:51:01AM +0800, Kewen.Lin wrote: > on 2022/9/1 23:04, Segher Boessenkool wrote: > > On Thu, Sep 01, 2022 at 05:05:44PM +0800, Kewen.Lin wrote: > >> Without any explicit -mpowerpc64 (and -mno-), I think we all agree > >> that -m64 should set OPTION_MASK_POWERPC64 in opts, conversely -m32 > >> should unset OPTION_MASK_POWERPC64 in opts. > > > > The latter only for OSes that do not handle -mpowerpc64 correctly. > > I think it's the same for the OSes that handle -mpowerpc64 correctly. No. -m32 should not set or unset POWERPC64. The two options are independent. -m64 on the other hand forces POWERPC64 to on. -m64 -mno-powerpc64 is invalid (and we do indeed error on that). But we do allow -m32 -mno-powerpc64 -m64 (silently enabling it again), urgh. > > Note that it's for the context without any explicit -mpowerpc64 (and > -mno-), assuming we don't "unset OPTION_MASK_POWERPC64 in opts" for > -m32, then the command line "-m64 -m32" would not be the same as > "-m32", since the previous "-m64" sets OPTION_MASK_POWERPC64 in opts > and it's still kept, it's unexpected. No. -m64 -m32 does not set POWERPC64! Or it shouldn't, in any case :-( Segher