Re: toolchain/60289 (NetBSD 11 gcc mis-optimises some NULL checks)

[Manuel Bouyer <manuel.bouyer%lip6.fr@localhost>]

On Sat, May 23, 2026 at 09:59:12PM +0000, riastradh%NetBSD.org@localhost wrote:
> Synopsis: NetBSD 11 gcc mis-optimises some NULL checks
> 
> State-Changed-From-To: open->analyzed
> State-Changed-By: riastradh%NetBSD.org@localhost
> State-Changed-When: Sat, 23 May 2026 21:59:11 +0000
> State-Changed-Why:
> This actually may be a gcc bug, because we compile the kernel with
> -fno-delete-null-pointer-checks, which is supposed to prevent gcc from
> eliminating these checks:
> 
> https://nxr.netbsd.org/xref/src/sys/conf/Makefile.kern.inc?r=1.306#108
> https://gcc.gnu.org/onlinedocs/gcc-14.3.0/gcc/Optimize-Options.html#index-fdelete-null-pointer-checks
> 
> It's not NetBSD-specific -- here's a godbolt.org example with 14.3.0,
> presumably not on NetBSD:
> 
> https://godbolt.org/z/aT6xqdMer
> 
> .LC0:
>         .string "A "
> ...
>         mov     edi, OFFSET FLAT:.LC0
>         call    printf
>         test    BYTE PTR [rbx+16], 1
>         je      .L9
> 
> So I think someone should file a bug with gcc upstream.

I found at last one gcc bug report on this topic:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100404

Adding
	asm("" : "+r"(barp)); 
just before the !barp test works around the isssue.

but explicitely checking for NULL before &barp->foo is a more correct
fix, even if it leads to an extra test which is not needed (could an
overly agressive optimisation leading to slower code be considered as a bug ?)

But,
 -fno-delete-null-pointer-checks doesn't work in this case; this is a real
   problem
 It seems that there's no way to get a warning when this optimisation is
   triggered, which I think is also a problem for developers.

A quick search showed other projects (bind, openjdk) running into this

-- 
Manuel Bouyer, LIP6, Sorbonne Universit�          Manuel.Bouyer%lip6.fr@localhost
     NetBSD: 26 ans d'experience feront toujours la difference
--