[Bug fortran/52387] I/O output of write after nonadvancing read

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52387 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|NEW

[Bug fortran/61632] Improve error locus on large format strings

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61632 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|NEW

[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 fortran/78351] comma not terminating READ of formatted input field - ok in 4.1.7, not 4.4.7- maybe related to 25419?

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78351 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|NEW

[Bug fortran/80009] Printing/writing a structure with a real edit descriptor.

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|NEW

[Bug fortran/81499] internal compiler error when compiling gfortran code with user-defined derived type i/o

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81499 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|NEW

[Bug fortran/82086] namelist read with repeat count fails when item is member of array of structures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82086 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|NEW

[Bug fortran/83522] ICE on invalid allocatable string reference, string(:)(:)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83522 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|NEW

[Bug fortran/83829] Implement runtime checks for DT format specifier and allignment with effective items

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83829 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|NEW

[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters

||jvdelisle at gcc dot gnu.org

[Bug fortran/77900] Compile time errors/warning for IO statements appear wrong

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77900 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug fortran/84094] several correctness issues in gfortran.dg

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84094 Bug 84094 depends on bug 87318, which changed state. Bug 87318 Summary: gfortran.dg/dtio_1.f90 is invalid https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87318 What|Removed |Added

[Bug fortran/87318] gfortran.dg/dtio_1.f90 is invalid

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87318 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug fortran/87318] gfortran.dg/dtio_1.f90 is invalid

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87318 --- Comment #8 from Jerry DeLisle --- Author: jvdelisle Date: Sat Sep 22 17:49:19 2018 New Revision: 264505 URL: https://gcc.gnu.org/viewcvs?rev=264505=gcc=rev Log: 2018-09-22 Jerry DeLisle PR fortran/87318 *

[Bug fortran/87318] gfortran.dg/dtio_1.f90 is invalid

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87318 --- Comment #5 from Jerry DeLisle --- (In reply to janus from comment #4) > (In reply to Jerry DeLisle from comment #3) > > Created attachment 44700 [details] > > Revised dtio_1.f90 > > > > Will this attached version suffice? > > Looks good at

[Bug fortran/87318] gfortran.dg/dtio_1.f90 is invalid

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87318 --- Comment #3 from Jerry DeLisle --- Created attachment 44700 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44700=edit Revised dtio_1.f90 Will this attached version suffice? When we wrote the test case we were not going for valid code,

[Bug fortran/87318] gfortran.dg/dtio_1.f90 is invalid

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87318 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/87233] Constraint C1279 still followed after f2008 standard revision (?)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87233 --- Comment #3 from Jerry DeLisle --- (In reply to kargl from comment #2) > (In reply to Jerry DeLisle from comment #1) > > The check is easy enough to delete: > > --- snip --- > What happens with -std=f95 and -std=f2003? > > -- > steve

[Bug fortran/87233] Constraint C1279 still followed after f2008 standard revision (?)

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87233 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/66575] Endless compilation on missing end interface

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66575 Jerry DeLisle changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED

[Bug fortran/86545] [6/7/8/9 Regression] ICE in transfer_expr on invalid WRITE statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86545 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/86837] Optimization breaks an unformatted read with implicit loop on Mac OS X

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86837 Jerry DeLisle changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed|

[Bug fortran/82009] [F08] ICE with block construct

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82009 --- Comment #11 from Jerry DeLisle --- The missing local variable exists in the fortran dump and it shows as the first item in the namespace passed to gfc_process_block_locals. However, it has no backend decl. I do not understand enough to

[Bug fortran/82009] [F08] ICE with block construct

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82009 --- Comment #10 from Jerry DeLisle --- In the tree dump, the declaration for idxs is missing for the first subroutine. I have modified to the following example so one can see it is not symbol name conflicts. MODULE

[Bug fortran/82009] [F08] ICE with block construct

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82009 Jerry DeLisle changed: What|Removed |Added Status|RESOLVED|REOPENED Resolution|FIXED

