[LLVMbugs] [Bug 3179] New: Code generator incorrectly reordering (or losing) stores

[bugzilla-daemon at cs.uiuc.edu]

http://llvm.org/bugs/show_bug.cgi?id=3179

           Summary: Code generator incorrectly reordering (or losing) stores
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: csdavec at swan.ac.uk
                CC: llvmbugs at cs.uiuc.edu


The attached fail.ll demonstrates the problem in the
@"._objc_method_SmalltalkTool()-run" function.  This is called with two
arguments, the first is a pointer to an object and the second is a selector. 
The selector is unused, the object is a structure containing a  pointer to a
class and a pointer to an object.

At line 959, this argument is stored in an alloca.
At line 960, the alloca is loaded again, into %3.
At line 966, a GEP is used to calculate an offset 4 bytes from the pointer (the
second element in the structure), and this is assigned to %7.
At line 967, this is bitcast to an i8** and assigned %ivar.
At line 979, a value is stored at the address pointed to by %ivar.
At line 980, the value of the argument is once again loaded from the alloca.
At line 985, this is passed to a function.

The function to which it is passed logs the two words after the pointer address
to the terminal; the second word is always 0 (the value from before the
function was entered), in spite of a non-zero value being assigned to it.  In
this example, the store does not appear to ever complete - inspecting the
pointer's target after the return from this function shows the same thing -
that the store has not completed.  

I believe the other functions in this file can be ignored - I have left them in
because this issue has a habit of disappearing seemingly at random.  Adding
other code after the existing code sometimes result the store being committed,
then adding more will sometimes result in it not being committed again.  

This has been tested by me on FreeBSD/x86 and replicated by two others on
Linux/x86.  If the IR is not saying what I think it's saying, please let me
know, otherwise please let me know if I can be of further assistance with test
cases.  Duplicating the last message send (the call to objc_msg_lookup() and
then the call to the returned function) n times results in some bizarre
behaviour.  The value is correctly stored most of the time, however it fails
when 3, 7, 11, or 15 message sends are entered in the function.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.