Le 01/06/2023 à 17:20, Paul Richard Thomas via Fortran a écrit :
Hi All,
This started out as the search for a fix to pr109948 and evolved to roll in
5 other prs.
Basically parse_associate was far too clunky and, in anycase, existing
functions in resolve.cc were well capable of doing the determi
Hello,
Le 01/06/2023 à 21:05, Harald Anlauf via Fortran a écrit :
Dear all,
we sometimes silently accept wrong declarations with unbalanced
parentheses, as the PR and testcases therein show.
It appears that the fix is obvious: use the existing error paths in
gfc_match_kind_spec and error retur
Le 08/06/2023 à 07:57, Paul Richard Thomas via Fortran a écrit :
Hi Harald,
In answer to your question:
void
gfc_replace_expr (gfc_expr *dest, gfc_expr *src)
{
free_expr0 (dest);
*dest = *src;
free (src);
}
So it does indeed do the job.
Sure, but his comment was about the case gfc_rep
Le 08/06/2023 à 11:58, Tamar Christina via Gcc-patches a écrit :
Hi,
New version of the patch, I've omitted the explanation again 😊
Bootstrapped Regtested on aarch64-none-linux-gnu and no issues.
Any feedback?
Hello,
this is not my area of expertise, but I saw the following:
+ /* [ns..ns
Le 10/06/2023 à 22:28, FX Coudert via Fortran a écrit :
See https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109373
I don’t believe it is widely used, and it was removed from everywhere else in
gcc.
Bootstrapped and regtested on x86_64-pc-linux-gnu.
OK to commit?
FX
OK, thanks.
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
Hello,
I spotted a few nits. See below.
Le 20/07/2022 à 00:10, Andrew MacLeod via Gcc-patches a écrit :
diff --git a/gcc/gimple-range-cache.cc b/gcc/gimple-range-cache.cc
index da7b8055d42..20dd5ead3bc 100644
--- a/gcc/gimple-range-cache.cc
+++ b/gcc/gimple-range-cache.cc
@@ -1312,6 +1312,38 @
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 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
Hello,
Le 31/07/2023 à 19:07, Andrew Pinski via Gcc-patches a écrit :
diff --git a/gcc/generic-match-head.cc b/gcc/generic-match-head.cc
index a71c0727b0b..ddaf22f2179 100644
--- a/gcc/generic-match-head.cc
+++ b/gcc/generic-match-head.cc
@@ -121,3 +121,45 @@ bitwise_equal_p (tree expr1, tree ex
Hello,
Le 13/08/2023 à 23:16, Harald Anlauf via Fortran a écrit :
Hi Mikael,
Am 09.08.23 um 22:21 schrieb Mikael Morin via Gcc-patches:
Hello,
(...)
I have regression tested this on x86_64-unknown-linux-gnu, and
powerpc64-unknown-linux-gnu (both -m32 and -m64).
OK for master?
this looks
Le 20/06/2023 à 18:30, Tobias Burnus a écrit :
On 20.06.23 18:19, Paul Richard Thomas via Fortran wrote:
Is there a better way to detect a type(c_ptr) formal argument?
u.derived->intmod_sym_id == ISOCBINDING_PTR ?
&& u.derived->from_intmod == INTMOD_ISO_C_BINDING ?
Le 22/06/2023 à 22:23, Harald Anlauf via Fortran a écrit :
Dear all,
gfortran's ABI specifies that actual arguments to CHARACTER(LEN=1),VALUE
dummy arguments are passed by value in the scalar case. That did work
for constant strings being passed, but not in several other cases, where
pointers w
Hello,
Le 02/07/2023 à 22:38, Harald Anlauf via Fortran a écrit :
Dear all,
the attached patch fixes a long-standing issue with the
order of evaluation of procedure argument expressions and
deallocation of allocatable actual arguments passed to
allocatable dummies with intent(out) attribute.
I
Le 04/07/2023 à 01:56, Steve Kargl a écrit :
On Mon, Jul 03, 2023 at 10:49:36PM +0200, Harald Anlauf via Fortran wrote:
Indeed, this is a nice demonstration.
While playing, I was wondering whether the following code is conforming:
program p
call s ((1))
contains
subroutine s (x)
in
Le 03/07/2023 à 22:49, Harald Anlauf a écrit :
Hi Mikael,
Am 03.07.23 um 13:46 schrieb Mikael Morin:
These look good, but I'm surprised that there is no similar change at
the 6819 line.
This is the class array actual vs class array dummy case.
It seems to be checked by the "bar"
Le 04/07/2023 à 21:00, Harald Anlauf a écrit :
Hi Mikael, all,
I think I've found it: there is a call to gfc_conv_class_to_class
that - according to a comment - does a repackaging to a class array.
Deferring that repackaging along with the deallocation not only fixes
the regression, but also the
Le 04/07/2023 à 21:37, Mikael Morin a écrit :
Le 04/07/2023 à 21:00, Harald Anlauf a écrit :
Hi Mikael, all,
I think I've found it: there is a call to gfc_conv_class_to_class
that - according to a comment - does a repackaging to a class array.
Deferring that repackaging along wit
Le 05/07/2023 à 22:36, Harald Anlauf a écrit :
Hi Mikael,
Am 05.07.23 um 16:54 schrieb Mikael Morin:
Here is an example, admittedly artificial. Fails with the above change,
but fails with master as well.
program p
implicit none
type t
integer :: i
end type t
type u
Hello,
Le 07/07/2023 à 20:23, Harald Anlauf a écrit :
Hi Mikael,
Am 07.07.23 um 14:21 schrieb Mikael Morin:
I'm attaching what I have (lightly) tested so far, which doesn't work.
It seems gfc_conv_class_to_class reevaluates part of the original
expression, which is not cor
Le 26/10/2023 à 11:29, Richard Biener a écrit :
On Wed, Oct 25, 2023 at 5:51 AM Andrew Pinski wrote:
diff --git a/gcc/fold-const.cc b/gcc/fold-const.cc
index 40767736389..2a2a90230f5 100644
--- a/gcc/fold-const.cc
+++ b/gcc/fold-const.cc
@@ -15047,15 +15047,33 @@ tree_single_nonnegative_warnv_p
Hello,
while preparing a testcase, I encountered a bug which I filed as
PR112371. Investigating further, I found two different problems which I
propose to fix with the followup patches.
Those have been bootstraped and regression tested on x86_64-pc-linux-gnu.
OK for master?
Mikael
Mikael
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 06/11/2023 à 19:12, Harald Anlauf a écrit :
Hi Mikael,
Am 06.11.23 um 12:43 schrieb Mikael Morin:
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
Le 06/11/2023 à 19:20, Harald Anlauf a écrit :
Hi Mikael,
Am 06.11.23 um 12:43 schrieb Mikael Morin:
Remove the forced overwrite of the first dimension of the result array
descriptor to set it to zero extent, in the function templates for
transformational functions doing an array reduction
Hello,
I have just pushed a for PR108923 (a memory leak).
It fixes the small reproducer that I pasted in bugzilla, and I have run
it through the fortran regression testsuite.
More details in the patch.From 545a7d5da5fcc338e29c5241b574ac99d03f4454 Mon Sep 17 00:00:00 2001
From: Mikael Morin
oblem.
Manually tested on Harald's testcase (predcom-1.f) and ran the full
fortran testsuite on x86_64-pc-linux-gnu.
OK for master and 12 and 11?
From 9b88208ec4130712d33d5c7ed74fc17466624a0c Mon Sep 17 00:00:00 2001
From: Mikael Morin
Date: Sat, 25 Feb 2023 16:27:24 +0100
Subject: [PATC
Le 25/02/2023 à 18:20, Harald Anlauf a écrit :
Hi Mikael,
Am 25.02.23 um 17:35 schrieb Mikael Morin:
Hello,
Harald found a testcase with memory still leaking despite my previous
patch for PR108923.
That patch was fixing a leak caused by absence of memory release, the
attached patch fixes a
Hello,
Le 03/03/2023 à 20:57, Steve Kargl via Fortran a écrit :
On Thu, Mar 02, 2023 at 11:03:48PM +0100, Harald Anlauf via Fortran wrote:
- if (attr->class_ok)
-/* Class container has already been built. */
+ /* Class container has already been built with same name. */
+ if (attr->cla
Le 03/03/2023 à 22:24, Mikael Morin a écrit :
I have two comments, one about the handling of as and sym->as, which I
quite don't understand, but I haven't had time to write something about it.
I have found the time finally. It's not as bad as it seemed. See below.
diff -
Le 04/03/2023 à 17:06, Harald Anlauf a écrit :
Sorry, attached the wrong patch.
Here's the correct one.
Harald
Am 04.03.23 um 17:02 schrieb Harald Anlauf via Gcc-patches:
The attached revised version uses the above proven changes,
and extends the new testcase class_74.f90 by variations of
th
Le 04/03/2023 à 22:20, Harald Anlauf a écrit :
Hi Mikael,
Am 04.03.23 um 18:09 schrieb Mikael Morin:
There was a comment about the old_symbol thing at the end of my previous
message:
https://gcc.gnu.org/pipermail/gcc-patches/2023-March/613354.html
I think Tobias might be the better person to
Le 10/05/2023 à 18:47, Bernhard Reutner-Fischer via Fortran a écrit :
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
PR fortran/78798
* array.cc (compare_bounds): Use narrower return type.
(gfc_compare_array_spec): Likewise.
(is_constant_element): Likewis
Le 14/05/2023 à 01:23, Bernhard Reutner-Fischer via Gcc-patches a écrit :
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
* trans-array.cc (is_pointer_array): Use _P() defines from tree.h.
(gfc_conv_scalarized_array_ref): Ditto.
(gfc_conv_array_ref): Ditto.
Le 14/05/2023 à 17:24, Bernhard Reutner-Fischer a écrit :
On Sun, 14 May 2023 15:04:15 +0200
Thomas Koenig wrote:
On 14.05.23 14:27, Mikael Morin wrote:
(...)
@@ -2098,7 +2098,7 @@ ref_same_as_full_array (gfc_ref *full_ref,
gfc_ref *ref)
there is some kind of overlap.
0
Le 17/05/2023 à 20:52, Harald Anlauf via Fortran a écrit :
Dear all,
the attached patch is neat, because it fixes a bug by removing code ;-)
When generating the initializer for a parameter array, we excepted
the case of size 0, which however prevented the detection of array
bounds violations an
Le 18/05/2023 à 17:18, Bernhard Reutner-Fischer a écrit :
On Sun, 14 May 2023 15:10:12 +0200
Mikael Morin wrote:
Le 14/05/2023 à 01:23, Bernhard Reutner-Fischer via Gcc-patches a écrit :
From: Bernhard Reutner-Fischer
gcc/fortran/ChangeLog:
* trans-array.cc (is_pointer_array): Use
Le 24/05/2023 à 21:16, Harald Anlauf via Fortran a écrit :
Dear all,
the attached almost obvious patch fixes an ICE on invalid that may
occur when we attempt to simplify an initialization expression with
SIZE for an out-of-range DIM argument. Returning gfc_bad_expr
allows for a more graceful er
Le 21/05/2023 à 22:48, Harald Anlauf via Fortran a écrit :
Dear all,
checking and simplification of the RESHAPE intrinsic could fail in
various ways for sufficiently complicated arguments, like array
constructors. Debugging revealed that in these cases we determined
that the array arguments wer
Le 04/08/2021 à 09:05, Thomas Koenig a écrit :
So far, we have refrained from adding too much explicit C++-isms into
the code, and if we do, my participation at least will have to be
reduced sharply (I don't speak much C++, and I don't intend to learn).
So, is this a path we want to go down?
I
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 26/09/2022 à 19:24, Aldy Hernandez via Gcc-patches a écrit :
For [0 = x & MASK], we can determine that x is ~MASK.
Suggestion: as AND is a bitwise operator, a X non-zero bit can be
cleared for every bit at which the result is cleared and the MASK is
set, so what you do here can be extended
Hello,
Le 16/09/2022 à 15:26, Aldy Hernandez via Gcc-patches a écrit :
diff --git a/gcc/value-range.cc b/gcc/value-range.cc
index d759fcf178c..55a216efd8b 100644
--- a/gcc/value-range.cc
+++ b/gcc/value-range.cc
@@ -617,21 +602,24 @@ frange::contains_p (tree cst) const
if (varying_p ())
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 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
Hello,
Le 08/03/2022 à 18:58, Jonathan Wakely via Gcc-patches a écrit :
Replace \([0-9]\+\) with \([0-9][0-9]*\) or with \([1-9][0-9]*\) in release
branch numbers, where
a leading zero does not occur.
Note that you also changed some gcc-[0-9]* to gcc-[1-9]*, which is a
typo/thinko I guess? I
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
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
Hello,
Le 21/01/2022 à 00:59, David Malcolm via Gcc-patches a écrit :
diff --git a/gcc/analyzer/constraint-manager.cc
b/gcc/analyzer/constraint-manager.cc
index 568e7150ea7..7c4a85bbb24 100644
--- a/gcc/analyzer/constraint-manager.cc
+++ b/gcc/analyzer/constraint-manager.cc
@@ -301,6 +301,80 @@
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
1 - 100 of 1073 matches
Mail list logo
