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 _______________________________________________ cfe-commits mailing list cfe-commits@lists.llvm.org https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
