[LLVMbugs] [Bug 13507] New: Miscompiled one-past-the-end pointer comparison

bugzilla-daemon at llvm.org bugzilla-daemon at llvm.org
Wed Aug 1 14:56:20 PDT 2012


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

             Bug #: 13507
           Summary: Miscompiled one-past-the-end pointer comparison
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: tomasz.miasko at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


$ cat opte.C 
#include <stdio.h>

const int size = 4;
int a[size];
int b[size];

int main() {
    if (a + size == b)
        puts("1");

    int *aEnd = a + size;
    if (aEnd == b)
        puts("2");

    printf("%p\n%p\n", (void*) aEnd, (void*) b);

    return 0;
}
$ clang++ -v 
clang version 3.2 (trunk 161130) (llvm/trunk 160639)
Target: x86_64-unknown-linux-gnu
Thread model: posix
$ clang++ opte.C 
$ ./a.out 
2
0x601050
0x601050


I would expect both conditions to be true iff "b" happens to be
located just after "a". Instead, when using default optimization
level, results of pointer comparisons are inconsistent (first
one is optimized out).

This seems to be the result of assumption that pointers are equal
if and only if they share the same base and offset in constant
folding code for C/C++ expressions (but not necessarily the only
cause).


C++03 defines pointer equality in 5.10.1 as follows: 

The == (equal to) and the != (not equal to) operators have the
same semantic restrictions, conversions, and result type as the
relational operators except for their lower precedence and
truth-value result. [Note: a<b == c<d is true whenever a<b and
c<d have the same truth-value. ] Pointers to objects or functions
of the same type (after pointer conversions) can be compared for
equality. Two pointers of the same type compare equal if and only
if they are both null, both point to the same function, or both
represent the same address (3.9.2).

And then in 3.9.2.3 one past the end address is explicitly mentioned:

If an object of type T is located at an address A, a pointer of
type cv T* whose value is the address A is said to point to that
object, regardless of how the value was obtained. [Note: for
instance, the address one past the end of an array (5.7) would be
considered to point to an unrelated object of the array’s element
type that might be located at that address. ]

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



More information about the llvm-bugs mailing list