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
