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 --
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
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 --
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
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 --
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
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 --
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
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 --
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
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
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
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
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
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
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 à 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
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 à 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
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
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
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
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 --
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
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
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
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
fixed.From ca034694757f0fb3461a1d0c22708a3e4c0e40fa Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Sat, 5 Jul 2025 15:05:20 +0200
Subject: [PATCH] testsuite: Fix unallocated array usage in test
gcc/testsuite/ChangeLog:
* gfortran.dg/asan/array_constructor_1.f90: Allocate array
before using it.
---
gcc/testsuite/g
From: Mikael Morin
Regression tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Generate the array reallocation on assignment code before entering the
scalarization loops. This doesn't move the generated code itself,
which was already put before the outermost loop, but only cha
From: Mikael Morin
Regression tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Delay the evaluation of bounds, offset, etc after the reallocation,
for the scalarization of allocatable arrays on the left hand side of
assignments.
Before this change, the code preceding the scalarizat
From: Mikael Morin
Regression tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Always generate the conditional initialization of unallocated variables
regardless of the basic variable allocation tracking done in the
frontend and with an additional always false condition.
The scalari
From: Mikael Morin
Hello,
here are three patches as follow-up to this message.
These started as an attempt to remove the PR fortran/108889 workaround,
which I didn't understand.
I had to keep it in the end but this is what I could save from that
failed attempt.
Regression tested on x86_
Le 09/07/2025 à 08:50, Andre Vehreschild a écrit :
HI Harald, hi Mikael,
why shall the testcase be invalid? The `list` is empty. Concatenating with it
is valid in Fortran like in most other programming languages. The mapping of an
empty list in gfortran is to have the array's data pointer set to
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
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
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
Le 22/06/2025 à 21:09, Harald Anlauf a écrit :
Hi Mikael!
Am 20.06.25 um 12:08 schrieb Mikael Morin:
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
Ok for master?
-- >8 --
The temporary variables that are generated to implement SELECT TYPE
and TYPE IS statements h
Le 23/06/2025 à 09:17, Richard Biener a écrit :
On Sun, Jun 22, 2025 at 2:11 PM Mikael Morin wrote:
From: Mikael Morin
Changes v1 -> v2:
- Also handle complex conjugate operator.
That's OK.
- Don't create the NON_LVALUE_EXPR if there is a type conversion between th
This is what I've just pushed.
-- >8 --
gcc/ChangeLog:
* match.pd (`-(-X)`, `~(~X)`, `conj(conj(X))`): Add a
NON_LVALUE_EXPR wrapper to the simplification of doubled unary
operators NEGATE_EXPR, BIT_NOT_EXPR and CONJ_EXPR.
gcc/testsuite/ChangeLog:
* gfortran.dg/
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 simplification doesn't happen.
Those cases are not tested.
Regression tested on x86_64-linux. OK for master?
From: Mikael Morin
Changes v1 -> v2:
- Also handle complex conjugate operator.
- Don't create the NON_LVALUE_EXPR if there is a type conversion between the
doubled operators.
Regression tested on x86_64-linux. OK for master?
-- 8< --
gcc/ChangeLog:
* match.pd (`-(
From: Mikael Morin
Regression tested on x86_64-linux. OK for master?
-- 8< --
gcc/ChangeLog:
* match.pd (`-(-X)`, `~(~X)`): Add a NON_LVALUE_EXPR wrapper to the
simplification of doubled unary operators NEGATE_EXPR and
BIT_NOT_EXPR.
gcc/testsuite/Change
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
Ok for master?
-- >8 --
The temporary variables that are generated to implement SELECT TYPE
and TYPE IS statements have (before this change) a name depending only
on the type. This can produce confusing dumps with code hav
Le 18/06/2025 à 23:50, Thomas Koenig a écrit :
Hi Mikael,
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
Just wondering... how does this relate to the recent fix of PR120483
by Andre? Is this also a regression? If so, maybe a backport would be
in order.
Best regads
Thoma
Le 18/06/2025 à 16:51, Richard Biener a écrit :
On Wed, Jun 18, 2025 at 11:23 AM Mikael Morin wrote:
From: Mikael Morin
Hello,
I'm proposing here an interpretor/simulator of the gimple IR.
It proved useful for me to debug complicated testcases, where
the misbehaviour is not obvious i
Le 18/06/2025 à 23:22, Jerry D a écrit :
On 6/18/25 2:02 PM, Mikael Morin wrote:
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
Was there a PR for this? or something you just ran into?
I'm not aware of any PR. I was trying to create a testcase exerc
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_trans_deferred_array): Statically
initialize deferred length variable for SAVEd character arrays.
gcc/testsuite/Change
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
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 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
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 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 à 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 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 à 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 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 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
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 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
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'
*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 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,
-
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
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
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 --
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 --
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 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
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 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
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
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 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
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
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
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 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 à 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
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 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
Le 14/09/2024 à 20:02, Steve Kargl a écrit :
On Fri, Sep 13, 2024 at 12:27:07PM +0200, Mikael Morin wrote:
gcc/fortran/ChangeLog:
* invoke.texi(finline-intrinsics): Document new flag.
* lang.opt (finline-intrinsics, finline-intrinsics=,
fno-inline-intrinsics): New
Le 13/09/2024 à 18:56, Steve Kargl a écrit :
OK. Sorry about dropping the balli on a review.
I thought it had already been approved and committed.
No problem, it was not an important one anyway.
Thanks for the review, patch is now really pushed.
*PING*
Joseph, could you take a quick look at the handling of the new option?
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/661267.html
Le 23/08/2024 à 10:31, Mikael Morin a écrit :
From: Mikael Morin
The documentation in this patch was partly reworded, compared
to the previous
Ping:
https://gcc.gnu.org/pipermail/fortran/2024-July/060640.html
Maybe I could argue that I can self approve, as the patch is a partial
revert an old patch of mine:
https://gcc.gnu.org/r180889
Le 07/07/2024 à 11:00, Mikael Morin a écrit :
Hello,
this is another small cleanup I had lying
From: Mikael Morin
The documentation in this patch was partly reworded, compared
to the previous version posted at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660607.html
The rest of the patch is unchanged, just rebased to a more recent
master.
Joseph is in CC as I need a ack for the
From: Mikael Morin
Add the tests covering the various cases for which we are about to implement
inline expansion of MINLOC and MAXLOC. Those are cases where the DIM
argument is not present.
PR fortran/90608
gcc/testsuite/ChangeLog:
* gfortran.dg/ieee/maxloc_nan_1.f90: New
From: Mikael Morin
Enable generation of inline MINLOC/MAXLOC code in the case where DIM
is not present, and either ARRAY is of floating point type or MASK is an
array. Those cases are the remaining bits to fully support inlining of
non-CHARACTER MINLOC/MAXLOC without DIM. They are treated
From: Mikael Morin
Enable inline code generation for the MINLOC and MAXLOC intrinsic, if the
DIM argument is not present and ARRAY has rank 1. This case is similar to
the case where the result is scalar (DIM present and rank 1 ARRAY), which
already supports inline expansion of the intrinsic
From: Mikael Morin
Enable generation of inline code for the MINLOC and MAXLOC intrinsic,
if the ARRAY argument is of integral type and of any rank (only the rank 1
case was previously inlined), and neither DIM nor MASK arguments are
present.
This needs a few adjustments in
From: Mikael Morin
Continue the second set of loops where the first one stopped in the
generated inline MINLOC/MAXLOC code in the cases where the generated code
contains two sets of loops. This fixes a regression that was introduced
when enabling the generation of inline MINLOC/MAXLOC code with
From: Mikael Morin
Disable rewriting of MINLOC/MAXLOC expressions for which inline code
generation is supported. Update the gfc_inline_intrinsic_function_p
predicate (already existing) for that, with the current state of
MINLOC/MAXLOC inlining support, that is only the cases of a scalar
result
From: Mikael Morin
The next patch will need reindenting of the array bound check generation
code. This outlines it to its own function beforehand, reducing the churn
in the next patch.
-- >8 --
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_conv_ss_startstride): Move array bound ch
From: Mikael Morin
Enable the generation of inline code for MINLOC/MAXLOC when argument ARRAY
is of integral type, DIM is not present, and MASK is present and is scalar
(only absent MASK or rank 1 ARRAY were inlined before).
Scalar masks are implemented with a wrapping condition around the code
From: Mikael Morin
Remove the frontend pass rewriting calls of MINLOC/MAXLOC without DIM to
calls with one-valued DIM enclosed in an array constructor. This
transformation was circumventing the limitation of inline MINLOC/MAXLOC code
generation to scalar cases only, allowing inline code to be
1 - 100 of 1087 matches
Mail list logo
