From mboxrd@z Thu Jan  1 00:00:00 1970
From: Greg McGary <greg@mcgary.org>
To: gcc@gcc.gnu.org
Cc: greg@mcgary.org
Subject: RFC: adding lookups on the target names for alias attributes
Date: Wed, 20 Sep 2000 18:22:00 -0000
Message-id: <200009210122.SAA00879@kayak.mcgary.org>
X-SW-Source: 2000-09/msg00495.html

The target name in an alias attribute is always used verbatim and
never looked-up.  The programmer needed to explicitly mangle C++
function names, and if the alias attribute didn't name a valid program
object it was silently ineffectual, passing from compiler to
assembler, then silently ignored by the assembler.

I would like to change that, to the degree that seems reasonable,
primarily for the benefit of bounded-pointer name mangling.

For C++, it seems reasonable, though painful, to require that the
programmer explicitly mangle the target name in order to disambiguate
overloaded names.  C++ doesn't seem so important for alias attributes
though, since I don't see any uses of alias attributes in libstdc++.

I'd like to do this in decl_attributes:

1) Lookup the target name, seeking a decl with the same
   flavor (function, data, type, whatever) as the aliasing decl
   yielding a target decl.

2) If a target decl of appropriate flavor is found and is unambiguous
   (overloading in C++ being the primary source of ambiguity), use the
   target decl's DECL_ASSEMBLER_NAME as the alias target, rather than
   the programmer-supplied target string.

   If the target name is not found, is the wrong flavor, or is
   ambiguous, issue a warning and use the programmer-supplied string.
   The warning is justified because if the target remains undefined in
   the object file, then the assembler will silently ignore the alias,
   which is unexpected and sometimes confusing behavior.  It's easy
   enough to avoid the warning by placing the alias decl after the
   target's definition.  Explicitly mangled C++ names need special
   handling to avoid the warning, but I'm inclined to just let that
   slide for now since aliases seem to be seldom, if ever, used in C++.

Does that sound reasonable?

I have already implemented something like this on GCC's
bounded-pointers-branch and it's been operational and trouble-free
for months for glibc on ix86 and PowerPC.

Greg