In D150159#4346788, @sscalpone wrote:

Hi Mehdi,

It's a good idea to guard CUDA Fortran dependencies on CUDA in a similar way to how clang's CUDA C++ dependencies on CUDA are guarded.

This patch is front end work; because there's no lowering yet, there's no need to add such CMake options yet. The feature is gated from Fortran users by way of a special required file extension (.cuf).

Could you at least make CUDA-Fortran support behind a CMake option.
As a package manager on platform where CUDA is not supported (I am sure I am not alone), I don't want to fix code that will never benefit my platform.
You know this a community project, CUDA is not supported everywhere.

There is a big difference between CUDA and CUDA-Fortran.
CUDA could be used by any compiler MSVC, Intel, IBM, GNU... as It doesn't require any support from the compiler. It's just libraries+headers.
While CUDA-Fortran requires a support from the compiler itself.
GCC, Intel, Cray, Fujitsu ... compilers do not support it because It's just an Nvidia/PGI dialect, Flang-Classic is just an open-sourced Frontend of PGI compiler.
We are talking here about a company pushing for a dialect not widely used by the community.
If you fellow many discussions online in Fortran community, you know for sure that PGI compiler is one of the least/worst used compiler.
I think Nvidia should keep CUDA-Fortran support in the commercial/proprietary compiler that will be based on flang.

Shouldn't an RFC be opened before start upstreaming CUDA stuff.
Is the community OK with supporting this Nvidia/PGI language extension/dialect?
If for example Intel invents a new extension based OneAPI/SYCL, Should Flang supports it?
There should be a policy for this kind of changes.

In D147768#4257566, @mmuetzel wrote:

There is no 80-bit floating point type in Fortran afaict, is there?
The LLVM IR emitted for COMPLEX*32 (corresponding to complex __float128 in C afaict) looks correct to me with the changes from here.

How about extended precision (80bit) which is supported by LLVM/Clang on MINGW.

Thanks

Could someone push it for me, Please!

Apply suggestions from reviewer

Address reviewer comment

ping!

> Does LLVM build successfully with /permissive-?
Yes, It does. You could check the windows build yourself
There was a failure with flang that we fixed it.

ping!

Thanks.

In D125262#3525059, @Meinersbur wrote:

LGTM

In D125262#3512790, @Meinersbur wrote:

Please add a summary where you mention that CLOCK_REALTIME is POSIX defined and never available with msvc, even without /permissive-. The difference is that the template is never instantiated and the compiler ignores the undefined identifier.

This is the error message:

[6795/8382] Building CXX object tools\flang\runtime\CMakeFiles\obj.FortranRuntime.dir\time-intrinsic.cpp.obj
FAILED: tools/flang/runtime/CMakeFiles/obj.FortranRuntime.dir/time-intrinsic.cpp.obj
sccache C:\BuildTools\VC\Tools\MSVC\14.29.30133\bin\Hostx64\x64\cl.exe  /nologo /TP -DBUILD_EXAMPLES -DFLANG_LITTLE_ENDIAN=1 -DGTEST_HAS_RTTI=0 -DUNICODE -D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS -D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_HAS_EXCEPTIONS=0 -D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools\flang\runtime -IC:\ws\w3\llvm-project\premerge-checks\flang\runtime -IC:\ws\w3\llvm-project\premerge-checks\flang\include -Itools\flang\include -Iinclude -IC:\ws\w3\llvm-project\premerge-checks\llvm\include -IC:\ws\w3\llvm-project\premerge-checks\llvm\..\mlir\include -Itools\mlir\include -Itools\clang\include -IC:\ws\w3\llvm-project\premerge-checks\llvm\..\clang\include /DWIN32 /D_WINDOWS   /Zc:inline /Zc:__cplusplus /Zc:strictStrings /Oi /Zc:rvalueCast /bigobj /permissive- /W4 -wd4141 -wd4146 -wd4244 -wd4267 -wd4291 -wd4351 -wd4456 -wd4457 -wd4458 -wd4459 -wd4503 -wd4624 -wd4722 -wd4100 -wd4127 -wd4512 -wd4505 -wd4610 -wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 -wd4389 -wd4611 -wd4805 -wd4204 -wd4577 -wd4091 -wd4592 -wd4319 -wd4709 -wd4324 -w14062 -we4238 /Gw /MD /O2 /Ob2 -UNDEBUG -std:c++17  /EHs-c- /GR- /showIncludes /Fotools\flang\runtime\CMakeFiles\obj.FortranRuntime.dir\time-intrinsic.cpp.obj /Fdtools\flang\runtime\CMakeFiles\obj.FortranRuntime.dir\ /FS -c C:\ws\w3\llvm-project\premerge-checks\flang\runtime\time-intrinsic.cpp
C:\ws\w3\llvm-project\premerge-checks\flang\runtime\time-intrinsic.cpp(77): error C2065: 'CLOCK_REALTIME': undeclared identifier
C:\ws\w3\llvm-project\premerge-checks\flang\runtime\time-intrinsic.cpp(77): error C3861: 'CLOCK_REALTIME': identifier not found
C:\ws\w3\llvm-project\premerge-checks\flang\runtime\time-intrinsic.cpp(146): error C2065: 'CLOCK_REALTIME': undeclared identifier
C:\ws\w3\llvm-project\premerge-checks\flang\runtime\time-intrinsic.cpp(146): error C3861: 'CLOCK_REALTIME': identifier not found

