Latest on PPC

Tue Mar 20 12:29:00 GMT 2001

>> generate_bytecode_insn - tree code not implemented: bit_field_ref
>> java/io/FilePermission.java:142: confused by earlier errors, bailing out

Anthony> I didn't think the front end generated bit_field_ref nodes by
Anthony> default. I think I saw them when compiling on PPC with -pg.
Anthony> The fix at the time was to find the switch stmt where they
Anthony> were being considered, and simply ignore them. I thought I
Anthony> had submitted this patch many months ago - but maybe not :-(
Now I get this error on x86.
fold() looks at this:
 return readPerm == p.readPerm && writePerm == p.writePerm && executePerm == p.executePerm && deletePerm == p.deletePerm;
... and decides to turn the adjacent field references into a bit field
reference. I can see how this would be more efficient: these fields
are all adjacent booleans, so if they can be merged we would end up
with a single 32-bit load per object.
Unfortunately this optimization confuses the bytecode generator. I
think unconfusing the generator isn't really an option, since it looks
like a lot of information is lost in this optimization.
I'm not really sure what to do about this.
The particular call to fold() comes from gcc/java/typeck.c:convert():
	return fold (convert_to_integer (type, expr));
I'm going to try only calling fold() when not emitting bytecode. I
have no idea whether that will help. It sure seems like a hack. But
eventually I think we'll want a Java-specific fold() anyway.
Tom