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: gcj producing bad code


Nic Ferrier wrote:
>>>GCJ is not compiling method calls quite right... it seems that all 
>>>super invocations are done through invokespecial. invokespecial 
>>>cannot be used when the target needs to be called through virtual 
>>>dispatch however. 
>>
>> 
>>I'm not quite sure you said that right.  Any call to super.method() is 
>>required to compile to invokespecial (unless method is static, in which 
>>case invokestatic is appropriate).  By the way, in the case of 
>>EnclosingClass.super.method(), it may require the assistance of an 
>>accessor method to use invokespecial while still obeying access rules.  
>>Consider this example, from the point of view of class C: 
> 
> 
> The case I'm referring to is a metjod invocation on a property of the
> super class, thus:
> 
>   class A
>    X x;
>    public X getX() { return x; }
> 
> 
>   class B extends A
>    public Y getY() { return super.getX().getY(); }
> 
> 
> The method B::getY() must compile to call getY() through a virtual
> dispatch even though X is in super.

The getY() isn't a super invocation - it's the same as
   (super.getX()).getY()
or even:
   X t = super.getX();
   return t.getY();

If we're emitting invokespecial to call getY, then I don't think
the flaw in actually in the bytecode-generation, but more likely
the front-end (resolve_qualified_expression_name in parse.y)
incorrectly setting CALL_WITH_SUPER.

I suspect the problem is that the variable 'from_super' isn't
being reset in resolve_qualified_expression_name.  Alex?
-- 
	--Per Bothner
per@bothner.com   http://www.bothner.com/per/


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