https://buildkite.com/llvm-project/premerge-checks/builds/92047#ae63959e-de4c-4cf0-a663-eeab39a06ce8/410-7338

In D125262#3504589, @Meinersbur wrote:

Patch summary missing. What is failing with /permissive-?

In D122523#3433643, @mstorsjo wrote:

@MehdiChinoune can you provide your preferred form of the git author line, Real Name <email@address>?

Could someone push it for me, Please.

This commit make building standalone LLDB impossible on Windows. llvm/Config/config.h file is only generated at build-time and not get installed with llvm.
Please Fix it.

In D101842#2744348, @awarzynski wrote:

Address PR comments

Thank you for taking a look @Meinersbur. It sounds that instead of updating LLVM_ENABLE_PROJECTS, it will be better to generate an error when Clang is missing. What do you think?

In D100442#2702575, @ashermancinelli wrote:

In D100442#2693549, @MehdiChinoune wrote:

Could someone push this change p, please.

Do you have an email I can use for the commit author?

Could someone push this change p, please.

Update diff

In D96069#2687939, @Meinersbur wrote:

Sorry for the wait. Patch LGTM.

Would you like me to push it top main?

Ping

In D99835#2668075, @clementval wrote:

In D99835#2667872, @MehdiChinoune wrote:

In D99835#2667759, @Meinersbur wrote:

Could you please update D96069 instead?

I lost access to my old account.

You can take control of the patch with your new account with the “Commandeer revision” action.

In D99835#2667759, @Meinersbur wrote:

Could you please update D96069 instead?

I don't see any other error for now.

It works

I get this error:

D:\dev\llvm-project\flang\runtime\reduction.cpp(95): error C2059: syntax error: 'template'
D:\dev\llvm-project\flang\runtime\reduction.cpp(404): note: see reference to function template instantiation 'signed char Fortran::runtime::GetTotalReduction<Fortran::common::TypeCategory::Integer,1,Fortran::runtime::IntegerSumAccumulator<int>>(const Fortran::runtime::Descriptor &,const char *,int,int,const Fortran::runtime::Descriptor *,ACCUMULATOR &&,const char *)' being compiled
        with
        [
            ACCUMULATOR=Fortran::runtime::IntegerSumAccumulator<int>
        ]

Could you fix it?

It would be better if you exclude int128 intrinsic functions introduced in D99764

Other issues with MSVC:
1 - MSVC doesn't have __uint128 and __int128.
MSVC doesn't accept that portable Int128 type defined in uint128.h to be linked with a C function.
Maybe you should disable int128 intrinsic functions on the platforms where __unit128 and __int128 are not available

This commit breaks Building on MSVC.