[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation

2020-08-29 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added a comment.

In D86671#2246486 , @dougpuob wrote:

> In D86671#2246480 , @Eugene.Zelenko 
> wrote:
>
>> By the word, you must mention new option in documentation too.
>
> Hi @Eugene.Zelenko,
> Is the `clang-tools-extra/docs/ReleaseNotes.rst` file that you mentioned?
>
> If YES, seems pretty simple with one line at the end for the new casing type, 
> like:
>
>   Casing types include:
>   
>- ``lower_case``,
>- ``UPPER_CASE``,
>- ``camelBack``,
>- ``CamelCase``,
>- ``camel_Snake_Back``,
>- ``Camel_Snake_Case``,
>- ``aNy_CasE``,
>- ``szHungarianNotation``. 
>
> Is it right? and any more about document I have to do?

Yes, you are correct.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D86671

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


[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation

2020-08-29 Thread Douglas Chen via Phabricator via cfe-commits
dougpuob added a comment.

In D86671#2246480 , @Eugene.Zelenko 
wrote:

> By the word, you must mention new option in documentation too.

Hi @Eugene.Zelenko,
Is the `clang-tools-extra/docs/ReleaseNotes.rst` file that you mentioned?

If YES, seems pretty simple with one line at the end for the new casing type, 
like:

  Casing types include:
  
   - ``lower_case``,
   - ``UPPER_CASE``,
   - ``camelBack``,
   - ``CamelCase``,
   - ``camel_Snake_Back``,
   - ``Camel_Snake_Case``,
   - ``aNy_CasE``,
   - ``szHungarianNotation``. 

Is it right? and any more about document I have to do?


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D86671

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


[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation

2020-08-29 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added a comment.

By the word, you must mention new option in documentation too.




Comment at: clang-tools-extra/docs/ReleaseNotes.rst:73
 
+- Added: Support variables could be checked with Hungarian Notation which the
+  prefix encodes the actual data type of the variable.

dougpuob wrote:
> Eugene.Zelenko wrote:
> > See examples for entry format below.
> Make it like the following ?
> 
> ```
> Changes in existing checks
> ^^
> 
> - Improved :doc:`readability-identifier-naming
>   ` check.
> 
>   Added an option `GetConfigPerFile` to support including files which use
>   different naming styles.
> 
> - Improved :doc:`readability-identifier-naming
>   ` 
> check.  
> 
>   Support variables could be checked with Hungarian Notation which the prefix
>   encodes the actual data type of the variable.
> ```
Yes, but link must be `clang-tidy/checks/readability-identifier-naming`, 
because it refer to documentation file, not regression test.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D86671

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


[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation

2020-08-29 Thread Douglas Chen via Phabricator via cfe-commits
dougpuob marked an inline comment as done.
dougpuob added inline comments.



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:73
 
+- Added: Support variables could be checked with Hungarian Notation which the
+  prefix encodes the actual data type of the variable.

Eugene.Zelenko wrote:
> See examples for entry format below.
Make it like the following ?

```
Changes in existing checks
^^

- Improved :doc:`readability-identifier-naming
  ` check.

  Added an option `GetConfigPerFile` to support including files which use
  different naming styles.

- Improved :doc:`readability-identifier-naming
  ` 
check.  

  Support variables could be checked with Hungarian Notation which the prefix
  encodes the actual data type of the variable.
```


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D86671

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


[clang] 6ae7b40 - Set alignment of .llvmbc and .llvmcmd to 1

2020-08-29 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2020-08-29T18:27:34-07:00
New Revision: 6ae7b403c3e1aebcb825d3dd4777d3c1149d6d67

URL: 
https://github.com/llvm/llvm-project/commit/6ae7b403c3e1aebcb825d3dd4777d3c1149d6d67
DIFF: 
https://github.com/llvm/llvm-project/commit/6ae7b403c3e1aebcb825d3dd4777d3c1149d6d67.diff

LOG: Set alignment of .llvmbc and .llvmcmd to 1

Otherwise their alignment is dependent on the size of the section.  If the size
is large than 16, the alignment will be 16.

16 is a bad choice for both .llvmbc and .llvmcmd because the padding between two
contributions from input sections is of a variable size.

A bitstream is actually guaranteed to be 4-byte aligned, but consumers don't
need this property.

Added: 


Modified: 
clang/test/Frontend/embed-bitcode.ll
clang/test/Frontend/x86-embed-bitcode.ll
llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
llvm/test/CodeGen/X86/embed-bitcode.ll

Removed: 




diff  --git a/clang/test/Frontend/embed-bitcode.ll 
b/clang/test/Frontend/embed-bitcode.ll
index 75cdc5f657fc..defb2d12f2f0 100644
--- a/clang/test/Frontend/embed-bitcode.ll
+++ b/clang/test/Frontend/embed-bitcode.ll
@@ -43,9 +43,9 @@
 ; RUN:| FileCheck %s -check-prefix=CHECK-WARNING
 
 ; CHECK-ELF: @llvm.embedded.module
-; CHECK-ELF: section ".llvmbc"
+; CHECK-ELF-SAME: section ".llvmbc", align 1
 ; CHECK-ELF: @llvm.cmdline
-; CHECK-ELF: section ".llvmcmd"
+; CHECK-ELF-SAME: section ".llvmcmd", align 1
 
 ; CHECK-ONLY-BITCODE: @llvm.embedded.module = private constant
 ; CHECK-ONLY-BITCODE: c"\DE\C0\17\0B

diff  --git a/clang/test/Frontend/x86-embed-bitcode.ll 
b/clang/test/Frontend/x86-embed-bitcode.ll
index 709f56bdfe81..b49fa6247c16 100644
--- a/clang/test/Frontend/x86-embed-bitcode.ll
+++ b/clang/test/Frontend/x86-embed-bitcode.ll
@@ -43,17 +43,17 @@
 ; CHECK: section "__LLVM,__cmdline"
 
 ; CHECK-ELF: @llvm.embedded.module
-; CHECK-ELF: section ".llvmbc"
+; CHECK-ELF-SAME: section ".llvmbc", align 1
 ; CHECK-ELF: @llvm.cmdline
-; CHECK-ELF: section ".llvmcmd"
+; CHECK-ELF-SAME: section ".llvmcmd", align 1
 
 ; CHECK-ELF-MARKER: @llvm.embedded.module
 ; CHECK-ELF-MARKER: constant [0 x i8] zeroinitializer
 ; CHECK-ELF-MARKER: @llvm.cmdline
-; CHECK-ELF-MARKER: section ".llvmcmd"
+; CHECK-ELF-MARKER: section ".llvmcmd", align 1
 
 ; CHECK-ELF-ONLY-BITCODE: @llvm.embedded.module
-; CHECK-ELF-ONLY-BITCODE: section ".llvmbc"
+; CHECK-ELF-ONLY-BITCODE-SAME: section ".llvmbc", align 1
 ; CHECK-ELF-ONLY-BITCODE-NOT: @llvm.cmdline
 ; CHECK-ELF-ONLY-BITCODE-NOT: section ".llvmcmd"
 

diff  --git a/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp 
b/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
index f2630903dba1..eaea026681b1 100644
--- a/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
+++ b/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
@@ -4852,6 +4852,9 @@ void llvm::EmbedBitcodeInModule(llvm::Module , 
llvm::MemoryBufferRef Buf,
   M, ModuleConstant->getType(), true, llvm::GlobalValue::PrivateLinkage,
   ModuleConstant);
   GV->setSection(getSectionNameForBitcode(T));
+  // Set alignment to 1 to prevent padding between two contributions from input
+  // sections after linking.
+  GV->setAlignment(Align(1));
   UsedArray.push_back(
   ConstantExpr::getPointerBitCastOrAddrSpaceCast(GV, UsedElementType));
   if (llvm::GlobalVariable *Old =
@@ -4875,6 +4878,7 @@ void llvm::EmbedBitcodeInModule(llvm::Module , 
llvm::MemoryBufferRef Buf,
   llvm::GlobalValue::PrivateLinkage,
   CmdConstant);
 GV->setSection(getSectionNameForCommandline(T));
+GV->setAlignment(Align(1));
 UsedArray.push_back(
 ConstantExpr::getPointerBitCastOrAddrSpaceCast(GV, UsedElementType));
 if (llvm::GlobalVariable *Old = M.getGlobalVariable("llvm.cmdline", true)) 
{

diff  --git a/llvm/test/CodeGen/X86/embed-bitcode.ll 
b/llvm/test/CodeGen/X86/embed-bitcode.ll
index 00dd7ef17d56..8c56dfe2168f 100644
--- a/llvm/test/CodeGen/X86/embed-bitcode.ll
+++ b/llvm/test/CodeGen/X86/embed-bitcode.ll
@@ -5,6 +5,6 @@
 ; CHECK-NEXT: .llvmbc  PROGBITS  [[#%x,OFF:]] 04 000
 ; CHECK-NEXT: .llvmcmd PROGBITS  [[#%x,OFF:]] 05 000
 
-@llvm.embedded.module = private constant [4 x i8] c"BC\C0\DE", section 
".llvmbc"
-@llvm.cmdline = private constant [5 x i8] c"-cc1\00", section ".llvmcmd"
+@llvm.embedded.module = private constant [4 x i8] c"BC\C0\DE", section 
".llvmbc", align 1
+@llvm.cmdline = private constant [5 x i8] c"-cc1\00", section ".llvmcmd", 
align 1
 @llvm.compiler.used = appending global [2 x i8*] [i8* getelementptr inbounds 
([4 x i8], [4 x i8]* @llvm.embedded.module, i32 0, i32 0), i8* getelementptr 
inbounds ([5 x i8], [5 x i8]* @llvm.cmdline, i32 0, i32 0)], section 
"llvm.metadata"



___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[clang] 4fbf063 - Remove OpenBSD/sparc support

2020-08-29 Thread Brad Smith via cfe-commits

Author: Brad Smith
Date: 2020-08-29T20:47:18-04:00
New Revision: 4fbf0636a214abbc30b6eee42bd5b7755dfd5f38

URL: 
https://github.com/llvm/llvm-project/commit/4fbf0636a214abbc30b6eee42bd5b7755dfd5f38
DIFF: 
https://github.com/llvm/llvm-project/commit/4fbf0636a214abbc30b6eee42bd5b7755dfd5f38.diff

LOG: Remove OpenBSD/sparc support

Added: 


Modified: 
clang/lib/Basic/Targets.cpp
clang/lib/Driver/ToolChains/OpenBSD.cpp
clang/test/Driver/openbsd.c
clang/test/Driver/pic.c

Removed: 




diff  --git a/clang/lib/Basic/Targets.cpp b/clang/lib/Basic/Targets.cpp
index c0187fd27842..1126b647e37b 100644
--- a/clang/lib/Basic/Targets.cpp
+++ b/clang/lib/Basic/Targets.cpp
@@ -411,8 +411,6 @@ TargetInfo *AllocateTarget(const llvm::Triple ,
   return new SolarisTargetInfo(Triple, Opts);
 case llvm::Triple::NetBSD:
   return new NetBSDTargetInfo(Triple, Opts);
-case llvm::Triple::OpenBSD:
-  return new OpenBSDTargetInfo(Triple, Opts);
 case llvm::Triple::RTEMS:
   return new RTEMSTargetInfo(Triple, Opts);
 default:
@@ -426,8 +424,6 @@ TargetInfo *AllocateTarget(const llvm::Triple ,
   return new LinuxTargetInfo(Triple, Opts);
 case llvm::Triple::NetBSD:
   return new NetBSDTargetInfo(Triple, Opts);
-case llvm::Triple::OpenBSD:
-  return new OpenBSDTargetInfo(Triple, Opts);
 case llvm::Triple::RTEMS:
   return new RTEMSTargetInfo(Triple, Opts);
 default:

diff  --git a/clang/lib/Driver/ToolChains/OpenBSD.cpp 
b/clang/lib/Driver/ToolChains/OpenBSD.cpp
index 1177fba96562..5ca2fa0850e6 100644
--- a/clang/lib/Driver/ToolChains/OpenBSD.cpp
+++ b/clang/lib/Driver/ToolChains/OpenBSD.cpp
@@ -43,15 +43,6 @@ void openbsd::Assembler::ConstructJob(Compilation , const 
JobAction ,
 CmdArgs.push_back("-many");
 break;
 
-  case llvm::Triple::sparc:
-  case llvm::Triple::sparcel: {
-CmdArgs.push_back("-32");
-std::string CPU = getCPUName(Args, getToolChain().getTriple());
-CmdArgs.push_back(sparc::getSparcAsmModeForCPU(CPU, 
getToolChain().getTriple()));
-AddAssemblerKPIC(getToolChain(), Args, CmdArgs);
-break;
-  }
-
   case llvm::Triple::sparcv9: {
 CmdArgs.push_back("-64");
 std::string CPU = getCPUName(Args, getToolChain().getTriple());

diff  --git a/clang/test/Driver/openbsd.c b/clang/test/Driver/openbsd.c
index cee4539eaca2..203b4b4a2ff0 100644
--- a/clang/test/Driver/openbsd.c
+++ b/clang/test/Driver/openbsd.c
@@ -58,8 +58,6 @@
 // RUN:   | FileCheck -check-prefix=CHECK-AMD64-M32 %s
 // RUN: %clang -target powerpc-unknown-openbsd -### -no-integrated-as -c %s 
2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK-POWERPC %s
-// RUN: %clang -target sparc-unknown-openbsd -### -no-integrated-as -c %s 2>&1 
\
-// RUN:   | FileCheck -check-prefix=CHECK-SPARC %s
 // RUN: %clang -target sparc64-unknown-openbsd -### -no-integrated-as -c %s 
2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK-SPARC64 %s
 // RUN: %clang -target mips64-unknown-openbsd -### -no-integrated-as -c %s 
2>&1 \
@@ -72,7 +70,6 @@
 // RUN:   | FileCheck -check-prefix=CHECK-MIPS64EL-PIC %s
 // CHECK-AMD64-M32: as{{.*}}" "--32"
 // CHECK-POWERPC: as{{.*}}" "-mppc" "-many"
-// CHECK-SPARC: as{{.*}}" "-32" "-Av8"
 // CHECK-SPARC64: as{{.*}}" "-64" "-Av9"
 // CHECK-MIPS64: as{{.*}}" "-mabi" "64" "-EB"
 // CHECK-MIPS64-PIC: as{{.*}}" "-mabi" "64" "-EB" "-KPIC"
@@ -80,8 +77,6 @@
 // CHECK-MIPS64EL-PIC: as{{.*}}" "-mabi" "64" "-EL" "-KPIC"
 
 // Check that the integrated assembler is enabled for SPARC
-// RUN: %clang -target sparc-unknown-openbsd -### -c %s 2>&1 \
-// RUN:   | FileCheck -check-prefix=CHECK-IAS %s
 // RUN: %clang -target sparc64-unknown-openbsd -### -c %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHECK-IAS %s
 // CHECK-IAS-NOT: "-no-integrated-as"

diff  --git a/clang/test/Driver/pic.c b/clang/test/Driver/pic.c
index c0cdeb464cbf..57924cd1bbb4 100644
--- a/clang/test/Driver/pic.c
+++ b/clang/test/Driver/pic.c
@@ -253,8 +253,6 @@
 // RUN:   | FileCheck %s --check-prefix=CHECK-PIE1
 // RUN: %clang -c %s -target powerpc-unknown-openbsd -### 2>&1 \
 // RUN:   | FileCheck %s --check-prefix=CHECK-PIE2
-// RUN: %clang -c %s -target sparc-unknown-openbsd -### 2>&1 \
-// RUN:   | FileCheck %s --check-prefix=CHECK-PIE2
 // RUN: %clang -c %s -target sparc64-unknown-openbsd -### 2>&1 \
 // RUN:   | FileCheck %s --check-prefix=CHECK-PIE2
 // RUN: %clang -c %s -target i386-pc-openbsd -fno-pie -### 2>&1 \



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


[PATCH] D84603: Thread safety analysis: More consistent warning message

2020-08-29 Thread Aaron Puchert via Phabricator via cfe-commits
aaronpuchert marked 4 inline comments as done.
aaronpuchert added inline comments.



Comment at: clang/include/clang/Analysis/Analyses/ThreadSafety.h:205
 
+  /// Warn when calling a function that the negative capability is not held.
+  /// \param D -- The decl for the function requiring the negative capability.

Should probably be "**a** negative capability", silly copy-and-paste error.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84603

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


[PATCH] D84603: Thread safety analysis: More consistent warning message

2020-08-29 Thread Aaron Puchert via Phabricator via cfe-commits
aaronpuchert updated this revision to Diff 288820.
aaronpuchert added a comment.
Herald added a subscriber: danielkiss.

Remove "holding" and moved to a separate message because the overlap was 
getting smaller.

Also introduced a separate function because it's more consistent with the other 
functions and because we can't easily distinguish between negative and positive 
capabilities otherwise.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84603

Files:
  clang/include/clang/Analysis/Analyses/ThreadSafety.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Analysis/ThreadSafety.cpp
  clang/lib/Sema/AnalysisBasedWarnings.cpp
  clang/test/SemaCXX/warn-thread-safety-analysis.cpp
  clang/test/SemaCXX/warn-thread-safety-negative.cpp


Index: clang/test/SemaCXX/warn-thread-safety-negative.cpp
===
--- clang/test/SemaCXX/warn-thread-safety-negative.cpp
+++ clang/test/SemaCXX/warn-thread-safety-negative.cpp
@@ -50,7 +50,7 @@
   }
 
   void bar() {
-baz();// expected-warning {{calling function 'baz' requires 
holding  '!mu'}}
+baz();// expected-warning {{calling function 'baz' requires 
negative capability '!mu'}}
   }
 
   void baz() EXCLUSIVE_LOCKS_REQUIRED(!mu) {
Index: clang/test/SemaCXX/warn-thread-safety-analysis.cpp
===
--- clang/test/SemaCXX/warn-thread-safety-analysis.cpp
+++ clang/test/SemaCXX/warn-thread-safety-analysis.cpp
@@ -4985,7 +4985,7 @@
   }
 
   void bar() {
-bar2();   // expected-warning {{calling function 'bar2' requires 
holding  '!mu'}}
+bar2();   // expected-warning {{calling function 'bar2' requires 
negative capability '!mu'}}
   }
 
   void bar2() EXCLUSIVE_LOCKS_REQUIRED(!mu) {
Index: clang/lib/Sema/AnalysisBasedWarnings.cpp
===
--- clang/lib/Sema/AnalysisBasedWarnings.cpp
+++ clang/lib/Sema/AnalysisBasedWarnings.cpp
@@ -1892,6 +1892,13 @@
 Warnings.emplace_back(std::move(Warning), getNotes());
   }
 
+  void handleNegativeNotHeld(const NamedDecl *D, Name LockName,
+ SourceLocation Loc) override {
+PartialDiagnosticAt Warning(
+Loc, S.PDiag(diag::warn_fun_requires_negative_cap) << D << LockName);
+Warnings.emplace_back(std::move(Warning), getNotes());
+  }
+
   void handleFunExcludesLock(StringRef Kind, Name FunName, Name LockName,
  SourceLocation Loc) override {
 PartialDiagnosticAt Warning(Loc, S.PDiag(diag::warn_fun_excludes_mutex)
Index: clang/lib/Analysis/ThreadSafety.cpp
===
--- clang/lib/Analysis/ThreadSafety.cpp
+++ clang/lib/Analysis/ThreadSafety.cpp
@@ -1641,8 +1641,7 @@
 // Otherwise the negative requirement must be propagated to the caller.
 LDat = FSet.findLock(Analyzer->FactMan, Cp);
 if (!LDat) {
-  Analyzer->Handler.handleMutexNotHeld("", D, POK, Cp.toString(),
-   LK_Shared, Loc);
+  Analyzer->Handler.handleNegativeNotHeld(D, Cp.toString(), Loc);
 }
 return;
   }
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -3477,6 +3477,9 @@
 def warn_acquire_requires_negative_cap : Warning<
   "acquiring %0 '%1' requires negative capability '%2'">,
   InGroup, DefaultIgnore;
+def warn_fun_requires_negative_cap : Warning<
+  "calling function %0 requires negative capability '%1'">,
+  InGroup, DefaultIgnore;
 
 // Thread safety warnings on pass by reference
 def warn_guarded_pass_by_reference : Warning<
Index: clang/include/clang/Analysis/Analyses/ThreadSafety.h
===
--- clang/include/clang/Analysis/Analyses/ThreadSafety.h
+++ clang/include/clang/Analysis/Analyses/ThreadSafety.h
@@ -202,6 +202,14 @@
   virtual void handleNegativeNotHeld(StringRef Kind, Name LockName, Name Neg,
  SourceLocation Loc) {}
 
+  /// Warn when calling a function that the negative capability is not held.
+  /// \param D -- The decl for the function requiring the negative capability.
+  /// \param LockName -- The name for the lock expression, to be printed in the
+  /// diagnostic.
+  /// \param Loc -- The location of the protected operation.
+  virtual void handleNegativeNotHeld(const NamedDecl *D, Name LockName,
+ SourceLocation Loc) {}
+
   /// Warn when a function is called while an excluded mutex is locked. For
   /// example, the mutex may be locked inside the function.
   /// \param Kind -- the capability's name parameter (role, mutex, etc).


Index: 

[PATCH] D86841: [clang] Adds noprogress attribute deduction for infinite loops

2020-08-29 Thread Atmn Patel via Phabricator via cfe-commits
atmnpatel updated this revision to Diff 288818.
atmnpatel added a comment.

Fixed comment in C++ test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86841

Files:
  clang/lib/CodeGen/CGLoopInfo.cpp
  clang/lib/CodeGen/CGLoopInfo.h
  clang/lib/CodeGen/CGStmt.cpp
  clang/test/CodeGen/attr-noprogress.c
  clang/test/CodeGen/attr-noprogress.cpp

Index: clang/test/CodeGen/attr-noprogress.cpp
===
--- /dev/null
+++ clang/test/CodeGen/attr-noprogress.cpp
@@ -0,0 +1,55 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --check-attributes
+// RUN: %clang_cc1 -S -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: Function Attrs: noinline nounwind optnone noprogress
+// CHECK-LABEL: define {{[^@]+}}@_Z1fv
+// CHECK-SAME: () [[ATTR0:#.*]] {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:br label [[FOR_COND:%.*]]
+// CHECK:   for.cond:
+// CHECK-NEXT:br i1 true, label [[FOR_BODY:%.*]], label [[FOR_END:%.*]]
+// CHECK:   for.body:
+// CHECK-NEXT:br label [[FOR_COND]], !llvm.loop [[LOOP2:!.]]
+// CHECK:   for.end:
+// CHECK-NEXT:ret void
+//
+void f() {
+  for (; 1;) {
+  }
+}
+
+// CHECK: Function Attrs: noinline nounwind optnone noprogress
+// CHECK-LABEL: define {{[^@]+}}@_Z1wv
+// CHECK-SAME: () [[ATTR0]] {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:br label [[WHILE_BODY:%.*]]
+// CHECK:   while.body:
+// CHECK-NEXT:br label [[WHILE_BODY]], !llvm.loop [[LOOP4:!.]]
+//
+void w() {
+  while (1) {
+  }
+}
+
+// CHECK: Function Attrs: noinline nounwind optnone noprogress
+// CHECK-LABEL: define {{[^@]+}}@_Z1dv
+// CHECK-SAME: () [[ATTR0]] {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:br label [[DO_BODY:%.*]]
+// CHECK:   do.body:
+// CHECK-NEXT:br label [[DO_COND:%.*]]
+// CHECK:   do.cond:
+// CHECK-NEXT:br i1 true, label [[DO_BODY]], label [[DO_END:%.*]], !llvm.loop [[LOOP5:!.]]
+// CHECK:   do.end:
+// CHECK-NEXT:ret void
+//
+void d() {
+  do {
+
+  } while (1);
+}
+
+// CHECK: [[LOOP2]] = distinct !{[[LOOP2]], [[LOOP_MD:!.]]}
+// CHECK: [[LOOP_MD]] = !{!"llvm.loop.noprogress"}
+// CHECK: [[LOOP4]] = distinct !{[[LOOP4]], [[LOOP_MD]]}
+// CHECK: [[LOOP5]] = distinct !{[[LOOP5]], [[LOOP_MD]]}
Index: clang/test/CodeGen/attr-noprogress.c
===
--- /dev/null
+++ clang/test/CodeGen/attr-noprogress.c
@@ -0,0 +1,52 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --check-attributes
+// RUN: %clang_cc1 -S -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: Function Attrs: noinline nounwind optnone noprogress
+// CHECK-LABEL: @f(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:br label [[FOR_COND:%.*]]
+// CHECK:   for.cond:
+// CHECK-NEXT:br i1 true, label [[FOR_BODY:%.*]], label [[FOR_END:%.*]]
+// CHECK:   for.body:
+// CHECK-NEXT:br label [[FOR_COND]], !llvm.loop [[LOOP2:!.]]
+// CHECK:   for.end:
+// CHECK-NEXT:ret void
+//
+void f() {
+  for (; 1;) {
+  }
+}
+
+// CHECK: Function Attrs: noinline nounwind optnone noprogress
+// CHECK-LABEL: @w(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:br label [[WHILE_BODY:%.*]]
+// CHECK:   while.body:
+// CHECK-NEXT:br label [[WHILE_BODY]], !llvm.loop [[LOOP4:!.]]
+//
+void w() {
+  while (1) {
+  }
+}
+
+// CHECK: Function Attrs: noinline nounwind optnone noprogress
+// CHECK-LABEL: @d(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:br label [[DO_BODY:%.*]]
+// CHECK:   do.body:
+// CHECK-NEXT:br label [[DO_COND:%.*]]
+// CHECK:   do.cond:
+// CHECK-NEXT:br i1 true, label [[DO_BODY]], label [[DO_END:%.*]], !llvm.loop [[LOOP5:!.]]
+// CHECK:   do.end:
+// CHECK-NEXT:ret void
+//
+void d() {
+  do {
+
+  } while (1);
+}
+
+// CHECK: [[LOOP2]] = distinct !{[[LOOP2]], [[LOOP_MD:!.]]}
+// CHECK: [[LOOP_MD]] = !{!"llvm.loop.noprogress"}
+// CHECK: [[LOOP4]] = distinct !{[[LOOP4]], [[LOOP_MD]]}
+// CHECK: [[LOOP5]] = distinct !{[[LOOP5]], [[LOOP_MD]]}
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -736,10 +736,26 @@
   JumpDest LoopHeader = getJumpDestInCurrentScope("while.cond");
   EmitBlock(LoopHeader.getBlock());
 
+  // Evaluate the conditional in the while header.  C99 6.8.5.1: The
+  // evaluation of the controlling expression takes place before each
+  // execution of the loop body.
+  llvm::Value *BoolCondVal = EvaluateExprAsBool(S.getCond());
+
+  // while(1) is common, avoid extra exit blocks.  Be sure
+  // to correctly handle break/continue though.
+  bool EmitBoolCondBranch = true;
+  bool NoProgress = false;
+  if (llvm::ConstantInt *C = dyn_cast(BoolCondVal))
+if (C->isOne()) {
+  EmitBoolCondBranch = false;
+  CurFn->addFnAttr(llvm::Attribute::NoProgress);
+

[PATCH] D86841: [clang] Adds noprogress attribute deduction for infinite loops

2020-08-29 Thread Atmn Patel via Phabricator via cfe-commits
atmnpatel updated this revision to Diff 288817.
atmnpatel edited the summary of this revision.
atmnpatel added a comment.

Sorry, Fixed the test, added a C++ test. I checked the C++, OpenCL C, and 
OpenCL C++ specs and couldn't find anything that diverged from C spec in this 
regard, but none of them explicitly stated this behavior either.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86841

Files:
  clang/lib/CodeGen/CGLoopInfo.cpp
  clang/lib/CodeGen/CGLoopInfo.h
  clang/lib/CodeGen/CGStmt.cpp
  clang/test/CodeGen/attr-noprogress.c
  clang/test/CodeGen/attr-noprogress.cpp

Index: clang/test/CodeGen/attr-noprogress.cpp
===
--- /dev/null
+++ clang/test/CodeGen/attr-noprogress.cpp
@@ -0,0 +1,55 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --function-signature --check-attributes --force-update
+// RUN: %clang_cc1 -S -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: Function Attrs: noinline nounwind optnone noprogress
+// CHECK-LABEL: define {{[^@]+}}@_Z1fv
+// CHECK-SAME: () [[ATTR0:#.*]] {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:br label [[FOR_COND:%.*]]
+// CHECK:   for.cond:
+// CHECK-NEXT:br i1 true, label [[FOR_BODY:%.*]], label [[FOR_END:%.*]]
+// CHECK:   for.body:
+// CHECK-NEXT:br label [[FOR_COND]], !llvm.loop [[LOOP2:!.]]
+// CHECK:   for.end:
+// CHECK-NEXT:ret void
+//
+void f() {
+  for (; 1;) {
+  }
+}
+
+// CHECK: Function Attrs: noinline nounwind optnone noprogress
+// CHECK-LABEL: define {{[^@]+}}@_Z1wv
+// CHECK-SAME: () [[ATTR0]] {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:br label [[WHILE_BODY:%.*]]
+// CHECK:   while.body:
+// CHECK-NEXT:br label [[WHILE_BODY]], !llvm.loop [[LOOP4:!.]]
+//
+void w() {
+  while (1) {
+  }
+}
+
+// CHECK: Function Attrs: noinline nounwind optnone noprogress
+// CHECK-LABEL: define {{[^@]+}}@_Z1dv
+// CHECK-SAME: () [[ATTR0]] {
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:br label [[DO_BODY:%.*]]
+// CHECK:   do.body:
+// CHECK-NEXT:br label [[DO_COND:%.*]]
+// CHECK:   do.cond:
+// CHECK-NEXT:br i1 true, label [[DO_BODY]], label [[DO_END:%.*]], !llvm.loop [[LOOP5:!.]]
+// CHECK:   do.end:
+// CHECK-NEXT:ret void
+//
+void d() {
+  do {
+
+  } while (1);
+}
+
+// CHECK: [[LOOP2]] = distinct !{[[LOOP2]], [[LOOP_MD:!.]]}
+// CHECK: [[LOOP_MD]] = !{!"llvm.loop.noprogress"}
+// CHECK: [[LOOP4]] = distinct !{[[LOOP4]], [[LOOP_MD]]}
+// CHECK: [[LOOP5]] = distinct !{[[LOOP5]], [[LOOP_MD]]}
Index: clang/test/CodeGen/attr-noprogress.c
===
--- /dev/null
+++ clang/test/CodeGen/attr-noprogress.c
@@ -0,0 +1,52 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py UTC_ARGS: --check-attributes
+// RUN: %clang_cc1 -S -emit-llvm %s -o - | FileCheck %s
+
+// CHECK: Function Attrs: noinline nounwind optnone noprogress
+// CHECK-LABEL: @f(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:br label [[FOR_COND:%.*]]
+// CHECK:   for.cond:
+// CHECK-NEXT:br i1 true, label [[FOR_BODY:%.*]], label [[FOR_END:%.*]]
+// CHECK:   for.body:
+// CHECK-NEXT:br label [[FOR_COND]], !llvm.loop [[LOOP2:!.]]
+// CHECK:   for.end:
+// CHECK-NEXT:ret void
+//
+void f() {
+  for (; 1;) {
+  }
+}
+
+// CHECK: Function Attrs: noinline nounwind optnone noprogress
+// CHECK-LABEL: @w(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:br label [[WHILE_BODY:%.*]]
+// CHECK:   while.body:
+// CHECK-NEXT:br label [[WHILE_BODY]], !llvm.loop [[LOOP4:!.]]
+//
+void w() {
+  while (1) {
+  }
+}
+
+// CHECK: Function Attrs: noinline nounwind optnone noprogress
+// CHECK-LABEL: @d(
+// CHECK-NEXT:  entry:
+// CHECK-NEXT:br label [[DO_BODY:%.*]]
+// CHECK:   do.body:
+// CHECK-NEXT:br label [[DO_COND:%.*]]
+// CHECK:   do.cond:
+// CHECK-NEXT:br i1 true, label [[DO_BODY]], label [[DO_END:%.*]], !llvm.loop [[LOOP5:!.]]
+// CHECK:   do.end:
+// CHECK-NEXT:ret void
+//
+void d() {
+  do {
+
+  } while (1);
+}
+
+// CHECK: [[LOOP2]] = distinct !{[[LOOP2]], [[LOOP_MD:!.]]}
+// CHECK: [[LOOP_MD]] = !{!"llvm.loop.noprogress"}
+// CHECK: [[LOOP4]] = distinct !{[[LOOP4]], [[LOOP_MD]]}
+// CHECK: [[LOOP5]] = distinct !{[[LOOP5]], [[LOOP_MD]]}
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -736,10 +736,26 @@
   JumpDest LoopHeader = getJumpDestInCurrentScope("while.cond");
   EmitBlock(LoopHeader.getBlock());
 
+  // Evaluate the conditional in the while header.  C99 6.8.5.1: The
+  // evaluation of the controlling expression takes place before each
+  // execution of the loop body.
+  llvm::Value *BoolCondVal = EvaluateExprAsBool(S.getCond());
+
+  // while(1) is common, avoid extra exit blocks.  Be sure
+  // 

[PATCH] D33825: [clang-tidy] signal handler must be plain old function check

2020-08-29 Thread JF Bastien via Phabricator via cfe-commits
jfb requested changes to this revision.
jfb added a comment.
This revision now requires changes to proceed.

MSC54-CPP refers to POF, which as I pointed out above isn't relevant anymore. 
I'd much rather have a diagnostic which honors the state of things after 
http://wg21.link/p0270.

Additionally, lots of what MSC54-CPP intends is implementation-defined. We 
shouldn't diagnose for things that clang has defined as signal safe, at least 
not by default.

From the paper, I'd like to see tests for these:

- a call to any standard library function, except for plain lock-free atomic 
atomic operations and functions explicitly identified as signal-safe. [Note: 
This implicitly excludes the use of new and delete expressions that rely on a 
library-provided memory allocator. – end note]; -- here I'd like to explicitly 
see the list of signal-safe functions, and examples of ones that are not
- an access to an object with thread storage duration;
- a dynamic_cast expression;
- throwing of an exception;
- control entering a try-block or function-try-block; or
- initialization of a variable with static storage duration requiring dynamic 
initialization (3.6.3 [basic.start.dynamic], 6.7 [stmt.decl])). [ Note: Such 
initialization might occur because it is the first odr-use (3.2 
[basic.def.odr]) of that variable. -- end note ]
- waiting for the completion of the initialization of a variable with static 
storage duration (6.7 [stmt.decl]).




Comment at: 
clang-tools-extra/clang-tidy/cert/SignalHandlerMustBePlainOldFunctionCheck.cpp:84
+  else if (llvm::isa(stmt))
+return "Construction of an unresolved type here";
+  else

Most of the above are fine per p0270, and most don't have a test at the moment. 



Comment at: clang-tools-extra/docs/clang-tidy/checks/cert-msc54-cpp.rst:15
+static void sig_handler(int sig) {}
+// warning: use 'external C' prefix for signal handlers
+

'extern', not 'external'



Comment at: clang-tools-extra/docs/clang-tidy/checks/cert-msc54-cpp.rst:23
+extern "C" void cpp_signal_handler(int sig) {
+  // warning: do not use C++ constructs in signal handlers
+  throw "error message";

Update the example too.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp:74
+  // CHECK-MESSAGES: :[[@LINE+2]]:3: note: function called here
+  // CHECK-MESSAGES: TestClass::static_function();
+  TestClass::static_function();

I don't think this should diagnose, it is signal safe for clang's 
implementation, and allowed by p0270.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp:91
+  auto char c = '1';
+  extern _Thread_local double _Complex d;
+  static const unsigned long int i = sizeof(float);

_Thread_local isn't signal safe per p0270.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp:114
+  do {
+_Atomic int v = _Alignof(char);
+_Static_assert(42 == 42, "True");

The atomic isn't used here, and atomic initialization isn't atomic, so the test 
isn't sufficient.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D33825

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


[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation

2020-08-29 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added inline comments.



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:73
 
+- Added: Support variables could be checked with Hungarian Notation which the
+  prefix encodes the actual data type of the variable.

See examples for entry format below.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D86671

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


[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation

2020-08-29 Thread Douglas Chen via Phabricator via cfe-commits
dougpuob marked 8 inline comments as done.
dougpuob added a comment.

I fixed all review suggestions from @aaron.ballman, @Eugene.Zelenko, and 
@njames93, Thank you. But I still can't sure I did everything correct.

I encountered a problem when I use `arc diff` or `arc diff --update D86671`, 
Arcanist will create a new Review(D86838 ) to 
Phabricator. This makes me to update the diff on the web interface.

Another behavior I can't sure do I did it right. I will pull the latest master 
then create a new local branch(my-new-branch) then manually merge the diff from 
previous branch(my-prev-branch). After this I use `git diff HEAD~1 -U99 > 
mypatch.patch`, then update the diff, `mypatch.patch` file to Phabricator. Is 
it right? Or is there a smarter way to do it?


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D86671

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


[PATCH] D86671: [clang-tidy] Add new case type to check variables with Hungarian notation

2020-08-29 Thread Douglas Chen via Phabricator via cfe-commits
dougpuob updated this revision to Diff 288812.
dougpuob added a comment.
Herald added a subscriber: danielkiss.

Improved for suggestions of code review.

1. Moved release notes to `Changes in existing checks` section. Eugene.Zelenko]
2. Modified release notes can be describe user-facing. [Eugene.Zelenko]
3. Added newline at the end to 
`readability-identifier-naming-hungarain-notion.cpp` file. [Eugene.Zelenko]
4. Removed unrelated change. [Nathan James]
5. Renamed getDeclFailureInfo() --> GetDeclFailureInfo() for local consistency. 
[Aaron Ballman]


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D86671

Files:
  clang-tools-extra/clang-tidy/bugprone/ReservedIdentifierCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/ReservedIdentifierCheck.h
  clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp
  clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.h
  clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
  clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming-hungarian-notation.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming-hungarian-notation.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming-hungarian-notation.cpp
@@ -0,0 +1,103 @@
+#include 
+#include 
+
+// RUN: %check_clang_tidy %s readability-identifier-naming %t -- \
+// RUN:   -config="{CheckOptions: [\
+// RUN:   {key: readability-identifier-naming.VariableCase, value: szHungarianNotation}, \
+// RUN:   ]}"
+
+const char *NamePtr = "Name";
+// CHECK-MESSAGES: :[[@LINE-1]]:13: warning: invalid case style for variable 'NamePtr' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}const char *szNamePtr = "Name";
+
+const char NameArray[] = "Name";
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: invalid case style for variable 'NameArray' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}const char szNameArray[] = "Name";
+
+void *BufferPtr1 = NULL;
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: invalid case style for variable 'BufferPtr1' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}void *pBufferPtr1 = NULL;
+
+void **BufferPtr2 = NULL;
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: invalid case style for variable 'BufferPtr2' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}void **ppBufferPtr2 = NULL;
+
+void **pBufferPtr3 = NULL;
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: invalid case style for variable 'pBufferPtr3' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}void **ppBufferPtr3 = NULL;
+
+int8_t ValueI8 = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: invalid case style for variable 'ValueI8' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}int8_t i8ValueI8 = 0;
+
+int16_t ValueI16 = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: invalid case style for variable 'ValueI16' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}int16_t i16ValueI16 = 0;
+
+int32_t ValueI32 = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: invalid case style for variable 'ValueI32' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}int32_t i32ValueI32 = 0;
+
+int64_t ValueI64 = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: invalid case style for variable 'ValueI64' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}int64_t i64ValueI64 = 0;
+
+uint8_t ValueU8 = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: invalid case style for variable 'ValueU8' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}uint8_t u8ValueU8 = 0;
+
+uint16_t ValueU16 = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: invalid case style for variable 'ValueU16' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}uint16_t u16ValueU16 = 0;
+
+uint32_t ValueU32 = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: invalid case style for variable 'ValueU32' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}uint32_t u32ValueU32 = 0;
+
+uint64_t ValueU64 = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: invalid case style for variable 'ValueU64' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}uint64_t u64ValueU64 = 0;
+
+float ValueFloat = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: invalid case style for variable 'ValueFloat' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}float fValueFloat = 0;
+
+double ValueDouble = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: invalid case style for variable 'ValueDouble' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}double dValueDouble = 0;
+
+char ValueChar = 'c';
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: invalid case style for variable 'ValueChar' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}char cValueChar = 'c';
+
+bool ValueBool = true;
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: invalid 

