Very odd floating-point behavior (22.625 < 0.0)

[exscape]

    let num = 22.625f32;
    if num < 0.0 {
        // This code executes!
    }

I created a self-contained test case (really, though, you only need the code shown above) here:
https://github.com/exscape/float-bug-testcase

Aside from narrowing down the problem I was having to this behavior, I have not debugged it further. I don't have a hardware debugger, nor do I really understand AVR assembly beyond the basics.

[dylanmckay]

Good catch! I haven't really tested floating point yet, so the problem could be anything.

[exscape]

I'm trying to investigate this. I'm really in way over my head, but with patience I'm at least making progress (and learning a lot on the way there).

I changed the example code slightly, and added a bunch of nonsense inline asm as "markers" that make it easy to spot where a certain LLVM IR instruction begins and ends in the final .elf:

            asm!("sei");
            let num = 22.625f32;
            asm!("cli");
            if num < 0.0 {
                asm!("nop");
                asm!("sleep");
                asm!("nop");
            }
            else {
                asm!("cli");
                asm!("sleep");
                asm!("cli");
            }
            asm!("sei");

That produces LLVM IR that certainly looks correct to me:

bb3:                                              ; preds = %bb9, %bb2
  call void asm "sei", ""(), !dbg !206, !srcloc !207
  store float 2.262500e+01, float* %num, !dbg !208
  call void asm "cli", ""(), !dbg !209, !srcloc !210
  %0 = load float, float* %num, !dbg !211
  %1 = fcmp olt float %0, 0.000000e+00, !dbg !211
  br i1 %1, label %bb4, label %bb5, !dbg !211

bb4:                                              ; preds = %bb3
  call void asm "nop", ""(), !dbg !212, !srcloc !213
  call void asm "sleep", ""(), !dbg !214, !srcloc !215
  call void asm "nop", ""(), !dbg !216, !srcloc !217
  br label %bb6, !dbg !211

bb5:                                              ; preds = %bb3
  call void asm "cli", ""(), !dbg !218, !srcloc !219
  call void asm "sleep", ""(), !dbg !220, !srcloc !221
  call void asm "cli", ""(), !dbg !222, !srcloc !223
  br label %bb6, !dbg !211

bb6:                                              ; preds = %bb5, %bb4
  call void asm "sei", ""(), !dbg !224, !srcloc !225

However, that produces nonsense asm. Specifically, it appears to me that the conditional branch in bb3 is causing the issue, as everything prior to (and including) the call to __cmpsf2 is verbose but correct:

000006ca <LBB10_3>:
 6ca:   78 94           sei
 6cc:   85 eb           ldi     r24, 0xB5       ; 181
 6ce:   91 e4           ldi     r25, 0x41       ; 65
 6d0:   8f 83           std     Y+7, r24        ; 0x07
 6d2:   98 87           std     Y+8, r25        ; 0x08
 6d4:   80 e0           ldi     r24, 0x00       ; 0
 6d6:   90 e0           ldi     r25, 0x00       ; 0
 6d8:   8d 83           std     Y+5, r24        ; 0x05
 6da:   9e 83           std     Y+6, r25        ; 0x06
 6dc:   f8 94           cli
 6de:   6d 81           ldd     r22, Y+5        ; 0x05
 6e0:   7e 81           ldd     r23, Y+6        ; 0x06
 6e2:   2f 81           ldd     r18, Y+7        ; 0x07
 6e4:   38 85           ldd     r19, Y+8        ; 0x08
 6e6:   8b 83           std     Y+3, r24        ; 0x03
 6e8:   9c 83           std     Y+4, r25        ; 0x04
 6ea:   c9 01           movw    r24, r18
 6ec:   2b 81           ldd     r18, Y+3        ; 0x03
 6ee:   3c 81           ldd     r19, Y+4        ; 0x04
 6f0:   4b 81           ldd     r20, Y+3        ; 0x03
 6f2:   5c 81           ldd     r21, Y+4        ; 0x04
 6f4:   0e 94 71 04     call    0x8e2   ; 0x8e2 <__cmpsf2>
 6f8:   e0 e0           ldi     r30, 0x00       ; 0
 6fa:   f1 e0           ldi     r31, 0x01       ; 1
 6fc:   2b 81           ldd     r18, Y+3        ; 0x03
 6fe:   3c 81           ldd     r19, Y+4        ; 0x04
 700:   62 17           cp      r22, r18
 702:   73 07           cpc     r23, r19
 704:   82 07           cpc     r24, r18
 706:   93 07           cpc     r25, r19
 708:   ea 83           std     Y+2, r30        ; 0x02
 70a:   f9 83           std     Y+1, r31        ; 0x01
 70c:   0c f4           brge    .+2             ; 0x710 <LBB10_4>
 70e:   05 c0           rjmp    .+10            ; 0x71a <LBB10_5>

