Bug 229479

Summary: clang unused code triggers link failure
Product: Base System Reporter: Adriaan de Groot <adridg>
Component: binAssignee: freebsd-bugs (Nobody) <bugs>
Status: Closed Overcome By Events    
Severity: Affects Some People CC: dim
Priority: ---    
Version: 11.2-STABLE   
Hardware: Any   
OS: Any   

Description Adriaan de Groot freebsd_committer freebsd_triage 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() {
    (void)(foop);
    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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 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 freebsd_triage 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.
Comment 5 Adriaan de Groot freebsd_committer freebsd_triage 2019-09-23 16:51:18 UTC
Given the march of time and clang versions -- with clang 8 in base on 12 and a later clang 6 in 11 as far as I know -- we can close this one. (Leaving that up to the assignee though)
Comment 6 Adriaan de Groot freebsd_committer freebsd_triage 2019-12-17 10:38:43 UTC
The affected clang versions are no longer in use.