チケット #39715

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

登録: 2019-11-02 23:49 最終更新: 2020-01-18 03:24

報告者:
担当者:
(未割り当て)
チケットの種類:
状況:
完了
コンポーネント:
(未割り当て)
マイルストーン:
(未割り当て)
優先度:
5 - 中
重要度:
5 - 中
解決法:
直さない
ファイル:
1
投票
点数: 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.

チケットの履歴 (4 件中 3 件表示)

2019-11-02 23:49 更新者: colin13on
  • 新しいチケット "Two possible C type double division bugs when compiling with gcc -Ofast" が作成されました
2019-11-13 06:41 更新者: 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 更新者: keith
  • 解決法なし から 直さない に更新されました
  • 状況オープン から 完了 に更新されました

添付ファイルリスト

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

編集

このチケットにコメントを追加するには、ログインが必要です » ログインする