[Bug gcov-profile/59542] New: [4.9 Regression] ICE: verify_flow_info failed during Firefox build with 'gold'

[Bug gcov-profile/59542] New: [4.9 Regression] ICE: verify_flow_info failed during Firefox build with 'gold'

[trippels at gcc dot gnu.org]

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

            Bug ID: 59542
           Summary: [4.9 Regression] ICE: verify_flow_info failed during
                    Firefox build with 'gold'
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: gcov-profile
          Assignee: unassigned at gcc dot gnu.org
          Reporter: trippels at gcc dot gnu.org

Firefox LTO/PGO build fails when using the gold linker.

The testcase is too big to attach.

 % wget trippelsdorf.de/testcase.tar.bz2
 % tar xvjf testcase.tar.bz2
 % g++ -fuse-ld=gold -w -nostdlib -r -flto=4 -fprofile-use -fprofile-correction
-march=amdfam10 -fno-rtti -fno-exceptions -fno-math-errno -std=gnu++0x -pipe
-O3 Unified_cpp_7.ii Unified_cpp_8.ii

/var/tmp/mozilla-central/js/src/vm/Interpreter.cpp: In function ‘Interpret’:
/var/tmp/mozilla-central/js/src/vm/Interpreter.cpp:3469:1: error: non-cold
basic block 39 dominated by a block in the cold partition (2517)
 }
 ^
/var/tmp/mozilla-central/js/src/vm/Interpreter.cpp:3469:1: internal compiler
error: verify_flow_info failed
0x5a1ecd verify_flow_info()
        ../../gcc/gcc/cfghooks.c:260
0x5b4ee2 cfg_layout_finalize()
        ../../gcc/gcc/cfgrtl.c:4286
0xd44662 duplicate_computed_gotos
        ../../gcc/gcc/bb-reorder.c:2492
0xd44662 execute
        ../../gcc/gcc/bb-reorder.c:2524
Please submit a full bug report,
with preprocessed source if appropriate.
Please include the complete backtrace with any bug report.
See <http://gcc.gnu.org/bugs.html> for instructions.
make: *** [/tmp/ccvLwfUA.ltrans0.ltrans.o] Error 1

With -fuse-ld=bfd everything works just fine.
>From gcc-bugs-return-437955-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Dec 18 08:57:23 2013
Return-Path: <gcc-bugs-return-437955-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 866 invoked by alias); 18 Dec 2013 08:57:23 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 798 invoked by uid 48); 18 Dec 2013 08:57:19 -0000
From: "amker.cheng at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/50955] [4.7 Regression] IVopts incorrectly rewrite the address of a global memory access into a local form.
Date: Wed, 18 Dec 2013 08:57:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.7.0
X-Bugzilla-Keywords: wrong-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: amker.cheng at gmail dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: rguenth at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-50955-4-FLzv34W4gj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-50955-4@http.gcc.gnu.org/bugzilla/>
References: <bug-50955-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-12/txt/msg01610.txt.bz2
Content-length: 5177

http://gcc.gnu.org/bugzilla/show_bug.cgi?idP955

bin.cheng <amker.cheng at gmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |amker.cheng at gmail dot com

--- Comment #17 from bin.cheng <amker.cheng at gmail dot com> ---
Hi Richard,
I am having difficulty in understanding cases if this PR.
For the reported case with two loops:

  for( y=0; y<4; y++, pDst += dstStep ) {
    for( x=y+1; x<4; x++ ) {
                    s = ( p1[x-y-1] + p1[x-y] + p1[x-y] + p1[x-y+1] + 2 ) >> 2;
                    pDst[x] = (unsigned char)s;
    }

    pDst[y] = p3;
  }

The dump for statement 'pDst[y] = p3;' before IVOPT is like:

<bb 4>:
Invalid sum of incoming frequencies 1667, should be 278
  y.2_64 = (sizetype) y_89;
  D.6421_65 = pDst_88 + y.2_64;
  *D.6421_65 = p3_37;
  pDst_69 = pDst_88 + pretmp.21_118;
  ivtmp.35_116 = ivtmp.35_87 - 1;
  if (ivtmp.35_116 != 0)
    goto <bb 18>;
  else
    goto <bb 19>;


IVOPT chooses candidate 15:
candidate 15
  depends on 3
  var_before ivtmp.154
  var_after ivtmp.154
  incremented before exit test
  type unsigned int
  base (unsigned int) pDst_39(D) - (unsigned int) &p1
  step (unsigned int) (pretmp.21_118 + 1)
