Vendored mimalloc `mi_prim_tls_slot()` inline asm turns a TLS load into a store when compiled with GCC `-masm=intel`

Start in Include/internal/mimalloc/mimalloc/prim.h at mi_prim_tls_slot() and mi_prim_tls_slot_set(), then reproduce the issue with the provided GCC and Clang commands. Compare objdump output for -masm=att and -masm=intel across the listed TLS accessors; done means both dialects produce loads and stores with the intended direction, or unsupported compilation fails safely.

Summary

On x86-64 Linux, compiling Objects/obmalloc.c with GCC and -masm=intel turns every inline-asm read of the thread-pointer slot in the vendored mimalloc into a write to %fs:0. The build succeeds with exit status 0 and only an assembler warning. Clang rejects the same code with a hard error. The asm template in Include/internal/mimalloc/mimalloc/prim.h is written only in AT&T syntax and has no {AT&T|Intel} dialect alternative.

Reproduction Code

Requires x86-64 Linux with glibc and a CPython tree configured with mimalloc (WITH_MIMALLOC 1 in pyconfig.h, the default). Tested with GCC 13.3.0, GNU binutils objdump and Ubuntu Clang 18.1.3.

./configure
CFLAGS_COMMON="-O2 -std=c11 -DPy_BUILD_CORE -I. -IInclude -IInclude/internal -IInclude/internal/mimalloc"

gcc $CFLAGS_COMMON -masm=att   -c Objects/obmalloc.c -o obm_att.o
gcc $CFLAGS_COMMON -masm=intel -c Objects/obmalloc.c -o obm_intel.o; echo "gcc exit=$?"

# fs:0x0 accesses that carry no TLS relocation come from the mimalloc slot-0 asm
for m in att intel; do
  echo "== $m"
  objdump -dr -Mintel --no-show-raw-insn obm_$m.o |
    awk '/fs:0x0/{l=$0; getline n; if (n !~ /R_X86_64/) {sub(/^ *[0-9a-f]+:\t/,"",l); print l}}' |
    sort | uniq -c
done

clang $CFLAGS_COMMON -masm=intel -c Objects/obmalloc.c -o obm_clang.o

Minimal stand-alone reproducer using the same asm statement:

void *get(long slot) {
    void *res;
    const unsigned long ofs = slot * sizeof(void *);
    __asm__("movq %%fs:%1, %0" : "=r" (res) : "m" (*((void **)ofs)) : );
    return res;
}

gcc -O2 -masm=intel -c tls.c && objdump -d -Mintel --no-show-raw-insn tls.o

Actual Behavior

GCC with -masm=intel exits with status 0. The assembler prints one warning per expansion:

Include/internal/mimalloc/mimalloc/prim.h: Assembler messages:
Include/internal/mimalloc/mimalloc/prim.h:171: Warning: redundant segment overrides

Accesses to fs:0x0 without a relocation:

== att
      6 mov    rax,QWORD PTR fs:0x0
      4 mov    rcx,QWORD PTR fs:0x0
     12 mov    rdx,QWORD PTR fs:0x0
      2 mov    rsi,QWORD PTR fs:0x0
== intel
      6 mov    QWORD PTR fs:0x0,rax
      4 mov    QWORD PTR fs:0x0,rcx
     12 mov    QWORD PTR fs:0x0,rdx
      2 mov    QWORD PTR fs:0x0,rsi

All 24 loads become stores. Affected functions include mi_free, _mi_free_delayed_block, mi_heap_collect_ex, _mi_heap_done, mi_heap_get_backing, _mi_heap_init_ex, mi_heap_malloc_small_zero, _mi_heap_malloc_zero_ex and mi_heap_try_new. For example, the same instruction in mi_heap_get_backing is:

-masm=att:    15a5f:	mov    rdx,QWORD PTR fs:0x0
-masm=intel:  15a5f:	mov    QWORD PTR fs:0x0,rdx

The stand-alone reproducer compiles to:

   4:	mov    QWORD PTR fs:[rdi*8+0x0],rax
   d:	ret

Clang with -masm=intel fails:

Include/internal/mimalloc/mimalloc/prim.h:171:13: error: unknown token in expression

Expected Behavior

mi_prim_tls_slot() should load from the thread control block in either assembler dialect. With -masm=intel, the generated code should match the -masm=att build (mov reg,QWORD PTR fs:0x0). If the dialect is unsupported, the build should fail instead of producing a store.

Detail

The TLS slot accessors in Include/internal/mimalloc/mimalloc/prim.h use inline asm templates written only in AT&T syntax. They have no {AT&T|Intel} dialect alternative. There are eight: four loads in mi_prim_tls_slot() (lines 165–171) and four stores in mi_prim_tls_slot_set() (lines 192–198), one each for i386 (%gs), macOS x86-64 (%gs), x32 and x86-64 Linux/BSD (%fs):

__asm__("movq %%fs:%1, %0" : "=r" (res) : "m" (*((void**)ofs)) : );  // x86_64 Linux, BSD uses FS

GCC does not translate an asm template. It only substitutes operands, and it formats them for the selected dialect. With -masm=intel, the AT&T template receives Intel-formatted operands:

-masm=att:    movq %fs:0, %rax
-masm=intel:  movq %fs:QWORD PTR ds:0, rax
              movq %fs:QWORD PTR 0[0+rdi*8], rax

GCC's Intel mode puts the assembler in .intel_syntax noprefix. There, the first operand is the destination, so the assembler encodes the line as mov QWORD PTR fs:0x0,rax, a store of rax into the TCB. The %fs: written in the template and the ds: that GCC prints for a constant address are two segment overrides. That is what the redundant segment overrides warning reports. Clang's integrated assembler rejects the mixed text instead (unknown token in expression), so only GCC builds are miscompiled.

On glibc x86-64, _mi_prim_thread_id() reaches the load through mi_prim_tls_slot(0). It is inlined into allocation and free paths such as mi_free and _mi_heap_malloc_zero_ex. Slot 0 is the TCB self-pointer, so the miscompiled code overwrites %fs:0 with a register value instead of reading it.