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: Diego Novillo <dnovillo at redhat dot com>
- To: Jeff Law <law at redhat dot com>
- Cc: "gcc-patches at gcc dot gnu dot org" <gcc-patches at gcc dot gnu dot org>
- Date: 12 Jun 2003 16:44:08 -0400
- Subject: Re: [tree-ssa] Fix gcc.dg/tree-ssa/20030530-2.c
- Organization: Red Hat Canada
- References: <200306122023.h5CKNuoV021232@speedy.slc.redhat.com>
On Thu, 2003-06-12 at 16:23, law@redhat.com wrote:
> print operand_equal_p (element->exp->operands[1], element->exp->operands[1], 0)
>
Yeah, they're the same.
> See my message from a couple weeks ago entitled "Questions about hashtab.c
> behavior". It went to Vlad, Jason, Andrew and you. I can resend it if
> you're interested in the details. The number of things that have to
> happen "just so" are pretty amazing, but it does happen.
>
Yup, I remember.
> Interestingly enough, I'm about to check in a change which fixes one case
> I've tripped over where we can get different has values for equal objects.
> The reason I mention it is that it also involves NOP conversions. We hash
> (via iterative_hash_object) on the TREE_TYPE of the conversion which hashes
> on the address of the TYPE. Which easily leads to this class of problems.
>
Good, because I think I'm tripping over this again on x86. I'm getting
a similar ICE when compiling libjava/verify.cc. It's odd because it
only happens when you initiate the compilation from libtool and if you
c-n-p the command into gdb, the program runs fine.
I have an unrelated patch in this x86 tree, so I've just started a build
on a pristine tree.
Diego.