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

[Serge Pavlov via Phabricator via llvm-commits]

sepavloff added a comment.

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.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82525