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
From: Mikael Morin
This series of patches enable the generation of inline code for the MINLOC
and MAXLOC intrinsics, when the DIM argument is not present. The
generated code is based on the inline implementation already generated in
the scalar case, that is when ARRAY has rank 1 and DIM is
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 --
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 --
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
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
;>
wrote:
Hi Mikael,
You were absolutely right. I looked at the caller and "just didn't
get it". Thanks. I will resubmit when I get back from a business trip.
Cordialement
Paul
On Sat, 27 Jul 2024 at 12:35, Mikael Morin mailto:morin-mik...@orange
Le 27/07/2024 à 19:23, rep.dot@gmail.com a écrit :
On 22 July 2024 20:53:18 CEST, Mikael Morin wrote:
From: Mikael Morin
Hello,
this fixes a null pointer dereference with absent optional dummy passed
as BACK argument of MINLOC/MAXLOC.
Tested for regression on x86_64-linux.
OK for
Hello,
Le 27/07/2024 à 11:25, Paul Richard Thomas a écrit :
This patch is straightforward but I am still puzzled as to why it is
necessary for the particular case. Having looked at all the other chunks
of frontend code involving use renaming, it seems that the process just
works everywhere els
From: Mikael Morin
Hello,
this fixes a null pointer dereference with absent optional dummy passed
as BACK argument of MINLOC/MAXLOC.
Tested for regression on x86_64-linux.
OK for master?
-- >8 --
Protect the evaluation of BACK with a check that the reference is non-null
in case
From: Mikael Morin
Hello,
I'm currently testing this on x86_64-linux.
I plan to push to master if all goes well.
Mikael
-- 8< --
Add the preliminary code that the generated expression for MASK may depend
on when generating the inline code to evaluate MINLOC or MAXLOC with a
scalar MA
Le 11/07/2024 à 22:49, Harald Anlauf a écrit :
Hi Mikael,
Am 11.07.24 um 21:55 schrieb Mikael Morin:
From: Mikael Morin
Hello,
I discovered this while testing the inline MINLOC/MAXLOC (aka PR90608)
patches.
Regression tested on x86_64-linux.
OK for master?
this is a nice finding! (NAG
From: Mikael Morin
Hello,
I discovered this while testing the inline MINLOC/MAXLOC (aka PR90608) patches.
Regression tested on x86_64-linux.
OK for master?
-- 8< --
Move the evaluation of the BACK argument out of the loop in the inline code
generated for MINLOC or MAXLOC. For that, add a
Hello,
this is another small cleanup I had lying around.
Regression-tested on x86_64-linux. Ok for master?
-- 8< --
Remove the special handling of end of nested scalarization chains, which
advanced the chain to an element of a parent chain when the current one
was reaching its end.
That handli
Hello,
I have found this small cleanup lying in a local branch.
Regression-tested on x86_64-linux, OK for master?
-- 8< --
No change of behaviour, this makes a variable easier to track.
gcc/fortran/ChangeLog:
* trans-array.cc (gfc_trans_preloop_setup): Use a separate variable
f
Le 23/06/2024 à 22:58, Harald Anlauf a écrit :
Dear all,
the attached patch fixes issues exhibited by the testcase in comment#19 of
PR55978.
First, when passing an allocatable optional dummy array to an optional dummy,
we need to prevent accessing the data component of the array when the argum
Hello...
Le 23/05/2024 à 22:52, Andrew MacLeod a écrit :
A range-query currently provides a couple of relation query routines,
plus it also provides direct access to an oracle. This patch moves
those queries into the oracle where they should be, and ands the ability
to create and destroy the
Hello,
Le 17/05/2024 à 16:03, Aldy Hernandez a écrit :
If the intersection of the bitmasks made the range span the entire
domain, normalize the range to VARYING.
gcc/ChangeLog:
PR middle-end/115131
* value-range.cc (prange::intersect): Set VARYING if intersection
of bit
Le 23/05/2024 à 21:15, Harald Anlauf a écrit :
Hi Mikael,
On 5/23/24 09:49, Mikael Morin wrote:
Le 13/05/2024 à 09:25, Mikael Morin a écrit :
Le 10/05/2024 à 21:56, Harald Anlauf a écrit :
Am 10.05.24 um 21:48 schrieb Harald Anlauf:
Hi Mikael,
Am 10.05.24 um 11:45 schrieb Mikael Morin:
Le
Le 23/05/2024 à 09:49, Mikael Morin a écrit :
Le 13/05/2024 à 09:25, Mikael Morin a écrit :
Le 10/05/2024 à 21:56, Harald Anlauf a écrit :
Am 10.05.24 um 21:48 schrieb Harald Anlauf:
Hi Mikael,
Am 10.05.24 um 11:45 schrieb Mikael Morin:
Le 09/05/2024 à 22:30, Harald Anlauf a écrit :
I&#x
Le 13/05/2024 à 09:25, Mikael Morin a écrit :
Le 10/05/2024 à 21:56, Harald Anlauf a écrit :
Am 10.05.24 um 21:48 schrieb Harald Anlauf:
Hi Mikael,
Am 10.05.24 um 11:45 schrieb Mikael Morin:
Le 09/05/2024 à 22:30, Harald Anlauf a écrit :
I'll stop here...
Thanks. Go figure, I ha
Le 10/05/2024 à 21:56, Harald Anlauf a écrit :
Am 10.05.24 um 21:48 schrieb Harald Anlauf:
Hi Mikael,
Am 10.05.24 um 11:45 schrieb Mikael Morin:
Le 09/05/2024 à 22:30, Harald Anlauf a écrit :
I'll stop here...
Thanks. Go figure, I have no problem reproducing today.
It's PR99798
Hello,
Here is my final patch to fix the ICE of PR99798.
It's maybe overly verbose with comments, but the memory management is
hopefully clarified.
I tested this with a full fortran regression test on x86_64-linux and a
manual check with valgrind on the testcase.
OK for master?
-- 8< --
This pre
Le 10/05/2024 à 21:24, Harald Anlauf a écrit :
Dear all,
the attached simple and obvious patch fixes a bogus recursion error
with inquiry refs used statement functions. The commit message
says all there is to say...
Regtested on x86_64-pc-linux-gnu.
I intend to commit to mainline within the n
Le 09/05/2024 à 22:30, Harald Anlauf a écrit :
Hi Mikael,
Am 09.05.24 um 21:51 schrieb Mikael Morin:
Hello,
Le 06/05/2024 à 21:33, Harald Anlauf a écrit :
Dear all,
I've been contemplating whether to submit the attached patch.
It addresses an ICE-on-invalid as reported in the PR, and
Hello,
Le 06/05/2024 à 21:33, Harald Anlauf a écrit :
Dear all,
I've been contemplating whether to submit the attached patch.
It addresses an ICE-on-invalid as reported in the PR, and also
fixes an accepts-invalid (see testcase), plus maybe some more,
related due to incomplete checking of symbo
Le 09/05/2024 à 10:47, HAO CHEN GUI a écrit :
Hi Mikael,
Thanks for your comments.
在 2024/5/9 16:03, Mikael Morin 写道:
I think the canonical API behaviour sets R to varying and returns true instead
of just returning false if nothing is known about the range.
I'm not sure whether it
Hello,
Le 07/05/2024 à 04:37, HAO CHEN GUI a écrit :
Hi,
The former patch adds isfinite optab for __builtin_isfinite.
https://gcc.gnu.org/pipermail/gcc-patches/2024-April/649339.html
Thus the builtin might not be folded at front end. The range op for
isfinite is needed for value range ana
Hello,
Le 08/05/2024 à 07:27, Kewen.Lin a écrit :
Hi,
Previously effective target fortran_real_c_float128 never
passes on Power regardless of the default 128 long double
is ibmlongdouble or ieeelongdouble. It's due to that TF
mode is always used for kind 16 real, which has precision
127, while
Hello,
Le 28/04/2024 à 23:37, Paul Richard Thomas a écrit :
Hi All,
Could this be looked at quickly? The timing of this regression is more
than a little embarrassing on the eve of the 14.1 release. The testcase
and the comment in gfc_trans_class_init_assign explain what this problem
is all a
Hell(o),
it didn't take long for my recent patch for PR111781 to show a regression.
The fix proposed here is actually the one Harald posted in the PR.
I can't imagine a case where it wouldn't do the right thing.
Regression tested on x86_64-pc-linux-gnu.
OK for master?
-- >8 --
The patch fixing P
Hello,
here is a fix for an ICE caused by dangling pointers to ISO_C_BINDING's
C_PTR symbol in the global intrinsic symbol for C_LOC.
I tried to fix it by making the intrinsic symbol use its own copy of
C_PTR, but it regressed heavily.
Instead, I propose this which is based on a patch I attached
Le 20/03/2024 à 21:24, Harald Anlauf a écrit :
Hi Mikael, all,
here's now the third version of the patch that implements the following
scheme:
On 3/15/24 20:29, Mikael Morin wrote:
Le 15/03/2024 à 18:26, Harald Anlauf a écrit :
OK, that sounds interesting. To clarify the options:
This fixes a spurious invalid variable in specification expression error.
The error was caused on the testcase from the PR by two different bugs.
First, the call to is_parent_of_current_ns was unable to recognize
correct host association and returned false. Second, an ad-hoc
condition coming next
This fixes invalid undeclared fortran array bound variables
in the testsuite.
gcc/testsuite/ChangeLog:
* gfortran.dg/graphite/pr107865.f90: Declare array bound variable(s)
as dummy argument(s).
* gfortran.dg/pr101267.f90: Likewise.
* gfortran.dg/pr112404.f90: Likew
1 - 100 of 1025 matches
Mail list logo
