Always false float comparisons

[Manu via Digitalmars-d]

On 16 May 2016 at 18:10, Walter Bright via Digitalmars-d
<digitalmars-d at puremagic.com> wrote:
> On 5/15/2016 11:00 PM, Ola Fosheim Grøstad wrote:
>>
>> On Sunday, 15 May 2016 at 22:49:27 UTC, Walter Bright wrote:
>>>
>>> On 5/15/2016 2:06 PM, Ola Fosheim Grøstad wrote:
>>>>
>>>> The net result is that adding const/immutable to a type can change the
>>>> semantics
>>>> of the program entirely at the whim of the compiler implementor.
>>>
>>>
>>> C++ Standard allows the same increased precision, at the whim of the
>>> compiler
>>> implementor, as quoted to you earlier.
>>>
>>> What your particular C++ compiler does is not relevant, as its behavior
>>> is not
>>> required by the Standard.
>>
>>
>> This is a crazy attitude to take. C++ provides means to detect that IEEE
>> floats
>> are being used in the standard library.
>
>
> IEEE floats do not specify precision of intermediate results. A C/C++
> compiler can be fully IEEE compliant and yet legitimately have increased
> precision for intermediate results.
>
> I posted several links here pointing out this behavior in VC++ and g++. If
> your C++ numerics code didn't have a problem with it, it's likely you wrote
> the code in such a way that more accurate answers were not wrong.
>
> FP behavior has complex trade-offs with speed, accuracy, compatibility, and
> size. There are no easy, obvious answers.

I think I might have misunderstood Iain's initial post on the matter.
I understand the links you've posted, but the point I was objecting to
was the moment an assignment is made, truncation must occur.
If you do:
float f()
{
  float x = some_float_expression;
  float y = some_expression_involving_x;
  return some_expression_involving_y;
}

If I run that in CTFE, will assignment to x, y, and the return
statement all truncate intermediate results to float at those moments?
If the answer is yes, I apologise for the confusion.