octave-maintainers
[Top][All Lists]
Advanced

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

Re: a < b for complex numbers on MinGW


From: Rik
Subject: Re: a < b for complex numbers on MinGW
Date: Wed, 13 Nov 2013 15:40:11 -0800

On 11/13/2013 03:12 PM, Michael Goffioul wrote:
On Wed, Nov 13, 2013 at 4:03 PM, Rik <address@hidden> wrote:
Good news on this bug.  Apparently we had already encountered it 4 years
ago
(http://thread.gmane.org/gmane.comp.gnu.octave.bugs/12361/focus=12404).
The root cause is that intermediate math results can sometimes be stored in
machine registers that exceed the mandated IEEE 64 bits.  Most of the time
this is fine, even good so numbers don't under/over flow, but occasionally
it causes problems as in this case.  We already have a configure option,
--enable-float-truncate, which declares the variables used for complex
comparisons as volatile so they get truncated to IEEE width.  I re-built
with this flag thrown and now MinGW is passing both the quadgk test and the
sort test which were failing.

Remaining question is where should we enable this flag?  We could detect
the vulnerable systems (MinGW and Cygwin) in Octave's configure script and
automatically set the option.  We could also put it in the mxe-octave build
script octave.mk.  The disadvantage of the latter is that some people may
get the tarball and be doing native builds without mxe and thus miss
setting this flag.

Seriously, do you really think a MinGW build is possible outside MXE without a lot of pain and sweat? Personally, I'd simply put it into octave.mk in MXE.

I agree, probably not much cause for it.  Still, it was easy enough so I modified configure.ac (http://hg.savannah.gnu.org/hgweb/octave/rev/82f096e1a805).  If the user specifies the option (either --enable or --disable) then they get that result.  If they don't specify anything then configure looks at the host_os to determine whether it is MinGW or Cygwin and sets the truncation flag if necessary.  Thus, if someone is a masochist they can use --disable-float-truncate on their native build system and get a potentially slightly faster, potentially buggy executable (I'm not going to stop them, even though I don't think it's a good idea).

--Rik


reply via email to

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