<html>
    <head>
      <base href="http://llvm.org/bugs/" />
    </head>
    <body><table border="1" cellspacing="0" cellpadding="8">
        <tr>
          <th>Bug ID</th>
          <td><a class="bz_bug_link 
          bz_status_NEW "
   title="NEW --- - fucom pattern with undefined results"
   href="http://llvm.org/bugs/show_bug.cgi?id=18897">18897</a>
          </td>
        </tr>

        <tr>
          <th>Summary</th>
          <td>fucom pattern with undefined results
          </td>
        </tr>

        <tr>
          <th>Product</th>
          <td>libraries
          </td>
        </tr>

        <tr>
          <th>Version</th>
          <td>3.3
          </td>
        </tr>

        <tr>
          <th>Hardware</th>
          <td>PC
          </td>
        </tr>

        <tr>
          <th>OS</th>
          <td>Linux
          </td>
        </tr>

        <tr>
          <th>Status</th>
          <td>NEW
          </td>
        </tr>

        <tr>
          <th>Severity</th>
          <td>normal
          </td>
        </tr>

        <tr>
          <th>Priority</th>
          <td>P
          </td>
        </tr>

        <tr>
          <th>Component</th>
          <td>Backend: X86
          </td>
        </tr>

        <tr>
          <th>Assignee</th>
          <td>unassignedbugs@nondot.org
          </td>
        </tr>

        <tr>
          <th>Reporter</th>
          <td>jonas.maebe@elis.ugent.be
          </td>
        </tr>

        <tr>
          <th>CC</th>
          <td>llvmbugs@cs.uiuc.edu
          </td>
        </tr>

        <tr>
          <th>Classification</th>
          <td>Unclassified
          </td>
        </tr></table>
      <p>
        <div>
        <pre>Created <span class=""><a href="attachment.cgi?id=12087" name="attach_12087" title="Reproducer test case">attachment 12087</a> <a href="attachment.cgi?id=12087&action=edit" title="Reproducer test case">[details]</a></span>
Reproducer test case

When compiling for an architecture that does not support fucomi and friends,
llc generates

fucom   %st(x)
<pop>   %st(x)
fnstsw  %ax

If %st(x) is at the top of the fpu stack, there is no problem because the fucom
is simply changed in fucomp. However, if it's not at the top of the fpu stack,
the the <pop> is changed into "fstp %st(x)" and fstp leaves the fpu status
flags in an undefined state according to the Intel manuals (and also according
to the information encoded in X86InstrFPStack.td).

To reproduce: compile the attached source code (extracted from SPEC2006
libquantum) with clang -march=i486 -O2 -S and search for "fucom" in the
generated code. It will look like this:

        faddp   %st(1)
        fxch    %st(3)
        fucom   %st(3)
        fstp    %st(3)
        fnstsw  %ax
                                        # kill: AX<def> AX<kill> EAX<def>
                                        # kill: AH<def> AH<kill> EAX<kill>
        sahf
        jbe     .LBB0_4

I'm using clang/llvm 3.4, but couldn't select this in the version field. I also
checked the source code of trunk, but did not see any changes to
lib/Target/X86/X86FloatingPoint.cpp that suggest this bug is already fixed.
Afaics, the problem is in FPS::handleCompareFP when it calls
freeStackSlotAfter, in case that one in turn has to call freeStackSlotBefore.

The attachment not a runnable test, and I'm not even sure whether the result
would actually fail because libquantum works fine when compiled with those
parameters even though it contains the invalid code. I only discovered the
problem after our own post-link time optimizer removed the "fucom" as dead code
because it determines that its result is not used (the values read by the
fnstsw, other than C1, are (un)defined by the fstp).</pre>
        </div>
      </p>
      <hr>
      <span>You are receiving this mail because:</span>
      
      <ul>
          <li>You are on the CC list for the bug.</li>
      </ul>
    </body>
</html>