[libc-commits] [PATCH] D76723: [libc] Generate math.h instead of the static file it is currently.

[Paula Toth via Phabricator via libc-commits]

PaulkaToast added inline comments.


================
Comment at: libc/config/linux/api.td:113
+    SimpleMacroDef<"INFINITY", "__builtin_inff()">,
+    SimpleMacroDef<"NAN", "__builtin_nanf()">,
+
----------------
abrachet wrote:
> `__builtin_nanf()` takes a `const char *` argument. I have no idea why. https://github.com/llvm/llvm-project/blob/master/clang/lib/AST/ExprConstant.cpp#L12816
It corresponds to the `tagp` argument for [nan](https://pubs.opengroup.org/onlinepubs/9699919799/functions/nan.html):

> These functions shall return a quiet NaN, if available, with content indicated through tagp.

This allows the creation of differently "tagged" NaN values (the tags are in the trailing bits). Both musl and glibc use `""` as the tag so this looks good.


================
Comment at: libc/config/linux/api.td:79
+    #define math_errhandling 0
+    #elif defined __NO_MATH_ERRNO__
+    #define math_errhandling (MATH_ERREXCEPT)
----------------
I think some of this might be gcc/glibc specific stuff and should be thought over. See:

* https://gcc.gnu.org/legacy-ml/gcc-patches/2014-11/msg01079.html
* https://github.com/bminor/glibc/commit/3c7d03129498e7426855b5d4cdd5b7109ecc2172

`0` is actually not a value allowed by the C2011 standard for `math_errhandling`. See this excerpt:

> The macros 
> **MATH_ERRNO**
> **MATH_ERREXCEPT**
> expand to the integer constants `1` and `2`, respectively; the macro
> `math_errhandling` expands to an expression that has type int and the value
> `MATH_ERRNO`, `MATH_ERREXCEPT`, or the bitwise OR of both.

> For all functions, a domain error occurs if an input argument is outside the domain over
> which the mathematical function is defined. The description of each function lists any
> required domain errors; an implementation may define additional domain errors, provided
> that such errors are consistent with the mathematical definition of the function.228) On a
> domain error, the function returns an implementation-defined value; if the integer
> expression `math_errhandling & MATH_ERRNO` is nonzero, the integer expression
> `errno` acquires the value `EDOM`; if the integer expression `math_errhandling & MATH_ERREXCEPT`
> is nonzero, the ‘‘invalid’’ floating-point exception is raised.

`__NO_MATH_ERRNO__` in particular is very gcc specific and clang doesn't set it regardless of `-ffast-math` or `-fno-math-errno`. This leads to this case where `sqrt(-1.0)` will not set `errno` despite us setting `math_errhandling` to `MATH_ERRNO | MATH_ERREXCEPT`: https://godbolt.org/z/ZhMT_z

For now it might be better just to define this conservatively as

  lang=c
  #define math_errhandling (MATH_ERREXCEPT)

since it seems a little tough to determine whether math functions will set `errno` across both gcc and clang, but it is known that they will set the floating point exceptions.


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D76723/new/

https://reviews.llvm.org/D76723