One test in data.cc crashes Octave 3.1.51

[John W. Eaton]

On 23-Aug-2008, Thomas Treichl wrote:

| John W. Eaton schrieb:
| > On 21-Aug-2008, Thomas Treichl wrote:
| > 
| > | Thanks for the example program, I think we are getting closer. Now I can see (if 
| > | I interpret this correctly) that the log function on my system cannot handle the 
| > | complex type?! This would really be a bad thing
| > 
| > Sorry, that was a mistake on my part.  Try the following instead.  It
| > should at least compile...
| > 
| > 
| >   #include <iostream>
| >   #include <cmath>
| >   #include <complex>
| > 
| >   int
| >   main (void)
| >   {
| >     double inf = 1.0 / 0.0;
| > 
| >     std::complex<double> foo
| >       = std::log (std::complex<double> (0, inf)) / std::log (2);
| > 
| >     std::cout << foo << std::endl;
| > 
| >     return 0;
| >   }
| 
| No problem.
| 
| I compiled the program the same way you did, but I always get the (inf,nan) 
| answer from it on my 32bit i386 system - it doesn't matter which -O level I am 
| using...
| 
|    ~/tmp $ g++ foo.cc
|    ~/tmp $ ./a.out
|    (inf,nan)
|    ~/tmp $ g++ -O foo.cc
|    ~/tmp $ ./a.out
|    (inf,nan)
|    ~/tmp $ g++ -O3 foo.cc
|    ~/tmp $ ./a.out
|    (inf,nan)
| 
| for PPC code running with the code translation backend on my i386 I always get 
| (nan,nan)...
| 
|    ~/tmp $ g++ -arch ppc -isysroot /Developer/SDKs/MacOSX10.3.9.sdk foo.cc
|    ~/tmp $ ./a.out
|    (nan,nan)
|    ~/tmp $ g++ -arch ppc -isysroot /Developer/SDKs/MacOSX10.3.9.sdk -O foo.cc
|    ~/tmp $ ./a.out
|    (nan,nan)
|    ~/tmp $ g++ -arch ppc -isysroot /Developer/SDKs/MacOSX10.3.9.sdk -O3 foo.cc
|    ~/tmp $ ./a.out
|    (nan,nan)
| 
| So both system results are different from the results that you can see on your 
| system. I think that I could need another small portion of help about what I 
| could/should do now.

What version of GCC?

Here is what I see on my system:

  segfault:1> for v in 3.3 4.0 4.1 4.2 4.3 ; do echo $v ; rm -f a.out ; g++-$v foo.cc ; ./a.out ; rm -f a.out ; g++-$v -O foo.cc ; ./a.out ; done
  3.3
  foo.cc: In function `int main()':
  foo.cc:8: warning: division by zero in `1.0e+0 / 0.'
  foo.cc:11: error: call of overloaded `log(int)' is ambiguous
  <internal>:11: error: candidates are: double std::log(double)
  /usr/include/c++/3.3/cmath:411: error:                 float std::log(float)
  /usr/include/c++/3.3/cmath:419: error:                 long double 
     std::log(long double)
  -bash: ./a.out: No such file or directory
  foo.cc: In function `int main()':
  foo.cc:8: warning: division by zero in `1.0e+0 / 0.'
  foo.cc:11: error: call of overloaded `log(int)' is ambiguous
  <internal>:11: error: candidates are: double std::log(double)
  /usr/include/c++/3.3/cmath:411: error:                 float std::log(float)
  /usr/include/c++/3.3/cmath:419: error:                 long double 
     std::log(long double)
  -bash: ./a.out: No such file or directory
  4.0
  foo.cc: In function 'int main()':
  foo.cc:8: warning: division by zero in '1.0e+0 / 0.'
  (inf,nan)
  foo.cc: In function 'int main()':
  foo.cc:8: warning: division by zero in '1.0e+0 / 0.'
  (inf,nan)
  4.1
  foo.cc: In function 'int main()':
  foo.cc:8: warning: division by zero in '1.0e+0 / 0.'
  (inf,nan)
  foo.cc: In function 'int main()':
  foo.cc:8: warning: division by zero in '1.0e+0 / 0.'
  (inf,2.26618)
  4.2
  foo.cc: In function 'int main()':
  foo.cc:8: warning: division by zero in '1.0e+0 / 0.'
  (inf,nan)
  foo.cc: In function 'int main()':
  foo.cc:8: warning: division by zero in '1.0e+0 / 0.'
  (inf,2.26618)
  4.3
  (inf,nan)
  (inf,2.26618)


so it looks like the behavior has changed over time but is still not
quite right as there is a difference depending on whether optimization
is enabled.

My view is (nearly all) compiler or tool bugs are outside the scope of
the Octave project, especially when fixes exist in the form of newer
versions of the tools.  So in this case, I think the thing to do is
upgrade your compiler.  And it would be nice if someone could also
report the apparent bug in GCC.  I don't think it should give
different results depending on the optimization flag.

jwe