Any call to `libqbe.Main` fatal-errors when the program is built with the race detector (`-race`) or with pointer-check instrumentation (`-gcflags=all=-d=checkptr`): ``` fatal error: checkptr: pointer arithmetic result points to invalid allocation ``` Normal (uninstrumented) builds are unaffected. This is **not** a data race - it reproduces single-threaded - it is a `checkptr` violation in the ccgo-generated `x_main`, which walks the NULL-terminated global target list `s_tlist` by `uintptr` arithmetic and converts the result back to a pointer. Because `checkptr` is implied by `-race`, this makes it impossible to run the race detector on any downstream package that links libqbe (e.g. `modernc.org/qbecc`), which is how it was found. ## Reproducer (self-contained) ```go package main import ( "bytes" "fmt" "os" "strings" "modernc.org/libqbe" ) func main() { const ssa = `function w $main() { @start ret 0 } ` var out bytes.Buffer if err := libqbe.Main("amd64_sysv", "repro.ssa", strings.NewReader(ssa), &out, nil); err != nil { fmt.Fprintln(os.Stderr, "err:", err) os.Exit(1) } fmt.Fprintln(os.Stderr, "ok, produced", out.Len(), "bytes of asm") } ``` ``` $ go run . # fine ok, produced 132 bytes of asm $ go run -race . # crash fatal error: checkptr: pointer arithmetic result points to invalid allocation $ go run -gcflags=all=-d=checkptr . # same crash, no race detector fatal error: checkptr: pointer arithmetic result points to invalid allocation ``` ## Stack trace (abridged) ``` fatal error: checkptr: pointer arithmetic result points to invalid allocation runtime.checkptrArithmetic(...) /usr/local/go/src/runtime/checkptr.go:69 modernc.org/libqbe.x_main(...) .../modernc.org/libqbe@v0.9.0/ccgo_linux_amd64.go:786 modernc.org/libqbe.Main(...) .../modernc.org/libqbe@v0.9.0/libqbe.go:325 main.main() ``` ## Root cause `ccgo_linux_amd64.go`, `x_main` (around lines 784–798): ```go t = uintptr(unsafe.Pointer(&qbe.s_tlist)) for { if !(*(*uintptr)(unsafe.Pointer(t)) != 0) { // <-- line 786, checkptr fires here fprintf(tls, qbe, libc.Xstderr, __ccgo_ts+43, libc.VaList(bp+8, target)) return int32(1) } if libc.Xstrcmp(tls, target, *(*uintptr)(unsafe.Pointer(t))) == 0 { qbe.x_T = *(*_Target)(unsafe.Pointer(*(*uintptr)(unsafe.Pointer(t)))) break } goto _1 _1: ; t += 8 } ``` This is the ccgo translation of a C pointer walk over the NULL-terminated global `T **tlist` (`for (T **t = tlist; *t; t++)`). Because it keeps the cursor as a bare `uintptr` and does `t += 8` between conversions back to `unsafe.Pointer(t)`, `checkptr` rejects the arithmetic once the cursor advances to (or past) the end of the `s_tlist` global's allocation - even though the equivalent C is well-defined. It is the standard "uintptr arithmetic across an allocation boundary" pattern that `unsafe.Pointer` rule #3 / `checkptr` disallows. Note: `s_tlist` is merely the *first* such loop reached at runtime. The `uintptr += N` / `unsafe.Pointer(uintptr)` idiom is pervasive in the generated code, so fixing this one loop will likely just move the crash to the next one. That is why the suggested fix below targets the code generator rather than a single loop. ## Impact - Downstream packages cannot run their test suites under `-race` (the race detector implies `checkptr`), losing race coverage for everything that transitively calls `libqbe.Main`. - Only instrumented builds are affected; production builds are correct. ## Suggested fix This looks like it needs to come from the ccgo code generator (or a libqbe post-processing step) emitting an allocation-boundary-safe idiom for walking global arrays/`T**` lists - e.g. keeping the cursor as an `unsafe.Pointer` advanced with `unsafe.Add`, or indexing the global array by element rather than raw `uintptr += 8`. If `s_tlist` walks are the only offenders, a targeted rewrite of that loop would unblock `-race` for downstream users.