Hi lang, Sorry I missed your previous message. I will just avoid passing the flag to cc1as for now and leave a FIXME on the lines Daniel Dunbar suggested.
On 22 November 2013 19:31, Lang Hames <[email protected]> wrote: > 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 <[email protected]> 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 <[email protected]> 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 >>> <[email protected]> wrote: >>>> >>>> On 28 October 2013 23:28, Lang Hames <[email protected]> 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 >>> >>> >> > _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