[PATCH] D86841: [clang] Adds noprogress attribute deduction for infinite loops

2020-08-29 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

Does that wording apply to both the C and C++ (OpenCL?)?
Regardless, might be good to test that.




Comment at: clang/test/CodeGen/attr-noprogress.c:1-2
+// RUN: %clang_cc1 -S -emit-llvm %s -o - | grep " noprogress " | count 1
+// RUN: %clang_cc1 -S -emit-llvm %s -o - | grep llvm.loop.noprogress | count 1
+

Please just FileCheck the expected output. Bonus points for using 
`llvm/utils/update_cc_test_checks.py`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86841

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


[PATCH] D86841: [clang] Adds noprogress attribute deduction for infinite loops

2020-08-29 Thread Atmn Patel via Phabricator via cfe-commits
atmnpatel created this revision.
atmnpatel added reviewers: jdoerfert, aqjune, RalfJung.
Herald added subscribers: cfe-commits, danielkiss.
Herald added a project: clang.
atmnpatel requested review of this revision.

The `noprogress` LLVM IR attribute currently under discussion is deduced for 
functions that contain loops that have a constant non-zero conditional as per 
the C Spec. In addition, these particular loops have an additional bit of 
metadata `llvm.loop.noprogress` so llvm can differentiate between the loops 
that can be optimized out and ones that can't be optimized out. The changes to 
the LoopDeletion pass is incoming.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86841

