From: Eric Botcazou <ebotcazou@adacore.com>
To: gcc-patches@gcc.gnu.org
Subject: [C++] Fix PR bootstrap/81926
Date: Sat, 02 Sep 2017 11:01:00 -0000 [thread overview]
Message-ID: <4078981.6jQ9KEkrUD@polaris> (raw)
[-- Attachment #1: Type: text/plain, Size: 3031 bytes --]
Hi,
this is the bootstrap failure reported for the 7 branch on SPARC64/Solaris:
Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/go/parse.o differs
make[2]: *** [compare] Error 1
On Solaris, the bootstrap is usually an old-style bootstrap, meaning that the
debug info is generated during stage2 & stage3 so the comparison also involves
the debug info, unlike on Linux. This can be emulated on Linux by configuring
--with-build-config=no and indeed you get the comparison failure there too:
Target: x86_64-suse-linux
Configured with: /home/eric/svn/gcc-7.2.0/configure --build=x86_64-suse-linux
--prefix=/home/eric/install/gcc-7.2.0 --enable-languages=c,c++,go --enable-
__cxa_atexit --disable-nls --with-build-config=no
Thread model: posix
gcc version 7.2.0 (GCC)
make[3]: Leaving directory '/home/eric/build/gcc-7.2.0'
Comparing stages 2 and 3
Bootstrap comparison failure!
gcc/go/parse.o differs
Makefile:24421: recipe for target 'compare' failed
make[2]: *** [compare] Error 1
The difference is:
35 .debug_info 0016367a 0000000000000000 0000000000000000 0001faf8 2**0
CONTENTS, RELOC, READONLY, DEBUGGING
35 .debug_info 00163670 0000000000000000 0000000000000000 0001faf8 2**0
CONTENTS, RELOC, READONLY, DEBUGGING
.byte 0 ! end of children of DIE 0x161dbc
.byte 0 ! end of children of DIE 0x161d9c
.byte 0 ! end of children of DIE 0x161d5b
- .byte 0xf2,0x1 ! uleb128 0xf2; (DIE (0x161dd2)
DW_TAG_ptr_to_member_type)
- .uaword 0x10445d ! DW_AT_containing_type
- .uaword 0x14806e ! DW_AT_type
- .byte 0xa5,0x1 ! uleb128 0xa5; (DIE (0x161ddc)
DW_TAG_subprogram)
+ .byte 0xa5,0x1 ! uleb128 0xa5; (DIE (0x161dd2)
DW_TAG_subprogram)
.uaword 0x146733 ! DW_AT_abstract_origin
It's a garbage collection issue similar to
https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00541.html
but for build_offset_type instead of build_complex_type.
It's called from the get_debug_type langhook in C++:
tree
cp_get_debug_type (const_tree type)
{
if (TYPE_PTRMEMFUNC_P (type) && !typedef_variant_p (type))
return build_offset_type (TYPE_PTRMEMFUNC_OBJECT_TYPE (type),
TREE_TYPE (TYPE_PTRMEMFUNC_FN_TYPE (type)));
return NULL_TREE;
}
Since the OFFSET_TYPEs created there are not attached to any GC root, they are
swept by every collection, meaning that the contents of the debug info depends
on the actual collection points.
The proposed fix is to build OFFSET_TYPEs manually instead. As witnessed by
the change to g++.dg/debug/dwarf2/ref-3.C, this generates more DIEs in the
debug info, but DW_TAG_ptr_to_member_type DIEs only contain 10 bytes.
Bootstrapped on x86-64/Linux & SPARC64/Solaris, OK for mainline and 7 branch?
2017-09-02 Eric Botcazou <ebotcazou@adacore.com>
PR bootstrap/81926
* cp-objcp-common.c: Include stor-layout.h.
(cp_get_debug_type): Build OFFSET_TYPEs manually.
2017-09-02 Eric Botcazou <ebotcazou@adacore.com>
* g++.dg/debug/dwarf2/ref-3.C: Adjust DW_TAG_ptr_to_member_type count.
--
Eric Botcazou
[-- Attachment #2: pr81926.diff --]
[-- Type: text/x-patch, Size: 2201 bytes --]
Index: cp/cp-objcp-common.c
===================================================================
--- cp/cp-objcp-common.c (revision 251553)
+++ cp/cp-objcp-common.c (working copy)
@@ -23,6 +23,7 @@ along with GCC; see the file COPYING3.
#include "coretypes.h"
#include "cp-tree.h"
#include "cp-objcp-common.h"
+#include "stor-layout.h"
#include "dwarf2.h"
/* Special routine to get the alias set for C++. */
@@ -138,8 +139,20 @@ tree
cp_get_debug_type (const_tree type)
{
if (TYPE_PTRMEMFUNC_P (type) && !typedef_variant_p (type))
- return build_offset_type (TYPE_PTRMEMFUNC_OBJECT_TYPE (type),
- TREE_TYPE (TYPE_PTRMEMFUNC_FN_TYPE (type)));
+ {
+ /* We cannot call build_offset_type here because the function uses the
+ type canonicalization hashtable, which is GC-ed, so its behavior
+ depends on the actual collection points. Since we are building these
+ types on the fly for the debug info, they are not attached to any
+ GC root and will always be swept, so we would make the contents of
+ the debug info depend on the collection points. */
+ tree t = make_node (OFFSET_TYPE);
+ TYPE_OFFSET_BASETYPE (t)
+ = TYPE_MAIN_VARIANT (TYPE_PTRMEMFUNC_OBJECT_TYPE (type));
+ TREE_TYPE (t) = TREE_TYPE (TYPE_PTRMEMFUNC_FN_TYPE (type));
+ layout_type (t);
+ return t;
+ }
return NULL_TREE;
}
Index: testsuite/g++.dg/debug/dwarf2/ref-3.C
===================================================================
--- testsuite/g++.dg/debug/dwarf2/ref-3.C (revision 251553)
+++ testsuite/g++.dg/debug/dwarf2/ref-3.C (working copy)
@@ -3,7 +3,7 @@
// { dg-final { scan-assembler-times " DW_AT_reference" 5 { xfail *-*-aix* } } }
// { dg-final { scan-assembler-times " DW_AT_rvalue_reference" 5 { xfail *-*-aix* } } }
// { dg-final { scan-assembler-times "DIE \\(\[^\n\]*\\) DW_TAG_subroutine_type" 6 { xfail *-*-aix* } } }
-// { dg-final { scan-assembler-times "DIE \\(\[^\n\]*\\) DW_TAG_ptr_to_member_type" 7 { xfail *-*-aix* } } }
+// { dg-final { scan-assembler-times "DIE \\(\[^\n\]*\\) DW_TAG_ptr_to_member_type" 13 { xfail *-*-aix* } } }
// { dg-final { scan-assembler-times " DW_AT_use_location" 1 { xfail *-*-aix* } } }
struct S
next reply other threads:[~2017-09-02 11:01 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-02 11:01 Eric Botcazou [this message]
2017-09-02 14:33 ` Richard Biener
2017-09-03 8:05 ` Eric Botcazou
2017-09-03 8:43 ` Richard Biener
2017-09-03 14:16 ` Eric Botcazou
2017-09-04 9:08 ` Richard Biener
2017-09-04 8:08 ` Eric Botcazou
2017-09-09 8:30 ` Jason Merrill
2017-09-22 20:20 ` Eric Botcazou
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=4078981.6jQ9KEkrUD@polaris \
--to=ebotcazou@adacore.com \
--cc=gcc-patches@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).