failed checks for mingw32 build in octave 3.0.0/3.0.1

[Benjamin Lindner]

Hello,

as correctly pointed out by Tatsuro on the forge mailing list, I move 
discussion of the mingw32 build here.

I have the following 3 failing tests for 3.0.0 and 3.0.1:

in ov-fcn-handle.cc
  ***** test
 a = 2;
 f = @(x) a + x;
 g = @(x) 2 * x;
 h = @log2;
 f2 = f;
 g2 = g;
 h2 = h;
 nm = tmpnam();
 unwind_protect
   save ("-text", nm, "f2", "g2", "h2");
   clear f2 g2 h2
   load (nm);
   assert (f(2),f2(2));
   assert (g(2),g2(2));
   assert (g(3),g2(3));
   unlink (nm);
   save ("-text", nm, "f2", "g2", "h2");
 unwind_protect_cleanup
   unlink (nm);
 end_unwind_protect
!!!!! test failed
error: function handle points to non-existent function



in bitcmp.m:
!!!!! test failed
error: assert (bitcmp (A, Amax),bitor (bitshift (1, Amax - 1), bitshift 
(1, Amax - 2))) expected
 6.7554e+15
but got
 1.1259e+16
values do not match
shared variables {
  Amax =  53
  Bmax =  9.0072e+15
  A =  2.2518e+15
}


and in test_arith.m
  ***** test
 x = [pi/2*i, 3*pi/2*i];
 v = [0, 0];
 assert(all (abs (coth (x) - v) < sqrt (eps)));
!!!!! test failed
error: assert (all (abs (coth (x) - v) < sqrt (eps))) failed


I don't understand any of these failures.
Taking the first.
Doing the following
  octave>f=@(x) x*2
  octave>save -text test.mat.txt f
yields the following saved file
  # Created by Octave 3.0.0, Sat Aug 09 21:08:34 2008 W. Europe 
Daylight Time <address@hidden>
  # name: f
  # type: function handle
  @<anonymous>
  @(x) x * 2

Trying to load it gives the error
octave> load test.mat.txt
error: function handle points to non-existent function
error: load: trouble reading ascii file `test.mat.txt'
error: load: reading file test.mat.txt

I have not debugged into it yet.


The second one, I don't understand what is tested here. This looks like 
bitshifting of floating point numbers.  Hmm, what is the background of 
this?


The third one baffles me, but I suspect it's a gcc bug.
I used the following test C++ program:

#include <iostream>
#include <complex>

int main()
{
   std::complex<double> c(0,M_PI_2);
   std::complex<double> cthc(0,0);
   std::complex<double> tanhc(0,0);
   std::complex<double> sinhc(0,0);
   std::complex<double> coshc(0,0);

   sinhc = std::sinh(c);
   coshc = std::cosh(c);
   tanhc = std::tanh(c);
   cthc = 1.0/tanhc;

   std::cout << " c = " << c << "\n";
   std::cout << " sinh(c) = " << sinhc << "\n";
   std::cout << " cosh(c) = " << coshc << "\n";
   std::cout << " tanh(c) =" << tanhc << "\n";
   std::cout << " ctanh(c) = " <<  cthc << "\n";

   return 0;
}

and compiled it using:
g++-3.4.2 (mingw)
g++-3.4.5 (mingw)
g++-4.2.1 (mingw)
g++-4.3.0-2 (TDM's mingw binary)
g++-4.3.1-1 (TDM's mingw binary)

and got

T:\>test-3.4.2.exe
 c = (0,1.5708)
 sinh(c) = (0,1)
 cosh(c) = (6.12303e-017,0)
 tanh(c) =(0,1.63318e+016)
 ctanh(c) = (0,-6.12303e-017)

T:\>test-3.4.5.exe
 c = (0,1.5708)
 sinh(c) = (0,1)
 cosh(c) = (6.12303e-017,0)
 tanh(c) =(0,1.63318e+016)
 ctanh(c) = (0,-6.12303e-017)

T:\>test-4.2.1.exe
 c = (0,1.5708)
 sinh(c) = (0,1)
 cosh(c) = (6.12303e-17,0)
 tanh(c) =(Infinity,Infinity)
 ctanh(c) = (NaN,NaN)

T:\>test-4.3.0-2.exe
 c = (0,1.5708)
 sinh(c) = (0,1)
 cosh(c) = (6.12303e-017,0)
 tanh(c) =(0,1.63318e+016)
 ctanh(c) = (0,-6.12303e-017)

T:\>test-4.3.1-1.exe
 c = (0,1.5708)
 sinh(c) = (0,1)
 cosh(c) = (6.12303e-017,0)
 tanh(c) =(0,1.63318e+016)
 ctanh(c) = (0,-6.12303e-017)

so it yields correct results, except for the gcc-4.2.1. And this I used 
for building octave. Yes, you always pick the wrong one, it's murphy's 
law...

I don't know if the bitcmp.m fail could also be a gcc bug, the anonymus 
function handle failure does not look like a gcc bug to me.

I will need to build using a different gcc to tell.

benjamin