https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64266
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
C++11 says that the address of __func__ can be the same as address of other
string literals, so I think that allows putting it into mergeable section.
But what isn't clear to me is if __func__ is used in some inline function,
if the standard allows __func__ to have different addresses between different
compilation units. Say a.h:
extern void bar (const char *);
inline void foo () { bar (__func__); }
a.C:
#include "a.h"
void bar (const char *x)
{
static const char *p;
if (p && p != x) __builtin_abort ();
p = x;
}
extern void baz ();
int
main ()
{
foo ();
baz ();
foo ();
}
b.C:
#include "a.h"
void baz ()
{
foo ();
}
Now, if you compile b.C into a shared library and a.C into executable linked
with the shared library, this will fail. If instead of bar (__func__) you use
static const char func[] = "func"; bar (func) it will presumably work fine.
So, the question is if C++ should just say that address comparisons on the
__func__ variables are undefined, or if we really need to make sure we use a
public symbol rather than private in that case.
And, for __func__ occurrences in non-inline functions, supposedly we can keep
them local and could consider using local symbols instead of the mangled names
to decrease .symtab/.strtab size. Though, perhaps that will make it harder for
users to inspect those in gdb.
