On Wed, Feb 26, 2025 at 12:22:10PM +0100, Richard Biener wrote:
> On Wed, Feb 26, 2025 at 11:38 AM Jakub Jelinek <ja...@redhat.com> wrote:
> >
> > On Wed, Feb 26, 2025 at 10:45:37AM +0100, Richard Biener wrote:
> > > OK
> >
> > Unfortunately I've only bootstrapped/regtested it with normal checking.
> > Testing it with --enable-checking=release now shows that this patch just
> > moved the FAILs to a different symbol. And note that isn't even a LTO
> > build.
> >
> > The following patch which IMHO still makes sense, those methods are also
> > trivial, moves it even further. But the next problem is
> > _ZN22simple_diagnostic_path9add_eventEmP9tree_nodeiPKcz
> > and that method is IMHO too large for the header file to be defined inline,
> > and doesn't even have final override like the others, isn't virtual in the
> > abstract class.
> > So, I have really no idea why it isn't compiled in.
>
> Hmm, so why isn't it part of libgccjit? I suppose C++ does not really support
> exposing a class but not exporting the classes ABI?
Actually, I had a closer look on what is going on.
The _ZN22simple_diagnostic_path9add_eventEmP9tree_nodeiPKcz symbol (and the
others too) are normally emitted in simple-diagnostic-path.o, it isn't some
fancy C++ optimization of classes with final method or LTO optimization.
The problem is that simple-diagnostic-path.o is like most objects added into
libbackend.a and we then link libbackend.a without -Wl,--whole-archive ...
-Wl,--no-whole-archive around it (and can't easily, not all system compilers
and linkers will support that).
With --enable-checking=yes simple-diagnostic-path.o is pulled in, because
selftest-run-tests.o calls simple_diagnostic_path_cc_tests and so
simple-diagnostic-path.o is linked in.
With --enable-checking=release self-tests aren't done and nothing links in
simple-diagnostic-path.o, because nothing in the compiler proper needs
anything from it, only the plugin tests.
Using -Wl,-M on cc1 linking, I see that in --enable-checking=release
build
analyzer/analyzer-selftests.o
digraph.o
dwarf2codeview.o
fibonacci_heap.o
function-tests.o
hash-map-tests.o
hash-set-tests.o
hw-doloop.o
insn-peep.o
lazy-diagnostic-path.o
options-urls.o
ordered-hash-map-tests.o
pair-fusion.o
print-rtl-function.o
resource.o
rtl-tests.o
selftest-rtl.o
selftest-run-tests.o
simple-diagnostic-path.o
splay-tree-utils.o
typed-splay-tree.o
vmsdbgout.o
aren't linked into cc1 (the *test* for obvious reasons of not doing
selftests, pair-fusion.o because it is aarch64 specific, hw-doloop.o because
x86 doesn't have doloop opts, vmsdbgout.o because not on VMS).
So, the question is if and what from digraph.o, fibinacci_heap.o,
hw-doloop.o, insn-peep.o, lazy-diagnostic-path.o, options-urls.o,
pair-fusion.o, print-rtl-function.o, resource.o, simple-diagnostic-path.o,
splay-tree-utils.o, typed-splay-tree.o are supposed to be part of the
plugin API if anything and how we arrange for those to be linked in when
plugins are enabled.
Jakub
