Re: [Patch, Fortran, OOP] PR 78443: Incorrect behavior with non_overridable keyword

On Tue, Nov 22, 2016 at 01:14:46PM +0100, Janus Weil wrote: > > here is a patch for a wrong-code problem with non_overridable > type-bound procedures. For details see the PR. Regtests cleanly. Ok > for trunk? OK. > Since the patch is very simple and it fixes wrong code which can > silently give

Re: PR69741: Bad error in formal with array scalar loop counters

On Sat, Nov 19, 2016 at 03:44:12PM +0100, Harald Anlauf wrote: > > > > 2016-11-19 Harald Anlauf > > > > PR fortran/69741 > > * resolve.c (gfc_resolve_forall): Check for non-scalar index > > variables. > > > > 2016-11-19 Harald Anlauf > > > >

[PATCH] PR fortran/58001 -- Handle tab in FORMAT

An earlier version of the attached patch lingered in bugzilla for over 3 years. I've updated the patch to include Manuel's comment #12. Regression tested on x86_64-*-freebsd. OK to commit? 2016-11-16 Steven G. Kargl PR fortran/58001 * io.c

Re: [PATCH] PR fortran/78300 -- class procedure as actual arg

On Mon, Nov 14, 2016 at 06:21:06PM +0100, Janus Weil wrote: > 2016-11-14 16:10 GMT+01:00 Steve Kargl <s...@troutmask.apl.washington.edu>: > > On Mon, Nov 14, 2016 at 12:29:31PM +0100, Janus Weil wrote: > >> > After looking into this a little bit more, I found th

Re: [PATCH] PR fortran/78300 -- class procedure as actual arg

