Two possible C type double division bugs when compiling with gcc -Ofast
Using: MinGW GCC compiler: gcc (MinGW.org GCC-8.2.0-5) 8.2.0; Microsoft Windows 7 Professional 64 bit operating system; Lenovo Thinkpad T420 laptop 64 bit computer.
Also tried on: GNU GCC compiler: gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0; Lubuntu 32 bit operating system; Samsung N220 netbook 32 bit computer.
Compiling with gcc: -O0, -O1, -O2, O3, -Os, -Og; the attached code works as intended.
But compiling with gcc -Ofast, it sometimes calculates the wrong "a" or "x". This behaviour seems consistent and reproducible on both the above setups, although the wrong behaviour is slightly different on each setup.
I know essentially nothing about what the "-Ofast" option does, and don't know whether using the "-Ofast" option might be expected to change the way type double division sometimes works, or whether this is something that merits further investigation.
I hope the attached comments and code are reasonably clear, but I am happy to answer questions.
P.S. I intend to attach a file with the C program code, examples of the wrong output, and more information. If I can't manage to attach that file then please let me know of another way of sending it. The file has just under 300 lines, of which 60 lines are the actual code and C preprocessor directives.
I'm not convinced that this is a bug, or that it merits further attention.
I know essentially nothing about what the "-Ofast" option does ...
Perhaps you should research it; the GCC documentation covers it in excruciating detial, with a recurring theme being that it sacrifices accuracy and precision, for faster execution.
By its very nature, floating point is imprecise, and in your case the floor() function truncates an already imprecise result toward negative infinity, throwing away possibly as much as one integer unit, if the imprecision is as little as one least significant floating point bit below the correctly rounded result. When the expected precision in the result is no better than plus or minus one integer unit, I don't think a variation of one integer unit constitutes a reportable bug.