Re: PATCH to fix NULLPTR_TYPE problems (bootstrap/44048, target/44099)

[Richard Guenther <richard dot guenther at gmail dot com>]

On Thu, May 13, 2010 at 7:11 AM, Jason Merrill <jason@redhat.com> wrote:
> Both of these PRs are problems caused by exposing NULLPTR_TYPE, a front end
> tree code, to language-independent code. ?I fixed the problems by changing
> the nullptr type to use LANG_TYPE instead of a new tree code; the debug
> output discussed on the dwarf list can be used as the default for any
> language-specific type, as it just says "unknown type named foo".
>
> While working on this, I noticed that much of the C++ front end uses the
> macro UNKNOWN_TYPE which is defined to LANG_TYPE, and then assumes that
> anything UNKNOWN_TYPE is in fact unknown_type_node, which is not a valid
> assumption. ?So I removed that macro and changed the various places that
> were checking the tree code rather than the specific type node.
>
> Tested x86_64-pc-linux-gnu, applied to trunk.

This now causes problems with LTO, as we leak nullptr to the middle-end for
something like

  typedef decltype(nullptr) nullptr_t;
  nullptr_t a;

where the global variable 'a' will now have LANG_TYPE type (which we refuse
to stream and in turn ICE on nearly all libstdc++ testcases).

This is PR44561 btw.

Richard.