Circling back on this -

I’ll make sure both sides agree on the name. I still need to go through the
tests on the libstdc++ side but that can wait until after stage1 closes.

In D62719#1527360, @mclow.lists wrote:

In D62719#1527089, @MikeDvorskiy wrote:

In D62719#1525450, @rodgert wrote:

Actually, we should probably get a test of some sort here before accepting the change. Yes, it's fairly obviously wrong and the fix is fairly obviously correct, but it's a regression and we should provide tests for regressions, lest certain standard library maintainers ask uncomfortable questions.

Do you mean a test should we added which will coverage the fixed error? In other words we need a test which checks following thing:

"Parallel algorithms shall not participate in overload resolution unless is_execution_policy_v<decay_-
t<ExecutionPolicy>> is true."

Right?

Right.

As far as I understand we should one call pear each algorithm with "fake" policy for is_execution_policy_v<fake_policy> is false and get a compilation error like "exclusive_scan(....).... is not found".
Otherwise, test "fail". So, it is "negative" test, right?
So, I have two questions:

1. Does LLVM test system support a negative test?

Yes it does. See (for example) "test/std/iterators/iterator.container/empty.array.fail.cpp"

2. If yes, to cover the all cases (to be sure that "enable_if is present") we have to add more 80 negative test units.

Agreed.

In D62719#1525469, @mclow.lists wrote:

In D62719#1525450, @rodgert wrote:

Actually, we should probably get a test of some sort here before accepting the change. Yes, it's fairly obviously wrong and the fix is fairly obviously correct, but it's a regression and we should provide tests for regressions, lest certain standard library maintainers ask uncomfortable questions.

My ears are suddenly burning ;-)
Are people talking about me?

Actually, we should probably get a test of some sort here before accepting the change. Yes, it's fairly obviously wrong and the fix is fairly obviously correct, but it's a regression and we should provide tests for regressions, lest certain standard library maintainers ask uncomfortable questions.

I am good with this change

In D60464#1464545, @ldionne wrote:

It's implicit in C++. I mean we can decide to do it like the rest of libc++, but we don't have to. For libc++, the reasoning is that it's needed to test in a freestanding environment.

@rodgert @MikeDvorskiy Do you guys want to consistently use return 0; at the end of main? If so, I'll fix this (and any other test that doesn't do it).

I'm not opposed to this change, but I wonder, should we then just remove the extra 'internal' directory, so that we get -

In D60480#1461587, @ldionne wrote:

In D60480#1461586, @rodgert wrote:

In D60480#1461555, @jfb wrote:

In D60480#1460733, @EricWF wrote:

In D60480#1460729, @rodgert wrote:

Not sure what is up with phabricator, but it won't let me respond inline to EricWF, specifically -

__FIRST_MOVER_ADVANTAGE

libc++ and libstdc++ have different 'uglification' protocols. As I said to mclow early on in this process, If I'm the one that has to do the grunt work of *all* of the uglification (very much has been case, BTW), it's going to follow libstdc++ convention as much as is possible.

libc++ code should follow libc++ conventions.

Just to be clear: PSTL is neither libc++ nor libstdc++. Louis kinda said so above, and Tom is making that point too, but I want to reiterate it. It's overall a silly bikeshedding point, but it's critical to keep everyone happy. PSTL isn't more "ours" than "theirs" (or rather, it's "ours" in that we're all in the same C++ team). This point was critical in getting PSTL to be a shared resource in the first place, and I don't want to walk back this commitment.

As Tom mentions above, we've talked about having tooling to massage PSTL to libc++'s and libstdc++'s liking on integration. Without volunteers to write said tooling, we should just accept slight ache when integrating PSTL, as we see here when integrating it into libc++.

The process of applying this kind of change is very error prone. I still have a patch coming that fixes a few cases I missed. That's the bigger argument IMO for tooling than the specific format.

I think I'm missing yours and JF's point. I don't understand why you need any tooling. All I'm saying is that PSTL being under the LLVM umbrella should conform to the usual LLVM code style, which used single underscore + capitals for macros unless I'm mistaken. libstdc++ and libc++ wouldn't apply any code transformation on the PSTL sources after that, it would just use it as a separate library and there wouldn't be very many PSTL macros used inside libstdc++/libc++. Only those macros that are part of the PSTL's interface, and yes, those would be using the PSTL's naming convention.

IOW, this is something that we simply missed in the initial check-in.

• [pstl] Supply definition of __PSTL_ASSERT() only if not already defined

In D60480#1461555, @jfb wrote:

In D60480#1460733, @EricWF wrote:

In D60480#1460729, @rodgert wrote:

Not sure what is up with phabricator, but it won't let me respond inline to EricWF, specifically -

__FIRST_MOVER_ADVANTAGE

libc++ and libstdc++ have different 'uglification' protocols. As I said to mclow early on in this process, If I'm the one that has to do the grunt work of *all* of the uglification (very much has been case, BTW), it's going to follow libstdc++ convention as much as is possible.

libc++ code should follow libc++ conventions.

Just to be clear: PSTL is neither libc++ nor libstdc++. Louis kinda said so above, and Tom is making that point too, but I want to reiterate it. It's overall a silly bikeshedding point, but it's critical to keep everyone happy. PSTL isn't more "ours" than "theirs" (or rather, it's "ours" in that we're all in the same C++ team). This point was critical in getting PSTL to be a shared resource in the first place, and I don't want to walk back this commitment.

