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

[Carlos Liam via llvm-dev]

I have IR at https://ghostbin.com/paste/daxv5 which is meant to exit 1, but it is always exiting 0.

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

[via llvm-dev]

How are you compiling it? For which target?

—escha

[Carlos Liam via llvm-dev]

I'm using lli, on x86-64.

 - CL

[John Criswell via llvm-dev]

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 list
llvm...@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev

-- 
John Criswell
Assistant Professor
Department of Computer Science, University of Rochester
http://www.cs.rochester.edu/u/criswell

[via llvm-dev]

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

[via llvm-dev]

DAG legalization still runs with -O0.

—escha

On May 4, 2016, at 6:00 PM, Carlos Liam <car...@aarzee.me> wrote:

Shouldn't that not happen when I run with -O0?

 - CL

[Pete Cooper via llvm-dev]

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

[Sanjay Patel via llvm-dev]

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