[PATCH] D99009: [RISCV] [1/2] Add intrinsic for Zbr extension

2021-03-20 Thread Jessica Clarke via Phabricator via cfe-commits
jrtc27 added a comment.

Please fix the style issues and update the patch with full context (see 
https://llvm.org/docs/Phabricator.html#requesting-a-review-via-the-web-interface,
 or use `arc`)




Comment at: clang/include/clang/Basic/BuiltinsRISCV.def:20
 
+// zbr extension
+TARGET_BUILTIN(__builtin_riscv_crc32_b, "LiLi", "nc", "experimental-zbr")

Zbr



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:11170
 
-// RISC-V V-extension
-def err_riscvv_builtin_requires_v : Error<
-   "builtin requires 'V' extension support to be enabled">;
+// RISC-V experimental extension
+def err_riscv_builtin_requires_extension : Error<

This will apply to non-experimental extensions too once V/B/K/etc get ratified



Comment at: clang/lib/Sema/SemaChecking.cpp:3400
+  
+  if (!TI.hasFeature(Features))
+  {

This new code assumes there's only one feature in the string



Comment at: clang/lib/Sema/SemaChecking.cpp:3405
+   << TheCall->getSourceRange()
+   << Features;
+  }

Extension name should have an upper case first letter



Comment at: clang/test/CodeGen/RISCV/rvb-intrinsics/riscv32-zbr.c:15-16
+//
+long crc32b(long a)
+{
+  return __builtin_riscv_crc32_b(a);

`long crc32b(long a) {` for all these



Comment at: clang/test/Headers/rvintrin.c:5
+// RUN:   -target-feature +experimental-v %s
+// expected-no-diagnostics
+

This does nothing unless you add -verify to the Clang command line



Comment at: llvm/include/llvm/IR/IntrinsicsRISCV.td:20
+class BitMan_GPR_Intrinsics
+: Intrinsic<[llvm_any_ty],[llvm_any_ty],
+[IntrNoMem, IntrSpeculatable, IntrWillReturn]>;

Space after comma



Comment at: llvm/lib/Target/RISCV/RISCVInstrInfoB.td:879
+let Predicates = [HasStdExtZbr] in {
+def : PatGpr;
+def : PatGpr;

Space after comma



Comment at: llvm/test/CodeGen/RISCV/rv32Zbr.ll:1
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc -mtriple=riscv32 -mattr=experimental-zbr -verify-machineinstrs < %s 
\

Lowercase z in the names of these files as it's a (sort of) -march string


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99009

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


[clang-tools-extra] 4dd92d6 - [clang-tidy] Fix bugprone-terminating-continue when continue appears inside a switch

2021-03-20 Thread Nathan James via cfe-commits

Author: Nathan James
Date: 2021-03-20T10:59:37Z
New Revision: 4dd92d61dbc4b3c51a98e1d0bfccabed24759ba9

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

LOG: [clang-tidy] Fix bugprone-terminating-continue when continue appears 
inside a switch

Don't emit a warning if the `continue` appears in a switch context as changing 
it to `break` will break out of the switch rather than a do loop containing the 
switch.
Fixes https://llvm.org/PR49492.

Reviewed By: aaron.ballman

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

Added: 


Modified: 
clang-tools-extra/clang-tidy/bugprone/TerminatingContinueCheck.cpp
clang-tools-extra/test/clang-tidy/checkers/bugprone-terminating-continue.cpp

Removed: 




diff  --git 
a/clang-tools-extra/clang-tidy/bugprone/TerminatingContinueCheck.cpp 
b/clang-tools-extra/clang-tidy/bugprone/TerminatingContinueCheck.cpp
index 43402a221218..65da4c325de4 100644
--- a/clang-tools-extra/clang-tidy/bugprone/TerminatingContinueCheck.cpp
+++ b/clang-tools-extra/clang-tidy/bugprone/TerminatingContinueCheck.cpp
@@ -26,10 +26,11 @@ void TerminatingContinueCheck::registerMatchers(MatchFinder 
*Finder) {
  equalsBoundNode("closestLoop"));
 
   Finder->addMatcher(
-  continueStmt(hasAncestor(stmt(anyOf(forStmt(), whileStmt(),
-  cxxForRangeStmt(), doStmt()))
-   .bind("closestLoop")),
-   hasAncestor(DoWithFalse))
+  continueStmt(
+  hasAncestor(stmt(anyOf(forStmt(), whileStmt(), cxxForRangeStmt(),
+ doStmt(), switchStmt()))
+  .bind("closestLoop")),
+  hasAncestor(DoWithFalse))
   .bind("continue"),
   this);
 }

diff  --git 
a/clang-tools-extra/test/clang-tidy/checkers/bugprone-terminating-continue.cpp 
b/clang-tools-extra/test/clang-tidy/checkers/bugprone-terminating-continue.cpp
index 4bdcbc42fc47..04fc4a80ea7d 100644
--- 
a/clang-tools-extra/test/clang-tidy/checkers/bugprone-terminating-continue.cpp
+++ 
b/clang-tools-extra/test/clang-tidy/checkers/bugprone-terminating-continue.cpp
@@ -32,6 +32,15 @@ void f() {
 // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: 'continue' in loop with false 
condition is equivalent to 'break' [bugprone-terminating-continue]
 // CHECK-FIXES: if (x > 0) break;
   } while (false);
+
+  switch (2) {
+  case 2:
+do {
+  continue; // LoopInSwitch
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: 'continue' in loop with 
false condition is equivalent to 'break' [bugprone-terminating-continue]
+  // CHECK-FIXES: break; // LoopInSwitch
+} while (0);
+  }
 }
 
 void g() {
@@ -62,4 +71,12 @@ void g() {
   if (n>2) continue;
 }
   } while (false);
+
+  do {
+switch (2) {
+case 1:
+case 2:
+  continue;
+}
+  } while (false);
 }



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


[PATCH] D98338: [clang-tidy] Fix bugprone-terminating-continue when continue appears inside a switch

2021-03-20 Thread Nathan James via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4dd92d61dbc4: [clang-tidy] Fix bugprone-terminating-continue 
when continue appears inside a… (authored by njames93).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98338

Files:
  clang-tools-extra/clang-tidy/bugprone/TerminatingContinueCheck.cpp
  clang-tools-extra/test/clang-tidy/checkers/bugprone-terminating-continue.cpp


Index: 
clang-tools-extra/test/clang-tidy/checkers/bugprone-terminating-continue.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-terminating-continue.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-terminating-continue.cpp
@@ -32,6 +32,15 @@
 // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: 'continue' in loop with false 
condition is equivalent to 'break' [bugprone-terminating-continue]
 // CHECK-FIXES: if (x > 0) break;
   } while (false);
+
+  switch (2) {
+  case 2:
+do {
+  continue; // LoopInSwitch
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: 'continue' in loop with 
false condition is equivalent to 'break' [bugprone-terminating-continue]
+  // CHECK-FIXES: break; // LoopInSwitch
+} while (0);
+  }
 }
 
 void g() {
@@ -62,4 +71,12 @@
   if (n>2) continue;
 }
   } while (false);
+
+  do {
+switch (2) {
+case 1:
+case 2:
+  continue;
+}
+  } while (false);
 }
Index: clang-tools-extra/clang-tidy/bugprone/TerminatingContinueCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/TerminatingContinueCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/TerminatingContinueCheck.cpp
@@ -26,10 +26,11 @@
  equalsBoundNode("closestLoop"));
 
   Finder->addMatcher(
-  continueStmt(hasAncestor(stmt(anyOf(forStmt(), whileStmt(),
-  cxxForRangeStmt(), doStmt()))
-   .bind("closestLoop")),
-   hasAncestor(DoWithFalse))
+  continueStmt(
+  hasAncestor(stmt(anyOf(forStmt(), whileStmt(), cxxForRangeStmt(),
+ doStmt(), switchStmt()))
+  .bind("closestLoop")),
+  hasAncestor(DoWithFalse))
   .bind("continue"),
   this);
 }


Index: clang-tools-extra/test/clang-tidy/checkers/bugprone-terminating-continue.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/bugprone-terminating-continue.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/bugprone-terminating-continue.cpp
@@ -32,6 +32,15 @@
 // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: 'continue' in loop with false condition is equivalent to 'break' [bugprone-terminating-continue]
 // CHECK-FIXES: if (x > 0) break;
   } while (false);
+
+  switch (2) {
+  case 2:
+do {
+  continue; // LoopInSwitch
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: 'continue' in loop with false condition is equivalent to 'break' [bugprone-terminating-continue]
+  // CHECK-FIXES: break; // LoopInSwitch
+} while (0);
+  }
 }
 
 void g() {
@@ -62,4 +71,12 @@
   if (n>2) continue;
 }
   } while (false);
+
+  do {
+switch (2) {
+case 1:
+case 2:
+  continue;
+}
+  } while (false);
 }
Index: clang-tools-extra/clang-tidy/bugprone/TerminatingContinueCheck.cpp
===
--- clang-tools-extra/clang-tidy/bugprone/TerminatingContinueCheck.cpp
+++ clang-tools-extra/clang-tidy/bugprone/TerminatingContinueCheck.cpp
@@ -26,10 +26,11 @@
  equalsBoundNode("closestLoop"));
 
   Finder->addMatcher(
-  continueStmt(hasAncestor(stmt(anyOf(forStmt(), whileStmt(),
-  cxxForRangeStmt(), doStmt()))
-   .bind("closestLoop")),
-   hasAncestor(DoWithFalse))
+  continueStmt(
+  hasAncestor(stmt(anyOf(forStmt(), whileStmt(), cxxForRangeStmt(),
+ doStmt(), switchStmt()))
+  .bind("closestLoop")),
+  hasAncestor(DoWithFalse))
   .bind("continue"),
   this);
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [clang] bdf39e6 - [Driver] Drop obsoleted Ubuntu 11.04 gcc detection

2021-03-20 Thread David Zarzycki via cfe-commits
This is failing on my Fedora 33 (x6-64) box. I'm going to revert this. If you 
need help debugging this, please let me know. Here is the relevant info:



FAIL: Clang :: Driver/gcc-toolchain.cpp (6552 of 75252)
 TEST 'Clang :: Driver/gcc-toolchain.cpp' FAILED 

Script:
--
: 'RUN: at line 3';   /tmp/_update_lc/r/bin/clang --driver-mode=g++ 
-no-canonical-prefixes /home/dave/ro_s/lp/clang/test/Driver/gcc-toolchain.cpp 
-### -o /tmp/_update_lc/r/tools/clang/test/Driver/Output/gcc-toolchain.cpp.tmp 
2>&1--target=x86_64-linux-gnu 
--gcc-toolchain=/home/dave/ro_s/lp/clang/test/Driver/Inputs/ubuntu_14.04_multiarch_tree/usr
 |/tmp/_update_lc/r/bin/FileCheck 
/home/dave/ro_s/lp/clang/test/Driver/gcc-toolchain.cpp
: 'RUN: at line 8';   /tmp/_update_lc/r/bin/clang --driver-mode=g++ 
-no-canonical-prefixes /home/dave/ro_s/lp/clang/test/Driver/gcc-toolchain.cpp 
-### -o /tmp/_update_lc/r/tools/clang/test/Driver/Output/gcc-toolchain.cpp.tmp 
2>&1--target=x86_64-linux-gnu -gcc-toolchain 
/home/dave/ro_s/lp/clang/test/Driver/Inputs/ubuntu_14.04_multiarch_tree/usr |   
 /tmp/_update_lc/r/bin/FileCheck 
/home/dave/ro_s/lp/clang/test/Driver/gcc-toolchain.cpp
: 'RUN: at line 30';   /tmp/_update_lc/r/bin/clang --driver-mode=g++ 
-no-canonical-prefixes /home/dave/ro_s/lp/clang/test/Driver/gcc-toolchain.cpp 
-### -o /tmp/_update_lc/r/tools/clang/test/Driver/Output/gcc-toolchain.cpp.tmp 
2>&1--target=aarch64-suse-linux 
--gcc-toolchain=/home/dave/ro_s/lp/clang/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr
 |/tmp/_update_lc/r/bin/FileCheck 
/home/dave/ro_s/lp/clang/test/Driver/gcc-toolchain.cpp --check-prefix=AARCH64
: 'RUN: at line 33';   /tmp/_update_lc/r/bin/clang --driver-mode=g++ 
-no-canonical-prefixes /home/dave/ro_s/lp/clang/test/Driver/gcc-toolchain.cpp 
-### -o /tmp/_update_lc/r/tools/clang/test/Driver/Output/gcc-toolchain.cpp.tmp 
2>&1--target=aarch64-suse-linux 
-B/home/dave/ro_s/lp/clang/test/Driver/Inputs/opensuse_42.2_aarch64_tree/usr |  
  /tmp/_update_lc/r/bin/FileCheck 
/home/dave/ro_s/lp/clang/test/Driver/gcc-toolchain.cpp --check-prefix=NO_AARCH64
--
Exit Code: 1

Command Output (stderr):
--
/home/dave/ro_s/lp/clang/test/Driver/gcc-toolchain.cpp:14:11: error: CHECK: 
expected string not found in input
// CHECK: 
"[[TOOLCHAIN:[^"]+]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8"
  ^
:5:568: note: scanning from here
 "/tmp/_update_lc/r/bin/clang" "-cc1" "-triple" "x86_64-unknown-linux-gnu" 
"-emit-obj" "-mrelax-all" "--mrelax-relocations" "-disable-free" 
"-disable-llvm-verifier" "-discard-value-names" "-main-file-name" 
"gcc-toolchain.cpp" "-mrelocation-model" "static" "-mframe-pointer=all" 
"-fmath-errno" "-fno-rounding-math" "-mconstructor-aliases" "-munwind-tables" 
"-target-cpu" "x86-64" "-tune-cpu" "generic" "-debugger-tuning=gdb" 
"-fcoverage-compilation-dir=/tmp/_update_lc/r/tools/clang/test/Driver" 
"-resource-dir" "/tmp/_update_lc/r/lib/clang/13.0.0" "-internal-isystem" 
"/tmp/_update_lc/r/bin/../include/c++/v1" "-internal-isystem" 
"/usr/local/include" "-internal-isystem" 
"/tmp/_update_lc/r/lib/clang/13.0.0/include" "-internal-externc-isystem" 
"/include" "-internal-externc-isystem" "/usr/include" "-fdeprecated-macro" 
"-fdebug-compilation-dir=/tmp/_update_lc/r/tools/clang/test/Driver" 
"-ferror-limit" "19" "-fgnuc-version=4.2.1" "-fcxx-exceptions" "-fexceptions" 
"-faddrsig" "-D__GCC_HAVE_DWARF2_CFI_ASM=1" "-o" "/tmp/gcc-toolchain-dfa1a3.o" 
"-x" "c++" "/home/dave/ro_s/lp/clang/test/Driver/gcc-toolchain.cpp"







   ^
:6:590: note: possible intended match here
 "/tmp/_update_lc/r/bin/ld.lld" "--hash-style=gnu" "--eh-frame-hdr" "-m" 
"elf_x86_64" "-dynamic-linker" "/lib64/ld-linux-x86-64.so.2" "-o" 
"/tmp/_update_lc/r/tools/clang/test/Driver/Output/gcc-toolchain.cpp.tmp" 
"/lib/../lib64/crt1.o" "/lib/../lib64/crti.o" 
"/home/dave/ro_s/lp/clang/test/Driver/Inputs/ubuntu_14.04_multiarch_tree/usr/lib/gcc/x86_64-linux-gnu/4.8/crtbegin.o"
 
