> From: Marc Glisse [mailto:marc.gli...@inria.fr] > Sent: Tuesday, August 12, 2014 5:47 PM > > > Are you sure you want something that strict? If there are floats in the > code but the compiler manages to get rid of them, it won't cause any > trouble with the ABI. Besides, if you #include a header that declares a > function returning a double, but you don't use that function, the > compilation will still fail. And if you only want to forbid float/double > at the source level, grep is a pretty good tool. I can't see a test for > __builtin_sqrt(42). No ObjC?
You raise some valid points due to the use case in mind when doing the patch, which is codes that aim to be independent of the float ABI in use on target with several float ABI. Now, that said, let's consider each point one by one. 1) Where to do the check Initially my approach was to detect whether a given execution unit is affected by the float ABI in use and was thus much less strict. It worked but needed some new hooks. After some discussion about this approach it appeared to be too complicated, difficult to make it target independent and also risky. Most importantly, it seemed unnecessary as if you don't use float at interface you probably don't use them at all. Or at least, it shouldn't be difficult to make it so. And as you can see from the PR mentioned, such approach can be useful for more use cases. About doing the test later, I believe it makes the feature a bit less useful. A float might be eliminated in a build due to an optimization but still remain in another build. I feel it more useful to tell the user that such line of code can lead to FPU being used. It also seems more natural to test such a thing in the frontend, as you process the file. However it's true that it prevents including math.h for instance. It might be a good idea to ignore prototypes. 2) Need for such an option at all Grep might work but it does not give any hint to the compiler that no float is used and therefore the file is independent of the float ABI. This is important since it allows the compiler to emit a special attribute to tell the linker about it. 3) __builtin_sqrt True, I shall try if it works with builtins. Thanks for the advice. 4) Objective C As said in the description, I'm not opposed to adding other language. It's easier to add another language than remove one after the fact because very few people use it. Therefore I preferred to have just C and C++ for now which is what I expect most of the users of such a switch to be interested in. Do you think I should add support for that language up front or can it wait a later version of the patch once people started to use it? > > I am not at all saying the approach is wrong, just making sure that's > what we want. Sure, I appreciate any constructive critics. If you are unconvinced by my arguments I'd be happy to hear about the reasons. Best regards, Thomas
