From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa2.mentor.iphmx.com (esa2.mentor.iphmx.com [68.232.141.98]) by sourceware.org (Postfix) with ESMTPS id 9D04E3858037 for ; Tue, 18 Jan 2022 14:32:01 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 9D04E3858037 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com IronPort-SDR: 61DJl+pFnOMurgJQ8z59ZtVabAXSPxbbgv7JY9JhG5Y0dTv9RsntxdPz6dr/Y/QGkpBHguKSC0 jUYgnx+KlRmbsM+zrqM4Y+QKKxSflx1XS0mo0llZn4MPgpZdMFyoAZp0zzZdPJgGU8KLVtEXDy BwbwuwZ8KRMEmkjr1LZZ2nck+dBe8VrcjWaDxyf7LSjb9j0V36N1NpfF+POTx5KQk3+upKWcJ5 NO/e5iusKzg6XIztOM/y1vGGNUJbj5DHjbsVMLHE6sp6JoehZsSdYQ6ybk0Q1jCblrDcH0EcT6 QV4= X-IronPort-AV: E=Sophos;i="5.88,297,1635235200"; d="scan'208";a="70896023" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 18 Jan 2022 06:31:58 -0800 IronPort-SDR: 7yFdWJb7WUnnzEoe+woBjKYC35OvYC3jU0MH3xpuN+wZeIc41sahwkMFbmJ/1XC7l/jk0UMwF8 4cHsEGEV7YrbatozAjRcyU404ksUVCrfG9QcIl71I4mw7bwdz2Fzq+YdTollr2huM2vqAts1u5 hS5hO2LL9u/b0retjztFzFHLdVM8kF9AwbRgdS9UWsVm8sCZ7kIx2cSxdeQBQShDPoHTxQoI7h ZtR1TA5x/Is5NHYpbe18uhFbxrQasJMAsrfAYgIndo8jmWpfuR6mSIj7VowUmjhWHh3BOLIovO j3E= Message-ID: <53521b17-79d1-6298-fcbf-e77398239422@codesourcery.com> Date: Tue, 18 Jan 2022 15:31:52 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:91.0) Gecko/20100101 Thunderbird/91.4.1 Subject: Re: [PATCH] libgomp, OpenMP: Fix issue for omp_get_device_num on gfx targets. To: Thomas Schwinge , Chung-Lin Tang CC: , Jakub Jelinek , Tom de Vries , Andrew Stubbs , Julian Brown , Tobias Burnus References: <32c3546a-49c1-bedf-3002-c4e7783bf312@codesourcery.com> <42b806a0-55a2-7fea-3e69-2d82bfc18007@codesourcery.com> <87bl09cjtl.fsf@euler.schwinge.homeip.net> From: Marcel Vollweiler In-Reply-To: <87bl09cjtl.fsf@euler.schwinge.homeip.net> Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-13.mgc.mentorg.com (139.181.222.13) To SVR-IES-MBX-03.mgc.mentorg.com (139.181.222.3) X-Spam-Status: No, score=-6.8 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, NICE_REPLY_A, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=no autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 18 Jan 2022 14:32:03 -0000 Hi Thomas, Am 18.01.2022 um 13:25 schrieb Thomas Schwinge: > Hi! > > Maybe I'm just totally confused -- as so often ;-) -- but things seem > strange here: > > On 2022-01-12T10:43:05+0100, Marcel Vollweiler = wrote: >> Currently omp_get_device_num does not work on gcn targets with more than >> one offload device. The reason is that GOMP_DEVICE_NUM_VAR > > I understand the 'GOMP_DEVICE_NUM_VAR' "macro indirection" is so that we > define the actual symbol name ('__gomp_device_num') in one place > ('libgomp/libgomp-plugin.h'), and then use it (via macro expansion) in > several places, right? Yes, as far as I understood. > >> is static in >> icv-device.c and thus "__gomp_device_num" is not visible in the offload >> image. > > That behavior seems correct -- but undesired indeed? Good question. In contrast to nvptx I observed that __gomp_device_num is not part of the offload image which we read out in GOMP_OFFLOAD_load_image ("if (status !=3D HSA_STATUS_SUCCESS)" in libgomp/plugin/plugin-gcn.c returns false). I validated it with some additional output in the if-branches. > >> This patch removes "static" such that "__gomp_device_num" is now part of >> the offload image and can now be found in GOMP_OFFLOAD_load_image in the >> plugin. > > That seems correct? > > Or, is there a reason to have it 'static', say, so that several such > local variables can co-exist, instead of just one global one? > >> This is not an issue for nvptx. There, "__gomp_device_num" is in the >> offload image even with "static". > > That's unexpected then, and should be looked into? Actually, I don't see the reason for the different behaviour for nvptx. I just tested that for nvptx the correct device number is returned by omp_get_device_num on the device - also if we have more than one device. > > Still, should 'static' be removed here, too? I wouldn't suggest unless it is really necessary? I mean, there we don't have any issue. Although I aggree with Andrew that we could combine both icv-device.c files into one common file. Marcel ----------------- Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstra=C3=9Fe 201= , 80634 M=C3=BCnchen; Gesellschaft mit beschr=C3=A4nkter Haftung; Gesch=C3= =A4ftsf=C3=BChrer: Thomas Heurung, Frank Th=C3=BCrauf; Sitz der Gesellschaf= t: M=C3=BCnchen; Registergericht M=C3=BCnchen, HRB 106955