[Bug middle-end/46515] New: [4.6 Regression] Many libjava failures

[Bug middle-end/46515] New: [4.6 Regression] Many libjava failures

[hjl.tools at gmail dot com]

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

           Summary: [4.6 Regression] Many libjava failures
           Product: gcc
           Version: 4.6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: middle-end
        AssignedTo: unassigned@gcc.gnu.org
        ReportedBy: hjl.tools@gmail.com


On Linux/x86-64, revision 166834 gave

FAIL: InterfaceDispatch -O3 -findirect-dispatch execution - source compiled
test
FAIL: InterfaceDispatch -findirect-dispatch execution - source compiled test
FAIL: ProxyTest -O3 -findirect-dispatch execution - source compiled test
FAIL: ProxyTest -findirect-dispatch execution - source compiled test
FAIL: TestProxy -O3 -findirect-dispatch execution - source compiled test
FAIL: TestProxy -findirect-dispatch execution - source compiled test
FAIL: anfi -O3 -findirect-dispatch execution - source compiled test
FAIL: anfi -findirect-dispatch execution - source compiled test

Revision 166823 is OK.

[Bug middle-end/46515] [4.6 Regression] Many libjava failures

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.6.0

[Bug middle-end/46515] [4.6 Regression] Many libjava failures

[hjl.tools at gmail dot com]

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

H.J. Lu <hjl.tools at gmail dot com> changed:

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

--- Comment #1 from H.J. Lu <hjl.tools at gmail dot com> 2010-11-17 12:51:20 UTC ---
It is caused by revision 166829:

http://gcc.gnu.org/ml/gcc-cvs/2010-11/msg00718.html

[Bug middle-end/46515] [4.6 Regression] Many libjava failures

[hjl.tools at gmail dot com]

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

--- Comment #2 from H.J. Lu <hjl.tools at gmail dot com> 2010-11-17 12:53:39 UTC ---
Failures look like

spawn [open ...]^M
FAIL: InterfaceDispatch -findirect-dispatch execution - source compiled test
UNTESTED: InterfaceDispatch -findirect-dispatch output - source compiled test

[Bug middle-end/46515] [4.6 Regression] Many libjava failures

[hjl.tools at gmail dot com]

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

--- Comment #3 from H.J. Lu <hjl.tools at gmail dot com> 2010-11-17 12:54:35 UTC ---
It is on Linux/x86-64.

[Bug middle-end/46515] [4.6 Regression] Many libjava failures

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2010.11.18 16:17:40
                 CC|                            |jakub at gcc dot gnu.org
     Ever Confirmed|0                           |1

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-11-18 16:17:40 UTC ---
This seems to be wrong unwind info for
_ZN10_Jv_Linker14wait_for_stateEPN4java4lang5ClassEi,
at least backtrace like:
#24 0x00007ffff5f73df2 in _Jv_Linker::resolve_pool_entry (klass=0x7fffeeb91618,
index=2, lazy=true) at ../../../libjava/link.cc:440
#25 0x00007ffff5f74158 in _Jv_Linker::ensure_class_linked
(klass=0x7fffeeb91618) at ../../../libjava/link.cc:1748
#26 0x00007ffff5f72a20 in _Jv_Linker::wait_for_state (klass=0x7fffeeb91618,
state=9) at ../../../libjava/link.cc:2076
#27 0x00007ffff5f737a8 in _Jv_Linker::get_interfaces (klass=0x7fffeeb91af8,
ifaces=0x7fffffffdbd0) at ../../../libjava/link.cc:777
#28 0x00007ffff5f74357 in _Jv_Linker::prepare_constant_time_tables
(klass=0x7fffeeb91af8) at ../../../libjava/link.cc:716
#29 0x00007ffff5f72b08 in _Jv_Linker::wait_for_state (klass=0x7fffeeb91af8,
state=7) at ../../../libjava/link.cc:2067
#30 0x0000000000000003 in ?? ()
#31 0x00007ffff5f733b6 in _Jv_Linker::link_symbol_table (klass=0x0) at
../../../libjava/link.cc:1308
#32 0x00007ffff5f72a30 in _Jv_Linker::wait_for_state (klass=0x7fffeeb913a8,
state=9) at ../../../libjava/link.cc:2078
#33 0x00007ffff5fa77e3 in java::lang::Class::initializeClass
(this=0x7fffeeb913a8) at ../../../libjava/java/lang/natClass.cc:720
suggests there (note the weird ra 0x00000003 in it).  GDB doesn't crash on it,
but the libgcc unwinder does.

