Re: [PATCH, r3], Add optional IEEE/IBM long double multilib support

[Segher Boessenkool <segher at kernel dot crashing dot org>]

Hi!

On Fri, Jan 12, 2018 at 01:46:27AM -0500, Michael Meissner wrote:
> This is my current multilib version support for migrating PowerPC servers from
> using IBM extended double as the long double type to IEEE 128-bit floating
> point.
> 
> I have built both little endian and big endian PowerPC toolchains without the
> options, and it works with no regressions.  I have also built a PowerPC little
> endian multlib toolchain (with IBM extended double as the default) and it
> worked, once I remembered to add the --with-system-zlib option.
> 
> All of the other patches have been broken out of this patch and submitted (and
> now comitteed -- thanks Segher), and this patch just adds the option multlib
> support for PowerPC little endian.  I ran out of time to add the PowerPC big
> endian multilib support (as it has to merge with 64/32-bit multilibs, and it
> also can only be enabled if the compiler is compiled using --with-cpu with at
> least power7).

Right -- it will be much simpler if we can use ieee128 also without VSX.

> Some changes from the last change based on comments I got:
> 
> 1) The lib64 directory is the directory that holds the default libraries.  If
> you configure the default to be IEEE 128-bit, then those libraries are put into
> lib64.  As Bill Schmidt said in an internal meeting, that is required by the
> ABI.  Other languages should work normally, assuming they don't use long
> double.  If they do use long double and use other libraries than libc/libm,
> they may need to use an -L -rpath optiosn to point to the old libraries.  I'm
> sure as we get into modifying GLIBC 2.28, we will discover new things.

"Brace yourself, winter is coming".

> 2) If you configure the compiler so that IBM long double is the default, the
> IEEE libraries are in lib64/ieee128.  If you configure the compiler so that
> IEEE is the default, the IBM extended double libraries are in lib64/ibm128.  I
> assume if we do a big endian port, we would use lib/ieee128 and lib/ibm128.

For the 32-bit libs?  Yeah.

> 3) Tulio says that he believes that the GLIBC libraries will be able to handle
> the switch with a single library.  However, it is not clear to me that other
> libraries like libstdc++, boost, etc. would be easy to add the necessary
> support to change the interfaces based on the defines.  This is why I think we
> need multilibs, at least for a transition period.
> 
> 4) As before, you have to explicitly configure the long double format to enable
> the multilibs.  Particularly with having to create a special version of the
> Advance Toolchain with the crt/lib files in the alternate directory and use
> --with-system-zlib, you really don't want to enable the multilibs by default.
> 
> Can I check this into the trunk?
> 
> As I post this, there are two previous patches that have not been ack'ed that
> are not needed to enable the multilibs, but will be needed as we start doing
> the transition.  The patches are:
> 
> 1) The patch to set .gnu_attribute #4 if you use a long double value but don't
> do any calls.
> 
> 2) The patch to document the --with-long-double-format={ieee,ibm} option.
> 
> It would be useful if I could configure the compiler to look in lib64, if it
> doesn't find the objects in lib64/ieee128 or lib64/ibm128.  But perhaps it is
> safer if it doesn't, since some things may fall through the cracks.

I think it always does that?  If not, get back to me when you need this?

> Note, I will be on vacation for the next 4 days, and I will return on Tuesday
> January 16th, 2018.  I will not have access to mail for most of the time.

Enjoy your vacation!


Segher