Boost logo

Boost :

Subject: Re: [boost] C++11 compilers and fenv
From: Niall Douglas (s_sourceforge_at_[hidden])
Date: 2015-05-06 05:48:56

On 6 May 2015 at 4:25, Damian Vicino wrote:

> I was planning to access FENV for detecting unsafe operations on the
> native floating point types and include some custom pre-post conditions
> for testing other floating types safety conditions.

The only compiler I've ever known fenv to work right on is MSVC and
ICC. But MSVC's FP support is extremely conservative by default, and
a lot of people needing FP performance use /fp:fast which completely
eliminates fenv.

I just looked up the docs and even MSVC default doesn't enable all of
fenv. For that you need /fp:strict or even /fp:except.

> I just found today that clang++ does not support the pragma to use FENV yet.
> warning: pragma STDC FENV_ACCESS ON is not supported
> Googling a little I found out that neither does gcc.

This doesn't surprise me. fenv is very hard to optimise well. Most FP
users would prefer undefined behaviour than very slow performance. I
would doubt clang nor GCC will ever fully implement fenv due to
insufficient demand.

> How are c++11 boost libraries dealing with these compiler issues?
> I got some options in mind:
> — Implement everything using custom detections, this will work in every compiler, but it will run slower for everyone too.
> — Finding a compiler with the support, implementing the library using the FENV, and assuming compilers will support it when the library is finished and reviewed.
> — Detect somehow the FENV pragma was not processed and have 2 implementations. No idea how to detect something like this.
> Had someone dealt with similar problem already?
> Is there a common approach?

Your mentor will surely advise, however I would recommend that your
library perform bit checks of the floating point values for every
operation. This will turn each single fp opcode into about eight
opcodes, all of which stall the CPU for a good 30 cycles each. But
correctness is more important than speed, and if the programmer is
employing safe_float they surely really need correctness over

I would also examine how ubsan implements its safe float checks to
see if you can lift some ideas.

One x86 specific trick is to reinterpret SSE2 registers as integers
for the bit checks, that way you don't force FP values back into
memory and reload into GP registers every single operation.
Performance might actually be tolerable. I would suspect you'll need
to drop into assembler for that though, and MSVC doesn't permit
inline assembler in x64.

I'd also loop David Bellot into this and ask what he thinks.


ned Productions Limited Consulting

Boost list run by bdawes at, gregod at, cpdaniel at, john at