[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-hackers
Subject:    Re: CFT: snmalloc as libc malloc [snmalloc misidentifies what llvm versions have source_location: ne
From:       Mark Millard <marklmi () yahoo ! com>
Date:       2023-02-13 22:01:29
Message-ID: 6660BD19-13BA-4F73-9447-A3B54D8E0B29 () yahoo ! com
[Download RAW message or body]

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

> On 12/02/2023 22:53, Mark Millard wrote:
> > [snmalloc misidentifies what llvm versions have source_location .]
> 
> Thanks, I thought snmalloc included the code I wrote in a related project to do \
> this, but apparently not.  I've opened a PR to fix it and will merge once it passes \
> CI, then bump the submodule: 
> https://github.com/microsoft/snmalloc/pull/591
> 

For the:

-#if (defined(__GNUC__) && !defined(__clang__) && __GNUC__ >= 11) || \
-  (defined(__clang__) && __clang_major__ >= 15)
+#ifdef __cpp_lib_source_location

My understanding is that __cpp_lib_source_location is guaranteed
to potentially become defined basically only 2 ways:

A) inclusion of <source_location>
B) inclusion of <version>

Clearly (A) is not the case here and would require a
__has_include(<source_location>) test to allow this style
of attempting to get a definition for
__cpp_lib_source_location .

I looked a round some and did not notice an example of (B),
but I may have missed it.

So, it might be that this changed turned off use of
<source_location> in unintended places.

===
Mark Millard
marklmi at yahoo.com


[prev in list] [next in list] [prev in thread] [next in thread]