Thanks Nico, I didn't see the bug report. It'd be nice to get a test checked in that covers whatever use case is going on.
-eric On Wed, Apr 29, 2015 at 2:21 PM Nico Weber <[email protected]> wrote: > This caused PR23375. It's possible we're holding something wrong (we > didn't change how we hold things recently), but since this was advertised > as not changing behavior I reverted it for now in r236159. > > On Tue, Apr 28, 2015 at 4:18 PM, Eric Christopher <[email protected]> > wrote: > >> Author: echristo >> Date: Tue Apr 28 18:18:33 2015 >> New Revision: 236060 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=236060&view=rev >> Log: >> Stop emitting the soft-float and soft-float-abi target features >> for ARM while the backend will only ignore them. No functional >> change intended. >> >> Modified: >> cfe/trunk/lib/Driver/Tools.cpp >> >> Modified: cfe/trunk/lib/Driver/Tools.cpp >> URL: >> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=236060&r1=236059&r2=236060&view=diff >> >> ============================================================================== >> --- cfe/trunk/lib/Driver/Tools.cpp (original) >> +++ cfe/trunk/lib/Driver/Tools.cpp Tue Apr 28 18:18:33 2015 >> @@ -714,29 +714,6 @@ static void getARMTargetFeatures(const D >> const ArgList &Args, >> std::vector<const char *> &Features, >> bool ForAS) { >> - StringRef FloatABI = tools::arm::getARMFloatABI(D, Args, Triple); >> - if (!ForAS) { >> - // FIXME: Note, this is a hack, the LLVM backend doesn't actually >> use these >> - // yet (it uses the -mfloat-abi and -msoft-float options), and it is >> - // stripped out by the ARM target. We should probably pass this a new >> - // -target-option, which is handled by the -cc1/-cc1as invocation. >> - // >> - // FIXME2: 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. >> - >> - // Use software floating point operations? >> - if (FloatABI == "soft") >> - Features.push_back("+soft-float"); >> - >> - // Use software floating point argument passing? >> - if (FloatABI != "hard") >> - Features.push_back("+soft-float-abi"); >> - } >> - >> // Honor -mfpu=. >> if (const Arg *A = Args.getLastArg(options::OPT_mfpu_EQ)) >> getARMFPUFeatures(D, A, Args, Features); >> @@ -745,6 +722,7 @@ static void getARMTargetFeatures(const D >> >> // Setting -msoft-float effectively disables NEON because of the GCC >> // implementation, although the same isn't true of VFP or VFP3. >> + StringRef FloatABI = tools::arm::getARMFloatABI(D, Args, Triple); >> if (FloatABI == "soft") { >> Features.push_back("-neon"); >> // Also need to explicitly disable features which imply NEON. >> >> >> _______________________________________________ >> cfe-commits mailing list >> [email protected] >> http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits >> > >
_______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
