Re: Location wrappers vs decls that change type (was Re: [v2 of PATCH 03/14] C++: add location_t wrapper nodes during parsing (minimal impl))

[David Malcolm <dmalcolm at redhat dot com>]

On Mon, 2018-01-08 at 12:25 -0500, Nathan Sidwell wrote:
> On 01/08/2018 12:14 PM, Jakub Jelinek wrote:
> > On Mon, Jan 08, 2018 at 12:10:50PM -0500, Nathan Sidwell wrote:
> > > > Both "_S_terminal" VAR_DECLs have a "_CharT"
> > > > TEMPLATE_TYPE_PARM, but
> > > > these types are different tree nodes.
> > > 
> > > correct. they are not EQ but are EQUAL (same_type_p will be
> > > true).
> > 
> > So perhaps location_wrapper_p could use that instead of pointer
> > comparison.
> > Though it would be expensive.
> 
> If TYPE_STRUCTURAL_COMPARISON_P (or however it's spelt) is true,
> it'll 
> be expensive.  Otherwise it's a function call, a couple of
> indirections 
> and a pointer compare.  But still more expensive than ...
> 
> > > Add a flag on the VIEW_CONVERT/NON_LVALUE expr explicitly noting
> > > its
> > > wrapperness (rather than infer it from TREE_TYPE == TREE_TYPE
> > > (TREE_OPERAND)).  TREE_LANG_FLAG_0 looks available?
> > 
> > Yeah, I think most if not all lang flags are still available for
> > those two
> > tree codes and checking that should be quite cheap.
> 
> ... a bit test on the node itself.
> 
> location_wrapper_p could contain something like
>    bool result = TREE_LANG_FLAG_$FOO (t);
>    gcc_checking_assert (result == same_type_p (TREE_TYPE (t),
> TREE_TYPE 
> (TREE_OPERAND (t, 0)));
>    return result;
> 
> for the paranoid.
> 
> nathan

Thanks Nathan and Jakub: a quick smoketest using TREE_LANG_FLAG_0
worked, and fixes this issue.

However, should I be using a TREE_LANG_FLAG for something that's in
tree.h/c, rather than just in the "cp" subdir?  (the wrapper nodes are
only added to C++ in this patch kit, but given that e.g. STRIP_NOPS
needs to remove them, the lang-independent code needs to handle them,
and ultimately we may want wrapper nodes in other FEs).

Dave