- User Since
- Sep 1 2015, 9:50 AM (303 w, 1 d)
Feb 14 2021
Messed with this some over the weekend, and realized there's ambiguity in the request. I also found that there are some challenges with each of the reasonable things that I think you could be requesting. Note that all 3 approaches result in failing tests, and fixing those tests will take time.
Feb 4 2021
I haven't messed with the pipeline or buildbot scripts before. Is there some way for me to test those changes before landing them?
Jan 30 2021
Removing the preprocessor defines, in order to divorce the tests from the library under test.
Jan 24 2021
Jan 4 2021
Jan 1 2021
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.