Bug 20606 - ICE in make_edges, at cfgbuild.c:327 on x86_64 (with O2 - not with no optimizations)
Summary: ICE in make_edges, at cfgbuild.c:327 on x86_64 (with O2 - not with no optimiz...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: middle-end (show other bugs)
Version: 4.0.0
: P2 normal
Target Milestone: 4.0.3
Assignee: Andrew Pinski
URL:
Keywords: ice-on-valid-code
Depends on: 24069
Blocks: 21362
  Show dependency treegraph
 
Reported: 2005-03-23 18:24 UTC by Andrew Overholt
Modified: 2005-10-05 19:52 UTC (History)
4 users (show)

See Also:
Host:
Target: x86_64-redhat-linux
Build:
Known to work:
Known to fail:
Last reconfirmed: 2005-04-06 15:13:38


Attachments
Test case (647 bytes, text/plain)
2005-03-23 18:25 UTC, Andrew Overholt
Details
Patch which needs testing (402 bytes, patch)
2005-09-30 22:43 UTC, Andrew Pinski
Details | Diff
The fix which needs to be tested (417 bytes, patch)
2005-10-05 00:55 UTC, Andrew Pinski
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Andrew Overholt 2005-03-23 18:24:31 UTC
Toggling line 17 of the (soon to be) attached source file allows the compilation
to proceed.  Bryce can duplicate this error with his build from head.

$ gcj --version
gcj (GCC) 4.0.0 20050320 (Red Hat 4.0.0-0.35)
$ wget http://people.redhat.com/~overholt/Main.java
$ javac Main.java
$ gcj -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic -o Main-noO2.so
Main.class
$ gcj -fPIC -fjni -findirect-dispatch -shared -Wl,-Bsymbolic -O2 -o
Main-withO2.so Main.class
Main.java: In class 'Main':
Main.java: In method
'Main.buildLocation(java.lang.String,java.net.URL,java.lang.String)':
Main.java:0: internal compiler error: in make_edges, at cfgbuild.c:327
Comment 1 Andrew Overholt 2005-03-23 18:25:19 UTC
Created attachment 8435 [details]
Test case

Toggling the comment on line 17 affects things.
Comment 2 Andrew Pinski 2005-03-23 19:29:03 UTC
Hmm, we are dying because of the following instruction:

(jump_insn 169 168 170 19 (set (pc)
 (reg/f:DI 66 [ #ref#6#19 ])) 515 {*indirect_jump_rtx64} (nil)
    (expr_list:REG_DEAD (reg/f:DI 66 [ #ref#6#19 ])
        (nil)))

But that does not make sense since this is a computed goto.

Why is computed_jump_p (insn) not returning true?
Comment 3 Andrew Pinski 2005-03-23 19:38:05 UTC
(In reply to comment #2)
> Why is computed_jump_p (insn) not returning true?
Actually it is the following insn:
(jump_insn 169 222 170 19 (set (pc)
        (reg:DI 0 ax)) 515 {*indirect_jump_rtx64} (nil)
    (insn_list:REG_LABEL 172 (nil)))

Which is a computed goto but at this point we have a REG_LABEL which causes computed_jump_p to 
return false.
Comment 4 Andrew Pinski 2005-03-23 19:46:18 UTC
Hmm, I think this is a reload or a recognizing problem.
inside reload (when adding the LABEL_REG), we have the following instruction:
(jump_insn 169 222 170 19 (set (pc)
        (label_ref:DI 172)) 515 {*indirect_jump_rtx64} (nil)
    (expr_list:REG_DEAD (reg/f:DI 66 [ #ref#6#19 ])
        (nil)))

But this is not an indirect_jump_rtx64 at this point but instead just a jump.

I cannot debug it further than this sorry.
Comment 5 Andrew Pinski 2005-03-23 20:30:34 UTC
We are missing some jump threading opertinutes on the tree level:
  prephitmp.107 = 0B;
  goto <bb 16> (*.LJpc=79);

.....

*.LJpc=79:;
  if (prephitmp.107 == 0B) goto *.LJpc=99; else goto <L13>;

Comment 6 Andrew Haley 2005-04-06 15:13:37 UTC
This only happens with -O2.  -O is a reasonable workaround for the time being.
Comment 7 Andrew Haley 2005-05-03 16:10:46 UTC
See also PR 21362
Comment 8 Andrew Pinski 2005-05-03 16:15:45 UTC
We no longer fail with this code on the mainline but most likely because actually thread the jump which 
I was taking in comment #5.
Comment 9 Andrew Pinski 2005-05-03 16:36:36 UTC
(In reply to comment #8)
> We no longer fail with this code on the mainline but most likely because actually thread the jump
> which  I was taking in comment #5.

Let me rewrite that.
This now works on the mainline.  This is most likely due to the jump threading changes in which we 
actually catch the threading on the tree level instead of waiting until the RTL level which causes the 
bug.
Comment 10 Mauro M. 2005-08-08 19:27:31 UTC
I am compiling eclipse on a dual opteron x86_64 system, running FC4, gcc 4.0.1
(fc package release 4.0.1-6) CVS: 20050729

Please find below the tail of the compile log:

++ /usr/bin/gcj-dbtool -f
/var/tmp/eclipse-3.1.0_ez-12-buildroot/usr/lib64/gcj/eclipse/platform.jar.db
/var/tmp/eclipse-3.1.0_ez-12-buildroot/usr/share/eclipse/plugins/org.eclipse.platform_3.1.1/platform.jar
/usr/lib64/gcj/eclipse/platform.jar.so
++ /usr/bin/gcj -shared -O2 -g -pipe -m64 -fPIC -findirect-dispatch -fjni
-Wl,-Bsymbolic
/var/tmp/eclipse-3.1.0_ez-12-buildroot/usr/share/eclipse/plugins/org.eclipse.platform_3.1.1/startup.jar
-o /var/tmp/eclipse-3.1.0_ez-12-buildroot/usr/lib64/gcj/eclipse/startup.jar.so
org/eclipse/core/launcher/Main.java: In class 'org.eclipse.core.launcher.Main':
org/eclipse/core/launcher/Main.java: In method
'org.eclipse.core.launcher.Main.buildLocation(java.lang.String,java.net.URL,java.lang.String)':
org/eclipse/core/launcher/Main.java:0: internal compiler error: in make_edges,
at cfgbuild.c:327
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://bugzilla.redhat.com/bugzilla> for instructions.
aot-compile-rpm: error: /usr/bin/gcj exited with code 1
error: Bad exit status from /var/tmp/rpm-tmp.33970 (%install)

The same build completes without errors on the same version of the compiler
built for and running on a dual Xeon 32 bit based system.
Comment 11 Andrew Haley 2005-08-08 19:37:14 UTC
I'm surprised this still fails with 4.0.1-6.

overholt, can you reproduce this?
Comment 12 Andrew Overholt 2005-08-24 14:45:50 UTC
(In reply to comment #11)
> I'm surprised this still fails with 4.0.1-6.
> 
> overholt, can you reproduce this?

I am having other issues building Eclipse ATM but I have not seen this, no.  If
it's important, I can set up a system with this exact version and try.  Building
for rawhide uses 4.0.1-10 now.

Comment 13 Andrew Pinski 2005-09-30 22:30:21 UTC
I am looking to fix this via the same fix for PR 24069.
The bug is the same, we have an indirect jump but to a known place.  This is a bug in make_edges.
Comment 14 Andrew Pinski 2005-09-30 22:43:42 UTC
Created attachment 9852 [details]
Patch which needs testing

This patch should fix the bug, could you try it on the 4.0 branch and see if it
fixes the problem for you.  I will be doing a bootstrap/test on
x86_64-pc-linux-gnu soon.
Comment 15 Andrew Pinski 2005-10-01 04:36:06 UTC
Ok, I can confirm this fixes the issue on the mainline with -fno-tree-dominator-opts so we get about 
the same RTL when expanding.
Comment 16 Andrew Pinski 2005-10-02 18:40:00 UTC
Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00047.html
Comment 17 Andrew Pinski 2005-10-04 19:07:12 UTC
The backtrace:
#1  0x008d8fc8 in make_edges (min=0x2c73cb8, max=0x2c694d0, update_p=1) at ../../gcc/cfgbuild.c:350
#2  0x008da32c in find_many_sub_basic_blocks (blocks=0x1e01200) at ../../gcc/cfgbuild.c:763
#3  0x0066ec6c in fixup_abnormal_edges () at ../../gcc/reload1.c:8185
#4  0x006576dc in reload (first=0x2c64c80, global=1) at ../../gcc/reload1.c:1265
#5  0x0091c6a4 in global_alloc (file=0x0) at ../../gcc/global.c:628
#6  0x0092375c in rest_of_handle_global_alloc () at ../../gcc/global.c:2497
#7  0x00728074 in execute_one_pass (pass=0xa61934) at ../../gcc/passes.c:827
#8  0x00728194 in execute_pass_list (pass=0xa61934) at ../../gcc/passes.c:859
#9  0x007281bc in execute_pass_list (pass=0xa60394) at ../../gcc/passes.c:860
#10 0x001486d4 in tree_rest_of_compilation (fndecl=0x2c49500) at ../../gcc/tree-optimize.c:419

Now to figure who is adding the REG_LABEL without updating JUMP_LABEL.
Comment 18 Andrew Pinski 2005-10-04 19:14:18 UTC
Reload is adding the REG_LABEL.
Comment 19 Andrew Pinski 2005-10-04 19:17:59 UTC
I am not going to try to fix a reload bug, sorry.
Comment 20 Andrew Pinski 2005-10-05 00:55:55 UTC
Created attachment 9888 [details]
The fix which needs to be tested

Sorry about the name of the patch but I really hate reload, Oh and this is the same fix in PR 24069 and yes I had to look into reload.
Comment 21 Andrew Pinski 2005-10-05 13:24:38 UTC
(In reply to comment #20)
> Created an attachment (id=9888) [edit]
> The fix which needs to be tested

And this patch fixes the problem too.  I will submitting it in a few minutes.
Comment 22 CVS Commits 2005-10-05 19:50:32 UTC
Subject: Bug 20606

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	pinskia@gcc.gnu.org	2005-10-05 19:50:28

Modified files:
	gcc            : ChangeLog reload.c 

Log message:
	2005-10-05  Andrew Pinski  <pinskia@physics.uc.edu>
	
	PR middle-end/20606
	PR middle-end/24069
	* reload.c (subst_reloads): When adding a REG_LABEL to a
	jump instruction, also update JUMP_LABEL.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&r1=2.10094&r2=2.10095
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reload.c.diff?cvsroot=gcc&r1=1.275&r2=1.276

Comment 23 CVS Commits 2005-10-05 19:52:20 UTC
Subject: Bug 20606

CVSROOT:	/cvs/gcc
Module name:	gcc
Branch: 	gcc-4_0-branch
Changes by:	pinskia@gcc.gnu.org	2005-10-05 19:52:14

Modified files:
	gcc            : ChangeLog reload.c 

Log message:
	2005-10-05  Andrew Pinski  <pinskia@physics.uc.edu>
	
	PR middle-end/20606
	PR middle-end/24069
	* reload.c (subst_reloads): When adding a REG_LABEL to a
	jump instruction, also update JUMP_LABEL.

Patches:
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=2.7592.2.448&r2=2.7592.2.449
http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/reload.c.diff?cvsroot=gcc&only_with_tag=gcc-4_0-branch&r1=1.268.2.1&r2=1.268.2.2

Comment 24 Andrew Pinski 2005-10-05 19:52:37 UTC
Fixed in 4.0.3.