From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 96198 invoked by alias); 17 May 2018 11:28:52 -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 96177 invoked by uid 89); 17 May 2018 11:28:51 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-2.4 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,KAM_SHORT,RCVD_IN_DNSWL_NONE,SPF_PASS autolearn=ham version=3.3.2 spammy=D*fr X-Spam-User: qpsmtpd, 2 recipients X-HELO: mail-lf0-f65.google.com Received: from mail-lf0-f65.google.com (HELO mail-lf0-f65.google.com) (209.85.215.65) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 17 May 2018 11:28:49 +0000 Received: by mail-lf0-f65.google.com with SMTP id t129-v6so8221302lff.3; Thu, 17 May 2018 04:28:49 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=b/vq+VryjUW6CcJn/spxN1twfPlPx+4saiLKDQe7GYU=; b=J2JBPAYIst22/wcKWcgnRdmMwHCHUEbL5iDfuvoUzTb/zsrcURjAAgls2bx90Ta2Dv ly1H1IU+aG5cvTeqWmDlnoLmfvt8B6QR4Bl57CP5BX1win1wVDSHdbGfkrSm6eEFVeL7 jgIaoO9lsVXSZcuRtklrCa5nEFEHhV/1TXPYkE56KMZvUmkBujWtEBViKgih694WCray kwJKbVfb0Vsr7vPiBznnKfC36oAtC2sm1Tak94WhnA3hDujlvib2rrA0P8PaSeTso6M+ OoClUCSDwK04ub7VDv0evPqzT7Q5dfQYMnKFp/532Or+6QXl2MWqUM6B7Ex9oumFJDpZ fBFw== X-Gm-Message-State: ALKqPwdQjQCixWjLzfP9IaYH3DlLRSX2761w3v6wrrctew2V8bOZTivP ZJAy9ve0Wu+CmAyMTh9XanEOBLRafSzhQPGrtGzLBA== X-Google-Smtp-Source: AB8JxZqhPQX9to2yx7TKI9jOB7uLd6916wEKdSrZQTKYdEGQ4UmCKItc3bWTORqp+meTgYhzgDGUglzIAEvM3U71d0Q= X-Received: by 2002:a2e:808a:: with SMTP id i10-v6mr2803936ljg.67.1526556527426; Thu, 17 May 2018 04:28:47 -0700 (PDT) MIME-Version: 1.0 References: <20180514153713.GA4320@redhat.com> <20180517110055.GN7974@redhat.com> In-Reply-To: From: Richard Biener Date: Thu, 17 May 2018 11:29:00 -0000 Message-ID: Subject: Re: [PATCH] Add __attribute__((malloc) to allocator and remove unused code To: "libstdc++" Cc: jwakely@redhat.com, GCC Patches , Gabriel Dos Reis Content-Type: text/plain; charset="UTF-8" X-IsSubscribed: yes X-SW-Source: 2018-05/txt/msg00818.txt.bz2 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... Richard. > -- > Marc Glisse