From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 21811 invoked by alias); 4 Aug 2009 04:39:50 -0000 Received: (qmail 21789 invoked by uid 22791); 4 Aug 2009 04:39:48 -0000 X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_00,SPF_PASS X-Spam-Check-By: sourceware.org Received: from qw-out-1920.google.com (HELO qw-out-1920.google.com) (74.125.92.146) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 Aug 2009 04:39:40 +0000 Received: by qw-out-1920.google.com with SMTP id 5so1838993qwc.14 for ; Mon, 03 Aug 2009 21:39:38 -0700 (PDT) Received: by 10.224.60.69 with SMTP id o5mr5555816qah.28.1249360778231; Mon, 03 Aug 2009 21:39:38 -0700 (PDT) Received: from ?192.168.10.200? (r74-192-213-54.bcstcmta02.clsttx.tl.dh.suddenlink.net [74.192.213.54]) by mx.google.com with ESMTPS id 7sm14444326qwf.18.2009.08.03.21.39.36 (version=TLSv1/SSLv3 cipher=RC4-MD5); Mon, 03 Aug 2009 21:39:37 -0700 (PDT) Message-ID: <4A77BB84.8000101@gmail.com> Date: Tue, 04 Aug 2009 05:39:00 -0000 From: John Freeman User-Agent: Thunderbird 2.0.0.17 (Windows/20080914) MIME-Version: 1.0 To: Jason Merrill CC: Adam Butcher , adam.butcher@selex-comms.com, Esben Mose Hansen , gcc@gcc.gnu.org Subject: Re: [lambda] Segmentation fault in simple lambda program References: <1248855585.29221.ezmlm@gcc.gnu.org> <4A772D0F.5010804@redhat.com> <4A77B130.2080302@redhat.com> In-Reply-To: <4A77B130.2080302@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org X-SW-Source: 2009-08/txt/msg00050.txt.bz2 I haven't been following GCC, so I need to thank Jason for forwarding this issue to me. I just read through the messages on the list, and had some more comments: > + /* relayout again -- to allow for implicit > + * parameters to have been added to the capture if it was a > + * 'default capture' -- note that this would not be necessary if > + * the stack-pointer variant was implemented -- since the layout > + * would be known. > + * Relayingout here might have nasty effect if one were to query > + * sizeof *this from within the body -- would that even be > + * possible -- *this would refer to the lambda or the enclosing > + * class instance -- if there was one.??? > + * > + * NOTE: I think this is a redefinition error; I'm just faking that > + * it isn't by clearing the size node... need to use stack pointer > + * method. But that will likely bring its own issues -- not with > + * class layout though. > + */ > + TYPE_SIZE (type) = NULL_TREE; > + finish_struct_1 (type); Relaying out the class after the lambda body was parsed is something I had attempted to do, but possibly failed at. It will absolutely need to be done. > The way 'default reference capture' is implemented on the lambda branch seems to be kind of reactive. I would expect > that inheriting the stack somehow (maybe using just a stack pointer) would be better but without more investigation I > don't know if that is possible or how one would go about doing it. This won't be suitable in the general case, because of the copy default capture [=]. Implicit captures will have to be reactive. > /* > * Rather than looping through the identifiers used in the scope of > * the lambda and synthesizing individual captures of them, it would > * be better to ref the stack frame as transparently as possible... > * e.g. given just three ints i, j and k in scope: > * Instead of transforming: > * > * [&] { i = 1; j = 2; k = 3; }; > * > * into > * > * [&i,&j,&k] { i = 1; j = 2; k = 3; }; > * > * and thus storing three pointers to int, transform it into: > * > * [sp=enclosing-stack-pointer] { var-from-stack(i,sp) = 1; > * var-from-stack(j,sp) = 2; > * var-from-stack(k,sp) = 3; }; > * > * and only store one pointer. This is preferred for reference default captures, but I was not familiar with stack pointer mechanics in GCC. I just wanted to get something working first that could be improved later. > * I don't know if its possible but it may be possible to 'append' > * the lambda's stack to the existing scope rather than creating a > * new constrained scope -- from a logical point of view. Again, this is not suitable to the general case because a lambda can outlast its enclosing scope. > My motivation for investigating is that I consider constraining lambdas to be monomorphic significantly reduces their > usefulness. I'm sure there are many good reasons why the committee decided that it was the way to go. I don't think it handicaps lambdas as much as some may believe, but still wanted polymorphic lambdas as well. There were just too many issues with deduction. When I last left the discussion, the biggest issue in my opinion was concept map dropping. The workaround made the deduction algorithm intimidatingly complex. > The following program generates the expected code and runs correctly. > auto f = [&] (T n, T const& m, U u) { i = ++n; j = u(++n); k = ++n; }; > This is exciting. The main thing I failed to add was dependent type support, so I want to check this out. (I need to register a new ssh key) - John