This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
PATCH: Re: gcj non-optimization curiosity
- From: Andrew Haley <aph at cambridge dot redhat dot com>
- To: Bryce McKinlay <bryce at waitaki dot otago dot ac dot nz>
- Cc: tromey at redhat dot com, java-patches at gcc dot gnu dot org,gcc-patches at gcc dot gnu dot org
- Date: Mon, 17 Dec 2001 09:51:22 +0000 (GMT)
- Subject: PATCH: Re: gcj non-optimization curiosity
- References: <87vgf628c4.fsf@creche.redhat.com><3C1D723A.7000803@waitaki.otago.ac.nz>
Bryce McKinlay writes:
>
> When explicit null pointer checks got added (for MMU-less targets),
> calls to java_check_reference were introduced with the
> flag_check_references argument. But for some reason - presumably a
> mistake - the check that occurs during array bounds checks uses "1"!
If I recall correctly, the explicit pointer check was there before --
but commented out for some reason -- and when the explicit null
pointer checks were added that behavour wasn't left in.
> I guess that with the java_check_reference the optimizer could not
> eliminate the check because it doesn't know that "new" can never return
> null, but why it couldn't move it out of the loop is a mystery!
I presume that NullPointerException will be thrown in the right place
even without the check. I must say that I'd be very interested to
know why the check isn't being hoisted out of the loop, though. I
guess the answer is that our loop optimizer needs some more attention.
Andrew.