Is FENV_ACCESS pragma somehow implied to be defined in C++ the same way as it is in C?

[b7.10...@gmail.com]

n4567 defines <cfenv> contents in 26.3.1, saying that the header defines all functions, types, and macros the same as Clause 7.6 of the C standard. But in the C standard there's a follow-up clause 7.6.1, which describes the FENV_ACCESS pragma and says that if the program tests floating-point status flags, sets FP control modes or runs under non-default mode settings, but was translated with the state for the FENV_ACCESS pragma "off", the behavior is undefined.

At the same time, FENV_ACCESS appears to be unmentioned in the C++ standard draft. Does this mean any of the following:

a) According to the C++ standard, a program is to behave as if FENV_ACCESS state is always "on"

b) FENV_ACCESS pragma is implicitly defined the same way as in the C standard

c) Using <cfenv> is broken and always leads to undefined behavior in C++

?

[Richard Smith]

On Fri, Mar 25, 2016 at 9:01 AM, <b7.10...@gmail.com> wrote:
> n4567 defines <cfenv> contents in 26.3.1, saying that the header defines all
> functions, types, and macros the same as Clause 7.6 of the C standard. But
> in the C standard there's a follow-up clause 7.6.1, which describes the
> FENV_ACCESS pragma and says that if the program tests floating-point status
> flags, sets FP control modes or runs under non-default mode settings, but
> was translated with the state for the FENV_ACCESS pragma "off", the behavior
> is undefined.
> At the same time, FENV_ACCESS appears to be unmentioned in the C++ standard
> draft. Does this mean any of the following:
>
> a) According to the C++ standard, a program is to behave as if FENV_ACCESS
> state is always "on"

No, there is no such implication.

> b) FENV_ACCESS pragma is implicitly defined the same way as in the C
> standard

No.

> c) Using <cfenv> is broken and always leads to undefined behavior in C++

Pretty much. But if your implementation happens to support #pragma
STDC FENV_ACCESS in C++, then it would not be unreasonable to expect
it to work.

Note that C++ does not even define the underlying notions on which
<fenv.h> is based (C++'s specification for floating point types is
incredibly weak compared to C's). Also, the interaction of floating
point constant expression evaluation and FENV_ACCESS would need to be
specified in order for <cfenv> to be meaningful in C++.

[b7.10...@gmail.com]

Thanks for your answer. Do you know of any existing attempts to improve this? Is there actually any chance that this could be improved in a future revision, or has it been left in current state intentionally?

[Jens Maurer]

On 03/26/2016 03:03 PM, b7.10...@gmail.com wrote:
> Thanks for your answer. Do you know of any existing attempts to improve this? Is there actually any chance that this could be improved in a future revision, or has it been left in current state intentionally?

Nobody has bothered enough about floating-point on the C++ standards level
to do something about it.

Personally, I'd expect an uphill battle to get something like <fenv.h>
supported in C++ without a more C++-like interface in addition to the
interface exposed by <fenv.h>. (Case in point: the Array TS.)
In particular, the whole idea of "state words" and "status flags" is
so incompatible with out-of-order execution, SIMD-style vectorization,
and implicit threads (see Parallelism TS) that I'd rather see C++
not say anything about the topic than enshrine a '90ies view on FP.

Jens