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
From: Mikael Morin
Hello,
this is the third version of the inline MINLOC/MAXLOC without DIM patchset
whose second version was posted before at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-August/660599.html
Compared to the previous version, it contains a change of wording of the
Hello,
Le 19/08/2024 à 21:44, Harald Anlauf a écrit :
Hi Mikael,
apart from patch #04/10, which did not apply cleanly here, I was
able to test your patch. It seems to work with a manual workaround
(-fno-frontend-optimize) to work around this problem.
Might be a local issue...
Huh? That's unex
From: Mikael Morin
This patch is new in the V2 series.
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
Introduce the -finline-intrinsics flag to control from the command line
whether to generate either inline code or calls to the functions from the
library, for the MIN
From: Mikael Morin
Compared to the previous version of the patch at
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658916.html
this uses the IEEE_ARITHMETIC module to generate NAN values in the
tests. This change required to move the affected tests to a separate file
in the ieee
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
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 ran
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
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
From: Mikael Morin
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, DIM is not present, and MASK is present and is scalar
(only absent MASK or rank 1 ARRAY were inlined bef
From: Mikael Morin
Hello,
this is the second version of the inline MINLOC/MAXLOC without DIM patchset
whose first version was posted before at:
https://gcc.gnu.org/pipermail/gcc-patches/2024-July/658909.html
Appart from the NAN skipping conditional likeliness which is left unchanged,
it takes
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
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 supp
From: Mikael Morin
This patch is new in the V2 series.
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
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 circumvent
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.
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
gcc/fortran/ChangeLog:
* tr
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
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 argume
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
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
MIN
Le 07/08/2024 à 12:03, Harald Anlauf a écrit :
Hi Mikael, Thomas!
Am 07.08.24 um 11:11 schrieb Mikael Morin:
Hello,
Le 06/08/2024 à 22:57, Thomas Koenig a écrit :
Hi Mikael and Harald,
- inline expansion is inhibited at -Os. But wouldn't it be good if
we make this expansion
Hello,
Le 06/08/2024 à 22:05, Harald Anlauf a écrit :
Hi Mikael,
thanks for this nice set of patches!
I've played around a bit, and it seems to look good.
I have only minor comments left (besides the nan issue raised):
- inline expansion is inhibited at -Os. But wouldn't it be good if
we
Hello,
Le 06/08/2024 à 22:57, Thomas Koenig a écrit :
Hi Mikael and Harald,
- inline expansion is inhibited at -Os. But wouldn't it be good if
we make this expansion also dependent on -ffrontend-optimize?
(This was the case for rank-1 before your patch).
By the way, I disabled the min
Hello,
Le 05/08/2024 à 21:25, Harald Anlauf a écrit :
Is there a reason you do not use the ieee intrinsic module way
to get a quiet nan? Otherwise, how do you prevent exceptions
to happen, possibly leading to a failing test?
(The test cases need a workaround to run with NAG).
indeed, I didn't
Le 05/08/2024 à 10:59, Jakub Jelinek a écrit :
On Fri, Aug 02, 2024 at 06:29:27PM +0200, Mikael Morin wrote:
I agree with all of that. Sure keeping the condition around would be the
safest. I'm just afraid of keeping code that would remain dead.
And the pasto fix would gues
Le 02/08/2024 à 17:05, Jakub Jelinek a écrit :
On Fri, Aug 02, 2024 at 04:58:09PM +0200, Mikael Morin wrote:
But the function actually returns 0 rather than 1 that PR45019 meant.
So I bet in addition to fixing the pasto we should move that conditional
from where it is right now to the return 0
Le 02/08/2024 à 10:12, Jakub Jelinek a écrit :
On Thu, Aug 01, 2024 at 09:03:39PM +0200, Mikael Morin wrote:
Le 01/08/2024 à 12:00, Jakub Jelinek a écrit :
Hi!
A static analyzer found what seems like a pasto in the PR45019 changes,
the second branch of || only accesses sym2 while the first
h! It's good to see so much progress...
Best regards
Thomas
Thanks to you and Bernhard.
This is what I'm going to push.From 40122a405386a8b67c11bbaad523ffce5c1c7855 Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Fri, 2 Aug 2024 14:24:34 +0200
Subject: [PATCH] fortran: Supp
Hello,
Le 01/08/2024 à 12:00, Jakub Jelinek a écrit :
Hi!
A static analyzer found what seems like a pasto in the PR45019 changes,
the second branch of || only accesses sym2 while the first one sym1 except
for this one spot.
Not sure I'm able to construct a testcase for this though.
What is r
Le 01/08/2024 à 12:30, Jakub Jelinek a écrit :
On Thu, Aug 01, 2024 at 12:12:38PM +0200, Mikael Morin wrote:
Yes, I've always wondered how much of a win these integer_zerop checks were,
probably not that much. In the cases we know they are useless, let's remove
them (patch pre-ap
Hello,
Le 01/08/2024 à 10:53, Jakub Jelinek a écrit :
Hi!
A static analyzer found a pasto in gfc_get_array_descr_info.
The code does
t = base_decl;
if (!integer_zerop (dtype_off))
t = fold_build_pointer_plus (t, dtype_off);
dtype = TYPE_MAIN_VARIANT (get_dtype_type
From: Mikael Morin
Tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
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/testsu
From: Mikael Morin
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, DIM is not present, and MASK is present and is scalar
(only absent MASK or rank 1 ARRAY were inlined bef
From: Mikael Morin
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
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
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.
Regression-tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
gcc/fortran/ChangeLog:
* tr
1 - 100 of 1059 matches
Mail list logo
