On Tue, Nov 24, 2015 at 11:58 AM, David Malcolm <dmalc...@redhat.com> wrote: > On Tue, 2015-11-24 at 10:40 +0100, Richard Biener wrote: >> On Mon, Nov 23, 2015 at 8:25 PM, Jason Merrill <ja...@redhat.com> 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? (just >> >>>> the tree.def part for now). Presumably usable for both lvalues and >> >>>> rvalues, where the thing it wraps is what's important. It merely exists >> >>>> to add an EXPR_LOCATION, for a usage of the wrapped thing. >> >>> >> >>> >> >>> Yes, but please see with Jason, Richard and perhaps others if they are 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: > ‘(std::size_t)0’ is not a constant expression > static const size_t _S_alignment = 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) > <nop_expr 0x7fffef03d580 > type <integer_type 0x7ffff1632f18 size_t unsigned type_6 DI > size <integer_cst 0x7ffff1891e58 constant 64> > unit size <integer_cst 0x7ffff1891e70 constant 8> > align 64 symtab 0 alias set -1 canonical type 0x7ffff18959d8 > precision 64 min <integer_cst 0x7ffff18b3138 0> max <integer_cst > 0x7ffff18a35e0 18446744073709551615>> > constant > arg 0 <location_expr 0x7fffef03d4e0 > type <integer_type 0x7ffff18957e0 int asm_written public type_6 > SI > size <integer_cst 0x7ffff18b30a8 constant 32> > unit size <integer_cst 0x7ffff18b30c0 constant 4> > align 32 symtab -243642208 alias set -1 canonical type > 0x7ffff18957e0 precision 32 min <integer_cst 0x7ffff18b3060 -2147483648> > max <integer_cst 0x7ffff18b3078 2147483647> > pointer_to_this <pointer_type 0x7ffff18b7930>> > constant > arg 0 <integer_cst 0x7ffff18b31f8 constant 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/coding-3/gcc-git-rich-errors/build-no-cloog/x86_64-pc-linux-gnu/libstdc++-v3/include/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-linux-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/include/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> > > 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
