public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
From: Thomas Koenig <tkoenig@netcologne.de>
To: FX Coudert <fxcoudert@gmail.com>
Cc: sgk@troutmask.apl.washington.edu,
	Harald Anlauf via Fortran <fortran@gcc.gnu.org>,
	gcc-patches@gcc.gnu.org,
	Michael Meissner <meissner@linux.ibm.com>
Subject: Re: [PATCH] Fortran: add Fortran 2018 IEEE_{MIN,MAX} functions
Date: Sun, 11 Jun 2023 11:50:46 +0200	[thread overview]
Message-ID: <f2e5194a-25aa-0596-2c30-b13163562a06@netcologne.de> (raw)
In-Reply-To: <38FC9C0B-84A0-43F9-A2B9-4F404A14E083@gmail.com>

Hi FX,

 >> The KIND=17 is a bit of a kludge.  It is not visible for
 >> user programs, they use KIND=16, but this is then translated
 >> to library calls as if it was KIND=17 if the IEEE 128-bit floats
 >> are selected
 >
 > Can you check what the IEEE test results are when 
-mabi=ieeelongdouble is enabled?
Running

nohup make -j7 check-fortran 
RUNTESTFLAGS="--target_board=unix/-mabi=ieeelongdouble/-mcpu=power9"&

from the gcc subdirectory yielded only a single failure:

grep ^FAIL nohup.out
FAIL: gfortran.dg/gomp/target-update-1.f90   -O   scan-tree-dump gimple 
"#pragma omp target update to\\(c \\[len: [0-9]+\\]\\) to\\(present:a 
\\[len: [0-9]+\\]\\) to\\(e \\[len: [0-9]+\\]\\) from\\(present:b 
\\[len: [0-9]+\\]\\) from\\(d \\[len: [0-9]+\\]\\)

and also ran the correct tests, as seen from gfortran.log; for example:

Executing on host: gfortran 
/home/tkoenig/gcc/gcc/testsuite/gfortran.dg/ieee/large_2.f90 
-mabi=ieeelongdouble -mcpu=power9   -fdiagnostics-plain-output 
-fdiagnostics-plain-output    -O0   -pedantic-errors 
-fintrinsic-modules-path 
/home/tkoenig/gcc-bin/powerpc64le-unknown-linux-gnu/./libgfortran/ 
-fno-unsafe-math-optimizations -frounding-math -fsignaling-nans    -lm 
-o ./large_2.exe    (timeout = 300)
spawn -ignore SIGHUP gfortran 
/home/tkoenig/gcc/gcc/testsuite/gfortran.dg/ieee/large_2.f90 
-mabi=ieeelongdouble -mcpu=power9 -fdiagnostics-plain-output 
-fdiagnostics-plain-output -O0 -pedantic-errors -fintrinsic-modules-path 
/home/tkoenig/gcc-bin/powerpc64le-unknown-linux-gnu/./libgfortran/ 
-fno-unsafe-math-optimizations -frounding-math -fsignaling-nans -lm -o 
./large_2.exe^M
PASS: gfortran.dg/ieee/large_2.f90   -O0  (test for excess errors)
Setting LD_LIBRARY_PATH to 
.:/home/tkoenig/lib/../lib64:.:/home/tkoenig/lib/../lib64
Execution timeout is: 300
spawn [open ...]^M
PASS: gfortran.dg/ieee/large_2.f90   -O0  execution test

This is a test that fails on POWER with the IBM long double format,
so things look ok.  It also works when compiled individually.

So, this is looking good.

By the way, if you or any other gfortran maintainer would like an
account on the POWER virtual machine in question, that would be
no problem. I would ask the cluster administrators for permission
and then create the account (I have admin privileges on that
virtual machine).

 > It’s not even clear to me what the IEEE kinds selected should be, in 
this case, depending on -mabi=ieeelongdouble

The "KIND=17" stuff should only be visible inside the library.

 >
 >> Regarding FX's patch: I am not quite sure that I am
 >> actually testing the right thing if running the testsuite
 >> there, so POWER should not hold up this patch.  If it turns
 >> out that POWER needs additonal work on IEEE, we can always
 >> add that later.
 >
 > Actually, it sounds like the situation is: the same target can
 > have two ABIs based on a compile-time flag. That sounds like a job
 > for multilib, i.e., we should compile libgfortran twice, one for
 > each ABI. I am sure> this was considered and rejected, do you
 > remember what was the rationale?

I don't remember discussing multilib in this context, sorry.

Best regards

	Thomas

  reply	other threads:[~2023-06-11  9:50 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-06 13:19 FX
2023-06-06 15:43 ` Steve Kargl
2023-06-06 15:51   ` Steve Kargl
2023-06-06 18:21     ` Steve Kargl
2023-06-06 19:00 ` Harald Anlauf
2023-06-06 19:00   ` Harald Anlauf
2023-06-06 19:11   ` FX Coudert
2023-06-07 18:31     ` Harald Anlauf
2023-06-07 18:31       ` Harald Anlauf
2023-06-07 18:50       ` Steve Kargl
2023-06-08 10:17         ` Thomas Koenig
2023-06-08 10:21           ` FX Coudert
2023-06-08 11:24             ` Thomas Koenig
2023-06-08 16:31           ` Steve Kargl
2023-06-08 18:17             ` Thomas Koenig
2023-06-10 15:24           ` FX Coudert
2023-06-11  9:50             ` Thomas Koenig [this message]
2023-06-11 13:43               ` FX Coudert
2023-06-06 19:35 ` FX Coudert
2023-06-07  3:15   ` Steve Kargl
2023-06-10 15:42     ` FX Coudert

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=f2e5194a-25aa-0596-2c30-b13163562a06@netcologne.de \
    --to=tkoenig@netcologne.de \
    --cc=fortran@gcc.gnu.org \
    --cc=fxcoudert@gmail.com \
    --cc=gcc-patches@gcc.gnu.org \
    --cc=meissner@linux.ibm.com \
    --cc=sgk@troutmask.apl.washington.edu \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).