[cfe-dev] Relational operators on pointers

[Eli Friedman]

On Thu, Oct 13, 2011 at 3:47 AM, Stefan Marr
<mailinglists at stefan-marr.de> wrote:
> Hi:
>
> On 13 Oct 2011, at 01:11, Eli Friedman wrote:
>
>> On Wed, Oct 12, 2011 at 3:13 PM, Stefan Marr
>> <mailinglists at stefan-marr.de> wrote:
>>> Hi:
>>>
>>> On 12 Oct 2011, at 23:54, David Chisnall wrote:
>>>
>>>> So, if you want to do a comparison between two unrelated pointers as unsigned values, the safest thing to do is cast them to uintptr_t and then do the comparison.
>>>
>>> Right, done, and failed. In this particular case, as Eli pointed out, some optimization is applied.
>>
>> We shouldn't be messing with integer comparisons...
>
> I would guess, the transformation implied by assuming certain allocation behavior comes first, and then leaves nothing for the casts to do their thing.

Oh, right, we make assumptions about the result of the pointer
arithmetic.  Again, -fwrapv should suppress those assumptions and make
everything work.

-Eli

> I attached a smaller self-contained test-case.
>
> Executed with:
> $ /usr/bin/clang++ -m32 -Wextra -Wno-write-strings -fdiagnostics-show-option -Wno-unused-variable -Wno-unused-value -fno-rtti  -O4 bug-report.cpp -o bug-report.bin ; ./bug-report.bin
>
> Results in the output:
> beginning should be before the ends
>
> Expected output:
> done
>
> The 'incorrect' output is consistently issued by binaries compiled by all compilers listed below, except of i686-apple-darwin10-g++-4.2.1.
> And similar, -O0 does produce the correct output, too.
>
> Adding casts like this:
>
> if ((uintptr_t)read_write_memory_base >= (uintptr_t)read_write_memory_past_end) {
>  printf("beginning should be before the end\n");
>  exit(-1);
> }
>
> if ((uintptr_t)read_mostly_memory_base >= (uintptr_t)read_write_memory_past_end) {
>
> does not change the results: incorrect behavior for llvm-gcc, clang 2.9 and 3.0.
>
>
>>
>>> All my casting to what ever type, and with whatever mechanism, did not help.
>>> Not even using temp variables of 64bit types with which ever signage.
>>> That all got just optimized away...
>>> Leaving me with a failing test without apparent reason.
>>
>> What version of clang are you using?
>
> $ /usr/bin/clang++ --version
> Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
> Target: x86_64-apple-darwin10.8.0
> Thread model: posix
>
> $ /opt/local/bin/clang++ --version
> clang version 2.9 (tags/RELEASE_29/final)
> Target: x86_64-apple-darwin10
> Thread model: posix
>
> $ /usr/bin/llvm-g++-4.2 --version
> i686-apple-darwin10-llvm-g++-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.1.00)
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
> $ g++-4.2 --version
> i686-apple-darwin10-g++-4.2.1 (GCC) 4.2.1 (Apple Inc. build 5666) (dot 3)
> Copyright (C) 2007 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
>
>
> Side note:
> For llvm-g++-4.2 I had to use -O3 instead of -O4 because it aborted with the following error:
>
> ld: lto: could not merge in /var/folders/In/InPYSzVvHvGU0ndnO3LOyU+++TI/-Tmp-//cc9rOCdg.o because Unknown instruction for architecture i386
> collect2: ld returned 1 exit status
> -bash: ./bug-report.bin: No such file or directory
>
>
> Best regards
> Stefan
>
>
>
>
>
>
>