[Bug fortran/114827] Valgrind reports errors with class(*) assignment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114827 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #2 from Jerry DeLisle --- Have you tried configuring gcc with --enable-valgrind-annotations and see what results this gives?
[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426 --- Comment #8 from Jerry DeLisle --- Martin or Matt, Can you test the following variation to see if you get better results. return st; } retval = NULL; if (c <= 0) retval = find_symbol (st->left, name, module, generic); if (c > 0 && retval == NULL) retval = find_symbol (st->right, name, module, generic); if (c > 0 && retval == NULL) retval = find_symbol (st->left, name, module, generic); if (c <= 0 && retval == NULL) retval = find_symbol (st->right, name, module, generic); return retval; This does pass regression testing but I do not think it guarantees better results. Apparently the value of c does not guarantee a find going left or right.
[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426
Jerry DeLisle changed:
What|Removed |Added
Last reconfirmed||2024-04-24
Status|UNCONFIRMED |NEW
Ever confirmed|0 |1
--- Comment #7 from Jerry DeLisle ---
With the proposed patch, the following test case fails.
! { dg-do compile }
! { dg-options "-fsecond-underscore" }
! PR fortran/95689 - ICE in check_sym_interfaces, at fortran/interface.c:2015
module m2345678901234567890123456789012345678901234567890123456789_123
type t2345678901234567890123456789012345678901234567890123456789_123
end type
interface
module subroutine
s2345678901234567890123456789012345678901234567890123456789_123 &
(x2345678901234567890123456789012345678901234567890123456789_123)
end
end interface
end
submodule(m2345678901234567890123456789012345678901234567890123456789_123) &
t2345678901234567890123456789012345678901234567890123456789_123
end
$ gfc -c -fsecond-underscore pr95689.f90
pr95689.f90:14:74:
14 |
submodule(m2345678901234567890123456789012345678901234567890123456789_123) &
|
1
Error: Name ‘t2345678901234567890123456789012345678901234567890123456789_123’
at (1) is an ambiguous reference to
‘m2345678901234567890123456789012345678901234567890123456789_123.t2345678901234567890123456789012345678901234567890123456789_123’
from current program unit
[Bug fortran/98426] find_symbol in module.c traverses O(N) part of a search tree
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98426 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #6 from Jerry DeLisle --- HI Matt, I can try your patch and if all tests clean I will request for it to be approved and I can push it. We have all been rather busy and short handed.
[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #35 from Jerry DeLisle --- Fixed on 13 and mainline (14)
[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 Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #40 from Jerry DeLisle --- Fixed on 13 and mainline (14)
[Bug libfortran/114618] Format produces incorrect output when contains 1x, ok when uses " "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618 --- Comment #6 from Jerry DeLisle --- Created attachment 57965 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57965=edit Preliminary patch to fix several issues. The attached patch is very preliminary and appears to fix the X format issue and does some code factoring. I have yet to explore the same situation with TR following the 19 '.' printed. This also fixes the problem with embedded garbage in the output. It does regression test with the new test cases, so getting close.
[Bug libfortran/114618] Format produces incorrect output when contains 1x, ok when uses " "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618 Jerry DeLisle changed: What|Removed |Added Status|REOPENED|NEW Depends on||113897, 109358 Referenced Bugs: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 [Bug 109358] Wrong formatting with T-descriptor during stream output https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113897 [Bug 113897] Consecutive tab and/or nX edits in format are not processed correctly.
[Bug libfortran/114618] Format produces incorrect output when contains 1x, ok when uses " "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
--- Comment #5 from Jerry DeLisle ---
A further reduction:
program tryit
implicit none
integer, parameter :: wp = kind(0d0)
real(kind=wp) :: pi =
3.14159265358979323846264338327950288419716939937510582097494459230_wp
character(40) gen1
character(40) gen2
gen1 = '(19("."),t1,g0,1x,t21,g0)'
gen2 = '(19("."),t1,g0," ",t21,g0)'
write (*, gen1) 'RADIX', radix(pi)
write (*, gen1) 'RANGE', range(pi)
write (*,'(80("-"))')
write (*, gen2) 'RADIX', radix(pi)
write (*, gen2) 'RANGE', range(pi)
end program tryit
This is indeed ugly. Note the embedded NULLs.
$ ./a.out >newdata
$ xxd newdata
: 5241 4449 582e 2e2e 2e2e 2e2e 2e2e 2e2e RADIX...
0010: 2e2e 2e00
0020: 0020 320a 5241 4e47 452e 2e2e 2e2e 2e2e . 2.RANGE...
0030: 2e2e 2e2e 2e2e 2e00
0040: 0020 3330 370a 2d2d 2d2d 2d2d . 307.--
0050: 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d
0060: 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d
0070: 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d
0080: 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d 2d2d
0090: 2d2d 2d2d 2d2d 2d2d 2d2d 0a52 4144 4958 --.RADIX
00a0: 202e 2e2e 2e2e 2e2e 2e2e 2e2e 2e2e 2032 . 2
00b0: 0a52 414e 4745 202e 2e2e 2e2e 2e2e 2e2e .RANGE .
00c0: 2e2e 2e2e 2033 3037 0a 307.
[Bug libfortran/114618] Format produces incorrect output when contains 1x, ok when uses " "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618
Jerry DeLisle changed:
What|Removed |Added
Status|RESOLVED|REOPENED
Resolution|DUPLICATE |---
Ever confirmed|0 |1
Last reconfirmed||2024-04-14
--- Comment #4 from Jerry DeLisle ---
Reopening this. I started working on the 'duplicate' portion of this which is
the 1X vs ' ' portion of it. Then I realized the first sets of output have a
bunch of garbage in the output. My first thought was the allocatable strings
aspect of this.
I reduced this by removing those aspects of the original post to get the
following.
program tryit
implicit none
integer, parameter :: wp = kind(0d0)
real(kind=wp) :: pi =
3.14159265358979323846264338327950288419716939937510582097494459230_wp
character(40) gen1
character(40) gen2
gen1 = '(19("."),t1,g0,1x,t21,g0)'
gen2 = '(19("."),t1,g0," ",t21,g0)'
write (*, gen1) 'PI', pi
write (*, gen1) 'REAL(PI)', real(pi)
write (*, gen1) 'DBLE(PI)', dble(pi)
write (*, gen1) 'RADIX', radix(pi)
write (*, gen1) 'RANGE', range(pi)
write (*, gen1) 'PRECISION', precision(pi)
write (*,'(80("-"))')
write (*, gen2) 'PI', pi
write (*, gen2) 'REAL(PI)', real(pi)
write (*, gen2) 'DBLE(PI)', dble(pi)
write (*, gen2) 'RADIX', radix(pi)
write (*, gen2) 'RANGE', range(pi)
write (*, gen2) 'PRECISION', precision(pi)
write (*,'(80("-"))')
end program tryit
Which gives:
$ ./a.out
PI. 3.1415926535897931
REAL(PI)... 3.14159274
DBLE(PI)... 3.1415926535897931
RADIX.. 3. 2
RANGE.. 3. 307
PRECISION.. 15
PI 3.1415926535897931
REAL(PI) .. 3.14159274
DBLE(PI) .. 3.1415926535897931
RADIX . 2
RANGE . 307
PRECISION . 15
I will focus on the 1X vs ' ' aspect of this as it fits into the 113897 that I
am currently working.
[Bug libfortran/107031] endfile truncates file at wrong position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #11 from Jerry DeLisle --- Fixed on trunk, closing.
[Bug fortran/56744] [meta-bug] Namelist bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56744 Bug 56744 depends on bug 107068, which changed state. Bug 107068 Summary: Run-time error when reading logical arrays with a namelist https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libfortran/107068] Run-time error when reading logical arrays with a namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #10 from Jerry DeLisle --- Fixed on trunk. Closing.
[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304 --- Comment #33 from Jerry DeLisle --- (In reply to Tobias Burnus from comment #30) > (In reply to rguent...@suse.de from comment #29) > > Might be for \r\n line endings? > > New lines are handled slightly differently – and \f and \v don't seem to be > handled at all. > > Comparing the result with ifort/ifx/flang, they handle a bare '\r' (in > contrast to \r\n) at fewer places than gfortran – albeit from the code it > looks as if a \r not followed by \n is not handled consistently either. > --- snip --- Initially we primarily handled /n and I recall having to do a number of places to take care of the \r\n because Microsoft allegedly chose to not follow the standards of the day and did the \r/\n. One can argue about that since some of the old teletypes needed the \n to roll the paper after the carriage return. ;) We have never done anything with \f or \v .
[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304 --- Comment #32 from Jerry DeLisle --- (In reply to Tobias Burnus from comment #28) > Created attachment 57896 [details] > Testcase > --- snip --- > I think we need at least an "|| c == '\t'"; I guess '\r' isn't really > required here, or is it? The particular snippit that broke the tab is only executed at the beginning read of the first effective item so we dont need anythin else at this spot.
[Bug libfortran/113897] Consecutive tab and/or nX edits in format are not processed correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113897 Jerry DeLisle changed: What|Removed |Added CC||urbanjost at comcast dot net --- Comment #3 from Jerry DeLisle --- *** Bug 114618 has been marked as a duplicate of this bug. ***
[Bug libfortran/114618] Format produces incorrect output when contains 1x, ok when uses " "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618 Jerry DeLisle changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #3 from Jerry DeLisle --- It is a duplicate of 113897 which I am still workimng on as i get time. *** This bug has been marked as a duplicate of bug 113897 ***
[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
Ever confirmed|0 |1
Status|UNCONFIRMED |NEW
CC||jvdelisle at gcc dot gnu.org
Last reconfirmed||2024-04-07
--- Comment #1 from Jerry DeLisle ---
Here is a fix. It wiggles on about 5 test cases that will need to be adjusted.
diff --git a/gcc/fortran/io.cc b/gcc/fortran/io.cc
index 6fd69f7c9a8..e6a5144b028 100644
--- a/gcc/fortran/io.cc
+++ b/gcc/fortran/io.cc
@@ -1129,12 +1129,10 @@ data_desc:
break;
case FMT_H:
- if (!(gfc_option.allow_std & GFC_STD_GNU) && !inhibit_warnings)
+ if (!gfc_notify_std (GFC_STD_F95_DEL, "H format specifier at %C"))
{
if (mode != MODE_FORMAT)
format_locus.nextc += format_string_pos;
- gfc_warning (0, "The H format specifier at %L is"
- " a Fortran 95 deleted feature", _locus);
}
if (mode == MODE_STRING)
{
[Bug libfortran/114618] Format produces incorrect output when contains 1x, ok when uses " "
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114618 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #2 from Jerry DeLisle --- Possibly a dup. I will try to get a closer look later today.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #37 from Jerry DeLisle --- Created attachment 57855 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57855=edit Preliminary patch to address some incorrect behavior This attached patch, gives some better results for the testcase in the previous commenr. $ ./a.out comma, isreal = F, testinput = ; n= 42 ios=0 point, isreal = F, testinput = ; n= 42 ios=0 comma, isreal = F, testinput = , n= 42 ios= 5010 point, isreal = F, testinput = , n= 42 ios=0 comma, isreal = F, testinput = . n= 42 ios= 5010 point, isreal = F, testinput = . n= 42 ios= 5010 comma, isreal = F, testinput = 5. n= 42 ios= 5010 point, isreal = F, testinput = 5. n= 42 ios= 5010 comma, isreal = F, testinput = 5, n= 42 ios= 5010 point, isreal = F, testinput = 5, n= 5 ios=0 comma, isreal = F, testinput = 5; n= 5 ios=0 point, isreal = F, testinput = 5; n= 5 ios=0 comma, isreal = F, testinput =7 . n= 7 ios=0 point, isreal = F, testinput =7 . n= 7 ios=0 comma, isreal = F, testinput =7 , n= 7 ios=0 point, isreal = F, testinput =7 , n= 7 ios=0 comma, isreal = F, testinput =7 ; n= 7 ios=0 point, isreal = F, testinput =7 ; n= 7 ios=0 comma, isreal = T, testinput = 8. r= 42.00 ios= 5010 point, isreal = T, testinput = 8. r= 8.00 ios=0 comma, isreal = T, testinput = 8, r= 8.00 ios=0 point, isreal = T, testinput = 8, r= 8.00 ios=0 comma, isreal = T, testinput = 8; r= 8.00 ios=0 point, isreal = T, testinput = 8; r= 8.00 ios=0 comma, isreal = T, testinput =9 . r= 9.00 ios=0 point, isreal = T, testinput =9 . r= 9.00 ios=0 comma, isreal = T, testinput =9 , r= 9.00 ios=0 point, isreal = T, testinput =9 , r= 9.00 ios=0 comma, isreal = T, testinput =9 ; r= 9.00 ios=0 point, isreal = T, testinput =9 ; r= 9.00 ios=0 comma, isreal = T, testinput = 3,3. r= 42.00 ios= 5010 point, isreal = T, testinput = 3.3. r= 42.00 ios= 5010 comma, isreal = T, testinput = 3,3, r= 42.00 ios= 5010 comma, isreal = T, testinput = 3,3; r= 3.30 ios=0 point, isreal = T, testinput = 3.3; r= 3.30 ios=0 comma, isreal = T, testinput = 4,4 . r= 4.40 ios=0 point, isreal = T, testinput = 4.4 . r= 4.40 ios=0 comma, isreal = T, testinput = 4,4 , r= 4.40 ios=0 point, isreal = T, testinput = 4.4 , r= 4.40 ios=0 comma, isreal = T, testinput = 4,4 ; r= 4.40 ios=0 point, isreal = T, testinput = 4.4 ; r= 4.40 ios=0
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #36 from Jerry DeLisle --- Created attachment 57854 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57854=edit Modified extended test case I modified the extended test case so I could review this and summarize. Currently this is what we get with my comments at the end of each line. I marked some that I think are clearly incorrect. Maybe OK depends on on strictly one chooses to interpret what the standard says. If we assume that one or more spaces is an acceptable separator if followed by a non-value I indicate those with the word space. comma, isreal = F, testinput = ; n= 42 ios=0 OK, null read point, isreal = F, testinput = ; n= 42 ios=0 maybe OK comma, isreal = F, testinput = , n= 42 ios= 5010 OK, error point, isreal = F, testinput = , n= 42 ios=0 OK, null read comma, isreal = F, testinput = . n= 42 ios= 5010 OK, error point, isreal = F, testinput = . n= 42 ios= 5010 OK, error comma, isreal = F, testinput = 5. n= 42 ios= 5010 OK, error point, isreal = F, testinput = 5. n= 42 ios= 5010 OK, error comma, isreal = F, testinput = 5, n= 42 ios= 5010 OK, error point, isreal = F, testinput = 5, n= 5 ios=0 OK, good read comma, isreal = F, testinput = 5; n= 5 ios=0 OK, good read point, isreal = F, testinput = 5; n= 5 ios=0 maybe OK comma, isreal = F, testinput =7 . n= 7 ios=0 OK, good read space point, isreal = F, testinput =7 . n= 7 ios=0 OK, good read space comma, isreal = F, testinput =7 , n= 42 ios= 5010 Incorrect point, isreal = F, testinput =7 , n= 7 ios=0 OK, good read comma, isreal = F, testinput =7 ; n= 7 ios=0 OK, good read space point, isreal = F, testinput =7 ; n= 7 ios=0 OK, good read space comma, isreal = T, testinput = 8. r= 42.00 ios= 5010 OK, error point, isreal = T, testinput = 8. r= 8.00 ios=0 OK, good read comma, isreal = T, testinput = 8, r= 8.00 ios=0 OK, good read point, isreal = T, testinput = 8, r= 8.00 ios=0 OK, good read comma, isreal = T, testinput = 8; r= 8.00 ios=0 OK, good read point, isreal = T, testinput = 8; r= 8.00 ios=0 maybe OK comma, isreal = T, testinput =9 . r= 9.00 ios=0 OK, good read space point, isreal = T, testinput =9 . r= 9.00 ios=0 OK, good read space comma, isreal = T, testinput =9 , r= 9.00 ios= 5010 Incorrect, space? point, isreal = T, testinput =9 , r= 9.00 ios=0 OK, good read comma, isreal = T, testinput =9 ; r= 9.00 ios=0 OK, good read point, isreal = T, testinput =9 ; r= 9.00 ios=0 maybe OK comma, isreal = T, testinput = 3,3. r= 42.00 ios= 5010 OK, error point, isreal = T, testinput = 3.3. r= 42.00 ios= 5010 OK, error comma, isreal = T, testinput = 3,3, r= 42.00 ios= 5010 OK, error comma, isreal = T, testinput = 3,3; r= 3.30 ios=0 OK, good read point, isreal = T, testinput = 3.3; r= 3.30 ios=0 maybe OK comma, isreal = T, testinput = 4,4 . r= 4.40 ios=0 OK, good read space point, isreal = T, testinput = 4.4 . r= 4.40 ios=0 OK, goor read space comma, isreal = T, testinput = 4,4 , r= 4.40 ios= 5010 Incorrect, space? point, isreal = T, testinput = 4.4 , r= 4.40 ios=0 OK, good read comma, isreal = T, testinput = 4,4 ; r= 4.40 ios=0 OK, good read point, isreal = T, testinput = 4.4 ; r= 4.40 ios=0 OK, good read space I have a followup comment on this.
[Bug fortran/103368] [11/12/13 Regression] ICE in gimplify_expr, at gimplify.c:15668 since r12-4464-g017665f63047ce47
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103368 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #5 from Jerry DeLisle --- (In reply to anlauf from comment #4) > Seems to ICE no longer at r14-9759, but 13-branch and older still fail. > Adjusting summary. > > But is it really invalid code? Intel and NAG accept it. I am not getting an ICE here. Until sub is defined or further definitions on components to t or t2, I do not see a basis to reject anything or give a diagnostic.
[Bug testsuite/28032] gfortran.dg tests use dg-options with -On even though it is already torture tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=28032 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #7 from Jerry DeLisle --- I will take this one so I don't lose track of it while also looking at the double space behaviors in 'dg-do run' vs 'dg-do run'.
[Bug libquadmath/114533] libquadmath: printf: fix misaligned access on args
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114533 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #9 from Jerry DeLisle --- Adding myself here as I need hex format for gfortran EX format specifiers.
[Bug libfortran/107031] endfile truncates file at wrong position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031 --- Comment #9 from Jerry DeLisle --- The following trivial patch changes gfortran behavior and regression tests Ok on x86_64. I will see if I can come up with a test case to catch this. diff --git a/libgfortran/io/file_pos.c b/libgfortran/io/file_pos.c index 2bc05b293f8..d169961f997 100644 --- a/libgfortran/io/file_pos.c +++ b/libgfortran/io/file_pos.c @@ -352,7 +352,6 @@ st_endfile (st_parameter_filepos *fpp) dtp.common = fpp->common; memset (, 0, sizeof (dtp.u.p)); dtp.u.p.current_unit = u; - next_record (, 1); } unit_truncate (u, stell (u->s), >common);
[Bug libfortran/107031] endfile truncates file at wrong position
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107031 Jerry DeLisle changed: What|Removed |Added Status|WAITING |NEW Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org CC||jvdelisle at gcc dot gnu.org --- Comment #8 from Jerry DeLisle --- Thankyou for information, I will take a look.
[Bug libfortran/106295] INQUIRE statement bus error at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106295 --- Comment #7 from Jerry DeLisle --- I don't think that is a bad idea. I realize that this comes up often enough to consider some solution.
[Bug fortran/80012] FIXME in diagnostic "%s procedure at %L is already declared as %s procedure" from symbol.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80012 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #5 from Jerry DeLisle --- I have not looked at this in detail. Generally, you can do conditional errors depending on what -std=f a user specifies at compile time. So theoretically you can do two different errors depending on these options. Also look in the codes for examples of 'notify' or 'notification' to see ways to do these things. Another way is to build an error message with snprintf for example and use that string in the error message.
[Bug fortran/103715] [11/12/13/14 Regression] ICE in gfc_find_gsymbol, at fortran/symbol.c:4301 since r9-3803-ga5fbc2f36a291cbe
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103715 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #6 from Jerry DeLisle --- (In reply to anlauf from comment #5) > Obvious fix for the invalid read (untested): > If it test OK feel free to commit.
[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304 --- Comment #21 from Jerry DeLisle --- The following may be a helpful read. https://www.ibm.com/docs/en/openxl-fortran-aix/17.1.2?topic=formatting-value-separators I am auditing our list_read.c code for the various types. The NULL read plays into this. The process is complicated further by the use of repeat counts in front of values.
[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304 --- Comment #20 from Jerry DeLisle --- Some additional information from the 2023 standard. 13.10.3.1List-directed input forms 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 boundary, • the first nonblank character is not a quotation mark or an apostrophe, • the leading characters are not digits followed by an asterisk, and • the character sequence contains at least one character, the delimiting apostrophes or quotation marks are not required. If the delimiters are omitted, the character sequence is terminated by the first blank, comma (if the decimal edit mode is POINT), semicolon (if the decimal edit mode is COMMA), slash, or end of record; in this case apostrophes and quotation marks within the datum are not to be doubled. --- I am still digesting this and should have something sorted out in the next day or so.
[Bug libfortran/114304] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
--- Comment #17 from Jerry DeLisle ---
(In reply to Jeffrey A. Law from comment #16)
> Per c#12, c#13, c#14 & c#15, dropping the regression marker, but leaving
> open.
Interestingly, the remaining part of this bug is also a regression, it just
does not break LAPACK. Reverting this change fixes it which means the new test
for pr105473 will fail. I have an idea where to put this check in
read_complex() but I have not finished this and tested it.
Jeffrey, if you would like me to push this, let me know. We can mark
pr105473.f90 in the test suite to XFAIL or comment out the one check there that
fails.
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index fb3f7dbc34d..c178acd61a5 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -471,8 +471,6 @@ eat_separator (st_parameter_dt *dtp)
case ',':
if (dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
{
- generate_error (>common, LIBERROR_READ_VALUE,
- "Comma not allowed as separator with DECIMAL='comma'");
unget_char (dtp, c);
break;
}
[Bug fortran/114023] complex part%ref of complex named constant array cannot be used in an initialization expression.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114023 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2024-03-13 --- Comment #2 from Jerry DeLisle --- Steve, Anuj is interested in digging in on this one. This will be a learning experience.
[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304 --- Comment #15 from Jerry DeLisle --- (In reply to Tobias Burnus from comment #14) --- snip --- > The question is whether the following show give an error as shown above: > real :: x(3) > character(len=1) :: s > ... > write(99, '(a)') '1.23435 1243.24 13.24 ;' > read(99, *) x, s > > Or whether reading this line should work, i.e. reading ';' as character – as > it does with ifort and flang. > > Or in other words: > * Does ';' count as character, readable by list-directed formatted I/O? > (ifort, ifx, flang) > * Or doesn't it? (gfortran since at least 4.9) > This error caught my attention right away as being odd. With the regression part out of the way at the moment I will study this further. My initial thought is we have an eat_seprator out of place where we only need an eat_spaces. Regardless, I am looking into it.
[Bug libfortran/105456] Child I/O does not propage iostat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #8 from Jerry DeLisle --- Not planning any backport on this. Closing.
[Bug fortran/20585] [meta-bug] Fortran 2003 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=20585 Bug 20585 depends on bug 105456, which changed state. Bug 105456 Summary: Child I/O does not propage iostat https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug libfortran/105361] Incorrect end-of-file condition for derived-type I/O
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105361 Bug 105361 depends on bug 105456, which changed state. Bug 105456 Summary: Child I/O does not propage iostat https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #33 from Jerry DeLisle --- (In reply to Tobias Burnus from comment #32) > See PR114304 for an issue that was caused by the fix in comment 27. Reverted portion of offending commit to fix.
[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304 --- Comment #11 from Jerry DeLisle --- Created attachment 57676 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57676=edit Proposed patch This patch fixes the issue by reverting the troublesome hunk and regression tests OK on x86_64. The test case added for pr105473 still passes. I will add the test attached already to this PR to our test suite.
[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304 --- Comment #9 from Jerry DeLisle --- Patch on comment #8 breaks all sorts of things. Not so obvious. I will try reverting the original hunk from pr105473 and then work from there.
[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
--- Comment #8 from Jerry DeLisle ---
This gets around the bogus error and makes sense to me. However with your
reduced test case I get and EOF error later. I also get this EOF witt gfortran
9. I have not checked 10, 11, or 12 yet.
If I can build lapack cleanly I will push this as sort of obvious.
$ git diff
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index e38e9a84976..c23c2bb2048 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -481,10 +481,10 @@ eat_separator (st_parameter_dt *dtp)
break;
case ';':
- if (dtp->u.p.current_unit->decimal_status == DECIMAL_POINT)
+ if (dtp->u.p.current_unit->decimal_status == DECIMAL_COMMA)
{
generate_error (>common, LIBERROR_READ_VALUE,
- "Semicolon not allowed as separator with DECIMAL='point'");
+ "Semicolon not allowed as separator with DECIMAL='comma'");
unget_char (dtp, c);
break;
}
[Bug libfortran/114304] [13/14 Regression] libgfortran I/O – bogus "Semicolon not allowed as separator with DECIMAL='point'"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114304 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-11 Ever confirmed|0 |1 --- Comment #7 from Jerry DeLisle --- I suppose we can put this error behind a -std= option. Just my luck it is discovered right after I backport to 13. The semi-colon in this case is intended to indicate the end of the line I think. I will have to did through the standards a but. If one is desperate to fix this and we need to revert on 13, let me know.
[Bug libfortran/93727] Fortran 2018: EX edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727
--- Comment #7 from Jerry DeLisle ---
(In reply to Thomas Henlich from comment #6)
--- snip ---
> Just some thoughts:
>
> Have you tried "%LA" for long double?
>
> Have you tried quadmath_snprintf
> (https://gcc.gnu.org/onlinedocs/libquadmath/quadmath_005fsnprintf.html) with
> "%QA" for quad precision?
That was the hint I needed.
#include
int main()
{
float x = 1.0f / 3.0f;
double y = 1.0l / 3.0l;
long double z = 1.0L / 3.0L;
printf(" FLOAT: %.18A\n", x);
printf(" DOUBLE: %.18lA\n", y);
printf("LONG DBL: %.18LA\n", z);
printf(" 123456789012345678901234567890\n");
printf(" FLOAT: %.20f\n", x);
printf(" DOUBLE: %.20lf\n", y);
printf("LONG DBL: %.20Lf\n", z);
}
$ gcc hexfloat.c
$ ./a.out
FLOAT: 0X1.56P-2
DOUBLE: 0X1.50P-2
LONG DBL: 0XA.AAB000P-5
123456789012345678901234567890
FLOAT: 0.3334326744079590
DOUBLE: 0.1483
LONG DBL: 0.3334
I will check the libqudmath version as well.
Thanks.
[Bug libfortran/93727] Fortran 2018: EX edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727 --- Comment #5 from Jerry DeLisle --- I have been studying this a bit by looking at the 2023 std and functionality of printf(). Specifically printf() provides the 'A' descriptor which can be used for float (kind=4) and double (kind=8). It will accept a long double (80 bit aka kind=10). I am noticing that the results of double and long double are identical, no extra precision visible. It is very possible I am not doing that correctly. I do not see anything related to quad precision floats. I am posting this as i think we will have to do some of our own translating byte portions of floats ourselves. Portability may be an issue. For example IBM 360 128bit precision or some other processor may not follow the same internal representations. Regardless I have preliminary code for the frontend that results in calling anew fucntion write_ex in transfer.c I think that kind=4 and kind=8 will be fine. Any thoughts on kind=10 or kind=16 I would appreciate as I further explore this.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #31 from Jerry DeLisle --- (In reply to john.harper from comment #30) > Thank you! > I encourage folks to move to gcc/gfortran 13. However, if you need it on 12, I can do so.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #29 from Jerry DeLisle --- Backported to 13 and closing.
[Bug fortran/110644] Error in gfc_format_decoder
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110644 --- Comment #13 from Jerry DeLisle --- Any luck getting a reduced case?
[Bug fortran/108680] Wrong DTIO arguments with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108680 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-03-06 Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 CC||jvdelisle at gcc dot gnu.org --- Comment #2 from Jerry DeLisle --- Taking a quick look at this one. Yes it handles -fdefault-integer-8 incorrectly. I agree with Steve in that this is not a Standard Fortran feature. The right way to allow changing kinds is to use a parameter defined with for example select_integer_kind in a module or something and have that parameter used everywhere. Obviously not conveniant. Regardless even if one declares integer 8 everywhere, the vlist is screwed up. Adding to my list.
[Bug fortran/109105] Error-prone format string building in resolve.cc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109105 Jerry DeLisle changed: What|Removed |Added Status|WAITING |NEW Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #4 from Jerry DeLisle --- So I don't lose it.
[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||jvdelisle at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #4 from Jerry DeLisle --- Triaging the list of 1300 gforran bugs and spotted this one, so getting on my list. (Especially since I have been buried in the related code).
[Bug libfortran/106295] INQUIRE statement bus error at runtime
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106295 Jerry DeLisle changed: What|Removed |Added Resolution|--- |INVALID CC||jvdelisle at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #5 from Jerry DeLisle --- I think this should be closed. Dont mix libraries.
[Bug libfortran/93727] Fortran 2018: EX edit descriptor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93727 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Severity|enhancement |normal CC||jvdelisle at gcc dot gnu.org
[Bug libfortran/93550] Implement control of leading zero in formatted numeric output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93550 --- Comment #4 from Jerry DeLisle --- The LEADING_ZERO specifiers are now included in the 2023 standard, so away we go! In support of lazy programmers lets make the compiler do it. ;)
[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141 --- Comment #9 from Jerry DeLisle --- --- snip --- > % gfcx -o z a.f90 > a.f90:5:6: > > 5 | x%im = 42 > | 1 > Error: 'x' at (1) associated to expression cannot be used in > a variable definition context (assignment) > > Mikael, thanks for the feedback. I'll see if I can fix > the parentheses case this weekend. This is definitely a 42 case, which is why I had three '?' in my reply. And if you understand this, you are OK in my book. :)
[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141 --- Comment #2 from Jerry DeLisle --- It looks like the 'selector' in this case is an expr. The expr must be a pointer object or a 'designator' A designator must be: R901 designator object-name array-element array-section coindexed-named-object complex-part-designator structure-component substring I am not seeing the expr in the example as one of these listed. ???
[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- I see the fail here but I am not sure of the validity. I am going to read the latest standard. I always thought of associate to refer associate complicated data references to make code more readable. In this case it is referring to a function which resolves to a constant. Interestingly if I wrap the associate with parens one gets: associate (x => (log(cmplx(-1,0 $ gfc pr114141.f90 pr114141.f90:6:14: 6 | y = x%im | 1 Error: The RE or IM part_ref at (1) must be applied to a COMPLEX expression
[Bug fortran/66499] Letters with accents change format behavior for X and T descriptors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66499 --- Comment #7 from Jerry DeLisle --- There two issues going on here. We do not interpret source code that is UTF-8 encoded. This is why in our current tests for UTF-8 encoding of data files we us hexidecimal codes. I will have to see what the standard says about non=ASCII character sets in source code. If I get around this by using something like this: char1 = 4_"Test without local char" char2 = 4_"Test with local char " char2(22:22) = 4_"Ã" char2(23:23) = 4_"Ã" $ ./a.out 23 23 1234567890123456789012345678901234567890 Test without local char 10. Test with local char ÃÃ10. The string lengths now match correctly. One can see the tabbing is still off. This is because the format buffer seek functions are byte oriented and when using UTF-8 encoding we need to seek the buffer differently. In fact we have to allocate it differently as well to maintain the four byte characters.
[Bug fortran/66499] Letters with accents change format behavior for X and T descriptors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66499
--- Comment #6 from Jerry DeLisle ---
This is an interesting puzzle. I took the -fdump-tree-original output of
compiling the test case and edited out all except the initialization of the two
variables char1 and char2.
I lined these up so we could see what each 4-byte character looks like. The
last two characters should be two characters of c383. We are generating c300
8300 for each character.
---
__builtin_memmove ((void *) , (void *) &"
T\x00\x00\x00
e\x00\x00\x00
s\x00\x00\x00
t\x00\x00\x00
\x00\x00\x00
w\x00\x00\x00
i\x00\x00\x00
t\x00\x00\x00
h\x00\x00\x00
o\x00\x00\x00
u\x00\x00\x00
t\x00\x00\x00
\x00\x00\x00
l\x00\x00\x00
o\x00\x00\x00
c\x00\x00\x00
a\x00\x00\x00
l\x00\x00\x00
\x00\x00\x00
c\x00\x00\x00
h\x00\x00\x00
a\x00\x00\x00
r\x00\x00"[1]{lb: 1 sz: 4}, 92);
__builtin_memmove ((void *) , (void *) &"
T\x00\x00\x00
e\x00\x00\x00
s\x00\x00\x00
t\x00\x00\x00
\x00\x00\x00
w\x00\x00\x00
i\x00\x00\x00
t\x00\x00\x00
h\x00\x00\x00
\x00\x00\x00
l\x00\x00\x00
o\x00\x00\x00
c\x00\x00\x00
a\x00\x00\x00
l\x00\x00\x00
\x00\x00\x00
c\x00\x00\x00
h\x00\x00\x00
a\x00\x00\x00
r\x00\x00\x00
\x00\x00\x00
\xc3\x00\x00\x00
\x83\x00\x00\x00
\xc3\x00\x00\x00
\x83\x00\x00"[1]{lb: 1 sz: 4}, 100);
[Bug libfortran/105456] Child I/O does not propage iostat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105456 --- Comment #4 from Jerry DeLisle --- Created attachment 57504 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57504=edit Proposed partial patch Proposed patch for the original test case with a READ function.
[Bug fortran/109358] Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 --- Comment #16 from Jerry DeLisle --- I think I was not being very clear when I opened pr113897. nX descriptors are very similar to TR code and I meeantt to take care of those in the 113897. The reason for the separate PR is that the problem is completely different than this one which is relates to the use of stream I/O. The consecutive tabs or spaces require looking ahead in the format string and effectively squashing these before writing the next actual data. This was my plan for PR113897.
[Bug libfortran/83282] missing comma in format changes output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83282 --- Comment #6 from Jerry DeLisle --- $ gfc -Wall -Werror -pedantic pr83282.f90 pr83282.f90:1:4: 1 |write(*,'(aa)') "ab", "bc" |1 Error: Unclassifiable statement at (1) This is not very useful either. :o
[Bug libfortran/83282] missing comma in format changes output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83282 --- Comment #5 from Jerry DeLisle --- With -std=f95 we get: $ gfc -std=f95 pr83282.f90 pr83282.f90:1:13: 1 |write(*,'(aa)') "ab", "bc" | 1 Error: GNU Extension: Missing comma at (1) pr83282.f90:2:17: 2 |write(*,'(a"bc")') "ab" | 1 Error: GNU Extension: Missing comma at (1) pr83282.f90:3:17: 3 |write(*,'(a"cd"a)') "ab", "bc" | 1 Error: GNU Extension: Missing comma at (1) and -pedantic gives: $ gfc -pedantic pr83282.f90 pr83282.f90:1:13: 1 |write(*,'(aa)') "ab", "bc" | 1 Warning: GNU Extension: Missing comma at (1) pr83282.f90:2:17: 2 |write(*,'(a"bc")') "ab" | 1 Warning: GNU Extension: Missing comma at (1) pr83282.f90:3:17: 3 |write(*,'(a"cd"a)') "ab", "bc" | 1 Warning: GNU Extension: Missing comma at (1) I wonder if we should reject the missing comma outright and only allow it for -std=legacy?
[Bug libfortran/107068] Run-time error when reading logical arrays with a namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107068
--- Comment #8 from Jerry DeLisle ---
After a bit of sleuthing it turns out that the '(' in the name was being
ignored and the comma in '(1,2)' was being treated as a delimiter. Since the
following '=' was not seen yet, the 2 was seen as a repeat value and we get the
error.
This is fixed with the following patch:
diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index f8ca64422de..0b7884fdda7 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -888,6 +888,14 @@ read_logical (st_parameter_dt *dtp, int length)
for(i = 0; i < 63; i++)
{
c = next_char (dtp);
+ if (c == '(')
+ {
+ l_push_char (dtp, c);
+ dtp->u.p.nml_read_error = 1;
+ dtp->u.p.line_buffer_enabled = 1;
+ dtp->u.p.line_buffer_pos = 0;
+ return;
+ }
if (is_separator(c))
{
/* All done if this is not a namelist read. */
[Bug fortran/105847] namelist-object-name can be a renamed host associated entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847 --- Comment #11 from Jerry DeLisle --- Having done all this, I found: C8102 (R868) The namelist-group-name shall not be a name accessed by use association. What does this mean in the context of renamed?
[Bug fortran/105847] namelist-object-name can be a renamed host associated entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847 --- Comment #9 from Jerry DeLisle --- This seems to work: /* Build the namelist object name. */ - - string = gfc_build_cstring_const (var_name); + if (sym && !sym->attr.use_only && sym->attr.use_rename) +string = gfc_build_cstring_const (sym->ns->use_stmts->rename->local_name); + else +string = gfc_build_cstring_const (var_name); Evidently the processing of the 'only' takes care of the renaming before we get here. Without the attr.use_only part namelist_use_only.f90 fails. With these tweaks there are no regressions and the test case here passes.
[Bug fortran/105847] namelist-object-name can be a renamed host associated entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847 --- Comment #8 from Jerry DeLisle --- There is an assert just above the patch that implies that sym can be NULL if c is not. With gdb I checked, and sure enough thats the failure point. I am testing with sym included in the condition.
[Bug fortran/105847] namelist-object-name can be a renamed host associated entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847 --- Comment #7 from Jerry DeLisle --- Steve, I am getting a boatload of regressions on this. I wonder if something in the sym structure needs to be guarded here. They appear to be segfaults. Can you take a look?
[Bug fortran/105847] namelist-object-name can be a renamed host associated entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847 --- Comment #6 from Jerry DeLisle --- I obviously did not get to this last May. Will try now.
[Bug libfortran/99210] X editing for reading file with encoding='utf-8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from Jerry DeLisle --- Fixed on main line. If someone needs a backport, let me know.
[Bug fortran/109358] Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #14 from Jerry DeLisle --- Fixed on trunk and 13
[Bug libfortran/99210] X editing for reading file with encoding='utf-8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210 --- Comment #7 from Jerry DeLisle --- Submitted for approval.
[Bug libfortran/99210] X editing for reading file with encoding='utf-8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210 --- Comment #6 from Jerry DeLisle --- I have reapplied the patch in comment #3 and it regression tests fine and appears to fix the issue. I have need to work up the test case and submit this for approval.
[Bug libfortran/99210] X editing for reading file with encoding='utf-8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org CC||jvdelisle at gcc dot gnu.org --- Comment #5 from Jerry DeLisle --- I need to keep an eye on this while working on related issues.
[Bug libfortran/113897] Consecutive tab edits in format are not processed correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113897 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2024-02-13 Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jerry DeLisle --- Adding to my list, but I do not see any priority needed for it.
[Bug libfortran/113897] New: Consecutive tab edits in format are not processed correctly.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113897 Bug ID: 113897 Summary: Consecutive tab edits in format are not processed correctly. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: libfortran Assignee: unassigned at gcc dot gnu.org Reporter: jvdelisle at gcc dot gnu.org Target Milestone: --- This issue found while working on pr109358. program tabs implicit none integer :: fd open(newunit=fd, file="test.txt", form="formatted") write(fd, "(a)") "12345678901234567890123456789" write(fd, "(i4, t25, t2, i4.4)") 1234, 0123 close(fd) end program tabs With gfortran gcc 10.4.1 20230121 (GCC) $ gfc10 -static -o tabs.x tabs.f90 $ ./tabs.x $ cat test.txt 12345678901234567890123456789 12340123 It seems to me this should be: 10123 Even though it is nonsensical to do this, it probably is valid. I will check the standards.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #38 from Jerry DeLisle --- Fixed on trunk and 13
[Bug fortran/85836] [meta-bug] Fortran 2018 support
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85836 Bug 85836 depends on bug 111022, which changed state. Bug 111022 Summary: ES0.0E0 format gave ES0.dE0 output with d too high. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #36 from Jerry DeLisle --- I was looking for my damnit doll until I got to your last post. Is this one worthy of backport?
[Bug fortran/109358] Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 --- Comment #11 from Jerry DeLisle --- I am going to submit the attached patch to close this PR and open a new PR for the lingering multiple tab edits in a row. The problem there is we have a special case if we have different T, TL, and TR following each other, a nonsensical situation. However, we should handle it. It will require "looking ahead" or "looking back" in the format statement to know that this is happening.
[Bug fortran/113883] allocatable length parameter used but is undefined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113883 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #2 from Jerry DeLisle --- I should be able to commit this. The patch looks good. I have one other thing to do in front of this.
[Bug fortran/109358] Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 --- Comment #10 from Jerry DeLisle --- To clarify. The following is the remaining issue that is not related to stream I/O: > program tabs > implicit none > integer :: fd > open(newunit=fd, file="test.txt", form="formatted") > write(fd, "(a)") "12345678901234567890123456789" > write(fd, "(i4, t25, t2, i4.4)") 1234, 0123 > close(fd) > end program tabs Posted earlier in comment #6.
[Bug fortran/109358] Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 --- Comment #9 from Jerry DeLisle --- Created attachment 57365 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57365=edit Preliminary patch The attached patch fixes the stream I/O related tabbing. This regression tests fine. There is another side issue I discovered not related to stream I am investigating still. I will also work up a test case stream issue.
[Bug fortran/109358] Wrong formatting with T-descriptor during stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109358 Jerry DeLisle changed: What|Removed |Added CC||nmm1 at cam dot ac.uk --- Comment #8 from Jerry DeLisle --- *** Bug 53962 has been marked as a duplicate of this bug. ***
[Bug libfortran/53962] Tab handling with formatted stream output
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=53962 Jerry DeLisle changed: What|Removed |Added Resolution|--- |DUPLICATE Status|ASSIGNED|RESOLVED --- Comment #5 from Jerry DeLisle --- Marking this as a duplicate and will roll the test case here into PR109358 as I work it shortly. *** This bug has been marked as a duplicate of bug 109358 ***
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #28 from Jerry DeLisle --- Created attachment 57260 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=57260=edit A final patch This patch provides the necessary changes with only minor adjustment to existing gfortran test cases. (This took insanely longer than I had hoped and such is life.) I am preparing one or two additional test cases and will submit this for approval on the list.
[Bug fortran/104908] [11/12/13/14 Regression] incorrect Fortran out-of-bound runtime error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104908 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #8 from Jerry DeLisle --- (In reply to anlauf from comment #7) > (In reply to anlauf from comment #6) > > This is currently regtesting. > > Regtesting succeeded. Simple enough to just commit.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #27 from Jerry DeLisle --- (In reply to anlauf from comment #26) > (In reply to Jerry DeLisle from comment #24) > > Currently gfortran does the following: > > > > character(20) :: fmt > > character(9) :: buffer > > fmt = "(1a1,d0.2,1a1)" > > write(buffer,fmt) ">", 3.0, "<" > > print *, buffer > > fmt = "(1a1,e0.2,1a1)" > > write(buffer,fmt) ">", 3.0, "<" > > print *, buffer > > end > > > > > > $ gfc question.f90 > > $ ./a.out > > >0.30D+1< > > >0.30E+1< > > > > Why not: > > > > $ ./a.out > > >3.00D+0< > > >3.00E+0< > > It seems the Fortran standard changed here between F2018 and F2023. > > F2018, Table 13.1: > > Ew.d |exp| ≤ 99E±z1z2 or ±0z1 z2 > 99 < |exp| ≤ 999 ±z1 z2z3 > > So Intel implements this. > > > > F2023, Table 13.1: > > Ew.d E0 or E0.dany E±z1 z2 . . . zs > Yes it changed. I am looking at a lot of different cases here as I have time and intuitively the 0.30D+1 caught my attention. Its not necessarily related to this bug. I also have the latest standard (2023) in front of me here.
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 --- Comment #24 from Jerry DeLisle --- Currently gfortran does the following: character(20) :: fmt character(9) :: buffer fmt = "(1a1,d0.2,1a1)" write(buffer,fmt) ">", 3.0, "<" print *, buffer fmt = "(1a1,e0.2,1a1)" write(buffer,fmt) ">", 3.0, "<" print *, buffer end $ gfc question.f90 $ ./a.out >0.30D+1< >0.30E+1< Why not: $ ./a.out >3.00D+0< >3.00E+0< What does Intel do?
[Bug fortran/82943] [F03] Error with type-bound procedure of parametrized derived type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82943 --- Comment #16 from Jerry DeLisle --- (In reply to Alexander Westbrooks from comment #15) > Created attachment 57176 [details] > Proposed Patch to fix PR82943, PR86148, PR86268 I am attempting to roll with this. Steve, do you know where the copyright assignment forms are? I a,m hunting for them and I asked on the gcc IRC channel as well.
[Bug libfortran/113223] NAMELIST internal write missing leading blank character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113223 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED Status|UNCONFIRMED |RESOLVED --- Comment #7 from Jerry DeLisle --- Backported to gcc-13 using the gcc-backport script.
[Bug libfortran/113313] execute_command_line hangs at run time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313
--- Comment #8 from Jerry DeLisle ---
(In reply to Steve Kargl from comment #7)
--- snip ---
> libgfortran is supposedly thread-safe and looking into
> flush_all_units() shows some unlocking and testing for
> locks. With 'print *, iam('john')', there may be lock
> contention.
My first thought when I observed the test case execution is locks. Have not
looked further yet.
[Bug libfortran/113313] execute_command_line hangs at run time
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113313 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #4 from Jerry DeLisle --- I just started looking at this today. I will give the patch a spin in the next few days and if tests OK I can commit. John, are you able tp apply Steve's patch and try it? If not would you like to learn how? I can show people the ropes. We have a MatterMost workspace you can join and I can linkup with you there. (I will send you an invite, just let me know.)
[Bug libfortran/113223] NAMELIST internal write missing leading blank character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113223 --- Comment #3 from Jerry DeLisle --- Created attachment 56990 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56990=edit Suggested patch including affected test cases Regression tested OK. Three test cases affected. $ git status On branch master Your branch is up to date with 'origin/master'. Changes not staged for commit: (use "git add ..." to update what will be committed) (use "git restore ..." to discard changes in working directory) modified: gcc/testsuite/gfortran.dg/dtio_25.f90 modified: gcc/testsuite/gfortran.dg/namelist_57.f90 modified: gcc/testsuite/gfortran.dg/namelist_65.f90 modified: libgfortran/io/write.c no changes added to commit (use "git add" and/or "git commit -a") This looks good to me and I will commit as simple and obvious.
[Bug libfortran/113223] NAMELIST internal write missing leading blank character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=113223 --- Comment #2 from Jerry DeLisle --- (In reply to kargl from comment #1) > Jerry can you take a look at this issue. Will do. Minor tweak I hope.
[Bug fortran/81615] save-temps and gfortran produces *.f90 files instead of *.i or *i90 files
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81615 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #19 from Jerry DeLisle --- (In reply to anlauf from comment #18) > (In reply to Alex Coplan from comment #17) > > Just a ping: it would be nice if this could be fixed, I'm currently trying > > to debug/reduce a miscompiled benchmark which has *.f90 source files but > > -save-temps isn't useful due to this issue. > > The patch in comment#16 seems to work and looks good to me, but it appears > to never have been submitted for review. > > One could also add a mini-section in invoke.texi by borrowing from > gcc/doc/invoke.texi (-> Developer Options) and add a minimal example > for -save-temps in the context of gfortran use. It seems simple. Shall we post the patch to make sure we dont get any broader objections? If none, then we commit.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #34 from Jerry DeLisle --- If not resolved, feel free to reopen.
[Bug ipa/112783] core dump on libxo when function is inlined
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112783 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #8 from Jerry DeLisle --- (In reply to GCC Commits from comment #7) > The master branch has been updated by Jerry DeLisle : > > https://gcc.gnu.org/g:a1f0d227481fe143f8c15b3f268e2d5964a3c90a > > commit r14-6606-ga1f0d227481fe143f8c15b3f268e2d5964a3c90a > Author: Jerry DeLisle > Date: Fri Dec 15 13:05:18 2023 -0800 > > fortran: Update degree trigs documentation. > > This is only some cleanup. > > gcc/fortran/ChangeLog: > > PR fortran/112783 > > * intrinsic.texi: Fix where no COMPLEX allowed. > * invoke.texi: Clarify -fdev-math. Typoe the PR number. Ignore should be 112873
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #32 from Jerry DeLisle --- commit a1f0d227481fe143f8c15b3f268e2d5964a3c90a (HEAD -> master, origin/master, origin/HEAD) Author: Jerry DeLisle Date: Fri Dec 15 13:05:18 2023 -0800 fortran: Update degree trigs documentation. This is only some cleanup. gcc/fortran/ChangeLog: PR fortran/112783 * intrinsic.texi: Fix where no COMPLEX allowed. * invoke.texi: Clarify -fdev-math. I fat fingered the PR number, sigh.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873
--- Comment #31 from Jerry DeLisle ---
(In reply to anlauf from comment #30)
> (In reply to Jerry DeLisle from comment #29)
> > Created attachment 56883 [details]
> > Updated Descriptions
> >
> > Fixed a few more things, The return value of tand is not in degrees.
>
> I think the following is also incorrect:
>
> @item @code{RESULT = ATAND(Y, X)}
Yes, got that one now. Thanks.
[Bug fortran/112873] F2023 degree trig functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=112873 --- Comment #29 from Jerry DeLisle --- Created attachment 56883 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=56883=edit Updated Descriptions Fixed a few more things, The return value of tand is not in degrees.
