PR 29585: C++ front end not setting TREE_ADDRESSABLE on vtbl entries

PR 29585: C++ front end not setting TREE_ADDRESSABLE on vtbl entries

[Diego Novillo]

[-- Attachment #1: Type: text/plain, Size: 1277 bytes --]


As discussed in http://gcc.gnu.org/ml/gcc/2007-03/msg01153.html, the C++
front end is building ADDR_EXPRs for vtbl entries but is not setting
TREE_ADDRESSABLE consistently.

This is causing the setup routines in alias analysis to ignore these
variables.  But during analysis, we add them to points-to and alias
sets.  Since the variables had been initially ignored, they don't get
marked for renaming, causing an ICE during conversion to SSA.

The approach I tried initially is to make the aliaser very strict in
asserting the addressability of every symbol added to an alias set.
This uncovers various inconsistencies in C, C++ and Java FEs.  So, the
idea is to make everything consistent by forcing build1() to set
TREE_ADDRESSABLE every time it's asked to build ADDR_EXPR.  This caused
some controversy, so I will not attempt that on 4.2.

The minimal fix that I found for 4.2 is along the lines of what Mark and
Jason suggested.  I did have to try a variation of Mark's suggestion of
building a NOP_EXPR in dfs_accumulate_vtbl_inits, because that was
causing ICEs elsewhere in other functions not expecting a NOP_EXPR.

Bootstrapped on i686, x86_64, ppc64 and ia64.

OK for 4.2?  For 4.3 I will use the sane approach of forcing
TREE_ADDRESSABLE for every ADDR_EXPR built.

[-- Attachment #2: 20070330-29585.diff --]
[-- Type: text/x-patch, Size: 1274 bytes --]

2007-03-30  Diego Novillo  <dnovillo@redhat.com>
            Mark Mitchell  <mark@codesourcery.com>

	PR 29585
	* class.c (dfs_accumulate_vtbl_inits): Use build_address
	to build the vtbl entry.


testsuite/ChangeLog

	PR 29585
	* g++.dg/tree-ssa/pr29585.C: New test.

Index: testsuite/g++.dg/tree-ssa/pr29585.C
===================================================================
--- testsuite/g++.dg/tree-ssa/pr29585.C	(revision 0)
+++ testsuite/g++.dg/tree-ssa/pr29585.C	(revision 0)
@@ -0,0 +1,15 @@
+/* { dg-do compile } */
+/* { dg-options "-O2" } */
+
+class ios_base{};
+struct basic_ostream : virtual ios_base{};
+namespace
+{
+  struct Nullostream : basic_ostream{};
+}
+class  In
+{
+  In ();
+  Nullostream  nullout;
+};
+In::In (){}
Index: cp/class.c
===================================================================
--- cp/class.c	(revision 123332)
+++ cp/class.c	(working copy)
@@ -7101,7 +7101,7 @@ dfs_accumulate_vtbl_inits (tree binfo,
 
       /* Figure out the position to which the VPTR should point.  */
       vtbl = TREE_PURPOSE (l);
-      vtbl = build1 (ADDR_EXPR, vtbl_ptr_type_node, vtbl);
+      vtbl = build_address (vtbl);
       index = size_binop (PLUS_EXPR,
 			  size_int (non_fn_entries),
 			  size_int (list_length (TREE_VALUE (l))));

Re: PR 29585: C++ front end not setting TREE_ADDRESSABLE on vtbl entries

[Mark Mitchell]

Diego Novillo wrote:

> The approach I tried initially is to make the aliaser very strict in
> asserting the addressability of every symbol added to an alias set.
> This uncovers various inconsistencies in C, C++ and Java FEs.  So, the
> idea is to make everything consistent by forcing build1() to set
> TREE_ADDRESSABLE every time it's asked to build ADDR_EXPR.  This caused
> some controversy, so I will not attempt that on 4.2.

FWIW, I think what you're suggesting is The Right Thing for 4.3.  In the
old days, the addressability of things whose addresses were not really
needed did impact optimization a lot, but I don't see that this should
be true with our new infrastructure.  Look, if you take its address, it
must be addressable. :-p


> 2007-03-30  Diego Novillo  <dnovillo@redhat.com>
>             Mark Mitchell  <mark@codesourcery.com>
> 
> 	PR 29585
> 	* class.c (dfs_accumulate_vtbl_inits): Use build_address
> 	to build the vtbl entry.
> 
> 
> testsuite/ChangeLog
> 
> 	PR 29585
> 	* g++.dg/tree-ssa/pr29585.C: New test.

OK, and thanks!!

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: PR 29585: C++ front end not setting TREE_ADDRESSABLE on vtbl entries

[Mike Stump]

On Mar 31, 2007, at 11:03 AM, Diego Novillo wrote:
> 2007-03-30  Diego Novillo  <dnovillo@redhat.com>
>             Mark Mitchell  <mark@codesourcery.com>
>
> 	PR 29585
> 	* class.c (dfs_accumulate_vtbl_inits): Use build_address
> 	to build the vtbl entry.

I think this patch breaks:

   FAIL: g++.old-deja/g++.mike/p4736b.C (internal compiler error)
   FAIL: g++.old-deja/g++.mike/p4736b.C (test for excess errors)

on powerpc-apple-darwin:

/Volumes/mrs3/net/gcc-4.2-fsf/gcc/gcc/testsuite/g++.old-deja/g++.mike/ 
p4736b.C:
In function 'int main()':
/Volumes/mrs3/net/gcc-4.2-fsf/gcc/gcc/testsuite/g++.old-deja/g++.mike/ 
p4736b.C:41:
internal compiler error: in convert_memory_address, at explow.c:319

:-(

Re: PR 29585: C++ front end not setting TREE_ADDRESSABLE on vtbl entries

[Mike Stump]

On Apr 4, 2007, at 7:00 PM, Mike Stump wrote:
> On Mar 31, 2007, at 11:03 AM, Diego Novillo wrote:
>> 2007-03-30  Diego Novillo  <dnovillo@redhat.com>
>>            Mark Mitchell  <mark@codesourcery.com>
>>
>>    PR 29585
>>    * class.c (dfs_accumulate_vtbl_inits): Use build_address
>>    to build the vtbl entry.
>
> I think this patch breaks:
>
>  FAIL: g++.old-deja/g++.mike/p4736b.C (internal compiler error)
>  FAIL: g++.old-deja/g++.mike/p4736b.C (test for excess errors)
>
> on powerpc-apple-darwin:
>
> /Volumes/mrs3/net/gcc-4.2-fsf/gcc/gcc/testsuite/g++.old-deja/g+ 
> +.mike/p4736b.C:
> In function 'int main()':
> /Volumes/mrs3/net/gcc-4.2-fsf/gcc/gcc/testsuite/g++.old-deja/g+ 
> +.mike/p4736b.C:41:
> internal compiler error: in convert_memory_address, at explow.c:319
>
> :-(

Fixed by the below.  I'll check this in tomorrow unless a maintainer  
of the code thinks it's not obvious or wrong, pretty sure it's better  
than the status quo.  This fixes it as the mode on the type of the  
vtbl goes from being BLKmode back to being what it was before (SImode  
on my machine).  The wrong mode on the decl causes  
convert_memory_address called from memory_address to abort.  The mode  
was taken in expand_one_stack_var_at:

     x = gen_rtx_MEM (DECL_MODE (decl), x);

The reason some people didn't see this is the check only happens when ! 
POINTERS_EXTEND_UNSIGNED.

2007-04-10  Mike Stump  <mrs@apple.com>

	* class.c (dfs_accumulate_vtbl_inits): Fix regressions introduced
	by fix for PR 29585.

2007-04-10  Mike Stump  <mrs@apple.com>

	* g++.dg/tree-ssa/pr29585.C: Don't die on an expected warning.

This is a release blocker for 4.2.0.

Doing diffs in .:
--- ./cp/class.c.~1~	2007-04-04 19:37:15.000000000 -0700
+++ ./cp/class.c	2007-04-10 17:34:46.000000000 -0700
@@ -7108,7 +7108,7 @@ dfs_accumulate_vtbl_inits (tree binfo,
        index = size_binop (MULT_EXPR,
  			  TYPE_SIZE_UNIT (vtable_entry_type),
  			  index);
-      vtbl = build2 (PLUS_EXPR, TREE_TYPE (vtbl), vtbl, index);
+      vtbl = build2 (PLUS_EXPR, vtbl_ptr_type_node, vtbl, index);
      }

    if (ctor_vtbl_p)
--- ./testsuite/g++.dg/tree-ssa/pr29585.C.~1~	2007-04-04  
19:37:14.000000000 -0700
+++ ./testsuite/g++.dg/tree-ssa/pr29585.C	2007-04-10  
17:44:53.000000000 -0700
@@ -1,5 +1,5 @@
  /* { dg-do compile } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -w" } */

  class ios_base{};
  struct basic_ostream : virtual ios_base{};
--------------

Re: PR 29585: C++ front end not setting TREE_ADDRESSABLE on vtbl entries

[Mark Mitchell]

Mike Stump wrote:

> --- ./cp/class.c.~1~    2007-04-04 19:37:15.000000000 -0700
> +++ ./cp/class.c    2007-04-10 17:34:46.000000000 -0700
> @@ -7108,7 +7108,7 @@ dfs_accumulate_vtbl_inits (tree binfo,
>        index = size_binop (MULT_EXPR,
>                TYPE_SIZE_UNIT (vtable_entry_type),
>                index);
> -      vtbl = build2 (PLUS_EXPR, TREE_TYPE (vtbl), vtbl, index);
> +      vtbl = build2 (PLUS_EXPR, vtbl_ptr_type_node, vtbl, index);

That does not look to be type-correct at the tree level; the type of
VTBL + INDEX should be the same as the type of VTBL.  You should
probably be using fold_convert to add the conversion, after the addition.

> I'll check this in tomorrow unless a maintainer of the code thinks it's not obvious or wrong, pretty sure it's better than the status quo.

I think that you should consider recalibrating your obviousness meter.

Thanks,

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: PR 29585: C++ front end not setting TREE_ADDRESSABLE on vtbl entries

[Mike Stump]

On Apr 10, 2007, at 6:13 PM, Mark Mitchell wrote:
> Mike Stump wrote:
>
>> --- ./cp/class.c.~1~    2007-04-04 19:37:15.000000000 -0700
>> +++ ./cp/class.c    2007-04-10 17:34:46.000000000 -0700
>> @@ -7108,7 +7108,7 @@ dfs_accumulate_vtbl_inits (tree binfo,
>>        index = size_binop (MULT_EXPR,
>>                TYPE_SIZE_UNIT (vtable_entry_type),
>>                index);
>> -      vtbl = build2 (PLUS_EXPR, TREE_TYPE (vtbl), vtbl, index);
>> +      vtbl = build2 (PLUS_EXPR, vtbl_ptr_type_node, vtbl, index);
>
> That does not look to be type-correct at the tree level; the type of
> VTBL + INDEX should be the same as the type of VTBL.  You should
> probably be using fold_convert to add the conversion, after the  
> addition.

Yeah, tried that, it didn't work.  If you really want to do that, then  
this would be a step in that direction.  I'll let you judge if you  
want to start down this path:

Doing diffs in .:
--- ./cp/class.c.~1~	2007-04-04 19:37:15.000000000 -0700
+++ ./cp/class.c	2007-04-10 18:51:27.000000000 -0700
@@ -6322,6 +6322,7 @@ get_vtbl_decl_for_binfo (tree binfo)
    tree decl;

    decl = BINFO_VTABLE (binfo);
+  STRIP_NOPS (decl);
    if (decl && TREE_CODE (decl) == PLUS_EXPR)
      {
        gcc_assert (TREE_CODE (TREE_OPERAND (decl, 0)) == ADDR_EXPR);
@@ -7109,6 +7110,7 @@ dfs_accumulate_vtbl_inits (tree binfo,
  			  TYPE_SIZE_UNIT (vtable_entry_type),
  			  index);
        vtbl = build2 (PLUS_EXPR, TREE_TYPE (vtbl), vtbl, index);
+      vtbl = convert (vtbl_ptr_type_node, vtbl);
      }

    if (ctor_vtbl_p)
--- ./testsuite/g++.dg/tree-ssa/pr29585.C.~1~	2007-04-04  
19:37:14.000000000 -0700
+++ ./testsuite/g++.dg/tree-ssa/pr29585.C	2007-04-10  
17:44:53.000000000 -0700
@@ -1,5 +1,5 @@
  /* { dg-do compile } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -w" } */

  class ios_base{};
  struct basic_ostream : virtual ios_base{};
--------------

I've been burned more often by changing the shape of the tree days  
before release than I have by being type unsafe in the manner of the  
previous patch.

Which path do you think is safer for 4.2 given where we are in the  
release cycle?

Re: PR 29585: C++ front end not setting TREE_ADDRESSABLE on vtbl entries

[Mark Mitchell]

Mike Stump wrote:
> On Apr 10, 2007, at 6:13 PM, Mark Mitchell wrote:
>> Mike Stump wrote:
>>
>>> --- ./cp/class.c.~1~    2007-04-04 19:37:15.000000000 -0700
>>> +++ ./cp/class.c    2007-04-10 17:34:46.000000000 -0700
>>> @@ -7108,7 +7108,7 @@ dfs_accumulate_vtbl_inits (tree binfo,
>>>        index = size_binop (MULT_EXPR,
>>>                TYPE_SIZE_UNIT (vtable_entry_type),
>>>                index);
>>> -      vtbl = build2 (PLUS_EXPR, TREE_TYPE (vtbl), vtbl, index);
>>> +      vtbl = build2 (PLUS_EXPR, vtbl_ptr_type_node, vtbl, index);
>>
>> That does not look to be type-correct at the tree level; the type of
>> VTBL + INDEX should be the same as the type of VTBL.  You should
>> probably be using fold_convert to add the conversion, after the addition.
> 
> Yeah, tried that, it didn't work. 

I didn't know that.

> +      vtbl = convert (vtbl_ptr_type_node, vtbl);

That's not the right function to call, even though it probably works;
convert is an ill-defined thing that handles lots of stuff, some of it
C++-specific.  fold_convert is probably what we want.

> I've been burned more often by changing the shape of the tree days
> before release than I have by being type unsafe in the manner of the
> previous patch.

That's a fair point.

However, threatening to check in "obvious" patches that clearly aren't
-- for example, that do something that you know is abstractly wrong,
even if expedient -- is also a risk to the release.  Please consider
"obvious" to mean something more like "every GCC contributor who knows
this code would immediately agree this is correct".

Given that we're looking at a hack, I'd prefer we stick with the hack we
know.  In particular, we used to be introducing the type-unsafety when
creating the ADDR_EXPR, not after the fact.  Diego changed us to use
build_address, which, politely, ensures type-safety, as well as calling
cxx_mark_addressable, which was the key thing to fix this bug.

So, let's just stomp on the type:

  ... build_address (...) ...
  /* ??? We should call fold_convert to convert the address to
     vtbl_ptr_type_node, which is the type of elements in the vtable.
     However, the resulting NOP_EXPRs confuse other parts of the C++
     front end.  */
  gcc_assert (TREE_CODE (vtbl) == ADDR_EXPR);
  TREE_TYPE (vtbl) = vtbl_ptr_type_node;

That patch is OK if it passes testing.  It would be nice if you would
try to fix this correctly for mainline, but if you don't have time, the
ugly hack is OK; it's essentially equivalent to the state before Diego's
change.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: PR 29585: C++ front end not setting TREE_ADDRESSABLE on vtbl entries

[Mike Stump]

On Apr 10, 2007, at 7:18 PM, Mark Mitchell wrote:
> So, let's just stomp on the type:
>
>  ... build_address (...) ...
>  /* ??? We should call fold_convert to convert the address to
>     vtbl_ptr_type_node, which is the type of elements in the vtable.
>     However, the resulting NOP_EXPRs confuse other parts of the C++
>     front end.  */
>  gcc_assert (TREE_CODE (vtbl) == ADDR_EXPR);
>  TREE_TYPE (vtbl) = vtbl_ptr_type_node;
>
> That patch is OK if it passes testing.

Does the patch and results look ok to you?

The init5 used to fail for be before, so, though it is a regression in  
my regtest, it isn't from before the previous change to class.c.   The  
various timeouts are probably safe, probably due to either slow  
network filesystems, or make -j3 check.  encode-8.mm did used to fail  
before, so it is safe.  The oddest result was:

-XPASS: 26_numerics/cmath/c99_classification_macros_c.cc (test for  
excess errors)

?  I don't have a clue.  It _used_ to XPASS for me.

I tested:

	* class.c (dfs_accumulate_vtbl_inits): Slam the vtbl type back to  
vtbl_ptr_type_node
	to ensure the mode is correct.

	* g++.dg/tree-ssa/pr29585.C: Don't die on an expected warning.

Index: testsuite/g++.dg/tree-ssa/pr29585.C
===================================================================
--- testsuite/g++.dg/tree-ssa/pr29585.C	(revision 123722)
+++ testsuite/g++.dg/tree-ssa/pr29585.C	(working copy)
@@ -1,5 +1,5 @@
  /* { dg-do compile } */
-/* { dg-options "-O2" } */
+/* { dg-options "-O2 -w" } */

  class ios_base{};
  struct basic_ostream : virtual ios_base{};
Index: cp/class.c
===================================================================
--- cp/class.c	(revision 123722)
+++ cp/class.c	(working copy)
@@ -7113,6 +7113,12 @@
        /* Figure out the position to which the VPTR should point.  */
        vtbl = TREE_PURPOSE (l);
        vtbl = build_address (vtbl);
+      /* ??? We should call fold_convert to convert the address to
+	 vtbl_ptr_type_node, which is the type of elements in the
+	 vtable.  However, the resulting NOP_EXPRs confuse other parts
+	 of the C++ front end.  */
+      gcc_assert (TREE_CODE (vtbl) == ADDR_EXPR);
+      TREE_TYPE (vtbl) = vtbl_ptr_type_node;
        index = size_binop (PLUS_EXPR,
  			  size_int (non_fn_entries),
  			  size_int (list_length (TREE_VALUE (l))));

and got:

--- mail-report-070411.log	2007-04-11 14:48:38.000000000 -0700
+++ mail-report-070411-ice.log	2007-04-11 13:40:42.000000000 -0700
@@ -6,47 +6,34 @@
  		=== g++ tests ===


  Running target unix
  WARNING: Could not compile g++.dg/compat/struct-layout-1 generator
-FAIL: g++.dg/eh/ctor3.C (test for excess errors)
  FAIL: g++.dg/other/unused1.C scan-assembler (string|ascii?)z?\ 
\t"class2("|\\\\\\\\000)
  FAIL: g++.dg/other/unused1.C scan-assembler (string|ascii?)z?\ 
\t"printer("|\\\\\\\\000)
+WARNING: program timed out.
  XPASS: g++.dg/tree-ssa/ivopts-1.C scan-tree-dump-not offset: -4B
  XPASS: g++.dg/tree-ssa/ivopts-1.C scan-tree-dump-not &x\\[5\\]
-FAIL: g++.dg/tree-ssa/pr29585.C (test for excess errors)
  FAIL: g++.dg/warn/weak1.C (test for excess errors)
  WARNING: g++.dg/warn/weak1.C compilation failed to produce executable
  FAIL: g++.dg/special/conpr-3.C execution test
  WARNING: program timed out.
-FAIL: g++.old-deja/g++.brendan/crash25.C (test for excess errors)
-FAIL: g++.old-deja/g++.mike/p4736b.C (internal compiler error)
-FAIL: g++.old-deja/g++.mike/p4736b.C (test for excess errors)
-WARNING: g++.old-deja/g++.mike/p4736b.C compilation failed to produce  
executable
-FAIL: g++.old-deja/g++.mike/p700.C (test for excess errors)
+FAIL: g++.old-deja/g++.other/init5.C (test for excess errors)

  		=== g++ Summary ===

-# of expected passes		13132
-# of unexpected failures	10
+# of expected passes		13137
+# of unexpected failures	5
  # of unexpected successes	2
  # of expected failures		66
  # of unsupported tests		110
  /Volumes/mrs5/net/gcc-4.2-fsf/gcc-darwinO2/gcc/testsuite/g++/../../g+ 
+  version 4.2.0 20070411 (prerelease)

  		=== gcc tests ===


  Running target unix
-WARNING: program timed out.
-FAIL: gcc.c-torture/compile/20020109-1.c  -O1  (test for excess errors)
-WARNING: program timed out.
-FAIL: gcc.c-torture/execute/20021120-3.c compilation,  -Os
-UNRESOLVED: gcc.c-torture/execute/20021120-3.c execution,  -Os
-WARNING: program timed out.
-FAIL: gcc.c-torture/execute/950511-1.c compilation,  -O3 -fomit-frame- 
pointer
-UNRESOLVED: gcc.c-torture/execute/950511-1.c execution,  -O3 -fomit- 
frame-pointer
  XPASS: gcc.c-torture/execute/mayalias-2.c compilation,  -O3 -g
  FAIL: gcc.dg/sibcall-6.c execution test
  FAIL: gcc.dg/tree-ssa/gen-vect-11b.c scan-tree-dump-times vectorized  
0 loops 1
  FAIL: gcc.dg/tree-ssa/gen-vect-11c.c scan-tree-dump-times vectorized  
0 loops 1
  FAIL: gcc.dg/tree-ssa/loadpre1.c scan-tree-dump-times Eliminated: 1 1
@@ -64,15 +51,14 @@
  FAIL: gcc.target/i386/vectorize1.c (internal compiler error)
  FAIL: gcc.target/i386/vectorize1.c (test for excess errors)

  		=== gcc Summary ===

-# of expected passes		41680
-# of unexpected failures	19
+# of expected passes		41685
+# of unexpected failures	16
  # of unexpected successes	2
  # of expected failures		110
-# of unresolved testcases	2
  # of untested testcases		28
  # of unsupported tests		392
  /Volumes/mrs5/net/gcc-4.2-fsf/gcc-darwinO2/gcc/xgcc  version 4.2.0  
20070411 (prerelease)

  		=== gfortran tests ===
@@ -91,10 +77,12 @@
  FAIL: gfortran.dg/common_equivalence_1.f  -O3 -g  (test for excess  
errors)
  FAIL: gfortran.dg/common_pointer_1.f90  -O3 -g  (test for excess  
errors)
  FAIL: gfortran.dg/contained_1.f90  -O3 -g  (test for excess errors)
  FAIL: gfortran.dg/cray_pointers_2.f90  -O3 -g  (test for excess  
errors)
  FAIL: gfortran.dg/cray_pointers_5.f90  -O3 -g  (test for excess  
errors)
+WARNING: program timed out.
+FAIL: gfortran.dg/direct_io_1.f90  -O0  (test for excess errors)
  FAIL: gfortran.dg/entry_array_specs_2.f  -O3 -g  (test for excess  
errors)
  FAIL: gfortran.dg/equiv_6.f90  -O3 -g  (test for excess errors)
  FAIL: gfortran.dg/f2c_6.f90  -O3 -g  (test for excess errors)
  FAIL: gfortran.dg/loc_1.f90  -O3 -g  (test for excess errors)
  FAIL: gfortran.dg/loc_2.f90  -O3 -g  (test for excess errors)
@@ -136,33 +124,31 @@
  FAIL: gfortran.dg/g77/intrinsic-unix-erf.f  -O3 -g  (test for excess  
errors)
  FAIL: gfortran.dg/g77/short.f  -O3 -g  (test for excess errors)

  		=== gfortran Summary ===

-# of expected passes		15854
-# of unexpected failures	56
+# of expected passes		15853
+# of unexpected failures	57
  # of expected failures		7
  # of unsupported tests		38
  /Volumes/mrs5/net/gcc-4.2-fsf/gcc-darwinO2/gcc/testsuite/ 
gfortran/../../gfortran  version 4.2.0 20070411 (prerelease)

  		=== obj-c++ tests ===


  Running target unix
-WARNING: program timed out.
-FAIL: obj-c++.dg/encode-8.mm (test for excess errors)
  FAIL: obj-c++.dg/stubify-1.mm (test for excess errors)
  ERROR: obj-c++.dg/stubify-1.mm: error executing dg-final: couldn't  
open "stubify-1.s": no such file or directory
  UNRESOLVED: obj-c++.dg/stubify-1.mm: error executing dg-final:  
couldn't open "stubify-1.s": no such file or directory
  FAIL: obj-c++.dg/stubify-2.mm (test for excess errors)
  ERROR: obj-c++.dg/stubify-2.mm: error executing dg-final: couldn't  
open "stubify-2.mm.08.jump": no such file or directory
  UNRESOLVED: obj-c++.dg/stubify-2.mm: error executing dg-final:  
couldn't open "stubify-2.mm.08.jump": no such file or directory

  		=== obj-c++ Summary ===

-# of expected passes		460
-# of unexpected failures	3
+# of expected passes		461
+# of unexpected failures	2
  # of unresolved testcases	2
  /Volumes/mrs5/net/gcc-4.2-fsf/gcc-darwinO2/gcc/testsuite/obj-c+ 
+/../../g++  version 4.2.0 20070411 (prerelease)

  		=== objc tests ===

@@ -295,11 +281,10 @@
  FAIL: 23_containers/vector/invalidation/2.cc execution test
  FAIL: 23_containers/vector/invalidation/3.cc execution test
  FAIL: 23_containers/vector/invalidation/4.cc execution test
  FAIL: 23_containers/vector/modifiers/swap/2.cc (test for excess  
errors)
  FAIL: 23_containers/vector/modifiers/swap/3.cc (test for excess  
errors)
-XPASS: 26_numerics/cmath/c99_classification_macros_c.cc (test for  
excess errors)
  FAIL: backward/strstream_members.cc execution test
  FAIL: ext/bitmap_allocator/check_allocate_max_size.cc (test for  
excess errors)
  FAIL: ext/bitmap_allocator/check_deallocate_null.cc (test for excess  
errors)
  FAIL: ext/bitmap_allocator/check_delete.cc (test for excess errors)
  FAIL: ext/mt_allocator/check_allocate_big_per_type.cc (test for  
excess errors)
@@ -382,12 +367,12 @@

  		=== libstdc++ Summary ===

  # of expected passes		3693
  # of unexpected failures	140
-# of unexpected successes	3
-# of expected failures		13
+# of unexpected successes	2
+# of expected failures		14
  # of unsupported tests		318

  Compiler version: 4.2.0 20070411 (prerelease)
  Platform: i686-apple-darwin9
  configure flags: --with-arch=nocona --with-tune=generic --prefix=/ 
tmp/gcc-061220 --build=i686-apple-darwin9 --host=i686-apple-darwin9 -- 
enable-languages=c,c++,fortran,objc,obj-c++,treelang

Re: PR 29585: C++ front end not setting TREE_ADDRESSABLE on vtbl entries

[Mark Mitchell]

Mike Stump wrote:
> On Apr 10, 2007, at 7:18 PM, Mark Mitchell wrote:
>> So, let's just stomp on the type:
>>
>>  ... build_address (...) ...
>>  /* ??? We should call fold_convert to convert the address to
>>     vtbl_ptr_type_node, which is the type of elements in the vtable.
>>     However, the resulting NOP_EXPRs confuse other parts of the C++
>>     front end.  */
>>  gcc_assert (TREE_CODE (vtbl) == ADDR_EXPR);
>>  TREE_TYPE (vtbl) = vtbl_ptr_type_node;
>>
>> That patch is OK if it passes testing.
> 
> Does the patch and results look ok to you?

Yes, this is OK; thanks.

I don't know what to say about some of the changes in results that you
saw.  Are you sure the only change to your environment between test runs
was the patch in question?  Certainly, the init5.C change seems odd, as
that test has no virtual functions.  However, since the patch looks
correct to me, I think it is OK.

-- 
Mark Mitchell
CodeSourcery
mark@codesourcery.com
(650) 331-3385 x713

Re: PR 29585: C++ front end not setting TREE_ADDRESSABLE on vtbl entries

[Eric Christopher]

>
> 2007-04-10  Mike Stump  <mrs@apple.com>
>
> 	* class.c (dfs_accumulate_vtbl_inits): Fix regressions introduced
> 	by fix for PR 29585.

Uh, how about a better changelog entry? You know, one that says what
you did instead of why? :)

-eric