Re: Coarray shared memory testing

On 7/19/25 2:26 PM, Thomas Koenig wrote: I wrote: I have grave concerns. At the last (to me an Nicolas) known state, before he was ousted from the project, there were known race conditions, which can cause freezing and/or data corruption. I believe these have not been addressed, neither teste

Re: Coarray shared memory testing

On 7/19/25 10:59 AM, Toon Moene wrote: On 7/19/25 18:32, Jerry D wrote: I expanded on Toon's random_weather.f90 test using: !integer, parameter :: DNX = 72, DNY = 70, DNZ = 30, BDSIZE = 4, HORSTEP =   1, VERSTEP = 100, FCLEN = 3600, TIMSTEP = 240 integer, parameter :: DNX = 1000

Re: Coarray shared memory testing

On 7/17/25 9:37 PM, Jerry D wrote: I have created a new gfortran-test branch on gcc here. origin/devel/gfortran-test This has the patches applied as needed to do the testing I have done. When Andre's patches are approved I will revert and rebase this so we can test the next set of

Re: [Patch] Fortran/OpenACC: Permit PARAMETER as 'var' in clauses (+ ignore)

On 7/11/25 10:36 PM, Tobias Burnus wrote: Now, finally pushed as r16-2213-g451b6dbf475959. Tobias On June 27, 2025, Tobias Burnus wrote: Background: In real-world code, one can find:    !$ACC DECLARE COPYIN(c1es, c2es, ...) as here for the ICON weather model. This clearly implies that other co

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

On 7/10/25 2:27 AM, Andre Vehreschild wrote: Hi all, after Jerry had the idea to use OpenCoarray's tests to also test caf_shmem, a few issue arose. Those have been fixed now in the updated patch-series. I have put all patches into one mail to allow the CIs to pick them all up and hopefully test

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

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

Re: [Fortran, Patch, PR120843, v3] Fix reject valid, because of inconformable coranks

On 7/2/25 4:12 PM, Jerry D wrote: On 7/2/25 9:40 AM, Jerry D wrote: On 7/2/25 3:14 AM, Andre Vehreschild wrote: Hi all, I successfully created a big mess with the previous patch. First of all by applying an outdated one and secondly by adding the conformance checks for coranks in

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

On 7/4/25 5:12 AM, Andre Vehreschild wrote: Hi all, attached patches goes on top of other 6 caf_shmem coarray patches and fixes missing includes esp. on non-Linux systems. I have tested this on a FreeBSD, which is very time consuming due to it being fully virtualized on my system. Regtests ok o

Re: [Fortran, Patch, PR120843, v3] Fix reject valid, because of inconformable coranks

On 7/2/25 9:40 AM, Jerry D wrote: On 7/2/25 3:14 AM, Andre Vehreschild wrote: Hi all, I successfully created a big mess with the previous patch. First of all by applying an outdated one and secondly by adding the conformance checks for coranks in a3f1cdd8ed46f9816b31ab162ae4dac547d34ebc

Re: [Fortran, Patch, PR120843, v3] Fix reject valid, because of inconformable coranks

