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

Playground. Can't reproduce elsewhere, but the actual behavior seems very unlikely to be playground-specific, except obviously it is.

$ go version
1.12.7

Does this issue reproduce with the latest release?

I think so.

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

Various. Only shows up on playground, which I think is 386.

What did you do?

Obtain a method using reflect, convert it to a function of its type, and call the function.

Here's a slightly verbose version, using both int32 and int64 parameters.
https://play.golang.org/p/PX0pVeYzswQ

Calls to the same method, directly and using reflect, report in their stack traces:

main.(*Updater).Update(0x414020, 0x40c108, 0x7d0, 0x0, 0x41a7a8, 0x1) // works
main.(*Updater).Update(0x414020, 0x7d0, 0x0, 0x213, 0x0, 0x0) // doesn't work
main.(*Updater32).Update(0x414078, 0x7d0, 0x13846d, 0x3) // works
main.(*Updater32).Update(0x414078, 0x7d0, 0x0, 0x446514) // also works

The same lines from a local machine, running GOARCH=386, and running 386 go:

main.(*Updater).Update(0x8812138, 0x7d0, 0x0, 0x3)
main.(*Updater).Update(0x8812138, 0x7d0, 0x0, 0x0)
main.(*Updater32).Update(0x88121a8, 0x7d0, 0x811492c)
main.(*Updater32).Update(0x88121a8, 0x7d0, 0x0)

So there's two things that stand out here. One is that on the playground, with int64, only the one that looks wrong is actually working.

What did you expect to see?

I expected that to work.

What did you see instead?

If the parameter in question is int64, I see garbage values because the call parameters appear to be out of sync in some way.