llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
28.87k stars 11.92k forks source link

clang: OpenMP conflict with #include <format> #105498

Open wmurw opened 2 months ago

wmurw commented 2 months ago

clang 18.1.8 clang 17.0.3 (from Visual Studio 2022)

Under windows code:

#include <iostream>
#include <chrono> 
#include <omp.h>

int main()
{
#pragma omp parallel
    std::cout << "Hello from thread " << omp_get_thread_num() << ", nthreads " << omp_get_num_threads() << "\n"; 
};

when compiling: clang++ main.cpp -std=c++23 -O2 -fopenmp generates an error:

C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\include\format:3204:54: error: capturing a
      structured binding is not yet supported in OpenMP
 3204 |         return _STD _Widen_and_copy<_CharT>(_Buffer, _End, _STD move(_Out));
      |                                                      ^
C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\include\format:3188:17: note: '_End' declared
      here
 3188 |     const auto [_End, _Ec] = _STD to_chars(_Buffer, _STD end(_Buffer), reinterpret_cast<uintptr_t>(_Value), 16);
      |                 ^
1 error generated.

although format is not used here and there is not even #include <format> (it is inside iostream and chrono) Without #include <chrono> the code compiles with -std=c++20

There is no problem when compiling msvc, although the same microsoft header files are used.

When compiling MinGW with its alternative std there is no problem either.

EugeneZelenko commented 2 months ago

Could you please try 19 or main branch? https://godbolt.org should be helpful.

wmurw commented 2 months ago

At https://godbolt.org/ everything works in x86-64 clang 18.1.0 - no this problem there I installed clang using LLVM-18.1.8-win64.exe I don't understand how to use clang 19.

I believe godbolt.org uses std not from microsoft, so it works there. But I have clang using microcoft's std by default. The -I and -L keys pointing to include and lib from MinGW don't change anything. I was able to use MinGW's std using the clang --target=x86_64-w64-mingw32 switch, but this only works without OpenMP. The key combination --target=x86_64-w64-mingw32 -fopenmp gives an error:

C:\mingw64\bin\ld.exe: cannot find -lomp: No such file or directory
clang++: error: linker command failed with exit code 1

MinGW compiles OpenMP programs without this error.

MinGW is taken from here, variant: x86_64-13.2.0-release-posix-seh-msvcrt-rt_v11-rev0.

wmurw commented 2 months ago

clang 18.1.8 from msys2 doesn't have this problem I want llvm-project to be free of it.

tonideleo commented 1 month ago

I am having the same issue, clang 18.1.8 from windows visual studio. OpenMP and format libraries do not work together.

llvmbot commented 1 month ago

@llvm/issue-subscribers-clang-frontend

Author: Юрий Муравьёв (wmurw)

clang 18.1.8 clang 17.0.3 (from Visual Studio 2022) Under windows code: ```C++ #include <iostream> #include <chrono> #include <omp.h> int main() { #pragma omp parallel std::cout << "Hello from thread " << omp_get_thread_num() << ", nthreads " << omp_get_num_threads() << "\n"; }; ``` when compiling: `clang++ main.cpp -std=c++23 -O2 -fopenmp` generates an error: ```C++ C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\include\format:3204:54: error: capturing a structured binding is not yet supported in OpenMP 3204 | return _STD _Widen_and_copy<_CharT>(_Buffer, _End, _STD move(_Out)); | ^ C:\Program Files\Microsoft Visual Studio\2022\Community\VC\Tools\MSVC\14.40.33807\include\format:3188:17: note: '_End' declared here 3188 | const auto [_End, _Ec] = _STD to_chars(_Buffer, _STD end(_Buffer), reinterpret_cast<uintptr_t>(_Value), 16); | ^ 1 error generated. ``` although `format` is not used here and there is not even `#include <format>` (it is inside `iostream` and `chrono`) Without `#include <chrono>` the code compiles with `-std=c++20` There is no problem when compiling _msvc_, although the same microsoft header files are used. When compiling _MinGW_ with its alternative `std` there is no problem either.