Re: [lambda] Segmentation fault in simple lambda program

On Thu, Aug 6, 2009 at 6:27 AM, Adam Butcher > wrote: I take you're point on [finish_struct_1] potentially being overkill but at least it means that user programs that copy can work. Right. I only added that comment so that other developers who come along

Re: [lambda] Segmentation fault in simple lambda program

Adam Butcher wrote: >John Freeman wrote: >> >> I just inspected my code again. The call to layout_class_type at the >> beginning of finish_lambda_function_body at semantics.c:5241 was >> intended to recalculate offsets to members in the case of default captures. >> >> Here is the complete order of

Re: [lambda] Segmentation fault in simple lambda program

John Freeman wrote: +/* 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

Re: [lambda] Segmentation fault in simple lambda program

Jason Merrill wrote: Incidentally, how does it work to just move the existing call of finish_struct to after we parse the body? I don't see why we need it to be complete while we're in the body. When I was working on it, there were some checks to make sure the class was complete. I can't re

Re: [lambda] Segmentation fault in simple lambda program

Jason Merrill wrote: On 08/04/2009 10:17 AM, John Freeman wrote: Reiterating, to allow more freedom in implementation, we can just say it "behaves as" a template, rather than "is" a template. I don't see the difference. As long as they work the same, the compiler is free to do whatever it wa

Re: [lambda] Segmentation fault in simple lambda program

On 08/03/2009 09:39 PM, John Freeman wrote: * 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

Re: [lambda] Segmentation fault in simple lambda program

On 08/04/2009 10:17 AM, John Freeman wrote: Reiterating, to allow more freedom in implementation, we can just say it "behaves as" a template, rather than "is" a template. I don't see the difference. As long as they work the same, the compiler is free to do whatever it wants internally. Jaso

Re: [lambda] Segmentation fault in simple lambda program

On 08/04/2009 04:52 AM, Adam Butcher wrote: Yes sorry about that. I appreciate the issue. I had taken a branch of trunk and applied the lambda changes to it to keep only lambda changes on my working branch (allowing simpler future rebaseing). There were a number of things I had to change to

Re: [lambda] Segmentation fault in simple lambda program

Jason Merrill wrote: On 08/04/2009 09:35 AM, John Freeman wrote: In my opinion, lambdas are not intended as just a shortcut to writing a function object class. This is why our proposal did not require that lambdas be implemented as classes; it is simply one implementation. (Awaiting word to see

Re: [lambda] Segmentation fault in simple lambda program

On 08/04/2009 09:35 AM, John Freeman wrote: In my opinion, lambdas are not intended as just a shortcut to writing a function object class. This is why our proposal did not require that lambdas be implemented as classes; it is simply one implementation. (Awaiting word to see if this is still the

Re: [lambda] Segmentation fault in simple lambda program

Adam Butcher wrote: Hopefully. From my point of view the class generated by a lambda expression should be equivalent to something you could write yourself -- aside from the single stack-pointer reference optimization which only a compiler could achieve -- the class has a name, albeit invisibl

Re: [lambda] Segmentation fault in simple lambda program

Hi Jason, Pending response from assign at gnu dot org, I've attached diffs made against your latest lambda head. They are cleaned up a little to from the previous diffs against trunk. First is the re-layout fix, second is experimental polymorphic lambda support. Cheers, Adam 0001-Re-laid-ou

Re: [lambda] Segmentation fault in simple lambda program

Jason Merrill wrote: > 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 supp

Re: [lambda] Segmentation fault in simple lambda program

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 ca

Re: [lambda] Segmentation fault in simple lambda program

Jason Merrill wrote: 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 an

Re: [lambda] Segmentation fault in simple lambda program

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 assignm

Re: [lambda] Segmentation fault in simple lambda program

On 07/29/2009 06:27 AM, Adam Butcher wrote: Esben Mose Hansen writes: I am completely new to gcc hacking, just dying to get lambda into gcc 4.5 :) Me too on both counts! Great! Please feel free to ask me any questions you have directly. Do you have copyright assignments on file yet? I

Re: [lambda] Segmentation fault in simple lambda program

Adam Butcher wrote: Hi Esben Mose Hansen writes: this program SEGFAULTs #include int main() { int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; const std::size_t nn = sizeof(numbers)/sizeof(int); int sum = 0; int f = 5; std::for_each(&numbers[0], &numbers[nn], [&] (int n) {

Re: [lambda] Segmentation fault in simple lambda program

Hi Esben Mose Hansen writes: > this program SEGFAULTs > > #include > > int main() { > int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; > const std::size_t nn = sizeof(numbers)/sizeof(int); > int sum = 0; > int f = 5; > std::for_each(&numbers[0], &numbers[nn], [&] (int n) { > sum +=

Re: [lambda] Segmentation fault in simple lambda program

On Thursday 30 April 2009 19:19:31 you wrote: > When I try to specify the capture it works ((&sum, &f) works too but f is > const): > > #include > > int > main(void) > { > int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; > const std::size_t nn = sizeof(numbers)/sizeof(int); > int sum = 0; >

Re: [lambda] Segmentation fault in simple lambda program

Esben Mose Hansen writes: > this program SEGFAULTs > > #include > > int main() { > int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; > const std::size_t nn = sizeof(numbers)/sizeof(int); > int sum = 0; > int f = 5; > std::for_each(&numbers[0], &numbers[nn], [&] (int n) { > sum +=

Re: [lambda] Segmentation fault in simple lambda program

Esben Mose Hansen writes: > this program SEGFAULTs > > #include > > int main() { > int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; > const std::size_t nn = sizeof(numbers)/sizeof(int); > int sum = 0; > int f = 5; > std::for_each(&numbers[0], &numbers[nn], [&] (int n) { > sum +=

[lambda] Segmentation fault in simple lambda program

Hi, this program SEGFAULTs #include int main() { int numbers[] = { 1, 2, 3, 4, 5, 6, 7, 8, 9 }; const std::size_t nn = sizeof(numbers)/sizeof(int); int sum = 0; int f = 5; std::for_each(&numbers[0], &numbers[nn], [&] (int n) { sum += n * f; }); } Now, my assembly days are