From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21236 invoked by alias); 30 Oct 2013 14:53:12 -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 21223 invoked by uid 89); 30 Oct 2013 14:53:11 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.7 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 30 Oct 2013 14:53:08 +0000 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r9UEr5Bu019051 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 30 Oct 2013 10:53:05 -0400 Received: from redhat.com (ovpn-116-47.ams2.redhat.com [10.36.116.47]) by int-mx12.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id r9UEqviq006366 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES128-SHA bits=128 verify=NO); Wed, 30 Oct 2013 10:53:03 -0400 Date: Wed, 30 Oct 2013 15:16:00 -0000 From: Marek Polacek To: Jason Merrill Cc: GCC Patches , Jakub Jelinek , "Joseph S. Myers" Subject: Re: [PATCH][ubsan] Add VLA bound instrumentation Message-ID: <20131030145253.GB31396@redhat.com> References: <20130912122655.GN23899@redhat.com> <20130925124132.GJ12296@redhat.com> <52697B9D.9000502@redhat.com> <20131025165803.GF27400@redhat.com> <526AB5CC.60408@redhat.com> <20131025190356.GG27400@redhat.com> <526AC0C9.1050003@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <526AC0C9.1050003@redhat.com> User-Agent: Mutt/1.5.20 (2009-06-14) X-SW-Source: 2013-10/txt/msg02548.txt.bz2 On Fri, Oct 25, 2013 at 03:04:41PM -0400, Jason Merrill wrote: > >I'm sorry, you want me to move the c++1y VLA check into > >compute_array_index_type, or just do the ubsan instrumentation in > >there? Thanks, > > Both. Unfortunately, I'm having quite a lot of trouble with side-effects. :( For e.g. int x = 1; int a[++x]; with the following hunk --- a/gcc/cp/decl.c +++ b/gcc/cp/decl.c @@ -8394,6 +8382,18 @@ compute_array_index_type (tree name, tree size, tsubst_flags_t com if (found) itype = variable_size (fold (newitype)); } + + if ((flag_sanitize & SANITIZE_VLA) + && !processing_template_decl + /* From C++1y onwards, we throw an exception on a negative + length size of an array; see above */ + && cxx_dialect < cxx1y) + { + tree x = cp_save_expr (size); + x = build2 (COMPOUND_EXPR, TREE_TYPE (x), + ubsan_instrument_vla (input_location, x), x); + finish_expr_stmt (x); + } } /* Make sure that there was no overflow when creating to a signed index type. (For example, on a 32-bit machine, an array with we generate int x = 1; int a[0:(sizetype) SAVE_EXPR ]; <>; < <= 0) { __builtin___ubsan_handle_vla_bound_not_positive (&*.Lubsan_data0, (unsigned long) SAVE_EXPR < ++x>); } else { 0 }, (void) SAVE_EXPR < ++x>; >>>>>; ssizetype D.2143; <>>>>; <];>>; that is, x is incremented twice and that is wrong. Is it possible to tell "x has already been evaluated, don't evaluate it again" so that the x isn't incremented in the cleanup_point? Or, would you, please, have some other advice? I've been looking into this for quite some time now, but haven't been able to come up with anything better than moving the checks back to create_array_type_for_decl, where it all started ;). Marek