public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Janis Johnson <janis187@us.ibm.com>
To: gcc@gcc.gnu.org, nathan@codesourcery.com, mark@codesourcery.com
Subject: patches that caused/fixed regression PR c++/8205 (still broken in 3.2 branch)
Date: Mon, 23 Dec 2002 10:32:00 -0000	[thread overview]
Message-ID: <20021223095028.C15405@us.ibm.com> (raw)

The regression reported in PR c++/8205 still exists on the 3.2 branch.
The patch that caused the bug to show up, and the patch that caused it
to go away on the mainline, are shown here.  They are both very large
so it's quite likely that this information isn't very useful.

Here's the patch that caused the regression to show up:

2001-11-25  Nathan Sidwell  <nathan@codesourcery.com>

	PR g++/3145
	* class.c (build_vbase_pointer): Remove.
	(build_vbase_path): Remove.
	(build_base_path): New function.
	* cp-tree.h (base_access, base_kind): New enumerations.
	(build_base_path): Declare.
	(convert_pointer_to_real): Remove.
	(convert_pointer_to): Remove.
	(lookup_base): Declare.
	(convert_pointer_to_vbase): Remove.
	* call.c (build_scoped_method_call): Use lookup_base &
	build_base_path instead of convert_pointer_to_real,
	get_base_distance & get_binfo.
	(build_over_call): Likewise.
	* cvt.c (cp_convert_to_pointer): Likewise.
	(convert_to_pointer_force): Likewise.
	(build_up_reference): Likewise.
	(convert_pointer_to_real): Remove.
	(convert_pointer_to): Remove.
	* init.c (dfs_initialize_vtbl_ptrs): Use build_base_path
	instead of convert_pointer_to_vbase & build_vbase_path.
	(emit_base_init): Use build_base_path instead of
	convert_pointer_to_real.
	(expand_virtual_init): Lose unrequired conversions.
	(resolve_offset_ref): Use lookup_base and build_base_path
	instead of convert_pointer_to.
	* rtti.c (build_dynamic_cast_1): Use lookup_base &
	build_base_path instead of get_base_distance & build_vbase_path.
	* search.c (get_vbase_1): Remove.
	(get_vbase): Remove.
	(convert_pointer_to_vbase): Remove.
	(lookup_base_recursive): New function.
	(lookup_base): New function.
	* typeck.c (require_complete_type): Use lookup_base &
	build_base_path instead of convert_pointer_to.
	(build_component_ref): Likewise.
	(build_x_function_call): Likewise.
	(get_member_function_from_ptrfunc): Likewise.
	(build_component_addr): Likewise.
	* typeck2.c (build_scoped_ref): Likewise.

Here's the patch that caused it to go away on the mainline:

2002-08-07  Mark Mitchell  <mark@codesourcery.com>

	Rework build_component_ref.
	* call.c (build_vfield_ref): Do not go through build_component_ref.
	(build_field_call): Use build_class_member_access_expr.
	(build_user_type_conversion_1): Use BASELINK_FUNCTIONS.
	(build_object_call): Likewise.
	* class.c (convert_to_base): New function.
	(type_requires_array_cookie): Use BASELINK_FUNCTIONS.
	(instantiate_type): Handle BASELINKs.
	* cp-tree.def (BASELINK): New tree code.
	* cp-tree.h (BASELINK_P): Reimplement.
	(SET_BASELINK_P): Remove.
	(BASELINK_BINFO): Reimplement.
	(BASELINK_FUNCTIONS): Likewise.
	(BASELINK_ACCESS_BINFO): Likewise.
	(BASELINK_OPTYPE): Likewise.
	(convert_to_base): New function.
	(name_p): Likewise.
	(build_object_ref): Remove.
	(build_component_ref_1): Likewise.
	(build_component_ref): Likewise.
	(build_x_component_ref): Likewise.
	(build_class_member_access_expr): New function.
	(finish_class_member_access_expr): Likewise.
	(build_ptrmemfunc_access_expr): Likewise.
	* decl.c (grokdeclarator): Handle BASELINKs.
	* decl2. (build_expr_from_tree): Handle COMPONENT_REFs by using
	finish_class_member_access_expr.
	(arg_assoc): Handle BASELINKs.
	(do_class_using_decl): Likewise.
	* error.c (dump_decl): Likewise.
	(dump_expr): Use build_ptrmemfunc_access_expr.
	* except.c (dtor_nothrow): Use CLASSTYPE_DESTRUCTORS to find
	destructors.
	(build_throw): Use BASELINK_FUNCTIONS.
	* init.c (perform_member_init): Use
	build_class_member_access_expr.
	(build_offset_ref): Handle BASELINKs.  Use
	build_class_member_access_expr.
	* method.c (hack_identifier): Likewise.
	* parse.y (do_id): Use BASELINK, not TREE_LIST.
	(primary): Remove uses of build_object_ref.
	* pt.c (lookup_template_function): Handle BASELINKs.
	(resolve_overloaded_unification): Likewise.
	* search.c (build_baselink): Build a BASELINK, not a TREE_LIST.
	(lookup_field): Use BASELINK, not TREE_LIST.
	(lookup_fnfiels): Likewise.
	(setup_class_bindings): Likewise.
	* semantics.c (finish_object_call_expr): Do not use
	build_method_call when we already know what function is being
	called.
	* spew.c (identifier_type): Use BASELINK, not TREE_LIST.
	* tree.c (really_overloaded_fn): Use OVL_CHAIN for OVERLOADs, not
	TREE_CHAIN.
	(name_p): New function.
	* typeck.c (build_object_ref): Remove.
	(build_component_ref_1): Likewise.
	(build_x_component_ref): Likewise.
	(build_class_member_access_expr): New function.
	(finish_class_member_access_expr): Likewise.
	(build_ptrmemfunc_access_expr): Likewise.
	(get_member_function_from_ptrfunc): Use
	build_ptrmemfunc_access_expr.
	(build_binary_op): Likewise.
	(build_unary_op): Likewise.
	(build_ptrmemfunc): Likewise.
	(pfn_from_ptrmemfunc): Likewise.
	* typeck2.c (build_m_component_ref): Adjust comment.

Here's a small test case that causes the compiler to complain about
valid code on i686-linux with the 3.2 branch cc1plus:

-------------------
class A { public: int i; };
class B {};
class E : A, B { public: using A::i; };

int main() {
  E e;
  e.i; // "`A' is an inaccessible base of `E'"
}
-------------------

Output from the 3.2 branch compiler:

8205.C: In function `int main()':
8205.C:7: `A' is an inaccessible base of `E'

I've added this information to the PR.

Janis

                 reply	other threads:[~2002-12-23 17:48 UTC|newest]

Thread overview: [no followups] expand[flat|nested]  mbox.gz  Atom feed

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=20021223095028.C15405@us.ibm.com \
    --to=janis187@us.ibm.com \
    --cc=gcc@gcc.gnu.org \
    --cc=mark@codesourcery.com \
    --cc=nathan@codesourcery.com \
    /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).