From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66498 invoked by alias); 17 May 2018 11:42:54 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Received: (qmail 66469 invoked by uid 89); 17 May 2018 11:42:53 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.9 required=5.0 tests=BAYES_00,KAM_LAZY_DOMAIN_SECURITY,KAM_SHORT autolearn=no version=3.3.2 spammy= X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail3-relais-sop.national.inria.fr Received: from mail3-relais-sop.national.inria.fr (HELO mail3-relais-sop.national.inria.fr) (192.134.164.104) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 17 May 2018 11:42:51 +0000 Received: from ip-34.net-89-2-101.rev.numericable.fr (HELO stedding) ([89.2.101.34]) by mail3-relais-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 17 May 2018 13:42:48 +0200 Date: Thu, 17 May 2018 12:05:00 -0000 From: Marc Glisse Reply-To: libstdc++@gcc.gnu.org To: Richard Biener cc: libstdc++ , jwakely@redhat.com, GCC Patches , Gabriel Dos Reis Subject: Re: [PATCH] Add __attribute__((malloc) to allocator and remove unused code In-Reply-To: Message-ID: References: <20180514153713.GA4320@redhat.com> <20180517110055.GN7974@redhat.com> User-Agent: Alpine 2.21 (DEB 202 2017-01-01) MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-SW-Source: 2018-05/txt/msg00821.txt.bz2 On Thu, 17 May 2018, Richard Biener wrote: > On Thu, May 17, 2018 at 1:14 PM Marc Glisse wrote: > >> 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. > > We don't have a good way to do this. Your suggestion of adding restrict > would work if it were not that only function-scope restrict uses are later > handled... This seems extremely similar to the issue of inlining functions with restrict arguments. I have written a PR, but it is probably not worth submitting. -- Marc Glisse