[Regression 16 -> 17] Template instantiation ignores FENV_ACCESS being ON for both definition and instantiation

[hubert-reinterpretcast]

Consider:

#pragma STDC FENV_ACCESS ON
template <typename>
int b() {
  int x;
  if ((float)0xFFFFFFFF != (float)0x100000000) {
    x = 1;
  }
  return x;
}
int f() { return b<void>(); }

Clang 16 generates the floating-point operations (as is appropriate for FENV_ACCESS being ON):

f():                                  # @f()
        mov     eax, 4294967295
        cvtsi2ss        xmm0, rax
        movabs  rax, 4294967296
        cvtsi2ss        xmm1, rax
        ucomiss xmm0, xmm1
        mov     eax, 1
        ret

Clang "17" currently generates no floating-point operations:

f(): # @f()
  ret

Compiler Explorer: https://godbolt.org/z/PcoaaxzKn

Reverting fde5924 restores the previous behaviour.

[llvmbot]

@llvm/issue-subscribers-clang-frontend

[spavloff]

This defect is not caused by fde5924. The reason is the elimination of ImplicitCastExpr when a template is instantiated, see comment:

llvm-project/clang/lib/Sema/TreeTransform.h

Lines 11629 to 11631 in a5fe6c7

	TreeTransform<Derived>::TransformImplicitCastExpr(ImplicitCastExpr *E) {
	// Implicit casts are eliminated during transformation, since they
	// will be recomputed by semantic analysis after transformation.

ImplicitCastExpr keeps FP options, including rounding direction. Removing them results in FPOptions loss, they are taken from the current Sema state, which is incorrect behavior.

Revert of fde5924 accidentally fixed the behavior, because FP options used to generate code were taken from Sema state (and nof from AST node) and they were the same as at the point of the template definition. If, for example, #pragma STDC FENV_ACCESS OFF is put at the end of the file, the problem would be observed with the commit reverted.

I will prepare a fix soon.

[AaronBallman]

FWIW, rc3 is supposed to go out in about a week and I believe we're hoping that's one of the last rcs, so we don't have much bake time for a fix. If the fix ends up being trivial and obviously correct, then I think it may still be able to make 17.x. I'm a bit more worried about it not being a trivial change though. It sounds like fde5924 accidentally exposed an issue that is causing more miscompiles and a revert of it would get us back to the same stability as Clang 16.x, even though it's not actually a "fix" per se. Am I correct? If so, we may want to consider doing that revert from the 17.x branch so we don't introduce more miscompilations and then do the real fix for 18.x with plenty of time for testing fallout.

[spavloff]

I put a patch https://reviews.llvm.org/D158158, which should fix the issue.It is not a full-fledged solution (it does not support variable templates), but it should be enough for this issue. It is small and obvious, hopefully this can facilitate the review.

fde5924 fixes #63542, so revert of it exposes that issue.

[AaronBallman]

fde5924 fixes #63542, so revert of it exposes that issue.

To make sure I'm on the same page -- a revert would bring us back to the Clang 16 behavior (bugs and all)?