"-L/home/dave/ro_s/lp/clang/test/Driver/Inputs/ubuntu_14.04_multiarch_tree/usr/lib/gcc/x86_64-linux-gnu/4.8"
 "-L/lib/../lib64" "-L/usr/lib/../lib64" 
"-L/home/dave/ro_s/lp/clang/test/Driver/Inputs/ubuntu_14.04_multiarch_tree/usr/lib/gcc/x86_64-linux-gnu/4.8/../../.."
 "-L/tmp/_update_lc/r/bin/../lib" "-L/lib" "-L/usr/lib" 
"/tmp/gcc-toolchain-dfa1a3.o" "-lc++" "-lm" "-lgcc_s" "-lgcc" "-lc" "-lgcc_s" 
"-lgcc" "crtend.o" "/li

[clang] 243333e - Revert "[Driver] Drop obsoleted Ubuntu 11.04 gcc detection"

2021-03-20 Thread David Zarzycki via cfe-commits

Author: David Zarzycki
Date: 2021-03-20T07:29:01-04:00
New Revision: 24ef3ec6c1e3910eb442177c2e2e927e6a87

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

LOG: Revert "[Driver] Drop obsoleted Ubuntu 11.04 gcc detection"

This reverts commit bdf39e6b0ed4b41a1842ac0193f30a726f8d9f63.

The change is failing on Fedora 33 (x86-64).

Added: 


Modified: 
clang/lib/Driver/ToolChains/Gnu.cpp
clang/test/Driver/gcc-toolchain.cpp
clang/test/Driver/linux-header-search.cpp
clang/test/Driver/linux-ld.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 3491a29a5f9c..3c1fc87d7896 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2506,6 +2506,7 @@ void 
Generic_GCC::GCCInstallationDetector::ScanLibDirForGCCTriple(
 const llvm::Triple &TargetTriple, const ArgList &Args,
 const std::string &LibDir, StringRef CandidateTriple,
 bool NeedsBiarchSuffix, bool GCCDirExists, bool GCCCrossDirExists) {
+  llvm::Triple::ArchType TargetArch = TargetTriple.getArch();
   // Locations relative to the system lib directory where GCC's triple-specific
   // directories might reside.
   struct GCCLibSuffix {
@@ -2529,7 +2530,15 @@ void 
Generic_GCC::GCCInstallationDetector::ScanLibDirForGCCTriple(
   // files in that location, not just GCC installation data.
   {CandidateTriple.str(), "..",
TargetTriple.getVendor() == llvm::Triple::Freescale ||
-   TargetTriple.getVendor() == llvm::Triple::OpenEmbedded}};
+   TargetTriple.getVendor() == llvm::Triple::OpenEmbedded},
+
+  // Deal with cases (on Ubuntu) where the system architecture could be 
i386
+  // but the GCC target architecture could be (say) i686.
+  // FIXME: It may be worthwhile to generalize this and look for a second
+  // triple.
+  {"i386-linux-gnu/gcc/" + CandidateTriple.str(), "../../..",
+   (TargetArch == llvm::Triple::x86 &&
+TargetTriple.getOS() != llvm::Triple::Solaris)}};
 
   for (auto &Suffix : Suffixes) {
 if (!Suffix.Active)

diff  --git a/clang/test/Driver/gcc-toolchain.cpp 
b/clang/test/Driver/gcc-toolchain.cpp
index 03a7991d6c70..cddf9b1bdbca 100644
--- a/clang/test/Driver/gcc-toolchain.cpp
+++ b/clang/test/Driver/gcc-toolchain.cpp
@@ -1,31 +1,34 @@
 // Test that gcc-toolchain option is working correctly
 //
 // RUN: %clangxx -no-canonical-prefixes %s -### -o %t 2>&1 \
-// RUN:   --target=x86_64-linux-gnu 
--gcc-toolchain=%S/Inputs/ubuntu_14.04_multiarch_tree/usr | \
-// RUN:   FileCheck %s
+// RUN: --target=i386-unknown-linux -stdlib=libstdc++ \
+// RUN: --gcc-toolchain=%S/Inputs/ubuntu_11.04_multiarch_tree/usr \
+// RUN: --sysroot="" \
+// RUN:   | FileCheck %s
 //
 // Additionally check that the legacy spelling of the flag works.
 // RUN: %clangxx -no-canonical-prefixes %s -### -o %t 2>&1 \
-// RUN:   --target=x86_64-linux-gnu -gcc-toolchain 
%S/Inputs/ubuntu_14.04_multiarch_tree/usr | \
-// RUN:   FileCheck %s
+// RUN: --target=i386-unknown-linux -stdlib=libstdc++ \
+// RUN: -gcc-toolchain %S/Inputs/ubuntu_11.04_multiarch_tree/usr \
+// RUN: --sysroot="" \
+// RUN:   | FileCheck %s
 //
 // Test for header search toolchain detection.
 // CHECK: "-internal-isystem"
-// CHECK: 
"[[TOOLCHAIN:[^"]+]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8"
+// CHECK: 
"[[TOOLCHAIN:[^"]+]]/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5/../../../../../include/c++/4.5"
 // CHECK: "-internal-isystem"
-// CHECK: 
"[[TOOLCHAIN]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/x86_64-linux-gnu/c++/4.8"
+// CHECK: 
"[[TOOLCHAIN]]/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5/../../../../../include/c++/4.5/i686-linux-gnu"
 // CHECK: "-internal-isystem"
-// CHECK: 
"[[TOOLCHAIN]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/backward"
+// CHECK: 
"[[TOOLCHAIN]]/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5/../../../../../include/c++/4.5/backward"
 // CHECK: "-internal-isystem" "/usr/local/include"
 //
 // Test for linker toolchain detection. Note that only the '-L' flags will use
 // the same precise formatting of the path as the '-internal-system' flags
 // above, so we just blanket wildcard match the 'crtbegin.o'.
 // CHECK: "{{[^"]*}}ld{{(.exe)?}}"
-// CHECK-SAME: "{{[^"]*}}/usr/lib/gcc/x86_64-linux-gnu/4.8{{/|}}crtbegin.o"
-// CHECK-SAME: "-L[[TOOLCHAIN]]/usr/lib/gcc/x86_64-linux-gnu/4.8"
-/// On x86_64, there is an extra 
usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu but we should not 
test it.
-// CHECK-SAME: "-L[[TOOLCHAIN]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../.."
+// CHECK: 
"{{[^"]*}}/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5{{/|}}crtbegin.o"
+// CHECK: "-L[[TOOLCHAIN]]/u

[PATCH] D98278: [test] Add ability to get error messages from CMake for errc substitution

2021-03-20 Thread Markus Böck via Phabricator via cfe-commits
zero9178 added a comment.

In D98278#2638005 , @mstorsjo wrote:

> In D98278#2637866 , @zero9178 wrote:
>
>> In D98278#2637826 , @mstorsjo wrote:
>>
>>> Btw, while this change does explain _what_ it does, it doesn't actually say 
>>> the exact reason _why_. Cleanliness? Sure, that's nice... Or is it a case 
>>> where e.g. some translations produce different error messages?
>>
>> Now that you mention it, it's indeed not as clear as I thought. But yes, in 
>> the case of MSVCs STL, the messages from `std::error_codes` which are used 
>> by various LLVM tools produce different strings then using `strerror` (the C 
>> function also called by Python) with the same error codes (Specifically, it 
>> has different casing).
>
> Ok, but would e.g. a case insensitive comparison have worked instead of this?
>
> And didn't the python script have hardcoded strings, specifically for the 
> MSVC case? Why weren't they written with the right casing for the case that 
> they're supposed to match? I.e. was it an issue with the existing hardcoded 
> strings, or did they work in one case but not another one?

Changes in this patch are based on this one https://reviews.llvm.org/D97472. In 
the discussion there it was deemed not a good solution to use case insensitive 
comparison as that would make any other matches case insensitive as well, which 
might be a source of bugs.

In D98278#2638023 , @mstorsjo wrote:

> In D98278#2637866 , @zero9178 wrote:
>
>> In D98278#2637826 , @mstorsjo wrote:
>>
>>> Btw, while this change does explain _what_ it does, it doesn't actually say 
>>> the exact reason _why_. Cleanliness? Sure, that's nice... Or is it a case 
>>> where e.g. some translations produce different error messages?
>>
>> Now that you mention it, it's indeed not as clear as I thought. But yes, in 
>> the case of MSVCs STL, the messages from `std::error_codes` which are used 
>> by various LLVM tools produce different strings then using `strerror` (the C 
>> function also called by Python) with the same error codes (Specifically, it 
>> has different casing).
>
> Or turning the question another way around: We have a couple different bots 
> that build and run the tests, successfully, with MSVC configurations. Are 
> there tests that failed for you in your configuration, that succeed in the 
> setup of the bots? Or are there other tests that aren't run as part of bots 
> that you're fixing? It's all still very vague to me.

Prior to this patch it worke with an MSVC configuration already as the strings 
were correctly hardcoded for the MSVC STL. Problem was when using any other 
compiler configuration on Windows. In my case I am using your llvm-mingw 
distribution to build all of LLVM and since it uses libc++ it produces 
different error messages from the one in MSVC STL. I observed the same problem 
when using GCC on Windows and if one were to theoretically use libc++ with 
clang-cl in a MSVC environment, tests would be failing as well due to a 
mismatch in error strings.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98278

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


[PATCH] D98278: [test] Add ability to get error messages from CMake for errc substitution

2021-03-20 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo added a comment.

In D98278#2639481 , @zero9178 wrote:

> Changes in this patch are based on this one https://reviews.llvm.org/D97472. 
> In the discussion there it was deemed not a good solution to use case 
> insensitive comparison as that would make any other matches case insensitive 
> as well, which might be a source of bugs.



> Prior to this patch it worke with an MSVC configuration already as the 
> strings were correctly hardcoded for the MSVC STL. Problem was when using any 
> other compiler configuration on Windows. In my case I am using your 
> llvm-mingw distribution to build all of LLVM and since it uses libc++ it 
> produces different error messages from the one in MSVC STL. I observed the 
> same problem when using GCC on Windows and if one were to theoretically use 
> libc++ with clang-cl in a MSVC environment, tests would be failing as well 
> due to a mismatch in error strings.

Ok, I think I see - so longterm (i.e. up until to a few months ago), we've just 
had some hardcoded (case insensitive) regexes in some testcases, and these 
didn't match for z/OS. As part of efforts to make it work for z/OS, a number of 
different incarnations have been used, and using a build-time tool to extract 
the real message looks like the most flexible solution in the end. And that 
also allows making it work properly for cases on Windows, where it's hard to 
know exactly which stdlib is going to be used at runtime and which kind of 
messages it produces.

Ok, so that makes sense to me, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98278

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


[PATCH] D99005: [clang] WIP: Implement P2266

2021-03-20 Thread Aaron Puchert via Phabricator via cfe-commits
aaronpuchert added a comment.

For coroutines I have D68845 . The current 
code is wrong, and not trivial to fix. We have never properly implemented P1825 
 and will probably just go with P2266 
 unconditionally, because that two-phase lookup 
is very cumbersome to imlement.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99005

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


[PATCH] D98867: [HIP] Fix ROCm detection

2021-03-20 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl marked 2 inline comments as done.
yaxunl added inline comments.



Comment at: clang/lib/Driver/ToolChains/AMDGPU.cpp:267-268
+// rocm-{major}.{minor}.{subMinor}[-{build}]
+auto Loc = StringRef(VerStr).rfind('_');
+if (Loc != StringRef::npos)
+  VerStr[Loc] = '.';

tra wrote:
> You don't need `StringRef` here. `VerStr.rfind()` will do.
will fix



Comment at: clang/lib/Driver/ToolChains/AMDGPU.cpp:269
+if (Loc != StringRef::npos)
+  VerStr[Loc] = '.';
+V.tryParse(VerStr);

tra wrote:
> This only deals with a single `.` in the version. It's likely that we will 
> have to deal with a patch release at some point, so you may want to replace 
> all instances.
> 
The ROCm directory follows rocm-{major}.{minor}.{subMinor}[-{build}] format, 
where major, minor and path (subMinor) are delimited by '.', only the optional 
build number is delimited by '-'. I have a comment about that at line 266.


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

https://reviews.llvm.org/D98867

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


[PATCH] D97080: [flang][driver] Add -fintrinsic-modules-path option

2021-03-20 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski accepted this revision.
awarzynski added a comment.
This revision is now accepted and ready to land.

LGTM, thank you for working on this!

In the summary you refer to `-fdebug-module-writer`. Could you please update 
before merging this?




Comment at: flang/lib/Frontend/CompilerInvocation.cpp:323
+  // Prepend the ordered list of -intrinsic-modules-path
+  // to the default location to search (currently hardcoded).
+  for (const auto *currentArg :

[nit] To me, `currently hardcoded` suggests that it's a temporary solution. But 
that's not the case, is it? Also, the default location is relative to the 
location of the driver, so it's not hardcoded.



Comment at: flang/lib/Frontend/CompilerInvocation.cpp:26
 #include "llvm/Support/raw_ostream.h"
+
+#include "llvm/Support/FileSystem.h"

awarzynski wrote:
> Not needed
Please revert before merging.


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

https://reviews.llvm.org/D97080

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


[PATCH] D98867: [HIP] Fix ROCm detection

2021-03-20 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl updated this revision to Diff 332104.
yaxunl marked 2 inline comments as done.
yaxunl added a comment.

revised by Artem's comments


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

https://reviews.llvm.org/D98867

Files:
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/test/Driver/rocm-detect.hip


Index: clang/test/Driver/rocm-detect.hip
===
--- clang/test/Driver/rocm-detect.hip
+++ clang/test/Driver/rocm-detect.hip
@@ -21,6 +21,20 @@
 // RUN:   --rocm-path=%S/Inputs/rocm %s 2>&1 \
 // RUN:   | FileCheck -check-prefixes=COMMON,NODEFAULTLIBS %s
 
+// Test environment variable ROCM_PATH.
+// RUN: env ROCM_PATH=%S/Inputs/rocm %clang -### -target x86_64-linux-gnu \
+// RUN:   --print-rocm-search-dirs %s 2>&1 \
+// RUN:   | FileCheck -check-prefixes=ROCM-ENV %s
+
+// Test detecting latest /opt/rocm-{release} directory.
+// RUN: rm -rf %T/opt
+// RUN: mkdir -p %T/opt
+// RUN: cp -r %S/Inputs/rocm %T/opt/rocm-3.9.0-1234
+// RUN: cp -r %S/Inputs/rocm %T/opt/rocm-3.10.0
+// RUN: %clang -### -target x86_64-linux-gnu --sysroot=%T \
+// RUN:   --print-rocm-search-dirs %s 2>&1 \
+// RUN:   | FileCheck -check-prefixes=ROCM-REL %s
+
 // Test ROCm installation built by SPACK by invoke clang at 
%T/rocm-spack/llvm-amdgpu-*
 // directory through a soft link.
 
@@ -60,6 +74,11 @@
 
 // COMMON: "-triple" "amdgcn-amd-amdhsa"
 
+// ROCM-ENV: ROCm installation search path: {{.*}}/Inputs/rocm
+
+// ROCM-REL: ROCm installation search path: {{.*}}/opt/rocm
+// ROCM-REL: ROCm installation search path: {{.*}}/opt/rocm-3.10.0
+
 // SPACK: ROCm installation search path (Spack 4.0.0): [[DIR:.*]]
 // SPACK: ROCm installation search path: [[CLANG:.*]]
 // SPACK: ROCm installation search path: [[CLANG]]/lib/clang/{{[0-9.]+}}
Index: clang/lib/Driver/ToolChains/AMDGPU.cpp
===
--- clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -186,6 +186,12 @@
 ROCmSearchDirs.emplace_back(RocmPathArg.str());
 DoPrintROCmSearchDirs();
 return ROCmSearchDirs;
+  } else if (const char *RocmPathEnv = ::getenv("ROCM_PATH")) {
+if (!StringRef(RocmPathEnv).empty()) {
+  ROCmSearchDirs.emplace_back(RocmPathEnv);
+  DoPrintROCmSearchDirs();
+  return ROCmSearchDirs;
+}
   }
 
   // Try to find relative to the compiler binary.
