Nested Lambdas with Capture

[jlperla]

Are there any known bugs in Intel ++ 11.1.051 Windows with nesting lambdas that capture other lambdas.

Stuff like (this exact code wasn't proven to replicate the bug)...

[bash]template

double my_func(const F& f, double x)

{

  auto g = [&](double x){return f(x)};

  return g(x); //Contrived of course, but I had something like this.

}

auto f = [](double x){return x;};

auto val = my_func(f, 2.0);[/bash]

I called something like this and it worked the first time, but calling the same function later with slightly different values seemed to have a the old or aninvalid "f" in the inner lambda. I am pretty sure it was the capture because when I wrote my own functors/capture everything worked fine.

If there are known bugs of this time I will wait for later compiler versions, otherwise I can try to replicate exactly.

[Quoc-An_L_Intel]

I am not aware of this issue. Could you try replicating the exact problem post it here?

[jlperla]

The following code seems to reproduce the problem... It may have an extra layer or two than necessary, I just tried to replicate my structure exactly.

To see the problem, run the code once and notice that the same number is output twice (it shouldn't be). Now switch the order of the lines so the auto h = [] and related cout happens before the auto h2 = [] and its cout. You will notice that the result is correct for the first number again, and wrong for the second.

I am usingIntel ++ 11.1.051 Windows:

[cpp]#include
template
double my_func(const F& f, double x)  

{  
	auto g = [&](double y){return 3 * f(y);};  
	return g(2.0 * x);
}  

template
double my_func1(const F& f, double x)
{
	double z = 2.0;
	auto g = [&](double y){return z + f(y);};  
	return my_func(g, x);  
}

main()
{
	auto h2 = [](double x){return 2*x*x;};
	std::cout << my_func1(h2, 2.0) << std::endl;

	auto h = [](double x){return x*x;};
	std::cout << my_func1(h, 2.0) << std::endl;
}[/cpp]

[jimdempseyatthecove]

What happens with this:

[bash]template
double my_func(const F& f, double x)
{
  auto do_f = [&](double y)( return f(y); }; 
  auto g = [&](double y){return 3 * do_f(y); };
   return g(2.0 * x);
 } 
[/bash]

The difference being:

f is an argument representing a functor reference
do_f is a functor

Syntactically this should not make a difference but the compiler may treat the two differently.

N.B. I also observed a problem where [=] was passing references instead of values (had to use [&,a,b,c] to capture values of a, b, and c). This may have been a bug in my version of the compiler 11.1.072

Jim Dempsey

[jimdempseyatthecove]

Sorry for the misformatted code snip

If you do a spell check with an embedded code snip, the code snip formatting goes to one gigantic line. What you saw was my attempt at re-editing the code snip (line breaks and indents got wacked).

Jim Dempsey

[jlperla]

The following code still has the problems for me (also, the problems still happen when I capture all of them by name... ie. [&f] instead of just [&]:

[cpp]#include

template
double my_func(const F& f, double x)
{ 
	auto do_f = [&](double y){ return f(y); };
	auto g = [&](double y){return 3 * do_f(y); };
	return g(2.0 * x);
} 

template
double my_func1(const F& f, double x)
{
	double z = 2.0;
	auto g = [&](double y){return z + f(y);};  
	return my_func(g, x);  
}

main()
{

	auto h2 = [](double x){return 2*x*x;};
	std::cout << my_func1(h2, 2.0) << std::endl;

	auto h = [](double x){return x*x;};
	std::cout << my_func1(h, 2.0) << std::endl;

}[/cpp]

[jlperla]

Hi Intel folks:

I just wanted to make sure you saw this post since I still believe it is a compiler bug, and a terrifying one since it is silent.

Thanks,

-Jesse

[Dale_S_Intel]

Quoting jlperla

Hi Intel folks:

I just wanted to make sure you saw this post since I still believe it is a compiler bug, and a terrifying one since it is silent.

Thanks,

-Jesse

In space no one can hear you compile :-)

Sorry for the delay, we're looking into it. I've reproduce the problem that you're seeing (thanks for the small test case). We'll respond here when we have more info.

Thanks!

Dale

[jlperla]

No worries at all, just wanted to make sure my bug report didn't enter the world of lost message board ramblings.

Thanks for making such a great compiler, and looking forward to the next release.

-Jesse

[Dale_S_Intel]

I'm sure that never happens (except sometimes :-). It's good to be prudent.

Thanks for your kind words regarding our product!

Dale