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

2015-10-11 Thread Bataev, Alexey via cfe-commits 
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 пишет:



On Fri, Oct 9, 2015 at 2:26 AM, Alexey Bataev via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:


ABataev created this revision.
ABataev added a reviewer: echristo.
ABataev added a subscriber: cfe-commits.

Currently debug info for types used in explicit cast only is not
emitted. It happened after a patch for better alignment handling.


You mean a patch related to alignment regressed this functionality? Do 
you have the specific revision number of that change (since it sounds 
like you tracked it down)?


This patch fixes this bug.

http://reviews.llvm.org/D13582

Files:
  lib/CodeGen/CGExpr.cpp
  test/CodeGenCXX/debug-info-explicit-cast.cpp

Index: lib/CodeGen/CGExpr.cpp
===
--- lib/CodeGen/CGExpr.cpp
+++ lib/CodeGen/CGExpr.cpp
@@ -799,6 +799,10 @@
 if (E->getType()->isVariablyModifiedType())
   EmitVariablyModifiedType(E->getType());

+if (isa(CE))
+  if (CGDebugInfo *DI = getDebugInfo())
+DI->EmitExplicitCastType(E->getType());
+
 switch (CE->getCastKind()) {
 // Non-converting casts (but not C's implicit conversion from
void*).
 case CK_BitCast:
Index: test/CodeGenCXX/debug-info-explicit-cast.cpp
===
--- test/CodeGenCXX/debug-info-explicit-cast.cpp
+++ test/CodeGenCXX/debug-info-explicit-cast.cpp
@@ -0,0 +1,18 @@
+// RUN: %clangxx -c -target x86_64-unknown-unknown -g %s
-emit-llvm -S -o - | FileCheck %s
+struct Foo {
+  int a;
+  Foo() : a(1){};
+};
+
+struct Bar {
+  int b;
+  Bar() : b(2){};
+};
+
+int main() {
+  Bar *pb = new Bar;
+
+  return reinterpret_cast(pb)->a;
+}
+
+// CHECK: !DICompositeType(tag: DW_TAG_structure_type, name: "Foo",



___
cfe-commits mailing list
cfe-commits@lists.llvm.org 
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits




___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2015-10-08 Thread Bataev, Alexey via cfe-commits 

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 add a test for #pragma 
init_seg("bss"), that would be great -- it seems its printPrettyPragma never 
put a newline in there for that attribute, and so I would guess there's lacking test 
coverage that this change should fix.

~Aaron


http://reviews.llvm.org/D13546





___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2015-09-10 Thread Bataev, Alexey via cfe-commits 

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/builders/clang-i686-cygwin-RA-centos6/builds/20524


