Branch: refs/heads/webkitglib/2.52
Home: https://github.com/WebKit/WebKit
Commit: 0d85f1f963ed29877c2234f94f37cf45af469dc9
https://github.com/WebKit/WebKit/commit/0d85f1f963ed29877c2234f94f37cf45af469dc9
Author: Paul Zander <[email protected]>
Date: 2026-05-29 (Fri, 29 May 2026)
Changed paths:
M Source/JavaScriptCore/dfg/DFGLoopUnrollingPhase.cpp
Log Message:
-----------
Cherry-pick 314072@main (87c075fbd8c3).
https://bugs.webkit.org/show_bug.cgi?id=310235
[jsc] Add back DFGBasicBlockInlines.h for DFGLoopUnrollingPhase.cpp
https://bugs.webkit.org/show_bug.cgi?id=310235
Reviewed by Adrian Perez de Castro.
292839@main has removed inclusion of DFGBasicBlockInlines.h from
DFGLoopUnrollingPhase.cpp, but actually the .cpp file still uses
BasicBlock::appendNode() which is a template defined in the .h file. So
the link of JSC now depends on luck: if the compiler creates a copy of
BasicBlock::appendNode instance in another TU, the link will succeeded;
but if there's no such a copy (for example the compiler inlined all
other appendNode calls in other TUs or made them TU-local during
interprocedural optimizations), the link will fail.
The issue manifests with webkitgtk-2.53.x: these releases fail to link
when its compiled with GCC 16.1.
* Source/JavaScriptCore/dfg/DFGLoopUnrollingPhase.cpp:
Canonical link: https://commits.webkit.org/314072@main
Canonical link: https://commits.webkit.org/305877.688@webkitglib/2.52
To unsubscribe from these emails, change your notification settings at
https://github.com/WebKit/WebKit/settings/notifications
