Interesting question. We don't do that yet, as far as I know.
Forwarded Message
Subject: gfortran fp16
Date: Mon, 16 May 2022 13:24:22 +0800 (GMT+08:00)
From: 陈刚
To: gcc-h...@gcc.gnu.org
Dear experts,
I want to use fp16 in fortran, does gfortran support the fp16?
I di
compilers differ in the
treatment of this case, there might be reason to ask the Fortran
Standard Committee for an Interpretation of the Standard ?
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
print *, associated(ptr, scalar)
end subroutine sub
end
!!!!!!!!
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
tributors, but it shows to the
broader GCC development community what gfortran is used for, and how
*we* deal with their questions and problems (and, thus, how important
this part of the GNU Compiler *Collection* is).
Oh, BTW, I retire in nine months, which would give me loads of time to
deal w
regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
n't a patch tracker (or at
least not a system where you submit patches to a thing vs emailing them to
a list and hoping someone replies).
Well, you can put patches into Bugzilla ...
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maarten
ourse) not given with a non-lto libgfortran.
The full question of "lto-ing" run time libraries is more complicated
than just "whether it works" as those who attended the BoF will recall.
Hope this helps,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
t of our .mod files.
But it would be a big win for Fortran ...
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
always used only by the same snapshot from the release
branch and so should be compatible with the LTO in it.
This might be an argument to make it a configure option, e.g.
--enable-lto-runtime.
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG
On 9/26/23 20:40, Toon Moene wrote:
On 9/26/23 09:30, Richard Biener via Gcc wrote:
On Mon, Sep 25, 2023 at 5:17 PM Sylvain Noiry via Gcc
wrote:
As I said at the end of the presentation, we have written a paper which
explains
our implementation in details. You can find it on the wiki page
Forwarded Message
Subject: [PATCH] testsuite, gfortan: Update link flags [PR112862].
Date: Sun, 28 Jan 2024 15:03:08 +
From: Iain Sandoe
Reply-To: i...@sandoe.co.uk
To: gcc-patc...@gcc.gnu.org
CC: r...@cebitec.uni-bielefeld.de
Tested on i686, x86_64, aarch64 Darwin, x86
For better visibility to the Fortran crowd, I'll send this to the
Fortran mailing list.
See Richard Earnshaw's remark near the end of the message.
Kind regards,
Toon Moene.
On 2/19/24 14:16, Richard Earnshaw (lists) wrote:
On 19/02/2024 10:58, Tamar Christina wrote:
-Origin
g file - there is more
information in it to zoom in on the errors on the aarch64 side (note
that the x86_64 side is not faultless).
Is there a way to pass this information to our websites, so that we do
not "forget" this - or in the alternative, follow the progress in
solving this ?
enabled by default.
I am suspect the aarch64 "excessive exceeding the threshold for
errors" are all caused by the more use of FMA rather than anything
else.
Aah, I forgot to include that tidbit, because its readily apparent from
the full logs - I compiled with *just* -O3.
Thanks,
--
On 5/6/24 23:35, Toon Moene wrote:
On 5/6/24 23:32, Andrew Pinski wrote:
Did you test x86_64 with -march=native (or with -mfma) or just -O3?
The reason why I am asking is aarch64 includes FMA by default while
x86_64 does not.
Most recent x86_64 includes an FMA instruction but since the base
On 5/7/24 00:02, Toon Moene wrote:
OK, perhaps on the aarch64 I need the following option to make the
comparison fair:
‘rdma’
Enable Round Double Multiply Accumulate instructions. This is on by
default for -march=armv8.1-a.
I.e., -mno-rdma
(I hope that's correct - I'll wil
On 5/7/24 20:35, Andrew Pinski wrote:
On Tue, May 7, 2024 at 11:31 AM Toon Moene wrote:
On 5/7/24 00:02, Toon Moene wrote:
OK, perhaps on the aarch64 I need the following option to make the
comparison fair:
‘rdma’
Enable Round Double Multiply Accumulate instructions. This is on by
On 5/7/24 20:44, Toon Moene wrote:
On 5/7/24 20:35, Andrew Pinski wrote:
On Tue, May 7, 2024 at 11:31 AM Toon Moene wrote:
On 5/7/24 00:02, Toon Moene wrote:
OK, perhaps on the aarch64 I need the following option to make the
comparison fair:
‘rdma’
Enable Round Double Multiply
ive a "git pull && git
merge" (and then fix the conflicts ...).
That said, I didn't have a chance to work on gcc's git, so my experience
might not apply here ...
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
For Your Information ...
Forwarded Message
Subject: GCC 11.0.1 Status Report (2021-03-16)
Date: Tue, 16 Mar 2021 12:19:20 +0100 (CET)
From: Richard Biener
Reply-To: g...@gcc.gnu.org
To: g...@gcc.gnu.org
CC: gcc-patc...@gcc.gnu.org
Status
==
GCC trunk which eventually wi
Hi All,
I know that most - if not all - of you do not follow the GCC Development
mailing list, so I'll forward the below message by the
Steering Committee.
In short: For anyone on this mailing list who already contributes to
gfortran and has a FSF copyright assignment, nothing changes.
Ki
to ask the Fortran Standardization Committee for an interpretation
(of the standard's text).
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
nction p(c, r)
complex, intent(in) :: c
real, intent(in):: r
p = c * r
end
I definitely see a difference between
$ gfortran -O2 -S complex.f90
and
$ gfortran -O2 -ffast-math -S complex.f90
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maarten
On 11/13/24 15:40, Richard Biener wrote:
On Wed, Nov 13, 2024 at 3:21 PM Toon Moene wrote:
On 11/13/24 15:12, Richard Biener wrote:
On Wed, Nov 13, 2024 at 3:05 PM Thomas Koenig wrote:
Hello world,
J3, the US Fortran standards committee, has passed
https://j3-fortran.org/doc/year/24/24
might be that Thomas finishes his UNSIGNED work, which surely
would be notable.
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
/2025-May/846097.html
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
MPI (which OpenMPI calls "vader" for reasons that escape me).
So I am certainly interested to compare Andre's implementation against
OpenCoarrays.
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
ossible ways to run into
deadlocks ...
Note that Thomas Koenig has written about this before:
https://gcc.gnu.org/pipermail/fortran/2025-June/062361.html.
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
illing to
build and test this branch to help flush out any issues.
Feedback and/or test results welcome.
Regards,
Jerry
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
give the same
results if the implementations are correct.
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
On 6/27/25 17:41, Toon Moene wrote:
Note: as the timeline at the top of the source implies, I have worked on
this until early 2021.
This means it compiled with gfortran 10 and 11.
So the problem is probably introduced after these versions.
[ Of course, while I perused the Fortran 2018
compiled with gfortran 10 and 11.
So the problem is probably introduced after these versions.
[ Of course, while I perused the Fortran 2018 standard while writing
this code, I could easily have made an error that gfortran 10/11 simply
didn't catch. ]
Kind regards,
--
Toon Moe
ran-test'.
Updating files: 100% (150947/150947), done.
HEAD is now at 6955bb63595 fortran: Testing patches for coarray shared
memory.
If you peruse the test run I did:
https://gcc.gnu.org/pipermail/gcc-testresults/2025-July/853295.html
you will see the 6955bb63595 mentioned in the test re
00 Found: 16
Expected: 160 Found: 160
$
So that seems to work.
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
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.
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 - ho
n't "hang" it certainly had a few hickup's and 20
seconds elapsed time is rather pathetic for this simple code.
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
and test runs:
https://gcc.gnu.org/pipermail/gcc-testresults/2025-July/853295.html
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
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
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 synchro
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
:28 +0200
Toon Moene wrote:
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
42 matches
Mail list logo
