[Bug fortran/103508] [PDT] ICE in gfc_find_symtree, at fortran/symbol.c:2979

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103508 --- Comment #9 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #8) > (In reply to kargls from comment #7) > > This fixes the issue. > > > However, the original test case still segfaults. Suggests needing something > similar to t

[Bug fortran/103508] [PDT] ICE in gfc_find_symtree, at fortran/symbol.c:2979

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103508 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/122002] [16 regression] gfortran.dg/pdt_13.f03 etc. FAIL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122002 --- Comment #11 from Jerry DeLisle --- $ gfc -g pdt_48.f03 jerry@quasar:~/dev/test/tryit$ gdb ./a.out GNU gdb (Fedora Linux) 16.3-1.fc42 Copyright (C) 2024 Free Software Foundation, Inc. License GPLv3+: GNU GPL version 3 or later

[Bug fortran/122002] [16 regression] gfortran.dg/pdt_13.f03 etc. FAIL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122002 Jerry DeLisle changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED

[Bug fortran/122002] gfortran.dg/pdt_13.f03 etc. FAIL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122002 --- Comment #4 from Jerry DeLisle --- Now I wonder why I dont see it here.

[Bug fortran/122002] gfortran.dg/pdt_13.f03 etc. FAIL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=122002 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/121939] [15/16 Regression] ICE in gfc_conv_string_parameter, at fortran/trans-expr.cc:11450

|UNCONFIRMED |NEW Ever confirmed|0 |1 CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- Confirmed.

[Bug fortran/96255] [F2018] Implement optional type spec for index in DO CONCURRENT

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255 --- Comment #16 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #15) > > Notice that outside the loop the index variables are not defined but we do > not give an diagnostic about not being implicitly declared. > > Seeking clarif

[Bug fortran/96255] [F2018] Implement optional type spec for index in DO CONCURRENT

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255 --- Comment #15 from Jerry DeLisle --- Steve, In your second version of the patch which I have applie and have been testing, the last hunk states: @@ -12359,6 +12365,12 @@ gfc_resolve_forall (gfc_code *code, gfc_namespace *ns, int forall_save)

[Bug fortran/78219] [F08] specifying the kind of a FORALL index in the header

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78219 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/36725] g0 edit descriptor: Missing compile-time checking for invalid g0.d

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=36725 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org

[Bug libfortran/90374] Fortran 2018: Support d0.d, e0.d, es0.d, en0.d, g0.d and ew.d e0 edit descriptors for output

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/96255] [F2018] Implement optional type spec for index in DO CONCURRENT

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255 --- Comment #14 from Jerry DeLisle --- Created attachment 62308 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62308&action=edit Preliminary patch cleaned up for current trunk Attached is Steves patch from comments within diffed to current

[Bug fortran/96255] [F2018] Implement optional type spec for index in DO CONCURRENT

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255 --- Comment #13 from Jerry DeLisle --- (In reply to kargls from comment #11) > (In reply to Scott Boyce from comment #10) > > Just wanted to see if there was any change on this. I just was about to post > > the same issue (and found this one) for

[Bug fortran/121796] DO CONCURRENT with typespec does not compile

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121796 Jerry DeLisle changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

[Bug fortran/96255] [F2018] Implement optional type spec for index in DO CONCURRENT

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96255 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/121796] DO CONCURRENT with typespec does not compile

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121796 --- Comment #2 from Jerry DeLisle --- In match_forall_iterator, which is used when we are matching and parsing a DO CONCURRENT, we are not even trying to match a typespec. I am going to review the standard before I proceed further. I do see wher

[Bug fortran/121796] DO CONCURRENT with typespec does not compile

