[PATCH] Fix PR middle-end/52894

Steven Bosscher stevenb.gcc@gmail.com
Tue Apr 10 13:36:00 GMT 2012


On Tue, Apr 10, 2012 at 2:44 PM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Tue, Apr 10, 2012 at 2:28 PM, Dave Anglin <dave.anglin@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.

Ciao!
Steven



More information about the Gcc-patches mailing list