On 14/02/2020 17:05, Marc Glisse wrote: > On Fri, 14 Feb 2020, Timothy Wrona wrote: > >> Just curious, but why couldn't you decide the rounding mode at compile >> time >> and pass the desired rounding mode as an argument to the compiler? > > Usually we need several different rounding modes in the same program. > Certainly there are some cases where the programmer wants to be careful about rounding modes and exact IEEE behaviour. But I expect that if you asked 100 C or C++ programmers what rounding modes they used, 95 would answer "what's a rounding mode?". And four of the other five would say they have a vague idea that rounding modes can be controlled, but they don't really care about them. Now, I believe it is important that we have standards for floating point behaviour, and deterministic behaviour across platforms and tools. But realistically, it is only relevant for a tiny proportion of programs. The huge majority would be fine - and faster - with "-ffast-math" and as much done at compile time as possible. The C++ standards and compilers have to provide support for people who need deterministic floating point results - but should not do so at the cost in usability or run-time efficiency for other users and other programs. In my (unqualified) opinion, rounding modes could best be handled as part of the type. Then those that want some calculations to round downwards and some to round to the nearest values, can use different types to specify exactly what they want, when they want it. And there could be a "don't care rounding" type for those of us who want the most efficient results. Compiler flags could choose the default type for "float" and "double". This way, the details are clear to the reader, easy to control by the programmer, and obvious to the compiler so that it can optimise (or calculate at compile time). (Ideally, it is the operations, not the types, which should have the rounding mode. But that would quickly get very ugly and inconvenient in code, which a type-based solution would be easy to use.) > The draft of the future C standard does have some pragma that might > help, but seeing how hard it is to find implementations of pragma fenv, > that may be optimistic. >
