Re: [PATCH] Fortran : Two further previously missed ICEs PR53298

2020-10-13 Thread Mark Eggleston
**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

Re: [PATCH] Fortran : ICE in build_field PR95614 (2nd attempt)

2020-10-13 Thread Mark Eggleston
**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

[PATCH] Fortran : ICE in gfc_validate_kind PR96099

2020-10-01 Thread Mark Eggleston
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

Re: [PATCH] Fortran : Two further previously missed ICEs PR53298

2020-09-29 Thread Mark Eggleston
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

[PATCH] Fortran : ICE in build_field PR95614 (2nd attempt)

2020-09-29 Thread Mark Eggleston
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

*PING* Re: [PATCH] Fortran : ICE in build_field PR95614

2020-09-24 Thread Mark Eggleston
: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

Re: [PATCH] Fortran : ICE in build_field PR95614

2020-09-14 Thread Mark Eggleston
**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

[PATCH] Fortran : Two further previously missed ICEs PR53298

2020-09-14 Thread Mark Eggleston
; 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):

[PATCH] Fortran : Two further previously missed ICEs PR53298

2020-09-11 Thread Mark Eggleston
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-

[PATCH] Fortran : ICE in build_field PR95614

2020-09-04 Thread Mark Eggleston
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):

[PATCH] Fortran : ICE on invalid code PR95398

2020-08-26 Thread Mark Eggleston
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

[PATCH] Fortran : ICE for division by zero in declaration PR95882

2020-08-25 Thread Mark Eggleston
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

Re: [PATCH] Fortran : ICE for division by zero in declaration PR95882

2020-08-25 Thread Mark Eggleston
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

Re: [PATCH] Fortran : ICE for division by zero in declaration PR95882

2020-08-25 Thread Mark Eggleston
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 --

[PATCH] Fortran : ICE for division by zero in declaration PR95882

2020-08-24 Thread Mark Eggleston
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

[PATCH] Fortran : Runtime error, reshape constant array assignment, PR96624

2020-08-20 Thread Mark Eggleston
): 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 

[PATCH] Fortran : get_environment_variable runtime error PR96486

2020-08-17 Thread Mark Eggleston
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

[PATCH] Fortran : rejected f0.d edit descriptor PR96436

2020-08-17 Thread Mark Eggleston
. 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

Re: [PATCH] Fortran : ICE in gfc_conv_scalarized_array_ref PR53298

2020-07-28 Thread Mark Eggleston
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

[PATCH] Fortran : Don't warn for LOGICAL kind conversion PR96319

2020-07-28 Thread Mark Eggleston
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

[PATCH] Fortran : ICE in gfc_conv_scalarized_array_ref PR53298

2020-07-20 Thread Mark Eggleston
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

Re: [PATCH] Fortran : ICE in gfc_find_array_ref(): No ref found PR95981

2020-07-10 Thread Mark Eggleston
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

Re: [PATCH] Fortran : ICE in gfc_check_pointer_assign PR95612

2020-07-10 Thread Mark Eggleston
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

[PATCH] Fortran : Implicitly type parameter causes an invalid error, PR96038

2020-07-09 Thread Mark Eggleston
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

[PATCH] Fortran : accepts pointer initialization of DT dummy args, PR45337

2020-07-09 Thread Mark Eggleston
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

Re: Fortran : Fortran translation issues PR52279

2020-07-02 Thread Mark Eggleston
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

Re: Fortran : Fortran translation issues PR52279

2020-07-02 Thread Mark Eggleston
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

Re: [PATCH] Fortran : Fill in missing array dimensions using the lower, bound (for review)

2020-07-02 Thread Mark Eggleston
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

Re: Fortran : Fortran translation issues PR52279

2020-07-02 Thread Mark Eggleston
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

Re: Fortran : Fortran translation issues PR52279

2020-07-02 Thread Mark Eggleston
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

[PATCH] Fortran : ICE in gfc_find_array_ref(): No ref found PR95981

2020-07-01 Thread Mark Eggleston
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

[PATCH] Fortran : ICE in gfc_check_pointer_assign PR95612

2020-07-01 Thread Mark Eggleston
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

Re: [PATCH] Fortran : ICE in generic_correspondence PR95584

2020-06-30 Thread Mark Eggleston
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

Re: Fortran : Fortran translation issues PR52279

2020-06-30 Thread Mark Eggleston
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

Re: [PATCH] Fortran : False positive for optional arguments PR95446

2020-06-30 Thread Mark Eggleston
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

