Re: c++/5607: No pointer adjustment in covariant return types (PATCH)

Re: c++/5607: No pointer adjustment in covariant return types (PATCH)

[Jason Merrill]

The following reply was made to PR c++/5607; it has been noted by GNATS.

From: Jason Merrill <jason@redhat.com>
To: gcc-patches@gcc.gnu.org
Cc: gcc-gnats@gcc.gnu.org
Subject: Re: c++/5607: No pointer adjustment in covariant return types
 (PATCH)
Date: Thu, 25 Apr 2002 19:02:54 +0100

 --=-=-=
 
 This is a known unimplimented feature, but we should have rejected your
 testcase with a sorry message.  We failed to do so because we were checking
 the vbase offset before we had calculated it.  This patch causes us to
 check later as well.
 
 Tested i686-pc-linux-gnu, applied to trunk.  Mark, do you think this should
 go into 3.1?  It's not a regression, but I don't like silently generating
 bad code...
 
 2002-04-25  Jason Merrill  <jason@redhat.com>
 
 	PR c++/5607
 	* search.c (check_final_overrider): No longer static.
 	* class.c (update_vtable_entry_for_fn): Call it.
 	* cp-tree.h: Adjust.
 
 
 --=-=-=
 Content-Type: text/x-patch
 Content-Disposition: inline
 
 *** class.c.~1~	Thu Apr 18 14:16:46 2002
 --- class.c	Thu Apr 25 12:24:06 2002
 *************** update_vtable_entry_for_fn (t, binfo, fn
 *** 2555,2560 ****
 --- 2555,2564 ----
     if (overrider == error_mark_node)
       return;
   
 +   /* Check for unsupported covariant returns again now that we've
 +      calculated the base offsets.  */
 +   check_final_overrider (TREE_PURPOSE (overrider), fn);
 + 
     /* Assume that we will produce a thunk that convert all the way to
        the final overrider, and not to an intermediate virtual base.  */
     virtual_base = NULL_TREE;
 *** cp-tree.h.~1~	Thu Apr 25 01:19:30 2002
 --- cp-tree.h	Thu Apr 25 12:21:04 2002
 *************** extern tree lookup_conversions			PARAMS 
 *** 4099,4104 ****
 --- 4099,4105 ----
   extern tree binfo_for_vtable			PARAMS ((tree));
   extern tree binfo_from_vbase			PARAMS ((tree));
   extern tree look_for_overrides_here		PARAMS ((tree, tree));
 + extern int check_final_overrider		PARAMS ((tree, tree));
   extern tree dfs_walk                            PARAMS ((tree,
   						       tree (*) (tree, void *),
   						       tree (*) (tree, void *),
 *** search.c.~1~	Thu Apr 18 14:52:10 2002
 --- search.c	Thu Apr 25 12:20:38 2002
 *************** static tree dfs_push_decls PARAMS ((tree
 *** 100,106 ****
   static tree dfs_unuse_fields PARAMS ((tree, void *));
   static tree add_conversions PARAMS ((tree, void *));
   static int covariant_return_p PARAMS ((tree, tree));
 - static int check_final_overrider PARAMS ((tree, tree));
   static int look_for_overrides_r PARAMS ((tree, tree));
   static struct search_level *push_search_level
   	PARAMS ((struct stack_level *, struct obstack *));
 --- 100,105 ----
 *************** covariant_return_p (brettype, drettype)
 *** 1798,1804 ****
   /* Check that virtual overrider OVERRIDER is acceptable for base function
      BASEFN. Issue diagnostic, and return zero, if unacceptable.  */
   
 ! static int
   check_final_overrider (overrider, basefn)
        tree overrider, basefn;
   {
 --- 1797,1803 ----
   /* Check that virtual overrider OVERRIDER is acceptable for base function
      BASEFN. Issue diagnostic, and return zero, if unacceptable.  */
   
 ! int
   check_final_overrider (overrider, basefn)
        tree overrider, basefn;
   {
 
 --=-=-=--

Re: c++/5607: No pointer adjustment in covariant return types (PATCH)

[Mark Mitchell]

The following reply was made to PR c++/5607; it has been noted by GNATS.

From: Mark Mitchell <mark@codesourcery.com>
To: Jason Merrill <jason@redhat.com>,
   "gcc-patches@gcc.gnu.org" <gcc-patches@gcc.gnu.org>
Cc: "gcc-gnats@gcc.gnu.org" <gcc-gnats@gcc.gnu.org>
Subject: Re: c++/5607: No pointer adjustment in covariant return types
 (PATCH)
Date: Thu, 25 Apr 2002 14:56:55 -0700

 > Tested i686-pc-linux-gnu, applied to trunk.  Mark, do you think this
 > should go into 3.1?  It's not a regression, but I don't like silently
 > generating bad code...
 
 Me neither, but it's not the only place.  Let's hold off.
 
 Thanks,
 
 --
 Mark Mitchell                   mark@codesourcery.com
 CodeSourcery, LLC               http://www.codesourcery.com