From: Richard Biener <richard.guenther@gmail.com>
To: "Markus Böck" <markus.boeck02@gmail.com>, "Jan Hubicka" <hubicka@ucw.cz>
Cc: GCC Patches <gcc-patches@gcc.gnu.org>
Subject: Re: [PATCH][PR94156] Split COMDAT groups on target that do not support them
Date: Wed, 5 May 2021 15:04:00 +0200 [thread overview]
Message-ID: <CAFiYyc3fnDW7s17=jdg=r6Ak8Tc3A=U_ncUyf5LaaAu9VDrTtw@mail.gmail.com> (raw)
In-Reply-To: <CAEZ8vhnLo3uAj+uGb_AKgUZigdYheb2kzAUjau8ua0n_=gOb=g@mail.gmail.com>
On Tue, Mar 23, 2021 at 5:29 PM Markus Böck via Gcc-patches
<gcc-patches@gcc.gnu.org> wrote:
>
> GCC at the moment uses COMDAT groups for things like virtual thunks,
> even on targets that do not support COMDAT groups. This has not been a
> problem as on platforms not supporting these (such as PE COFF on
> Windows), the backend handled it through directives to GAS. GCC would
> simply use a .linkonce directive telling the assembler that this
> symbol may occur multiple times, and GAS would translate that into a
> "select any" COMDAT, containing only the symbol itself (as Windows
> does support COMDAT, just not groups).
>
> When using LTO on Windows however, a few problems occur: The COMDAT
> group is transmitted as part of the IR and the linker (ld) will try to
> resolve symbols. On Windows the COMDAT information is put into the
> symbol table, instead of in sections, leading to the linker to error
> out with a multiple reference error before even calling the
> lto-wrapper and LTRANS on the IR, which would otherwise resolve the
> use of COMDAT groups.
>
> This patch removes comdat groups for symbols in the ipa-visibility
> pass and instead puts them into their own comdat. An exception to this
> rule are aliases which (at least on Windows) are also allowed to be in
> the same comdat group as the symbol they are referencing.
>
> This fixes PR94156: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94156
> A previous discussion on the problems this patch attempts to fix were
> had here: https://gcc.gnu.org/pipermail/gcc-patches/2020-July/550148.html
>
> I tested this patch with a x86_64-w64-mingw32 target on a Linux host.
> No regressions between before and after of this patch were noted. The
> Test cases provided with this patch have been confirmed to reproduce
> before this patch, and link and work after the application of the
> patch.
>
> Feedback is very welcome, especially on implications I might not be aware of.
Honza - can you have a look here?
Thanks,
Richard.
> gcc/ChangeLog:
>
> 2020-03-23 Markus Böck <markus.boeck02@gmail.com>
>
> * ipa-visibility.c (function_and_variable_visibility): Split
> COMDAT groups on targets not supporting them
>
> gcc/testsuite/ChangeLog:
>
> 2020-03-23 Markus Böck <markus.boeck02@gmail.com>
>
> * g++.dg/lto/pr94156.h: New test.
> * g++.dg/lto/pr94156_0.C: New test.
> * g++.dg/lto/pr94156_1.C: New test.
>
> --------------
> diff --git a/gcc/ipa-visibility.c b/gcc/ipa-visibility.c
> index eb0ebf770e3..76f1a8ff72a 100644
> --- a/gcc/ipa-visibility.c
> +++ b/gcc/ipa-visibility.c
> @@ -709,6 +709,14 @@ function_and_variable_visibility (bool whole_program)
> }
> node->dissolve_same_comdat_group_list ();
> }
> +
> + if (!HAVE_COMDAT_GROUP && node->same_comdat_group
> + && !node->alias && !node->has_aliases_p())
> + {
> + node->remove_from_same_comdat_group();
> + node->set_comdat_group(DECL_ASSEMBLER_NAME_RAW(node->decl));
> + }
> +
> gcc_assert ((!DECL_WEAK (node->decl)
> && !DECL_COMDAT (node->decl))
> || TREE_PUBLIC (node->decl)
> @@ -742,8 +750,11 @@ function_and_variable_visibility (bool whole_program)
> {
> gcc_checking_assert (DECL_COMDAT (node->decl)
> == DECL_COMDAT (decl_node->decl));
> - gcc_checking_assert (node->in_same_comdat_group_p (decl_node));
> - gcc_checking_assert (node->same_comdat_group);
> + if (HAVE_COMDAT_GROUP)
> + {
> + gcc_checking_assert (node->in_same_comdat_group_p
> (decl_node));
> + gcc_checking_assert (node->same_comdat_group);
> + }
> }
> node->forced_by_abi = decl_node->forced_by_abi;
> if (DECL_EXTERNAL (decl_node->decl))
> diff --git a/gcc/testsuite/g++.dg/lto/pr94156.h
> b/gcc/testsuite/g++.dg/lto/pr94156.h
> new file mode 100644
> index 00000000000..3990ac46fcb
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/lto/pr94156.h
> @@ -0,0 +1,20 @@
> +class Base0 {
> +public:
> + virtual ~Base0() {}
> +};
> +
> +class Base1 {
> +public:
> + virtual void foo() = 0;
> +};
> +
> +class Base2 {
> +public:
> + virtual void foo() = 0;
> +};
> +
> +class Derived : public Base0, public Base1, public Base2 {
> +public:
> + virtual ~Derived();
> + virtual void foo() override {}
> +};
> diff --git a/gcc/testsuite/g++.dg/lto/pr94156_0.C
> b/gcc/testsuite/g++.dg/lto/pr94156_0.C
> new file mode 100644
> index 00000000000..1a2e30badc7
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/lto/pr94156_0.C
> @@ -0,0 +1,6 @@
> +// { dg-lto-do link }
> +#include "pr94156.h"
> +
> +Derived::~Derived() {}
> +
> +int main() {}
> diff --git a/gcc/testsuite/g++.dg/lto/pr94156_1.C
> b/gcc/testsuite/g++.dg/lto/pr94156_1.C
> new file mode 100644
> index 00000000000..d7a40efa96c
> --- /dev/null
> +++ b/gcc/testsuite/g++.dg/lto/pr94156_1.C
> @@ -0,0 +1,6 @@
> +#include "pr94156.h"
> +
> +void bar(Derived* p)
> +{
> + p->foo();
> +}
prev parent reply other threads:[~2021-05-05 13:04 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-03-23 16:27 Markus Böck
2021-05-05 13:04 ` Richard Biener [this message]
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='CAFiYyc3fnDW7s17=jdg=r6Ak8Tc3A=U_ncUyf5LaaAu9VDrTtw@mail.gmail.com' \
--to=richard.guenther@gmail.com \
--cc=gcc-patches@gcc.gnu.org \
--cc=hubicka@ucw.cz \
--cc=markus.boeck02@gmail.com \
/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).