|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from Jerry DeLisle --- $ gfc pr121796.f90 pr121796.f90:5:15: 5 | do concurrent(integer :: i=1:size(array

[Bug fortran/121796] New: DO CONCURRENT with typespec does not compile

: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jvdelisle at gcc dot gnu.org Target Milestone: --- Example from Damian. implicit none integer i, array(2) do concurrent(integer :: i=1:size(array)) array(i) = i end do end

[Bug fortran/121759] Windows/MinGW: formatted reads lose decimal digits after binary stream read

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121759 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/114611] H edit descriptor should flag as error with -std-f95 (or higher)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114611 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED Status|NEW

[Bug fortran/121697] ASAN reports heap-use-after-free at fortran/simplify.cc:133 when compiling testsuite/gfortran.dg/pdt_39.f03

||jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jerry DeLisle --- For what it's worth. $ gfc -g pdt_39.f03 $ $ valgrind --leak-check=full --show-leak-kinds=all ./

[Bug fortran/114611] H edit descriptor should flag as error with -std-f95 (or higher)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114611 --- Comment #5 from Jerry DeLisle --- Created attachment 62206 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=62206&action=edit Proposed patch to adjust warnings and errors The attached patch has the following effects: $ gfc pr114611.f90

[Bug fortran/114611] H edit descriptor should flag as error with -std-f95 (or higher)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114611 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org

[Bug fortran/120812] [regression] buffer(80:80) = C_NEW_LINE not working with gfortran 15.1 under Mac

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120812 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/121628] Use-after-free in compiler-generated assignment operators

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121628 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org Ever

[Bug libfortran/93727] Fortran 2018: EX edit descriptor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727 --- Comment #9 from Jerry DeLisle --- Little by little. ! pr93727 EX Format Specifiers program main implicit none character s1 real(4) :: r4 real(8) :: r8 real(10) :: r10 !real(16) :: r16 r4 = -huge(34.0_4) r8 = -huge( 1.0_8/

[Bug fortran/121616] Assignment to an unlimited polymorphic variable causes a segmentation fault at runtime

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121616 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/121564] Segmentation fault when function returns pointer to a derived type with pointer components

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121564 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug fortran/121564] Segmentation fault when function returns pointer to a derived type with pointer components

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121564 Jerry DeLisle changed: What|Removed |Added Status|WAITING |NEW --- Comment #4 from Jerry DeLisle

[Bug fortran/121561] New: "A" field descriptor does not work with multi-byte characters

ty: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: urbanjost at comcast dot net CC: jvdelisle at gcc dot gnu.org Target Milestone: --- Ever confirmed: 1 Last reconfirmed: 2025-08-15 CC: jvdeli

[Bug fortran/121564] Segmentation fault when function returns pointer to a derived type with pointer components

|WAITING CC||jvdelisle at gcc dot gnu.org Last reconfirmed||2025-08-15 --- Comment #1 from Jerry DeLisle --- Works for me on latest master. $ gfc seggy.f90 jerry@quasar:~/dev/test/tryit$ ./a.out MRE: Calling

[Bug libfortran/93727] Fortran 2018: EX edit descriptor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727 --- Comment #8 from Jerry DeLisle --- I have had to explore this a bit to get to a point of understanding. The following C example shows building the HEX float strings and the incantations needed. For those systems that support the 17 byte float

[Bug fortran/121475] Missed finalization

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121475 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/121480] ICE on assigning to polymorphic component with additional nesting

||2025-08-13 Status|UNCONFIRMED |NEW CC||jvdelisle at gcc dot gnu.org --- Comment #2 from Jerry DeLisle --- Taking a guess it looks like we need to either modify or delete the assert. The flang-new compiles it ok.

[Bug fortran/121513] Lower bound of an assumed rank variable is 0 instead of 1

|NEW CC||jvdelisle at gcc dot gnu.org Last reconfirmed||2025-08-13 --- Comment #1 from Jerry DeLisle --- gfortran gives: $ ./a.out user defined type array: argument array with bounds0 1

[Bug fortran/121537] Missed defined-assignment

|NEW Last reconfirmed||2025-08-13 CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- Likewise, flang-new follows ifort.

[Bug libfortran/121234] Bogus diagnostic on READ of string with semicolon.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121234 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug fortran/121429] [caf_shmem] Test fails without explicit SYNC ALL

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121429 Jerry DeLisle changed: What|Removed |Added Last reconfirmed||2025-08-06 Ever confirmed|0

[Bug fortran/121429] New: [caf_shmem] Test fails without explicit SYNC ALL

: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jvdelisle at gcc dot gnu.org Target Milestone: --- The following test fails without a SYNC ALL before or after the deallocate. Should the deallocate automatically sync the images? program main implicit none

[Bug fortran/121366] When an intrinsic trigonometric function in degrees is used as a pointer target, an internal compiler error occurs

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121366 --- Comment #4 from Jerry DeLisle --- What is different about sind? (obvious question)