Files:
  clang/lib/CodeGen/CGLoopInfo.cpp
  clang/lib/CodeGen/CGLoopInfo.h
  clang/lib/CodeGen/CGStmt.cpp
  clang/test/CodeGen/attr-noprogress.c

Index: clang/test/CodeGen/attr-noprogress.c
===
--- /dev/null
+++ clang/test/CodeGen/attr-noprogress.c
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -S -emit-llvm %s -o - | grep " noprogress " | count 1
+// RUN: %clang_cc1 -S -emit-llvm %s -o - | grep llvm.loop.noprogress | count 1
+
+void f() {
+  for (; 1;) {
+  }
+}
+
+void w() {
+  while (1) {
+  }
+}
+
+void d() {
+  do {
+
+  } while (1);
+}
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -736,10 +736,26 @@
   JumpDest LoopHeader = getJumpDestInCurrentScope("while.cond");
   EmitBlock(LoopHeader.getBlock());
 
+  // Evaluate the conditional in the while header.  C99 6.8.5.1: The
+  // evaluation of the controlling expression takes place before each
+  // execution of the loop body.
+  llvm::Value *BoolCondVal = EvaluateExprAsBool(S.getCond());
+
+  // while(1) is common, avoid extra exit blocks.  Be sure
+  // to correctly handle break/continue though.
+  bool EmitBoolCondBranch = true;
+  bool NoProgress = false;
+  if (llvm::ConstantInt *C = dyn_cast(BoolCondVal))
+if (C->isOne()) {
+  EmitBoolCondBranch = false;
+  CurFn->addFnAttr(llvm::Attribute::NoProgress);
+  NoProgress = true;
+}
+
   const SourceRange  = S.getSourceRange();
   LoopStack.push(LoopHeader.getBlock(), CGM.getContext(), CGM.getCodeGenOpts(),
  WhileAttrs, SourceLocToDebugLoc(R.getBegin()),
- SourceLocToDebugLoc(R.getEnd()));
+ SourceLocToDebugLoc(R.getEnd()), NoProgress);
 
   // Create an exit block for when the condition fails, which will
   // also become the break target.
