sdk-ng

sdk-ng copied to clipboard

Overview

Newlib (and picolibc) currently does not provide the long double math functions (i.e. the math functions suffixed with l such as acoshl) for aarch64-zephyr-elf, riscv64-zephyr-elf and x86_64-zephyr-elf targets because:

• Newlib does not implement any generic long double math functions.
• Newlib maps the long double math functions to the double math functions if and only if the type of long double is equivalent to the type of double.
  • long double type check
  • long double math function mapping

On these targets, typeof(long double) != typeof(double), so the long double math functions are not mapped to the double math functions, and none of the them provides target-specific long double math functions; leaving the long double math functions unimplemented.

For more details, refer to the issue #566.

Implementation Strategy

Since our focus has shifted from the newlib to the picolibc, it would make the most sense to put the effort into getting the long double math function feature parity on the picolibc first.

Consider adding generic 128-bit (and possibly 80-bit) long double math function implementations from compatibly licensed open source libraries to the picolibc -- for example, openlibm.

• Should adjust samples/cpp/hello_world/sample.yaml to remove qemu_x86 and friends from filtered platforms

I fixed above issue building my own SDK with this patch: https://github.com/espressif/newlib-esp32/commit/07be17637e8e3a796926c955d8361f3ddd8550a6

Long double support from openlibm is being added to picolibc in https://github.com/picolibc/picolibc/pull/378.

@stephanosio - is this related?

Undefined reference to __unordxf2, __gexf2, __unordxf2, __lexf2, __gtxf2 on qemu_x86. https://github.com/zephyrproject-rtos/gsoc-2022-thrift/actions/runs/3922902274/jobs/6706162959

It looks like glibc (and hence libgcc) doesn't actually have soft float support for 80-bit values. Looks like we either need to fix that, or bail on long double support for -msoft-float 32-bit x86 targets.