Regression tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Save subexpressions of array descriptor references to variables, so that
all the expressions using the descriptor as base object benefit from a
simplified reference using the variables.
This limits the size of the expressions gen
From: Mikael Morin
Regression-tested on aarch64-unknown-linux-gnu.
OK for master?
-- >8 --
Add the preliminary code produced for the evaluation of the FROM and TO
arguments of the MOVE_ALLOC intrinsic before using their values.
Before this change, the preliminary code was ignored and drop
Hello Andre,
I get a regression on this testcase with a patch that is otherwise
regression-free.
I think the testcase is invalid.
It does:
type(container), allocatable :: list(:)
list = [list, new_elem(5)]
so it's using the variable 'list' unallocated.
The original testcase in the
Le 16/07/2025 à 00:05, Steve Kargl a écrit :
On Sun, Jul 13, 2025 at 10:59:32AM +0200, Mikael Morin wrote:
Regression tested on x86_64-pc-linux-gnu.
OK for master?
Yes, with one observation below.
diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc
index 1561936daf1
Le 23/06/2025 à 09:34, Richard Biener a écrit :
On Sun, Jun 22, 2025 at 10:23 PM Mikael Morin wrote:
From: Mikael Morin
See the description in the ChangeLog entry below.
The testcases are best effort; for some operators the fortran frontend
generates a temporary variable, so the
From: Mikael Morin
gcc/fortran/ChangeLog:
* trans-decl.cc (gfc_trans_deferred_vars): Fix indentation.
---
gcc/fortran/trans-decl.cc | 16
1 file changed, 8 insertions(+), 8 deletions(-)
diff --git a/gcc/fortran/trans-decl.cc b/gcc/fortran/trans-decl.cc
index
From: Mikael Morin
PR 121185 exhibited wrong code examples where for assignements such as:
class_obj%non_poly = class_obj%non_poly * x
polymorphic references are (wrongly) used to access the left-hand-side
array.
This is caused by:
1. In the scalarizer, we delay (since r16-2248) evaluation
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
This is a follow-up to revision:
r16-2371-g8f41c87654fd819e48c9f6f1ac3d87e35794d310
fortran: Factor array descriptor references
That revision introduced new variables to limit repeated subexpressions
in ar
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Don't look for a class container too far after an array descriptor.
This avoids generating a polymorphic array reference, using the virtual
table of a parent object, to access a non-polymorphic child
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
This is a follow-up to:
r16-2248-gac8e536526393580bc9a4339bab2f8603eff8a47
fortran: Delay evaluation of array bounds after reallocation
That revision delayed the evaluation of array bounds, with changes
Hello,
here are a few more comments on the patch below.
It's not ready yet, but the remarks should be easily addressed.
diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index be984271d6a..c2a91c93d28 100644
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans
Le 27/07/2025 à 05:40, Yuao Ma a écrit :
Hi Mikael,
On 7/27/2025 3:57 AM, Mikael Morin wrote:
Hello,
here are a few more comments on the patch below.
It's not ready yet, but the remarks should be easily addressed.
Thanks for the thorough review! I've addressed the comments and a
I forgot to add:
+ else
+ {
+ if (pos < 1 || pos > (stringlen + 1))
+ runtime_error ("If BACK is present with the value true, the value
of "
+ "POS shall be in the range [1, LEN (STRING) + 1]");
+
can you provide the value of pos and stringlen in the error messages?
Le 27/07/2025 à 11:37, Yuao Ma a écrit :
On 7/27/2025 5:19 PM, Mikael Morin wrote:
+gfc_charlen_type
+string_split (gfc_charlen_type stringlen, const CHARTYPE *string,
+ gfc_charlen_type setlen, const CHARTYPE *set,
+ gfc_charlen_type pos, GFC_LOGICAL_4 back
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
The function gfc_array_init_size evaluates the number of array elements
to a variable from a caller, but the single caller providing the
variable actually doesn't use it.
This change removes the vari
Le 27/07/2025 à 13:46, Yuao Ma a écrit :
On 7/27/2025 7:14 PM, Mikael Morin wrote:
Le 27/07/2025 à 11:37, Yuao Ma a écrit :
On 7/27/2025 5:19 PM, Mikael Morin wrote:
+gfc_charlen_type
+string_split (gfc_charlen_type stringlen, const CHARTYPE *string,
+ gfc_charlen_type setlen
Le 29/07/2025 à 08:53, Paul Richard Thomas a écrit :
Hi Mikail,
I apologise for the delay between reviewing this patch and the first.
Some daytime work issues came up that I couldn't ignore.
This addition is fine, does as advertised and is good for mainline.
Oops, sorry thanks for the revi
From: Mikael Morin
The fortran frontend has getter and setter functions to generate code
either to read array descriptor fields or to write to them.
In some places, those functions are not used, and the access to the
field is generated manually.
The following patches replace those direct
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
In some places, a write to an array descriptor offset field was
generated simply by adding a modification of a reference to it that
was already available. This change uses the existing set
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
The function gfc_conv_descriptor_data_addr generates an address to the
data field of an array descriptor. It is only used once, and in the
single place where it is used, the address is immediat
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
In some places, a write to an array descriptor data field was generated
simply by adding a modification of a reference to it that was already
available. This change uses the existing setter function inst
Le 29/07/2025 à 09:01, Paul Richard Thomas a écrit :
I haven't had time to track them down
but there are other places where code has had to be inserted to prevent
non-polymorphic references in a polymorphic way. I wonder if they cannot
be unified at some time?
Are there? gfc_get_class_from_e
From: Mikael Morin
This one may look like a collection of obscure random changes.
It started with the removal of an isolated array descriptor offset
update, and the chain of regression fixes that followed completed it to
the below. I have even found a testcase that is fixed by it.
Regression
Le 30/07/2025 à 02:42, Yuao Ma a écrit :
On 7/27/2025 8:51 PM, Mikael Morin wrote:
Le 27/07/2025 à 13:46, Yuao Ma a écrit :
On 7/27/2025 7:14 PM, Mikael Morin wrote:
Le 27/07/2025 à 11:37, Yuao Ma a écrit :
On 7/27/2025 5:19 PM, Mikael Morin wrote:
+gfc_charlen_type
+string_split
From: Mikael Morin
In a comment, fix the closing brace of the tree layout definition of the
openmp allocate clause. It was confusing vim's matching brace support.
gcc/fortran/ChangeLog:
* trans-decl.cc (gfc_trans_deferred_vars): Fix closing brace in
a comment.
---
gcc/fo
From: Mikael Morin
These independant patches remove code generating isolated updates of the
array descriptor fields.
The rationale for doing this is that updates of array descriptors should
always be complete. It doesn't make sense to generate part of the
update in one place, and do the
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
The array constructor expansion extends the size of the array
dynamically, and sets the upper bound appropriately every time it
does. There is no need to do it again at the end of expansion.
gcc/fort
From: Mikael Morin
In this case the isolated field write causes wrong code.
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Remove an overwrite of the array descriptor span field when pointer-
assigning from a polymorphic function result to a non-polymorphic
pointer. T
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
In the initialization of associate variable array descriptors, remove
an overwrite of the span field. The descriptor that is returned by
gfc_conv_expr_descriptor should already be usable without it.
From: Mikael Morin
The gfc_se::use_offset field is set in a few places, but is nowhere
used. Remove it.
gcc/fortran/ChangeLog:
* trans.h (gfc_se): Remove field use_offset.
* trans-expr.cc (gfc_conv_intrinsic_to_class): Remove use_offset
initialization
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
The array descriptor returned by gfc_conv_expr_descriptor should be
usable as is. No need to overwrite the offset.
gcc/fortran/ChangeLog:
* trans-stmt.cc (trans_associate_var): Remove overwrite
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
A pointer has no default initialization; it is invalid to use it before
it is associated to a target. We can just as well leave its span field
uninitialized, and wait for the first pointer association
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Setting just the span in an otherwise uninitialized array descriptor to
pass to a function that will use the descriptor for its result (thus do
the initialization) doesn't seem to be useful.
gcc
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
For actual arguments whose dummy is INTENT(OUT), we used to generate
clobbers on them at the same time we generated the argument reference
for the function call. This was wrong if for an argument coming
later, the value expression was depending on the value of the just-
clobbered argument, and we
]
Mikael Morin (9):
fortran: Move the clobber generation code
fortran: Fix invalid function decl clobber ICE [PR105012]
fortran: Move clobbers after evaluation of all arguments [PR106817]
fortran: Support clobbering of reference variables [PR41453]
fortran: Support clobbering of SAVE
This is in spirit a revert of:
r9-3032-gee7fb0588c6361b4d77337ab0f7527be64fcdde2
That commit added a condition to avoid generating ICE with clobbers
of variables with the SAVE attribute.
The test added at that point continues to pass if we remove that
condition now.
PR fortran/87395
is no information
from the procedure interface.
gcc/testsuite/ChangeLog:
* gfortran.dg/intent_optimize_4.f90: New test.
Co-Authored-By: Mikael Morin
---
gcc/fortran/trans-expr.cc | 19 +++
.../gfortran.dg/intent_optimize_4.f90
This adds support for clobbering of allocatable and pointer scalar
variables passed as actual argument to a subroutine when the associated
dummy has the INTENT(OUT) attribute.
Support was explicitly disabled, but the clobber generation code seems
to support it well, as demonstrated by the newly add
This adds support for clobbering of variables passed by reference,
when the reference is forwarded to a subroutine as actual argument
whose associated dummy has the INTENT(OUT) attribute.
This was explicitly disabled and enabling it seems to work, as
demonstrated by the new testcase.
PR fo
This is probably the most risky patch in the series.
A previous version of this patch allowing all exactly matching derived
types showed two regressions. One of them uncovered PR106817 for which
I added a fix in this series, and for the other I have excluded
types with allocatable components from
This is in spirit a revert of:
r9-3051-gc109362313623d83fe0a5194bceaf994cf0c6ce0
That commit added a condition to avoid generating ICE with clobbers
of ASSOCIATE variables.
The test added at that point continues to pass if we remove that
condition now.
PR fortran/87397
PR fortran/
This adds support for clobbering of partial variable references, when
they are passed as actual argument and the associated dummy has the
INTENT(OUT) attribute.
Support includes array elements, derived type component references,
and complex real or imaginary parts.
This is done by removing the che
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
This is in spirit a revert of:
r9-3051-gc109362313623d83fe0a5194bceaf994cf0c6ce0
That commit added a condition to avoid generating ICE with clobbers
of ASSOCIATE variables.
The test added at that point continues to pass if we remove that
condition now.
PR fortran/87397
PR fortran/
This adds support for clobbering of variables passed by reference,
when the reference is forwarded to a subroutine as actual argument
whose associated dummy has the INTENT(OUT) attribute.
This was explicitly disabled and enabling it seems to work, as
demonstrated by the new testcase.
PR fo
[PR105012]
Mikael Morin (8):
fortran: Move the clobber generation code
fortran: Fix invalid function decl clobber ICE [PR105012]
fortran: Move clobbers after evaluation of all arguments [PR106817]
fortran: Support clobbering of reference variables [PR41453]
fortran: Support clobbering of SAVE
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 is probably the most risky patch in the series.
A previous version of this patch allowing all exactly matching derived
types showed two regressions. One of them uncovered PR106817 for which
I added a fix in this series, and for the other I have excluded
types with allocatable components from
This adds support for clobbering of allocatable and pointer scalar
variables passed as actual argument to a subroutine when the associated
dummy has the INTENT(OUT) attribute.
Support was explicitly disabled, but the clobber generation code seems
to support it well, as demonstrated by the newly add
For actual arguments whose dummy is INTENT(OUT), we used to generate
clobbers on them at the same time we generated the argument reference
for the function call. This was wrong if for an argument coming
later, the value expression was depending on the value of the just-
clobbered argument, and we
is no information
from the procedure interface.
gcc/testsuite/ChangeLog:
* gfortran.dg/intent_optimize_5.f90: New test.
Co-Authored-By: Mikael Morin
---
gcc/fortran/trans-expr.cc | 19 +++
.../gfortran.dg/intent_optimize_5.f90
This is in spirit a revert of:
r9-3032-gee7fb0588c6361b4d77337ab0f7527be64fcdde2
That commit added a condition to avoid generating ICE with clobbers
of variables with the SAVE attribute.
The test added at that point continues to pass if we remove that
condition now.
PR fortran/87395
4-pc-linux-gnu. OK for master?
Mikael Morin (4):
fortran: Pre-evaluate string pointers. [PR102043]
fortran: Update index extraction code. [PR102043]
fortran: Generate an array temporary reference [PR102043]
fortran: Use pointer arithmetic to index arrays [PR102043]
gcc/fortran/tran
This avoids a regression on deferred_character_23.f90 later in the
patch series when array references are rewritten to use pointer
arithmetic.
The problem is a SAVE_EXPR tree as TYPE_SIZE_UNIT of one array element
type, which is used by the pointer arithmetic expressions. As these
expressions app
1001 - 1100 of 1125 matches
Mail list logo
