From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5966 invoked by alias); 1 Apr 2008 14:30:15 -0000 Received: (qmail 5957 invoked by uid 22791); 1 Apr 2008 14:30:14 -0000 X-Spam-Check-By: sourceware.org Received: from NaN.false.org (HELO nan.false.org) (208.75.86.248) by sourceware.org (qpsmtpd/0.31) with ESMTP; Tue, 01 Apr 2008 14:29:50 +0000 Received: from nan.false.org (localhost [127.0.0.1]) by nan.false.org (Postfix) with ESMTP id 11516983BE; Tue, 1 Apr 2008 14:29:49 +0000 (GMT) Received: from caradoc.them.org (22.svnf5.xdsl.nauticom.net [209.195.183.55]) by nan.false.org (Postfix) with ESMTP id EE82A98119; Tue, 1 Apr 2008 14:29:48 +0000 (GMT) Received: from drow by caradoc.them.org with local (Exim 4.69) (envelope-from ) id 1JghUi-0004HN-93; Tue, 01 Apr 2008 10:29:48 -0400 Date: Tue, 01 Apr 2008 14:51:00 -0000 From: Daniel Jacobowitz To: Aleksandar Ristovski Cc: gdb-patches@sourceware.org Subject: Re: [patch] fix for c++/2416 Message-ID: <20080401142948.GE12753@caradoc.them.org> Mail-Followup-To: Aleksandar Ristovski , gdb-patches@sourceware.org References: <47C5A5EE.6070107@qnx.com> <20080227193546.GA11796@caradoc.them.org> <47C5BE84.7050803@qnx.com> <20080227200019.GB12434@caradoc.them.org> <47C5D138.6020909@qnx.com> <20080227220659.GE14556@caradoc.them.org> <47C70319.4050804@qnx.com> <20080228191516.GA8975@caradoc.them.org> <47C78DD3.4080109@qnx.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <47C78DD3.4080109@qnx.com> User-Agent: Mutt/1.5.17 (2007-12-11) X-IsSubscribed: yes Mailing-List: contact gdb-patches-help@sourceware.org; run by ezmlm Precedence: bulk List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: gdb-patches-owner@sourceware.org X-SW-Source: 2008-04/txt/msg00015.txt.bz2 On Thu, Feb 28, 2008 at 11:45:07PM -0500, Aleksandar Ristovski wrote: > Allright, then how about this, yet newer and yet more revisited diff? I > removed changes to eval.c and let it simply call value_cast as it used to. > Now value_cast knows how to handle references. We were converging on a fix and then there's a whole different patch to look at... sorry I couldn't make time until now. > @@ -257,6 +290,7 @@ value_cast_pointers (struct type *type, > return arg2; > } > > + > /* Cast value ARG2 to type TYPE and return as a value. > More general than a C cast: accepts any two types of the same length, > and if ARG2 is an lvalue it can be cast into anything at all. */ Please drop the whitespace change. > @@ -275,6 +309,26 @@ value_cast (struct type *type, struct va > if (value_type (arg2) == type) > return arg2; > > + code1 = TYPE_CODE (check_typedef (type)); > + > + /* Check if we are casting struct reference to struct reference. */ > + if (code1 == TYPE_CODE_REF) > + { > + /* We dereference type; then we recurse and finally > + we generate value of the given reference. Nothing wrong with > + that. */ > + struct type *t1 = check_typedef (type); > + struct type *dereftype = check_typedef (TYPE_TARGET_TYPE (t1)); > + struct value *val = value_cast (dereftype, arg2); > + return value_ref (val); > + } This allows things like "(int&) int_var", by automatically creating references. Should we really do that? -- Daniel Jacobowitz CodeSourcery