This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [tree-ssa] Operand management II
- From: law at redhat dot com
- To: Andrew MacLeod <amacleod at redhat dot com>
- Cc: gcc-patches <gcc-patches at gcc dot gnu dot org>
- Date: Tue, 16 Dec 2003 20:08:17 -0700
- Subject: Re: [tree-ssa] Operand management II
- Reply-to: law at redhat dot com
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