[PATCH] D11297: PR17829: Functions declared extern "C" with a name matching a mangled C++ function are allowed

John McCall rjmccall at gmail.com
Fri Jul 24 11:39:36 PDT 2015


rjmccall added a comment.

Thanks. :)

When you do have time to work on this again, I've found that the best way to do this is to simply propagate a flag down to GetAddrOfFunction indicating whether you intend to define it.  (One of these lessons that I keep meaning to back port from the Swift compiler...)  The actions to take are then pretty easy:

- If the global value doesn't already exist, or it already exists and has the right type + kind, you don't need to do anything special.
- Otherwise, we have an existing global value with the wrong kind (e.g. is a GlobalVariable) or the wrong type:
  - If you're not trying to define it, just return a bitcast.
  - If you're trying to define it, and the existing value is not a definition, just claim the name for a new Function and queue up the existing one to be replaced with a bitcast.  (Replacing it immediately can be dangerous because there could be outstanding references to it that aren't held in a value handle, e.g. if we're emitting the definition of something in the middle of emitting the definition of something else, which does happen sometimes.)
  - If you're trying to define it, and the existing value is a definition, diagnose the collision and return a new Function.  You don't want to mess with the existing definition because it's possible that something is currently emitting code into it.

For these purposes, the existing value is a definition if it was created by a call to GetAddrOfFunction or GetAddrOfGlobalVar with a flag saying that this is for a definition.  (Or if it was emitted by EmitAliasDefinition.)  You have to be somewhat careful about just checking whether it's an LLVM definition because we might have created it for the purposes of defining it but not yet started that definition; this is particularly likely with global variables.  (In fact, it might only be possible with them.)


http://reviews.llvm.org/D11297







More information about the cfe-commits mailing list