Skip to content

/rust

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

Compatibility fixes for LLVM 3.5 #21588

Closed
wants to merge 3 commits into from

Conversation

Reviewers
No reviews
Assignees

@brson brson

Labels
None yet
Projects
None yet
Milestone
No milestone
5 participants
@lucab @rust-highfive @alexcrichton @huonw @brson
@lucab
Copy link
Contributor

lucab commented Jan 24, 2015

This fixes building with a system-installed LLVM 3.5 and also closes #20010
@lucab
rustc_trans: don't hardcode llvm version for conditional intrinsics 
This commit introduce a third parameter for compatible_ifn!, as new
intrinsics are being added in recent LLVM releases and there is no
need to hardcode a specific case.

Signed-off-by: Luca Bruno <lucab@debian.org>
9f1c621

@rust-highfive rust-highfive assigned brson Jan 24, 2015

@rust-highfive

This comment has been minimized.

Sign in to view
Copy link
Collaborator

rust-highfive commented Jan 24, 2015

r? @brson

(rust_highfive has picked a reviewer for you, use r? to override)
src/librustc_trans/trans/context.rs Outdated
compatible_ifn!("llvm.copysign.f64", copysign(t_f64, t_f64) -> t_f64, 4);
compatible_ifn!("llvm.round.f32", roundf(t_f32) -> t_f32, 4);
compatible_ifn!("llvm.round.f64", round(t_f64) -> t_f64, 4);
compatible_ifn!("llvm.assume", fn(i1) -> void, 6);

This comment has been minimized.

Sign in to view
Copy link
@huonw

huonw Jan 24, 2015

Member

I suspect this isn't quite right, unfortunately; it seems like it might be declaring a substitute C function with signature void fn(i1). (I.e. the compatible_ifn! macro has a different syntax.)

This comment has been minimized.

Sign in to view
Copy link
@lucab

lucab Jan 24, 2015

Author Contributor

Ah, ouch sorry. I didn't notice the difference in what the two macros expect as the second parameter.

@lucab lucab force-pushed the lucab:lucab/stable-llvm-compat branch from 260a406 to f85e825 Jan 24, 2015

@lucab

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

lucab commented Jan 24, 2015

In turn, this seems to trigger an assertion in libstd/hash when building stage2 libcore: https://gist.github.com/lucab/8302e6ef7f88827fb093

I was inclined to blame myself for something I've forgotten to touch, but it looks like the same ICE already surfaced before in #2235, so I am a bit unsure...
@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented Jan 24, 2015

Hm well the ICE may be related to some odd LLVM different, but we can probably diagnose after this lands, this is definitely good to land for now. Thanks!
@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented Jan 24, 2015

@bors: r+ f85e825 rollup
@lucab

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

lucab commented Jan 24, 2015

Ok, I'll open a separate ticket for the ICE then, thanks.

@lucab lucab referenced this pull request Jan 25, 2015

Closed

ICE compiling stage2 libcore, when building with LLVM-3.5 #21620

lucab added some commits Jan 24, 2015

@lucab
rustc_trans: 'assume' intrinsic is only available on LLVM >= 3.6 
Signed-off-by: Luca Bruno <lucab@debian.org>
88f8f52
@lucab
rustllvm: fix wrapper builds with LLVM 3.5 
EngineBuilder signature has changed in LLVM 3.6, as the interface
was not move-based in previous releases.

Signed-off-by: Luca Bruno <lucab@debian.org>
Loading status checks…
18f8d35

@lucab lucab force-pushed the lucab:lucab/stable-llvm-compat branch from f85e825 to 18f8d35 Jan 26, 2015

@lucab

This comment has been minimized.

Sign in to view
Copy link
Contributor Author

lucab commented Jan 26, 2015

Mmmh, however I just realized that my fix was incomplete/incorrect as I was mapping "llvm.assume" to a non-existing "void assume(bool)" C function. Rebased a commit to introduce a stub function. However, in the ligth of #21620, I wonder if merging this PR makes sense anymore.
@alexcrichton

This comment has been minimized.

Sign in to view
Copy link
Member

alexcrichton commented Jan 27, 2015

Hm we'd probably prefer to lower it to a noop instead of a call to an actual function (as that may end up hindering optimizations). You've got a good point about #21620 though, so I think for now we can just close in favor of that. Thanks for investigating though!

@alexcrichton alexcrichton closed this Jan 27, 2015

@sylvestre sylvestre referenced this pull request Jan 29, 2015

Closed

Fails to build against llvm 3.6 rc1 #21512

@davidvoit davidvoit referenced this pull request May 23, 2015

Closed

Stable: Compatibility fixes for LLVM 3.5 #25739

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.