public inbox for gcc-patches@gcc.gnu.org
 help / color / mirror / Atom feed
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

             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).