-
Notifications
You must be signed in to change notification settings - Fork 901
need a way to disable REAL16 support with configure #8616
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Comments
I will add that this Fortran compiler does not support
|
Definitively not new, but your reference dates from 2014 and it related to a different topic (the MPI_Op not being correctly implemented and not the type support itself). That put aside, the F90 code is autogenerated (gen-mpi-sizeof.pl) and the REAL16 part should not be inside. I tried on few machines without being able to replicate, but I do not have access to an AArch64 with the NVidia compilers. Could this file be a leftover from a prior build ? If not can you remove ompi/mpi/fortran/mpif-h/sizeof_f.f90 in build directory, and do a make V=1. We would need to know how gen-mpi-sizeof.pl is invoked. |
This is a brand new build on a system I started using today so it's clean. NVHPC compilers are free. You can download and install using the shell commands provided on https://developer.nvidia.com/nvidia-hpc-sdk-downloads. You do not need GPUs attached to use them. |
|
The problem is that
|
As #6205 appears to be the cause here, maybe @kawashima-fj can take a look. I just need a way to disable |
There seems to be a real issue with the generator, as in the command line you provided the real16 is clearly turned off, so the code should not have been generated (independently of the real2 support). |
REAL16 here means 16-bit real not 16-byte real. The problem is that Open-MPI is enabling 2-byte floats when the NVF compiler doesn't support them, because they are not standard Fortran. |
You're right, short float enables the float16. What is configure saying about the support of short float ? |
@jeffhammond can you give this a try
(the default is |
Having extensions that require non-standard Fortran language features enabled by default seems like a bad decision. How many Fortran compilers support 2-byte floats? |
First things first: did this help? At first glance, it seems the configury logic of this extension fails to disqualify it (or at least the Fortran extension), |
I install NVHPV compilers without root every day.
That's all. I'll test configure later. Had to be AFK before I could try it. |
thanks for the info! nvidia website says to |
it seems there is something wrong with our logic: we only test Fortran with |
It will not be easy to change this, because this would force us to change the meaning of our defines and REAL16 is already used for REAL*16. But if we want to have this change in, we should amend it globally before the 5.0. |
I would argue that you should stop using |
@jeffhammond until we come up with a proper patch you can just use: diff --git a/ompi/mpi/fortran/mpif-h/Makefile.am b/ompi/mpi/fortran/mpif-h/Makefile.am
index b8225bf889..7d03514767 100644
--- a/ompi/mpi/fortran/mpif-h/Makefile.am
+++ b/ompi/mpi/fortran/mpif-h/Makefile.am
@@ -121,7 +121,7 @@ sizeof_f.f90:
--impl=$@ --ierror=mandatory --mpi \
--maxrank=$(OMPI_FORTRAN_MAX_ARRAY_RANK) \
--generate=$(OMPI_FORTRAN_BUILD_SIZEOF) \
- --real2=$(OMPI_HAVE_FORTRAN_REAL2) \
+ --real2=0 \
--real16=$(OMPI_HAVE_FORTRAN_REAL16) \
--complex4=$(OMPI_HAVE_FORTRAN_COMPLEX4) \
--complex32=$(OMPI_HAVE_FORTRAN_COMPLEX32) |
Yeah I did that already in all the Fortran interface directories. |
@ggouaillardet regarding
|
@ggouaillardet disabling extensions is not a solution here...
|
@ggouaillardet The NVHPC download page has been updated to make it clear that |
@jeffhammond a patchless workaround is to @bosilca @kawashima-fj There are two issues here:
|
@ggouaillardet I can name a second compiler that supports it despite not being a standardized type. I can see 2 solutions:
|
@bosilca this non standard So a third option is to simply get rid of short float in the Fortran diff --git a/ompi/mpi/fortran/base/gen-mpi-sizeof.pl b/ompi/mpi/fortran/base/gen-mpi-sizeof.pl
index 194e7b0e7f..3670744967 100755
--- a/ompi/mpi/fortran/base/gen-mpi-sizeof.pl
+++ b/ompi/mpi/fortran/base/gen-mpi-sizeof.pl
@@ -153,7 +153,7 @@ sub generate {
for my $size (qw/8 16 32 64/) {
queue_sub("integer(int${size})", "int${size}", "int${size}");
}
-for my $size (qw/16 32 64 128/) {
+for my $size (qw/32 64 128/) {
if (!($size == 16 && $mpi_real2 == 0) &&
!($size == 128 &&$mpi_real16 == 0)) {
queue_sub("real(real${size})", "real${size}", "real${size}"); and unless we want to keep the dead code since diff --git a/ompi/mpi/fortran/base/gen-mpi-sizeof.pl b/ompi/mpi/fortran/base/gen-mpi-sizeof.pl
index 3670744967..7e6ef55229 100755
--- a/ompi/mpi/fortran/base/gen-mpi-sizeof.pl
+++ b/ompi/mpi/fortran/base/gen-mpi-sizeof.pl
@@ -154,12 +154,10 @@ for my $size (qw/8 16 32 64/) {
queue_sub("integer(int${size})", "int${size}", "int${size}");
}
for my $size (qw/32 64 128/) {
- if (!($size == 16 && $mpi_real2 == 0) &&
- !($size == 128 &&$mpi_real16 == 0)) {
+ if (!($size == 128 &&$mpi_real16 == 0)) {
queue_sub("real(real${size})", "real${size}", "real${size}");
}
- if (!($size == 16 && $mpi_complex4 == 0) &&
- !($size == 128 && $mpi_complex32 == 0)) {
+ if (!($size == 128 && $mpi_complex32 == 0)) {
queue_sub("complex(real${size})", "complex${size}", "real${size}");
}
} I tested these patches with nvhpc compilers, and it worked out of the box (read the |
I think you want to support REAL*2 in MPI_SIZEOF until we can delete that unnecessary procedure. The REAL16 stuff should only exist if the compiler supports it. |
Right, it might be simpler to drop iso:real16 from sizeof. But then we should replace iso:real16 with REAL*2 in sizeof as suggested by @jeffhammond |
a PR is coming, I took the long road and will use |
I was thinking about this, but the fortran documentation is so scattered and incomplete that I had a hard time understanding the difference between the two types. However some of the documentation I found (mostly GNU, Intel and Oracle) seem to indicate that the two types iso:real16 and REAL*2 do not have to be equivalent, the former being an optional 16 bits floating point representation while the latter real of at least 2 bytes. |
Though this has not landed into the Fortran standard, some compilers support REAL16 in the ISO_FORTRAN_ENV module. Use it when available, and fallback to REAL*2 and COMPLEX*4 otherwise. Thanks Jeff Hammond for reporting this issue Ref. open-mpi#8616 Signed-off-by: Gilles Gouaillardet <[email protected]>
In that case I can do both |
Though this has not landed into the Fortran standard, some compilers support REAL16 in the ISO_FORTRAN_ENV module. Use it when available, and fallback to REAL*2 and COMPLEX*4 otherwise. Thanks Jeff Hammond for reporting this issue Ref. open-mpi#8616 Signed-off-by: Gilles Gouaillardet <[email protected]>
Though this has not landed into the Fortran standard, some compilers support REAL16 in the ISO_FORTRAN_ENV module. Use it when available, and fallback to REAL*2 and COMPLEX*4 otherwise. Thanks Jeff Hammond for reporting this issue Ref. open-mpi#8616 Signed-off-by: Gilles Gouaillardet <[email protected]>
Though this has not landed into the Fortran standard, some compilers support REAL16 in the ISO_FORTRAN_ENV module. Use it when available, and fallback to REAL*2 and COMPLEX*4 otherwise. Thanks Jeff Hammond for reporting this issue Ref. open-mpi#8616 Signed-off-by: Gilles Gouaillardet <[email protected]> (cherry picked from commit 3a6fc24)
@jeffhammond Fixed in master via #8637 As a side note, feel free to ask the nvhpc compiler team to support the non standard (yet ?) |
Merged into v5.0.x here: |
Closing. Unless this is desired on the v4 series, in which case please reopen and do the appropriate cherry-picks. |
I am trying to build e604107 on an AArch64 system with NVHPC Fortran 21.2-0.
It appears that REAL16 support in NVFortran isn't what Open-MPI is looking for, but I do not care about REAL16 support and would prefer to just not have it in the build.
I see this is not a new problem (#63) but cannot figure out how to disable REAL16 now.
Reproduce
You need to use GCC for C/C++ and NVIDIA Fortran to reproduce this.
The text was updated successfully, but these errors were encountered: