https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109890
Bug ID: 109890 Summary: vector's constructor doesn't start object lifetimes during constant evaluation Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: libstdc++ Assignee: unassigned at gcc dot gnu.org Reporter: barry.revzin at gmail dot com Target Milestone: --- >From StackOverflow (https://stackoverflow.com/q/76269606/2069064), clang rejects this code when compiling with libstdc++: #include <vector> consteval auto bar(int n){ std::vector<int> v(n); return v[0]; } constexpr auto m = bar(5); This is because libstdc++ basically does something like this: #include <memory> class V { int* p; int n; std::allocator<int> alloc; public: constexpr V(int n) : n(n) { p = alloc.allocate(n); // fill with 0s? for (int i = 0; i != n; ++i) { p[i] = 0; } } constexpr ~V() { alloc.deallocate(p, n); } }; consteval auto bar(int n) { V v(n); return n; } static_assert(bar(5) == 5); And clang is more picky about the assignment there - it doesn't like just writing p[0] = 0, because the int's lifetime hasn't started yet. gcc accepts the above though. I think that's... technically correct (if pedantic) and libstdc++'s path needs to do a construct_at somewhere.