This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [tree-ssa] Fix gcc.dg/tree-ssa/20030530-2.c


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]