PATCH: [4.1 Regression]: java compiler generates wrong code on ia64
H. J. Lu
hjl@lucon.org
Mon Apr 18 19:34:00 GMT 2005
On Mon, Apr 18, 2005 at 12:16:10PM -0700, H. J. Lu wrote:
> On Mon, Apr 18, 2005 at 03:03:02PM -0400, Bryce McKinlay wrote:
> > H. J. Lu wrote:
> >
> > >>The function pointers in the GCJ method metadata (_Jv_Method) are always
> > >>local, except in the case of CNI functions. But, even local function
> > >>references in a .so will point at PLT entries if the function is also
> > >>referenced from the main binary.
> > >>
> > >>
> > >
> > >Whan you said "local function", did you mean
> > >
> > >1. A local data variable with function type. Or
> > >2. A function symbol which isn't visible to the outside. Or
> > >3. A global data variable with function type pointing to a local
> > >function.
> > >
> > >I ran into a very tricky issue. But I don't have a testcase. This
> > >problem may be related.
> > >
> > >
> > I mean "a reference to a function which is public (visible to the
> > outside) and defined within the same compilation unit"
>
> That makes senses now. For me, "local function" means a different
> thing :-). If you want to know if a function will be bound locally
> at the run time, you should use targetm.binds_local_p. I think this
> patch is correct.
>
>
> H.J.
> ---
> 2005-04-18 H.J. Lu <hongjiu.lu@intel.com>
>
> PR java/21070
> * class.c (make_local_function_alias): Use targetm.binds_local_p
> to check if a function is bound locally.
>
Second thought. Since you can only create an aliase for a symbol
defined within the same file, targetm.binds_local_p alone may not be
suitable for this purpose.
H.J.
More information about the Java-patches
mailing list