I'll try the POC patch in a bit (kind of ugly as we have to replicate this for a whole bunch of types, I guess).
Just FYI, I noticed this similar bug report came in today, not sure about the types: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80309 -- Bill Bill Schmidt, Ph.D. GCC for Linux on Power Linux on Power Toolchain IBM Linux Technology Center wschm...@linux.vnet.ibm.com > On Apr 4, 2017, at 8:49 AM, Nathan Sidwell <nat...@acm.org> wrote: > > On 04/04/2017 09:00 AM, Richard Biener wrote: > >> tree >> add_builtin_type (const char *name, tree type) >> { >> tree id = get_identifier (name); >> tree decl = build_decl (BUILTINS_LOCATION, TYPE_DECL, id, type); >> return lang_hooks.decls.pushdecl (decl); >> } >> >> this seems to miss setting TYPE_NAME (type) = decl - oh, that may be >> what set_underlying_type does via the langhook. > > Correct, via the langhook. I wonder if the smacking of the incoming-type's > TYPE_NAME is so that the global tree node references the now-named builtin > type. If we were to make a clone here, (things like) VS4SI_type_node would > remain an unnamed type. And I guess debug would be unhappy? > >> At this point I'd rather restrict fiddling in this fragile area in >> rs6000.c only ;) > > me too. > >> Does removing the TYPE_NAME setting fix things? > > no, those TYPE_NAME assignments are redundant -- set_underlying_type has > already initialized it. > > The attached PoC fixes 79905 (no idea what ppc test it might break) > > nathan > > -- > Nathan Sidwell > <79905-2.diff>
