From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 66081 invoked by alias); 2 Nov 2017 14:46:44 -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 66071 invoked by uid 89); 2 Nov 2017 14:46:44 -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,RCVD_IN_DNSWL_NONE,RCVD_IN_SORBS_SPAM autolearn=no version=3.3.2 spammy=H*RU:209.85.223.193, Hx-spam-relays-external:209.85.223.193 X-HELO: mail-io0-f193.google.com Received: from mail-io0-f193.google.com (HELO mail-io0-f193.google.com) (209.85.223.193) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Thu, 02 Nov 2017 14:46:42 +0000 Received: by mail-io0-f193.google.com with SMTP id d66so13655176ioe.5 for ; Thu, 02 Nov 2017 07:46:41 -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:in-reply-to:references:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=/55BDIxMnOjpfjivCzTVNNedTABk3LH7i7KrwgmDlFo=; b=EpGJUkvikxSsram2fgFfXJ7zGZCEQM6qZelz0rubXjn3Fg4WdEgO9v71lZQa5vkk76 4obVr/jf03UUCfZopAlzhCrA8R0kwcJwpxMVrb+RF3S7VvhpWzoruNmNJbG+KRGVfhFg /LBiF2oOIlYJJtj0v5P3H7eihwlqEuiyYxH4rVVr/T/6cDrkpSBDCUc4SrUsyILtp2pr OVKby39GzFTrTDKLCW2A2J3t0c7byuPC4osPC/WiXZk7mEPoiHsFfRaqJp1/7n/LJyZv EdoEkbdqrKHElv8X/H5qvgFkfeuhWulT20FGbBOmJnhI+Ide/0Qyz4y4mJYerC1Awci8 UHnw== X-Gm-Message-State: AMCzsaVmGWIjxZw/BLO4dcLnyITGTo3lcPmyVPWVcP928b2R5ZcnbYAw o/lUv3OEhDoPMMEqK8mk1e0xj73Y8V3W44Ck1zM1TA== X-Google-Smtp-Source: ABhQp+RJcgXPmBPTxTuKmIWQS3AhHQki0uWYAQOy7G2HiD6wZQkxt5pQfHu9rhiSv0vPbV1C0gAeQxh/4cnQMA1AmUs= X-Received: by 10.36.44.76 with SMTP id i73mr2934848iti.41.1509634000371; Thu, 02 Nov 2017 07:46:40 -0700 (PDT) MIME-Version: 1.0 Received: by 10.107.170.26 with HTTP; Thu, 2 Nov 2017 07:46:19 -0700 (PDT) In-Reply-To: <1509484153.15469.45.camel@redhat.com> References: <1508536408-57560-1-git-send-email-dmalcolm@redhat.com> <1509484153.15469.45.camel@redhat.com> From: Jason Merrill Date: Thu, 02 Nov 2017 14:46:00 -0000 Message-ID: Subject: Re: [PATCH] RFC: Preserving locations for variable-uses and constants (PR 43486) To: David Malcolm Cc: Nathan Sidwell , Jakub Jelinek , Richard Biener , gcc-patches List Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2017-11/txt/msg00098.txt.bz2 On Tue, Oct 31, 2017 at 5:09 PM, David Malcolm wrote: > On Tue, 2017-10-24 at 09:53 -0400, Jason Merrill wrote: >> On Fri, Oct 20, 2017 at 5:53 PM, David Malcolm >> wrote: >> > Design questions: >> > >> > * The patch introduces a new kind of tree node, currently called >> > DECL_WRAPPER_EXPR (although it's used for wrapping constants as >> > well >> > as decls). Should wrappers be a new kind of tree node, or should >> > they >> > reuse an existing TREE_CODE? (e.g. NOP_EXPR, CONVERT_EXPR, etc). >> > * NOP_EXPR: seems to be for use as an rvalue >> > * CONVERT_EXPR: for type conversions >> > * NON_LVALUE_EXPR: "Value is same as argument, but guaranteed >> > not an >> > lvalue" >> > * but we *do* want to support lvalues here >> >> I think using NON_LVALUE_EXPR for constants would be appropriate. >> >> > * VIEW_CONVERT_EXPR: viewing one thing as of a different type >> > * can it support lvalues? >> >> Yes, the purpose of VIEW_CONVERT_EXPR is to support lvalues, it seems >> like the right choice. >> >> Jason > > Thanks. I've been working on a new version of the patch using those > tree codes, but have run into an issue. > > In g++.dg/conversion/reinterpret1.C: > > // PR c++/15076 > > struct Y { Y(int &); }; > > int v; > Y y1(reinterpret_cast(v)); // { dg-error "" } > > With trunk, this successfully generates an error: > > reinterpret1.C:6:6: error: cannot bind non-const lvalue reference of ty= pe =E2=80=98int&=E2=80=99 to an rvalue of type =E2=80=98int=E2=80=99 > Y y1(reinterpret_cast(v)); // { dg-error "" } > ^~~~~~~~~~~~~~~~~~~~~~~~ > reinterpret1.C:3:12: note: initializing argument 1 of =E2=80=98Y::Y(i= nt&)=E2=80=99 > struct Y { Y(int &); }; > ^ > > where internally there's a NON_LVALUE_EXPR around a VAR_DECL, where > both have the same type: > > (gdb) call debug_tree (expr) > type size > unit-size > align:32 warn_if_not_align:0 symtab:0 alias-set -1 canonical-type= 0x7ffff132e5e8 precision:32 min m= ax > pointer_to_this reference_to_this <= reference_type 0x7ffff144ca80>> > > arg:0 > used public static tree_1 read SI /home/david/coding-3/gcc-git-ex= pr-vs-decl/src/gcc/testsuite/g++.dg/conversion/reinterpret1.C:5:5 size unit-size > align:32 warn_if_not_align:0 context > chain > public decl_2 VOID /home/david/coding-3/gcc-git-expr-vs-decl/= src/gcc/testsuite/g++.dg/conversion/reinterpret1.C:3:8 > align:8 warn_if_not_align:0 context chain >> > /home/david/coding-3/gcc-git-expr-vs-decl/src/gcc/testsuite/g++.dg/co= nversion/reinterpret1.C:6:6 start: /home/david/coding-3/gcc-git-expr-vs-dec= l/src/gcc/testsuite/g++.dg/conversion/reinterpret1.C:6:6 finish: /home/davi= d/coding-3/gcc-git-expr-vs-decl/src/gcc/testsuite/g++.dg/conversion/reinter= pret1.C:6:29> > > The problem is that this reinterpret cast "looks" just like one of my > location wrappers. Your code shouldn't strip a NON_LVALUE_EXPR around a VAR_DECL. > I see a similar issue with constants, where with: > > struct Y { Y(int &); }; > Y y1(reinterpret_cast(42)); > > trunk generates an error like the above, but my code handles the > NON_LVALUE_EXPR(INTEGER_CST(42)) > as if it were a location wrapper around the INTEGER_CST, and thus > doesn't emit the error. Why doesn't it emit the error? We should get the same error whether or not we strip the wrapper. Jason