In file included from /usr/include/c++/v1/__algorithm/ranges_set_difference.h:15, from /usr/include/c++/v1/algorithm:1851, from /wrkdirs/usr/ports/math/kamis/work/KaMIS-2.1/extern/KaHIP/lib/partition/uncoarsening/separator/vertex_separator_flow_solver.cpp:8: /usr/include/c++/v1/__algorithm/set_difference.h: In instantiation of 'std::__1::pair<__remove_cvref(_InIter1), __remove_cvref(_OutIter)> std::__1::__set_difference(_InIter1&&, _Sent1&&, _InIter2&&, _Sent2&&, _OutIter&&, _Comp&&) [with _AlgPolicy = _ClassicAlgPolicy; _Comp = __less<unsigned int>; _InIter1 = __wrap_iter<unsigned int*>&; _Sent1 = __wrap_iter<unsigned int*>&; _InIter2 = __wrap_iter<unsigned int*>&; _Sent2 = __wrap_iter<unsigned int*>&; _OutIter = __wrap_iter<int*>&]': /usr/include/c++/v1/__algorithm/set_difference.h:32:1: error: use of built-in trait '__remove_cvref(_InIter1)' in function signature; use library traits instead 32 | __set_difference( | ^~~~~~~~~~~~~~~~ /usr/include/c++/v1/__algorithm/set_difference.h:32:1: error: use of built-in trait '__remove_cvref(_OutIter)' in function signature; use library traits instead
^Triage: Bug is specific to the build of two ports, so it makes more sense to start the summary with their port origins rather than with the failing compiler and to assign the bug to their maintainer. Indeed, a fix for the issue would probably be a patch to the failing ports, not a patch to the compiler port. Of course, it is always a good idea to put the failing compiler maintainers into CC so that they are aware of the problem and do their best to help. I suggest you file a bug report upstream. I will try to have a look into this issue as soon as possible, but since I already have a lot of things to work on (a GCC 14 release is coming soon, which means a new exp-run to update the GCC default version again) and armv7 is a tier 2 platform on all supported FreeBSD releases (https://www.freebsd.org/platforms/) this is unlikely to happen soon, sorry.
Since this failure is specific to armv7 (gcc-13 succeeds on these ports on the amd64 platform), and the C++ code looks valid, I believe that this is a gcc problem, or a gcc on FreeBSD problem. I'll create the GCC bug report for this.
GCC bug report: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114878
Based on the GCC reponse this is a fixed libc++ bug, which fix needs to be backported to FreeBSD: > Yes it was a bug in libc++, see https://github.com/llvm/llvm-project/commit/55357160d0e151c32f86e1d6683b4bddbb706aa1 I am assigning this bug report to toolchain@.
Can somebody verify on a armv7 system that older gcc ports build with the upstream patch for libc++? Because that is essential if I import that patch.