On Thursday 24 October 2024 20:02:55 LIU Hao wrote: > 在 2024-10-24 19:19, Martin Storsjö 写道: > > Thanks, this sounds reasonable. So for old x86 32 bit, this argument > > isn't relevant, and it could be concievable that these functions should > > work together with our implementations in libmingwex? > > For x86-64 those are unusable because of `long double`. > > For x86-32, probably; but I suggest we should not rely on them. It's quite > possible that the MS routines reset x87 precision to 53 bits. > > They might be safely reused for ARM and ARM64.
Currently those functions are provided by libmingwex.a library and also by particular libmsvcr*.a library. Therefore symbol is provided two times and gcc / gnu linker can chose either of them (depending on LTO and other factors). So it is not a good idea to provide symbol of standard function in two mingw-w64 libraries, when both of them are being linked. MS amd64 functions are using exclusively SSE floating point and therefore they are incompatible with application code compiled by gcc switch -mfpmath=387 or -mfpmath=both, and also when long double is used by application. Older versions of MS i386 functions (like _controlfp) were using exclusively only x87 floating point, not touching SSE and therefore not suitable for -mfpmath=sse. New versions are handling both x87 and SSE (which should be the case of msvcr120 and UCRT). But reset to 53 bit x87 precision is probably still valid argument. This could be verified and maybe some of functions enabled. For MS arm functions there is still an issue with double symbols from libmingwex.a. So until those functions are moved from libmingwex.a to individual libmsvcr*.a libraries, they should not be present in .def files. _______________________________________________ Mingw-w64-public mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
