From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm1-x335.google.com (mail-wm1-x335.google.com [IPv6:2a00:1450:4864:20::335]) by sourceware.org (Postfix) with ESMTPS id 115A53858D1E; Mon, 29 Jan 2024 20:45:15 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 115A53858D1E Authentication-Results: sourceware.org; dmarc=pass (p=none dis=none) header.from=gmail.com Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com ARC-Filter: OpenARC Filter v1.0.0 sourceware.org 115A53858D1E Authentication-Results: server2.sourceware.org; arc=none smtp.remote-ip=2a00:1450:4864:20::335 ARC-Seal: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706561118; cv=none; b=wLsYB7CbL2r13A40ZSXyPg84Ep8qSPvjSVq9kfewA1w/9nUO6E3a5UpinuNTkn2PXn+1js0vjFupcavPki8jXA6W0FeNbcHVfqyG7+ocL+qdoN7hQefoPrRujLAPYgjCGW+blBH0O0Hkb/HLnKRcH9Ue4Ub1lHTr6weJrZ9wVEE= ARC-Message-Signature: i=1; a=rsa-sha256; d=sourceware.org; s=key; t=1706561118; c=relaxed/simple; bh=8zepptJJs3GVQlSkaJIVPLIuGYqtfjqWuXkQ2vexVgA=; h=DKIM-Signature:Date:From:To:Subject:Message-ID:MIME-Version; b=OO0aOHcWfdQUNlWph0dIWNo9VPJPSC9XH1OqXGpOEjUv6Bw7QsOKrUA7KlkiKg6znhf88MiwN87IiYYEGsfQyPeP72Rht7aMeJEYtBd8D5LieIwy8VhMSBbssLIC7OJ1Ypqd48mqi/0mv6TSNgSrISDzyGYxdNTBnJ48OPA3U/E= ARC-Authentication-Results: i=1; server2.sourceware.org Received: by mail-wm1-x335.google.com with SMTP id 5b1f17b1804b1-40efcb37373so3513965e9.2; Mon, 29 Jan 2024 12:45:15 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1706561113; x=1707165913; darn=gcc.gnu.org; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=v6el+TbgU/94ZVAi6ZucH2Rsuw5GNQxCDuc41xUdfkU=; b=jWi/NgPdwxpBMW2CdkvJrftAEzZykBaE1/KfViQ9tN9QJHPg5yZIwYM3rSEf1XV/Za BL15A9zhmDf/rrAOKQPMllRBhAQd+CVlkzkW/4H9StofAoBDqLRoZv4kfiy/isGO8xeg J5PC7Qp7zVXWMHTh5R08dtd9/a6Yvp9u3Le+lVW58VSAalDMZt3LfyjY+A4oCQJqZ398 hAq9ErvSM5wek+iKs4dMQbfWX0j/zNaNozN/vgAZIM6RE3qYAZkkCNbZC83CBO/RPn2J U4ByYPcU4PmUcLzFEMktXOElC/c2oJzfH2CbWXg7XzHhxVMJHMF6YNm/HW8oRixPBcTa fFUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1706561113; x=1707165913; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=v6el+TbgU/94ZVAi6ZucH2Rsuw5GNQxCDuc41xUdfkU=; b=FxgBfXMP8fiAHPAQ8wp/cim6bKOq7K2drXHFis5v36YqIV7PoRNAi4608pd0Zg40b5 ox260Q1WDK7NB2wnFR06xfraqW9WVKt13rKgwSffp/X1GKx4uwsEEmJCwLbHqar7M7l9 6+e6wGGb7gWrcXKHTEHtsa6+0pEwhw1iPb2bPaOY8ki19Jtpe7ysdAb9cmb/O2znEr5k Dn2OUjdQESUhBZzAHIsgao0csXzk4jeCmvHtDR92PabP3Jc7OcsvCrEw6PCZh6Yz56UQ IC6m/y6B1aK6dxvvJepACuhcdhzcFtm31gydCBGXLyzIKTHndXZXKZs2b68DZ2/zSohT v+eg== X-Gm-Message-State: AOJu0YxQ10x2BKu6nXYxuHfAWzO9isAnpucXQaIeqKWBbM8jCpco8jMp cMFnsHDKoj8I5gS22tlaqAVuU4gX5o7IimwJ9YkSgUEZqcfYjrYu X-Google-Smtp-Source: AGHT+IFomQjqndSE14zPAg9kYZ75yt0LY0R811ahCnBnR2sZQ6ABTs8WbCzgVdWkwv9v/NoXlyyFuQ== X-Received: by 2002:a5d:444f:0:b0:33a:f6da:58ad with SMTP id x15-20020a5d444f000000b0033af6da58admr582073wrr.60.1706561113145; Mon, 29 Jan 2024 12:45:13 -0800 (PST) Received: from nbbrfq.loc (80-110-214-113.static.upcbusiness.at. [80.110.214.113]) by smtp.gmail.com with ESMTPSA id y11-20020adffa4b000000b0033aee139e26sm3211724wrr.63.2024.01.29.12.45.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 29 Jan 2024 12:45:12 -0800 (PST) Date: Mon, 29 Jan 2024 21:45:09 +0100 From: Bernhard Reutner-Fischer To: Harald Anlauf Cc: rep.dot.nop@gmail.com, Harald Anlauf via Fortran , gcc-patches@gcc.gnu.org Subject: Re: [PATCH] Fortran: Mark internal symbols as artificial [PR88009,PR68800] Message-ID: <20240129214509.590a7fa0@nbbrfq.loc> In-Reply-To: <4842a7cf-48a2-cd34-e717-952d181abd84@gmx.de> References: <20211114231748.376086cd@nbbrfq> <20211117091216.3a0ec44f@nbbrfq> <4842a7cf-48a2-cd34-e717-952d181abd84@gmx.de> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit X-Spam-Status: No, score=-3.6 required=5.0 tests=BAYES_00,DKIM_SIGNED,DKIM_VALID,DKIM_VALID_AU,DKIM_VALID_EF,FREEMAIL_FROM,RCVD_IN_DNSWL_NONE,SPF_HELO_NONE,SPF_PASS,TXREP,T_SCC_BODY_TEXT_LINE 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: On Wed, 17 Nov 2021 21:32:14 +0100 Harald Anlauf wrote: > Do you have testcases/reproducers demonstrating that the patch actually > fixes the issues you're describing? I believe that marking artificial symbols as such is obvious and i did use the existing tests to verify that the changes do not regress but behave as intended. I did check that the memory leak in gfc_find_derived_vtab is fixed with the patch. Ok for stage 1 if the rebased regression test passes? thanks > > 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_wrapper, > >>> (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 level > >>> 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 symbols. > >>> (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 for > >>> 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=true 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_vtab > >>> so i also tagged it [PR68800]. At least that was the initial > >>> motiviation to look at that spot. > >>> We were doing > >>> - name = xasprintf ("__vtab_%s", tname); > >>> ... > >>> gfc_set_sym_referenced (vtab); > >>> - name = xasprintf ("__vtype_%s", tname); > >>> > >>> Bootstrapped and regtested without regressions on x86_64-unknown-linux. > >>> Ok for trunk? > >>> > >> > >> > > > > >