* [Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
@ 2020-10-31 8:58 ` redi at gcc dot gnu.org
2020-10-31 9:00 ` redi at gcc dot gnu.org
` (19 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: redi at gcc dot gnu.org @ 2020-10-31 8:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #1 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Created attachment 49479
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49479&action=edit
Assembly code
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
2020-10-31 8:58 ` [Bug target/97653] " redi at gcc dot gnu.org
@ 2020-10-31 9:00 ` redi at gcc dot gnu.org
2020-10-31 9:12 ` redi at gcc dot gnu.org
` (18 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: redi at gcc dot gnu.org @ 2020-10-31 9:00 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Without -mabilongdouble the result is correct.
If configured with --with-long-double-format=ibm the result is correct with any
-mabi option.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
2020-10-31 8:58 ` [Bug target/97653] " redi at gcc dot gnu.org
2020-10-31 9:00 ` redi at gcc dot gnu.org
@ 2020-10-31 9:12 ` redi at gcc dot gnu.org
2020-11-03 19:51 ` meissner at gcc dot gnu.org
` (17 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: redi at gcc dot gnu.org @ 2020-10-31 9:12 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #3 from Jonathan Wakely <redi at gcc dot gnu.org> ---
int printf(const char*, ...);
const unsigned long k = 256;
int main()
{
long double r[] = { 0.1L, 0.2L, 0.5L, 0.9L };
for (int i = 0; i < 4; ++i)
{
unsigned long j = k * r[i];
printf("%lu * %Lf = %lu\n", k, r[i], j);
}
}
$ ~/gcc/ieee128/bin/gcc k.c -mno-gnu-attribute -mabi=ibmlongdouble -Wall &&
./a.out
256 * 0.100000 = 256
256 * 0.200000 = 256
256 * 0.500000 = 256
256 * 0.900000 = 256
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
` (2 preceding siblings ...)
2020-10-31 9:12 ` redi at gcc dot gnu.org
@ 2020-11-03 19:51 ` meissner at gcc dot gnu.org
2020-11-03 19:58 ` meissner at gcc dot gnu.org
` (16 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: meissner at gcc dot gnu.org @ 2020-11-03 19:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
Michael Meissner <meissner at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2020-11-03
Status|UNCONFIRMED |ASSIGNED
Assignee|unassigned at gcc dot gnu.org |meissner at gcc dot gnu.org
Ever confirmed|0 |1
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
` (3 preceding siblings ...)
2020-11-03 19:51 ` meissner at gcc dot gnu.org
@ 2020-11-03 19:58 ` meissner at gcc dot gnu.org
2020-11-04 12:02 ` redi at gcc dot gnu.org
` (15 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: meissner at gcc dot gnu.org @ 2020-11-03 19:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #4 from Michael Meissner <meissner at gcc dot gnu.org> ---
You need the patch that fixes PR libgcc/97543, which is another side of the
same coin. PR 97543 was about making long double default to 64-bits, PR 97643
is about making long double default to IEEE 128-bit.
For both PRs, you need to make sure the modules that deal with IBM 128-bit
values using -mabi=ibmlongdouble. And also as a good measure, disable GNU
attributes to prevent linker warnings.
Here is the patch that should be applied:
https://gcc.gnu.org/pipermail/gcc-patches/2020-October/557413.html
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
` (4 preceding siblings ...)
2020-11-03 19:58 ` meissner at gcc dot gnu.org
@ 2020-11-04 12:02 ` redi at gcc dot gnu.org
2020-12-08 14:09 ` redi at gcc dot gnu.org
` (14 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: redi at gcc dot gnu.org @ 2020-11-04 12:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #5 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yep, that fixes the testcases above, thanks. Retrying the libstdc++ tests ...
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
` (5 preceding siblings ...)
2020-11-04 12:02 ` redi at gcc dot gnu.org
@ 2020-12-08 14:09 ` redi at gcc dot gnu.org
2021-01-21 1:41 ` meissner at gcc dot gnu.org
` (13 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: redi at gcc dot gnu.org @ 2020-12-08 14:09 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This was committed, but with the wrong PR number so didn't get added here:
The master branch has been updated by Michael Meissner <meissner@gcc.gnu.org>:
https://gcc.gnu.org/g:9f1a6501994a2d18ec4fe2a6664637f48021b210
commit r11-5728-g9f1a6501994a2d18ec4fe2a6664637f48021b210
Author: Michael Meissner <meissner@linux.ibm.com>
Date: Thu Dec 3 14:50:26 2020 -0500
PowerPC: PR libgcc/97543 and libgcc/97643, fix long double issues
If you use a compiler with long double defaulting to 64-bit instead of
128-bit
with IBM extended double, you get linker warnings about mis-matches in the
gnu
attributes for long double (PR libgcc/97543). Even if the compiler is
configured to have long double be 64 bit as the default with the
configuration
option '--without-long-double-128' you get the warnings.
You also get the same issues if you use a compiler with long double
defaulting
to IEEE 128-bit instead of IBM extended double (PR libgcc/97643).
The issue is the way libgcc.a/libgcc.so is built. Right now when building
libgcc under Linux, the long double size is set to 128-bits when building
libgcc. However, the gnu attributes are set, leading to the warnings.
One feature of the current GNU attribute implementation is if you have a
shared
library (such as libgcc_s.so), the GNU attributes for the shared library is
an
inclusive OR of all of the objects within the library. This means if any
object file that uses the -mlong-double-128 option and uses long double,
the GNU
attributes for the library will indicate that it uses 128-bit IBM long
doubles. If you have a static library, you will get the warning only if
you
actually reference an object file with the attribute set.
This patch does two things:
1) All of the object files that support IBM 128-bit long doubles
explicitly set the ABI to IBM extended double.
2) I turned off GNU attributes for building the shared library or for
building the IBM 128-bit long double support.
libgcc/
2020-12-03 Michael Meissner <meissner@linux.ibm.com>
PR libgcc/97543
PR libgcc/97643
* config/rs6000/t-linux (IBM128_STATIC_OBJS): New make variable.
(IBM128_SHARED_OBJS): New make variable.
(IBM128_OBJS): New make variable. Set all objects to use the
explicit IBM format, and disable gnu attributes.
(IBM128_CFLAGS): New make variable.
(gcc_s_compile): Add -mno-gnu-attribute to all shared library
modules.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
` (6 preceding siblings ...)
2020-12-08 14:09 ` redi at gcc dot gnu.org
@ 2021-01-21 1:41 ` meissner at gcc dot gnu.org
2021-01-21 1:44 ` meissner at gcc dot gnu.org
` (12 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: meissner at gcc dot gnu.org @ 2021-01-21 1:41 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
Bug 97653 depends on bug 97543, which changed state.
Bug 97543 Summary: powerpc64le: libgcc has unexpected long double in .gnu_attribute
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97543
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution|--- |FIXED
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
` (7 preceding siblings ...)
2021-01-21 1:41 ` meissner at gcc dot gnu.org
@ 2021-01-21 1:44 ` meissner at gcc dot gnu.org
2021-03-23 18:07 ` redi at gcc dot gnu.org
` (11 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: meissner at gcc dot gnu.org @ 2021-01-21 1:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
Michael Meissner <meissner at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|ASSIGNED |RESOLVED
--- Comment #7 from Michael Meissner <meissner at gcc dot gnu.org> ---
Bug fixed with the December 3rd, 2020 check-in to the master branch. We do not
expect GCC 10 to build with IEEE 128-bit long double default, so we don't need
a backport at this time.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
` (8 preceding siblings ...)
2021-01-21 1:44 ` meissner at gcc dot gnu.org
@ 2021-03-23 18:07 ` redi at gcc dot gnu.org
2021-03-23 18:08 ` redi at gcc dot gnu.org
` (10 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: redi at gcc dot gnu.org @ 2021-03-23 18:07 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|RESOLVED |REOPENED
Resolution|FIXED |---
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Reopening as I'm still seeing this (or it's returned).
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
` (9 preceding siblings ...)
2021-03-23 18:07 ` redi at gcc dot gnu.org
@ 2021-03-23 18:08 ` redi at gcc dot gnu.org
2021-03-30 11:28 ` jakub at gcc dot gnu.org
` (9 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: redi at gcc dot gnu.org @ 2021-03-23 18:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #9 from Jonathan Wakely <redi at gcc dot gnu.org> ---
[test@ibm-p8-cluster-02 ~]$ cat 97653.c
int printf(const char*, ...);
const unsigned long k = 256;
int main()
{
long double r[] = { 0.1L, 0.2L, 0.5L, 0.9L };
for (int i = 0; i < 4; ++i)
{
unsigned long j = k * r[i];
printf("%lu * %Lf = %lu\n", k, r[i], j);
}
}
[test@ibm-p8-cluster-02 ~]$ ~/gcc/ieee/bin/gcc 97653.c -mno-gnu-attribute
-mabi=ibmlongdouble -Wall -static-libgcc -v && ./a.out
Using built-in specs.
COLLECT_GCC=/home/test/gcc/ieee/bin/gcc
COLLECT_LTO_WRAPPER=/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/lto-wrapper
Target: powerpc64le-unknown-linux-gnu
Configured with: /home/test/src/gcc/configure --prefix=/home/test/gcc/ieee
--disable-multilib --disable-bootstrap --enable-languages=c++ --disable-pch
--disable-nls --without-isl --with-long-double-format=ieee : (reconfigured)
/home/test/src/gcc/configure --prefix=/home/test/gcc/ieee --disable-multilib
--disable-bootstrap --enable-languages=c++ --disable-pch --disable-nls
--without-isl --with-long-double-format=ieee
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 11.0.1 20210323 (experimental) (GCC)
COLLECT_GCC_OPTIONS='-mno-gnu-attribute' '-mabi=ibmlongdouble' '-Wall'
'-static-libgcc' '-v' '-dumpdir' 'a-'
/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/cc1
-quiet -v 97653.c -quiet -dumpdir a- -dumpbase 97653.c -dumpbase-ext .c
-mno-gnu-attribute -mabi=ibmlongdouble -Wall -version -o /tmp/ccNHNZzj.s
GNU C17 (GCC) version 11.0.1 20210323 (experimental)
(powerpc64le-unknown-linux-gnu)
compiled by GNU C version 11.0.0 20210225 (Red Hat 11.0.0-0), GMP
version 6.2.0, MPFR version 4.1.0-p9, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
ignoring nonexistent directory
"/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/../../../../powerpc64le-unknown-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/include
/usr/local/include
/home/test/gcc/ieee/include
/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/include-fixed
/usr/include
End of search list.
GNU C17 (GCC) version 11.0.1 20210323 (experimental)
(powerpc64le-unknown-linux-gnu)
compiled by GNU C version 11.0.0 20210225 (Red Hat 11.0.0-0), GMP
version 6.2.0, MPFR version 4.1.0-p9, MPC version 1.2.1, isl version none
GGC heuristics: --param ggc-min-expand=30 --param ggc-min-heapsize=4096
Compiler executable checksum: ab29af0a0f73449cd280c2751cbad267
COLLECT_GCC_OPTIONS='-mno-gnu-attribute' '-mabi=ibmlongdouble' '-Wall'
'-static-libgcc' '-v' '-dumpdir' 'a-'
as -v -a64 -mpower8 -mlittle -o /tmp/cc4MmQYf.o /tmp/ccNHNZzj.s
GNU assembler version 2.35.1 (ppc64le-redhat-linux) using BFD version version
2.35.1-41.fc34
COMPILER_PATH=/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/:/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/:/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/:/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/:/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/
LIBRARY_PATH=/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/:/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/../../../../lib64/:/lib/../lib64/:/usr/lib/../lib64/:/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/../../../:/lib/:/usr/lib/
COLLECT_GCC_OPTIONS='-mno-gnu-attribute' '-mabi=ibmlongdouble' '-Wall'
'-static-libgcc' '-v' '-dumpdir' 'a.'
/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/collect2
-plugin
/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/liblto_plugin.so
-plugin-opt=/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-linux-gnu/11.0.1/lto-wrapper
-plugin-opt=-fresolution=/tmp/ccwamb6Q.res -plugin-opt=-pass-through=-lgcc
-plugin-opt=-pass-through=-lgcc_eh -plugin-opt=-pass-through=-lc
-plugin-opt=-pass-through=-lgcc -plugin-opt=-pass-through=-lgcc_eh
--eh-frame-hdr -V -m elf64lppc -dynamic-linker /lib64/ld64.so.2
/lib/../lib64/crt1.o /lib/../lib64/crti.o
/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/crtbegin.o
-L/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1
-L/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/../../../../lib64
-L/lib/../lib64 -L/usr/lib/../lib64
-L/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/../../..
/tmp/cc4MmQYf.o -lgcc -lgcc_eh -lc -lgcc -lgcc_eh
/home/test/gcc/ieee/lib/gcc/powerpc64le-unknown-linux-gnu/11.0.1/crtend.o
/lib/../lib64/crtn.o
GNU ld version 2.35.1-41.fc34
Supported emulations:
elf64lppc
elf32lppc
elf32lppclinux
elf32lppcsim
elf64ppc
elf32ppc
elf32ppclinux
elf32ppcsim
elf32_spu
i386pep
i386pe
elf64bpf
COLLECT_GCC_OPTIONS='-mno-gnu-attribute' '-mabi=ibmlongdouble' '-Wall'
'-static-libgcc' '-v' '-dumpdir' 'a.'
256 * 0.100000 = 256
256 * 0.200000 = 256
256 * 0.500000 = 256
256 * 0.900000 = 256
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
` (10 preceding siblings ...)
2021-03-23 18:08 ` redi at gcc dot gnu.org
@ 2021-03-30 11:28 ` jakub at gcc dot gnu.org
2021-03-30 11:44 ` redi at gcc dot gnu.org
` (8 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-03-30 11:28 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |jakub at gcc dot gnu.org
--- Comment #10 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #9)
> [test@ibm-p8-cluster-02 ~]$ cat 97653.c
> int printf(const char*, ...);
>
> const unsigned long k = 256;
>
> int main()
> {
> long double r[] = { 0.1L, 0.2L, 0.5L, 0.9L };
> for (int i = 0; i < 4; ++i)
> {
> unsigned long j = k * r[i];
> printf("%lu * %Lf = %lu\n", k, r[i], j);
> }
> }
> [test@ibm-p8-cluster-02 ~]$ ~/gcc/ieee/bin/gcc 97653.c -mno-gnu-attribute
> -mabi=ibmlongdouble -Wall -static-libgcc -v && ./a.out
> Using built-in specs.
> COLLECT_GCC=/home/test/gcc/ieee/bin/gcc
> COLLECT_LTO_WRAPPER=/home/test/gcc/ieee/libexec/gcc/powerpc64le-unknown-
> linux-gnu/11.0.1/lto-wrapper
> Target: powerpc64le-unknown-linux-gnu
> Configured with: /home/test/src/gcc/configure --prefix=/home/test/gcc/ieee
> --disable-multilib --disable-bootstrap --enable-languages=c++ --disable-pch
> --disable-nls --without-isl --with-long-double-format=ieee : (reconfigured)
> /home/test/src/gcc/configure --prefix=/home/test/gcc/ieee --disable-multilib
> --disable-bootstrap --enable-languages=c++ --disable-pch --disable-nls
> --without-isl --with-long-double-format=ieee
Is your compiler intentionally configured without --with-long-double-128, i.e.
are you intentionally testing the double == long double case?
I can reproduce the weirdo output only when I build with such configured
cross-compiler (without -mlong-double-128) and link on gcc112 on CompilerFarm
with the system compiler (which defaults to -mlong-double-128).
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
` (11 preceding siblings ...)
2021-03-30 11:28 ` jakub at gcc dot gnu.org
@ 2021-03-30 11:44 ` redi at gcc dot gnu.org
2021-03-30 11:49 ` redi at gcc dot gnu.org
` (7 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: redi at gcc dot gnu.org @ 2021-03-30 11:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #10)
> Is your compiler intentionally configured without --with-long-double-128,
No.
> i.e. are you intentionally testing the double == long double case?
Not intentionally, isn't that implied by --with-long-double-format=ieee ?!
That's what the docs seem to say:
Specify whether long double uses the IBM extended double format or the IEEE
128-bit floating point format on PowerPC Linux systems.
[...]
If you use the --with-long-double-64 configuration option, the
--with-long-double-format=ibm and --with-long-double-format=ieee options
are ignored.
That tells me that using --with-long-double-format={ibm,ieee} chooses *which*
of the 128-bit long double formats you want, and so --with-long-double-128 is
implied. Maybe I'm reading it wrong.
Let me test again. Maybe I was using the system libgcc_s.so not the one
configured as --with-long-double-format=ieee (but I would still expect that to
work as the system one is from F34's gcc-11).
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
` (12 preceding siblings ...)
2021-03-30 11:44 ` redi at gcc dot gnu.org
@ 2021-03-30 11:49 ` redi at gcc dot gnu.org
2021-03-30 12:02 ` jakub at gcc dot gnu.org
` (6 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: redi at gcc dot gnu.org @ 2021-03-30 11:49 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #12 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Also, the docs for --with-long-double-128 say
When neither of these configure options are used, the default will be 128-bit
long double when built against GNU C Library 2.4 and later, 64-bit long
double
otherwise.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/97653] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
` (13 preceding siblings ...)
2021-03-30 11:49 ` redi at gcc dot gnu.org
@ 2021-03-30 12:02 ` jakub at gcc dot gnu.org
2021-03-31 10:58 ` [Bug target/97653] [11 Regression] " jakub at gcc dot gnu.org
` (5 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-03-30 12:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
(In reply to Jonathan Wakely from comment #11)
> That tells me that using --with-long-double-format={ibm,ieee} chooses
> *which* of the 128-bit long double formats you want, and so
> --with-long-double-128 is implied. Maybe I'm reading it wrong.
At least from seeing what my cross-compiler does it is not implied.
If I compile with those
-mno-gnu-attribute -mabi=ibmlongdouble
options, scp assembly to gcc112, compile there (system compiler defaults to
-mlong-double-128), it fails, if I compile locally with
-mno-gnu-attribute -mabi=ibmlongdouble -mlong-double-128
and scp and do the same, it works.
And I can't reproduce on gcc112 with 11.0.0 20210126 gcc natively built there
which defaults to -mlong-double-128:
~/gcc/obj31/gcc/xgcc -B ~/gcc/obj31/gcc/ -B
~/gcc/obj31/powerpc64le-unknown-linux-gnu/libgcc/ -o pr97653{,.c}
-static-libgcc -mno-gnu-attribute -mabi=ibmlongdouble
./pr97653
256 * 0.100000 = 25
256 * 0.200000 = 51
256 * 0.500000 = 128
256 * 0.900000 = 230
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/97653] [11 Regression] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
` (14 preceding siblings ...)
2021-03-30 12:02 ` jakub at gcc dot gnu.org
@ 2021-03-31 10:58 ` jakub at gcc dot gnu.org
2021-03-31 11:59 ` jakub at gcc dot gnu.org
` (4 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-03-31 10:58 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Priority|P3 |P1
Target Milestone|--- |11.0
Summary|Incorrect long double |[11 Regression] Incorrect
|calculation with |long double calculation
|-mabi=ibmlongdouble |with -mabi=ibmlongdouble
--- Comment #14 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, what I missed was that my gcc on gccfarm has been configured without the
--with-long-double-format=ieee option, but Jonathan's gcc has been configured
with that option.
When compiling the #c9 testcase with -mabi=ibmlongdouble , both on compiler
that
was configured --with-long-double-format=ieee and on compiler that was
configured without it, gcc emits calls to
__floatunditf
__gcc_qmul
__fixunstfdi
while when compiling the testcase with -mabi=ieeelongdouble , on both compilers
it emits calls to
__floatundikf
__mulkf3
__fixunskfdi
So far so good.
The problem I see is that depending on how gcc has been configured, libgcc
changes.
In gcc configured without --with-long-double-format=ieee , I see
__floatunditf calling __gcc_qadd and __gcc_qmul, so looks that the tf it talks
about is IBM double double aka if.
But looking at __floatunditf on --with-long-double-format=ieee configured gcc,
I see it calls __floatundikf, __mulkf3 and __addkf3. So it looks both like ABI
incompatibility and something else weird going on, because if it was treating
the
tf as kf, why would it call __floatundikf and something on top of that?
Skimming other __*tf* functions in libgcc.a in --with-long-double-format=ieee
configured gcc, __powitf2 calls __gcc_q{mul,div}, so might be ok,
__eprintf calls __fprintfieee128 rather than fprintf from the other gcc,
but maybe it is ok because it passes to fprintf only arguments that are not
floating point.
__fixtfdi calls __lekf2, so looks ABI incompatible, ditto __fixunstfdi,
__floatditf calls __gcc_q{mul,add}, so might be ok, __fixtfti calls __lekf2,
so looks ABI incompatible, ditto __fixunstfti, __floattitf also looks broken,
ditto __floatuntitf.
Ignoring the decimal stuff (_dpd*).
So, if we want backwards ABI compatibility, I'm afraid when building libgcc,
at least the *tf* entry points, they should be built with explicit
-mabi=ibmlongdouble or otherwise ensure it is using IFmode rather than TFmode
stuff.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/97653] [11 Regression] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
` (15 preceding siblings ...)
2021-03-31 10:58 ` [Bug target/97653] [11 Regression] " jakub at gcc dot gnu.org
@ 2021-03-31 11:59 ` jakub at gcc dot gnu.org
2021-03-31 12:24 ` jakub at gcc dot gnu.org
` (3 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-03-31 11:59 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #15 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
So, just completely untested possibility:
--- libgcc/config/rs6000/t-float128.jj 2021-03-30 18:11:52.572091848 +0200
+++ libgcc/config/rs6000/t-float128 2021-03-31 13:55:47.199756547 +0200
@@ -90,8 +90,16 @@ ibm128_dec_objs = $(addsuffix $(objext)
FP128_CFLAGS_DECIMAL = -mno-gnu-attribute -Wno-psabi -mabi=ieeelongdouble
IBM128_CFLAGS_DECIMAL = -mno-gnu-attribute -Wno-psabi -mabi=ibmlongdouble
+ibm128_siditi_tf_funcs = \
+ $(foreach f,$(sifuncs) $(difuncs) $(tifuncs),$(if $(findstring tf,$f),$f))
+ibm128_siditi_tf_objs = $(patsubst %,%$(objext),$(ibm128_siditi_tf_funcs))
+ifeq ($(enable_shared),yes)
+ibm128_siditi_tf_objs += $(patsubst %,%_s$(objext),$(ibm128_siditi_tf_funcs))
+endif
+
$(fp128_dec_objs) : INTERNAL_CFLAGS += $(FP128_CFLAGS_DECIMAL)
$(ibm128_dec_objs) : INTERNAL_CFLAGS += $(IBM128_CFLAGS_DECIMAL)
+$(ibm128_siditi_tf_objs) : INTERNAL_CFLAGS += $(IBM128_CFLAGS_DECIMAL)
$(fp128_softfp_src) : $(srcdir)/soft-fp/$(subst -sw,,$(subst kf,tf,$@))
$(fp128_dep)
@src="$(srcdir)/soft-fp/$(subst -sw,,$(subst kf,tf,$@))"; \
(though IBM128_CFLAGS_DECIMAL is misnamed for those because it has nothing to
do with decimal).
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/97653] [11 Regression] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
` (16 preceding siblings ...)
2021-03-31 11:59 ` jakub at gcc dot gnu.org
@ 2021-03-31 12:24 ` jakub at gcc dot gnu.org
2021-04-03 8:06 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
20 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-03-31 12:24 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #16 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Actually, there is code to handle that already, just with typos and omissions
in it.
So perhaps better:
2021-03-31 Jakub Jelinek <jakub@redhat.com>
PR target/97653
* config/rs6000/t-linux (IBM128_STATIC_OBJS): Fix spelling, use
$(objext) instead of $(object). Use _floatunditf instead of
_floatunsditf. Add tf <-> ti conversion objects.
--- libgcc/config/rs6000/t-linux.jj 2020-12-04 08:08:06.556434569 +0100
+++ libgcc/config/rs6000/t-linux 2021-03-31 14:20:50.953852864 +0200
@@ -11,9 +11,11 @@ HOST_LIBGCC2_CFLAGS += -mno-minimal-toc
# the IBM extended double format. Also turn off gnu attributes on the static
# modules.
IBM128_STATIC_OBJS = ibm-ldouble$(objext) _powitf2$(objext) \
- ppc64-fp$(objext) _divtc3$(object) _multc3$(object) \
- _fixtfdi$(object) _fixunstfdi$(object) \
- _floatditf$(objext) _floatunsditf$(objext)
+ ppc64-fp$(objext) _divtc3$(objext) _multc3$(objext) \
+ _fixtfdi$(objext) _fixunstfdi$(objext) \
+ _floatditf$(objext) _floatunditf$(objext) \
+ _fixtfti$(objext) _fixunstfti$(objext) \
+ _floattitf$(objext) _floatuntitf$(objext)
IBM128_SHARED_OBJS = $(IBM128_STATIC_OBJS:$(objext):_s$(objext))
IBM128_OBJS = $(IBM128_STATIC_OBJS) $(IBM128_SHARED_OBJS)
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/97653] [11 Regression] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
` (17 preceding siblings ...)
2021-03-31 12:24 ` jakub at gcc dot gnu.org
@ 2021-04-03 8:06 ` cvs-commit at gcc dot gnu.org
2021-04-03 8:16 ` jakub at gcc dot gnu.org
2021-04-20 9:45 ` cvs-commit at gcc dot gnu.org
20 siblings, 0 replies; 22+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-04-03 8:06 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #17 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:cda41ce0e8414aec59e6b9fbe645d96e6e8193e2
commit r11-7969-gcda41ce0e8414aec59e6b9fbe645d96e6e8193e2
Author: Jakub Jelinek <jakub@redhat.com>
Date: Sat Apr 3 10:05:32 2021 +0200
rs6000: Fix up libgcc ABI when built with --with-long-double-format=ieee
[PR97653]
__floatunditf and __fixtfdi and a couple of other libgcc{.a,_s.so}
entrypoints for backwards compatibility should mean IBM double double
handling (i.e. IFmode), gcc emits such calls for that format and
form IEEE long double emits *kf* instead.
When gcc is configured without --with-long-double-format=ieee ,
everything is fine, but when it is not, we need to compile those
libgcc sources with -mno-gnu-attribute -mabi=ibmlongdouble.
The following snippet in libgcc/config/rs6000/t-linux was attempting
to ensure that, and for some routines it works fine (e.g. for _powitf2).
But, due to 4 different types of bugs it doesn't work for most of those
functions, which means that in --with-long-double-format=ieee
configured gcc those *tf* entrypoints instead handle the long double
arguments as if they were KFmode.
The bugs are:
1) the first few objs properly use $(objext) as suffix, but
several other contain a typo and use $(object) instead,
which is a variable that isn't set to anything, so we don't
add .o etc. extensions
2) while unsigned fix are properly called _fixuns*, unsigned float
are called _floatun* (without s), but the var was using there
the extra s and so didn't match
3) the variable didn't cover any of the TF <-> TI conversions,
only TF <-> DI conversions
4) nothing in libgcc_s.so was handled, as those object files are
called *_s.o rather than *.o and IBM128_SHARED_OBJS used wrong
syntax of the GNU make substitution reference, which should be
$(var:a=b) standing for $(patsubst a,b,$(var)) but it used
$(var:a:b) instead
2021-04-03 Jakub Jelinek <jakub@redhat.com>
PR target/97653
* config/rs6000/t-linux (IBM128_STATIC_OBJS): Fix spelling, use
$(objext) instead of $(object). Use _floatunditf instead of
_floatunsditf. Add tf <-> ti conversion objects.
(IBM128_SHARED_OBJS): Use proper substitution reference syntax.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/97653] [11 Regression] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
` (18 preceding siblings ...)
2021-04-03 8:06 ` cvs-commit at gcc dot gnu.org
@ 2021-04-03 8:16 ` jakub at gcc dot gnu.org
2021-04-20 9:45 ` cvs-commit at gcc dot gnu.org
20 siblings, 0 replies; 22+ messages in thread
From: jakub at gcc dot gnu.org @ 2021-04-03 8:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
Jakub Jelinek <jakub at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Resolution|--- |FIXED
Status|REOPENED |RESOLVED
--- Comment #18 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Fixed on the trunk.
^ permalink raw reply [flat|nested] 22+ messages in thread
* [Bug target/97653] [11 Regression] Incorrect long double calculation with -mabi=ibmlongdouble
2020-10-31 8:57 [Bug target/97653] New: Incorrect long double calculation with -mabi=ibmlongdouble redi at gcc dot gnu.org
` (19 preceding siblings ...)
2021-04-03 8:16 ` jakub at gcc dot gnu.org
@ 2021-04-20 9:45 ` cvs-commit at gcc dot gnu.org
20 siblings, 0 replies; 22+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2021-04-20 9:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97653
--- Comment #19 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jakub Jelinek
<jakub@gcc.gnu.org>:
https://gcc.gnu.org/g:8642b73a0f0df1f8e1e2d2102d67a76f8ed0a255
commit r10-9720-g8642b73a0f0df1f8e1e2d2102d67a76f8ed0a255
Author: Jakub Jelinek <jakub@redhat.com>
Date: Sat Apr 3 10:05:32 2021 +0200
rs6000: Fix up libgcc ABI when built with --with-long-double-format=ieee
[PR97653]
__floatunditf and __fixtfdi and a couple of other libgcc{.a,_s.so}
entrypoints for backwards compatibility should mean IBM double double
handling (i.e. IFmode), gcc emits such calls for that format and
form IEEE long double emits *kf* instead.
When gcc is configured without --with-long-double-format=ieee ,
everything is fine, but when it is not, we need to compile those
libgcc sources with -mno-gnu-attribute -mabi=ibmlongdouble.
The following snippet in libgcc/config/rs6000/t-linux was attempting
to ensure that, and for some routines it works fine (e.g. for _powitf2).
But, due to 4 different types of bugs it doesn't work for most of those
functions, which means that in --with-long-double-format=ieee
configured gcc those *tf* entrypoints instead handle the long double
arguments as if they were KFmode.
The bugs are:
1) the first few objs properly use $(objext) as suffix, but
several other contain a typo and use $(object) instead,
which is a variable that isn't set to anything, so we don't
add .o etc. extensions
2) while unsigned fix are properly called _fixuns*, unsigned float
are called _floatun* (without s), but the var was using there
the extra s and so didn't match
3) the variable didn't cover any of the TF <-> TI conversions,
only TF <-> DI conversions
4) nothing in libgcc_s.so was handled, as those object files are
called *_s.o rather than *.o and IBM128_SHARED_OBJS used wrong
syntax of the GNU make substitution reference, which should be
$(var:a=b) standing for $(patsubst a,b,$(var)) but it used
$(var:a:b) instead
2021-04-03 Jakub Jelinek <jakub@redhat.com>
PR target/97653
* config/rs6000/t-linux (IBM128_STATIC_OBJS): Fix spelling, use
$(objext) instead of $(object). Use _floatunditf instead of
_floatunsditf. Add tf <-> ti conversion objects.
(IBM128_SHARED_OBJS): Use proper substitution reference syntax.
(cherry picked from commit cda41ce0e8414aec59e6b9fbe645d96e6e8193e2)
^ permalink raw reply [flat|nested] 22+ messages in thread