EASY: Remove unnecessary BCProviderFromSrc.h include from RuntimeModule.cpp #1866
+39
−2
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
meta-cla
bot
added
the
CLA Signed
added 2 commits
January 5, 2026 11:55
Summary:
GCC 16 in Release mode fails to link with:
undefined reference to `typeinfo for llvh::raw_svector_ostream'
The error occurs because of an interaction between GCC 16's speculative
devirtualization and mixed RTTI settings:
1. LLVH library is compiled with -fno-rtti
2. Usage is compiled with -frtti
3. buffer_ostream is fully inline in the header, with no "key function"
When GCC 16 sees a virtual destructor call through a raw_ostream*, it
generates speculative comparisons derived types:
mov (%rbx),%rax # Load vtable ptr
lea 0x0(%rip),%rdx # Load &buffer_ostream::~buffer_ostream
mov 0x8(%rax),%rax # Load destructor from vtable
cmp %rdx,%rax # Is this a buffer_ostream?
je specialized_path # If yes, use direct call
This comparison requires the ADDRESS of buffer_ostream::~buffer_ostream,
which forces emission of the destructor, vtable, and typeinfo. The
typeinfo for buffer_ostream references its parent's typeinfo
(raw_svector_ostream), which was never emitted because LLVH uses
-fno-rtti.
The fix moves buffer_ostream's destructor out-of-line to raw_ostream.cpp.
This makes it the "key function" per the Itanium C++ ABI, causing the
vtable and typeinfo to be emitted (or not) in that translation unit.
Since raw_ostream.cpp is compiled with -fno-rtti, no typeinfo is
emitted, and the dangling reference is avoided.
Reviewed By: fbmal7
Differential Revision: D89755963
…le.cpp (facebook#1866) Summary: This fixes a link error with GCC 16 in Release mode. GCC 16's speculative devirtualization optimization generates comparison code against all known derived class vtables when it sees a virtual call through a base pointer. RuntimeModule.cpp is part of the lean build (VM without compiler), but it was including BCProviderFromSrc.h even though it doesn't use anything from that header. When GCC sees virtual calls through BCProviderBase*, it speculatively generates code paths for BCProviderFromSrc (since the class is visible via the include). This instantiates the inline virtual methods from BCProviderFromSrc, which reference BytecodeModule::getFunction() - a symbol that doesn't exist in the lean build. The fix is simply to remove the unnecessary include. RuntimeModule.cpp only uses BCProviderBase (via bcProvider_) and BCProviderFromBuffer (for sizeof), both of which are available through BCProvider.h, which is already included via RuntimeModule.h. Reviewed By: avp Differential Revision: D89755964
tmikov
force-pushed
the
export-D89755964
branch
from
4ea43da to
9d82d33
Compare
|
This pull request has been merged in 7718502. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary:
This fixes a link error with GCC 16 in Release mode. GCC 16's speculative
devirtualization optimization generates comparison code against all known
derived class vtables when it sees a virtual call through a base pointer.
RuntimeModule.cpp is part of the lean build (VM without compiler), but it
was including BCProviderFromSrc.h even though it doesn't use anything from
that header. When GCC sees virtual calls through BCProviderBase*, it
speculatively generates code paths for BCProviderFromSrc (since the class
is visible via the include). This instantiates the inline virtual methods
from BCProviderFromSrc, which reference BytecodeModule::getFunction() -
a symbol that doesn't exist in the lean build.
The fix is simply to remove the unnecessary include. RuntimeModule.cpp
only uses BCProviderBase (via bcProvider_) and BCProviderFromBuffer
(for sizeof), both of which are available through BCProvider.h, which
is already included via RuntimeModule.h.
Differential Revision: D89755964