Re: [power-ieee128] What should the math functions be annotated with?
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?
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?
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?
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?
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
Comment on web page https://gcc.gnu.org/projects/cxx-status.html#cxx11
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.
Best Regards,
Jürgen Sauermann
Re: Comment on web page https://gcc.gnu.org/projects/cxx-status.html#cxx11
On Fri, 3 Dec 2021, 18:58 Dr. Jürgen Sauermann,
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
gcc-10-20211203 is now available
Snapshot gcc-10-20211203 is now available on https://gcc.gnu.org/pub/gcc/snapshots/10-20211203/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 10 git branch with the following options: git://gcc.gnu.org/git/gcc.git branch releases/gcc-10 revision 1a11b7c860f9305cdcf0d1ad9d8a7f3b512d546e You'll find: gcc-10-20211203.tar.xz Complete GCC SHA256=5be67eef2052e532485de04083429785fe932e476f5ed3c30886c14cc8da8e93 SHA1=68978343858bbdcf5f508b0004d0f0f466bcf78d Diffs from 10-20211126 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-10 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: odd internal failure
David,
Thanks, I've bookmarked your advice. I do use gdb but I've always
found the macros in common use are the biggest hurdle. In addition
C++ has its own associated difficulties.
Note, in the past working on other compilers I've always tried to have
a function version of the macros available.
#if USE_FUNCTIONS
foo_t
MUMBLE( grumble_t *g)
{
return FU( BAR(g));
}
#else
MUMBLE(g) FU(BAR(g))
#endif
There are many advantages to this. Some are, better type checking,
being able to step into them and invoke them in gdb "p MUMBLE(x)".
Thanks again,
Gary
From: David Malcolm
Sent: Thursday, December 2, 2021 6:04 AM
To: Richard Biener ; Gary Oblock
Cc: gcc@gcc.gnu.org
Subject: Re: odd internal failure
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
On Thu, 2021-12-02 at 12:40 +0100, Richard Biener via Gcc wrote:
> On Wed, Dec 1, 2021 at 9:56 PM Gary Oblock
> wrote:
> >
> > Richard,
> >
> > I rebuilt at "-O0" and that particular call now works but on a call
> > to
> > the same function with a different offset it fails. 😱
>
> use a debugger to see why
In case you haven't seen them, I put together some tips on debugging
GCC here:
https://dmalcolm.fedorapeople.org/gcc/newbies-guide/debugging.html
https://github.com/davidmalcolm/gcc-newbies-guide/blob/master/debugging.rst
Inserting print statements only gets you so far; at some point you
really need a debugger.
Dave
>
> > Thanks,
> >
> > Gary
> >
> >
> >
> > From: Richard Biener
> > Sent: Wednesday, December 1, 2021 1:09 AM
> > To: Gary Oblock
> > Cc: gcc@gcc.gnu.org
> > Subject: Re: odd internal failure
> >
> > [EXTERNAL EMAIL NOTICE: This email originated from an external
> > sender. Please be mindful of safe email handling and proprietary
> > information protection practices.]
> >
> >
> > On Wed, Dec 1, 2021 at 8:46 AM Gary Oblock via Gcc
> > wrote:
> > >
> > > What is happening should be trivial to determine but for some
> > > reason it's
> > > not. I'd normally bounce this off a coworker but given the pandemic
> > > and modern dispersed hiring practices it's not even remotely
> > > possible.
> > >
> > > I'm making this call and tree_to_uhwi is failing on an internal
> > > error.
> > > That's normally easy to fix, but here is where the weirdness kicks
> > > in.
> > >
> > > unsigned HOST_WIDE_INT wi_offset = tree_to_uhwi (offset);
> > >
> > > tree_to_uhwi from tree.h is:
> > >
> > > extern inline __attribute__ ((__gnu_inline__)) unsigned
> > > HOST_WIDE_INT
> > > tree_to_uhwi (const_tree t)
> > > {
> > > gcc_assert (tree_fits_uhwi_p (t));
> > > return TREE_INT_CST_LOW (t);
> > > }
> > >
> > > and
> > >
> > > tree_fits_uhwi_p from tree.c is
> > >
> > > bool
> > > tree_fits_uhwi_p (const_tree t)
> > > {
> > > return (t != NULL_TREE
> > > && TREE_CODE (t) == INTEGER_CST
> > > && wi::fits_uhwi_p (wi::to_widest (t)));
> > > }
> > >
> > > Here's what this instrumentation shows (DEBUG_A is an indenting
> > > fprintf to
> > > stderr.)
> > >
> > > DEBUG_A ("TREE_CODE(offset) = %s && ", code_str (TREE_CODE
> > > (offset)));
> > > DEBUG_A ("fits %s\n", wi::fits_uhwi_p (wi::to_widest (offset)) ?
> > > "true" : "false");
> > > DEBUG_A ("tree_fits_uhwi_p(offset) %s\n",tree_fits_uhwi_p
> > > (offset) ? "true" : "false");
> > >
> > >TREE_CODE(offset) = INTEGER_CST && fits true
> > >tree_fits_uhwi_p(offset) true
> > >
> > > By the way, offset is:
> > >
> > > _Literal (struct BASKET * *) 8
> > >
> > > And it's an operand of:
> > >
> > > MEM[(struct BASKET * *)&perm + 8B]
> > >
> > > Any clues on what's going on here?
> >
> > it should just work.
> >
> > > Thanks,
> > >
> > > Gary
> > >
> >
> > Btw, try to setup things so you don't spam below stuff to public
> > mailing lists.
> >
> > > CONFIDENTIALITY NOTICE: This e-mail message, including any
> > > attachments, is for the sole use of the intended recipient(s) and
> > > contains information that is confidential and proprietary to Ampere
> > > Computing or its subsidiaries. It is to be used solely for the
> > > purpose of furthering the parties' business relationship. Any
> > > unauthorized review, copying, or distribution of this email (or any
> > > attachments thereto) is strictly prohibited. If you are not the
> > > intended recipient, please contact the sender immediately and
> > > permanently delete the original and any copies of this email and
> > > any attachments thereto.
>
Re: odd internal failure
On 12/4/21 00:54, Gary Oblock via Gcc wrote:
David,
Thanks, I've bookmarked your advice. I do use gdb but I've always
found the macros in common use are the biggest hurdle. In addition
C++ has its own associated difficulties.
Note, in the past working on other compilers I've always tried to have
a function version of the macros available.
#if USE_FUNCTIONS
foo_t
MUMBLE( grumble_t *g)
{
return FU( BAR(g));
}
#else
MUMBLE(g) FU(BAR(g))
#endif
There are many advantages to this. Some are, better type checking,
being able to step into them and invoke them in gdb "p MUMBLE(x)".
Thanks again,
Gary
Shouldn't it be possible to use `-ggdb3` when compiling GCC to get debug
information that includes macros ? It seems like that'd avoid having to
manually define a bunch of equivalent functions for the sole purpose of
being able to step through them.
From: David Malcolm
Sent: Thursday, December 2, 2021 6:04 AM
To: Richard Biener ; Gary Oblock
Cc: gcc@gcc.gnu.org
Subject: Re: odd internal failure
[EXTERNAL EMAIL NOTICE: This email originated from an external sender. Please
be mindful of safe email handling and proprietary information protection
practices.]
On Thu, 2021-12-02 at 12:40 +0100, Richard Biener via Gcc wrote:
On Wed, Dec 1, 2021 at 9:56 PM Gary Oblock
wrote:
Richard,
I rebuilt at "-O0" and that particular call now works but on a call
to
the same function with a different offset it fails. 😱
use a debugger to see why
In case you haven't seen them, I put together some tips on debugging
GCC here:
https://dmalcolm.fedorapeople.org/gcc/newbies-guide/debugging.html
https://github.com/davidmalcolm/gcc-newbies-guide/blob/master/debugging.rst
Inserting print statements only gets you so far; at some point you
really need a debugger.
Dave
Thanks,
Gary
From: Richard Biener
Sent: Wednesday, December 1, 2021 1:09 AM
To: Gary Oblock
Cc: gcc@gcc.gnu.org
Subject: Re: odd internal failure
[EXTERNAL EMAIL NOTICE: This email originated from an external
sender. Please be mindful of safe email handling and proprietary
information protection practices.]
On Wed, Dec 1, 2021 at 8:46 AM Gary Oblock via Gcc
wrote:
What is happening should be trivial to determine but for some
reason it's
not. I'd normally bounce this off a coworker but given the pandemic
and modern dispersed hiring practices it's not even remotely
possible.
I'm making this call and tree_to_uhwi is failing on an internal
error.
That's normally easy to fix, but here is where the weirdness kicks
in.
unsigned HOST_WIDE_INT wi_offset = tree_to_uhwi (offset);
tree_to_uhwi from tree.h is:
extern inline __attribute__ ((__gnu_inline__)) unsigned
HOST_WIDE_INT
tree_to_uhwi (const_tree t)
{
gcc_assert (tree_fits_uhwi_p (t));
return TREE_INT_CST_LOW (t);
}
and
tree_fits_uhwi_p from tree.c is
bool
tree_fits_uhwi_p (const_tree t)
{
return (t != NULL_TREE
&& TREE_CODE (t) == INTEGER_CST
&& wi::fits_uhwi_p (wi::to_widest (t)));
}
Here's what this instrumentation shows (DEBUG_A is an indenting
fprintf to
stderr.)
DEBUG_A ("TREE_CODE(offset) = %s && ", code_str (TREE_CODE
(offset)));
DEBUG_A ("fits %s\n", wi::fits_uhwi_p (wi::to_widest (offset)) ?
"true" : "false");
DEBUG_A ("tree_fits_uhwi_p(offset) %s\n",tree_fits_uhwi_p
(offset) ? "true" : "false");
TREE_CODE(offset) = INTEGER_CST && fits true
tree_fits_uhwi_p(offset) true
By the way, offset is:
_Literal (struct BASKET * *) 8
And it's an operand of:
MEM[(struct BASKET * *)&perm + 8B]
Any clues on what's going on here?
it should just work.
Thanks,
Gary
Btw, try to setup things so you don't spam below stuff to public
mailing lists.
CONFIDENTIALITY NOTICE: This e-mail message, including any
attachments, is for the sole use of the intended recipient(s) and
contains information that is confidential and proprietary to Ampere
Computing or its subsidiaries. It is to be used solely for the
purpose of furthering the parties' business relationship. Any
unauthorized review, copying, or distribution of this email (or any
attachments thereto) is strictly prohibited. If you are not the
intended recipient, please contact the sender immediately and
permanently delete the original and any copies of this email and
any attachments thereto.
List-Unsubscribe
List-Unsubscribe
Re: [power-ieee128] What should the math functions be annotated with?
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=
# 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: meiss...@linux.ibm.com
