[Bug libfortran/80727] [7/8 Regression] Crash of runtime gfortran library during integer transformation

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

[Bug fortran/80666] character length parameter fails if declaration order incorrect

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

[Bug fortran/80674] trunk/gcc/fortran/trans-stmt.c:2578]: (style) Redundant condition

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

[Bug fortran/80333] Namelist dtio write of array of class does not traverse the array

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

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659 --- Comment #14 from Jerry DeLisle --- Author: jvdelisle Date: Thu May 11 20:40:49 2017 New Revision: 247930 URL: https://gcc.gnu.org/viewcvs?rev=247930=gcc=rev Log: 2017-05-11 Jerry DeLisle PR fortran/78659

[Bug fortran/79930] Potentially Missed Optimisation for MATMUL / DOT_PRODUCT

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79930 --- Comment #15 from Jerry DeLisle --- I wonder if we should back port this as well since the bug can have a serious performance hit without it. ?

[Bug libfortran/51119] MATMUL slow for large matrices

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51119 Bug 51119 depends on bug 68600, which changed state. Bug 68600 Summary: Inlined MATMUL is too slow. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68600 What|Removed |Added

[Bug fortran/37131] inline matmul for small matrix sizes

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37131 Bug 37131 depends on bug 68600, which changed state. Bug 68600 Summary: Inlined MATMUL is too slow. https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68600 What|Removed |Added

[Bug fortran/68600] Inlined MATMUL is too slow.

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

[Bug fortran/80484] Three syntax errors involving derived-type I/O

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

[Bug fortran/80484] Three syntax errors involving derived-type I/O

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484 --- Comment #15 from Jerry DeLisle --- Author: jvdelisle Date: Thu May 4 18:45:50 2017 New Revision: 247615 URL: https://gcc.gnu.org/viewcvs?rev=247615=gcc=rev Log: 2017-05-04 Jerry DeLisle Backport from

[Bug fortran/80524] [F03] Problematic behaviour with a finalization subroutine in gfortran

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80524 --- Comment #5 from Jerry DeLisle --- (In reply to janus from comment #4) > (In reply to Jerry DeLisle from comment #3) > > I think this depends a lot on the compiler implementation. > > I don't actually think the calling of finalization

[Bug fortran/80524] Problematic behaviour with a finalization subroutine in gfortran

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

[Bug fortran/80484] Three syntax errors involving derived-type I/O

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484 --- Comment #14 from Jerry DeLisle --- Fixed on trunk, will backport to 7 as soon as permitted.

[Bug fortran/80484] Three syntax errors involving derived-type I/O

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484 --- Comment #13 from Jerry DeLisle --- Author: jvdelisle Date: Sun Apr 23 15:49:16 2017 New Revision: 247084 URL: https://gcc.gnu.org/viewcvs?rev=247084=gcc=rev Log: 2017-04-23 Jerry DeLisle PR fortran/80484

[Bug fortran/80484] Three syntax errors involving derived-type I/O

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484 Jerry DeLisle changed: What|Removed |Added Keywords||wrong-code --- Comment #12 from Jerry

[Bug fortran/80484] Three syntax errors involving derived-type I/O

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484 --- Comment #10 from Jerry DeLisle --- (In reply to Walt Brainerd from comment #9) > Just FYI, Intel 2017 compiles 3DT'...', but it does not run correctly > (response inspired by your comments about a similar possibility :-). > Seems to run OK

[Bug fortran/80484] Three syntax errors involving derived-type I/O

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484 --- Comment #8 from Jerry DeLisle --- Regarding: use dt_write_mod, only: B_type, write (formatted) This works: use dt_write_mod, only: B_type It seems to me that since write (formatted) is a special instance of an interface defined by

[Bug fortran/80484] Three syntax errors involving derived-type I/O

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484 --- Comment #7 from Jerry DeLisle --- Created attachment 41246 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41246=edit Preliminary patch for testing This patch takes care of the rejected format with a repeat in front of the DT and the

