[PATCH] [ARM] Keep track of previous changes to the bit pattern stored HW_FP
ranjeet.singh at arm.com
Mon Jun 22 10:04:00 PDT 2015
> Why are you testing for _ARM_FP if the core of what you're doing is adding +/- strings to -target-features? Why not test the target-features directly?
Because it's set to the value of HW_FP and HW_FP is what could get the wrong value in the previous code.
// ACLE 6.5.1 Hardware Floating Point
Builder.defineMacro("__ARM_FP", "0x" + llvm::utohexstr(HW_FP));
> If you need to test _ARM_FP, that's a different, simpler test: just put a bunch of variations and see that all of them give what you expect.
There already exists a test that checks what the value of _ARM_FP is, it's in clang/test/Preprocessor/arm-acle-6.5.c.
> I'm just saying that you should test that the expected target features are coming from the right options.
I don't mind adding a test for this but it seems unrelated to the bug I'm trying to fix in this patch, could you explain a bit more as to why you want this test?
More information about the llvm-commits