From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from esa4.mentor.iphmx.com (esa4.mentor.iphmx.com [68.232.137.252]) by sourceware.org (Postfix) with ESMTPS id 3A8A83858002; Mon, 29 Mar 2021 13:58:25 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org 3A8A83858002 Authentication-Results: sourceware.org; dmarc=none (p=none dis=none) header.from=codesourcery.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=Tobias_Burnus@mentor.com IronPort-SDR: ej6mV09FfNRVDV0nOieRoWW74XLFyG7nmAVDNsZI5eyL4b2tE0MLUlTHOC99jEPZMVJiv9nHXA t5Tqw+zSBS3TA8L7Pigy4vsSvCMtfjsBCuIwBUjNVICdkgjlf3Udj/Qnct4lauRGox+71j4OPV FO1CC2ZJKFhIWXKraDwx2mfexQGssE3PbpmkqRjrvPI644h79W8kZn87RY7EEPfyiWt2MKWNgl y1IZnLhbmobT2ywuGz/UHG7BvhzJzY5wXktVnjl3Z1A51xpCJcX89pAFPeacNHraHaTqE0lgv4 OSU= X-IronPort-AV: E=Sophos;i="5.81,287,1610438400"; d="scan'208";a="59718576" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa4.mentor.iphmx.com with ESMTP; 29 Mar 2021 05:58:24 -0800 IronPort-SDR: 91t3ouEEgLb3tGEQbCkFwH/mj/VqPxhr46pwP7ribHZHKHk+QI0+kTadXdjMviWMQSab/LFgYW 0VYDRbwBlCj0AnoF/zwsamDjmDqRaOL2GmkPb9NR6eLlXY9hBeqzJ82AeSiAPS4l7pOmLa8FOM qZAVp31vtyWnC4vkuelHCNn2Tsh8VISG+WKYAsjS0gaB7rekV+GEck/3sTQVXShMIBnCmDDVT2 pv3V44WzENxJQ1oOXT0tHr0xXEV0JHlTUwioZpMGqa/ywhvfNENZtiMWrpwUnT2x2oMfXqIidm e9U= Subject: Re: [Patch, fortran] 99307 - FAIL: gfortran.dg/class_assign_4.f90 execution test To: Paul Richard Thomas , "fortran@gcc.gnu.org" , gcc-patches References: From: Tobias Burnus Message-ID: Date: Mon, 29 Mar 2021 15:58:19 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: quoted-printable Content-Language: en-US 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=-6.0 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.2 X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on server2.sourceware.org X-BeenThere: fortran@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Fortran mailing list List-Unsubscribe: , List-Archive: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Mar 2021 13:58:27 -0000 Hi all, as preremark I want to note that the testcase class_assign_4.f90 was added for PR83118/PR96012 (fixes problems in handling class objects, De= c 18, 2020) and got revised for PR99124 (class defined operators, Feb 23, 2021). Both patches were then also applied to GCC 9 and 10. On 26.03.21 17:30, Paul Richard Thomas via Gcc-patches wrote: > This patch comes in two versions: submit.diff with Change.Logs or > submit2.diff with Change2.Logs. > The first fixes the problem by changing array temporaries from class > expressions into class temporaries. This permits the use of > gfc_get_class_from_expr to obtain the vptr for these temporaries and all > the good things that come with that when handling dynamic types. The seco= nd > part of the fix is to use the array element length from the class > descriptor, when reallocating on assignment. This is needed because the > vptr is being set too early. I will set about trying to track down why th= is > is happening and fix it after release. > > The second version does the same as the first but puts in place a load of > tidying up that is permitted by the fix to class array temporaries. > I couldn't readily see how to prepare a testcase - ideas? > Both regtest on FC33/x86_64. The first was tested by Dominique (see the > PR). OK for master? Typo =E2=80=93 underscore-'c' should be a dot-'c' =E2=80=93 both changelog = files > * trans-expr_c (gfc_trans_scalar_assign): Make use of pre and I think the second longer version is nicer in general, but at least for GCC 9/GCC10 the first version is simpler and, hence, less error prone. As you only ask about mainline, I would prefer the second one. However, I am not happy about gfc_find_and_cut_at_last_class_ref: > + of refs following. If ts is non-null the cut is at the class entity > + or component that is followed by an array reference, which is not + > an element. */ ... + + if (ts) + { + if (e->symtree + && > e->symtree->n.sym->ts.type =3D=3D BT_CLASS) + *ts =3D > &e->symtree->n.sym->ts; + else + *ts =3D NULL; + } + for (ref =3D e->ref; > ref; ref =3D ref->next) { + if (ts && ref->type =3D=3D REF_COMPONENT + && > ref->u.c.component->ts.type =3D=3D BT_CLASS + && ref->next && > ref->next->type =3D=3D REF_COMPONENT + && strcmp > (ref->next->u.c.component->name, "_data") =3D=3D 0 + && ref->next->next + > && ref->next->next->type =3D=3D REF_ARRAY + && ref->next->next->u.ar.type > !=3D AR_ELEMENT) + { + *ts =3D &ref->u.c.component->ts; + class_ref =3D r= ef; > + break; + } + + if (ts && *ts =3D=3D NULL) + return NULL; + Namely, if there is: type1%array_class2 =E2=86=92 array_class2 is used for 'ts' and later (ok= ) type1%type%array_class2 =E2=86=92 NULL is returned (why?) class1%type%array_class2 =E2=86=92 ts =3D class1 but array2_class is use= d later on (ups!) class1%...%scalar_class2 =E2=86=92 ts =3D class1 but scalar_class2 is us= ed etc. Thus this either needs to be cleaned up (separate 'ref' loop for ts !=3D NULL) =E2=80=93 including the wording in the description which tell= s what happens if 'ts' is passed as arg but the expr has rank =3D=3D 0 =E2=80=93 a= nd what value is assigned to 'ts'. (You can then also fix 'class.c::' to 'class.c: ' in the description above the function.) Alternatively, you can leave the current code ref handling code in place at build_class_array_ref, which might be the simpler alternative. Otherwise, it looks sensible to me. Tobias ----------------- Mentor Graphics (Deutschland) GmbH, Arnulfstrasse 201, 80634 M=C3=BCnchen R= egistergericht M=C3=BCnchen HRB 106955, Gesch=C3=A4ftsf=C3=BChrer: Thomas H= eurung, Frank Th=C3=BCrauf