aboutsummaryrefslogtreecommitdiff
path: root/gcc
diff options
context:
space:
mode:
authorJonathan Wakely <jwakely@redhat.com>2022-04-29 12:17:13 +0100
committerJonathan Wakely <jwakely@redhat.com>2022-04-29 14:40:59 +0100
commitbb7cf39b05a216431a431499d0c36a6034f6acc4 (patch)
tree33eadd4ca49ff604b8abdd42d193316ac484618f /gcc
parent19c62569ccf20d2744b63482a470474391d28c02 (diff)
downloadgcc-bb7cf39b05a216431a431499d0c36a6034f6acc4.zip
gcc-bb7cf39b05a216431a431499d0c36a6034f6acc4.tar.gz
gcc-bb7cf39b05a216431a431499d0c36a6034f6acc4.tar.bz2
libstdc++: Add missing exports for ppc64le --with-long-double-format=ibm [PR105417]
The --with-long-double-abi=ibm build is missing some exports that are present in the --with-long-double-abi=ieee build. Those symbols never should have been exported at all, but now that they have been, they should be exported consistently by both ibm and ieee. This simply defines them as aliases for equivalent symbols that are already present. The abi-tag on num_get::_M_extract_int isn't really needed, because it only uses a std::string as a local variable, not in the return type or function parameters, so it's safe to define the _M_extract_int[abi:cxx11] symbols as aliases for the corresponding function without the abi-tag. This causes some new symbols to be added to the GLIBCXX_3.4.29 version for the ibm long double build mode, but there is no advantage to adding them to 3.4.30 for that build. That would just create more inconsistencies. libstdc++-v3/ChangeLog: PR libstdc++/105417 * config/abi/post/powerpc64-linux-gnu/baseline_symbols.txt: Regenerate. * src/c++11/compatibility-ldbl-alt128.cc [_GLIBCXX_USE_DUAL_ABI]: Define __gnu_ieee128::num_get<C>::_M_extract_int[abi:cxx11]<I> symbols as aliases for corresponding symbols without abi-tag.
Diffstat (limited to 'gcc')
0 files changed, 0 insertions, 0 deletions