[Bug middle-end/37243] New: [4.4 Regression] Revision 139590 caused many regressions

[Bug middle-end/37243] New: [4.4 Regression] Revision 139590 caused many regressions

[hjl dot tools at gmail dot com]

+FAIL: 21_strings/basic_string/numeric_conversions/char/stoi.cc execution test
+FAIL: 21_strings/basic_string/numeric_conversions/char/stol.cc execution test
+FAIL: 21_strings/basic_string/numeric_conversions/char/stoul.cc execution test
On Linux/x86-64, revision 139590 caused the following regressions:

+FAIL: g++.old-deja/g++.eh/ia64-1.C execution test
+FAIL: g++.old-deja/g++.eh/rethrow6.C execution test
+FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 2
+FAIL: gcc.target/i386/pr36222-1.c scan-assembler-not movdqa
+FAIL: gcc.target/i386/pr36222-1.c scan-assembler-not movdqa
+FAIL: gcc.target/i386/pr36246.c scan-assembler-not movq
+FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer  execution test
+FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
+FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test

with

# make check RUNTESTFLAGS="--target_board 'unix{-m32,}'"


-- 
           Summary: [4.4 Regression] Revision 139590 caused many regressions
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: hjl dot tools at gmail dot com


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

[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions

[hjl dot tools at gmail dot com]

------- Comment #1 from hjl dot tools at gmail dot com  2008-08-26 15:07 -------
Those are Linux/ia32 only regressions:

+FAIL: 21_strings/basic_string/numeric_conversions/char/stoi.cc execution test
+FAIL: 21_strings/basic_string/numeric_conversions/char/stol.cc execution test
+FAIL: 21_strings/basic_string/numeric_conversions/char/stoul.cc execution test
+FAIL: g++.old-deja/g++.eh/ia64-1.C execution test
+FAIL: gcc.target/i386/pr36222-1.c scan-assembler-not movdqa
+FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer  execution test
+FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
+FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test


-- 


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

[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions

[rguenth at gcc dot gnu dot org]

-- 

rguenth at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.4.0


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

[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions

[hjl dot tools at gmail dot com]

------- Comment #2 from hjl dot tools at gmail dot com  2008-08-26 18:22 -------
These are regressions on Linux/ia64:

+FAIL: g++.dg/opt/eh3.C execution test
+FAIL: gfortran.dg/list_read_8.f90  -O0  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O1  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O2  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O3 -fomit-frame-pointer  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
+FAIL: gfortran.dg/list_read_8.f90  -O3 -g  execution test
+FAIL: gfortran.dg/list_read_8.f90  -Os  execution test


-- 


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

[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions

[hjl dot tools at gmail dot com]

------- Comment #3 from hjl dot tools at gmail dot com  2008-08-26 20:03 -------
On Linux/ia32, it also miscompiled 416.gamess in SPEC CPU 2006.
with -O2 -msse2 -mfpmath=sse -ffast-math.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |Joey dot ye at intel dot
                   |                            |com, weiliang dot lin at
                   |                            |intel dot com, xuepeng dot
                   |                            |guo at intel dot com


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

[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions

[hjl dot tools at gmail dot com]

------- Comment #4 from hjl dot tools at gmail dot com  2008-08-26 20:09 -------
We got

  Running 416.gamess ref base lnx32-gcc default

416.gamess: copy #0 non-zero return code (rc=0, signal=11)


416.gamess: copy #0 non-zero return code (rc=0, signal=11)


416.gamess: copy #0 non-zero return code (rc=0, signal=11)

We will try to find a small testcase.


-- 


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

[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pinskia at gcc dot gnu dot
                   |                            |org
           Severity|normal                      |blocker


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

[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions

[hjl dot tools at gmail dot com]

------- Comment #5 from hjl dot tools at gmail dot com  2008-08-26 22:24 -------
Linux/x86-64 only regressions are

+FAIL: g++.old-deja/g++.eh/rethrow6.C execution test
+FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 2
+FAIL: gcc.target/i386/pr36222-1.c scan-assembler-not movdqa
+FAIL: gcc.target/i386/pr36246.c scan-assembler-not movq


-- 


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

[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions

[hjl dot tools at gmail dot com]

------- Comment #6 from hjl dot tools at gmail dot com  2008-08-27 00:05 -------
On Linux/Intel64, I got

  Running 434.zeusmp ref base lnx32e-gcc default

434.zeusmp: copy #0 non-zero return code (rc=0, signal=11)

with -O2 -ffast-math.


-- 


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

[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions

[Joey dot ye at intel dot com]

------- Comment #7 from Joey dot ye at intel dot com  2008-08-27 08:07 -------
Created an attachment (id=16155)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16155&action=view)
Test case from 2006.434.zeusmp

Though fail to extract a smaller case, hopeful it helpful.

Compile with gfortran -c -O2 -DSPEC_CPU_LP64 tranx1.f -S -fdump-rtl-all -g.
Miscompile in revision 139590.

In IRA dump file, I believe following suspicious RTL is the cause of segfault:
(insn 886 885 893 35 tranx1.f:570 (set (reg:DI 0 ax [orig:123 D.3215 ] [123])
        (mem/c:DI (plus:DI (reg/f:DI 7 sp)
                (const_int -104 [0xffffffffffffff98])) [68 D.3215+0 S8 A64]))
89 {*movdi_1_rex64} (nil))

(insn 893 886 896 35 tranx1.f:570 (set (mem/c:DI (plus:DI (reg/f:DI 7 sp)
                (const_int -104 [0xffffffffffffff98])) [68 ivtmp.160+0 S8 A64])
        (reg/f:DI 3 bx [orig:159 ivtmp.160 ] [159])) 89 {*movdi_1_rex64} (nil))
D.3215 and ivtmp.160 shares the spill space (%rsp-104), where as D.3215 and
ivtmp.160 has overlapped liverange.


-- 


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

[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions

[Joey dot ye at intel dot com]

------- Comment #8 from Joey dot ye at intel dot com  2008-08-27 08:11 -------
GDB output:
(gdb)  b tranx1_
Breakpoint 1 at 0x43a670
(gdb)  r

Breakpoint 1, 0x000000000043a670 in tranx1_ ()
(gdb)  b *0x43accd
Breakpoint 2 at 0x43accd
(gdb)  b *0x43acf4
Breakpoint 3 at 0x43acf4
(gdb)  b *0x43ad2f
Breakpoint 4 at 0x43ad2f
(gdb)  c

Breakpoint 2, 0x000000000043accd in tranx1_ ()
(gdb)  x 0x43accd
0x43accd <tranx1_+1629>:        mov    0xffffffffffffff98(%rsp),%rcx
(gdb)  c

Breakpoint 3, 0x000000000043acf4 in tranx1_ ()
(gdb)  x 0x43acf4
0x43acf4 <tranx1_+1668>:        lea    0x160603e8(,%rcx,8),%rbx
(gdb)  i r rcx
rcx            0x5      5
(gdb)  c

Breakpoint 4, 0x000000000043ad2f in tranx1_ ()
(gdb)  x 0x43ad2f
0x43ad2f <tranx1_+1727>:        mov    %rbx,0xffffffffffffff98(%rsp) 
// RTL #893 Suspicious
(gdb)  i r rbx
rbx            0x16060410       369493008
(gdb)  c

Breakpoint 2, 0x000000000043accd in tranx1_ ()
(gdb)  x 0x43accd
0x43accd <tranx1_+1629>:        mov    0xffffffffffffff98(%rsp),%rcx
(gdb)  c

Breakpoint 3, 0x000000000043acf4 in tranx1_ ()
(gdb)  x 0x43acf4
0x43acf4 <tranx1_+1668>:        lea    0x160603e8(,%rcx,8),%rbx
(gdb)  i r rcx
rcx            0x16060410       369493008
(gdb)  c

Breakpoint 4, 0x000000000043ad2f in tranx1_ ()
(gdb)  x 0x43ad2f
0x43ad2f <tranx1_+1727>:        mov    %rbx,0xffffffffffffff98(%rsp)
(gdb)  i r rbx
rbx            0xc6362468       3325437032
(gdb)  c

Program received signal SIGSEGV, Segmentation fault.
0x000000000043ad65 in tranx1_ ()
(gdb)  x 0x43ad65
0x43ad65 <tranx1_+1781>:        subsd  (%r14),%xmm0
(gdb)  i r r14
r14            0xc6362468       3325437032


-- 


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

[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions

[dominiq at lps dot ens dot fr]

------- Comment #9 from dominiq at lps dot ens dot fr  2008-08-27 13:27 -------
New failures between revision 139588 and 139622 on i686-apple-darwin9

32 and 64 bit modes
< FAIL: g++.old-deja/g++.eh/ia64-1.C execution test
< FAIL: gcc.target/i386/pr36222-1.c scan-assembler-not movdqa
< FAIL: gfortran.dg/function_kinds_5.f90  -O   (test for errors, line 8)


32 bit mode only
< FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer  execution test
< FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
< FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test

64 bit mode only
< FAIL: g++.old-deja/g++.eh/rethrow6.C execution test
< FAIL: 21_strings/basic_string/numeric_conversions/char/stoi.cc execution test
< FAIL: 21_strings/basic_string/numeric_conversions/char/stol.cc execution test
< FAIL: 21_strings/basic_string/numeric_conversions/char/stoul.cc execution
test
< FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/stod.cc execution
test
< FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/stof.cc execution
test
< FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/stoi.cc execution
test
< FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/stol.cc execution
test
< FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/stold.cc execution
test
< FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/stoll.cc execution
test
< FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/stoul.cc execution
test
< FAIL: 21_strings/basic_string/numeric_conversions/wchar_t/stoull.cc execution
test


-- 


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

[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions

[vmakarov at redhat dot com]

------- Comment #10 from vmakarov at redhat dot com  2008-08-27 16:33 -------
IRA degradation on rethrow6.C.

This test fails when compiled with -O0.  The wrong code looks like

bb:
p93<-ax
p96<-dx

where p93 got dx and p96 got ax.  The reason for this is that ax and dx are not
live regs at the start of basic block when -O0 is used and as a consequence p93
does not conflict with dx as it should be.

There are 2 solutions:
  first one is to generate the info for -O0 too
  second one is to prevent assigning hard registers to global pseudos as the
old register allocator does.

The second one is more simple.  It does not increase compiler speed. In fact, I
found the second solution makes compiler 0.5% faster on all_cp2k_fortran.f90
(although such improvement is an error margin).

I'll send the patch for solving rethrow6.C degradation soon.


-- 


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

[Bug middle-end/37243] [4.4 Regression] Revision 139590 caused many regressions

[Joey dot ye at intel dot com]

------- Comment #11 from Joey dot ye at intel dot com  2008-08-28 06:14 -------
(In reply to comment #4)
> We got
>   Running 416.gamess ref base lnx32-gcc default
> 416.gamess: copy #0 non-zero return code (rc=0, signal=11)
> 416.gamess: copy #0 non-zero return code (rc=0, signal=11)
> 416.gamess: copy #0 non-zero return code (rc=0, signal=11)
> We will try to find a small testcase.
Small case available:
$ cat case.f
      SUBROUTINE SCHMD(V,M,N,LDV)
      IMPLICIT DOUBLE PRECISION(A-H,O-Z)
      LOGICAL GOPARR,DSKWRK,MASWRK
      DIMENSION V(LDV,N)
      COMMON /IOFILE/ IR,IW,IP,IS,IPK,IDAF,NAV,IODA(400)
      COMMON /PAR   / ME,MASTER,NPROC,IBTYP,IPTIM,GOPARR,DSKWRK,MASWRK
      PARAMETER (ZERO=0.0D+00, ONE=1.0D+00, TOL=1.0D-10)
      IF (M .EQ. 0) GO TO 180
      DO 160 I = 1,M
      DUMI = ZERO
      DO 100 K = 1,N
  100 DUMI = DUMI+V(K,I)*V(K,I)
      DUMI = ONE/ SQRT(DUMI)
      DO 120 K = 1,N
  120 V(K,I) = V(K,I)*DUMI
      IF (I .EQ. M) GO TO 160
      I1 = I+1
      DO 140 J = I1,M
      DUM = -DDOT(N,V(1,J),1,V(1,I),1)
      CALL DAXPY(N,DUM,V(1,I),1,V(1,J),1)
  140 CONTINUE
  160 CONTINUE
      IF (M .EQ. N) RETURN
  180 CONTINUE
      I = M
      J = 0
  200 I0 = I
      I = I+1
      IF (I .GT. N) RETURN
  220 J = J+1
      IF (J .GT. N) GO TO 320
      DO 240 K = 1,N
  240 V(K,I) = ZERO
      CALL DAXPY(N,DUM,V(1,II),1,V(1,I),1)
  260 CONTINUE
      DUMI = ZERO
      DO 280 K = 1,N
  280 DUMI = DUMI+V(K,I)*V(K,I)
      IF ( ABS(DUMI) .LT. TOL) GO TO 220
      DO 300 K = 1,N
  300 V(K,I) = V(K,I)*DUMI
      GO TO 200
  320 END
      program main
      DOUBLE PRECISION V
      DIMENSION V(18, 18)
      common // v

      call schmd(V, 1, 18, 18)
      end

      subroutine DAXPY
      end

      FUNCTION DDOT ()
      DOUBLE PRECISION DDOT
      DDOT = 1
      end

$ gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../src/configure --disable-bootstrap
--enable-languages=c,c++,fortran --enable-checking=assert
Thread model: posix
gcc version 4.4.0 20080826 (experimental) [trunk revision 139590] (GCC) 
$ gfortran -O2 -o case.exe case.f -m32
$ ./case.exe
Segmentation fault

$ gfortran -v
Using built-in specs.
Target: x86_64-unknown-linux-gnu
Configured with: ../src/configure --disable-bootstrap
--enable-languages=c,c++,fortran --enable-checking=assert
Thread model: posix
gcc version 4.4.0 20080826 (experimental) [trunk revision 139589] (GCC) 
$ gfortran -O2 -o case.exe case.f -m32
$ ./case.exe
$


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[pinskia at gcc dot gnu dot org]

-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2008-08-29 04:37:57
               date|                            |
            Summary|[4.4 Regression] Revision   |[4.4 Regression] IRA causes
                   |139590 caused many          |wrong code generation
                   |regressions                 |


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[vmakarov at redhat dot com]

------- Comment #12 from vmakarov at redhat dot com  2008-08-29 15:55 -------
Here is the analysis of regressions on pr36222 and pr36246.  PR36222 contains
the following code:
p64:V4SI=vec_concat (p66:V2SI, p65:V2SI) dead p66 and p65
xmm0:V2DI=subreg:V2DI (p64:V4SI)

IRA allocates p65, p66, and p64 in this order.  p65 gets xmm0, p66 gets xmm1,
and p64 gets xmm0.  Reload generates additional move insn because p66 and p64
should be the same operand according to the 1st insn constraints.

IRA uses copies to propagate preferences.  p66 and pc64, p66 and p64 connected
by copies with same frequencies as dying pseudos.  IRA did not create copy
connecting p66 and p64 as operands should be in the same register according to
the insn constraints because IRA does not create copies for allocnos with
different modes.

Preference of xmm0 was not propagated to p64 because IRA does not create copies
for subregs.

Another pitfall of IRA, it propagates preferences only from allocnos *directly*
connected by copies.

The patch solving the problem will be sent soon.


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[vmakarov at gcc dot gnu dot org]

------- Comment #13 from vmakarov at gcc dot gnu dot org  2008-08-29 16:18 -------
Subject: Bug 37243

Author: vmakarov
Date: Fri Aug 29 16:16:45 2008
New Revision: 139769

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139769
Log:
2008-08-29  Vladimir Makarov  <vmakarov@redhat.com>

        PR rtl-opt/37243
        * ira-color (ira_fast_allocation): Don't assign hard registers to
        global allocnos.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ira-color.c


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[hjl dot tools at gmail dot com]

------- Comment #14 from hjl dot tools at gmail dot com  2008-08-29 18:24 -------
I suspect this patch

http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01903.html

is incorrect. Back it out from IRA branch fixed the testcase
in comment #11. I am running SPEC CPU 2000/2006 with IRA
branch using revision 139581 and revision 139582 on Linux/ia32
and Linux/Intel64. It will tell us if revision 139582 is bad.


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[pinskia at gcc dot gnu dot org]

------- Comment #15 from pinskia at gcc dot gnu dot org  2008-08-29 19:46 -------
(In reply to comment #14)
> I suspect this patch
> 
> http://gcc.gnu.org/ml/gcc-patches/2008-08/msg01903.html
> 

That patch enabled IRA by default, before it was only enabled via the -fira
flag.  So please test before that patch with -fira and get back to us about
which patch really caused the regressions ....


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[vmakarov at redhat dot com]

------- Comment #16 from vmakarov at redhat dot com  2008-08-30 18:52 -------
This is an analysis of the SPEC2006 degradation.

First of all of thanks for reducing the test.  I really appreciate
this.  Finding it in spec20006 would be very time consuming for me.

The problem looks following
  1. pseudo 80 in the 1st loop gets hard register #2,
     pseudo 153 in the same loop gets hard register #5.
  2. Reload spills pseudo 80 and than assigns it to hard register #5
     through IRA.  Although p80 and p153 in the 1st loop really conflict.

It happens because of wrong flattening regional IR into plain IR done
for reload.  IR flattening is wrong because ira-emit.c (see end of
function ira-emit.c::change_loop) does not rename disjoint live ranges
of p153 in the 1st loop and in another top-level loop.  Again it
happens because p153 in the 1st loop is not in bitmap
mentioned_allocnos.  p153 is not mentioned in the 1st loop (only in
its subloops) but lives through BBs of the 1st loop.

The patch solving the problem will be sent soon.


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[hjl at gcc dot gnu dot org]

------- Comment #17 from hjl at gcc dot gnu dot org  2008-09-02 18:17 -------
Subject: Bug 37243

Author: hjl
Date: Tue Sep  2 18:16:24 2008
New Revision: 139900

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139900
Log:
2008-09-02  H.J. Lu  <hongjiu.lu@intel.com>

        Backport from mainline:
        2008-09-01  John David Anglin  <dave.anglin@nrc-cnrc.gc.ca>

        * ira.c (setup_eliminable_regset): Only declare i if ELIMINABLE_REGS is
        defined.

        2008-08-29  Vladimir Makarov  <vmakarov@redhat.com>

        PR rtl-opt/37251
        * ira-color.c (push_allocnos_to_stack): Truncate
        removed_splay_allocno_vec.

        2008-08-29  Vladimir Makarov  <vmakarov@redhat.com>

        PR rtl-opt/37243
        * ira-color (ira_fast_allocation): Don't assign hard registers to
        global allocnos.

Added:
    branches/ira-merge/gcc/ChangeLog.ira
Modified:
    branches/ira-merge/gcc/ira-color.c
    branches/ira-merge/gcc/ira.c


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[hjl at gcc dot gnu dot org]

------- Comment #18 from hjl at gcc dot gnu dot org  2008-09-02 18:24 -------
Subject: Bug 37243

Author: hjl
Date: Tue Sep  2 18:22:59 2008
New Revision: 139901

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139901
Log:
2008-09-02  Vladimir Makarov  <vmakarov@redhat.com>

        PR rtl-opt/37243
        * ira-conflicts.c (REG_SUBREG_P, go_through_subreg): New.
        (process_regs_for_copy): Process subregs.  Refine check when cost
        is taken into account in ira-costs.c.
        (process_reg_shuffles): Use REG_SUBREG_P.
        (add_insn_allocno_copies): Ditto.  Ignore modes.

        * ira-color.c (conflict_allocno_vec): New.
        (COST_HOP_DIVISOR): New macro.
        (update_copy_costs_1): Use it.
        (update_conflict_hard_regno_costs): New function.
        (assign_hard_reg): Use it.
        (ira_color): Allocate and free conflict_allocno_vec.

Modified:
    branches/ira-merge/gcc/ChangeLog.ira
    branches/ira-merge/gcc/ira-color.c
    branches/ira-merge/gcc/ira-conflicts.c


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[hjl at gcc dot gnu dot org]

------- Comment #19 from hjl at gcc dot gnu dot org  2008-09-02 18:28 -------
Subject: Bug 37243

Author: hjl
Date: Tue Sep  2 18:27:34 2008
New Revision: 139902

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139902
Log:
2008-09-02  Vladimir Makarov  <vmakarov@redhat.com>

        PR rtl-opt/37243
        * ira-int.h (ira_loop_tree_node): Rename mentioned_allocnos to
        all_allocnos.

        * ira-color.c (print_loop_title): Use all_allocnos.
        (color_pass): Ditto.  Don't add border_allocnos.  Check that
        subloop allocno in the correspdoning bitmap all_allocnos.

        * ira-emit.c (change_loop): Use all_allocnos.

        * ira-build.c (create_loop_tree_nodes, finish_loop_tree_node):
        Ditto.
        (ira_create_allocno): Set up all_allocnos bit for the created
        allocno.
        (create_cap_allocno): Remove setting mentioned_allocnos.
        (create_insn_allocnos): Ditto.
        (remove_unnecessary_allocnos): Use all_allocnos.
        (check_allocno_creation): Check that allocnos are in the
        corresponding bitmap all_allocnos.

Modified:
    branches/ira-merge/gcc/ChangeLog.ira
    branches/ira-merge/gcc/ira-build.c
    branches/ira-merge/gcc/ira-color.c
    branches/ira-merge/gcc/ira-emit.c
    branches/ira-merge/gcc/ira-int.h


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[hjl dot tools at gmail dot com]

------- Comment #20 from hjl dot tools at gmail dot com  2008-09-02 20:40 -------
On ira-merge branch at revision 139902, Linux/ia32 has regression:

+FAIL: 21_strings/basic_string/numeric_conversions/char/stoi.cc execution test
+FAIL: 21_strings/basic_string/numeric_conversions/char/stol.cc execution test
+FAIL: 21_strings/basic_string/numeric_conversions/char/stoul.cc execution test
+FAIL: g++.old-deja/g++.eh/ia64-1.C execution test
+FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer  execution test
+FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
+FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test

Linux/x86-64 has regressions:

+FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 2

Linux/ia64 has regressions:
+FAIL: g++.dg/opt/eh3.C execution test
+FAIL: gfortran.dg/list_read_8.f90  -O0  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O1  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O2  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O3 -fomit-frame-pointer  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
+FAIL: gfortran.dg/list_read_8.f90  -O3 -g  execution test
+FAIL: gfortran.dg/list_read_8.f90  -Os  execution test


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[hjl dot tools at gmail dot com]

------- Comment #21 from hjl dot tools at gmail dot com  2008-09-02 23:52 -------
On ira-merge branch at revision 139914, Linux/ia32 has regression:

+FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer  execution test
+FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
+FAIL: libgomp.fortran/vla7.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test

Linux/x86-64 has regressions:

+FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 2

Linux/ia64 has regressions:

+FAIL: gfortran.dg/list_read_8.f90  -O0  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O1  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O2  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O3 -fomit-frame-pointer  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
+FAIL: gfortran.dg/list_read_8.f90  -O3 -g  execution test
+FAIL: gfortran.dg/list_read_8.f90  -Os  execution test


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[hjl dot tools at gmail dot com]

------- Comment #22 from hjl dot tools at gmail dot com  2008-09-03 16:05 -------
(In reply to comment #7)
> Created an attachment (id=16155)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=16155&action=view) [edit]
> Test case from 2006.434.zeusmp
> 
> Though fail to extract a smaller case, hopeful it helpful.
> 
> Compile with gfortran -c -O2 -DSPEC_CPU_LP64 tranx1.f -S -fdump-rtl-all -g.
> Miscompile in revision 139590.
> 
> In IRA dump file, I believe following suspicious RTL is the cause of segfault:
> (insn 886 885 893 35 tranx1.f:570 (set (reg:DI 0 ax [orig:123 D.3215 ] [123])
>         (mem/c:DI (plus:DI (reg/f:DI 7 sp)
>                 (const_int -104 [0xffffffffffffff98])) [68 D.3215+0 S8 A64]))
> 89 {*movdi_1_rex64} (nil))
> 
> (insn 893 886 896 35 tranx1.f:570 (set (mem/c:DI (plus:DI (reg/f:DI 7 sp)
>                 (const_int -104 [0xffffffffffffff98])) [68 ivtmp.160+0 S8 A64])
>         (reg/f:DI 3 bx [orig:159 ivtmp.160 ] [159])) 89 {*movdi_1_rex64} (nil))
> D.3215 and ivtmp.160 shares the spill space (%rsp-104), where as D.3215 and
> ivtmp.160 has overlapped liverange.
> 

It is fixed by Richard's use DF patch:

http://gcc.gnu.org/ml/gcc/2008-09/msg00015.html


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[hjl dot tools at gmail dot com]

------- Comment #23 from hjl dot tools at gmail dot com  2008-09-03 19:44 -------
On ira-merge branch at revision 139942, there are no regression
on Linux/ia32.  Linux/x86-64 has regressions:

+FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 2

Linux/ia64 has regressions:

+FAIL: gfortran.dg/list_read_8.f90  -O0  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O1  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O2  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O3 -fomit-frame-pointer  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O3 -fomit-frame-pointer -funroll-all-loops
-finline-functions  execution test
+FAIL: gfortran.dg/list_read_8.f90  -O3 -fomit-frame-pointer -funroll-loops 
execution test
+FAIL: gfortran.dg/list_read_8.f90  -O3 -g  execution test
+FAIL: gfortran.dg/list_read_8.f90  -Os  execution test

ligfortran is miscompiled since the executable runs correctly with
ligfortran from revision 139589.


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[hjl dot tools at gmail dot com]

------- Comment #24 from hjl dot tools at gmail dot com  2008-09-03 20:04 -------
(In reply to comment #23)
> 
> Linux/ia64 has regressions:
> 
> +FAIL: gfortran.dg/list_read_8.f90  -O0  execution test
> +FAIL: gfortran.dg/list_read_8.f90  -O1  execution test
> +FAIL: gfortran.dg/list_read_8.f90  -O2  execution test
> +FAIL: gfortran.dg/list_read_8.f90  -O3 -fomit-frame-pointer  execution test
> +FAIL: gfortran.dg/list_read_8.f90  -O3 -fomit-frame-pointer -funroll-all-loops
> -finline-functions  execution test
> +FAIL: gfortran.dg/list_read_8.f90  -O3 -fomit-frame-pointer -funroll-loops 
> execution test
> +FAIL: gfortran.dg/list_read_8.f90  -O3 -g  execution test
> +FAIL: gfortran.dg/list_read_8.f90  -Os  execution test
> 
> ligfortran is miscompiled since the executable runs correctly with
> ligfortran from revision 139589.
> 

I opened PR 37359 to track it.


-- 

hjl dot tools at gmail dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  BugsThisDependsOn|                            |37359


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[vmakarov at gcc dot gnu dot org]

------- Comment #25 from vmakarov at gcc dot gnu dot org  2008-09-03 20:13 -------
Subject: Bug 37243

Author: vmakarov
Date: Wed Sep  3 20:12:27 2008
New Revision: 139949

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139949
Log:
2008-09-03  Vladimir Makarov  <vmakarov@redhat.com>

        PR rtl-opt/37243

        * ira-conflicts.c (REG_SUBREG_P, go_through_subreg): New.
        (process_regs_for_copy): Process subregs.  Refine check when cost
        is taken into account in ira-costs.c.
        (process_reg_shuffles): Use REG_SUBREG_P.
        (add_insn_allocno_copies): Ditto.  Ignore modes.

        * ira-color.c (conflict_allocno_vec): New.
        (COST_HOP_DIVISOR): New macro.
        (update_copy_costs_1): Use it.
        (update_conflict_hard_regno_costs): New function.
        (assign_hard_reg): Use it.
        (ira_color): Allocate and free conflict_allocno_vec.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ira-color.c
    trunk/gcc/ira-conflicts.c


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[vmakarov at gcc dot gnu dot org]

------- Comment #26 from vmakarov at gcc dot gnu dot org  2008-09-03 20:22 -------
Subject: Bug 37243

Author: vmakarov
Date: Wed Sep  3 20:20:57 2008
New Revision: 139952

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139952
Log:
2008-09-03  Vladimir Makarov  <vmakarov@redhat.com>

        PR rtl-opt/37243

        * ira-int.h (ira_loop_tree_node): Rename mentioned_allocnos to
        all_allocnos.

        * ira-color.c (print_loop_title): Use all_allocnos.
        (color_pass): Ditto.  Don't add border_allocnos.  Check that
        subloop allocno in the correspdoning bitmap all_allocnos.

        * ira-emit.c (change_loop): Use all_allocnos.

        * ira-build.c (create_loop_tree_nodes, finish_loop_tree_node):
        Ditto.
        (ira_create_allocno): Set up all_allocnos bit for the created
        allocno.
        (create_cap_allocno): Remove setting mentioned_allocnos.
        (create_insn_allocnos): Ditto.
        (remove_unnecessary_allocnos): Use all_allocnos.
        (check_allocno_creation): Check that allocnos are in the
        corresponding bitmap all_allocnos.


Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ira-build.c
    trunk/gcc/ira-color.c
    trunk/gcc/ira-emit.c
    trunk/gcc/ira-int.h


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[hjl at gcc dot gnu dot org]

------- Comment #27 from hjl at gcc dot gnu dot org  2008-09-04 05:01 -------
Subject: Bug 37243

Author: hjl
Date: Thu Sep  4 05:00:07 2008
New Revision: 139972

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139972
Log:
2008-09-03  H.J. Lu  <hongjiu.lu@intel.com>

        PR rtl-optimization/37243
        * gfortran.dg/pr37243.f: New.

Added:
    branches/ira-merge/gcc/testsuite/ChangeLog.ira
    branches/ira-merge/gcc/testsuite/gfortran.dg/pr37243.f


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[hjl dot tools at gmail dot com]

------- Comment #28 from hjl dot tools at gmail dot com  2008-09-04 05:45 -------
(In reply to comment #23)
> on Linux/ia32.  Linux/x86-64 has regressions:
> 
> +FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 2
> 

I opened PR 37364 to track it.


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[hjl dot tools at gmail dot com]

------- Comment #29 from hjl dot tools at gmail dot com  2008-09-04 13:34 -------
On ira-merge branch at revision 139972, there are no regression
on Linux/ia32 and Linux/ia64. Linux/x86-64 has regressions:

+FAIL: gcc.target/i386/pr34256.c scan-assembler-times mov 2

It is tracked by PR 37364.


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[hjl at gcc dot gnu dot org]

------- Comment #30 from hjl at gcc dot gnu dot org  2008-09-04 15:47 -------
Subject: Bug 37243

Author: hjl
Date: Thu Sep  4 15:46:05 2008
New Revision: 139987

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139987
Log:
2008-09-04  H.J. Lu  <hongjiu.lu@intel.com>

        PR rtl-optimization/37243
        * gfortran.dg/pr37243.f: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/pr37243.f
Modified:
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[rsandifo at gcc dot gnu dot org]

------- Comment #31 from rsandifo at gcc dot gnu dot org  2008-09-04 18:48 -------
Subject: Bug 37243

Author: rsandifo
Date: Thu Sep  4 18:47:35 2008
New Revision: 139993

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=139993
Log:
gcc/
        PR middle-end/37243
        * ira-build.c (form_loop_tree): Reverse BB walk.
        (create_bb_allocnos): Likewise.
        * ira-lives.c (make_regno_born_and_dead, regs_set): Delete.
        (mark_reg_store): Rename to...
        (mark_ref_live): ...this and take a df_ref argument instead of
        note_stores arguments.  Assert that we have a register.
        (mark_reg_clobber): Delete.
        (def_conflicts_with_inputs_p): New function.
        (mark_reg_conflicts): Delete.
        (mark_reg_death): Rename to...
        (mark_ref_dead): ...this and take a df_ref argument instead of
        a register.  Assert that we have a register.
        (process_bb_node_lives): Hoist frequency calculation out of
        instruction walk.  Convert from a forwards scan to a backwards scan.
        Use DF_REF_USES and DF_REF_DEFS instead of register notes and
        note_stores.  Remove EH_RETURN_DATA_REGNO and regs_set handling.
        (create_allocno_live_ranges): Don't create regs_set.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/ira-build.c
    trunk/gcc/ira-lives.c


-- 


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

[Bug middle-end/37243] [4.4 Regression] IRA causes wrong code generation

[hjl dot tools at gmail dot com]

------- Comment #32 from hjl dot tools at gmail dot com  2008-09-04 21:05 -------
I am closing this bug. We will track PR 37364 separately.


-- 

hjl dot tools at gmail dot com changed:

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


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