On 7/3/25 10:43 AM, Patrick Palka wrote:
On Thu, 3 Jul 2025, Jason Merrill wrote:
On 7/2/25 7:58 PM, Patrick Palka wrote:
Bootstrapped and regtested on x86_64-pc-linux-gnu, does this look OK
for trunk?
-- >8 --
Here the flag -fno-delete-null-pointer-checks causes the trivial address
comparison in
inline int a, b;
static_assert(&a != &b);
to be rejected as non-constant because with the flag we can't assume
such weak symbols are non-NULL, which causes symtab/fold-const.cc to
punt on such comparisons. Note this also affects -fsanitize=undefined
since it implies -fno-delete-null-pointer-checks.
Right, the underlying problem is that we use the one flag to mean two things:
1) a static storage duration decl can live at address 0
2) do more careful checking for null pointers/lvalues (i.e. in
gimple_call_nonnull_result_p)
Both cases are related to checking for null, but they are different situations
and really shouldn't depend on the same flag.
Your patch seems wrong for #1 targets; on such a target 'a' might end up
allocated at address 0, so "&a != nullptr" is not decidable at compile time.
OTOH such targets are a small minority, and I suspect they already have other
C++ issues with e.g. a conversion to base not adjusting a null pointer.
Yep, and normally I would not be so bold to propose making such a
trade-off, but this seems to be exactly the trade-off we made in
PR96862 for -frounding-math? The flag makes lossy floating-point
operations depend on the run-time rounding mode and so not decidable at
compile time, so we ended up disabling the flag during constexpr
evaluation and using the default rounding mode. I don't immediately
see why -frounding-math maybe be special.
On a related note, I notice we accept
[[gnu::weak]] inline int a, b;
static_assert(&a != &b);
with the default -fdelete-null-pointer-checks, which seems wrong,
Hmm, it seems fine to me; if we define a and b in the current TU, we
know they are defined, so their addresses aren't going to be null and
thus won't compare equal.
Jason
