Change:
extern "C" LLVMValueRef LLVMRustGetOrInsertGlobal(LLVMModuleRef M, const char *Name, size_t NameLen, LLVMTypeRef Ty) { <ins> Module *Mod = unwrap(M); </ins> StringRef NameRef(Name, NameLen); <del> return wrap(unwrap(M)->getOrInsertGlobal(NameRef, unwrap(Ty))); </del> <ins> // We don't use Module::getOrInsertGlobal because that returns a Constant*, // which may either be the real GlobalVariable*, or a constant bitcast of it // if our type doesn't match the original declaration. We always want the // GlobalVariable* so we can access linkage, visibility, etc. GlobalVariable *GV = Mod->getGlobalVariable(NameRef, true); if (!GV) GV = new GlobalVariable(*Mod, unwrap(Ty), false, GlobalValue::ExternalLinkage, nullptr, NameRef); return wrap(GV); </ins> } extern "C" LLVMValueRef

Discussion:
<!-- Thank you for filing a regression report! A regression is something that changed between versions of Rust but was not supposed to. Please provide a short summary of the regression, along with any information you feel is relevant to replicate it. --After upgrading our toolchains from to , our bootloader rust crates stopped building. Instead, the build command produced the error message . As these are a closed-source projects I cannot share any code publicly, but it can be shared privately if necessary. I expected to see this happen: the build to succeed Instead, this happened: the build failed <!-- Provide the most recent version this worked on, for example: It most recently worked on: Rust 1.53 --It most recently worked on: Rust 1.53 <!-- Provide the version you are using that has the regression. --: <!-- Did the compiler crash? If so, please provide a backtrace. --The compiler did not crash or produce a backtrace. </p</details<!-- If you know when this regression occurred, please add a line like below, replacing with one of stable, beta, or nightly. modify labels: +regression-from-stable-to-stable -regression-untriaged --
Looks like a dup of
Ah, it does appear to be. We had several blocks with definitions with the same name. After merging them together so that the variables only occurred once the projects started compiling again. The sections looked as follows, if that helps. They were repeated a few times in different scopes: Thank you for the heads up.
You may search whether you have declarations that have the same name, but a different type. I was only able to reproduce the error with that constraint, see
All declarations have the same type, everywhere (). It could be that the issues are related but not strictly the same.
Can you use the project to get a "-alt" nightly (which has LLVM assertions enabled) and try to compile your code with it. Does it give you the same result as ?
I've tried, but it seems as though the target we build for isn't (easily?) available that way. doesn't work, and I'm not sure how to get it to work. Any guidance?
Try this (replace the hash if needed):
Thank you, now running worked.

It does seem to be the same issue as in , apart from the fact that our types are all the same.
Ok, I think then we should leave this issue open until a fix is available. I would suggest that you branch the current work to have it later available for testing. If a fix is merged, I hopefully will remember this and ping you again to test it with that nightly again. Is that feasible for you?
Yes, that sounds good to me! Will do, and thank you for the help
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
or anyone else in this thread know how to get the builds for Apple Silicon Macs?
my best guess is: because aarch64-apple-darwin is not a , there's no alt target built per default. You may have to build it yourself. have you a better idea?
I don't mind building myself was just hoping I didn't have to! edit: I built it myself no problems there, was curious if there was a way to get a line or function name easily that is causing the clash? I'm seeing this only on my and not my machine and I'm a bit lost tracing what's causing this in a large project.
Huh interesting looks like my project is now only hitting this on any good way to track down which symbols are clashing?
The code that caused the issue in the project mentioned was an that pointed to itself. Removing the unnecessary resolved the issue.

<!-- Thank you for finding an Internal Compiler Error! If possible, try to provide a minimal verifiable example. You can read "Rust Bug Minimization Patterns" for how to create smaller examples. -- <!-- If you're using the stable version of the compiler, you should also check if the bug also exists in the beta or nightly versions. --:
Forgive the unsafe mess :)
Using a self built rustc, I get this (already ered): I also got this recently:
I managed to recude the code a lot. The problem is, that the error happens on random. I'm not sure why or what, but when running it ten times () it happens maybe once... would you mind pinging the LLVM crew? I don't know what to do here :(
With a custom built llvm (and asserts on) I will now get this error every time
ping llvm
Hey LLVM ICE-breakers! This bug has been identified as a good "LLVM ICE-breaking candidate". In case it's useful, here are some [instructions] for tackling these sorts of bugs. Maybe take a look? Thanks! <3 [instructions]: https://rustc-dev- cc
So, I got this: The key is to have two identical named extern variables with a different type. They have be called and inlined for this to work. I'm not sure if bisecting here is helpful because it will probably bisect to the LLVM12 merge. But the LLVM people here on the repo should be able to find something :) Have fun
Still spurious.
Yes and no. So the key here is to have a LLVM backend with asserts enabled. There are the -alt builds which have asserts enabled and they give me the same result as my local built rustc (which is unsurprising and expected ;) ) You can use to install them.
Assigning priority based on the discussion for in the of the Prioritization Working Group. label +regression-from-stable-to-stable +P-high
Still an issue even with the LLVM13 upgrade :/
Valgrind gave me a little more clue where this is coming from for . (Assuming it is indeed the same issue, but it seems likely.)
seems to be fixed.. thank you!