Hi! To close the loop:
On Fri, 9 Mar 2018 09:32:11 +0100, Siegmar Gross <siegmar.gr...@informatik.hs-fulda.de> wrote: > Am 09.03.2018 um 08:44 schrieb Jakub Jelinek: > > On Fri, Mar 09, 2018 at 07:56:38AM +0100, Siegmar Gross wrote: > >> some days ago I've installed gcc-8-20180225 with accelerator support on my > >> "SUSE Linux Enterprise Server 12.3 (x86_64)" with gcc-6.4.0. Yesterday I > >> tried to add the languages objc, obj-c++, and go to my installation. > >> Unfortunately, I lost the OpenMP support. Adding the languages > >> step-by-step, I found out that "go" is responsible for the problem. (OpenACC/OpenMP usage in Objective-C and Objective-C++ code might somewhat work, or require not too much effort to get implemented, for these front ends are, as far as I remember, mostly implemented on top of the C and C++ front ends, but that would be completely untested, to the best of my knowledge. And certainly no attention has been paid so far for any specialities of these C/C++ "dialects".) > > Why are you doing it at all? > > In the OpenMP/OpenACC offloading compiler, you only need the LTO "frontend", > > and libraries built for C, C++ and Fortran as those are the languages > > supported by OpenMP/OpenACC. Specifically, these are the *only* languages supported per the current OpenACC/OpenMP standards. That's not a hard limitation though: one could add support for other languages to the OpenACC/OpenMP standards. There currently isn't code offloading support in GCC for any other languages; offloading currently is available only via OpenACC/OpenMP. Other languages maybe might support code offloading via different mechanisms than the source code pragmas used for OpenACC/OpenMP. These different mechanisms could then be mapped to the existing offloading support in GCC, extending that as needed. For example, one could add logic to GCC to analyze any language's code in its common intermediate representation in GCC, and automatically figure out which computations make sense to distribute to SMP CPUs (see "-ftree-parallelize-loops"), or to offload to a GPU etc. This is, however, a totally non-trivial amount of work. :-) (This relates to the poor support in GCC for the OpenACC kernels construct, compared to the much more mature support for the OpenACC parallel and OpenMP target constructs.) We're available for contracting on all such things, if I may add that here. > > You don't need anything else. And, Go doesn't > > support NVPTX at all. Ada probably doesn't either. > > You are right. I'm using C and OpenMP/OpenACC for CPUs and accelerators, but a > colleague of mine wants to use the other languages, so that I tried to build > them as well. Grüße Thomas
