<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On 29 April 2014 14:55, Renato Golin <span dir="ltr"><<a href="mailto:renato.golin@linaro.org" target="_blank">renato.golin@linaro.org</a>></span> wrote:<br>

<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On 29 April 2014 14:46, Hal Finkel <<a href="mailto:hfinkel@anl.gov" target="_blank">hfinkel@anl.gov</a>> wrote:<br>


> But why? I don't find this gcc comparison a compelling argument. It seems easier to support it, and more useful, than not supporting it. Adding a warning does not seem more difficult than adding the error. Regardless of what gcc does, Clang/LLVM must have a design process that keeps modern C++ in mind, and modern C++ includes lambda functions.<br>


<br>
</div>C++11 constructs should use annotations, not pragmas. We should only<br>
implement legacy pragmas for legacy behaviour. Any new pragmas, or new<br>
behaviour that we add on legacy pragmas will diverge from the original<br>
intention and require ifdefs on user code.<br></blockquote><div><br></div><div>I agree on this point about lambdas.</div><div><br></div><div>GCC defines pragma optimize as a "function-specific pragma" that applies an attribute to function definitions. C++11 lambdas are not exactly functions, they are a class type with some properties (the "closure type"), one of which is to implicitly have an operator(). So I would not expect the pragma to have a direct effect on lambdas because there isn't an explicit definition of the operator(). It might have an effect for lambdas defined within an enclosed function just as an artifact of the implementation, but it is not specified as such.</div>

<div>The only documentation on the MSVC pragma says that it enables/disables optimizations starting from the first function after it. In practice it does not seem to affect lambdas (I've only tried a simple example in VS2012 though, I haven't done extensive testing).</div>
<div><br></div><div>I think the conservative choice of not specifying any additional behaviour for lambdas is the safest.</div><div>Also, since the main use case is debugging, and debugging a lambda has other problems (it is often on just one line and you can't step much into it anyway), I don't think 'optnone' would make a big difference in that case. Basically we aren't particularly worried about lambdas for this feature.</div>

<div><br></div><div>Cheers,</div><div>    Dario Domizioli</div><div>    SN Systems - Sony Computer Entertainment Group</div><div><br></div></div></div></div>