[power-ieee128] What should the math functions be annotated with?

[power-ieee128] What should the math functions be annotated with?

[Thomas Koenig]

I am currently working on implementing the IEEE 128-bit floating
on POWER.  One of the things to decide is what to call the
math functions for the library calls.

Example: libgfortran/generated/bessel_r16.c currently has

#if defined(GFC_REAL_16_IS_FLOAT128)
#define MATHFUNC(funcname) funcname ## q
#else
#define MATHFUNC(funcname) funcname ## l
#endif

(This is actually generated from an m4 file).

For the BesselJ functions, for example, either the library functions jnq
or jnl will be called.

We have chosen *_r17.c and _c17.c as the naming conventions for
library functions using IEEE 128-bit, and the files will be compiled
with mabi=ieeelongdouble.

So, what should the suffix for math functions be?  I assume they will be
picked up from some library.  Somebody else than me will have to make
sure this is done correctly, though :-)

Regards

	Thomas
So, what should the math functions be called so that they are actually
found in the library?

Re: [power-ieee128] What should the math functions be annotated with?

[Jakub Jelinek]

On Wed, Dec 01, 2021 at 09:34:47PM +0100, Thomas Koenig via Gcc wrote:
> I am currently working on implementing the IEEE 128-bit floating
> on POWER.  One of the things to decide is what to call the
> math functions for the library calls.
> 
> Example: libgfortran/generated/bessel_r16.c currently has
> 
> #if defined(GFC_REAL_16_IS_FLOAT128)
> #define MATHFUNC(funcname) funcname ## q
> #else
> #define MATHFUNC(funcname) funcname ## l
> #endif
> 
> (This is actually generated from an m4 file).
> 
> For the BesselJ functions, for example, either the library functions jnq
> or jnl will be called.

I think it depends.
Inside of libgfortran, I think it should depend on some macro defined
in libgfortran.h.
#if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
    && defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32)
then
#define MATHFUNC(funcname) __ ## funcname ## ieee128
(i.e. use the functions that will be used when one uses e.g.
sinl in C when compiled with -mabi=ieeelongdouble), but I'm not sure
if those need to be declared by libgfortran or math.h declares them).
Otherwise (when libgfortran is compiled against glibc older than 2.32)
it should use
#define MATHFUNC(funcname) funcname ## q
i.e. use the libquadmath APIs).

Now, when compiler itself actually emits calls like sinl etc. itself,
IMHO it should use solely those __ ## funcname ## ieee128 functions,
because that means either user uses explicit -mabi=ieeelongdouble
and at that point he needs to make sure he has glibc 2.32 or later,
or the compiler is configured to default to -mabi=ieeelongdouble and
user doesn't use -mabi=ibmlongdouble (then presumably again user has to
make sure glibc 2.32 or later is used).
The reason to use libquadmath as fallback inside of libgfortran is so that
one can build gcc against older glibc and keep the libgfortran ABI,
and then use the compiler against newer glibc (or the older glibc assuming
ibmlongdouble is used).

	Jakub

Re: [power-ieee128] What should the math functions be annotated with?

[Jakub Jelinek]

On Wed, Dec 01, 2021 at 09:54:50PM +0100, Jakub Jelinek wrote:
> sinl in C when compiled with -mabi=ieeelongdouble), but I'm not sure
> if those need to be declared by libgfortran or math.h declares them).

To answer this myself, just tried on Fedora 34 and we'd need to
declare those ourselves.
Because math.h for -mabi=ibmlongdouble (which we want to compile
the libgfortran *.c files with so that REAL16 is long double as before)
only has prototypes like:
extern long double sinl (long double __x) __attribute__ ((__nothrow__ , __leaf__)); extern long double __sinl (long double __x) __attribute__ ((__nothrow__ , __leaf__));
and with -mabi=ieeelongdouble it has:
extern long double sinl (long double __x) __asm__ ("" "__sinieee128") __attribute__ ((__nothrow__ , __leaf__)); extern long double __sinl (long double __x) __asm__ ("" "____sinieee128") __attribute__ ((__nothrow__ , __leaf__));
but in neither case there is what we actually need for libgfortran,
which is
extern __float128 __sinieee128 (__float128) __attribute__ ((__nothrow__, __leaf__));

	Jakub

Re: [power-ieee128] What should the math functions be annotated with?

[Thomas Koenig]

On 01.12.21 21:54, Jakub Jelinek via Fortran wrote:

