LLVM 3.6 giving incorrectly signed zeros #10377

simonbyrne · 2015-03-02T16:13:22Z

Using LLVM 3.6, branches involving comparison to zero can sometimes return the incorrect sign.

This has come up in #9336 (comment) and #9880 (comment).

Here is a minimal example:

julia> versioninfo()
Julia Version 0.4.0-dev+3639
Commit 7f7e9ae (2015-03-01 22:49 UTC)
Platform Info:
  System: Linux (x86_64-linux-gnu)
  CPU: Intel(R) Xeon(R) CPU E7- 8850  @ 2.00GHz
  WORD_SIZE: 64
  BLAS: libopenblas (USE64BITINT DYNAMIC_ARCH NO_AFFINITY Nehalem)
  LAPACK: libopenblas
  LIBM: libopenlibm
  LLVM: libLLVM-3.6.0

julia> function foo(x,y)
           if x==y==0
               return y
           end
           y+1
       end
foo (generic function with 1 method)

julia> foo(0.0,-0.0)
0.0

And the @code_llvm foo(0.0,-0.0):

define double @julia_foo_42667(double, double) {
top:
  call void @llvm.dbg.value(metadata double %0, i64 0, metadata !10, metadata !16)
  call void @llvm.dbg.value(metadata double %1, i64 0, metadata !17, metadata !16)
  %2 = fcmp une double %0, %1, !dbg !18
  br i1 %2, label %L3, label %L1, !dbg !18

L1:                                               ; preds = %top
  call void @llvm.dbg.value(metadata double 0.000000e+00, i64 0, metadata !20, metadata !16)
  %phitmp = fcmp une double %0, 0.000000e+00, !dbg !18
  br i1 %phitmp, label %L3, label %if2, !dbg !18

if2:                                              ; preds = %L1
  ret double %0, !dbg !21

L3:                                               ; preds = %top, %L1
  %3 = fadd double %1, 1.000000e+00, !dbg !22
  ret double %3, !dbg !22
}

The problem here is that the if2 label it is returning %0 instead of %1.

The text was updated successfully, but these errors were encountered:

ViralBShah · 2015-03-02T18:13:44Z

Should we have a label for llvm bugs?

tkelman · 2015-03-02T21:29:57Z

We can probably rename the "fixed in LLVM 3.5" label to be a general "LLVM issue" instead... or just keep using "upstream" where it's usually pretty clear which upstream is being referred to.

simonbyrne · 2015-03-03T14:21:41Z

BTW, I haven't filed an upstream issue, as I wasn't really sure where the problem lay. Could someone who understands more about the internals help me out?

JeffBezanson · 2015-03-03T17:25:34Z

"fixed in LLVM 3.5" is actually a pretty useful label since we'll know exactly which issues to confirm and close when we upgrade LLVM.

tkelman · 2015-03-03T19:13:42Z

"fixed in LLVM 3.5" is actually a pretty useful label since we'll know exactly which issues to confirm and close when we upgrade LLVM

True, but we can re-appropriate it after that's done. Either "fixed in LLVM 3.7" or something else.

kmsquire · 2015-03-03T21:21:39Z

Or just add a new label.

tkelman · 2015-03-06T01:00:05Z

BTW, I haven't filed an upstream issue, as I wasn't really sure where the problem lay. Could someone who understands more about the internals help me out?

I don't really understand the internals very well, but I think the way to communicate these things upstream would be to try to create a standalone .ll file with IR that returns incorrect results on 3.6.0 but correct on 3.5.1?

simonbyrne · 2015-03-06T08:32:10Z

The problem is that the generated LLVM IR is incorrect (see above), so I'm not sure where the actual problem lies.

tkelman · 2015-03-06T09:09:30Z

~~Hm, then the upstream label is probably wrong.~~

mbauman · 2015-03-06T13:54:42Z

Isn't it just likely to be an LLVM optimization pass bug? Perhaps try disabling all the optimizations and see if it persists.

simonbyrne · 2015-03-06T16:03:13Z

Looking at the debug info, here's the two optimisation passes between which the wrong value gets returned:

*** IR Dump After Combine redundant instructions ***
; Function Attrs: sspreq
define double @julia_foo_64477(double, double) #0 {
top:
  call void @llvm.dbg.value(metadata double %0, i64 0, metadata !10, metadata !16)
  call void @llvm.dbg.value(metadata double %1, i64 0, metadata !17, metadata !16)
  %2 = fcmp une double %0, %1, !dbg !18
  br i1 %2, label %L3, label %L1, !dbg !18

L1:                                               ; preds = %top
  call void @llvm.dbg.value(metadata double 0.000000e+00, i64 0, metadata !20, metadata !16)
  %phitmp = fcmp une double %1, 0.000000e+00, !dbg !18
  br i1 %phitmp, label %L3, label %if2, !dbg !18

if2:                                              ; preds = %L1
  ret double %1, !dbg !21

L3:                                               ; preds = %top, %L1
  %3 = fadd double %1, 1.000000e+00, !dbg !22
  ret double %3, !dbg !22
}
*** IR Dump After Global Value Numbering ***
; Function Attrs: sspreq
define double @julia_foo_64477(double, double) #0 {
top:
  call void @llvm.dbg.value(metadata double %0, i64 0, metadata !10, metadata !16)
  call void @llvm.dbg.value(metadata double %1, i64 0, metadata !17, metadata !16)
  %2 = fcmp une double %0, %1, !dbg !18
  br i1 %2, label %L3, label %L1, !dbg !18

