Re: CFT: snmalloc as libc malloc [snmalloc misidentifies what llvm versions have source_location: need >= 16, not 15]

[snmalloc misidentifies what llvm versions have source_location .]

On Feb 12, 2023, at 14:36, Mark Millard <marklmi@yahoo.com> wrote:
> 
> On Feb 12, 2023, at 14:24, Shawn Webb <shawn.webb@hardenedbsd.org> wrote:
> 
>> On Sun, Feb 12, 2023 at 01:48:59PM -0800, Mark Millard wrote:
>>> On Feb 12, 2023, at 13:09, Shawn Webb <shawn.webb@hardenedbsd.org> wrote:
>>> 
>>>> . . .
>>>> That does not include the extra text that would be generated
>>>> by having added the -v requested to that shown command line.
>>>> That tet would likely have been before the text that you did
>>>> include.
>>>> 
>>>> Did you add the -v option? Was there extra text?
>>> 
>>> Good catch. I missed reading that. Here's the new output:
>>> http://ix.io/4nSy
>>> 
>>> Hmm. Scanning that list . . .
>>> 
>>> #include "..." search starts here:
>>> #include <...> search starts here:
>>> /data/src/hardenedbsd/lib/libc/include
>>> /data/src/hardenedbsd/include
>>> 
>>> The above likely includes a non-C++: stddef.h
>>> That likely overrides any: . . ./include/c++/v1/stddef.h
>>> that is required for things to work for the
>>> nullptr_t issue. (See prior E-mail from when
>>> I noticed that I'd missed the include/c++/v1/stddef.h
>>> involved.)
>>> 
>>> /data/src/hardenedbsd/lib/libc/amd64
>>> /data/src/hardenedbsd/contrib/gdtoa
>>> /data/src/hardenedbsd/contrib/libc-vis
>>> /usr/obj/data/src/hardenedbsd/amd64.amd64/lib/libc
>>> /data/src/hardenedbsd/lib/libc/resolv
>>> /data/src/hardenedbsd/lib/libmd
>>> /data/src/hardenedbsd/lib/libc/locale
>>> /data/src/hardenedbsd/lib/libc/rpc
>>> /data/src/hardenedbsd/lib/libutil
>>> /data/src/hardenedbsd/lib/msun/amd64
>>> /data/src/hardenedbsd/lib/msun/x86
>>> /data/src/hardenedbsd/contrib/snmalloc/src/snmalloc
>>> /usr/obj/data/src/hardenedbsd/amd64.amd64/tmp/usr/include/c++/v1
>>> 
>>> The above looks to be the first/only chance to pick
>>> up a C++ based file header (that may in turn look
>>> for a C based one as well).
>>> 
>>> /usr/lib/clang/15.0.7/include
>>> /usr/obj/data/src/hardenedbsd/amd64.amd64/tmp/usr/include
>>> /data/src/hardenedbsd/lib/msun/src
>>> End of search list.
>>> 
>>> The ordering does not look anything like correct
>>> to me relative to C++ headers, some of which in
>>> turn may include the C variants from the environment.
>>> 
>>> It is not so clear to me what the relationship is
>>> to the source_location file issue.
>> 
>> Also: find /data/src/hardenedbsd -iname '*source_location*'
>> 
>> ^ that returns zero results. Are we ("we" being both FreeBSD and
>> HardenedBSD) completely missing a header file somewhere?
>> 
> 
> Quoting prior content, after showing a find
> that indicated no examples in system header
> areas, including for llvm15:
> 
> QUOTE
> 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].
> END QUOTE
> 

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

shows that it misidentifes what llvm versions have source__location,
indicating that llvm15 (__clang_major__ >= 15) has it when it does not :

#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

===
Mark Millard
marklmi at yahoo.com