The code difference from yesterday in that routine is:

     193f:      0f 84 79 fe ff ff       je     17be
<_ZN10_Jv_Linker14wait_for_stateEPN4java4lang5ClassEi+0x1e>
     1945:      e8 00 00 00 00          callq  194a
<_ZN10_Jv_Linker14wait_for_stateEPN4java4lang5ClassEi+0x1aa>
                        1946: R_X86_64_PLT32    _Z20_Jv_GetCurrentJNIEnvv-0x4
-    194a:      48 83 c4 08             add    $0x8,%rsp
-    194e:      48 89 d9                mov    %rbx,%rcx
-    1951:      4c 89 ee                mov    %r13,%rsi
-    1954:      5b                      pop    %rbx
-    1955:      5d                      pop    %rbp
-    1956:      41 5c                   pop    %r12
-    1958:      41 5d                   pop    %r13
-    195a:      41 5e                   pop    %r14
-    195c:      41 5f                   pop    %r15
-    195e:      48 89 c2                mov    %rax,%rdx
-    1961:      bf 38 00 00 00          mov    $0x38,%edi
-    1966:      31 c0                   xor    %eax,%eax
-    1968:      e9 00 00 00 00          jmpq   196d
<_ZN10_Jv_Linker14wait_for_stateEPN4java4lang5ClassEi+0x1cd>
-                       1969: R_X86_64_PLT32   
_Z19_Jv_JVMTI_PostEvent10jvmtiEventPN4java4lang6ThreadEz-0x4
-    196d:      0f 1f 00                nopl   (%rax)
+    194a:      41 58                   pop    %r8
+    194c:      48 89 d9                mov    %rbx,%rcx
+    194f:      4c 89 ee                mov    %r13,%rsi
+    1952:      48 89 c2                mov    %rax,%rdx
+    1955:      5b                      pop    %rbx
+    1956:      5d                      pop    %rbp
+    1957:      41 5c                   pop    %r12
+    1959:      41 5d                   pop    %r13
+    195b:      41 5e                   pop    %r14
+    195d:      41 5f                   pop    %r15
+    195f:      bf 38 00 00 00          mov    $0x38,%edi
+    1964:      31 c0                   xor    %eax,%eax
+    1966:      e9 00 00 00 00          jmpq   196b
<_ZN10_Jv_Linker14wait_for_stateEPN4java4lang5ClassEi+0x1cb>
+                       1967: R_X86_64_PLT32   
_Z19_Jv_JVMTI_PostEvent10jvmtiEventPN4java4lang6ThreadEz-0x4
+    196b:      0f 1f 44 00 00          nopl   0x0(%rax,%rax,1)
     1970:      48 89 df                mov    %rbx,%rdi
     1973:      e8 00 00 00 00          callq  1978
<_ZN10_Jv_Linker14wait_for_stateEPN4java4lang5ClassEi+0x1d8>
                        1974: R_X86_64_PLT32   
_ZN10_Jv_Linker28ensure_method_table_completeEPN4java4lang5ClassE-0x4

(i.e. replacement of addq $8, %rsp with popq %r8 and movq %rax, %rdx scheduled
elsewhere).

And unwind info difference is:

   DW_CFA_advance_loc: 4 to 000017d0
   DW_CFA_restore_state
-  DW_CFA_advance_loc2: 382 to 0000194e
-  DW_CFA_remember_state
+  DW_CFA_advance_loc2: 380 to 0000194c
   DW_CFA_def_cfa_offset: 56
-  DW_CFA_advance_loc: 7 to 00001955
+  DW_CFA_advance_loc: 10 to 00001956
+  DW_CFA_remember_state
   DW_CFA_def_cfa_offset: 48
-  DW_CFA_advance_loc: 1 to 00001956
+  DW_CFA_advance_loc: 1 to 00001957
   DW_CFA_def_cfa_offset: 40
-  DW_CFA_advance_loc: 2 to 00001958
+  DW_CFA_advance_loc: 2 to 00001959
   DW_CFA_def_cfa_offset: 32
