[Bug java/32758] New: ecj1 hangs

[Bug java/32758] New: ecj1 hangs

[dir at lanl dot gov]

I built gcj and when I try to compile anything ecj1 uses about 5:33 minutes of
CPU time, then ecj1 and gcj just sit doing nothing.

  PID COMMAND      %CPU   TIME   #TH #PRTS #MREGS RPRVT  RSHRD  RSIZE  VSIZE
 9951 ecj1         0.0%  5:33.55   2    32    70  41.5M  94.1M  60.9M   350M 
 9950 gcj          0.0%  0:00.01   1    19    26   260K  1.43M  1.05M  87.8M


[dranta:~/tests] dir% gcj -bind_at_load --main=picture -o picture  picture.java
^C
[dranta:~/tests] dir% gcj --v
Using built-in specs.
Reading specs from
/usr/local/java/lib/gcc/powerpc-apple-darwin8.10.0/4.3.0/../../../libgcj.spec
rename spec startfile to startfileorig
rename spec lib to liborig
Target: powerpc-apple-darwin8.10.0
Configured with: ../gcc/configure --prefix=/usr/local/java
--enable-languages=c,c++,java --enable-java-awt=gtk --enable-gtk-cairo
--disable-multilib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib
--with-ecj-jar=/Users/dir/gfortran/gcc/ecj.jar
Thread model: posix
gcc version 4.3.0 20070705 (experimental)


-- 
           Summary: ecj1 hangs
           Product: gcc
           Version: 4.3.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: java
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: dir at lanl dot gov
  GCC host triplet: Darwin 8.9.0


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

[Bug java/32758] ecj1 hangs

[pinskia at gcc dot gnu dot org]

------- Comment #1 from pinskia at gcc dot gnu dot org  2007-07-15 21:03 -------
If ecj is hanging this might not be a GCJ bug but an ecj one.
Can you attach picture.java?


-- 


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

[Bug java/32758] ecj1 hangs

[dir at lanl dot gov]

------- Comment #2 from dir at lanl dot gov  2007-07-16 12:32 -------
Created an attachment (id=13921)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13921&action=view)
simple java test #1

This, I expected to build but crash on trying to run


-- 


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

[Bug java/32758] ecj1 hangs

[dir at lanl dot gov]

------- Comment #3 from dir at lanl dot gov  2007-07-16 12:35 -------
Created an attachment (id=13922)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13922&action=view)
Simple java test #2

This one actually ran before ecj


-- 


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

[Bug java/32758] ecj1 hangs

[dir at lanl dot gov]

------- Comment #4 from dir at lanl dot gov  2007-07-16 12:48 -------
These both do the same thing for me - ecj1 eats about 5:30 minutes of time -
then nothing, it just sits using no CPU time. This is my second try at a java
build since the switch to ecj with no luck at getting anything to work.


-- 


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

[Bug java/32758] ecj1 hangs

[tromey at gcc dot gnu dot org]

------- Comment #5 from tromey at gcc dot gnu dot org  2007-07-24 14:33 -------
Can you try running ecj with -help or something like that?
I'm wondering whether it works at all.
Perhaps the bootstrap java interpreter is broken on your machine,
or something like that.


-- 

tromey at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |tromey at gcc dot gnu dot
                   |                            |org
             Status|UNCONFIRMED                 |NEW
     Ever Confirmed|0                           |1
   Last reconfirmed|0000-00-00 00:00:00         |2007-07-24 14:33:31
               date|                            |


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

[Bug java/32758] ecj1 hangs

[dir at lanl dot gov]

------- Comment #6 from dir at lanl dot gov  2007-07-25 12:56 -------
I did the build with "--with-ecj-jar=/Users/dir/gfortran/gcc/ecj.jar" and there
is no visible ecj anywhere on my machine. ecj1 is in
./java/libexec/gcc/powerpc-apple-darwin8.10.0/4.3.0/. With "ecj1 -help", ecj1
sits using nearly 100 percent of the cpu time, but nothing else.


-- 


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

[Bug java/32758] ecj1 hangs

[dir at lanl dot gov]

------- Comment #7 from dir at lanl dot gov  2007-08-03 14:03 -------
I was looking in the CrashReported log for something else and I noticed that
ecj1 was hanging because it was crashing. Here is the crash log trace back -

**********

Host Name:      dir
Date/Time:      2007-07-13 10:52:37.582 -0700
OS Version:     10.4.10 (Build 8R218)
Report Version: 4

Command: ecj1
Path:    /usr/local/java/libexec/gcc/powerpc-apple-darwin8.10.0/4.3.0/ecj1
Parent:  gcj [9917]

Version: ??? (???)

PID:    9918
Thread: 0

Exception:  EXC_BAD_ACCESS (0x0001)
Codes:      KERN_PROTECTION_FAILURE (0x0002) at 0x00000624