for use 1:
use 1
  address
  in statement *D.6421_65 = p3_37;

  at position *D.6421_65
  type unsigned char *
  base pDst_39(D)
  step pretmp.21_118 + 1
  base object (void *) pDst_39(D)
  related candidates

After rewriting, the dump is like:

<bb 4>:
Invalid sum of incoming frequencies 1667, should be 278
  MEM[symbol: p1, index: ivtmp.154_200, offset: 0B] = p3_37;
  pDst_69 = pDst_88 + pretmp.21_118;
  ivtmp.149_218 = ivtmp.149_249 - 1;
  ivtmp.154_190 = ivtmp.154_200 + D.6617_250;
  if (x_40 != 4)
    goto <bb 18>;
  else
    goto <bb 19>;

Eventually, the storing to TMR[p1,ivtmp,0] is considered local and deleted.

BUT, for your reduced case:

  p3 = (unsigned char)(((signed int)p1[1] + (signed int)p2[1]
                        + (signed int)p1[0] +(signed int)p1[0] + 2 ) >> 2 );

  for( x=y+1; x<4; x++ ) {
      s = ( p1[x-y-1] + p1[x-y] + p1[x-y] + p1[x-y+1] + 2 ) >> 2;
      pDst[x] = (unsigned char)s;
  }

  pDst[y] = p3;

It is about the the TMR in below dump (before IVOPT):

<bb 6>:
  # vect_pp1.30_166 = PHI <vect_pp1.30_167(16), vect_pp1.33_165(5)>
  # vect_pp1.37_176 = PHI <vect_pp1.37_177(16), vect_pp1.40_175(5)>
  # vect_pp1.46_194 = PHI <vect_pp1.46_195(16), vect_pp1.49_193(5)>
  # vect_p.60_223 = PHI <vect_p.60_224(16), vect_p.63_222(5)>
  # ivtmp.64_225 = PHI <ivtmp.64_226(16), 0(5)>
  ...
  MEM[(unsigned char *)vect_p.60_223] = vect_var_.58_219;
  vect_pp1.30_167 = vect_pp1.30_166 + 8;
  vect_pp1.37_177 = vect_pp1.37_176 + 8;
  vect_pp1.46_195 = vect_pp1.46_194 + 8;
  vect_p.60_224 = vect_p.60_223 + 8;
  ivtmp.64_226 = ivtmp.64_225 + 1;
  if (ivtmp.64_226 < bnd.27_128)
    goto <bb 16>;
  else
    goto <bb 7>;

Your patch prevents IVOPT from choosing cand 4:
candidate 4 (important)
  var_before ivtmp.110
  var_after ivtmp.110
  incremented before exit test
  type unsigned int
  base (unsigned int) (&p1 + 8)
  step 8
  base object (void *) &p1
for use 3:
use 3
  generic
  in statement vect_p.60_223 = PHI <vect_p.60_224(16), vect_p.63_222(5)>

  at position
  type vector(8) unsigned char *
  base batmp.61_221 + 1
  step 8
  base object (void *) batmp.61_221
  is a biv
  related candidates

To prevent IVOPT from rewriting into:

<bb 6>:
  # ivtmp.107_150 = PHI <ivtmp.107_256(16), 0(5)>
  # ivtmp.110_241 = PHI <ivtmp.110_146(16), ivtmp.110_132(5)>
  D.6585_133 = (unsigned int) batmp.61_221;
  p1.131_277 = (unsigned int) &p1;
  D.6587_278 = D.6585_133 - p1.131_277;
  D.6588_279 = D.6587_278 + ivtmp.110_241;
  D.6589_280 = D.6588_279 + 4294967289;
  D.6590_281 = (vector(8) unsigned char *) D.6589_280;
  vect_p.60_223 = D.6590_281;
  ...
  MEM[(unsigned char *)vect_p.60_223] = vect_var_.58_219;
  ivtmp.107_256 = ivtmp.107_150 + 1;
  ivtmp.110_146 = ivtmp.110_241 + 8;
  if (ivtmp.107_256 < bnd.27_128)
    goto <bb 16>;
  else
    goto <bb 7>;

Thus prevents IVOPT from generating candidate 15 in outer loop.  (Expressing
use 3 by cand 4 itself is good, right?)


