From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mout.gmx.net (mout.gmx.net [212.227.17.20]) by sourceware.org (Postfix) with ESMTPS id E5F6C3857816; Wed, 17 Nov 2021 20:32:45 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E5F6C3857816 X-UI-Sender-Class: 01bb95c1-4bf8-414a-932a-4f6e2808ef9c Received: from gluon.fritz.box ([79.251.8.28]) by mail.gmx.net (mrgmx105 [212.227.17.168]) with ESMTPSA (Nemesis) id 1MvbG2-1mVMC52FZW-00saD1; Wed, 17 Nov 2021 21:32:43 +0100 Subject: Re: [PATCH] Fortran: Mark internal symbols as artificial [PR88009,PR68800] To: Bernhard Reutner-Fischer , Harald Anlauf via Fortran Cc: gcc-patches@gcc.gnu.org Newsgroups: gmane.comp.gcc.patches,gmane.comp.gcc.fortran References: <20211114231748.376086cd@nbbrfq> <20211117091216.3a0ec44f@nbbrfq> From: Harald Anlauf Message-ID: <4842a7cf-48a2-cd34-e717-952d181abd84@gmx.de> Date: Wed, 17 Nov 2021 21:32:14 +0100 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.12.0 MIME-Version: 1.0 In-Reply-To: <20211117091216.3a0ec44f@nbbrfq> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: quoted-printable X-Provags-ID: V03:K1:MsE7j1cPOpN18DRrRVTOyTv61G9bfokzH83AwqqUvRSr67Mbt+N TQubwCbVbWT/wH27BEvoS6AcE7n/oUgGTSWstkIv17BP/E/FVOwnN2Dn268PuMfAvoLcYW7 bBnXSUE5s6J85heBvFFFrp5HnLfPg5+am3OZyz0NrY9OFpxbzQx2pLLRVzFtxn+odtxA7v4 H0/ka3P5eExxiaj9jKxJw== X-UI-Out-Filterresults: notjunk:1;V03:K0:cpsfNpNtCOo=:iN65B1MNIFd4F+RWzNfL1y Ep3OUiX9zHqeHWvJtCbt2VXUUfdqjOiOjG5mw3yEdoJYZty0Dm1ELyApdjTVcJvaySbbeK/s8 5ewAGhjUExbqgM+KVtdDCwI22CDQinoK4zNRaAKtop4z35zahocXDVs+lChTq9z5C7rYAlFis UeK0rGltG5Sj0xtPzpMgvwkPKyuxeqxB9DWNV+gWZS0AKLClCVzx3lTzlLMB72Xu+3w5CqjGj Yono4gB+ciiqyYWzoRf1bZp/O0vVxvXAryyXjv2SQSXoH3G4PMbLbOT63eWazKRq6HXMtBVSO J+GMIWdDNwqSXffNPeUqH7Y+TPqDX0stOHna0V1024TK241esfo6FEmoVBhED+giKTWMvxWdl BD+OCR0XDzSw2ZGm2q/WNrqcwBrUs7VHOWbeepV7/DV0vCJtCTsA5IUnQbTn86bIU+VimtUTm 3H7Ddz9JkfNDc6tyDicuwOq0iGN52l4MVBeDQzBY3aDTc2uZgIoezVsgkk1Yr9UHPG5tEGm0Y oObqHlKhG0HnKaWYDC0LSWIZZYRsGnZdFOlF+cfHvE9C2IhzS8SReVs0ppjZwrxzhxrM82KpZ KRGFGGgopOby9zOJuyoCTFploukFKEZJ2S0I/JRSn4OKPKzwtA89h+qb7xdDzXXZgwipS0f9E JHwl8Gvnw4ZDmm6Zkodiwt4QBiBQV/ReFdcsXOQxoaVgGWEEInuGlgcNp3mo/7LaICPz1uYMs AQ9bj13/nxVQmPykQUUC1jxy4KzDnUnYAG2u5nvujUl7ItTf7b7i7kD8vv6peVzrLW2iwQ/T4 mPGpM4fiScB4YJyu4N9m8KttcBJ9pjBNLqzrRcKwTzt+e9YQEFfkuviYNybSP6Dh3bp97Imt4 xBiBkXKJ4vzcNgWnpkXuU/q/RmzZvdJ9eph3vevpsvVc9v+FUo1w/5NEHKcAs0Ype6Rrpb7az liGyDmWNmKOqlMilUuH3hUomgxoN56VsAENGA9OZmPCrNJ2ZvG1CUnjwsrHRCEOEyluzrMVls JgrAaaO/vyZu16omEC6mgU3dDdWgI2YIB9sglTpe37tuuvkKuhsbqOIMO9EJg4bVf4LV6WpQI a9Y0r7+nepIdAs= X-Spam-Status: No, score=-4.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, FREEMAIL_FROM, NICE_REPLY_A, RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) 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, 17 Nov 2021 20:32:47 -0000 Do you have testcases/reproducers demonstrating that the patch actually fixes the issues you're describing? Am 17.11.21 um 09:12 schrieb Bernhard Reutner-Fischer via Gcc-patches: > On Tue, 16 Nov 2021 21:46:32 +0100 > Harald Anlauf via Fortran wrote: > >> Hi Bernhard, >> >> I'm trying to understand your patch. What does it really try to solve? > > Compiler generated symbols should be marked artificial. > The fix for PR88009 ( f8add009ce300f24b75e9c2e2cc5dd944a020c28 , > r9-5194 ) added artificial just to the _final component and left out all= the rest. > Note that the majority of compiler generated symbols in class.c > already had artificial set properly. > The proposed patch amends the other generated symbols to be marked > artificial, too. > > The other parts fix memory leaks. > >> >> PR88009 is closed and seems to have nothing to do with this. > > Well it marked only _final as artificial and forgot to adjust the > others as well. > We can remove the reference to PR88009 if you prefer? > > thanks! >> >> Harald >> >> Am 14.11.21 um 23:17 schrieb Bernhard Reutner-Fischer via Fortran: >>> Hi! >>> >>> Amend fix for PR88009 to mark all these class components as artificial= . >>> >>> gcc/fortran/ChangeLog: >>> >>> * class.c (gfc_build_class_symbol, generate_finalization_wra= pper, >>> (gfc_find_derived_vtab, find_intrinsic_vtab): Use stringpool= for >>> names. Mark internal symbols as artificial. >>> * decl.c (gfc_match_decl_type_spec, gfc_match_end): Fix >>> indentation. >>> (gfc_match_derived_decl): Fix indentation. Check extension l= evel >>> before incrementing refs counter. >>> * parse.c (parse_derived): Fix style. >>> * resolve.c (resolve_global_procedure): Likewise. >>> * symbol.c (gfc_check_conflict): Do not ignore artificial sy= mbols. >>> (gfc_add_flavor): Reorder condition, cheapest first. >>> (gfc_new_symbol, gfc_get_sym_tree, >>> generate_isocbinding_symbol): Fix style. >>> * trans-expr.c (gfc_trans_subcomponent_assign): Remove >>> restriction on !artificial. >>> * match.c (gfc_match_equivalence): Special-case CLASS_DATA f= or >>> warnings. >>> >>> --- >>> gfc_match_equivalence(), too, should not bail-out early on the first >>> error but should diagnose all errors. I.e. not goto cleanup but set >>> err=3Dtrue and continue in order to diagnose all constraints of a >>> statement. Maybe Sandra or somebody else will eventually find time to >>> tweak that. >>> >>> I think it also plugs a very minor leak of name in gfc_find_derived_vt= ab >>> so i also tagged it [PR68800]. At least that was the initial >>> motiviation to look at that spot. >>> We were doing >>> - name =3D xasprintf ("__vtab_%s", tname); >>> ... >>> gfc_set_sym_referenced (vtab); >>> - name =3D xasprintf ("__vtype_%s", tname); >>> >>> Bootstrapped and regtested without regressions on x86_64-unknown-linux= . >>> Ok for trunk? >>> >> >> > >