dpcpp lacking C++11 features according to Boost

[Michael_Lass]

Hi,

compiling the following minimal program with dpcpp 2022.1.0.20220316 and Boost 1.77 fails:

#include <boost/math/distributions/chi_squared.hpp>
int main() {
  return 0;
}

The error messages are:

/opt/software/pc2/EB-SW/software/Boost/1.77.0-GCC-11.2.0/include/boost/math/special_functions/detail/bernoulli_details.hpp:560:4: error: unknown type name 'atomic_counter_type'
atomic_counter_type m_counter, m_current_precision;
^
/opt/software/pc2/EB-SW/software/Boost/1.77.0-GCC-11.2.0/include/boost/math/special_functions/detail/bernoulli_details.hpp:413:41: error: unknown type name 'atomic_integer_type'
m_counter.store(static_cast<atomic_integer_type>(bn.size()), std::memory_order_release);
^
/opt/software/pc2/EB-SW/software/Boost/1.77.0-GCC-11.2.0/include/boost/math/special_functions/detail/bernoulli_details.hpp:525:41: error: unknown type name 'atomic_integer_type'
m_counter.store(static_cast<atomic_integer_type>(bn.size()), std::memory_order_release);
^
3 errors generated.

Building against Boost 1.76 or older version works properly but throws the following warnings:

