Hi Paul,
While an error is correctly generated, the wording of
the error message iand locus seems odd. I have a
code that has
module foo
implicit none
private
generic, public :: bar => bar
generic, private :: bar => bah
...
end module
% gfcx -c a_gen4.F90
a_gen4.
On Thu, Jul 31, 2025 at 01:34:14PM -0700, Steve Kargl wrote:
>
> It seems that
>
> module foo
> implicit none
> private
> public bar
> generic :: bar => bar, bah
> end module
>
> is not accepted.
>
As a follow-up, this is accepted with your patch.
module foo
implicit none
pr
On Wed, Jul 23, 2025 at 05:53:17PM +0100, Paul Richard Thomas wrote:
>
>
> Regtests on x86_64/FC42 - OK for mainline?
>
Here's another testcase that fails.
% gfcx -o z a_gen2.F90 && ./z
42.000
43.500
% gfcx -o z -DGEN a_gen2.F90
a_gen2.F90:9:21:
9 |generic :: ba
On Wed, Jul 23, 2025 at 05:53:17PM +0100, Paul Richard Thomas wrote:
>
> The attached implements the F2018 generic statement, which has the same
> semantics as the typebound version but can appear in any specification
> statement.
>
> As it says in the first comment in the patch, use is made of t
Hi Mikael,
The patch applies cleanly, regtests and fixes the problem, as advertised.
It does likewise on 15-branch.
Good for mainline and, I would suggest, backporting.
Thanks for the patch.
Paul
On Wed, 30 Jul 2025 at 10:04, Mikael Morin wrote:
> From: Mikael Morin
>
> This one may look l
Hi Yuao,
That's exactly how I had a mind to do it. You beat me to it :-(
Just get on, polish the patch and add more tests.
Thanks
Paul
On Wed, 30 Jul 2025 at 15:53, Yuao Ma wrote:
> Hi all,
>
> This patch introduces support for conditional expressions (also known as
> ternary operators in s
On 7/30/25 18:14, Andre Vehreschild wrote:
Hi Toon,
yes, please keep this coming. I suffered from a catastrophic hardware fault on
last Thursday and only get running again. I will process this as soon as I have
processed the earlier reports.
Regards,
Andre
On Wed, 30 Jul 2025 17:43:28
On Sun, 6 Jul 2025, Yuao Ma wrote:
> +#ifndef HAVE_COSPI
> +#define HAVE_COSPI 1
> +double cospi (double);
> +
> +double
> +cospi (double x)
> +{
> + return cos (x * pihi_d + x * pilo_d);
For reasonable results for large x you should first reduce mod 2 to the
range [-1, 1] (or reduce mod 1 and
Hi Toon,
yes, please keep this coming. I suffered from a catastrophic hardware fault on
last Thursday and only get running again. I will process this as soon as I have
processed the earlier reports.
Regards,
Andre
On Wed, 30 Jul 2025 17:43:28 +0200
Toon Moene wrote:
> On 7/28/25 20:27,
On 7/28/25 20:27, Toon Moene wrote:
On 7/27/25 14:46, Toon Moene wrote:
Today I updated my random-weather example (https://moene.org/~toon/
random-weather) to fix the problem that two different implementations
of the underlying coarray library might give different result numbers
due to the
Le 30/07/2025 à 02:42, Yuao Ma a écrit :
On 7/27/2025 8:51 PM, Mikael Morin wrote:
Le 27/07/2025 à 13:46, Yuao Ma a écrit :
On 7/27/2025 7:14 PM, Mikael Morin wrote:
Le 27/07/2025 à 11:37, Yuao Ma a écrit :
On 7/27/2025 5:19 PM, Mikael Morin wrote:
+gfc_charlen_type
+string_split (gfc_ch
Hi Harald,
>From a very quick perusal of the F2018 standard, I have come to the
tentative conclusion that:
(i) 'real module function realg (arg1, arg2)' is almost certainly a
correct requirement, although both flang-new and gfortran compile happily
without the module attribute; and
(ii) As far as
On Tue, Jul 29, 2025 at 10:29:37PM +0200, Harald Anlauf wrote:
>
> - I am a little confused about the handling of the access specification.
> After the first "public :: g", NAG complains about the
>
> generic, public :: g ...
>
> and only allows
>
> generic :: g ...
>
> Then duplicate pub
On 7/27/2025 8:51 PM, Mikael Morin wrote:
Le 27/07/2025 à 13:46, Yuao Ma a écrit :
On 7/27/2025 7:14 PM, Mikael Morin wrote:
Le 27/07/2025 à 11:37, Yuao Ma a écrit :
On 7/27/2025 5:19 PM, Mikael Morin wrote:
+gfc_charlen_type
+string_split (gfc_charlen_type stringlen, const CHARTYPE *str
On 7/27/25 1:25 PM, Harald Anlauf wrote:
Gesendet: Sonntag, 27. Juli 2025 um 21:18
Von: "Mikael Morin"
An: "Andre Vehreschild"
CC: "Harald Anlauf" , fortran@gcc.gnu.org
Betreff: Re: Add: [Bug fortran/121043] [16 Regression] Tests of OpenCoarray
fail to pass, work
Hi Paul!
Am 24.07.25 um 08:07 schrieb Paul Richard Thomas:
I forgot to include subroutine tests. Please find attached the patch with
updated testcases.
Paul
On Wed, 23 Jul 2025 at 17:53, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
Hi All,
The attached implements the F2018 ge
Le 29/07/2025 à 09:01, Paul Richard Thomas a écrit :
I haven't had time to track them down
but there are other places where code has had to be inserted to prevent
non-polymorphic references in a polymorphic way. I wonder if they cannot
be unified at some time?
Are there? gfc_get_class_from_e
Le 29/07/2025 à 08:53, Paul Richard Thomas a écrit :
Hi Mikail,
I apologise for the delay between reviewing this patch and the first.
Some daytime work issues came up that I couldn't ignore.
This addition is fine, does as advertised and is good for mainline.
Oops, sorry thanks for the revi
Hi Mikail,
Yes to this third patch as well. I haven't had time to track them down but
there are other places where code has had to be inserted to prevent
non-polymorphic references in a polymorphic way. I wonder if they cannot be
unified at some time?
All three can be pushed to mainline.
Many th
Hi Mikail,
I apologise for the delay between reviewing this patch and the first. Some
daytime work issues came up that I couldn't ignore.
This addition is fine, does as advertised and is good for mainline.
Thanks
Paul
On Sat, 26 Jul 2025 at 20:32, Mikael Morin wrote:
> From: Mikael Morin
>
Retrying, as the last version ended up as HTML garbage... :-(
***
Hi Andre,
I've tried to work out a (rather old-style) program that structurally resembles your testcase, but using plain MPI, with mpi_put for 1-sided communication as you suggested, and avoiding associate to avoid potential is
works with at least one other compiler, that would be a real benefit.
Cheers,
Harald
Gesendet: Montag, 28. Juli 2025 um 00:05
Von: "Andre Vehreschild"
An: "Harald Anlauf" , morin-mik...@orange.fr
CC: fortran@gcc.gnu.org
Betreff: Re: Aw: Re: Add: [Bug fortran/121043]
On Sun, Jul 27, 2025 at 02:47:14PM +0200, Mikael Morin wrote:
> From: Mikael Morin
>
> Regression-tested on x86_64-pc-linux-gnu.
> OK for master?
>
Looks ok to me. Of course, the last time I reviewed one
of your patches, polymorphism got in the way of what appeared
to be straight forward clea
On 7/27/25 14:46, Toon Moene wrote:
On 7/24/25 21:49, Toon Moene wrote:
On 7/24/25 21:35, Thomas Koenig wrote:
Am 23.07.25 um 21:47 schrieb Toon Moene:
Today I used Thomas's "locks" example code from the same e-mail
message (showing the full output):
Actually, I think that example is fl
Hi Harald,
Am 27. Juli 2025 22:25:40 schrieb Harald Anlauf :
Harald, are you still unconvinced? Do we need to discuss the behavior of
the testcase test_teams_1? or something else?
I will not make any specific suggestions about the actual implementation
of coarrays in gfortran.
Let me phrase
> Gesendet: Sonntag, 27. Juli 2025 um 21:18
> Von: "Mikael Morin"
> An: "Andre Vehreschild"
> CC: "Harald Anlauf" , fortran@gcc.gnu.org
> Betreff: Re: Add: [Bug fortran/121043] [16 Regression] Tests of OpenCoarray
> fail to pass, works on
Well, I have to think about a test case. But a dg-not-present one should be
doable.
Expr_compcall is not supported in gfortran 's coarray handling at all. I
think there is a bug report for this.
Teams map to Mpi_communicators 1-to-1. Well, that's my conclusion from
reading the standard. It s
Le 27/07/2025 à 17:35, Andre Vehreschild a écrit :
On Sun, 27 Jul 2025 16:57:14 +0200
Mikael Morin wrote:
Le 27/07/2025 à 12:57, Andre Vehreschild a écrit :
Hi Mikael,
In this example, image 1, i.e., for
Opencoarrays a thread on image one takes the data from the executing
image and wri
On Sun, 27 Jul 2025 16:57:14 +0200
Mikael Morin wrote:
> Le 27/07/2025 à 12:57, Andre Vehreschild a écrit :
> > Hi Mikael,
> >
> >>> In this example, image 1, i.e., for
> >>> Opencoarrays a thread on image one takes the data from the executing
> >>> image and writes it into the memory of im
Le 27/07/2025 à 12:57, Andre Vehreschild a écrit :
Hi Mikael,
In this example, image 1, i.e., for
Opencoarrays a thread on image one takes the data from the executing
image and writes it into the memory of image 1.
When you say it takes data, do you mean it takes the assignment right
hand side
On 7/27/2025 8:51 PM, Mikael Morin wrote:
Le 27/07/2025 à 13:46, Yuao Ma a écrit :
On 7/27/2025 7:14 PM, Mikael Morin wrote:
Le 27/07/2025 à 11:37, Yuao Ma a écrit :
On 7/27/2025 5:19 PM, Mikael Morin wrote:
+gfc_charlen_type
+string_split (gfc_charlen_type stringlen, const CHARTYPE *str
Le 27/07/2025 à 13:46, Yuao Ma a écrit :
On 7/27/2025 7:14 PM, Mikael Morin wrote:
Le 27/07/2025 à 11:37, Yuao Ma a écrit :
On 7/27/2025 5:19 PM, Mikael Morin wrote:
+gfc_charlen_type
+string_split (gfc_charlen_type stringlen, const CHARTYPE *string,
+ gfc_charlen_type setlen, const
On 7/24/25 21:49, Toon Moene wrote:
On 7/24/25 21:35, Thomas Koenig wrote:
Am 23.07.25 um 21:47 schrieb Toon Moene:
Today I used Thomas's "locks" example code from the same e-mail
message (showing the full output):
Actually, I think that example is flawed, it lacks synchronization.
Sorry
Hi Mikael,
This looks fine to me. OK for mainline.
Thanks for the fix.
Paul
On Sat, 26 Jul 2025 at 20:31, Mikael Morin wrote:
> From: Mikael Morin
>
> Regression-tested on x86_64-pc-linux-gnu.
> OK for master?
>
> -- >8 --
>
> Don't look for a class container too far after an array descript
Hi Steve,
On 7/27/2025 2:25 AM, Steve Kargl wrote:
Thanks for the review! If the new patch looks good for trunk and there are
no other objections, could you please help me merge it?
I haven't committed a patch since the transition from subversion
to git. I'm not paid to learn yet-another-SCCS
On 7/27/2025 7:14 PM, Mikael Morin wrote:
Le 27/07/2025 à 11:37, Yuao Ma a écrit :
On 7/27/2025 5:19 PM, Mikael Morin wrote:
+gfc_charlen_type
+string_split (gfc_charlen_type stringlen, const CHARTYPE *string,
+ gfc_charlen_type setlen, const CHARTYPE *set,
+ gfc_charlen_typ
Le 27/07/2025 à 11:37, Yuao Ma a écrit :
On 7/27/2025 5:19 PM, Mikael Morin wrote:
+gfc_charlen_type
+string_split (gfc_charlen_type stringlen, const CHARTYPE *string,
+ gfc_charlen_type setlen, const CHARTYPE *set,
+ gfc_charlen_type pos, GFC_LOGICAL_4 back)
+{
+ gfc_charlen_
Hi Mikael,
> > In this example, image 1, i.e., for
> > Opencoarrays a thread on image one takes the data from the executing
> > image and writes it into the memory of image 1.
> When you say it takes data, do you mean it takes the assignment right
> hand side (named "data"), or do you mean th
On 7/27/2025 5:43 PM, Mikael Morin wrote:
I forgot to add:
+ else
+ {
+ if (pos < 1 || pos > (stringlen + 1))
+ runtime_error ("If BACK is present with the value true, the
value of "
+ "POS shall be in the range [1, LEN (STRING) + 1]");
+
can you provide the valu
I forgot to add:
+ else
+ {
+ if (pos < 1 || pos > (stringlen + 1))
+ runtime_error ("If BACK is present with the value true, the value
of "
+ "POS shall be in the range [1, LEN (STRING) + 1]");
+
can you provide the value of pos and stringlen in the error messages?
On 7/27/2025 5:19 PM, Mikael Morin wrote:
+gfc_charlen_type
+string_split (gfc_charlen_type stringlen, const CHARTYPE *string,
+ gfc_charlen_type setlen, const CHARTYPE *set,
+ gfc_charlen_type pos, GFC_LOGICAL_4 back)
+{
+ gfc_charlen_type i, j;
+
+ if (!back)
+ {
+ i
Le 27/07/2025 à 05:40, Yuao Ma a écrit :
Hi Mikael,
On 7/27/2025 3:57 AM, Mikael Morin wrote:
Hello,
here are a few more comments on the patch below.
It's not ready yet, but the remarks should be easily addressed.
Thanks for the thorough review! I've addressed the comments and attached
a n
Le 26/07/2025 à 23:14, Andre Vehreschild a écrit :
Hi Harald and Mikael,
sorry when I jumped too much in answering different questions to my
evident error.
What I am trying to correct with my lastest patch is exactly what Harald
wants. Standard compliant evaluation of all arguments to a (coi
Hi Mikael,
On 7/27/2025 3:57 AM, Mikael Morin wrote:
Hello,
here are a few more comments on the patch below.
It's not ready yet, but the remarks should be easily addressed.
Thanks for the thorough review! I've addressed the comments and attached
a new patch below.
diff --git a/gcc/fortran
kael Morin"
An: "Harald Anlauf" , ve...@gmx.de
CC: fortran@gcc.gnu.org
Betreff: Re: Aw: Re: Add: [Bug fortran/121043] [16 Regression] Tests of
OpenCoarray fail to pass, works on 15.1.1 20250712
Le 24/07/2025 à 22:01, Harald Anlauf a écrit :
Hi Andre,
Gesendet: Donnerstag, 24. Juli
Le 26/07/2025 à 19:03, Harald Anlauf a écrit :
Gesendet: Samstag, 26. Juli 2025 um 15:17
Von: "Mikael Morin"
An: "Harald Anlauf" , ve...@gmx.de
CC: fortran@gcc.gnu.org
Betreff: Re: Aw: Re: Add: [Bug fortran/121043] [16 Regression] Tests of
OpenCoarray fail to pass, works on
Hello,
here are a few more comments on the patch below.
It's not ready yet, but the remarks should be easily addressed.
diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc
index be984271d6a..c2a91c93d28 100644
--- a/gcc/fortran/trans-intrinsic.cc
+++ b/gcc/fortran/trans
On Sat, Jul 26, 2025 at 11:57:50PM +0800, Yuao Ma wrote:
>
> On 7/26/2025 11:25 PM, Steve Kargl wrote:
> > On Sat, Jul 26, 2025 at 09:14:43PM +0800, Yuao Ma wrote:
> > > + add_sym_4s ("split", GFC_ISYM_SPLIT, CLASS_IMPURE,
> > > + BT_UNKNOWN, 0, GFC_STD_F2023,
> > > + gfc_check_split,
> Gesendet: Samstag, 26. Juli 2025 um 19:03
> Von: "Harald Anlauf"
> An: morin-mik...@orange.fr, ve...@gmx.de
> CC: fortran@gcc.gnu.org
> Betreff: Re: Aw: Re: Add: [Bug fortran/121043] [16 Regression] Tests of
> OpenCoarray fail to pass, works on 15.1.1 202507
> Gesendet: Samstag, 26. Juli 2025 um 15:17
> Von: "Mikael Morin"
> An: "Harald Anlauf" , ve...@gmx.de
> CC: fortran@gcc.gnu.org
> Betreff: Re: Aw: Re: Add: [Bug fortran/121043] [16 Regression] Tests of
> OpenCoarray fail to pass, works on 15.1.1 20250712
&g
Hi Steve,
On 7/26/2025 11:25 PM, Steve Kargl wrote:
On Sat, Jul 26, 2025 at 09:14:43PM +0800, Yuao Ma wrote:
+ add_sym_4s ("split", GFC_ISYM_SPLIT, CLASS_IMPURE,
+ BT_UNKNOWN, 0, GFC_STD_F2023,
+ gfc_check_split, NULL, gfc_resolve_split,
+ "string", BT_CH
On Sat, Jul 26, 2025 at 09:14:43PM +0800, Yuao Ma wrote:
>
> + add_sym_4s ("split", GFC_ISYM_SPLIT, CLASS_IMPURE,
> + BT_UNKNOWN, 0, GFC_STD_F2023,
> + gfc_check_split, NULL, gfc_resolve_split,
> + "string", BT_CHARACTER, dc, REQUIRED, INTENT_IN,
> + "set"
Le 24/07/2025 à 22:01, Harald Anlauf a écrit :
Hi Andre,
Gesendet: Donnerstag, 24. Juli 2025 um 10:25
Von: "Andre Vehreschild"
An: "Harald Anlauf"
CC: fortran@gcc.gnu.org
Betreff: Re: Add: [Bug fortran/121043] [16 Regression] Tests of OpenCoarray
fail to pass, works on
Hi Andre,
> Gesendet: Donnerstag, 24. Juli 2025 um 10:25
> Von: "Andre Vehreschild"
> An: "Harald Anlauf"
> CC: fortran@gcc.gnu.org
> Betreff: Re: Add: [Bug fortran/121043] [16 Regression] Tests of OpenCoarray
> fail to pass, works on 15.1.1 20250712
>
On 7/24/25 21:35, Thomas Koenig wrote:
Am 23.07.25 um 21:47 schrieb Toon Moene:
Today I used Thomas's "locks" example code from the same e-mail
message (showing the full output):
Actually, I think that example is flawed, it lacks synchronization.
Sorry for that.
Good - hope it's not too h
Am 23.07.25 um 21:47 schrieb Toon Moene:
Today I used Thomas's "locks" example code from the same e-mail message
(showing the full output):
Actually, I think that example is flawed, it lacks synchronization.
Sorry for that.
Best regards
Thomas
Hi Harald,
> > Did that help?
>
> Actually this discussion is quite helpful to me, so I (and maybe
> others) understand more of the underlying stuff.
>
> I now spent some time looking thru portions of the F2023 standard,
> and I think that it answers many questions in that respect:
>
> - 10
I forgot to include subroutine tests. Please find attached the patch with
updated testcases.
Paul
On Wed, 23 Jul 2025 at 17:53, Paul Richard Thomas <
paul.richard.tho...@gmail.com> wrote:
> Hi All,
>
> The attached implements the F2018 generic statement, which has the same
> semantics as the typ
Hi Andre,
> Gesendet: Mittwoch, 23. Juli 2025 um 10:06
> Von: "Andre Vehreschild"
> An: "Harald Anlauf"
> CC: fortran@gcc.gnu.org
> Betreff: Re: Add: [Bug fortran/121043] [16 Regression] Tests of OpenCoarray
> fail to pass, works on 15.1.1 20250712
&
On 7/22/25 20:45, Toon Moene wrote:
Using my build [Debian Testing on x86_64)] of the branch provided by
Jerry (see https://gcc.gnu.org/pipermail/gcc-testresults/2025-
July/853295.html) I got the following:
I used Thomas's "sync all" code as an example (see https://gcc.gnu.org/
pipermail/for
Am 22.07.25 um 23:54 schrieb Jerry D:
On 7/22/25 11:28 AM, Harald Anlauf wrote:
Dear all,
the attached patch fixes a long-standing issue with legacy code,
where an assumed-length character function is passed as actual
argument to a procedure, and when there is no explicit interface.
The solutio
Hi Andre
> On 23 Jul 2025, at 08:41, Andre Vehreschild wrote:
> thank you for testing. I know already about the missing include. It
> is also needed on FreeBSD. What's new is the . Is that really
> needed or is it transitively included by ? Could you check by, for
> example, just grepping signa
Hi Harald,
> I spent some time understanding why Intel fails on your example.
> Playing around with your code below, adding print statements,
> rearranging code, etc., it appears that ifx has a problem with:
I came to that conclusion, too. But we both agree that independent of rewriting
the chang
Hi Iain,
thank you for testing. I know already about the missing include. It
is also needed on FreeBSD. What's new is the . Is that really
needed or is it transitively included by ? Could you check by, for
example, just grepping signal.h for it?
grep 'sys/types.h' /usr/include/signal.h
As "hell
On 7/22/25 11:28 AM, Harald Anlauf wrote:
Dear all,
the attached patch fixes a long-standing issue with legacy code,
where an assumed-length character function is passed as actual
argument to a procedure, and when there is no explicit interface.
The solution is to do the same as in the case when
s there an equivalent to MPI communicators with Coarrays?
(and does form_team create that communicator, change_team remap coarray
descriptors
suitably, etc.?) Or am I completely off?
Cheers,
Harald
> Gesendet: Donnerstag, 17. Juli 2025 um 15:42
> Von: "Andre Vehreschild"
>
On 7/22/25 17:22, Iain Sandoe wrote:
Hi Andre
2. If I try linking a trivial Fortran code thus:
gfortran /src-local/test/fortran/hello.f90 -o h -lcaf_shmem -fcoarray=lib
the exe then hangs - it looks like it might be deadlocked in startup code:
Call graph:
2166 Thread_408707810 Disp
Hi Andre
It would be very helpful if there were such a thing as a “hello-coarrays.fxx”
code for
those of us who do not have existing installations of mpi &c. aand limited time
to
so tests…
… experiments so far - below
thanks
Iain
> >> > > We like everyone to test the new caf_shmem library an
Hi Jerry,
> Andre, one of the the other things I have not got to yet is reviewing the
> interface between gfortran and the caf_shmem. Is this interface generic
> enough to allow other libraries to be used. For example, we have the
> caf_shmem library and we have the OpenCoarrays library, down t
Well, that brought me one step further: configure did work, but I needed to
add the option --disable-multilib to exclude the 32-bits versions.
That gave me the makefiles to start the build, but then:
"gmake install" failed on the directory ./fixincludes.
Copying that from gcc/fixincludes did not h
Ah, right, will try that.
Regards,
Arjen
Op di 22 jul 2025 om 08:28 schreef Andrew Pinski :
> On Mon, Jul 21, 2025 at 11:21 PM Arjen Markus
> wrote:
> >
> > I am trying to build the branch via WSL on my Windows machine, but
> configure reports that it cannot find the mpc.h include file. It is
On Mon, Jul 21, 2025 at 11:21 PM Arjen Markus wrote:
>
> I am trying to build the branch via WSL on my Windows machine, but configure
> reports that it cannot find the mpc.h include file. It is correct - that is
> lacking, but installing or reinstalling mpc does not help. The program I want
> t
I am trying to build the branch via WSL on my Windows machine, but
configure reports that it cannot find the mpc.h include file. It is correct
- that is lacking, but installing or reinstalling mpc does not help. The
program I want to test can be found here:
https://github.com/arjenmarkus/memos-on-p
On 7/21/25 20:52, Andre Vehreschild wrote:
Hi Toon,
the coarray_native branch is not where Jerry has put the caf_shmem
patches. Coarray native is an older branch, that used a different
approach to shared memory coarrays. Caf_shmem is partially based on it.
The branch Jerry has build is
rem
Hi Toon,
the coarray_native branch is not where Jerry has put the caf_shmem patches.
Coarray native is an older branch, that used a different approach to shared
memory coarrays. Caf_shmem is partially based on it.
The branch Jerry has build is
remotes/origin/devel/gfortran-test
- AndreAndr
On 7/19/25 20:40, Jerry D wrote:
Yes, this is why we need additional testers.
For those who need some guidance to the test branch:
$ git clone git://gcc.gnu.org/git/gcc.git
$ cd gcc
$ git checkout remotes/origin/devel/gfortran-test
$ git switch -c gfortran-test
If you already have an existi
On 7/19/25 5:06 PM, Jerry D wrote:
On 7/19/25 2:26 PM, Thomas Koenig wrote:
I wrote:
I have grave concerns.
At the last (to me an Nicolas) known state, before he was ousted
from the project, there were known race conditions, which can
cause freezing and/or data corruption.
I believe these ha
Very much appreciated. Thank you!
- Andre
On Mon, 21 Jul 2025 13:38:56 +0200
Arjen Markus wrote:
> I have a not-so-trivial, but compact test case for you. I will try it out
> with the receipe you gave :).
>
> Regards,
>
> Arjen
>
> Op ma 21 jul 2025 om 13:31 schreef Andre Vehreschild :
>
>
I have a not-so-trivial, but compact test case for you. I will try it out
with the receipe you gave :).
Regards,
Arjen
Op ma 21 jul 2025 om 13:31 schreef Andre Vehreschild :
> Hi all,
>
> we are looking for people having old and/or modern Fortran codes available
> that use Coarrays more or less
Hi Paul,
thanks for review. Committed as gcc-16-2372-g3a7fcf4f54e.
The issue is also present on gcc-15 and 14. I would backport this to gcc-15 in a
week, if no one objects!
Thanks again,
Andre
On Fri, 18 Jul 2025 16:35:51 +0100
Paul Richard Thomas wrote:
> Hi Andre,
>
> After a false
On 7/19/25 23:26, Thomas Koenig wrote:
I wrote:
I have grave concerns.
At the last (to me an Nicolas) known state, before he was ousted
from the project, there were known race conditions, which can
cause freezing and/or data corruption.
I believe these have not been addressed, neither tested
Hi Steve,
On 7/20/2025 11:06 AM, Steve Kargl wrote:
On Sun, Jul 20, 2025 at 12:39:00AM +0800, Yuao Ma wrote:
On 7/18/2025 11:43 PM, Yuao Ma wrote:
I noticed that hex(16128084538487209988) evaluates to
0xdfd27774, and it looks like the higher bits weren't being
zeroed out as expected. A
On Sun, Jul 20, 2025 at 12:39:00AM +0800, Yuao Ma wrote:
> On 7/18/2025 11:43 PM, Yuao Ma wrote:
> > I noticed that hex(16128084538487209988) evaluates to
> > 0xdfd27774, and it looks like the higher bits weren't being
> > zeroed out as expected. After I explicitly added pos =
> > convert(g
On 7/19/25 2:26 PM, Thomas Koenig wrote:
I wrote:
I have grave concerns.
At the last (to me an Nicolas) known state, before he was ousted
from the project, there were known race conditions, which can
cause freezing and/or data corruption.
I believe these have not been addressed, neither teste
I wrote:
I have grave concerns.
At the last (to me an Nicolas) known state, before he was ousted
from the project, there were known race conditions, which can
cause freezing and/or data corruption.
I believe these have not been addressed, neither tested nor by
inspection.
Maybe a word of exp
Am 19.07.25 um 18:32 schrieb Jerry D:
I am ready to approve this. Can anyone second this.
I have grave concerns.
At the last (to me an Nicolas) known state, before he was ousted
from the project, there were known race conditions, which can
cause freezing and/or data corruption.
I believe thes
On 7/19/25 10:59 AM, Toon Moene wrote:
On 7/19/25 18:32, Jerry D wrote:
I expanded on Toon's random_weather.f90 test using:
!integer, parameter :: DNX = 72, DNY = 70, DNZ = 30, BDSIZE = 4, HORSTEP =
1, VERSTEP = 100, FCLEN = 3600, TIMSTEP = 240
integer, parameter :: DNX = 1000, DNY =
On 7/19/25 18:32, Jerry D wrote:
I expanded on Toon's random_weather.f90 test using:
!integer, parameter :: DNX = 72, DNY = 70, DNZ = 30, BDSIZE = 4, HORSTEP =
1, VERSTEP = 100, FCLEN = 3600, TIMSTEP = 240
integer, parameter :: DNX = 1000, DNY = 1500, DNZ = 100, BDSIZE = 4,
HORSTEP =
On 7/18/2025 11:43 PM, Yuao Ma wrote:
I noticed that hex(16128084538487209988) evaluates to
0xdfd27774, and it looks like the higher bits weren't being
zeroed out as expected. After I explicitly added pos =
convert(gfc_charlen_type_node, pos); for type conversion, the test case
started
On 7/17/25 9:37 PM, Jerry D wrote:
I have created a new gfortran-test branch on gcc here.
origin/devel/gfortran-test
This has the patches applied as needed to do the testing I have done.
When Andre's patches are approved I will revert and rebase this so we can test
the next set of major chang
On Sat, Jul 19, 2025 at 12:08:44AM +0800, Yuao Ma wrote:
> Hi Tobias,
>
> On 7/18/2025 3:16 PM, Tobias Burnus wrote:
> > I am wondering whether we should implement it – for kind=1 (and at
> > least for set len=1) by a call to BUILT_IN_MEMCHR / BUILT_IN_MEMRCHR.
> > For set len > 1, a loop around
Hi Andre,
Am 18.07.25 um 21:41 schrieb Andre Vehreschild:
Hi Harald,
that looks fine to me. Ok to commit and backport. Thanks for the patch.
pushed as r16-2355-g8f9450505f8244 so far.
Thanks for the review!
Harald
- Andre
Andre Vehreschild * ve...@gmx.de
Am 18. Juli 2025 21:19:00 schrieb
Hi Harald,
that looks fine to me. Ok to commit and backport. Thanks for the patch.
- Andre
Andre Vehreschild * ve...@gmx.de
Am 18. Juli 2025 21:19:00 schrieb Harald Anlauf :
Dear all,
the attached simple and obvious patch fixes an erroneous runtime check
with -fcheck=pointer when passing a no
Hi Tobias,
On 7/18/2025 3:16 PM, Tobias Burnus wrote:
I am wondering whether we should implement it – for kind=1 (and at
least for set len=1) by a call to BUILT_IN_MEMCHR / BUILT_IN_MEMRCHR.
For set len > 1, a loop around it has to be generated, and for kind=4,
it could be implemented manual
Hi Mikael,
On 7/18/2025 3:26 PM, Mikael Morin wrote:
Le 17/07/2025 à 15:58, Yuao Ma a écrit :
Hi Mikael,
On 7/17/2025 3:47 PM, Mikael Morin wrote:
How did you declare gfor_fndecl_string_split?
More exactly what is the declaration type for the POS argument?
For the POS argument type, I'm usi
Hi Andre,
After a false start, the patch was applied to mainline, did what it was
supposed to do and regtests fine.
Ok for mainline.
Thanks
Paul
On Fri, 18 Jul 2025 at 13:42, Andre Vehreschild wrote:
> Hi all, hi Harald,
>
> attached patch fixes a runtime out-of-bounds error when an iterato
Le 17/07/2025 à 15:58, Yuao Ma a écrit :
Hi Mikael,
On 7/17/2025 3:47 PM, Mikael Morin wrote:
How did you declare gfor_fndecl_string_split?
More exactly what is the declaration type for the POS argument?
For the POS argument type, I'm using
build_pointer_type(gfc_charlen_type_node). I got th
Hi Yuao,
c8ef wrote:
I'm currently working on implementing the `split` procedure, which was
added in Fortran 2023.
I am wondering whether we should implement it – for kind=1 (and at
least for set len=1) by a call to BUILT_IN_MEMCHR / BUILT_IN_MEMRCHR.
For set len > 1, a loop around it has t
I have created a new gfortran-test branch on gcc here.
origin/devel/gfortran-test
This has the patches applied as needed to do the testing I have done.
When Andre's patches are approved I will revert and rebase this so we can test
the next set of major changes. I have done this to simplify the
On 7/16/25 7:13 AM, Andre Vehreschild wrote:
Hi Jerry,
I am back on track.
--- snip ---
After some back and forth with Andre I finally understand the discrepancies I
was having here. Andre has an OpenCoarrays branch being used to update
OpenCoarrays to sync with changes to gfortran-16. Thi
1 - 100 of 3293 matches
Mail list logo
