[PATCH] D134369: [Clang] Support constexpr builtin fmax

Tue Oct 4 11:32:02 PDT 2022

aaron.ballman added a comment.

Regarding Annex F requirements, do we document that we conform to Annex F and do we have any actual test coverage for it? This question has come up for me quite a bit as I've worked on our C status page and I've never found a satisfactory answer of what we intend to support.

In D134369#3822144 <https://reviews.llvm.org/D134369#3822144>, @jcranmer-intel wrote:

> https://eel.is/c++draft/library.c#3 says that a floating-point exception other than `FE_INEXACT` causes it to not be a constant expression, if I have constant expression wording right. `FE_INVALID` can be raised if the inputs are signalling NaNs, but even if we're claiming implementation of Annex F, it's okay to treat sNaN as qNaN unless we're claiming `FE_SNANS_ALWAYS_SIGNAL` (this is new in C2x, I think). We shouldn't be claiming that except maybe if we're using `-fp-model=strict`. I don't think `#pragma STDC FENV_ACCESS ON` bears any relevance here, but now I'm wondering what needs to happen with that for regular floating-point operations that may trigger exceptions.

I think `FENV_ACCESS` is relevant. [library.c]p3 says C++ constant expressions follow Annex F requirements, and C2x F.8.4p1 says that `FENV_ACCESS` impacts constant expression evaluation.

================
Comment at: clang/lib/AST/ExprConstant.cpp:14034
+      return false;
+    // when comparing zeroes, return +0.0 if one of the zeroes is positive
+    if (Result.isZero() && RHS.isZero() && Result.isNegative())
----------------

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D134369