4

According to cppreference, to determine if std::hardware_constructive_interference_size is usable it uses the following example:

#include <new>

#ifdef __cpp_lib_hardware_interference_size
    using std::hardware_constructive_interference_size;
    using std::hardware_destructive_interference_size;
#else
    // 64 bytes on x86-64 │ L1_CACHE_BYTES │ L1_CACHE_SHIFT │ __cacheline_aligned │ ...
    constexpr std::size_t hardware_constructive_interference_size
        = 2 * sizeof(std::max_align_t);
    constexpr std::size_t hardware_destructive_interference_size
        = 2 * sizeof(std::max_align_t);
#endif

However, my system defines __cpp_lib_hardware_interference_size but there is no symbol std::hardware_constructive_interference_size.

How can I handle this situation?
Is there a way to check if a symbol is defined?

  • Apple clang version 12.0.0 (clang-1200.0.32.29)
    Target: x86_64-apple-darwin19.6.0
    Thread model: posix
    InstalledDir: /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin
  • macOS Catalina 10.15.7 (MacBook Pro 2019)

CMakeLists.txt

cmake_minimum_required(VERSION 3.19)
project(untitled4)

set(CMAKE_CXX_STANDARD 17)
set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -O3")
if (UNIX AND NOT APPLE)
    set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -fopenmp")
endif()

add_executable(untitled4 main.cpp)
김선달
  • 1,485
  • 9
  • 23
  • What value does `__cpp_lib_hardware_interference_size` have if you print it? Is it `>= 201703L`? When reading [an old LLVM mail thread](https://lists.llvm.org/pipermail/cfe-dev/2018-May/058073.html) I noticed that they were very reluctant to actually add it to their library and thought about writing a defect report to the standards committee instead. – Ted Lyngmo Jun 16 '21 at 09:19
  • It prints `201703`. That's strange... according to the comment at https://stackoverflow.com/a/39887282/8176989 the author of the proposal works at the Apple Clang team. – 김선달 Jun 17 '21 at 05:07
  • 1
    Well, a proposal has to come from _somewhere_ :-) Afaik, gcc has not implemented this either. I'm surprised that the feature test macro "lies" though. My `clang++-12` (on linux) does not define that macro. – Ted Lyngmo Jun 17 '21 at 05:35

1 Answers1

2

How can I handle this situation?

You could detect the broken language implementation using pre-defined macros and make an exception for it.

Detection could be made by trying to compile and run a small program:

#include <new>

int main() {
#ifdef __cpp_lib_hardware_interference_size
    // return 0 if the interference_sizes are defined
    return !(std::hardware_constructive_interference_size &&
             std::hardware_destructive_interference_size);
#else
    return 1; // no interference_sizes
#endif
}

clang++ -std=c++17 -o hwisize hwisize.cpp 2>/dev/null && ./hwisize
has_hw_interference_sizes=$?
  • If the compilation fails, has_hw_interference_sizes will be 1.
  • If the compilation succeeds, but __cpp_lib_hardware_interference_size is not defined, has_hw_interference_sizes will be 1.
  • If the compilation succeeds, and __cpp_lib_hardware_interference_size is defined, has_hw_interference_sizes will be 0.

(The reversed bool logic is how common shells define true (0) and false (not 0))

Just plug that into your build system.

Ted Lyngmo
  • 93,841
  • 5
  • 60
  • 108
eerorika
  • 232,697
  • 12
  • 197
  • 326