/cfe/trunk/test/OpenMP/parallel_codegen.cpp:99 Seems it is incompatible to 
32-bit targets, for example, i686-linux, i686-cygwin.

   define internal void @.omp_outlined..1(i32* noalias %.global_tid., i32* 
noalias %.bound_tid., i8*** dereferenceable(4) %argc) #1 personality i8* 
bitcast (i32 (...)* @__gxx_personality_v0 to i8*) {

Users:
   ABataev (Author)

http://reviews.llvm.org/rL247251





___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2015-08-25 Thread Bataev, Alexey via cfe-commits 
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 variables we 
have to deal with the second point, not the first one, because of 
usability. I don't think that the "diagnostic consumer" would be happy 
to see a message like "unnamed variable cannot be implicitly captured in 
a lambda expression" pointing to '=' or '&'. Here we have to emit the 
diagnostic at the point of the very first use of the variable we're 
going to capture to make diagnostic more user-friendly. But actual point 
of capturing is still a point, where we have '=' or '&' symbols in 
capture-list.


Best regards,
Alexey Bataev
=
Software Engineer
Intel Compiler Team

25.08.2015 19:00, Eric Christopher пишет:


Yeah. I can't see a difference here being useful, and more likely harmful.


On Tue, Aug 25, 2015, 8:48 AM David Blaikie > wrote:


On Tue, Aug 25, 2015 at 8:44 AM, Bataev, Alexey
mailto:a.bat...@hotmail.com>> wrote:

Debug info points to the real place where it is captured,
while diagnostics points to the first use of implicitly
captured variable.


Right, but I'm trying to understand the justification for why
that's the right thing to do. Why the debug info user would want a
different experience than the compiler diagnostic consumer would want.


- David



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, Alexey
mailto:a.bat...@hotmail.com>
>> wrote:

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.


Why the difference between the diagnostic & the debug
info, then?


Best regards,
Alexey Bataev
=
Software Engineer
Intel Compiler Team

25.08.2015 18 
:07, David Blaikie пишет:



On Tue, Aug 18, 2015 at 9:05 PM, Alexey Bataev via
cfe-commits
mailto:cfe-commits@lists.llvm.org>
>

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

2015-08-25 Thread Bataev, Alexey via cfe-commits 
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, Alexey > wrote:


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.


Why the difference between the diagnostic & the debug info, then?


Best regards,
Alexey Bataev
=
Software Engineer
Intel Compiler Team

25.08.2015 18 :07, David Blaikie пишет:



On Tue, Aug 18, 2015 at 9:05 PM, Alexey Bataev via cfe-commits
mailto:cfe-commits@lists.llvm.org>
>> wrote:

ABataev created this revision.
ABataev added reviewers: echristo, rjmccall, rsmith.
ABataev added a subscriber: cfe-commits.

When variables are implicitly captured in lambdas, debug info
generated for captured variables points to location where
they are
used first.  This patch makes debug info to point to capture
default location.


Not sure if this is the right tradeoff, or if it is, perhaps
we should reconsider how our diagnostics work too?

Currently if you, say, capture a variable by value and that
variable doesn't have an accessible copy ctor, the diagnostic
points to the first use. Should we change that too?


http://reviews.llvm.org/D12134

Files:
  lib/Sema/SemaLambda.cpp
  test/CodeGenCXX/debug-lambda-expressions.cpp

Index: lib/Sema/SemaLambda.cpp
===
--- lib/Sema/SemaLambda.cpp
+++ lib/Sema/SemaLambda.cpp
@@ -1377,10 +1377,10 @@
 }

 static ExprResult performLambdaVarCaptureInitialization(
-Sema &S, LambdaScopeInfo::Capture &Capture,
-FieldDecl *Field,
+Sema &S, LambdaScopeInfo::Capture &Capture, FieldDecl
*Field,
 SmallVectorImpl &ArrayIndexVars,
-SmallVectorImpl &ArrayIndexStarts) {
+SmallVectorImpl &ArrayIndexStarts, bool
ImplicitCapture,
+SourceLocation CaptureDefaultLoc) {
   assert(Capture.isVariableCapture() && "not a variable
capture");

   auto *Var = Capture.getVariable();
@@ -1399,7 +1399,10 @@
   //   An entity captured by a lambda-expression is
odr-used (3.2) in
   //   the scope containing the lambda-expression.
   ExprResult RefResult = S.BuildDeclarationNameExpr(
-  CXXScopeSpec(), DeclarationNameInfo(Var->getDeclName(),
Loc), Var);
+  CXXScopeSpec(),
+ DeclarationNameInfo(Var->getDeclName(),
+  ImplicitCapture ?
CaptureDefaultLoc : Loc),
+  Var);
   if (RefResult.isInvalid())
 return ExprError();
   Expr *Ref = RefResult.get();
@@ -1561,7 +1564,8 @@
   Expr *Init = From.getInitExpr();
   if (!Init) {
 auto InitResult =
performLambdaVarCaptureInitialization(
-*this, From, *CurField, ArrayIndexVars,
ArrayIndexStarts);
+*this, From, *CurField, ArrayIndexVars,
ArrayIndexStarts,
+CaptureDefault != LCD_None, CaptureDefaultLoc);
 if (InitResult.isInvalid())
   return ExprError();
 Init = InitResult.get();
Index: test/CodeGenCXX/debug-lambda-expressions.cpp
===
--- test/CodeGenCXX/debug-lambda-expressions.cpp
+++ test/CodeGenCXX/debug-lambda-expressions.cpp
@@ -14,6 +14,19 @@
 struct D { D(); D(const D&); int x; };
 int d(int x) { D y[10]; return [x,y] { return y[x].x; }(); }

+// CHECK-LABEL: foo
+int foo(int x) {
+// CHECK: [[X:%.+]] = alloca i32,
+// CHECK: call void @llvm.dbg.declare(
+// CHECK: [[X_REF:%.+]] = getelementptr inbounds %{{.+}},
%{{.+}}* %{{.+}}, i32 0, i32 0, !dbg ![[DBG_FOO:[0-9]+]]
+// CHECK: [[X_VAL:%.+]] = load i32, i32* [[X]], align 4, !dbg
![[DBG_FOO]]
+// CHECK: store i32 [[X_VAL]], i32* [[X_REF]], align 4, !dbg
![[DBG_FOO]]
+// CHECK: call i32 @{{.+}}, !dbg ![[DB

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

2015-08-25 Thread Bataev, Alexey via cfe-commits 
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, 2015 at 9:05 PM, Alexey Bataev via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:


ABataev created this revision.
ABataev added reviewers: echristo, rjmccall, rsmith.
ABataev added a subscriber: cfe-commits.

When variables are implicitly captured in lambdas, debug info
generated for captured variables points to location where they are
used first.  This patch makes debug info to point to capture
default location.


Not sure if this is the right tradeoff, or if it is, perhaps we should 
reconsider how our diagnostics work too?


Currently if you, say, capture a variable by value and that variable 
doesn't have an accessible copy ctor, the diagnostic points to the 
first use. Should we change that too?



http://reviews.llvm.org/D12134

Files:
  lib/Sema/SemaLambda.cpp
  test/CodeGenCXX/debug-lambda-expressions.cpp

Index: lib/Sema/SemaLambda.cpp
===
--- lib/Sema/SemaLambda.cpp
+++ lib/Sema/SemaLambda.cpp
@@ -1377,10 +1377,10 @@
 }

 static ExprResult performLambdaVarCaptureInitialization(
-Sema &S, LambdaScopeInfo::Capture &Capture,
-FieldDecl *Field,
+Sema &S, LambdaScopeInfo::Capture &Capture, FieldDecl *Field,
 SmallVectorImpl &ArrayIndexVars,
-SmallVectorImpl &ArrayIndexStarts) {
+SmallVectorImpl &ArrayIndexStarts, bool
ImplicitCapture,
+SourceLocation CaptureDefaultLoc) {
   assert(Capture.isVariableCapture() && "not a variable capture");

   auto *Var = Capture.getVariable();
@@ -1399,7 +1399,10 @@
   //   An entity captured by a lambda-expression is odr-used (3.2) in
   //   the scope containing the lambda-expression.
   ExprResult RefResult = S.BuildDeclarationNameExpr(
-  CXXScopeSpec(), DeclarationNameInfo(Var->getDeclName(),
Loc), Var);
+  CXXScopeSpec(),
+  DeclarationNameInfo(Var->getDeclName(),
+  ImplicitCapture ? CaptureDefaultLoc : Loc),
+  Var);
   if (RefResult.isInvalid())
 return ExprError();
   Expr *Ref = RefResult.get();
@@ -1561,7 +1564,8 @@
   Expr *Init = From.getInitExpr();
   if (!Init) {
 auto InitResult = performLambdaVarCaptureInitialization(
-*this, From, *CurField, ArrayIndexVars,
ArrayIndexStarts);
+*this, From, *CurField, ArrayIndexVars, ArrayIndexStarts,
+CaptureDefault != LCD_None, CaptureDefaultLoc);
 if (InitResult.isInvalid())
   return ExprError();
 Init = InitResult.get();
Index: test/CodeGenCXX/debug-lambda-expressions.cpp
===
--- test/CodeGenCXX/debug-lambda-expressions.cpp
+++ test/CodeGenCXX/debug-lambda-expressions.cpp
@@ -14,6 +14,19 @@
 struct D { D(); D(const D&); int x; };
 int d(int x) { D y[10]; return [x,y] { return y[x].x; }(); }

+// CHECK-LABEL: foo
+int foo(int x) {
+// CHECK: [[X:%.+]] = alloca i32,
+// CHECK: call void @llvm.dbg.declare(
+// CHECK: [[X_REF:%.+]] = getelementptr inbounds %{{.+}},
%{{.+}}* %{{.+}}, i32 0, i32 0, !dbg ![[DBG_FOO:[0-9]+]]
+// CHECK: [[X_VAL:%.+]] = load i32, i32* [[X]], align 4, !dbg
![[DBG_FOO]]
+// CHECK: store i32 [[X_VAL]], i32* [[X_REF]], align 4, !dbg
![[DBG_FOO]]
+// CHECK: call i32 @{{.+}}, !dbg ![[DBG_FOO]]
+  return [=] {
+return x;
+  }();
+}
+
 // Randomness for file. -- 6
 // CHECK: [[FILE:.*]] = !DIFile(filename:
"{{.*}}debug-lambda-expressions.cpp",

@@ -100,3 +113,5 @@
 // CHECK-SAME:  line: [[VAR_LINE]],
 // CHECK-SAME:  elements:
![[VAR_ARGS:[0-9]+]]
 // CHECK: ![[VAR_ARGS]] = !{!{{[0-9]+}}}
+
+// CHECK: [[DBG_FOO:![0-9]+]] = !DILocation(line: 25,



___
cfe-commits mailing list
cfe-commits@lists.llvm.org 
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits




___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2015-08-25 Thread Bataev, Alexey via cfe-commits 
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. cherry]{
16. printf("apple = %d\n",apple);
17. printf("banana = %d\n",banana);
18. printf("cherry = %d\n",cherry);

Should be 13, 14, 15 yes?

-eric


http://reviews.llvm.org/D12134





___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2015-08-20 Thread Bataev, Alexey via cfe-commits 

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_pragma_openmp)) {
-ParseOpenMPDeclarativeDirective();
  continue;

While testing this patch with the latest trunk for my work on declare target, I 
kept getting a build error in ParseDeclCXX.cpp as there seems to be no CurAS in 
scope, this may be because of recent changes. But this line:
   if (Tok.is(tok::annot_pragma_openmp))
 return ParseOpenMPDeclarativeDirective(CurAS);
Seems to work better as
   if (Tok.is(tok::annot_pragma_openmp))
 return ParseOpenMPDeclarativeDirective(AS);


http://reviews.llvm.org/D11182





___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2015-08-17 Thread Bataev, Alexey via cfe-commits 

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 if
someone could double check
http://llvm.org/viewvc/llvm-project?rev=245229&view=rev

Thanks,
Hans

On Sun, Aug 16, 2015 at 8:55 PM, Bataev, Alexey  wrote:

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

URL: http://llvm.org/viewvc/llvm-project?rev=245041&view=rev
Log:
[OPENMP] Fix for http://llvm.org/PR24371: Assert failure compiling
blender 2.75.
blender uses statements expression in condition of the loop under control
of the '#pragma omp parallel for'. This condition is used several times in
different expressions required for codegen of the loop directive. If there
are some variables defined in statement expression, it fires an assert
during codegen because of redefinition of the same variables.
We have to rebuild several expression to be sure that all variables are
unique.

Should we merge this to 3.7?




___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

2015-08-16 Thread Bataev, Alexey via cfe-commits 

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

URL: http://llvm.org/viewvc/llvm-project?rev=245041&view=rev
Log:
[OPENMP] Fix for http://llvm.org/PR24371: Assert failure compiling blender 2.75.
blender uses statements expression in condition of the loop under control of 
the '#pragma omp parallel for'. This condition is used several times in 
different expressions required for codegen of the loop directive. If there are 
some variables defined in statement expression, it fires an assert during 
codegen because of redefinition of the same variables.
We have to rebuild several expression to be sure that all variables are unique.

Should we merge this to 3.7?


___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits