public inbox for gcc-bugs@sourceware.org help / color / mirror / Atom feed
From: "cvs-commit at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org> To: gcc-bugs@gcc.gnu.org Subject: [Bug plugins/108634] [13 regression] 'undefined symbol: tree_code_type' when building kernel GCC plugins since r13-5431-gb0241ce6e37031 Date: Fri, 10 Mar 2023 09:40:33 +0000 [thread overview] Message-ID: <bug-108634-4-PBfEj0UXth@http.gcc.gnu.org/bugzilla/> (raw) In-Reply-To: <bug-108634-4@http.gcc.gnu.org/bugzilla/> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108634 --- Comment #6 from CVS Commits <cvs-commit at gcc dot gnu.org> --- The master branch has been updated by Jakub Jelinek <jakub@gcc.gnu.org>: https://gcc.gnu.org/g:4c599ae6e081496466cada6f97b0d4687a6d765a commit r13-6577-g4c599ae6e081496466cada6f97b0d4687a6d765a Author: Jakub Jelinek <jakub@redhat.com> Date: Fri Mar 10 10:38:49 2023 +0100 tree: Use comdat tree_code_{type,length} even for C++11/14 [PR108634] The recent change to undo the tree_code_type/tree_code_length excessive duplication apparently broke building the Linux kernel plugin. While it is certainly desirable that GCC plugins are built with the same compiler as GCC has been built and with the same options (at least the important ones), it might be hard to arrange that, e.g. if gcc is built using a cross-compiler but the plugin then built natively, or GCC isn't bootstrapped for other reasons, or just as in the kernel case they were building the plugin with -std=gnu++11 while the bootstrapped GCC has been built without any such option and so with whatever the compiler defaulted to. For C++17 and later tree_code_{type,length} are UNIQUE symbols with those assembler names, while for C++11/14 they were _ZL14tree_code_type and _ZL16tree_code_length. The following patch uses a comdat var for those even for C++11/14 as suggested by Maciej Cencora. Relying on weak attribute is not an option because not all hosts support it and there are non-GNU system compilers. While we could use it unconditionally, I think defining a template just to make it comdat is weird, and the compiler itself is always built with the same compiler. Plugins, being separate shared libraries, will have a separate copy of the arrays if they are ODR-used in the plugin, so there is not a big deal if e.g. cc1plus uses tree_code_type while plugin uses _ZN19tree_code_type_tmplILi0EE14tree_code_typeE or vice versa. 2023-03-10 Jakub Jelinek <jakub@redhat.com> PR plugins/108634 * tree-core.h (tree_code_type, tree_code_length): For C++11 or C++14, don't declare as extern const arrays. (tree_code_type_tmpl, tree_code_length_tmpl): New types with static constexpr member arrays for C++11 or C++14. * tree.h (TREE_CODE_CLASS): For C++11 or C++14 use tree_code_type_tmpl <0>::tree_code_type instead of tree_code_type. (TREE_CODE_LENGTH): For C++11 or C++14 use tree_code_length_tmpl <0>::tree_code_length instead of tree_code_length. * tree.cc (tree_code_type, tree_code_length): Remove.
next prev parent reply other threads:[~2023-03-10 9:40 UTC|newest] Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top 2023-02-01 22:37 [Bug plugins/108634] New: " sam at gentoo dot org 2023-02-01 22:44 ` [Bug plugins/108634] " arsen at aarsen dot me 2023-02-01 22:46 ` sam at gentoo dot org 2023-02-01 22:48 ` pinskia at gcc dot gnu.org 2023-02-01 23:11 ` sam at gentoo dot org 2023-02-04 0:09 ` jakub at gcc dot gnu.org 2023-03-10 9:40 ` cvs-commit at gcc dot gnu.org [this message] 2023-03-17 7:45 ` cvs-commit at gcc dot gnu.org
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=bug-108634-4-PBfEj0UXth@http.gcc.gnu.org/bugzilla/ \ --to=gcc-bugzilla@gcc.gnu.org \ --cc=gcc-bugs@gcc.gnu.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).