Re: [PATCH] Fortran : Bogus error with additional blanks in type(*) PR95829

2020-06-30 Thread Mark Eggleston
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

[PATCH] Fortran : Fill in missing array dimensions using the lower, bound (for review)

2020-06-25 Thread Mark Eggleston
        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 : ICE in generic_correspondence PR95584

2020-06-25 Thread Mark Eggleston
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

Fortran : Fortran translation issues PR52279

2020-06-25 Thread Mark Eggleston
>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/

[PATCH] Fortran : Bogus error with additional blanks in type(*) PR95829

2020-06-24 Thread Mark Eggleston
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:/

[PATCH] Fortran : False positive for optional arguments PR95446

2020-06-24 Thread Mark Eggleston
  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

[PATCH] Fortran : ICE in resolve_fl_procedure PR95708

2020-06-19 Thread Mark Eggleston
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.

[PATCH] Fortran : ICE in gfc_check_reshape PR95585

2020-06-18 Thread Mark Eggleston
(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

[PATCH] Fortran : Missing gcc-internal-format PR42693

2020-06-17 Thread Mark Eggleston
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

[PATCH] Fortran : ICE in gfc_validate_kind PR95586

2020-06-17 Thread Mark Eggleston
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

Re: [PATCH] Fortran : ICE in maybe_canonicalize_comparison_1 PR92993

2020-06-05 Thread Mark Eggleston
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

[PATCH] Fortran : ICE in maybe_canonicalize_comparison_1 PR92993

2020-06-05 Thread Mark Eggleston
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

Re: [PATCH] PR94397 the compiler consider "type is( real(kind(1.)) )" as a syntax error

2020-05-27 Thread Mark Eggleston
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

Re: [PATCH] Fortran : ICE in gfc_trans_label_assign PR50392

2020-05-27 Thread Mark Eggleston
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

Re: [PATCH] Fortran : ProcPtr function results: 'ppr@' in error message PR39695

2020-05-19 Thread Mark Eggleston
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

Re: [PATCH] Fortran : ICE in gfc_trans_label_assign PR50392

2020-05-19 Thread Mark Eggleston
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

[PATCH] Fortran : ProcPtr function results: 'ppr@' in error message PR39695

2020-05-18 Thread Mark Eggleston
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

[PATCH] Fortran : ProcPtr function results: 'ppr@' in error message PR39695

2020-05-18 Thread Mark Eggleston
). 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

[PATCH] PR94397 the compiler consider "type is( real(kind(1.)) )" as a syntax error

2020-05-13 Thread Mark Eggleston
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

[PATCH, FORTRAN] ICE in gfc_conv_array_constructor_expr PR93497

2020-05-12 Thread Mark Eggleston
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

Re: [patch, fortran][8/9/10 Regression] PR59107 Fortran : Spurious warning message with -Wsurprising

2020-04-27 Thread Mark Eggleston
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

[patch, fortran][8/9/10 Regression] PR59107 Fortran : Spurious warning message with -Wsurprising

2020-04-27 Thread Mark Eggleston
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

Re: [patch, 10 Regression] FAIL: gfortran.dg/pr93365.f90 PR94386

2020-04-01 Thread Mark Eggleston
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

Re: [patch, 10 Regression] FAIL: gfortran.dg/pr93365.f90 PR94386

2020-04-01 Thread Mark Eggleston
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

[patch, 10 Regression] FAIL: gfortran.dg/pr93365.f90 PR94386

2020-04-01 Thread Mark Eggleston
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

[PATCH, 8/9/10 Regression] fortran: ICE equivalence with an element of an array PR94030

2020-03-30 Thread Mark Eggleston
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

[PATCH, 9/10 Regression] fortran : ICE in gfc_resolve_findloc PR93498

2020-03-30 Thread Mark Eggleston
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

Re: [Patch, 9/10 Regression] fortran: ICE in build_entry_thunks PR93814

2020-03-30 Thread Mark Eggleston
**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

Re: [Patch, 9/10 Regression] fortran: ICE in build_entry_thunks PR93814

2020-03-23 Thread Mark Eggleston
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

[Patch, 9/10 Regression] fortran: ICE in build_entry_thunks PR93814

2020-03-20 Thread 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

[Patch, 10 Regression] fortran: ICE in gfc_match_assignment PR93600

2020-03-20 Thread Mark Eggleston
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

