Created attachment 236025 [details] v1 (apply via "git am") $ pkg install gcc11 $ echo 'int main() {}' >a.cc $ gcc11 -stdlib=libc++ a.cc gcc11: error: unrecognized command-line option '-stdlib=libc++' $ man gcc11 | col -b | fgrep -A9 stdlib= -stdlib=libstdc++,libc++ When G++ is configured to support this option, it allows specification of alternate C++ runtime libraries. Two options are available: libstdc++ (the default, native C++ runtime for G++) and libc++ which is the C++ runtime installed on some operating systems (e.g. Darwin versions from Darwin11 onwards). The option switches G++ to use the headers from the specified library and to emit "-lstdc++" or "-lc++" respectively, when a C++ runtime is required for linking.
s/gcc11/g++11/ (can't edit typos due to bug 191677)
Thanks Jan. I have reproduced the bug and I am going to test your patch as soon as possible.
Limiting to g++11 may not cover everything g++ related: # g++12 -stdlib=libc++ trivial.cpp g++12: error: unrecognized command-line option '-stdlib=libc++' Some decision about the range of g++* 's to cover may be needed. But my ports context goes back to mid-July (in case things have changed): # ~/fbsd-based-on-what-commit.sh -C /usr/ports branch: main merge-base: 872199326a916efbb4bf13c97bc1af910ba1482e merge-base: CommitDate: 2022-07-14 01:26:04 +0000 872199326a91 (HEAD -> main, freebsd/main, freebsd/HEAD) devel/ruby-build: Update to 20220713 n589512 (--first-parent --count for merge-base) FYI: In some personal makefiles I've used the likes of: CXX= g++11 -v -std=c++20 -Wpedantic -Wall -Wextra CXX+= -Wno-psabi -nostdinc -nostdinc++ -I/usr/include/c++/v1 -I/usr/include LDCXX= -nodefaultlibs -lc++ -lcxxrt -lthr -lm -lc -lgcc_s in order to use a g++* with libc++ on FreeBSD. (I've not gone back and updated to g++12 for that context as yet.) So there has been a way to use libc++ with the likes of g++11 in some cases --just messier to set up.
Created attachment 236028 [details] v2 (apply via "git am") Applied to all affected lang/gcc* versions. However, I haven't tested anything beyond lang/gcc11 yet. (In reply to Mark Millard from comment #3) > # g++12 -stdlib=libc++ trivial.cpp > g++12: error: unrecognized command-line option '-stdlib=libc++' Fixed. Required for bug 265964 via lang/guile.
I'm unsure if what is proposed here deals completely with making g++* compiles/links produce working code for FreeBSD in all cases. This is based on considering more than just amd64 and i386, such as aarch64. The following is extracted from a comment in another bugzilla report. It might be worth testing the analogous case where -stdlib=libc++ can be (and is) used. Part of the point would be validation what ldd shows for the built program to see if FreeBSD libraries and gcc libraries end up in an odd mix for the usage. The copied example comment . . . The following 6 line c++ program is sufficient to demonstrate the __unordtf2@GCC_4.5.0 binding failure when targeting aarch64: # more fp-binding-failure-aarch64.cpp #include <cmath> volatile long double v=NAN; int main() { return std::isnan(v) ? 1 : 0; } # g++11 fp-binding-failure-aarch64.cpp # ./a.out ld-elf.so.1: /lib/libgcc_s.so.1: version GCC_4.5.0 required by /usr/home/root/c_tests/a.out not found Note that the complaint is not about a reference in /usr/local/lib/gcc11/libstdc++.so.6 but about the a.out that has its own reference to __unordtf2@GCC_4.5.0 : # nm -a a.out | grep '@GCC_[4-9]\.' | more U __unordtf2@GCC_4.5.0 For reference . . . # ldd a.out a.out: libstdc++.so.6 => /usr/local/lib/gcc11/libstdc++.so.6 (0x83000000) libm.so.5 => /lib/libm.so.5 (0x81834000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x8275a000) libc.so.7 => /lib/libc.so.7 (0x845f3000)
(In reply to Mark Millard from comment #3) I forgot that for aarch64 those personal makefiles used more in order to make the use of libc++ work: CXX= g++11 -v -std=c++20 -Wpedantic -Wall -Wextra CXX+= -Wno-psabi -nostdinc -nostdinc++ -I/usr/include/c++/v1 -I/usr/include OPT+= -mno-outline-atomics LDCXX= -nodefaultlibs -lc++ -lcxxrt -lthr -lm -lc -lgcc_s LDCXX+= -Wl,-rpath=/usr/local/lib/gcc11 As I remember that last ( -wl,-rpath=/usr/local/lib/gcc11 ) was tied to the issue in comment #5 . There is also that -mno-outline-atomics addition that was tied to allowing it to manage to link (avoiding missing definitions), if I remember right. (It has been over a year since I dealt with the above.)
(In reply to Mark Millard from comment #5) libgcc_s.so error is likely due to "shared-libgcc" in "gcc11 -dumpspecs" output missing -Wl,-rpath,/usr/local/lib/gcc11 while a file with similar name exists under /usr/lib. See also https://wiki.freebsd.org/Ports/libgcc_linking_problem Not related to -stdlib=libc++.
Thanks Jan and Mark. My first tests confirm that Jan's patch work. Rather than making lots of tests on many different architectures on my machine, I think we can take advantage of the fact that we have many different gcc ports with different roles and update them carefully one at the time. The plan is as follow: - commit the patch to -devel ports first, as they have no ports depending on them and I update them about once a week; - commit the patch to gcc12, as it is the only supported production gcc version that does not have dependent ports and I have just started the process to make it the new GCC default version (see bug #265948), so the port will be heavily tested through exp-runs and more tests from other ports maintainers. I don't plan to wait for GCC default version update to be finished before moving to the next steps, but hopefully we will have some more testing anyway; - commit the patch to gcc10, that has many ports depending on it; - commit the patch to gcc11, that has the most ports depending on it has it is now GCC default version. I don't plan to patch unsupported gcc version that we still have in the ports tree for some reason. The plan might change depending on how fast is the GCC default version update process going. Does the plan sound good?
Created attachment 236029 [details] v2.1 (apply via "git am") Sort CONFIGURE_ARGS (cosmetic) in order to group --with-gxx-include-dir and --with-gxx-libcxx-include-dir together. (In reply to Lorenzo Salvadore from comment #8) > - commit the patch to gcc12, as it is the only supported production > gcc version that does not have dependent ports lang/guile has USE_GCC=12 since ports a02c296c230a but it seems to be masked by USE_GCC=yes via USES=compiler:gcc-c++11-lib. > I have just started the process to make it the new GCC default version > (see bug #265948), so the port will be heavily tested through exp-runs > and more tests from other ports maintainers. Another option is to rely on exp-run results from bug 265964 which depends on the patch here. > Does the plan sound good? Confusing but consistent with previous maintainer. I prefer to group related changes together and land atomically unless they can be split by topic. Makes before/after easier to reason about than having to remember where the change landed and where it's only queued.
(In reply to Jan Beich from comment #7) I guess my point would have been better stated as: using -stdlib=libc++ will not remove the need for use of the likes of -Wl,-rpath=/usr/local/lib/gcc11 (or whatever is the proper match) in order to keep things working for the likes of aarch64. Nor will -stdlib=libc++ fix various examples that are broken as things are, examples that lack such an rpath definition: The __unordtf2@GCC_4.5.0 binding problem (and related) make various builds fail last I knew, sometimes not just via such references from libstdc++ .
(In reply to Jan Beich from comment #9) >> I have just started the process to make it the new GCC default version >> (see bug #265948), so the port will be heavily tested through exp-runs >> and more tests from other ports maintainers. > Another option is to rely on exp-run results from bug 265964 which depends on the patch here. I think I have not understood your idea. As you state, bug #265964 depends on this port, so how can I use the results of its exp run for this bug? The exp run for bug #265964 must be done after this bug is fixed, isn't it? Am I missing something?
(In reply to Lorenzo Salvadore from comment #8) I gather your sequence does not, of itself, involve testing building ports such that the builds use -stdlib=libc++ instead of the an implicit -stdlib=libstdc++ . Just the relevant g++*'s would be built to allow -stdlib=libc++ to be tried. By contrast, Jan's activity would involve some use of -stdlib=libc++ with some g++* . Together those seem to have a fair amount of coverage. There is probably no grand, immediate switching of lots of ports to -stdlib=libc++ use expected. Overall, sounds good to me.
(In reply to Mark Millard from comment #12) Ah, thanks Mark, now it is clearer. Indeed, an exp run for bug #265964 is also useful although it comes after this bug is closed.
(In reply to Lorenzo Salvadore from comment #11) > The exp run for bug #265964 must be done after this bug is fixed, isn't it? No. exp-run are not automatic but scheduled by a portmgr@ peer who can follow instructions. In bug 265964 comment 1 I've asked to test changes "together". Due to GCC_DEFAULT=11 only lang/gcc11 part is relevant for exp-run while other lang/gcc* are QA'd for free.
(In reply to Jan Beich from comment #14) Ah thanks, I had never seen asking for an exp-run using patches from two different bug reports. If the exp run for bug #265994 is completed successfully we can indeed go faster. I see the patch you submitted for this bug report does not cover gcc10. Is it because you do not need it or GCC_DEFAULT=11 made you forget about gcc10 being still around?
(In reply to Lorenzo Salvadore from comment #15) > ... does not cover gcc10. GCC < 11 doesn't support -stdlib= flag. Patching gcc/cp/g++spec.c failed. libc++abi is only mentioned in libsanitizer docs (inline comment + ChangeLog). See also https://github.com/gcc-mirror/gcc/commit/662b9c55cf06 > Is it because you do not need it ... ? USES=compiler:gcc-c++11-lib has USE_GCC=yes which works fine due to GCC_DEFAULT=11. To override USE_GCC (older/newer than default) it has to be defined after <bsd.port.pre.mk>.
(In reply to Jan Beich from comment #7) I'm still confused by the claimed independence: # ldd /lib/libc++.so.1 /usr/lib/libcxxrt.so /lib/libc++.so.1: libcxxrt.so.1 => /lib/libcxxrt.so.1 (0x145f0547f000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x145f0547f000) libc.so.7 => /lib/libc.so.7 (0x145f0547f000) /usr/lib/libcxxrt.so: libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x145f05e8f000) libc.so.7 => /lib/libc.so.7 (0x145f05e8f000) Use of -stdlib-libc++ for g++* use needs to end up producing files consistent with the above bindings for libgcc_s.so.1 and libc.so.7 so far as I can tell. Use of the likes of, say, /usr/local/lib/gcc12/libgcc_s.so.1 /usr/local/lib/gcc12/libgcc_s.so in the mix would not be a valid combination in general when /lib/libc++.so.1 or /usr/lib/libcxxrt.so are in use if I understand right.
(In reply to Mark Millard from comment #17) /usr/local/lib/gcc*/libgcc_s.so (part of gcc* packages) is a superset of /usr/lib/libgcc_s.so (part of base or FreeBSD-clibs package), so /usr/lib/libc++.so can use either. So, gcc12 -stdlib=libc++ should work fine without -Wl,-rpath,/usr/local/lib/gcc12. However, when using math functions GCC may emit calls to libgcc_s (e.g., via optimization), into a subset NOT implemented by FreeBSD. Clang can also emit calls into libgcc_s but given compiler-rt is part of LLVM those are always compatible. Sorry, I'm not interested in libgcc_s issue. Outside of emulators/yuzu none of my ports need lang/gcc* and even yuzu works fine with /usr/lib/libgcc_s.so.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=117c06cf3d5626ff5650342ed91c786759a6de1c commit 117c06cf3d5626ff5650342ed91c786759a6de1c Author: Jan Beich <jbeich@FreeBSD.org> AuthorDate: 2022-08-20 23:26:46 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2022-08-21 10:14:23 +0000 lang/gcc12-devel: Expose non-default -stdlib=libc++ support Fix -stdlib=libc++ option which produced "error: unrecognized command-line option '-stdlib=libc++'". PR: 265962 Reported by: jbeich lang/gcc12-devel/Makefile | 1 + lang/gcc12-devel/files/patch-libcxxrt (new) | 18 ++++++++++++++++++ 2 files changed, 19 insertions(+)
(In reply to commit-hook from comment #19) This overlaps with Jan's 'v2.1 (apply via "git am")' patch, which also covered gcc12-devel . Jan's patch likely needs another update now to avoid trying to update gcc12-devel for the issue.
(In reply to Mark Millard from comment #20) No need to update the patch again, at least for me: its meaning is clear and I am extracting the part that I need for each single port. Moreover, in the next hours gcc13-devel will also be updated (unless some bug prevents me to do so) and I will apply the patch there too.
But in bug 265964 Jan has requested that the patch from here also be applied during/for the exp run for bug 265964 . This may mess up the exp run for bug 265964 if the patch is rejected for no longer matching the ports appropriately.
(In reply to Mark Millard from comment #22) I am sure antoine@, who usually runs our exp-runs, is able to deal with an easy merge conflict. If however we want to make things easier for him, we can update the patch once more: Jan, if you want to update the patch, please include in it only gcc11 and gcc12, which are the only ports that should affect the exp run. I am going to deal with the -devel ports separately: gcc12-devel is already fixed, gcc13-devel should be fixed within the next 24 hours and gcc11-devel should be fixed next Friday or Saturday (gcc11 snapshots are made on Fridays and as for the other -devel ports I plan to patch gcc11-devel together with the update to the latest snapshot).
Created attachment 236053 [details] v2.2 (apply via "git am") Split by port and rebase after ports 117c06cf3d56. If "git am bug265962.diff" fails, re-run as "git am --skip" to apply the rest while skipping the conflicting (already applied) patch in the series.
(In reply to Jan Beich from comment #24) Thanks Jan. So, if I understand correctly, now that the patch is split by ports I can commit the patches for the rest of the -devel ports without forcing you to re-update the attached patch for antoine@, is that right? Or would you prefer that I just waited for the exp-run to be completed?
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=4de701de115afbd0789dd5fd9e276423fc1df500 commit 4de701de115afbd0789dd5fd9e276423fc1df500 Author: Jan Beich <jbeich@FreeBSD.org> AuthorDate: 2022-08-21 23:25:49 +0000 Commit: Lorenzo Salvadore <salvadore@FreeBSD.org> CommitDate: 2022-08-22 12:00:04 +0000 lang/gcc13-devel: Expose non-default -stdlib=libc++ support Fix -stdlib=libc++ option which produced "error: unrecognized command-line option '-stdlib=libc++'". PR: 265962 Reported by: jbeich lang/gcc13-devel/Makefile | 2 ++ lang/gcc13-devel/files/patch-libcxxrt (new) | 18 ++++++++++++++++++ 2 files changed, 20 insertions(+)
(In reply to commit-hook from comment #26) I confirm that after this commit the patch can still be applied cleanly thanks to git am --skip. I tested before pushing. So need to update the patch this time.
(In reply to Lorenzo Salvadore from comment #27) > So need to update the patch this time. Sorry, I meant "So no need to update the patch this time."
(In reply to commit-hook from comment #26) "Reported by" shouldn't be used here. When you use someone's else patch it should be "Submitted by" but since Git commit author is already set it can be omitted. The attached patch(es) already provide an example commit message where "Approved by" can be omitted if it's pushed/committed by the maintainer. https://docs.freebsd.org/en/articles/committers-guide/#_include_appropriate_metadata_in_a_footer
Bug 265964 exp-run passed without fallout. Now it's time to push/land but comment 8 only has implicit approval and what already pushed/landed used slightly different commit messages. If you're fine with me doing the rest change Assignee.
Comment on attachment 236053 [details] v2.2 (apply via "git am") Maintainer approval explicitly granted: you can do the rest, thank you very much Jan. Please use the slightly different commit message I wrote: I find it clearer. Also please keep the patch splitted by ports. And I guess adding antoine's testing to the commit message would also be a good idea. Thanks.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=86e7abbbf467e97ffa58363ca3327d08395931ee commit 86e7abbbf467e97ffa58363ca3327d08395931ee Author: Jan Beich <jbeich@FreeBSD.org> AuthorDate: 2022-08-20 16:06:02 +0000 Commit: Jan Beich <jbeich@FreeBSD.org> CommitDate: 2022-08-25 21:35:37 +0000 lang/gcc12: Expose non-default -stdlib=libc++ support Fix -stdlib=libc++ option which produced "error: unrecognized command-line option '-stdlib=libc++'". PR: 265962 Approved by: salvadore (maintainer) Exp-run by: antoine (via bug 265964) lang/gcc12/Makefile | 2 ++ lang/gcc12/files/patch-libcxxrt (new) | 18 ++++++++++++++++++ 2 files changed, 20 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=e6e0bd06a2eec3f9f5e2780869ce3682d6c81391 commit e6e0bd06a2eec3f9f5e2780869ce3682d6c81391 Author: Jan Beich <jbeich@FreeBSD.org> AuthorDate: 2022-08-20 16:06:02 +0000 Commit: Jan Beich <jbeich@FreeBSD.org> CommitDate: 2022-08-25 21:35:37 +0000 lang/gcc11-devel: Expose non-default -stdlib=libc++ support Fix -stdlib=libc++ option which produced "error: unrecognized command-line option '-stdlib=libc++'". PR: 265962 Approved by: salvadore (maintainer) Exp-run by: antoine (via bug 265964) lang/gcc11-devel/Makefile | 2 ++ lang/gcc11-devel/files/patch-libcxxrt (new) | 18 ++++++++++++++++++ 2 files changed, 20 insertions(+)
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=65fe81d73e72f1303557c9809a73716cc7fcd77b commit 65fe81d73e72f1303557c9809a73716cc7fcd77b Author: Jan Beich <jbeich@FreeBSD.org> AuthorDate: 2022-08-20 16:06:02 +0000 Commit: Jan Beich <jbeich@FreeBSD.org> CommitDate: 2022-08-25 21:35:37 +0000 lang/gcc11: Expose non-default -stdlib=libc++ support Fix -stdlib=libc++ option which produced "error: unrecognized command-line option '-stdlib=libc++'". PR: 265962 Approved by: salvadore (maintainer) Exp-run by: antoine (via bug 265964) lang/gcc11/Makefile | 2 ++ lang/gcc11/files/patch-libcxxrt (new) | 18 ++++++++++++++++++ 2 files changed, 20 insertions(+)
Thanks Jan. I have also assigned you the bug (I had forgotten it before, sorry).
FYI: One property of a straight forward use of --stdlib=libc++ is the search path consequences for some includes with the same names in the gcc* and FreeBSD: ignoring nonexistent directory "/usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd14.0/12.2.0/include-fixed" ignoring nonexistent directory "/usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd14.0/12.2.0/../../../../../aarch64-portbld-freebsd14.0/include" #include <...> search starts here: /usr/include/c++/v1 /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd14.0/12.2.0/include /usr/local/include /usr/include End of search list. # cd /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd14.0/12.2.0/include/ # ls -dC1 * */* ISO_Fortran_binding.h acc_prof.h arm_acle.h arm_bf16.h arm_fp16.h arm_neon.h arm_sve.h float.h gcov.h iso646.h objc objc/NXConstStr.h objc/Object.h objc/Protocol.h objc/message.h objc/objc-decls.h objc/objc-exception.h objc/objc-sync.h objc/objc.h objc/runtime.h objc/thr.h omp.h openacc.h ssp ssp/ssp.h ssp/stdio.h ssp/string.h ssp/unistd.h stdalign.h stdarg.h stdatomic.h stdbool.h stddef.h stdfix.h stdint-gcc.h stdint.h stdnoreturn.h tgmath.h unwind.h varargs.h
(In reply to Mark Millard from comment #36) I got an actual compile error from the issue when I tried: # g++12 -std=c++20 -stdlib=libc++ -fmodules-ts -xc++-system-header memory # g++12 -std=c++20 -stdlib=libc++ -fmodules-ts -xc++-system-header iostream In file included from /usr/include/c++/v1/__threading_support:34, from /usr/include/c++/v1/__thread/timed_backoff_policy.h:16, from /usr/include/c++/v1/atomic:524, from /usr/include/c++/v1/__memory/shared_ptr.h:35, from /usr/include/c++/v1/memory:821, of module /usr/include/c++/v1/memory, imported at /usr/include/c++/v1/__locale:18, included from /usr/include/c++/v1/ios:214, from /usr/include/c++/v1/iostream:37: /usr/include/pthread.h:102:41: error: inconsistent imported macro definition 'NULL' 102 | #define PTHREAD_MUTEX_INITIALIZER NULL | ^~~~ In file included from /usr/include/locale.h:38, from /usr/include/c++/v1/locale.h:46, from /usr/include/c++/v1/__locale:17: /usr/include/sys/_null.h:37: note: '#define NULL nullptr' 37 | #define NULL nullptr | In file included from /usr/include/c++/v1/cstddef:44, from /usr/include/c++/v1/type_traits:420, from /usr/include/c++/v1/__functional/weak_result_type.h:16, from /usr/include/c++/v1/__functional/invoke.h:14, from /usr/include/c++/v1/__functional_base:15, from /usr/include/c++/v1/memory:808: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd14.0/12.2.0/include/stddef.h:401: note: '#define NULL __null' 401 | #define NULL __null | So: mismatched NULL definitions put to use overall (nullptr vs __null). (The point is the mismatch, not the detail that I happened to be doing a experiment with modules when I ran into the mismatch.) It also reported messages like: /usr/include/c++/v1/__mutex_base:34:29: error: 'NULL' was not declared in this scope 34 | __libcpp_mutex_t __m_ = _LIBCPP_MUTEX_INITIALIZER; | ^~~~~~~~~~~~~~~~~~~~~~~~~ In file included from /usr/include/c++/v1/mutex:190, from /usr/include/c++/v1/__locale:19: /usr/include/c++/v1/__mutex_base:26:1: note: 'NULL' is defined in header '<cstddef>'; did you forget to '#include <cstddef>'? 25 | #include <__undef_macros> +++ |+#include <cstddef> 26 | But that might well get into module scoping being involved. I've no clue if FreeBSD expects its environment for clang is ready for setting up module imports of things like <iostream> . And it got a message for: /usr/include/c++/v1/__mutex_base:57:56: error: static assertion failed: the default constructor for std::mutex must be nothrow 57 | static_assert(is_nothrow_default_constructible<mutex>::value, | ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~^~~~~ I've not tracked this one down. But, here I'm just really noting the __null usage in: /usr/local/lib/gcc12/gcc/aarch64-portbld-freebsd14.0/12.2.0/include/stddef.h as an example of a more basic issue that can show up.
Just an FYI: I updated context were I'd used g++12 with -stdlib=libc++ to be based on trying g++13 instead. While it recognized the command line notation -stdlib=libc++ and picked out libc++ files to compile with, it rejects the libc++ source big time.
(In reply to Mark Millard from comment #38) Turns out it all traces back to one issue: __is_convertible already being a builtin in g++13, much like Microsoft's __is_convertible_to . The following local hack let me build the software in question: # diff -u /usr/include/c++/v1/__type_traits/is_convertible.h.orig /usr/include/c++/v1/__type_traits/is_convertible.h --- /usr/include/c++/v1/__type_traits/is_convertible.h.orig 2023-05-04 13:37:14.535549000 -0700 +++ /usr/include/c++/v1/__type_traits/is_convertible.h 2023-05-04 13:33:12.656731000 -0700 @@ -29,6 +29,11 @@ template <class _T1, class _T2> struct _LIBCPP_TEMPLATE_VIS is_convertible : public integral_constant<bool, __is_convertible_to(_T1, _T2)> {}; +#elif __has_builtin(__is_convertible) && !defined(_LIBCPP_USE_IS_CONVERTIBLE_FALLBACK) + +template <class _T1, class _T2> struct _LIBCPP_TEMPLATE_VIS is_convertible + : public integral_constant<bool, __is_convertible(_T1, _T2)> {}; + #else // __has_builtin(__is_convertible_to) && !defined(_LIBCPP_USE_IS_CONVERTIBLE_FALLBACK) namespace __is_convertible_imp I'll submit an llvm report and reference it on the toolchain list.