Re: [Patch, Fortran/90068] Add finalizer creation to array constructor for functions of derived type.
Hi Andre, I had been working in exactly the same area to correct the implementation of finalization of function results in array constructors. However, I couldn't see a light way of having the finalization occur at the correct time; "If an executable construct references a nonpointer function, the result is finalized after execution of the innermost executable construct containing the reference." This caused all manner of difficulty with assignment. I'll come back to this. In the meantime, preventing memory leaks should take priority. This is fine for mainline. Thanks Paul On Wed, 5 Jun 2024 at 10:47, Andre Vehreschild wrote: > Hi Fortraneers, > > another patch to fix a memory leak. This time temporaries created during an > array construction did not have their finalizers called. I.e. allocated > memory > was not freed. The attached patch addresses this issue. > > Regtested ok on x86_64/Fedora 39. Ok for trunk? > > Regards, > Andre > -- > Andre Vehreschild * Email: vehre ad gmx dot de >
Re: [GOMP, Fortran] RFC: Issues with gomp-fortran tests
Hi Steve, there have not been any answers yet, so thank you for looking into that. I tried your proposal and changed the installation directory to: /mnt/work_store/gcc/installs/dev Unfortunately this did not change anything. The gomp-tests are still unable to compile. But I don't see any issues with libsanitizer tests (at least nothing is reported) nor any issues with gmake, make and $MAKE. Looks like that is some Fedora 39 oddity perhaps? Do you have any pointers who might have insight in this expect stuff and could shed a light why this GFORTRAN_UNDER_TEST is checked in the gomp tests only when the libs are not found? > PS: Welcome back to the gfortran effort. Thanks, I hope to produce a constant stream of patches in the next year or even longer. Thank you for your time. If you have any other idea that I could test, please let me know. Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Patch, PR Fortran/90072] Polymorphic Dispatch to Polymophic Return Type Memory Leak
Hi Paul, thank you for the review. No need to apologize. I am happily working on and will ping if I get no reviews. Btw, Mikael, Nikolas and I are covered by the same funding and agreed to not review each others work to prevent any "smells", like "they follow there own agenda". We can of course be triggered by the community to do a second review of each others work, when no one has enough expertise in the area worked on. The patch has been commited to master as gcc-15-1090-g51046e46ae6 > PS That's good news about the funding. Maybe we will get to see "built in" > coarrays soon? You hopefully will see Nikolas work on the shared memory coarray support, if that is what you mean by "built in" coarrays. I will be working on the distributed memory coarray support esp. fixing the module issues and some other team related things. Thanks again for the review. Regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Commited, Patch, Fortran/90068] Add finalizer creation to array constructor for functions of derived type.
Hi Paul, and thanks for the review. Merged as gcc-15-1090-g51046e46ae6. > I had been working in exactly the same area to correct the implementation > of finalization of function results in array constructors. However, I > couldn't see a light way of having the finalization occur at the correct > time; "If an executable construct references a nonpointer function, the > result is finalized after execution of the innermost executable construct > containing the reference." This caused all manner of difficulty with > assignment. I'll come back to this. This sounds to me like another application for a try-finally, but that is just a first shot w/o any deep thought on the aspects. If you like a rubber ducking feel free to contact me. Sometimes talking about it helps... Thanks again and regards, Andre -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [GOMP, Fortran] RFC: Issues with gomp-fortran tests
I don't know too much about the testsuite infrastructure. You'll likely need to ping jakub or tobias, who seem to be the most active gomp contributors. On my FreeBSD system, I have my sources in gcc/gccx, build in gcc/objx, and install into $HOME/work/x. For building and testing, I have a script that ends with # MAKE is required to get the right make(1) propagated through # the 'make' process including the check-fortran phase. # MAKE=gmake export MAKE ../gccx/configure --prefix=$HOME/work/x --enable-languages=c,c++,fortran,lto \ --enable-bootstrap --disable-nls --disable-multilib --disable-libssp \ --enable-initfini-array sleep 1 nice gmake -j6 bootstrap sleep 1 cd gcc nice gmake -j6 check-fortran sleep 1 tail testsuite/gfortran/gfortran.sum Most of the tests that fail have the following log file entry ==3733==ASan runtime does not come first in initial library list; you should either link runtime to your application or manually preload it with LD_PRELOAD. FAIL: gfortran.dg/asan/pointer_assign_16.f90 -fsanitize=address -O0 execution test I've never been able to track down how to fix this. It would seem to me that if some ASan lib needs to come first, then it should proactively preload the requisite libraries during testing. -- steve On Fri, Jun 07, 2024 at 09:39:14AM +0200, Andre Vehreschild wrote: > Hi Steve, > > there have not been any answers yet, so thank you for looking into that. I > tried your proposal and changed the installation directory to: > > /mnt/work_store/gcc/installs/dev > > Unfortunately this did not change anything. The gomp-tests are still unable to > compile. But I don't see any issues with libsanitizer tests (at least nothing > is reported) nor any issues with gmake, make and $MAKE. Looks like that is > some > Fedora 39 oddity perhaps? Do you have any pointers who might have insight in > this expect stuff and could shed a light why this GFORTRAN_UNDER_TEST is > checked in the gomp tests only when the libs are not found? > > > PS: Welcome back to the gfortran effort. > > Thanks, I hope to produce a constant stream of patches in the next year or > even > longer. > > Thank you for your time. If you have any other idea that I could test, please > let me know. > > Regards, > Andre > -- > Andre Vehreschild * Email: vehre ad gmx dot de -- Steve