This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix PR middle-end/52894
On Tue, Apr 10, 2012 at 3:36 PM, Steven Bosscher <email@example.com> wrote:
> On Tue, Apr 10, 2012 at 2:44 PM, Richard Guenther
> <firstname.lastname@example.org> wrote:
>> On Tue, Apr 10, 2012 at 2:28 PM, Dave Anglin <email@example.com> 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
>>>> and the vector" is deleted. ?pa.c keeps its own vector which references
>>>> 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
>>> 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
>>> 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
>>> 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.