i386-specific G++ bug
Jason Merrill
jason@cygnus.com
Sun Sep 28 11:41:00 GMT 1997
>>>>> Charles M Hannum <mycroft@mit.edu> writes:
[snip]
> After some investigation, I've found that this is because the C++
> frontend is violating the RTL interface. To wit, grokfndecl() has the
> following code:
> /* All function decls start out public; we'll fix their linkage later (at
> definition or EOF) if appropriate. */
> TREE_PUBLIC (decl) = 1;
> This causes TREE_PUBLIC() to be true for all function declarations,
> including static ones. Because the i386 port uses TREE_PUBLIC() to
> set SYMBOL_REF_FLAG(), and in turn uses SYMBOL_REF_FLAG() to decide
> how to reference a symbol, this means that all references to static
> top-level C++ functions that have been declared are compiled
> incorrectly.
[snip]
> What I'd really like to know is why the code was originally written as it
> is.
Because of things with weak linkage, like template instantiations or
virtual inlines. On targets that don't actually support weak symbols, if
we can't figure out where to put them we need to make them static, but we
can't decide on that until end of file (see import_export_* in decl2.c); we
might see an explicit instantiation or figure out where the vtable goes.
We need to do the same sort of thing on targets that support weak symbols,
but there it's a matter of weak/non-weak instead of static/public, and
that's less likely to have an impact on output patterns.
I suppose this actually isn't necessary or useful for things that are
declared static; they're never going to become public. It can only go the
other way. I'll fix it.
Jason
More information about the Gcc
mailing list