On Mon, Nov 14, 2016 at 12:29:31PM +0100, Janus Weil wrote: > > After looking into this a little bit more, I found that the culprit > > seems to be 'resolve_procedure_interface', which does not properly > > copy the 'class_ok' attribute. I propose the attached patch to fix > > this (regtesting

Re: [patch,libgfortran] PR51119 - MATMUL slow for large matrices

On Sun, Nov 13, 2016 at 04:08:50PM -0800, Jerry DeLisle wrote: > Hi all, > > Attached patch implements a fast blocked matrix multiply. The basic algorithm > is > derived from netlib.org tuned blas dgemm. See matmul.m4 for reference. > > The matmul() function is compiled with -Ofast

[PATCH] PR fortran/78300 -- class procedure as actual arg

The attach patch allows a procedure with a class result to be an actual argument to subprogram where the dummy argument expected to be a class. OK to commit? 2016-11-14 Steven G. Kargl PR fortran/78300 * resolve.c (resolve_fl_var_and_proc): Allow class

Re: [Patch, Fortran, OOP] PR 66366: ICE on invalid with non-allocatable CLASS variable

On Sat, Nov 12, 2016 at 09:13:26PM +0100, Janus Weil wrote: > > this patch fixes an ICE on invalid code involving class component > declarations. The ICE is avoided by moving forward the error check > from resolution to parsing stage. For class components this is > possible, because the

Re: [Patch, Fortran, F03] PR 77501: ICE in gfc_match_generic, at fortran/decl.c:9429

On Fri, Nov 11, 2016 at 03:05:06PM +0100, Janus Weil wrote: > 2016-11-11 14:38 GMT+01:00 Janus Weil : > > [Btw, speaking of gfc_get_tbp_symtree: Can anyone tell me by chance > > why it is necessary to nullify 'result->n.tb' on a newly-created > > symtree?] > > Removing the

Re: [Patch, Fortran, F03] PR 77501: ICE in gfc_match_generic, at fortran/decl.c:9429

On Fri, Nov 11, 2016 at 02:38:25PM +0100, Janus Weil wrote: > > 2016-11-11 Janus Weil > > PR fortran/77501 > * decl.c (gfc_match_decl_type_spec): Use gfc_get_tbp_symtree, > fix indentation. > (gfc_match_generic): Remove an unnecessary assert. > Use

Re: Prevent aliasing between arguments in calls to move_alloc

The attached fixes the problem and bootstraps/regtests. > > OK for trunk? > > Paul > > > On 5 November 2016 at 16:17, Steve Kargl > <s...@troutmask.apl.washington.edu> wrote: > > On Sat, Nov 05, 2016 at 10:05:30AM +0100, Paul Richard Thomas wrote: > >> &

Re: [Patch, Fortran, F03] PR77596: procedure pointer component with implicit interface can point to a function

On Tue, Nov 08, 2016 at 11:02:26AM +0100, Janus Weil wrote: > > here is a simple patch for the accepts-invalid problem of PR77596. > Regtests cleanly on x86_64-linux-gnu. Ok for trunk? > Yes. (and welcome back to the wonderful world of bugzilla). -- Steve

Re: Prevent aliasing between arguments in calls to move_alloc

On Sat, Nov 05, 2016 at 10:05:30AM +0100, Paul Richard Thomas wrote: > > Bootstraps and regtests on FC21/x86_64 - OK for trunk? OK with minor nit (see below). > > + /* F2003 12.4.1.7 */ > + if (to->expr_type == EXPR_VARIABLE && from->expr_type ==EXPR_VARIABLE Need a space after ==.

Re: [Patch, fortran] PR64933 - ASSOCIATE on a character variable does not allow substring expressions

On Fri, Nov 04, 2016 at 12:43:37PM +0100, Paul Richard Thomas wrote: > > The associate construct does not readily permit the identification of > the associate name as an array during parsing. However, this can be > done whilst matching rvalues within the associate block. This patch > extends this

Re: [Patch, fortran] PR54679 Erroneous "Expected P edit descriptor" in conjunction with L descriptor

On Sat, Oct 29, 2016 at 08:30:46PM -0700, Jerry DeLisle wrote: > > OK for trunk? > > 2016-10-29 Jerry DeLisle > > PR fortran/54679 > * io.c (check_format): Adjust checks for FMT_L to treat a zero > width as an extension, giving warnings or error as

Re: [PATCH, Fortran, v1] Restructure initialization of allocatable components

On Thu, Nov 03, 2016 at 02:16:48PM +0100, Andre Vehreschild wrote: > > Bootstraps and regtests fine on x86_64-linux/F23. Ok for trunk? > > @Dominique: Would you give it a go on your open patch collection? Maybe it > fixes one PR, but I am not very hopeful, because the patch is merely removing >

Re: [patch, fortran] Fix PR 69544

On Tue, Nov 01, 2016 at 11:58:10AM +0100, Thomas Koenig wrote: > > the attached, rather simple, patch, fixes a regression where > the locus was not set, leading to an ICE on a warning. > > Regression-tested on trunk. OK on all affected and open branches > (7/6/5)? > Yes. -- Steve

Re: [patch, libgfortran] Bug 78123 - Short reads with T edit descriptor not padding correctly

On Sun, Oct 30, 2016 at 01:21:41PM -0700, Jerry DeLisle wrote: > See patch below which is very simple. We were handling the case > where we tabbed left of current position in the record by clearing > the seen_eor flag. We were not handling the case where we tab > toward the right and so are still

Re: [patch, fortran] Fix PR 67219, erroneous warning

On Sun, Oct 30, 2016 at 05:32:52PM +0100, Thomas Koenig wrote: > > the regression in question was caused by issuing a conversion > warning for a complex constant too early, when the statement would be > rejected later. > > The solution is to throw away the warning if we do not find that > comma.

[Committed] PR fortran/71891 -- Fix obvious typo

I've committed the following to both 6-branch and trunk. 2016-10-28 Steven G. Kargl PR fortran/71891 * symbol.c (gfc_type_compatible): Fix typo. Index: symbol.c === --- symbol.c(revision

Re: [PATCH] Fix select type parsing (PR fortran/78026)

On Thu, Oct 27, 2016 at 09:07:49PM +0200, Jakub Jelinek wrote: > > This PR has been reported as something related to OpenMP, but in the end > I think it is unrelated, the bug I see is in the select type parsing. > > The problem is that if select type is the very first stmt in the TU, > we parse

[Committed] PF fortran/71895 -- remove assert

The following patch was committed to cure an ICE. The gcc_assert() is converted into an "if ()" condition where gfc_internal_error() is called. gfc_internal_error() allows gfortran to exit gracefully instead of an ICE, because gfortran has already isssued an error message. 2016-10-24 Steven G.

[Committed] PR fortran/77763 -- STRUCTURE in BLOCK DATA

I've committed the following patch. Both Oracle's manual and DVF's manual indicate that STRUCTURE can appear in a BLOCK DATA statement. While I was here, I sorted the case labels. 2016-10-23 Steven G. Kargl PR fortran/77763 * parse.c (parse_spec): Allow

Re: [PATCH] PR fortran/78033 -- This was a REAL pain

On Sat, Oct 22, 2016 at 08:55:46AM +0200, Paul Richard Thomas wrote: > > Thanks for persevering with this. The patch looks good to me. If it > has regtested OK, please feel free to commit. > The attached patch is the final version, which I just committed. 2016-10-23 Steven G. Kargl

Re: [PATCH] PR fortran/78033 -- This was a REAL pain

On Sat, Oct 22, 2016 at 02:22:47PM +0200, Dominique d'Humières wrote: > See comments in pr78033. What are the plans to handle pr54730? > Not sure what you mean. I certainly will not remove Mikael's checkpointing in the array constructor code, leaving array_constructor_43.f90 broken. -- Steve

[PATCH] PR fortran/78033 -- This was a REAL pain

All, The attached patch fixes PR fortran/78033. This was a REAL pain to fix because Fortran overloads REAL as an intrinsic type and an intrinsic subprogram. gfc_match_type_spec() in match.c is used to match Fortran 2003 type-specs in things like array constructors and TYPE IS statements. At

[COMMITTED] Fortran -- remove set, but unused variable.

Committed as "obvious". Index: ChangeLog === --- ChangeLog (revision 241387) +++ ChangeLog (working copy) @@ -1,3 +1,8 @@ +2016-10-20 Steven G. Kargl + + * array.c (gfc_match_array_constructor): Remove

Re: [patch, fortran] PR77828 Linking gfortran-7 compiled program with libgfortran of 5.x allowed but crashes

I haven't had time to test the patch. I don't see off hand anything wrong the patch. But, as you've seen in bugzilla recent IO work has caused some problem for a few archs. You'll probably need to keep an eye open for new issues. -- steve On Thu, Oct 20, 2016 at 12:32:38PM -0700, Jerry

Re: [patch, gfortran] PR48298 DTIO, implement size=

On Mon, Oct 17, 2016 at 06:02:52PM -0700, Jerry DeLisle wrote: > Hi all, > > The attached patch enables the size= specifier in a READ statement to work > with > child DTIO procedures. This is accomplished by moving the size_used variable > from the dtp structure to the gfc_unit structure so

Re: [PATCH] PR fortran/77978 -- STOP code fixes

On Fri, Oct 14, 2016 at 05:24:53PM -0700, Steve Kargl wrote: > For the code > > program foo > stop merge(667, 668, .true.) > end > > gfortran with either -std=f95 or -std=f2003 should reject > this code. My patch does not fix this issue, because it > w

[PATCH] PR fortran/77978 -- STOP code fixes

The attach patch fixes a number of shortcomings with STOP codes in gfortran. The updated comment in the code nicely summarizes the problem. /* Match a number or character constant after an (ERROR) STOP or PAUSE - statement. */ + statement. The requirements for a stop-code differs in the

Re: [patch, fortran] PR77972 ICE on broken character continuation with -Wall etc.

On Thu, Oct 13, 2016 at 07:04:04PM -0700, Jerry DeLisle wrote: > This patch is straight forward. We were sending bogus locus info to the > diagnostics machinery and catch an assert in error,c. > > The patch avoids doing this. > > Regression tested on x86-64-linux. > > OK for trunk? > Yes,

Re: PING! [Fortran, Patch, PR72832, v1] [6/7 Regression] [OOP] ALLOCATE with SOURCE fails to allocate requested dimensions

On Wed, Oct 12, 2016 at 11:50:10AM +0200, Andre Vehreschild wrote: > Ping! > > Updated patch with the comments gotten so far. > > Ok for trunk? > Looks good to me. -- Steve

[Committed] PR fortran/77942 -- test for zero

Committed to 6-branch and trunk. 2016-10-11 Steven G. Kargl PR fortran/77942 * simplify.c (gfc_simplify_cshift): Check for zero. 2016-10-11 Steven G. Kargl PR fortran/77942 * gfortran.dg/pr77942.f90 Index:

Re: [PATCH] Fix formatting of the -fdec-math changes

On Tue, Oct 11, 2016 at 09:00:54PM +0200, Jakub Jelinek wrote: > On Tue, Oct 11, 2016 at 02:47:34PM -0400, Fritz Reese wrote: > > On Tue, Oct 11, 2016 at 2:44 PM, Fritz Reese wrote: > > > On Mon, 2016-10-11 08:43 AM, Markus Trippelsdorf > > >

Re: PING! Re: [PATCH, Fortran] Extension: COTAN and degree-valued trig intrinsics with -fdec-math

On Tue, Oct 11, 2016 at 11:10:13AM -0700, Jerry DeLisle wrote: > @@ -1782,6 +1784,7 @@ radians_f (mpfr_t x, mp_rnd_t rnd_mode) > mpfr_div_d (x, x, 180.0, rnd_mode); > I forgot to point out that the above should changed to mpfr_div_ui (x, x, 180, rnd_mode); In fact, any place where

Re: PING! Re: [PATCH, Fortran] Extension: COTAN and degree-valued trig intrinsics with -fdec-math

On Tue, Oct 11, 2016 at 11:10:13AM -0700, Jerry DeLisle wrote: > > diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c > index bf60f747..18135d2f 100644 > --- a/gcc/fortran/simplify.c > +++ b/gcc/fortran/simplify.c > @@ -1768,11 +1768,13 @@ degrees_f (mpfr_t x, mp_rnd_t rnd_mode) >

Re: PING! Re: [PATCH, Fortran] Extension: COTAN and degree-valued trig intrinsics with -fdec-math

On Mon, Oct 10, 2016 at 12:29:32PM -0700, Jerry DeLisle wrote: > On 10/10/2016 08:06 AM, Fritz Reese wrote: > > https://gcc.gnu.org/ml/fortran/2016-09/msg00163.html [original] > > https://gcc.gnu.org/ml/fortran/2016-09/msg00183.html [latest] > > > > On Wed, Sep 28, 2016 at 4:14 PM, Fritz Reese

Re: Fix ICE due to map typespecs with different sized charlens being copied

On Wed, Oct 05, 2016 at 04:40:50PM -0400, Fritz Reese wrote: > When union type symbols are compared and they contain maps containing > characters with different lengths, their type symbols should have > different backend declarations otherwise the gimple tree explodes. > Strangely enough the

Re: Possible patch for fortran/57910

On Thu, Oct 06, 2016 at 07:04:36PM +0200, Dominique d'Humières wrote: > Dear Louis, > > > PR fortran/57910 > > * trans-expr.c (gfc_add_interface_mapping): Don't try to > > dereference call-by-value scalar argument. > > > > The patch seems to work without breaking other tests. > >From the patch, I

Re: [PATCH] PR fortran/58991 and fortran/58992

On Tue, Sep 27, 2016 at 11:45:35AM -0700, Steve Kargl wrote: > > 2016-09-27 Steven G. Kargl <kar...@gcc.gnu.org> > > PR fortran/58991 > PR fortran/58992 > * resolve.c (resolve_assoc_var): Fix CHARACTER type-spec for a >

[PATCH] Backport of 25 fortran patches

The attached patch and ChangeLog entries are for the backporting of 25 patches from trunk to the 6-branch. The bugzilla PR's contained in the patch are fortran/41922 fortran/60774 fortran/61318 fortran/68566 fortran/69514 fortran/69867 fortran/69962 fortran/70006 fortran/71067 fortran/71730

Re: [PATCH, Fortran] Extension: COTAN and degree-valued trig intrinsics with -fdec-math

On Mon, Sep 26, 2016 at 10:01:27AM -0400, Fritz Reese wrote: > > Attached is a patch extending the GNU Fortran front-end to support > some additional math intrinsics, enabled with a new compile flag > -fdec-math. The flag adds the COTAN intrinsic (cotangent), as well as > degree versions of all

Re: [patch, libgfortran] PR77707 formatted direct access: nextrec off by one

On Tue, Sep 27, 2016 at 10:15:40PM -0700, Jerry DeLisle wrote: > I plan to commit the attached patch in the next few days. Fairly simple. > > Regression tested on x86-64. > Looks ok to me. -- Steve

[PATCH] PR fortran/58991 and fortran/58992

The attached patch fixes both PR fortran/58991 and fortran/58992. The issue was that for a CHARACTER expression or variable as a selector in an ASSOCIATE statement, the type-spec was incomplete. That is, the actual length of the string was not set. The patch rectifies the problem (at least in my

[Committed] PR fortran/77420

This is a follow-up commit to really fix PR fortran/77420. The code has been in my tree for 2 weeks and has passed numerous regression tests. 2016-09-26 Steven G. Kargl PR fortran/77420 * trans-common.c: Handle array elements in equivalence when the

[Committed] PR fortran/77429

Committed as obvious. 2016-09-25 Steven G. Kargl PR fortran/77429 * dependency.c (gfc_check_dependency): Convert gcc_assert() to a conditional and possible call to gfc_internal_error(). 2016-09-25 Steven G. Kargl PR

[Committed] PR fortran/77694

Committed as "obvious" even though thomas OK patch in bugzilla audit trail. 2016-09-25 Steven G. Kargl PR fortran/77694 * frontend-passes.c (optimize_binop_array_assignment): Check pointer for NULL. 2016-09-25 Steven G. Kargl

Re: [Patch, fortran] Initializing components of derived type variables

On Fri, Mar 04, 2016 at 11:42:48AM -0500, Fritz Reese wrote: > > Here I propose a patch to gfortran which allows initializing > components of derived type variables with a new compile flag. > > Currently the options -finit-integer=, -finit-real=, -finit-logical=, > and -finit-character= are

[Committed] Fix PR fortran/77612

I've committed the following patch. 2016-09-16 Steven G. Kargl PR fortran/77612 * decl.c (char_len_param_value): Check parent namespace for seen_implicit_none. 2016-09-16 Steven G. Kargl PR fortran/77612 *

[PATCH] PR fortran/77420 -- take two

The attached patch appears to fix PR fortran/77420 without causing regressions. The problem raised by Andrew Benson at https://gcc.gnu.org/ml/fortran/2016-09/msg00039.html contained in pr77420_3.f90 and pr77420_4.f90. The original testcase from the PR is in pr77420_1.f90 and a variation on that

Re: [PATCH, updated] Add a warning for suspicious use of conditional expressions in boolean context

On Wed, Sep 14, 2016 at 04:10:46PM +, Bernd Edlinger wrote: > > fortran: > 2016-09-14 Bernd Edlinger > > PR c++/77434 > * simplify.c (gfc_simplify_repeat): Fix a warning. > > Index: gcc/fortran/simplify.c >

[Committed] PR fortran/77420 -- revert previous commit

I've reverted my previous fix for PR fortran/77420. It was causing a regression that could, in principle, effect a significant nubmer of gfortran users. 2016-09-13 Steven G. Kargl PR fortran/77420 * module.c (load_equiv): Revert revision 240063.

Re: [PATCH] PR fortran/77507

On Sat, Sep 10, 2016 at 08:04:40PM +0200, Andreas Schwab wrote: > FAIL: gfortran.dg/pr77507.f90 -O (test for excess errors) > Excess errors: > /opt/gcc/gcc-20160910/gcc/testsuite/gfortran.dg/pr77507.f90:3:6: Fatal Error: > Can't open module file 'ieee_arithmetic.mod' for reading at (1): No

Re: [PATCH] PR fortran/77507

On Sat, Sep 10, 2016 at 09:03:16AM +0200, Andreas Schwab wrote: > FAIL: gfortran.dg/c_assoc_2.f03 -O (test for errors, line 23) > Sorry about that. Seems I forgot to check-in the updated testcases with r240050. Should be fixed now. -- Steve

[Committed] PR fortran/77420

I've committed the following patch. It restores gfortran's behavior prior to my commit r224159 if the current namespace has an empty equivalent list. 2016-09-09 Steven G. Kargl PR fortran/77420 * module.c (load_equiv): If the current namespace has a list of

[PATCH] PR fortran/77429

The following patch fixes an ICE due to a gcc_assert() firing. As everyone here knows, gfortran runs a series a matchers during parsing. If a matcher fails, it often queuesi/reports an error message and returns, which allows other matchers to run. If a match is successful, a queued error

Re: [PATCH] PR fortran/77406

On Wed, Aug 31, 2016 at 05:14:43PM -0700, Steve Kargl wrote: > > 2016-09-03 Steven G. Kargl <ka...@gcc.gnu.org> > > PR fortran/77406 > * interface.c (gfc_compare_interfaces): Fix detection of ambiguous > interface involving alternate return. &

[PATCH] PR fortran/77506

Regression tested on x86_64-*-freebsd. OK to commit? 2016-09-08 Steven G. Kargl PR fortran/77506 * array.c (gfc_match_array_constructor): CHARACTER(len=*) cannot appear in an array constructor. 2016-09-08 Steven G. Kargl

[PATCH] PR fortran/77507

The attached patch fixes issues with using keywords with the IEEE_VALUE and C_ASSOCIATED intrinsic routines. Regression tested on x86_64-*-freebsd. OK to commit? 2016-09-08 Steven G. Kargl PR fortran/77507 * intrinsic.c (add_functions): Use correct

[Committed] PR fortran/69514

I've committed the attached patch to trunk after completing regression testing on x86_64-*-freebsd. 2016-09-08 Steven G. Kargl PR fortran/69514 * array.c (gfc_match_array_constructor): If type-spec is present, walk the array constructor performing

[PATCH] PR fortran/77460

I plan to commit the following patch in the next day or two. Objections? 2016-09-03 Steven G. Kargl PR fortran/77460 * simplify.c (simplify_transformation_to_scalar): On error, result may be NULL, simply return. 2016-09-03 Steven G. Kargl

[PATCH] PR fortran/77406

Consider the code interface s subroutine foo(*) end subroutine foo subroutine bar(*) end subroutine bar end interface s end gfortran currently ICE's, because she is ill-prepared to deal with alternate returns in an interface blocks. The attached patch fixes this

Re: [PATCH] PR fortran/77372

On Mon, Aug 29, 2016 at 11:10:41AM +0200, Andreas Schwab wrote: > On Aug 26 2016, Steve Kargl <s...@troutmask.apl.washington.edu> wrote: > > > 2016-08-25 Steven G. Kargl <ka...@gcc.gnu.org> > > > > PR fortran/77372 > > gfortran.dg/pr77372.f90: Ne

Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer

On Fri, Aug 26, 2016 at 10:28:25PM +0200, Mikael Morin wrote: > Hello, > > Le 26/08/2016 à 20:27, Steve Kargl a écrit : > > Here are two possible patches for PR fortran/77391. The first > > patch treats the invalid code as a GNU Fortran extension as > > gfortran curre

Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer

On Fri, Aug 26, 2016 at 10:28:25PM +0200, Mikael Morin wrote: > Hello, > > Le 26/08/2016 à 20:27, Steve Kargl a écrit : > > Here are two possible patches for PR fortran/77391. The first > > patch treats the invalid code as a GNU Fortran extension as > > gfortran curre

Re: [PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer

On Fri, Aug 26, 2016 at 10:28:25PM +0200, Mikael Morin wrote: > Hello, > > Le 26/08/2016 à 20:27, Steve Kargl a écrit : > > Here are two possible patches for PR fortran/77391. The first > > patch treats the invalid code as a GNU Fortran extension as > > gfortran curre

[PATCH(es)] PR fortran/77391 -- RFC vote on which you prefer

Here are two possible patches for PR fortran/77391. The first patch treats the invalid code as a GNU Fortran extension as gfortran current accepts the invalid code. The second patch enforces the standard. As I think gfortran should encourage standard conformance, I am inclined to commit the

[PATCH] PR fortran/77380

I plan to commit the following patch on Saturday if no one objects in the next 40 or so hours. 2016-08-25 Steven G. Kargl PR fortran/77380 * dependency.c (gfc_check_dependency): Do not assert with -fcoarray=lib. 2016-08-25 Steven G. Kargl

[PATCH] PR fortran/77372

I plan to commit the following patch on Saturday if no one objects in the next 40 or so hours. 2016-08-25 Steven G. Kargl PR fortran/77372 simplify.c (simplify_ieee_selected_real_kind): Check for NULL pointers. 2016-08-25 Steven G. Kargl

[Committed] PR fortran/77351

I've committed the following patch. tkoenig approved it in bugzilla. 2016-08-25 Steven g. Kargl PR fortran/77351 * frontend-passes.c (remove_trim,combine_array_constructor): Check for NULL pointer. 2016-08-25 Steven g. Kargl

[PR fortran/60774] Patch

If no one objects, I would like to commit the following patch on Saturday. Note, Bud Davis found the location of the problem for free-form code and proposed a fixed. I've modified his proposed patch and applied a similar change for fixed-form. Previously, gfortran would issue a warning and

[PR fortran/61318] Patch

I intend to commit the following patch on Saturday. It improves the reporting on where an error occurs. Without the patch, one gets % gfc7 -c gcc/testsuite/gfortran.dg/pr61318.f90 gcc/testsuite/gfortran.dg/pr61318.f90:19:6: use gbl_message 1 Error: Type mismatch in argument 'message'

[PR fortran/77260] Patch

If no one objects before Saturday, I will commit the following patch. 2016-08-20 Steven G. Kargl PR fortran/77260 * trans-decl.c(generate_local_decl): Suppress warning for unused variable if symbol is entry point. 2016-08-20 Steven G. Kargl

PR fortran/41922 -- Patch

The attached patch has been built and tested on x86_64-*-freebsd. There are no regression in the testing. OK to commit? 2016-07-30 Steven G. Kargl PR fortran/41922 * target-memory.c (expr_to_char): Pass in locus and use it in error messages.

[Committed] PR fortran/68566

I've committed the following patch. 2016-07-30 Steven G. Kargl PR fortran/68566 * check.c (gfc_check_reshape): Check for constant expression. 2016-07-30 Steven G. Kargl PR fortran/68566 * gfortran.dg/pr68566.f90: new

PR fortran/69867 -- Patch

Unless someone speaks up, I will commit the following patch as obvious. 2016-07-29 Steven G. Kargl PR fortran/69867 * decl.c (build_struct): Ensure that pointers point to something. 2016-07-29 Steven G. Kargl PR fortran/69867

PR fortran/69962 -- Patch

I intend to commit the following patch unless someone speaks up before sometime tomorrow (i.e, Saturday). 2016-07-29 Steven G. Kargl PR fortran/69962 * decl.c (gfc_set_constant_character_len): if expr is not constant issue an error instead of an

PR fortran/70006 -- Patch

I intend to commit this patch in the next day or two unless someone objects. 2016-07-28 Steven G. Kargl PR fortran/70006 * io.c (gfc_resolve_dt): Use correct locus. * resolve.c (resolve_branch): Ditto. 2016-07-28 Steven G. Kargl

[Committed] PR fortran/71067 -- set a pointer to NULL

Committed as obvious. 2016-07-28 Steven G. Kargl PR fortran/71067 * decl.c (match_data_constant): On error, set 'result' to NULL. 2016-07-28 Steven G. Kargl PR fortran/71067 * gfortran.dg/pr71067_1.f90: New test.

PR fortran/71730 -- Patch

I plan to commit the following patch in the next day or two if no one objects. It falls into the trivially correct category. 2016-07-28 Steven G. Kargl PR fortran/71730 * decl.c (match_data_constant): Set 'result' to NULL in error case.

PR fortran/71799 -- Patch

Probably committable under trivially correct. OK? 2016-07-22 Steven G. Kargl PR fortran/71799 * resolve.c(gfc_resolve_iterator): Failure of type conversion need not ICE. 2016-07-22 Steven G. Kargl PR fortran/71799

PR fortran/71859 -- Patch

Patch is self-explanatory. OK? 2016-07-26 Steven G. Kargl PR fortran/71859 * check.c(numeric_check): Prevent ICE. Issue error for invalid subroutine as an actual argument when numeric argument is expected. 2016-07-26 Steven G. Kargl

[PR fortran/71859] Patch

I intend to commit the following patch in approximately 2 * exp(1.) = 5.436 hours. 2016-07-22 Steven G. Kargl PR fortran/71859 * check.c(numeric_check): Prevent ICE. Issue error for invalid subroutine as an actual argument when numeric argument is

[PR fortran/71862] Patch

I intend to commit the following patch and close the PR in approximate 6.283 hours. 2016-07-22 Steven G. Kargl PR fortran/71862 * class.c: Remove assert. Iterate over component only if non-null. 2016-07-22 Steven G. Kargl

[Committed] PR fortran/71935

I've committed the following patch under "obviously correct." 2016-07-22 Steven G. Kargl PR fortran/71935 * check.c (is_c_interoperable): Simplify right expression. 2016-07-22 Steven G. Kargl PR fortran/71935 *

PR fortran/29819 -- fix committed.

Committed as obvious. 2016-07-14 Steven G. Kargl PR fortran/29819 * parse.c (parse_contained): Use proper locus. 2016-07-14 Steven G. Kargl PR fortran/29819 * gfortran.dg/bind_c_usage_9.f03: Move dg-error. *

PR fortran/68426 -- committed

2016-07-08 Steven G. Kargl PR fortran/68426 * simplify (gfc_simplify_spread): Adjust locus. Index: simplify.c === --- simplify.c (revision 238178) +++ simplify.c (working copy) @@ -6183,8

Fortran patch committed [revision 235999]

I have committed a patch for PR fortran/56226. The diff is available as an attachment in the bugzilla PR. Details about the patch can be found here: https://gcc.gnu.org/ml/fortran/2016-03/msg2.html -- Steve

Re: [PATCH] PR47040 - Make error message for empty array constructor more helpful/correct

On Sat, Apr 09, 2016 at 06:51:50PM +0200, Dominique d'Humières wrote: > > > > > It is valid syntax because of > > > > "An empty sequence forms a zero-sized rank-one array." > > > > It seems that J3 saw the error in their ways as (/ /) is clearly > > an empty array constructor, and fixed the

Re: [PATCH] PR47040 - Make error message for empty array constructor more helpful/correct

On Sat, Apr 09, 2016 at 05:56:12PM +0200, Dominique d'Humières wrote: > > > (/ /) is valid Fortran 95 syntax > > ... > > > > program foo > > call bar((/ /)) > > end program foo > > > > % gfc -c -std=f95 foo.f90 > > foo.f90:2:17: > > > >call bar((/ /)) > > 1 > > Error:

Re: [PATCH] PR47040 - Make error message for empty array constructor more helpful/correct

> it be back ported to the gcc-5 branch? > >>> > >>> No and No. > > Le 7 avr. 2016 à 15:59, Steve Kargl <s...@troutmask.apl.washington.edu> a > > écrit : > > > > The latter is obvious as this "fixes" neither a regression > > nor documentation.

Re: [PATCH] PR47040 - Make error message for empty array constructor more helpful/correct

The latter is obvious as this "fixes" neither a regression nor documentation. For the former, see Fortran 95, section 4.5. -- steve On Thu, Apr 07, 2016 at 07:51:14AM +0200, Dominique d'Humières wrote: > Could you please elaborate. > > Dominique > > > Le 7 avr.

Re: [PATCH] PR47040 - Make error message for empty array constructor more helpful/correct

On Wed, Apr 06, 2016 at 05:44:55PM +0200, Dominique d'Humières wrote: > Is the following patch OK (regtested on x86_64-apple-darwin15)? Should it be > back ported to the gcc-5 branch? No and No. -- Steve

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

On Thu, Dec 31, 2015 at 09:57:10PM +0800, Gerald Pfeifer wrote: > On Sat, 21 Nov 2015, Steve Kargl wrote: > > 2015-11-21 Steven G. Kargl <ka...@gcc.gnu.org> > > > > * simplify.c (gfc_simplify_cshift): Work around bootstrap issues > > due to inappropria

Re: [PATCH, RFC, gfortran] Multi-threaded random number generator

On Thu, Dec 24, 2015 at 04:53:30PM +0200, Janne Blomqvist wrote: > On Thu, Dec 24, 2015 at 1:18 AM, Steve Kargl > <s...@troutmask.apl.washington.edu> wrote: > > On Thu, Dec 24, 2015 at 12:29:02AM +0200, Janne Blomqvist wrote: > >> > >> the GFortran ra

Re: [PATCH, RFC, gfortran] Multi-threaded random number generator

On Thu, Dec 24, 2015 at 12:29:02AM +0200, Janne Blomqvist wrote: > > the GFortran random number generator (RANDOM_NUMBER and RANDOM_SEED > intrinsics) has a number of issues that the attached preliminary patch > tries to address. > First, I think your effort to retool random numbers is a nice

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

On Fri, Dec 18, 2015 at 07:12:47PM +0100, Paul Richard Thomas wrote: > > I have just applied the patch to 5 branch and have found that, apart > from two minor tweaks in trans.c, all was well. It bootstrapped > and regtested fine, apart from deferred_character_2.f90. In this > latter, deferred

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

On Thu, Dec 17, 2015 at 01:22:06PM +0100, Alessandro Fanfarillo wrote: > > I've noticed that this patch has been applied only on trunk and not on > the gcc-5-branch. Is it a problem to include EVENTS in gcc-5? > No problem. When I applied the EVENTS patch to trunk, the 5.3 release was being

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

On Thu, Dec 17, 2015 at 11:12:17PM +0100, Paul Richard Thomas wrote: > > Some problems have come up that are not dissimilar to the original > bug, involving infinite recursion with procedure components, with the > same type as the containing type. The fix is verging on the trivial. > However,

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