added test for bitcast signaled nan float

[Hardy7cc]

This was fixed by MR #14201

closes #10449

[Hardy7cc]

I narrowed the test issue down to the following:

It seems like it's an issue with llvm it self.
When compiling the following llvm-ir with llc -mtriple arm-linux-none the constant value 0xH7C01 seems to get turned into #32256 (0x7E00) inverting the signaling bit and discarding the payload of the float value.

define dso_local void @entry() #0 {
Entry:
    %0 = alloca half, align 2
    store half 0xH7C01, ptr %0, align 2
    ret void
}

entry:
        sub     sp, sp, #4
        mov     r0, #1
        orr     r0, r0, #32256
        strh    r0, [sp, #2]
        add     sp, sp, #4
        mov     pc, lr

When I examined it with godbolt (https://godbolt.org/z/487zsYsnq) the example is even more weird. The zig example code does switch from 0xH7C01 to #32257 (0x7E01) inverting the signaling bit but preserving the payload.

If someone with more llvm experince could take a look at this and maybe get this upstreamed or some hints how to move on.

[Vexu]

If the test is only failing for arm you should create a Zig issue for it and disable the test for builtin.cpu.arch == .arm and builtin.compiler_backend == .stage2_llvm with a comment linking to that issue. Upstreaming the issue to LLVM should also be easier now that they use github for issues.

Also please place the test in a named behavior test file like floatop.zig or maybe cast.zig.

[Hardy7cc]

Sorry I missed out the skip for the C backend. I added that and did another rebase. Hopefully this should it be.

And I'm a bit curious why windows c-backend did work the first pipeline but not the second round, probably some change on master between the two rebases.