On Tue, Apr 10, 2012 at 2:28 PM, Dave Anglin <dave.ang...@bell.net> wrote: > On 10-Apr-12, at 7:06 AM, Richard Guenther wrote: > >> I can't immediately see how your description of "the list of pending >> externals >> and the vector" is deleted. pa.c keeps its own vector which references >> the >> decls and the only issue I see is that if you call assemble_external after >> processing externals you ICE because the pointer-set is not initialized? >> >> Why does the pa backend end up calling assemble_external at final time? > > > The backend calls assemble_integer to output function descriptors at final > time. This indirectly calls assemble_external from output_addr_const. > This can be seen in comment #4 in the PR. This occurs after the pending > externals are processed. > > We have to ensure that we only output function descriptors that are > referenced, > and we can only determine this at final.
You mean function destcriptors for functions that are output? You already know this at cgraph clone materialization time. > As a result, assemble_external is called after the VEC has been deleted. > The compiler doesn't ICE. It goes into an infinite loop when a call to > pointer_set_insert tries to extend the deleted VEC. It does this even if > the > pointer is already in the VEC hash. Isn't the bug then that the backend deletes the VEC too early? > Previously, the storage wasn't deleted. I suspect the ineffective calls on > hpux > weren't noticed because assemble_external had already been called for the > function descriptors earlier, so the list in the backend was complete. > > The problem was first seen with the Linux target. There is no backend > list for this target because it doesn't use or need assemble_external. > > I personally think it was wrong to add the deferral in assemble_external, > but that's another issue. I think the best thing would be to revert the offending patch on old branches (4.6 and 4.5) and see if the deferal can be fixed properly - though I didn't look at the pa issue in detail. Maybe Steven can do this. Richard. > Dave.