<div dir="ltr">Hi all,<br><br>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.<br><br>The C2x standard draft (<a href="http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2454.pdf">http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2454.pdf</a>) states (7.6p4):<br><br><blockquote style="margin:0 0 0 40px;border:none;padding:0px">    Certain programming conventions support the intended model of use for the dynamic floating-point environment:*)<br>       — 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;<br> — a function call is assumed to require default floating-point control modes, unless its documentation promises otherwise;<br>  — a function call is assumed to have the potential for raising floating-point exceptions, unless its documentation promises otherwise.<br>      *) 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.</blockquote>     <br>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:<br> - store FP state,<br> - set default FP state,<br> - call the function,<br> - restore FP state.<br>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.<br><br>Choosing the proper way we need to take into account:<br>- 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.<br>- function inlining occurs in IR level and the chosen solution may potentially affect semantics of other languages (maybe Fortran?).<br><br>So the first question is: should the compiler set default FP state prior to function calls?<br><br>The next question is: should the compiler support some frontend attribute to mark functions that do not require default FP mode? These are functions that:<br>       - do not involve FP operations,<br>       - work correctly in any FP mode,<br>      - expects particular FP mode,<br> - modifies FP mode,<br>   - probably something else.<br>For such functions compiler would not generate save/restore operations. We also could have several attributes if we need to distinguish between these cases.<div><br></div><div><div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature"><br></div><div dir="ltr" class="gmail_signature" data-smartmail="gmail_signature">Thanks,<br>--Serge<br></div></div></div></div>