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
gollvm: some built-in libgo tests failed #51648
Comments
cc @thanm |
Thanks for that investigation. |
Change https://go.dev/cl/393295 mentions this issue: |
Change https://go.dev/cl/393595 mentions this issue: |
Change https://go.dev/cl/394474 mentions this issue: |
The existing implementation folds addr(deref(X)) => X only. This change makes it also work the opposite way. Updates golang/go#51648 Change-Id: Idc1996d431827fb2c410e4d9fdd99625c1d2dfa6 Reviewed-on: https://go-review.googlesource.com/c/gollvm/+/393295 Trust: Eli Bendersky <eliben@golang.org> Reviewed-by: Than McIntosh <thanm@google.com>
…x types The current implementation translates '-EXPR' into 'ZERO_EXPR - EXPR'. It handles EXPR of floating-point types as a special case for which ZERO_EXPR is -0.0. This change applies the same approach to EXPR of complex types so that '-CMPLX_EXPR' translates into '(-0.0-0.0i) - CMPLX_EXPR' instead of '(0.0+0.0i) - CMPLX_EXPR'. Updates golang/go#51648 Change-Id: I66bcfaa9864a83d108c2719fe6dce59975e1c205 Reviewed-on: https://go-review.googlesource.com/c/gollvm/+/393595 Reviewed-by: Than McIntosh <thanm@google.com> Trust: Bryan Mills <bcmills@google.com>
Signame() checks for HAVE_STRSIGNAL but the current implementation never defines it. This change adds a check for strsignal() existence to cmake rules. Updates golang/go#51648 Change-Id: I404e6e6903ae31fdcceafecfae77ac5993549c03 Reviewed-on: https://go-review.googlesource.com/c/gollvm/+/394474 Reviewed-by: Than McIntosh <thanm@google.com> Trust: Martin Möhrmann <martin@golang.org>
Change https://go.dev/cl/419574 mentions this issue: |
similar to https://go-review.googlesource.com/c/gofrontend/+/140517/ skipping a test that is not working on gollvm. For golang/go#51648 Change-Id: Iec36c27a4f4f965dff512468326354686763ea22
Change https://go.dev/cl/421314 mentions this issue: |
Change https://go.dev/cl/421442 mentions this issue: |
Arrange for tests that call setMimeInit to fully restore the old values, by clearing the sync.Once that controls initialization. Once we've done that, call initMime in initMimeUnixTest because otherwise the test types loaded there will be cleared by the call to initMime that previously was not being done. For golang/go#51648 Change-Id: I8bf92b305fc4499337db06113817c9decdc5aedb
Arrange for tests that call setMimeInit to fully restore the old values, by clearing the sync.Once that controls initialization. Once we've done that, call initMime in initMimeUnixTest because otherwise the test types loaded there will be cleared by the call to initMime that previously was not being done. For golang/go#51648 Change-Id: I8bf92b305fc4499337db06113817c9decdc5aedb
Arrange for tests that call setMimeInit to fully restore the old values, by clearing the sync.Once that controls initialization. Once we've done that, call initMime in initMimeUnixTest because otherwise the test types loaded there will be cleared by the call to initMime that previously was not being done. For #51648 Change-Id: I8bf92b305fc4499337db06113817c9decdc5aedb Reviewed-on: https://go-review.googlesource.com/c/go/+/421442 Reviewed-by: Than McIntosh <thanm@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com>
Arrange for tests that call setMimeInit to fully restore the old values, by clearing the sync.Once that controls initialization. Once we've done that, call initMime in initMimeUnixTest because otherwise the test types loaded there will be cleared by the call to initMime that previously was not being done. For golang#51648 Change-Id: I8bf92b305fc4499337db06113817c9decdc5aedb Reviewed-on: https://go-review.googlesource.com/c/go/+/421442 Reviewed-by: Than McIntosh <thanm@google.com> Auto-Submit: Ian Lance Taylor <iant@google.com> TryBot-Result: Gopher Robot <gobot@golang.org> Run-TryBot: Ian Lance Taylor <iant@golang.org> Reviewed-by: Ian Lance Taylor <iant@google.com> Run-TryBot: Ian Lance Taylor <iant@google.com>
Change https://go.dev/cl/483117 mentions this issue: |
Backport CL 421442 from upstream. Original description: Arrange for tests that call setMimeInit to fully restore the old values, by clearing the sync.Once that controls initialization. Once we've done that, call initMime in initMimeUnixTest because otherwise the test types loaded there will be cleared by the call to initMime that previously was not being done. For golang/go#51648 Change-Id: Ie21bb1e891479d2d842e831dc5225a9386ec6ef1 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/483117 Reviewed-by: Than McIntosh <thanm@google.com> Reviewed-by: Cherry Mui <cherryyz@google.com>
I think that everything here is fixed now. Thanks for reporting the problems. |
Backport CL 421442 from upstream. Original description: Arrange for tests that call setMimeInit to fully restore the old values, by clearing the sync.Once that controls initialization. Once we've done that, call initMime in initMimeUnixTest because otherwise the test types loaded there will be cleared by the call to initMime that previously was not being done. For golang/go#51648 Reviewed-on: https://go-review.googlesource.com/c/gofrontend/+/483117
What version of Go are you using (
go version
)?Does this issue reproduce with the latest release?
Yes
What operating system and processor architecture are you using (
go env
)?go env
OutputWhat did you do?
Ran all built-in libgo tests:
What did you expect to see?
Nothing, all tests pass
What did you see instead?
internal/fmtsort
fails due to the same issue described at gollvm: can't use unsafe.Pointer as map key #51238. I've got a fix for this one already. I will submit a cl soon.os/signal
requires cmake files to be updated, I'll submit a cl fixing this.runtime
fails due to the same issue described at gollvm: gofrontend: go version prints 'unknown' #51098.runtime/debug
requires the same check added for runtime in gofrontend with https://go-review.googlesource.com/c/gofrontend/+/140517/runtime/pprof
but I'm not sure yet.Mikhail Ablakatov
The text was updated successfully, but these errors were encountered: