From patchwork Mon Apr 16 19:28:43 2018 Content-Type: text/plain; charset="utf-8" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit X-Patchwork-Submitter: Jakub Jelinek X-Patchwork-Id: 898984 Return-Path: X-Original-To: incoming@patchwork.ozlabs.org Delivered-To: patchwork-incoming@bilbo.ozlabs.org Authentication-Results: ozlabs.org; spf=pass (mailfrom) smtp.mailfrom=gcc.gnu.org (client-ip=209.132.180.131; helo=sourceware.org; envelope-from=gcc-patches-return-476453-incoming=patchwork.ozlabs.org@gcc.gnu.org; receiver=) Authentication-Results: ozlabs.org; dmarc=fail (p=none dis=none) header.from=redhat.com Authentication-Results: ozlabs.org; dkim=pass (1024-bit key; unprotected) header.d=gcc.gnu.org header.i=@gcc.gnu.org header.b="yW2HUp70"; dkim-atps=neutral Received: from sourceware.org (server1.sourceware.org [209.132.180.131]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ozlabs.org (Postfix) with ESMTPS id 40Q3B44ScKz9s0t for ; Tue, 17 Apr 2018 08:35:39 +1000 (AEST) DomainKey-Signature: a=rsa-sha1; c=nofws; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; q=dns; s=default; b=ATD3BvlCgC307hNuyBoFN64gLnXfA MBLRv1mssaKi1uWsINi2JQww0wdUWqlcv3hICNQ1Xr4enFRJ8Vx/2eLXDNpVCwgr JRU2XHD9dItgDnE5lw7RTFKTqrjU1pquEEVfhwy/fR4kmKwPvWBGxJEAqU4iposh eNmt1wIR8ngzHM= DKIM-Signature: v=1; a=rsa-sha1; c=relaxed; d=gcc.gnu.org; h=list-id :list-unsubscribe:list-archive:list-post:list-help:sender:date :from:to:cc:subject:message-id:reply-to:mime-version :content-type; s=default; bh=1BktKtUtRoJMzQUk2tZUeCHuVMM=; b=yW2 HUp70ubYi6TiUCjzQDbvPfc5DcZzA/RgtsP1IrLERHCEVclGCxYTFAPG1SIngGu6 LkkWHhsG1i6uGEd1PEtI8bQXRX7LsR9eC5XDK2Dfinfd+1gSIjN4c9+Ov1pmsBVL QgNghosEqjR2Gi3Jy3JiAfmL9UKnSmk+C14nvFk4= Received: (qmail 21563 invoked by alias); 16 Apr 2018 22:35:32 -0000 Mailing-List: contact gcc-patches-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Archive: List-Post: List-Help: Sender: gcc-patches-owner@gcc.gnu.org Delivered-To: mailing list gcc-patches@gcc.gnu.org Received: (qmail 21027 invoked by uid 89); 16 Apr 2018 22:35:31 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-11.6 required=5.0 tests=AWL, BAYES_00, GIT_PATCH_2, GIT_PATCH_3 autolearn=ham version=3.3.2 spammy= X-HELO: mx1.redhat.com Received: from mx3-rdu2.redhat.com (HELO mx1.redhat.com) (66.187.233.73) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Mon, 16 Apr 2018 22:35:30 +0000 Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com [10.11.54.6]) (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1.redhat.com (Postfix) with ESMTPS id A4793EBFE9 for ; Mon, 16 Apr 2018 22:35:22 +0000 (UTC) Received: from tucnak.zalov.cz (unknown [10.36.118.110]) by smtp.corp.redhat.com (Postfix) with ESMTPS id 64156215CDC8 for ; Mon, 16 Apr 2018 22:35:19 +0000 (UTC) Received: from tucnak.zalov.cz (localhost [127.0.0.1]) by tucnak.zalov.cz (8.15.2/8.15.2) with ESMTP id w3GJSiBq020468; Mon, 16 Apr 2018 21:28:44 +0200 Received: (from jakub@localhost) by tucnak.zalov.cz (8.15.2/8.15.2/Submit) id w3GJShVK020467; Mon, 16 Apr 2018 21:28:43 +0200 Date: Mon, 16 Apr 2018 21:28:43 +0200 From: Jakub Jelinek To: Jason Merrill Cc: gcc-patches@gcc.gnu.org Subject: [C++ PATCH] Fix constexpr handling of &x->y (PR c++/84463) Message-ID: <20180416192843.GT8577@tucnak> Reply-To: Jakub Jelinek MIME-Version: 1.0 Content-Disposition: inline User-Agent: Mutt/1.9.2 (2017-12-15) X-IsSubscribed: yes Hi! On the following new testcase we emit 2 different constexpr errors because of premature folding, where the PR44100 hack which is supposed to fold expressions like &((S *)0)->f or &((S *)24)->f folds all the &x->y expressions if x is TREE_CONSTANT into (some type)(x + cst) where what we were actually trying to access is lost. The following patch limits the offsetof-like expression hack to expressions where maybe_constant_value of val's operand is INTEGER_CST, or e.g. a cast of INTEGER_CST to some pointer type. This way we don't regress e.g. init/struct2.C, but don't mess up with x is e.g. some constexpr variable initialized to address of something. Or should it avoid maybe_constant_value and just handle the literal INTEGER_CST and cast thereof? We wouldn't handle &((S *)(24 + 8))->f that way though... The patches causes a small regression on constexpr-nullptr-1.C, it tries to compare (outside of constexpr contexts because it is undefined there) null with non-equality comparison with &x->y and was expecting it to be folded even when not optimizing, which is what doesn't happen anymore. We optimize it in the GIMPLE passes fine, so I've just added -O1. Earlier version of this patch has been bootstrapped/regtested on x86_64-linux and i686-linux, is this one ok for trunk if it passes bootstrap/regtest? 2018-04-16 Jakub Jelinek PR c++/84463 * typeck.c (cp_build_addr_expr_1): Don't use fold_offsetof_1 hack if val's operand does not fold into INTEGER_CST possibly wrapped with conversions. * g++.dg/cpp0x/constexpr-nullptr-1.C: Add -O1 to dg-options. * g++.dg/cpp0x/constexpr-84463.C: New test. Jakub --- gcc/cp/typeck.c.jj 2018-04-16 18:11:54.784378158 +0200 +++ gcc/cp/typeck.c 2018-04-16 21:03:15.674152875 +0200 @@ -5902,8 +5902,13 @@ cp_build_addr_expr_1 (tree arg, bool str && INDIRECT_REF_P (val) && TREE_CONSTANT (TREE_OPERAND (val, 0))) { - tree type = build_pointer_type (argtype); - return fold_convert (type, fold_offsetof_1 (arg)); + tree t = maybe_constant_value (TREE_OPERAND (val, 0)); + STRIP_NOPS (t); + if (TREE_CODE (t) == INTEGER_CST) + { + tree type = build_pointer_type (argtype); + return fold_convert (type, fold_offsetof_1 (arg)); + } } /* Handle complex lvalues (when permitted) --- gcc/testsuite/g++.dg/cpp0x/constexpr-nullptr-1.C.jj 2016-09-30 09:42:13.778446684 +0200 +++ gcc/testsuite/g++.dg/cpp0x/constexpr-nullptr-1.C 2018-04-16 21:13:06.057428435 +0200 @@ -6,7 +6,7 @@ // c++/67376 on gcc-patches for additional background. // { dg-do compile { target c++11 } } -// { dg-options "-fdelete-null-pointer-checks -fdump-tree-optimized" } +// { dg-options "-O1 -fdelete-null-pointer-checks -fdump-tree-optimized" } // Runtime assert. Used for potentially invalid expressions. #define RA(e) ((e) ? (void)0 : __builtin_abort ()) --- gcc/testsuite/g++.dg/cpp0x/constexpr-84463.C.jj 2018-04-16 21:02:16.282128997 +0200 +++ gcc/testsuite/g++.dg/cpp0x/constexpr-84463.C 2018-04-16 21:02:16.282128997 +0200 @@ -0,0 +1,22 @@ +// PR c++/84463 +// { dg-do compile { target c++11 } } + +struct S { int r; const unsigned char s[5]; }; +static constexpr S a[] = { { 0, "abcd" } }; +struct T { const unsigned char s[5]; }; +static constexpr T b[] = { { "abcd" } }; + +constexpr int +foo (const unsigned char *x) +{ + return x[0]; +} + +constexpr static const S *j = &a[0]; +constexpr static const int k = j->s[0]; +constexpr static int l = foo (a[0].s); +constexpr static int m = foo (j->s); +constexpr static const T *n = &b[0]; +constexpr static const int o = n->s[0]; +constexpr static int p = foo (b[0].s); +constexpr static int q = foo (n->s);