Skip to content

[Darwin] Get rid of trampoline hack for lgamma function. #1776

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

Closed
wants to merge 1 commit into from

Conversation

rintaro
Copy link
Member

@rintaro rintaro commented Mar 22, 2016

What's in this pull request?

Since swiftc pass-through -Xcc arguments to ClangImporter,
we can unveil lgamma_r with -Xcc -D_REENTRANT.

Resolved bug number: N/A


Before merging this pull request to apple/swift repository:

  • Test pull request on Swift continuous integration.

@rintaro rintaro force-pushed the darwin-lgamma branch 2 times, most recently from fc7acf2 to fbd5449 Compare March 22, 2016 18:58
Since swiftc pass-through -Xcc arguments to ClangImporter,
we can unveil lgamma_r from _REENTRANT macro.
@gribozavr
Copy link
Contributor

@jrose-apple Is this change safe for the downstream modules and apps?

@jrose-apple
Copy link
Contributor

Maybe? Because lgamma is inlineable, its body must only reference things that a downstream app would see. But since lgamma has a simple signature, it's possible the forward-declaration in SIL would be self-contained and not reference anything imported.

Fortunately, compiling simple calls to lgamma (1) covering all the overloads, (2) without the macro defined, and (3) with optimizations on should be enough to verify whether it's a problem—if it is, the SIL verifier will fail. Unfortunately, I don't think the general case is or will ever be sound for inlineable code. It won't ever miscompile, though—either it'll work, or a debug compiler will trap and a release compiler will probably crash.

It's up to you whether you want to take it under those conditions.

@gribozavr
Copy link
Contributor

it's possible the forward-declaration in SIL would be self-contained and not reference anything imported.

Based on #1724, I'm afraid that does not really work.

To be on the safe side, I'm inclined to reject this change.

@jrose-apple
Copy link
Contributor

I'm confused. #1724 doesn't seem to offer any barriers to this at all.

@gribozavr
Copy link
Contributor

For this change, my concern is that we won't pass -D_REENTRANT to swiftc invocations, which would mean that we would have inconsistent Clang importer state between invocations that serialize the Darwin module and those that import it. The ones that import it won't get the Clang declarations if they don't use -D_REENTRANT. Does this mean that cross-references in the module would be broken, for example?

@jrose-apple
Copy link
Contributor

That's exactly the right concern, but because the only references are at the SIL level and there are no Clang types involved, there shouldn't be any cross-references to Clang decls. …I think. There are many ways that would no longer be true in the future (debug info, perhaps), but again we'd detect it very quickly.

@jrose-apple
Copy link
Contributor

It also depends on what else _REENTRANT does, which might be enough reason to leave it alone for now.

@gribozavr
Copy link
Contributor

@rintaro Sorry!

@gribozavr gribozavr closed this Mar 22, 2016
@rintaro
Copy link
Member Author

rintaro commented Mar 23, 2016

To be on the safe side,

I agree.
Thank you for very thoughtful discussion @gribozavr @jrose-apple !

@rintaro rintaro deleted the darwin-lgamma branch April 26, 2016 08:02
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants