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 A642B385E013; Wed, 14 Apr 2021 13:51:16 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.3.2 sourceware.org A642B385E013 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: 7RHduh/kAqb+4cYg5cVCZKDwlLhu+EtwuH5b3HPauPWkUwOvpAAqUS3XVTGmTg+IDffR1ueUbZ 0NzeBOfyuhz6IH49GJbO2nSSpA5HFGSmSjAZ1jlU0f7y8BwEFS6j03mqI2ZRXiThfPaoDPT+Df FYUcusKEoKnTqmUvAl8cpmiFKKgIbuZ9tuCFHJNROvUymv6BW0Bnr/MHYlH32tQ9UOLBJZv4Uc LPqfcTHHstEOQEuec1qKeJ95EjavZTZCs5mDhhvQHA5cBHjCbtSDhu0mpxWLgxZ6YGz3pdJv2P M4s= X-IronPort-AV: E=Sophos;i="5.82,222,1613462400"; d="scan'208";a="60111489" Received: from orw-gwy-02-in.mentorg.com ([192.94.38.167]) by esa2.mentor.iphmx.com with ESMTP; 14 Apr 2021 05:51:15 -0800 IronPort-SDR: tLVWM11HQJWNBzHeHatXgrc0tQJeOhfb8xgHJ9pDQMULZqEEpI1bO+ep0wlId+hK/27cg2g1jN VfWg3yg7tJZg5uUMshd+mU1VfUX+NX6nJzYCTuFK5KVzeY54oIgsBUYU7OvRobe7FcfLBfRtfE geLDvz7Dl53gLJluLFtV2ajrTzmLppBnl6B24eLscp56AfZAeViM28PMWjuw2frazbkkV9fnnK /qIDaImOl2p+g44V1MCI0WiyF+pk7GVd0HXzEIzLWO377smYYhaqFrbY1Z73UdYy2HKrpwYS5N Gxw= Subject: Re: [Patch, fortran] 99307 - FAIL: gfortran.dg/class_assign_4.f90 execution test To: Paul Richard Thomas , Tobias Burnus CC: "fortran@gcc.gnu.org" , gcc-patches References: From: Tobias Burnus Message-ID: <2ddc9e59-95fb-21e0-b013-012289e0a14d@codesourcery.com> Date: Wed, 14 Apr 2021 15:51:09 +0200 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.9.1 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-04.mgc.mentorg.com (139.181.222.4) 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, RCVD_IN_DNSWL_NONE, 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: Wed, 14 Apr 2021 13:51:18 -0000 On 11.04.21 09:05, Paul Richard Thomas wrote: > Tobias noticed a major technical fault with the resubmission below: I > forgot to attach the patch :-( LGTM. Plus as remarked in the first review: 'trans-expr_c' typo needs to be fixed (ChangeLog). Tobias > > Please find it attached this time. > > Paul > > On Tue, 6 Apr 2021 at 18:08, Paul Richard Thomas > > > wrote: > > Hi Tobias, > > I believe that the attached fixes the problems that you found with > gfc_find_and_cut_at_last_class_ref. > > I will test: > 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 used > later on (ups!) > class1%...%scalar_class2 =E2=86=92 ts =3D class1 but scalar_class2= is used > > The ChangeLogs remain the same, apart from the date. > > Regtests OK on FC33/x86_64. > > Paul > > > On Mon, 29 Mar 2021 at 14:58, Tobias Burnus > > wrote: > > 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, Dec 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 second > > 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 this > > 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 > > >=C2=A0 * trans-expr_c (gfc_trans_scalar_assign): Make use o= f > 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 ref; > > + 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_cl= ass is > used later on (ups!) > class1%...%scalar_class2 =E2=86=92 ts =3D class1 but scalar_cl= ass2 is > used > 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 > tells what > happens if 'ts' is passed as arg but the expr has rank =3D=3D 0 = =E2=80=93 and > 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 Registergericht M=C3=BCnchen HRB 106955, Gesch=C3=A4= ftsf=C3=BChrer: > Thomas Heurung, Frank Th=C3=BCrauf > > > > -- > "If you can't explain it simply, you don't understand it well > enough" - Albert Einstein > > > > -- > "If you can't explain it simply, you don't understand it well enough" > - Albert Einstein ----------------- 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