On Wed, Oct 06, 2021 at 08:59:53AM +0200, Thomas Koenig wrote: > On 05.10.21 23:54, Segher Boessenkool wrote: > >>There is also the issue of binary data. If some user has written > >>out data in double double and wants to read it in as IEEE quad, > >>the results are going to be garbage. Another option for CONVERT > >>might be the solution to that, or, as you wrote, having a > >>REAL(KIND=15). It should be inaccessible via SELECTED_REAL_KIND, > >>though. > > > >That means flipping the default on all PowerPC to no longer be double- > >double. This means that you should have IEEE QP work everywhere, or the > >people who do need more than double precision will have no recourse. > > I think we can exclude big-endian POWER from this - they do not have > IEEE QP support, correct? So, exclude that from the SONAME change.
Not correct, no. IEEE QP works fine in either endianness. I don't know what the libraries do, but in GCC it works just fine. > So this would only be critical for people on little-endian POWER8 > who use double double. Hmm... can the POWER8 handle the IEEE QP > instructions, or would that be trap and emulate? What is the > plan there? The registers used by the QP insns are the VRs. Trying to use the QP insns on a p8 will trap. There is no kernel emulation for them afaik. But, for p8 there is software emulation, that GCC can generate. This follows the ABI as for p9 and later. > >It will be great if you can do this at the same time, get all the pain > >over with at the same time, have better results for everyone. Heck, you > >only need the "kind=15" for compatibility then. > > It would still mean that people would have to change their source code, > especially those who have followed the standard convention of > using selected_real_kind. Not sure what the consequences would be. Yes, that is pain. But pain once :-) > >People who have data stored in the old format will be in a tough spot > >no matter what. Presumably everyone will want to convert to the > >standard format at some point. > > In that case, extending the CONVERT option to the OPEN statement > might be the best way (plus the corresponding handling of the > environment variables and options). It would be slow, especially > when honoring NaN and INF, but people could at least read in data and > then write it out again. Converting double-double to IEEE QP should not be hard or slow? Segher