-  DW_CFA_advance_loc: 2 to 0000195a
+  DW_CFA_advance_loc: 2 to 0000195b
   DW_CFA_def_cfa_offset: 24
-  DW_CFA_advance_loc: 2 to 0000195c
+  DW_CFA_advance_loc: 2 to 0000195d
   DW_CFA_def_cfa_offset: 16
-  DW_CFA_advance_loc: 2 to 0000195e
+  DW_CFA_advance_loc: 2 to 0000195f
   DW_CFA_def_cfa_offset: 8
-  DW_CFA_advance_loc: 18 to 00001970
+  DW_CFA_advance_loc: 17 to 00001970
   DW_CFA_restore_state

Except for the expected DW_CFA_advance_loc changes, the important difference is
that before Richard's patch DW_CFA_remember_state preceeded
DW_CFA_def_cfa_offset 56 right after the add $8, %rsp insn, while with
Richard's patch DW_CFA_remember_state appears only after it.  I'll preprocess
link.cc now and will see what is gong on at the RTL level...

[Bug middle-end/46515] [4.6 Regression] Many libjava failures

[rth at gcc dot gnu.org]

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

Richard Henderson <rth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED
         AssignedTo|unassigned at gcc dot       |rth at gcc dot gnu.org
                   |gnu.org                     |

--- Comment #5 from Richard Henderson <rth at gcc dot gnu.org> 2010-11-18 16:34:36 UTC ---
A change in the placement of remember_state suggests a change
in the placement of EPILOGUE_BEG.  Which suggests a change in
prologue_epilogue_contains -- peep2 not copying status?

Mine.

[Bug middle-end/46515] [4.6 Regression] Many libjava failures

[jakub at gcc dot gnu.org]

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

--- Comment #6 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-11-18 16:42:12 UTC ---
Created attachment 22448
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22448
link.ii.bz2

./cc1plus -fpreprocessed link.ii -quiet -dumpbase link.ii -mtune=generic
-march=x86-64 -auxbase-strip link.s -g -O2 -fno-rtti -fnon-call-exceptions
-fdollars-in-identifiers -fomit-frame-pointer -fPIC -o link.s

if it saves you time...

[Bug middle-end/46515] [4.6 Regression] Many libjava failures

[jakub at gcc dot gnu.org]

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

--- Comment #7 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-11-18 16:48:54 UTC ---
I don't think we have any API to add a new insn into prologue or epilogue
hashes, guess easiest would be to reuse the old insn (and just change its
PATTERN/notes/etc. as needed) in the RTX_FRAME_RELATED_P case.

[Bug middle-end/46515] [4.6 Regression] Many libjava failures

[rth at gcc dot gnu.org]

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

--- Comment #8 from Richard Henderson <rth at gcc dot gnu.org> 2010-11-18 16:51:36 UTC ---
We do: maybe_copy_epilogue_insn.

[Bug middle-end/46515] [4.6 Regression] Many libjava failures

[jakub at gcc dot gnu.org]

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

--- Comment #9 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-11-18 16:55:03 UTC ---
Actually we have maybe_copy_epilogue_insn, just not maybe_copy_prologue_insn.

[Bug middle-end/46515] [4.6 Regression] Many libjava failures

[rth at gcc dot gnu.org]

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

--- Comment #10 from Richard Henderson <rth at gcc dot gnu.org> 2010-11-18 21:08:45 UTC ---
Author: rth
Date: Thu Nov 18 21:08:38 2010
New Revision: 166920

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=166920
Log:
PR middle-end/46515
        * function.c (maybe_copy_prologue_epilogue_insn): Rename from
        maybe_copy_epilogue_insn; handle prologue insns as well.
        * rtl.h, cfglayout.c: Update for rename.
        * recog.c (peep2_attempt): Copy prologue/epilogue data for
        RTX_FRAME_RELATED_P insns.

Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/cfglayout.c
    trunk/gcc/function.c
    trunk/gcc/recog.c
    trunk/gcc/rtl.h

[Bug middle-end/46515] [4.6 Regression] Many libjava failures

[jakub at gcc dot gnu.org]

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

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

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

--- Comment #11 from Jakub Jelinek <jakub at gcc dot gnu.org> 2010-11-18 22:16:46 UTC ---
Fixed.