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.

  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: link
Be 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).