-
Notifications
You must be signed in to change notification settings - Fork 13.5k
[M68k] Fix ODR violation in GISel code #72797
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
Conversation
@llvm/pr-subscribers-backend-m68k Author: Vadim Petrochenkov (petrochenkov) ChangesIt prevents LLVM from being linked with LLD at least on Windows, with errors like this:
Binutils linker also complains about this, but only with warnings.
Full diff: https://github.com/llvm/llvm-project/pull/72797.diff 2 Files Affected:
diff --git a/llvm/lib/Target/M68k/GISel/M68kCallLowering.cpp b/llvm/lib/Target/M68k/GISel/M68kCallLowering.cpp
index bb63516e957fd5e..8aa8a48c12d501c 100644
--- a/llvm/lib/Target/M68k/GISel/M68kCallLowering.cpp
+++ b/llvm/lib/Target/M68k/GISel/M68kCallLowering.cpp
@@ -119,7 +119,7 @@ bool M68kCallLowering::lowerFormalArguments(MachineIRBuilder &MIRBuilder,
CCAssignFn *AssignFn =
TLI.getCCAssignFn(F.getCallingConv(), false, F.isVarArg());
IncomingValueAssigner ArgAssigner(AssignFn);
- FormalArgHandler ArgHandler(MIRBuilder, MRI);
+ M68kFormalArgHandler ArgHandler(MIRBuilder, MRI);
return determineAndHandleAssignments(ArgHandler, ArgAssigner, SplitArgs,
MIRBuilder, F.getCallingConv(),
F.isVarArg());
diff --git a/llvm/lib/Target/M68k/GISel/M68kCallLowering.h b/llvm/lib/Target/M68k/GISel/M68kCallLowering.h
index 7644e6cffbb1bc1..82b5cee9e03bcc3 100644
--- a/llvm/lib/Target/M68k/GISel/M68kCallLowering.h
+++ b/llvm/lib/Target/M68k/GISel/M68kCallLowering.h
@@ -64,8 +64,8 @@ struct M68kIncomingValueHandler : public CallLowering::IncomingValueHandler {
ISD::ArgFlagsTy Flags) override;
};
-struct FormalArgHandler : public M68kIncomingValueHandler {
- FormalArgHandler(MachineIRBuilder &MIRBuilder, MachineRegisterInfo &MRI)
+struct M68kFormalArgHandler : public M68kIncomingValueHandler {
+ M68kFormalArgHandler(MachineIRBuilder &MIRBuilder, MachineRegisterInfo &MRI)
: M68kIncomingValueHandler(MIRBuilder, MRI) {}
};
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Defining FormatArgHandler
in the anonymous namespace might be better, but still LGTM.
Just wondering why doesn't this happen on linux ?
Perhaps linker implementations are more permissive there. |
Yep, no errors or warnings with ELF linkers (both lld and binutils). |
030de30
to
0f7858f
Compare
The CI failure doesn't look relevant to me. |
ping @mshockwave |
It prevents LLVM from being linked with LLD at least on Windows, with errors like this: ``` = note: ld.lld: error: duplicate symbol: vtable for llvm::FormalArgHandler >>> defined at librustc_llvm-a81737dd65a7c126.rlib(M68kCallLowering.cpp.obj) >>> defined at librustc_llvm-a81737dd65a7c126.rlib(PPCCallLowering.cpp.obj) ``` Binutils linker also complains about this, but only with warnings. `FormalArgHandler` has a base class `M68kIncomingValueHandler` which doesn't have a virtual method `markPhysRegUsed` like `IncomingValueHandler`s for all other targets including PPC, so it results in a conflict. The simplest fix is to rename the `FormalArgHandler` structure (rather than to adding virtual methods for compatibility).
0f7858f
to
1fbefe4
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM. Thank you!
Side note: please don't force push unless it's necessary (e.g. to resolve failing tests). Please append with new commits and squash them upon merging the PR.
It prevents LLVM from being linked with LLD at least on Windows, with errors like this:
Binutils linker also complains about this, but only with warnings.
FormalArgHandler
has a base classM68kIncomingValueHandler
which doesn't have a virtual methodmarkPhysRegUsed
likeIncomingValueHandler
s for all other targets including PPC, so it results in a conflict.The simplest fix is to rename the
FormalArgHandler
structure (rather than to add virtual methods for compatibility).cc rust-lang/rust#107668