From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 15091 invoked by alias); 16 Oct 2013 13:32:52 -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 15081 invoked by uid 89); 16 Oct 2013 13:32:52 -0000 Authentication-Results: sourceware.org; auth=none X-Virus-Found: No X-Spam-SWARE-Status: No, score=-4.4 required=5.0 tests=AWL,BAYES_00,RP_MATCHES_RCVD,SPF_HELO_PASS,SPF_PASS autolearn=ham version=3.3.2 X-HELO: mx1.redhat.com Received: from mx1.redhat.com (HELO mx1.redhat.com) (209.132.183.28) by sourceware.org (qpsmtpd/0.93/v0.84-503-g423c35a) with ESMTP; Wed, 16 Oct 2013 13:32:51 +0000 Received: from int-mx02.intmail.prod.int.phx2.redhat.com (int-mx02.intmail.prod.int.phx2.redhat.com [10.5.11.12]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id r9GDWnxY017438 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Wed, 16 Oct 2013 09:32:49 -0400 Received: from host2.jankratochvil.net (ovpn-116-26.ams2.redhat.com [10.36.116.26]) by int-mx02.intmail.prod.int.phx2.redhat.com (8.13.8/8.13.8) with ESMTP id r9GDWjOe002491 (version=TLSv1/SSLv3 cipher=AES128-SHA bits=128 verify=NO); Wed, 16 Oct 2013 09:32:47 -0400 Date: Wed, 16 Oct 2013 13:32:00 -0000 From: Jan Kratochvil To: Tom Tromey Cc: gdb-patches@sourceware.org, Jonathan Wakely Subject: Re: [patch] Support C++11 rvalue (move constructor) Message-ID: <20131016133245.GA10846@host2.jankratochvil.net> References: <20131012152836.GA9438@host2.jankratochvil.net> <87fvs33kb7.fsf@fleche.redhat.com> <20131014175747.GA9176@host2.jankratochvil.net> <87hacj1zsk.fsf@fleche.redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <87hacj1zsk.fsf@fleche.redhat.com> User-Agent: Mutt/1.5.21 (2010-09-15) X-IsSubscribed: yes X-SW-Source: 2013-10/txt/msg00484.txt.bz2 On Mon, 14 Oct 2013 20:18:51 +0200, Tom Tromey wrote: > >> Is that also true for inferior calls? > >> I didn't look. > > Jan> GDB cannot call constructors so this is irrelevant now. > > I'm not sure constructors matter. rvalue references affect overloading, > e.g.: > > #include > > int ov(int &x) { return 0; } > int ov(int &&x) { return 1; } > > int main() { > int z = 23; > printf ("%d %d\n", ov(z), ov(23)); > } OK, true. I see && already works fine due to the C++11 libiberty/ demangler. (gdb) complete p 'ov p 'ov(int&&) p 'ov(int&) Just inferior calls pick randomly the function depending on their order in source (in DWARF): (gdb) p ov(z) $1 = 0 vs. (gdb) p ov(z) $1 = 1 This means we should really have two distinct TYPE_CODEs and then properly select lvalue vs. rvalue function depending on the type of argument used passed for the inferior call. Possibly failing to find the function if function only accepts rvalue but user passes in real variable (lvalue). The patch is definitely incorrect as is but I would say it is better than nothing. The proper rvalue implementation is some work and I would say I have other work to do. > Tom> Maybe the size increase isn't that important. > > Jan> I always thought the opposite is true. > Jan> Due to CU expansion with after some completions one easily gets to > Jan> 1GB GDB and more (but IMO this is a bug should not expand CUs). > > I think what's missing is an idea of the amount that struct main_type > contributes. > > My recollection is that I concluded that shrinking types wasn't > worthwhile. However, it's worthwhile to redo the experiment, at least > if you plan to completely fix this problem. I find clear the CU expansion should be fixed. Then maybe GDB stops growing. Or maybe not (and then one has to look more at main_type...). Jan