Bug 48822 - [4.5 Regression] G++ gets stucks and never finishes compilation when enabling -O2/3 optimization options.
Summary: [4.5 Regression] G++ gets stucks and never finishes compilation when enabling...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: tree-optimization (show other bugs)
Version: 4.5.2
: P3 major
Target Milestone: 4.5.4
Assignee: Richard Biener
URL:
Keywords:
: 48921 (view as bug list)
Depends on:
Blocks:
 
Reported: 2011-04-29 13:43 UTC by qball
Modified: 2011-07-04 14:24 UTC (History)
2 users (show)

See Also:
Host:
Target:
Build:
Known to work: 4.4.5, 4.6.1, 4.7.0
Known to fail: 4.5.3, 4.6.0
Last reconfirmed: 2011-04-29 13:58:16


Attachments
Test case triggering the bug. (673 bytes, text/plain)
2011-04-29 13:44 UTC, qball
Details

Note You need to log in before you can comment on or make changes to this bug.
Description qball 2011-04-29 13:43:01 UTC
Trying to compile the example below with g++ -O3 or -O2 it gets stuck in an endless loop.

Error seems to occur in optimizing the (a == CFraction(0,0));
It only occurs when it is CFraction(0,0).  It seems to break in the '==' implementation  on the lowestTerm() (line 69) on the CFraction(0,0);


running on a 64bit machine. (ubuntu natty)

gcc -v:
Using built-in specs.
COLLECT_GCC=g++
COLLECT_LTO_WRAPPER=/usr/lib/x86_64-linux-gnu/gcc/x86_64-linux-gnu/4.5.2/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro 4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs --enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr --program-suffix=-4.5 --enable-shared --enable-multiarch --with-multiarch-defaults=x86_64-linux-gnu --enable-linker-build-id --with-system-zlib --libexecdir=/usr/lib/x86_64-linux-gnu --without-included-gettext --enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/x86_64-linux-gnu --enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug --enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default --with-plugin-ld=ld.gold --enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic --enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-linux-gnu
Thread model: posix
gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) 

(4.4.5 works fine)
Comment 1 qball 2011-04-29 13:44:26 UTC
Created attachment 24146 [details]
Test case triggering the bug.
Comment 2 Richard Biener 2011-04-29 13:58:16 UTC
Confirmed.  It's stuck in SCCVN/FRE visiting

g_37 = PHI <g_36(12), g_38(13)>
g_38 = PHI <g_35(12), g_39(13)>
g_39 = g_37 % g_38;

Value numbering g_37 stmt = g_37 = PHI <g_36(12), g_38(13)>
Setting value number of g_37 to g_37 (changed)
Value numbering g_38 stmt = g_38 = PHI <g_35(12), g_39(13)>
Setting value number of g_38 to 0 (changed)
Value numbering g_39 stmt = g_39 = g_37 % g_38;
Setting value number of g_39 to g_39 (changed)
Value numbering g_37 stmt = g_37 = PHI <g_36(12), g_38(13)>
Setting value number of g_37 to 0 (changed)
Value numbering g_38 stmt = g_38 = PHI <g_35(12), g_39(13)>
Setting value number of g_38 to g_38 (changed)
Value numbering g_39 stmt = g_39 = g_37 % g_38;
RHS g_37 % g_38 simplified to 0 has constants 1
Setting value number of g_39 to 0 (changed)

thus it oscillates.

Maybe latent everywhere else.

Workaround: -fno-tree-fre -fno-tree-pre
Comment 3 qball 2011-04-29 14:04:48 UTC
Doing -O1  -finline-small-functions breaks it aswell.

Indeed adding -fno-tree-fre fixes compilation.

Thanks.
Comment 4 Richard Biener 2011-04-29 14:06:24 UTC
  D.23284.num = 0;
  D.23284.den = 0;
...
<bb 11>:
  D.23599_34 = D.23284.den;
  if (D.23599_34 == 0)
    goto <bb 21> (<L10>);
  else
    goto <bb 12>;

<bb 12>:
  g_35 = D.23284.den;
  g_36 = D.23284.num;
  goto <bb 14>;

<bb 13>:
  g_39 = g_37 % g_38;

<bb 14>:
  # g_37 = PHI <g_36(12), g_38(13)>
  # g_38 = PHI <g_35(12), g_39(13)>
  if (g_38 != 0)
    goto <bb 13>;

and D.23599_34, g_35 and g_36 are correctly value-numbered to zero.  We then
start

Value numbering g_37 stmt = g_37 = PHI <g_36(12), g_38(13)>
Setting value number of g_37 to 0 (changed)
Value numbering g_38 stmt = g_38 = PHI <g_35(12), g_39(13)>
Setting value number of g_38 to 0 (changed)
Value numbering g_39 stmt = g_39 = g_37 % g_38;
Setting value number of g_39 to g_39 (changed)

