Bug 20606

Created attachment 8435 [details]
Test case

Toggling the comment on line 17 affects things.

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?

(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.

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.

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>;

This only happens with -O2.  -O is a reasonable workaround for the time being.

See also PR 21362

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.

(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.

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.

I'm surprised this still fails with 4.0.1-6.

overholt, can you reproduce this?

(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.

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.

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.

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.

Patch posted:
http://gcc.gnu.org/ml/gcc-patches/2005-10/msg00047.html

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.

Reload is adding the REG_LABEL.

I am not going to try to fix a reload bug, sorry.

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.

(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.

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

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

Fixed in 4.0.3.