Clang -Wa options (for integrated as)

Folks,

Two bugs related -Wa option parsing in Clang that I could just easily
add them one after the other, but I wanted to ask for your opinion
first, as I don't even know where to start if not doing the obvious
fix.

http://llvm.org/bugs/show_bug.cgi?id=20339
http://llvm.org/bugs/show_bug.cgi?id=20700

These two bugs show that -Wa option doesn't accept much, and a look at
the driver code show me that "static void
CollectArgsForIntegratedAssembler()" is incomplete, to say the least.

The questions that pop to mind are:

1. If I just want to add a new options to "allow" default behaviour to
ignore its own flag (like -mimplitic-it=arm) and warn on improper use
or missing features (like the work around for PR20700), would that be
a good idea?

2. To implement -mfpu, I'd either have to re-use the current FPU
parsing (which is not yet centralised), or I could leave that parsing
to the underlying assembler. If that's so, do we try to validate here?
Or do we ignore any unknown syntax and just hope the receiving end
will validate and warn/error?

3. Clang basically ignores anything passed down to gas and only
validates things for the integrated assembler, shouldn't we have
similar behaviour and actually validate in our assembler?

cheers,
--renato

Folks,

Two bugs related -Wa option parsing in Clang that I could just easily
add them one after the other, but I wanted to ask for your opinion
first, as I don't even know where to start if not doing the obvious
fix.

http://llvm.org/bugs/show_bug.cgi?id=20339
http://llvm.org/bugs/show_bug.cgi?id=20700

These two bugs show that -Wa option doesn't accept much, and a look at
the driver code show me that "static void
CollectArgsForIntegratedAssembler()" is incomplete, to say the least.

The questions that pop to mind are:

1. If I just want to add a new options to "allow" default behaviour to
ignore its own flag (like -mimplitic-it=arm) and warn on improper use
or missing features (like the work around for PR20700), would that be
a good idea?

I think so (though I'm hardly the authority here, adding Chandler as
owner of the driver). That's what I did before I implemented
compression - support it in the driver, warn about it (either in the
driver or in -cc1as, I forget which). Then users with build systems
that try to compress debug info could simply disable the warning if
necessary, rather than having to have special build suport to
conditionally pass the flag only to the non-integrated linker (and the
warning would silently go away if they disabled the integrated
assembler, too, of course).

2. To implement -mfpu, I'd either have to re-use the current FPU
parsing (which is not yet centralised), or I could leave that parsing
to the underlying assembler. If that's so, do we try to validate here?
Or do we ignore any unknown syntax and just hope the receiving end
will validate and warn/error?

(I don't know enough about that stuff to have an opinion)

3. Clang basically ignores anything passed down to gas and only
validates things for the integrated assembler, shouldn't we have
similar behaviour and actually validate in our assembler?

Possibly - though of course our assembler has an API, not a command
line interface. Both -cc1 and -cc1as have to parse those options and
initialize the MCAssembler as appropriate, but we could factor that
into a common initialization and error handling down at that layer.

Not sure if that's the right refactoring (any such common handling is
just as easy (or easier) to do up in the driver - but, yeah, means one
fewer layer of explicit handling, potentially)

- David