public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
To: Kugan Vivekanandarajah <kugan.vivekanandarajah@linaro.org>
Cc: Richard Biener <richard.guenther@gmail.com>,
	GCC Patches <gcc-patches@gcc.gnu.org>,
	Bernhard Reutner-Fischer <rep.dot.nop@gmail.com>
Subject: Re: [PR47785] COLLECT_AS_OPTIONS
Date: Mon, 28 Oct 2019 22:02:00 -0000	[thread overview]
Message-ID: <20191028225229.6e15d314@nbbrfq.loc> (raw)
In-Reply-To: <CAELXzTPNeXjRUYGmExzobs6+WiEpNx_5SBuDyz7D7t-xhSBMvw@mail.gmail.com>

On Mon, 28 Oct 2019 11:53:06 +1100
Kugan Vivekanandarajah <kugan.vivekanandarajah@linaro.org> wrote:

> On Wed, 23 Oct 2019 at 23:07, Richard Biener <richard.guenther@gmail.com> wrote:

> > Did you try this with multiple assembler options?  I see you stream
> > them as -Wa,-mfpu=xyz,-mthumb but then compare the whole
> > option strings so a mismatch with -Wa,-mthumb,-mfpu=xyz would be

indeed, i'd have expected some kind of sorting, but i don't see it in
the proposed patch?

> > diagnosed.  If there's a spec induced -Wa option do we get to see
> > that as well?  I can imagine -march=xyz enabling a -Wa option
> > for example.
> >
> > +             *collect_as = XNEWVEC (char, strlen (args_text) + 1);
> > +             strcpy (*collect_as, args_text);
> >
> > there's strdup.  Btw, I'm not sure why you don't simply leave
> > the -Wa option in the merged options [individually] and match
> > them up but go the route of comparing strings and carrying that
> > along separately.  I think that would be much better.
> 
> Is attached patch which does this is OK?

> +  obstack_init (&collect_obstack);
> +  obstack_grow (&collect_obstack, "COLLECT_AS_OPTIONS=",
> +		sizeof ("COLLECT_AS_OPTIONS=") - 1);
> +  obstack_grow (&collect_obstack, "-Wa,", strlen ("-Wa,"));

Why don't you grow once, including the "-Wa," ?

> +/* Append options OPTS from -Wa, options to ARGV_OBSTACK.  */
> +
> +static void
> +append_compiler_wa_options (obstack *argv_obstack,
> +			    struct cl_decoded_option *opts,
> +			    unsigned int count)
> +{
> +  static const char *collect_as;
> +  for (unsigned int j = 1; j < count; ++j)
> +    {
> +      struct cl_decoded_option *option = &opts[j];

Instead of the switch below, why not just

if (option->opt_index != OPT_Wa_)
  continue;

here?

> +      if (j == 1)
> +	collect_as = NULL;

or at least here?

(why's collect_as static in the first place? wouldn't that live in the parent function?)

> +      const char *args_text = option->orig_option_with_args_text;
> +      switch (option->opt_index)
> +	{
> +	case OPT_Wa_:
> +	  break;
> +	default:
> +	  continue;
> +	}

  reply	other threads:[~2019-10-28 21:52 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2019-10-02  8:39 Kugan Vivekanandarajah
2019-10-02 10:41 ` Richard Biener
2019-10-11  5:42   ` Kugan Vivekanandarajah
2019-10-11 11:37     ` Richard Biener
2019-10-21  9:22       ` Kugan Vivekanandarajah
2019-10-23 12:12         ` Richard Biener
2019-10-28  3:32           ` Kugan Vivekanandarajah
2019-10-28 22:02             ` Bernhard Reutner-Fischer [this message]
2019-10-28 22:11               ` Richard Earnshaw
2019-10-29  7:53                 ` Bernhard Reutner-Fischer
2019-10-29  9:02                   ` Richard Biener
2019-10-28 22:36               ` Kugan Vivekanandarajah
2019-10-29 16:26             ` H.J. Lu
2019-11-01  1:33               ` Kugan Vivekanandarajah
2019-11-01 15:49                 ` H.J. Lu
2019-11-04  2:46                   ` Kugan Vivekanandarajah
2019-11-04 16:57                     ` H.J. Lu
2019-11-04 23:17                       ` Kugan Vivekanandarajah
2019-11-05 12:08                         ` Richard Biener
2019-11-08  2:36                           ` Kugan Vivekanandarajah
2019-11-14 12:30                             ` Richard Biener
2020-01-08 10:20                           ` Prathamesh Kulkarni
2020-01-15  9:47                             ` Prathamesh Kulkarni
2020-01-17 17:04                               ` H.J. Lu
2020-01-20 10:32                             ` Richard Biener
2020-01-24  8:29                               ` Prathamesh Kulkarni
2020-01-28 12:06                                 ` Richard Biener
2020-01-30  7:10                                   ` Prathamesh Kulkarni
2020-01-30 13:49                                     ` Richard Biener
2020-02-03 11:37                                       ` Prathamesh Kulkarni
2020-02-04 14:14                                         ` Richard Biener
2020-02-06 12:49                                           ` Prathamesh Kulkarni
2020-02-06 13:12                                             ` Richard Biener
2020-02-06 14:34                                               ` Prathamesh Kulkarni
2020-02-17  9:28                                                 ` Prathamesh Kulkarni
2020-02-17 14:22                                                   ` Richard Biener
2020-02-18 12:52                                                     ` Prathamesh Kulkarni
2020-02-18 14:10                                                       ` Richard Biener
2020-02-18 23:19                                                         ` Prathamesh Kulkarni
2020-02-19 14:24                                                           ` Richard Biener
2020-02-24  6:32                                                             ` Prathamesh Kulkarni
2020-02-24 13:10                                                               ` Christophe Lyon
2020-02-25  6:18                                                                 ` Prathamesh Kulkarni
2021-04-09 20:16                                                               ` [GCC 9] " H.J. Lu
2021-04-12  9:40                                                                 ` Richard Biener

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:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

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

  git send-email \
    --in-reply-to=20191028225229.6e15d314@nbbrfq.loc \
    --to=rep.dot.nop@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=kugan.vivekanandarajah@linaro.org \
    --cc=richard.guenther@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* 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).