Thread 0 Crashed:
0   libgcc_s.1.dylib    0x9143bb80 _Unwind_fallback_frame_state_for + 160
1   libgcc_s.1.dylib    0x914383cc uw_frame_state_for + 96
2   libgcc_s.1.dylib    0x914395dc _Unwind_Backtrace + 72
3   libgcj.9.dylib      0x05c7f394 Jv_StackTrace::GetStackTrace() + 116
(stacktrace.cc:193)
4   libgcj.9.dylib      0x05cb0224
_ZN4java4lang11VMThrowable16fillInStackTraceEJPS1_PNS0_9ThrowableE + 52
(natVMThrowable.cc:33)
5   libgcj.9.dylib      0x060ef6a8
_ZN4java4lang9Throwable16fillInStackTraceEJPS1_v + 24 (Throwable.java:499)
6   libgcj.9.dylib      0x060eef28
java::lang::Throwable::Throwable[in-charge](java::lang::String*) + 52
(Throwable.java:160)
7   libgcj.9.dylib      0x060d68c4
java::lang::Exception::Exception[in-charge](java::lang::String*) + 16
(Error.java:0)
8   libgcj.9.dylib      0x060b5a78
java::io::IOException::IOException[in-charge](java::lang::String*) + 16
(Flushable.java:0)
9   libgcj.9.dylib      0x05c9aeb0
_ZN3gnu3gcj4Core6createEJPS1_PN4java4lang6StringE + 112 (natCore.cc:118)
10  libgcj.9.dylib      0x05d901e8
_ZN3gnu4java3net8protocol4core10Connection7connectEJvv + 52
(Connection.java:51)
11  libgcj.9.dylib      0x05d905fc
_ZN3gnu4java3net8protocol4core10Connection10getHeadersEJvv + 84
(Connection.java:162)
12  libgcj.9.dylib      0x05d902d0
_ZN3gnu4java3net8protocol4core10Connection14getHeaderFieldEJPN4java4lang6StringES8_
+ 36 (Connection.java:75)
13  libgcj.9.dylib      0x0611c53c
_ZN4java3net13URLConnection17getHeaderFieldIntEJiPNS_4lang6StringEi + 36
(URLConnection.java:428)
14  libgcj.9.dylib      0x0611c354
_ZN4java3net13URLConnection16getContentLengthEJiv + 56 (URLClassLoader.java:0)
15  libgcj.9.dylib      0x05d8e4e8
_ZN3gnu4java3net6loader15RemoteURLLoader11getResourceEJPNS2_8ResourceEPN4java4lang6StringE
+ 136 (RemoteURLLoader.java:79)
16  libgcj.9.dylib      0x0611b4c0
_ZN4java3net14URLClassLoader9findClassEJPNS_4lang5ClassEPNS2_6StringE + 288
(URLClassLoader.java:527)
17  libgcj.9.dylib      0x05cd5e0c
_ZN3gnu3gcj7runtime15BootClassLoader13bootLoadClassEJPN4java4lang5ClassEPNS4_6StringE
+ 68 (ccLCHdqDjx:0)
18  libgcj.9.dylib      0x05cb00d8
_ZN4java4lang13VMClassLoader9loadClassEJPNS0_5ClassEPNS0_6StringEb + 96
(natVMClassLoader.cc:224)
19  libgcj.9.dylib      0x05ca8f04 Jv_FindClass(_Jv_Utf8Const*,
java::lang::ClassLoader*) + 384 (natClassLoader.cc:465)
20  libgcj.9.dylib      0x05ca7254
_ZN4java4lang5Class7forNameEJPS1_PNS0_6StringEbPNS0_11ClassLoaderE + 160
(natClass.cc:107)
21  libgcj.9.dylib      0x05cd5238
_ZN3gnu3gcj7convert14UnicodeToBytes10getEncoderEJPS2_PN4java4lang6StringE + 356
(UnicodeToBytes.java:99)
22  libgcj.9.dylib      0x05cd4f3c
_ZN3gnu3gcj7convert14UnicodeToBytes17getDefaultEncoderEJPS2_v + 80
(Output_iconv.java:0)
23  libgcj.9.dylib      0x060c4758
java::io::OutputStreamWriter::OutputStreamWriter[in-charge](java::io::OutputStream*)
+ 28 (OutputStream.java:0)
24  libgcj.9.dylib      0x060c76d0
java::io::PrintWriter::PrintWriter[in-charge](java::io::OutputStream*) + 60
(PrintWriter.java:130)
25  libgcj.9.dylib      0x066bcaa4 ffi_call_DARWIN + 208 (darwin.S:131)
26  libgcj.9.dylib      0x066bd854 ffi_call + 104 (ffi_darwin.c:464)
27  libgcj.9.dylib      0x066bda88 ffi_java_raw_call + 92 (java_raw_api.c:294)
28  libgcj.9.dylib      0x05c92824 Jv_InterpMethod::run(void*, ffi_raw*,
_Jv_InterpMethod*) + 1536 (interpret-run.cc:590)
29  libgcj.9.dylib      0x066bdd2c ffi_java_translate_args + 104
(java_raw_api.c:308)
30  libgcj.9.dylib      0x066bd404 ffi_closure_helper_DARWIN + 308
(ffi_darwin.c:800)
31  libgcj.9.dylib      0x066bcb84 ffi_closure_ASM + 116 (darwin_closure.S:106)
32  libgcj.9.dylib      0x05c9de1c _ZN3gnu4java4lang10MainThread9call_mainEJvv
+ 220 (natMainThread.cc:61)
33  libgcj.9.dylib      0x05caf6f0 Jv_ThreadRun(java::lang::Thread*) + 52
(natThread.cc:345)
34  libgcj.9.dylib      0x05c6de38 Jv_RunMain(_Jv_VMInitArgs*,
java::lang::Class*, char const*, int, char const**, bool) + 508 (prims.cc:1770)
35  ecj1                0x00002228 _start + 760
36  ecj1                0x00001f2c start + 48