[Bug fortran/121366] When an intrinsic trigonometric function in degrees is used as a pointer target, an internal compiler error occurs

||2025-08-02 CC||jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #2 from Jerry DeLisle --- Confirmed: $ gfc function-array.f90 function-array.f90:22:57: 22 |func_array(2)%f => s

[Bug fortran/121360] New: Use of preliminary coarray with locks gives unexpected results

Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jvdelisle at gcc dot gnu.org Target Milestone: --- Using the preliminary coarray implementation from devel/gfortran-test, the following test case gives unexpected results. program

[Bug libfortran/121234] Bogus diagnostic on READ of string with semicolon.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121234 --- Comment #3 from Jerry DeLisle --- 13.10.3.1, paragraph 8 8 If the next effective item is default, ASCII, or ISO 10646 character and • the character sequence does not contain value separators, • the character sequence does not cross a record

[Bug libfortran/121234] Bogus diagnostic on READ of string with semicolon.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121234 --- Comment #2 from Jerry DeLisle --- The original test case is rather clever. With this slightly modified, placing quotes around the 'string' in the buffer. character(80) buffer,a buffer="'33;44'" print *, buffer read(b

[Bug libfortran/121234] Bogus diagnostic on READ of string with semicolon.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121234 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org

[Bug fortran/121043] [16 Regression] Tests of OpenCoarray fail to pass, works on 15.1.1 20250712

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121043 Jerry DeLisle changed: What|Removed |Added Status|NEW |WAITING Depends on|

[Bug fortran/121043] [16 Regression] Tests of OpenCoarray fail to pass, works on 15.1.1 20250712

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121043 --- Comment #11 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #10) > Andre has sent a fixer patch for these. Building now and will test. Does not work, disregard.

[Bug fortran/121043] [16 Regression] Tests of OpenCoarray fail to pass, works on 15.1.1 20250712

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121043 --- Comment #10 from Jerry DeLisle --- Andre has sent a fixer patch for these. Building now and will test.

[Bug fortran/121043] [16 Regression] Tests of OpenCoarray fail to pass, works on 15.1.1 20250712

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121043 --- Comment #9 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #3) > There are a series of patches involved here. > > The first failure occurs at: > > commit 1be1970f97d05a07851cd826132fcf466827ebe5 > Author: Andre Vehreschild

[Bug fortran/121043] [16 Regression] Tests of OpenCoarray fail to pass, works on 15.1.1 20250712

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121043 --- Comment #8 from Jerry DeLisle --- (In reply to Tobias Burnus from comment #7) > (In reply to Jerry DeLisle from comment #2) > > However, I do see the following on gcc-15 pulled this morning. > > Can you check what branch you checked out? Be

[Bug fortran/121060] ICE when argument is associate name created from type-bound operator result

||2025-07-14 Ever confirmed|0 |1 CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- Thankyou Damian for reducing this one. I can confirm it.

[Bug fortran/121043] [16 Regression] Tests of OpenCoarray fail to pass, works on 15.1.1 20250712

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121043 --- Comment #6 from Jerry DeLisle --- I narrowed it down. I modified with some convenient prints: program register3 implicit none integer, parameter :: invalid_rank=-2 integer :: np=invalid_rank,array_size=10 integer,allocatable :: arr

[Bug fortran/121043] [16 Regression] Tests of OpenCoarray fail to pass, works on 15.1.1 20250712

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121043 --- Comment #5 from Jerry DeLisle --- I assume the first failure was fixed by the second patch. There is no log entry for that test. I had to terminate it. I have let it run for over 30 minutes before doing so. The test is being run with two i

[Bug fortran/121043] [16 Regression] Tests of OpenCoarray fail to pass, works on 15.1.1 20250712

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121043 --- Comment #4 from Jerry DeLisle --- The log from the first failure: 23/88 Testing: sync_team 23/88 Test: sync_team Command: "/usr/bin/bash" "/home/jerry/dev/opencoarrays-clean/bin/cafrun" "-np" "8" "/home/jerry/dev/opencoarrays-clean/bin/Open

[Bug fortran/121043] [16 Regression] Tests of OpenCoarray fail to pass, works on 15.1.1 20250712

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121043 Jerry DeLisle changed: What|Removed |Added Last reconfirmed||2025-07-13 Ever confirmed|0

