<div dir="ltr">Hi Rafael,<div><br></div><div>Here is how I see it. There are two problems:</div><div><br></div><div>1. For consistency, it would be ideal if we set up the target machine state the same when using the frontend or the assembler. We don't currently do that for the assembler, we pass the options directly to the backend and never even instantiate the frontend TargetInfo. If we did, and used its handleTargetFeatures hook, then we could ensure the assembler and the frontend behave the same.</div>
<div><br></div><div>2. The use of soft-abi as a target feature is a hack, and it might be good for us to have a generic mechanism like TargetOption as you propose. This seems like general goodness.</div><div><br></div><div>
Fixing either one of these will resolve this particular issue, but fixing both of them might make sense. Thoughts?</div><div><br></div><div> - Daniel</div><div><br></div></div><div class="gmail_extra"><br><br><div class="gmail_quote">
On Mon, Oct 28, 2013 at 9:03 PM, Rafael Espíndola <span dir="ltr"><<a href="mailto:rafael.espindola@gmail.com" target="_blank">rafael.espindola@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5">On 28 October 2013 23:28, Lang Hames <<a href="mailto:lhames@gmail.com">lhames@gmail.com</a>> wrote:<br>
> Hi Rafael,<br>
><br>
> I noticed that as a consequence of this patch, clang is issuing the<br>
> following warning when assembling for arm:<br>
><br>
> "'+soft-float-abi' is not a recognized feature for this target (ignoring<br>
> feature)"<br>
><br>
> You can reproduce this (at least on Darwin, and I expect on Linux too) by<br>
> creating an empty foo.s file and running:<br>
><br>
> clang -arch armv7 -c foo.s<br>
><br>
> It looks like the cause of the warning is that both Clang::ConstructJob and<br>
> ClangAs::ConstructJob are both calling getARMTargetFeatures (indirectly via<br>
> getTargetFeatures), and getARMTargetFeatures always adds the abi-appropriate<br>
> flag, even when the driver was being invoked as an assembler.<br>
><br>
> I'm not very familiar with the driver code, so I didn't want to jump in and<br>
> undo any of the useful parts of your refactor to fix this.<br>
><br>
> Do you have any thoughts on the right way to omit this flag when assembling?<br>
<br>
</div></div>Good question. These are odd "feature, but not really". It looks like<br>
the driver passes them as features because that is all that TargetInfo<br>
in "clang -cc1" will see. Some options would be<br>
<br>
* Don't pass this information as features. Call them TargetOptions or<br>
something like that and add a  virtual bool handleTargetOption.<br>
* Make them real features (attached patch).<br>
* Pass a flag to getARMTargetFeatures so that it knows the target<br>
features are being collected for the assembler.<br>
<br>
Daniel, you added this back in r91755 along with the "this is a hack"<br>
FIXME. What was the direction you wanted this to take?<br>
<br>
Cheers,<br>
Rafael<br>
</blockquote></div><br></div>