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.

Reply via email to