On Tue, Feb 5, 2019 at 10:46 AM Nikhil Benesch <nikhil.bene...@gmail.com> wrote: > > Ian—is there anything preventing this from getting merged? (I don't have > write access.)
Thanks, committed now. Ian > On Thu, Jan 24, 2019 at 11:31 AM Nikhil Benesch <nikhil.bene...@gmail.com> > wrote: > > > On Thu, Jan 24, 2019 at 10:15 AM Richard Biener > > <richard.guent...@gmail.com> wrote: > > > > > > Ah, I missed that pt is probably a pointer type as well, then the code > > > simply aligns the pointed-to type (note dependent on how pt was built > > > this seems prone to wreck the TYPE_POINTER_TO/TYPE_NEXT_PTR_TO > > > chains which link pointer types to a type. > > > > Right. In fact, set_placeholder_pointer_type asserts that both pt and tt > > are pointer types. > > > > It's true that, after a call to set_placeholder_pointer_type, pt becomes > > a distinct pointer type to T, yet is not part of the > > TYPE_POINTER_TO/TYPE_NEXT_PTR_TO chain for T. As far as I can tell, > > that's fine. The chain for T remains intact, as placeholder pointer > > types are careful to always point to a distinct dummy object (see the > > Gcc_backend::placeholder_pointer_type method) that nothing cares about. > > The only consequence I see is the increased memory usage of having > > multiple distinct but semantically identical pointer types to T. > >
