libstdc++-v3: do not duplicate some math functions when using newlib

[Jonathan Wakely]

On Thu, 15 Jun 2023, 01:46 Alexandre Oliva via Libstdc++, <
libstdc++@gcc.gnu.org> wrote:

>
> Contributing a patch by Joel Brobecker <brobecker@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.
>

Excellent, I've been looking at this area of our configury and the math
stubs recently and this is a nice improvement.

OK for trunk, thanks.


> 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>
>