> Inside of libgfortran, I think it should depend on some macro defined
> in libgfortran.h.
> #if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
>      && defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32)
> then
> #define MATHFUNC(funcname) __ ## funcname ## ieee128
> (i.e. use the functions that will be used when one uses e.g.
> sinl in C when compiled with -mabi=ieeelongdouble), but I'm not sure
> if those need to be declared by libgfortran or math.h declares them).
> Otherwise (when libgfortran is compiled against glibc older than 2.32)
> it should use
> #define MATHFUNC(funcname) funcname ## q
> i.e. use the libquadmath APIs).

The current Ubuntu does not have these functions:

ubuntu@gcc-fortran:/lib/powerpc64le-linux-gnu$ nm libm.a 2>/dev/null | 
grep ieee128
ubuntu@gcc-fortran:/lib/powerpc64le-linux-gnu$

Will they be supplied in the future, or with the advanced toolchain?

Regards

	Thomas

Re: [power-ieee128] What should the math functions be annotated with?

[Jakub Jelinek]

On Fri, Dec 03, 2021 at 08:29:53AM +0100, Thomas Koenig wrote:
> 
> On 01.12.21 21:54, Jakub Jelinek via Fortran wrote:
> 
> > Inside of libgfortran, I think it should depend on some macro defined
> > in libgfortran.h.
> > #if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
> >      && defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32)
> > then
> > #define MATHFUNC(funcname) __ ## funcname ## ieee128
> > (i.e. use the functions that will be used when one uses e.g.
> > sinl in C when compiled with -mabi=ieeelongdouble), but I'm not sure
> > if those need to be declared by libgfortran or math.h declares them).
> > Otherwise (when libgfortran is compiled against glibc older than 2.32)
> > it should use
> > #define MATHFUNC(funcname) funcname ## q
> > i.e. use the libquadmath APIs).
> 
> The current Ubuntu does not have these functions:
> 
> ubuntu@gcc-fortran:/lib/powerpc64le-linux-gnu$ nm libm.a 2>/dev/null | grep
> ieee128
> ubuntu@gcc-fortran:/lib/powerpc64le-linux-gnu$
> 
> Will they be supplied in the future, or with the advanced toolchain?

It is part of upstream glibc 2.32 (released Aug 2020) and later, see
https://sourceware.org/git/?p=glibc.git;a=commit;h=051be01f6b41a1466b07ae4bd7f5894a8ec5fe67
distrowatch says that glibc 2.32 and later is in Ubuntu 21.04 and later.

	Jakub

Re: [power-ieee128] What should the math functions be annotated with?

[Thomas Koenig]

On 03.12.21 10:28, Jakub Jelinek wrote:
> On Fri, Dec 03, 2021 at 08:29:53AM +0100, Thomas Koenig wrote:
>>
>> On 01.12.21 21:54, Jakub Jelinek via Fortran wrote:
>>
>>> Inside of libgfortran, I think it should depend on some macro defined
>>> in libgfortran.h.
>>> #if defined(__powerpc64__) && __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__ \
>>>       && defined __GLIBC_PREREQ && __GLIBC_PREREQ (2, 32)
>>> then
>>> #define MATHFUNC(funcname) __ ## funcname ## ieee128
>>> (i.e. use the functions that will be used when one uses e.g.
>>> sinl in C when compiled with -mabi=ieeelongdouble), but I'm not sure
>>> if those need to be declared by libgfortran or math.h declares them).
>>> Otherwise (when libgfortran is compiled against glibc older than 2.32)
>>> it should use
>>> #define MATHFUNC(funcname) funcname ## q
>>> i.e. use the libquadmath APIs).
>>
>> The current Ubuntu does not have these functions:
>>
>> ubuntu@gcc-fortran:/lib/powerpc64le-linux-gnu$ nm libm.a 2>/dev/null | grep
>> ieee128
>> ubuntu@gcc-fortran:/lib/powerpc64le-linux-gnu$
>>
>> Will they be supplied in the future, or with the advanced toolchain?
> 
> It is part of upstream glibc 2.32 (released Aug 2020) and later, see
> https://sourceware.org/git/?p=glibc.git;a=commit;h=051be01f6b41a1466b07ae4bd7f5894a8ec5fe67
> distrowatch says that glibc 2.32 and later is in Ubuntu 21.04 and later.
> 
> 	Jakub
> 

