[MSWindows] 32-bit quadmath builds fail multiple tests. #21313
Comments
Just to clarify - the issue does NOT pertain to the unthreaded MSWin32-x86-perlio-quadmath and MSWin32-x86-perlio-64int-quadmath builds. As an experiment I set EXTRACFLAGS to -masm=intel in the GNUmakefile and rebuilt perl using Sanders' gcc-13.1.0 compilers. That is, the op/index_thr.t, op/substr_thr.t. re/pat_psycho_thr.t and re/speed_thr.t failures were avoided. Cheers, |
|
The problem is stack alignment. The point that at least one failing test crashes at is: movdqa is "Move Aligned Double Quadword" which requires that the address be 16-byte aligned. If I look at the similar code for lhmouse (note change to Intel syntax): This uses the movdqu instruction, which allows for unaligned addresses. __letf2 (aka __lttf2) is a function used to implement less than for __float128 values, See https://github.com/gcc-mirror/gcc/blob/master/libgcc/soft-fp/letf2.c in my case it's being called from pp_chr: If I build with AFAIK, 32-bit windows only requires 4 byte stack alignment, so SSE code should not assume that esp accesses are properly aligned. The backtraces I checked for the failing cases were in non-main threads, so I suspect CreateThread() is giving us an unaligned stack. So I took a look at threads.x and tried: (without I don't know why lhmouse is generating movdqu vs movdqa, the code here is in Note: the issue has nothing to do with intel vs AT&T syntax. |
|
It didn't fix every failure, but it did most of them: I suspect some of the other failures that involve callbacks (fork, signals) have similar fixes |
|
Diff as follows: helped a lot: I also have a simple reproducer: |
|
I'll look at cleaning this up tomorrow. |
I couldn't find the source of the winlibs build, but it seems that lhmouse's includes this patch, which seems related. There's a comment about it in the PKGBUILD file: |
|
In the bugzilla ticket it's mentioned that it's possible to force gas to always generate unaligned moves with this:
I didn't test it, but it could be the solution. |
|
Unfortunately neither is a solution we can implement, the code doing the unaligned accesses here is in Also, I expect any new mingw packagers who don't notice the issue will be broken until they notice it or gcc itself is fixed. |
This issue pertains to MSWin32-x86-multi-thread-quadmath and MSWin32-x86-multi-thread-64int-quadmath builds of perl, going back over at least the last couple of years.
All other configurations are currently fine, irrespective of whether gcc's threads model is POSIX or MCF, and irrespective of whether gcc's runtime is msvcrt or ucrt.
For the record, at time of writing, current stable release is 5.38.0, and current devel release is 5.39.0.
Over the last year or two, I have played around with a number of mingw-w64 ports of gcc provided by nixman (https://github.com/niXman/mingw-builds-binaries/releases/), by lhmouse (https://gcc-mcf.lhmouse.com/) and by Brecht Sanders (https://winlibs.com).
Most of the ones that I've tried (and there has been quite a few) have been from the winlibs website.
The 32-bit quadmath builds always fail multiple tests (irrespective of IVSIZE) - except when using lhmouse's compilers, where all tests always pass (again, irrespective of IVSIZE).
The only 3 compilers from lhmouse that I've actually tried have been a 13.0.1 snapshot, the 13.1.0 (dated 2023-04-26), and the 13.2.1 snapshot (dated 2023-07-28). All three have successfully built these 32-bit quadmath perls 5.37.10 to 5.39.1, with all tests passing.
And all 3 were built with MCF-threads && msvc runtime.
From a discussion at
https://sourceforge.net/p/mingw-w64/mailman/mingw-w64-public/thread/CADZSBj2PDJj1E64zWeWUeZ%3DrvRj7_ETbHxb6p1pBKg-rf9BJ5Q%40mail.gmail.com/#msg37836780
I gather that lhmouse's gcc builds have Intel as the default assembly syntax, whereas AFAIK the other builders are still specifying AT&T as the default.
I don't know if the default of Intel could account for the success that I have in building 32-bit quadmath perls with lhmouse's compilers.
I can well envisage that there might be other differences, too - but the default assembly syntax is the only difference I know of.
When using Brecht Sanders releases of gcc-13.1.0 built with MCF-threads && msvc runtime, the perls they build suffer multiple test failures.
Here is the 'gmake test' report for almost-current (commit 942fa8d) blead, using Brecht Sanders' gcc-13.1.0 built with MCF-threads && msvc runtime.
There are far fewer failures when the same perl source is built using Brecht Sanders' gcc-13.1.0 that is built with POSIX-threads && msvc runtime:
So we see that the number of failures increases markedly when Brecht Sanders' MCF-threads version of gcc-13.1.0 is used. (Though it's lhmouse's MCF-threads version that succeeds.)
Things look pretty much the same with Brecht Sanders' 13.2.0 compilers.
LHmouse hasn't provided a gcc-13.2.0, but the gcc-13.2.1 (snapshot) works fine.
(For the 32-bit compilers lhmouse provides only MCF-threads with msvc runtime.)
Perl configuration
Cheers,
Rob
The text was updated successfully, but these errors were encountered: