On Tue, Apr 10, 2012 at 3:36 PM, Steven Bosscher <stevenb....@gmail.com> wrote: > On Tue, Apr 10, 2012 at 2:44 PM, Richard Guenther > <richard.guent...@gmail.com> wrote: >> 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 deferral can be fixed properly - though I didn't >> look at the pa issue in detail. Maybe Steven can do this. > > It seems to me that the patch Dave posted is fine. It basically > reverts to the old situation (i.e. before the > pending_assemble_external stuff was added) for all back ends.
Well, ok then. Thanks, Richard. > Ciao! > Steven
