[PATCH] D57625: [TargetLibraryInfo] Update run time support for Windows

[Evandro Menezes via Phabricator via llvm-commits]

evandro marked 2 inline comments as done.
evandro added a comment.

In D57625#1386061 <https://reviews.llvm.org/D57625#1386061>, @rnk wrote:

> Do we know when most of these were added? Did the all arrive in more or less the same version? It would be nice to make this conditional on a new enough environment version. That gives users a way to indicate that they are targetting an old CRT if they need to.


Goodness, I wrote this document (https://is.gd/vQYYpY) in 2004 about VS6!  Just don't ask me any question about it, as it was in another life.



================
Comment at: llvm/lib/Analysis/TargetLibraryInfo.cpp:225
     TLI.setUnavailable(LibFunc_acoshf);
     TLI.setUnavailable(LibFunc_acoshl);
+    // asinh
----------------
mstorsjo wrote:
> evandro wrote:
> > mstorsjo wrote:
> > > For ucrt (VS2015 and newer), all of acosh, acoshf, acoshl are available in the crt DLL at least.
> > As far as I can tell, `acoshf()` and `acoshl()` are wrappers around `acosh()`.   Likewise for other math functions. This is confirmed by the documentation at https://is.gd/W5fT9r.
> Can you quote which part there says they're wrappers? I would at least expect e.g. `acoshf()` to be distinct from `acosh()`. Since long double and double are equivalent, I don't doubt that `acoshl()` is a wrapper around `acosh()` though. But in practice, even if e.g. the headers would do such redirecting, the MSVCRT (both DLL and import library) still provides all three function names, both plain, with `f` and `l` suffix.
This is what the document says:

> When you use C++, you can call overloads of *acosh* that take and return *float* or *long* double values. In a C program, *acosh* always takes and returns *double*.

Disassembling the DLL, it's not clear that the `float` version just calls the `double` version after the proper conversions, though.  

We're dealing with very poor documentation that doesn't quite match the header files that don't quite match the object file.

I'm making a judgment call for the the least common denominator: the poor documentation.




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

https://reviews.llvm.org/D57625