================
@@ -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.
----------------
zygoloid wrote:
I don't think there are "constexpr-unknown objects" in the standard -- in this
case we instead get an "unspecified object":
> For such a reference that is not usable in constant expressions, the
> reference is treated as binding to an unspecified object of the referenced
> type whose lifetime and that of all subobjects includes the entire constant
> evaluation and whose dynamic type is constexpr-unknown.
And I think, because the object is unspecified, that means that it's implicitly
unspecified whether it's the same object as another object -- or more
specifically, whether pointers to the two objects represent the same address,
and hence implicitly unspecified whether the pointers compare equal. (In this
case, they could both be member subobjects of the same union, for example.) I
agree it'd be nice if that were more explicit, but I think the choice of
wording here ("unspecified object") was intended to trigger the "comparison
whose result is unspecified" rule.
https://github.com/llvm/llvm-project/pull/147663
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
