public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug libstdc++/100912] New: powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
@ 2021-06-04 18:51 msc at linux dot ibm.com
2021-06-04 22:27 ` [Bug target/100912] " pinskia at gcc dot gnu.org
` (12 more replies)
0 siblings, 13 replies; 14+ messages in thread
From: msc at linux dot ibm.com @ 2021-06-04 18:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912
Bug ID: 100912
Summary: powerpc64le: ieee128 long double incorrectly printed
when using shared libstdc++
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: libstdc++
Assignee: unassigned at gcc dot gnu.org
Reporter: msc at linux dot ibm.com
Target Milestone: ---
Steps to reproduce:
- Build gcc with IEEE128 as the default long double format (using GCC source
revision cb6e6d5faa3f817435b6f203226fa5969d7a7264).
~/build/gcc> ~/src/gcc/configure --prefix=/home/mscastanho/usr
--with-long-double-128 --with-long-double-format=ieee
--build=powerpc64le-linux-gnu --host=powerpc64le-linux-gnu
--target=powerpc64le-linux-gnu --enable-languages=c++ --with-glibc-version=2.33
--disable-bootstrap CC=gcc-11 CXX=g++-11
~/build/gcc> make && make install
~/build/gcc> /home/mscastanho/usr/bin/g++ -v
Using built-in specs.
COLLECT_GCC=/home/mscastanho/usr/bin/g++
COLLECT_LTO_WRAPPER=/home/mscastanho/usr/libexec/gcc/powerpc64le-linux-gnu/12.0.0/lto-wrapper
Target: powerpc64le-linux-gnu
Configured with: /home/mscastanho/src/gcc/configure
--prefix=/home/mscastanho/usr --with-long-double-128
--with-long-double-format=ieee --build=powerpc64le-linux-gnu
--host=powerpc64le-linux-gnu --target=powerpc64le-linux-gnu
--enable-languages=c++ --with-glibc-version=2.33 --disable-bootstrap CC=gcc-11
CXX=g++-11
Thread model: posix
Supported LTO compression algorithms: zlib
gcc version 12.0.0 20210604 (experimental) (GCC)
- Build and run simple test program with the new compiler and libstdc++
~/build/gcc> cat ~/test-ieee128.cpp
#include <iostream>
using namespace std;
int main () {
long double n = 1.0L;
cout << n << endl;
return 0;
}
~/build/gcc> /home/mscastanho/usr/bin/g++ -g ~/test-ieee128.cpp -o test-shared
~/build/gcc> LD_PRELOAD=~/usr/lib64/libstdc++.so.6 ./test-shared
6.95326e-310
Here I'd expect "1" to be printed.
If the same program is statically linked to libstdc++, it works as expected:
mscastanho@yanny4:~/build/gcc> /home/mscastanho/usr/bin/g++ -g
-static-libstdc++ ~/test-ieee128.cpp -o test-static
mscastanho@yanny4:~/build/gcc> ./test-static
1
After running the two programs side-by-side under gdb, I found out they are
actually calling two different symbols for vsnprintf on std::__convert_from_v.
Dynamically linked binary:
>>> disas _ZSt16__convert_from_vRKP15__locale_structPciPKcz
Dump of assembler code for function
_ZSt16__convert_from_vRKP15__locale_structPciPKcz:
0x00007ffff7d19340 <+0>: addis r2,r12,37
0x00007ffff7d19344 <+4>: addi r2,r2,-14912
=> 0x00007ffff7d19348 <+8>: mflr r0
0x00007ffff7d1934c <+12>: std r29,-24(r1)
0x00007ffff7d19350 <+16>: std r30,-16(r1)
0x00007ffff7d19354 <+20>: mr r29,r6
0x00007ffff7d19358 <+24>: std r31,-8(r1)
0x00007ffff7d1935c <+28>: mr r30,r5
0x00007ffff7d19360 <+32>: mr r31,r4
0x00007ffff7d19364 <+36>: std r0,16(r1)
0x00007ffff7d19368 <+40>: stdu r1,-64(r1)
0x00007ffff7d1936c <+44>: std r7,128(r1)
0x00007ffff7d19370 <+48>: std r8,136(r1)
0x00007ffff7d19374 <+52>: std r10,152(r1)
0x00007ffff7d19378 <+56>: std r9,144(r1)
0x00007ffff7d1937c <+60>: ld r3,0(r3)
0x00007ffff7d19380 <+64>: bl 0x7ffff7d09b60
<000006bf.plt_call.__uselocale@@GLIBC_2.17>
0x00007ffff7d19384 <+68>: ld r2,24(r1)
0x00007ffff7d19388 <+72>: mr r5,r29
0x00007ffff7d1938c <+76>: mr r4,r30
0x00007ffff7d19390 <+80>: addi r6,r1,128
0x00007ffff7d19394 <+84>: mr r9,r3
0x00007ffff7d19398 <+88>: mr r3,r31
0x00007ffff7d1939c <+92>: mr r30,r9
0x00007ffff7d193a0 <+96>: bl 0x7ffff7d112a0
<000006bf.plt_call.vsnprintf@@GLIBC_2.17> <<<<<<<<<<<<<<<<<<<<<<<<<<<<<<
0x00007ffff7d193a4 <+100>: ld r2,24(r1)
0x00007ffff7d193a8 <+104>: mr r31,r3
0x00007ffff7d193ac <+108>: mr r3,r30
0x00007ffff7d193b0 <+112>: bl 0x7ffff7d09b60
<000006bf.plt_call.__uselocale@@GLIBC_2.17>
0x00007ffff7d193b4 <+116>: ld r2,24(r1)
0x00007ffff7d193b8 <+120>: addi r1,r1,64
0x00007ffff7d193bc <+124>: mr r3,r31
0x00007ffff7d193c0 <+128>: ld r0,16(r1)
0x00007ffff7d193c4 <+132>: ld r29,-24(r1)
0x00007ffff7d193c8 <+136>: ld r30,-16(r1)
0x00007ffff7d193cc <+140>: ld r31,-8(r1)
0x00007ffff7d193d0 <+144>: mtlr r0
0x00007ffff7d193d4 <+148>: blr
0x00007ffff7d193d8 <+152>: .long 0x0
0x00007ffff7d193dc <+156>: .long 0x1000900
0x00007ffff7d193e0 <+160>: .long 0x380
End of assembler dump.
Statically linked binary:
>>> disas _ZSt16__convert_from_vRKP15__locale_structPciPKcz
Dump of assembler code for function
_ZSt16__convert_from_vRKP15__locale_structPciPKcz:
0x000000001002e470 <+0>: lis r2,4122
0x000000001002e474 <+4>: addi r2,r2,31744
=> 0x000000001002e478 <+8>: mflr r0
0x000000001002e47c <+12>: std r29,-24(r1)
0x000000001002e480 <+16>: std r30,-16(r1)
0x000000001002e484 <+20>: mr r29,r6
0x000000001002e488 <+24>: std r31,-8(r1)
0x000000001002e48c <+28>: mr r30,r5
0x000000001002e490 <+32>: mr r31,r4
0x000000001002e494 <+36>: std r0,16(r1)
0x000000001002e498 <+40>: stdu r1,-64(r1)
0x000000001002e49c <+44>: std r7,128(r1)
0x000000001002e4a0 <+48>: std r8,136(r1)
0x000000001002e4a4 <+52>: std r10,152(r1)
0x000000001002e4a8 <+56>: std r9,144(r1)
0x000000001002e4ac <+60>: ld r3,0(r3)
0x000000001002e4b0 <+64>: bl 0x10003720
<0000011a.plt_call.__uselocale@@GLIBC_2.17>
0x000000001002e4b4 <+68>: ld r2,24(r1)
0x000000001002e4b8 <+72>: mr r5,r29
0x000000001002e4bc <+76>: mr r4,r30
0x000000001002e4c0 <+80>: addi r6,r1,128
0x000000001002e4c4 <+84>: mr r9,r3
0x000000001002e4c8 <+88>: mr r3,r31
0x000000001002e4cc <+92>: mr r30,r9
0x000000001002e4d0 <+96>: bl 0x10003280
<0000011a.plt_call.__vsnprintfieee128@@GLIBC_2.32> <<<<<<<<<<<<<<<<<<<<<
0x000000001002e4d4 <+100>: ld r2,24(r1)
0x000000001002e4d8 <+104>: mr r31,r3
0x000000001002e4dc <+108>: mr r3,r30
0x000000001002e4e0 <+112>: bl 0x10003720
<0000011a.plt_call.__uselocale@@GLIBC_2.17>
0x000000001002e4e4 <+116>: ld r2,24(r1)
0x000000001002e4e8 <+120>: addi r1,r1,64
0x000000001002e4ec <+124>: mr r3,r31
0x000000001002e4f0 <+128>: ld r0,16(r1)
0x000000001002e4f4 <+132>: ld r29,-24(r1)
0x000000001002e4f8 <+136>: ld r30,-16(r1)
0x000000001002e4fc <+140>: ld r31,-8(r1)
0x000000001002e500 <+144>: mtlr r0
0x000000001002e504 <+148>: blr
0x000000001002e508 <+152>: .long 0x0
0x000000001002e50c <+156>: .long 0x1000900
0x000000001002e510 <+160>: .long 0x380
End of assembler dump.
Software versions used:
Distro:
~/build/gcc> cat /etc/os-release
NAME="openSUSE Tumbleweed"
# VERSION="20210105"
ID="opensuse-tumbleweed"
ID_LIKE="opensuse suse"
VERSION_ID="20210105"
PRETTY_NAME="openSUSE Tumbleweed"
ANSI_COLOR="0;32"
CPE_NAME="cpe:/o:opensuse:tumbleweed:20210105"
BUG_REPORT_URL="https://bugs.opensuse.org"
HOME_URL="https://www.opensuse.org/"
DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed"
LOGO="distributor-logo"
GCC used to build the new compiler:
~/build/gcc> g++-11 -v
Using built-in specs.
COLLECT_GCC=g++-11
COLLECT_LTO_WRAPPER=/usr/lib64/gcc/powerpc64le-suse-linux/11/lto-wrapper
Target: powerpc64le-suse-linux
Configured with: ../configure --prefix=/usr --infodir=/usr/share/info
--mandir=/usr/share/man --libdir=/usr/lib64 --libexecdir=/usr/lib64
--enable-languages=c,c++,objc,fortran,obj-c++,ada,go,jit --enable-host-shared
--enable-checking=release --disable-werror
--with-gxx-include-dir=/usr/include/c++/11 --enable-ssp --disable-libssp
--disable-libvtv --enable-cet=auto --disable-libcc1 --enable-plugin
--with-bugurl=https://bugs.opensuse.org/ --with-pkgversion='SUSE Linux'
--with-slibdir=/lib64 --with-system-zlib --enable-libstdcxx-allocator=new
--disable-libstdcxx-pch --enable-version-specific-runtime-libs
--with-gcc-major-version-only --enable-linker-build-id --enable-linux-futex
--enable-gnu-indirect-function --program-suffix=-11 --without-system-libunwind
--with-cpu=power8 --with-tune=power9 --enable-secureplt --with-long-double-128
--enable-targets=powerpcle-linux --disable-multilib
--with-build-config=bootstrap-lto-lean --enable-link-mutex
--build=powerpc64le-suse-linux --host=powerpc64le-suse-linux
Thread model: posix
Supported LTO compression algorithms: zlib zstd
gcc version 11.0.0 20210118 (experimental) [revision
76c1dd15e4a056a59a13b2208af23a6bd67c2682] (SUSE Linux)
glibc:
~/build/gcc> /lib64/libc.so.6
GNU C Library (GNU libc) release release version 2.33 (git 9826b03b74).
[...]
binutils:
~/build/gcc> rpm -qa binutils
binutils-2.35.1-1.1.ppc64le
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
2021-06-04 18:51 [Bug libstdc++/100912] New: powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++ msc at linux dot ibm.com
@ 2021-06-04 22:27 ` pinskia at gcc dot gnu.org
2021-06-05 10:51 ` redi at gcc dot gnu.org
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu.org @ 2021-06-04 22:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Last reconfirmed| |2021-06-04
Component|libstdc++ |target
Ever confirmed|0 |1
Status|UNCONFIRMED |WAITING
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
This sounds like it is still picking up the wrong libstdc++ really.
Can you disassemble (objdump -dr) ~/usr/lib64/libstdc++.so.6 to see which
vsnprintf is used there?
Also can you set LD_LIBRARY_PATH to ~/usr/lib64/ rather than using LD_PRELOAD
and see if that works.
The other thing to do use LD_DEBUG to figure out which libstdc++ is being used
really.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
2021-06-04 18:51 [Bug libstdc++/100912] New: powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++ msc at linux dot ibm.com
2021-06-04 22:27 ` [Bug target/100912] " pinskia at gcc dot gnu.org
@ 2021-06-05 10:51 ` redi at gcc dot gnu.org
2021-06-07 13:27 ` msc at linux dot ibm.com
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2021-06-05 10:51 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912
--- Comment #2 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Yes, or use "-Wl,-rpath,$HOME/usr/lib64" when linking.
I won't be able to test this myself until Monday
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
2021-06-04 18:51 [Bug libstdc++/100912] New: powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++ msc at linux dot ibm.com
2021-06-04 22:27 ` [Bug target/100912] " pinskia at gcc dot gnu.org
2021-06-05 10:51 ` redi at gcc dot gnu.org
@ 2021-06-07 13:27 ` msc at linux dot ibm.com
2021-06-07 13:50 ` msc at linux dot ibm.com
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: msc at linux dot ibm.com @ 2021-06-07 13:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912
--- Comment #3 from Matheus Castanho <msc at linux dot ibm.com> ---
Using objdump -dr ~/usr/lib64/libstdc++.so.6:
[...]
00000000000c9340 <_ZSt16__convert_from_vRKP15__locale_structPciPKcz>:
c9340: 25 00 4c 3c addis r2,r12,37
c9344: c0 c5 42 38 addi r2,r2,-14912
c9348: a6 02 08 7c mflr r0
c934c: e8 ff a1 fb std r29,-24(r1)
c9350: f0 ff c1 fb std r30,-16(r1)
c9354: 78 33 dd 7c mr r29,r6
c9358: f8 ff e1 fb std r31,-8(r1)
c935c: 78 2b be 7c mr r30,r5
c9360: 78 23 9f 7c mr r31,r4
c9364: 10 00 01 f8 std r0,16(r1)
c9368: c1 ff 21 f8 stdu r1,-64(r1)
c936c: 80 00 e1 f8 std r7,128(r1)
c9370: 88 00 01 f9 std r8,136(r1)
c9374: 98 00 41 f9 std r10,152(r1)
c9378: 90 00 21 f9 std r9,144(r1)
c937c: 00 00 63 e8 ld r3,0(r3)
c9380: e1 07 ff 4b bl b9b60
<000006bf.plt_call.__uselocale@@GLIBC_2.17>
c9384: 18 00 41 e8 ld r2,24(r1)
c9388: 78 eb a5 7f mr r5,r29
c938c: 78 f3 c4 7f mr r4,r30
c9390: 80 00 c1 38 addi r6,r1,128
c9394: 78 1b 69 7c mr r9,r3
c9398: 78 fb e3 7f mr r3,r31
c939c: 78 4b 3e 7d mr r30,r9
c93a0: 01 7f ff 4b bl c12a0
<000006bf.plt_call.vsnprintf@@GLIBC_2.17>
c93a4: 18 00 41 e8 ld r2,24(r1)
c93a8: 78 1b 7f 7c mr r31,r3
c93ac: 78 f3 c3 7f mr r3,r30
c93b0: b1 07 ff 4b bl b9b60
<000006bf.plt_call.__uselocale@@GLIBC_2.17>
c93b4: 18 00 41 e8 ld r2,24(r1)
c93b8: 40 00 21 38 addi r1,r1,64
c93bc: 78 fb e3 7f mr r3,r31
c93c0: 10 00 01 e8 ld r0,16(r1)
c93c4: e8 ff a1 eb ld r29,-24(r1)
c93c8: f0 ff c1 eb ld r30,-16(r1)
c93cc: f8 ff e1 eb ld r31,-8(r1)
c93d0: a6 03 08 7c mtlr r0
c93d4: 20 00 80 4e blr
c93d8: 00 00 00 00 .long 0x0
c93dc: 00 09 00 01 .long 0x1000900
c93e0: 80 03 00 00 .long 0x380
c93e4: 00 00 00 60 nop
c93e8: 00 00 00 60 nop
c93ec: 00 00 00 60 nop
[...]
Using LD_LIBRARY_PATH instead of LD_PRELOAD shows the same behavior:
~/build/gcc> LD_LIBRARY_PATH=~/usr/lib64/ ./test-shared
6.95326e-310
Adding LD_DEBUG=libs shows that it is indeed using the libstdc++ I built:
~/build/gcc> LD_LIBRARY_PATH=~/usr/lib64/ LD_DEBUG=libs ./test-shared
38216: find library=libstdc++.so.6 [0]; searching
38216: search
path=/home/mscastanho/usr/lib64/glibc-hwcaps/power9:/home/mscastanho/usr/lib64/tls/power9/altivec/dfp:/home/mscastanho/usr/lib64/tls/power9/altivec:/home/
mscastanho/usr/lib64/tls/power9/dfp:/home/mscastanho/usr/lib64/tls/power9:/home/mscastanho/usr/lib64/tls/altivec/dfp:/home/mscastanho/usr/lib64/tls/altivec:/home/mscastanho/usr/l
ib64/tls/dfp:/home/mscastanho/usr/lib64/tls:/home/mscastanho/usr/lib64/power9/altivec/dfp:/home/mscastanho/usr/lib64/power9/altivec:/home/mscastanho/usr/lib64/power9/dfp:/home/ms
castanho/usr/lib64/power9:/home/mscastanho/usr/lib64/altivec/dfp:/home/mscastanho/usr/lib64/altivec:/home/mscastanho/usr/lib64/dfp:/home/mscastanho/usr/lib64
(LD_LIB
RARY_PATH)
38216: trying
file=/home/mscastanho/usr/lib64/glibc-hwcaps/power9/libstdc++.so.6
38216: trying
file=/home/mscastanho/usr/lib64/tls/power9/altivec/dfp/libstdc++.so.6
38216: trying
file=/home/mscastanho/usr/lib64/tls/power9/altivec/libstdc++.so.6
38216: trying
file=/home/mscastanho/usr/lib64/tls/power9/dfp/libstdc++.so.6
38216: trying file=/home/mscastanho/usr/lib64/tls/power9/libstdc++.so.6
38216: trying
file=/home/mscastanho/usr/lib64/tls/altivec/dfp/libstdc++.so.6
38216: trying file=/home/mscastanho/usr/lib64/tls/altivec/libstdc++.so.6
38216: trying file=/home/mscastanho/usr/lib64/tls/dfp/libstdc++.so.6
38216: trying file=/home/mscastanho/usr/lib64/tls/libstdc++.so.6
38216: trying
file=/home/mscastanho/usr/lib64/power9/altivec/dfp/libstdc++.so.6
38216: trying
file=/home/mscastanho/usr/lib64/power9/altivec/libstdc++.so.6
38216: trying
file=/home/mscastanho/usr/lib64/power9/dfp/libstdc++.so.6
38216: trying file=/home/mscastanho/usr/lib64/power9/libstdc++.so.6
38216: trying
file=/home/mscastanho/usr/lib64/altivec/dfp/libstdc++.so.6
38216: trying file=/home/mscastanho/usr/lib64/altivec/libstdc++.so.6
38216: trying file=/home/mscastanho/usr/lib64/dfp/libstdc++.so.6
38216: trying file=/home/mscastanho/usr/lib64/libstdc++.so.6
38216:
38216: find library=libm.so.6 [0]; searching
38216: search path=/home/mscastanho/usr/lib64
(LD_LIBRARY_PATH)
38216: trying file=/home/mscastanho/usr/lib64/libm.so.6
38216: search cache=/etc/ld.so.cache
38216: trying file=/lib64/libm.so.6
38216:
38216: find library=libgcc_s.so.1 [0]; searching
38216: search path=/home/mscastanho/usr/lib64
(LD_LIBRARY_PATH)
38216: trying
file=/home/mscastanho/usr/lib64/libgcc_s.so.1
38216:
38216: find library=libc.so.6 [0]; searching
38216: search path=/home/mscastanho/usr/lib64
(LD_LIBRARY_PATH)
38216: trying
file=/home/mscastanho/usr/lib64/libc.so.6
38216: search cache=/etc/ld.so.cache
38216: trying file=/lib64/libc.so.6
38216:
38216:
38216: calling init: /lib64/ld64.so.2
38216:
38216:
38216: calling init: /lib64/libc.so.6
38216:
38216:
38216: calling init:
/home/mscastanho/usr/lib64/libgcc_s.so.1
38216:
38216:
38216: calling init: /lib64/libm.so.6
38216:
38216:
38216: calling init: /home/mscastanho/usr/lib64/libstdc++.so.6
38216:
38216:
38216: initialize program: ./test-shared
38216:
38216:
38216: transferring control: ./test-shared
38216:
6.95325e-310
38216:
38216: calling fini: ./test-shared [0]
38216:
38216:
38216: calling fini: /home/mscastanho/usr/lib64/libstdc++.so.6 [0]
38216:
38216:
38216: calling fini: /lib64/libm.so.6 [0]
38216:
38216:
38216: calling fini:
/home/mscastanho/usr/lib64/libgcc_s.so.1 [0]
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug target/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
2021-06-04 18:51 [Bug libstdc++/100912] New: powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++ msc at linux dot ibm.com
` (2 preceding siblings ...)
2021-06-07 13:27 ` msc at linux dot ibm.com
@ 2021-06-07 13:50 ` msc at linux dot ibm.com
2021-10-11 10:08 ` [Bug libstdc++/100912] " qiu.chaofan at outlook dot com
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: msc at linux dot ibm.com @ 2021-06-07 13:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912
--- Comment #4 from Matheus Castanho <msc at linux dot ibm.com> ---
Just for completeness, setting the rpath showed the same results:
~/build/gcc> /home/mscastanho/usr/bin/g++ -g -Wl,-rpath,$HOME/usr/lib64
~/test-ieee128.cpp -o test-shared
~/build/gcc> ./test-shared
6.95329e-310
The output with LD_DEBUG=libs is very much the same as in my previous comment.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
2021-06-04 18:51 [Bug libstdc++/100912] New: powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++ msc at linux dot ibm.com
` (3 preceding siblings ...)
2021-06-07 13:50 ` msc at linux dot ibm.com
@ 2021-10-11 10:08 ` qiu.chaofan at outlook dot com
2021-10-13 8:56 ` qiu.chaofan at outlook dot com
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: qiu.chaofan at outlook dot com @ 2021-10-11 10:08 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912
Qiu Chaofan <qiu.chaofan at outlook dot com> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |qiu.chaofan at outlook dot com
--- Comment #5 from Qiu Chaofan <qiu.chaofan at outlook dot com> ---
Hi, I encountered the same problem when dynamically linking against libstdcxx,
while static linking works fine. The HEAD of git history is 8f323c712 (early
Sep.) so it shouldn't be old.
The configure option is: --enable-languages=c,c++ --disable-nls
--disable-bootstrap --with-long-double-format=ieee --disable-libgomp
--enable-multilib --with-cpu=power9 --with-advance-toolchain=at15.0
(Disabling multilib still has this issue)
By digging into make log, I found something interesting (some omitted):
libtool: link: /build/./gcc/xgcc -shared-libgcc ... -fPIC -DPIC
-D_GLIBCXX_SHARED -shared -nostdlib /opt/at15.0/lib/../lib64/crti.o
/build/./gcc/crtbeginS.o .libs/compatibility.o
.libs/compatibility-debug_list.o .libs/compatibility-debug_list-2.o
.libs/compatibility-ldbl.o .libs/compatibility-c++0x.o
.libs/compatibility-atomic-c++0x.o .libs/compatibility-thread-c++0x.o
.libs/compatibility-chrono.o .libs/compatibility-condvar.o
.libs/compatibility-ldbl-alt128.o .libs/compatibility-ldbl-alt128-cxx11.o
-Wl,--whole-archive ../libsupc++/.libs/libsupc++convenience.a
../src/c++98/.libs/libc++98convenience.a
../src/c++11/.libs/libc++11convenience.a
../src/c++17/.libs/libc++17convenience.a
../src/c++20/.libs/libc++20convenience.a ... -Wl,-soname -Wl,libstdc++.so.6 -o
.libs/libstdc++.so.6.0.29
Only the 'compatibility' objects joined the link, and they're built using
`-mabi=ibmlongdouble`, not IEEE. Manually adding `c++11/wlocale-inst.o`
produces error complaining about multiple definition.
While libstdc++.a contains all of these definitions, actually seven
(compatibility-ldbl.o compatibility-ldbl-alt128.o
compatibility-ldbl-alt128-cxx11.o cxx11-locale-inst.o cxx11-wlocale-inst.o
locale-inst.o wlocale-inst.o
), so ld can find the correct one properly. (although I'm still not clear how
ld does it)
If I understood correctly, the reason why result is incorrect is that the
`libstdc++.so` only contains symbols built for compatibility. Maybe something
went wrong in the build scripts?
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
2021-06-04 18:51 [Bug libstdc++/100912] New: powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++ msc at linux dot ibm.com
` (4 preceding siblings ...)
2021-10-11 10:08 ` [Bug libstdc++/100912] " qiu.chaofan at outlook dot com
@ 2021-10-13 8:56 ` qiu.chaofan at outlook dot com
2021-10-13 9:16 ` redi at gcc dot gnu.org
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: qiu.chaofan at outlook dot com @ 2021-10-13 8:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912
--- Comment #6 from Qiu Chaofan <qiu.chaofan at outlook dot com> ---
By changing the order of linked objects (move .libs/compatibility-ldbl.o
.libs/compatibility-ldbl-alt128.o .libs/compatibility-ldbl-alt128-cxx11.o after
the series of convenience archives), the result under `-mabi=ieeelongdouble` is
correct, but `-mabi=ibmlongdouble` goes wrong.
Removing `--gc-sections` and use nm, we’ll see both
`__vsnprintfieee128@@GLIBC_2.32` and `vsnprintf@@GLIBC_2.17` exist. So it looks
all the symbols (with the same name,
_ZSt16__convert_from_vRKP15__locale_structPciPKcz) were visited by the linker,
but only the first one was kept.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
2021-06-04 18:51 [Bug libstdc++/100912] New: powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++ msc at linux dot ibm.com
` (5 preceding siblings ...)
2021-10-13 8:56 ` qiu.chaofan at outlook dot com
@ 2021-10-13 9:16 ` redi at gcc dot gnu.org
2021-10-21 3:47 ` qiu.chaofan at outlook dot com
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2021-10-13 9:16 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |ASSIGNED
Keywords| |wrong-code
Assignee|unassigned at gcc dot gnu.org |redi at gcc dot gnu.org
--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Thanks for the analysis! Looks like we need two different versions of that
symbol, with different mangled names.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
2021-06-04 18:51 [Bug libstdc++/100912] New: powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++ msc at linux dot ibm.com
` (6 preceding siblings ...)
2021-10-13 9:16 ` redi at gcc dot gnu.org
@ 2021-10-21 3:47 ` qiu.chaofan at outlook dot com
2021-12-06 6:26 ` qiu.chaofan at outlook dot com
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: qiu.chaofan at outlook dot com @ 2021-10-21 3:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912
--- Comment #8 from Qiu Chaofan <qiu.chaofan at outlook dot com> ---
> Looks like we need two different versions of that symbol, with different mangled names.
Yes, I did a little hack: adding another symbol `__convert_from_v_ieee128`
(guarded under macro __LONG_DOUBLE_IEEE128__), and use the macro to determine
call `__convert_from_v_ieee128` or `__convert_from_v` in callers, which shows
expected result.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
2021-06-04 18:51 [Bug libstdc++/100912] New: powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++ msc at linux dot ibm.com
` (7 preceding siblings ...)
2021-10-21 3:47 ` qiu.chaofan at outlook dot com
@ 2021-12-06 6:26 ` qiu.chaofan at outlook dot com
2022-01-10 9:57 ` qiu.chaofan at outlook dot com
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: qiu.chaofan at outlook dot com @ 2021-12-06 6:26 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912
--- Comment #9 from Qiu Chaofan <qiu.chaofan at outlook dot com> ---
I also get following 'symbol not found' error for following case (under
-mabi=ieeelongdouble): undefined reference to
`std::__gnu_cxx11_ieee128::money_get<wchar_t, std::istreambuf_iterator<wchar_t,
std::char_traits<wchar_t> > >::money_get(unsigned long)'
Maybe related?
#include <iterator>
#include <locale>
#include <sstream>
struct D : public std::money_get<wchar_t> {
D() : std::money_get<wchar_t>() {}
iter_type do_get(iter_type s, iter_type end, bool intl, std::ios_base &str,
std::ios_base::iostate &err, long double &units) const {
return std::money_get<wchar_t>::do_get(s, end, intl, str, err, units);
}
} d;
int main(void) {
std::wistringstream in(L"1 ");
in.imbue(std::locale::classic());
in.exceptions(std::ios_base::goodbit);
long double val;
std::istreambuf_iterator<wchar_t> end;
std::istreambuf_iterator<wchar_t> begin(in);
std::ios_base::iostate prior_err = in.rdstate();
std::ios_base::iostate err = in.rdstate();
d.do_get(begin, end, true, in, err, val);
return 0;
}
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
2021-06-04 18:51 [Bug libstdc++/100912] New: powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++ msc at linux dot ibm.com
` (8 preceding siblings ...)
2021-12-06 6:26 ` qiu.chaofan at outlook dot com
@ 2022-01-10 9:57 ` qiu.chaofan at outlook dot com
2022-01-10 10:01 ` redi at gcc dot gnu.org
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: qiu.chaofan at outlook dot com @ 2022-01-10 9:57 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912
--- Comment #10 from Qiu Chaofan <qiu.chaofan at outlook dot com> ---
Hi, does GCC plan to switch to IEEE-quad as default `long double` semantics (or
at least fully support it but under an option)? If so, I guess this should be a
blocker.
If GCC 12 supports it well, other compilers like Clang can emit warning if
enabling abi=ieeelongdouble but linking against older libstdcxx version.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
2021-06-04 18:51 [Bug libstdc++/100912] New: powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++ msc at linux dot ibm.com
` (9 preceding siblings ...)
2022-01-10 9:57 ` qiu.chaofan at outlook dot com
@ 2022-01-10 10:01 ` redi at gcc dot gnu.org
2022-02-14 17:27 ` cvs-commit at gcc dot gnu.org
2022-02-14 17:29 ` redi at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2022-01-10 10:01 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912
--- Comment #11 from Jonathan Wakely <redi at gcc dot gnu.org> ---
This absolutely needs to be (and will be) fixed for GCC 12 anyway, whether the
default is switched or not.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
2021-06-04 18:51 [Bug libstdc++/100912] New: powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++ msc at linux dot ibm.com
` (10 preceding siblings ...)
2022-01-10 10:01 ` redi at gcc dot gnu.org
@ 2022-02-14 17:27 ` cvs-commit at gcc dot gnu.org
2022-02-14 17:29 ` redi at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2022-02-14 17:27 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912
--- Comment #12 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jonathan Wakely <redi@gcc.gnu.org>:
https://gcc.gnu.org/g:3d50dede07de0923f0f320d385162e546445e640
commit r12-7231-g3d50dede07de0923f0f320d385162e546445e640
Author: Jonathan Wakely <jwakely@redhat.com>
Date: Mon Feb 14 16:46:55 2022 +0000
libstdc++: Fix stream extraction of IEEE128 long double [PR100912]
The std::__convert_from_v helper that formats double and long double
values into a char buffer was not being duplicated for the two long
double ABIs. This resulted in an ODR violation inside the library, where
some callers needed it to use snprintf to format __ibm128 values and
other callers needed it to use __snprintfieee128 to format __ieee128
values. The linker discarded one of the definitions, leaving one set of
callers using the wrong code.
This puts __convert_from_v in the __gnu_cxx_ieee128 inline namespace
when long double is __ieee128, so that there are two different
definitions of the function.
The std::money_put::__do_put overload for __ibm128 values needs a
different fix, because that is defined when long double is __ieee128 and
so would call the one in the inline namespace. That can be fixed by just
inlining the code directly into the function and using an asm alias to
call the right version of snprintf for the __ibm128 format. The code to
do that can be simpler than __convert_from_v because if we're defining
the ALT128_COMPAT symbols we know that we have a recent glibc and so we
can assume that uselocale and snprintf are supported.
libstdc++-v3/ChangeLog:
PR libstdc++/100912
* config/locale/gnu/c_locale.h (__convert_from_v): Use inline
namespace for IEEE128 long double mode.
* config/os/gnu-linux/ldbl-ieee128-extra.ver: Add new symbol
version and export __gnu_cxx_ieee128::__convert_from_v.
* include/bits/locale_facets_nonio.tcc (money_put::__do_put):
Make __ibm128 overload use snprintf directly
* testsuite/util/testsuite_abi.cc: Add new symbol version.
Remove stable IEEE128/LDBL versions.
^ permalink raw reply [flat|nested] 14+ messages in thread
* [Bug libstdc++/100912] powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++
2021-06-04 18:51 [Bug libstdc++/100912] New: powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++ msc at linux dot ibm.com
` (11 preceding siblings ...)
2022-02-14 17:27 ` cvs-commit at gcc dot gnu.org
@ 2022-02-14 17:29 ` redi at gcc dot gnu.org
12 siblings, 0 replies; 14+ messages in thread
From: redi at gcc dot gnu.org @ 2022-02-14 17:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100912
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|ASSIGNED |RESOLVED
Target Milestone|--- |12.0
Resolution|--- |FIXED
--- Comment #13 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Fixed on trunk now. As this adds new symbol versions I don't plan to backport
it to gcc-11. Trunk should be used for anybody who needs IEEE128 support.
^ permalink raw reply [flat|nested] 14+ messages in thread
end of thread, other threads:[~2022-02-14 17:29 UTC | newest]
Thread overview: 14+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2021-06-04 18:51 [Bug libstdc++/100912] New: powerpc64le: ieee128 long double incorrectly printed when using shared libstdc++ msc at linux dot ibm.com
2021-06-04 22:27 ` [Bug target/100912] " pinskia at gcc dot gnu.org
2021-06-05 10:51 ` redi at gcc dot gnu.org
2021-06-07 13:27 ` msc at linux dot ibm.com
2021-06-07 13:50 ` msc at linux dot ibm.com
2021-10-11 10:08 ` [Bug libstdc++/100912] " qiu.chaofan at outlook dot com
2021-10-13 8:56 ` qiu.chaofan at outlook dot com
2021-10-13 9:16 ` redi at gcc dot gnu.org
2021-10-21 3:47 ` qiu.chaofan at outlook dot com
2021-12-06 6:26 ` qiu.chaofan at outlook dot com
2022-01-10 9:57 ` qiu.chaofan at outlook dot com
2022-01-10 10:01 ` redi at gcc dot gnu.org
2022-02-14 17:27 ` cvs-commit at gcc dot gnu.org
2022-02-14 17:29 ` redi at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).