This is the mail archive of the
java-patches@gcc.gnu.org
mailing list for the Java project.
Re: Patch: PR java/20031 - ICE on missing files
- From: Ranjit Mathew <rmathew at gmail dot com>
- To: Andrew Haley <aph at redhat dot com>
- Cc: GCJ Patches <java-patches at gcc dot gnu dot org>, GCC Patches <gcc-patches at gcc dot gnu dot org>
- Date: Fri, 09 Sep 2005 18:33:21 +0530
- Subject: Re: Patch: PR java/20031 - ICE on missing files
- Openpgp: url=http://ranjitmathew.hostingzero.com/aa_6C114B8F.txt
- References: <43215F24.5090108@gmail.com> <17185.33432.656250.529509@zapata.pink>
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Andrew Haley wrote:
> Ranjit Mathew writes:
[...]
> >
> > The contentious bit would probably be my proposal to use
> > TYPE_DUMMY on a RECORD_TYPE node to indicate a failed
> > loading of the class, even in the non-indirect-dispatch
> > case when VERBOSE is true and to use this to not bother
> > to lay out a class's methods if it failed loading.
> >
> > As I understand it, VERBOSE is set to 1 for load_class()
> > when we expect the class to be found and consider it an
> > error if it is not. In this case, if the class failed
> > loading, there does not seem to be any hope of finding it
> > later and therefore it is better to "poison" the RECORD_TYPE
> > denoting the class. I would like to know if this assumption
> > is invalid.
[...]
> >
> > OK for mainline?
>
> I can't say it fills me with happiness. Is there really no better way
> to do this than to (ab)use TYPE_DUMMY ? OK, if you really want to do
> this go ahead, but at least add some commentary to the effect that
> when compiling without indirect dispatch this really is a fatal error,
> but we're continuing in case we need to generate further disgnostics.
I don't wish to push this patch through unnecessarily. A much simpler
fix would be to turn that error() into a fatal_error(), but then we
lose out on further diagnostics as you point out. A better fix would
perhaps be to make load_class() return a status code (success/error)
that the caller can check to see if it makes sense to proceed with
the class or not.
The problem with just a return code is that if we retain that
RECORD_TYPE node and use it elsewhere in the compiler, those
parts also need to know that it is merely a placeholder and
the respective class was not found. We need some way of percolating
this information and hence my (ab)use of TYPE_DUMMY.
By the way, there are several:
if (!CLASS_LOADED_P (foo))
load_class (foo, 1);
fragments throughout the front-end that should be updated to check
the status of that load_class().
Ranjit.
- --
Ranjit Mathew Email: rmathew AT gmail DOT com
Bangalore, INDIA. Web: http://ranjitmathew.hostingzero.com/
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.2 (MingW32)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
iD8DBQFDIYgZYb1hx2wRS48RAvrjAKCgKbyDCk1cIOufQloXJsrZ+wFeXACgqUKI
xq6jP7ETXARE8AuRUz+429U=
=hoNQ
-----END PGP SIGNATURE-----