From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from helium.openadk.org (helium.openadk.org [IPv6:2a00:1828:2000:679::23]) by sourceware.org (Postfix) with ESMTPS id 19036385841A for ; Wed, 23 Feb 2022 17:34:26 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 19036385841A Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=openadk.org Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=openadk.org Received: by helium.openadk.org (Postfix, from userid 1000) id DE04031E050D; Wed, 23 Feb 2022 18:34:24 +0100 (CET) Date: Wed, 23 Feb 2022 18:34:24 +0100 From: Waldemar Brodkorb To: Alan Modra Cc: Peter Bergner , Waldemar Brodkorb , binutils@sourceware.org Subject: Re: regression with binutils 2.28 for ppc Message-ID: References: <8b8a3144-5c59-786f-a2ba-6f8813d60845@linux.ibm.com> <1f433717-0b26-4c53-6f21-9efeab7dcdc7@linux.ibm.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: X-Operating-System: Linux 5.10.0-10-amd64 x86_64 X-Spam-Status: No, score=-8.7 required=5.0 tests=BAYES_00, GIT_PATCH_0, KAM_DMARC_STATUS, SPF_HELO_NONE, SPF_PASS, TXREP, T_SCC_BODY_TEXT_LINE autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: binutils@sourceware.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Binutils mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 23 Feb 2022 17:34:27 -0000 Hi Alan, Alan Modra wrote, > All things considered, I think all I can do in gas is to partially > revert commit b25f942e18d6 which made .machine more strict. At least > that way -many (passed by release gcc) or other user sticky -Wa > options like -maltivec will not be lost. Bad luck if a user wants > -mcpu=power9 -Wa,-power10 for example. > > * config/tc-ppc.c (ppc_machine): Treat an early .machine specially, > keeping sticky options to work around gcc bugs. > > diff --git a/gas/config/tc-ppc.c b/gas/config/tc-ppc.c > index 054f9c72161..89bc7d3f9b9 100644 > --- a/gas/config/tc-ppc.c > +++ b/gas/config/tc-ppc.c > @@ -5965,7 +5965,30 @@ ppc_machine (int ignore ATTRIBUTE_UNUSED) > options do not count as a new machine, instead they add > to currently selected opcodes. */ > ppc_cpu_t machine_sticky = 0; > - new_cpu = ppc_parse_cpu (ppc_cpu, &machine_sticky, cpu_string); > + /* Unfortunately, some versions of gcc emit a .machine > + directive very near the start of the compiler's assembly > + output file. This is bad because it overrides user -Wa > + cpu selection. Worse, there are versions of gcc that > + emit the *wrong* cpu, not even respecting the -mcpu given > + to gcc. See gcc pr101393. And to compound the problem, > + as of 20220222 gcc doesn't pass the correct cpu option to > + gas on the command line. See gcc pr59828. Hack around > + this by keeping sticky options for an early .machine. */ > + asection *sec; > + for (sec = stdoutput->sections; sec != NULL; sec = sec->next) > + { > + segment_info_type *info = seg_info (sec); > + /* Are the frags for this section perturbed from their > + initial state? Even .align will count here. */ > + if (info != NULL > + && (info->frchainP->frch_root != info->frchainP->frch_last > + || info->frchainP->frch_root->fr_type != rs_fill > + || info->frchainP->frch_root->fr_fix != 0)) > + break; > + } > + new_cpu = ppc_parse_cpu (ppc_cpu, > + sec == NULL ? &sticky : &machine_sticky, > + cpu_string); > if (new_cpu != 0) > ppc_cpu = new_cpu; > else That fixes the kernel compile for me, too. thanks Alan! best regards Waldemar