On Tuesday 24 June 2025 17:13:01 Martin Storsjö wrote: > On Tue, 24 Jun 2025, Martin Storsjö wrote: > > > On Tue, 24 Jun 2025, Pali Rohár wrote: > > > > > When I run tests manually at the time of sending those my changes, they > > > passed on 32-bit msvcrt locally. > > > > FWIW, you probably have old headers lying around in your sysroot if you > > don't notice the issue with the missing _mingw_print_push.h header, > > which has been removed since 2018.
I mean that my newly added tests passed on 32-bit msvcrt library. There were failures of some existing tests. > > > Maybe the test suite is using system mingw-w64 libs instead of locally > > > compiled? And it is needed to first install mingw-w64 libs before > > > running test suite? Just guessing. > > > > Sorry about this, this was indeed the case. I did install the headers, > > but the build system had decided to install the files into > > <prefix>/lib32 instead of the expected <prefix>/lib directory, for 32 > > bit cases, so those cases didn't use the newly built files. > > > > (And the issues with ucrtbase also seemed to be a case of this.) > > > > With this fixed, most tests do build correctly. tstmain_sys_xxx.c fails > > to link in UCRT mode, and t_ansi_io.c still depends on a header removed > > in 2018 though. > > > > With this in place, I did see that a recently pushed patch actually did > > regress the t_stat_slash test; I'll send a patch for that too. > > After extending the testing to armv7 and aarch64 too, I run into errors that > fseeko64 is missing in libmsvcrt-os.a on armv7 and aarch64. Now I quickly looked at it and I see where is the problem. fseeko64 and ftello64 aliases are not defined for arm msvcrt builds. Could you try this change? diff --git a/mingw-w64-crt/def-include/crt-aliases.def.in b/mingw-w64-crt/def-include/crt-aliases.def.in index 1edb042baf94..4f89318789f2 100644 --- a/mingw-w64-crt/def-include/crt-aliases.def.in +++ b/mingw-w64-crt/def-include/crt-aliases.def.in @@ -321,10 +321,12 @@ stat64i32 == _stat64i32 #if defined(NO_FIXED_SIZE_64_ALIAS) && !defined(NO_FSTAT64_ALIAS) fstat64 == _fstat64 #endif +#ifdef WITH_FSEEKO64_FTELLO64_ALIASES +fseeko64 == _fseeki64 +ftello64 == _ftelli64 +#endif #else fstat64 == _fstat64 -#endif -#ifndef FIXED_SIZE_SYMBOLS fseeko64 == _fseeki64 ftello64 == _ftelli64 #endif diff --git a/mingw-w64-crt/lib-common/msvcrt.def.in b/mingw-w64-crt/lib-common/msvcrt.def.in index 1fa3ffc9ad3a..4608b0245cf9 100644 --- a/mingw-w64-crt/lib-common/msvcrt.def.in +++ b/mingw-w64-crt/lib-common/msvcrt.def.in @@ -1930,5 +1930,6 @@ F_I386(_libm_sse2_tan_precise) #endif #if defined(__arm__) || defined(__aarch64__) #define USE_WCSTOK_S_FOR_WCSTOK +#define WITH_FSEEKO64_FTELLO64_ALIASES #endif #include "crt-aliases.def.in" > And on aarch64 on ucrt, t_aligned_alloc ends up with this failure: > > ../testcases/t_aligned_alloc.c:97: _aligned_msize: ptr 0x000001612540FA80 > has incorrect size 2000 > > So it would seem that _aligned_realloc() to shrink an allocation didn't > actually choose to shrink it at all. > > // Martin UCRT does not use any mingw-w64 emulation of those aligned alloc / size functions. So if that test is failing then it has to be an UCRT issue. Seems that in this case _aligned_realloc() does not shrink the allocation or it does not update information for _aligned_msize correctly. Could you verify that the final test exe binary is really using UCRT functions and not mingw-w64 emulations? (Just in case that there is not a bug in mingw-w64 CRT import library / linking). _______________________________________________ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
