[PATCH] D98895: [X86][clang] Disable long double type for -mno-x87 option

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D98895#3232453 <https://reviews.llvm.org/D98895#3232453>, @nickdesaulniers wrote:

> Linus Torvalds' thoughts <https://lore.kernel.org/linux-pm/CAHk-=wh55h__rC6+RTH7pLLTbnBuuOXPNzGGswVDGN7C6NW1pQ@mail.gmail.com/> on the patches as a result of this change.
>
>> Those uses of 1E6L were perhaps strange, but they were only used in
>> constant compile-time expressions that were cast to 'unsigned long' in
>> the end, so how the heck did llvm end up with any floating point in
>> there?
>>
>> In this case there was really no excuse not to just use a better
>> constant, but there are other situations where it might well be quite
>> reasonable to use floating point calculations to create an integer
>> constant (eg maybe some spec describes an algorithm in FP, but the
>> implementation uses fixed-point arithmetic and has initializers that
>> do the conversion).
>>
>> Imagine for a moment that you want to do fixed-point math (perhaps
>> because you have a microcontroller without an FP unit - it's not
>> limited to just "the kernel doesn't do FP"). Further imagine just for
>> a moment that you still want some fundamental constants like PI in
>> that fixed-point format.
>>
>> The sane way to generate said constants is to do something like
>>
>>   #define FIXPT_1 (1u << FIXPT_SHIFT)
>>   #define FIXPT_FP(x) ((fixpt_t) (((x)*FIXPT_1)+0.5))
>>   #define FIXPT_PI FIXPT_FP(3.14159265)
>>
>> rather than have to do something incredibly stupid and illogical and
>> unreadable like
>>
>>   #define FIXPT_PI 205887
>>
>> So honestly, this seems to be just llvm being completely stupid. The
>> fact that you don't want to generate floating point code has *NOTHING*
>> to do with floating point literals for constant expressions.
>>
>> In fact, even if you don't want to generate floating point code -
>> again, maybe you don't have a FP unit - doesn't mean that you might
>> not want to generate normal floating point constants. You may end up
>> having explicit software floating point, and doing things like passing
>> the floating point values around manually, ie
>>
>>    union fp {
>>        uint64_t val;
>>        double fp_val;
>>   };
>>
>> and having code like
>>
>>   static const union fp sqrt2 = { .fp_val = 1.4142.... };
>>
>> and then doing all the math in 'uint64_t' just because you wrote a
>> couple of math routines yourself:
>>
>>   fp_mul(&res,  sqrt2.val, x);
>>
>> again, there's no floating point *code* generated, but that doesn't
>> mean that the compiler shouldn't allow users to use floating point
>> *values*.
>>
>> The two
>> examples above are very much not about the Linux kernel (although I
>> think we actually have a couple of places that do things exactly like
>> that) they are about generic coding issues.

I saw that and responded to it on the ClangBuiltLinux thread...

Generally, our policy is that we should do all our diagnostics in the CFE/Sema. I believe GCC implements this limitation in the code-generator, so the result is that depending on optimization settings, you don't get these errors.  I'm going to disagree with Linus, from a language design perspective, if we want to decide a type is 'illegal', we need to do so consistently, not JUST when it shows up. The Clang project has had this opinion as long as I've been around, and we've had to have GCC incompatibilities in the past as a result.  I don't see this as any different from what we have done before.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D98895/new/

https://reviews.llvm.org/D98895