This is the mail archive of the java@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: Strange, elusive bug in boolean return values with latest fetch from cvs


Tom Tromey writes:
 > >>>>> "Andrew" == Andrew Haley <aph@redhat.com> writes:
 > 
 > Andrew> The problem seems to be due to the fact that the type system of the
 > Andrew> Java Virtual Machine is subtly different from the type system of the
 > Andrew> Java Programming Language.  In particular, booleans and ints are
 > Andrew> incompatible in the source language but are both treated as integer
 > Andrew> types in the VM.
 > 
 > Yeah.  And booleans are treated as bytes for the purposes of array
 > operations.
 > 
 > Andrew> + 	  if (TREE_TYPE (node) != TREE_TYPE (decl))
 > Andrew> + 	    decl = convert (TREE_TYPE (node), decl);
 > Andrew>   	  java_add_stmt (build (MODIFY_EXPR, TREE_TYPE (node), decl, node));
 > 
 > This looks like an lvalue cast to me... sort of weird.

Yes, you're right.  It's a mistake.

 > Andrew>     type = promote_type (type);
 > Andrew> +   /* Although Java local variables may be of boolean type, the Java VM
 > Andrew> +      treats them as though they're integers.  */
 > Andrew> +   if (type == promoted_boolean_type_node)
 > Andrew> +     type = int_type_node;
 > 
 > This is curious since I would have expected promote_type() to do
 > something along these lines.  But I find I don't really understand
 > promote_type() at all -- when can BOOLEAN_TYPE and boolean_type_node
 > differ?

There are two nodes of boolean type: boolean itself, and
promoted_boolean.  One is wider than the other.  But both are
BOOLEAN_TYPE.  The thing is that most of this stuff is correct for the
Java language, but wrong for the VM.

 > Anyway, for the stack and local variables, the VM does not distinguish
 > between boolean, byte, char, short, or int.  It represents them all as
 > int.  The conversion operators are basically about masking and
 > sign-extension, and during array and field stores you simply mask off
 > the extra bits.  I don't understand all the code here that well, but I
 > would assume something similar would be needed for the char and short
 > cases.

Yes.  For those cases we have promoted_short and promoted_char.

Andrew.


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