On Wednesday 07 December 2011 17:45:52 Tobias Burnus wrote:
> This fixes a -frealloc-lhs regression where the RHS is handled by a
> "conversion function" whose argument has component refs.
>
> Build and regtested on x86-64-linux.
> OK for the trunk and 4.7?
>
> Tobias
OK.
Mikael
On Wednesday 07 December 2011 14:54:36 Tobias Burnus wrote:
> * ping * ?
>
> On 12/04/2011 06:46 PM, Tobias Burnus wrote:
> > Hi all,
> >
> > as Dominique has found, Fortran 2008 allows the BOZ edit descriptors
> > now also with REAL and COMPLEX arguments. (See PR for quotes from the
> > standard
On Friday 02 December 2011 22:01:19 Tobias Burnus wrote:
> Found via Reinhold Bader's test suite: If a component is public, it
> remains public even if the extended type has PRIVATE.
>
> Build and regtested on x86-64-linux.
> OK for the trunk?
>
OK.
Mikael
On Wednesday 07 December 2011 14:53:20 Tobias Burnus wrote:
> ** PING **
>
> On 11/29/2011 07:35 PM, Tobias Burnus wrote:
> > gfortran had an ICE when trying to insert a check whether the
> > character length between actual and dummy argument matches. This check
> > is pointless for deferred-lengt
nux-gnu. OK for 4.7/4.6/4.5[/4.4] ?
Mikael.
PS: Greetings for the new year.
2011-12-29 Mikael Morin
* trans-expr.c (gfc_conv_expr): Move address taking...
(gfc_conv_expr_reference): ... here.
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 8
On 31/12/2011 18:03, Tobias Burnus wrote:
> OK for the trunk?
>
OK
Thanks
Mikael
On Monday 02 January 2012 12:20:36 Tobias Burnus wrote:
> Hello Mikael,
>
> Mikael Morin wrote:
> > Regression tested on x86_64-unknown-linux-gnu. OK for 4.7/4.6/4.5[/4.4] ?
>
> OK - thanks for the comprehensive patch explanation and for the patch
> i
reate
the struct in the first place, as it is unused.
I'm currently regtesting the following patch. The testcase is the same
as your. OK for 4.7/4.6?
2012-01-09 Mikael Morin
* trans-array.c (gfc_walk_elemental_function_args):
Skip over NULL() actual arguments.
diff --g
On 09.01.2012 15:45, Tobias Burnus wrote:
On 01/09/2012 03:34 PM, Mikael Morin wrote:
The issue is that the code handling NULL() doesn't consume the gfc_ss
struct created for it. Your fix, which advances to the next one anyway
would work just well, but I think it is slightly cleaner t
On 18.01.2012 10:12, Tobias Burnus wrote:
Dear Janne,
the attached patch changes the binding labels that are needed for
bind(C) symbols to be heap allocated rather than, as currently, being
fixed size arrays of size 127 (or 64 in module.c!?).
wonder whether it would have been smarter to us
On 31.01.2012 23:22, Tobias Burnus wrote:
Dear all,
I have no idea about the scalarizer, but the attached patch fixes the
test case and somehow adding an array ref to a scalar looks odd to me ...
??
The condition is about an array without array ref, isn't it?
We can't access the "array" part o
On 31.01.2012 23:41, Tobias Burnus wrote:
Tobias Burnus wrote:
Unfortunately, it turns out that the check does not handle inheritance
well. At least I would expect that the attached test case is valid
(and it compiles with NAG 5.1), but it is rejected with GCC 4.6 and 4.7.
Actually, I withdra
sing.
Regression tested on x86_64-unknown-freebsd9.0. OK for trunk?
Mikael
2012-02-02 Mikael Morin
PR fortran/41587
PR fortran/46356
PR fortran/51754
PR fortran/50981
* class.c (insert_component_ref, class_data_ref_missing,
g
working part.
Regression tested on x86_64-unknown-freebsd9.0. OK for trunk?
Mikael
2012-02-07 Mikael Morin
* trans-array.c (gfc_get_proc_ifc_for_expr): New function.
(gfc_walk_elemental_function_args): Move code to
gfc_get_proc_ifc_for_expr and call it.
d
al in gfc_conv_procedure_call. We
need to make sure to save the value of se->ss, as gfc_conv_tmp_array_ref
or gfc_conv_expr_reference will advance it to the next in the chain.
Otherwise nothing special.
Regression tested on x86_64-unknown-freebsd9.0. OK for trunk?
Mikael
2012-02-12 Mikael Morin
*
is patch uses a helper
function to check the type without impacting the testsuite.
Regression tested on x86_64-unknown-freebsd9.0. OK for trunk?
Mikael
2012-02-12 Mikael Morin
* trans-expr.c (is_class_container_ref): New function.
(gfc_conv_procedure_call): Add a "_data&quo
Hello,
On Monday 13 February 2012 23:38:57 Paul Richard Thomas wrote:
> Mikael,
>
> This is OK for trunk with one proviso; could you move
> is_class_container_ref to gfc_is_class_container_ref in class.c?
>
> Thanks for the patch
>
I have a small hardware issue (overheating) preventing me from
On Tuesday 21 February 2012 16:55:09 Tobias Burnus wrote:
> Build and regtested on x86-64-linux.
> OK for the 4.8 trunk?
>
OK.
Mikael
PS: I think that, in general, we should _accept_ statements on MATCH_ERROR to
avoid issues of this kind.
On Saturday 18 February 2012 14:33:09 Tobias Burnus wrote:
> The patch consists of two parts:
>
> * The pointer check in gfc_check_vardef_context didn't honour
> polymorphic variables
>
> * Passing a TYPE to a CLASS is not allowed if CLASS is a pointer or
> allocatable as the actual argument cann
Hello,
On Tuesday 14 February 2012 12:42:21 Tobias Burnus wrote:
> Fortunately, -O0 is often sufficient to remove the reallocation code.
>
I guess you mean -O1 here...
> In turn, the warning might be printed even if at the end no realloc code is
> generated or present with -O1.
>
Can it be ca
On Tuesday 21 June 2011 17:08:17 Richard Guenther wrote:
> The following is a patch^Whack that should handle almost all
> array exprs. Well, tried on the following testcase:
>
> subroutine foo (dst, bar, ni, nj)
> integer, intent(in) :: ni, nj
> double precision, intent(in) :: bar(ni, nj)
>
on x86_64-unknown-freebsd8.2. OK for trunk? Should I
backport to the branches?
Mikael
2011-07-07 Mikael Morin
gcc/fortran
PR fortran/49648
* resolve.c (resolve_symbol): Force resolution of function result's
array specification.
gcc/testsuite
PR fortran/49648
* gfortran.dg/result_in_spec
On Thursday 07 July 2011 07:35:07 Tobias Burnus wrote:
> diff --git a/libgfortran/caf/mpi.c b/libgfortran/caf/mpi.c
> index 83f39f6..2d4af6b 100644
> --- a/libgfortran/caf/mpi.c
> +++ b/libgfortran/caf/mpi.c
> @@ -103,10 +110,19 @@ _gfortran_caf_register (ptrdiff_t size, caf_register_t
type,
>
On Saturday 09 July 2011 20:59:08 Tobias Burnus wrote:
> The regression seems to be a side effect of the -fwhole-file effort.
>
> The BT_UNKNOWN of the second argument of SIGNAL(NUMBER,HANDLER) triggers
> an ICE in trans-types.c, when generating the decl for the external
> function "signal" (or ra
On Monday 11 July 2011 09:49:20 Tobias Burnus wrote:
> On 07/10/2011 09:56 PM, Tobias Burnus wrote:
> > This patch implemented the trans*.c part of allocatable scalar
> > coarrays; contrary to noncoarray allocatable scalars, they have
> > cobounds and thus use an array descriptor.
>
> I found a te
On Saturday 16 July 2011 17:25:36 Tobias Burnus wrote:
> Mikael Morin wrote:
> > let me understand one thing about coarray scalars: despite their name,
> > they are arrays, right?
>
> Yes and no. In terms of the language, they are scalars - but they have a
> codimension, e
On Friday 15 July 2011 23:27:26 Tobias Burnus wrote:
> ptr(10,1:) => target was accepted as for the check "(10,1:)" was seen as
> equivalent to the valid "(10:, 1:)" - although the first dimension is
> not a range but an element. (Side note: (10:, 1:) would be wrong as well
> as one then needs to h
On Thursday 14 July 2011 11:01:29 Tobias Burnus wrote:
> As the title says: Mark "token" of static coarrays "restrict"
>
> Bootstrapped and regtested on x86-64-linux.
> OK for the trunk?
>
> Tobias
OK. (and obvious)
Mikael
On Monday 18 July 2011 21:37:24 Tobias Burnus wrote:
> As the coarray status is nontrivial to check, I have created a function
> for that - and I use it now for the interface checking. There are more
> cases, where the wrong check is used, leading to accepts-invalid and
> rejects-valid issues; howe
On Wednesday 27 July 2011 22:39:20 Tobias Burnus wrote:
> See discussion at http://gcc.gnu.org/ml/fortran/2011-07/msg00281.html
> and see PR 45586.
>
> This patch fixes the test case of the PR by properly using the
> nonrestricted type for pointer components. Before, the test case failed
> (ICE) i
On Saturday 30 July 2011 17:43:03 Janus Weil wrote:
> Hi all,
>
> the PR in the subject line contains several issues, and with the
> "duplicate save" part fixed, the attached patch takes care of the
> "missing type-bound procedure" regression (comment #6).
>
> The problem is the following: When p
On Saturday 16 April 2011 22:25:19 Tobias Burnus wrote:
> In simplify.c, currently an error is returned if the cobounds are
> exceeded. One should probably downgrade those to warnings.
OK with that change.
As far as I know, it is (weird but) valid to use the image_index result for
something comple
On Tuesday 19 April 2011 12:36:11 Tobias Burnus wrote:
> Build and regtested on x86-64-linux.
> OK for the trunk - and after some grace period - for the 4.6 branch?
Yes.
Do you think we could have a case where we have to delay module namespace
resolving as well (which we can't as we have to genera
On Thursday 21 April 2011 11:30:49 Richard Guenther wrote:
> Status
> ==
>
> A first release candidate for GCC 4.5.3 is beeing made. The branch
> is now frozen until after the final 4.5.3 release. All changes
> require explicit release manager approval.
>
>
> Quality Data
>
>
On Thursday 21 April 2011 16:02:18 Thomas Koenig wrote:
> Am 19.04.2011 20:35, schrieb Thomas Koenig:
> > Hello world,
> >
> > this patch fixes the enhancement PR, plus probably a few regressions.
> >
> > The basic problem was that the code walker got confused when *c, the
> > pointer to the curr
On Tuesday 26 April 2011 00:40:40 Thomas Koenig wrote:
> Am 22.04.2011 22:07, schrieb Thomas Koenig:
> > Hello world,
> >
> > the attached patch makes block names unique, so that
> > -fdump-fortran-original dumps are easier to read.
> >
> > Regression-tested. OK for trunk?
> >
> > Thomas
> >
>
On Tuesday 26 April 2011 18:52:58 Steve Kargl wrote:
> On Mon, Apr 25, 2011 at 11:15:35PM +0300, Janne Blomqvist wrote:
> > On Mon, Apr 25, 2011 at 22:45, Steve Kargl
> >
> > wrote:
> > > On Mon, Apr 25, 2011 at 10:26:20PM +0300, Janne Blomqvist wrote:
> > >> Hmm, I'd prefer if the warning was is
On Wednesday 27 April 2011 01:06:26 Steve Kargl wrote:
> > > Index: primary.c
> > > ===
> > > --- primary.c (revision 172974)
> > > +++ primary.c (working copy)
> > > @@ -541,6 +541,17 @@ match_real_constant (gfc_expr **result,
> >
On Tuesday 26 April 2011 23:41:17 Tobias Burnus wrote:
> This patch fixes three issues, (a) and (b) are 4.6/4.7 regressions.
>
> a) PR48112: Due to incomplete resolution, there was an ICE when writing
> the module file. Solution: Back-out the patch which introduced the
> incomplete resolution - an
On Wednesday 27 April 2011 23:10:14 Steve Kargl wrote:
> On Wed, Apr 27, 2011 at 10:54:37PM +0200, Mikael Morin wrote:
> > On Wednesday 27 April 2011 01:06:26 Steve Kargl wrote:
> > > It's an 'if -- else if' construct. If gfc_notify_std == FAILURE, then
> >
> --- a/gcc/fortran/decl.c
> +++ b/gcc/fortran/decl.c
> @@ -2995,7 +2995,7 @@ gfc_match_import (void)
>gfc_error ("Type name '%s' at %C is ambiguous", name);
>return MATCH_ERROR;
> }
> - else if (gfc_current_ns->proc_name->ns->parent != NULL
> +
On Wednesday 11 May 2011 15:20:38 Tobias Burnus wrote:
> As the PR shows, in the function the gfc_expr can be such that
> expr->value.function.esym points to the correct specific function but
> the generic expr->symtree->n.sym does not exist (expr->symtree == NULL).
> However, also the opposite can
On Saturday 12 March 2011 23:40:32 Thomas Koenig wrote:
> Hi Jerry,
>
> > On 03/12/2011 02:09 PM, Thomas Koenig wrote:
> >> Hello world,
> >>
> >> the attached patch fixes PR 48066, a regression introduced way back
> >> when. It is
> >> pretty self-explanatory. Regression-tested.
> >>
> >> OK fo
On Saturday 19 March 2011 19:59:56 Thomas Koenig wrote:
> Am 19.03.2011 00:23, schrieb Tobias Burnus:
> > I have not followed the discussion nor have I fully read the patch, but
> > what's the reason for allowing ELEMENTAL functions?
>
> Here's an updated version of the patch, which removes the el
> Here is the new version of the patch. Regression-tested. OK for trunk?
OK this time.
Thank you.
Mikael
Hello,
On Thursday 07 April 2011 21:50:46 Daniel Kraft wrote:
> Ok. Just my opinion (as non-native-speaker), though:
+@item -ffrontend-optimize
+@opindex @code{frontend-optimize}
+@cindex Front-end optimization
+This option performs front-end optimization, based on the Fortran parse
+tree. Ena
On Tuesday 05 April 2011 19:44:29 Tobias Burnus wrote:
> This patch adds multi-image support to UCOBOUND. In the -fcoarray=single
> case, the last dimension is just "LCOARRAY (coarray, dim=corank)".
> However, if there are multiple images, one has for corank-1 coarrays:
> "lcobound(coarray) + num_i
From: Mikael Morin
Checked on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Add the tests covering the cases for which the following patches will
implement inline expansion of MINLOC and MAXLOC. Those are cases where the
DIM argument is a constant value, and the ARRAY argument has rank grea
From: Mikael Morin
Bootstrapped and regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Enable generation of inline MINLOC/MAXLOC code in the cases where DIM is a
constant, and either ARRAY is of REAL type or MASK is an array. Those cases
are the remaining bits to fully supp
From: Mikael Morin
Hello,
this is the second (and last) series of patches to inline MINLOC and MAXLOC.
The previous series added support for inlining without DIM. This one
focuses on the cases where the DIM argument is present (and is a
constant), using the existing support for reduction
From: Mikael Morin
Bootstrapped and regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Enable generation of inline code for the MINLOC and MAXLOC intrinsics,
if the ARRAY argument is of integral type and of rank > 1 (only the rank 1
case was previously inlined), the DIM ar
From: Mikael Morin
Bootstrapped and regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Update the conditions used by the inline MINLOC/MAXLOC code generation
function to check directly the properties of MASK instead of the
variable holding its scalarization chain.
The inl
From: Mikael Morin
Bootstrapped and regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Enable the generation of inline code for MINLOC/MAXLOC when argument
ARRAY is of integral type and has rank > 1, DIM is a constant, and MASK is
scalar (only absent MASK or rank 1 ARRA
From: Mikael Morin
Bootstrapped and regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
In the function generating inline code to implement MINLOC and MAXLOC, only
check for ARRAY size along DIM if DIM is present.
The check for ARRAY emptyness had been checking the size of
From: Mikael Morin
Bootstrapped and regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Evaluate the BACK argument of MINLOC/MAXLOC once before the
scalarization loops in the case where the DIM argument is present.
This is a follow-up to r15-1
Hello,
Le 18/10/2024 à 18:48, Richard Sandiford a écrit :
[+ranger folks, who I forgot to CC originally, sorry!]
This patch applies X /[ex] Y cmp Z -> X cmp (Y * Z) when Y * Z is
representable.
(...)
diff --git a/gcc/match.pd b/gcc/match.pd
index b952225b08c..1b1d38cf105 100644
--- a/gcc/m
*PING*
The first series of patches was pushed, the second (and last) one [1][2]
is awaiting review.
[1] https://gcc.gnu.org/pipermail/gcc-patches/2024-October/665360.html
[2] https://gcc.gnu.org/pipermail/fortran/2024-October/061180.html
Le 30/10/2024 à 23:00, Harald Anlauf a écrit :
given that Jakub changed lots of whitespace in r15-4624-g50332a4fdd3243,
you may want to rebase your patches onto HEAD of trunk.
May I also suggest to attach the patches instead of mailing them inline?
Hello,
I checked with today's master, didn'
Le 28/10/2024 à 14:38, Andrew MacLeod a écrit :
On 10/26/24 15:08, Mikael Morin wrote:
Hello,
Le 24/10/2024 à 14:53, Andrew MacLeod a écrit :
diff --git a/gcc/range-op-ptr.cc b/gcc/range-op-ptr.cc
index dd312a80366..ef2b2cce516 100644
--- a/gcc/range-op-ptr.cc
+++ b/gcc/range-op-ptr.cc
Hello,
Le 24/10/2024 à 14:53, Andrew MacLeod a écrit :
diff --git a/gcc/range-op-ptr.cc b/gcc/range-op-ptr.cc
index dd312a80366..ef2b2cce516 100644
--- a/gcc/range-op-ptr.cc
+++ b/gcc/range-op-ptr.cc
(...)
-void
-pointer_or_operator::wi_fold (irange &r, tree type,
-
Le 23/09/2024 à 00:01, Andreas Schwab a écrit :
On Sep 22 2024, Arsen Arsenović wrote:
Andreas Schwab writes:
On Sep 22 2024, Jakub Jelinek wrote:
On Sun, Sep 22, 2024 at 10:52:37PM +0200, Andreas Schwab wrote:
On Sep 22 2024, Mikael Morin wrote:
@@ -370,7 +370,7 @@ Set the default
e 22/09/2024 à 16:27, Jakub Jelinek a écrit :
On Sun, Sep 22, 2024 at 04:17:11PM +0200, Mikael Morin wrote:
-@opindex @code{std=}@var{std} option
+@opindex std=@var{std} option
IMHO this one should be just
@opindex std=@var{std}
The option part is superfluous.
Yes, this one looked strange
Le 21/09/2024 à 16:32, Mikael Morin a écrit :
Le 19/09/2024 à 23:24, Jakub Jelinek a écrit :
(...)
Just note lang.opt.urls will need to be updated, either you do it
right away
with make regenerate-opt-urls or commit, wait for a nag-mail from CI and
commit incrementally the patch it creates
Le 19/09/2024 à 23:24, Jakub Jelinek a écrit :
On Mon, Sep 16, 2024 at 10:52:43AM +0200, Mikael Morin wrote:
While I understand the intent of 'positive form' vs 'negative form', the
above might be clearer as
Usage of intrinsics can be implemented either by generatin
From: Mikael Morin
Hello,
this adds many missing URLs in fortran's lang.opt.url.
Surprisingly, the change to fortran's invoke.texi also impacts URL files for
rust, m2, ada... I assume it's the expected outcome?
Thanks to Jakub for the doc pointers and the analysis help.
Ch
Checked with make html pdf. Pushed.From e9f341426567442a70747f89b6b954a005ca287a Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Thu, 26 Sep 2024 14:23:06 +0200
Subject: [PATCH] doc: Remove index reference to removed documentation in
fortran manual
Fortran option -M used to be an alias for
From: Mikael Morin
With this change, -ffixed-line-length-n and -ffree-line-length-n are the
only remaining options with variables appearing in the index. But I
think they are better left as-is.
I refrained from adding the missing syntactic variant in the
documentation of options allowing both
Le 26/09/2024 à 21:57, Thomas Koenig a écrit :
Now for the remaining intrinsics (FINDLOC, MAXLOC,
MINLOC, MAXVAL, MINVAL, CSHIFT and EOSHIFT still missing).
I have one patch series touching (inline) MINLOC and MAXLOC to post in
the coming days. Could you please keep away from them for one mor
Le 27/09/2024 à 17:08, Thomas Koenig a écrit :
Hi Mikael,
Now for the remaining intrinsics (FINDLOC, MAXLOC,
MINLOC, MAXVAL, MINVAL, CSHIFT and EOSHIFT still missing).
I have one patch series touching (inline) MINLOC and MAXLOC to post in
the coming days. Could you please keep away from them
Le 23/09/2024 à 20:43, Arsen Arsenović a écrit :
Andreas Schwab writes:
It's only about the @opindex. The vast majority have those variable
parts removed from the index entry.
We can probably do both at the same time, either via makeinfos -D option
and some special macro, or by emitting a m
Le 23/09/2024 à 20:37, Andreas Schwab a écrit :
On Sep 23 2024, Mikael Morin wrote:
For options where the variable is not a separate argument, I think it's
preferable to keep the variable.
For example, -ffree-line-length-@var{n} looks better on the index page as
"-ffree-line-lengt
Le 18/11/2024 à 20:18, Steve Kargl a écrit :
Mikael,
I've read through each of the patch and nothing jumped out
as an issue. I think you can go ahead and commit them. I'll
leave it up to you whether to commit a patch and wait a short
time before committing the next in the series. The short
t
Hello,
Le 08/01/2025 à 11:34, Andre Vehreschild a écrit :
The flag is used now to indicate, that a type can (indirectly) reference
itself. Not having the marker lead to endless recursion during construction of
copy or deallocate operations on an object of the type.
Can it be removed from the
Le 08/01/2025 à 14:13, Jakub Jelinek a écrit :
On Wed, Jan 08, 2025 at 01:40:20PM +0100, Mikael Morin wrote:
Le 08/01/2025 à 11:42, Jakub Jelinek a écrit :
The full list of changes with the posted patches is
(first a.mod, then b.mod, 14 -> 15) below.
I have no idea what adds those __co
Le 22/01/2025 à 22:55, Harald Anlauf a écrit :
Dear all,
while looking at details of a related but slightly different PR, I found
that we did evaluate the arguments to MINLOC/MAXLOC too often in the
inlined version.
The attached patch creates temporaries for array elements where needed,
and ens
Le 08/01/2025 à 18:37, Jakub Jelinek a écrit :
On Wed, Jan 08, 2025 at 06:23:40PM +0100, Andre Vehreschild wrote:
gcc/fortran/ChangeLog:
PR fortran/118337
* module.cc (use_iso_fortran_env_module): Prevent additional run
over (un-)signed ints and assign kind directly.
---
Le 08/01/2025 à 18:23, Andre Vehreschild a écrit :
First of all the recursive attr must not be set on vtypes, neither on module
ones nor anywhere else. Strictly speaking is a vtype recursive, because by its
extends member it references itself through a pointer. But it is guaranteed
that the base
Le 09/01/2025 à 18:12, Andre Vehreschild a écrit :
Hi Jakub,
Yes, that is what I had in mind. Being German I don't see any problem with the
explanation, but that is better judged by a native English speaker.
Is the send patch hunk intentional where only indentation is changed? I haven't
applied
Le 08/01/2025 à 12:16, Andre Vehreschild a écrit :
That sounds like a feasible solution when finding the erroneous (to my belief)
setting of flag takes longer than expect.
Mikael, do you know your way around the module export stuff and can you point
me directly to the line in question? I haven't
Le 08/01/2025 à 11:42, Jakub Jelinek a écrit :
The full list of changes with the posted patches is
(first a.mod, then b.mod, 14 -> 15) below.
I have no idea what adds those __copy_* elts etc. and whether they could be
forced to be in the middle rather than at the end and what is an ABI break
and
Le 09/03/2025 à 17:40, Thomas Koenig a écrit :
Hi Mikael,
_symbol *asym = a->expr->symtree->n.sym;
You may consider calling gfc_commit_symbol(s) instead at the end of
the function body. It might avoid leaking the old_symbol field in
case the function is called more than once or the symbol
Hello,
sorry to come late to the party.
Le 08/03/2025 à 13:52, Thomas Koenig a écrit :
diff --git a/gcc/fortran/interface.cc b/gcc/fortran/interface.cc
index edec907d33a..e3bc22f25e5 100644
--- a/gcc/fortran/interface.cc
+++ b/gcc/fortran/interface.cc
@@ -5836,6 +5836,8 @@ gfc_get_formal_from_
Le 28/02/2025 à 17:01, Filip Kastl a écrit :
diff --git a/gcc/gimple-ssa-sccopy.cc b/gcc/gimple-ssa-sccopy.cc
index 9f25fbaff36..7ffb5718ab6 100644
--- a/gcc/gimple-ssa-sccopy.cc
+++ b/gcc/gimple-ssa-sccopy.cc
@@ -568,6 +568,19 @@ scc_copy_prop::propagate ()
{
vec scc = worklist.pop
gcc/fortran/ChangeLog:
* trans.cc (get_final_proc_ref): New function.
(gfc_build_final_call): Outline the pointer evaluation code
to get_final_proc_ref.
---
gcc/fortran/trans.cc | 27 +--
1 file changed, 21 insertions(+), 6 deletions(-)
diff --git
gfc_add_finalizer_call creates one expression which is only used
by the get_final_proc_ref function. Move the expression generation
there.
gcc/fortran/ChangeLog:
* trans.cc (gfc_add_finalizer_call): Remove local variable
elem_size. Pass expression to get_elem_size and move the
gcc/fortran/ChangeLog:
* trans.cc (get_var_descr): New function.
(gfc_build_final_call): Outline the data reference descriptor
evaluation code to get_var_descr.
---
gcc/fortran/trans.cc | 149 ---
1 file changed, 83 insertions(+), 66
gcc/fortran/ChangeLog:
* trans.cc (get_elem_size): New function.
(gfc_build_final_call): Outline the element size evaluation
to get_elem_size.
---
gcc/fortran/trans.cc | 44 ++--
1 file changed, 30 insertions(+), 14 deletions(-)
dif
Function gfc_build_final_call has been simplified, inline it.
gcc/fortran/ChangeLog:
* trans.cc (gfc_build_final_call): Inline...
(gfc_add_finalizer_call): ... to its one caller.
---
gcc/fortran/trans.cc | 66 +---
1 file changed, 25 insert
gcc/fortran/ChangeLog:
* trans.cc (get_vptr): New function.
(gfc_add_finalizer_call): Move virtual table pointer evaluation
to get_vptr.
---
gcc/fortran/trans.cc | 33 ++---
1 file changed, 22 insertions(+), 11 deletions(-)
diff --git a/gcc/for
Reuse twice the same final procedure pointer expression instead of
translating it twice.
Final procedure pointer expressions were translated twice, once for the
final procedure call, and once for the check for non-nullness (if
applicable).
gcc/fortran/ChangeLog:
* trans.cc (gfc_add_finali
d and partially tested
with RUNTESTFLAGS="dg.exp=*final*".
The complete set has been fully tested on x86_64-pc-linux-gnu.
OK for master?
[1] https://gcc.gnu.org/pipermail/fortran/2023-July/059582.html
[2] https://gcc.gnu.org/pipermail/fortran/2023-July/059583.html
Mikael Morin (14):
f
Move cleanup code for the data descriptor after the finalization code
as it makes more sense to have it after.
Other cleanup blocks should be empty (element size and final pointer
are just data references), but add them by the way, just in case.
gcc/fortran/ChangeLog:
* trans.cc (gfc_add_
The same scalar descriptor generation code is present twice, in the
case of derived type entities, and in the case of polymorphic
non-coarray entities. Factor it in preparation for a future third case
that will also need the same code for scalar descriptor generation.
gcc/fortran/ChangeLog:
Final procedure pointer expression is generated in gfc_build_final_call
and only used in get_final_proc_ref. Move the generation there.
gcc/fortran/ChangeLog:
* trans.cc (gfc_add_finalizer_call): Remove local variable
final_expr. Pass down expr to get_final_proc_ref and move
get_var_descr get passed as argument both expr and expr->ts.
Remove the type argument which can be retrieved from the other
argument.
gcc/fortran/ChangeLog:
* trans.cc (get_var_descr): Remove argument ts. Use var->ts
instead.
(gfc_add_finalizer_call): Update caller.
---
The variable has_finalizer is only used in one place, inline its
definition there.
gcc/fortran/ChangeLog:
* trans.cc (gfc_add_finalizer_call): Inline definition of
variable has_finalizer. Merge nested conditions.
---
gcc/fortran/trans.cc | 16 +++-
1 file changed, 7
Add the possibility to provide a pre-evaluated class container argument
to gfc_add_finalizer to avoid repeatedly evaluating data reference
expressions in the generated code.
PR fortran/110618
gcc/fortran/ChangeLog:
* trans.h (gfc_add_finalizer_call): Add class container argument.
Pass already evaluated class container argument from
gfc_conv_procedure_call down to gfc_add_finalizer_call through
gfc_deallocate_scalar_with_status and gfc_deallocate_with_status,
to avoid repeatedly evaluating the same data reference expressions
in the generated code.
PR fortran/110618
x-gnu, and
powerpc64-unknown-linux-gnu (both -m32 and -m64).
OK for master?
[1] https://gcc.gnu.org/onlinedocs/gfortran/Argument-passing-conventions.html
Mikael Morin (3):
fortran: New predicate gfc_length_one_character_type_p
fortran: Fix length one character dummy arg type [PR110419]
test
Revision r14-2171-g8736d6b14a4dfdfb58c80ccd398981b0fb5d00aa
changed the argument passing convention for length 1 value dummy
arguments to pass just the single character by value. However, the
procedure declarations weren't updated to reflect the change in the
argument types.
This change does the m
901 - 1000 of 1075 matches
Mail list logo
