public inbox for
 help / color / mirror / Atom feed
From: Richard Earnshaw <>
To: Nick Clifton <>,
	Thomas Schwinge <>,
	Tom de Vries <>,,
Subject: Re: Forward GCC '-v' command-line option to binutils assembler, linker (was: [PING] nvptx: forward '-v' command-line option to assembler, linker)
Date: Thu, 22 Sep 2022 13:46:58 +0100	[thread overview]
Message-ID: <> (raw)
In-Reply-To: <>

On 22/09/2022 12:32, Nick Clifton via Gcc wrote:
> Hi Thomas,
>>>> +/* 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?
> Not really no.  Historically of course this has not been done, so changing
> it now might surprise a few users.  But it should not be that big of an
> issue.
>>> So, any particular reason why we would do things differently for
>>> nvptx?
> Nope, none at all.
> Harmonizing the effect of the -v option sounds like a good idea to me.
> Cheers
>    Nick

What's wrong with users passing -Wa,-v or -Wl,-v to pass the option 
through to the assembler and linker respectively?  The more flags like 
this we force pass to the additional tools the more likely we are to 
have problems when that tool is not from the GNU toolchain.


      reply	other threads:[~2022-09-22 12:47 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <MentorEmbedded/nvptx-tools/pull/>
     [not found] ` <MentorEmbedded/nvptx-tools/pull/31/>
     [not found]   ` <>
     [not found]     ` <>
     [not found]       ` <>
     [not found]         ` <>
2022-09-21  9:21           ` Thomas Schwinge
2022-09-22 11:32             ` Nick Clifton
2022-09-22 12:46               ` Richard Earnshaw [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \ \ \ \ \ \ \ \

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).