Re: [Fortran, Patch, v1] 2/(3) Stop spending memory in coarray single mode executables.

Am 25.06.25 um 13:42 schrieb Andre Vehreschild: Hi, attached patch prevents generation of a token component in derived types, when -fcoarray=single is used. Generating the token only wastes memory. It is never even initialized nor accessed. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainl

Re: [Fortran, Patch, v1] 3/(3) Prevent creating tree that is never used.

Am 25.06.25 um 13:45 schrieb Andre Vehreschild: Hi, while hunting for pr120711 I found a construct where a call-tree was created and never used. The patch now just suppresses the tree creation and instead uses directly the tree that is desired. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for m

Re: [Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor

Am 25.06.25 um 13:39 schrieb Andre Vehreschild: Hi all, attached patch fixes an out of bounds access in the clean up code of a concatenating array constructor. A fragment like list = [ list, something() ] lead to clean up using an offset (of the list array) that was manipulated in the loop cop

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On 6/24/25 11:49 PM, Andre Vehreschild wrote: Hi Jerry, thank you very much. Just try it. I can only imagine that Paul had a somehow corrupted build directory or left overs from some previous build. I am still wondering, that I got no automated mail from the build hosts, but I can imagine, that

Re: [PATCH] Fortran: fix ICE in verify_gimple_in_seq with substrings [PR120743]

Am 24.06.25 um 21:11 schrieb Steve Kargl: On Tue, Jun 24, 2025 at 09:00:46PM +0200, Harald Anlauf wrote: here's an obvious fix for a recent regression: substring offset calculations used a wrong type that crashed in gimplification. Andre basically OK'ed it in the PR, but here it is nevertheless

[PATCH 07/17] gfortran: Avoid freeing uninitialized value

Hi, When compiling fortran/match.cc, clang emits a warning fortran/match.cc:5301:7: warning: variable 'p' is used uninitialized whenever 'if' condition is true [-Wsometimes-uninitialized] which looks accurate, so this patch adds an initialization of p to avoid the use. Bootstrapped and teste

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

On 6/24/25 6:09 AM, Andre Vehreschild wrote: Hi all, this series of patches (six in total) adds a new coarray backend library to libgfortran. The library uses shared memory and processes to implement running multiple images on the same node. The work is based on work started by Thomas and Nico

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

Andre, this series of patches (six in total) adds a new coarray backend library to libgfortran. The library uses shared memory and processes to implement running multiple images on the same node. The work is based on work started by Thomas and Nicolas Koenig. No changes to the gfortran compile

Re: [PATCH 16/17] Fortran: Silence a clang warning (suggesting a brace) in io.cc

Thanks for cleaning up gfortran code. I was curious about what the GNU Coding Standard said about this case, but it does not consider initialization of subobjects. I did find 5.3 Clean Use of C Constructs ... Don't make the program ugly just to placate static analysis tools such as l

Re: [PATCH 07/17] gfortran: Avoid freeing uninitialized value

On Wed, Jun 25, 2025 at 04:09:26PM +0200, Martin Jambor wrote: > Hi, > > When compiling fortran/match.cc, clang emits a warning > > fortran/match.cc:5301:7: warning: variable 'p' is used uninitialized > whenever 'if' condition is true [-Wsometimes-uninitialized] > > which looks accurate, so t

Re: [Patch, Fortran, Coarray, PR88076, v1] 6/6 Add a shared memory multi process coarray library.

Andre, I assumed that there would be some overhead, and perhaps bloat, if -fcoarray=single were made the default. With the introduction of a shmem runtime, changing the default is likely a GCC 17 change and not something we should pursue for GCC 16. Yes, I know that this uses shmem and not MPI.

[PATCH 16/17] Fortran: Silence a clang warning (suggesting a brace) in io.cc

Hi, when GCC is built with clang, it suggests that we add a brace to the initialization of format_asterisk: gcc/fortran/io.cc:32:16: warning: suggest braces around initialization of subobject [-Wmissing-braces] So this patch does that to silence it. Bootstrapped and tested on x86_64-linx. O

[Fortran, Patch, PR120637, v1] Ensure expression in finalizer creation is freed only when unused.

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

[Fortran, Patch, v1] 3/(3) Prevent creating tree that is never used.

Hi, while hunting for pr120711 I found a construct where a call-tree was created and never used. The patch now just suppresses the tree creation and instead uses directly the tree that is desired. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehresc

[Fortran, Patch, v1] 2/(3) Stop spending memory in coarray single mode executables.

Hi, attached patch prevents generation of a token component in derived types, when -fcoarray=single is used. Generating the token only wastes memory. It is never even initialized nor accessed. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? Regards, Andre -- Andre Vehreschild

[Fortran, Patch, PR120711, v1] 1/(3) Fix out of bounds access in cleanup of array constructor

Hi all, attached patch fixes an out of bounds access in the clean up code of a concatenating array constructor. A fragment like list = [ list, something() ] lead to clean up using an offset (of the list array) that was manipulated in the loop copying the existing array elements and at the end po

Re: [Patch, Fortran, Coarray, PR88076, v1] 6/6 Add a shared memory multi process coarray library.

Giving something new time to mature before making it the default is always a great policy. My suggestion is aspirational. I’m describing a dream that I hope can be the ultimate goal. There’s no need to rush into implementing my proposed vision. D On Tue, Jun 24, 2025 at 23:25 Andre Vehreschild

Re: [Patch, Fortran, Coarray, PR88076, v1] 0/6 Add a shared memory multi process coarray library.

Hi Jerry, thank you very much. Just try it. I can only imagine that Paul had a somehow corrupted build directory or left overs from some previous build. I am still wondering, that I got no automated mail from the build hosts, but I can imagine, that they get issues with a series of patches, that b