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.