On Tue, Nov 02, 2021 at 07:19:10AM +0100, Thomas Koenig wrote: > > On 01.11.21 18:45, Jakub Jelinek wrote: > > Note, if we go the way of C/C++ with -mabi=ieeelongdouble vs. > > -mabi=ibmlongdouble choosing between the two ABIs and libgfortran being > > ABI compatible with both, then we don't need to bump soname. > > Sounds like one major pain solved. I think we should do if it possible. > > > But, if we don't bump it, we need to keep double double there backwards > > compatible (i.e. _r16 etc. being the double double, not IEEE). > > Correct. I would actually go for 17 for the IEEE because it is > the larger number, but that is a pure style issue and has no > impact on something that is user visible :-) > > > When in the future we bump the soname, we can swap those two and > > make _r16 newly stand for IEEE quad and _r15 or _r16d or whatever > > for double double. > > Yep. > > We do need to do something about the generated module files, though, to > make programs compiled with one option incompatible with the other ones > on that level.
In general, I wouldn't expect mixing and matching long double options to work. But you do want the library to have both versions of the library functions with different names. And as I've found out, outside of the official libraries, you run into smaller libraries (like gmp, mpfr, and mpc used in the compiler) that also need to be compiled with the right options because they have random functions that have long double elements (even if the app doesn't use the long double arguments). For example, in the C world, we need to have 3 versions of each of the *printf functions, since printf can be passed long double. > Or are people expected to get that right? :-) In terms of testing, it isn't ideal, but if you make a branch that we (IBM) can access, we can run it on our various systems. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com