Thread 1:
0   libSystem.B.dylib   0x9002c3c8 semaphore_wait_signal_trap + 8
1   libSystem.B.dylib   0x90030eac pthread_cond_wait + 480
2   libgcj.9.dylib      0x05cb9178 Jv_CondWait(_Jv_ConditionVariable_t*,
_Jv_Mutex_t*, long long, int) + 636 (posix-threads.cc:212)
3   libgcj.9.dylib      0x05c9d4a0 _ZN3gnu3gcj7runtime15FinalizerThread3runEJvv
+ 144 (natFinalizerThread.cc:58)
4   libgcj.9.dylib      0x05caf6f0 Jv_ThreadRun(java::lang::Thread*) + 52
(natThread.cc:345)
5   libgcj.9.dylib      0x05cb8b50 _ZL12really_startPv + 56
(posix-threads.cc:618)
6   libgcj.9.dylib      0x066d8878 GC_start_routine + 268
(pthread_support.c:1306)
7   libSystem.B.dylib   0x9002bd08 _pthread_body + 96

Thread 0 crashed with PPC Thread State 64:
  srr0: 0x000000009143bb80 srr1: 0x100000000200f030                       
vrsave: 0x0000000000000000
    cr: 0x24002422          xer: 0x0000000020000000   lr: 0x000000009143bb70 
ctr: 0x0000000091437a88
    r0: 0x000000009143bb70   r1: 0x00000000bfffcf20   r2: 0x00000000a14310a0  
r3: 0x0000000022000442
    r4: 0x0000000000000046   r5: 0x00000000000003e8   r6: 0xffffffffffffffff  
r7: 0x0000000000000000
    r8: 0x0000000000000000   r9: 0x0000000000000118  r10: 0x0000000000000000 
r11: 0x00000000a1431098
   r12: 0x0000000091437a88  r13: 0x00000000bfffedc0  r14: 0x0000000000000000 
r15: 0x0000000000000000
   r16: 0x0000000000000000  r17: 0x0000000000000000  r18: 0x0000000000000000 
r19: 0x0000000000000000
   r20: 0x0000000006ddbfc8  r21: 0x0000000006dcb100  r22: 0x00000000006d1960 
r23: 0x0000000000000624
   r24: 0x00000000bfffd32c  r25: 0x00000000bfffd0c8  r26: 0x00000000bfffcf58 
r27: 0x00000000bfffcfd8
   r28: 0x0000000000000020  r29: 0x0000000000000000  r30: 0x0000000000000624 
r31: 0x000000009143bae8

Binary Images Description:
    0x1000 -     0x2fff ecj1   
/usr/local/java/libexec/gcc/powerpc-apple-darwin8.10.0/4.3.0/ecj1
 0x5c69000 -  0x6c61fff libgcj.9.dylib  /usr/local/java/lib/libgcj.9.dylib
0x8fe00000 - 0x8fe52fff dyld 46.12      /usr/lib/dyld
0x90000000 - 0x901bcfff libSystem.B.dylib       /usr/lib/libSystem.B.dylib
0x90214000 - 0x90219fff libmathCommon.A.dylib  
/usr/lib/system/libmathCommon.A.dylib
0x91431000 - 0x9143cfff libgcc_s.1.dylib        /usr/lib/libgcc_s.1.dylib
0x92a02000 - 0x92af0fff libiconv.2.dylib        /usr/lib/libiconv.2.dylib


-- 


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

[Bug java/32758] ecj1 hangs

[andreast at gcc dot gnu dot org]

------- Comment #8 from andreast at gcc dot gnu dot org  2007-08-06 20:34 -------
Happens since r125624. Same situation on ppc-linux (32-bit)

In the libjava testsuite you'll see the following test cases failing since
then:

FAIL: noclass execution - gij test
FAIL: pr11951 execution - gij test
FAIL: throwit execution - gij test
FAIL: pr29812 execution - gij test
FAIL: ExtraClassLoader execution - source compiled test
FAIL: ExtraClassLoader -findirect-dispatch execution - source compiled test
FAIL: ExtraClassLoader -O3 execution - source compiled test
FAIL: ExtraClassLoader -O3 -findirect-dispatch execution - source compiled test


-- 

andreast at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Last reconfirmed|2007-07-24 14:33:31         |2007-08-06 20:34:34
               date|                            |


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

[Bug java/32758] ecj1 hangs

[aph at gcc dot gnu dot org]

------- Comment #9 from aph at gcc dot gnu dot org  2007-08-08 08:48 -------
I've seen this in a few different contexts now.

Looks like the dataflow merge broke _Unwind_fallback_frame_state_for.


-- 

