[llvm-bugs] [Bug 32014] New: Wrongly suspected UB possibly during FP optimization causing miscompilation at O1

[via llvm-bugs]

https://bugs.llvm.org/show_bug.cgi?id=32014

            Bug ID: 32014
           Summary: Wrongly suspected UB possibly during FP optimization
                    causing miscompilation at O1
           Product: clang
           Version: 3.9
          Hardware: PC
                OS: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
          Assignee: unassignedclangbugs at nondot.org
          Reporter: fh.faraz.hussain at gmail.com
                CC: llvm-bugs at lists.llvm.org

Created attachment 18010
  --> https://bugs.llvm.org/attachment.cgi?id=18010&action=edit
Test case of clang miscompilation at O1

Summary: In pb1fh.c, g_113[0] should have value 1.000000 when the program ends.
This is exactly what clang prints at both O0 and O2. At O1, however, clang
prints 257.000000, which is wrong.


Analysis: The outer for loop ends with p_62 equals 2, which means the last
value of *l_112 is 1. l_112 points to g_113[0]. Hence, the last value of g_113
should be 1. 

The inner for-loop seems to be the one that's confusing the optimizer at O1.
This loop never gets executed because g_107 is 0. Perhaps the O1 optimization
algorithm suspects there's some undefined behavior (UB) due to the inner for
loop, and therefore messes up. Of course, there's no UB there because g_107 is
0.  Interestingly, O2 gets it right, likely due to more global and detailed
analysis. 

Adding assert(g_107 == 0) before the inner for-loop removes the problem. 

Independently of the assert, making g_113 and l_112 ints also removes this
problem.

-- 
You are receiving this mail because:
You are on the CC list for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-bugs/attachments/20170220/3c1b58c3/attachment.html>