Hello,
Le 30/11/2023 à 22:06, Harald Anlauf a écrit :
the attached rather obvious patch fixes the first testcase of pr112772:
we unconditionally generated copy-out code for optional class arguments,
while the copy-in properly checked the presence of arguments.
Regtested on x86_64-pc-linux-gnu.
https://gcc.gnu.org/pipermail/fortran/2023-November/059896.html
https://gcc.gnu.org/pipermail/gcc-patches/2023-November/635305.html
Changes from version 1:
* Add patch 1/3 to the series fixing the unallocated empty result issue.
* In patch 2/3 (formerly 1/2) clamp negative extent to zero.
Mikael Mor
Remove the early return present in function templates for transformational
functions doing a (masked) reduction of an array along a dimension.
This early return, which triggered if the extent in the reduction dimension
was zero, was wrong because even if the reduction operation degenerates to
a con
Le 07/11/2023 à 19:16, Harald Anlauf a écrit :
Hi Mikael,
this is OK.
Thanks for the patches!
Harald
Patches pushed.
Thanks for the (fruitful) review.
Le 17/11/2023 à 12:38, Tobias Burnus a écrit :
Unless there are follow up comments, I will commit it later today.
I skimmed quickly through the patch, and noticed one typo to fix:
> diff --git a/gcc/fortran/invoke.texi b/gcc/fortran/invoke.texi
> index 10387e39501..5f87b330a22 100644
> --- a/
Hello,
Le 20/11/2023 à 20:02, Steve Kargl a écrit :
Harald,
Sorry about delayed response. Got side-tracked by Family this weekend.
On Sun, Nov 19, 2023 at 09:46:46PM +0100, Harald Anlauf wrote:
On 11/19/23 01:04, Steve Kargl wrote:
On Sat, Nov 18, 2023 at 11:12:55PM +0100, Harald Anlauf wr
Le 21/11/2023 à 23:09, Harald Anlauf a écrit :
Uhh, it happened again. Attached a wrong patch.
Only looked at the -v3 ... My bad.
Sorry!
Harald
On 11/21/23 22:54, Harald Anlauf wrote:
Hi Mikael, Steve,
On 11/21/23 12:33, Mikael Morin wrote:
Harald, you mentioned the lack of
Le 22/11/2023 à 21:36, Harald Anlauf a écrit :
Hi Mikael!
On 11/22/23 10:36, Mikael Morin wrote:
(...)
diff --git a/gcc/fortran/error.cc b/gcc/fortran/error.cc
index 2ac51e95e4d..be715b50469 100644
--- a/gcc/fortran/error.cc
+++ b/gcc/fortran/error.cc
@@ -980,7 +980,11 @@ char const
Hello,
Le 22/11/2023 à 22:02, Harald Anlauf a écrit :
Dear all,
testcases assumed_rank_8.f90 and assumed_rank_10.f90 are invalid:
NULL() is passed without MOLD to an assumed-rank dummy argument.
This is detected by NAG, but not yet by gfortran (see pr104819).
gfortran even ignores the MOLD arg
Hello,
Le 23/11/2023 à 22:59, Harald Anlauf a écrit :
Dear all,
the PR is about a redundant obsolescence warning for COMMON when
a symbols appears in the scope of a submodule. As we did not warn
for use-associated symbols, it seemed natural to extend this to
symbols that are used in a submodul
Hello,
Le 27/09/2023 à 12:46, Jakub Jelinek a écrit :
--- gcc/vec.h.jj2023-09-27 10:38:50.635845540 +0200
+++ gcc/vec.h 2023-09-27 12:11:56.665586490 +0200
@@ -1028,13 +1050,17 @@ template
inline void
vec::truncate (unsigned size)
{
- gcc_checking_assert (length () >= size);
+
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
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
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
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'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 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 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 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
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
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
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
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
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
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 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
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
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 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
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
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
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
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
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
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
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
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
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
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
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
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 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
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
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
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
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
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
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
;>
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
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
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 --
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 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
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
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 --
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
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
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
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 à 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
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
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
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 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
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
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 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 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
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 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
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 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 à 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
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
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: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
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
*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
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.
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
(loop)->pre. The test-case is fixed by the
gfc_conv_ss_startstride hunks only, but I also added the set_loop_bounds
and gfc_set_delta hunks, as these function seemed to need the same fix.
Regression tested on x86_64-unknown-linux-gnu. OK for trunk/4.8?
Mikael
2013-08-20 Mikael Morin
Le 19/08/2013 13:38, Janus Weil a écrit :
> Hi all,
>
> here is a small patch which does some cleanup to avoid an ICE on
> invalid SELECT TYPE statements.
>
> The first three hunks are just cosmetics, and the fourth one also
> contains minor refactoring, where I pull some common code out of the
>
Le 22/08/2013 12:49, Janus Weil a écrit :
> Hi,
>
>>> Thus the condition should probably be
>>> else if (selector->ts.type == BT_DERIVED) as the BT_CLASS was handled
>>> before? OK with that change (if it works).
>>
>> Good point. And yes, it works.
>>
>> However, on second thought, I wonder why
Le 14/08/2013 23:46, Thomas Koenig a écrit :
> Hello world,
>
> the attached patch enables more sophisticated bounds-checking on
> array slices by using gfc_dep_difference to calculate extents.
> The information may also be useful in other places of the
> front end, I don't really know.
>
> There
Le 22/08/2013 17:41, Janus Weil a écrit :
> Hi all,
>
> here is a wrong-code fix for type-bound assignments, which makes sure
> that these are resolved to polymorphic procedure calls. This was not
> always the case, because we used the wrong ordering when checking for
> defined-assignment procedur
Hello,
Le 22/08/2013 15:20, Janus Weil a écrit :
> Hi all,
>
> the SIZEOF intrinsic currently returns the size according to the
> *declared* type for polymorphic variables. I think this doesn't really
> make much sense and it also causes ICEs when SIZEOF is called on
> CLASS(*) variables (which d
Le 22/08/2013 23:30, Mikael Morin a écrit :
> Le 14/08/2013 23:46, Thomas Koenig a écrit :
>> Hello world,
>>
>> the attached patch enables more sophisticated bounds-checking on
>> array slices by using gfc_dep_difference to calculate extents.
>> The information m
Le 26/08/2013 13:22, Janus Weil a écrit :
> Hi Mikael,
>
>>> the SIZEOF intrinsic currently returns the size according to the
>>> *declared* type for polymorphic variables. I think this doesn't really
>>> make much sense and it also causes ICEs when SIZEOF is called on
>>> CLASS(*) variables (whic
Le 26/08/2013 16:16, Janus Weil a écrit :
I'm slightly inclined to kindly invite the user to switch to
STORAGE_SIZE+SIZE instead. Any other opinion?
>>>
>>> Since the SIZEOF intrinsic has been around for some time in gfortran
>>> (before STORAGE_SIZE was available), I would say we should
Le 04/10/2012 12:17, Janus Weil a écrit :
>
> When backporting to 4.6 and 4.7, do you intend to also bump the module
> version there? Does that make sense?
>
If the module version is different from that of trunk, please don't, as
we would have two different module formats with the same module ver
Le 03/10/2012 18:48, Janus Weil a écrit :
> Hi all,
>
> here is a small patch for a wrong-code regression with polymorphic
> allocation. The problem is that we falsely detect the allocation
> variable to be a polymorphic array (although it is a scalar). For
> further details see the PR, in particu
Hello,
Le 04/10/2012 00:06, Janus Weil a écrit :
> Hi all,
>
> the attached patch implements an F08 feature, which allows to
> distinguish two specific procedures in a generic interface, based on
> the POINTER and ALLOCATABLE attribute of their arguments.
>
> In addition to this, the patch fixes
Le 07/10/2013 23:31, Tobias Burnus a écrit :
> The patch is rather obvious. The question is just why was the check
> there at the first place.
>
> Build and regtested on x86-64-gnu-linux.
> OK for the trunk?
>
OK. Thanks.
Mikael
).
Regression-tested on x86_64-unknown-linux-gnu. OK for trunk?
Mikael
2016-02-01 Mikael Morin
PR fortran/66089
* trans-expr.c (expr_is_variable, gfc_expr_is_variable): Rename
the former to the latter and make it non-static. Update callers.
* gfortran.h
Le 03/02/2016 14:00, Paul Richard Thomas a écrit :
Dear Mikael,
The patch is OK for trunk.
A small niggle: Although present in the original testcase, 'a' is unused.
Indeed, I'll remove it.
I am not in a position to find out for myself, right now, but does the
testcase of comment #10 work wi
Le 20/02/2016 19:35, Paul Richard Thomas a écrit :
The only way that I know to do
this reliably is to drop the use of a has and to use the extended type
names directly. This will take a bit of work!
Maybe the vtab pointer can be used to discriminate between types?
There is one vtab struct for e
is bumped.
Regression tested on x86_64-unknown-linux-gnu. OK for trunk?
I plan to submit a variant that doesn't change the module format for the
branches (doing more parsing by hand).
Mikael
2014-01-02 Mikael Morin
PR fortran/58007
* module.c (MOD_VERSION): Bu
Le 02/01/2014 18:40, Janus Weil a écrit :
> Hi all,
>
> I have just committed as obvious a one-line-removal patch which fixes
> a wrong-code OOP regression:
>
> http://gcc.gnu.org/viewcvs/gcc?view=revision&revision=206281
>
Sometimes computer programming is more witchcraft than (computer) scienc
201 - 300 of 1075 matches
Mail list logo