aph at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |aph at gcc dot gnu dot org


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[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
          Component|java                        |middle-end
   GCC host triplet|Darwin 8.9.0                |
 GCC target triplet|                            |powerpc-darwin
            Summary|ecj1 hangs                  |[4.3 Regression] ecj1 hangs
   Target Milestone|---                         |4.3.0


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[andreast at gcc dot gnu dot org]

------- Comment #10 from andreast at gcc dot gnu dot org  2007-08-24 21:05 -------
if libffi is compiled with -O0 the tests pass. If compiled with -O1/O2 they
fail.


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[andreast at gcc dot gnu dot org]

------- Comment #11 from andreast at gcc dot gnu dot org  2007-08-26 21:28 -------
compiling only java_raw_api.c with -O0 succeeds as well. So let us concentrate
on this one. Speaking for darwin-ppc.
Will retry tomorrow on ppc-linux.


-- 

andreast at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |andreast at gcc dot gnu dot
                   |                            |org
 GCC target triplet|powerpc-darwin              |powerpc-*
   Last reconfirmed|2007-08-06 20:34:34         |2007-08-26 21:28:27
               date|                            |


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[andreast at gcc dot gnu dot org]

------- Comment #12 from andreast at gcc dot gnu dot org  2007-08-27 07:57 -------
Created an attachment (id=14120)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14120&action=view)
Preprocessed source at O1 java_raw_api


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[andreast at gcc dot gnu dot org]

------- Comment #13 from andreast at gcc dot gnu dot org  2007-08-27 07:58 -------
Created an attachment (id=14121)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14121&action=view)
Assembly output from preprocessing the java_raw_api at O1


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[aph at gcc dot gnu dot org]

------- Comment #14 from aph at gcc dot gnu dot org  2007-08-28 11:44 -------
Is this with -fno-strict-aliasing?


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[rguenth at gcc dot gnu dot org]

------- Comment #15 from rguenth at gcc dot gnu dot org  2007-08-28 12:16 -------
-O1 doesn't enable -fstrict-aliasing, only -O2 does.


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[andreast at gcc dot gnu dot org]

------- Comment #16 from andreast at gcc dot gnu dot org  2007-08-28 18:44 -------
Volumes/development/gcc/head/objdir/./gcc/xgcc
-B/Volumes/development/gcc/head/objdir/./gcc/
-B/Volumes/development/gcc/head/testbin/powerpc-apple-darwin8.10.0/bin/
-B/Volumes/development/gcc/head/testbin/powerpc-apple-darwin8.10.0/lib/
-isystem
/Volumes/development/gcc/head/testbin/powerpc-apple-darwin8.10.0/include
-isystem
/Volumes/development/gcc/head/testbin/powerpc-apple-darwin8.10.0/sys-include
-DHAVE_CONFIG_H -I. -I/Volumes/development/gcc/head/gcc/libffi -I. -I.
-I/Volumes/development/gcc/head/gcc/libffi/include -Iinclude
-I/Volumes/development/gcc/head/gcc/libffi/src -Wall -g -fexceptions -O0 -g -O0
-MT src/java_raw_api.lo -MD -MP -MF src/.deps/java_raw_api.Tpo -c
/Volumes/development/gcc/head/gcc/libffi/src/java_raw_api.c -fno-common -DPIC
-o src/.libs/java_raw_api.o

So no explicit -fstrict-aliasing.
Iow, yes with -fno-strict-aliasing.


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[jakub at gcc dot gnu dot org]

------- Comment #17 from jakub at gcc dot gnu dot org  2007-08-28 19:38 -------
I can reproduce this on ppc32-linux, working on a self-contained reproducer.


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[andreast at gcc dot gnu dot org]

------- Comment #18 from andreast at gcc dot gnu dot org  2007-08-28 21:00 -------
Adding -fno-dce at -O1/O2 helps passing the failing test cases mentioned in
comment #8 on ppc-linux and ppc-darwin.


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[jakub at gcc dot gnu dot org]

------- Comment #19 from jakub at gcc dot gnu dot org  2007-08-29 08:07 -------
Binary search among the routines in java_raw_api.c with -fno-inline shows
the noclass testcase fails if either ffi_java_raw_call or
ffi_java_translate_args
is compiled with -O2 -fdce, if both are compiled with -O2 -fno-dce the testcase
succeeds.
The assembly diff for ffi_java_raw_call is fairly small:
--- /tmp/j4.s1  2007-08-29 10:05:43.000000000 +0200
+++ /tmp/j4.s2  2007-08-29 10:05:49.000000000 +0200
@@ -51,12 +51,6 @@ ffi_java_raw_call:
         # /tmp/j4.i:1008
        .loc 1 1008 0
        lwz 0,0(1)
-        # /tmp/j4.i:1007
-       .loc 1 1007 0
-       mr 31,1
-.LCFI9:
-        # /tmp/j4.i:1008
-       .loc 1 1008 0
        lwz 9,4(3)
        slwi 9,9,2
        addi 9,9,30
@@ -150,10 +144,6 @@ ffi_java_raw_call:
        .uleb128 0x2
        .byte   0x9d     # DW_CFA_offset, column 0x1d
        .uleb128 0x3
-       .byte   0x4      # DW_CFA_advance_loc4
-       .4byte  .LCFI9-.LCFI8
-       .byte   0xd      # DW_CFA_def_cfa_register
-       .uleb128 0x1f
        .align 2
 .LEFDE0:
 #NO_APP
@@ -207,10 +197,6 @@ ffi_java_raw_call:
        .uleb128 0x2
        .byte   0x9d     # DW_CFA_offset, column 0x1d
        .uleb128 0x3
-       .byte   0x4      # DW_CFA_advance_loc4
-       .4byte  .LCFI9-.LCFI8
-       .byte   0xd      # DW_CFA_def_cfa_register
-       .uleb128 0x1f
        .align 2
 .LEFDE1:
 #NO_APP