So it is not possible to test on the current machine set up for this,
which has ubuntu 20.04. This makes development rather pointless at
the moment :-(

So, what should the path forward be?

Re: [power-ieee128] What should the math functions be annotated with?

[Jakub Jelinek]

On Fri, Dec 03, 2021 at 12:16:56PM +0100, Thomas Koenig wrote:
> > It is part of upstream glibc 2.32 (released Aug 2020) and later, see
> > https://sourceware.org/git/?p=glibc.git;a=commit;h=051be01f6b41a1466b07ae4bd7f5894a8ec5fe67
> > distrowatch says that glibc 2.32 and later is in Ubuntu 21.04 and later.
> 
> So it is not possible to test on the current machine set up for this,
> which has ubuntu 20.04. This makes development rather pointless at
> the moment :-(
> 
> So, what should the path forward be?

glibc is backwards compatible, so if whomever has root on the machine would
just upgrade glibc, that would be enough.
I don't know if ubuntu has something like mock(1) that allows just
installing packages from a newer distro in a new chroot, that would be
another option.
One can also just as a user unpack newer glibc somewhere, configure gcc
against that tree as --with-sysroot= but for running tests one would need to
change dynamic_linker_prefix in specs -
*dynamic_linker_prefix:
/home/user/wherever
in some file and -specs=/that/file
but it would be a pain.
Note, we want to test both building gcc on ppc64le with older glibc
and newer glibc (and that libgfortran will have the same ABI between both
and one can move gcc including libgfortran and libquadmath from the older
glibc setup to newer and make -mabi=ieeelongdouble work in Fortran too).

	Jakub

Re: [power-ieee128] What should the math functions be annotated with?

[Thomas Koenig]

Hi Jakub,

> Note, we want to test both building gcc on ppc64le with older glibc
> and newer glibc (and that libgfortran will have the same ABI between both
> and one can move gcc including libgfortran and libquadmath from the older
> glibc setup to newer and make -mabi=ieeelongdouble work in Fortran too).

Using an older glibc is no problem - we can use gcc135 on the compile
farm for that.

As far as the other options you outlined, I think I'll defer to people
who know more about setting up libraries than I do. I have root access,
but chances are I would just mess up the virtual machine :-)

Regards

	Thomas

Re: [power-ieee128] What should the math functions be annotated with?

[Bill Schmidt]

Hi!

On 12/3/21 5:56 AM, Thomas Koenig wrote:
>
> Hi Jakub,
>
>> Note, we want to test both building gcc on ppc64le with older glibc
>> and newer glibc (and that libgfortran will have the same ABI between both
>> and one can move gcc including libgfortran and libquadmath from the older
>> glibc setup to newer and make -mabi=ieeelongdouble work in Fortran too).
>
> Using an older glibc is no problem - we can use gcc135 on the compile
> farm for that.
>
> As far as the other options you outlined, I think I'll defer to people
> who know more about setting up libraries than I do. I have root access,
> but chances are I would just mess up the virtual machine :-)

Easiest is probably to install the advance toolchain.  Mike said he'll work on

that later this morning.

Thanks!
Bill

>
> Regards
>
>     Thomas

Re: [power-ieee128] What should the math functions be annotated with?

[Michael Meissner]

On Fri, Dec 03, 2021 at 08:57:54AM -0600, Bill Schmidt wrote:
> Hi!
> 
> On 12/3/21 5:56 AM, Thomas Koenig wrote:
> >
> > Hi Jakub,
> >
> >> Note, we want to test both building gcc on ppc64le with older glibc
> >> and newer glibc (and that libgfortran will have the same ABI between both
> >> and one can move gcc including libgfortran and libquadmath from the older
> >> glibc setup to newer and make -mabi=ieeelongdouble work in Fortran too).
> >
> > Using an older glibc is no problem - we can use gcc135 on the compile
> > farm for that.
> >
> > As far as the other options you outlined, I think I'll defer to people
> > who know more about setting up libraries than I do. I have root access,
> > but chances are I would just mess up the virtual machine :-)
> 
> Easiest is probably to install the advance toolchain.  Mike said he'll work on
> 
> that later this morning.
> 
> Thanks!
> Bill

I have loaded Advance Toolchain 15.0 on the system.  It is located in
/opt/at15.0.  AT 15 provides a GCC 11.2 compiler and GLIBC 2.34.

I built a trunk compiler using the options:

        --enable-languages=c,c++,fortran \
        --disable-plugin \
        --enable-checking \
        --enable-stage1-checking \
        --enable-gnu-indirect-function \
        --disable-libgomp \
        --enable-decimal-float \
        --enable-secureplt \
        --enable-threads=posix \
        --enable-__cxa_atexit \
        --with-cpu=power8 \
        --with-long-double-128 \
        --with-as=/opt/at15.0/bin/as \
        --with-ld=/opt/at15.0/bin/ld \
        --with-gnu-as=/opt/at15.0/bin/as \
        --with-gnu-ld=/opt/at15.0/bin/ld \
        --with-advance-toolchain=at15.0 \
        --with-system-zlib \
        --with-native-system-header-dir=/opt/at15.0/include \
        --without-ppl \
        --without-cloog \
        --without-isl

