Re: [PATCH] D13582: [DEBUG INFO] Emit debug info for type used in explicit cast only.

Yes, revision 246985 broke th debug info for types in explicit casts. Best regards, Alexey Bataev = Software Engineer Intel Compiler Team 09.10.2015 18:26, David Blaikie

Re: [PATCH] D13546: [ATTR] Automatic line feed after pragma-like attribute, NFC.

Ok, will do Best regards, Alexey Bataev = Software Engineer Intel Compiler Team 08.10.2015 16:02, Aaron Ballman пишет: aaron.ballman accepted this revision. aaron.ballman added a comment. This revision is now accepted and ready to land. LGTM, thanks! If you would be so kind as to a

Re: [Diffusion] rL247251: [OPENMP] Outlined function for parallel and other regions with list of…

Yes, I know. Fixing it right now. Will be fixed in few minutes, thanks. Best regards, Alexey Bataev = Software Engineer Intel Compiler Team 10.09.2015 11:46, NAKAMURA Takumi пишет: chapuni added subscribers: cfe-commits, chapuni. chapuni added a comment. See also; http://bb.pgr.jp/

Re: [PATCH] D12134: Improve debug info for implicitly captured vars in lambdas

Guys, talking about implicitly captured variables we have to deal with 2 locations: 1) point of real capturing (it is the point of '=' or '&' symbols in lambda capture-list); 2) a point of first use of variable inside lambda's body. When we're talking about diagnostic for implicitly captured var

Re: [PATCH] D12134: Improve debug info for implicitly captured vars in lambdas

Debug info points to the real place where it is captured, while diagnostics points to the first use of implicitly captured variable. Best regards, Alexey Bataev = Software Engineer Intel Compiler Team 25.08.2015 18:22, David Blaikie пишет: On Tue, Aug 25, 2015 at 8:18 AM, Bataev,

Re: [PATCH] D12134: Improve debug info for implicitly captured vars in lambdas

I though about this. I think it will be more convenient for user to see the diagnostic on the first use of the variable rather than on '=' or '&' symbol. Best regards, Alexey Bataev = Software Engineer Intel Compiler Team 25.08.2015 18:07, David Blaikie пишет: On Tue, Aug 18, 20

Re: [PATCH] D12134: [DEBUG INFO] Source correlation for lambda captured values.

Yes, you're right, and it will be 13, 14, 15. It is implemented already and this patch does not break this. Best regards, Alexey Bataev = Software Engineer Intel Compiler Team 25.08.2015 9:00, Eric Christopher пишет: echristo added a comment. How about: 13. [apple, 14. banana, 15

Re: [PATCH] D11182: [OPENMP 4.0] Initial support for 'omp declare reduction' construct.

I'll update patch, Michael Best regards, Alexey Bataev = Software Engineer Intel Compiler Team 20.08.2015 18:40, Michael Wong пишет: fraggamuffin added a comment. Comment at: lib/Parse/ParseDeclCXX.cpp:3011 @@ -3010,3 +3010,3 @@ if (Tok.is(tok::annot_pra

Re: r245041 - [OPENMP] Fix for http://llvm.org/PR24371: Assert failure compiling blender 2.75.

Hans, everything is fine. Best regards, Alexey Bataev = Software Engineer Intel Compiler Team 17.08.2015 21:30, Hans Wennborg пишет: Merged in r245229. There were merge conflicts in StmtOpenMP.h because we don't have r244209 on the branch. I think I got it right, but I'd appreciate

Re: r245041 - [OPENMP] Fix for http://llvm.org/PR24371: Assert failure compiling blender 2.75.

Yes, please, forget to tell you. :) Best regards, Alexey Bataev = Software Engineer Intel Compiler Team 14.08.2015 19:03, Hans Wennborg пишет: On Fri, Aug 14, 2015 at 5:25 AM, Alexey Bataev via cfe-commits wrote: Author: abataev Date: Fri Aug 14 07:25:37 2015 New Revision: 245041