From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ot1-x32b.google.com (mail-ot1-x32b.google.com [IPv6:2607:f8b0:4864:20::32b]) by sourceware.org (Postfix) with ESMTPS id 50EE0385702F for ; Sat, 5 Sep 2020 14:52:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 50EE0385702F Received: by mail-ot1-x32b.google.com with SMTP id a65so8552795otc.8 for ; Sat, 05 Sep 2020 07:52:34 -0700 (PDT) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=nky8mhdI93voVr4cMK0dSy+TgNRtlgJ36wfSHK+x29A=; b=nAReNyDerTwYhTM5JG/6VVQFYkhVKweil64aTgioe3ZUBW1gkdXVYpGELl1TUGFIiu n7KeCXFfU4w1S/eQ9gtXEIh55CjmheR/oSU7GEmlajAPKI30gz5f0lHEUMmltp5NkRtK XK4GNf+oyuztzEK6atd/YrQUst0IvoDOavjMd8716bLxZ+uSNJzOyQv5ePF3tRsVPcYo zQmL3/MkPyIqWiPvOJdDX1l/3tFCRDIXfS7YawS5912uKXL1jvkRv2BXVDlnWFk5kEyJ 2hXFvDSWDwARiFdcTxbF7v6yQSoLD/Vq+6g92P15xueUlG05h0OaS8uNvlBqBR4gtohE QQ5Q== X-Gm-Message-State: AOAM532a4cO9BBHwp2LlJCcjVO8G9JUhum9gXyMVdKrCnNreyGxOn1DT Y+C/FkVhEWdbX+AkH/bsk3KMQekaXaKpuFevOHc= X-Google-Smtp-Source: ABdhPJwIiGE12W5p6r0pnT+oXf9p2jdaLEnZf2qXP4+knaJ5pkBBUTmfLdfeIGdjK2qYHp5106hY7BuVlRnFhRq4x+k= X-Received: by 2002:a9d:1d7:: with SMTP id e81mr8994256ote.86.1599317553596; Sat, 05 Sep 2020 07:52:33 -0700 (PDT) MIME-Version: 1.0 References: <3623842f-ac71-795f-4b0f-4cda4267258d@ceid.upatras.gr> <2cae69e9-66e3-523b-dfad-de7ceab59ad4@ceid.upatras.gr> In-Reply-To: <2cae69e9-66e3-523b-dfad-de7ceab59ad4@ceid.upatras.gr> From: Alin Marin Elena Date: Sat, 5 Sep 2020 15:52:22 +0100 Message-ID: Subject: Re: gfortran/OpenMP/declare target link issue To: "Ioannis E. Venetis" Cc: gcc-help Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-2.0 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, KAM_ASCII_DIVIDERS, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP, T_PDS_OTHER_BAD_TLD autolearn=no autolearn_force=no version=3.4.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 05 Sep 2020 14:52:36 -0000 Dear Ioannis, this is my experience with offloading using omp4... it is slightly out of date but i suspect syntax did not change. in the module that contains the data (i suspect in reality is a glorified common block) you need things like this ``` !$omp declare target(xxx,yyy,zzz,vxx,vyy,vzz,fxx,fyy,fzz) ``` then of course you will need to sync the data to device before the call of the routine ``` !$omp target map(to: imcon) & !$omp map(to: xxx,yyy,zzz) ``` Regards, Alin Without Questions there are no Answers! ______________________________________________________________________ Dr. Alin Marin ELENA http://alin.elena.space/ ______________________________________________________________________ On Sat, 5 Sep 2020 at 15:35, Ioannis E. Venetis w= rote: > > Any comment on this? Are global variables defined in a module and used > in subroutines in the target region supported through the declare target > link mechanism currently on gcc? If so, am I doing something wrong on > how to use that mechanism? If not, is there any other approach I could > follow without too many changes in the code? In the real code I have > about 20 such variables and the call tree in the target region goes up > to 3 subroutines deep. > > Ioannis E. Venetis > > On 3/9/2020 9:36 =CE=BC.=CE=BC., Ioannis E. Venetis wrote: > > Hello everyone, > > > > I have a larger program that I am trying to convert so that the > > computationally intensive part will run on an NVidia GPU using OpenMP. > > However, I am running into trouble when compiling the program. The > > part of the program to run on the GPU contains calls to subroutines, > > where variables declared in a separate module are used. This seems to > > be creating issues. I have reduced the problem to the attached files. > > > > I compile as follows: > > > > gfortran test_link.f90 common_vars.f90 parameters.f90 -O0 -fopenmp > > -Wall -Wextra -o test_link > > > > With the file test_link.f90 as attached, the program compiles and runs > > without a problem. > > > > If I remove the comments for the subroutine TEST() and comment out > > line 31 in test_link.f90 (the line "I =3D NR") the compilation gives th= e > > following error: > > > > ptxas /tmp/ccw3FqJD.o, line 52; error : Illegal operand type to > > instruction 'ld' > > ptxas /tmp/ccw3FqJD.o, line 52; error : Unknown symbol > > '__common_vars_MOD_nr$linkptr' > > ptxas fatal : Ptx assembly aborted due to errors > > nvptx-as: ptxas returned 255 exit status > > mkoffload: fatal error: > > /home/myself/apps/gcc-10.2.0/bin/x86_64-pc-linux-gnu-accel-nvptx-none-g= cc > > returned 1 exit status > > compilation terminated. > > lto-wrapper: fatal error: > > /home/myself/apps/gcc-10.2.0/libexec/gcc/x86_64-pc-linux-gnu/10.2.0//ac= cel/nvptx-none/mkoffload > > returned 1 exit status > > compilation terminated. > > /usr/bin/ld: error: lto-wrapper failed > > collect2: error: ld returned 1 exit status > > > > Is this a bug in gfortran or have I misunderstood how DECLARE TARGET > > LINK works in combination with using subroutines? > > > > And a last point: If I use -O3 during compilation the program compiles > > and runs fine in both cases. I assume that TEST() is inlined in this > > case and the error disappears? > > > > Any help to overcome this issue is more than welcome. > > > > Best regards, > > > > Ioannis E. Venetis > > > > PS1: The problem happens with gcc 10.2 that I compiled myself: > > > > $ ~/apps/gcc-10.2.0/bin/gfortran -v > > Using built-in specs. > > COLLECT_GCC=3D/home/myself/apps/gcc-10.2.0/bin/gfortran > > COLLECT_LTO_WRAPPER=3D/home/myself/apps/gcc-10.2.0/libexec/gcc/x86_64-p= c-linux-gnu/10.2.0/lto-wrapper > > > > OFFLOAD_TARGET_NAMES=3Dnvptx-none > > Target: x86_64-pc-linux-gnu > > Configured with: ../gcc-10.2.0/configure > > --enable-offload-targets=3Dnvptx-none > > --with-cuda-driver-include=3D/usr/local/cuda/include > > --with-cuda-driver-lib=3D/usr/local/cuda/lib64 --disable-bootstrap > > --disable-multilib --enable-languages=3Dc,c++,fortran,lto > > --prefix=3D/home/myself/apps/gcc-10.2.0 > > Thread model: posix > > Supported LTO compression algorithms: zlib > > gcc version 10.2.0 (GCC) > > > > > > PS2: Same problem also happens with gcc 9.3 as installed on Ubuntu > > 16.04 from apt: > > > > $ gfortran -v > > Using built-in specs. > > COLLECT_GCC=3Dgfortran > > COLLECT_LTO_WRAPPER=3D/usr/lib/gcc/x86_64-linux-gnu/9/lto-wrapper > > OFFLOAD_TARGET_NAMES=3Dnvptx-none:hsa > > OFFLOAD_TARGET_DEFAULT=3D1 > > Target: x86_64-linux-gnu > > Configured with: ../src/configure -v --with-pkgversion=3D'Ubuntu > > 9.3.0-10ubuntu2~16.04' > > --with-bugurl=3Dfile:///usr/share/doc/gcc-9/README.Bugs > > --enable-languages=3Dc,ada,c++,go,brig,d,fortran,objc,obj-c++,gm2 > > --prefix=3D/usr --with-gcc-major-version-only --program-suffix=3D-9 > > --program-prefix=3Dx86_64-linux-gnu- --enable-shared > > --enable-linker-build-id --libexecdir=3D/usr/lib > > --without-included-gettext --enable-threads=3Dposix --libdir=3D/usr/lib > > --enable-nls --enable-clocale=3Dgnu --enable-libstdcxx-debug > > --enable-libstdcxx-time=3Dyes --with-default-libstdcxx-abi=3Dnew > > --enable-gnu-unique-object --disable-vtable-verify --enable-plugin > > --with-system-zlib --with-target-system-zlib=3Dauto > > --enable-objc-gc=3Dauto --enable-multiarch --disable-werror > > --with-arch-32=3Di686 --with-abi=3Dm64 --with-multilib-list=3Dm32,m64,m= x32 > > --enable-multilib --with-tune=3Dgeneric > > --enable-offload-targets=3Dnvptx-none,hsa --without-cuda-driver > > --enable-checking=3Drelease --build=3Dx86_64-linux-gnu > > --host=3Dx86_64-linux-gnu --target=3Dx86_64-linux-gnu > > Thread model: posix > > gcc version 9.3.0 (Ubuntu 9.3.0-10ubuntu2~16.04) > >