This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Fix gcc.dg/tree-ssa/20030530-2.c
- From: law at redhat dot com
- To: Jason Merrill <jason at redhat dot com>
- Cc: Diego Novillo <dnovillo at redhat dot com>, "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: Wed, 11 Jun 2003 13:19:31 -0600
- Subject: Re: [tree-ssa] Fix gcc.dg/tree-ssa/20030530-2.c
- Reply-to: law at redhat dot com
In message <wvladcofmyj.fsf@prospero.boston.redhat.com>, Jason Merrill writes:
>On 11 Jun 2003 14:43:32 -0400, Diego Novillo <dnovillo@redhat.com> wrote:
>
>>> My gut is telling me that we should bite the bullet and sort the
>>> vuses based on some stable criteria.
>>>
>> Agreed. What I was proposing is to have them topologically sorted using
>> the tree operands. But that requires having separate sets for each
>> operand. The simplicity of the current scheme is that you have
>> everything in a single set. And that is giving us grief now.
>>
>>> Can you refresh my memory as to what objects can appear in the VUSE
>>> array? Just SSA_NAME, or do we potentially have things like
>>> COMPONENT_REF, INDIRECT_REF, VAR_REF, etc?
>>>
>> Just SSA_NAMEs. VUSEs are typically emitted for aliases. But we also
>> use VUSE/VDEFs for aggregate types.
>
>Heck, if we only have to deal with SSA_NAMEs, which are unique (right?), we
>can just sort by address.
Or their version #. Either way it's a simple comparison routine.
jeff