As Tom mentions above, we've talked about having tooling to massage PSTL to libc++'s and libstdc++'s liking on integration. Without volunteers to write said tooling, we should just accept slight ache when integrating PSTL, as we see here when integrating it into libc++.

In D60480#1461436, @ldionne wrote:

In D60480#1461416, @rodgert wrote:

In D60480#1461369, @ldionne wrote:

In D60480#1460728, @rodgert wrote:

In D60480#1460300, @ldionne wrote:

I also suggest:

• Removing the <algorithm> & friends headers from PSTL itself. Those don't belong there, they belong with the standard library.

WDYT @rodgert ?

If we remove them, then we sort of lose the ability to test pstl outside of standard library, no? I'm not going to be testing or packaging libc++ most likely, but I am going to be contributing changes here and running tests within the context of libstdc++. Having the ability to test changes to the library independent of any integration with another standard library is still useful for me.

I believe those headers should be provided by a dummy standard library that we use only to run the tests. Basically we'd have a dummy standard library in pstl/test that would define these headers, and that's what we would run the tests against.

That would work for me...AND...we can probably remove the per-test #ifdef for the standalone checks, centralize it in the dummy standard headers in 'pstl/test' which would be much cleaner than what is currently there.

Ok, I'll submit a patch for that.

Lastly, about the __PSTL_XXX vs _PSTL_XXX: This patch is using what's in PSTL today, that's all. As a separate change, I thought about changing all __PSTL_XXX macros to be _PSTL_XXX to follow the more common convention (underscore-capital or double-underscore-lowercase), but this is a change separate from the integration into libc++.

JF and I discussed possibly some tooling for this sort of thing. I'm still interested in looking at that, I just don't see a lot of value in changing it by hand just to comply with conflicting conventions between standard library implementations.

I don't think the conventions used in PSTL should conform to the coding standard in any one standard library implementation. It's a library on its own. I think it should conform to its own coding standards, and in this case, I think those coding standard should be that of LLVM. Does this point of view make sense?

In D60480#1461369, @ldionne wrote:

In D60480#1460728, @rodgert wrote:

In D60480#1460300, @ldionne wrote:

The purpose of this review is to expose how I plan to integrate the parallel STL into libc++, and to discuss some changes that are desirable in pstl for this to be possible. This is a work in progress, obviously, and it's meant as a concrete support for having discussions.

Concrete changes I think we need to make in pstl:

• Rename all the files to double underscores.

This isn't a libstdc++ convention, but I'm not opposed.

The problem with not doing that is that our headers could collide with user's header files.

Not sure what is up with phabricator, but it won't let me respond inline to EricWF, specifically -

In D60480#1460300, @ldionne wrote:

The purpose of this review is to expose how I plan to integrate the parallel STL into libc++, and to discuss some changes that are desirable in pstl for this to be possible. This is a work in progress, obviously, and it's meant as a concrete support for having discussions.

Concrete changes I think we need to make in pstl:

• Rename all the files to double underscores.

This isn't a libstdc++ convention, but I'm not opposed.

In D59813#1454566, @MikeDvorskiy wrote:

Of course. I will configure "ninja" for running the upstream test.

I am also in favor of this.

Committed by other, non-phab, means

Committed by other, non-phab, means

Committed by other, non-phab, means

Committed by other, non-phab, means

Committed by other, non-phab, means

Committed by other, non-phab, means

Committed by other, non-phab, means

Committed by other, non-phab, means

Applied by "other means"

In D59704#1439794, @ldionne wrote:

I don't see a big problem with this change per-se, but can you please expand on the bit where you say:

It may be necessary for the other back-ends, where dynamic memory is not available and custom memory allocator may be provided by a custom policy.

How would you somehow handle allocation through a custom policy?

• Remove nested CMakeLists.txt in test/std, replace with glob-recurse

In D59110#1426159, @ldionne wrote:

To be clear about what I'd like: please do not add CMakeLists.txts all over the tree, instead keep relying on GLOB_RECURSE like my current test/CMakeLists.txt does.

@ldionne - When Intel added multiple new algorithm implementations, they did so without qualifying these calls. This led to a situation where some were and some weren't qualified.

In D59111#1423235, @ldionne wrote:

Do you want me to commit this?

Will resubmit (as discussed) as a couple of smaller patches

In D58852#1418265, @MikeDvorskiy wrote:

pstl_config.h is not required

Thomas, could you please clarify it?

The fact is the file contains significant macros, which are used in simd bricks, and the other useful macros.

In D58852#1416945, @ldionne wrote:

Do you think you could split this change into smaller changes? Perhaps one that removes the support for the Makefile tests, one that introduces forward declarations, and one that renames the test suite files?

I'm going to resubmit this as a set of smaller patches

• Introduce forward declaratoins
• Deprecate non-cmake build and test suite

• Remove unused include

• Introduce forward definitions

• Add ifdef guards for parallel overloads

Added a reply note to Mihail and Alexey's inline commentary on whether __PSTL_USE_PAR_POLICIES is how we really want to be controlling this.

See inline notes on __PSTL_USE_PAR_POLICIES #ifdefs

See inline comment

Ignore this version, Intel changed the definitions of most (all?) of these entry points in the version committed to LLVM, will resubmit after fixing signatures