On Fri, 14 Feb 2025, Jacek Caban wrote:
On 11.02.2025 23:11, Martin Storsjö wrote:
On Sun, 9 Feb 2025, Jacek Caban wrote:
It may also be good to include a bit of introduction in the commit
message; each time I look at fenv.h it takes a bit of time to wrap my
head around how it works, as it differs quite significantly from the
corresponding MSVC ones.
If I remember correctly, our fenv.h directly exposes the architecture
specific control words, as they are provided by the FPU. I.e. the
fenv_t data type, and the flags/masks, have entirely different
definitions across architectures.
On the other hand, the MSVC fenv.h uses architecture independent
generalized definitions outwards, that don't exactly match any
specific architecture, and the fesetenv/fegetenv functions translate
between the architecture specific interface and the external public
interface.
The more I look at it, the more I’m tempted to adjust fenv_t handling to
be closer to MSVC. I think it was originally implemented entirely in
mingwex because msvcrt lacked it before msvcr120, so there wasn’t
anything to be compatible with at the time.
I’d like to try making it compatible with UCRT, but that looks like a
significant amount of work, so I'm not yet sure. If you think it's a bad
idea, please let me know.
No that sounds totally reasonable to me.
I guess in theory it's a mild ABI break if we change the fenv.h define
values (if you'd have old existing object files or static libraries), but
it's probably tolerable.
The ARM version is much closer to the native implementation,
By native implementation, I presume you mean the MSVC one?
but even there, some of the defines have different values, likely
hardware-specific rather than abstract, as you mentioned.
Yes, I wrote our fenv.h for ARM by just defining the public defines based
on the actual FPU control register bits.
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
