Bug 40105 - [4.3/4.4 Regression] SH: 4.3/4.4 compilers segfault when recompiling itself on gentoo system
Summary: [4.3/4.4 Regression] SH: 4.3/4.4 compilers segfault when recompiling itself o...
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: rtl-optimization (show other bugs)
Version: unknown
: P4 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords: wrong-code
Depends on: 40710
Blocks:
  Show dependency treegraph
 
Reported: 2009-05-11 17:54 UTC by Raúl Porcel
Modified: 2009-07-10 10:39 UTC (History)
3 users (show)

See Also:
Host: sh4-unknown-linux-gnu
Target: sh4-unknown-linux-gnu
Build: sh4-unknown-linux-gnu
Known to work: 4.1.2 4.5.0
Known to fail: 4.3.2 4.3.3 4.4.0
Last reconfirmed: 2009-05-12 22:37:54


Attachments
a test case (327 bytes, text/plain)
2009-05-13 14:07 UTC, Kazumoto Kojima
Details
A patch (2.56 KB, patch)
2009-05-14 00:12 UTC, Kazumoto Kojima
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Raúl Porcel 2009-05-11 17:54:55 UTC
Since gcc-4.3 I'm unable to rebuild gcc, please check the downstream bug: http://bugs.gentoo.org/show_bug.cgi?id=267247

As pointed out there, it compiles with gcc-4.1.2, but after upgrading to gcc-4.3, switching to that compiler, and recompiling itself, it segfaults.

sh4-unknown-linux-gnu-gcc   -O -DIN_GCC   -W -Wall -Wwrite-strings
-Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition
-Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros       
                          -Wno-overlength-strings -fno-common   -DHAVE_CONFIG_H
-Wl,-O1 -o xgcc gcc.o opts-common.o gcc-options.o gccspec.o \
          intl.o prefix.o version.o  ../libcpp/libcpp.a  
../libiberty/libiberty.a ../libdecnumber/libdecnumber.a
/var/tmp/portage/sys-devel/gcc-4.3.3-r2/work/build/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-4.3.3-r2/work/build/./gcc/
-B/usr/sh4-unknown-linux-gnu/bin/ -B/usr/sh4-unknown-linux-gnu/lib/ -isystem
/usr/sh4-unknown-linux-gnu/include -isystem
/usr/sh4-unknown-linux-gnu/sys-include -dumpspecs > tmp-specs
/bin/sh: line 1:  9859 Segmentation fault     
/var/tmp/portage/sys-devel/gcc-4.3.3-r2/work/build/./gcc/xgcc
-B/var/tmp/portage/sys-devel/gcc-4.3.3-r2/work/build/./gcc/
-B/usr/sh4-unknown-linux-gnu/bin/ -B/usr/sh4-unknown-linux-gnu/lib/ -isystem
/usr/sh4-unknown-linux-gnu/include -isystem
/usr/sh4-unknown-linux-gnu/sys-include -dumpspecs > tmp-specs
make[3]: *** [specs] Error 139
make[3]: Leaving directory

