Bug#906753: GCC's -O2 optimization breaks floating point precision or something else

[Lumin <cdluminate@gmail.com>]

Package: g++-8
Version: 8.2.0-4
Severity: serious
Justification: -O2 results in different double precision number result.
Affects: 906708

This bug is found in package src:hepmc, which currently FTBFS on
i386, arm64, ppc64el and s390x.

https://buildd.debian.org/status/package.php?p=hepmc
 - arm64:
   difference is : 3.55271e-15
 - i386:
   difference is : 1.77636e-15
 - ppc64el:
   difference is : 3.55271e-15
 - s390x:
   difference is : 3.55271e-15

Data Matrix:

 * amd64 architecture
   + GCC-8:
     -O2 : OK
     -O0 : OK
   + Clang-6.0
     -O2 : OK
     -O0 : OK

 * ppc64el architecture
   + GCC-8:
     -O2 : FTBFS because floating point precision beyond tolerance
     -O0 : OK
   + Clang-6.0:
     -O2 : OK
     -O0 : OK

   + GCC-7:
     -O2 : FTBFS

   + GCC-6:
     -O2 : FTBFS

   + GCC-5:
     -O2 : FTBFS

 * i386, arm64, s390x not tested.

 * In testSimpleVector.cc, the expected result of
   v4.m2() and vector.m2() are both 2.4200000000000053 .

 * -O2 and -O0 can be specified in DEB_CXXFLAGS_MAINT_APPEND
 * default compiler can be switched by simply e.g.
   export CC=clang
   export CXX=clang++
   in debian/rules
   
I wanted to trace into testSimpleVector.cc with gdb to find out
what's going wrong. However this bug only occurs with -O2 option
with which gdb cannot trace the C++ code line by line.

Clang-6 doesn't FTBFS with the same compiler flags, so I
consider this bug is an RC bug of GCC.

I totally forgot how to dump the detail about gcc's -O2 option.
Hence I'm not sure if gcc -O2 used something like -ffast-math .