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

Unclear semantics of [@@noalloc] #7655

Closed
vicuna opened this Issue Oct 9, 2017 · 3 comments

Comments

Projects
None yet
2 participants
@vicuna
Copy link
Collaborator

commented Oct 9, 2017

Original bug ID: 7655
Reporter: @mmottl
Assigned to: @gasche
Status: resolved (set by @gasche on 2017-10-14T23:43:18Z)
Resolution: fixed
Priority: normal
Severity: text
Version: 4.05.0
Fixed in version: 4.06.0 +dev/beta1/beta2/rc1
Category: documentation
Monitored by: @gasche @mmottl

Bug description

The manual does not seem to specify the behavior of external function declarations with the [@@noalloc] attribute if both a byte and native code entry point are declared. Though one would typically expect both entry points to have the same allocation behavior, this is eminently not the case when the function also declares that it returns unboxed values.

E.g. many numeric functions in Pervasives return unboxed doubles, which have to be explicitly allocated for byte code but not for native code. The functions are nevertheless declared with [@@noalloc]. I guess the byte code interpreter always ignores this attribute, otherwise the current Pervasives implementation would not be safe.

I think the expected behavior of [@@noalloc] with byte and native code should be documented in the C-interface section of the manual.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 9, 2017

Comment author: @xavierleroy

Yes, [@@noalloc] and several other function attributes such as [@@unboxed] apply only in native code. Feel free to suggest a better wording for the reference manual to make this point clearer.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 9, 2017

Comment author: @mmottl

Indeed, I just realized that the main section has a small note that it only applies to the native code compiler. But in its subsections (about unboxing and direct C-calls respectively) the text only refers to "the OCaml compiler". The note at the beginning of the main section is easy to miss. I knew that unboxing / untagging would only work with the native code compiler, but I always mistakenly believed that "noalloc" applied to byte code stubs, too.

I have just submitted a pull request that hopefully improves the wording in subsections.

@vicuna

This comment has been minimized.

Copy link
Collaborator Author

commented Oct 14, 2017

Comment author: @gasche

Fixed by merging Markus' pull request: #1422

@vicuna vicuna closed this Oct 14, 2017

@vicuna vicuna added the bug label Mar 20, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.