From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 13751 invoked by alias); 8 Nov 2011 13:37:58 -0000 Received: (qmail 13667 invoked by uid 22791); 8 Nov 2011 13:37:56 -0000 X-SWARE-Spam-Status: No, hits=-2.3 required=5.0 tests=AWL,BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW X-Spam-Check-By: sourceware.org Received: from mail-bw0-f47.google.com (HELO mail-bw0-f47.google.com) (209.85.214.47) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 08 Nov 2011 13:37:40 +0000 Received: by bkbzs2 with SMTP id zs2so437842bkb.20 for ; Tue, 08 Nov 2011 05:37:39 -0800 (PST) MIME-Version: 1.0 Received: by 10.182.114.42 with SMTP id jd10mr10152040obb.42.1320759458602; Tue, 08 Nov 2011 05:37:38 -0800 (PST) Received: by 10.182.17.232 with HTTP; Tue, 8 Nov 2011 05:37:38 -0800 (PST) In-Reply-To: <20111107214511.GP27375@tyan-ft48-01.lab.bos.redhat.com> References: <20111107214511.GP27375@tyan-ft48-01.lab.bos.redhat.com> Date: Tue, 08 Nov 2011 13:45:00 -0000 Message-ID: Subject: Re: Patch ping From: Richard Guenther To: Jakub Jelinek Cc: gcc-patches@gcc.gnu.org Content-Type: text/plain; charset=ISO-8859-1 X-IsSubscribed: yes 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 X-SW-Source: 2011-11/txt/msg01182.txt.bz2 On Mon, Nov 7, 2011 at 10:45 PM, Jakub Jelinek wrote: > Hi! > > I'd like to ping the restrict_based_on_field attribute patch: > http://gcc.gnu.org/ml/gcc-patches/2011-10/msg00135.html > > We currently don't do cast restricts and even if we do them again, > as this attribute doesn't make the type __restrict it wouldn't > affect those, it only affects parameters, if they are __restrict > themselves what they point to, and global vars. > > IMHO it would be a pitty not to improve generated code for std::vector > for 4.7. The patch probably needs updating for the changes I committed and it still says "The patch is still incomplete,.." It does look like this would map to the more general solution explicitely specifying a restrict tag. That way we'd avoid the funny field walkings (do you properly update the FIELD_DECL parameter of the attribute when instantiating templates?) --- libstdc++-v3/include/bits/stl_vector.h.jj 2011-08-18 08:36:12.000000000 +0200 +++ libstdc++-v3/include/bits/stl_vector.h 2011-10-03 15:45:26.000000000 +0200 @@ -77,9 +77,18 @@ _GLIBCXX_BEGIN_NAMESPACE_CONTAINER struct _Vector_impl : public _Tp_alloc_type { - pointer _M_start; - pointer _M_finish; - pointer _M_end_of_storage; + /* These pointers act like restricted pointers, except that there + are 3 pointers pointing into the same array instead of just one. + That is, if any part of the array pointed by _M_start is + modified, it can be accessed through either pointers based + on the _M_start field, or based on the _M_finish field, or + _M_end_of_storage field. */ + pointer _M_start + __attribute__((__restrict_based_on_field__ (_M_start))); + pointer _M_finish + __attribute__((__restrict_based_on_field__ (_M_start))); + pointer _M_end_of_storage + __attribute__((__restrict_based_on_field__ (_M_start))); are we sure that no shallow copies of vectors are allowed? I'm thinking of move constructors or so ... Finally just the above is not very much testing coverage. Thanks, Richard.