I will rebuild the compiler using --with-cpu=power9 instead, since if power9 is
the default CPU, we avoid the use of using an emulator for IEEE 128-bit.

Note, if you are doing a bootstrap using the AT 15.0 libraries, you need a
'msgfmt' in your PATH to avoid problems that show up when the compiler is
rebuilding libstdc++.  I use this script:

#! /bin/bash

# Hack script to allow building GCC with the --with-advance-toolchain=<at>
# option and do a bootstrap.  What happens is at the end of the stage1 build,
# and in preparation for the stage2 build, the environment variable
# LD_LIBRARY_PATH is set to the new library directory.  Unfortunately this
# occurs while we are building libstdc++, and the libstdc++ that is pointed to
# is incomplete.  The msgfmt program then aborts because it doesn't have the
# right symbols.  This script allows us to not use those environment variables.

unset LD_LIBRARY_PATH
unset RPATH_ENVVAR

for x in /usr/local/bin /usr/bin /bin; do
    if [ -x "${x}/msgfmt" ]; then
	exec "${x}/msgfmt" $@
    fi
done

echo "Could not find msgfmt" >&2
exit 1


-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

Re: [power-ieee128] What should the math functions be annotated with?

[Thomas Koenig]

Hi,

> I have loaded Advance Toolchain 15.0 on the system.  It is located in
> /opt/at15.0.  AT 15 provides a GCC 11.2 compiler and GLIBC 2.34.

Thanks!

> I built a trunk compiler using the options:
> 
>          --enable-languages=c,c++,fortran \
>          --disable-plugin \
>          --enable-checking \
>          --enable-stage1-checking \
>          --enable-gnu-indirect-function \
>          --disable-libgomp \
>          --enable-decimal-float \
>          --enable-secureplt \
>          --enable-threads=posix \
>          --enable-__cxa_atexit \
>          --with-cpu=power8 \
>          --with-long-double-128 \
>          --with-as=/opt/at15.0/bin/as \
>          --with-ld=/opt/at15.0/bin/ld \
>          --with-gnu-as=/opt/at15.0/bin/as \
>          --with-gnu-ld=/opt/at15.0/bin/ld \
>          --with-advance-toolchain=at15.0 \
>          --with-system-zlib \
>          --with-native-system-header-dir=/opt/at15.0/include \
>          --without-ppl \
>          --without-cloog \
>          --without-isl

I will add --enable-maintainer-mode and change --with-cpu=power8 to
--with-cpu=power9, and see how things go.

One question: Your configure has --with-long-double-128. Will this also
allow use of the IBM long double functions with a compiler switch
(and which one)?

Regards

	Thomas

Re: [power-ieee128] What should the math functions be annotated with?

[Thomas Koenig]

On 04.12.21 07:39, Michael Meissner via Fortran wrote:
> I have loaded Advance Toolchain 15.0 on the system.  It is located in
> /opt/at15.0.  AT 15 provides a GCC 11.2 compiler and GLIBC 2.34.

I tried bootstrapping (from a separate account I set up on the
machine to make sure I don't mess up anybody else's stuff)
with the options

../gcc/configure \
         --prefix=$HOME \
         --enable-languages=c,c++,fortran \
         --disable-plugin \
         --enable-checking \
         --enable-stage1-checking \
         --enable-gnu-indirect-function \
         --enable-maintainer-mode \
         --disable-libgomp \
         --enable-decimal-float \
         --enable-secureplt \
         --enable-threads=posix \
         --enable-__cxa_atexit \
         --with-cpu=power9 \
         --with-long-double-128 \
         --with-as=/opt/at15.0/bin/as \
         --with-ld=/opt/at15.0/bin/ld \
         --with-gnu-as=/opt/at15.0/bin/as \
         --with-gnu-ld=/opt/at15.0/bin/ld \
         --with-advance-toolchain=at15.0 \
         --with-system-zlib \
         --with-native-system-header-dir=/opt/at15.0/include \
         --without-ppl \
         --without-cloog \
         --without-isl

but it failed with

../../gcc/gcc/lto-compress.c:34:10: fatal error: zlib.h: No such file or 
directory

