From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 3B6473858CDB for ; Wed, 21 Sep 2022 09:21:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 3B6473858CDB Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.93,333,1654588800"; d="scan'208";a="83441006" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 21 Sep 2022 01:21:23 -0800 IronPort-SDR: o0qMFO959VdCVdPXHoQvP8GViywLsy7knDUF6CZWSq9EG4sYcgtX/hD/uJq47Py1yOHtAu0t8Z a22vtPsgGk8y46rLojq9IXPu52e23wuhY17LwW9YYvYGtFaEh9MFXDvtliM2k6kySO5kUR6pDN g87rcW9TXniIk3/V70g4oOom1WdGDaD5XY5aodBQbWQa4kXlrGA6iBATIKlb8LEVX5/mg2Thwj HC2KpDNQ49V/c7vPBYJZ3Oh+kf/nhN9SzrIhXVJ06joqKnDIUfvDudKDLBIkR+Zd+4oCPHW82p Re8= From: Thomas Schwinge To: Tom de Vries , , CC: Carlos O'Donell Subject: Forward GCC '-v' command-line option to binutils assembler, linker (was: [PING] nvptx: forward '-v' command-line option to assembler, linker) In-Reply-To: <820c4820-aca2-29f2-8727-11aa3913ae68@suse.de> References: <874k185ak4.fsf@dem-tschwing-1.ger.mentorg.com> <871qw08orn.fsf@euler.schwinge.homeip.net> <820c4820-aca2-29f2-8727-11aa3913ae68@suse.de> User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Wed, 21 Sep 2022 11:21:01 +0200 Message-ID: <878rmd84n6.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-09.mgc.mentorg.com (139.181.222.9) To svr-ies-mbx-10.mgc.mentorg.com (139.181.222.10) X-Spam-Status: No, score=-5.9 required=5.0 tests=BAYES_00,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,RCVD_IN_MSPIKE_H2,SPF_HELO_PASS,SPF_PASS,TXREP 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: Hi! This is a question regarding command-line options for GCC vs. binutils assembler, linker. It came up during a patch review related to nvptx assembler and linker, which live outside of binutils: , and don't share the standard binutils assembler, linker framework (because they're rather different/simpler). As such they also don't share the standard binutils 'as', 'ld' command-line interface, though it's of course helpful (to users) to be compatible, as much as is feasible. I had proposed for GCC "nvptx: forward '-v' command-line option to assembler, linker" (see snippets quoted below), and during review we found: On 2022-09-05T17:02:26+0200, Tom de Vries via Gcc-patches wrote: > On 6/7/22 17:41, Thomas Schwinge wrote: >> --- a/gcc/config/nvptx/nvptx.h >> +++ b/gcc/config/nvptx/nvptx.h >> +/* Assembler supports '-v' option; handle similar to >> + '../../gcc.cc:asm_options', 'HAVE_GNU_AS'. */ >> +#define ASM_SPEC "%{v}" > The ASM_SPEC part LGTM. For reference, that GCC '-v' gets forwarded to binutils assembler is due to 'gcc/gcc.cc:asm_options': 1272 #if HAVE_GNU_AS 1273 /* If GNU AS is used, then convert -w (no warnings), -I, an= d -v 1274 to the assembler equivalents. */ 1275 "%{v} %{w:-W} %{I*} " 1276 #endif That was added by Carlos some 15 years ago; Subversion r127275 (Git commit dc60b7754db561a029e42eeb297493726f8b8b33), "Pass more options to the assembler". ('-w', '-I' are not applicable to nvptx 'as'.) But that was for binutils assembler only, not for binutils linker, so when for nvptx I additionally proposed: >> +/* Linker supports '-v' option. */ >> +#define LINK_SPEC "%{v}" ..., Tom rightfully asked: > [...] I wonder, normally we don't pass -v to ld, and need -Wl,-v for > that. So, on my quest for making things uniform/simple, I now wonder: should we also forward GCC '-v' to binutils linker, or is there a reason to not do that? (As far as I can tell, GCC 'collect2' is also already doing the right thing regarding '-v'.) I've manually run a few experiments with 'gcc -v -Wl,-v' (proposed to then simplify to just 'gcc -v'), with both binutils 'ld.bfd', 'ld.gold', and have not spotted any issues. As 'ld.mold', 'ld.lld' also identify as "compatible with GNU ld", I've likewise tested them, and again not spotted any issues. So I think we should be save to generally handle '%{v}' linker spec for all 'HAVE_GNU_LD', or does anyone see any problem with that? (I've not yet thought about where in 'gcc/gcc.cc' to place '%{v}' linker spec, guarded by '#if HAVE_GNU_LD'.) > So, any particular reason why we would do things differently for > nvptx? Let's first work out why binutils assembler vs. linker are handled differently. ;-) Gr=C3=BC=C3=9Fe Thomas ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955