remove fortran compiler option -m128bit-long-double from general option lists

Create issue
Issue #1845 closed
Frank Löffler created an issue

According to the documentation:

    These switches control the size of long double type. The i386 application binary interface specifies the size to be 96 bits, so -m96bit-long-double is the default in 32 bit mode.

    Modern architectures (Pentium and newer) would prefer long double to be aligned to an 8 or 16 byte boundary. In arrays or structures conforming to the ABI, this would not be possible. So specifying a -m128bit-long-double will align long double to a 16 byte boundary by padding the long double with an additional 32 bit zero.

    In the x86-64 compiler, -m128bit-long-double is the default choice as its ABI specifies that long double is to be aligned on 16 byte boundary.

    Notice that neither of these options enable any extra precision over the x87 standard of 80 bits for a long double.

    Warning: if you override the default value for your target ABI, the structures and arrays containing long double variables will change their size as well as function calling convention for function taking long double will be modified. Hence they will not be binary compatible with arrays or structures in code compiled without that switch.

The problem with this switch is that it is target-specific; it is only defined for Intel platforms. Option lists like 'debian.cfg' should not be target specific. I don't know why this flag was given, and from above docu I can only imagine it is to preserve binary-compatibility between 32bit and 64bit long doubles. On the other hand, I have no idea how that plays out with linked libraries that might have been compiled differently, and also I have no idea where we would actually use Fortran long doubles.

Thus, I here propose to remove this flag, at least from general option lists (not machine-specific), unless of course someone objects and can name a good reason to keep it. Currently it prevents option lists like debian.cfg or ubuntu.cfg from compiling on non-Intel platforms.


Comments (8)

  1. Erik Schnetter
    • removed comment

    The original motivation for -m128bit-long-double is to ensure that C and Fortran can both define a type CCTK_REAL16, and use the same internal representation for this type. Without this option, Fortran calls the extended precision type real10 or real12 (depending on the compiler), and the size of long double in C also isn't 16, so Cactus won't provide CCTK_REAL16.

    On a side note I want to remark that the option -march=native give substantial performance benefits on modern Intel CPUs, i.e. most workstations and laptops. However, this option is Intel-specific as well.

  2. Roland Haas
    • changed status to open
    • removed comment

    So the question would be if we an detect at configure time what a "long double" looks like and then make fortran use the same type for CCTK_REAL16 (no matter whether this is 10, 12 or 16 bytes). I don't think we need to make sure that a CCTK_REAL16 actually occupies 16 bytes, just that it is "better" than CCTK_REAL8 and is the same in both C/C++ and Fortran code.

  3. Steven R. Brandt
    • removed comment

    I don't know if anyone wants to worry about this, but I've seen VMs generate invalid instructions using gcc -march=native.

  4. Ian Hinder
    • removed comment

    I think that happens when a VM is created on one architecture, an executable compiled "native" to that architecture, and the VM is then run on another architecture, i.e. a different CPU. The code is then incompatible with the new CPU, generating the illegal instruction error. Probably the best solution to this is to use compilation options which are as generic as possible when compiling a configuration which will be included pre-built in a VM, just like, e.g., Debian, does when compiling packages which should run on a wide variety of hardware.

  5. Log in to comment