public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/109890] New: vector's constructor doesn't start object lifetimes during constant evaluation
@ 2023-05-17 13:50 barry.revzin at gmail dot com
  2023-05-17 14:06 ` [Bug libstdc++/109890] " redi at gcc dot gnu.org
  0 siblings, 1 reply; 2+ messages in thread
From: barry.revzin at gmail dot com @ 2023-05-17 13:50 UTC (permalink / raw)
  To: gcc-bugs

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.

^ permalink raw reply	[flat|nested] 2+ messages in thread

* [Bug libstdc++/109890] vector's constructor doesn't start object lifetimes during constant evaluation
  2023-05-17 13:50 [Bug libstdc++/109890] New: vector's constructor doesn't start object lifetimes during constant evaluation barry.revzin at gmail dot com
@ 2023-05-17 14:06 ` redi at gcc dot gnu.org
  0 siblings, 0 replies; 2+ messages in thread
From: redi at gcc dot gnu.org @ 2023-05-17 14:06 UTC (permalink / raw)
  To: gcc-bugs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109890

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
     Ever confirmed|0                           |1
   Last reconfirmed|                            |2023-05-17
             Status|UNCONFIRMED                 |NEW

--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
For trivial types the std::uninitialized_xxx algos elide the constructors and
just do something like memcpy/memset. We need to use
std::is_constant_evaluated() to elide the elision in this case.

^ permalink raw reply	[flat|nested] 2+ messages in thread

end of thread, other threads:[~2023-05-17 14:06 UTC | newest]

Thread overview: 2+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-05-17 13:50 [Bug libstdc++/109890] New: vector's constructor doesn't start object lifetimes during constant evaluation barry.revzin at gmail dot com
2023-05-17 14:06 ` [Bug libstdc++/109890] " redi at gcc dot gnu.org

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).