[Bug debug/54693] New: VTA guality issues with loops

[Bug debug/54693] New: VTA guality issues with loops

[jakub at gcc dot gnu.org]

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

             Bug #: 54693
           Summary: VTA guality issues with loops
    Classification: Unclassified
           Product: gcc
           Version: 4.7.2
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: debug
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: jakub@gcc.gnu.org
                CC: aoliva@gcc.gnu.org


Something that has been reported privately to me - gcc -g -O2:
__attribute__((noinline, noclone)) void
foo (char *str, char c)
{
  asm volatile ("" : : "r" (str), "r" (c) : "memory");
  *str = c;
}

int
main ()
{
  int i;
  char c;
  char arr[11];

  for (i = 0; i < 10; i++)
    {
      c = 0x30 + i;
      foo (&arr[i], c);
    }

  __builtin_printf ("arr = %s\n", arr);
  return 0;
}

In 4.7.x the c variable in main is available in the whole loop (just not in the
prologue, but that is kind of expected when it is not initialized there), but
the i variable is available only in the prologue (0, correctly) and very short
part of the loop.  In 4.8.0
http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=185129
change made it even worse, the ivopts pass changes there the debug insns for i
to point to D#2 which is initialized to NULL right away.

As for the problem common to 4.7.x and 4.8.0, I think the issue is that vrp1
transforms:
  <bb 2>:
  # DEBUG i => 0
  goto <bb 4>;

  <bb 3>:
...
  # DEBUG i => i_10

  <bb 4>:
  # i_1 = PHI <0(2), i_10(3)>
  # DEBUG i => i_1
  if (i_1 <= 9)
    goto <bb 3>;
  else
    goto <bb 5>;
into:
  <bb 2>:
  # DEBUG i => 0
  goto <bb 6>;

  <bb 3>:
  # i_16 = PHI <i_1(4), i_14(6)>
...
  # DEBUG i => i_10

  <bb 4>:
  # i_1 = PHI <i_10(3)>
  # DEBUG i => i_1
  if (i_1 != 10)
    goto <bb 3>;
  else
    goto <bb 5>;
...
  <bb 6>:
  # i_14 = PHI <0(2)>
  # DEBUG i => i_14
  goto <bb 3>;

(still fine), but the debug insn no longer references the PHI), then dce1 comes
in, and I guess in some cfg cleanup makes this into:
  <bb 2>:
  # DEBUG i => 0
  # DEBUG i => 0

  <bb 3>:
  # i_16 = PHI <i_10(3), 0(2)>
...
  # DEBUG i => i_10
  # DEBUG i => i_10
  if (i_10 != 10)
    goto <bb 3>;
  else
    goto <bb 4>;

Note, in neither case ... contains any # DEBUG i => something stmts.
The problem with this is that vrp together with dce transformations effectively
moved the almost the end of the bb only, it is no longer at the start of the
loop where it used to be before the transformations.  Would be nice if we could
figure out that for the two blocks we have DEBUG stmts that refer to
corresponding PHI arguments (i_16 above) and that we should insert
  # DEBUG i => i_16
at the start of bb 3, because previously if going from bb 2 there is # DEBUG i
=> 0 and if going from bb 3 there is # DEBUG i => i_10.

Alex, what do you think?  As for IVOPTS, haven't looked at that at all yet.

[Bug debug/54693] VTA guality issues with loops

[jakub at gcc dot gnu.org]

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

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-10-01 15:26:10 UTC ---
In VRP it is jump threading that performs the first CFG transformation, and the
second one happens as two merge_block opportunities during cleanup_tree_cfg.
Doing the new DEBUG stmt insertion upon merge_blocks would be weird, perhaps
some pass should just in addition to what it does now try to detect at least
the simple cases, where at the end of more than one predecessor block are live
debug stmts for some decl, and they use invariants or SSA_NAMEs that appear
together in some PHI - then adding a DEBUG stmt at the start of the bb with a
PHI might improve debug info quality, something var-tracking won't be able to
figure out due to the conditional.

[Bug debug/54693] VTA guality issues with loops

[jakub at gcc dot gnu.org]

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

