Bug 229479 - clang unused code triggers link failure
Summary: clang unused code triggers link failure
Status: New
Alias: None
Product: Base System
Classification: Unclassified
Component: bin (show other bugs)
Version: 11.2-STABLE
Hardware: Any Any
: --- Affects Some People
Assignee: freebsd-bugs mailing list
Depends on:
Reported: 2018-07-02 21:18 UTC by Adriaan de Groot
Modified: 2018-07-06 21:16 UTC (History)
1 user (show)

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Adriaan de Groot freebsd_committer 2018-07-02 21:18:26 UTC
With 11.2-STABLE, using either base clang or clang50 from ports, this C++ program compiles, but fails to link:

  #include <string>
  static std::string foop() { return std::string(); }
  int main() {
    return 0;

The error message is

[adridg@beastie]$ c++ t.cpp 
/tmp/t-0b5183.o: In function `foop()':
t.cpp:(.text+0x20): undefined reference to `std::__1::basic_string<char, std::__1::char_traits<char>, std::__1::allocator<char> >::basic_string()'
/usr/bin/ld: a.out: hidden symbol `_ZNSt3__112basic_stringIcNS_11char_traitsIcEENS_9allocatorIcEEEC2Ev' isn't defined
/usr/bin/ld: final link failed: Nonrepresentable section on output

The same problem occurs with clang50 on 11-STABLE, and with (base) clang60 on 12-CURRENT from mid-june. The program compiles and links without issue with g++6 on 11-STABLE.

Removing the line `(void)(foop);` allows the program to link; it does generate one warning about an unused function, though.

**On Linux**: The program compiles and links with clang5 and clang6 on Linux using the default C++ library (e.g. `clang++ t.cpp`). I am told that it does **not** link when using libc++ (e.g. `clang++ -stdlib=libc++ t.cpp`). I have not been able to verify that, though
Comment 1 Adriaan de Groot freebsd_committer 2018-07-03 11:01:59 UTC
Also reported upstream as https://bugs.llvm.org/show_bug.cgi?id=38029
Comment 2 Adriaan de Groot freebsd_committer 2018-07-06 09:31:43 UTC
Upstream says "Should be fixed by r336419." I think the problem was only affecting one KDE port in KDE's FreeBSD CI, so there's no immediate need to update clang.
Comment 3 Dimitry Andric freebsd_committer 2018-07-06 18:16:40 UTC
Adriaan, can we work around this particular bug in that kde port, or would it still be handy to cherry-pick the upstream fix at some point?
Comment 4 Adriaan de Groot freebsd_committer 2018-07-06 21:16:39 UTC
Let's just work around this in the KDE port -- that's no problem here right now, and has been fixed in KDE upstream already. So there's no need to cherry-pick anything, unless other parts of FreeBSD start bumping into unused but not-unreferenced code returning always_inline'd templated types.