Ticket #39715

Two possible C type double division bugs when compiling with gcc -Ofast

Open Date: 2019-11-02 23:49 Last Update: 2020-01-18 03:24

5 - Medium
5 - Medium
Won't Fix
Score: 0
No votes
0.0% (0/0)
0.0% (0/0)


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.

Colin Bartlett

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.

Ticket History (3/4 Histories)

2019-11-02 23:49 Updated by: colin13on
  • New Ticket "Two possible C type double division bugs when compiling with gcc -Ofast" created
2019-11-13 06:41 Updated by: keith

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.

2020-01-18 03:24 Updated by: keith
  • Resolution Update from None to Won't Fix
  • Status Update from Open to Closed

Attachment File List

  • qdoublebug.c(12KB)
    • Comments on and explanation of the possible two bugs, with the code producing the possible bugs.


Please login to add comment to this ticket » Login