Re: [PATCH, libgfortran] PR68867 numeric formatting problem in the fortran library

[Steve Kargl]

On Sat, Dec 12, 2015 at 08:14:39PM -0800, Jerry DeLisle wrote:
>  case 16:
> +  /* Adjust decimal precision depending on binary precision, 103 or 113. 
>  */


s/103/106

I suspect that this is simply a bandaid on a much bigger
problem.  Namely, few of the intrinsic functions for 
REAL(16) expect 106 bits instead of 113 bits.

-- 
Steve

Re: [Patch, Fortran] PR45859 - Permit array elements to coarray dummy arguments

[Steve Kargl]

On Wed, Dec 09, 2015 at 08:24:39AM +0100, Tobias Burnus wrote:
> PING
> 

OK.

-- 
Steve

Re: [Patch, Fortran] PR68815 - replace '%s' quotes by %< ... %>

[Steve Kargl]

On Wed, Dec 09, 2015 at 04:53:37PM +0100, Tobias Burnus wrote:
> 
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
> 

OK.

-- 
Steve

[PATCH,committed] PR fortran/50201 -- quadmath_snprintf isn't weak

[Steve Kargl]

Committed to trunk and 5-bracnh after testing.

2015-12-05  Juoko Orava 

PR fortran/50201
* io/write_float.def: Avoid marking quadmath_snprintf as an untyped
weak reference, which fixing linking with -static.

