This is the mail archive of the
libstdc++@gcc.gnu.org
mailing list for the libstdc++ project.
Re: [PATCH] Add __attribute__((malloc) to allocator and remove unused code
- From: Marc Glisse <marc dot glisse at inria dot fr>
- To: Jonathan Wakely <jwakely at redhat dot com>
- Cc: libstdc++ at gcc dot gnu dot org, gcc-patches at gcc dot gnu dot org, Gabriel Dos Reis <gdr at integrable-solutions dot net>
- Date: Thu, 17 May 2018 12:54:24 +0200 (CEST)
- Subject: Re: [PATCH] Add __attribute__((malloc) to allocator and remove unused code
- References: <20180514153713.GA4320@redhat.com>
- Reply-to: libstdc++ at gcc dot gnu dot org
On Mon, 14 May 2018, Jonathan Wakely wrote:
As discussed at https://gcc.gnu.org/ml/libstdc++/2018-01/msg00073.html
we can simplify the allocator function for valarray memory. I also
noticed that the _Array(size_t) constructor is never used.
* include/bits/valarray_array.h (__valarray_get_memory): Remove.
(__valarray_get_storage): Call operator new directly. Remove ignored
top-level restrict qualifier and add malloc attribute instead.
I am trying to understand the point of adding this attribute. The function
is just
{ return static_cast<_Tp*>(operator new(__n * sizeof(_Tp))); }
The idea is that it isn't safe (? see PR 23383) to mark operator new with
the attribute, but it is safe for this particular use?
When optimizing, I certainly hope this trivial function gets inlined, and
then the attribute is lost (should the inliner add 'restrict' when
inlining a function with attribute malloc?) and all that matters is
operator new.
--
Marc Glisse