This makes sure that the PSTL integration doesn't regress. Eventually,
when we're ready to ship PSTL, this configuration will be enabled by
default in all builds and we can drop this additional CI configuration.
|61,270 ms||x64 debian > AddressSanitizer-x86_64-linux-dynamic.TestCases::scariness_score_test.cpp|
Script: -- : 'RUN: at line 4'; /var/lib/buildkite-agent/builds/llvm-project/build/./bin/clang --driver-mode=g++ -fsanitize=address -mno-omit-leaf-frame-pointer -fno-omit-frame-pointer -fno-optimize-sibling-calls -gline-tables-only -m64 -shared-libasan -O0 /var/lib/buildkite-agent/builds/llvm-project/compiler-rt/test/asan/TestCases/scariness_score_test.cpp -o /var/lib/buildkite-agent/builds/llvm-project/build/projects/compiler-rt/test/asan/X86_64LinuxDynamicConfig/TestCases/Output/scariness_score_test.cpp.tmp
|60,120 ms||x64 debian > AddressSanitizer-x86_64-linux.TestCases::scariness_score_test.cpp|
Script: -- : 'RUN: at line 4'; /var/lib/buildkite-agent/builds/llvm-project/build/./bin/clang --driver-mode=g++ -fsanitize=address -mno-omit-leaf-frame-pointer -fno-omit-frame-pointer -fno-optimize-sibling-calls -gline-tables-only -m64 -O0 /var/lib/buildkite-agent/builds/llvm-project/compiler-rt/test/asan/TestCases/scariness_score_test.cpp -o /var/lib/buildkite-agent/builds/llvm-project/build/projects/compiler-rt/test/asan/X86_64LinuxConfig/TestCases/Output/scariness_score_test.cpp.tmp
|60,030 ms||x64 debian > libFuzzer.libFuzzer::fuzzer-leak.test|
Script: -- : 'RUN: at line 3'; /var/lib/buildkite-agent/builds/llvm-project/build/./bin/clang --driver-mode=g++ -O2 -gline-tables-only -fsanitize=address,fuzzer -I/var/lib/buildkite-agent/builds/llvm-project/compiler-rt/lib/fuzzer -m64 /var/lib/buildkite-agent/builds/llvm-project/compiler-rt/test/fuzzer/LeakTest.cpp -o /var/lib/buildkite-agent/builds/llvm-project/build/projects/compiler-rt/test/fuzzer/X86_64DefaultLinuxConfig/Output/fuzzer-leak.test.tmp-LeakTest
|60,020 ms||x64 debian > libFuzzer.libFuzzer::minimize_crash.test|
Script: -- : 'RUN: at line 1'; /var/lib/buildkite-agent/builds/llvm-project/build/./bin/clang --driver-mode=g++ -O2 -gline-tables-only -fsanitize=address,fuzzer -I/var/lib/buildkite-agent/builds/llvm-project/compiler-rt/lib/fuzzer -m64 /var/lib/buildkite-agent/builds/llvm-project/compiler-rt/test/fuzzer/NullDerefTest.cpp -o /var/lib/buildkite-agent/builds/llvm-project/build/projects/compiler-rt/test/fuzzer/X86_64DefaultLinuxConfig/Output/minimize_crash.test.tmp-NullDerefTest
|60,030 ms||x64 debian > libFuzzer.libFuzzer::out-of-process-fuzz.test|
Script: -- : 'RUN: at line 2'; rm -rf /var/lib/buildkite-agent/builds/llvm-project/build/projects/compiler-rt/test/fuzzer/X86_64DefaultLinuxConfig/Output/out-of-process-fuzz.test.tmp && mkdir /var/lib/buildkite-agent/builds/llvm-project/build/projects/compiler-rt/test/fuzzer/X86_64DefaultLinuxConfig/Output/out-of-process-fuzz.test.tmp
|View Full Test Results (77 Failed)|
|3032–3037 ↗||(On Diff #348057)|
This change is necessary for the PSTL tests to succeed.
I am fairly certain that we can reduce that failure sufficiently to show that we actually have a bug in std::not_fn. @zoecarver would you be able to take a look since you implemented __perfect_forward_impl?
I am trying to update this review to continue enabling of PSTL CI with necessary modifications of the pipeline and fixes in PSTL source/tests, but I cannot do that. Seems like I don't have enough permissions to update the review I am not the author of. I am using web interface and when I am pressing "Update diff" I can only create the new revision and don't have an option to update the current one. Probably it's because I don't have direct Phabricator account (I have been using the GitHub one from the very beginning) or probably the reason is different. Together with @MikeDvorskiy we tried to do the same from his account (using web interface as well) and everything works just fine.
Could you please help me with the issue?
P.S. That problem was observed even earlier so, it seems I've never had such permission
How realistic is it that this still makes it into LLVM 15? I'd really like to start testing the pstl in our ecosystem a bit, happy to file bug reports too if so, but I'd need a way to be able to build it...
Unfortunately, I don't think we'll cherry-pick this to LLVM 15. Proper integration requires additional work, and that would be too much for LLVM 15 since we've already branched. We focused on Ranges and Format for LLVM 15. This should make it for LLVM 16 though.
I think the PSTL should be more tightly integrated with libc++, and we should probably be including libc++'s internal headers directly from it to break these kinds of circular dependencies.
This is going to be non-trivial though because there was an intent to share the PSTL between libc++ and libstdc++ -- I don't know whether that is still desired, and we may need to revisit this if we want to ease the integration between libc++ and PSTL.
@rodgert What is the current state of PSTL within libstdc++? How do you integrate it nowadays? Back in the days, I think you had a script that basically copied the sources to libstdc++ -- if that's still the case, do you have plans to keep it up to date, and can you link to that script so we can take a look at how the integration works?
We should be installing the PSTL headers to include/c++/v1 so that we find them alongside other libc++ headers out-of-the-box, and users don't need to add an additional include.
I suspect that means we'll have to start running the tests against a fake-installation of libc++/libc++abi/PSTL/whatever, which is what we should do anyways because it's closer to what users get. I've been meaning to do that for a while, I'll see if I can do this in the next few weeks.
This bit (and a few others) can land separately.
I pulled a new version in 2020 and have not rebased since. I had been waiting on the tag dispatch rewrite before considering the process again. I also not seen any progress on that since January, so maybe I will rethink matters if that continues.
I think any changes to include libc++'s internal headers would be detrimental to the continued to sharing of this codebase. I deliberately have not done that so far with libstdc++ (or I maintain those changes downstream only) because that would almost certainly introduce massive and likely unresolvable breakage for libc++.