This is the mail archive of the java-patches@gcc.gnu.org mailing list for the Java project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Patch: PR java/20031 - ICE on missing files


-----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-----


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]