asavonic added a comment.
In D101156#2724789 <https://reviews.llvm.org/D101156#2724789>, @rjmccall wrote:
> What's the crash exactly/ Is IRGen just unhappy about processing the user
> definition when we've generated a declaration with a different type? Because
> we're already supposed to be being cautious about this.
Hi John. Sorry for the late reply.
class a {
public:
~a();
} b;
void *__dso_handle = &__dso_handle;
This code code causes a crash because the compiler first generates a
__dso_handle with i8 type:
@__dso_handle = external dso_local global i8
... and then reaches the explicit definition of it with a pointer type and a
pointer initializer, and tries to generate this instead:
@__dso_handle = hidden global i8* bitcast (i8** @__dso_handle to i8*), align 8
Since __dso_handle already exists in the module, it must be replaced because the
initializer has an incompatible type.
There is indeed some handling for this case in EmitGlobalVarDefinition, but it
does not work correctly when the initializer is a pointer to the variable
itself. Specifically, the Init variable in EmitGlobalVarDefinition becomes
stale:
p Init->dump()
<badref> = hidden global i8 <null operand!>
The current patch avoids this problem by having two distinct globals, but maybe
it is better to fix EmitGlobalVarDefinition instead? Is it supposed to handle
such case?
Repository:
rG LLVM Github Monorepo
CHANGES SINCE LAST ACTION
https://reviews.llvm.org/D101156/new/
https://reviews.llvm.org/D101156
_______________________________________________
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
