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

Jump to bottom

noescape causes crash with assembly code #6730

Closed
gopherbot opened this issue Nov 7, 2013 · 4 comments
Closed

noescape causes crash with assembly code #6730

gopherbot opened this issue Nov 7, 2013 · 4 comments
Labels
FrozenDueToAge

Comments

@gopherbot
Copy link

by rayneolivetti:

The attached code calls an assembly function that doesn't escape anything.
When marked with //go:noescape, it causes crash.

I originally bumped into this when switching to 1.2rc3 from 1.1.2 (am64). The original
(and lengthy) code strangely runs okay with 1.1.2 whereas the test case causes panic
with 1.1.2 as well.

This made me believe that the problem exists in both version, so I will try to find the
"missing element" that lets this one slip with go 1.1.2.

By the way, is I move u and v to the global scope, the problem disappears as well.

Attachments:

  1. escape.go (169 bytes)
  2. escape_amd64.s (117 bytes)
@remyoudompheng
Copy link
Contributor

Comment 1:

There is no guarantee of a 128-bit alignment of u in this code. Heap allocations are
better aligned than stack variables, which explains the issue.
Replacing MOVAPS by MOVUPS should work in all cases.

@minux
Copy link
Member

minux commented Nov 7, 2013

Comment 2:

Yes. And when the address happens to be 128-bit aligned, I think using MOVUPS has no
performance hit at all.
Another way would be to allocate a slice (on stack/heap) larger than what you need, and
reslice it to get the needed alignment (you will need to use a C or even asm function to
do this, or you can use unsafe.Pointer).

Status changed to WorkingAsIntended.

@gopherbot
Copy link
Author

Comment 3 by rayneolivetti:

Thank you all very much for explaining this. I was living under the delusion that all
allocations are aligned.
About performance penalty, it appears that there is none with a recent Intel CPU.
All works just fine.
I'm so sorry about filing this invalid bug.

@davecheney
Copy link
Contributor

Comment 4:

The runtime guarentees that structs with be 8 byte aligned, but that is about it.

@golang golang locked and limited conversation to collaborators Jun 25, 2016
This issue was closed.
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Assignees
No one assigned
Labels
FrozenDueToAge
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
4 participants
@davecheney @minux @remyoudompheng @gopherbot