From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: by sourceware.org (Postfix, from userid 48) id 6E9143858403; Sat, 25 Sep 2021 21:27:32 +0000 (GMT) DKIM-Filter: OpenDKIM Filter v2.11.0 sourceware.org 6E9143858403 From: "pc at us dot ibm.com" To: gcc-bugs@gcc.gnu.org Subject: [Bug target/102485] New: -Wa,-many no longer has any effect Date: Sat, 25 Sep 2021 21:27:32 +0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: new 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: pc at us dot ibm.com X-Bugzilla-Status: UNCONFIRMED X-Bugzilla-Resolution: 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter target_milestone Message-ID: 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: Sat, 25 Sep 2021 21:27:32 -0000 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D102485 Bug ID: 102485 Summary: -Wa,-many no longer has any effect Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: target Assignee: unassigned at gcc dot gnu.org Reporter: pc at us dot ibm.com Target Milestone: --- The assembler option "-many" tells the assembler to support assembly of instructions from any vintage of processor. This can be passed through the = GCC compiler using the command line option "-Wa,-many". The "-many" functionality has been under attack of late. ;-) It once was that GCC would always pass "-many" to the assembler. This was stopped with commit e154242724b084380e3221df7c08fcdbd8460674 "Don't pass -m= any to the assembler". A recent change to binutils, commit b25f942e18d6ecd7ec3e2d2e9930eb4f996c258a "ignore sticky options for .machine" stopped preserving "sticky" options across a base `.machine` directive. This change caused sequences li= ke: .machine altivec .machine power5 ...to disable AltiVec instructions afterward, because "power5" did not supp= ort AltiVec, and "power5" is a base ".machine" directive. A perhaps unintended consequence is that using GCC to pass "-many" to the assembler (via "-Wa,-many") has no effect because GCC adds a base ".machine" directive to every(?) assembler file given to the assembler, but only passes "-many" (no ".machine" directives are added). The assember sees the "-many" parameter, then sees the base ".machine" directive, and suppresses any impa= ct of the "-many" parameter. -- mfppr32.c: long f () { long ppr; asm volatile ("mfppr32 %0" : "=3Dr"(ppr)); return ppr; } -- $ gcc -c ./mfppr32.c gcc -c ./mfppr32.c /tmp/ccAShoDb.s: Assembler messages: /tmp/ccAShoDb.s:18: Error: unrecognized opcode: `mfppr32' $ gcc -Wa,-many ./mfppr32.c /tmp/cc0tRDPx.s: Assembler messages: /tmp/cc0tRDPx.s:18: Error: unrecognized opcode: `mfppr32' $ gcc -S -Wa,-many -O ./mfppr32.c $ cat mfppr32.s [edited for brevity] .file "mfppr32.c" .machine ppc .section ".text" .globl f .type f, @function f: mfppr32 3 blr $ as mfppr32.s mfppr32.s: Assembler messages: mfppr32.s:12: Error: unrecognized opcode: `mfppr32' With older binutils, this worked: $ older-as mfppr32.s $ -- If binutils assembler (as) is doing the right thing now with respect to the base ".machine" directives and sticky ".machine" directives, then it would perhaps be GCCs responsibility to build an assembler file that allows for passing the "-many" assembler command line option through GCC and have that continue to work as likely expected.=