compile GCC without quadmath on Apple Silicon to unbreak Fortran REAL128

[jeffhammond]

Provide a detailed description of the proposed feature

Please compile GCC with --disable-libquadmath --disable-libquadmath-support on Apple Silicon to match what is used on AArch64 Linux systems, and to allow whatever method of supporting float128 in Fortran is used there is used on Apple Silicon, thereby unbreaking this feature. libquadmath does not support ARM (as far as I have been able to determine).

What is the motivation for the feature?

REAL128 support is broken in Homebrew GCC Fortran on Apple Silicon, whereas it works with Homebrew GCC Fortran on Intel systems, and with GCC Fortran on Linux AArch64 systems.

% gfortran -ffree-form f.F              
f.F:3:15:

    3 |   real(real128) :: x
      |               1
Error: Kind -1 not supported for type REAL at (1)

% cat f.F 
program foo
  use, intrinsic :: iso_fortran_env, only: REAL_KINDS, real128
  real(real128) :: x
  x=0
  print*,x
end program foo

% gfortran -v
Using built-in specs.
COLLECT_GCC=gfortran
COLLECT_LTO_WRAPPER=/opt/homebrew/Cellar/gcc/10.2.0_4/libexec/gcc/aarch64-apple-darwin20/10.2.1/lto-wrapper
Target: aarch64-apple-darwin20
Configured with: ../configure --build=aarch64-apple-darwin20 --prefix=/opt/homebrew/Cellar/gcc/10.2.0_4 --libdir=/opt/homebrew/Cellar/gcc/10.2.0_4/lib/gcc/10 --disable-nls --enable-checking=release --enable-languages=c,c++,objc,obj-c++,fortran --program-suffix=-10 --with-gmp=/opt/homebrew/opt/gmp --with-mpfr=/opt/homebrew/opt/mpfr --with-mpc=/opt/homebrew/opt/libmpc --with-isl=/opt/homebrew/opt/isl --with-system-zlib --with-pkgversion='Homebrew GCC 10.2.0_4' --with-bugurl=https://github.com/Homebrew/homebrew-core/issues --disable-multilib --with-native-system-header-dir=/usr/include --with-sysroot=/Library/Developer/CommandLineTools/SDKs/MacOSX.sdk SED=/usr/bin/sed
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 10.2.1 20201220 (Homebrew GCC 10.2.0_4) 

How will the feature be relevant to at least 90% of Homebrew users?

It isn't. I doubt that any single package is used by 90% of Homebrew users, even GCC, and I am certain that less than half of all Homebrew users touch the Fortran compile. Among those that compile Fortran, I suspect only 1% use the 128-bit floating-point type, although it is part of widely used quantum chemistry codes like GAMESS.

What alternatives to the feature have been considered?

I can compile GCC myself, but avoiding this is the primary reason why I use Homebrew.

[carlocab]

CC @fxcoudert

[carlocab]

Have you tested whether compiling with the flags --disable-libquadmath --disable-libquadmath-support fixes your issues?

[jeffhammond]

@carlocab I haven't figured out how to do that properly yet but I am trying.

[jeffhammond]

Apparently GCC gets this from glibc if quadmath isn't present, which isn't useful on MacOS if glibc isn't used. But I'll try to verify this before closing the issue.

[fxcoudert]

REAL128 support is broken in Homebrew GCC Fortran on Apple Silicon

It's unsupported. Not broken, as the Fortran standard does not require the presence of a 128-bit floating-point type.

it works with Homebrew GCC Fortran on Intel

GCC features are different on different platforms. It is possible to open an issue at the upstream project so it gets improved, but I don't think it will have high priority. As for any new platform, there are a lot of important new things to get right.

---

I would like to get some more information on this, though:

it works with GCC Fortran on Linux AArch64 systems

and

--disable-libquadmath --disable-libquadmath-support is used on AArch64 Linux systems

Where are these options passed in aarch64-linux? And what math library runtime is used, if libquadmath is disabled?

Apparently GCC gets this from glibc if quadmath isn't present

If that's true, I didn't know glibc chose to ship with float128 library functions exposed. It certainly doesn't on Intel processors, otherwise libquadmath would not be necessary. But for macOS, we can't use this, anyway.

[fxcoudert]

PS: I don't think any widely-used software package should rely on the availability of real128. There are lots of targets that don't have it, lots of compilers that don't expose it. A good approach, as for any optional feature of the standard, would be to detect it and use conditionally.

[mitchblank]

I don't know the details involved, but just taking a quick glance at the debian build rules in https://sources.debian.org/src/gcc-10/10.2.1-6/debian/ :
In rules.defs

# libquadmath -------------------

quadmath_targets = amd64 ia64 i386 x32 \
		hurd-i386 kfreebsd-i386 kfreebsd-amd64 \
		ppc64el
# powerpc and ppc64 don't have power7 CPU defaults ...
ifneq (,$(filter $(DEB_TARGET_ARCH), $(quadmath_targets)))
  # FIXME: upstream build tied to gfortran build
  ifeq ($(with_fortran),yes)
    with_qmath := yes

In rules2:

ifneq ($(with_qmath),yes)
  CONFARGS += --disable-libquadmath --disable-libquadmath-support
endif

So it looks like they explicitly pass those flags when building gcc except when on x86 or ppc64le

[fxcoudert]

The upstream issue is at iains/gcc-darwin-arm64#5
Closing here