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] Operand management II


In message <1071610959.13039.192.camel@p4>, Andrew MacLeod writes:
 >Now, I've discovered something very interesting along the way. The SSA
 >verifier is not catching all the problems we have. In fact, when I first
 >enabled this, I had 45 more failures in the gcc testsuite, all due to
 >the verifier.
 >
 >It turns out that an optimization can do something incorrect, like
 >remove a VDEF which still has uses, and the verifier may not catch it
 >because when it looks at SSA_NAE_DEF_STMT(ssa_name), it still points to
 >the old VDEF which was deleted.  AS long as that memory hasn't been
 >stomped on, it still looks fine. Ahhhh. So what was happening, I was
 >freeing an operand, overwriting the first word to use as a 'next'
 >pointer, and voila, it triggers the ssa verifier since it is no longer
 >correct.
FWIW, Jan has some improvements to the verification code which may 
(or may not) help detect this stuff.

I'm still trying to figure out how I want to twiddle the SSA_NAME recycling
code to make it more robust in terms of not leaving dangling SSA_NAMEs
in the IL.


Jeff


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