[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 Jonathan Wakely changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #21 from Jonathan Wakely --- Should be fixed now, for 9.3 and 10.1
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 --- Comment #20 from Jonathan Wakely --- Author: redi Date: Thu Aug 29 13:22:13 2019 New Revision: 275033 URL: https://gcc.gnu.org/viewcvs?rev=275033=gcc=rev Log: PR libstdc++/91067 add more missing exports for directory iterators PR libstdc++/91067 * acinclude.m4 (libtool_VERSION): Bump to 6:28:0. * configure: Regenerate. * config/abi/pre/gnu.ver (GLIBCXX_3.4.28): Add new version. Export missing symbols. * testsuite/27_io/filesystem/iterators/91067.cc: Test move constructors. * testsuite/util/testsuite_abi.cc: Add new symbol version. Modified: branches/gcc-9-branch/libstdc++-v3/ChangeLog branches/gcc-9-branch/libstdc++-v3/acinclude.m4 branches/gcc-9-branch/libstdc++-v3/config/abi/pre/gnu.ver branches/gcc-9-branch/libstdc++-v3/configure branches/gcc-9-branch/libstdc++-v3/testsuite/27_io/filesystem/iterators/91067.cc branches/gcc-9-branch/libstdc++-v3/testsuite/util/testsuite_abi.cc
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 --- Comment #19 from Jonathan Wakely --- Author: redi Date: Thu Aug 29 12:16:27 2019 New Revision: 275032 URL: https://gcc.gnu.org/viewcvs?rev=275032=gcc=rev Log: PR libstdc++/91067 add more missing exports for directory iterators PR libstdc++/91067 * acinclude.m4 (libtool_VERSION): Bump to 6:28:0. * configure: Regenerate. * config/abi/pre/gnu.ver (GLIBCXX_3.4.28): Add new version. Export missing symbols. * testsuite/27_io/filesystem/iterators/91067.cc: Test move constructors. * testsuite/util/testsuite_abi.cc: Add new symbol version. Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/configure trunk/libstdc++-v3/testsuite/27_io/filesystem/iterators/91067.cc trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 Jonathan Wakely changed: What|Removed |Added CC||rafael at espindo dot la --- Comment #18 from Jonathan Wakely --- *** Bug 91516 has been marked as a duplicate of this bug. ***
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 Jonathan Wakely changed: What|Removed |Added Target Milestone|9.2 |9.3
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 --- Comment #17 from Viktor Ostashevskyi --- Ok, got following today with GCC 9.2 with "-O2 -fno-inline -flto=20": ld.bfd: /tmp/tests.oKru4z.ltrans32.ltrans.o: in function `std::__shared_ptr::operator=(std::__shared_ptr&&)': c++/9.2.0/bits/shared_ptr_base.h:1265: undefined reference to `std::__shared_ptr::__shared_ptr(std::__shared_ptr&&)' Code base is huge, so it is hard to minimize test case. Even not sure whether LTO or libstdc++ is guilty.
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 --- Comment #16 from Jonathan Wakely --- Except -O0, which is what I find surprising.
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 --- Comment #15 from Viktor Ostashevskyi --- (In reply to Jonathan Wakely from comment #14) > I can reproduce the link failure. For some reason Clang requires that > constructor at -O1, but not at any other optimization level. It will require it at any -O level with fno-inline.
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 Jonathan Wakely changed: What|Removed |Added Keywords||link-failure Status|RESOLVED|REOPENED Resolution|FIXED |--- --- Comment #14 from Jonathan Wakely --- I can reproduce the link failure. For some reason Clang requires that constructor at -O1, but not at any other optimization level.
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 --- Comment #13 from Viktor Ostashevskyi --- (In reply to Jonathan Wakely from comment #12) > I didn't export that because nothing should need it. Nothing in libstdc++ > derives from __shared_ptr<_Dir> and nothing in user code is allowed to refer > to that type, because it's an implementation detail. > > The explicit instantiation tells Clang not to emit that constructor, but it > shouldn't cause it to depend on that constructor. Well, Clang emits call to C2 version somehow. Should it be reported as a but to Clang?
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 --- Comment #12 from Jonathan Wakely --- I didn't export that because nothing should need it. Nothing in libstdc++ derives from __shared_ptr<_Dir> and nothing in user code is allowed to refer to that type, because it's an implementation detail. The explicit instantiation tells Clang not to emit that constructor, but it shouldn't cause it to depend on that constructor.
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 --- Comment #11 from Viktor Ostashevskyi --- I assume that problem comes from explicit instantiation: extern template class __shared_ptr; which was added in c8fb3443911413cc88f316305fc6b7bf4861ccaa. It prevent Clang in emitting "C2" version of constructors on its own.
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067
Viktor Ostashevskyi changed:
What|Removed |Added
CC||ostash at ostash dot kiev.ua
--- Comment #10 from Viktor Ostashevskyi ---
What about "base object constructors" (mangled with C2)?
For simple case like:
---
#include
#include
int main(int argc, char** argv)
{
for (const auto& dirElem : std::filesystem::directory_iterator(argv[1]))
std::cout << dirElem.path().filename() << '\n';
}
---
When compiling with Clang 8 against libstdc++ from GCC 9.2.0 I got:
in function
`std::filesystem::directory_iterator::directory_iterator(std::filesystem::directory_iterator&&)':
fs.cpp:(.text._ZNSt10filesystem18directory_iteratorC2EOS0_[_ZNSt10filesystem18directory_iteratorC2EOS0_]+0x1):
undefined reference to `std::__shared_ptr::__shared_ptr(std::__shared_ptr&&)'
Checking in libstdc++.so showed that symbols are exported, but only for
complete object constructor:
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC1EOS5_
Not sure why, but Clang emits call to base object constructor:
_ZNSt12__shared_ptrINSt10filesystem7__cxx114_DirELN9__gnu_cxx12_Lock_policyE2EEC2EOS5_
I've checked Clang8 vs libstdc++ from GCC 8.3.0 and see that it emits calls to
same base object ctor, but its definition is also emitted, so no linker error
occur.
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 Jonathan Wakely changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jonathan Wakely --- Fixed on trunk and for GCC 9.2, thanks for finding and reporting the bug!
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 --- Comment #8 from Jonathan Wakely --- Author: redi Date: Wed Jul 3 21:09:13 2019 New Revision: 273025 URL: https://gcc.gnu.org/viewcvs?rev=273025=gcc=rev Log: PR libstdc++/91067 fix missing exports for filesystem iterators The copy assignment operator for recursive_directory_iterator was not exported despite being needed. The __shared_ptr default constructors are not needed when compiling with GCC but Clang requires them for -O1. PR libstdc++/91067 * acinclude.m4 (libtool_VERSION): Bump to 6:27:0. * configure: Regenerate. * config/abi/pre/gnu.ver (GLIBCXX_3.4.27): Add new version. Export missing symbols. * testsuite/27_io/filesystem/iterators/91067.cc: New test. * testsuite/util/testsuite_abi.cc: Add new symbol version. Added: branches/gcc-9-branch/libstdc++-v3/testsuite/27_io/filesystem/iterators/91067.cc Modified: branches/gcc-9-branch/libstdc++-v3/ChangeLog branches/gcc-9-branch/libstdc++-v3/acinclude.m4 branches/gcc-9-branch/libstdc++-v3/config/abi/pre/gnu.ver branches/gcc-9-branch/libstdc++-v3/configure branches/gcc-9-branch/libstdc++-v3/testsuite/util/testsuite_abi.cc
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 --- Comment #7 from Jonathan Wakely --- Author: redi Date: Wed Jul 3 21:06:25 2019 New Revision: 273023 URL: https://gcc.gnu.org/viewcvs?rev=273023=gcc=rev Log: PR libstdc++/91067 fix missing exports for filesystem iterators The copy assignment operator for recursive_directory_iterator was not exported despite being needed. The __shared_ptr default constructors are not needed when compiling with GCC but Clang requires them for -O1. PR libstdc++/91067 * acinclude.m4 (libtool_VERSION): Bump to 6:27:0. * configure: Regenerate. * config/abi/pre/gnu.ver (GLIBCXX_3.4.27): Add new version. Export missing symbols. * testsuite/27_io/filesystem/iterators/91067.cc: New test. * testsuite/util/testsuite_abi.cc: Add new symbol version. Added: trunk/libstdc++-v3/testsuite/27_io/filesystem/iterators/91067.cc Modified: trunk/libstdc++-v3/ChangeLog trunk/libstdc++-v3/acinclude.m4 trunk/libstdc++-v3/config/abi/pre/gnu.ver trunk/libstdc++-v3/configure trunk/libstdc++-v3/testsuite/util/testsuite_abi.cc
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067
--- Comment #6 from Jonathan Wakely ---
There are also some recursive_directory_iterator symbols missing. This fails
even compiled with GCC:
#include
int main()
{
std::filesystem::recursive_directory_iterator d;
d = d;
}
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 --- Comment #5 from Jonathan Wakely --- (In reply to Jonathan Wakely from comment #4) > This is a regression caused by moving the std::filesystem symbols into the > libstdc++.so shared library. It links OK with GCC 8 (using -lstdc++fs to > link to the static lib as needed for std::filesystem in GCC 8). To be clear, I meant it links OK with clang when using the headers+libs from GCC 8. (It also links OK when compiled with GCC 8, because it inlines differently.)
[Bug libstdc++/91067] [9/10 Regression] Clang compiler can't link executable if std::filesystem::directory_iterator is encountered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91067 Jonathan Wakely changed: What|Removed |Added Known to work||8.3.0 Summary|Clang compiler can't link |[9/10 Regression] Clang |executable if |compiler can't link |std::filesystem::directory_ |executable if |iterator is encountered |std::filesystem::directory_ ||iterator is encountered Known to fail||10.0, 9.1.0 --- Comment #4 from Jonathan Wakely --- This is a regression caused by moving the std::filesystem symbols into the libstdc++.so shared library. It links OK with GCC 8 (using -lstdc++fs to link to the static lib as needed for std::filesystem in GCC 8). Adding the missing export will require GCC 9.2 to bump the version to libstdc++.so.6.0.27
