Re: Java: fix Array_3 byte compiler failures

[Andrew Haley <aph at redhat dot com>]

Per Bothner writes:
 > Andrew Haley wrote:
 > 
 > > The type of '(Object[])null' is 'Object[]' -- the NOP_EXPR is stripped
 > > off, but the type of the pointer is definitely set correctly.  But the
 > > issue here isn't generating incorrect bytecode, because the bytecode
 > > is legal, I'm sure of that.
 > 
 > Well, somebody is stripping off the type before it gets to
 > build_java_array_length_access, or else your patch would have
 > no effect.  My point is:  If the type of the argument to
 > build_java_array_length_access is pointer_type_node then
 > I think that indicates a bug before we get that far.

How could it be otherwise?  aconst_null doesn't push an array type.

 > In your initial posting you said that:
 >    aconst_null
 >    arraylength
 > is valid bytecode.
 > 
 > I don't believe it is; javac generates from
 >    ((Object[] null).length
 > the following
 >    aconst_null
 >    checkcast #9=<Class [Ljava.lang.Object;>
 >    arraylength
 > 
 > I.e. somewhere you're losing type information,
 > and your patch is fixing the symptom, not the bug.

I disagree.  Although javac generates checkcast instructions for this
case, the runtime verifier accepts code without them, and the JVM spec
says that it should do so.

[BTW, the first patch I wrote did indeed change things so that the
bytecode contained the checkcast -- but I rejected that patch because
I decided it was fixing the symptom, not the bug!]

Andrew.