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 t
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99609
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
Res
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99711
Jerry DeLisle changed:
What|Removed |Added
Resolution|INVALID |---
Last reconfirmed|
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)
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,
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.
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,
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, nm
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=(unsig
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.
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 po
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->
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66499
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97571
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98825
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|WAITING
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95647
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98686
--- Comment #3 from Jerry DeLisle ---
I am changing the word 'defined' to 'declared'.
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 parame
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99145
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98890
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
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.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98686
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98301
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96580
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99210
Jerry DeLisle changed:
What|Removed |Added
Last reconfirmed||2021-02-23
CC|
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66499
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |ASSIGNED
CC|
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'
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
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 outpu
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
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
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.
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 the
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
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:cdc6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
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
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.
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
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
--
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?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|ASSIGNED
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 app
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+
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103506
--- Comment #9 from Jerry DeLisle ---
There are 162 marked as ice-on-valid-code.
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 Won
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/fortr
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
Status|NEW
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83705
Jerry DeLisle changed:
What|Removed |Added
Resolution|--- |FIXED
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107820
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
Jerry DeLisle changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107820
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107721
Jerry DeLisle changed:
What|Removed |Added
CC||gs...@t-online.de
--- Comment #1 from J
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
--
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 relat
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108649
Jerry DeLisle changed:
What|Removed |Added
Ever confirmed|0 |1
CC|
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 inte
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
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_a
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.
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92639
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109076
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109080
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
Re
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109099
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107489
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107489
--- Comment #3 from Jerry DeLisle ---
CCed Paul so he has this example.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872
Jerry DeLisle changed:
What|Removed |Added
Last reconfirmed||2022-11-27
CC|
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107872
--- Comment #4 from Jerry DeLisle ---
Pauls patch regression tests fine. Thanks Paul
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107874
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
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 =
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
ts
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 Th
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 sta
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91316
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Comment
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
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 sur
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102331
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
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 o
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
Jerry DeLisle changed:
What|Removed |Added
Last reconfirmed||2022-05-08
Assignee|unassigne
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105542
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
--- Commen
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.
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 decima
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 implementatio
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
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.
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
$ ./
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.
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 f2
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.
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 state
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
1 - 100 of 424 matches
Mail list logo
