clang -O2 doesn't export the same symbols as gcc with virtual destructor

New user self-registration is disabled due to spam. For an account please email [email protected] with your e-mail address and full name.

Bug 45322 - clang -O2 doesn't export the same symbols as gcc with virtual destructor

Note You need to log in before you can comment on or make changes to this bug.

Happening on a bunch of cases here:
https://clang.debian.net/status.php?version=9.0.1&key=CHANGE_SYM_LIB

Probably not a recent issue

=== a.cpp ===
#include <stddef.h>
namespace pugi {
class xml_writer {
public:
  virtual ~xml_writer() {}
};
class a : xml_writer {
  virtual void b(const void *, size_t);
};
void a::b(const void *, size_t) {}
} // namespace pugi


=== script

ARG="  -O2 -o pugixml.cpp.o -c a.cpp"

CXX=/usr/bin/clang++
$CXX $ARG
mv pugixml.cpp.o clang.o


CXX=/usr/bin/g++-9
$CXX $ARG
mv pugixml.cpp.o gcc.o

nm clang.o |grep -q N4pugi10xml_writerD2Ev
nm gcc.o |grep -q  N4pugi10xml_writerD2Ev

===
Will show:

nm clang.o |grep N4pugi10xml_writerD2Ev
0000000000000000 W _ZN4pugi10xml_writerD2Ev
nm gcc.o |grep  N4pugi10xml_writerD2Ev

=== 
without -O2, gcc will generate the symbol too.

maybe clang should remove too when -O2 is used?

The vtable for "a" needs to refer to some function to represent its virtual destructor.  clang chooses xml_writer::~xml_writer.  gcc chooses a::~a.  I don't think the choice has any practical effect.

> I don't think the choice has any practical effect.

Probably not indeed. However, some linux distros like Debian & Ubuntu are keeping track of symbols in C/C++ libraries:
https://wiki.debian.org/UsingSymbolsFiles (for changes in ABI).

This different behavior is causing packages to fail to build when looking for the symbol list.
Maybe I could hack the tool [1] to ignore such patterns?


[1] https://manpages.debian.org/testing/dpkg-dev/dpkg-gensymbols.1.en.html

If you're looking at the set of exported symbols including inline functions, that's never going to be stable for C++ projects that aren't using something like -fvisibility-inlines-hidden.  The fundamental problem is that the compiler may or may not expose the symbols in question, depending on optimization heuristics.

The name of the destructor here is a relatively minor aspect of that.

If you want a stable result, you probably need some way to ask the compiler to dump the complete set of symbols that are odr-used in a given translation unit.  Or require that all projects use -fvisibility-inlines-hidden.