This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: gcc-8-20180225: "go" breaks building OpenMP
Hi!
To close the loop:
On Fri, 9 Mar 2018 09:32:11 +0100, Siegmar Gross <siegmar.gross@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