[Bug libfortran/91593] Implicit enum conversions in libgfortran/io/transfer.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91593 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from Jerry DeLisle --- As far as I can tell, fixed on trunk.
[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 --- Comment #3 from Jerry DeLisle --- Created attachment 47116 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=47116&action=edit Peliminary patch This is a preliminary patch to allow others to check the results
[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 --- Comment #4 from Jerry DeLisle --- Author: jvdelisle Date: Thu Nov 7 03:06:20 2019 New Revision: 277905 URL: https://gcc.gnu.org/viewcvs?rev=277905&root=gcc&view=rev Log: 2019-11-06 Jerry DeLisle PR fortran/90374 * io.c (check_format): Allow zero width for D, E, EN, and ES specifiers as default and when -std=F2018 is given. Retain existing errors when using the -fdec family of flags. * libgfortran/io/format.c (parse_format_list): Relax format checking for zero width as default and when -std=f2018. io/format.h (format_token): Move definition to io.h. io/io.h (format_token): Add definition here to allow access to this definition at higher levels. Rename the declaration of write_real_g0 to write_real_w0 and add a new format_token argument, allowing higher level functions to pass in the token for handling of g0 vs the other zero width specifiers. io/transfer.c (formatted_transfer_scalar_write): Add checks for zero width and call write_real_w0 to handle it. io/write.c (write_real_g0): Remove. (write_real_w0): Add new, same as previous write_real_g0 except check format token to handle the g0 case. * gfortran.dg/fmt_error_10.f: Modify for new constraints. * gfortran.dg/fmt_error_7.f: Add dg-options "-std=f95". * gfortran.dg/fmt_error_9.f: Modify for new constraints. * gfortran.dg/fmt_zero_width.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/fmt_zero_width.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/fmt_error_10.f trunk/gcc/testsuite/gfortran.dg/fmt_error_7.f trunk/gcc/testsuite/gfortran.dg/fmt_error_9.f trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c trunk/libgfortran/io/format.h trunk/libgfortran/io/io.h trunk/libgfortran/io/transfer.c trunk/libgfortran/io/write.c
[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-11-08 CC||jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #7 from Jerry DeLisle --- I just noticed this bug. Since I implemented STREAM I/O in the first place, I wiil study this a bit and get back to you. I have experimented with the code and I think something is wrong.
[Bug fortran/92358] libgfortran/io/async.c:548:37: warning: unused parameter 'cmp'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92358 --- Comment #1 from Jerry DeLisle --- I notoced your report here. I do not get that warning on my system here. I am using gcc version 9.2.1 20190827 to build with. What are you using?
[Bug libfortran/92569] [8/9/10 Regression] gfortran read with end directive does not trigger with -ffrontend-optimize
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92569 --- Comment #9 from Jerry DeLisle --- (In reply to Thomas Koenig from comment #8) > Hope you don't mind if I take this. Hi Thomas, just noticed this one. I can review for you when you are ready.
[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
--- Comment #8 from Jerry DeLisle ---
Patch:
diff --git a/libgfortran/io/transfer.c b/libgfortran/io/transfer.c
index 6382d0dad09..bb104db3584 100644
--- a/libgfortran/io/transfer.c
+++ b/libgfortran/io/transfer.c
@@ -3273,8 +3273,9 @@ data_transfer_init_worker (st_parameter_dt *dtp, int
read_flag)
if (dtp->pos != dtp->u.p.current_unit->strm_pos)
{
- fbuf_flush (dtp->u.p.current_unit, dtp->u.p.mode);
- if (sseek (dtp->u.p.current_unit->s, dtp->pos - 1, SEEK_SET) <
0)
+ fbuf_reset (dtp->u.p.current_unit);
+ if (sseek (dtp->u.p.current_unit->s, dtp->pos - 1,
+SEEK_SET) < 0)
{
generate_error (&dtp->common, LIBERROR_OS, NULL);
return;
[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100 --- Comment #9 from Jerry DeLisle --- Author: jvdelisle Date: Sun Nov 24 22:14:59 2019 New Revision: 278660 URL: https://gcc.gnu.org/viewcvs?rev=278660&root=gcc&view=rev Log: 2019-11-24 Jerry DeLisle PR fortran/92100 io/transfer.c (data_transfer_init_worker): Use fbuf_reset instead of fbuf_flush before the seek. Note that fbuf_reset calls fbuf_flush and adjusts fbuf pointers. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/transfer.c
[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100 --- Comment #10 from Jerry DeLisle --- Author: jvdelisle Date: Mon Nov 25 02:24:55 2019 New Revision: 278664 URL: https://gcc.gnu.org/viewcvs?rev=278664&root=gcc&view=rev Log: 2019-11-24 Jerry DeLisle PR fortran/92100 gfortran.dg/streamio_18.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/streamio_18.f90 Modified: trunk/gcc/ChangeLog
[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100 --- Comment #11 from Jerry DeLisle --- > Modified: > trunk/gcc/ChangeLog Hi hit the wrong log file for the testsuite entry. It has been fixed.
[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100 --- Comment #12 from Jerry DeLisle --- Author: jvdelisle Date: Tue Nov 26 22:56:24 2019 New Revision: 278740 URL: https://gcc.gnu.org/viewcvs?rev=278740&root=gcc&view=rev Log: 2019-11-26 Jerry DeLisle Backport from mainline PR fortran/92100 io/transfer.c (data_transfer_init_worker): Use fbuf_reset instead of fbuf_flush before the seek. Note that fbuf_reset calls fbuf_flush and adjusts fbuf pointers. gfortran.dg/streamio_18.f90: New test. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/streamio_18.f90 Modified: branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/libgfortran/ChangeLog branches/gcc-9-branch/libgfortran/io/transfer.c
[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100 --- Comment #13 from Jerry DeLisle --- Author: jvdelisle Date: Wed Nov 27 00:50:51 2019 New Revision: 278753 URL: https://gcc.gnu.org/viewcvs?rev=278753&root=gcc&view=rev Log: 2019-11-26 Jerry DeLisle Backport from mainline PR fortran/92100 io/transfer.c (data_transfer_init): Use fbuf_reset instead of fbuf_flush before the seek. Note that fbuf_reset calls fbuf_flush and adjusts fbuf pointers. gfortran.dg/streamio_18.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/streamio_18.f90 Modified: branches/gcc-8-branch/gcc/testsuite/ChangeLog branches/gcc-8-branch/libgfortran/ChangeLog branches/gcc-8-branch/libgfortran/io/transfer.c
[Bug libfortran/92100] Formatted stream IO irreproducible read with binary data in file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #14 from Jerry DeLisle --- Fixed on 10, 9, and 8.
[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 --- Comment #5 from Jerry DeLisle --- Author: jvdelisle Date: Thu Nov 28 18:33:20 2019 New Revision: 278817 URL: https://gcc.gnu.org/viewcvs?rev=278817&root=gcc&view=rev Log: PR fortran/90374 * io.c (check_format): Allow zero width expoenent with e0. * io/format.c (parse_format_list): Relax format checking to allow e0 exponent specifier. * gfortran.dg/fmt_zero_width.f90: Update test. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/fmt_zero_width.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c trunk/libgfortran/io/write_float.def
[Bug fortran/92350] Document non-standard namelist quote handling in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92350 --- Comment #3 from Jerry DeLisle --- (In reply to Tobias Burnus from comment #2) > For the added text, cf. PR 60148 and > https://gcc.gnu.org/ml/fortran/2014-03/msg00145.html > > I missed that patch when writing this PR because it wasn't posted to > gcc-patches@ :-( Sorry about that. So would you like this better documented? The whole situation is unfortunate.
[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
--- Comment #7 from Jerry DeLisle ---
(In reply to anlauf from comment #6)
> (In reply to Jerry DeLisle from comment #5)
> > Author: jvdelisle
> > Date: Thu Nov 28 18:33:20 2019
> > New Revision: 278817
>
> Jerry,
>
> your change to format.c generates a warning here:
>
> ../../../trunk/libgfortran/io/format.c: In function 'parse_format_list':
> ../../../trunk/libgfortran/io/format.c:1029:7: warning: suggest explicit
> braces to avoid am
> biguous 'else' [-Wdangling-else]
> 1029 |if (t != FMT_POSINT)
> | ^
>
> Looking at the context:
>
> t = format_lex (fmt);
> if (t != FMT_POSINT)
> if (t == FMT_ZERO)
> {
>
> this seems to make sense (to me). Do you plan to add {}?
Hi Herald, I saw that also, so plan to add the braces.
[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 --- Comment #8 from Jerry DeLisle --- Author: jvdelisle Date: Sun Dec 1 22:29:43 2019 New Revision: 278886 URL: https://gcc.gnu.org/viewcvs?rev=278886&root=gcc&view=rev Log: 2019-12-01 Jerry DeLisle PR fortran/90374 * io/format.c (parse_format_list): Add braces to disambiguate conditional. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c
[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
--- Comment #9 from Jerry DeLisle ---
(In reply to anlauf from comment #6)
---snip---
> Jerry,
>
> your change to format.c generates a warning here:
>
> ../../../trunk/libgfortran/io/format.c: In function 'parse_format_list':
> ../../../trunk/libgfortran/io/format.c:1029:7: warning: suggest explicit
---snip---
> {
>
> this seems to make sense (to me). Do you plan to add {}?
Hi Herald, I saw that also, so did add the braces.
[Bug libfortran/92836] segfault with inquire()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #3 from Jerry DeLisle --- With the the following example I see varying results: program inq use OMP_Lib implicit none logical :: s character(len=27) :: c integer :: i, j i=64 !$omp parallel private(c,j,s) print *, OMP_Get_Thread_Num(), omp_get_num_threads(), omp_get_num_threads()/2 do while (.true.) if (OMP_Get_Thread_Num() < omp_get_num_threads()/2) then open(newUnit=j,file='test.txt',form='formatted',status='unknown') write (c,'(e17.10, ">>>",i5, i5, "<<<")') 1.23456d0, j, OMP_Get_Thread_Num() write (j,*) trim(c) close(j) else inquire(file='test.txt',exist=s) end if end do !$omp end parallel end program I get randomly: $ ./a.out 0 8 4 3 8 4 6 8 4 5 8 4 4 8 4 1 8 4 2 8 4 At line 14 of file bug1.f90 At line 14 of file bug1.f90 7 8 4 Fortran runtime error: Fortran runtime error: End of recordEnd of record $ ./a.out 2 8 4 5 8 4 6 8 4 1 8 4 7 8 4 0 8 4 4 8 4 3 8 4 At line 14 of file bug1.f90 At line 14 of file bug1.f90 At line 14 of file bug1.f90 At line 14 of file bug1.f90 Fortran runtime error: Fortran runtime error: Fortran runtime error: End of recordFortran runtime error: End of recordEnd of record End of record [jerry@amdr threadbug]$ ./a.out 0 8 4 2 8 4 6 8 4 1 8 4 5 8 4 7 8 4 At line 14 of file bug1.f90 Fortran runtime error: End of record 3 8 4 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: $ ./a.out 2 8 4 6 8 4 1 8 4 0 8 4 5 8 4 7 8 4 3 8 4 4 8 4 At line 14 of file bug1.f90 At line 14 of file bug1.f90 Fortran runtime error: At line 14 of file bug1.f90 At line 14 of file bug1.f90 End of recordFortran runtime error: Fortran runtime error: Fortran runtime error: End of recordEnd of recordEnd of record $ ./a.out 7 8 4 6 8 4 1 8 4 0 8 4 5 8 4 2 8 4 3 8 4 At line 14 of file bug1.f90 Fortran runtime error:4 8 4 End of record At line 14 of file bug1.f90 Fortran runtime error: End of file
[Bug libfortran/92836] segfault with inquire()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836 --- Comment #4 from Jerry DeLisle --- Removing close statement: $ ./a.out 0 8 4 2 8 4 -10 5 8 4 4 8 4 3 8 4 At line 16 of file bug1.f90 Fortran runtime error: End of record 6 8 4 At line 14 of file bug1.f90 Internal Error: Unit number changed At line 14 of file bug1.f90 What I speculate is happening is that newunit is getting invoked in the middle of trying to close the unit on a different thread and we do end up with duplicate unit numbers assigned by newunit. I need to look at that code yet. Exploring further here.
[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 --- Comment #11 from Jerry DeLisle --- (In reply to Thomas Henlich from comment #10) --- snip --- > > 13.7.2.3.3 E and D editing > ... If e is positive the exponent part contains e digits, otherwise it > contains the minimum number of digits required to represent the exponent > value. ... Yes, thanks Thomas. I will fix this. It was very easy to do what I did with the existing code. To get rid of the leading zero on the exponent will require me to scratch my head a little further. Cheers
[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 --- Comment #17 from Jerry DeLisle --- Thanks for feedback. Hopefully I can get to it next day or so.
[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 --- Comment #20 from Jerry DeLisle --- While working on this I found another issue: program test implicit none real(8) :: rn character(32) :: afmt, aresult rn = 0.000314e8_8 write (*,fmt="(E0.8e0, a3)") rn, "<<<" end $ gfc c10.f90 $ ./a.out At line 6 of file c10.f90 (unit = 6, file = 'stdout') Fortran runtime error: Expected REAL for item 2 in formatted transfer, got CHARACTER (E0.8e0, a3) This is a more serious error since I am parsing wrong here. ^
[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 --- Comment #21 from Jerry DeLisle --- Author: jvdelisle Date: Thu Jan 2 00:57:31 2020 New Revision: 279828 URL: https://gcc.gnu.org/viewcvs?rev=279828&root=gcc&view=rev Log: PR 90374 d0.d, e0.d, es0.d, en0.d, g0.d and ew.d edit descriptors. PR libfortran/90274 * io/format.c (parse_format_list): Implement the E0 exponent width to provide smallest possible width for exponent fields. Refactor code for correct parsing and better readability of the code. * io/io.h (write_real_w0): Change interface to pass in pointer to fnode. * io/transfer.c: Update all calls to write_real_w0 to use the new interface. * io/write.c ((write_real_w0): Use the new interface with fnode to access both the decimal precision and exponent widths used in build_float_string. * io/write_float.def (build_float_string): Use the passed in exponent width to calculate the used width in the case of E0. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/fmt_zero_width.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c trunk/libgfortran/io/io.h trunk/libgfortran/io/transfer.c trunk/libgfortran/io/write.c trunk/libgfortran/io/write_float.def
[Bug translation/90274] untranslated string literal in opts.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90274 --- Comment #5 from Jerry DeLisle --- Author: jvdelisle Date: Thu Jan 2 00:57:31 2020 New Revision: 279828 URL: https://gcc.gnu.org/viewcvs?rev=279828&root=gcc&view=rev Log: PR 90374 d0.d, e0.d, es0.d, en0.d, g0.d and ew.d edit descriptors. PR libfortran/90274 * io/format.c (parse_format_list): Implement the E0 exponent width to provide smallest possible width for exponent fields. Refactor code for correct parsing and better readability of the code. * io/io.h (write_real_w0): Change interface to pass in pointer to fnode. * io/transfer.c: Update all calls to write_real_w0 to use the new interface. * io/write.c ((write_real_w0): Use the new interface with fnode to access both the decimal precision and exponent widths used in build_float_string. * io/write_float.def (build_float_string): Use the passed in exponent width to calculate the used width in the case of E0. Modified: trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/fmt_zero_width.f90 trunk/libgfortran/ChangeLog trunk/libgfortran/io/format.c trunk/libgfortran/io/io.h trunk/libgfortran/io/transfer.c trunk/libgfortran/io/write.c trunk/libgfortran/io/write_float.def
[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 --- Comment #22 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #21) > Author: jvdelisle > Date: Thu Jan 2 00:57:31 2020 > New Revision: 279828 > > URL: https://gcc.gnu.org/viewcvs?rev=279828&root=gcc&view=rev > Log: > PR 90374 d0.d, e0.d, es0.d, en0.d, g0.d and ew.d edit descriptors. > > PR libfortran/90274 Notice the reference to 90274 here. I notice the typo in the middle of editing the git commit entry and aborted the edit, fixed it and did the commit again. So the ChangeLog files are correct and it it the correct PR comment here, but shows the typo. I wonder if I need to execute some other git command if I abort a commit like that?
[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 --- Comment #27 from Jerry DeLisle --- Hi Thomas, stating the obvious, I do not find it straight forwaed to interpret the standards because there are nooks and crannies and corner cases. At least now I have the basic pieces in place. I will try to study this weekend and try to do the further refinements.
[Bug fortran/93234] INQUIRE on pre-assigned files of ROUND and SIGN properties fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93234
Jerry DeLisle changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-01-13
CC||jvdelisle at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jerry DeLisle ---
The enumerators in inquire.c do not match those set in unit.c.
Something like this is needed.
diff --git a/libgfortran/io/inquire.c b/libgfortran/io/inquire.c
index e6b22eb0b33..62aca71a162 100644
--- a/libgfortran/io/inquire.c
+++ b/libgfortran/io/inquire.c
@@ -371,7 +371,7 @@ inquire_via_unit (st_parameter_inquire *iqp, gfc_unit *u)
else
switch (u->flags.sign)
{
- case SIGN_PROCDEFINED:
+ case SIGN_UNSPECIFIED:
p = "PROCESSOR_DEFINED";
break;
case SIGN_SUPPRESS:
@@ -409,7 +409,7 @@ inquire_via_unit (st_parameter_inquire *iqp, gfc_unit *u)
case ROUND_COMPATIBLE:
p = "COMPATIBLE";
break;
- case ROUND_PROCDEFINED:
+ case ROUND_UNSPECIFIED:
p = "PROCESSOR_DEFINED";
break;
default:
I wonder if they are off for any others?
[Bug fortran/93234] INQUIRE on pre-assigned files of ROUND and SIGN properties fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93234 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from Jerry DeLisle --- Fixed on trunk. This could be easily backported to gcc 9. Any thoughts?
[Bug libfortran/92836] segfault with inquire()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836 --- Comment #15 from Jerry DeLisle --- Did we conclude that this is an expected race condition? I run the example comment 14 and it just hangs for me.
[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 --- Comment #29 from Jerry DeLisle --- I think this last patch above fixes the last adjustment needed. I could be wrong I suppose. Is this ready to close?
[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 --- Comment #32 from Jerry DeLisle --- Thanks Thomas, I will have a look. It really helps to have a second pair of eyes on this.
[Bug libfortran/93550] Implement control of leading zero in formatted numeric output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93550 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- A truly wish the standards committee would stop inventing these unnecessary features. I hope they vote it out.
[Bug libfortran/93567] G edit descriptor uses E instead of F editing in rounding mode UP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93567 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- hmm, I will have to take a closer look at this one.
[Bug fortran/93599] [9/10 regression] Bug in fortran asynchronous I/O wait function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93599 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- The fact that it worked in the previous version is sort of irrelevent because it was simply syntax checking brfore the patch and not actually doing anything useful. So it appears to be a some sort of difficult to trigger bug o this specific platform. I am going to see if I can reproduce this on x86 with a big repeting loop or soething. It could be a bug in thread locking or gomp related on the powerpc.
[Bug fortran/93599] [9/10 regression] Bug in fortran asynchronous I/O wait function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93599 --- Comment #5 from Jerry DeLisle --- (In reply to Thomas Koenig from comment #4) > Created attachment 47800 [details] > Possible fix > > Here is something that Nicolas and I came up with. The theory is that > pthread_cond_wait can get a spurious interrupt once in a blue moon which > previosly led to the macro becoming a no-op. > > I have tested this to around 8 Million invocations of the test program, but > this is not a guarantee... > > Incidentially, this also appears to fix the issue that helgrind reported. > It passes regression testing. > > Is there a reasonable way to test this further? Awesome sleuthing. I think we could run your test case on a PowerPC64 either in the gcc compile farm for at OSU (Oregon State University) I will check to see if I can still get into the OSU machine.
[Bug fortran/93599] [9/10 regression] Bug in fortran asynchronous I/O wait function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93599 --- Comment #6 from Jerry DeLisle --- Forgot to mention. Did you test with or without Janne's patch here: https://gcc.gnu.org/ml/fortran/2020-01/msg00158.html It could be related or influence this.
[Bug libfortran/56737] [4.6/4.7/4.8/4.9 Regression] Wrong I/O result with format cache for Hollerith strings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56737
--- Comment #3 from Jerry DeLisle 2013-03-28
02:34:32 UTC ---
Note the comment at line 728 of format.c where we must disable format caching
when we encounter FMT_STRING. The problem is related to saving a pointer to a
string rather than the string itself. That pointer can go out of scope on
subsequent I/O operations so caching the format data will not work.
A similar thing happens with FMT_H. Try this not regression tested yet
Index: format.c
===
--- format.c(revision 196516)
+++ format.c(working copy)
@@ -807,6 +807,7 @@
goto data_desc;
case FMT_H:
+ saveit = false;
get_fnode (fmt, &head, &tail, FMT_STRING);
if (fmt->format_string_len < 1)
{
@@ -984,6 +985,7 @@
break;
case FMT_H:
+ saveit = false;
if (repeat > fmt->format_string_len)
{
fmt->error = bad_hollerith;
I get:
$ gfortran -g -o gfort_bug gfort_bug-2.f90 && valgrind ./gfort_bug
==22746== Memcheck, a memory error detector
==22746== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==22746== Using Valgrind-3.8.1 and LibVEX; rerun with -h for copyright info
==22746== Command: ./gfort_bug
==22746==
fmt = ( 3(1H ),6h= ,a 12,i4,6h =)
title1= end of level
level =1
= end of level 1 =
fmt = ( 3(1H ),6h= ,a 12,i4,6h =)
title1= end of level
level =1
= end of level 1 =
==22746==
==22746== HEAP SUMMARY:
==22746== in use at exit: 0 bytes in 0 blocks
==22746== total heap usage: 29 allocs, 29 frees, 27,978 bytes allocated
==22746==
==22746== All heap blocks were freed -- no leaks are possible
==22746==
==22746== For counts of detected and suppressed errors, rerun with: -v
==22746== ERROR SUMMARY: 0 errors from 0 contexts (suppressed: 2 from 2)
I see no burning need to cache these kinds of formats so just disable it.
[Bug libfortran/49791] [4.6/4.7/4.8/4.9 Regression] Formatted namelist reads fails with: Cannot match namelist object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791 --- Comment #24 from Jerry DeLisle 2013-03-30 02:58:25 UTC --- Created attachment 29751 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=29751 Related test case This example fails with a runtime error and passes with ifort. The other cases in this PR are fixed.
[Bug fortran/51825] Fortran runtime error: Cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51825 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jerry DeLisle 2013-03-30 03:13:27 UTC --- Fixed on trunk, lets close this one and will carry forward on 56660.
[Bug libfortran/49791] [4.6/4.7/4.8/4.9 Regression] Formatted namelist reads fails with: Cannot match namelist object
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49791 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #25 from Jerry DeLisle 2013-03-30 03:18:49 UTC --- Lets close this one and carry forward on PR56660.
[Bug fortran/52512] Cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52512 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution||FIXED --- Comment #6 from Jerry DeLisle 2013-03-30 03:30:25 UTC --- This bug fixed by Tilo's patch. Closing.
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 --- Comment #20 from Jerry DeLisle 2013-03-30 03:54:27 UTC --- Lets take namelist out of the picture here for the case of comment #6 program test_type_extension type t1_t real :: x end type t1_t type, extends(t1_t) :: t1e_t character(8) :: string end type t1e_t type(t1e_t) :: t1e tle%x = 5.678 end program test_type_extension $ gfc pr55117.f90 pr55117.f90:13.6: tle%x = 5.678 1 Error: Symbol 'tle' at (1) has no IMPLICIT type Ifort agrees with gfortran on this example So, I think this PR (55117) can be closed and if the example in this comment and #6 is another bug, lets open a new PR for it.
[Bug fortran/56743] Namelist bug with comment and no blank
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56743 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot ||gnu.org --- Comment #3 from Jerry DeLisle 2013-03-30 04:08:19 UTC --- Agree, we should just audit list_read.c for this case.
[Bug fortran/55117] Programs fails to read namelist (contains derived types objects)
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55117 --- Comment #21 from Jerry DeLisle 2013-03-30 05:05:03 UTC --- Oops! Disregard Comment #20. There is a not so subtle effect when one mixes up the letter 'l' and the digit '1' in names.
[Bug libfortran/56786] [4.6/4.7/4.8/4.9 Regression] Namelist read fails with designators containing embedded spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56786 --- Comment #1 from Jerry DeLisle 2013-04-01 00:05:14 UTC --- Author: jvdelisle Date: Sun Mar 31 20:32:33 2013 New Revision: 197290 URL: http://gcc.gnu.org/viewcvs?rev=197290&root=gcc&view=rev Log: 2013-03-31 Jerry DeLisle PR libfortran/56786 * io/list_read.c (nml_parse_qualifier): Remove spurious next_char call when checking for EOF. Use error return mechanism when EOF detected. Do not return false unless parse_err_msg and parse_err_msg_size have been set. Use hit_eof. (nml_get_obj_data): Likewise use the correct error mechanism. * io/transfer.c (hit_eof): Do not set AFTER_ENDFILE if in namelist mode. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c trunk/libgfortran/io/transfer.c
[Bug fortran/56803] EOF with namelist read give INTERNAL error instead of END OF FILE error
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56803 --- Comment #1 from Jerry DeLisle 2013-04-01 20:10:02 UTC --- This is fixed on 4.9 by patch to PR56786, but it patch does need to be backported. $ gfc tc56803.f90 $ ./a.out At line 8 of file tc56803.f90 (unit = 99, file = '/tmp/gfortrantmp5qfaGE') Fortran runtime error: End of file
[Bug fortran/56660] Fails to read NAMELIST with certain form array syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56660 --- Comment #2 from Jerry DeLisle 2013-04-01 20:33:52 UTC --- Author: jvdelisle Date: Mon Apr 1 20:30:41 2013 New Revision: 197321 URL: http://gcc.gnu.org/viewcvs?rev=197321&root=gcc&view=rev Log: 2013-04-01 Jerry DeLisle PR libfortran/56660 * io/list_read.c (nml_read_obj): Do not reset the read error flag inside nml_read_obj. If the read error flag is found set just exit. Fix some whitespace on comments. (nml_read_obj_data): Reset the read error flag before the first call to nml_read_object. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c
[Bug fortran/56660] Fails to read NAMELIST with certain form array syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56660 --- Comment #3 from Jerry DeLisle 2013-04-01 21:00:36 UTC --- Author: jvdelisle Date: Mon Apr 1 20:59:34 2013 New Revision: 197322 URL: http://gcc.gnu.org/viewcvs?rev=197322&root=gcc&view=rev Log: 2013-04-01 Jerry DeLisle PR fortran/56660 * gfortran.dg/namelist_82.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/namelist_82.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981 --- Comment #2 from Jerry DeLisle 2013-04-17 00:58:02 UTC --- There is a seek inside next_record_w_unf. That function is used for DIRECT I/O. Looks conceptually wrong to me for sequential unformatted. I won't have time for a few days to look at this further.
[Bug fortran/56981] Slow I/O: Unformatted 5x slower, large sys component; formatted slow as well
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56981 --- Comment #6 from Jerry DeLisle 2013-04-18 01:21:42 UTC --- I like Jannes idea with the flags. Also, it seems that at the time we open a file we know it is /dev/null or /dev/nul in some cases by the file name. It would be very low overhead in a few cases to disable some or all checks and even disable the writing completely. We would not get all situations, but the low hanging fruit we could. It could be done by setting a "NULL" bit. One could consider doing this at compile time in some cases where the frontend could have more elaborate configuration checks that determine the name of the null device on the target system and look for its use. (probably not really worth if fur NULL I/O The other idea to consider is a compiler flag, say -fast-IO or similar that also disables the extra error checking that is not critical to runtime after a program has been debugged.
[Bug libfortran/56786] [4.7/4.8/4.9 Regression] Namelist read fails with designators containing embedded spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56786 --- Comment #6 from Jerry DeLisle 2013-04-27 22:51:47 UTC --- I am in the process of back port to 4.8 along with Tilos patches for 52512 and probably 51825. I will do each separately so we can have a clear record.
[Bug fortran/52512] Cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52512 --- Comment #8 from Jerry DeLisle 2013-04-28 03:24:29 UTC --- Committed to support backport of fix to PR56786 Author: jvdelisle Date: Sun Apr 28 02:59:44 2013 New Revision: 198366 URL: http://gcc.gnu.org/viewcvs?rev=198366&root=gcc&view=rev Log: 2013-04-27 Jerry DeLisle Backport from mainline: 2013-03-25 Tilo Schwarz PR libfortran/52512 * io/list_read.c (nml_parse_qualifier): To check for a derived type don't use the namelist head element type but the current element type. (nml_get_obj_data): Add current namelist element type to nml_parse_qualifier call. PR fortran/52512 * gfortran.dg/namelist_79.f90: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/namelist_79.f90 Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/libgfortran/ChangeLog branches/gcc-4_8-branch/libgfortran/io/list_read.c
[Bug fortran/52512] Cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52512 --- Comment #9 from Jerry DeLisle 2013-04-28 16:54:14 UTC --- Really closed now. Author: jvdelisle Date: Sun Apr 28 16:50:19 2013 New Revision: 198373 URL: http://gcc.gnu.org/viewcvs?rev=198373&root=gcc&view=rev Log: 2013-04-28 Jerry DeLisle Backport from mainline: 2013-03-25 Tilo Schwarz PR libfortran/52512 * io/list_read.c (nml_parse_qualifier): To check for a derived type don't use the namelist head element type but the current element type. (nml_get_obj_data): Add current namelist element type to nml_parse_qualifier call. 2013-04-28 Jerry DeLisle Backport from trunk: PR fortran/52512 * gfortran.dg/namelist_79.f90: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/namelist_79.f90 Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/libgfortran/ChangeLog branches/gcc-4_7-branch/libgfortran/io/list_read.c
[Bug libfortran/56786] [4.7/4.8/4.9 Regression] Namelist read fails with designators containing embedded spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56786 --- Comment #7 from Jerry DeLisle 2013-04-28 16:55:52 UTC --- Author: jvdelisle Date: Sun Apr 28 13:47:42 2013 New Revision: 198370 URL: http://gcc.gnu.org/viewcvs?rev=198370&root=gcc&view=rev Log: 2013-04-28 Jerry DeLisle Backport from mainline: PR libfortran/56786 * io/list_read.c (nml_parse_qualifier): Remove spurious next_char call when checking for EOF. Use error return mechanism when EOF detected. Do not return FAILURE unless parse_err_msg and parse_err_msg_size have been set. Use hit_eof. (nml_get_obj_data): Likewise use the correct error mechanism. * io/transfer.c (hit_eof): Do not set AFTER_ENDFILE if in namelist mode. PR fortran/56786 * gfortran.dg/namelist_81.f90: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/namelist_81.f90 Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/libgfortran/ChangeLog branches/gcc-4_8-branch/libgfortran/io/list_read.c branches/gcc-4_8-branch/libgfortran/io/transfer.c
[Bug libfortran/56786] [4.7/4.8/4.9 Regression] Namelist read fails with designators containing embedded spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56786 --- Comment #8 from Jerry DeLisle 2013-04-28 17:21:12 UTC --- Author: jvdelisle Date: Sun Apr 28 17:20:06 2013 New Revision: 198375 URL: http://gcc.gnu.org/viewcvs?rev=198375&root=gcc&view=rev Log: 2013-04-28 Jerry DeLisle Backport from mainline: PR libfortran/56786 * io/list_read.c (nml_parse_qualifier): Remove spurious next_char call when checking for EOF. Use error return mechanism when EOF detected. Do not return FAILURE unless parse_err_msg and parse_err_msg_size have been set. Use hit_eof. (nml_get_obj_data): Likewise use the correct error mechanism. * io/transfer.c (hit_eof): Do not set AFTER_ENDFILE if in namelist mode. Backport from trunk: PR fortran/56786 * gfortran.dg/namelist_81.f90: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/namelist_81.f90 Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/libgfortran/ChangeLog branches/gcc-4_7-branch/libgfortran/io/list_read.c branches/gcc-4_7-branch/libgfortran/io/transfer.c
[Bug libfortran/56786] [4.7/4.8/4.9 Regression] Namelist read fails with designators containing embedded spaces
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56786 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #9 from Jerry DeLisle 2013-04-28 17:21:56 UTC --- Fixed on 4.8 and 4.7 Closing
[Bug fortran/51825] Fortran runtime error: Cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51825 --- Comment #7 from Jerry DeLisle 2013-04-29 00:55:08 UTC --- Back port due to silent wrong code. Author: jvdelisle Date: Mon Apr 29 00:52:23 2013 New Revision: 198385 URL: http://gcc.gnu.org/viewcvs?rev=198385&root=gcc&view=rev Log: 2013-04-28 Jerry DeLisle Backport from mainline: 2013-03-20 Tilo Schwarz PR libfortran/51825 * io/list_read.c (nml_read_obj): Don't end the component loop on a nested derived type, but continue with the next loop iteration. (nml_get_obj_data): Don't move the first_nl pointer further in the list if a qualifier was found. PR fortran/51825 * gfortran.dg/namelist_77.f90: New test. * gfortran.dg/namelist_78.f90: New test. Added: branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/namelist_77.f90 branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/namelist_78.f90 Modified: branches/gcc-4_8-branch/gcc/testsuite/ChangeLog branches/gcc-4_8-branch/libgfortran/ChangeLog branches/gcc-4_8-branch/libgfortran/io/list_read.c
[Bug fortran/51825] Fortran runtime error: Cannot match namelist object name
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=51825 --- Comment #8 from Jerry DeLisle 2013-04-29 01:27:05 UTC --- Author: jvdelisle Date: Mon Apr 29 01:25:43 2013 New Revision: 198386 URL: http://gcc.gnu.org/viewcvs?rev=198386&root=gcc&view=rev Log: 2013-04-28 Jerry DeLisle Backport from mainline: 2013-03-20 Tilo Schwarz PR libfortran/51825 * io/list_read.c (nml_read_obj): Don't end the component loop on a nested derived type, but continue with the next loop iteration. (nml_get_obj_data): Don't move the first_nl pointer further in the list if a qualifier was found. PR fortran/51825 * gfortran.dg/namelist_77.f90: New test. * gfortran.dg/namelist_78.f90: New test. Added: branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/namelist_77.f90 branches/gcc-4_7-branch/gcc/testsuite/gfortran.dg/namelist_78.f90 Modified: branches/gcc-4_7-branch/gcc/testsuite/ChangeLog branches/gcc-4_7-branch/libgfortran/ChangeLog branches/gcc-4_7-branch/libgfortran/io/list_read.c Really closed now.
[Bug fortran/56743] Namelist bug with comment and no blank
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56743 --- Comment #5 from Jerry DeLisle 2013-05-03 20:32:51 UTC --- I have a patch testing that fixes the items identified in the attachment of Comment #4 by accepting them as extension.
[Bug fortran/56660] Fails to read NAMELIST with certain form array syntax
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56660 --- Comment #4 from Jerry DeLisle 2013-05-05 00:37:10 UTC --- Fixed on trunk. Shall we close this? The type extension bug, PR56117 remains.
[Bug fortran/52387] I/O output of write after nonadvancing read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52387 --- Comment #10 from Jerry DeLisle 2012-10-28 00:35:41 UTC --- Tobias, any further information on this one?
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot ||gnu.org --- Comment #3 from Jerry DeLisle 2010-12-18 21:24:02 UTC --- Please confirm for me. Is the difference between EN and RU decimal point vs decimal comma? Can you attach a small example of the namelist data file generated with RU locale?
[Bug fortran/47007] Values from namelist file should not depend on locale settings
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47007 Jerry DeLisle changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org --- Comment #10 from Jerry DeLisle 2010-12-19 17:47:54 UTC --- Putting the Fortran standard aside for a moment, it seems reasonable to me that we do something about this bug, even if it is as an extension. I have assigned to myself and will give it some thought before I suggest a solution. Thanks for the report.
[Bug fortran/47042] New: ICE with character pointer in function
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47042 Summary: ICE with character pointer in function Product: gcc Version: 4.6.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran AssignedTo: unassig...@gcc.gnu.org ReportedBy: jvdeli...@gcc.gnu.org I am not sure this is valid code, but it gives and ICE. There is no ICE if the ptmp pointer is removed or the function is compiled outside the program block. program bug contains function get_cstring (c_str, maxlen, c_term_char) use iso_c_binding, only: c_ptr, c_char, c_null_char character(kind=c_char, len=maxlen) :: get_cstring character(kind=c_char,len=1), optional :: c_term_char character(kind=c_char), pointer:: ptmp type(c_ptr):: c_str integer:: i, maxlen call c_f_pointer (c_str, ptmp) do i=1,maxlen get_cstring(i:i) = ptmp(i) if (ptmp(i) == c_null_char) goto 10 if (present(c_term_char).and.ptmp(i) == c_term_char) goto 10 end do return 10 continue end function end program
[Bug fortran/46703] Wrong I/O output (only) when running under valgrind
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46703 --- Comment #3 from Jerry DeLisle 2010-12-27 01:03:55 UTC --- -ffloat-store is the first thing I tried and no change. However, the run-time side, libgfortran, is not compiled normally with -ffloat-store so maybe we should try that.
[Bug fortran/47051] [4.6 Regression] wrong reallocate
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47051 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot ||gnu.org --- Comment #7 from Jerry DeLisle 2010-12-30 03:19:55 UTC --- Whys is this a regression? When did it work last?
[Bug libfortran/47154] [4.6 Regression] END= does not work in namelist read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47154 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot ||gnu.org AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org --- Comment #2 from Jerry DeLisle 2011-01-03 14:40:26 UTC --- I will work on this one.
[Bug libfortran/47154] [4.6 Regression] END= does not work in namelist read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47154 --- Comment #3 from Jerry DeLisle 2011-01-04 05:17:18 UTC --- Created attachment 22893 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=22893 A proposed patch The regression was caused by: http://gcc.gnu.org/viewcvs?view=revision&revision=166180 I have attached a patch that passes our current namelist tests. The problem is that we were getting more than one call to generate_error, interfering with the END handler in error.c and even trashing some error messages.
[Bug libfortran/47154] [4.6 Regression] END= does not work in namelist read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47154 --- Comment #4 from Jerry DeLisle 2011-01-04 14:24:56 UTC --- The patch passes regression testing. I will commit tonight with ChangeLog and test case if someone can approve.
[Bug libfortran/47154] [4.6 Regression] END= does not work in namelist read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47154 --- Comment #6 from Jerry DeLisle 2011-01-04 18:24:19 UTC --- Thanks Janne, You are absolutely right, the multiple hit_eof's which call the generate_error. So far I do not think we need to fix anything in hit_eof. Thanks for review.
[Bug libfortran/47154] [4.6 Regression] END= does not work in namelist read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47154 --- Comment #7 from Jerry DeLisle 2011-01-05 03:53:23 UTC --- Author: jvdelisle Date: Wed Jan 5 03:53:15 2011 New Revision: 168502 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168502 Log: 2011-01-04 Jerry DeLisle PR libgfortran/47154 * io/list_read.c (namelist_read): Remove calls to hit_eof to avoid the duplicate calls via next_record. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/list_read.c
[Bug libfortran/47154] [4.6 Regression] END= does not work in namelist read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47154 --- Comment #8 from Jerry DeLisle 2011-01-05 04:18:43 UTC --- Author: jvdelisle Date: Wed Jan 5 04:18:39 2011 New Revision: 168503 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168503 Log: 2011-01-04 Jerry DeLisle PR libgfortran/47154 * gfortran.dg/namelist_68.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/namelist_68.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug libfortran/47154] [4.6 Regression] END= does not work in namelist read
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47154 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||FIXED --- Comment #9 from Jerry DeLisle 2011-01-05 04:24:48 UTC --- Fixed
[Bug fortran/47204] [4.6 Regression] [OOP] ICE: SIGSEGV in gfc_free_namespace (symbol.c:3323) on invalid code
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47204 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot ||gnu.org --- Comment #3 from Jerry DeLisle 2011-01-07 17:52:22 UTC --- Paul, I think its the one liner at the top of the PR, comment #0
[Bug fortran/47240] [F03] segfault with procedure pointer component
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47240 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot ||gnu.org --- Comment #13 from Jerry DeLisle 2011-01-13 05:28:03 UTC --- Confirmed at 168737 $ gfc -c -O2 red.f90 red.f90: In function ‘gp’: red.f90:67:0: error: non-trivial conversion at assignment void (*) (void) void (*) (struct array1_unknown &, integer(kind=4), struct array1_integer(kind=4) & restrict) __result_gp_72 = make_mess; red.f90:67:0: internal compiler error: verify_stmts failed Looks like an optimization bug.
[Bug fortran/37829] Incorrect name mangling with iso_c_binding
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=37829 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot ||gnu.org Known to fail|| --- Comment #16 from Jerry DeLisle 2011-01-13 05:46:01 UTC --- >From c.l.f James Van Buskirk; Elusive bug PR37829 That bug bugs me so bad and it's hard to reproduce, but I found a trigger: C:\gfortran\clf\opengl2>type bug1.f90 module m3 use ISO_C_BINDING implicit none private public kill_C_PTR interface function kill_C_PTR() bind(C) import implicit none type(C_PTR) kill_C_PTR end function kill_C_PTR end interface public kill_C_FUNPTR interface function kill_C_FUNPTR() bind(C) import implicit none type(C_FUNPTR) kill_C_FUNPTR end function kill_C_FUNPTR end interface end module m3 module m1 use m3 end module m1 program X use m1 use ISO_C_BINDING implicit none type(C_PTR) cp type(C_FUNPTR) fp integer(C_INT),target :: i interface function fun() bind(C) use ISO_C_BINDING implicit none real(C_FLOAT) fun end function fun end interface cp = C_NULL_PTR cp = C_LOC(i) fp = C_NULL_FUNPTR fp = C_FUNLOC(fun) end program X function fun() bind(C) use ISO_C_BINDING implicit none real(C_FLOAT) fun fun = 1.0 end function fun function kill_C_PTR() bind(C) use ISO_C_BINDING implicit none type(C_PTR) kill_C_PTR integer(C_INT), pointer :: p allocate(p) kill_C_PTR = C_LOC(p) end function kill_C_PTR function kill_C_FUNPTR() bind(C) use ISO_C_BINDING implicit none type(C_FUNPTR) kill_C_FUNPTR interface function fun() bind(C) use ISO_C_BINDING implicit none real(C_FLOAT) fun end function fun end interface kill_C_FUNPTR = C_FUNLOC(fun) end function kill_C_FUNPTR C:\gfortran\clf\opengl2>gfortran bug1.f90 -obug1 bug1.f90:44.8: cp = C_NULL_PTR 1 Error: Can't convert TYPE(_gfortran_iso_c_binding_c_ptr) to TYPE(c_ptr) at (1) bug1.f90:45.8: cp = C_LOC(i) 1 Error: Can't convert TYPE(_gfortran_iso_c_binding_c_ptr) to TYPE(c_ptr) at (1) bug1.f90:46.8: fp = C_NULL_FUNPTR 1 Error: Can't convert TYPE(_gfortran_iso_c_binding_c_funptr) to TYPE(c_funptr) at (1) bug1.f90:47.8: fp = C_FUNLOC(fun) 1 Error: Can't convert TYPE(_gfortran_iso_c_binding_c_funptr) to TYPE(c_funptr) at (1) bug1.f90:63.16: kill_C_PTR = C_LOC(p) 1 Error: Can't convert TYPE(_gfortran_iso_c_binding_c_ptr) to TYPE(c_ptr) at (1) bug1.f90:77.19: kill_C_FUNPTR = C_FUNLOC(fun) 1 Error: Can't convert TYPE(_gfortran_iso_c_binding_c_funptr) to TYPE(c_funptr) at (1) It's the use of a function with result of TYPE(C_PTR) that kills C_PTR subsequently and similarly the function with a result of TYPE(C_FUNPTR) kills off C_FUNPTR. Abstract interfaces do the trick as well as interfaces to realized functions. Note that directly USEing module m3 in program X above isn't sufficient to trigger the bug: m3 needs to be USEd in intermediate module m1 which then is USEd in program X. It's hard to set this one off, but when you do, look out! Note that the last two failures occur in external functions that don't even USE module m3 or m1 directly or indirectly, yet they still fall victim once the compiler has come off the rails.
[Bug fortran/47267] array constructor causing long compile times
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47267 Jerry DeLisle changed: What|Removed |Added AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org --- Comment #3 from Jerry DeLisle 2011-01-13 19:33:25 UTC --- I think currently we use the limit for parameter arrays to not simplify at compile time. We do not do this for non parameter arrays. I will look into it further.
[Bug libfortran/47285] G format outputs wrong number of characters when decimal supplied in literal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47285 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.14 02:13:18 CC||jvdelisle at gcc dot ||gnu.org AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jerry DeLisle 2011-01-14 02:13:18 UTC --- I will have a go of it.
[Bug fortran/47296] I/O Segfault when running out of file descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47296 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.14 19:52:52 AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org Ever Confirmed|0 |1 --- Comment #2 from Jerry DeLisle 2011-01-14 19:52:52 UTC --- I will take this one.
[Bug libfortran/47285] G format outputs wrong number of characters when decimal supplied in literal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47285 --- Comment #3 from Jerry DeLisle 2011-01-14 20:01:18 UTC --- *** Bug 47284 has been marked as a duplicate of this bug. ***
[Bug libfortran/47284] G format outputs wrong number of asterixes
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47284 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |RESOLVED Resolution||DUPLICATE --- Comment #2 from Jerry DeLisle 2011-01-14 20:01:18 UTC --- This is actually the same bug as 47285. I am developing a more diverse test case as I work it. The exact spot is in write_float.def. Surprising sometimes how long we go before these show up. :) Thanks for bug reports. *** This bug has been marked as a duplicate of bug 47285 ***
[Bug fortran/47296] I/O Segfault when running out of file descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47296
--- Comment #3 from Jerry DeLisle 2011-01-15
06:33:15 UTC ---
This is easy enough and if you study the code path, it makes sense. The error
flag returned here is passed up the call chain where an "os" error is
generated. When attempting to open a temporary file, if the file open fails,
the file name in the opp structure is not set, so it is NULL.
Index: unix.c
===
--- unix.c(revision 168773)
+++ unix.c(working copy)
@@ -1000,6 +1000,8 @@
int
unpack_filename (char *cstring, const char *fstring, int len)
{
+ if (fstring == NULL)
+return 1;
len = fstrlen (fstring, len);
if (len >= PATH_MAX)
return 1;
The result:
At line 39 of file pr47296.f90 (unit = 27, file = '')
Fortran runtime error: Too many open files
I will commit this as obvious shortly if regression testing passes. I can not
imagine it causing a problem.
In the meantime, I will see if i can test on a Windows based system, to see if
it works or if there is another issue.
[Bug fortran/47296] I/O Segfault when running out of file descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47296 --- Comment #4 from Jerry DeLisle 2011-01-15 06:42:33 UTC --- Author: jvdelisle Date: Sat Jan 15 06:42:30 2011 New Revision: 168832 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168832 Log: 2011-01-14 Jerry DeLisle PR libgfortran/47296 * io/unix.c (unpack_filename): Return non-zero if the filename passed in is NULL. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/unix.c
[Bug fortran/47296] I/O Segfault when running out of file descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47296 --- Comment #7 from Jerry DeLisle 2011-01-15 18:16:33 UTC --- Unpatched on Cygwin on Windows 7, I do not get the segfault. I also do not get the OS error. The assign error mechanism of the test case picks up that there is a problem. The windows version does not give an error and sets the tempfile name string even though no file is opened. I am doing a rebuild to latest trunk on the Win7 box, so when that is done, I will see what mechanism we need to error out on this.
[Bug fortran/47296] I/O Segfault when running out of file descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47296
--- Comment #9 from Jerry DeLisle 2011-01-16
08:29:55 UTC ---
After getting Win7-cygwin build of gcc latest trunk built, I was able to do
some more testing. I could then reproduce another segfault. As Janne
suggested and I certainly agree, the following simple patch clears this second
segfault. It is interesting that the Windows/cygwin execution behaves
differently and the opp->file somewhere is getting touched or not initialized.
Index: unix.c
===
--- unix.c(revision 168844)
+++ unix.c(working copy)
@@ -1085,7 +1085,11 @@
#endif /* HAVE_MKSTEMP */
if (fd < 0)
-free (template);
+{
+ free (template);
+ opp->file = NULL;
+ opp->file_len = 0;
+}
else
{
opp->file = template;
I will commit this sometime tomorrow.
[Bug fortran/47296] I/O Segfault when running out of file descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47296 --- Comment #11 from Jerry DeLisle 2011-01-17 05:59:15 UTC --- No more segfault on Cygwin, it should be good. Thanks.
[Bug fortran/28397] Check format mismatches at compile time
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=28397 Jerry DeLisle changed: What|Removed |Added Status|NEW |ASSIGNED CC||jvdelisle at gcc dot ||gnu.org AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org --- Comment #2 from Jerry DeLisle 2011-01-17 20:06:02 UTC --- gathering up some of these format related PRs into my pile since they are all related.
[Bug fortran/27436] gfortran: Abort compiling if there are insufficient data descriptors in format after reversion
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27436 Jerry DeLisle changed: What|Removed |Added Status|NEW |ASSIGNED CC||jvdelisle at gcc dot ||gnu.org AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org --- Comment #2 from Jerry DeLisle 2011-01-17 20:07:10 UTC --- Adding to my list
[Bug fortran/45129] I/O edit descriptors: Warn if the format field is too small for the E and F edit descriptor
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45129 Jerry DeLisle changed: What|Removed |Added Status|NEW |ASSIGNED AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org --- Comment #5 from Jerry DeLisle 2011-01-17 20:09:05 UTC --- Adding to my list
[Bug fortran/43062] NAMELIST attribute conflicts with ALLOCATABLE attribute
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43062 --- Comment #21 from Jerry DeLisle 2011-01-18 13:27:48 UTC --- It is not resolved because we are waiting for an interpretation from the Fortran standards committee on whether the test case is valid or invalid Fortran. If invalid, then we need to give an error, if valid, we need to make sure it works correctly. Unfortunately, this PR is in a waiting state.
[Bug libfortran/47285] G format outputs wrong number of characters when decimal supplied in literal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47285 --- Comment #4 from Jerry DeLisle 2011-01-22 13:53:52 UTC --- Created attachment 23076 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23076 A possible patch This patch seems to be acceptable. I add a try return value to output float to communicate when the field width is not successful. Oddly, I had to make an adjustment to the exponent width to take care of a case that returns successfully. if (e > 4)\ e = 4;\ This seems to work, but I wonder if I have a latent bug within. This patch does regression test OK. I thought I would let others play with it before I submit.
[Bug fortran/47296] I/O Segfault when running out of file descriptors
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47296 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #12 from Jerry DeLisle 2011-01-22 14:23:45 UTC --- Patch committed: Sendinglibgfortran/ChangeLog Sendinglibgfortran/io/unix.c Transmitting file data .. Committed revision 16. Thanks. Closing
[Bug fortran/47293] libquadmath: strtoflt128 - NAN not correctly read and C99 hex floating point format missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47293 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot ||gnu.org AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org --- Comment #2 from Jerry DeLisle 2011-01-22 14:25:52 UTC --- Taking this one
[Bug libfortran/47434] Wrong field width for NaN with (F0.n) formatting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47434 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2011.01.24 13:12:19 CC||jvdelisle at gcc dot ||gnu.org AssignedTo|unassigned at gcc dot |jvdelisle at gcc dot |gnu.org |gnu.org Ever Confirmed|0 |1 --- Comment #1 from Jerry DeLisle 2011-01-24 13:12:19 UTC --- I will investigate.
[Bug fortran/47293] libquadmath: strtoflt128 - NAN not correctly read and C99 hex floating point format missing
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47293 --- Comment #3 from Jerry DeLisle 2011-01-26 05:45:35 UTC --- I think this fixes it. Why it was whacked, who knows. Index: gd_qnan.h === --- gd_qnan.h(revision 169141) +++ gd_qnan.h(working copy) @@ -2,9 +2,9 @@ #define d_QNAN0 0x0 #define d_QNAN1 0xfff8 #define ld_QNAN0 0x0 -#define ld_QNAN1 0xc000 -#define ld_QNAN2 0x -#define ld_QNAN3 0x0 +#define ld_QNAN1 0x0 +#define ld_QNAN2 0x0 +#define ld_QNAN3 0x8000 #define ldus_QNAN0 0x0 #define ldus_QNAN1 0x0 #define ldus_QNAN2 0x0 Test program I used. Try this without the patch and it is very obvious what is wrong. character(len=200) :: str real(16) :: r, x, y, z integer(16) :: k x = 0.0 y = 0.0 r = 1.0 str = 'NAN' ; read(str,*) r print *, r z = x/y print *, z k = transfer(z,k) print "(b128)", k print * k = transfer(r,k) print "(b128)", k end
[Bug libfortran/47285] G format outputs wrong number of characters when decimal supplied in literal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47285 --- Comment #5 from Jerry DeLisle 2011-01-27 02:16:23 UTC --- Author: jvdelisle Date: Thu Jan 27 02:16:18 2011 New Revision: 169320 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=169320 Log: 2011-01-26 Jerry DeLisle PR libgfortran/47285 * io/write_float.def (output_float): Return SUCCESS or FAILURE and use the result to set the padding. Modified: trunk/libgfortran/ChangeLog trunk/libgfortran/io/write_float.def
[Bug libfortran/47285] G format outputs wrong number of characters when decimal supplied in literal
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47285 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution||FIXED --- Comment #6 from Jerry DeLisle 2011-01-27 02:20:02 UTC --- Fixed on trunk, closing.
[Bug libfortran/47434] Wrong field width for NaN with (F0.n) formatting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47434 --- Comment #3 from Jerry DeLisle 2011-01-27 12:47:04 UTC --- I agree to fix the NaN case. I have the patch already. Regarding the other cases: The copy of the F2008 standard I have says in 10.7.2.3.2 F editing: "When w is zero, the processor selects the field width." I also see this: "Leading zeros are not permitted except for an optional zero immediately to the left of the decimal symbol if the magnitude of the value in the output field is less than one." Similarly for the '+' sign on Inf. Until now we have chosen to emit the optional characters.
[Bug libfortran/47434] Wrong field width for NaN with (F0.n) formatting
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=47434 --- Comment #7 from Jerry DeLisle 2011-01-27 16:35:13 UTC --- I remember the discussion when we first implemented this and we wanted the + on Inf to be consistent with -Inf. Oh well, if folks really feel strongly about this, I can change it all. Hmm, I think I will add the optional NaN type field so now the smallest I can fit will be quite a bit wider then 3. (Just kidding ;) )