Let me know if you need more info
Comment 1 Kazumoto Kojima 2009-05-12 00:43:53 UTC
Your compilers are the gentoo special versions, aren't they?
If so, you should try the original FSF compiler sources for both
build/target compilers.  See http://gcc.gnu.org/bugs.html#dontwant.
FSF 4.3/4.4 release compilers are bootstraped without problems
on sh4-unknown-linux-gnu for me. 
Only I can say from the log in #1 is that your xgcc driver looks
to segfault with -dumpspecs option.  Since it doesn't happen with
your gcc-4.1.2, it seems that your 4.3 compiler miscompiles something
for xgcc.  If it's the case, you can bisect the problem with
replacing objects and libraries for xgcc with those compiled by
your 4.1.2 compiler.
Comment 2 Raúl Porcel 2009-05-12 17:27:06 UTC
(In reply to comment #1)
> Your compilers are the gentoo special versions, aren't they?
Nope, there's no patch applied in this case. If you meant that we don't 'make bootstrap-lean && make install', yes.

> If so, you should try the original FSF compiler sources for both
> build/target compilers.  See http://gcc.gnu.org/bugs.html#dontwant.
> FSF 4.3/4.4 release compilers are bootstraped without problems
> on sh4-unknown-linux-gnu for me. 
> Only I can say from the log in #1 is that your xgcc driver looks
> to segfault with -dumpspecs option.  Since it doesn't happen with
> your gcc-4.1.2, it seems that your 4.3 compiler miscompiles something
> for xgcc.  If it's the case, you can bisect the problem with
> replacing objects and libraries for xgcc with those compiled by
> your 4.1.2 compiler.
> 

Can you build gcc-4.3.3 using gcc-4.3.3 and with the following command?
make -j3 LDFLAGS=-Wl,-O1 STAGE1_CFLAGS=-O 'BOOT_CFLAGS= -O2 -pipe'
bootstrap-lean

Not sure if you saw what i said on #4.

Anyway, i'll try a more "cleaner" way, but in that case this bug can't be here. Can you try with the command i pasted?

Thanks
Comment 3 Kazumoto Kojima 2009-05-12 22:37:51 UTC
Ah, now I understand the issue and find that what we need
in the bug report http://gcc.gnu.org/bugs.html#need is in
http://bugs.gentoo.org/show_bug.cgi?id=267247.  Next time,
please give the minimal information to reproduce the problem
in the bug report itself, not in some URL.
The real problem will be the wrong code problem with -O1
for 4.3 compiler on SH, rather than a bootstrap problem.  It
might be very hard to solve, though.  Perhaps we can find what
part of the compiler is miscompiled with the 4.3 compiler
with -O by replacing gcc/*.o objects compiled with -O2.
Even if we can detect a problematic .o, it will be very
large and it'd be difficult to get an appropriate test case
which is wrongly compiled with -O.  We can't go forward
without such a test case.
Comment 4 Kazumoto Kojima 2009-05-13 14:07:34 UTC
Created attachment 17857 [details]
a test case

I've got a small test case from libiberty/concat.c.
With -O1, 4.3 compiles vconcat_length to the codes below:

	...
.L5:
	jsr	@r12		! Call strlen
	nop
	add	r0,r9
	mov.l	@r8,r4
	mov	r4,r2
	add	#4,r2
	mov.l	@(4,r8),r1
	cmp/hs	r2,r1
	bt/s	.L4
	mov	r8,r2
	mov.l	@(16,r8),r4
	mov	r13,r2
.L4:
	mov	r4,r1
	add	#4,r1
	mov.l	r1,@r2
	mov.l	@r4,r4
	tst	r4,r4
	bf/s	.L5
	mov	r9,r4		!!!
	mov.l	.L17,r0
	jsr	@r0		! Call malloc.
	...

i.e. the delayed branch optimization fills a delay slot
with an inappropriate instruction at the line !!!.
I've confirmed that the 4.4 compiler's output is similar
and the outputs for 4.2 and 4.5 look correct even with -O.
I have no idea for what is going on ATM, though.
Comment 5 Kazumoto Kojima 2009-05-14 00:12:23 UTC
Created attachment 17860 [details]
A patch

A binary search on trunk shows me that the patch in r146829 and
its follow-up r146988 fix the issue.
See http://gcc.gnu.org/ml/gcc-patches/2009-04/msg02097.html for
r146829 changes.
With these patches, 4.3 compiler emits "bf .L5" instead of "bf/s .L5"
even with -O1.  So it seems that this is an rtl-optimization issue
which is fixed on trunk recently.
I'm not sure about the backport to the release branches because
that patch is originally for PR 34415 which was also a mips 4.3
regression and solved only on the trunk (4.4 at that moment).
I've attached an r146829+r146988 patch tuned for gcc-4_3-branch.
Could you try it?
Comment 6 Raúl Porcel 2009-05-18 16:29:11 UTC
Sorry for taking a while, but i'm pretty sure you know sh machines are kinda of slow :)

Yes! it works!

Thank you for investigating it
Comment 7 Kazumoto Kojima 2009-05-18 23:41:50 UTC
Thanks for confirmation!  I'll ask if the r146829 patch is safe
to backport for 4.[34] branches in the gcc list, after the tests
on x86 and powerpc.
Comment 8 Kazumoto Kojima 2009-05-21 23:17:53 UTC
Subject: Bug 40105

Author: kkojima
Date: Thu May 21 23:17:37 2009
New Revision: 147780

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147780
Log:
	PR rtl-optimization/40105
	Backport from mainline:

	2009-04-29  Eric Botcazou  <ebotcazou@adacore.com>
		    Steven Bosscher  <steven@gcc.gnu.org>

	* Makefile.in (cfgrtl.o): Add $(INSN_ATTR_H).
	* cfgrtl.c: Include insn-attr.h.
	(rest_of_pass_free_cfg): New function.
	(pass_free_cfg): Use rest_of_pass_free_cfg as execute function.

	2009-04-27  Richard Sandiford  <rdsandiford@googlemail.com>
		    Eric Botcazou  <ebotcazou@adacore.com>

	* resource.c (find_basic_block): Use BLOCK_FOR_INSN to look up
	a label's basic block.
	(mark_target_live_regs): Tidy and rework obsolete comments.
	Change back DF problem to LIVE.  If a label starts a basic block,
	assume that all registers that used to be live then still are.
	(init_resource_info): If a label starts a basic block, set its
	BLOCK_FOR_INSN accordingly.
	(free_resource_info): Undo the setting of BLOCK_FOR_INSN.


Modified:
    branches/gcc-4_4-branch/gcc/ChangeLog
    branches/gcc-4_4-branch/gcc/Makefile.in
    branches/gcc-4_4-branch/gcc/cfgrtl.c
    branches/gcc-4_4-branch/gcc/resource.c

Comment 9 Kazumoto Kojima 2009-05-21 23:31:55 UTC
Subject: Bug 40105

Author: kkojima
Date: Thu May 21 23:31:44 2009
New Revision: 147781

URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=147781
Log:
	PR rtl-optimization/40105
	Backport from mainline:

	2009-04-29  Eric Botcazou  <ebotcazou@adacore.com>
		    Steven Bosscher  <steven@gcc.gnu.org>

	* Makefile.in (cfgrtl.o): Add $(INSN_ATTR_H).
	* cfgrtl.c: Include insn-attr.h.
	(rest_of_pass_free_cfg): New function.
	(pass_free_cfg): Use rest_of_pass_free_cfg as execute function.

	2009-04-27  Richard Sandiford  <rdsandiford@googlemail.com>
		    Eric Botcazou  <ebotcazou@adacore.com>

	* resource.c (find_basic_block): Use BLOCK_FOR_INSN to look up
	a label's basic block.
	(mark_target_live_regs): Tidy and rework obsolete comments.
	Change back DF problem to LIVE.  If a label starts a basic block,
	assume that all registers that used to be live then still are.
	(init_resource_info): If a label starts a basic block, set its
	BLOCK_FOR_INSN accordingly.
	(free_resource_info): Undo the setting of BLOCK_FOR_INSN.


Modified:
    branches/gcc-4_3-branch/gcc/ChangeLog
    branches/gcc-4_3-branch/gcc/Makefile.in
    branches/gcc-4_3-branch/gcc/cfgrtl.c
    branches/gcc-4_3-branch/gcc/resource.c

Comment 10 Kazumoto Kojima 2009-05-21 23:36:30 UTC
Fixed.