@@ -224,14 +210,9 @@ ffi_java_raw_call:
        .2byte  0x1      # Location expression size
        .byte   0x51     # DW_OP_reg1
        .4byte  .LCFI0-.Ltext0   # Location list begin address (*.LLST0)
-       .4byte  .LCFI9-.Ltext0   # Location list end address (*.LLST0)
-       .2byte  0x2      # Location expression size
-       .byte   0x71     # DW_OP_breg1
-       .sleb128 32
-       .4byte  .LCFI9-.Ltext0   # Location list begin address (*.LLST0)
        .4byte  .LFE28-.Ltext0   # Location list end address (*.LLST0)
        .2byte  0x2      # Location expression size
-       .byte   0x8f     # DW_OP_breg31
+       .byte   0x71     # DW_OP_breg1
        .sleb128 32
        .4byte  0x0      # Location list terminator begin (*.LLST0)
        .4byte  0x0      # Location list terminator end (*.LLST0)

Investigating (though my guess is this is caused by dataflow).


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[jakub at gcc dot gnu dot org]

------- Comment #20 from jakub at gcc dot gnu dot org  2007-08-29 08:52 -------
typedef struct {
  int abi;
  unsigned nargs;
  void **arg_types;
  void *rtype;
  unsigned bytes;
  unsigned flags;
} ffi_cif;

void ffi_java_raw_to_ptrarray (ffi_cif *cif, void *raw, void **args);
void ffi_java_rvalue_to_raw (ffi_cif *cif, void *rvalue);
void ffi_call(ffi_cif *cif, void (*fn)(), void *rvalue, void **avalue);

void ffi_java_raw_call (ffi_cif *cif, void (*fn)(), void *rvalue, void *raw)
{
  void **avalue = (void**) __builtin_alloca (cif->nargs * sizeof (void*));
  ffi_java_raw_to_ptrarray (cif, raw, avalue);
  ffi_call (cif, fn, rvalue, avalue);
  ffi_java_rvalue_to_raw (cif, rvalue);
}

-m32 -O2 -fexceptions -fno-dce vs. -m32 -O2 -fexceptions -fdce
shows the same difference.
The assignment of stack pointer to hard frame pointer is removed during
*.peephole2.  Although the hard frame pointer is never referenced directly
in the function, it is really necessary for proper unwind info, given
that the function uses alloca and stack pointer is decreased by some
non-constant
value.

Here is an executable testcase for inclusion in the testsuite.  Fails with both
ppc -m32 and -m64 at -O2 -fexceptions, doesn't fail with -O2 -fno-dce
-fexceptions.

/* HP-UX libunwind.so doesn't provide _UA_END_OF_STACK */
/* { dg-do run } */
/* { dg-options "-O2 -fexceptions" } */
/* { dg-skip-if "" { "ia64-*-hpux11.*" }  { "*" } { "" } } */
/* Verify unwind info in presence of alloca.  */

#include <unwind.h>
#include <stdlib.h>
#include <string.h>

static _Unwind_Reason_Code
force_unwind_stop (int version, _Unwind_Action actions,
                   _Unwind_Exception_Class exc_class,
                   struct _Unwind_Exception *exc_obj,
                   struct _Unwind_Context *context,
                   void *stop_parameter)
{
  if (actions & _UA_END_OF_STACK)
    abort ();
  return _URC_NO_REASON;
}

static void force_unwind (void)
{
  struct _Unwind_Exception *exc = malloc (sizeof (*exc));
  memset (&exc->exception_class, 0, sizeof (exc->exception_class));
  exc->exception_cleanup = 0;

#ifndef __USING_SJLJ_EXCEPTIONS__
  _Unwind_ForcedUnwind (exc, force_unwind_stop, 0);
#else
  _Unwind_SjLj_ForcedUnwind (exc, force_unwind_stop, 0);
#endif

  abort ();
}

__attribute__((noinline))
void foo (void *x __attribute__((unused)))
{
  force_unwind ();
}

__attribute__((noinline))
int bar (unsigned int x)
{
  void *y = __builtin_alloca (x);
  foo (y);
  return 1;
}

static void handler (void *p __attribute__((unused)))
{
  exit (0);
}

__attribute__((noinline))
static void doit ()
{
  char dummy __attribute__((cleanup (handler)));
  bar (1024);
}

int main ()
{
  doit ();
  abort ();
}


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[jakub at gcc dot gnu dot org]

------- Comment #21 from jakub at gcc dot gnu dot org  2007-08-29 11:18 -------
The major difference between say i?86 or x86_64 and ppc here is that
on the former two the hard frame pointer is actually visibly, not just
artificially, used when restoring the stack pointer.  ppc restores the
stack pointer from the memory value stwux instruction creates and so it
doesn't visibly use hard frame pointer.
While rest_of_handle_ud_dce calls mark_artificial_uses and that way marks
all the instructions that define the artificial registers.  On the other
side, dce_process_block from fast_dce will not mark the instructions that
define the artificial uses, instead or all the artificial register bits into
local_live bitmap.
31 (ppc hard frame pointer) is an artificial use, so dce_process_block
sets bit 31 in local_live during initialization (i.e. at the end of the basic
block).  But then goes through insns backwards and finds
(insn 50 49 51 2 l2.c:9 (set (reg/f:DI 31 31)
        (mem/c:DI (plus:DI (reg/f:DI 1 1)
                (const_int -8 [0xfffffffffffffff8])) [5 S8 A8])) -1 (nil))
