This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
RFC: adding lookups on the target names for alias attributes
- To: gcc at gcc dot gnu dot org
- Subject: RFC: adding lookups on the target names for alias attributes
- From: Greg McGary <greg at mcgary dot org>
- Date: Wed, 20 Sep 2000 18:22:04 -0700
- Cc: greg at mcgary dot org
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