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.

Re: Execution time for gfortran regression testing

On 6/3/25 3:02 AM, Mikael Morin wrote: Le 30/05/2025 à 22:28, Harald Anlauf a écrit : When I'm working on a particular area of gfortran, I tend to use RUNTESTFLAGS to limit what is tested.  For example, I just fixed SPREAD() for scalar source and ncopies < 1. I do % cd obj % gmake % cd gcc % gm

Build appears to be broken.

I am getting this tonight. Jerry In file included from /home/jerry/dev/usr/include/c++/16.0.0/x86_64-pc-linux-gnu/bits/gthr-default.h:35, from /home/jerry/dev/usr/include/c++/16.0.0/x86_64-pc-linux-gnu/bits/gthr.h:157, from /home/jerry/dev/usr/include/c++/16.

[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: possible gfortran bug

On 5/21/25 6:46 PM, George Rinker wrote: When I run gfortran (13.1.0 installed 2023/08/20.17:50) from cmd.exe on a source.f that generates a compiler error, I get a message listing the first error line and column in normal text, then subsequent messages in a different color, and then it hangs a

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

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 iso_c_binding, but not the indirect one

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

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

On 5/17/25 10:22 AM, Jerry D wrote: Hello all, --- snip --- PS I managed to clean up the change log and add in Steve: Author: Jerry DeLisle Date: Sat May 17 09:45:14 2025 -0700 Fortran: Fix c_associated argument checks. PR fortran/120049 gcc/fortran/ChangeLog

[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.

Breakage on specifics_1.f90

I am seeing this today. I do not think it is related to my patch. Running /home/jerry/dev/trunk/gcc/testsuite/gfortran.dg/dg.exp ... FAIL: gfortran.dg/specifics_1.f90 -O2 execution test FAIL: gfortran.dg/specifics_1.f90 -O3 -fomit-frame-pointer -funroll-loops -fpeel-loops -ftracer -finline-

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

On 5/6/25 9:51 AM, Steve Kargl wrote: On Mon, May 05, 2025 at 08:30:09PM -0700, Jerry D wrote: 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

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

15 is now at or very near release

I now see this in git: remotes/origin/releases/gcc-15 So we are at or very close to the release. Cheers, Jerry

Re: Fortran 15.0.1 treats "shiftl" as impure

On 4/16/25 6:48 PM, ZAPART CHRISTOPHER ANDREW wrote: Sorry don’t have a bugzilla account yet. For completeness here is a full test code that also calls a pure subroutine from within a “block” located inside a “do concurrent” loop. Regards, Chris gfortran -march=native -g -Ofast -fPIC -fno-fin

Re: Fortran 15.0.1 treats "shiftl" as impure

On 4/16/25 9:58 AM, Jerry D wrote: On 4/15/25 9:44 PM, ZAPART CHRISTOPHER ANDREW wrote: Hello, After a recent upgrade from Fedora 41 to 42 the gfortran got updated from 14 to 15.0.1: [chris@fedora FITSWEBQLSE]$ gfortran --version GNU Fortran (GCC) 15.0.1 20250329 (Red Hat 15.0.1-0) The new

Re: Fortran 15.0.1 treats "shiftl" as impure

On 4/15/25 9:44 PM, ZAPART CHRISTOPHER ANDREW wrote: Hello, After a recent upgrade from Fedora 41 to 42 the gfortran got updated from 14 to 15.0.1: [chris@fedora FITSWEBQLSE]$ gfortran --version GNU Fortran (GCC) 15.0.1 20250329 (Red Hat 15.0.1-0) The new version 15.0.1 seems to treat "shiftl

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

Re: [Fortran, Patch, Team, 3/5] Update get_team, team_number and image_status to F2018 [PR88154, PR88960, PR97210, PR103001]

On 4/10/25 5:59 AM, Andre Vehreschild wrote: Hi all, attached patch reworks GET_TEAM(), TEAM_NUMBER() and IMAGE_STATUS() to adhere to the Fortran 2018 as much as possible and to play nicely with the previous patch of the TEAM statements. Regtests ok on x86_64-pc-linux-gnu / F41. Ok for mainline

Re: [patch, libgfortran] PR119502

On 4/13/25 1:27 AM, Thomas Koenig wrote: Hi Jerry, 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 OK. Thanks for the patch! Best regards Thomas Pushed as commit ee617380

Re: F2008 and F2018 statuses on gfortran wiki

On 4/13/25 12:48 AM, Paul Richard Thomas wrote: Hi All, Recently a lot of work has been done on the "partial" or "no"s in the F2008 and F2018 implementation statuses. Please send me updates and I will do the editing in time for the gcc-15 release. Thanks Paul Andre has a good chunk of th

[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: Bug 119349 [15 Regression] polymorphic array dummy argument with function result actual argument in elemental function

On 3/17/25 10:40 PM, Damian Rouson wrote: With gfortran 12.4.0, 13.3.0, and 14.2.0, the program below prints "T". With gfortran 15, the program crashes with an error message that indicates that a pointer is being freed that was not allocated. % cat all.f90 implicit none type string_t

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

Fwd: GCC GSoC 2025: Call for project ideas and mentors

Chenlu, You appear to be quite knowledgeable. It would be great to have you do this. I am forwarding additional information. Our most knowledgeable person in the DO_CONCURRENT area is probably Tobias (copied on this email). I certainly cannot speak for Tobias. I do think the gfortran team cou

Re: [GSoC][Fortran – DO CONCURRENT] Interest in 2025 GSoC – Fortran DO CONCURRENT Auto-Parallelization

On 3/10/25 4:29 AM, Damian Rouson wrote: If this moves forward, I’d like to offer example code to target in Fiats (https://go.lbl.gov/fiats ).  I presented automatic parallelization results produced by compiling with LLVM flang- new for inference at the PAW-ATM worksho

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/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: [PATCH] Fortran: fix check for non-optional arrays passed to elemental

On 2/28/25 1:13 AM, Peter Hill wrote: No problem, created PR119054 with a reproducer and some details. Cheers, Peter Peter, thanks very much for the patch. It is fixed on gcc-15 and will do back ports in a few days. Best Regards Jerry PS If you are interested you can join our MatterMost

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] 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

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

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: DLL with gfortran open statement crashes Excel

On 2/25/25 11:41 AM, Jürgen Bausa wrote: In the meantime I found out what is causing the problem. There seems to be a bug in the connection from gfortran to UCRT (Microsofts universal C runtime, that ships with Windows 10 and 11). If I switch to a compiler that uses MSVCRT (Microsoft Visual C run

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, Fortran] Fix PR 24878, checking actual arguments against global symbols

On 2/9/25 12:54 AM, Thomas Koenig wrote: Am 08.02.25 um 22:46 schrieb Harald Anlauf: looks good, just two minor comments: +  actual_name = act_sym->name ? act_sym->name : act_sym->name; Why not just +  actual_name = act_sym->name; ? That was a leftover from a previous commit. +

Re: RFC: Bugzilla keyword "interp" where it is not clear if a program is standard-conforming or not

On 2/9/25 1:07 AM, Thomas Koenig wrote: Hello world, looking at a few Fortran bug reports, I found some cases where it was not clear if the program in question was standard-conforming or not.  I would propose to add a keyword for that, tentatively called "interp". Comments? Suggestions for a di

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: How to do a seek (nonadvancing read) on a stream file?

On 2/3/25 12:10 PM, Andi McClure wrote: (This is an attempt to reply to a Mon Feb 3 19:09:38 GMT 2025 message by Steve Kargl.) > I believe that you are misreading C1223.  The file is > opened with form='unformatted'. Hm, okay. I guess it comes down to whether you "diagram" the sentence in t

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 12:49 PM, 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 lengths in an array constructor from a GNU to a legacy extension, so that users get a war

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, libfortran] PR114618 Format produces incorrect output when contains 1x, ok when uses " "

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. Adding the following lines before the check with the STOP statement: write(*,'(a)') ou

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

Re: [Linaro-TCWG-CI] gcc patch #105542: 12 regressions on arm

On 1/28/25 10:40 AM, Andrew Pinski wrote: On Tue, Jan 28, 2025 at 10:32 AM Jerry D wrote: Before I go clicking on links, is this legit? I presume patches are getting checked before being pushed. Yes this is a legit email from the Linaro automation. And yes patches are being tested before

Fwd: [Linaro-TCWG-CI] gcc patch #105542: 12 regressions on arm

://patchwork.sourceware.org/patch/105542 | Author: Jerry D | Date: Mon Jan 27 19:41:04 2025 -0800 | | [patch, libfortran] PR114618 Format produces incorrect output when contains 1x, ok when uses " " | | Hello all, | | The attached patch is part 1 of my eff

[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

Using MatterMost

I am plugging for the gfortran MatterMost website. https://gfortran-mm.osuosl.org/main/channels/insights At that location one can go to the top of the page and find all the hints one needs to use git including commits and correcting logs. I use it all the time to fix-up the git log or change a

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

  1   2   3   4   >