Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Cryptic compiler error on using non-int parameters in make #120

Closed
kyegupov opened this issue Jan 4, 2019 · 6 comments
Closed

Cryptic compiler error on using non-int parameters in make #120

kyegupov opened this issue Jan 4, 2019 · 6 comments
Labels
bug Something isn't working

Comments

@kyegupov
Copy link
Contributor

kyegupov commented Jan 4, 2019

The following code compiles by mainline Go:

buf := make([]byte, x.methodReturningUint64())

but, when attempting to use that code in TinyGo, it crashes with the following error:

Call parameter type does not match function signature!
  %10 = call i64 @"(TypeOfX).methodReturningUint64"(i32 %8, i8* %9, i8* undef), !dbg !24845
 i32  call void @runtime.sliceBoundsCheckMake(i64 %10, i64 %10, i8* undef), !dbg !24846
@aykevl
Copy link
Member

aykevl commented Jan 4, 2019

On which target is this an issue? I'm asking because this case should be tested in testdata/slice.go, and I can't reproduce on AVR either.

@kyegupov
Copy link
Contributor Author

kyegupov commented Jan 8, 2019

Sorry, the target is WebAssembly.

@aykevl
Copy link
Member

aykevl commented Jan 9, 2019

I managed to reproduce this, with the following code:

var x []byte

func main() {
	buf := make([]byte, foo())
	x = buf
}

func foo() uint64 {
	return 3
}

Apparently there is a difference between uint64(3) and foo(). This is why the tests pass but the code here still fails. I'll have to investigate why this is.

@aykevl
Copy link
Member

aykevl commented Jan 9, 2019

And this is a bug on all non-64-bit targets I just tested (avr, wasm, cortex-m). So it's not limited to WebAssembly.

@deadprogram
Copy link
Member

I think this issue is now fixed in the dev branch, is that correct @aykevl ?

@aykevl
Copy link
Member

aykevl commented Apr 11, 2019

Yes, it should be fixed.

@aykevl aykevl closed this as completed Apr 11, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants