From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa3.mentor.iphmx.com (esa3.mentor.iphmx.com [68.232.137.180]) by sourceware.org (Postfix) with ESMTPS id 7A3243858038 for ; Mon, 19 Jul 2021 08:46:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7A3243858038 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: +SFOBIcGq756FOWm8+nOFJ3Day0giQ2nTAhjhT03OuNsr6JaZ/kuazr1I4hAkTTABMDDCw+1PV T9KwG//waVOx2uEEbztbifzVvXLYKfJu07Im1anp6cZIqiWu6b5qtPq05mfo5LJ17HNZTfGCC3 jzG5/ADPQYeSh9yXRzKbcyc0lPwzCYgRs/BlcVS997TJXKtVVesTf46/TwzCEeYRUV+SQD8j5k VtiEXb8Dtmo7O5glPeE7Hu4MC/hnS+gBad/Uw32ta3t1gy9aOpkQHyFsAnJkuYM0lD6P69XcFC Fh4q0QLZv4UsVwRGjKWFRQhV X-IronPort-AV: E=Sophos;i="5.84,251,1620720000"; d="scan'208,223";a="63657521" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa3.mentor.iphmx.com with ESMTP; 19 Jul 2021 00:46:45 -0800 IronPort-SDR: 0h1o7sqjck1cP6oocjCKS7GewVM/y3YT0vPr8Pvq7Znld4Z8aoH/RGtc65xMptdCKl+LImjFTf wjP2XxpO1ypqGaKwE7LgSqBGUJW2EX3ey2zbuvuP8Zc3L4tcEOHKmsk7iW4LieKdEQTyIvbCr/ Xl7dIDaAxQSofFzWuKKi0K8A0Aqn0QhkEY+SHTXCxi3faWA1NTGHH8KT4kg+uNiBghzYKriKY7 /ER5KyqVG1v3vCdWzlMmJ2k5Dnjae7NqE7eJy6R/SKvuPdXJXcKhD+znDytvjzeBMRwWxPHjY4 P0s= From: Thomas Schwinge To: Andrew Stubbs , CC: Martin Sebor , Hafiz Abid Qadeer , Subject: [gcn] Work-around libgomp 'error: array subscript 0 is outside array bounds of =?utf-8?Q?=E2=80=98=5F=5Flds?= struct gomp_thread * =?utf-8?Q?=5F=5Flds=5B0=5D=E2=80=99?= [-Werror=array-bounds]' (was: [PATCH libatomic/arm] avoid warning on constant addresses (PR 101379)) In-Reply-To: <2e085663-b619-5240-6a40-961420341ebd@codesourcery.com> References: <816ce216-bf6a-75ca-4241-4861ec43ab27@gmail.com> <87pmvii29w.fsf@euler.schwinge.homeip.net> <2e085663-b619-5240-6a40-961420341ebd@codesourcery.com> User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Mon, 19 Jul 2021 10:46:35 +0200 Message-ID: <87bl6ybsic.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: SVR-IES-MBX-07.mgc.mentorg.com (139.181.222.7) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-12.3 required=5.0 tests=BAYES_00, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, SPF_HELO_PASS, SPF_PASS, TXREP autolearn=ham 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: Mon, 19 Jul 2021 08:46:48 -0000 --=-=-= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi! | On 7/16/21 11:42 AM, Thomas Schwinge wrote: |> On 2021-07-09T17:11:25-0600, Martin Sebor via Gcc-patches wrote: |>> The attached tweak avoids the new -Warray-bounds instances when |>> building libatomic for arm. Christophe confirms it resolves |>> the problem (thank you!) |> |> As Abid has just reported in |> , similar |> problem with GCN target libgomp build: |> |> In function =E2=80=98gcn_thrs=E2=80=99, |> inlined from =E2=80=98gomp_thread=E2=80=99 at [...]/source-gcc/= libgomp/libgomp.h:803:10, |> inlined from =E2=80=98GOMP_barrier=E2=80=99 at [...]/source-gcc= /libgomp/barrier.c:34:29: |> [...]/source-gcc/libgomp/libgomp.h:792:10: error: array subscript 0= is outside array bounds of =E2=80=98__lds struct gomp_thread * __lds[0]=E2= =80=99 [-Werror=3Darray-bounds] |> 792 | return *thrs; |> | ^~~~~ |> |> gcc/config/gcn/gcn.h: c_register_addr_space ("__lds", ADDR_SPACE_L= DS); \ |> |> libgomp/libgomp.h-static inline struct gomp_thread *gcn_thrs (void) |> libgomp/libgomp.h-{ |> libgomp/libgomp.h- /* The value is at the bottom of LDS. */ |> libgomp/libgomp.h: struct gomp_thread * __lds *thrs =3D (struct go= mp_thread * __lds *)4; |> libgomp/libgomp.h- return *thrs; |> libgomp/libgomp.h-} |> |> ..., plus a few more. Work-around: |> |> struct gomp_thread * __lds *thrs =3D (struct gomp_thread * __lds= *)4; |> +# pragma GCC diagnostic push |> +# pragma GCC diagnostic ignored "-Warray-bounds" |> return *thrs; |> +# pragma GCC diagnostic pop |> |> ..., but it's a bit tedious to add that in all that the other places, |> too. Wasn't so bad after all; a lot of duplicates due to 'libgomp.h'. I've thus pushed "[gcn] Work-around libgomp 'error: array subscript 0 is outside array bounds of =E2=80=98__lds struct gomp_thread * __lds[0]=E2=80= =99 [-Werror=3Darray-bounds]' [PR101484]" to master branch in commit 9f2bc5077debef2b046b6c10d38591ac324ad8b5, see attached. |> (So I'll consider some GCN-specific '-Wno-array-bounds' if we don't |> get to resolve this otherwise, soon.) Now: "Awaiting a different solution, of course." ;-) On 2021-07-17T23:28:45+0100, Andrew Stubbs wrote: > On 16/07/2021 18:42, Thomas Schwinge wrote: >> Of course, we may simply re-work the libgomp/GCN code -- but don't we >> first need to answer the question whether the current code is actually >> "bad"? Aren't we going to get a lot of similar reports from >> kernel/embedded/other low-level software developers, once this is out in >> the wild? I mean: > > GCN already uses address 4 for this value because address 0 caused > problems with null-pointer checks. Ugh. How much wasted bytes per what is that? (I haven't looked yet; hopefully not per GPU thread?) Because: > It really ought not be this hard. :-( I'm sure we can avoid that. Gr=C3=BC=C3=9Fe Thomas ----------------- 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 --=-=-= Content-Type: text/x-diff Content-Disposition: inline; filename="0001-gcn-Work-around-libgomp-error-array-subscript-0-is-o.patch" >From 9f2bc5077debef2b046b6c10d38591ac324ad8b5 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 16 Jul 2021 19:12:02 +0200 Subject: [PATCH] =?UTF-8?q?[gcn]=20Work-around=20libgomp=20'error:=20array?= =?UTF-8?q?=20subscript=200=20is=20outside=20array=20bounds=20of=20?= =?UTF-8?q?=E2=80=98=5F=5Flds=20struct=20gomp=5Fthread=20*=20=5F=5Flds[0]?= =?UTF-8?q?=E2=80=99=20[-Werror=3Darray-bounds]'=20[PR101484]?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit ... seen as of commit a110855667782dac7b674d3e328b253b3b3c919b "Correct handling of variable offset minus constant in -Warray-bounds [PR100137]". Awaiting a different solution, of course. libgomp/ PR target/101484 * config/gcn/team.c: Apply '-Werror=array-bounds' work-around. * libgomp.h [__AMDGCN__]: Likewise. --- libgomp/config/gcn/team.c | 3 +++ libgomp/libgomp.h | 12 ++++++++++++ 2 files changed, 15 insertions(+) diff --git a/libgomp/config/gcn/team.c b/libgomp/config/gcn/team.c index 627210ea407..94ce2f2dfeb 100644 --- a/libgomp/config/gcn/team.c +++ b/libgomp/config/gcn/team.c @@ -65,9 +65,12 @@ gomp_gcn_enter_kernel (void) void * __lds *arena_start = (void * __lds *)TEAM_ARENA_START; void * __lds *arena_free = (void * __lds *)TEAM_ARENA_FREE; void * __lds *arena_end = (void * __lds *)TEAM_ARENA_END; +# pragma GCC diagnostic push +# pragma GCC diagnostic ignored "-Warray-bounds" /*TODO PR101484 */ *arena_start = team_arena; *arena_free = team_arena; *arena_end = team_arena + TEAM_ARENA_SIZE; +# pragma GCC diagnostic pop /* Allocate and initialize the team-local-storage data. */ struct gomp_thread *thrs = team_malloc_cleared (sizeof (*thrs) diff --git a/libgomp/libgomp.h b/libgomp/libgomp.h index 8d25dc8e2a8..4159cbe3334 100644 --- a/libgomp/libgomp.h +++ b/libgomp/libgomp.h @@ -128,7 +128,10 @@ team_malloc (size_t size) : "=v"(result) : "v"(TEAM_ARENA_FREE), "v"(size), "e"(1L) : "memory"); /* Handle OOM. */ +# pragma GCC diagnostic push +# pragma GCC diagnostic ignored "-Warray-bounds" /*TODO PR101484 */ if (result + size > *(void * __lds *)TEAM_ARENA_END) +# pragma GCC diagnostic pop { /* While this is experimental, let's make sure we know when OOM happens. */ @@ -159,8 +162,11 @@ team_free (void *ptr) However, if we fell back to using heap then we should free it. It would be better if this function could be a no-op, but at least LDS loads are cheap. */ +# pragma GCC diagnostic push +# pragma GCC diagnostic ignored "-Warray-bounds" /*TODO PR101484 */ if (ptr < *(void * __lds *)TEAM_ARENA_START || ptr >= *(void * __lds *)TEAM_ARENA_END) +# pragma GCC diagnostic pop free (ptr); } #else @@ -789,13 +795,19 @@ static inline struct gomp_thread *gcn_thrs (void) { /* The value is at the bottom of LDS. */ struct gomp_thread * __lds *thrs = (struct gomp_thread * __lds *)4; +# pragma GCC diagnostic push +# pragma GCC diagnostic ignored "-Warray-bounds" /*TODO PR101484 */ return *thrs; +# pragma GCC diagnostic pop } static inline void set_gcn_thrs (struct gomp_thread *val) { /* The value is at the bottom of LDS. */ struct gomp_thread * __lds *thrs = (struct gomp_thread * __lds *)4; +# pragma GCC diagnostic push +# pragma GCC diagnostic ignored "-Warray-bounds" /*TODO PR101484 */ *thrs = val; +# pragma GCC diagnostic pop } static inline struct gomp_thread *gomp_thread (void) { -- 2.30.2 --=-=-=--