From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 88640 invoked by alias); 24 Nov 2015 11:37:03 -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 88627 invoked by uid 89); 24 Nov 2015 11:37:03 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-0.7 required=5.0 tests=AWL,BAYES_50,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-yk0-f174.google.com Received: from mail-yk0-f174.google.com (HELO mail-yk0-f174.google.com) (209.85.160.174) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-GCM-SHA256 encrypted) ESMTPS; Tue, 24 Nov 2015 11:37:01 +0000 Received: by ykba77 with SMTP id a77so14821769ykb.2 for ; Tue, 24 Nov 2015 03:36:59 -0800 (PST) MIME-Version: 1.0 X-Received: by 10.129.70.65 with SMTP id t62mr26893678ywa.240.1448365019389; Tue, 24 Nov 2015 03:36:59 -0800 (PST) Received: by 10.37.93.11 with HTTP; Tue, 24 Nov 2015 03:36:59 -0800 (PST) In-Reply-To: <1448362710.19594.234.camel@surprise> References: <1446868737-3306-1-git-send-email-dmalcolm@redhat.com> <1447563717-24429-1-git-send-email-dmalcolm@redhat.com> <564E3512.9080701@redhat.com> <56501A61.6010806@redhat.com> <20151121082151.GQ5675@tucnak.redhat.com> <1448297620.19594.168.camel@surprise> <20151123165754.GF5675@tucnak.redhat.com> <20151123170752.GO21807@redhat.com> <56536842.9090608@redhat.com> <1448362710.19594.234.camel@surprise> Date: Tue, 24 Nov 2015 11:50:00 -0000 Message-ID: Subject: Re: [PATCH/RFC] C++ FE: expression ranges (v2) From: Richard Biener To: David Malcolm Cc: Jason Merrill , Marek Polacek , Jakub Jelinek , GCC Patches Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-IsSubscribed: yes X-SW-Source: 2015-11/txt/msg02875.txt.bz2 On Tue, Nov 24, 2015 at 11:58 AM, David Malcolm wrote: > On Tue, 2015-11-24 at 10:40 +0100, Richard Biener wrote: >> On Mon, Nov 23, 2015 at 8:25 PM, Jason Merrill wrote: >> > On 11/23/2015 12:07 PM, Marek Polacek wrote: >> >> >> >> On Mon, Nov 23, 2015 at 05:57:54PM +0100, Jakub Jelinek wrote: >> >>> >> >>> On Mon, Nov 23, 2015 at 11:53:40AM -0500, David Malcolm wrote: >> >>>> >> >>>> Does the following look like the kind of thing you had in mind? (j= ust >> >>>> the tree.def part for now). Presumably usable for both lvalues and >> >>>> rvalues, where the thing it wraps is what's important. It merely e= xists >> >>>> to add an EXPR_LOCATION, for a usage of the wrapped thing. >> >>> >> >>> >> >>> Yes, but please see with Jason, Richard and perhaps others if they a= re ok >> >>> with that too before spending too much time in that direction. >> >>> All occurrences of it would have to be folded away during the >> >>> gimplification >> >>> at latest, this shouldn't be something we use in the middle-end. >> >> >> >> >> >> I'd expect LOCATION_EXPR be defined in c-family/c-common.def, not >> >> tree.def. >> >> And I'd think it shouldn't survive genericizing, thus never leak into= the >> >> ME. >> > >> > >> > Makes sense. > > FWIW, attached is a work-in-progress patch for the LOCATION_EXPR > approach. This one > * adds LOCATION_EXPR to cp/cp-tree.def, rather than to c-common.def (my > thinking being that if it's only being used in the C++ FE, make it > specific to it) > * LOCATION_EXPR wrapper nodes are created for VAR_DECL, PARM_DECL (I'm > not sure if I want to create them for STRING_CST) > * strips them out in cp_genericize_r > * verifies their absence in cp_gimplify_expr via a gcc_unreachable > * lots of use of STRIP_LOCATION_EXPRS around places which expect a > certain kind of node. This feels like a game of whack-a-mole. I've got > increasing amounts of the C++ stdlib to parse, but am running into > various folding issues: > > x86_64-pc-linux-gnu/libstdc++-v3/include/type_traits:2053:42: error: > =E2=80=98(std::size_t)0=E2=80=99 is not a constant expression > static const size_t _S_alignment =3D 0; > ^ > > which doesn't seem to be easily fixable; I'd already put a cp_fully_fold > into cp/constexpr.c:verify_constant, but this is: > > (gdb) call debug_tree (t) > type size > unit size > align 64 symtab 0 alias set -1 canonical type 0x7ffff18959d8 > precision 64 min max 0x7ffff18a35e0 18446744073709551615>> > constant > arg 0 type SI > size > unit size > align 32 symtab -243642208 alias set -1 canonical type > 0x7ffff18957e0 precision 32 min > max > pointer_to_this > > constant > arg 0 > /home/david/coding-3/gcc-git-rich-errors/build-no-cloog/x86_64-pc= -linux-gnu/libstdc++-v3/include/type_traits:2053:42 start: /home/david/codi= ng-3/gcc-git-rich-errors/build-no-cloog/x86_64-pc-linux-gnu/libstdc++-v3/in= clude/type_traits:2053:42 finish: /home/david/coding-3/gcc-git-rich-errors/= build-no-cloog/x86_64-pc-linux-gnu/libstdc++-v3/include/type_traits:2053:42> > /home/david/coding-3/gcc-git-rich-errors/build-no-cloog/x86_64-pc-lin= ux-gnu/libstdc++-v3/include/type_traits:2053:42 start: /home/david/coding-3= /gcc-git-rich-errors/build-no-cloog/x86_64-pc-linux-gnu/libstdc++-v3/includ= e/type_traits:2053:42 finish: /home/david/coding-3/gcc-git-rich-errors/buil= d-no-cloog/x86_64-pc-linux-gnu/libstdc++-v3/include/type_traits:2053:42> > > which isn't folded here by cp_fully_fold since we're in > processing_template_decl; STRIP_NOPS etc can't do it since LOCATION_EXPR > is frontend-specific. > > Any thoughts on how to work around this? > > >> OTOH then the FEs need to strip trees of it if they ever want to use >> sth from fold-const.c for example. NON_LVALUE_EXPR is not >> in c-family/c-common.def either... (and conveniently stripped with >> STRIP_NOPS and friends). > > Just to clarify, do you mean "NON_LVALUE_EXPR is *not* conveniently > stripped by STRIP_NOPS and friends"? No, it _is_ conveniently stripped because it's a middle-end tree code. All I wanted to say is that if you can make it work with a lang-tree-code more power to you but I'd expect it to me much easier to use a middle-end one if not just because of STRIP_NOPS and fold. > As far as I can tell, STRIP_NOPS > etc are all frontend-independent, hence frontend-specific tree types > can't be handled there. Yes (we'd definitely not want a langhook here ;)) >> Ok, I _would_ like to move NON_LVALUE_EXPR to the C frontend >> family as well... so I guess that would be a nice starting project >> and if you can make that work you can add LOCATION_EXPR to >> the C family only. > > At a higher level, I'm nervous about feature-creep here, relative to the > v2 patch; that one (mostly) worked, without creating a new tree type, in > that it captured the locations (and thus ranges) for the leaf nodes of > the parse tree for just long enough to let them be used when building > more interesting expressions, which is where the range information is > useful. I think at this stage a new tree code isn't appropriate. Richard. > Dave