[PATCH 0/2] MR10953: Update default i386_CFLAGS
The immediate reason for this is !10716, but I suspect it might come in handy in other places as well. FWIW I've been building Wine with similar CFLAGS for many, many years. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10953
From: Matteo Bruni <mbruni@codeweavers.com> The original SSE instruction set has been available since the Pentium 3 (1999) and the Athlon XP (2001). i386_CFLAGS can always be overridden to drop the -msse part, or in any other way. --- configure.ac | 7 ++++++- 1 file changed, 6 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index 5517c70ae94..fea864659ff 100644 --- a/configure.ac +++ b/configure.ac @@ -449,7 +449,12 @@ do [wine_try_msvc=no]) CPPFLAGS="" - AS_VAR_SET_IF([${wine_arch}_CFLAGS],[],[AS_VAR_SET([${wine_arch}_CFLAGS],[${CROSSCFLAGS:-"-g -O2"}])]) + case $wine_arch in + i386) + AS_VAR_SET_IF([${wine_arch}_CFLAGS],[],[AS_VAR_SET([${wine_arch}_CFLAGS],[${CROSSCFLAGS:-"-g -O2 -msse"}])]) ;; + *) + AS_VAR_SET_IF([${wine_arch}_CFLAGS],[],[AS_VAR_SET([${wine_arch}_CFLAGS],[${CROSSCFLAGS:-"-g -O2"}])]) ;; + esac AS_VAR_SET_IF([${wine_arch}_LDFLAGS],[],[AS_VAR_SET([${wine_arch}_LDFLAGS],[$CROSSLDFLAGS])]) AS_VAR_SET_IF([${wine_arch}_CXX],[],[AS_VAR_COPY([${wine_arch}_CXX],[${wine_arch}_CC])]) AS_VAR_SET_IF([${wine_arch}_CXXFLAGS],[],[AS_VAR_COPY([${wine_arch}_CXXFLAGS],[${wine_arch}_CFLAGS])]) -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/10953
From: Matteo Bruni <mbruni@codeweavers.com> --- configure.ac | 15 ++++++++++++++- 1 file changed, 14 insertions(+), 1 deletion(-) diff --git a/configure.ac b/configure.ac index fea864659ff..13dcc0d8a90 100644 --- a/configure.ac +++ b/configure.ac @@ -414,6 +414,14 @@ do esac done +for wine_arch in $cross_archs $extra_arch +do + case $wine_arch in + x86_64) + x86_64_cpu_available=1 ;; + esac +done + for wine_arch in $cross_archs $extra_arch do case $wine_arch in @@ -451,7 +459,12 @@ do CPPFLAGS="" case $wine_arch in i386) - AS_VAR_SET_IF([${wine_arch}_CFLAGS],[],[AS_VAR_SET([${wine_arch}_CFLAGS],[${CROSSCFLAGS:-"-g -O2 -msse"}])]) ;; + if test -n "$x86_64_cpu_available" -o -n "$with_wine64" + then + AS_VAR_SET_IF([${wine_arch}_CFLAGS],[],[AS_VAR_SET([${wine_arch}_CFLAGS],[${CROSSCFLAGS:-"-g -O2 -march=x86-64"}])]) + else + AS_VAR_SET_IF([${wine_arch}_CFLAGS],[],[AS_VAR_SET([${wine_arch}_CFLAGS],[${CROSSCFLAGS:-"-g -O2 -msse"}])]) + fi ;; *) AS_VAR_SET_IF([${wine_arch}_CFLAGS],[],[AS_VAR_SET([${wine_arch}_CFLAGS],[${CROSSCFLAGS:-"-g -O2"}])]) ;; esac -- GitLab https://gitlab.winehq.org/wine/wine/-/merge_requests/10953
Well, yet we have a game or too which is broken with this flag in Proton (which builds i386 with -msse2 from start). For that reason there is a hack removing that flag with #pragma for ddraw. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10953#note_140691
The original SSE instruction set has been available since the Pentium 3 (1999) and the Athlon XP (2001).
Does Wine have a particular reason to second-guess the compiler, or do we just think that their default is a bad choice? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10953#note_140722
In the normal cases the only concern with demanding sse on i386 by default is old CPUs which don't support it (which is probably less of a concern these days). But in Wine case that is a matter of compatibility, games have issues / bugs which are mitigated by the fact that dlls on Windows use x87 in dlls. Re-Volt game will leak x87 stack in its own code but will get away with that because it is doing ddraw calls using x87 that would inevitably reset fp stack for it from time to time (breaks if enabling sse). I don't have an example in hands rn but I suspect there will be more of less exotic issues when some game will depend plainly on x87 rounding / else mode affecting things in the same ddraw. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10953#note_140725
Well, yet we have a game or too which is broken with this flag in Proton (which builds i386 with -msse2 from start). For that reason there is a hack removing that flag with #pragma for ddraw.
Notice that these changes are not supposed to enable sse instructions for floating point arithmetic; that would be `-mfpmath=sse`, which is not implied by either compile option that I'm introducing here. This is quite a smaller change; the compiler is still allowed to use additional instructions in some situations (most likely for struct copies or synthesized `memcpy()`) but I don't expect it to be so impactful. As far as I can see, Proton in fact only forces the default fpmath setting for ddraw, it doesn't touch `-msse` or `-msse2` or any of that, e.g.: https://github.com/ValveSoftware/wine/commit/4912df4e37458b06f14abebb5382610.... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10953#note_140757
The original SSE instruction set has been available since the Pentium 3 (1999) and the Athlon XP (2001).
Does Wine have a particular reason to second-guess the compiler, or do we just think that their default is a bad choice?
AFAIU the default `-march` setting is chosen by the distro and it's usually a very conservative default. Not much "guessing" on their part in any case. Also, we do in fact have additional info that we can use, which is what the second patch does (we're also building 64-bit code -> CPU must support 64-bit mode -> we can use all the features baseline in x86-64 architectures, namely SSE and SSE2). My immediate interest for this MR is to be able to use SSE compiler intrinsics in dsound with default CFLAGS. FWIW, we're already force enabling `-mcx16` on x86_64, and that one is even put in x86_64_EXTRACFLAGS since, I assume, we really do require it. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10953#note_140761
FWIW, we're already force enabling -mcx16 on x86_64, and that one is even put in x86_64_EXTRACFLAGS since, I assume, we really do require it.
Yes we do, and if we are going to require SSE it should use the same mechanism (and we'd want at least SSE2). Guessing based on the build architecture doesn't make much sense. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10953#note_140766
On Wed May 20 09:41:36 2026 +0000, Alexandre Julliard wrote:
FWIW, we're already force enabling -mcx16 on x86_64, and that one is even put in x86_64_EXTRACFLAGS since, I assume, we really do require it. Yes we do, and if we are going to require SSE it should use the same mechanism (and we'd want at least SSE2). Guessing based on the build architecture doesn't make much sense. At least for !10716, we can use SSE instructions in the optimized resampler (just SSE1, no SSE2+ instructions needed at the moment) when available, and we can still manage without them, thus the idea of defaulting to `-msse`, but not forcing it. If we want to require SSE2 on x86 going forward then sure, no reason to do it this way.
WRT the x86-64 architecture check, is it logically incorrect or does it just feel awkward / messy? -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10953#note_140773
At least for !10716, we can use SSE instructions in the optimized resampler (just SSE1, no SSE2+ instructions needed at the moment) when available, and we can still manage without them, thus the idea of defaulting to -msse, but not forcing it. If we want to require SSE2 on x86 going forward then sure, no reason to do it this way.
If we are going to require SSE, then there are other places where we could take advantage of it, and SSE2 would be more useful, without making much difference in terms of supported hardware. If we are not going to require it, then the right way would be `#pragma GCC target` and a runtime check. But it's probably not worth the trouble nowadays.
WRT the x86-64 architecture check, is it logically incorrect or does it just feel awkward / messy?
It's logically incorrect, building 64-bit code doesn't imply anything about the runtime CPU. For instance I routinely build ARM64 PE files on my (amd64) box, that doesn't imply that my CPU can run ARM64 code. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10953#note_140775
If we are not going to require it, then the right way would be #pragma GCC target and a runtime check. But it's probably not worth the trouble nowadays.
Excellent! That also answers my (unexpressed) question about what to do for newer instruction sets, like AVX, where requiring support is not an option. One case where requiring SSE2 in i386 PE code is a bit annoying is for running tests on old HW, which is sometimes very useful. I guess it's one more hop to jump through, nothing qualitatively different, at least in the short term. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10953#note_140776
On Wed May 20 14:33:03 2026 +0000, Matteo Bruni wrote:
Well, yet we have a game or too which is broken with this flag in Proton (which builds i386 with -msse2 from start). For that reason there is a hack removing that flag with #pragma for ddraw. Notice that these changes are not supposed to enable sse instructions for floating point arithmetic; that would be `-mfpmath=sse`, which is not implied by either compile option that I'm introducing here. This is quite a smaller change; the compiler is still allowed to use additional instructions in some situations (most likely for struct copies or synthesized `memcpy()`) but I don't expect it to be so impactful. As far as I can see, Proton in fact only forces the default fpmath setting for ddraw, it doesn't touch `-msse` or `-msse2` or any of that, e.g.: https://github.com/ValveSoftware/wine/commit/4912df4e37458b06f14abebb5382610.... Oh yeah, sorry, I misread it. My concern was only about enabling sse for compiler generated math which it obviously doesn't do.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10953#note_140815
One case where requiring SSE2 in i386 PE code is a bit annoying is for running tests on old HW, which is sometimes very useful.
In what cases would it make sense to test Wine on a Pentium 3 or older? Perhaps there are some, but personally, I struggle to imagine them. -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10953#note_141022
On Fri May 22 04:13:39 2026 +0000, QwertyChouskie wrote:
One case where requiring SSE2 in i386 PE code is a bit annoying is for running tests on old HW, which is sometimes very useful. In what cases would it make sense to test Wine on a Pentium 3 or older? Perhaps there are some, but personally, I struggle to imagine them. Testing ddraw behavior on a contemporary OS on real HW is the usual example. Not a super common use case, but it's known to have happened (and to have been useful) a number of times.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10953#note_141029
Testing ddraw behavior on a contemporary OS on real HW is the usual example. Not a super common use case, but it's known to have happened (and to have been useful) a number of times.
Indeed I do this regularly. Of course, I can change my CFLAGS if necessary... -- https://gitlab.winehq.org/wine/wine/-/merge_requests/10953#note_141059
On Fri May 22 15:58:30 2026 +0000, Elizabeth Figura wrote:
Testing ddraw behavior on a contemporary OS on real HW is the usual example. Not a super common use case, but it's known to have happened (and to have been useful) a number of times. Indeed I do this regularly. Of course, I can change my CFLAGS if necessary... Right, i386_EXTRACFLAGS specifically. It might become trickier if at some point we end up depending on SSE2 in winecrt0 or some other dependency, but we can probably make a conscious effort to keep those safe to use on old HW.
-- https://gitlab.winehq.org/wine/wine/-/merge_requests/10953#note_141178
participants (6)
-
Alexandre Julliard (＠julliard) -
Elizabeth Figura (＠zfigura)
-
Matteo Bruni
-
Matteo Bruni (＠Mystral)
-
Paul Gofman (＠gofman)
-
QwertyChouskie (＠QwertyChouskie)