[Bug fortran/71404] [7 Regression] 416.gamess in SPEC CPU 2006 failed to build

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71404

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #5 from Jerry DeLisle  ---
I am on it. Thanks for reduction. I can "see" the problem.

[Bug fortran/71404] [7 Regression] 416.gamess in SPEC CPU 2006 failed to build

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71404

--- Comment #2 from Jerry DeLisle  ---
I can only guess until I get a test case. Perhaps the undo_symbols was too
agressive.

[Bug fortran/52393] I/O: "READ format" statement with parenthesed default-char-expr

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52393

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Jerry DeLisle  ---
Fixed on trunk and closing

[Bug fortran/52393] I/O: "READ format" statement with parenthesed default-char-expr

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52393

--- Comment #12 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri Jun  3 01:25:31 2016
New Revision: 237051

URL: https://gcc.gnu.org/viewcvs?rev=237051=gcc=rev
Log:
2016-06-02  Jerry DeLisle  

PR fortran/52393
* gfortran.dg/fmt_read_3.f90: Fix typo.
* gfortran.dg/fmt_read_4.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_read_4.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/fmt_read_3.f90

[Bug fortran/52393] I/O: "READ format" statement with parenthesed default-char-expr

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52393

--- Comment #11 from Jerry DeLisle  ---
Author: jvdelisle
Date: Wed Jun  1 17:06:50 2016
New Revision: 237003

URL: https://gcc.gnu.org/viewcvs?rev=237003=gcc=rev
Log:
2016-06-01  Jerry DeLisle  

PR fortran/52393
* io.c (match_io): For READ, try to match a default character
expression. If found, set the dt format expression to this,
otherwise go back and try control list.

PR fortran/52393
* gfortran.dg/fmt_read_3.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/fmt_read_3.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/io.c
trunk/gcc/testsuite/ChangeLog

[Bug libfortran/48925] Code cleanup in write_float.def

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48925

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #4 from Jerry DeLisle  ---
Working on this.

[Bug fortran/66461] [4.9/5/6/7 Regression] ICE on missing end program in fixed source

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #28 from Jerry DeLisle  ---
Fixed and closing

[Bug fortran/66461] [4.9/5/6/7 Regression] ICE on missing end program in fixed source

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461

--- Comment #27 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri May 27 04:47:11 2016
New Revision: 236808

URL: https://gcc.gnu.org/viewcvs?rev=236808=gcc=rev
Log:
2016-05-26  Jerry DeLisle  

Backport from trunk.
PR fortran/66461
* scanner.c (gfc_next_char_literal): Clear end_flag when adjusting
current locus back to old_locus.

Backport from trunk.
PR fortran/66461
* gfortran.dg/unexpected_eof.f: New test

Added:
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/unexpected_eof.f
Modified:
branches/gcc-4_9-branch/gcc/fortran/ChangeLog
branches/gcc-4_9-branch/gcc/fortran/scanner.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug fortran/66461] [4.9/5/6/7 Regression] ICE on missing end program in fixed source

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461

--- Comment #26 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri May 27 03:17:03 2016
New Revision: 236807

URL: https://gcc.gnu.org/viewcvs?rev=236807=gcc=rev
Log:
2016-05-26  Jerry DeLisle  

Backport from trunk.
PR fortran/66461
* scanner.c (gfc_next_char_literal): Clear end_flag when adjusting
current locus back to old_locus.

Backport from trunk.
PR fortran/66461
* gfortran.dg/unexpected_eof.f: New test.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/unexpected_eof.f
Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/scanner.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog

[Bug fortran/66461] [4.9/5/6/7 Regression] ICE on missing end program in fixed source

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461

--- Comment #25 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri May 27 01:05:21 2016
New Revision: 236806

URL: https://gcc.gnu.org/viewcvs?rev=236806=gcc=rev
Log:
2016-05-26  Jerry DeLisle  

Backport from trunk.
PR fortran/66461
* scanner.c (gfc_next_char_literal): Clear end_flag when adjusting
current locus back to old_locus.

Backport from trunk.
PR fortran/66461
* gfortran.dg/unexpected_eof.f: New test

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/unexpected_eof.f
Modified:
branches/gcc-6-branch/gcc/fortran/ChangeLog
branches/gcc-6-branch/gcc/fortran/scanner.c
branches/gcc-6-branch/gcc/testsuite/ChangeLog

[Bug libfortran/71123] Namelist read failure on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71123

Jerry DeLisle  changed:

   What|Removed |Added

 CC||ktietz at gcc dot gnu.org

--- Comment #6 from Jerry DeLisle  ---
Kai,

If you have time, could you check this actually works on Windows before I close
it. It fixes my linux version of the bug.

Thanks,

Jerry

[Bug fortran/52393] I/O: "READ format" statement with parenthesed default-char-expr

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52393

--- Comment #10 from Jerry DeLisle  ---
Created attachment 38577
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38577=edit
Final patch, regression tested

I will submit this patch to list for approval.

[Bug fortran/52393] I/O: "READ format" statement with parenthesed default-char-expr

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52393

--- Comment #9 from Jerry DeLisle  ---
The following patch allows the program to compile. I just need to check the
standard to confirm if the syntax in question also applies to WRITE.

