- User Since
- Sep 1 2015, 9:50 AM (240 w, 1 d)
Jan 2 2020
Oct 1 2019
Feb 4 2019
I like this too, however I don't know how this interacts with tests like test/libcxx/language.support/support.dynamic/new_faligned_allocation.sh.cpp that specify the build command-line explicitly:// RUN: %build -faligned-allocation
We'd make sure that %build links in the additional entry point?
Agreed that seems problematic, but I think we can fix it after this patch lands. :)
For what it's worth, when I ran these tests with MSVC in the Windows kernel, I just called main, and falling off the end of main happened to work. I can't say I'm thrilled with that approach though.
Oct 24 2018
add a comment, and it will be fine in my eyes. You'll need signoff from the code owner though.
Oct 12 2018
You should probably add whoever the current code owner of that static analyzer to this review. I have very little involvement with Clang these days, so a "LGTM" from me doesn't carry much weight.
Apr 24 2018
For those that would prefer random device to not exist if it isn't cryptographically secure, please write a wg21 paper. I will gladly review such a paper, and if you need a presenter, then I will present it if I am attending. I won't be at Rapperswil, but I will be at San Diego.
Apr 4 2018
Dec 9 2017
Dec 5 2017
Talked with mclow and some Microsoft devs in Albuquerque. I'm not expecting include_next to show up in MSVC. Sometime in the next month I hope to rebase this change.
Sep 11 2017
Is there a benchmark where this demonstrates some performance improvement? I fear that the switch to condition_variable_any will swamp any performance gains from the switch to a spin lock.
Aug 21 2017
Aug 15 2017
The test headers should not be in the production include folder. They should probably be in the benchmark folder.
Aug 11 2017
Aug 10 2017
If you want the performance improvements in the BM_sort_std_worst_quick cases preserved, you really need to port the benchmark from Aditya's repo into the libcxx benchmark code base. Otherwise, the next person that comes along to improve std::sort performance may very well wreck the performance gains you achieved.
Aug 8 2017
I like this change in general. Dinkumware has been using introsort for 10+ years, so I'm a bit surprised that libc++ wasn't already.
Those are interesting (and useful) results... but they don't look like they came from the same algorithms.bench.cpp that I'm looking at...
Aug 7 2017
alternatively, you could report the comparison of the old code vs. the new code with an existing benchmark, like benchmarks/algorithms.bench.cpp
This patch needs benchmarks that demonstrate the performance changes.
Jul 31 2017
Jul 23 2017
Jul 12 2017
Jul 11 2017
Jul 10 2017
Switched to static consts
Jul 9 2017
Jul 5 2017
Separating out logging into it's own class.
Also tweaked the output slightly so that the language dialect under test shows up as the first line of output.
Jun 27 2017
_LIBCPP_MS_CRT seems fine too.
Jun 26 2017
LGTM, but you should probably get approval from somebody a bit more senior with the project.
Jun 25 2017
Jun 24 2017
Jun 15 2017
This is very stale at this point, and isn't blocking anything. Closing.
Jun 14 2017
@waltl : Do you need me to submit the changes, or will you handle that?
Jun 13 2017
May 29 2017
May 25 2017
Are you suggesting that libc++ should stop declaring/defining these functions, at least publically?
May 18 2017
May 12 2017
I noticed that the Windows STL headers have to do this dance with new (even though they do (foo)(...) for min and max). If we're going to need
to guard against a bunch of macros I would like to use a single approach. Other than updating the #if defined(min) || defined(max) lines it's trivial to guard
against additional macros.
May 11 2017
I agree that we need to be precise in our platform detection macros. On Windows, we currently need to worry about which compiler is being used, whether we are targeting the mingw environment or the native (?) environment, and which c-runtime is being used.
I like the warning that you generate for min and max macros existing. Is the push_macro / pop_macro the right way to go though? You could throw extra parenthesis around the declaration and usages of min/max to avoid macro expansion.
May 10 2017
May 9 2017
May 8 2017
May 7 2017
Getting the test suite green sooner rather than later seems like a good reason to temporarily pick a 1-3 year solution rather than a 5+ year solution. Also, as you mention, this isn't all throw away work, so it's still progress.
May 6 2017
libstdc++ and the Visual Studio C++ runtime have very different compatibility expectations.
May 4 2017
I'm still working on this.
Apr 24 2017
Apr 23 2017
Apr 21 2017
Apr 17 2017
Apr 11 2017
Sep 9 2016
Neat! I would have liked to have had this for the Excess Padding Checker. Currently, the padding checker has a very long diagnostic that recommends a new order for data members. I think a note (or fixit) would be more appropriate, but that support didn't exist previously.
This seems related:
Sep 2 2016
Sep 1 2016
The "@" will do a ping through phabricator, but a direct email is probably going to be your best bet at this point.
Aug 31 2016
Aug 25 2016
Aug 24 2016
Aug 19 2016
I like the rationale here, but can we avoid pulling in headers at all?
You could test _ _STDC_NO_ATOMICS_ _. You could also have some code like this...
Aug 2 2016
Aug 1 2016
committed rL277357: Improve shared_ptr dtor performance.
I am going to submit the code changes and the tests independently. I'm having trouble getting cmake to use the right compiler for the libcxx-benchmarks target.
Jul 21 2016
Jul 20 2016
Jul 19 2016
Added weak_ptr benchmark, as that's where the cost shifted.
Jul 18 2016
Jul 8 2016
Jul 6 2016
LGTM. As usual, you'll want to get one of the code owner's sign off first though.
Jul 5 2016
Jun 30 2016
Also, can you add test cases for a lot of these things? I don't expect test cases for the DSO side of things, but a lot of the tricky atexit cases should be covered.
Jun 29 2016
Hmm, maybe? If other global destructors run after ~DtorListHolder(), and they cause a thread_local to be initialized for the first time, __cxa_thread_atexit() might be called again. I was thinking that dtors would get re-initialized in that case but it appears it does not. So yeah, I think I'll need to leak the pthread_key_t.
I'm not sure how to avoid leaking the actual thread_local objects that get created in that situation. There's nothing left to trigger run_dtors() a second time.
You should look at __thread_specific_ptr in libcxx's <thread>. It does a lot of these things in order to satisfy the requirements of notify_all_at_thread_exit, set_value_at_thread_exit, and make_ready_at_thread_exit.
Jun 23 2016
@joerg. I think this has been fixed in newer versions of NetBSD.