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 7A1D5385842E; Wed, 26 Oct 2022 10:39:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 7A1D5385842E Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=mentor.com X-IronPort-AV: E=Sophos;i="5.95,214,1661846400"; d="scan'208";a="85275166" Received: from orw-gwy-01-in.mentorg.com ([192.94.38.165]) by esa3.mentor.iphmx.com with ESMTP; 26 Oct 2022 02:39:44 -0800 IronPort-SDR: 9pexATmeSBTyX+/4SzVNfDDuJjK/BqwcCuab6blC7h/vsvr3A30vv+CBWIH8XsfxhM2sHukl8+ TD0qGS/bYtDv4TpMZ8TsYTwvjtsrRrjdC8TNAm/ZiAH4GzURUIwfSOPLfxm9Pw+Edwnnh+R2zj BnzcdkdmVE5CvzQ+8LpIpOJpiyuEdSDOHm+UgxWw7FsUdXXR2xkQrTxORX/C6v2J0MWQ/DSScl 7uusUqltKaiWp3l+ihWdjzBrbYET9pWnxDRB9OXWUzYXKqk80n9sZ1txjIykBCHFPrAIbKIKjl 9OE= Message-ID: Date: Wed, 26 Oct 2022 12:39:39 +0200 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.3.3 Subject: Re: [PATCH] OpenMP: Duplicate checking for map clauses in Fortran (PR107214) Content-Language: en-US To: Julian Brown , , Jakub Jelinek CC: , Tobias Burnus References: <20221020161414.7430-1-julian@codesourcery.com> From: Tobias Burnus In-Reply-To: <20221020161414.7430-1-julian@codesourcery.com> 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-11.mgc.mentorg.com (139.181.222.11) To svr-ies-mbx-12.mgc.mentorg.com (139.181.222.12) X-Spam-Status: No, score=-5.4 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.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: Hi Julian, I had a first quick lock at this patch, I should have a closer look later. However, I stumbled over the following: On 20.10.22 18:14, Julian Brown wrote: > typedef struct gfc_symbol > { > ... > struct gfc_symbol *old_symbol; > > unsigned mark:1, comp_mark:1, data_mark:1, dev_mark:1, gen_mark:1; > unsigned reduc_mark:1, gfc_new:1; > > struct gfc_symbol *tlink; > > unsigned equiv_built:1; > ... I know that this was the case before, but can you move the mark:1 etc. after 'tlink'? In that case all bitfields are grouped together. If I have not miscounted, we have currently 7 bits before and 9 bits after 'tlink' and grouping them together reduced pointless padding. * * * > + else if (n->sym->mark) > + gfc_error ("Symbol %qs present on both data and map clauses " > + "at %L", n->sym->name, &n->where); I wonder whether that also rejects the following =E2=80=93 which seems to b= e valid. The 'map' goes to 'target' and the 'firstprivate' to 'parallel', cf. OpenMP 5.2, "17.2 Clauses on Combined and Composite Constructs", [340:3-4 & 12-14]. (BTW: While some fixes went into 5.1 regarding this sect= ion, a likewise wording is already in 5.0.) (Testing showed: it give an ICE without the patch and an error with.) module m integer :: a =3D 1 end module m module m2 contains subroutine bar() use m !$omp declare target a =3D a + 5 end subroutine bar end program p use m !$omp target parallel do map(a) firstprivate(a) do i =3D 1, 1 a =3D 7 call bar() if (a /=3D 7) error stop 1 a =3D a + 8 end do if (a /=3D 6) error stop end * * * The ICE seems to be because gcc/fortran/trans-openmp.cc's gfc_split_omp_cla= uses mishandles this as the dump shows the following: #pragma omp target firstprivate(a) map(tofrom:a) #pragma omp parallel firstprivate(a) * * * In contrast, for the C testcase: void foo(int x) { #pragma omp target parallel for simd map(x) firstprivate(x) for (int k =3D 0; k < 1; ++k) x =3D 1; } the dump is as follows, which seems to be sensible: #pragma omp target map(tofrom:x) #pragma omp parallel firstprivate(x) #pragma omp for nowait #pragma omp simd Tobias ----------------- 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