[PATCH] Add __attribute__((malloc) to allocator and remove unused code
Marc Glisse
marc.glisse@inria.fr
Thu May 17 11:14:00 GMT 2018
On Thu, 17 May 2018, Jonathan Wakely wrote:
> On 17/05/18 12:54 +0200, Marc Glisse wrote:
>> 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?
>
> I'd forgotten about that (I was assuming the compiler doesn't need to
> be told about the properties of operator new, because they're defined
> by the language). We can remove the attribute.
I am not necessarily asking to remove it. I don't have a good
understanding of what would break if we marked operator new with the
attribute, so I have no idea if those reasons also apply for this use in
valarray.
>> 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.
If we determine that using the attribute here but not on operator new is
the right choice, then I believe we need some middle-end tweaks so it
isn't ignored.
--
Marc Glisse
More information about the Libstdc++
mailing list