[Bug fortran/82009] [F08] ICE with block construct

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82009 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug fortran/82009] [F08] ICE with block construct

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82009 --- Comment #6 from Jerry DeLisle --- Author: jvdelisle Date: Wed Jul 4 18:08:16 2018 New Revision: 262416 URL: https://gcc.gnu.org/viewcvs?rev=262416=gcc=rev Log: 2018-07-04 Jerry DeLisle PR fortran/82009 * trans-decl.c

[Bug fortran/82086] namelist read with repeat count fails when item is member of array of structures

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82086 --- Comment #10 from Jerry DeLisle --- I am back on this. If I simply remove the check for repeat count the case given runs fine. The original code doing this check goes way back in history and there is one case in namelist_19.f90 that fails

[Bug fortran/71612] [Coarray] Wrongly rejects coindexed variables in READ

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71612 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/82009] [F08] ICE with block construct

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82009 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/85983] ICE in check_dtio_interface1, at fortran/interface.c:4748

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85983 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug fortran/85983] ICE in check_dtio_interface1, at fortran/interface.c:4748

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85983 --- Comment #3 from Jerry DeLisle --- Author: jvdelisle Date: Sun Jun 24 04:09:20 2018 New Revision: 261994 URL: https://gcc.gnu.org/viewcvs?rev=261994=gcc=rev Log: 2018-06-23 Jerry DeLisle PR fortran/85983 * interface.c

[Bug fortran/86281] [9 regression] SEGV in fortran/resolve.c:resolve_function

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86281 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug libfortran/78549] Very slow formatted internal file output

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78549 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug libfortran/85906] Conditional jump depends on uninitialized value in write_decimal / write_integer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85906 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug libfortran/86070] [7 regression] gfortran.dg/fmt_zero_digits.f90 segmentation fault starting with r261077

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86070 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug libfortran/86070] [7 regression] gfortran.dg/fmt_zero_digits.f90 segmentation fault starting with r261077

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86070 --- Comment #7 from Jerry DeLisle --- Author: jvdelisle Date: Sun Jun 10 03:10:00 2018 New Revision: 261384 URL: https://gcc.gnu.org/viewcvs?rev=261384=gcc=rev Log: 2018-06-09 Jerry DeLisle Backport from trunk. PR

[Bug libfortran/86070] [7 regression] gfortran.dg/fmt_zero_digits.f90 segmentation fault starting with r261077

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86070 --- Comment #6 from Jerry DeLisle --- Author: jvdelisle Date: Sun Jun 10 02:26:57 2018 New Revision: 261383 URL: https://gcc.gnu.org/viewcvs?rev=261383=gcc=rev Log: 2018-06-09 Jerry DeLisle PR libgfortran/86070 *

[Bug libfortran/86070] [7 regression] gfortran.dg/fmt_zero_digits.f90 segmentation fault starting with r261077

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86070 --- Comment #5 from Jerry DeLisle --- Author: jvdelisle Date: Sun Jun 10 01:49:02 2018 New Revision: 261382 URL: https://gcc.gnu.org/viewcvs?rev=261382=gcc=rev Log: 2018-06-09 Jerry DeLisle PR libgfortran/86070 *

[Bug libfortran/86070] [7 regression] gfortran.dg/fmt_zero_digits.f90 segmentation fault starting with r261077

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86070 --- Comment #4 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #3) > I am seeing a memory issue with valgrindinvestigating Had a variable being used unitialized specific to the flt_str_len that I added in my offending patch

[Bug libfortran/86070] [7 regression] gfortran.dg/fmt_zero_digits.f90 segmentation fault starting with r261077

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86070 --- Comment #3 from Jerry DeLisle --- I am seeing a memory issue with valgrindinvestigating

[Bug libfortran/86070] [7 regression] gfortran.dg/fmt_zero_digits.f90 segmentation fault starting with r261077

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86070 --- Comment #2 from Jerry DeLisle --- Well I am not seeing this on gcc112, so will try on gcc110. Bill were your tests on a gcc compile farm machine?

