RE: [PATCH] D73967: Implement _ExtInt as an extended int type specifier.

[Keane, Erich via cfe-commits]

No problem, thanks for the response!

Phab emails are apparently about 30 minutes delayed for me apparently, which is 
unfortunate or I would have had the fix ready before your revert 😊

Let me know if you run into any more issues, but I’m 99% sure I got it right 
this time.

Thanks
-Erich

From: Sterling Augustine 
Sent: Friday, April 17, 2020 11:38 AM
To: reviews+d73967+public+2549cbb9adffa...@reviews.llvm.org
Cc: Keane, Erich ; aaron.ball...@gmail.com; 
m.ge...@gmx.de; Blower, Melanie I ; Mikhail Ramalho 
; arichardson@gmail.com; david.gr...@arm.com; 
bevin.hans...@ericsson.com; riccib...@gmail.com; Andrews, Elizabeth 
; samm...@gmail.com; Mikael Holmén 
; a.bat...@hotmail.com; Sidorov, Dmitry 
; sabre+phabrica...@nondot.org; 
karl-johan.karls...@ericsson.com; git...@john.mcfarlane.name; 
jfbast...@apple.com; ronan-l...@keryell.fr; Richard Smith 
; ikosa...@accesssoftek.com; rekanikol...@gmail.com; 
Alex L ; cfe-commits ; 
mlek...@skidmore.edu; blitzrak...@gmail.com; Han Shen ; 
1.in...@gmail.com
Subject: Re: [PATCH] D73967: Implement _ExtInt as an extended int type 
specifier.

Sorry for the trouble. I think many buildbots don't build lldb--not enough of 
them anyway. I found this myself.

As I understand it, the switch-cover warning is supposed to be enabled 
everywhere when built in release mode, so it looks like the lldb builders (what 
few there are) aren't building in release mode. I can look into fixing that.

On Fri, Apr 17, 2020 at 11:20 AM Erich Keane via Phabricator 
mailto:revi...@reviews.llvm.org>> wrote:
erichkeane added a comment.

Already relanded here: 5f0903e9bec9 


@saugustine  I checked the buildbots, every one with LLDB in its name stayed 
green, and I cannot see the warning in any of their STDIO.  Can you point out 
how I can proactively keep an eye on this? The lldb build is broken 
out-of-the-box anyway for me due to the LLDB Python Wrapper having a syntax 
error in the SWIG bindings.

bash-4.2$ swig -copyright

SWIG Version 2.0.10
/workspaces/llvm-project/lldb/bindings/./python/python-typemaps.swig:496: 
Error: Syntax error in input(3).


Repository:
  rG LLVM Github Monorepo

CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D73967/new/

https://reviews.llvm.org/D73967


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

RE: r355698 - Re-fix _lrotl/_lrotr to always take Long, no matter the platform.

[Keane, Erich via cfe-commits]

Right, the intent was to get this to match Microsoft’s behavior better while 
still making sense on other platforms.  IIRC this was in order to fix a codegen 
bug due to type mismatches, though I don’t completely remember (as it was 
nearly a year ago).

From: James Y Knight 
Sent: Wednesday, February 26, 2020 8:39 PM
To: Michael Spencer 
Cc: Keane, Erich ; cfe-commits 

Subject: Re: r355698 - Re-fix _lrotl/_lrotr to always take Long, no matter the 
platform.

I'm not clear as to what you're saying is broken.

On MS platforms, long is 32-bit, so either way this function takes a 32bit 
value, right? And, Microsoft's docs say this function takes a long.


On Wed, Feb 26, 2020, 5:09 PM Michael Spencer via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
I believe this commit is wrong. These intrinsics were originally implemented to 
support Windows code which expects _lrot{l,r}'s first argument to be 32 bits, 
it's a breaking change to change these definitions. I'm fine with adding the 
Intel version of these intrinsics, but you can't just break the Microsoft 
version of them.

- Michael Spencer

On Fri, Mar 8, 2019 at 7:09 AM Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Fri Mar  8 07:10:07 2019
New Revision: 355698

URL: http://llvm.org/viewvc/llvm-project?rev=355698&view=rev
Log:
Re-fix _lrotl/_lrotr to always take Long, no matter the platform.

r355322 fixed this, however is being reverted due to concerns with
enabling it in other modes.

Change-Id: I6a939b7469b8fa196d5871a627eb2330dbd30f29

Modified:
cfe/trunk/include/clang/Basic/Builtins.def
cfe/trunk/test/CodeGen/ms-intrinsics-rotations.c

Modified: cfe/trunk/include/clang/Basic/Builtins.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Builtins.def?rev=355698&r1=355697&r2=355698&view=diff
==
--- cfe/trunk/include/clang/Basic/Builtins.def (original)
+++ cfe/trunk/include/clang/Basic/Builtins.def Fri Mar  8 07:10:07 2019
@@ -831,12 +831,12 @@ LANGBUILTIN(_ReturnAddress, "v*", "n", A
 LANGBUILTIN(_rotl8,  "UcUcUc","n", ALL_MS_LANGUAGES)
 LANGBUILTIN(_rotl16, "UsUsUc","n", ALL_MS_LANGUAGES)
 LANGBUILTIN(_rotl,   "UiUii", "n", ALL_MS_LANGUAGES)
-LANGBUILTIN(_lrotl,  "UNiUNii",   "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(_lrotl,  "ULiULii",   "n", ALL_MS_LANGUAGES)
 LANGBUILTIN(_rotl64, "UWiUWii",   "n", ALL_MS_LANGUAGES)
 LANGBUILTIN(_rotr8,  "UcUcUc","n", ALL_MS_LANGUAGES)
 LANGBUILTIN(_rotr16, "UsUsUc","n", ALL_MS_LANGUAGES)
 LANGBUILTIN(_rotr,   "UiUii", "n", ALL_MS_LANGUAGES)
-LANGBUILTIN(_lrotr,  "UNiUNii",   "n", ALL_MS_LANGUAGES)
+LANGBUILTIN(_lrotr,  "ULiULii",   "n", ALL_MS_LANGUAGES)
 LANGBUILTIN(_rotr64, "UWiUWii",   "n", ALL_MS_LANGUAGES)
 LANGBUILTIN(__va_start,   "vc**.", "nt", ALL_MS_LANGUAGES)
 LANGBUILTIN(__fastfail, "vUi","nr", ALL_MS_LANGUAGES)

Modified: cfe/trunk/test/CodeGen/ms-intrinsics-rotations.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/ms-intrinsics-rotations.c?rev=355698&r1=355697&r2=355698&view=diff
==
--- cfe/trunk/test/CodeGen/ms-intrinsics-rotations.c (original)
+++ cfe/trunk/test/CodeGen/ms-intrinsics-rotations.c Fri Mar  8 07:10:07 2019
@@ -12,17 +12,10 @@
 // RUN: | FileCheck %s --check-prefixes CHECK,CHECK-32BIT-LONG
 // RUN: %clang_cc1 -ffreestanding -fms-extensions -fms-compatibility 
-fms-compatibility-version=17.00 \
 // RUN: -triple x86_64--linux -emit-llvm %s -o - \
-// RUN: | FileCheck %s --check-prefixes CHECK,CHECK-32BIT-LONG
+// RUN: | FileCheck %s --check-prefixes CHECK,CHECK-64BIT-LONG
 // RUN: %clang_cc1 -ffreestanding -fms-extensions \
 // RUN: -triple x86_64--darwin -emit-llvm %s -o - \
-// RUN: | FileCheck %s --check-prefixes CHECK,CHECK-32BIT-LONG
-
-// LP64 targets use 'long' as 'int' for MS intrinsics (-fms-extensions)
-#ifdef __LP64__
-#define LONG int
-#else
-#define LONG long
-#endif
+// RUN: | FileCheck %s --check-prefixes CHECK,CHECK-64BIT-LONG

 // rotate left

@@ -47,12 +40,15 @@ unsigned int test_rotl(unsigned int valu
 // CHECK:   [[R:%.*]] = call i32 @llvm.fshl.i32(i32 [[X:%.*]], i32 [[X]], i32 
[[Y:%.*]])
 // CHECK:   ret i32 [[R]]

-unsigned LONG test_lrotl(unsigned LONG value, int shift) {
+unsigned long test_lrotl(unsigned long value, int shift) {
   return _lrotl(value, shift);
 }
 // CHECK-32BIT-LONG: i32 @test_lrotl
 // CHECK-32BIT-LONG:   [[R:%.*]] = call i32 @llvm.fshl.i32(i32 [[X:%.*]], i32 
[[X]], i32 [[Y:%.*]])
 // CHECK-32BIT-LONG:   ret i32 [[R]]
+// CHECK-64BIT-LONG: i64 @test_lrotl
+// CHECK-64BIT-LONG:   [[R:%.*]] = call i64 @llvm.fshl.i64(i64 [[X:%.*]], i64 
[[X]], i64 [[Y:%.*]])
+// CHECK-64BIT-LONG:   ret i64 [[R]]

 unsigned __int64 test_rotl64(unsigned __int64 value, int shift) {
   return _rotl64(value, shift);
@@ -84,12 +80,1

Re: [PATCH] D68824: Fix __builtin_assume_aligned with too large values.

[Keane, Erich via cfe-commits]

Thanks! On the way home for the evening, so I'll fix it up tomorrow.

On Oct 10, 2019 2:34 PM, Nico Weber via Phabricator  
wrote:
thakis added a comment.

Since you just left IRC, I reverted this in 374456 for now.


CHANGES SINCE LAST ACTION
  https://reviews.llvm.org/D68824/new/

https://reviews.llvm.org/D68824



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

RE: r373247 - Teach CallGraph to look into Generic Lambdas.

[Keane, Erich via cfe-commits]

Yep, I agree.  I tend to figure if I can get it done in ~1-2 hours, that I 
could just fix it.  Note that this was 1:30 😊

From: Nico Weber 
Sent: Wednesday, October 2, 2019 4:37 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r373247 - Teach CallGraph to look into Generic Lambdas.

Thanks!

If it takes a few hours to investigate, I think it's better to revert first and 
then investigate while the tree is green.

On Mon, Sep 30, 2019 at 4:43 PM Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
Should be fixe din r373259

From: Nico Weber mailto:tha...@chromium.org>>
Sent: Monday, September 30, 2019 12:50 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r373247 - Teach CallGraph to look into Generic Lambdas.

This broke a few clangd unit tests:

http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/38857/steps/ninja%20check%201/logs/FAIL%3A%20Clangd%20Unit%20Tests%3A%3AHover.Structured
http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/38857/steps/ninja%20check%201/logs/FAIL%3A%20Clangd%20Unit%20Tests%3A%3AHover.All
http://45.33.8.238/linux/680/step_7.txt

On Mon, Sep 30, 2019 at 3:10 PM Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Mon Sep 30 12:12:29 2019
New Revision: 373247

URL: http://llvm.org/viewvc/llvm-project?rev=373247&view=rev
Log:
Teach CallGraph to look into Generic Lambdas.

CallGraph visited LambdaExpr by getting the Call Operator from
CXXRecordDecl (LambdaExpr::getCallOperator calls
CXXRecordDecl::getLambdaCallOperator), which replaced generic lambda
call operators with the non-instantiated FunctionDecl.  The result was
that the CallGraph would only pick up non-dependent calls.

This patch does a few things:
1- Extend CXXRecordDecl to have a getDependentLambdaCallOperator, which
will get the FunctionTemplateDecl, rather than immediately getting the
TemplateDecl.
2- Define getLambdaCallOperator and getDependentLambdaCallOperator in
terms of a common function.
3- Extend LambdaExpr with a getDependentCallOperator, which just calls
the above function.
4- Changes CallGraph to handle Generic LambdaExprs.

Modified:
cfe/trunk/include/clang/AST/DeclCXX.h
cfe/trunk/include/clang/AST/ExprCXX.h
cfe/trunk/lib/AST/DeclCXX.cpp
cfe/trunk/lib/AST/ExprCXX.cpp
cfe/trunk/lib/Analysis/CallGraph.cpp
cfe/trunk/test/Analysis/debug-CallGraph.cpp

Modified: cfe/trunk/include/clang/AST/DeclCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclCXX.h?rev=373247&r1=373246&r2=373247&view=diff
==
--- cfe/trunk/include/clang/AST/DeclCXX.h (original)
+++ cfe/trunk/include/clang/AST/DeclCXX.h Mon Sep 30 12:12:29 2019
@@ -1172,6 +1172,10 @@ public:
   /// if this is a closure type.
   CXXMethodDecl *getLambdaCallOperator() const;

+  /// Retrieve the dependent lambda call operator of the closure type
+  /// if this is a templated closure type.
+  FunctionTemplateDecl *getDependentLambdaCallOperator() const;
+
   /// Retrieve the lambda static invoker, the address of which
   /// is returned by the conversion operator, and the body of which
   /// is forwarded to the lambda call operator.

Modified: cfe/trunk/include/clang/AST/ExprCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ExprCXX.h?rev=373247&r1=373246&r2=373247&view=diff
==
--- cfe/trunk/include/clang/AST/ExprCXX.h (original)
+++ cfe/trunk/include/clang/AST/ExprCXX.h Mon Sep 30 12:12:29 2019
@@ -1907,6 +1907,10 @@ public:
   /// lambda expression.
   CXXMethodDecl *getCallOperator() const;

+  /// Retrieve the function template call operator associated with this
+  /// lambda expression.
+  FunctionTemplateDecl *getDependentCallOperator() const;
+
   /// If this is a generic lambda expression, retrieve the template
   /// parameter list associated with it, or else return null.
   TemplateParameterList *getTemplateParameterList() const;

Modified: cfe/trunk/lib/AST/DeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclCXX.cpp?rev=373247&r1=373246&r2=373247&view=diff
==
--- cfe/trunk/lib/AST/DeclCXX.cpp (original)
+++ cfe/trunk/lib/AST/DeclCXX.cpp Mon Sep 30 12:12:29 2019
@@ -1399,17 +1399,25 @@ static bool allLookupResultsAreTheSame(c
 }
 #endif

-CXXMethodDecl* CXXRecordDecl::getLambdaCallOperator() const {
-  if (!isLambda()) return nullptr;
+NamedDecl* getLambdaCallOperatorHelper(const CXXRecordDecl &RD) {
+  if (!RD.isLambda()) return nullptr;
   DeclarationName Name =
-getASTContext().DeclarationNames.getCXXOperatorName(OO_Call);
-  DeclContext::lookup_result Calls = lookup(Name);
+RD.getASTContext().DeclarationNames.getCXXOperatorName(OO_Call);
+  DeclContext::lookup_result Calls = RD.lookup(Name)

RE: r373247 - Teach CallGraph to look into Generic Lambdas.

[Keane, Erich via cfe-commits]

Should be fixe din r373259

From: Nico Weber 
Sent: Monday, September 30, 2019 12:50 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r373247 - Teach CallGraph to look into Generic Lambdas.

This broke a few clangd unit tests:

http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/38857/steps/ninja%20check%201/logs/FAIL%3A%20Clangd%20Unit%20Tests%3A%3AHover.Structured
http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/38857/steps/ninja%20check%201/logs/FAIL%3A%20Clangd%20Unit%20Tests%3A%3AHover.All
http://45.33.8.238/linux/680/step_7.txt

On Mon, Sep 30, 2019 at 3:10 PM Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Mon Sep 30 12:12:29 2019
New Revision: 373247

URL: http://llvm.org/viewvc/llvm-project?rev=373247&view=rev
Log:
Teach CallGraph to look into Generic Lambdas.

CallGraph visited LambdaExpr by getting the Call Operator from
CXXRecordDecl (LambdaExpr::getCallOperator calls
CXXRecordDecl::getLambdaCallOperator), which replaced generic lambda
call operators with the non-instantiated FunctionDecl.  The result was
that the CallGraph would only pick up non-dependent calls.

This patch does a few things:
1- Extend CXXRecordDecl to have a getDependentLambdaCallOperator, which
will get the FunctionTemplateDecl, rather than immediately getting the
TemplateDecl.
2- Define getLambdaCallOperator and getDependentLambdaCallOperator in
terms of a common function.
3- Extend LambdaExpr with a getDependentCallOperator, which just calls
the above function.
4- Changes CallGraph to handle Generic LambdaExprs.

Modified:
cfe/trunk/include/clang/AST/DeclCXX.h
cfe/trunk/include/clang/AST/ExprCXX.h
cfe/trunk/lib/AST/DeclCXX.cpp
cfe/trunk/lib/AST/ExprCXX.cpp
cfe/trunk/lib/Analysis/CallGraph.cpp
cfe/trunk/test/Analysis/debug-CallGraph.cpp

Modified: cfe/trunk/include/clang/AST/DeclCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclCXX.h?rev=373247&r1=373246&r2=373247&view=diff
==
--- cfe/trunk/include/clang/AST/DeclCXX.h (original)
+++ cfe/trunk/include/clang/AST/DeclCXX.h Mon Sep 30 12:12:29 2019
@@ -1172,6 +1172,10 @@ public:
   /// if this is a closure type.
   CXXMethodDecl *getLambdaCallOperator() const;

+  /// Retrieve the dependent lambda call operator of the closure type
+  /// if this is a templated closure type.
+  FunctionTemplateDecl *getDependentLambdaCallOperator() const;
+
   /// Retrieve the lambda static invoker, the address of which
   /// is returned by the conversion operator, and the body of which
   /// is forwarded to the lambda call operator.

Modified: cfe/trunk/include/clang/AST/ExprCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ExprCXX.h?rev=373247&r1=373246&r2=373247&view=diff
==
--- cfe/trunk/include/clang/AST/ExprCXX.h (original)
+++ cfe/trunk/include/clang/AST/ExprCXX.h Mon Sep 30 12:12:29 2019
@@ -1907,6 +1907,10 @@ public:
   /// lambda expression.
   CXXMethodDecl *getCallOperator() const;

+  /// Retrieve the function template call operator associated with this
+  /// lambda expression.
+  FunctionTemplateDecl *getDependentCallOperator() const;
+
   /// If this is a generic lambda expression, retrieve the template
   /// parameter list associated with it, or else return null.
   TemplateParameterList *getTemplateParameterList() const;

Modified: cfe/trunk/lib/AST/DeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclCXX.cpp?rev=373247&r1=373246&r2=373247&view=diff
==
--- cfe/trunk/lib/AST/DeclCXX.cpp (original)
+++ cfe/trunk/lib/AST/DeclCXX.cpp Mon Sep 30 12:12:29 2019
@@ -1399,17 +1399,25 @@ static bool allLookupResultsAreTheSame(c
 }
 #endif

-CXXMethodDecl* CXXRecordDecl::getLambdaCallOperator() const {
-  if (!isLambda()) return nullptr;
+NamedDecl* getLambdaCallOperatorHelper(const CXXRecordDecl &RD) {
+  if (!RD.isLambda()) return nullptr;
   DeclarationName Name =
-getASTContext().DeclarationNames.getCXXOperatorName(OO_Call);
-  DeclContext::lookup_result Calls = lookup(Name);
+RD.getASTContext().DeclarationNames.getCXXOperatorName(OO_Call);
+  DeclContext::lookup_result Calls = RD.lookup(Name);

   assert(!Calls.empty() && "Missing lambda call operator!");
   assert(allLookupResultsAreTheSame(Calls) &&
  "More than one lambda call operator!");
+  return Calls.front();
+}
+
+FunctionTemplateDecl* CXXRecordDecl::getDependentLambdaCallOperator() const {
+  NamedDecl *CallOp = getLambdaCallOperatorHelper(*this);
+  return  dyn_cast(CallOp);
+}

-  NamedDecl *CallOp = Calls.front();
+CXXMethodDecl *CXXRecordDecl::getLambdaCallOperator() const {
+  NamedDecl *CallOp = getLambdaCallOperatorHelper(*this);
   if (const auto *CallOpTmpl = dyn_cast(CallOp))
 return cast(CallOpT

RE: r373247 - Teach CallGraph to look into Generic Lambdas.

[Keane, Erich via cfe-commits]

I saw that, thanks!  I’m looking into them now.  I can revert if it takes me 
too long.

From: Nico Weber 
Sent: Monday, September 30, 2019 12:50 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r373247 - Teach CallGraph to look into Generic Lambdas.

This broke a few clangd unit tests:

http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/38857/steps/ninja%20check%201/logs/FAIL%3A%20Clangd%20Unit%20Tests%3A%3AHover.Structured
http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/38857/steps/ninja%20check%201/logs/FAIL%3A%20Clangd%20Unit%20Tests%3A%3AHover.All
http://45.33.8.238/linux/680/step_7.txt

On Mon, Sep 30, 2019 at 3:10 PM Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Mon Sep 30 12:12:29 2019
New Revision: 373247

URL: http://llvm.org/viewvc/llvm-project?rev=373247&view=rev
Log:
Teach CallGraph to look into Generic Lambdas.

CallGraph visited LambdaExpr by getting the Call Operator from
CXXRecordDecl (LambdaExpr::getCallOperator calls
CXXRecordDecl::getLambdaCallOperator), which replaced generic lambda
call operators with the non-instantiated FunctionDecl.  The result was
that the CallGraph would only pick up non-dependent calls.

This patch does a few things:
1- Extend CXXRecordDecl to have a getDependentLambdaCallOperator, which
will get the FunctionTemplateDecl, rather than immediately getting the
TemplateDecl.
2- Define getLambdaCallOperator and getDependentLambdaCallOperator in
terms of a common function.
3- Extend LambdaExpr with a getDependentCallOperator, which just calls
the above function.
4- Changes CallGraph to handle Generic LambdaExprs.

Modified:
cfe/trunk/include/clang/AST/DeclCXX.h
cfe/trunk/include/clang/AST/ExprCXX.h
cfe/trunk/lib/AST/DeclCXX.cpp
cfe/trunk/lib/AST/ExprCXX.cpp
cfe/trunk/lib/Analysis/CallGraph.cpp
cfe/trunk/test/Analysis/debug-CallGraph.cpp

Modified: cfe/trunk/include/clang/AST/DeclCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclCXX.h?rev=373247&r1=373246&r2=373247&view=diff
==
--- cfe/trunk/include/clang/AST/DeclCXX.h (original)
+++ cfe/trunk/include/clang/AST/DeclCXX.h Mon Sep 30 12:12:29 2019
@@ -1172,6 +1172,10 @@ public:
   /// if this is a closure type.
   CXXMethodDecl *getLambdaCallOperator() const;

+  /// Retrieve the dependent lambda call operator of the closure type
+  /// if this is a templated closure type.
+  FunctionTemplateDecl *getDependentLambdaCallOperator() const;
+
   /// Retrieve the lambda static invoker, the address of which
   /// is returned by the conversion operator, and the body of which
   /// is forwarded to the lambda call operator.

Modified: cfe/trunk/include/clang/AST/ExprCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ExprCXX.h?rev=373247&r1=373246&r2=373247&view=diff
==
--- cfe/trunk/include/clang/AST/ExprCXX.h (original)
+++ cfe/trunk/include/clang/AST/ExprCXX.h Mon Sep 30 12:12:29 2019
@@ -1907,6 +1907,10 @@ public:
   /// lambda expression.
   CXXMethodDecl *getCallOperator() const;

+  /// Retrieve the function template call operator associated with this
+  /// lambda expression.
+  FunctionTemplateDecl *getDependentCallOperator() const;
+
   /// If this is a generic lambda expression, retrieve the template
   /// parameter list associated with it, or else return null.
   TemplateParameterList *getTemplateParameterList() const;

Modified: cfe/trunk/lib/AST/DeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclCXX.cpp?rev=373247&r1=373246&r2=373247&view=diff
==
--- cfe/trunk/lib/AST/DeclCXX.cpp (original)
+++ cfe/trunk/lib/AST/DeclCXX.cpp Mon Sep 30 12:12:29 2019
@@ -1399,17 +1399,25 @@ static bool allLookupResultsAreTheSame(c
 }
 #endif

-CXXMethodDecl* CXXRecordDecl::getLambdaCallOperator() const {
-  if (!isLambda()) return nullptr;
+NamedDecl* getLambdaCallOperatorHelper(const CXXRecordDecl &RD) {
+  if (!RD.isLambda()) return nullptr;
   DeclarationName Name =
-getASTContext().DeclarationNames.getCXXOperatorName(OO_Call);
-  DeclContext::lookup_result Calls = lookup(Name);
+RD.getASTContext().DeclarationNames.getCXXOperatorName(OO_Call);
+  DeclContext::lookup_result Calls = RD.lookup(Name);

   assert(!Calls.empty() && "Missing lambda call operator!");
   assert(allLookupResultsAreTheSame(Calls) &&
  "More than one lambda call operator!");
+  return Calls.front();
+}
+
+FunctionTemplateDecl* CXXRecordDecl::getDependentLambdaCallOperator() const {
+  NamedDecl *CallOp = getLambdaCallOperatorHelper(*this);
+  return  dyn_cast(CallOp);
+}

-  NamedDecl *CallOp = Calls.front();
+CXXMethodDecl *CXXRecordDecl::getLambdaCallOperator() const {
+  NamedDecl *CallOp = getLambdaCallOperatorHelper(*this);
   if (const 

RE: r372185 - Revert "Create UsersManual section entitled 'Controlling Floating Point"

[Keane, Erich via cfe-commits]

Ah, sorry-
It broke the sphinx build bot, and the author was home for the evening and is 
going to get to it during the day today.

From: Richard Smith 
Sent: Tuesday, September 17, 2019 8:10 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r372185 - Revert "Create UsersManual section entitled 'Controlling 
Floating Point"

On Tue, 17 Sep 2019, 15:25 Erich Keane via cfe-commits, 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Tue Sep 17 14:27:07 2019
New Revision: 372185

URL: http://llvm.org/viewvc/llvm-project?rev=372185&view=rev
Log:
Revert "Create UsersManual section entitled 'Controlling Floating Point"

When reverting a change, please include a reason for the revert in your commit 
message.

This reverts commit a08d5a4b0ebd44dc64f41049ed4e97a3c6d31498.

Modified:
cfe/trunk/docs/UsersManual.rst

Modified: cfe/trunk/docs/UsersManual.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=372185&r1=372184&r2=372185&view=diff
==
--- cfe/trunk/docs/UsersManual.rst (original)
+++ cfe/trunk/docs/UsersManual.rst Tue Sep 17 14:27:07 2019
@@ -1128,165 +1128,6 @@ number of cases where the compilation en
 and the precompiled header cannot be generated after headers have been
 installed.

-.. _controlling-fp-behavior:
-
-Controlling Floating Point Behavior

-
-Clang provides a number of ways to control floating point behavior. The options
-are listed below.
-
-.. option:: -ffast-math
-
-   Enable fast-math mode.  This option lets the
-   compiler make aggressive, potentially-lossy assumptions about
-   floating-point math.  These include:
-
-   * Floating-point math obeys regular algebraic rules for real numbers (e.g.
- ``+`` and ``*`` are associative, ``x/y == x * (1/y)``, and
- ``(a + b) * c == a * c + b * c``),
-   * Operands to floating-point operations are not equal to ``NaN`` and
- ``Inf``, and
-   * ``+0`` and ``-0`` are interchangeable.
-
-   ``-ffast-math`` also defines the ``__FAST_MATH__`` preprocessor
-   macro. Some math libraries recognize this macro and change their behavior.
-   With the exception of ``-ffp-contract=fast``, using any of the options
-   below to disable any of the individual optimizations in ``-ffast-math``
-   will cause ``__FAST_MATH__`` to no longer be set.
-
-  This option implies:
-
-   * ``-fno-honor-infinities``
-
-   * ``-fno-honor-nans``
-
-   * ``-fno-math-errno``
-
-   * ``-ffinite-math``
-
-   * ``-fassociative-math``
-
-   * ``-freciprocal-math``
-
-   * ``-fno-signed-zeros``
-
-   * ``-fno-trapping-math``
-
-   * ``-ffp-contract=fast``
-
-.. option:: -fdenormal-fp-math=
-
-   Select which denormal numbers the code is permitted to require.
-
-   Valid values are:
-
-   * ``ieee`` - IEEE 754 denormal numbers
-   * ``preserve-sign`` - the sign of a flushed-to-zero number is preserved in 
the sign of 0
-   * ``positive-zero`` - denormals are flushed to positive zero
-
-   Defaults to ``ieee``.
-
-.. option:: -f[no-]strict-float-cast-overflow
-
-   When a floating-point value is not representable in a destination integer
-   type, the code has undefined behavior according to the language standard.
-   By default, Clang will not guarantee any particular result in that case.
-   With the 'no-strict' option, Clang attempts to match the overflowing 
behavior
-   of the target's native float-to-int conversion instructions.
-
-.. option:: -f[no-]math-errno
-
-   Require math functions to indicate errors by setting errno.
-   The default varies by ToolChain.  ``-fno-math-errno`` allows optimizations
-   that might cause standard C math functions to not set ``errno``.
-   For example, on some systems, the math function ``sqrt`` is specified
-   as setting ``errno`` to ``EDOM`` when the input is negative. On these
-   systems, the compiler cannot normally optimize a call to ``sqrt`` to use
-   inline code (e.g. the x86 ``sqrtsd`` instruction) without additional
-   checking to ensure that ``errno`` is set appropriately.
-   ``-fno-math-errno`` permits these transformations.
-
-   On some targets, math library functions never set ``errno``, and so
-   ``-fno-math-errno`` is the default. This includes most BSD-derived
-   systems, including Darwin.
-
-.. option:: -f[no-]trapping-math
-
-   ``-fno-trapping-math`` allows optimizations that assume that
-   floating point operations cannot generate traps such as divide-by-zero,
-   overflow and underflow. Defaults to ``-ftrapping-math``.
-   Currently this option has no effect.
-
-.. option:: -ffp-contract=
-
-   Specify when the compiler is permitted to form fused floating-point
-   operations, such as fused multiply-add (FMA). Fused operations are
-   permitted to produce more precise results than performing the same
-   operations separately.
-
-   The C standard permits intermediate floating-point results within an
-   expression to be computed with more precis

RE: r369281 - Implement P1668R1

[Keane, Erich via cfe-commits]

Yeah, sorry about that.  I fixed it in 369284.

From: Leonard Chan [mailto:leonardc...@google.com]
Sent: Monday, August 19, 2019 11:33 AM
To: Keane, Erich 
Cc: cfe-commits cfe 
Subject: Re: r369281 - Implement P1668R1

Not sure if this was caught by upstream bots already, but we're seeing a 
failing test ob our x64 bots:

```
FAIL: Clang :: SemaCXX/cxx1z-constexpr-lambdas.cpp (9574 of 15387)
 TEST 'Clang :: SemaCXX/cxx1z-constexpr-lambdas.cpp' FAILED 

Script:
--
: 'RUN: at line 1';   
/b/s/w/ir/k/recipe_cleanup/clangAGxiPQ/llvm_build_dir/bin/clang -cc1 
-internal-isystem 
/b/s/w/ir/k/recipe_cleanup/clangAGxiPQ/llvm_build_dir/lib/clang/10.0.0/include 
-nostdsysteminc -std=c++1z -verify -fsyntax-only -fblocks 
/b/s/w/ir/k/llvm-project/clang/test/SemaCXX/cxx1z-constexpr-lambdas.cpp 
-fcxx-exceptions
: 'RUN: at line 2';   
/b/s/w/ir/k/recipe_cleanup/clangAGxiPQ/llvm_build_dir/bin/clang -cc1 
-internal-isystem 
/b/s/w/ir/k/recipe_cleanup/clangAGxiPQ/llvm_build_dir/lib/clang/10.0.0/include 
-nostdsysteminc -std=c++2a -verify -fsyntax-only -fblocks 
/b/s/w/ir/k/llvm-project/clang/test/SemaCXX/cxx1z-constexpr-lambdas.cpp 
-fcxx-exceptions
: 'RUN: at line 3';   
/b/s/w/ir/k/recipe_cleanup/clangAGxiPQ/llvm_build_dir/bin/clang -cc1 
-internal-isystem 
/b/s/w/ir/k/recipe_cleanup/clangAGxiPQ/llvm_build_dir/lib/clang/10.0.0/include 
-nostdsysteminc -std=c++1z -verify -fsyntax-only -fblocks 
-fdelayed-template-parsing 
/b/s/w/ir/k/llvm-project/clang/test/SemaCXX/cxx1z-constexpr-lambdas.cpp 
-fcxx-exceptions
: 'RUN: at line 4';   
/b/s/w/ir/k/recipe_cleanup/clangAGxiPQ/llvm_build_dir/bin/clang -cc1 
-internal-isystem 
/b/s/w/ir/k/recipe_cleanup/clangAGxiPQ/llvm_build_dir/lib/clang/10.0.0/include 
-nostdsysteminc -std=c++14 -verify -fsyntax-only -fblocks 
/b/s/w/ir/k/llvm-project/clang/test/SemaCXX/cxx1z-constexpr-lambdas.cpp 
-DCPP14_AND_EARLIER -fcxx-exceptions
--
Exit Code: 1

Command Output (stderr):
--
error: 'error' diagnostics expected but not seen:
  File /b/s/w/ir/k/llvm-project/clang/test/SemaCXX/cxx1z-constexpr-lambdas.cpp 
Line 26 (directive at 
/b/s/w/ir/k/llvm-project/clang/test/SemaCXX/cxx1z-constexpr-lambdas.cpp:28): 
use of this statement in a constexpr function is a C++2a extension
error: 'warning' diagnostics seen but not expected:
  File /b/s/w/ir/k/llvm-project/clang/test/SemaCXX/cxx1z-constexpr-lambdas.cpp 
Line 26: use of this statement in a constexpr function is a C++2a extension
2 errors generated.

--


Testing: 0 .. 10.. 20.. 30.. 40.. 50.. 60.. 70.. 80.. 90..
Testing Time: 79.76s

Failing Tests (1):
Clang :: SemaCXX/cxx1z-constexpr-lambdas.cpp
```

Could you look into this? Thanks.

On Mon, Aug 19, 2019 at 10:39 AM Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Mon Aug 19 10:39:59 2019
New Revision: 369281

URL: http://llvm.org/viewvc/llvm-project?rev=369281&view=rev
Log:
Implement P1668R1

Allow inline assembly statements in unexecuted branches of constexpr
functions.

Modified:
cfe/trunk/lib/Frontend/InitPreprocessor.cpp
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.constexpr/p3.cpp
cfe/trunk/test/Lexer/cxx-features.cpp
cfe/trunk/test/SemaCXX/cxx1z-constexpr-lambdas.cpp

Modified: cfe/trunk/lib/Frontend/InitPreprocessor.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/InitPreprocessor.cpp?rev=369281&r1=369280&r2=369281&view=diff
==
--- cfe/trunk/lib/Frontend/InitPreprocessor.cpp (original)
+++ cfe/trunk/lib/Frontend/InitPreprocessor.cpp Mon Aug 19 10:39:59 2019
@@ -480,6 +480,7 @@ static void InitializeCPlusPlusFeatureTe
 Builder.defineMacro("__cpp_user_defined_literals", "200809L");
 Builder.defineMacro("__cpp_lambdas", "200907L");
 Builder.defineMacro("__cpp_constexpr",
+LangOpts.CPlusPlus2a ? "201907L" :
 LangOpts.CPlusPlus17 ? "201603L" :
 LangOpts.CPlusPlus14 ? "201304L" : "200704");
 Builder.defineMacro("__cpp_range_based_for",

Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cpp?rev=369281&r1=369280&r2=369281&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Mon Aug 19 10:39:59 2019
@@ -1995,6 +1995,9 @@ CheckConstexprFunctionStmt(Sema &SemaRef
 return false;
 return true;

+  case Stmt::GCCAsmStmtClass:
+  case Stmt::MSAsmStmtClass:
+// C++2a allows inline assembly statements.
   case Stmt::CXXTryStmtClass:
 if (Cxx2aLoc.isInvalid())
   Cxx2aLoc = S->getBeginLoc();

Modified: cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.constexpr/p3.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CXX/dcl.dcl/dcl.spe

RE: r367027 - Implement P1771

[Keane, Erich via cfe-commits]

Ah!  Thanks.  I’ll fix it now.

From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Thursday, July 25, 2019 9:26 AM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r367027 - Implement P1771

On Thu, 25 Jul 2019, 08:10 Erich Keane via cfe-commits, 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Thu Jul 25 08:10:56 2019
New Revision: 367027

URL: http://llvm.org/viewvc/llvm-project?rev=367027&view=rev
Log:
Implement P1771

As passed in the Cologne meeting and treated by Core as a DR,
[[nodiscard]] was applied to constructors so that they can be diagnosed
in cases where the user forgets a variable name for a type.

The intent is to enable the library to start using this on the
constructors of scope_guard/lock_guard.

Differential Revision: https://reviews.llvm.org/D64914

Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/include/clang/Basic/AttrDocs.td
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/AST/Expr.cpp
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
cfe/trunk/lib/Sema/SemaStmt.cpp
cfe/trunk/test/CXX/dcl.dcl/dcl.attr/dcl.attr.nodiscard/p2.cpp
cfe/trunk/test/Preprocessor/has_attribute.cpp
cfe/trunk/www/cxx_status.html

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=367027&r1=367026&r2=367027&view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Thu Jul 25 08:10:56 2019
@@ -2335,12 +2335,19 @@ def WarnUnused : InheritableAttr {
 }

 def WarnUnusedResult : InheritableAttr {
-  let Spellings = [CXX11<"", "nodiscard", 201603>, C2x<"", "nodiscard">,
+  let Spellings = [CXX11<"", "nodiscard", 201907>, C2x<"", "nodiscard">,
CXX11<"clang", "warn_unused_result">,
GCC<"warn_unused_result">];
   let Subjects = SubjectList<[ObjCMethod, Enum, Record, FunctionLike]>;
   let Args = [StringArgument<"Message", 1>];
   let Documentation = [WarnUnusedResultsDocs];
+  let AdditionalMembers = [{
+// Check whether this the C++11 nodiscard version, even in non C++11
+// spellings.
+bool IsCXX11NoDiscard() const {
+  return this->getSemanticSpelling() == CXX11_nodiscard;
+}
+  }];
 }

 def Weak : InheritableAttr {

Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=367027&r1=367026&r2=367027&view=diff
==
--- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
+++ cfe/trunk/include/clang/Basic/AttrDocs.td Thu Jul 25 08:10:56 2019
@@ -1500,6 +1500,33 @@ in any resulting diagnostics.
   }
   error_info &foo();
   void f() { foo(); } // Does not diagnose, error_info is a reference.
+
+Additionally, discarded temporaries resulting from a call to a constructor
+marked with ``[[nodiscard]]`` or a constructor of a type marked
+``[[nodiscard]]`` will also diagnose. This also applies to type conversions 
that
+use the annotated ``[[nodiscard]]`` constructor or result in an annotated type.
+
+.. code-block: c++
+  struct [[nodiscard]] marked_type {/*..*/ };
+  struct marked_ctor {
+[[nodiscard]] marked_ctor();
+marked_ctor(int);
+  };
+
+  struct S {
+operator marked_type() const;
+[[nodiscard]] operator int() const;
+  };
+
+  void usages() {
+marked_type(); // diagnoses.
+marked_ctor(); // diagnoses.
+marked_ctor(3); // Does not diagnose, int constructor isn't marked 
nodiscard.
+
+S s;
+static_cast(s); // diagnoses
+(int)s; // diagnoses
+  }
   }];
 }


Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=367027&r1=367026&r2=367027&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu Jul 25 08:10:56 
2019
@@ -7430,6 +7430,12 @@ def warn_unused_container_subscript_expr
 def warn_unused_call : Warning<
   "ignoring return value of function declared with %0 attribute">,
   InGroup;
+def warn_unused_constructor : Warning<
+  "ignoring temporary created by a constructor declared with %0 attribute">,
+  InGroup;
+def warn_unused_constructor_msg : Warning<
+  "ignoring temporary created by a constructor declared with %0 attribute: 
%1">,
+  InGroup;
 def warn_side_effects_unevaluated_context : Warning<
   "expression with side effects has no effect in an unevaluated context">,
   InGroup;

Modified: cfe/trunk/lib/AST/Expr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Expr.cpp?rev=367027&r1=367026&r2=367027&view=diff
==
--- cfe/trun

RE: r362119 - Add Attribute NoThrow as an Exception Specifier Type

[Keane, Erich via cfe-commits]

To Update: Nico and I discussed this on IRC and believe the best way to fix 
this is to simply suppress this when it comes from a macro-expansion in a 
system header ala r221172 (or r220992).

I intend to work on that fix next after my current (fairly short) fix.

Thanks!
-Erich

From: Nico Weber [mailto:tha...@chromium.org]
Sent: Friday, May 31, 2019 6:58 AM
To: Keane, Erich 
Cc: Aaron Ballman ; cfe-commits 

Subject: Re: r362119 - Add Attribute NoThrow as an Exception Specifier Type

I'm not sure this is the best fix. From the patch description, it sounds like 
this is a Microsoft-specific change. So splitting this into a new diag group 
that then everyone using the Microsoft headers has to disable seems a bit 
roundabout – don't we get the same behavior by not emitting this warning in the 
first place, except that we don't require everyone using clang-cl to explicitly 
disable this warning then?

On Fri, May 31, 2019 at 9:38 AM Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
Presumably the right choice for you on this one is to separate the diagnostic 
into a new group.  Copying Aaron since he might have an idea of an existing 
group, otherwise I’ll push a commit to put it in a new one.

Thanks for the report!
-Erich

From: Nico Weber [mailto:tha...@chromium.org]
Sent: Thursday, May 30, 2019 6:15 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r362119 - Add Attribute NoThrow as an Exception Specifier Type

Hello,

this causes this diagnostic when building on Windows:

In file included from 
../../ui/accessibility/platform/ax_platform_node_textchildprovider_win.cc:10:
../..\ui/accessibility/platform/ax_platform_node_textprovider_win.h(22,3): 
error: 'nothrow' attribute conflicts with exception specification; attribute 
ignored [-Werror,-Wignored-attributes]
  END_COM_MAP()
  ^
..\..\third_party\depot_tools\win_toolchain\vs_files\ 
818a152b3f1da991c1725d85be19a0f27af6bab4\VC\Tools\MSVC\14.16.27023\atlmfc\include\atlcom.h(2358,2):
 note: expanded from macro 'END_COM_MAP'
STDMETHOD(QueryInterface)( \
^
..\..\third_party\depot_tools\win_toolchain\vs_files\ 
818a152b3f1da991c1725d85be19a0f27af6bab4\win_sdk\Include\10.0.17763.0\um\combaseapi.h(170,42):
 note: expanded from macro 'STDMETHOD'
#define STDMETHOD(method)virtual COM_DECLSPEC_NOTHROW HRESULT 
STDMETHODCALLTYPE method
 ^
..\..\third_party\depot_tools\win_toolchain\vs_files\ 
818a152b3f1da991c1725d85be19a0f27af6bab4\win_sdk\Include\10.0.17763.0\um\combaseapi.h(165,30):
 note: expanded from macro 'COM_DECLSPEC_NOTHROW'
#define COM_DECLSPEC_NOTHROW DECLSPEC_NOTHROW
 ^
..\..\third_party\depot_tools\win_toolchain\vs_files\ 
818a152b3f1da991c1725d85be19a0f27af6bab4\win_sdk\Include\10.0.17763.0\um\winnt.h(200,39):
 note: expanded from macro 'DECLSPEC_NOTHROW'
#define DECLSPEC_NOTHROW   __declspec(nothrow)
  ^


Suggestions? We don't want to use -Wno-ignored-attributes since that disables 
this warning for all attributes.

All the involved macros are in system headers and we have no control over them.

On Thu, May 30, 2019 at 1:28 PM Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Thu May 30 10:31:54 2019
New Revision: 362119

URL: http://llvm.org/viewvc/llvm-project?rev=362119&view=rev
Log:
Add Attribute NoThrow as an Exception Specifier Type

In response to https://bugs.llvm.org/show_bug.cgi?id=33235, it became
clear that the current mechanism of hacking through checks for the
exception specification of a function gets confused really quickly when
there are alternate exception specifiers.

This patch introcues EST_NoThrow, which is the equivilent of
EST_noexcept when caused by EST_noThrow. The existing implementation is
left in place to cover functions with no FunctionProtoType.

Differential Revision: https://reviews.llvm.org/D62435

Added:
cfe/trunk/test/SemaCXX/nothrow-vs-exception-specs.cpp   (with props)
Modified:
cfe/trunk/include/clang-c/Index.h
cfe/trunk/include/clang/AST/Decl.h
cfe/trunk/include/clang/AST/Type.h
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Basic/ExceptionSpecificationType.h
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/AST/JSONNodeDumper.cpp
cfe/trunk/lib/AST/Type.cpp
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/lib/Sema/SemaType.cpp
cfe/trunk/tools/libclang/CXType.cpp

Modified: cfe/trunk/include/clang-c/Index.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang-c/Index.h?rev=362119&r1=362118&r2=362119&view=diff
==
--- cfe/trunk/include/clang-c/Index.h (original)
+++ cfe/trunk/include/clang-c/Index.h Thu May 30 1

RE: r362119 - Add Attribute NoThrow as an Exception Specifier Type

[Keane, Erich via cfe-commits]

It IS an attribute that works on Linux as well (about ½ way down this page: 
https://gcc.gnu.org/onlinedocs/gcc-4.7.2/gcc/Function-Attributes.html), though 
used rarely (at least in C++ code) as far as I understand.

The fact that a mistake like this is in the ATL headers is frustrating, but I’m 
not sure the best way to deal with this.  Aaron and I both believed the warning 
to be meaningful/useful (since this conflict is the same as saying throw() 
noexcept(false)), so I’m not sure removing it is a good idea (if that’s what 
you’re suggesting).

However, if this is something reasonably common on Microsoft implementations, I 
wonder if it is a warning we can make off-by-default on clang-cl.  It would be 
a shame to lose it, but if this is a commonly enough used problem we might be 
stuck with it.

From: Nico Weber [mailto:tha...@chromium.org]
Sent: Friday, May 31, 2019 6:58 AM
To: Keane, Erich 
Cc: Aaron Ballman ; cfe-commits 

Subject: Re: r362119 - Add Attribute NoThrow as an Exception Specifier Type

I'm not sure this is the best fix. From the patch description, it sounds like 
this is a Microsoft-specific change. So splitting this into a new diag group 
that then everyone using the Microsoft headers has to disable seems a bit 
roundabout – don't we get the same behavior by not emitting this warning in the 
first place, except that we don't require everyone using clang-cl to explicitly 
disable this warning then?

On Fri, May 31, 2019 at 9:38 AM Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
Presumably the right choice for you on this one is to separate the diagnostic 
into a new group.  Copying Aaron since he might have an idea of an existing 
group, otherwise I’ll push a commit to put it in a new one.

Thanks for the report!
-Erich

From: Nico Weber [mailto:tha...@chromium.org]
Sent: Thursday, May 30, 2019 6:15 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r362119 - Add Attribute NoThrow as an Exception Specifier Type

Hello,

this causes this diagnostic when building on Windows:

In file included from 
../../ui/accessibility/platform/ax_platform_node_textchildprovider_win.cc:10:
../..\ui/accessibility/platform/ax_platform_node_textprovider_win.h(22,3): 
error: 'nothrow' attribute conflicts with exception specification; attribute 
ignored [-Werror,-Wignored-attributes]
  END_COM_MAP()
  ^
..\..\third_party\depot_tools\win_toolchain\vs_files\ 
818a152b3f1da991c1725d85be19a0f27af6bab4\VC\Tools\MSVC\14.16.27023\atlmfc\include\atlcom.h(2358,2):
 note: expanded from macro 'END_COM_MAP'
STDMETHOD(QueryInterface)( \
^
..\..\third_party\depot_tools\win_toolchain\vs_files\ 
818a152b3f1da991c1725d85be19a0f27af6bab4\win_sdk\Include\10.0.17763.0\um\combaseapi.h(170,42):
 note: expanded from macro 'STDMETHOD'
#define STDMETHOD(method)virtual COM_DECLSPEC_NOTHROW HRESULT 
STDMETHODCALLTYPE method
 ^
..\..\third_party\depot_tools\win_toolchain\vs_files\ 
818a152b3f1da991c1725d85be19a0f27af6bab4\win_sdk\Include\10.0.17763.0\um\combaseapi.h(165,30):
 note: expanded from macro 'COM_DECLSPEC_NOTHROW'
#define COM_DECLSPEC_NOTHROW DECLSPEC_NOTHROW
 ^
..\..\third_party\depot_tools\win_toolchain\vs_files\ 
818a152b3f1da991c1725d85be19a0f27af6bab4\win_sdk\Include\10.0.17763.0\um\winnt.h(200,39):
 note: expanded from macro 'DECLSPEC_NOTHROW'
#define DECLSPEC_NOTHROW   __declspec(nothrow)
  ^


Suggestions? We don't want to use -Wno-ignored-attributes since that disables 
this warning for all attributes.

All the involved macros are in system headers and we have no control over them.

On Thu, May 30, 2019 at 1:28 PM Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Thu May 30 10:31:54 2019
New Revision: 362119

URL: http://llvm.org/viewvc/llvm-project?rev=362119&view=rev
Log:
Add Attribute NoThrow as an Exception Specifier Type

In response to https://bugs.llvm.org/show_bug.cgi?id=33235, it became
clear that the current mechanism of hacking through checks for the
exception specification of a function gets confused really quickly when
there are alternate exception specifiers.

This patch introcues EST_NoThrow, which is the equivilent of
EST_noexcept when caused by EST_noThrow. The existing implementation is
left in place to cover functions with no FunctionProtoType.

Differential Revision: https://reviews.llvm.org/D62435

Added:
cfe/trunk/test/SemaCXX/nothrow-vs-exception-specs.cpp   (with props)
Modified:
cfe/trunk/include/clang-c/Index.h
cfe/trunk/include/clang/AST/Decl.h
cfe/trunk/include/clang/AST/Type.h
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Basic/ExceptionSpecificationType.h
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/AST/JSONNodeDumper.cpp
cfe/trunk/lib/AST/Type.cpp
c

RE: r362119 - Add Attribute NoThrow as an Exception Specifier Type

[Keane, Erich via cfe-commits]

Presumably the right choice for you on this one is to separate the diagnostic 
into a new group.  Copying Aaron since he might have an idea of an existing 
group, otherwise I’ll push a commit to put it in a new one.

Thanks for the report!
-Erich

From: Nico Weber [mailto:tha...@chromium.org]
Sent: Thursday, May 30, 2019 6:15 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r362119 - Add Attribute NoThrow as an Exception Specifier Type

Hello,

this causes this diagnostic when building on Windows:

In file included from 
../../ui/accessibility/platform/ax_platform_node_textchildprovider_win.cc:10:
../..\ui/accessibility/platform/ax_platform_node_textprovider_win.h(22,3): 
error: 'nothrow' attribute conflicts with exception specification; attribute 
ignored [-Werror,-Wignored-attributes]
  END_COM_MAP()
  ^
..\..\third_party\depot_tools\win_toolchain\vs_files\ 
818a152b3f1da991c1725d85be19a0f27af6bab4\VC\Tools\MSVC\14.16.27023\atlmfc\include\atlcom.h(2358,2):
 note: expanded from macro 'END_COM_MAP'
STDMETHOD(QueryInterface)( \
^
..\..\third_party\depot_tools\win_toolchain\vs_files\ 
818a152b3f1da991c1725d85be19a0f27af6bab4\win_sdk\Include\10.0.17763.0\um\combaseapi.h(170,42):
 note: expanded from macro 'STDMETHOD'
#define STDMETHOD(method)virtual COM_DECLSPEC_NOTHROW HRESULT 
STDMETHODCALLTYPE method
 ^
..\..\third_party\depot_tools\win_toolchain\vs_files\ 
818a152b3f1da991c1725d85be19a0f27af6bab4\win_sdk\Include\10.0.17763.0\um\combaseapi.h(165,30):
 note: expanded from macro 'COM_DECLSPEC_NOTHROW'
#define COM_DECLSPEC_NOTHROW DECLSPEC_NOTHROW
 ^
..\..\third_party\depot_tools\win_toolchain\vs_files\ 
818a152b3f1da991c1725d85be19a0f27af6bab4\win_sdk\Include\10.0.17763.0\um\winnt.h(200,39):
 note: expanded from macro 'DECLSPEC_NOTHROW'
#define DECLSPEC_NOTHROW   __declspec(nothrow)
  ^


Suggestions? We don't want to use -Wno-ignored-attributes since that disables 
this warning for all attributes.

All the involved macros are in system headers and we have no control over them.

On Thu, May 30, 2019 at 1:28 PM Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Thu May 30 10:31:54 2019
New Revision: 362119

URL: http://llvm.org/viewvc/llvm-project?rev=362119&view=rev
Log:
Add Attribute NoThrow as an Exception Specifier Type

In response to https://bugs.llvm.org/show_bug.cgi?id=33235, it became
clear that the current mechanism of hacking through checks for the
exception specification of a function gets confused really quickly when
there are alternate exception specifiers.

This patch introcues EST_NoThrow, which is the equivilent of
EST_noexcept when caused by EST_noThrow. The existing implementation is
left in place to cover functions with no FunctionProtoType.

Differential Revision: https://reviews.llvm.org/D62435

Added:
cfe/trunk/test/SemaCXX/nothrow-vs-exception-specs.cpp   (with props)
Modified:
cfe/trunk/include/clang-c/Index.h
cfe/trunk/include/clang/AST/Decl.h
cfe/trunk/include/clang/AST/Type.h
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Basic/ExceptionSpecificationType.h
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/AST/JSONNodeDumper.cpp
cfe/trunk/lib/AST/Type.cpp
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/lib/Sema/SemaType.cpp
cfe/trunk/tools/libclang/CXType.cpp

Modified: cfe/trunk/include/clang-c/Index.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang-c/Index.h?rev=362119&r1=362118&r2=362119&view=diff
==
--- cfe/trunk/include/clang-c/Index.h (original)
+++ cfe/trunk/include/clang-c/Index.h Thu May 30 10:31:54 2019
@@ -32,7 +32,7 @@
  * compatible, thus CINDEX_VERSION_MAJOR is expected to remain stable.
  */
 #define CINDEX_VERSION_MAJOR 0
-#define CINDEX_VERSION_MINOR 57
+#define CINDEX_VERSION_MINOR 58

 #define CINDEX_VERSION_ENCODE(major, minor) ( \
   ((major) * 1)   \
@@ -221,7 +221,12 @@ enum CXCursor_ExceptionSpecificationKind
   /**
* The exception specification has not been parsed yet.
*/
-  CXCursor_ExceptionSpecificationKind_Unparsed
+  CXCursor_ExceptionSpecificationKind_Unparsed,
+
+  /**
+   * The cursor has a __declspec(nothrow) exception specification.
+   */
+  CXCursor_ExceptionSpecificationKind_NoThrow
 };

 /**

Modified: cfe/trunk/include/clang/AST/Decl.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=362119&r1=362118&r2=362119&view=diff
==
--- cfe/trunk/include/clang/AST/Decl.h (original)
+++ cfe/trunk/include/clang/AST/Decl.h Thu May 30 10:31:54 2019
@@ -2330,6 +2330,14 @@ public:
 return T->castAs()-

RE: r355322 - Enable _rotl, _lrotl, _rotr, _lrotr on all platforms.

[Keane, Erich via cfe-commits]

You’re right, GCC has these in a header as a #define.  This patch didn’t 
interfere with that and was causing some other failures for us as a result.  If 
its OK, I’d prefer to revert ONLY the enable on Linux mode at the moment, the 
long-int fix WAS valuable as well.

From: James Y Knight [mailto:jykni...@google.com]
Sent: Thursday, March 7, 2019 3:52 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r355322 - Enable _rotl, _lrotl, _rotr, _lrotr on all platforms.

This patch breaks some code which is (conditionally) defining functions of 
these names on certain platforms. Now, it's true that it shouldn't be doing 
that, and if the claim in the commit message about GCC was true, I'd just say 
"don't do that".

But, the commit message is wrong. GCC does _not_ define these as builtins, it 
defines them in ia32intrin.h header (publicly via x86intrin.h) .

IMO, this commit should be reverted, and  functions defined in the header, 
instead. Perhaps similar to what 
2c8f9c2c23e0cafd7b85a7aec969c949349f747c
 did, although I note that was reverted in 
b62c5bc64dee3642884c31b8208c07a6f74b81fd,
 reportedly due to breaking mingw.

(I'd further note that even MSVC doesn't enable these builtins by default! It 
implements a `#pragma intrinsic(NAME)` mechanism which you need to use in order 
to enable them (and #include  will do so). But clang doesn't really 
implement that pragma, and instead enables all the MSVC-builtins 
unconditionally.)

On Mon, Mar 4, 2019 at 1:46 PM Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Mon Mar  4 10:47:21 2019
New Revision: 355322

URL: http://llvm.org/viewvc/llvm-project?rev=355322&view=rev
Log:
Enable _rotl, _lrotl, _rotr, _lrotr on all platforms.

The above builtins are currently implemented for MSVC mode, however GCC
also implements these.  This patch enables them for all platforms.

Additionally, this corrects the type for these builtins to always be
'long int' to match the specification in the Intel Intrinsics Guide.

Change-Id: Ida34be98078709584ef5136c8761783435ec02b1

Added:
cfe/trunk/test/CodeGen/rot-intrinsics.c   (with props)
Modified:
cfe/trunk/include/clang/Basic/Builtins.def
cfe/trunk/test/CodeGen/ms-intrinsics-rotations.c
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: r351495 - Make integral-o-pointer conversions in SFINAE illegal.

[Keane, Erich via cfe-commits]

Thanks for the heads up!  Looking now.

-Original Message-
From: Peter Smith [mailto:peter.sm...@linaro.org] 
Sent: Friday, January 18, 2019 2:33 AM
To: Keane, Erich 
Cc: cfe-commits cfe 
Subject: Re: r351495 - Make integral-o-pointer conversions in SFINAE illegal.

Hello Erich,

The test added in this commit is failing on the Arm and Hexagon builders. I 
think that this is because the expected type "long" in the warning text is 
"int" on these platforms (possibly other 32-bit host platforms).

The raw output from an Arm machine is:
llvm-project/clang/test/SemaCXX/int-ptr-cast-SFINAE.cpp:5:5: warning:
incompatible integer to pointer conversion assigning to 'int *' from 'int'; 
take the address with &
  a -= b; // expected-warning {{incompatible integer to pointer conversion 
assigning to 'int *' from 'long'}}
^  ~
   &

Could you take a look and update the test?

Thanks in advance

Peter

On Thu, 17 Jan 2019 at 23:14, Erich Keane via cfe-commits 
 wrote:
>
> Author: erichkeane
> Date: Thu Jan 17 15:11:15 2019
> New Revision: 351495
>
> URL: http://llvm.org/viewvc/llvm-project?rev=351495&view=rev
> Log:
> Make integral-o-pointer conversions in SFINAE illegal.
>
> As reported in PR40362, allowing the conversion from an integral to a 
> pointer type (despite being illegal in the C++ standard) will cause 
> surprsing results when testing for certain behaviors in SFINAE.  This 
> patch converts the error to a SFINAE Error and adds a test to ensure 
> that it is still a warning in non-SFINAE but an error in it.
>
> Change-Id: I1f475637fa4d83217ae37dc6b5dbf653e118fae4
>
> Added:
> cfe/trunk/test/SemaCXX/int-ptr-cast-SFINAE.cpp   (with props)
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Diag
> nosticSemaKinds.td?rev=351495&r1=351494&r2=351495&view=diff
> ==
> 
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu Jan 17 
> +++ 15:11:15 2019
> @@ -6817,7 +6817,7 @@ def ext_typecheck_convert_int_pointer :
>"; take the address with &|"
>"; remove *|"
>"; remove &}3">,
> -  InGroup;
> +  InGroup, SFINAEFailure;
>  def ext_typecheck_convert_pointer_void_func : Extension<
>"%select{%diff{assigning to $ from $|assigning to different types}0,1"
>"|%diff{passing $ to parameter of type $|"
>
> Added: cfe/trunk/test/SemaCXX/int-ptr-cast-SFINAE.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/int-ptr-cas
> t-SFINAE.cpp?rev=351495&view=auto 
> ==
> 
> --- cfe/trunk/test/SemaCXX/int-ptr-cast-SFINAE.cpp (added)
> +++ cfe/trunk/test/SemaCXX/int-ptr-cast-SFINAE.cpp Thu Jan 17 15:11:15 
> +++ 2019
> @@ -0,0 +1,22 @@
> +// RUN: %clang_cc1 -fsyntax-only -verify %s // RUN: %clang_cc1 
> +-fsyntax-only -verify %s -std=c++17
> +
> +void foo(int* a, int *b) {
> +  a -= b; // expected-warning {{incompatible integer to pointer 
> +conversion assigning to 'int *' from 'long'}} }
> +
> +template T declval();
> +struct true_type { static const bool value = true; }; struct 
> +false_type { static const bool value = false; }; template +typename T, typename U> struct select { using type = T; }; 
> +template struct select { using 
> +type = U; };
> +
> +
> +template
> +typename select<(sizeof(declval() -= declval(), 1) != 1), 
> +true_type, false_type>::type test(...); template 
> +false_type test(...);
> +
> +template
> +static const auto has_minus_assign = decltype(test())::value;
> +
> +static_assert(has_minus_assign, "failed"); // expected-error 
> +{{static_assert failed due to requirement 'has_minus_assign' 
> +"failed"}}
>
> Propchange: cfe/trunk/test/SemaCXX/int-ptr-cast-SFINAE.cpp
> --
> svn:eol-style = native
>
> Propchange: cfe/trunk/test/SemaCXX/int-ptr-cast-SFINAE.cpp
> --
> svn:keywords = "Author Date Id Rev URL"
>
> Propchange: cfe/trunk/test/SemaCXX/int-ptr-cast-SFINAE.cpp
> --
> svn:mime-type = text/plain
>
>
> ___
> 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: r349201 - Add extension to always default-initialize nullptr_t.

[Keane, Erich via cfe-commits]

Hi Richard-
I finally got a chance to take a look at this patch and run it through the 
nullptr_t tests that we have, and it seems to solve the problem I was 
attempting.  It would be my preference to commit this.

I currently have my existing tests (from the previous patch) and am happy with 
the messages.  What work to you believe needs to happen in order to get this 
committed?  I note that you didn’t have tests in it and I’m not sure what you 
were attempting to test initially, but if you can tell me what you were 
attempting to solve, I could perhaps come up with a handful of tests and commit 
this.

Thanks!
-Erich

From: Keane, Erich
Sent: Friday, December 14, 2018 2:57 PM
To: Richard Smith 
Cc: cfe-commits 
Subject: RE: r349201 - Add extension to always default-initialize nullptr_t.

Thanks!  I’ll take a look in a bit!
-Erich

From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Friday, December 14, 2018 2:55 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r349201 - Add extension to always default-initialize nullptr_t.

Attached. With the functional part of your change reverted and this applied, 
the modified tests still pass except

error: 'note' diagnostics expected but not seen:
  File 
/usr/local/google/home/richardsmith/llvm-git-1/src/tools/clang/test/Analysis/nullptr.cpp
 Line 128: 'p' initialized to a null pointer value
error: 'note' diagnostics seen but not expected:
  File 
/usr/local/google/home/richardsmith/llvm-git-1/src/tools/clang/test/Analysis/nullptr.cpp
 Line 128: 'p' declared without an initial value

... which seems accurate (but perhaps not useful).

On Fri, 14 Dec 2018 at 14:47, Richard Smith 
mailto:rich...@metafoo.co.uk>> wrote:
I have a patch I put together a while back as an attempt to fix a different 
bug, that creates a new CastKind for this operation (didn't work out there, but 
it might do so here). I'll dig it out and mail it to you in case it's a useful 
starting point.

On Fri, 14 Dec 2018 at 14:42, Keane, Erich via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Alright, no problem.  I’ll push a revert in a few minutes and give it another 
try.  Perhaps I can suppress the creation of a CK_LValueToRValue in the case 
where it’s a read from nullptr_t


From: Richard Smith [mailto:rich...@metafoo.co.uk<mailto:rich...@metafoo.co.uk>]
Sent: Friday, December 14, 2018 2:41 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r349201 - Add extension to always default-initialize nullptr_t.

Sorry, I was late with my review comment. I think this is the wrong way to 
approach this problem. This does not "fix all situations where nullptr_t would 
seem uninitialized", and it makes our AST representation lose source fidelity.

On Fri, 14 Dec 2018 at 14:25, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Fri Dec 14 14:22:29 2018
New Revision: 349201

URL: http://llvm.org/viewvc/llvm-project?rev=349201&view=rev
Log:
Add extension to always default-initialize nullptr_t.

Core issue 1013 suggests that having an uninitialied std::nullptr_t be
UB is a bit foolish, since there is only a single valid value. This DR
reports that DR616 fixes it, which does so by making lvalue-to-rvalue
conversions from nullptr_t be equal to nullptr.

However, just implementing that results in warnings/etc in many places.
In order to fix all situations where nullptr_t would seem uninitialized,
this patch instead (as an otherwise transparent extension) default
initializes uninitialized VarDecls of nullptr_t.

Differential Revision: https://reviews.llvm.org/D53713

Change-Id: I84d72a9290054fa55341e8cbdac43c8e7f25b885

Added:
cfe/trunk/test/SemaCXX/nullptr_t-init.cpp   (with props)
Modified:
cfe/trunk/lib/Sema/SemaInit.cpp
cfe/trunk/test/Analysis/nullptr.cpp
cfe/trunk/test/SemaCXX/ast-print-crash.cpp

Modified: cfe/trunk/lib/Sema/SemaInit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaInit.cpp?rev=349201&r1=349200&r2=349201&view=diff
==
--- cfe/trunk/lib/Sema/SemaInit.cpp (original)
+++ cfe/trunk/lib/Sema/SemaInit.cpp Fri Dec 14 14:22:29 2018
@@ -4881,6 +4881,13 @@ static void TryDefaultInitialization(Sem
 return;
   }

+  // As an extension, and to fix Core issue 1013, zero initialize nullptr_t.
+  // Since there is only 1 valid value of nullptr_t, we can just use that.
+  if (DestType->isNullPtrType()) {
+Sequence.AddZeroInitializationStep(Entity.getType());
+return;
+  }
+
   // - otherwise, no initialization is performed.

   //   If a program calls for the default initialization of an object of

Modified: cfe/trunk/test/Analysi

RE: r350643 - Limit COFF 'common' emission to <=32 alignment types.

[Keane, Erich via cfe-commits]

Thank you for that!

From: Shoaib Meenai [mailto:smee...@fb.com]
Sent: Tuesday, January 8, 2019 4:48 PM
To: David Majnemer 
Cc: Keane, Erich ; cfe-commits@lists.llvm.org; Martin 
Storsjo 
Subject: Re: r350643 - Limit COFF 'common' emission to <=32 alignment types.

I sent out https://reviews.llvm.org/D56466 to clarify the comment accordingly.

From: David Majnemer mailto:david.majne...@gmail.com>>
Date: Tuesday, January 8, 2019 at 3:21 PM
To: Shoaib Meenai mailto:smee...@fb.com>>
Cc: "Keane, Erich" mailto:erich.ke...@intel.com>>, 
"cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>, Martin Storsjo 
mailto:mar...@martin.st>>
Subject: Re: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Yes, the MinGW toolchain can handle this by specifying the alignment of a 
common symbol using the aligncomm directive. The MSVC toolchain has no such 
mechanism.

This is why the check uses isKnownWindowsMSVCEnvironment.

On Tue, Jan 8, 2019 at 1:09 PM Shoaib Meenai 
mailto:smee...@fb.com>> wrote:
It checks for both OS=Win32 and Environment=MSVC, so that wouldn't cover other 
COFF environments. wbs (Martin Storsjo) mentioned on IRC that MinGW adds an 
aligncomm directive to specify alignment for common symbols, so perhaps that's 
part of it?

From: "Keane, Erich" mailto:erich.ke...@intel.com>>
Date: Tuesday, January 8, 2019 at 1:04 PM
To: Shoaib Meenai mailto:smee...@fb.com>>, 
"cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>, David Majnemer 
mailto:david.majne...@gmail.com>>
Subject: RE: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Yep, exactly.  I looked, and isKnownWindowsMSVCEnvironment checks for OS=Win32, 
which I believe would be different for other architectures.

From: Shoaib Meenai [mailto:smee...@fb.com]
Sent: Tuesday, January 8, 2019 12:41 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>; 
cfe-commits@lists.llvm.org; David Majnemer 
mailto:david.majne...@gmail.com>>
Subject: Re: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Ah, looks like you were originally checking for COFF, and then David suggested 
checking for MSVC instead? I'm curious about why, although I'm sure the 
suggestion is legit :)

From: cfe-commits 
mailto:cfe-commits-boun...@lists.llvm.org>> 
on behalf of Shoaib Meenai via cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Reply-To: Shoaib Meenai mailto:smee...@fb.com>>
Date: Tuesday, January 8, 2019 at 12:39 PM
To: Erich Keane mailto:erich.ke...@intel.com>>, 
"cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Why does this check for isKnownWindowsMSVCEnvironment specifically? Wouldn't 
any COFF target (windows-cygnus, windows-gnu, windows-itanium, etc.) have the 
same limitation, since it's an object file format issue and not an ABI issue?

From: cfe-commits 
mailto:cfe-commits-boun...@lists.llvm.org>> 
on behalf of Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Reply-To: Erich Keane mailto:erich.ke...@intel.com>>
Date: Tuesday, January 8, 2019 at 10:48 AM
To: "cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>
Subject: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Author: erichkeane
Date: Tue Jan  8 10:44:22 2019
New Revision: 350643

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D350643-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=Ph9GOtRaQERmqyeJeAJTFwV3sg3q8fE05FlJ3qwNx4I&e=
Log:
Limit COFF 'common' emission to <=32 alignment types.

As reported in PR33035, LLVM crashes if given a common object with an
alignment of greater than 32 bits. This is because the COFF file format
does not support these alignments, so emitting them is broken anyway.

This patch changes any global definitions greater than 32 bit alignment
to no longer be in 'common'.

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D33035&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=ac1NEHuvztd6jSTCsOUJajkklfeyqdzW-xqtddJ-hvM&e=

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D56391&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=AucP9Sp-DYHSaOP-sPfpAOrww3xwdh8FjQkHrLZhhyo&e=

Change-Id: I48609289753b7f3b58c5e2bc1712756750fbd45a

Added:
cfe/trunk/test/CodeGen/microsoft-no-common-align.c
Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_t

RE: r350643 - Limit COFF 'common' emission to <=32 alignment types.

[Keane, Erich via cfe-commits]

That seems like it would make sense to me.  COFF isn’t my expertise, so 
hopefully David/Martin/others can let me know if this is subtly broken 
elsewhere.

From: Shoaib Meenai [mailto:smee...@fb.com]
Sent: Tuesday, January 8, 2019 1:09 PM
To: Keane, Erich ; cfe-commits@lists.llvm.org; David 
Majnemer ; Martin Storsjo 
Subject: Re: r350643 - Limit COFF 'common' emission to <=32 alignment types.

It checks for both OS=Win32 and Environment=MSVC, so that wouldn't cover other 
COFF environments. wbs (Martin Storsjo) mentioned on IRC that MinGW adds an 
aligncomm directive to specify alignment for common symbols, so perhaps that's 
part of it?

From: "Keane, Erich" mailto:erich.ke...@intel.com>>
Date: Tuesday, January 8, 2019 at 1:04 PM
To: Shoaib Meenai mailto:smee...@fb.com>>, 
"cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>, David Majnemer 
mailto:david.majne...@gmail.com>>
Subject: RE: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Yep, exactly.  I looked, and isKnownWindowsMSVCEnvironment checks for OS=Win32, 
which I believe would be different for other architectures.

From: Shoaib Meenai [mailto:smee...@fb.com]
Sent: Tuesday, January 8, 2019 12:41 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>; 
cfe-commits@lists.llvm.org; David Majnemer 
mailto:david.majne...@gmail.com>>
Subject: Re: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Ah, looks like you were originally checking for COFF, and then David suggested 
checking for MSVC instead? I'm curious about why, although I'm sure the 
suggestion is legit :)

From: cfe-commits 
mailto:cfe-commits-boun...@lists.llvm.org>> 
on behalf of Shoaib Meenai via cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Reply-To: Shoaib Meenai mailto:smee...@fb.com>>
Date: Tuesday, January 8, 2019 at 12:39 PM
To: Erich Keane mailto:erich.ke...@intel.com>>, 
"cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Why does this check for isKnownWindowsMSVCEnvironment specifically? Wouldn't 
any COFF target (windows-cygnus, windows-gnu, windows-itanium, etc.) have the 
same limitation, since it's an object file format issue and not an ABI issue?

From: cfe-commits 
mailto:cfe-commits-boun...@lists.llvm.org>> 
on behalf of Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Reply-To: Erich Keane mailto:erich.ke...@intel.com>>
Date: Tuesday, January 8, 2019 at 10:48 AM
To: "cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>
Subject: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Author: erichkeane
Date: Tue Jan  8 10:44:22 2019
New Revision: 350643

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D350643-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=Ph9GOtRaQERmqyeJeAJTFwV3sg3q8fE05FlJ3qwNx4I&e=
Log:
Limit COFF 'common' emission to <=32 alignment types.

As reported in PR33035, LLVM crashes if given a common object with an
alignment of greater than 32 bits. This is because the COFF file format
does not support these alignments, so emitting them is broken anyway.

This patch changes any global definitions greater than 32 bit alignment
to no longer be in 'common'.

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D33035&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=ac1NEHuvztd6jSTCsOUJajkklfeyqdzW-xqtddJ-hvM&e=

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D56391&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=AucP9Sp-DYHSaOP-sPfpAOrww3xwdh8FjQkHrLZhhyo&e=

Change-Id: I48609289753b7f3b58c5e2bc1712756750fbd45a

Added:
cfe/trunk/test/CodeGen/microsoft-no-common-align.c
Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_lib_CodeGen_CodeGenModule.cpp-3Frev-3D350643-26r1-3D350642-26r2-3D350643-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=gmTnEmW03ruG8LbJluf5Z4yQcxM64QP7Ce1VTnVqvPo&e=
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Tue Jan  8 10:44:22 2019
@@ -3761,6 +3761,11 @@ static bool isVarDeclStrongDefinition(co
   }
 }
   }
+  // COFF doesn't support alignments greater than 32, so these cannot be
+  // in common.
+  if (Context.getTargetInfo().getTriple().isKnownWindowsM

RE: r350643 - Limit COFF 'common' emission to <=32 alignment types.

[Keane, Erich via cfe-commits]

Yep, exactly.  I looked, and isKnownWindowsMSVCEnvironment checks for OS=Win32, 
which I believe would be different for other architectures.

From: Shoaib Meenai [mailto:smee...@fb.com]
Sent: Tuesday, January 8, 2019 12:41 PM
To: Keane, Erich ; cfe-commits@lists.llvm.org; David 
Majnemer 
Subject: Re: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Ah, looks like you were originally checking for COFF, and then David suggested 
checking for MSVC instead? I'm curious about why, although I'm sure the 
suggestion is legit :)

From: cfe-commits 
mailto:cfe-commits-boun...@lists.llvm.org>> 
on behalf of Shoaib Meenai via cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Reply-To: Shoaib Meenai mailto:smee...@fb.com>>
Date: Tuesday, January 8, 2019 at 12:39 PM
To: Erich Keane mailto:erich.ke...@intel.com>>, 
"cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Why does this check for isKnownWindowsMSVCEnvironment specifically? Wouldn't 
any COFF target (windows-cygnus, windows-gnu, windows-itanium, etc.) have the 
same limitation, since it's an object file format issue and not an ABI issue?

From: cfe-commits 
mailto:cfe-commits-boun...@lists.llvm.org>> 
on behalf of Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>>
Reply-To: Erich Keane mailto:erich.ke...@intel.com>>
Date: Tuesday, January 8, 2019 at 10:48 AM
To: "cfe-commits@lists.llvm.org" 
mailto:cfe-commits@lists.llvm.org>>
Subject: r350643 - Limit COFF 'common' emission to <=32 alignment types.

Author: erichkeane
Date: Tue Jan  8 10:44:22 2019
New Revision: 350643

URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D350643-26view-3Drev&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=Ph9GOtRaQERmqyeJeAJTFwV3sg3q8fE05FlJ3qwNx4I&e=
Log:
Limit COFF 'common' emission to <=32 alignment types.

As reported in PR33035, LLVM crashes if given a common object with an
alignment of greater than 32 bits. This is because the COFF file format
does not support these alignments, so emitting them is broken anyway.

This patch changes any global definitions greater than 32 bit alignment
to no longer be in 'common'.

https://urldefense.proofpoint.com/v2/url?u=https-3A__bugs.llvm.org_show-5Fbug.cgi-3Fid-3D33035&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=ac1NEHuvztd6jSTCsOUJajkklfeyqdzW-xqtddJ-hvM&e=

Differential Revision: 
https://urldefense.proofpoint.com/v2/url?u=https-3A__reviews.llvm.org_D56391&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=AucP9Sp-DYHSaOP-sPfpAOrww3xwdh8FjQkHrLZhhyo&e=

Change-Id: I48609289753b7f3b58c5e2bc1712756750fbd45a

Added:
cfe/trunk/test/CodeGen/microsoft-no-common-align.c
Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_lib_CodeGen_CodeGenModule.cpp-3Frev-3D350643-26r1-3D350642-26r2-3D350643-26view-3Ddiff&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=gmTnEmW03ruG8LbJluf5Z4yQcxM64QP7Ce1VTnVqvPo&e=
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Tue Jan  8 10:44:22 2019
@@ -3761,6 +3761,11 @@ static bool isVarDeclStrongDefinition(co
   }
 }
   }
+  // COFF doesn't support alignments greater than 32, so these cannot be
+  // in common.
+  if (Context.getTargetInfo().getTriple().isKnownWindowsMSVCEnvironment() &&
+  Context.getTypeAlignIfKnown(D->getType()) > 32)
+return true;
   return false;
}

Added: cfe/trunk/test/CodeGen/microsoft-no-common-align.c
URL: 
https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_test_CodeGen_microsoft-2Dno-2Dcommon-2Dalign.c-3Frev-3D350643-26view-3Dauto&d=DwIGaQ&c=5VD0RTtNlTh3ycd41b3MUw&r=o3kDXzdBUE3ljQXKeTWOMw&m=RNVKy_b0_Wgp_PTFDpvQXETsZdWubmT5SGnGz3GigS0&s=hzPmmVFbvg4OTEVpnQ5pIfy295Ne0-xAsctZs00WZgY&e=
==
--- cfe/trunk/test/CodeGen/microsoft-no-common-align.c (added)
+++ cfe/trunk/test/CodeGen/microsoft-no-common-align.c Tue Jan  8 10:44:22 2019
@@ -0,0 +1,8 @@
+// RUN: %clang_cc1 -triple x86_64-windows-msvc -emit-llvm -o - %s | FileCheck 
%s
+typedef float TooLargeAlignment __attribute__((__vector_size__(64)));
+typedef float NormalAlignment __attribute__((__vector_size__(4)));
+
+TooLargeAlignment TooBig;
+// CHECK: @TooBig = dso_local global <16 x float>  zeroinitializer, align 64
+NormalAlignment JustRight;
+// CHECK: @JustRight

RE: r349201 - Add extension to always default-initialize nullptr_t.

[Keane, Erich via cfe-commits]

Thanks!  I’ll take a look in a bit!
-Erich

From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Friday, December 14, 2018 2:55 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r349201 - Add extension to always default-initialize nullptr_t.

Attached. With the functional part of your change reverted and this applied, 
the modified tests still pass except

error: 'note' diagnostics expected but not seen:
  File 
/usr/local/google/home/richardsmith/llvm-git-1/src/tools/clang/test/Analysis/nullptr.cpp
 Line 128: 'p' initialized to a null pointer value
error: 'note' diagnostics seen but not expected:
  File 
/usr/local/google/home/richardsmith/llvm-git-1/src/tools/clang/test/Analysis/nullptr.cpp
 Line 128: 'p' declared without an initial value

... which seems accurate (but perhaps not useful).

On Fri, 14 Dec 2018 at 14:47, Richard Smith 
mailto:rich...@metafoo.co.uk>> wrote:
I have a patch I put together a while back as an attempt to fix a different 
bug, that creates a new CastKind for this operation (didn't work out there, but 
it might do so here). I'll dig it out and mail it to you in case it's a useful 
starting point.

On Fri, 14 Dec 2018 at 14:42, Keane, Erich via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Alright, no problem.  I’ll push a revert in a few minutes and give it another 
try.  Perhaps I can suppress the creation of a CK_LValueToRValue in the case 
where it’s a read from nullptr_t


From: Richard Smith [mailto:rich...@metafoo.co.uk<mailto:rich...@metafoo.co.uk>]
Sent: Friday, December 14, 2018 2:41 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r349201 - Add extension to always default-initialize nullptr_t.

Sorry, I was late with my review comment. I think this is the wrong way to 
approach this problem. This does not "fix all situations where nullptr_t would 
seem uninitialized", and it makes our AST representation lose source fidelity.

On Fri, 14 Dec 2018 at 14:25, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Fri Dec 14 14:22:29 2018
New Revision: 349201

URL: http://llvm.org/viewvc/llvm-project?rev=349201&view=rev
Log:
Add extension to always default-initialize nullptr_t.

Core issue 1013 suggests that having an uninitialied std::nullptr_t be
UB is a bit foolish, since there is only a single valid value. This DR
reports that DR616 fixes it, which does so by making lvalue-to-rvalue
conversions from nullptr_t be equal to nullptr.

However, just implementing that results in warnings/etc in many places.
In order to fix all situations where nullptr_t would seem uninitialized,
this patch instead (as an otherwise transparent extension) default
initializes uninitialized VarDecls of nullptr_t.

Differential Revision: https://reviews.llvm.org/D53713

Change-Id: I84d72a9290054fa55341e8cbdac43c8e7f25b885

Added:
cfe/trunk/test/SemaCXX/nullptr_t-init.cpp   (with props)
Modified:
cfe/trunk/lib/Sema/SemaInit.cpp
cfe/trunk/test/Analysis/nullptr.cpp
cfe/trunk/test/SemaCXX/ast-print-crash.cpp

Modified: cfe/trunk/lib/Sema/SemaInit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaInit.cpp?rev=349201&r1=349200&r2=349201&view=diff
==
--- cfe/trunk/lib/Sema/SemaInit.cpp (original)
+++ cfe/trunk/lib/Sema/SemaInit.cpp Fri Dec 14 14:22:29 2018
@@ -4881,6 +4881,13 @@ static void TryDefaultInitialization(Sem
 return;
   }

+  // As an extension, and to fix Core issue 1013, zero initialize nullptr_t.
+  // Since there is only 1 valid value of nullptr_t, we can just use that.
+  if (DestType->isNullPtrType()) {
+Sequence.AddZeroInitializationStep(Entity.getType());
+return;
+  }
+
   // - otherwise, no initialization is performed.

   //   If a program calls for the default initialization of an object of

Modified: cfe/trunk/test/Analysis/nullptr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/nullptr.cpp?rev=349201&r1=349200&r2=349201&view=diff
==
--- cfe/trunk/test/Analysis/nullptr.cpp (original)
+++ cfe/trunk/test/Analysis/nullptr.cpp Fri Dec 14 14:22:29 2018
@@ -125,21 +125,16 @@ struct Type {
 };

 void shouldNotCrash() {
-  decltype(nullptr) p; // expected-note{{'p' declared without an initial 
value}}
-  if (getSymbol()) // expected-note   {{Assuming the condition is false}}
-   // expected-note@-1{{Taking false branch}}
-   // expected-note@-2{{Assuming the condition is false}}
-   // expected-note@-3{{Taking false branch}}
-   // expected-note@-4{{Assuming the condition is true}}
-   // expected-note@-5{{Taking true br

RE: r349201 - Add extension to always default-initialize nullptr_t.

[Keane, Erich via cfe-commits]

Reverted in r349206.

From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Friday, December 14, 2018 2:41 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r349201 - Add extension to always default-initialize nullptr_t.

Sorry, I was late with my review comment. I think this is the wrong way to 
approach this problem. This does not "fix all situations where nullptr_t would 
seem uninitialized", and it makes our AST representation lose source fidelity.

On Fri, 14 Dec 2018 at 14:25, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Fri Dec 14 14:22:29 2018
New Revision: 349201

URL: http://llvm.org/viewvc/llvm-project?rev=349201&view=rev
Log:
Add extension to always default-initialize nullptr_t.

Core issue 1013 suggests that having an uninitialied std::nullptr_t be
UB is a bit foolish, since there is only a single valid value. This DR
reports that DR616 fixes it, which does so by making lvalue-to-rvalue
conversions from nullptr_t be equal to nullptr.

However, just implementing that results in warnings/etc in many places.
In order to fix all situations where nullptr_t would seem uninitialized,
this patch instead (as an otherwise transparent extension) default
initializes uninitialized VarDecls of nullptr_t.

Differential Revision: https://reviews.llvm.org/D53713

Change-Id: I84d72a9290054fa55341e8cbdac43c8e7f25b885

Added:
cfe/trunk/test/SemaCXX/nullptr_t-init.cpp   (with props)
Modified:
cfe/trunk/lib/Sema/SemaInit.cpp
cfe/trunk/test/Analysis/nullptr.cpp
cfe/trunk/test/SemaCXX/ast-print-crash.cpp

Modified: cfe/trunk/lib/Sema/SemaInit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaInit.cpp?rev=349201&r1=349200&r2=349201&view=diff
==
--- cfe/trunk/lib/Sema/SemaInit.cpp (original)
+++ cfe/trunk/lib/Sema/SemaInit.cpp Fri Dec 14 14:22:29 2018
@@ -4881,6 +4881,13 @@ static void TryDefaultInitialization(Sem
 return;
   }

+  // As an extension, and to fix Core issue 1013, zero initialize nullptr_t.
+  // Since there is only 1 valid value of nullptr_t, we can just use that.
+  if (DestType->isNullPtrType()) {
+Sequence.AddZeroInitializationStep(Entity.getType());
+return;
+  }
+
   // - otherwise, no initialization is performed.

   //   If a program calls for the default initialization of an object of

Modified: cfe/trunk/test/Analysis/nullptr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/nullptr.cpp?rev=349201&r1=349200&r2=349201&view=diff
==
--- cfe/trunk/test/Analysis/nullptr.cpp (original)
+++ cfe/trunk/test/Analysis/nullptr.cpp Fri Dec 14 14:22:29 2018
@@ -125,21 +125,16 @@ struct Type {
 };

 void shouldNotCrash() {
-  decltype(nullptr) p; // expected-note{{'p' declared without an initial 
value}}
-  if (getSymbol()) // expected-note   {{Assuming the condition is false}}
-   // expected-note@-1{{Taking false branch}}
-   // expected-note@-2{{Assuming the condition is false}}
-   // expected-note@-3{{Taking false branch}}
-   // expected-note@-4{{Assuming the condition is true}}
-   // expected-note@-5{{Taking true branch}}
-invokeF(p); // expected-warning{{1st function call argument is an 
uninitialized value}}
-// expected-note@-1{{1st function call argument is an 
uninitialized value}}
+  decltype(nullptr) p; // expected-note{{'p' initialized to a null pointer 
value}}
   if (getSymbol()) // expected-note   {{Assuming the condition is false}}
// expected-note@-1{{Taking false branch}}
// expected-note@-2{{Assuming the condition is true}}
// expected-note@-3{{Taking true branch}}
-invokeF(nullptr); // expected-note   {{Calling 'invokeF'}}
-  // expected-note@-1{{Passing null pointer value via 1st 
parameter 'x'}}
+invokeF(p); // expected-note{{Passing null pointer value via 1st parameter 
'x'}}
+// expected-note@-1{{Calling 'invokeF'}}
+  if (getSymbol()) // expected-note   {{Assuming the condition is false}}
+   // expected-note@-1{{Taking false branch}}
+invokeF(nullptr);
   if (getSymbol()) {  // expected-note  {{Assuming the condition is true}}
   // expected-note@-1{{Taking true branch}}
 X *xx = Type().x; // expected-note   {{Null pointer value stored to field 
'x'}}

Modified: cfe/trunk/test/SemaCXX/ast-print-crash.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/ast-print-crash.cpp?rev=349201&r1=349200&r2=349201&view=diff
==
--- cfe/trunk/test/SemaCXX/ast-print-crash.cpp (original)
+++ cfe/trunk/test/SemaCXX/ast-print-crash.cpp Fri Dec 14 14:22:29 2018
@@ -7,6 +7,6 @@

 // CHECK:   

RE: r349201 - Add extension to always default-initialize nullptr_t.

[Keane, Erich via cfe-commits]

Alright, no problem.  I’ll push a revert in a few minutes and give it another 
try.  Perhaps I can suppress the creation of a CK_LValueToRValue in the case 
where it’s a read from nullptr_t


From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Friday, December 14, 2018 2:41 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r349201 - Add extension to always default-initialize nullptr_t.

Sorry, I was late with my review comment. I think this is the wrong way to 
approach this problem. This does not "fix all situations where nullptr_t would 
seem uninitialized", and it makes our AST representation lose source fidelity.

On Fri, 14 Dec 2018 at 14:25, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Fri Dec 14 14:22:29 2018
New Revision: 349201

URL: http://llvm.org/viewvc/llvm-project?rev=349201&view=rev
Log:
Add extension to always default-initialize nullptr_t.

Core issue 1013 suggests that having an uninitialied std::nullptr_t be
UB is a bit foolish, since there is only a single valid value. This DR
reports that DR616 fixes it, which does so by making lvalue-to-rvalue
conversions from nullptr_t be equal to nullptr.

However, just implementing that results in warnings/etc in many places.
In order to fix all situations where nullptr_t would seem uninitialized,
this patch instead (as an otherwise transparent extension) default
initializes uninitialized VarDecls of nullptr_t.

Differential Revision: https://reviews.llvm.org/D53713

Change-Id: I84d72a9290054fa55341e8cbdac43c8e7f25b885

Added:
cfe/trunk/test/SemaCXX/nullptr_t-init.cpp   (with props)
Modified:
cfe/trunk/lib/Sema/SemaInit.cpp
cfe/trunk/test/Analysis/nullptr.cpp
cfe/trunk/test/SemaCXX/ast-print-crash.cpp

Modified: cfe/trunk/lib/Sema/SemaInit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaInit.cpp?rev=349201&r1=349200&r2=349201&view=diff
==
--- cfe/trunk/lib/Sema/SemaInit.cpp (original)
+++ cfe/trunk/lib/Sema/SemaInit.cpp Fri Dec 14 14:22:29 2018
@@ -4881,6 +4881,13 @@ static void TryDefaultInitialization(Sem
 return;
   }

+  // As an extension, and to fix Core issue 1013, zero initialize nullptr_t.
+  // Since there is only 1 valid value of nullptr_t, we can just use that.
+  if (DestType->isNullPtrType()) {
+Sequence.AddZeroInitializationStep(Entity.getType());
+return;
+  }
+
   // - otherwise, no initialization is performed.

   //   If a program calls for the default initialization of an object of

Modified: cfe/trunk/test/Analysis/nullptr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/nullptr.cpp?rev=349201&r1=349200&r2=349201&view=diff
==
--- cfe/trunk/test/Analysis/nullptr.cpp (original)
+++ cfe/trunk/test/Analysis/nullptr.cpp Fri Dec 14 14:22:29 2018
@@ -125,21 +125,16 @@ struct Type {
 };

 void shouldNotCrash() {
-  decltype(nullptr) p; // expected-note{{'p' declared without an initial 
value}}
-  if (getSymbol()) // expected-note   {{Assuming the condition is false}}
-   // expected-note@-1{{Taking false branch}}
-   // expected-note@-2{{Assuming the condition is false}}
-   // expected-note@-3{{Taking false branch}}
-   // expected-note@-4{{Assuming the condition is true}}
-   // expected-note@-5{{Taking true branch}}
-invokeF(p); // expected-warning{{1st function call argument is an 
uninitialized value}}
-// expected-note@-1{{1st function call argument is an 
uninitialized value}}
+  decltype(nullptr) p; // expected-note{{'p' initialized to a null pointer 
value}}
   if (getSymbol()) // expected-note   {{Assuming the condition is false}}
// expected-note@-1{{Taking false branch}}
// expected-note@-2{{Assuming the condition is true}}
// expected-note@-3{{Taking true branch}}
-invokeF(nullptr); // expected-note   {{Calling 'invokeF'}}
-  // expected-note@-1{{Passing null pointer value via 1st 
parameter 'x'}}
+invokeF(p); // expected-note{{Passing null pointer value via 1st parameter 
'x'}}
+// expected-note@-1{{Calling 'invokeF'}}
+  if (getSymbol()) // expected-note   {{Assuming the condition is false}}
+   // expected-note@-1{{Taking false branch}}
+invokeF(nullptr);
   if (getSymbol()) {  // expected-note  {{Assuming the condition is true}}
   // expected-note@-1{{Taking true branch}}
 X *xx = Type().x; // expected-note   {{Null pointer value stored to field 
'x'}}

Modified: cfe/trunk/test/SemaCXX/ast-print-crash.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/ast-print-crash.cpp?rev=349201&r1=349200&r2=349201&view=diff
=

RE: [cfe-dev] Dumping AST information to other formats

[Keane, Erich via cfe-commits]

I'd be tentative to commit to any stability guarantees, particularly as the AST 
tends to change reasonably often.  That said, I can see the value of this.

Additionally, it would be preferential I suspect if we could make the standard 
ast-dump just another (albeit default) "format" in whatever plugin architecture 
you plan.  I presume that would result in a lesser maintenance burden (again, 
depending on the plugin architecture).  

-Original Message-
From: cfe-dev [mailto:cfe-dev-boun...@lists.llvm.org] On Behalf Of Aaron 
Ballman via cfe-dev
Sent: Monday, November 26, 2018 11:20 AM
To: cfe-dev ; cfe-commits 
Cc: Eric Schulte 
Subject: [cfe-dev] Dumping AST information to other formats

Clang currently supports various -cc1 options that allow displaying AST 
information (-ast-dump, -ast-print, -ast-list, etc), but these options are not 
convenient to consume by third-party tools. GrammaTech has ongoing research 
efforts where we would like to output some information from the AST to a more 
open machine-consumable format (such as JSON or s-expressions). We propose 
adding an optional output format to the -ast-dump command allowing the user to 
select from either the default or JSON formats. If the output format is not 
explicitly specified, it will continue to default to the same textual 
representation it uses today. e.g., clang -cc1 -ast-dump=json foo.c.
This feature is intended to output a safe subset of AST information that is 
considered crucial rather than an implementation detail (like the name of a 
NamedDecl object and the SourceRange for the name), so the output is expected 
to be mostly stable between releases.

Once upon a time, there was -ast-print-xml. This -cc1 option was dropped 
because it was frequently out of sync with the AST data. It is right to ask: 
why would JSON, etc be any different? This is still an open question, but a 
goal of this implementation will be to ensure it's easier to maintain as the 
AST evolves. However, this feature is intended to output a safe subset of AST 
information, so I don't think this feature will require any more burden to 
support than -ast-dump already requires (which is extremely limited). If AST 
information is found to be missing from the output, it seems reasonable to have 
a discussion as to whether it is stable information or an implementation 
detail, so missing information is to be expected rather than concerned by. That 
said, GrammaTech is able to commit to maintaining this code for at least the 
next 1-2 years and possibly beyond as it useful functionality for our research 
efforts.

I wanted to see if there were concerns or implementation ideas the community 
wanted to share before beginning the implementation phase of this feature.

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

RE: r346677 - Implement P1094R2 (nested inline namespaces)

[Keane, Erich via cfe-commits]

Coolbeans, will do!  Thanks for the review.

-Erich

From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Monday, November 12, 2018 11:59 AM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r346677 - Implement P1094R2 (nested inline namespaces)

On Mon, 12 Nov 2018 at 09:22, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Mon Nov 12 09:19:48 2018
New Revision: 346677

URL: http://llvm.org/viewvc/llvm-project?rev=346677&view=rev
Log:
Implement P1094R2 (nested inline namespaces)

As approved for the Working Paper in San Diego, support annotating
inline namespaces with 'inline'.

Change-Id: I51a654e11ffb475bf27cccb2458768151619e384

Added:
cfe/trunk/test/Parser/cxx2a-inline-nested-namespace-definition.cpp   (with 
props)
Modified:
cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
cfe/trunk/include/clang/Parse/Parser.h
cfe/trunk/lib/Parse/ParseDeclCXX.cpp
cfe/trunk/www/cxx_status.html

Modified: cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td?rev=346677&r1=346676&r2=346677&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td Mon Nov 12 09:19:48 
2018
@@ -222,6 +222,11 @@ def ext_nested_namespace_definition : Ex
 def warn_cxx14_compat_nested_namespace_definition : Warning<
   "nested namespace definition is incompatible with C++ standards before 
C++17">,
   InGroup, DefaultIgnore;
+def ext_inline_nested_namespace_definition : ExtWarn<
+  "inline nested namespace definition is a C++2a extension">, InGroup;
+def warn_cxx17_compat_inline_nested_namespace_definition : Warning<
+  "inline nested namespace definition is incompatible with C++ standards 
before"
+  " C++2a">, InGroup, DefaultIgnore;
 def err_inline_nested_namespace_definition : Error<
   "nested namespace definition cannot be 'inline'">;
 def err_expected_semi_after_attribute_list : Error<

Modified: cfe/trunk/include/clang/Parse/Parser.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Parse/Parser.h?rev=346677&r1=346676&r2=346677&view=diff
==
--- cfe/trunk/include/clang/Parse/Parser.h (original)
+++ cfe/trunk/include/clang/Parse/Parser.h Mon Nov 12 09:19:48 2018
@@ -2659,9 +2659,16 @@ private:
   DeclGroupPtrTy ParseNamespace(DeclaratorContext Context,
 SourceLocation &DeclEnd,
 SourceLocation InlineLoc = SourceLocation());
-  void ParseInnerNamespace(std::vector &IdentLoc,
-   std::vector &Ident,
-   std::vector &NamespaceLoc,
+
+  struct InnerNamespaceInfo {
+SourceLocation NamespaceLoc;
+SourceLocation InlineLoc;
+SourceLocation IdentLoc;
+IdentifierInfo *Ident;
+  };
+  using InnerNamespaceInfoList = llvm::SmallVector;
+
+  void ParseInnerNamespace(const InnerNamespaceInfoList &InnerNSs,
unsigned int index, SourceLocation &InlineLoc,
ParsedAttributes &attrs,
BalancedDelimiterTracker &Tracker);

Modified: cfe/trunk/lib/Parse/ParseDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseDeclCXX.cpp?rev=346677&r1=346676&r2=346677&view=diff
==
--- cfe/trunk/lib/Parse/ParseDeclCXX.cpp (original)
+++ cfe/trunk/lib/Parse/ParseDeclCXX.cpp Mon Nov 12 09:19:48 2018
@@ -33,24 +33,23 @@ using namespace clang;
 /// may either be a top level namespace or a block-level namespace alias. If
 /// there was an inline keyword, it has already been parsed.
 ///
-///   namespace-definition: [C++ 7.3: basic.namespace]
+///   namespace-definition: [C++: namespace.def]
 /// named-namespace-definition
 /// unnamed-namespace-definition
+/// nested-namespace-definition
+///
+///   named-namespace-definition:
+/// 'inline'[opt] 'namespace' attributes[opt] identifier '{' 
namespace-body '}'
 ///
 ///   unnamed-namespace-definition:
 /// 'inline'[opt] 'namespace' attributes[opt] '{' namespace-body '}'
 ///
-///   named-namespace-definition:
-/// original-namespace-definition
-/// extension-namespace-definition
+///   nested-namespace-definition:
+/// 'namespace' enclosing-namespace-specifier '::' 'inline'[opt] 
identifier '{' namespace-body '}'
 ///
-///   original-namespace-definition:
-/// 'inline'[opt] 'namespace' identifier attributes[opt]
-/// '{' namespace-body '}'
-///
-///   extension-namespace-definition:
-/// 'inline'[opt] 'namespace' original-namespace-name
-/// '{' namespace-body '}'
+///   enclosi

RE: r344957 - Give Multiversion-inline functions linkonce linkage

[Keane, Erich via cfe-commits]

From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Monday, October 29, 2018 11:41 AM
To: Keane, Erich 
Cc: Eric Christopher ; cfe-commits@lists.llvm.org
Subject: Re: r344957 - Give Multiversion-inline functions linkonce linkage


On Mon, Oct 29, 2018 at 11:30 AM Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
GCC actually doesn’t support function multiversioning in C mode, so this fix is 
part of our extension to support C with multiversioning.

Ah, what's the motivation for that?
[Keane, Erich] Basically, I identified no good reason to not support it.  GCC’s 
motivation is lost to time as far as I can tell.  This multiversioning is super 
useful in my employer’s math/intrinsic libraries (MKL uses this feature 
extensively), so enabling it in C seemed like a positive improvement.  We’ve 
made some other behavioral changes to make ‘target’ work more sanely to 
suppress some of the worst bugs (becoming MV after usage) as well as make it 
work better with Clang’s emit-functionality.


  I perhaps wonder if this is part of the reason GCC only supports it in C++ 
mode...

Yeah... could be.

I mean I suppose using linkonce isn't making multiversioning any worse in C 
than it already is in C++ inline functions (which is where it's pretty easy to 
misuse, as I understand it - two files, one compiled with a CPU feature, one 
without, linkonce functions get linked together & the linker picks one - then 
code built without the feature calls code that uses the feature - but, I mean, 
that can happen even witohut multiversioning, if you compile some source files 
with a feature and some without) - I guess the main risk would be if it 
confuses users by making multiversioned C inline functions end up behaving too 
differently from non-multiversioned ones...
[Keane, Erich] I suspect that multiversioning is such a sharp edged feature, 
that a change like this makes it a touch more sane.  Since the individual 
versions are independently mangled, you don’t have to worry about merging 
different versions.  The only real issue comes from merging the resolver 
functions if the visible list of declarations is different, but we treat that 
as an ODR violation.


- Dave


From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Monday, October 29, 2018 11:25 AM
To: Keane, Erich mailto:erich.ke...@intel.com>>; Eric 
Christopher mailto:echri...@gmail.com>>
Cc: cfe-commits@lists.llvm.org
Subject: Re: r344957 - Give Multiversion-inline functions linkonce linkage

Does this match GCC's approach here?

(I ask this sort of as throwaway/conversation starter - because the 
linkage/behavior around multiversion functions and their inlining is full of 
sharp corners/risks of code moving out of the areas appropriately restricted 
based on the cpu features)
On Mon, Oct 22, 2018 at 2:22 PM Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Mon Oct 22 14:20:45 2018
New Revision: 344957

URL: http://llvm.org/viewvc/llvm-project?rev=344957&view=rev
Log:
Give Multiversion-inline functions linkonce linkage

Since multiversion variant functions can be inline, in C they become
available-externally linkage.  This ends up causing the variants to not
be emitted, and not available to the linker.

The solution is to make sure that multiversion functions are always
emitted by marking them linkonce.

Change-Id: I897aa37c7cbba0c1eb2c57ee881d5000a2113b75

Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/test/CodeGen/attr-target-mv.c

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=344957&r1=344956&r2=344957&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Mon Oct 22 14:20:45 2018
@@ -3669,6 +3669,10 @@ llvm::GlobalValue::LinkageTypes CodeGenM
   return llvm::GlobalVariable::WeakAnyLinkage;
   }

+  if (const auto *FD = D->getAsFunction())
+if (FD->isMultiVersion() && Linkage == GVA_AvailableExternally)
+  return llvm::GlobalVariable::LinkOnceAnyLinkage;
+
   // We are guaranteed to have a strong definition somewhere else,
   // so we can use available_externally linkage.
   if (Linkage == GVA_AvailableExternally)

Modified: cfe/trunk/test/CodeGen/attr-target-mv.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/attr-target-mv.c?rev=344957&r1=344956&r2=344957&view=diff
==
--- cfe/trunk/test/CodeGen/attr-target-mv.c (original)
+++ cfe/trunk/test/CodeGen/attr-target-mv.c Mon Oct 22 14:20:45 2018
@@ -88,19 +88,19 @@ void bar4() {

 // CHECK: declare i32 @foo.arch_sandybridge()

-// CHECK: define available_externally i32 @foo_inline.sse4.2()
+// CHECK: define linkonce i32 @foo_inline.sse4.2()
 // CHECK: ret i3

RE: r344957 - Give Multiversion-inline functions linkonce linkage

[Keane, Erich via cfe-commits]

GCC actually doesn’t support function multiversioning in C mode, so this fix is 
part of our extension to support C with multiversioning.  I perhaps wonder if 
this is part of the reason GCC only supports it in C++ mode...

From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Monday, October 29, 2018 11:25 AM
To: Keane, Erich ; Eric Christopher 
Cc: cfe-commits@lists.llvm.org
Subject: Re: r344957 - Give Multiversion-inline functions linkonce linkage

Does this match GCC's approach here?

(I ask this sort of as throwaway/conversation starter - because the 
linkage/behavior around multiversion functions and their inlining is full of 
sharp corners/risks of code moving out of the areas appropriately restricted 
based on the cpu features)
On Mon, Oct 22, 2018 at 2:22 PM Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Mon Oct 22 14:20:45 2018
New Revision: 344957

URL: http://llvm.org/viewvc/llvm-project?rev=344957&view=rev
Log:
Give Multiversion-inline functions linkonce linkage

Since multiversion variant functions can be inline, in C they become
available-externally linkage.  This ends up causing the variants to not
be emitted, and not available to the linker.

The solution is to make sure that multiversion functions are always
emitted by marking them linkonce.

Change-Id: I897aa37c7cbba0c1eb2c57ee881d5000a2113b75

Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/test/CodeGen/attr-target-mv.c

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=344957&r1=344956&r2=344957&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Mon Oct 22 14:20:45 2018
@@ -3669,6 +3669,10 @@ llvm::GlobalValue::LinkageTypes CodeGenM
   return llvm::GlobalVariable::WeakAnyLinkage;
   }

+  if (const auto *FD = D->getAsFunction())
+if (FD->isMultiVersion() && Linkage == GVA_AvailableExternally)
+  return llvm::GlobalVariable::LinkOnceAnyLinkage;
+
   // We are guaranteed to have a strong definition somewhere else,
   // so we can use available_externally linkage.
   if (Linkage == GVA_AvailableExternally)

Modified: cfe/trunk/test/CodeGen/attr-target-mv.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/attr-target-mv.c?rev=344957&r1=344956&r2=344957&view=diff
==
--- cfe/trunk/test/CodeGen/attr-target-mv.c (original)
+++ cfe/trunk/test/CodeGen/attr-target-mv.c Mon Oct 22 14:20:45 2018
@@ -88,19 +88,19 @@ void bar4() {

 // CHECK: declare i32 @foo.arch_sandybridge()

-// CHECK: define available_externally i32 @foo_inline.sse4.2()
+// CHECK: define linkonce i32 @foo_inline.sse4.2()
 // CHECK: ret i32 0

 // CHECK: declare i32 @foo_inline.arch_sandybridge()
 //
-// CHECK: define available_externally i32 @foo_inline.arch_ivybridge()
+// CHECK: define linkonce i32 @foo_inline.arch_ivybridge()
 // CHECK: ret i32 1
-// CHECK: define available_externally i32 @foo_inline()
+// CHECK: define linkonce i32 @foo_inline()
 // CHECK: ret i32 2

-// CHECK: define available_externally void @foo_decls()
-// CHECK: define available_externally void @foo_decls.sse4.2()
+// CHECK: define linkonce void @foo_decls()
+// CHECK: define linkonce void @foo_decls.sse4.2()

-// CHECK: define available_externally void @foo_multi.avx_sse4.2()
-// CHECK: define available_externally void @foo_multi.fma4_sse4.2()
-// CHECK: define available_externally void 
@foo_multi.arch_ivybridge_fma4_sse4.2()
+// CHECK: define linkonce void @foo_multi.avx_sse4.2()
+// CHECK: define linkonce void @foo_multi.fma4_sse4.2()
+// CHECK: define linkonce void @foo_multi.arch_ivybridge_fma4_sse4.2()


___
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: r339387 - Revert -r339382, which apparently breaks the Windows build.

[Keane, Erich via cfe-commits]

AH! Thanks!  I was just messing around on Godbolt to try to figure out what was 
going on.

From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Thursday, August 9, 2018 2:16 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r339387 - Revert -r339382, which apparently breaks the Windows 
build.

On Thu, 9 Aug 2018 at 14:14, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Thu Aug  9 14:13:46 2018
New Revision: 339387

URL: http://llvm.org/viewvc/llvm-project?rev=339387&view=rev
Log:
Revert -r339382, which apparently breaks the Windows build.

Modified:
cfe/trunk/include/clang/Sema/ParsedAttr.h

Modified: cfe/trunk/include/clang/Sema/ParsedAttr.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/ParsedAttr.h?rev=339387&r1=339386&r2=339387&view=diff
==
--- cfe/trunk/include/clang/Sema/ParsedAttr.h (original)
+++ cfe/trunk/include/clang/Sema/ParsedAttr.h Thu Aug  9 14:13:46 2018
@@ -118,7 +118,9 @@ class ParsedAttr final
 : private llvm::TrailingObjects<
   ParsedAttr, ArgsUnion, detail::AvailabilityData,
   detail::TypeTagForDatatypeData, ParsedType, detail::PropertyData> {
-  friend class TrailingObjects;
+  friend class llvm::TrailingObjects<
+  ParsedAttr, ArgsUnion, detail::AvailabilityData,
+  detail::TypeTagForDatatypeData, ParsedType, detail::PropertyData>;

You need to use "friend TrailingObjects;" here, not "friend class 
TrailingObjects;", to avoid breaking MSVC (which doesn't implement 
injected-class-names quite according to spec).

   size_t numTrailingObjects(OverloadToken) const { return NumArgs; }
   size_t numTrailingObjects(OverloadToken) const {


___
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: r337005 - [NFC] Rename clang::AttributeList to clang::ParsedAttr

[Keane, Erich via cfe-commits]

Good grief... I even made a note to remove this 'TODO' on my whiteboard!

I discussed the name with AaronBallman who preferred ParsedAttr over 
ParsedAttribute (since ParsedAttributes is also a type).

Fixed in r339039.

-Original Message-
From: meiners...@googlemail.com [mailto:meiners...@googlemail.com] On Behalf Of 
Michael Kruse
Sent: Monday, August 6, 2018 11:00 AM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r337005 - [NFC] Rename clang::AttributeList to clang::ParsedAttr

2018-07-13 10:07 GMT-05:00 Erich Keane via cfe-commits
:
> -class AttributeList { // TODO: This should really be called ParsedAttribute
> +class ParsedAttr { // TODO: This should really be called ParsedAttribute

Should this TODO be removed/ParsedAttr really be called ParsedAttribute?

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

RE: r338630 - [AST][1/4] Move the bit-fields from TagDecl, EnumDecl and RecordDecl into DeclContext

[Keane, Erich via cfe-commits]

Hi, sorry for the delayed response, I only just got back into the office.  I've 
added the author of the patch to this email chain.

-Original Message-
From: Abramo Bagnara [mailto:abramo.bagn...@bugseng.com] 
Sent: Sunday, August 5, 2018 5:03 AM
To: Keane, Erich ; cfe-commits@lists.llvm.org
Subject: Re: r338630 - [AST][1/4] Move the bit-fields from TagDecl, EnumDecl 
and RecordDecl into DeclContext

Il 01/08/2018 22:48, Erich Keane via cfe-commits ha scritto:
> Author: erichkeane
> Date: Wed Aug  1 13:48:16 2018
> New Revision: 338630
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=338630&view=rev
> Log:
> [AST][1/4] Move the bit-fields from TagDecl, EnumDecl and RecordDecl 
> into DeclContext
> 

This commit break the build with gcc version 7.3-win32 20180312 (GCC).

I've tracked the cause to the presence of:

enum { ObjCMethodFamilyBitWidth = 4 };

between two bitfields declarations.

Moving it to begin of class fix the build. This is spotted only because the 
static_assert, so it is well possible there are other occurrences of the same 
problem.

The following typescript show the issue:

abramo@igor:/tmp$ cat bad.cc
#include 
enum { NumDeclContextBits = 13 };
class ObjCMethodDeclBitfields {
  uint64_t : NumDeclContextBits;
  enum { ObjCMethodFamilyBitWidth = 4 };
  mutable uint64_t Family : ObjCMethodFamilyBitWidth;
  uint64_t IsInstance : 1;
  uint64_t IsVariadic : 1;
  uint64_t IsPropertyAccessor : 1;
  uint64_t IsDefined : 1;
  uint64_t IsRedeclaration : 1;
  mutable uint64_t HasRedeclaration : 1;
  uint64_t DeclImplementation : 2;
  uint64_t objcDeclQualifier : 7;
  uint64_t RelatedResultType : 1;
  uint64_t SelLocsKind : 2;
  uint64_t IsOverriding : 1;
  uint64_t HasSkippedBody : 1;
};
static_assert(sizeof(ObjCMethodDeclBitfields) <= 8,
  "ObjCMethodDeclBitfields is larger than 8 bytes!"); 
abramo@igor:/tmp$ x86_64-w64-mingw32-g++ -c bad.cc
bad.cc:20:1: error: static assertion failed: ObjCMethodDeclBitfields is larger 
than 8 bytes!
 static_assert(sizeof(ObjCMethodDeclBitfields) <= 8,  ^
1|abramo@igor:/tmp$ cat good.cc
#include 
enum { NumDeclContextBits = 13 };
class ObjCMethodDeclBitfields {
  enum { ObjCMethodFamilyBitWidth = 4 };
  uint64_t : NumDeclContextBits;
  mutable uint64_t Family : ObjCMethodFamilyBitWidth;
  uint64_t IsInstance : 1;
  uint64_t IsVariadic : 1;
  uint64_t IsPropertyAccessor : 1;
  uint64_t IsDefined : 1;
  uint64_t IsRedeclaration : 1;
  mutable uint64_t HasRedeclaration : 1;
  uint64_t DeclImplementation : 2;
  uint64_t objcDeclQualifier : 7;
  uint64_t RelatedResultType : 1;
  uint64_t SelLocsKind : 2;
  uint64_t IsOverriding : 1;
  uint64_t HasSkippedBody : 1;
};
static_assert(sizeof(ObjCMethodDeclBitfields) <= 8,
  "ObjCMethodDeclBitfields is larger than 8 bytes!"); 
abramo@igor:/tmp$ x86_64-w64-mingw32-g++ -c good.cc abramo@igor:/tmp$


--
Abramo Bagnara

BUGSENG srl - http://bugseng.com
mailto:abramo.bagn...@bugseng.com
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: [PATCH] D48100: Append new attributes to the end of an AttributeList.

[Keane, Erich via cfe-commits]

I suspect you're right about that.  Hopefully it would be easy enough.

Unfortunately, SourceLocation doesn't have an operator<, which kind of stinks.  
I suspect that it'll be a non-trivial thing to do, since it is actually 
possible to have attributes added with empty source-locations in some case, but 
hopefully whoever is brave enough to tackle this can figure it out.

-Original Message-
From: Aaron Ballman [mailto:aaron.ball...@gmail.com] 
Sent: Friday, August 3, 2018 7:35 AM
To: Keane, Erich 
Cc: reviews+d48100+public+bdf72fdc7f8c9...@reviews.llvm.org; Michael Kruse 
; Hal Finkel ; Tyler Nowicki 
; Alexey Bataev ; John McCall 
; George Burgess IV ; Nick 
Lewycky ; Nick Lewycky ; d...@google.com; 
sammcc...@google.com; david.gr...@arm.com; llvm-commits 
; jrt...@jrtc27.com; Richard Smith 
; Eric Christopher ; 
zhaos...@codeaurora.org; Simon Atanasyan ; cfe-commits 
; junb...@codeaurora.org; florian.h...@arm.com
Subject: Re: [PATCH] D48100: Append new attributes to the end of an 
AttributeList.

On Fri, Aug 3, 2018 at 10:09 AM, Keane, Erich  wrote:
>> As a possible idea (that may or may not work): the Attr object itself has a 
>> SourceRange on it; perhaps a solution is to keep the > attributes in sorted 
>> order within DeclBase::addAttr() based on the SourceRanges passed in?
>
> Interestingly, I think I came up with that idea in a comment on D50214.  I 
> think that we should either keep the attributes sorted, or make the iterator 
> give a sorted version.

Oh, hey, so you did! I think keeping them in a sorted order is preferable to 
having the iterator return a sorted version; I believe we iterate attribute 
more often than we add them because things like
hasAttr<>() and getAttr<>() both rely on iterating through the attributes.

~Aaron

>
>
>
> -Original Message-
> From: Aaron Ballman [mailto:aaron.ball...@gmail.com]
> Sent: Friday, August 3, 2018 7:02 AM
> To: reviews+d48100+public+bdf72fdc7f8c9...@reviews.llvm.org
> Cc: Michael Kruse ; Hal Finkel ; 
> Tyler Nowicki ; Alexey Bataev 
> ; John McCall ; George 
> Burgess IV ; Nick Lewycky 
> ; Nick Lewycky ; d...@google.com; 
> sammcc...@google.com; david.gr...@arm.com; llvm-commits 
> ; jrt...@jrtc27.com; Richard Smith 
> ; Keane, Erich ; Eric 
> Christopher ; zhaos...@codeaurora.org; Simon 
> Atanasyan ; cfe-commits 
> ; junb...@codeaurora.org; 
> florian.h...@arm.com
> Subject: Re: [PATCH] D48100: Append new attributes to the end of an 
> AttributeList.
>
> On Fri, Aug 3, 2018 at 8:53 AM, Erich Keane via Phabricator 
>  wrote:
>> erichkeane added a comment.
>>
>> In https://reviews.llvm.org/D48100#1186654, @Meinersbur wrote:
>>
>>> I have two approaches to tackle the wrong marker order: 
>>> https://reviews.llvm.org/D50215 and https://reviews.llvm.org/D50216. IMHO 
>>> both are too invasive to be justified for the small issue.
>>
>>
>> I think you're right here.  I despise https://reviews.llvm.org/D50215, and 
>> only mostly hate https://reviews.llvm.org/D50216.  I think I'd prefer 
>> leaving this as a "FIXME" somewhere.
>
> Oye, I'm in agreement that this should be fixed but that neither of these 
> approaches leaves me feeling warm and fuzzy.
>
> As a possible idea (that may or may not work): the Attr object itself has a 
> SourceRange on it; perhaps a solution is to keep the attributes in sorted 
> order within DeclBase::addAttr() based on the SourceRanges passed in?
>
> ~Aaron
>
>>
>>
>> Repository:
>>   rL LLVM
>>
>> https://reviews.llvm.org/D48100
>>
>>
>>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: [PATCH] D48100: Append new attributes to the end of an AttributeList.

[Keane, Erich via cfe-commits]

> As a possible idea (that may or may not work): the Attr object itself has a 
> SourceRange on it; perhaps a solution is to keep the > attributes in sorted 
> order within DeclBase::addAttr() based on the SourceRanges passed in?

Interestingly, I think I came up with that idea in a comment on D50214.  I 
think that we should either keep the attributes sorted, or make the iterator 
give a sorted version.  



-Original Message-
From: Aaron Ballman [mailto:aaron.ball...@gmail.com] 
Sent: Friday, August 3, 2018 7:02 AM
To: reviews+d48100+public+bdf72fdc7f8c9...@reviews.llvm.org
Cc: Michael Kruse ; Hal Finkel ; Tyler 
Nowicki ; Alexey Bataev ; John McCall 
; George Burgess IV ; Nick 
Lewycky ; Nick Lewycky ; d...@google.com; 
sammcc...@google.com; david.gr...@arm.com; llvm-commits 
; jrt...@jrtc27.com; Richard Smith 
; Keane, Erich ; Eric Christopher 
; zhaos...@codeaurora.org; Simon Atanasyan 
; cfe-commits ; 
junb...@codeaurora.org; florian.h...@arm.com
Subject: Re: [PATCH] D48100: Append new attributes to the end of an 
AttributeList.

On Fri, Aug 3, 2018 at 8:53 AM, Erich Keane via Phabricator 
 wrote:
> erichkeane added a comment.
>
> In https://reviews.llvm.org/D48100#1186654, @Meinersbur wrote:
>
>> I have two approaches to tackle the wrong marker order: 
>> https://reviews.llvm.org/D50215 and https://reviews.llvm.org/D50216. IMHO 
>> both are too invasive to be justified for the small issue.
>
>
> I think you're right here.  I despise https://reviews.llvm.org/D50215, and 
> only mostly hate https://reviews.llvm.org/D50216.  I think I'd prefer leaving 
> this as a "FIXME" somewhere.

Oye, I'm in agreement that this should be fixed but that neither of these 
approaches leaves me feeling warm and fuzzy.

As a possible idea (that may or may not work): the Attr object itself has a 
SourceRange on it; perhaps a solution is to keep the attributes in sorted order 
within DeclBase::addAttr() based on the SourceRanges passed in?

~Aaron

>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D48100
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: r338884 - [NFC] Silence unused variable warning in Attr.td/AttrParsedAttrImpl.inc

[Keane, Erich via cfe-commits]

Thanks for the heads up!  I repro’ed both in Godbolt, and saw that clang 
suggests wrapping in a void-cast, so I’ve done  that.

From: Nico Weber [mailto:tha...@chromium.org]
Sent: Friday, August 3, 2018 6:16 AM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r338884 - [NFC] Silence unused variable warning in 
Attr.td/AttrParsedAttrImpl.inc

This causes a warning:

gen/clang/include/clang/Sema/AttrParsedAttrImpl.inc:1050:12: warning: 
expression result unused [-Wunused-value]
return S, false;
   ^

On Fri, Aug 3, 2018 at 9:01 AM Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Fri Aug  3 06:01:32 2018
New Revision: 338884

URL: http://llvm.org/viewvc/llvm-project?rev=338884&view=rev
Log:
[NFC] Silence unused variable warning in Attr.td/AttrParsedAttrImpl.inc

Modified:
cfe/trunk/include/clang/Basic/Attr.td

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=338884&r1=338883&r2=338884&view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Fri Aug  3 06:01:32 2018
@@ -145,7 +145,7 @@ def HasFunctionProto : SubsetSubject;

 // A single argument to an attribute


___
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: r338884 - [NFC] Silence unused variable warning in Attr.td/AttrParsedAttrImpl.inc

[Keane, Erich via cfe-commits]

Hmm… I thought this was a pretty clever one.  Again, that didn’t show up in my 
older GCC :/

Any thoughts on how I can silence this AND the other warning?



From: Nico Weber [mailto:tha...@chromium.org]
Sent: Friday, August 3, 2018 6:16 AM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r338884 - [NFC] Silence unused variable warning in 
Attr.td/AttrParsedAttrImpl.inc

This causes a warning:

gen/clang/include/clang/Sema/AttrParsedAttrImpl.inc:1050:12: warning: 
expression result unused [-Wunused-value]
return S, false;
   ^

On Fri, Aug 3, 2018 at 9:01 AM Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Fri Aug  3 06:01:32 2018
New Revision: 338884

URL: http://llvm.org/viewvc/llvm-project?rev=338884&view=rev
Log:
[NFC] Silence unused variable warning in Attr.td/AttrParsedAttrImpl.inc

Modified:
cfe/trunk/include/clang/Basic/Attr.td

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=338884&r1=338883&r2=338884&view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Fri Aug  3 06:01:32 2018
@@ -145,7 +145,7 @@ def HasFunctionProto : SubsetSubject;

 // A single argument to an attribute


___
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: r338641 - [AST][4/4] Move the bit-fields from ObjCMethodDecl and ObjCContainerDecl into DeclContext

[Keane, Erich via cfe-commits]

Thanks Vlad for the removal!  This warning didn’t show up in my environment 
when committing this, I really need get a newer GCC :/

I suspect the patch author should extract that assert to the bitfield area with 
the rest.


From: David Jones [mailto:d...@google.com]
Sent: Wednesday, August 1, 2018 3:57 PM
To: Keane, Erich 
Cc: cfe-commits@lists.llvm.org
Subject: Re: r338641 - [AST][4/4] Move the bit-fields from ObjCMethodDecl and 
ObjCContainerDecl into DeclContext

(And it was fixed in r338648)

On Wed, Aug 1, 2018 at 3:24 PM David Jones 
mailto:d...@google.com>> wrote:
FYI, this breaks clang:

.../llvm/tools/clang/lib/AST/DeclObjC.cpp:793:7: error: static_assert 
expression is not an integral constant expression
  static_cast(ObjCMethodDeclBits.ObjCMethodFamilyBitWidth) ==
  ^
.../llvm/tools/clang/lib/AST/DeclObjC.cpp:793:29: note: implicit use of 'this' 
pointer is only allowed within the evaluation of a call to a 'constexpr' member 
function
  static_cast(ObjCMethodDeclBits.ObjCMethodFamilyBitWidth) ==
^
1 error generated.


On Wed, Aug 1, 2018 at 2:31 PM Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Wed Aug  1 14:31:08 2018
New Revision: 338641

URL: http://llvm.org/viewvc/llvm-project?rev=338641&view=rev
Log:
[AST][4/4] Move the bit-fields from ObjCMethodDecl and ObjCContainerDecl into 
DeclContext

This patch follows https://reviews.llvm.org/D49729,
https://reviews.llvm.org/D49732 and
https://reviews.llvm.org/D49733.

Move the bits from ObjCMethodDecl and ObjCContainerDecl
into DeclContext.

Differential Revision: https://reviews.llvm.org/D49734

Patch By: bricci

Modified:
cfe/trunk/include/clang/AST/DeclObjC.h
cfe/trunk/lib/AST/DeclObjC.cpp
cfe/trunk/lib/Sema/SemaDeclObjC.cpp
cfe/trunk/lib/Serialization/ASTReaderDecl.cpp
cfe/trunk/lib/Serialization/ASTWriterDecl.cpp

Modified: cfe/trunk/include/clang/AST/DeclObjC.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclObjC.h?rev=338641&r1=338640&r2=338641&view=diff
==
--- cfe/trunk/include/clang/AST/DeclObjC.h (original)
+++ cfe/trunk/include/clang/AST/DeclObjC.h Wed Aug  1 14:31:08 2018
@@ -141,58 +141,10 @@ public:
   enum ImplementationControl { None, Required, Optional };

 private:
-  // The conventional meaning of this method; an ObjCMethodFamily.
-  // This is not serialized; instead, it is computed on demand and
-  // cached.
-  mutable unsigned Family : ObjCMethodFamilyBitWidth;
-
-  /// instance (true) or class (false) method.
-  unsigned IsInstance : 1;
-  unsigned IsVariadic : 1;
-
-  /// True if this method is the getter or setter for an explicit property.
-  unsigned IsPropertyAccessor : 1;
-
-  // Method has a definition.
-  unsigned IsDefined : 1;
-
-  /// Method redeclaration in the same interface.
-  unsigned IsRedeclaration : 1;
-
-  /// Is redeclared in the same interface.
-  mutable unsigned HasRedeclaration : 1;
-
-  // NOTE: VC++ treats enums as signed, avoid using ImplementationControl enum
-  /// \@required/\@optional
-  unsigned DeclImplementation : 2;
-
-  // NOTE: VC++ treats enums as signed, avoid using the ObjCDeclQualifier enum
-  /// in, inout, etc.
-  unsigned objcDeclQualifier : 7;
-
-  /// Indicates whether this method has a related result type.
-  unsigned RelatedResultType : 1;
-
-  /// Whether the locations of the selector identifiers are in a
-  /// "standard" position, a enum SelectorLocationsKind.
-  unsigned SelLocsKind : 2;
-
-  /// Whether this method overrides any other in the class hierarchy.
-  ///
-  /// A method is said to override any method in the class's
-  /// base classes, its protocols, or its categories' protocols, that has
-  /// the same selector and is of the same kind (class or instance).
-  /// A method in an implementation is not considered as overriding the same
-  /// method in the interface or its categories.
-  unsigned IsOverriding : 1;
-
-  /// Indicates if the method was a definition but its body was skipped.
-  unsigned HasSkippedBody : 1;
-
-  // Return type of this method.
+  /// Return type of this method.
   QualType MethodDeclType;

-  // Type source information for the return type.
+  /// Type source information for the return type.
   TypeSourceInfo *ReturnTInfo;

   /// Array of ParmVarDecls for the formal parameters of this method
@@ -203,7 +155,7 @@ private:
   /// List of attributes for this method declaration.
   SourceLocation DeclEndLoc; // the location of the ';' or '{'.

-  // The following are only used for method definitions, null otherwise.
+  /// The following are only used for method definitions, null otherwise.
   LazyDeclStmtPtr Body;

   /// SelfDecl - Decl for the implicit self parameter. This is lazily
@@ -220,21 +172,14 @@ private:
  bool isVariadic = false, bool i

RE: r336380 - Add PCH tests for R336379

[Keane, Erich via cfe-commits]

Ugg… I did not.  Seemingly my svn-property cleaning script isn’t working for 
some reason.  If it hasn’t been done yet, I’ll clear the properties now.

From: Nico Weber [mailto:tha...@chromium.org]
Sent: Wednesday, July 18, 2018 5:21 AM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r336380 - Add PCH tests for R336379

I think normally we don't set all these svn properties. Did you set them 
intentionally?

On Thu, Jul 5, 2018 at 1:28 PM Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Thu Jul  5 10:23:15 2018
New Revision: 336380

URL: http://llvm.org/viewvc/llvm-project?rev=336380&view=rev
Log:
Add PCH tests for R336379

I seemingly forgot the tests for this commit, added here.

Added:
cfe/trunk/test/PCH/Inputs/pch-through-use0.cpp   (with props)
cfe/trunk/test/PCH/Inputs/pch-through-use1.cpp   (with props)
cfe/trunk/test/PCH/Inputs/pch-through-use2.cpp   (with props)
cfe/trunk/test/PCH/Inputs/pch-through-use3a.cpp   (with props)
cfe/trunk/test/PCH/Inputs/pch-through-use3b.cpp   (with props)
cfe/trunk/test/PCH/Inputs/pch-through1.h   (with props)
cfe/trunk/test/PCH/Inputs/pch-through2.h   (with props)
cfe/trunk/test/PCH/Inputs/pch-through3.h   (with props)
cfe/trunk/test/PCH/Inputs/pch-through4.h   (with props)
cfe/trunk/test/PCH/pch-through1.cpp   (with props)
cfe/trunk/test/PCH/pch-through2.cpp   (with props)
cfe/trunk/test/PCH/pch-through3a.cpp   (with props)
cfe/trunk/test/PCH/pch-through3b.cpp   (with props)

Added: cfe/trunk/test/PCH/Inputs/pch-through-use0.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/PCH/Inputs/pch-through-use0.cpp?rev=336380&view=auto
==
--- cfe/trunk/test/PCH/Inputs/pch-through-use0.cpp (added)
+++ cfe/trunk/test/PCH/Inputs/pch-through-use0.cpp Thu Jul  5 10:23:15 2018
@@ -0,0 +1,2 @@
+void foo() {
+}

Propchange: cfe/trunk/test/PCH/Inputs/pch-through-use0.cpp
--
svn:eol-style = native

Propchange: cfe/trunk/test/PCH/Inputs/pch-through-use0.cpp
--
svn:keywords = Author Date Id Rev URL

Propchange: cfe/trunk/test/PCH/Inputs/pch-through-use0.cpp
--
svn:mime-type = text/plain

Added: cfe/trunk/test/PCH/Inputs/pch-through-use1.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/PCH/Inputs/pch-through-use1.cpp?rev=336380&view=auto
==
--- cfe/trunk/test/PCH/Inputs/pch-through-use1.cpp (added)
+++ cfe/trunk/test/PCH/Inputs/pch-through-use1.cpp Thu Jul  5 10:23:15 2018
@@ -0,0 +1,5 @@
+#include "Inputs/pch-through1.h"
+#include "Inputs/pch-through3.h"
+void foo() {
+  through2(0);
+}

Propchange: cfe/trunk/test/PCH/Inputs/pch-through-use1.cpp
--
svn:eol-style = native

Propchange: cfe/trunk/test/PCH/Inputs/pch-through-use1.cpp
--
svn:keywords = Author Date Id Rev URL

Propchange: cfe/trunk/test/PCH/Inputs/pch-through-use1.cpp
--
svn:mime-type = text/plain

Added: cfe/trunk/test/PCH/Inputs/pch-through-use2.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/PCH/Inputs/pch-through-use2.cpp?rev=336380&view=auto
==
--- cfe/trunk/test/PCH/Inputs/pch-through-use2.cpp (added)
+++ cfe/trunk/test/PCH/Inputs/pch-through-use2.cpp Thu Jul  5 10:23:15 2018
@@ -0,0 +1,3 @@
+void foo() {
+  through4(0);
+}

Propchange: cfe/trunk/test/PCH/Inputs/pch-through-use2.cpp
--
svn:eol-style = native

Propchange: cfe/trunk/test/PCH/Inputs/pch-through-use2.cpp
--
svn:keywords = Author Date Id Rev URL

Propchange: cfe/trunk/test/PCH/Inputs/pch-through-use2.cpp
--
svn:mime-type = text/plain

Added: cfe/trunk/test/PCH/Inputs/pch-through-use3a.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/PCH/Inputs/pch-through-use3a.cpp?rev=336380&view=auto
==
--- cfe/trunk/test/PCH/Inputs/pch-through-use3a.cpp (added)
+++ cfe/trunk/test/PCH/Inputs/pch-through-use3a.cpp Thu Jul  5 10:23:15 2018
@@ -0,0 +1,2 @@
+#define AFOO 0
+#include "Inputs/pch-through1.h"

Propchange: cfe/trunk/test/PCH/Inputs/pch-through-use3a.cpp
--

RE: r336726 - [NFC] Switch CodeGenFunction to use value init instead of member init lists

[Keane, Erich via cfe-commits]

Sorry everyone, I didn't police my subversion directory correctly.  I noticed 
when I got the email that the 'commit' list was too large!  Reverted in 336727.

-Original Message-
From: Erich Keane via cfe-commits [mailto:cfe-commits@lists.llvm.org] 
Sent: Tuesday, July 10, 2018 1:47 PM
To: cfe-commits@lists.llvm.org
Subject: r336726 - [NFC] Switch CodeGenFunction to use value init instead of 
member init lists

Author: erichkeane
Date: Tue Jul 10 13:46:46 2018
New Revision: 336726

URL: http://llvm.org/viewvc/llvm-project?rev=336726&view=rev
Log:
[NFC] Switch CodeGenFunction to use value init instead of member init lists

The member init list for the sole constructor for CodeGenFunction
has gotten out of hand, so this patch moves the non-parameter-dependent
initializations into the member value inits.

Modified:
cfe/trunk/include/clang/AST/ASTContext.h
cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
cfe/trunk/include/clang/AST/Type.h
cfe/trunk/include/clang/AST/TypeLoc.h
cfe/trunk/include/clang/AST/TypeNodes.def
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/include/clang/Serialization/ASTBitCodes.h
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/AST/ASTStructuralEquivalence.cpp
cfe/trunk/lib/AST/ItaniumMangle.cpp
cfe/trunk/lib/AST/MicrosoftMangle.cpp
cfe/trunk/lib/AST/Type.cpp
cfe/trunk/lib/AST/TypePrinter.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/lib/Sema/SemaTemplate.cpp
cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp
cfe/trunk/lib/Sema/SemaType.cpp
cfe/trunk/lib/Sema/TreeTransform.h
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp
cfe/trunk/test/SemaCXX/vector.cpp
cfe/trunk/tools/libclang/CIndex.cpp

Modified: cfe/trunk/include/clang/AST/ASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=336726&r1=336725&r2=336726&view=diff
==
--- cfe/trunk/include/clang/AST/ASTContext.h (original)
+++ cfe/trunk/include/clang/AST/ASTContext.h Tue Jul 10 13:46:46 2018
@@ -168,6 +168,7 @@ class ASTContext : public RefCountedBase
   mutable llvm::FoldingSet
   DependentAddressSpaceTypes;
   mutable llvm::FoldingSet VectorTypes;
+  mutable llvm::FoldingSet DependentVectorTypes;
   mutable llvm::FoldingSet FunctionNoProtoTypes;
   mutable llvm::ContextualFoldingSet
 FunctionProtoTypes;
@@ -1321,6 +1322,11 @@ public:
   /// \pre \p VectorType must be a built-in type.
   QualType getVectorType(QualType VectorType, unsigned NumElts,
  VectorType::VectorKind VecKind) const;
+  /// Return the unique reference to the type for a dependently sized vector of
+  /// the specified element type.
+  QualType getDependentVectorType(QualType VectorType, Expr *SizeExpr,
+  SourceLocation AttrLoc,
+  VectorType::VectorKind VecKind) const;
 
   /// Return the unique reference to an extended vector type
   /// of the specified element type and size.

Modified: cfe/trunk/include/clang/AST/RecursiveASTVisitor.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/RecursiveASTVisitor.h?rev=336726&r1=336725&r2=336726&view=diff
==
--- cfe/trunk/include/clang/AST/RecursiveASTVisitor.h (original)
+++ cfe/trunk/include/clang/AST/RecursiveASTVisitor.h Tue Jul 10 13:46:46 2018
@@ -993,6 +993,12 @@ DEF_TRAVERSE_TYPE(DependentAddressSpaceT
   TRY_TO(TraverseType(T->getPointeeType()));
 })
 
+DEF_TRAVERSE_TYPE(DependentVectorType, {
+  if (T->getSizeExpr())
+TRY_TO(TraverseStmt(T->getSizeExpr()));
+  TRY_TO(TraverseType(T->getElementType()));
+})
+
 DEF_TRAVERSE_TYPE(DependentSizedExtVectorType, {
   if (T->getSizeExpr())
 TRY_TO(TraverseStmt(T->getSizeExpr()));
@@ -1221,6 +1227,12 @@ DEF_TRAVERSE_TYPELOC(VectorType, {
   TRY_TO(TraverseType(TL.getTypePtr()->getElementType()));
 })
 
+DEF_TRAVERSE_TYPELOC(DependentVectorType, {
+  if (TL.getTypePtr()->getSizeExpr())
+TRY_TO(TraverseStmt(TL.getTypePtr()->getSizeExpr()));
+  TRY_TO(TraverseType(TL.getTypePtr()->getElementType()));
+})
+
 // FIXME: size and attributes
 // FIXME: base VectorTypeLoc is unfinished
 DEF_TRAVERSE_TYPELOC(ExtVectorType, {

Modified: cfe/trunk/include/clang/AST/Type.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Type.h?rev=336726&r1=336725&r2=336726&view=diff
==
--- cfe/trunk/include/clang/AST/Type.h (original)
+++ cfe/trunk/include/clang/AST/Type.h Tue Jul 10 13:46:46 2018
@@ -1590,6 +1590,7 @@ protected:
 
   class VectorTypeBitfields {
 friend class VectorType;
+friend class DependentVectorType;
 
 unsigned : NumTypeBits;
 
@@ -3079,6 +3080,51 @@ public:
   }
 };
 

RE: r334650 - Implement constexpr __builtin_*_overflow

[Keane, Erich via cfe-commits]

Fixed in R336364.  Thank you very much for the heads up!

From: Evgenii Stepanov [mailto:eugeni.stepa...@gmail.com]
Sent: Tuesday, July 3, 2018 12:59 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r334650 - Implement constexpr __builtin_*_overflow

Hi,

with this change, the following compiles to "ret i32 undef":

int main(int argc, char **argv) {
  constexpr int x = 1;
  constexpr int y = 2;
  int z;

  __builtin_sadd_overflow(x, y, &z);
  return z;
}


On Wed, Jun 13, 2018 at 1:43 PM, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Wed Jun 13 13:43:27 2018
New Revision: 334650

URL: http://llvm.org/viewvc/llvm-project?rev=334650&view=rev
Log:
Implement constexpr __builtin_*_overflow

As requested here:https://bugs.llvm.org/show_bug.cgi?id=37633
permit the __builtin_*_overflow builtins in constexpr functions.

Differential Revision: https://reviews.llvm.org/D48040

Modified:
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/test/SemaCXX/builtins-overflow.cpp

Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=334650&r1=334649&r2=334650&view=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Wed Jun 13 13:43:27 2018
@@ -8155,6 +8155,124 @@ bool IntExprEvaluator::VisitBuiltinCallE
   case Builtin::BIomp_is_initial_device:
 // We can decide statically which value the runtime would return if called.
 return Success(Info.getLangOpts().OpenMPIsDevice ? 0 : 1, E);
+  case Builtin::BI__builtin_add_overflow:
+  case Builtin::BI__builtin_sub_overflow:
+  case Builtin::BI__builtin_mul_overflow:
+  case Builtin::BI__builtin_sadd_overflow:
+  case Builtin::BI__builtin_uadd_overflow:
+  case Builtin::BI__builtin_uaddl_overflow:
+  case Builtin::BI__builtin_uaddll_overflow:
+  case Builtin::BI__builtin_usub_overflow:
+  case Builtin::BI__builtin_usubl_overflow:
+  case Builtin::BI__builtin_usubll_overflow:
+  case Builtin::BI__builtin_umul_overflow:
+  case Builtin::BI__builtin_umull_overflow:
+  case Builtin::BI__builtin_umulll_overflow:
+  case Builtin::BI__builtin_saddl_overflow:
+  case Builtin::BI__builtin_saddll_overflow:
+  case Builtin::BI__builtin_ssub_overflow:
+  case Builtin::BI__builtin_ssubl_overflow:
+  case Builtin::BI__builtin_ssubll_overflow:
+  case Builtin::BI__builtin_smul_overflow:
+  case Builtin::BI__builtin_smull_overflow:
+  case Builtin::BI__builtin_smulll_overflow: {
+LValue ResultLValue;
+APSInt LHS, RHS;
+
+QualType ResultType = E->getArg(2)->getType()->getPointeeType();
+if (!EvaluateInteger(E->getArg(0), LHS, Info) ||
+!EvaluateInteger(E->getArg(1), RHS, Info) ||
+!EvaluatePointer(E->getArg(2), ResultLValue, Info))
+  return false;
+
+APSInt Result;
+bool DidOverflow = false;
+
+// If the types don't have to match, enlarge all 3 to the largest of them.
+if (BuiltinOp == Builtin::BI__builtin_add_overflow ||
+BuiltinOp == Builtin::BI__builtin_sub_overflow ||
+BuiltinOp == Builtin::BI__builtin_mul_overflow) {
+  bool IsSigned = LHS.isSigned() || RHS.isSigned() ||
+  ResultType->isSignedIntegerOrEnumerationType();
+  bool AllSigned = LHS.isSigned() && RHS.isSigned() &&
+  ResultType->isSignedIntegerOrEnumerationType();
+  uint64_t LHSSize = LHS.getBitWidth();
+  uint64_t RHSSize = RHS.getBitWidth();
+  uint64_t ResultSize = Info.Ctx.getTypeSize(ResultType);
+  uint64_t MaxBits = std::max(std::max(LHSSize, RHSSize), ResultSize);
+
+  // Add an additional bit if the signedness isn't uniformly agreed to. We
+  // could do this ONLY if there is a signed and an unsigned that both have
+  // MaxBits, but the code to check that is pretty nasty.  The issue will 
be
+  // caught in the shrink-to-result later anyway.
+  if (IsSigned && !AllSigned)
+++MaxBits;
+
+  LHS = APSInt(IsSigned ? LHS.sextOrSelf(MaxBits) : 
LHS.zextOrSelf(MaxBits),
+   !IsSigned);
+  RHS = APSInt(IsSigned ? RHS.sextOrSelf(MaxBits) : 
RHS.zextOrSelf(MaxBits),
+   !IsSigned);
+  Result = APSInt(MaxBits, !IsSigned);
+}
+
+// Find largest int.
+switch (BuiltinOp) {
+default:
+  llvm_unreachable("Invalid value for BuiltinOp");
+case Builtin::BI__builtin_add_overflow:
+case Builtin::BI__builtin_sadd_overflow:
+case Builtin::BI__builtin_saddl_overflow:
+case Builtin::BI__builtin_saddll_overflow:
+case Builtin::BI__builtin_uadd_overflow:
+case Builtin::BI__builtin_uaddl_overflow:
+case Builtin::BI__builtin_uaddll_overflow:
+  Result = LHS.isSigned() ? LHS.sadd_ov(RHS, DidOverflow)
+  : LHS.uadd_ov(RHS, DidOverflow);
+  break;
+case Builtin::BI__builtin_sub_overflow:
+case Builtin::BI__built

RE: r336225 - Fix allocation of Nullability attribute.

[Keane, Erich via cfe-commits]

Unfortunately I'm not sure of a good way to validate this.  The only way I was 
able to even discover this was with manual instrumentation of D48788.  There is 
a future opportunity to better instrument the source to find these things in 
the future that'll catch more issues like this one however.

-Original Message-
From: aaron.ball...@gmail.com [mailto:aaron.ball...@gmail.com] On Behalf Of 
Aaron Ballman
Sent: Tuesday, July 3, 2018 1:43 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r336225 - Fix allocation of Nullability attribute.

On Tue, Jul 3, 2018 at 4:30 PM, Erich Keane via cfe-commits 
 wrote:
> Author: erichkeane
> Date: Tue Jul  3 13:30:34 2018
> New Revision: 336225
>
> URL: http://llvm.org/viewvc/llvm-project?rev=336225&view=rev
> Log:
> Fix allocation of Nullability attribute.
>
> Existing code always allocates for on the declarator's attribute pool, 
> but sometimes adds it to the declspec.  This patch ensures that the 
> correct pool is used.
>
>
> Discovered while testing: https://reviews.llvm.org/D48788

Can you devise a testcase for this change, or is that hard to get the original 
behavior to fail in a consistent way?

~Aaron

>
> Modified:
> cfe/trunk/lib/Parse/ParseObjc.cpp
>
> Modified: cfe/trunk/lib/Parse/ParseObjc.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseObjc.cpp?
> rev=336225&r1=336224&r2=336225&view=diff
> ==
> 
> --- cfe/trunk/lib/Parse/ParseObjc.cpp (original)
> +++ cfe/trunk/lib/Parse/ParseObjc.cpp Tue Jul  3 13:30:34 2018
> @@ -381,25 +381,23 @@ static void addContextSensitiveTypeNulla
> SourceLocation nullabilityLoc,
> bool &addedToDeclSpec) {
>// Create the attribute.
> -  auto getNullabilityAttr = [&]() -> AttributeList * {
> -return D.getAttributePool().create(
> - P.getNullabilityKeyword(nullability),
> - SourceRange(nullabilityLoc),
> - nullptr, SourceLocation(),
> - nullptr, 0,
> - AttributeList::AS_ContextSensitiveKeyword);
> +  auto getNullabilityAttr = [&](AttributePool &Pool) -> AttributeList * {
> +return Pool.create(P.getNullabilityKeyword(nullability),
> +   SourceRange(nullabilityLoc), nullptr, 
> SourceLocation(),
> +   nullptr, 0, 
> + AttributeList::AS_ContextSensitiveKeyword);
>};
>
>if (D.getNumTypeObjects() > 0) {
>  // Add the attribute to the declarator chunk nearest the declarator.
> -auto nullabilityAttr = getNullabilityAttr();
> +auto nullabilityAttr = getNullabilityAttr(D.getAttributePool());
>  DeclaratorChunk &chunk = D.getTypeObject(0);
>  nullabilityAttr->setNext(chunk.getAttrListRef());
>  chunk.getAttrListRef() = nullabilityAttr;
>} else if (!addedToDeclSpec) {
>  // Otherwise, just put it on the declaration specifiers (if one
>  // isn't there already).
> -D.getMutableDeclSpec().addAttributes(getNullabilityAttr());
> +D.getMutableDeclSpec().addAttributes(
> +getNullabilityAttr(D.getDeclSpec().getAttributePool()));
>  addedToDeclSpec = true;
>}
>  }
>
>
> ___
> 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: r334650 - Implement constexpr __builtin_*_overflow

[Keane, Erich via cfe-commits]

Yikes!  Thanks for the heads up!  I’ll start looking into this.

Thanks for letting me know.

From: Evgenii Stepanov [mailto:eugeni.stepa...@gmail.com]
Sent: Tuesday, July 3, 2018 12:59 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r334650 - Implement constexpr __builtin_*_overflow

Hi,

with this change, the following compiles to "ret i32 undef":

int main(int argc, char **argv) {
  constexpr int x = 1;
  constexpr int y = 2;
  int z;

  __builtin_sadd_overflow(x, y, &z);
  return z;
}


On Wed, Jun 13, 2018 at 1:43 PM, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Wed Jun 13 13:43:27 2018
New Revision: 334650

URL: http://llvm.org/viewvc/llvm-project?rev=334650&view=rev
Log:
Implement constexpr __builtin_*_overflow

As requested here:https://bugs.llvm.org/show_bug.cgi?id=37633
permit the __builtin_*_overflow builtins in constexpr functions.

Differential Revision: https://reviews.llvm.org/D48040

Modified:
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/test/SemaCXX/builtins-overflow.cpp

Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=334650&r1=334649&r2=334650&view=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Wed Jun 13 13:43:27 2018
@@ -8155,6 +8155,124 @@ bool IntExprEvaluator::VisitBuiltinCallE
   case Builtin::BIomp_is_initial_device:
 // We can decide statically which value the runtime would return if called.
 return Success(Info.getLangOpts().OpenMPIsDevice ? 0 : 1, E);
+  case Builtin::BI__builtin_add_overflow:
+  case Builtin::BI__builtin_sub_overflow:
+  case Builtin::BI__builtin_mul_overflow:
+  case Builtin::BI__builtin_sadd_overflow:
+  case Builtin::BI__builtin_uadd_overflow:
+  case Builtin::BI__builtin_uaddl_overflow:
+  case Builtin::BI__builtin_uaddll_overflow:
+  case Builtin::BI__builtin_usub_overflow:
+  case Builtin::BI__builtin_usubl_overflow:
+  case Builtin::BI__builtin_usubll_overflow:
+  case Builtin::BI__builtin_umul_overflow:
+  case Builtin::BI__builtin_umull_overflow:
+  case Builtin::BI__builtin_umulll_overflow:
+  case Builtin::BI__builtin_saddl_overflow:
+  case Builtin::BI__builtin_saddll_overflow:
+  case Builtin::BI__builtin_ssub_overflow:
+  case Builtin::BI__builtin_ssubl_overflow:
+  case Builtin::BI__builtin_ssubll_overflow:
+  case Builtin::BI__builtin_smul_overflow:
+  case Builtin::BI__builtin_smull_overflow:
+  case Builtin::BI__builtin_smulll_overflow: {
+LValue ResultLValue;
+APSInt LHS, RHS;
+
+QualType ResultType = E->getArg(2)->getType()->getPointeeType();
+if (!EvaluateInteger(E->getArg(0), LHS, Info) ||
+!EvaluateInteger(E->getArg(1), RHS, Info) ||
+!EvaluatePointer(E->getArg(2), ResultLValue, Info))
+  return false;
+
+APSInt Result;
+bool DidOverflow = false;
+
+// If the types don't have to match, enlarge all 3 to the largest of them.
+if (BuiltinOp == Builtin::BI__builtin_add_overflow ||
+BuiltinOp == Builtin::BI__builtin_sub_overflow ||
+BuiltinOp == Builtin::BI__builtin_mul_overflow) {
+  bool IsSigned = LHS.isSigned() || RHS.isSigned() ||
+  ResultType->isSignedIntegerOrEnumerationType();
+  bool AllSigned = LHS.isSigned() && RHS.isSigned() &&
+  ResultType->isSignedIntegerOrEnumerationType();
+  uint64_t LHSSize = LHS.getBitWidth();
+  uint64_t RHSSize = RHS.getBitWidth();
+  uint64_t ResultSize = Info.Ctx.getTypeSize(ResultType);
+  uint64_t MaxBits = std::max(std::max(LHSSize, RHSSize), ResultSize);
+
+  // Add an additional bit if the signedness isn't uniformly agreed to. We
+  // could do this ONLY if there is a signed and an unsigned that both have
+  // MaxBits, but the code to check that is pretty nasty.  The issue will 
be
+  // caught in the shrink-to-result later anyway.
+  if (IsSigned && !AllSigned)
+++MaxBits;
+
+  LHS = APSInt(IsSigned ? LHS.sextOrSelf(MaxBits) : 
LHS.zextOrSelf(MaxBits),
+   !IsSigned);
+  RHS = APSInt(IsSigned ? RHS.sextOrSelf(MaxBits) : 
RHS.zextOrSelf(MaxBits),
+   !IsSigned);
+  Result = APSInt(MaxBits, !IsSigned);
+}
+
+// Find largest int.
+switch (BuiltinOp) {
+default:
+  llvm_unreachable("Invalid value for BuiltinOp");
+case Builtin::BI__builtin_add_overflow:
+case Builtin::BI__builtin_sadd_overflow:
+case Builtin::BI__builtin_saddl_overflow:
+case Builtin::BI__builtin_saddll_overflow:
+case Builtin::BI__builtin_uadd_overflow:
+case Builtin::BI__builtin_uaddl_overflow:
+case Builtin::BI__builtin_uaddll_overflow:
+  Result = LHS.isSigned() ? LHS.sadd_ov(RHS, DidOverflow)
+  : LHS.uadd_ov(RHS, DidOverflow);
+  break;
+case Builtin::BI__builtin_sub_ov

RE: r332470 - Add support for __declspec(code_seg("segname"))

[Keane, Erich via cfe-commits]

Hi Richard-
Thanks for the feedback.  I’m copying the author of this patch on this email 
for further discussion if you care to.

We’ll have her take another look at it.  Thanks for the revert. 
(https://github.com/llvm-mirror/clang/commit/746b78de7812bc785fbb5207b788348040b23fa7).

-Erich

From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Friday, May 18, 2018 1:14 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r332470 - Add support for __declspec(code_seg("segname"))

Here's an example regression:

https://godbolt.org/g/S72Nki

I'll check that into the test suite alongside the revert once my testing 
finishes.

On 18 May 2018 at 13:03, Richard Smith 
mailto:rich...@metafoo.co.uk>> wrote:
On 16 May 2018 at 06:57, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Wed May 16 06:57:17 2018
New Revision: 332470

URL: http://llvm.org/viewvc/llvm-project?rev=332470&view=rev
Log:
Add support for __declspec(code_seg("segname"))

Add support for __declspec(code_seg("segname"))

This patch is built on the existing support for #pragma code_seg. The code_seg
declspec is allowed on functions and classes. The attribute enables the
placement of code into separate named segments, including compiler-generated
members and template instantiations.

For more information, please see the following:
https://msdn.microsoft.com/en-us/library/dn636922.aspx

A new CodeSeg attribute is used instead of adding a new spelling to the existing
Section attribute since they don’t apply to the same Subjects. Section
attributes are also added for the code_seg declspec since they are used for
#pragma code_seg. No CodeSeg attributes are added to the AST.

This approach really doesn't work. You're incorrectly applying the 
__declspec(code_seg) restrictions to __attribute__((section)), regressing our 
support for the latter. Also, code_seg has fundamentally different semantics 
from the section attribute -- the former exists in part to support paged 
addressing (which is why it has the virtual function restriction) and the 
latter exists merely to control properties of the object file. This approach 
also violates our policy of maintaining source fidelity.

I'm going to revert this for now to fix the regression; when it comes back, I 
think you should just use CodeSegAttr to represent __declspec(code_seg) rather 
than trying to treat it as -- effectively -- a different spelling of 
SectionAttr.

The patch is written to match with the Microsoft compiler’s behavior even where
that behavior is a little complicated (see https://reviews.llvm.org/D22931, the
Microsoft feedback page is no longer available since MS has removed the page).
That code is in getImplicitSectionAttrFromClass routine.

Diagnostics messages are added to match with the Microsoft compiler for code-seg
attribute mismatches on base and derived classes and virtual overrides.


Differential Revision: https://reviews.llvm.org/D43352

Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/include/clang/Basic/AttrDocs.td
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/lib/Sema/SemaLambda.cpp

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=332470&r1=332469&r2=332470&view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Wed May 16 06:57:17 2018
@@ -1769,6 +1769,13 @@ def Section : InheritableAttr {
   let Documentation = [SectionDocs];
 }

+def CodeSeg : InheritableAttr {
+  let Spellings = [Declspec<"code_seg">];
+  let Args = [StringArgument<"Name">];
+  let Subjects = SubjectList<[Function, CXXRecord], ErrorDiag>;
+  let Documentation = [CodeSegDocs];
+}
+
 def PragmaClangBSSSection : InheritableAttr {
   // This attribute has no spellings as it is only ever created implicitly.
   let Spellings = [];

Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=332470&r1=332469&r2=332470&view=diff
==
--- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
+++ cfe/trunk/include/clang/Basic/AttrDocs.td Wed May 16 06:57:17 2018
@@ -306,6 +306,18 @@ An example of how to use ``alloc_size``
   }];
 }

+def CodeSegDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+The ``__declspec(code_seg)`` attribute enables the placement of code into 
separate
+named segments that can be paged or locked in memory individually. This 
attribute
+is used to control the placement of instantiated templates and 
compiler-generated
+code. See the documentation for `__declspec(code_s

RE: r331536 - [NFC]Convert Class to use member initialization instead of inline.

[Keane, Erich via cfe-commits]

I don’t believe the member initialization for bitfields (of which all the ‘0’ 
values are) happened until C++17, right?  I could definitely member initialize 
the two enum fields though.

From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Monday, May 7, 2018 12:03 PM
To: Keane, Erich 
Cc: cfe-commits@lists.llvm.org
Subject: Re: r331536 - [NFC]Convert Class to use member initialization instead 
of inline.

Perhaps this should use non-static data member initializers instead?

On Fri, May 4, 2018 at 9:23 AM Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Fri May  4 09:19:53 2018
New Revision: 331536

URL: http://llvm.org/viewvc/llvm-project?rev=331536&view=rev
Log:
[NFC]Convert Class to use member initialization instead of inline.

Modified:
cfe/trunk/include/clang/Frontend/DependencyOutputOptions.h

Modified: cfe/trunk/include/clang/Frontend/DependencyOutputOptions.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/DependencyOutputOptions.h?rev=331536&r1=331535&r2=331536&view=diff
==
--- cfe/trunk/include/clang/Frontend/DependencyOutputOptions.h (original)
+++ cfe/trunk/include/clang/Frontend/DependencyOutputOptions.h Fri May  4 
09:19:53 2018
@@ -65,15 +65,11 @@ public:
   std::string ModuleDependencyOutputDir;

 public:
-  DependencyOutputOptions() {
-IncludeSystemHeaders = 0;
-ShowHeaderIncludes = 0;
-UsePhonyTargets = 0;
-AddMissingHeaderDeps = 0;
-IncludeModuleFiles = 0;
-ShowIncludesDest = ShowIncludesDestination::None;
-OutputFormat = DependencyOutputFormat::Make;
-  }
+  DependencyOutputOptions()
+  : IncludeSystemHeaders(0), ShowHeaderIncludes(0), UsePhonyTargets(0),
+AddMissingHeaderDeps(0), IncludeModuleFiles(0),
+ShowIncludesDest(ShowIncludesDestination::None),
+OutputFormat(DependencyOutputFormat::Make) {}
 };

 }  // end namespace clang


___
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: r325081 - Implement function attribute artificial

[Keane, Erich via cfe-commits]

Thanks for your comments Richard, I’ve added the author to this email so that 
she can take a look.

From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Tuesday, February 13, 2018 5:39 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r325081 - Implement function attribute artificial

On 13 February 2018 at 16:14, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Tue Feb 13 16:14:07 2018
New Revision: 325081

URL: http://llvm.org/viewvc/llvm-project?rev=325081&view=rev
Log:
Implement function attribute artificial

Added support in clang for GCC function attribute 'artificial'. This attribute
is used to control stepping behavior of debugger with respect to inline
functions.

Patch By: Elizabeth Andrews (eandrews)

Differential Revision: https://reviews.llvm.org/D43259


Added:
cfe/trunk/test/CodeGen/artificial.c
cfe/trunk/test/Sema/artificial.c
Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/include/clang/Basic/AttrDocs.td
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/Sema/SemaDeclAttr.cpp

Modified: cfe/trunk/include/clang/Basic/Attr.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=325081&r1=325080&r2=325081&view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Tue Feb 13 16:14:07 2018
@@ -111,6 +111,9 @@ def SharedVar : SubsetSubjecthasGlobalStorage()}], "global variables">;

+def InlineFunction : SubsetSubjectisInlineSpecified()}], "inline functions">;
+
 // FIXME: this hack is needed because DeclNodes.td defines the base Decl node
 // type to be a class, not a definition. This makes it impossible to create an
 // attribute subject which accepts a Decl. Normally, this is not a problem,
@@ -588,6 +591,12 @@ def AlwaysInline : InheritableAttr {
   let Documentation = [Undocumented];
 }

+def Artificial : InheritableAttr {
+  let Spellings = [GCC<"artificial">];
+  let Subjects = SubjectList<[InlineFunction], WarnDiag>;
+  let Documentation = [ArtificialDocs];
+}
+
 def XRayInstrument : InheritableAttr {
   let Spellings = [Clang<"xray_always_instrument">,
Clang<"xray_never_instrument">];

Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=325081&r1=325080&r2=325081&view=diff
==
--- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
+++ cfe/trunk/include/clang/Basic/AttrDocs.td Tue Feb 13 16:14:07 2018
@@ -3273,3 +3273,13 @@ For more information see
 or `msvc documentation `_.
 }];
 }
+
+def ArtificialDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+The ``artificial`` attribute is used with inline functions to treat the inline
+function as a unit while debugging. For more information see GCC_ 
documentation.

I find this to be hard to understand. What does "treat the inline function as a 
unit" actually mean? How about something like:

The ``artificial`` attribute can be applied to an inline function. If such a 
function is inlined, the attribute indicates that debuggers should associate 
the resulting instructions with the call site, rather than with the 
corresponding line within the inlined callee.

+
+.. _GCC: https://gcc.gnu.org/onlinedocs/gcc-4.6.4/gcc/Function-Attributes.html

If you still want to reference the GCC documentation, could you pick a newer 
version? :)

+  }];
+}

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=325081&r1=325080&r2=325081&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Tue Feb 13 16:14:07 2018
@@ -3235,7 +3235,7 @@ void CGDebugInfo::EmitFunctionStart(Glob
   if (Name.startswith("\01"))
 Name = Name.substr(1);

-  if (!HasDecl || D->isImplicit()) {
+  if (!HasDecl || D->isImplicit() || D->hasAttr()) {
 Flags |= llvm::DINode::FlagArtificial;
 // Artificial functions should not silently reuse CurLoc.
 CurLoc = SourceLocation();

Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=325081&r1=325080&r2=325081&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Tue Feb 13 16:14:07 2018
@@ -6057,6 +6057,9 @@ static void ProcessDeclAttribute(Sema &S
   case AttributeList::AT_AlwaysInline:
 handleAlwaysInlineAttr(S, D, Attr);
 break;
+  case AttributeList::AT_Artificial:
+handleSimpleAttribute(S, D, Attr);
+break;
 

RE: [PATCH] D41837: Add Function multiversion to the release notes.

[Keane, Erich via cfe-commits]

It did not, I held it until just after the branch was made.

-Original Message-
From: hwennb...@google.com [mailto:hwennb...@google.com] On Behalf Of Hans 
Wennborg
Sent: Wednesday, January 17, 2018 4:47 AM
To: reviews+d41837+public+36225483e5851...@reviews.llvm.org
Cc: Keane, Erich ; Richard Smith 
; Aaron Ballman ; Eric 
Christopher ; cfe-commits 
Subject: Re: [PATCH] D41837: Add Function multiversion to the release notes.

Did this functionality land before the 6.0 branch, that is, should we copy the 
release notes to the branch?

Thanks
Hans

On Tue, Jan 9, 2018 at 12:37 AM, Erich Keane via Phabricator 
 wrote:
> This revision was automatically updated to reflect the committed changes.
> Closed by commit rC322043: Document attribute target multiversioning. 
> (authored by erichkeane, committed by ).
>
> Changed prior to commit:
>   https://reviews.llvm.org/D41837?vs=128982&id=128995#toc
>
> Repository:
>   rC Clang
>
> https://reviews.llvm.org/D41837
>
> Files:
>   docs/ReleaseNotes.rst
>   include/clang/Basic/AttrDocs.td
>
>
> Index: docs/ReleaseNotes.rst
> ===
> --- docs/ReleaseNotes.rst
> +++ docs/ReleaseNotes.rst
> @@ -80,6 +80,12 @@
>  Attribute Changes in Clang
>  --
>
> +- Clang now supports function multiversioning with attribute 'target' 
> +on ELF
> +  based x86/x86-64 environments by using indirect functions. This 
> +implementation
> +  has a few minor limitations over the GCC implementation for the 
> +sake of AST
> +  sanity, however it is otherwise compatible with existing code using 
> +this
> +  feature for GCC. Consult the documentation for the target attribute 
> +for more
> +  information.
>  - ...
>
>  Windows Support
> Index: include/clang/Basic/AttrDocs.td 
> ===
> --- include/clang/Basic/AttrDocs.td
> +++ include/clang/Basic/AttrDocs.td
> @@ -1474,6 +1474,24 @@
>  Example "subtarget features" from the x86 backend include: "mmx", 
> "sse", "sse4.2",  "avx", "xop" and largely correspond to the machine 
> specific options handled by  the front end.
> +
> +Additionally, this attribute supports function multiversioning for 
> +ELF based
> +x86/x86-64 targets, which can be used to create multiple 
> +implementations of the same function that will be resolved at runtime 
> +based on the priority of their ``target`` attribute strings. A 
> +function is considered a multiversioned function if either two 
> +declarations of the function have different ``target`` attribute
> +  strings, or if it has a ``target`` attribute string of ``default``.  
> +For
> +  example:
> +
> +  .. code-block:: c++
> +  __attribute__((target("arch=atom")))
> +  void foo() {} // will be called on 'atom' processors.
> +  __attribute__((target("default")))
> +  void foo() {} // will be called on any other processors.
> +
> +All multiversioned functions must contain a ``default`` (fallback) 
> +implementation, otherwise usages of the function are considered invalid.
> +Additionally, a function may not become multiversioned after its first use.
>  }];
>  }
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: r320489 - Fix ICE when __has_unqiue_object_representations called with invalid decl

[Keane, Erich via cfe-commits]

Fixed in 320493.  Thanks for catching that.

From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Tuesday, December 12, 2017 8:07 AM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r320489 - Fix ICE when __has_unqiue_object_representations called 
with invalid decl

On 12 Dec 2017 16:02, "Erich Keane via cfe-commits" 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Tue Dec 12 08:02:06 2017
New Revision: 320489

URL: http://llvm.org/viewvc/llvm-project?rev=320489&view=rev
Log:
Fix ICE when __has_unqiue_object_representations called with invalid decl

Modified:
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/test/SemaCXX/type-traits.cpp

Modified: cfe/trunk/lib/AST/ASTContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTContext.cpp?rev=320489&r1=320488&r2=320489&view=diff
==
--- cfe/trunk/lib/AST/ASTContext.cpp (original)
+++ cfe/trunk/lib/AST/ASTContext.cpp Tue Dec 12 08:02:06 2017
@@ -2279,6 +2279,9 @@ bool ASTContext::hasUniqueObjectRepresen
   if (Ty->isRecordType()) {
 const RecordDecl *Record = Ty->getAs()->getDecl();

+if (Record->isInvalidDecl())
+  return false;
+
 if (Record->isUnion())
   return unionHasUniqueObjectRepresentations(*this, Record);


Modified: cfe/trunk/lib/Sema/SemaExprCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExprCXX.cpp?rev=320489&r1=320488&r2=320489&view=diff
==
--- cfe/trunk/lib/Sema/SemaExprCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExprCXX.cpp Tue Dec 12 08:02:06 2017
@@ -4958,7 +4958,7 @@ static bool EvaluateBinaryTypeTrait(Sema
 EnterExpressionEvaluationContext Unevaluated(
 Self, Sema::ExpressionEvaluationContext::Unevaluated);
 Sema::SFINAETrap SFINAE(Self, /*AccessCheckingSFINAE=*/true);
-Sema::ContextRAII TUContext(Self, Self.Context.getTranslationUnitDecl());
+Sema::ContextRAII TUContext(Self, Self.Context.getTranslationUnitDecl()); {
 ExprResult Result = Self.BuildBinOp(/*S=*/nullptr, KeyLoc, BO_Assign, &Lhs,
 &Rhs);
 if (Result.isInvalid() || SFINAE.hasErrorOccurred())
@@ -4981,6 +4981,7 @@ static bool EvaluateBinaryTypeTrait(Sema

 llvm_unreachable("unhandled type trait");
 return false;
+}

Was this change intentional?

   }
 default: llvm_unreachable("not a BTT");
   }

Modified: cfe/trunk/test/SemaCXX/type-traits.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/type-traits.cpp?rev=320489&r1=320488&r2=320489&view=diff
==
--- cfe/trunk/test/SemaCXX/type-traits.cpp (original)
+++ cfe/trunk/test/SemaCXX/type-traits.cpp Tue Dec 12 08:02:06 2017
@@ -2661,3 +2661,11 @@ static_assert(sizeof(CanBeUniqueIfNoPadd
   has_unique_object_representations::value,
   "inherit from std layout");

+namespace ErrorType {
+  struct S; //expected-note{{forward declaration of 'ErrorType::S'}}
+
+  struct T {
+S t; //expected-error{{field has incomplete type 'ErrorType::S'}}
+  };
+  bool b = __has_unique_object_representations(T);
+};


___
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: r320489 - Fix ICE when __has_unqiue_object_representations called with invalid decl

[Keane, Erich via cfe-commits]

Gah, no it wasn’t.  I’ll revert that now.

From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Tuesday, December 12, 2017 8:07 AM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r320489 - Fix ICE when __has_unqiue_object_representations called 
with invalid decl

On 12 Dec 2017 16:02, "Erich Keane via cfe-commits" 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Tue Dec 12 08:02:06 2017
New Revision: 320489

URL: http://llvm.org/viewvc/llvm-project?rev=320489&view=rev
Log:
Fix ICE when __has_unqiue_object_representations called with invalid decl

Modified:
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/test/SemaCXX/type-traits.cpp

Modified: cfe/trunk/lib/AST/ASTContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTContext.cpp?rev=320489&r1=320488&r2=320489&view=diff
==
--- cfe/trunk/lib/AST/ASTContext.cpp (original)
+++ cfe/trunk/lib/AST/ASTContext.cpp Tue Dec 12 08:02:06 2017
@@ -2279,6 +2279,9 @@ bool ASTContext::hasUniqueObjectRepresen
   if (Ty->isRecordType()) {
 const RecordDecl *Record = Ty->getAs()->getDecl();

+if (Record->isInvalidDecl())
+  return false;
+
 if (Record->isUnion())
   return unionHasUniqueObjectRepresentations(*this, Record);


Modified: cfe/trunk/lib/Sema/SemaExprCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExprCXX.cpp?rev=320489&r1=320488&r2=320489&view=diff
==
--- cfe/trunk/lib/Sema/SemaExprCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExprCXX.cpp Tue Dec 12 08:02:06 2017
@@ -4958,7 +4958,7 @@ static bool EvaluateBinaryTypeTrait(Sema
 EnterExpressionEvaluationContext Unevaluated(
 Self, Sema::ExpressionEvaluationContext::Unevaluated);
 Sema::SFINAETrap SFINAE(Self, /*AccessCheckingSFINAE=*/true);
-Sema::ContextRAII TUContext(Self, Self.Context.getTranslationUnitDecl());
+Sema::ContextRAII TUContext(Self, Self.Context.getTranslationUnitDecl()); {
 ExprResult Result = Self.BuildBinOp(/*S=*/nullptr, KeyLoc, BO_Assign, &Lhs,
 &Rhs);
 if (Result.isInvalid() || SFINAE.hasErrorOccurred())
@@ -4981,6 +4981,7 @@ static bool EvaluateBinaryTypeTrait(Sema

 llvm_unreachable("unhandled type trait");
 return false;
+}

Was this change intentional?

   }
 default: llvm_unreachable("not a BTT");
   }

Modified: cfe/trunk/test/SemaCXX/type-traits.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/type-traits.cpp?rev=320489&r1=320488&r2=320489&view=diff
==
--- cfe/trunk/test/SemaCXX/type-traits.cpp (original)
+++ cfe/trunk/test/SemaCXX/type-traits.cpp Tue Dec 12 08:02:06 2017
@@ -2661,3 +2661,11 @@ static_assert(sizeof(CanBeUniqueIfNoPadd
   has_unique_object_representations::value,
   "inherit from std layout");

+namespace ErrorType {
+  struct S; //expected-note{{forward declaration of 'ErrorType::S'}}
+
+  struct T {
+S t; //expected-error{{field has incomplete type 'ErrorType::S'}}
+  };
+  bool b = __has_unique_object_representations(T);
+};


___
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: r316518 - mplement __has_unique_object_representations

[Keane, Erich via cfe-commits]

Thanks for the review Richard.  Would you like me to revert, or can I just make 
these changes in a new patch?


From: Richard Smith [mailto:rich...@metafoo.co.uk]
Sent: Thursday, October 26, 2017 9:50 AM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r316518 - mplement __has_unique_object_representations

On 24 Oct 2017 14:32, "Erich Keane via cfe-commits" 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Tue Oct 24 14:31:50 2017
New Revision: 316518

URL: http://llvm.org/viewvc/llvm-project?rev=316518&view=rev
Log:
mplement __has_unique_object_representations

A helper builtin to facilitate implementing the
std::has_unique_object_representations type trait.

Requested here: https://bugs.llvm.org/show_bug.cgi?id=34942
Also already exists in GCC and MSVC.

Differential Revision: https://reviews.llvm.org/D39064

Modified:
cfe/trunk/include/clang/AST/Type.h
cfe/trunk/include/clang/Basic/TokenKinds.def
cfe/trunk/include/clang/Basic/TypeTraits.h
cfe/trunk/lib/AST/Type.cpp
cfe/trunk/lib/Parse/ParseExpr.cpp
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/test/SemaCXX/type-traits.cpp

Modified: cfe/trunk/include/clang/AST/Type.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Type.h?rev=316518&r1=316517&r2=316518&view=diff
==
--- cfe/trunk/include/clang/AST/Type.h (original)
+++ cfe/trunk/include/clang/AST/Type.h Tue Oct 24 14:31:50 2017
@@ -770,6 +770,10 @@ public:
   /// Return true if this is a trivially copyable type (C++0x [basic.types]p9)
   bool isTriviallyCopyableType(const ASTContext &Context) const;

+  /// Return true if this has unique object representations according to (C++17
+  /// [meta.unary.prop]p9)
+  bool hasUniqueObjectRepresentations(const ASTContext &Context) const;

I think this would make more sense as a member of ASTContext. The Type object 
generally doesn't know or care about its representation.

+
   // Don't promise in the API that anything besides 'const' can be
   // easily added.

@@ -1114,6 +1118,8 @@ public:
   QualType getAtomicUnqualifiedType() const;

 private:
+  bool unionHasUniqueObjectRepresentations(const ASTContext& Context) const;
+  bool structHasUniqueObjectRepresentations(const ASTContext& Context) const;
   // These methods are implemented in a separate translation unit;
   // "static"-ize them to avoid creating temporary QualTypes in the
   // caller.

Modified: cfe/trunk/include/clang/Basic/TokenKinds.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/TokenKinds.def?rev=316518&r1=316517&r2=316518&view=diff
==
--- cfe/trunk/include/clang/Basic/TokenKinds.def (original)
+++ cfe/trunk/include/clang/Basic/TokenKinds.def Tue Oct 24 14:31:50 2017
@@ -455,6 +455,8 @@ TYPE_TRAIT_1(__is_pod, IsPOD, KEYCXX)
 TYPE_TRAIT_1(__is_polymorphic, IsPolymorphic, KEYCXX)
 TYPE_TRAIT_1(__is_trivial, IsTrivial, KEYCXX)
 TYPE_TRAIT_1(__is_union, IsUnion, KEYCXX)
+TYPE_TRAIT_1(__has_unique_object_representations,
+ HasUniqueObjectRepresentations, KEYCXX)

 // Clang-only C++ Type Traits
 TYPE_TRAIT_N(__is_trivially_constructible, IsTriviallyConstructible, KEYCXX)

Modified: cfe/trunk/include/clang/Basic/TypeTraits.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/TypeTraits.h?rev=316518&r1=316517&r2=316518&view=diff
==
--- cfe/trunk/include/clang/Basic/TypeTraits.h (original)
+++ cfe/trunk/include/clang/Basic/TypeTraits.h Tue Oct 24 14:31:50 2017
@@ -70,7 +70,8 @@ namespace clang {
 UTT_IsUnsigned,
 UTT_IsVoid,
 UTT_IsVolatile,
-UTT_Last = UTT_IsVolatile,
+UTT_HasUniqueObjectRepresentations,
+UTT_Last = UTT_HasUniqueObjectRepresentations,
 BTT_IsBaseOf,
 BTT_IsConvertible,
 BTT_IsConvertibleTo,

Modified: cfe/trunk/lib/AST/Type.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Type.cpp?rev=316518&r1=316517&r2=316518&view=diff
==
--- cfe/trunk/lib/AST/Type.cpp (original)
+++ cfe/trunk/lib/AST/Type.cpp Tue Oct 24 14:31:50 2017
@@ -2166,6 +2166,152 @@ bool QualType::isTriviallyCopyableType(c
   return false;
 }

+bool QualType::unionHasUniqueObjectRepresentations(
+const ASTContext &Context) const {
+  assert((*this)->isUnionType() && "must be union type");
+  CharUnits UnionSize = Context.getTypeSizeInChars(*this);
+  const RecordDecl *Union = getTypePtr()->getAs()->getDecl();
+
+  for (const auto *Field : Union->fields()) {
+if (!Field->getType().hasUniqueObjectRepresentations(Context))
+  return false;
+CharUnits FieldSize = Context.getTypeSizeInChars(Field->getType());
+if (FieldSize != UnionSize)
+  return false;
+  }
+  return true;
+}
+
+bool isStructEmpty(QualType Ty) {
+  assert(Ty.get

RE: r316518 - mplement __has_unique_object_representations

[Keane, Erich via cfe-commits]

Yikes!  Thanks for pointing this out, fixing it now.

From: David Majnemer [mailto:david.majne...@gmail.com]
Sent: Tuesday, October 24, 2017 2:55 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r316518 - mplement __has_unique_object_representations



On Tue, Oct 24, 2017 at 2:31 PM, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Tue Oct 24 14:31:50 2017
New Revision: 316518

URL: http://llvm.org/viewvc/llvm-project?rev=316518&view=rev
Log:
mplement __has_unique_object_representations

A helper builtin to facilitate implementing the
std::has_unique_object_representations type trait.

Requested here: https://bugs.llvm.org/show_bug.cgi?id=34942
Also already exists in GCC and MSVC.

Differential Revision: https://reviews.llvm.org/D39064

Modified:
cfe/trunk/include/clang/AST/Type.h
cfe/trunk/include/clang/Basic/TokenKinds.def
cfe/trunk/include/clang/Basic/TypeTraits.h
cfe/trunk/lib/AST/Type.cpp
cfe/trunk/lib/Parse/ParseExpr.cpp
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/test/SemaCXX/type-traits.cpp

Modified: cfe/trunk/include/clang/AST/Type.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Type.h?rev=316518&r1=316517&r2=316518&view=diff
==
--- cfe/trunk/include/clang/AST/Type.h (original)
+++ cfe/trunk/include/clang/AST/Type.h Tue Oct 24 14:31:50 2017
@@ -770,6 +770,10 @@ public:
   /// Return true if this is a trivially copyable type (C++0x [basic.types]p9)
   bool isTriviallyCopyableType(const ASTContext &Context) const;

+  /// Return true if this has unique object representations according to (C++17
+  /// [meta.unary.prop]p9)
+  bool hasUniqueObjectRepresentations(const ASTContext &Context) const;
+
   // Don't promise in the API that anything besides 'const' can be
   // easily added.

@@ -1114,6 +1118,8 @@ public:
   QualType getAtomicUnqualifiedType() const;

 private:
+  bool unionHasUniqueObjectRepresentations(const ASTContext& Context) const;
+  bool structHasUniqueObjectRepresentations(const ASTContext& Context) const;
   // These methods are implemented in a separate translation unit;
   // "static"-ize them to avoid creating temporary QualTypes in the
   // caller.

Modified: cfe/trunk/include/clang/Basic/TokenKinds.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/TokenKinds.def?rev=316518&r1=316517&r2=316518&view=diff
==
--- cfe/trunk/include/clang/Basic/TokenKinds.def (original)
+++ cfe/trunk/include/clang/Basic/TokenKinds.def Tue Oct 24 14:31:50 2017
@@ -455,6 +455,8 @@ TYPE_TRAIT_1(__is_pod, IsPOD, KEYCXX)
 TYPE_TRAIT_1(__is_polymorphic, IsPolymorphic, KEYCXX)
 TYPE_TRAIT_1(__is_trivial, IsTrivial, KEYCXX)
 TYPE_TRAIT_1(__is_union, IsUnion, KEYCXX)
+TYPE_TRAIT_1(__has_unique_object_representations,
+ HasUniqueObjectRepresentations, KEYCXX)

 // Clang-only C++ Type Traits
 TYPE_TRAIT_N(__is_trivially_constructible, IsTriviallyConstructible, KEYCXX)

Modified: cfe/trunk/include/clang/Basic/TypeTraits.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/TypeTraits.h?rev=316518&r1=316517&r2=316518&view=diff
==
--- cfe/trunk/include/clang/Basic/TypeTraits.h (original)
+++ cfe/trunk/include/clang/Basic/TypeTraits.h Tue Oct 24 14:31:50 2017
@@ -70,7 +70,8 @@ namespace clang {
 UTT_IsUnsigned,
 UTT_IsVoid,
 UTT_IsVolatile,
-UTT_Last = UTT_IsVolatile,
+UTT_HasUniqueObjectRepresentations,
+UTT_Last = UTT_HasUniqueObjectRepresentations,
 BTT_IsBaseOf,
 BTT_IsConvertible,
 BTT_IsConvertibleTo,

Modified: cfe/trunk/lib/AST/Type.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Type.cpp?rev=316518&r1=316517&r2=316518&view=diff
==
--- cfe/trunk/lib/AST/Type.cpp (original)
+++ cfe/trunk/lib/AST/Type.cpp Tue Oct 24 14:31:50 2017
@@ -2166,6 +2166,152 @@ bool QualType::isTriviallyCopyableType(c
   return false;
 }

+bool QualType::unionHasUniqueObjectRepresentations(
+const ASTContext &Context) const {
+  assert((*this)->isUnionType() && "must be union type");
+  CharUnits UnionSize = Context.getTypeSizeInChars(*this);
+  const RecordDecl *Union = getTypePtr()->getAs()->getDecl();
+
+  for (const auto *Field : Union->fields()) {
+if (!Field->getType().hasUniqueObjectRepresentations(Context))
+  return false;
+CharUnits FieldSize = Context.getTypeSizeInChars(Field->getType());
+if (FieldSize != UnionSize)
+  return false;
+  }
+  return true;
+}
+
+bool isStructEmpty(QualType Ty) {
+  assert(Ty.getTypePtr()->isStructureOrClassType() &&
+ "Must be struct or class");
+  const RecordDecl *RD = Ty.getTypePtr()->getAs()->getDecl();
+
+  if (!RD->field_empty())
+return fa

RE: r316447 - Fix spelling in comment, field is isMsStruct, not Strust

[Keane, Erich via cfe-commits]

Ah, thanks for letting me know! I’ll do that now.

From: tha...@google.com [mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Tuesday, October 24, 2017 8:59 AM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r316447 - Fix spelling in comment, field is isMsStruct, not Strust

This is fine, but a few years ago we agreed that we shouldn't repeat method 
names in doxygen. So an Even Better Fix would've been to just remove everything 
up to (and including) the ' - ' :-) Just FYI, no need to follow this up with 
the deletion.

On Tue, Oct 24, 2017 at 3:34 PM, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Tue Oct 24 08:34:59 2017
New Revision: 316447

URL: http://llvm.org/viewvc/llvm-project?rev=316447&view=rev
Log:
Fix spelling in comment, field is isMsStruct, not Strust

Modified:
cfe/trunk/include/clang/AST/Decl.h

Modified: cfe/trunk/include/clang/AST/Decl.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=316447&r1=316446&r2=316447&view=diff
==
--- cfe/trunk/include/clang/AST/Decl.h (original)
+++ cfe/trunk/include/clang/AST/Decl.h Tue Oct 24 08:34:59 2017
@@ -3540,7 +3540,7 @@ public:
 return K >= firstRecord && K <= lastRecord;
   }

-  /// isMsStrust - Get whether or not this is an ms_struct which can
+  /// isMsStruct - Get whether or not this is an ms_struct which can
   /// be turned on with an attribute, pragma, or -mms-bitfields
   /// commandline option.
   bool isMsStruct(const ASTContext &C) const;


___
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: r314262 - Emit section information for extern variables.

[Keane, Erich via cfe-commits]

Elizabeth gave me a patch, submitted it with a test in r314939

From: Andrews, Elizabeth
Sent: Wednesday, October 4, 2017 1:54 PM
To: Friedman, Eli ; Keane, Erich 
; Nico Weber 
Cc: cfe-commits 
Subject: RE: r314262 - Emit section information for extern variables.

Alright. Will do. Thanks!

From: Friedman, Eli [mailto:efrie...@codeaurora.org]
Sent: Wednesday, October 4, 2017 4:51 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>; 
Andrews, Elizabeth 
mailto:elizabeth.andr...@intel.com>>; Nico Weber 
mailto:tha...@chromium.org>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r314262 - Emit section information for extern variables.

On 10/4/2017 1:48 PM, Keane, Erich wrote:
Ah, cool!  I didn’t realize that, and that is actually exactly what Elizabeth 
is looking into now.

Elizabeth, if you send me a diff, I’ll commit it as review-after-commit if Eli 
is alright with this.  It should be something like changing:
+  if (VD->isThisDeclarationADefinition() != VarDecl::Definition) {
To
+  if (VD->isThisDeclarationADefinition() != VarDecl::Definition && 
VD->isThsDeclarationADefinition() != VarDecl::TentativeDefinition) {


Right?

I'd probably just write it "if (VD->isThisDeclarationADefinition() == 
VarDecl::DeclarationOnly)", but yes.  (And don't forget a testcase.)

-Eli


From: Friedman, Eli [mailto:efrie...@codeaurora.org]
Sent: Wednesday, October 4, 2017 1:46 PM
To: Andrews, Elizabeth 
; Nico Weber 

Cc: cfe-commits 
; Keane, Erich 

Subject: Re: r314262 - Emit section information for extern variables.

Oh, that's easy to explain; sorry, I didn't think of it when I was reviewing.

DefinitionKind has three possible values: DeclarationOnly, TentativeDefinition, 
and Definition.  (Tentative definitions are C weirdness that allows you to 
write "int x; int x = 10;".)

For the purpose of this warning, a TentativeDefinition should count as a 
definition.

-Eli

On 10/4/2017 1:38 PM, Andrews, Elizabeth wrote:
Hello,
I just spoke to Erich. The warning isn’t supposed to be emitted when the 
section attribute is specified on a definition. I’m not sure why struct r_debug 
_r_debug __attribute__((nocommon, section(".r_debug"))); failed the 
isThisDeclarationADefiniton check. I need to look into it.
Thanks,
Elizabeth

From: tha...@google.com [mailto:tha...@google.com] On 
Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 4:29 PM
To: Keane, Erich 
Cc: Andrews, Elizabeth 
; Friedman, 
Eli ; cfe-commits 

Subject: Re: r314262 - Emit section information for extern variables.

All I know about this code that it used to build (and still builds with gcc) 
and now it doesn't, sorry :-) What that code does seems somewhat questionable, 
but also somewhat useful, and it feels like the behavior change from this 
change here for that code might have been unintentional.

Your suggestion sounds reasonable to me.

On Wed, Oct 4, 2017 at 4:18 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
I saw that… I don’t see where it prevents the same change from being made in 
link.h.

As I mentioned, there is a solution to make this Warning less aggressive (in 
the lib/Sema/SemaDecl.cpp changes, add a condition that Old->isUsed() before 
the warning.  I’m wondering if that solves your issue.

It would result in
extern struct r_debug _r_debug;
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
Compiling, but :
extern struct r_debug _r_debug;
r_debug = something();
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
NOT compiling (which is almost definitely a bug).



From: tha...@google.com 
[mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 1:14 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: Andrews, Elizabeth 
mailto:elizabeth.andr...@intel.com>>; Friedman, 
Eli mailto:efrie...@codeaurora.org>>; cfe-commits 
mailto:cfe-commits@lists.llvm.org>>

Subject: Re: r314262 - Emit section information for extern variables.

For why, here's the comment from the code I linked to:

/*
 * GDB looks for this symbol name when it cannot find PT_DYNAMIC->DT_DEBUG.
 * We don't have a PT_DYNAMIC, so it will find this.  Now all we have to do
 * is arrange for this space to be filled in with the dynamic linker's
 * _r_debug contents after they're initialized.  That way, attaching GDB to
 * this process or examining its core file will find the PIE we loaded, the
 * dynamic linker, and all the shared libraries, making debugging pleasant.
 */

On Wed, Oct 4, 2017 at 4:11 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
I’ve added Elizabeth, who is the original patch author.  Hopefully she can help 
out here.  

RE: r314262 - Emit section information for extern variables.

[Keane, Erich via cfe-commits]

Ah, cool!  I didn’t realize that, and that is actually exactly what Elizabeth 
is looking into now.

Elizabeth, if you send me a diff, I’ll commit it as review-after-commit if Eli 
is alright with this.  It should be something like changing:
+  if (VD->isThisDeclarationADefinition() != VarDecl::Definition) {
To
+  if (VD->isThisDeclarationADefinition() != VarDecl::Definition && 
VD->isThsDeclarationADefinition() != VarDecl::TentativeDefinition) {


Right?

From: Friedman, Eli [mailto:efrie...@codeaurora.org]
Sent: Wednesday, October 4, 2017 1:46 PM
To: Andrews, Elizabeth ; Nico Weber 

Cc: cfe-commits ; Keane, Erich 

Subject: Re: r314262 - Emit section information for extern variables.

Oh, that's easy to explain; sorry, I didn't think of it when I was reviewing.

DefinitionKind has three possible values: DeclarationOnly, TentativeDefinition, 
and Definition.  (Tentative definitions are C weirdness that allows you to 
write "int x; int x = 10;".)

For the purpose of this warning, a TentativeDefinition should count as a 
definition.

-Eli

On 10/4/2017 1:38 PM, Andrews, Elizabeth wrote:
Hello,
I just spoke to Erich. The warning isn’t supposed to be emitted when the 
section attribute is specified on a definition. I’m not sure why struct r_debug 
_r_debug __attribute__((nocommon, section(".r_debug"))); failed the 
isThisDeclarationADefiniton check. I need to look into it.
Thanks,
Elizabeth

From: tha...@google.com [mailto:tha...@google.com] On 
Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 4:29 PM
To: Keane, Erich 
Cc: Andrews, Elizabeth 
; Friedman, 
Eli ; cfe-commits 

Subject: Re: r314262 - Emit section information for extern variables.

All I know about this code that it used to build (and still builds with gcc) 
and now it doesn't, sorry :-) What that code does seems somewhat questionable, 
but also somewhat useful, and it feels like the behavior change from this 
change here for that code might have been unintentional.

Your suggestion sounds reasonable to me.

On Wed, Oct 4, 2017 at 4:18 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
I saw that… I don’t see where it prevents the same change from being made in 
link.h.

As I mentioned, there is a solution to make this Warning less aggressive (in 
the lib/Sema/SemaDecl.cpp changes, add a condition that Old->isUsed() before 
the warning.  I’m wondering if that solves your issue.

It would result in
extern struct r_debug _r_debug;
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
Compiling, but :
extern struct r_debug _r_debug;
r_debug = something();
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
NOT compiling (which is almost definitely a bug).



From: tha...@google.com 
[mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 1:14 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: Andrews, Elizabeth 
mailto:elizabeth.andr...@intel.com>>; Friedman, 
Eli mailto:efrie...@codeaurora.org>>; cfe-commits 
mailto:cfe-commits@lists.llvm.org>>

Subject: Re: r314262 - Emit section information for extern variables.

For why, here's the comment from the code I linked to:

/*
 * GDB looks for this symbol name when it cannot find PT_DYNAMIC->DT_DEBUG.
 * We don't have a PT_DYNAMIC, so it will find this.  Now all we have to do
 * is arrange for this space to be filled in with the dynamic linker's
 * _r_debug contents after they're initialized.  That way, attaching GDB to
 * this process or examining its core file will find the PIE we loaded, the
 * dynamic linker, and all the shared libraries, making debugging pleasant.
 */

On Wed, Oct 4, 2017 at 4:11 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
I’ve added Elizabeth, who is the original patch author.  Hopefully she can help 
out here.  Additionally, Eli did the original review, so hopefully he can chime 
in as well.

I believe the necessity for this warning came out of the discussion on fixing 
the section behavior.  The issue here is that redeclaring with a different 
‘section’ can cause some pretty nasty issues, since it isn’t terribly clear 
what happens if the variable is used in the meantime.

There is 1 change that I can think of that Elizabeth and I discussed, which was 
to only warn in the case where there was a USAGE between these two 
redeclarations.  I’m not sure that will allow na_cl to compile, however it is 
my belief that if there IS a usage between link.h:64 and nacl_bootstrap.c:434, 
that this is a bug in nacl that is simply being uncovered thanks to this new 
warning.

Is there a good/reasonable reason the source of nacl wants to redeclare this 
with a different ‘section’?


From: tha...@google.com 
[mailto:tha...@google.com] On

RE: r314262 - Emit section information for extern variables.

[Keane, Erich via cfe-commits]

Elizabeth pointed out to me separately that the “isDeclarationADefinition” 
check ought to have prevented this from happening, so she’s taking a look I 
believe.  The usage proposal I mentioned below might be handy as well.

My fear is that this is a case where the existing functionality in Chromium 
works ‘by chance’ and isn’t terribly guaranteed by the code generation of 
either compiler.  IF this is the case, it could be a situation where this 
warning has found a bug.

As I’m not convinced that this is actually a clang bug, I would like to give 
Elizabeth a chance to poke around and make that determination first before a 
revert, if that is acceptable to you.

-Erich

From: tha...@google.com [mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 1:29 PM
To: Keane, Erich 
Cc: Andrews, Elizabeth ; Friedman, Eli 
; cfe-commits 
Subject: Re: r314262 - Emit section information for extern variables.

All I know about this code that it used to build (and still builds with gcc) 
and now it doesn't, sorry :-) What that code does seems somewhat questionable, 
but also somewhat useful, and it feels like the behavior change from this 
change here for that code might have been unintentional.

Your suggestion sounds reasonable to me.

On Wed, Oct 4, 2017 at 4:18 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
I saw that… I don’t see where it prevents the same change from being made in 
link.h.

As I mentioned, there is a solution to make this Warning less aggressive (in 
the lib/Sema/SemaDecl.cpp changes, add a condition that Old->isUsed() before 
the warning.  I’m wondering if that solves your issue.

It would result in
extern struct r_debug _r_debug;
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
Compiling, but :
extern struct r_debug _r_debug;
r_debug = something();
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
NOT compiling (which is almost definitely a bug).



From: tha...@google.com 
[mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 1:14 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: Andrews, Elizabeth 
mailto:elizabeth.andr...@intel.com>>; Friedman, 
Eli mailto:efrie...@codeaurora.org>>; cfe-commits 
mailto:cfe-commits@lists.llvm.org>>

Subject: Re: r314262 - Emit section information for extern variables.

For why, here's the comment from the code I linked to:

/*
 * GDB looks for this symbol name when it cannot find PT_DYNAMIC->DT_DEBUG.
 * We don't have a PT_DYNAMIC, so it will find this.  Now all we have to do
 * is arrange for this space to be filled in with the dynamic linker's
 * _r_debug contents after they're initialized.  That way, attaching GDB to
 * this process or examining its core file will find the PIE we loaded, the
 * dynamic linker, and all the shared libraries, making debugging pleasant.
 */

On Wed, Oct 4, 2017 at 4:11 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
I’ve added Elizabeth, who is the original patch author.  Hopefully she can help 
out here.  Additionally, Eli did the original review, so hopefully he can chime 
in as well.

I believe the necessity for this warning came out of the discussion on fixing 
the section behavior.  The issue here is that redeclaring with a different 
‘section’ can cause some pretty nasty issues, since it isn’t terribly clear 
what happens if the variable is used in the meantime.

There is 1 change that I can think of that Elizabeth and I discussed, which was 
to only warn in the case where there was a USAGE between these two 
redeclarations.  I’m not sure that will allow na_cl to compile, however it is 
my belief that if there IS a usage between link.h:64 and nacl_bootstrap.c:434, 
that this is a bug in nacl that is simply being uncovered thanks to this new 
warning.

Is there a good/reasonable reason the source of nacl wants to redeclare this 
with a different ‘section’?


From: tha...@google.com 
[mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 12:59 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r314262 - Emit section information for extern variables.

Hi Erich,

this breaks existing code. NaCl does this:

#include 
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));

(There's a lengthy-ish comment for why in 
https://cs.chromium.org/chromium/src/native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c?q=nacl_bootstrap.c&sq=package:chromium&dr&l=424)

link.h in e.g. the debian jessie sysroot says:
extern struct r_debug _r_debug;

After this change, clang complains:

../../native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c:434:16: 
error: section attribute is specified on redeclared variable [-Werror,-Wsection]
struct r_debug _r_debug __attribute__((nocommon, section

RE: r314262 - Emit section information for extern variables.

[Keane, Erich via cfe-commits]

I saw that… I don’t see where it prevents the same change from being made in 
link.h.

As I mentioned, there is a solution to make this Warning less aggressive (in 
the lib/Sema/SemaDecl.cpp changes, add a condition that Old->isUsed() before 
the warning.  I’m wondering if that solves your issue.

It would result in
extern struct r_debug _r_debug;
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
Compiling, but :
extern struct r_debug _r_debug;
r_debug = something();
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
NOT compiling (which is almost definitely a bug).



From: tha...@google.com [mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 1:14 PM
To: Keane, Erich 
Cc: Andrews, Elizabeth ; Friedman, Eli 
; cfe-commits 
Subject: Re: r314262 - Emit section information for extern variables.

For why, here's the comment from the code I linked to:

/*
 * GDB looks for this symbol name when it cannot find PT_DYNAMIC->DT_DEBUG.
 * We don't have a PT_DYNAMIC, so it will find this.  Now all we have to do
 * is arrange for this space to be filled in with the dynamic linker's
 * _r_debug contents after they're initialized.  That way, attaching GDB to
 * this process or examining its core file will find the PIE we loaded, the
 * dynamic linker, and all the shared libraries, making debugging pleasant.
 */

On Wed, Oct 4, 2017 at 4:11 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
I’ve added Elizabeth, who is the original patch author.  Hopefully she can help 
out here.  Additionally, Eli did the original review, so hopefully he can chime 
in as well.

I believe the necessity for this warning came out of the discussion on fixing 
the section behavior.  The issue here is that redeclaring with a different 
‘section’ can cause some pretty nasty issues, since it isn’t terribly clear 
what happens if the variable is used in the meantime.

There is 1 change that I can think of that Elizabeth and I discussed, which was 
to only warn in the case where there was a USAGE between these two 
redeclarations.  I’m not sure that will allow na_cl to compile, however it is 
my belief that if there IS a usage between link.h:64 and nacl_bootstrap.c:434, 
that this is a bug in nacl that is simply being uncovered thanks to this new 
warning.

Is there a good/reasonable reason the source of nacl wants to redeclare this 
with a different ‘section’?


From: tha...@google.com 
[mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 12:59 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r314262 - Emit section information for extern variables.

Hi Erich,

this breaks existing code. NaCl does this:

#include 
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));

(There's a lengthy-ish comment for why in 
https://cs.chromium.org/chromium/src/native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c?q=nacl_bootstrap.c&sq=package:chromium&dr&l=424)

link.h in e.g. the debian jessie sysroot says:
extern struct r_debug _r_debug;

After this change, clang complains:

../../native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c:434:16: 
error: section attribute is specified on redeclared variable [-Werror,-Wsection]
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
   ^
../../build/linux/debian_jessie_amd64-sysroot/usr/include/link.h:67:23: note: 
previous declaration is here
extern struct r_debug _r_debug;


This code used to work in clang, and continues to work in gcc. So this patch 
probably isn't quite the right approach. Ideas?

On Tue, Sep 26, 2017 at 7:42 PM, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Tue Sep 26 16:42:34 2017
New Revision: 314262

URL: http://llvm.org/viewvc/llvm-project?rev=314262&view=rev
Log:
Emit section information for extern variables.

Currently, if _attribute_((section())) is used for extern variables,
section information is not emitted in generated IR when the variables are used.
This is expected since sections are not generated for external linkage objects.
However NiosII requires this information as it uses special GP-relative accesses
for any objects that use attribute section (.sdata). GCC keeps this attribute in
  middle-end.

This change emits the section information for all targets.

Patch By: Elizabeth Andrews

Differential Revision:https://reviews.llvm.org/D36487


Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/test/Sema/attr-section.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=314262&r1=314261&r2=314262&view=diff
=

RE: r314262 - Emit section information for extern variables.

[Keane, Erich via cfe-commits]

I’ve added Elizabeth, who is the original patch author.  Hopefully she can help 
out here.  Additionally, Eli did the original review, so hopefully he can chime 
in as well.

I believe the necessity for this warning came out of the discussion on fixing 
the section behavior.  The issue here is that redeclaring with a different 
‘section’ can cause some pretty nasty issues, since it isn’t terribly clear 
what happens if the variable is used in the meantime.

There is 1 change that I can think of that Elizabeth and I discussed, which was 
to only warn in the case where there was a USAGE between these two 
redeclarations.  I’m not sure that will allow na_cl to compile, however it is 
my belief that if there IS a usage between link.h:64 and nacl_bootstrap.c:434, 
that this is a bug in nacl that is simply being uncovered thanks to this new 
warning.

Is there a good/reasonable reason the source of nacl wants to redeclare this 
with a different ‘section’?


From: tha...@google.com [mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, October 4, 2017 12:59 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r314262 - Emit section information for extern variables.

Hi Erich,

this breaks existing code. NaCl does this:

#include 
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));

(There's a lengthy-ish comment for why in 
https://cs.chromium.org/chromium/src/native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c?q=nacl_bootstrap.c&sq=package:chromium&dr&l=424)

link.h in e.g. the debian jessie sysroot says:
extern struct r_debug _r_debug;

After this change, clang complains:

../../native_client/src/trusted/service_runtime/linux/nacl_bootstrap.c:434:16: 
error: section attribute is specified on redeclared variable [-Werror,-Wsection]
struct r_debug _r_debug __attribute__((nocommon, section(".r_debug")));
   ^
../../build/linux/debian_jessie_amd64-sysroot/usr/include/link.h:67:23: note: 
previous declaration is here
extern struct r_debug _r_debug;


This code used to work in clang, and continues to work in gcc. So this patch 
probably isn't quite the right approach. Ideas?

On Tue, Sep 26, 2017 at 7:42 PM, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Tue Sep 26 16:42:34 2017
New Revision: 314262

URL: http://llvm.org/viewvc/llvm-project?rev=314262&view=rev
Log:
Emit section information for extern variables.

Currently, if _attribute_((section())) is used for extern variables,
section information is not emitted in generated IR when the variables are used.
This is expected since sections are not generated for external linkage objects.
However NiosII requires this information as it uses special GP-relative accesses
for any objects that use attribute section (.sdata). GCC keeps this attribute in
  middle-end.

This change emits the section information for all targets.

Patch By: Elizabeth Andrews

Differential Revision:https://reviews.llvm.org/D36487


Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/test/Sema/attr-section.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=314262&r1=314261&r2=314262&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Tue Sep 26 16:42:34 
2017
@@ -2620,6 +2620,8 @@ def err_attribute_section_invalid_for_ta
   "argument to 'section' attribute is not valid for this target: %0">;
 def warn_mismatched_section : Warning<
   "section does not match previous declaration">, InGroup;
+def warn_attribute_section_on_redeclaration : Warning<
+  "section attribute is specified on redeclared variable">, InGroup;

 def err_anonymous_property: Error<
   "anonymous property is not supported">;

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=314262&r1=314261&r2=314262&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Tue Sep 26 16:42:34 2017
@@ -2432,6 +2432,12 @@ CodeGenModule::GetOrCreateLLVMGlobal(Str
   EmitGlobalVarDefinition(D);
 }

+// Emit section information for extern variables.
+if (D->hasExternalStorage()) {
+  if (const SectionAttr *SA = D->getAttr())
+GV->setSection(SA->getName());
+}
+
 // Handle XCore specific ABI requirements.
 if (getTriple().getArch() == llvm::Triple::xcore &&
 D->getLanguageLinkage() == CLanguageLinkage &&

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/Sema

RE: r314235 - Allow IUnknown/IInterface types to come from extern C++

[Keane, Erich via cfe-commits]

BTW: The guy who told me about this issue ALSO discovered a different issue 
that that I didn't solve due to his reproducer not contining the whole 
testcase.  I've got a patch to fix all of it in his hands right now, so I'll 
submit this fix with it together.

-Erich

-Original Message-
From: Friedman, Eli [mailto:efrie...@codeaurora.org] 
Sent: Tuesday, September 26, 2017 12:06 PM
To: Keane, Erich ; cfe-commits@lists.llvm.org
Subject: Re: r314235 - Allow IUnknown/IInterface types to come from extern C++

On 9/26/2017 11:55 AM, Erich Keane via cfe-commits wrote:
> Author: erichkeane
> Date: Tue Sep 26 11:55:16 2017
> New Revision: 314235
>
> URL: http://llvm.org/viewvc/llvm-project?rev=314235&view=rev
> Log:
> Allow IUnknown/IInterface types to come from extern C++
>
> It was brought up in response to my last implementation for this 
> struct-as-interface features that at least 1 header in the MS SDK uses 
> "extern C++" around an IUnknown declaration.
>
> The previous implementation demanded that this type exist in the 
> TranslationUnit DeclContext.  This small change simply also allows in 
> the situation where we're extern "C++".
>
> Modified:
>  cfe/trunk/lib/AST/DeclCXX.cpp
>  cfe/trunk/test/SemaCXX/ms-iunknown.cpp
>
> Modified: cfe/trunk/lib/AST/DeclCXX.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclCXX.cpp?rev=
> 314235&r1=314234&r2=314235&view=diff
> ==
> 
> --- cfe/trunk/lib/AST/DeclCXX.cpp (original)
> +++ cfe/trunk/lib/AST/DeclCXX.cpp Tue Sep 26 11:55:16 2017
> @@ -1491,7 +1491,8 @@ bool CXXRecordDecl::isInterfaceLike() co
>   
> // Check "Special" types.
> const auto *Uuid = getAttr();
> -  if (Uuid && isStruct() && getDeclContext()->isTranslationUnit() &&
> +  if (Uuid && isStruct() && (getDeclContext()->isTranslationUnit() ||
> + getDeclContext()->isExternCXXContext()) 
> + &&

Do you need to check that the "extern C++" is actually a direct child of the 
translation unit?  Consider, e.g. `namespace X { extern "C++"`...

-Eli

--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

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

RE: r314235 - Allow IUnknown/IInterface types to come from extern C++

[Keane, Erich via cfe-commits]

Ah! Sorry, I didn't realize that isExternCXXContext actually searched the 
entire search-set!  Followup patch coming  Thanks for the heads up!

-Original Message-
From: Friedman, Eli [mailto:efrie...@codeaurora.org] 
Sent: Tuesday, September 26, 2017 12:06 PM
To: Keane, Erich ; cfe-commits@lists.llvm.org
Subject: Re: r314235 - Allow IUnknown/IInterface types to come from extern C++

On 9/26/2017 11:55 AM, Erich Keane via cfe-commits wrote:
> Author: erichkeane
> Date: Tue Sep 26 11:55:16 2017
> New Revision: 314235
>
> URL: http://llvm.org/viewvc/llvm-project?rev=314235&view=rev
> Log:
> Allow IUnknown/IInterface types to come from extern C++
>
> It was brought up in response to my last implementation for this 
> struct-as-interface features that at least 1 header in the MS SDK uses 
> "extern C++" around an IUnknown declaration.
>
> The previous implementation demanded that this type exist in the 
> TranslationUnit DeclContext.  This small change simply also allows in 
> the situation where we're extern "C++".
>
> Modified:
>  cfe/trunk/lib/AST/DeclCXX.cpp
>  cfe/trunk/test/SemaCXX/ms-iunknown.cpp
>
> Modified: cfe/trunk/lib/AST/DeclCXX.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/DeclCXX.cpp?rev=
> 314235&r1=314234&r2=314235&view=diff
> ==
> 
> --- cfe/trunk/lib/AST/DeclCXX.cpp (original)
> +++ cfe/trunk/lib/AST/DeclCXX.cpp Tue Sep 26 11:55:16 2017
> @@ -1491,7 +1491,8 @@ bool CXXRecordDecl::isInterfaceLike() co
>   
> // Check "Special" types.
> const auto *Uuid = getAttr();
> -  if (Uuid && isStruct() && getDeclContext()->isTranslationUnit() &&
> +  if (Uuid && isStruct() && (getDeclContext()->isTranslationUnit() ||
> + getDeclContext()->isExternCXXContext()) 
> + &&

Do you need to check that the "extern C++" is actually a direct child of the 
translation unit?  Consider, e.g. `namespace X { extern "C++"`...

-Eli

--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

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

RE: r313907 - Suppress Wsign-conversion for enums with matching underlying type

[Keane, Erich via cfe-commits]

Fixed in 313909.

-Original Message-
From: Friedman, Eli [mailto:efrie...@codeaurora.org] 
Sent: Thursday, September 21, 2017 1:14 PM
To: Keane, Erich ; cfe-commits@lists.llvm.org
Subject: Re: r313907 - Suppress Wsign-conversion for enums with matching 
underlying type

On 9/21/2017 12:58 PM, Erich Keane via cfe-commits wrote:
> Author: erichkeane
> Date: Thu Sep 21 12:58:55 2017
> New Revision: 313907
>
> URL: http://llvm.org/viewvc/llvm-project?rev=313907&view=rev
> Log:
> Suppress Wsign-conversion for enums with matching underlying type
>
> As reported here: https://bugs.llvm.org/show_bug.cgi?id=34692
>
> A non-defined enum with a backing type was always defaulting to being 
> treated as a signed type. IN the case where it IS defined, the 
> signed-ness of the actual items is used.
>
> This patch uses the underlying type's signed-ness in the non-defined 
> case to test signed-comparision.
>
> Differential Revision: https://reviews.llvm.org/D38145
>
> Modified:
>  cfe/trunk/lib/Sema/SemaChecking.cpp

Missing testcase?

-El

--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

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

RE: r313907 - Suppress Wsign-conversion for enums with matching underlying type

[Keane, Erich via cfe-commits]

Ugg... good catch, thanks.

-Original Message-
From: Friedman, Eli [mailto:efrie...@codeaurora.org] 
Sent: Thursday, September 21, 2017 1:14 PM
To: Keane, Erich ; cfe-commits@lists.llvm.org
Subject: Re: r313907 - Suppress Wsign-conversion for enums with matching 
underlying type

On 9/21/2017 12:58 PM, Erich Keane via cfe-commits wrote:
> Author: erichkeane
> Date: Thu Sep 21 12:58:55 2017
> New Revision: 313907
>
> URL: http://llvm.org/viewvc/llvm-project?rev=313907&view=rev
> Log:
> Suppress Wsign-conversion for enums with matching underlying type
>
> As reported here: https://bugs.llvm.org/show_bug.cgi?id=34692
>
> A non-defined enum with a backing type was always defaulting to being 
> treated as a signed type. IN the case where it IS defined, the 
> signed-ness of the actual items is used.
>
> This patch uses the underlying type's signed-ness in the non-defined 
> case to test signed-comparision.
>
> Differential Revision: https://reviews.llvm.org/D38145
>
> Modified:
>  cfe/trunk/lib/Sema/SemaChecking.cpp

Missing testcase?

-El

--
Employee of Qualcomm Innovation Center, Inc.
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, a Linux 
Foundation Collaborative Project

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

RE: r312542 - [Preprocessor] Correct internal token parsing of newline characters in CRLF

[Keane, Erich via cfe-commits]

There’s an existing test in r311683.  I’d initially implemented handling ‘\r\n’ 
as well as ‘\n\r’, but Reid had suggested that I simply handle the former.  I’d 
inadvertently contributed the previous revision.  I noticed this morning that 
I’d done so, so I corrected my commit.

From: tha...@google.com [mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Tuesday, September 5, 2017 1:47 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r312542 - [Preprocessor] Correct internal token parsing of newline 
characters in CRLF

Test?

On Tue, Sep 5, 2017 at 1:32 PM, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Tue Sep  5 10:32:36 2017
New Revision: 312542

URL: http://llvm.org/viewvc/llvm-project?rev=312542&view=rev
Log:
[Preprocessor] Correct internal token parsing of newline characters in CRLF

Correct implementation:  Apparently I managed in r311683 to submit the wrong
version of the patch for this, so I'm correcting it now.

Differential Revision: https://reviews.llvm.org/D37079

Modified:
cfe/trunk/lib/Lex/Lexer.cpp

Modified: cfe/trunk/lib/Lex/Lexer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/Lexer.cpp?rev=312542&r1=312541&r2=312542&view=diff
==
--- cfe/trunk/lib/Lex/Lexer.cpp (original)
+++ cfe/trunk/lib/Lex/Lexer.cpp Tue Sep  5 10:32:36 2017
@@ -3071,10 +3071,11 @@ LexNextToken:
 Kind = tok::unknown;
 break;

-  case '\n':
   case '\r':
-if (CurPtr[0] != Char && (CurPtr[0] == '\n' || CurPtr[0] == '\r'))
+if (CurPtr[0] == '\n')
   Char = getAndAdvanceChar(CurPtr, Result);
+LLVM_FALLTHROUGH;
+  case '\n':
 // If we are inside a preprocessor directive and we see the end of line,
 // we know we are done with the directive, so return an EOD token.
 if (ParsingPreprocessorDirective) {


___
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] D36707: [CodeGen]Refactor CpuSupports/CPUIs Builtin Code Gen to better work with "target" implementation

[Keane, Erich via cfe-commits]

Oops, totally forgot this got approved ☺  Thanks for the reminder!

From: Eric Christopher [mailto:echri...@gmail.com]
Sent: Friday, September 1, 2017 12:40 PM
To: reviews+d36707+public+aa8b48c258736...@reviews.llvm.org; Keane, Erich 
; llvm-...@redking.me.uk; craig.top...@gmail.com
Cc: cfe-commits@lists.llvm.org
Subject: Re: [PATCH] D36707: [CodeGen]Refactor CpuSupports/CPUIs Builtin Code 
Gen to better work with "target" implementation


Don't wait on me here.

On Thu, Aug 31, 2017, 10:53 PM Craig Topper via Phabricator 
mailto:revi...@reviews.llvm.org>> wrote:
craig.topper accepted this revision.
craig.topper added a comment.
This revision is now accepted and ready to land.

LGTM


https://reviews.llvm.org/D36707


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

RE: r311683 - [Preprocessor] Correct internal token parsing of newline characters in CRLF

[Keane, Erich via cfe-commits]

Alright, final update.  Thanks to some fantastic help on #llvm, I believe this 
is fixed.

Stephen: You may have to do some shenanigans to fix your local stuff, but the 
monorepo and another repo both seem to work.  Sorry for this everyone :/

From: Stephen Hines [mailto:srhi...@google.com]
Sent: Thursday, August 24, 2017 3:18 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r311683 - [Preprocessor] Correct internal token parsing of newline 
characters in CRLF

This change seems to have broken the git mirrors, as I can no longer check out 
clang without having a merge conflict as git alters the line endings. Setting 
core.autocrlf to false doesn't help either. Does anyone have any idea how to 
fix this svn <-> git issue?

Thanks,
Steve

On Thu, Aug 24, 2017 at 11:36 AM, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Thu Aug 24 11:36:07 2017
New Revision: 311683

URL: http://llvm.org/viewvc/llvm-project?rev=311683&view=rev
Log:
[Preprocessor] Correct internal token parsing of newline characters in CRLF

Discovered due to a goofy git setup, the test system-headerline-directive.c
(and a few others) failed because the token-consumption will consume only the
'\r' in CRLF, making the preprocessor's printed value give the wrong line number
when returning from an include. For example:

(line 1):#include \r\n

The "file exit" code causes the printer to try to print the 'returned to the
main file' line. It looks up what the current line number is. However, since the
current 'token' is the '\n' (since only the \r was consumed), it will give the
line number as '1", not '2'. This results in a few failed tests, but more
importantly, results in error messages being incorrect when compiling a
previously preprocessed file.

Differential Revision: https://reviews.llvm.org/D37079

Added:
cfe/trunk/test/Frontend/.gitattributes
cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c   
(with props)
Modified:
cfe/trunk/lib/Lex/Lexer.cpp

Modified: cfe/trunk/lib/Lex/Lexer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/Lexer.cpp?rev=311683&r1=311682&r2=311683&view=diff
==
--- cfe/trunk/lib/Lex/Lexer.cpp (original)
+++ cfe/trunk/lib/Lex/Lexer.cpp Thu Aug 24 11:36:07 2017
@@ -3073,6 +3073,8 @@ LexNextToken:

   case '\n':
   case '\r':
+if (CurPtr[0] != Char && (CurPtr[0] == '\n' || CurPtr[0] == '\r'))
+  Char = getAndAdvanceChar(CurPtr, Result);
 // If we are inside a preprocessor directive and we see the end of line,
 // we know we are done with the directive, so return an EOD token.
 if (ParsingPreprocessorDirective) {

Added: cfe/trunk/test/Frontend/.gitattributes
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/.gitattributes?rev=311683&view=auto
==
--- cfe/trunk/test/Frontend/.gitattributes (added)
+++ cfe/trunk/test/Frontend/.gitattributes Thu Aug 24 11:36:07 2017
@@ -0,0 +1,2 @@
+# Below test validates crlf line endings, so it should stay crlf.
+system-header-line-directive-ms-lineendings.c text eol=crlf

Added: cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c?rev=311683&view=auto
==
--- cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c 
(added)
+++ cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c Thu 
Aug 24 11:36:07 2017
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 %s -E -o - -I %S/Inputs -isystem 
%S/Inputs/SystemHeaderPrefix | FileCheck %s
+#include 
+#include 
+
+#include "line-directive.h"
+
+// This tests that the line numbers for the current file are correctly 
outputted
+// for the include-file-completed test case.
+
+// CHECK: # 1 "{{.*}}system-header-line-directive-ms-lineendings.c" 2
+// CHECK: # 1 "{{.*}}noline.h" 1 3
+// CHECK: foo();
+// CHECK: # 3 "{{.*}}system-header-line-directive-ms-lineendings.c" 2
+// CHECK: # 1 "{{.*}}line-directive-in-system.h" 1 3
+//  The "3" below indicates that "foo.h" is considered a system header.
+// CHECK: # 1 "foo.h" 3
+// CHECK: foo();
+// CHECK: # 4 "{{.*}}system-header-line-directive-ms-lineendings.c" 2
+// CHECK: # 1 "{{.*}}line-directive.h" 1
+// CHECK: # 10 "foo.h"{{$}}
+// CHECK: # 6 "{{.*}}system-header-line-directive-ms-lineendings.c" 2

Propchange: 
cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c
--
svn:eol-style = CRLF


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

_

RE: r311683 - [Preprocessor] Correct internal token parsing of newline characters in CRLF

[Keane, Erich via cfe-commits]

1 more dataset, Craig has the git mirror working right, but with the public 
mirror…

From: Stephen Hines [mailto:srhi...@google.com]
Sent: Thursday, August 24, 2017 3:18 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r311683 - [Preprocessor] Correct internal token parsing of newline 
characters in CRLF

This change seems to have broken the git mirrors, as I can no longer check out 
clang without having a merge conflict as git alters the line endings. Setting 
core.autocrlf to false doesn't help either. Does anyone have any idea how to 
fix this svn <-> git issue?

Thanks,
Steve

On Thu, Aug 24, 2017 at 11:36 AM, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Thu Aug 24 11:36:07 2017
New Revision: 311683

URL: http://llvm.org/viewvc/llvm-project?rev=311683&view=rev
Log:
[Preprocessor] Correct internal token parsing of newline characters in CRLF

Discovered due to a goofy git setup, the test system-headerline-directive.c
(and a few others) failed because the token-consumption will consume only the
'\r' in CRLF, making the preprocessor's printed value give the wrong line number
when returning from an include. For example:

(line 1):#include \r\n

The "file exit" code causes the printer to try to print the 'returned to the
main file' line. It looks up what the current line number is. However, since the
current 'token' is the '\n' (since only the \r was consumed), it will give the
line number as '1", not '2'. This results in a few failed tests, but more
importantly, results in error messages being incorrect when compiling a
previously preprocessed file.

Differential Revision: https://reviews.llvm.org/D37079

Added:
cfe/trunk/test/Frontend/.gitattributes
cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c   
(with props)
Modified:
cfe/trunk/lib/Lex/Lexer.cpp

Modified: cfe/trunk/lib/Lex/Lexer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/Lexer.cpp?rev=311683&r1=311682&r2=311683&view=diff
==
--- cfe/trunk/lib/Lex/Lexer.cpp (original)
+++ cfe/trunk/lib/Lex/Lexer.cpp Thu Aug 24 11:36:07 2017
@@ -3073,6 +3073,8 @@ LexNextToken:

   case '\n':
   case '\r':
+if (CurPtr[0] != Char && (CurPtr[0] == '\n' || CurPtr[0] == '\r'))
+  Char = getAndAdvanceChar(CurPtr, Result);
 // If we are inside a preprocessor directive and we see the end of line,
 // we know we are done with the directive, so return an EOD token.
 if (ParsingPreprocessorDirective) {

Added: cfe/trunk/test/Frontend/.gitattributes
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/.gitattributes?rev=311683&view=auto
==
--- cfe/trunk/test/Frontend/.gitattributes (added)
+++ cfe/trunk/test/Frontend/.gitattributes Thu Aug 24 11:36:07 2017
@@ -0,0 +1,2 @@
+# Below test validates crlf line endings, so it should stay crlf.
+system-header-line-directive-ms-lineendings.c text eol=crlf

Added: cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c?rev=311683&view=auto
==
--- cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c 
(added)
+++ cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c Thu 
Aug 24 11:36:07 2017
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 %s -E -o - -I %S/Inputs -isystem 
%S/Inputs/SystemHeaderPrefix | FileCheck %s
+#include 
+#include 
+
+#include "line-directive.h"
+
+// This tests that the line numbers for the current file are correctly 
outputted
+// for the include-file-completed test case.
+
+// CHECK: # 1 "{{.*}}system-header-line-directive-ms-lineendings.c" 2
+// CHECK: # 1 "{{.*}}noline.h" 1 3
+// CHECK: foo();
+// CHECK: # 3 "{{.*}}system-header-line-directive-ms-lineendings.c" 2
+// CHECK: # 1 "{{.*}}line-directive-in-system.h" 1 3
+//  The "3" below indicates that "foo.h" is considered a system header.
+// CHECK: # 1 "foo.h" 3
+// CHECK: foo();
+// CHECK: # 4 "{{.*}}system-header-line-directive-ms-lineendings.c" 2
+// CHECK: # 1 "{{.*}}line-directive.h" 1
+// CHECK: # 10 "foo.h"{{$}}
+// CHECK: # 6 "{{.*}}system-header-line-directive-ms-lineendings.c" 2

Propchange: 
cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c
--
svn:eol-style = CRLF


___
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: r311683 - [Preprocessor] Correct internal token parsing of newline characters in CRLF

[Keane, Erich via cfe-commits]

Hi Stephen-
I’m digging through this, and it seems odd.  SVN seems to store it with the 
CRLF line endings.  The Git mirror for some reason is not paying attention to 
the svn file attribute.  However, the .gitattribute file seems to convert it to 
the CRLF endings (as it should be), but it seems to think I’ve modified it now.

Are you seeing the same symptom?

From: Stephen Hines [mailto:srhi...@google.com]
Sent: Thursday, August 24, 2017 3:18 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r311683 - [Preprocessor] Correct internal token parsing of newline 
characters in CRLF

This change seems to have broken the git mirrors, as I can no longer check out 
clang without having a merge conflict as git alters the line endings. Setting 
core.autocrlf to false doesn't help either. Does anyone have any idea how to 
fix this svn <-> git issue?

Thanks,
Steve

On Thu, Aug 24, 2017 at 11:36 AM, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Thu Aug 24 11:36:07 2017
New Revision: 311683

URL: http://llvm.org/viewvc/llvm-project?rev=311683&view=rev
Log:
[Preprocessor] Correct internal token parsing of newline characters in CRLF

Discovered due to a goofy git setup, the test system-headerline-directive.c
(and a few others) failed because the token-consumption will consume only the
'\r' in CRLF, making the preprocessor's printed value give the wrong line number
when returning from an include. For example:

(line 1):#include \r\n

The "file exit" code causes the printer to try to print the 'returned to the
main file' line. It looks up what the current line number is. However, since the
current 'token' is the '\n' (since only the \r was consumed), it will give the
line number as '1", not '2'. This results in a few failed tests, but more
importantly, results in error messages being incorrect when compiling a
previously preprocessed file.

Differential Revision: https://reviews.llvm.org/D37079

Added:
cfe/trunk/test/Frontend/.gitattributes
cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c   
(with props)
Modified:
cfe/trunk/lib/Lex/Lexer.cpp

Modified: cfe/trunk/lib/Lex/Lexer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/Lexer.cpp?rev=311683&r1=311682&r2=311683&view=diff
==
--- cfe/trunk/lib/Lex/Lexer.cpp (original)
+++ cfe/trunk/lib/Lex/Lexer.cpp Thu Aug 24 11:36:07 2017
@@ -3073,6 +3073,8 @@ LexNextToken:

   case '\n':
   case '\r':
+if (CurPtr[0] != Char && (CurPtr[0] == '\n' || CurPtr[0] == '\r'))
+  Char = getAndAdvanceChar(CurPtr, Result);
 // If we are inside a preprocessor directive and we see the end of line,
 // we know we are done with the directive, so return an EOD token.
 if (ParsingPreprocessorDirective) {

Added: cfe/trunk/test/Frontend/.gitattributes
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/.gitattributes?rev=311683&view=auto
==
--- cfe/trunk/test/Frontend/.gitattributes (added)
+++ cfe/trunk/test/Frontend/.gitattributes Thu Aug 24 11:36:07 2017
@@ -0,0 +1,2 @@
+# Below test validates crlf line endings, so it should stay crlf.
+system-header-line-directive-ms-lineendings.c text eol=crlf

Added: cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c?rev=311683&view=auto
==
--- cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c 
(added)
+++ cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c Thu 
Aug 24 11:36:07 2017
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 %s -E -o - -I %S/Inputs -isystem 
%S/Inputs/SystemHeaderPrefix | FileCheck %s
+#include 
+#include 
+
+#include "line-directive.h"
+
+// This tests that the line numbers for the current file are correctly 
outputted
+// for the include-file-completed test case.
+
+// CHECK: # 1 "{{.*}}system-header-line-directive-ms-lineendings.c" 2
+// CHECK: # 1 "{{.*}}noline.h" 1 3
+// CHECK: foo();
+// CHECK: # 3 "{{.*}}system-header-line-directive-ms-lineendings.c" 2
+// CHECK: # 1 "{{.*}}line-directive-in-system.h" 1 3
+//  The "3" below indicates that "foo.h" is considered a system header.
+// CHECK: # 1 "foo.h" 3
+// CHECK: foo();
+// CHECK: # 4 "{{.*}}system-header-line-directive-ms-lineendings.c" 2
+// CHECK: # 1 "{{.*}}line-directive.h" 1
+// CHECK: # 10 "foo.h"{{$}}
+// CHECK: # 6 "{{.*}}system-header-line-directive-ms-lineendings.c" 2

Propchange: 
cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c
--
svn:eol-style = CRLF


___
cfe-commits mailing list
cfe-commits@lists.llvm.org

RE: r311683 - [Preprocessor] Correct internal token parsing of newline characters in CRLF

[Keane, Erich via cfe-commits]

Can you better clarify what went wrong?  I included a ‘.gitattriutes’ that 
matches only the new test that is supposed to keep it as CLRF


From: Stephen Hines [mailto:srhi...@google.com]
Sent: Thursday, August 24, 2017 3:18 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r311683 - [Preprocessor] Correct internal token parsing of newline 
characters in CRLF

This change seems to have broken the git mirrors, as I can no longer check out 
clang without having a merge conflict as git alters the line endings. Setting 
core.autocrlf to false doesn't help either. Does anyone have any idea how to 
fix this svn <-> git issue?

Thanks,
Steve

On Thu, Aug 24, 2017 at 11:36 AM, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Thu Aug 24 11:36:07 2017
New Revision: 311683

URL: http://llvm.org/viewvc/llvm-project?rev=311683&view=rev
Log:
[Preprocessor] Correct internal token parsing of newline characters in CRLF

Discovered due to a goofy git setup, the test system-headerline-directive.c
(and a few others) failed because the token-consumption will consume only the
'\r' in CRLF, making the preprocessor's printed value give the wrong line number
when returning from an include. For example:

(line 1):#include \r\n

The "file exit" code causes the printer to try to print the 'returned to the
main file' line. It looks up what the current line number is. However, since the
current 'token' is the '\n' (since only the \r was consumed), it will give the
line number as '1", not '2'. This results in a few failed tests, but more
importantly, results in error messages being incorrect when compiling a
previously preprocessed file.

Differential Revision: https://reviews.llvm.org/D37079

Added:
cfe/trunk/test/Frontend/.gitattributes
cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c   
(with props)
Modified:
cfe/trunk/lib/Lex/Lexer.cpp

Modified: cfe/trunk/lib/Lex/Lexer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/Lexer.cpp?rev=311683&r1=311682&r2=311683&view=diff
==
--- cfe/trunk/lib/Lex/Lexer.cpp (original)
+++ cfe/trunk/lib/Lex/Lexer.cpp Thu Aug 24 11:36:07 2017
@@ -3073,6 +3073,8 @@ LexNextToken:

   case '\n':
   case '\r':
+if (CurPtr[0] != Char && (CurPtr[0] == '\n' || CurPtr[0] == '\r'))
+  Char = getAndAdvanceChar(CurPtr, Result);
 // If we are inside a preprocessor directive and we see the end of line,
 // we know we are done with the directive, so return an EOD token.
 if (ParsingPreprocessorDirective) {

Added: cfe/trunk/test/Frontend/.gitattributes
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/.gitattributes?rev=311683&view=auto
==
--- cfe/trunk/test/Frontend/.gitattributes (added)
+++ cfe/trunk/test/Frontend/.gitattributes Thu Aug 24 11:36:07 2017
@@ -0,0 +1,2 @@
+# Below test validates crlf line endings, so it should stay crlf.
+system-header-line-directive-ms-lineendings.c text eol=crlf

Added: cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c?rev=311683&view=auto
==
--- cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c 
(added)
+++ cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c Thu 
Aug 24 11:36:07 2017
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 %s -E -o - -I %S/Inputs -isystem 
%S/Inputs/SystemHeaderPrefix | FileCheck %s
+#include 
+#include 
+
+#include "line-directive.h"
+
+// This tests that the line numbers for the current file are correctly 
outputted
+// for the include-file-completed test case.
+
+// CHECK: # 1 "{{.*}}system-header-line-directive-ms-lineendings.c" 2
+// CHECK: # 1 "{{.*}}noline.h" 1 3
+// CHECK: foo();
+// CHECK: # 3 "{{.*}}system-header-line-directive-ms-lineendings.c" 2
+// CHECK: # 1 "{{.*}}line-directive-in-system.h" 1 3
+//  The "3" below indicates that "foo.h" is considered a system header.
+// CHECK: # 1 "foo.h" 3
+// CHECK: foo();
+// CHECK: # 4 "{{.*}}system-header-line-directive-ms-lineendings.c" 2
+// CHECK: # 1 "{{.*}}line-directive.h" 1
+// CHECK: # 10 "foo.h"{{$}}
+// CHECK: # 6 "{{.*}}system-header-line-directive-ms-lineendings.c" 2

Propchange: 
cfe/trunk/test/Frontend/system-header-line-directive-ms-lineendings.c
--
svn:eol-style = CRLF


___
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

RE: r306149 - Emit warning when throw exception in destruct or dealloc functions which has a

[Keane, Erich via cfe-commits]

Hi Richard:
I’m not sure if you noticed this, but my coworker did submit a review here: 
https://reviews.llvm.org/D34671 with the changes you suggested.

Thanks,
Erich

From: meta...@gmail.com [mailto:meta...@gmail.com] On Behalf Of Richard Smith
Sent: Monday, June 26, 2017 2:25 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r306149 - Emit warning when throw exception in destruct or dealloc 
functions which has a

On 23 June 2017 at 13:22, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Fri Jun 23 15:22:19 2017
New Revision: 306149

URL: http://llvm.org/viewvc/llvm-project?rev=306149&view=rev
Log:
Emit warning when throw exception in destruct or dealloc functions which has a
(possible implicit) noexcept specifier

Throwing in the destructor is not good (C++11 change try to not allow see 
below).
 But in reality, those codes are exist.
C++11 [class.dtor]p3:

A declaration of a destructor that does not have an exception-specification is
implicitly considered to have the same exception specification as an implicit
declaration.

With this change, the application worked before may now run into runtime
termination. My goal here is to emit a warning to provide only possible info to
where the code may need to be changed.

First there is no way, in compile time to identify the “throw” really throw out
of the function. Things like the call which throw out… To keep this simple,
when “throw” is seen, checking its enclosing function(only destructor and
dealloc functions) with noexcept(true) specifier emit warning.

Here is implementation detail:
A new member function CheckCXXThrowInNonThrowingFunc is added for class Sema
in Sema.h. It is used in the call to both BuildCXXThrow and
TransformCXXThrowExpr.

The function basic check if the enclosing function with non-throwing noexcept
specifer, if so emit warning for it.

The example of warning message like:
k1.cpp:18:3: warning: ''~dependent_warn'' has a (possible implicit) non-throwing

noexcept specifier. Throwing exception may cause termination.
[-Wthrow-in-dtor]
throw 1;
^

k1.cpp:43:30: note: in instantiation of member function

'dependent_warn::~dependent_warn' requested here

dependent_warn f; // cause warning

Differential Revision: https://reviews.llvm.org/D3


Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp
cfe/trunk/test/CXX/except/except.spec/p11.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=306149&r1=306148&r2=306149&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Jun 23 15:22:19 
2017
@@ -6351,6 +6351,15 @@ def err_exceptions_disabled : Error<
   "cannot use '%0' with exceptions disabled">;
 def err_objc_exceptions_disabled : Error<
   "cannot use '%0' with Objective-C exceptions disabled">;
+def warn_throw_in_noexcept_func
+: Warning<"%0 has a non-throwing exception specification but can still "
+  "throw, resulting in unexpected program termination">,

How do you know it's unexpected? :) You also don't know that this leads to 
program termination: a set_unexpected handler could do something else, in 
principle. I would just delete the ", resulting in unexpected program 
termination" part here.

+  InGroup;
+def note_throw_in_dtor
+: Note<"destructor or deallocator has a (possibly implicit) non-throwing "
+  "excepton specification">;

Please figure out which case we're actually in, and just mention that one. You 
can use "hasImplicitExceptionSpec" in SemaExceptionSpec.cpp to determine 
whether the exception specification is implicit.

Also, typo "excepton".

+def note_throw_in_function
+: Note<"non-throwing function declare here">;

declare -> declared, but something like "function declared non-throwing here" 
would be preferable

 def err_seh_try_outside_functions : Error<
   "cannot use SEH '__try' in blocks, captured regions, or Obj-C method decls">;
 def err_mixing_cxx_try_seh_try : Error<

Modified: cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp?rev=306149&r1=306148&r2=306149&view=diff
==
--- cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp (original)
+++ cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp Fri Jun 23 15:22:19 2017
@@ -279,6 +279,150 @@ static void checkRecursiveFunction(Sema
 }

 
//===--===//
+// Check for throw in a non-throwing function.
+//===--===//
+enum ThrowSta

RE: r306149 - Emit warning when throw exception in destruct or dealloc functions which has a

[Keane, Erich via cfe-commits]

Sorry Richard, I thought I gave you enough time before committing this for Jen.

Adding her so she can respond to your comments and fix these.

Thanks,
Erich

From: meta...@gmail.com [mailto:meta...@gmail.com] On Behalf Of Richard Smith
Sent: Monday, June 26, 2017 2:25 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r306149 - Emit warning when throw exception in destruct or dealloc 
functions which has a

On 23 June 2017 at 13:22, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Fri Jun 23 15:22:19 2017
New Revision: 306149

URL: http://llvm.org/viewvc/llvm-project?rev=306149&view=rev
Log:
Emit warning when throw exception in destruct or dealloc functions which has a
(possible implicit) noexcept specifier

Throwing in the destructor is not good (C++11 change try to not allow see 
below).
 But in reality, those codes are exist.
C++11 [class.dtor]p3:

A declaration of a destructor that does not have an exception-specification is
implicitly considered to have the same exception specification as an implicit
declaration.

With this change, the application worked before may now run into runtime
termination. My goal here is to emit a warning to provide only possible info to
where the code may need to be changed.

First there is no way, in compile time to identify the “throw” really throw out
of the function. Things like the call which throw out… To keep this simple,
when “throw” is seen, checking its enclosing function(only destructor and
dealloc functions) with noexcept(true) specifier emit warning.

Here is implementation detail:
A new member function CheckCXXThrowInNonThrowingFunc is added for class Sema
in Sema.h. It is used in the call to both BuildCXXThrow and
TransformCXXThrowExpr.

The function basic check if the enclosing function with non-throwing noexcept
specifer, if so emit warning for it.

The example of warning message like:
k1.cpp:18:3: warning: ''~dependent_warn'' has a (possible implicit) non-throwing

noexcept specifier. Throwing exception may cause termination.
[-Wthrow-in-dtor]
throw 1;
^

k1.cpp:43:30: note: in instantiation of member function

'dependent_warn::~dependent_warn' requested here

dependent_warn f; // cause warning

Differential Revision: https://reviews.llvm.org/D3


Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp
cfe/trunk/test/CXX/except/except.spec/p11.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=306149&r1=306148&r2=306149&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Jun 23 15:22:19 
2017
@@ -6351,6 +6351,15 @@ def err_exceptions_disabled : Error<
   "cannot use '%0' with exceptions disabled">;
 def err_objc_exceptions_disabled : Error<
   "cannot use '%0' with Objective-C exceptions disabled">;
+def warn_throw_in_noexcept_func
+: Warning<"%0 has a non-throwing exception specification but can still "
+  "throw, resulting in unexpected program termination">,

How do you know it's unexpected? :) You also don't know that this leads to 
program termination: a set_unexpected handler could do something else, in 
principle. I would just delete the ", resulting in unexpected program 
termination" part here.

+  InGroup;
+def note_throw_in_dtor
+: Note<"destructor or deallocator has a (possibly implicit) non-throwing "
+  "excepton specification">;

Please figure out which case we're actually in, and just mention that one. You 
can use "hasImplicitExceptionSpec" in SemaExceptionSpec.cpp to determine 
whether the exception specification is implicit.

Also, typo "excepton".

+def note_throw_in_function
+: Note<"non-throwing function declare here">;

declare -> declared, but something like "function declared non-throwing here" 
would be preferable

 def err_seh_try_outside_functions : Error<
   "cannot use SEH '__try' in blocks, captured regions, or Obj-C method decls">;
 def err_mixing_cxx_try_seh_try : Error<

Modified: cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp?rev=306149&r1=306148&r2=306149&view=diff
==
--- cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp (original)
+++ cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp Fri Jun 23 15:22:19 2017
@@ -279,6 +279,150 @@ static void checkRecursiveFunction(Sema
 }

 
//===--===//
+// Check for throw in a non-throwing function.
+//===--===//
+enum ThrowState {
+  Fo

RE: [PATCH] D32046: [Preprocessor]Correct Macro-Arg allocation of StringifiedArguments, correct getNumArguments

[Keane, Erich via cfe-commits]

Thanks for the heads up!  Fixed in 305491.  Turns out a function that 
AllocateMacroInfo returns a pointer, but the PP still owns it.  
MacroArgs::create returns a pointer, and expects the user to delete it.  I 
added a unique_ptr with a custom delete to call the macro-args 'destroy' 
function. 

-Original Message-
From: Kostya Serebryany via Phabricator [mailto:revi...@reviews.llvm.org] 
Sent: Thursday, June 15, 2017 10:44 AM
To: Keane, Erich ; r...@google.com; 
rich...@metafoo.co.uk; arpha...@gmail.com
Cc: k...@google.com; cfe-commits@lists.llvm.org
Subject: [PATCH] D32046: [Preprocessor]Correct Macro-Arg allocation of 
StringifiedArguments, correct getNumArguments

kcc added a comment.

the bots complain about a leak in the new test code. 
Please fix/revert ASAP. 
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/5691/steps/check-clang%20asan/logs/stdio

28905==ERROR: LeakSanitizer: detected memory leaks 
==

Direct leak of 216 byte(s) in 1 object(s) allocated from:

  #0 0x4eca08 in __interceptor_malloc 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:66
  #1 0xefcb8f in clang::MacroArgs::create(clang::MacroInfo const*, 
llvm::ArrayRef, bool, clang::Preprocessor&) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Lex/MacroArgs.cpp:51:27
  #2 0x54dc56 in (anonymous 
namespace)::LexerTest_DontOverallocateStringifyArgs_Test::TestBody() 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/unittests/Lex/LexerTest.cpp:405:19
  #3 0x65154e in HandleExceptionsInMethodIfSupported 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2458:12
  #4 0x65154e in testing::Test::Run() 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2474
  #5 0x653848 in testing::TestInfo::Run() 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11
  #6 0x654b86 in testing::TestCase::Run() 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28
  #7 0x675586 in testing::internal::UnitTestImpl::RunAllTests() 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43
  #8 0x67487e in 
HandleExceptionsInMethodIfSupported 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2458:12
  #9 0x67487e in testing::UnitTest::Run() 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:4257
  #10 0x634bfe in RUN_ALL_TESTS 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46
  #11 0x634bfe in main 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:51
  #12 0x7f016e9cb82f in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)


Repository:
  rL LLVM

https://reviews.llvm.org/D32046



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

RE: r305425 - [Preprocessor]Correct Macro-Arg allocation of StringifiedArguments,

[Keane, Erich via cfe-commits]

Ah, right… This function mallocs, and is usually tossed in the Preprocessor 
Cache, but I’m doing an end-run around that this time.  I’ll see if it is 
better to put it into the PP Cache, or just call ‘free’ on it.

Thanks!
-Erich

From: Kostya Serebryany [mailto:k...@google.com]
Sent: Thursday, June 15, 2017 10:44 AM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r305425 - [Preprocessor]Correct Macro-Arg allocation of 
StringifiedArguments,

the bots complain about a leak in the new test code.
Please fix/revert ASAP.
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/5691/steps/check-clang%20asan/logs/stdio

=28905==ERROR: LeakSanitizer: detected memory leaks



Direct leak of 216 byte(s) in 1 object(s) allocated from:

#0 0x4eca08 in __interceptor_malloc 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/projects/compiler-rt/lib/asan/asan_malloc_linux.cc:66

#1 0xefcb8f in clang::MacroArgs::create(clang::MacroInfo const*, 
llvm::ArrayRef, bool, clang::Preprocessor&) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Lex/MacroArgs.cpp:51:27

#2 0x54dc56 in (anonymous 
namespace)::LexerTest_DontOverallocateStringifyArgs_Test::TestBody() 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/unittests/Lex/LexerTest.cpp:405:19

#3 0x65154e in HandleExceptionsInMethodIfSupported 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2458:12

#4 0x65154e in testing::Test::Run() 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2474

#5 0x653848 in testing::TestInfo::Run() 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2656:11

#6 0x654b86 in testing::TestCase::Run() 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2774:28

#7 0x675586 in testing::internal::UnitTestImpl::RunAllTests() 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:4649:43

#8 0x67487e in 
HandleExceptionsInMethodIfSupported 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:2458:12

#9 0x67487e in testing::UnitTest::Run() 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/src/gtest.cc:4257

#10 0x634bfe in RUN_ALL_TESTS 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/googletest/include/gtest/gtest.h:2233:46

#11 0x634bfe in main 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/utils/unittest/UnitTestMain/TestMain.cpp:51

#12 0x7f016e9cb82f in __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x2082f)


On Wed, Jun 14, 2017 at 4:09 PM, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Wed Jun 14 18:09:01 2017
New Revision: 305425

URL: http://llvm.org/viewvc/llvm-project?rev=305425&view=rev
Log:
[Preprocessor]Correct Macro-Arg allocation of StringifiedArguments,
correct getNumArguments

StringifiedArguments is allocated (resized) based on the size the
getNumArguments function. However, this function ACTUALLY currently
returns the amount of total UnexpArgTokens which is minimum the same as
the new implementation of getNumMacroArguments, since empty/omitted arguments
result in 1 UnexpArgToken, and included ones at minimum include 2
(1 for the arg itself, 1 for eof).

This patch renames the otherwise unused getNumArguments to be more clear
that it is the number of arguments that the Macro expects, and thus the maximum
number that can be stringified. This patch also replaces the explicit memset
(which results in value instantiation of the new tokens, PLUS clearing the
memory) with brace initialization.

Differential Revision: https://reviews.llvm.org/D32046

Modified:
cfe/trunk/include/clang/Lex/MacroArgs.h
cfe/trunk/lib/Lex/MacroArgs.cpp
cfe/trunk/unittests/Lex/LexerTest.cpp

Modified: cfe/trunk/include/clang/Lex/MacroArgs.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Lex/MacroArgs.h?rev=305425&r1=305424&r2=305425&view=diff
==
--- cfe/trunk/include/clang/Lex/MacroArgs.h (original)
+++ cfe/trunk/include/clang/Lex/MacroArgs.h Wed Jun 14 18:09:01 2017
@@ -53,9 +53,12 @@ class MacroArgs {
   /// Preprocessor owns which we use to avoid thrashing malloc/free.
   MacroArgs *ArgCache;

-  MacroArgs(unsigned NumToks, bool varargsElided)
-: NumUnexpArgTokens(NumToks), VarargsElided(varargsElided),
-  ArgCache(nullptr) {}
+  /// MacroArgs - The number of arguments the invoked macro expects.
+  unsigned NumMacroArgs;
+
+  MacroArgs(unsigned NumToks, bool varargsElided, unsigned MacroArgs)
+  : NumUnexpArgTokens(NumToks), VarargsE

RE: r305087 - support operator keywords used in Windows SDK

[Keane, Erich via cfe-commits]

Should be fixed as of here: https://reviews.llvm.org/rL305128 .   Curious that 
none of the other tests found this, but thankfully UBSan did!  

Committed as no-wait due to the breakage and not wanting to leave it broken 
over the weekend.

-Original Message-
From: Evgenii Stepanov [mailto:eugeni.stepa...@gmail.com] 
Sent: Friday, June 9, 2017 3:00 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r305087 - support operator keywords used in Windows SDK

Hi,

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/5571/steps/check-clang%20ubsan/logs/stdio

tools/clang/lib/Parse/ParseExprCXX.cpp:383:26: runtime error:
reference binding to null pointer of type 'clang::IdentifierInfo'
#0 0x5313046 in
clang::Parser::ParseOptionalCXXScopeSpecifier(clang::CXXScopeSpec&,
clang::OpaquePtr, bool, bool*, bool, clang::IdentifierInfo**, 
bool)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseExprCXX.cpp:383:21
#1 0x52d3dc7 in
clang::Parser::ParseDirectDeclarator(clang::Declarator&)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDecl.cpp:5433:7
#2 0x52d349d in
clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void
(clang::Parser::*)(clang::Declarator&))
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDecl.cpp:5254:7
#3 0x52ee74c in
clang::Parser::ParseCXXMemberDeclaratorBeforeInitializer(clang::Declarator&,
clang::VirtSpecifiers&, clang::ActionResult&,
clang::Parser::LateParsedAttrList&)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:2248:5
#4 0x52efaef in
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&,
clang::ParsingDeclRAIIObject*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:2619:7
#5 0x52f147a in
clang::Parser::ParseCXXClassMemberDeclarationWithPragmas(clang::AccessSpecifier&,
clang::Parser::ParsedAttributesWithRange&, clang::TypeSpecifierType,
clang::Decl*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:3079:12
#6 0x52ed276 in
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation,
clang::SourceLocation, clang::Parser::ParsedAttributesWithRange&,
unsigned int, clang::Decl*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:3250:7
#7 0x52eb9ad in
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo 
const&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext,
clang::Parser::ParsedAttributesWithRange&)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:1910:7
#8 0x52c8c41 in
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, 
clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDecl.cpp:3588:7
#9 0x52ef702 in
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&,
clang::ParsingDeclRAIIObject*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:2550:3
#10 0x52f147a in
clang::Parser::ParseCXXClassMemberDeclarationWithPragmas(clang::AccessSpecifier&,
clang::Parser::ParsedAttributesWithRange&, clang::TypeSpecifierType,
clang::Decl*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:3079:12
#11 0x52ed276 in
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation,
clang::SourceLocation, clang::Parser::ParsedAttributesWithRange&,
unsigned int, clang::Decl*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:3250:7
#12 0x52eb9ad in
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo 
const&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext,
clang::Parser::ParsedAttributesWithRange&)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:1910:7
#13 0x52c8c41 in
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, 
clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDecl.cpp:3588:7
#14 0x52a89c6 in
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::Par

RE: r305087 - support operator keywords used in Windows SDK

[Keane, Erich via cfe-commits]

Thanks, I didn't notice that one.  Looking into it.

-Erich

-Original Message-
From: Evgenii Stepanov [mailto:eugeni.stepa...@gmail.com] 
Sent: Friday, June 9, 2017 3:00 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: Re: r305087 - support operator keywords used in Windows SDK

Hi,

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/5571/steps/check-clang%20ubsan/logs/stdio

tools/clang/lib/Parse/ParseExprCXX.cpp:383:26: runtime error:
reference binding to null pointer of type 'clang::IdentifierInfo'
#0 0x5313046 in
clang::Parser::ParseOptionalCXXScopeSpecifier(clang::CXXScopeSpec&,
clang::OpaquePtr, bool, bool*, bool, clang::IdentifierInfo**, 
bool)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseExprCXX.cpp:383:21
#1 0x52d3dc7 in
clang::Parser::ParseDirectDeclarator(clang::Declarator&)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDecl.cpp:5433:7
#2 0x52d349d in
clang::Parser::ParseDeclaratorInternal(clang::Declarator&, void
(clang::Parser::*)(clang::Declarator&))
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDecl.cpp:5254:7
#3 0x52ee74c in
clang::Parser::ParseCXXMemberDeclaratorBeforeInitializer(clang::Declarator&,
clang::VirtSpecifiers&, clang::ActionResult&,
clang::Parser::LateParsedAttrList&)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:2248:5
#4 0x52efaef in
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&,
clang::ParsingDeclRAIIObject*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:2619:7
#5 0x52f147a in
clang::Parser::ParseCXXClassMemberDeclarationWithPragmas(clang::AccessSpecifier&,
clang::Parser::ParsedAttributesWithRange&, clang::TypeSpecifierType,
clang::Decl*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:3079:12
#6 0x52ed276 in
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation,
clang::SourceLocation, clang::Parser::ParsedAttributesWithRange&,
unsigned int, clang::Decl*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:3250:7
#7 0x52eb9ad in
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo 
const&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext,
clang::Parser::ParsedAttributesWithRange&)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:1910:7
#8 0x52c8c41 in
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, 
clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDecl.cpp:3588:7
#9 0x52ef702 in
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&,
clang::ParsingDeclRAIIObject*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:2550:3
#10 0x52f147a in
clang::Parser::ParseCXXClassMemberDeclarationWithPragmas(clang::AccessSpecifier&,
clang::Parser::ParsedAttributesWithRange&, clang::TypeSpecifierType,
clang::Decl*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:3079:12
#11 0x52ed276 in
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation,
clang::SourceLocation, clang::Parser::ParsedAttributesWithRange&,
unsigned int, clang::Decl*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:3250:7
#12 0x52eb9ad in
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo 
const&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext,
clang::Parser::ParsedAttributesWithRange&)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:1910:7
#13 0x52c8c41 in
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, 
clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDecl.cpp:3588:7
#14 0x52a89c6 in
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier)
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/Parser.cpp:912:3
#15 0x52a8542 in
clang::Parser::

RE: r303798 - For Microsoft compatibility, set fno_operator_names

[Keane, Erich via cfe-commits]

No problem, I definitely think it was the right choice.

A change that contains all of what Melanie’s original patch did, plus the 
Header changes (plus the clang-tidy fixes that came out of this) would be 
acceptable?

Also, I believe she’s working on the warning as well.  We were discussing it, 
and I was thinking that if we track down where the operator-identification is 
done (hints as to where that is is appreciated), that we could simply warn if 
the user is using one of the Operators with operators off.  The warning itself 
could then be suppressed if necessary.

Thoughts?


From: Nico Weber [mailto:tha...@google.com]
Sent: Thursday, May 25, 2017 9:56 AM
To: Keane, Erich 
Cc: Blower, Melanie ; rnk ; 
cfe-commits ; Hans Wennborg 
Subject: Re: r303798 - For Microsoft compatibility, set fno_operator_names

On Thu, May 25, 2017 at 12:18 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
How does chromium compiler in CL?  It seems that it would have a similar 
problem here…

That's a good question! It looks like iso646.h is included, and in MSVC that 
contains something like `#define and &&`. But clang's lib/Headers/iso646.h 
assumes that the compiler provides this and doesn't define `and`. So for the 
reland, that header would have to check if the operator name is disabled, and 
if so, define it. (Or, better, maybe we can come up with something more 
targeted for the system header, similar to e.g. 
http://llvm.org/viewvc/llvm-project?view=revision&revision=212238)

Thanks for the revert!


From: tha...@google.com 
[mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Thursday, May 25, 2017 9:16 AM
To: Blower, Melanie mailto:melanie.blo...@intel.com>>
Cc: rnk mailto:r...@chromium.org>>; Keane, Erich 
mailto:erich.ke...@intel.com>>; cfe-commits 
mailto:cfe-commits@lists.llvm.org>>; Hans Wennborg 
mailto:h...@chromium.org>>

Subject: RE: r303798 - For Microsoft compatibility, set fno_operator_names

In addition to this making clang-cl silently accept invalid code, it also 
breaks existing valid code, building chromium now fails. Let's revert and come 
up with something better asynchronously.

FAILED: obj/third_party/WebKit/Source/core/dom/dom/CustomElementRegistry.obj
E:\b\c\goma_client/gomacc.exe 
../../third_party/llvm-build/Release+Asserts/bin/clang-cl.exe /nologo 
/showIncludes /FC 
@obj/third_party/WebKit/Source/core/dom/dom/CustomElementRegistry.obj.rsp /c 
../../third_party/WebKit/Source/core/dom/custom/CustomElementRegistry.cpp 
/Foobj/third_party/WebKit/Source/core/dom/dom/CustomElementRegistry.obj 
/Fd"obj/third_party/WebKit/Source/core/dom/dom_cc.pdb"
E:\b\c\b\win_clang\src\third_party\WebKit\Source\core\dom\custom\CustomElementRegistry.cpp(229,7):
  error: unknown type name 'definition'
  if (definition and definition->Descriptor().LocalName() == desc.LocalName()) {
  ^
E:\b\c\b\win_clang\src\third_party\WebKit\Source\core\dom\custom\CustomElementRegistry.cpp(229,18):
  error: variable declaration in condition must have an initializer
  if (definition and definition->Descriptor().LocalName() == desc.LocalName()) {
 ^
2 errors generated.


On May 24, 2017 4:01 PM, "Blower, Melanie" 
mailto:melanie.blo...@intel.com>> wrote:
Thanks for the feedback, working on it…

From: Keane, Erich
Sent: Wednesday, May 24, 2017 3:47 PM
To: Nico Weber mailto:tha...@chromium.org>>; Blower, 
Melanie mailto:melanie.blo...@intel.com>>

Cc: cfe-commits 
mailto:cfe-commits@lists.llvm.org>>; rnk 
mailto:r...@chromium.org>>
Subject: RE: r303798 - For Microsoft compatibility, set fno_operator_names

Adding Melanie, the author of the patch.

From: tha...@google.com [mailto:tha...@google.com] On 
Behalf Of Nico Weber
Sent: Wednesday, May 24, 2017 12:43 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: cfe-commits 
mailto:cfe-commits@lists.llvm.org>>; rnk 
mailto:r...@chromium.org>>
Subject: Re: r303798 - For Microsoft compatibility, set fno_operator_names

Reviewed here: https://reviews.llvm.org/D33505

Still, please make this warn.

On Wed, May 24, 2017 at 3:42 PM, Nico Weber 
mailto:tha...@google.com>> wrote:
Was this reviewed somewhere?

Please make it so that this emits a warning. We want clang-cl to warn on 
invalid code (and in system headers warnings are suppressed).

On Wed, May 24, 2017 at 3:31 PM, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Wed May 24 14:31:19 2017
New Revision: 303798

URL: http://llvm.org/viewvc/llvm-project?rev=303798&view=rev
Log:
For Microsoft compatibility, set fno_operator_names

There's a Microsoft header in the Windows SDK which won't
compile with clang because it uses an operator name (and)
as a field name. This patch allows that file to compile by
setting the option which disables operator names.
The header which doesn't compile  C:/Program Files (x86)/
Windows Kits/10/include/10.0.14393.0/um\Query.h:259:40:
error: expected m

RE: r303798 - For Microsoft compatibility, set fno_operator_names

[Keane, Erich via cfe-commits]

Patch and Buildbot fixes all reverted as of –r303882.  Sorry for the thrash.

From: tha...@google.com [mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Thursday, May 25, 2017 9:16 AM
To: Blower, Melanie 
Cc: rnk ; Keane, Erich ; cfe-commits 
; Hans Wennborg 
Subject: RE: r303798 - For Microsoft compatibility, set fno_operator_names

In addition to this making clang-cl silently accept invalid code, it also 
breaks existing valid code, building chromium now fails. Let's revert and come 
up with something better asynchronously.

FAILED: obj/third_party/WebKit/Source/core/dom/dom/CustomElementRegistry.obj
E:\b\c\goma_client/gomacc.exe 
../../third_party/llvm-build/Release+Asserts/bin/clang-cl.exe /nologo 
/showIncludes /FC 
@obj/third_party/WebKit/Source/core/dom/dom/CustomElementRegistry.obj.rsp /c 
../../third_party/WebKit/Source/core/dom/custom/CustomElementRegistry.cpp 
/Foobj/third_party/WebKit/Source/core/dom/dom/CustomElementRegistry.obj 
/Fd"obj/third_party/WebKit/Source/core/dom/dom_cc.pdb"
E:\b\c\b\win_clang\src\third_party\WebKit\Source\core\dom\custom\CustomElementRegistry.cpp(229,7):
  error: unknown type name 'definition'
  if (definition and definition->Descriptor().LocalName() == desc.LocalName()) {
  ^
E:\b\c\b\win_clang\src\third_party\WebKit\Source\core\dom\custom\CustomElementRegistry.cpp(229,18):
  error: variable declaration in condition must have an initializer
  if (definition and definition->Descriptor().LocalName() == desc.LocalName()) {
 ^
2 errors generated.


On May 24, 2017 4:01 PM, "Blower, Melanie" 
mailto:melanie.blo...@intel.com>> wrote:
Thanks for the feedback, working on it…

From: Keane, Erich
Sent: Wednesday, May 24, 2017 3:47 PM
To: Nico Weber mailto:tha...@chromium.org>>; Blower, 
Melanie mailto:melanie.blo...@intel.com>>

Cc: cfe-commits 
mailto:cfe-commits@lists.llvm.org>>; rnk 
mailto:r...@chromium.org>>
Subject: RE: r303798 - For Microsoft compatibility, set fno_operator_names

Adding Melanie, the author of the patch.

From: tha...@google.com [mailto:tha...@google.com] On 
Behalf Of Nico Weber
Sent: Wednesday, May 24, 2017 12:43 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: cfe-commits 
mailto:cfe-commits@lists.llvm.org>>; rnk 
mailto:r...@chromium.org>>
Subject: Re: r303798 - For Microsoft compatibility, set fno_operator_names

Reviewed here: https://reviews.llvm.org/D33505

Still, please make this warn.

On Wed, May 24, 2017 at 3:42 PM, Nico Weber 
mailto:tha...@google.com>> wrote:
Was this reviewed somewhere?

Please make it so that this emits a warning. We want clang-cl to warn on 
invalid code (and in system headers warnings are suppressed).

On Wed, May 24, 2017 at 3:31 PM, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Wed May 24 14:31:19 2017
New Revision: 303798

URL: http://llvm.org/viewvc/llvm-project?rev=303798&view=rev
Log:
For Microsoft compatibility, set fno_operator_names

There's a Microsoft header in the Windows SDK which won't
compile with clang because it uses an operator name (and)
as a field name. This patch allows that file to compile by
setting the option which disables operator names.
The header which doesn't compile  C:/Program Files (x86)/
Windows Kits/10/include/10.0.14393.0/um\Query.h:259:40:
error: expected member name or ';' after declaration specifiers

  /* [case()] */ NODERESTRICTION or;
   ~~~ ^

   1 error generated.

Contributed for Melanie Blower

Differential Revision:https://reviews.llvm.org/D33505

Modified:
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Parser/MicrosoftExtensions.cpp
cfe/trunk/test/Preprocessor/cxx_oper_keyword.cpp

Modified: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInvocation.cpp?rev=303798&r1=303797&r2=303798&view=diff
==
--- cfe/trunk/lib/Frontend/CompilerInvocation.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp Wed May 24 14:31:19 2017
@@ -1882,7 +1882,7 @@ static void ParseLangArgs(LangOptions &O
   Opts.GNUKeywords = Args.hasFlag(OPT_fgnu_keywords, OPT_fno_gnu_keywords,
   Opts.GNUKeywords);

-  if (Args.hasArg(OPT_fno_operator_names))
+  if (Args.hasArg(OPT_fno_operator_names) || 
Args.hasArg(OPT_fms_compatibility))
 Opts.CXXOperatorNames = 0;

   if (Args.hasArg(OPT_fcuda_is_device))

Modified: cfe/trunk/test/Parser/MicrosoftExtensions.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/MicrosoftExtensions.cpp?rev=303798&r1=303797&r2=303798&view=diff
==
--- cfe/trunk/test/Parser/MicrosoftExtensions.cpp (original)
+++ cfe/trunk/test/Parser/MicrosoftExtensions.cpp Wed May 24 14:31:19 2017
@@ -261,9 +261,8 @@ int __identifier(else}

RE: r303798 - For Microsoft compatibility, set fno_operator_names

[Keane, Erich via cfe-commits]

How does chromium compiler in CL?  It seems that it would have a similar 
problem here…

From: tha...@google.com [mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Thursday, May 25, 2017 9:16 AM
To: Blower, Melanie 
Cc: rnk ; Keane, Erich ; cfe-commits 
; Hans Wennborg 
Subject: RE: r303798 - For Microsoft compatibility, set fno_operator_names

In addition to this making clang-cl silently accept invalid code, it also 
breaks existing valid code, building chromium now fails. Let's revert and come 
up with something better asynchronously.

FAILED: obj/third_party/WebKit/Source/core/dom/dom/CustomElementRegistry.obj
E:\b\c\goma_client/gomacc.exe 
../../third_party/llvm-build/Release+Asserts/bin/clang-cl.exe /nologo 
/showIncludes /FC 
@obj/third_party/WebKit/Source/core/dom/dom/CustomElementRegistry.obj.rsp /c 
../../third_party/WebKit/Source/core/dom/custom/CustomElementRegistry.cpp 
/Foobj/third_party/WebKit/Source/core/dom/dom/CustomElementRegistry.obj 
/Fd"obj/third_party/WebKit/Source/core/dom/dom_cc.pdb"
E:\b\c\b\win_clang\src\third_party\WebKit\Source\core\dom\custom\CustomElementRegistry.cpp(229,7):
  error: unknown type name 'definition'
  if (definition and definition->Descriptor().LocalName() == desc.LocalName()) {
  ^
E:\b\c\b\win_clang\src\third_party\WebKit\Source\core\dom\custom\CustomElementRegistry.cpp(229,18):
  error: variable declaration in condition must have an initializer
  if (definition and definition->Descriptor().LocalName() == desc.LocalName()) {
 ^
2 errors generated.


On May 24, 2017 4:01 PM, "Blower, Melanie" 
mailto:melanie.blo...@intel.com>> wrote:
Thanks for the feedback, working on it…

From: Keane, Erich
Sent: Wednesday, May 24, 2017 3:47 PM
To: Nico Weber mailto:tha...@chromium.org>>; Blower, 
Melanie mailto:melanie.blo...@intel.com>>

Cc: cfe-commits 
mailto:cfe-commits@lists.llvm.org>>; rnk 
mailto:r...@chromium.org>>
Subject: RE: r303798 - For Microsoft compatibility, set fno_operator_names

Adding Melanie, the author of the patch.

From: tha...@google.com [mailto:tha...@google.com] On 
Behalf Of Nico Weber
Sent: Wednesday, May 24, 2017 12:43 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: cfe-commits 
mailto:cfe-commits@lists.llvm.org>>; rnk 
mailto:r...@chromium.org>>
Subject: Re: r303798 - For Microsoft compatibility, set fno_operator_names

Reviewed here: https://reviews.llvm.org/D33505

Still, please make this warn.

On Wed, May 24, 2017 at 3:42 PM, Nico Weber 
mailto:tha...@google.com>> wrote:
Was this reviewed somewhere?

Please make it so that this emits a warning. We want clang-cl to warn on 
invalid code (and in system headers warnings are suppressed).

On Wed, May 24, 2017 at 3:31 PM, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Wed May 24 14:31:19 2017
New Revision: 303798

URL: http://llvm.org/viewvc/llvm-project?rev=303798&view=rev
Log:
For Microsoft compatibility, set fno_operator_names

There's a Microsoft header in the Windows SDK which won't
compile with clang because it uses an operator name (and)
as a field name. This patch allows that file to compile by
setting the option which disables operator names.
The header which doesn't compile  C:/Program Files (x86)/
Windows Kits/10/include/10.0.14393.0/um\Query.h:259:40:
error: expected member name or ';' after declaration specifiers

  /* [case()] */ NODERESTRICTION or;
   ~~~ ^

   1 error generated.

Contributed for Melanie Blower

Differential Revision:https://reviews.llvm.org/D33505

Modified:
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Parser/MicrosoftExtensions.cpp
cfe/trunk/test/Preprocessor/cxx_oper_keyword.cpp

Modified: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInvocation.cpp?rev=303798&r1=303797&r2=303798&view=diff
==
--- cfe/trunk/lib/Frontend/CompilerInvocation.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp Wed May 24 14:31:19 2017
@@ -1882,7 +1882,7 @@ static void ParseLangArgs(LangOptions &O
   Opts.GNUKeywords = Args.hasFlag(OPT_fgnu_keywords, OPT_fno_gnu_keywords,
   Opts.GNUKeywords);

-  if (Args.hasArg(OPT_fno_operator_names))
+  if (Args.hasArg(OPT_fno_operator_names) || 
Args.hasArg(OPT_fms_compatibility))
 Opts.CXXOperatorNames = 0;

   if (Args.hasArg(OPT_fcuda_is_device))

Modified: cfe/trunk/test/Parser/MicrosoftExtensions.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/MicrosoftExtensions.cpp?rev=303798&r1=303797&r2=303798&view=diff
==
--- cfe/trunk/test/Parser/MicrosoftExtensions.cpp (original)
+++ cfe/trunk/test/Parser/MicrosoftExtensions.cpp Wed May 24 14:31:19 2017
@@ -261,9 +261,8 @@ int __ident

RE: r303798 - For Microsoft compatibility, set fno_operator_names

[Keane, Erich via cfe-commits]

Adding Melanie, the author of the patch.

From: tha...@google.com [mailto:tha...@google.com] On Behalf Of Nico Weber
Sent: Wednesday, May 24, 2017 12:43 PM
To: Keane, Erich 
Cc: cfe-commits ; rnk 
Subject: Re: r303798 - For Microsoft compatibility, set fno_operator_names

Reviewed here: https://reviews.llvm.org/D33505

Still, please make this warn.

On Wed, May 24, 2017 at 3:42 PM, Nico Weber 
mailto:tha...@google.com>> wrote:
Was this reviewed somewhere?

Please make it so that this emits a warning. We want clang-cl to warn on 
invalid code (and in system headers warnings are suppressed).

On Wed, May 24, 2017 at 3:31 PM, Erich Keane via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: erichkeane
Date: Wed May 24 14:31:19 2017
New Revision: 303798

URL: http://llvm.org/viewvc/llvm-project?rev=303798&view=rev
Log:
For Microsoft compatibility, set fno_operator_names

There's a Microsoft header in the Windows SDK which won't
compile with clang because it uses an operator name (and)
as a field name. This patch allows that file to compile by
setting the option which disables operator names.
The header which doesn't compile  C:/Program Files (x86)/
Windows Kits/10/include/10.0.14393.0/um\Query.h:259:40:
error: expected member name or ';' after declaration specifiers

  /* [case()] */ NODERESTRICTION or;
   ~~~ ^

   1 error generated.

Contributed for Melanie Blower

Differential Revision:https://reviews.llvm.org/D33505

Modified:
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Parser/MicrosoftExtensions.cpp
cfe/trunk/test/Preprocessor/cxx_oper_keyword.cpp

Modified: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInvocation.cpp?rev=303798&r1=303797&r2=303798&view=diff
==
--- cfe/trunk/lib/Frontend/CompilerInvocation.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp Wed May 24 14:31:19 2017
@@ -1882,7 +1882,7 @@ static void ParseLangArgs(LangOptions &O
   Opts.GNUKeywords = Args.hasFlag(OPT_fgnu_keywords, OPT_fno_gnu_keywords,
   Opts.GNUKeywords);

-  if (Args.hasArg(OPT_fno_operator_names))
+  if (Args.hasArg(OPT_fno_operator_names) || 
Args.hasArg(OPT_fms_compatibility))
 Opts.CXXOperatorNames = 0;

   if (Args.hasArg(OPT_fcuda_is_device))

Modified: cfe/trunk/test/Parser/MicrosoftExtensions.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/MicrosoftExtensions.cpp?rev=303798&r1=303797&r2=303798&view=diff
==
--- cfe/trunk/test/Parser/MicrosoftExtensions.cpp (original)
+++ cfe/trunk/test/Parser/MicrosoftExtensions.cpp Wed May 24 14:31:19 2017
@@ -261,9 +261,8 @@ int __identifier(else} = __identifier(fo
 #define identifier_weird(x) __identifier(x
 int k = identifier_weird(if)); // expected-error {{use of undeclared 
identifier 'if'}}

-// This is a bit weird, but the alternative tokens aren't keywords, and this
-// behavior matches MSVC. FIXME: Consider supporting this anyway.
-extern int __identifier(and) r; // expected-error {{cannot convert '&&' token 
to an identifier}}
+// 'and' is not an operator name with Microsoft compatibility.
+extern int __identifier(and) r; // expected-error {{expected ';' after top 
level declarator}}

 void f() {
   __identifier(() // expected-error {{cannot convert '(' token to an 
identifier}}
@@ -355,7 +354,6 @@ void TestProperty() {
   ++sp.V11;
 }

-//expected-warning@+1 {{C++ operator 'and' (aka '&&') used as a macro name}}
 #define and foo

 struct __declspec(uuid("---C000-0046")) 
__declspec(novtable) IUnknown {};

Modified: cfe/trunk/test/Preprocessor/cxx_oper_keyword.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/cxx_oper_keyword.cpp?rev=303798&r1=303797&r2=303798&view=diff
==
--- cfe/trunk/test/Preprocessor/cxx_oper_keyword.cpp (original)
+++ cfe/trunk/test/Preprocessor/cxx_oper_keyword.cpp Wed May 24 14:31:19 2017
@@ -1,5 +1,6 @@
 // RUN: %clang_cc1 %s -E -verify -DOPERATOR_NAMES
 // RUN: %clang_cc1 %s -E -verify -fno-operator-names
+// RUN: %clang_cc1 %s-verify -DTESTWIN -fms-compatibility

 #ifndef OPERATOR_NAMES
 //expected-error@+3 {{token is not a valid binary operator in a preprocessor 
subexpression}}
@@ -29,3 +30,14 @@
 #ifdef and
 #warning and is defined
 #endif
+
+#ifdef TESTWIN
+// For cl compatibility, fno-operator-names is enabled by default.
+int and;
+int bitand;
+int bitor;
+int compl;
+int not;
+int or;
+int xor;
+#endif


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

RE: r298410 - Correct class-template deprecation behavior

[Keane, Erich via cfe-commits]

Ended up being simpler than I expected.  I added -r298433  To fix this.  

The issue is that the test had a conditional based on the "C" version, so I 
explicitly added a test for C89 and C99, which the PS4 is apparently not 
defaulting to.

Thanks!
-Erich


-Original Message-
From: Yung, Douglas [mailto:douglas.y...@sony.com] 
Sent: Tuesday, March 21, 2017 12:59 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: RE: r298410 - Correct class-template deprecation behavior

Hi Erich,

Your change is causing the Sema/attr-deprecated.c test to fail on the PS4 bot 
(http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/7087).
 Can you take a look?

Douglas Yung

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On 
> Behalf Of Erich Keane via cfe-commits
> Sent: Tuesday, March 21, 2017 10:49
> To: cfe-commits@lists.llvm.org
> Subject: r298410 - Correct class-template deprecation behavior
> 
> Author: erichkeane
> Date: Tue Mar 21 12:49:17 2017
> New Revision: 298410
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=298410&view=rev
> Log:
> Correct class-template deprecation behavior
> 
> Based on the comment in the test, and my reading of the standard, a 
> deprecated warning should be issued in the following case:
> template [[deprecated]] class Foo{}; Foo f;
> 
> This was not the case, because the ClassTemplateSpecializationDecl 
> creation did not also copy the deprecated attribute.
> 
> Note: I did NOT audit the complete set of attributes to see WHICH ones 
> should be copied, so instead I simply copy ONLY the deprecated attribute.
> 
> Differential Revision: https://reviews.llvm.org/D27486
> 
> Modified:
> cfe/trunk/include/clang/Basic/Attr.td
> cfe/trunk/include/clang/Sema/Sema.h
> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> cfe/trunk/lib/Sema/SemaTemplate.cpp
> cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
> cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
> cfe/trunk/test/CXX/dcl.dcl/dcl.attr/dcl.attr.deprecated/p1.cpp
> cfe/trunk/test/Sema/attr-deprecated.c
> cfe/trunk/test/SemaCXX/attr-deprecated.cpp
> cfe/trunk/test/SemaObjC/attr-deprecated.m
> cfe/trunk/test/SemaObjC/special-dep-unavail-warning.m
> cfe/trunk/test/SemaObjC/warn-deprecated-implementations.m
> cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp
> 
> Modified: cfe/trunk/include/clang/Basic/Attr.td
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/include/clang/Basic/Attr.td?rev=298410&r1=298409&r2=
> 298410&v
> iew=diff
> ==
> 
> --- cfe/trunk/include/clang/Basic/Attr.td (original)
> +++ cfe/trunk/include/clang/Basic/Attr.td Tue Mar 21 12:49:17 2017
> @@ -302,6 +302,9 @@ class Attr {
>// Set to true if this attribute can be duplicated on a subject 
> when merging
>// attributes. By default, attributes are not merged.
>bit DuplicatesAllowedWhileMerging = 0;
> +  // Set to true if this attribute is meaningful when applied to or 
> + inherited  // in a class template definition.
> +  bit MeaningfulToClassTemplateDefinition = 0;
>// Lists language options, one of which is required to be true for the
>// attribute to be applicable. If empty, no language options are required.
>list LangOpts = [];
> @@ -373,6 +376,7 @@ def AbiTag : Attr {
>let Args = [VariadicStringArgument<"Tags">];
>let Subjects = SubjectList<[Struct, Var, Function, Namespace], ErrorDiag,
>"ExpectedStructClassVariableFunctionOrInlineNamespace">;
> +  let MeaningfulToClassTemplateDefinition = 1;
>let Documentation = [AbiTagsDocs];
>  }
> 
> @@ -805,6 +809,7 @@ def Deprecated : InheritableAttr {
>// An optional string argument that enables us to provide a
>// Fix-It.
>StringArgument<"Replacement", 1>];
> +  let MeaningfulToClassTemplateDefinition = 1;
>let Documentation = [DeprecatedDocs];  }
> 
> @@ -1723,6 +1728,7 @@ def Visibility : InheritableAttr {
>let Args = [EnumArgument<"Visibility", "VisibilityType",
> ["default", "hidden", "internal", "protected"],
> ["Default", "Hidden", "Hidden", 
> "Protected"]>];
> +  let MeaningfulToClassTemplateDefinition = 1;
>let Documentation = [Undocumented];  }
> 
> 
> Modified: cfe/trunk/include/clang/Sema/Sema.h
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/include/clang/Sema/Sema.h?rev=298410&r1=298409&r2=29
> 8410&vie
> w=diff
> ==
> 
> --- cfe/trunk/include/clang/Sema/Sema.h (original)
> +++ cfe/trunk/include/clang/Sema/Sema.h Tue Mar 21 12:49:17 2017
> @@ -7505,6 +7505,12 @@ public:
>  LateInstantiatedAttrVec *LateAttrs = nullptr,
>  LocalInstantiationScope *OuterMostScope = 
> nullptr);
> 
> +  void
> +  InstantiateAttrsForDecl(const MultiL

RE: r298410 - Correct class-template deprecation behavior

[Keane, Erich via cfe-commits]

I saw that, I was digging into it, then went to lunch.  I'm hoping to push a 
fix by EOD if I can.

Thanks for the heads up though!

-Original Message-
From: Yung, Douglas [mailto:douglas.y...@sony.com] 
Sent: Tuesday, March 21, 2017 12:59 PM
To: Keane, Erich 
Cc: cfe-commits 
Subject: RE: r298410 - Correct class-template deprecation behavior

Hi Erich,

Your change is causing the Sema/attr-deprecated.c test to fail on the PS4 bot 
(http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/7087).
 Can you take a look?

Douglas Yung

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On 
> Behalf Of Erich Keane via cfe-commits
> Sent: Tuesday, March 21, 2017 10:49
> To: cfe-commits@lists.llvm.org
> Subject: r298410 - Correct class-template deprecation behavior
> 
> Author: erichkeane
> Date: Tue Mar 21 12:49:17 2017
> New Revision: 298410
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=298410&view=rev
> Log:
> Correct class-template deprecation behavior
> 
> Based on the comment in the test, and my reading of the standard, a 
> deprecated warning should be issued in the following case:
> template [[deprecated]] class Foo{}; Foo f;
> 
> This was not the case, because the ClassTemplateSpecializationDecl 
> creation did not also copy the deprecated attribute.
> 
> Note: I did NOT audit the complete set of attributes to see WHICH ones 
> should be copied, so instead I simply copy ONLY the deprecated attribute.
> 
> Differential Revision: https://reviews.llvm.org/D27486
> 
> Modified:
> cfe/trunk/include/clang/Basic/Attr.td
> cfe/trunk/include/clang/Sema/Sema.h
> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> cfe/trunk/lib/Sema/SemaTemplate.cpp
> cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
> cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
> cfe/trunk/test/CXX/dcl.dcl/dcl.attr/dcl.attr.deprecated/p1.cpp
> cfe/trunk/test/Sema/attr-deprecated.c
> cfe/trunk/test/SemaCXX/attr-deprecated.cpp
> cfe/trunk/test/SemaObjC/attr-deprecated.m
> cfe/trunk/test/SemaObjC/special-dep-unavail-warning.m
> cfe/trunk/test/SemaObjC/warn-deprecated-implementations.m
> cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp
> 
> Modified: cfe/trunk/include/clang/Basic/Attr.td
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/include/clang/Basic/Attr.td?rev=298410&r1=298409&r2=
> 298410&v
> iew=diff
> ==
> 
> --- cfe/trunk/include/clang/Basic/Attr.td (original)
> +++ cfe/trunk/include/clang/Basic/Attr.td Tue Mar 21 12:49:17 2017
> @@ -302,6 +302,9 @@ class Attr {
>// Set to true if this attribute can be duplicated on a subject 
> when merging
>// attributes. By default, attributes are not merged.
>bit DuplicatesAllowedWhileMerging = 0;
> +  // Set to true if this attribute is meaningful when applied to or 
> + inherited  // in a class template definition.
> +  bit MeaningfulToClassTemplateDefinition = 0;
>// Lists language options, one of which is required to be true for the
>// attribute to be applicable. If empty, no language options are required.
>list LangOpts = [];
> @@ -373,6 +376,7 @@ def AbiTag : Attr {
>let Args = [VariadicStringArgument<"Tags">];
>let Subjects = SubjectList<[Struct, Var, Function, Namespace], ErrorDiag,
>"ExpectedStructClassVariableFunctionOrInlineNamespace">;
> +  let MeaningfulToClassTemplateDefinition = 1;
>let Documentation = [AbiTagsDocs];
>  }
> 
> @@ -805,6 +809,7 @@ def Deprecated : InheritableAttr {
>// An optional string argument that enables us to provide a
>// Fix-It.
>StringArgument<"Replacement", 1>];
> +  let MeaningfulToClassTemplateDefinition = 1;
>let Documentation = [DeprecatedDocs];  }
> 
> @@ -1723,6 +1728,7 @@ def Visibility : InheritableAttr {
>let Args = [EnumArgument<"Visibility", "VisibilityType",
> ["default", "hidden", "internal", "protected"],
> ["Default", "Hidden", "Hidden", 
> "Protected"]>];
> +  let MeaningfulToClassTemplateDefinition = 1;
>let Documentation = [Undocumented];  }
> 
> 
> Modified: cfe/trunk/include/clang/Sema/Sema.h
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/include/clang/Sema/Sema.h?rev=298410&r1=298409&r2=29
> 8410&vie
> w=diff
> ==
> 
> --- cfe/trunk/include/clang/Sema/Sema.h (original)
> +++ cfe/trunk/include/clang/Sema/Sema.h Tue Mar 21 12:49:17 2017
> @@ -7505,6 +7505,12 @@ public:
>  LateInstantiatedAttrVec *LateAttrs = nullptr,
>  LocalInstantiationScope *OuterMostScope = 
> nullptr);
> 
> +  void
> +  InstantiateAttrsForDecl(const MultiLevelTemplateArgumentList &TemplateArgs,
> +  const Decl *Pattern, Decl *Inst,
> + 

RE: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null dereference with OpenMP array access

[Keane, Erich via cfe-commits]

I don't see any .ll files for the tests.  I see the directory 
build/tools/clang/test/OpenMP/Output has a bunch of .script and .tmp(binary 
files), but no obvious .ll files.


-Original Message-
From: Alexey Bataev [mailto:a.bat...@hotmail.com] 
Sent: Monday, October 10, 2016 1:22 PM
To: Keane, Erich 
Cc: reviews+d25373+public+d8ec2a4bb41b1...@reviews.llvm.org; 
cfe-commits@lists.llvm.org; dblai...@gmail.com; david.majne...@gmail.com; 
guy.ben...@intel.com
Subject: Re: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null dereference 
with OpenMP array access

I mean, could you send new  .ll files, which you get after these changes?

Best regards,
Alexey Bataev

> 10 окт. 2016 г., в 22:26, Keane, Erich  написал(а):
> 
> Sure, attached.  So far, there are a few changes that seem curious and 
> concerning. A few cases of loads going missing, and a few more of things like 
> 'nonnull' going missing.
> 
> -Original Message-
> From: Alexey Bataev [mailto:a.bat...@hotmail.com]
> Sent: Monday, October 10, 2016 12:18 PM
> To: Keane, Erich ; 
> reviews+d25373+public+d8ec2a4bb41b1...@reviews.llvm.org; 
> cfe-commits@lists.llvm.org; dblai...@gmail.com; 
> david.majne...@gmail.com; guy.ben...@intel.com
> Subject: Re: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null 
> dereference with OpenMP array access
> 
> Could you send the new results for these tests?
> 
> Best regards,
> Alexey Bataev
> 
>> On 10/10/2016 09:22 PM, Keane, Erich wrote:
>> This causes a massive number of openmp test failures (obviously), and I'm 
>> not terribly comfortable with how OpenMP works.  I can update the tests (and 
>> will), but would like it if you could be extra diligent in confirming the 
>> correct behavior for me.
>> 
>> Failing Tests (6):
>> Clang :: OpenMP/for_reduction_codegen.cpp
>> Clang :: OpenMP/for_reduction_codegen_UDR.cpp
>> Clang :: OpenMP/nvptx_target_codegen.cpp
>> Clang :: OpenMP/target_codegen.cpp
>> Clang :: OpenMP/target_firstprivate_codegen.cpp
>> Clang :: OpenMP/target_map_codegen.cpp -Original Message-
>> From: Alexey Bataev [mailto:a.bat...@hotmail.com]
>> Sent: Monday, October 10, 2016 10:55 AM
>> To: Keane, Erich ;
>> reviews+d25373+public+d8ec2a4bb41b1...@reviews.llvm.org;
>> cfe-commits@lists.llvm.org; dblai...@gmail.com; 
>> david.majne...@gmail.com; guy.ben...@intel.com
>> Subject: Re: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null 
>> dereference with OpenMP array access
>> 
>> Add a check to line 299:
>> 
>> if (!VarTy->isReferenceType() &&
>> !(FD->getType()->isVariablyModifiedType()  &&
>> ArgLVal.getType()->isPointerType()))
>> 
>> Best regards,
>> Alexey Bataev
>> 
>>> On 10/10/2016 08:19 PM, Keane, Erich wrote:
>>> That does turn ArgType into a PointerType int*.  However, line 301 
>>> (GenerateOpenMPCapturedStmtFunction) attempts to cast it to a reference 
>>> type a bit later, resulting in a SIGABRT there.  Do I need to re-add the 
>>> reference there?  Is removing the array type REALLY what we wish to do?
>>> 
>>> -Original Message-
>>> From: Alexey Bataev [mailto:a.bat...@hotmail.com]
>>> Sent: Monday, October 10, 2016 10:09 AM
>>> To: Keane, Erich ;
>>> reviews+d25373+public+d8ec2a4bb41b1...@reviews.llvm.org;
>>> cfe-commits@lists.llvm.org; dblai...@gmail.com; 
>>> david.majne...@gmail.com; guy.ben...@intel.com
>>> Subject: Re: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null 
>>> dereference with OpenMP array access
>>> 
>>> Aaaahhh,
>>> 
>>> Now I see. We have a parameter with the type that is a reference to VLA.
>>> I think in this case we should rework this code to something like this:
>>> 
>>> if (ArgType->isVariablyModifiedType())
>>> ArgType =
>>> getContext().getCanonicalParamType(ArgType.getNonReferenceType());
>>> 
>>> 
>>> Try this solution.
>>> 
>>> Best regards,
>>> Alexey Bataev
>>> 
 On 10/10/2016 07:51 PM, Keane, Erich wrote:
 I did.  I changed line 236 to "ArgType = 
 getContext().getCanonicalParamType(ArgType);" (as I believe you were 
 suggesting), and the output was identical when doing dump on ArgType:
 
 This:
 
 LValueReferenceType 0xa451620 'int (&)[*]' variably_modified
 `-VariableArrayType 0xa4515e0 'int [*]' variably_modified  *
   |-BuiltinType 0xa3f4090 'int'
   `-<<>>
 Vs:
 LValueReferenceType 0xa451690 'int (&)[*]' variably_modified
 `-VariableArrayType 0xa451650 'int [*]' variably_modified  *
   |-BuiltinType 0xa3f4090 'int'
   `-<<>>
 
 -Original Message-
 From: Alexey Bataev [mailto:a.bat...@hotmail.com]
 Sent: Monday, October 10, 2016 9:47 AM
 To: reviews+d25373+public+d8ec2a4bb41b1...@reviews.llvm.org; Keane, 
 Erich ; cfe-commits@lists.llvm.org; 
 dblai...@gmail.com; david.majne...@gmail.com; guy.ben...@intel.com
 Subject: Re: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null 
 dereference with OpenMP array access
 
 Hmm,
 
 I thou

RE: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null dereference with OpenMP array access

[Keane, Erich via cfe-commits]

This causes a massive number of openmp test failures (obviously), and I'm not 
terribly comfortable with how OpenMP works.  I can update the tests (and will), 
but would like it if you could be extra diligent in confirming the correct 
behavior for me.

Failing Tests (6):
Clang :: OpenMP/for_reduction_codegen.cpp
Clang :: OpenMP/for_reduction_codegen_UDR.cpp
Clang :: OpenMP/nvptx_target_codegen.cpp
Clang :: OpenMP/target_codegen.cpp
Clang :: OpenMP/target_firstprivate_codegen.cpp
Clang :: OpenMP/target_map_codegen.cpp
-Original Message-
From: Alexey Bataev [mailto:a.bat...@hotmail.com] 
Sent: Monday, October 10, 2016 10:55 AM
To: Keane, Erich ; 
reviews+d25373+public+d8ec2a4bb41b1...@reviews.llvm.org; 
cfe-commits@lists.llvm.org; dblai...@gmail.com; david.majne...@gmail.com; 
guy.ben...@intel.com
Subject: Re: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null dereference 
with OpenMP array access

Add a check to line 299:

if (!VarTy->isReferenceType() && 
!(FD->getType()->isVariablyModifiedType()  && 
ArgLVal.getType()->isPointerType()))

Best regards,
Alexey Bataev

On 10/10/2016 08:19 PM, Keane, Erich wrote:
> That does turn ArgType into a PointerType int*.  However, line 301 
> (GenerateOpenMPCapturedStmtFunction) attempts to cast it to a reference type 
> a bit later, resulting in a SIGABRT there.  Do I need to re-add the reference 
> there?  Is removing the array type REALLY what we wish to do?
>
> -Original Message-
> From: Alexey Bataev [mailto:a.bat...@hotmail.com]
> Sent: Monday, October 10, 2016 10:09 AM
> To: Keane, Erich ; 
> reviews+d25373+public+d8ec2a4bb41b1...@reviews.llvm.org; 
> cfe-commits@lists.llvm.org; dblai...@gmail.com; david.majne...@gmail.com; 
> guy.ben...@intel.com
> Subject: Re: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null dereference 
> with OpenMP array access
>
> Aaaahhh,
>
> Now I see. We have a parameter with the type that is a reference to VLA.
> I think in this case we should rework this code to something like this:
>
> if (ArgType->isVariablyModifiedType())
> ArgType =
> getContext().getCanonicalParamType(ArgType.getNonReferenceType());
>
>
> Try this solution.
>
> Best regards,
> Alexey Bataev
>
> On 10/10/2016 07:51 PM, Keane, Erich wrote:
>> I did.  I changed line 236 to "ArgType = 
>> getContext().getCanonicalParamType(ArgType);" (as I believe you were 
>> suggesting), and the output was identical when doing dump on ArgType:
>>
>> This:
>>
>> LValueReferenceType 0xa451620 'int (&)[*]' variably_modified
>> `-VariableArrayType 0xa4515e0 'int [*]' variably_modified  *
>>   |-BuiltinType 0xa3f4090 'int'
>>   `-<<>>
>> Vs:
>> LValueReferenceType 0xa451690 'int (&)[*]' variably_modified
>> `-VariableArrayType 0xa451650 'int [*]' variably_modified  *
>>   |-BuiltinType 0xa3f4090 'int'
>>   `-<<>>
>>
>> -Original Message-
>> From: Alexey Bataev [mailto:a.bat...@hotmail.com]
>> Sent: Monday, October 10, 2016 9:47 AM
>> To: reviews+d25373+public+d8ec2a4bb41b1...@reviews.llvm.org; Keane, Erich 
>> ; cfe-commits@lists.llvm.org; dblai...@gmail.com; 
>> david.majne...@gmail.com; guy.ben...@intel.com
>> Subject: Re: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null dereference 
>> with OpenMP array access
>>
>> Hmm,
>>
>> I thought it must return a pointer to the element type rather than [*] kind 
>> type. Did you checked it?
>>
>> Best regards,
>> Alexey Bataev
>>
>> On 10/10/2016 07:09 PM, Erich Keane wrote:
>>> erichkeane added a comment.
>>>
>>> Andrey-
>>> It seems that getVariableArrayDecayedType and getCanonicalParamType return 
>>> the same type in this case (at least in the reproduction).  I could 
>>> definitely change the call, though the changes to CGDebugInfo.cpp are 
>>> apparently also necessary even in that case.
>>>
>>> Is there additional logic that should happen in CGStmtOpenMP that I'm 
>>> missing?
>>>
>>>
>>> Repository:
>>>  rL LLVM
>>>
>>> https://reviews.llvm.org/D25373
>>>
>>>
>>>

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

RE: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null dereference with OpenMP array access

[Keane, Erich via cfe-commits]

That does turn ArgType into a PointerType int*.  However, line 301 
(GenerateOpenMPCapturedStmtFunction) attempts to cast it to a reference type a 
bit later, resulting in a SIGABRT there.  Do I need to re-add the reference 
there?  Is removing the array type REALLY what we wish to do?

-Original Message-
From: Alexey Bataev [mailto:a.bat...@hotmail.com] 
Sent: Monday, October 10, 2016 10:09 AM
To: Keane, Erich ; 
reviews+d25373+public+d8ec2a4bb41b1...@reviews.llvm.org; 
cfe-commits@lists.llvm.org; dblai...@gmail.com; david.majne...@gmail.com; 
guy.ben...@intel.com
Subject: Re: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null dereference 
with OpenMP array access

Aaaahhh,

Now I see. We have a parameter with the type that is a reference to VLA. 
I think in this case we should rework this code to something like this:

if (ArgType->isVariablyModifiedType())
   ArgType = 
getContext().getCanonicalParamType(ArgType.getNonReferenceType());


Try this solution.

Best regards,
Alexey Bataev

On 10/10/2016 07:51 PM, Keane, Erich wrote:
> I did.  I changed line 236 to "ArgType = 
> getContext().getCanonicalParamType(ArgType);" (as I believe you were 
> suggesting), and the output was identical when doing dump on ArgType:
>
> This:
>
>LValueReferenceType 0xa451620 'int (&)[*]' variably_modified
>`-VariableArrayType 0xa4515e0 'int [*]' variably_modified  *
>  |-BuiltinType 0xa3f4090 'int'
>  `-<<>>
> Vs:
>LValueReferenceType 0xa451690 'int (&)[*]' variably_modified
>`-VariableArrayType 0xa451650 'int [*]' variably_modified  *
>  |-BuiltinType 0xa3f4090 'int'
>  `-<<>>
>
> -Original Message-
> From: Alexey Bataev [mailto:a.bat...@hotmail.com]
> Sent: Monday, October 10, 2016 9:47 AM
> To: reviews+d25373+public+d8ec2a4bb41b1...@reviews.llvm.org; Keane, Erich 
> ; cfe-commits@lists.llvm.org; dblai...@gmail.com; 
> david.majne...@gmail.com; guy.ben...@intel.com
> Subject: Re: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null dereference 
> with OpenMP array access
>
> Hmm,
>
> I thought it must return a pointer to the element type rather than [*] kind 
> type. Did you checked it?
>
> Best regards,
> Alexey Bataev
>
> On 10/10/2016 07:09 PM, Erich Keane wrote:
>> erichkeane added a comment.
>>
>> Andrey-
>> It seems that getVariableArrayDecayedType and getCanonicalParamType return 
>> the same type in this case (at least in the reproduction).  I could 
>> definitely change the call, though the changes to CGDebugInfo.cpp are 
>> apparently also necessary even in that case.
>>
>> Is there additional logic that should happen in CGStmtOpenMP that I'm 
>> missing?
>>
>>
>> Repository:
>> rL LLVM
>>
>> https://reviews.llvm.org/D25373
>>
>>
>>

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

RE: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null dereference with OpenMP array access

[Keane, Erich via cfe-commits]

I did.  I changed line 236 to "ArgType = 
getContext().getCanonicalParamType(ArgType);" (as I believe you were 
suggesting), and the output was identical when doing dump on ArgType:

This:

  LValueReferenceType 0xa451620 'int (&)[*]' variably_modified
  `-VariableArrayType 0xa4515e0 'int [*]' variably_modified  *
|-BuiltinType 0xa3f4090 'int'
`-<<>>
Vs:
  LValueReferenceType 0xa451690 'int (&)[*]' variably_modified
  `-VariableArrayType 0xa451650 'int [*]' variably_modified  *
|-BuiltinType 0xa3f4090 'int'
`-<<>>

-Original Message-
From: Alexey Bataev [mailto:a.bat...@hotmail.com] 
Sent: Monday, October 10, 2016 9:47 AM
To: reviews+d25373+public+d8ec2a4bb41b1...@reviews.llvm.org; Keane, Erich 
; cfe-commits@lists.llvm.org; dblai...@gmail.com; 
david.majne...@gmail.com; guy.ben...@intel.com
Subject: Re: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null dereference 
with OpenMP array access

Hmm,

I thought it must return a pointer to the element type rather than [*] kind 
type. Did you checked it?

Best regards,
Alexey Bataev

On 10/10/2016 07:09 PM, Erich Keane wrote:
> erichkeane added a comment.
>
> Andrey-
> It seems that getVariableArrayDecayedType and getCanonicalParamType return 
> the same type in this case (at least in the reproduction).  I could 
> definitely change the call, though the changes to CGDebugInfo.cpp are 
> apparently also necessary even in that case.
>
> Is there additional logic that should happen in CGStmtOpenMP that I'm missing?
>
>
> Repository:
>rL LLVM
>
> https://reviews.llvm.org/D25373
>
>
>

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

RE: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null dereference with OpenMP array access

[Keane, Erich via cfe-commits]

Ok, I dug into this deeper.  ASTContext.cpp:2811 (getVariableArrayDecayedType) 
intentionaly sets size to nullptr in this case for the purpose of turning it 
into a [*] type.  OpenMP.cpp:236 
(CodeGenFunction::GenerateOpenMPCapturedStmtFunction) calls this to replace 
variably modified type with this one.  It definitely looks like this is on 
purpose as far as I can tell.



From: Keane, Erich
Sent: Friday, October 7, 2016 11:56 AM
To: 'David Blaikie' ; 
reviews+d25373+public+d8ec2a4bb41b1...@reviews.llvm.org; 
cfe-commits@lists.llvm.org; david.majne...@gmail.com; 'Alexey Bataev' 

Cc: junb...@codeaurora.org
Subject: RE: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null dereference 
with OpenMP array access

Added Alexey to the list, he’s the OMP Maintainer, so hopefully he knows better 
☺

From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Friday, October 7, 2016 11:51 AM
To: 
reviews+d25373+public+d8ec2a4bb41b1...@reviews.llvm.org;
 Keane, Erich mailto:erich.ke...@intel.com>>; 
cfe-commits@lists.llvm.org; 
david.majne...@gmail.com; 
guy.ben...@intel.com
Cc: junb...@codeaurora.org
Subject: Re: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null dereference 
with OpenMP array access

Could you explain how/why there's a null size expr? I would've thought it must 
have /some/ size for code generation purposes...

On Fri, Oct 7, 2016 at 11:33 AM Erich Keane 
mailto:erich.ke...@intel.com>> wrote:
erichkeane created this revision.
erichkeane added reviewers: cfe-commits, dblaikie, majnemer, gbenyei.
erichkeane set the repository for this revision to rL LLVM.

OpenMP creates a variable array type with a a null size-expr.  The Debug 
generation failed to properly consider this case.  This patch adds a null check 
to prevent a null dereference seg-fault in this case, plus adds a test.


Repository:
  rL LLVM

https://reviews.llvm.org/D25373

Files:
  lib/CodeGen/CGDebugInfo.cpp
  test/CodeGenCXX/debug-info-openmp-array.cpp


Index: lib/CodeGen/CGDebugInfo.cpp
===
--- lib/CodeGen/CGDebugInfo.cpp
+++ lib/CodeGen/CGDebugInfo.cpp
@@ -2181,7 +2181,8 @@
   Count = CAT->getSize().getZExtValue();
 else if (const auto *VAT = dyn_cast(Ty)) {
   llvm::APSInt V;
-  if (VAT->getSizeExpr()->EvaluateAsInt(V, CGM.getContext()))
+  if (VAT->getSizeExpr() &&
+  VAT->getSizeExpr()->EvaluateAsInt(V, CGM.getContext()))
 Count = V.getExtValue();
 }

Index: test/CodeGenCXX/debug-info-openmp-array.cpp
===
--- test/CodeGenCXX/debug-info-openmp-array.cpp
+++ test/CodeGenCXX/debug-info-openmp-array.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang -target x86_64-unknown-unknown -fverbose-asm -fopenmp -g -O0 -S 
-emit-llvm %s -o - | FileCheck %s
+
+
+void f(int m) {
+  int i;
+  int cen[m];
+#pragma omp parallel for
+  for (i = 0; i < m; ++i) {
+cen[i] = i;
+  }
+}
+
+// CHECK: !DICompositeType(tag: DW_TAG_array_type,
+// CHECK-NOT: size:
+// CHECK-SAME: align: 32
+// CHECK-SAME:  elements: [[ELEM_TYPE:![0-9]+]]
+// CHECK: !DISubrange(count: -1)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null dereference with OpenMP array access

[Keane, Erich via cfe-commits]

Added Alexey to the list, he’s the OMP Maintainer, so hopefully he knows better 
☺

From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Friday, October 7, 2016 11:51 AM
To: reviews+d25373+public+d8ec2a4bb41b1...@reviews.llvm.org; Keane, Erich 
; cfe-commits@lists.llvm.org; david.majne...@gmail.com; 
guy.ben...@intel.com
Cc: junb...@codeaurora.org
Subject: Re: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null dereference 
with OpenMP array access

Could you explain how/why there's a null size expr? I would've thought it must 
have /some/ size for code generation purposes...

On Fri, Oct 7, 2016 at 11:33 AM Erich Keane 
mailto:erich.ke...@intel.com>> wrote:
erichkeane created this revision.
erichkeane added reviewers: cfe-commits, dblaikie, majnemer, gbenyei.
erichkeane set the repository for this revision to rL LLVM.

OpenMP creates a variable array type with a a null size-expr.  The Debug 
generation failed to properly consider this case.  This patch adds a null check 
to prevent a null dereference seg-fault in this case, plus adds a test.


Repository:
  rL LLVM

https://reviews.llvm.org/D25373

Files:
  lib/CodeGen/CGDebugInfo.cpp
  test/CodeGenCXX/debug-info-openmp-array.cpp


Index: lib/CodeGen/CGDebugInfo.cpp
===
--- lib/CodeGen/CGDebugInfo.cpp
+++ lib/CodeGen/CGDebugInfo.cpp
@@ -2181,7 +2181,8 @@
   Count = CAT->getSize().getZExtValue();
 else if (const auto *VAT = dyn_cast(Ty)) {
   llvm::APSInt V;
-  if (VAT->getSizeExpr()->EvaluateAsInt(V, CGM.getContext()))
+  if (VAT->getSizeExpr() &&
+  VAT->getSizeExpr()->EvaluateAsInt(V, CGM.getContext()))
 Count = V.getExtValue();
 }

Index: test/CodeGenCXX/debug-info-openmp-array.cpp
===
--- test/CodeGenCXX/debug-info-openmp-array.cpp
+++ test/CodeGenCXX/debug-info-openmp-array.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang -target x86_64-unknown-unknown -fverbose-asm -fopenmp -g -O0 -S 
-emit-llvm %s -o - | FileCheck %s
+
+
+void f(int m) {
+  int i;
+  int cen[m];
+#pragma omp parallel for
+  for (i = 0; i < m; ++i) {
+cen[i] = i;
+  }
+}
+
+// CHECK: !DICompositeType(tag: DW_TAG_array_type,
+// CHECK-NOT: size:
+// CHECK-SAME: align: 32
+// CHECK-SAME:  elements: [[ELEM_TYPE:![0-9]+]]
+// CHECK: !DISubrange(count: -1)

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

RE: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null dereference with OpenMP array access

[Keane, Erich via cfe-commits]

I cannot personally right now, though I will dig into OpenMP implementation to 
see how intentional that is.  The size is seemingly determined by the OMP code 
generation as far as I can tell.

From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Friday, October 7, 2016 11:51 AM
To: reviews+d25373+public+d8ec2a4bb41b1...@reviews.llvm.org; Keane, Erich 
; cfe-commits@lists.llvm.org; david.majne...@gmail.com; 
guy.ben...@intel.com
Cc: junb...@codeaurora.org
Subject: Re: [PATCH] D25373: Fix for Bug 30639: CGDebugInfo Null dereference 
with OpenMP array access

Could you explain how/why there's a null size expr? I would've thought it must 
have /some/ size for code generation purposes...

On Fri, Oct 7, 2016 at 11:33 AM Erich Keane 
mailto:erich.ke...@intel.com>> wrote:
erichkeane created this revision.
erichkeane added reviewers: cfe-commits, dblaikie, majnemer, gbenyei.
erichkeane set the repository for this revision to rL LLVM.

OpenMP creates a variable array type with a a null size-expr.  The Debug 
generation failed to properly consider this case.  This patch adds a null check 
to prevent a null dereference seg-fault in this case, plus adds a test.


Repository:
  rL LLVM

https://reviews.llvm.org/D25373

Files:
  lib/CodeGen/CGDebugInfo.cpp
  test/CodeGenCXX/debug-info-openmp-array.cpp


Index: lib/CodeGen/CGDebugInfo.cpp
===
--- lib/CodeGen/CGDebugInfo.cpp
+++ lib/CodeGen/CGDebugInfo.cpp
@@ -2181,7 +2181,8 @@
   Count = CAT->getSize().getZExtValue();
 else if (const auto *VAT = dyn_cast(Ty)) {
   llvm::APSInt V;
-  if (VAT->getSizeExpr()->EvaluateAsInt(V, CGM.getContext()))
+  if (VAT->getSizeExpr() &&
+  VAT->getSizeExpr()->EvaluateAsInt(V, CGM.getContext()))
 Count = V.getExtValue();
 }

Index: test/CodeGenCXX/debug-info-openmp-array.cpp
===
--- test/CodeGenCXX/debug-info-openmp-array.cpp
+++ test/CodeGenCXX/debug-info-openmp-array.cpp
@@ -0,0 +1,17 @@
+// RUN: %clang -target x86_64-unknown-unknown -fverbose-asm -fopenmp -g -O0 -S 
-emit-llvm %s -o - | FileCheck %s
+
+
+void f(int m) {
+  int i;
+  int cen[m];
+#pragma omp parallel for
+  for (i = 0; i < m; ++i) {
+cen[i] = i;
+  }
+}
+
+// CHECK: !DICompositeType(tag: DW_TAG_array_type,
+// CHECK-NOT: size:
+// CHECK-SAME: align: 32
+// CHECK-SAME:  elements: [[ELEM_TYPE:![0-9]+]]
+// CHECK: !DISubrange(count: -1)

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

RE: r277134 - [GCC] Support for __final specifier

[Keane, Erich via cfe-commits]

Fixed in: r277206 after review in https://reviews.llvm.org/D22970


From: Keane, Erich
Sent: Friday, July 29, 2016 11:58 AM
To: 'Andrey Bokhanko' ; Mike Aizatsky 

Cc: cfe-commits 
Subject: RE: r277134 - [GCC] Support for __final specifier

Sure, looking into it now.

From: Andrey Bokhanko [mailto:andreybokha...@gmail.com]
Sent: Friday, July 29, 2016 11:57 AM
To: Mike Aizatsky mailto:aizat...@google.com>>; Keane, 
Erich mailto:erich.ke...@intel.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r277134 - [GCC] Support for __final specifier

Mike,
Thanks for letting me know.
I committed a patch authored by Erich (CCed); Erich, could you, please, 
investigate?
Yours,
Andrey

On Fri, Jul 29, 2016 at 9:35 PM, Mike Aizatsky 
mailto:aizat...@google.com>> wrote:
Andrey,

This change breaks the bot:

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/15093


==15371==WARNING: MemorySanitizer: use-of-uninitialized-value

#0 0x733784d in 
clang::Parser::ParseOptionalCXX11VirtSpecifierSeq(clang::VirtSpecifiers&, bool, 
clang::SourceLocation) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:2050:9

#1 0x7337d55 in 
clang::Parser::ParseCXXMemberDeclaratorBeforeInitializer(clang::Declarator&, 
clang::VirtSpecifiers&, clang::ActionResult&, 
clang::Parser::LateParsedAttrList&) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:2119:5

#2 0x733d2b9 in 
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier, 
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&, 
clang::ParsingDeclRAIIObject*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:2475:7

#3 0x73441a7 in 
clang::Parser::ParseCXXClassMemberDeclarationWithPragmas(clang::AccessSpecifier&,
 clang::Parser::ParsedAttributesWithRange&, clang::TypeSpecifierType, 
clang::Decl*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:2943:10

#4 0x733264c in 
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, 
clang::SourceLocation, clang::Parser::ParsedAttributesWithRange&, unsigned int, 
clang::Decl*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:3113:7

#5 0x732b9c4 in clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, 
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo 
const&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext, 
clang::Parser::ParsedAttributesWithRange&) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:1775:7

#6 0x72cb42c in clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, 
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, 
clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDecl.cpp:3413:7

#7 0x7474138 in clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned 
int, clang::Parser::ParsedTemplateInfo const&, clang::ParsingDeclRAIIObject&, 
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseTemplate.cpp:207:3

#8 0x7472b4d in 
clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int, 
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseTemplate.cpp:152:10

#9 0x747159a in 
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int, 
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseTemplate.cpp:38:10

#10 0x72c86ed in clang::Parser::ParseDeclaration(unsigned int, 
clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDecl.cpp:1492:18

#11 0x72819fd in 
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
 clang::ParsingDeclSpec*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/Parser.cpp:749:14

#12 0x7318897 in 
clang::Parser::ParseInnerNamespace(std::__1::vector >&, 
std::__1::vector >&, 
std::__1::vector >&, unsigned int, 
clang::SourceLocation&, clang::ParsedAttributes&, 
clang::BalancedDelimiterTracker&) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:221:7

#13 0x731722e in clang::Parser::ParseNamespace(unsigned int, 
clang::SourceLocation&, clang::SourceLocation) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/b

RE: [PATCH] D22970: Ensure Ident_GNU_final is properly initialized in the Parser Initialize function

[Keane, Erich via cfe-commits]

I don't have the ability to commit this, but if it is blocking someone in some 
way (since the build verifier would otherwise be broken), someone committing it 
before then would be much appreciated.

Thanks!
-Erich

-Original Message-
From: Andrey Bokhanko [mailto:andreybokha...@gmail.com] 
Sent: Friday, July 29, 2016 12:32 PM
To: Keane, Erich ; cfe-commits@lists.llvm.org; 
aizat...@google.com; andreybokha...@gmail.com
Subject: Re: [PATCH] D22970: Ensure Ident_GNU_final is properly initialized in 
the Parser Initialize function

andreybokhanko accepted this revision.
andreybokhanko added a comment.
This revision is now accepted and ready to land.

LGTM

I can commit this patch on Monday, when I will reach my work machine.

Andrey


Repository:
  rL LLVM

https://reviews.llvm.org/D22970



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

RE: r277134 - [GCC] Support for __final specifier

[Keane, Erich via cfe-commits]

Sure, looking into it now.

From: Andrey Bokhanko [mailto:andreybokha...@gmail.com]
Sent: Friday, July 29, 2016 11:57 AM
To: Mike Aizatsky ; Keane, Erich 
Cc: cfe-commits 
Subject: Re: r277134 - [GCC] Support for __final specifier

Mike,
Thanks for letting me know.
I committed a patch authored by Erich (CCed); Erich, could you, please, 
investigate?
Yours,
Andrey

On Fri, Jul 29, 2016 at 9:35 PM, Mike Aizatsky 
mailto:aizat...@google.com>> wrote:
Andrey,

This change breaks the bot:

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/15093


==15371==WARNING: MemorySanitizer: use-of-uninitialized-value

#0 0x733784d in 
clang::Parser::ParseOptionalCXX11VirtSpecifierSeq(clang::VirtSpecifiers&, bool, 
clang::SourceLocation) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:2050:9

#1 0x7337d55 in 
clang::Parser::ParseCXXMemberDeclaratorBeforeInitializer(clang::Declarator&, 
clang::VirtSpecifiers&, clang::ActionResult&, 
clang::Parser::LateParsedAttrList&) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:2119:5

#2 0x733d2b9 in 
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier, 
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&, 
clang::ParsingDeclRAIIObject*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:2475:7

#3 0x73441a7 in 
clang::Parser::ParseCXXClassMemberDeclarationWithPragmas(clang::AccessSpecifier&,
 clang::Parser::ParsedAttributesWithRange&, clang::TypeSpecifierType, 
clang::Decl*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:2943:10

#4 0x733264c in 
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, 
clang::SourceLocation, clang::Parser::ParsedAttributesWithRange&, unsigned int, 
clang::Decl*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:3113:7

#5 0x732b9c4 in clang::Parser::ParseClassSpecifier(clang::tok::TokenKind, 
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo 
const&, clang::AccessSpecifier, bool, clang::Parser::DeclSpecContext, 
clang::Parser::ParsedAttributesWithRange&) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:1775:7

#6 0x72cb42c in clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&, 
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier, 
clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDecl.cpp:3413:7

#7 0x7474138 in clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned 
int, clang::Parser::ParsedTemplateInfo const&, clang::ParsingDeclRAIIObject&, 
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseTemplate.cpp:207:3

#8 0x7472b4d in 
clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int, 
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseTemplate.cpp:152:10

#9 0x747159a in 
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int, 
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseTemplate.cpp:38:10

#10 0x72c86ed in clang::Parser::ParseDeclaration(unsigned int, 
clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDecl.cpp:1492:18

#11 0x72819fd in 
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
 clang::ParsingDeclSpec*) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/Parser.cpp:749:14

#12 0x7318897 in 
clang::Parser::ParseInnerNamespace(std::__1::vector >&, 
std::__1::vector >&, 
std::__1::vector >&, unsigned int, 
clang::SourceLocation&, clang::ParsedAttributes&, 
clang::BalancedDelimiterTracker&) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:221:7

#13 0x731722e in clang::Parser::ParseNamespace(unsigned int, 
clang::SourceLocation&, clang::SourceLocation) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDeclCXX.cpp:195:3

#14 0x72c8955 in clang::Parser::ParseDeclaration(unsigned int, 
clang::SourceLocation&, clang::Parser::ParsedAttributesWithRange&) 
/mnt/b/sanitizer-buildbot3/sanitizer-x86_64-linux-fast/build/llvm/tools/clang/lib/Parse/ParseDecl.cpp:1505:12

#15 0x72819fd in 
clang::Par

RE: [ReviewRequest] [Sema/Parser] GCC Compatibility Patch: Support for __final specifier

[Keane, Erich via cfe-commits]

I’ve put this review up on the Phabricator site so that it is easier to look 
at, see here: https://reviews.llvm.org/D22919

Thanks!
-Erich

From: David Majnemer [mailto:david.majne...@gmail.com]
Sent: Monday, July 25, 2016 1:18 PM
To: Keane, Erich 
Cc: cfe-commits@lists.llvm.org
Subject: Re: [ReviewRequest] [Sema/Parser] GCC Compatibility Patch: Support for 
__final specifier

You've added a comment describing the new enum value.  Please make sure the 
comment starts with a cap letter and ends with a period.

On Mon, Jul 25, 2016 at 4:09 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
Thanks for the quick review!  I’ve updated the patch with the name changes in 
the attached diff file.

From: David Majnemer 
[mailto:david.majne...@gmail.com<mailto:david.majne...@gmail.com>]
Sent: Monday, July 25, 2016 12:40 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>
Subject: Re: [ReviewRequest] [Sema/Parser] GCC Compatibility Patch: Support for 
__final specifier

I'd rename VS_Alt_Final to VS_GNU_Final.

On Mon, Jul 25, 2016 at 2:24 PM, Keane, Erich via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Hi all, my first potential-contribution, so I apologize if I’m submitting this 
improperly, I’m unfamiliar with the ‘type’ keys that you use in the topic, so 
hopefully I have this right.

As reported in bug 28473, GCC supports ‘final’ functionality in pre-C++11 code 
using the __final keyword.  Clang currently supports the ‘final’ keyword in 
accordance with the C++11 specification, however it ALSO supports it in 
pre-C++11 mode, with a warning.

This patch adds the ‘__final’ keyword for compatibility with GCC in GCC 
Keywords mode (so it is enabled with existing flags), and issues a warning on 
its usage (suggesting switching to the C++11 keyword).  This patch also adds a 
regression test for the functionality described.  I believe this patch has 
minimal impact, as it simply adds a new keyword for existing behavior.

This has been validated with check-clang to avoid regressions.  Patch is 
created in reference to revisions 276665

Thanks,
Erich

___
cfe-commits mailing list
cfe-commits@lists.llvm.org<mailto: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: [ReviewRequest] [Sema/Parser] GCC Compatibility Patch: Support for __final specifier

[Keane, Erich via cfe-commits]

Done!  Attached a new diff.

From: David Majnemer [mailto:david.majne...@gmail.com]
Sent: Monday, July 25, 2016 1:18 PM
To: Keane, Erich 
Cc: cfe-commits@lists.llvm.org
Subject: Re: [ReviewRequest] [Sema/Parser] GCC Compatibility Patch: Support for 
__final specifier

You've added a comment describing the new enum value.  Please make sure the 
comment starts with a cap letter and ends with a period.

On Mon, Jul 25, 2016 at 4:09 PM, Keane, Erich 
mailto:erich.ke...@intel.com>> wrote:
Thanks for the quick review!  I’ve updated the patch with the name changes in 
the attached diff file.

From: David Majnemer 
[mailto:david.majne...@gmail.com<mailto:david.majne...@gmail.com>]
Sent: Monday, July 25, 2016 12:40 PM
To: Keane, Erich mailto:erich.ke...@intel.com>>
Cc: cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>
Subject: Re: [ReviewRequest] [Sema/Parser] GCC Compatibility Patch: Support for 
__final specifier

I'd rename VS_Alt_Final to VS_GNU_Final.

On Mon, Jul 25, 2016 at 2:24 PM, Keane, Erich via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Hi all, my first potential-contribution, so I apologize if I’m submitting this 
improperly, I’m unfamiliar with the ‘type’ keys that you use in the topic, so 
hopefully I have this right.

As reported in bug 28473, GCC supports ‘final’ functionality in pre-C++11 code 
using the __final keyword.  Clang currently supports the ‘final’ keyword in 
accordance with the C++11 specification, however it ALSO supports it in 
pre-C++11 mode, with a warning.

This patch adds the ‘__final’ keyword for compatibility with GCC in GCC 
Keywords mode (so it is enabled with existing flags), and issues a warning on 
its usage (suggesting switching to the C++11 keyword).  This patch also adds a 
regression test for the functionality described.  I believe this patch has 
minimal impact, as it simply adds a new keyword for existing behavior.

This has been validated with check-clang to avoid regressions.  Patch is 
created in reference to revisions 276665

Thanks,
Erich

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




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

RE: [ReviewRequest] [Sema/Parser] GCC Compatibility Patch: Support for __final specifier

[Keane, Erich via cfe-commits]

Thanks for the quick review!  I’ve updated the patch with the name changes in 
the attached diff file.

From: David Majnemer [mailto:david.majne...@gmail.com]
Sent: Monday, July 25, 2016 12:40 PM
To: Keane, Erich 
Cc: cfe-commits@lists.llvm.org
Subject: Re: [ReviewRequest] [Sema/Parser] GCC Compatibility Patch: Support for 
__final specifier

I'd rename VS_Alt_Final to VS_GNU_Final.

On Mon, Jul 25, 2016 at 2:24 PM, Keane, Erich via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Hi all, my first potential-contribution, so I apologize if I’m submitting this 
improperly, I’m unfamiliar with the ‘type’ keys that you use in the topic, so 
hopefully I have this right.

As reported in bug 28473, GCC supports ‘final’ functionality in pre-C++11 code 
using the __final keyword.  Clang currently supports the ‘final’ keyword in 
accordance with the C++11 specification, however it ALSO supports it in 
pre-C++11 mode, with a warning.

This patch adds the ‘__final’ keyword for compatibility with GCC in GCC 
Keywords mode (so it is enabled with existing flags), and issues a warning on 
its usage (suggesting switching to the C++11 keyword).  This patch also adds a 
regression test for the functionality described.  I believe this patch has 
minimal impact, as it simply adds a new keyword for existing behavior.

This has been validated with check-clang to avoid regressions.  Patch is 
created in reference to revisions 276665

Thanks,
Erich

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



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

[ReviewRequest] [Sema/Parser] GCC Compatibility Patch: Support for __final specifier

[Keane, Erich via cfe-commits]

Hi all, my first potential-contribution, so I apologize if I'm submitting this 
improperly, I'm unfamiliar with the 'type' keys that you use in the topic, so 
hopefully I have this right.

As reported in bug 28473, GCC supports 'final' functionality in pre-C++11 code 
using the __final keyword.  Clang currently supports the 'final' keyword in 
accordance with the C++11 specification, however it ALSO supports it in 
pre-C++11 mode, with a warning.

This patch adds the '__final' keyword for compatibility with GCC in GCC 
Keywords mode (so it is enabled with existing flags), and issues a warning on 
its usage (suggesting switching to the C++11 keyword).  This patch also adds a 
regression test for the functionality described.  I believe this patch has 
minimal impact, as it simply adds a new keyword for existing behavior.

This has been validated with check-clang to avoid regressions.  Patch is 
created in reference to revisions 276665

Thanks,
Erich


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