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 C6D4A3850438 for ; Tue, 20 Jul 2021 08:40:32 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org C6D4A3850438 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: 7BMLi9SCj1AwICwi+uamHYnuc0n4gUFwwNWJWlWV+jW1DrrRt6hcypWPyj7Nzt/M2OX17/MSTL NnOVmXkg+BmL60spzd1daVFy711el3EpTh3QTodvSUNkJSmSJX+xg9sew+cVo51SmpiVj4x7uo jGIoPIGU+MGm89PfpgxfvaM5sWO2KDDms6euhn+fJBA2VClIrQZeLERJ3xyBLN5W5Md40VjCK+ qpJ2xwgsW54W4zkOG9q0UEJw/PnZJH9/tuMPDyBqWgD7k28BCh+B7G+Mo7GFxNgHzn7GsBa8Nm 4CqVdny/aWTTn9kTbNj0CqAI X-IronPort-AV: E=Sophos;i="5.84,254,1620720000"; d="scan'208";a="63714472" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 20 Jul 2021 00:40:31 -0800 IronPort-SDR: Hla9STJt9voumHFqScPwc+10RurGrQcPPr13/GRYVlL7eROi3oYglksDoo9B9/cA6yuPwAIgTJ uFHkh4KzHAHx01J8TsrVwiLi6kPXBRf3KaNp92XwtcQ0Q6n+DzlAJZw4cvvz6uH/CbvaABth+8 JPdNpWFLdMsocr5DHB0iacBz7Cq2z8F8gTX6RLfXYHOcgLZQc2D2z2A9aCdS7o1ACxVFGkINm8 a1nMZu0lbYlEbXK9et0lJtn0CEV1p7qWpoOShI9rNp7n3RDP64BcSocQWCJwxO4zm3natJSx17 9xA= From: Thomas Schwinge To: Martin Sebor , CC: Andrew Stubbs , Hafiz Abid Qadeer , , Jakub Jelinek Subject: '#pragma GCC diagnostic' (mis-)use in 'statement' of 'if' (was: [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: <87v9558n4j.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> <87v9558n4j.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 10:40:22 +0200 Message-ID: <87sg098jk9.fsf@euler.schwinge.homeip.net> MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable X-Originating-IP: [137.202.0.90] X-ClientProxiedBy: svr-ies-mbx-05.mgc.mentorg.com (139.181.222.5) To svr-ies-mbx-01.mgc.mentorg.com (139.181.222.1) X-Spam-Status: No, score=-6.3 required=5.0 tests=BAYES_00, HEADER_FROM_DIFFERENT_DOMAINS, KAM_DMARC_STATUS, KAM_SHORT, 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, 20 Jul 2021 08:40:35 -0000 Hi! On 2021-07-20T09:23:24+0200, I wrote: > 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-g= cc/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 subscrip= t 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_SPAC= E_LDS); \ >> |> >> |> libgomp/libgomp.h-static inline struct gomp_thread *gcn_thrs (vo= id) >> |> 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 * __= 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. > > 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.) OK, phew. Martin: your diagnostic changes are *not* to be blamed for code generation changes -- it's my '#pragma GCC diagnostic pop' placement that triggers: > 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 err= ors) > [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-11.c executi= on test > > PASS: libgomp.c/../libgomp.c-c++-common/for-12.c (test for excess err= ors) > [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-12.c executi= on test > > PASS: libgomp.c/../libgomp.c-c++-common/for-3.c (test for excess erro= rs) > [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-3.c executio= n test > > PASS: libgomp.c/../libgomp.c-c++-common/for-5.c (test for excess erro= rs) > [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-5.c executio= n test > > PASS: libgomp.c/../libgomp.c-c++-common/for-6.c (test for excess erro= rs) > [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-6.c executio= n test > > PASS: libgomp.c/../libgomp.c-c++-common/for-9.c (test for excess erro= rs) > [-PASS:-]{+FAIL:+} libgomp.c/../libgomp.c-c++-common/for-9.c executio= n 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: In addition to a few in straight-line code, I also had these two: > --- a/libgomp/libgomp.h > +++ b/libgomp/libgomp.h > @@ -128,7 +128,10 @@ team_malloc (size_t size) > : "=3Dv"(result) : "v"(TEAM_ARENA_FREE), "v"(size), "e"(1L) : "me= mory"); > > /* 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,8 +159,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 >=3D *(void * __lds *)TEAM_ARENA_END) > +# pragma GCC diagnostic pop > free (ptr); > } > #else ..., and it appears that the '#pragma GCC diagnostic pop' are considered here to be the 'statement' of the 'if'! That's (a) unexpected (to me, at least) for this kind of "non-executable" '#pragma', and (b) certainly would be worth a dignostic, like we have for OMP pragmas, for example: if (context =3D=3D pragma_stmt) { error_at (loc, "%<#pragma %s%> may only be used in compound stateme= nts", "[...]"); Addressing that is for another day. 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