Fwd: gfortran fp16
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 didn't find the fp16 in gfortran but in C language. Is there any solutions? Best Gang Chen School of Mathematics Sichuan University, China
Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
On 7/27/22 21:45, Harald Anlauf via Fortran wrote: Hi Mikael, Am 26.07.22 um 21:25 schrieb Mikael Morin: 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. May I suggest that, if well known Fortran 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
Re: [PATCH, v2] Fortran: fix invalid rank error in ASSOCIATED when rank is remapped [PR77652]
Looks good to me. Thanks ! Toon. On 7/30/22 12:03, Mikael Morin wrote: 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, but an answer for each example should give a good picture. Anything to correct or change? Anything to add? Mikael Hello, we are contributors to gfortran. We have been discussing the restrictions a processor is required to put on ASSOCIATED functions calls with regards to rank mismatch in the thread at: https://gcc.gnu.org/pipermail/fortran/2022-July/058012.html The following discussions are on the same topic as well: https://groups.google.com/g/comp.lang.fortran/c/BQfpeDZxX3Q https://community.intel.com/t5/Intel-Fortran-Compiler/Intel-rejects-ASSOCIATED-pointer-target-for-non-equal-ranks/m-p/1402799/highlight/true#M162159 The position from Steve Lionel in the latter threads is that a processor is required to reject an ASSOCIATED function call with arguments of mismatching ranks as there is no bounds-remapping list. Our understanding is that a processor shall accept it as long as it may accept a corresponding pointer association statement with additional bounds-remapping list. Our poll of existing compilers shows the same disagreement, with two accepting mismatching ranks (cray 14.0, nvidia 22.5) and two rejecting them (NAG 7.0 & 7.1, Intel). So we would like an official interpretation on this topic. More specifically, for each program below, is a processor (at compile time) required to reject it, allowed to reject it but not required to, or required to accept it? Harald Anlauf, Mikael Morin ! Example 1 ! matrix pointer vs array target program p real, dimension(100), target :: array real, dimension(:,:), pointer :: pmatrix => null() print *, associated(pmatrix, array) end ! Example 2 ! array pointer vs matrix target program p real, dimension(20,5), target :: matrix real, dimension(:), pointer :: parray => null() print *, associated(parray, matrix) end ! Example 3 ! array pointer vs rank 2 non-contiguous target program p real, dimension(20,5), target :: matrix real, dimension(:), pointer :: parray => null() print *, associated(parray, matrix(1:20:3, 1:5:2)) end ! Example 4 ! array pointer vs scalar target program p real, target :: scalar real, dimension(:), pointer :: parray => null() print *, associated(parray, scalar) end ! Example 5 ! scalar pointer vs array target program p real, dimension(100), target :: array real, pointer :: pscalar => null() print *, associated(pscalar, array) end ! Example 6 ! assumed rank (array) pointer vs matrix target program p real, dimension(20,5), target :: matrix real, dimension(:), pointer :: parray => null() call sub(parray) contains subroutine sub(ptr) real, pointer :: ptr(..) print *, associated(ptr, matrix) end subroutine sub end ! Example 7 ! assumed rank (scalar) pointer vs array target program p real, dimension(100), target :: array real, pointer :: pscalar => null() call sub(pscalar) contains subroutine sub(ptr) real, pointer :: ptr(..) print *, associated(ptr, array) end subroutine sub end ! Example 8 ! assumed rank (array) pointer vs scalar target program p real, target :: scalar real, dimension(:), pointer :: parray => null() call sub(parray) contains subroutine sub(ptr) real, pointer :: ptr(..) 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
Re: Team Collaboration Considerations
On 12/8/22 20:14, Holcomb, Katherine A (kah3f) via Fortran wrote: I was thinking I might try to contribute when I retire, though that may be in a year or two. But it's been a very long time since I dove into a large software project and it's intimidating. I do know C (really C++, I haven't used plain C for a long time). I am one of those "aging" types but I am familiar at least superficially with newer tools because I must use them for work, specifically git and Slack (Mattermost seems to be an open-source Slack alternative) -- we make heavy use of Slack in particular. Is there some kind of "getting started" guide? Thanks, Katherine, for your thoughts on this side of support (i.e., fixing compiler bugs, and how to get people interested in contributing). Based on that, I thought of another approach, namely: interesting *users* of gfortran to provide us with useful information on their experiences with it (lest we only look at the depressing list of PRs). Would it help if we created a fortran-h...@gcc.gnu.org list (a loose parallel of gcc-h...@gcc.gnu.org) for *questions* from our user base ? I just have to look at the questions I get at work from my colleagues: 1. I get this message while compiling XYZ weather forecasting model (HELP, what does it mean ?). How do I solve it ? Do I need ABC (mega-corporation chip manufacturing's) fortran compiler ? 2. gfortran gives me a "internal compiler error", but this code compiled perfectly just a year ago (an ICE is never a user's problem). How can I work around it ? 3. Is this (source code provided) code conformant ? gfortran complains about it, but XYZ compiler just compiles it fine. etc. This might not result in many new contributors, 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 with such a mailing list. Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: Team Collaboration Considerations
On 12/9/22 22:56, Paul Richard Thomas wrote: One really helpful collaborative activity would be to update the gfortran wiki. For a good long while that, together with the gfortran list, did serve as our collaborative focus. Another thing I might have tons of time for beyond 20230827. Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: Team Collaboration Considerations
On 1/19/23 13:28, NightStrike via Fortran wrote: On Thu, Jan 19, 2023, 00:01 Benson Muite via Fortran wrote: The GCC workflows is quite different from other open source projects being primarily email based and not using a bug tracker. There's a bug tracker. I think you mean there isn'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 Maartensdijk, The Netherlands
Test with an lto-build of libgfortran.
Hi all, During the GNU Tools Cauldron we discussed (at the BoF: IPA & LTO) the possibility (and hazards) of building the run time libraries for various compilers with -flto, enabling an -flto -static linking of programs with the run time library available during link time optimizations. Today I tried that on my (AMD Ryzen 7 5800U) laptop with gcc version 14.0.0 20230926 (experimental) [master r14-4282-g53daf67fd55] (GCC) with the following "quick hack": diff --git a/libgfortran/configure b/libgfortran/configure index cd176b04a14..69a2b4a8881 100755 --- a/libgfortran/configure +++ b/libgfortran/configure @@ -5959,11 +5959,11 @@ fi # Add -Wall -fno-repack-arrays -fno-underscoring if we are using GCC. have_real_17=no if test "x$GCC" = "xyes"; then - AM_FCFLAGS="-I . -Wall -Werror -fimplicit-none -fno-repack-arrays -fno-underscoring" + AM_FCFLAGS="-I . -Wall -Werror -fimplicit-none -fno-repack-arrays -fno-underscoring -flto" ## We like to use C11 and C99 routines when available. This makes ## sure that ## __STDC_VERSION__ is set such that libc includes make them available. - AM_CFLAGS="-std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -Werror=implicit-function-declaration -Werror=vla" + AM_CFLAGS="-std=gnu11 -Wall -Wstrict-prototypes -Wmissing-prototypes -Wold-style-definition -Wextra -Wwrite-strings -Werror=implicit-function-declaration -Werror=vla -flto" ## Compile the following tests with the same system header contents ## that we'll encounter when compiling our own source files. CFLAGS="-std=gnu11 $CFLAGS" The build of this compiler (languages=fortran) completed without problems (no test results - not enough time). I then proceeded to build LAPACK with the following build options: CFLAGS = -O3 -flto -flto-partition=none -static and FFLAGS = -O3 -flto -flto-partition=none -static This gave the same test results of the LAPACK test suite as the build with the same compiler, but without an lto'd libgfortran. The lto-ing of libgfortran did succeed, because I did get a new warning: gfortran -O3 -flto -flto-partition=none -static -o xlintstrfz zchkrfp.o zdrvrfp.o zdrvrf1.o zdrvrf2.o zdrvrf3.o zdrvrf4.o zerrrfp.o zlatb4.o zlaipd.o zlarhs.o zsbmv.o zget04.o zpot01.o zpot03.o zpot02.o chkxer.o xerbla.o alaerh.o aladhd.o alahd.o alasvm.o ../../libtmglib.a ../../liblapack.a ../../librefblas.a In function 'xtoa_big', inlined from 'write_z' at /home/toon/compilers/gcc/libgfortran/io/write.c:1296:11, inlined from 'formatted_transfer_scalar_write' at /home/toon/compilers/gcc/libgfortran/io/transfer.c:2136:4: /home/toon/compilers/gcc/libgfortran/io/write.c:1222:6: warning: writing 1 byte into a region of size 0 [-Wstringop-overflow=] 1222 | *q = '\0'; | ^ /home/toon/compilers/gcc/libgfortran/io/write.c: In function 'formatted_transfer_scalar_write': /home/toon/compilers/gcc/libgfortran/io/write.c:1291:8: note: at offset [34, 4294967294] into destination object 'itoa_buf' of size 33 1291 | char itoa_buf[GFC_XTOA_BUF_SIZE]; |^ which was (of course) 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
Re: Test with an lto-build of libgfortran.
On 9/28/23 07:33, Thomas Koenig wrote: Hi Toon, [ I wrote: ] 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. I didn't attend the Cauldron (but that discussion would have been very interesting). I think for libgfortran, a first step would be additional work to get declarations on both sides to agree (which is worth doing anyway). Best regards Thomas The big problem in *distributing* GCC (i.e., the collection) with lto'd run-time libraries is that the format of the lto structure changes with releases. If a compiler (by accident) picks up a run time library with non-matching lto objects, it might crash (or "introduce subtle errors in a once working program"). I.e., like the problem the gfortran community had with the changing format 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
Re: Test with an lto-build of libgfortran.
On 9/28/23 21:26, Jakub Jelinek wrote:
It is worse than that, usually the LTO format changes e.g. any time any
option or parameter is added on a release branch (several times a year) and
at other times as well.
Though, admittedly GCC is the single package that actually could get away
with LTO in lib*.a libraries, at least in some packagings (if the static
libraries are in gcc specific subdirectories rather than say /usr/lib{,64}
or similar and if the packaging of gcc updates both the compiler and
corresponding static libraries in a lock-step. Because in that case LTO
in there will be 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 Maartensdijk, The Netherlands
Re: Complex numbers support: discussions summary
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 of the
Cauldron
(https://gcc.gnu.org/wiki/cauldron2023talks?action=AttachFile&do=view&target=Exposing+Complex+Numbers+to+Target+Back-ends+%28paper%29.pdf).
Thanks for the detailed presentation at the Cauldron.
My personal summary is that I'm less convinced delaying lowering is
the way to go.
Thanks Sylvain for the quick summary of the discussion - it helps a
great deal now that the discussion is still fresh in our memory.
I found time today to run some tests.
First of all, the result of the gcc test harness as applied to the top
of the complex/kvx branch in the https://github.com/kalray/gcc repository:
https://gcc.gnu.org/pipermail/gcc-testresults/2023-October/797627.html
I think there are several complex failures here that are not in
"standard" 12.2 release (for x86_64-linux-gnu).
I also compiled all of lapack-3.11.0 with that compiler and obtained the
same results as with gcc/gfortran 13.2:
--> LAPACK TESTING SUMMARY <--
Processing LAPACK Testing output found in the TESTING directory
SUMMARY nb test run numerical error other error
=== =
REAL1327023 0 (0.000%)0
(0.000%)
DOUBLE PRECISION1300917 6 (0.000%)0
(0.000%)
COMPLEX 786775 0 (0.000%)0
(0.000%)
COMPLEX16 787842 0 (0.000%)0
(0.000%)
--> ALL PRECISIONS 4202557 6 (0.000%)0 (0.000%)
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Fwd: [PATCH] testsuite, gfortan: Update link flags [PR112862].
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_64, aarch64 Linux,
OK for trunk?
thanks, Iain
--- 8< ---
The regressions here are caused by two issues:
1. In some cases there is no generated runpath for libatomic
2. In other cases there are duplicate paths.
This patch simplifies the addition of the options in the main
gfortran exp and removes the duplicates elewhere.
We need to add options to locate libgfortran and the dependent libs
libquadmath (supporting REAL*16) and libatomic (supporting operations
used by coarrays). Usually '-L' options are added to point to the
relevant directories for the uninstalled libraries.
In cases where libraries are available as both shared and convenience
some additional checks are made.
For some targets -static- options are handled by specs substitution
and need a '-B' option rather than '-L'. For Darwin, when embedded
runpaths are in use (the default for all versions after macOS 10.11),
'-B' is also needed to provide the runpath.
When '-B' is used, this results in a '-L' for each path that exists (so
that appending a '-L' as well is a needless duplicate). There are also
cases where tools warn for duplicates, leading to spurious fails.
PR target/112862
gcc/testsuite/ChangeLog:
* gfortran.dg/coarray/caf.exp: Remove duplicate additions of
libatomic handling.
* gfortran.dg/dg.exp: Likewise.
* lib/gfortran.exp: Decide on whether to present -B or -L to
reference the paths to uninstalled libgfortran, libqadmath and
libatomic and use that to generate the link flags.
---
gcc/testsuite/gfortran.dg/coarray/caf.exp | 16 +
gcc/testsuite/gfortran.dg/dg.exp | 20 ---
gcc/testsuite/lib/gfortran.exp| 73 +++
3 files changed, 51 insertions(+), 58 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/coarray/caf.exp
b/gcc/testsuite/gfortran.dg/coarray/caf.exp
index dae46bd92fa..31c13cd34e5 100644
--- a/gcc/testsuite/gfortran.dg/coarray/caf.exp
+++ b/gcc/testsuite/gfortran.dg/coarray/caf.exp
@@ -70,18 +70,6 @@ proc dg-compile-aux-modules { args } {
}
}
-# Add -latomic only where supported. Assume built-in support elsewhere.
-set maybe_atomic_lib ""
-if [check_effective_target_libatomic_available] {
-if ![is_remote host] {
- if [info exists TOOL_OPTIONS] {
- set maybe_atomic_lib "[atomic_link_flags [get_multilibs
${TOOL_OPTIONS}]]"
- } else {
- set maybe_atomic_lib "[atomic_link_flags [get_multilibs]]"
- }
-}
-}
-
# Main loop.
foreach test [lsort [glob -nocomplain
$srcdir/$subdir/*.\[fF\]{,90,95,03,08} ]] {
# If we're only testing specific files and this isn't one of them,
skip it.
@@ -105,14 +93,14 @@ foreach test [lsort [glob -nocomplain
$srcdir/$subdir/*.\[fF\]{,90,95,03,08} ]]
foreach flags $option_list {
verbose "Testing $nshort (single), $flags" 1
set gfortran_aux_module_flags "-fcoarray=single $flags"
- dg-test $test "-fcoarray=single $flags" $maybe_atomic_lib
+ dg-test $test "-fcoarray=single $flags" {}
cleanup-modules ""
}
foreach flags $option_list {
verbose "Testing $nshort (libcaf_single), $flags" 1
set gfortran_aux_module_flags "-fcoarray=lib $flags -lcaf_single"
- dg-test $test "-fcoarray=lib $flags -lcaf_single" $maybe_atomic_lib
+ dg-test $test "-fcoarray=lib $flags -lcaf_single" {}
cleanup-modules ""
}
}
diff --git a/gcc/testsuite/gfortran.dg/dg.exp
b/gcc/testsuite/gfortran.dg/dg.exp
index f936fd38644..7a9cb89c194 100644
--- a/gcc/testsuite/gfortran.dg/dg.exp
+++ b/gcc/testsuite/gfortran.dg/dg.exp
@@ -54,27 +54,7 @@ proc dg-compile-aux-modules { args } {
}
}
-# coarray tests might need libatomic. Assume that it is either not
needed or
-# provided by builtins if it's not available.
-set maybe_atomic_lib ""
-if [check_effective_target_libatomic_available] {
-if ![is_remote host] {
- if [info exists TOOL_OPTIONS] {
- set maybe_atomic_lib "[atomic_link_flags [get_multilibs
${TOOL_OPTIONS}]]"
- } else {
- set maybe_atomic_lib "[atomic_link_flags [get_multilibs]]"
- }
-} else {
-set maybe_atomic_lib ""
-}
-}
-
set all_flags $DEFAULT_FFLAGS
-if { $maybe_atomic_lib != "" } {
- foreach f $maybe_atomic_lib {
- lappend all_flags $f
- }
-}
# Main loop.
gfortran-dg-runtest [lsort \
diff --git a/gcc/testsuite/lib/gfortran.exp b/gcc/testsuite/lib/gfortran.exp
index c3e258b410b..1ccb81ccec5 100644
--- a/gcc/testsuite/lib/gfortran.exp
+++ b/gcc/testsuite/lib/gfortran.exp
@@ -79,6 +79,7 @@ proc gfortran_link_flags { paths } {
global ld_library_path
global GFORTRAN_UNDER_TEST
glob
Re: [PATCH]AArch64: xfail modes_1.f90 [PR107071]
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:
-Original Message-
From: Tamar Christina
Sent: Thursday, February 15, 2024 11:05 AM
To: Richard Earnshaw (lists) ; gcc-
patc...@gcc.gnu.org
Cc: nd ; Marcus Shawcroft ; Kyrylo
Tkachov ; Richard Sandiford
Subject: RE: [PATCH]AArch64: xfail modes_1.f90 [PR107071]
-Original Message-
From: Richard Earnshaw (lists)
Sent: Thursday, February 15, 2024 11:01 AM
To: Tamar Christina ; gcc-patc...@gcc.gnu.org
Cc: nd ; Marcus Shawcroft ;
Kyrylo
Tkachov ; Richard Sandiford
Subject: Re: [PATCH]AArch64: xfail modes_1.f90 [PR107071]
On 15/02/2024 10:57, Tamar Christina wrote:
Hi All,
This test has never worked on AArch64 since the day it was committed. It has
a number of issues that prevent it from working on AArch64:
1. IEEE does not require that FP operations raise a SIGFPE for FP operations,
only that an exception is raised somehow.
2. Most Arm designed cores don't raise SIGFPE and instead set a status register
and some partner cores raise a SIGILL instead.
3. The way it checks for feenableexcept doesn't really work for AArch64.
As such this test doesn't seem to really provide much value on AArch64 so we
should just xfail it.
Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
Wouldn't it be better to just skip the test. XFAIL just adds clutter to verbose
output
and suggests that someday the tools might be fixed for this case.
Better still would be a new dg-requires fp_exceptions_raise_sigfpe as a guard
for
the test.
It looks like this is similar to
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78314 so
I'll just similarly skip it.
--- inline copy of patch ---
diff --git a/gcc/testsuite/gfortran.dg/ieee/modes_1.f90
b/gcc/testsuite/gfortran.dg/ieee/modes_1.f90
index
205c47f38007d06116289c19d6b23cf3bf83bd48..e29d8c678e6e51c3f2e5dac53c7703bb18a99ac4
100644
--- a/gcc/testsuite/gfortran.dg/ieee/modes_1.f90
+++ b/gcc/testsuite/gfortran.dg/ieee/modes_1.f90
@@ -1,5 +1,5 @@
! { dg-do run }
-!
+! { dg-skip-if "PR libfortran/78314" { aarch64*-*-gnu* arm*-*-gnueabi
arm*-*-gnueabihf } }
! Test IEEE_MODES_TYPE, IEEE_GET_MODES and IEEE_SET_MODES
Regtested on aarch64-none-linux-gnu and no issues.
Ok for master?
OK, but please give the fortran maintainers 24hrs to comment before pushing.
R.
Thanks,
Tamar
gcc/testsuite/ChangeLog:
PR fortran/107071
* gfortran.dg/ieee/modes_1.f90: skip aarch64, arm.
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Tests of gcc development beyond its testsuite (in this case, for gfortran)
I have now, for some time, ran LAPACK's test programs on my gcc/gfortran builds on both on the x86_64-linux-gnu architecture, as well as the aarch64-linux-gnu one (see, e.g., http://moene.org/~toon/lapack-amd64-gfortran13-O3). The results are rather alarming - this is r15-202 for aarch64 vs r15-204 for x86_64 (compiled with -O3): diff lapack-amd64-gfortran15-O3 lapack-aarch64-gfortran15-O3 3892,3895c3928,3931 < REAL 1327023 0 (0.000%)0 (0.000%) < DOUBLE PRECISION 1300917 6 (0.000%)0 (0.000%) < COMPLEX786775 0 (0.000%)0 (0.000%) < COMPLEX16 787842 0 (0.000%)0 (0.000%) --- > REAL 1317063 71 (0.005%)0 (0.000%) > DOUBLE PRECISION 1318331 54 (0.004%)4 (0.000%) > COMPLEX767023 390 (0.051%)0 (0.000%) > COMPLEX16 772338 305 (0.039%)0 (0.000%) 3897c3933 < --> ALL PRECISIONS 4202557 6 (0.000%)0 (0.000%) --- > --> ALL PRECISIONS 4174755 820 (0.020%)4 (0.000%) Note the excessive exceeding the threshold for errors on the aarch64 side (>). Of course, this is only an excerpt of the full log 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 ? Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)
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 ISA does not include it, it is not 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, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)
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 ISA does not include it, it is not 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, 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 will try that when the Sun rises again and I have some power to run the AArch64 machine ...). I must say I didn't expected this - the discussion on the "Intel" side was always that the fact that fused multiply-add instruction didn't express the "real computations" expressed by the program meant that they were evil and therefore had to be hidden behind some special compiler option that made it very clear that those instruction were evil. Again, thanks to point me to the difference (in philosophy, if not math) between to the two continents (i.e., the Americas and Europe's - before Brexit - England :-) Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)
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 will try that when the Sun rises again and I have some power to run the AArch64 machine ...). Well, I did two independent runs with gfortran-13.2 and the following options: -O3 -march=armv8.1-a+rdma and -O3 -march=armv8.1-a+nordma No difference in the number of error runs exceeding the prescribed thresholds. So, unless I made a mistake in the option specification (or the compiler silently ignored them because they were not applicable to my machine - ugh), the cause of the problem lies elsewhere. Kind regards, -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)
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 default for -march=armv8.1-a. I.e., -mno-rdma (I hope that's correct - I'll will try that when the Sun rises again and I have some power to run the AArch64 machine ...). Well, I did two independent runs with gfortran-13.2 and the following options: -O3 -march=armv8.1-a+rdma and -O3 -march=armv8.1-a+nordma No difference in the number of error runs exceeding the prescribed thresholds. So, unless I made a mistake in the option specification (or the compiler silently ignored them because they were not applicable to my machine - ugh), the cause of the problem lies elsewhere. AARCH64 armv8-a has FMA as part of its base ISA. So you want to try with `-ffp-contract=off` instead. RDMA turns on/off instructions which are not used by the auto-vectorizer (yet) and used by intrinsics for them (If I read the code correctly). Ah, thanks - I'll try that tomorrow. -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: Tests of gcc development beyond its testsuite (in this case, for gfortran)
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 Accumulate instructions. This is on by default for -march=armv8.1-a. I.e., -mno-rdma (I hope that's correct - I'll will try that when the Sun rises again and I have some power to run the AArch64 machine ...). Well, I did two independent runs with gfortran-13.2 and the following options: -O3 -march=armv8.1-a+rdma and -O3 -march=armv8.1-a+nordma No difference in the number of error runs exceeding the prescribed thresholds. So, unless I made a mistake in the option specification (or the compiler silently ignored them because they were not applicable to my machine - ugh), the cause of the problem lies elsewhere. AARCH64 armv8-a has FMA as part of its base ISA. So you want to try with `-ffp-contract=off` instead. RDMA turns on/off instructions which are not used by the auto-vectorizer (yet) and used by intrinsics for them (If I read the code correctly). Ah, thanks - I'll try that tomorrow. Yep, that did it: --> LAPACK TESTING SUMMARY <-- Processing LAPACK Testing output found in the TESTING directory SUMMARY nb test run numerical error other error === = REAL1327023 0 (0.000%)0 (0.000%) DOUBLE PRECISION1327845 0 (0.000%)0 (0.000%) COMPLEX 786775 0 (0.000%)0 (0.000%) COMPLEX16 787842 0 (0.000%)0 (0.000%) --> ALL PRECISIONS 4229485 0 (0.000%)0 (0.000%) So, obviously, the threshold values for these tests were derived on a machine without fused-multiply-add, or without using them if present. This is perhaps not surprising, as the default build-and-test setup (make.inc.example) of the LAPACK package as distributed from netlib.org lists as the compiler choice: FC = gfortran FFLAGS = -O2 -frecursive FFLAGS_DRV = $(FFLAGS) FFLAGS_NOOPT = -O0 -frecursive which means that the choice of architecture on x86-64 would be "generic" and wouldn't include FMA instructions. If the authors had used that setup in deriving the thresholds, it is not surprising that you need -ffp-contract=off on architectures that include FMA instructions by default. Thanks for helping me out with this ! -- Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: git help: fortran_unsigned branch
On 8/9/24 21:58, Mikael Morin wrote: Hello, Le 09/08/2024 à 21:40, Thomas Koenig a écrit : Am 09.08.24 um 21:17 schrieb Dimitar Dimitrov: I assume you reset your local branch? The branch on the server does not seem to be affected. I suggest to rebase the remote branch using another local branch. Example: # Just in case, see which is your old local branch. $ git branch # Create a new local tracking branch $ git checkout -b fortran_unsigned-20240809 origin/devel/fortran_unsigned $ git rebase origin/master $ gitk -n1000 I tried that, with te same result: warning: skipped previously applied commit a6399bb27b3 hint: use --reapply-cherry-picks to include skipped commits hint: Disable this message with "git config advice.skippedCherryPicks false" Successfully rebased and updated refs/heads/fortran_unsigned-20240809. $ git status On branch fortran_unsigned-20240809 Your branch and 'origin/devel/fortran_unsigned' have diverged, and have 690 and 198 different commits each, respectively. (use "git pull" to merge the remote branch into yours) So, it seems I already pushed something dubious previously. Isn'it the expected outcome? As soon as you rebase, you have a local branch based on a recent master, and a remote branch still with the patches applied on an older master. So they have diverged. So why do "we" want to use rebase ? Wouldn't it be more "natural" to merge master into your branch, and work from that ? I must say that in my professional (i.e., paid) life using git, I always had to work from a master that was "derived" from a remote repository, so "the god-given truth", I tend to treat our local branches as something that had to survive 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
Fwd: GCC 11.0.1 Status Report (2021-03-16)
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 will become GCC 11 is still in regression and documentation fixes only mode (Stage 4). If history should repeat itself then a first release candidate of GCC 11 will be released mid April. For this to happen we need to resolve the remaining 17 P1 regressions - 8 of which are classified as target or bootstrap issues. Please have a look at the set of P1 (and preferably also P2) regressions which can be conveniently accessed via the 'Serious regressions' link on https://gcc.gnu.org Quality Data Priority # Change from last report --- --- P1 17 - 45 P2 288 - 46 P3 37 + 1 P4 192 + 2 P5 24 --- --- Total P1-P3 342 - 90 Total 558 - 88 Previous Report === https://gcc.gnu.org/pipermail/gcc/2021-January/234703.html
Fwd: Update to GCC copyright assignment policy
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. Kind regards, Toon. Forwarded Message Subject: Update to GCC copyright assignment policy Date: Tue, 1 Jun 2021 10:00:06 -0400 From: David Edelsohn via Gcc Reply-To: David Edelsohn To: GCC Development GCC was created as part of the GNU Project but has grown to operate as an autonomous project. The GCC Steering Committee has decided to relax the requirement to assign copyright for all changes to the Free Software Foundation. GCC will continue to be developed, distributed, and licensed under the GNU General Public License v3.0. GCC will now accept contributions with or without an FSF copyright assignment. This change is consistent with the practices of many other major Free Software projects, such as the Linux kernel. Contributors who have an FSF Copyright Assignment don't need to change anything. Contributors who wish to utilize the Developer Certificate of Origin[1] should add a Signed-off-by message to their commit messages. Developers with commit access may add their name to the DCO list in the MAINTAINERS file to certify the DCO for all future commits in lieu of individual Signed-off-by messages for each commit. The GCC Steering Committee continues to affirm the principles of Free Software, and that will never change. - The GCC Steering Committee [1] https://developercertificate.org/
Re: [PATCH, Fortran] Fix setting of array lower bound for named arrays
On 11/30/21 8:54 PM, Harald Anlauf via Fortran wrote: Hi Tobias, You seem to be quite convinced with your interpretation, while I am simply confused. If both compiler developers are confused, and actual compiler implementations differ in their outcomes of the test case, IMNSHO it is time 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
Re: Complex arithmetic in Fortran
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-179.txt which states (with a bit of an overabundance of clarity) that, in Fortran, it is possible special-case complex multiplication when one of the numbers is known to have a zero component, for example when promoting a real to complex for complex multiplication. For example, multiplying a complex variable b with a real variable a can be done with c%re = b%re * a, c%im = b%im * a, without considering NaNs and infinities. Apparently, other Fortran compilers do this. They also stated that ISO/IEC 60559:2020 (aka IEEE 754) does not specify complex arithmetic (I wouldn't know, because it is a paywalled standard). How do we want to deal with this? Do we want to implement this (it's an obvious speed advantage)? Should it be the default? Do we want to include this in -fcx-fortran-rules? The middle-end complex lowering pass does this already, irrespective of NaNs, same for some degenerate cases with division. Are you sure ? For this code: $ cat complex.f90 complex function 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 Maartensdijk, The Netherlands
Re: Complex arithmetic in Fortran
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-179.txt
which states (with a bit of an overabundance of
clarity) that, in Fortran, it is possible special-case
complex multiplication when one of the numbers is known
to have a zero component, for example when promoting
a real to complex for complex multiplication. For
example, multiplying a complex variable b with a real
variable a can be done with c%re = b%re * a, c%im = b%im * a,
without considering NaNs and infinities. Apparently, other
Fortran compilers do this.
They also stated that ISO/IEC 60559:2020 (aka IEEE 754) does
not specify complex arithmetic (I wouldn't know, because it is a
paywalled standard).
How do we want to deal with this? Do we want to implement this
(it's an obvious speed advantage)? Should it be the default?
Do we want to include this in -fcx-fortran-rules?
The middle-end complex lowering pass does this already, irrespective
of NaNs, same for some degenerate cases with division.
Are you sure ?
For this code:
$ cat complex.f90
complex function 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
Ah. This is because of
static int
some_nonzerop (tree t)
{
int zerop = false;
/* Operations with real or imaginary part of a complex number zero
cannot be treated the same as operations with a real or imaginary
operand if we care about the signs of zeros in the result. */
if (TREE_CODE (t) == REAL_CST && !flag_signed_zeros)
zerop = real_identical (&TREE_REAL_CST (t), &dconst0);
so the -ffast-math result can be obtained with just -fno-signed-zeros (I assumed
fortran doesn't have signed zeros?)
Since the Fortran 95 Standard it does (in the current Standard: 7.4.3.2
Real type):
The real type includes a zero value. Processors that distinguish between
positive and negative zeros shall treat them as mathematically equivalent
• in all intrinsic relational operations, and
• as actual arguments to intrinsic procedures other than those for which
it is explicitly specified that negative zero is distinguished.
[Note that "processor" in Fortran standardese means everything
(combined) from the compiler down to the actual hardware].
So we have to comb through the Standard to see where bullet 2 applies ...
Kind regards,
--
Toon Moene - e-mail: t...@moene.org - phone: +31 346 214290
Saturnushof 14, 3738 XG Maartensdijk, The Netherlands
Re: [wwwdocs][Patch] gcc-15: Fortran - mention -funsigned + PowerPC Darwin IEEE module support
On 9/20/24 10:12, Tobias Burnus wrote: Hi all, I thought it makes sense to have a look at what went into GCC 15 to update the Fortran section. However, while several bugs were fixed (and extended some features a tiny bit) [hooray!], I did not really see many newsworthy features. Well, it 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
