[cfe-dev] [llvm-dev] Calling function from non-default floating-point environment

[Cameron McInally via cfe-dev]

Hey Serge,

Before I comment, I should mention that we've discussed this before
and I think the C Standard is frustrating and vague w.r.t. to FPEnv.
We should probably work on tightening up this part of the standard.

Comments inline...

On Tue, Jan 7, 2020 at 1:02 PM Serge Pavlov via llvm-dev
<llvm-dev at lists.llvm.org> wrote:
>
> Hi all,
>
> Implementation of #pragma STDC FENV_ACCESS raises a problem: what to do if a function is called inside a region where FP environment differs from the default?
> If the function expects default FP mode it may work incorrectly in such case.

The standard draft linked below says:

"If part of a program tests floating-point status flags or establishes
non-default floating-point mode settings using any means other than
the FENV_ROUND pragmas, but was translated with the state for the
FENV_ACCESS pragma "off", the behavior is undefined."

I think that covers your question. If the caller sets `FENV_ACCESS=ON`
and the callee is translated with `FENV_ACCESS=OFF`, then the behavior
is undefined.

Otherwise, if the caller sets `FENV_ACCESS=OFF` and the callee is
translated with `FENV_ACCESS=ON`, then there is no danger there since
the callee explicitly manages the FPEnv. I.e.:

"When execution passes from a part of the program translated with
FENV_ACCESS "off" to a part translated with FENV_ACCESS "on", the
state of the floating-point status flags is unspecified and the
floating-point control modes have their default settings." (1)

And, of course, the cases where `FENV_ACCESS` is the same for both
caller and callee are trivial.

> The C2x standard draft (http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2454.pdf) states (7.6p4):
>
> Certain programming conventions support the intended model of use for the dynamic floating-point environment:*)
> — a function call does not alter its caller’s floating-point control modes, clear its caller’s floating point status flags, nor depend on the state of its caller’s floating-point status flags unless the function is so documented;
> — a function call is assumed to require default floating-point control modes, unless its documentation promises otherwise;
> — a function call is assumed to have the potential for raising floating-point exceptions, unless its documentation promises otherwise.
> *) With these conventions, a programmer can safely assume default floating-point control modes (or be unaware of them). The responsibilities associated with accessing the floating-point environment fall on the programmer or program that does so explicitly.
>
>
> It looks like that the standard requires to call functions in default FP mode, so inside a block where #pragma STDC FENV_ACCESS acts, each function call should be converted into sequence:
>  - store FP state,
>  - set default FP state,
>  - call the function,
>  - restore FP state.
> These save/restore instructions could be inserted by compiler. This could be the safest solution but it complicates implementation and may impact performance. There is also another viewpoint: it is user responsibility to provide necessary environment and save/restore operations must be inserted manually.

I think this is overkill, especially the save/restore steps. The only
case that the compiler ***may*** need to reset the default FPEnv state
is the `FENV_ACCESS=ON` case [see (1) above]. It's not clear to me
whether (1) implies that the compiler should explicitly set the
control modes to their default settings OR assumes that the user will
reset the control modes to their default settings. I'd like to hear
other interpretations though. IIRC, the group decided that it was the
user's responsibility to reset the default state.

> Choosing the proper way we need to take into account:
> - generally it is hard for a user to be sure that a function do not depend on FP environment. Functions that apparently do not use FP numbers (like addition to hash table) may actually involve FP operations internally.
> - function inlining occurs in IR level and the chosen solution may potentially affect semantics of other languages (maybe Fortran?).
>
> So the first question is: should the compiler set default FP state prior to function calls?

I'm leaning towards agreeing with Kevin. It's up to the user to manage
the FPEnv state (except maybe at the end of compound statements, which
we punted on). I think the footnote mentioned above is significant:
"The responsibilities associated with accessing the floating-point
environment fall on the programmer or program that does so
explicitly."


Digressing a bit, this clause brings up an interesting (and
controversial) topic:

  — a function call is assumed to have the potential for raising
floating-point exceptions, unless its documentation promises
otherwise.

I read this as we should be compiling system/3rd party libraries, e.g.
libm, in a trap-safe mode. IINM, the current plan is to not do that.