g_39 has undefined result, thus

Value numbering g_37 stmt = g_37 = PHI <g_36(12), g_38(13)>
Setting value number of g_37 to 0
Value numbering g_38 stmt = g_38 = PHI <g_35(12), g_39(13)>
Setting value number of g_38 to g_38 (changed)
Value numbering g_39 stmt = g_39 = g_37 % g_38;
RHS g_37 % g_38 simplified to 0 has constants 1

where here is the bug that we go from VARYING to CONSTANT for g_39.

ISTR changing VN to never do that but that had lots of weird fallout.

I'm sure the issue is latent.
Comment 5 Richard Biener 2011-05-02 11:39:58 UTC
Testcase that breaks since 4.5:

void foo (int *, int *);
int bar ()
{
  int a = 0;
  int b = 0;
  if (b != 0)
    {
      int ax = a;
      int bx = b;
      while (bx != 0)
        {
          int tem = ax % bx;
          ax = bx;
          bx = tem;
        }
    }
  foo (&a, &b);
}

4.4 has different PHI ordering and does

Value numbering bx_2 stmt = bx_2 = PHI <bx_5(3), tem_6(4)>
Setting value number of bx_2 to 0 (changed)
Value numbering ax_1 stmt = ax_1 = PHI <ax_4(3), bx_2(4)>
Setting value number of ax_1 to 0 (changed)
Value numbering tem_6 stmt = tem_6 = ax_1 % bx_2;
Setting value number of tem_6 to tem_6 (changed)
Value numbering bx_2 stmt = bx_2 = PHI <bx_5(3), tem_6(4)>
Setting value number of bx_2 to bx_2 (changed)
Value numbering ax_1 stmt = ax_1 = PHI <ax_4(3), bx_2(4)>
Setting value number of ax_1 to ax_1 (changed)

to avoid the issue.
Comment 6 Richard Biener 2011-05-02 13:11:30 UTC
Author: rguenth
Date: Mon May  2 13:11:27 2011
New Revision: 173250

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173250
Log:
2011-05-02  Richard Guenther  <rguenther@suse.de>

	PR tree-optimization/48822
	* tree-ssa-sccvn.c (set_ssa_val_to): Never go up the lattice.
	(process_scc): Indicate which iteration we start.

	* gcc.dg/torture/pr48822.c: New testcase.

Added:
    trunk/gcc/testsuite/gcc.dg/torture/pr48822.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/tree-ssa-sccvn.c
Comment 7 Richard Biener 2011-05-02 13:11:53 UTC
Fixed on trunk sofar.
Comment 8 Richard Biener 2011-05-12 14:08:05 UTC
Author: rguenth
Date: Thu May 12 14:08:00 2011
New Revision: 173705

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=173705
Log:
2011-05-12  Richard Guenther  <rguenther@suse.de>

        Backport from mainline
        2011-05-02  Richard Guenther  <rguenther@suse.de>

	PR tree-optimization/48822
	* tree-ssa-sccvn.c (set_ssa_val_to): Never go up the lattice.
	(process_scc): Indicate which iteration we start.

	* gcc.dg/torture/pr48822.c: New testcase.

Added:
    branches/gcc-4_6-branch/gcc/testsuite/gcc.dg/torture/pr48822.c
Modified:
    branches/gcc-4_6-branch/gcc/ChangeLog
    branches/gcc-4_6-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_6-branch/gcc/tree-ssa-sccvn.c
Comment 9 Richard Biener 2011-05-12 14:08:22 UTC
.
Comment 10 Jakub Jelinek 2011-05-19 12:51:25 UTC
*** Bug 48921 has been marked as a duplicate of this bug. ***
Comment 11 Richard Biener 2011-07-04 14:24:13 UTC
Author: rguenth
Date: Mon Jul  4 14:24:10 2011
New Revision: 175813

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=175813
Log:
2011-07-04  Richard Guenther  <rguenther@suse.de>

        Backport from mainline
        2011-05-02  Richard Guenther  <rguenther@suse.de>

	PR tree-optimization/48822
	* tree-ssa-sccvn.c (set_ssa_val_to): Never go up the lattice.

	* gcc.dg/torture/pr48822.c: New testcase.

Added:
    branches/gcc-4_5-branch/gcc/testsuite/gcc.dg/torture/pr48822.c
Modified:
    branches/gcc-4_5-branch/gcc/ChangeLog
    branches/gcc-4_5-branch/gcc/testsuite/ChangeLog
    branches/gcc-4_5-branch/gcc/tree-ssa-sccvn.c
Comment 12 Richard Biener 2011-07-04 14:24:31 UTC
Fixed.