[cfe-users] Usage of CLang CUDA target with MinGW stdlib

2018-11-02 Thread KOLANICH via cfe-users
Hello everybody.

Could anyone clarify how to use this cuda target (-std=c++11 -x cuda) with 
MinGW stdlib?

I mean I get errors

\LLVM-7.0.0-win32\lib\clang\7.0.0\include\cuda_wrappers\new:41:12: 
error: use of undeclared identifier 'malloc' return ::malloc(size);
\LLVM-7.0.0-win32\lib\clang\7.0.0\include\cuda_wrappers\new:58:7: 
error: no type named 'free' in the global namespace ::free(ptr);

and I wonder what I should do to fix them.
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users


Re: [cfe-users] Usage of CLang CUDA target with MinGW stdlib

2018-11-09 Thread KOLANICH via cfe-users
2018 11 9 18:38:24 UTC, Artem Belevich  пишет:
>+cc cfe-users back;
>
>On Thu, Nov 8, 2018 at 10:20 PM KOLANICH  wrote:
>
>> 2018 11 7 23:25:38 UTC, Artem Belevich  пишет:
>> >This may be same/similar to
>https://bugs.llvm.org/show_bug.cgi?id=38811
>> >
>> >Basically, there's no owner for CUDA support on windows. Someone
>needs
>> >to
>> >figure out why/how CUDA includes behave differently under mingw and
>> >figure
>> >out how to work around that in the CUDA wrapper headers in clang.
>> >
>> >
>> >On Fri, Nov 2, 2018 at 2:23 PM KOLANICH via cfe-users <
>> >cfe-users@lists.llvm.org> wrote:
>> >
>> >> Hello everybody.
>> >>
>> >> Could anyone clarify how to use this cuda target (-std=c++11 -x
>cuda)
>> >with
>> >> MinGW stdlib?
>> >>
>> >> I mean I get errors
>> >>
>> >>
>>
>>
>>\LLVM-7.0.0-win32\lib\clang\7.0.0\include\cuda_wrappers\new:41:12:
>> >> error: use of undeclared identifier 'malloc' return
>::malloc(size);
>> >>
>>
>>
>>\LLVM-7.0.0-win32\lib\clang\7.0.0\include\cuda_wrappers\new:58:7:
>> >> error: no type named 'free' in the global namespace ::free(ptr);
>> >>
>> >> and I wonder what I should do to fix them.
>> >> ___
>> >> cfe-users mailing list
>> >> cfe-users@lists.llvm.org
>> >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users
>> >>
>>
>> Thank you for the suggestion. But this doesn't clarify the strange
>syntax
>> used in the mentioned lines.
>
>
>You need to look at the preprocessed output in order to see what is it
>that
>clang is complaining about.
>
>
>> I googled a bit and haven't found anything clarifying, but there are
>some
>> hints suggesting that it may be specific to Visual Studio.
>>
>
>It's quite likely. Clang's wrappers for C++ standard library are fairly
>specific to particular library. AFAICT we never even tried to make it
>work
>with whatever VC uses.
>
>
>>
>> P.S. I don't use CUDA headers
>
>You actually do. With  "-x cuda" clang pre-includes ton of CUDA headers
>(same as nvcc) and adds extra include search paths.
>If you do not want to pre-include any CUDA headers, then you need to
>pass
>-nocudainc option.
>
>
>
>> - I have AMD GPU and there is a CUDA impl for any OpenCL-capable
>device
>> having own headers, which may be far more compatible that the ones
>provided
>> by CUDA.
>
>
>Interesting. Can you tell me more about this CUDA-over-OpenCL project?
>
>
>> The problem I encounter in the headers shipped with CLang, it seems
>they
>> depend on something missing in MinGW headers.
>>
>
>Those headers are only intended to make clang work with NVIDIA's CUDA
>SDK
>on linux. MinGW + a project that provides alternative CUDA headers is
>unlikely to work as is. -nocudainc should get clang's headers out of
>your
>way, but it will be up to you to provide the equivalent.
>
>Good luck,

>Interesting. Can you tell me more about this CUDA-over-OpenCL project?

https://github.com/hughperkins/coriander

I'm not very involved into it yet, I just try to brign it up on Windows upon 
MinGW+CLang instead of MSVC+CLang. I have managed to make it buildable by MinGW 
( https://github.com/hughperkins/coriander/pull/76 ), but running the compiler 
doesn't work for now. In order to try to run it one needs to modify 
https://github.com/hughperkins/coriander/blob/master/bin/cocl.py#L316 : add 
there msvc-compatibility flags, undef MSVC-specific macrodefs in order  add 
some macrodefs like __STRICT_ANSI__,  uncomment 
https://github.com/hughperkins/coriander/blob/master/bin/cocl.py#L326L328 and 
add there some paths ...

> -nocudainc should get clang's headers out of
>your
>way, but it will be up to you to provide the equivalent.

Yes, corriander provides replacements for NVidia headers. But the problem is in 
the header shipped with CLang.


>You need to look at the preprocessed output in order to see what is it
>that
>clang is complaining about.

Thank you for the advices.



___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users


Re: [cfe-users] build errors with MinGW-W64 GCC-8.1.0 on Windows

2018-11-12 Thread KOLANICH via cfe-users
Hello, Maarten.

I have partially built LLVM with MinGW-w64 8.1.0 (some llvm shared libs needed, 
not clang and stdlib). 

For experimenting with build I personally recommend using ninja instead of 
mingw32-make because it allows resuming without rebuilding everything from 
scratch if I added a linker flag into a CMake cache variable.

> So I think it would have been better to select the Mingw-w64 x86_64-win32-seh 
> or even x86_64-win32-sjlj version instead?

I guess, no. If something somewhere uses std::thread and other threading stuff, 
you will have problems since "win32" versions of the toolchain lack it since it 
is implemented upon pthreads.

> 'InitOnceExecuteOnce' was not declared in this scope

some header is needed and it exists in MinGW since I get another error that the 
symbol is not found on linking stage (so yo may have problem with it anyway).
___
cfe-users mailing list
cfe-users@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-users