[Octave-bug-tracker] [bug #40560] a < b incorrect for complex numbers on MinGW

[Rik]

Follow-up Comment #2, bug #40560 (project octave):

What about compiling with either of these two options from gcc which limit the
precision of math results to IEEE standards?  It might be easier to throw a
compile flag, so we know we get the correct behavior everywhere, rather than
the only place we've seen a problem which is with Complex numbers.


-ffloat-store
 Do not store floating point variables in registers, and inhibit other options
that might change whether a floating point value is taken from a register or
memory. 

 This option prevents undesirable excess precision on machines such as the
68000 where the floating registers (of the 68881) keep more precision than a
"double" is supposed to have. Similarly for the x86 architecture. For most
programs, the excess precision does only good, but a few programs rely on the
precise definition of IEEE floating point. Use -ffloat-store for such
programs, after modifying them to store all pertinent intermediate
computations into variables. 
-fexcess-precision=style
 This option allows further control over excess precision on machines where
floating-point registers have more precision than the IEEE "float" and
"double" types and the processor does not support operations rounding to those
types. By default, -fexcess-precision=fast is in effect; this means that
operations are carried out in the precision of the registers and that it is
unpredictable when rounding to the types specified in the source code takes
place. When compiling C, if -fexcess-precision=standard is specified then
excess precision will follow the rules specified in ISO C99; in particular,
both casts and assignments cause values to be rounded to their semantic types
(whereas -ffloat-store only affects assignments). This option is enabled by
default for C if a strict conformance option such as -std=c99 is used. 

 -fexcess-precision=standard is not implemented for languages other than C,
and has no effect if -funsafe-math-optimizations or -ffast-math is specified.
On the x86, it also has no effect if -mfpmath=sse or -mfpmath=sse+387 is
specified; in the former case, IEEE semantics apply without excess precision,
and in the latter, rounding is unpredictable.



    _______________________________________________________

Reply to this item at:

  <http://savannah.gnu.org/bugs/?40560>

_______________________________________________
  Message sent via/by Savannah
  http://savannah.gnu.org/