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
