#1534: Bug in complex numbers -----------------------+---------------------------------------------------- Reporter: eschnett | Owner: Type: defect | Status: new Priority: critical | Milestone: Component: Cactus | Version: development version Resolution: | Keywords: -----------------------+----------------------------------------------------
Comment (by rhaas):
Reading the bug report this seems to be only an issue for return values. The bug report states that even std::complex<double> is fine *in memory* ie std::complex<double> must look the same as _Complex double in memory. The only functions we have that returns a CCTK_COMPLEX are the CCTK_CmplxAdd etc functions. Since we now require C99 all of our supported languages (C, C++, F77, F90) support a complex type natively to do algebra with. So it seems feasible that we can make things standards conforming by removing the CCTK_CmplxAdd etc. functions which are no longer required since the users can just use the language provided functionality instead. For backwards compatibility we can provide macro versions of the routines in cctk_Math.h or similar (or inline functions returning CCTK_COMPLEX for C/C++). I actually do run the Cactus test suites on a 32bit (virtual) machine. The failing tests (current trunk) are (using gcc/gfortran): {{{ waveinterp-2p (from CarpetInterp) test_o9 (from CarpetProlongateTest) Schwarzschild_EF (from Exact) test_tov_carpet_refined_nosync (from GRHydro) tov_slowsector (from GRHydro) test_axibrill_nostagger (from IDAxiBrillBH) test_simpson (from Multipole) regression_test (from SphericalHarmonicRecon) }}} SphericalHarmonicRecon in PITTNull uses complex numbers. PITTNull itself is in Fortran so probably fine, MoL does the update and is in C so *should* be fine as well. There seems to be no C++ code using complex numbers in the tests. Slab uses complex numbers but the test does not use Slab. Both SphericalHarmonicReconGen and SphericalSlice do use them and are in C++, neither one is in the ET yet.
There are two reasons I can see for the SphericalHarmonicRecon test failing: 1. complex return values are handled differently in C and Fortran after all (different from what is stated in the link above) 2. 32bit machines by default compile for the i387 coprocessor which always uses 80bit long double precision in its registers (well almost always) while 64bit machines use sse2 which uses only 64bit double precision it its registers. One can test this by recompiling the code (assuming gcc) using -mfpmath=sse
I am testing patch for the flesh that replaces the complex algebra routines by inline function calls which should remove the problem of possibly differing return value representations and will report back on the results using the patch alone and using -mfpmath=sse.