Fix C++20 macro in parallel_for_each + fix concepts macro definition

[kboyarinov]

Description

Add a comprehensive description of proposed changes

Fix two issues:

• parallel_for_each failed to compile on gcc9 since __TBB_CPP20_PRESENT was while STL concepts were used actually. Changed to __TBB_CPP20_CONCEPTS_PRESENT
• __TBB_CPP20_CONCEPTS_PRESENT macro was always defined to 0 for Intel Compiler and Clang. Changed to the detection based on Standard feature-test macros (the same approach as previously used for three-way-comparison)

Fixes #1552

Type of change

Choose one or multiple, leave empty if none of the other choices apply

Add a respective label(s) to PR if you have permissions

• bug fix - change that fixes an issue
• new feature - change that adds functionality
• tests - change in tests
• infrastructure - change in infrastructure and CI
• documentation - documentation update

Tests

• added - required for new features and some bug fixes
• not needed

Documentation

• updated in # - add PR number
• needs to be updated
• not needed

Breaks backward compatibility

• Yes
• No
• Unknown

Notify the following users

List users with @ to send notifications

Other information

[mmichel11]

@kboyarinov @dnmokhov @sarathnandu Could this PR please be prioritized for review? The bug is significantly impacting oneDPL's pass rate here as it shows up in our oneTBB backend, and it needs to be fixed for our upcoming milestone.

[aleksei-fedotov]

Looks good to me, but some tests on macOS fail. Is it because of the compiler not supporting concept specifics we use?

[kboyarinov]

@aleksei-fedotov @pavelkumbrasev @isaevil @sarathnandu @dnmokhov
I faced some unexpected and strange concept issues with clang on MacOS.
I propose to submit all of the other fixes now and keep the concepts disabled on MacOS. I will open an issue to fix that in the future or define the versions of Apple Clang that are not working with all or part of our concepts.
What do you think?

[sarathnandu]

@aleksei-fedotov @pavelkumbrasev @isaevil @sarathnandu @dnmokhov I faced some unexpected and strange concept issues with clang on MacOS. I propose to submit all of the other fixes now and keep the concepts disabled on MacOS. I will open an issue to fix that in the future or define the versions of Apple Clang that are not working with all or part of our concepts. What do you think?

I agree, since this patch is affecting oneDPL's pass rate and they are waiting for this patch to be merged. We can investigate the MacOS build issue separately.

[phprus]

I think this is a bug in Clang (not only AppleClang):
llvm/llvm-project#61763

The bug is fixed in version LLVM 18.1.0.

AppleClang from Xcode 16.2 based on LLVM 17.

[sarathnandu]

LGTM!

[sarathnandu]

The icpx compiler is also failing. I have tested on Intel(R) oneAPI DPC++/C++ Compiler 2023.2.0 (2023.2.0.20230721)

I believe you need to disable it for all clang not just clang && APPLE.

[dnmokhov]

I think this is a bug in Clang (not only AppleClang): llvm/llvm-project#61763

The bug is fixed in version LLVM 18.1.0.

AppleClang from Xcode 16.2 based on LLVM 17.

I agree that we should just disable these concepts with any Clang for now.

My results of compiling test_blocked_range.cpp on Ubuntu:

• Clang 14.0.0 - compiles
• Clang 15.0.0 - compiles
• Clang 17.0.1 - same compilation error as in MacOS CI above
• Clang 18.1.0 - compiles
• Clang 19.1.0 - internal compiler error

[aleksei-fedotov]

I think this is a bug in Clang (not only AppleClang): llvm/llvm-project#61763
The bug is fixed in version LLVM 18.1.0.
AppleClang from Xcode 16.2 based on LLVM 17.

I agree that we should just disable these concepts with any Clang for now.

My results of compiling test_blocked_range.cpp on Ubuntu:

• Clang 14.0.0 - compiles
• Clang 15.0.0 - compiles
• Clang 17.0.1 - same compilation error as in MacOS CI above
• Clang 18.1.0 - compiles
• Clang 19.1.0 - internal compiler error

Should not we then check the clang's version and enable concepts only if the version is not 17 or not 19? We have __TBB_CLANG_VERSION macro.

[kboyarinov]

I think this is a bug in Clang (not only AppleClang): llvm/llvm-project#61763
The bug is fixed in version LLVM 18.1.0.
AppleClang from Xcode 16.2 based on LLVM 17.

I agree that we should just disable these concepts with any Clang for now.
My results of compiling test_blocked_range.cpp on Ubuntu:

• Clang 14.0.0 - compiles
• Clang 15.0.0 - compiles
• Clang 17.0.1 - same compilation error as in MacOS CI above
• Clang 18.1.0 - compiles
• Clang 19.1.0 - internal compiler error

Should not we then check the clang's version and enable concepts only if the version is not 17 or not 19? We have __TBB_CLANG_VERSION macro.

I agree, we can enable back concepts on the clang versions not affected by the issue described above.
An other option we have is not to disable concepts completely since the issue only affects TBB classes that uses a constrained friend declaration inside (like blocked_range that friends blocked_range2d.

I still propose to keep concepts on clang totally disabled for this release and create a separate issue for enabling it to make sure other fixes introduced in this patch are landed. I still feel that we need to test the potential fix better on different versions of clang on both Linux and MacOS before enabling concepts.

[aleksei-fedotov]

Okay, let's have it disabled for Clang in this release.

[sarathnandu]

LGTM

[mcaryl-digitalbarriers]

Thanks for this.