--- Comment #2 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-10-04 06:09:48 UTC ---
As a quick hack just for this testcase we might perhaps do something in jump
threading code, if we have a DEBUG stmt based on a PHI result and are splitting
it up, look if it is the last DEBUG stmt for the variable in the threaded bb
and if so, consider adding a DEBUG stmt also to the fallthru bb after the
threaded block, based on its PHI.

For the general solution, didn't give it much thought yet, but so far I was
thinking about a pass that would analyze on GIMPLE (perhaps shortly before
expansion) all DEBUG stmts and work similarly to tree-into-ssa.c algorithm
(just simplified by performing it just once, never incrementally). 
SSA_NAME_VERSION
for the debug stmt lhs decls could be some integer recorded perhaps as
gimple_uid on the debug stmts, we'd track the current definition of each debug
stmt lhs uid, and instead of inserting PHI nodes we could:
1) look for existing PHI node for the var mentioned in the debug stmt rhs,
   use that if exists
2) in bb with few incoming edges, look for existing PHI node with constant
   PHI arguments where for different current defs of some debug stmt lhs uid
   the constants have different values, like:
 <bb 7>:
   DEBUG i => D#12
   goto bb 9;
 <bb 8>:
   DEBUG i => i_17
 <bb 9>:
   z = PHI <7(7), 19(8)>

   We can then insert something like
   DEBUG i => z == 7 ? D#12 : i_17
3) otherwise punt.

Perhaps 2) would need some var-tracking changes, I'm afraid unavailability of a
VALUE for either of the branches of the COND_EXPR would reset it all.  But at
least 1) could work.

[Bug debug/54693] VTA guality issues with loops

[aoliva at gcc dot gnu.org]

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

--- Comment #3 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-10-14 21:19:00 UTC ---
Created attachment 28447
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=28447
Work in progress patch

This patch improves jump threading so that it won't drop debug info on the
floor as often as it does now, copying the debug bind stmts of the
jump-threaded block to the new confluence destination, so that the copies will
be updated so as to bind to the new PHI nodes, if needed.

This preserved variable i longer than before within the compilation, but it was
stll lost in ivopts.

I started looking into the ivopts loss: we need to rewrite at least the PHI
nodes we're removing in terms of the remaining ivs, but even though I wrote all
the needed infrastructure to adjust the debug info bindings, I couldn't figure
out how to express the dropped ivs in terms of the remaining ones.  I suppose
someone more familiar with tree-ivopts might have some idea, so I decided not
to spend more time trying to figure it out.

This is as far as I could get on my own.  I hope this helps.

[Bug debug/54693] VTA guality issues with loops