@@ -247,6 +253,43 @@
 
   ROCmSearchDirs.emplace_back(D.SysRoot + "/opt/rocm",
   /*StrictChecking=*/true);
+
+  // Find the latest /opt/rocm-{release} directory.
+  std::error_code EC;
+  std::string LatestROCm;
+  llvm::VersionTuple LatestVer;
+  // Get ROCm version from ROCm directory name.
+  auto GetROCmVersion = [](StringRef DirName) {
+llvm::VersionTuple V;
+std::string VerStr = DirName.drop_front(strlen("rocm-")).str();
+// The ROCm directory name follows the format of
+// rocm-{major}.{minor}.{subMinor}[-{build}]
+std::replace(VerStr.begin(), VerStr.end(), '-', '.');
+V.tryParse(VerStr);
+return V;
+  };
+  for (llvm::vfs::directory_iterator
+   File = D.getVFS().dir_begin(D.SysRoot + "/opt", EC),
+   FileEnd;
+   File != FileEnd && !EC; File.increment(EC)) {
+llvm::StringRef FileName = llvm::sys::path::filename(File->path());
+if (!FileName.startswith("rocm-"))
+  continue;
+if (LatestROCm.empty()) {
+  LatestROCm = FileName.str();
+  LatestVer = GetROCmVersion(LatestROCm);
+  continue;
+}
+auto Ver = GetROCmVersion(FileName);
+if (LatestVer < Ver) {
+  LatestROCm = FileName.str();
+  LatestVer = Ver;
+}
+  }
+  if (!LatestROCm.empty())
+ROCmSearchDirs.emplace_back(D.SysRoot + "/opt/" + LatestROCm,
+/*StrictChecking=*/true);
+
   DoPrintROCmSearchDirs();
   return ROCmSearchDirs;
 }


Index: clang/test/Driver/rocm-detect.hip
===
--- clang/test/Driver/rocm-detect.hip
+++ clang/test/Driver/rocm-detect.hip
@@ -21,6 +21,20 @@
 // RUN:   --rocm-path=%S/Inputs/rocm %s 2>&1 \
 // RUN:   | FileCheck -check-prefixes=COMMON,NODEFAULTLIBS %s
 
+// Test environment variable ROCM_PATH.
+// RUN: env ROCM_PATH=%S/Inputs/rocm %clang -### -target x86_64-linux-gnu \
+// RUN:   --print-rocm-search-dirs %s 2>&1 \
+// RUN:   | FileCheck -check-prefixes=ROCM-ENV %s
+
+// Test detecting latest /opt/rocm-{release} directory.
+// RUN: rm -rf %T/opt
+// RUN: mkdir -p %T/opt
+// RUN: cp -r %S/Inputs/rocm %T/opt/rocm-3.9.0-1234
+// RUN: cp -r %S/Inputs/rocm %T/opt/rocm-3.10.0
+// RUN: %clang -### -target x86_64-linux-gnu --sysroot=%T \
+// RUN:   --print-rocm-search-dirs %s 2>&1 \
+// RUN:   | FileCheck -check-prefixes=ROCM-REL %s
+
 // Test ROCm installation built by SPACK by invoke clang at %T/rocm-spack/llvm-amdgpu-*
 // directory through a soft link.
 
@@ -60,6 +74,11 @@
 
 // COMMON: "-triple" "amdgcn-amd-amdhsa"

[PATCH] D95007: [CUDA][HIP] Add -fuse-cuid

2021-03-20 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D95007#2638955 , @MaskRay wrote:

> Should `-cuid=` be `--cuid=`?

For the existing clang options, there seem to be no rule or convention whether 
to use - or --. For example,

  -rtlib=  Compiler runtime library to use
  -save-stats= Save llvm statistics.
  -save-temps= Save intermediate compilation results.
  -std=Language standard to compile for
  -stdlib= C++ standard library to use
  -struct-layout=  Run the Structure Peeling passes
  -struct-peel-mem-block-size=
  -struct-peel-ptr-size=
  -sycl-std=   SYCL language standard to compile for.

Here I choose -cuid= since it is shorter.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D95007

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


[PATCH] D99018: [clang][flang] Moke the definition of `-module-dir` restricted to Flang

2021-03-20 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski created this revision.
Herald added a reviewer: sscalpone.
Herald added subscribers: jansvoboda11, dang.
awarzynski requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

`-module-dir` is a Flang specific option and should not be visible in
Clang. This patch adds `FlangOnlyOption` flag to its definition. This
way Clang will know that it should reject it and skip it when generating
output for `clang -help`.

The definition of `-module-dir` is moved next to other Flang options.
As `-J` is an alias for `-module-dir`, it has to be moved as well (the
alias cannot be defined before the original option). As `gfortran` mode
is effectively no longer supported (*), `-J` is claimed as Flang only
option.

This is a follow-up of a post-commit review for
https://reviews.llvm.org/D95448.

- https://reviews.llvm.org/rG6a75496836ea14bcfd2f4b59d35a1cad4ac58cee


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99018

Files:
  clang/include/clang/Driver/Options.td


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -986,11 +986,6 @@
 def module_dependency_dir : Separate<["-"], "module-dependency-dir">,
   Flags<[CC1Option]>, HelpText<"Directory to dump module dependencies to">,
   MarshallingInfoString>;
-def module_dir : Separate<["-"], "module-dir">, 
Flags<[FlangOption,FC1Option]>, MetaVarName<"">,
-  HelpText<"Put MODULE files in ">,
-  DocBrief<[{This option specifies where to put .mod files for compiled 
modules.
-It is also added to the list of directories to be searched by an USE statement.
-The default is the current directory.}]>;
 def dsym_dir : JoinedOrSeparate<["-"], "dsym-dir">,
   Flags<[NoXarchOption, RenderAsInput]>,
   HelpText<"Directory to output dSYM's (if any) to">, MetaVarName<"">;
@@ -4220,7 +4215,6 @@
 
 // Generic gfortran options.
 def A_DASH : Joined<["-"], "A-">, Group;
-def J : JoinedOrSeparate<["-"], "J">, 
Flags<[RenderJoined,FlangOption,FC1Option]>, Group, 
Alias;
 def cpp : Flag<["-"], "cpp">, Group;
 def nocpp : Flag<["-"], "nocpp">, Group;
 def static_libgfortran : Flag<["-"], "static-libgfortran">, 
Group;
@@ -4303,6 +4297,12 @@
 
//===--===//
 let Flags = [FC1Option, FlangOption, FlangOnlyOption] in {
 
+def module_dir : Separate<["-"], "module-dir">, MetaVarName<"">,
+  HelpText<"Put MODULE files in ">,
+  DocBrief<[{This option specifies where to put .mod files for compiled 
modules.
+It is also added to the list of directories to be searched by an USE statement.
+The default is the current directory.}]>;
+
 def ffixed_form : Flag<["-"], "ffixed-form">, Group,
   HelpText<"Process source files in fixed form">;
 def ffree_form : Flag<["-"], "ffree-form">, Group,
@@ -4340,6 +4340,11 @@
   HelpText<"Enable the old style PARAMETER statement">;
 }
 
+def J : JoinedOrSeparate<["-"], "J">,
+  Flags<[RenderJoined, FlangOption, FC1Option, FlangOnlyOption]>,
+  Group,
+  Alias;
+
 
//===--===//
 // FC1 Options
 
//===--===//


Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -986,11 +986,6 @@
 def module_dependency_dir : Separate<["-"], "module-dependency-dir">,
   Flags<[CC1Option]>, HelpText<"Directory to dump module dependencies to">,
   MarshallingInfoString>;
-def module_dir : Separate<["-"], "module-dir">, Flags<[FlangOption,FC1Option]>, MetaVarName<"">,
-  HelpText<"Put MODULE files in ">,
-  DocBrief<[{This option specifies where to put .mod files for compiled modules.
-It is also added to the list of directories to be searched by an USE statement.
-The default is the current directory.}]>;
 def dsym_dir : JoinedOrSeparate<["-"], "dsym-dir">,
   Flags<[NoXarchOption, RenderAsInput]>,
   HelpText<"Directory to output dSYM's (if any) to">, MetaVarName<"">;
@@ -4220,7 +4215,6 @@
 
 // Generic gfortran options.
 def A_DASH : Joined<["-"], "A-">, Group;
-def J : JoinedOrSeparate<["-"], "J">, Flags<[RenderJoined,FlangOption,FC1Option]>, Group, Alias;
 def cpp : Flag<["-"], "cpp">, Group;
 def nocpp : Flag<["-"], "nocpp">, Group;
 def static_libgfortran : Flag<["-"], "static-libgfortran">, Group;
@@ -4303,6 +4297,12 @@
 //===--===//
 let Flags = [FC1Option, FlangOption, FlangOnlyOption] in {
 
+def module_dir : Separate<["-"], "module-dir">, MetaVarName<"">,
+  HelpText<"Put MODULE files in ">,
+  DocBrief<[{This option specifies where to put .mod files for compiled modules.
+It is also added to the list of directories to be searched by an USE statement.

[PATCH] D98774: [AST] De-duplicate empty node introspection

2021-03-20 Thread Stephen Kelly via Phabricator via cfe-commits
steveire marked an inline comment as done.
steveire added a comment.

@thakis Do you have any more on this? Can we de-duplicate?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98774

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


[PATCH] D98502: [clang][Checkers] Extend PthreadLockChecker state dump (NFC).

2021-03-20 Thread Balázs Benics via Phabricator via cfe-commits
steakhal added inline comments.



Comment at: clang/test/Analysis/pthreadlock_state.c:55
+  // CHECK-NEXT:  "mtx: conj_$11{int, LC1, S1874, #1}", 
+  // CHECK-NEXT:  ""
+  // CHECK-NEXT:]}

Out of curiosity, what is the purpose of this 'empty' line? I've seen it many 
times in other tests but I still don't know.



Comment at: clang/test/Analysis/pthreadlock_state.c:70
+  // CHECK-NEXT:  "Mutexes in unresolved possibly destroyed state:", 
+  // CHECK-NEXT:  "SymRegion{reg_$12}: 
conj_$15{int, LC1, S1921, #1}", 
+  // CHECK-NEXT:  ""

I recommend not hardcoding symbol identifier numbers. `reg$NN`, `conj_$NN`, 
`LCNN`, `S`
It would result in a less fragile test.
I'm pretty sure you can use some regexp to achieve this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98502

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


[clang] dc3b438 - Revert "Revert "[Driver] Drop obsoleted Ubuntu 11.04 gcc detection""

2021-03-20 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2021-03-20T09:57:05-07:00
New Revision: dc3b438c8f34a54ba9648c97a02764319bd1aca8

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

LOG: Revert "Revert "[Driver] Drop obsoleted Ubuntu 11.04 gcc detection""

This reverts commit 24ef3ec6c1e3910eb442177c2e2e927e6a87.

Added: 


Modified: 
clang/lib/Driver/ToolChains/Gnu.cpp
clang/test/Driver/gcc-toolchain.cpp
clang/test/Driver/linux-header-search.cpp
clang/test/Driver/linux-ld.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 3c1fc87d7896..3491a29a5f9c 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2506,7 +2506,6 @@ void 
Generic_GCC::GCCInstallationDetector::ScanLibDirForGCCTriple(
 const llvm::Triple &TargetTriple, const ArgList &Args,
 const std::string &LibDir, StringRef CandidateTriple,
 bool NeedsBiarchSuffix, bool GCCDirExists, bool GCCCrossDirExists) {
-  llvm::Triple::ArchType TargetArch = TargetTriple.getArch();
   // Locations relative to the system lib directory where GCC's triple-specific
   // directories might reside.
   struct GCCLibSuffix {
@@ -2530,15 +2529,7 @@ void 
Generic_GCC::GCCInstallationDetector::ScanLibDirForGCCTriple(
   // files in that location, not just GCC installation data.
   {CandidateTriple.str(), "..",
TargetTriple.getVendor() == llvm::Triple::Freescale ||
-   TargetTriple.getVendor() == llvm::Triple::OpenEmbedded},
-
-  // Deal with cases (on Ubuntu) where the system architecture could be 
i386
-  // but the GCC target architecture could be (say) i686.
-  // FIXME: It may be worthwhile to generalize this and look for a second
-  // triple.
-  {"i386-linux-gnu/gcc/" + CandidateTriple.str(), "../../..",
-   (TargetArch == llvm::Triple::x86 &&
-TargetTriple.getOS() != llvm::Triple::Solaris)}};
+   TargetTriple.getVendor() == llvm::Triple::OpenEmbedded}};
 
   for (auto &Suffix : Suffixes) {
 if (!Suffix.Active)

diff  --git a/clang/test/Driver/gcc-toolchain.cpp 
b/clang/test/Driver/gcc-toolchain.cpp
index cddf9b1bdbca..03a7991d6c70 100644
--- a/clang/test/Driver/gcc-toolchain.cpp
+++ b/clang/test/Driver/gcc-toolchain.cpp
@@ -1,34 +1,31 @@
 // Test that gcc-toolchain option is working correctly
 //
 // RUN: %clangxx -no-canonical-prefixes %s -### -o %t 2>&1 \
-// RUN: --target=i386-unknown-linux -stdlib=libstdc++ \
-// RUN: --gcc-toolchain=%S/Inputs/ubuntu_11.04_multiarch_tree/usr \
-// RUN: --sysroot="" \
-// RUN:   | FileCheck %s
+// RUN:   --target=x86_64-linux-gnu 
--gcc-toolchain=%S/Inputs/ubuntu_14.04_multiarch_tree/usr | \
+// RUN:   FileCheck %s
 //
 // Additionally check that the legacy spelling of the flag works.
 // RUN: %clangxx -no-canonical-prefixes %s -### -o %t 2>&1 \
-// RUN: --target=i386-unknown-linux -stdlib=libstdc++ \
-// RUN: -gcc-toolchain %S/Inputs/ubuntu_11.04_multiarch_tree/usr \
-// RUN: --sysroot="" \
-// RUN:   | FileCheck %s
+// RUN:   --target=x86_64-linux-gnu -gcc-toolchain 
%S/Inputs/ubuntu_14.04_multiarch_tree/usr | \
+// RUN:   FileCheck %s
 //
 // Test for header search toolchain detection.
 // CHECK: "-internal-isystem"
-// CHECK: 
"[[TOOLCHAIN:[^"]+]]/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5/../../../../../include/c++/4.5"
+// CHECK: 
"[[TOOLCHAIN:[^"]+]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8"
 // CHECK: "-internal-isystem"
-// CHECK: 
"[[TOOLCHAIN]]/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5/../../../../../include/c++/4.5/i686-linux-gnu"
+// CHECK: 
"[[TOOLCHAIN]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/x86_64-linux-gnu/c++/4.8"
 // CHECK: "-internal-isystem"
