PATCH: [4.1 Regression]: java compiler generates wrong code on ia64

[Bryce McKinlay]

H. J. Lu wrote:

>On Mon, Apr 18, 2005 at 03:57:47PM -0400, Bryce McKinlay wrote:
>  
>
>>>I am not familiar with Java semantics. targetm.binds_local_p will
>>>tell you if a function may be discarded at the link time or overriden
>>>by something else at the run time. If a function is public and defined
>>>within the same compilation unit, it can be discarded at the link time
>>>due to linkonce/comdat and can be overriden by dynamic linker. If it is
>>>discarded or overriden, does a local alias make any more senses for
>>>Java? It seems that
>>>
>>>if (DECL_EXTERNAL (method) || !targetm.binds_local_p (method))
>>>  return method;
>>>
>>>will make sure that an aliase will only be created when the function
>>>is defined within the compilation unit and won't be discarded or
>>>overriden.
>>>
>>>
>>>      
>>>
>>Well, this is certainly the behaviour we would like for Java, but AFAIK 
>>we have no way to ensure that something always binds locally.
>>
>>binds_local_p is described as:
>>
>> /* True if EXP names an object for which name resolution must resolve
>>    to the current module.  */
>>
>>It seems to me that, given ELF semantics, a public symbol can always be 
>>overriden by the linker at runtime, thus targetm.binds_local_p will 
>>always be false? If there was some way to force targetm.binds_local_p 
>>then we wouldn't need make_local_function_alias()!
>>
>>    
>>
>
>
>A public symbol can be overriden by the dynamic linker at runtime
>unless it is internal, hidden or protected. If you don't need to export
>it outside of the module, you can mark it hidden. If you have to export
>it outside of the module, you can mark it protected.
>  
>

Currently, ALL the symbols for Java methods need to be visible outside 
the module. This is because of both a) the need for compatibility with 
the C++ ABI for CNI (CNI allows "private" Java methods to be called from 
C++), and b) continued support for the "old" C++ ABI for Java code.

Using protected symbols everywhere would carry significant overhead, 
apparently - see http://gcc.gnu.org/ml/java-patches/2005-q1/msg00201.html

Bryce