[Bug fortran/80484] Three syntax errors involving derived-type I/O

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484 --- Comment #3 from Jerry DeLisle --- As an example of what I just said: $ gfc pr80484.f03 f951: internal compiler error: in gfc_match_use, at fortran/module.c:689 With no module defined. This is an unrelated bug I just stumbled on... with

[Bug fortran/80484] Three syntax errors involving derived-type I/O

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80484 --- Comment #2 from Jerry DeLisle --- (In reply to Walt Brainerd from comment #0) > Windows 10, gcc 7.0.1 20170416 > > If the commented versions of the USE or WRITE statements > are used, the program works fine. > > The function B converts

[Bug fortran/80484] Three syntax errors involving derived-type I/O

||2017-04-21 CC||jvdelisle at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |jvdelisle at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from Jerry DeLisle --- I will have

[Bug fortran/80388] ICE in output_constructor_regular_field, at varasm.c:4986

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

[Bug fortran/59910] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:5327

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59910 --- Comment #9 from Jerry DeLisle --- (In reply to Dominique d'Humieres from comment #8) > > > It does for me provided the patch is applied at the proper location: > > > > > > @@ -2657,6 +2657,12 @@ gfc_match_structure_constructor (gfc_sym > >

[Bug fortran/59910] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:5327

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

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 --- Comment #26 from Jerry DeLisle --- (In reply to r...@cebitec.uni-bielefeld.de from comment #25) --- snip --- > > Btw., I happened to notice that this "int * length" (and many more > instances throughout the file and probably all of

[Bug fortran/78670] [F03] Incorrect file position with namelist read under DTIO

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

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 --- Comment #24 from Jerry DeLisle --- (In reply to Christophe Lyon from comment #23) > (In reply to Jiong Wang from comment #22) > > (In reply to Rainer Orth from comment #15) > > > The new testcase FAILs on 64-bit Solaris/SPARC: > > > > +

[Bug fortran/80333] New: Namelist dtio write of array of class does not traverse the array

Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: jvdelisle at gcc dot gnu.org Target Milestone: --- The following test case shows the wrong behavior. I am pretty sure this is frontend related. Notice that derived types work OK

[Bug fortran/80305] print statement inside do-concurrent

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

[Bug fortran/78670] [F03] Incorrect file position with namelist read under DTIO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78670 --- Comment #8 from Jerry DeLisle --- Author: jvdelisle Date: Wed Mar 29 21:37:45 2017 New Revision: 246576 URL: https://gcc.gnu.org/viewcvs?rev=246576=gcc=rev Log: 2017-03-29 Jerry DeLisle PR

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

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

[Bug fortran/78670] [F03] Incorrect file position with namelist read under DTIO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78670 Bug 78670 depends on bug 78661, which changed state. Bug 78661 Summary: [OOP] Namelist output missing object designator under DTIO https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661 What|Removed |Added

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 --- Comment #20 from Jerry DeLisle --- (In reply to r...@cebitec.uni-bielefeld.de from comment #19) > [...] > > Here's the output I get: > > 63 > > 65

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 --- Comment #18 from Jerry DeLisle --- (In reply to r...@cebitec.uni-bielefeld.de from comment #17) > > ro@colima 27 > > LD_LIBRARY_PATH=../../../sparc-sun-solaris2.12/sparcv9/libgfortran/.libs > ./dtio_26.exe >

[Bug fortran/78670] [F03] Incorrect file position with namelist read under DTIO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78670 --- Comment #7 from Jerry DeLisle --- Good news, I have this sorted out and working now with Janus patch for the namelist write portion. We were calling the child procedure too early in nml_get_obj_data when we should have called it in

[Bug libfortran/78793] list_read.c: 7 * possible unintended fallthrough ?

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

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

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

[Bug fortran/78670] [F03] Incorrect file position with namelist read under DTIO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78670 --- Comment #6 from Jerry DeLisle --- (In reply to janus from comment #5) > (In reply to Jerry DeLisle from comment #4) > > Janus, the fix for this bug depends on your patch for pr78661. I would like > > to incorporate yours into the solution to

