**ping**
see https://gcc.gnu.org/pipermail/gcc-patches/2020-September/554034.html
and https://gcc.gnu.org/pipermail/gcc-patches/2020-September/555072.html
OK for master?
On 14/09/2020 08:22, Mark Eggleston wrote:
Second attempt this time with patch attached.
For review.
Fixes the two ICEs
**ping**
previously omitted commit message added
On 29/09/2020 14:03, Mark Eggleston wrote:
For review.
When the first attempt was committed the result was PR97224 i.e. it
broke the build of SPECCPU 2006 Games.
I've changed the condition under which the error is produced. It was
produced
kind.
OK for master?
Is it worth backporting?
[PATCH] Fortran : ICE in gfc_validate_kind PR96099
Only check for kind if the type supports kind.
2020-10-02 Mark Eggleston
/gcc/fortran
PR fortran/96099
* decl.c (gfc_match_implicit): Check for numeric and logical
types.
2020-10-02
On 16/09/2020 08:02, Andre Vehreschild wrote:
Hi Mark,
a few remarks:
[...]
[PATCH] Fortran : Two further previously missed ICEs PR53298
There were 3 ICEs with different call stacks in the comments of this
PR. A previous commit fixed only one of those ICEs.
The ICEs fixed here are in
standards somewhat confusing
on the subject, so I haven't determined whether there should be any
standards dependent code.
--
https://www.codethink.co.uk/privacy.html
>From 56cd489ae564640e6cd397250f71947d768b796c Mon Sep 17 00:00:00 2001
From: Mark Eggleston
Date: Thu, 11 Jun 2020 14:33:51
:03, Andre Vehreschild wrote:
Hi Marc,
the patch looks reasonable and ok to me. Ok for trunk.
Thanks for the patch.
Regards,
Andre
On Fri, 4 Sep 2020 08:35:59 +0100
Mark Eggleston wrote:
Please find attached a fix for PR95614. The original patch was by Steve
Kargl.
The original patc
**ping**
On 04/09/2020 08:35, Mark Eggleston wrote:
Please find attached a fix for PR95614. The original patch was by
Steve Kargl.
The original patch resulted in name clashes between global identifiers
naming common blocks and local identifiers. According to the 2018
standard 19.3.1
; was
previously omitted. The cast is harmless.
2020-09-11 Mark Eggleston
gcc/fortran/
PR fortran/53298
* trans-array.c (gfc_conv_array_ref): In the body of the if
statement only execute the code before the reurn is se->ss is
set.
* trans-expr.c (gfc_conv_component_ref):
ot match its comments. Fixing
the code to match the comments fixes the ICE. A side affect is that
the in the tree dumps for finalize_35.f90 and finalize_36.f90 contain
"__builtin_free ((void *) ptr2->dat.data);", the "(void *)" was
previously omitted. The cast is harmless.
2020-
local identifier can be the same as
a global identier if that identifier represents a common. The patch
was modified to allow global identifiers that represent a common
block.
2020-09-04 Steven G. Kargl
Mark Eggleston
gcc/fortran/
PR fortran/95614
* decl.c (gfc_get_common):
a
NULL pointer to derive components if it isn't BT_CLASS.
2020-08-26 Mark Eggleston
gcc/testsuite
PR fortran/95398
* gfortran/pr95398.f90: New test.
--
https://www.codethink.co.uk/privacy.html
>From 9460e5033d1f20efa8b6dc6c892a085de46105d3 Mon Sep 17 00:00:00 2001
From: M
that a contant divided by a constant.
The cause was that char_len_param_value can return MATCH_YES
even if a divide by zero was seen. Prior to returning check
whether a divide by zero was seen and if so set it to MATCH_ERROR.
2020-08-24 Mark Eggleston
gcc/fortran
PR fortran/95882
* decl.c
On 25/08/2020 07:13, Mark Eggleston wrote:
On 24/08/2020 17:42, Thomas Koenig wrote:
Hi Mark,
OK to commit and backport?
The test cases mentioned in the ChangeLog are not in the
patch, instead there is the test case for PR 96624.
Could you correct that?
Whoops, yes I'll fix
On 24/08/2020 17:42, Thomas Koenig wrote:
Hi Mark,
OK to commit and backport?
The test cases mentioned in the ChangeLog are not in the
patch, instead there is the test case for PR 96624.
Could you correct that?
Whoops, yes I'll fix that.
Best regards
Thomas
--
complicated that a contant divided by a constant.
The cause was that char_len_param_value can return MATCH_YES
even if a divide by zero was seen. Prior to returning check
whether a divide by zero was seen and if so set it to MATCH_ERROR.
2020-08-24 Mark Eggleston
gcc/fortran
PR fortran/95882
): Add new variable "zerosize".
Set zerosize if any of the result shape ranks are zero. After
setting the result shapes, if zerosize is set jump to new label
"sizezero". Add label "sizezero" just before clearing index and
returning result.
2020-08-20
contain -1 if the value
of the environment is too large to fit in the value argument, this
is the case if the type is character(0) so there is no reason to
produce a runtime error if the value argument is zero length.
2020-08-17 Mark Eggleston
libgfortran/
PR fortran/96486
* intrin
.
2020-08-10 Mark Eggleston
libgfortran/io/
PR fortran/96436
* format.c (parse_format_list): Add new local variable
"standard" to hold the required standard to check. If the
format width is zero select standard depending on descriptor.
Call notification_std usi
ping
On 20/07/2020 08:27, Mark Eggleston wrote:
Please find attached a fix for PR53298.
This appears to be a very simple fix, however, since it involves
structures I'm unfamiliar with I think it needs checking.
When the gfc_ref structure is created for a (1:) substring it has an
expression
he gfortran-9 branch.
Fortran : Don't warn for LOGICAL kind conversion PR96319
LOGICAL values will always fit regardless of kind so there
is no need for warnings.
2020-07-28 Mark Eggleston
gcc/fortran/
PR fortran/96319
* intrinsic.c (gfc_convert_type_warn): Add check for
LOGICAL t
and
is accessed using (:)(1:) an ICE occurs. The upper bound of the
substring does not have an expression and such should not have
a Scalarization State structure added to the Scalarization State
chain.
2020-07-20 Mark Eggleston
gcc/fortran/
PR fortran/53298
* trans-array.c
ping
On 01/07/2020 07:56, Mark Eggleston wrote:
Please find attached a patch to fix PR95981. Original patch by Steve
Kargl.
OK to commit and backport?
Commit message:
Fortran : ICE in gfc_find_array_ref(): No ref found PR95981
When looking for an array reference allow NULL references
ping
On 01/07/2020 07:12, Mark Eggleston wrote:
Please find attached a patch which is a fix for PR95612. The original
patch is by Steve Kargl.
OK to commit and backport?
Commit message:
Fortran : ICE in gfc_check_pointer_assign PR95612
Output an error if the right hand value is a zero
output a error and reject.
2020-07-09 Mark Eggleston
gcc/testsuite/
PR fortran/96038
* gfortran.dg/pr96038.f90: New test.
--
https://www.codethink.co.uk/privacy.html
>From 7dfee4edf9796304c75785bb56610f3e06211f29 Mon Sep 17 00:00:00 2001
From: Mark Eggleston
Date: Mon, 6 Jul 2020 07
attribute
being added to the variable. The save attribute is not allowed for
variables with the dummy attribute set. Initialisation should be
rejected for dummy variables.
2020-07-09 Mark Eggleston
gcc/fortran/
PR fortran/45337
* resolve.c (resolve_fl_variable): Remove type and intent
On 02/07/2020 13:56, Mark Eggleston wrote:
On 02/07/2020 13:25, David Edelsohn wrote:
On Thu, Jul 2, 2020 at 6:16 AM Mark Eggleston
wrote:
I've committed the change from array to pointer. Does this fix your
builds?
On 02/07/2020 08:18, Mark Eggleston wrote:
On 01/07/2020 20:07, David
On 02/07/2020 13:25, David Edelsohn wrote:
On Thu, Jul 2, 2020 at 6:16 AM Mark Eggleston
wrote:
I've committed the change from array to pointer. Does this fix your builds?
On 02/07/2020 08:18, Mark Eggleston wrote:
On 01/07/2020 20:07, David Edelsohn wrote:
This patch breaks bootstrap
On 01/07/2020 23:01, Jerry DeLisle wrote:
On 6/27/20 1:40 AM, Thomas Koenig via Fortran wrote:
Hi Mark,
Use -fdec-add-missing-indexes to enable feature. Also enabled by fdec.
A warning that the lower bound is being used for a mission dimension
is output unless suppressed by using
I've committed the change from array to pointer. Does this fix your builds?
On 02/07/2020 08:18, Mark Eggleston wrote:
On 01/07/2020 20:07, David Edelsohn wrote:
This patch breaks bootstrap.
Apologies. I didn't see this when I built the compiler the with
bootstrap on x86_64. I'll endevour
On 01/07/2020 20:07, David Edelsohn wrote:
This patch breaks bootstrap.
Apologies. I didn't see this when I built the compiler the with
bootstrap on x86_64. I'll endevour to get it fixed as soon as possible.
regards,
Mark
It is not portable to use _( ... ) to initialize an array.
In
should return false.
2020-07-01 Steven G. Kargl
gcc/fortran/
PR fortran/95981
* check.c (dim_rank_check): Allow NULL references in call to
gfc_find_array_ref and return false if no reference is found.
2020-07-01 Mark Eggleston
gcc/testsuite/
PR fortran/95981
* gfortran.dg
continue checking.
2020-07-01 Steven G. Kargl
gcc/fortran/
PR fortran/95612
* expr.c (gfc_check_pointer_assigb): Output an error if
rvalue is a zero sized array or output an error if rvalue
doesn't have a symbol tree.
2020-07-01 Mark Eggleston
gcc/testsuite/
PR
I forgot to use [PATCH] in the subject line. ping!
On 25/06/2020 07:33, Mark Eggleston wrote:
Please find attached fix for PR95584. Original patch by Steve Kargl.
OK to commit and backport?
Commit message:
Fortran : ICE in generic_correspondence PR95584
Output an error for ambiguous
ping!
On 25/06/2020 07:28, Mark Eggleston wrote:
Patch to fix PR52279. Marked strings that are indirectly used in
error and warning messages so that they are marked for translation.
OK to commit?
Commit message:
Fortran : Fortran translation issues PR52279
Mark strings for translation
ping!
On 24/06/2020 09:00, Mark Eggleston wrote:
Please find attached a fix for PR95446. Patch originally posted to
the PR by Steve Kargl.
OK to commit to master and backport?
Commit message:
Fortran : False positive for optional arguments PR95446
Check that there is non-optional
On 24/06/2020 10:13, Manfred Schwarb wrote:
Am 24.06.20 um 10:12 schrieb Mark Eggleston:
Please find a fix for PR95829. Original patch by Steve Kargl posted to PR.
Commit to master and backport?
Commit message:
Fortran : Bogus error with additional blanks in type(*) PR95829
Checking
Mark Eggleston
gcc/fortran/
* lang.opt: Add options -Wmissing-index and
-fdec-add-missing-indexes.
* options.c (set_dec_flags): Add SET_BITFLAG for new option.
* resolve.c (compare_spec_to_ref): If the flag is set and
the number of dimension is less than the rank use
fortran/95584
* interface.c (generic_correspondence): Only use the pointer
to a symbol if exists.
2020-06-25 Mark Eggleston
gcc/testsuite/
PR fortran/95584
* gfortran.dg/pr95584.f90: New test.
--
https://www.codethink.co.uk/privacy.html
>F
>From ecd9fd13dcc6479b14072e6a0c8b186d33e5992b Mon Sep 17 00:00:00 2001
From: Mark Eggleston
Date: Tue, 2 Jun 2020 08:38:01 +0100
Subject: [PATCH] Fortran : Fortran translation issues PR52279
Mark strings for translation by enclosing in G_() and _().
2020-06-24 Mark Eggleston
gcc/fortran/
Kargl
gcc/fortran/
PR fortran/95829
* decl.c (gfc_match_decl_type_spec): Compare with "* ) " instead
of "*)".
2020-06-24 Mark Eggleston
gcc/testsuite/
PR fortran/95829
* gfortran.dg/pr95829.f90: New test.
--
https:/
Mark Eggleston
gcc/testsuite/
PR fortran/95446
* gfortran.dg/elemental_optional_args_6.f90: Remove check
for warnings that were erroneously output.
* gfortran.dg/pr95446.f90: New test.
--
https://www.codethink.co.uk/privacy.html
>From 4ad64b418c93064cfdfd07fc8a9e6305d8cc6
PR fortran/PR95708
* intrinsic.c (add_functions): Replace CLASS_INQUIRY with
CLASS_TRANSFORMATIONAL for intrinsic num_images.
(make_generic): Replace ACTUAL_NO with ACTUAL_YES for
intrinsic team_number.
2020-06-19 Mark Eggleston
gcc/testsuite/
PR fortran/95708
* gfortran.
(gfc_check_reshape): Add check for a value when
the symbol has an attribute flavor FL_PARAMETER.
2020-06-17 Mark Eggleston
gcc/testsuite/
PR fortran/95585
* gfortran.dg/pr95585.f90: New test.
--
https://www.codethink.co.uk/privacy.html
>From ac759f1708e6b325abdb8586ea378fe5b8a234ba
Please find attached patch for PR42693.
OK to commit and backport?
Fortran : Missing gcc-internal-format PR42693
Messages in gfc_arith_error contain gcc internal format specifiers
which should be enclosed in G_() in order to be correctly translated.
2020-06-17 Mark Eggleston
gcc/fortran
on those
provided by G. Steinmetz in the PR.
2020-06-17 Steven G. Kargl
gcc/fortran/
PR fortran/95586
* dec.l (gfc_match_implicit): Only perform else branch if
the type spect is not BT_DERIVED.
2020-06-17 Mark Eggleston
gcc/testsuite/
PR fortran/95586
* gfortran.dg
This time with actual patch.
On 05/06/2020 09:04, Mark Eggleston wrote:
OK to commit?
Commit message:
Fortran : ICE in maybe_canonicalize_comparison_1 PR92993
This issue has been fixed by PR94090. Add test case to ensure that
this does not re-occur.
2020-06-04 Mark Eggleston
gcc
OK to commit?
Commit message:
Fortran : ICE in maybe_canonicalize_comparison_1 PR92993
This issue has been fixed by PR94090. Add test case to ensure that
this does not re-occur.
2020-06-04 Mark Eggleston
gcc/fortran/
PR fortran/92993
* gfortran.dg/pr92993.f90: New test
ping
On 13/05/2020 18:19, Mark Eggleston wrote:
Please find attached a patch for PR94397.
Commit message:
Fortran : "type is( real(kind(1.)) )" spurious syntax error PR94397
Based on a patch in the comments of the PR. That patch fixed this problem
but caused the test cases f
ping
On 19/05/2020 08:49, Mark Eggleston wrote:
Please find attached patch for PR50392.
This patch was extracted from the comments in the PR and was written
back in 2011! I have verified that it fixes the PR on master, gcc-8,
gcc-9 and gcc-10.
Commit message:
Fortran : ICE
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
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
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
). 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
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
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
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
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
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
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
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
**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
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.
gcc/testsuite/ChanheLog:
Mark Eggleston
/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
of the fix for PR93581. A small change
(resolve.c) was necessary to fix that.
As a free gift this also fixes PR93365.
OK to commit?
gcc/fortran/ChangeLog:
Mark Eggleston
Steven G. Kargl
PR fortran/93600
* expr.c (simplify_parameter_variable): Check whether the ref
chai
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
**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
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
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
**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
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
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
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
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
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_
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
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
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?
--
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
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
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
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
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 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
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 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
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
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
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
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
.
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
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
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
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
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
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
, 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
1 - 100 of 151 matches
Mail list logo