-- 
Steve
Index: libgfortran/io/write_float.def
===
--- libgfortran/io/write_float.def	(revision 231314)
+++ libgfortran/io/write_float.def	(working copy)
@@ -938,7 +938,7 @@ snprintf (buffer, size, "%+-#.*Le", (pre
 
 #if defined(GFC_REAL_16_IS_FLOAT128)
 #define DTOA2Q(prec,val)			\
-__qmath_(quadmath_snprintf) (buffer, size, "%+-#.*Qe", (prec), (val))
+quadmath_snprintf (buffer, size, "%+-#.*Qe", (prec), (val))
 #endif
 
 #define FDTOA(suff,prec,val) TOKENPASTE(FDTOA2,suff)(prec,val)
@@ -953,7 +953,7 @@ snprintf (buffer, size, "%+-#.*Lf", (pre
 
 #if defined(GFC_REAL_16_IS_FLOAT128)
 #define FDTOA2Q(prec,val)			   \
-__qmath_(quadmath_snprintf) (buffer, size, "%+-#.*Qf", \
+quadmath_snprintf (buffer, size, "%+-#.*Qf", \
 			 (prec), (val))
 #endif
 

[PATCH, committed] Fix PR fortran/68684

[Steve Kargl]

I've committed the obvious patch after confirmation from
the original author that it is correct.

2015-12-04  Steven G. Kargl  

PR fortran/68684
* resolve.c (resolve_lock_unlock_event): Fix logic faux pas.

Index: resolve.c
===
--- resolve.c   (revision 231243)
+++ resolve.c   (working copy)
@@ -8745,7 +8745,7 @@ resolve_lock_unlock_event (gfc_code *cod
  !gfc_is_coindexed (code->expr1
 gfc_error ("Lock variable at %L must be a scalar of type LOCK_TYPE",
   >expr1->where);
-  else if ((code->op == EXEC_EVENT_POST && code->op == EXEC_EVENT_WAIT)
+  else if ((code->op == EXEC_EVENT_POST || code->op == EXEC_EVENT_WAIT)
   && (code->expr1->ts.type != BT_DERIVED
   || code->expr1->expr_type != EXPR_VARIABLE
   || code->expr1->ts.u.derived->from_intmod
-- 
Steve

Re: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE

[Steve Kargl]

On Thu, Dec 03, 2015 at 02:53:06PM +0100, Mikael Morin wrote:
> Le 03/12/2015 10:29, Janne Blomqvist a écrit :
> > On Tue, Dec 1, 2015 at 7:51 PM, Bernhard Reutner-Fischer
> >  wrote:
> >> As said, we could as well use a list of candidates with NULL as record 
> >> marker.
> >> Implementation cosmetics. Steve seems to not be thrilled by the
> >> overall idea in the first place, so unless there is clear support by
> >> somebody else i won't pursue this any further, it's not that i'm bored
> >> or ran out of stuff i should do.. ;)
> >
> > FWIW, I think the idea of this patch is quite nice, and I'd like to
> > see it in the compiler.
> >
> I like this feature as well.
> 
> > I'm personally Ok with "C++-isms", but nowadays my contributions are
> > so minor that my opinion shouldn't carry that much weight on this
> > matter.
> >
> Same here.
> David Malcolm suggested to move the candidate selection code to the 
> common middle-end infrastructure, which would move half of the so-called 
> "bloat" there.  Steve, would that work for you?

Fine with me.

When debugging, if I run into C++isms, I'll stop and move to
a new bug.  We certainly have enough open bugs to choose from. 

-- 
Steve

Re: [OpenACC 0/7] host_data construct

[Steve Kargl]

On Wed, Dec 02, 2015 at 11:16:10AM -0800, Cesar Philippidis wrote:
> 
> This host_data patch exposed a bug in the fortran front end where it was
> allowing arrays to be used as reduction variables. If replace you
> replace codimension with dimension, you'd see a similar ICE. The
> attached patch, while it doesn't make any attempt to fix the gimplifier
> changes, does teach the fortran front end to error on acc reductions
> containing array variables.
> 
> Note that this solution is somewhat aggressive because we probably
> should allow reductions on individual array elements. E.g.
> 
>   !$acc loop reduction(+:var(1))
> 
> The c and c++ front ends also have that problem. Maybe I'll revisit this
> later.
> 
> Is this ok for trunk? It will close pr63861.
> 

I think that it is OK, but will defer to Jakub or Thomas.
I suspect tht Jakub may be pre-occupied with the upcoming
5.3 release.

-- 
Steve

Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS

[Steve Kargl]

Committed as revision 231208.

Alessandro, Tobias, is this a candidate for a commit to 
the 5-branch when it is re-opened?

-- 
steve

On Wed, Dec 02, 2015 at 03:16:05PM +0100, Alessandro Fanfarillo wrote:
> *PING*
> 
> 2015-11-26 17:51 GMT+01:00 Steve Kargl <s...@troutmask.apl.washington.edu>:
> > On Wed, Nov 25, 2015 at 06:24:49PM +0100, Alessandro Fanfarillo wrote:
> >> Dear all,
> >>
> >> in attachment the previous patch compatible with the current trunk.
> >> The patch also includes the changes introduced in the latest TS 18508.
> >>
> >> Built and regtested on x86_64-pc-linux-gnu.
> >>
> >> PS: I will add the test cases in a different patch.
> >>
> >
> > I have now built and regression tested the patch on
> > x86_64-*-freebsd and i386-*-freebsd.  There were no
> > regressions.  In reading through the patch, nothing
> > jumped out at me as suspicious/wrong.  Tobias, this
> > is OK to commit.  If you don't committed by Sunday,
> > I'll do it for you.
> >
> > --
> > steve

-- 
Steve

Re: [Patch, fortran] PR68534 - No error on mismatch in number of arguments between submodule and module interface

[Steve Kargl]

On Wed, Dec 02, 2015 at 10:26:30PM -0800, Steve Kargl wrote:
> On Wed, Dec 02, 2015 at 10:02:33PM -0800, Steve Kargl wrote:
> > Paul,
> > 
> > I'm stumped.  Something is broken on i386-*-freebsd. :-(
> > 
> > Running /mnt/kargl/gcc/gcc/testsuite/gfortran.dg/dg.exp ...
> > FAIL: gfortran.dg/submodule_10.f08   -O  (internal compiler error)
> > FAIL: gfortran.dg/submodule_10.f08   -O  (test for excess errors)
> > FAIL: gfortran.dg/submodule_11.f08   -O0  (internal compiler error)
> > FAIL: gfortran.dg/submodule_11.f08   -O0  (test for excess errors)
> > FAIL: gfortran.dg/submodule_11.f08   -O1  (internal compiler error)
> > FAIL: gfortran.dg/submodule_11.f08   -O1  (test for excess errors)
> > FAIL: gfortran.dg/submodule_11.f08   -O2  (internal compiler error)
> > FAIL: gfortran.dg/submodule_11.f08   -O2  (test for excess errors)
> > FAIL: gfortran.dg/submodule_11.f08   -O3 -fomit-frame-pointer 
> > -funroll-loops -fpeel-loops -ftracer -finline-functions  (internal compiler 
> > error)
> > FAIL: gfortran.dg/submodule_11.f08   -O3 -fomit-frame-pointer 
> > -funroll-loops -fpeel-loops -ftracer -finline-functions  (test for excess 
> > errors)
> > FAIL: gfortran.dg/submodule_11.f08   -O3 -g  (internal compiler error)
> > FAIL: gfortran.dg/submodule_11.f08   -O3 -g  (test for excess errors)
> > FAIL: gfortran.dg/submodule_11.f08   -Os  (internal compiler error)
> > FAIL: gfortran.dg/submodule_11.f08   -Os  (test for excess errors)
> 
> Well, if I change the order of the conditionals decl.c:4831, I 
> can get rid of the above FAILs.
> 
> Index: decl.c
> ===
> --- decl.c  (revision 231219)
> +++ decl.c  (working copy)
> @@ -4826,7 +4826,7 @@ ok:
>  
>/* Abbreviated module procedure declaration is not meant to have any
>  formal arguments!  */
> -  if (!sym->abr_modproc_decl && formal && !head)
> +  if (formal && !head && sym && !sym->abr_modproc_decl)
> arg_count_mismatch = true;
>  
>for (p = formal, q = head; p && q; p = p->next, q = q->next)
> 
> -- 
> steve
> 
> > FAIL: gfortran.dg/submodule_13.f08   -O  (internal compiler error)
> > FAIL: gfortran.dg/submodule_13.f08   -O   (test for errors, line 29)
> > FAIL: gfortran.dg/submodule_13.f08   -O  (test for excess errors)

These ICEs persist at line 4831.  In looking at the code, I'm
now somewhat unsure what it should be doing.  In particular, 
there are 2 gfc_error_now() calls in the below:


  for (p = formal, q = head; p && q; p = p->next, q = q->next)
{
  if ((p->next != NULL && q->next == NULL)
  || (p->next == NULL && q->next != NULL))
arg_count_mismatch = true;
  else if ((p->sym == NULL && q->sym == NULL)
|| strcmp (p->sym->name, q->sym->name) == 0)
continue;
  else
gfc_error_now ("Mismatch in MODULE PROCEDURE formal "
   "argument names (%s/%s) at %C",
   p->sym->name, q->sym->name);
}

  if (arg_count_mismatch)
  gfc_error_now ("Mismatch in number of MODULE PROCEDURE "
 "formal arguments at %C");
}

  return MATCH_YES;

cleanup:
  gfc_free_formal_arglist (head);
  return m;

But, we return MATCH_YES?  I would expect setting m = MATCH_ERROR
and jumping to cleanup.  That's ugly.

-- 
Steve

Re: [Patch, fortran] PR68534 - No error on mismatch in number of arguments between submodule and module interface

[Steve Kargl]

On Wed, Dec 02, 2015 at 10:02:33PM -0800, Steve Kargl wrote:
> Paul,
> 
> I'm stumped.  Something is broken on i386-*-freebsd. :-(
> 
> Running /mnt/kargl/gcc/gcc/testsuite/gfortran.dg/dg.exp ...
> FAIL: gfortran.dg/submodule_10.f08   -O  (internal compiler error)
> FAIL: gfortran.dg/submodule_10.f08   -O  (test for excess errors)
> FAIL: gfortran.dg/submodule_11.f08   -O0  (internal compiler error)
> FAIL: gfortran.dg/submodule_11.f08   -O0  (test for excess errors)
> FAIL: gfortran.dg/submodule_11.f08   -O1  (internal compiler error)
> FAIL: gfortran.dg/submodule_11.f08   -O1  (test for excess errors)
> FAIL: gfortran.dg/submodule_11.f08   -O2  (internal compiler error)
> FAIL: gfortran.dg/submodule_11.f08   -O2  (test for excess errors)
> FAIL: gfortran.dg/submodule_11.f08   -O3 -fomit-frame-pointer -funroll-loops 
> -fpeel-loops -ftracer -finline-functions  (internal compiler error)
> FAIL: gfortran.dg/submodule_11.f08   -O3 -fomit-frame-pointer -funroll-loops 
> -fpeel-loops -ftracer -finline-functions  (test for excess errors)
> FAIL: gfortran.dg/submodule_11.f08   -O3 -g  (internal compiler error)
> FAIL: gfortran.dg/submodule_11.f08   -O3 -g  (test for excess errors)
> FAIL: gfortran.dg/submodule_11.f08   -Os  (internal compiler error)
> FAIL: gfortran.dg/submodule_11.f08   -Os  (test for excess errors)

Well, if I change the order of the conditionals decl.c:4831, I 
can get rid of the above FAILs.

Index: decl.c
===
--- decl.c  (revision 231219)
+++ decl.c  (working copy)
@@ -4826,7 +4826,7 @@ ok:
 
   /* Abbreviated module procedure declaration is not meant to have any
 formal arguments!  */
-  if (!sym->abr_modproc_decl && formal && !head)
+  if (formal && !head && sym && !sym->abr_modproc_decl)
arg_count_mismatch = true;
 
   for (p = formal, q = head; p && q; p = p->next, q = q->next)

-- 
steve

> FAIL: gfortran.dg/submodule_13.f08   -O  (internal compiler error)
> FAIL: gfortran.dg/submodule_13.f08   -O   (test for errors, line 29)
> FAIL: gfortran.dg/submodule_13.f08   -O  (test for excess errors)
> 
> Using valgrind on 'f951 submodule_10.f08' yields
> 
> laptop-kargl:kargl[324] valgrind 
> ~/work/libexec/gcc/i386-unknown-freebsd11.0/6.0.0/f951 submodule_10.f08
> ==74201== Memcheck, a memory error detector
> ==74201== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
> ==74201== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
> ==74201== Command: 
> /home/kargl/work/libexec/gcc/i386-unknown-freebsd11.0/6.0.0/f951 
> submodule_10.f08
> ==74201== 
> ==74201== Use of uninitialised value of size 4
> ==74201==at 0x81DC20C: gfc_match_formal_arglist(gfc_symbol*, int, int) 
> (decl.c:4829)
> ==74201==by 0x81DE6F7: gfc_match_subroutine() (decl.c:6016)
> ==74201==by 0x8248FC0: decode_statement() (parse.c:378)
> ==74201==by 0x8247844: next_free (parse.c:1076)
> ==74201==by 0x8247844: next_statement() (parse.c:1310)
> ==74201==by 0x8258ACC: parse_contained(int) (parse.c:5038)
> ==74201==by 0x824870F: parse_module() (parse.c:5431)
> ==74201==by 0x82467D4: gfc_parse_file() (parse.c:5729)
> ==74201==by 0x82972E7: gfc_be_parse_file() (f95-lang.c:201)
> ==74201==by 0x87E4787: compile_file() (toplev.c:464)
> ==74201==by 0x87E43E4: do_compile (toplev.c:1951)
> ==74201==by 0x87E43E4: toplev::main(int, char**) (toplev.c:2058)
> ==74201==by 0x8FCC00D: main (main.c:39)
> ==74201== 
> ==74201== Invalid read of size 1
> ==74201==at 0x81DC20C: gfc_match_formal_arglist(gfc_symbol*, int, int) 
> (decl.==74201==at 0x81DC20C: gfc_match_formal_arglist(gfc_symbol*, int, 
> int) (decl.c:4829)
> ==74201==by 0x81DE6F7: gfc_match_subroutine() (decl.c:6016)
> ==74201==by 0x8248FC0: decode_statement() (parse.c:378)
> ==74201==by 0x8247844: next_free (parse.c:1076)
> ==74201==by 0x8247844: next_statement() (parse.c:1310)
> ==74201==by 0x8258ACC: parse_contained(int) (parse.c:5038)
> ==74201==by 0x824870F: parse_module() (parse.c:5431)
> ==74201==by 0x82467D4: gfc_parse_file() (parse.c:5729)
> ==74201==by 0x82972E7: gfc_be_parse_file() (f95-lang.c:201)
> ==74201==by 0x87E4787: compile_file() (toplev.c:464)
> ==74201==by 0x87E43E4: do_compile (toplev.c:1951)
> ==74201==by 0x87E43E4: toplev::main(int, char**) (toplev.c:2058)
> ==74201==by 0x8FCC00D: main (main.c:39)
> ==74201==  Address 0x8094 is not stack'd, malloc'd or (recently) free'd
> ==74201== 
> 
> 
> I suspect that we have a sym=NULL dereferenc someplace.
> 
> -- 
> steve
> 
> 
> On Mon, Nov 30, 2015 at 02:35:35PM +0100, Paul Richard Thomas

Re: [Patch, fortran] PR68534 - No error on mismatch in number of arguments between submodule and module interface

[Steve Kargl]

Paul,

I'm stumped.  Something is broken on i386-*-freebsd. :-(

Running /mnt/kargl/gcc/gcc/testsuite/gfortran.dg/dg.exp ...
FAIL: gfortran.dg/submodule_10.f08   -O  (internal compiler error)
FAIL: gfortran.dg/submodule_10.f08   -O  (test for excess errors)
FAIL: gfortran.dg/submodule_11.f08   -O0  (internal compiler error)
FAIL: gfortran.dg/submodule_11.f08   -O0  (test for excess errors)
FAIL: gfortran.dg/submodule_11.f08   -O1  (internal compiler error)
FAIL: gfortran.dg/submodule_11.f08   -O1  (test for excess errors)
FAIL: gfortran.dg/submodule_11.f08   -O2  (internal compiler error)
FAIL: gfortran.dg/submodule_11.f08   -O2  (test for excess errors)
FAIL: gfortran.dg/submodule_11.f08   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  (internal compiler error)
FAIL: gfortran.dg/submodule_11.f08   -O3 -fomit-frame-pointer -funroll-loops 
-fpeel-loops -ftracer -finline-functions  (test for excess errors)
FAIL: gfortran.dg/submodule_11.f08   -O3 -g  (internal compiler error)
FAIL: gfortran.dg/submodule_11.f08   -O3 -g  (test for excess errors)
FAIL: gfortran.dg/submodule_11.f08   -Os  (internal compiler error)
FAIL: gfortran.dg/submodule_11.f08   -Os  (test for excess errors)
FAIL: gfortran.dg/submodule_13.f08   -O  (internal compiler error)
FAIL: gfortran.dg/submodule_13.f08   -O   (test for errors, line 29)
FAIL: gfortran.dg/submodule_13.f08   -O  (test for excess errors)

Using valgrind on 'f951 submodule_10.f08' yields

laptop-kargl:kargl[324] valgrind 
~/work/libexec/gcc/i386-unknown-freebsd11.0/6.0.0/f951 submodule_10.f08
==74201== Memcheck, a memory error detector
==74201== Copyright (C) 2002-2013, and GNU GPL'd, by Julian Seward et al.
==74201== Using Valgrind-3.10.0 and LibVEX; rerun with -h for copyright info
==74201== Command: 
/home/kargl/work/libexec/gcc/i386-unknown-freebsd11.0/6.0.0/f951 
submodule_10.f08
==74201== 
==74201== Use of uninitialised value of size 4
==74201==at 0x81DC20C: gfc_match_formal_arglist(gfc_symbol*, int, int) 
(decl.c:4829)
==74201==by 0x81DE6F7: gfc_match_subroutine() (decl.c:6016)
==74201==by 0x8248FC0: decode_statement() (parse.c:378)
==74201==by 0x8247844: next_free (parse.c:1076)
==74201==by 0x8247844: next_statement() (parse.c:1310)
==74201==by 0x8258ACC: parse_contained(int) (parse.c:5038)
==74201==by 0x824870F: parse_module() (parse.c:5431)
==74201==by 0x82467D4: gfc_parse_file() (parse.c:5729)
==74201==by 0x82972E7: gfc_be_parse_file() (f95-lang.c:201)
==74201==by 0x87E4787: compile_file() (toplev.c:464)
==74201==by 0x87E43E4: do_compile (toplev.c:1951)
==74201==by 0x87E43E4: toplev::main(int, char**) (toplev.c:2058)
==74201==by 0x8FCC00D: main (main.c:39)
==74201== 
==74201== Invalid read of size 1
==74201==at 0x81DC20C: gfc_match_formal_arglist(gfc_symbol*, int, int) 
(decl.==74201==at 0x81DC20C: gfc_match_formal_arglist(gfc_symbol*, int, 
int) (decl.c:4829)
==74201==by 0x81DE6F7: gfc_match_subroutine() (decl.c:6016)
==74201==by 0x8248FC0: decode_statement() (parse.c:378)
==74201==by 0x8247844: next_free (parse.c:1076)
==74201==by 0x8247844: next_statement() (parse.c:1310)
==74201==by 0x8258ACC: parse_contained(int) (parse.c:5038)
==74201==by 0x824870F: parse_module() (parse.c:5431)
==74201==by 0x82467D4: gfc_parse_file() (parse.c:5729)
==74201==by 0x82972E7: gfc_be_parse_file() (f95-lang.c:201)
==74201==by 0x87E4787: compile_file() (toplev.c:464)
==74201==by 0x87E43E4: do_compile (toplev.c:1951)
==74201==by 0x87E43E4: toplev::main(int, char**) (toplev.c:2058)
==74201==by 0x8FCC00D: main (main.c:39)
==74201==  Address 0x8094 is not stack'd, malloc'd or (recently) free'd
==74201== 


I suspect that we have a sym=NULL dereferenc someplace.

-- 
steve


On Mon, Nov 30, 2015 at 02:35:35PM +0100, Paul Richard Thomas wrote:
> Committed as revision 231072.
> 
> Thanks for the review
> 
> Paul
> 
> On 28 November 2015 at 17:19, Steve Kargl
> <s...@troutmask.apl.washington.edu> wrote:
> > On Sat, Nov 28, 2015 at 11:35:54AM +0100, Paul Richard Thomas wrote:
> >> +
> >> +   /* Abreviated module procedure declaration is not meant to have any
> >
> > s/Abreviated/Abbreviated
> >
> >> +  formal arguments!  */
> >> +   if (!sym->abr_modproc_decl && formal && !head)
> >> + arg_count_mismatch = true;
> >> +
> >
> > OK to commit.
> >
> > --
> > Steve
> 
> 
> 
> -- 
> Outside of a dog, a book is a man's best friend. Inside of a dog it's
> too dark to read.
> 
> Groucho Marx

-- 
Steve

Re: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE

[Steve Kargl]

On Tue, Dec 01, 2015 at 12:58:28PM -0500, David Malcolm wrote:
> On Tue, 2015-12-01 at 18:51 +0100, Bernhard Reutner-Fischer wrote:
> > As said, we could as well use a list of candidates with NULL as record 
> > marker.
> > Implementation cosmetics. Steve seems to not be thrilled by the
> > overall idea in the first place, so unless there is clear support by
> > somebody else i won't pursue this any further, it's not that i'm bored
> > or ran out of stuff i should do.. ;)
> 
> (FWIW I liked the idea, but I'm not a Fortran person so my opinion
> counts much less that Steve's)
> 

Your opinion is as valid as mine.

My only concern is code maintenance.  Injection of C++ (or any
other language) into C code seems to add possible complications
when something needs to be fix or changed to accommodate a new
Fortran freature.

-- 
Steve

Re: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE

[Steve Kargl]

On Tue, Dec 01, 2015 at 06:34:57PM +0100, Bernhard Reutner-Fischer wrote:
> On 1 December 2015 at 17:41, Steve Kargl
> >
> > Yes, I know there are other C++ (mis)features within the
> > Fortran FE especially in the trans-*.c files.  Those are
> > accepted (by some) as necessary evils to interface with
> > the ME.  Your patch injects C++ into otherwise perfectly
> > fine C code, which makes it more difficult for those with
> > no or very limited C++ knowledge to maintain the gfortran.
> 
> So you're in favour of using realloc and strcat, ok. I can use that.
> Let me see if ipa-icf can replace all the identical tails of the
> lookup_*_fuzzy into a common helper.
> Shouldn't rely on LTO anyway nor ipa-icf i suppose.

Yes, I would prefer it, but certainly won't demand it.
There are other Fortran contributors/maintainers.  They
may prefer you approach, so give them time to speak up.

-- 
Steve

Re: [PATCH] Commentary typo fix for gfc_typenode_for_spec()

[Steve Kargl]

On Tue, Dec 01, 2015 at 01:55:00PM +0100, Bernhard Reutner-Fischer wrote:
> Regstrapped without regressions, ok for trunk stage3 now / next stage1?
> 
> gcc/fortran/ChangeLog
> 
> 2015-11-29  Bernhard Reutner-Fischer  
> 
>   * trans-types.c (gfc_typenode_for_spec): Commentary typo fix.
> 

Patches to fix typographical errors in comments are pre-approved.

-- 
Steve

Re: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE

[Steve Kargl]

On Tue, Dec 01, 2015 at 01:55:01PM +0100, Bernhard Reutner-Fischer wrote:
> 
> David Malcolm nice Levenshtein distance spelling check helpers
> were used in some parts of other frontends. This proposed patch adds
> some spelling corrections to the fortran frontend.
> 
> Suggestions are printed if we can find a suitable name, currently
> perusing a very simple cutoff factor:
> /* If more than half of the letters were misspelled, the suggestion is
>likely to be meaningless.  */
> cutoff = MAX (strlen (typo), strlen (best_guess)) / 2;
> which effectively skips names with less than 4 characters.
> For e.g. structures, one could try to be much smarter in an attempt to
> also provide suggestions for single-letter members/components.
> 
> This patch covers (at least partly):
> - user-defined operators
> - structures (types and their components)
> - functions
> - symbols (variables)
> 
> I do not immediately see how to handle subroutines. Ideas?
> 
> If anybody has a testcase where a spelling-suggestion would make sense
> then please pass it along so we maybe can add support for GCC-7.
> 

What problem are you trying to solve here?  The patch looks like
unneeded complexity with the result of injecting C++ idioms into
the Fortran FE.

-- 
Steve

Re: [PATCH] RFC: Use Levenshtein spelling suggestions in Fortran FE

[Steve Kargl]

On Tue, Dec 01, 2015 at 05:12:57PM +0100, Bernhard Reutner-Fischer wrote:
> On 1 December 2015 at 16:01, Steve Kargl
> <s...@troutmask.apl.washington.edu> wrote:
> > On Tue, Dec 01, 2015 at 01:55:01PM +0100, Bernhard Reutner-Fischer wrote:
> >>
> >> David Malcolm nice Levenshtein distance spelling check helpers
> >> were used in some parts of other frontends. This proposed patch adds
> >> some spelling corrections to the fortran frontend.
> 
> > What problem are you trying to solve here?  The patch looks like
> 
> The idea is to improve the programmer experience when writing code.
> See the testcases enclosed in the patch. I consider this a feature :)

Opinions differ.  I consider it unnecessary bloat.

> > unneeded complexity with the result of injecting C++ idioms into
> > the Fortran FE.
> 
> What C++ idioms are you referring to? The autovec?
> AFAIU the light use of C++ in GCC is deemed OK. I see usage of
> std::swap and std::map in the FE, not to mention the wide-int uses
> (wi::). Thus we don't have to realloc/strcat but can use vectors to
> the same effect, just as other frontends, including the C frontend,
> do.
> I take it you remember that we had to change all "try" to something
> C++ friendly. If the Fortran FE meant to opt-out of being compiled
> with a C++ compiler in the first place, why were all the C++ clashes
> rewritten, back then? :)

Yes, I know there are other C++ (mis)features within the
Fortran FE especially in the trans-*.c files.  Those are
accepted (by some) as necessary evils to interface with 
the ME.  Your patch injects C++ into otherwise perfectly
fine C code, which makes it more difficult for those with
no or very limited C++ knowledge to maintain the gfortran.

There are currently 806 open bug reports for gfortran.
AFAIK, your patch does not address any of those bug reports.
The continued push to inject C++ into the Fortran FE will
have the (un)intentional consequence of forcing at least one
active gfortran contributor to stop.

--  
Steve

Re: [Patch, fortran] PR68534 - No error on mismatch in number of arguments between submodule and module interface

[Steve Kargl]

On Sat, Nov 28, 2015 at 11:35:54AM +0100, Paul Richard Thomas wrote:
> + 
> +   /* Abreviated module procedure declaration is not meant to have any

s/Abreviated/Abbreviated

> +  formal arguments!  */
> +   if (!sym->abr_modproc_decl && formal && !head)
> + arg_count_mismatch = true;
> + 

OK to commit.

-- 
Steve

Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS

[Steve Kargl]

On Wed, Nov 25, 2015 at 06:24:49PM +0100, Alessandro Fanfarillo wrote:
> Dear all,
> 
> in attachment the previous patch compatible with the current trunk.
> The patch also includes the changes introduced in the latest TS 18508.
> 
> Built and regtested on x86_64-pc-linux-gnu.
> 
> PS: I will add the test cases in a different patch.
> 

I have now built and regression tested the patch on
x86_64-*-freebsd and i386-*-freebsd.  There were no
regressions.  In reading through the patch, nothing
jumped out at me as suspicious/wrong.  Tobias, this
is OK to commit.  If you don't committed by Sunday,
I'll do it for you.

-- 
steve

Re: [Fortran, Patch] (RFC, Coarray) Implement TS18508's EVENTS

[Steve Kargl]

Paul

I've bootstrap and regression tested the patch on x86_64-*-freebsd.
I intend to do the same tonight on i386-*-freebsd.  After that, I'll
go over the patch as you have done and then intend to commit it.
AFAICT, Tobias is busy with Real-Life (tm) (or taking a much
needed rest from gfortran hacking).  tobias, if you would rather
commit the patch, I'm fine with that; otherwise, I'll take care
of it in the next few days.

-- 
steve 

On Wed, Nov 25, 2015 at 11:28:28PM +0100, Paul Richard Thomas wrote:
> Dear Alessandro and Tobias,
> 
> I have been through the patch to check for obvious bloopers but can
> find none, as expected given the author :-)
> 
> I would dearly like to see the testcases at the same time as the patch
> but I think that the commit should be made sooner, rather than
> later. Given its nature, I think that it is pretty safe at this stage
> of the 6.0.0 lifecycle and so I say OK for trunk.
> 
> Cheers
> 
> Paul
> 
> On 25 November 2015 at 18:24, Alessandro Fanfarillo
>  wrote:
> > Dear all,
> >
> > in attachment the previous patch compatible with the current trunk.
> > The patch also includes the changes introduced in the latest TS 18508.
> >
> > Built and regtested on x86_64-pc-linux-gnu.
> >
> > PS: I will add the test cases in a different patch.
> >
> > 2015-04-29 9:55 GMT+02:00 Tobias Burnus :
> >> Dear all,
> >>
> >> attached patch fixes a bug and implements EVENTS. I think the patch is
> >> finished, but I still have to extend the test cases, to re-read the
> >> patch and to write a changelog. As I am not sure how soon I will able
> >> to do so, I follow the paradigm: release soon, release often and post
> >> it here. Comments and reviews are welcome.
> >>
> >> The patch fixes two bug in the "errmsg" handling, found by Alessandro:
> >> I don't pass on the address of the actual argument and in libcaf_single,
> >> I copy only 8 characters (sizeof pointer) instead of all of the the
> >> characters of the error message.
> >>
> >> Regarding events: Events is a way to permit barrier/locking-free
> >> programming: One sends the finished data to an other image and then
> >> tells that image that the data is there ("event post(msg_var[idx])").
> >> That image can then either wait for the event by querying the status
> >> on the local variable ("event wait(msg_var)") or only check the status
> >> and if it is not ready do something else (e.g. another iteration);
> >> that's done via "call event_query(msg_var, count)".
> >>
> >> Technically, event_post works like atomic_add(msg_var[idx], 1) and
> >> event_query like "atomic_ref(msg_var, count)". event_wait is the same
> >> as event_query plus a spin/sleep loop waiting for the status change,
> >> followed by an atomic_add(msg_var, -until_count). Except that
> >> event_post/event_wait are image control statements. (Otherwise it
> >> could happen that the event is there before the data for which the
> >> event has been posted.)
> >>
> >> Regarding the implementation in this patch, the limitations are the
> >> same as for locking: Currently, neither lock_type nor event_type
> >> variables are permitted as (nonallocatable) components
> >> of a derived type - and type extension of them also not yet supported.*
> >>
> >> The spec can be found at http://bitly.com/sc22wg5 -> 2015 -> TS draft
> >> or directly at
> >> http://isotc.iso.org/livelink/livelink?func=ll=17064344=Open
> >>
> >> Tobias
> >>
> >>
> >> * Doing so is not really difficult but I need to handle cases like
> >> the following. For "allocatable" with SOURCE= I also need to handle
> >> it with polymorphic types.
> >>
> >> type t1
> >>   type(event_type) :: EV
> >>   type(lock_type) :: LK
> >> end type1
> >> type t2
> >>   type(t1) :: a(5)
> >> end type t2
> >> type t3
> >>   type(t2) :: b(8)
> >> end type t3
> >>
> >> type(t3), save :: caf(3)[*]
> >>
> >> For those, I need to call _gfortran_caf_register for
> >>   caf(:)%b(:)%a(:)%ev and caf(:)%b(:)%a(:)%lk
> >> Looping though all array references.
> >>
> >> Similar for
> >>   type(t3), allocatable :: caf2(:)[:]
> >>   allocate(caf2(n)[*])
> >> for the allocate call.
> 
> 
> 
> -- 
> Outside of a dog, a book is a man's best friend. Inside of a dog it's
> too dark to read.
> 
> Groucho Marx

-- 
Steve

[PATCH, committed] PR fortran/PR68227

[Steve Kargl]

Committed to placate the masses.

2015-11-25  Steven G. Kargl  

PR fortran/68227
* trans-stmt.c (gfc_do_allocate): Convert gcc_assert argument into
into part of conditional statement.

Index: gcc/gcc/gcc/fortran/trans-stmt.c
===
--- gcc/gcc/gcc/fortran/trans-stmt.c(revision 230851)
+++ gcc/gcc/gcc/fortran/trans-stmt.c(working copy)
@@ -3125,9 +3125,8 @@ gfc_do_allocate (tree bytesize, tree siz
 
   type = build_range_type (gfc_array_index_type, gfc_index_zero_node, tmp);
   type = build_array_type (elem_type, type);
-  if (gfc_can_put_var_on_stack (bytesize))
+  if (gfc_can_put_var_on_stack (bytesize) && INTEGER_CST_P (size))
 {
-  gcc_assert (INTEGER_CST_P (size));
   tmpvar = gfc_create_var (type, "temp");
   *pdata = NULL_TREE;
 }

-- 
Steve

Re: [PATCH] PR52251

[Steve Kargl]

On Sun, Nov 22, 2015 at 02:35:01PM -0800, Jerry DeLisle wrote:
> Another old patch I forgot about.  This one is fairly self
> explanatory.  We were not handling pending spaces for
> ADVANCE_NO and T editing.
> 
> Regression tested x86-64-linux.  New test case.
> 
> OK for trunk?
> 

Looks ok to me.

-- 
Steve

[PATCH] fortran/openmp.c -- Fix bootstrap

[Steve Kargl]

I have no idea if this is actually correct, but it restores bootstrap.
OK to commit?

2015-11-22  Steven G. Kargl  

* openmp.c (match_oacc_clause_gang): Fix bootstrap.


Index: openmp.c
===
--- openmp.c(revision 230723)
+++ openmp.c(working copy)
@@ -415,7 +415,8 @@ match_oacc_clause_gang (gfc_omp_clauses 
 static match
 gfc_match_oacc_clause_link (const char *str, gfc_omp_namelist **list)
 {
-  gfc_omp_namelist *head, *tail, *p;
+  gfc_omp_namelist *head = NULL;
+  gfc_omp_namelist *tail, *p;
   locus old_loc;
   char n[GFC_MAX_SYMBOL_LEN+1];
   gfc_symbol *sym;
@@ -4821,7 +4822,7 @@ gfc_resolve_oacc_declare (gfc_namespace 
 
   for (oc = ns->oacc_declare; oc; oc = oc->next)
 {
-  for (list = 0; list <= OMP_LIST_NUM; list++)
+  for (list = 0; list < OMP_LIST_NUM; list++)
for (n = oc->clauses->lists[list]; n; n = n->next)
  {
n->sym->mark = 0;
@@ -4846,7 +4847,7 @@ gfc_resolve_oacc_declare (gfc_namespace 
 
   for (oc = ns->oacc_declare; oc; oc = oc->next)
 {
-  for (list = 0; list <= OMP_LIST_NUM; list++)
+  for (list = 0; list < OMP_LIST_NUM; list++)
for (n = oc->clauses->lists[list]; n; n = n->next)
  {
if (n->sym->mark)
@@ -4862,7 +4863,7 @@ gfc_resolve_oacc_declare (gfc_namespace 
 
   for (oc = ns->oacc_declare; oc; oc = oc->next)
 {
-  for (list = 0; list <= OMP_LIST_NUM; list++)
+  for (list = 0; list < OMP_LIST_NUM; list++)
for (n = oc->clauses->lists[list]; n; n = n->next)
  n->sym->mark = 0;
 }
-- 
Steve

Re: [PATCH] (Partial) Implementation of simplificaiton of CSHIFT

[Steve Kargl]

On Sun, Nov 22, 2015 at 09:51:09AM +0100, Dominique d'Humi??res wrote:
> 
> Compiling the attached code after revision r230710 gives the ICE
> 
> f951: internal compiler error: in gfc_simplify_cshift, at 
> fortran/simplify.c:1823
> 
> while it compiled before.
> 

File a bug report, then fix rank > 2.

-- 
Steve

Re: [PATCH] Fix leading zero with g0 editing

[Steve Kargl]

On Sun, Nov 22, 2015 at 01:32:56PM -0800, Jerry DeLisle wrote:
> This minor patch brings the leading zero to emitting floats with g0 editing by
> moving the block of code up a little before the g0 is handled.  This has been
> lurking in my trunk for several moths and I would like to get it out of the 
> way.
> Updated Test case also.
> 
> Regression tested on x86-64-linux.
> 
> OK for trunk?
> 

OK.  Thanks for the patch.

-- 
Steve

Re: [PATCH] (Partial) Implementation of simplificaiton of CSHIFT

[Steve Kargl]

On Sat, Nov 21, 2015 at 11:41:51AM +0100, Paul Richard Thomas wrote:
> 
> Just a couple of small typos:
> "Unexpected expr_type cause an ICE" ;  causes?
> "! An array of derived types workd too." ; works?
> 
> Apart from that it's OK for trunk.
> 
> Thanks for the patch
> 

Thanks for the the review.  I don't have a clue as
to how to do simplification for rank > 2. :(

-- 
Steve

Re: [PATCH] (Partial) Implementation of simplificaiton of CSHIFT

[Steve Kargl]

On Sat, Nov 21, 2015 at 10:07:35AM -0800, H.J. Lu wrote:
> On Sat, Nov 21, 2015 at 8:26 AM, Steve Kargl
> <s...@troutmask.apl.washington.edu> wrote:
> > On Sat, Nov 21, 2015 at 11:41:51AM +0100, Paul Richard Thomas wrote:
> >>
> >> Just a couple of small typos:
> >> "Unexpected expr_type cause an ICE" ;  causes?
> >> "! An array of derived types workd too." ; works?
> >>
> >> Apart from that it's OK for trunk.
> >>
> >> Thanks for the patch
> >>
> >
> > Thanks for the the review.  I don't have a clue as
> > to how to do simplification for rank > 2. :(
> >
> 
> It breaks bootstrap:
> 
>   int dm;
> 
>   /* DIM is only useful for rank > 1, but deal with it here as one can
>  set DIM = 1 for rank = 1.  */
>   if (dim)
> {
>   if (!gfc_is_constant_expr (dim))
> return NULL;
>   dm = mpz_get_si (dim->value.integer);
> }
>   else
> dm = 1;
> 
> dm is set, but never used.
> 

Perhaps, bootstrap needs to set appropriate warning levels.

-- 
Steve

Re: [PATCH] (Partial) Implementation of simplificaiton of CSHIFT

[Steve Kargl]

On Sat, Nov 21, 2015 at 11:19:22AM -0800, H.J. Lu wrote:
> On Sat, Nov 21, 2015 at 10:20 AM, Steve Kargl
> <s...@troutmask.apl.washington.edu> wrote:
> > On Sat, Nov 21, 2015 at 10:07:35AM -0800, H.J. Lu wrote:
> >> On Sat, Nov 21, 2015 at 8:26 AM, Steve Kargl
> >> <s...@troutmask.apl.washington.edu> wrote:
> >> > On Sat, Nov 21, 2015 at 11:41:51AM +0100, Paul Richard Thomas wrote:
> >> >>
> >> >> Just a couple of small typos:
> >> >> "Unexpected expr_type cause an ICE" ;  causes?
> >> >> "! An array of derived types workd too." ; works?
> >> >>
> >> >> Apart from that it's OK for trunk.
> >> >>
> >> >> Thanks for the patch
> >> >>
> >> >
> >> > Thanks for the the review.  I don't have a clue as
> >> > to how to do simplification for rank > 2. :(
> >> >
> >>
> >> It breaks bootstrap:
> >>
> >>   int dm;
> >>
> >>   /* DIM is only useful for rank > 1, but deal with it here as one can
> >>  set DIM = 1 for rank = 1.  */
> >>   if (dim)
> >> {
> >>   if (!gfc_is_constant_expr (dim))
> >> return NULL;
> >>   dm = mpz_get_si (dim->value.integer);
> >> }
> >>   else
> >> dm = 1;
> >>
> >> dm is set, but never used.
> >>
> >
> > Perhaps, bootstrap needs to set appropriate warning levels.
> 
> https://gcc.gnu.org/ml/gcc-regression/2015-11/msg00648.html
> 

See 5 lines up.

-- 
Steve

Re: [PATCH] (Partial) Implementation of simplificaiton of CSHIFT

[Steve Kargl]

On Sat, Nov 21, 2015 at 09:22:40PM +0100, Dominique d'Humi??res wrote:
> ???dm??? is actually not used, the building problem is fixed by the patch (I 
> did not rearrange the nested ???if???s)
> 
> --- ../_clean/gcc/fortran/simplify.c  2015-11-21 20:59:57.0 +0100
> +++ gcc/fortran/simplify.c2015-11-21 21:06:30.0 +0100
> @@ -1792,7 +1792,6 @@ gfc_expr *
>  gfc_simplify_cshift (gfc_expr *array, gfc_expr *shift, gfc_expr *dim)
>  {
>gfc_expr *a, *result;
> -  int dm;
>  
>/* DIM is only useful for rank > 1, but deal with it here as one can
>   set DIM = 1 for rank = 1.  */
> @@ -1800,10 +1799,7 @@ gfc_simplify_cshift (gfc_expr *array, gf
>  {
>if (!gfc_is_constant_expr (dim))
>   return NULL;
> -  dm = mpz_get_si (dim->value.integer);
>  }
> -  else
> -dm = 1;
>  
>/* Copy array into 'a', simplify it, and then test for a constant array.
>   An unexpected expr_type causes an ICE.   */
> 

I already fix the problem.

Your patch unfixes the valid code that is needed for the rank>2 case.

-- 
Steve

Re: [PATCH] (Partial) Implementation of simplificaiton of CSHIFT

[Steve Kargl]

On Sat, Nov 21, 2015 at 11:26:17PM +0100, Eric Botcazou wrote:
> > +   * simplify.c (gfc_simplify_cshift): Work around bootstrap issues
> > +   due to inappropriate warning options.
> 
> The warning options are appropriate, any dead code can potentially hide a bug 
> and should be flagged; every static analyzer will also do it and we would 
> soon 
> have PRs opened with bugzilla if we tolerated it.
> 

I disgree.

If bootstrap is going to enforce -Werror -Wunused-*, then 
this should be the default for any possible invocation of
make.

-- 
Steve

Re: [PATCH] (Partial) Implementation of simplificaiton of CSHIFT

[Steve Kargl]

> > >
> > > Perhaps, bootstrap needs to set appropriate warning levels.
> > 
> > https://gcc.gnu.org/ml/gcc-regression/2015-11/msg00648.html
> > 
> 
> See 5 lines up.
> 

Committed.

Index: ChangeLog
===
--- ChangeLog   (revision 230709)
+++ ChangeLog   (working copy)
@@ -1,5 +1,10 @@
 2015-11-21  Steven G. Kargl  
 
+   * simplify.c (gfc_simplify_cshift): Work around bootstrap issues
+   due to inappropriate warning options. 
+
+2015-11-21  Steven G. Kargl  
+
* simplify.c (gfc_simplify_cshift): Implement simplification of
CSHIFT for rank=1 arrays.
(gfc_simplify_spread): Remove a FIXME and add error condition.
Index: simplify.c
===
--- simplify.c  (revision 230709)
+++ simplify.c  (working copy)
@@ -1869,6 +1869,15 @@ gfc_simplify_cshift (gfc_expr *array, gf
   else
 {
   /* FIXME: Deal with rank > 1 arrays.  For now, don't leak memory.  */
+
+  /* GCC bootstrap is too stupid to realize that the above code for dm
+is correct.  First, dim can be specified for a rank 1 array.  It is
+not needed in this nor used here.  Second, the code is simply waiting
+for someone to implement rank > 1 simplification.   For now, add a
+pessimization to the code that has a zero valid reason to be here.  */
+  if (dm > array->rank)
+   gcc_unreachable ();
+
   gfc_free_expr (a);
 }
 
-- 
Steve

Re: [PATCH] (Partial) Implementation of simplificaiton of CSHIFT

[Steve Kargl]

On Thu, Nov 19, 2015 at 04:58:36PM -0800, Steve Kargl wrote:
> 
> 2015-11-19  Steven G. Kargl  <ka...@gcc.gnu.org>
> 
>   * intrinsic.h: Prototype for gfc_simplify_cshift
>   * intrinsic.c (add_functions): Use gfc_simplify_cshift.
>   * simplify.c (gfc_simplify_cshift): Implement simplification of CSHIFT.
>   (gfc_simplify_spread): Remove a FIXME and add error condition.
>  
> 2015-11-19  Steven G. Kargl  <ka...@gcc.gnu.org>
> 
>   * gfortran.dg/simplify_cshift_1.f90: New test.
> 

I've attached an updated patch.  The changes consists of
1) better/more comments
2) re-organize code to reduce copying of the array.
3) add optimization for a left/right shift that 
   returns the original array.
4) Don't leak memory.

-- 
Steve
Index: gcc/fortran/intrinsic.c
===
--- gcc/fortran/intrinsic.c	(revision 230585)
+++ gcc/fortran/intrinsic.c	(working copy)
@@ -1659,9 +1659,11 @@ add_functions (void)
 
   make_generic ("count", GFC_ISYM_COUNT, GFC_STD_F95);
 
-  add_sym_3 ("cshift", GFC_ISYM_CSHIFT, CLASS_TRANSFORMATIONAL, ACTUAL_NO, BT_REAL, dr, GFC_STD_F95,
-	 gfc_check_cshift, NULL, gfc_resolve_cshift,
-	 ar, BT_REAL, dr, REQUIRED, sh, BT_INTEGER, di, REQUIRED,
+  add_sym_3 ("cshift", GFC_ISYM_CSHIFT, CLASS_TRANSFORMATIONAL, ACTUAL_NO,
+	 BT_REAL, dr, GFC_STD_F95,
+	 gfc_check_cshift, gfc_simplify_cshift, gfc_resolve_cshift,
+	 ar, BT_REAL, dr, REQUIRED,
+	 sh, BT_INTEGER, di, REQUIRED,
 	 dm, BT_INTEGER, ii, OPTIONAL);
 
   make_generic ("cshift", GFC_ISYM_CSHIFT, GFC_STD_F95);
Index: gcc/fortran/intrinsic.h
===
--- gcc/fortran/intrinsic.h	(revision 230585)
+++ gcc/fortran/intrinsic.h	(working copy)
@@ -271,6 +271,7 @@ gfc_expr *gfc_simplify_conjg (gfc_expr *
 gfc_expr *gfc_simplify_cos (gfc_expr *);
 gfc_expr *gfc_simplify_cosh (gfc_expr *);
 gfc_expr *gfc_simplify_count (gfc_expr *, gfc_expr *, gfc_expr *);
+gfc_expr *gfc_simplify_cshift (gfc_expr *, gfc_expr *, gfc_expr *);
 gfc_expr *gfc_simplify_dcmplx (gfc_expr *, gfc_expr *);
 gfc_expr *gfc_simplify_dble (gfc_expr *);
 gfc_expr *gfc_simplify_digits (gfc_expr *);
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c	(revision 230585)
+++ gcc/fortran/simplify.c	(working copy)
@@ -1789,6 +1789,99 @@ gfc_simplify_count (gfc_expr *mask, gfc_
 
 
 gfc_expr *
+gfc_simplify_cshift (gfc_expr *array, gfc_expr *shift, gfc_expr *dim)
+{
+  int dm;
+  gfc_expr *a;
+
+  /* DIM is only useful for rank > 1, but deal with it here as one can
+ set DIM = 1 for rank = 1.  */
+  if (dim)
+{
+  if (!gfc_is_constant_expr (dim))
+	  return NULL;
+  dm = mpz_get_si (dim->value.integer);
+}
+  else
+dm = 1;
+
+  /* Copy array into 'a', simplify it, and then test for a constant array.
+ Unexpected expr_type cause an ICE.   */
+  switch (array->expr_type)
+{
+  case EXPR_VARIABLE:
+  case EXPR_ARRAY:
+	a = gfc_copy_expr (array);
+	gfc_simplify_expr (a, 0);
+	if (!is_constant_array_expr (a))
+	  {
+	gfc_free_expr (a);
+	return NULL;
+	  }
+	break;
+  default:
+	gcc_unreachable ();
+}
+
+  if (a->rank == 1)
+{
+  gfc_constructor *ca, *cr;
+  gfc_expr *result;
+  mpz_t size;
+  int i, j, shft, sz;
+
+  if (!gfc_is_constant_expr (shift))
+	{
+	  gfc_free_expr (a);
+	  return NULL;
+	}
+
+  shft = mpz_get_si (shift->value.integer);
+
+  /*  Case (i):  If ARRAY has rank one, element i of the result is
+	  ARRAY (1 + MODULO (i + SHIFT ­ 1, SIZE (ARRAY))).  */
+
+  mpz_init (size);
+  gfc_array_size (a, );
+  sz = mpz_get_si (size);
+  mpz_clear (size);
+
+  /* Special case: rank 1 array with no shift or a complete shift to
+	 the original order!  */
+  if (shft == 0 || shft == sz || shft == 1 - sz)
+	return a;
+
+  /* Adjust shft to deal with right or left shifts. */
+  shft = shft < 0 ? 1 - shft : shft;
+
+  result = gfc_copy_expr (a);
+  cr = gfc_constructor_first (result->value.constructor);
+  for (i = 0; i < sz; i++, cr = gfc_constructor_next (cr))
+	{
+	  j = (i + shft) % sz;
+	  ca = gfc_constructor_first (a->value.constructor);
+	  while (j-- > 0)
+	ca = gfc_constructor_next (ca);
+	  cr->expr = gfc_copy_expr (ca->expr);
+	}
+
+  gfc_free_expr (a);
+  return result;
+}
+  else
+{
+  /* FIXME: Deal with rank > 1 arrays.  For now, don't leak memory
+	 and exit with an error message.  */
+  gfc_free_expr (a);
+  gfc_error ("Simplification of CSHIFT with an array with rank > 1 "
+	 "no yet support");
+}
+
+  return NULL;
+}
+
+
+gfc_expr *
 gfc_simplify_dcmplx (gfc_expr *x, gfc_expr *y)
 {
   return simplify_cmplx ("

[PATCH] (Partial) Implementation of simplificaiton of CSHIFT

[Steve Kargl]

The attached patch provides a partial implementation for
the simplification for CSHIFT.  It is partial in that it
only applies to rank 1 arrays.  For arrays with rank > 1,
gfc_simplify_cshift will issue an error.  Here, the intent
is that hopefully someone that knows what they are doing
with supply a patch for rank > 1.

The meat of the patch for rank = 1 may not be the most
efficient.  It copies the array elements from 'a' to 'result'
in the circularly shifted order.  It inefficiently always
starts with the first element in 'a' to find the candidate
element for next 'result' element.

  cr = gfc_constructor_first (result->value.constructor);
  for (i = 0; i < sz; i++, cr = gfc_constructor_next (cr))
{
  j = (i + shft) % sz;
  ca = gfc_constructor_first (a->value.constructor);
  while (j-- > 0)
ca = gfc_constructor_next (ca);
  cr->expr = gfc_copy_expr (ca->expr);
}

As the values are storied in a splay tree, there may be
a more efficient way to split the splay and recombine
it into a new.

Anyway, I would like to commit the attached patch.
Built and tested on x86_64-*-freebsd?

2015-11-19  Steven G. Kargl  

* intrinsic.h: Prototype for gfc_simplify_cshift
* intrinsic.c (add_functions): Use gfc_simplify_cshift.
* simplify.c (gfc_simplify_cshift): Implement simplification of CSHIFT.
(gfc_simplify_spread): Remove a FIXME and add error condition.
 
2015-11-19  Steven G. Kargl  

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

-- 
Steve
Index: gcc/fortran/intrinsic.c
===
--- gcc/fortran/intrinsic.c	(revision 230585)
+++ gcc/fortran/intrinsic.c	(working copy)
@@ -1659,9 +1659,11 @@ add_functions (void)
 
   make_generic ("count", GFC_ISYM_COUNT, GFC_STD_F95);
 
-  add_sym_3 ("cshift", GFC_ISYM_CSHIFT, CLASS_TRANSFORMATIONAL, ACTUAL_NO, BT_REAL, dr, GFC_STD_F95,
-	 gfc_check_cshift, NULL, gfc_resolve_cshift,
-	 ar, BT_REAL, dr, REQUIRED, sh, BT_INTEGER, di, REQUIRED,
+  add_sym_3 ("cshift", GFC_ISYM_CSHIFT, CLASS_TRANSFORMATIONAL, ACTUAL_NO,
+	 BT_REAL, dr, GFC_STD_F95,
+	 gfc_check_cshift, gfc_simplify_cshift, gfc_resolve_cshift,
+	 ar, BT_REAL, dr, REQUIRED,
+	 sh, BT_INTEGER, di, REQUIRED,
 	 dm, BT_INTEGER, ii, OPTIONAL);
 
   make_generic ("cshift", GFC_ISYM_CSHIFT, GFC_STD_F95);
Index: gcc/fortran/intrinsic.h
===
--- gcc/fortran/intrinsic.h	(revision 230585)
+++ gcc/fortran/intrinsic.h	(working copy)
@@ -271,6 +271,7 @@ gfc_expr *gfc_simplify_conjg (gfc_expr *
 gfc_expr *gfc_simplify_cos (gfc_expr *);
 gfc_expr *gfc_simplify_cosh (gfc_expr *);
 gfc_expr *gfc_simplify_count (gfc_expr *, gfc_expr *, gfc_expr *);
+gfc_expr *gfc_simplify_cshift (gfc_expr *, gfc_expr *, gfc_expr *);
 gfc_expr *gfc_simplify_dcmplx (gfc_expr *, gfc_expr *);
 gfc_expr *gfc_simplify_dble (gfc_expr *);
 gfc_expr *gfc_simplify_digits (gfc_expr *);
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c	(revision 230585)
+++ gcc/fortran/simplify.c	(working copy)
@@ -1789,6 +1789,88 @@ gfc_simplify_count (gfc_expr *mask, gfc_
 
 
 gfc_expr *
+gfc_simplify_cshift (gfc_expr *array, gfc_expr *shift, gfc_expr *dim)
+{
+  gfc_expr *a;
+
+  a = gfc_copy_expr (array);
+
+  switch (a->expr_type)
+{
+  case EXPR_VARIABLE:
+  case EXPR_ARRAY:
+	gfc_simplify_expr (a, 0);
+	if (!is_constant_array_expr (a))
+	  {
+	gfc_free_expr (a);
+	return NULL;
+	  }
+	break;
+  default:
+	gcc_unreachable ();
+}
+
+  if (a->rank == 1)
+{
+  gfc_constructor *ca, *cr;
+  gfc_expr *result;
+  mpz_t size;
+  int i, j, shft, sz;
+
+  if (!gfc_is_constant_expr (shift))
+	return NULL;
+
+  shft = mpz_get_si (shift->value.integer);
+
+  /* Special case: rank 1 array with no shift!  */
+  if (shft == 0)
+	return a;
+
+  /*  Case (i):  If ARRAY has rank one, element i of the result is
+	  ARRAY (1 + MODULO (i + SHIFT ­ 1, SIZE (ARRAY))).  */
+
+  result = gfc_copy_expr (a);
+  mpz_init (size);
+  gfc_array_size (a, );
+  sz = mpz_get_si (size);
+  mpz_clear (size);
+  shft = shft < 0 ? 1 - shft : shft;
+  cr = gfc_constructor_first (result->value.constructor);
+  for (i = 0; i < sz; i++, cr = gfc_constructor_next (cr))
+	{
+	  j = (i + shft) % sz;
+	  ca = gfc_constructor_first (a->value.constructor);
+	  while (j-- > 0)
+	ca = gfc_constructor_next (ca);
+	  cr->expr = gfc_copy_expr (ca->expr);
+	}
+
+  gfc_free_expr (a);
+  return result;
+}
+  else
+{
+  int dm;
+
+  if (dim)
+	{
+	  if (!gfc_is_constant_expr (dim))
+	return NULL;
+
+	  dm = mpz_get_si (dim->value.integer);
+	}
+  else
+	dm = 1;
+
+  gfc_error ("Simplification of CSHIFT with an array with rank > 1 "

Re: [PATCH] (Partial) Implementation of simplificaiton of CSHIFT

[Steve Kargl]

On Thu, Nov 19, 2015 at 04:58:36PM -0800, Steve Kargl wrote:
> +  else
> +{
> +  int dm;
> +
> +  if (dim)
> + {
> +   if (!gfc_is_constant_expr (dim))
> + return NULL;
> +
> +   dm = mpz_get_si (dim->value.integer);
> + }
> +  else
> + dm = 1;
> +
> +  gfc_error ("Simplification of CSHIFT with an array with rank > 1 "
> +  "no yet support");
> +}
> +

To save some time, the dim portion of the patch isn't
correct.  dim can be scalar or rank 1 array.  I'll
#if 0 ... #endif this section unless I persevere with
the rank > 1 case.

-- 
Steve

Re: [PATCH] (Partial) Implementation of simplificaiton of CSHIFT

[Steve Kargl]

On Thu, Nov 19, 2015 at 05:31:32PM -0800, Steve Kargl wrote:
> On Thu, Nov 19, 2015 at 04:58:36PM -0800, Steve Kargl wrote:
> > +  else
> > +{
> > +  int dm;
> > +
> > +  if (dim)
> > +   {
> > + if (!gfc_is_constant_expr (dim))
> > +   return NULL;
> > +
> > + dm = mpz_get_si (dim->value.integer);
> > +   }
> > +  else
> > +   dm = 1;
> > +
> > +  gfc_error ("Simplification of CSHIFT with an array with rank > 1 "
> > +"no yet support");
> > +}
> > +
> 
> To save some time, the dim portion of the patch isn't
> correct.  dim can be scalar or rank 1 array.  I'll
> #if 0 ... #endif this section unless I persevere with
> the rank > 1 case.

Ugh.  Too much gdb today.  The above is correct.  I conflated
SHIFT and DIM's requirements.

-- 
Steve

Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement

[Steve Kargl]

On Tue, Nov 17, 2015 at 05:01:42PM -0800, Steve Kargl wrote:
> On Tue, Nov 17, 2015 at 04:36:01PM -0800, Steve Kargl wrote:
> > On Wed, Nov 18, 2015 at 12:24:29AM +0100, Dominique d'Humières wrote:
> > > > ??? but I suspect gfc_reduce_init_expr() 
> > > > may be useful for PARAMETER statements as well (need to
> > > > check this!).
> > > 
> > > As in the following test
> > > 
> > >   module m
> > > implicit none
> > > type t
> > >   integer :: i
> > > end type t
> > > type(t), dimension(2), parameter :: a1  = (/ t(1), t(2) /)
> > > type(t), dimension(1), parameter :: c = spread ( a1(1), 1, 1 )
> > >   end module m
> > 
> > Yep.  We again arrive at gfc_conv_array_initializer with
> > expr->expr_type == EXPR_FUNCTION, which isn't handled correctly.
> > 
> > The issue seems deeply rooted in the handling of derived types,
> > which is actually worse than this!  But, that is definitely for
> > another day.  See PR67817. :(
> 
> Ugh. gfc_simplify_spread does not actually the use of SPREAD
> here, because source->expr_type == EXPR_STRUCTURE which is not
> handled.

Dominiq,

I plan to commit my patch and close this PR as the patch
fixes the issue raised in the PR.  I think the above
code highlights a specific issue with SPREAD, and a new PR
should be committed.
-- 
Steve

Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement

[Steve Kargl]

On Wed, Nov 18, 2015 at 11:23:21AM -0800, Steve Kargl wrote:
> On Tue, Nov 17, 2015 at 05:01:42PM -0800, Steve Kargl wrote:
> > On Tue, Nov 17, 2015 at 04:36:01PM -0800, Steve Kargl wrote:
> > > On Wed, Nov 18, 2015 at 12:24:29AM +0100, Dominique d'Humières wrote:
> > > > > ??? but I suspect gfc_reduce_init_expr() 
> > > > > may be useful for PARAMETER statements as well (need to
> > > > > check this!).
> > > > 
> > > > As in the following test
> > > > 
> > > >   module m
> > > > implicit none
> > > > type t
> > > >   integer :: i
> > > > end type t
> > > > type(t), dimension(2), parameter :: a1  = (/ t(1), t(2) /)
> > > > type(t), dimension(1), parameter :: c = spread ( a1(1), 1, 1 )
> > > >   end module m
> > > 
> > > Yep.  We again arrive at gfc_conv_array_initializer with
> > > expr->expr_type == EXPR_FUNCTION, which isn't handled correctly.
> > > 
> > > The issue seems deeply rooted in the handling of derived types,
> > > which is actually worse than this!  But, that is definitely for
> > > another day.  See PR67817. :(
> > 
> > Ugh. gfc_simplify_spread does not actually the use of SPREAD
> > here, because source->expr_type == EXPR_STRUCTURE which is not
> > handled.
> 
> Dominiq,
> 
> I plan to commit my patch and close this PR as the patch
> fixes the issue raised in the PR.  I think the above
> code highlights a specific issue with SPREAD, and a new PR
> should be committed.

This is now PR fortran/68426

-- 
Steve

[PATCH] PR fortran/43996 -- Too large array constructor in SPREAD

[Steve Kargl]

The attached patch fixes an issue with SPREAD and the PARAMETER
attribute when an array constructor is too large for expansion.
gfortran now issues an error message and points to the 
-fmax-array-constructor.

Patch built on i386-*-freebsd and x86_64-*-freebsd.  There are
no regressions.  OK to commit?

2015-11-17  Steven G. Kargl  

PR fortran/43996
* simplify.c (gfc_simplify_spread): Issue error for too large array 
constructor in a PARAMETER statement.

2015-11-17  Steven G. Kargl  

PR fortran/43996
* gfortran.dg/pr43996.f90

-- 
Steve
Index: gcc/fortran/simplify.c
===
--- gcc/fortran/simplify.c	(revision 230463)
+++ gcc/fortran/simplify.c	(working copy)
@@ -5991,8 +5991,8 @@ gfc_simplify_spacing (gfc_expr *x)
 gfc_expr *
 gfc_simplify_spread (gfc_expr *source, gfc_expr *dim_expr, gfc_expr *ncopies_expr)
 {
-  gfc_expr *result = 0L;
-  int i, j, dim, ncopies;
+  gfc_expr *result = NULL;
+  int nelem, i, j, dim, ncopies;
   mpz_t size;
 
   if ((!gfc_is_constant_expr (source)
@@ -6019,8 +6019,20 @@ gfc_simplify_spread (gfc_expr *source, g
   else
 mpz_init_set_ui (size, 1);
 
-  if (mpz_get_si (size)*ncopies > flag_max_array_constructor)
-return NULL;
+  nelem = mpz_get_si (size) * ncopies;
+  if (nelem > flag_max_array_constructor)
+{
+  if (gfc_current_ns->sym_root->n.sym->attr.flavor == FL_PARAMETER)
+	{
+	  gfc_error ("The number of elements (%d) in the array constructor "
+		 "at %L requires an increase of the allowed %d upper "
+		 "limit.  See %<-fmax-array-constructor%> option.",
+		 nelem, >where, flag_max_array_constructor);
+	  return _bad_expr;
+	}
+  else
+	return NULL;
+}
 
   if (source->expr_type == EXPR_CONSTANT)
 {
Index: gcc/testsuite/gfortran.dg/pr43996.f90
===
--- gcc/testsuite/gfortran.dg/pr43996.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr43996.f90	(working copy)
@@ -0,0 +1,7 @@
+! { dg-do compile }
+! PR fortran/43996
+!
+real, parameter :: a(720,360) = spread((/(j, j=1,720) /), dim=2, ncopies=360) ! { dg-error "number of elements" }
+real x
+x = a(720,360)
+end

Re: [PATCH] PR 65751 Bogus in error message

[Steve Kargl]

On Tue, Nov 17, 2015 at 10:53:52AM +0100, Dominique d'Humi??res wrote:
> Is the following patch OK for trunk and 5.3? 

OK.

> 
> I have used the legalese found in my draft for Fortran 2015.
> Would it be acceptable to replace 
> "with the BIND attribute or the SEQUENCE attribute" 
> with
> "with the BIND or SEQUENCE attribute"?

In my opinion, yes.

-- 
Steve

[PATCH] PR fortran/59910 -- structure constructor in DATA statement

[Steve Kargl]

Here's what looks like a fairly simple patch, but it leads
to a question.  Why does gfortran not try to reduce the 
components in a structure constructor in general?  I've
hidden the gfc_reduce_init_expr() behind a check for a
DATA statement, but I suspect gfc_reduce_init_expr() 
may be useful for PARAMETER statements as well (need to
check this!).

Anyway, the patch has been built and tested on x86_64-*-freebsd.
A slightly different patch was built and tested on i386-*-freebsd.

OK to commit?

2015-11-17  Steven G. Kargl  

PR fortran/59910
* primary.c (gfc_match_structure_constructor): Reduce a structure
constructor in a DATA statement.

2015-11-17  Steven G. Kargl  

PR fortran/59910
* gfortran.dg/pr59910.f90:

-- 
Steve
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c	(revision 230497)
+++ gcc/fortran/primary.c	(working copy)
@@ -2722,6 +2722,12 @@ gfc_match_structure_constructor (gfc_sym
   return MATCH_ERROR;
 }
 
+  /* If a structure constructor is in a DATA statement, then each entity
+ in the structure constructor must be a constant.  Try to reduce the
+ expression here.  */
+  if (gfc_in_match_data ())
+gfc_reduce_init_expr (e);
+
   *result = e;
   return MATCH_YES;
 }
Index: gcc/testsuite/gfortran.dg/pr59910.f90
===
--- gcc/testsuite/gfortran.dg/pr59910.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr59910.f90	(working copy)
@@ -0,0 +1,11 @@
+! { dg-do compile }
+! PR fortran/59910
+!
+program main
+  implicit none
+  type bar
+  integer :: limit(1)
+  end type
+  type (bar) :: testsuite
+  data testsuite / bar(reshape(source=[10],shape=[1])) /
+end

Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement

[Steve Kargl]

On Tue, Nov 17, 2015 at 04:36:01PM -0800, Steve Kargl wrote:
> On Wed, Nov 18, 2015 at 12:24:29AM +0100, Dominique d'Humières wrote:
> > > ??? but I suspect gfc_reduce_init_expr() 
> > > may be useful for PARAMETER statements as well (need to
> > > check this!).
> > 
> > As in the following test
> > 
> >   module m
> > implicit none
> > type t
> >   integer :: i
> > end type t
> > type(t), dimension(2), parameter :: a1  = (/ t(1), t(2) /)
> > type(t), dimension(1), parameter :: c = spread ( a1(1), 1, 1 )
> >   end module m
> > 
> 
> Yep.  We again arrive at gfc_conv_array_initializer with
> expr->expr_type == EXPR_FUNCTION, which isn't handled correctly.
> 
> The issue seems deeply rooted in the handling of derived types,
> which is actually worse than this!  But, that is definitely for
> another day.  See PR67817. :(
> 

Ugh. gfc_simplify_spread does not actually the use of SPREAD
here, because source->expr_type == EXPR_STRUCTURE which is not
handled.

-- 
Steve

Re: [PATCH] PR fortran/59910 -- structure constructor in DATA statement

[Steve Kargl]

On Wed, Nov 18, 2015 at 12:24:29AM +0100, Dominique d'Humières wrote:
> > ??? but I suspect gfc_reduce_init_expr() 
> > may be useful for PARAMETER statements as well (need to
> > check this!).
> 
> As in the following test
> 
>   module m
> implicit none
> type t
>   integer :: i
> end type t
> type(t), dimension(2), parameter :: a1  = (/ t(1), t(2) /)
> type(t), dimension(1), parameter :: c = spread ( a1(1), 1, 1 )
>   end module m
> 

Yep.  We again arrive at gfc_conv_array_initializer with
expr->expr_type == EXPR_FUNCTION, which isn't handled correctly.

The issue seems deeply rooted in the handling of derived types,
which is actually worse than this!  But, that is definitely for
another day.  See PR67817. :(

-- 
Steve

[PATCH, committed] fortran/primary.c -- fix whitespace

[Steve Kargl]

For the record, I committed the following:

2015-11-17  Steven G. Kargl  

* primary.c (gfc_match_structure_constructor): Fix whitespace.

-- 
Steve
Index: primary.c
===
--- primary.c   (revision 230494)
+++ primary.c   (working copy)
@@ -2709,21 +2709,21 @@ gfc_match_structure_constructor (gfc_sym
   e->value.function.esym = sym;
   e->symtree->n.sym->attr.generic = 1;
 
-   m = gfc_match_actual_arglist (0, >value.function.actual);
-   if (m != MATCH_YES)
- {
-   gfc_free_expr (e);
-   return m;
- }
-
-   if (!gfc_convert_to_structure_constructor (e, sym, NULL, NULL, false))
- {
-   gfc_free_expr (e);
-   return MATCH_ERROR;
- }
+  m = gfc_match_actual_arglist (0, >value.function.actual);
+  if (m != MATCH_YES)
+{
+  gfc_free_expr (e);
+  return m;
+}
 
-   *result = e;
-   return MATCH_YES;
+  if (!gfc_convert_to_structure_constructor (e, sym, NULL, NULL, false))
+{
+  gfc_free_expr (e);
+  return MATCH_ERROR;
+}
+
+  *result = e;
+  return MATCH_YES;
 }
 
 

[PATCH] PR fortran/58027,60993 -- BOZ in array constructor initialization expression

[Steve Kargl]

First, thanks to Dominiq for prodding me into looking at PR 58027.

This was a fun ICE to track down!

Most users have no idea what the Fortran standard requires for
the parsing of a BOZ.  Consider the line of code

  integer, parameter :: i(1) = (/ z'ff80' /)

The naive user wants to assign a BOZ interpreted as a 32-bit entity
to i(1) in an array constructor.  Ignoring the fact that a BOZ 
can't be used here, the BOZ is converted to an integer with the
widest decimal exponential range.  On all(?) targets this is at
least a 64-bit integer (known as INTEGER(8)).  To do the assignment
gfortan inserts a __convert_i8_i4(), but it does so after any
checking for an initialization expression.  So, when gfortran
finally gets around to calling gfc_conv_array_initializer() to
translates into tree-ssa form, gfc_conv_array_initializer() is not
expecting a function and dies with an ICE. 

The fix is affected by calling gfc_check_init_expr() under
appropriate conditions.  Because the __convert_* functions
are sort of psuedo-intrinsic procedures, a check for an intrinsic
procedure needs to be circumvented.

Anyway, the patch has been built and tested on i386-*-freebsd
and x86_64-*-freebsd.  OK to commit?

2015-11-15  Steven G. Kargl  

PR fortran/58027
PR fortran/60993
* expr.c (gfc_check_init_expr): Prevent a redundant check when a
__convert_* function was inserted into an array constructor.
(gfc_check_assign_symbol): Check for an initialization expression
when a __convert_* was inserted.

2015-11-15  Steven G. Kargl  

PR fortran/58027
PR fortran/60993
* gfortran.dg/pr58027.f90: New test.

-- 
Steve
Index: gcc/fortran/expr.c
===
--- gcc/fortran/expr.c	(revision 230397)
+++ gcc/fortran/expr.c	(working copy)
@@ -2471,7 +2471,8 @@ gfc_check_init_expr (gfc_expr *e)
   t = false;
 
   {
-	gfc_intrinsic_sym* isym;
+	bool conversion;
+	gfc_intrinsic_sym* isym = NULL;
 	gfc_symbol* sym = e->symtree->n.sym;
 
 	/* Simplify here the intrinsics from the IEEE_ARITHMETIC and
@@ -2490,8 +2491,14 @@ gfc_check_init_expr (gfc_expr *e)
 	  }
 	  }
 
-	if (!gfc_is_intrinsic (sym, 0, e->where)
-	|| (m = gfc_intrinsic_func_interface (e, 0)) != MATCH_YES)
+	/* If a conversion function, e.g., __convert_i8_i4, was inserted
+	   into an array constructor, we need to skip the error check here.
+   Conversion errors are  caught below in scalarize_intrinsic_call.  */
+	conversion = e->value.function.isym
+		   && (e->value.function.isym->conversion == 1);
+
+	if (!conversion && (!gfc_is_intrinsic (sym, 0, e->where)
+	|| (m = gfc_intrinsic_func_interface (e, 0)) != MATCH_YES))
 	  {
 	gfc_error ("Function %qs in initialization expression at %L "
 		   "must be an intrinsic function",
@@ -2518,7 +2525,7 @@ gfc_check_init_expr (gfc_expr *e)
 	   array argument.  */
 	isym = gfc_find_function (e->symtree->n.sym->name);
 	if (isym && isym->elemental
-	&& (t = scalarize_intrinsic_call(e)))
+	&& (t = scalarize_intrinsic_call (e)))
 	  break;
   }
 
@@ -3844,7 +3851,17 @@ gfc_check_assign_symbol (gfc_symbol *sym
   if (pointer || proc_pointer)
 r = gfc_check_pointer_assign (, rvalue);
   else
-r = gfc_check_assign (, rvalue, 1);
+{
+  /* If a conversion function, e.g., __convert_i8_i4, was inserted
+	 into an array constructor, we should check if it can be reduced
+	 as an initialization expression.  */
+  if (rvalue->expr_type == EXPR_FUNCTION
+	  && rvalue->value.function.isym
+	  && (rvalue->value.function.isym->conversion == 1))
+	gfc_check_init_expr (rvalue);
+
+  r = gfc_check_assign (, rvalue, 1);
+}
 
   free (lvalue.symtree);
   free (lvalue.ref);
Index: gcc/testsuite/gfortran.dg/pr58027.f90
===
--- gcc/testsuite/gfortran.dg/pr58027.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr58027.f90	(working copy)
@@ -0,0 +1,5 @@
+! { dg-do compile }
+! PR fortran/58027
+integer, parameter :: i(1)=(/z'ff80'/) ! { dg-error "overflow converting" }
+print *, isclass
+end

Re: [PATCH] PR fortran/68283 -- remove a rogue gfc_internal_error()

[Steve Kargl]

On Sat, Nov 14, 2015 at 02:51:08PM +0100, Dominique d'Humi??res wrote:
> Hi Steve,
> 
> Although I have not strong objection to your proposed patch,
> I???ld prefer the following one

The patch is fine.  Need a ChangeLog entry.

(patch elided)

>  
> Now both patches are just papering over the real issues:
> 
> (1) Why is this block reached when compiling with -ffrontend-optimize,
> but not with -fno-frontend-optimize (Thomas)?

I saw Thomas's reply.  Of course, -ffrontend-optimize takes a
different code path through the compiler and rewrites some of
the internal state along the way.  If the source code is fixed,
the ICE goes away.  Why waste time worrying about the cause of
an ICE that clearly should be suppressed in the presences of a
sequence of emitted errors?

> (2) Is there expected side effect(s) when removing the' for???
> block introduced at revision r221955 for pr56852 (Paul)?

I doubt that there are anything side effects.

-- 
Steve

Re: Ping: [Patch, fortran] Bug 68241 - [meta-bug] Deferred-length character - PRs50221, 68216, 63932, 66408, 67674 and 49954

[Steve Kargl]

On Sat, Nov 14, 2015 at 06:39:28PM +0100, Paul Richard Thomas wrote:
> 
> I am completely unable to reproduce the problems that Dominique is
> reporting for deferred_character_4.f90. This might be because the
> patch has moved on to fix PR49554 :-)
> 
> Concatenation expressions assigned to deferred length character arrays
> need careful handling to ensure that the temporary creation for the
> concatenation operator occurs at the right place, that the descriptor
> dtype is updated and an array temporary is created if there is any
> dependency between lhs and rhs. This latter has been implemented in
> resolve.c.
> 
> Testcases 4-6 have been added to reflect the additional fixes afforded
> by the original patch, as reported by Dominique (thanks!).
> 
> As soon as this patch has been committed, I will prepare a version for
> 4.9 and 5 branches
> 
> Bootstrapped and regtested on FC21/x86_64 - OK for trunk?
> 

Hi Paul,

I was going to cast an eye over your diff today.  I'll
build and run some tests on FreeBSD.  Dominiq uses 
MacOS.  So, perhaps, some latent memory corruption 
issue. 

-- 
steve

Re: Ping: [Patch, fortran] Bug 68241 - [meta-bug] Deferred-length character - PRs50221, 68216, 63932, 66408, 67674 and 49954

[Steve Kargl]

On Sat, Nov 14, 2015 at 07:25:29PM +0100, Paul Richard Thomas wrote:
> 
> Following an email from Dominique to me, I think not. In the course of
> fixing PR49954, I put right the setting of the descriptor dtype. Since
> this gets passed to the IO runtime, I think that this is the reason
> for the difference in behaviour.
> 
> I think that another week of effort should put right gfortran's woes
> with deferred characters. As well as concatenation problems that I
> think I have fixed, parentheses cause instant death :-(
> 

Hi Paul,

I built and tested on both x86_64-*-freebsd and i386-*-freebsd.
All tests passed.

I read through the patch did not raise any red (or what
the heck is he doing here) flags.

OK to commit as this is a step in the right direction in
dealing with deferred character issues.

-- 
Steve

[PATCH] PR fortran/68319 -- Implement checks for F2008:C1206

[Steve Kargl]

The attached patch implements the checks required by
constraint C1206 from Fortran 2008 standard.  Built
and regression tested on x86_64-*-freebsd.  OK to
commmit?

2015-11-13  Steven G. Kargl  

PR fortran/68319
* decl.c (gfc_match_data, gfc_match_entry): Enforce F2008:C1206.
* io.c (gfc_match_format): Ditto.
* match.c (gfc_match_st_function): Ditto.

2015-11-13  Steven G. Kargl  

PR fortran/68319
* gfortran.dg/pr68319.f90: New test.

-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 230336)
+++ gcc/fortran/decl.c	(working copy)
@@ -552,6 +552,15 @@ gfc_match_data (void)
   gfc_data *new_data;
   match m;
 
+  /* Before parsing the rest of a DATA statement, check F2008:c1206.  */
+  if ((gfc_current_state () == COMP_FUNCTION
+   || gfc_current_state () == COMP_SUBROUTINE)
+  && gfc_state_stack->previous->state == COMP_INTERFACE)
+{
+  gfc_error ("DATA statement at %C cannot appear within an INTERFACE");
+  return MATCH_ERROR;
+}
+
   set_in_match_data (true);
 
   for (;;)
@@ -5767,6 +5776,13 @@ gfc_match_entry (void)
   return MATCH_ERROR;
 }
 
+  if ((state == COMP_SUBROUTINE || state == COMP_FUNCTION)
+  && gfc_state_stack->previous->state == COMP_INTERFACE)
+{
+  gfc_error ("ENTRY statement at %C cannot appear within an INTERFACE");
+  return MATCH_ERROR;
+}
+
   module_procedure = gfc_current_ns->parent != NULL
 		   && gfc_current_ns->parent->proc_name
 		   && gfc_current_ns->parent->proc_name->attr.flavor
Index: gcc/fortran/io.c
===
--- gcc/fortran/io.c	(revision 230336)
+++ gcc/fortran/io.c	(working copy)
@@ -1199,6 +1199,15 @@ gfc_match_format (void)
   return MATCH_ERROR;
 }
 
+  /* Before parsing the rest of a FORMAT statement, check F2008:c1206.  */
+  if ((gfc_current_state () == COMP_FUNCTION
+   || gfc_current_state () == COMP_SUBROUTINE)
+  && gfc_state_stack->previous->state == COMP_INTERFACE)
+{
+  gfc_error ("FORMAT statement at %C cannot appear within an INTERFACE");
+  return MATCH_ERROR;
+}
+
   if (gfc_statement_label == NULL)
 {
   gfc_error ("Missing format label at %C");
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c	(revision 230336)
+++ gcc/fortran/match.c	(working copy)
@@ -4913,6 +4913,15 @@ gfc_match_st_function (void)
 
   sym->value = expr;
 
+  if ((gfc_current_state () == COMP_FUNCTION
+   || gfc_current_state () == COMP_SUBROUTINE)
+  && gfc_state_stack->previous->state == COMP_INTERFACE)
+{
+  gfc_error ("Statement function at %L cannot appear within an INTERFACE",
+		 >where);
+  return MATCH_ERROR;
+}
+
   if (!gfc_notify_std (GFC_STD_F95_OBS, "Statement function at %C"))
 return MATCH_ERROR;
 
Index: gcc/testsuite/gfortran.dg/pr68319.f90
===
--- gcc/testsuite/gfortran.dg/pr68319.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr68319.f90	(working copy)
@@ -0,0 +1,26 @@
+! { dg-do compile }
+! PR fortran/68319
+!
+subroutine foo
+
+   interface
+
+  real function bar(i)
+ f(i) = 2 * i ! { dg-error "cannot appear within" }
+  end function bar
+
+  real function bah(j)
+ entry boo(j) ! { dg-error "cannot appear within" }
+  end function bah
+
+  real function fu(j)
+ data i /1/   ! { dg-error "cannot appear within" }
+  end function fu
+
+  real function fee(j)
+10   format('(A)')! { dg-error "cannot appear within" }
+  end function fee
+
+   end interface
+
+end subroutine foo

Re: [PATCH] PR fortran/67803 -- Check CHARACTER array constructor element types

[Steve Kargl]

On Fri, Nov 13, 2015 at 01:57:13PM -0800, Steve Kargl wrote:
> The attached patch fixes an ICE that occurs in arith.c(gfc_arith_concat)
> because op1 and op2 have incompatible typespecs.  The fix is actually
> implemented in array.c(gfc_match_array_constructor) where the types
> of the elements in a constructor are compared to the typespec that was
> specified in the constructor.  See testcase for examples.  Built
> and regression tested on x86_64-*-freebsd.  OK to commit?
> 
> 2015-11-13  Steven G. Kargl  <ka...@gcc.gnu.org>
> 
>   PR fortran/67803
>   * array.c (gfc_match_array_constructor): If array constructor included
>   a CHARACTER typespec, check array elements for compatible type.
> 
> 2015-11-13  Steven G. Kargl  <ka...@gcc.gnu.org>
>  
>   PR fortran/67803
>   * gfortran.dg/pr67803.f90: New test.
> 

Now with a patch attached.

-- 
Steve
Index: gcc/fortran/array.c
===
--- gcc/fortran/array.c	(revision 230351)
+++ gcc/fortran/array.c	(working copy)
@@ -1162,6 +1162,35 @@ done:
 {
   expr = gfc_get_array_expr (ts.type, ts.kind, );
   expr->ts = ts;
+
+  /* If the typespec is CHARACTER, check that array elements can
+	 be converted.  See PR fortran/67803.  */
+  if (ts.type == BT_CHARACTER)
+	{
+	  gfc_constructor *c;
+
+	  c = gfc_constructor_first (head);
+	  for (; c; c = gfc_constructor_next (c))
+	{
+	  if (gfc_numeric_ts (>expr->ts)
+		  || c->expr->ts.type == BT_LOGICAL)
+		{
+		  gfc_error ("Incompatiable typespec for array element at %L",
+			 >expr->where);
+		  return MATCH_ERROR;
+		}
+
+	  /* Special case null().  */
+	  if (c->expr->expr_type == EXPR_FUNCTION
+		  && c->expr->ts.type == BT_UNKNOWN
+		  && strcmp (c->expr->symtree->name, "null") == 0)
+		{
+		  gfc_error ("Incompatiable typespec for array element at %L",
+			 >expr->where);
+		  return MATCH_ERROR;
+		}
+	}
+	}
 }
   else
 expr = gfc_get_array_expr (BT_UNKNOWN, 0, );
@@ -1171,6 +1200,7 @@ done:
 expr->ts.u.cl->length_from_typespec = seen_ts;
 
   *result = expr;
+
   return MATCH_YES;
 
 syntax:
Index: gcc/testsuite/gfortran.dg/pr67803.f90
===
--- gcc/testsuite/gfortran.dg/pr67803.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr67803.f90	(working copy)
@@ -0,0 +1,14 @@
+! { dg-do compile }
+! PR fortran/67803
+! Original code submitted by Gerhard Steinmetz
+! 
+!
+program p
+  character(2) :: x(1)
+  x = '0' // [character :: 1]   ! { dg-error "Incompatiable typespec for" }
+  x = '0' // [character :: 1.]  ! { dg-error "Incompatiable typespec for" }
+  x = '0' // [character :: 1d1] ! { dg-error "Incompatiable typespec for" }
+  x = '0' // [character :: (0.,1.)] ! { dg-error "Incompatiable typespec for" }
+  x = '0' // [character :: .true.]  ! { dg-error "Incompatiable typespec for" }
+  x = '0' // [character :: null()]  ! { dg-error "Incompatiable typespec for" }
+end

Re: [PATCH] PR fortran/67803 -- Check CHARACTER array constructor element types

[Steve Kargl]

On Fri, Nov 13, 2015 at 01:57:49PM -0800, Steve Kargl wrote:
> 
> Now with a patch attached.
> 
> +   gfc_error ("Incompatiable typespec for array element at %L",

Yes, I know "Incompatiable" is spelled wrong.

-- 
Steve

Re: [PATCH] PR fortran/68319 -- Implement checks for F2008:C1206

[Steve Kargl]

On Fri, Nov 13, 2015 at 08:22:13PM +0100, Paul Richard Thomas wrote:
> 
> I saw the thread on clf. That's a pretty quick turn around!
> 
> OK for trunk.
> 
> Thanks for the patch
> 

Thanks for the review.  It was easy once I found
gfc_state_stack->previous->state would hold COMP_INTERFACE.

-- 
Steve

[PATCH] PR fortran/67803 -- Check CHARACTER array constructor element types

[Steve Kargl]

The attached patch fixes an ICE that occurs in arith.c(gfc_arith_concat)
because op1 and op2 have incompatible typespecs.  The fix is actually
implemented in array.c(gfc_match_array_constructor) where the types
of the elements in a constructor are compared to the typespec that was
specified in the constructor.  See testcase for examples.  Built
and regression tested on x86_64-*-freebsd.  OK to commit?

2015-11-13  Steven G. Kargl  

PR fortran/67803
* array.c (gfc_match_array_constructor): If array constructor included
a CHARACTER typespec, check array elements for compatible type.

2015-11-13  Steven G. Kargl  
 
PR fortran/67803
* gfortran.dg/pr67803.f90: New test.

-- 
Steve

[PATCH,committed] PR fortran/68318 -- increment reference count

[Steve Kargl]

I've committed the attached patch as obvious after
testing on x86_64-*-freebsd.

The short story is that gfortran tracks the number
of ENTRY symbols with a reference count.  If an
ENTRY was included in a routine within a MODULE the
reference count was not properly increment.  This
patch now does the increment.

As a bonus it fixes a nearby comment that is missing
a space, and changes the only occurence of ++sym->refs
to sym->refs++ for consistency.

2015-11-12  Steven G. Kargl  

PR fortran/68318
* decl.c (get_proc_name): Increment reference count for ENTRY.
While here, fix comment and use postfix ++ for consistency.

2015-11-12  Steven G. Kargl  

PR fortran/68318
* gfortran.dg/pr68318_1.f90: New test.
* gfortran.dg/pr68318_2.f90: Ditto.

-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 230064)
+++ gcc/fortran/decl.c	(working copy)
@@ -926,6 +926,7 @@ get_proc_name (const char *name, gfc_sym
 	  gfc_find_sym_tree (name, gfc_current_ns, 0, );
 	  st->n.sym = *result;
 	  st = gfc_get_unique_symtree (gfc_current_ns);
+	  sym->refs++;
 	  st->n.sym = sym;
 	}
 }
@@ -972,7 +973,7 @@ get_proc_name (const char *name, gfc_sym
   /* Trap another encompassed procedure with the same name.  All
 	 these conditions are necessary to avoid picking up an entry
 	 whose name clashes with that of the encompassing procedure;
-	 this is handled using gsymbols to register unique,globally
+	 this is handled using gsymbols to register unique, globally
 	 accessible names.  */
   if (sym->attr.flavor != 0
 	  && sym->attr.proc != 0
@@ -9052,7 +9053,7 @@ gfc_match_final_decl (void)
 
   /* Add this symbol to the list of finalizers.  */
   gcc_assert (block->f2k_derived);
-  ++sym->refs;
+  sym->refs++;
   f = XCNEW (gfc_finalizer);
   f->proc_sym = sym;
   f->proc_tree = NULL;
Index: gcc/testsuite/gfortran.dg/pr68318_1.f90
===
--- gcc/testsuite/gfortran.dg/pr68318_1.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr68318_1.f90	(working copy)
@@ -0,0 +1,18 @@
+! { dg-do compile }
+! { dg-options "-O0"
+! PR fortran/68318
+! Original code submitted by Gerhard Steinmetz
+! 
+!
+module m
+   implicit none
+contains
+   subroutine s1
+   entry e! { dg-error "(2)" }
+   end
+   subroutine s2
+   entry e! { dg-error "is already defined" }
+   end
+end module
+! { dg-prune-output "Duplicate ENTRY attribute specified" }
+
Index: gcc/testsuite/gfortran.dg/pr68318_2.f90
===
--- gcc/testsuite/gfortran.dg/pr68318_2.f90	(nonexistent)
+++ gcc/testsuite/gfortran.dg/pr68318_2.f90	(working copy)
@@ -0,0 +1,22 @@
+! { dg-do compile }
+! PR fortran/68318
+! Original code submitted by Gerhard Steinmetz
+! 
+!
+module m1
+   implicit none
+contains
+   subroutine s1
+   entry e
+   end
+end module
+
+module m2
+   use m1 ! { dg-error "(2)" }
+   implicit none
+contains
+   subroutine s2
+   entry e! { dg-error "is already defined" }
+   end
+end module
+! { dg-prune-output "Cannot change attribute" }

[PATCH] PR fortran/68283 -- remove a rogue gfc_internal_error()

[Steve Kargl]

This probably falls under the "obviously correct" moniker.
It has been built and tested on i386-*-freebsd.  OK to commit?

The patch removes a gfc_internal_error().  I suspect that it
was originally put into gfortran to cover "correctly written
valid Fortran code cannot possibly ever hit this line of 
code; so, it must be an internal error to reach this line".
The code in PR 68283 is not valid Fortran.  A number of error
messages are spewed by gfortran prior to hitting this line of code.
The patch simply removes the gfc_internal_error(), which allows
gfortran to exit gracefully.

2015-11-11  Steven G. Kargl  

PR fortran/68283
* primary.c (gfc_variable_attr): Remove a gfc_internal_error().

-- 
Steve
Index: gcc/fortran/primary.c
===
--- gcc/fortran/primary.c	(revision 229970)
+++ gcc/fortran/primary.c	(working copy)
@@ -2268,8 +2268,6 @@ gfc_variable_attr (gfc_expr *expr, gfc_t
 		&& errors > 0)
 		  break;
 	  }
-	if (n == ref->u.ar.as->rank)
-	  gfc_internal_error ("gfc_variable_attr(): Bad array reference");
 	  }
 
 	break;

Re: [PATCH] PR fortran/68053 -- Reduce initialization expression to constant value

[Steve Kargl]

On Sun, Nov 08, 2015 at 02:35:58PM -0800, Steve Kargl wrote:
> The attached patch has been built and regression tested
> on i386-*-freebsd and x86_64-*-freebsd.  If an array
> index in an initialization expression is an array element
> from an array named constant, the array index needs to be
> reduced.  This patch causes the reduction to occur.
> OK to commit?
> 
> 2015-11-08  Steven g. Kargl  <ka...@gcc.gnu.org>
> 
>   PR fortran/68053
>   * decl.c (add_init_expr_to_sym):  Try to reduce initialization 
> expression
>   before testing for a constant value.
> 
> 2015-11-08  Steven g. Kargl  <ka...@gcc.gnu.org>
> 
>   PR fortran/68053
>   * gfortran.dg/pr68053.f90: New test.

Now with the patch attached!

-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 229970)
+++ gcc/fortran/decl.c	(working copy)
@@ -1529,26 +1529,34 @@ add_init_expr_to_sym (const char *name, 
 	  for (dim = 0; dim < sym->as->rank; ++dim)
 	{
 	  int k;
-	  gfc_expr* lower;
-	  gfc_expr* e;
+	  gfc_expr *e, *lower;
 
 	  lower = sym->as->lower[dim];
-	  if (lower->expr_type != EXPR_CONSTANT)
+
+	  /* If the lower bound is an array element from another 
+		 parameterized array, then it is marked with EXPR_VARIABLE and
+		 is an initialization expression.  Try to reduce it.  */
+	  if (lower->expr_type == EXPR_VARIABLE)
+		gfc_reduce_init_expr (lower);
+
+	  if (lower->expr_type == EXPR_CONSTANT)
+		{
+		  /* All dimensions must be without upper bound.  */
+		  gcc_assert (!sym->as->upper[dim]);
+
+		  k = lower->ts.kind;
+		  e = gfc_get_constant_expr (BT_INTEGER, k, >declared_at);
+		  mpz_add (e->value.integer, lower->value.integer,
+			   init->shape[dim]);
+		  mpz_sub_ui (e->value.integer, e->value.integer, 1);
+		  sym->as->upper[dim] = e;
+		}
+	  else
 		{
 		  gfc_error ("Non-constant lower bound in implied-shape"
 			 " declaration at %L", >where);
 		  return false;
 		}
-
-	  /* All dimensions must be without upper bound.  */
-	  gcc_assert (!sym->as->upper[dim]);
-
-	  k = lower->ts.kind;
-	  e = gfc_get_constant_expr (BT_INTEGER, k, >declared_at);
-	  mpz_add (e->value.integer,
-		   lower->value.integer, init->shape[dim]);
-	  mpz_sub_ui (e->value.integer, e->value.integer, 1);
-	  sym->as->upper[dim] = e;
 	}
 
 	  sym->as->type = AS_EXPLICIT;
Index: gcc/testsuite/gfortran.dg/pr68053.f90
===
--- gcc/testsuite/gfortran.dg/pr68053.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/pr68053.f90	(working copy)
@@ -0,0 +1,10 @@
+! { dg-do run }
+! PR fortran/68053
+! Original code contributed by Gerhard Steinmetz
+! 
+program p
+   integer, parameter :: n(3) = [1,2,3]
+   integer, parameter :: x(1) = 7
+   integer, parameter :: z(n(2):*) = x
+   if (lbound(z,1) /= 2) call abort
+end

[PATCH] PR fortran/68053 -- Reduce initialization expression to constant value

[Steve Kargl]

The attached patch has been built and regression tested
on i386-*-freebsd and x86_64-*-freebsd.  If an array
index in an initialization expression is an array element
from an array named constant, the array index needs to be
reduced.  This patch causes the reduction to occur.
OK to commit?

2015-11-08  Steven g. Kargl  

PR fortran/68053
* decl.c (add_init_expr_to_sym):  Try to reduce initialization 
expression
before testing for a constant value.

2015-11-08  Steven g. Kargl  

PR fortran/68053
* gfortran.dg/pr68053.f90: New test.
-- 
Steve

[PATCH] PR fortran/68244 -- Check for NULL() in an array spec.

[Steve Kargl]

NULL() can only appear in a few situations.  It cannot
be part of an array spec.  See testcase for example.
OK to commit?

2015-11-07  Steven G. Kargl  

PR fortran/68224
* array.c (match_array_element_spec): Check of invalid NULL().
While here, fix nearby comments.

2015-11-07  Steven G. Kargl  

PR fortran/68224
* gfortran.dg/pr68224.f90: New test.

-- 
Steve
Index: gcc/fortran/array.c
===
--- gcc/fortran/array.c	(revision 229933)
+++ gcc/fortran/array.c	(working copy)
@@ -147,9 +147,9 @@ matched:
 }
 
 
-/* Match an array reference, whether it is the whole array or a
-   particular elements or a section. If init is set, the reference has
-   to consist of init expressions.  */
+/* Match an array reference, whether it is the whole array or particular
+   elements or a section.  If init is set, the reference has to consist
+   of init expressions.  */
 
 match
 gfc_match_array_ref (gfc_array_ref *ar, gfc_array_spec *as, int init,
@@ -422,6 +422,13 @@ match_array_element_spec (gfc_array_spec
   if (!gfc_expr_check_typed (*upper, gfc_current_ns, false))
 return AS_UNKNOWN;
 
+  if ((*upper)->expr_type == EXPR_FUNCTION && (*upper)->ts.type == BT_UNKNOWN
+  && (*upper)->symtree && strcmp ((*upper)->symtree->name, "null") == 0)
+{
+  gfc_error ("Expecting a scalar INTEGER expression at %C");
+  return AS_UNKNOWN;
+}
+
   if (gfc_match_char (':') == MATCH_NO)
 {
   *lower = gfc_get_int_expr (gfc_default_integer_kind, NULL, 1);
@@ -442,13 +449,20 @@ match_array_element_spec (gfc_array_spec
   if (!gfc_expr_check_typed (*upper, gfc_current_ns, false))
 return AS_UNKNOWN;
 
+  if ((*upper)->expr_type == EXPR_FUNCTION && (*upper)->ts.type == BT_UNKNOWN
+  && (*upper)->symtree && strcmp ((*upper)->symtree->name, "null") == 0)
+{
+  gfc_error ("Expecting a scalar INTEGER expression at %C");
+  return AS_UNKNOWN;
+}
+
   return AS_EXPLICIT;
 }
 
 
 /* Matches an array specification, incidentally figuring out what sort
-   it is. Match either a normal array specification, or a coarray spec
-   or both. Optionally allow [:] for coarrays.  */
+   it is.  Match either a normal array specification, or a coarray spec
+   or both.  Optionally allow [:] for coarrays.  */
 
 match
 gfc_match_array_spec (gfc_array_spec **asp, bool match_dim, bool match_codim)
Index: gcc/testsuite/gfortran.dg/pr68224.f90
===
--- gcc/testsuite/gfortran.dg/pr68224.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/pr68224.f90	(working copy)
@@ -0,0 +1,10 @@
+! { dg-do compile }
+! PR fortran/68224
+! Original code contribute by Gerhard Steinmetz
+! 
+! 
+program p
+   integer, parameter :: a(null()) = [1, 2]   ! { dg-error "scalar INTEGER expression" }
+   integer, parameter :: b(null():*) = [1, 2]   ! { dg-error "scalar INTEGER expression" }
+   integer, parameter :: c(1:null()) = [1, 2]   ! { dg-error "scalar INTEGER expression" }
+end program p

Re: [Patch, fortran] PR68196 [4.9/5/6 Regression] ICE on function result with procedure pointer component

[Steve Kargl]

On Wed, Nov 04, 2015 at 04:03:10PM +0100, Paul Richard Thomas wrote:
> 
> 2015-11-04  Paul Thomas  
> 
> PR fortran/68196
> * class.c (has_finalizer_component): Prevent infinite recursion
> through this function if the derived type and that of its
> component are the same.
> * trans-types.c (gfc_get_derived_type): Do the same for proc
> pointers by ignoring the explicit interface for the component.
> 
> PR fortran/66465
> * check.c (same_type_check): If either of the expressions is
> BT_PROCEDURE, use the typespec from the symbol, rather than the
> expression.
> 
> 2015-11-04  Paul Thomas  
> 
> PR fortran/68196
> * gfortran.dg/proc_ptr_47.f90: New test.
> 
> PR fortran/66465
> * gfortran.dg/pr66465.f90: New test.

OK.  Thanks for the patch.

-- 
steve

Re: [PATCH] PR fortran/68151 -- Check CASE selector for valid type

[Steve Kargl]

On Mon, Nov 02, 2015 at 12:33:25PM +0100, Mikael Morin wrote:
> 
> Le 01/11/2015 22:16, Steve Kargl a écrit :
> > The attach patch add checking for a valid type during
> > matching of a CASE selector.  Built and regression
> > tested on i386-*-freebsd.  OK to commit?
> 
> [...]
> 
> > Index: gcc/fortran/match.c
> > ===
> > --- gcc/fortran/match.c (revision 229634)
> > +++ gcc/fortran/match.c (working copy)
> > @@ -5036,6 +5036,15 @@ match_case_selector (gfc_case **cp)
> > goto need_expr;
> >if (m == MATCH_ERROR)
> > goto cleanup;
> > +
> > +  /* F08:C830 case-expr shall be of type character, integer, or 
> > logical.  */
> case-expr is the expression appearing in a SELECT CASE statement (k in 
> the test), while here the problem is in a CASE statement, dealing with 
> value-expr's.
> So I think C830 doesn't apply here.  But you can rely on F08:C832 saying:
>"For a given case-construct, each case-value shall be of the same 
> type as case-expr"
> The type of case-expr is only checked in resolve_select, so the check 
> for the value-expr's should probably happen there as well.
> 

Thanks for the correction.  I'll update the comment
and check to see if F08:C832 is enforced

-- 
Steve

[PATCH] Pr fortran/68153 -- Enhance checking of RESHAPE shape arg

[Steve Kargl]

The attached patch enhances the check of the shape argument
when it is a named constant.  See the testcase for example.
Built and regression tested on i386-*-freebsd.  OK to commit?

2015-11-01  Steven G. Kargl  

PR fortran/68153
* check.c (gfc_check_reshape): Improve check for valid SHAPE argument.

2015-11-01  Steven G. Kargl  

PR fortran/68153
* gfortran.dg/pr68153.f90: New test.

-- 
Steve
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c	(revision 229634)
+++ gcc/fortran/check.c	(working copy)
@@ -3711,6 +3711,36 @@ gfc_check_reshape (gfc_expr *source, gfc
 	}
 	}
 }
+  else if (shape->expr_type == EXPR_VARIABLE && shape->ref
+	   && shape->ref->u.ar.type == AR_FULL && shape->ref->u.ar.dimen == 1
+	   && shape->ref->u.ar.as
+	   && shape->ref->u.ar.as->lower[0]->expr_type == EXPR_CONSTANT
+	   && shape->ref->u.ar.as->lower[0]->ts.type == BT_INTEGER
+	   && shape->ref->u.ar.as->upper[0]->expr_type == EXPR_CONSTANT
+	   && shape->ref->u.ar.as->upper[0]->ts.type == BT_INTEGER
+	   && shape->symtree->n.sym->attr.flavor == FL_PARAMETER)
+{
+  int i, dim;
+  gfc_expr *e, *v;
+
+  v = shape->symtree->n.sym->value;
+
+  for (i = 0; i < shape_size; i++)
+	{
+	  e = gfc_constructor_lookup_expr (v->value.constructor, i);
+	  if (e == NULL)
+	 break;
+
+	  gfc_extract_int (e, );
+
+	  if (dim < 0)
+	{
+	  gfc_error ("Element %d of actual argument of RESHAPE at %L "
+			 "cannot be negative", i + 1, >where);
+	  return false;
+	}
+	}
+}
 
   if (pad != NULL)
 {
Index: gcc/testsuite/gfortran.dg/pr68153.f90
===
--- gcc/testsuite/gfortran.dg/pr68153.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/pr68153.f90	(working copy)
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! PR fortran/68153
+! Original code contribute by Gerhard Steinmetz
+! 
+!
+program foo
+   integer, parameter :: a(2) = [2, -2]
+   integer, parameter :: b(2,2) = reshape([1, 2, 3, 4], a) ! { dg-error "cannot be negative" }
+end program foo

[PATCH] PR fortran/68151 -- Check CASE selector for valid type

[Steve Kargl]

The attach patch add checking for a valid type during
matching of a CASE selector.  Built and regression
tested on i386-*-freebsd.  OK to commit?

2015-11-01  Steven G. Kargl  

PR fortran/68151
* match.c (match_case_selector):  Check for invalid type.

2015-11-01  Steven G. Kargl  

PR fortran/68151
* gfortran.dg/pr68151.f90: New test.

-- 
Steve
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c	(revision 229634)
+++ gcc/fortran/match.c	(working copy)
@@ -5036,6 +5036,15 @@ match_case_selector (gfc_case **cp)
 	goto need_expr;
   if (m == MATCH_ERROR)
 	goto cleanup;
+
+  /* F08:C830 case-expr shall be of type character, integer, or logical.  */
+  if (c->high->ts.type != BT_LOGICAL && c->high->ts.type != BT_INTEGER
+	  && c->high->ts.type != BT_CHARACTER)
+	{
+	  gfc_error ("Expression in CASE at %L cannot be %s",
+		 >high->where, gfc_typename (>high->ts));
+	  goto cleanup;
+	}
 }
   else
 {
@@ -5045,6 +5054,15 @@ match_case_selector (gfc_case **cp)
   if (m == MATCH_NO)
 	goto need_expr;
 
+  /* F08:C830 case-expr shall be of type character, integer, or logical.  */
+  if (c->low->ts.type != BT_LOGICAL && c->low->ts.type != BT_INTEGER
+	  && c->low->ts.type != BT_CHARACTER)
+	{
+	  gfc_error ("Expression in CASE at %L cannot be %s",
+		 >low->where, gfc_typename (>low->ts));
+	  goto cleanup;
+	}
+
   /* If we're not looking at a ':' now, make a range out of a single
 	 target.  Else get the upper bound for the case range.  */
   if (gfc_match_char (':') != MATCH_YES)
Index: gcc/testsuite/gfortran.dg/pr68151.f90
===
--- gcc/testsuite/gfortran.dg/pr68151.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/pr68151.f90	(working copy)
@@ -0,0 +1,13 @@
+! { dg-do compile }
+! PR fortran/68151
+! Original code contribute by Gerhard Steinmetz
+! 
+!
+program p
+   integer :: k = 1
+   select case (k)
+   case (:huge(1._4))   ! { dg-error "Expression in CASE" }
+   case (:huge(2._8))   ! { dg-error "Expression in CASE" }
+   case ((1.0,2.0)) ! { dg-error "Expression in CASE" }
+   end select
+end

[PATCH,committed] PR fortran/46588 -- add testcase

[Steve Kargl]

I've committed a testcase for PR fortran/46588 to trunk.
The patches for PR 67805 and 68108 fixed this 46588,
but the testcase goes through a differenti compiler path.
 
2015-10-30  Steven G. Kargl  

PR fortran/46588
* gfortran.dg/pr46588.f90: New test.

Index: gcc/testsuite/gfortran.dg/pr46588.f90
===
--- gcc/testsuite/gfortran.dg/pr46588.f90   (revision 0)
+++ gcc/testsuite/gfortran.dg/pr46588.f90   (working copy)
@@ -0,0 +1,21 @@
+! { dg-do run }
+! { dg-options "-std=gnu" }
+! PR fortran/46588
+! Original code contributed by Oleh Steblev 
+!
+! Issue appears to be fixed by PR 67805/68108
+function aufun(pm)
+   character(len = *) pm
+   character(len = *) aufun
+   character(len = len(aufun)) temp 
+   temp = pm 
+   aufun = 'Oh' // trim(temp)
+end function aufun
+
+program ds
+   implicit none
+   character(len = 4) :: ins = ' no!'
+   character(len = 20) st, aufun 
+   st = aufun(ins)
+   if (trim(st) /= 'Oh no!') call abort
+end
-- 
Steve

[PATCH,committed] PR fortran/51993 -- Convert assert() to if-statement

[Steve Kargl]

I've committed the attached patch as obvious.  It
converts a gcc_assert() into an if-statement, which
then allows gfortran to issue a sensible error
message.

2015-10-15  Steven G. Kargl  

PR fortran/51993
* decl.c (gfc_set_constant_character_len): Convert gcc_assert into an
if-statement causing an early return leads to valid error message.

2015-10-15  Steven G. Kargl  

PR fortran/51993
* gfortran.dg/pr51993.f90: New test.

-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 229593)
+++ gcc/fortran/decl.c	(working copy)
@@ -1293,7 +1293,9 @@ gfc_set_constant_character_len (int len,
   int slen;
 
   gcc_assert (expr->expr_type == EXPR_CONSTANT);
-  gcc_assert (expr->ts.type == BT_CHARACTER);
+
+  if (expr->ts.type != BT_CHARACTER)
+return;
 
   slen = expr->value.character.length;
   if (len != slen)
Index: gcc/testsuite/gfortran.dg/pr51993.f90
===
--- gcc/testsuite/gfortran.dg/pr51993.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/pr51993.f90	(working copy)
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! PR fortran/51993
+! Code contributed by Sebastien Bardeau 
+module mymod
+  type :: mytyp
+character(len=3) :: a = .true. ! { dg-error "convert LOGICAL" }
+  end type mytyp
+end module mymod

[PATCH] PR fortran/36192 -- yet another fix for an ICE

[Steve Kargl]

The patch for PR fortran/36192 that I committed here:

https://gcc.gnu.org/ml/gcc-bugs/2015-10/msg02160.html

cured an ICE for a testcase that was reduced from the
originally submitted mutilated Fortran code.  The 
original code could in fact invoke another ICE.  This
patch cures that ICE.  The patch simply checks that
the array indices have INTEGER type before calling
GMP routines.  Tested om x86_64-*-freebsd.
OK to commit?

2015-10-29  Steven G. Kargl  

PR fortran/36192
* interface.c (get_expr_storage_size):  Check for INTEGER type before
calling gmp routines.

2015-10-29  Steven G. Kargl  

PR fortran/36192
* gfortran.dg/pr36192_1.f90: New test.

-- 
Steve
Index: gcc/fortran/interface.c
===
--- gcc/fortran/interface.c	(revision 229542)
+++ gcc/fortran/interface.c	(working copy)
@@ -2455,7 +2455,9 @@ get_expr_storage_size (gfc_expr *e)
 	  {
 	if (ref->u.ar.as->lower[i] && ref->u.ar.as->upper[i]
 		&& ref->u.ar.as->lower[i]->expr_type == EXPR_CONSTANT
-		&& ref->u.ar.as->upper[i]->expr_type == EXPR_CONSTANT)
+		&& ref->u.ar.as->lower[i]->ts.type == BT_INTEGER
+		&& ref->u.ar.as->upper[i]->expr_type == EXPR_CONSTANT
+		&& ref->u.ar.as->upper[i]->ts.type == BT_INTEGER)
 	  elements *= mpz_get_si (ref->u.ar.as->upper[i]->value.integer)
 			  - mpz_get_si (ref->u.ar.as->lower[i]->value.integer)
 			  + 1L;
Index: gcc/testsuite/gfortran.dg/pr36192_1.f90
===
--- gcc/testsuite/gfortran.dg/pr36192_1.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/pr36192_1.f90	(working copy)
@@ -0,0 +1,12 @@
+! { dg-do compile }
+! PR fortran/36192
+program three_body
+   real, parameter ::  n = 2, d = 2
+   real, dimension(n,d) :: x_hq ! { dg-error "of INTEGER type|of INTEGER type" }
+   call step(x_hq)
+   contains
+   subroutine step(x)
+  real, dimension(:,:), intent(in) :: x
+   end subroutine step
+end program three_body
+! { dg-prune-output "must have constant shape" }

[PATCH] PR fortran/68154 -- repair damage done byfix for PR fortran/65429

[Steve Kargl]

The attached patch restores 3 lines of code removed in my
fix for PR fortran/65429.  The code now checks for a NULL
character length in the typespec.  If it is indeed NULL,
gfortran will look for a valid constructor to use (ie.,
the 3 lines of code).  It is somewhat surprising that
it took 6 months for this bug to appear.  Patch tested
on x86_64-*-freebsd.  OK to commit?

2015-10-29  Steven G. Kargl  

PR fortran/68154
* decl.c (add_init_expr_to_sym): if the char length in the typespec
is NULL, check for and use the constructor. 

2015-10-29  Steven G. Kargl  

PR fortran/68154
*gfortran.dg/pr68154.f90

-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 229542)
+++ gcc/fortran/decl.c	(working copy)
@@ -1461,7 +1461,16 @@ add_init_expr_to_sym (const char *name, 
 		}
 		  else if (init->expr_type == EXPR_ARRAY)
 		{
-		  clen = mpz_get_si (init->ts.u.cl->length->value.integer);
+		  if (init->ts.u.cl)
+			clen = mpz_get_si (init->ts.u.cl->length->value.integer);
+		  else if (init->value.constructor)
+			{
+			  gfc_constructor *c;
+	  c = gfc_constructor_first (init->value.constructor); 	 
+	  clen = c->expr->value.character.length;
+			}
+		  else
+			  clen = 1;
 		  sym->ts.u.cl->length
 = gfc_get_int_expr (gfc_default_integer_kind,
 		NULL, clen);
Index: gcc/testsuite/gfortran.dg/pr68154.f90
===
--- gcc/testsuite/gfortran.dg/pr68154.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/pr68154.f90	(working copy)
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! PR fortran/68154
+! Original code contributed by Gerhard Steinmetz
+! gerhard dot steinmetz dot fortran at t-online dot de
+program p
+   character(1), parameter :: x1(2) = 'a'
+   character(*), parameter :: x2(2) = x1
+   character(*), parameter :: x3(*) = x1
+end

[PATCH, committed] PR fortran/68108 -- Check for valid array ref.

[Steve Kargl]

I've committed the attached patch after testing on
x86_64-*-freebsd.  A regression was introduced by 
my fix for PR fortran/67805, which failed to check
for a valid array ref.  Note, Mikael approved the 
patch in the PR audit trail.

2015-10-27  Steven G. Kargl  

PR fortran/68108
* decl.c (char_len_param_value): Check for REF_ARRAY.
 
2015-10-27  Steven G. Kargl  

PR fortran/68108
* gfortran.dg/pr67805_2.f90: New test.

-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 229445)
+++ gcc/fortran/decl.c	(working copy)
@@ -748,13 +748,15 @@ char_len_param_value (gfc_expr **expr, b
 
   /* This catches the invalid code "[character(m(2:3)) :: 'x', 'y']",
 	 which causes an ICE if gfc_reduce_init_expr() is called.  */
-  if (e->ref && e->ref->u.ar.type == AR_UNKNOWN
+  if (e->ref && e->ref->type == REF_ARRAY
+	  && e->ref->u.ar.type == AR_UNKNOWN
 	  && e->ref->u.ar.dimen_type[0] == DIMEN_RANGE)
 	goto syntax;
 
   gfc_reduce_init_expr (e);
 
-  if ((e->ref && e->ref->u.ar.type != AR_ELEMENT) 
+  if ((e->ref && e->ref->type == REF_ARRAY
+	   && e->ref->u.ar.type != AR_ELEMENT) 
 	  || (!e->ref && e->expr_type == EXPR_ARRAY))
 	{
 	  gfc_free_expr (e);
Index: gcc/testsuite/gfortran.dg/pr67805_2.f90
===
--- gcc/testsuite/gfortran.dg/pr67805_2.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/pr67805_2.f90	(working copy)
@@ -0,0 +1,22 @@
+! { dg-do compile }
+! PR fortran/68108
+! Code contributed by Juergen Reuter (juergen.reuter at desy dot de)
+! Test fix for regression caused by PR fortran/67805.
+module lexers
+  implicit none
+  type :: template_t
+ character(256) :: charset1
+ integer :: len1
+  end type template_t
+
+contains
+
+  subroutine match_quoted (tt, s, n)
+type(template_t), intent(in) :: tt
+character(*), intent(in) :: s
+integer, intent(out) :: n
+character(tt%len1) :: ch1
+ch1 = tt%charset1
+  end subroutine match_quoted
+
+end module lexers

[PATCH] PR fortran/67885 -- PARAMETER needs to be marked in BLOCK

[Steve Kargl]

When an specification statement in a BLOCK construct has a
PARAMETER attribute, gfortran currently discards the entity.
This patch marks PARAMETER entity if in a BLOCK.  I'm not
complete convince that this is the right fix, but it does
allow the testcase to compile and run.  Built and tested
on x86_64-*-freebsd.  OK to commit (if not no one has a
better patch)?

2015-10-26  Steven G. Kargl  

PR fortran/67885
* trans-decl.c (generate_local_decl): Mark PARAMETER entities in
BLOCK construct.

2015-10-26  Steven G. Kargl  

PR fortran/67885
* gfortran.dg/pr67885.f90: New test.

-- 
Steve
Index: gcc/fortran/trans-decl.c
===
--- gcc/fortran/trans-decl.c	(revision 229390)
+++ gcc/fortran/trans-decl.c	(working copy)
@@ -5217,6 +5217,16 @@ generate_local_decl (gfc_symbol * sym)
 			  "Unused parameter %qs which has been explicitly "
 			  "imported at %L", sym->name, >declared_at);
 	}
+
+  if (sym->ns
+	  && sym->ns->parent
+	  && sym->ns->parent->code
+	  && sym->ns->parent->code->op == EXEC_BLOCK)
+	{
+	  if (sym->attr.referenced)
+	gfc_get_symbol_decl (sym);
+	  sym->mark = 1;
+	}
 }
   else if (sym->attr.flavor == FL_PROCEDURE)
 {
Index: gcc/testsuite/gfortran.dg/pr67885.f90
===
--- gcc/testsuite/gfortran.dg/pr67885.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/pr67885.f90	(working copy)
@@ -0,0 +1,12 @@
+! { dg-do run }
+! PR fortran/67885
+! Original code contributed by Gerhard Steinmetz
+! gerhard dot steinmetz dot fortran at t-online dot de
+program p
+   block
+  integer, parameter :: a(2) = [1, 2]
+  integer :: x(2)
+  x = a
+  if (x(1) /= 1) call abort
+   end block
+end

Re: [PATCH] PR fortran/36192 -- Check for valid BT_INTEGER

[Steve Kargl]

On Mon, Oct 26, 2015 at 09:49:10AM +0100, FX wrote:
> > 2015-10-25  Steven G. Kargl  
> > 
> > PR fortran/36192
> > * array.c (gfc_ref_dimen_size): Check for BT_INTEGER before calling
> > mpz_set.
> > 
> > 
> > 2015-10-25  Steven G. Kargl  
> > 
> > PR fortran/36192
> > * gfortran.dg/pr36192.f90: New test.
> 
> OK. But I don???t understand why the testcase???s dg-error pattern has this 
> form: a regex ???or??? (|) of two identical strings?
> 

Because the code issues two errors, one for each dimension.
I thought testing for the third (which I prune) to be
excessive.

laptop-kargl:kargl[202] gfc -c pr36192.f90
pr36192.f90:6:18:

   real, dimension(n,d) :: x ! { dg-error "of INTEGER type|of INTEGER type" }
  1
Error: Expression at (1) must be of INTEGER type, found REAL
pr36192.f90:6:20:

   real, dimension(n,d) :: x ! { dg-error "of INTEGER type|of INTEGER type" }
1
Error: Expression at (1) must be of INTEGER type, found REAL
pr36192.f90:6:27:

   real, dimension(n,d) :: x ! { dg-error "of INTEGER type|of INTEGER type" }
   1
Error: The module or main program array 'x' at (1) must have constant shape

-- 
Steve

Re: [PATCH] PR fortran/36192 -- Check for valid BT_INTEGER

[Steve Kargl]

On Mon, Oct 26, 2015 at 03:43:37PM +0100, FX wrote:
> > Because the code issues two errors, one for each dimension.
> 
> Then shouldn???t it be ???string.*string??? to match
> two occurences of the string, with some stuff (incl. newline) in the middle?
> 

I don't know dejagnu well enough to know if some other regex pattern
would capture all 3 errors.  I'm simply using the advice given on
the wiki: https://gcc.gnu.org/wiki/TestCaseWriting
If you have a better pattern, I'm more than willing to change the
testcase.

The point of the testcase isn't to see if 3 errors messages or even
1 error message is issued.  The testcase demonstrates that the segfault
in F951 (caused by calling mpz_set with an invalid mpz_t) does not happen.

-- 
Steve

[PATCH] PR fortran/36192 -- Check for valid BT_INTEGER

[Steve Kargl]

The attached patch fixes a segfault in f951 for some poorly
written invalid code.  See the testcase for the code in
question.  Built and tested on i386-*-freebsd.  Ok to commit?

2015-10-25  Steven G. Kargl  

PR fortran/36192
* array.c (gfc_ref_dimen_size): Check for BT_INTEGER before calling
mpz_set.


2015-10-25  Steven G. Kargl  

PR fortran/36192
* gfortran.dg/pr36192.f90: New test.

-- 
Steve
Index: gcc/fortran/array.c
===
--- gcc/fortran/array.c	(revision 229301)
+++ gcc/fortran/array.c	(working copy)
@@ -2208,7 +2208,8 @@ gfc_ref_dimen_size (gfc_array_ref *ar, i
   if (ar->start[dimen] == NULL)
 	{
 	  if (ar->as->lower[dimen] == NULL
-	  || ar->as->lower[dimen]->expr_type != EXPR_CONSTANT)
+	  || ar->as->lower[dimen]->expr_type != EXPR_CONSTANT
+	  || ar->as->lower[dimen]->ts.type != BT_INTEGER)
 	goto cleanup;
 	  mpz_set (lower, ar->as->lower[dimen]->value.integer);
 	}
@@ -,7 +2223,8 @@ gfc_ref_dimen_size (gfc_array_ref *ar, i
   if (ar->end[dimen] == NULL)
 	{
 	  if (ar->as->upper[dimen] == NULL
-	  || ar->as->upper[dimen]->expr_type != EXPR_CONSTANT)
+	  || ar->as->upper[dimen]->expr_type != EXPR_CONSTANT
+	  || ar->as->upper[dimen]->ts.type != BT_INTEGER)
 	goto cleanup;
 	  mpz_set (upper, ar->as->upper[dimen]->value.integer);
 	}
Index: gcc/testsuite/gfortran.dg/pr36192.f90
===
--- gcc/testsuite/gfortran.dg/pr36192.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/pr36192.f90	(working copy)
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! PR fortran/36192.f90
+!
+program three_body
+  real, parameter :: n = 2, d = 2
+  real, dimension(n,d) :: x  ! { dg-error "of INTEGER type|of INTEGER type" }
+  x(1,:) = (/ 1.0, 0.0 /)
+end program three_body
+! { dg-prune-output "have constant shape" }

[PATCH] PR fortran/68054 -- PROTECTED in modules only

[Steve Kargl]

The attached patch fixes an ICE that occurs when gfortran 
is not expecting a PROTECTED attribute.  Built and tested
on x86_64-*-freebsd.  OK to commit?


2015-10-24  Steven G. Kargl  

PR fortran/68054
* decl.c (match_attr_spec): PROTECTED can only be a module.

2015-10-24  Steven G. Kargl  

PR fortran/68054
* gfortran.dg/pr68054.f90: New test.

-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 229288)
+++ gcc/fortran/decl.c	(working copy)
@@ -3957,7 +3957,9 @@ match_attr_spec (void)
 	  break;
 
 	case DECL_PROTECTED:
-	  if (gfc_current_ns->proc_name->attr.flavor != FL_MODULE)
+	  if (gfc_current_state () != COMP_MODULE
+	  || (gfc_current_ns->proc_name
+		  && gfc_current_ns->proc_name->attr.flavor != FL_MODULE))
 	{
 	   gfc_error ("PROTECTED at %C only allowed in specification "
 			  "part of a module");
Index: gcc/testsuite/gfortran.dg/pr68054.f90
===
--- gcc/testsuite/gfortran.dg/pr68054.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/pr68054.f90	(working copy)
@@ -0,0 +1,8 @@
+! { dg-do compile }
+! PR fortran/68054
+! Original code contributed by Gerhard Steinmetz
+! gerhard dot steinmetz dot fortran at t-online dot de
+!
+!program p
+   real, protected :: x   ! { dg-error "only allowed in specification" }
+end

[PATCH] PR fortran/67805 -- Check for invalid charlength

[Steve Kargl]

All,

The attached patch fixes several ICEs caused by invalid
charlengths.  The new testcase pr67805.f90 shows the 
kinds of issues the patch will detect.  An appropriate
error message is now issued.

Built and regression tested on x86_64-*-freebsd.
OK to commit?

2015-10-23  Steven G. Kargl  

PR fortran/67805
* array.c (gfc_match_array_constructor): Check for error from type
spec matching.
* decl.c (char_len_param_value): Check for valid of charlen parameter.
Reap dead code dating to 2008.
match.c (gfc_match_type_spec): Special case the keyword use in REAL.

2015-10-23  Steven G. Kargl  

PR fortran/67805
* gfortran.dg/pr67805.f90: New testcase.
* gfortran.dg/array_constructor_26.f03: Update testcase.
* gfortran.dg/array_constructor_27.f03: Ditto.
* gfortran.dg/char_type_len_2.f90: Ditto.
* gfortran.dg/pr67802.f90: Ditto.
* gfortran.dg/used_before_typed_3.f90: Ditto.

-- 
Steve

Re: [PATCH] PR fortran/67805 -- Check for invalid charlength

[Steve Kargl]

On Fri, Oct 23, 2015 at 12:28:14PM -0700, Steve Kargl wrote:
> Built and regression tested on x86_64-*-freebsd.
> OK to commit?
> 

Now with the patch attached!

-- 
Steve
Index: gcc/fortran/array.c
===
--- gcc/fortran/array.c	(revision 229265)
+++ gcc/fortran/array.c	(working copy)
@@ -1080,7 +1080,8 @@ gfc_match_array_constructor (gfc_expr **
   /* Try to match an optional "type-spec ::"  */
   gfc_clear_ts ();
   gfc_new_undo_checkpoint (changed_syms);
-  if (gfc_match_type_spec () == MATCH_YES)
+  m = gfc_match_type_spec ();
+  if (m == MATCH_YES)
 {
   seen_ts = (gfc_match (" ::") == MATCH_YES);
 
@@ -1102,6 +1103,11 @@ gfc_match_array_constructor (gfc_expr **
 	}
 	}
 }
+  else if (m == MATCH_ERROR)
+{
+  gfc_restore_last_undo_checkpoint ();
+  goto cleanup;
+}
 
   if (seen_ts)
 gfc_drop_last_undo_checkpoint ();
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 229265)
+++ gcc/fortran/decl.c	(working copy)
@@ -715,36 +715,59 @@ char_len_param_value (gfc_expr **expr, b
 
   if ((*expr)->expr_type == EXPR_FUNCTION)
 {
-  if ((*expr)->value.function.actual
-	  && (*expr)->value.function.actual->expr->symtree)
+  if ((*expr)->ts.type == BT_INTEGER
+	  || ((*expr)->ts.type == BT_UNKNOWN
+	  && strcmp((*expr)->symtree->name, "null") != 0))
+	return MATCH_YES;
+
+  goto syntax;
+}
+  else if ((*expr)->expr_type == EXPR_CONSTANT)
+{
+  /* F2008, 4.4.3.1:  The length is a type parameter; its kind is
+	 processor dependent and its value is greater than or equal to zero.
+	 F2008, 4.4.3.2:  If the character length parameter value evaluates
+	 to a negative value, the length of character entities declared
+	 is zero.  */
+
+  if ((*expr)->ts.type == BT_INTEGER)
 	{
-	  gfc_expr *e;
-	  e = (*expr)->value.function.actual->expr;
-	  if (e->symtree->n.sym->attr.flavor == FL_PROCEDURE
-	  && e->expr_type == EXPR_VARIABLE)
-	{
-	  if (e->symtree->n.sym->ts.type == BT_UNKNOWN)
-		goto syntax;
-	  if (e->symtree->n.sym->ts.type == BT_CHARACTER
-		  && e->symtree->n.sym->ts.u.cl
-		  && e->symtree->n.sym->ts.u.cl->length->ts.type == BT_UNKNOWN)
-	goto syntax;
-	}
+	  if (mpz_cmp_si ((*expr)->value.integer, 0) < 0)
+	mpz_set_si ((*expr)->value.integer, 0);
 	}
+  else
+	goto syntax;
 }
+  else if ((*expr)->expr_type == EXPR_ARRAY)
+goto syntax;
+  else if ((*expr)->expr_type == EXPR_VARIABLE)
+{
+  gfc_expr *e;
+
+  e = gfc_copy_expr (*expr);
+
+  /* This catches the invalid code "[character(m(2:3)) :: 'x', 'y']",
+	 which causes an ICE if gfc_reduce_init_expr() is called.  */
+  if (e->ref && e->ref->u.ar.type == AR_UNKNOWN
+	  && e->ref->u.ar.dimen_type[0] == DIMEN_RANGE)
+	goto syntax;
+
+  gfc_reduce_init_expr (e);
+
+  if ((e->ref && e->ref->u.ar.type != AR_ELEMENT) 
+	  || (!e->ref && e->expr_type == EXPR_ARRAY))
+	{
+	  gfc_free_expr (e);
+	  goto syntax;
+	}
 
-  /* F2008, 4.4.3.1:  The length is a type parameter; its kind is processor
- dependent and its value is greater than or equal to zero.
- F2008, 4.4.3.2:  If the character length parameter value evaluates to
- a negative value, the length of character entities declared is zero.  */
-  if ((*expr)->expr_type == EXPR_CONSTANT
-  && mpz_cmp_si ((*expr)->value.integer, 0) < 0)
-mpz_set_si ((*expr)->value.integer, 0);
+  gfc_free_expr (e);
+}
 
   return m;
 
 syntax:
-  gfc_error ("Conflict in attributes of function argument at %C");
+  gfc_error ("Scalar INTEGER expression expected at %L", &(*expr)->where);
   return MATCH_ERROR;
 }
 
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c	(revision 229265)
+++ gcc/fortran/match.c	(working copy)
@@ -1939,6 +1939,11 @@ kind_selector:
   if (m == MATCH_NO)
 m = MATCH_YES;		/* No kind specifier found.  */
 
+  /* gfortran may have matched REAL(a=1), which is the keyword form of the
+ intrinsic procedure.  */
+  if (ts->type == BT_REAL && m == MATCH_ERROR)
+m = MATCH_NO;
+
   return m;
 }
 
Index: gcc/testsuite/gfortran.dg/array_constructor_26.f03
===
--- gcc/testsuite/gfortran.dg/array_constructor_26.f03	(revision 229265)
+++ gcc/testsuite/gfortran.dg/array_constructor_26.f03	(working copy)
@@ -11,7 +11,6 @@ MODULE WinData
   integer :: i
   TYPE TWindowData
 CHARACTER (MAX_FLD_HED, 1) :: DWFdHd(MAXFLD) = [(" ", i = 1, MAXFLD)]
-   

[PATCH] PR fortran/68055 -- Check for valid kind in old-style declaration

[Steve Kargl]

The attached patch has been built and tested on x86_64-*-freebsd.
It implements a check for validate kinds in type declarations
of the form REAL*42.

OK to commit?

2015-10-23  Steven G. Kargl  

PR fortran/68055
* decl.c (gfc_match_decl_type_spec): Check for valid kind in old-style
declarations.

2015-10-23  Steven G. Kargl  

PR fortran/68055
* gfortran.dg/pr68055.f90: New case.
-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 229265)
+++ gcc/fortran/decl.c	(working copy) 
@@ -2998,7 +3021,11 @@ get_kind:
 
   m = gfc_match_kind_spec (ts, false);
   if (m == MATCH_NO && ts->type != BT_CHARACTER)
-m = gfc_match_old_kind_spec (ts);
+{
+  m = gfc_match_old_kind_spec (ts);
+  if (gfc_validate_kind (ts->type, ts->kind, true) == -1)
+ return MATCH_ERROR;
+}
 
   if (matched_type && gfc_match_char (')') != MATCH_YES)
 return MATCH_ERROR;
Index: gcc/testsuite/gfortran.dg/pr68055.f90
===
--- gcc/testsuite/gfortran.dg/pr68055.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/pr68055.f90	(working copy)
@@ -0,0 +1,13 @@
+! { dg-do compile }
+! PR fortran/68055
+! Original code contributed by Gerhard Steinmetz
+! gerhard dot steinmetz dot fortran at t-online dot de
+! 
+   integer*3 c! { dg-error "not supported at" }
+   real*9 x   ! { dg-error "not supported at" }
+   logical*11 a   ! { dg-error "not supported at" }
+   complex*42 z   ! { dg-error "not supported at" }
+   c = 1
+   x = 1
+   call foo(a)
+end

[PATCH] PR fortran/67939 -- Fix zero length strings in DATA statement

[Steve Kargl]

The attach patch properly sets the length for a zero length string
in a data.  Built and regression tested on x86_64-*-freebsd.  The
testcase is self-explanatory.

OK to commit?


2015-10-21  Steven G. Kargl  

PR fortran/67939
* data.c (create_character_initializer): Deal with zero length string.

2015-10-21  Steven G. Kargl  

PR fortran/67939
* gfortran.dg/pr67939.f90: New test.

-- 
Steve
Index: gcc/fortran/data.c
===
--- gcc/fortran/data.c	(revision 229138)
+++ gcc/fortran/data.c	(working copy)
@@ -104,7 +104,7 @@ static gfc_expr *
 create_character_initializer (gfc_expr *init, gfc_typespec *ts,
 			  gfc_ref *ref, gfc_expr *rvalue)
 {
-  int len, start, end;
+  int len, start, end, tlen;
   gfc_char_t *dest;
   bool alloced_init = false;
 	
@@ -162,12 +162,22 @@ create_character_initializer (gfc_expr *
   else
 len = rvalue->value.character.length;
 
-  if (len > end - start)
+  tlen = end - start;
+  if (len > tlen)
 {
-  gfc_warning_now (0, "Initialization string starting at %L was "
-		   "truncated to fit the variable (%d/%d)",
-		   >where, end - start, len);
-  len = end - start;
+  if (tlen < 0)
+	{
+	  gfc_warning_now (0, "Unused initialization string at %L because "
+			   "variable has zero length", >where);
+	  len = 0;
+	}
+  else
+	{
+	  gfc_warning_now (0, "Initialization string at %L was truncated to "
+			   "fit the variable (%d/%d)", >where,
+			   tlen, len);
+	  len = tlen;
+	}
 }
 
   if (rvalue->ts.type == BT_HOLLERITH)
@@ -181,7 +191,7 @@ create_character_initializer (gfc_expr *
 	len * sizeof (gfc_char_t));
 
   /* Pad with spaces.  Substrings will already be blanked.  */
-  if (len < end - start && ref == NULL)
+  if (len < tlen && ref == NULL)
 gfc_wide_memset ([start + len], ' ', end - (start + len));
 
   if (rvalue->ts.type == BT_HOLLERITH)
Index: gcc/testsuite/gfortran.dg/pr67939.f90
===
--- gcc/testsuite/gfortran.dg/pr67939.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/pr67939.f90	(working copy)
@@ -0,0 +1,21 @@
+! { dg-do compile }
+! PR fortran/67939
+! Original code by Gerhard Steinmetz
+! gerhard dot steinmetz dot fortran at t-online dot de
+!
+program p
+   character(100) :: x
+   data x(998:99) /'ab'/   ! { dg-warning "Unused initialization string" }
+   call a
+end
+
+subroutine a
+   character(2) :: x
+   data x(:-1) /'ab'/  ! { dg-warning "Unused initialization string" }
+end subroutine a
+
+subroutine b
+   character(8) :: x
+   data x(3:1) /'abc'/ ! { dg-warning "Unused initialization string" }
+end subroutine b
+

Re: [PATCH] PR fortran/67939 -- Fix zero length strings in DATA statement

[Steve Kargl]

On Wed, Oct 21, 2015 at 11:20:55PM +0200, Paul Richard Thomas wrote:
> 
> It looks good to me - OK to commit.
> 
> Cheers
> 
> Paul
> 
> PS You, as far as I can tell, are the second most prolific bug fixer
> of 2015. The only person that beats you is Mr(or Ms) Unassigned. We
> need to sort out who this person is.
> 

Well, Gerhard Steinmetz is submitting small self-contained
bugs that appear to be corner cases in the matchers.  Allr
are low hanging fruit.  I leave the hard PR's to people that
know what they are doing. ;-)

-- 
Steve

Re: [PATCH] fortran/68019 -- Remove an assert() that prevents error message

[Steve Kargl]

Thanks.  Patch committed to both 5-branch and trunk.

-- 
steve

On Mon, Oct 19, 2015 at 10:02:09PM +0200, Paul Richard Thomas wrote:
> Hi Steve,
> 
> Yes, this is OK for trunk. I suggest that it is so obvious that it
> should go into 5 branch as well.
> 
> Cheers
> 
> Paul
> 
> On 19 October 2015 at 21:13, Steve Kargl
> <s...@troutmask.apl.washington.edu> wrote:
> > The attached patch removes an assert() that prevents gfortran from
> > issuing an error message.  Built and tested on x86_64-*-freebsd.
> > Althoug probably an "obviously correct" patch, OK to commit?
> >
> > 2015-10-19  Steven G. Kargl  <ka...@gcc.gnu.org>
> >
> > PR fortran/68019
> > * decl.c (add_init_expr_to_sym): Remove an assert() to allow an 
> > error
> > message to be issued.
> >
> > 2015-10-19  Steven G. Kargl  <ka...@gcc.gnu.org>
> >
> > PR fortran/68019
> > * gfortran.dg/pr68019.f90: new test.
> >
> > --
> > Steve
> 
> 
> 
> -- 
> Outside of a dog, a book is a man's best friend. Inside of a dog it's
> too dark to read.
> 
> Groucho Marx

-- 
Steve

[PATCH] fortran/68019 -- Remove an assert() that prevents error message

[Steve Kargl]

The attached patch removes an assert() that prevents gfortran from
issuing an error message.  Built and tested on x86_64-*-freebsd.
Althoug probably an "obviously correct" patch, OK to commit?

2015-10-19  Steven G. Kargl  

PR fortran/68019
* decl.c (add_init_expr_to_sym): Remove an assert() to allow an error
message to be issued.

2015-10-19  Steven G. Kargl  

PR fortran/68019
* gfortran.dg/pr68019.f90: new test.

-- 
Steve
Index: gcc/fortran/decl.c
===
--- gcc/fortran/decl.c	(revision 228974)
+++ gcc/fortran/decl.c	(working copy)
@@ -1486,7 +1486,6 @@ add_init_expr_to_sym (const char *name, 
 			 " with scalar", >declared_at);
 	  return false;
 	}
-	  gcc_assert (sym->as->rank == init->rank);
 
 	  /* Shape should be present, we get an initialization expression.  */
 	  gcc_assert (init->shape);
Index: gcc/testsuite/gfortran.dg/pr68019.f90
===
--- gcc/testsuite/gfortran.dg/pr68019.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/pr68019.f90	(working copy)
@@ -0,0 +1,13 @@
+! { dg-do compile }
+! Original code from Gerhard Steinmetz
+! Gerhard dot Steinmetz for fortran at t-online dot de
+! PR fortran/68019
+!
+program p
+   integer :: i
+   type t
+  integer :: n
+   end type
+   type(t), parameter :: vec(*) = [(t(i), i = 1, 4)]
+   type(t), parameter :: arr(*) = reshape(vec, [2, 2])   ! { dg-error "ranks 1 and 2 in assignment" }
+end

[PATCH,committed] PR fortran/67900 -- Check for NULL pointer

[Steve Kargl]

Committed as 'obvious' after Mikael's comment in PR audit trail.

2015-10-19  Steven G. Kargl  

* resolve.c (gfc_verify_binding_labels): Check for NULL pointer.

2015-10-19  Steven G. Kargl  

* gfortran.dg/pr67900.f90: New tests.

-- 
Steve
Index: gcc/fortran/resolve.c
===
--- gcc/fortran/resolve.c	(revision 229002)
+++ gcc/fortran/resolve.c	(working copy)
@@ -10800,7 +10800,7 @@ gfc_verify_binding_labels (gfc_symbol *s
   sym->binding_label = NULL;
 
 }
-  else if (sym->attr.flavor == FL_VARIABLE
+  else if (sym->attr.flavor == FL_VARIABLE && module 
 	   && (strcmp (module, gsym->mod_name) != 0
 	   || strcmp (sym->name, gsym->sym_name) != 0))
 {
Index: gcc/testsuite/gfortran.dg/pr67900.f90
===
--- gcc/testsuite/gfortran.dg/pr67900.f90	(revision 0)
+++ gcc/testsuite/gfortran.dg/pr67900.f90	(working copy)
@@ -0,0 +1,19 @@
+! { dg-do compile }
+! PR fortran/67900
+! Original code contributed by Giorgian Borca-Tasciuc
+! giorgianb at gmail dot com
+! 
+program main
+   implicit none
+   interface f
+  function f_real(x)
+ real, bind(c) :: x
+ real :: f_real
+  end function f_real
+
+  function f_integer(x)
+ integer, bind(c) :: x
+ integer :: f_integer
+  end function f_integer
+   end interface f
+end program main

Re: [Patch, fortran] PR67177, 67977 and memory leaks in move_alloc

[Steve Kargl]

On Sat, Oct 17, 2015 at 09:49:45PM +0200, Paul Richard Thomas wrote:
> 
> I was moved by a report on clf of memory leaks in move_alloc to
> investigate the cause. This turned out to be trivial but led to the
> above PRs, which themselves were trivial. The result is the attached
> patch. I am aware that I have not investigated the further
> ramifications that I can imagine are there. Rather, I thought just to
> fix the reported problems.
> 
> It should be noted that there is no PR directly associated with the
> memory leaks. Since the standard does not require this, I did not
> think that it was worthwhile to raise a PR and then close it!
> 
> Bootstraps and regtests on FC21/x86_64 - OK for trunk? ... and 5.2
> after a decent interval?

OK.

-- 
steve

[PATCH] PR fortran/67987 -- character lengths cannot be negative

[Steve Kargl]

The attach patch enforces the Fortran Standard's requirement
that character length must be great than or equal to zero.
The fix submitted here supercedes the fix for PR fortran/31250,
which silently converted a negative string length to zero.
In removing the fix for 31250, a regression occurred, because
a substring reference where the 'start' value is larger than 
'end' value results in a zero length string.  gfortran was computing
the length, but not checking for a negative value.  This has
be fixed by actually doing the check and resetting legnth to
zero. 

Built and tested on x86_64-*-freebsd.  OK to commit? 

2015-10-16  Steven G. Kargl  

* decl.c (char_len_param_value): Check for negative character length.
Unwrap a nearby unlong line.
* resolve.c (gfc_resolve_substring_charlen): If a substring would have
a negative character length, set it to zero per the Fortran standard.
Unwrap a nearby unlong line.
(resolve_charlen): Check for negative character length.

2015-10-16  Steven G. Kargl  

gfortran.dg/char_length_2.f90: Update the testcase.

-- 
Steve
Index: fortran/decl.c
===
--- fortran/decl.c	(revision 228667)
+++ fortran/decl.c	(working copy)
@@ -697,8 +697,7 @@ char_len_param_value (gfc_expr **expr, b
 
   if (gfc_match_char (':') == MATCH_YES)
 {
-  if (!gfc_notify_std (GFC_STD_F2003, "deferred type "
-			   "parameter at %C"))
+  if (!gfc_notify_std (GFC_STD_F2003, "deferred type parameter at %C"))
 	return MATCH_ERROR;
 
   *deferred = true;
@@ -708,11 +707,13 @@ char_len_param_value (gfc_expr **expr, b
 
   m = gfc_match_expr (expr);
 
-  if (m == MATCH_YES
-  && !gfc_expr_check_typed (*expr, gfc_current_ns, false))
+  if (m == MATCH_NO || m == MATCH_ERROR)
+return m;
+
+  if (!gfc_expr_check_typed (*expr, gfc_current_ns, false))
 return MATCH_ERROR;
 
-  if (m == MATCH_YES && (*expr)->expr_type == EXPR_FUNCTION)
+  if ((*expr)->expr_type == EXPR_FUNCTION)
 {
   if ((*expr)->value.function.actual
 	  && (*expr)->value.function.actual->expr->symtree)
@@ -731,6 +732,16 @@ char_len_param_value (gfc_expr **expr, b
 	}
 	}
 }
+
+  /* F2008, 4.4.3.1:  The length is a type parameter; its kind is processor
+ dependent and its value is greater than or equal to zero.  */
+  if ((*expr)->expr_type == EXPR_CONSTANT
+  && mpz_cmp_si ((*expr)->value.integer, 0) < 0)
+{
+  gfc_error ("LEN at %C must be greater than or equal to 0");
+  return MATCH_ERROR;
+}
+
   return m;
 
 syntax:
Index: fortran/resolve.c
===
--- fortran/resolve.c	(revision 228667)
+++ fortran/resolve.c	(working copy)
@@ -4562,8 +4562,7 @@ gfc_resolve_substring_charlen (gfc_expr 
 {
   if (e->ts.u.cl->length)
 	gfc_free_expr (e->ts.u.cl->length);
-  else if (e->expr_type == EXPR_VARIABLE
-		 && e->symtree->n.sym->attr.dummy)
+  else if (e->expr_type == EXPR_VARIABLE && e->symtree->n.sym->attr.dummy)
 	return;
 }
 
@@ -4596,12 +4595,19 @@ gfc_resolve_substring_charlen (gfc_expr 
   return;
 }
 
-  /* Length = (end - start +1).  */
+  /* Length = (end - start + 1).  */
   e->ts.u.cl->length = gfc_subtract (end, start);
   e->ts.u.cl->length = gfc_add (e->ts.u.cl->length,
 gfc_get_int_expr (gfc_default_integer_kind,
 		  NULL, 1));
 
+  /* F2008, 6.4.1:  Both the starting point and the ending point shall
+ be within the range 1, 2, ..., n unless the starting point exceeds
+ the ending point, in which case the substring has length zero.  */
+
+  if (mpz_cmp_si (e->ts.u.cl->length->value.integer, 0) < 0)
+mpz_set_si (e->ts.u.cl->length->value.integer, 0);
+
   e->ts.u.cl->length->ts.type = BT_INTEGER;
   e->ts.u.cl->length->ts.kind = gfc_charlen_int_kind;
 
@@ -10882,17 +10888,12 @@ resolve_charlen (gfc_charlen *cl)
 	}
 }
 
-  /* "If the character length parameter value evaluates to a negative
- value, the length of character entities declared is zero."  */
   if (cl->length && !gfc_extract_int (cl->length, ) && i < 0)
 {
-  if (warn_surprising)
-	gfc_warning_now (OPT_Wsurprising,
-			 "CHARACTER variable at %L has negative length %d,"
-			 " the length has been set to zero",
-			 >length->where, i);
-  gfc_replace_expr (cl->length,
-			gfc_get_int_expr (gfc_default_integer_kind, NULL, 0));
+  gfc_error ("LEN at %L must be greater than or equal to 0", 
+		 >length->where);
+  specification_expr = saved_specification_expr;
+  return false;
 }
 
   /* Check that the character length is not too large.  */
Index: testsuite/gfortran.dg/char_length_2.f90
===
--- testsuite/gfortran.dg/char_length_2.f90	(revision 228667)
+++ testsuite/gfortran.dg/char_length_2.f90	(working copy)
@@ -1,22 +1,12 @@
-! { dg-do link }
-! { 

Re: [Patch, fortran] COMMON block error recovery: PR 67758 (second pass)

[Steve Kargl]

On Tue, Oct 06, 2015 at 07:52:16PM +0200, Mikael Morin wrote:
> 
> Dominique noticed that the test coming with the preceding PR67758 patch 
> [1] was failing if compiled as free form.
> [1] https://gcc.gnu.org/ml/gcc-patches/2015-10/msg00301.html
> 
> The problem is again an inconsistent state, but this time between the 
> in_common attribute and the common_block pointer.
> So, here is another iteration, hopefully fixing the remaining problems.
> The changes are:
> - adding a symbol to a common block list in gfc_match_common is 
> delayed after the call to gfc_add_in_common.
> - gfc_restore_latest_undo_checkpoint is changed to check the 
> common_block pointer directly instead of the in_common attribute.
> Both of these changes fix the testcase independently, but with some 
> regressions, so there is additionally:
> - gfc_restore_old_symbol is changed to also restore the 
> common-related pointers.  This is done using a new function created to 
> factor the related memory management.
> - In gfc_restore_last_undo_checkpoint, when a symbol has been 
> removed from the common block linked list, its common_next pointer is 
> cleared.
> 
> Regression tested on x86_64-linux.  OK for trunk?
> 

Hi Mikael,

I think the patch is OK

-- 
Steve

Re: [PATCH] PR fortran/67987 -- character lengths cannot be negative

[Steve Kargl]

On Fri, Oct 16, 2015 at 10:17:34PM +0200, FX wrote:
> > The attach patch enforces the Fortran Standard's requirement
> > that character length must be great than or equal to zero.
> 
> 4.4.3.2. "If the character length parameter value evaluates to
> a negative value, the length of character entities declared is zero."
> 

Thanks.  I missed the above.  The above text goes back to 
at least F90 (see p. 41 on N693.pdf).  New diff attached.

2015-10-16  Steven G. Kargl  

PR fortran/67987
* decl.c (char_len_param_value): Unwrap unlong line.  If LEN < 0,
then force it to zero pre Fortran Standards. 
* resolve.c (gfc_resolve_substring_charlen): Unwrap unlong line.
If 'start' is larger than 'end', then length of string is negative,
so explicitly set it to zero.
(resolve_charlen): Remove -Wsurprising warning.  Update comment to
text from F2008 standard.

2015-10-16  Steven G. Kargl  

PR fortran/67987
* gfortran.dg/char_length_2.f90: Add declaration from PR to testcase.

-- 
Steve
Index: fortran/decl.c
===
--- fortran/decl.c	(revision 228667)
+++ fortran/decl.c	(working copy)
@@ -697,8 +697,7 @@ char_len_param_value (gfc_expr **expr, b
 
   if (gfc_match_char (':') == MATCH_YES)
 {
-  if (!gfc_notify_std (GFC_STD_F2003, "deferred type "
-			   "parameter at %C"))
+  if (!gfc_notify_std (GFC_STD_F2003, "deferred type parameter at %C"))
 	return MATCH_ERROR;
 
   *deferred = true;
@@ -708,11 +707,13 @@ char_len_param_value (gfc_expr **expr, b
 
   m = gfc_match_expr (expr);
 
-  if (m == MATCH_YES
-  && !gfc_expr_check_typed (*expr, gfc_current_ns, false))
+  if (m == MATCH_NO || m == MATCH_ERROR)
+return m;
+
+  if (!gfc_expr_check_typed (*expr, gfc_current_ns, false))
 return MATCH_ERROR;
 
-  if (m == MATCH_YES && (*expr)->expr_type == EXPR_FUNCTION)
+  if ((*expr)->expr_type == EXPR_FUNCTION)
 {
   if ((*expr)->value.function.actual
 	  && (*expr)->value.function.actual->expr->symtree)
@@ -731,6 +732,15 @@ char_len_param_value (gfc_expr **expr, b
 	}
 	}
 }
+
+  /* F2008, 4.4.3.1:  The length is a type parameter; its kind is processor
+ dependent and its value is greater than or equal to zero.
+ F2008, 4.4.3.2:  If the character length parameter value evaluates to
+ a negative value, the length of character entities declared is zero.  */
+  if ((*expr)->expr_type == EXPR_CONSTANT
+  && mpz_cmp_si ((*expr)->value.integer, 0) < 0)
+mpz_set_si ((*expr)->value.integer, 0);
+
   return m;
 
 syntax:
Index: fortran/resolve.c
===
--- fortran/resolve.c	(revision 228667)
+++ fortran/resolve.c	(working copy)
@@ -4562,8 +4562,7 @@ gfc_resolve_substring_charlen (gfc_expr 
 {
   if (e->ts.u.cl->length)
 	gfc_free_expr (e->ts.u.cl->length);
-  else if (e->expr_type == EXPR_VARIABLE
-		 && e->symtree->n.sym->attr.dummy)
+  else if (e->expr_type == EXPR_VARIABLE && e->symtree->n.sym->attr.dummy)
 	return;
 }
 
@@ -4596,12 +4595,19 @@ gfc_resolve_substring_charlen (gfc_expr 
   return;
 }
 
-  /* Length = (end - start +1).  */
+  /* Length = (end - start + 1).  */
   e->ts.u.cl->length = gfc_subtract (end, start);
   e->ts.u.cl->length = gfc_add (e->ts.u.cl->length,
 gfc_get_int_expr (gfc_default_integer_kind,
 		  NULL, 1));
 
+  /* F2008, 6.4.1:  Both the starting point and the ending point shall
+ be within the range 1, 2, ..., n unless the starting point exceeds
+ the ending point, in which case the substring has length zero.  */
+
+  if (mpz_cmp_si (e->ts.u.cl->length->value.integer, 0) < 0)
+mpz_set_si (e->ts.u.cl->length->value.integer, 0);
+
   e->ts.u.cl->length->ts.type = BT_INTEGER;
   e->ts.u.cl->length->ts.kind = gfc_charlen_int_kind;
 
@@ -10882,18 +10888,11 @@ resolve_charlen (gfc_charlen *cl)
 	}
 }
 
-  /* "If the character length parameter value evaluates to a negative
- value, the length of character entities declared is zero."  */
+  /* F2008, 4.4.3.2:  If the character length parameter value evaluates to
+ a negative value, the length of character entities declared is zero.  */
   if (cl->length && !gfc_extract_int (cl->length, ) && i < 0)
-{
-  if (warn_surprising)
-	gfc_warning_now (OPT_Wsurprising,
-			 "CHARACTER variable at %L has negative length %d,"
-			 " the length has been set to zero",
-			 >length->where, i);
-  gfc_replace_expr (cl->length,
+gfc_replace_expr (cl->length,
 			gfc_get_int_expr (gfc_default_integer_kind, NULL, 0));
-}
 
   /* Check that the character length is not too large.  */
   k = gfc_validate_kind (BT_INTEGER, gfc_charlen_int_kind, false);
Index: testsuite/gfortran.dg/char_length_2.f90
===
--- 

Re: [PATCH] PR fortran/67987 -- character lengths cannot be negative

[Steve Kargl]

On Fri, Oct 16, 2015 at 02:55:27PM -0700, Steve Kargl wrote:
> On Fri, Oct 16, 2015 at 11:39:51PM +0200, FX wrote:
> 
> >   - why remove the -Wsurprising warning? it seems a good case
> > for -Wsurprising: legal code, but dubious anyway
> > 
> > OK after you ponder that second point.
> > 
> 
> F90 is over 26 years old.  There has been 3 major revisions that
> have superceded F90 (F95, F03, and F08).  All of those revisions
> include the text that you pointed out to me.  Why is it surprising
> that a compiler conforms to the standard?  
> 
> "Simplify, simplify, simplify."  Henry David Thoreau
> 

Another reason to remove it.  It is no longer reached
for the first 2 of the 3 dg-warnings in char_length_2.f90. 

% head -13 char_length_2.f90

! { dg-do link }
! { dg-options "-Wsurprising" }
! Tests the fix for PR 31250
! CHARACTER lengths weren't reduced early enough for all checks of
! them to be meaningful.  Furthermore negative string lengths weren't
! dealt with correctly.
CHARACTER(len=0) :: c1   ! This is OK.
CHARACTER(len=-1) :: c2  ! { dg-warning "has negative length" }
PARAMETER(I=-100)
CHARACTER(len=I) :: c3   ! { dg-warning "has negative length" }
CHARACTER(len=min(I,500)) :: c4  ! { dg-warning "has negative length" }
CHARACTER(len=max(I,500)) :: d1  ! no warning
CHARACTER(len=5) :: d2   ! no warning

-- 
Steve

Re: [Patch, fortran, 5] Bakport Andre's r222477 deep copy fix for PR67818

[Steve Kargl]

On Thu, Oct 15, 2015 at 12:18:12PM +0200, Andre Vehreschild wrote:
> 
> Regards,
>   Andre
> 
> PS: Note, I don't have reviewer status.
> 

Given your contributions to gfortran and the fact that
you probably understand portions of the (de)allocation
code better than anyone, I suspect that your opinion
on any patch would be quite welcomed.  In other words,
consider youself a reviewer for patches in an area 
of the compiler that you are comfortable.

-- 
Steve

Re: Possible patch for PR fortran/67806

[Steve Kargl]

On Sun, Oct 11, 2015 at 10:18:48PM -0700, Louis Krupp wrote:
> The problem involves a derived type with a character component declared 
> CHARACTER(NULL()) or CHARACTER(NULL(n)), where mold argument n is an integer 
> pointer.
> 

I was looking at 67805 this weekend, which is somewhat
related to this PR.  AFAICT, gfortran does no checking
for n in CHARACTER(LEN=n). n should be a scalar-int-expr
(that is scalar INTEGER expression).  NULL() is not
an integer, and NULL(n) is a disassociated pointer.  So,
I believe neither can appear in an scalar-int-expr.

Note, also that there is a table in 13.7.125 on where
NULL() can appear.

My patch for 67805 leads to one regression that I've been
unable to resolve.

-- 
Steve

Re: [PATCH] fortran/67758 -- Prevent ICE caused by misplaced COMMON

[Steve Kargl]

On Sat, Oct 03, 2015 at 12:13:12PM +0200, Mikael Morin wrote:
>
> I have finally managed to find a patch that doesn't regress in the 
> testsuite.
> 
> The gfc_add_in_common call in gfc_match_common is delayed after the 
> array spec handling and without return value check, so that errors are 
> ignored.  Another gfc_add_in_common call is necessary to report errors 
> again during resolution.  This is patch number 2.
> The error location for the second call is grabbed from the common block 
> struct, which is made accessible in the function by patch number 1.
> 
> No regression on x86-unknown-linux-gnu, OK for trunk?
> 

The patch is OK.  Thanks for taking over PR.

-- 
Steve

Re: [Patch, fortran] PR67721 deep copy missing when assigning derived type constructor to an array

[Steve Kargl]

On Fri, Oct 02, 2015 at 09:33:33AM -0700, H.J. Lu wrote:
> On Sat, Sep 26, 2015 at 6:10 AM, Mikael Morin  wrote:
> > Hello,
> >
> > I've just submitted this PR, and the patch as well, which passes the
> > testsuite.
> >
> > The problem is a missing deep copy when the rhs is a (scalar) derived type
> > constructor (with allocatable components) and the lhs an array.
> > The patch removes the nonconstantness condition, so that the deep_copy flag
> > passed to gfc_trans_scalar_assign is set to true.
> >
> > Regression-tested on x86_64-unknown-linux-gnu. OK for trunk?
> > Mikael
> >
> 
> This caused:
> 
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67818
> 
> on GCC 5 branch.
> 

Fairly, uninformative bug report.  

-- 
Steve

Re: [PATCH] fortran/67758 -- Prevent ICE caused by misplaced COMMON

[Steve Kargl]

On Fri, Oct 02, 2015 at 11:28:06AM +0200, Mikael Morin wrote:
> Le 01/10/2015 18:30, Steve Kargl a écrit :
> > I'm fine with your patch, although I find the error message
> > to be somewhat confusing as no procedure appears in COMMON.
> 
> Well, XX is implicitly a procedure.
> 

Yes, I understamf what gfortran is doing.  However, I
less fluent Fortran programmer who expects XX to be 
an array may be confused by error message.

> > The call-stmt in the code is the start of an execution-construct.
> > A common-stmt is not allowed in an execution-construct.  At
> > least, that's how I intepret the BNF in 2.1 of F2008.
> >
> The error message appears too soon, before we finish parsing the common 
> statement.  If it's delayed, as with the following additional patch, the 
> common statements is properly rejected:
> 
> common_24.f:10:72:
> 
> COMMON /FMCOM / XX(80 000 000) ! { dg-error "conflicts with 
> COMMON" }
>  1
> Error: Unexpected COMMON statement at (1)
> common_24.f:8:72:
> 
> Error: PROCEDURE attribute conflicts with COMMON attribute in ???xx??? at (1)
> 
> This needs a little more polishing (location missing in the second error 
> message), then let's see how the testsuite likes it.
> 

While I prefer the first error message above, if it requires
too much polish, then at least commit your first patch to cure
the ICE.  We can worry about polish later.

-- 
Steve

Re: [PATCH] fortran/67758 -- Prevent ICE caused by misplaced COMMON

[Steve Kargl]

On Thu, Oct 01, 2015 at 03:29:05PM +0200, Mikael Morin wrote:
> Le 01/10/2015 14:16, Mikael Morin a écrit :
> > Le 01/10/2015 02:07, Steve Kargl a écrit :
> >> On Wed, Sep 30, 2015 at 05:06:30PM -0700, Steve Kargl wrote:
> >>> Patch built and regression tested on x86_64-*-freebsd.
> >>> OK to commit?
> >>>
> >>> The patch prevents the dereferencing of a NULL pointer
> >>> by jumping out of the cleanup of a list of COMMON blocks.
> >>>
> > Hold on, I believe p should be present in the common symbol list pointed
> > by p->common.
> s/p->common/p->common_block/
> > And by the way, if we are in gfc_restore_last_undo_checkpoint, we have
> > found something bogus enough to backtrack, so hopefully an error has
> > already been prepared (but maybe not emitted).
> > I will investigate more.
> >
> It seems the error [1] is reported in gfc_add_in_common, between the 
> time the symbol's common_block pointer is set and the time the symbol is 
> added to the list.
> As the program goes straight to clean-up/return upon error, this interim 
> state is not fixed and poses problem.
> 
> So we need to reduce the interim time to zero or fix the state upon error.
> I propose the following, which delays setting the common_block after 
> error_checking (I believe it is not used in that time).
> 
> Regression-tested on x86_64-unknown-linux-gnu. OK for trunk?
> 

I'm fine with your patch, although I find the error message
to be somewhat confusing as no procedure appears in COMMON.
The call-stmt in the code is the start of an execution-construct.
A common-stmt is not allowed in an execution-construct.  At
least, that's how I intepret the BNF in 2.1 of F2008.

-- 
Steve

[PATCH] fortran/67802 -- Numeric constant character length must ...

[Steve Kargl]

be an integer expression.

The attached patch checks that a numerical constant in
a CHARACTER(LEN=x) declaration is an integer.  Regression
tested on x86_64-*-freebsd*.  OK to commit?

2015-10-01  Steven G. Kargl  

PR fortran/67802
* decl.c (add_init_expr_to_sym): Numeric constant for character
length must be an INTEGER.

2015-10-01  Steven G. Kargl  

PR fortran/67802
* gfortran.dg/pr67802.f90: New test.

-- 
Steve
Index: fortran/decl.c
===
--- fortran/decl.c	(revision 228306)
+++ fortran/decl.c	(working copy)
@@ -1439,7 +1439,16 @@ add_init_expr_to_sym (const char *name, 
 	  /* Update initializer character length according symbol.  */
 	  else if (sym->ts.u.cl->length->expr_type == EXPR_CONSTANT)
 	{
-	  int len = mpz_get_si (sym->ts.u.cl->length->value.integer);
+	  int len;
+
+	  if (sym->ts.u.cl->length->ts.type != BT_INTEGER)
+		{
+		  gfc_error ("Expecting an scalar-int-expr at %L",
+			 >ts.u.cl->length->where);
+		  return false;
+		}
+
+	  len = mpz_get_si (sym->ts.u.cl->length->value.integer);
 
 	  if (init->expr_type == EXPR_CONSTANT)
 		gfc_set_constant_character_len (len, init, -1);
Index: testsuite/gfortran.dg/pr67802.f90
===
--- testsuite/gfortran.dg/pr67802.f90	(revision 0)
+++ testsuite/gfortran.dg/pr67802.f90	(working copy)
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! PR fortran/67802
+! Original code contribute by gerhard.steinmetz.fortran at t-online.de
+program p
+   character(1.) :: c1 = ' '  ! { dg-error "Expecting an scalar-int-expr" }
+   character(1d1) :: c2 = ' ' ! { dg-error "Expecting an scalar-int-expr" }
+   character((0.,1.)) :: c3 = ' ' ! { dg-error "Expecting an scalar-int-expr" }
+   character(.true.) :: c4 = ' '  ! { dg-error "Expecting an scalar-int-expr" }
+end program p

Re: [PATCH] fortran/67802 -- Numeric constant character length must ...

[Steve Kargl]

On Thu, Oct 01, 2015 at 09:19:15PM +0200, FX wrote:
> > 2015-10-01  Steven G. Kargl  
> > 
> > PR fortran/67802
> > * decl.c (add_init_expr_to_sym): Numeric constant for character
> > length must be an INTEGER.
> > 
> > 2015-10-01  Steven G. Kargl  
> > 
> > PR fortran/67802
> > * gfortran.dg/pr67802.f90: New test.
> 
> OK, but not with that error message. We currently don???t use
> the ???shorthand??? standard notation (like "scalar-int-expr???)
> in our error messages, and we should keep that consistent.
> So I would go with ???character length should be of integer
> type??? or something like that.
> 

Well, ahem, gfortran does have several error messages that use the
standard notation.  I know.  I wrote some of them. :-)

I'll simply change it to "Expecting an INTEGER at %L"

-- 
Steve

Re: [PATCH] fortran/67802 -- Numeric constant character length must ...

[Steve Kargl]

On Thu, Oct 01, 2015 at 11:19:37PM +0200, Dominique d'Humières wrote:
> Without initialization the errors are of the kind:
> 
> Error: Expression at (1) must be of INTEGER type, found *
> 
> see https://gcc.gnu.org/ml/gcc-bugs/2015-10/msg00081.html. Should not we get 
> the same message with initialization?
> 

Ugh, that message is horrible.  IMHO, everything after the comma
(your ", found *") is an abmonition.


-- 
Steve

Re: [PATCH] fortran/67758 -- Prevent ICE caused by misplaced COMMON

[Steve Kargl]

On Wed, Sep 30, 2015 at 05:06:30PM -0700, Steve Kargl wrote:
> Patch built and regression tested on x86_64-*-freebsd.
> OK to commit?
> 
> The patch prevents the dereferencing of a NULL pointer
> by jumping out of the cleanup of a list of COMMON blocks.
> 
> 2015-09-30  Steven G. Kargl  <ka...@gcc.gnu.org>
> 
>   * symbol.c (gfc_restore_last_undo_checkpoint): Prevent ICE during
>   cleanup of a misplaced COMMON.
> 
> 2015-09-30  Steven G. Kargl  <ka...@gcc.gnu.org>
> 
>   * gfortran.dg/pr67758.f: New test.
> 

Now with the patch attached!

-- 
Steve
Index: fortran/symbol.c
===
--- fortran/symbol.c	(revision 228306)
+++ fortran/symbol.c	(working copy)
@@ -3211,6 +3211,11 @@ gfc_restore_last_undo_checkpoint (void)
 
 	  while (csym != p)
 		{
+		  if (!csym)
+		{
+		  gfc_error ("Unexpected COMMON at %C");
+		  goto error;
+		}
 		  cparent = csym;
 		  csym = csym->common_next;
 		}
@@ -3237,6 +3242,8 @@ gfc_restore_last_undo_checkpoint (void)
 	restore_old_symbol (p);
 }
 
+error:
+
   latest_undo_chgset->syms.truncate (0);
   latest_undo_chgset->tbps.truncate (0);
 
Index: testsuite/gfortran.dg/pr67758.f
===
--- testsuite/gfortran.dg/pr67758.f	(revision 0)
+++ testsuite/gfortran.dg/pr67758.f	(working copy)
@@ -0,0 +1,6 @@
+c { dg-do compile }
+c PR fortran/67758
+  COMMON /FMCOM / X(80 000 000)
+  CALL T(XX(A))
+  COMMON /FMCOM / XX(80 000 000) ! { dg-error "Unexpected COMMON" }
+  END

[PATCH] fortran/67758 -- Prevent ICE caused by misplaced COMMON

[Steve Kargl]

Patch built and regression tested on x86_64-*-freebsd.
OK to commit?

The patch prevents the dereferencing of a NULL pointer
by jumping out of the cleanup of a list of COMMON blocks.

2015-09-30  Steven G. Kargl  

* symbol.c (gfc_restore_last_undo_checkpoint): Prevent ICE during
cleanup of a misplaced COMMON.

2015-09-30  Steven G. Kargl  

* gfortran.dg/pr67758.f: New test.

-- 
Steve

[PATCH] fortran/66979 -- FLUSH requires a UNIT number in the spec-list

[Steve Kargl]

When FLUSH is used with a flulsh-spec-list, a unit is required.
Thus, a statement like 'flush(iostat=i)' would lead to an ICE
because gfortran was dereference a pointer to a non-existant
unit number.  The attached patch was built and tested on
x86-*-freebsd.  OK to commit?

2015-09-30  Steven G. Kargl  

* io.c (gfc_resolve_filepos): Check for a UNIT number.  Add a nearby
missing 'return false'.

2015-09-30  Steven G. Kargl  

gfortran.dg/pr66979.f90: new test.

-- 
Steve
Index: fortran/io.c
===
--- fortran/io.c	(revision 228306)
+++ fortran/io.c	(working copy)
@@ -2515,12 +2515,21 @@ gfc_resolve_filepos (gfc_filepos *fp)
   if (!gfc_reference_st_label (fp->err, ST_LABEL_TARGET))
 return false;
 
+  if (!fp->unit && (fp->iostat || fp->iomsg))
+{
+  locus where;
+  where = fp->iostat ? fp->iostat->where : fp->iomsg->where;
+  gfc_error ("UNIT number missing in statement at %L", );
+  return false;
+}
+
   if (fp->unit->expr_type == EXPR_CONSTANT
   && fp->unit->ts.type == BT_INTEGER
   && mpz_sgn (fp->unit->value.integer) < 0)
 {
   gfc_error ("UNIT number in statement at %L must be non-negative",
 		 >unit->where);
+  return false;
 }
 
   return true;
Index: testsuite/gfortran.dg/pr66979.f90
===
--- testsuite/gfortran.dg/pr66979.f90	(revision 0)
+++ testsuite/gfortran.dg/pr66979.f90	(working copy)
@@ -0,0 +1,7 @@
+! { dg-do compile }
+! PR fortran/66979
+program p
+  implicit none
+  integer::i
+  flush (iostat=i) ! { dg-error "UNIT number missing" }
+end program p

[PATCH] fortran/67616 -- Fix ICE in BLOCK with a DATA statement

[Steve Kargl]

The attached patch was built and tested on x86_64-*-freebsd.
OK to commit?

The patch prevents an ICE in a BLOCK construct that uses
a DATA statement and default initialization.  The problem
was that the derived typed was declared in the host and
was not in the BLOCK's symtree.  The fix looks for the 
derived type through host associate.

Just remembered Mikael pre-approved patch.

2015-09-30  Steven G. Kargl  

PR fortran/67616
* primary.c (gfc_match_structure_constructor): Use a possibly
host-associated symtree to prevent ICE.

2015-09-30  Steven G. Kargl  

PR fortran/67616
* gfortran.dg/pr67616.f90: New test.

-- 
Steve
Index: fortran/primary.c
===
--- fortran/primary.c	(revision 228306)
+++ fortran/primary.c	(working copy)
@@ -2697,7 +2697,7 @@ gfc_match_structure_constructor (gfc_sym
   gfc_expr *e;
   gfc_symtree *symtree;
 
-  gfc_get_sym_tree (sym->name, NULL, , false);   /* Can't fail */
+  gfc_get_ha_sym_tree (sym->name, );
 
   e = gfc_get_expr ();
   e->symtree = symtree;
Index: testsuite/gfortran.dg/pr67616.f90
===
--- testsuite/gfortran.dg/pr67616.f90	(revision 0)
+++ testsuite/gfortran.dg/pr67616.f90	(working copy)
@@ -0,0 +1,13 @@
+! { dg-do compile }
+! PR fortran/67616
+! Original code contributed by Gerhard Steinmetz 
+program p
+   type t
+   end type
+   type(t) :: y
+   data y /t()/
+   block
+  type(t) :: x
+  data x /t()/  ! Prior to patch, this would ICE.
+   end block
+end

[PATCH,committed] xfail Fortran tests on i386-*freebsd*

[Steve Kargl]

Neither test mention below has a chance to ever pass
on i386-*-freebsd* without a rewrite of the testecases.
So, I've xfailed both.


2015-09-29  Steven G. Kargl  

gfortran.dg/ieee/ieee_4.f90: xfail on i386-*-freebsd*
gfortran.dg/round_4.f90: ditto.

Index: gfortran.dg/ieee/ieee_4.f90
===
--- gfortran.dg/ieee/ieee_4.f90 (revision 228261)
+++ gfortran.dg/ieee/ieee_4.f90 (working copy)
@@ -1,4 +1,4 @@
-! { dg-do run }
+! { dg-do run { xfail i386-*-freebsd* } }
 
   use :: ieee_arithmetic
   implicit none
Index: gfortran.dg/round_4.f90
===
--- gfortran.dg/round_4.f90 (revision 228261)
+++ gfortran.dg/round_4.f90 (working copy)
@@ -1,4 +1,4 @@
-! { dg-do run }
+! { dg-do run { xfail i386-*-freebsd* } }
 ! { dg-add-options ieee }
 ! { dg-skip-if "PR libfortran/58015" { hppa*-*-hpux* } }
 ! { dg-skip-if "IBM long double 31 bits of precision, test requires 38" { 
powerpc*-*-linux* } }
-- 
Steve

Re: [PATCH] fortran/67616 -- Fix ICE within a BLOCK construct

[Steve Kargl]

On Sat, Sep 26, 2015 at 03:34:22PM +0200, Mikael Morin wrote:
> Le 25/09/2015 23:41, Steve Kargl a ??crit :
> > The attached patch has been built and regression
> > tested on x86_64-*-freebsd.  No regression occurred.
> >
> > The patch removes a conditional within an assert()
> > that triggers when a BLOCK construct is encountered.
> >
> What happens here, I think, is symtree is a new block-local symbol 
> instead of the host-associated one.
> symtree is basically unused here, yet playing with the wrong one is not 
> right.
> Can you try using gfc_get_ha_sym_tree a few lines above instead of 
> gfc_get_sym_tree?
> A patch like that is preapproved.
> 

Mikael,

Thanks.  Your suggested change prevents the ICE.  I'll
commit shortly.

-- 
Steve

[PATCH] fortran/67616 -- Fix ICE within a BLOCK construct

[Steve Kargl]

The attached patch has been built and regression
tested on x86_64-*-freebsd.  No regression occurred.

The patch removes a conditional within an assert() 
that triggers when a BLOCK construct is encountered.

OK to commit?

2015-09-25  Steven G. Kargl  

PR fortran/67616
* primary.c (gfc_match_structure_constructor): Remove a condition
in an assert() that is not valid within a BLOCK-END BLOCK construct.

2015-09-25  Steven G. Kargl  

PR fortran/67616
* gfortran.dg/pr67616.f90: New test.
-- 
Steve
Index: fortran/primary.c
===
--- fortran/primary.c	(revision 228061)
+++ fortran/primary.c	(working copy)
@@ -2703,8 +2703,7 @@ gfc_match_structure_constructor (gfc_sym
   e->symtree = symtree;
   e->expr_type = EXPR_FUNCTION;
 
-  gcc_assert (sym->attr.flavor == FL_DERIVED
-	  && symtree->n.sym->attr.flavor == FL_PROCEDURE);
+  gcc_assert (sym->attr.flavor == FL_DERIVED);
   e->value.function.esym = sym;
   e->symtree->n.sym->attr.generic = 1;
 
Index: testsuite/gfortran.dg/pr67616.f90
===
--- testsuite/gfortran.dg/pr67616.f90	(revision 0)
+++ testsuite/gfortran.dg/pr67616.f90	(working copy)
@@ -0,0 +1,13 @@
+! { dg-do compile }
+! PR fortran/67616
+! Original code contributed by Gerhard Steinmetz 
+program p
+   type t
+   end type
+   type(t) :: y
+   data y /t()/
+   block
+  type(t) :: x
+  data x /t()/  ! Prior to patch, this would ICE.
+   end block
+end

[PATCH] fortran/67614 -- Detect an invalid NULL in an arithmetic if

[Steve Kargl]

The attached patch has been built and regression tested on
x86_64-*-freebsd.  There were no regression.

If the scalar-numeric-expr in an arithmetic-if is ar
reference to NULL(), this is an invalid expression.
By resolving the expression, then entity is correctly
identified by EXPR_NULL.  Thus, the patch prevents 
an ICE when a messed up non-scalar-numeric-expr is
later translated in SSA form.

2015-09-25  Steven G. Kargl  

PR fortran/67614
* resolve.c (gfc_resolve_code): Prevent ICE for invalid EXPR_NULL.

2015-09-25  Steven G. Kargl  

PR fortran/67614
* gfortran.dg/pr67614.f90: New test.

-- 
Steve
Index: fortran/resolve.c
===
--- fortran/resolve.c	(revision 228061)
+++ fortran/resolve.c	(working copy)
@@ -10380,10 +10380,14 @@ gfc_resolve_code (gfc_code *code, gfc_na
 	  {
 	gfc_expr *e = code->expr1;
 
+	gfc_resolve_expr (e);
+	if (e->expr_type == EXPR_NULL)
+	  gfc_error ("Invalid NULL at %L", >where);
+
 	if (t && (e->rank > 0
 		  || !(e->ts.type == BT_REAL || e->ts.type == BT_INTEGER)))
 	  gfc_error ("Arithmetic IF statement at %L requires a scalar "
-			 "REAL or INTEGER expression", >expr1->where);
+			 "REAL or INTEGER expression", >where);
 
 	resolve_branch (code->label1, code);
 	resolve_branch (code->label2, code);
Index: testsuite/gfortran.dg/pr67614.f90
===
--- testsuite/gfortran.dg/pr67614.f90	(revision 0)
+++ testsuite/gfortran.dg/pr67614.f90	(working copy)
@@ -0,0 +1,12 @@
+! { dg-do compile }
+! { dg-options "-std=legacy" }
+! PR fortran/67614
+!
+program foo
+   implicit none
+   integer, pointer :: z
+   if (null(z)) 10, 20, 30! { dg-error "Invalid NULL" }
+10 continue
+20 continue
+30 continue
+end program foo