Any idea how to fix this?

Regards

	Thomas

Re: [power-ieee128] What should the math functions be annotated with?

[Jakub Jelinek]

On Sat, Dec 04, 2021 at 11:16:28AM +0100, Thomas Koenig wrote:
> 
> On 04.12.21 07:39, Michael Meissner via Fortran wrote:
> > I have loaded Advance Toolchain 15.0 on the system.  It is located in
> > /opt/at15.0.  AT 15 provides a GCC 11.2 compiler and GLIBC 2.34.
> 
> I tried bootstrapping (from a separate account I set up on the
> machine to make sure I don't mess up anybody else's stuff)
> with the options
> 
> ../gcc/configure \
>         --prefix=$HOME \
>         --enable-languages=c,c++,fortran \
>         --disable-plugin \
>         --enable-checking \
>         --enable-stage1-checking \
>         --enable-gnu-indirect-function \
>         --enable-maintainer-mode \
>         --disable-libgomp \
>         --enable-decimal-float \
>         --enable-secureplt \
>         --enable-threads=posix \
>         --enable-__cxa_atexit \
>         --with-cpu=power9 \
>         --with-long-double-128 \
>         --with-as=/opt/at15.0/bin/as \
>         --with-ld=/opt/at15.0/bin/ld \
>         --with-gnu-as=/opt/at15.0/bin/as \
>         --with-gnu-ld=/opt/at15.0/bin/ld \
>         --with-advance-toolchain=at15.0 \
>         --with-system-zlib \
>         --with-native-system-header-dir=/opt/at15.0/include \
>         --without-ppl \
>         --without-cloog \
>         --without-isl
> 
> but it failed with
> 
> ../../gcc/gcc/lto-compress.c:34:10: fatal error: zlib.h: No such file or
> directory
> 
> Any idea how to fix this?

If zlib devel isn't installed, drop --with-system-zlib option
or use --without-system-zlib.

You've asked in another mail how to configure gcc to default to
-mabi=ieeelongdouble, that is
--with-long-double-format=ieee

	Jakub

Re: [power-ieee128] What should the math functions be annotated with?

[Thomas Koenig]

On 04.12.21 11:29, Jakub Jelinek wrote:
> If zlib devel isn't installed, drop --with-system-zlib option
> or use --without-system-zlib.
> 
> You've asked in another mail how to configure gcc to default to
> -mabi=ieeelongdouble, that is
> --with-long-double-format=ieee

Thanks for those hints.

I have now managed to bootstrap a compiler on that machine, but
success at running programs is somewhat limited:

tkoenig@gcc-fortran:~/Tst$ which gcc
/home/tkoenig/bin/gcc
tkoenig@gcc-fortran:~/Tst$ cat hello.c
#include <stdio.h>

int main()
{
   printf ("Hello, world!\n");
   return 0;
}
tkoenig@gcc-fortran:~/Tst$ gcc hello.c
tkoenig@gcc-fortran:~/Tst$ ldd ./a.out
./a.out: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not 
found (required by ./a.out)
         linux-vdso64.so.1 (0x00007a16a4510000)
         libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6 
(0x00007a16a42c0000)
         /opt/at15.0/lib64/ld64.so.2 => /lib64/ld64.so.2 
(0x00007a16a4530000)
tkoenig@gcc-fortran:~/Tst$ export LD_LIBRARY_PATH=~/lib64:/opt/at15.0/lib64/
tkoenig@gcc-fortran:~/Tst$ ls
Segmentation fault (core dumped)

@IBM folks: I would appreciate if you gave me access to a system
which actually worked, together with the necessary information,
so I can actually do what I volunteered to do.

Right now, I appear to be just wasting my time.

Regards

	Thomas

Re: [power-ieee128] What should the math functions be annotated with?

[Michael Meissner]