[Bug fortran/121043] [15/16 Regression] Tests of OpenCoarray fail to pass, works on 14.3.1 20250701

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121043 --- Comment #2 from Jerry DeLisle --- While bisecting on gcc-15 branch I can not reproduce the OpenCoarray test failure. However, I do see the following on gcc-15 pulled this morning. Clean build. FAIL: gfortran.dg/goacc/parameter-3.f90 -O (

[Bug fortran/121043] [15/16 Regression] Tests of OpenCoarray fail to pass, works on 14.3.1 20250701

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=121043 Jerry DeLisle changed: What|Removed |Added CC||vehre at gcc dot gnu.org --- Comment #1

[Bug fortran/121043] New: [15/16 Regression] Tests of OpenCoarray fail to pass, works on 14.3.1 20250701

: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jvdelisle at gcc dot gnu.org Target Milestone: --- Starting with a clean build directory, building OpenCoarrays works but the tests fail. In particular, Test #4

[Bug fortran/117077] ICE due to allocatable component in hidden type

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=117077 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/120847] [15/16-Regression, Coarray] ICE after "Component ... already declared at..." when type with coarray comp is defined

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120847 Jerry DeLisle changed: What|Removed |Added Status|WAITING |NEW --- Comment #7 from Jerry DeLisle

[Bug fortran/120847] [15/16-Regression, Coarray] ICE after "Component ... already declared at..." when type with coarray comp is defined

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120847 --- Comment #6 from Jerry DeLisle --- Created attachment 61778 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61778&action=edit Test case I am testing with. This requires no input files and uses the default settings. I will see if I can

[Bug fortran/120847] [15/16-Regression, Coarray] ICE after "Component ... already declared at..." when type with coarray comp is defined

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120847 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/114611] H edit descriptor should flag as error with -std-f95 (or higher)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114611 --- Comment #3 from Jerry DeLisle --- I have not had much time to finish this one. I will try to get to it.

[Bug fortran/88076] Shared Memory implementation for Coarrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076 --- Comment #23 from Jerry DeLisle --- (In reply to Andre Vehreschild from comment #22) --- snip--- > > I can only ask you to do a clean build and maybe also drop the installation > directory. Sometimes build systems find funny things and then t

[Bug fortran/88076] Shared Memory implementation for Coarrays

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88076 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/119948] Source allocation of pure function result rejected

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119948 Jerry DeLisle changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|---

[Bug fortran/119948] Source allocation of pure function result rejected

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119948 --- Comment #23 from Jerry DeLisle --- Paul is out for about two weeks. I have appled the two patches involved to 15 and if testing is clean, I will commit.

[Bug fortran/120743] ice in verify_gimple_in_seq

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120743 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/120690] Faster short testing of gfortran

dot gnu.org |jvdelisle at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2025-06-17

[Bug fortran/120690] New: Faster short testing of gfortran

Assignee: unassigned at gcc dot gnu.org Reporter: jvdelisle at gcc dot gnu.org Target Milestone: --- I am putting together a python script to enable the gfortran maintainers to do quicker testing of the gfortran.dg testing. I though I would open this PR so we can track review

