[LLVMbugs] [Bug 1850] New: comparing pointer constants gives surprising results

[bugzilla-daemon at cs.uiuc.edu]

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

           Summary: comparing pointer constants gives surprising results
           Product: libraries
           Version: 2.1
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jay.foad at antixlabs.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1281)
 --> (http://llvm.org/bugs/attachment.cgi?id=1281)
test case

The attached test case is based on gcc.c-torture/execute/20010329-1.c in the
GCC testsuite. If I compile it with "llvm-gcc -O1 -S -emit-llvm pre.c", I get
this:

define i32 @main() {
entry:
        tail call void @abort( )
        unreachable
}

This is a bit surprising, because the test looks like it should obviously pass
(i.e. call exit(0) instead of abort()). You could probably argue that the
results of the pointer comparisons are undefined, because the pointers don't
point into any valid object, but I still think it would be nice if the code
behaved in the obvious way.


I've investigated a bit, and the GCC front end is generating code a bit like
this:

        %x = inttoptr i64 2147483649 to i8* ; 0x80000001
        %x1 = getelementptr i8* %x, i64 2147483648 ; 0x80000000
        %cond = icmp ule i8* %x1, inttoptr (i64 5 to i8*)

It's a bit strange that it adds 0x80000000 to x instead of subtracting it, but
if pointers are 32 bit then the result will be the same.

Then, after -instcombine, this is folded to false, presumably because the
operations have been evaluated using 64-bit arithmetic. So maybe -instcombine
is wrong to assume that pointers are 64 bit.


-- 
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.