From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 2E2313858434; Thu, 24 Feb 2022 11:07:58 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 2E2313858434 From: "amodra at gmail dot com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/102485] -Wa,-many no longer has any effect Date: Thu, 24 Feb 2022 11:07:57 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: target X-Bugzilla-Version: 12.0 X-Bugzilla-Keywords: X-Bugzilla-Severity: normal X-Bugzilla-Who: amodra at gmail dot com X-Bugzilla-Status: RESOLVED X-Bugzilla-Resolution: INVALID X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-BeenThere: gcc-bugs@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-bugs mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 24 Feb 2022 11:07:58 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102485 --- Comment #10 from Alan Modra --- I have spent some time over the last few days digging into history relevant= to this bug as part of looking into a binutils report that an ARCH=3Dpowerpc CROSS_COMPILE=3Dpowerpc-linux- pmac32_defconfig linux kernel no longer buil= ds with binutils-2.38. As a result I've partly reverted the effect of binutils commit "ignore stic= ky options for .machine", on both mainline binutils and the 2.38 branch. Given the way gcc operates, that commit was a mistake on my part. The initial .machine passed by gcc will again keep -many, -maltivec, -mvsx, -mvle, -msp= e or -mspe2 in effect. A .machine later in an assembly file, after some output = to any section (even .align counts), will be more strictly enforced. That's the best I can do to solve this mess. It does not completely fix th= is bug, which I believe is a valid complaint. For instance a user who has pow= er10 asm() but does not want gcc generated power10 code, perhaps due to a gcc co= de gen bug, might like to use -mcpu=3Dpower9 -Wa,-mpower10 on the gcc command = line.=20 Instead they would be forced to write ".machine power10" in their asm.=20 (Ideally, .machine push; .machine power10; user asm; .machine pop, on each = use of power10 instructions.) At least, that is the case for current mainline = gcc and binutils-2.38 where even "-mcpu=3Dpower9 -Wa,-many" won't work. We sim= ply cannot dictate to users that their assembly needs rewriting. A lot of this came about by accident. On the gas side, it was by accident = that any of the gas command line cpu options were sticky for .machine. The inte= nt behind the sticky options was to support people writing gas command lines l= ike "-maltivec -mppc" as well as the canonical "-mppc -maltivec". When you consider that gas also needs to support multiple cpu options on a command l= ine, with the last overriding any previous selection, it is more obvious why opt= ions that add functional units like -maltivec are special. On the gcc side, we have pr59828 and commit b9f12a01bedb5 which is where gcc started to emit .machine rather than passing correct arguments to gas. Cur= rent mainline gcc continues to pass the wrong cpu to gas on the command line when multiple -mcpu options are given to gcc, as can be seen by examining -v out= put from the kernel compile mentioned above. There have been multiple gcc bug reports about that .machine directive, pr71216, pr91050, pr101393 to point = out some. This means there are versions of gcc in widespread use that pass an incorrect .machine to gas, which is why I say my gas change to make .machine more strict was a mistake. We can't expect the kernel and other users of t= he toolchain to cope with gas using wrong cpu info if -many is disabled by .machine. Of course, the bugs in .machine might have been found earlier if -many hadn't been covering them. Similarly for bugs in the linux kernel makefiles; mfsrin and mtsrin are not ppc64 instructions. Overall, I think using .machine as a workaround for pr59828 was a mistake, especially since digging into this bug reminded me that I'd submitted a conceptually simple patch to fix pr59828 by passing on all the cpu args to = gas. Which went unreviewed for a whole year before being dismissed.=