Re: [power-ieee128] What should the math functions be annotated with?
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
How to get started with contribution
Respected Sir/Madam, I am Om Kenge, a Second Year IT Student, I have just entered my second year at MMCOE Pune. I am new to open source contributions but I am well aware of C++. I would love to contribute to your Organisation Hoping to hear from you soon. Regards Om
Re: [power-ieee128] What should the math functions be annotated with?
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?
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: Comment on web page https://gcc.gnu.org/projects/cxx-status.html#cxx11
On 12/3/21 9:12 PM, Jonathan Wakely wrote:
On Fri, 3 Dec 2021, 18:58 Dr. Jürgen Sauermann,
mailto:m...@juergen-sauermann.de>> wrote:
Hi,
not sure if this matters or how int can be fixed, but today I
observed
the following:
Your web page says that "Static assertions" are supported by GCC
since
version 4.3.
Today I tried to use "Static assertions" on an avr-g++ resp. avr-gcc
which identifies
itself as:
eedjsa@server68:~/projects/AVR_workspace/ATMEGA8U2_32U2$ avr-g++
--version
avr-g++ (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
eedjsa@server68:~/projects/AVR_workspace/ATMEGA8U2_32U2$ avr-gcc
--version
avr-gcc (GCC) 5.4.0
Copyright (C) 2015 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
but it seems not to support static assertions.
The "regular" g++ works:
eedjsa@server68:~/projects/AVR_workspace/ATMEGA8U2_32U2$ echo '
static_assert(0, "error"); int main() {}' | g++ -S -o /dev/null -x
c++ -
:2:15: error: static assertion failed: error
while the avr-g++ fails:
eedjsa@server68:~/projects/AVR_workspace/ATMEGA8U2_32U2$ echo '
static_assert(0, "error"); int main() {}' | avr-g++ -S -o
/dev/null -x c++ -
:2:14: error: expected constructor, destructor, or type
conversion before ‘(’ token
Maybe this should be mentioned on the web page.
Static assertions are a C++11 feature, so you simply need to use
-std=c++11 or -std=gnu++11
Hi Jonathan,
thanks a lot. This works indeed, even with avr-gcc/g++.
Re: How to get started with contribution
On Sat, 4 Dec 2021, 10:03 Om Kenge, wrote: > Respected Sir/Madam, > > I am Om Kenge, a Second Year IT Student, I have just entered my second year > at MMCOE Pune. I am new to open source contributions but I am well aware of > C++. I would love to contribute to your Organisation > > Hoping to hear from you soon. > I already replied to you on November 23rd. https://gcc.gnu.org/pipermail/gcc/2021-November/237795.html If you're serious about contributing, start by reading the responses of people who are trying to help you!
Re: [power-ieee128] What should the math functions be annotated with?
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
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 (0x7a16a451)
libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6
(0x7a16a42c)
/opt/at15.0/lib64/ld64.so.2 => /lib64/ld64.so.2
(0x7a16a453)
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?
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
>
> 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 (0x7a16a451)
> libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6
> (0x7a16a42c)
> /opt/at15.0/lib64/ld64.so.2 => /lib64/ld64.so.2 (0x7a16a453)
> 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 (0x796b63da)
libm.so.6 => /lib/powerpc64le-linux-gnu/libm.so.6 (0x796b63c5)
libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6 (0x796b63a1)
/opt/at15.0/lib64/ld64.so.2 => /lib64/ld64.so.2 (0x796b63dc)
15:15:27 ~/tests
-gcc-fortran-> /opt/at15.0/bin/ldd a.out
linux-vdso64.so.1 (0x70dea014)
libm.so.6 => /opt/at15.0/lib64/power9/libm.so.6 (0x70dea002)
libc.so.6 => /opt/at15.0/lib64/power9/libc.so.6 (0x70de9fdb)
/opt/at15.0/lib64/ld64.so.2 (0x70dea016)
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: meiss...@linux.ibm.com
Re: [power-ieee128] What should the math functions be annotated with?
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 (0x7f633962) libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6 (0x7f63393d) /opt/at15.0/lib64/ld64.so.2 => /lib64/ld64.so.2 (0x7f633964) ubuntu@gcc-fortran:/home/tkoenig/Tst$ /opt/at15.0/bin/ldd ./a.out linux-vdso64.so.1 (0x7158fb1c) libc.so.6 => /opt/at15.0/lib64/power9/libc.so.6 (0x7158faf4) /opt/at15.0/lib64/ld64.so.2 (0x7158fb1e) 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?
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 (0x7f633962) > libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6 (0x7f63393d) > /opt/at15.0/lib64/ld64.so.2 => /lib64/ld64.so.2 (0x7f633964) 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?
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 (0x7f633962) > > libc.so.6 => /lib/powerpc64le-linux-gnu/libc.so.6 (0x7f63393d) > > /opt/at15.0/lib64/ld64.so.2 => /lib64/ld64.so.2 (0x7f633964) > > 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?
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?
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
gcc-11-20211204 is now available
Snapshot gcc-11-20211204 is now available on https://gcc.gnu.org/pub/gcc/snapshots/11-20211204/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 11 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-11 revision 217d8bf22b148ebe52456a4bccfe9d725e7c68e9 You'll find: gcc-11-20211204.tar.xz Complete GCC SHA256=3a673d21417a4a37c0c58bddfc7d3e6e6781defb35eb49f96184ed391dc5c7d1 SHA1=05a70dcc592327c30e7c9c44c8b488cc31239b8d Diffs from 11-20211127 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-11 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
Re: [power-ieee128] What should the math functions be annotated with?
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
