Re: FINAL subroutines
Hi Salvatore, This looks like it's related to some of the missing finalization functionality (https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37336). Paul has some patches (e.g. https://gcc.gnu.org/pipermail/fortran/2022-January/057415.html) which implement most of the missing functionality. With those patches incorporated your code gives the following output with gfortran: $ ./testfinal Allocating wrapper Calling new_outer_type Assigning outer%test_item Called delete_test_type End of new_outer_type DeAllocating wrapper Called delete_test_type So there is one more call to the finalizer than you found - I haven't checked carefully but I would guess this is a deallocation of LHS on assignment. In testing these patches using the Intel compiler we found that it seems to call the finalization wrapper more than it should, sometimes on objects that have already been deallocated. Your code, compiled with the Intel compiler and then run under valgrind shows the following: $ valgrind ./testfinal ==7340== Memcheck, a memory error detector ==7340== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==7340== Using Valgrind-3.13.0 and LibVEX; rerun with -h for copyright info ==7340== Command: ./testfinal ==7340== ==7340== Conditional jump or move depends on uninitialised value(s) ==7340==at 0x493A51: __intel_sse2_strcpy (in /home/abensonca/Scratch/ ifortTests/testfinal) ==7340==by 0x45D70E: for__add_to_lf_table (in /home/abensonca/Scratch/ ifortTests/testfinal) ==7340==by 0x4410CB: for__open_proc (in /home/abensonca/Scratch/ ifortTests/testfinal) ==7340==by 0x423A64: for__open_default (in /home/abensonca/Scratch/ ifortTests/testfinal) ==7340==by 0x4305A9: for_write_seq_lis (in /home/abensonca/Scratch/ ifortTests/testfinal) ==7340==by 0x4047E1: MAIN__ (testfinal.f90:62) ==7340==by 0x403CE1: main (in /home/abensonca/Scratch/ifortTests/ testfinal) ==7340== Allocating wrapper Calling new_outer_type Assigning outer%test_item Called delete_test_type ==7340== Conditional jump or move depends on uninitialised value(s) ==7340==at 0x40572A: do_alloc_copy (in /home/abensonca/Scratch/ifortTests/ testfinal) ==7340==by 0x406B9A: do_alloc_copy (in /home/abensonca/Scratch/ifortTests/ testfinal) ==7340==by 0x4084ED: for_alloc_assign_v2 (in /home/abensonca/Scratch/ ifortTests/testfinal) ==7340==by 0x404474: target_mod_mp_new_outer_type_ (testfinal.f90:48) ==7340==by 0x40485E: MAIN__ (testfinal.f90:65) ==7340==by 0x403CE1: main (in /home/abensonca/Scratch/ifortTests/ testfinal) ==7340== Called delete_test_type End of new_outer_type DeAllocating wrapper Called delete_test_type ==7340== ==7340== HEAP SUMMARY: ==7340== in use at exit: 48 bytes in 1 blocks ==7340== total heap usage: 14 allocs, 13 frees, 12,879 bytes allocated ==7340== ==7340== LEAK SUMMARY: ==7340==definitely lost: 48 bytes in 1 blocks ==7340==indirectly lost: 0 bytes in 0 blocks ==7340== possibly lost: 0 bytes in 0 blocks ==7340==still reachable: 0 bytes in 0 blocks ==7340== suppressed: 0 bytes in 0 blocks ==7340== Rerun with --leak-check=full to see details of leaked memory ==7340== ==7340== For counts of detected and suppressed errors, rerun with: -v ==7340== Use --track-origins=yes to see where uninitialised values come from ==7340== ERROR SUMMARY: 2 errors from 2 contexts (suppressed: 0 from 0) so there are some cases of what look like incorrect accesses (and some leaked memory). Your code compiled with gfortran (with Paul's patches in place) shows no errors or leaks from valgrind. So, in summary, in this case I think the current gfortran is missing some finalizations (which are fixed by Paul's patches), and ifort is likely doing something wrong and probably calling the finalizer more times than it should. -Andrew On Monday, January 24, 2022 6:49:23 AM PST Salvatore Filippone via Fortran wrote: > And here is the code embedded as text sorry about sending an > attachment that was purged > - testfinal.f90 - > module test_type_mod > > type :: my_test_type > integer, allocatable :: i > contains > final :: delete_test_type > end type my_test_type > > interface my_test_type > module procedure new_test_type_object > end interface my_test_type > > contains > > subroutine delete_test_type(this) > type(my_test_type) :: this > > write(*,*) 'Called delete_test_type' > if (allocated(this%i)) deallocate(this%i) > > end subroutine delete_test_type > > > function new_test_type_object(item) result(res) > type(my_test_type) :: res > integer, intent(in) :: item > !Allocation on assignment > res%i=item > end function new_test_type_object > > > end module test_type_mod > > module target_mod > use test_type_mod > type :: outer_type > type(my_test_type), allocatable :: test_item > end type outer_type > > contain
gfortran, OpenMP and static linking
I've been following the fix proposed by Bernhard in this thread:
https://gcc.gnu.org/pipermail/fortran/2021-April/055907.html
to allow static linking of Fortran codes compiled with -fopenmp. (I know that
static linking of OpenMP codes isn't guaranteed to work, but this fix has
worked well for me anyway.)
This fix seems to no longer work with glibc >= 2.34 - I think because the
functionality of libpthread has been integrated into libc:
https://sourceware.org/pipermail/libc-alpha/2021-August/129718.html
When compiling the simple test code from that thread with glibc 2.34 or newer
I get a segfault:
$ cat omp.f90
use omp_lib
!$omp parallel
write(*,*) "thread ", omp_get_thread_num()
!$omp end parallel
end
$ gfortran -o omp -fopenmp omp.f90 -static -Wl,--whole-archive -lpthread -
Wl,--no-whole-archive && OMP_NUM_THREADS=2 ./omp
./../../gcc-13-source/gcc-13-20220710/libgomp/config/linux/../../allocator.c:
102: warning: Using 'dlopen' in statically linked applications requires at
runtime the shared libraries from the glibc version used for linking
./../../gcc-13-source/gcc-13-20220710/libgomp/oacc-profiling.c:137: warning:
Using 'dlopen' in statically linked applications requires at runtime the
shared libraries from the glibc version used for linking
thread0
thread1
Program received signal SIGSEGV: Segmentation fault - invalid memory
reference.
Backtrace for this error:
#0 0x467b0f in ???
#1 0x0 in ???
Segmentation fault (core dumped)
Tracking this down in gdb it seems that pthread_mutex_destroy() is called, but
that symbol is null.
>From comment #9 in this PR:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58909#c9
I figured out a workaround, which is to create a C file with this content:
#include "pthread.h"
#define nullptr ((void*)0)
void pthread_workaround() {
pthread_mutex_destroy((pthread_mutex_t *) nullptr);
}
which defines a function pthread_workaround() which calls
pthread_mutex_destroy(), but which itself it never called. Compiling that C
code, and linking with the Fortran allows the test code to run successfully.
$ gcc -c -o fix.o -fopenmp fix.c
$ gfortran -c -o omp.o -fopenmp omp.f90
$ gfortran -o omp -fopenmp -static omp.o fix.o
./../../gcc-13-source/gcc-13-20220710/libgomp/config/linux/../../allocator.c:
102: warning: Using 'dlopen' in statically linked applications requires at
runtime the shared libraries from the glibc version used for linking
./../../gcc-13-source/gcc-13-20220710/libgomp/oacc-profiling.c:137: warning:
Using 'dlopen' in statically linked applications requires at runtime the
shared libraries from the glibc version used for linking
$ OMP_NUM_THREADS=2 ./omp
thread0
thread1
My understanding of glibc, pthreads, etc. etc. is insufficient to know if this
is a good and/or safe workaround, but I figured I'd share it here in case:
a) it's useful to anyone;
b) it's indicative of a bug in gfortran;
c) anyone has a more elegant solution!
-Andrew
--
* Andrew Benson: https://abensonca.github.io
* Galacticus: https://bitbucket.org/abensonca/galacticus
Re: Error message
Hi Salvatore, I've run into similar error messages occasionally. I've never been able to fully track down the cause, but it seems to happen if I change the content of a derived type (e.g. add some new variable to it), recompile the module containing it, but don't recompile some other module that USEs that first module. It seems like there are then multiple definitions of the derived type (from different modules) that are out of sync. So, recompiling everything resolves this issue for me. But, as I said, I'm not 100% sure that this is the explanation! -Andrew On Monday, October 17, 2022 2:28:33 AM PDT Salvatore Filippone via Fortran wrote: > Dear all > I am getting the following error message, which I find quite confusing > >68 | use amg_prec_mod > > | 1 > > Fatal Error: Mismatch in components of derived type > '__vtype_psb_c_par_mat_mod_Psb_c_par_mat_type' from 'psb_c_par_mat_mod' at > (1): expecting 'bldext', but got 'aclsum' > compilation terminated. > > from > mpifort -v > mpifort for MPICH version 3.4.3 > Using built-in specs. > COLLECT_GCC=/opt/gnu/12.1.0/bin/gfortran > COLLECT_LTO_WRAPPER=/opt/gnu/12.1.0/libexec/gcc/x86_64-pc-linux-gnu/12.1.0/l > to-wrapper Target: x86_64-pc-linux-gnu > Configured with: ../gcc-12.1.0/configure --prefix=/opt/gnu/12.1.0 > --enable-languages=c,c++,fortran > Thread model: posix > Supported LTO compression algorithms: zlib > gcc version 12.1.0 (GCC) > > > What might the compiler be complaining about? Where can I find additional > info on what to do? > Any help greatly appreciated > > Salvatore -- * Andrew Benson: https://abensonca.github.io * Galacticus: https://github.com/galacticusorg/galacticus
Re: [Patch, fortran] PR37336 finalization
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 +, 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 > 0280 T __beamsm_MOD___final_beamsm_Table_t > 0580 T __bsam_MOD___final_bsam_Bsa_info_t > 01e0 T __bsam_MOD___final_bsam_Bsa_t > 00a0 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
Segfault when using defined assignment
I opened a PR on bugzilla for the following: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109066 The following code (compiled using current trunk), when run, causes a segfault, and valgrind complains about an invalid read. The code appears correct to me, and runs correctly (no segfault, no warnings from valgrind) when compiled with ifort. module Input_Parameters_Bug public type :: resourceManager integer :: counter=0 ! Remove this to resolve segfault contains procedure :: resourceManagerAssign generic :: assignment(=) => resourceManagerAssign end type resourceManager type hdf5Object private type (resourceManager) :: objectManager contains procedure :: openGroup =>IO_HDF5_Open_Group ! procedure :: h5Assign ! Add this defined assignment to avoid segfault. ! generic :: assignment(=) => h5Assign end type hdf5Object interface hdf5Object module procedure hdf5Constructor end interface hdf5Object type :: inputParameters private type(hdf5Object), pointer :: outputParameters => null() ! Make this allocatable instead of pointer to resolve segfault end type inputParameters interface inputParameters module procedure inputParametersConstructorNode end interface inputParameters contains subroutine resourceManagerAssign(to,from) implicit none class(resourceManager), intent( out) :: to class(resourceManager), intent(in ) :: from to%counter=from%counter+1 write (0,*) "ASSIGN",to%counter return end subroutine resourceManagerAssign function hdf5Constructor() result(self) implicit none type(hdf5Object) :: self return end function hdf5Constructor function IO_HDF5_Open_Group(inObject) result (self) implicit none type(hdf5Object) :: self class(hdf5Object), intent(in ) :: inObject write (0,*) "OPEN" return end function IO_HDF5_Open_Group subroutine h5Assign(to,from) implicit none class(hdf5Object), intent( out) :: to class(hdf5Object), intent(in ) :: from write (0,*) "ASSIGN H5" to%objectManager=from%objectManager return end subroutine h5Assign function inputParametersConstructorNode(outputParametersGroup) result(self) implicit none type(inputParameters) :: self type(hdf5Object ), intent(in ) :: outputParametersGroup allocate(self%outputParameters) write (0,*) "START" self%outputParameters=outputParametersGroup%openGroup() write (0,*) "STOP" return end function inputParametersConstructorNode end module Input_Parameters_Bug program Test_Parameters_Bug use :: Input_Parameters_Bug implicit none type(hdf5Object) :: outputFile type(inputParameters) :: testParameters outputFile=hdf5Object() write (0,*) "CALL" testParameters=inputParameters(outputFile) end program Test_Parameters_Bug $ gfortran bug.F90 -g $ valgrind --track-origins=yes ./a.out ==19625== Memcheck, a memory error detector ==19625== Copyright (C) 2002-2017, and GNU GPL'd, by Julian Seward et al. ==19625== Using Valgrind-3.17.0 and LibVEX; rerun with -h for copyright info ==19625== Command: ./a.out ==19625== ASSIGN 1 CALL START OPEN ==19625== Use of uninitialised value of size 8 ==19625==at 0x4012DF: __input_parameters_bug_MOD_inputparametersconstructornode (bug.F90:73) ==19625==by 0x4017D4: MAIN__ (bug.F90:87) ==19625==by 0x401812: main (bug.F90:81) ==19625== Uninitialised value was created by a stack allocation ==19625==at 0x401206: __input_parameters_bug_MOD_inputparametersconstructornode (bug.F90:67) ==19625== Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x4e161ef in ??? #1 0x4012df in __input_parameters_bug_MOD_inputparametersconstructornode at /data001/abenson/Galacticus/galacticus_gfortranFinalization/ bug.F90:73 #2 0x4017d4 in test_parameters_bug at /data001/abenson/Galacticus/galacticus_gfortranFinalization/ bug.F90:87 #3 0x401812 in main at /data001/abenson/Galacticus/galacticus_gfortranFinalization/ bug.F90:81 ==19625== ==19625== Process terminating with default action of signal 11 (SIGSEGV) ==19625==at 0x4E1613E: raise (in /home/abenson/Galacticus/Tools/lib/ libc-2.12.1.so) ==19625==by 0x4E161EF: ??? (in /home/abenson/Galacticus/Tools/lib/ libc-2.12.1.so) ==19625==by 0x4012DE: __input_parameters_bug_MOD_inputparametersconstructornode (bug.F90:73) ==19625==by 0x4017D4: MAIN__ (bug.F90:87) ==19625==by 0x401812: main (bug.F90:81) ==19625== ==19625== HEAP SUMMARY: ==19625== in use at exit: 5,448 bytes in 18 blocks ==19625== total heap usage: 22 allocs, 4 frees, 13,588 bytes allocated ==19625== ==19625== LEAK SUMMARY: ==19625==definitely lost: 0 bytes in 0 blocks ==19625==indirectly lost: 0 bytes in 0 blocks ==19625== possibly lost: 0 bytes in 0 blocks ==19625==still reachable: 5,448 bytes in 18 blocks
Possible problems with OpenMP task parallelism
I've been starting to try using OpenMP task parallelism, but I'm running into some issues. I'm not sufficiently experienced with task parallelism in OpenMP to know if I'm misunderstanding how it should work, or if there's a compiler bug. Here's an example code (highly simplified from the actual code I'm working on): module taskerMod type :: tasker integer :: depth=-1 contains final ::taskerDestruct procedure :: compute => taskerCompute end type tasker contains subroutine taskerDestruct(self) !$ use :: OMP_Lib implicit none type(tasker), intent(inout) :: self write (0,*) "DESTRUCT FROM DEPTH ",self%depth !$ ," : ",omp_get_thread_num() return end subroutine taskerDestruct recursive subroutine taskerCompute(self) !$ use :: OMP_Lib implicit none class(tasker), intent(inout) :: self !$omp atomic self%depth=self%depth+1 write (0,*) "DEPTH ",self%depth !$ ," : ",omp_get_thread_num() if (self%depth < 3) then !$omp task untied call self%compute() !$omp end task end if return end subroutine taskerCompute end module taskerMod program testTasks use :: taskerMod implicit none type(tasker) :: tasker_ tasker_=tasker(0) !$omp parallel !$omp single !$omp taskgroup !$omp task untied call tasker_%compute() !$omp end task !$omp end taskgroup !$omp end single !$omp end parallel end program testTasks Compiling without OpenMP results in the expected behavior: $ gfortran test.F90 $ ./a.out DESTRUCT FROM DEPTH -1 DEPTH1 DEPTH2 DEPTH3 There's a call to the finalizer for the tasker class (on assignment), and then it simply reports the 3 levels of recursion that I've set it to go through. But, if I compile with OpenMP and run just a single thread (the same problem occurs with multiple threads also): $ gfortran test.F90 -fopenmp $ ./a.out DESTRUCT FROM DEPTH -1 DEPTH1 DEPTH2 DESTRUCT FROM DEPTH2 DEPTH3 DESTRUCT FROM DEPTH3 I now see cal
Re: Possible problems with OpenMP task parallelism
I've opened PRs for both of these issues: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110547 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110548 -Andrew -- * Andrew Benson: http://users.obs.carnegiescience.edu/abenson * Galacticus: https://github.com/galacticusorg/galacticus On Wed, Jun 28, 2023, 5:01 PM Andrew Benson wrote: > I've been starting to try using OpenMP task parallelism, but I'm running > into > some issues. I'm not sufficiently experienced with task parallelism in > OpenMP > to know if I'm misunderstanding how it should work, or if there's a > compiler > bug. > > Here's an example code (highly simplified from the actual code I'm working > on): > > module taskerMod > >type :: tasker > integer :: depth=-1 > contains > final ::taskerDestruct > procedure :: compute => taskerCompute >end type tasker > > contains > >subroutine taskerDestruct(self) > !$ use :: OMP_Lib > > > > implicit none > type(tasker), intent(inout) :: self > > write (0,*) "DESTRUCT FROM DEPTH ",self%depth !$ ," : > ",omp_get_thread_num() > > > return >end subroutine taskerDestruct > >recursive subroutine taskerCompute(self) > !$ use :: OMP_Lib > > > > implicit none > class(tasker), intent(inout) :: self > > !$omp atomic > self%depth=self%depth+1 > write (0,*) "DEPTH ",self%depth !$ ," : ",omp_get_thread_num() > > > if (self%depth < 3) then > !$omp task untied > > > call self%compute() > !$omp end task > > > > end if > return >end subroutine taskerCompute > > end module taskerMod > > program testTasks >use :: taskerMod >implicit none >type(tasker) :: tasker_ > >tasker_=tasker(0) >!$omp parallel > > >!$omp single > > >!$omp taskgroup > > > >!$omp task untied > > > >call tasker_%compute() >!$omp end task > > >!$omp end taskgroup > > > >!$omp end single > > >!$omp end parallel > > > end program testTasks > > Compiling without OpenMP results in the expected behavior: > $ gfortran test.F90 > $ ./a.out > DESTRUCT FROM DEPTH -1 > DEPTH1 > DEPTH2 > DEPTH3 > > There's a call to the finalizer for the tasker class (on assignment), and > then > it simply reports the 3 levels of recursion that I've set it to go through. > > But, if I compile with OpenMP and run just a single thread (the same > problem > occurs with multiple threads also): > $ gfortran test.F90 -fopenmp > $ ./a.out > DESTRUCT FROM DEPTH -1 > DEPTH1 > DEPTH2 > DESTRUCT FROM DEPTH2 > DEPTH3 > DESTRUCT FROM DEPTH3 > > I now see calls to the finalizer from the 2nd and 3rd recursive calls to > the > taskerCompute function. Since self is intent(inout) to this function I > wouldn't expect it to be finalized. But, this is where I doubt my > understanding of how tasks should behave. > > This happens with versions 12.0.0, 13.0.1, and the current HEAD of the GCC > git > repo. But, ifort, does not produce the extra finalizer calls when used to > compile the above with OpenMP. > > Does anyone have any insights into whether or not the finalizer should be > called in this situation? > > Another issue I find with a modified version of the above: > > module taskerMod > >type :: helper >end type helper > >type :: tasker > integer :: depth=-1 > contains > final ::taskerDestruct > procedure :: compute => taskerCompute >end type tasker > > contains > >subroutine taskerDestruct(self) > !$ use :: OMP_Lib > > > > implicit none > type(tasker), intent(inout) :: self > > write (0,*) "DESTRUCT FROM DEPTH ",self%depth !$ ," : > ",omp_get_thread_num() > > > return >end subroutine taskerDestruct > >recursive subroutine taskerCompute(self,helper_) > !$ use :: OMP_Lib > > > > implicit none > class(tasker), intent(inout) :: self > class(helper), intent(inout), optional :: helper_ > > !$omp atomic > > > self%depth=self%depth+1 > write (0,*) "DEPTH ",self%depth !$ ," : ",omp_get_thread_num() > > > if (self%depth < 3) then > !$omp task untied > > > call self%compute(helper_) > !$omp end task > > > > end if > return >end subroutine taskerCompute > > end module taskerMod > > program testTasks >use :: taskerMod >implicit none >type(tasker) :: tasker_ >type(helper) :: helper_ > >tasker_=tasker(0) >!$omp parallel > > >!$omp single > > >!$omp taskgroup > > > >!$omp task untied > > > >call tasker_%compute() >!$omp end task > > >!$omp end taskgroup > > > >!$omp end single > > >!$omp end parallel > > > end program testTasks > > This one causes a segfault: > $ gfortran test1.F90 -fopenmp > $ ./a.out > DESTRUCT FROM DEPTH -1 > DEPTH
Missing finalizations
I will (hopefully) have some time in the next few months to work on gfortran. I could pick up a few easy PRs to fix, but a more ambitious (and more useful) task would be to work on some of the missing finalizations. For my own work finalization of function results and stay constructors would be most useful. But, I don't have any real idea of how difficult this would be to do. Does any one here have any guidance on how to do this, or how challenging it might be? Thanks, Andrew
Re: Missing finalizations
Hi Paul, Thanks, that sounds good. -Andrew On Tuesday, September 14, 2021 11:51:00 PM PDT Paul Richard Thomas wrote: > Hi Andrew, > > Not long before I had to step aside (temporarily, I hope) from gfortran > maintenance, I made quite a lot of progress on missing finalizations. I'll > dig out the in-progress patch for you and remind myself of the remaining > issues. One of these was a standards problem, where the patched gfortran > differed from a leading brand and I thought that the leading brand was > wrong. > > Give me a day or two and prod me if I do not come up with the goods by the > end of the week. > > Paul > > > On Wed, 15 Sept 2021 at 01:31, Andrew Benson via Fortran < > > fortran@gcc.gnu.org> wrote: > > I will (hopefully) have some time in the next few months to work on > > gfortran. > > I could pick up a few easy PRs to fix, but a more ambitious (and more > > useful) > > task would be to work on some of the missing finalizations. For my own > > work > > finalization of function results and stay constructors would be most > > useful. > > But, I don't have any real idea of how difficult this would be to do. Does > > any > > one here have any guidance on how to do this, or how challenging it might > > be? > > > > Thanks, > > Andrew -- * Andrew Benson: https://abensonca.github.io * Galacticus: https://github.com/galacticusorg/galacticus T
Re: Missing finalizations
Hi Paul, I'm following up on this as you requested. I won't be able to start looking into this seriously for a week or two anyway. Thanks, Andrew On Tuesday, September 14, 2021 11:51:00 PM PDT Paul Richard Thomas wrote: > Hi Andrew, > > Not long before I had to step aside (temporarily, I hope) from gfortran > maintenance, I made quite a lot of progress on missing finalizations. I'll > dig out the in-progress patch for you and remind myself of the remaining > issues. One of these was a standards problem, where the patched gfortran > differed from a leading brand and I thought that the leading brand was > wrong. > > Give me a day or two and prod me if I do not come up with the goods by the > end of the week. > > Paul > > > On Wed, 15 Sept 2021 at 01:31, Andrew Benson via Fortran < > > fortran@gcc.gnu.org> wrote: > > I will (hopefully) have some time in the next few months to work on > > gfortran. > > I could pick up a few easy PRs to fix, but a more ambitious (and more > > useful) > > task would be to work on some of the missing finalizations. For my own > > work > > finalization of function results and stay constructors would be most > > useful. > > But, I don't have any real idea of how difficult this would be to do. Does > > any > > one here have any guidance on how to do this, or how challenging it might > > be? > > > > Thanks, > > Andrew -- * Andrew Benson: https://abensonca.github.io * Galacticus: https://github.com/galacticusorg/galacticus