[Bug fortran/78670] [F03] Incorrect file position with namelist read under DTIO

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

[Bug fortran/78670] [F03] Incorrect file position with namelist read under DTIO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78670 --- Comment #3 from Jerry DeLisle --- With latest patches on trunk, I get this: $ ./a.out Got ' ' Got '=' At line 72 of file pr78670.f03 Fortran runtime error: End of file A minor problem with the test case is IF (ch /= '') THEN should be

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

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

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 --- Comment #13 from Jerry DeLisle --- Author: jvdelisle Date: Sat Mar 25 18:48:01 2017 New Revision: 246478 URL: https://gcc.gnu.org/viewcvs?rev=246478=gcc=rev Log: 2017-03-25 Jerry DeLisle PR

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 --- Comment #12 from Jerry DeLisle --- Another issue: In the case with file I/O if the child procedure consumes the EOR character, upon return, the parent is also wanting to complete the EOR the check for EOR and hits EOF. Lets see what I get

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 --- Comment #11 from Jerry DeLisle --- I finally figured out what is happening. The parent READ begins with eating any leading spaces. If a non-space character is found, rather than seek backward (which can't be done with some units) we unget

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 --- Comment #10 from Jerry DeLisle --- The test cases I have been working on uses: read( unit=s, fmt='(dt)', iostat=istat, iomsg=imsg, pad='yes' ) foo versus: read( unit=s, fmt=*, iostat=istat, iomsg=imsg, pad='yes' ) foo With fmt=*,

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 --- Comment #9 from Jerry DeLisle --- Created attachment 41014 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=41014=edit Preliminay Patch Here is a preliminary patch. I have spent a lot of time looking at the DTIO problem case as well as

[Bug fortran/38573] Missing markers for translation

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=38573 --- Comment #7 from Jerry DeLisle --- intrinsic.c contains a similar error message: if (!gfc_check_intrinsic_standard (isym, , false, loc) && !sym->attr.artificial) { if (sym->attr.proc == PROC_UNKNOWN && warn_intrinsics_std)

[Bug fortran/38573] Missing markers for translation

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

