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 30A95385E02C for ; Tue, 20 Jul 2021 07:23:33 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 30A95385E02C 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: HuXgj3jefFYaLY8NvXA0kQH0pL+07Ucg79xcGvIz/+aKTQj2ezSWnzigYWaX/XjlWaY2q/neeI DBoiKL7w6lvsvRjuy+/i0VuEd5gj1Q2lBTbzMa69nbWnQ9WWpqQU79CzTfjFzKq28QE2VyipMm B0X48F5eha59Z/oPqNT3xDSNLYcxOmSZryPVY7Ji0hH83Z3CebkW7c47yinT8R/MQF05gPa8l6 jyCOJmfpzpFiQO3C2cOxvt4TB+r/ZXYtgXZa0D4VToS8XkAs3nA/ksCW+i938sU7YTv5SVNSpU mc9iFkxfAeJy72Orv6FeHH0E X-IronPort-AV: E=Sophos;i="5.84,254,1620720000"; d="scan'208,223";a="63712172" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 19 Jul 2021 23:23:31 -0800 IronPort-SDR: sbzSLC4UiNOtk57Ja4iI9yj2y5GCPMUpXZbCS9PhiJod0iytuiyTvfjROip+5EHVPk9ZS+94L3 F6KZW0OUSKBhAIVSJ+/xJw/k9pu3esFsbjLF2uU7mtjCFcdzkJf49RhKhPI+WwiU6iUDrSTNrA VslwPPahSe4ysWLETCfcGwDB9BPKvwCEYItyHncU1uoy7+Nf1DQ/IOHGfUNbZtSNwC5YQY/w9a gQlawXSU9vh1h0BBtUbkjNoycGGTbA7swI4ml2hBV2WKLm8DIRVe/qrfRBvhsAhmsQhty3KteI 7iM= From: Thomas Schwinge To: Martin Sebor , CC: Andrew Stubbs , Hafiz Abid Qadeer , , Jakub Jelinek Subject: Re: [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]' In-Reply-To: <87bl6ybsic.fsf@euler.schwinge.homeip.net> References: <816ce216-bf6a-75ca-4241-4861ec43ab27@gmail.com> <87pmvii29w.fsf@euler.schwinge.homeip.net> <2e085663-b619-5240-6a40-961420341ebd@codesourcery.com> <87bl6ybsic.fsf@euler.schwinge.homeip.net> User-Agent: Notmuch/0.29.3+94~g74c3f1b (https://notmuchmail.org) Emacs/27.1 (x86_64-pc-linux-gnu) Date: Tue, 20 Jul 2021 09:23:24 +0200 Message-ID: <87v9558n4j.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-06.mgc.mentorg.com (139.181.222.6) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-12.2 required=5.0 tests=BAYES_00, GIT_PATCH_0, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_LOTSOFHASH, 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: Tue, 20 Jul 2021 07:23:35 -0000 --=-=-= Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hi! On 2021-07-19T10:46:35+0200, I wrote: > | 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-gc= c/libgomp/libgomp.h:803:10, > |> inlined from =E2=80=98GOMP_barrier=E2=80=99 at [...]/source-g= cc/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= _LDS); \ > |> > |> libgomp/libgomp.h-static inline struct gomp_thread *gcn_thrs (voi= d) > |> libgomp/libgomp.h-{ > |> libgomp/libgomp.h- /* The value is at the bottom of LDS. */ > |> libgomp/libgomp.h: struct gomp_thread * __lds *thrs =3D (struct = gomp_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 * __l= ds *)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. As I should find, these '#pragma GCC diagnostic [...]' directives cause some code generation changes (that seems unexpected, problematic!). (Martin, any idea? Might be a pre-existing problem, of course.) This results in a lot (ten thousands) of 'GCN team arena exhausted' run-time diagnostics, also leading to a few FAILs: PASS: libgomp.c/../libgomp.c-c++-common/for-11.c (test for excess error= s) [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-11.c execution= test PASS: libgomp.c/../libgomp.c-c++-common/for-12.c (test for excess error= s) [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-12.c execution= test PASS: libgomp.c/../libgomp.c-c++-common/for-3.c (test for excess errors= ) [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-3.c execution = test PASS: libgomp.c/../libgomp.c-c++-common/for-5.c (test for excess errors= ) [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-5.c execution = test PASS: libgomp.c/../libgomp.c-c++-common/for-6.c (test for excess errors= ) [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-6.c execution = test PASS: libgomp.c/../libgomp.c-c++-common/for-9.c (test for excess errors= ) [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-9.c execution = test Same for 'libgomp.c++'. It remains to be analyzed how '#pragma GCC diagnostic [...]' directives can cause code generation changes; for now I'm working around the "unexpected" '-Werror=3Darray-bounds' diagnostics differently: > |> (So I'll consider some GCN-specific '-Wno-array-bounds' if we don't > |> get to resolve this otherwise, soon.) '-Wno-error=3Darray-bounds', precisely. I've now 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-boun= ds]' some more [PR101484]" to master branch in commit 8168338684fc2bed576bb09202c63b3e9e678d92, see attached. 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; charset="utf-8" Content-Disposition: inline; filename="0001-gcn-Work-around-libgomp-error-array-subscript-0-is-o.patch" Content-Transfer-Encoding: quoted-printable >From 8168338684fc2bed576bb09202c63b3e9e678d92 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 19 Jul 2021 23:11:38 +0200 Subject: [PATCH] =3D?UTF-8?q?[gcn]=3D20Work-around=3D20libgomp=3D20'error:= =3D20array?=3D =3D?UTF-8?q?=3D20subscript=3D200=3D20is=3D20outside=3D20array=3D20bounds= =3D20of=3D20?=3D =3D?UTF-8?q?=3DE2=3D80=3D98=3D5F=3D5Flds=3D20struct=3D20gomp=3D5Fthread=3D= 20*=3D20=3D5F=3D5Flds[0]?=3D =3D?UTF-8?q?=3DE2=3D80=3D99=3D20[-Werror=3D3Darray-bounds]'=3D20some=3D20m= ore=3D20[PR101484?=3D =3D?UTF-8?q?]?=3D MIME-Version: 1.0 Content-Type: text/plain; charset=3DUTF-8 Content-Transfer-Encoding: 8bit With yesterday's commit 9f2bc5077debef2b046b6c10d38591ac324ad8b5 "[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-boun= ds]' [PR101484]", I did defuse the "unexpected" '-Werror=3Darray-bounds' diagnostics that we = see as of commit a110855667782dac7b674d3e328b253b3b3c919b "Correct handling of variable offset minus constant in -Warray-bounds [PR100137]". However, the= se '#pragma GCC diagnostic [...]' directives cause some code generation changes (that seems unexpected, problematic!), which results in a lot (ten thousand= s) of 'GCN team arena exhausted' run-time diagnostics, also leading to a few FAILs: PASS: libgomp.c/../libgomp.c-c++-common/for-11.c (test for excess error= s) [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-11.c execution= test PASS: libgomp.c/../libgomp.c-c++-common/for-12.c (test for excess error= s) [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-12.c execution= test PASS: libgomp.c/../libgomp.c-c++-common/for-3.c (test for excess errors) [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-3.c execution = test PASS: libgomp.c/../libgomp.c-c++-common/for-5.c (test for excess errors) [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-5.c execution = test PASS: libgomp.c/../libgomp.c-c++-common/for-6.c (test for excess errors) [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-6.c execution = test PASS: libgomp.c/../libgomp.c-c++-common/for-9.c (test for excess errors) [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-9.c execution = test Same for 'libgomp.c++'. It remains to be analyzed how '#pragma GCC diagnostic [...]' directives can cause code generation changes; for now I'm working around the "unexpected" '-Werror=3Darray-bounds' diagnostics differently. Overall, still awaiting a different solution, of course. libgomp/ PR target/101484 * configure.tgt [amdgcn*-*-*] (XCFLAGS): Add '-Wno-error=3Darray-bounds'. * config/gcn/team.c: Remove '-Werror=3Darray-bounds' work-around. * libgomp.h [__AMDGCN__]: Likewise. --- libgomp/config/gcn/team.c | 3 --- libgomp/configure.tgt | 3 +++ libgomp/libgomp.h | 12 ------------ 3 files changed, 3 insertions(+), 15 deletions(-) diff --git a/libgomp/config/gcn/team.c b/libgomp/config/gcn/team.c index 94ce2f2dfeb..627210ea407 100644 --- a/libgomp/config/gcn/team.c +++ b/libgomp/config/gcn/team.c @@ -65,12 +65,9 @@ gomp_gcn_enter_kernel (void) void * __lds *arena_start =3D (void * __lds *)TEAM_ARENA_START; void * __lds *arena_free =3D (void * __lds *)TEAM_ARENA_FREE; void * __lds *arena_end =3D (void * __lds *)TEAM_ARENA_END; -# pragma GCC diagnostic push -# pragma GCC diagnostic ignored "-Warray-bounds" /*TODO PR101484 */ *arena_start =3D team_arena; *arena_free =3D team_arena; *arena_end =3D team_arena + TEAM_ARENA_SIZE; -# pragma GCC diagnostic pop =20 /* Allocate and initialize the team-local-storage data. */ struct gomp_thread *thrs =3D team_malloc_cleared (sizeof (*thrs) diff --git a/libgomp/configure.tgt b/libgomp/configure.tgt index fe2bf1dac51..d4f1e741b5a 100644 --- a/libgomp/configure.tgt +++ b/libgomp/configure.tgt @@ -173,6 +173,9 @@ case "${target}" in =20 amdgcn*-*-*) config_path=3D"gcn accel" + + #TODO PR101484 + XCFLAGS=3D"$XCFLAGS -Wno-error=3Darray-bounds" ;; =20 *) diff --git a/libgomp/libgomp.h b/libgomp/libgomp.h index 4159cbe3334..8d25dc8e2a8 100644 --- a/libgomp/libgomp.h +++ b/libgomp/libgomp.h @@ -128,10 +128,7 @@ team_malloc (size_t size) : "=3Dv"(result) : "v"(TEAM_ARENA_FREE), "v"(size), "e"(1L) : "memo= ry"); =20 /* 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. */ @@ -162,11 +159,8 @@ 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 >=3D *(void * __lds *)TEAM_ARENA_END) -# pragma GCC diagnostic pop free (ptr); } #else @@ -795,19 +789,13 @@ static inline struct gomp_thread *gcn_thrs (void) { /* The value is at the bottom of LDS. */ struct gomp_thread * __lds *thrs =3D (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 =3D (struct gomp_thread * __lds *)4; -# pragma GCC diagnostic push -# pragma GCC diagnostic ignored "-Warray-bounds" /*TODO PR101484 */ *thrs =3D val; -# pragma GCC diagnostic pop } static inline struct gomp_thread *gomp_thread (void) { --=20 2.30.2 --=-=-=--