[llvm-dev] Code which should exit 1 is exiting 0

[Sanjay Patel via llvm-dev]

I filed a shorter version of the i7 example here:
https://llvm.org/bugs/show_bug.cgi?id=27825

On Wed, May 4, 2016 at 11:37 PM, Pete Cooper via llvm-dev <
llvm-dev at lists.llvm.org> wrote:

> I was curious about this for integers.  Looks like we have at least one
> bug which is of a similar vein.  Comment out the branch here and the test
> will pass on x86, otherwise it fails.
>
> Note, command line I used was: llc int.ll -o int.s --filetype=asm &&
> clang++ int.s -o main && ./main; echo $?
>
> @g = constant i8 255
> define i32 @main() {
>   %ptr = bitcast i8* @g to i7*
>   %v7 = load i7, i7* %ptr
> ;  br label %cmp
> ; cmp:
>   %add7 = add i7 %v7, 1
>   %icmp = icmp eq i7 %add7, 0
>   br i1 %icmp, label %eq, label %ne
> eq:
>   ret i32 0
> ne:
>   ret i32 1
> }
>
> Pete
>
> On May 4, 2016, at 6:04 PM, via llvm-dev <llvm-dev at lists.llvm.org> wrote:
>
> DAG legalization still runs with -O0.
>
> —escha
>
> On May 4, 2016, at 6:00 PM, Carlos Liam <carlos at aarzee.me> wrote:
>
> Shouldn't that not happen when I run with -O0?
>
>  - CL
>
> On May 4, 2016, at 8:56 PM, escha at apple.com wrote:
>
> I checked the debug log: this is what’s happening.
>
> 1. Because f16 isn’t legal, SINT_TO_FP and FP_TO_SINT get promoted to f32.
> 2. f32 has 24 mantissa bits, which is enough to losslessly represent i16s.
> So the conversion gets eliminated in FoldIntToFPToInt.
>
> Part 1) here looks fairly suspicious.
>
> —escha
>
> On May 4, 2016, at 5:41 PM, John Criswell via llvm-dev <
> llvm-dev at lists.llvm.org> wrote:
>
> On 5/4/16 8:25 PM, Carlos Liam via llvm-dev wrote:
>
> I have IR at https://ghostbin.com/paste/daxv5 which is meant to exit 1,
> but it is always exiting 0.
>
>
> 1) It would help if you pasted the relevant code into your message.
> Paranoid people like me don't following links in emails.
>
> 2) Have you ensured that your program doesn't exercise undefined
> behavior?  If your program has a signed overflow, an out-of-bounds error,
> or some other undefined behavior, the compiler may optimize it in
> surprising and unexpected way.
>
> Regards,
>
> John Criswell
>
> I'm using it as a template for checking if two functions @test1 and @test2
> are equivalent by checking against the exhaustive possible i16 values. For
> this particular example it should be enough to know that for certain i16,
> @test1 and @test2 are *not* equal. When an inequality is found, the program
> should exit 1. However, it seems like it's always exiting 0. Is there
> something I'm doing wrong?
>
>  - CL
>
>
>
> _______________________________________________
> LLVM Developers mailing listllvm-dev at lists.llvm.orghttp://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> --
> John Criswell
> Assistant Professor
> Department of Computer Science, University of Rochesterhttp://www.cs.rochester.edu/u/criswell
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
>
> _______________________________________________
> LLVM Developers mailing list
> llvm-dev at lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20160520/d8a8aa8d/attachment.html>