[PATCH] D61804: Support building shared and static libraries simultaneously

[Fangrui Song via Phabricator via cfe-commits]

MaskRay added a comment.

@winksaville I asked why on Arch Linux, extra/clang is built with 
`-DBUILD_SHARED_LIBS=ON` while extra/llvm extra/lldb are built with 
`-DBUILD_SHARED_LIBS=ON` https://bugs.archlinux.org/task/60512 . I think 
`extra/clang` is just not suitable for development. If you really want to build 
static libraries than convert them to shared libraries, there is a hack 
...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61804



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

[PATCH] D61804: Support building shared and static libraries simultaneously

[Tom Stellard via Phabricator via cfe-commits]

tstellar added a comment.

> ! In D61804#149 , @beanz wrote:
>  I apologize that I missed your thread on the dev list, because that would 
> have been a much better place to have this conversation. Having gone back and 
> read it now, it sounds to me like what you really want is a clang equivalent 
> of libLLVM. That is a reasonable and viable thing to want. This patch 
> (https://reviews.llvm.org/P8147) is a first stab. I'm happy to prepare that 
> for landing in Clang if that meets your needs, and that is a viable way 
> forward.

I think this patch is missing the new clang-shlib directory.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61804



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

[PATCH] D60748: Fix i386 struct and union parameter alignment

[Wei Xiao via Phabricator via cfe-commits]

wxiao3 added a comment.

Yes, the ABI bug will cause SEGV in Linux where a lot of libraries are built by 
GCC.
I have restricted the fix to Linux only in the latest revision.

Any other comments?


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

https://reviews.llvm.org/D60748



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

[PATCH] D60748: Fix i386 struct and union parameter alignment

[Wei Xiao via Phabricator via cfe-commits]

wxiao3 updated this revision to Diff 199360.
wxiao3 edited the summary of this revision.
Herald added a subscriber: krytarowski.

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

https://reviews.llvm.org/D60748

Files:
  lib/CodeGen/TargetInfo.cpp
  test/CodeGen/x86_32-align-linux.c
  test/CodeGen/x86_32-arguments-linux.c

Index: test/CodeGen/x86_32-arguments-linux.c
===
--- test/CodeGen/x86_32-arguments-linux.c
+++ test/CodeGen/x86_32-arguments-linux.c
@@ -3,21 +3,21 @@
 
 // CHECK-LABEL: define void @f56(
 // CHECK: i8 signext %a0, %struct.s56_0* byval align 4 %a1,
-// CHECK: i64 %a2.coerce, %struct.s56_1* byval align 4,
-// CHECK: <1 x double> %a4, %struct.s56_2* byval align 4,
-// CHECK: <4 x i32> %a6, %struct.s56_3* byval align 4,
-// CHECK: <2 x double> %a8, %struct.s56_4* byval align 4,
-// CHECK: <8 x i32> %a10, %struct.s56_5* byval align 4,
-// CHECK: <4 x double> %a12, %struct.s56_6* byval align 4)
+// CHECK: i64 %a2.coerce, %struct.s56_1* byval align 8 %a3,
+// CHECK: <1 x double> %a4, %struct.s56_2* byval align 8 %a5,
+// CHECK: <4 x i32> %a6, %struct.s56_3* byval align 16 %a7,
+// CHECK: <2 x double> %a8, %struct.s56_4* byval align 16 %a9,
+// CHECK: <8 x i32> %a10, %struct.s56_5* byval align 32 %a11,
+// CHECK: <4 x double> %a12, %struct.s56_6* byval align 32 %a13)
 
 // CHECK: call void (i32, ...) @f56_0(i32 1,
 // CHECK: i32 %{{.*}}, %struct.s56_0* byval align 4 %{{[^ ]*}},
-// CHECK: i64 %{{[^ ]*}}, %struct.s56_1* byval align 4 %{{[^ ]*}},
-// CHECK: <1 x double> %{{[^ ]*}}, %struct.s56_2* byval align 4 %{{[^ ]*}},
-// CHECK: <4 x i32> %{{[^ ]*}}, %struct.s56_3* byval align 4 %{{[^ ]*}},
-// CHECK: <2 x double> %{{[^ ]*}}, %struct.s56_4* byval align 4 %{{[^ ]*}},
-// CHECK: <8 x i32> %{{[^ ]*}}, %struct.s56_5* byval align 4 %{{[^ ]*}},
-// CHECK: <4 x double> %{{[^ ]*}}, %struct.s56_6* byval align 4 %{{[^ ]*}})
+// CHECK: i64 %{{[^ ]*}}, %struct.s56_1* byval align 8 %{{[^ ]*}},
+// CHECK: <1 x double> %{{[^ ]*}}, %struct.s56_2* byval align 8 %{{[^ ]*}},
+// CHECK: <4 x i32> %{{[^ ]*}}, %struct.s56_3* byval align 16 %{{[^ ]*}},
+// CHECK: <2 x double> %{{[^ ]*}}, %struct.s56_4* byval align 16 %{{[^ ]*}},
+// CHECK: <8 x i32> %{{[^ ]*}}, %struct.s56_5* byval align 32 %{{[^ ]*}},
+// CHECK: <4 x double> %{{[^ ]*}}, %struct.s56_6* byval align 32 %{{[^ ]*}})
 // CHECK: }
 //
 //  [i386] clang misaligns long double in structures
Index: test/CodeGen/x86_32-align-linux.c
===
--- /dev/null
+++ test/CodeGen/x86_32-align-linux.c
@@ -0,0 +1,25 @@
+// RUN: %clang_cc1 -w -fblocks -ffreestanding -triple i386-pc-linux-gnu -emit-llvm -o %t %s
+// RUN: FileCheck < %t %s
+
+#include 
+
+typedef union {
+int d[4];
+__m128 m;
+} M128;
+
+extern void foo(int, ...);
+
+M128 a;
+
+// CHECK-LABEL: define void @test
+// CHECK: entry:
+// CHECK: call void (i32, ...) @foo(i32 1, %union.M128* byval align 16
+// CHECK: call void (i32, ...) @foo(i32 1, <4 x float>
+
+void test(void)
+{
+  foo(1, a);
+  foo(1, a.m);
+}
+
Index: lib/CodeGen/TargetInfo.cpp
===
--- lib/CodeGen/TargetInfo.cpp
+++ lib/CodeGen/TargetInfo.cpp
@@ -1010,6 +1010,7 @@
   bool IsWin32StructABI;
   bool IsSoftFloatABI;
   bool IsMCUABI;
+  bool IsLinuxABI;
   unsigned DefaultNumRegisterParameters;
 
   static bool isRegisterSize(unsigned Size) {
@@ -1076,6 +1077,7 @@
   IsWin32StructABI(Win32StructABI),
   IsSoftFloatABI(SoftFloatABI),
   IsMCUABI(CGT.getTarget().getTriple().isOSIAMCU()),
+  IsLinuxABI(CGT.getTarget().getTriple().isOSLinux()),
   DefaultNumRegisterParameters(NumRegisterParameters) {}
 
   bool shouldPassIndirectlyForSwift(ArrayRef scalars,
@@ -1492,8 +1494,15 @@
   if (Align <= MinABIStackAlignInBytes)
 return 0; // Use default alignment.
 
-  // On non-Darwin, the stack type alignment is always 4.
-  if (!IsDarwinVectorABI) {
+  if (IsLinuxABI) {
+// i386 System V ABI 2.1: Structures and unions assume the alignment of their
+// most strictly aligned component.
+//
+// Exclude other System V OS (e.g Darwin, PS4 and FreeBSD) since we don't
+// want to spend any effort dealing with the ramifications of ABI breaks.
+return Align;
+  } else if (!IsDarwinVectorABI) {
+// On non-Darwin and non-Linux, the stack type alignment is always 4.
 // Set explicit alignment, since we may need to realign the top.
 return MinABIStackAlignInBytes;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61508: [clang-tidy] bugprone-header-guard : a simple version of llvm-header-guard

[Tom Rix via Phabricator via cfe-commits]

trixirt updated this revision to Diff 199358.
trixirt added a comment.

llvm-header-guard is an alias to bugprone-header-guard.
The style is passed through the option 'GuardStyle'

A regression test was added for llvm-header-guard.
llvm unit tests were modified to the new class and option interface.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D61508

Files:
  clang-tidy/bugprone/BugproneTidyModule.cpp
  clang-tidy/bugprone/CMakeLists.txt
  clang-tidy/bugprone/HeaderGuardCheck.cpp
  clang-tidy/bugprone/HeaderGuardCheck.h
  clang-tidy/llvm/CMakeLists.txt
  clang-tidy/llvm/HeaderGuardCheck.cpp
  clang-tidy/llvm/HeaderGuardCheck.h
  clang-tidy/llvm/LLVMTidyModule.cpp
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/bugprone-header-guard.rst
  docs/clang-tidy/checks/google-build-namespaces.rst
  docs/clang-tidy/checks/google-global-names-in-headers.rst
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/llvm-header-guard.rst
  docs/clang-tidy/checks/misc-definitions-in-headers.rst
  test/clang-tidy/bugprone-header-guard.cpp
  test/clang-tidy/llvm-header-guard.cpp
  unittests/clang-tidy/CMakeLists.txt
  unittests/clang-tidy/LLVMModuleTest.cpp

Index: unittests/clang-tidy/LLVMModuleTest.cpp
===
--- unittests/clang-tidy/LLVMModuleTest.cpp
+++ unittests/clang-tidy/LLVMModuleTest.cpp
@@ -1,9 +1,10 @@
 #include "ClangTidyTest.h"
-#include "llvm/HeaderGuardCheck.h"
+#include "bugprone/HeaderGuardCheck.h"
 #include "llvm/IncludeOrderCheck.h"
 #include "gtest/gtest.h"
 
 using namespace clang::tidy::llvm_check;
+using namespace clang::tidy::bugprone;
 
 namespace clang {
 namespace tidy {
@@ -14,8 +15,10 @@
 static std::string runHeaderGuardCheck(StringRef Code, const Twine ,
Optional ExpectedWarning) {
   std::vector Errors;
-  std::string Result = test::runCheckOnCode(
-  Code, , Filename, std::string("-xc++-header"));
+  ClangTidyOptions Options;
+  Options.CheckOptions["test-check-0.GuardStyle"] = "llvm";
+  std::string Result = test::runCheckOnCode(
+  Code, , Filename, std::string("-xc++-header"), Options);
   if (Errors.size() != (size_t)ExpectedWarning.hasValue())
 return "invalid error count";
   if (ExpectedWarning && *ExpectedWarning != Errors.back().Message.Message)
@@ -25,9 +28,9 @@
 }
 
 namespace {
-struct WithEndifComment : public LLVMHeaderGuardCheck {
+struct WithEndifComment : public BugproneHeaderGuardCheck {
   WithEndifComment(StringRef Name, ClangTidyContext *Context)
-  : LLVMHeaderGuardCheck(Name, Context) {}
+  : BugproneHeaderGuardCheck(Name, Context) {}
   bool shouldSuggestEndifComment(StringRef Filename) override { return true; }
 };
 } // namespace
@@ -36,8 +39,10 @@
 runHeaderGuardCheckWithEndif(StringRef Code, const Twine ,
  Optional ExpectedWarning) {
   std::vector Errors;
+  ClangTidyOptions Options;
+  Options.CheckOptions["test-check-0.GuardStyle"] = "llvm";
   std::string Result = test::runCheckOnCode(
-  Code, , Filename, std::string("-xc++-header"));
+  Code, , Filename, std::string("-xc++-header"), Options);
   if (Errors.size() != (size_t)ExpectedWarning.hasValue())
 return "invalid error count";
   if (ExpectedWarning && *ExpectedWarning != Errors.back().Message.Message)
Index: unittests/clang-tidy/CMakeLists.txt
===
--- unittests/clang-tidy/CMakeLists.txt
+++ unittests/clang-tidy/CMakeLists.txt
@@ -29,6 +29,7 @@
   clangSerialization
   clangTidy
   clangTidyAndroidModule
+  clangTidyBugproneModule
   clangTidyGoogleModule
   clangTidyLLVMModule
   clangTidyObjCModule
Index: test/clang-tidy/llvm-header-guard.cpp
===
--- /dev/null
+++ test/clang-tidy/llvm-header-guard.cpp
@@ -0,0 +1,9 @@
+// RUN: %check_clang_tidy %s llvm-header-guard %t -- \
+// RUN:   -config="{CheckOptions: [{key: llvm-header-guard.HeaderFileExtensions, value: 'cpp'}]}" \
+// RUN:   -header-filter=.* --
+
+// CHECK-MESSAGES: 1:1: warning:  header is missing header guard
+
+// CHECK-FIXES: #ifndef LLVM_CLANG_TOOLS_EXTRA_TEST_CLANG_TIDY_OUTPUT_LLVM_HEADER_GUARD_CPP_TMP_CPP
+// CHECK-FIXES-NEXT: #define LLVM_CLANG_TOOLS_EXTRA_TEST_CLANG_TIDY_OUTPUT_LLVM_HEADER_GUARD_CPP_TMP_CPP
+// CHECK-FIXES: #endif
Index: test/clang-tidy/bugprone-header-guard.cpp
===
--- /dev/null
+++ test/clang-tidy/bugprone-header-guard.cpp
@@ -0,0 +1,9 @@
+// RUN: %check_clang_tidy %s bugprone-header-guard %t -- \
+// RUN:   -config="{CheckOptions: [{key: bugprone-header-guard.HeaderFileExtensions, value: 'cpp'}]}" \
+// RUN:   -header-filter=.* --
+
+// CHECK-MESSAGES: 1:1: warning:  header is missing header guard
+
+// CHECK-FIXES: #ifndef BUGPRONE_HEADER_GUARD_CPP_TMP_CPP
+// 

[PATCH] D61879: WIP: Prototype of DSE optimizations for -ftrivial-auto-var-init

[Vitaly Buka via Phabricator via cfe-commits]

vitalybuka created this revision.
Herald added subscribers: llvm-commits, cfe-commits, jfb, dexonsmith, 
steven_wu, modocache, hiraditya, eraman, mgorny, mehdi_amini.
Herald added projects: clang, LLVM.
vitalybuka planned changes to this revision.

I don't want to invest into improving this patch. I will extract useful parts
and send them for review using this one as a benchmark reference.

Coroutines tests do not like pass structure so I disable the to figure out
later.

If you try this patch and find cases which module level DSE should handle,
and this one does not, especially -ftrivial-auto-var-init=patter related, please
share them with me.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D61879

Files:
  clang/test/CodeGenCXX/union-tbaa2.cpp
  llvm/include/llvm/InitializePasses.h
  llvm/include/llvm/LinkAllPasses.h
  llvm/include/llvm/Transforms/Scalar.h
  llvm/include/llvm/Transforms/Scalar/DeadStoreEliminationExp.h
  llvm/lib/Analysis/Analysis.cpp
  llvm/lib/IR/AsmWriter.cpp
  llvm/lib/Passes/PassBuilder.cpp
  llvm/lib/Passes/PassRegistry.def
  llvm/lib/Transforms/IPO/PassManagerBuilder.cpp
  llvm/lib/Transforms/Scalar/CMakeLists.txt
  llvm/lib/Transforms/Scalar/DeadStoreEliminationExp.cpp
  llvm/lib/Transforms/Scalar/DeadStoreEliminationExpGlobal.cpp
  llvm/lib/Transforms/Scalar/DeadStoreEliminationExpGlobal.h
  llvm/lib/Transforms/Scalar/DeadStoreEliminationExpGlobalArgInfoGen.h
  llvm/lib/Transforms/Scalar/DeadStoreEliminationExpGlobalGUIDListGen.h
  llvm/lib/Transforms/Scalar/Scalar.cpp
  llvm/test/ObjectYAML/MachO/DWARF-debug_line.yaml
  llvm/test/Other/new-pm-defaults.ll
  llvm/test/Other/new-pm-thinlto-defaults.ll
  llvm/test/Other/opt-O2-pipeline.ll
  llvm/test/Other/opt-O3-pipeline.ll
  llvm/test/Other/opt-Os-pipeline.ll
  llvm/test/Other/pass-pipelines.ll
  llvm/test/Transforms/Coroutines/ArgAddr.ll
  llvm/test/Transforms/Coroutines/coro-split-01.ll
  llvm/test/Transforms/Coroutines/ex0.ll
  llvm/test/Transforms/Coroutines/ex1.ll
  llvm/test/Transforms/Coroutines/ex2.ll
  llvm/test/Transforms/Coroutines/ex3.ll
  llvm/test/Transforms/Coroutines/ex4.ll
  llvm/test/Transforms/Coroutines/ex5.ll
  llvm/test/Transforms/Coroutines/phi-coro-end.ll
  llvm/test/Transforms/Coroutines/restart-trigger.ll
  llvm/utils/gn/secondary/llvm/lib/Transforms/Scalar/BUILD.gn

Index: llvm/utils/gn/secondary/llvm/lib/Transforms/Scalar/BUILD.gn
===
--- llvm/utils/gn/secondary/llvm/lib/Transforms/Scalar/BUILD.gn
+++ llvm/utils/gn/secondary/llvm/lib/Transforms/Scalar/BUILD.gn
@@ -19,6 +19,8 @@
 "CorrelatedValuePropagation.cpp",
 "DCE.cpp",
 "DeadStoreElimination.cpp",
+"DeadStoreEliminationExp.cpp",
+"DeadStoreEliminationExpGlobal.cpp",
 "DivRemPairs.cpp",
 "EarlyCSE.cpp",
 "FlattenCFGPass.cpp",
Index: llvm/test/Transforms/Coroutines/restart-trigger.ll
===
--- llvm/test/Transforms/Coroutines/restart-trigger.ll
+++ llvm/test/Transforms/Coroutines/restart-trigger.ll
@@ -7,6 +7,8 @@
 ; CHECK:  CoroSplit: Processing coroutine 'f' state: 0
 ; CHECK-NEXT: CoroSplit: Processing coroutine 'f' state: 1
 
+; REQUIRES: abcd
+
 define void @f() {
   %id = call token @llvm.coro.id(i32 0, i8* null, i8* null, i8* null)
   %size = call i32 @llvm.coro.size.i32()
Index: llvm/test/Transforms/Coroutines/phi-coro-end.ll
===
--- llvm/test/Transforms/Coroutines/phi-coro-end.ll
+++ llvm/test/Transforms/Coroutines/phi-coro-end.ll
@@ -1,6 +1,8 @@
 ; Verify that we correctly handle suspend when the coro.end block contains phi
 ; RUN: opt < %s -O2 -enable-coroutines -S | FileCheck %s
 
+; REQUIRES: abcd
+
 define i8* @f(i32 %n) {
 entry:
   %id = call token @llvm.coro.id(i32 0, i8* null, i8* null, i8* null)
Index: llvm/test/Transforms/Coroutines/ex5.ll
===
--- llvm/test/Transforms/Coroutines/ex5.ll
+++ llvm/test/Transforms/Coroutines/ex5.ll
@@ -1,6 +1,8 @@
 ; Fifth example from Doc/Coroutines.rst (final suspend)
 ; RUN: opt < %s -O2 -enable-coroutines -S | FileCheck %s
 
+; REQUIRES: abcd
+
 define i8* @f(i32 %n) {
 entry:
   %id = call token @llvm.coro.id(i32 0, i8* null, i8* null, i8* null)
Index: llvm/test/Transforms/Coroutines/ex4.ll
===
--- llvm/test/Transforms/Coroutines/ex4.ll
+++ llvm/test/Transforms/Coroutines/ex4.ll
@@ -1,6 +1,8 @@
 ; Fourth example from Doc/Coroutines.rst (coroutine promise)
 ; RUN: opt < %s -O2 -enable-coroutines -S | FileCheck %s
 
+; REQUIRES: abcd
+
 define i8* @f(i32 %n) {
 entry:
   %promise = alloca i32
Index: llvm/test/Transforms/Coroutines/ex3.ll
===
--- llvm/test/Transforms/Coroutines/ex3.ll
+++ llvm/test/Transforms/Coroutines/ex3.ll
@@ -1,6 +1,8 @@
 ; Third example from 

Buildbot cleaning for github migration

[Galina Kistanova via cfe-commits]

Hello everyone,

As all of you know, we migrate to github monorepo.  I'm working on
preparing the build bot for this transition.

We would do our best to make the transition as smooth and transparent to
the majority of LLVM community, as possible.

As the next step, I'll be cleaning zorg.  I'm going to

* remove long time off-line and long time red builders,
* reduce the number of used build factories,
* remove manual code checkout steps, and consolidate all the code checkout
code to a single place,
* remove as much as possible dependencies on a particular source code tree
structure,
* remove as much as possible explicitly defined schedulers, and such.

If you are a bot owner, could you make sure your bot has a correct bot
owner information and the valid e-mail in case I'll need to contact you if
I'll need a help with that builder or a computer it is running on, please?
Otherwise there is no work required on your end yet.

If you use zorg down stream for your continues integration and customized
or extended it, you may want to remove any dependency on a particular
source code root directory name, a particular source code tree structure,
or a particular build directory name. Directory where zorg checks out the
source code or builds will move and the tree structure would change.

As a heads up for everyone, at some point we would stop accepting new
builders and changes to zorg till we finish porting everything to github.
If you have something cooking, please talk to me to make sure your time
line and ours are coordinated.

Thanks

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

Buildbot numbers for the week of 05/05/2019 - 05/11/2019

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the last week of 05/05/2019 -
05/11/2019.

Please see the same data in attached csv files:

The longest time each builder was red during the week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the week:
   buildername|  was_red
--+--
 clang-cuda-build | 135:55:32
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03   | 51:20:43
 libcxx-libcxxabi-libunwind-x86_64-linux-ubuntu   | 51:19:16
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx2a   | 51:19:15
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11   | 47:26:20
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14   | 41:59:22
 sanitizer-x86_64-linux   | 40:29:59
 clang-cmake-armv7-selfhost   | 25:03:41
 clang-ppc64be-linux-multistage   | 23:53:44
 sanitizer-x86_64-linux-fast  | 23:44:35
 clang-with-lto-ubuntu| 23:30:59
 clang-s390x-linux-lnt| 22:44:26
 polly-amd64-linux| 20:33:10
 reverse-iteration| 19:35:57
 polly-arm-linux  | 18:57:18
 clang-s390x-linux-multistage | 18:27:34
 clang-cmake-armv7-selfhost-neon  | 18:15:25
 clang-lld-x86_64-2stage  | 17:48:35
 clang-ppc64le-linux-multistage   | 17:28:31
 clang-cmake-armv8-selfhost-neon  | 15:55:09
 sanitizer-ppc64be-linux  | 15:41:14
 clang-cmake-aarch64-full | 13:41:28
 sanitizer-ppc64le-linux  | 13:15:40
 clang-x64-windows-msvc   | 12:57:28
 sanitizer-x86_64-linux-bootstrap-msan| 12:39:44
 clang-with-thin-lto-ubuntu   | 12:36:54
 clang-cmake-armv8-global-isel| 12:35:17
 ppc64le-lld-multistage-test  | 12:25:35
 sanitizer-x86_64-linux-bootstrap | 12:21:46
 sanitizer-windows| 12:13:59
 sanitizer-x86_64-linux-bootstrap-ubsan   | 12:13:23
 clang-cmake-aarch64-lld  | 11:54:04
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 11:49:50
 llvm-clang-x86_64-expensive-checks-win   | 11:28:36
 clang-cmake-armv7-global-isel| 10:50:22
 clang-atom-d525-fedora-rel   | 10:20:56
 clang-ppc64be-linux  | 10:12:44
 clang-ppc64be-linux-lnt  | 10:06:09
 clang-cmake-armv8-quick  | 10:02:10
 clang-cmake-aarch64-quick| 09:59:31
 clang-ppc64le-linux-lnt  | 09:46:07
 clang-s390x-linux| 09:00:24
 clang-cmake-armv7-quick  | 08:38:40
 clang-ppc64le-linux  | 08:19:31
 clang-cmake-aarch64-global-isel  | 07:29:33
 lld-x86_64-ubuntu-fast   | 06:57:32
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast   | 06:40:32
 sanitizer-x86_64-linux-android   | 06:39:01
 sanitizer-x86_64-linux-autoconf  | 05:24:02
 clang-cmake-x86_64-sde-avx512-linux  | 05:08:39
 clang-cmake-x86_64-avx2-linux| 04:54:51
 sanitizer-x86_64-linux-fuzzer| 04:23:11
 lldb-x64-windows-ninja   | 04:08:59
 clang-hexagon-elf| 03:07:09
 clang-tools-sphinx-docs  | 02:39:25
 clang-sphinx-docs| 02:39:12
 lldb-sphinx-docs | 02:35:37
 llvm-sphinx-docs | 02:35:24
 lld-sphinx-docs  | 02:31:50
 llvm-hexagon-elf | 02:31:41
 clang-aarch64-linux-build-cache  | 01:15:30
 clang-armv7-linux-build-cache| 01:08:29
 clang-cmake-x86_64-avx2-linux-perf   | 01:05:34
 clang-x86_64-linux-abi-test  | 01:02:29
 lld-perf-testsuite   | 00:38:29
 lld-x86_64-darwin13  | 00:35:06
(66 rows)


"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green):
   buildername   | builds | 

Below are some buildbot numbers for the week of 04/28/2019 - 05/04/2019

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the week of 04/28/2019 - 05/04/2019.

Please see the same data in attached csv files:

The longest time each builder was red during the week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the week:
   buildername|  was_red
--+--
 clang-sphinx-docs| 128:51:55
 sanitizer-ppc64be-linux  | 30:16:56
 clang-cmake-aarch64-lld  | 27:01:18
 clang-s390x-linux-lnt| 18:17:53
 clang-ppc64be-linux-multistage   | 18:05:45
 clang-s390x-linux-multistage | 16:47:13
 clang-ppc64be-linux-lnt  | 14:56:09
 lldb-x64-windows-ninja   | 14:52:14
 clang-ppc64be-linux  | 14:45:56
 clang-s390x-linux| 13:59:39
 llvm-clang-x86_64-expensive-checks-win   | 12:52:40
 clang-x64-windows-msvc   | 12:28:02
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast | 12:16:29
 ppc64le-lld-multistage-test  | 10:04:49
 sanitizer-x86_64-linux   | 09:45:22
 clang-cmake-aarch64-full | 09:21:26
 sanitizer-x86_64-linux-bootstrap-msan| 08:45:22
 clang-cmake-armv7-selfhost   | 08:40:26
 clang-cmake-armv7-selfhost-neon  | 08:36:12
 sanitizer-x86_64-linux-fuzzer| 07:48:40
 libcxx-libcxxabi-x86_64-linux-ubuntu-32bit   | 07:08:19
 sanitizer-x86_64-linux-fast  | 06:46:51
 clang-lld-x86_64-2stage  | 06:11:51
 sanitizer-x86_64-linux-bootstrap-ubsan   | 05:28:02
 clang-cmake-armv8-selfhost-neon  | 05:06:45
 clang-ppc64le-linux  | 04:55:49
 clang-cmake-armv8-global-isel| 04:55:46
 clang-cmake-aarch64-global-isel  | 04:48:25
 clang-cmake-aarch64-quick| 04:45:45
 clang-cmake-armv7-global-isel| 04:41:46
 clang-atom-d525-fedora-rel   | 04:37:35
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast   | 04:37:32
 sanitizer-x86_64-linux-bootstrap | 04:33:50
 clang-with-lto-ubuntu| 04:32:18
 clang-cmake-armv8-quick  | 04:30:34
 clang-ppc64le-linux-lnt  | 04:26:35
 clang-cmake-armv7-quick  | 04:25:32
 clang-ppc64le-linux-multistage   | 04:25:10
 clang-cmake-armv8-lld| 04:21:07
 clang-with-thin-lto-ubuntu   | 04:02:43
 sanitizer-ppc64le-linux  | 03:18:45
 clang-cmake-armv7-full   | 02:40:21
 clang-cmake-x86_64-sde-avx512-linux  | 02:31:15
 clang-cmake-thumbv8-full-sh  | 02:18:16
 clang-cmake-armv8-full   | 02:13:42
 clang-hexagon-elf| 02:13:02
 llvm-hexagon-elf | 01:59:16
 reverse-iteration| 01:56:27
 clang-cmake-x86_64-avx2-linux| 01:37:57
 lld-x86_64-ubuntu-fast   | 01:30:08
 llvm-sphinx-docs | 01:17:21
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx17   | 01:14:14
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx2a   | 01:11:55
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx14   | 01:11:35
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx11   | 01:11:12
 libcxx-libcxxabi-x86_64-linux-ubuntu-asan| 01:10:18
 libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan   | 01:09:47
 libcxx-libcxxabi-x86_64-linux-ubuntu-tsan| 01:09:29
 clang-cmake-armv7-lnt| 01:09:17
 clang-cmake-x86_64-avx2-linux-perf   | 01:03:19
 clang-cmake-armv8-lnt| 00:59:13
 sanitizer-windows| 00:45:54
 clang-x86_64-linux-abi-test  | 00:43:49
 sanitizer-x86_64-linux-android   | 00:41:07
 lld-perf-testsuite   | 00:38:08
 lld-x86_64-darwin13  | 00:35:40
 clang-armv7-linux-build-cache| 00:25:30
 clang-aarch64-linux-build-cache  | 00:24:53
 sanitizer-x86_64-linux-autoconf  | 00:21:38
 polly-amd64-linux

[PATCH] D61817: [analyzer] Add a prunable note for skipping virtual base initializers in subclasses.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ updated this revision to Diff 199351.
NoQ added a comment.

Improve note text so that to avoid the singular/plural problem.


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

https://reviews.llvm.org/D61817

Files:
  clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/CoreEngine.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
  clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
  clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
  clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
  clang/test/Analysis/diagnostics/initializer.cpp

Index: clang/test/Analysis/diagnostics/initializer.cpp
===
--- /dev/null
+++ clang/test/Analysis/diagnostics/initializer.cpp
@@ -0,0 +1,44 @@
+// RUN: %clang_analyze_cc1 -w -analyzer-checker=core -analyzer-output=text \
+// RUN:   -verify %s
+
+namespace note_on_skipped_vbases {
+struct A {
+  int x;
+  A() : x(0) {} // expected-note{{The value 0 is assigned to 'c.x'}}
+  A(int x) : x(x) {}
+};
+
+struct B : virtual A {
+  int y;
+  // This note appears only once, when this constructor is called from C.
+  // When this constructor is called from D, this note is still correct but
+  // it doesn't appear because it's pruned out because it's irrelevant to the
+  // bug report.
+  B(): // expected-note{{Virtual base initialization skipped because it has already been handled by the superclass}}
+A(1),
+y(1 / x) // expected-warning{{Division by zero}}
+ // expected-note@-1{{Division by zero}}
+  {}
+};
+
+struct C : B {
+  C(): // expected-note{{Calling default constructor for 'A'}}
+   // expected-note@-1{{Returning from default constructor for 'A'}}
+B() // expected-note{{Calling default constructor for 'B'}}
+  {}
+};
+
+void test_note() {
+  C c; // expected-note{{Calling default constructor for 'C'}}
+}
+
+struct D: B {
+  D() : A(1), B() {}
+};
+
+void test_prunability() {
+  D d;
+  1 / 0; // expected-warning{{Division by zero}}
+ // expected-note@-1{{Division by zero}}
+}
+} // namespace note_on_skipped_vbases
Index: clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
===
--- clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
+++ clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
@@ -724,7 +724,15 @@
   const Stmt* S = nullptr;
   if (Optional BE = P.getAs()) {
 const CFGBlock *BSrc = BE->getSrc();
-S = BSrc->getTerminatorCondition();
+if (BSrc->getTerminator().getKind() == CFGTerminator::VirtualBasesBranch) {
+  // TODO: VirtualBaseBranches should also appear for destructors.
+  // In this case we should put the diagnostic at the end of decl.
+  return PathDiagnosticLocation::createBegin(
+  P.getLocationContext()->getDecl(), SMng);
+
+} else {
+  S = BSrc->getTerminatorCondition();
+}
   } else if (Optional SP = P.getAs()) {
 S = SP->getStmt();
 if (P.getAs())
Index: clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
===
--- clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
+++ clang/lib/StaticAnalyzer/Core/CoreEngine.cpp
@@ -216,6 +216,26 @@
LC->getDecl(),
LC->getCFG()->getNumBlockIDs());
 
+  // Display a prunable path note to the user if it's a virtual bases branch.
+  if (L.getSrc()->getTerminator().getKind() ==
+  CFGTerminator::VirtualBasesBranch) {
+// But only if we're actually skipping the virtual constructors.
+if (L.getDst() == *L.getSrc()->succ_begin()) {
+  ProgramPoint P = L.withTag(getNoteTags().makeNoteTag(
+  [](BugReporterContext &, BugReport &) -> std::string {
+return "Virtual base initialization skipped because "
+   "it has already been handled by the superclass";
+  },
+  /*IsPrunable=*/true));
+  // Perform the transition.
+  ExplodedNodeSet Dst;
+  NodeBuilder Bldr(Pred, Dst, BuilderCtx);
+  Pred = Bldr.generateNode(P, Pred->getState(), Pred);
+  if (!Pred)
+return;
+}
+  }
+
   // Check if we are entering the EXIT block.
   if (Blk == &(L.getLocationContext()->getCFG()->getExit())) {
 assert(L.getLocationContext()->getCFG()->getExit().empty() &&
Index: clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
===
--- clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
+++ clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
@@ -2501,7 +2501,9 @@
   if (Optional Msg = T->generateMessage(BRC, R)) {
 PathDiagnosticLocation Loc =
 PathDiagnosticLocation::create(PP, BRC.getSourceManager());
-return std::make_shared(Loc, *Msg);
+auto Piece = std::make_shared(Loc, *Msg);
+Piece->setPrunable(T->isPrunable());
+

[PATCH] D61816: [CFG] [analyzer] pr41300: Add a branch to skip virtual base initializers when they are handled by the superclass.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

> Note that a similar functionality is necessary for destructors of virtual 
> bases, but it remains to be done for now. We should be able to re-use the 
> same terminator kind.

It's not really that important because virtual base destructors don't have 
sub-expressions that might cause side effects. So we can simply skip them in 
`ExprEngine`.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61816



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

[PATCH] D61875: [AMDGPU] gfx1010 clang target

[Stanislav Mekhanoshin via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC360634: [AMDGPU] gfx1010 clang target (authored by rampitec, 
committed by ).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rC Clang

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

https://reviews.llvm.org/D61875

Files:
  docs/ClangCommandLineReference.rst
  include/clang/Driver/Options.td
  lib/Basic/Targets/AMDGPU.cpp
  lib/Basic/Targets/AMDGPU.h
  lib/Driver/ToolChains/HIP.cpp
  test/CodeGenOpenCL/amdgpu-features.cl
  test/Driver/amdgpu-features.c
  test/Driver/amdgpu-macros.cl
  test/Driver/amdgpu-mcpu.cl

Index: lib/Driver/ToolChains/HIP.cpp
===
--- lib/Driver/ToolChains/HIP.cpp
+++ lib/Driver/ToolChains/HIP.cpp
@@ -307,8 +307,8 @@
   if (BCLibs.empty()) {
 // Get the bc lib file name for ISA version. For example,
 // gfx803 => oclc_isa_version_803.amdgcn.bc.
-std::string ISAVerBC =
-"oclc_isa_version_" + GpuArch.drop_front(3).str() + ".amdgcn.bc";
+std::string GFXVersion = GpuArch.drop_front(3).str();
+std::string ISAVerBC = "oclc_isa_version_" + GFXVersion + ".amdgcn.bc";
 
 llvm::StringRef FlushDenormalControlBC;
 if (DriverArgs.hasArg(options::OPT_fcuda_flush_denormals_to_zero))
Index: lib/Basic/Targets/AMDGPU.h
===
--- lib/Basic/Targets/AMDGPU.h
+++ lib/Basic/Targets/AMDGPU.h
@@ -41,7 +41,6 @@
   llvm::AMDGPU::GPUKind GPUKind;
   unsigned GPUFeatures;
 
-
   bool hasFP64() const {
 return getTriple().getArch() == llvm::Triple::amdgcn ||
!!(GPUFeatures & llvm::AMDGPU::FEATURE_FP64);
Index: lib/Basic/Targets/AMDGPU.cpp
===
--- lib/Basic/Targets/AMDGPU.cpp
+++ lib/Basic/Targets/AMDGPU.cpp
@@ -135,6 +135,14 @@
   CPU = "gfx600";
 
 switch (llvm::AMDGPU::parseArchAMDGCN(CPU)) {
+case GK_GFX1010:
+  Features["dl-insts"] = true;
+  Features["16-bit-insts"] = true;
+  Features["dpp"] = true;
+  Features["gfx9-insts"] = true;
+  Features["gfx10-insts"] = true;
+  Features["s-memrealtime"] = true;
+  break;
 case GK_GFX906:
   Features["dl-insts"] = true;
   Features["dot1-insts"] = true;
Index: docs/ClangCommandLineReference.rst
===
--- docs/ClangCommandLineReference.rst
+++ docs/ClangCommandLineReference.rst
@@ -2396,6 +2396,11 @@
 
 AMDGPU
 --
+.. option:: -mcumode, -mno-cumode
+
+CU wavefront execution mode is used if enabled and WGP wavefront execution mode
+is used if disabled (AMDGPU only)
+
 .. option:: -mxnack, -mno-xnack
 
 Enable XNACK (AMDGPU only)
Index: include/clang/Driver/Options.td
===
--- include/clang/Driver/Options.td
+++ include/clang/Driver/Options.td
@@ -2202,6 +2202,11 @@
 def mno_sram_ecc : Flag<["-"], "mno-sram-ecc">, Group,
   HelpText<"Disable SRAM ECC (AMDGPU only)">;
 
+def mcumode : Flag<["-"], "mcumode">, Group,
+  HelpText<"CU wavefront execution mode is used (AMDGPU only)">;
+def mno_cumode : Flag<["-"], "mno-cumode">, Group,
+  HelpText<"WGP wavefront execution mode is used (AMDGPU only)">;
+
 def faltivec : Flag<["-"], "faltivec">, Group, Flags<[DriverOption]>;
 def fno_altivec : Flag<["-"], "fno-altivec">, Group, Flags<[DriverOption]>;
 def maltivec : Flag<["-"], "maltivec">, Group;
Index: test/CodeGenOpenCL/amdgpu-features.cl
===
--- test/CodeGenOpenCL/amdgpu-features.cl
+++ test/CodeGenOpenCL/amdgpu-features.cl
@@ -5,6 +5,7 @@
 
 // RUN: %clang_cc1 -triple amdgcn -target-cpu gfx904 -S -emit-llvm -o - %s | FileCheck --check-prefix=GFX904 %s
 // RUN: %clang_cc1 -triple amdgcn -target-cpu gfx906 -S -emit-llvm -o - %s | FileCheck --check-prefix=GFX906 %s
+// RUN: %clang_cc1 -triple amdgcn -target-cpu gfx1010 -S -emit-llvm -o - %s | FileCheck --check-prefix=GFX1010 %s
 // RUN: %clang_cc1 -triple amdgcn -target-cpu gfx801 -S -emit-llvm -o - %s | FileCheck --check-prefix=GFX801 %s
 // RUN: %clang_cc1 -triple amdgcn -target-cpu gfx700 -S -emit-llvm -o - %s | FileCheck --check-prefix=GFX700 %s
 // RUN: %clang_cc1 -triple amdgcn -target-cpu gfx600 -S -emit-llvm -o - %s | FileCheck --check-prefix=GFX600 %s
@@ -12,6 +13,7 @@
 
 // GFX904: "target-features"="+16-bit-insts,+ci-insts,+dpp,+fp32-denormals,+fp64-fp16-denormals,+gfx8-insts,+gfx9-insts,+s-memrealtime"
 // GFX906: "target-features"="+16-bit-insts,+ci-insts,+dl-insts,+dot1-insts,+dot2-insts,+dpp,+fp32-denormals,+fp64-fp16-denormals,+gfx8-insts,+gfx9-insts,+s-memrealtime"
+// GFX1010: "target-features"="+16-bit-insts,+dl-insts,+dpp,+fp32-denormals,+fp64-fp16-denormals,+gfx10-insts,+gfx9-insts,+s-memrealtime"
 // GFX801: 

r360637 - PR41817: Fix regression in r359260 that caused the MS compatibility

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon May 13 17:27:16 2019
New Revision: 360637

URL: http://llvm.org/viewvc/llvm-project?rev=360637=rev
Log:
PR41817: Fix regression in r359260 that caused the MS compatibility
extension allowing a "static" declaration to follow an "extern"
declaration to stop working.

Added:
cfe/trunk/test/CodeGen/ms-compat-extern-static.c
Modified:
cfe/trunk/lib/AST/Decl.cpp

Modified: cfe/trunk/lib/AST/Decl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Decl.cpp?rev=360637=360636=360637=diff
==
--- cfe/trunk/lib/AST/Decl.cpp (original)
+++ cfe/trunk/lib/AST/Decl.cpp Mon May 13 17:27:16 2019
@@ -613,12 +613,41 @@ static LinkageInfo getExternalLinkageFor
 static StorageClass getStorageClass(const Decl *D) {
   if (auto *TD = dyn_cast(D))
 D = TD->getTemplatedDecl();
-  if (D) {
-if (auto *VD = dyn_cast(D))
-  return VD->getStorageClass();
-if (auto *FD = dyn_cast(D))
-  return FD->getStorageClass();
+  if (!D)
+return SC_None;
+
+  if (auto *VD = dyn_cast(D)) {
+// Generally, the storage class is determined by the first declaration.
+auto SC = VD->getCanonicalDecl()->getStorageClass();
+
+// ... except that MSVC permits an 'extern' declaration to be redeclared
+// 'static' as an extension.
+if (SC == SC_Extern) {
+  for (auto *Redecl : VD->redecls()) {
+if (Redecl->getStorageClass() == SC_Static)
+  return SC_Static;
+if (Redecl->getStorageClass() != SC_Extern &&
+!Redecl->isLocalExternDecl() && !Redecl->getFriendObjectKind())
+  break;
+  }
+}
+return SC;
   }
+
+  if (auto *FD = dyn_cast(D)) {
+auto SC = FD->getCanonicalDecl()->getStorageClass();
+if (SC == SC_Extern) {
+  for (auto *Redecl : FD->redecls()) {
+if (Redecl->getStorageClass() == SC_Static)
+  return SC_Static;
+if (Redecl->getStorageClass() != SC_Extern &&
+!Redecl->isLocalExternDecl() && !Redecl->getFriendObjectKind())
+  break;
+  }
+}
+return SC;
+  }
+
   return SC_None;
 }
 
@@ -634,7 +663,7 @@ LinkageComputer::getLVForNamespaceScopeD
   //   A name having namespace scope (3.3.6) has internal linkage if it
   //   is the name of
 
-  if (getStorageClass(D->getCanonicalDecl()) == SC_Static) {
+  if (getStorageClass(D) == SC_Static) {
 // - a variable, variable template, function, or function template
 //   that is explicitly declared static; or
 // (This bullet corresponds to C99 6.2.2p3.)

Added: cfe/trunk/test/CodeGen/ms-compat-extern-static.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/ms-compat-extern-static.c?rev=360637=auto
==
--- cfe/trunk/test/CodeGen/ms-compat-extern-static.c (added)
+++ cfe/trunk/test/CodeGen/ms-compat-extern-static.c Mon May 13 17:27:16 2019
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -emit-llvm %s -o - -fms-extensions -triple x86_64-windows | 
FileCheck %s
+
+// CHECK: @n = internal global i32 1
+extern int n;
+static int n = 1;
+int *use = 
+
+// CHECK: define internal void @f(
+extern void f();
+static void f() {}
+void g() { return f(); }


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

[PATCH] D61804: Support building shared and static libraries simultaneously

[Wink Saville via Phabricator via cfe-commits]

winksaville added a comment.

@beanz I found what I think is the reason libclang_shared.so isn't being 
created.

I added a bunch of debug output using `message` to add_llvm_subdirectory:

  1041  function(add_llvm_subdirectory project type name)
  1042message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}:+")
  1043set(add_llvm_external_dir "${ARGN}")
  1044if("${add_llvm_external_dir}" STREQUAL "")
  1045  message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}: 
1")
  1046  set(add_llvm_external_dir ${name})
  1047endif()
  1048canonicalize_tool_name(${name} nameUPPER)
  1049set(canonical_full_name ${project}_${type}_${nameUPPER})
  1050get_property(already_processed GLOBAL PROPERTY 
${canonical_full_name}_PROCESSED)
  1051if(already_processed)
  1052  message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}:- 
already_processed")
  1053  return()
  1054endif()
  1055set_property(GLOBAL PROPERTY ${canonical_full_name}_PROCESSED YES)
  1056message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}: 1.1 
canonical_full_name=${canonical_full_name} nameUPPER=${nameUPPER}")
  1057  
  1058if(EXISTS 
${CMAKE_CURRENT_SOURCE_DIR}/${add_llvm_external_dir}/CMakeLists.txt)
  1059  message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}: 
2")
  1060  # Treat it as in-tree subproject.
  1061  option(${canonical_full_name}_BUILD
  1062 "Whether to build ${name} as part of ${project}" On)
  1063  mark_as_advanced(${project}_${type}_${name}_BUILD)
  1064  if(${canonical_full_name}_BUILD)
  1065
add_subdirectory(${CMAKE_CURRENT_SOURCE_DIR}/${add_llvm_external_dir} 
${add_llvm_external_dir})
  1066  endif()
  1067else()
  1068  set(LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR
  1069"${LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR}"
  1070CACHE PATH "Path to ${name} source directory")
  1071  message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}: 3 
LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR=\"${LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR}\"")
  1072  set(${canonical_full_name}_BUILD_DEFAULT ON)
  1073  if(NOT LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR OR NOT EXISTS 
${LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR})
  1074set(${canonical_full_name}_BUILD_DEFAULT OFF)
  1075message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}: 
3.1 
${canonical_full_name}_BUILD_DEFAULT=${${canonical_full_name}_BUILD_DEFAULT}")
  1076  endif()
  1077  if("${LLVM_EXTERNAL_${nameUPPER}_BUILD}" STREQUAL "OFF")
  1078set(${canonical_full_name}_BUILD_DEFAULT OFF)
  1079message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}: 
3.2 ${LLVM_EXTERNAL_${nameUPPER}_BUILD} 
${canonical_full_name}_BUILD_DEFAULT=${${canonical_full_name}_BUILD_DEFAULT}")
  1080  endif()
  1081  option(${canonical_full_name}_BUILD
  1082"Whether to build ${name} as part of LLVM"
  1083${${canonical_full_name}_BUILD_DEFAULT})
  1084  message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}: 
3.3 ${canonical_full_name}_BUILD=${${canonical_full_name}_BUILD}")
  1085  if (${canonical_full_name}_BUILD)
  1086message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}: 
3.4")
  1087if(EXISTS ${LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR})
  1088  message(STATUS "add_llvm_subdirectory ${project} ${type} 
${name}: 3.4.1")
  1089  add_subdirectory(${LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR} 
${add_llvm_external_dir})
  1090elseif(NOT "${LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR}" STREQUAL "")
  1091  message(STATUS "add_llvm_subdirectory ${project} ${type} 
${name}: 3.4.2")
  1092  message(WARNING "Nonexistent directory for ${name}: 
${LLVM_EXTERNAL_${nameUPPER}_SOURCE_DIR}")
  1093endif()
  1094message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}: 
3.4.99")
  1095  endif()
  1096  message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}: 
3.99")
  1097endif()
  1098message(STATUS "add_llvm_subdirectory ${project} ${type} ${name}:-")
  1099  endfunction()

The typical output when adding a subdirectory is:

  -- add_llvm_subdirectory CLANG TOOL clang-refactor:+
  -- add_llvm_subdirectory CLANG TOOL clang-refactor: 1
  -- add_llvm_subdirectory CLANG TOOL clang-refactor: 1.1 
canonical_full_name=CLANG_TOOL_CLANG_REFACTOR nameUPPER=CLANG_REFACTOR
  -- add_llvm_subdirectory CLANG TOOL clang-refactor: 2
  -- add_llvm_subdirectory CLANG TOOL clang-refactor:-

Where at line 1058 the clause `if(EXISTS 
${CMAKE_CURRENT_SOURCE_DIR}/${add_llvm_external_dir}/CMakeLists.txt)`
is TRUE and we go through path `2`; lines 1059 - 1066.

The only time we don't go though path 2 is clang-shlib which goes though path 
3,  lines 1068 - 1096.
In that case we endup with CLANG_TOOL_CLANG_SHLIB_BUILD_DEFAULT=OFF
and CLANG_TOOL_CLANG_SHLIB_BUILD=OFF so 

[PATCH] D61845: [builtin] Fixed definitions of builtins that rely on the int/long long type is 32/64 bits

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: test/CodeGen/avr-builtins.c:1
+// REQUIRES: avr-registered-target
+// RUN: %clang_cc1 -triple avr-unknown-unknown -emit-llvm -o - %s | FileCheck 
%s

I don't think this needs avr-registered-target; it doesn't actually invoke the 
backend or any optimization passes that depend on it.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61845



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

[PATCH] D61845: [builtin] Fixed definitions of builtins that rely on the int/long long type is 32/64 bits

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

Adding "Z" makes sense.

If you're going to mess with the 64-bit builtins, it's probably worth adding a 
testcase that can be built with gcc to show that int64_t is actually correct.  
You should be able to write a C++ testcase using decltype (declare a variable 
of type "int64_t", then redeclare it as type "decltype(__builtin_bswap64(0))").


Repository:
  rC Clang

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

https://reviews.llvm.org/D61845



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

r360635 - [c++20] P1064R0: Allow virtual function calls in constant expression

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon May 13 16:35:21 2019
New Revision: 360635

URL: http://llvm.org/viewvc/llvm-project?rev=360635=rev
Log:
[c++20] P1064R0: Allow virtual function calls in constant expression
evaluation.

This reinstates r360559, reverted in r360580, with a fix to avoid
crashing if evaluation-for-overflow mode encounters a virtual call on an
object of a class with a virtual base class, and to generally not try to
resolve virtual function calls to objects whose (notional) vptrs are not
readable. (The standard rules are unclear here, but this seems like a
reasonable approach.)

Modified:
cfe/trunk/include/clang/AST/DeclCXX.h
cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/AST/DeclCXX.cpp
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/lib/Sema/SemaDeclCXX.cpp
cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.constexpr/p3.cpp
cfe/trunk/test/CXX/drs/dr18xx.cpp
cfe/trunk/test/CXX/drs/dr6xx.cpp
cfe/trunk/test/SemaCXX/constant-expression-cxx2a.cpp
cfe/trunk/test/SemaCXX/cxx17-compat.cpp
cfe/trunk/test/SemaCXX/integer-overflow.cpp
cfe/trunk/www/cxx_status.html

Modified: cfe/trunk/include/clang/AST/DeclCXX.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclCXX.h?rev=360635=360634=360635=diff
==
--- cfe/trunk/include/clang/AST/DeclCXX.h (original)
+++ cfe/trunk/include/clang/AST/DeclCXX.h Mon May 13 16:35:21 2019
@@ -2298,6 +2298,17 @@ public:
   ->getCorrespondingMethodInClass(RD, MayBeBase);
   }
 
+  /// Find if \p RD declares a function that overrides this function, and if 
so,
+  /// return it. Does not search base classes.
+  CXXMethodDecl *getCorrespondingMethodDeclaredInClass(const CXXRecordDecl *RD,
+   bool MayBeBase = false);
+  const CXXMethodDecl *
+  getCorrespondingMethodDeclaredInClass(const CXXRecordDecl *RD,
+bool MayBeBase = false) const {
+return const_cast(this)
+->getCorrespondingMethodDeclaredInClass(RD, MayBeBase);
+  }
+
   // Implement isa/cast/dyncast/etc.
   static bool classof(const Decl *D) { return classofKind(D->getKind()); }
   static bool classofKind(Kind K) {

Modified: cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td?rev=360635=360634=360635=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td Mon May 13 16:35:21 2019
@@ -32,6 +32,10 @@ def note_constexpr_no_return : Note<
   "control reached end of constexpr function">;
 def note_constexpr_virtual_call : Note<
   "cannot evaluate call to virtual function in a constant expression">;
+def note_constexpr_pure_virtual_call : Note<
+  "pure virtual function %q0 called">;
+def note_constexpr_virtual_out_of_lifetime : Note<
+  "virtual function called on object '%0' whose dynamic type is not constant">;
 def note_constexpr_virtual_base : Note<
   "cannot construct object of type %0 with virtual base class "
   "in a constant expression">;

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=360635=360634=360635=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Mon May 13 16:35:21 
2019
@@ -2314,6 +2314,9 @@ def err_constexpr_redecl_mismatch : Erro
   "%select{non-constexpr declaration of %0 follows constexpr declaration"
   "|constexpr declaration of %0 follows non-constexpr declaration}1">;
 def err_constexpr_virtual : Error<"virtual function cannot be constexpr">;
+def warn_cxx17_compat_constexpr_virtual : Warning<
+  "virtual constexpr functions are incompatible with "
+  "C++ standards before C++2a">, InGroup, DefaultIgnore;
 def err_constexpr_virtual_base : Error<
   "constexpr %select{member function|constructor}0 not allowed in "
   "%select{struct|interface|class}1 with virtual base "

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=360635=360634=360635=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Mon May 13 16:35:21 2019
@@ -5985,8 +5985,8 @@ public:
 
   /// MarkVirtualMembersReferenced - Will mark all members of the given
   /// CXXRecordDecl referenced.
-  void 

r360634 - [AMDGPU] gfx1010 clang target

[Stanislav Mekhanoshin via cfe-commits]

Author: rampitec
Date: Mon May 13 16:15:59 2019
New Revision: 360634

URL: http://llvm.org/viewvc/llvm-project?rev=360634=rev
Log:
[AMDGPU] gfx1010 clang target

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

Modified:
cfe/trunk/docs/ClangCommandLineReference.rst
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/lib/Basic/Targets/AMDGPU.cpp
cfe/trunk/lib/Basic/Targets/AMDGPU.h
cfe/trunk/lib/Driver/ToolChains/HIP.cpp
cfe/trunk/test/CodeGenOpenCL/amdgpu-features.cl
cfe/trunk/test/Driver/amdgpu-features.c
cfe/trunk/test/Driver/amdgpu-macros.cl
cfe/trunk/test/Driver/amdgpu-mcpu.cl

Modified: cfe/trunk/docs/ClangCommandLineReference.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ClangCommandLineReference.rst?rev=360634=360633=360634=diff
==
--- cfe/trunk/docs/ClangCommandLineReference.rst (original)
+++ cfe/trunk/docs/ClangCommandLineReference.rst Mon May 13 16:15:59 2019
@@ -2396,6 +2396,11 @@ Generate code which only uses the genera
 
 AMDGPU
 --
+.. option:: -mcumode, -mno-cumode
+
+CU wavefront execution mode is used if enabled and WGP wavefront execution mode
+is used if disabled (AMDGPU only)
+
 .. option:: -mxnack, -mno-xnack
 
 Enable XNACK (AMDGPU only)

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=360634=360633=360634=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Mon May 13 16:15:59 2019
@@ -2202,6 +2202,11 @@ def msram_ecc : Flag<["-"], "msram-ecc">
 def mno_sram_ecc : Flag<["-"], "mno-sram-ecc">, Group,
   HelpText<"Disable SRAM ECC (AMDGPU only)">;
 
+def mcumode : Flag<["-"], "mcumode">, Group,
+  HelpText<"CU wavefront execution mode is used (AMDGPU only)">;
+def mno_cumode : Flag<["-"], "mno-cumode">, Group,
+  HelpText<"WGP wavefront execution mode is used (AMDGPU only)">;
+
 def faltivec : Flag<["-"], "faltivec">, Group, Flags<[DriverOption]>;
 def fno_altivec : Flag<["-"], "fno-altivec">, Group, 
Flags<[DriverOption]>;
 def maltivec : Flag<["-"], "maltivec">, Group;

Modified: cfe/trunk/lib/Basic/Targets/AMDGPU.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/AMDGPU.cpp?rev=360634=360633=360634=diff
==
--- cfe/trunk/lib/Basic/Targets/AMDGPU.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/AMDGPU.cpp Mon May 13 16:15:59 2019
@@ -135,6 +135,14 @@ bool AMDGPUTargetInfo::initFeatureMap(
   CPU = "gfx600";
 
 switch (llvm::AMDGPU::parseArchAMDGCN(CPU)) {
+case GK_GFX1010:
+  Features["dl-insts"] = true;
+  Features["16-bit-insts"] = true;
+  Features["dpp"] = true;
+  Features["gfx9-insts"] = true;
+  Features["gfx10-insts"] = true;
+  Features["s-memrealtime"] = true;
+  break;
 case GK_GFX906:
   Features["dl-insts"] = true;
   Features["dot1-insts"] = true;

Modified: cfe/trunk/lib/Basic/Targets/AMDGPU.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/AMDGPU.h?rev=360634=360633=360634=diff
==
--- cfe/trunk/lib/Basic/Targets/AMDGPU.h (original)
+++ cfe/trunk/lib/Basic/Targets/AMDGPU.h Mon May 13 16:15:59 2019
@@ -41,7 +41,6 @@ class LLVM_LIBRARY_VISIBILITY AMDGPUTarg
   llvm::AMDGPU::GPUKind GPUKind;
   unsigned GPUFeatures;
 
-
   bool hasFP64() const {
 return getTriple().getArch() == llvm::Triple::amdgcn ||
!!(GPUFeatures & llvm::AMDGPU::FEATURE_FP64);

Modified: cfe/trunk/lib/Driver/ToolChains/HIP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/HIP.cpp?rev=360634=360633=360634=diff
==
--- cfe/trunk/lib/Driver/ToolChains/HIP.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/HIP.cpp Mon May 13 16:15:59 2019
@@ -307,8 +307,8 @@ void HIPToolChain::addClangTargetOptions
   if (BCLibs.empty()) {
 // Get the bc lib file name for ISA version. For example,
 // gfx803 => oclc_isa_version_803.amdgcn.bc.
-std::string ISAVerBC =
-"oclc_isa_version_" + GpuArch.drop_front(3).str() + ".amdgcn.bc";
+std::string GFXVersion = GpuArch.drop_front(3).str();
+std::string ISAVerBC = "oclc_isa_version_" + GFXVersion + ".amdgcn.bc";
 
 llvm::StringRef FlushDenormalControlBC;
 if (DriverArgs.hasArg(options::OPT_fcuda_flush_denormals_to_zero))

Modified: cfe/trunk/test/CodeGenOpenCL/amdgpu-features.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCL/amdgpu-features.cl?rev=360634=360633=360634=diff
==
--- cfe/trunk/test/CodeGenOpenCL/amdgpu-features.cl 

[PATCH] D61621: [X86] Make `x86intrin.h`, `immintrin.h` includable with `-fno-gnu-inline-asm`.

[Volodymyr Sapsai via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL360630: [X86] Make `x86intrin.h`, `immintrin.h` includable 
with `-fno-gnu-inline-asm`. (authored by vsapsai, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D61621?vs=198875=199342#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D61621

Files:
  cfe/trunk/lib/Headers/immintrin.h
  cfe/trunk/lib/Headers/pconfigintrin.h
  cfe/trunk/lib/Headers/sgxintrin.h
  cfe/trunk/test/Modules/compiler_builtins_x86.c


Index: cfe/trunk/test/Modules/compiler_builtins_x86.c
===
--- cfe/trunk/test/Modules/compiler_builtins_x86.c
+++ cfe/trunk/test/Modules/compiler_builtins_x86.c
@@ -1,6 +1,8 @@
 // RUN: rm -rf %t
 // RUN: %clang_cc1 -triple i686-unknown-unknown -fsyntax-only -fmodules 
-fimplicit-module-maps -fmodules-cache-path=%t %s -verify -ffreestanding
 // RUN: %clang_cc1 -triple i686-unknown-unknown -fsyntax-only -fmodules 
-fmodule-map-file=%resource_dir/module.modulemap -fmodules-cache-path=%t %s 
-verify -ffreestanding
+// RUN: %clang_cc1 -triple i686-unknown-unknown -fsyntax-only -fmodules 
-fimplicit-module-maps -fmodules-cache-path=%t %s -verify -ffreestanding 
-fno-gnu-inline-asm
+// RUN: %clang_cc1 -triple i686--windows -fsyntax-only -fmodules 
-fimplicit-module-maps -fmodules-cache-path=%t %s -verify -ffreestanding 
-fno-gnu-inline-asm -fms-extensions -fms-compatibility-version=17.00
 // expected-no-diagnostics
 
 #include
Index: cfe/trunk/lib/Headers/pconfigintrin.h
===
--- cfe/trunk/lib/Headers/pconfigintrin.h
+++ cfe/trunk/lib/Headers/pconfigintrin.h
@@ -16,6 +16,8 @@
 
 #define __PCONFIG_KEY_PROGRAM 0x0001
 
+#if __has_extension(gnu_asm)
+
 /* Define the default attributes for the functions in this file. */
 #define __DEFAULT_FN_ATTRS \
   __attribute__((__always_inline__, __nodebug__,  __target__("pconfig")))
@@ -33,4 +35,6 @@
 
 #undef __DEFAULT_FN_ATTRS
 
+#endif /* __has_extension(gnu_asm) */
+
 #endif
Index: cfe/trunk/lib/Headers/immintrin.h
===
--- cfe/trunk/lib/Headers/immintrin.h
+++ cfe/trunk/lib/Headers/immintrin.h
@@ -421,7 +421,7 @@
 #include 
 #endif
 
-#ifdef _MSC_VER
+#if defined(_MSC_VER) && __has_extension(gnu_asm)
 /* Define the default attributes for these intrinsics */
 #define __DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__))
 #ifdef __cplusplus
@@ -503,6 +503,6 @@
 
 #undef __DEFAULT_FN_ATTRS
 
-#endif /* _MSC_VER */
+#endif /* defined(_MSC_VER) && __has_extension(gnu_asm) */
 
 #endif /* __IMMINTRIN_H */
Index: cfe/trunk/lib/Headers/sgxintrin.h
===
--- cfe/trunk/lib/Headers/sgxintrin.h
+++ cfe/trunk/lib/Headers/sgxintrin.h
@@ -14,6 +14,8 @@
 #ifndef __SGXINTRIN_H
 #define __SGXINTRIN_H
 
+#if __has_extension(gnu_asm)
+
 /* Define the default attributes for the functions in this file. */
 #define __DEFAULT_FN_ATTRS \
   __attribute__((__always_inline__, __nodebug__,  __target__("sgx")))
@@ -53,4 +55,6 @@
 
 #undef __DEFAULT_FN_ATTRS
 
+#endif /* __has_extension(gnu_asm) */
+
 #endif


Index: cfe/trunk/test/Modules/compiler_builtins_x86.c
===
--- cfe/trunk/test/Modules/compiler_builtins_x86.c
+++ cfe/trunk/test/Modules/compiler_builtins_x86.c
@@ -1,6 +1,8 @@
 // RUN: rm -rf %t
 // RUN: %clang_cc1 -triple i686-unknown-unknown -fsyntax-only -fmodules -fimplicit-module-maps -fmodules-cache-path=%t %s -verify -ffreestanding
 // RUN: %clang_cc1 -triple i686-unknown-unknown -fsyntax-only -fmodules -fmodule-map-file=%resource_dir/module.modulemap -fmodules-cache-path=%t %s -verify -ffreestanding
+// RUN: %clang_cc1 -triple i686-unknown-unknown -fsyntax-only -fmodules -fimplicit-module-maps -fmodules-cache-path=%t %s -verify -ffreestanding -fno-gnu-inline-asm
+// RUN: %clang_cc1 -triple i686--windows -fsyntax-only -fmodules -fimplicit-module-maps -fmodules-cache-path=%t %s -verify -ffreestanding -fno-gnu-inline-asm -fms-extensions -fms-compatibility-version=17.00
 // expected-no-diagnostics
 
 #include
Index: cfe/trunk/lib/Headers/pconfigintrin.h
===
--- cfe/trunk/lib/Headers/pconfigintrin.h
+++ cfe/trunk/lib/Headers/pconfigintrin.h
@@ -16,6 +16,8 @@
 
 #define __PCONFIG_KEY_PROGRAM 0x0001
 
+#if __has_extension(gnu_asm)
+
 /* Define the default attributes for the functions in this file. */
 #define __DEFAULT_FN_ATTRS \
   __attribute__((__always_inline__, __nodebug__,  __target__("pconfig")))
@@ -33,4 +35,6 @@
 
 #undef __DEFAULT_FN_ATTRS
 
+#endif /* __has_extension(gnu_asm) */
+
 #endif
Index: cfe/trunk/lib/Headers/immintrin.h

[PATCH] D61350: [clang-tidy] New check calling out uses of +new in Objective-C code

[Michael Wyman via Phabricator via cfe-commits]

mwyman updated this revision to Diff 199341.
mwyman added a comment.

Added +new declaration for ProxyFoo.


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

https://reviews.llvm.org/D61350

Files:
  clang-tools-extra/clang-tidy/google/AvoidNSObjectNewCheck.cpp
  clang-tools-extra/clang-tidy/google/AvoidNSObjectNewCheck.h
  clang-tools-extra/clang-tidy/google/CMakeLists.txt
  clang-tools-extra/clang-tidy/google/GoogleTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/google-objc-avoid-nsobject-new.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/google-objc-avoid-nsobject-new.m

Index: clang-tools-extra/test/clang-tidy/google-objc-avoid-nsobject-new.m
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/google-objc-avoid-nsobject-new.m
@@ -0,0 +1,79 @@
+// RUN: %check_clang_tidy %s google-objc-avoid-nsobject-new %t
+
+@interface NSObject
++ (instancetype)new;
++ (instancetype)alloc;
+- (instancetype)init;
+@end
+
+@interface NSProxy  // Root class with no -init method.
+@end
+
+// NSDate provides a specific factory method.
+@interface NSDate : NSObject
++ (instancetype)date;
+@end
+
+// For testing behavior with Objective-C Generics.
+@interface NSMutableDictionary<__covariant KeyType, __covariant ObjectType> : NSObject
+@end
+
+@class NSString;
+
+#define ALLOCATE_OBJECT(_Type) [_Type new]
+
+void CheckSpecificInitRecommendations(void) {
+  NSObject *object = [NSObject new];
+  // CHECK-MESSAGES: [[@LINE-1]]:22: warning: do not create objects with +new [google-objc-avoid-nsobject-new]
+  // CHECK-FIXES: [NSObject alloc] init];
+
+  NSDate *correctDate = [NSDate date];
+  NSDate *incorrectDate = [NSDate new];
+  // CHECK-MESSAGES: [[@LINE-1]]:27: warning: do not create objects with +new [google-objc-avoid-nsobject-new]
+  // CHECK-FIXES: [NSDate date];
+
+  NSObject *macroCreated = ALLOCATE_OBJECT(NSObject);  // Shouldn't warn on macros.
+
+  NSMutableDictionary *dict = [NSMutableDictionary new];
+  // CHECK-MESSAGES: [[@LINE-1]]:31: warning: do not create objects with +new [google-objc-avoid-nsobject-new]
+  // CHECK-FIXES: [NSMutableDictionary alloc] init];
+}
+
+@interface Foo : NSObject
++ (instancetype)new; // Declare again to suppress warning.
+- (instancetype)initWithInt:(int)anInt;
+- (instancetype)init __attribute__((unavailable));
+
+- (id)new;
+@end
+
+@interface Baz : Foo // Check unavailable -init through inheritance.
+@end
+
+@interface ProxyFoo : NSProxy
+@end
+
+void CallNewWhenInitUnavailable(void) {
+  Foo *foo = [Foo new];
+  // CHECK-MESSAGES: [[@LINE-1]]:14: warning: do not create objects with +new [google-objc-avoid-nsobject-new]
+
+  Baz *baz = [Baz new];
+  // CHECK-MESSAGES: [[@LINE-1]]:14: warning: do not create objects with +new [google-objc-avoid-nsobject-new]
+
+  // Instance method -new calls may be weird, but are not strictly forbidden.
+  Foo *bar = [[Foo alloc] initWithInt:4];
+  [bar new];
+
+  ProxyFoo *proxy = [ProxyFoo new];
+  // CHECK-MESSAGES: [[@LINE-1]]:21: warning: do not create objects with +new [google-objc-avoid-nsobject-new]
+}
+
+@interface HasNewOverride : NSObject
+@end
+
+@implementation HasNewOverride
++ (instancetype)new {
+  return [[self alloc] init];
+}
+// CHECK-MESSAGES: [[@LINE-3]]:1: warning: classes should not override +new [google-objc-avoid-nsobject-new]
+@end
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -133,6 +133,7 @@
google-default-arguments
google-explicit-constructor
google-global-names-in-headers
+   google-objc-avoid-nsobject-new
google-objc-avoid-throwing-exception
google-objc-function-naming
google-objc-global-variable-declaration
Index: clang-tools-extra/docs/clang-tidy/checks/google-objc-avoid-nsobject-new.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/google-objc-avoid-nsobject-new.rst
@@ -0,0 +1,29 @@
+.. title:: clang-tidy - google-objc-avoid-nsobject-new
+
+google-objc-avoid-nsobject-new
+==
+
+Finds calls to ``+new`` or overrides of it, which are prohibited by the
+Google Objective-C style guide.
+
+The Google Objective-C style guide forbids calling ``+new`` or overriding it in
+class implementations, preferring ``+alloc`` and ``-init`` methods to
+instantiate objects.
+
+An example:
+
+.. code-block:: objc
+
+  NSDate *now = [NSDate new];
+  Foo *bar = [Foo new];
+
+Instead, code should use ``+alloc``/``-init`` or class factory methods.
+
+.. code-block:: objc
+
+  NSDate *now = [NSDate date];
+  Foo *bar = [[Foo alloc] init];
+
+This check corresponds to the Google Objective-C Style Guide rule
+`Do Not Use +new

r360630 - [X86] Make `x86intrin.h`, `immintrin.h` includable with `-fno-gnu-inline-asm`.

[Volodymyr Sapsai via cfe-commits]

Author: vsapsai
Date: Mon May 13 15:40:11 2019
New Revision: 360630

URL: http://llvm.org/viewvc/llvm-project?rev=360630=rev
Log:
[X86] Make `x86intrin.h`, `immintrin.h` includable with `-fno-gnu-inline-asm`.

Currently `immintrin.h` includes `pconfigintrin.h` and `sgxintrin.h`
which contain inline assembly. It causes failures when building with the
flag `-fno-gnu-inline-asm`.

Fix by excluding functions with inline assembly when this extension is
disabled. So far there was no need to support `_pconfig_u32`,
`_enclu_u32`, `_encls_u32`, `_enclv_u32` on platforms that require
`-fno-gnu-inline-asm`. But if developers start using these functions,
they'll have compile-time undeclared identifier errors which is
preferrable to runtime errors.

rdar://problem/49540880

Reviewers: craig.topper, GBuella, rnk, echristo

Reviewed By: rnk

Subscribers: jkorous, dexonsmith, cfe-commits

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


Modified:
cfe/trunk/lib/Headers/immintrin.h
cfe/trunk/lib/Headers/pconfigintrin.h
cfe/trunk/lib/Headers/sgxintrin.h
cfe/trunk/test/Modules/compiler_builtins_x86.c

Modified: cfe/trunk/lib/Headers/immintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/immintrin.h?rev=360630=360629=360630=diff
==
--- cfe/trunk/lib/Headers/immintrin.h (original)
+++ cfe/trunk/lib/Headers/immintrin.h Mon May 13 15:40:11 2019
@@ -421,7 +421,7 @@ _storebe_i64(void * __P, long long __D)
 #include 
 #endif
 
-#ifdef _MSC_VER
+#if defined(_MSC_VER) && __has_extension(gnu_asm)
 /* Define the default attributes for these intrinsics */
 #define __DEFAULT_FN_ATTRS __attribute__((__always_inline__, __nodebug__))
 #ifdef __cplusplus
@@ -503,6 +503,6 @@ _InterlockedCompareExchange64_HLERelease
 
 #undef __DEFAULT_FN_ATTRS
 
-#endif /* _MSC_VER */
+#endif /* defined(_MSC_VER) && __has_extension(gnu_asm) */
 
 #endif /* __IMMINTRIN_H */

Modified: cfe/trunk/lib/Headers/pconfigintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/pconfigintrin.h?rev=360630=360629=360630=diff
==
--- cfe/trunk/lib/Headers/pconfigintrin.h (original)
+++ cfe/trunk/lib/Headers/pconfigintrin.h Mon May 13 15:40:11 2019
@@ -16,6 +16,8 @@
 
 #define __PCONFIG_KEY_PROGRAM 0x0001
 
+#if __has_extension(gnu_asm)
+
 /* Define the default attributes for the functions in this file. */
 #define __DEFAULT_FN_ATTRS \
   __attribute__((__always_inline__, __nodebug__,  __target__("pconfig")))
@@ -33,4 +35,6 @@ _pconfig_u32(unsigned int __leaf, __SIZE
 
 #undef __DEFAULT_FN_ATTRS
 
+#endif /* __has_extension(gnu_asm) */
+
 #endif

Modified: cfe/trunk/lib/Headers/sgxintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/sgxintrin.h?rev=360630=360629=360630=diff
==
--- cfe/trunk/lib/Headers/sgxintrin.h (original)
+++ cfe/trunk/lib/Headers/sgxintrin.h Mon May 13 15:40:11 2019
@@ -14,6 +14,8 @@
 #ifndef __SGXINTRIN_H
 #define __SGXINTRIN_H
 
+#if __has_extension(gnu_asm)
+
 /* Define the default attributes for the functions in this file. */
 #define __DEFAULT_FN_ATTRS \
   __attribute__((__always_inline__, __nodebug__,  __target__("sgx")))
@@ -53,4 +55,6 @@ _enclv_u32(unsigned int __leaf, __SIZE_T
 
 #undef __DEFAULT_FN_ATTRS
 
+#endif /* __has_extension(gnu_asm) */
+
 #endif

Modified: cfe/trunk/test/Modules/compiler_builtins_x86.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/compiler_builtins_x86.c?rev=360630=360629=360630=diff
==
--- cfe/trunk/test/Modules/compiler_builtins_x86.c (original)
+++ cfe/trunk/test/Modules/compiler_builtins_x86.c Mon May 13 15:40:11 2019
@@ -1,6 +1,8 @@
 // RUN: rm -rf %t
 // RUN: %clang_cc1 -triple i686-unknown-unknown -fsyntax-only -fmodules 
-fimplicit-module-maps -fmodules-cache-path=%t %s -verify -ffreestanding
 // RUN: %clang_cc1 -triple i686-unknown-unknown -fsyntax-only -fmodules 
-fmodule-map-file=%resource_dir/module.modulemap -fmodules-cache-path=%t %s 
-verify -ffreestanding
+// RUN: %clang_cc1 -triple i686-unknown-unknown -fsyntax-only -fmodules 
-fimplicit-module-maps -fmodules-cache-path=%t %s -verify -ffreestanding 
-fno-gnu-inline-asm
+// RUN: %clang_cc1 -triple i686--windows -fsyntax-only -fmodules 
-fimplicit-module-maps -fmodules-cache-path=%t %s -verify -ffreestanding 
-fno-gnu-inline-asm -fms-extensions -fms-compatibility-version=17.00
 // expected-no-diagnostics
 
 #include


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

[PATCH] D61621: [X86] Make `x86intrin.h`, `immintrin.h` includable with `-fno-gnu-inline-asm`.

[Volodymyr Sapsai via Phabricator via cfe-commits]

vsapsai added a comment.

In D61621#1497027 , @rnk wrote:

> lgtm, thanks!
>
> In D61621#1496978 , @vsapsai wrote:
>
> > Didn't use `-fms-compatibility` in the test and it seems to be working fine.
> >  Don't know if it is accidental and if I should add the flag.
>
>
> `-fms-extensions` is probably all you need. That's the one that defines 
> _MSC_VER.


Thanks for extra information and for the review. In my testing it was 
`-fms-compatibility-version` that defines `_MSC_VER` on macOS. I haven't tested 
extensively but looks like for the driver `-fms-extensions` should be enough 
but for -cc1 you need `-fms-compatibility-version`.


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

https://reviews.llvm.org/D61621



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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Kristóf Umann via Phabricator via cfe-commits]

Szelethus added a comment.

In D57858#1500635 , @NoQ wrote:

> In D57858#146 , @dkrupp wrote:
>
> > Some alpha checkers are considerably more mature than others and are quite 
> > usable. In our experience, there are some users who are keen to run these 
> > checkers on their code and report back any false positives to us. So in 
> > this sense these are not "developer only" checkers. So I think we should 
> > let the users list them, read their descriptions and try them out. Some of 
> > them will come back with useful feedback as to how to improve them further.
>
>
> What are such checkers currently? Like, the ones that aren't clearly "missing 
> limbs" and that have somebody happy to //address// feedback sent against them?


`IteratorChecker` is a prime example that still suffers from not ideal FP/TP 
ratio, but users at Ericsson value it plenty enough not to be bothered by it. 
Many of the changes here and in private directly address user bug reports 
(That's just one, but I do remember having others around too!).

> Do you have a chance to call out to your users for testing the checker and 
> actively request feedback, as @Szelethus did on the mailing list?

Actually yes! Experimental features, even if not checkers, such as the macro 
expansion thingy I wrote was very much feedback driven.

> I feel that we could do some sort of "early access checkers" programme, but i 
> believe this would require a more careful PR than just dumping a list of 
> alpha checkers on our users' heads.

How about making the `-analyzer-checker-help-alpha` flag only emit alpha 
checkers, surrounded by giant disclaimers, and adding some scary text to each 
checkers description?

  *** DISCLAIMER: Alpha checkers might be incomplet and inkorrekt, unstable and 
emit high amount of false positives! Use it as your own discretion! ***
  
alpha.cplusplus.ReinterpretCastIsBad  **EXPERIMENTAL, UNDER DEVELOPMENT** A 
checker that shames you for using reinterpret_cast.
alpha.optin.optout.Random **EXPERIMENTAL, UNDER DEVELOPMENT** 
This checker will cause a crash when enabled. Really.
alpha.pointless.Congrats  **EXPERIMENTAL, UNDER DEVELOPMENT** A 
checker that emits a report for each correct function pointer to function 
pointer C-style cast. Nice!
  
  *** DISCLAIMER: Alpha checkers might be incomplet and inkorrekt, unstable and 
emit high amount of false positives! Use it as your own discretion! ***


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

https://reviews.llvm.org/D57858



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

[PATCH] D61350: [clang-tidy] New check calling out uses of +new in Objective-C code

[Stephane Moore via Phabricator via cfe-commits]

stephanemoore requested changes to this revision.
stephanemoore marked an inline comment as done.
stephanemoore added inline comments.
This revision now requires changes to proceed.



Comment at: clang-tools-extra/clang-tidy/google/AvoidNSObjectNewCheck.cpp:112
+  Result.Nodes.getNodeAs("new_call")) {
+// Don't warn if the call expression originates from a macro expansion.
+if (isMessageExpressionInsideMacro(CallExpr))

mwyman wrote:
> stephanemoore wrote:
> > If the message expression is within a macro expansion, maybe we should emit 
> > the diagnostic without the fixit?
> I'm leery of emitting a warning in a case where the code may not originate 
> from the code in question. Maybe if the macro is defined in the same source 
> file, but I think perhaps that could be a follow-up.
I think that it's reasonable to surface the diagnostic. If the user determines 
that the diagnostic is not relevant in this situation then they can suppress 
it. That is, I believe it's preferable to surface issues and have the user 
determine relevance rather than suppress diagnostics without the knowledge of 
the user.

(with that said, I do not consider this a hard blocker and am comfortable 
deferring this for future consideration)



Comment at: 
clang-tools-extra/test/clang-tidy/google-objc-avoid-nsobject-new.m:53
+
+@interface ProxyFoo : NSProxy
+@end

Shouldn't you declare `+[ProxyFoo new]` so that you can call it on line 67?


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

https://reviews.llvm.org/D61350



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

r360628 - Removing an unused member variable; NFC.

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Mon May 13 15:29:16 2019
New Revision: 360628

URL: http://llvm.org/viewvc/llvm-project?rev=360628=rev
Log:
Removing an unused member variable; NFC.

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

Modified: cfe/trunk/include/clang/AST/JSONNodeDumper.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/JSONNodeDumper.h?rev=360628=360627=360628=diff
==
--- cfe/trunk/include/clang/AST/JSONNodeDumper.h (original)
+++ cfe/trunk/include/clang/AST/JSONNodeDumper.h Mon May 13 15:29:16 2019
@@ -118,7 +118,6 @@ class JSONNodeDumper
   public NodeStreamer {
   friend class JSONDumper;
 
-  raw_ostream 
   const SourceManager 
   PrintingPolicy PrintPolicy;
 
@@ -161,7 +160,7 @@ class JSONNodeDumper
 public:
   JSONNodeDumper(raw_ostream , const SourceManager ,
  const PrintingPolicy )
-  : NodeStreamer(OS), OS(OS), SM(SrcMgr), PrintPolicy(PrintPolicy) {}
+  : NodeStreamer(OS), SM(SrcMgr), PrintPolicy(PrintPolicy) {}
 
   void Visit(const Attr *A);
   void Visit(const Stmt *Node);


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

[PATCH] D61765: [OpenMP][Clang][BugFix] Split declares and math functions inclusion.

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC360626: [OpenMP][Clang][BugFix] Split declares and math 
functions inclusion. (authored by gbercea, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D61765?vs=199304=199340#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D61765

Files:
  lib/Driver/ToolChains/Clang.cpp
  lib/Headers/CMakeLists.txt
  lib/Headers/__clang_cuda_cmath.h
  lib/Headers/__clang_cuda_device_functions.h
  lib/Headers/__clang_cuda_math_forward_declares.h
  lib/Headers/openmp_wrappers/__clang_openmp_math.h
  lib/Headers/openmp_wrappers/__clang_openmp_math_declares.h
  lib/Headers/openmp_wrappers/cmath
  lib/Headers/openmp_wrappers/math.h
  test/Headers/Inputs/include/cstdlib
  test/Headers/nvptx_device_cmath_functions.c
  test/Headers/nvptx_device_cmath_functions.cpp
  test/Headers/nvptx_device_math_functions.c
  test/Headers/nvptx_device_math_functions.cpp

Index: test/Headers/nvptx_device_cmath_functions.cpp
===
--- test/Headers/nvptx_device_cmath_functions.cpp
+++ test/Headers/nvptx_device_cmath_functions.cpp
@@ -4,9 +4,10 @@
 // REQUIRES: nvptx-registered-target
 
 // RUN: %clang_cc1 -internal-isystem %S/Inputs/include -include cmath -x c++ -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc
-// RUN: %clang_cc1 -internal-isystem %S/../../lib/Headers/openmp_wrappers -include __clang_openmp_math.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -include cmath -internal-isystem %S/Inputs/include -include stdlib.h -x c++ -fopenmp -triple nvptx64-nvidia-cuda -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck -check-prefix CHECK-YES %s
+// RUN: %clang_cc1 -internal-isystem %S/../../lib/Headers/openmp_wrappers -include __clang_openmp_math_declares.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -include cmath -internal-isystem %S/Inputs/include -include stdlib.h -x c++ -fopenmp -triple nvptx64-nvidia-cuda -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck -check-prefix CHECK-YES %s
 
 #include 
+#include 
 
 void test_sqrt(double a1) {
   #pragma omp target
Index: test/Headers/nvptx_device_math_functions.c
===
--- test/Headers/nvptx_device_math_functions.c
+++ test/Headers/nvptx_device_math_functions.c
@@ -4,7 +4,7 @@
 // REQUIRES: nvptx-registered-target
 
 // RUN: %clang_cc1 -internal-isystem %S/Inputs/include -include math.h -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc
-// RUN: %clang_cc1 -internal-isystem %S/../../lib/Headers/openmp_wrappers -include __clang_openmp_math.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -include math.h -fopenmp -triple nvptx64-nvidia-cuda -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck -check-prefix CHECK-YES %s
+// RUN: %clang_cc1 -internal-isystem %S/../../lib/Headers/openmp_wrappers -include __clang_openmp_math_declares.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -include math.h -fopenmp -triple nvptx64-nvidia-cuda -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck -check-prefix CHECK-YES %s
 
 #include 
 
Index: test/Headers/nvptx_device_cmath_functions.c
===
--- test/Headers/nvptx_device_cmath_functions.c
+++ test/Headers/nvptx_device_cmath_functions.c
@@ -4,7 +4,7 @@
 // REQUIRES: nvptx-registered-target
 
 // RUN: %clang_cc1 -internal-isystem %S/Inputs/include -include cmath -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc
-// RUN: %clang_cc1 -internal-isystem %S/../../lib/Headers/openmp_wrappers -include __clang_openmp_math.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -include cmath -fopenmp -triple nvptx64-nvidia-cuda -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck -check-prefix CHECK-YES %s
+// RUN: %clang_cc1 -internal-isystem %S/../../lib/Headers/openmp_wrappers -include __clang_openmp_math_declares.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -include cmath -fopenmp -triple nvptx64-nvidia-cuda -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda 

[PATCH] D61619: Make language option `GNUAsm` discoverable with `__has_extension` macro.

[Volodymyr Sapsai via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rC360625: Make language option `GNUAsm` discoverable with 
`__has_extension` macro. (authored by vsapsai, committed by ).
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D61619?vs=198363=199339#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D61619

Files:
  include/clang/Basic/Features.def
  test/Parser/asm.c
  test/Parser/no-gnu-inline-asm.c


Index: include/clang/Basic/Features.def
===
--- include/clang/Basic/Features.def
+++ include/clang/Basic/Features.def
@@ -248,6 +248,7 @@
 EXTENSION(overloadable_unmarked, true)
 EXTENSION(pragma_clang_attribute_namespaces, true)
 EXTENSION(pragma_clang_attribute_external_declaration, true)
+EXTENSION(gnu_asm, LangOpts.GNUAsm)
 
 #undef EXTENSION
 #undef FEATURE
Index: test/Parser/no-gnu-inline-asm.c
===
--- test/Parser/no-gnu-inline-asm.c
+++ test/Parser/no-gnu-inline-asm.c
@@ -1,5 +1,9 @@
 // RUN: %clang_cc1 %s -triple i686-apple-darwin -verify -fsyntax-only 
-fno-gnu-inline-asm
 
+#if __has_extension(gnu_asm)
+#error Expected extension 'gnu_asm' to be disabled
+#endif
+
 asm ("INST r1, 0"); // expected-error {{GNU-style inline assembly is disabled}}
 
 void foo() __asm("__foo_func"); // AsmLabel is OK
Index: test/Parser/asm.c
===
--- test/Parser/asm.c
+++ test/Parser/asm.c
@@ -1,5 +1,9 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s
 
+#if !__has_extension(gnu_asm)
+#error Extension 'gnu_asm' should be available by default
+#endif
+
 void f1() {
   // PR7673: Some versions of GCC support an empty clobbers section.
   asm ("ret" : : :);


Index: include/clang/Basic/Features.def
===
--- include/clang/Basic/Features.def
+++ include/clang/Basic/Features.def
@@ -248,6 +248,7 @@
 EXTENSION(overloadable_unmarked, true)
 EXTENSION(pragma_clang_attribute_namespaces, true)
 EXTENSION(pragma_clang_attribute_external_declaration, true)
+EXTENSION(gnu_asm, LangOpts.GNUAsm)
 
 #undef EXTENSION
 #undef FEATURE
Index: test/Parser/no-gnu-inline-asm.c
===
--- test/Parser/no-gnu-inline-asm.c
+++ test/Parser/no-gnu-inline-asm.c
@@ -1,5 +1,9 @@
 // RUN: %clang_cc1 %s -triple i686-apple-darwin -verify -fsyntax-only -fno-gnu-inline-asm
 
+#if __has_extension(gnu_asm)
+#error Expected extension 'gnu_asm' to be disabled
+#endif
+
 asm ("INST r1, 0"); // expected-error {{GNU-style inline assembly is disabled}}
 
 void foo() __asm("__foo_func"); // AsmLabel is OK
Index: test/Parser/asm.c
===
--- test/Parser/asm.c
+++ test/Parser/asm.c
@@ -1,5 +1,9 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s
 
+#if !__has_extension(gnu_asm)
+#error Extension 'gnu_asm' should be available by default
+#endif
+
 void f1() {
   // PR7673: Some versions of GCC support an empty clobbers section.
   asm ("ret" : : :);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61350: [clang-tidy] New check calling out uses of +new in Objective-C code

[Michael Wyman via Phabricator via cfe-commits]

mwyman updated this revision to Diff 199338.
mwyman added a comment.

Update for comments


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

https://reviews.llvm.org/D61350

Files:
  clang-tools-extra/clang-tidy/google/AvoidNSObjectNewCheck.cpp
  clang-tools-extra/clang-tidy/google/AvoidNSObjectNewCheck.h
  clang-tools-extra/clang-tidy/google/CMakeLists.txt
  clang-tools-extra/clang-tidy/google/GoogleTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/google-objc-avoid-nsobject-new.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/test/clang-tidy/google-objc-avoid-nsobject-new.m

Index: clang-tools-extra/test/clang-tidy/google-objc-avoid-nsobject-new.m
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/google-objc-avoid-nsobject-new.m
@@ -0,0 +1,79 @@
+// RUN: %check_clang_tidy %s google-objc-avoid-nsobject-new %t
+
+@interface NSObject
++ (instancetype)new;
++ (instancetype)alloc;
+- (instancetype)init;
+@end
+
+@interface NSProxy  // Root class with no -init method.
+@end
+
+// NSDate provides a specific factory method.
+@interface NSDate : NSObject
++ (instancetype)date;
+@end
+
+// For testing behavior with Objective-C Generics.
+@interface NSMutableDictionary<__covariant KeyType, __covariant ObjectType> : NSObject
+@end
+
+@class NSString;
+
+#define ALLOCATE_OBJECT(_Type) [_Type new]
+
+void CheckSpecificInitRecommendations(void) {
+  NSObject *object = [NSObject new];
+  // CHECK-MESSAGES: [[@LINE-1]]:22: warning: do not create objects with +new [google-objc-avoid-nsobject-new]
+  // CHECK-FIXES: [NSObject alloc] init];
+
+  NSDate *correctDate = [NSDate date];
+  NSDate *incorrectDate = [NSDate new];
+  // CHECK-MESSAGES: [[@LINE-1]]:27: warning: do not create objects with +new [google-objc-avoid-nsobject-new]
+  // CHECK-FIXES: [NSDate date];
+
+  NSObject *macroCreated = ALLOCATE_OBJECT(NSObject);  // Shouldn't warn on macros.
+
+  NSMutableDictionary *dict = [NSMutableDictionary new];
+  // CHECK-MESSAGES: [[@LINE-1]]:31: warning: do not create objects with +new [google-objc-avoid-nsobject-new]
+  // CHECK-FIXES: [NSMutableDictionary alloc] init];
+}
+
+@interface Foo : NSObject
++ (instancetype)new; // Declare again to suppress warning.
+- (instancetype)initWithInt:(int)anInt;
+- (instancetype)init __attribute__((unavailable));
+
+- (id)new;
+@end
+
+@interface Baz : Foo // Check unavailable -init through inheritance.
+@end
+
+@interface ProxyFoo : NSProxy
+@end
+
+void CallNewWhenInitUnavailable(void) {
+  Foo *foo = [Foo new];
+  // CHECK-MESSAGES: [[@LINE-1]]:14: warning: do not create objects with +new [google-objc-avoid-nsobject-new]
+
+  Baz *baz = [Baz new];
+  // CHECK-MESSAGES: [[@LINE-1]]:14: warning: do not create objects with +new [google-objc-avoid-nsobject-new]
+
+  // Instance method -new calls may be weird, but are not strictly forbidden.
+  Foo *bar = [[Foo alloc] initWithInt:4];
+  [bar new];
+
+  ProxyFoo *proxy = [ProxyFoo new];
+  // CHECK-MESSAGES: [[@LINE-1]]:21: warning: do not create objects with +new [google-objc-avoid-nsobject-new]
+}
+
+@interface HasNewOverride : NSObject
+@end
+
+@implementation HasNewOverride
++ (instancetype)new {
+  return [[self alloc] init];
+}
+// CHECK-MESSAGES: [[@LINE-3]]:1: warning: classes should not override +new [google-objc-avoid-nsobject-new]
+@end
Index: clang-tools-extra/docs/clang-tidy/checks/list.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/list.rst
+++ clang-tools-extra/docs/clang-tidy/checks/list.rst
@@ -133,6 +133,7 @@
google-default-arguments
google-explicit-constructor
google-global-names-in-headers
+   google-objc-avoid-nsobject-new
google-objc-avoid-throwing-exception
google-objc-function-naming
google-objc-global-variable-declaration
Index: clang-tools-extra/docs/clang-tidy/checks/google-objc-avoid-nsobject-new.rst
===
--- /dev/null
+++ clang-tools-extra/docs/clang-tidy/checks/google-objc-avoid-nsobject-new.rst
@@ -0,0 +1,29 @@
+.. title:: clang-tidy - google-objc-avoid-nsobject-new
+
+google-objc-avoid-nsobject-new
+==
+
+Finds calls to ``+new`` or overrides of it, which are prohibited by the
+Google Objective-C style guide.
+
+The Google Objective-C style guide forbids calling ``+new`` or overriding it in
+class implementations, preferring ``+alloc`` and ``-init`` methods to
+instantiate objects.
+
+An example:
+
+.. code-block:: objc
+
+  NSDate *now = [NSDate new];
+  Foo *bar = [Foo new];
+
+Instead, code should use ``+alloc``/``-init`` or class factory methods.
+
+.. code-block:: objc
+
+  NSDate *now = [NSDate date];
+  Foo *bar = [[Foo alloc] init];
+
+This check corresponds to the Google Objective-C Style Guide rule
+`Do Not Use +new

[PATCH] D61350: [clang-tidy] New check calling out uses of +new in Objective-C code

[Stephane Moore via Phabricator via cfe-commits]

stephanemoore accepted this revision.
stephanemoore added a comment.

I believe that all the feedback from @gribozavr has been addressed modulo one 
small nit. Once that nit has been addressed, I can land this.




Comment at: clang-tools-extra/clang-tidy/google/AvoidNSObjectNewCheck.h:19
+
+/// The check finds Objective-C code that uses +new to create object instances,
+/// or overrides +new in classes. Both are forbidden by Google's Objective-C

I believe @gribozavr recommended "This check".


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

https://reviews.llvm.org/D61350



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

r360626 - [OpenMP][Clang][BugFix] Split declares and math functions inclusion.

[Gheorghe-Teodor Bercea via cfe-commits]

Author: gbercea
Date: Mon May 13 15:11:44 2019
New Revision: 360626

URL: http://llvm.org/viewvc/llvm-project?rev=360626=rev
Log:
[OpenMP][Clang][BugFix] Split declares and math functions inclusion.

Summary: This patches fixes an issue in which the __clang_cuda_cmath.h header 
is being included even when cmath or math.h headers are not included.

Reviewers: jdoerfert, ABataev, hfinkel, caomhin, tra

Reviewed By: tra

Subscribers: tra, mgorny, guansong, cfe-commits

Tags: #clang

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

Added:
cfe/trunk/lib/Headers/openmp_wrappers/__clang_openmp_math_declares.h
cfe/trunk/test/Headers/Inputs/include/cstdlib
Modified:
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/lib/Headers/CMakeLists.txt
cfe/trunk/lib/Headers/__clang_cuda_cmath.h
cfe/trunk/lib/Headers/__clang_cuda_device_functions.h
cfe/trunk/lib/Headers/__clang_cuda_math_forward_declares.h
cfe/trunk/lib/Headers/openmp_wrappers/__clang_openmp_math.h
cfe/trunk/lib/Headers/openmp_wrappers/cmath
cfe/trunk/lib/Headers/openmp_wrappers/math.h
cfe/trunk/test/Headers/nvptx_device_cmath_functions.c
cfe/trunk/test/Headers/nvptx_device_cmath_functions.cpp
cfe/trunk/test/Headers/nvptx_device_math_functions.c
cfe/trunk/test/Headers/nvptx_device_math_functions.cpp

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=360626=360625=360626=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Mon May 13 15:11:44 2019
@@ -1166,7 +1166,7 @@ void Clang::AddPreprocessingOptions(Comp
 }
 
 CmdArgs.push_back("-include");
-CmdArgs.push_back("__clang_openmp_math.h");
+CmdArgs.push_back("__clang_openmp_math_declares.h");
   }
 
   // Add -i* options, and automatically translate to

Modified: cfe/trunk/lib/Headers/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/CMakeLists.txt?rev=360626=360625=360626=diff
==
--- cfe/trunk/lib/Headers/CMakeLists.txt (original)
+++ cfe/trunk/lib/Headers/CMakeLists.txt Mon May 13 15:11:44 2019
@@ -132,6 +132,7 @@ set(openmp_wrapper_files
   openmp_wrappers/math.h
   openmp_wrappers/cmath
   openmp_wrappers/__clang_openmp_math.h
+  openmp_wrappers/__clang_openmp_math_declares.h
 )
 
 set(output_dir ${LLVM_LIBRARY_OUTPUT_INTDIR}/clang/${CLANG_VERSION}/include)

Modified: cfe/trunk/lib/Headers/__clang_cuda_cmath.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/__clang_cuda_cmath.h?rev=360626=360625=360626=diff
==
--- cfe/trunk/lib/Headers/__clang_cuda_cmath.h (original)
+++ cfe/trunk/lib/Headers/__clang_cuda_cmath.h Mon May 13 15:11:44 2019
@@ -36,8 +36,10 @@
 #define __DEVICE__ static __device__ __inline__ __attribute__((always_inline))
 #endif
 
+#if !(defined(_OPENMP) && defined(__cplusplus))
 __DEVICE__ long long abs(long long __n) { return ::llabs(__n); }
 __DEVICE__ long abs(long __n) { return ::labs(__n); }
+#endif
 __DEVICE__ float abs(float __x) { return ::fabsf(__x); }
 __DEVICE__ double abs(double __x) { return ::fabs(__x); }
 __DEVICE__ float acos(float __x) { return ::acosf(__x); }

Modified: cfe/trunk/lib/Headers/__clang_cuda_device_functions.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/__clang_cuda_device_functions.h?rev=360626=360625=360626=diff
==
--- cfe/trunk/lib/Headers/__clang_cuda_device_functions.h (original)
+++ cfe/trunk/lib/Headers/__clang_cuda_device_functions.h Mon May 13 15:11:44 
2019
@@ -1493,8 +1493,10 @@ __DEVICE__ double cbrt(double __a) { ret
 __DEVICE__ float cbrtf(float __a) { return __nv_cbrtf(__a); }
 __DEVICE__ double ceil(double __a) { return __nv_ceil(__a); }
 __DEVICE__ float ceilf(float __a) { return __nv_ceilf(__a); }
+#ifndef _OPENMP
 __DEVICE__ int clock() { return __nvvm_read_ptx_sreg_clock(); }
 __DEVICE__ long long clock64() { return __nvvm_read_ptx_sreg_clock64(); }
+#endif
 __DEVICE__ double copysign(double __a, double __b) {
   return __nv_copysign(__a, __b);
 }

Modified: cfe/trunk/lib/Headers/__clang_cuda_math_forward_declares.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/__clang_cuda_math_forward_declares.h?rev=360626=360625=360626=diff
==
--- cfe/trunk/lib/Headers/__clang_cuda_math_forward_declares.h (original)
+++ cfe/trunk/lib/Headers/__clang_cuda_math_forward_declares.h Mon May 13 
15:11:44 2019
@@ -27,11 +27,13 @@
   static __inline__ __attribute__((always_inline)) __attribute__((device))
 #endif
 
-__DEVICE__ double abs(double);
-__DEVICE__ float abs(float);

r360625 - Make language option `GNUAsm` discoverable with `__has_extension` macro.

[Volodymyr Sapsai via cfe-commits]

Author: vsapsai
Date: Mon May 13 15:11:10 2019
New Revision: 360625

URL: http://llvm.org/viewvc/llvm-project?rev=360625=rev
Log:
Make language option `GNUAsm` discoverable with `__has_extension` macro.

This can be used for better support of `-fno-gnu-inline-asm` builds.

rdar://problem/49540880

Reviewers: aaron.ballman, rsmith

Reviewed By: aaron.ballman

Subscribers: eraman, jkorous, dexonsmith, craig.topper, cfe-commits

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


Modified:
cfe/trunk/include/clang/Basic/Features.def
cfe/trunk/test/Parser/asm.c
cfe/trunk/test/Parser/no-gnu-inline-asm.c

Modified: cfe/trunk/include/clang/Basic/Features.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Features.def?rev=360625=360624=360625=diff
==
--- cfe/trunk/include/clang/Basic/Features.def (original)
+++ cfe/trunk/include/clang/Basic/Features.def Mon May 13 15:11:10 2019
@@ -248,6 +248,7 @@ EXTENSION(cxx_variable_templates, LangOp
 EXTENSION(overloadable_unmarked, true)
 EXTENSION(pragma_clang_attribute_namespaces, true)
 EXTENSION(pragma_clang_attribute_external_declaration, true)
+EXTENSION(gnu_asm, LangOpts.GNUAsm)
 
 #undef EXTENSION
 #undef FEATURE

Modified: cfe/trunk/test/Parser/asm.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/asm.c?rev=360625=360624=360625=diff
==
--- cfe/trunk/test/Parser/asm.c (original)
+++ cfe/trunk/test/Parser/asm.c Mon May 13 15:11:10 2019
@@ -1,5 +1,9 @@
 // RUN: %clang_cc1 -fsyntax-only -verify %s
 
+#if !__has_extension(gnu_asm)
+#error Extension 'gnu_asm' should be available by default
+#endif
+
 void f1() {
   // PR7673: Some versions of GCC support an empty clobbers section.
   asm ("ret" : : :);

Modified: cfe/trunk/test/Parser/no-gnu-inline-asm.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/no-gnu-inline-asm.c?rev=360625=360624=360625=diff
==
--- cfe/trunk/test/Parser/no-gnu-inline-asm.c (original)
+++ cfe/trunk/test/Parser/no-gnu-inline-asm.c Mon May 13 15:11:10 2019
@@ -1,5 +1,9 @@
 // RUN: %clang_cc1 %s -triple i686-apple-darwin -verify -fsyntax-only 
-fno-gnu-inline-asm
 
+#if __has_extension(gnu_asm)
+#error Expected extension 'gnu_asm' to be disabled
+#endif
+
 asm ("INST r1, 0"); // expected-error {{GNU-style inline assembly is disabled}}
 
 void foo() __asm("__foo_func"); // AsmLabel is OK


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

[PATCH] D61136: [Analyzer] Refactor begin and end symbol creation

[Artem Dergachev via Phabricator via cfe-commits]

NoQ accepted this revision.
NoQ added a comment.

Thx!


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

https://reviews.llvm.org/D61136



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

[PATCH] D61619: Make language option `GNUAsm` discoverable with `__has_extension` macro.

[Volodymyr Sapsai via Phabricator via cfe-commits]

vsapsai added a comment.

Thanks for the review, Aaron.


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

https://reviews.llvm.org/D61619



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

[PATCH] D61370: Add a C2x mode and allow attributes in it

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith accepted this revision.
rsmith added inline comments.
This revision is now accepted and ready to land.



Comment at: lib/Frontend/CompilerInvocation.cpp:2593-2596
+  // Enable [[]] attributes in C++11 and C2x by default.
+  Opts.DoubleSquareBracketAttributes = Args.hasFlag(
+  OPT_fdouble_square_bracket_attributes,
+  OPT_fno_double_square_bracket_attributes, Opts.CPlusPlus11 || Opts.C2x);

(We get this wrong in a bunch of other places, but...)

The default from the language mode should be set by `setLangDefault`, and here 
we should override it if suitable flags are set.


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

https://reviews.llvm.org/D61370



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

[PATCH] D57858: [analyzer] Add a new frontend flag to display all checker options

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

In D57858#146 , @dkrupp wrote:

> Some alpha checkers are considerably more mature than others and are quite 
> usable. In our experience, there are some users who are keen to run these 
> checkers on their code and report back any false positives to us. So in this 
> sense these are not "developer only" checkers. So I think we should let the 
> users list them, read their descriptions and try them out. Some of them will 
> come back with useful feedback as to how to improve them further.


What are such checkers currently? Like, the ones that aren't clearly "missing 
limbs" and that have somebody happy to //address// feedback sent against them?

Do you have a chance to call out to your users for testing the checker and 
actively request feedback, as @Szelethus did on the mailing list?

I feel that we could do some sort of "early access checkers" programme, but i 
believe this would require a more careful PR than just dumping a list of alpha 
checkers on our users' heads.

In D57858#146 , @dkrupp wrote:

> Some users would not care if the checker gives some more false positives than 
> the "mature" checkers if they can catch some true positives with them.


Yeah, and these are pretty much the users we're trying to protect from 
themselves :)


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

https://reviews.llvm.org/D57858



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

[PATCH] D60910: [WIP] Dumping the AST to JSON

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman closed this revision.
aaron.ballman added a comment.

Commit in r360622.


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

https://reviews.llvm.org/D60910



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

[PATCH] D24892: [clang-tidy] Add option "LiteralInitializers" to cppcoreguidelines-pro-type-member-init

[Matthias Gehre via Phabricator via cfe-commits]

mgehre updated this revision to Diff 199330.
mgehre added a comment.

Fix wrong merge of ReleaseNotes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D24892

Files:
  clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.cpp
  clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-pro-type-member-init.rst
  
clang-tools-extra/test/clang-tidy/cppcoreguidelines-pro-type-member-init-use-assignment.cpp

Index: clang-tools-extra/test/clang-tidy/cppcoreguidelines-pro-type-member-init-use-assignment.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/cppcoreguidelines-pro-type-member-init-use-assignment.cpp
@@ -0,0 +1,40 @@
+// RUN: %check_clang_tidy %s cppcoreguidelines-pro-type-member-init %t -- -config="{CheckOptions: [{key: "cppcoreguidelines-pro-type-member-init.UseAssignment", value: 1}]}" -- -std=c++11
+
+struct T {
+  int i;
+};
+
+struct S {
+  bool b;
+  // CHECK-FIXES: bool b = false;
+  char c;
+  // CHECK-FIXES: char c = 0;
+  signed char sc;
+  // CHECK-FIXES: signed char sc = 0;
+  unsigned char uc;
+  // CHECK-FIXES: unsigned char uc = 0U;
+  int i;
+  // CHECK-FIXES: int i = 0;
+  unsigned u;
+  // CHECK-FIXES: unsigned u = 0U;
+  long l;
+  // CHECK-FIXES: long l = 0L;
+  unsigned long ul;
+  // CHECK-FIXES: unsigned long ul = 0UL;
+  long long ll;
+  // CHECK-FIXES: long long ll = 0LL;
+  unsigned long long ull;
+  // CHECK-FIXES: unsigned long long ull = 0ULL;
+  float f;
+  // CHECK-FIXES: float f = 0.0F;
+  double d;
+  // CHECK-FIXES: double d = 0.0;
+  long double ld;
+  // CHECK-FIXES: double ld = 0.0L;
+  int *ptr;
+  // CHECK-FIXES: int *ptr = nullptr;
+  T t;
+  // CHECK-FIXES: T t{};
+  S() {}
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: constructor does not initialize these fields:
+};
Index: clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-pro-type-member-init.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-pro-type-member-init.rst
+++ clang-tools-extra/docs/clang-tidy/checks/cppcoreguidelines-pro-type-member-init.rst
@@ -33,6 +33,10 @@
zero-initialized during construction. For performance critical code, it may
be important to not initialize fixed-size array members. Default is `0`.
 
+.. option:: UseAssignment
+   If set to non-zero, the check will provide fix-its with literal initializers
+   (``int i = 0;``) instead of curly braces (``int i{};``).
+
 This rule is part of the "Type safety" profile of the C++ Core
 Guidelines, corresponding to rule Type.6. See
 https://github.com/isocpp/CppCoreGuidelines/blob/master/CppCoreGuidelines.md#Pro-type-memberinit.
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -163,6 +163,11 @@
 
   Rewrites function signatures to use a trailing return type.
 
+- Added `UseAssignment` option to :doc:`cppcoreguidelines-pro-type-member-init`
+
+  If set to true, the check will provide fix-its with literal initializers
+  (``int i = 0;``) instead of curly braces (``int i{};``).
+
 Improvements to include-fixer
 -
 
Index: clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.h
===
--- clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.h
+++ clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.h
@@ -64,6 +64,11 @@
 
   // Whether arrays need to be initialized or not. Default is false.
   bool IgnoreArrays;
+
+  // Whether fix-its for initialization of fundamental type use assignment
+  // instead of brace initalization. Only effective in C++11 mode. Default is
+  // false.
+  bool UseAssignment;
 };
 
 } // namespace cppcoreguidelines
Index: clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.cpp
===
--- clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.cpp
+++ clang-tools-extra/clang-tidy/cppcoreguidelines/ProTypeMemberInitCheck.cpp
@@ -250,7 +250,8 @@
 ProTypeMemberInitCheck::ProTypeMemberInitCheck(StringRef Name,
ClangTidyContext *Context)
 : ClangTidyCheck(Name, Context),
-  IgnoreArrays(Options.get("IgnoreArrays", false)) {}
+  IgnoreArrays(Options.get("IgnoreArrays", false)),
+  UseAssignment(Options.getLocalOrGlobal("UseAssignment", false)) {}
 
 void ProTypeMemberInitCheck::registerMatchers(MatchFinder *Finder) {
   if (!getLangOpts().CPlusPlus)
@@ -314,6 +315,7 @@
 
 void 

r360622 - Introduce the ability to dump the AST to JSON.

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Mon May 13 14:39:55 2019
New Revision: 360622

URL: http://llvm.org/viewvc/llvm-project?rev=360622=rev
Log:
Introduce the ability to dump the AST to JSON.

This adds the -ast-dump=json cc1 flag (in addition to -ast-dump=default, which 
is the default if no dump format is specified), as well as some initial AST 
dumping functionality and tests.

Added:
cfe/trunk/include/clang/AST/JSONNodeDumper.h
cfe/trunk/lib/AST/JSONNodeDumper.cpp
cfe/trunk/test/AST/ast-dump-enum-json.cpp
cfe/trunk/test/AST/ast-dump-if-json.cpp
cfe/trunk/test/AST/ast-dump-namespace-json.cpp
Modified:
cfe/trunk/include/clang/AST/ASTDumperUtils.h
cfe/trunk/include/clang/AST/DeclBase.h
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/include/clang/Frontend/ASTConsumers.h
cfe/trunk/include/clang/Frontend/FrontendOptions.h
cfe/trunk/lib/AST/ASTDumper.cpp
cfe/trunk/lib/AST/CMakeLists.txt
cfe/trunk/lib/Frontend/ASTConsumers.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/lib/Frontend/FrontendActions.cpp
cfe/trunk/tools/clang-check/ClangCheck.cpp
cfe/trunk/tools/clang-import-test/clang-import-test.cpp

Modified: cfe/trunk/include/clang/AST/ASTDumperUtils.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTDumperUtils.h?rev=360622=360621=360622=diff
==
--- cfe/trunk/include/clang/AST/ASTDumperUtils.h (original)
+++ cfe/trunk/include/clang/AST/ASTDumperUtils.h Mon May 13 14:39:55 2019
@@ -17,6 +17,12 @@
 
 namespace clang {
 
+/// Used to specify the format for printing AST dump information.
+enum ASTDumpOutputFormat {
+  ADOF_Default,
+  ADOF_JSON
+};
+
 // Colors used for various parts of the AST dump
 // Do not use bold yellow for any text.  It is hard to read on white screens.
 

Modified: cfe/trunk/include/clang/AST/DeclBase.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/DeclBase.h?rev=360622=360621=360622=diff
==
--- cfe/trunk/include/clang/AST/DeclBase.h (original)
+++ cfe/trunk/include/clang/AST/DeclBase.h Mon May 13 14:39:55 2019
@@ -13,6 +13,7 @@
 #ifndef LLVM_CLANG_AST_DECLBASE_H
 #define LLVM_CLANG_AST_DECLBASE_H
 
+#include "clang/AST/ASTDumperUtils.h"
 #include "clang/AST/AttrIterator.h"
 #include "clang/AST/DeclarationName.h"
 #include "clang/Basic/IdentifierTable.h"
@@ -1134,7 +1135,8 @@ public:
   // Same as dump(), but forces color printing.
   void dumpColor() const;
 
-  void dump(raw_ostream , bool Deserialize = false) const;
+  void dump(raw_ostream , bool Deserialize = false,
+ASTDumpOutputFormat OutputFormat = ADOF_Default) const;
 
   /// \return Unique reproducible object identifier
   int64_t getID() const;

Added: cfe/trunk/include/clang/AST/JSONNodeDumper.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/JSONNodeDumper.h?rev=360622=auto
==
--- cfe/trunk/include/clang/AST/JSONNodeDumper.h (added)
+++ cfe/trunk/include/clang/AST/JSONNodeDumper.h Mon May 13 14:39:55 2019
@@ -0,0 +1,330 @@
+//===--- JSONNodeDumper.h - Printing of AST nodes to JSON 
-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// This file implements AST dumping of components of individual AST nodes to
+// a JSON.
+//
+//===--===//
+
+#ifndef LLVM_CLANG_AST_JSONNODEDUMPER_H
+#define LLVM_CLANG_AST_JSONNODEDUMPER_H
+
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/ASTNodeTraverser.h"
+#include "clang/AST/ASTDumperUtils.h"
+#include "clang/AST/AttrVisitor.h"
+#include "clang/AST/CommentCommandTraits.h"
+#include "clang/AST/CommentVisitor.h"
+#include "clang/AST/ExprCXX.h"
+#include "llvm/Support/JSON.h"
+
+namespace clang {
+
+class NodeStreamer {
+  bool FirstChild = true;
+  bool TopLevel = true;
+  llvm::SmallVector, 32> Pending;
+
+protected:
+  llvm::json::OStream JOS;
+
+public:
+  /// Add a child of the current node.  Calls DoAddChild without arguments
+  template  void AddChild(Fn DoAddChild) {
+return AddChild("", DoAddChild);
+  }
+
+  /// Add a child of the current node with an optional label.
+  /// Calls DoAddChild without arguments.
+  template  void AddChild(StringRef Label, Fn DoAddChild) {
+// If we're at the top level, there's nothing interesting to do; just
+// run the dumper.
+if (TopLevel) {
+  TopLevel = false;
+  JOS.objectBegin();
+
+  DoAddChild();
+
+  while (!Pending.empty()) {
+Pending.back()(true);
+Pending.pop_back();
+  }
+
+  

[PATCH] D61874: [clang-tidy] Fix invalid fixit for readability-static-accessed-through-instance (bug 40544)

[Matthias Gehre via Phabricator via cfe-commits]

mgehre created this revision.
mgehre added reviewers: aaron.ballman, alexfh, xazax.hun.
mgehre added projects: clang, clang-tools-extra.
Herald added a subscriber: rnkovacs.

Fixed https://bugs.llvm.org/show_bug.cgi?id=40544
Before, we would generate a fixit like `(anonymous namespace)::Foo::fun();` for
the added test case.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D61874

Files:
  
clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
  
clang-tools-extra/test/clang-tidy/readability-static-accessed-through-instance.cpp


Index: 
clang-tools-extra/test/clang-tidy/readability-static-accessed-through-instance.cpp
===
--- 
clang-tools-extra/test/clang-tidy/readability-static-accessed-through-instance.cpp
+++ 
clang-tools-extra/test/clang-tidy/readability-static-accessed-through-instance.cpp
@@ -220,3 +220,31 @@
   qp->y = 10; // OK, the overloaded operator might have side-effects.
   qp->K = 10; //
 }
+
+namespace {
+  struct Anonymous {
+static int I;
+  };
+}
+
+void use_anonymous() {
+  Anonymous Anon;
+  Anon.I;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: static member
+  // CHECK-FIXES: {{^}}  Anonymous::I;{{$}}
+}
+
+namespace Outer {
+  inline namespace Inline {
+struct S {
+  static int I;
+};
+  }
+}
+
+void use_inline() {
+  Outer::S V;
+  V.I;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: static member
+  // CHECK-FIXES: {{^}}  Outer::S::I;{{$}}
+}
Index: 
clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
===
--- 
clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
+++ 
clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
@@ -67,6 +67,7 @@
   const ASTContext *AstContext = Result.Context;
   PrintingPolicy PrintingPolicyWithSupressedTag(AstContext->getLangOpts());
   PrintingPolicyWithSupressedTag.SuppressTagKeyword = true;
+  PrintingPolicyWithSupressedTag.SuppressUnwrittenScope = true;
   std::string BaseTypeName =
   BaseType.getAsString(PrintingPolicyWithSupressedTag);
 


Index: clang-tools-extra/test/clang-tidy/readability-static-accessed-through-instance.cpp
===
--- clang-tools-extra/test/clang-tidy/readability-static-accessed-through-instance.cpp
+++ clang-tools-extra/test/clang-tidy/readability-static-accessed-through-instance.cpp
@@ -220,3 +220,31 @@
   qp->y = 10; // OK, the overloaded operator might have side-effects.
   qp->K = 10; //
 }
+
+namespace {
+  struct Anonymous {
+static int I;
+  };
+}
+
+void use_anonymous() {
+  Anonymous Anon;
+  Anon.I;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: static member
+  // CHECK-FIXES: {{^}}  Anonymous::I;{{$}}
+}
+
+namespace Outer {
+  inline namespace Inline {
+struct S {
+  static int I;
+};
+  }
+}
+
+void use_inline() {
+  Outer::S V;
+  V.I;
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: static member
+  // CHECK-FIXES: {{^}}  Outer::S::I;{{$}}
+}
Index: clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
===
--- clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
+++ clang-tools-extra/clang-tidy/readability/StaticAccessedThroughInstanceCheck.cpp
@@ -67,6 +67,7 @@
   const ASTContext *AstContext = Result.Context;
   PrintingPolicy PrintingPolicyWithSupressedTag(AstContext->getLangOpts());
   PrintingPolicyWithSupressedTag.SuppressTagKeyword = true;
+  PrintingPolicyWithSupressedTag.SuppressUnwrittenScope = true;
   std::string BaseTypeName =
   BaseType.getAsString(PrintingPolicyWithSupressedTag);
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61827: [clang-tidy] modernize-loop-convert: impl const cast iter

[Don Hinton via Phabricator via cfe-commits]

hintonda accepted this revision.
hintonda added a comment.
This revision is now accepted and ready to land.

Awesome, thanks...

LGTM, but you may want to give @alexfh or @aaron.ballman a day to comment 
before you commit.


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

https://reviews.llvm.org/D61827



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

[PATCH] D61749: [clang-tidy] initial version of readability-static-const-method

[Matthias Gehre via Phabricator via cfe-commits]

mgehre updated this revision to Diff 199329.
mgehre marked an inline comment as done.
mgehre added a comment.

Remove ``const`` part from this PR. Address comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61749

Files:
  clang-tools-extra/clang-tidy/readability/CMakeLists.txt
  clang-tools-extra/clang-tidy/readability/ReadabilityTidyModule.cpp
  clang-tools-extra/clang-tidy/readability/StaticMethodCheck.cpp
  clang-tools-extra/clang-tidy/readability/StaticMethodCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/readability-static-method.rst
  clang-tools-extra/test/clang-tidy/readability-static-method.cpp

Index: clang-tools-extra/test/clang-tidy/readability-static-method.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/readability-static-method.cpp
@@ -0,0 +1,174 @@
+// RUN: %check_clang_tidy %s readability-static-method %t
+
+class DoNotMakeEmptyStatic {
+  void emptyMethod() {}
+  void empty_method_out_of_line();
+};
+
+void DoNotMakeEmptyStatic::empty_method_out_of_line() {}
+
+class A {
+  int field;
+  const int const_field;
+  static int static_field;
+
+  void no_use() {
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: method 'no_use' can be made static
+// CHECK-FIXES: {{^}}  static void no_use() {
+int i = 1;
+  }
+
+  int read_field() {
+return field;
+  }
+
+  void write_field() {
+field = 1;
+  }
+
+  int call_non_const_member() { return read_field(); }
+
+  int call_static_member() {
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: method 'call_static_member' can be made static
+// CHECK-FIXES: {{^}}  static int call_static_member() {
+already_static();
+  }
+
+  int read_static() {
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: method 'read_static' can be made static
+// CHECK-FIXES: {{^}}  static int read_static() {
+return static_field;
+  }
+  void write_static() {
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: method 'write_static' can be made static
+// CHECK-FIXES: {{^}}  static void write_static() {
+static_field = 1;
+  }
+
+  static int already_static() { return static_field; }
+
+  int already_const() const { return field; }
+
+  int already_const_convert_to_static() const {
+// CHECK-MESSAGES: :[[@LINE-1]]:7: warning: method 'already_const_convert_to_static' can be made static
+// CHECK-FIXES: {{^}}  static int already_const_convert_to_static() {
+return static_field;
+  }
+
+  static int out_of_line_already_static();
+
+  void out_of_line_call_static();
+  // CHECK-FIXES: {{^}}  static void out_of_line_call_static();
+  int out_of_line_const_to_static() const;
+  // CHECK-FIXES: {{^}}  static int out_of_line_const_to_static() ;
+};
+
+int A::out_of_line_already_static() { return 0; }
+
+void A::out_of_line_call_static() {
+  // CHECK-MESSAGES: :[[@LINE-1]]:9: warning: method 'out_of_line_call_static' can be made static
+  // CHECK-FIXES: {{^}}void A::out_of_line_call_static() {
+  already_static();
+}
+
+int A::out_of_line_const_to_static() const {
+  // CHECK-MESSAGES: :[[@LINE-1]]:8: warning: method 'out_of_line_const_to_static' can be made static
+  // CHECK-FIXES: {{^}}int A::out_of_line_const_to_static() {
+  return 0;
+}
+
+struct KeepVirtual {
+  virtual int f() { return 0; }
+  virtual int h() const { return 0; }
+};
+
+struct KeepVirtualDerived : public KeepVirtual {
+  int f() { return 0; }
+  int h() const override { return 0; }
+};
+
+// Don't add 'static' to special member functions and operators.
+struct KeepSpecial {
+  KeepSpecial() { int L = 0; }
+  ~KeepSpecial() { int L = 0; }
+  int operator+() { return 0; }
+  operator int() { return 0; }
+};
+
+void KeepLambdas() {
+  auto F = +[]() { return 0; };
+  auto F2 = []() { return 0; };
+}
+
+template 
+struct KeepWithTemplateBase : public Base {
+  int i;
+  // We cannot make these methods static because they might need to override
+  // a function from Base.
+  int static_f() { return 0; }
+};
+
+template 
+struct KeepTemplateClass {
+  int i;
+  // We cannot make these methods static because a specialization
+  // might use *this differently.
+  int static_f() { return 0; }
+};
+
+struct KeepTemplateMethod {
+  int i;
+  // We cannot make these methods static because a specialization
+  // might use *this differently.
+  template 
+  static int static_f() { return 0; }
+};
+
+void instantiate() {
+  struct S {};
+  KeepWithTemplateBase I1;
+  I1.static_f();
+
+  KeepTemplateClass I2;
+  I2.static_f();
+
+  KeepTemplateMethod I3;
+  I3.static_f();
+}
+
+struct TrailingReturn {
+  auto g() const -> int {
+// CHECK-MESSAGES: :[[@LINE-1]]:8: warning: method 'g' can be made static
+// CHECK-FIXES: {{^}}  static auto g() -> int {
+return 0;
+  }
+};
+
+struct NoFixitInMacro {
+#define CONST 

[PATCH] D61749: [clang-tidy] initial version of readability-static-const-method

[Matthias Gehre via Phabricator via cfe-commits]

mgehre marked 17 inline comments as done.
mgehre added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/readability-static-const-method.cpp:312
+return const_cast(this)->get();
+  }
+

JonasToth wrote:
> mgehre wrote:
> > JonasToth wrote:
> > > I think more template tests wouldn't hurt. From the other checks 
> > > experience I can safely say we got burned a few times :)
> > > Instantiating the templates with builtin arrays, pointers, references and 
> > > different qualifiers usually produces interesting test cases as well, 
> > > that need to be handled properly.
> > > 
> > > Another thing that comes to mind with templates are overloaded operators.
> > > ```
> > > template 
> > > void bar() {
> > >  Foo x1, x2;
> > >  Foo y = x1 + x2;
> > > }
> > > ```
> > > Builtins are not changed by `operator+` but that can not be said about 
> > > other types in general (maybe with concepts used properly).
> > The check only checks templates instantiations (so we will see no template 
> > parameters, just ordinary types). The plus here will be be function call in 
> > the AST of the instantiation when Foo has an overloaded operator+.
> > The current version will never propose to make bar() const when a method on 
> > `this` is called.
> > I can add the test to show this.
> Yes please add a test to show they are not analyzed.
I will now restrict this PR to the `static` part of the check, and I fail to 
come up with an example where operators could make a static looking function 
non-static.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61749



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

[PATCH] D61765: [OpenMP][Clang][BugFix] Split declares and math functions inclusion.

[Artem Belevich via Phabricator via cfe-commits]

tra accepted this revision.
tra added a comment.
This revision is now accepted and ready to land.

In D61765#1500457 , @gtbercea wrote:

> This won't affect CUDA in any way, all we have added is OpenMP specific.


LGTM for CUDA. I'll leave the question of testing with libc++ to someone more 
familiar with OpenMP.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61765



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

[PATCH] D61765: [OpenMP][Clang][BugFix] Split declares and math functions inclusion.

[Johannes Doerfert via Phabricator via cfe-commits]

jdoerfert added a comment.

In D61765#1500351 , @gtbercea wrote:

> - Exclude clock functions. Reverse inclusion order.


LGTM from my side. I don't have strong feelings about testing libc++ now, 
though it is probably a good idea to have such a testbed.
I agree this should not infer with CUDA (at least that is our intention).

P.S.
There will be a ticket to add the OpenMP variant support we need (similar to 
the `__device__` in CUDA) will be written by Tom Scogland and me for a first 
vote already in this meeting.
That is what we will then need to implement.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61765



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

[PATCH] D57922: [analyzer] Insert checker options into AnalyzerOption::ConfigTable

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added inline comments.



Comment at: lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp:314
 insertOptionToCollection(StringRef FullName, T ,
- const CheckerRegistry::CmdLineOption &) {
+ const CheckerRegistry::CmdLineOption &,
+ AnalyzerOptions ) {

Mmm, const rvalue reference? Is this even a thing?



Comment at: lib/StaticAnalyzer/Frontend/CheckerRegistry.cpp:331
 insertOptionToCollection(CheckerOptEntry.first, Checkers,
- std::move(CheckerOptEntry.second));
+ std::move(CheckerOptEntry.second), AnOpts);
   }

Wait, how did you manage to move from a `const &`?

This type doesn't look very move-friendly in general.



Comment at: test/Analysis/analyzer-config.c:1
 // RUN: %clang_analyze_cc1 -triple x86_64-apple-darwin10 %s -o /dev/null 
-analyzer-checker=core,osx.cocoa,debug.ConfigDumper -analyzer-max-loop 34 > %t 
2>&1
 // RUN: FileCheck --input-file=%t %s --match-full-lines

If i understand correctly, you should be able to simplify this line 
dramatically.


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

https://reviews.llvm.org/D57922



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

[PATCH] D59465: [analyzer] Add a test plugin for checker option handling

[Artem Dergachev via Phabricator via cfe-commits]

NoQ accepted this revision.
NoQ added a comment.

I don't see any problems with adding more tests.


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

https://reviews.llvm.org/D59465



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

[PATCH] D61804: Support building shared and static libraries simultaneously

[Wink Saville via Phabricator via cfe-commits]

winksaville added a comment.

In D61804#1500445 , @winksaville wrote:

> In D61804#1500409 , @beanz wrote:
>
> > My change should not have decreased build time from trunk, nor should it 
> > have reduced the number of build steps. That patch should generate 
> > lib/libClang_shared.so, which will export the C++ API. libClang is 
> > unchanged since changing it would break existing clients of the library.
>
>
> OK, I'll look into what I've done wrong. If you see anything or have any 
> guesses please let me know.


I found my mistake that caused the speed up, I'd aborted a previous build so 
ninja started where it left off, just as should :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61804



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

[PATCH] D59464: [analyzer] Add an example plugin for checker dependency handling

[Artem Dergachev via Phabricator via cfe-commits]

NoQ accepted this revision.
NoQ added a comment.
This revision is now accepted and ready to land.

I can't say "no" to more tests.


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

https://reviews.llvm.org/D59464



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

[PATCH] D61839: [analyzer][WIP] Hide developer-only checker/package options by default

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

In D57858#1499414 , @Szelethus wrote:

> Checker options are a different kind of animal entirely. I think we should 
> definitely let the user fine-tune some modeling checkers, for instance, 
> `unix.DynamicMemoryModeling:Optimistic`, despite us not really wanting to let 
>  anyone (even developers really) mess around whether 
> `unix.DynamicMemoryModeling` should be enabled.


Hmm, great point!

In D57858#1499414 , @Szelethus wrote:

> I am not really confident about osx checkers


Let's hide `CheckOSObject` and unhide the rest. Hmm, Devin also mentioned that 
some help texts are also not user-friendly-enough (eg., the localization 
checker help with `SymRegion`s and stuff), let's also hide this one.

In D57858#1499414 , @Szelethus wrote:

> I can see valid uses for the rest of the options, but I might not be strict 
> enough on this


I think `debug.AnalysisOrder` options are worth hiding. Let's also hide the 
`Optimistic` Malloc Checker, it's clearly alpha. Probably hide alpha checker 
options if we hide alpha checkers (i.e., Clone Checker).


Repository:
  rC Clang

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

https://reviews.llvm.org/D61839



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

[PATCH] D61827: [clang-tidy] modernize-loop-convert: impl const cast iter

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

Sounds good, thank you!




Comment at: 
clang-tools-extra/docs/clang-tidy/checks/modernize-loop-convert.rst:262
+not been used on code with a compatibility requirements of OpenMP prior to
+version 5.

I would add a cross-reference to `NOLINT` documentation,
and a mention that the check **intentionally** makes no attempt
to prevent issuing these diagnostics for OpenMP loops.


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

https://reviews.llvm.org/D61827



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

[PATCH] D61827: [clang-tidy] modernize-loop-convert: impl const cast iter

[Torbjörn Klatt via Phabricator via cfe-commits]

torbjoernk updated this revision to Diff 199326.
torbjoernk edited the summary of this revision.
torbjoernk added a comment.
Herald added subscribers: jdoerfert, jfb.

Fixed the issues pointed out by Don Hinton and added note on OpenMP to the 
check's docs as suggested by Roman Lebedev.

Also fixed a small typo in a comment within the tests.

Side note: Somehow, the various failing tests I had previously where due to the 
fact that `make check-clang-tools` was picking my system-installed clang-tidy-8 
and not the one I was building... o.O


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

https://reviews.llvm.org/D61827

Files:
  clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
  clang-tools-extra/docs/clang-tidy/checks/modernize-loop-convert.rst
  clang-tools-extra/test/clang-tidy/modernize-loop-convert-basic.cpp
  clang-tools-extra/test/clang-tidy/modernize-loop-convert-extra.cpp

Index: clang-tools-extra/test/clang-tidy/modernize-loop-convert-extra.cpp
===
--- clang-tools-extra/test/clang-tidy/modernize-loop-convert-extra.cpp
+++ clang-tools-extra/test/clang-tidy/modernize-loop-convert-extra.cpp
@@ -776,17 +776,20 @@
   // CHECK-FIXES: for (auto P : *Ps)
   // CHECK-FIXES-NEXT: printf("s has value %d\n", P.X);
 
-  // V.begin() returns a user-defined type 'iterator' which, since it's
-  // different from const_iterator, disqualifies these loops from
-  // transformation.
   dependent V;
   for (dependent::const_iterator It = V.begin(); It != V.end(); ++It) {
 printf("Fibonacci number is %d\n", *It);
   }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (int It : V)
+  // CHECK-FIXES-NEXT: printf("Fibonacci number is %d\n", It);
 
   for (dependent::const_iterator It(V.begin()); It != V.end(); ++It) {
 printf("Fibonacci number is %d\n", *It);
   }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (int It : V)
+  // CHECK-FIXES-NEXT: printf("Fibonacci number is %d\n", It);
 }
 
 } // namespace SingleIterator
@@ -991,18 +994,26 @@
   // CHECK-FIXES: for (int & I : Dep)
   // CHECK-FIXES-NEXT: auto H2 = [&]() { int R = I + 2; };
 
-  // FIXME: It doesn't work with const iterators.
   for (dependent::const_iterator I = Dep.begin(), E = Dep.end();
I != E; ++I)
 auto H3 = [I]() { int R = *I; };
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (int I : Dep)
+  // CHECK-FIXES-NEXT: auto H3 = []() { int R = I; };
 
   for (dependent::const_iterator I = Dep.begin(), E = Dep.end();
I != E; ++I)
 auto H4 = [&]() { int R = *I + 1; };
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (int I : Dep)
+  // CHECK-FIXES-NEXT: auto H4 = [&]() { int R = I + 1; };
 
   for (dependent::const_iterator I = Dep.begin(), E = Dep.end();
I != E; ++I)
 auto H5 = [=]() { int R = *I; };
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (int R : Dep)
+  // CHECK-FIXES-NEXT: auto H5 = [=]() { };
 }
 
 void captureByValue() {
Index: clang-tools-extra/test/clang-tidy/modernize-loop-convert-basic.cpp
===
--- clang-tools-extra/test/clang-tidy/modernize-loop-convert-basic.cpp
+++ clang-tools-extra/test/clang-tidy/modernize-loop-convert-basic.cpp
@@ -369,7 +369,7 @@
 // CHECK-FIXES: for (auto Val_int_ptr : Val_int_ptrs)
   }
 
-  // This container uses an iterator where the derefence type is a typedef of
+  // This container uses an iterator where the dereference type is a typedef of
   // a reference type. Make sure non-const auto & is still used. A failure here
   // means canonical types aren't being tested.
   {
@@ -431,19 +431,22 @@
   // CHECK-FIXES: for (auto P : *Ps)
   // CHECK-FIXES-NEXT: printf("s has value %d\n", P.X);
 
-  // V.begin() returns a user-defined type 'iterator' which, since it's
-  // different from const_iterator, disqualifies these loops from
-  // transformation.
   dependent V;
   for (dependent::const_iterator It = V.begin(), E = V.end();
It != E; ++It) {
 printf("Fibonacci number is %d\n", *It);
   }
+  // CHECK-MESSAGES: :[[@LINE-4]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (int It : V)
+  // CHECK-FIXES-NEXT: printf("Fibonacci number is %d\n", It);
 
   for (dependent::const_iterator It(V.begin()), E = V.end();
It != E; ++It) {
 printf("Fibonacci number is %d\n", *It);
   }
+  // CHECK-MESSAGES: :[[@LINE-4]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES: for (int It : V)
+  // CHECK-FIXES-NEXT: printf("Fibonacci number is %d\n", It);
 }
 
 // Tests to ensure that an implicit 'this' is picked up as the container.
Index: 

[PATCH] D61742: [Driver][Windows] Add dependent lib argument for profile instr generate

[Reid Kleckner via Phabricator via cfe-commits]

rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.

lgtm


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

https://reviews.llvm.org/D61742



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

[PATCH] D60910: [WIP] Dumping the AST to JSON

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D60910#1495673 , @rsmith wrote:

> If you're happy with these two conditions, then I have no concerns with this 
> moving forward:
>
> - There is no implied stability for the content or format of the dump between 
> major releases, other than that it be valid JSON; this should be stated 
> explicitly in the documentation. (Compatibility between patch releases seems 
> like something we can work out with the release manager, but I'm inclined to 
> say we should make a best-effort attempt to preserve it.) If people want to 
> build tools on this rather than on one of our stable APIs, they should expect 
> to be broken in some way on every major release.
> - There is no requirement for people maintaining the AST (changing or adding 
> AST nodes) to update the dump output for modified AST nodes to show any new 
> information -- unlike the existing -ast-dump, this is not just for debugging, 
> but we should be able to treat it as if it were. Perhaps a better way to put 
> it: there is no requirement that the information in this dump is complete, 
> but the information that is dumped should be correct.
>
>   If you want stronger guarantees than that, then we should have a broader 
> discussion to establish some community buy-in.


Both of these conditions make a lot of sense and we're happy with them. I'll 
update the documentation accordingly as I land the initial patch. Thanks!




Comment at: include/clang/AST/DeclBase.h:1139
+  void dump(raw_ostream , bool Deserialize = false,
+ASTDumpOutputFormat OutputFormat = ADOF_Default) const;
 

steveire wrote:
> aaron.ballman wrote:
> > steveire wrote:
> > > I think we've talked about this before, but I don't think growing 
> > > interfaces like this is the best way forward. An enum is a less-good 
> > > replacement for an object (ie making the user of the API responsible for 
> > > creating the dumper they want to use).
> > > 
> > > I think that could be made more convenient in the future. What do you 
> > > think?
> > I think that may be a good future improvement, yes.
> > 
> > One thing to take on balance when considering this for the future is that 
> > `dump()` can be called from within a debugger and that's a bit harder to 
> > accomplish with an object interface. I'm not certain that will be a big 
> > issue for my use case, but it may matter to some folks.
> I don't think "it may matter to some folks." is a good guideline to use when 
> designing an API. I have a patch which moves ASTDumper to its own header 
> which I have just uploaded here: https://reviews.llvm.org/D61835
> 
> If additional args to `dump()` are mainly for debugging, then adding new args 
> which are not for debugging doesn't seem right. 
The status quo is that we want `dump()` to be a function; changing that to use 
a different interface is certainly worth discussing. However, I'm opposed to 
trying to do that refactoring at the same time as I'm trying to land this 
functionality. I would recommend we land this initial patch first, then if we 
decide to refactor the `dump()` interface, do that in subsequent reviews.


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

https://reviews.llvm.org/D60910



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

[PATCH] D60163: [ThinLTO] Handle -fno-builtin* options for distributed backends

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson abandoned this revision.
tejohnson added a comment.

The parent revision now includes both clang and llvm side changes.


Repository:
  rC Clang

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

https://reviews.llvm.org/D60163



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

[PATCH] D60910: [WIP] Dumping the AST to JSON

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman updated this revision to Diff 199316.
aaron.ballman marked 2 inline comments as done.
aaron.ballman added a comment.

Switched to using the JSON streaming interface rather than a custom solution
Updated the test cases for the new formatting


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

https://reviews.llvm.org/D60910

Files:
  include/clang/AST/ASTDumperUtils.h
  include/clang/AST/DeclBase.h
  include/clang/AST/JSONNodeDumper.h
  include/clang/Driver/CC1Options.td
  include/clang/Frontend/ASTConsumers.h
  include/clang/Frontend/FrontendOptions.h
  lib/AST/ASTDumper.cpp
  lib/AST/CMakeLists.txt
  lib/AST/JSONNodeDumper.cpp
  lib/Frontend/ASTConsumers.cpp
  lib/Frontend/CompilerInvocation.cpp
  lib/Frontend/FrontendActions.cpp
  test/AST/ast-dump-enum-json.cpp
  test/AST/ast-dump-if-json.cpp
  test/AST/ast-dump-namespace-json.cpp
  tools/clang-check/ClangCheck.cpp
  tools/clang-import-test/clang-import-test.cpp

Index: tools/clang-import-test/clang-import-test.cpp
===
--- tools/clang-import-test/clang-import-test.cpp
+++ tools/clang-import-test/clang-import-test.cpp
@@ -316,8 +316,9 @@
   auto  = *static_cast(ASTConsumers.back().get());
 
   if (ShouldDumpAST)
-ASTConsumers.push_back(CreateASTDumper(nullptr /*Dump to stdout.*/,
-   "", true, false, false));
+ASTConsumers.push_back(
+CreateASTDumper(nullptr /*Dump to stdout.*/, "", true, false, false,
+clang::ADOF_Default));
 
   CI.getDiagnosticClient().BeginSourceFile(
   CI.getCompilerInstance().getLangOpts(),
Index: tools/clang-check/ClangCheck.cpp
===
--- tools/clang-check/ClangCheck.cpp
+++ tools/clang-check/ClangCheck.cpp
@@ -134,11 +134,11 @@
 if (ASTList)
   return clang::CreateASTDeclNodeLister();
 if (ASTDump)
-  return clang::CreateASTDumper(nullptr /*Dump to stdout.*/,
-ASTDumpFilter,
+  return clang::CreateASTDumper(nullptr /*Dump to stdout.*/, ASTDumpFilter,
 /*DumpDecls=*/true,
 /*Deserialize=*/false,
-/*DumpLookups=*/false);
+/*DumpLookups=*/false,
+clang::ADOF_Default);
 if (ASTPrint)
   return clang::CreateASTPrinter(nullptr, ASTDumpFilter);
 return llvm::make_unique();
Index: test/AST/ast-dump-namespace-json.cpp
===
--- test/AST/ast-dump-namespace-json.cpp
+++ test/AST/ast-dump-namespace-json.cpp
@@ -0,0 +1,211 @@
+// RUN: %clang_cc1 -triple x86_64-pc-linux -std=c++2a -ast-dump=json %s | FileCheck %s
+
+namespace foo {
+}
+// CHECK: "kind": "NamespaceDecl",
+// CHECK-NEXT: "loc": {
+// CHECK-NEXT: "col": 11,
+// CHECK-NEXT: "file": "{{.*}}",
+// CHECK-NEXT: "line": 3
+// CHECK-NEXT: },
+// CHECK-NEXT: "range": {
+// CHECK-NEXT: "begin": {
+// CHECK-NEXT: "col": 1,
+// CHECK-NEXT: "file": "{{.*}}",
+// CHECK-NEXT: "line": 3
+// CHECK-NEXT: },
+// CHECK-NEXT: "end": {
+// CHECK-NEXT: "col": 1,
+// CHECK-NEXT: "file": "{{.*}}",
+// CHECK-NEXT: "line": 4
+// CHECK-NEXT: }
+// CHECK-NEXT: },
+// CHECK-NEXT: "name": "foo"
+// CHECK-NEXT: },
+
+
+namespace {
+}
+// CHECK: "kind": "NamespaceDecl",
+// CHECK-NEXT: "loc": {
+// CHECK-NEXT: "col": 11,
+// CHECK-NEXT: "file": "{{.*}}",
+// CHECK-NEXT: "line": 27
+// CHECK-NEXT: },
+// CHECK-NEXT: "range": {
+// CHECK-NEXT: "begin": {
+// CHECK-NEXT: "col": 1,
+// CHECK-NEXT: "file": "{{.*}}",
+// CHECK-NEXT: "line": 27
+// CHECK-NEXT: },
+// CHECK-NEXT: "end": {
+// CHECK-NEXT: "col": 1,
+// CHECK-NEXT: "file": "{{.*}}",
+// CHECK-NEXT: "line": 28
+// CHECK-NEXT: }
+// CHECK-NEXT: }
+// CHECK-NEXT: },
+// CHECK-NEXT: {
+// CHECK-NEXT: "id": "0x{{.*}}",
+// CHECK-NEXT: "kind": "UsingDirectiveDecl",
+// CHECK-NEXT: "loc": {},
+// CHECK-NEXT: "range": {
+// CHECK-NEXT: "begin": {
+// CHECK-NEXT: "col": 11,
+// CHECK-NEXT: "file": "{{.*}}",
+// CHECK-NEXT: "line": 27
+// CHECK-NEXT: },
+// CHECK-NEXT: "end": {}
+// CHECK-NEXT: },
+// CHECK-NEXT: "isImplicit": true,
+// CHECK-NEXT: "nominatedNamespace": {
+// CHECK-NEXT: "id": "0x{{.*}}",
+// CHECK-NEXT: "kind": "NamespaceDecl",
+// CHECK-NEXT: "name": ""
+// CHECK-NEXT: }
+// CHECK-NEXT: },
+
+namespace bar {
+inline namespace __1 {
+}
+}
+// CHECK: "kind": "NamespaceDecl",
+// CHECK-NEXT: "loc": {
+// CHECK-NEXT: "col": 11,
+// CHECK-NEXT: "file": "{{.*}}",
+// CHECK-NEXT: "line": 68
+// CHECK-NEXT: },
+// CHECK-NEXT: "range": {
+// CHECK-NEXT: "begin": {
+// CHECK-NEXT: "col": 1,
+// CHECK-NEXT: "file": "{{.*}}",
+// CHECK-NEXT: "line": 68
+// CHECK-NEXT: },
+// CHECK-NEXT: "end": {
+// CHECK-NEXT: "col": 1,
+// CHECK-NEXT: "file": "{{.*}}",
+// CHECK-NEXT: "line": 71
+// CHECK-NEXT: }
+// CHECK-NEXT: 

[PATCH] D60162: [ThinLTO] Support TargetLibraryInfoImpl in the backend

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson added a comment.

In D60162#1498392 , @tejohnson wrote:

> In D60162#1498288 , @tejohnson wrote:
>
> > Working on this one again as it previously wasn't causing any issues but 
> > just now got exposed in multiple places and started causing correctness 
> > issues. Two questions:
> >
> > 1. What should be the behavior when merging modules e.g. for LTO. I'm 
> > thinking of the following, with multiple module flags to specify different 
> > aspects: a) For the NoBuiltinFuncs I'm thinking of a module flag containing 
> > the list of strings, with AppendUnique merging behavior, so we get a 
> > superset in the merged module b) For the flag to disable all builtins, have 
> > a separate module flag with a Max merge (so we get the most conservative 
> > behavior) c) For the VectorLibrary, not sure - should it be an Error to 
> > merge modules with different libraries?
> > 2. While we get the above hammered out, would it be ok to submit this one 
> > (and companion clang change) to fix the bug (then remove when the module 
> > flags are added)?
>
>
> Weird, phabricator added numbering to all of my bullets, which formatted very 
> differently than intended. Modified the above a bit to hopefully format 
> better (2 high level questions, and some subquestions on the first one).


I went ahead and implemented the above approach, PTAL. I added test cases for 
ensuring that the various clang driver flags set up the module flags properly, 
that merging behaves as expected, and that these options correctly affect LTO 
backends.

Note that this patch now includes both clang and llvm changes. I am going to 
mark the old clang child patch as obsolete.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60162



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

[PATCH] D60162: [ThinLTO] Support TargetLibraryInfoImpl in the backend

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson updated this revision to Diff 199320.
tejohnson added a comment.
Herald added subscribers: cfe-commits, hiraditya, eraman.
Herald added a project: clang.

Rework using module flags.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60162

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/nobuiltins.c
  clang/test/CodeGen/svml-calls.ll
  clang/test/CodeGen/thinlto_backend_nobuiltin.ll
  clang/test/CodeGen/thinlto_backend_nobuiltin_memset.ll
  clang/test/CodeGen/veclib-calls.ll
  clang/test/CodeGen/veclib.c
  llvm/lib/LTO/LTOBackend.cpp

Index: llvm/lib/LTO/LTOBackend.cpp
===
--- llvm/lib/LTO/LTOBackend.cpp
+++ llvm/lib/LTO/LTOBackend.cpp
@@ -218,6 +218,34 @@
   // FIXME (davide): verify the output.
 }
 
+static TargetLibraryInfoImpl *createTLII(Module , TargetMachine *TM) {
+  TargetLibraryInfoImpl *TLII =
+  new TargetLibraryInfoImpl(Triple(TM->getTargetTriple()));
+  if (auto *MD = mdconst::extract_or_null(
+  Mod.getModuleFlag("DisableAllBuiltins"))) {
+if (MD->getZExtValue())
+  TLII->disableAllFunctions();
+  } else if (Metadata *Val = Mod.getModuleFlag("NoBuiltins")) {
+// Disable individual libc/libm calls in TargetLibraryInfo.
+LibFunc F;
+for (const MDOperand  : cast(Val)->operands())
+  if (TLII->getLibFunc(cast(*FuncName).getString(), F))
+TLII->setUnavailable(F);
+  }
+
+  if (MDString *VL =
+  dyn_cast_or_null(Mod.getModuleFlag("VectorLibrary"))) {
+if (VL->getString() == "Accelerate")
+  TLII->addVectorizableFunctionsFromVecLib(
+  TargetLibraryInfoImpl::Accelerate);
+else if (VL->getString() == "SVML")
+  TLII->addVectorizableFunctionsFromVecLib(TargetLibraryInfoImpl::SVML);
+else
+  llvm_unreachable("Invalid vector library module flag");
+  }
+  return TLII;
+}
+
 static void runNewPMCustomPasses(Module , TargetMachine *TM,
  std::string PipelineDesc,
  std::string AAPipelineDesc,
@@ -239,6 +267,10 @@
   // Register the AA manager first so that our version is the one used.
   FAM.registerPass([&] { return std::move(AA); });
 
+  std::unique_ptr TLII(createTLII(Mod, TM));
+  FAM.registerPass([&] { return TargetLibraryAnalysis(*TLII); });
+  MAM.registerPass([&] { return TargetLibraryAnalysis(*TLII); });
+
   // Register all the basic analyses with the managers.
   PB.registerModuleAnalyses(MAM);
   PB.registerCGSCCAnalyses(CGAM);
@@ -268,7 +300,7 @@
   passes.add(createTargetTransformInfoWrapperPass(TM->getTargetIRAnalysis()));
 
   PassManagerBuilder PMB;
-  PMB.LibraryInfo = new TargetLibraryInfoImpl(Triple(TM->getTargetTriple()));
+  PMB.LibraryInfo = createTLII(Mod, TM);
   PMB.Inliner = createFunctionInliningPass();
   PMB.ExportSummary = ExportSummary;
   PMB.ImportSummary = ImportSummary;
Index: clang/test/CodeGen/veclib.c
===
--- /dev/null
+++ clang/test/CodeGen/veclib.c
@@ -0,0 +1,21 @@
+// RUN: %clang_cc1 -emit-llvm -fveclib=Accelerate %s -o - | FileCheck %s -check-prefix=ACCELERATE
+// RUN: %clang_cc1 -emit-llvm -fveclib=SVML %s -o - | FileCheck %s -check-prefix=SVML
+// RUN: %clang_cc1 -emit-llvm -fveclib=none %s -o - | FileCheck %s -check-prefix=NONE
+// RUN: %clang_cc1 -emit-llvm %s -o - | FileCheck %s -check-prefix=NONE
+
+// ACCELERATE: !{{[0-9]+}} = !{i32 1, !"VectorLibrary", !"Accelerate"}
+// SVML: !{{[0-9]+}} = !{i32 1, !"VectorLibrary", !"SVML"}
+// NONE-NOT: VectorLibrary
+
+// Now ensure merging gets the expected behavior
+// RUN: %clang -c -flto %s -o %t0.o
+// RUN: %clang -c -flto -fveclib=Accelerate %s -o %t1.o
+// RUN: %clang -c -flto -fveclib=SVML %s -o %t2.o
+// Merge none with -fveclib=Accelerate -> VectorLibrary=Accelerate
+// RUN: llvm-lto %t0.o %t1.o -o %t3.o -save-merged-module
+// RUN: llvm-dis %t3.o.merged.bc -o - | FileCheck %s --check-prefix=ACCELERATE
+// Merge none with -fveclib=SVML -> VectorLibrary=SVML
+// RUN: llvm-lto %t0.o %t2.o -o %t3.o -save-merged-module
+// RUN: llvm-dis %t3.o.merged.bc -o - | FileCheck %s --check-prefix=SVML
+// Merge -fveclib=Accelerate with -fveclib=SVML -> Error
+// RUN: not llvm-lto %t1.o %t2.o -o %t3.o -save-merged-module
Index: clang/test/CodeGen/veclib-calls.ll
===
--- /dev/null
+++ clang/test/CodeGen/veclib-calls.ll
@@ -0,0 +1,38 @@
+; Test to ensure that -fveclib=Accelerate module flag is handled properly in
+; the ThinLTO distributed backend.
+
+; RUN: opt -module-summary -o %t.o %s
+; RUN: llvm-lto -thinlto -o %t %t.o
+; RUN: %clang -target x86_64-unknown-linux-gnu -O3 -o %t2.o -x ir %t.o -c -fthinlto-index=%t.thinlto.bc -save-temps=obj
+; RUN: llvm-dis %t.s.4.opt.bc -o - | FileCheck %s
+
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"
+target triple = 

[PATCH] D61765: [OpenMP][Clang][BugFix] Split declares and math functions inclusion.

[Gheorghe-Teodor Bercea via Phabricator via cfe-commits]

gtbercea added a comment.

In D61765#1500446 , @tra wrote:

> In D61765#1500309 , @gtbercea wrote:
>
> > As soon as libc++ the limits header included in
> >
> >   __clang_cuda_cmath.h:15
> >   ``` is not found:
> >  
> >  
> >
> >
> > __clang_cuda_cmath.h:15:10: fatal error: 'limits' file not found
> >  #include 
> >
> >   Not even CUDA works actually so I'm not sure what the best answer to this 
> > problem is.
>
>
> Could you give me more details on how you've got this error?
>
> If this change breaks CUDA compilation with libc++, that's going to be a 
> problem. Currently CUDA and clang's headers we ship do work with both libc++ 
> and few versions of libstdc++:
>  E.g: 
> http://lab.llvm.org:8011/builders/clang-cuda-build/builds/33364/steps/ninja%20build%20simple%20CUDA%20tests/logs/stdio


This won't affect CUDA in any way, all we have added is OpenMP specific.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61765



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

[PATCH] D61765: [OpenMP][Clang][BugFix] Split declares and math functions inclusion.

[Gheorghe-Teodor Bercea via Phabricator via cfe-commits]

gtbercea added a comment.

In D61765#1500446 , @tra wrote:

> In D61765#1500309 , @gtbercea wrote:
>
> > As soon as libc++ the limits header included in
> >
> >   __clang_cuda_cmath.h:15
> >   ``` is not found:
> >  
> >  
> >
> >
> > __clang_cuda_cmath.h:15:10: fatal error: 'limits' file not found
> >  #include 
> >
> >   Not even CUDA works actually so I'm not sure what the best answer to this 
> > problem is.
>
>
> Could you give me more details on how you've got this error?
>
> If this change breaks CUDA compilation with libc++, that's going to be a 
> problem. Currently CUDA and clang's headers we ship do work with both libc++ 
> and few versions of libstdc++:
>  E.g: 
> http://lab.llvm.org:8011/builders/clang-cuda-build/builds/33364/steps/ninja%20build%20simple%20CUDA%20tests/logs/stdio


It's an error on my side, I don't have libc++ installed so trying to use it 
will come up with header not found errors.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61765



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

[PATCH] D61634: [clang/llvm] Allow efficient implementation of libc's memory functions in C/C++

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a comment.

My main blocker is that I want to make sure we're moving in the right 
direction: towards LLVM IR with clear semantics, towards straightforward rules 
for writing freestanding C code, and towards solutions which behave 
appropriately for all targets.  There's clearly a problem here that's worth 
solving, but I want to make sure we're adding small features that interact with 
existing features in an obvious way.  The patch as written is adding a new 
attribute that changes the semantics of C and LLVM IR in a subtle way that 
interacts with existing optimizations and lowering in ways that are complex and 
hard to understand.

I don't want to mix general restrictions on calling C library functions, with 
restrictions that apply specifically to memcpy: clang generally works on the 
assumption that a "memcpy" symbol is available in freestanding environments, 
and we don't really want to change that.

With -fno-builtin, specifically, we currently apply the restriction that 
optimizations will not introduce memcpy calls that would not exist with 
optimization disabled.  This is sort of artificial, and and maybe a bit 
confusing, but it seems to work well enough in practice.  gcc does something 
similar.

I don't really want to add an attribute that has a different meaning from 
-fno-builtin.  An attribute that has the same meaning is a lot less 
problematic: it reduces potential confusion, and solves a related problem that 
-fno-builtin currently doesn't really work with LTO, because we don't encode it 
into the IR.

Your current patch is using the "AlwaysInline" flag for 
SelectionDAG::getMemcpy, which forces a memcpy to be lowered to an inline 
implementation.  In general, this flag is only supported for constant-size 
memcpy calls; otherwise, on targets where EmitTargetCodeForMemcpy does not have 
some special lowering, like the x86 "rep;movs", you'll hit an assertion 
failure.  And we don't really want to add an implementation of variable-length 
memcpy for a lot of targets; it's very inefficient on targets which don't have 
unaligned memory access.  You could try to narrowly fix this to only apply 
"AlwaysInline" if the size is a constant integer, but there's a related 
problem: even if a memcpy is constant size in C, optimizations don't promise to 
preserve that, in general.  We could theoretically add such a promise, I guess, 
but that's awkward: it would conditionally apply to llvm.memcpy where the 
parameter is already const, so it's not something we can easily verify.

If we added a new builtin `llvm.memcpy.inline`, or something like that, the end 
result ends up being simpler in many ways. It has obvious rules for both 
generating it and lowering it, which don't depend on attributes in the parent 
function.  We could mark the size as "immarg", so we don't have to add special 
optimization rules for it.   And if we have it, we have a "complete" solution 
for writing memcpy implementations in C: we make `__builtin_memcpy`, or a new 
`__builtin_inline_memcpy`, produce it, and it can be combined with -fno-builtin 
to ensure we don't produce any calls to the "real" memcpy.  The downside of a 
new builtin, of course, is that we now have two functions with similar 
semantics, and potentially have to fix a bunch of places to check for both of 
them.

MemCpyOpt has been mentioned (the pass which transforms memcpy-like loops into 
llvm.memcpy).  If we want it to perform some transform in circumstances where 
the call "memcpy" isn't available, we have to make sure to restrict it based on 
the target: in the worst case, on some targets without unaligned memory access, 
it could just act as a low-quality loop unroller.  This applies no matter how 
the result is actually represented in IR.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61634



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

[PATCH] D61765: [OpenMP][Clang][BugFix] Split declares and math functions inclusion.

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D61765#1500309 , @gtbercea wrote:

> As soon as libc++ the limits header included in
>
>   __clang_cuda_cmath.h:15
>   ``` is not found:
>  
>  
>
>
> __clang_cuda_cmath.h:15:10: fatal error: 'limits' file not found
>  #include 
>
>   Not even CUDA works actually so I'm not sure what the best answer to this 
> problem is.


Could you give me more details on how you've got this error?

If this change breaks CUDA compilation with libc++, that's going to be a 
problem. Currently CUDA and clang's headers we ship do work with both libc++ 
and few versions of libstdc++:
E.g: 
http://lab.llvm.org:8011/builders/clang-cuda-build/builds/33364/steps/ninja%20build%20simple%20CUDA%20tests/logs/stdio


Repository:
  rC Clang

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

https://reviews.llvm.org/D61765



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

[PATCH] D61804: Support building shared and static libraries simultaneously

[Wink Saville via Phabricator via cfe-commits]

winksaville added a comment.

In D61804#1500409 , @beanz wrote:

> My change should not have decreased build time from trunk, nor should it have 
> reduced the number of build steps. That patch should generate 
> lib/libClang_shared.so, which will export the C++ API. libClang is unchanged 
> since changing it would break existing clients of the library.


OK, I'll look into what I've done wrong. If you see anything or have any 
guesses please let me know.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61804



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

[PATCH] D61861: DeleteNullPointerCheck now deletes until the end brace of the condition

[Jonathan Camilleri via Phabricator via cfe-commits]

J-Camilleri updated this revision to Diff 199315.
J-Camilleri added a comment.

Added a new unit test and restored the modified test as it was.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61861

Files:
  clang-tools-extra/clang-tidy/readability/DeleteNullPointerCheck.cpp
  clang-tools-extra/test/clang-tidy/readability-delete-null-pointer.cpp


Index: clang-tools-extra/test/clang-tidy/readability-delete-null-pointer.cpp
===
--- clang-tools-extra/test/clang-tidy/readability-delete-null-pointer.cpp
+++ clang-tools-extra/test/clang-tidy/readability-delete-null-pointer.cpp
@@ -3,6 +3,15 @@
 #define NULL 0
 
 void f() {
+  int *ps = 0;
+  if (ps /**/) // #0
+delete ps;
+  // CHECK-MESSAGES: :[[@LINE-2]]:3: warning: 'if' statement is unnecessary; 
deleting null pointer has no effect [readability-delete-null-pointer]
+
+  // CHECK-FIXES: int *ps = 0;
+  // CHECK-FIXES-NEXT: {{^  }}// #0
+  // CHECK-FIXES-NEXT: delete ps;
+
   int *p = 0;
 
   // #1
Index: clang-tools-extra/clang-tidy/readability/DeleteNullPointerCheck.cpp
===
--- clang-tools-extra/clang-tidy/readability/DeleteNullPointerCheck.cpp
+++ clang-tools-extra/clang-tidy/readability/DeleteNullPointerCheck.cpp
@@ -7,6 +7,7 @@
 
//===--===//
 
 #include "DeleteNullPointerCheck.h"
+#include "../utils/LexerUtils.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/Lex/Lexer.h"
@@ -62,9 +63,11 @@
 
   Diag << FixItHint::CreateRemoval(CharSourceRange::getTokenRange(
   IfWithDelete->getBeginLoc(),
-  Lexer::getLocForEndOfToken(IfWithDelete->getCond()->getEndLoc(), 0,
- *Result.SourceManager,
- Result.Context->getLangOpts(;
+  utils::lexer::getPreviousToken(IfWithDelete->getThen()->getBeginLoc(),
+ *Result.SourceManager,
+ Result.Context->getLangOpts())
+  .getLocation()));
+
   if (Compound) {
 Diag << FixItHint::CreateRemoval(
 CharSourceRange::getTokenRange(Compound->getLBracLoc()));


Index: clang-tools-extra/test/clang-tidy/readability-delete-null-pointer.cpp
===
--- clang-tools-extra/test/clang-tidy/readability-delete-null-pointer.cpp
+++ clang-tools-extra/test/clang-tidy/readability-delete-null-pointer.cpp
@@ -3,6 +3,15 @@
 #define NULL 0
 
 void f() {
+  int *ps = 0;
+  if (ps /**/) // #0
+delete ps;
+  // CHECK-MESSAGES: :[[@LINE-2]]:3: warning: 'if' statement is unnecessary; deleting null pointer has no effect [readability-delete-null-pointer]
+
+  // CHECK-FIXES: int *ps = 0;
+  // CHECK-FIXES-NEXT: {{^  }}// #0
+  // CHECK-FIXES-NEXT: delete ps;
+
   int *p = 0;
 
   // #1
Index: clang-tools-extra/clang-tidy/readability/DeleteNullPointerCheck.cpp
===
--- clang-tools-extra/clang-tidy/readability/DeleteNullPointerCheck.cpp
+++ clang-tools-extra/clang-tidy/readability/DeleteNullPointerCheck.cpp
@@ -7,6 +7,7 @@
 //===--===//
 
 #include "DeleteNullPointerCheck.h"
+#include "../utils/LexerUtils.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
 #include "clang/Lex/Lexer.h"
@@ -62,9 +63,11 @@
 
   Diag << FixItHint::CreateRemoval(CharSourceRange::getTokenRange(
   IfWithDelete->getBeginLoc(),
-  Lexer::getLocForEndOfToken(IfWithDelete->getCond()->getEndLoc(), 0,
- *Result.SourceManager,
- Result.Context->getLangOpts(;
+  utils::lexer::getPreviousToken(IfWithDelete->getThen()->getBeginLoc(),
+ *Result.SourceManager,
+ Result.Context->getLangOpts())
+  .getLocation()));
+
   if (Compound) {
 Diag << FixItHint::CreateRemoval(
 CharSourceRange::getTokenRange(Compound->getLBracLoc()));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61370: Add a C2x mode and allow attributes in it

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Ping x2.


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

https://reviews.llvm.org/D61370



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

[PATCH] D58920: [Modules][PR39287] Consolidate multiple std's

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

The problem may well be that you're recursively triggering deserialization of 
the `std` namespace from its own deserialization.

In D58920#1500246 , @modocache wrote:

>   @@ -3401,6 +3402,22 @@ ASTDeclReader::FindExistingResult 
> ASTDeclReader::findExisting(NamedDecl *D) {
>  return FindExistingResult(Reader, D, Existing, 
> AnonymousDeclNumber,
>TypedefNameForLinkage);
>}
>   +if (isa(D) && D->getName() == "std") {
>   +  llvm::outs() << "Found std namespace: ";
>   +  D->dump();
>   +  llvm::outs() << "Merging into Sema std namespace: ";
>   +  Sema *S = Reader.getSema();
>   +  S->getStdNamespace()->dump();
>


You shouldn't call `getStdNamespace()` here, because that will trigger 
deserialization. You should query the `LazyDeclPtr` directly to see if there's 
an already-deserialized `std` namespace.

>   +  NamedDecl *Existing =
>   +  getDeclForMerging(S->getStdNamespace(), TypedefNameForLinkage);

(No need to call this, `std` isn't an anonymous struct.)

>   +  llvm::outs() << "Found Existing: ";
>   +  Existing->dump();
>   +  if (isSameEntity(Existing, D)) {
>   +llvm::outs() << "isSameEntity is true\n";
>   +return FindExistingResult(Reader, D, Existing, AnonymousDeclNumber,
>   +  TypedefNameForLinkage);
>   +  }
>   +}
>  } else {
>// Not in a mergeable context.
>return FindExistingResult(Reader);

You should also change `FindExistingResult::~FindExistingResult` to update 
`Sema::StdNamespace` to point to your newly-deserialized namespace if you 
didn't find a prior declaration of it, so that `Sema::getStdNamespace()` finds 
the deserialized namespace.


Repository:
  rC Clang

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

https://reviews.llvm.org/D58920



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

[PATCH] D61804: Support building shared and static libraries simultaneously

[Chris Bieneman via Phabricator via cfe-commits]

beanz added a comment.

My change should not have decreased build time from trunk, nor should it have 
reduced the number of build steps. That patch should generate 
lib/libClang_shared.so, which will export the C++ API. libClang is unchanged 
since changing it would break existing clients of the library.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61804



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

[PATCH] D24892: [clang-tidy] Add option "LiteralInitializers" to cppcoreguidelines-pro-type-member-init

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added inline comments.



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:66-69
+- Added `UseAssignment` option to `cppcoreguidelines-pro-type-member-init`
+
+  If set to true, the check will provide fix-its with literal initializers
+  (``int i = 0;``) instead of curly braces (``int i{};``).

This is in the wrong category


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D24892



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

[PATCH] D61809: [BPF] Preserve original struct/union type name/access index and array subscripts

[Yonghong Song via Phabricator via cfe-commits]

yonghong-song added a comment.

@rsmith @eli.friedman Thanks for your comments. I fully agree that it seems 
awkward that we have both GEP and intrinsic generation. I will try to do some 
experiments here to only have intrinsic generation. My only concern is possible 
performance degradation. I will post here once I got concrete implementation 
and numbers.

@rsmith regarding to your concerns about struct size change. Yes, the structure 
size may indeed change. Currently, we plan only to support field fields 
(non-struct/union type with 1/2/4/8 bytes, and strings). These are most common 
use cases. Let me explain a little bit more.

Here, we are targeting the bpf_probe_read 
(https://github.com/torvalds/linux/blob/master/include/uapi/linux/bpf.h#L532-L537)

  int bpf_probe_read(void *dst, u32 size, const void *src)

which tries to copy some data from kernel (src pointer) to the stack of the bpf 
program.

Here, if "src" points to a structure, and user intends to copy the whole 
structure out of kernel, then "size" may need to be different for different 
kernels if different kernels indeed have different structure size. 
But first, in all our use cases, users typically do not read the whole 
structure. Second, if "size" does change, we request users to use multiple 
versioning (using patchable global variables) with possibly different "size" 
values for different kernel versions. 
Note that "size" must be constant for bpf verifier to succeed.
(https://github.com/torvalds/linux/blob/master/kernel/trace/bpf_trace.c#L138-L156)

Just gave another two examples here about reading kernel memories in 
iovisor/bcc. Note that
bcc will transform certain pointer access "b->c" to "bpf_probe_read(, 
size, >c)" internally.

The bcc tool biosnoop.py contain several bpf probe read:

  https://github.com/iovisor/bcc/blob/master/tools/biosnoop.py#L110
data.len = req->__data_len;
  https://github.com/iovisor/bcc/blob/master/tools/biosnoop.py#L117
data.len = req->__data_len;
  https://github.com/iovisor/bcc/blob/master/tools/biosnoop.py#L118
data.sector = req->__sector;
  https://github.com/iovisor/bcc/blob/master/tools/biosnoop.py#L120
struct gendisk *rq_disk = req->rq_disk;
  https://github.com/iovisor/bcc/blob/master/tools/biosnoop.py#L121-L122
   bpf_probe_read(_name, sizeof(data.disk_name),
   rq_disk->disk_name);

They are all primitive types and strings.

Another example for bcc tool tcpconnect.py

  https://github.com/iovisor/bcc/blob/master/tools/tcpconnect.py#L128
u16 dport = skp->__sk_common.skc_dport;
  https://github.com/iovisor/bcc/blob/master/tools/tcpconnect.py#L136-L137
data4.saddr = skp->__sk_common.skc_rcv_saddr;
data4.daddr = skp->__sk_common.skc_daddr;

.

In summary, right now, the to-be-read kernel memory size (through a specific 
bpf_probe_read() call)
won't change between different kernel versions. So we do not need to handle 
structure allocation size change here.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61809



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

[PATCH] D61619: Make language option `GNUAsm` discoverable with `__has_extension` macro.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM!


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

https://reviews.llvm.org/D61619



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

[PATCH] D61707: [Preprocessor] Fix crash emitting note with framework location for "file not found" error.

[Volodymyr Sapsai via Phabricator via cfe-commits]

vsapsai added a comment.

Ping.


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

https://reviews.llvm.org/D61707



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

[PATCH] D24892: [clang-tidy] Add option "LiteralInitializers" to cppcoreguidelines-pro-type-member-init

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D24892#1500371 , @mgehre wrote:

> Do I wait for @alexfh to turn his red into a green, too?


I think you covered all of the concerns he raised. If he doesn't give you an LG 
in the next 24 hours, I think you can go ahead and commit. If there are 
remaining issues, we can deal with them post-commit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D24892



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

[PATCH] D61804: Support building shared and static libraries simultaneously

[Wink Saville via Phabricator via cfe-commits]

winksaville added a comment.

> Arch Linux is in an unsupported state, and your patch isn't the way forward.

OK, I'll filed a bug, https://bugs.archlinux.org/task/62624

> Let's rewind.
> 
> Why do "some people like shared libraries"? There are usually two reasons 
> people cite for linking shared libraries. One is reduced binary distribution 
> size because you're reducing duplication of code. The other, is the ability 
> to update libraries without updating tools.
> 
> The later, is not an issue here. LLVM and Clang's C++ libraries don't provide 
> any API or ABI stability guarantees across releases, so there is no way 
> you're going to reasonably update LLVM or Clang libraries without rebuilding 
> the applications using them.
> 
> The former can be valuable, but it comes at a cost. Dynamic resolution of 
> symbols slows down process launch time, and dynamic resolution of C++ 
> link-once ODRs are exceptionally slow. If you are building a compiler, 
> chances are you don't want to slow down your process launch that much. But 
> let's pretend you don't care. Your solution still isn't the right way to do 
> this.
> 
> Creating component shared libraries results in duplicating all the C++ 
> link-once ODRs across each shared module. That will not only slow down your 
> process launch, but bloat the size of your binary distribution.

Learn something new every day, thanks.

> 
> 
> In D61804#1499276 , @winksaville 
> wrote:
> 
>> It looks to me that llvm, libunwind and libcxx support building both, so the 
>> goal isn't unprecedented,
> 
> 
> This is very much an apple and oranges comparison. For one, LLVM does not 
> support generating component dylibs and shared libs. It supports generating 
> libLLVM, a single dylib containing all of the LLVM components rolled 
> together. libunwind, libcxx, libcxxabi, are runtime libraries that are 
> designed to allow static linkage, and they don't link LLVM.
> 
> I apologize that I missed your thread on the dev list, because that would 
> have been a much better place to have this conversation. Having gone back and 
> read it now, it sounds to me like what you really want is a clang equivalent 
> of libLLVM. That is a reasonable and viable thing to want. This patch 
> (https://reviews.llvm.org/P8147) is a first stab. I'm happy to prepare that 
> for landing in Clang if that meets your needs, and that is a viable way 
> forward.

Yes, as @tstellar also said, creating a single clang ".so" that exported the 
same set of symbols as the static libraries (libclang*.a) would be nice and 
probably what Arch Linux would prefer, especially if it was "officially" 
supported and was generated "simultaneously" with the static libraries.

I applied your patch to master:

  $ git log -1
  commit e5a5b7db3ac71a37af790a416486f653dbff47fb (HEAD -> master, 
origin/master, origin/HEAD)
  Author: anatolik 
  Date:   Sun May 12 19:16:54 2019 +
  
  archrelease: copy trunk to testing-x86_64
  
  git-svn-id: file:///srv/repos/svn-packages/svn@353145 
eb2447ed-0c53-47e4-bac8-5bc4a241df78

And built llvm, clang, lld and compiler-rt using:

  $ cmake ../llvm -G Ninja '-DLLVM_ENABLE_PROJECTS=clang;lld;compiler-rt' 
-DCMAKE_INSTALL_PREFIX=/home/wink/local-clang-shlib-master 
-DCMAKE_BUILD_TYPE=Release -DLLVM_BUILD_LLVM_DYLIB=ON
  $ ninja -j11 -v

I see libclang.so*:

  $ ls build-clang-shlib-master/lib/libclang.so* -al
  lrwxrwxrwx 1 wink users   16 May 13 10:49 
build-clang-shlib-master/lib/libclang.so -> libclang.so.9svn
  -rwxr-xr-x 1 wink users 81573360 May 13 10:49 
build-clang-shlib-master/lib/libclang.so.9
  lrwxrwxrwx 1 wink users   13 May 13 10:49 
build-clang-shlib-master/lib/libclang.so.9svn -> libclang.so.9

But the exported symbols are only the clang C api from libclang.exports:

  $ nm -g --demangle build-clang-shlib-master/lib/libclang.so.9 | grep ' T ' | 
wc -l
  381
  $ wc -l clang/tools/libclang/libclang.exports 
  381 clang/tools/libclang/libclang.exports

If I don't use your patch and build the same way lib/libclang.so.9 is still 
created and with the 381 globals:

  $ cmake ../llvm -G Ninja '-DLLVM_ENABLE_PROJECTS=clang;lld;compiler-rt' 
-DCMAKE_INSTALL_PREFIX=/home/wink/local-master -DCMAKE_BUILD_TYPE=Release 
-DLLVM_BUILD_LLVM_DYLIB=ON
  $ ninja -j11 -v
  $ ls build-master/lib/libclang*so* -al
  lrwxrwxrwx 1 wink users   16 May 13 11:35 build-master/lib/libclang.so -> 
libclang.so.9svn
  -rwxr-xr-x 1 wink users 81573360 May 13 11:35 build-master/lib/libclang.so.9
  lrwxrwxrwx 1 wink users   13 May 13 11:35 
build-master/lib/libclang.so.9svn -> libclang.so.9
  $ nm -g --demangle build-master/lib/libclang.so.9 | grep ' T ' | wc -l
  381

I was assuming the goal of clang-shlib was to export all of the symbols as 
exported by the libclang*.a files,
of so the first stab didn't quite do it.

But one thing it did do was reduce the steps and time ninja needed to complete 
my test
build from 4355 steps for 

[PATCH] D61851: [clang-tidy] New option for misc-throw-by-value-catch-by-reference

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang-tidy/misc/ThrowByValueCatchByReferenceCheck.cpp:25
+  WarnOnLargeObject(Options.get("WarnOnLargeObject", false)),
+  // Cannot access `ASTContext` from here so set it to an extremal value
+  MaxSize(Options.get("MaxSize", std::numeric_limits::max())) {}

Missing a full stop at the end of the comment.



Comment at: 
docs/clang-tidy/checks/misc-throw-by-value-catch-by-reference.rst:37-40
+   Also warns for any large trivial object caught by value. Catching a large
+   object by value is not dangerous but affects the perofrmance negatively. The
+   maximum size of an object allowed to be caught without warning can be set
+   using option `MaxSize`

large trivial object -> large, trivial object
affects the perofrmance -> affects the performance
using option `MaxSize` -> using the `MaxSize` option.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D61851



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

[PATCH] D61619: Make language option `GNUAsm` discoverable with `__has_extension` macro.

[Volodymyr Sapsai via Phabricator via cfe-commits]

vsapsai added a comment.

Ping.


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

https://reviews.llvm.org/D61619



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

[PATCH] D59885: [Lex] Allow to consume tokens while preprocessing

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith added a comment.

Thinking about this some more: distinguishing between "macro expansion" and 
other cases seems like a proxy for "this token came from inside the 
preprocessor / lexer" versus "this token was provided by the user", which is 
also exactly what `IsNewToken` is supposed to capture. I don't think we need 
two separate flags here.

I also suspect that a significant amount of the cost is the additional function 
call on the hot path (the 1-parameter `Lex` wrapper function). I wonder if 
there's something that we could do to remove that from the hot path without 
duplicating the whole `Lex` function. Maybe we could add a flag to `Token`s to 
say that they're a replay of prior tokens, rather than being newly-created 
tokens, and make `TokenLexer` set that flag on tokens it produces if its token 
sequence came from a "replay" context (that's largely the same as your current 
"not a macro expansion" check, but there are probably cases where the 
preprocessor itself generates tokens for which that's wrong; we should have a 
flag on `EnterTokenStream` to indicate which mode we're in). We can then also 
change `CachingLex` to set the flag, and get rid of the `IsNewToken` flag too.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D59885



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

[PATCH] D24892: [clang-tidy] Add option "LiteralInitializers" to cppcoreguidelines-pro-type-member-init

[Matthias Gehre via Phabricator via cfe-commits]

mgehre added a comment.

Do I wait for @alexfh to turn his red into a green, too?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D24892



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

[PATCH] D61858: Make `__is_base_of` more friendly with unions

[Marshall Clow via Phabricator via cfe-commits]

mclow.lists closed this revision.
mclow.lists added a comment.

Committed as revision 360614


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

https://reviews.llvm.org/D61858



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

r360614 - Make more friendly with unions. Reviewed as https://reviews.llvm.org/D61858

[Marshall Clow via cfe-commits]

Author: marshall
Date: Mon May 13 12:29:23 2019
New Revision: 360614

URL: http://llvm.org/viewvc/llvm-project?rev=360614=rev
Log:
Make  more friendly with unions. Reviewed as https://reviews.llvm.org/D61858

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

Modified: cfe/trunk/lib/Sema/SemaExprCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExprCXX.cpp?rev=360614=360613=360614=diff
==
--- cfe/trunk/lib/Sema/SemaExprCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExprCXX.cpp Mon May 13 12:29:23 2019
@@ -5118,8 +5118,15 @@ static bool EvaluateBinaryTypeTrait(Sema
 assert(Self.Context.hasSameUnqualifiedType(LhsT, RhsT)
  == (lhsRecord == rhsRecord));
 
+// Unions are never base classes, and never have base classes.
+// It doesn't matter if they are complete or not. See PR#41843
+if (lhsRecord && lhsRecord->getDecl()->isUnion())
+  return false;
+if (rhsRecord && rhsRecord->getDecl()->isUnion())
+  return false;
+
 if (lhsRecord == rhsRecord)
-  return !lhsRecord->getDecl()->isUnion();
+  return true;
 
 // C++0x [meta.rel]p2:
 //   If Base and Derived are class types and are different types

Modified: cfe/trunk/test/SemaCXX/type-traits.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/type-traits.cpp?rev=360614=360613=360614=diff
==
--- cfe/trunk/test/SemaCXX/type-traits.cpp (original)
+++ cfe/trunk/test/SemaCXX/type-traits.cpp Mon May 13 12:29:23 2019
@@ -14,6 +14,7 @@ typedef NonPOD NonPODArMB[10][2];
 enum Enum { EV };
 struct POD { Enum e; int i; float f; NonPOD* p; };
 struct Empty {};
+struct IncompleteStruct;
 typedef Empty EmptyAr[10];
 typedef Empty EmptyArNB[];
 typedef Empty EmptyArMB[1][2];
@@ -1915,6 +1916,20 @@ void is_base_of() {
   { int arr[F(__is_base_of(Base, NonderivedTemp))]; }
   { int arr[F(__is_base_of(Base, UndefinedTemp))]; } // expected-error 
{{implicit instantiation of undefined template 'UndefinedTemp'}}
 
+  { int arr[F(__is_base_of(IncompleteUnion, IncompleteUnion))]; }
+  { int arr[F(__is_base_of(Union, IncompleteUnion))]; }
+  { int arr[F(__is_base_of(IncompleteUnion, Union))]; }
+  { int arr[F(__is_base_of(IncompleteStruct, IncompleteUnion))]; }
+  { int arr[F(__is_base_of(IncompleteUnion, IncompleteStruct))]; }
+  { int arr[F(__is_base_of(Empty, IncompleteUnion))]; }
+  { int arr[F(__is_base_of(IncompleteUnion, Empty))]; }
+  { int arr[F(__is_base_of(int, IncompleteUnion))]; }
+  { int arr[F(__is_base_of(IncompleteUnion, int))]; }
+  { int arr[F(__is_base_of(Empty, Union))]; }
+  { int arr[F(__is_base_of(Union, Empty))]; }
+  { int arr[F(__is_base_of(int, Empty))]; }
+  { int arr[F(__is_base_of(Union, int))]; }
+
   isBaseOfT();
   isBaseOfF();
 


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

[PATCH] D61700: [clang-tidy] readability-redundant-declaration: fix false positive with C "extern inline"

[Matthias Gehre via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
mgehre marked 2 inline comments as done.
Closed by commit rL360613: [clang-tidy] readability-redundant-declaration: fix 
false positive with C… (authored by mgehre, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D61700?vs=198724=199306#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D61700

Files:
  clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp
  clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.c
  clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp


Index: 
clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp
@@ -17,6 +17,10 @@
 namespace tidy {
 namespace readability {
 
+AST_MATCHER(FunctionDecl, doesDeclarationForceExternallyVisibleDefinition) {
+  return Node.doesDeclarationForceExternallyVisibleDefinition();
+}
+
 RedundantDeclarationCheck::RedundantDeclarationCheck(StringRef Name,
  ClangTidyContext *Context)
 : ClangTidyCheck(Name, Context),
@@ -25,8 +29,10 @@
 void RedundantDeclarationCheck::registerMatchers(MatchFinder *Finder) {
   Finder->addMatcher(
   namedDecl(anyOf(varDecl(unless(isDefinition())),
-  functionDecl(unless(anyOf(isDefinition(), isDefaulted(),
-hasParent(friendDecl()))
+  functionDecl(unless(anyOf(
+  isDefinition(), isDefaulted(),
+  doesDeclarationForceExternallyVisibleDefinition(),
+  hasParent(friendDecl()))
   .bind("Decl"),
   this);
 }
Index: 
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.c
===
--- clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.c
+++ clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.c
@@ -0,0 +1,31 @@
+// RUN: %check_clang_tidy %s readability-redundant-declaration %t
+
+extern int Xyz;
+extern int Xyz; // Xyz
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: redundant 'Xyz' declaration 
[readability-redundant-declaration]
+// CHECK-FIXES: {{^}}// Xyz{{$}}
+int Xyz = 123;
+
+extern int A;
+extern int A, B;
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: redundant 'A' declaration
+// CHECK-FIXES: {{^}}extern int A, B;{{$}}
+
+extern int Buf[10];
+extern int Buf[10]; // Buf[10]
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: redundant 'Buf' declaration
+// CHECK-FIXES: {{^}}// Buf[10]{{$}}
+
+static int f();
+static int f(); // f
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: redundant 'f' declaration
+// CHECK-FIXES: {{^}}// f{{$}}
+static int f() {}
+
+inline void g() {}
+
+inline void g();
+// CHECK-MESSAGES: :[[@LINE-1]]:13: warning: redundant 'g' declaration
+
+// OK: Needed to emit an external definition.
+extern inline void g();
Index: 
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp
===
--- 
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp
+++ 
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp
@@ -68,3 +68,13 @@
 // CHECK-FIXES: {{^}}DEFINE(test);{{$}}
 
 } // namespace macros
+
+inline void g() {}
+
+inline void g(); // g
+// CHECK-MESSAGES: :[[@LINE-1]]:13: warning: redundant 'g' declaration
+// CHECK-FIXES: {{^}}// g{{$}}
+
+extern inline void g(); // extern g
+// CHECK-MESSAGES: :[[@LINE-1]]:20: warning: redundant 'g' declaration
+// CHECK-FIXES: {{^}}// extern g{{$}}


Index: clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp
===
--- clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp
+++ clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp
@@ -17,6 +17,10 @@
 namespace tidy {
 namespace readability {
 
+AST_MATCHER(FunctionDecl, doesDeclarationForceExternallyVisibleDefinition) {
+  return Node.doesDeclarationForceExternallyVisibleDefinition();
+}
+
 RedundantDeclarationCheck::RedundantDeclarationCheck(StringRef Name,
  ClangTidyContext *Context)
 : ClangTidyCheck(Name, Context),
@@ -25,8 +29,10 @@
 void RedundantDeclarationCheck::registerMatchers(MatchFinder *Finder) {
   Finder->addMatcher(
   namedDecl(anyOf(varDecl(unless(isDefinition())),
-  

[clang-tools-extra] r360613 - [clang-tidy] readability-redundant-declaration: fix false positive with C "extern inline"

[Matthias Gehre via cfe-commits]

Author: mgehre
Date: Mon May 13 12:21:57 2019
New Revision: 360613

URL: http://llvm.org/viewvc/llvm-project?rev=360613=rev
Log:
[clang-tidy] readability-redundant-declaration: fix false positive with C 
"extern inline"

Summary:
readability-redundant-declaration was diagnosing a redundant declaration
on "extern inline void f();", which is needed in C code to force an external 
definition
of the inline function f. (This is different to how inline behaves in C++).

Reviewers: alexfh, danielmarjamaki

Subscribers: xazax.hun, cfe-commits

Tags: #clang

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

Added:
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.c
Modified:
clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp

clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp

Modified: 
clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp?rev=360613=360612=360613=diff
==
--- 
clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp 
(original)
+++ 
clang-tools-extra/trunk/clang-tidy/readability/RedundantDeclarationCheck.cpp 
Mon May 13 12:21:57 2019
@@ -17,6 +17,10 @@ namespace clang {
 namespace tidy {
 namespace readability {
 
+AST_MATCHER(FunctionDecl, doesDeclarationForceExternallyVisibleDefinition) {
+  return Node.doesDeclarationForceExternallyVisibleDefinition();
+}
+
 RedundantDeclarationCheck::RedundantDeclarationCheck(StringRef Name,
  ClangTidyContext *Context)
 : ClangTidyCheck(Name, Context),
@@ -25,8 +29,10 @@ RedundantDeclarationCheck::RedundantDecl
 void RedundantDeclarationCheck::registerMatchers(MatchFinder *Finder) {
   Finder->addMatcher(
   namedDecl(anyOf(varDecl(unless(isDefinition())),
-  functionDecl(unless(anyOf(isDefinition(), isDefaulted(),
-hasParent(friendDecl()))
+  functionDecl(unless(anyOf(
+  isDefinition(), isDefaulted(),
+  doesDeclarationForceExternallyVisibleDefinition(),
+  hasParent(friendDecl()))
   .bind("Decl"),
   this);
 }

Added: 
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.c
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.c?rev=360613=auto
==
--- clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.c 
(added)
+++ clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.c 
Mon May 13 12:21:57 2019
@@ -0,0 +1,31 @@
+// RUN: %check_clang_tidy %s readability-redundant-declaration %t
+
+extern int Xyz;
+extern int Xyz; // Xyz
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: redundant 'Xyz' declaration 
[readability-redundant-declaration]
+// CHECK-FIXES: {{^}}// Xyz{{$}}
+int Xyz = 123;
+
+extern int A;
+extern int A, B;
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: redundant 'A' declaration
+// CHECK-FIXES: {{^}}extern int A, B;{{$}}
+
+extern int Buf[10];
+extern int Buf[10]; // Buf[10]
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: redundant 'Buf' declaration
+// CHECK-FIXES: {{^}}// Buf[10]{{$}}
+
+static int f();
+static int f(); // f
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: redundant 'f' declaration
+// CHECK-FIXES: {{^}}// f{{$}}
+static int f() {}
+
+inline void g() {}
+
+inline void g();
+// CHECK-MESSAGES: :[[@LINE-1]]:13: warning: redundant 'g' declaration
+
+// OK: Needed to emit an external definition.
+extern inline void g();

Modified: 
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp?rev=360613=360612=360613=diff
==
--- 
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp 
(original)
+++ 
clang-tools-extra/trunk/test/clang-tidy/readability-redundant-declaration.cpp 
Mon May 13 12:21:57 2019
@@ -68,3 +68,13 @@ DEFINE(test);
 // CHECK-FIXES: {{^}}DEFINE(test);{{$}}
 
 } // namespace macros
+
+inline void g() {}
+
+inline void g(); // g
+// CHECK-MESSAGES: :[[@LINE-1]]:13: warning: redundant 'g' declaration
+// CHECK-FIXES: {{^}}// g{{$}}
+
+extern inline void g(); // extern g
+// CHECK-MESSAGES: :[[@LINE-1]]:20: warning: redundant 'g' declaration
+// CHECK-FIXES: {{^}}// extern g{{$}}


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

[PATCH] D61858: Make `__is_base_of` more friendly with unions

[Richard Smith - zygoloid via Phabricator via cfe-commits]

rsmith accepted this revision.
rsmith added a comment.

Yeah, this seems to match the library wording. (I think it's short-sighted and 
over-fitting -- this is baking into the library specification that the language 
happens to not allow unions to have base classes today -- but this isn't the 
venue for that discussion.)


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

https://reviews.llvm.org/D61858



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

[PATCH] D61765: [OpenMP][Clang][BugFix] Split declares and math functions inclusion.

[Gheorghe-Teodor Bercea via Phabricator via cfe-commits]

gtbercea updated this revision to Diff 199304.
gtbercea added a comment.

- Exclude clock functions. Reverse inclusion order.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61765

Files:
  lib/Driver/ToolChains/Clang.cpp
  lib/Headers/CMakeLists.txt
  lib/Headers/__clang_cuda_cmath.h
  lib/Headers/__clang_cuda_device_functions.h
  lib/Headers/__clang_cuda_math_forward_declares.h
  lib/Headers/openmp_wrappers/__clang_openmp_math.h
  lib/Headers/openmp_wrappers/__clang_openmp_math_declares.h
  lib/Headers/openmp_wrappers/cmath
  lib/Headers/openmp_wrappers/math.h
  test/Headers/Inputs/include/cstdlib
  test/Headers/nvptx_device_cmath_functions.c
  test/Headers/nvptx_device_cmath_functions.cpp
  test/Headers/nvptx_device_math_functions.c
  test/Headers/nvptx_device_math_functions.cpp

Index: test/Headers/nvptx_device_math_functions.cpp
===
--- test/Headers/nvptx_device_math_functions.cpp
+++ test/Headers/nvptx_device_math_functions.cpp
@@ -4,8 +4,9 @@
 // REQUIRES: nvptx-registered-target
 
 // RUN: %clang_cc1 -internal-isystem %S/Inputs/include -include math.h -x c++ -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc
-// RUN: %clang_cc1 -internal-isystem %S/../../lib/Headers/openmp_wrappers -include __clang_openmp_math.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -include math.h -internal-isystem %S/Inputs/include -include stdlib.h -include limits -x c++ -fopenmp -triple nvptx64-nvidia-cuda -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck -check-prefix CHECK-YES %s
+// RUN: %clang_cc1 -internal-isystem %S/../../lib/Headers/openmp_wrappers -include __clang_openmp_math_declares.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -include math.h -internal-isystem %S/Inputs/include -include stdlib.h -include limits -include cstdlib -x c++ -fopenmp -triple nvptx64-nvidia-cuda -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck -check-prefix CHECK-YES %s
 
+#include 
 #include 
 
 void test_sqrt(double a1) {
Index: test/Headers/nvptx_device_math_functions.c
===
--- test/Headers/nvptx_device_math_functions.c
+++ test/Headers/nvptx_device_math_functions.c
@@ -4,7 +4,7 @@
 // REQUIRES: nvptx-registered-target
 
 // RUN: %clang_cc1 -internal-isystem %S/Inputs/include -include math.h -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc
-// RUN: %clang_cc1 -internal-isystem %S/../../lib/Headers/openmp_wrappers -include __clang_openmp_math.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -include math.h -fopenmp -triple nvptx64-nvidia-cuda -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck -check-prefix CHECK-YES %s
+// RUN: %clang_cc1 -internal-isystem %S/../../lib/Headers/openmp_wrappers -include __clang_openmp_math_declares.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -include math.h -fopenmp -triple nvptx64-nvidia-cuda -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck -check-prefix CHECK-YES %s
 
 #include 
 
Index: test/Headers/nvptx_device_cmath_functions.cpp
===
--- test/Headers/nvptx_device_cmath_functions.cpp
+++ test/Headers/nvptx_device_cmath_functions.cpp
@@ -4,9 +4,10 @@
 // REQUIRES: nvptx-registered-target
 
 // RUN: %clang_cc1 -internal-isystem %S/Inputs/include -include cmath -x c++ -fopenmp -triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc %s -o %t-ppc-host.bc
-// RUN: %clang_cc1 -internal-isystem %S/../../lib/Headers/openmp_wrappers -include __clang_openmp_math.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -include cmath -internal-isystem %S/Inputs/include -include stdlib.h -x c++ -fopenmp -triple nvptx64-nvidia-cuda -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s -fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o - | FileCheck -check-prefix CHECK-YES %s
+// RUN: %clang_cc1 -internal-isystem %S/../../lib/Headers/openmp_wrappers -include __clang_openmp_math_declares.h -internal-isystem %S/../../lib/Headers/openmp_wrappers -include cmath -internal-isystem %S/Inputs/include -include stdlib.h -x c++ -fopenmp -triple nvptx64-nvidia-cuda -aux-triple powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda 

[PATCH] D61858: Make `__is_base_of` more friendly with unions

[Louis Dionne via Phabricator via cfe-commits]

ldionne accepted this revision.
ldionne added a comment.
This revision is now accepted and ready to land.

I'm not a frontend expert, but this looks reasonable to me.


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

https://reviews.llvm.org/D61858



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

[PATCH] D61858: Make `__is_base_of` more friendly with unions

[Marshall Clow via Phabricator via cfe-commits]

mclow.lists added a comment.

In D61858#1500270 , @ldionne wrote:

> Shouldn't we also add unit tests for PR41843 in libc++?


Yes. But I want to do that later.
After this has landed (and probably wait a week for all the bots that are 
running trunk to update).


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

https://reviews.llvm.org/D61858



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

[PATCH] D61850: Removed superfluous and slightly annoying newlines in run-clang-tidy's output.

[Sven Panne via Phabricator via cfe-commits]

svenpanne added a comment.

In D61850#1500298 , @JonasToth wrote:

> [...] please ensure that e.g. clang-analyzer-* output looks proper as well 
> and `-quiet` does, too.


OK, are there any (unit) tests which I should run? If yes, how exactly? I have 
a successfully built a fork of https://github.com/llvm/llvm-project via ninja 
locally, but the documentation for the various subprojects is still a bit hard 
to find to me. Is there a ninja target for `clang-tidy`-related tests? Any 
hints to get started would be highly appreciated.

This and the other output-related patches are my first submissions here, and 
they are intentionally simple to get the workflow right. My real intention is 
trying to improve/fix the `readability-identifier-naming` check/fixer, which 
still has a few issues.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D61850



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

[libunwind] r360610 - Add a new LIBUNWIND_WEAK_PTHREAD Cmake option to force

[Sterling Augustine via cfe-commits]

Author: saugustine
Date: Mon May 13 11:45:03 2019
New Revision: 360610

URL: http://llvm.org/viewvc/llvm-project?rev=360610=rev
Log:
Add a new LIBUNWIND_WEAK_PTHREAD Cmake option to force
calls into the pthread library use weak symbols.

This option allows libpthread to be a weak dependency rather
than a hard one.

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

Modified:
libunwind/trunk/CMakeLists.txt
libunwind/trunk/src/CMakeLists.txt
libunwind/trunk/src/RWMutex.hpp

Modified: libunwind/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/CMakeLists.txt?rev=360610=360609=360610=diff
==
--- libunwind/trunk/CMakeLists.txt (original)
+++ libunwind/trunk/CMakeLists.txt Mon May 13 11:45:03 2019
@@ -134,6 +134,7 @@ option(LIBUNWIND_ENABLE_STATIC "Build li
 option(LIBUNWIND_ENABLE_CROSS_UNWINDING "Enable cross-platform unwinding 
support." OFF)
 option(LIBUNWIND_ENABLE_ARM_WMMX "Enable unwinding support for ARM WMMX 
registers." OFF)
 option(LIBUNWIND_ENABLE_THREADS "Build libunwind with threading support." ON)
+option(LIBUNWIND_WEAK_PTHREAD_LIB "Use weak references to refer to pthread 
functions." OFF)
 option(LIBUNWIND_USE_COMPILER_RT "Use compiler-rt instead of libgcc" OFF)
 option(LIBUNWIND_INCLUDE_DOCS "Build the libunwind documentation." 
${LLVM_INCLUDE_DOCS})
 

Modified: libunwind/trunk/src/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/CMakeLists.txt?rev=360610=360609=360610=diff
==
--- libunwind/trunk/src/CMakeLists.txt (original)
+++ libunwind/trunk/src/CMakeLists.txt Mon May 13 11:45:03 2019
@@ -67,6 +67,7 @@ endif()
 unwind_append_if(libraries LIBUNWIND_HAS_DL_LIB dl)
 if (LIBUNWIND_ENABLE_THREADS)
   unwind_append_if(libraries LIBUNWIND_HAS_PTHREAD_LIB pthread)
+  unwind_append_if(LIBUNWIND_COMPILE_FLAGS LIBUNWIND_WEAK_PTHREAD_LIB 
-DLIBUNWIND_USE_WEAK_PTHREAD=1)
 endif()
 
 # Setup flags.

Modified: libunwind/trunk/src/RWMutex.hpp
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/RWMutex.hpp?rev=360610=360609=360610=diff
==
--- libunwind/trunk/src/RWMutex.hpp (original)
+++ libunwind/trunk/src/RWMutex.hpp Mon May 13 11:45:03 2019
@@ -56,17 +56,52 @@ private:
   SRWLOCK _lock = SRWLOCK_INIT;
 };
 
-#else
+#elif !defined(LIBUNWIND_USE_WEAK_PTHREAD)
 
 class _LIBUNWIND_HIDDEN RWMutex {
 public:
-  bool lock_shared() { return pthread_rwlock_rdlock(&_lock) == 0; }
+  bool lock_shared() { return pthread_rwlock_rdlock(&_lock) == 0;  }
   bool unlock_shared() { return pthread_rwlock_unlock(&_lock) == 0; }
   bool lock() { return pthread_rwlock_wrlock(&_lock) == 0; }
   bool unlock() { return pthread_rwlock_unlock(&_lock) == 0; }
 
 private:
   pthread_rwlock_t _lock = PTHREAD_RWLOCK_INITIALIZER;
+};
+
+#else
+
+extern "C" int __attribute__((weak))
+pthread_create(pthread_t *thread, const pthread_attr_t *attr,
+   void *(*start_routine)(void *), void *arg);
+extern "C" int __attribute__((weak))
+pthread_rwlock_rdlock(pthread_rwlock_t *lock);
+extern "C" int __attribute__((weak))
+pthread_rwlock_wrlock(pthread_rwlock_t *lock);
+extern "C" int __attribute__((weak))
+pthread_rwlock_unlock(pthread_rwlock_t *lock);
+
+// Calls to the locking functions are gated on pthread_create, and not the
+// functions themselves, because the data structure should only be locked if
+// another thread has been created. This is what similar libraries do.
+
+class _LIBUNWIND_HIDDEN RWMutex {
+public:
+  bool lock_shared() {
+return !pthread_create || (pthread_rwlock_rdlock(&_lock) == 0);
+  }
+  bool unlock_shared() {
+return !pthread_create || (pthread_rwlock_unlock(&_lock) == 0);
+  }
+  bool lock() {
+return !pthread_create || (pthread_rwlock_wrlock(&_lock) == 0);
+  }
+  bool unlock() {
+return !pthread_create || (pthread_rwlock_unlock(&_lock) == 0);
+  }
+
+private:
+  pthread_rwlock_t _lock = PTHREAD_RWLOCK_INITIALIZER;
 };
 
 #endif


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

[PATCH] D61438: [ASTImporter] Use llvm::Expected and Error in the importer API

[Adrian Prantl via Phabricator via cfe-commits]

aprantl added inline comments.



Comment at: clang/include/clang/AST/ASTImporter.h:203
 /// context, or the import error.
-llvm::Expected Import_New(TypeSourceInfo *FromTSI);
-// FIXME: Remove this version.
-TypeSourceInfo *Import(TypeSourceInfo *FromTSI);
+llvm::Expected Import(TypeSourceInfo *FromTSI);
 

martong wrote:
> aprantl wrote:
> > Wouldn't it make more sense to return `Expected`?
> That would not be consistent with the other changes. In this patch we change 
> the signature of each functions similarly:
> From `T foo(...)` to `Expected foo(...)`.
> Also, `TypeSourceInfo` factory functions in `ASTContext` do return with a 
> pointer. For example:
> ```
>   TypeSourceInfo *CreateTypeSourceInfo(QualType T, unsigned Size = 0) const;
> 
>   /// Allocate a TypeSourceInfo where all locations have been
>   /// initialized to a given location, which defaults to the empty
>   /// location.
>   TypeSourceInfo *
>   getTrivialTypeSourceInfo(QualType T,
>SourceLocation Loc = SourceLocation()) const;
> 
> ```
I believe that LLVM's practice of passing non-null pointers around is bad API 
design because it's never quite clear from looking at an API which pointer 
parameters are nullable, so I was hoping that we could correct some of that at 
least in the cases where we introduce API that return Expected<> objects to 
make it obvious that this is either an error or a valid object. If you that the 
perceived inconsistency weighs stronger than the readability improvements let 
me know and I can reconsider.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61438



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

[PATCH] D61765: [OpenMP][Clang][BugFix] Split declares and math functions inclusion.

[Gheorghe-Teodor Bercea via Phabricator via cfe-commits]

gtbercea added a comment.

In D61765#1500233 , @tra wrote:

> In D61765#1499957 , @jdoerfert wrote:
>
> > Two small changes and then it is fine with me. @tra ?
>
>
> LGTM in general. I would still like to confirm that the changes work with 
> libc++.


As soon as libc++ the limits header included in

  __clang_cuda_cmath.h:15
  ``` is not found:

__clang_cuda_cmath.h:15:10: fatal error: 'limits' file not found
#include 

  Not even CUDA works actually so I'm not sure what the best answer to this 
problem is.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61765



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

[PATCH] D61850: Removed superfluous and slightly annoying newlines in run-clang-tidy's output.

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added a comment.

I agree with the direction, please ensure that e.g. clang-analyzer-* output 
looks proper as well and `-quiet` does, too.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D61850



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

[PATCH] D61749: [clang-tidy] initial version of readability-static-const-method

[Jonas Toth via Phabricator via cfe-commits]

JonasToth added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/readability-static-const-method.cpp:209
+void KeepLambdas() {
+  auto F = +[]() { return 0; };
+  auto F2 = []() { return 0; };

mgehre wrote:
> JonasToth wrote:
> > Does it pass here?
> > I looks a bit weird, shouldnt the lambda be called for this to work (this 
> > is the unary + right?)?
> https://stackoverflow.com/questions/18889028/a-positive-lambda-what-sorcery-is-this
Thank you C++ for showing my simple mindedness all the time :D
Its fine then and I will keep it in my mind for future test cases I check 
against ;)



Comment at: 
clang-tools-extra/test/clang-tidy/readability-static-const-method.cpp:312
+return const_cast(this)->get();
+  }
+

mgehre wrote:
> JonasToth wrote:
> > I think more template tests wouldn't hurt. From the other checks experience 
> > I can safely say we got burned a few times :)
> > Instantiating the templates with builtin arrays, pointers, references and 
> > different qualifiers usually produces interesting test cases as well, that 
> > need to be handled properly.
> > 
> > Another thing that comes to mind with templates are overloaded operators.
> > ```
> > template 
> > void bar() {
> >  Foo x1, x2;
> >  Foo y = x1 + x2;
> > }
> > ```
> > Builtins are not changed by `operator+` but that can not be said about 
> > other types in general (maybe with concepts used properly).
> The check only checks templates instantiations (so we will see no template 
> parameters, just ordinary types). The plus here will be be function call in 
> the AST of the instantiation when Foo has an overloaded operator+.
> The current version will never propose to make bar() const when a method on 
> `this` is called.
> I can add the test to show this.
Yes please add a test to show they are not analyzed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61749



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

[PATCH] D61849: Do not list enabled checks when -quiet is given to run-clang-tidy.

[Jonas Toth via Phabricator via cfe-commits]

JonasToth accepted this revision.
JonasToth added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D61849



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

[PATCH] D61861: DeleteNullPointerCheck now deletes until the end brace of the condition

[Mads Ravn via Phabricator via cfe-commits]

madsravn added a comment.

Besides my one comment this looks good to me.




Comment at: 
clang-tools-extra/test/clang-tidy/readability-delete-null-pointer.cpp:9
   // #1
-  if (p) { // #2
+  if (p /**/) { // #2
 delete p;

Would you mind creating a new test instead of changing the existing one? 
Removing tests could create another whole for a bug to fall through.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D61861



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

[PATCH] D61858: Make `__is_base_of` more friendly with unions

[Louis Dionne via Phabricator via cfe-commits]

ldionne added a comment.

Shouldn't we also add unit tests for PR41843 in libc++?


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

https://reviews.llvm.org/D61858



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

[PATCH] D61851: [clang-tidy] New option for misc-throw-by-value-catch-by-reference

[Torbjörn Klatt via Phabricator via cfe-commits]

torbjoernk added inline comments.



Comment at: 
docs/clang-tidy/checks/misc-throw-by-value-catch-by-reference.rst:35-46
+.. option:: WarnOnLargeObject
+
+   Also warns for any large trivial object caught by value. Catching a large
+   object by value is not dangerous but affects the perofrmance negatively. The
+   maximum size of an object allowed to be caught without warning can be set
+   using option `MaxSize`
+   Default is `0`.

I think it might be worth adding a note on the fallback to `sizeof(size_t)` if 
`MaxSize` is not set or manually set to `std::numeric_limits::max()` 
by the user.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D61851



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

r360607 - [clang][ASTContext] Call setAttached for comments attached to a declaration

[Jan Korous via cfe-commits]

Author: jkorous
Date: Mon May 13 10:52:09 2019
New Revision: 360607

URL: http://llvm.org/viewvc/llvm-project?rev=360607=rev
Log:
[clang][ASTContext] Call setAttached for comments attached to a declaration

This is a bug affecting performance when compiling with -Wdocumentation.

In Sema::ActOnDocumentable we're checking whether there are any comments 
unattached to declaration at the end of comment list whenever we encounter new 
documentable declaration.
Since this property of RawComment was never set we were trying to find comments 
every time and that involves at least a couple expensive SourceLocation 
decompositions.

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

Modified:
cfe/trunk/lib/AST/ASTContext.cpp

Modified: cfe/trunk/lib/AST/ASTContext.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ASTContext.cpp?rev=360607=360606=360607=diff
==
--- cfe/trunk/lib/AST/ASTContext.cpp (original)
+++ cfe/trunk/lib/AST/ASTContext.cpp Mon May 13 10:52:09 2019
@@ -255,6 +255,7 @@ RawComment *ASTContext::getRawCommentFor
 SourceMgr.getLineNumber(DeclLocDecomp.first, DeclLocDecomp.second)
   == SourceMgr.getLineNumber(CommentBeginDecomp.first,
  CommentBeginDecomp.second)) {
+  (**Comment).setAttached();
   return *Comment;
 }
   }
@@ -296,6 +297,7 @@ RawComment *ASTContext::getRawCommentFor
   if (Text.find_first_of(";{}#@") != StringRef::npos)
 return nullptr;
 
+  (**Comment).setAttached();
   return *Comment;
 }
 


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

[PATCH] D58920: [Modules][PR39287] Consolidate multiple std's

[Brian Gesiak via Phabricator via cfe-commits]

modocache added a comment.

Thanks @rsmith for the guidance here! I appreciate it very much. One snag I ran 
into after following your suggestion, though, is that when I modify 
`ASTDeclReader::findExisting` to return Sema's existing implicit std namespace, 
I run into an assertion later on, when the decl chain is being marked as 
incomplete. That is, the following patch (debug output included):

  diff --git a/lib/Serialization/ASTReaderDecl.cpp 
b/lib/Serialization/ASTReaderDecl.cpp
  index 32bd82d077..9d447952e1 100644
  --- a/lib/Serialization/ASTReaderDecl.cpp
  +++ b/lib/Serialization/ASTReaderDecl.cpp
  @@ -47,6 +47,7 @@
   #include "clang/Basic/SourceLocation.h"
   #include "clang/Basic/Specifiers.h"
   #include "clang/Sema/IdentifierResolver.h"
  +#include "clang/Sema/Sema.h"
   #include "clang/Serialization/ASTBitCodes.h"
   #include "clang/Serialization/ASTReader.h"
   #include "clang/Serialization/ContinuousRangeMap.h"
  @@ -3401,6 +3402,22 @@ ASTDeclReader::FindExistingResult 
ASTDeclReader::findExisting(NamedDecl *D) {
 return FindExistingResult(Reader, D, Existing, AnonymousDeclNumber,
   TypedefNameForLinkage);
   }
  +if (isa(D) && D->getName() == "std") {
  +  llvm::outs() << "Found std namespace: ";
  +  D->dump();
  +  llvm::outs() << "Merging into Sema std namespace: ";
  +  Sema *S = Reader.getSema();
  +  S->getStdNamespace()->dump();
  +  NamedDecl *Existing =
  +  getDeclForMerging(S->getStdNamespace(), TypedefNameForLinkage);
  +  llvm::outs() << "Found Existing: ";
  +  Existing->dump();
  +  if (isSameEntity(Existing, D)) {
  +llvm::outs() << "isSameEntity is true\n";
  +return FindExistingResult(Reader, D, Existing, AnonymousDeclNumber,
  +  TypedefNameForLinkage);
  +  }
  +}
 } else {
   // Not in a mergeable context.
   return FindExistingResult(Reader);

Results in the expected output, along with an unexpected assert:

  Found std namespace: NamespaceDecl 0x55a391530910 
 col:11 imported in a.h std
  Merging into Sema std namespace: NamespaceDecl 0x55a391501ec8 <>  implicit std
  Found Existing: NamespaceDecl 0x55a391501ec8 <>  
implicit std
  isSameEntity is true
  clang-9: ../include/llvm/ADT/PointerUnion.h:135: T llvm::PointerUnion::get() const [with T = clang::LazyGenerationalUpdatePtr; 
PT1 = llvm::PointerUnion; PT2 = 
clang::LazyGenerationalUpdatePtr]: Assertion `is() && 
"Invalid accessor called"' failed.
  Stack dump:
  0.  Program arguments: 
/home/modocache/Source/llvm/git/dev/llvm/build/bin/clang-9 -cc1 -triple 
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name 
mod-virtual-destructor-bug.cpp -mrelocation-model static -mthread-model posix 
-mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases 
-munwind-tables -fuse-init-array -target-cpu x86-64 -dwarf-column-info 
-debugger-tuning=gdb -resource-dir 
/home/modocache/Source/llvm/git/dev/llvm/build/lib/clang/9.0.0 -I 
mod-virtual-destructor-bug -internal-isystem 
/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8 -internal-isystem 
/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/x86_64-linux-gnu/c++/8 
-internal-isystem 
/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/x86_64-linux-gnu/c++/8 
-internal-isystem 
/usr/lib/gcc/x86_64-linux-gnu/8/../../../../include/c++/8/backward 
-internal-isystem /usr/local/include -internal-isystem 
/home/modocache/Source/llvm/git/dev/llvm/build/lib/clang/9.0.0/include 
-internal-externc-isystem /usr/include/x86_64-linux-gnu 
-internal-externc-isystem /include -internal-externc-isystem /usr/include 
-std=c++17 -fdeprecated-macro -fdebug-compilation-dir 
/home/modocache/Source/tmp/mod -ferror-limit 19 -fmessage-length 195 -fmodules 
-fimplicit-module-maps -fmodules-cache-path=mod-virtual-destructor-cache 
-fmodules-validate-system-headers -fobjc-runtime=gcc -fcxx-exceptions 
-fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o 
/tmp/mod-virtual-destructor-bug-0da92f.o -x c++ mod-virtual-destructor-bug.cpp 
-faddrsig
  1.  mod-virtual-destructor-bug.cpp:10:17: current parser token 'class'
   #0 0x55a388bfaaa5 llvm::sys::PrintStackTrace(llvm::raw_ostream&) 
/home/modocache/Source/llvm/git/dev/llvm/build/../lib/Support/Unix/Signals.inc:494:22
   #1 0x55a388bfab38 PrintStackTraceSignalHandler(void*) 
/home/modocache/Source/llvm/git/dev/llvm/build/../lib/Support/Unix/Signals.inc:558:1
   #2 0x55a388bf8b32 llvm::sys::RunSignalHandlers() 
/home/modocache/Source/llvm/git/dev/llvm/build/../lib/Support/Signals.cpp:68:20
   #3 0x55a388bfa4fb SignalHandler(int) 
/home/modocache/Source/llvm/git/dev/llvm/build/../lib/Support/Unix/Signals.inc:357:1
   #4 0x7f909ab86dd0 __restore_rt 
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12dd0)
   #5 0x7f909a249077 raise 
/build/glibc-B9XfQf/glibc-2.28/signal/../sysdeps/unix/sysv/linux/raise.c:51:1
   #6 

Re: r360559 - [c++20] P1064R0: Allow virtual function calls in constant expression

[Richard Smith via cfe-commits]

Thanks for the revert and the reduced test case.

On Mon, 13 May 2019, 07:50 Hans Wennborg via cfe-commits, <
cfe-commits@lists.llvm.org> wrote:

> Here's a creduced repro:
>
> --
> class a {};
> class b : virtual a {
>   virtual bool c(const void *, int);
> };
> class C : b {
> public:
>   bool c(const void *, int);
> };
> int d;
> bool e() {
>   C f;
>   if (f.c(, d))
> ;
> }
> --
>
> $ clang.bad -cc1 -triple x86_64-unknown-linux-gnu -fsyntax-only -std=c++14
> a.cc
>
> The assert goes away if invoking clang with -w.
>
> From: Hans Wennborg 
> Date: Mon, May 13, 2019 at 3:16 PM
> To: Richard Smith
> Cc: cfe-commits
>
> > This caused asserts in Chromium, so I've reverted in r360580. There's
> > a repro at
> https://bugs.chromium.org/p/chromium/issues/detail?id=962458#c1,
> > and I'm working on a reduced version.
> >
> > From: Richard Smith via cfe-commits 
> > Date: Mon, May 13, 2019 at 9:39 AM
> > To: 
> >
> > > Author: rsmith
> > > Date: Mon May 13 00:42:10 2019
> > > New Revision: 360559
> > >
> > > URL: http://llvm.org/viewvc/llvm-project?rev=360559=rev
> > > Log:
> > > [c++20] P1064R0: Allow virtual function calls in constant expression
> > > evaluation.
> > >
> > > Modified:
> > > cfe/trunk/include/clang/AST/DeclCXX.h
> > > cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td
> > > cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> > > cfe/trunk/include/clang/Sema/Sema.h
> > > cfe/trunk/lib/AST/DeclCXX.cpp
> > > cfe/trunk/lib/AST/ExprConstant.cpp
> > > cfe/trunk/lib/Sema/SemaDeclCXX.cpp
> > > cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
> > > cfe/trunk/test/CXX/dcl.dcl/dcl.spec/dcl.constexpr/p3.cpp
> > > cfe/trunk/test/CXX/drs/dr18xx.cpp
> > > cfe/trunk/test/CXX/drs/dr6xx.cpp
> > > cfe/trunk/test/SemaCXX/constant-expression-cxx2a.cpp
> > > cfe/trunk/test/SemaCXX/cxx17-compat.cpp
> > > cfe/trunk/www/cxx_status.html
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D61765: [OpenMP][Clang][BugFix] Split declares and math functions inclusion.

[Artem Belevich via Phabricator via cfe-commits]

tra added a comment.

In D61765#1499957 , @jdoerfert wrote:

> Two small changes and then it is fine with me. @tra ?


LGTM in general. I would still like to confirm that the changes work with 
libc++.


Repository:
  rC Clang

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

https://reviews.llvm.org/D61765



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

[PATCH] D61865: [clangd] improve help message for limit-results

[Brennan Vincent via Phabricator via cfe-commits]

umanwizard created this revision.
umanwizard added a reviewer: clang-tools-extra.
Herald added subscribers: cfe-commits, kadircet, arphaman, jkorous, MaskRay, 
ilya-biryukov.
Herald added a project: clang.

Make it clear that the default is 100.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D61865

Files:
  clang-tools-extra/clangd/tool/ClangdMain.cpp


Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -117,7 +117,7 @@
 static llvm::cl::opt LimitResults(
 "limit-results",
 llvm::cl::desc("Limit the number of results returned by clangd. "
-   "0 means no limit."),
+   "0 means no limit. (default=100)"),
 llvm::cl::init(100));
 
 static llvm::cl::opt RunSynchronously(


Index: clang-tools-extra/clangd/tool/ClangdMain.cpp
===
--- clang-tools-extra/clangd/tool/ClangdMain.cpp
+++ clang-tools-extra/clangd/tool/ClangdMain.cpp
@@ -117,7 +117,7 @@
 static llvm::cl::opt LimitResults(
 "limit-results",
 llvm::cl::desc("Limit the number of results returned by clangd. "
-   "0 means no limit."),
+   "0 means no limit. (default=100)"),
 llvm::cl::init(100));
 
 static llvm::cl::opt RunSynchronously(
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D58035: [clang/DIVar] Emit flag for params that have unchanged values

[Adrian Prantl via Phabricator via cfe-commits]

aprantl added inline comments.



Comment at: lib/CodeGen/CGDebugInfo.cpp:3885
+  if (ArgNo) {
+auto *PD = dyn_cast(VD);
+ParmCache[PD].reset(D);

A `dyn_cast` followed by an unconditional use seems strange. I would expect 
either a `cast` or an `if (PD)` check.


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

https://reviews.llvm.org/D58035



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