[Bug libfortran/86070] [7 regression] gfortran.dg/fmt_zero_digits.f90 segmentation fault starting with r261077

||2018-06-07 Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jerry DeLisle --- Mine, not sure why that patch would break it. I had to manually apply to 7 branch so maybe I

[Bug fortran/85983] ICE in check_dtio_interface1, at fortran/interface.c:4748

at gcc dot gnu.org |jvdelisle at gcc dot gnu.org

[Bug fortran/85983] ICE in check_dtio_interface1, at fortran/interface.c:4748

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85983 --- Comment #2 from Jerry DeLisle --- Removing the assert at interface.c:4748 seems to fix this, giving the following error: z2.f03:14:16: subroutine s2 (dtv, unit) 1 Error: Too few dummy arguments in DTIO procedure ‘s2’ at

[Bug fortran/85840] Memory leak in write.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85840 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug fortran/85840] Memory leak in write.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85840 --- Comment #16 from Jerry DeLisle --- Author: jvdelisle Date: Fri Jun 1 18:34:09 2018 New Revision: 261077 URL: https://gcc.gnu.org/viewcvs?rev=261077=gcc=rev Log: 2018-06-01 Jerry DeLisle Backport from trunk. PR

[Bug fortran/85840] Memory leak in write.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85840 --- Comment #15 from Jerry DeLisle --- Author: jvdelisle Date: Fri Jun 1 02:14:53 2018 New Revision: 261054 URL: https://gcc.gnu.org/viewcvs?rev=261054=gcc=rev Log: 2018-05-31 Jerry DeLisle Backport from trunk. PR

[Bug fortran/85840] Memory leak in write.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85840 --- Comment #14 from Jerry DeLisle --- Author: jvdelisle Date: Mon May 28 21:55:31 2018 New Revision: 260851 URL: https://gcc.gnu.org/viewcvs?rev=260851=gcc=rev Log: 2018-05-28 Jerry DeLisle PR libgfortran/85840 * io/write.c

[Bug libfortran/85906] Conditional jump depends on uninitialized value in write_decimal / write_integer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85906 --- Comment #9 from Jerry DeLisle --- (In reply to Jan Niklas Hasse from comment #8) > Thanks! If I understand it correctly this will go into 8.1.2? Per usual sequence, the next release of the 8 branch will be 8.2. However, some linux

[Bug libfortran/85906] Conditional jump depends on uninitialized value in write_decimal / write_integer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85906 --- Comment #7 from Jerry DeLisle --- Author: jvdelisle Date: Sun May 27 03:22:11 2018 New Revision: 260802 URL: https://gcc.gnu.org/viewcvs?rev=260802=gcc=rev Log: 2018-05-26 Jerry DeLisle Backport from

[Bug fortran/85840] Memory leak in write.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85840 --- Comment #13 from Jerry DeLisle --- Author: jvdelisle Date: Sun May 27 03:22:11 2018 New Revision: 260802 URL: https://gcc.gnu.org/viewcvs?rev=260802=gcc=rev Log: 2018-05-26 Jerry DeLisle Backport from

[Bug fortran/85840] Memory leak in write.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85840 --- Comment #12 from Jerry DeLisle --- Fixed on trunk. I think this should be backported as it is a regression I think on 7 and 8 branches.

[Bug libfortran/85906] Conditional jump depends on uninitialized value in write_decimal / write_integer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85906 --- Comment #6 from Jerry DeLisle --- Fixed on trunk. If anyone thinks this should be backported as a regression, let me know.

[Bug libfortran/85906] Conditional jump depends on uninitialized value in write_decimal / write_integer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85906 --- Comment #5 from Jerry DeLisle --- 2018-05-26 Jerry DeLisle PR libgfortran/85906 * io/write.c (write_integer): Initialise the fnode format to FMT_NONE, used for list directed write.

