gollvm/gofrontend: complex division produces wrong results.

[xqq0629]

What version of Go are you using (go version)?

$ go version

gollvm

Does this issue reproduce with the latest release?

yes

What operating system and processor architecture are you using (go env)?

go env Output

$ go env

Debian

Intel(R) Xeon(R) Platinum 8260 CPU @ 2.40GHz (Cascade Lake)

What did you do?

error case:

package main

import (
    "fmt"
    "math"
)

var (
    nan     = math.NaN()
    inf     = math.Inf(1)
    zero    = 0.0
)

func main() {
    var val complex128 = complex(zero, zero)
    var val1 complex128 = complex(nan, inf)

    res1 := val / val1
    fmt.Println(res1)
}

What did you expect to see?

(0+0i)
According to ISO/IEC 9899:1999 (E), (0+0i) / (NaN+Infi) = (0+0i)

What did you see instead?

(NaN+NaNi)

[randall77]

The Go spec doesn't claim to follow ISO/IEC 9899:1999, so this may not be a bug.
That said, gc does produce (0+0i), and intentionally.

[heschi]

cc @thanm

[thanm]

I'll take a look.

[ianlancetaylor]

gccgo also prints (0+0i).

[tsqua]

The Go spec doesn't claim to follow ISO/IEC 9899:1999, so this may not be a bug. That said, gc does produce (0+0i), and intentionally.

Currently, there is a running error in gonum testing. (https://github.com/gonum/gonum/tree/master/lapack/gonum)

[tsqua]

I'll take a look.

How about moving the implementation of complex128div function to runtime?
Then we can call runtime.complex128div when encounting complex division case.

[thanm]

How about moving the implementation of complex128div function to runtime?

That would be once way to do it.

[ianlancetaylor]

As a historical note libgo used to have its own implementation of complex division (https://go.googlesource.com/gofrontend/+/6b01f8cdc11d86bd98165c91d6ae101bcf6b9e1a/libgo/runtime/go-cdiv.c). I removed it because because at least with gccgo it was no longer needed. But it didn't quite match the discussion on #14644, and removing it did match where that discussion wound up with the gc compiler. So I removed it (https://go.dev/cl/274213).

(I'm a bit surprised that GoLLVM doesn't just do what C99 expects by default.)