https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102595
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
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/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
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=edit
FM509 that I have here.
This morning I also recall there was one NIST test that had an error. I
contacted them
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 #8 from Jerry DeLisle ---
Created attachment 54263
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54263=edit
Reference files used by script
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=edit
Script used. may need to be adjusted for ones envoronment
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108369
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102331
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106731
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91316
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
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
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
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
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
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
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=107872
--- Comment #4 from Jerry DeLisle ---
Pauls patch regression tests fine. Thanks Paul
||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
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=107489
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
--- Comment #26 from Jerry DeLisle ---
I will be comitting it to trunk which is rev 13 if approved. John, I was not
expecting you to do anything. Since all my time on this is unpaid volunteer
work, I get to it when I have time.
I am not sure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106065
--- Comment #2 from Jerry DeLisle ---
I was a bit curious to see what flang would do with the test case. It gives
the exact same error message as gfortran, word for word.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105473
Jerry DeLisle changed:
What|Removed |Added
Attachment #52981|0 |1
is obsolete|
||2022-06-24
CC||jvdelisle at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jerry DeLisle ---
Well, its not really a 'crash', but certainly not correct.
Comment out the READ statements and look
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
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
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 =
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
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 #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 #12 from Jerry DeLisle ---
Created attachment 52981
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52981=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 #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
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
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
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=105542
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
|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
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=97571
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
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=66499
Jerry DeLisle changed:
What|Removed |Added
Status|ASSIGNED|NEW
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
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
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=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 #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>;
.
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,
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
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 #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 =
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
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
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99609
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
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
||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
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
||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
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96580
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98301
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
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=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=98890
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
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=99145
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
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=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
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
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=95647
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
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=93599
--- Comment #6 from Jerry DeLisle ---
Forgot to mention. Did you test with or without Janne's patch here:
https://gcc.gnu.org/ml/fortran/2020-01/msg00158.html
It could be related or influence this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93599
--- Comment #5 from Jerry DeLisle ---
(In reply to Thomas Koenig from comment #4)
> Created attachment 47800 [details]
> Possible fix
>
> Here is something that Nicolas and I came up with. The theory is that
> pthread_cond_wait can get a
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93599
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93567
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93550
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #32 from Jerry DeLisle ---
Thanks Thomas, I will have a look. It really helps to have a second pair of
eyes on this.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #29 from Jerry DeLisle ---
I think this last patch above fixes the last adjustment needed. I could be
wrong I suppose. Is this ready to close?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836
--- Comment #15 from Jerry DeLisle ---
Did we conclude that this is an expected race condition?
I run the example comment 14 and it just hangs for me.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93234
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
||2020-01-13
CC||jvdelisle at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from Jerry DeLisle ---
The enumerators in inquire.c do not match those set in unit.c.
Something like this is needed.
diff --git
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #27 from Jerry DeLisle ---
Hi Thomas, stating the obvious, I do not find it straight forwaed to interpret
the standards because there are nooks and crannies and corner cases. At least
now I have the basic pieces in place. I will
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #22 from Jerry DeLisle ---
(In reply to Jerry DeLisle from comment #21)
> Author: jvdelisle
> Date: Thu Jan 2 00:57:31 2020
> New Revision: 279828
>
> URL: https://gcc.gnu.org/viewcvs?rev=279828=gcc=rev
> Log:
> PR 90374 d0.d,
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #21 from Jerry DeLisle ---
Author: jvdelisle
Date: Thu Jan 2 00:57:31 2020
New Revision: 279828
URL: https://gcc.gnu.org/viewcvs?rev=279828=gcc=rev
Log:
PR 90374 d0.d, e0.d, es0.d, en0.d, g0.d and ew.d edit descriptors.
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90274
--- Comment #5 from Jerry DeLisle ---
Author: jvdelisle
Date: Thu Jan 2 00:57:31 2020
New Revision: 279828
URL: https://gcc.gnu.org/viewcvs?rev=279828=gcc=rev
Log:
PR 90374 d0.d, e0.d, es0.d, en0.d, g0.d and ew.d edit descriptors.
PR
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #20 from Jerry DeLisle ---
While working on this I found another issue:
program test
implicit none
real(8) :: rn
character(32) :: afmt, aresult
rn = 0.000314e8_8
write (*,fmt="(E0.8e0, a3)") rn, "<<<"
end
$
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #17 from Jerry DeLisle ---
Thanks for feedback. Hopefully I can get to it next day or so.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #11 from Jerry DeLisle ---
(In reply to Thomas Henlich from comment #10)
--- snip ---
>
> 13.7.2.3.3 E and D editing
> ... If e is positive the exponent part contains e digits, otherwise it
> contains the minimum number of digits
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836
--- Comment #4 from Jerry DeLisle ---
Removing close statement:
$ ./a.out
0 8 4
2 8 4
-10
5 8 4
4 8 4
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92836
Jerry DeLisle changed:
What|Removed |Added
CC||jvdelisle at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #9 from Jerry DeLisle ---
(In reply to anlauf from comment #6)
---snip---
> Jerry,
>
> your change to format.c generates a warning here:
>
> ../../../trunk/libgfortran/io/format.c: In function 'parse_format_list':
>
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #8 from Jerry DeLisle ---
Author: jvdelisle
Date: Sun Dec 1 22:29:43 2019
New Revision: 278886
URL: https://gcc.gnu.org/viewcvs?rev=278886=gcc=rev
Log:
2019-12-01 Jerry DeLisle
PR fortran/90374
* io/format.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #7 from Jerry DeLisle ---
(In reply to anlauf from comment #6)
> (In reply to Jerry DeLisle from comment #5)
> > Author: jvdelisle
> > Date: Thu Nov 28 18:33:20 2019
> > New Revision: 278817
>
> Jerry,
>
> your change to format.c
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92350
--- Comment #3 from Jerry DeLisle ---
(In reply to Tobias Burnus from comment #2)
> For the added text, cf. PR 60148 and
> https://gcc.gnu.org/ml/fortran/2014-03/msg00145.html
>
> I missed that patch when writing this PR because it wasn't
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90374
--- Comment #5 from Jerry DeLisle ---
Author: jvdelisle
Date: Thu Nov 28 18:33:20 2019
New Revision: 278817
URL: https://gcc.gnu.org/viewcvs?rev=278817=gcc=rev
Log:
PR fortran/90374
* io.c (check_format): Allow zero width
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100
Jerry DeLisle changed:
What|Removed |Added
Status|NEW |RESOLVED
Resolution|---
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92100
--- Comment #13 from Jerry DeLisle ---
Author: jvdelisle
Date: Wed Nov 27 00:50:51 2019
New Revision: 278753
URL: https://gcc.gnu.org/viewcvs?rev=278753=gcc=rev
Log:
2019-11-26 Jerry DeLisle
Backport from mainline
PR
201 - 300 of 2081 matches
Mail list logo
