From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 5242 invoked by alias); 3 Nov 2014 21:22:22 -0000 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 Received: (qmail 5231 invoked by uid 89); 3 Nov 2014 21:22:21 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-3.1 required=5.0 tests=AWL,BAYES_00,RCVD_IN_DNSWL_LOW,RP_MATCHES_RCVD,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mail-ob0-f177.google.com Received: from mail-ob0-f177.google.com (HELO mail-ob0-f177.google.com) (209.85.214.177) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with (AES128-SHA encrypted) ESMTPS; Mon, 03 Nov 2014 21:22:20 +0000 Received: by mail-ob0-f177.google.com with SMTP id m8so9441696obr.36 for ; Mon, 03 Nov 2014 13:22:18 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=ZDVrxwBWaVyQbI2ucAf9b4QlG/PvTNmY53E6DdFI7iQ=; b=Qm93OZolI33+VqwkBahWTVLIm8plKajsfI5VYC46bgl8cEWHkoxEjHe1CQsNICkBJQ N8pSJkpE6eRqsX8FfNNzcvi4dmzXRzH7Pmt+bhMz5p0oVi2DpCuR3frqmZyQZV9OL1ns TsLmSX6ufkq7A6fhKErv0tVItzDSt0sMb2xdcHUFWQ9wmGUXOMbhCokMSrOBqw7Hmu7H /R9tOVGrxaZDEiCBW2wxxtNo5vyHp6GuMy3T7e99fqDRHqjM481TuO1i4RR35aNS0ImN hIU89lv9orEPA3JeXTKyocrBXNduU2j6IlYq9DlLiLzPtX8dT+degI0sigG3zuc/DLDq 0w1g== X-Gm-Message-State: ALoCoQmyyjj6y7s9YJAMFQK4c7TuFICq2YEfWcJt1TSjEKxT3/QUw41TQl8BIwubyQNQsve6z8rb MIME-Version: 1.0 X-Received: by 10.60.69.131 with SMTP id e3mr38880202oeu.0.1415049738354; Mon, 03 Nov 2014 13:22:18 -0800 (PST) Received: by 10.202.197.13 with HTTP; Mon, 3 Nov 2014 13:22:18 -0800 (PST) In-Reply-To: References: <201411031443.sA3EhfqM019330@d06av02.portsmouth.uk.ibm.com> Date: Mon, 03 Nov 2014 21:22:00 -0000 Message-ID: Subject: Re: [PATCH v4] Make chained function calls in expressions work From: Siva Chandra To: Ulrich Weigand Cc: gdb-patches Content-Type: text/plain; charset=UTF-8 X-IsSubscribed: yes X-SW-Source: 2014-11/txt/msg00054.txt.bz2 On Mon, Nov 3, 2014 at 11:55 AM, Siva Chandra wrote: >>>+/* Return true is T is a class or a union. False otherwise. */ >>>+ >>>+int >>>+class_or_union_p (const struct type *t) >>>+{ >>>+ return (TYPE_CODE (t) == TYPE_CODE_STRUCT >>>+ || TYPE_CODE (t) == TYPE_CODE_UNION); >>>+} >> >> I understand we need to do this for classes with member functions (so that >> f().g() will work) -- do we really need it for classes without member >> functions (or plain C structs)? > > We could have a struct like this in C++: > > struct Derived : public virtual Base > { > ... > }; > > Do you mean we should have a language check before reserving space on the stack? Sorry for revisiting but I thought I can be a bit more elaborate on this. To complete the example, I am talking about a case like this: struct Base { int base; }; struct Derived : public virtual Base { int derived; }; Derived does not have any methods, but will be returned in a hidden param as it has a virtual base class. Even for simple structs like this: struct Simple { int simple; }; the return value could be a reference argument for a subsequent inferior function and hence would still need to be have an address.