Re: CFT: snmalloc as libc malloc (the source_location issue)
- Reply: Mark Millard : "Re: CFT: snmalloc as libc malloc (the source_location issue)"
- Reply: Mark Millard : "Re: CFT: snmalloc as libc malloc (the source_location issue)"
- In reply to: Mark Millard : "Re: CFT: snmalloc as libc malloc (the source_location issue)"
- Go to: [ bottom of page ] [ top of archives ] [ this month ]
Date: Sat, 11 Feb 2023 17:13:48 UTC
On 10 Feb 2023, at 21:34, Mark Millard <marklmi@yahoo.com> wrote: > > # find / -name source_location -print | more > /usr/obj/DESTDIRs/main-amd64-chroot/usr/local/lib/gcc12/include/c++/experimental/source_location > /usr/obj/DESTDIRs/main-amd64-chroot/usr/local/lib/gcc12/include/c++/source_location > /usr/local/lib/gcc12/include/c++/experimental/source_location > /usr/local/lib/gcc12/include/c++/source_location > > So, none for FreeBSD and its llvm15. > > This makes sense, https://libcxx.llvm.org/Status/Cxx20.html shows: > > P1208R6 LWG Adopt source_location for C++20 Cologne Complete 16.0 > > So, likely FreeBSD will not have this until it progresses to > LLVM16 . It just changed to LLVM15 in main [so: FreeBSD 14]. The include of source_location is guarded under an #if __has_include, it should be used only if it exists. If it doesn’t, there’s a stub implementation. If you have GCC includes in your include path, is it possible that it’s finding a source_location that is then guarded behind a check for a compiler builtin that clang doesn’t have? David