Le 23/02/2022 à 23:21, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
Fortran 2018 added a QUIET= specifier to STOP and ERROR STOP statements.
Janne already implemented the library side code four (4!) years ago,
but so far the frontend implementation was missing.
Furthermore, F2018 allow
Le 28/02/2022 à 15:27, Kwok Cheung Yeung a écrit :
On 28/02/2022 2:07 pm, Jakub Jelinek wrote:
(...)
Don't we usually test instead || (*expr)->rank != 0 when testing for
scalars?
(...)
So (*expr)->rank is 0 here even with an array. I'm not sure why - is
rank updated later, or did we forget
Le 28/02/2022 à 17:00, Jakub Jelinek a écrit :
On Mon, Feb 28, 2022 at 04:54:24PM +0100, Mikael Morin wrote:
Le 28/02/2022 à 15:27, Kwok Cheung Yeung a écrit :
On 28/02/2022 2:07 pm, Jakub Jelinek wrote:
(...)
Don't we usually test instead || (*expr)->rank != 0 when testing for
Le 28/02/2022 à 19:38, Kwok Cheung Yeung a écrit :
In gfc_expression_rank, e->ref is non-NULL, so e->rank is not set from
the symtree. It then iterates through the ref elements - ref->type ==
REF_ARRAY and ref->u.ar.type == AR_ELEMENT, so e->rank remains at 0.
This is the expected behavior.
Le 28/02/2022 à 21:37, Mikael Morin a écrit :
Maybe corank should be checked together with rank?
Lesson learned today: expressions don’t have a corank.
Does pr104131-2.f90 really need to be rejected?
Le 15/11/2021 à 22:38, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
the attached patch fixes the handling of the DEC trigonometric intrinsics
for different argument kinds. It is based on the original patch by Steve,
which fixes the lookup for the needed intrinsics.
Regtested on x86_64
Le 19/11/2021 à 20:47, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
scalariziation of the elemental intrinsic LEN_TRIM was ICEing
when the optional KIND argument was present.
The cleanest solution is to use the infrastructure added by
Mikael's fix for PR97896. In that case it is a 1-l
Le 19/11/2021 à 10:40, Jakub Jelinek via Fortran a écrit :
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Hello,
you know probably better than me or any fortran maintainer whether it’s
good or bad.
So OK from the fortran side.
Le 22/11/2021 à 21:30, Bernhard Reutner-Fischer a écrit :
I'm just wondering loud if it would be more convenient to have a
unsigned hidden_arg:1 bit in let's say gfc_actual_arglist that denotes
if the argument should be const eval'ed and used before, and, most
importantly not passed to the libra
Le 23/11/2021 à 21:46, Harald Anlauf via Fortran a écrit :
Dear all,
in simplify_bound we did hit an assert when trying to simplify
LBOUND/UBOUND for arrays with allocatable or pointer attribute.
We cannot do that. Terminate simplification in that situation.
Regtested on x86_64-pc-linux-gnu.
Hello,
Le 24/11/2021 à 22:32, Harald Anlauf via Fortran a écrit :
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 5a5aca10ebe..837eb0912c0 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -4866,10 +4868,17 @@ gfc_check_reshape (gfc_expr *source, gfc_expr *shape,
Le 25/11/2021 à 21:03, Harald Anlauf a écrit :
Hi Mikael,
Am 25.11.21 um 17:46 schrieb Mikael Morin:
Hello,
Le 24/11/2021 à 22:32, Harald Anlauf via Fortran a écrit :
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 5a5aca10ebe..837eb0912c0 100644
--- a/gcc/fortran/check.c
+++ b
Le 25/11/2021 à 22:52, Harald Anlauf a écrit :
>
> Motivated by your reasoning I tried gfc_reduce_init_expr. That attempt
> failed miserably (many regressions), and I think it is not right.
> Then I found that array sections posed a problem that wasn't detected
> before. gfc_simplify_expr seeme
Le 26/11/2021 à 21:07, Harald Anlauf a écrit :
That should hopefully be the final version...
Yes it is OK. Thanks for your patience.
Mikael
Hello,
Le 29/11/2021 à 22:31, Harald Anlauf via Fortran a écrit :
Dear all,
a trivial one: we need to check the type of the SUB argument
to the coarray IMAGE_INDEX intrinsic. It has to be an array
of type integer.
Patch by Steve Kargl.
I hope at some point he’ll finally come to a working gi
Le 29/11/2021 à 23:01, Harald Anlauf via Fortran a écrit :
Dear all,
another trivial and obvious one, discovered by Gerhard.
We can have a NULL pointer dereference simplifying MINLOC/MAXLOC
on an array that was not properly declared.
OK for mainline / affected 11-branch after regtesting comple
Le 29/11/2021 à 16:03, Richard Biener via Gcc-patches a écrit :
diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
index f5ba7cecd54..16ee2afc9c0 100644
--- a/gcc/fortran/frontend-passes.c
+++ b/gcc/fortran/frontend-passes.c
@@ -5229,7 +5229,6 @@ gfc_expr_walker (gfc_expr
On 30/11/2021 14:25, Richard Biener wrote:
On Tue, 30 Nov 2021, Mikael Morin wrote:
Le 29/11/2021 à 16:03, Richard Biener via Gcc-patches a écrit :
diff --git a/gcc/fortran/frontend-passes.c b/gcc/fortran/frontend-passes.c
index f5ba7cecd54..16ee2afc9c0 100644
--- a/gcc/fortran/frontend
Hello,
On 27/11/2021 21:56, Harald Anlauf via Fortran wrote:
diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index 6552eaf3b0c..fbc66097c80 100644
--- a/gcc/fortran/array.c
+++ b/gcc/fortran/array.c
@@ -1804,6 +1804,12 @@ expand_constructor (gfc_constructor_base base)
if (empty_con
On 02/12/2021 22:48, Harald Anlauf via Fortran wrote:
Dear Fortranners,
specifying invalid constant array declarations (e.g. real array bounds)
could lead to an ICE because the array specs were checked for consistency.
A possible solution is to try an early simplification before doing that
check
Hello,
On 06/12/2021 23:39, Harald Anlauf via Fortran wrote:
diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index 5762c8d92d4..5f9ed17f919 100644
--- a/gcc/fortran/array.c
+++ b/gcc/fortran/array.c
@@ -2403,11 +2403,9 @@ gfc_ref_dimen_size (gfc_array_ref *ar, int dimen, mpz_t
*result, m
On 06/12/2021 23:19, Harald Anlauf via Fortran wrote:
Dear all,
we didn't check the type of the upper bound in a case range.
Bummer. Simply add a corresponding check.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
OK, Thanks.
Hello,
On 05/12/2021 22:55, Harald Anlauf via Fortran wrote:
Dear all,
the check of dummy arguments with pointer attribute and INTENT(IN)
was broken in the case the argument was passed to an intrinsic.
We therefore rejected valid code as e.g. given in the PR.
The patch relaxes the excessive ch
On 07/12/2021 21:43, Harald Anlauf via Fortran wrote:
I haven't figured out yet how to kill or fix the array decl in
that case.
As long as an error is reported, and the compiler doesn’t crash after
it, I’m not sure there is something more to fix.
Nevertheless it makes sense to catch situat
On 07/12/2021 21:46, Harald Anlauf wrote:
Hi Mikael,
Am 07.12.21 um 21:17 schrieb Mikael Morin:
Hello,
On 05/12/2021 22:55, Harald Anlauf via Fortran wrote:
Dear all,
the check of dummy arguments with pointer attribute and INTENT(IN)
was broken in the case the argument was passed to an
Hello,
On 09/12/2021 21:05, Harald Anlauf via Fortran wrote:
Dear all,
I had thought that we had fixed this in the past (see PR31001),
but it did fail for me with all gcc versions I have tried (7-12)
for a slightly more elaborate case as in the old testcase.
The loop in pack_internal did try t
On 09/12/2021 23:05, Harald Anlauf wrote:
Hi Mikael,
Am 08.12.21 um 10:32 schrieb Mikael Morin:
On 07/12/2021 21:46, Harald Anlauf wrote:
Hi Mikael,
Am 07.12.21 um 21:17 schrieb Mikael Morin:
The existing code looks dubious to me (or at least difficult to
understand), and your patch doesn’t
On 10/12/2021 22:49, Harald Anlauf via Fortran wrote:
Dear all,
when accessing CLASS components we need to ensure that the
corresponding class container has already been built.
Invalid code, e.g. the testcase in PR103606, may otherwise
generate segfaults due to invalid reads.
Regtested on x86_6
Le 11/10/2022 à 22:23, Harald Anlauf via Fortran a écrit :
Dear all,
we need to check that the operands of arithmetic binary operations
are consistent and of numeric type.
The PR reported an issue for multiplication ("*"), but we better
extend this to the other binary operations.
I chose the f
Le 09/10/2022 à 20:57, Harald Anlauf via Fortran a écrit :
Dear all,
the check of data transfer elements needs to verify that for
polymorphic objects there is a user defined DTIO procedure.
This check worked fine for scalars, but skipped arrays,
leading to an ICE later.
The obvious fix is to al
Le 16/10/2022 à 20:46, Harald Anlauf via Fortran a écrit :
Dear all,
this PR is actually very related to PR107217 that addressed ICEs
with bad array constructors with typespec when used in arithmetic
expressions. The present patch extends the checking to logical
operations and to comparisons an
Le 15/10/2022 à 22:15, Harald Anlauf via Fortran a écrit :
Dear all,
here is an updated version of the patch that includes suggestions
and comments by Mikael in PR93483.
Basic new features are:
- a new enum value ARITH_NOT_REDUCED to keep track if we encountered
an expression that was not re
Hello,
Le 20/10/2022 à 16:13, Aldy Hernandez via Gcc-patches a écrit :
The finite_operands_p function was incorrectly named, as it only
returned TRUE when !NAN. This was leftover from the initial
implementation of frange. Using the maybe_isnan() nomenclature is
more consistent and easier to un
Le 20/10/2022 à 20:56, Mikael Morin a écrit :
Doesn't this miss a check of flag_finite_math_only to be strictly
equivalent? You keep that check for the two-arguments case, so I guess
it's not redundant?
Well, the check is removed in the follow-up patch, so maybe is is after all.
Le 19/10/2022 à 22:49, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
here's another patch that improves error receovery with references
of bad array constructors leading to an ICE after a NULL pointer
dereference.
Original patch by Steve, which I amended with a logic cleanup.
Regtested
Le 18/10/2022 à 22:48, Harald Anlauf via Fortran a écrit :
I intended to add the updated patch but forgot, so here it is...
Am 18.10.22 um 22:41 schrieb Harald Anlauf via Fortran:
Dear all,
Jose posted a patch here that was never reviewed:
https://gcc.gnu.org/pipermail/fortran/2021-April/0
Hello,
Le 26/10/2022 à 21:15, Harald Anlauf via Fortran a écrit :
Dear all,
a BOZ as source-expression in an ALLOCATE statement could lead
to an ICE when the allocate-object was a CLASS variable.
Since a BOZ has no type, we can handle it as type incompatible
with any type. This is also what th
Le 28/10/2022 à 22:12, Harald Anlauf via Fortran a écrit :
Dear all,
the passing of procedure arguments in Fortran sometimes requires
ancillary parameters that are "hidden". Examples are string length
and the presence status of scalar variables with optional+value
attribute.
The gfortran ABI i
Le 30/10/2022 à 20:23, Mikael Morin a écrit :
I think some discrepancy remains, as gfc_conv_procedure_call accumulates
coarray stuff into the stringargs, while your change accumulates the
associated parameter decls separately into hidden_arglist. It's not
completely clear to me wheth
Le 30/10/2022 à 20:23, Mikael Morin a écrit :
Another probable issue is your change to create_function_arglist changes
arglist/hidden_arglist without also changing typelist/hidden_typelist
accordingly. I think a change to gfc_get_function_type is also
necessary: as the function decl is
Le 30/10/2022 à 22:25, Mikael Morin a écrit :
Le 30/10/2022 à 20:23, Mikael Morin a écrit :
Another probable issue is your change to create_function_arglist
changes arglist/hidden_arglist without also changing
typelist/hidden_typelist accordingly. I think a change to
gfc_get_function_type is
Le 31/10/2022 à 21:29, Harald Anlauf via Fortran a écrit :
Hi Mikael,
thanks a lot, your testcases broke my initial (and incorrect) patch
in multiple ways. I understand now that the right solution is much
simpler and smaller.
I've added your testcases, see attached, with a simple scan of the
d
Le 02/11/2022 à 22:19, Harald Anlauf via Fortran a écrit :
Am 02.11.22 um 18:20 schrieb Mikael Morin:
Unfortunately no, the coarray case works, but the other problem remains.
The type problem is not visible in the definition of S, it is in the
declaration of S's prototype in P.
S is de
Hello,
Tobias approved it already, but I spotted what looks like typos.
See below.
Mikael
gcc/
* common.opt (static-libquadmath): New option.
* gcc.c (driver_handle_option): Always accept -static-libquadmath.
* config/darwin.h (LINK_SPEC): Handle -static-libquadmath.
Le 20/08/2022 à 10:41, Jakub Jelinek via Fortran a écrit :
Hi!
As discussed earlier, all other -static-lib* options are Driver only,
these 2 are Driver in common.opt and Fortran in lang.opt.
The spec files never pass the -static-lib* options down to any compiler
(f951 etc.), so the 2 errors bel
Le 20/08/2022 à 21:11, Harald Anlauf via Fortran a écrit :
Dear all,
the simplification of the TRANSFER intrinsic produces a
redundant representation of the result, one in expr->value
and another in expr->representation.string. This is done
to ensure a safe "round-trip" for nested TRANSFER.
In
Le 04/09/2022 à 22:04, Harald Anlauf via Fortran a écrit :
Dear all,
said PR was addressed by Jose in
https://gcc.gnu.org/pipermail/fortran/2021-April/055949.html
but unfortunately his patch was never reviewed.
IMHO the patch is mostly fine, with one small exception that
it should use POIN
Le 10/09/2022 à 12:14, FX via Fortran a écrit :
If you have a solution for the standards checking, I’ll add it.
As a first step, one could check the use rename lists; what's done for
iso_fortran_env can be used as an example.
To diagnose the other usages, the check could be put in resolve_sym
Le 11/09/2022 à 11:57, FX a écrit :
As a first step, one could check the use rename lists; what's done for
iso_fortran_env can be used as an example.
Yes, but iso_fortran_env is handled entirely in front-end, not through external
files.
That's true, but the standard check doesn't really dep
Hello,
diff --git a/gcc/testsuite/gcc.misc-tests/gcov.exp
b/gcc/testsuite/gcc.misc-tests/gcov.exp
index 82376d90ac2..a55ce234f6e 100644
--- a/gcc/testsuite/gcc.misc-tests/gcov.exp
+++ b/gcc/testsuite/gcc.misc-tests/gcov.exp
@@ -24,9 +24,9 @@ global GCC_UNDER_TEST
(...)
} else {
-set GC
Le 11/09/2022 à 18:04, Torbjorn SVENSSON a écrit :
Can you fix it for me and submit it or do you want me to send a v3?
For trivial things like this, there is no need for a v3 (nor was there
for a v2).
Do you miss a git write account and need someone to push for you?
Le 12/09/2022 à 09:06, Torbjorn SVENSSON a écrit :
On 2022-09-11 21:38, Mikael Morin wrote:
Le 11/09/2022 à 18:04, Torbjorn SVENSSON a écrit :
Can you fix it for me and submit it or do you want me to send a v3?
For trivial things like this, there is no need for a v3 (nor was there
for a
I have just pushed the attached fix for two UNRESOLVED checks at
-O0 that I hadn’t seen.From 6cc26f3037a18b9a958b4ac2a1363149a7fccd39 Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Mon, 25 Apr 2022 13:14:20 +0200
Subject: [pushed] =?UTF-8?q?testsuite:=C2=A0add=20additional=20option=20to
Le 25/04/2022 à 14:12, Jakub Jelinek a écrit :
On Mon, Apr 25, 2022 at 01:38:25PM +0200, Mikael Morin wrote:
I have just pushed the attached fix for two UNRESOLVED checks at -O0 that I
hadn’t seen.
I don't like forcing of DSE in -O0 compilation, wouldn't it be better
to just not che
-linux-gnu.
I plan to push it tonight.From 85d57fb88203697d7e52d5f1f148eab35e4f7486 Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Tue, 26 Apr 2022 13:05:32 +0200
Subject: [PATCH] fortran: Avoid infinite self-recursion [PR105381]
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content
Le 26/04/2022 à 15:32, Jakub Jelinek a écrit :
On Tue, Apr 26, 2022 at 03:22:08PM +0200, Tobias Burnus wrote:
LGTM - however:
On 26.04.22 14:38, Mikael Morin wrote:
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -3698,7 +3698,8 @@ non_negative_strides_array_p (tree expr
Hello,
this fixes a regression caused by my recent PR103662 patch.
Regression tested on x86_64-pc-linux-gnu. OK for master?From d7309a471c42e51e84c37d5d4a3fd5bb0ed67405 Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Mon, 25 Apr 2022 19:47:04 +0200
Subject: [PATCH] fortran: Compare non
Le 26/04/2022 à 19:12, Mikael Morin a écrit :
Le 26/04/2022 à 15:32, Jakub Jelinek a écrit :
or one can repeat it like:
if (DECL_P (expr)
&& DECL_LANG_SPECIFIC (expr)
&& GFC_DECL_SAVED_DESCRIPTOR (expr)
&& GFC_DECL_SAVED_DESCRIPTOR (expr
Le 29/04/2022 à 22:10, Thomas Koenig via Fortran a écrit :
the attached patch documents the support for IEEE long double for
Fortran. OK? Suggestions for better wording?
I'd like to get this in before the gcc12 release. It would also
qualify as obviously correct, I think :-) so I'll commit
Le 08/05/2022 à 22:17, Harald Anlauf via Fortran a écrit :
Dear all,
the PR correctly notes that a space between keywords 'TYPE' and 'IS' is
required in free-form, but we currently accept 'TYPEIS'. We shouldn't.
The combinations with non-optional blanks are listed in the standard;
in F2018 this
Le 09/05/2022 à 21:34, Harald Anlauf a écrit :
Hi Mikael,
Am 09.05.22 um 20:24 schrieb Mikael Morin:
The fix itself looks good. Regarding the test, I don’t understand the
problem. Can’t there be multiple subroutines, each having one (or more)
problematic statement(s)?
that's why I
Le 09/05/2022 à 22:20, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
we were lacking checks for arguments of type TEAM_TYPE to some
coarray intrinsics (FORM TEAM, CHANGE TEAM, and SYNC TEAM).
The attached patch adds these, and as a bonus verifies that
TEAM NUMBER is a scalar integer.
Re
Le 11/05/2022 à 10:17, Martin Liška a écrit :
On 5/9/22 14:03, Richard Biener wrote:
On Thu, May 5, 2022 at 4:30 PM Martin Liška wrote:
On 5/5/22 14:58, Iain Buclaw wrote:
This D front-end change doesn't look right to me, besides the slight
Hello.
Sorry, I've re-read the patch and fixed s
Le 27/10/2021 à 23:11, Bernhard Reutner-Fischer via Fortran a écrit :
Delete some more declarations without definitions and make some
functions static.
Bootstrapped and regtested on x86_64-unknown-linux without regressions.
Ok for trunk?
Ok.
Thanks
Mikael
Le 29/10/2021 à 01:58, Bernhard Reutner-Fischer via Fortran a écrit :
On Wed, 27 Oct 2021 23:39:43 +0200
Bernhard Reutner-Fischer wrote:
Ping
[hmz. it's been a while, I'll rebase and retest this one.
Ok if it passes?]
Testing passed without any new regressions.
Ok for trunk?
thanks,
On Mon,
Le 27/10/2021 à 23:29, Bernhard Reutner-Fischer via Fortran a écrit :
From: Bernhard Reutner-Fischer
addresses: FIXME: gfc_current_locus is wrong
by using the locus of the current intrinsic.
Regtests clean, ok for trunk?
Hello,
I’m not convinced that replacing a global variable by an other r
Le 31/10/2021 à 18:25, Bernhard Reutner-Fischer via Fortran a écrit :
As Gerhard Steinmetz noticed, gfc_match_implicit_none() had a notify_std
that mentioned IMPORT instead of IMPLICIT. Fix that typo.
IMPLICIT NONE (external) is supposed to require external procedures to
be explicitly declared w
Le 01/11/2021 à 22:39, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
a recent patch uncovered a latent issue with simplification of
array-valued expressions where the resulting shape was not set
from the referenced subobject. Once found, the fix looks obvious.
Regtested on x86_64-pc-li
Le 04/11/2021 à 20:49, Harald Anlauf via Fortran a écrit :
Let's see what others think.
OK, thanks.
Mikael
Le 31/10/2021 à 22:35, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
the fix for initialization of DT arrays caused an apparent regression for
cases where inconsistent ranks were used in such an initialization.
This caused either an ICE in subsequent uses of these arrays, or showed
up in
Le 05/11/2021 à 03:58, Sandra Loosemore a écrit :
This is an expanded version of the patch for PR 101337 that Bernhard
sent out a few days ago with a request for me to finish it. Bernhard
did the part for operands and I added the pieces for procedure arguments
and intrinsics, along with fixing
Le 05/11/2021 à 19:46, Mikael Morin a écrit :
Don’t you get the same effect on the memory leaks if you keep just the
following hunk?
>>> @@ -1605,8 +1608,7 @@ generate_finalization_wrapper (gfc_symbol
*derived, gfc_namespace *ns,
>>> /* Set up the namespace.
Sorry, I hadn’t seen your message.
Le 05/11/2021 à 23:08, Bernhard Reutner-Fischer a écrit :
On Fri, 5 Nov 2021 19:46:16 +0100
Mikael Morin wrote:
Le 29/10/2021 à 01:58, Bernhard Reutner-Fischer via Fortran a écrit :
On Wed, 27 Oct 2021 23:39:43 +0200
Bernhard Reutner-Fischer wrote
Le 07/11/2021 à 00:56, Bernhard Reutner-Fischer a écrit :
On Sat, 6 Nov 2021 13:04:07 +0100
Mikael Morin wrote:
Le 05/11/2021 à 23:08, Bernhard Reutner-Fischer a écrit :
On Fri, 5 Nov 2021 19:46:16 +0100
Mikael Morin wrote:
I’m a bit concerned by the loss of the null_expr’s type
Committed as r12-5192.
The KIND argument of the INDEX intrinsic is a compile time constant
that is used at compile time only to resolve to a kind-specific library
function. That argument is otherwise completely ignored at runtime, and there is
no code generated for it as the library procedure ha
mainline?
Thanks,
Harald
On 1/30/24 11:46, Mikael Morin wrote:
Le 30/01/2024 à 11:38, Mikael Morin a écrit :
Another (easier) way to clarify the data reference would be rephrasing
the message so that the array part is separate from the scalar part,
like so (there are too many 'of', bu
Le 15/03/2024 à 18:26, Harald Anlauf a écrit :
Hi Mikael,
On 3/15/24 17:31, Mikael Morin wrote:
Le 10/03/2024 à 22:31, Harald Anlauf a écrit :
Dear all,
after playing for some time with NAG and Intel, and an off-list
discussion with Jerry, I am getting more and more convinced that
simpler
involved, and enables more valid ones, as visible in the testcases from the
first patch.
The patch is not completely trivial, and fix what is not really a regression,
so it is more for stage1, I think.
Tested for regression on x86_64-pc-linux-gnu. Ok for master when stage1
opens?
Mikael Morin (2
This fixes invalid undeclared fortran array bound variables
in the testsuite.
gcc/testsuite/ChangeLog:
* gfortran.dg/graphite/pr107865.f90: Declare array bound variable(s)
as dummy argument(s).
* gfortran.dg/pr101267.f90: Likewise.
* gfortran.dg/pr112404.f90: Likew
This fixes a spurious invalid variable in specification expression error.
The problem is caused by improper restoration of formal_arg_flag to false
(instead of restoring it to its previous value). This happens with the
testcase from the PR where a dummy argument is itself a procedure with dummy
ar
master when stage1
opens?
Mikael
v1 -> v2 changes:
- Fix condition guarding sym->result access.
Mikael Morin (2):
testsuite: Declare fortran array bound variables
fortran: Fix specification expression error with dummy procedures
[PR111781]
gcc/fortran/e
This fixes invalid undeclared fortran array bound variables
in the testsuite.
gcc/testsuite/ChangeLog:
* gfortran.dg/graphite/pr107865.f90: Declare array bound variable(s)
as dummy argument(s).
* gfortran.dg/pr101267.f90: Likewise.
* gfortran.dg/pr112404.f90: Likew
This fixes a spurious invalid variable in specification expression error.
The problem is caused by improper restoration of formal_arg_flag to false
(instead of restoring it to its previous value). This happens with the
testcase from the PR where a dummy argument is itself a procedure with dummy
ar
Le 15/03/2024 à 20:32, Harald Anlauf a écrit :
Dear all,
as there has been some good progress in the handling of optional dummy
arguments, I looked again at this PR and a patch for it that I withdrew
as it turned out incomplete.
It turned out that it now needs only a minor adjustment for option
g
to push it before stage 1 so that I can get rid of it sooner.
On 3/17/24 17:57, Mikael Morin wrote:
* expr.cc (check_restricted): Remove the case where symbol is dummy
and declared in the current ns. Use gfc_get_spec_ns to get the
right namespace.
Looking at the original and n
Hello,
Le 22/02/2024 à 19:29, Anbazhagan, Karthiban a écrit :
(...)
gcc/config/i386/{znver4.md => zn4zn5.md} | 858 +-
looks like the patch pushed to master lost the file rename.
I get a bootstrap failure caused by the missing zn4zn5.md file.
Can you have a look?
Le 17/03/2024 à 23:10, Harald Anlauf a écrit :
Hi Mikael,
On 3/17/24 22:04, Mikael Morin wrote:
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 3673fa40720..a7717a8107e 100644
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -7526,6 +7526,17
hangelog text from second patch
- Target current stage (stage4) instead of next (stage1)
v1 -> v2 changes:
- Fix condition guarding sym->result access.
Mikael Morin (2):
testsuite: Declare fortran array bound variables
fortran: Fix specification expression error with du
This fixes invalid undeclared fortran array bound variables
in the testsuite.
gcc/testsuite/ChangeLog:
* gfortran.dg/graphite/pr107865.f90: Declare array bound variable(s)
as dummy argument(s).
* gfortran.dg/pr101267.f90: Likewise.
* gfortran.dg/pr112404.f90: Likew
This fixes a spurious invalid variable in specification expression error.
The error was caused on the testcase from the PR by two different bugs.
First, the call to is_parent_of_current_ns was unable to recognize
correct host association and returned false. Second, an ad-hoc
condition coming next
Le 20/03/2024 à 21:24, Harald Anlauf a écrit :
Hi Mikael, all,
here's now the third version of the patch that implements the following
scheme:
On 3/15/24 20:29, Mikael Morin wrote:
Le 15/03/2024 à 18:26, Harald Anlauf a écrit :
OK, that sounds interesting. To clarify the options:
Hello,
here is a fix for an ICE caused by dangling pointers to ISO_C_BINDING's
C_PTR symbol in the global intrinsic symbol for C_LOC.
I tried to fix it by making the intrinsic symbol use its own copy of
C_PTR, but it regressed heavily.
Instead, I propose this which is based on a patch I attached
Hell(o),
it didn't take long for my recent patch for PR111781 to show a regression.
The fix proposed here is actually the one Harald posted in the PR.
I can't imagine a case where it wouldn't do the right thing.
Regression tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
The patch fixing P
Hello,
I tested this on x86_64-pc-linux-gnu without regression.
There is no new test, as the problem is visible on an
existing test with valgrind or an asan-instrumented compiler.
OK for master?
-- >8 --
This change is a followup to the fix for PR48776 (namely
r14-3572-gd58150452976c4ca65ddc811
Hello,
Le 20/01/2024 à 22:58, Harald Anlauf a écrit :
Dear all,
here's the first part of an attempt to fix issues with optional
dummy arguments as actual arguments to optional dummies. This patch
rectifies the case of scalar dummies with the VALUE attribute,
which in gfortran's argument passin
Le 23/01/2024 à 21:36, Harald Anlauf a écrit :
Dear all,
here's the second part of a series for the treatment of missing
optional arguments passed to optional dummies, now fixing the
case that the latter procedures are elemental. Adjustments
were necessary when the missing dummy has the VALUE a
Le 24/01/2024 à 22:39, Harald Anlauf a écrit :
Dear all,
this patch is actually only a followup fix to generate the proper name
of an array reference in derived-type components for the runtime error
message generated for the bounds-checking code. Without the proper
part ref, not only a user may
Le 25/01/2024 à 22:26, Harald Anlauf a écrit :
Dear all,
this is the third patch in a series that addresses dummy arguments
with the VALUE attribute, now handling the passing of NULL actual
arguments. It is based on the refactoring in the previous patch
and reuses the handling of absent argumen
Le 29/01/2024 à 21:50, Harald Anlauf a écrit :
Am 29.01.24 um 18:25 schrieb Harald Anlauf:
I was talking about the generated format strings of runtime error
messages.
program p
implicit none
type t
real :: zzz(10) = 42
end type t
class(t), allocatable :: xx(:)
integer :: j
Le 30/01/2024 à 11:38, Mikael Morin a écrit :
Another (easier) way to clarify the data reference would be rephrasing
the message so that the array part is separate from the scalar part,
like so (there are too many 'of', but I lack inspiration):
Index '0' of dimension 1
101 - 200 of 1075 matches
Mail list logo
