[PATCH] D126364: Fix interaction of pragma FENV_ACCESS with other pragmas

Serge Pavlov via Phabricator via cfe-commits cfe-commits at lists.llvm.org
Tue Jun 7 04:11:49 PDT 2022


sepavloff added inline comments.


================
Comment at: clang/include/clang/Basic/LangOptions.h:622
     setFPContractMode(LangOptions::FPM_Off);
     setRoundingMode(static_cast<RoundingMode>(LangOptions::FPR_ToNearest));
     setFPExceptionMode(LangOptions::FPE_Ignore);
----------------
efriedma wrote:
> sepavloff wrote:
> > efriedma wrote:
> > > I'm suggesting this should be `setRoundingMode(llvm::RoundingMode::Dynamic)`.
> > > 
> > > If FENV_ACCESS is off, getEffectiveRoundingMode() converts that to "nearest".  If FENV_ACCESS is turned on, the mode is treated as dynamic.  This is exactly what we want.
> > It would change semantics. In particular, it would make impossible to use FP arithmetic in constexpr functions. An expression like `1.0 / 3.0` cannot be evaluated with dynamic rounding mode.
> Can we just change the relevant code in ExprConstant to call getEffectiveRoundingMode()?
What is the advantage of using FE_DYNAMIC in the case when it is known that rounding mode is FE_TONEAREST?

Probably `FENV_ROUND FE_DYNAMIC` should result in `dynamic` rounding even if `FENV_ACCESS ON` is absent. Rounding mode cannot be changed in this case but it can be used to inform the compiler that such function can be called in environment, where rounding mode is non-default. It would prevent some constant evaluations and other transformations that assume rounding mode is known. Anyway the standard only allow to assume FE_TONEAREST but does not require this.

In such case `getEffectiveRoundingMode` is not needed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D126364



More information about the cfe-commits mailing list