L1:                                               ; preds = %top
  call void @llvm.dbg.value(metadata double 0.000000e+00, i64 0, metadata !20, metadata !16)
  %phitmp = fcmp une double %0, 0.000000e+00, !dbg !18
  br i1 %phitmp, label %L3, label %if2, !dbg !18

if2:                                              ; preds = %L1
  ret double %0, !dbg !21

L3:                                               ; preds = %top, %L1
  %3 = fadd double %1, 1.000000e+00, !dbg !22
  ret double %3, !dbg !22
}

simonbyrne · 2015-03-06T16:27:28Z

Bug report opened here: LLVM #22823.

simonbyrne · 2015-03-06T20:47:33Z

So it looks like it has been patched in svn (http://reviews.llvm.org/rL230564), but it just missed out on 3.6. Does this mean we need a "fixed in LLVM 3.7" tag?

nalimilan · 2015-03-06T20:51:24Z

Or hopefully "to be fixed in LLVM 3.6.1"?

tkelman · 2015-03-06T20:52:21Z

Ask in the bug thread / mailing list if the fix can be a candidate for backporting for 3.6.1.

edit: looks like you already did, great - see http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/082945.html for the patch release plans. We could try making a local patch for this too.

StefanKarpinski · 2015-03-06T21:43:18Z

LLVM doesn't do point releases.

simonster · 2015-03-06T21:47:32Z

Don't they? There are point releases (3.4.1, 3.4.2, and 3.5.1) on the download page.

StefanKarpinski · 2015-03-06T21:52:43Z

Oh, I guess they started doing point releases in the 3.4 cycle. Nevermind, I hadn't noticed that.

eschnett · 2015-03-06T22:21:08Z

3.6.1 is scheduled for March (this month), so backporting would need to happen soon.

tkelman · 2015-03-06T23:47:46Z

@eschnett see http://lists.cs.uiuc.edu/pipermail/llvmdev/2015-March/082945.html, 3.5.2 is scheduled for March, 3.6.1 is scheduled for May. I just tested fixing this as a local patch and it seems to work, I'll open a PR.

signed-zero bug in LLVM 3.6.0

Carry local patch to fix #10377

simonbyrne · 2015-05-05T16:27:28Z

This patch made the 3.6.1 release:
llvm-mirror/llvm@0ee7686

tkelman · 2015-05-05T16:53:09Z

Awesome, thanks for keeping an eye on that one.

vtjnash mentioned this issue Mar 2, 2015

activate LLVM37 #9336

Closed

19 tasks

ivarne added the upstream The issue is with an upstream dependency, e.g. LLVM label Mar 2, 2015

tkelman mentioned this issue Mar 3, 2015

llvmcall test failure with LLVM 3.6.0 on Win64 #10394

Closed

ViralBShah added the bug Indicates an unexpected problem or unintended behavior label Mar 6, 2015

tkelman added a commit that referenced this issue Mar 6, 2015

Carry local patch to fix #10377

8ed90a1

signed-zero bug in LLVM 3.6.0

tkelman mentioned this issue Mar 6, 2015

Carry local patch to fix #10377 #10424

Merged

vtjnash closed this as completed in #10424 Mar 7, 2015

vtjnash added a commit that referenced this issue Mar 7, 2015

Merge pull request #10424 from JuliaLang/tk/fix10377

4a43960

Carry local patch to fix #10377

simonbyrne mentioned this issue Apr 12, 2015

isequal(sqrt(complex(0.0,-0.0)),complex(0.0,-0.0)) test failure on with LLVM 3.6 #10795

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

LLVM 3.6 giving incorrectly signed zeros #10377

LLVM 3.6 giving incorrectly signed zeros #10377

simonbyrne commented Mar 2, 2015

ViralBShah commented Mar 2, 2015

tkelman commented Mar 2, 2015

simonbyrne commented Mar 3, 2015

JeffBezanson commented Mar 3, 2015

tkelman commented Mar 3, 2015

kmsquire commented Mar 3, 2015

tkelman commented Mar 6, 2015

simonbyrne commented Mar 6, 2015

tkelman commented Mar 6, 2015

mbauman commented Mar 6, 2015

simonbyrne commented Mar 6, 2015

simonbyrne commented Mar 6, 2015

simonbyrne commented Mar 6, 2015

nalimilan commented Mar 6, 2015

tkelman commented Mar 6, 2015

StefanKarpinski commented Mar 6, 2015

simonster commented Mar 6, 2015

StefanKarpinski commented Mar 6, 2015

eschnett commented Mar 6, 2015

tkelman commented Mar 6, 2015

simonbyrne commented May 5, 2015

tkelman commented May 5, 2015

LLVM 3.6 giving incorrectly signed zeros #10377

LLVM 3.6 giving incorrectly signed zeros #10377

Comments

simonbyrne commented Mar 2, 2015

ViralBShah commented Mar 2, 2015

tkelman commented Mar 2, 2015

simonbyrne commented Mar 3, 2015

JeffBezanson commented Mar 3, 2015

tkelman commented Mar 3, 2015

kmsquire commented Mar 3, 2015

tkelman commented Mar 6, 2015

simonbyrne commented Mar 6, 2015

tkelman commented Mar 6, 2015

mbauman commented Mar 6, 2015

simonbyrne commented Mar 6, 2015

simonbyrne commented Mar 6, 2015

simonbyrne commented Mar 6, 2015

nalimilan commented Mar 6, 2015

tkelman commented Mar 6, 2015

StefanKarpinski commented Mar 6, 2015

simonster commented Mar 6, 2015

StefanKarpinski commented Mar 6, 2015

eschnett commented Mar 6, 2015

tkelman commented Mar 6, 2015

simonbyrne commented May 5, 2015

tkelman commented May 5, 2015