[PATCH] [ARM] Keep track of previous changes to the bit pattern stored HW_FP

Ranjeet Singh 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
  if (HW_FP)
    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 mailing list