Re: Latest on PPC

[Tom Tromey <tromey at redhat dot com>]

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