Re: [PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484

2020-02-24 Thread Mark Eggleston
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

Re: [PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484

2020-02-24 Thread Mark Eggleston
**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

Re: [9/10 Regression, fortran, patch] ICE in simplify_findloc_nodim, at fortran/simplify.c:5513

2020-02-24 Thread Mark Eggleston
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

[9/10 Regression, fortran, patch] ICE in simplify_findloc_nodim, at fortran/simplify.c:5513

2020-02-24 Thread Mark Eggleston
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

Re: [Regression, patch][Fortran] ICE in gfc_conv_constant_to_tree PR93604

2020-02-24 Thread Mark Eggleston
**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

Re: Test failure on GCC-8/9 in typebound_call_22.f03

2020-02-19 Thread Mark Eggleston
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

[Regression, patch][Fortran] ICE: Invalid expression in gfc_element_size PR93601

2020-02-17 Thread Mark Eggleston
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

[Regression, patch][Fortran] ICE in gfc_typenode_for_spec PR93603

2020-02-17 Thread Mark Eggleston
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

[Regression, patch][Fortran] ICE in gfc_conv_constant_to_tree PR93604

2020-02-17 Thread Mark Eggleston
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

[8/9/10 Regression, patch][PR93714] ICE in gfc_check_same_strlen, at fortran/check.c:1253

2020-02-14 Thread Mark Eggleston
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_

[9/10 Regression, PATCH] fortran: ICE in gfc_validate_kind(): Got bad kind [PR93580]

2020-02-11 Thread Mark Eggleston
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

Re: [9/10 Regression, PATCH] fortran: ICE in gfc_validate_kind(): Got bad kind [PR93580]

2020-02-11 Thread Mark Eggleston
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

[9/10 Regression, PATCH] fortran: ICE in gfc_validate_kind(): Got bad kind [PR93580]

2020-02-11 Thread Mark Eggleston
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

[PATCH] fortran: ICE using undeclared symbol in array constructor, PR93484

2020-02-11 Thread Mark Eggleston
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

Git: accessing vendors branches

2020-01-16 Thread Mark Eggleston
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? --

[Patch, fortran][9/10 Regression] PR 93236 -fno-automatic and RECURSIVE

2020-01-16 Thread Mark Eggleston
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

[PATCH, WWW-DOCS] Deprecate non-standard hexadecimal BOZ constants.

2020-01-15 Thread Mark Eggleston
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

[PATCH, WWW-DOCS] Deprecate non-standard hexadecimal BOZ constants

2020-01-15 Thread Mark Eggleston
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

Re: [Patch, Fortran] PR92896 [10 Regression] Fix - Prevent character conversion in array constructor

2019-12-18 Thread Mark Eggleston
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

Re: [Patch, Fortran] PR92896 [10 Regression] Fix - Prevent character conversion in array constructor

2019-12-18 Thread Mark Eggleston
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

Re: [Patch, Fortran] PR92896 [10 Regression] Fix - Prevent character conversion in array constructor

2019-12-17 Thread Mark Eggleston
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

[Patch, Fortran] PR92896 [10 Regression] Fix - Prevent character conversion in array constructor

2019-12-17 Thread Mark Eggleston
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

Re: [Patch, gcc-wwdocs] Update to Fortran changes

2019-11-27 Thread Mark Eggleston
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

Re: [Patch, gcc-wwdocs] Update to Fortran changes

2019-11-27 Thread Mark Eggleston
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

Re: [Patch, gcc-wwdocs] Update to Fortran changes

2019-11-26 Thread Mark Eggleston
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

Re: [Patch, gcc-wwdocs] Update to Fortran changes

2019-11-26 Thread Mark Eggleston
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

[Patch, gcc-wwdocs] Update to Fortran changes

2019-11-26 Thread Mark Eggleston
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

Re: [Patch, Fortran] dec comparisons - for approval

2019-11-25 Thread Mark Eggleston
. 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

[Patch, Fortran] dec comparisons - for approval

2019-11-21 Thread Mark Eggleston
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

[Patch, Fortran] dec comparisons - for review

2019-11-15 Thread Mark Eggleston
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

Re: [Patch, fortran] PR fortran/92142 - CFI_setpointer corrupts descriptor

2019-11-11 Thread Mark Eggleston
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

Re: [PATCH, Fortran] Allow CHARACTER literals in assignments and DATA statements

2019-11-08 Thread Mark Eggleston
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

Re: [PATCH, Fortran] Allow CHARACTER literals in assignments and DATA statements

2019-11-05 Thread Mark Eggleston
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

[PATCH, Fortran] Allow CHARACTER literals in assignments and DATA statements - for review

2019-10-21 Thread Mark Eggleston
, 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   2   >