This is the mail archive of the mailing list for the GCC 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][java] Fix type problems in the Java frontend

On Wed, 11 Jul 2007, Tom Tromey wrote:

> >>>>> "Richard" == Richard Guenther <> 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.  */

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.


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