Re: [PATCH][java] Fix type problems in the Java frontend

[Richard Guenther <rguenther at suse dot de>]

On Wed, 11 Jul 2007, Tom Tromey wrote:

> >>>>> "Richard" == Richard Guenther <rguenther@suse.de> writes:
> 
> Richard> (It looks like there is funny stuff going on in the FE - it does
> Richard> the equivalent of *(T **)p with p of type (T *).  This may ask for
> Richard> trouble with aliasing.)
> 
> Yeah, there are some oddities with types.  I don't recall this one
> offhand.  Could you file it?  Or update the existing gcj "types are
> weird" PR with more info?

Do you have the PR number ready?

> Richard> 	(build_jni_stub): Likewise.  Use a comparison against zero
> Richard> 	for null-pointer test in COND_EXPR.
> 
> tree.def says that the condition in a COND_EXPR can have any type.  I
> don't really care if this changes but the documentation needs to be
> updated...

I "extrapolated" from

"In either case, the argument will be
   either zero or one.  For example, a TRUTH_NOT_EXPR will never have
   an INTEGER_TYPE VAR_DECL as its argument; instead, a NE_EXPR will be
   used to compare the VAR_DECL to zero, thereby obtaining a node with
   value zero or one.  */
DEFTREECODE (TRUTH_ANDIF_EXPR,

but in any case, the gimplifier will "fix" the COND_EXPR condition
from pointer type to (boolean) pointer, which is odd and a non-canonical
form.  (The verifier only allows conversions from pointer to integers
of same precision)

I will go through the tree documentation before submitting the
verifier again.

Thanks,
Richard.