Floating point rounding modes: we should restrict them slightly

[Don]

Stewart Gordon wrote:
> Don wrote:
> <snip>
>>> Floating point settings are just another case of the same thing, 
>>> except that currently violations in relation to the former are allowed.
>>
>> There's a fundamental difference between them: the floating point 
>> settings are a hardware feature and it is IMPOSSIBLE to avoid them.
> 
> Actually, you _can_ avoid changing the floating point settings in the 
> course of an average program.  But still....

The hardware dependency is still there, in every function which uses 
floating point. And the compiler must assume that dependency.

> 
>> You can choose not to use locale settings. Or, you can pass them as a 
>> parameter, which doesn't work for floating point settings.
> 
> As long as it's the built-in arithmetic operators you're concerned 
> about.  

Of course. There's nothing else to floating point, other than the 
built-in operators. And this is the problem with unconstrained rounding 
modes: they influence EVERYTHING.

>But that said, wrapping every arithmetic operation in a function 
> to purify it of dependence on floating point settings wouldn't be ideal.

It's worse than that. Every function which might call a function which 
might use floating point would have to pass the parameter. It doesn't work.

>> Please do not get sidetracked on pure functions, it is orthogonal to 
>> this issue.
> 
> I'm not sure about this.  ISTM arithmetic operators are essentially pure 
> functions, and so the compiler may treat them as such.

No, they always depend on the FP settings, and assuming they are pure 
functions is not permitted in C, C++, or D. C allows the rounding mode 
to change at any time.

This proposal:
Rounding mode changes must only affect callees, not callers.

The pure function memoisation issue:
Certain functions may be marked as 'pure', even though they use floating 
point (and are therefore dependent on the FP state). The compiler must 
be able to prevent memoisation of those functions in cases where the 
rounding mode may have changed. (Or, equivalently, the memoisation must 
include the FP state).

I've provided very simple solutions for both of these. I'm getting 
pretty irritated that people are acting as though these are difficult 
problems and trying to come up with convoluted solutions. Impose minimal 
semantics and it becomes trivial.