which restores the saved hard frame pointer in the epilogue.  This definition
clears bit 31 from the local_live bitmap and as everything is one basic block,
there is nothing else which will prevent removing the hard frame pointer
initialization.

df_simulate_one_insn_forwards and df_simulate_one_insn_backwards
(why we have the former when nothing ever uses it?) both call
df_simulate_fixup_sets to fix this up, shouldn't dce_process_block call that
too?


-- 

jakub at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dberlin at gcc dot gnu dot
                   |                            |org, bonzini at gnu dot org
           Priority|P3                          |P1


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[jakub at gcc dot gnu dot org]

------- Comment #22 from jakub at gcc dot gnu dot org  2007-08-29 11:41 -------
Created an attachment (id=14132)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=14132&action=view)
gcc43-pr32758.patch

Here is what I will try to regtest (already verified it fixes the testcase).
Alternatively, artificial_live could be a pointer bitmap which would just
point to one of the &df->*_block_artificial_uses bitmap, though not sure
if that ever could or in some register that wasn't originally set in
local_live.
Certainly calling df_has_eh_preds just once per bb rather than per insn is IMHO
worthwhile.


-- 

jakub at gcc dot gnu dot org changed:

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


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[paolo dot bonzini at lu dot unisi dot ch]

------- Comment #23 from paolo dot bonzini at lu dot unisi dot ch  2007-08-29 11:47 -------
Subject: Re:  [4.3 Regression] ecj1 hangs


> df_simulate_one_insn_forwards and df_simulate_one_insn_backwards
> (why we have the former when nothing ever uses it?) both call
> df_simulate_fixup_sets to fix this up, shouldn't dce_process_block call that
> too?

Yes, it was probably an oversight of this patch:

2007-05-21  Kenneth Zadeck <zadeck@naturalbridge.com>

         * dbgcnt.def: Fixed comment.
         * df-scan.c (df_get_regular_block_artificial_uses): Added frame
         pointer after reload if frame_pointer_needed.
         * df.h (df_simulate_defs, df_simulate_uses): Made public.
         * df-problems.c (df_simulate_defs, df_simulate_uses): Made
        public.
         * dce.c (deletable_insn_p): Only allow frame-related insns to be
         deleted if there is a REG_MAYBE_DEAD note.
         (dce_process_block): Now uses df_simulate_defs and
         df_simulate_uses.

It should be placed outside the if, i.e. you should always execute it. 
You can CC me when you send the patch to the mailing list (but I'll be 
out of office from tomorrow to sunday).


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[paolo dot bonzini at lu dot unisi dot ch]

------- Comment #24 from paolo dot bonzini at lu dot unisi dot ch  2007-08-29 12:15 -------
Subject: Re:  [4.3 Regression] ecj1 hangs

> Here is what I will try to regtest (already verified it fixes the testcase).

This is wrong, because local_live changes during execution of 
dce_process_block.  The {eh,regular}_block_artificial_uses must always 
be set (they are live throughout, not just at the bottom of the basic 
block).

> Alternatively, artificial_live could be a pointer bitmap which would just
> point to one of the &df->*_block_artificial_uses bitmap, though not sure
> if that ever could or in some register that wasn't originally set in
> local_live.

Much better, and would have the same effect as dce_simulate_fixup_sets.

> Certainly calling df_has_eh_preds just once per bb rather than per insn is IMHO
> worthwhile.

A patch to do so if preapproved if you add a comment saying

/* Calling df_simulate_fixup_sets has the disadvantage of calling
    df_has_eh_preds once per insn, so we cache the information here.  */

before the place where you set artificial_live.

Thanks!


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[jakub at gcc dot gnu dot org]

------- Comment #25 from jakub at gcc dot gnu dot org  2007-08-29 13:26 -------
Unfortunately it breaks e.g. memcpy-chk.c, simplified testcase here:
extern void abort (void);
typedef __SIZE_TYPE__ size_t;
extern void *memcpy (void *, const void *, size_t);
extern volatile int chk_fail_allowed;
extern void *chk_fail_buf[];
char *s2 = "defg";
char *s3 = "FGH";
size_t l1 = 1;
void
__attribute__((noinline))
test4 (void)
{
  struct A { char buf1[10]; char buf2[10]; } a;
  char buf3[20];

  chk_fail_allowed = 1;

  if (__builtin_setjmp (chk_fail_buf) == 0)
    {
      __builtin___memcpy_chk (&a.buf2[9], s2, l1 + 1, __builtin_object_size
(&a.buf2[9], 0));
      abort ();
    }
  if (__builtin_setjmp (chk_fail_buf) == 0)
    {
      __builtin___memcpy_chk (&a.buf2[7], s3, strlen (s3) + 1,
__builtin_object_size (&a.buf2[7], 0));
      abort ();
    }

  if (__builtin_setjmp (chk_fail_buf) == 0)
    {
      __builtin___memcpy_chk (&buf3[19], "ab", 2, __builtin_object_size
(&buf3[19], 0));
      abort ();
    }
  chk_fail_allowed = 0;
}

