Re: vector<bool> _M_start and 0 offset

[Jonathan Wakely <jwakely at redhat dot com>]

On 17/09/18 19:57 +0200, Marc Glisse wrote:
> On Mon, 17 Sep 2018, Jonathan Wakely wrote:
>
> > On 15/09/18 14:27 +0200, Marc Glisse wrote:
> > > Hello,
> > >
> > > as explained in the PR, the implementation of vector<bool> is 
> > > weirdly wasteful. Preserving the ABI prevents from changing much 
> > > for now, but this small tweak can help the compiler remove quite a 
> > > bit of dead code.
> > >
> > > I think most other direct uses of _M_start are in constructors 
> > > where the offset has just been initialized to 0, so the compiler 
> > > should already know enough there, but I may have missed a few 
> > > relevant places where the same idea could be used.
> > >
> > > I used C++11 syntax because I find it nicer, and the compiler 
> > > accepts it in C++98 mode with just a warning, suppressed in a 
> > > standard header.
>
> ^^^^^^^^^^
>
> > > Bootstrap+regtest on powerpc64le-unknown-linux-gnu.
> > >
> > > 2018-09-15  Marc Glisse  <marc.glisse@inria.fr>
> > >
> > >       PR libstdc++/87258
> > > 	* include/bits/stl_bvector.h (vector::begin(), vector::cbegin()):
> > > 	Rebuild _M_start with an explicit 0 offset.
> > >
> > > --
> > > Marc Glisse
> >
> > > Index: include/bits/stl_bvector.h
> > > ===================================================================
> > > --- include/bits/stl_bvector.h	(revision 264178)
> > > +++ include/bits/stl_bvector.h	(working copy)
> > > @@ -802,25 +802,25 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER
> > > #endif
> > >
> > > #if __cplusplus >= 201103L
> > >      void
> > >      assign(initializer_list<bool> __l)
> > >      { _M_assign_aux(__l.begin(), __l.end(), 
> > > random_access_iterator_tag()); }
> > > #endif
> > >
> > >      iterator
> > >      begin() _GLIBCXX_NOEXCEPT
> > > -      { return this->_M_impl._M_start; }
> > > +      { return { this->_M_impl._M_start._M_p, 0 }; }
> > >
> > >      const_iterator
> > >      begin() const _GLIBCXX_NOEXCEPT
> > > -      { return this->_M_impl._M_start; }
> > > +      { return { this->_M_impl._M_start._M_p, 0 }; }
> >
> > Won't this fail to compile in C++98 mode?
>
> "I used C++11 syntax because I find it nicer, and the compiler accepts 
> it in C++98 mode with just a warning, suppressed in a standard 
> header."

Oh sorry, I just looked at the patch and replied without reading the
top bit.

> Even with -Wsystem-headers I don't get a warning, I have to precompile 
> with -P -E then compile the result to get "warning: extended 
> initializer lists only available with -std=c++11 or -std=gnu++11".

OK for trunk then.