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

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

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

[PATCH, committed] Fix PR fortran/68684

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

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

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. >

Re: [OpenACC 0/7] host_data construct

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,

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

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.wa

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

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

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

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: gfo

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

ted 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: > >> + > >> + /* Abrevi

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

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 > >

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

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 n

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

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):

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

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

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

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 Malcol

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

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 =

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

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

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

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

[PATCH, committed] PR fortran/PR68227

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

Re: [PATCH] PR52251

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

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

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

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

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

Re: [PATCH] Fix leading zero with g0 editing

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

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

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

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

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 typ

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

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

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

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 > +++

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

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

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

> > > > > > 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

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

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_sim

[PATCH] (Partial) Implementation of simplificaiton of CSHIFT

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

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

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); >

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

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)

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

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 b

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

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: > >

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

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

Re: [PATCH] PR 65751 Bogus in error message

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

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

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

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

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!). >

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

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 >

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

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) +++

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

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

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

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

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

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

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

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

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

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):

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

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

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

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

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. --

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

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

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

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

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

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

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

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

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

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?

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

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

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

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

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

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? >

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

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):

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

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.

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

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:

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

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

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

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] PR fortran/68154 -- repair damage done byfix for PR fortran/65429

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

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

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

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

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

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

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 > > >

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

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

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

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):

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

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.

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

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

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

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/fortra

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

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

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

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

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

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

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

> > 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 "obvi

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

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

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

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

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

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

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

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,

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

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,

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

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

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

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 th

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

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

Re: Possible patch for PR fortran/67806

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

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

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 >

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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:

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

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

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

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

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

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,

[PATCH] fortran/67525 -- fix ICE in SELECT TYPE

The follwoing patch has been built and regression tested on x86_64-*-freebsd. There were no regression. The patch removes an assert, which allows gfortran to detect an invalid selector in SELECT TYPE statement. 2015-09-25 Steven G. Kargl PR fortran/67525

Re: [PATCH, fortran] Revival of AUTOMATIC patch

On Fri, Sep 25, 2015 at 07:23:53PM +0200, Paul Richard Thomas wrote: > > Frankly, I would accept the patch with the proviso that: > (i) It is hidden behand a gfc_notify_std (GFC_STD_GNU, "...; > (ii) The feature is set in conflict with the new features that FX > mentions, especially coarrays

<    5   6   7   8   9   10   11   12   13   >