- changed status to open
- removed comment
remove fortran compiler option -m128bit-long-double from general option lists
According to the documentation:
-m96bit-long-double
-m128bit-long-double
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.
Keyword:
Comments (8)
-
reporter -
- changed status to open
- removed comment
Fine with me.
-
- 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.
-
- 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.
-
- 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.
-
- 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.
-
reporter - changed status to resolved
- removed comment
This has been fixed in 5380a83. Should there be a problem with long doubles, please open a new ticket.
-
- edited description
- changed status to closed
- Log in to comment