[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

Re: [Fortran, Patch, PR117643] Implement F_C_STRING()

n. commit efc0981077a70c4de4596f682c4aeade07ec2f17 (HEAD -> master, origin/master, origin/HEAD) Author: Steven G. Kargl Date: Sun Dec 29 14:19:18 2024 -0800 Fortran: Implement f_c_string function. On Sun, 29 Dec 2024 at 23:10, Jerry D <mailto:jvdelis...@gmail.com>> wrote: Attached is the revis

Re: [Fortran, Patch, PR117643] Implement F_C_STRING()

Attached is the revised patch incorporating handling of optional arguments of a calling procedure and simplified checking for C interoperability. See the PR for much discussion. Regression tested on x86_64_linux_gnu. Two test cases. OK for trunk? Author: Steven G. Kargl Date: Sun Dec 29

Re: [PATCH] Fortran: fix NULL without MOLD argument to scalar DT pointer dummy [PR118179]

On 12/23/24 9:19 AM, Harald Anlauf wrote: Dear all, while preparing the testcase null_actual_7.f90 for commit r15-6408, I overlooked a corner case, leading to a regression (PR118179). The obvious solution is to extend the suppression of copying back the pointer also for NULL actual arguments to

Re: [2nd PING, Fortran, Patch, PR107635, Part 1] Rework handling of allocatable components in derived type coarrays.

On 12/20/24 9:09 AM, Andre Vehreschild wrote: Thank you very much Jerry. The delta between the two patches is really minor. In resolve.c I have removed some attr.pointer setting and in caf/single.c the handling for those as well as treating non-descriptor arrays differently. Most changes in

Re: [PATCH] Fortran: potential aliasing of complex pointer inquiry references [PR118120]

On 12/19/24 1:34 PM, Harald Anlauf wrote: Dear all, the check for potential aliasing of lhs and rhs currently shortcuts if the types differ. This is a problem if one is of type complex and the other is of type real (and of the same kind parameter value), as this ignores that F2008 inquiry refer

Re: [Fortran, Patch, PR57598] Fix coarray STOP

On 12/19/24 4:13 AM, Andre Vehreschild wrote: Hi all, attached patch fixes a rather old open issue, that I stumbled upon while trying to figure, why a test failed on the command line but not in the testsuite. The implementation of the STOP command in caf_single did not hand the errorcode over to

Re: [PING!, Fortran, Patch, PR107635, Part 1] Rework handling of allocatable components in derived type coarrays.

Andre, have you tested this with the tests in OpenCoarrays suite? I ask since this touches coarray things. Jerry On 12/16/24 1:58 AM, Andre Vehreschild wrote: PING! On Fri, 6 Dec 2024 19:10:08 +0100 Andre Vehreschild wrote: Hi all, I had to dive deeply into the issue with handling allocat

Re: [Fortran, Patch, PR117643] Implement F_C_STRING()

On 12/18/24 4:11 AM, Harald Anlauf wrote: Hi Steve, thanks for the draft patch. I haven't looked close enough, but you may have to add support for 'asis' being an optional dummy variable.  The following example crashes here with a segfault: program foo    use iso_c_binding, only : c_null_char

Re: [patch, libgfortran] Bug 117819 - Formatted READ with BZ in format fails

Pushed r15-6090-gcf406a6c Thanks for the review! Jerry On 12/10/24 12:15 AM, Andre Vehreschild wrote: Hi Jerry, patch looks good. Ok for mainline and backport after grace period. Thanks for the patch, Andre On Mon, 9 Dec 2024 20:31:08 -0800 Jerry D wrote: Hi all, The attached

[patch, libgfortran] Bug 117819 - Formatted READ with BZ in format fails

Hi all, The attached patch fixes this bug by checking for the case of a short READ that should be padded with blanks and if the BZ mode is enabled, those blanks should be treated as trailing zero's. New test case courtesy Malcom Cohen. Regression tested on X86_64_linux_gnu. OK for trunk and

[patch, libgfortran] PR117820

Hi all, Attached patch adds a test for zero that is needed for write_boz to work correctly. Almost obvious. Regression tested on x86_64. Ok for trunk? Jerry Author: Jerry DeLisle Date: Mon Dec 2 19:45:26 2024 -0800 Fortran: Fix B64.0 formatted write output. PR fortran/1

Re: [PATCH] Fortran: fix crash with bounds check writing array section [PR117791]

On 11/27/24 12:31 PM, Harald Anlauf wrote: Dear all, the attached patch fixes a wrong-code issue with bounds-checking enabled when doing I/O of an array section and an index is either an expression or a function result. The problem does not occur without bounds-checking. When looking at the or

Re: [Patch, fortran] PR117763 [15.0 regression] segmentation fault through allocatable char arrays (?)

On 11/25/24 3:09 AM, Paul Richard Thomas wrote: Hi All, The breakage was caused by the patch for PR109345. As it happens, this part of the patch was not required to fix the PR and looked to be a considerable simplification of the condition. Although correct that all is left are class dummies,

[patch, fortran] PR117765 Impure function within a BLOCK construct within a DO CONCURRENT

I would like to commit the attached patch for Steve. Regression tested on x86-64-linux-gnu. OK for trunk? Author: Steve Kargl Date: Sun Nov 24 18:26:03 2024 -0800 Fortran: Check IMPURE in BLOCK inside DO CONCURRENT. PR fortran/117765 gcc/fortran/ChangeLog:

Re: [wwwdocs] Fortran changes, add description regarding commas in formats

On 11/23/24 10:59 AM, Harald Anlauf wrote: Am 23.11.24 um 19:35 schrieb Jerry D: Suggested docs change regarding fix to PR88052. See attached diff file. OK to push? Regards, Jerry Jerry, for clarification: isn't it the language standard option used when compiling the main th

[wwwdocs] Fortran changes, add description regarding commas in formats

Suggested docs change regarding fix to PR88052. See attached diff file. OK to push? Regards, Jerry diff --git a/htdocs/gcc-15/changes.html b/htdocs/gcc-15/changes.html index 46dad391..2dc222e3 100644 --- a/htdocs/gcc-15/changes.html +++ b/htdocs/gcc-15/changes.html @@ -143,6 +143,10 @@ a work-

Re: [libgfortran, patch] PR88052 Format contravening constraint C1002 permitted

On 11/23/24 12:40 AM, Thomas Koenig wrote: Hi Jerry, I had originally created this patch in 2018 and we did not get back to it. This results in more restrictive runtime behavior. I will go through the front-end code with another patch to catch this at compile time. Changelog and new test ca

[libgfortran, patch] PR88052 Format contravening constraint C1002 permitted

Hi all, I had originally created this patch in 2018 and we did not get back to it. This results in more restrictive runtime behavior. I will go through the front-end code with another patch to catch this at compile time. Changelog and new test case. See attached patch. OK for trunk Author:

Re: [PATCH] Fortran: fix checking of protected variables in submodules [PR83135]

On 11/20/24 1:08 PM, Harald Anlauf wrote: Dear all, the attached, actually rather straightforward patch fixes the checking of protected variables in submodules. When a variable was use-associated in an ancestor module, we failed to properly diagnose this. Regtested on x86_64-pc-linux-gnu. OK

Re: [PATCH] Fortran: add bounds-checking for ALLOCATE of CHARACTER with type-spec [PR53357]

On 11/17/24 2:21 PM, Harald Anlauf wrote: Dear all, the attached patch fixes a rejects-valid / rejects-potentially-valid code issue for ALLOCATE of CHARACTER with type-spec, and add character length checking with -fcheck=bounds for the case at hand. It also improves checking of character funct

  1   2   3   >