-// CHECK: 
"[[TOOLCHAIN]]/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5/../../../../../include/c++/4.5/backward"
+// CHECK: 
"[[TOOLCHAIN]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/backward"
 // CHECK: "-internal-isystem" "/usr/local/include"
 //
 // Test for linker toolchain detection. Note that only the '-L' flags will use
 // the same precise formatting of the path as the '-internal-system' flags
 // above, so we just blanket wildcard match the 'crtbegin.o'.
 // CHECK: "{{[^"]*}}ld{{(.exe)?}}"
-// CHECK: 
"{{[^"]*}}/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5{{/|}}crtbegin.o"
-// CHECK: "-L[[TOOLCHAIN]]/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5"
-// CHECK: 
"-L[[TOOLCHAIN]]/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5/../../../.."
+// CHECK-SAME: "{{[^"]*}}/usr/lib/gcc/x86_64-linux-gnu/4.8{{/|}}crtbegin.o"
+// CHECK-SAME: "-L[[TOOLCHAIN]]/usr/lib/gcc/x86_64-linux-gnu/4.8"
+/// On x86_64, there is an extra 
usr/lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu but we sh

[PATCH] D99018: [clang][flang] Moke the definition of `-module-dir` restricted to Flang

2021-03-20 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay accepted this revision.
MaskRay added a comment.
This revision is now accepted and ready to land.

Thanks. I do not know why `FlangOption and FC1 Options` needs be in 
`clang/include/clang/Driver/Options.td` but perhaps that is how things work:)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99018

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


[PATCH] D96403: [Android] Use -l:libunwind.a with --rtlib=compiler-rt

2021-03-20 Thread Shoaib Meenai via Phabricator via cfe-commits
smeenai added a comment.

Got it, thanks for all the info!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96403

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


[clang] e92faa7 - [test] Fix Driver/gcc-toolchain.cpp if CLANG_DEFAULT_CXX_STDLIB is libc++

2021-03-20 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2021-03-20T11:06:44-07:00
New Revision: e92faa77b4b7e425fc29574c0273b3904ee2b0a6

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

LOG: [test] Fix Driver/gcc-toolchain.cpp if CLANG_DEFAULT_CXX_STDLIB is libc++

Added: 


Modified: 
clang/test/Driver/gcc-toolchain.cpp

Removed: 




diff  --git a/clang/test/Driver/gcc-toolchain.cpp 
b/clang/test/Driver/gcc-toolchain.cpp
index 03a7991d6c70..8bb391f19eac 100644
--- a/clang/test/Driver/gcc-toolchain.cpp
+++ b/clang/test/Driver/gcc-toolchain.cpp
@@ -1,12 +1,12 @@
 // Test that gcc-toolchain option is working correctly
 //
-// RUN: %clangxx -no-canonical-prefixes %s -### -o %t 2>&1 \
-// RUN:   --target=x86_64-linux-gnu 
--gcc-toolchain=%S/Inputs/ubuntu_14.04_multiarch_tree/usr | \
+// RUN: %clangxx -no-canonical-prefixes %s -### -o %t 
--target=x86_64-linux-gnu \
+// RUN:   --gcc-toolchain=%S/Inputs/ubuntu_14.04_multiarch_tree/usr 
-stdlib=libstdc++ 2>&1 | \
 // RUN:   FileCheck %s
 //
 // Additionally check that the legacy spelling of the flag works.
-// RUN: %clangxx -no-canonical-prefixes %s -### -o %t 2>&1 \
-// RUN:   --target=x86_64-linux-gnu -gcc-toolchain 
%S/Inputs/ubuntu_14.04_multiarch_tree/usr | \
+// RUN: %clangxx -no-canonical-prefixes %s -### -o %t 
--target=x86_64-linux-gnu \
+// RUN:   --gcc-toolchain=%S/Inputs/ubuntu_14.04_multiarch_tree/usr 
-stdlib=libstdc++ 2>&1 | \
 // RUN:   FileCheck %s
 //
 // Test for header search toolchain detection.



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


[clang] 188405b - [AST] Ensure that an empty json file is generated if compile errors

2021-03-20 Thread Stephen Kelly via cfe-commits

Author: Stephen Kelly
Date: 2021-03-20T18:08:01Z
New Revision: 188405bc192df54fbf048ddd3da071c9fff4d0d1

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

LOG: [AST] Ensure that an empty json file is generated if compile errors

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

Added: 


Modified: 
clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.cpp
clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.h
clang/lib/Tooling/DumpTool/ClangSrcLocDump.cpp

Removed: 




diff  --git a/clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.cpp 
b/clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.cpp
index ff279d9425d8..e7400e958716 100644
--- a/clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.cpp
+++ b/clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.cpp
@@ -79,17 +79,16 @@ llvm::json::Object toJSON(llvm::StringMap const 
&Obj) {
   return JsonObj;
 }
 