Not all basic blocks have all 4 x86_64 regular_block_artificial_regs registers
set in DF_LR_IN and so oring this in causes infinite loop, as process_dce_block
always returns something changed.


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[jakub at gcc dot gnu dot org]

------- Comment #26 from jakub at gcc dot gnu dot org  2007-08-29 13:56 -------
Apparently dce is the only user of df_simulate_* which at the start of the
basic block compares the resulting bitmap with DF_LR_IN.  All other users
of these interfaces don't do that (ifcvt, rtl-factoring, peephole2).
And df-problems.c which computes DF_LR_IN doesn't or in the regular or eh
artificial uses bitmap in every step.
So, if fast dce is to keep comparing the local_live bitmap with DF_LR_IN
(and it probably needs to, since if some insns are marked to be deleted,
it needs to update it), local_live has to be computed the same way as it is
now.

So either we just check either local_live or au bitmaps:

--- dce.c.jj    2007-08-13 15:11:18.000000000 +0200
+++ dce.c       2007-08-29 15:37:57.000000000 +0200
@@ -527,6 +527,7 @@ static bool
 dce_process_block (basic_block bb, bool redo_out)
 {
   bitmap local_live = BITMAP_ALLOC (&dce_tmp_bitmap_obstack);
+  bitmap au;
   rtx insn;
   bool block_changed;
   struct df_ref **def_rec, **use_rec;
@@ -569,6 +570,15 @@ dce_process_block (basic_block bb, bool 
        bitmap_set_bit (local_live, DF_REF_REGNO (use));
     }

+  /* These regs are considered always live so if they end up dying
+     because of some def, we need to bring the back again.
+     Calling df_simulate_fixup_sets has the disadvantage of calling
+     df_has_eh_preds once per insn, so we cache the information here.  */
+  if (df_has_eh_preds (bb))
+    au = df->eh_block_artificial_uses;
+  else
+    au = df->regular_block_artificial_uses;
+
   FOR_BB_INSNS_REVERSE (bb, insn)
     if (INSN_P (insn))
       {
@@ -580,7 +590,8 @@ dce_process_block (basic_block bb, bool 

            /* The insn is needed if there is someone who uses the output.  */
            for (def_rec = DF_INSN_DEFS (insn); *def_rec; def_rec++)
-             if (bitmap_bit_p (local_live, DF_REF_REGNO (*def_rec)))
+             if (bitmap_bit_p (local_live, DF_REF_REGNO (*def_rec))
+                 || bitmap_bit_p (au, DF_REG_REGNO (*def_rec)))
                {
                  needed = true;
                  break;

or add another bitmap:

--- dce.c.jj    2007-08-13 15:11:18.000000000 +0200
+++ dce.c       2007-08-29 15:41:48.000000000 +0200
@@ -527,6 +527,8 @@ static bool
 dce_process_block (basic_block bb, bool redo_out)
 {
   bitmap local_live = BITMAP_ALLOC (&dce_tmp_bitmap_obstack);
+  bitmap local_live_or_au = BITMAP_ALLOC (&dce_tmp_bitmap_obstack);
+  bitmap au;
   rtx insn;
   bool block_changed;
   struct df_ref **def_rec, **use_rec;
@@ -569,6 +571,16 @@ dce_process_block (basic_block bb, bool 
        bitmap_set_bit (local_live, DF_REF_REGNO (use));
     }

+  /* These regs are considered always live so if they end up dying
+     because of some def, we need to bring the back again.
+     Calling df_simulate_fixup_sets has the disadvantage of calling
+     df_has_eh_preds once per insn, so we cache the information here.  */
+  if (df_has_eh_preds (bb))
+    au = df->eh_block_artificial_uses;
+  else
+    au = df->regular_block_artificial_uses;
+  bitmap_ior (local_live_or_au, local_live, au);
+
   FOR_BB_INSNS_REVERSE (bb, insn)
     if (INSN_P (insn))
       {
@@ -580,7 +592,7 @@ dce_process_block (basic_block bb, bool 

            /* The insn is needed if there is someone who uses the output.  */
            for (def_rec = DF_INSN_DEFS (insn); *def_rec; def_rec++)
-             if (bitmap_bit_p (local_live, DF_REF_REGNO (*def_rec)))
+             if (bitmap_bit_p (local_live_or_au, DF_REF_REGNO (*def_rec)))
                {
                  needed = true;
                  break;
@@ -600,6 +612,7 @@ dce_process_block (basic_block bb, bool 
                    if (dump_file)
                      fprintf (dump_file, "needed libcall %d\n", INSN_UID
(insn));
                    mark_libcall (insn, true);
+                   BITMAP_FREE (local_live_or_au);
                    BITMAP_FREE (local_live);
                    return dce_process_block (bb, false);
                  }
@@ -616,6 +629,8 @@ dce_process_block (basic_block bb, bool 
           anything in local_live.  */
        if (marked_insn_p (insn))
          df_simulate_uses (insn, local_live);
+
+       bitmap_ior (local_live_or_au, local_live, au);
       }

   for (def_rec = df_get_artificial_defs (bb_index); *def_rec; def_rec++)
@@ -640,6 +655,7 @@ dce_process_block (basic_block bb, bool 
   if (block_changed)
     bitmap_copy (DF_LR_IN (bb), local_live);

+  BITMAP_FREE (local_live_or_au);
   BITMAP_FREE (local_live);
   return block_changed;
 }

The latter might be faster, but I'm not 100% sure about that.


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[bonzini at gnu dot org]

------- Comment #27 from bonzini at gnu dot org  2007-08-29 14:11 -------

> Not all basic blocks have all 4 x86_64 regular_block_artificial_regs registers
> set in DF_LR_IN and so oring this in causes infinite loop, as process_dce_block
> always returns something changed.

If so, your previous patch would be correct.  But in that case I wonder:

1) what is the purpose df_simulate_fixup_sets in df_simulate_one_insn_backwards
(and df_simulate_one_insn_forwards, FWIW).  Doing the OR for every insn is
clearly wrong, if it doesn't result in the IN set equal to DF_LR_IN.

2) why is the code marked as 

  /* Process the artificial defs and uses at the bottom of the block.  */

in dce_process_block slightly different from df_simulate_artificial_refs_at_end
and df_simulate_artificial_refs_at_top.

3) whether the code you added in dce_process_block should go in
df_simulate_artificial_refs_at_end actually.

Post your first patch, I will try to sort out this mess next week and may ask
you to regtest a patch on at least x86_64 and ia64.  In the meanwhile I CCed
Zadeck so that he can answer these questions...


-- 

bonzini at gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |zadeck at gcc dot gnu dot
                   |                            |org


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[bonzini at gnu dot org]

------- Comment #28 from bonzini at gnu dot org  2007-08-29 14:14 -------
> Apparently dce is the only user of df_simulate_* which at the start of the
> basic block compares the resulting bitmap with DF_LR_IN. 

Yes.  The other two don't get infinite loops from their doing the wrong thing;
they just think some register is live and may miss some optimization.


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[bonzini at gnu dot org]

------- Comment #29 from bonzini at gnu dot org  2007-08-29 14:16 -------
(When I said "post your first patch", I meant the first one from comment #26;
if my "fixing the mess" works, it'll not be necessary anymore).


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[zadeck at naturalbridge dot com]

------- Comment #30 from zadeck at naturalbridge dot com  2007-08-29 15:34 -------
Subject: Re:  [4.3 Regression] ecj1 hangs

bonzini at gnu dot org wrote:
> ------- Comment #29 from bonzini at gnu dot org  2007-08-29 14:16 -------
> (When I said "post your first patch", I meant the first one from comment #26;
> if my "fixing the mess" works, it'll not be necessary anymore).
>
>
>   
For some reason, I was not copied on any of the postings for this patch
until this morning.

First, thankyou Jakub and Andreas for going this.

I think that it is obvious that you have spotted the exact problem: in
some way shape form of fashion, the artificial uses at the end of the
block need to be re added into the live set after the processing of each
insn in the block.

There are two ways of doing this (assume that you have a local variable
called artificial_uses_fixup which is a pointer to either
df->eh_block_artificial_uses or
df->regular_block_artificial_uses depending on if the block has eh preds) :

1) you can explicitly or artificial_uses_fixup into local_live after
processing each insn.
2) you can test artificial_uses_fixup along with local_live when setting
needed.

As noted, (1) has the problem that may cause an infinite loop.  This
infinite loop could be fixed by changing the equation for block_changed
to be

!bitmap_equal (local_live, DF_LR_IN (BB) || artificial_uses_fixup)

i.e. the infinite loop is because DF_LR_IN may be deficient in some of
the bits in artificial_uses_fixup for basically the same reason that
caused the bug in the first place.

I personally think that solution (1) is preferable to (2) because it is
fewer bitmap operations even though it will require a extra temp bitmap
to hold the or.

But either patch is a reasonable approach. 

As far as why there are all of the df_simulate functions that do things
in different ways, the answer is that the code has evolved and sometimes
things get missed.

The addition of the df->eh_block_artificial_uses and
df->regular_block_artificial_uses sets is fairly recent and it would
most likely be useful to replace walks  of artificial_uses with them. 

Kenny


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[andreast at gcc dot gnu dot org]

------- Comment #31 from andreast at gcc dot gnu dot org  2007-08-29 20:17 -------
Thanks Jakub!

With this patch: http://gcc.gnu.org/ml/gcc-patches/2007-08/msg02111.html
you not only brought back the testsuite passes, you also made the bytecode
compilation work again on ppc-linux and ppc-darwin (32-bit at least).
Before it was not possible, since the dataflow merge revision, to compile a
hello.java into a class file and execute via gij.

Your speed on how to solve this issue really impressed me!
Thanks again!!!


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[jakub at gcc dot gnu dot org]

------- Comment #32 from jakub at gcc dot gnu dot org  2007-08-30 08:27 -------
Subject: Bug 32758

Author: jakub
Date: Thu Aug 30 08:27:33 2007
New Revision: 127923

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=127923
Log:
        PR middle-end/32758
        * dce.c (dce_process_block): Don't delete setters of
        artificially used registers.

        * gcc.dg/cleanup-12.c: New test.

Added:
    trunk/gcc/testsuite/gcc.dg/cleanup-12.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/dce.c
    trunk/gcc/testsuite/ChangeLog


-- 


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

[Bug middle-end/32758] [4.3 Regression] ecj1 hangs

[jakub at gcc dot gnu dot org]

------- Comment #33 from jakub at gcc dot gnu dot org  2007-08-30 08:43 -------
Fixed.


-- 

jakub at gcc dot gnu dot org changed:

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


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