@@ -760,18 +776,6 @@
   if (S.getConditionVariable())
 EmitDecl(*S.getConditionVariable());
 
-  // Evaluate the conditional in the while header.  C99 6.8.5.1: The
-  // evaluation of the controlling expression takes place before each
-  // execution of the loop body.
-  llvm::Value *BoolCondVal = EvaluateExprAsBool(S.getCond());
-
-  // while(1) is common, avoid extra exit blocks.  Be sure
-  // to correctly handle break/continue though.
-  bool EmitBoolCondBranch = true;
-  if (llvm::ConstantInt *C = dyn_cast(BoolCondVal))
-if (C->isOne())
-  EmitBoolCondBranch = false;
-
   // As long as the condition is true, go to the loop body.
   llvm::BasicBlock *LoopBody = createBasicBlock("while.body");
   if (EmitBoolCondBranch) {
@@ -838,27 +842,33 @@
 
   EmitBlock(LoopCond.getBlock());
 
-  const SourceRange  = S.getSourceRange();
-  LoopStack.push(LoopBody, CGM.getContext(), CGM.getCodeGenOpts(), DoAttrs,
- SourceLocToDebugLoc(R.getBegin()),
- SourceLocToDebugLoc(R.getEnd()));
-
-  // C99 6.8.5.2: "The evaluation of the controlling expression takes place
-  // after each execution of the loop body."
-
   // Evaluate the conditional in the while header.
   // C99 6.8.5p2/p4: The first substatement is executed if the expression
   // compares unequal to 0.  The condition must be a scalar type.
   llvm::Value *BoolCondVal = EvaluateExprAsBool(S.getCond());
 
-  BreakContinueStack.pop_back();
-
   // "do {} while (0)" is common in macros, avoid extra blocks.  Be sure
   // to correctly handle break/continue though.
   bool EmitBoolCondBranch = true;
-  if (llvm::ConstantInt *C = dyn_cast(BoolCondVal))
+  bool NoProgress = false;
+  if (llvm::ConstantInt *C = dyn_cast(BoolCondVal)) {
 if (C->isZero())
   EmitBoolCondBranch = false;
+if (C->isOne()) {
+  CurFn->addFnAttr(llvm::Attribute::NoProgress);
+  NoProgress = true;
+}
+  }
+
+  const SourceRange  = S.getSourceRange();
+  LoopStack.push(LoopBody, CGM.getContext(), CGM.getCodeGenOpts(), DoAttrs,
+ SourceLocToDebugLoc(R.getBegin()),
+ SourceLocToDebugLoc(R.getEnd()), NoProgress);
+
+  // C99 6.8.5.2: "The evaluation of the controlling expression takes place
+  // after each execution of the loop body."
+
+  BreakContinueStack.pop_back();
 
   // As long as the condition is 

[PATCH] D77491: [Sema] Introduce BuiltinAttr, per-declaration builtin-ness

2020-08-29 Thread Raul Tambre via Phabricator via cfe-commits
tambre added a comment.

Please review. I would like to get this in a mergeable state.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77491

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


[PATCH] D86838: Improved for suggestions of code review. 1. Moved release notes to `Changes in existing checks` section. [Eugene.Zelenko] 2. Modified release notes can be describe user-facing. [Eu

2020-08-29 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added a comment.

You need just upload new diff into existing Phabricator revision, not create 
new one.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86838

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


[PATCH] D77491: [Sema] Introduce BuiltinAttr, per-declaration builtin-ness

2020-08-29 Thread Raul Tambre via Phabricator via cfe-commits
tambre updated this revision to Diff 288792.
tambre added a comment.
Herald added subscribers: danielkiss, jfb.

Rebase, fix new MS builtins and other tests, XFAIL pthread_create() test


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77491

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/Builtins.def
  clang/include/clang/Basic/IdentifierTable.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Decl.cpp
  clang/lib/Headers/intrin.h
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaLookup.cpp
  clang/test/AST/ast-dump-attr.cpp
  clang/test/Analysis/bstring.cpp
  clang/test/CodeGen/builtin-redeclaration.c
  clang/test/CodeGen/callback_pthread_create.c
  clang/test/Sema/implicit-builtin-decl.c
  clang/test/Sema/warn-fortify-source.c
  clang/test/SemaCXX/cxx11-compat.cpp
  clang/test/SemaCXX/warn-unused-local-typedef.cpp

Index: clang/test/SemaCXX/warn-unused-local-typedef.cpp
===
--- clang/test/SemaCXX/warn-unused-local-typedef.cpp
+++ clang/test/SemaCXX/warn-unused-local-typedef.cpp
@@ -67,10 +67,10 @@
 
 void test() {
   typedef signed long int superint; // no diag
-  printf("%f", (superint) 42);
+  printf("%ld", (superint)42);
 
   typedef signed long int superint2; // no diag
-  printf("%f", static_cast(42));
+  printf("%ld", static_cast(42));
 
 #pragma clang diagnostic push
 #pragma clang diagnostic ignored "-Wunused-local-typedef"
Index: clang/test/SemaCXX/cxx11-compat.cpp
===
--- clang/test/SemaCXX/cxx11-compat.cpp
+++ clang/test/SemaCXX/cxx11-compat.cpp
@@ -31,7 +31,7 @@
 s = { n }, // expected-warning {{non-constant-expression cannot be narrowed from type 'int' to 'char' in initializer list in C++11}} expected-note {{explicit cast}}
 t = { 1234 }; // expected-warning {{constant expression evaluates to 1234 which cannot be narrowed to type 'char' in C++11}} expected-warning {{changes value}} expected-note {{explicit cast}}
 
-#define PRIuS "uS"
+#define PRIuS "zu"
 int printf(const char *, ...);
 typedef __typeof(sizeof(int)) size_t;
 void h(size_t foo, size_t bar) {
Index: clang/test/Sema/warn-fortify-source.c
===
--- clang/test/Sema/warn-fortify-source.c
+++ clang/test/Sema/warn-fortify-source.c
@@ -1,8 +1,6 @@
 // RUN: %clang_cc1 -triple x86_64-apple-macosx10.14.0 %s -verify
-// RUN: %clang_cc1 -triple x86_64-apple-macosx10.14.0 %s -verify -DUSE_PASS_OBJECT_SIZE
 // RUN: %clang_cc1 -triple x86_64-apple-macosx10.14.0 %s -verify -DUSE_BUILTINS
 // RUN: %clang_cc1 -xc++ -triple x86_64-apple-macosx10.14.0 %s -verify
-// RUN: %clang_cc1 -xc++ -triple x86_64-apple-macosx10.14.0 %s -verify -DUSE_PASS_OBJECT_SIZE
 // RUN: %clang_cc1 -xc++ -triple x86_64-apple-macosx10.14.0 %s -verify -DUSE_BUILTINS
 
 typedef unsigned long size_t;
@@ -13,13 +11,7 @@
 
 extern int sprintf(char *str, const char *format, ...);
 
-#if defined(USE_PASS_OBJECT_SIZE)
-void *memcpy(void *dst, const void *src, size_t c);
-static void *memcpy(void *dst __attribute__((pass_object_size(1))), const void *src, size_t c) __attribute__((overloadable)) __asm__("merp");
-static void *memcpy(void *const dst __attribute__((pass_object_size(1))), const void *src, size_t c) __attribute__((overloadable)) {
-  return 0;
-}
-#elif defined(USE_BUILTINS)
+#if defined(USE_BUILTINS)
 #define memcpy(x,y,z) __builtin_memcpy(x,y,z)
 #else
 void *memcpy(void *dst, const void *src, size_t c);
@@ -45,14 +37,7 @@
   };
   struct pair p;
   char buf[20];
-  memcpy(, buf, 20);
-#ifdef USE_PASS_OBJECT_SIZE
-  // Use the more strict checking mode on the pass_object_size attribute:
-  // expected-warning@-3 {{memcpy' will always overflow; destination buffer has size 4, but size argument is 20}}
-#else
-  // Or just fallback to type 0:
-  // expected-warning@-6 {{memcpy' will always overflow; destination buffer has size 8, but size argument is 20}}
-#endif
+  memcpy(, buf, 20); // expected-warning {{memcpy' will always overflow; destination buffer has size 8, but size argument is 20}}
 }
 
 void call_strncat() {
Index: clang/test/Sema/implicit-builtin-decl.c
===
--- clang/test/Sema/implicit-builtin-decl.c
+++ clang/test/Sema/implicit-builtin-decl.c
@@ -1,5 +1,4 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s
-// RUN: not %clang_cc1 -fsyntax-only -ast-dump %s | FileCheck %s
 
 void f() {
   int *ptr = malloc(sizeof(int) * 10); // expected-warning{{implicitly declaring library function 'malloc' with type}} \
@@ -63,9 +62,5 @@
 struct __jmp_buf_tag {};
 void sigsetjmp(struct __jmp_buf_tag[1], int); // expected-warning{{declaration of built-in function 'sigsetjmp' requires the declaration of the 'jmp_buf' type, commonly provided in the header .}}
 
-// CHECK: FunctionDecl 

[PATCH] D86838: Improved for suggestions of code review. 1. Moved release notes to `Changes in existing checks` section. [Eugene.Zelenko] 2. Modified release notes can be describe user-facing. [Eu

2020-08-29 Thread Douglas Chen via Phabricator via cfe-commits
dougpuob created this revision.
Herald added subscribers: cfe-commits, danielkiss.
Herald added a project: clang.
dougpuob requested review of this revision.

...-identifier-naming-hungarain-notion.cpp` file. [Eugene.Zelenko]   4. Removed 
unrelated change. [Nathan James]   5. Renamed getDeclFailureInfo() --> 
GetDeclFailureInfo() for local consistency. [Aaron Ballman]


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D86838

Files:
  clang-tools-extra/clang-tidy/bugprone/ReservedIdentifierCheck.cpp
  clang-tools-extra/clang-tidy/bugprone/ReservedIdentifierCheck.h
  clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp
  clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.h
  clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
  clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming-hungarian-notation.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming-hungarian-notation.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming-hungarian-notation.cpp
@@ -0,0 +1,103 @@
+#include 
+#include 
+
+// RUN: %check_clang_tidy %s readability-identifier-naming %t -- \
+// RUN:   -config="{CheckOptions: [\
+// RUN:   {key: readability-identifier-naming.VariableCase, value: szHungarianNotation}, \
+// RUN:   ]}"
+
+const char *NamePtr = "Name";
+// CHECK-MESSAGES: :[[@LINE-1]]:13: warning: invalid case style for variable 'NamePtr' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}const char *szNamePtr = "Name";
+
+const char NameArray[] = "Name";
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: invalid case style for variable 'NameArray' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}const char szNameArray[] = "Name";
+
+void *BufferPtr1 = NULL;
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: invalid case style for variable 'BufferPtr1' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}void *pBufferPtr1 = NULL;
+
+void **BufferPtr2 = NULL;
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: invalid case style for variable 'BufferPtr2' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}void **ppBufferPtr2 = NULL;
+
+void **pBufferPtr3 = NULL;
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: invalid case style for variable 'pBufferPtr3' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}void **ppBufferPtr3 = NULL;
+
+int8_t ValueI8 = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: invalid case style for variable 'ValueI8' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}int8_t i8ValueI8 = 0;
+
+int16_t ValueI16 = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: invalid case style for variable 'ValueI16' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}int16_t i16ValueI16 = 0;
+
+int32_t ValueI32 = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: invalid case style for variable 'ValueI32' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}int32_t i32ValueI32 = 0;
+
+int64_t ValueI64 = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: invalid case style for variable 'ValueI64' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}int64_t i64ValueI64 = 0;
+
+uint8_t ValueU8 = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: invalid case style for variable 'ValueU8' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}uint8_t u8ValueU8 = 0;
+
+uint16_t ValueU16 = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: invalid case style for variable 'ValueU16' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}uint16_t u16ValueU16 = 0;
+
+uint32_t ValueU32 = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: invalid case style for variable 'ValueU32' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}uint32_t u32ValueU32 = 0;
+
+uint64_t ValueU64 = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:10: warning: invalid case style for variable 'ValueU64' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}uint64_t u64ValueU64 = 0;
+
+float ValueFloat = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: invalid case style for variable 'ValueFloat' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}float fValueFloat = 0;
+
+double ValueDouble = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: invalid case style for variable 'ValueDouble' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}double dValueDouble = 0;
+
+char ValueChar = 'c';
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: invalid case style for variable 'ValueChar' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}char cValueChar = 'c';
+
+bool ValueBool = true;
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: invalid case style for variable 'ValueBool' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}bool bValueBool = true;
+
+int ValueInt = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: invalid case style for variable 'ValueInt' 

[clang] 85fce44 - [Sema] Simplify ShouldDiagnoseUnusedDecl, NFC

2020-08-29 Thread Aaron Puchert via cfe-commits

Author: Aaron Puchert
Date: 2020-08-29T18:42:58+02:00
New Revision: 85fce449dc43447bf9d75163bda81e157f5b73e7

URL: 
https://github.com/llvm/llvm-project/commit/85fce449dc43447bf9d75163bda81e157f5b73e7
DIFF: 
https://github.com/llvm/llvm-project/commit/85fce449dc43447bf9d75163bda81e157f5b73e7.diff

LOG: [Sema] Simplify ShouldDiagnoseUnusedDecl, NFC

Instead of writing to a flag and then returning based on that flag we
can also return directly. The flag name also doesn't provide additional
information, it just reflects the name of the function (isReferenced).

Added: 


Modified: 
clang/lib/Sema/SemaDecl.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index fba590f44c20..a9e6113dc7bb 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -1763,25 +1763,20 @@ static bool ShouldDiagnoseUnusedDecl(const NamedDecl 
*D) {
   if (D->isInvalidDecl())
 return false;
 
-  bool Referenced = false;
   if (auto *DD = dyn_cast(D)) {
 // For a decomposition declaration, warn if none of the bindings are
 // referenced, instead of if the variable itself is referenced (which
 // it is, by the bindings' expressions).
-for (auto *BD : DD->bindings()) {
-  if (BD->isReferenced()) {
-Referenced = true;
-break;
-  }
-}
+for (auto *BD : DD->bindings())
+  if (BD->isReferenced())
+return false;
   } else if (!D->getDeclName()) {
 return false;
   } else if (D->isReferenced() || D->isUsed()) {
-Referenced = true;
+return false;
   }
 
-  if (Referenced || D->hasAttr() ||
-  D->hasAttr())
+  if (D->hasAttr() || D->hasAttr())
 return false;
 
   if (isa(D))



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


[clang] b4a2d36 - [Sema] ICK_Function_Conversion is a third kind conversion

2020-08-29 Thread Aaron Puchert via cfe-commits

Author: Aaron Puchert
Date: 2020-08-29T18:42:36+02:00
New Revision: b4a2d36c3f74ea5574cd03a9c1a704bcffb1869e

URL: 
https://github.com/llvm/llvm-project/commit/b4a2d36c3f74ea5574cd03a9c1a704bcffb1869e
DIFF: 
https://github.com/llvm/llvm-project/commit/b4a2d36c3f74ea5574cd03a9c1a704bcffb1869e.diff

LOG: [Sema] ICK_Function_Conversion is a third kind conversion

Not sure if this has any effect, but it was inconsistent before.

Reviewed By: rsmith

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

Added: 


Modified: 
clang/lib/Sema/SemaOverload.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index ec7c41e8ed09..21a9ad04d500 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -5515,7 +5515,6 @@ static bool CheckConvertedConstantConversions(Sema ,
   // conversions are fine.
   switch (SCS.Second) {
   case ICK_Identity:
-  case ICK_Function_Conversion:
   case ICK_Integral_Promotion:
   case ICK_Integral_Conversion: // Narrowing conversions are checked elsewhere.
   case ICK_Zero_Queue_Conversion:
@@ -5562,6 +5561,7 @@ static bool CheckConvertedConstantConversions(Sema ,
   case ICK_Function_To_Pointer:
 llvm_unreachable("found a first conversion kind in Second");
 
+  case ICK_Function_Conversion:
   case ICK_Qualification:
 llvm_unreachable("found a third conversion kind in Second");
 



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


[PATCH] D67113: ICK_Function_Conversion is a third kind conversion

2020-08-29 Thread Aaron Puchert via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGb4a2d36c3f74: [Sema] ICK_Function_Conversion is a third kind 
conversion (authored by aaronpuchert).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67113

Files:
  clang/lib/Sema/SemaOverload.cpp


Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -5515,7 +5515,6 @@
   // conversions are fine.
   switch (SCS.Second) {
   case ICK_Identity:
-  case ICK_Function_Conversion:
   case ICK_Integral_Promotion:
   case ICK_Integral_Conversion: // Narrowing conversions are checked elsewhere.
   case ICK_Zero_Queue_Conversion:
@@ -5562,6 +5561,7 @@
   case ICK_Function_To_Pointer:
 llvm_unreachable("found a first conversion kind in Second");
 
+  case ICK_Function_Conversion:
   case ICK_Qualification:
 llvm_unreachable("found a third conversion kind in Second");
 


Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -5515,7 +5515,6 @@
   // conversions are fine.
   switch (SCS.Second) {
   case ICK_Identity:
-  case ICK_Function_Conversion:
   case ICK_Integral_Promotion:
   case ICK_Integral_Conversion: // Narrowing conversions are checked elsewhere.
   case ICK_Zero_Queue_Conversion:
@@ -5562,6 +5561,7 @@
   case ICK_Function_To_Pointer:
 llvm_unreachable("found a first conversion kind in Second");
 
+  case ICK_Function_Conversion:
   case ICK_Qualification:
 llvm_unreachable("found a third conversion kind in Second");
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D14484: [clang-format] Formatting constructor initializer lists by putting them always on different lines

2020-08-29 Thread Francesco Stefanni via Phabricator via cfe-commits
FStefanni added a comment.
Herald added a subscriber: danielkiss.

Hi to all,

I am also interested to this option, since match my personal style, but more 
important, in my experience, this kind of formatting is very used.
I hope it will be implemented in a near future.

Which is the current status? Is someone going to support this?

Regards.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D14484

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


[PATCH] D85091: [Sema, CodeGen] Implement [[likely]] and [[unlikely]] in IfStmt

2020-08-29 Thread Mark de Wever via Phabricator via cfe-commits
Mordante updated this revision to Diff 288781.
Mordante marked an inline comment as done.
Mordante added a comment.

Reworked the patch to match the behaviour as discussed in D86559 
.

- The likelihood attributes only have an effect when used directly on the 
ThenStmt and ElseStmt.
- Conflicting attributes on the ThenStmt and ElseStmt generate a diagnostic.
- Moved the likelihood determination from the CodeGen to the Sema. This 
requires the state to be stored in the AST.
- Updated the AST functions for the new likelihood bits.
- Updated the documentation.

Note currently there's no diagnostic for ignored attributes, this will be added 
in a future patch.


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

https://reviews.llvm.org/D85091

Files:
  clang/include/clang/AST/Stmt.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/JSONNodeDumper.cpp
  clang/lib/AST/Stmt.cpp
  clang/lib/AST/TextNodeDumper.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaStmtAttr.cpp
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/test/AST/ast-dump-if-json.cpp
  clang/test/AST/ast-dump-stmt.cpp
  clang/test/CodeGenCXX/attr-likelihood-if-branch-weights.cpp
  clang/test/Preprocessor/has_attribute.cpp
  clang/test/Sema/attr-likelihood.c
  clang/test/SemaCXX/attr-likelihood.cpp
  clang/www/cxx_status.html
  llvm/include/llvm/Transforms/Scalar/LowerExpectIntrinsic.h
  llvm/lib/Transforms/Scalar/LowerExpectIntrinsic.cpp

Index: llvm/lib/Transforms/Scalar/LowerExpectIntrinsic.cpp
===
--- llvm/lib/Transforms/Scalar/LowerExpectIntrinsic.cpp
+++ llvm/lib/Transforms/Scalar/LowerExpectIntrinsic.cpp
@@ -24,7 +24,6 @@
 #include "llvm/IR/Metadata.h"
 #include "llvm/InitializePasses.h"
 #include "llvm/Pass.h"
-#include "llvm/Support/CommandLine.h"
 #include "llvm/Support/Debug.h"
 #include "llvm/Transforms/Scalar.h"
 #include "llvm/Transforms/Utils/MisExpect.h"
@@ -48,10 +47,10 @@
 // 'select' instructions. It may be worthwhile to hoist these values to some
 // shared space, so they can be used directly by other passes.
 
-static cl::opt LikelyBranchWeight(
+cl::opt llvm::LikelyBranchWeight(
 "likely-branch-weight", cl::Hidden, cl::init(2000),
 cl::desc("Weight of the branch likely to be taken (default = 2000)"));
-static cl::opt UnlikelyBranchWeight(
+cl::opt llvm::UnlikelyBranchWeight(
 "unlikely-branch-weight", cl::Hidden, cl::init(1),
 cl::desc("Weight of the branch unlikely to be taken (default = 1)"));
 
Index: llvm/include/llvm/Transforms/Scalar/LowerExpectIntrinsic.h
===
--- llvm/include/llvm/Transforms/Scalar/LowerExpectIntrinsic.h
+++ llvm/include/llvm/Transforms/Scalar/LowerExpectIntrinsic.h
@@ -17,6 +17,7 @@
 
 #include "llvm/IR/Function.h"
 #include "llvm/IR/PassManager.h"
+#include "llvm/Support/CommandLine.h"
 
 namespace llvm {
 
@@ -31,6 +32,8 @@
   PreservedAnalyses run(Function , FunctionAnalysisManager &);
 };
 
+extern cl::opt LikelyBranchWeight;
+extern cl::opt UnlikelyBranchWeight;
 }
 
 #endif
Index: clang/www/cxx_status.html
===
--- clang/www/cxx_status.html
+++ clang/www/cxx_status.html
@@ -987,7 +987,7 @@
 
   [[likely]] and [[unlikely]] attributes
   https://wg21.link/p0479r5;>P0479R5
-  No
+  Clang 12 (partial)
 
 
   typename optional in more contexts
Index: clang/test/SemaCXX/attr-likelihood.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/attr-likelihood.cpp
@@ -0,0 +1,132 @@
+// RUN: %clang_cc1 %s -fsyntax-only -verify
+// RUN: %clang_cc1 %s -DPEDANTIC -pedantic -fsyntax-only -verify
+
+#if PEDANTIC
+void g() {
+  if (true)
+[[likely]] {} // expected-warning {{use of the 'likely' attribute is a C++20 extension}}
+  else
+[[unlikely]] {} // expected-warning {{use of the 'unlikely' attribute is a C++20 extension}}
+}
+#else
+void a() {
+  if (true)
+[[likely]]; // expected-warning {{conflicting attributes 'likely' are ignored}}
+  else
+[[likely]]; // expected-note {{conflicting attribute is here}}
+}
+
+void b() {
+  if (true)
+[[unlikely]]; // expected-warning {{conflicting attributes 'unlikely' are ignored}}
+  else
+[[unlikely]]; // expected-note {{conflicting attribute is here}}
+}
+
+void c() {
+  if (true)
+[[likely]];
+}
+
+void d() {
+  if (true)
+[[unlikely]];
+}
+
+void g() {
+  if (true)
+[[likely]] {}
+  else
+[[unlikely]] {}
+}
+
+void h() {
+  if (true)
+[[likely]] {}
+  else {
+  }
+}
+
+void 

[PATCH] D86559: [Sema, CodeGen] Allow [[likely]] and [[unlikely]] on labels

2020-08-29 Thread Mark de Wever via Phabricator via cfe-commits
Mordante added a comment.

In D86559#2243583 , @staffantj wrote:

> The use case for this becomes clearer when considering that the attribute 
> that will be used 95% of the time is [[unlikely]]. You may have a constructor 
> that you wish to ask the compiler to please, please, do not inline this, in a 
> particular function, even if the rest of that function is either likely or 
> neutral.

At the moment the likelihood is used only for branch prediction and not for 
inlining decisions. I'm not sure it would be a good idea to use this attribute 
for that duality. If it's wanted to control the inlining of calls at the 
callers side I feel a separate attribute would make more sense.

  void foo()
  {
[[unlikely]] expensive_class q{};
...
  }

This looks odd to me and the attribute isn't allowed on the declaration. I 
think this looks better:

  void foo()
  {
[[noinline]] expensive_class q{};
...
  }



>   if (a)
> [[unlikely]] expensive_class q{};
>
> This could be the case if expensive_class held large static members, for 
> instance.

This can be rewritten to be an expression and not a declaration, then the 
attribute can be used:

  if(a)
[[unlikely]] expensive_class{};




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86559

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


[PATCH] D86559: [Sema, CodeGen] Allow [[likely]] and [[unlikely]] on labels

2020-08-29 Thread Mark de Wever via Phabricator via cfe-commits
Mordante added a comment.

In D86559#2243575 , @staffantj wrote:

> As one of the SG14 industry members driving this, I'm firmly in the camp that 
> this is what we're expecting. In the first case the 1/2 case are "neutral". 
> This is a very explicit, and local, marker. Anything else makes it so vague 
> as to be unusable for fine tuned code.

Thanks for your interest and affirming this looks like the right path to take.

> I should also make the point that we are not talking about a feature that is 
> expected, or indeed should be, used by anyone other than someone with an 
> exceedingly good understanding of what is going on. This is not a "teach 
> everyone about it, it's safe" feature. It's there to produce a very 
> fine-grained control in those cases where it really matters, and where 
> profiling-guided optimizations would produce exactly the wrong result. Using 
> this feature should be an automatic "is this needed" question in a code 
> review. It is needed sometimes, just rarely.

I think it's hard to predict how the feature will be used. For example if a 
well known C++ gives a presentation at a conference about the attributes it 
might be more used. Even though as humans we're bad at guessing the performance 
bottleneck in our code I still think there are cases where the attribute can be 
used without testing. For example when writing a cache in an application you 
can mark the cache-hit to be more likely. If that isn't the case there's no 
reason for adding a cache. (Of course it would still be wise to measure.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86559

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


[PATCH] D86559: [Sema, CodeGen] Allow [[likely]] and [[unlikely]] on labels

2020-08-29 Thread Mark de Wever via Phabricator via cfe-commits
Mordante added a comment.
Herald added a subscriber: danielkiss.

In D86559#2242713 , @aaron.ballman 
wrote:

> In D86559#2242586 , @Mordante wrote:
>
>>> That is exactly the behavior I am coming to believe we should follow. You 
>>> can either write it on a compound statement that is guarded by a flow 
>>> control decision (`if`/`else`/`while`) or you can write it on a label, 
>>> otherwise the attribute is parsed and ignored (with a diagnostic). This 
>>> feels like the right mixture of useful with understandable semantics so 
>>> far, but perhaps we'll find other examples that change our minds.
>>>
>>> The fallthrough behavior question has one more case we may want to think 
>>> about:
>>>
>>>   switch (x) {
>>>   case 0:
>>>   case 1:
>>>   [[likely]] case 2: break;
>>>   [[unlikely]] default:
>>>   }
>>>
>>> Does this mark cases `0` and `1` as being likely or not? I could see users 
>>> wanting to use shorthand rather than repeat themselves on all the cases. 
>>> However, I'm also not certain whether there would be any performance impact 
>>> if we marked only `case 2` as likely and left cases `0` and `1` with 
>>> default likelihood. My gut feeling is that this should only mark `case 2`, 
>>> but others may have different views.
>>
>> Not according to the standard: "A path of execution includes a label if and 
>> only if it contains a jump to that label."
>
> A switch statement contains a jump to all of its labels, though. So all of 
> those labels are included in the path of execution, which is not likely 
> what's intended by the standard.

In the example above if `x == 0` there will be a jump to `case 0` which then 
falls through to `case 1` and `case 2` so `case 0` doesn't jump to `case 2` and 
thus doesn't "execute" the label.

>> if(a) {
>>
>>   [[likely]] return; // Ignored, not on the first statement
>>
>> }
>
> Agreed.
>
>> if(a)  // Attribute not allowed on a declaration,
>>
>>   [[likely]] int i = 5;  // but I can't think about a good use-case
>>  // for this code.
>
> This is a fun example because I can think of a somewhat reasonable use-case 
> but we can't support it without a compound statement. :-D The declaration 
> could be an RAII object,
>
>   if (a)
> [[likely]] SomeRAIIObj Obj(*a);
>
> However, you're right that we cannot write the attribute there because a 
> declaration-statement cannot be attributed 
> (http://eel.is/c++draft/stmt.stmt#stmt.pre-1), so the attribute instead 
> appertains to the declaration and not the statement. So the user would have 
> to write:
>
>   if (a) [[likely]] {
> SomeRAIIObj Obj(*a);
>   }
>
> That said, I think this is enough of a corner case that requiring the 
> compound statement is not really a burden. If we find users run into that 
> often (they'd get an attribute ignored error if they tried), we could add a 
> fix-it to help them out, but that doesn't seem necessary initially.

I had thought about RAII before and I think there it's also not a real issue. 
Your example does the same as:

  if (a)
 [[likely]] SomeRAIIObj{*a};
   

Here's  no declaration and the attribute is allowed. If the RAII object is used 
in a declaration I expect it usually will be inside a compound statement to 
create a scope where the object is alive. In that case the attribute is placed 
on the compound statement. I don't expect people to really write code like 
this, but it may happen when using macros.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86559

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


[PATCH] D33825: [clang-tidy] signal handler must be plain old function check

2020-08-29 Thread Tibor Brunner via Phabricator via cfe-commits
bruntib updated this revision to Diff 288777.
bruntib added a comment.

Note texts are now describing what kind of C++ constructs were used. The 
warning message also explains better the reason of the issue: "signal handlers 
must be plain old functions, C++-only constructs are not allowed"


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D33825

Files:
  clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
  clang-tools-extra/clang-tidy/cert/CMakeLists.txt
  clang-tools-extra/clang-tidy/cert/SignalHandlerMustBePlainOldFunctionCheck.cpp
  clang-tools-extra/clang-tidy/cert/SignalHandlerMustBePlainOldFunctionCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/cert-msc54-cpp.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp
@@ -0,0 +1,134 @@
+// RUN: %check_clang_tidy %s cert-msc54-cpp %t -- -- -std=c++11
+
+namespace std {
+extern "C" using signalhandler = void(int);
+int signal(int sig, signalhandler *func);
+}
+
+#define SIG_ERR -1
+#define SIGTERM 15
+
+static void sig_handler(int sig) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:13: warning: signal handlers must be 'extern "C"' [cert-msc54-cpp]
+// CHECK-MESSAGES: :[[@LINE+3]]:39: note: given as a signal parameter here
+
+void install_signal_handler() {
+  if (SIG_ERR == std::signal(SIGTERM, sig_handler))
+return;
+}
+
+extern "C" void cpp_signal_handler(int sig) {
+  // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: signal handlers must be plain old functions, C++-only constructs are not allowed [cert-msc54-cpp]
+  // CHECK-MESSAGES: :[[@LINE+1]]:3: note: throw statement used here
+  throw "error message";
+}
+
+void install_cpp_signal_handler() {
+  if (SIG_ERR == std::signal(SIGTERM, cpp_signal_handler))
+return;
+}
+
+void indirect_recursion();
+
+void cpp_like(){
+  try {
+cpp_signal_handler(SIG_ERR);
+  } catch(...) {
+// handle error
+  }
+}
+
+void no_body();
+
+void recursive_function() {
+  indirect_recursion();
+  cpp_like();
+  no_body();
+  recursive_function();
+}
+
+void indirect_recursion() {
+  recursive_function();
+}
+
+extern "C" void signal_handler_with_cpp_function_call(int sig) {
+  // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: do not call functions with C++ constructs in signal handlers [cert-msc54-cpp]
+  // CHECK-MESSAGES: :[[@LINE-11]]:3: note: function called here
+  // CHECK-MESSAGES: :[[@LINE-23]]:3: note: try statement used here
+  recursive_function();
+}
+
+void install_signal_handler_with_cpp_function_call() {
+  if (SIG_ERR == std::signal(SIGTERM, signal_handler_with_cpp_function_call))
+return;
+}
+
+class TestClass {
+public:
+  static void static_function() {}
+};
+
+extern "C" void signal_handler_with_cpp_static_method_call(int sig) {
+  // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: do not call functions with C++ constructs in signal handlers [cert-msc54-cpp]
+  // CHECK-MESSAGES: :[[@LINE+2]]:3: note: function called here
+  // CHECK-MESSAGES: TestClass::static_function();
+  TestClass::static_function();
+}
+
+void install_signal_handler_with_cpp_static_method_call() {
+  if (SIG_ERR == std::signal(SIGTERM, signal_handler_with_cpp_static_method_call))
+return;
+}
+
+
+// Something that does not trigger the check:
+
+extern "C" void c_sig_handler(int sig) {
+#define cbrt(X) _Generic((X), long double \
+ : cbrtl, default \
+ : cbrt)(X)
+  auto char c = '1';
+  extern _Thread_local double _Complex d;
+  static const unsigned long int i = sizeof(float);
+  void f();
+  volatile struct c_struct {
+enum e {};
+union u;
+  };
+  typedef bool boolean;
+label:
+  switch (c) {
+  case ('1'):
+break;
+  default:
+d = 1.2;
+  }
+  goto label;
+  for (; i < 42;) {
+if (d == 1.2)
+  continue;
+else
+  return;
+  }
+  do {
+_Atomic int v = _Alignof(char);
+_Static_assert(42 == 42, "True");
+  } while (c == 42);
+}
+
+void install_c_sig_handler() {
+  if (SIG_ERR == std::signal(SIGTERM, c_sig_handler)) {
+// Handle error
+  }
+}
+
+extern "C" void signal_handler_with_function_pointer(int sig) {
+  void (*funp) (void);
+  funp = _like;
+  funp();
+}
+
+void install_signal_handler_with_function_pointer() {
+  if (SIG_ERR == std::signal(SIGTERM, signal_handler_with_function_pointer))
+return;
+}
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ 

[PATCH] D85091: [Sema, CodeGen] Implement [[likely]] and [[unlikely]] in IfStmt

2020-08-29 Thread Mark de Wever via Phabricator via cfe-commits
Mordante marked 7 inline comments as done.
Mordante added inline comments.
Herald added a subscriber: danielkiss.



Comment at: clang/include/clang/Basic/Attr.td:1288
+def Likely : StmtAttr {
+  let Spellings = [CXX11<"", "likely", 201803>];
+  let Documentation = [LikelihoodDocs];

aaron.ballman wrote:
> Mordante wrote:
> > aaron.ballman wrote:
> > > Mordante wrote:
> > > > Mordante wrote:
> > > > > aaron.ballman wrote:
> > > > > > Mordante wrote:
> > > > > > > Mordante wrote:
> > > > > > > > aaron.ballman wrote:
> > > > > > > > > Mordante wrote:
> > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > Hmm, I'm on the fence about specifying `201803` for these 
> > > > > > > > > > > attributes. Given that this is only the start of 
> > > > > > > > > > > supporting the attribute, do we want to claim it already 
> > > > > > > > > > > matches the standard's behavior? Or do we just want to 
> > > > > > > > > > > return `1` to signify that we understand this attribute 
> > > > > > > > > > > but we don't yet fully support it in common cases (such 
> > > > > > > > > > > as on labels in switch statements, etc)?
> > > > > > > > > > > 
> > > > > > > > > > > As another question, should we consider adding a C2x 
> > > > > > > > > > > spelling `[[clang::likely]]` and `[[clang::unlikely]]` to 
> > > > > > > > > > > add this functionality to C?
> > > > > > > > > > I was also somewhat on the fence, for now I'll change it to 
> > > > > > > > > > specify `1`.
> > > > > > > > > > 
> > > > > > > > > > I'll have a look at the C2x changes. Just curious do you 
> > > > > > > > > > know whether there's a proposal to add this to C2x?
> > > > > > > > > > I'll have a look at the C2x changes. Just curious do you 
> > > > > > > > > > know whether there's a proposal to add this to C2x?
> > > > > > > > > 
> > > > > > > > > There isn't one currently because there is no implementation 
> > > > > > > > > experience with the attributes in C. This is a way to get 
> > > > > > > > > that implementation experience so it's easier to propose the 
> > > > > > > > > feature to WG14.
> > > > > > > > > I was also somewhat on the fence, for now I'll change it to 
> > > > > > > > > specify `1`.
> > > > > > > > 
> > > > > > > > There seems to be an issue using the `1` so I used `2` instead. 
> > > > > > > > (Didn't want to look closely at the issue.)
> > > > > > > > 
> > > > > > > > > I'll have a look at the C2x changes. Just curious do you know 
> > > > > > > > > whether there's a proposal to add this to C2x?
> > > > > > > > 
> > > > > > > > There isn't one currently because there is no implementation 
> > > > > > > > experience with the attributes in C. This is a way to get that 
> > > > > > > > implementation experience so it's easier to propose the feature 
> > > > > > > > to WG14.
> > > > > > > 
> > > > > > > Nice to know. It seems the C2x wasn't at straightforward as I 
> > > > > > > hoped, so I didn't implement it yet. I intend to look at it 
> > > > > > > later. I first want the initial part done to see whether this is 
> > > > > > > the right approach.
> > > > > > What issues are you running into? 1 is the default value when you 
> > > > > > don't specify a value specifically.
> > > > > It give the error "clang/include/clang/Basic/Attr.td:265:7: error: 
> > > > > Standard attributes must have valid version information."
> > > > > > > I'll have a look at the C2x changes. Just curious do you know 
> > > > > > > whether there's a proposal to add this to C2x?
> > > > > > 
> > > > > > There isn't one currently because there is no implementation 
> > > > > > experience with the attributes in C. This is a way to get that 
> > > > > > implementation experience so it's easier to propose the feature to 
> > > > > > WG14.
> > > > > 
> > > > > Nice to know. It seems the C2x wasn't at straightforward as I hoped, 
> > > > > so I didn't implement it yet. I intend to look at it later. I first 
> > > > > want the initial part done to see whether this is the right approach.
> > > > 
> > > > I had another look and I got it working in C.
> > > If you leave the version number off entirely, it defaults to 1.
> > Yes and that gives the same error. So the default value doesn't "compile". 
> > I assume that's intentional to avoid setting a date of 1 for standard 
> > attributes. So we could keep it at 2 or switch back to `201803`. Which 
> > value do you prefer?
> Ah, yeah, you're right (sorry for the noise). I think `2` is fine for now 
> unless you find that the new patch actually hits enough of the important 
> cases from the standard to justify `201803`. We can figure that out with the 
> updated patch series.
For now let's keep it at `2`, this patch won't implement the `switch`. Once the 
`switch` works the iteration statements still need to be done, but I think they 
aren't as important as the selection statements.


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

https://reviews.llvm.org/D85091


[PATCH] D33825: [clang-tidy] signal handler must be plain old function check

2020-08-29 Thread Tibor Brunner via Phabricator via cfe-commits
bruntib added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp:22
+  // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: do not use C++ constructs in 
signal handlers [cert-msc54-cpp]
+  // CHECK-MESSAGES: :[[@LINE+1]]:3: note: C++ construct used here
+  throw "error message";

jfb wrote:
> "C++ construct" isn't particularly useful. Here it needs to call out throwing 
> exceptions.
Thanks for the review!
I think the clang-tidy message is understandable, because the next line after 
"note: C++ construct used here" displays the exact source location where this 
C++ construct is used. I included this line in the test file so it is visible 
here. The full message looks like this:

llvm-project/clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp:20:17:
 warning: do not use C++ constructs in signal handlers [cert-msc54-cpp]
extern "C" void cpp_signal_handler(int sig) {
^
llvm-project/clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp:23:3:
 note: C++ construct used here
  throw "error message";
  ^

Do you think it's enough, or should the note text be different for all C++ 
constructs?


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D33825

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


[PATCH] D33825: [clang-tidy] signal handler must be plain old function check

2020-08-29 Thread Tibor Brunner via Phabricator via cfe-commits
bruntib updated this revision to Diff 288774.
bruntib added a comment.

Test file has been extended with the second line of the "note" diagnostic 
message which designates the location of the suspicious "C++ construct". The 
full clang-tidy output looks like this:

llvm-project/clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp:20:17:
 warning: do not use C++ constructs in signal handlers [cert-msc54-cpp]
extern "C" void cpp_signal_handler(int sig) {

  ^

llvm-project/clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp:23:3:
 note: C++ construct used here

  throw "error message";
  ^


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D33825

Files:
  clang-tools-extra/clang-tidy/cert/CERTTidyModule.cpp
  clang-tools-extra/clang-tidy/cert/CMakeLists.txt
  clang-tools-extra/clang-tidy/cert/SignalHandlerMustBePlainOldFunctionCheck.cpp
  clang-tools-extra/clang-tidy/cert/SignalHandlerMustBePlainOldFunctionCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/cert-msc54-cpp.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cert-signal-handler-must-be-plain-old-function.cpp
@@ -0,0 +1,136 @@
+// RUN: %check_clang_tidy %s cert-msc54-cpp %t -- -- -std=c++11
+
+namespace std {
+extern "C" using signalhandler = void(int);
+int signal(int sig, signalhandler *func);
+}
+
+#define SIG_ERR -1
+#define SIGTERM 15
+
+static void sig_handler(int sig) {}
+// CHECK-MESSAGES: :[[@LINE-1]]:13: warning: signal handlers must be 'extern "C"' [cert-msc54-cpp]
+// CHECK-MESSAGES: :[[@LINE+3]]:39: note: given as a signal parameter here
+
+void install_signal_handler() {
+  if (SIG_ERR == std::signal(SIGTERM, sig_handler))
+return;
+}
+
+extern "C" void cpp_signal_handler(int sig) {
+  // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: do not use C++ constructs in signal handlers [cert-msc54-cpp]
+  // CHECK-MESSAGES: :[[@LINE+2]]:3: note: C++ construct used here
+  // CHECK-MESSAGES: throw "error message";
+  throw "error message";
+}
+
+void install_cpp_signal_handler() {
+  if (SIG_ERR == std::signal(SIGTERM, cpp_signal_handler))
+return;
+}
+
+void indirect_recursion();
+
+void cpp_like(){
+  try {
+cpp_signal_handler(SIG_ERR);
+  } catch(...) {
+// handle error
+  }
+}
+
+void no_body();
+
+void recursive_function() {
+  indirect_recursion();
+  cpp_like();
+  no_body();
+  recursive_function();
+}
+
+void indirect_recursion() {
+  recursive_function();
+}
+
+extern "C" void signal_handler_with_cpp_function_call(int sig) {
+  // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: do not call functions with C++ constructs in signal handlers [cert-msc54-cpp]
+  // CHECK-MESSAGES: :[[@LINE-11]]:3: note: function called here
+  // CHECK-MESSAGES: :[[@LINE-23]]:3: note: C++ construct used here
+  // CHECK-MESSAGES: try {
+  recursive_function();
+}
+
+void install_signal_handler_with_cpp_function_call() {
+  if (SIG_ERR == std::signal(SIGTERM, signal_handler_with_cpp_function_call))
+return;
+}
+
+class TestClass {
+public:
+  static void static_function() {}
+};
+
+extern "C" void signal_handler_with_cpp_static_method_call(int sig) {
+  // CHECK-MESSAGES: :[[@LINE-1]]:17: warning: do not call functions with C++ constructs in signal handlers [cert-msc54-cpp]
+  // CHECK-MESSAGES: :[[@LINE+2]]:3: note: function called here
+  // CHECK-MESSAGES: TestClass::static_function();
+  TestClass::static_function();
+}
+
+void install_signal_handler_with_cpp_static_method_call() {
+  if (SIG_ERR == std::signal(SIGTERM, signal_handler_with_cpp_static_method_call))
+return;
+}
+
+
+// Something that does not trigger the check:
+
+extern "C" void c_sig_handler(int sig) {
+#define cbrt(X) _Generic((X), long double \
+ : cbrtl, default \
+ : cbrt)(X)
+  auto char c = '1';
+  extern _Thread_local double _Complex d;
+  static const unsigned long int i = sizeof(float);
+  void f();
+  volatile struct c_struct {
+enum e {};
+union u;
+  };
+  typedef bool boolean;
+label:
+  switch (c) {
+  case ('1'):
+break;
+  default:
+d = 1.2;
+  }
+  goto label;
+  for (; i < 42;) {
+if (d == 1.2)
+  continue;
+else
+  return;
+  }
+  do {
+_Atomic int v = _Alignof(char);
+_Static_assert(42 == 42, "True");
+  } while (c == 42);
+}
+
+void install_c_sig_handler() {
+  if (SIG_ERR == std::signal(SIGTERM, c_sig_handler)) {
+// Handle error
+  }
+}
+
+extern "C" void signal_handler_with_function_pointer(int sig) {
+  void (*funp) (void);
+ 

[PATCH] D80791: [AArch64] Generate .note.gnu.property based on module flags.

2020-08-29 Thread Daniel Kiss via Phabricator via cfe-commits
danielkiss updated this revision to Diff 288775.
danielkiss edited the summary of this revision.
danielkiss added a comment.

Sync with D85649 .


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

https://reviews.llvm.org/D80791

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
  llvm/test/CodeGen/AArch64/note-gnu-property-pac-bti-0.ll
  llvm/test/CodeGen/AArch64/note-gnu-property-pac-bti-1.ll
  llvm/test/CodeGen/AArch64/note-gnu-property-pac-bti-2.ll
  llvm/test/CodeGen/AArch64/note-gnu-property-pac-bti-3.ll
  llvm/test/CodeGen/AArch64/note-gnu-property-pac-bti-4.ll
  llvm/test/CodeGen/AArch64/note-gnu-property-pac-bti-5.ll
  llvm/test/CodeGen/AArch64/note-gnu-property-pac-bti-6.ll
  llvm/test/CodeGen/AArch64/note-gnu-property-pac-bti-7.ll
  llvm/test/CodeGen/AArch64/note-gnu-property-pac-bti-8.ll

Index: llvm/test/CodeGen/AArch64/note-gnu-property-pac-bti-8.ll
===
--- llvm/test/CodeGen/AArch64/note-gnu-property-pac-bti-8.ll
+++ /dev/null
@@ -1,21 +0,0 @@
-; RUN: llc -mtriple=aarch64-linux %s   -o - | \
-; RUN:   FileCheck %s --check-prefix=ASM
-; RUN: llc -mtriple=aarch64-linux %s -filetype=obj -o - | \
-; RUN:   llvm-readelf --notes - | FileCheck %s --check-prefix=OBJ
-
-define dso_local i32 @f() #0 {
-entry:
-  %r = tail call i32 @g()
-  ret i32 %r
-}
-
-declare dso_local i32 @g()
-
-attributes #0 = { "branch-target-enforcement" }
-
-; Declarations don't prevent setting BTI
-; ASM:	.word	3221225472
-; ASM-NEXT:	.word	4
-; ASM-NEXT:	.word	1
-
-; OBJ: Properties: aarch64 feature: BTI
Index: llvm/test/CodeGen/AArch64/note-gnu-property-pac-bti-7.ll
===
--- llvm/test/CodeGen/AArch64/note-gnu-property-pac-bti-7.ll
+++ /dev/null
@@ -1,23 +0,0 @@
-; RUN: llc -mtriple=aarch64-linux %s   -o - 2>&1 | \
-; RUN:   FileCheck %s --check-prefix=ASM
-; RUN: llc -mtriple=aarch64-linux %s -filetype=obj -o -  |  \
-; RUN:   llvm-readelf -S - | FileCheck %s --check-prefix=OBJ
-
-define dso_local i32 @f() #0 {
-entry:
-  ret i32 0
-}
-
-define dso_local i32 @g() #1 {
-entry:
-  ret i32 0
-}
-
-attributes #0 = { "sign-return-address"="non-leaf" }
-
-attributes #1 = { "branch-target-enforcement" }
-
-; No common attribute, no note section
-; ASM: warning: not setting BTI in feature flags
-; ASM-NOT: .note.gnu.property
-; OBJ-NOT: .note.gnu.property
Index: llvm/test/CodeGen/AArch64/note-gnu-property-pac-bti-6.ll
===
--- llvm/test/CodeGen/AArch64/note-gnu-property-pac-bti-6.ll
+++ /dev/null
@@ -1,22 +0,0 @@
-; RUN: llc -mtriple=aarch64-linux %s   -o - | \
-; RUN:   FileCheck %s --check-prefix=ASM
-; RUN: llc -mtriple=aarch64-linux %s -filetype=obj -o - |  \
-; RUN:   llvm-readelf -S - | FileCheck %s --check-prefix=OBJ
-
-define dso_local i32 @f() #0 {
-entry:
-  ret i32 0
-}
-
-define dso_local i32 @g() #1 {
-entry:
-  ret i32 0
-}
-
-attributes #0 = { "sign-return-address"="non-leaf" }
-
-attributes #1 = { "sign-return-address"="none" }
-
-; No common attribute, no note section
-; ASM-NOT: .note.gnu.property
-; OBJ-NOT: .note.gnu.property
Index: llvm/test/CodeGen/AArch64/note-gnu-property-pac-bti-5.ll
===
--- llvm/test/CodeGen/AArch64/note-gnu-property-pac-bti-5.ll
+++ /dev/null
@@ -1,26 +0,0 @@
-; RUN: llc -mtriple=aarch64-linux %s   -o - 2>&1 | \
-; RUN:   FileCheck %s --check-prefix=ASM
-; RUN: llc -mtriple=aarch64-linux %s -filetype=obj -o -  |  \
-; RUN:   llvm-readelf --notes - | FileCheck %s --check-prefix=OBJ
-
-define dso_local i32 @f() #0 {
-entry:
-  ret i32 0
-}
-
-define dso_local i32 @g() #1 {
-entry:
-  ret i32 0
-}
-
-attributes #0 = { "branch-target-enforcement" "sign-return-address"="non-leaf" }
-
-attributes #1 = { "sign-return-address"="all" }
-
-; Only the common atttribute (PAC)
-; ASM: warning: not setting BTI in feature flags
-; ASM:	.word	3221225472
-; ASM-NEXT:	.word	4
-; ASM-NEXT:	.word	2
-
-; OBJ: Properties: aarch64 feature: PAC
Index: llvm/test/CodeGen/AArch64/note-gnu-property-pac-bti-4.ll
===
--- llvm/test/CodeGen/AArch64/note-gnu-property-pac-bti-4.ll
+++ llvm/test/CodeGen/AArch64/note-gnu-property-pac-bti-4.ll
@@ -1,25 +1,12 @@
 ; RUN: llc -mtriple=aarch64-linux %s   -o - | \
 ; RUN:   FileCheck %s --check-prefix=ASM
-; RUN: llc -mtriple=aarch64-linux %s -filetype=obj -o - |  \
-; RUN:   llvm-readelf --notes - | FileCheck %s --check-prefix=OBJ
 
 define dso_local i32 @f() #0 {
 entry:
   ret i32 0
 }
 
-define dso_local i32 @g() #1 {
-entry:
-  ret i32 0
-}
-
 attributes #0 = { "branch-target-enforcement" "sign-return-address"="non-leaf" }
 
-attributes #1 = { "branch-target-enforcement" }
-
-; Only the common 

[PATCH] D75181: [AArch64] Handle BTI/PAC in case of generated functions.

2020-08-29 Thread Daniel Kiss via Phabricator via cfe-commits
danielkiss abandoned this revision.
danielkiss added a comment.

Abandoning in favour of D85649 .


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

https://reviews.llvm.org/D75181

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


[PATCH] D26418: [clang-tidy] Add '-suppress-checks-filter' option to suppress diagnostics from certain files

2020-08-29 Thread Lev Khoroshansky via Phabricator via cfe-commits
khoroshansky added a comment.
Herald added a subscriber: danielkiss.

Will this ever be merged?


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

https://reviews.llvm.org/D26418

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


[PATCH] D73425: [PPC] Fix platform definitions when compiling FreeBSD powerpc64 as LE

2020-08-29 Thread Dimitry Andric via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGfc2dac4116df: [PPC] Fix platform definitions when compiling 
FreeBSD powerpc64 as LE (authored by dim).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73425

Files:
  clang/lib/Basic/Targets.cpp
  clang/test/CodeGen/target-data.c
  clang/test/Driver/freebsd.c
  clang/test/Driver/ppc-abi.c
  clang/test/Preprocessor/init-ppc64.c


Index: clang/test/Preprocessor/init-ppc64.c
===
--- clang/test/Preprocessor/init-ppc64.c
+++ clang/test/Preprocessor/init-ppc64.c
@@ -1067,6 +1067,7 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-unknown-freebsd11 
-target-abi elfv1 -xc /dev/null | FileCheck --check-prefix=PPC64-ELFv1 %s
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-unknown-freebsd12 
-target-abi elfv1 -xc /dev/null | FileCheck --check-prefix=PPC64-ELFv1 %s
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-unknown-freebsd13 
-target-abi elfv2 -xc /dev/null | FileCheck --check-prefix=PPC64-ELFv2 %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64le-unknown-freebsd13 
-target-abi elfv2 -xc /dev/null | FileCheck --check-prefix=PPC64-ELFv2 %s
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-unknown-openbsd 
-target-abi elfv2 -xc /dev/null | FileCheck --check-prefix=PPC64-ELFv2 %s
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-linux-musl 
-target-abi elfv2 -xc /dev/null | FileCheck --check-prefix=PPC64-ELFv2 %s
 
@@ -1079,4 +1080,5 @@
 // PPC64LE-LINUX:#define _CALL_LINUX 1
 
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-unknown-freebsd < 
/dev/null | FileCheck -match-full-lines -check-prefix PPC64-FREEBSD %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64le-unknown-freebsd < 
/dev/null | FileCheck -match-full-lines -check-prefix PPC64-FREEBSD %s
 // PPC64-FREEBSD-NOT: #define __LONG_DOUBLE_128__ 1
Index: clang/test/Driver/ppc-abi.c
===
--- clang/test/Driver/ppc-abi.c
+++ clang/test/Driver/ppc-abi.c
@@ -20,6 +20,7 @@
 // RUN: %clang -target powerpc64-unknown-freebsd12 %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv1 %s
 // RUN: %clang -target powerpc64-unknown-freebsd13 %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv2-BE %s
 // RUN: %clang -target powerpc64-unknown-freebsd14 %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv2-BE %s
+// RUN: %clang -target powerpc64le-unknown-freebsd13 %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv2 %s
 // RUN: %clang -target powerpc64-unknown-openbsd %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv2-BE-PIE %s
 // RUN: %clang -target powerpc64-linux-musl %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv2-BE-PIE %s
 
Index: clang/test/Driver/freebsd.c
===
--- clang/test/Driver/freebsd.c
+++ clang/test/Driver/freebsd.c
@@ -21,7 +21,15 @@
 // CHECK-PPC64: "-cc1" "-triple" "powerpc64-pc-freebsd8"
 // CHECK-PPC64: ld{{.*}}" "--sysroot=[[SYSROOT:[^"]+]]"
 // CHECK-PPC64: "--eh-frame-hdr" "-dynamic-linker" "{{.*}}ld-elf{{.*}}" "-o" 
"a.out" "{{.*}}crt1.o" "{{.*}}crti.o" "{{.*}}crtbegin.o" 
"-L[[SYSROOT]]/usr/lib" "{{.*}}.o" "-lgcc" "--as-needed" "-lgcc_s" 
"--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" 
"{{.*}}crtend.o" "{{.*}}crtn.o"
-//
+
+// RUN: %clang -no-canonical-prefixes \
+// RUN:   -target powerpc64le-unknown-freebsd13 %s \
+// RUN:   --sysroot=%S/Inputs/basic_freebsd64_tree -### 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-PPC64LE %s
+// CHECK-PPC64LE: "-cc1" "-triple" "powerpc64le-unknown-freebsd13"
+// CHECK-PPC64LE: ld{{.*}}" "--sysroot=[[SYSROOT:[^"]+]]"
+// CHECK-PPC64LE: "--eh-frame-hdr" "-dynamic-linker" "{{.*}}ld-elf{{.*}}" "-o" 
"a.out" "{{.*}}crt1.o" "{{.*}}crti.o" "{{.*}}crtbegin.o" 
"-L[[SYSROOT]]/usr/lib" "{{.*}}.o" "-lgcc" "--as-needed" "-lgcc_s" 
"--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" 
"{{.*}}crtend.o" "{{.*}}crtn.o"
+
 //
 // Check that -m32 properly adjusts the toolchain flags.
 //
Index: clang/test/CodeGen/target-data.c
===
--- clang/test/CodeGen/target-data.c
+++ clang/test/CodeGen/target-data.c
@@ -130,6 +130,10 @@
 // RUN: FileCheck %s -check-prefix=PPC64-FREEBSD
 // PPC64-FREEBSD: target datalayout = "E-m:e-i64:64-n32:64"
 
+// RUN: %clang_cc1 -triple powerpc64le-freebsd -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=PPC64LE-FREEBSD
+// PPC64LE-FREEBSD: target datalayout = "e-m:e-i64:64-n32:64"
+
 // RUN: %clang_cc1 -triple powerpc64-linux -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=PPC64-LINUX
 // PPC64-LINUX: target datalayout = "E-m:e-i64:64-n32:64"
Index: clang/lib/Basic/Targets.cpp

[clang] fc2dac4 - [PPC] Fix platform definitions when compiling FreeBSD powerpc64 as LE

2020-08-29 Thread Dimitry Andric via cfe-commits

Author: Dimitry Andric
Date: 2020-08-29T12:03:20+02:00
New Revision: fc2dac4116df62c25396b15ec9730f67a0b1aac7

URL: 
https://github.com/llvm/llvm-project/commit/fc2dac4116df62c25396b15ec9730f67a0b1aac7
DIFF: 
https://github.com/llvm/llvm-project/commit/fc2dac4116df62c25396b15ec9730f67a0b1aac7.diff

LOG: [PPC] Fix platform definitions when compiling FreeBSD powerpc64 as LE

As a prerequisite to doing experimental buids of pieces of FreeBSD PowerPC64 as 
little-endian, allow actually targeting it.

This is needed so basic platform definitions are pulled in. Without it, the 
compiler will only run freestanding.

Reviewed By: MaskRay

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

Added: 


Modified: 
clang/lib/Basic/Targets.cpp
clang/test/CodeGen/target-data.c
clang/test/Driver/freebsd.c
clang/test/Driver/ppc-abi.c
clang/test/Preprocessor/init-ppc64.c

Removed: 




diff  --git a/clang/lib/Basic/Targets.cpp b/clang/lib/Basic/Targets.cpp
index 933b7b342891..c0187fd27842 100644
--- a/clang/lib/Basic/Targets.cpp
+++ b/clang/lib/Basic/Targets.cpp
@@ -358,6 +358,8 @@ TargetInfo *AllocateTarget(const llvm::Triple ,
 switch (os) {
 case llvm::Triple::Linux:
   return new LinuxTargetInfo(Triple, Opts);
+case llvm::Triple::FreeBSD:
+  return new FreeBSDTargetInfo(Triple, Opts);
 case llvm::Triple::NetBSD:
   return new NetBSDTargetInfo(Triple, Opts);
 case llvm::Triple::OpenBSD:

diff  --git a/clang/test/CodeGen/target-data.c 
b/clang/test/CodeGen/target-data.c
index 4f2dbe7c8e10..0ba20d568a08 100644
--- a/clang/test/CodeGen/target-data.c
+++ b/clang/test/CodeGen/target-data.c
@@ -130,6 +130,10 @@
 // RUN: FileCheck %s -check-prefix=PPC64-FREEBSD
 // PPC64-FREEBSD: target datalayout = "E-m:e-i64:64-n32:64"
 
+// RUN: %clang_cc1 -triple powerpc64le-freebsd -o - -emit-llvm %s | \
+// RUN: FileCheck %s -check-prefix=PPC64LE-FREEBSD
+// PPC64LE-FREEBSD: target datalayout = "e-m:e-i64:64-n32:64"
+
 // RUN: %clang_cc1 -triple powerpc64-linux -o - -emit-llvm %s | \
 // RUN: FileCheck %s -check-prefix=PPC64-LINUX
 // PPC64-LINUX: target datalayout = "E-m:e-i64:64-n32:64"

diff  --git a/clang/test/Driver/freebsd.c b/clang/test/Driver/freebsd.c
index 5eb00ce65d71..769bb22da0dc 100644
--- a/clang/test/Driver/freebsd.c
+++ b/clang/test/Driver/freebsd.c
@@ -21,7 +21,15 @@
 // CHECK-PPC64: "-cc1" "-triple" "powerpc64-pc-freebsd8"
 // CHECK-PPC64: ld{{.*}}" "--sysroot=[[SYSROOT:[^"]+]]"
 // CHECK-PPC64: "--eh-frame-hdr" "-dynamic-linker" "{{.*}}ld-elf{{.*}}" "-o" 
"a.out" "{{.*}}crt1.o" "{{.*}}crti.o" "{{.*}}crtbegin.o" 
"-L[[SYSROOT]]/usr/lib" "{{.*}}.o" "-lgcc" "--as-needed" "-lgcc_s" 
"--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" 
"{{.*}}crtend.o" "{{.*}}crtn.o"
-//
+
+// RUN: %clang -no-canonical-prefixes \
+// RUN:   -target powerpc64le-unknown-freebsd13 %s \
+// RUN:   --sysroot=%S/Inputs/basic_freebsd64_tree -### 2>&1 \
+// RUN:   | FileCheck --check-prefix=CHECK-PPC64LE %s
+// CHECK-PPC64LE: "-cc1" "-triple" "powerpc64le-unknown-freebsd13"
+// CHECK-PPC64LE: ld{{.*}}" "--sysroot=[[SYSROOT:[^"]+]]"
+// CHECK-PPC64LE: "--eh-frame-hdr" "-dynamic-linker" "{{.*}}ld-elf{{.*}}" "-o" 
"a.out" "{{.*}}crt1.o" "{{.*}}crti.o" "{{.*}}crtbegin.o" 
"-L[[SYSROOT]]/usr/lib" "{{.*}}.o" "-lgcc" "--as-needed" "-lgcc_s" 
"--no-as-needed" "-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" 
"{{.*}}crtend.o" "{{.*}}crtn.o"
+
 //
 // Check that -m32 properly adjusts the toolchain flags.
 //

diff  --git a/clang/test/Driver/ppc-abi.c b/clang/test/Driver/ppc-abi.c
index 491f9336a5c3..a74a19953ca2 100644
--- a/clang/test/Driver/ppc-abi.c
+++ b/clang/test/Driver/ppc-abi.c
@@ -20,6 +20,7 @@
 // RUN: %clang -target powerpc64-unknown-freebsd12 %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv1 %s
 // RUN: %clang -target powerpc64-unknown-freebsd13 %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv2-BE %s
 // RUN: %clang -target powerpc64-unknown-freebsd14 %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv2-BE %s
+// RUN: %clang -target powerpc64le-unknown-freebsd13 %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv2 %s
 // RUN: %clang -target powerpc64-unknown-openbsd %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv2-BE-PIE %s
 // RUN: %clang -target powerpc64-linux-musl %s -### 2>&1 | FileCheck 
--check-prefix=CHECK-ELFv2-BE-PIE %s
 

diff  --git a/clang/test/Preprocessor/init-ppc64.c 
b/clang/test/Preprocessor/init-ppc64.c
index cffd82fdf3c5..b553d07183ec 100644
--- a/clang/test/Preprocessor/init-ppc64.c
+++ b/clang/test/Preprocessor/init-ppc64.c
@@ -1067,6 +1067,7 @@
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-unknown-freebsd11 
-target-abi elfv1 -xc /dev/null | FileCheck --check-prefix=PPC64-ELFv1 %s
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-unknown-freebsd12 
-target-abi elfv1 -xc /dev/null | FileCheck --check-prefix=PPC64-ELFv1 %s
 

[PATCH] D81930: [AArch64] Add -mmark-bti-property flag.

2020-08-29 Thread Daniel Kiss via Phabricator via cfe-commits
danielkiss updated this revision to Diff 288765.
danielkiss marked an inline comment as done.

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

https://reviews.llvm.org/D81930

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/Driver/arm64-markbti.S
  llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
  llvm/lib/Target/AArch64/MCTargetDesc/AArch64TargetStreamer.cpp
  llvm/lib/Target/AArch64/MCTargetDesc/AArch64TargetStreamer.h

Index: llvm/lib/Target/AArch64/MCTargetDesc/AArch64TargetStreamer.h
===
--- llvm/lib/Target/AArch64/MCTargetDesc/AArch64TargetStreamer.h
+++ llvm/lib/Target/AArch64/MCTargetDesc/AArch64TargetStreamer.h
@@ -36,6 +36,9 @@
   /// Callback used to implement the .inst directive.
   virtual void emitInst(uint32_t Inst);
 
+  /// Callback used to implement the .note.gnu.property section.
+  virtual void emitNoteSection(unsigned Flags);
+
   virtual void EmitARM64WinCFIAllocStack(unsigned Size) {}
   virtual void EmitARM64WinCFISaveFPLR(int Offset) {}
   virtual void EmitARM64WinCFISaveFPLRX(int Offset) {}
Index: llvm/lib/Target/AArch64/MCTargetDesc/AArch64TargetStreamer.cpp
===
--- llvm/lib/Target/AArch64/MCTargetDesc/AArch64TargetStreamer.cpp
+++ llvm/lib/Target/AArch64/MCTargetDesc/AArch64TargetStreamer.cpp
@@ -11,12 +11,23 @@
 //===--===//
 
 #include "AArch64TargetStreamer.h"
+#include "AArch64MCAsmInfo.h"
+#include "AArch64Subtarget.h"
+#include "llvm/BinaryFormat/ELF.h"
 #include "llvm/MC/ConstantPools.h"
+#include "llvm/MC/MCContext.h"
 #include "llvm/MC/MCSection.h"
+#include "llvm/MC/MCSectionELF.h"
 #include "llvm/MC/MCSubtargetInfo.h"
+#include "llvm/Support/CommandLine.h"
 
 using namespace llvm;
 
+static cl::opt MarkBTIProperty(
+"aarch64-mark-bti-property", cl::Hidden,
+cl::desc("Add .note.gnu.property with BTI to assembly files"),
+cl::init(false));
+
 //
 // AArch64TargetStreamer Implemenation
 //
@@ -37,8 +48,52 @@
   ConstantPools->emitForCurrentSection(Streamer);
 }
 
-// finish() - write out any non-empty assembler constant pools.
-void AArch64TargetStreamer::finish() { ConstantPools->emitAll(Streamer); }
+// finish() - write out any non-empty assembler constant pools and
+//   write out note.gnu.properties if need.
+void AArch64TargetStreamer::finish() {
+  ConstantPools->emitAll(Streamer);
+
+  if (MarkBTIProperty) {
+emitNoteSection(ELF::GNU_PROPERTY_AARCH64_FEATURE_1_BTI);
+  }
+}
+
+void AArch64TargetStreamer::emitNoteSection(unsigned Flags) {
+  if (Flags == 0) {
+return;
+  }
+  MCStreamer  = getStreamer();
+  MCContext  = OutStreamer.getContext();
+  // Emit a .note.gnu.property section with the flags.
+  MCSection *Cur = OutStreamer.getCurrentSectionOnly();
+  MCSectionELF *Nt = Context.getELFSection(".note.gnu.property", ELF::SHT_NOTE,
+   ELF::SHF_ALLOC);
+  if (Nt->isRegistered()) {
+SMLoc Loc;
+Context.reportWarning(
+Loc,
+"The .note.gnu.property is not emitted because it is already present.");
+return;
+  }
+
+  OutStreamer.SwitchSection(Nt);
+
+  // Emit the note header.
+  OutStreamer.emitValueToAlignment(Align(8).value());
+  OutStreamer.emitIntValue(4, 4); // data size for "GNU\0"
+  OutStreamer.emitIntValue(4 * 4, 4); // Elf_Prop size
+  OutStreamer.emitIntValue(ELF::NT_GNU_PROPERTY_TYPE_0, 4);
+  OutStreamer.emitBytes(StringRef("GNU", 4)); // note name
+
+  // Emit the PAC/BTI properties.
+  OutStreamer.emitIntValue(ELF::GNU_PROPERTY_AARCH64_FEATURE_1_AND, 4);
+  OutStreamer.emitIntValue(4, 4); // data size
+  OutStreamer.emitIntValue(Flags, 4); // data
+  OutStreamer.emitIntValue(0, 4); // pad
+
+  OutStreamer.endSection(Nt);
+  OutStreamer.SwitchSection(Cur);
+}
 
 void AArch64TargetStreamer::emitInst(uint32_t Inst) {
   char Buffer[4];
Index: llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
===
--- llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
+++ llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp
@@ -221,26 +221,9 @@
 return;
 
   // Emit a .note.gnu.property section with the flags.
-  MCSection *Cur = OutStreamer->getCurrentSectionOnly();
-  MCSection *Nt = MMI->getContext().getELFSection(
-  ".note.gnu.property", ELF::SHT_NOTE, ELF::SHF_ALLOC);
-  OutStreamer->SwitchSection(Nt);
-
-  // Emit the note header.
-  emitAlignment(Align(8));
-  OutStreamer->emitInt32(4); // data size for "GNU\0"
-  OutStreamer->emitInt32(4 * 4); // Elf_Prop size
-  OutStreamer->emitInt32(ELF::NT_GNU_PROPERTY_TYPE_0);
-  OutStreamer->emitBytes(StringRef("GNU", 4)); // note name
-
-  // Emit the PAC/BTI properties.
-  OutStreamer->emitInt32(ELF::GNU_PROPERTY_AARCH64_FEATURE_1_AND);
-  OutStreamer->emitInt32(4); // data size
-  

[PATCH] D86156: [BFI] Make BFI information available through loop passes inside LoopStandardAnalysisResults

2020-08-29 Thread Nikita Popov via Phabricator via cfe-commits
nikic accepted this revision.
nikic added a comment.
This revision is now accepted and ready to land.

Thanks, looks good now :)


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

https://reviews.llvm.org/D86156

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