[Bug fortran/85840] Memory leak in write.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85840 --- Comment #11 from Jerry DeLisle --- Author: jvdelisle Date: Sat May 26 17:30:52 2018 New Revision: 260793 URL: https://gcc.gnu.org/viewcvs?rev=260793=gcc=rev Log: 2018-05-26 Jerry DeLisle PR

[Bug fortran/85840] Memory leak in write.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85840 --- Comment #10 from Jerry DeLisle --- (In reply to Joshua Cogliati from comment #9) --- snip --- > I could look into either method of fixing this if you want. (And for what > it is worth, I do have copyright assignment paperwork from both

[Bug libfortran/85906] Conditional jump depends on uninitialized value in write_decimal / write_integer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85906 --- Comment #4 from Jerry DeLisle --- After checking for possible other execution paths, it looks like the proposed patch will work fine. It is more obvious then that, the fnode is a local declaration. I will commit this one as "obvious" after

[Bug libfortran/85906] Conditional jump depends on uninitialized value in write_decimal / write_integer

||2018-05-25 Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #3 from Jerry DeLisle --- Confirmed, the fix needs farther up in the call chain. I am on it.

[Bug libfortran/85906] Conditional jump depends on uninitialized value in write_decimal / write_integer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85906 --- Comment #2 from Jerry DeLisle --- (In reply to kargl from comment #1) > I've added Jerry to the CC as he's probably the most familiar with > this area of the library. Jerry, does this one-line patch look > correct or are there deeper issues

[Bug fortran/25829] [F03] Asynchronous IO support

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829 --- Comment #42 from Jerry DeLisle --- (In reply to Nicolas Koenig from comment #41) > Created attachment 44151 [details] > Next version of patch. --- snip --- > real0m15.465s > user0m15.313s > sys 0m0.152s > > With the "no"

[Bug fortran/85840] Memory leak in write.c

at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #6 from Jerry DeLisle --- That did not take long. Thanks for simple test case. Confirmed.

[Bug fortran/85840] Memory leak in write.c

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85840 --- Comment #5 from Jerry DeLisle --- I will see if I can reproduce this here with you example and if so will get on it.

[Bug fortran/25829] [F03] Asynchronous IO support

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829 --- Comment #39 from Jerry DeLisle --- Per definition in ioparm.def in frontend: IOPARM (wait,id,1 << 7, pint4) id should be a pointer to an integer kind=4. This means: > typedef struct > { >st_parameter_common common;

[Bug fortran/25829] [F03] Asynchronous IO support

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829 --- Comment #38 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #37) > (In reply to Nicolas Koenig from comment #36) > > so some adjustment of > > > > typedef struct > > { > > st_parameter_common common; > > CHARACTER1 (id);

[Bug fortran/25829] [F03] Asynchronous IO support

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=25829 --- Comment #37 from Jerry DeLisle --- (In reply to Nicolas Koenig from comment #36) > so some adjustment of > > typedef struct > { > st_parameter_common common; > CHARACTER1 (id); > } > st_parameter_wait; > > is probably required. If id

[Bug fortran/83606] [6/7/8 Regression] co-indexed array RHS yields incorrect result in assignment to vector-indexed LHS

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83606 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/69497] ICE in gfc_free_namespace, at fortran/symbol.c:3701

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69497 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug fortran/66709] ICE on formatted io with parameter array specifier fmt

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66709 Jerry DeLisle changed: What|Removed |Added Assignee|jvdelisle at gcc dot gnu.org |unassigned at gcc dot gnu.org

[Bug fortran/69497] ICE in gfc_free_namespace, at fortran/symbol.c:3701

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69497 --- Comment #6 from Jerry DeLisle --- Committing to svn+ssh://jvdeli...@gcc.gnu.org/svn/gcc/trunk ... A gcc/testsuite/gfortran.dg/pr69497.f90 M gcc/fortran/ChangeLog M gcc/fortran/symbol.c M