On Sat, Dec 04, 2021 at 02:42:13PM +0100, Thomas Koenig wrote:
> On 04.12.21 11:29, Jakub Jelinek wrote:
> > If zlib devel isn't installed, drop --with-system-zlib option
> > or use --without-system-zlib.
> > 
> > You've asked in another mail how to configure gcc to default to
> > -mabi=ieeelongdouble, that is
> > --with-long-double-format=ieee
> 
> Thanks for those hints.
> 
> I have now managed to bootstrap a compiler on that machine, but
> success at running programs is somewhat limited:
> 
> tkoenig@gcc-fortran:~/Tst$ which gcc
> /home/tkoenig/bin/gcc
> tkoenig@gcc-fortran:~/Tst$ cat hello.c
> #include <stdio.h>
> 
> int main()
> {
>   printf ("Hello, world!\n");
>   return 0;
> }
> tkoenig@gcc-fortran:~/Tst$ gcc hello.c
> tkoenig@gcc-fortran:~/Tst$ ldd ./a.out
> ./a.out: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not
> found (required by ./a.out)
>         linux-vdso64.so.1 (0x00007a16a4510000)
>         libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6
> (0x00007a16a42c0000)
>         /opt/at15.0/lib64/ld64.so.2 => /lib64/ld64.so.2 (0x00007a16a4530000)
> tkoenig@gcc-fortran:~/Tst$ export LD_LIBRARY_PATH=~/lib64:/opt/at15.0/lib64/
> tkoenig@gcc-fortran:~/Tst$ ls
> Segmentation fault (core dumped)
> 
> @IBM folks: I would appreciate if you gave me access to a system
> which actually worked, together with the necessary information,
> so I can actually do what I volunteered to do.
> 
> Right now, I appear to be just wasting my time.

The Advance Toolchain has its own GLIBC, and it sets a different path to load
up the libraries.  You should not need to set the LD_LIBRARY_PATH variable.

Note, the system ldd does not tend to accurately report the library
dependencies for AT libraries:

15:15:03 ~/tests
-gcc-fortran-> /home/meissner/fsf-install-ppc64le/trunk/bin/gcc -O2 hello.c

15:15:23 ~/tests
-gcc-fortran-> ldd a.out
./a.out: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./a.out)
        linux-vdso64.so.1 (0x0000796b63da0000)
        libm.so.6 => /lib/powerpc64le-linux-gnu/libm.so.6 (0x0000796b63c50000)
        libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6 (0x0000796b63a10000)
        /opt/at15.0/lib64/ld64.so.2 => /lib64/ld64.so.2 (0x0000796b63dc0000)

15:15:27 ~/tests
-gcc-fortran-> /opt/at15.0/bin/ldd a.out
        linux-vdso64.so.1 (0x000070dea0140000)
        libm.so.6 => /opt/at15.0/lib64/power9/libm.so.6 (0x000070dea0020000)
        libc.so.6 => /opt/at15.0/lib64/power9/libc.so.6 (0x000070de9fdb0000)
        /opt/at15.0/lib64/ld64.so.2 (0x000070dea0160000)


This is done by the GCC driver setting a different dynamic linker path
internally:

	-dynamic-linker /opt/at15.0/lib64/ld64.so.2

Tulio can probably expand on what is going on in more detail.  The reason for
using the Advance Toolchain is to get access to newer libraries.  I don't know
Ubuntu at all, but I believe the version that is installed is too old to have
the necessary changes in it.  There isn't a LTS (long time support) version of
Ubuntu yet available that has the library.  There are newer versions that
aren't LTS (i.e. every 6 months you have to jump to the next release), and
Peter, Bill and I have talked about upgrading the partition to use those.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com

Re: [power-ieee128] What should the math functions be annotated with?

[Peter Bergner]

On 12/4/21 9:25 AM, Michael Meissner wrote:
> On Sat, Dec 04, 2021 at 02:42:13PM +0100, Thomas Koenig wrote:
> Note, the system ldd does not tend to accurately report the library
> dependencies for AT libraries:

And using AT15's ldd, it shows your a.out is linked to the correct libc:

ubuntu@gcc-fortran:/home/tkoenig/Tst$ ldd ./a.out 
./a.out: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./a.out)
	linux-vdso64.so.1 (0x00007f6339620000)
	libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6 (0x00007f63393d0000)
	/opt/at15.0/lib64/ld64.so.2 => /lib64/ld64.so.2 (0x00007f6339640000)
ubuntu@gcc-fortran:/home/tkoenig/Tst$ /opt/at15.0/bin/ldd ./a.out 
	linux-vdso64.so.1 (0x00007158fb1c0000)
	libc.so.6 => /opt/at15.0/lib64/power9/libc.so.6 (0x00007158faf40000)
	/opt/at15.0/lib64/ld64.so.2 (0x00007158fb1e0000)


What I would do is place /opt/at15.0/bin as the 2nd directory in your PATH,
with your new GCC install dir being first.  That way, things should be
seemless for you.

Peter

Re: [power-ieee128] What should the math functions be annotated with?

[Peter Bergner]

