[cfe-dev] Visibility/inlining issue in clang/libc++

[Jake Ehrlich via cfe-dev]

We're hitting an issue on Fuchsia which seems to be the result of two
problems in clang. The first one should be easy to reproduce. Simply build
libcxx with the latest clang on/for any non-mac system. I had to use
LIBCXX_ABI_VERSION=2 to make the symbol table show this symbol at all for
some reason but the issue exists regardless. If you now run `readelf -Ws
libc++.so.2 | grep
_ZNSt3__213basic_ostreamIcNS_11char_traitsIcEEElsEPFRS3_S4_E` you can see
that `std::ostream::operator<<(std::ostream& (*)(std::ostream&))` is
local/hidden. This appears to result from `-fvisibility-inlines-hidden`
being used and causing that operator to be marked as hidden. However, there
is an extern explicit template instantiation at the bottom of <ostream>
(which is actually used on non-mac systems). So the compiler should be
allowed to not inline the call if it so desires. However since libc++ does
not provide a global definition of this symbol, the linker fails if the
compiler chooses to do this.
The second issue is why the compiler is ever choosing to do this in the
first place. This is harder to reproduce and I don't have as much
information on it. When you build Fuchsia in debug mode (-Og as the
optimization level) it inlines the call to this operator in all translation
units as we would expect from any sane compiler on any optimization level
above -O0. However on non-debug builds (-O3 as the optimization level) it
does not inline this call. This seems absurd however because one would
think its just adding an extra call, passing more arguments, and increasing
code size for no good reason. I'm not an optimization person though so I
can only speculate. So -Og is somehow making a better inlining choice that
-O3 it would appear. This issue just appears to be a regression in how well
clang makes inlining decisions.
Does anyone more familiar with the compiler know where the code that
handles this is? It's currently blocking us from rolling a new toolchain on
Fuchsia.

Best,
Jake
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/cfe-dev/attachments/20180921/03e88a4c/attachment.html>