[jakub at gcc dot gnu.org]

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

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-10-19 12:34:14 UTC ---
Thanks, the threadedge patch looks reasonable (I think gimple_location on debug
stmts is ignored, so we don't need to drop it).

As for ivopts, there is no use in these cases.  We'd either need to add debug
uses of IVs as a special set of uses (perhaps in a different vector), that
wouldn't be used for decision of which IVs to keep/use, but just for
computation of the best candidate for it (where for debug info best is
something very different from best for code, for debug info smaller cost is as
small as possible expression, as few address expressions in it as possible, as
few SSA_NAMEs as possible).
Or I guess another alternative for unused IVs used in debug stmts is do what
your loop does (but drop the PHI check and do it for all unused IVs?; in the
particular testcase before your threadedge change the DEBUG stmts use i_10,
which is i_16 + 1 (where i_16 is set in PHI <i_10, 0>), so it wouldn't do
anything).  You can build an artificial temporary use object,
get_computation_at
only uses the iv field of it (so just struct iv_use use; memset (&use, 0,
sizeof (use)); use.iv = info->iv;, for stmt I'd use for PHI setters
gsi_after_labels stmt, for normal assignments next stmt after the setter it if
any.  And for cand perhaps go through all of the (or just a subsect of)
iv_cands that are
iv_use (data, i)->selected for some i.  Perhaps we can first search for a
cand->iv with equal step to the unused iv if any (and prefer integer bases over
more complex ones, on this testcase the removed iv used by some DEBUG stmts is:
ssa name i_10
  type int
  base 1
  step 1
  is a biv
and iv_cands that are selected by any uses are:
  type unsigned long
  base (unsigned long) &arr
  step 1
  base object (void *) &arr
and
  type unsigned int
  base 48
  step 1
where better is to use the second one, both because it has an integer base, and
because TYPE_MODE of its type is identical to TYPE_MODE of the iv (so no
extension/truncation is needed).  get_computation_at returns possibly large
tree, so we need to gimplify it into perhaps series of debug temps, finally
assign to a debug temp after the setter stmt, then rewrite all the debug stmt
uses to use this debug temp.

[Bug debug/54693] VTA guality issues with loops

[jakub at gcc dot gnu.org]

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

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-10-19 13:49:03 UTC ---
What I had in mind for ivopts is roughly this.  Not sure about the last
argument to get_computation_at.  For normal statements I'd hope it shouldn't
make a difference, the stmt that initializes the unused iv should hopefully not
be in any way related to the place where increment of the new iv will happen,
for phis it needs more investigation.

And I don't see any infrastructure to gimplify a larger expression into several
debug temporaries with simpler expressions.

--- gcc/tree-ssa-loop-ivopts.c.jj    2012-09-12 10:57:02.629762526 +0200
+++ gcc/tree-ssa-loop-ivopts.c    2012-10-19 15:35:19.631230006 +0200
@@ -6422,7 +6422,76 @@ remove_unused_ivs (struct ivopts_data *d
       && !info->inv_id
       && !info->iv->have_use_for
       && !info->preserve_biv)
-    bitmap_set_bit (toremove, SSA_NAME_VERSION (info->iv->ssa_name));
+    {
+      bitmap_set_bit (toremove, SSA_NAME_VERSION (info->iv->ssa_name));
+
+      if (MAY_HAVE_DEBUG_STMTS
+          && SSA_NAME_DEF_STMT (info->iv->ssa_name))
+        {
+          tree comp = NULL_TREE;
+          imm_use_iterator imm_iter;
+          use_operand_p use_p;
+          gimple stmt;
+
+          FOR_EACH_IMM_USE_STMT (stmt, imm_iter, info->iv->ssa_name)
+        {
+          if (!gimple_debug_bind_p (stmt))
+            continue;
+
+          if (comp == NULL_TREE)
+            {
+              struct iv_use dummy_use;
+              struct iv_cand *best_cand = NULL, *cand;
+              unsigned i, best_pref = 0, cand_pref;
+
+              memset (&dummy_use, 0, sizeof (dummy_use));
+              dummy_use.iv = info->iv;
+              for (i = 0; i < n_iv_uses (data) && i < 64; i++)
+            {
+              cand = iv_use (data, i)->selected;
+              if (cand == best_cand)
+                continue;
+              cand_pref = operand_equal_p (cand->iv->step,
+                               info->iv->step, 0)
+                      ? 4 : 0;
+              cand_pref
+                += TYPE_MODE (TREE_TYPE (cand->iv->base))
+                   == TYPE_MODE (TREE_TYPE (info->iv->base))
+                   ? 2 : 0;
+              cand_pref
+                += TREE_CODE (cand->iv->base) == INTEGER_CST
+                   ? 1 : 0;
+              if (best_cand == NULL || best_pref < cand_pref)
+                {
+                  best_cand = cand;
+                  best_pref = cand_pref;
+                }
+            }
+              if (best_cand == NULL)
+            BREAK_FROM_IMM_USE_STMT (imm_iter);
+
+              comp = get_computation_at (data->current_loop,
+                         &dummy_use, best_cand,
+                         SSA_NAME_DEF_STMT (info->iv->ssa_name));
+              if (comp == NULL_TREE)
+            BREAK_FROM_IMM_USE_STMT (imm_iter);
+              /* "gimplify" into DEBUG temporaries expression comp,
+             insert immediately after
+             SSA_NAME_DEF_STMT (info->iv->ssa_name).
+             Set comp to the final DEBUG_EXPR_DECL.  */
+#if 1
+              (void) comp;
+              BREAK_FROM_IMM_USE_STMT (imm_iter);
+#endif
+            }
+
+          FOR_EACH_IMM_USE_ON_STMT (use_p, imm_iter)
+            SET_USE (use_p, comp);
+
+          update_stmt (stmt);
+        }
+        }
+    }
     }

   release_defs_bitset (toremove);

[Bug debug/54693] VTA guality issues with loops

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |ASSIGNED
   Last reconfirmed|                            |2012-10-26
         AssignedTo|unassigned at gcc dot       |aoliva at gcc dot gnu.org
                   |gnu.org                     |
     Ever Confirmed|0                           |1

--- Comment #6 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-10-26 07:16:35 UTC ---
Patchset for trunk posted:
http://gcc.gnu.org/ml/gcc-patches/2012-10/msg02379.html

[Bug debug/54693] VTA guality issues with loops

[aoliva at gcc dot gnu.org]

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

--- Comment #7 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-10-29 19:26:21 UTC ---
Author: aoliva
Date: Mon Oct 29 19:26:16 2012
New Revision: 192957

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192957
Log:
PR debug/54693
* config/i386/i386.c (add_parameter_dependencies): Stop
backward scan at the insn before the incoming head.
(ix86_dependencies_evaluation_hook): Skip debug insns.  Stop
if first_arg is head.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c

[Bug debug/54693] VTA guality issues with loops

[aoliva at gcc dot gnu.org]

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

--- Comment #8 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-10-29 19:27:11 UTC ---
Author: aoliva
Date: Mon Oct 29 19:27:09 2012
New Revision: 192958

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192958
Log:
PR debug/54693
* loop-unroll.c (loop_exit_at_end_p): Skip debug insns.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/loop-unroll.c

[Bug debug/54693] VTA guality issues with loops

[aoliva at gcc dot gnu.org]

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

--- Comment #9 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-10-29 19:27:39 UTC ---
Author: aoliva
Date: Mon Oct 29 19:27:31 2012
New Revision: 192959

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192959
Log:
PR debug/54551
PR debug/54693
* valtrack.c (dead_debug_global_find): Accept NULL dtemp.
(dead_debug_global_insert): Return new entry.
(dead_debug_global_replace_temp): Return early if REG is no
longer in place, or if dtemp was already substituted.
(dead_debug_promote_uses): Insert for all defs and replace all
debug uses at once.
(dead_debug_local_finish): Release used after promotion.
(dead_debug_insert_temp): Stop if dtemp is NULL.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/valtrack.c

[Bug debug/54693] VTA guality issues with loops

[aoliva at gcc dot gnu.org]

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

--- Comment #11 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-10-29 19:37:31 UTC ---
Author: aoliva
Date: Mon Oct 29 19:37:25 2012
New Revision: 192962

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192962
Log:
PR debug/54693
* gcc/valtrack.c (dead_debug_insert_temp): Defer rescan of
newly-emitted debug insn.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/valtrack.c

[Bug debug/54693] VTA guality issues with loops

[aoliva at gcc dot gnu.org]

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

--- Comment #10 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-10-29 19:36:52 UTC ---
Author: aoliva
Date: Mon Oct 29 19:36:47 2012
New Revision: 192961

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=192961
Log:
gcc/ChangeLog:
PR debug/54693
* tree-ssa-threadedge.c (thread_around_empty_block): Copy
debug temps from predecessor before threading.
gcc/testsuite/ChangeLog:
PR debug/54693
* gcc.dg/guality/pr54693.c: New.

Added:
    trunk/gcc/testsuite/gcc.dg/guality/pr54693.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-threadedge.c

[Bug debug/54693] VTA guality issues with loops

[aoliva at gcc dot gnu.org]

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

--- Comment #12 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-10-30 23:47:44 UTC ---
Author: aoliva
Date: Tue Oct 30 23:47:35 2012
New Revision: 193003

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193003
Log:
PR debug/54551
PR debug/54693
* valtrack.c (dead_debug_promote_uses): Assert-check that
global used bit was clear and initialize entry
unconditionally.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/valtrack.c

[Bug debug/54693] VTA guality issues with loops

[aoliva at gcc dot gnu.org]

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

--- Comment #14 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-11-04 18:44:32 UTC ---
Author: aoliva
Date: Sun Nov  4 18:44:25 2012
New Revision: 193139

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193139
Log:
PR debug/54693
* tree-ssa-loop-ivopts.c (remove_unused_ivs): Emit debug temps
for dropped IV sets.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-loop-ivopts.c

[Bug debug/54693] VTA guality issues with loops

[aoliva at gcc dot gnu.org]

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

--- Comment #13 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-11-04 18:44:18 UTC ---
Author: aoliva
Date: Sun Nov  4 18:44:13 2012
New Revision: 193138

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193138
Log:
PR debug/54693
* tree-ssa-threadedge.c (propagate_threaded_block_debug_into):
New, rewritten from debug stmt copying code...
(thread_around_empty_block): ... removed from here.
(thread_across_edge): Call propagate_threaded_block_debug_into.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-threadedge.c

[Bug debug/54693] VTA guality issues with loops

[aoliva at gcc dot gnu.org]

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

Alexandre Oliva <aoliva at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #15 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-11-04 22:09:12 UTC ---
Fixed

[Bug debug/54693] VTA guality issues with loops

[jakub at gcc dot gnu.org]

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

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-06 09:45:58 UTC ---
Not completely.  Apparently the new testcase fails on both x86_64-linux and
i686-linux with -O1 -g.  The reason for that is that with -O1 jump threading
isn't performed, and the bb duplication is done in tree-ssa-loop-ch.c instead.

So, I'd say we want to do something similar to what
propagate_threaded_block_debug_into does, in copy_loop_headers or so, on
copied_bbs, copying debug stmts into the loop body (exit->dest before the
gimple_duplicate_sese_region call).
Calling p propagate_threaded_block_debug_into (exit->dest, entry->dest)
from the debugger fixed the testcase for -O1 -g.

[Bug debug/54693] VTA guality issues with loops

[aoliva at gcc dot gnu.org]

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

--- Comment #17 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-11-06 17:59:04 UTC ---
Author: aoliva
Date: Tue Nov  6 17:58:52 2012
New Revision: 193251

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193251
Log:
PR debug/54693
* tree-ssa-threadedge.c (propagate_threaded_block_debug_into):
Use a stack vector before allocating a pointer set.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/tree-ssa-threadedge.c

[Bug debug/54693] VTA guality issues with loops

[jakub at gcc dot gnu.org]

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

--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> 2012-11-07 07:50:07 UTC ---
Author: jakub
Date: Wed Nov  7 07:50:01 2012
New Revision: 193281

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=193281
Log:
    PR debug/54693
    * tree-flow.h (propagate_threaded_block_debug_into): New prototype.
    * tree-ssa-threadedge.c (propagate_threaded_block_debug_into): No
    longer static.
    * tree-ssa-loop-ch.c (copy_loop_headers): Use it.

    * gcc.dg/guality/pr54693-2.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/guality/pr54693-2.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-flow.h
    trunk/gcc/tree-ssa-loop-ch.c
    trunk/gcc/tree-ssa-threadedge.c

[Bug debug/54693] VTA guality issues with loops

[andreast at gcc dot gnu.org]

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

Andreas Tobler <andreast at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andreast at gcc dot gnu.org

--- Comment #19 from Andreas Tobler <andreast at gcc dot gnu.org> 2012-11-17 10:01:05 UTC ---
The commit r193139, comment #14, breaks bootstrap on powerpc64-*-* with
--disabled-checking.

Seen here on powerpc64-unknown-freebsd10.0 and Peter Bergner confirmed the same
break on powerp64-*-linux*.

Bootstrap comparison failure!
gcc/tree-ssa-forwprop.o differs

<._ZL33ssa_forward_propagate_and_combinev+0x2548>
-    9658:    e8 89 00 09     ldu     r4,8(r9)
-    965c:    39 08 00 01     addi    r8,r8,1
+    9658:    39 08 00 01     addi    r8,r8,1
+    965c:    e8 89 00 09     ldu     r4,8(r9)
     9660:    4b ff ff d0     b       9630

[Bug debug/54693] VTA guality issues with loops

[andreast at gcc dot gnu.org]

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

--- Comment #20 from Andreas Tobler <andreast at gcc dot gnu.org> 2012-11-17 12:36:16 UTC ---
Just for clarification, the following commits (after #14) in this PR did not
resolve the bootstrap issue. I was on r193501 when I first encountered the
comparison failure and then I went back until the comparison failure went away.

[Bug debug/54693] VTA guality issues with loops

[aoliva at gcc dot gnu.org]

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

--- Comment #21 from Alexandre Oliva <aoliva at gcc dot gnu.org> 2012-11-18 01:56:04 UTC ---
This doesn't look like something the bugfix may have caused, but rather as some
latent bug exposed by that patch, like the latent bug fixed in comment 7. 
Anyway, a preprocessed code that would enable me to look into this with a cross
compiler would be appreciated.  TIA,