00000710 <LBB10_4>:
 710:   89 81           ldd     r24, Y+1        ; 0x01
 712:   81 70           andi    r24, 0x01       ; 1
 714:   80 30           cpi     r24, 0x00       ; 0
 716:   41 f4           brne    .+16            ; 0x728 <LBB10_7>
 718:   03 c0           rjmp    .+6             ; 0x720 <LBB10_6>

0000071a <LBB10_5>:
 71a:   8a 81           ldd     r24, Y+2        ; 0x02
 71c:   89 83           std     Y+1, r24        ; 0x01
 71e:   f8 cf           rjmp    .-16            ; 0x710 <LBB10_4>

00000720 <LBB10_6>:
 720:   00 00           nop
 722:   88 95           sleep
 724:   00 00           nop
 726:   04 c0           rjmp    .+8             ; 0x730 <LBB10_8>

00000728 <LBB10_7>:
 728:   f8 94           cli
 72a:   88 95           sleep
 72c:   f8 94           cli
 72e:   00 c0           rjmp    .+0             ; 0x730 <LBB10_8>

00000730 <LBB10_8>:
 730:   78 94           sei

For reference, GCC produces (in function) identical code prior to the call to __cmpsf2, but working and easily understandable code after:

 1be:   78 94           sei
 1c0:   80 e0           ldi     r24, 0x00       ; 0
 1c2:   90 e0           ldi     r25, 0x00       ; 0
 1c4:   a5 eb           ldi     r26, 0xB5       ; 181
 1c6:   b1 e4           ldi     r27, 0x41       ; 65
 1c8:   89 83           std     Y+1, r24        ; 0x01
 1ca:   9a 83           std     Y+2, r25        ; 0x02
 1cc:   ab 83           std     Y+3, r26        ; 0x03
 1ce:   bc 83           std     Y+4, r27        ; 0x04
 1d0:   f8 94           cli
 1d2:   20 e0           ldi     r18, 0x00       ; 0
 1d4:   30 e0           ldi     r19, 0x00       ; 0
 1d6:   a9 01           movw    r20, r18
 1d8:   69 81           ldd     r22, Y+1        ; 0x01
 1da:   7a 81           ldd     r23, Y+2        ; 0x02
 1dc:   8b 81           ldd     r24, Y+3        ; 0x03
 1de:   9c 81           ldd     r25, Y+4        ; 0x04
 1e0:   0e 94 19 01     call    0x232   ; 0x232 <__cmpsf2>
 1e4:   88 23           and     r24, r24
 1e6:   24 f4           brge    .+8             ; 0x1f0 <setup+0x3e>
 1e8:   00 00           nop
 1ea:   88 95           sleep
 1ec:   00 00           nop
 1ee:   03 c0           rjmp    .+6             ; 0x1f6 <setup+0x44>
 1f0:   f8 94           cli
 1f2:   88 95           sleep
 1f4:   f8 94           cli
 1f6:   78 94           sei

I've been looking at the output of running llc -print-after-all on the LLVM IR file. It looks good up until "IR Dump After Expand ISel Pseudo-instructions", which is where I'm at now. I'm having trouble understanding the output there, so far.

[exscape]

Plenty of more digging -- and I've solved it! 😀
It was a fairly simple fix; finding what caused the problem in the first place was the hard part! It took plenty of looking at DAGs and llc -debug output, not to mention googling and learning what a DAG even is prior.

In the end, I solved it by running GDB on LLC while it was type-legalizing the DAG, and stepping through to see exactly what was doing.
LLVM assumes that the return type for float comparison functions is i32, unless otherwise specified. With an override to i8, it generates working code.

I'll keep testing, and submit a fix when I feel a bit more confident in it. Any advice on how to proceed, though? Should I open a pull request, and if so, how (with submodules and all that -- I've never used them before)?

My actual program still has a bug where -1.0f32 is formatted as "0.000" (about a dozen other test values are now correctly formatted); the same Rust code for float formatting works on x86_64 (with 32-bit floats), so it ought to be something in LLVM here as well. I'll switch my focus to debugging that tomorrow, as I need to rebuild LLVM yet again first.

[exscape]

By the way, the bug mentioned in the previous comment, with the incorrectly formatted -1.0, is caused by #77, which I wrote a seemingly working (but possibly incorrect) fix for.

[dylanmckay]

Committed upstream in r314070, cherry picked in 31313e05e4b4b52882c2327d6b912ad5ee71385d, thanks for the patch!