This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Pass -mtune and -march options to assembler.
Richard Sandiford wrote:
>>> ...here is that it isn't an "either/or". Both approaches are only
>>> useful if we do them right, and if we do do them right, they're
>>> _independently_ useful.
>> Yes, I think you've made a convincing argument for that. However, the
>> use of specs should be limited to the compilation of .s files, where the
>> compiler itself is not involved;
> But this is what I disagree with. I'm not sure whether what you say
> is an opinion or a policy.
Fortunately for all of us, I don't get to make policy unilaterally. :-)
I'm arguing for what I think the policy should be, though.
> Yes, but the same is equally true the other way round: in the case
> of compilation to object files, there's no need for directives if
> we have working specs.
An assembly file generated by the compiler is intended for use on a
specific CPU. The compiler made a bunch of decisions predicated on that
CPU. Those include optimization choices, but they may also include
questions about functionality (don't use these ISA instructions), or
work-arounds for buggy hardware, etc. If the assembler needs to care
about this stuff, it should have a view of the world consistent with the
compiler. Otherwise, passing the assembly file to the assembler is
going to result in the assembler possibly undoing the work of the compiler.
The most robust way to ensure that consistent view of the world is to
include the information in the assembly file, not to hope that specs
processing at some later date, possibly with a different GCC, results in
the right information being passed to the assembler.
I agree with you that people *should* assemble .s files with "gcc".
But, in practice, many of them assemble them with "as" -- just as many
people link with "ld". (We still install these tools in $bindir, not in
$libexecdir, which is what we should do if we really don't want people
using them...) In any case, relying on specs is error-prone; it's
subject to users failing to pass the right flags, invoking the wrong
tool, and on changes to specs processing over time. In contrast,
putting the information in the assembly file accurately conveys the
user's intent when performing the initial compilation.
If you want to have a way to override those settings on the
command-line, fine. I'd argue you should get a warning in that case,
but not all that strongly. But, I will (or I guess I *have*) argued
strongly that the compiler and assembler should be considered a logical
whole, and that in that context it makes sense for the compiler's output
to be complete input to the assembler, independent of any other options.
(650) 331-3385 x713