[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED Status|REOPENED

[Bug libstdc++/120514] Build failure, possibly with C++

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120514 --- Comment #5 from Jerry DeLisle --- As a followup. Thanks for the hints about what is going on. I recently upgraded from Fedora 41 to 42. The build I was attempting was a clean build, I always start with an empty build directory. I was susp

[Bug c++/120514] New: Build failure, possibly with C++

++ Assignee: unassigned at gcc dot gnu.org Reporter: jvdelisle at gcc dot gnu.org Target Milestone: --- I am seeing this. 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

[Bug fortran/119948] Source allocation of pure function result rejected

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119948 --- Comment #21 from Jerry DeLisle --- (In reply to Damian Rouson from comment #20) > Should this issue be marked as resolved? If so, can the fix be back ported > to the 15 branch? I think it is resolved. It could be backported. Paul if you ar

[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856 --- Comment #14 from Jerry DeLisle --- Created attachment 61556 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=61556&action=edit Patch to correct runtime behavior of repeated use of the same format This patch corrects a latent problem. ma

[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856 --- Comment #13 from Jerry DeLisle --- (In reply to Walter Spector from comment #12) > > Definately not right. > > > > This is some different Issue. > > If it would help, I'd be happy to submit another PR. No need. I do have an idea why this i

[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856 Jerry DeLisle changed: What|Removed |Added Resolution|FIXED |--- Status|RESOLVED

[Bug fortran/27436] gfortran: Abort compiling if there are insufficient data descriptors in format after reversion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27436 --- Comment #7 from Jerry DeLisle --- Currently. ! From PR27436 write(*,'(abc)') n ! We throw a compile time error here. write(10,"(i7,(' abcd'))") n, n ! We throw a run time error here. 10 print *, "Hello World!" end Comment the first

[Bug fortran/27436] gfortran: Abort compiling if there are insufficient data descriptors in format after reversion

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27436 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856 --- Comment #9 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #8) > At line 7 of file newby.f90 (unit = 6, file = 'stdout') > Fortran runtime error: Missing comma between descriptors > (AI5) > ^ Oops, I copied the wrong o

[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856 --- Comment #8 from Jerry DeLisle --- (In reply to Walter Spector from comment #7) > Confirmed that the compiler now diagnoses the missing commas. Thanks! > After taking out the iostat so I could see the error message I am getting the followin

[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856 Bug 119856 depends on bug 83282, which changed state. Bug 83282 Summary: missing comma in format changes output https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83282 What|Removed |Added ---

[Bug libfortran/83282] missing comma in format changes output

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83282 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED

[Bug fortran/119856] Missing commas in I/O formats not diagnosed by default at compile time.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119856 --- Comment #4 from Jerry DeLisle --- Note: I biffed the PR number in the log. The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:e2bf0b3910de7e65363435f0a7fa606e2448a677 commit r16-939-ge2bf0b3910de7e65363435f0a7fa60

[Bug tree-optimization/119586] [15 Regression] wrong code at -O2 with "-ftree-loop-vectorize -fno-inline" on x86_64-linux-gnu since r15-8047

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119586 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/109345] [12/13/14 Regression] class(*) variable that is a string array is not handled correctly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109345 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/101735] Type parameter inquiries for substrings are rejected

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101735 --- Comment #13 from Jerry DeLisle --- (In reply to anlauf from comment #12) > Created attachment 61529 [details] > Fix for the breakage by r16-914-g787a8dec1acedf OK to push after testing. I am rebuilding now and can do for you. It has to be l

[Bug fortran/101735] Type parameter inquiries for substrings are rejected

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101735 --- Comment #9 from Jerry DeLisle --- (In reply to anlauf from comment #8) > (In reply to Jerry DeLisle from comment #7) > > Ruuning tests right now to see if this has caused some breakage. > > Are you also hit by r16-916-g517c9487f8fdc4 which

[Bug fortran/101735] Type parameter inquiries for substrings are rejected

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101735 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049 --- Comment #37 from Jerry DeLisle --- With this now pushed, I plan to backport to 15 in a few days. I also want to revise the langauge of the error messages to be clearer. This will wiggle on several existing test cases so I want it to be a se

[Bug fortran/120431] SPREAD does not handle scalar argument and NCOPIES=-1 correctly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120431 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049 Jerry DeLisle changed: What|Removed |Added Attachment #61475|0 |1 is obsolete|

[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049 Jerry DeLisle changed: What|Removed |Added Attachment #61445|0 |1 is obsolete|

[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049 --- Comment #33 from Jerry DeLisle --- (In reply to GCC Commits from comment #32) > The releases/gcc-15 branch has been updated by Jerry DeLisle > : Preparing for the backport of the follow-on patch.

[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049 --- Comment #31 from Jerry DeLisle --- Patch submitted: https://gcc.gnu.org/pipermail/fortran/2025-May/062177.html

[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049 Jerry DeLisle changed: What|Removed |Added Attachment #61307|0 |1 is obsolete|

[Bug fortran/120049] ICE when using IS_C_ASSOCIATED ()

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=120049 --- Comment #29 from Jerry DeLisle --- Steve, I am still working on it. Always other things getting me in the time domain. (poles and zeros so to speak, LOL) I do like some of the checks in Comment #27.

  1   2   3   4   5   6   7   8   9   10   >