On Wed, Nov 12, 2025 at 10:45:44AM +0100, Theo Buehler wrote:
> On Wed, Nov 12, 2025 at 10:25:09AM +0100, Claudio Jeker wrote:
> > On Sat, Nov 08, 2025 at 04:51:07PM +0100, Theo Buehler wrote:
> > > Just in case someone is interested in this diff. It builds with gcc/15
> > > (no for need gnu++17 CXXFLAGS). It errors out building some test with
> > > gcc/8. That can likely be fixed but I won't be the one debugging that.
> > > I haven't tried with gcc/11 at all.
> > > 
> > > It is a somewhat intrusive patch adapted from
> > > https://github.com/abseil/abseil-cpp/issues/1634#issuecomment-2576011026
> > > 
> > > Since upstream doesn't seem keen on fixing this, I'm not sure we would
> > > really want this (once we switch to a newer gcc). The constant churn
> > > happening in abseil makes it likely that it needs fixing and adapting on
> > > every update. That's going to be tedious albeit rather straightforward.
> > > 
> > > I also have no idea why we need this when others seem to run into this
> > > problem only when enabling some sanitiers.
> > > 
> > > Tests look reasonable on sparc64 and arm64.
> > 
> > Not sure if this works on clang but adding -fdelete-null-pointer-checks
> > allows me to build abseil-cpp without the crazy diff.
> 
> Nice find. I saw the list of flags in CMakeLists but was too lazy to see
> if I can bisect the culprit.
> 
> > 
> > With this most tests pass:
> > 93% tests passed, 15 tests failed out of 218
> > 
> > I start to think that we should enable that by default in g++ since
> > this also fixes a few other ports. It seems to be on by default on linux
> > at least from reading the various bug reports. Only when sanitizers are
> > used the compiler adds -fno-delete-null-pointer-checks because the
> > sanitizers want to see those checks.
> 
> That explains...
> 
> See below.
> 
> > -- 
> > :wq Claudio
> > 
> > Index: Makefile
> > ===================================================================
> > RCS file: /cvs/ports/devel/abseil-cpp/Makefile,v
> > diff -u -p -r1.41 Makefile
> > --- Makefile	23 Sep 2025 18:46:30 -0000	1.41
> > +++ Makefile	12 Nov 2025 07:39:11 -0000
> > @@ -1,5 +1,3 @@
> > -BROKEN-sparc64 = is not a constant expression
> > -
> >  COMMENT =	abseil common libraries (C++)
> >  CATEGORIES =	devel
> >  
> > @@ -12,6 +10,8 @@ SITES =		https://github.com/abseil/absei
> >  MAINTAINER =	Andrew Krasavin <noiseless-ak@yandex.ru>, \
> >  		Klemens Nanni <kn@openbsd.org>
> >  
> > +DPB_PROPERTIES =	parallel
> 
> Fine with me.
> 
> > +
> >  # Apache 2.0
> >  PERMIT_PACKAGE =	Yes
> >  
> > @@ -67,6 +67,8 @@ CONFIGURE_ARGS =	-DBUILD_SHARED_LIBS=ON 
> >  # for CMake >= 3.8. Abseil developers recommend enabling this option
> >  # to ensure that our project builds correctly.
> >  CONFIGURE_ARGS +=      -DABSL_PROPAGATE_CXX_STD=ON
> > +
> > +CXXFLAGS +=		-fdelete-null-pointer-checks
> 
> This would limit the addition only to g++:
> 
> CXXFLAGS_ports-gcc = -fdelete-null-pointer-checks
> 
> If this works with gcc/15,
> 
> ok tb
> 
> (there is still the question if that builds with gcc/8. We can either
> test that or just land this and see. I think we should switch to
> gcc/15 soon enough that it doesn't matter).
> 
> >  
> >  LIB_DEPENDS +=		devel/gtest>=1.14.0
> >  
> 

We need similar fixes in webkitgtk4, qtwebkit, qt6-qtdeclarative and
probably some more. This is why I think we somehow miss a magic option
in gcc to enable this by default.
Anything using type_traits seems to hit this error.

gcc has this about this optimisation:
-fdelete-null-pointer-checks

    Assume that programs cannot safely dereference null pointers, and that
no code or data element resides at address zero. This option enables
simple constant folding optimizations at all optimization levels. In
addition, other optimization passes in GCC use this flag to control global
dataflow analyses that eliminate useless checks for null pointers; these
assume that a memory access to address zero always results in a trap, so
that if a pointer is checked after it has already been dereferenced, it
cannot be null.

    Note however that in some environments this assumption is not true.
Use -fno-delete-null-pointer-checks to disable this optimization for
programs that depend on that behavior.

    This option is enabled by default on most targets. On AVR and MSP430,
this option is completely disabled.

    Passes that use the dataflow information are enabled independently at
different optimization levels.


Now there is some carfuffle about this optimisation since it affects a
common mistake like the code below:
	struct foo	*bar = arg;
	int		 x = bar->x;

	if (bar == NULL)
		errx(1, "barf");

Here the bar == NULL check including the errx is optimised away because
bar is dereferenced before. On OpenBSD we can't map anything at 0 neither
in the kernel nor in userland so theoretically we should be fine enabling
this.

Now if you use physical addressing bypassing the MMU you can access the
real address 0 and so there -fno-delete-null-pointer-checks is needed.

-- 
:wq Claudio