Miscompilation of printstring at high optimization levels

[aykevl]

As reported by @deadprogram in PR #12, this code does not print the string:

package main

import (
	"machine"
	"time"
)

func main() {
	machine.InitADC()

	led := machine.GPIO{machine.LED}
	led.Configure(machine.GPIOConfig{Mode: machine.GPIO_OUTPUT})

	sensor := machine.ADC{machine.ADC2}
	sensor.Configure()

	for {
		val := sensor.Get()
		if val < 512 {
			led.Low()
		} else {
			led.High()
		}

		println("Value is", val) // this prints only the numeric value of val, not the string prefix "Value is"
		time.Sleep(time.Millisecond * 100)
	}
}

So far, I've found it's related to optimization levels (see params to Optimize() in main.go). Size level 0 and 1 compile just fine, but 2 fails. Optimization level 1 and 2 have no difference.

[deadprogram]

Just confirming this is still an issue with the latest master branch. Was not sure with all of the core changes.

[aykevl]

I plan to look into it once I'm on a stable LLVM version. It is possible this is a bug in LLVM.

What I've found last time I experimented with it, is that it is a specific combination of a branch depending on a volatile variable, print, and time.Sleep(). Note that something like:

println("foo", uint16(5))

is turned into this:

runtime.printstring("foo")
runtime.printspace()
runtime.printuint16(5)
runtime.printnl()

EDIT: if you manage to reproduce this on a desktop computer, that would make finding the bug much easier (with bugpoint).

[aykevl]

Tested on stable LLVM, the issue is still present.

[aykevl]

It looks like I made a mistake while testing. I cannot reproduce it now (on stable LLVM) so it looks like a bug in LLVM that was fixed before the release.
@deadprogram can you try whether it is still present?

[deadprogram]

Good news here, I also can no longer reproduce on latest LLVM. Seems you are correct, this must have been addressed upstream. Seems like it can ne closed now.

[aykevl]

Glad to hear, and thanks for testing!
So this is why I wasn't putting much time in it ;) I already suspected a LLVM bug as it happened during an optimization pass.