* [Bug c++/95428] ABI breakage for "base object constructor" for final classes
2020-05-30 0:08 [Bug c++/95428] New: ABI breakage for "base object constructor" for final classes P at draigBrady dot com
@ 2020-05-30 23:56 ` pinskia at gcc dot gnu.org
2020-05-31 12:31 ` P at draigBrady dot com
` (10 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: pinskia at gcc dot gnu.org @ 2020-05-30 23:56 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428
--- Comment #1 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
Can you provide a full testcase?
>From the sound of it, this might be a LLVM bug.
As mentioned you can't extend a final class which means base object constructor
can't be called. If LLVM is producing a call, then it seems like an ABI bug
there.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/95428] ABI breakage for "base object constructor" for final classes
2020-05-30 0:08 [Bug c++/95428] New: ABI breakage for "base object constructor" for final classes P at draigBrady dot com
2020-05-30 23:56 ` [Bug c++/95428] " pinskia at gcc dot gnu.org
@ 2020-05-31 12:31 ` P at draigBrady dot com
2020-05-31 12:46 ` P at draigBrady dot com
` (9 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: P at draigBrady dot com @ 2020-05-31 12:31 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428
--- Comment #2 from Pádraig Brady <P at draigBrady dot com> ---
The test case is in bug #70462.
Copying here...
g++ -std=c++11 -c -o t.o -x c++ - << EOF
struct Bar final
{
Bar();
};
Bar::Bar()
{}
EOF
$ nm t.o | grep C2 || echo ABI issue
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/95428] ABI breakage for "base object constructor" for final classes
2020-05-30 0:08 [Bug c++/95428] New: ABI breakage for "base object constructor" for final classes P at draigBrady dot com
2020-05-30 23:56 ` [Bug c++/95428] " pinskia at gcc dot gnu.org
2020-05-31 12:31 ` P at draigBrady dot com
@ 2020-05-31 12:46 ` P at draigBrady dot com
2020-05-31 16:46 ` pinskia at gcc dot gnu.org
` (8 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: P at draigBrady dot com @ 2020-05-31 12:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428
--- Comment #3 from Pádraig Brady <P at draigBrady dot com> ---
I've not got a reduced example where clang is generating the call, but it could
be a linker issue as the two constructors are aliased to the same address.
The linker used here was lld.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/95428] ABI breakage for "base object constructor" for final classes
2020-05-30 0:08 [Bug c++/95428] New: ABI breakage for "base object constructor" for final classes P at draigBrady dot com
` (2 preceding siblings ...)
2020-05-31 12:46 ` P at draigBrady dot com
@ 2020-05-31 16:46 ` pinskia at gcc dot gnu.org
2020-06-01 13:29 ` nathan at gcc dot gnu.org
` (7 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: pinskia at gcc dot gnu.org @ 2020-05-31 16:46 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428
Andrew Pinski <pinskia at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Ever confirmed|0 |1
Status|UNCONFIRMED |WAITING
Last reconfirmed| |2020-05-31
--- Comment #4 from Andrew Pinski <pinskia at gcc dot gnu.org> ---
(In reply to Pádraig Brady from comment #3)
> I've not got a reduced example where clang is generating the call, but it
> could be a linker issue as the two constructors are aliased to the same
> address.
> The linker used here was lld.
Can you check using BFD LD or gold? And report back? And if it works with
them, please file the bug against LLD instead.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/95428] ABI breakage for "base object constructor" for final classes
2020-05-30 0:08 [Bug c++/95428] New: ABI breakage for "base object constructor" for final classes P at draigBrady dot com
` (3 preceding siblings ...)
2020-05-31 16:46 ` pinskia at gcc dot gnu.org
@ 2020-06-01 13:29 ` nathan at gcc dot gnu.org
2020-06-04 9:47 ` redi at gcc dot gnu.org
` (6 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: nathan at gcc dot gnu.org @ 2020-06-01 13:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428
--- Comment #5 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
i have filed ABI issue 104
https://github.com/itanium-cxx-abi/cxx-abi/issues/104
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/95428] ABI breakage for "base object constructor" for final classes
2020-05-30 0:08 [Bug c++/95428] New: ABI breakage for "base object constructor" for final classes P at draigBrady dot com
` (4 preceding siblings ...)
2020-06-01 13:29 ` nathan at gcc dot gnu.org
@ 2020-06-04 9:47 ` redi at gcc dot gnu.org
2020-06-05 20:15 ` nathan at gcc dot gnu.org
` (5 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: redi at gcc dot gnu.org @ 2020-06-04 9:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|WAITING |SUSPENDED
--- Comment #6 from Jonathan Wakely <redi at gcc dot gnu.org> ---
I think SUSPENDED is more appropriate than WAITING, since we're waiting for an
ABI spec clarification.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/95428] ABI breakage for "base object constructor" for final classes
2020-05-30 0:08 [Bug c++/95428] New: ABI breakage for "base object constructor" for final classes P at draigBrady dot com
` (5 preceding siblings ...)
2020-06-04 9:47 ` redi at gcc dot gnu.org
@ 2020-06-05 20:15 ` nathan at gcc dot gnu.org
2020-08-21 9:45 ` redi at gcc dot gnu.org
` (4 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: nathan at gcc dot gnu.org @ 2020-06-05 20:15 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428
--- Comment #7 from Nathan Sidwell <nathan at gcc dot gnu.org> ---
Richard Smith thinks the ABI is clear and compilers should always emit the
as-base ctor. Even though that wording was written before final was a thing.
Depends if Jason wants to argue the case?
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/95428] ABI breakage for "base object constructor" for final classes
2020-05-30 0:08 [Bug c++/95428] New: ABI breakage for "base object constructor" for final classes P at draigBrady dot com
` (6 preceding siblings ...)
2020-06-05 20:15 ` nathan at gcc dot gnu.org
@ 2020-08-21 9:45 ` redi at gcc dot gnu.org
2020-08-21 19:50 ` jason at gcc dot gnu.org
` (3 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: redi at gcc dot gnu.org @ 2020-08-21 9:45 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428
Jonathan Wakely <redi at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|SUSPENDED |NEW
--- Comment #8 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Let's reopen this then, as GCC needs to keep providing the alias for the base
object constructor.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/95428] ABI breakage for "base object constructor" for final classes
2020-05-30 0:08 [Bug c++/95428] New: ABI breakage for "base object constructor" for final classes P at draigBrady dot com
` (7 preceding siblings ...)
2020-08-21 9:45 ` redi at gcc dot gnu.org
@ 2020-08-21 19:50 ` jason at gcc dot gnu.org
2020-08-24 21:44 ` cvs-commit at gcc dot gnu.org
` (2 subsequent siblings)
11 siblings, 0 replies; 13+ messages in thread
From: jason at gcc dot gnu.org @ 2020-08-21 19:50 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Assignee|unassigned at gcc dot gnu.org |jason at gcc dot gnu.org
Status|NEW |ASSIGNED
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/95428] ABI breakage for "base object constructor" for final classes
2020-05-30 0:08 [Bug c++/95428] New: ABI breakage for "base object constructor" for final classes P at draigBrady dot com
` (8 preceding siblings ...)
2020-08-21 19:50 ` jason at gcc dot gnu.org
@ 2020-08-24 21:44 ` cvs-commit at gcc dot gnu.org
2020-08-24 21:47 ` jason at gcc dot gnu.org
2020-08-25 2:44 ` cvs-commit at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-08-24 21:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428
--- Comment #9 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The releases/gcc-10 branch has been updated by Jason Merrill
<jason@gcc.gnu.org>:
https://gcc.gnu.org/g:d94796352234def681a34eef99dad18bccecbca7
commit r10-8659-gd94796352234def681a34eef99dad18bccecbca7
Author: Jason Merrill <jason@redhat.com>
Date: Fri Aug 21 16:23:03 2020 -0400
c++: Emit as-base 'tor symbols for final class. [PR95428]
For PR70462 I stopped emitting the as-base constructor and destructor
variants for final classes, because they can never be called. Except that
it turns out that clang calls base variants from complete variants, even
for
classes with virtual bases, and in some cases inlines them such that the
calls to the base variant are exposed. So we need to continue to emit the
as-base symbols, even though they're unreachable by G++-compiled code.
gcc/cp/ChangeLog:
PR c++/95428
* optimize.c (populate_clone_array): Revert PR70462 change.
(maybe_clone_body): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/other/final8.C: Adjust expected output.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/95428] ABI breakage for "base object constructor" for final classes
2020-05-30 0:08 [Bug c++/95428] New: ABI breakage for "base object constructor" for final classes P at draigBrady dot com
` (9 preceding siblings ...)
2020-08-24 21:44 ` cvs-commit at gcc dot gnu.org
@ 2020-08-24 21:47 ` jason at gcc dot gnu.org
2020-08-25 2:44 ` cvs-commit at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: jason at gcc dot gnu.org @ 2020-08-24 21:47 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Target Milestone|--- |10.3
Status|ASSIGNED |RESOLVED
Resolution|--- |FIXED
--- Comment #10 from Jason Merrill <jason at gcc dot gnu.org> ---
Fixed for 10.3/11.
^ permalink raw reply [flat|nested] 13+ messages in thread
* [Bug c++/95428] ABI breakage for "base object constructor" for final classes
2020-05-30 0:08 [Bug c++/95428] New: ABI breakage for "base object constructor" for final classes P at draigBrady dot com
` (10 preceding siblings ...)
2020-08-24 21:47 ` jason at gcc dot gnu.org
@ 2020-08-25 2:44 ` cvs-commit at gcc dot gnu.org
11 siblings, 0 replies; 13+ messages in thread
From: cvs-commit at gcc dot gnu.org @ 2020-08-25 2:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95428
--- Comment #11 from CVS Commits <cvs-commit at gcc dot gnu.org> ---
The master branch has been updated by Jason Merrill <jason@gcc.gnu.org>:
https://gcc.gnu.org/g:6b958ee0fd0e1b2a2b22784ffbe531ed74358a22
commit r11-2829-g6b958ee0fd0e1b2a2b22784ffbe531ed74358a22
Author: Jason Merrill <jason@redhat.com>
Date: Fri Aug 21 16:23:03 2020 -0400
c++: Emit as-base 'tor symbols for final class. [PR95428]
For PR70462 I stopped emitting the as-base constructor and destructor
variants for final classes, because they can never be called. Except that
it turns out that clang calls base variants from complete variants, even
for
classes with virtual bases, and in some cases inlines them such that the
calls to the base variant are exposed. So we need to continue to emit the
as-base symbols, even though they're unreachable by G++-compiled code.
gcc/cp/ChangeLog:
PR c++/95428
* optimize.c (populate_clone_array): Revert PR70462 change.
(maybe_clone_body): Likewise.
gcc/testsuite/ChangeLog:
* g++.dg/other/final8.C: Adjust expected output.
^ permalink raw reply [flat|nested] 13+ messages in thread