[Bug bootstrap/61757] New: genmodes failure with enable-checking

[Bug bootstrap/61757] New: genmodes failure with enable-checking

[dcb314 at hotmail dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

            Bug ID: 61757
           Summary: genmodes failure with enable-checking
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
          Assignee: unassigned at gcc dot gnu.org
          Reporter: dcb314 at hotmail dot com

I just tried a bootstrap of revision 212385 with extra
flag --enable-checking=yes and got

echo timestamp > s-genrtl-h
build/genmodes -m > tmp-min-modes.c
build/genmodes: config/i386/i386-modes.def:25: (TF) field format must not be
set
build/genmodes: config/i386/i386-modes.def:24: (XF) field format must not be
set
build/genmodes: machmode.def:203: (DF) field format must not be set
build/genmodes: machmode.def:202: (SF) field format must not be set
build/genmodes: machmode.def:244: (TD) field format must not be set
build/genmodes: machmode.def:243: (DD) field format must not be set
build/genmodes: machmode.def:242: (SD) field format must not be set
make[3]: *** [s-modes-m] Error 1

Configure line is

../src/trunk/configure --prefix=/home/dcb/gcc/results --enable-checking=yes
--enable-languages=c,c++,fortran --disable-werror CC="clang -g -O2 -Wall
-fheinous-gnu-extensions" CXX="clang++ -g -O2 -Wall -fheinous-gnu-extensions"

Bootstrap line is

(date; time make BOOT_CFLAGS='-g -O3' CFLAGS_FOR_TARGET='-g -O3' -j 5
bootstrap; date) > mk.out 2>&1 &

[Bug bootstrap/61757] genmodes failure with enable-checking

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2014-07-09
     Ever confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
See also https://gcc.gnu.org/ml/gcc-regression/2014-07/

Same thing here on x86_64-apple-darwin13 at r212373 configured with

  $ ../p_work/configure --prefix=/opt/gcc/gcc4.10p-212373
--enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp
--with-system-zlib --enable-checking=release --with-isl=/opt/mp --enable-lto
--enable-plugin --with-arch=core2 --with-cpu=core2

My bootstrap compiler is gcc r211652. With it I have successfully
boostrapped r212366 configured with

  $ ../work/configure --prefix=/opt/gcc/gcc4.10w
--enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto --with-gmp=/opt/mp
--with-system-zlib --with-isl=/opt/mp --enable-lto --enable-plugin
--with-arch=corei7 --with-cpu=corei7

or r212374 configured with

  $ ../_clean/configure --prefix=/opt/gcc/gcc4.10c
--enable-languages=c,c++,fortran,objc,obj-c++,ada,java,lto --with-gmp=/opt/mp
--with-system-zlib --with-isl=/opt/mp --enable-lto --enable-plugin

[Bug bootstrap/61757] genmodes failure with enable-checking

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

ktkachov at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |aarch64-linux, x86, ia64
                 CC|                            |ktkachov at gcc dot gnu.org,
                   |                            |mshawcroft at gcc dot gnu.org

--- Comment #2 from ktkachov at gcc dot gnu.org ---
Confirmed on aarch64 as well

[Bug bootstrap/61757] [4.10 Regression] genmodes failure with enable-checking

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |build
           Priority|P3                          |P1
            Version|4.9.0                       |4.10.0
   Target Milestone|---                         |4.10.0
            Summary|genmodes failure with       |[4.10 Regression] genmodes
                   |enable-checking             |failure with
                   |                            |enable-checking

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

Andreas Schwab <schwab@linux-m68k.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |rguenther at suse dot de
          Component|bootstrap                   |tree-optimization

--- Comment #3 from Andreas Schwab <schwab@linux-m68k.org> ---
Broken by r212352.

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

--- Comment #4 from Andreas Schwab <schwab@linux-m68k.org> ---
This also breaks gcc.dg/tree-ssa/20030922-2.c on m68k.

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |us15 at os dot inf.tu-dresden.de

--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
*** Bug 61764 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
           Assignee|unassigned at gcc dot gnu.org      |rguenth at gcc dot gnu.org

--- Comment #6 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, for me a i586 bootstrap with r212352 works (x86_64 host, gcc 4.8 host
compiler) at least up to stage2 genmodes, from HJs fails it seems that only
stage3 genmodes fails (so lets wait a bit more...) which means that the stage2
compiler is miscompiled by the stage1 compiler (ugh).

