On Wed, Feb 26, 2025 at 1:13 PM Jakub Jelinek <ja...@redhat.com> wrote: > > 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.
I think "everything" is part of the plugin API (at least of what is declared in headers we install). I suppose we'd need to split up libbackend into two parts so we can link it with whole-archive but avoid, say, linking in hash-map-tests.o or other TUs we obviously do not need? Alternatively libgccjit could export the symbols in its map file, that should pull in the required archive members? Richard. > > Jakub >
