[Bug middle-end/28752] bootstrap comparision fails with "-ftree-vectorize -maltivec" on ppc

law at redhat dot com gcc-bugzilla@gcc.gnu.org
Tue Nov 7 21:03:00 GMT 2006



------- Comment #11 from law at redhat dot com  2006-11-07 21:03 -------
Subject: Re:  bootstrap comparision fails with
        "-ftree-vectorize -maltivec" on ppc

On Tue, 2006-11-07 at 08:31 +0000, irar at il dot ibm dot com wrote:
> 
> ------- Comment #9 from irar at il dot ibm dot com  2006-11-07 08:31 -------
> In r110758 (and r110705) bootstrap with BOOT_CFLAGS="-O2 -g -ftree-vectorize
> -maltivec" fails with another error:
[ ... ]
I've been unable to make any progress with this.

It's not even clear to me right now that the .i file you sent is valid.
Every compiler I've tried to use to process that .i file complains
that the size of the test_real_width array is negative.  

Clearly I'm doing something different than you are.

I can speculate that one of a few things might be happening.


  1. We might have some kind of memory corruption or similar bug
     causing us to zero the SSA_NAME_DEF_STMT/TREE_CHAIN field of
     the affected SSA_NAME.  Possible, but unlikely.

  2. We have an SSA_NAME in the IL which was deleted.

  3. Something else totally unexpected.


#2 has happened in the past and I'd consider it the most likely
culprit.  What is interesting is that a checking failure was not
triggered -- our SSA verifiers should be checking for case #2 and
issuing an error.

So let's start with checking a couple things.

  1. Put a breakpoint in tree_ssa_cd_dce when compiling the
     offending function from recog.c.    When that breakpoint
     triggers issue:

     verify_ssa (true)

     I can't see any way for that to fail, but better safe than
     sorry.

  2. When the gcc_assert triggers, issue:

     debug_tree (op)
     debug_generic_stmt (op)

  3. Send me the phi-only copyprop dumps.


If #1 passes and #2 indicates the name in question is on the free
list, then either DCE is mucking things up or we have out-of-date
operands in the operand cache relative to the IL (which I can
detect with the dumps).

Jeff


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28752



More information about the Gcc-bugs mailing list