/opt/software/pc2/EB-SW/software/Boost/1.76.0-GCC-10.3.0/include/boost/math/tools/cxx03_warn.hpp:99:1: warning: CAUTION: One or more C++11 features were found to be unavailable [-W#pragma-messages]

/opt/software/pc2/EB-SW/software/Boost/1.76.0-GCC-10.3.0/include/boost/math/tools/cxx03_warn.hpp:100:1: warning: CAUTION: Compiling Boost.Math in pre-C++11 conformance modes is now deprecated and will be removed from March 2021. [-W#pragma-messages]

/opt/software/pc2/EB-SW/software/Boost/1.76.0-GCC-10.3.0/include/boost/math/tools/cxx03_warn.hpp:101:1: warning: CAUTION: Define BOOST_MATH_DISABLE_DEPRECATED_03_WARNING to suppress this message. [-W#pragma-messages]

/opt/software/pc2/EB-SW/software/Boost/1.76.0-GCC-10.3.0/include/boost/math/tools/cxx03_warn.hpp:102:1: warning: CAUTION: This message was generated due to the define: BOOST_NO_CXX11_THREAD_LOCAL [-W#pragma-messages]

Boost seems to think we are using a pre C++11 compiler. The math library in Boost 1.77 then seemingly has dropped support for those.

Further notes:

• The problem only occurs with dpcpp. icpx compiles the program without problems.
• Explicitly setting a language standard, e.g., using -std=c++17 does not help.
• The operating system here is a RHEL 8.5.

[Michael_Lass]

This might very well be an issue with the Boost compiler and stdlib recognition. Adding

#define BOOST_NO_STDLIB_CONFIG

to the very top of the test program solves the problem. This is documented here: https://www.boost.org/doc/libs/master/libs/config/doc/html/index.html

[VidyalathaB_Intel]

Hi Michael,

Thanks for reaching out to us.

>>This might very well be an issue with the Boost compiler and stdlib recognition.... solves the problem.

Glad to know that your issue is resolved and thanks for letting us know about it.

As the issue is resolved, could you please confirm if we can close this thread from our end?

Regards,

Vidya.

[Michael_Lass]

Sorry, that was phrased ambiguously. Adding that line circumvents the problem, which hints towards where the problem lies. Of course, Boost and dpcpp should work together out of the box. So I would not consider this solved. If the problem is actually on dpcpp's or Boost's side I so far cannot tell.

[VidyalathaB_Intel]

Hi Michael,

I apologize for the misunderstanding here.

Yes, as you mentioned the issue is reproducible with dpcpp but it is compiling fine with icpx/icx/icpc compilers.

We are working on your issue, we will get back to you soon.

Regards,

Vidya.

[Klaus-Dieter_O_Intel · Accepted solution]

Presumably this was an issue in Boost 1.77. It cannot be reproduced with Boost 1.78 or the latest 1.79. The compilation with the newer Boost versions work out of the box. Please check.

[Michael_Lass]

Thanks for testing on your end. Indeed this specific error is gone with Boost 1.78. The reason is the following change in Boost:

• Allow Bernoulli code to be used on platforms with no atomic integers.

This however only hides the underlying issue which I now tracked down further: dpcpp handles an if-else preprocessor block that checks for preprocessor variables from <atomic> wrong. Here is a minimal reproducer:

#include <atomic>

#if ATOMIC_INT_LOCK_FREE == 2
# warning int is lock free
#else
# warning int is NOT lock free
#endif

Compiling this with icpx -c test.cpp yields the expected warning:

test.cpp:4:3: warning: int is lock free [-W#warnings]
# warning int is lock free
^
1 warning generated.

Compiling with dpcpp -c test.cpp outputs both warnings, i.e., it interprets if and else block:

test4.cpp:6:3: warning: int is NOT lock free [-W#warnings]
# warning int is NOT lock free
^
1 warning generated.
test4.cpp:4:3: warning: int is lock free [-W#warnings]
# warning int is lock free
^
1 warning generated.

This looks very wrong to me. I think this then causes boost::multiprecision::detail to set up preprocessor variables and datatypes the wrong way which leads to the issue originally reported in this thread.

I was not able to reproduce this with simple custom preprocessor macros, so it may be specific to those macros from <atomic>. It seems that a sycl-specific header file is used in oneAPI: dpcpp-ct/2022.1.0/include/dpct/atomic.hpp

[Klaus-Dieter_O_Intel]

The 2 warnings are for the 2 different compilation phases CPU (lock free) and device (NOT lock free). Details for both phases will be shown by using flag "-v" (but not used below):

+ icpc -E test_atomic.cpp -o test_atomic_icpc.i

test_atomic.cpp(4): warning #1224: #warning directive: int is lock free

 # warning int is lock free

  ^

+ dpcpp -fno-sycl -E test_atomic.cpp -o test_atomic_dpcpp-fno-sycl.i

test_atomic.cpp:4:3: warning: int is lock free [-W#warnings]

# warning int is lock free

 ^

1 warning generated.

+ dpcpp -fsycl-device-only -E test_atomic.cpp -o test_atomic_dpcpp-fsycl-device-only.i

test_atomic.cpp:6:3: warning: int is NOT lock free [-W#warnings]

# warning int is NOT lock free

 ^

1 warning generated.

dpcpp-ct/2022.1.0/include/dpct/atomic.hpp is not used (also not seen if removing the first match "-m1"):

+ egrep -m1 '/atomic' *.i

test_atomic_dpcpp-fno-sycl.i:# 1 "/usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/atomic" 1 3

test_atomic_dpcpp-fsycl-device-only.i:# 1 "/usr/lib/gcc/x86_64-redhat-linux/8/../../../../include/c++/8/atomic" 1 3

test_atomic_icpc.i:# 1 "/opt/intel/oneapi/compiler/2022.1.0/linux/bin/intel64/../../compiler/include/icc/atomic" 1 3

[Michael_Lass]

Thanks for the explanation! That means this behavior in fact was no bug but boost correctly determined that lock free atomic integers are missing (although only for the device and not for the host). Therefore parts of boost::math could not be used when compiling with dpcpp. With boost 1.78 they now also work without support for atomic integers.

I can also confirm that compiling the reproducer in the original post with boost 1.77 using dpcpp -fno-sycl works as well.

[VidyalathaB_Intel]

Hi Michael,

Thanks for accepting the solution.

Please post a new question if you need any additional assistance from Intel as this thread will no longer be monitored.

Regards,

Vidya.