Contributing a patch by Joel Brobecker <brobec...@adacore.com>. Regstrapped on x86_64-linux-gnu just to be sure, also tested with aarch64-rtems6. I'm going to put this in later this week if there aren't any objections.
When running the libstdc++ testsuite on AArch64 RTEMS, we noticed that about 25 tests are failing during the link, due to the "sqrtl" function being defined twice: - once inside RTEMS' libm; - once inside our libstdc++. One test that fails, for instance, would be 26_numerics/complex/13450.cc. In comparing libm and libstdc++, we found that libstc++ also duplicates "hypotf", and "hypotl". For "sqrtl" and "hypotl", the symbosl come a unit called from math_stubs_long_double.cc, while "hypotf" comes from the equivalent unit for the float version, called math_stubs_float.cc. Those units are always compiled in libstdc++ and provide our own version of various math routines when those are missing from the target system. The definition of those symbols is predicated on the existance of various macros provided by c++config.h, which themselves are predicated by the corresponding HAVE_xxx macros in config.h. One key element behind what's happening, here, is that the target uses newlib, and therefore GCC was configured --with-newlib. The section of libstdc++v3's configure script that handles which math functions are available has a newlib-specific section, and that section provides a hardcoded list of symbols. For "hypotf", this commit fixes the issue by doing the same as for the other routines already declared in that section. I verified by inspection in the newlib code that this function should always be present, so hardcoding it in our configure script should not be an issue. For the math routines handling doubles ("sqrtl" and "hypotl"), however, I do not believe we can assume that newlib's libm will always provide them. Therefore, this commit fixes that part of the issue by ading a compile-check for "sqrtl" and "hypotl". And while at it, we also include checks for all the other math functions that math_stubs_long_double.cc re-implements, allowing us to be resilient to future newlib enhancements adding support for more functions. libstdc++-v3/ChangeLog: * configure.ac ["x${with_newlib}" = "xyes"]: Define HAVE_HYPOTF. Add compile-checks for various long double math functions as well. * configure: Regenerate. --- libstdc++-v3/configure | 1179 +++++++++++++++++++++++++++++++++++++++++++++ libstdc++-v3/configure.ac | 9 2 files changed, 1188 insertions(+) diff --git a/libstdc++-v3/configure b/libstdc++-v3/configure index 354c566b0055c..bda8053ecc279 100755 [omitted] diff --git a/libstdc++-v3/configure.ac b/libstdc++-v3/configure.ac index 0abe54e7b9a21..9770c1787679f 100644 --- a/libstdc++-v3/configure.ac +++ b/libstdc++-v3/configure.ac @@ -349,6 +349,7 @@ else AC_DEFINE(HAVE_FLOORF) AC_DEFINE(HAVE_FMODF) AC_DEFINE(HAVE_FREXPF) + AC_DEFINE(HAVE_HYPOTF) AC_DEFINE(HAVE_LDEXPF) AC_DEFINE(HAVE_LOG10F) AC_DEFINE(HAVE_LOGF) @@ -360,6 +361,14 @@ else AC_DEFINE(HAVE_TANF) AC_DEFINE(HAVE_TANHF) +dnl # Support for the long version of some math libraries depends on +dnl # architecture and newlib version. So test for their availability +dnl # rather than hardcoding that information. + GLIBCXX_CHECK_MATH_DECLS([ + acosl asinl atan2l atanl ceill coshl cosl expl fabsl floorl fmodl + frexpl hypotl ldexpl log10l logl modfl powl sinhl sinl sqrtl + tanhl tanl]) + AC_DEFINE(HAVE_ICONV) AC_DEFINE(HAVE_MEMALIGN) -- Alexandre Oliva, happy hacker https://FSFLA.org/blogs/lxo/ Free Software Activist GNU Toolchain Engineer Disinformation flourishes because many people care deeply about injustice but very few check the facts. Ask me about <https://stallmansupport.org>