r188906 - Centralize the handling of -target-feature.

[Lang Hames]

Hi Rafael,

Are you likely to be able to make a proper fix for this soon? If not I
think it should be reverted for now - it's still broken.

Cheers,
Lang.


On Mon, Nov 18, 2013 at 4:02 PM, Lang Hames <lhames at gmail.com> wrote:

> Hi Guys,
>
> Any further thoughts on this? I'd keen to see it fixed one way or another
> - getting that warning every time ARM is assembled is less than ideal.
>
> If this is going to require some significant infrastructure changes, is
> there a reasonable short-term fix that we can apply?
>
> - Lang.
>
>
>
> On Mon, Nov 11, 2013 at 12:04 PM, Daniel Dunbar <daniel at zuster.org> wrote:
>
>> Hi Rafael,
>>
>> Here is how I see it. There are two problems:
>>
>> 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.
>>
>> 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.
>>
>> Fixing either one of these will resolve this particular issue, but fixing
>> both of them might make sense. Thoughts?
>>
>>  - Daniel
>>
>>
>>
>> On Mon, Oct 28, 2013 at 9:03 PM, Rafael Espíndola <
>> rafael.espindola at gmail.com> wrote:
>>
>>> On 28 October 2013 23:28, Lang Hames <lhames at gmail.com> wrote:
>>> > Hi Rafael,
>>> >
>>> > I noticed that as a consequence of this patch, clang is issuing the
>>> > following warning when assembling for arm:
>>> >
>>> > "'+soft-float-abi' is not a recognized feature for this target
>>> (ignoring
>>> > feature)"
>>> >
>>> > You can reproduce this (at least on Darwin, and I expect on Linux too)
>>> by
>>> > creating an empty foo.s file and running:
>>> >
>>> > clang -arch armv7 -c foo.s
>>> >
>>> > It looks like the cause of the warning is that both
>>> Clang::ConstructJob and
>>> > ClangAs::ConstructJob are both calling getARMTargetFeatures
>>> (indirectly via
>>> > getTargetFeatures), and getARMTargetFeatures always adds the
>>> abi-appropriate
>>> > flag, even when the driver was being invoked as an assembler.
>>> >
>>> > I'm not very familiar with the driver code, so I didn't want to jump
>>> in and
>>> > undo any of the useful parts of your refactor to fix this.
>>> >
>>> > Do you have any thoughts on the right way to omit this flag when
>>> assembling?
>>>
>>> Good question. These are odd "feature, but not really". It looks like
>>> the driver passes them as features because that is all that TargetInfo
>>> in "clang -cc1" will see. Some options would be
>>>
>>> * Don't pass this information as features. Call them TargetOptions or
>>> something like that and add a  virtual bool handleTargetOption.
>>> * Make them real features (attached patch).
>>> * Pass a flag to getARMTargetFeatures so that it knows the target
>>> features are being collected for the assembler.
>>>
>>> Daniel, you added this back in r91755 along with the "this is a hack"
>>> FIXME. What was the direction you wanted this to take?
>>>
>>> Cheers,
>>> Rafael
>>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-commits/attachments/20131122/7e29d2cd/attachment.html>