[Bug fortran/51260] PARAMETER array with constructor initializer: Compile-time simplify single element access

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51260 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/77941] ICE in expand_expr_addr_expr_1, at expr.c:7805

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77941 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/66310] Problems with intrinsic repeat for large number of copies

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66310 --- Comment #27 from Jerry DeLisle --- (In reply to Dominique d'Humieres from comment #26) > > I concur. Closing accordingly. > > I disagree: if there is a limit, gfortran should emit an error. Well you are hitting on an OS limit, we could put

[Bug fortran/66310] Problems with intrinsic repeat for large number of copies

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66310 --- Comment #24 from Jerry DeLisle --- (In reply to Jerry DeLisle from comment #23) > Ok I see it. > > In fbuf.c (fbuf_alloc): > > /* Round up to nearest multiple of the current buffer length. */ > newlen = ((u->fbuf->pos + len) /

[Bug fortran/66310] Problems with intrinsic repeat for large number of copies

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66310 --- Comment #23 from Jerry DeLisle --- Ok I see it. In fbuf.c (fbuf_alloc): /* Round up to nearest multiple of the current buffer length. */ newlen = ((u->fbuf->pos + len) / u->fbuf->len + 1) *u->fbuf->len; u->fbuf->buf =

[Bug fortran/66310] Problems with intrinsic repeat for large number of copies

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66310 --- Comment #20 from Jerry DeLisle --- (In reply to Dominique d'Humieres from comment #19) > > Can this be closed. > > The problem is not fixed in 32-bit mode. Dominique, what are you seeing? This is working fine with my system with -m32.

[Bug fortran/84432] [F08] Detect illegal component initialization in pdt_27.f03

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84432 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84143 --- Comment #6 from Jerry DeLisle --- The patch fixes the first part of the problem so the write will ignore the kind and len parameters. The component n is simply not being initialized at all. I am searching code for where this ought to

[Bug fortran/84143] Intrinsic output of PDT incorrectly includes type parameters

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84143 --- Comment #5 from Jerry DeLisle --- Looking at the tree dump we have: _gfortran_st_write (_parm.0); { struct Pdtfoo_1 * D.3772; D.3772 = _gfortran_transfer_integer_write (_parm.0, >k1, 4);

[Bug fortran/84506] [6/7/8 Regression] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug fortran/84506] [6/7/8 Regression] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506 --- Comment #15 from Jerry DeLisle --- Author: jvdelisle Date: Fri Feb 23 19:53:04 2018 New Revision: 257951 URL: https://gcc.gnu.org/viewcvs?rev=257951=gcc=rev Log: 2018-02-23 Jerry DeLisle Backport from

[Bug fortran/84506] [6/7/8 Regression] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506 --- Comment #14 from Jerry DeLisle --- Author: jvdelisle Date: Fri Feb 23 19:16:00 2018 New Revision: 257945 URL: https://gcc.gnu.org/viewcvs?rev=257945=gcc=rev Log: 2018-02-23 Jerry DeLisle Backport from

[Bug fortran/84506] [6/7/8 Regression] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506 --- Comment #13 from Jerry DeLisle --- Fixed on trunk. Jakub, thanks for the report. This will be backported to 6 and 7 shortly.

[Bug fortran/84506] [6/7/8 Regression] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506 --- Comment #12 from Jerry DeLisle --- Author: jvdelisle Date: Fri Feb 23 18:40:14 2018 New Revision: 257941 URL: https://gcc.gnu.org/viewcvs?rev=257941=gcc=rev Log: 2018-02-23 Jerry DeLisle PR fortran/84506

[Bug fortran/84506] [6/7/8 Regression] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506 --- Comment #11 from Jerry DeLisle --- Tentative patch. Testing now. The intent originally was to prevent unit numbers that don't fit into kind=4. It use to be we had no negative unit numbers. With newunit, now we do. I need to see if this

[Bug fortran/84506] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

