[Bug fortran/100971] ICE: Bad IO basetype (7)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100971 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle2 at gmail dot com --- Comment #1 from Jerry DeLisle --- I can confirm this bug.
[Bug fortran/103054] [f18] Gfortran accepts invalid and rejects valid co_reduce argument keyword name
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103054 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle2 at gmail dot com --- Comment #3 from Jerry DeLisle --- I will commit as obvious.
[Bug fortran/107874] merge not using all its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874 --- Comment #9 from Jerry DeLisle --- I am seeing timeout failures with merge_1.f90. Can you look into this? Thanks, Jerry On Thu, Dec 1, 2022, 12:28 PM anlauf at gcc dot gnu.org via Gcc-bugs < gcc-bugs@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874 > > anlauf at gcc dot gnu.org changed: > >What|Removed |Added > > >Target Milestone|--- |13.0 > Resolution|--- |FIXED > Status|ASSIGNED|RESOLVED > > --- Comment #8 from anlauf at gcc dot gnu.org --- > Fixed on mainline for gcc-13. Closing. > > Thanks for the report!
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle2 at gmail dot com --- Comment #1 from Jerry DeLisle --- Well, looks like we are allowing as an extension. $ gfortran -std=f95 pr105473.f90 pr105473.f90:6:27: 6 | read(testinput,*,decimal='point',iostat=ios) n | 1 Error: Fortran 2003: DECIMAL= at (1) not allowed in Fortran 95 If you set n to some value so that it is 'defined' per the standards like this: ! Does list-directed reading an integer allow some non-integer input? implicit none integer n,ios character(1):: testinput = ';' n = 999 print *,'testinput = "',testinput,'"' read(testinput,*,decimal='point',iostat=ios) n print *,'n=',n,' ios=',ios if(ios>0) print *,'testinput was not an integer' end program $ gfortran pr105473.f90 [jerry@amdr pr105473]$ ./a.out testinput = ";" n= 999 ios= 0 You will see that nothing is read into n at all. The list read is just ended.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #2 from Jerry DeLisle --- I should add, I am not saying this is right or wrong. The error message refers to F2003. $ gfortran -std=f2003 pr105473.f90 [jerry@amdr pr105473]$ ./a.out testinput = ";" n= 999 ios= 0 It is being allowed with the later standard flag. We will have to dig through the standard as well as look at the error checking that is in place to answer the question.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #4 from Jerry DeLisle --- Hi all, I will be looking closer on this one. As I said have to look at the checking code. As soon as I noticed -std=f2003 allowing this it makes no sense at all. I can understand possibly the extension to allow a semicolon to simply end the transfer. We do need to fix the diagnostics. I see I no longer have change status on PRs. Evidently some of the address and login changes I have had to do in the process of changing my email providers has messed it all up. Who do you call? Ghost Busters?
[Bug libfortran/105361] Incorrect end-of-file condition for derived-type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle2 at gmail dot com --- Comment #3 from Jerry DeLisle --- Hi Thomas, this is another one I would like to look at since I implemented a lot of this in the beginning. I want to look at the dump and see why the condition is not being set. I have a hunch on this. It has to do with the DTP structure where the status kept.
[Bug fortran/102619] [11/12/13/14/15 Regression] ICE in gfc_conv_descriptor_dtype, at fortran/trans-array.c:215 since r9-6493-g0e3088806577e805
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102619 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle2 at gmail dot com --- Comment #7 from Jerry DeLisle --- Interestingly, real :: x(:,:) works vs real :: x(..) in the function declaration with your partial patch.
[Bug fortran/115689] New: Missed deallocation before exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115689 Bug ID: 115689 Summary: Missed deallocation before exit Product: gcc Version: 15.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jvdelisle2 at gmail dot com Target Milestone: --- The following gives valgrind error when the deallocate is commented out: program test integer, allocatable, dimension(:) :: VLQ integer i, filo allocate(VLQ(0)) do i=1, 5 filo = 2**i + 27 VLQ = [ VLQ, int(filo) ] print *, VLQ end do !deallocate(VLQ) end program ==16247== HEAP SUMMARY: ==16247== in use at exit: 20 bytes in 1 blocks ==16247== total heap usage: 38 allocs, 37 frees, 5,645 bytes allocated ==16247== ==16247== LEAK SUMMARY: ==16247==definitely lost: 20 bytes in 1 blocks
[Bug fortran/115689] Missed deallocation before exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115689 --- Comment #2 from Jerry DeLisle --- Well I do not know about how all the hooks work but this is with the following configure: ../trunk/configure --prefix=/home/jerry/dev/usr --enable-languages=c,c++,fortran --enable-libgomp --disable-bootstrap --enable-valgrind-annotations Enabling the valgrind annotations should give fairly accurate results. I do not know what you get on FreeBSD OS. I was using Fedora 40 OS.
[Bug fortran/115689] Missed deallocation before exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115689 --- Comment #4 from Jerry DeLisle --- (In reply to kargls from comment #3) > The code you posted is standard conforming, and when > compiled, executes as expected. > > My point is that the program is exiting. The operate system will > reap the process and reclaim the memory. Valgrind need not warn > about this. It is just noise. It is not a memory leak. If anything > it is poor programming on the part of the person that wrote the > code, and arguably a bug the code. > I agree completely, I would prefer that programmers explicitly deallocate. I simply do not know what our expectations should be when testing. Maybe in this case it is a don't care. I posted the question for clarification from others.
[Bug fortran/115689] Missed deallocation before exit
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=115689 Jerry DeLisle changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #7 from Jerry DeLisle --- Thankyou for comments. I will close as not a bug.
[Bug libfortran/105361] Incorrect end-of-file condition for derived-type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361 --- Comment #5 from Jerry DeLisle --- Created attachment 58715 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=58715&action=edit Proposed patch, still testing The attached patch fixes this bug and passes regression testing. I want to try a variation on this and test some more before submitting for approval.
[Bug libfortran/105361] Incorrect end-of-file condition for derived-type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361 --- Comment #7 from Jerry DeLisle --- I am not allowed to close this PR. (???) It is Resolved/Fixed.
[Bug fortran/119054] [12/13/14/15 Regression] ICE on passing optional array to elemental procedure with -pedantic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119054 --- Comment #3 from Jerry DeLisle --- I will do the commit. On Fri, Mar 7, 2025, 12:57 PM anlauf at gcc dot gnu.org via Gcc-bugs < gcc-bugs@gcc.gnu.org> wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=119054 > > --- Comment #2 from anlauf at gcc dot gnu.org --- > (In reply to Jerry DeLisle from comment #1) > > Thanks for PR and a patch submitted here: > > > > https://gcc.gnu.org/pipermail/fortran/2025-February/061793.html > > > > In review. > > LGTM. I had to manually apply the patch, as it did not show as a proper > attachment in my reader. > > Jerry, do you want to take it?
