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.

Reply via email to