[PATCH] D82525: [FPEnv] Intrinsics for access to FP control modes

[Craig Topper via Phabricator via llvm-commits]

craig.topper added a comment.

In D82525#2605358 <https://reviews.llvm.org/D82525#2605358>, @sepavloff wrote:

> In D82525#2603611 <https://reviews.llvm.org/D82525#2603611>, @craig.topper wrote:
>
>> In D82525#2603275 <https://reviews.llvm.org/D82525#2603275>, @sepavloff wrote:
>>
>>> In D82525#2600598 <https://reviews.llvm.org/D82525#2600598>, @craig.topper wrote:
>>>
>>>> Is there any guarantee that femode_t will be the same layout for a given target in different C library implementations?
>>>
>>> Strictly speaking there is no such guarantee. However the obvious implementation of `femode_t` is the type used to store content of FP control register. Most of 16 targets supported by glibc use `unsigned int` as `femode_t`.  Exceptions are alpha, ia64, sparc (`unsigned long`) and powerpc (`double`). In these cases `femode_t` is identical to `fenv_t`.
>>
>> Isn't X86 using this struct which is 8 bytes?
>>
>>   typedef struct
>>     {
>>       unsigned short int __control_word;
>>       unsigned short int __glibc_reserved;
>>       unsigned int __mxcsr;
>>     }
>>   femode_t;
>
> Sure. I forget to mention x86.
>
> There are cases when size of `fenv_t` differs in different libraries. ARM uses `unsigned int` in glibc but `unsigned long` in musl.

Is `unsigned long` 32-bits in this case?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82525