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

Re: [PATCH] Fortran: fix passing of NULL() actual argument to character dummy [PR104819]

On 11/13/24 2:26 PM, Harald Anlauf wrote: Dear all, the attached patch is the third part of a series to fix the handling of NULL() passed to pointer dummy arguments. This one addresses character dummy arguments (scalar, assumed-shape, assumed-rank) for various uses in the caller. The patch is

Re: [Patch, fortran] PR105054 - [12/13/14/15 Regression] Using one kind of pointer functions causes the compiler to hang since r11-3029-g2b0df0a6ac79b34f

On 11/12/24 5:23 AM, Paul Richard Thomas wrote: Hi All, The ChangeLog and comment make it clear what this patch does and why. OK for mainline and backporting after a week or so? Regards Paul In the test case: A comment s/resul/result/ Also the test conditional if (trim (array_strings2(i

Re: [patch, Fortran] Introduce unsigned versions of MASKL and MASKR

On 11/2/24 8:44 AM, Thomas Koenig wrote: Ping **(5./7.) ? MASKR and MASKL are obvious candidates for unsigned, too; in the previous version of the doc patch, I had promised that these would take unsigned arguments in the future. What I had in mind was they could take an unsigned argument and re

Re: [Patch, fortran] PR115700 - comment 5: uninitialized string length in ASSOCIATE

On 10/30/24 9:58 AM, Steve Kargl wrote: On Wed, Oct 30, 2024 at 04:41:40PM +, Paul Richard Thomas wrote: This wrinkle to PR115700 came about because the associate-name string length was not being initialized, when an array selector had a substring reference with non-constant start or end. Th

Re: [PATCH] Fortran: fix several front-end memleaks

On 10/29/24 2:00 PM, Harald Anlauf wrote: Dear all, while looking at the recent testcase gfortran.dg/pr115070.f90 with f951 running under valgrind, I noticed minor front-end memleaks of gfc_expr's that are probably fallout from a code refactoring, which are fixed by the attached. Regtested on x

Re: [patch, fortran] PR28032 gfortran.dg tests use dg-options with -On even though it is already torture tests

On 10/20/24 1:16 PM, Harald Anlauf wrote: Hi Jerry! Am 20.10.24 um 21:53 schrieb Jerry D: On 10/20/24 12:23 PM, Harald Anlauf wrote: Hi Jerry! Am 20.10.24 um 18:56 schrieb Jerry D: The attached diff file begins some test suite cleanup. The patch removes extra spaces between dg-do and the

Re: [patch, fortran] PR28032 gfortran.dg tests use dg-options with -On even though it is already torture tests

On 10/20/24 12:23 PM, Harald Anlauf wrote: Hi Jerry! Am 20.10.24 um 18:56 schrieb Jerry D: The attached diff file begins some test suite cleanup. The patch removes extra spaces between dg-do and the run directive, I only have gone through gfortran.dg and not its sub-directories

[patch, fortran] PR28032 gfortran.dg tests use dg-options with -On even though it is already torture tests

The attached diff file begins some test suite cleanup. The patch removes extra spaces between dg-do and the run directive, I only have gone through gfortran.dg and not its sub-directories. Interestingly, one of the tests fails when this space is removed. I fixed that by adding in a -O in the d

Re: Fortran: Add range-based diagnostic

On 10/18/24 3:35 PM, Tobias Burnus wrote: This patch was motivated by David's talk at Cauldron – and by getting rather bad locations for some diagnostics, where I wanted to use the column number to ensure that all items are found. The main problem was a missing gobbling of spaces, but still rang

Re: [Patch] Fortran: Fix translatability of diagnostic strings

On 10/18/24 3:20 PM, Tobias Burnus wrote: *Patch ping* OK for trunk. Jerry Tobias Burnus wrote: I noticed that several diagnostic strings were not tagged as translatable. I fixed them by adding _ or G_ as prefix ( →gcc/ABOUT-GCC-NLS) and moved a single-use string to the message to make it

Re: [patch, fortran] Fix ICE with use of INT32 et al from ISO_FORTRAN_ENV

On 10/17/24 12:52 PM, Thomas Koenig wrote: Hello world, The attached patch fixes an ICE when an UNSIGNED-specific constant is used from ISO_FORTRAN_ENV.  The error message is not particularly great, it is Error: Unsigned: The symbol 'uint32', referenced at (1), is not in the selected standard

PR105361 Fix of testcase

Pushed as stated in the PR to cleanup the test case. commit 6604a05fa27bc21c3409e767552daca3fcf43964 (HEAD -> master, origin/master, origin/HEAD) Author: Jerry DeLisle Date: Thu Oct 17 13:39:09 2024 -0700 Fortran: Add tolerance to real value comparisons. gcc/testsuite/ChangeLog:

Re: [patch, Fortran] Unsigned constants for ISO_FORTRAN_ENV and ISO_C_BINDING

On 10/12/24 9:04 AM, Thomas Koenig wrote: Hello world, the attached patch implements the constants for UNSIGNED for ISO_FORTRAN_ENV and ISO_C_BINDING.  With this, the implementation of UNSIGNED for gfortran should be complete, modulo bugs, of course. OK for trunk? Looks good to go Thomas. Th

Re: [PATCH] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

On 9/24/24 5:46 PM, Hans-Peter Nilsson wrote: Thanks for the review! Date: Tue, 24 Sep 2024 17:10:27 -0700 Cc: Jerry D From: Jerry D On 9/23/24 11:21 PM, Hans-Peter Nilsson wrote: I hope the inclusion of gfortran-dg.exp in fortran-torture.exp is not controversial, but there's no fo

Re: [PATCH] gfortran testsuite: Remove unit-files in files having open-statements, PR116701

On 9/23/24 11:21 PM, Hans-Peter Nilsson wrote: Here's a general approach to handle PR116701. I considered adding manual deletions as quoted below and mentioned in the PR, but seeing the handling of "integer 8" in fortran-torture-execute I decided to follow that example: better scan the source fo

Re: [patch, fortran] Implement IANY, IALL and IPARITY for unsigned

On 9/18/24 1:20 PM, Thomas Koenig wrote: OK for trunk? OK and thanks. Jerry --- snip ---

Re: [PATCH] Fortran: fix ICE in gfc_create_module_variable [PR100273]

On 9/5/24 12:42 PM, Harald Anlauf wrote: Dear all, the attached simple patch fixes a corner case related to pr84868, which was tracked separately. While Paul's patch for pr84868 added the framework for treating len_trim in the specification part of a character function, it missed the possibilit

Re: [Ping x2 , Fortran, Patch, PR77518, (coarray), v4] Fix ICE in sizeof(coarray)

On 8/20/24 5:35 AM, Andre Vehreschild wrote: Hi all, pinging this patch. Regtests ok on x86_64-pc-linux-gnu / Fedora 39. Ok for mainline? Regards, Andre Your approach looks reasonable so I think OK to push. Thanks, Jerry

Re: [Ping x 3, Fortran, Patch, coarray, PR84246, v2] Fix for [Coarray] ICE in conv_caf_send, at fortran/trans-intrinsic.c:1950

On 8/19/24 4:43 AM, Andre Vehreschild wrote: Hi all, another ping on this patch. Regtests ok on x86_64-pc-linux-gnu on updated master. Ok for mainline? Regards, Andre Looks OK to go ahead Andre. Thanks, Jerry On Fri, 9 Aug 2024 16:29:08 +0200 Andre Vehreschild wrote: Ping! O

  1   2   >