Re: [Ping, Fortran, Patch, PR120637, v1] Ensure expression in finalizer creation is freed only when unused.
Hi Jerry, thanks for the review. Pushed as gcc-16-2086-gd1f05661fa6. Thanks again, Andre On Mon, 7 Jul 2025 10:49:50 -0700 Jerry D wrote: > On 7/7/25 8:39 AM, Andre Vehreschild wrote: > > Ping! > > > OK for mainline. > > Thanks, > > Jerry > > > > On Thu, 26 Jun 2025 15:32:47 +0200 > > Andre Vehreschild wrote: > > > >> Hi, > >> > >> I found a bug in the module cleanup expression at the end of the test. In > >> the attached patch it is corrected. > >> > >> Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? > >> > >> Regards, > >>Andre > >> > >> On Wed, 25 Jun 2025 15:48:11 +0200 > >> Andre Vehreschild wrote: > >> > >>> Hi, > >>> > >>> Antony Lewis reported this issue and also proposed a patch, that removes > >>> the was_finalized tracking. While this may lead to the desired effect for > >>> the issue at hand, I don't believe that the was_finalized tracking code > >>> has been there for no reason. > >>> > >>> This patch fixes the issue that also Antony found, but by ensuring the > >>> expression stays allocated when used instead of being freeed. > >>> > >>> The test has been put into the asan directory of gfortran.dg and reliably > >>> reports the issue without the fix. (With the fix, the asan is quite). > >>> > >>> Regtests ok on x86_64-pc-linxu-gnu / F41. Ok for mainline? > >>> > >>> Regards, > >>> Andre > >> > >> > > > > > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor
HI Harald, hi Mikael, why shall the testcase be invalid? The `list` is empty. Concatenating with it is valid in Fortran like in most other programming languages. The mapping of an empty list in gfortran is to have the array's data pointer set to NULL and the ubound below the lbound. Current gfortran copes fine with this, so does Intel's Fortran compiler and flang (all executables tested with valgrind). In F2018 §7.8 Paragraph 8 it states: "An empty sequence forms a zero-sized array", This is the closest it gets to an unallocated array, but it does not exclude nor include it. Maybe someone with access to other fortran compilers can test this, too. But I see all compilers available to me be fine with an unallocated array in the array constructor. But I am doing to much wrong at the moment, so don't value my words too much. Regards, Andre On Tue, 8 Jul 2025 22:17:23 +0200 Harald Anlauf wrote: > Am 05.07.25 um 14:55 schrieb Mikael Morin: > > Hello Andre, > > > > I get a regression on this testcase with a patch that is otherwise > > regression-free. > > I think the testcase is invalid. > > It does: > > > >> type(container), allocatable :: list(:) > >> > >> list = [list, new_elem(5)] > > > > so it's using the variable 'list' unallocated. > > The original testcase in the PR had an extra zero-sized allocate > > statement before the assignment. > > I think it's the only missing bit. > > > > Mikael, > > I believe you are right: the testcase is technically invalid > without an > >allocate(list(0)) > > as in the original testcase in the PR. > > A corresponding fix is approved. > > Thanks, > Harald > -- Andre Vehreschild * Email: vehre ad gmx dot de
Re: [Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor
Am 09.07.25 um 08:50 schrieb Andre Vehreschild: HI Harald, hi Mikael, why shall the testcase be invalid? The `list` is empty. Concatenating with it is valid in Fortran like in most other programming languages. The mapping of an empty list in gfortran is to have the array's data pointer set to NULL and the ubound below the lbound. Current gfortran copes fine with this, so does Intel's Fortran compiler and flang (all executables tested with valgrind). In F2018 §7.8 Paragraph 8 it states: "An empty sequence forms a zero-sized array", This is the closest it gets to an unallocated array, but it does not exclude nor include it. Maybe someone with access to other fortran compilers can test this, too. But I see all compilers available to me be fine with an unallocated array in the array constructor. But I am doing to much wrong at the moment, so don't value my words too much. NAG: Runtime Error: array_constructor_1.f90, line 12: ALLOCATABLE LIST is not currently allocated Program terminated by fatal error Aborted Regards, Andre On Tue, 8 Jul 2025 22:17:23 +0200 Harald Anlauf wrote: Am 05.07.25 um 14:55 schrieb Mikael Morin: Hello Andre, I get a regression on this testcase with a patch that is otherwise regression-free. I think the testcase is invalid. It does: type(container), allocatable :: list(:) list = [list, new_elem(5)] so it's using the variable 'list' unallocated. The original testcase in the PR had an extra zero-sized allocate statement before the assignment. I think it's the only missing bit. Mikael, I believe you are right: the testcase is technically invalid without an allocate(list(0)) as in the original testcase in the PR. A corresponding fix is approved. Thanks, Harald
Re: [PATCH] libgfortran: add fallback for trigonometric pi-based functions
On 7/8/2025 2:03 AM, Steve Kargl wrote: On Sun, Jul 06, 2025 at 09:09:53PM +0800, Yuao Ma wrote: Hi Tobias, On 7/6/2025 6:34 PM, Tobias Burnus wrote: As that commit is from 2020 and 2.69 in from 2012, it seems as if your autoconf is too new. Can you re-check that the right version is at the beginning of the PATH? Note that there is a CI job that checks whether the generated files are in deed up to date, i.e. the current trunk should be fine unless someone has messed up. It is possible that autoconf 2.69 contains this commit, as we can see from https://github.com/autotools-mirror/autoconf/commit/a1d8293f3bfa2516f9a0424e3a6e63c2f8e93c6e that it has been backported to v2.69b - v2.69e. The main reason is that my devbox has autoconf2.69 (2.69-3.1) from Debian, released on Sat, 19 Nov 2022 21:40:11 +0200, which includes the commit from 2020. This version takes precedence over my compiled version. Once I switch to my compiled version, the generation output functions as expected. The other question is whether the autoconf version shouldn't be updated, given that 2.69 is quite old. Upgrading this basic component may seem like a major change, but opting for the same version with a backported patch appears to be a better choice. Please see https://gcc.gnu.org/install/prerequisites.html. That page specifically says "autoconf version 2.69"; not some 2.69-patch-level. Everyone using the same release prevents conflicting changes. Yes, I am aware of that. The newest version of the patch now uses the correct autoconf version to generate the configure file, eliminating the LARGE_OFF_T noise. Besides the LARGE_OFF_T issue, are there any other issues this patch needs to address? Thanks, Yuao
Re: Coarray shared memory testing
On the tsunami example from Curcic book Modern Fortran I am getting the following: $ cafrun -np 4 ./tsunami At line 201 of file mod_field.f90 Fortran runtime error: Attempting to allocate already allocated variable 'edge' At line 201 of file mod_field.f90 Fortran runtime error: Attempting to allocate already allocated variable 'edge' At line 201 of file mod_field.f90 Fortran runtime error: Attempting to allocate already allocated variable 'edge' At line 201 of file mod_field.f90 Fortran runtime error: Attempting to allocate already allocated variable 'edge' Error: Command: `/usr/lib64/mpich/bin/mpiexec -n 4 ./tsunami` failed to run. It compiles fine. This is with OpenCoarrays using mpich. With -lcaf_shmem it segfaults. Does this look like one of the other bugs already identified? The source code is here: https://github.com/modern-fortran/tsunami Jerry On 7/7/25 2:00 PM, Jerry D wrote: Hello all, I have done the following to test the collection of Andre's patches which implement the subject -lcaf_shmem: 1) Successfully compiled and executed Toon's random_weather.f90 program. The only question I have on this one is when I select an np value such that the slab size does not come out even, the program exits as expected with a STOP code. However, I think this is performed by the first image to hit the stop. It looks like execution of the other images may just be frozen. I wonder if there are constraints in the standard regarding using a STOP within multiple images where each image may be trying to execute it? Is this a race condition or invalid Fortran. Ctrl-C does exit the program. 2) I can build and run OpenCoarrays with this test version of gfortran. However, when I do the usual 'make test', the test program register_alloc_vector hangs in a bad way with execution burning CPU cycles. Outside the OpenCoarrays test environment it appears to run correctly. While testing this with valgrind also hangs. It appears that valgrind is inside some memory check routine. I do not know if it is valid to even try to use valgrind with multiple images. So this test may be invalid. 3) I want to get broader testing of this so I set up a testing branch at the following location where others can clone this and test. https://forge.sourceware.org/JerryD/gfortran-TEST This is a test only repository and I intend to delete it after a few weeks until I can set up a better gfortran testing repo that is maintained current to trunk. One may have to register with sourceware to access this, I have not checked. I would appreciate anyone willing to build and test this branch to help flush out any issues. Feedback and/or test results welcome. Regards, Jerry
Re: [Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor
Am 05.07.25 um 14:55 schrieb Mikael Morin: Hello Andre, I get a regression on this testcase with a patch that is otherwise regression-free. I think the testcase is invalid. It does: type(container), allocatable :: list(:) list = [list, new_elem(5)] so it's using the variable 'list' unallocated. The original testcase in the PR had an extra zero-sized allocate statement before the assignment. I think it's the only missing bit. Mikael, I believe you are right: the testcase is technically invalid without an allocate(list(0)) as in the original testcase in the PR. A corresponding fix is approved. Thanks, Harald
