On Mon, 10 Mar 2025, Jacek Caban wrote:
On 10.03.2025 14:48, Martin Storsjö wrote:
On Wed, 5 Mar 2025, Jacek Caban wrote:
Based on Wine code by Piotr Caban and Alexandre Julliard, who granted
permission to use it under the mingw-w64 license.
Unlike earlier versions, msvcr120 and UCRT implement fenv.h, but
their representation differs from what mingw-w64
has used so far. fenv_t has a target-independent layout and flags,
requiring translation to and from machine-specific
flags. Generic helpers handle this conversion.
Side note nitpick: The commit message here has longer lines than the
common git standard; it makes it more readable in 80 char wide
terminals if it would be word wrapped to the usual git commit message
width :-)
I didn't know we're sticking with that, I will change it.
I'm not sure if we have such a practice formalized (and I'm not sure if
others agree/disagree/care), but that's at least how I make commits in
general, and I haven't noticed that others' commit messages feel out of
place either.
This could really warrant a comment explaining what it does, as 0x20
isn't a named constant.
It originates from your Wine patch:
https://gitlab.winehq.org/wine/wine/-/commit/6391a9f8978b42b71b37c27b673a0a13c21ea577
I guess it's based on testing Windows behavior, I don't know why Windows
does it. I can add a comment like "for Windows compatibility".
Thanks. I have no memory of that at all...
For aarch64 things I would have expected things to be based on how the
previous arm version did things, but I don't really see anything such
there before that commit either. (The ifdef jungle in that file doesn't
really make it easier to find either.)
It probably doesn't matter much for this patchset, but I wonder if I
should try to remove it and see if anything breaks, which would serve as
documentation for it. (If I ever get to that, and come up with such a
change for Wine, it should be simple to adapt this code in mingw
similarly.)
This bit feels a bit asymetrical; in fesetenv we use our own
__mingw_setfp for setting things, but in fegetenv we just use
_controlfp() and _statusfp() from the CRT. (This is also a bit of a
functional change as we've been entirely detached from the CRT's
handling of this bit so far.)
It's probably fine though, but I'm wondering if this would be clearer
if we'd have our own __mingw_controlfp/__mingw_setupfp at first for
ARM/AArch64 too, so we'd have the full loop of both setting and
getting in our own code, just like before. Then we could convert
__mingw_controlfp into a call to the CRT's _controlfp in a separate step.
I will change it.
Thanks!
// Martin
_______________________________________________
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