at gcc dot gnu.org |jvdelisle at gcc dot gnu.org --- Comment #8 from Jerry DeLisle --- With iUnit as kind=4, the dump ford not have the check. { struct __st_parameter_inquire inquire_parm.2; inquire_parm.2.common.filename = &"pr84506.f90"[1]{lb: 1 sz: 1};

[Bug fortran/84506] INQUIRE(pos=) always sets pos=0 with -fdefault-integer-8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84506 --- Comment #7 from Jerry DeLisle --- The problem is not related to the newunit functions or neunit alloc stuff. In the call to st_inquire we are passing the correct value of -10 for the unit number. However, the dump-original we have: {

[Bug fortran/82007] DTIO write format stored in a string leads to severe errors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82007 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug fortran/82007] DTIO write format stored in a string leads to severe errors

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82007 --- Comment #10 from Jerry DeLisle --- Author: jvdelisle Date: Tue Feb 20 04:05:38 2018 New Revision: 257837 URL: https://gcc.gnu.org/viewcvs?rev=257837=gcc=rev Log: 2018-02-19 Jerry DeLisle Backport from

[Bug fortran/35339] Improve translation of implied do loop in transfer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=35339 --- Comment #15 from Jerry DeLisle --- (In reply to Thomas Koenig from comment #14) > Fixed (finally). > > Closing. Thanks Thomas!

[Bug fortran/84389] Defined output: unexpected compiler error with the use of ":" edit descriptor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84389 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|---

[Bug fortran/84389] Defined output: unexpected compiler error with the use of ":" edit descriptor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84389 --- Comment #8 from Jerry DeLisle --- Author: jvdelisle Date: Sun Feb 18 19:19:47 2018 New Revision: 257795 URL: https://gcc.gnu.org/viewcvs?rev=257795=gcc=rev Log: 2018-02-18 Jerry DeLisle PR fortran/84389

[Bug fortran/84412] [7/8 Regression] Erroneous "Inquire statement identifies an internal file" error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84412 Jerry DeLisle changed: What|Removed |Added Status|NEW |RESOLVED Resolution|---

[Bug fortran/84412] [7/8 Regression] Erroneous "Inquire statement identifies an internal file" error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84412 --- Comment #4 from Jerry DeLisle --- Author: jvdelisle Date: Sun Feb 18 16:30:42 2018 New Revision: 257793 URL: https://gcc.gnu.org/viewcvs?rev=257793=gcc=rev Log: 2018-02-18 Jerry DeLisle Backport from trunk

[Bug fortran/84412] [7/8 Regression] Erroneous "Inquire statement identifies an internal file" error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84412 --- Comment #3 from Jerry DeLisle --- Author: jvdelisle Date: Sun Feb 18 15:32:39 2018 New Revision: 257791 URL: https://gcc.gnu.org/viewcvs?rev=257791=gcc=rev Log: 2018-02-18 Jerry DeLisle PR

[Bug fortran/84389] Defined output: unexpected compiler error with the use of ":" edit descriptor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84389 Jerry DeLisle changed: What|Removed |Added Status|NEW |ASSIGNED

[Bug fortran/84412] [7/8 Regression] Erroneous "Inquire statement identifies an internal file" error

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84412 Jerry DeLisle changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org

[Bug fortran/84389] Defined output: unexpected compiler error with the use of ":" edit descriptor

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84389 Jerry DeLisle changed: What|Removed |Added CC||jvdelisle at gcc dot gnu.org

[Bug fortran/84387] Defined output does not work for a derived type that has no components

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84387 Jerry DeLisle changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|jvdelisle at gcc

[Bug fortran/84387] Defined output does not work for a derived type that has no components

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84387 --- Comment #2 from Jerry DeLisle --- Looking at our -fdump-tree-original, since the derived type contains nothing we are not building any call to output anything. >From a practical point of view its a nonsensical case and one could argue to

<    1   2   3   4   5   6   7   8   9   10   >