[PATCH/RFC] C++ FE: expression ranges (v2)

[David Malcolm]

On Tue, 2015-11-24 at 10:40 +0100, Richard Biener wrote:
> On Mon, Nov 23, 2015 at 8:25 PM, Jason Merrill <jason@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"?  As far as I can tell, STRIP_NOPS
etc are all frontend-independent, hence frontend-specific tree types
can't be handled there.


> 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.

Dave
-------------- next part --------------
A non-text attachment was scrubbed...
Name: wip.patch
Type: text/x-patch
Size: 63442 bytes
Desc: not available
URL: <http://gcc.gnu.org/pipermail/gcc-patches/attachments/20151124/a86bc7b8/attachment.bin>