[LLVMdev] lli vs JIT diffs on FCmp::ne with NaN operands

[Dound]

I am having a little trouble with the fcmp one instruction on doubles only.

For ordered comparisons, the LLVM manual states that true should be returned
iff neither operands is QNAN.  ( http://llvm.org/docs/LangRef.html#i_fcmp)

If I do fcmp one which includes one or both operands as a NaN, the result is
expected to be 0 then.

If I run the bitcode with lli (JIT off), no problem.  If I use the JIT (lli
--force-interpreted=true), then it returns 1.

(Converely, fcmp une with the JIT returns 0 instead of the expected 1 ...
without JIT it returns the expected 0).

The other operators (oeq, oge, ..., ueq, uge, ...) seem to work fine.


Is this a bug with the JIT or have I done to muck this up?  I've included
source below which illustrates the problem (with doubles on fcmp one only
... ).

Thanks for your help.

~ David

declare void @exit(i32)
declare void @llvm.memcpy.i32(i8*, i8*, i32, i32)

; see if (%f1!=%f2) gives the expected result %ne_expected (doubles)
define void @testFCmpOrdered( double %f1, double %f2, i1 %ne_expected ) {
entry:
  %ne_result = fcmp one double %f1, %f2
  %matches = icmp eq i1 %ne_result, %ne_expected
  br i1 %matches, label %return, label %no_match

no_match:
  call void @exit( i32 1 )
  unreachable

return:
  ret void
}

; see if NaN ne comparisons work as expected
define i32 @main() {
entry:
  %x = alloca i64, align 8
  %nan = alloca double, align 8

  ; build NaN
  store i64 -1, i64* %x
  %nan_as_i8 = bitcast double* %nan to i8*
  %x_as_i8 = bitcast i64* %x to i8*
  call void @llvm.memcpy.i32( i8* %nan_as_i8, i8* %x_as_i8, i32 8, i32 8 )

  ; load two copies of our NaN
  %nan1 = load double* %nan
  %nan2 = load double* %nan

  ; compare NaN to 0 (NaN != 0 should return 0)
  call void @testFCmpOrdered( double %nan1, double 0.000000e+00, i1 0 )

  ; compare NaN to itself (NaN != NaN should return 0)
  call void @testFCmpOrdered( double %nan1, double %nan2, i1 0 )

  ret i32 0
}
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20070924/1657c0d6/attachment.html>