This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: Basic Improvements Branch Bootstrap Failure Analysis
- From: Jan Hubicka <jh at suse dot cz>
- To: Roger Sayle <roger at eyesopen dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Thu, 10 Oct 2002 10:17:56 +0200
- Subject: Re: Basic Improvements Branch Bootstrap Failure Analysis
- References: <Pine.LNX.4.33.0210092306360.24537-100000@www.eyesopen.com>
>
> The gcc-3_4-basic-improvements-branch has been failing to bootstrap
> on i686-pc-linux-gnu for a few days, so I decided to investigate
> whether I could shed any light on the problem.
>
> The failure is an ICE in libjava building ObjectInputStream.java
> /home/roger/ObjectInputStream.java:41: error: Attempt to delete
> prologue/epilogue insn:
> (insn 552 551 553 27 (nil) (set (reg:SI 5 edi)
> (mem:SI (plus:SI (reg/f:SI 6 ebp)
> (const_int -4 [0xfffffffc])) [0 S4 A8])) -1 (nil)
> (nil))
> /home/roger/ObjectInputStream.java:41: internal compiler error: in
> propagate_one_insn, at flow.c:1634
This looks strange as this seems to be epilogue instruction
(prologue does not read memory) and liveness in epilogue should be
really trivial.
>
> This disables the cross-jumping optimization in cfg_cleanup during
> the "flow2" pass. This change is sufficient to allow the b-i-b
Seeing the dump would be very usefull, OK I wll start the build.
> branch to bootstrap again on i686-pc-linux-gnu.
>
> My hypothesis is that the bug is either in cleanup_cfg's
> cross-jumping or cross-jumping's interaction with updating
> life information. Its quite clear from the example that several
> of the edges in this routine are EH edges, which may possibly be
> being incorrectly cross-jumped. This then leads to the attempt
> to delete the prologue/epilogue instruction. Of course, I
> could be completely wrong (i.e. the RTL may be invalid prior
> to .java.25.flow2).
>
> Unfortunately, I don't speak much Java so I can't tell if
> the fact that callReadMethod throws a RuntimeException is a
> contributing factor (the declaration only lists IOException).
>
>
> I'll continue to dig deeper, but I thought I'd share what I'd
> discovered so far to (i) help anyone else already looking into
> this and (ii) perhaps attract the attention of Jan and RTH who
You can CC me next time ;))
I will try to reproduce the failure here.
Honza
> best understand this part of the compiler.
>
> Roger
> --
> Roger Sayle, E-mail: roger@eyesopen.com
> OpenEye Scientific Software, WWW: http://www.eyesopen.com/
> Suite 1107, 3600 Cerrillos Road, Tel: (+1) 505-473-7385
> Santa Fe, New Mexico, 87507. Fax: (+1) 505-473-0833