On 12/4/21 9:37 AM, Peter Bergner wrote:
> On 12/4/21 9:25 AM, Michael Meissner wrote:
> ubuntu@gcc-fortran:/home/tkoenig/Tst$ ldd ./a.out 
> ./a.out: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./a.out)
> 	linux-vdso64.so.1 (0x00007f6339620000)
> 	libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6 (0x00007f63393d0000)
> 	/opt/at15.0/lib64/ld64.so.2 => /lib64/ld64.so.2 (0x00007f6339640000)

To go into a little more in depth, the important thing is your a.out
was linked with the correct loader:

ubuntu@gcc-fortran:/home/tkoenig/Tst$ readelf -l a.out | grep interpreter
      [Requesting program interpreter: /opt/at15.0/lib64/ld64.so.2]


...and the error message you saw was a good thing, it showed your a.out was
expecting to see the newer GLIBC 2.34 and didn't.  The reason it didn't
was that the system ldd which you used does some magic and overrides the
a.out runtime loader with the system loader and that loader uses its
own ld.so.cache which doesn't include AT15's library paths.  The AT15
loader has its own /opt/at15.0/etc/ld.so.cache which includes its lib dirs
as well the system lib dirs.  This way, the AT15 libs are found first and
any library AT15 doesn't provide it automatically picked up from the system.
As long as you keep the AT15 bin path before the system bin dirs, you should
be fine.

Peter

Re: [power-ieee128] What should the math functions be annotated with?

[Jakub Jelinek]