-void WriteJSON(std::string JsonPath,
-   llvm::StringMap const &ClassInheritance,
-   llvm::StringMap> const &ClassesInClade,
-   llvm::StringMap const &ClassEntries) {
+void WriteJSON(std::string JsonPath, llvm::json::Object &&ClassInheritance,
+   llvm::json::Object &&ClassesInClade,
+   llvm::json::Object &&ClassEntries) {
   llvm::json::Object JsonObj;
 
   using llvm::json::toJSON;
 
-  JsonObj["classInheritance"] = ::toJSON(ClassInheritance);
-  JsonObj["classesInClade"] = ::toJSON(ClassesInClade);
-  JsonObj["classEntries"] = ::toJSON(ClassEntries);
+  JsonObj["classInheritance"] = std::move(ClassInheritance);
+  JsonObj["classesInClade"] = std::move(ClassesInClade);
+  JsonObj["classEntries"] = std::move(ClassEntries);
 
   std::error_code EC;
   llvm::raw_fd_ostream JsonOut(JsonPath, EC, llvm::sys::fs::F_Text);
@@ -101,9 +100,12 @@ void WriteJSON(std::string JsonPath,
 }
 
 void ASTSrcLocProcessor::generate() {
-  WriteJSON(JsonPath, ClassInheritance, ClassesInClade, ClassEntries);
+  WriteJSON(JsonPath, ::toJSON(ClassInheritance), ::toJSON(ClassesInClade),
+::toJSON(ClassEntries));
 }
 
+void ASTSrcLocProcessor::generateEmpty() { WriteJSON(JsonPath, {}, {}, {}); }
+
 std::vector
 CaptureMethods(std::string TypeString, const clang::CXXRecordDecl *ASTClass,
const MatchFinder::MatchResult &Result) {

diff  --git a/clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.h 
b/clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.h
index 00994758e03c..5d848f48ed54 100644
--- a/clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.h
+++ b/clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.h
@@ -30,6 +30,7 @@ class ASTSrcLocProcessor : public 
ast_matchers::MatchFinder::MatchCallback {
  StringRef File);
 
   void generate();
+  void generateEmpty();
 
 private:
   void run(const ast_matchers::MatchFinder::MatchResult &Result) override;

diff  --git a/clang/lib/Tooling/DumpTool/ClangSrcLocDump.cpp 
b/clang/lib/Tooling/DumpTool/ClangSrcLocDump.cpp
index 06b58c6382ed..8328977178cc 100644
--- a/clang/lib/Tooling/DumpTool/ClangSrcLocDump.cpp
+++ b/clang/lib/Tooling/DumpTool/ClangSrcLocDump.cpp
@@ -48,7 +48,13 @@ class ASTSrcLocGenerationAction : public 
clang::ASTFrontendAction {
 public:
   ASTSrcLocGenerationAction() : Processor(JsonOutputPath) {}
 
-  ~ASTSrcLocGenerationAction() { Processor.generate(); }
+  void ExecuteAction() override {
+clang::ASTFrontendAction::ExecuteAction();
+if (getCompilerInstance().getDiagnostics().getNumErrors() > 0)
+  Processor.generateEmpty();
+else
+  Processor.generate();
+  }
 
   std::unique_ptr
   CreateASTConsumer(clang::CompilerInstance &Compiler,



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


[PATCH] D98827: [AST] Ensure that an empty json file is generated if compile errors

2021-03-20 Thread Stephen Kelly via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG188405bc192d: [AST] Ensure that an empty json file is 
generated if compile errors (authored by stephenkelly).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98827

Files:
  clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.cpp
  clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.h
  clang/lib/Tooling/DumpTool/ClangSrcLocDump.cpp


Index: clang/lib/Tooling/DumpTool/ClangSrcLocDump.cpp
===
--- clang/lib/Tooling/DumpTool/ClangSrcLocDump.cpp
+++ clang/lib/Tooling/DumpTool/ClangSrcLocDump.cpp
@@ -48,7 +48,13 @@
 public:
   ASTSrcLocGenerationAction() : Processor(JsonOutputPath) {}
 
-  ~ASTSrcLocGenerationAction() { Processor.generate(); }
+  void ExecuteAction() override {
+clang::ASTFrontendAction::ExecuteAction();
+if (getCompilerInstance().getDiagnostics().getNumErrors() > 0)
+  Processor.generateEmpty();
+else
+  Processor.generate();
+  }
 
   std::unique_ptr
   CreateASTConsumer(clang::CompilerInstance &Compiler,
Index: clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.h
===
--- clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.h
+++ clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.h
@@ -30,6 +30,7 @@
  StringRef File);
 
   void generate();
+  void generateEmpty();
 
 private:
   void run(const ast_matchers::MatchFinder::MatchResult &Result) override;
Index: clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.cpp
===
--- clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.cpp
+++ clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.cpp
@@ -79,17 +79,16 @@
   return JsonObj;
 }
 
-void WriteJSON(std::string JsonPath,
-   llvm::StringMap const &ClassInheritance,
-   llvm::StringMap> const &ClassesInClade,
-   llvm::StringMap const &ClassEntries) {
+void WriteJSON(std::string JsonPath, llvm::json::Object &&ClassInheritance,
+   llvm::json::Object &&ClassesInClade,
+   llvm::json::Object &&ClassEntries) {
   llvm::json::Object JsonObj;
 
   using llvm::json::toJSON;
 
-  JsonObj["classInheritance"] = ::toJSON(ClassInheritance);
-  JsonObj["classesInClade"] = ::toJSON(ClassesInClade);
-  JsonObj["classEntries"] = ::toJSON(ClassEntries);
+  JsonObj["classInheritance"] = std::move(ClassInheritance);
+  JsonObj["classesInClade"] = std::move(ClassesInClade);
+  JsonObj["classEntries"] = std::move(ClassEntries);
 
   std::error_code EC;
   llvm::raw_fd_ostream JsonOut(JsonPath, EC, llvm::sys::fs::F_Text);
@@ -101,9 +100,12 @@
 }
 
 void ASTSrcLocProcessor::generate() {
-  WriteJSON(JsonPath, ClassInheritance, ClassesInClade, ClassEntries);
+  WriteJSON(JsonPath, ::toJSON(ClassInheritance), ::toJSON(ClassesInClade),
+::toJSON(ClassEntries));
 }
 
+void ASTSrcLocProcessor::generateEmpty() { WriteJSON(JsonPath, {}, {}, {}); }
+
 std::vector
 CaptureMethods(std::string TypeString, const clang::CXXRecordDecl *ASTClass,
const MatchFinder::MatchResult &Result) {


Index: clang/lib/Tooling/DumpTool/ClangSrcLocDump.cpp
===
--- clang/lib/Tooling/DumpTool/ClangSrcLocDump.cpp
+++ clang/lib/Tooling/DumpTool/ClangSrcLocDump.cpp
@@ -48,7 +48,13 @@
 public:
   ASTSrcLocGenerationAction() : Processor(JsonOutputPath) {}
 
-  ~ASTSrcLocGenerationAction() { Processor.generate(); }
+  void ExecuteAction() override {
+clang::ASTFrontendAction::ExecuteAction();
+if (getCompilerInstance().getDiagnostics().getNumErrors() > 0)
+  Processor.generateEmpty();
+else
+  Processor.generate();
+  }
 
   std::unique_ptr
   CreateASTConsumer(clang::CompilerInstance &Compiler,
Index: clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.h
===
--- clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.h
+++ clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.h
@@ -30,6 +30,7 @@
  StringRef File);
 
   void generate();
+  void generateEmpty();
 
 private:
   void run(const ast_matchers::MatchFinder::MatchResult &Result) override;
Index: clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.cpp
===
--- clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.cpp
+++ clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.cpp
@@ -79,17 +79,16 @@
   return JsonObj;
 }
 
-void WriteJSON(std::string JsonPath,
-   llvm::StringMap const &ClassInheritance,
-   llvm::StringMap> const &ClassesInClade,
-   llvm::StringMap const &ClassEntries) {
+void WriteJSON(std::string JsonPath, llvm::json::Object &&ClassInheritance,
+   llvm::j

[PATCH] D98775: [AST] Add introspection support for Decls

2021-03-20 Thread Stephen Kelly via Phabricator via cfe-commits
steveire updated this revision to Diff 332119.
steveire added a comment.

Update


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98775

Files:
  clang/include/clang/Tooling/NodeIntrospection.h
  clang/lib/Tooling/CMakeLists.txt
  clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.cpp
  clang/lib/Tooling/DumpTool/generate_cxx_src_locs.py
  clang/unittests/Introspection/IntrospectionTest.cpp

Index: clang/unittests/Introspection/IntrospectionTest.cpp
===
--- clang/unittests/Introspection/IntrospectionTest.cpp
+++ clang/unittests/Introspection/IntrospectionTest.cpp
@@ -42,7 +42,7 @@
 
 #define STRING_LOCATION_PAIR(INSTANCE, LOC) Pair(#LOC, INSTANCE->LOC)
 
-TEST(Introspection, SourceLocations) {
+TEST(Introspection, SourceLocations_Stmt) {
   auto AST = buildASTFromCode("void foo() {} void bar() { foo(); }", "foo.cpp",
   std::make_shared());
   auto &Ctx = AST->getASTContext();
@@ -79,3 +79,69 @@
   EXPECT_THAT(ExpectedRanges, UnorderedElementsAre(STRING_LOCATION_PAIR(
   FooCall, getSourceRange(;
 }
+
+TEST(Introspection, SourceLocations_Decl) {
+  auto AST =
+  buildASTFromCode(R"cpp(
+namespace ns1 {
+namespace ns2 {
+template  struct Foo {};
+template  struct Bar {
+  struct Nested {
+template 
+Foo method(int i, bool b) const noexcept(true);
+  };
+};
+} // namespace ns2
+} // namespace ns1
+
+template 
+template 
+ns1::ns2::Foo ns1::ns2::Bar::Nested::method(int i, bool b) const
+noexcept(true) {}
+)cpp",
+   "foo.cpp", std::make_shared());
+  auto &Ctx = AST->getASTContext();
+  auto &TU = *Ctx.getTranslationUnitDecl();
+
+  auto BoundNodes = ast_matchers::match(
+  decl(hasDescendant(
+  cxxMethodDecl(hasName("method"), isDefinition()).bind("method"))),
+  TU, Ctx);
+
+  EXPECT_EQ(BoundNodes.size(), 1u);
+
+  auto *MethodDecl = BoundNodes[0].getNodeAs("method");
+
+  auto Result = NodeIntrospection::GetLocations(MethodDecl);
+
+  if (Result.LocationAccessors.empty() && Result.RangeAccessors.empty()) {
+return;
+  }
+
+  auto ExpectedLocations =
+  FormatExpected(Result.LocationAccessors);
+
+  EXPECT_THAT(ExpectedLocations,
+  UnorderedElementsAre(
+  STRING_LOCATION_PAIR(MethodDecl, getBeginLoc()),
+  STRING_LOCATION_PAIR(MethodDecl, getBodyRBrace()),
+  STRING_LOCATION_PAIR(MethodDecl, getEllipsisLoc()),
+  STRING_LOCATION_PAIR(MethodDecl, getInnerLocStart()),
+  STRING_LOCATION_PAIR(MethodDecl, getLocation()),
+  STRING_LOCATION_PAIR(MethodDecl, getOuterLocStart()),
+  STRING_LOCATION_PAIR(MethodDecl, getPointOfInstantiation()),
+  STRING_LOCATION_PAIR(MethodDecl, getTypeSpecEndLoc()),
+  STRING_LOCATION_PAIR(MethodDecl, getTypeSpecStartLoc()),
+  STRING_LOCATION_PAIR(MethodDecl, getEndLoc(;
+
+  auto ExpectedRanges = FormatExpected(Result.RangeAccessors);
+
+  EXPECT_THAT(
+  ExpectedRanges,
+  UnorderedElementsAre(
+  STRING_LOCATION_PAIR(MethodDecl, getExceptionSpecSourceRange()),
+  STRING_LOCATION_PAIR(MethodDecl, getParametersSourceRange()),
+  STRING_LOCATION_PAIR(MethodDecl, getReturnTypeSourceRange()),
+  STRING_LOCATION_PAIR(MethodDecl, getSourceRange(;
+}
Index: clang/lib/Tooling/DumpTool/generate_cxx_src_locs.py
===
--- clang/lib/Tooling/DumpTool/generate_cxx_src_locs.py
+++ clang/lib/Tooling/DumpTool/generate_cxx_src_locs.py
@@ -177,6 +177,9 @@
 NodeLocationAccessors NodeIntrospection::GetLocations(clang::Stmt const *) {
   return {};
 }
+NodeLocationAccessors NodeIntrospection::GetLocations(clang::Decl const *) {
+  return {};
+}
 NodeLocationAccessors
 NodeIntrospection::GetLocations(clang::DynTypedNode const &) {
   return {};
Index: clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.cpp
===
--- clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.cpp
+++ clang/lib/Tooling/DumpTool/ASTSrcLocProcessor.cpp
@@ -26,7 +26,8 @@
   isDefinition(),
   isSameOrDerivedFrom(
   // TODO: Extend this with other clades
-  namedDecl(hasName("clang::Stmt")).bind("nodeClade")),
+  namedDecl(hasAnyName("clang::Stmt", "clang::Decl"))
+  .bind("nodeClade")),
   optionally(isDerivedFrom(cxxRecordDecl().bind("derivedFrom"
   .bind("className"),
   this);
Index: clang/lib/Tooling/CMakeLists.txt
===
--- clang/lib/Tooling/CMakeLists.txt
+++ clang/lib/Tooling/CMakeLists.txt
@@ -40,6 +40,9 @@
 NodeLocationAccessors NodeIntrospection::GetLocations(clang::Stmt const

[clang] ee8b538 - [BranchProbability] move options for 'likely' and 'unlikely'

2021-03-20 Thread Sanjay Patel via cfe-commits

Author: Sanjay Patel
Date: 2021-03-20T14:46:46-04:00
New Revision: ee8b53815ddf6f6f94ade0068903cd5ae843fafa

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

LOG: [BranchProbability] move options for 'likely' and 'unlikely'

This makes the settings available for use in other passes by housing
them within the Support lib, but NFC otherwise.

See D98898 for the proposed usage in SimplifyCFG
(where this change was originally included).

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

Added: 


Modified: 
clang/lib/CodeGen/CodeGenFunction.cpp
llvm/include/llvm/Support/BranchProbability.h
llvm/include/llvm/Transforms/Scalar/LowerExpectIntrinsic.h
llvm/lib/Support/BranchProbability.cpp
llvm/lib/Transforms/Scalar/LowerExpectIntrinsic.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CodeGenFunction.cpp 
b/clang/lib/CodeGen/CodeGenFunction.cpp
index a00ae74fa165..18927b46958c 100644
--- a/clang/lib/CodeGen/CodeGenFunction.cpp
+++ b/clang/lib/CodeGen/CodeGenFunction.cpp
@@ -42,8 +42,8 @@
 #include "llvm/IR/Intrinsics.h"
 #include "llvm/IR/MDBuilder.h"
 #include "llvm/IR/Operator.h"
+#include "llvm/Support/BranchProbability.h"
 #include "llvm/Support/CRC.h"
-#include "llvm/Transforms/Scalar/LowerExpectIntrinsic.h"
 #include "llvm/Transforms/Utils/PromoteMemToReg.h"
 using namespace clang;
 using namespace CodeGen;

diff  --git a/llvm/include/llvm/Support/BranchProbability.h 
b/llvm/include/llvm/Support/BranchProbability.h
index 6c7ad1fe2a52..f977c70221a5 100644
--- a/llvm/include/llvm/Support/BranchProbability.h
+++ b/llvm/include/llvm/Support/BranchProbability.h
@@ -13,6 +13,7 @@
 #ifndef LLVM_SUPPORT_BRANCHPROBABILITY_H
 #define LLVM_SUPPORT_BRANCHPROBABILITY_H
 
+#include "llvm/Support/CommandLine.h"
 #include "llvm/Support/DataTypes.h"
 #include 
 #include 
@@ -21,6 +22,9 @@
 
 namespace llvm {
 
+extern cl::opt LikelyBranchWeight;
+extern cl::opt UnlikelyBranchWeight;
+
 class raw_ostream;
 
 // This class represents Branch Probability as a non-negative fraction that is

diff  --git a/llvm/include/llvm/Transforms/Scalar/LowerExpectIntrinsic.h 
b/llvm/include/llvm/Transforms/Scalar/LowerExpectIntrinsic.h
index 22b2e649e4d4..4e47ff70d557 100644
--- a/llvm/include/llvm/Transforms/Scalar/LowerExpectIntrinsic.h
+++ b/llvm/include/llvm/Transforms/Scalar/LowerExpectIntrinsic.h
@@ -17,7 +17,6 @@
 
 #include "llvm/IR/Function.h"
 #include "llvm/IR/PassManager.h"
-#include "llvm/Support/CommandLine.h"
 
 namespace llvm {
 
@@ -32,8 +31,6 @@ struct LowerExpectIntrinsicPass : 
PassInfoMixin {
   PreservedAnalyses run(Function &F, FunctionAnalysisManager &);
 };
 
-extern cl::opt LikelyBranchWeight;
-extern cl::opt UnlikelyBranchWeight;
 }
 
 #endif

diff  --git a/llvm/lib/Support/BranchProbability.cpp 
b/llvm/lib/Support/BranchProbability.cpp
index 60d5478a9052..d93d9cffb9f7 100644
--- a/llvm/lib/Support/BranchProbability.cpp
+++ b/llvm/lib/Support/BranchProbability.cpp
@@ -19,6 +19,20 @@
 
 using namespace llvm;
 
+// These default values are chosen to represent an extremely skewed outcome for
+// a condition, but they leave some room for interpretation by later passes.
+//
+// If the documentation for __builtin_expect() was made explicit that it should
+// only be used in extreme cases, we could make this ratio higher. As it 
stands,
+// programmers may be using __builtin_expect() / llvm.expect to annotate that a
+// branch is only mildly likely or unlikely to be taken.
+cl::opt llvm::LikelyBranchWeight(
+"likely-branch-weight", cl::Hidden, cl::init(2000),
+cl::desc("Weight of the branch likely to be taken (default = 2000)"));
+cl::opt llvm::UnlikelyBranchWeight(
+"unlikely-branch-weight", cl::Hidden, cl::init(1),
+cl::desc("Weight of the branch unlikely to be taken (default = 1)"));
+
 constexpr uint32_t BranchProbability::D;
 
 raw_ostream &BranchProbability::print(raw_ostream &OS) const {

diff  --git a/llvm/lib/Transforms/Scalar/LowerExpectIntrinsic.cpp 
b/llvm/lib/Transforms/Scalar/LowerExpectIntrinsic.cpp
index da13075dfee2..d862fcfe8ce5 100644
--- a/llvm/lib/Transforms/Scalar/LowerExpectIntrinsic.cpp
+++ b/llvm/lib/Transforms/Scalar/LowerExpectIntrinsic.cpp
@@ -24,6 +24,7 @@
 #include "llvm/IR/Metadata.h"
 #include "llvm/InitializePasses.h"
 #include "llvm/Pass.h"
+#include "llvm/Support/BranchProbability.h"
 #include "llvm/Support/Debug.h"
 #include "llvm/Transforms/Scalar.h"
 
@@ -34,25 +35,6 @@ using namespace llvm;
 STATISTIC(ExpectIntrinsicsHandled,
   "Number of 'expect' intrinsic instructions handled");
 
-// These default values are chosen to represent an extremely skewed outcome for
-// a condition, but they leave some room for interpretation by later passes.
-//
-// If the documentation for __builtin_expect() was made explicit 

[PATCH] D98945: [BranchProbability] move options for 'likely' and 'unlikely'

2021-03-20 Thread Sanjay Patel via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGee8b53815ddf: [BranchProbability] move options for 
'likely' and 'unlikely' (authored by spatel).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98945

Files:
  clang/lib/CodeGen/CodeGenFunction.cpp
  llvm/include/llvm/Support/BranchProbability.h
  llvm/include/llvm/Transforms/Scalar/LowerExpectIntrinsic.h
  llvm/lib/Support/BranchProbability.cpp
  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,6 +24,7 @@
 #include "llvm/IR/Metadata.h"
 #include "llvm/InitializePasses.h"
 #include "llvm/Pass.h"
+#include "llvm/Support/BranchProbability.h"
 #include "llvm/Support/Debug.h"
 #include "llvm/Transforms/Scalar.h"
 
@@ -34,25 +35,6 @@
 STATISTIC(ExpectIntrinsicsHandled,
   "Number of 'expect' intrinsic instructions handled");
 
-// These default values are chosen to represent an extremely skewed outcome for
-// a condition, but they leave some room for interpretation by later passes.
-//
-// If the documentation for __builtin_expect() was made explicit that it should
-// only be used in extreme cases, we could make this ratio higher. As it stands,
-// programmers may be using __builtin_expect() / llvm.expect to annotate that a
-// branch is likely or unlikely to be taken.
-//
-// There is a known dependency on this ratio in CodeGenPrepare when transforming
-// 'select' instructions. It may be worthwhile to hoist these values to some
-// shared space, so they can be used directly by other passes.
-
-cl::opt llvm::LikelyBranchWeight(
-"likely-branch-weight", cl::Hidden, cl::init(2000),
-cl::desc("Weight of the branch likely to be taken (default = 2000)"));
-cl::opt llvm::UnlikelyBranchWeight(
-"unlikely-branch-weight", cl::Hidden, cl::init(1),
-cl::desc("Weight of the branch unlikely to be taken (default = 1)"));
-
 static std::tuple
 getBranchWeight(Intrinsic::ID IntrinsicID, CallInst *CI, int BranchCount) {
   if (IntrinsicID == Intrinsic::expect) {
Index: llvm/lib/Support/BranchProbability.cpp
===
--- llvm/lib/Support/BranchProbability.cpp
+++ llvm/lib/Support/BranchProbability.cpp
@@ -19,6 +19,20 @@
 
 using namespace llvm;
 
+// These default values are chosen to represent an extremely skewed outcome for
+// a condition, but they leave some room for interpretation by later passes.
+//
+// If the documentation for __builtin_expect() was made explicit that it should
+// only be used in extreme cases, we could make this ratio higher. As it stands,
+// programmers may be using __builtin_expect() / llvm.expect to annotate that a
+// branch is only mildly likely or unlikely to be taken.
+cl::opt llvm::LikelyBranchWeight(
+"likely-branch-weight", cl::Hidden, cl::init(2000),
+cl::desc("Weight of the branch likely to be taken (default = 2000)"));
+cl::opt llvm::UnlikelyBranchWeight(
+"unlikely-branch-weight", cl::Hidden, cl::init(1),
+cl::desc("Weight of the branch unlikely to be taken (default = 1)"));
+
 constexpr uint32_t BranchProbability::D;
 
 raw_ostream &BranchProbability::print(raw_ostream &OS) const {
Index: llvm/include/llvm/Transforms/Scalar/LowerExpectIntrinsic.h
===
--- llvm/include/llvm/Transforms/Scalar/LowerExpectIntrinsic.h
+++ llvm/include/llvm/Transforms/Scalar/LowerExpectIntrinsic.h
@@ -17,7 +17,6 @@
 
 #include "llvm/IR/Function.h"
 #include "llvm/IR/PassManager.h"
-#include "llvm/Support/CommandLine.h"
 
 namespace llvm {
 
@@ -32,8 +31,6 @@
   PreservedAnalyses run(Function &F, FunctionAnalysisManager &);
 };
 
-extern cl::opt LikelyBranchWeight;
-extern cl::opt UnlikelyBranchWeight;
 }
 
 #endif
Index: llvm/include/llvm/Support/BranchProbability.h
===
--- llvm/include/llvm/Support/BranchProbability.h
+++ llvm/include/llvm/Support/BranchProbability.h
@@ -13,6 +13,7 @@
 #ifndef LLVM_SUPPORT_BRANCHPROBABILITY_H
 #define LLVM_SUPPORT_BRANCHPROBABILITY_H
 
+#include "llvm/Support/CommandLine.h"
 #include "llvm/Support/DataTypes.h"
 #include 
 #include 
@@ -21,6 +22,9 @@
 
 namespace llvm {
 
+extern cl::opt LikelyBranchWeight;
+extern cl::opt UnlikelyBranchWeight;
+
 class raw_ostream;
 
 // This class represents Branch Probability as a non-negative fraction that is
Index: clang/lib/CodeGen/CodeGenFunction.cpp
===
--- clang/lib/CodeGen/CodeGenFunction.cpp
+++ clang/lib/CodeGen/CodeGenFunction.cpp
@@ -42,8 +42,8 @@
 #i

[clang] f628ba0 - [test] Fix Driver/gcc-toolchain.cpp if CLANG_DEFAULT_RTLIB is compiler-rt

2021-03-20 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2021-03-20T13:24:49-07:00
New Revision: f628ba0b55b117dc68f9cb3be58189c05910660c

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

LOG: [test] Fix Driver/gcc-toolchain.cpp if CLANG_DEFAULT_RTLIB is compiler-rt

Added: 


Modified: 
clang/test/Driver/gcc-toolchain.cpp

Removed: 




diff  --git a/clang/test/Driver/gcc-toolchain.cpp 
b/clang/test/Driver/gcc-toolchain.cpp
index 8bb391f19eac..4bd658315a44 100644
--- a/clang/test/Driver/gcc-toolchain.cpp
+++ b/clang/test/Driver/gcc-toolchain.cpp
@@ -1,12 +1,14 @@
 // Test that gcc-toolchain option is working correctly
 //
+/// Without --rtlib=libgcc the driver may pick clang_rt.crtbegin.o if
+/// -DCLANG_DEFAULT_RTLIB=compiler-rt.
 // RUN: %clangxx -no-canonical-prefixes %s -### -o %t 
--target=x86_64-linux-gnu \
-// RUN:   --gcc-toolchain=%S/Inputs/ubuntu_14.04_multiarch_tree/usr 
-stdlib=libstdc++ 2>&1 | \
+// RUN:   --gcc-toolchain=%S/Inputs/ubuntu_14.04_multiarch_tree/usr 
-stdlib=libstdc++ --rtlib=libgcc 2>&1 | \
 // RUN:   FileCheck %s
 //
 // Additionally check that the legacy spelling of the flag works.
 // RUN: %clangxx -no-canonical-prefixes %s -### -o %t 
--target=x86_64-linux-gnu \
-// RUN:   --gcc-toolchain=%S/Inputs/ubuntu_14.04_multiarch_tree/usr 
-stdlib=libstdc++ 2>&1 | \
+// RUN:   -gcc-toolchain %S/Inputs/ubuntu_14.04_multiarch_tree/usr 
-stdlib=libstdc++ --rtlib=libgcc 2>&1 | \
 // RUN:   FileCheck %s
 //
 // Test for header search toolchain detection.



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


[PATCH] D98948: [analyzer][solver] Fix infeasible constraints (PR49642)

2021-03-20 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: clang/test/Analysis/PR49642.c:1
+// RUN: %clang --analyze -Xclang -analyzer-checker=core %s
+

vsavchenko wrote:
> NoQ wrote:
> > Why not the usual `%clang_analyze_cc1`? Your approach only adds driver 
> > testing which doesn't seem to test anything new. Also if you do `clang 
> > --analyze` you don't need to enable `core` explicitly, you already have all 
> > on-by-default checks running.
> I didn't figure out how to reproduce the crash with `%clang_analyze_cc1` :-(
Mmm ok weird. Let's start by using `-###` to convert the driver invocation into 
a `-cc1` invocation and then bisecting flags until we obtain a minimal `-cc1` 
invocation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98948

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


[PATCH] D98995: [CGAtomic] Lift stronger requirements on cmpxch and add support for acquire failure mode

2021-03-20 Thread JF Bastien via Phabricator via cfe-commits
jfb accepted this revision.
jfb added a comment.
This revision is now accepted and ready to land.

Maybe refer to http://wg21.link/p0418 directly in the commit message?


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

https://reviews.llvm.org/D98995

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


[PATCH] D97183: [analyzer] Add NoteTag for smart-ptr get()

2021-03-20 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added a comment.

No-no, `TrackControlDependencyCondBRVisitor`'s purpose is completely different. 
It tracks symbols that didn't necessarily participate in the report but 
participated in conditional statements that lexically surround the report. It's 
used for explaining how did we got ourselves into a given lexical spot but it 
doesn't explain why is this a problem.

We can get it out of the way:

  A *a = P.get(); // no note expected
  if (!P) {}
  P->foo();

vs.

  A *a = P.get(); // expected note
  if (!a) {}
  P->foo();

I suspect that it may still work and the reason this works is because we're not 
collapsing `.get()`'s return value to null when it's constrained to null. Given 
that the only interesting thing that could happen to the return value of 
`.get()` is getting constrained to null (because it's an rvalue, the programmer 
can't use it to overwrite the raw pointer value inside the pointer), it's 
either already null or you'd see the constraint tracked once you mark the 
symbol as interesting.

The reason i'd still not like this solution is because collapsing the symbol to 
null on `.get()` (if it's already constrained to null) is arguably the 
preferred behavior as it makes constraint solver's life easier. But that'd most 
likely break your tracking solution.

In D97183#2637341 , @steakhal wrote:

> Do you think it is a related issue @NoQ?

I don't see any smart pointers or null dereferences so... no? But there's 
definitely //an// issue with tracking in your example. It's definitely correct 
that `div` is initialized with zero on the path on which `p0` is zero but the 
events that led to `p0` being zero are not explained which is a bug that needs 
to be fixed.




Comment at: clang/test/Analysis/smart-ptr-text-output.cpp:317
 
 void getShouldNotAlwaysLeaveANote() {
std::unique_ptr P; // expected-note {{Default constructed smart 
pointer 'P' is null}}

Looks like your git history is acting up. Your patch adds this test right? Are 
there more proposed changes in the cpp files that aren't currently highlighted 
for a similar reason?

I'll try to play with your patch locally once this is fixed ^.^


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97183

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


[PATCH] D99005: [clang] WIP: Implement P2266

2021-03-20 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov added a comment.

In D99005#2639501 , @aaronpuchert 
wrote:

> For coroutines I have D68845 . The current 
> code is wrong, and not trivial to fix. We have never properly implemented 
> P1825  and will probably just go with P2266 
>  unconditionally, because that two-phase 
> lookup is very cumbersome to imlement.

Okay, once this is properly tested, we can spin a separate patch from this, 
just taking the coroutine bits unconditionally, and propose a new DR.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99005

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


[PATCH] D97993: [Driver] Suppress GCC detection under -B

2021-03-20 Thread Vlad Vereschaka via Phabricator via cfe-commits
vvereschaka added a comment.

Hi @MaskRay,

sorry, but these changes break the `Clang::gcc-toolchain.cpp` test on the 
ARMv7/AArch64 cross builders:

- https://lab.llvm.org/buildbot/#/builders/119/builds/2807 (Aarch64)
- https://lab.llvm.org/buildbot/#/builders/60/builds/2416 (ARMv7)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97993

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


[clang] 1fe1e99 - [test] Delete "-internal-isystem" "/usr/local/include"

2021-03-20 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2021-03-20T15:24:02-07:00
New Revision: 1fe1e996e987426e5d6352dabef358fc4ae619e5

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

LOG: [test] Delete "-internal-isystem" "/usr/local/include"

Added: 


Modified: 
clang/test/Driver/gcc-toolchain.cpp

Removed: 




diff  --git a/clang/test/Driver/gcc-toolchain.cpp 
b/clang/test/Driver/gcc-toolchain.cpp
index 4bd658315a44..fa256bec2b9a 100644
--- a/clang/test/Driver/gcc-toolchain.cpp
+++ b/clang/test/Driver/gcc-toolchain.cpp
@@ -18,7 +18,6 @@
 // CHECK: 
"[[TOOLCHAIN]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/x86_64-linux-gnu/c++/4.8"
 // CHECK: "-internal-isystem"
 // CHECK: 
"[[TOOLCHAIN]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/backward"
-// CHECK: "-internal-isystem" "/usr/local/include"
 //
 // Test for linker toolchain detection. Note that only the '-L' flags will use
 // the same precise formatting of the path as the '-internal-system' flags



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


[PATCH] D97993: [Driver] Suppress GCC detection under -B

2021-03-20 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D97993#2639844 , @vvereschaka wrote:

> Hi @MaskRay,
>
> sorry, but these changes break the `Clang::gcc-toolchain.cpp` test on the 
> ARMv7/AArch64 cross builders:
>
> - https://lab.llvm.org/buildbot/#/builders/119/builds/2807 (Aarch64)
> - https://lab.llvm.org/buildbot/#/builders/60/builds/2416 (ARMv7)

The Windows bots don't have `/usr/local/include/`. I think they should have 
been broken before my change. Anycase, I deleted `"-internal-isystem" 
"/usr/local/include"` in 1fe1e996e987426e5d6352dabef358fc4ae619e5 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97993

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


[clang] 06d6b14 - [Driver] Gnu.cpp: remove unneeded -L lib/gcc/$triple/$version/../../../$triple

2021-03-20 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2021-03-20T18:50:14-07:00
New Revision: 06d6b1471eb809aaad0681e1eb88727ac8225d47

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

LOG: [Driver] Gnu.cpp: remove unneeded -L 
lib/gcc/$triple/$version/../../../$triple

After path resolution, it duplicates a subsequent -L entry. The entry below
(lib/gcc/$triple/$version/../../../../$OSLibDir) usually does not exist (e.g.
Arch Linux; Debian cross gcc). When it exists, it typically just has ld.so (e.g.
Debian native gcc) which cannot cause collision. Removing the -L (similar to
reordering it) is therefore justified.

Added: 


Modified: 
clang/lib/Driver/ToolChains/Gnu.cpp
clang/test/Driver/linux-ld.c
clang/test/Driver/mips-reduced-toolchain.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 3491a29a5f9c..f9df2370266c 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2843,10 +2843,8 @@ void Generic_GCC::AddMultilibPaths(const Driver &D,
 // the cross. Note that GCC does include some of these directories in some
 // configurations but this seems somewhere between questionable and simply
 // a bug.
-if (StringRef(LibPath).startswith(SysRoot)) {
-  addPathIfExists(D, LibPath + "/" + MultiarchTriple, Paths);
+if (StringRef(LibPath).startswith(SysRoot))
   addPathIfExists(D, LibPath + "/../" + OSLibDir, Paths);
-}
   }
 }
 

diff  --git a/clang/test/Driver/linux-ld.c b/clang/test/Driver/linux-ld.c
index 8ba57a941443..a07b289540ec 100644
--- a/clang/test/Driver/linux-ld.c
+++ b/clang/test/Driver/linux-ld.c
@@ -572,16 +572,15 @@
 // RUN: --sysroot=%S/Inputs/ubuntu_12.04_LTS_multiarch_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-UBUNTU-12-04-ARM-HF %s
 // CHECK-UBUNTU-12-04-ARM-HF: "{{.*}}ld{{(.exe)?}}" 
"--sysroot=[[SYSROOT:[^"]+]]"
-// CHECK-UBUNTU-12-04-ARM-HF: 
"{{.*}}/usr/lib/gcc/arm-linux-gnueabihf/4.6.3/../../../arm-linux-gnueabihf{{/|}}crt1.o"
-// CHECK-UBUNTU-12-04-ARM-HF: 
"{{.*}}/usr/lib/gcc/arm-linux-gnueabihf/4.6.3/../../../arm-linux-gnueabihf{{/|}}crti.o"
+// CHECK-UBUNTU-12-04-ARM-HF: 
"{{.*}}/usr/lib/arm-linux-gnueabihf{{/|}}crt1.o"
+// CHECK-UBUNTU-12-04-ARM-HF: 
"{{.*}}/usr/lib/arm-linux-gnueabihf{{/|}}crti.o"
 // CHECK-UBUNTU-12-04-ARM-HF: 
"{{.*}}/usr/lib/gcc/arm-linux-gnueabihf/4.6.3{{/|}}crtbegin.o"
 // CHECK-UBUNTU-12-04-ARM-HF: 
"-L[[SYSROOT]]/usr/lib/gcc/arm-linux-gnueabihf/4.6.3"
-// CHECK-UBUNTU-12-04-ARM-HF: 
"-L[[SYSROOT]]/usr/lib/gcc/arm-linux-gnueabihf/4.6.3/../../../arm-linux-gnueabihf"
 // CHECK-UBUNTU-12-04-ARM-HF: "-L[[SYSROOT]]/lib/arm-linux-gnueabihf"
 // CHECK-UBUNTU-12-04-ARM-HF: "-L[[SYSROOT]]/usr/lib/arm-linux-gnueabihf"
 // CHECK-UBUNTU-12-04-ARM-HF: 
"-L[[SYSROOT]]/usr/lib/gcc/arm-linux-gnueabihf/4.6.3/../../.."
 // CHECK-UBUNTU-12-04-ARM-HF: 
"{{.*}}/usr/lib/gcc/arm-linux-gnueabihf/4.6.3{{/|}}crtend.o"
-// CHECK-UBUNTU-12-04-ARM-HF: 
"{{.*}}/usr/lib/gcc/arm-linux-gnueabihf/4.6.3/../../../arm-linux-gnueabihf{{/|}}crtn.o"
+// CHECK-UBUNTU-12-04-ARM-HF: 
"{{.*}}/usr/lib/arm-linux-gnueabihf{{/|}}crtn.o"
 //
 // Check Ubuntu 13.10 on x86-64 targeting arm-linux-gnueabihf.
 // RUN: %clang -no-canonical-prefixes %s -### -o %t.o 2>&1 \
@@ -628,16 +627,15 @@
 // RUN: --sysroot=%S/Inputs/ubuntu_14.04_multiarch_tree \
 // RUN:   | FileCheck --check-prefix=CHECK-UBUNTU-14-04-PPC64LE %s
 // CHECK-UBUNTU-14-04-PPC64LE: "{{.*}}ld{{(.exe)?}}" 
"--sysroot=[[SYSROOT:[^"]+]]"
-// CHECK-UBUNTU-14-04-PPC64LE: 
"{{.*}}/usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../powerpc64le-linux-gnu{{/|}}crt1.o"
-// CHECK-UBUNTU-14-04-PPC64LE: 
"{{.*}}/usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../powerpc64le-linux-gnu{{/|}}crti.o"
+// CHECK-UBUNTU-14-04-PPC64LE: 
"{{.*}}/usr/lib/powerpc64le-linux-gnu{{/|}}crt1.o"
+// CHECK-UBUNTU-14-04-PPC64LE: 
"{{.*}}/usr/lib/powerpc64le-linux-gnu{{/|}}crti.o"
 // CHECK-UBUNTU-14-04-PPC64LE: 
"{{.*}}/usr/lib/gcc/powerpc64le-linux-gnu/4.8{{/|}}crtbegin.o"
 // CHECK-UBUNTU-14-04-PPC64LE: 
"-L[[SYSROOT]]/usr/lib/gcc/powerpc64le-linux-gnu/4.8"
-// CHECK-UBUNTU-14-04-PPC64LE: 
"-L[[SYSROOT]]/usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../powerpc64le-linux-gnu"
 // CHECK-UBUNTU-14-04-PPC64LE: "-L[[SYSROOT]]/lib/powerpc64le-linux-gnu"
 // CHECK-UBUNTU-14-04-PPC64LE: "-L[[SYSROOT]]/usr/lib/powerpc64le-linux-gnu"
 // CHECK-UBUNTU-14-04-PPC64LE: 
"-L[[SYSROOT]]/usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../.."
 // CHECK-UBUNTU-14-04-PPC64LE: 
"{{.*}}/usr/lib/gcc/powerpc64le-linux-gnu/4.8{{/|}}crtend.o"
-// CHECK-UBUNTU-14-04-PPC64LE: 
"{{.*}}/usr/lib/gcc/powerpc64le-linux-gnu/4.8/../../../powerpc64le-linux-gnu{{/|}}crtn.o"
+// CHECK-UBUNTU-14-04-PPC64LE: 
"{{.*}}

[PATCH] D99005: [clang] WIP: Implement P2266

2021-03-20 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov updated this revision to Diff 332140.
mizvekov added a comment.

- Removed special flag, now is enabled on -std=c++2b
- Always enabled for coroutines
- Ran test suite
- Some relevant test files updated to also run c++2b
- Some new tests added


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99005

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaCoroutine.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CXX/class/class.init/class.copy.elision/p3.cpp
  clang/test/CXX/special/class.copy/p33-0x.cpp

Index: clang/test/CXX/special/class.copy/p33-0x.cpp
===
--- clang/test/CXX/special/class.copy/p33-0x.cpp
+++ clang/test/CXX/special/class.copy/p33-0x.cpp
@@ -1,4 +1,6 @@
-// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -std=c++11 -fsyntax-only -verify %s
+// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -std=c++2b -fsyntax-only -verify=expected,cxx2b %s
+// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -std=c++11 -fsyntax-only -verify=expected,cxx11 %s
+// cxx2b-no-diagnostics
 class X {
   X(const X&);
 
@@ -27,7 +29,7 @@
   struct X {
 X();
 X(X&&);
-X(const X&) = delete; // expected-note 2{{'X' has been explicitly marked deleted here}}
+X(const X&) = delete; // cxx11-note 2{{'X' has been explicitly marked deleted here}}
   };
 
   void f(int i) {
@@ -36,7 +38,7 @@
   X x2;
   if (i)
 throw x2; // okay
-  throw x; // expected-error{{call to deleted constructor of 'PR10142::X'}}
+  throw x; // cxx11-error{{call to deleted constructor of 'PR10142::X'}}
 } catch (...) {
 }
   }
@@ -48,10 +50,10 @@
   T x2;
   if (i)
 throw x2; // okay
-  throw x; // expected-error{{call to deleted constructor of 'PR10142::X'}}
+  throw x; // cxx11-error{{call to deleted constructor of 'PR10142::X'}}
 } catch (...) {
 }
   }
 
-  template void f2(int); // expected-note{{in instantiation of function template specialization 'PR10142::f2' requested here}}
+  template void f2(int); // cxx11-note{{in instantiation of function template specialization 'PR10142::f2' requested here}}
 }
Index: clang/test/CXX/class/class.init/class.copy.elision/p3.cpp
===
--- clang/test/CXX/class/class.init/class.copy.elision/p3.cpp
+++ clang/test/CXX/class/class.init/class.copy.elision/p3.cpp
@@ -1,7 +1,8 @@
-// RUN: %clang_cc1 -std=c++20 -fsyntax-only -fcxx-exceptions -verify=expected,cxx20 %s
-// RUN: %clang_cc1 -std=c++17 -fsyntax-only -fcxx-exceptions -verify=expected,cxx11_14_17 %s
-// RUN: %clang_cc1 -std=c++14 -fsyntax-only -fcxx-exceptions -verify=expected,cxx11_14_17 %s
-// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fcxx-exceptions -verify=expected,cxx11_14_17 %s
+// RUN: %clang_cc1 -std=c++2b -fsyntax-only -fcxx-exceptions -verify=expected,cxx20_2b,cxx2b %s
+// RUN: %clang_cc1 -std=c++20 -fsyntax-only -fcxx-exceptions -verify=expected,cxx11_14_17_20,cxx20_2b %s
+// RUN: %clang_cc1 -std=c++17 -fsyntax-only -fcxx-exceptions -verify=expected,cxx11_14_17_20,cxx11_14_17 %s
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -fcxx-exceptions -verify=expected,cxx11_14_17_20,cxx11_14_17 %s
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fcxx-exceptions -verify=expected,cxx11_14_17_20,cxx11_14_17 %s
 
 namespace test_delete_function {
 struct A1 {
@@ -72,20 +73,20 @@
 
 struct B1 {
   B1(const B1 &);
-  B1(B1 &&) = delete; // cxx20-note {{'B1' has been explicitly marked deleted here}}
+  B1(B1 &&) = delete; // cxx20_2b-note {{'B1' has been explicitly marked deleted here}}
 };
 B1 test3(B1 &&b) {
-  return b; // cxx20-error {{call to deleted constructor of 'test_implicitly_movable_rvalue_ref::B1'}}
+  return b; // cxx20_2b-error {{call to deleted constructor of 'test_implicitly_movable_rvalue_ref::B1'}}
 }
 
 struct B2 {
   B2(const B2 &);
 
 private:
-  B2(B2 &&); // cxx20-note {{declared private here}}
+  B2(B2 &&); // cxx20_2b-note {{declared private here}}
 };
 B2 test4(B2 &&b) {
-  return b; // cxx20-error {{calling a private constructor of class 'test_implicitly_movable_rvalue_ref::B2'}}
+  return b; // cxx20_2b-error {{calling a private constructor of class 'test_implicitly_movable_rvalue_ref::B2'}}
 }
 } // namespace test_implicitly_movable_rvalue_ref
 
@@ -96,13 +97,13 @@
 
 struct A1 {
   A1(const A1 &);
-  A1(A1 &&) = delete; // cxx20-note {{'A1' has been explicitly marked deleted here}}
+  A1(A1 &&) = delete; // cxx20_2b-note {{'A1' has been explicitly marked deleted here}}
 };
 void test1() {
   try {
 func();
   } catch (A1 a) {
-throw a; // cxx20-error {{call to deleted constructor of 'test_throw_parameter::A1'}}
+throw a; // cxx20_2b-error {{call to deleted constructor of 'test_throw_parameter::A1'}}
   }
 }
 
@@ -110,13 +111,13 @@
   A2(const A2

[clang] 0ad0c47 - [Driver] Gnu.cpp: remove unneeded -L detection hack for -mx32

2021-03-20 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2021-03-20T20:12:45-07:00
New Revision: 0ad0c476efdbc6b8e933edc32e6f943ed3a33b0d

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

LOG: [Driver] Gnu.cpp: remove unneeded -L detection hack for -mx32

Removing the hack actually improves our compatibility with gcc -mx32.

Added: 


Modified: 
clang/lib/Driver/ToolChains/Gnu.cpp
clang/test/Driver/linux-ld.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index f9df2370266c..bd14bbb63f3a 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2855,11 +2855,6 @@ void Generic_GCC::AddMultiarchPaths(const Driver &D,
   // Try walking via the GCC triple path in case of biarch or multiarch GCC
   // installations with strange symlinks.
   if (GCCInstallation.isValid()) {
-addPathIfExists(D,
-SysRoot + "/usr/lib/" + GCCInstallation.getTriple().str() +
-"/../../" + OSLibDir,
-Paths);
-
 // Add the 'other' biarch variant path
 Multilib BiarchSibling;
 if (GCCInstallation.getBiarchSibling(BiarchSibling)) {

diff  --git a/clang/test/Driver/linux-ld.c b/clang/test/Driver/linux-ld.c
index a07b289540ec..93202da3c083 100644
--- a/clang/test/Driver/linux-ld.c
+++ b/clang/test/Driver/linux-ld.c
@@ -649,12 +649,11 @@
 // CHECK-UBUNTU-14-04-X32: 
"{{.*}}/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../libx32{{/|}}crti.o"
 // CHECK-UBUNTU-14-04-X32: 
"{{.*}}/usr/lib/gcc/x86_64-linux-gnu/4.8/x32{{/|}}crtbegin.o"
 // CHECK-UBUNTU-14-04-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.8/x32"
-// CHECK-UBUNTU-14-04-X32: 
"-L[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../libx32"
-// CHECK-UBUNTU-14-04-X32: "-L[[SYSROOT]]/lib/../libx32"
-// CHECK-UBUNTU-14-04-X32: "-L[[SYSROOT]]/usr/lib/../libx32"
-// CHECK-UBUNTU-14-04-X32: 
"-L[[SYSROOT]]/usr/lib/x86_64-linux-gnu/../../libx32"
-// CHECK-UBUNTU-14-04-X32: "-L[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.8"
-// CHECK-UBUNTU-14-04-X32: 
"-L[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../.."
+// CHECK-UBUNTU-14-04-X32-SAME: {{^}} 
"-L[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../libx32"
+// CHECK-UBUNTU-14-04-X32-SAME: {{^}} "-L[[SYSROOT]]/lib/../libx32"
+// CHECK-UBUNTU-14-04-X32-SAME: {{^}} "-L[[SYSROOT]]/usr/lib/../libx32"
+// CHECK-UBUNTU-14-04-X32-SAME: {{^}} 
"-L[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.8"
+// CHECK-UBUNTU-14-04-X32-SAME: {{^}} 
"-L[[SYSROOT]]/usr/lib/gcc/x86_64-linux-gnu/4.8/../../.."
 // CHECK-UBUNTU-14-04-X32: 
"{{.*}}/usr/lib/gcc/x86_64-linux-gnu/4.8/x32{{/|}}crtend.o"
 // CHECK-UBUNTU-14-04-X32: 
"{{.*}}/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../libx32{{/|}}crtn.o"
 //



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


[clang] 775a294 - [Driver] Gnu.cpp: remove unneeded -L detection for libc++

2021-03-20 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2021-03-20T18:56:40-07:00
New Revision: 775a294820caefdce4e60603eaac0a071dd72765

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

LOG: [Driver] Gnu.cpp: remove unneeded -L detection for libc++

If clang is installed in the system, the other -L suffice;
otherwise $ccc_install_dir/../lib below suffices.

Added: 


Modified: 
clang/lib/Driver/ToolChains/Linux.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Linux.cpp 
b/clang/lib/Driver/ToolChains/Linux.cpp
index ad98013dd4f0..6599f46d0d52 100644
--- a/clang/lib/Driver/ToolChains/Linux.cpp
+++ b/clang/lib/Driver/ToolChains/Linux.cpp
@@ -307,16 +307,6 @@ Linux::Linux(const Driver &D, const llvm::Triple &Triple, 
const ArgList &Args)
 
   Generic_GCC::AddMultilibPaths(D, SysRoot, OSLibDir, MultiarchTriple, Paths);
 
-  // Similar to the logic for GCC above, if we currently running Clang inside
-  // of the requested system root, add its parent library paths to
-  // those searched.
-  // FIXME: It's not clear whether we should use the driver's installed
-  // directory ('Dir' below) or the ResourceDir.
-  if (StringRef(D.Dir).startswith(SysRoot)) {
-addPathIfExists(D, D.Dir + "/../lib/" + MultiarchTriple, Paths);
-addPathIfExists(D, D.Dir + "/../" + OSLibDir, Paths);
-  }
-
   addPathIfExists(D, SysRoot + "/lib/" + MultiarchTriple, Paths);
   addPathIfExists(D, SysRoot + "/lib/../" + OSLibDir, Paths);
 



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


[clang] 56700e9 - [Driver] Gnu.cpp: drop an unneeded special rule related to sysroot

2021-03-20 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2021-03-20T21:32:55-07:00
New Revision: 56700e937903969a4a95f68c59e38e35d1ea

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

LOG: [Driver] Gnu.cpp: drop an unneeded special rule related to sysroot

Seem unnecessary to diverge from GCC here.
Beside, lib/../$OSLibDir can be considered closer to the GCC
installation then the system root. The comment should not apply.

Added: 


Modified: 
clang/lib/Driver/ToolChains/Gnu.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index bd14bbb63f3a..39be77463544 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2834,17 +2834,7 @@ void Generic_GCC::AddMultilibPaths(const Driver &D,
 SelectedMultilib.osSuffix(),
 Paths);
 
-// If the GCC installation we found is inside of the sysroot, we want to
-// prefer libraries installed in the parent prefix of the GCC installation.
-// It is important to *not* use these paths when the GCC installation is
-// outside of the system root as that can pick up unintended libraries.
-// This usually happens when there is an external cross compiler on the
-// host system, and a more minimal sysroot available that is the target of
-// the cross. Note that GCC does include some of these directories in some
-// configurations but this seems somewhere between questionable and simply
-// a bug.
-if (StringRef(LibPath).startswith(SysRoot))
-  addPathIfExists(D, LibPath + "/../" + OSLibDir, Paths);
+addPathIfExists(D, LibPath + "/../" + OSLibDir, Paths);
   }
 }
 



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


[PATCH] D98692: [clang-tidy] Add cppcoreguidelines-comparison-operator

2021-03-20 Thread Yang Fan via Phabricator via cfe-commits
nullptr.cpp updated this revision to Diff 332145.
nullptr.cpp edited the summary of this revision.
nullptr.cpp added a comment.

- Warn on both declarations and definitions
- Add check for parameter passing
- Add options `CheckParamPassing` and `ExpensiveToCopySize`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98692

Files:
  clang-tools-extra/clang-tidy/cppcoreguidelines/CMakeLists.txt
  clang-tools-extra/clang-tidy/cppcoreguidelines/ComparisonOperatorCheck.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/ComparisonOperatorCheck.h
  clang-tools-extra/clang-tidy/cppcoreguidelines/CppCoreGuidelinesTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-comparison-operator.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-comparison-operator-check-param-passing.cpp
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-comparison-operator-expensive-to-copy-size.cpp
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-comparison-operator.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-comparison-operator.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-comparison-operator.cpp
@@ -0,0 +1,194 @@
+// RUN: %check_clang_tidy %s cppcoreguidelines-comparison-operator %t -- --fix-notes
+
+/// member function
+namespace test_member_function {
+struct A {
+  int Var;
+
+  bool operator==(const A &a) const;
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: 'operator==' should not be member function [cppcoreguidelines-comparison-operator]
+
+  bool operator!=(const A &a) const;
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: 'operator!=' should not be member function [cppcoreguidelines-comparison-operator]
+
+  bool operator<(const A &a) const;
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: 'operator<' should not be member function [cppcoreguidelines-comparison-operator]
+
+  bool operator<=(const A &a) const;
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: 'operator<=' should not be member function [cppcoreguidelines-comparison-operator]
+
+  bool operator>(const A &a) const;
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: 'operator>' should not be member function [cppcoreguidelines-comparison-operator]
+
+  bool operator>=(const A &a) const;
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: 'operator>=' should not be member function [cppcoreguidelines-comparison-operator]
+};
+} // namespace test_member_function
+
+/// parameters types differ
+namespace test_params_type_differ {
+struct B;
+bool operator==(const B &lh, int rh) noexcept;
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: 'operator==' should have 2 parameters of the same type [cppcoreguidelines-comparison-operator]
+
+bool operator!=(const B &lh, int rh) noexcept;
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: 'operator!=' should have 2 parameters of the same type [cppcoreguidelines-comparison-operator]
+
+bool operator<(const B &lh, int rh) noexcept;
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: 'operator<' should have 2 parameters of the same type [cppcoreguidelines-comparison-operator]
+
+bool operator<=(const B &lh, int rh) noexcept;
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: 'operator<=' should have 2 parameters of the same type [cppcoreguidelines-comparison-operator]
+
+bool operator>(const B &lh, int rh) noexcept;
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: 'operator>' should have 2 parameters of the same type [cppcoreguidelines-comparison-operator]
+
+bool operator>=(const B &lh, int rh) noexcept;
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: 'operator>=' should have 2 parameters of the same type [cppcoreguidelines-comparison-operator]
+} // namespace test_params_type_differ
+
+/// can throw
+namespace test_can_throw {
+struct C;
+bool operator==(const C &lh, const C &rh);
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: 'operator==' should be marked noexcept [cppcoreguidelines-comparison-operator]
+// CHECK-MESSAGES: :[[@LINE-2]]:6: note: mark 'noexcept'
+// CHECK-FIXES: bool operator==(const C &lh, const C &rh) noexcept
+
+bool operator!=(const C &lh, const C &rh);
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: 'operator!=' should be marked noexcept [cppcoreguidelines-comparison-operator]
+// CHECK-MESSAGES: :[[@LINE-2]]:6: note: mark 'noexcept'
+// CHECK-FIXES: bool operator!=(const C &lh, const C &rh) noexcept;
+
+bool operator<(const C &lh, const C &rh);
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: 'operator<' should be marked noexcept [cppcoreguidelines-comparison-operator]
+// CHECK-MESSAGES: :[[@LINE-2]]:6: note: mark 'noexcept'
+// CHECK-FIXES: bool operator<(const C &lh, const C &rh) noexcept;
+
+bool operator<=(const C &lh, const C &rh);
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: 'operator<

[PATCH] D99005: [clang] WIP: Implement P2266

2021-03-20 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone added a comment.

Conspicuously missing: tests for `decltype(auto)` return types, tests for 
`co_return`.

Personally I'd rather see these new p2266-related tests go in a separate test 
file, not appended to the existing file, so as to keep each test file 
relatively simpler and shorter. (But I don't know that those-in-charge would 
agree.)




Comment at: clang/test/CXX/class/class.init/class.copy.elision/p3.cpp:5
+// RUN: %clang_cc1 -std=c++14 -fsyntax-only -fcxx-exceptions 
-verify=expected,cxx11_14_17_20,cxx11_14_17 %s
+// RUN: %clang_cc1 -std=c++11 -fsyntax-only -fcxx-exceptions 
-verify=expected,cxx11_14_17_20,cxx11_14_17 %s
 

These labels seem to be getting unwieldy. I propose that you rename 
`cxx11_14_17` to `cxx17` and `cxx11_14_17_20` to `cxx17_20`.

(There are no cases where C++11, '14, '17's behavior differ.)

So then we'll have `cxx17`, `cxx17_20`, `cxx20`, `cxx20_2b`, and `cxx2b`.
IMHO it might even be nice to eliminate the overlapping labels; just, when a 
message is expected in two out of three modes, write two expectations.
```
  B1(B1 &&) = delete;
// cxx20-note@-1 {{'B1' has been explicitly marked deleted here}}
// cxx2b-note@-2 {{'B1' has been explicitly marked deleted here}}
```
What do you think? (This could also be severed into its own earlier commit.)



Comment at: clang/test/CXX/class/class.init/class.copy.elision/p3.cpp:325
+  MoveOnly&& rr = test_3a(static_cast(w)); // cxx11_14_17_20-note 
{{in instantiation of function template specialization}}
+}
+

FWIW here I would prefer
```
template MoveOnly& test_3a(MoveOnly&);
template MoveOnly&& test_3a(MoveOnly&&);
```
with an expected error on the second line. The parameter-ness of `w` seems like 
a red herring in your version.



Comment at: clang/test/CXX/class/class.init/class.copy.elision/p3.cpp:335
+  try {
+throw x; // cxx11_14_17_20-error {{call to implicitly-deleted copy 
constructor}}
+  } catch(...) {}

I believe this is incorrect; `throw x` here shouldn't implicit-move because 
`x`'s scope exceeds the nearest enclosing try-block.



Comment at: clang/test/CXX/special/class.copy/p33-0x.cpp:3
+// RUN: %clang_cc1 -fcxx-exceptions -fexceptions -std=c++11 -fsyntax-only 
-verify=expected,cxx11 %s
+// cxx2b-no-diagnostics
 class X {

Could you please ensure that this test is updated to be tested in //all// 
modes? My interpretation of the old line 1 is it's been locked to run only in 
'11 mode (not '14 or '17 or '20), which is just bizarre. There's nothing 
'11-specific about this file that I can see. (And again that change can be 
severed from the rest of this PR and landed earlier, I hope.)



Comment at: clang/test/CXX/special/class.copy/p33-0x.cpp:41
 throw x2; // okay
-  throw x; // expected-error{{call to deleted constructor of 'PR10142::X'}}
+  throw x; // cxx11-error{{call to deleted constructor of 'PR10142::X'}}
 } catch (...) {

I believe this is incorrect; `throw x` here shouldn't implicit-move (not even 
in C++2b) because `x`'s scope exceeds the nearest enclosing try-block.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99005

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


[clang] c2f9086 - [Driver] Gnu.cpp: drop an unneeded special rule related to sysroot

2021-03-20 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2021-03-20T21:37:49-07:00
New Revision: c2f9086b6184a132ec8cac7edeb620813796e1e8

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

LOG: [Driver] Gnu.cpp: drop an unneeded special rule related to sysroot

Added: 


Modified: 
clang/lib/Driver/ToolChains/Gnu.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Gnu.cpp 
b/clang/lib/Driver/ToolChains/Gnu.cpp
index 39be77463544..078579669634 100644
--- a/clang/lib/Driver/ToolChains/Gnu.cpp
+++ b/clang/lib/Driver/ToolChains/Gnu.cpp
@@ -2853,8 +2853,6 @@ void Generic_GCC::AddMultiarchPaths(const Driver &D,
   Paths);
 }
 
-// See comments above on the multilib variant for details of why this is
-// included even from outside the sysroot.
 const std::string &LibPath =
 std::string(GCCInstallation.getParentLibPath());
 const llvm::Triple &GCCTriple = GCCInstallation.getTriple();
@@ -2862,11 +2860,7 @@ void Generic_GCC::AddMultiarchPaths(const Driver &D,
 addPathIfExists(
 D, LibPath + "/../" + GCCTriple.str() + "/lib" + Multilib.osSuffix(),
 Paths);
-
-// See comments above on the multilib variant for details of why this is
-// only included from within the sysroot.
-if (StringRef(LibPath).startswith(SysRoot))
-  addPathIfExists(D, LibPath, Paths);
+addPathIfExists(D, LibPath, Paths);
   }
 }
 



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


[PATCH] D99031: [clang-format] Fix CompactNamespaces corner case when AllowShortLambdasOnASingleLine/BraceWrapping.BeforeLambdaBody are set

2021-03-20 Thread Ahmed Mahdy via Phabricator via cfe-commits
aybassiouny created this revision.
aybassiouny added reviewers: curdeius, Wawha, MyDeveloperDay, 
HazardyKnusperkeks.
aybassiouny added a project: clang-format.
aybassiouny requested review of this revision.
Herald added a project: clang.

**Summary** `CompactNamespaces` config stops work when 
`AllowShortLambdasOnASingleLine` is set to false or 
`BraceWrapping.BeforeLambdaBody` is true

Input:

  namespace out {
  namespace in {
  } 
  } // namespace out::in

Expected output:

  namespace out { namespace in {
  }} // namespace out::in

Output from current binaries:

  namespace out {
  namespace in {
  } 
  } // namespace out::in

Config triggering the issue:

  ---
  AllowShortLambdasOnASingleLine: None
  CompactNamespaces: true
  ...

This config too triggers the same issue:

  ---
  BraceWrapping:
BeforeLambdaBody :true
  BreakBeforeBraces: Custom
  CompactNamespaces: true
  ...

**What's happening:** Seems there's a corner case when 
AllowShortLambdasOnASingleLine is false, or when 
`BraceWrapping.BeforeLambdaBody` is true, that causes CompactNamespaces to stop 
working. The root cause seems to be isAllmanLambdaBrace 
,
 that !!assumes the namespace brace is a lambda and blocks compacting the 
namespace!!. The regression was probably introduced with this commit 
.

I have only added a UT covering the corner cases, please let me know if more 
coverage is needed, I am new to the codebase. One corner case I am aware of, is 
anonymous namespaces, which would not be affected by my 
`Tok.Previous->Previous->is(tok::kw_namespace)` check, but I am not sure what's 
the expected behavior there anyway.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D99031

Files:
  clang/lib/Format/TokenAnnotator.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -2589,6 +2589,33 @@
Style));
 }
 
+TEST_F(FormatTest, FormatsCompactNamespacesLambdaRegression) {
+  FormatStyle Style = getLLVMStyle();
+  Style.CompactNamespaces = true;
+
+  // Make sure compact namespaces are not confused with lambdas
+  auto NoShortLambdaStyle{Style};
+  NoShortLambdaStyle.AllowShortLambdasOnASingleLine = FormatStyle::SLS_None;
+  EXPECT_EQ("namespace out { namespace in {\n"
+"}} // namespace out::in",
+format("namespace out {\n"
+   "namespace in {\n"
+   "} // namespace in\n"
+   "} // namespace out",
+   NoShortLambdaStyle));
+
+  auto BraceWrappingBeforeLambdaBodyStyle{Style};
+  BraceWrappingBeforeLambdaBodyStyle.BreakBeforeBraces = 
FormatStyle::BS_Custom;
+  BraceWrappingBeforeLambdaBodyStyle.BraceWrapping.BeforeLambdaBody = true;
+  EXPECT_EQ("namespace out { namespace in {\n"
+"}} // namespace out::in",
+format("namespace out {\n"
+   "namespace in {\n"
+   "} // namespace in\n"
+   "} // namespace out",
+   BraceWrappingBeforeLambdaBodyStyle));
+}
+
 TEST_F(FormatTest, FormatsExternC) {
   verifyFormat("extern \"C\" {\nint a;");
   verifyFormat("extern \"C\" {}");
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -3494,7 +3494,8 @@
 }
 static bool isAllmanLambdaBrace(const FormatToken &Tok) {
   return (Tok.is(tok::l_brace) && Tok.is(BK_Block) &&
-  !Tok.isOneOf(TT_ObjCBlockLBrace, TT_DictLiteral));
+  !Tok.isOneOf(TT_ObjCBlockLBrace, TT_DictLiteral) &&
+  !Tok.Previous->Previous->is(tok::kw_namespace));
 }
 
 static bool isAllmanBraceIncludedBreakableLambda(


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -2589,6 +2589,33 @@
Style));
 }
 
+TEST_F(FormatTest, FormatsCompactNamespacesLambdaRegression) {
+  FormatStyle Style = getLLVMStyle();
+  Style.CompactNamespaces = true;
+
+  // Make sure compact namespaces are not confused with lambdas
+  auto NoShortLambdaStyle{Style};
+  NoShortLambdaStyle.AllowShortLambdasOnASingleLine = FormatStyle::SLS_None;
+  EXPECT_EQ("namespace out { namespace in {\n"
+"}} // namespace out::in",
+format("namespace out {\n"
+   "namespace in {\n"
+   "} // namespace in\n"
+   "} // namespace out",
+   NoShortLambdaStyle));
+
+  auto BraceWrappingBeforeLambdaBodyStyle{St

[PATCH] D97183: [analyzer] Add NoteTag for smart-ptr get()

2021-03-20 Thread Deep Majumder via Phabricator via cfe-commits
RedDocMD updated this revision to Diff 332147.
RedDocMD added a comment.

Fixed up the git history


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97183

Files:
  clang/lib/StaticAnalyzer/Checkers/SmartPtrChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
  clang/test/Analysis/smart-ptr-text-output.cpp


Index: clang/test/Analysis/smart-ptr-text-output.cpp
===
--- clang/test/Analysis/smart-ptr-text-output.cpp
+++ clang/test/Analysis/smart-ptr-text-output.cpp
@@ -306,10 +306,44 @@
 };
 
 void derefAfterBranchingOnUnknownInnerPtr(std::unique_ptr P) {
-  A *RP = P.get();
+  A *RP = P.get(); // expected-note {{Obtained null inner pointer from 'P'}}
   if (!RP) { // expected-note {{Assuming 'RP' is null}}
 // expected-note@-1 {{Taking true branch}}
 P->foo(); // expected-warning {{Dereference of null smart pointer 'P' 
[alpha.cplusplus.SmartPtr]}}
 // expected-note@-1{{Dereference of null smart pointer 'P'}}
   }
 }
+
+void getShouldNotAlwaysLeaveANote() {
+   std::unique_ptr P; // expected-note {{Default constructed smart 
pointer 'P' is null}}
+   A *a = P.get(); 
+   P->foo(); // expected-warning {{Dereference of null smart pointer 'P' 
[alpha.cplusplus.SmartPtr]}}
+// expected-note@-1{{Dereference of null smart pointer 'P'}}
+}
+
+void getShouldNotLeaveNoteWhenPtrNotUsed(std::unique_ptr P) {
+  A *a = P.get(); 
+  if (!P) { // expected-note {{Taking true branch}}
+// expected-note@-1 {{Assuming smart pointer 'P' is null}}
+P->foo(); // expected-warning {{Dereference of null smart pointer 'P' 
[alpha.cplusplus.SmartPtr]}}
+// expected-note@-1{{Dereference of null smart pointer 'P'}}
+  }
+}
+
+void getShouldLeaveANoteWithWhileLoop(std::unique_ptr P) {
+  A *RP = P.get(); // expected-note {{Obtained null inner pointer from 'P'}}
+  while (!RP) {// expected-note {{Assuming 'RP' is null}}
+// expected-note@-1 {{Loop condition is true.  Entering loop body}}
+P->foo(); // expected-warning {{Dereference of null smart pointer 'P' 
[alpha.cplusplus.SmartPtr]}}
+// expected-note@-1{{Dereference of null smart pointer 'P'}}
+  }
+}
+
+void getShouldLeaveANoteWithForLoop(std::unique_ptr P) {
+  for (A *RP = P.get(); !RP;) { // expected-note {{Assuming 'RP' is null}}
+// expected-note@-1 {{Loop condition is true.  Entering loop body}}
+// expected-note@-2 {{Obtained null inner pointer from 'P'}}
+P->foo(); // expected-warning {{Dereference of null smart pointer 'P' 
[alpha.cplusplus.SmartPtr]}}
+// expected-note@-1{{Dereference of null smart pointer 'P'}}
+  }
+}
\ No newline at end of file
Index: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
+++ clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
@@ -457,8 +457,22 @@
 
   State = State->BindExpr(Call.getOriginExpr(), C.getLocationContext(),
   InnerPointerVal);
