Re: f build dies with: undefined reference to `lookup_name'

[Geoff Keating <geoffk at geoffk dot org>]

> Date: Fri, 15 Mar 2002 11:26:41 +1030
> From: Alan Modra <amodra@bigpond.net.au>

> On Thu, Mar 14, 2002 at 06:24:04PM -0500, David Edelsohn wrote:
> > 
> > 	I think a better approach may be to turn lookup_name into a
> > lang_hook because we still need to distinguish between the different
> > languages for that anyway.
> > 
> > 	I am going to roll this back and follow that path.
> 
> IMO adding these hooks isn't improving matters at all.  The major
> problem with the code as of a day or so ago was the call to lookup_decl
> from varasm.c.  The patch I posted at
> http://gcc.gnu.org/ml/gcc-patches/2002-03/msg00308.html cures this, and
> also addresses the problem rth mentioned in
> http://gcc.gnu.org/ml/gcc-patches/2002-03/msg00298.html

OK, we have two proposals, both of which I've looked at and I think I
understand:

- David's (revised) proposal, which is to add an extra lang_hook to
  allow varasm.c to call into the language backends to do name lookup;
and
- Alan Modra's proposal, which moves the initial name lookup to the
  backends, and provides a routine in varasm.c which backends can call
  before creating a decl to see if they should mark the decl weak.

Now, I have two comments about these that makes me think neither is
the final answer, although they both represent progress.

Firstly, how do these work in C++?  In particular, if I write

void bar(void);
namespace foo {
#pragma weak bar
  extern void bar(void);
  struct c {
    void bar(void);
  };
}
namespace bat {
  extern void bar(void);
}
void doit(void)
{
  struct foo::c cc;
  bar();
  foo::bar();
  cc.bar();
  bat::bar();
}

do I get foo::bar weak, ::bar weak, everything named 'bar' weak, or
something else?  I believe the correct thing is to have foo::bar,
only, be weak.  The current compiler seems to make 
'extern "C" bar' weak, which indicates (at least to me) that no-one
thought about this at all :-).  I believe that Alan's patch will
change this behaviour in an improving direction, but I think from the
description it will pick ::bar, because ::bar's decl is visible at the
point of the pragma under the name 'bar'.

[It's this question that makes me think that the code should really be
part of a language backend.  Anything that can't work right for both C
and C++ is clearly so language-specific that it probably doesn't make
any sense at all for, say, Ada, and so it's not surprising that
there are compile errors.]


Secondly, why is this particular code in varasm.c at all?  I liked
what David originally tried to do by moving it out (to c-common.c?),
but I think it will require at least part of Alan's patch to avoid the
problems that David hit.

The reason I ask this question is that in some other languages, you
can do this sort of thing in a more organized fashion by writting
things like

attribute bar weak;
attribute bar watched, synchronized;
...
type bar procedure;

and so on, and those languages wouldn't be able to use this mechanism;
it's very specialized for the C languages, and so I would think it
should be somewhere like c-common.

-- 
- Geoffrey Keating <geoffk@geoffk.org> <geoffk@redhat.com>