[clang] [clang] Fix pointer comparisons between pointers to constexpr-unknown (PR #147663)
Eli Friedman via cfe-commits
cfe-commits at lists.llvm.org
Fri Jul 11 15:01:41 PDT 2025
================
@@ -14544,6 +14538,23 @@ EvaluateComparisonBinaryOperator(EvalInfo &Info, const BinaryOperator *E,
(LHSValue.Base && isZeroSized(RHSValue)))
return DiagComparison(
diag::note_constexpr_pointer_comparison_zero_sized);
+ // A constexpr-unknown reference can be equal to any other lvalue, except
+ // for variables allocated during constant evaluation. (The "lifetime
+ // [...] includes the entire constant evaluation", so it has to be
+ // distinct from anything allocated during constant evaluation.)
+ //
+ // Theoretically we could handle other cases, but the standard doesn't say
+ // what other cases we need to handle; it just says an "equality
+ // operator where the result is unspecified" isn't a constant expression.
----------------
efriedma-quic wrote:
The text says the lifetime of the object includes the entire constant evaluation. And if you have a live object of type int, and a live object of type float, they can't overlap. (If you have an int and a float in a union, they can't both be live at the same time.)
Maybe the intent is that the unspecified object doesn't actually have to be a live object, just refer to allocated storage? I guess that would eliminate the weirdest edge cases/inconsistencies. And I guess that would mean a constexpr-unknown object can overlap with an object allocated during constant evaluation.
We would have to check alignment, though; if we can prove the low bits of two pointers are not equal, the pointers themselves can't be equal:
```
struct alignas(int) F { char x[4]; };
extern F &e1, &e2;
static_assert(&e1.x[1] != &e2.x[2]);
```
And... I can't think of anything else we need to check off the top of my head, but there might be other edge cases I'm not thinking of. It would be nicer if the standard just allowed us to reject everything involving equality of constexpr-unknown.
https://github.com/llvm/llvm-project/pull/147663
More information about the cfe-commits
mailing list