-  // TODO: Add NoteTag, for how the raw pointer got using 'get' method.
-  C.addTransition(State);
+
+  C.addTransition(State, C.getNoteTag([ThisRegion, InnerPointerVal,
+   State](PathSensitiveBugReport &BR,
+  llvm::raw_ostream &OS) {
+if (&BR.getBugType() != smartptr::getNullDereferenceBugType() ||
+!BR.isInteresting(ThisRegion))
+  return;
+if (!BR.isInteresting(InnerPointerVal) || 
!BR.isInteresting(InnerPointerVal.getAsSymbol()))
+  return;
+if (ThisRegion->canPrintPretty()) {
+  OS << "Obtained null inner pointer from";
+  checkAndPrettyPrintRegion(OS, ThisRegion);
+} else {
+  OS << "Obtained null inner pointer here";
+}
+  }));
 }
 
 bool SmartPtrModeling::handleAssignOp(const CallEvent &Call,
Index: clang/lib/StaticAnalyzer/Checkers/SmartPtrChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/SmartPtrChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/SmartPtrChecker.cpp
@@ -87,6 +87,8 @@
   auto R = std::make_unique(NullDereferenceBugType,
 OS.str(), ErrNode);
   R->markInteresting(DerefRegion);
+  const Expr *BugExpr = Call.getOriginExpr();
+  bugreporter::trackExpressionValue(ErrNode, BugExpr, *R);
   C.emitReport(std::move(R));
 }
 


