[clang] [C23] Add INFINITY and NAN macros to <float.h> (PR #96659)

[Aaron Ballman via cfe-commits]

AaronBallman wrote:

> > I looked at my meeting notes for discussion of this paper and I think we do need to worry about what the C standard says. From my notes: `The big intent from this change seems to be about making INFINITY to be a feature test macro.`, so if users are going to portably expect `#ifdef INFINITY` to mean that their use of the macro will generate an actual infinity, we really should support that IMO.
> 
> I went looking through the CFP history of the proposal. It's based on a comp.std.c thread here: https://groups.google.com/g/comp.std.c/c/XCzEiwD9n_A, which became a CFP discussion here: https://mailman.oakapple.net/pipermail/cfp-interest/2021-October/002216.html (and more in the September portion of the archives, but the relevant part of the discussion is in October), and the minutes of the CFP meeting where this was discussed here: https://mailman.oakapple.net/pipermail/cfp-interest/2021-October/002253.html
> 
> The entire history of this discussion is about FP types that do not have a format for infinity (say, VAX FP), and there was commentary on the CFP thread that there was evidence that users thought that `INFINITY` was conditionally defined like `NAN` was. Note that `NAN` has been similarly conditionally defined for a long time, and gcc doesn't undefine it in `-ffinite-math-only` mode, so that's strong precedent for not undefining INFINITY in fast-math.

I spoke with the chair of CFP and he agreed with my assessment that `INFINITY` and `NAN` should not be defined in `-ffinite-math-only` mode, at least in terms of intent behind N2848. He also pointed out that not defining the macro is a security win because it makes it harder for people to write code using that macro and expecting it to do anything useful, which I strongly agree with.

Aside from "compatibility/historically", do we have any technical arguments against following the intent of the standard here? (We already deviate from GCC in so many other ways, I'm not worried about a deviation here; I would presume GCC will eventually get around to doing the same thing, at least for C23 and up).

https://github.com/llvm/llvm-project/pull/96659