diff mbox

C++ PATCH for c++/51917 (wrong tinfo hints on some targets)

Message ID 4F1F8766.1080009@redhat.com
State New
Headers show

Commit Message

Jason Merrill Jan. 25, 2012, 4:39 a.m. UTC 
As it turns out, this bug depended on vector allocation size. 
xref_basetypes asks for space for a certain number of bases, then fills 
up the vector, and assumes that if there's any space left we must have 
hit a shared virtual base, i.e. diamond-shaped inheritance.  But since 
my vec.c patch for PR 14179, when we allocate a vector we get back a 
vector with the number of slots that fill the memory we get from the 
allocator, rather than the exact number of slots we asked for.  So if 
those don't match, the compiler thinks that we're sharing.

Fixed by directly comparing the number of slots filled to the number of 
slots expected.  Tested x86_64-pc-linux-gnu, applying to trunk.
diff mbox

Patch

commit 8860243111f961b8f1d37238cd28ed82516b1927
Author: Jason Merrill <jason@redhat.com>
Date:   Tue Jan 24 22:05:52 2012 -0500

    	PR c++/51917
    	* decl.c (xref_basetypes): Check VEC_length instead of VEC_space.

diff --git a/gcc/cp/decl.c b/gcc/cp/decl.c
index ef43dbf..7fba04a 100644
--- a/gcc/cp/decl.c
+++ b/gcc/cp/decl.c
@@ -11916,8 +11916,8 @@  xref_basetypes (tree ref, tree base_list)
       BINFO_BASE_ACCESS_APPEND (binfo, access);
     }
 
-  if (VEC_space (tree, CLASSTYPE_VBASECLASSES (ref), 1))
-    /* If we have space in the vbase vector, we must have shared at
+  if (VEC_length (tree, CLASSTYPE_VBASECLASSES (ref)) < max_vbases)
+    /* If we didn't get max_vbases vbases, we must have shared at
        least one of them, and are therefore diamond shaped.  */
     CLASSTYPE_DIAMOND_SHAPED_P (ref) = 1;