> On 23 Feb 2026, at 16:10, Jan Beulich <[email protected]> wrote: > > On 23.02.2026 11:04, Edwin Török wrote: >> clang-21 doesn't support `-ffixed-xmm0`, so `%xmm0` won't have the >> expected value. >> Disable these tests on clang. > > I don't think that's what we want, and not only because of the clutter the > various #ifdef cause. We want to be able to run as many of the tests as > possible, so the first goal should be to find some alternative mechanism to > achieve the same effect. A global register variable comes to mind as a > possible option. > > Further, how did you arrive at which tests need suppressing?
I used gdb to look at the 2 memory areas, and noticed that the XMM region was different between emulated and actual when built with clang. Then I noticed the build failures due to the lack of fixed-xmm0. Then I added the ifdefs one by one as I ran the test until the whole test program passed without failure. I tried adding some ‘pxor xmm0, xmm0’ into the cpu_has_sse2 sections, but that didn’t really work either. Although I may have been misled by the overlapping region, see below. > I don't think > we rely on an "expected value" anywhere. I don't even recall us passing > -ffixed-xmm0 when compiling test_x86_emulate.c. Yes, I’m surprised it works with GCC. But maybe only because the emulator overwrites the actual FXSAVE area corresponding to XMM. XMM0 begins at offset 160, and 0x100 - 0x80 = 128. AFAICT the actual execution stores its result at [0x80, 0x80+0x200), and the emulator stores its result into [0x100, 0x100+0x200). So the emulator will overwrite some of the values from the actual run. This only works if the end of the FXSAVE area looks like its beginning (i.e. if FCW/FSW/etc. happens to match MM6/etc.) If I move the regions, such that they are distinct, then this begins to fail with GCC too (perhaps due to the lack of fixed-xmm0, I haven’t tried). Perhaps a better way to fix this would be to make the 2 regions distinct first, get it to work with GCC and then see what bugs remain on Clang. I’ll try that approach, and see how far I get. Best regards, —Edwin > We use that option when > building various of the test blobs, iirc. And the comment ahead of the > first use explains why we use the option there. (Later we also use > -ffixed-ymm<N> and -ffixed-zmm<N>, btw.) > > Jan
