[LLVMbugs] [Bug 8241] New: llvm misconverts (uintmax_t)0 to -0.0

[bugzilla-daemon at llvm.org]

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

           Summary: llvm misconverts (uintmax_t)0 to -0.0
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dimitry at andric.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=5535)
 --> (http://llvm.org/bugs/attachment.cgi?id=5535)
Test for fesetround() issue

The following (C99) fesetround() test program sometimes gives an
incorrect result (-0.0000) with clang, at least for the following
platforms:
- x86_64-unknown-freebsd9.0 (i386 works OK)
- (i386|x86_64)-unknown-linux-gnu
- (i386|x86_64)-apple-darwin10 (checked by d0k)

The .ll on x86_64-unknown-freebsd9.0 looks as follows:

; ModuleID = 'clang-fesetround-bug.c'
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple = "x86_64-unknown-linux-gnu"

@.str = private constant [6 x i8] c"%.4f\0A\00"
@max_er = internal global i64 0, align 8

define i32 @main() nounwind {
entry:
  %retval = alloca i32, align 4
  store i32 0, i32* %retval
  %call = call i32 @fesetround(i32 1024) nounwind
  %tmp = volatile load i64* @max_er, align 8
  %conv = uitofp i64 %tmp to double
  %call1 = call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([6 x i8]*
@.str, i32 0, i32 0), double %conv)
  ret i32 0
}

declare i32 @fesetround(i32) nounwind

declare i32 @printf(i8*, ...)

So I am suspecting there may be a problem in the 'uitofp i64' operation?

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