-------------------------------
But,
It seems because the check:

  if (address_p)
    {
      /* Do not try to express address of an object with computation based
         on address of a different object.  This may cause problems in rtl
         level alias analysis (that does not expect this to be happening,
         as this is illegal in C), and would be unlikely to be useful
         anyway.  */
      if (use->iv->base_object
          && cand->iv->base_object
          && !operand_equal_p (use->iv->base_object, cand->iv->base_object, 0))
        return infinite_cost;

failed because cand(15)->iv->base_object == NULL.  For the reported case, it's
not about an iv use appearing in memory reference while not marked as
address_p, and can be fixed by revise the existing check condition, is it true?

PS, sorry for replying to a fixed PR, I found it's kind of impossible to fix
PR52272 without fully understanding this one.

[Bug gcov-profile/59542] [4.9 Regression] ICE: verify_flow_info failed during Firefox build with 'gold'

[trippels at gcc dot gnu.org]

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

--- Comment #1 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
https://sourceware.org/bugzilla/show_bug.cgi?id=12322
is still open.

[Bug gcov-profile/59542] [4.9 Regression] ICE: verify_flow_info failed during Firefox build with 'gold'

[tejohnson at google dot com]

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

--- Comment #2 from Teresa Johnson <tejohnson at google dot com> ---
Thanks, I am able to reproduce now with the gold linker option.
Investigating...
Teresa

On Wed, Dec 18, 2013 at 12:52 AM, trippels at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59542
>
> Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:
>
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>                  CC|                            |tejohnson at google dot com
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug gcov-profile/59542] [4.9 Regression] ICE: verify_flow_info failed during Firefox build with 'gold'

[tejohnson at google dot com]

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

--- Comment #3 from Teresa Johnson <tejohnson at google dot com> ---
On Wed, Dec 18, 2013 at 6:15 AM, Teresa Johnson <tejohnson@google.com> wrote:
> Thanks, I am able to reproduce now with the gold linker option. Investigating...
> Teresa
>
> On Wed, Dec 18, 2013 at 12:52 AM, trippels at gcc dot gnu.org
> <gcc-bugzilla@gcc.gnu.org> wrote:
>> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59542
>>
>> Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:
>>
>>            What    |Removed                     |Added
>> ----------------------------------------------------------------------------
>>                  CC|                            |tejohnson at google dot com
>>
>> --
>> You are receiving this mail because:
>> You are on the CC list for the bug.

Here is the patch that fixes it, and I am currently regression testing:

Teresa

2013-12-18  Teresa Johnson  <tejohnson@google.com>

        * bb-reorder.c (duplicate_computed_gotos): Invoke fixup_partitions
        if we have made any changes.

Index: bb-reorder.c
===================================================================
--- bb-reorder.c        (revision 206100)
+++ bb-reorder.c        (working copy)
@@ -2390,6 +2390,7 @@ duplicate_computed_gotos (void)
   basic_block bb, new_bb;
   bitmap candidates;
   int max_size;
+  bool changed = false;

   if (n_basic_blocks_for_fn (cfun) <= NUM_FIXED_BLOCKS + 1)
     return 0;
@@ -2486,9 +2487,17 @@ duplicate_computed_gotos (void)
       new_bb->aux = bb->aux;
       bb->aux = new_bb;
       new_bb->flags |= BB_VISITED;
+      changed = true;
     }

 done:
+  /* Duplicating blocks above will redirect edges and may cause hot blocks
+     previously reached by both hot and cold blocks to become dominated only
+     by cold blocks. This will cause the verification when leaving cfg layout
+     mode to fail, and lead to now cold code in the hot section. Invoke
+     fixup_partitions to address these problems.  */
+  if (changed)
+    fixup_partitions ();
   cfg_layout_finalize ();

   BITMAP_FREE (candidates);


>
>
>
> --
> Teresa Johnson | Software Engineer | tejohnson@google.com | 408-460-2413

[Bug gcov-profile/59542] [4.9 Regression] ICE: verify_flow_info failed during Firefox build with 'gold'

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P1
   Target Milestone|---                         |4.9.0

[Bug gcov-profile/59542] [4.9 Regression] ICE: verify_flow_info failed during Firefox build with 'gold'

[tejohnson at gcc dot gnu.org]

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

--- Comment #4 from tejohnson at gcc dot gnu.org ---
Author: tejohnson
Date: Thu Dec 19 22:11:25 2013
New Revision: 206135

URL: http://gcc.gnu.org/viewcvs?rev=206135&root=gcc&view=rev
Log:
2013-12-19  Teresa Johnson  <tejohnson@google.com>

    PR gcov-profile/59542
    * bb-reorder.c (duplicate_computed_gotos): Invoke fixup_partitions
    if we have made any changes.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/bb-reorder.c

[Bug gcov-profile/59542] [4.9 Regression] ICE: verify_flow_info failed during Firefox build with 'gold'

[trippels at gcc dot gnu.org]

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

Markus Trippelsdorf <trippels at gcc dot gnu.org> changed:

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

--- Comment #5 from Markus Trippelsdorf <trippels at gcc dot gnu.org> ---
Fixed. Thank you.