diff --git a/gcc/fortran/io.c b/gcc/fortran/io.c
index da0e1c5e..296beef4 100644
--- a/gcc/fortran/io.c
+++ b/gcc/fortran/io.c
@@ -3751,7 +3751,7 @@ match_io (io_kind k)
 {
   /* Before issuing an error for a malformed 'print (1,*)' type of
 error, check for a default-char-expr of the form ('(I0)').  */
-  if (k == M_PRINT && m == MATCH_YES)
+  if (m == MATCH_YES)
{
  /* Reset current locus to get the initial '(' in an expression.  */
  gfc_current_locus = where;

[Bug libfortran/71123] Namelist read failure on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71123

--- Comment #5 from Jerry DeLisle  ---
(In reply to Jerry DeLisle from comment #4)
> Author: jvdelisle
> Date: Tue May 24 06:16:00 2016
> New Revision: 236629
> 
> URL: https://gcc.gnu.org/viewcvs?rev=236629=gcc=rev
> Log:
> 2016-05-23  Jerry DeLisle  
> 
>   PR libgfortran/71123
>   * io/list_read (eat_spaces): Eat '\r' as part of spaces.
> fix change log
> 
> Modified:
> trunk/libgfortran/ChangeLog

(In reply to Jerry DeLisle from comment #21)
> Author: jvdelisle
> Date: Tue May 24 06:11:21 2016
> New Revision: 236628
> 
> URL: https://gcc.gnu.org/viewcvs?rev=236628=gcc=rev
> Log:
> 2016-05-23  Jerry DeLisle  
> 
>   PR libgfortran/70684
>   * io/list_read (eat_spaces): Eat '\r' as part of spaces.
> 
>   * gfortran.dg/namelist_90.f: New test
> 
> Added:
> trunk/gcc/testsuite/gfortran.dg/namelist_90.f
> Modified:
> trunk/gcc/testsuite/ChangeLog
> trunk/libgfortran/ChangeLog
> trunk/libgfortran/io/list_read.c

Had wrong PR number in changelog. Fixed

[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684

--- Comment #22 from Jerry DeLisle  ---
(In reply to Jerry DeLisle from comment #21)
> Author: jvdelisle
> Date: Tue May 24 06:11:21 2016
> New Revision: 236628
> 
> URL: https://gcc.gnu.org/viewcvs?rev=236628=gcc=rev
> Log:
> 2016-05-23  Jerry DeLisle  
> 
>   PR libgfortran/70684
>   * io/list_read (eat_spaces): Eat '\r' as part of spaces.
> 
>   * gfortran.dg/namelist_90.f: New test
> 
> Added:
> trunk/gcc/testsuite/gfortran.dg/namelist_90.f
> Modified:
> trunk/gcc/testsuite/ChangeLog
> trunk/libgfortran/ChangeLog
> trunk/libgfortran/io/list_read.c

My apologies, this should be for PR71223

[Bug libfortran/71123] Namelist read failure on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71123

--- Comment #4 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue May 24 06:16:00 2016
New Revision: 236629

URL: https://gcc.gnu.org/viewcvs?rev=236629=gcc=rev
Log:
2016-05-23  Jerry DeLisle  

PR libgfortran/71123
* io/list_read (eat_spaces): Eat '\r' as part of spaces.
fix change log

Modified:
trunk/libgfortran/ChangeLog

[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684

--- Comment #21 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue May 24 06:11:21 2016
New Revision: 236628

URL: https://gcc.gnu.org/viewcvs?rev=236628=gcc=rev
Log:
2016-05-23  Jerry DeLisle  

PR libgfortran/70684
* io/list_read (eat_spaces): Eat '\r' as part of spaces.

* gfortran.dg/namelist_90.f: New test

Added:
trunk/gcc/testsuite/gfortran.dg/namelist_90.f
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/list_read.c

[Bug fortran/66461] [4.9/5/6/7 Regression] ICE on missing end program in fixed source

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461

--- Comment #24 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue May 24 04:15:39 2016
New Revision: 236627

URL: https://gcc.gnu.org/viewcvs?rev=236627=gcc=rev
Log:
2016-05-23  Jerry DeLisle  

PR fortran/66461
* scanner.c (gfc_next_char_literal): Clear end_flag when adjusting
current locus back to old_locus.

* gfortran.dg/unexpected_eof.f: New test

Added:
trunk/gcc/testsuite/gfortran.dg/unexpected_eof.f
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/scanner.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/66461] [4.9/5/6/7 Regression] ICE on missing end program in fixed source

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461

--- Comment #22 from Jerry DeLisle  ---
This patch, by itself, fixes the whole issue.

Regression tested on x86-64.

Mikael shook the old brain cells.

diff --git a/gcc/fortran/scanner.c b/gcc/fortran/scanner.c
index f4dedd69..6a7a5b68 100644
--- a/gcc/fortran/scanner.c
+++ b/gcc/fortran/scanner.c
@@ -1556,6 +1556,7 @@ restart:
 not_continuation:
   c = '\n';
   gfc_current_locus = old_loc;
+  end_flag = 0;

 done:
   if (c == '\n')

One of them notorious one liners.

Thanks all for the help.

[Bug fortran/66461] [4.9/5/6/7 Regression] ICE on missing end program in fixed source

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461

--- Comment #21 from Jerry DeLisle  ---
(In reply to Mikael Morin from comment #20)
> (In reply to Mikael Morin from comment #19)
> > 
> > what I don't understand is that error itself, 
> 
> It comes from scanner.c's end_flag which is cleared on the first match, but
> it is set at some point later, and it's not restored to its cleared state
> when the locus is restored before the second match.
> The end_flag basically disables all of the continuation and comment lines
> handling in gfc_next_char_literal.

Mikael thanks for help! I have not checked, but unexpected_eof in parse.c does
not clear end_flag after backing up.  Maybe thats it.

[Bug fortran/66461] [4.9/5/6/7 Regression] ICE on missing end program in fixed source

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461

--- Comment #17 from Jerry DeLisle  ---
Steve, I like your patch much better. I will test and commit for you with a
Changelog

Dominique, Do you have a version of gfortran where this does not give an ICE???

I have just one other thing to check first

[Bug fortran/66461] [4.9/5/6/7 Regression] ICE on missing end program in fixed source

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461

--- Comment #14 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #13)
--- snip ---
> 
> Although I partially agree with that, I don't understand why
> 
>  if ( x(1) < 0 .or.  &
>  x(2) < 0 ) print *, x
> 
> does not trigger any matching error in free form, while
> 
>  if ( x(1) < 0 .or.
>  &x(2) < 0 ) print *, x
> 
> does in fixed form. IMO there is latent bug in the parser.

I dont think in the parser.  I agree this is an odd duck.  Theoretically
continuation markers are removed and the parser only sees one line.  One
difference between fixed and free is that fixed lines are padded out to the
max-line-length with spaces.

Another odd thing I found is on or about scanner.c:1530 is this:

  if (c == '0' || c == ' ' || c == '\n')

What is the significance of a zero digit in that position.  Is this some old
syntax.  I have deleted it and also tried changing it to '\0', as in NULL, but
it has no effect on the problem at hand or the testsuite.

Also when an unexpected end of file is encountered, the locus is backed up one
line.  It could be that one line is trying to be parsed a second time and
giving the error. I have not had time to try additional debuggery. This gets
into an area we engineers call the $#!t to worth ratio. ;)

[Bug libfortran/71123] Namelist read failure on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71123

--- Comment #3 from Jerry DeLisle  ---

This patch regression tests OK and fixes the namelist read.


diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index b8e174c5..6ea6007a 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -418,7 +418,7 @@ eat_spaces (st_parameter_dt *dtp)
   /* Now skip spaces, EOF and EOL are handled in next_char.  */
   do
 c = next_char (dtp);
-  while (c != EOF && (c == ' ' || c == '\t'));
+  while (c != EOF && (c == ' ' || c == '\t' || c == '\r'));

   unget_char (dtp, c);
   return c;

[Bug fortran/66461] [4.9/5/6/7 Regression] ICE on missing end program in fixed source

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461

--- Comment #12 from Jerry DeLisle  ---
I have a patch testing for this.  I am not sure this is a regression.  I see it
as far back as 4.5.  I don't have any earlier builds.  My thinking is that
since this is an ICE on invalid code, I don't want to bother with backports,
unless this is just really burning someone somehow.

[Bug libfortran/71123] Namelist read failure on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71123

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #1 from Jerry DeLisle  ---
I will investigate.

[Bug libfortran/71123] New: Namelist read failure on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71123

Bug ID: 71123
   Summary: Namelist read failure on Windows
   Product: gcc
   Version: unknown
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: libfortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jvdelisle at gcc dot gnu.org
  Target Milestone: ---

Posted on the gfortran list.

The following program works fine under Linux but fails under Windows.

  IMPLICIT REAL*8(A-H,O-Z)
  DIMENSION SENID(30)
  NAMELIST /FITH/ SENID
  DO I=1,30
 SENID(I) = I
  ENDDO
  OPEN(UNIT=7,FILE='TEST.OUT',FORM='FORMATTED',
 * STATUS='NEW',ACTION='READWRITE')
  WRITE(7,NML=FITH)
  REWIND(7)
  READ(7,NML=FITH)
  END

[Bug fortran/70959] [6/7 Regression] Invalid type determination due to expression in a type declaration statement

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70959

--- Comment #3 from Jerry DeLisle  ---
I have tried changing the matching order so that integer constants are matched
before real or complex.  It fixes the reported problem but results in numerous
test suite failures.

I wonder. If we just change the warning message to "possible change of value in
conversion ...  " would this be sufficient?  It is only a warning.  Otherwise
we will have to work on some fairly intricate code.  The revision mentioned in
comment #2 only added the warning feature, it did not change the matching
codes.

[Bug fortran/66461] [4.9/5/6/7 Regression] ICE on missing end program in fixed source

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66461

--- Comment #10 from Jerry DeLisle  ---
This is a bandaid, but it works.

diff --git a/gcc/fortran/match.c b/gcc/fortran/match.c
index 2490f856..726973a6 100644
--- a/gcc/fortran/match.c
+++ b/gcc/fortran/match.c
@@ -1438,7 +1438,16 @@ gfc_match_if (gfc_statement *if_type)
   if (m == MATCH_ERROR)
 return MATCH_ERROR;

-  gfc_match (" if ( %e ) ", );/* Guaranteed to match.  */
+  m = gfc_match (" if ( %e ) ", );  /* Not always guaranteed to match. 
*/
+
+  if (m == MATCH_ERROR)
+{
+  /* Under some invalid conditions like unexpected end of file, one
+can get an error in the match. We bail out here and hope for
+the best (the best being an error reported somewhere else.  */
+  gfc_clear_error ();
+  return MATCH_YES;
+}

   m = gfc_match_pointer_assignment ();
   if (m == MATCH_YES)

Probably need to test some variations.  I have dug around quite a bit in the
scanner.c and other places trying to understand why this bug is only in fixed
source. To no avail, and not sure its worth more time. I have even tried saving
the know good locus and retoring just before the failing match attempt and it
does not work.

[Bug fortran/71087] scipy amos crash

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71087

--- Comment #9 from Jerry DeLisle  ---
(In reply to Nick from comment #0)
> Created attachment 38475 [details]
> Source code trigging bug
> 
> - Compiling amos/zunhj.f in scipy package crashes with:
> 
> zunhj.f:1:0:
> 
>SUBROUTINE ZUNHJ(ZR, ZI, FNU, IPMTR, TOL, PHIR, PHII, ARGR, ARGI,
>  
> internal compiler error: Illegal instruction
> 0xa64def crash_signal
> ../../gcc/toplev.c:333
> Please submit a full bug report,
> with preprocessed source if appropriate.
> Please include the complete backtrace with any bug report.
> See  for instructions.
> 
> 
> - This bug happens whenever -OX, for X>=1 is in effect.
> 

Have you tried using -march=opteron   

There are subtle differences between plain vanilla x86 with different chips. 
If the gcc build was for Intel on Intel it may be defaulting the instruction
set.

[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #20 from Jerry DeLisle  ---
and ...

[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684

--- Comment #19 from Jerry DeLisle  ---
Fixed on 7, 6, 5, and 4.9.  and closing.  Please let me know if further
problems arise.

[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684

--- Comment #18 from Jerry DeLisle  ---
Author: jvdelisle
Date: Fri May  6 01:18:59 2016
New Revision: 235941

URL: https://gcc.gnu.org/viewcvs?rev=235941=gcc=rev
Log:
2016-05-05  Jerry DeLisle  

Backport from trunk.
PR libgfortran/70684
* io/list_read (next_char): Add '\r' to check for end of line.
factor. (two places)

PR libgfortran/70684
* gfortran.dg/list_read_14.f90: New test.

Added:
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/list_read_14.f90
Modified:
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/libgfortran/ChangeLog
branches/gcc-4_9-branch/libgfortran/io/list_read.c

[Bug fortran/70959] Invalid type determination due to expression in a type declaration statement

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70959

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #1 from Jerry DeLisle  ---
With the parenthesis around the constant, it is being interpreted as a complex
number. The check in arith.c is taking this as a component of the complex
constant.

match_complex_constant in primary.c probably returns a MATCH_NO, but I think
the warning is occurring in the middle of the attempted matching process.

#0  gfc_warning_now (opt=opt@entry=201, 
gmsgid=gmsgid@entry=0x140c530 "Change of value in conversion from %qs to
%qs at %L") at ../../trunk/gcc/fortran/error.c:1148
#1  0x0062e0ce in gfc_int2real (src=0x1ff3db0, kind=4)
at ../../trunk/gcc/fortran/arith.c:2079
#2  0x006abb35 in match_sym_complex_part (result=0x7fffd400)
at ../../trunk/gcc/fortran/primary.c:1289
#3  match_complex_part (result=0x7fffd400)
at ../../trunk/gcc/fortran/primary.c:1314
#4  0x006abbc2 in match_complex_constant (
result=result@entry=0x7fffd690)
at ../../trunk/gcc/fortran/primary.c:1347

[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684

--- Comment #17 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue May  3 00:51:30 2016
New Revision: 235801

URL: https://gcc.gnu.org/viewcvs?rev=235801=gcc=rev
Log:
2016-05-02  Jerry DeLisle  

Backport from mainline
PR libgfortran/70684
* gfortran.dg/list_read_14.f90: New test.

Backport from trunk.
PR libgfortran/70684
* io/list_read (check_buffers): Add '\r' to check for end of line.

Added:
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/list_read_14.f90
Modified:
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/libgfortran/ChangeLog
branches/gcc-5-branch/libgfortran/io/list_read.c

[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684

--- Comment #16 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Apr 24 05:07:21 2016
New Revision: 235391

URL: https://gcc.gnu.org/viewcvs?rev=235391=gcc=rev
Log:
2016-04-23  Jerry DeLisle  

PR libgfortran/70684
* io/list_read (check_buffers): Add '\r' to check for end of line.
factor.

* gfortran.dg/list_read_14.f90: New test.

Added:
branches/gcc-6-branch/gcc/testsuite/gfortran.dg/list_read_14.f90
Modified:
branches/gcc-6-branch/gcc/testsuite/ChangeLog
branches/gcc-6-branch/libgfortran/ChangeLog
branches/gcc-6-branch/libgfortran/io/list_read.c

[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684

--- Comment #15 from Jerry DeLisle  ---
(In reply to Andy May from comment #14)
--- snip ---
> 
> Of course, I really appreciate the work that goes into this. I've already
> made a local patch file with your fix so that the mxe.cc gcc builds with it
> and now our program runs correctly.
> 

Your testing and confirming the original issue is fixed helps greatly, thanks.

> I look after a project with ~2.5 million lines of Fortran, some which were
> written 40 years ago on punch cards.

So many of us learned on those punch cards. (yeeehah!)

[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684

--- Comment #13 from Jerry DeLisle  ---
(In reply to Andy May from comment #12)
> I don't know that it's necessary or desired to support both '\n' and '\r' as
> eol, but instead the native eol just needs to be used consistently
> everywhere, for example something like the following pseudo code:
> 
> #ifdef __MINGW32__
> #define EOL '\r'
> #else
> #define EOL '\n'
> #endif
> ...
> dtp->u.p.at_eol = (c == EOL || c == EOF);
> 

Each compiler may choose to do this a little differently.  In our case we see
/r and look for the /n to eat it. If one is interested in reading a /r as data
one should use access="stream" which allows you to do what ever you want.

I could do something like the above, but it would touch quite a few places in
the code which opens it up for mistakes and regressions (admittedly probably
not any more than we get now and we could improve maintainability). Our
personal time is a factor too.  I have bigger bugs to fry and I don't get paid
to do this.  I do it in my spare time for the greater good of all.  Regardless
I do appreciate all input in this process of "open" software. (I should further
audit the code when I get a chance)

[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684

--- Comment #10 from Jerry DeLisle  ---
(In reply to Ray Donnelly from comment #9)
> Should the other two places - next_char_default () and next_char_internal ()
> -that also do:
> 
> dtp->u.p.at_eol = (c == '\n' || c == EOF);
> 
> not check for '\r' too?

Placing it in next_char_default gives us a regression elsewhere.  I am actually
checking to see if after my patch whether the line above is even needed in
next_char_default.  There are a lot of subtle interactions that go into this
code, so i tread lightly.

I will not close this until I have the initial patch back ported and have done
some more testing and others have had time to do more testing.  If you happen
to find a use case that fails, of course, let me know, and thanks.

[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684

--- Comment #8 from Jerry DeLisle  ---
Author: jvdelisle
Date: Tue Apr 19 19:24:28 2016
New Revision: 235220

URL: https://gcc.gnu.org/viewcvs?rev=235220=gcc=rev
Log:
2016-04-19  Jerry DeLisle  

PR libgfortran/70684
* io/list_read (check_buffers): Add '\r' to check for end of line.
factor.

* gfortran.dg/list_read_14.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/list_read_14.f90
Modified:
trunk/gcc/testsuite/ChangeLog
trunk/libgfortran/ChangeLog
trunk/libgfortran/io/list_read.c

[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684

--- Comment #7 from Jerry DeLisle  ---
The following patch fixes the issue.

diff --git a/libgfortran/io/list_read.c b/libgfortran/io/list_read.c
index e24b3922..b8e174c5 100644
--- a/libgfortran/io/list_read.c
+++ b/libgfortran/io/list_read.c
@@ -197,7 +197,7 @@ check_buffers (st_parameter_dt *dtp)
 }

 done:
-  dtp->u.p.at_eol = (c == '\n' || c == EOF);
+  dtp->u.p.at_eol = (c == '\n' || c == '\r' || c == EOF);
   return c;
 }

Regression tested on trunk with Linux.

[Bug libfortran/70684] [4.9/5/6/7 Regression] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684

--- Comment #6 from Jerry DeLisle  ---
The regression occurred at r200238, which was a fix for PR57633.

I am working on a fix.

[Bug libfortran/70684] [Regression 5.3, 6] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684

--- Comment #3 from Jerry DeLisle  ---
This slightly modified version of the testcase shows the bug with Linux:

program test
implicit none
integer,parameter :: isize=12
integer,parameter :: funit=12
integer :: i
character(1), parameter :: cr=char(13)

double precision, dimension(isize) :: a

do i=1,isize
 a(i)=dble(i)
enddo

write(6,*)'Value to write'
do i=1,isize
 write(6,*)a(i)
enddo

open(funit,file='test.txt')
write(funit,'(1x,6(f25.20,'',''),a)') (a(i),i=1,6), cr
write(funit,'(1x,6(f25.20,'',''),a)') (a(i),i=7,12), cr
close(funit)

do i=1,isize
 a(i)=0d0
enddo

open(funit,file='test.txt')
read(funit,*) (a(i),i=1,isize)
close(funit)

write(6,*)'Values after read'
do i=1,isize
 write(6,*)a(i)
enddo

end

[Bug libfortran/70684] [Regression 5.3, 6] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-04-15
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org
Summary|incorrect reading of values |[Regression 5.3, 6]
   |from file on Windows|incorrect reading of values
   ||from file on Windows
 Ever confirmed|0   |1

--- Comment #2 from Jerry DeLisle  ---
Confirmed, works on 4.9 Fails on 5.3

Marking as a regression.

[Bug libfortran/70684] incorrect reading of values from file on Windows

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70684

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #1 from Jerry DeLisle  ---
You are doing list direct reads here.  You will see where /r is treated as a
separator. Regardless, this has all worked before without a problem, so it may
be your build of gcc has a problem.

I will investigate here a bit with your test case and get back to you.

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

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68600

--- Comment #13 from Jerry DeLisle  ---
(In reply to Thomas Koenig from comment #12)
> (In reply to Jerry DeLisle from comment #11)

---snip--
> 
> May I suggest reading the docs? ;-)
> 
--- snip ---

>  The default value for N is the value specified for
>  `-fblas-matmul-limit' if this option is specified, or unlimitited
>  otherwise.

Oh gosh!, Sorry about that Thomas. I just did not see it.  And I was even
looking for it because I thought it was there! This is excellent because I am
working on a modification to the run-time libraries. This will give us
something like:

 
 Matmul  
 fixed   
 Size  Loops explicit   NewMatmul
 
   16  2000  1.496  1.719
   32  2000  2.427  1.784
   64  2000  1.343  1.967
  128  2000  1.657  2.113
  256   477  2.660  2.185
  51259  2.027  2.195
 1024 7  1.530  2.208
 2048 1  1.516  2.210

On this particular machine, the inlining at high levels of optimization has
some sweet spots at size of 32 x 32 for example, so allowing the tuning is
essential depending on users application.

[Bug fortran/52884] double precision constants promoted to 16 byte by -fdefault-real-8

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52884

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #3 from Jerry DeLisle  ---
May I suggest the following wording:

-fdefault-real-8
Set the default real type to an 8 byte wide type. This option
also affects the kind of non-double real constants like 1.0.
This option promotes the default width of DOUBLE PRECISION
and double real constants like 1.d0 to 16 bytes if possible.
If -fdefault-double-8 is given along with -fdefault-real-8,
DOUBLE PRECISION and double real constants are not promoted.
Note, -fdefault-real-8, does not promote variables with explicit
kind declarations.

-fdefault-double-8
Set the DOUBLE PRECISION type to an 8 byte wide type. Do nothing
if this is already the default. This option prevents -fdefault-real-8
from promoting DOUBLE PRECISION and double real constants like 1.d0
to 16 bytes.

[Bug fortran/67039] Documentation of pseudorandom number intrinsics is incorrect

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67039

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #7 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #6)
> I am planning to submit the following patch

---snip---

I think this word should be singular. 
> +@code{RANDOM_SEED} to initialize the pseudo-random numbers <= no 's'
> +generator and @code{RANDOM_NUMBER} to generate pseudo-random numbers.
> +These subroutines should be used in new codes.

Even if internally there may be multiple 'generators' involved, from the user
perspective it is just one generator.

[Bug fortran/60751] Extra comma in WRITE statement not diagnosed

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60751

--- Comment #18 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #17)
> Note that the extra comma is used in the following tests:
> 
> gfortran.dg/array_constructor_49.f90
> gfortran.dg/integer_exponentiation_6.F90
> gfortran.dg/graphite/pr38083.f90
> 
> Any reason to keep it?

No, and I am planning to fix the diagnostic on this.

[Bug fortran/51820] [doc] underscoring documentation incorrect

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=51820

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #3 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #2)
> Is the following patch a step in the right direction?

---snip---

This all looks good to me except the following:

>  @item -fsecond-underscore
>  @opindex @code{fsecond-underscore}
> @@ -1355,8 +1365,7 @@ By default, GNU Fortran appends an under
>  names.  If this option is used GNU Fortran appends two
>  underscores to names with underscores and one underscore to external names
>  with no underscores.  GNU Fortran also appends two underscores to
> -internal names with underscores to avoid naming collisions with external
> -names.
> +internal names with underscores.
>  
>  This option has no effect if @option{-fno-underscoring} is
>  in effect.  It is implied by the @option{-ff2c} option.

It is confusing to me about names with underscores. For example, on internal
names, does foo_ become foo__ or foo___, appending one underscore to the
existing for a total of two or appending two more to the existing for a total
of three underscores.  I think the wording needs to be a little more concise.

[Bug fortran/58000] Accept OPEN( ... NAME=) with -std=legacy

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=58000

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #4 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #3)
> Patch I am planning to submit
> 
> --- ../_clean/gcc/fortran/gfortran.texi   2016-01-04 19:51:09.0 
> +0100
> +++ gcc/fortran/gfortran.texi 2016-04-10 14:00:11.0 +0200
> @@ -2148,6 +2148,7 @@ code that uses them running with the GNU
>  @c * Omitted arguments in procedure call::
>  * Alternate complex function syntax::
>  * Volatile COMMON blocks::
> +* OPEN( ... NAME=)::
>  @end menu
>  
>  
> @@ -2355,6 +2356,19 @@ invalid standard Fortran syntax and is n
>  
>  
>  
> +@node OPEN( ... NAME=)
> +@subsection @code{OPEN( ... NAME=)}
> +@cindex @code{NAM}
> +
> +Some Fortran compilers, including @command{g77}, let the user declare
> +@code{OPEN( ... NAME=)}. This is
> +invalid standard Fortran syntax and is not supported by
> +@command{gfortran}.  @code{OPEN( ... NAME=)} should be replaced
> +with @code{OPEN( ... FILE=)}.
> +
> +
> +
> +@c -
>  @c -
>  @c Mixed-Language Programming
>  @c -

Approved! Please proceed.

[Bug fortran/68566] ICE on using unusable array in reshape (double free or corruption)

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68566

--- Comment #10 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sat Apr  9 19:09:02 2016
New Revision: 234864

URL: https://gcc.gnu.org/viewcvs?rev=234864=gcc=rev
Log:
2016-04-09  Jerry DeLisle  

PR fortran/68566
* array.c (match_array_element_spec): Add check for non-integer.
* simplify.c (gfc_simplify_reshape): If source shape is NULL return.

PR fortran/68566
* gfortran.dg/pr36192.f90: Update test.
* gfortran.dg/pr36192_1.f90: Update test.
* gfortran.dg/real_dimension_1.f: Update test.
* gfortran.dg/parameter_array_init_7.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/parameter_array_init_7.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/array.c
trunk/gcc/fortran/simplify.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/pr36192.f90
trunk/gcc/testsuite/gfortran.dg/pr36192_1.f90
trunk/gcc/testsuite/gfortran.dg/real_dimension_1.f

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

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68600

--- Comment #11 from Jerry DeLisle  ---
(In reply to Jerry DeLisle from comment #8)
> Created attachment 36887 [details]
> A faster version
> 
> I took the example code found in
> http://wiki.cs.utexas.edu/rvdg/HowToOptimizeGemm/ where the register based
> vector computations are explicitly called via the SSE registers and
> converted it to use the builtin gcc vector extensions.  I had to experiment
> a little to get some of the equivalent operations of the original code.
> 
> With only -O2 and march=native I am getting good results. I need to roll
> this into the other test program yet to confirm the gflops are being
> computed correctly.  The diff value is comparing to the reference naive
> results to check the computation is correct.
> 
> MY_MMult = [
> Size: 40, Gflops: 1.828571e+00, Diff: 2.664535e-15 
> Size: 80, Gflops: 3.696751e+00, Diff: 7.105427e-15 
> Size: 120, Gflops: 4.051583e+00, Diff: 1.065814e-14 
> Size: 160, Gflops: 4.015686e+00, Diff: 1.421085e-14 
> Size: 200, Gflops: 4.029212e+00, Diff: 2.131628e-14 
> Size: 240, Gflops: 3.972414e+00, Diff: 2.486900e-14 
> Size: 280, Gflops: 3.881188e+00, Diff: 2.842171e-14 
> Size: 320, Gflops: 3.872371e+00, Diff: 3.552714e-14 
> Size: 360, Gflops: 3.887676e+00, Diff: 4.973799e-14 
> Size: 400, Gflops: 3.862052e+00, Diff: 4.973799e-14 
> Size: 440, Gflops: 3.886575e+00, Diff: 4.973799e-14 
> Size: 480, Gflops: 3.910124e+00, Diff: 6.039613e-14 
> Size: 520, Gflops: 3.863706e+00, Diff: 6.394885e-14 
> Size: 560, Gflops: 3.976947e+00, Diff: 6.750156e-14 
> Size: 600, Gflops: 4.002631e+00, Diff: 7.460699e-14 
> Size: 640, Gflops: 3.992507e+00, Diff: 8.171241e-14 
> Size: 680, Gflops: 3.964570e+00, Diff: 9.237056e-14 
> Size: 720, Gflops: 3.973661e+00, Diff: 1.101341e-13 
> Size: 760, Gflops: 3.982346e+00, Diff: 1.065814e-13 
> Size: 800, Gflops: 3.869291e+00, Diff: 8.881784e-14 
> Size: 840, Gflops: 3.936271e+00, Diff: 1.065814e-13 
> Size: 880, Gflops: 3.931259e+00, Diff: 1.030287e-13 
> Size: 920, Gflops: 3.912907e+00, Diff: 1.207923e-13 
> Size: 960, Gflops: 3.938391e+00, Diff: 1.278977e-13 
> Size: 1000, Gflops: 3.945754e+00, Diff: 1.421085e-13

(In reply to Dominique d'Humieres from comment #10)
> > I think you are seeing the effects of inefficiencies of assumed-shape 
> > arrays.
> >
> > If you want to use matmul on very small matrix sizes, it is best to
> > use fixed-size explicit arrays.
> 
> Then IMO the matmul inlining should be restricted to fixed-size explicit
> arrays. Could this be done before the release of gcc-6?

I was experimenting some more here a few days ago.  I really think that
inlineing shold be disabled above some threshold.  On larger arrays, the
runtime library outperforms inline and right now by default the runtime
routines are never used unless you provide -fno-frontend-optimize which is
counter intuitive for the larger arrays.

If one compiles with -march=native -mavx -Ofast etc etc, the inline can do
fairly well on the larger, however when we update the runtime routines to
something like shown in comment #8 it will make even more sense to not do
inline all the time. (Unless of course we further optimize the
frontend-optimize to do better.)

[Bug fortran/52393] I/O: "READ format" statement with parenthesed default-char-expr

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=52393

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #8 from Jerry DeLisle  ---
Let me add this to my list and then I will investigate in a little while

[Bug fortran/68566] ICE on using unusable array in reshape (double free or corruption)

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68566

--- Comment #9 from Jerry DeLisle  ---
The following additional patchlet does the trick.

Still need to regression test.

diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index 2fc9dfaf..8fef30ce 100644
--- a/gcc/fortran/array.c
+++ b/gcc/fortran/array.c
@@ -421,6 +421,12 @@ match_array_element_spec (gfc_array_spec *as)
   if (!gfc_expr_check_typed (*upper, gfc_current_ns, false))
 return AS_UNKNOWN;

+  if ((*upper)->expr_type == EXPR_CONSTANT && (*upper)->ts.type != BT_INTEGER)
+{
+  gfc_error ("Expecting a scalar INTEGER expression at %C");
+  return AS_UNKNOWN;
+}
+
   if ((*upper)->expr_type == EXPR_FUNCTION && (*upper)->ts.type == BT_UNKNOWN
   && (*upper)->symtree && strcmp ((*upper)->symtree->name, "null") == 0)
 {

[Bug fortran/68566] ICE on using unusable array in reshape (double free or corruption)

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=68566

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #8 from Jerry DeLisle  ---
(In reply to Harald Anlauf from comment #5)
--- snip ---
> 
> Index: gcc/fortran/simplify.c
> ===
> --- gcc/fortran/simplify.c  (revision 234170)
> +++ gcc/fortran/simplify.c  (working copy)
> @@ -5163,6 +5163,9 @@
>|| !is_constant_array_expr (order_exp))
>  return NULL;
>  
> +  if (source->shape == NULL)
> +return NULL;
> +
>/* Proceed with simplification, unpacking the array.  */
>  
>mpz_init (index);
> 
> 

Although an error is thrown and no ICE, for the cases of comment #1, we get two
errors, one of which is bogus.

I believe the z2.f90 through z5.f90 need to be caught much earlier in syntax
checking

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70235

--- Comment #24 from Jerry DeLisle  ---
Dominiq, I have tested as much as I can with several variations of values of
the float and all looks good. I am ready to approve your patch when you are.

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70235

--- Comment #23 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #22)
> Created attachment 38107 [details]
> New patch with test.
> 
> With the patch we now get for y=6431.25
> 
> ru,-8pf18.2 y=  0.01
> 
> IMO this is the correct rounding. Does someone disagree with that?
> 
> What tests should be removed/added from gfortran.dg/fmt_pf.f90?

I think good.

With round up, Any x,  .01 >= x > 0.0 is .01
   .1 >= x > 0.0 is .1

[Bug fortran/69043] Trying to include a directory causes an infinite loop

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69043

Jerry DeLisle  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Jerry DeLisle  ---
Closing

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70235

--- Comment #20 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #19)
> Created attachment 38100 [details]
> Another patch with correct rounding
> 
> > While I think the handling of nafter < 0 is correct, it is probably
> > a too big hammer since the expected output should be all zeroes.
> 
> The attached patch does exactly that.

Nice work!

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70235

--- Comment #15 from Jerry DeLisle  ---
Created attachment 38091
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38091=edit
A more exhaustive testing program

This test allows at least visual inspection of the patterns. The test omits the
"starred" results where things dont fit the width.

The results at least look consistent using my previously attached updated
patch.

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70235

--- Comment #14 from Jerry DeLisle  ---
Created attachment 38090
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38090=edit
Updated patch correcting problem found by Dominique

This is what I came up with independent of Dominiques patch.  This patch is
much simpler.  Lets continue testing.

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70235

--- Comment #12 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #11)
> > Created attachment 38075 [details]
> > A patch for testing
> 
> With the patch and using the test attached to comment 5 with y = 1.0 and
> d=8, I get the following output
> 
> -8pf18.8 y=0.000.
> -7pf18.8 y=0.00.0
... snip ...
> which is wrong for P<=-2.

OK great, this is related to the conditions for the shift, thanks.  I will keep
at it.

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70235

--- Comment #10 from Jerry DeLisle  ---
Created attachment 38075
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=38075=edit
A patch for testing

Please test this patch as much as possible.  I think I have it right, but one
can never tell so independent testing helps.  I must say this was a PITA to
figure out.

[Bug fortran/70233] Missing diagnostic in array constructor, different size strings

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70233

--- Comment #9 from Jerry DeLisle  ---
Dominique, thanks for finding this. It even makes sense; if the typespec is
given one knows what the size of the string is.  If not given, how does one
decide which is the right size, so require that they all be equal.

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70235

--- Comment #8 from Jerry DeLisle  ---
(In reply to Tobias Burnus from comment #7)
... snip ...
> 
> My gut feeling is that it has something to do with having "precision" == 17
> in that function. In any case, the nafter is too large when nblanks is
> calculated.

Yes, and I find one place where after a memmove to align digits, the
significant digit gets wiped to a zero, really odd. I am on the hunt

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70235

--- Comment #5 from Jerry DeLisle  ---
Created attachment 37990
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=37990=edit
A useful test program

I get correct results using the attached with gcc version 4.6.4 (GCC)

Broken in 4.9, 5, and 6.

[Bug fortran/69043] Trying to include a directory causes an infinite loop

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69043

--- Comment #8 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sat Mar 19 20:28:38 2016
New Revision: 234352

URL: https://gcc.gnu.org/viewcvs?rev=234352=gcc=rev
Log:
2016-03-19  Jerry DeLisle  

PR fortran/69043
* scanner.c (load_file): Update to use S_ISREG macro.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/scanner.c

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70235

--- Comment #6 from Jerry DeLisle  ---
*** Bug 70237 has been marked as a duplicate of this bug. ***

[Bug fortran/70237] [4.9/5/6 Regression] Incorrect 0.0 output with PF format

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70237

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |DUPLICATE

--- Comment #3 from Jerry DeLisle  ---
This is a duplicate.

*** This bug has been marked as a duplicate of bug 70235 ***

[Bug fortran/70233] Missing diagnostic in array constructor, different size strings

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70233

--- Comment #6 from Jerry DeLisle  ---
The failures I looked at were becasue the constructors were using strings of
different sizes. So my question was going to be what are the rules.  Are the
strings suppose to get padded to the length of the character array element?

All elements must be of the same size so I assume if the length is say six, you
can not use "abc" in a constructor and one must use "abc   "

I did not check all the failures, but at least one requires the -fbackslash and
with the patch passes fine if I pad out the strings in the constructor.

[Bug fortran/69043] Trying to include a directory causes an infinite loop

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69043

Jerry DeLisle  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #7 from Jerry DeLisle  ---
(In reply to Andris Pavenis from comment #6)
> Breaks include support for DJGPP native compiler as S_ISREG is 0 for it. One
> should use S_ISREG(st.st_mode) instead. gcc/system.h ensures that S_ISREG is
> defined, so there should be no problems with it.
> 
> Verified that replacing '(st.st_mode & S_IFREG)' with S_ISREG(st.st_mode)
> fixes libgfortran native build for DJGPP.

OK, thanks for the feedback, will fix and make sure this works on Linux as
well.

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70235

--- Comment #9 from Jerry DeLisle  ---
I have isolated to a block of code which is dead relative to our current
testsuite. Now to work on the solution.

[Bug fortran/70233] Missing diagnostic in array constructor, different size strings

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70233

--- Comment #3 from Jerry DeLisle  ---
Harold,

Thanks for the help and I will test

[Bug fortran/70235] [4.9/5/6 Regression] Incorrect output with PF format

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70235

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #4 from Jerry DeLisle  ---
I will get started on this one. Dominique, if you spot the problem let me know.

[Bug fortran/70237] [4.9/5/6 Regression] Incorrect 0.0 output with PF format

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70237

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #2 from Jerry DeLisle  ---
I will get started on this one.

[Bug fortran/70233] New: Missing diagnostic in array constructor, different size strings

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70233

Bug ID: 70233
   Summary: Missing diagnostic in array constructor, different
size strings
   Product: gcc
   Version: 6.0
Status: UNCONFIRMED
  Severity: normal
  Priority: P3
 Component: fortran
  Assignee: unassigned at gcc dot gnu.org
  Reporter: jvdelisle at gcc dot gnu.org
  Target Milestone: ---

In the following code, one case of the constructor gives an error and one does
not.

integer, parameter :: char_len = 32
character(char_len), allocatable :: ch_array(:)
character(char_len) :: ch, bh

allocate(ch_array(5))
print *,lbound(ch_array), ubound(ch_array)
ch = "a"
bh = "b"
!ch_array = [bh, "def", ch, ch, bh]! no error given
ch_array = ["def", bh, ch, ch, ch] ! error given
print *, ch_array
deallocate(ch_array)
end

[Bug fortran/70231] Runtime error: Different CHARACTER lengths in array constructor with allocatable array and -O0

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70231

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-15
 CC||jvdelisle at gcc dot gnu.org
 Ever confirmed|0   |1

--- Comment #1 from Jerry DeLisle  ---
Interesting: -fdump-tree-original snippets

 snip 

ch_array.dim[0].lbound = 1;
ch_array.dim[0].ubound = 0;

 snip 

D.3452 = ch_array.dim[0].lbound;
D.3453 = ch_array.dim[0].ubound;
 snip 

  S.6 = D.3452;
  while (1)
{
  if (S.6 > D.3453) goto L.1;
  __builtin_memmove ((void *) &(*(character(kind=1)[1][1:32] *
restrict) atmp.4.data)[offset.5][1]{lb: 1 sz: 1}, (void *) &(*D.3450)[S.6 +
D.3451], 32);
  len.3 = 32;
  offset.5 = offset.5 + 1;
  S.6 = S.6 + 1;
}
  L.1:;
}
  }
  __builtin_memmove ((void *) &(*(character(kind=1)[1][1:32] *
restrict) atmp.4.data)[offset.5][1]{lb: 1 sz: 1}, (void *) , 32);
  if ((integer(kind=8)) (len.3 != 32))
{
  _gfortran_runtime_error_at (&"At line 8 of file
pr70231.f90"[1]{lb: 1 sz: 1}, &"Different CHARACTER lengths (%ld/%ld) in array
constructor"[1]{lb: 1 sz: 1}, (integer(kind=8)) len.3, 32);
}

len.3 does not get set because the lower bound of ch_array is greater than the
upperbound, so when the check is done, len.3 is uninitialized.

[Bug fortran/69043] Trying to include a directory causes an infinite loop

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69043

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #5 from Jerry DeLisle  ---
Closing

[Bug fortran/69043] Trying to include a directory causes an infinite loop

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69043

--- Comment #4 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Mar 13 17:38:07 2016
New Revision: 234169

URL: https://gcc.gnu.org/viewcvs?rev=234169=gcc=rev
Log:
2016-03-13  Jerry DeLisle  
Jim MacArthur  

PR fortran/69043
* scanner.c (load_file): Check that included file is regular.

PR fortran/69043
* gfortran.dg/include_9.f90: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/include_9.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/scanner.c
trunk/gcc/testsuite/ChangeLog

[Bug fortran/69520] Implement reversal of -fcheck options

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69520

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Jerry DeLisle  ---
Closing

[Bug fortran/70215] segmentation fault with allocate on assign; 32 bit version, not 64 bit

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70215

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #2 from Jerry DeLisle  ---
Shall we add a test case?

[Bug fortran/69520] Implement reversal of -fcheck options

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69520

--- Comment #8 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Mar 13 00:19:08 2016
New Revision: 234167

URL: https://gcc.gnu.org/viewcvs?rev=234167=gcc=rev
Log:
2016-03-12  Jerry DeLisle  
Harold Anlauf  

PR fortran/69520
* invoke.texi: Explain use of the 'no-' construct within the
-fcheck= option.
* options.c (gfc_handle_runtime_check_option): Enable use of
'no-' prefix for the various options with -fcheck= to allow
negating previously enabled check options.

Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/invoke.texi
trunk/gcc/fortran/options.c

[Bug fortran/69520] Implement reversal of -fcheck options

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69520

--- Comment #7 from Jerry DeLisle  ---
(In reply to Harald Anlauf from comment #6)
> Hi Jerry,
> 
> do you think my suggested patch could be applied before the 6 release?
> 
> Thanks,
> Harald

This is my plan. Just out of town for a few days. Maybe this weekend.

I have reviewed it already and it looks good.

[Bug fortran/70058] Segmentation fault when open file with existing file and status = "UNKNOWN"

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70058

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |INVALID

--- Comment #9 from Jerry DeLisle  ---
(In reply to Paul from comment #8)
> I downloaded the latest version I could find from
> https://sourceforge.net/projects/mingw-w64/?source=typ_redirect.   It is
> version 5.3.0.   The problem does not exist with version 5.3.0.  My
> apologies for not finding the latest gfortran version earlier.

Glad to hear you have resolved.

[Bug fortran/70058] Segmentation fault when open file with existing file and status = "UNKNOWN"

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70058

--- Comment #6 from Jerry DeLisle  ---
(In reply to kargl from comment #5)
> (In reply to Jerry DeLisle from comment #4)
> > The problem does not exist on Linux for sure.  Not sure if this is a TDM
> > distribution problem, a Windows problem, a MingW problem, or gfortran.
> > 
> > I am going to have to get set up on Windows so this may take a while.
> 
> From the backtrace in comment #3,
> 
> (gdb) backtrace
> #0 in strcmp () from C:\WINDOWS\system32\msvcrt.dll
> #1 in libgfortran_64-3!clog10l ()
> #2 in libgfortran_64-3!clog10l ()
> #3 in libgfortran_64-3!_gfortran_unpack1_char4 () 
> #4 in libgfortran_64-3!_gfortran_unpack1_char4 ()
> #5 in libgfortran_64-3!_gfortran_st_open ()
> 
> I doubt that this is a gfortran problem.  It is highly unlikely that
> OPEN uses a complex*16 log10 function that calls itself.

No kidding Steve. This could be linking against the wrong library. Another
possibility I suppose is memory corruption and the prgram is jumping into never
never land. We do not really no the creators of or the integrity of the TDM
distribution. Out of curiosity I am going to try to set it up in a sandbox and
see what I can find.

[Bug fortran/70058] Segmentation fault when open file with existing file and status = "UNKNOWN"

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70058

--- Comment #4 from Jerry DeLisle  ---
The problem does not exist on Linux for sure.  Not sure if this is a TDM
distribution problem, a Windows problem, a MingW problem, or gfortran.

I am going to have to get set up on Windows so this may take a while.

[Bug fortran/70068] ICE: out of memory on involving empty substring

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70068

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #3 from Jerry DeLisle  ---
Possibly related to or duplicate of 66310

[Bug fortran/70058] Segmentation fault when open file with existing file and status = "UNKNOWN"

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70058

--- Comment #2 from Jerry DeLisle  ---
Paul, could you please post the terminal output that gives the error message
please.

[Bug fortran/70058] Segmentation fault when open file with existing file and status = "UNKNOWN"

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70058

Jerry DeLisle  changed:

   What|Removed |Added

 Status|UNCONFIRMED |NEW
   Last reconfirmed||2016-03-03
 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  ---
Thanks for report.  If it worked before it is a regression. I will start
working on this right away.

[Bug fortran/45179] Support UTF-8 (and other encodings) in the source file (.f90) for CHARACTER(kind=4)

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=45179

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #5 from Jerry DeLisle  ---
We have UTF-8 read function in libgfortran, we could just incorporate these
into scanner.c  Adding to my TODO list.

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

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66709

Jerry DeLisle  changed:

   What|Removed |Added

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

--- Comment #3 from Jerry DeLisle  ---
This I think gets into array constructors to build the parameter constants and
we don't address it yet.

[Bug fortran/56226] Add support for DEC UNION and MAP extensions

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56226

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org

--- Comment #11 from Jerry DeLisle  ---
(In reply to Joel Matz from comment #8)
> Any word on this?  I would certainly be willing to help test.

Please start testing if you can.  The more testing the better.  Lots of
variations. I am not familiar with these extensions, I assume a lot of legacy
code exists.

[Bug fortran/56007] Remarkably bad error message with DO array=1,2

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56007

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #11 from Jerry DeLisle  ---
Fixed. Closing

[Bug fortran/56007] Remarkably bad error message with DO array=1,2

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56007

--- Comment #10 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Feb 28 19:07:42 2016
New Revision: 233795

URL: https://gcc.gnu.org/viewcvs?rev=233795=gcc=rev
Log:
2016-02-28  Harald Anlauf 
Jerry DeLisle  

PR fortran/56007
* match.c (gfc_match_iterator): Add diagnostic for array variable
as do loop index.

* gfortran.dg/coarray_8.f90: Adjust error message.
* gfortran.dg/pr56007.f90: New test.
* gfortran.dg/pr56007.f: New test.

Added:
trunk/gcc/testsuite/gfortran.dg/pr56007.f
trunk/gcc/testsuite/gfortran.dg/pr56007.f90
Modified:
trunk/gcc/fortran/ChangeLog
trunk/gcc/fortran/match.c
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gfortran.dg/coarray_8.f90

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

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66310

--- Comment #9 from Jerry DeLisle  ---
(In reply to Dominique d'Humieres from comment #8)
... snip ...
> before the patch and with
> 
> pr66310_1.f90:3:0:
> 
>print *, repeat(z, huge(1_4))
>  
> internal compiler error: Segmentation fault: 11
> 
> after the patch.

The patch fixes two places where the signed integer wrapped giving the
18446744065119617024 message.  The Segfault you have noted is in yet another
place where some address is getting exceeded. I also found this problem and it
will require further tracking.

[Bug fortran/56007] Remarkably bad error message with DO array=1,2

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=56007

Jerry DeLisle  changed:

   What|Removed |Added

 CC||jvdelisle at gcc dot gnu.org
   Assignee|unassigned at gcc dot gnu.org  |jvdelisle at gcc dot 
gnu.org

--- Comment #9 from Jerry DeLisle  ---
Plan to commit shortly

[Bug fortran/61156] [4.9/5/6 Regression] Internal compiler error for Fortran files when specifying a file instead of an include directory with -I

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61156

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #13 from Jerry DeLisle  ---
Fixed and closing.

[Bug fortran/61156] [4.9/5/6 Regression] Internal compiler error for Fortran files when specifying a file instead of an include directory with -I

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61156

--- Comment #12 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Feb 28 18:16:56 2016
New Revision: 233793

URL: https://gcc.gnu.org/viewcvs?rev=233793=gcc=rev
Log:
2016-02-28  Jerry DeLisle  

Backported from mainline
PR fortran/61156
* scanner.c (add_path_to_list): If include path is not a directory,
issue a fatal error.

* gfortran.dg/include_6.f90: Update test.

Modified:
branches/gcc-4_9-branch/gcc/fortran/ChangeLog
branches/gcc-4_9-branch/gcc/fortran/scanner.c
branches/gcc-4_9-branch/gcc/testsuite/ChangeLog
branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/include_6.f90

[Bug fortran/61156] [4.9/5/6 Regression] Internal compiler error for Fortran files when specifying a file instead of an include directory with -I

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61156

--- Comment #11 from Jerry DeLisle  ---
Author: jvdelisle
Date: Sun Feb 28 06:50:27 2016
New Revision: 233789

URL: https://gcc.gnu.org/viewcvs?rev=233789=gcc=rev
Log:
2016-02-27  Jerry DeLisle  

Backported from mainline
PR fortran/61156
* scanner.c (add_path_to_list): If include path is not a directory,
issue a fatal error.

* gfortran.dg/include_6.f90: Update test.

Modified:
branches/gcc-5-branch/gcc/fortran/ChangeLog
branches/gcc-5-branch/gcc/fortran/scanner.c
branches/gcc-5-branch/gcc/testsuite/ChangeLog
branches/gcc-5-branch/gcc/testsuite/gfortran.dg/include_6.f90

[Bug fortran/69456] Namelist value with trailing sign is ignored without error

[jvdelisle at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=69456

Jerry DeLisle  changed:

   What|Removed |Added

 Status|NEW |RESOLVED
 Resolution|--- |FIXED

--- Comment #9 from Jerry DeLisle  ---
Fixed on trunk. Closing