On Fri, Feb 24, 2023 at 11:59:53AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > This needs to be alignas(T) unsigned char m_data[sizeof(T) * N];
>
> unsigned char m_data[MAX (N, 2) * sizeof (T)];
>
> if we want to preserve current behavior I think.
>
> I've screwed up, when I was about to c
On Fri, Feb 24, 2023 at 10:30:00AM +, Jonathan Wakely wrote:
> On Fri, 24 Feb 2023 at 10:24, Jakub Jelinek wrote:
> >
> > On Fri, Feb 24, 2023 at 11:02:07AM +0100, Jakub Jelinek via Gcc-patches
> > wrote:
> > > Maybe this would work, vl_relative even could be vl_embed.
> > > Because vl_embed
On Fri, 24 Feb 2023 at 10:24, Jakub Jelinek wrote:
>
> On Fri, Feb 24, 2023 at 11:02:07AM +0100, Jakub Jelinek via Gcc-patches wrote:
> > Maybe this would work, vl_relative even could be vl_embed.
> > Because vl_embed I believe is used in two spots, part of
> > auto_vec where it is followed by m_d
On Fri, Feb 24, 2023 at 11:02:07AM +0100, Jakub Jelinek via Gcc-patches wrote:
> Maybe this would work, vl_relative even could be vl_embed.
> Because vl_embed I believe is used in two spots, part of
> auto_vec where it is followed by m_data and on heap or GGC
> allocated memory where vec<..., vl_em
On Fri, Feb 24, 2023 at 09:55:13AM +, Jonathan Wakely wrote:
> > You would still be accessing past the end of the
> > vec::m_vecdata array which is UB.
>
> My thinking is something like:
>
> // New tag type
> struct vl_relative { };
>
> // This must only be used as a member subobject of anot
On Fri, 24 Feb 2023 at 09:50, Jonathan Wakely wrote:
>
> On Fri, 24 Feb 2023 at 09:49, Jakub Jelinek wrote:
> >
> > Assuming a compiler handles the T m_vecdata[1]; as flexible array member
> > like (which we need because standard C++ doesn't have flexible array members
> > nor [0] arrays), I wonde
On Fri, Feb 24, 2023 at 09:50:33AM +, Jonathan Wakely wrote:
> On Fri, 24 Feb 2023 at 09:49, Jakub Jelinek wrote:
> >
> > Assuming a compiler handles the T m_vecdata[1]; as flexible array member
> > like (which we need because standard C++ doesn't have flexible array members
> > nor [0] arrays)
On Fri, 24 Feb 2023 at 09:49, Jakub Jelinek wrote:
>
> Assuming a compiler handles the T m_vecdata[1]; as flexible array member
> like (which we need because standard C++ doesn't have flexible array members
> nor [0] arrays), I wonder if we instead of the m_auto followed by m_data
> trick couldn't
On Fri, Feb 24, 2023 at 09:34:46AM +, Richard Biener wrote:
> > Looking at vec::operator[] which just does
> >
> > template
> > inline const T &
> > vec::operator[] (unsigned ix) const
> > {
> > gcc_checking_assert (ix < m_vecpfx.m_num);
> > return m_vecdata[ix];
> > }
> >
> > the whole
On Fri, 24 Feb 2023, Richard Biener wrote:
> On Thu, 23 Feb 2023, Jakub Jelinek wrote:
>
> > On Thu, Feb 23, 2023 at 03:02:01PM +, Richard Biener wrote:
> > > > > * vec.h (auto_vec): Turn m_data storage into
> > > > > uninitialized unsigned char.
> > > >
> > > > Given that we act
On Thu, 23 Feb 2023, Jakub Jelinek wrote:
> On Thu, Feb 23, 2023 at 03:02:01PM +, Richard Biener wrote:
> > > > * vec.h (auto_vec): Turn m_data storage into
> > > > uninitialized unsigned char.
> > >
> > > Given that we actually never reference the m_data array anywhere,
> > >
On Thu, Feb 23, 2023 at 03:02:01PM +, Richard Biener wrote:
> > > * vec.h (auto_vec): Turn m_data storage into
> > > uninitialized unsigned char.
> >
> > Given that we actually never reference the m_data array anywhere,
> > it is just to reserve space, I think even the alignas(T) there is
On Thu, 23 Feb 2023, Jakub Jelinek wrote:
> On Thu, Feb 23, 2023 at 01:54:27PM +0100, Richard Biener wrote:
> > 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 case
On Thu, Feb 23, 2023 at 01:54:27PM +0100, Richard Biener wrote:
> 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
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.
Bootstrapped and tested on x86_64-unknown-linux-g
15 matches
Mail list logo
