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
