Test failures with `--enable-optimize=fast`

[dschwoerer]

I noticed there are some test failures with gcc (GCC) 10.2.1 20201125 (Red Hat 10.2.1-9)

----- integrated/test-initial -----
	Checking minus       : l-2: 0.0000e+00 ... PASS
This should only happen in i686 with an x87 math architecture.
We detected however an x86_64 architecture.
	Checking mixmode     : l-2: 5.5526e-05 ... FAIL
This should only happen in i686 with an x87 math architecture.
We detected however an x86_64 architecture.
	Checking mixmode_seed: l-2: 5.5526e-05 ... FAIL
...
	Checking minus       : l-2: 0.0000e+00 ... PASS
This should only happen in i686 with an x87 math architecture.
We detected however an x86_64 architecture.
	Checking mixmode     : l-2: 5.5526e-05 ... FAIL
This should only happen in i686 with an x87 math architecture.
We detected however an x86_64 architecture.
	Checking mixmode_seed: l-2: 5.5526e-05 ... FAIL
	Checking pi          : l-2: 0.0000e+00 ... PASS


----- unit -----
mesh/data/test_gridfromoptions.cxx:169: Failure
Value of: IsFieldEqual(result, expected_3d)
  Actual: false (Field3D(8, 9, 1; [486]) == 68.805304826052208; Expected: 68.805304826052193)
Expected: true
[  FAILED  ] GridFromOptionsTest.GetField3D (2 ms)
[==========] 1789 tests from 123 test suites ran. (14819 ms total)
[  PASSED  ] 1788 tests.

I think that is somewhat expected as -Ofast:

Disregard strict standards compliance. -Ofast enables all -O3 optimizations. It also enables optimizations that are not valid for all standard-compliant programs. It turns on -ffast-math, -fallow-store-data-races and the Fortran-specific -fstack-arrays, unless -fmax-stack-var-size is specified, and -fno-protect-parens

I am not sure we want to do something about it, just wanted to raise awareness ...

[ZedThree]

Yes, this isn't surprising. We can loosen the tolerance on GridFromOptionsTest.GetField3D, as the errors are very low and we probably don't really care about exact machine precision there.

mixmode is perhaps a bit trickier -- we could loosen the tolerance and maybe also check that the Fourier transform has the spectrum we're expecting.

[dschwoerer]

I guess this can be closed as we are not having the =fast option anymore ...