On Sat, Dec 04, 2021 at 10:12:37AM -0600, Peter Bergner via Gcc wrote:
> On 12/4/21 9:37 AM, Peter Bergner wrote:
> > On 12/4/21 9:25 AM, Michael Meissner wrote:
> > ubuntu@gcc-fortran:/home/tkoenig/Tst$ ldd ./a.out 
> > ./a.out: /lib/powerpc64le-linux-gnu/libc.so.6: version `GLIBC_2.34' not found (required by ./a.out)
> > 	linux-vdso64.so.1 (0x00007f6339620000)
> > 	libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6 (0x00007f63393d0000)
> > 	/opt/at15.0/lib64/ld64.so.2 => /lib64/ld64.so.2 (0x00007f6339640000)
> 
> To go into a little more in depth, the important thing is your a.out
> was linked with the correct loader:
> 
> ubuntu@gcc-fortran:/home/tkoenig/Tst$ readelf -l a.out | grep interpreter
>       [Requesting program interpreter: /opt/at15.0/lib64/ld64.so.2]
> 
> 
> ...and the error message you saw was a good thing, it showed your a.out was
> expecting to see the newer GLIBC 2.34 and didn't.  The reason it didn't
> was that the system ldd which you used does some magic and overrides the
> a.out runtime loader with the system loader and that loader uses its
> own ld.so.cache which doesn't include AT15's library paths.  The AT15
> loader has its own /opt/at15.0/etc/ld.so.cache which includes its lib dirs
> as well the system lib dirs.  This way, the AT15 libs are found first and
> any library AT15 doesn't provide it automatically picked up from the system.
> As long as you keep the AT15 bin path before the system bin dirs, you should
> be fine.

But when Thomas is working on the vanilla gcc tree, trying to make it work
for Fortran, I think he'll need to patch that gcc tree too to use the
AT15's dynamic linker and rpath like the AT15 gcc is.

	Jakub

Re: [power-ieee128] What should the math functions be annotated with?

[Peter Bergner]

On 12/4/21 10:19 AM, Jakub Jelinek wrote:
> But when Thomas is working on the vanilla gcc tree, trying to make it work
> for Fortran, I think he'll need to patch that gcc tree too to use the
> AT15's dynamic linker and rpath like the AT15 gcc is.

That is part of the magic that happens when you configure with
--with-advance-toolchain=at15.0, it forces the gcc to use AT15's
dynamic linker and AT15's ld.so.cache makes it so that the
dynamic linker finds AT15's libs etc.

Peter

Re: [power-ieee128] What should the math functions be annotated with?

[Thomas Koenig]

On 04.12.21 17:12, Peter Bergner via Fortran wrote:
> As long as you keep the AT15 bin path before the system bin dirs, you should
> be fine.

OK, what I have now is

tkoenig@gcc-fortran:~$ echo $PATH
/home/tkoenig/bin:/opt/at15.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
tkoenig@gcc-fortran:~$ echo $LD_LIBRARY_PATH
/home/tkoenig/lib64

I generally use LD_LIBRARY_PATH to point to where the shared
libgfortran and other libraries is installed.

However, this breaks man (and I don't know what else):

man: command exited with status 1: (cd /usr/share/man && 
/usr/lib/man-db/zsoelim) | (cd /usr/share/man && /usr/lib/man-db/manconv 
-f UTF-8:ISO-8859-1 -t UTF-8//IGNORE) | (cd /usr/share/man && preconv -e 
UTF-8) | (cd /usr/share/man && tbl) | (cd /usr/share/man && nroff 
-mandoc -rLL=231n -rLT=231n -Tutf8)

Any ideas there?

Regards

	Thomas

Re: [power-ieee128] What should the math functions be annotated with?

[Peter Bergner]

On 12/4/21 11:40 AM, Thomas Koenig wrote:
> OK, what I have now is
> 
> tkoenig@gcc-fortran:~$ echo $PATH
> /home/tkoenig/bin:/opt/at15.0/bin:/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/sbin:/bin:/usr/games:/usr/local/games:/snap/bin
> tkoenig@gcc-fortran:~$ echo $LD_LIBRARY_PATH
> /home/tkoenig/lib64
> 
> I generally use LD_LIBRARY_PATH to point to where the shared
> libgfortran and other libraries is installed.
> 
> However, this breaks man (and I don't know what else):

So LD_LIBRARY_PATH is searched before the directories in ld.so.cache,
so you end up picking up some "new" libs from /home/tkoenig/lib64
and some of these rely on the newer libs in AT15.  However, man and
some of the other system binaries use the system dynamic linker, so
they search first through LD_LIBRARY_PATH an dnot finding something,
they fall back to /etc/ld.so.cache and that doesn't have the newer
AT15 libs, so you hit errors.

Instead of setting LD_LIBRARY_PATH=/home/tkoenig/lib64 could you try
setting it to LD_LIBRARY_PATH='$ORIGIN/lib64' instead?  This would
allow the other system binaries to not find your /home/tkoenig/lib64
directory so they'd behave normally.  However, any binary that was
compiled in a directory where your lib64/ exists would find your
new libs and use them.  I'm not sure if that cramps your testing
or not, to limit yourself to compiling your tests in that one directory.

If that doesn't work, could you instead not set LD_LIBRARY_PATH and
instead compile using -L/home/bergner/lib64 -R/home/bergner/lib64 ?

Peter

Re: [power-ieee128] What should the math functions be annotated with?

[Thomas Koenig]

On 05.12.21 01:35, Peter Bergner wrote:
> Instead of setting LD_LIBRARY_PATH=/home/tkoenig/lib64 could you try
> setting it to LD_LIBRARY_PATH='$ORIGIN/lib64' instead?  This would
> allow the other system binaries to not find your /home/tkoenig/lib64
> directory so they'd behave normally.  However, any binary that was
> compiled in a directory where your lib64/ exists would find your
> new libs and use them.  I'm not sure if that cramps your testing
> or not, to limit yourself to compiling your tests in that one directory.
> 
> If that doesn't work, could you instead not set LD_LIBRARY_PATH and
> instead compile using -L/home/bergner/lib64 -R/home/bergner/lib64 ?

I think I shall forsake the dubious joys of dynamic linking and use
-static-libgfortran instead.

Regards

	Thomas

Re: [power-ieee128] What should the math functions be annotated with?

[Michael Meissner]

On Sun, Dec 05, 2021 at 12:16:38PM +0100, Thomas Koenig wrote:
> 
> On 05.12.21 01:35, Peter Bergner wrote:
> > Instead of setting LD_LIBRARY_PATH=/home/tkoenig/lib64 could you try
> > setting it to LD_LIBRARY_PATH='$ORIGIN/lib64' instead?  This would
> > allow the other system binaries to not find your /home/tkoenig/lib64
> > directory so they'd behave normally.  However, any binary that was
> > compiled in a directory where your lib64/ exists would find your
> > new libs and use them.  I'm not sure if that cramps your testing
> > or not, to limit yourself to compiling your tests in that one directory.
> > 
> > If that doesn't work, could you instead not set LD_LIBRARY_PATH and
> > instead compile using -L/home/bergner/lib64 -R/home/bergner/lib64 ?
> 
> I think I shall forsake the dubious joys of dynamic linking and use
> -static-libgfortran instead.

Yes, I tend to use -static-libgfortran for running Fortran spec things, and
-static-libstdc++ for C++, since it can be a quaqmire getting the right library
when you have several libraries on the system.

-- 
Michael Meissner, IBM
PO Box 98, Ayer, Massachusetts, USA, 01432
email: meissner@linux.ibm.com