jcranmer-intel 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. https://github.com/llvm/llvm-project/pull/96659 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
