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
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
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
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
Introduce a new predicate to simplify conditionals checking for
a character type whose length is the constant one.
gcc/fortran/ChangeLog:
* gfortran.h (gfc_length_one_character_type_p): New inline
function.
* check.cc (is_c_interoperable): Use
gfc_length_one_charac
Use distinct error codes, so that we can spot directly from the
testsuite log which case is failing.
gcc/testsuite/ChangeLog:
* gfortran.dg/value_9.f90 (val, val4, sub, sub4): Take the error
codes from the arguments.
(p): Update calls: pass explicit distinct error codes.
-
Hello,
I ran into a bug recently, running dg-cmp-results.sh with variant
unix/-m32. This fixes it.
OK for master?
-- >8 --
Escape slash characters in $header variable (coming from the variant
argument). This avoids runs with say "unix/-m32" as variant resulting
in sed errors "unknown command:
If an actual argument is associated with an INTENT(OUT) dummy, and code
to deallocate it is generated, generate the class wrapper initialization
after the actual argument deallocation.
This is achieved by passing a cleaned up expression to
gfc_conv_class_to_class, so that the class wrapper initial
4-pc-linux-gnu. OK for master?
[1] https://gcc.gnu.org/pipermail/fortran/2023-July/059562.html
[2] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110618
Mikael Morin (3):
fortran: defer class wrapper initialization after deallocation
[PR92178]
fortran: Factor data references for scalar clas
In the case of a scalar actual arg passed to a polymorphic assumed-rank
dummy with INTENT(OUT) attribute, avoid repeatedly evaluating the actual
argument reference by saving a pointer to it. This is non-optimal, but
may also be invalid, because the data reference may depend on its own
content. In
In the case of an array actual arg passed to a polymorphic array dummy
with INTENT(OUT) attribute, reorder the argument evaluation code to
the following:
- first evaluate arguments' values, and data references,
- deallocate data references associated with an allocatable,
intent(out) dummy,
-
Hello,
I saw the light regarding this PR after Paul posted a comment yesterday.
Regression test in progress on x86_64-pc-linux-gnu.
I plan to push in the next hours.
Mikael
-- >8 --
Release symbols in reversed order wrt the order they were allocated.
This fixes an error recovery ICE in the cas
bmit a separate patch for the release branch with only patch 6
and 7 and the next->next->next indirections.
Regression-tested on x86_64-linux-gnu. Ok for master?
Mikael Morin (7):
fortran: new abstract class gfc_dummy_arg
fortran: Tiny sort_actual internal refactoring
fortran: Rever
Preliminary refactoring to make further changes more obvious.
No functional change.
gcc/fortran/
* intrinsic.c (sort_actual): initialise variable and use it earlier.
---
gcc/fortran/intrinsic.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/gcc/fortran/intrins
Introduce a new abstract class gfc_dummy_arg that provides a common
interface to both dummy arguments of user-defined procedures (which
have type gfc_formal_arglist) and dummy arguments of intrinsic procedures
(which have type gfc_intrinsic_arg).
gcc/fortran/
* gfortran.h (gfc_dummy_arg):
There was originally no way from an actual argument to get
to the corresponding dummy argument, even if the job of sorting
and matching actual with dummy arguments was done.
The closest was a field named actual in gfc_intrinsic_arg that was
used as scratch data when sorting arguments of one specif
This adds two methods to the abstract gfc_dummy_arg and makes
usage of them to simplify a bit the walking of elemental procedure
arguments for scalarization. As information about dummy arguments
can be obtained from the actual argument through the just-introduced
associated_dummy field, there is
Now that we can get information about an actual arg's associated
dummy using the associated_dummy attribute, the field missing_arg_type
contains redundant information.
This removes it.
gcc/fortran/
* gfortran.h (gfc_actual_arglist::missing_arg_type): Remove.
* interface.c (gfc_com
This reverts commit d09847357b965a2c2cda063827ce362d4c9c86f2 except for
its testcase.
gcc/fortran/
* intrinsic.c (add_sym_4ind): Remove.
(add_functions): Use add_sym4 instead of add_sym4ind.
Don’t special case the index intrinsic.
* iresolve.c (gfc_resolve_index_fu
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
method. It is otherwise completely ignored at runtime, and there is
no code generated for it as the library procedure has no kind argument.
This confuses the
parate patch for the release branch with only patch 6
and 7 and the next->next->next indirections.
Regression-tested on x86_64-linux-gnu. Ok for master?
[1] https://gcc.gnu.org/pipermail/fortran/2021-August/056303.html
Mikael Morin (7):
fortran: new wrapper class gfc_dummy_arg
f
Introduce a new wrapper class gfc_dummy_arg that provides a common
interface to both dummy arguments of user-defined procedures (which
have type gfc_formal_arglist) and dummy arguments of intrinsic procedures
(which have type gfc_intrinsic_arg).
gcc/fortran/
* gfortran.h (gfc_dummy_arg_ki
Preliminary refactoring to make further changes more obvious.
No functional change.
gcc/fortran/
* intrinsic.c (sort_actual): initialise variable and use it earlier.
---
gcc/fortran/intrinsic.c | 7 +++
1 file changed, 3 insertions(+), 4 deletions(-)
diff --git a/gcc/fortran/intrins
There was originally no way from an actual argument to get
to the corresponding dummy argument, even if the job of sorting
and matching actual with dummy arguments was done.
The closest was a field named actual in gfc_intrinsic_arg that was
used as scratch data when sorting arguments of one specif
This adds two functions working with the wrapper class gfc_dummy_arg
and makes usage of them to simplify a bit the walking of elemental
procedure arguments for scalarization. As information about dummy arguments
can be obtained from the actual argument through the just-introduced
associated_dummy
Now that we can get information about an actual arg's associated
dummy using the associated_dummy attribute, the field missing_arg_type
contains redundant information.
This removes it.
gcc/fortran/
* gfortran.h (gfc_actual_arglist::missing_arg_type): Remove.
* interface.c (gfc_com
This reverts commit d09847357b965a2c2cda063827ce362d4c9c86f2 except for
its testcase.
gcc/fortran/
* intrinsic.c (add_sym_4ind): Remove.
(add_functions): Use add_sym4 instead of add_sym4ind.
Don’t special case the index intrinsic.
* iresolve.c (gfc_resolve_index_fu
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
method. It is otherwise completely ignored at runtime, and there is
no code generated for it as the library procedure has no kind argument.
This confuses the
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
method. It is otherwise completely ignored at runtime, and there is
no code generated for it as the library procedure has no kind argument.
This confuses the
is the patch 2 of
the series, preceded with the revert in patch 1. I intend to commit both of
them squashed together.
Regression-tested on x86_64-linux-gnu. Ok for 11 branch?
[1] https://gcc.gnu.org/pipermail/fortran/2021-August/056317.html
Mikael Morin (2):
Revert "Remove KIND arg
This reverts commit d09847357b965a2c2cda063827ce362d4c9c86f2 except for
its testcase.
gcc/fortran/
* intrinsic.c (add_sym_4ind): Remove.
(add_functions): Use add_sym4 instead of add_sym4ind.
Don’t special case the index intrinsic.
* iresolve.c (gfc_resolve_index_fu
The fortran frontend, as result symbol for a function without
declared result symbol, uses the function symbol itself. This caused
an invalid clobber of a function decl to be emitted, leading to an
ICE, whereas the intended behaviour was to clobber the function result
variable. This change fixes
This change inlines the clobber generation code from
gfc_conv_expr_reference to the single caller from where the add_clobber
flag can be true, and removes the add_clobber argument.
What motivates this is the standard making the procedure call a cause
for a variable to become undefined, which trans
901 - 1000 of 1046 matches
Mail list logo