[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841 --- Comment #10 from Jerry DeLisle --- Fixed on trunk Can this be closed?

[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841 --- Comment #9 from Jerry DeLisle --- Author: jvdelisle Date: Fri Mar 17 18:21:08 2017 New Revision: 246241 URL: https://gcc.gnu.org/viewcvs?rev=246241=gcc=rev Log: 2017-03-17 Jerry DeLisle PR fortran/79841

[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841 --- Comment #8 from Jerry DeLisle --- (In reply to Roland Illig from comment #6) > Could you perhaps make all 6 messages in that function follow the same > syntax? Will do

[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69499 --- Comment #11 from Jerry DeLisle --- Always helps to double check. The three original test cases do not ICE on trunk and gfc_release_symbol is already NULL guarded internally. I would not chase this further on trunk for the first three

[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69499 --- Comment #10 from Jerry DeLisle --- Very good question, maybe we do: if (p) gfc_release_symbol (p); I will try it.

[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69499 --- Comment #8 from Jerry DeLisle --- I will take care of it. Thanks Nicolas

[Bug fortran/69499] [F03] ICE-on-invalid on combining select type with wrong statement

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

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661 --- Comment #27 from Jerry DeLisle --- With the patch applied and the following test case: MODULE m IMPLICIT NONE TYPE :: t integer :: j CHARACTER :: c integer :: k CONTAINS PROCEDURE :: write_formatted GENERIC ::

[Bug fortran/79382] DTIO ICE

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79382 --- Comment #9 from Jerry DeLisle --- Can this be closed?

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661 --- Comment #26 from Jerry DeLisle --- (In reply to janus from comment #25) > (In reply to Jerry DeLisle from comment #24) > > I dont think the parent is suppose to emit the Object name. What if there > > are multiple components? > > Huh, I'm

[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|WAITING |NEW --- Comment #9 from Jerry DeLisle

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009 --- Comment #8 from Jerry DeLisle --- (In reply to Walt Brainerd from comment #7) > I took "not processed by" to mean that there is no DT edit descriptor > corresponding to it. > > But I see how this might be interpreted otherwise. > > Intel

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=80009 --- Comment #6 from Jerry DeLisle --- (In reply to Walt Brainerd from comment #1) > Forgot to add: > > Pls see F08 std 9.6.3(7) 2nd bullet I see: BULLET: If a list item of derived type in a formatted input/output statement is not processed by

[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 CC||jvdelisle at gcc dot gnu.org

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661 --- Comment #24 from Jerry DeLisle --- I dont think the parent is suppose to emit the Object name. What if there are multiple comments? should be: I dont think the parent is suppose to emit the Object name. What if there are multiple

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661 --- Comment #23 from Jerry DeLisle --- (In reply to janus from comment #22) > (In reply to janus from comment #21) > > The testcase seems to be working properly by now, but unfortunately the > > patch breaks dtio_25.f90 (execution test), i.e.

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661 Bug 78661 depends on bug 78854, which changed state. Bug 78854 Summary: [F03] DTIO namelist output not working on internal unit https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854 What|Removed |Added

[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit

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

[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854 --- Comment #14 from Jerry DeLisle --- Fixed on trunk.

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

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

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 --- Comment #7 from Jerry DeLisle --- This is interesting. If I use: read( unit=s, fmt='(DT)', iostat=istat, iomsg=imsg ) foo then we do not lose the first character. However, the loop in the dtio procedure does not exit. So I inserted in

[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854 --- Comment #13 from Jerry DeLisle --- Author: jvdelisle Date: Sat Mar 11 14:49:57 2017 New Revision: 246070 URL: https://gcc.gnu.org/viewcvs?rev=246070=gcc=rev Log: 2017-03-11 Jerry DeLisle PR

[Bug libfortran/79956] [7 Regression] many new -Wmaybe-uninitialized warnings with bootstrap-O3

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

[Bug fortran/79484] Segfault when executing a test in Power8

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79484 --- Comment #3 from Jerry DeLisle --- Using LOC is not the right way to do these things. You should use bind(c) on the fortran side. I think you can google help with this. Power8 systems are less forgiving then others. I dont get any errors on

[Bug fortran/79484] Segfault when executing a test in Power8

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

[Bug fortran/79933] gfortran no longer able to compile dolfyn benchmark

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

[Bug fortran/79933] gfortran no longer able to compile dolfyn benchmark

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

[Bug fortran/79930] Potentially Missed Optimisation for MATMUL / DOT_PRODUCT

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79930 --- Comment #6 from Jerry DeLisle --- Thanks Thomas, somehow I thought we would have built the temporary to do this. (Well actully we do, but after the frontend passes) Now we get: $ gfc -O2 tp_array.f90 $ time ./a.out This code variant

[Bug fortran/79930] Potentially Missed Optimisation for MATMUL / DOT_PRODUCT

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

[Bug fortran/78670] [F03] Incorrect file position with namelist read under DTIO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78670 --- Comment #2 from Jerry DeLisle --- Preliminary patch given in PR78854

[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854 --- Comment #12 from Jerry DeLisle --- Here is a modified test case where I test the iotype and if its is NAMELIST, I format the output to what would be expected. Since there is no user defined namelist read, it just uses default reading of the

[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854 --- Comment #11 from Jerry DeLisle --- Created attachment 40885 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40885=edit A preliminary patch. Any and all testing greatly appreciated. I am regression testing this now. I wanted to get it

[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841 --- Comment #5 from Jerry DeLisle --- Author: jvdelisle Date: Sat Mar 4 03:13:34 2017 New Revision: 245891 URL: https://gcc.gnu.org/viewcvs?rev=245891=gcc=rev Log: 2017-03-03 Jerry DeLisle PR fortran/79841

[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79841 --- Comment #4 from Jerry DeLisle --- I will commit this: diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c index 3ca23493..753dc5ad 100644 --- a/gcc/fortran/openmp.c +++ b/gcc/fortran/openmp.c @@ -3732,7 +3732,7 @@

[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

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

[Bug fortran/79841] Inconsistent diagnostics in fortran/openmp.c, function check_symbol_not_pointer

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

[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854 --- Comment #10 from Jerry DeLisle --- We are not handling the internal unit check correctly in unit.c (get_unit) and we return a NULL to the caller which is then interpreted as an error. I am working on the fix now. (just a little head

[Bug fortran/79739] ICE with some interesting code

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79739 --- Comment #1 from Jerry DeLisle --- Created attachment 40839 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=40839=edit Combined to one file. Compile slightly reduced file with gfcortran -fopenmp cafmain.f90

[Bug fortran/79739] New: ICE with some interesting code

Assignee: unassigned at gcc dot gnu.org Reporter: jvdelisle at gcc dot gnu.org Target Milestone: --- Three files. While testing some threading concept. Note: This is not an actual coarray program. Compile with: gfortran -fopenmp cafmain.f90 cafi.f90 caf.f90 Compiles and runs fine

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 --- Comment #6 from Jerry DeLisle --- (In reply to Paul Thomas from comment #5) > (In reply to Jerry DeLisle from comment #3) > > (In reply to janus from comment #2) > > > (In reply to janus from comment #0) > > > > It seems like the first

[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854 --- Comment #9 from Jerry DeLisle --- (In reply to janus from comment #1) > This essentially blocks PR 78661, for which it is very hard to write a > proper test case as long as this bug is unfixed. Janus, you could open a file with status

[Bug libfortran/79540] [7 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79540 --- Comment #4 from Jerry DeLisle --- Possibly due to r240018 which is fix for pr77393.

[Bug libfortran/79540] [7 Regression] FAIL: gfortran.dg/fmt_fw_d.f90 -O0 execution test

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

[Bug fortran/78854] [F03] DTIO namelist output not working on internal unit

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78854 --- Comment #8 from Jerry DeLisle --- Sorry for the delay here. The unit number passed to the users dtio procedure is 0, so thats clearly wrong. I will see if I can fix that and see what happens.

[Bug fortran/79430] [7 Regression] action of statement incorrectly optimised away

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

[Bug fortran/60913] [OOP] Memory leak with allocatable polymorphic function result (in type-bound operator)

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

[Bug fortran/78661] [OOP] Namelist output missing object designator under DTIO

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78661 --- Comment #19 from Jerry DeLisle --- (In reply to janus from comment #18) > Created attachment 40364 [details] > updated patch > > Here is an updated patch, which fixes all wrong-code issues AFAICS. It > includes improved handling of

[Bug fortran/59781] [5/6 Regression] [F03] Incorrect initialisation of derived type

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

[Bug fortran/78881] [F03] reading from string with DTIO procedure does not work properly

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78881 --- Comment #3 from Jerry DeLisle --- (In reply to janus from comment #2) > (In reply to janus from comment #0) > > It seems like the first character is being swallowed somewhere ... > > Moreover the EOF is supposed to be an EOR? I will start

[Bug fortran/78864] ICE in dtio_procs_present, at fortran/resolve.c:13819

||jvdelisle at gcc dot gnu.org Resolution|--- |DUPLICATE --- Comment #2 from Jerry DeLisle --- This is a DUP of reopened 78659, I will include your test case as part of it. *** This bug has been marked as a duplicate of bug 78659 ***

[Bug fortran/78659] [F03] Spurious "requires DTIO" reported against namelist statement

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78659 Jerry DeLisle changed: What|Removed |Added CC||gerhard.steinmetz.fortran@t

<    3   4   5   6   7   8   9   10   11   12   >