From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-pl1-f172.google.com (mail-pl1-f172.google.com [209.85.214.172]) by sourceware.org (Postfix) with ESMTPS id 7EC763858289 for ; Wed, 8 Mar 2023 15:29:46 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.2 sourceware.org 7EC763858289 Authentication-Results: sourceware.org; dmarc=fail (p=none dis=none) header.from=carnegiescience.edu Authentication-Results: sourceware.org; spf=pass smtp.mailfrom=gmail.com Received: by mail-pl1-f172.google.com with SMTP id p6so18072996plf.0 for ; Wed, 08 Mar 2023 07:29:46 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; t=1678289385; h=content-transfer-encoding:mime-version:references:in-reply-to :organization:message-id:date:subject:cc:to:from:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=dKvlh8YmmnnyH3u9xewLAwy9Ek+2sQyr77ebcywoYnE=; b=taq2rQv+5giNQh8QHSdVHLyqOpy41EWPuvPuluVShY5iBtWVTYyLs0Ad38rz3LuwxN EnetIdKcMJP+rnmZWgJDskBD0QkL2z3pxq42QEOmMh6yGx0cbp80PXOM8deDVlzsMGvM /HUalbkoevRIo9iQv8L9YY90zFAeaftmQY2ZCTFdzF7NJV8ebu61yNcgqf7eZYq9kZAb 1mse0keVa7HzJ1Bz6vcBp1VjwZZu+eMDIBSufq/k4Mgzty3Sz9z+imsFd/Ss31TlZBAU gs3aIY36ct2qc1F7ZcJbjJEXnso4poy/jsN1oPfLCiPPEj7Zh0ZiDcRDzQiE5ZqUOp0N OM3g== X-Gm-Message-State: AO0yUKVbDVm4BuyM/OKt+JFtfYdnNYZ1IqCFyzW5D4DWXCp/Vz/B5ll4 XqIKa0b4BqpvmfbLmw5wMhU= X-Google-Smtp-Source: AK7set8s76lXaNNN2RMaUPtfnxteOMpWEdH4UqVxop9x8NWFqciq+VPQvE219f5SH1o7vdoPu2yhLw== X-Received: by 2002:a17:903:2349:b0:19e:64b9:41c6 with SMTP id c9-20020a170903234900b0019e64b941c6mr24226177plh.60.1678289385489; Wed, 08 Mar 2023 07:29:45 -0800 (PST) Received: from abensonca-precision-7540.localnet (075-140-015-040.biz.spectrum.com. [75.140.15.40]) by smtp.gmail.com with ESMTPSA id kq14-20020a170903284e00b0019cf747253csm10014846plb.87.2023.03.08.07.29.44 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 08 Mar 2023 07:29:45 -0800 (PST) From: Andrew Benson To: sgk@troutmask.apl.washington.edu Cc: Paul Richard Thomas , Thomas Koenig , "fortran@gcc.gnu.org" Subject: Re: [Patch, fortran] PR37336 finalization Date: Wed, 08 Mar 2023 07:29:44 -0800 Message-ID: <3421859.jTxya6Jnig@abensonca-precision-7540> Organization: Observatories of the Carnegie Institution for Science In-Reply-To: References: MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_00,FREEMAIL_FORGED_FROMDOMAIN,FREEMAIL_FROM,HEADER_FROM_DIFFERENT_DOMAINS,KAM_DMARC_STATUS,RCVD_IN_DNSWL_NONE,RCVD_IN_MSPIKE_H2,SPF_HELO_NONE,SPF_PASS,TXREP autolearn=no autolearn_force=no version=3.4.6 X-Spam-Checker-Version: SpamAssassin 3.4.6 (2021-04-09) on server2.sourceware.org List-Id: I agree with Steve that the lack of finalization support in gfortran means there are not many open-source Fortran projects that rely on it. I've made extensive use of finalization: https://github.com/galacticusorg/galacticus An issue with this is that I had to work-around the missing pieces of finalization (e.g. finalization of function results). Now that those are implemented, my code breaks with Paul's finalization patch applied. This just requires me to go through the code and remove those workarounds (which will result in much cleaner code - so I'm very happy that finalization is now fully implemented). So, it's possible that any other projects that have used the previous, incomplete finalization implementation might similarly break with the new patch. So, maybe some explanation of this in the release notes would be helpful so that users are made aware of possible problems. -Andrew On Wednesday, March 8, 2023 7:12:04 AM PST Steve Kargl via Fortran wrote: > On Wed, Mar 08, 2023 at 07:32:55AM +0000, Paul Richard Thomas wrote: > > Could you please review the patch on that self same time scale? I would be > > happy to have feedback one file at a time. > > Yes, I'll commit time to review individual patches. Smaller > patches are typically easier to review. > > As to other topics in the thread, I suspect you won't > find a lot of open-source Fortran project that make heavy > use of finalization. This is likely due to gfortran's > current lack of robust support. There, however, must > some implicit finalization already occurring. For one > of my codes, I see > > % foreach i (*.o) > foreach? nm $i | grep final > foreach? end > 0000000000000280 T __beamsm_MOD___final_beamsm_Table_t > 0000000000000580 T __bsam_MOD___final_bsam_Bsa_info_t > 00000000000001e0 T __bsam_MOD___final_bsam_Bsa_t > 00000000000000a0 T __ffn_data_MOD___final_ffn_data_Fe_t > > I do not explicitly use finalization nor do I have > subprograms named __final_*. To me, this re-inforces > Richard's point about not breaking existing code. -- * Andrew Benson: https://abensonca.github.io * Galacticus: https://github.com/galacticusorg/galacticus