oneapi-src / oneDPL

oneAPI DPC++ Library (oneDPL) https://software.intel.com/content/www/us/en/develop/tools/oneapi/components/dpc-library.html
Apache License 2.0
724 stars 113 forks source link

OneDPL headers inside extern "C++" wrapper #225

Closed abagusetty closed 3 years ago

abagusetty commented 3 years ago

Can some one please provide any pointer to this build issue.

While compiling a cxx source file or compilation unit (using dpcpp compiler) the first line has #define _GLIBCXX_USE_TBB_PAR_BACKEND 0 // for GCC 10 to address limitations between oneTBB and oneDPL according to the release notes. This line has resolved the issues with oneTBB (task) build errors as documented in the release notes.

The below error was generated using an application with C++ source file involving 3 headers. Out of these 3 headers, 2 headers contain standard ISO C++ headers and the other has a mixture of oneDPL, SYCL and some more C++ headers.

I wasn't able to reproduce this build issue using an isolated test case with oneDPL, C++ headers and defining appropriate macro to ZERO.

In file included from /soft/......./sdk/2021.04.30.001/oneapi/dpl/latest/linux/include/oneapi/dpl/execution:32:
In file included from /soft/packaging/spack-builds/linux-opensuse_leap15-x86_64/gcc-10.2.0/gcc-10.2.0-yudlyezca7twgd5o3wkkraur7wdbngdn/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/execution:38:
/soft/packaging/spack-builds/linux-opensuse_leap15-x86_64/gcc-10.2.0/gcc-10.2.0-yudlyezca7twgd5o3wkkraur7wdbngdn/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/pstl/glue_algorithm_impl.h:30:12: error: use of undeclared identifier '__internal'; did you mean '__pstl::__internal'?
    return __internal::__pattern_any_of(
           ^
/soft/packaging/spack-builds/linux-opensuse_leap15-x86_64/gcc-10.2.0/gcc-10.2.0-yudlyezca7twgd5o3wkkraur7wdbngdn/lib/gcc/x86_64-pc-linux-gnu/10.2.0/../../../../include/c++/10.2.0/pstl/numeric_fwd.h:18:11: note: '__pstl::__internal' declared here
namespace __internal
          ^           

GCC: gcc (Spack GCC) 10.2.0 DPCPP: Intel(R) oneAPI DPC++/C++ Compiler 2021.2.0 (2021.x.0.20210323)

andreyfe1 commented 3 years ago

Hi @abagusetty, Actually we didn't face it before and couldn't reproduce it locally. Just some thoughts:

  1. Do you have any using namespace ... in your code?
  2. Do you call the any_of algorithm?
abagusetty commented 3 years ago

Hey @capatober Thanks again for taking a peek at this issue.

No, I didnt have both the use of using namespace and even any_of algo in the entire code base. I have also updated the entire set of errors if it provides a clearer picture. It looks like every other line of glue_algorithm_impl is reporting

abagusetty commented 3 years ago

@capatober My colleague was able to create a reproducer for this issue. The above compilation errors pop up when wrapping onedpl headers in extern "C++" clause with dpcpp compiler as was done in one of our internal codes. Hope this helps to take a peek.

#define _GLIBCXX_USE_TBB_PAR_BACKEND 0

extern "C++" {
    #include <oneapi/dpl/algorithm>
    #include <oneapi/dpl/execution>
    #include <oneapi/dpl/iterator>
    #include <oneapi/dpl/functional>
}

int main()
{
    int n = 100;
    int *a = (int *)malloc( n*sizeof(int) );
    for(int i=0; i<n; ++i ) a[i] = i;
    printf("done %d\n", a[0] );
    return 0;
}
rarutyun commented 3 years ago

The interesting case is that it's enough to use just headers from GNU C++ standard library with clang compiler. Even the code snippet below allows to reproduce the issue with right environment (clang version: 11.01, GNU C++ standard library version: 10.2.0, compiler flags: -std=c++17)

extern "C++" {
    #include <execution>
}

Other combinations of clang and GNU C++ standard library versions are also possible. That one is just convenient to reproduce on godbolt: https://godbolt.org/z/esefzonh9

Wrapping #include directive with extern "C++" block is essential. Without it the code snippet above can be compiled.

On GCC this issue is not reproducible.

Basing on the information above I tend to think that this is the compiler front-end issue. As you can see oneDPL participates in the reproducer no longer