Skip to content

Is debug rustc + (Release+Asserts) llvm a valid bootstrap combination? #32706

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
MagaTailor opened this issue Apr 3, 2016 · 5 comments
Closed

Comments

@MagaTailor
Copy link

If not, fine, otherwise here's a bug:

rustc: arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/librustc_trans
src/librustc_trans/attributes.rs:31:13: 31:43 error: unresolved name `llvm::RemoveFunctionAttributes` [E0425]
src/librustc_trans/attributes.rs:31             llvm::RemoveFunctionAttributes(val, attr)
                                                ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/librustc_trans/attributes.rs:31:13: 31:43 help: run `rustc --explain E0425` to see a detailed explanation
src/librustc_trans/attributes.rs:42:9: 42:39 error: unresolved name `llvm::RemoveFunctionAttributes` [E0425]
src/librustc_trans/attributes.rs:42         llvm::RemoveFunctionAttributes(val, llvm::Attribute::UWTable);
                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/librustc_trans/attributes.rs:42:9: 42:39 help: run `rustc --explain E0425` to see a detailed explanation
src/librustc_trans/attributes.rs:50:9: 50:39 error: unresolved name `llvm::RemoveFunctionAttributes` [E0425]
src/librustc_trans/attributes.rs:50         llvm::RemoveFunctionAttributes(val, llvm::Attribute::NoUnwind);
                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/librustc_trans/attributes.rs:50:9: 50:39 help: run `rustc --explain E0425` to see a detailed explanation
src/librustc_trans/attributes.rs:63:9: 63:39 error: unresolved name `llvm::RemoveFunctionAttributes` [E0425]
src/librustc_trans/attributes.rs:63         llvm::RemoveFunctionAttributes(val, llvm::Attribute::OptimizeForSize);
                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/librustc_trans/attributes.rs:63:9: 63:39 help: run `rustc --explain E0425` to see a detailed explanation
src/librustc_trans/attributes.rs:73:9: 73:39 error: unresolved name `llvm::RemoveFunctionAttributes` [E0425]
src/librustc_trans/attributes.rs:73         llvm::RemoveFunctionAttributes(val, llvm::Attribute::Naked);
                                            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
src/librustc_trans/attributes.rs:73:9: 73:39 help: run `rustc --explain E0425` to see a detailed explanation
error: aborting due to 5 previous errors
make: *** [arm-unknown-linux-gnueabihf/stage0/lib/rustlib/arm-unknown-linux-gnueabihf/lib/stamp.rustc_trans] Error 101

The reason I'm asking this (looks like a regular name resolution error), is the cfg: disabling C++ optimization (CFG_DISABLE_OPTIMIZE_CXX) option, which is not true in this case, as I was using an existing llvm build.

Source revision: a09f386

@Aatch
Copy link
Contributor

Aatch commented Apr 4, 2016

I'm not sure what would cause this, but the most likely option is probably that your build is broken in some way. That function isn't conditionally compiled and the relevant file has the appropriate uses. There's also not been any relevant changes since that revision.

@sanxiyn
Copy link
Member

sanxiyn commented Apr 4, 2016

It would be helpful to know what LLVM you are using, since it doesn't seem to be the default one.

@dotdash
Copy link
Contributor

dotdash commented Apr 4, 2016

That function is in RustWrapper.cpp, i.e. it should be present regardless of the used LLVM version. Right now my best bet would be a problem in the Makefiles that caused that file not to be recompiled after an update.

@MagaTailor
Copy link
Author

Thanks, I must have broken something by trying to reuse an existing llvm build directory that I'd preserved.

It normally works for the same build type but this time it was changed to debug. The only other potential problem could be the codegen-units option - I'll try again without it.

edit
No difference, so it must have been me :(

@MagaTailor
Copy link
Author

Turned out I wasn't doing anything wrong but my local clone got corrupted somehow. It took ages to produce this trace on ARM but it might help unravel the mystery of the "Cannot promote non-promotable alloca!" assertion.

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

No branches or pull requests

4 participants