Re: [C++ RFC/Patch] PR 58561

[Paolo Carlini <paolo dot carlini at oracle dot com>]

On 01/29/2014 06:41 PM, Cary Coutant wrote:
> > in this bug we ICE in dwarf2out.c:is_base_type with -g, because it doesn't
> > know how to handle the TEMPLATE_TYPE_PARM coming from the C++ front-end and
> > representing 'auto' in this kind of C++1y code.
> >
> > That it shouldn't ICE and return 0 instead I'm pretty sure, I'm less sure
> > about the next problem, that is what gen_type_die_with_usage should do:
> > build a DW_TAG_unspecified_type, like happens for NULLPTR_TYPE or
> > LANG_TYPE?!? Anyway, my wild guessing resulted in adding an hook, per the
> > below draft (in any case, tentative names and comments but passes testing).
> > Or we want something completely different?
> We've been discussing this in the DWARF workgroup, and the current
> proposal on the table is to use DW_TAG_unspecified_type, as you have
> done here. This looks OK to me (although I kind of wish we had a
> better way of testing for "auto" than doing a string compare!).
> Depending on further discussions in the workgroup, we'll probably need
> to do a bit more work to support auto return types, but I think this
> is the right direction.
Thanks Cary. I think Jason already proceeded in this direction in his 
patch for c++/53756:

    http://gcc.gnu.org/ml/gcc-patches/2014-01/msg01806.html

and I'm following up with some additional bits for this bug. By the way, 
this recycling of TEMPLATE_TYPE_PARM + name seems weird to me too, I 
noticed it a couple of times already (I think it shows in an open 
diagnostic issue too). I think the alternative would an additional 
TREE_CODE and a lot of uses of it wherever now we just say 
TEMPLATE_TYPE_PARM (eg, in pt.c). Maybe it's worth it, maybe not, I 
don't know if Jason *actually* tried the idea in his local trees.

Paolo.