On 7/2/25 3:14 AM, Andre Vehreschild wrote: Hi all, I successfully created a big mess with the previous patch. First of all by applying an outdated one and secondly by adding the conformance checks for coranks in a3f1cdd8ed46f9816b31ab162ae4dac547d34ebc. Checking the standard even using AI (haha

Re: [PATCH] Fortran: fix minor issues with coarrays

On 7/1/25 12:51 PM, Harald Anlauf wrote: Dear all, the attached patch fixes the following minor issues found by running f951 under valgrind for the just added new testcases coindexed_6.f90 and coindexed_7.f90: - minor front-end memleaks with non-freed strings and lost GMP variables  (these are

Re: [PATCH, part2] Fortran: follow-up fix to checking of renamed-on-use interface name [PR120784]

On 6/27/25 1:48 PM, Harald Anlauf wrote: Dear all, my original patch caused a regression on previously working code where an imported interface was *not* renamed-on-use, as the related new logic did not expect a local_name to be an empty string. Funnily, there was no previously existing test in

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

On 6/26/25 12:22 AM, Andre Vehreschild wrote: Hi Jerry, thanks for testing. I have fixed IMO most of the whitespace issues in the patch attached to this mail: https://gcc.gnu.org/pipermail/fortran/2025-June/062349.html About the 32 vs. 64 bit versions of the libraries: I never got in touch with

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

they get issues with a series of patches, that build upon each other. Just try it. The more feedback, the better. Regards, Andre On Tue, 24 Jun 2025 11:07:23 -0700 Jerry D wrote: On 6/24/25 6:09 AM, Andre Vehreschild wrote: Hi all, this series of patches (six in total) adds a new

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] PR106135 - Implement F2018 IMPORT statements

On 6/23/25 9:43 AM, Paul Richard Thomas wrote: Hello All, I was mulling over the F2018 status of gfortran, when I came across the additions to the IMPORT statement. This seemed like such a useful addition to fortran that I set about an implementation; thinking that this would be low hanging f

Re: [PATCH] Fortran: fix checking of renamed-on-use interface name [PR120784]

On 6/23/25 12:39 PM, Harald Anlauf wrote: Dear all, here's an obvious fix for a rejects-valid when an interface was renamed on use and is extended in the importing module.  One check incorrectly referred to the original interface name, not the renamed one. Regtested on x86_64-pc-linux-gnu.  OK

Re: [PATCH] fortran: Statically initialize length of SAVEd character arrays

On 6/18/25 2:02 PM, Mikael Morin wrote: From: Mikael Morin Regression-tested on x86_64-pc-linux-gnu. OK for master? Was there a PR for this? or something you just ran into? Not a problem either way, just curious. It looks OK to me. OK for master. Jerry -- >8 -- gcc/fortran/ChangeL

Re: [PATCH] Fortran: fix checking of MOLD= in ALLOCATE statements [PR51961]

On 6/15/25 1:22 PM, Harald Anlauf wrote: Am 15.06.25 um 21:25 schrieb Harald Anlauf: Dear all, the attached patch fixes a rejects-valid: in an ALLOCATE statement with MOLD= present, if the allocate-object has an explicit-shape-spec, the compatibility of ranks is not required by the standard.  (

Re: [PATCH] libfortran: Regenerate files

On 6/6/25 5:34 AM, FX Coudert wrote: Hi, In commit 5e918a4db9e4a5bdbeafec6881fa8b22a55d3789, regenerated files were not included in the commit as they should have been. Therefore, a whitespace fix was not propagated. Sync generated files now, as obtained from a run with --enable-maintainer-mode.

[PATCH, libgfortran] PR119856 Part 2 Fix error handling for missing commas in format strings

Hi all, The attached patch fixes a latent issue where we were saving a parsed and checked format string that had a missing comma. This resulted in the correct error on the first use of the string, but a missed error on subsequent uses of the string. New test case provided. Regression tested

Minor patch committed.

This was a followup to make the error message a little better. Committed. commit c69afa2f1bd7455457ab4e028a6bc51211b2dd20 (HEAD -> master, origin/master, origin/HEAD) Author: Jerry DeLisle Date: Thu May 29 10:02:00 2025 -0700 Fortran: Make minor adjustment to error message.

Re: [PATCH, Fortran] Bug 119856 - Missing commas in I/O formats not diagnosed by default at compile time.

On 5/28/25 10:09 AM, Steve Kargl wrote: On Wed, May 28, 2025 at 08:11:05AM -0700, Jerry D wrote: The attached patch is simple and self explanatory in the git log entry. Regression tested on X86_64-linux-gnu. OK for trunk? Yes, with one question. commit

[PATCH, Fortran] Bug 119856 - Missing commas in I/O formats not diagnosed by default at compile time.

The attached patch is simple and self explanatory in the git log entry. Regression tested on X86_64-linux-gnu. OK for trunk? Regards, Jerrycommit 845768cbead03f76265e491bcf5ea6de7020ff39 Author: Jerry DeLisle Date: Wed May 28 07:56:12 2025 -0700 Fortran: Adjust handling of optional com

Re: Test suite failures.

On 5/27/25 2:19 PM, Harald Anlauf wrote: Jerry, all, that was entirely my fault - attempting a last-minute cleanup that reordered code, trying to use a refactoring.  I've put on my brown bag and pushed a corrections as obvious as: r16-921-g74a2281ae18c6d. See attached. Caveat: this was tested

Test suite failures.

After my last commit, I always rerun make check-fortran. Now I see a bunch of fails. I reverted my patch locally and did a rebuild and I still see these. Heralds patch still in there. No failures after reverting this: commit r16-914-g787a8dec1acedf5561c8ee43bed0b3653fca150d Author: Harald Anl

Re: [PATCH, fortran] PR120049 - ICE when using IS_C_ASSOCIATED ()

On 5/27/25 12:39 PM, Harald Anlauf wrote: Hi Jerry! On 5/27/25 21:02, Jerry D wrote: On 5/20/25 12:35 PM, Jerry D wrote: On 5/20/25 12:01 PM, Harald Anlauf wrote: Hi Jerry! Am 20.05.25 um 05:23 schrieb Jerry D: On 5/19/25 1:50 PM, Harald Anlauf wrote: Hi Jerry, so contrary to what the

Re: [PATCH] Fortran: fix parsing of type parameter inquiries of substrings [PR101735]

On 5/27/25 11:24 AM, Harald Anlauf wrote: Dear all, the attached patch fixes a variety of small issues with parsing of inquiry references of substrings.  The testcase exercises variations of the examples in the PR and ensures that these are successfully simplified. Don't try it with other compi

Re: [PATCH, fortran] PR120049 - ICE when using IS_C_ASSOCIATED ()

On 5/20/25 12:35 PM, Jerry D wrote: On 5/20/25 12:01 PM, Harald Anlauf wrote: Hi Jerry! Am 20.05.25 um 05:23 schrieb Jerry D: On 5/19/25 1:50 PM, Harald Anlauf wrote: Hi Jerry, so contrary to what the name of patch claims (pr120049-final.diff), it fixes only the case of direct use of

Re: [patch, fortran] PR120049 - ICE when using IS_C_ASSOCIATED ()

push the incremental patch now, go ahead. Cheers, Harald Am 18.05.25 um 23:46 schrieb Jerry D: On 5/18/25 2:34 PM, Jerry D wrote: On 5/18/25 2:10 PM, Harald Anlauf wrote: Hi Jerry, I found 2 corner invalid cases which are silently accepted with your patch when iso_c_binding is used indirectly

Re: [patch, fortran] PR120049 - ICE when using IS_C_ASSOCIATED ()

On 5/18/25 2:34 PM, Jerry D wrote: On 5/18/25 2:10 PM, Harald Anlauf wrote: Hi Jerry, I found 2 corner invalid cases which are silently accepted with your patch when iso_c_binding is used indirectly:    print *, c_associated(c_loc(val), C_NULL_FUNPTR)    print *, c_associated(C_NULL_FUNPTR

Re: [patch, fortran] PR120049 - ICE when using IS_C_ASSOCIATED ()

On 5/18/25 2:10 PM, Harald Anlauf wrote: Hi Jerry, I found 2 corner invalid cases which are silently accepted with your patch when iso_c_binding is used indirectly:   print *, c_associated(c_loc(val), C_NULL_FUNPTR)   print *, c_associated(C_NULL_FUNPTR, c_loc(val)) These should get rejected

[patch, fortran] PR120049 - ICE when using IS_C_ASSOCIATED ()

Hello all, The attached patch revises the logic of the checks in gfc_check_c_associated to handle previous cases that ICE'ed as seen in the PR. There are multiple gotchas in these cases, particularly with the optional c_ptr_2 argument. I factored the logic into two new helper functions. This

Re: [PING] [PATCH] Fortran: fix passing of inquiry ref of complex array to TRANSFER [PR102891]

On 5/10/25 11:33 AM, Harald Anlauf wrote: Early ping. Am 06.05.25 um 21:06 schrieb Harald Anlauf: Dear all, here's another rather obvious case where a temporary is needed for an inquiry reference of a complex array which is a component of a derived type.  In contrast to PR119986, the argument

Re: [patch, fortram] Bug 120049 - ICE when using IS_C_ASSOCIATED ()

On 5/6/25 10:59 AM, Steve Kargl wrote: On Tue, May 06, 2025 at 07:43:41PM +0200, Harald Anlauf wrote: the new logic misses the following bad code: print *, c_associated(c_loc(val), 42) This now ICEs here. I suggest to not 'return true' too early before all arguments have been checked.

Re: [patch, fortram] Bug 120049 - ICE when using IS_C_ASSOCIATED ()

On 5/6/25 12:44 AM, Paul Richard Thomas wrote: HI Jerry, The patch looks good to me. OK for mainline and for backporting. I never quite know what to suggest for delaying backporting and so I will leave it to your judgement. Thanks for the patch. Paul Thanks Paul, committed as: commit r16

[patch, fortram] Bug 120049 - ICE when using IS_C_ASSOCIATED ()

Attached patch fixes this by checking for BT_VOID and EXPR_FUNCTION. Thank you for guidance from Steve in the PR and Vincent for identifying the problem. Two test case files added to the testsuite. Regression tested on x86_64. OK for mainline? Since this breakage impacts gtk-fortran I would a

Re: [PATCH] Fortran: fix procedure pointer handling with -fcheck=pointer [PR102900]

On 4/24/25 12:59 PM, Harald Anlauf wrote: Dear all, the attached patch is the result of my attempts to fix an ICE when compiling gfortran.dg/proc_ptr_52.f90 with -fcheck=all.  While trying to reduce this, I found several oddities with functions returning class(*), pointer that ICE'd too. The or

Re: [patch fortran] PR119836 [15/16 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

Ping! Can we backport this to 15 please? Regards, Jerry On 4/18/25 6:35 PM, Jerry D wrote: On 4/18/25 5:48 PM, Jerry D wrote: I will be committing a fix for this to the 16 mainline tonight. I am requesting Release Manager approval to push to 15 release branch after full testing here

Re: [patch fortran] PR119836 [15/16 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

On 4/18/25 5:48 PM, Jerry D wrote: I will be committing a fix for this to the 16 mainline tonight. I am requesting Release Manager approval to push to 15 release branch after full testing here. Regards, Jerry See attached diff. 2025-04-18  Steven G. Kargl  PR fortran/119836 * resolve.cc

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support

On 4/18/25 9:13 AM, Paul Richard Thomas wrote: Hi Andre, On Thu, 17 Apr 2025 at 14:20, Andre Vehreschild > wrote: Hi Jerry, thanks for the review and sorry for the long delay. With publishing the team's patches for gfortran, I also created a pull request f

[patch fortran] PR119836 [15/16 Regression] Elemental intrinsic treated as IMPURE within BLOCK within DO CONCURRENT

I will be committing a fix for this to the 16 mainline tonight. I am requesting Release Manager approval to push to 15 release branch after full testing here. Regards, Jerry See attached diff. 2025-04-18 Steven G. Kargl PR fortran/119836 * resolve.cc(check_pure_function, pure_subroutine

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support

On 4/18/25 8:05 AM, Jerry D wrote: On 4/17/25 6:20 AM, Andre Vehreschild wrote: Hi Jerry, thanks for the review and sorry for the long delay. With publishing the team's patches for gfortran, I also created a pull request for OpenCoarrays. There I was asked to add some testcase with

Re: [Fortran, Patch, Teams, 6/5] Various fixes for F2018 teams support

On 4/17/25 6:20 AM, Andre Vehreschild wrote: Hi Jerry, thanks for the review and sorry for the long delay. With publishing the team's patches for gfortran, I also created a pull request for OpenCoarrays. There I was asked to add some testcase with more "beef" in it. I.e. something that really ma

Re: [PATCH] Fortran: pure subroutine with pure procedure as dummy [PR106948]

On 4/15/25 12:01 PM, Harald Anlauf wrote: Dear all, the testcase in the PR shows a case where the pureness of a function is not properly determined, even though the function is resolved, and its attributes clearly show that it is pure, because gfc_pure_function relies on isym or esym being set. 

Re: [Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support

On 4/13/25 11:47 PM, Andre Vehreschild wrote: Hi Jerry, thank you very much for the review. I would love to fix the nits you found, but I don't see, what you see. Can you elaborate? May be some mail client has removed something, or I am missing something. Are you commenting on gfc_error (

Re: [Fortran, Patch, Teams, 0/5] Improve on Fortran 2018 teams support

On 4/10/25 5:59 AM, Andre Vehreschild wrote: Hi all, I again have a series of patches. This time to improve the teams support in gfortran. 1/5: Improves/Unifies handling of STAT= and ERRMSG= handling, which is part of all TEAM statements. I wanted to prevent repeating myself over and over so I

[patch, libgfortran] PR119502

The attached patch fixes this bug by adding checks for negative unit numbers in CLOSE and OPEN statements. Regression tested on x86_64_linux_gnu. OK for trunk Author: Jerry DeLisle Date: Sat Apr 12 19:51:23 2025 -0700 Fortran: Fix runtime segfault closing negative unit Whe

Re: [Patch] Fortran: Add code gen for do,concurrent's LOCAL/LOCAL_INIT [PR101602]

On 4/8/25 10:44 AM, Tobias Burnus wrote: This patch is essentially the one of PR101602, comment 6. Thus, it has the same issues as that patch: * LOCAL for derived-type variables with default   initalizers do not work (not initialized) * LOCAL/LOCAL_INIT for assumed-shape arrays fails   (need s

Re: [PATCH] Fortran: fix issue with impure elemental subroutine and interface [PR119656]

On 4/8/25 1:43 PM, Harald Anlauf wrote: Hi all, the attached patch fixes a rather strange 12/13/14/15 regression. When walking through the list of procedures in an interface to find the matching one, the code could remember an inferred type from a false module procedure within the same interface

Re: [Fortran, Patch, PR119349, v1] Fix regression of polymorphic dummy sourced from array constructors.

On 3/20/25 9:20 AM, Andre Vehreschild wrote: Hi all, attached patch fixes a 15-regression where an element of an actual temporary array, i.e., elemental([ e1, e2...]) passed to the formal polymorphic dummy leads to a double free of the derived types components. This patch prevents this by preven

Re: [PATCH] Fortran: check type-spec in ALLOCATE of dummy with assumed length [PR119338]

On 3/17/25 2:47 PM, Harald Anlauf wrote: Dear all, F2003:C626 was only partly implemented: we missed the case of ALLOCATE of character dummy arguments with assumed length, where the type-spec must use asterisk, i.e. (*). Regtesting found one testcase that had a previously undetected error and n

Re: [Patch, fortran] PR85836: Implement the F2018 reduce intrinsic

On 3/16/25 10:26 AM, Paul Richard Thomas wrote: --- snip --- A slight niggle is the linker error that comes up if compiled without any optimization: /usr/bin/ld: warning: /tmp/cc9cx9Rw.o: requires executable stack (because the .note.GNU-stack section is executable) I think that this is unlikely

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

On 3/10/25 9:57 AM, Jerry D wrote: On 3/10/25 1:08 AM, Andre Vehreschild wrote: Hi Steve and Jerry, thanks for the review and the proposed changes. I have based on them, but needed to adapt some places, because the meaning was changed. Can you please take another look? Jerry, where do I

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

On 3/10/25 1:08 AM, Andre Vehreschild wrote: Hi Steve and Jerry, thanks for the review and the proposed changes. I have based on them, but needed to adapt some places, because the meaning was changed. Can you please take another look? Jerry, where do I find this check-script? In bin/ nothing ju

Re: [Ping, Patch, www-docs, Fortran, Coarray-ABI] Announce coarray-ABI changes in gfortran-15

On 3/6/25 10:02 AM, Steve Kargl wrote: Andre, Here's a bit of wordsmith. I removed the abbreviation "Esp." I'm not sure if there is additional markup needed; especially, with the "-fcoarray=single" I inserted. Coarray support has been reworked to allow access to components in derived typ

Re: [Fortran, Patch, PR107143, v1] Fix gimplification error in forall' pointer remapping

On 3/5/25 6:34 AM, Andre Vehreschild wrote: Hi all, attached patch fixes a gimplification error when a pointer remapping on derived type's components with deferred arrays is made. The issue boiled down to the dependency analysis being to loose. It saw a dependency as soon as both sides of the =>

Re: [patch, doc] PR108369 GCC: Documentation of -x option

On 2/27/25 11:31 AM, Harald Anlauf wrote: Am 27.02.25 um 02:58 schrieb Jerry D: This attached patch is intended to clarify the '-x' option using '-x f77' as an example. I was not sure who should review. Tested by inspecting the generated info file from make info. OK for t

Re: [PATCH] Fortran: fix check for non-optional arrays passed to elemental

On 2/27/25 12:33 PM, Peter Hill wrote: On Thu, 27 Feb 2025 at 18:09, Jerry D wrote: On 2/27/25 7:38 AM, Peter Hill wrote: Dear all, The attached patch fixes an ICE in gfc_resolve_code when passing an optional array to an elemental procedure with `-pedantic` enabled. PR95446 added the

ping Re: [patch, doc] PR108369 GCC: Documentation of -x option

On 2/26/25 5:58 PM, Jerry D wrote: This attached patch is intended to clarify the '-x' option using '-x f77' as an example. I was not sure who should review. Tested by inspecting the generated info file from make info. OK for trunk and backport to 14? Regards, Jerry A

Re: [PATCH] Fortran: fix check for non-optional arrays passed to elemental

On 2/27/25 7:38 AM, Peter Hill wrote: Dear all, The attached patch fixes an ICE in gfc_resolve_code when passing an optional array to an elemental procedure with `-pedantic` enabled. PR95446 added the original check, this patch fixes the case where the other actual argument is an array literal (

[patch, doc] PR108369 GCC: Documentation of -x option

This attached patch is intended to clarify the '-x' option using '-x f77' as an example. I was not sure who should review. Tested by inspecting the generated info file from make info. OK for trunk and backport to 14? Regards, Jerry Author: Jerry DeLisle Date: Wed Feb 26 17:26:26 2025 -080

Re: [Fortran, Patch, PR108233, v1] Prevent SAVE_EXPR on lhs in assign.

On 2/25/25 9:18 AM, Andre Vehreschild wrote: Hi all, for some recreation after all the coarray stuff, I found this pr cc'ed to me. Taking a look at it, I figured that using a SAVE_EXPR on the lhs of the assignment was doing the harm. The data seems to be not written back into the vector shaped d

Re: [Patch] Fortran: Improve gfc_array_kind for assumed rank; gfc_tree_array_size on 'tree'

On 2/19/25 10:08 AM, Tobias Burnus wrote: The attached patch does some ground-laying work for OpenMP deep mapping - touching common gfortran code. It does so by: (1)gfc_tree_array_size now can determine the array size not only from the passed Fortran gfc_expr but also using a descriptor, passe

Re: [patch, fortran] PR117430 gfortran allows type(C_ptr) in I/O list

On 2/13/25 7:09 PM, Jerry D wrote: On 2/13/25 1:42 PM, Harald Anlauf wrote: Am 12.02.25 um 21:49 schrieb Jerry D: The attached patch is fairly obvious. The use of notify_std is changed to a gfc_error. Several test cases had to be adjusted. Regression tested on x86_64. OK for trunk? This is

Re: 7/7 [Fortran, Patch, Coarray, PR107635] Remove deprecated coarray routines

On 2/13/25 11:48 AM, Jerry D wrote: On 2/10/25 2:25 AM, Andre Vehreschild wrote: [PATCH 7/7] Fortran: Remove deprecated coarray routines [PR107635] I have applied all patches. Regression tested OK here. From patch 5 there was one reject: patching file gcc/testsuite/gfortran.dg/coarray

Re: [patch, fortran] PR117430 gfortran allows type(C_ptr) in I/O list

On 2/13/25 1:42 PM, Harald Anlauf wrote: Am 12.02.25 um 21:49 schrieb Jerry D: The attached patch is fairly obvious. The use of notify_std is changed to a gfc_error. Several test cases had to be adjusted. Regression tested on x86_64. OK for trunk? This is not a review, just some random

Re: [patch, Fortran] Fix PR 118845

On 2/13/25 11:59 AM, Thomas Koenig wrote: Hello world, this was an interesting regression.  It came from my recent patch, where an assert was triggered because a procedure artificial dummy argument generated for a global symbol did not have the information if if was a function or a subroutine. 

Re: 7/7 [Fortran, Patch, Coarray, PR107635] Remove deprecated coarray routines

On 2/10/25 2:25 AM, Andre Vehreschild wrote: [PATCH 7/7] Fortran: Remove deprecated coarray routines [PR107635] I have applied all patches. Regression tested OK here. From patch 5 there was one reject: patching file gcc/testsuite/gfortran.dg/coarray/send_char_array_1.f90 Hunk #1 FAILED at 39

[patch, fortran] PR117430 gfortran allows type(C_ptr) in I/O list

The attached patch is fairly obvious. The use of notify_std is changed to a gfc_error. Several test cases had to be adjusted. Regression tested on x86_64. OK for trunk? Regards, Jerry Author: Jerry DeLisle Date: Tue Feb 11 20:57:50 2025 -0800 Fortran: gfortran allows type(C_ptr) in

Re: 1/7 [Fortran, Patch, Coarray, PR107635] Move caf_get-rewrite to rewrite.cc

On 2/10/25 2:25 AM, Andre Vehreschild wrote: [PATCH 1/7] Fortran: Move caf_get-rewrite to rewrite.cc [PR107635] Add a rewriter to keep all expression tree manipulation that is not optimization together. At the moment this is just a move from resolve.cc, but will be extended to handle more cases

Re: [patch, libfortran] PR114618 Version 2 Format produces incorrect output when contains 1x, ok when uses " "

On 1/31/25 11:30 AM, Harald Anlauf wrote: --- snip -- So either commit the current version and track this issue in a PR if not yet done, or have a look if there is a quick fix. Thanks for the work! Harald Committed as: commit cfed99751c1a3b93ca66451eb1b62271e682f927 (HEAD -> master, origin/

Re: [patch, libfortran] PR114618 Version 2 Format produces incorrect output when contains 1x, ok when uses " "

On 1/31/25 11:30 AM, Harald Anlauf wrote: Hi Jerry, Am 30.01.25 um 21:50 schrieb Jerry D: On 1/29/25 10:30 AM, Jerry D wrote: Follow-up: On 1/28/25 1:33 PM, Harald Anlauf wrote: Jerry, while I haven't read your actual patch yet, I think the testcase is slightly incorrect. In fact,

Re: [PING, PATCH] fortran: fix -MT/-MQ adding additional target [PR47485]

Committed as: commit e41a5a2a0832509fa1c0b7cab0c8001fadbd23d4 (HEAD -> master, origin/master, origin/HEAD) Author: Jerry DeLisle Date: Tue Feb 4 17:21:42 2025 -0800 Fortran: Fix PR 47485. The -MT and -MQ options should replace the default target in the generated dependency file

Re: [PING, PATCH] fortran: fix -MT/-MQ adding additional target [PR47485]

On 2/4/25 9:29 AM, Jerry D wrote: On 2/3/25 4:46 PM, Vincent Vanlaer wrote: On 4/02/2025 01:42, Jerry D wrote: On 2/3/25 2:14 PM, Vincent Vanlaer wrote: Hi all, Gentle ping for the patch below: https://gcc.gnu.org/pipermail/ fortran/2024-December/061467.html Best wishes, Vincent On 30

Re: [PING, PATCH] fortran: fix -MT/-MQ adding additional target [PR47485]

On 2/3/25 4:46 PM, Vincent Vanlaer wrote: On 4/02/2025 01:42, Jerry D wrote: On 2/3/25 2:14 PM, Vincent Vanlaer wrote: Hi all, Gentle ping for the patch below: https://gcc.gnu.org/pipermail/ fortran/2024-December/061467.html Best wishes, Vincent On 30/12/2024 00:19, Vincent Vanlaer

Re: [PING, PATCH] fortran: fix -MT/-MQ adding additional target [PR47485]

On 2/3/25 2:14 PM, Vincent Vanlaer wrote: Hi all, Gentle ping for the patch below: https://gcc.gnu.org/pipermail/ fortran/2024-December/061467.html Best wishes, Vincent On 30/12/2024 00:19, Vincent Vanlaer wrote: The -MT and -MQ options should replace the default target in the generated dep

Re: [patch, fortran] Add modular exponentiation for unsigned

On 2/3/25 11:55 AM, Thomas Koenig wrote: Hello world, with the following patch to the failing test case diff --git a/gcc/testsuite/gfortran.dg/unsigned_15.f90 b/gcc/testsuite/ gfortran.dg/unsigned_15.f90 index da4ccd2dc17..80a7a54e380 100644 --- a/gcc/testsuite/gfortran.dg/unsigned_15.f90 +++

Re: [PATCH] Fortran: different character lengths in array constructor [PR93289]

On 2/3/25 2:49 AM, Richard Sandiford wrote: Steve Kargl writes: On Sat, Feb 01, 2025 at 09:49:17PM +0100, Harald Anlauf wrote: Am 01.02.25 um 21:03 schrieb Steve Kargl: On Sat, Feb 01, 2025 at 07:25:51PM +0100, Harald Anlauf wrote: the attached patch downgrades different constant character

Re: [PATCH] Fortran: different character lengths in array constructor [PR93289]

On 2/1/25 10:25 AM, Harald Anlauf wrote: Dear all, the attached patch downgrades different constant character lengths in an array constructor from a GNU to a legacy extension, so that users get a warning with -std=gnu.  We continue to generate an error when standard conformance is requested. Re

Re: [patch, libfortran] PR114618 Version 2 Format produces incorrect output when contains 1x, ok when uses " "

On 1/31/25 11:30 AM, Harald Anlauf wrote: Hi Jerry, Am 30.01.25 um 21:50 schrieb Jerry D: On 1/29/25 10:30 AM, Jerry D wrote: Follow-up: On 1/28/25 1:33 PM, Harald Anlauf wrote: Jerry, while I haven't read your actual patch yet, I think the testcase is slightly incorrect. In fact,

Re: [PATCH] Fortran: host association issue with symbol in COMMON block [PR108454]

On 1/30/25 1:44 PM, Harald Anlauf wrote: Dear all, analyzing the the PR (by Gerhard) turned out to two slightly related issues.  The first one, where a variable in a COMMON block is falsely resolved to a derived type declared in the host, leads to a false freeing of the symbol, resulting in memo

Re: [patch, libfortran] PR114618 Version 2 Format produces incorrect output when contains 1x, ok when uses " "

On 1/29/25 10:30 AM, Jerry D wrote: Follow-up: On 1/28/25 1:33 PM, Harald Anlauf wrote: Jerry, while I haven't read your actual patch yet, I think the testcase is slightly incorrect. In fact, Intel, NAG, Nvidia and AMD flang disagree with it. --- snip --- The following adjustment t

Re: [PATCH] Fortran: fix passing of component ref to assumed-rank dummy [PR118683]

On 1/28/25 12:49 PM, Harald Anlauf wrote: Dear all, the attached simple and obvious patch fixes an issue found when running a UBSAN instrumented compiler on a recent testcase, see PR.  Also verified when running f951 under gdb on that testcase. I intend to commit within the next 24 hours unless

Re: [patch, libfortran] PR114618 Format produces incorrect output when contains 1x, ok when uses " "

On 1/28/25 1:33 PM, Harald Anlauf wrote: Jerry, while I haven't read your actual patch yet, I think the testcase is slightly incorrect. In fact, Intel, NAG, Nvidia and AMD flang disagree with it. I also installed flang and noticed this. I also received a auto patch test on ARM that causes me

[patch, libfortran] PR114618 Format produces incorrect output when contains 1x, ok when uses " "

Hello all, The attached patch is part 1 of my effort to fix these X and T edit descriptor issues. This one cleans up some really ugly output. Before the patch with the test case provided by the reporter: PI.^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@^@ 3.1415926535897931 REAL(PI)

Re: [PATCH] Fortran: fix bogus diagnostics on renamed interface import [PR110993]

On 1/26/25 2:07 PM, Harald Anlauf wrote: Dear all, in the checking of imported interfaces we need to use the local names of procedures that are renamed-on-use, as the original name becomes inaccessible.  Similarly, we should not compare interfaces of non-bind(C) procedures against bind(C) interf

Re: [PATCH] Fortran: fix issues with variables in BLOCK DATA [PR58857]

On 1/25/25 11:12 AM, Harald Anlauf wrote: Dear all, the attached patch fixes bogus errors with CLASS variables in BLOCK DATA that showed up because some compiler-generated components were not declared as artificial. Furthermore, a warning can be emitted for variables declared but not in a COMMO

Re: [patch. libgfortran] PR118571 UTF-8 output and the A edit descriptor

On 1/24/25 12:25 AM, Andre Vehreschild wrote: Hi Jerry, the patch looks good to me. One small nit: in write.c after the period of the first sentence should be two space, when I am not mistaken. Thanks for the patch, Andre Thanks for review. Pushed as: commit r15-7181-g4daf088123b

[patch. libgfortran] PR118571 UTF-8 output and the A edit descriptor

Hello all, The attached patch is straight forward. I spent more time on getting the test case ready. Thanks Steve for finding this and narrowing down where the problem was. Regression tested on x86_64-linux-gnu. OK for trunk? What about a backport to 14? Regards, Jerry Author: Jerry DeLis

Re: PING **(6./7.): [patch, Fortran] -fc-prototypes fixes.

On 1/15/25 1:13 PM, Thomas Koenig wrote: Am 09.01.25 um 14:36 schrieb Thomas Koenig: Am 09.01.25 um 14:34 schrieb Thomas Koenig: This patch fixes and reorganizes dumping C prototypes. And here is the "five seconds later, I realized I had forgotten to attach the patch" e-mail... ... with the

Re: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)

Committed as: commit 20b8500cfa522ebe0fcf756d5b32816da7f904dd (HEAD -> master, origin/master, origin/HEAD) Author: Anuj Mohite Date: Mon Jan 13 16:28:57 2025 -0800 Fortran: Add LOCALITY support for DO_CONCURRENT This patch provided by Anuj Mohite as part of the GSoC project

Re: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)

e current code is fine. * * * On 1/7/25 12:06 PM, Jerry D wrote: cannot understand why moving the forall_iterator from the sub- structure 'concur' back to where it was at the 'ext' sub-structure of typedef struct gfc_code. 'ext' is a union. I suspected there is an

Re: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)

On 1/7/25 12:06 PM, Jerry D wrote: On 9/25/24 3:18 AM, Andre Vehreschild wrote: Hi all, I finally managed to apply the fixed patch. It still had some stray line break so check_GNU_style.py wouldn't succeed. But with that fixed I agree to have only some nonsense bickering of the script

Re: [Patch, fortran] PR108434 - [12/13/14/15 Regression] ICE in class_allocatable, at fortran/expr.cc:5000

On 1/10/25 9:19 AM, Paul Richard Thomas wrote: Hi Harald, hi all, As of today, Gerhard Steinmetz has no fewer than 33 regressions to his name out of a total of 54 for fortran and libgfortran. It's time that some of these bugs are swatted, I think :-) As well as this PR, 106946 seems to have

Re: [Ping, Fortran, Patch, PR114612, v1] Fix missing deep-copy for allocatable components of derived types having cycles.

On 1/6/25 2:08 AM, Andre Vehreschild wrote: Hi all, attached patch has been rebased to latest trunk. Just pinging! Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? - Andre On Fri, 13 Dec 2024 12:10:58 +0100 Andre Vehreschild wrote: Hi all, attached patch fixes deep-copying (or r

Re: [-Ping-, Fortran, Patch, PR116669, v3] Fix ICE in deallocation of derived types having cyclic dependencies

On 1/6/25 6:21 AM, Andre Vehreschild wrote: Hi all, during looking for something completely different, I figured, that gcc does not use std::set internally, but its implementation of hash_set. I therefore adapted the patch to use it. Nothing more changed. Still regtests ok on x86_64-pc-linux-gn

Re: [Ping, Fortran, Patch, PR116669, v1] Fix ICE in deallocation of derived types having cyclic dependencies

On 1/6/25 2:06 AM, Andre Vehreschild wrote: Hi all, pinging attached rebased patch. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline? - Andre On Thu, 12 Dec 2024 14:50:13 +0100 Andre Vehreschild wrote: Hi all, attached patch improves analysis of cycles in derived types, i.e. type

Re: [PATCH] Fortran: Added support for locality specs in DO CONCURRENT (Fortran 2018/23)

On 9/23/24 1:00 AM, Andre Vehreschild wrote: Hi Anuj, please check the code style of your patch using: contrib/check_GNU_style.py It reports several errors with line length and formatting. I am going to work with Tobias to move this along. I have the style things fixed. I am going to work

Re: [PATCH] Fortran: Cray pointer comparison wrongly optimized away [PR106692]

On 1/2/25 12:04 PM, Harald Anlauf wrote: Dear all, this patch addresses overeager optimization of Cray pointers when used in comparisons. Cray pointers are non-standard, and odd in a sense that they were introduced before modern Fortran pointers. Comparisons with e.g. a "NULL" pointer are actua

  1   2   3   >