Probably because of lack of time to search for the latent bug I'll end up
reverting the patch later :/  (I'll try reverting only parts of it, which
will take some extra verification time).

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[ktkachov at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

--- Comment #7 from ktkachov at gcc dot gnu.org ---
Don't know if this will help, but the bootstrap works fine on
arm-none-linux-gnueabihf (but breaks on aarch64 as mentioned previously)

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

--- Comment #8 from Andreas Schwab <schwab@linux-m68k.org> ---
$ diff -u gcc-201407{08,10}/Build/20030922-2.c.079t.dom1
--- gcc-20140708/Build/20030922-2.c.079t.dom1   2014-07-10 12:25:20.886372197
+0200
+++ gcc-20140710/Build/20030922-2.c.079t.dom1   2014-07-10 12:25:11.460420770
+0200
@@ -12,7 +12,6 @@
 ;; 4 succs { 5 6 }
 ;; 5 succs { 1 }
 ;; 6 succs { 1 }
-Removing basic block 4
 rgn_rank (struct rtx_def * insn1, struct rtx_def * insn2)
 {
   int * block_to_bb.0_2;
@@ -43,19 +42,25 @@
   if (_8 != _14)
     goto <bb 3>;
   else
-    goto <bb 5>;
+    goto <bb 6>;

   <bb 3>:
   target_bb.1_15 = target_bb;
   if (_14 == target_bb.1_15)
     goto <bb 4>;
   else
-    goto <bb 5>;
+    goto <bb 6>;

   <bb 4>:
-  return 1;
+  if (_8 != target_bb.1_15)
+    goto <bb 5>;
+  else
+    goto <bb 6>;

   <bb 5>:
+  return 1;
+
+  <bb 6>:
   return;

 }

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

--- Comment #9 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Thu Jul 10 14:43:07 2014
New Revision: 212433

URL: https://gcc.gnu.org/viewcvs?rev=212433&root=gcc&view=rev
Log:
2014-07-10  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/61757
    * tree-ssa-dom.c (loop_depth_of_name): Restore.
    (propagate_rhs_into_lhs): Revert part of last change.

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

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

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

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

--- Comment #10 from Richard Biener <rguenth at gcc dot gnu.org> ---
Bootstrap should be fixed now.  The m68k test fail must be unrelated - there
are no loops in the testcase.

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

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

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

--- Comment #11 from Richard Biener <rguenth at gcc dot gnu.org> ---
Still reproduces on x86_64 with --enable-checking=release.  stage1 gcc
miscompiles
stage2 tree-vrp.c which then miscompiles stage3 genmodes.  Now on to figure
how we miscompile tree-vrp.c ...

... probably not before next week though.

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

--- Comment #12 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
For the record:

Using built-in specs.
COLLECT_GCC=gfcp
COLLECT_LTO_WRAPPER=/opt/gcc/gcc4.10p-212433/libexec/gcc/x86_64-apple-darwin13.3.0/4.10.0/lto-wrapper
Target: x86_64-apple-darwin13.3.0
Configured with: ../p_work/configure --prefix=/opt/gcc/gcc4.10p-212433
--enable-languages=c,c++,lto,fortran,ada,objc,obj-c++ --with-gmp=/opt/mp
--with-system-zlib --enable-checking=release --with-isl=/opt/mp --enable-lto
--enable-plugin --with-arch=core2 --with-cpu=core2
Thread model: posix
gcc version 4.10.0 20140710 (experimental) [trunk revision 212433] (GCC)

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[ro at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

Rainer Orth <ro at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|aarch64-linux, x86, ia64    |aarch64-linux, x86, ia64,
                   |                            |sparc
                 CC|                            |ro at gcc dot gnu.org

--- Comment #13 from Rainer Orth <ro at gcc dot gnu.org> ---
Still breaks sparc-sun-solaris2.11 bootstrap, even after Richards patch.

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

--- Comment #14 from Andreas Schwab <schwab@linux-m68k.org> ---
Perhaps the m68k test failure can still provide an easier hint.

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[pthaugen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

Pat Haugen <pthaugen at gcc dot gnu.org> changed:

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

--- Comment #15 from Pat Haugen <pthaugen at gcc dot gnu.org> ---
CPU2000 benchmark 176.gcc started miscomparing on PowerPC(-m64 only) starting
with r212352. Currently trying to narrow down the problem...

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[matz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

Michael Matz <matz at gcc dot gnu.org> changed:

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

--- Comment #16 from Michael Matz <matz at gcc dot gnu.org> ---
At least the miscompilation of tree-vrp.c on x86-64 --enable-checking=release
bootstrap is due to the change in copy_prop_visit_phi_node().  The only
remaining one (in init_copy_prop) is harmless.

The dumps aren't that trivial to compare (many changes downstream the copyprop
passes), the diff of the disassembled tree-vrp is shorter, but also unwieldy.
So I hope Pat finds something from 176.gcc.

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[matz at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

--- Comment #17 from Michael Matz <matz at gcc dot gnu.org> ---
The testsuite failure on m68k is indeed caused by r212352.  In particular
this hunk:

@@ -1641,8 +1609,7 @@ record_equality (tree x, tree y)
      long as we canonicalize on one value.  */
   if (is_gimple_min_invariant (y))
     ;
-  else if (is_gimple_min_invariant (x)
-          || (loop_depth_of_name (x) <= loop_depth_of_name (y)))
+  else if (is_gimple_min_invariant (x))
     prev_x = x, x = y, y = prev_x, prev_x = prev_y;
   else if (prev_x && is_gimple_min_invariant (prev_x))
     x = y, y = prev_x, prev_x = prev_y;

The test is <=, so without loops (both SSA names being at 'depth' 0) the check
succeeds always and hence will canonicalize on x (i.e. record x as value of y).
The testcase is written so that this is the expected order for the third
if to be found trivial.

The problem doesn't happen on x86-64 because with -O1 the && condition is
rewritten into arithmetic on '&', so even though the wanted transformation
doesn't happen there are only two 'if ' statements, which is what is searched
for.

Unfortunately this is all harmless and not causing the miscompilations, it's
only a missed optimization.

FWIW, I think the canonicalization that DOM wants here should be retained
in some form (canonicalize to the value that covers a larger area).  Possibly
by checking if one definition dominates the other

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[schwab@linux-m68k.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

--- Comment #18 from Andreas Schwab <schwab@linux-m68k.org> ---
The testsuite failure is now bug 61783.

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[pthaugen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

--- Comment #19 from Pat Haugen <pthaugen at gcc dot gnu.org> ---
Tracked down the problem in 176.gcc to a difference in the generated code for
benchmark source toplev.c:exact_log2_wide(). Following compiled with -O3
-mcpu=power7.

int exact_log2_wide (unsigned int x)
{
  register int log = 0;

  if (x == 0 || x != (x & -x))
    return -1;
  while ((x >>= 1) != 0)
    log++;
  return log;
}

r212351:
    neg 9,3
    and 9,9,3
    cmplw 7,9,3
    bne 7,.L5
>>>	rldicl. 9,9,63,33
    li 3,0
    beq 0,.L6

r212352:
    neg 10,3
    and 10,10,3
    cmplw 7,10,3
    bne 7,.L5
>>>	srdi. 9,3,1
    li 3,0
    beq 0,.L6

r212351 is clearing the high word of the 64-bit register on the initial shift
right of 'x', whereas r212352 just starts shifting the whole 64-bit reg. The
reason this causes problems is that the callers are calling with an integer
arg:

#define exact_log2(N) exact_log2_wide ((HOST_WIDE_INT) (N))

So in the case where MIN_INT32 is passed (sign extended), the upper 32 bits are
'1' so r212352 returns a value of 63 whereas prior revisions returned a value
of 31.

Not sure if this is more of a benchmark source error, but figured I'd post my
findings in case it helps with the general problem.
>From gcc-bugs-return-456150-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Sat Jul 12 01:42:52 2014
Return-Path: <gcc-bugs-return-456150-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 18840 invoked by alias); 12 Jul 2014 01:42:52 -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 18782 invoked by uid 48); 12 Jul 2014 01:42:48 -0000
From: "emsr at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/57644] [C++1y] Cannot bind bitfield to lvalue reference
Date: Sat, 12 Jul 2014 01:42:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: emsr at gcc dot gnu.org
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status cc resolution
Message-ID: <bug-57644-4-s7lpa2b7gY@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57644-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57644-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: 2014-07/txt/msg00741.txt.bz2
Content-length: 472

https://gcc.gnu.org/bugzilla/show_bug.cgi?idW644

emsr at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |RESOLVED
                 CC|                            |emsr at gcc dot gnu.org
         Resolution|---                         |FIXED

--- Comment #5 from emsr at gcc dot gnu.org ---
Fixed on trunk...

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kikairoya at gmail dot com

--- Comment #20 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
*** Bug 61793 has been marked as a duplicate of this bug. ***

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[segher at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

Segher Boessenkool <segher at gcc dot gnu.org> changed:

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

--- Comment #21 from Segher Boessenkool <segher at gcc dot gnu.org> ---
(In reply to Pat Haugen from comment #19)
> So in the case where MIN_INT32 is passed (sign extended), the upper 32 bits
> are '1' so r212352 returns a value of 63 whereas prior revisions returned a
> value of 31.

When called with r3=ffffffff80000000 the new code
returns -1 as far as I can see?

And it should be called with 0000000080000000 instead;
does the caller not have a prototype in scope?

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[danglin at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

John David Anglin <danglin at gcc dot gnu.org> changed:

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

--- Comment #22 from John David Anglin <danglin at gcc dot gnu.org> ---
Bootstrap is still broken on hppa-unknown-linux-gnu as revision 212498:

echo timestamp > s-genrtl-h
build/genmodes -m > tmp-min-modes.c
build/genhooks "Target Hook" \
                                     > tmp-target-hooks-def.h
build/genmodes: config/pa/pa-modes.def:29: (TF) field format must not be set
build/genmodes: machmode.def:203: (DF) field format must not be set
build/genmodes: machmode.def:202: (SF) field format must not be set
build/genmodes: machmode.def:244: (TD) field format must not be set
build/genmodes: machmode.def:243: (DD) field format must not be set
build/genmodes: machmode.def:242: (SD) field format must not be set
Makefile:2175: recipe for target 's-modes-m' failed

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

--- Comment #23 from Richard Biener <rguenth at gcc dot gnu.org> ---
The first interesting difference is that for

  <bb 14>:
  _793 = ASSERT_EXPR <_73, _73 != 18>;
  switch (_793) <default: <L32>, case 0: <L26>, case 1: <L27>, case 2: <L28>,
case 3: <L29>, case 4 ... 9: <L28>, case 10 ... 11: <L30>, case 12 ... 17:
<L31>>

<L28>:

we record an equality instead of a range:

@@ -17655,13 +17655,7 @@

        BB #19
        EDGE 14->19 14 [14.3%]  (EXECUTABLE)
-       PREDICATE: _73 ge_expr 2
-
-       switch (_73) <default: <L32>, case 0: <L26>, case 1: <L27>, case 2:
<L28>, case 3: <L29>, case 4 ... 9: <L28>, case 10 ... 11: <L30>, case 12 ...
17: <L31>>
-
-       BB #19
-       EDGE 14->19 14 [14.3%]  (EXECUTABLE)
-       PREDICATE: _73 le_expr 9
+       PREDICATE: _73 eq_expr 2

@@ -19815,9 +19806,8 @@
   goto <bb 28>;

 <L28>:
-  _792 = ASSERT_EXPR <_794, _794 >= 2>;
-  _793 = ASSERT_EXPR <_792, _792 <= 9>;
-  _77 = _793 + 4294967288;
+  _792 = ASSERT_EXPR <_793, _793 == 2>;
+  _77 = _792 + 4294967288;
   _78 = _77 > 1;
   _79 = (requirement) _78;
   validate_mode (m_780, 2, 0, 1, 1, _79);

that's of course bogus, happens via find_switch_asserts where for correctly
sorted ci vector we fail to pick up CASE_HIGH of cast 4...9.

We miscompile the loop

          /* Skip labels until the last of the group.  */
          do {
            ++idx;
          } while (idx < n && cbb == ci[idx].bb);

to

   0x0000000000b6a492 <+3074>:  mov    %eax,%r14d
   0x0000000000b6a495 <+3077>:  lea    0x1(%r14),%r15d
=> 0x0000000000b6a499 <+3081>:  cmp    %r15,%rcx
   0x0000000000b6a49c <+3084>:  mov    %r15,%rax
   0x0000000000b6a49f <+3087>:  ja     0xb6a492
<find_assert_locations_1(basic_block, sbitmap)+3074>

that is, we simply increment idx until it is equal to n and then use
CASE_HIGH of the last case label in the vector which is the default
label (and thus does not have CASE_HIGH nor CASE_LOW).

The following testcase derived from that is miscompiled on trunk at -O2:

extern void abort (void);

struct X { void *p; int res; } a[32];

int foo (unsigned i, unsigned n, void *q)
{
  if (i + 1 < n && q == a[i + 1].p)
    {
      do {
          ++i;
      } while (i < n && q == a[i].p);
      --i;
      return a[i].res;
    }
}

int main ()
{
  int x;
  a[0].p = &x;
  a[1].p = &x;
  a[1].res = 1;
  a[2].p = (void *)0;
  a[2].res = 0;
  if (foo (0, 3, &x) != 1)
    abort ();
  return 0;
}

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

--- Comment #24 from Richard Biener <rguenth at gcc dot gnu.org> ---
w/o missing return:

extern void abort (void);

struct X { void *p; int res; } a[32];

int foo (unsigned i, unsigned n, void *q)
{
  if (i + 1 < n && q == a[i + 1].p)
    {
      do {
          ++i;
      } while (i < n && q == a[i].p);
      --i;
      return a[i].res;
    }
  else
    return a[i].res;
}

int main ()
{
  int x;
  a[0].p = &x;
  a[0].res = -1;
  a[1].p = &x;
  a[1].res = 1;
  a[2].p = (void *)0;
  a[2].res = 0;
  if (foo (0, 3, &x) != 1)
    abort ();
  return 0;
}

passes when disabling both DOM passes.

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

--- Comment #25 from Richard Biener <rguenth at gcc dot gnu.org> ---
Hmm, reverting the record_equality change that is supposed to fix the unrelated
testsuite fallout fixes the testcase ...

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

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

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

--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> ---
DOM first rotates the loop by threading the entry over the first part of
the conditional, producing

 if (i + 1 < n && q == a[i + 1].p)
   {
     ++i;
     do
       {
         if (q != a[i].p)
           break;
         ++i;
         if (i >= n)
           break;
       }
     while (1);

the 2nd DOM pass then tries to complete the rotate but manages to record
two threadings that are incompatible:

  Threaded jump 6 --> 12 to 13
Jump threading proved probability of edge 12->4 too small (it is 5114, should
be 10000).
  Threaded jump 7 --> 12 to 14

the 2nd one over the loop entry would be ok, completing the rotate.  But
the first one is odd - and I can't see why we register it:

Optimizing block #6

1>>> COND 1 = n_4(D) ge_expr i_12
1>>> COND 1 = n_4(D) ne_expr i_12
1>>> COND 1 = n_4(D) gt_expr i_12
1>>> COND 0 = n_4(D) le_expr i_12
Optimizing statement pretmp_11 = a[i_12].p;
LKUP STMT pretmp_11 = a[i_12].p
          pretmp_11 = a[i_12].p;
2>>> STMT pretmp_11 = a[i_12].p
          pretmp_11 = a[i_12].p;
  Registering jump thread: (6, 12) incoming edge;  (12, 4) normal;
<<<< STMT pretmp_11 = a[i_12].p
          pretmp_11 = a[i_12].p;
<<<< COND 0 = n_4(D) le_expr i_12
<<<< COND 1 = n_4(D) gt_expr i_12
<<<< COND 1 = n_4(D) ne_expr i_12
<<<< COND 1 = n_4(D) ge_expr i_12

bb6 is just

<bb 6>:
pretmp_11 = a[i_12].p;

and its single predecessor

<bb 4>:
i_12 = i_9 + 1;
if (n_4(D) > i_12)
  goto <bb 6>;
else
  goto <bb 5>;

with the record_equality change we now record q_8(D) == prephitmp_16
instead of the other way around:

Optimizing block #4

0>>> COPY q_8(D) = prephitmp_16
1>>> COND 1 = q_8(D) le_expr prephitmp_16
1>>> COND 1 = q_8(D) ge_expr prephitmp_16
1>>> COND 1 = q_8(D) eq_expr prephitmp_16
1>>> COND 0 = q_8(D) ne_expr prephitmp_16

but when threading over the backedge this doesn't get invalidated.

So this canonicalization happens to be a correctness issue (by accident?
Jeff?)

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

--- Comment #28 from Richard Biener <rguenth at gcc dot gnu.org> ---
Author: rguenth
Date: Mon Jul 14 10:50:46 2014
New Revision: 212513

URL: https://gcc.gnu.org/viewcvs?rev=212513&root=gcc&view=rev
Log:
2014-07-14  Richard Biener  <rguenther@suse.de>

    PR tree-optimization/61757
    PR tree-optimization/61783
    PR tree-optimization/61787
    * tree-ssa-dom.c (record_equality): Revert canonicalization
    change and add comment.
    (propagate_rhs_into_lhs): Revert previous fix, removing
    loop depth restriction again.

    * gcc.dg/torture/pr61757.c: New testcase.
    * gcc.dg/torture/pr61787.c: Likewise.

Added:
    trunk/gcc/testsuite/gcc.dg/torture/pr61757.c
    trunk/gcc/testsuite/gcc.dg/torture/pr61787.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-dom.c

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[rguenth at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

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

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

--- Comment #27 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed. (IMHO latent jump threading bug still present)

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[pthaugen at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

--- Comment #29 from Pat Haugen <pthaugen at gcc dot gnu.org> ---
(In reply to Segher Boessenkool from comment #21)
> (In reply to Pat Haugen from comment #19)
> > So in the case where MIN_INT32 is passed (sign extended), the upper 32 bits
> > are '1' so r212352 returns a value of 63 whereas prior revisions returned a
> > value of 31.
> 
> When called with r3=ffffffff80000000 the new code
> returns -1 as far as I can see?

The new code is doing a logical shift right of the full 64-bit reg, which will
require 63 shifts for the value in the reg to become zero.


> And it should be called with 0000000080000000 instead;
> does the caller not have a prototype in scope?

No, there is no prototype, which is really the problem because it should be
passed zero-extended as you say in which case either of the code sequences
would work.

I tried the benchmark after the patch went in, and it is back to generating the
rldicl insn and the benchmark passes.

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

--- Comment #32 from Jeffrey A. Law <law at redhat dot com> ---
No, we don't have that information available in any reasonable form.  That's
one of the things I need to investigate.

One of the possibilities is to flip things on their side a bit.  The old code
started recording equivalences it might need to invalidate when it traversed
the backedge.  Part of the problem with that scheme is some of the equivalences
were already recorded by tree-ssa-dom.c, independent of the threading bits.  We
didn't have a way to find or invalidate those equivalences.

One of the things I want to look at is whether or not we can start recording
when we process a PHI with arguments that are the targets of backedges.  I
haven't prototyped any code around that and I'm not sure if we'll have a
reasonable separation between DOM and the threading code, but that's the first
thing I want to look at once I deal with Teresa's changes.

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[rguenther at suse dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

--- Comment #33 from rguenther at suse dot de <rguenther at suse dot de> ---
On Mon, 14 Jul 2014, law at redhat dot com wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757
> 
> --- Comment #32 from Jeffrey A. Law <law at redhat dot com> ---
> No, we don't have that information available in any reasonable form.  That's
> one of the things I need to investigate.

At least during the DOM walk we record the undo stack, so when visiting
a backedge we'd need to unwind up to the target block (or record
that unwind info in some other place to be usable in the threading code).

That also sounds cheaper than the quadratic complexity invalidation
done as noted in PR61515.

> One of the possibilities is to flip things on their side a bit.  The old code
> started recording equivalences it might need to invalidate when it traversed
> the backedge.  Part of the problem with that scheme is some of the equivalences
> were already recorded by tree-ssa-dom.c, independent of the threading bits.  We
> didn't have a way to find or invalidate those equivalences.

See above - those are the easy bits I think...  I know nothing of those
recorded at threading time (I've not dug into that code many times).

[Bug tree-optimization/61757] [4.10 Regression] genmodes failure with enable-checking

[law at redhat dot com]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61757

--- Comment #34 from Jeffrey A. Law <law at redhat dot com> ---
Whee, fun, finally getting a chance to investigate this BZ.  Namely why does
canonicalization of equivalences in DOM effect correctness of jump threading.

BB12 is what's interesting here.  It's the head of the loop.  It has two
predecessors.  BB7 which is outside the loop and BB6 which is inside the loop. 
BB7->BB12 is the loop entry and BB6->BB12 is the latch edge, naturally.

# i_9 = PHI <_3(7), i_12(6)>
# prephitmp_16 = PHI <q_8(D)(7), pretmp_11(6)>
i_17 = i_9 + 4294967295;
if (q_8(D) == prephitmp_16)
  goto <bb 4>;
else
  goto <bb 8>;

When DOM enters BB12 (via BB7) it does not record anything from the PHI since
the block has multiple predecessors and the PHI is not a degenerate (ie, the
PHI doesn't generate an equivalence that holds every time BB12 executes).  When
DOM gets to the conditional, it'll record that on the true edge that _8 and _16
are equivalent.

It's important to realize that _16 is clearly defined in the loop and that _8
comes from outside the loop (it's actually a default definition).

Eventually DOM "traverses" that true edge and we call record_equivalence (which
has the loop depth canonicalization).  It can record either _8 = _16 or _16 =
_8 (OK, I guess it could record both).  Without canonicalization we can end up
with _8 = 16, ie, an object from outside the loop is defined as equivalent to
an object inside the loop.

That is bad because when we traverse the loop back edge during threading,
objects in the loop can change their values and must trigger invalidations.

Invalidation of equivalences the threader is designed on the assumption that
nothing outside the loop is ever equivalent to something inside the loop.  In
effect we assume that all we need to do is either record a new equivalence or
invalidate equivalences on every SSA_NAME assigned in the loop as we process
the assignment.

If we have to handle cases where something outside the loop is recorded as
equivalent to something inside the loop, then we'd do to an invalidate for
every ssa name in the loop, then record any newly discovered equivalences.

I tried real hard to avoid that because of the cost of invalidation.  Granted
the cost of invalidation now is dramatically smaller, I'd still prefer not to
have to do so many invalidations.

Given that I want to look at ripping all the backedge stuff out in favor of the
on-demand backwards walk approach we're doing for FSMs, I think our best bet is
to leave things as-is for gcc-5.

The comment in the code references back to this BZ, so I don't think we need to
update the comment further.