From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.15.18]) by sourceware.org (Postfix) with ESMTPS id 6434038533E1; Tue, 13 Dec 2022 22:27:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 6434038533E1 Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmx.de Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmx.de DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=gmx.de; s=s31663417; t=1670970439; bh=BtXO3K/TBZxWNKHoKD+tk2mJs2B5l1WE8VMd/gxkb6I=; h=X-UI-Sender-Class:Date:Subject:To:References:From:In-Reply-To; b=n46PeMHuVnLPj9K22T8nHu+KiV64UlNitABOoIk74oeSJ6exIi4IIiSG36hKkI1Vq mdWnF+oVam6kEIH/bmKPOLcVAUANFyAGx5xrhL0VjOIm4ZJnyqmPhwokWcds1JqzZX yzihuNb0KDKjYzblVY/6WOOh/YFg0sIUFQszPgrGu6lq/o4j8SOoUSMuJNFYBErOVf viQZDA46f+u8R9KfNPaY/X8Sz5X04EJHfG/0PzqTkqE2+WCWC+cLbduqsRrDttdwl3 og5QjISuT8zqwsoVUlbIw9FUwBuJQfbfbcx6gSdsEaqhViIbxQn/oJoVgvroX8wph8 V0AdS7cDZz8Og== X-UI-Sender-Class: 724b4f7f-cbec-4199-ad4e-598c01a50d3a Received: from [192.168.178.29] ([93.207.80.163]) by mail.gmx.net (mrgmx005 [212.227.17.190]) with ESMTPSA (Nemesis) id 1M2wL0-1p46kU3z4u-003NoA; Tue, 13 Dec 2022 23:27:19 +0100 Message-ID: Date: Tue, 13 Dec 2022 23:27:17 +0100 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Subject: Re: [Patch, Fortran] libgfortran's ISO_Fortran_binding.c: Use GCC11 version for backward-only code [PR108056] To: Tobias Burnus , gcc-patches , fortran Newsgroups: gmane.comp.gcc.patches,gmane.comp.gcc.fortran References: <1faf5680-9f5a-1f9d-4a9d-4eaff8982056@codesourcery.com> Content-Language: en-US From: Harald Anlauf In-Reply-To: <1faf5680-9f5a-1f9d-4a9d-4eaff8982056@codesourcery.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:j//ZS0JJ5k+woU0QDq/vOXduv6rMOc1t7nDDDA3NdHt3EGp8qV1 IUNPFnD8P5Xh8PdusvqtMOUppxIo7fY+yK1gD+qHS+lqjmD+bzkkXMgPkt1yh+69AaefQt4 1dXEdpngWzrjks93xH3catiDGAS8ooezcJCjsZm1r8kVKTrUmGwXjN8HuHc4FJSf069H9xO gCTgVSYHQDQH1WjkWXNJw== UI-OutboundReport: notjunk:1;M01:P0:lFxuWyv+XrU=;zEMVet0j8JXSyN92qmdreOUBD3F dsQQFp6nh/Aeoa0gD61yfN7sjOh5eLKvfO2Mp8yNXBtX11aSZCy3SiBRHpoYwomSpetuhTbvt pnwfSzvUiUrdDOXbigivQORfMiK2QJAWLowWO8J6+qWUxyB6ln0SLVIOTXDn+TR4iNMB1icJH iaU8gz/YzrRWY4fLK+2ZBiGpPWVM8RYRXnPgyX70zi/r71OZ8WJEpsBz+GbOl5rHXK2Va4Oxm GxZrRMoXv/3SebhvlcuUALhFG6KAsaKp0DCMkdvjGoxABTXi3IAerGcXyjEiqwEUk1NGwn9kx /FfaUqi3pLDrh4mPXDItke1GdKEYYvkqk+pSbmioYZfe3RujyjPYANk5jDtX0liV9E2Skex3J rEJg169XHqZdDPFADuQbm4KoZKbri7xwrWchbbxue1pf6GiofYdBBtBHoULEabWlbszv6J/ch rUk44nai+YcKyEkoLIo1Ran6c5EVpxCqlnH91QIXdsrwKKUAnPt9vSePTeDNRjyRFItP9/K2k xpKKLgSWG9QTAivAPYQZr0xC3gqR6wXQ0f7gwfjPu88ZbmgwUIMi4/4Vi4yjwqPVg+QTwV/Fn EVJdw82Wpof6TPRJPA3QLoyJDXeDUtHuRpYI8JSngLO7QlOhyIWGekKYeZcZlzy/c1VhaX6zG R54cBzXvqLQpEixgOVSL2TkQQC1XNUnm4BP3OvPnFoQQgz8mCwI2Y8J1961DSR8yczdbR+cqj dltmM2LicS/ACmdgFcZET8MZ5Pq7oRbm01RY5KMNFVxRnXLgtdqJumslUmUWP6eR69rg/7vsw Mw9vSZHAdmoyNPfFGJDAvAElAua5lA5+uQ037wix0IazaGYo8Ar8+351NgrIanm7mlO2/jgs7 uyzNlCyjDPMxdCsb5td/XELL8K5Vx/CRNMaCoKhdOY0/fAbqyUcGiGbBXYHBTbDM5ZlZvEUxE SGiRPA== X-Spam-Status: No, score=-4.3 required=5.0 tests=BAYES_00,BODY_8BITS,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,NICE_REPLY_A,RCVD_IN_DNSWL_LOW,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=ham 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 Tobias, Am 13.12.22 um 22:41 schrieb Tobias Burnus: > Note: We only talk about those two functions, the other functions are us= ed > by both GCC <=3D 11 and GCC >=3D 12. yes. > Fortunately, these functions matter most as they map GFC internals to CF= I > internals or vice versa. Most other functions are user callable and ther= e > incompatibilities are less likely to show up and GCC 11 users also could > profit from fixes there. It looks as if CFI_section and CFI_select_part = had > some larger changes, likewise CFI_setpointer. > > Back to differences: 'diff -U0 -p -w' against the last GCC 11 branch sho= ws: > > ... > @@ -35,0 +37,2 @@ export_proto(cfi_desc_to_gfc_desc); > +/* NOTE: Since GCC 12, the FE generates code to do the conversion > +=C2=A0=C2=A0 directly without calling this function.=C2=A0 */ > @@ -63 +66 @@ cfi_desc_to_gfc_desc (gfc_array_void *d, > -=C2=A0 d->dtype.version =3D s->version; > +=C2=A0 d->dtype.version =3D 0; I was wondering what the significance of "version" is. In ISO_Fortran_binding.h we seem to always have #define CFI_VERSION 1 and it did not change with gcc-12. If it is just decoration (for now), then it is not important. I just didn't see where it is used. > @@ -76,0 +80 @@ cfi_desc_to_gfc_desc (gfc_array_void *d, > +=C2=A0 if (GFC_DESCRIPTOR_DATA (d)) > @@ -79,3 +83,7 @@ cfi_desc_to_gfc_desc (gfc_array_void *d, > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 GFC_DESCRIPTOR_LBOUND(d, n) =3D (index_t= ype)s->dim[n].lower_bound; > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 GFC_DESCRIPTOR_UBOUND(d, n) =3D (index_t= ype)(s->dim[n].extent > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 + s->dim[n= ].lower_bound > - 1); > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 CFI_index_t lb =3D 1; > + > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 if (s->attribute !=3D CFI_attribut= e_other) > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 lb =3D s->dim[n].lower= _bound; > + > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 GFC_DESCRIPTOR_LBOUND(d, n) =3D (i= ndex_type)lb; > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 GFC_DESCRIPTOR_UBOUND(d, n) =3D (i= ndex_type)(s->dim[n].extent + lb > - 1); Oh, now I see that on 11-branch in trans-expr.c we set a hard-coded attribute =3D 2 instead of using CFI_attribute_other, even if that was available as a macro defining the very same value. Thus it is ok. > @@ -89,0 +98,2 @@ export_proto(gfc_desc_to_cfi_desc); > +/* NOTE: Since GCC 12, the FE generates code to do the conversion > +=C2=A0=C2=A0 directly without calling this function.=C2=A0 */ > @@ -100,2 +110,2 @@ gfc_desc_to_cfi_desc (CFI_cdesc_t **d_pt > -=C2=A0=C2=A0=C2=A0 d =3D malloc (sizeof (CFI_cdesc_t) > -=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0 + (CFI_type_t)(CFI_MAX_RANK * sizeof (CFI_dim_t))); > +=C2=A0=C2=A0=C2=A0 d =3D calloc (1, (sizeof (CFI_cdesc_t) > +=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2= =A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 + (CFI_type_t)(CFI_MAX_RANK * size= of (CFI_dim_t)))); > @@ -107 +117 @@ gfc_desc_to_cfi_desc (CFI_cdesc_t **d_pt > -=C2=A0 d->version =3D s->dtype.version; > +=C2=A0 d->version =3D CFI_VERSION; This treatment of "version" was the equivalent to the above that confused me. Assuming we were to change CFI_VERSION in gcc-13+, is this the right choice here regarding backward compatibility? > Probably yes. I don't have a better suggestion. The problem is that it > usually only matters in some corner cases, like in the PR where a not > some argument is passed to the GFC=E2=86=92CFI conversion but first a Fo= rtran > function is called with TYPE(*) any only then it is passed on. =E2=80=93= Such > cases are usually not in the testsuite. (With GCC 12 we have a rather > complex testsuite, but obviously it also does not cover everything.) Well, I understand we have to draw a line here, whether we reproduce every bug in <=3D gcc-11 where the user may have attempted to implement a workaround. That might be tough. >> Well, in the real world there are larger installations with large >> software stacks, and it is easier said to "compile each component >> with the same compiler version" than done... > > I concur =E2=80=93 but there were really many fixes for the array descri= ptor / > TS29113 in GCC 12. > > It is simply not possible to fix tons of bugs and be 100% compatible > with the working bits of the old version =E2=80=93 especially if they on= ly work > if one does not look sharply at the result. (Like here, were 'type' is > wrong, which does not matter unless in programs which use them.) True. I was only thinking of the 90+ percent of valid and common uses that we really consider important. So besides the "version" question ok from my side. Thanks, Harald > Thanks, > > 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 Gesellschaft: M=C3=BCnchen; > Registergericht M=C3=BCnchen, HRB 106955 >