Re: [PATCH 2/2] Avoid default-initializing auto_vec storage, fix vec

2023-02-24 Thread Richard Biener via Gcc-patches
On Fri, 24 Feb 2023, Jakub Jelinek wrote: > On Fri, Feb 24, 2023 at 02:47:39PM +0100, Richard Biener wrote: > > * vec.h (vec::m_vecdata): Remove. > > (vec::m_vecpfx): Align as T to avoid > > changing alignment of vec and simplifying > > address. > > (vec::address): Compute as

Re: [PATCH 2/2] Avoid default-initializing auto_vec storage, fix vec

2023-02-24 Thread Jakub Jelinek via Gcc-patches
On Fri, Feb 24, 2023 at 02:47:39PM +0100, Richard Biener wrote: > * vec.h (vec::m_vecdata): Remove. > (vec::m_vecpfx): Align as T to avoid > changing alignment of vec and simplifying > address. > (vec::address): Compute as this + 1. > (vec::embedded_size): Use

[PATCH 2/2] Avoid default-initializing auto_vec storage, fix vec

2023-02-24 Thread Richard Biener via Gcc-patches
The following avoids default-initializing auto_vec storage for non-POD T since that's not what the allocated storage fallback will do and it's also not expected for existing cases like auto_vec, 64> elts; which exist to optimize the allocation. It also fixes the array accesses done by vec to

Re: [PATCH 2/2] Avoid default-initializing auto_vec storage, fix vec

2023-02-24 Thread Jakub Jelinek via Gcc-patches
On Fri, Feb 24, 2023 at 12:15:04PM +, Richard Biener wrote: > > > Anyway, I wonder if you get the -Werror=stringop-overflow= errors during > > > bootstrap that I got with my version or not. > > Yes, I get this as well, not sure how to suppress it. I guess there's > no standard way to get at

Re: [PATCH 2/2] Avoid default-initializing auto_vec storage, fix vec

2023-02-24 Thread Jakub Jelinek via Gcc-patches
On Fri, Feb 24, 2023 at 12:15:04PM +, Richard Biener wrote: > > > Also, I think it needs to be MAX (N, 2) instead of N, because auto_vec > > > ctors use MAX (N, 2). We could also change all those to MAX (N, 1) > > > now, but it can't be N because m_data[sizeof (T) * 0] is invalid in > > >

Re: [PATCH 2/2] Avoid default-initializing auto_vec storage, fix vec

2023-02-24 Thread Richard Biener via Gcc-patches
On Fri, 24 Feb 2023, Jonathan Wakely wrote: > On Fri, 24 Feb 2023 at 11:52, Jakub Jelinek wrote: > > > > On Fri, Feb 24, 2023 at 12:44:44PM +0100, Richard Biener wrote: > > > --- a/gcc/vec.h > > > +++ b/gcc/vec.h > > > @@ -586,8 +586,8 @@ public: > > >unsigned allocated (void) const { return

Re: [PATCH 2/2] Avoid default-initializing auto_vec storage, fix vec

2023-02-24 Thread Jakub Jelinek via Gcc-patches
On Fri, Feb 24, 2023 at 11:54:54AM +, Jonathan Wakely wrote: > > The comment needs adjustment and don't we need > > alignas (T) alignas (vec_prefix) ? > > Yes. If alignas(T) is less than the natural alignment then this will > be an error. We want it to be the larger of the two alignments, so

Re: [PATCH 2/2] Avoid default-initializing auto_vec storage, fix vec

2023-02-24 Thread Jonathan Wakely via Gcc-patches
On Fri, 24 Feb 2023 at 11:52, Jakub Jelinek wrote: > > On Fri, Feb 24, 2023 at 12:44:44PM +0100, Richard Biener wrote: > > --- a/gcc/vec.h > > +++ b/gcc/vec.h > > @@ -586,8 +586,8 @@ public: > >unsigned allocated (void) const { return m_vecpfx.m_alloc; } > >unsigned length (void) const {

Re: [PATCH 2/2] Avoid default-initializing auto_vec storage, fix vec

2023-02-24 Thread Jakub Jelinek via Gcc-patches
On Fri, Feb 24, 2023 at 12:44:44PM +0100, Richard Biener wrote: > --- a/gcc/vec.h > +++ b/gcc/vec.h > @@ -586,8 +586,8 @@ public: >unsigned allocated (void) const { return m_vecpfx.m_alloc; } >unsigned length (void) const { return m_vecpfx.m_num; } >bool is_empty (void) const { return

[PATCH 2/2] Avoid default-initializing auto_vec storage, fix vec

2023-02-24 Thread Richard Biener via Gcc-patches
The following avoids default-initializing auto_vec storage for non-POD T since that's not what the allocated storage fallback will do and it's also not expected for existing cases like auto_vec, 64> elts; which exist to optimize the allocation. It also fixes the array accesses done by vec to