Re: CFT: snmalloc as libc malloc (the source_location issue)

[Previously noted in another exchange, I note the snmalloc
source issue in reply to this message as well, to hopefully
avoid confusions when someone reads this particular
exchange.]

On Feb 11, 2023, at 09:13, David Chisnall <theraven@FreeBSD.org> wrote:

> 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,

I do not see such when I look at:

https://github.com/microsoft/snmalloc/blob/main/src/snmalloc/ds_core/defines.h

What I see is version checking that is based on llvm15 and above
having source_location :

#if (defined(__GNUC__) && !defined(__clang__) && __GNUC__ >= 11) || \
(defined(__clang__) && __clang_major__ >= 15)
# include <source_location>
. . .

__clang_major__ >= 16 would be appropriate, based on:

https://libcxx.llvm.org/Status/Cxx20.html

Other tests, less dependent on version checking, might
work instead.

> 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?

===
Mark Millard
marklmi at yahoo.com