Is there any particular reason that include line continuation is
isolated in -fdec-include? Is there a specific restriction regarding
include lines in the Fortran standard such that continuations in free
form and fixed form can't be used with include lines?
regards,
Mark Eggleston
On 12/11/2018
..4dd34082b97a
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/pr87919-dec-structure-1.f
@@ -0,0 +1,21 @@
+! { dg-do compile }
+!
+! PR/fortran/87919
+!
+! Should fail to compile without the -fdec or -fdec-structure options
+!
+! Contributed by Mark Eggleston
+
+ program test
+
+structure /info
On 12/12/2018 12:06, Mark Eggleston wrote:
I'm about to build the compiler with
memset (buffer, 0x20, buffer_size);
instead of
memset (buffer, (flag_dec_pad_with_spaces ? 0x20 : 0x0), buffer_size);
and will check again, if necessary a padding variable can be used
instead initially set
Before delving into the code to make changes to handle the case when
passing a variable into transfer instead of a literal I revised the the
test cases. The results indicate to me that this patch as originally
intended is erroneous.
When a character literal is assigned to character variable
On 12/12/2018 11:52, Jakub Jelinek wrote:
What about:
integer(kind=2) :: a
a = -1
print *, transfer (1_2, 1_8), transfer (a, 1_8)
end
?
I assume you meant transfer (-1_2, 1_8), the result from gfortran is
65535 for both transfers.
I'm about to build the compiler with
memset
to commit the change if it is acceptable.
There are several more patches to support legacy Fortran which will be
sent in order.
regards,
Mark Eggleston
--
https://www.codethink.co.uk/privacy.html
>From de02d8bbab91a87c30672d1a9e1c3ecc95b800f7 Mon Sep 17 00:00:00 2001
From: Jim MacArthur
Date:
On 12/11/2018 20:28, Fritz Reese wrote:
Attached is the latest version, which builds and regtests cleanly on
x86_64-redhat-linux. OK for trunk, 7-branch, and 8-branch?
I'm currently using this patch (pending it being committed) and have
some pending patches that use it.
I can use the old
On 04/12/2018 17:04, Fritz Reese wrote:
On Tue, Dec 4, 2018 at 10:12 AM Jakub Jelinek wrote:
Just a couple of random comments.
-fdec-pad-with-spaces option name doesn't look right, because it doesn't say
what the option affects. So perhaps have transfer in the option name?
[...]
Wouldn't
On 04/12/2018 15:11, Jakub Jelinek wrote:
On Tue, Dec 04, 2018 at 02:47:25PM +, Mark Eggleston wrote:
Here is a patch to considered for incorporation into gfortran adding to its
legacy support. It pads character to integer conversions using spaces
instead of zeros when enabled.
The pad
On 06/12/2018 10:33, Jakub Jelinek wrote:
On Wed, Dec 05, 2018 at 06:27:00PM -0800, Jerry DeLisle wrote:
I disagree completely. I assume the idea of -fdec-pad-with-spaces is to
accomodate some old dec fortran code. The only reason to use some other
character is if someone is writing new dec
On 06/12/2018 10:20, Mark Eggleston wrote:
Yes. Mark, you'll need to also patch iresolve.c (gfc_resolve_transfer)
to affect non-constant resolution.
Thanks for the hint.
I've looked at gfc_resolve_transfer regarding handling of padding when a
character variable is passed to transfer
Enabling of -fdec-include is missing from list of options enabled by
-fdec. When rendered as a PDF some lines are too long in the list of
options controlling Fortran dialect and in the list of options to
request or suppress errors and warnings.
=89348
gcc/fortran/ChangeLog:
2019-02-14 Mark Eggleston
PR fortran/89348
* invoke.texi: Lines too long for PDF in option lists. Add
-fdec-include to list of options enabled by -fdec.
OK for trunk? I do not have commit access.
regards, Mark
--
https://www.codethink.co.uk/privacy.html
access to svn.
regards,
Mark
--
https://www.codethink.co.uk/privacy.html
>From f722d946230613894f7f91103494b0078319fe29 Mon Sep 17 00:00:00 2001
From: Mark Eggleston
Date: Thu, 31 Jan 2019 13:36:48 +
Subject: [PATCH 1/3] Intrinsic sign and GNU extension.
The intrinsic sign has the s
On 10/06/2019 15:10, Mark Eggleston wrote:
On 10/06/2019 15:07, Thomas Koenig wrote:
Am 10.06.19 um 15:33 schrieb Mark Eggleston:
This patch is for a customer that has a huge codebase and that is
the only reason for its existence.
I didn't know gfortran as a whole has customers
On 12/06/2019 19:11, Steve Kargl wrote:
On Tue, Jun 11, 2019 at 11:50:40AM +0200, Jakub Jelinek wrote:
On Tue, Jun 11, 2019 at 10:30:59AM +0100, Mark Eggleston wrote:
Jim MacArthur
Mark Eggleston
Two spaces before < instead of one.
This is not a patch review, just comme
On 25/06/2019 00:17, Jeff Law wrote:
On 6/24/19 2:19 AM, Bernhard Reutner-Fischer wrote:
On Fri, 21 Jun 2019 07:10:11 -0700
Steve Kargl wrote:
On Fri, Jun 21, 2019 at 02:31:51PM +0100, Mark Eggleston wrote:
Currently variables with the AUTOMATIC attribute can not appear in an
EQUIVALENCE
Mark Eggleston
* gfortran.h: Add check_conflict declaration.
* symbol.c (check_conflict): Remove automatic in equivalence conflict
check.
* symbol.c (save_symbol): Add check for in equivalence to stop the
the save attribute being added.
* trans-common.c (build_equiv_decl
On 24/06/2019 09:19, Bernhard Reutner-Fischer wrote:
On Fri, 21 Jun 2019 07:10:11 -0700
Steve Kargl wrote:
On Fri, Jun 21, 2019 at 02:31:51PM +0100, Mark Eggleston wrote:
Currently variables with the AUTOMATIC attribute can not appear in an
EQUIVALENCE statement. However its counterpart
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89100 see comment 4
Please can someone commit the attached patch as I do not have commit rights.
Change logs:
For gcc/fortran
Jeff Law
Mark Eggleston
PR fortran/89100
* gfortran.texi: Add Default widths for F, G and I format
examples along with other minor changes.
I do not have commit privileges so someone else will have to commit this:
For the change log:
Mark Eggleston
* gfortran.texi: Remove reference to the ASSIGN statement, capitalise
complex, state that padding is with spaces and modify
On 13/05/2019 10:45, Mark Eggleston wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89100 see comment 4
Please can someone commit the attached patch as I do not have commit
rights.
Change logs:
For gcc/fortran
Jeff Law
Mark Eggleston
PR fortran/89100
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89103 see comment 4
Please can some one commit the attached patch for me as I do not have
the privileges to do so.
Change logs:
gcc/fortran
Jim MacArthur
Mark Eggleston
PR fortran/89103
* gfortran.texi: Add -fdec-blank-format
On 23/05/2019 11:38, Christophe Lyon wrote:
On Wed, 22 May 2019 at 13:57, Janne Blomqvist wrote:
On Wed, May 22, 2019 at 10:58 AM Mark Eggleston
wrote:
On 13/05/2019 10:45, Mark Eggleston wrote:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89100 see comment 4
Please can someone commit
On 24/05/2019 10:06, Christophe Lyon wrote:
On Thu, 23 May 2019 at 19:21, Steve Kargl
wrote:
On Thu, May 23, 2019 at 05:26:53PM +0200, Christophe Lyon wrote:
On Thu, 23 May 2019 at 15:54, Mark Eggleston
wrote:
The logs contain:
/gcc/testsuite/gfortran.dg/fmt_f_default_field_width_1.f90:15
without
REAL(16).
Change logs:
gcc/fortran
Mark Eggleston
PR fortran/89286
* check.c (gfc_check_sign): Deleted.
* intrinsic.c (add_functions): Call add_sym_2 with gfc_check_a_p
instead of gfc_check_sign for "sign".
* intrinsic.h: Remove declaration of gfc_
On 10/07/2019 17:20, Bernhard Reutner-Fischer wrote:
On 10 July 2019 17:52:40 CEST, Steve Kargl
wrote:
On Wed, Jul 10, 2019 at 02:50:47PM +0100, Mark Eggleston wrote:
The attached patch treats the intrinsic SIGN in the same way as MOD
and
DIM as it has the same arguments.
Tested using
On 25/06/2019 14:17, Mark Eggleston wrote:
On 25/06/2019 00:17, Jeff Law wrote:
On 6/24/19 2:19 AM, Bernhard Reutner-Fischer wrote:
On Fri, 21 Jun 2019 07:10:11 -0700
Steve Kargl wrote:
On Fri, Jun 21, 2019 at 02:31:51PM +0100, Mark Eggleston wrote:
Currently variables with the AUTOMATIC
**ping**
On 01/07/2019 10:35, Mark Eggleston wrote:
On 25/06/2019 14:17, Mark Eggleston wrote:
On 25/06/2019 00:17, Jeff Law wrote:
On 6/24/19 2:19 AM, Bernhard Reutner-Fischer wrote:
On Fri, 21 Jun 2019 07:10:11 -0700
Steve Kargl wrote:
On Fri, Jun 21, 2019 at 02:31:51PM +0100, Mark
documents.
OK to commit?
ChangeLog:
gcc/fortran
Mark Eggleston
* gfortran.texi: Delete paragraph about integer overload errors
when initialising integer variables with BOZ constants as these
no longer occur.
--
https://www.codethink.co.uk/privacy.html
>F
On 14/08/2019 18:10, Jeff Law wrote:
On 8/14/19 2:45 AM, Mark Eggleston wrote:
I now have commit access.
gcc/fortran
Jeff Law
Mark Eggleston
* gfortran.h: Add gfc_check_conflict declaration.
* symbol.c (check_conflict): Rename cfg_check_conflict and remove
static
I now have commit access.
gcc/fortran
Jeff Law
Mark Eggleston
* gfortran.h: Add gfc_check_conflict declaration.
* symbol.c (check_conflict): Rename cfg_check_conflict and remove
static.
* symbol.c (cfg_check_conflict): Remove automatic in equivalence
conflict
Edlinger
Phil Edwards
+Mark Eggleston
Steve Ellcey
Mohan Embar
Revital Eres
Eggleston
PR fortran/89236
* intrinsic.texi: Add GNU extension notes to DIM, MOD, MODULO.
--
https://www.codethink.co.uk/privacy.html
>From 4e527390271f8002f37b33262bd4b4f90ad2062a Mon Sep 17 00:00:00 2001
From: Mark Eggleston
Date: Tue, 5 Feb 2019 16:38:10 +
Subject: [PATCH] Intrin
On 16/08/2019 15:55, Steve Kargl wrote:
On Fri, Aug 16, 2019 at 03:25:03PM +0100, Mark Eggleston wrote:
In section 6.1.10 BOZ literal constants of the gfortran manual
(gfortran.pdf) the final paragraph refers to integer overflow error. As
a result of Steve Kargl's work on BOZ constants
d is a bit of kludge any pointers
regarding a better solution will be appreciated.
The patch including test cases is attached.
ChangeLogs:
gcc/fortran
Mark Eggleston
* arith.c (gfc_arith_concat): Set length field in typespec.
* expr.c (gfc_get_character_expr): Set leng
On 13/09/2019 07:54, Janne Blomqvist wrote:
On Mon, Sep 9, 2019 at 4:52 PM Mark Eggleston
wrote:
To work around these problems I added a new length field to gfc_typespec
to used to produce the name of a character type if the character length
structure is not present.
The addition
plit into 2 or 3 bug reports.
The trunk compiler was built on x86_64 hardware using code from
Subversion revision 274157.
regards,
Mark Eggleston
On 24/07/2019 00:05, Steve Kargl wrote:
I've committed the attached patch as a follow-up to
the recent BOZ (r273747). It removes a few lefto
On 07/08/2019 19:56, Steve Kargl wrote:
On Wed, Aug 07, 2019 at 09:09:49AM -0700, Steve Kargl wrote:
On Wed, Aug 07, 2019 at 01:58:17PM +0100, Mark Eggleston wrote:
DATA statements for logical and character variable compile but do not work:
program test
character(4) :: c
data c / z
On 07/08/2019 17:09, Steve Kargl wrote:
On Wed, Aug 07, 2019 at 01:58:17PM +0100, Mark Eggleston wrote:
BOZ problems in the following areas
* use of logical and character variables with BOZ constants
* comparisons with BOZ constants
* DATA statements
Comparing 9.1 and trunk
/fortran
Mark Eggleston
* array.c (check_element_type): Call gfc_typename with the gfc_expr
"expr" instead of its gfc_typespec "ts".
* check.c (gfc_check_co_reduce): Call gfc_typename with the gfc_expr
"a" instead of its gfc_typespec "t
a new option,
-Woverwrite-recursive, initialised to on.
I don't have a test case for this as I don't know how to test for a
warning that isn't related to a line of code.
It is a very simple patch, can the test case be omitted?
ChangeLog
gcc/fortran
Mark Eggleston
* lang.opt: Add
Original thread starts here
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01185.html
OK to commit?
gcc/fortran/ChangeLog
Mark Eggleston
* invoke.texi: Add -Wno-overwrite-recursive to list of options. Add
description of -Wno-overwrite-recursive. Fix typo in description
On 20/09/2019 07:46, Bernhard Reutner-Fischer wrote:
On Thu, 19 Sep 2019 17:46:29 +0200
Tobias Burnus wrote:
Hi Mark,
On 9/19/19 3:40 PM, Mark Eggleston wrote:
The following warning is produced when -fno-automatic and -frecursive
are used at the same time:
f951: Warning: Flag '-fno
On 24/09/2019 14:53, Bernhard Reutner-Fischer wrote:
On Tue, 24 Sep 2019 12:12:04 +0100
Mark Eggleston wrote:
@@ -411,7 +411,7 @@ gfc_post_options (const char **pfilename)
&& flag_max_stack_var_size != 0)
gfc_warning_now (0, "Flag %<-fno-automatic%> overwr
On 28/09/2019 17:50, Steve Kargl wrote:
On Thu, Sep 26, 2019 at 09:45:28AM +0100, Mark Eggleston wrote:
Original thread starts here
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01185.html
OK to commit?
I'm not a big fan of option proliferation. If you don't
want to see warns just use -w
and have sent it
to this e-mail thread https://gcc.gnu.org/ml/fortran/2019-09/msg00123.html
regards,
Mark
On 30/09/2019 11:24, Jakub Jelinek wrote:
On Sat, Sep 28, 2019 at 10:33:26PM +0200, Andreas Schwab wrote:
On Aug 14 2019, Mark Eggleston wrote:
* gfortran.dg/auto_in_equiv_3.f90: New
Please find attached a patch to replace the test cases for "Automatic in
equivalence".
ChangeLog:
Mark Eggleston
* gfortran.dg/auto_in_equiv_1.f90: Deleted.
* gfortran.dg/auto_in_equiv_2.f90: Deleted.
* gfortran.dg/auto_in_equiv_3.f90: Deleted.
* g
Apologies typo in ChangeLog.
On 08/07/2019 14:51, Mark Eggleston wrote:
**ping**
On 01/07/2019 10:35, Mark Eggleston wrote:
On 25/06/2019 14:17, Mark Eggleston wrote:
On 25/06/2019 00:17, Jeff Law wrote:
On 6/24/19 2:19 AM, Bernhard Reutner-Fischer wrote:
On Fri, 21 Jun 2019 07:10:11
Unfortunately ISO_Fortran_binding_16.f90 contains a typo resulting in:
FAIL: gfortran.dg/ISO_Fortran_binding_16.f90 -O0 (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_16.f90 -O1 (test for excess errors)
FAIL: gfortran.dg/ISO_Fortran_binding_16.f90 -O2 (test for excess
this patch is being reviewed.
ChangeLogs
gcc/fortran
Jim MacArthur
Mark Eggleston
* gfortran.texi: Update Hollerith constants support for character types
and use in comparisons.
* invoke.texi: Tidy up list of options. Update description of
-fdec-char-conversions for character
On 25/10/2019 09:03, Tobias Burnus wrote:
Hello Mark, hi all,
On 10/21/19 4:40 PM, Mark Eggleston wrote:
This is an extension to support a legacy feature supported by other
compilers such as flang and the sun compiler. As I understand it
this feature is associated with DEC so it enabled
PING - OK, to commit? I have a pending patch that needs this in place.
On 05/11/2019 09:55, Mark Eggleston wrote:
On 25/10/2019 09:03, Tobias Burnus wrote:
Hello Mark, hi all,
On 10/21/19 4:40 PM, Mark Eggleston wrote:
This is an extension to support a legacy feature supported by other
in the new year?
Change logs:
gcc/fortran
Mark Eggleston
Jim MacArthur
* gfortran.texi: Update Hollerith constants support for character types
and use in comparisons.
* invoke.texi: Tidy up list of options. Update description of
-fdec-char-conversions.
* resolve.c
ion 277975). If the
conversion occurs in a array constructor it is rejected.
Patch is attached.
OK for trunk?
Change logs:
gcc/fortran/ChangeLog
Mark Eggleston
PR fortran/92896
* array.c (walk_array_constructor): Replace call to cfg_convert_type
with call to gfc_convert_type_war
On 17/12/2019 17:06, Steve Kargl wrote:
On Tue, Dec 17, 2019 at 03:41:41PM +, Mark Eggleston wrote:
gcc/fortran/ChangeLog
Mark Eggleston
PR fortran/92896
* array.c (walk_array_constructor): Replace call to cfg_convert_type
s/cfg_convert_type/gfc_convert_type
PING - OK to commit?
On 02/10/2019 09:00, Mark Eggleston wrote:
On 28/09/2019 17:50, Steve Kargl wrote:
On Thu, Sep 26, 2019 at 09:45:28AM +0100, Mark Eggleston wrote:
Original thread starts here
https://gcc.gnu.org/ml/gcc-patches/2019-09/msg01185.html
OK to commit?
I'm not a big fan
, REAL,
COMPLEX) and LOGICAL variables by direct assignment or in DATA statements.
Please find attached the patch which includes changes to the gfortran
manual.
Tested on x86_64 using "make check-fortran".
Change logs:
gcc/fortran/ChangeLog
Jim MacArthur
Mark
On 04/10/2019 11:39, Jakub Jelinek wrote:
On Wed, Oct 02, 2019 at 03:31:53PM +0100, Mark Eggleston wrote:
It was there because the code base has -fno-automatic for procedures are
that aren't recursive and the -frecursive was used because the recursive
routines don't have the recursive keyword
a
change log as there there doesn't appear to be any ChangeLog files.
The patch is attached. OK to commit?
--
https://www.codethink.co.uk/privacy.html
>From 2090a5d6d2e96c2a99094cd0a5f5d6e5c5bd3409 Mon Sep 17 00:00:00 2001
From: Mark Eggleston
Date: Tue, 26 Nov 2019 10:12:44 +
Subject: [PA
On 26/11/2019 11:12, Tobias Burnus wrote:
Hi Mark,
On 11/26/19 11:46 AM, Mark Eggleston wrote:
I've check the changes with W3 validator. There are no problems
related to my changes, however, it does object to the lack of
character encoding in the file.
Note that some script modifies
Second attempt this time with attachment.
Apologies.
regards,
Mark
On 26/11/2019 15:56, Mark Eggleston wrote:
On 26/11/2019 11:12, Tobias Burnus wrote:
Hi Mark,
On 11/26/19 11:46 AM, Mark Eggleston wrote:
I've check the changes with W3 validator. There are no problems
related to my
Corrected and committed.
On 27/11/2019 09:00, Tobias Burnus wrote:
On 11/26/19 7:33 PM, Mark Eggleston wrote:
htdocs/gcc-10/changes.html | 41
+
+
+ Default fields widths can be used for I,
F
+ and G format specifiers when
On 27/11/2019 08:29, Tobias Burnus wrote:
On 11/27/19 8:58 AM, Janne Blomqvist wrote:
On Tue, Nov 26, 2019 at 1:12 PM Tobias Burnus
wrote:
AUTOMATIC attribute
Speaking of which, to avoid confusion maybe we should rename the
-f[no-]automatic option to something like -f[no-]save, since the
.
As I right in thinking that items should be added to the list of Fortran
changes in the file gcc-wwwdocs/htdocs/gcc-10/changes.html?
Is there any procedure for checking changes to this repository?
regards,
Mark
On 11/21/19 12:05 PM, Mark Eggleston wrote:
Please find attached an updated
On 17/12/2019 17:47, Steve Kargl wrote:
On Tue, Dec 17, 2019 at 05:28:05PM +, Mark Eggleston wrote:
On 17/12/2019 17:06, Steve Kargl wrote:
On Tue, Dec 17, 2019 at 03:41:41PM +, Mark Eggleston wrote:
gcc/fortran/ChangeLog
Mark Eggleston
PR fortran/92896
On 17/12/2019 18:04, Janne Blomqvist wrote:
On Tue, Dec 17, 2019 at 7:47 PM Steve Kargl
wrote:
On Tue, Dec 17, 2019 at 05:28:05PM +, Mark Eggleston wrote:
On 17/12/2019 17:06, Steve Kargl wrote:
On Tue, Dec 17, 2019 at 03:41:41PM +, Mark Eggleston wrote:
gcc/fortran/ChangeLog
**ping**
On 17/02/2020 11:26, Mark Eggleston wrote:
Please find attached patch for PR93604.
gcc/fortran/ChangeLog
Steven G. Kargl
PR fortran/93604
* decl.c (gfc_match_data) : Check whether the data expression
is a derived type and is a constructor. If a BOZ constant
r
operands at (1) and (2) are not conformable" which is effectively the same.
gcc/fortran/ChangeLog
Mark Eggleston
Steven G. Kargl
PR fortran/93835
* decl.c (gfc_match_data) : Check whether the data expression
is a derived type and is a constructor. If a B
Forgot to add the purpose of the e-mail: OK to commit?
On 24/02/2020 12:24, Mark Eggleston wrote:
Please find attached a patch to fix PR93835. This patch ensures that
the array returned by SHAPE has its shape defined, the original patch
from Steve Kargl handled the lack of shape
**ping**
The following was a reply to
https://gcc.gnu.org/ml/fortran/2020-02/msg00042.html
see response below. OK to commit?
On 11/02/2020 15:23, Steve Kargl wrote:
On Tue, Feb 11, 2020 at 12:10:41PM +, Mark Eggleston wrote:
Please find attached a patch for PR93484. The original author
On 24/02/2020 14:34, Thomas Koenig wrote:
Hi Mark,
Might need
gfc_reduce_init_expr (e);
here. The kind type parameter should be a constant expression.
Not needed. I've also checked use of the kind argument, it is
evidently checked elsewhere: if k is allowed to be implicitly
nter assignment target" }
| 1
Error: Pointer assignment target is neither TARGET nor POINTER at (1)
this is because c does not have TARGET or POINTER attributes specified.
Change logs:
gcc/fortran/ChangeLog
Mark Eggleston
PR fortran/93714
* expr.c (gfc_check_pointer_
PR91984 modified typebound_call_22.f03 as it was expected to fail.
PR92113 negated the need for the xfail but unfortunately the test case
was not modified.
The attached patch removes the xfail.
gcc/testsuite/ChangeLog
Mark Eggleston
* typebound_call_22.d03 : Remove xfail clause
in the ChangeLog files but it is not
obvious for git commit messages.
OK for master and gcc 9 branch?
gcc/fortran/ChangeLog:
Steven G. Kargl
Mark Eggleston
PR fortran/93580
* primary.c (gfc_match_varspec): If the symbol following %
is re or im and the primary expression type
RROR.
gcc/testsuite/ChangeLog
Mark Eggleston
PR fortran/93484
* gfortran/pr93484_1.f90: New test.
* gfortran/pr93484_2.f90: New test.
--
https://www.codethink.co.uk/privacy.html
>From 4a3db68ce1fc8696b0108b4b0633c1f0959dac80 Mon Sep 17 00:00:00 2001
From: Mark Eggleston
Date
in the ChangeLog files but it is not
obvious for git commit messages.
OK for master and gcc 9 branch?
gcc/fortran/ChangeLog:
Steven G. Kargl
Mark Eggleston
PR fortran/93580
* primary.c (gfc_match_varspec): If the symbol following %
is re or im and the primary expression type
So it does, I'll have an other go.
On 11/02/2020 15:20, Steve Kargl wrote:
On Tue, Feb 11, 2020 at 02:41:26PM +, Mark Eggleston wrote:
Please find attached a patch, it is based on Steve Kargl's patch in PR93580
adding a check for %len and test case.
Looks like the wrong diff
and return
MATCH_ERROR.
gcc/testsuite/ChangeLog
Mark Eggleston
PR fortran/93604
* gfortran.dg/pr93604.f90 : New test.
OK to commit?
--
https://www.codethink.co.uk/privacy.html
>From b4bd5742d842c860da5b35955301e3c1a1e06160 Mon Sep 17 00:00:00 2001
From: Mark Eggleston
Date: Thu
Please find attached fix for PR fortran/93603.
gcc/fortran/ChangeLog
Steven G. Kargl
PR fortran/93603
* match.c (gfc_match_associate) : If target expression
has the type BT_BOZ output an error and goto
assocListError.
gcc/testsuite/ChangeLog
Mark Eggleston
PR
Please find attached a fix for PR93601.
gcc/fortran/ChangeLogs
Steven G. Kargl
PR fortran/93601
* match.c (gfc_match_assignment) : Reject assignment if
the lhs stype is BT_CLASS and the rhs type is BT_BOZ.
gcc/testsuite/ChangeLogs
Mark Eggleston
PR fortran/93601
Add a note the the Fortran changes to the effect that non-standard BOZ
constants are deprecated.
Is the wording OK?
--
https://www.codethink.co.uk/privacy.html
Add a note the the Fortran changes to the effect that non-standard BOZ
constants are deprecated.
Is the wording OK?
second attempt this time with attachment!
--
https://www.codethink.co.uk/privacy.html
diff --git a/htdocs/gcc-10/changes.html b/htdocs/gcc-10/changes.html
index
Please find attached patch to fix this regression.
OK for master and 9 branch?
Change logs:
gcc/fortran
Mark Eggleston
PR fortran/93236
* resolve.c (resolve_types): Declare boolean recursive and set with the
value of the recursive attribute of namespace proc_name symbol
Using git ls-remote, refs for vendor branches can be seen e.g.:
1a7bff0abccf167830c6e0443f3591380b960cb0
refs/vendors/redhat/heads/gcc-9-branch
Using git branch -r and there is no sign of that branch.
What needs to be done to access vendor branches?
--
On 01/04/2020 10:43, H.J. Lu wrote:
On Wed, Apr 1, 2020 at 2:31 AM Mark Eggleston
wrote:
Please find attached a patch to fix test case failures of pr93365.f90,
pr93600_1.f90 and pr93600_2.f90.
OK to commit?
gcc/fortran/ChangeLog:
Mark Eggleston
PR fortran/04386
Please find attached a patch to fix test case failures of pr93365.f90,
pr93600_1.f90 and pr93600_2.f90.
OK to commit?
gcc/fortran/ChangeLog:
Mark Eggleston
PR fortran/04386
expr.c (simplify_parameter_variable): Restore code deleted
in PR94246.
--
https
On 01/04/2020 10:46, Jakub Jelinek wrote:
On Wed, Apr 01, 2020 at 02:43:46AM -0700, H.J. Lu via Gcc-patches wrote:
On Wed, Apr 1, 2020 at 2:31 AM Mark Eggleston
wrote:
Please find attached a patch to fix test case failures of pr93365.f90,
pr93600_1.f90 and pr93600_2.f90.
OK to commit?
gcc
y_spec use is_non_constants_shape_array
to determine whether the array can be used in a in an
equivalence statement.
gcc/testsuite/ChangeLog:
Mark Eggleston
Steven G. Kargl
PR fortran/94030
* gfortran.dg/pr94030_1.f90: New test.
* gfortran.dg/pr94030_2.f90: New test.
--
https://www.codet
**ping**
On 23/03/2020 14:55, Mark Eggleston wrote:
Apologies, 2nd attempt:
gcc/fortran/ChangeLog:
Steven G. Kargl
PR fortran/93814
* resolve.c (gfc_verify_binding_labels): Handle symbols with
the subroutine attribute separately from symbols with the
function attribute
Please find attached patch for PR93498.
OK to commit?
gcc/fortran/ChangeLog:
Steven G. Kargl
PR fortran/93498
* check.c (gfc_check_findloc): If the kinds of the arguments
differ goto label "incompat".
gcc/testsuite/ChangeLog:
Mark Eggleston
PR for
On 27/04/2020 09:56, Thomas Koenig wrote:
Am 27.04.20 um 09:51 schrieb Mark Eggleston:
Please find attached three slightly different patches based on a
patch for PR59107 originally developed by Janus Weil
and Dominique d'Humieres for
gcc-5. The last comment regarding the patch was on 2015
required resulting in 3
slightly different patches.
Tested on x86_64 using make check-fortran.
OK to commit?
Change logs for master:
fortran/ChangeLog:
Janus Weil and
Dominique d'Humieres
Mark Eggleston
PR59107
* gfortran.h: Rename field resolved as resolve_symbol_called
is of type EXPR_OP and if so simplify it.
* resolve.c (resolve_charlen) : Reject length if it has a
rank.
2020-05-12 Mark Eggleston
gcc/testsuite/
PR fortran/93497
* gfortran.dg/pr88025.f90: Change in wording of error.
* gfortran.dg/pr93497.f90: New test.
* gfortran.dg
xpressions if the expression is not EXPR_VARIABLE and not
EXPR_CONSTANT.
2020-05-13 Steven G. Kargl
Mark Eggleston
gcc/fortran/
PR fortran/94397
* match.c (gfc_match_type_spec): New variable ok initialised
to true. Set ok with the return value of gfc_reduce_init_expr
). When reporting errors for
symbols that have the proc_pointer attribute check whether the
result attribute is set and set the name accordingly.
2020-05-18 Mark Eggleston
gcc/fortran/
PR fortran/39695
* resolve.c (resolve_fl_procedure): Set name depending on
whether the result attribute
symbol's namespace (ns). When reporting errors for
symbols that have the proc_pointer attribute check whether the
result attribute is set and set the name accordingly.
2020-05-18 Mark Eggleston
gcc/fortran/
PR fortran/39695
* resolve.c (resolve_fl_procedure): Set name depending
Messed up the e-mail addressed, gcc-patches now added.
Also, I note that I missed the PR fortran/50392 which should be inserted
at the start of the change log entries.
On 19/05/2020 08:49, Mark Eggleston wrote:
Please find attached patch for PR50392.
This patch was extracted from
On 19/05/2020 09:08, Manfred Schwarb wrote:
Am 18.05.20 um 09:35 schrieb Mark Eggleston:
Please find attached a patch for PR39695 (this time it is attached).
Commit message:
Fortran : ProcPtr function results: 'ppr@' in error message PR39695
The value 'ppr@' is set in the name of result
/testsuite/ChanheLog:
Mark Eggleston
PR fortran/93814
* gfortran.dg/pr93814.f90: New test.
--
https://www.codethink.co.uk/privacy.html
>From 4a3db68ce1fc8696b0108b4b0633c1f0959dac80 Mon Sep 17 00:00:00 2001
From: Mark Eggleston
Date: Tue, 11 Feb 2020 08:35:02 +
Subject: [PA
1 - 100 of 151 matches
Mail list logo
