This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: patch/RFC/RFT detect ICE in libjava testsuite
- From: Tom Tromey <tromey at redhat dot com>
- To: Janis Johnson <janis187 at us dot ibm dot com>
- Cc: java-patches at gcc dot gnu dot org, ddaney at avtrex dot com
- Date: 15 May 2006 08:29:53 -0600
- Subject: Re: patch/RFC/RFT detect ICE in libjava testsuite
- References: <20060512231635.GA7197@us.ibm.com>
- Reply-to: tromey at redhat dot com
>>>>> "Janis" == Janis Johnson <janis187@us.ibm.com> writes:
Janis> This isn't fully tested yet, but I wanted to check on my approach for
Janis> reporting internal compiler errors in the libjava testsuite.
Nice.
Janis> I modified bytecompile_file so that instead of returning 0 for fail,
Janis> 1 for success, it now returns 0 for success, 1 for failure, 2 for
Janis> failure with "internal compiler error" in the compiler output.
I wish the gcc driver gave a different exit status in this situation.
Grepping for text in the output is not very i18n-friendly :-(
Janis> Since I don't have a libjava test that ICEs, I don't even know
Janis> if that's the string gcj uses, or whether it's appropriate to
Janis> look for it from bytecompile_file as well as from
Janis> libjava_tcompile.
It is the string we use; gcj reuses the gcc driver here.
I do think you want to check in libjava_tcompile as well.
bytecompile_file is only used for the source->class compilation, so
this patch will only catch ICEs there. However, sometimes translation
to object code may ICE when translation to class file does not.
Janis> Am I on the right track?
Yes.
Janis> + if { $ice != 0 } {
Janis> + fail "$errname compilation from source (internal compiler error)"
Generally speaking we try to keep the test messages the same no matter
what happens. For things like this, it is better to log a message
about the ICE using send_log or verbose and keep the 'fail' argument
the same.
Tom