octave-bug-tracker
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Octave-bug-tracker] [bug #65321] C++20 warnings about deprecated uses o


From: John W. Eaton
Subject: [Octave-bug-tracker] [bug #65321] C++20 warnings about deprecated uses of volatile variables
Date: Sat, 17 Feb 2024 15:46:36 -0500 (EST)

Follow-up Comment #7, bug#65321 (group octave):

I found this statement at
https://en.cppreference.com/w/cpp/types/climits/FLT_EVAL_METHOD


Cast and assignment strip away any extraneous range and
precision: this models the action of storing a value from an
extended-precision FPU register into a standard-sized memory
location.


If that is true even if the method of floating point evaluation is
implementation defined, then I agree that the volatile keyword is no longer
needed.

But in the past there was no guarantee that storing a value to a temporary
wouldn't be optimized in some way so that extended precision was preserved. 
Although, as I understand it, this behavior was common on systems with x87
floating point processors, without any language guarantee it could happen (or
not) on any system.  My recollection is also that the GCC option -ffloat-store
prevented such optimizations.

Now, there is another GCC option:


-ffp-contract=style

    -ffp-contract=off disables floating-point expression
contraction. -ffp-contract=fast enables floating-point
expression contraction such as forming of fused multiply-add
operations if the target has native support for them.
-ffp-contract=on enables floating-point expression contraction
if allowed by the language standard. This is implemented for C
and C++, where it enables contraction within one expression, but
not across different statements.

    The default is -ffp-contract=off for C in a standards
compliant mode (-std=c11 or similar), -ffp-contract=fast
otherwise.


So even if extended precision or special instructions are enabled, they can
only apply within a statement and an assigment statement force truncation,
consistent with the info from cppreference.


    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?65321>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/




reply via email to

[Prev in Thread] Current Thread [Next in Thread]