Index: clang/test/Analysis/smart-ptr-text-output.cpp
===
--- clang/test/Analysis/smart-ptr-text-output.cpp
+++ clang/test/Analysis/smart-ptr-text-output.cpp
@@ -306,10 +306,44 @@
 };
 
 void derefAfterBranchingOnUnknownInnerPtr(std::unique_ptr P) {
-  A *RP = P.get();
+  A *RP = P.get(); // expected-note {{Obtained null inner pointer from 'P'}}
   if (!RP) { // expected-no

[PATCH] D97183: [analyzer] Add NoteTag for smart-ptr get()

2021-03-20 Thread Deep Majumder via Phabricator via cfe-commits
RedDocMD marked an inline comment as done.
RedDocMD added inline comments.



Comment at: clang/test/Analysis/smart-ptr-text-output.cpp:317
 
 void getShouldNotAlwaysLeaveANote() {
std::unique_ptr P; // expected-note {{Default constructed smart 
pointer 'P' is null}}

NoQ wrote:
> Looks like your git history is acting up. Your patch adds this test right? 
> Are there more proposed changes in the cpp files that aren't currently 
> highlighted for a similar reason?
> 
> I'll try to play with your patch locally once this is fixed ^.^
Yeah I seem to have tripped over the single commit rule. It should be fixed now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97183

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