[Bug fortran/95644] [F2018] IEEE_FMA is missing from the IEEE_ARITHMETIC module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644 --- Comment #10 from Jerry DeLisle --- It is very likely that the gcc optimizers will actually convert the to fma machine instructions, but no guarantee. I don't have much time, but it is likely some of the tricks we used in matmul can be used to get this to be "register" implemented .
[Bug fortran/99609] Pure Function that has a Variable with Value Attribute that is modified
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99609 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #4 from Jerry DeLisle --- (In reply to Scott Boyce from comment #3) > Yeah that is the same bug request. Though it is for version 11, any chance > of back-porting to version 9 and 10? It has been committed to version 10.
[Bug fortran/99711] Crash when reading an allocated character array in namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from Jerry DeLisle --- F2018 standard section 13.10.3 List-directed Input There is a note NOTE 13.29 at the end of the first sub-section 13.10.3.1" "An allocatable, deferred-length character effective item does not have its allocation status or allocated length changed as a result of list-directed input." This implies that if the strings of the array are not already allocated to a resonable length, for example a string of blanks, then the read will attempt to transfer the file contents into unallocated strings. If the status is unallocated the list READ cannot do any allocation to change its status to ALLOCATED. Thus all bets are off if it crashes. The read routines have no idea of the size to allocate the length to until the read is completed. There may be other places in the standard to clarify this, but looks like invalid fortran.
[Bug fortran/99711] Crash when reading an allocated character array in namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711 Jerry DeLisle changed: What|Removed |Added Resolution|INVALID |--- Last reconfirmed||2021-03-23 Status|RESOLVED|NEW Ever confirmed|0 |1 --- Comment #3 from Jerry DeLisle --- (In reply to kargl from comment #2) > (In reply to Jerry DeLisle from comment #1) > > F2018 standard section 13.10.3 List-directed Input > > > > There is a note NOTE 13.29 at the end of the first sub-section 13.10.3.1" > > > > "An allocatable, deferred-length character effective item does not have its > > allocation status or allocated length changed as a result of list-directed > > input." > > > > This implies that if the strings of the array are not already allocated to a > > resonable length, for example a string of blanks, then the read will attempt > > to transfer the file contents into unallocated strings. > > Doesn't the line > > allocate( character(len=10) :: cbulist_ru(5) ) > > that is the first executable statement in the program > allocate an array of 5 strings with length 10? You are right Steve, tired eyes were "seeing" only the declaration. In that case this should be OK and I do see the segfault. It is likely a front end issue.
[Bug fortran/99711] Crash when reading an allocated character array in namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711 --- Comment #4 from Jerry DeLisle --- Setting the character length in the type spec enables this to run correctly, so the string length is not getting set correctly in the allocate statement. program allocnml implicit none character(len=10), dimension(:), allocatable :: cbulist_ru ! set here integer :: iluseg namelist /nam_bu_ru/ cbulist_ru allocate( character(len=10) :: cbulist_ru(5) ) open(newunit=iluseg, file='list.nml', status='old', & action='read', form='formatted', access='sequential') read(unit=iluseg, nml=nam_bu_ru) print *, cbulist_ru close(unit=iluseg) end program allocnml
[Bug fortran/99711] Crash when reading an allocated character array in namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #7 from Jerry DeLisle ---
Digging further within gfc_resolve_dt which is resolving the READ statement,
one can find:
(gdb) p *e->symtree.n.sym.ts.u.cl
$31 = {length = 0x0, next = 0x0, length_from_typespec = false, backend_decl =
0x0,
passed_length = 0x0, resolved = 1}
e is the gfc_expr for cbulist_ru in the test case
I have checked both the gfc_expr itself and it's symtree and in all cases the
character length is NULL, not being intialized. I suspect it is getting missed
in the resolution of the allocate statement. At this point in gfc_resolve_dt
it is marked as having been resolved.
[Bug fortran/99711] Crash when reading an allocated character array in namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711 --- Comment #8 from Jerry DeLisle --- I see nowhere in resolve.c (resolve_allocate_expr) any attempt to resolve the chraracter length. I think it has been missed. I have cc'ed Paul to see if he has any thoughts.
[Bug fortran/99711] Crash when reading an allocated character array in namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711 --- Comment #11 from Jerry DeLisle --- Steve, I agree with your comment. Now in the READ at runtime there is a loop specification that is initialized to allow the read process to loop through these elements of an array. This works fine elsewhere, so I suspect, based on what you see here, that this loopspec is not getting initialized correctly meaning the array descriptor is uninitialized or otherwize corrupted. It is a bit late for me to look at this tonight, but as I get time I will examine where we set the loop spec and where it comes from.
[Bug fortran/99711] Crash when reading an allocated character array in namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #12 from Jerry DeLisle ---
This is interesting, compiling with the -g option for debugging.
Running a test case that is working with:
character(len=10), dimension(:), allocatable :: cbulist_ru ! explicit char
len
Breakpoint 1, nml_read_obj (dtp=dtp@entry=0x7fffd260,
nl=nl@entry=0x5184c0, offset=offset@entry=0,
pprev_nl=pprev_nl@entry=0x7fffd068,
nml_err_msg=nml_err_msg@entry=0x7fffd100 "Internal namelist read
error", clow=1, chigh=0, nml_err_msg_size=200)
at ../../../trunk/libgfortran/io/list_read.c:2886
2886 if (dtp->u.p.nml_read_error || !nl->touched)
(gdb) p nl
$1 = (namelist_info *) 0x5184c0
(gdb) p *nl
$2 = {type = BT_CHARACTER, var_name = 0x518530 "cbulist_ru",
mem_pos = 0x515e80, dtio_sub = 0x0, vtable = 0x0, touched = 1, len = 1,
var_rank = 1, size = 10, string_length = 10, dim = 0x518550, ls = 0x518570,
next = 0x0}
string_length as expected.
Running the failing test case with:
character(len=:), dimension(:), allocatable :: cbulist_ru ! deferred len
Breakpoint 1, nml_read_obj (dtp=dtp@entry=0x7fffd240,
nl=nl@entry=0x5184c0, offset=offset@entry=0,
pprev_nl=pprev_nl@entry=0x7fffd048,
nml_err_msg=nml_err_msg@entry=0x7fffd0e0 "Internal namelist read
error", clow=1, chigh=0, nml_err_msg_size=200)
at ../../../trunk/libgfortran/io/list_read.c:2886
2886 if (dtp->u.p.nml_read_error || !nl->touched)
(gdb) p nl->string_length
$13 = 10
(gdb) p *nl
$14 = {type = BT_CHARACTER, var_name = 0x518530 "cbulist_ru",
mem_pos = 0x515e80, dtio_sub = 0x0, vtable = 0x0, touched = 1, len = 1,
var_rank = 1, size = 967676983855022080, string_length = 10, dim = 0x518550,
ls = 0x518570, next = 0x0}
(gdb) p *nl->dim
$15 = {_stride = 1, lower_bound = 1, _ubound = 5}
size is messed up badly.
[Bug fortran/99711] Crash when reading an allocated character array in namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
--- Comment #13 from Jerry DeLisle ---
Looking at the -fdump-tree-originals in the two cases:
The working case:
{.elem_len=10, .rank=1, .type=6});
The failing case:
D.3962 = (sizetype) NON_LVALUE_EXPR <.cbulist_ru>;
.
{.elem_len=(unsigned long) SAVE_EXPR , .rank=1, .type=6});
Also one sees this:
Breakpoint 1, _gfortran_st_set_nml_var (dtp=0x7fffd2a0, var_addr=0x408910,
var_name=0x402053 "cbulist_ru", len=1, string_length=10, dtype=...)
at ../../../trunk/libgfortran/io/transfer.c:4597
4597{
(gdb) p *dtype
Structure has no component named operator*.
(gdb) p dtype
$1 = {elem_len = 14971996835529359360, version = 0, rank = 1 '\001',
type = 6 '\006', attribute = 0}
The call to _gfortran_st_set_nml_var is created by the frontend as shown in the
dump, the elem_len is bogus.
As far as I can tell then, the front-end is failing in the allocation
initializing the size correctly.
[Bug fortran/99711] Crash when reading an allocated character array in namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711 --- Comment #14 from Jerry DeLisle --- Created attachment 50473 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50473&action=edit -fdump-tree-original for failing case Attached the dump file of the failing case.
[Bug fortran/99711] Crash when reading an allocated character array in namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711 --- Comment #16 from Jerry DeLisle --- FWIW it also segfaults on: write(unit=6, nml=nam_bu_ru) I have been digging around with gdb in trans-io.c and I can see the cl is 0x0 in the sym->ts.u.cl and I can find nothing else accessible at this point. I think I am going to have to go back to the "trans" for the allocate which should have the length resolved and stuff it into the sym.
[Bug fortran/99711] Crash when reading an allocated character array in namelist
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711 --- Comment #17 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #16) > FWIW it also segfaults on: > > write(unit=6, nml=nam_bu_ru) > > I have been digging around with gdb in trans-io.c and I can see the cl is > 0x0 in the sym->ts.u.cl and I can find nothing else accessible at this > point. I think I am going to have to go back to the "trans" for the allocate > which should have the length resolved and stuff it into the sym. In trans-stmt.c (gfc_trans_allocate (gfc_code * code)) I find: (gdb) p *code->ext->alloc.ts.u.cl.length.value.integer._mp_d $41 = 10 So it is there and there is code to handle it in that function. However, I do not yet understand the inner workings of frontend to see what the problem is.
[Bug fortran/66499] Letters with accents change format behavior for X and T descriptors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66499 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|NEW
[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 Status|ASSIGNED|NEW
[Bug fortran/97571] long parsing phase for simple array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97571 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #8 from Jerry DeLisle --- Is it technically possible to do this differently in the compiler? yes Are there resources to actually do so? no Are putting resouces into it worth it (cost/benefit)? no Is there an easy work around? yes solution: do the workaround. subroutine bpr_init implicit none integer :: i real :: tacos2( 0:35250) do i=0,35250 tacos2(i) = acos((i + 64000.0)/10.0) end do end subroutine bpr_init [aside: I realize the example is a simplified/contrived example. Regardless it is horrible software practices using hard coded un-named real constants, etc etc etc.]
[Bug libfortran/98825] Unexpected behavior of FORTRAN FORMAT expressions when suppressing new line with '$'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98825 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED Status|WAITING |RESOLVED --- Comment #11 from Jerry DeLisle --- Fixed on trunk. Thanks for report.
[Bug fortran/95647] operator(.eq.) and operator(==) treated differently
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #13 from Jerry DeLisle --- Fixed on trunk and gcc-10
[Bug fortran/98686] Namelist group objects shall be defined before appearing in namelist for -std=f2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98686 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Status|NEW |ASSIGNED CC||jvdelisle at gcc dot gnu.org --- Comment #2 from Jerry DeLisle --- I have this working: pr98686.f90:2:19: 2 | namelist /NML/ x, m, q | 1 Error: Symbol ‘x’ in namelist ‘nml’ at (1) must be defined before the namelist is declared. Does this read OK?
[Bug fortran/98686] Namelist group objects shall be defined before appearing in namelist for -std=f2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98686 --- Comment #3 from Jerry DeLisle --- I am changing the word 'defined' to 'declared'.
[Bug fortran/98686] Namelist group objects shall be defined before appearing in namelist for -std=f2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98686
--- Comment #4 from Jerry DeLisle ---
One of this difficulties here is:
"If a namelist group object is typed by the implicit typing rules, its
appearance in any subsequent type declaration statement shall confirm the
implied type and type parameters."
If one takes away the IMPLICIT NONE in the example given, it would be valid
only if the subsequent explicit declarations agreed with the IMPLICIT. As far
as I know, there is no checking that explicit declarations confirm IMPLICIT.
My thinking is to add the check I have so far and defer the confirmatory checks
elsewhere, maybe as a warning. Otherwise I think it is can of worms. I do
think it might be useful to warn people about not confirming an implicit type
since it is conceivable that someone might contradict themselves while
modifying legacy codes. This is why we always recommend IMPLICIT NONE
regardless.
The patch at this point regressions tests OK.
diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 2df6191d7e6..2e6d1db515a 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -5536,6 +5536,17 @@ gfc_match_namelist (void)
if (m == MATCH_ERROR)
goto error;
+ /* It is required that members of a namelist be declared
+before the namelist. We check this by checking if the
+symbol has a defined type. */
+ if (gfc_current_ns->seen_implicit_none &&
+ sym->ts.type == BT_UNKNOWN)
+ {
+ gfc_error ("Symbol %qs in namelist %qs at %C must be "
+"declared before the namelist is declared.",
+sym->name, group_name->name);
+ goto error;
+ }
if (sym->attr.in_namelist == 0
&& !gfc_add_in_namelist (&sym->attr, sym->name, NULL))
goto error;
[Bug fortran/98686] Namelist group objects shall be defined before appearing in namelist for -std=f2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98686 --- Comment #5 from Jerry DeLisle --- The wording in the F2018 standard goes all the way back to F95. I do not plan to put this behind any check for any particular standard.
[Bug fortran/99145] gfortran LOOP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99145 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- What do you mean by LOOP? You are trying to set a string of 4294967300 characters to empty. The compiler is tryingt o create a very long empty string, basically a literal constant. Did the system run out of memory? What did it do?
[Bug fortran/99145] gfortran LOOP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99145 --- Comment #3 from Jerry DeLisle --- Initially it is creating the very large string in the frontend passes and then via resolution and translation phases, and finally into the middle-end and back end phases where it I am guessing the optimizers are realizing the simplifications. It is a known that some of these special cases are not recognized in the front end and immediately reduced. In this case it is creating a literal constant that big. Normally a program would be attempting to use the parameter in more than one place in which case it is literally substituted in. Should we mark this as invalid?
[Bug fortran/98890] ICE on reference to module function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98890 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #5 from Jerry DeLisle --- (In reply to Tobias Burnus from comment #4) > Related issue but without an ICE: > >contains > integer function f1() > !f2 = 1 ! gives an error as expected > j = f2! accepted; cast of function addr to integer(kind=4) > f1 = 1! ↑ ifort: 'already been used as an external function name' > end function > integer function f2() > f2=1 > end function >end A variation with a question: program p1 implicit none integer j, k j = 99 k = f1() print *, j, k contains integer function f1() !f2 = 1 j = f2 ! Should this be warned or rejected? print *, j f1 = 1 ! This should not be rejected end function integer function f2() f2=1 end function end
[Bug fortran/98890] ICE on reference to module function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98890 --- Comment #6 from Jerry DeLisle --- I should have noted in the above case, if we remove the parens on line 5, k = f1 is rejected.
[Bug fortran/98686] Namelist group objects shall be defined before appearing in namelist for -std=f2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98686 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from Jerry DeLisle --- Fixed on trunk.
[Bug libfortran/98301] random_init() is broken
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98301 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #5 from Jerry DeLisle --- Steve, if you think this does it. I will get it ready to commit for you. Does it also need to be back ported?
[Bug fortran/96580] F2018 changes to date_and_time intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96580 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- I was playing around with this just to see what happens: program test_time_and_date character(8) :: date character(10) :: time character(5) :: zone integer(2),dimension(8) :: values ! using keyword arguments call date_and_time(date,time,zone,values) call date_and_time(DATE=date,ZONE=zone) call date_and_time(TIME=time) call date_and_time(VALUES=values) print '(a,2x,a,2x,a)', date, time, zone print *, "-" print '(8i5)', values end program test_time_and_date Using integer(2): $ gfc -g -static pr96580.f90 $ $ gfc -Wall -fcheck=all pr96580.f90 $ Compiles without indication of an issue. However, segfaults. Not really surprising, but maybe we ought to detect or reject the code. (gdb) r Starting program: /home/jerry/dev/test/pr96580/a.out Program received signal SIGABRT, Aborted. 0x00443585 in raise () (gdb) bt #0 0x00443585 in raise () #1 0x004012cb in abort () #2 0x0040110a in _gfortran_date_and_time (__date=, __time=, __zone=, __values=, __date_len=, __time_len=, __zone_len=5) at ../../../trunk/libgfortran/intrinsics/date_and_time.c:227 #3 0x00402267 in test_time_and_date () at pr96580.f90:7 #4 0x004025ba in main (argc=1, argv=0x7fffd9c6) at pr96580.f90:14 #5 0x0043cf6a in __libc_start_main () #6 0x004020be in _start ()
[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 Last reconfirmed||2021-02-23 CC||jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #2 from Jerry DeLisle --- I will take this one. I need to investigate a bit, I can reproduce the results shown.
[Bug libfortran/99210] X editing for reading file with encoding='utf-8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210
--- Comment #3 from Jerry DeLisle ---
Here is the real issue. The X format specifier is a position modifier. UTF-8 is
a variable character length encoding so moving one character could mean move 1,
2, 3, or 4 bytes depending on the content of the file.
Up to now we have chosen to move "position" by 1 byte.
13.8.1.1 Position editing
1 The position edit descriptors T, TL, TR, and X, specify the position at which
the next character will be transmitted to or from the record. If any character
skipped by a position edit descriptor is of type nondefault character,
and the unit is a default character internal file or an external non-Unicode
file, the result of that position editing is processor dependent.
Our interpretation of this has been that the example provided in this PR is
processor dependent. However, the file is opened as encoding='UTF-8'.
So, we have to use UTF-8 based skips for READs. The following patch does this:
diff --git a/libgfortran/io/read.c b/libgfortran/io/read.c
index 7515d912c51..30ff0e0deb7 100644
--- a/libgfortran/io/read.c
+++ b/libgfortran/io/read.c
@@ -1255,6 +1255,23 @@ read_x (st_parameter_dt *dtp, size_t n)
if (n == 0)
return;
+
+ if (dtp->u.p.current_unit->flags.encoding == ENCODING_UTF8)
+{
+ gfc_char4_t c;
+ size_t nbytes, j;
+
+ /* Proceed with decoding one character at a time. */
+ for (j = 0; j < n; j++)
+ {
+ c = read_utf8 (dtp, &nbytes);
+
+ /* Check for a short read and if so, break out. */
+ if (nbytes == 0 || c == (gfc_char4_t)0)
+ break;
+ }
+ return;
+}
length = n;
The remaining part of this is what to do for end of file conditions. So, I am
doing a little mor testing.
[Bug fortran/66499] Letters with accents change format behavior for X and T descriptors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66499 Jerry DeLisle changed: What|Removed |Added Status|NEW |ASSIGNED 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 --- The case in the original report is likely not valid without setting the encoding for the output unit as Dominique has done in Comment 1. The problem here is likely similar to 99210.
[Bug libfortran/99210] X editing for reading file with encoding='utf-8'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210 --- Comment #4 from Jerry DeLisle --- I think the patch works fine as is as far as I can tell. There will be a similar fix for writing files with encoding='utf8'
[Bug fortran/108369] FM509 Fails to compile with error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #5 from Jerry DeLisle --- I use to run the NIST tests regularly many years ago. Even then, we would hita bug once in a while. FM509 has failed before in those times and I would not be surprised something got broke. I do remember you have to use -std=legacy no matter what. Steve you may have discovered something new. I the meantime I hope I can find the old script I used to run the tests. Its about three disk drive ago connected to three different computers, however, I never delete things. (on the hunt tonight)
[Bug fortran/108369] FM509 Fails to compile with error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #6 from Jerry DeLisle --- Unbelievable! I found the folder in my test directory. The NIST test suite passes as before with my test script using the latest gfortran trunk rev 13. I do some comparisons way back with some example outputs in some of these cases. I will zip this up and send it to Ben and Steve. I was actually surprised things still passed.
[Bug fortran/108369] FM509 Fails to compile with error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #7 from Jerry DeLisle --- Created attachment 54262 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54262&action=edit Script used. may need to be adjusted for ones envoronment
[Bug fortran/108369] FM509 Fails to compile with error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #8 from Jerry DeLisle --- Created attachment 54263 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54263&action=edit Reference files used by script
[Bug fortran/108369] FM509 Fails to compile with error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #9 from Jerry DeLisle --- The NIST files themselves are too large to attach here.
[Bug fortran/108369] FM509 Fails to compile with error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #13 from Jerry DeLisle --- Created attachment 54267 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54267&action=edit FM509 that I have here. This morning I also recall there was one NIST test that had an error. I contacted them regarding this error with a correction. This was based on a lot of sleuthing. I do not remember if they ever corrected it or not and I do not remember which one. FWIW I will attach the FM509 case I am using here.
[Bug fortran/108369] FM509 Fails to compile with error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #14 from Jerry DeLisle --- the '-x f77' id documented here: https://gcc.gnu.org/onlinedocs/gcc-12.2.0/gcc/Overall-Options.html#Overall-Options All it does is tell the compiler the source is fixed form or free-form. Admittedly that is confusing. -std= is definately what should be used for various dialects of fortran. The .f suffix on the file also tells the compiler fixed form. With this, we should consider changing the use of the option as it does no relate to dialect but rather the form of the source code.
[Bug fortran/102331] ICE in attr_decl1, at fortran/decl.c:8691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102331 --- Comment #7 from Jerry DeLisle --- I biffed the PR number on this commit. It should have been here. I will have to look into amending the ChangeLog correctly. The master branch has been updated by Jerry DeLisle : https://gcc.gnu.org/g:cdc6bf44eec295805ae29a8aaddafd111de01c8e commit r13-4934-gcdc6bf44eec295805ae29a8aaddafd111de01c8e Author: Steve Kargl Date: Mon Dec 26 14:07:04 2022 -0800 Modify checks to avoid referencing NULL pointer. Update test cases with error messages that changed as a result. gcc/fortran/ChangeLog: PR fortran/102595 * decl.cc (attr_decl1): Guard against NULL pointer. * parse.cc (match_deferred_characteristics): Include BT_CLASS in check for derived being undefined. gcc/testsuite/ChangeLog: PR fortran/102595 * gfortran.dg/class_result_4.f90: Update error message check. * gfortran.dg/pr85779_3.f90: Update error message check.
[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #7 from Jerry DeLisle --- (In reply to CVS Commits from comment #6) The above commit should have been for PR102331.
[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595
--- Comment #8 from Jerry DeLisle ---
I started to do some variations on the z1.f90 case:
program p
complex, parameter :: x(0) = 2
!data x%im /3.0/
print *, x
end
Running this prints a blank line;
Looking at the -fdump-tree-original shows:
parm.1.span = 8;
parm.1.dtype = {.elem_len=8, .rank=1, .type=4};
parm.1.dim[0].lbound = 1;
parm.1.dim[0].ubound = 0;
parm.1.dim[0].stride = 1;
parm.1.data = (void *) &x[0];
parm.1.offset = -1;
Is it valid to have an ubound less than the lbound?
program p
complex, parameter :: x(1) = 2
!data x%im /3.0/
print *, x
end
The z2 case prints what is expected. It looks like we need to catch something
in the parameter declaration before the data statement so that it is not
garbage later.
.. to be continued ..
[Bug fortran/106731] ICE on automatic array of derived type with DTIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731 --- Comment #13 from Jerry DeLisle --- I will backport to 12 as it is an ice on Valid.
[Bug fortran/102331] ICE in attr_decl1, at fortran/decl.c:8691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102331 --- Comment #8 from Jerry DeLisle --- Fixed ChangeLogs PR number referenced. commit 04d7cc165387d19e1433a4b2157d2bde7b95305b (HEAD -> master, origin/master, origin/HEAD) Author: Jerry DeLisle Date: Tue Jan 17 17:30:49 2023 -0800 Fix bug number reference in Changelogs For: gcc/fortran/ChangeLog-2022: gcc/testsuite/ChangeLog-2022:
[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595
Jerry DeLisle changed:
What|Removed |Added
Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot
gnu.org
--- Comment #10 from Jerry DeLisle ---
The following appears to catch it correctly. The previous spot I removed after
spotting while checking the addition to primary.cc. I keep the error message
similar so that existing tests in gfortrn.dg pass without changing.
diff --git a/gcc/fortran/data.cc b/gcc/fortran/data.cc
index 443d35da9cf..d29eb12c1b1 100644
--- a/gcc/fortran/data.cc
+++ b/gcc/fortran/data.cc
@@ -244,13 +244,6 @@ gfc_assign_data_value (gfc_expr *lvalue, gfc_expr *rvalue,
mpz_t index,
"array-element nor a scalar-structure-component";
symbol = lvalue->symtree->n.sym;
- if (symbol->attr.flavor == FL_PARAMETER)
-{
- gfc_error ("PARAMETER %qs shall not appear in a DATA statement at %L",
-symbol->name, &lvalue->where);
- return false;
-}
-
init = symbol->value;
last_ts = &symbol->ts;
last_con = NULL;
diff --git a/gcc/fortran/primary.cc b/gcc/fortran/primary.cc
index 543d9cc0de4..158f039f225 100644
--- a/gcc/fortran/primary.cc
+++ b/gcc/fortran/primary.cc
@@ -4076,6 +4076,11 @@ match_variable (gfc_expr **result, int equiv_flag, int
host_flag)
gfc_error ("Named constant at %C in an EQUIVALENCE");
return MATCH_ERROR;
}
+ if (gfc_in_match_data())
+ {
+ gfc_error ("PARAMETER %qs shall not appear in a DATA statement at
%C",
+ sym->name);
+ }
/* Otherwise this is checked for and an error given in the
variable definition context checks. */
break;
[Bug fortran/108369] FM509 Fails to compile with error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369 --- Comment #15 from Jerry DeLisle --- Do we close this bug as invalid or do we need to adjustsomething?
[Bug fortran/106731] ICE on automatic array of derived type with DTIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #15 from Jerry DeLisle --- Backport complete, closing.
[Bug fortran/103506] [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506
--- Comment #5 from Jerry DeLisle ---
I found that the attached patch does not work. At the point of assertion many
of the other functions to free memory have null pointers which leads to
segfaults all along the way.
The following approach appears to work, however, obviously there is a lot of
memory left not freed, so we would rely on the OS to clean it up. Maybe this is
ok, not sure.
+++ b/gcc/fortran/symbol.cc
@@ -4032,7 +4032,7 @@ void
gfc_free_namespace (gfc_namespace *&ns)
{
gfc_namespace *p, *q;
- int i;
+ int i, ecnt;
gfc_was_finalized *f;
if (ns == NULL)
@@ -4042,6 +4042,12 @@ gfc_free_namespace (gfc_namespace *&ns)
if (ns->refs > 0)
return;
+ /* In the presence of errors, the namespace may be
+ corrupted or non-sense. Don't assert() and bail out. */
+ gfc_get_errors (NULL, &ecnt);
+ if (ecnt > 0)
+return;
+
gcc_assert (ns->refs == 0);
gfc_free_statements (ns->code);
[Bug fortran/103506] [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506 --- Comment #7 from Jerry DeLisle --- The only other way would be some sort of built in memory management scheme that would guarantee all "objects" are freed implicitly. Of course gfortran itself implements this type of thing as does I think C++ and Rust. Well we sure are not going to completely rewrite gfortran. Sometimes I think we just ought to accept ice-on-invalid and just toss out all those bug reports as the effort to fix them is not worth the benefit from doing so. I would like to see if we can get a list out of Bugzilla for at least the ones we have marked as ice-on-invalid and just push those priorities to the back of the line.
[Bug fortran/103506] [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506 --- Comment #8 from Jerry DeLisle --- Doing the search in bugzilla, 137 bugs are marked as ic-on-invalid-code. I suggest we make all of these P5 or Wont fix. As my time and others is scarce, I plan to focus on the valid-code bugs. This one was a good one for me to study, but that is the only value I got out of it.
[Bug fortran/103506] [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506 --- Comment #9 from Jerry DeLisle --- There are 162 marked as ice-on-valid-code.
[Bug fortran/103506] [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506 --- Comment #13 from Jerry DeLisle --- (In reply to anlauf from comment #11) > (In reply to Jerry DeLisle from comment #8) > > Doing the search in bugzilla, 137 bugs are marked as ic-on-invalid-code. I > > suggest we make all of these P5 or Wont fix. > > Please don't make them wont-fix. I would not do anything like that unilaterally. I am exploring how we can sort these things out by priority. I am also aware that different contributors may have different priorities. Regarding ice-on-invalid being possible indicators of a problem elsewhere. This very bug is one of those. I have a variation on the patch I posted in comment #5 where the initial error occurs. There is a loop in the parsing there that bothers me. I am not done yet.
[Bug fortran/103506] [10/11/12/13 Regression] ICE in gfc_free_namespace, at fortran/symbol.c:4039 since r10-2798-ge68a35ae4a65d2b3
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506
--- Comment #14 from Jerry DeLisle ---
This is interesting. Simply doing the following eliminates the ice.
diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc
index 0fb19cc9f0f..a9e538cc2a1 100644
--- a/gcc/fortran/parse.cc
+++ b/gcc/fortran/parse.cc
@@ -6544,8 +6544,6 @@ loop:
default:
gfc_error ("Unexpected %s statement in MODULE at %C",
gfc_ascii_statement (st));
-
- error = true;
reject_statement ();
st = next_statement ();
goto loop;
I discovered this studying other code that was rejecting statements and found
the following existing function:
/* Generic complaint about an out of order statement. We also do
whatever is necessary to clean up. */
static void
unexpected_statement (gfc_statement st)
{
gfc_error ("Unexpected %s statement at %C", gfc_ascii_statement (st));
reject_statement ();
}
I tried it at the location of the patch just above and it worked. The error
message is generic but no ice. In fact the only difference is setting
error=true.
With the generic error message there are a couple of existing test cases that
don't pass but these would be minor edits.
All this begs the question about why set error=true. Right after this the code
on parse.cc has:
/* Make sure not to free the namespace twice on error. */
if (!error)
s->ns = gfc_current_ns;
Well, setting it true s->ns is not getting set at all. Meaning it is left
uninitialized. The comment about freeing the namespace is also bogus here.
There is no freeing of anything in this chunk of code.
[Bug fortran/102595] ICE in var_element, at fortran/decl.c:298 since r10-5607-gde89b5748d68b76b
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #12 from Jerry DeLisle --- Fixed and closing.
[Bug fortran/83705] [10/11/12/13 Regression] ICE/wrong code with large values of REPEAT after revision r256284
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705 Jerry DeLisle changed: What|Removed |Added Resolution|--- |FIXED CC||jvdelisle at gcc dot gnu.org Status|REOPENED|RESOLVED --- Comment #20 from Jerry DeLisle --- As far as I can tell this is fixed on branches 10 thru 13. I do not know why it was reopened. I am closing.
[Bug fortran/107820] ICE in match_mult_operand, at fortran/matchexp.cc:296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107820 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #2 from Jerry DeLisle --- (In reply to anlauf from comment #1) > Confirmed. > > I think this is a dup of pr107721 (lost typespec). This variation is a hint: program p print *, [real :: ([3])] ** 2 !0 end $ gfc z1.f90 f951: internal compiler error: free_expr0(): Bad expr type
[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721 Jerry DeLisle changed: What|Removed |Added Ever confirmed|0 |1 CC||jvdelisle at gcc dot gnu.org Last reconfirmed||2023-01-30 Status|UNCONFIRMED |NEW
[Bug fortran/107820] ICE in match_mult_operand, at fortran/matchexp.cc:296
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107820 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from Jerry DeLisle --- Marking as a duplicate. Side note, the problem goes away when not in a print statement. *** This bug has been marked as a duplicate of bug 107721 ***
[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721 Jerry DeLisle changed: What|Removed |Added CC||gs...@t-online.de --- Comment #1 from Jerry DeLisle --- *** Bug 107820 has been marked as a duplicate of this bug. ***
[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #2 from Jerry DeLisle --- I will see if I can find this.
[Bug fortran/108621] [12 regression]: bind(c) pointer array spurious maybe-uninitialized warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621 --- Comment #3 from Jerry DeLisle --- (In reply to Steve Kargl from comment #2) > On Wed, Feb 01, 2023 at 06:13:33PM +, kargl at gcc dot gnu.org wrote: > > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108621 > > > > This appears to be related to Sandra and Tobias's work on CFI. In > > particular, > > trans-expr.cc(gfc_conv_gfc_desc_to_cfi_desc) appear to not handle an > > intent(out) deferred entity. gfortran eventually gets to line 5818 and > > following where the `tree gfx` and `tree idx` are getting manipulated, but > > `fsym->as` shows > > > > It seems that bugzilla does not recognize the email address > that Tobias's uses in ChangeLong. Try to cc him here to see > if he gets added to the audit trail. Got it
[Bug fortran/108649] allocation segmentation fault for pointer derive type and ICE for final-binding
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649 Jerry DeLisle changed: What|Removed |Added Ever confirmed|0 |1 CC||jvdelisle at gcc dot gnu.org Last reconfirmed||2023-02-03 Status|UNCONFIRMED |NEW --- Comment #6 from Jerry DeLisle --- Thanks for giving test cases. I have not looked in detail but I will say that finalization bugs are being actively worked by Paul Thomas. He is very close to having it ready. I will try you cases against his latest patch to see what happens.
[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721 --- Comment #3 from Jerry DeLisle --- I have a copy of the standard so I will answer my own question. This is a comment: In a situation like this: print *, [integer :: ([1.0])] ** 2 My brain wants to say reject it because 1.0 is not an integer. I will check further as I said, but yet another example to me where the standard is counter-intuitive to me. I will be even bold and say the idea of even having a typespec in this form seems, shall I say, not so bright. But, there it is.
[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721 --- Comment #4 from Jerry DeLisle --- Well folks, I like to document my thought process. >From the 2022 draft standard we have: R781 ac-value is expr or ac-implied-do R782 ac-implied-do is ( ac-value-list , ac-implied-do-control ) In our code within array.cc we are clearly matching for R782. However, we are not really trying to match expr of R781. Our basic problem here is we have the following: print *, [integer :: ([1.0])] ** 2 The ([1.0]) portion is clearly not an ac-implied-do, so what is it? So is it an expr? R1023 expr is [ expr defined-binary-op ] level-5-expr Looks to me that it is an expr. print *, ([1.0]) works quite well. We have, therefore an expr. In array.cc we have gfc_match_array_constructor. As far as I can tell we are matching the ac-implied-do, however we are not even trying to match expr. Let's see what we can do about it.
[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
--- Comment #6 from Jerry DeLisle ---
I had to go back in the Standard to deepen my understanding. Yes simplifying
it would help. I think what we need to do is acknowledge that we should match
'(' and if found, recursively call the gfc_match_array_constructor and check
for the closing ')' on the other end of it.
[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721 --- Comment #7 from Jerry DeLisle --- I should mention, this also fails: print *, [real:: ((/2, 3/))] ** 2 So we also have to deal with this. I think I have it figured out.
[Bug fortran/107721] Lost typespec with constant expressions using array constructors and parentheses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721 --- Comment #8 from Jerry DeLisle --- FWIW : I think the typespec is being lost because the initial call into gfc_match_array_constructor which finds and matches the typespec sets a local variable seen_ts which is used later in that function to do the type conversion steps. However, before that happens a call from gfc_match_array_constructor into match_array_cons_element then results in a subsequent call to gfc_match_array_constructor where there is no typespec left to match. The local seen_ts is set to false so the conversion code does not get called. Killing parens does not fix any of this. I think what is needed is the seen_ts needs to be passed down the call chain to preserve it during the match_array_cons_element process. My intuition tells me it would be better if portions of this code are refactored little to avoid some of these recursive calls.
[Bug fortran/92639] Error: Integer too big for its kind at (1)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #3 from Jerry DeLisle --- Please observe: program demonstrate integer :: i i = huge(i) print *, i i= -huge(i) print *, i end program $ gfc demonstrate.f90 $ ./a.out 2147483647 -2147483647 This is by the fortran standard definition for a 32 bit integer. You cannot represent 2147483648 in 32 bits because you need bit 32 to represent the sign of the value. How other compilers are storing the sign I can not speak to.
[Bug fortran/109076] class extending abstract type with deferred procedures, with another unrelated procedure interface, crashes on valid code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109076 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- In the summary statement you are saying crashes. Not sure what you mean. With gfortran latest truck, aka 13, I get the following: $ gfc pr109076.f90 pr109076.f90:13:15: 13 | procedure :: expand => i_expand | 1 Error: Argument mismatch for the overriding procedure ‘expand’ at (1): Shape mismatch in argument 'array' pr109076.f90:11:57: 11 | type, public, extends(parallel_class) :: interpolator | 1 Error: Derived-type ‘interpolator’ declared at (1) must be ABSTRACT because ‘expand’ is DEFERRED and not overridden
[Bug fortran/109080] A write of a NAMELIST group containing an allocatable array is incorrect
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109080 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #3 from Jerry DeLisle --- Closing, invalid in the sense that it has been fixed in a later version of gfortran. Report is appreciated regardless.
[Bug libfortran/109099] Assignment in NAMELIST input does not fill in row-column order
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109099 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #5 from Jerry DeLisle --- Well I got curious here as I implemented many of the namelist features and have not seen too many namelist related bugs. This is with the example in the original post. $ gfc -std=f2003 pr109099.f90 $ ./a.out At line 9 of file pr109099.f90 Fortran runtime error: Cannot match namelist object name 234 My thinking is auto-filling anything is a legacy extension. Now if one comments out the READ and sees how gfortran writes the namelist: $ gfc -std=f2003 pr109099.f90 $ ./a.out &GROUP X= 12*999, / My own thought is that it is always good to check things this way to see if the "form" of the namelist input is good. Modifying your program: program testit integer, allocatable :: x(:,:); namelist / group / x character(len=80) :: input(3) allocate( x(3,4),source=999) x = reshape ([999, 999, 999, 999, 999, 999, 1, 2, 3, 4, 999, 999], [3, 4]) print *, shape(x), size(x) input=[& "&group ",& " x(2,3)=1,2,3,4,",& "/ "] !read( input, nml=group) write(*,group) end program testit Assuming I have your intent right in the reshape. $ ./a.out 3 4 12 &GROUP X= 6*999,1 ,2 ,3 ,4 , 2*999, / and then doing the following shows a safer way to do these things: program testit integer, allocatable :: x(:,:); namelist / group / x character(len=20) :: input(3) allocate( x(3,4),source=999) input=["&GROUP",& " X= 6*999,1,2,3,4,",& " 2*999,/ "] read( input, nml=group) write(*,group) end program testit $ gfc -std=f2003 pr109099.f90 $ ./a.out &GROUP X= 6*999,1 ,2 ,3 ,4 , 2*999, /
[Bug fortran/107489] Runtime segfault in finalization routine of derived type with allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107489 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #2 from Jerry DeLisle --- The patch is here: https://gcc.gnu.org/pipermail/fortran/attachments/20220203/5c8a5980/attachment-0011.bin
[Bug fortran/107489] Runtime segfault in finalization routine of derived type with allocatable components
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107489 --- Comment #3 from Jerry DeLisle --- CCed Paul so he has this example.
[Bug fortran/107872] ICE on recursive DT with DTIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872 Jerry DeLisle changed: What|Removed |Added Last reconfirmed||2022-11-27 CC||jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from Jerry DeLisle --- The ICE is not related to the RECURSIVE as far as I can tell. I am trying some combinations of syntax to see if I can narrow this down.
[Bug fortran/107872] ICE on recursive DT with DTIO since r7-4096-gbf9f15ee55f5b291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872 --- Comment #4 from Jerry DeLisle --- Pauls patch regression tests fine. Thanks Paul
[Bug fortran/107872] ICE on recursive DT with DTIO since r7-4096-gbf9f15ee55f5b291
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872 --- Comment #5 from Jerry DeLisle --- Except WARNING: program timed out. FAIL: gfortran.dg/merge_1.f90 -O0 execution test
[Bug fortran/107874] merge not using all its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #12 from Jerry DeLisle --- Created attachment 54003 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54003&action=edit -fdump-tree-original output I get no output at runtime. The program simply hangs and does nothing. This is on: $ uname -a Linux r7laptop 6.0.10-300.fc37.x86_64 #1 SMP PREEMPT_DYNAMIC Sat Nov 26 16:55:13 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux
[Bug fortran/107874] merge not using all its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874 --- Comment #13 from Jerry DeLisle --- A debug session gives: (gdb) c Continuing. ^C Program received signal SIGINT, Interrupt. futex_wait (private=0, expected=2, futex_word=0x405950) at ../sysdeps/nptl/futex-internal.h:146 146 int err = lll_futex_timed_wait (futex_word, expected, NULL, private); (gdb) bt #0 futex_wait (private=0, expected=2, futex_word=0x405950) at ../sysdeps/nptl/futex-internal.h:146 #1 __GI___lll_lock_wait (futex=futex@entry=0x405950, private=0) at lowlevellock.c:49 #2 0x779d1432 in lll_mutex_lock_optimized (mutex=0x405950) at pthread_mutex_lock.c:48 #3 ___pthread_mutex_lock (mutex=0x405950) at pthread_mutex_lock.c:93 #4 0x77e73503 in __gthread_mutex_lock (__mutex=0x405950) at ../libgcc/gthr-default.h:749 #5 get_gfc_unit (n=6, do_create=1) at ../../../trunk/libgfortran/io/unit.c:395 #6 0x77e71b85 in data_transfer_init (dtp=0x7fffd9d0, read_flag=0) at ../../../trunk/libgfortran/io/transfer.c:3007 #7 0x004017dd in testmerge9::tstuff () at merge_1.f90:39 #8 0x0040128c in testmerge9 () at merge_1.f90:14 #9 0x0040184f in main (argc=1, argv=0x7fffe2c4) at merge_1.f90:36 #10 0x7796a510 in __libc_start_call_main ( main=main@entry=0x40181b , argc=argc@entry=1, argv=argv@entry=0x7fffdfa8) at ../sysdeps/nptl/libc_start_call_main.h:58 #11 0x7796a5c9 in __libc_start_main_impl (main=0x40181b , argc=1, argv=0x7fffdfa8, init=, fini=, rtld_fini=, stack_end=0x7fffdf98) at ../csu/libc-start.c:381 I would speculate we are trashing some memory since there is no reason to hang in there.
[Bug fortran/107874] merge not using all its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874 --- Comment #14 from Jerry DeLisle --- Now this is interesting. Compling with -static I get: $ gfc -static merge_1.f90 [jerry@r7laptop merge]$ ./a.out tstuff fstuff T tstuff fstuff F tstuff fstuff T tstuff fstuff F tstuff T tstuff F fstuff T fstuff F So there is something wrong with the linking as it hangs without -static $ echo $LD_LIBRARY_PATH /home/jerry/dev/usr/lib64/:/home/jerry/dev/usr/lib/ $ gfc -v Using built-in specs. COLLECT_GCC=gfc COLLECT_LTO_WRAPPER=/home/jerry/dev/usr/libexec/gcc/x86_64-pc-linux-gnu/13.0.0/lto-wrapper Target: x86_64-pc-linux-gnu Configured with: ../trunk/configure --prefix=/home/jerry/dev/usr --enable-languages=c,c++,fortran --enable-libgomp --disable-bootstrap Thread model: posix Supported LTO compression algorithms: zlib gcc version 13.0.0 20221201 (experimental) (GCC) [jerry@r7laptop bin]$ ls -l gfc lrwxrwxrwx. 1 jerry jerry 32 Nov 20 15:50 gfc -> /home/jerry/dev/usr/bin/gfortran Am I doing something wrong? Also Valgrind does show some issues, but one can not be sure.: $ gfc -static merge_1.f90 [jerry@r7laptop merge]$ valgrind --leak-check=full --show-leak-kinds=all ./a.out ==17321== Memcheck, a memory error detector ==17321== Copyright (C) 2002-2022, and GNU GPL'd, by Julian Seward et al. ==17321== Using Valgrind-3.20.0 and LibVEX; rerun with -h for copyright info ==17321== Command: ./a.out ==17321== ==17321== Syscall param set_robust_list(head) points to uninitialised byte(s) ==17321==at 0x48848A: __tls_init_tp (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x439361: __libc_setup_tls (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x438630: (below main) (in /home/jerry/dev/test/merge/a.out) ==17321== Address 0x40006b0 is in the brk data segment 0x400-0x4000d3f ==17321== ==17321== Conditional jump or move depends on uninitialised value(s) ==17321==at 0x460387: malloc (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x4B3B9A: _dl_get_origin (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x489416: _dl_non_dynamic_init (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x48ABE8: __libc_init_first (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x4386A8: (below main) (in /home/jerry/dev/test/merge/a.out) ==17321== ==17321== Conditional jump or move depends on uninitialised value(s) ==17321==at 0x460459: malloc (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x4B3B9A: _dl_get_origin (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x489416: _dl_non_dynamic_init (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x48ABE8: __libc_init_first (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x4386A8: (below main) (in /home/jerry/dev/test/merge/a.out) ==17321== ==17321== Conditional jump or move depends on uninitialised value(s) ==17321==at 0x45EFBB: _int_malloc (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x45FC34: tcache_init.part.0 (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x460463: malloc (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x4B3B9A: _dl_get_origin (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x489416: _dl_non_dynamic_init (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x48ABE8: __libc_init_first (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x4386A8: (below main) (in /home/jerry/dev/test/merge/a.out) ==17321== ==17321== Conditional jump or move depends on uninitialised value(s) ==17321==at 0x4757D4: __strcspn_sse42 (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x4B8CFC: strsep (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x4AEE1E: fillin_rpath.isra.0 (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x4AF52C: _dl_init_paths (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x489A3B: _dl_non_dynamic_init (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x48ABE8: __libc_init_first (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x4386A8: (below main) (in /home/jerry/dev/test/merge/a.out) ==17321== ==17321== Conditional jump or move depends on uninitialised value(s) ==17321==at 0x4757B2: __strcspn_sse42 (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x4B8CFC: strsep (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x4AEE1E: fillin_rpath.isra.0 (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x4AF52C: _dl_init_paths (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x489A3B: _dl_non_dynamic_init (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x48ABE8: __libc_init_first (in /home/jerry/dev/test/merge/a.out) ==17321==by 0x4386A8: (below main) (in /home/jerry/dev/test/merge/a.out) ==17321== tstuff fstuff T tstuff fstuff F tstuff fstuff T tstuff fstuff F tstuff T tstuff F fstuff T fstuff F ==17321== Conditional jump or move depends on uninitialised value(s) ==17321==at 0x45B3D9: __libc_cleanup_push_defer (in /home/jerry/dev/test/merge/a.out) ==17321==by
[Bug fortran/107874] merge not using all its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874 --- Comment #16 from Jerry DeLisle --- (In reply to anlauf from comment #15) --- snip --- > Can you please verify? Yes, this fixes the test case. However if the orginal test case is valid fortran we probably need to fix something else. Paul Thomas was noticing a similar problem with his Finalization patches. He was doing the finalization inside trans_transfer or similar so it was blocking on a mutex trying to finalize in the middle of an I/O operation. So in this case, my guess is the merge expression needs to be resolved before the translation phase.
[Bug fortran/107874] merge not using all its arguments
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874 --- Comment #23 from Jerry DeLisle --- John, Your original case in Comment 1 now gives: $ gfc original.f90 $ ./a.out tstuff fstuff T tstuff fstuff F So I think it is OK, Harald's test case has function calls embedded in the print statements within the main program and those functions have embedded print statements themselves to the same output device which is stdout and this is not allowed per the Fortran standard. So the issue is only in the test case he previously committed and it is now fixed.
[Bug fortran/91316] Derived type finalization failing
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91316 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #3 from Jerry DeLisle --- (In reply to Paul Thomas from comment #2) > (In reply to Paul Thomas from comment #1) > > I notice that this is missing from the list of dependencies of PR37336, for > > which a wider fix will be submitted this afternoon. This has caught folks twice this last week. I have some ideas on a diagnostic for it at run time and will submit a separate PR for it.
[Bug fortran/106731] ICE on automatic array of derived type with DTIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #8 from Jerry DeLisle --- The simple patch does indeed fix the ICE at compile time. It also regression tests cleanly. I am studying the results of running this test case to be sure it makes sense. The DTIO procedure in the example is not getting invoked from my first look.
[Bug fortran/106731] ICE on automatic array of derived type with DTIO
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731 --- Comment #9 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #8) > The simple patch does indeed fix the ICE at compile time. It also > regression tests cleanly. > > I am studying the results of running this test case to be sure it makes > sense. The DTIO procedure in the example is not getting invoked from my > first look. Indeed it was not being invoked since the line: print *, 'n=',n,automatic(n)%x Completely resolves the value of x. If instead one uses: print *, 'n=',n,automatic The DTIO procedure is invoked as expected. I will commit this one under simple and obvious rule shortly with a test case.
[Bug fortran/102331] ICE in attr_decl1, at fortran/decl.c:8691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102331 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #5 from Jerry DeLisle --- After exploring a while and looking for other places I have concluded that for invalid code Steve's patch is adequate. I will regression test it next.
[Bug fortran/102331] ICE in attr_decl1, at fortran/decl.c:8691
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102331 --- Comment #6 from Jerry DeLisle --- Regression testing looks good. The patch wiggles on the error messages given for: pr85779.f90 class_result_4.f90 In both cases they are reasonable. I don't think we need any new test cases since we are obviously exercising the patch. If anyone insists I add the z1 and z2 cases to the testsuite, let me know and i will 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 Jerry DeLisle changed: What|Removed |Added Last reconfirmed||2022-05-08 Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 CC||jvdelisle at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #6 from Jerry DeLisle --- I will take this one. My gcc.gnu.org account evaporated. All I had to do is re-create it.
[Bug fortran/105542] [F03] Orthogonal standard-conforming type finalization tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105542 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org --- Comment #1 from Jerry DeLisle --- Yes, it is always usefule to have tests available. I cloned the repository. fpm build is happy. $ fpm test compiler_test.f90 done. usage_test.f90 done. main.f90 done. reference-counter-test done. [100%] Project compiled successfully. Running Tests Test that The compiler finalizes a non-allocatable object on the LHS of an intrinsic assignment finalizes an allocated allocatable LHS of an intrinsic assignment finalizes a target when the associated pointer is deallocated finalizes an object upon explicit deallocation finalizes a non-pointer non-allocatable array object at the END statement finalizes a non-pointer non-allocatable object at the end of a block construct finalizes a function reference on the RHS of an intrinsic assignment finalizes a specification expression function result finalizes an intent(out) derived type dummy argument finalizes an allocatable component object Using a reference-counted object creates a resource when constructed removes the resource when it goes out of scope a copy points to the same resource A total of 13 test cases At line 42 of file test/usage_test.f90 Fortran runtime error: Attempt to DEALLOCATE unallocated 'the_resource' Execution failed for object " reference-counter-test " *cmd_run*:stopping due to failed executions STOP 1 Am I missing a step? This is with gfortran 12.
[Bug fortran/105542] [F03] Orthogonal standard-conforming type finalization tests
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105542 --- Comment #3 from Jerry DeLisle --- This is probably not the right place, but all gfortranners, try fpm if you have not already done so. It makes building and running the tests in this example so easy. Not to mention your own applications.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #7 from Jerry DeLisle --- My apologies for taking some time to get back to this. After a closer look, I realize that in the original test case there is no problem. The semicolon is an acceptable value separator regardless of decimal='point' or decimal='comma' Take these two examples: 1) The comma is the decimal keeper so semicolon must be used as the separator implicit none integer n,m,ios real r character(20):: testinput = '1;17;3,14159' n = 999 print *,'testinput = "',testinput,'"' read(testinput,*,decimal='comma', iostat=ios) n, m, r print *,'n=',n,' m= ', m,' r= ', r,' ios=',ios if(ios>0) print *,'testinput was not an integer' end program 2) The point is the decimal keeper so semicolon may be used as the separator or a comma implicit none integer n,m,ios real r character(20):: testinput = '1;17;3.14159' n = 999 print *,'testinput = "',testinput,'"' read(testinput,*,decimal='point', iostat=ios) n, m, r print *,'n=',n,' m= ', m,' r= ', r,' ios=',ios if(ios>0) print *,'testinput was not an integer' end program In the original test case, the semicolon is a separator and is simply ending the read as no value is there.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #9 from Jerry DeLisle --- Thank you for digging out the standards references. That was going to be my next step as the standards are notorious for these kinds of tidbits and corner cases. I have been reviewing the code implementations of this stuff so I have identified the places where checks can be added. Some of my preliminary attempts have resulted in quite a few test regressions. I am still at it here.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #10 from Jerry DeLisle --- Just completed good regression testing and have this: testinput = "1;17;3.14159" At line 8 of file pr105473.f90 Fortran runtime error: Semicolon not allowed as separator with DECIMAL='point' Now I wonder if I should likewise do the same for the other case with DECIMAL='comma' and we find a 'comma' separator.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #12 from Jerry DeLisle --- Created attachment 52981 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52981&action=edit Prposed Patch to add checks for 'comma' and 'point' This patch is pretty close. It does regression test OK.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #13 from Jerry DeLisle --- With John's multiple combinations test case I get the following results with the attached patch. All places where we gave an error before the patch, we give errors now plus new errors $ gfc multi.f90 $ ./a.out i= 1 input(i) = "2,5," with decimal=point x(:) = 2. 5. ios= 0 with decimal=comma x(:) = 2. 666.00 ios=5010 i= 2 input(i) = "2;5," with decimal=point x(:) = 2. 666.00 ios=5010 with decimal=comma x(:) = 2. 5. ios= 0 i= 3 input(i) = "2 5," with decimal=point x(:) = 2. 5. ios= 0 with decimal=comma x(:) = 2. 5. ios= 0 i= 4 input(i) = "2.5," with decimal=point x(:) = 2.5000 5. ios= -1 with decimal=comma x(:) = 2.5000 666.00 ios=5010 i= 5 input(i) = "2,5;" with decimal=point x(:) = 2. 5. ios=5010 with decimal=comma x(:) = 2.5000 666.00 ios= -1 i= 6 input(i) = "2;5;" with decimal=point x(:) = 2. 666.00 ios=5010 with decimal=comma x(:) = 2. 5. ios= 0 i= 7 input(i) = "2 5;" with decimal=point x(:) = 2. 5. ios=5010 with decimal=comma x(:) = 2. 5. ios= 0 i= 8 input(i) = "2.5;" with decimal=point x(:) = 2.5000 5. ios=5010 with decimal=comma x(:) = 2.5000 666.00 ios= -1 i= 9 input(i) = "2,5 " with decimal=point x(:) = 2. 5. ios= 0 with decimal=comma x(:) = 2.5000 666.00 ios= -1 i= 10 input(i) = "2;5 " with decimal=point x(:) = 2. 666.00 ios=5010 with decimal=comma x(:) = 2. 5. ios= 0 i= 11 input(i) = "2 5 " with decimal=point x(:) = 2. 5. ios= 0 with decimal=comma x(:) = 2. 5. ios= 0 i= 12 input(i) = "2.5 " with decimal=point x(:) = 2.5000 5. ios= -1 with decimal=comma x(:) = 2.5000 666.00 ios= -1 i= 13 input(i) = "2,5." with decimal=point x(:) = 2. 5. ios= 0 with decimal=comma x(:) = 2. 666.00 ios=5010 i= 14 input(i) = "2;5." with decimal=point x(:) = 2. 666.00 ios=5010 with decimal=comma x(:) = 2. 5. ios= 0 i= 15 input(i) = "2 5." with decimal=point x(:) = 2. 5. ios= 0 with decimal=comma x(:) = 2. 5. ios= 0 i= 16 input(i) = "2.5." with decimal=point x(:) = 2. 5. ios=5010 with decimal=comma x(:) = 2. 666.00 ios=5010 [jerry@amdr pr105473]$ gfc multi.f90 [jerry@amdr pr105473]$ ./a.out i= 1 input(i) = "2,5," with decimal=point x(:) = 2. 5. ios= 0 with decimal=comma x(:) = 2. 666.00 ios=5010 Bad real number in item 1 of list input i= 2 input(i) = "2;5," with decimal=point x(:) = 2. 666.00 ios=5010 Semicolon not allowed as separator with DECIMAL='point' with decimal=comma x(:) = 2. 5. ios= 0 i= 3 input(i) = "2 5," with decimal=point x(:) = 2. 5. ios= 0 with decimal=comma x(:) = 2. 5. ios= 0 i= 4 input(i) = "2.5," with decimal=point x(:) = 2.5000 5. ios= -1 End of file with decimal=comma x(:) = 2.5000 666.00 ios=5010 Bad real number in item 1 of list input i= 5 input(i) = "2,5;" with decimal=point x(:) = 2. 5. ios=5010 Semicolon not allowed as separator with DECIMAL='point' with decimal=comma x(:) = 2.5000 666.00 ios= -1 End of file i= 6 input(i) = "2;5;" with decimal=point x(:) = 2. 666.00 ios=5010 Semicolon not allowed as separator with DECIMAL='point' with decimal=comma x(:) = 2. 5. ios= 0 i= 7 input(i) = "2 5;" with decimal=point x(:) = 2. 5. ios=5010 Semico
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #14 from Jerry DeLisle --- The first set of results in in Comment #13 is with the line that prints msg commented out. The second set is with the msg prints.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #18 from Jerry DeLisle --- (In reply to harper from comment #17) > On comparing that with ifort's result I think that the only remaining bug > is that if decimal='comma' then '.' is neither a decimal symbol nor a > separator (see f2018 13.6). Making this easier for others to see. With gfortran I see with the 8th sub-case: i= 8 input(i) = "2.5;" with decimal=point x(:) =2.5 666.0 ios=5010 with decimal=comma x(:) =2.5 666.0 ios=-1 i= 12 input(i) = "2.5 " with decimal=point x(:) =2.5 666.0 ios=-1 with decimal=comma x(:) =2.5 666.0 ios=-1 In these cases the decimal=comma should have never seen 2.5 With ifort: i= 8 input(i) = "2.5;" with decimal=point x(:) = 2.5000 5. ios=5010 with decimal=comma x(:) = 2.5000 666.00 ios= -1 I don't think ifort has the decimal=point part right, as if it backed up and read the digit 5 a second time. Regardless, getting closer here. I will work on the gfortran comma issue.
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #20 from Jerry DeLisle --- Please check this. Second pair of eyes needed. $ ./a.out i= 1 input="2,5," with point x =2.05.0 OK i= 1 input="2,5," with comma x = 666.0 999.0 ERR i= 2 input="2;5," with point x =2.0 999.0 ERR i= 2 input="2;5," with comma x =2.05.0 OK i= 3 input="2 5," with point x =2.05.0 OK i= 3 input="2 5," with comma x =2.05.0 OK i= 4 input="2.5," with point x =2.5 999.0 end i= 4 input="2.5," with comma x = 666.0 999.0 ERR i= 5 input="2,5;" with point x =2.05.0 ERR i= 5 input="2,5;" with comma x =2.5 999.0 end i= 6 input="2;5;" with point x =2.0 999.0 ERR i= 6 input="2;5;" with comma x =2.05.0 OK i= 7 input="2 5;" with point x =2.05.0 ERR i= 7 input="2 5;" with comma x =2.05.0 OK i= 8 input="2.5;" with point x =2.5 999.0 ERR i= 8 input="2.5;" with comma x = 666.0 999.0 ERR i= 9 input="2,5 " with point x =2.05.0 OK i= 9 input="2,5 " with comma x =2.5 999.0 end i=10 input="2;5 " with point x =2.0 999.0 ERR i=10 input="2;5 " with comma x =2.05.0 OK i=11 input="2 5 " with point x =2.05.0 OK i=11 input="2 5 " with comma x =2.05.0 OK i=12 input="2.5 " with point x =2.5 999.0 end i=12 input="2.5 " with comma x = 666.0 999.0 ERR i=13 input="2,5." with point x =2.05.0 OK i=13 input="2,5." with comma x = 666.0 999.0 ERR i=14 input="2;5." with point x =2.0 999.0 ERR i=14 input="2;5." with comma x =2.0 999.0 ERR i=15 input="2 5." with point x =2.05.0 OK i=15 input="2 5." with comma x =2.0 999.0 ERR i=16 input="2.5." with point x = 666.0 999.0 ERR i=16 input="2.5." with comma x = 666.0 999.0 ERR
[Bug fortran/105473] semicolon allowed when list-directed read integer with decimal='point'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473 --- Comment #22 from Jerry DeLisle --- 12.11.2 (6) says "if the statement is a READ statement or the error condition occurs in a wait operation for a transfer initiated by a READ statement, all input items or namelist group objects in the statement that initiated the transfer become undefined;" By undefined, it means you cant rely on it whether or not it has a value read into it or not. It is undefined by the standard and to the user, so it could be anything, There was one last place I am going to check in the code before I am done. (maybe ;)) Regarding NAG, yes we always use to like to see that interpretation.
[Bug fortran/105847] namelist-object-name can be a renamed host associated entity
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105847 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 #2 from Jerry DeLisle --- I will see if I can commit this one.
