From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 92162 invoked by alias); 18 Mar 2016 18:13: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 92130 invoked by uid 89); 18 Mar 2016 18:13:10 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=1.8 required=5.0 tests=BAYES_50,KAM_LAZY_DOMAIN_SECURITY,RP_MATCHES_RCVD,SPF_HELO_PASS autolearn=no version=3.3.2 spammy=234306, INTEGER_CST, integer_zerop, eq_expr 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 (AES256-GCM-SHA384 encrypted) ESMTPS; Fri, 18 Mar 2016 18:13:09 +0000 Received: from int-mx13.intmail.prod.int.phx2.redhat.com (int-mx13.intmail.prod.int.phx2.redhat.com [10.5.11.26]) by mx1.redhat.com (Postfix) with ESMTPS id A8CC585545; Fri, 18 Mar 2016 18:13:07 +0000 (UTC) Received: from slagheap.utah.redhat.com (ovpn-113-164.phx2.redhat.com [10.3.113.164]) by int-mx13.intmail.prod.int.phx2.redhat.com (8.14.4/8.14.4) with ESMTP id u2IID6JQ017693; Fri, 18 Mar 2016 14:13:07 -0400 Subject: Re: [PATCH] c++/67376 Comparison with pointer to past-the-end, of array fails inside constant expression To: Martin Sebor , Gcc Patch List , Jason Merrill References: <56E72C33.8000301@gmail.com> <56E9B9C3.5000908@redhat.com> <56EB1ECA.90800@gmail.com> Cc: Marek Polacek , Jakub Jelinek From: Jeff Law Message-ID: <56EC4532.3070905@redhat.com> Date: Fri, 18 Mar 2016 19:13:00 -0000 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.6.0 MIME-Version: 1.0 In-Reply-To: <56EB1ECA.90800@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-IsSubscribed: yes X-SW-Source: 2016-03/txt/msg01113.txt.bz2 On 03/17/2016 03:16 PM, Martin Sebor wrote: > > gcc-67376.patch > > > PR c++/67376 - [5/6 regression] Comparison with pointer to past-the-end > of array fails inside constant expression > PR c++/70170 - [6 regression] bogus not a constant expression error comparing > pointer to array to null > PR c++/70172 - incorrect reinterpret_cast from integer to pointer error > on invalid constexpr initialization > PR c++/60760 - arithmetic on null pointers should not be allowed in constant > expressions > PR c++/70228 - insufficient detail in diagnostics for a constexpr out of bounds > array subscript > > gcc/testsuite/ChangeLog: > 2016-03-17 Martin Sebor > > PR c++/67376 > PR c++/70170 > PR c++/70172 > PR c++/60760 > PR c++/70228 > * g++.dg/cpp0x/constexpr-array-ptr10.C: New test. > * g++.dg/cpp0x/constexpr-array-ptr9.C: New test. > * g++.dg/cpp0x/constexpr-array5.C: Adjust text of expected diagnostic. > * g++.dg/cpp0x/constexpr-nullptr.C: Add test cases. > * g++.dg/cpp0x/constexpr-string.C: Same. > * g++.dg/cpp0x/constexpr-wstring2.C: Same. > * g++.dg/cpp0x/pr65398.C: Same. > * g++.dg/ext/constexpr-vla1.C: Same. > * g++.dg/ext/constexpr-vla2.C: Same. > * g++.dg/ext/constexpr-vla3.C: Same. > * g++.dg/ubsan/pr63956.C: Same. > > gcc/cp/ChangeLog: > 2016-03-17 Martin Sebor > > PR c++/67376 > PR c++/70170 > PR c++/70172 > PR c++/60760 > PR c++/70228 > * constexpr.c (cxx_eval_binary_expression): Add argument. > (cxx_eval_component_reference): Same. > (cxx_eval_constant_expression): Same. > (cxx_eval_indirect_ref): Same. > (cxx_eval_outermost_constant_expr): Same. > (diag_array_subscript): New function. > (cxx_eval_call_expression): Adjust. > (cxx_eval_conditional_expression): Same. > (cxx_eval_array_reference): Detect null pointers. > (cxx_eval_statement_list): Adjust. > > gcc/ChangeLog: > 2016-03-17 Martin Sebor > > PR c++/67376 > * fold-const.c (maybe_nonzero_address): New function. > (fold_comparison): Call it. Fold equality and relational > expressions involving null pointers. > (tree_single_nonzero_warnv_p): Call maybe_nonzero_address. > > Index: gcc/cp/constexpr.c > =================================================================== > --- gcc/cp/constexpr.c (revision 234306) > +++ gcc/cp/constexpr.c (working copy) > @@ -1839,11 +1874,26 @@ cxx_eval_array_reference (const constexp > @@ -3300,10 +3357,21 @@ cxx_eval_constant_expression (const cons > + > + if (TREE_CODE (t) == INTEGER_CST > + && TREE_CODE (TREE_TYPE (t)) == POINTER_TYPE > + && !integer_zerop (t)) > + { > + if (!ctx->quiet) > + error ("null pointer arithmetic in %qE", t); > + if (nullptr_p) > + *nullptr_p = true; > + } Something looks odd here. You're testing !integer_zerop, so in T is going to be non-NULL, but you mentioned null pointer arithmetic in the error message. Am I missing something here? > @@ -3738,15 +3812,32 @@ cxx_eval_constant_expression (const cons > Index: gcc/fold-const.c > @@ -8639,6 +8653,38 @@ fold_comparison (location_t loc, enum tr > base1 = build_fold_addr_expr_loc (loc, base1); > return fold_build2_loc (loc, code, type, base0, base1); > } > + > + /* Comparison between an ordinary (non-weak) symbol and a null > + pointer can be eliminated since such sybols must have a non > + null address. */ > + else if (DECL_P (base0) > + && maybe_nonzero_address (base0) > 0 > + // && (!HAS_DECL_ASSEMBLER_NAME_P (base0) || !DECL_WEAK (base0)) Please remove the commented out line. > + /* Avoid folding references to struct members at offset 0 to > + prevent tests like '&ptr->firstmember == 0' from getting > + eliminated. When ptr is null, although the -> expression > + is strictly speaking invalid, GCC retains it as a matter > + of QoI. See PR c/44555. */ > + && (TREE_CODE (op0) != ADDR_EXPR > + || TREE_CODE (TREE_OPERAND (op0, 0)) != COMPONENT_REF > + || compare_tree_int (DECL_FIELD_OFFSET ((TREE_OPERAND > + (TREE_OPERAND (op0, 0), 1))), 0)) > + && TREE_CODE (arg1) == INTEGER_CST > + && compare_tree_int (arg1, 0) == 0) > + { > + switch (code) > + { > + case GE_EXPR: > + case EQ_EXPR: > + case LE_EXPR: > + return boolean_false_node; > + case GT_EXPR: > + case LT_EXPR: > + case NE_EXPR: > + return boolean_true_node; > + default: gcc_unreachable (); Can you put the gcc_unreachable on a new line? I know there's a few cases in the sources where it's on the default: line, but the vast majority have it on its own line.