https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94676
Bug ID: 94676
Summary: constexpr destructors run too late for temporaries
created inside __builtin_constant_p
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: c++
Assignee: unassigned at gcc dot gnu.org
Reporter: richard-gccbugzilla at metafoo dot co.uk
Target Milestone: ---
Testcase:
struct A {
int *p;
constexpr ~A() { *p = 0; }
};
static_assert(!__builtin_constant_p((A{}, 123)));
I think this testcase should be accepted. The way I see it, there are two ways
one could approach this:
1) Run the destructor for the A temporary after evaluating
__builtin_constant_p's operand, notice the operand is non-constant, and
evaluate the __bcp call to 0.
2) Notice that the __bcp call's operand has a side-effect on the enclosing
evaluation (registering a non-trivial destructor for a temporary) and evaluate
the call to 0 due to that side-effect. [This is what Clang currently does.]
I was considering changing Clang's behavior from option 2 to option 1, but I
noticed that GCC actually appears to do a third thing:
3) Run the destructor at the end of the entire static-assert condition and
reject the program because the destructor (run outside of the protection of
__builtin_constant_p) has a side-effect.
I don't think there's an obvious correct answer here, but (3) doesn't seem
right to me.
