runtime error when formatting a large int64

[nrwiersma]

Hi,

I am getting a weird runtime error when formatting a large int64 using strconv.FormatInt on my Arduino Nano. This problem does not exist in Go. I am using go version go1.14.5 darwin/amd64.

The following code snippet consistently produces the issue.

package main

import (
	"strconv"
	"time"
)

func main() {
	for {
		var now int64 = 6854775807
		println(strconv.FormatInt(now, 10))

		time.Sleep(time.Second)
	}
}

Output:

panic: runtime error: index out of range
panic: runtime error: index out of range

[nrwiersma]

As an additional note: I began by trying to use println(now) but it returns 000000 in the serial monitor in this case, which I was not expecting. With other numbers, println prints random chars. Not sure if this is a known thing.

[niaow]

Neither of these issues replicate on the latest dev branch on, at least when targeting a *nix system. Is there a particular device this failed on? It is also possible that this is an instance of a bug which was already fixed and will go into next release.

[niaow]

Oh wait arduino nano i missed that

[niaow]

Interestingly, it is actually printing for me, just printing the wrong value (0559808511)

[nrwiersma]

i mean, better, but still not massively useful 😃

[niaow]

It turns out that if you put this in an init so that the IR is executed by interp, it runs just fine. This is probably either:

1. Some sort of UB which we only have noticed on AVR (I am not sure how this would happen?)
2. More likely, a bug in LLVM's backend for AVR

[aykevl]

Yes, most likely an AVR backend bug. I've seen formatting issues previously for println. I don't intend to track down the bug as there is a high likelyhood it will be fixed with the switch to LLVM 11 (see #1056).

[aykevl]

I tested this with #1056 and that PR indeed fixes this issue. Therefore it is most likely an AVR backend issue fixed in LLVM 11.

I'm closing this issue now because the issue is fixed upstream and will eventually reach TinyGo, and there isn't really anything specific to do here. Please follow #1056 for progress on LLVM 11 support.