From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 11524 invoked by alias); 4 Aug 2009 03:55:43 -0000 Received: (qmail 11512 invoked by uid 22791); 4 Aug 2009 03:55:42 -0000 X-SWARE-Spam-Status: No, hits=-2.5 required=5.0 tests=AWL,BAYES_00,SPF_HELO_PASS,SPF_PASS X-Spam-Check-By: sourceware.org Received: from mx2.redhat.com (HELO mx2.redhat.com) (66.187.237.31) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 04 Aug 2009 03:55:34 +0000 Received: from int-mx2.corp.redhat.com (int-mx2.corp.redhat.com [172.16.27.26]) by mx2.redhat.com (8.13.8/8.13.8) with ESMTP id n743tV7G022253; Mon, 3 Aug 2009 23:55:32 -0400 Received: from ns3.rdu.redhat.com (ns3.rdu.redhat.com [10.11.255.199]) by int-mx2.corp.redhat.com (8.13.1/8.13.1) with ESMTP id n743tUsb005870; Mon, 3 Aug 2009 23:55:30 -0400 Received: from [IPv6:::1] (sebastian-int.corp.redhat.com [172.16.52.221]) by ns3.rdu.redhat.com (8.13.8/8.13.8) with ESMTP id n743tSgM005006; Mon, 3 Aug 2009 23:55:29 -0400 Message-ID: <4A77B130.2080302@redhat.com> Date: Tue, 04 Aug 2009 04:11:00 -0000 From: Jason Merrill User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.1.3pre) Gecko/20090802 Shredder/3.0b4pre MIME-Version: 1.0 To: Adam Butcher CC: adam.butcher@selex-comms.com, Esben Mose Hansen , gcc@gcc.gnu.org, jfreeman08@gmail.com Subject: Re: [lambda] Segmentation fault in simple lambda program References: <1248855585.29221.ezmlm@gcc.gnu.org> <4A772D0F.5010804@redhat.com> In-Reply-To: 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/msg00048.txt.bz2 On 08/03/2009 09:36 PM, Adam Butcher wrote: > Thanks. I haven't any copyright assignments on file -- this is my first dabbling with gcc and I've been doing it > mostly to experiment with C++ lambda support and non-standard extensions such as polymorphic lambda support. OK. We'll need an assignment in order to incorporate your changes into GCC. If you want to assign all present and future changes to the compiler, you could use the form http://git.savannah.gnu.org/cgit/gnulib.git/tree/doc/Copyright/request-assign.future > Cool. I've been working in my own repository which I rebased earlier today from trunk (r150148). I've attached the > rebase including the fix for generating correct copying of lambda classes (re-laying out after parsing body). Hmm, having the new changes folded into the old changes is kind of inconvenient, but I suppose I can deal. It's moot anyway until your assignment is on file. Incidentally, comments like /* * * */ aren't customary in GCC sources; that's just something John did that we'll need to clean up before the code goes into the trunk. There are other formatting irregularities, some of which I've corrected. > It also > fixes return type deduction which didn't work after updating to 4.5 as build_lang_decl no longer accepts DECL_RESULT > (I replaced it with build_decl directly which seemed to work fine). There were a few other things like placement of > GTY (()) and replacing preservation of skip_evaluation with preservation of cp_unevaluated_operand and > c_inhibit_evaluation_warnings (which seems to have been what's occurred in other places). Oops, and I checked in my merge without even testing that it would build...guess I'd better fix it. > Experimenting with a working version and seeing it's issues will be useful to me. To others to maybe. With concepts > gone from C++0x and being reworked for C++15(?) maybe support for polymorphic lambdas could be reintroduced? -- though > I'm sure its much too late for that and that its likely been around the buoy many times. From what I have read I got > the idea that the Callable concept was the primary reason for polymorphic lambdas not being accepted. I don't know what the reasoning was there, but people have been somewhat conservative about what usages of lambdas are allowed for fear of unforseen implementation issues. Certainly having a working implementation would go a lot toward convincing people to allow it, even if it doesn't make it into C++0x. > Implied template typename arguments via auto are not currently supported. The syntax parses but I haven't yet > synthesized the template arguments and therefore not replaced the auto's with them so it doesn't compile. Since templates work so differently from normal functions, I'm a little uncomfortable with the idea of templates that don't involve any template syntax, just the use of auto in the parameter list. But I'm open to giving it a try, at least in the lambda context. Maybe outside of lambda it could be used with a small template introducer... > I'd welcome feedback on the syntax and semantics and of course any fundamental things I've missed by coming up with > such a syntax! > > From a grammar point of view I've just expanded lambda-parameter-declaration to start with: > lambda-template-param-decl [opt] > where lambda-template-param-decl is: > < template-parameter-list> Makes sense. I suppose to specify explicit template arguments users would have to write lambdaob.operator()(fn-arg) so we'd really expect them to be only deduced. > # unspecified typename inferred by use of auto in function parameter list > [=] (auto* x, YY y) { return x->Func( y, a, b ); }; > # is translated into > [=] (X* x, YY y) { return x->Func( y, a, b ); }; A mixed declaration like that seems rather ugly to me; I'd hope that people would use either explicit template args or auto in a particular lambda, not both. But I suppose that's not reason enough to forbid it. Jason