From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x42a.google.com (mail-wr1-x42a.google.com [IPv6:2a00:1450:4864:20::42a]) by sourceware.org (Postfix) with ESMTPS id E1B713858D39; Sun, 14 Nov 2021 19:53:13 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org E1B713858D39 Received: by mail-wr1-x42a.google.com with SMTP id d24so26409792wra.0; Sun, 14 Nov 2021 11:53:13 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:cc:subject:message-id:in-reply-to :references:mime-version:content-transfer-encoding; bh=yU9ox6b6ZT/AplmN96gXusV5LsqBtG36OyIFDiGOXgY=; b=kHMADprYcL6XjATiRYm0M+Z9U6n4xpc72Jd5bzjXGnChEZZfmJ2gBSe493odGAKGDu MYCf3POiRq1qufrKFW8zIWBeOB+pXgUm5yBdw/huXYBYAtobGSAyiwtpaGam/cEfd2g9 E25u7fg9BAijjOoUw9NI9x2gqmPpZDnyIEfGJAOxR2GqPUQGzdZb5ZfoiwS9rfPPKhEg q6iUc+jQWUd84jqoIb4f4GdUZJwy7AiQ7jAhJfHkc67vd/JAU7hnWl/olN7YpjV4h7Dp hHY+ybWFJ1iYdvXrgFF1156x86lEO8LjEFxodRnf7rmuKGG9hw3y8ND3KnpukS/yUa7S +g2w== X-Gm-Message-State: AOAM532Yu8W8LB2vsv1BY5F7PFTPCIKG+WVAxDDpjSn0SPoCzQ8hsNAt S29qcyYDjAvUje4o4mvo2MM= X-Google-Smtp-Source: ABdhPJzBADy/9VJDADxcsXHWvoKXA5cPL8YyLQVDFT+gzA4Xb+6p3Kx+u60XZLqE5Y0SodBmVxtouw== X-Received: by 2002:adf:ec90:: with SMTP id z16mr41610673wrn.247.1636919592846; Sun, 14 Nov 2021 11:53:12 -0800 (PST) Received: from nbbrfq (62-46-115-185.adsl.highway.telekom.at. [62.46.115.185]) by smtp.gmail.com with ESMTPSA id c1sm12049648wrt.14.2021.11.14.11.53.12 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 14 Nov 2021 11:53:12 -0800 (PST) Date: Sun, 14 Nov 2021 20:53:09 +0100 From: Bernhard Reutner-Fischer To: Mikael Morin Cc: rep.dot.nop@gmail.com, gcc-patches@gcc.gnu.org, fortran@gcc.gnu.org Subject: Re: [PATCH,FORTRAN] Fix memory leak in finalization wrappers Message-ID: <20211114205309.70e85395@nbbrfq> In-Reply-To: References: <20181015082306.23083-1-rep.dot.nop@gmail.com> <20211027233943.082d66ed@nbbrfq> <20211029015857.14a80703@nbbrfq> <6683b641-0c67-814e-cf87-e164729b1cfe@orange.fr> <20211105230812.78ca344b@nbbrfq> <6d86c6ec-a9a5-431a-e2ed-a8a71baea830@orange.fr> <20211107005655.4bf8a07e@nbbrfq> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-9.8 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, GIT_PATCH_0, RCVD_IN_DNSWL_NONE, 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: gcc-patches@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-patches mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sun, 14 Nov 2021 19:53:15 -0000 On Sun, 7 Nov 2021 13:32:34 +0100 Mikael Morin wrote: > > btw.. Just because it's vagely related. > > I think f8add009ce300f24b75e9c2e2cc5dd944a020c28 for > > PR fortran/88009 (ICE in find_intrinsic_vtab, at fortran/class.c:2761) > > is incomplete in that i think all the internal class helpers should be > > flagged artificial. All these symbols built in gfc_build_class_symbol, > > generate_finalization_wrapper, gfc_find_derived_vtab etc. > > Looking at the history it seems the artificial bit often was forgotten.= =20 >=20 > I guess so, yes... >=20 > > And most importantly i think it is not correct to ignore artificial in > > gfc_check_conflict! > > =20 > Well, it=E2=80=99s not correct to throw errors at users for things they h= aven=E2=80=99t=20 > written and that they don=E2=80=99t control. oops, i forgot to add the hunk to the patch to drain complaints to the user 1). Of course we don't want the error to be user-visible, but i think we do want to check_conflicts (e.g. gfortran.dg/pr95587.f90 regresses via an unspecific Unclassifiable statement; I assume we should copy all or at least some sym attribs to the corresponding CLASS_DATA attribs which i think makes sense for consistency anyway). 1) diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c index 1a1e4551355..9df23f314df 100644 --- a/gcc/fortran/symbol.c +++ b/gcc/fortran/symbol.c @@ -898,6 +898,10 @@ gfc_check_conflict (symbol_attribute *attr, const char= *name, locus *where) return true; =20 conflict: + /* It would be wrong to complain about artificial code. */ + if (attr->artificial) + return false; + if (name =3D=3D NULL) gfc_error ("%s attribute conflicts with %s attribute at %L", a1, a2, where);