[Bug libstdc++/109890] New: vector's constructor doesn't start object lifetimes during constant evaluation

["barry.revzin at gmail dot com" <gcc-bugzilla@gcc.gnu.org>]

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.