Note that we could also apply this flag *only* to lib/msun/src/s_ctanhf.c optionally, as this is the only case we know for certain that has issues with these spurious exceptions.

LGTM

Rebase

LGTM.

Although the original authors seem to dislike constant folding by the compiler, it is a good idea here. :)

If this also works for softfloat now, please go ahead.

Looks like a good idea to me.

Yes, I like this. It's always annoyed me that the failing values weren't printed, and that a lot of code was repeated.

I don't like it too much, but it seems to be necessary to be able to build world with sanitizers later, so let's go for it. :)

Ah sorry, totally forgotten about this. It seems to be fine, let's get it in then.

LGTM

LGTM

In D28787#646959, @arichardson wrote:

In D28787#646949, @dim wrote:

Hm, wouldn't it be better to fix this in gdtoa() instead? Then it would be solved for all gdtoa() consumers. That said, I've understood that the gdtoa code is very impenetrable...

I had a brief look at modifying the gdtoa code, but it seemed to be quite akward so I chose to change the wrapper instead.

It's rather huge, and I'm unsure if the new implementation is much clearer than the old one, with all the magic numbers.... But it passes all current tests, and looks about one or two levels less scary. :)

Hm, wouldn't it be better to fix this in gdtoa() instead? Then it would be solved for all gdtoa() consumers. That said, I've understood that the gdtoa code is very impenetrable...

Though I dislike this all getting so complex, I guess there is no good alternative way to get the required information. At some point using an external toolchain will become the default, and then it'd better work... :)

In D28799#644957, @arichardson wrote:

The real problem is IMO that there are three subtly incompatible definitions of struct _Unwind_Exception: include/unwind.h, contrib/llvm/libunwind and contrib/libcxxrt. This also caused issues in CheriBSD.

In D28690#642826, @jhb wrote:

Don't the symbol map entries just get ignored if the symbols aren't present, so it would be ok to have these in the MI Symbol.map?

LGTM, I ran make check (with LD_LIBRARY_PATH set :) ) and it worked.

Remove the list of math builtins, and only pass -fno-builtin while
building tests for now.

In D28577#639842, @arichardson wrote:

In D28577#639808, @jrtc27 wrote:

In D28577#639776, @jrtc27 wrote:

Doing so for tests makes sense, but why libm itself?

This is because libm has many functions which are implemented in terms of other math functions. For instance, many functions which handle complex arguments are implemented in terms of calling the non-complex variants. E.g. csinh() calls sinh(), cosh(), sin() and cos(). In all these cases, unexpected outcomes could occur if the compiler deciders to shortcut the logic by inserting its own builtins at those call sites.

But that's legal, and if the function has different semantics than C says it should then you shouldn't be calling it that (and how is it ok to use that in the system's standard library implementation)? This feels to me like fixing the wrong problem.

I have seen some LLVM tests fail because the constant folding of math calls produces different floating point constants when the buildbot runs on different operating systems. This is unlikely to happen here, but if it does and you are compiling with a buggy host libm, you might end up creating a broken target libm.

Closing this in favor of D28690.