Le 20/12/2021 à 23:05, Harald Anlauf via Fortran a écrit :
Dear all,
we need to check the arguments of the elemental MASKL and MASKR
intrinsics also before simplifying.
Testcase by Gerhard. The fix is almost obvious, but I'm happy to
get feedback in case there is something I overlooked. (Ther
Le 26/12/2021 à 21:09, FX via Fortran a écrit :
OK to commit?
This looks good, yes. Thanks.
Le 06/01/2022 à 20:50, Harald Anlauf a écrit :
Did you find the time to try your version?
Not yet. But I have not (yet) forgotten about this.
lFrom c1c17a43e172ebc28f2cd247f6e83c5fdbc6219f Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Fri, 7 Jan 2022 22:34:59 +0100
Subject: [PATCH] Fortran: Ignore KIND argument of a few more intrinsics. [PR103789]
After PR97896 for which some code was added to ignore the KIND argument
of the
Le 09/01/2022 à 15:10, Mikael Morin a écrit :
pulling the latest master brought me a broken bootstrap
It was a user error (of course).
Bootstrap and regression test and commit pending.
Now tested and committed as
r12-6386-gc1c17a43e172ebc28f2cd247f6e83c5fdbc6219f
Le 03/01/2022 à 20:45, Harald Anlauf via Fortran a écrit :
Dear all,
the initial-data-target for a pointer initialization can be either
NULL() or a non-constant target. In the latter case subscripts of
the target specification (or substring starting and ending points)
must be constant expressio
Le 09/01/2022 à 11:52, FX via Fortran a écrit :
ping
Le 2 janv. 2022 à 11:50, FX a écrit :
Hi,
This is the first part of a three-patch series to fix PR 82207
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207), making gfortran handle
signaling NaNs. This part fixes the library code imple
Le 06/01/2022 à 22:44, Mikael Morin a écrit :
Le 06/01/2022 à 20:50, Harald Anlauf a écrit :
Did you find the time to try your version?
Not yet. But I have not (yet) forgotten about this.
I have looked at it, and it enables infinite mutual recursion between
gfc_intrinsic_func_interface and
Le 12/01/2022 à 21:29, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
the attached patch improves error recovery after an invalid
structure constructor has been detected in a DATA statement.
Testcase by Gerhard.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
This should be a rathe
Hello,
Le 10/01/2022 à 18:32, FX via Fortran a écrit :
Hi,
Second part of a three-patch series to fix PR 82207
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82207), making gfortran handle
signaling NaNs. This part fixes the library code implementing IEEE_VALUE. To do
so, I switched that part
Hello,
I have just pushed the attached patch after testing the impacted tests
individually.
MikaelFrom 15630e6e9eb019477d1fc5c0966b43979e18ae18 Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Sun, 16 Jan 2022 18:33:36 +0100
Subject: [PATCH] testsuite: Enrich tests with variants failing on
I managed to break a working patch by splitting it.
Now fixed.
From d7a44809924297a2ff26b6b1d040c72c22f07346 Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Mon, 17 Jan 2022 11:45:46 +0100
Subject: [PATCH] Fortran: Ignore KIND argument of a few more intrinsics.
[PR103789]
After PR97896 for
Hello,
Le 17/01/2022 à 00:11, FX via Fortran a écrit :
This patch is the third in my “signaling NaN” series. For targets with IEEE
support but without the issignaling macro in libc (i.e., everywhere except
glibc), this allows us to provide a fallback implementation. In order to keep
the code
Le 23/01/2022 à 11:05, FX a écrit :
Hi Mikael,
I spotted two unexpected things (to me at least) related to x86 extended type:
- You check for endianness, so the format is not x86-specific?
- Is it expected that the padding bits are in the middle of the data in the
big-endian case?
IEEE speci
Le 26/01/2022 à 21:59, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
the use of -fdefault-integer-8 exhibits several cases where
we missed to convert the result of an intrinsic from the
declared to the effective resulting type.
The attached obvious patch fixes this for IMAGE_STATUS,
TEA
Le 23/01/2022 à 22:08, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
conversions between different character kinds using TRANSFER exhibit
inconsistencies that can occur between expr->representation.string
(which is char*) on the one hand, and expr->->value.character.string.
One issue (i
00:00:00 2001
From: Mikael Morin
Date: Fri, 28 Jan 2022 22:00:57 +0100
Subject: [PATCH] fortran: Unshare associate var charlen [PR104228]
PR104228 showed that character lengths were shared between associate
variable and associate targets. This is problematic when the associate
target is itself a
Hello,
Le 29/01/2022 à 22:41, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
compiling with -fsanitize=undefined shows that we did mishandle the
case where a missing optional argument is passed to another procedure.
Besides the example given in the PR, the existing testcase
fortran.dg/m
Hello
Le 06/02/2022 à 22:14, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
some instances of valid constant array constructors did lead to ICEs.
It turned out that on the one hand we need to attempt simplification of
elements of the constructor, especially when we encounter parenthesize
Le 23/02/2022 à 23:21, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
Fortran 2018 added a QUIET= specifier to STOP and ERROR STOP statements.
Janne already implemented the library side code four (4!) years ago,
but so far the frontend implementation was missing.
Furthermore, F2018 allow
Le 28/02/2022 à 15:27, Kwok Cheung Yeung a écrit :
On 28/02/2022 2:07 pm, Jakub Jelinek wrote:
(...)
Don't we usually test instead || (*expr)->rank != 0 when testing for
scalars?
(...)
So (*expr)->rank is 0 here even with an array. I'm not sure why - is
rank updated later, or did we forget
Le 28/02/2022 à 17:00, Jakub Jelinek a écrit :
On Mon, Feb 28, 2022 at 04:54:24PM +0100, Mikael Morin wrote:
Le 28/02/2022 à 15:27, Kwok Cheung Yeung a écrit :
On 28/02/2022 2:07 pm, Jakub Jelinek wrote:
(...)
Don't we usually test instead || (*expr)->rank != 0 when testing for
Le 28/02/2022 à 19:38, Kwok Cheung Yeung a écrit :
In gfc_expression_rank, e->ref is non-NULL, so e->rank is not set from
the symtree. It then iterates through the ref elements - ref->type ==
REF_ARRAY and ref->u.ar.type == AR_ELEMENT, so e->rank remains at 0.
This is the expected behavior.
Le 28/02/2022 à 21:37, Mikael Morin a écrit :
Maybe corank should be checked together with rank?
Lesson learned today: expressions don’t have a corank.
Does pr104131-2.f90 really need to be rejected?
Le 16/02/2022 à 22:20, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
while we detect invalid uses of type(*), we may run into other issues
later when the declared variable is used, leading to an ICE due to a
NULL pointer dereference. This is demonstrated by Gerhard's testcase.
Steve an
Le 28/02/2022 à 22:32, Mikael Morin a écrit :
So please use a condition on expr->ts.type instead.
I said «instead», but «as well» is more appropriate; both expr.ts.type
and expr.ts.u.derived conditions are probably necessary.
Le 28/02/2022 à 22:37, Jakub Jelinek a écrit :
On Mon, Feb 28, 2022 at 09:45:10PM +0100, Mikael Morin wrote:
Le 28/02/2022 à 21:37, Mikael Morin a écrit :
Maybe corank should be checked together with rank?
Lesson learned today: expressions don’t have a corank.
There is gfc_is_coindexed
So, if I try to sum up what has been gathered in this thread:
- pr104131.f90 is invalid, as x is not scalar.
Checks are better done in resolve_omp_clauses after a call
to gfc_resolve_expr.
Checking expr->sym->attr.dimension seems to cover more cases than
expr->rank > 0.
- pr104131-
Le 01/03/2022 à 23:18, Harald Anlauf via Fortran a écrit :
I do hope I got you right. The attached patch fixes your variant
as well as the original testcase, and regtests fine.
Just to be sure: is this what you were thinking of?
Indeed, that’s what I had in mind.
Nice, I didn’t expect that th
targeted
at all the open branches so this one as well.
OK for 11/10/9?
From af11a90c730a57be86b94331f31a611b31276b83 Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Sun, 13 Mar 2022 22:22:55 +0100
Subject: [PATCH] fortran: Separate associate character lengths earlier
[PR104570]
MIME-Version
tested on x86_64-pc-linux-gnu. OK for master?
MikaelFrom ff9de8b00e5eedf44af0ce75d268dce216bf645f Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Wed, 20 Apr 2022 12:04:38 +0200
Subject: [PATCH] fortran: Detect duplicate unlimited polymorphic types
[PR103662]
MIME-Version: 1.0
Content-Type: text
Le 21/04/2022 à 23:14, Mikael Morin a écrit :
Hello,
this is a fix for PR103662, a TBAA issue with unlimited polymorphic types.
I attached a draft patch to the PR which was accumulating all unlimited
polymorphic symbols to a single namespace, avoiding duplicate symbols
and thus eliminating the
Ping for the four patches starting at
https://gcc.gnu.org/pipermail/fortran/2022-April/057759.html :
https://gcc.gnu.org/pipermail/fortran/2022-April/057757.html
https://gcc.gnu.org/pipermail/fortran/2022-April/057760.html
https://gcc.gnu.org/pipermail/fortran/2022-April/057758.html
https://gcc.g
I have just pushed the attached fix for two UNRESOLVED checks at
-O0 that I hadn’t seen.From 6cc26f3037a18b9a958b4ac2a1363149a7fccd39 Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Mon, 25 Apr 2022 13:14:20 +0200
Subject: [pushed] =?UTF-8?q?testsuite:=C2=A0add=20additional=20option=20to
Le 25/04/2022 à 14:12, Jakub Jelinek a écrit :
On Mon, Apr 25, 2022 at 01:38:25PM +0200, Mikael Morin wrote:
I have just pushed the attached fix for two UNRESOLVED checks at -O0 that I
hadn’t seen.
I don't like forcing of DSE in -O0 compilation, wouldn't it be better
to just not che
-linux-gnu.
I plan to push it tonight.From 85d57fb88203697d7e52d5f1f148eab35e4f7486 Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Tue, 26 Apr 2022 13:05:32 +0200
Subject: [PATCH] fortran: Avoid infinite self-recursion [PR105381]
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content
Le 26/04/2022 à 15:32, Jakub Jelinek a écrit :
On Tue, Apr 26, 2022 at 03:22:08PM +0200, Tobias Burnus wrote:
LGTM - however:
On 26.04.22 14:38, Mikael Morin wrote:
--- a/gcc/fortran/trans-array.cc
+++ b/gcc/fortran/trans-array.cc
@@ -3698,7 +3698,8 @@ non_negative_strides_array_p (tree expr
Hello,
this fixes a regression caused by my recent PR103662 patch.
Regression tested on x86_64-pc-linux-gnu. OK for master?From d7309a471c42e51e84c37d5d4a3fd5bb0ed67405 Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Mon, 25 Apr 2022 19:47:04 +0200
Subject: [PATCH] fortran: Compare non
Le 26/04/2022 à 19:12, Mikael Morin a écrit :
Le 26/04/2022 à 15:32, Jakub Jelinek a écrit :
or one can repeat it like:
if (DECL_P (expr)
&& DECL_LANG_SPECIFIC (expr)
&& GFC_DECL_SAVED_DESCRIPTOR (expr)
&& GFC_DECL_SAVED_DESCRIPTOR (expr
Le 29/04/2022 à 22:10, Thomas Koenig via Fortran a écrit :
the attached patch documents the support for IEEE long double for
Fortran. OK? Suggestions for better wording?
I'd like to get this in before the gcc12 release. It would also
qualify as obviously correct, I think :-) so I'll commit
Le 08/05/2022 à 22:17, Harald Anlauf via Fortran a écrit :
Dear all,
the PR correctly notes that a space between keywords 'TYPE' and 'IS' is
required in free-form, but we currently accept 'TYPEIS'. We shouldn't.
The combinations with non-optional blanks are listed in the standard;
in F2018 this
Le 09/05/2022 à 21:34, Harald Anlauf a écrit :
Hi Mikael,
Am 09.05.22 um 20:24 schrieb Mikael Morin:
The fix itself looks good. Regarding the test, I don’t understand the
problem. Can’t there be multiple subroutines, each having one (or more)
problematic statement(s)?
that's why I
Le 09/05/2022 à 22:20, Harald Anlauf via Fortran a écrit :
Dear Fortranners,
we were lacking checks for arguments of type TEAM_TYPE to some
coarray intrinsics (FORM TEAM, CHANGE TEAM, and SYNC TEAM).
The attached patch adds these, and as a bonus verifies that
TEAM NUMBER is a scalar integer.
Re
Hello,
I don’t like the _Float128 vs __float128 business, it’s confusing.
And accordinog to https://gcc.gnu.org/onlinedocs/gcc/Floating-Types.html
they seem to be basically the same thing, so it’s also redundant.
Is there a reason why the standard one, _Float128, can’t be used everywhere?
Mikae
Le 27/06/2022 à 09:54, Jakub Jelinek a écrit :
Still, using __float128 when the APIs are declared for __float128 and
_Float128 when the APIs are declared for _Float128 can be better for
consistency.
I agree with that.
I was implicitly suggesting to change the libquadmath API to use the
standar
Le 02/07/2022 à 13:18, Thomas Koenig a écrit :
>
> One thought: If we have to bite the bullet and break the ABI, why not go
> all the way and use the C descriptors in ISO_Fortran_binding.h as
> gfortran's native format?
>
As far as I know, CFI descriptors are mutually exclusive with
non-negative
Hello,
the principle looks good, but...
Le 18/07/2022 à 22:43, Harald Anlauf via Fortran a écrit :
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 2ebf076f730..dacd33561d0 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -5004,7 +5004,11 @@ find_array_spec
Le 19/07/2022 à 21:09, Harald Anlauf via Fortran a écrit :
Hi Mikael,
Am 19.07.22 um 11:03 schrieb Mikael Morin:
Hello,
the principle looks good, but...
Le 18/07/2022 à 22:43, Harald Anlauf via Fortran a écrit :
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 2ebf076f730
Le 19/07/2022 à 23:34, Harald Anlauf a écrit :
Committed: r13-1757-gf838d15641d256e21ffc126c3277b290ed743928
Thanks.
Le 21/07/2022 à 22:12, Harald Anlauf via Fortran a écrit :
Dear all,
the rank check for ASSOCIATED (POINTER, TARGET) did not allow all
rank combinations that were allowed in pointer assignment for
newer versions of the Fortran standard (F2008+). Fix the logic.
So, if I understand correctly th
Le 25/07/2022 à 18:01, Harald Anlauf a écrit :
Hi Mikael, all,
a discussion in the Intel compiler forum suggests that the F2018
standard prohibits such use of the ASSOCIATED intrinsic.
https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-rejects-ASSOCIATED-pointer-target-for-non-equal-ra
Le 25/07/2022 à 22:39, Harald Anlauf via Fortran a écrit :
Dear all,
we currently may ICE when array bounds of a dummy argument have
a non-integer type, and the procedure with the bad declaration is
referenced. The same applies to bad character length of dummies.
We could simply punt in such a
Le 25/07/2022 à 22:18, Harald Anlauf a écrit :
I would normally trust NAG more than Intel and Cray.
… and yourself, it seems. Too bad.
If somebody else convinces me to accept that NAG has it wrong this time, I
would be happy to proceed.
It won’t convince you about NAG, but here are two rea
Hello,
Le 27/07/2022 à 21:45, Harald Anlauf via Fortran a écrit :
ok, I have thought about your comments in the review process,
and played with the Cray compiler. Attached is a refined version
of the patch that now rejects in addition these cases for which there
are no possible related pointer
Hello,
Le 28/07/2022 à 22:11, Harald Anlauf via Fortran a écrit :
Dear all,
in free-form mode, blanks are significant, so they cannot appear
in literal constants, especially not before or after the "_" that
separates the literal and the kind specifier.
The initial patch from Steve addressed nu
Le 29/07/2022 à 21:59, Harald Anlauf via Fortran a écrit :
Am 29.07.22 um 13:11 schrieb Mikael Morin:
> and use gfc_next_char instead of gfc_match_char
in get_kind.
There is one important functionality in gfc_match_char(): it manages
the locus. We would need then to add this explicitly
Le 29/07/2022 à 23:09, Harald Anlauf via Fortran a écrit :
Hi Mikael,
Am 29.07.22 um 22:36 schrieb Mikael Morin:
Indeed, I overlooked that, but my opinion remains that we shouldn’t
play with fixed vs free form considerations here.
So the options I can see are:
- handle the locus in get_kind
Le 28/07/2022 à 22:19, Mikael Morin a écrit :
I propose to prepare something tomorrow.
Here you go. I haven’t found a procedure, a template or guidelines on
wg5-fortran.org, so I’m just asking questions as free text.
I have not put every combination of cases to limit the number of
examples
Le 30/07/2022 à 21:40, Harald Anlauf a écrit :
Hi Mikael,
Am 30.07.22 um 10:28 schrieb Mikael Morin:
Meh! We killed one check for gfc_current_form but the other one is still
there.
OK, match_kind_param calls two functions that also gobble space, so
there is work remaining here.
So please make
Le 30/07/2022 à 12:03, Mikael Morin a écrit :
Le 28/07/2022 à 22:19, Mikael Morin a écrit :
I propose to prepare something tomorrow.
Here you go.
I posted the message the other day.
The mailing list archive are not automatic, so there is no link to the
message (yet?), nor to the thread
Hello,
Tobias approved it already, but I spotted what looks like typos.
See below.
Mikael
gcc/
* common.opt (static-libquadmath): New option.
* gcc.c (driver_handle_option): Always accept -static-libquadmath.
* config/darwin.h (LINK_SPEC): Handle -static-libquadmath.
Le 20/08/2022 à 10:41, Jakub Jelinek via Fortran a écrit :
Hi!
As discussed earlier, all other -static-lib* options are Driver only,
these 2 are Driver in common.opt and Fortran in lang.opt.
The spec files never pass the -static-lib* options down to any compiler
(f951 etc.), so the 2 errors bel
Le 20/08/2022 à 21:11, Harald Anlauf via Fortran a écrit :
Dear all,
the simplification of the TRANSFER intrinsic produces a
redundant representation of the result, one in expr->value
and another in expr->representation.string. This is done
to ensure a safe "round-trip" for nested TRANSFER.
In
Le 04/09/2022 à 22:04, Harald Anlauf via Fortran a écrit :
Dear all,
said PR was addressed by Jose in
https://gcc.gnu.org/pipermail/fortran/2021-April/055949.html
but unfortunately his patch was never reviewed.
IMHO the patch is mostly fine, with one small exception that
it should use POIN
Le 10/09/2022 à 12:14, FX via Fortran a écrit :
If you have a solution for the standards checking, I’ll add it.
As a first step, one could check the use rename lists; what's done for
iso_fortran_env can be used as an example.
To diagnose the other usages, the check could be put in resolve_sym
Le 11/09/2022 à 11:57, FX a écrit :
As a first step, one could check the use rename lists; what's done for
iso_fortran_env can be used as an example.
Yes, but iso_fortran_env is handled entirely in front-end, not through external
files.
That's true, but the standard check doesn't really dep
Le 02/09/2022 à 13:37, FX via Fortran a écrit :
Hi,
These operations were added to Fortran 2018, and correspond to well-defined
IEEE comparison operations, with defined signaling semantics for NaNs. All are
implemented in terms of GCC expressions and built-ins, with no library support
needed.
Le 04/09/2022 à 18:30, FX via Fortran a écrit :
Hi,
The IEEE_MODES_TYPE type and the two functions that get and set it were added
in Fortran 2018. They can be implemented using the already existing
target-specific functions. A future optimization could, on some targets,
set/get all modes th
Le 17/09/2022 à 19:03, Thomas Koenig via Fortran a écrit :
Hi Mikael,
This adds support for clobbering of partial variable references, when
they are passed as actual argument and the associated dummy has the
INTENT(OUT) attribute.
Support includes array elements, derived type component referen
Le 17/09/2022 à 21:33, Mikael Morin a écrit :
The testcase from the patch was not specifically checking lack of
side-effect clobbers, so I have double-checked with the following
testcase, which should lift your concerns.
The dump matches didn’t fail as expected with patch 2/10 reversed.
This
Le 18/09/2022 à 08:12, Richard Biener a écrit :
On Sat, Sep 17, 2022 at 9:33 PM Mikael Morin wrote:
Le 17/09/2022 à 19:03, Thomas Koenig via Fortran a écrit :
I have a concern about this part, though. My understanding at the
time was that it is not possible to clobber an individual array
Le 18/09/2022 à 12:23, Thomas Koenig a écrit :
I think some of the desired behavior can still be salvaged. For
example, for
(...)
clobbers for the whole array can still be generated, but not for
call foo(a(2),2)
so one would have to look at the lower bound.
Well, my patches were for
Le 18/09/2022 à 20:32, Harald Anlauf a écrit :
Assumed shape will be on the easy side,
while assumed size likely needs to be excluded for clobbering.
Isn’t it the converse that is true?
Assumed shape can be non-contiguous so have to be excluded, but assumed
size are contiguous, so valid candi
Le 18/09/2022 à 22:55, Mikael Morin a écrit :
Assumed shape can be non-contiguous so have to be excluded,
Thinking about it again, assumed shape are probably acceptable, but
there should be a check for contiguousness on the actual argument.
Le 18/09/2022 à 12:48, Richard Biener a écrit :
Does *(&a[1]) count as a pointer dereference?
Yes, technically.
Even in the original dump it is already simplified to a straight a[1].
But this not anymore. The check can probably be relaxed, it stems from the
dual purpose of CLOBBER.
S
Hello,
I'm coming (late) to this.
Le 31/08/2022 à 20:29, FX via Fortran a écrit :
This adds new F2018 features, that are not really enabled (because their
runtime support is optional).
(...)
2. Add the optional RADIX argument to IEEE_SET_ROUNDING_MODE and
IEEE_GET_ROUNDING_MODE. It is unu
Le 19/09/2022 à 18:17, FX a écrit :
Hi,
2. Add the optional RADIX argument to IEEE_SET_ROUNDING_MODE and
IEEE_GET_ROUNDING_MODE. It is unused for now, because we do not support
floating-point radices other than 2.
If we accept the argument, we have to support it somehow.
So for IEEE_GET_ROUN
Le 19/09/2022 à 21:46, Harald Anlauf a écrit :
Am 18.09.22 um 22:55 schrieb Mikael Morin:
Le 18/09/2022 à 20:32, Harald Anlauf a écrit :
Assumed shape will be on the easy side,
while assumed size likely needs to be excluded for clobbering.
Isn’t it the converse that is true?
Assumed shape
Le 20/09/2022 à 08:54, Thomas Koenig a écrit :
On 19.09.22 22:50, Mikael Morin wrote:
Le 19/09/2022 à 21:46, Harald Anlauf a écrit :
Assumed size (*) is just a contiguous hunk of memory of possibly
unknown size, which can be zero. So you couldn't set a clobber
for the a(1) actual arg
Hello,
Le 19/09/2022 à 22:17, Harald Anlauf via Fortran a écrit :
Dear all,
the following patch was submitted by Jose but never reviewed:
https://gcc.gnu.org/pipermail/fortran/2021-April/055946.html
Before, we didn't set function attributes properly when
passing polymorphic pointers, which co
Le 21/09/2022 à 11:57, Thomas Koenig a écrit :
Hi Harald,
I think I understand much of what is said, but I feel that I do
not really understand what *clobber* means for the different
beasts we are discussing (although I have an impression of what
it means for a scalar object).
Obviously, "cl
Le 22/09/2022 à 22:42, Harald Anlauf via Fortran a écrit :
Hi Mikael,
thanks for this impressive series of patches.
Am 18.09.22 um 22:15 schrieb Mikael Morin via Fortran:
The first patch is a refactoring moving the clobber generation in
gfc_conv_procedure_call where it feels more appropriate
Le 23/09/2022 à 09:54, Mikael Morin a écrit :
Le 22/09/2022 à 22:42, Harald Anlauf via Fortran a écrit :
I was wondering if you could add a test for the change in patch 7
addressing the clobber generation for an associate-name, e.g. by
adding to testcase intent_optimize_7.f90 near the end
Le 27/09/2022 à 21:05, Harald Anlauf via Fortran a écrit :
Dear all,
invalid input may trigger an assert while trying to simplify an
expression involving the intrinsic UNPACK and when the constructor
is lacking sufficient valid elements. The obvious solution is to
replace the assert by a condit
Hello,
Le 02/10/2022 à 22:07, Thomas Koenig via Fortran a écrit :
I am a bit stuck of how to generate a reference to the first element
of the array (really, just dereferencing the data pointer)
in the most elegant way. I am currently leaning towards
building a gfc_expr, which should work, but
Hello
Le 04/10/2022 à 23:19, Harald Anlauf via Fortran a écrit :
Dear all,
we did not recover well from bad expressions in array constructors,
especially when there was a typespec and a unary '+' or '-', and
when the array constructor was used in an arithmetic expression.
The attached patch in
Le 05/10/2022 à 10:51, Mikael Morin a écrit :
Unfortunately, it doesn't fix the bogus incommensurate arrays errors.
The following does.
diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index e6e35ef3c42..2c57c796270 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/ari
Hello
Le 04/10/2022 à 21:27, Harald Anlauf via Fortran a écrit :
Dear all,
when looking at output item lists we didn't catch procedures
and procedure pointers and ran into a gfc_internal_error().
Such items are not allowed by the Fortran standard, e.g. for
procedure pointers there is
C1233 (R1
Le 05/10/2022 à 22:40, Harald Anlauf a écrit :
Hi Mikael,
Gesendet: Mittwoch, 05. Oktober 2022 um 12:34 Uhr
Von: "Mikael Morin"
Please move the check to resolve_transfer in resolve.cc.
I have done this, see attached updated patch.
Regtests cleanly on x86_64-pc-linux-gnu.
Stra
Le 05/10/2022 à 23:40, Harald Anlauf a écrit :
There is one last thing that I'm dissatisfied with.
The handling of unknown types should be moved to reduce_binary, because
the dispatching in reduce_binary doesn't handle EXPR_OP, so even if
either or both operands are scalar, they are handled by
Le 06/10/2022 à 10:37, Mikael Morin a écrit :
Le 05/10/2022 à 22:40, Harald Anlauf a écrit :
Hi Mikael,
Gesendet: Mittwoch, 05. Oktober 2022 um 12:34 Uhr
Von: "Mikael Morin"
Please move the check to resolve_transfer in resolve.cc.
I have done this, see attached updated patch.
Le 06/10/2022 à 23:36, Harald Anlauf a écrit :
For example, for this case:
[real :: 2] * [real :: +(.true.)]
First there is a "root" invocation of reduce binary with arguments [real
:: 2] and [real :: +(.true.)]
The root invocation of reduce_binary will call reduce_binary_aa. This is
normal.
Le 07/10/2022 à 20:46, Harald Anlauf a écrit :
OK, that is because reduce_binary dispatches the reduce_binary_*.
We could move the check from reduce_binary_aa to the beginning of
reduce_binary, as with the following change on top of the patch:
diff --git a/gcc/fortran/arith.cc b/gcc/fortran/ari
Le 07/10/2022 à 21:47, Mikael Morin a écrit :
Let me have a look.
The attached patch works with your test, I just moved the checks into
the loops.
I'm now checking the patch against the full fortran testsuite.
I'm (finally) fine with that version, what do you think
Le 23/09/2022 à 09:54, Mikael Morin a écrit :
Le 22/09/2022 à 22:42, Harald Anlauf via Fortran a écrit :
This LGTM. It also fixes a regression introduced with r9-3030 :-)
If you think that this set (1-3) is backportable, feel free to do so.
Yes, 2 and 3 are worth backporting, I will see how
Le 11/10/2022 à 20:47, Harald Anlauf via Fortran a écrit :
Dear all,
this PR is an obvious followup to PR107000, where invalid
types appeared in array constructors and lead to an ICE
either in a conversion or reduction of a unary or binary
expression.
The present PR shows that several other con
Le 11/10/2022 à 22:23, Harald Anlauf via Fortran a écrit :
Dear all,
we need to check that the operands of arithmetic binary operations
are consistent and of numeric type.
The PR reported an issue for multiplication ("*"), but we better
extend this to the other binary operations.
I chose the f
Le 09/10/2022 à 20:57, Harald Anlauf via Fortran a écrit :
Dear all,
the check of data transfer elements needs to verify that for
polymorphic objects there is a user defined DTIO procedure.
This check worked fine for scalars, but skipped arrays,
leading to an ICE later.
The obvious fix is to al
Le 16/10/2022 à 20:46, Harald Anlauf via Fortran a écrit :
Dear all,
this PR is actually very related to PR107217 that addressed ICEs
with bad array constructors with typespec when used in arithmetic
expressions. The present patch extends the checking to logical
operations and to comparisons an
Le 15/10/2022 à 22:15, Harald Anlauf via Fortran a écrit :
Dear all,
here is an updated version of the patch that includes suggestions
and comments by Mikael in PR93483.
Basic new features are:
- a new enum value ARITH_NOT_REDUCED to keep track if we encountered
an expression that was not re
1 - 100 of 483 matches
Mail list logo
