[PATCH] D80079: [clang-format] [NFC] isCpp() is inconsistently used to mean both C++ and Objective C, add language specific isXXX() functions

2020-05-18 Thread Sam McCall via Phabricator via cfe-commits
sammccall added inline comments.



Comment at: clang/include/clang/Format/Format.h:1632
+  bool isCppOnly() const { return Language == LK_Cpp; }
+  bool isObjectiveC() const { return Language == LK_ObjC; }
+  bool isCpp() const { return isCppOnly() || isObjectiveC(); }

Just my 2c - I find the current meaning of isCpp easier to understand, and 
would prefer isObjectiveC to mean objective-C/C++. h if it exists.

Reasons:
 - this is consistent with LangOptions::CPlusPlus and LangOptions::ObjC
 - when checking for C++, also applying these rules to ObjC++ should be the 
common/default case, and excluding ObjC++ the special case that justifies more 
precise syntax (and honestly, I'd find `isCpp && !isObjC` to carry the clearest 
intent in that case). IOW, this seems like it will attract bugs.

> perhaps a better name for isCpp() is isCStyleLanguages()

Clang uses the term "C family languages", and this includes C, C++, ObjC, 
ObjC++.
If you really want to avoid the conflict between C++ the boolean language 
option and C++ the precise language mode, I'd suggest `isPlusPlus()` and 
`isObjective()`. But I think consistency with LangOptions is worth more.



Comment at: clang/include/clang/Format/Format.h:1635
   bool isCSharp() const { return Language == LK_CSharp; }
+  bool isProtoBuf() const { return Language == LK_Proto; }
+  bool isTableGen() const { return Language == LK_TableGen; }

These functions that don't *even in principle* do more than compare to an enum 
seem like extra indirection that hurts understanding of the code (have to look 
up what isObjectiveC() does, or have subtle bugs).

I suspect isCSharp() was added due to a misunderstanding of what isCpp() was 
for.


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

https://reviews.llvm.org/D80079



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


[PATCH] D79862: [clangd-remote] Replace YAML serialization with proper Protobuf messages

2020-05-18 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev updated this revision to Diff 264554.
kbobyrev added a comment.

Inline HeaderCode and MainCode.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79862

Files:
  clang-tools-extra/clangd/index/remote/Client.cpp
  clang-tools-extra/clangd/index/remote/Index.proto
  clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
  clang-tools-extra/clangd/unittests/CMakeLists.txt
  clang-tools-extra/clangd/unittests/TestTU.cpp
  clang-tools-extra/clangd/unittests/TestTU.h
  clang-tools-extra/clangd/unittests/remote/CMakeLists.txt
  clang-tools-extra/clangd/unittests/remote/MarshallingTests.cpp

Index: clang-tools-extra/clangd/unittests/remote/MarshallingTests.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/remote/MarshallingTests.cpp
@@ -0,0 +1,87 @@
+//===--- MarshallingTests.cpp *- C++-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "../TestTU.h"
+#include "index/Serialization.h"
+#include "index/remote/marshalling/Marshalling.h"
+#include "llvm/Support/StringSaver.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace clangd {
+namespace remote {
+namespace {
+
+class RemoteMarshallingTest : public ::testing::Test {
+public:
+  RemoteMarshallingTest() : Strings(NewArena) {
+TU.HeaderCode = R"(
+// This is a class.
+class Foo {
+public:
+  Foo();
+
+  int Bar;
+private:
+  double Number;
+};
+/// This is a function.
+char baz();
+template 
+T getT ();
+struct FooBar {};
+)";
+TU.Code = R"(
+const int GlobalVariable = 123;
+
+class ForwardDecl;
+char baz() { return 'x'; }
+template 
+T getT() { return T(); }
+Foo::Foo() : Bar(GlobalVariable), Number(42) {
+  for (int Counter = 0; Counter < GlobalVariable; ++Counter) {
+baz();
+getT();
+  }
+}
+)";
+  }
+
+  SymbolSlab symbols() { return TU.symbols(); }
+  RefSlab refs() { return TU.refs(); }
+
+  llvm::UniqueStringSaver Strings;
+
+private:
+  TestTU TU;
+  llvm::BumpPtrAllocator NewArena;
+};
+
+TEST_F(RemoteMarshallingTest, SymbolSerialization) {
+  for (auto  : symbols()) {
+const auto ProtobufMeessage = toProtobuf(Sym);
+const auto SymToProtobufAndBack = fromProtobuf(ProtobufMeessage, );
+EXPECT_TRUE(SymToProtobufAndBack.hasValue());
+EXPECT_EQ(toYAML(Sym), toYAML(*SymToProtobufAndBack));
+  }
+}
+
+TEST_F(RemoteMarshallingTest, ReferenceSerialization) {
+  for (const auto  : refs()) {
+for (const auto  : SymbolWithRefs.second) {
+  const auto RefToProtobufAndBack = fromProtobuf(toProtobuf(Ref), );
+  EXPECT_TRUE(RefToProtobufAndBack.hasValue());
+  EXPECT_EQ(toYAML(Ref), toYAML(*RefToProtobufAndBack));
+}
+  }
+}
+
+} // namespace
+} // namespace remote
+} // namespace clangd
+} // namespace clang
Index: clang-tools-extra/clangd/unittests/remote/CMakeLists.txt
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/remote/CMakeLists.txt
@@ -0,0 +1,26 @@
+set(LLVM_LINK_COMPONENTS
+  Support
+  )
+
+get_filename_component(CLANGD_SOURCE_DIR
+  ${CMAKE_CURRENT_SOURCE_DIR}/../../clangd REALPATH)
+include_directories(
+  ${CLANGD_SOURCE_DIR}
+  )
+
+include_directories(${CMAKE_CURRENT_BINARY_DIR}/../../index/remote)
+add_definitions(-DGOOGLE_PROTOBUF_NO_RTTI=1)
+
+add_custom_target(ClangdRemoteUnitTests)
+add_unittest(ClangdRemoteUnitTests ClangdRemoteTests
+  MarshallingTests.cpp
+
+  ../TestTU.cpp
+  ../TestFS.cpp
+  )
+
+target_link_libraries(ClangdRemoteTests
+  PRIVATE
+  clangDaemon
+  clangdRemoteMarshalling
+  )
Index: clang-tools-extra/clangd/unittests/TestTU.h
===
--- clang-tools-extra/clangd/unittests/TestTU.h
+++ clang-tools-extra/clangd/unittests/TestTU.h
@@ -70,6 +70,11 @@
   ParsedAST build() const;
   ParseInputs inputs() const;
   SymbolSlab headerSymbols() const;
+  RefSlab headerRefs() const;
+  // Returns all symbols from the header and main file.
+  SymbolSlab symbols() const;
+  // Returns all references from the header and main file.
+  RefSlab refs() const;
   std::unique_ptr index() const;
 };
 
Index: clang-tools-extra/clangd/unittests/TestTU.cpp
===
--- clang-tools-extra/clangd/unittests/TestTU.cpp
+++ clang-tools-extra/clangd/unittests/TestTU.cpp
@@ -113,6 +113,39 @@
 AST.getCanonicalIncludes()));
 }
 
+RefSlab TestTU::headerRefs() const {
+  auto AST = build();
+  return 

[PATCH] D79862: [clangd-remote] Replace YAML serialization with proper Protobuf messages

2020-05-18 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev updated this revision to Diff 264553.
kbobyrev added a comment.

Don't complicate SymbolCollectorTest, use TestTU.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79862

Files:
  clang-tools-extra/clangd/index/remote/Client.cpp
  clang-tools-extra/clangd/index/remote/Index.proto
  clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
  clang-tools-extra/clangd/unittests/CMakeLists.txt
  clang-tools-extra/clangd/unittests/TestTU.cpp
  clang-tools-extra/clangd/unittests/TestTU.h
  clang-tools-extra/clangd/unittests/remote/CMakeLists.txt
  clang-tools-extra/clangd/unittests/remote/MarshallingTests.cpp

Index: clang-tools-extra/clangd/unittests/remote/MarshallingTests.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/remote/MarshallingTests.cpp
@@ -0,0 +1,89 @@
+//===--- MarshallingTests.cpp *- C++-*-===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "../TestTU.h"
+#include "index/Serialization.h"
+#include "index/remote/marshalling/Marshalling.h"
+#include "llvm/Support/StringSaver.h"
+#include "gtest/gtest.h"
+
+namespace clang {
+namespace clangd {
+namespace remote {
+namespace {
+
+class RemoteMarshallingTest : public ::testing::Test {
+public:
+  RemoteMarshallingTest() : Strings(NewArena) {
+const std::string HeaderCode = R"(
+// This is a class.
+class Foo {
+public:
+  Foo();
+
+  int Bar;
+private:
+  double Number;
+};
+/// This is a function.
+char baz();
+template 
+T getT ();
+struct FooBar {};
+)";
+const std::string Main = R"(
+const int GlobalVariable = 123;
+
+class ForwardDecl;
+char baz() { return 'x'; }
+template 
+T getT() { return T(); }
+Foo::Foo() : Bar(GlobalVariable), Number(42) {
+  for (int Counter = 0; Counter < GlobalVariable; ++Counter) {
+baz();
+getT();
+  }
+}
+)";
+TU.HeaderCode = HeaderCode;
+TU.Code = Main;
+  }
+
+  SymbolSlab symbols() { return TU.symbols(); }
+  RefSlab refs() { return TU.refs(); }
+
+  llvm::UniqueStringSaver Strings;
+
+private:
+  TestTU TU;
+  llvm::BumpPtrAllocator NewArena;
+};
+
+TEST_F(RemoteMarshallingTest, SymbolSerialization) {
+  for (auto  : symbols()) {
+const auto ProtobufMeessage = toProtobuf(Sym);
+const auto SymToProtobufAndBack = fromProtobuf(ProtobufMeessage,
+); EXPECT_TRUE(SymToProtobufAndBack.hasValue());
+EXPECT_EQ(toYAML(Sym), toYAML(*SymToProtobufAndBack));
+  }
+}
+
+TEST_F(RemoteMarshallingTest, ReferenceSerialization) {
+  for (const auto  : refs()) {
+for (const auto  : SymbolWithRefs.second) {
+  const auto RefToProtobufAndBack = fromProtobuf(toProtobuf(Ref),
+  ); EXPECT_TRUE(RefToProtobufAndBack.hasValue());
+  EXPECT_EQ(toYAML(Ref), toYAML(*RefToProtobufAndBack));
+}
+  }
+}
+
+} // namespace
+} // namespace remote
+} // namespace clangd
+} // namespace clang
Index: clang-tools-extra/clangd/unittests/remote/CMakeLists.txt
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/remote/CMakeLists.txt
@@ -0,0 +1,26 @@
+set(LLVM_LINK_COMPONENTS
+  Support
+  )
+
+get_filename_component(CLANGD_SOURCE_DIR
+  ${CMAKE_CURRENT_SOURCE_DIR}/../../clangd REALPATH)
+include_directories(
+  ${CLANGD_SOURCE_DIR}
+  )
+
+include_directories(${CMAKE_CURRENT_BINARY_DIR}/../../index/remote)
+add_definitions(-DGOOGLE_PROTOBUF_NO_RTTI=1)
+
+add_custom_target(ClangdRemoteUnitTests)
+add_unittest(ClangdRemoteUnitTests ClangdRemoteTests
+  MarshallingTests.cpp
+
+  ../TestTU.cpp
+  ../TestFS.cpp
+  )
+
+target_link_libraries(ClangdRemoteTests
+  PRIVATE
+  clangDaemon
+  clangdRemoteMarshalling
+  )
Index: clang-tools-extra/clangd/unittests/TestTU.h
===
--- clang-tools-extra/clangd/unittests/TestTU.h
+++ clang-tools-extra/clangd/unittests/TestTU.h
@@ -70,6 +70,11 @@
   ParsedAST build() const;
   ParseInputs inputs() const;
   SymbolSlab headerSymbols() const;
+  RefSlab headerRefs() const;
+  // Returns all symbols from the header and main file.
+  SymbolSlab symbols() const;
+  // Returns all references from the header and main file.
+  RefSlab refs() const;
   std::unique_ptr index() const;
 };
 
Index: clang-tools-extra/clangd/unittests/TestTU.cpp
===
--- clang-tools-extra/clangd/unittests/TestTU.cpp
+++ clang-tools-extra/clangd/unittests/TestTU.cpp
@@ -113,6 +113,39 @@
 

[PATCH] D79961: [PGO] Fix computation of fuction Hash

2020-05-18 Thread Hans Wennborg via Phabricator via cfe-commits
hans added a comment.

Nice fix, and nice test :-)

May I ask how you found this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79961



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


[PATCH] D79704: [Analyzer] [NFC] Parameter Regions

2020-05-18 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware marked an inline comment as done.
baloghadamsoftware added a comment.

In D79704#2040798 , @NoQ wrote:

> > It turns out that parameter regions are never created for functions without 
> > `Decl` because of the first lines in 
> > `CallEvent::getCalleeAnalysisDeclContext()`.
>
> Removing these lines is more or less the whole point of your work.


Is it? The point of my work is to avoid the crashes you mentioned in 
D49443#1193290  by making the regions 
of the parameters independent of their declarations so we can remove the 
limitation that callee's stack frame is only created for functions with 
definition. (Can you provide me with examples which the crashes you mentioned 
with `VarRegions`? I need them for testing my solution.) It could be a future 
step to also remove the limitation that also allows getting the region for 
parameters without declaration. Even removing the original limitation (creation 
of stack frame without definition) is part of my planned subsequent patch, not 
this one. I am trying to follow incremental development to avoid too huge 
patches.




Comment at: clang/lib/StaticAnalyzer/Core/MemRegion.cpp:191
+const ParmVarDecl *ParamRegion::getDecl() const {
+  const Decl *D = getStackFrame()->getDecl();
+

NoQ wrote:
> baloghadamsoftware wrote:
> > NoQ wrote:
> > > baloghadamsoftware wrote:
> > > > NoQ wrote:
> > > > > baloghadamsoftware wrote:
> > > > > > NoQ wrote:
> > > > > > > This doesn't work when the callee is unknown.
> > > > > > Please give me an example where the callee is unknown. As I wrote, 
> > > > > > originally I put a `getExpr()` method here as well and `getType()` 
> > > > > > fell back to it if it could not find the `Decl()`. However, it was 
> > > > > > never invoked on the whole test suite. (I put an `assert(false)` 
> > > > > > into it, and did not get a crash.
> > > > > > Please give me an example where the callee is unknown.
> > > > > 
> > > > > >>! In D79704#2034571, @NoQ wrote:
> > > > > >>>! In D79704#2032947, @Szelethus wrote:
> > > > > >> Could you give a specific code example? 
> > > > > > 
> > > > > > ```lang=c++
> > > > > > struct S {
> > > > > >   S() {
> > > > > > this; // What region does 'this' point to...
> > > > > >   }
> > > > > > };
> > > > > > 
> > > > > > void foo(void (*bar)(S)) {
> > > > > >   bar(S()); // ...in this invocation?
> > > > > > }
> > > > > > ```
> > > > OK, but it still does not crash the analyzer, even if I enable creation 
> > > > of stack frames for all the callees, even for those without definition. 
> > > > What else should I do to enforce the crash (null pointer dereference)? 
> > > > Try to use `getParameterLocation()` in a unit test?
> > > Yes. I demonstrated how you can get the region without a decl but you 
> > > should turn this into a test that actually calls one of the problematic 
> > > functions. Like, `clang_analyzer_dump()` it or something.
> > Of  course I tried `clang_analyzer_explain()`, but neither 
> > `clang_analyzer_dump()` helps. I also tried a unit test now where I call 
> > `getParameterLocation()` explicitly. It turns out that parameter regions 
> > are never created for functions without `Decl` because of the first lines 
> > in `CallEvent::getCalleeAnalysisDeclContext()`. This function //needs// the 
> > `Decl` to retrieve the `AnalysisDeclContext` of the callee, which is needed 
> > to retrieve its stack  frame by `getCalleeStackFrame()`. Without stack 
> > frame we do not create `ParamRegion`. The other two functions creating 
> > `ParamRegion` (`CallEvent::addParameterValuesToBindings` and the newly 
> > created `MemRegionManager::getRegionForParam`) start from `ParmVarDecl` 
> > which always belongs to a `Decl`. So we can safely assume that currently 
> > all parameter regions have a `Decl`. Of course, this can be changed in the 
> > future, but I must not include dead code in a patch that cannot even be 
> > tested in the current phase. Even creation of callee stack frame for 
> > functions without //definition// is not part of this patch, but of the 
> > subsequent one.
> > neither `clang_analyzer_dump()` helps
> 
> So, does it dump a parameter region? Because it obviously should.
It dumps a temporary region as until now. So this patch does not change the 
behavior of the analyzer at this point.


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

https://reviews.llvm.org/D79704



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


[PATCH] D79325: [clang-format] [PR42164] Add Option to Break before While

2020-05-18 Thread Krasimir Georgiev via Phabricator via cfe-commits
krasimir accepted this revision.
krasimir added a comment.
This revision is now accepted and ready to land.

Thank you!


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

https://reviews.llvm.org/D79325



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


[PATCH] D80079: [clang-format] [NFC] isCpp() is inconsistently used to mean both C++ and Objective C, add language specific isXXX() functions

2020-05-18 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.

- I personally find the current form (Style.Language == LK_XXX) very verbose 
and difficult to read, especially when its in the middle of a large clause.
- Its clear to me that isCpp() is not understood, its name doesn't quite 
suggest what it does and as such there is code that effectively does if 
(isCpp() || isObjectiveC()) (which you can't easily see because of the verbose 
form)
- I added isCSharp() (I knew what isCpp() did) but I added it so it was very 
clear where the C# handling code was, I didn't want to proliferate the 
`Style.Language == LK_CSharp` , and also its easier to search for all 
`!Style.isCSharp()` and `Style.isCSharp()` in one go rather than having to 
handle the `!=/==` cases

I think functions need to be named to say what they do, and isCpp() currently 
doesn't and it has/does already cause mistakes. I don't mind what its called 
I'm happy to change names, but I feel there is more clarity in the isXXX() 
calls.

This has been on of those refactorings I've wanted to do over the last year as 
I've been working on clang-format, I was expecting it to be controversial: ;-)

My 2p worth.


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

https://reviews.llvm.org/D80079



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


[PATCH] D79961: [PGO] Fix computation of fuction Hash

2020-05-18 Thread serge via Phabricator via cfe-commits
serge-sans-paille updated this revision to Diff 264552.
serge-sans-paille edited the summary of this revision.
serge-sans-paille added a comment.

Updated summary + removed namespace.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79961

Files:
  clang/lib/CodeGen/CodeGenPGO.cpp
  clang/test/Profile/c-collision.c


Index: clang/test/Profile/c-collision.c
===
--- /dev/null
+++ clang/test/Profile/c-collision.c
@@ -0,0 +1,22 @@
+// Test that a slight change in the code leads to a different hash.
+// RUN: %clang_cc1 -UEXTRA -triple x86_64-unknown-linux-gnu -main-file-name 
c-collision.c %s -o - -emit-llvm -fprofile-instrument=clang | FileCheck %s 
--check-prefix=CHECK-NOEXTRA
+// RUN: %clang_cc1 -DEXTRA -triple x86_64-unknown-linux-gnu -main-file-name 
c-collision.c %s -o - -emit-llvm -fprofile-instrument=clang | FileCheck %s 
--check-prefix=CHECK-EXTRA
+
+// CHECK-NOEXTRA: @__profd_foo = private global { {{.*}} } { i64 
6699318081062747564, i64 7156072912471487002,
+// CHECK-EXTRA:   @__profd_foo = private global { {{.*}} } { i64 
6699318081062747564, i64 -4383447408116050035,
+
+extern int bar;
+void foo() {
+  if (bar) {
+  }
+  if (bar) {
+  }
+  if (bar) {
+if (bar) {
+#ifdef EXTRA
+  if (bar) {
+  }
+#endif
+}
+  }
+}
Index: clang/lib/CodeGen/CodeGenPGO.cpp
===
--- clang/lib/CodeGen/CodeGenPGO.cpp
+++ clang/lib/CodeGen/CodeGenPGO.cpp
@@ -747,13 +747,15 @@
 return Working;
 
   // Check for remaining work in Working.
-  if (Working)
-MD5.update(Working);
+  if (Working) {
+using namespace llvm::support;
+uint64_t Swapped = endian::byte_swap(Working);
+MD5.update(llvm::makeArrayRef((uint8_t *), sizeof(Swapped)));
+  }
 
   // Finalize the MD5 and return the hash.
   llvm::MD5::MD5Result Result;
   MD5.final(Result);
-  using namespace llvm::support;
   return Result.low();
 }
 


Index: clang/test/Profile/c-collision.c
===
--- /dev/null
+++ clang/test/Profile/c-collision.c
@@ -0,0 +1,22 @@
+// Test that a slight change in the code leads to a different hash.
+// RUN: %clang_cc1 -UEXTRA -triple x86_64-unknown-linux-gnu -main-file-name c-collision.c %s -o - -emit-llvm -fprofile-instrument=clang | FileCheck %s --check-prefix=CHECK-NOEXTRA
+// RUN: %clang_cc1 -DEXTRA -triple x86_64-unknown-linux-gnu -main-file-name c-collision.c %s -o - -emit-llvm -fprofile-instrument=clang | FileCheck %s --check-prefix=CHECK-EXTRA
+
+// CHECK-NOEXTRA: @__profd_foo = private global { {{.*}} } { i64 6699318081062747564, i64 7156072912471487002,
+// CHECK-EXTRA:   @__profd_foo = private global { {{.*}} } { i64 6699318081062747564, i64 -4383447408116050035,
+
+extern int bar;
+void foo() {
+  if (bar) {
+  }
+  if (bar) {
+  }
+  if (bar) {
+if (bar) {
+#ifdef EXTRA
+  if (bar) {
+  }
+#endif
+}
+  }
+}
Index: clang/lib/CodeGen/CodeGenPGO.cpp
===
--- clang/lib/CodeGen/CodeGenPGO.cpp
+++ clang/lib/CodeGen/CodeGenPGO.cpp
@@ -747,13 +747,15 @@
 return Working;
 
   // Check for remaining work in Working.
-  if (Working)
-MD5.update(Working);
+  if (Working) {
+using namespace llvm::support;
+uint64_t Swapped = endian::byte_swap(Working);
+MD5.update(llvm::makeArrayRef((uint8_t *), sizeof(Swapped)));
+  }
 
   // Finalize the MD5 and return the hash.
   llvm::MD5::MD5Result Result;
   MD5.final(Result);
-  using namespace llvm::support;
   return Result.low();
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D80109: [AST][RecoveryExpr] Preserve type for broken member call expr.

2020-05-18 Thread Haojian Wu via Phabricator via cfe-commits
hokein created this revision.
hokein added a reviewer: sammccall.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80109

Files:
  clang/lib/Sema/SemaOverload.cpp
  clang/test/AST/ast-dump-recovery.cpp

Index: clang/test/AST/ast-dump-recovery.cpp
===
--- clang/test/AST/ast-dump-recovery.cpp
+++ clang/test/AST/ast-dump-recovery.cpp
@@ -101,6 +101,29 @@
   foo->func(x);
 }
 
+// CHECK:  FunctionDecl {{.*}} test2
+// CHECK-NEXT: |-ParmVarDecl {{.*}} f
+// CHECK-NEXT: `-CompoundStmt
+// CHECK-NEXT:   |-RecoveryExpr {{.*}} 'int' contains-errors
+// CHECK-NEXT: `-UnresolvedMemberExpr
+// CHECK-NEXT:   `-DeclRefExpr {{.*}} 'Foo2'
+// CHECK-NEXT:   `-RecoveryExpr {{.*}} ''
+// CHECK-NEXT: |-MemberExpr {{.*}} ''
+// CHECK-NEXT: | `-DeclRefExpr {{.*}}
+// CHECK-NEXT:   `-IntegerLiteral {{.*}} 'int' 1
+struct Foo2 {
+  int overload(int);
+  int overload(int, int);
+
+  double func();
+};
+void test2(Foo2 f) {
+  f.overload(); // verify "int" is preserved
+
+  // FIXME: capture the type!
+  f.func(1);
+}
+
 // CHECK: |-AlignedAttr {{.*}} alignas
 // CHECK-NEXT:| `-RecoveryExpr {{.*}} contains-errors
 // CHECK-NEXT:|   `-UnresolvedLookupExpr {{.*}} 'invalid'
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -14080,14 +14080,17 @@
 UnbridgedCasts.restore();
 
 OverloadCandidateSet::iterator Best;
+bool Succeeded = true;
 switch (CandidateSet.BestViableFunction(*this, UnresExpr->getBeginLoc(),
 Best)) {
 case OR_Success:
   Method = cast(Best->Function);
   FoundDecl = Best->FoundDecl;
   CheckUnresolvedMemberAccess(UnresExpr, Best->FoundDecl);
-  if (DiagnoseUseOfDecl(Best->FoundDecl, UnresExpr->getNameLoc()))
-return ExprError();
+  if (DiagnoseUseOfDecl(Best->FoundDecl, UnresExpr->getNameLoc())) {
+Succeeded = false;
+break;
+  }
   // If FoundDecl is different from Method (such as if one is a template
   // and the other a specialization), make sure DiagnoseUseOfDecl is
   // called on both.
@@ -14096,7 +14099,7 @@
   // being used.
   if (Method != FoundDecl.getDecl() &&
   DiagnoseUseOfDecl(Method, UnresExpr->getNameLoc()))
-return ExprError();
+Succeeded = false;
   break;
 
 case OR_No_Viable_Function:
@@ -14106,8 +14109,8 @@
   PDiag(diag::err_ovl_no_viable_member_function_in_call)
   << DeclName << MemExprE->getSourceRange()),
   *this, OCD_AllCandidates, Args);
-  // FIXME: Leaking incoming expressions!
-  return ExprError();
+  Succeeded = false;
+  break;
 
 case OR_Ambiguous:
   CandidateSet.NoteCandidates(
@@ -14115,8 +14118,8 @@
   PDiag(diag::err_ovl_ambiguous_member_call)
   << DeclName << MemExprE->getSourceRange()),
   *this, OCD_AmbiguousCandidates, Args);
-  // FIXME: Leaking incoming expressions!
-  return ExprError();
+  Succeeded = false;
+  break;
 
 case OR_Deleted:
   CandidateSet.NoteCandidates(
@@ -14124,9 +14127,14 @@
   PDiag(diag::err_ovl_deleted_member_call)
   << DeclName << MemExprE->getSourceRange()),
   *this, OCD_AllCandidates, Args);
-  // FIXME: Leaking incoming expressions!
-  return ExprError();
+  Succeeded = false;
+  break;
 }
+// Overload resolvation fails, try to recover.
+if (!Succeeded)
+  return CreateRecoveryExpr(MemExprE->getBeginLoc(), MemExprE->getEndLoc(),
+{MemExprE},
+chooseRecoveryType(CandidateSet, ));
 
 MemExprE = FixOverloadedFunctionReference(MemExprE, FoundDecl, Method);
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79950: [clangd] Avoid wasteful data structures in RefSlab::Builder

2020-05-18 Thread Kirill Bobyrev via Phabricator via cfe-commits
kbobyrev accepted this revision.
kbobyrev added a comment.
This revision is now accepted and ready to land.

LGTM with a couple of nits.

Thank you for the patch, this is a good idea!




Comment at: clang-tools-extra/clangd/index/Ref.cpp:11
+#include "llvm/ADT/STLExtras.h"
+#include "llvm/Support/Allocator.h"
+#include "llvm/Support/StringSaver.h"

This defines `BumpPtrAllocator`, right? I think it should be included in 
`clang-tools-extra/clangd/index/Ref.h`, not here if the intent is to explicitly 
include used headers. Same for `StringSaver.h`, this source file does not use 
any additional variables of these types.



Comment at: clang-tools-extra/clangd/index/Ref.h:140
+  SymbolID Symbol;
+  Ref R;
+};

nit: I know you like the short names, but with `R` I had to get back to `Entry` 
definition each time I saw it (I was thinking "wait, `R`? is there an `L` 
somewhere here?". Maybe it's just me, but one-letter fields seem scary. Maybe 
`Reference`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79950



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


[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

2020-05-18 Thread Ties Stuij via Phabricator via cfe-commits
stuij updated this revision to Diff 264560.
stuij added a comment.

addressing review comments and adding Simon Tatham to contributers


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76077

Files:
  clang/include/clang/Basic/arm_neon.td


Index: clang/include/clang/Basic/arm_neon.td
===
--- clang/include/clang/Basic/arm_neon.td
+++ clang/include/clang/Basic/arm_neon.td
@@ -247,6 +247,12 @@

"UcUsUicsilPcPsfQUcQUsQUiQcQsQiQPcQPsQflUlQlQUlhdQhQdPlQPl"> {
   let isLaneQ = 1;
 }
+let ArchGuard = "defined(__ARM_FEATURE_BF16_VECTOR_ARITHMETIC)" in {
+  def SPLAT_BF  : WInst<"splat_lane", ".(!q)I", "bQb">;
+  def SPLATQ_BF : WInst<"splat_laneq", ".(!Q)I", "bQb"> {
+let isLaneQ = 1;
+  }
+}
 
 
//===--===//
 // Intrinsics


Index: clang/include/clang/Basic/arm_neon.td
===
--- clang/include/clang/Basic/arm_neon.td
+++ clang/include/clang/Basic/arm_neon.td
@@ -247,6 +247,12 @@
"UcUsUicsilPcPsfQUcQUsQUiQcQsQiQPcQPsQflUlQlQUlhdQhQdPlQPl"> {
   let isLaneQ = 1;
 }
+let ArchGuard = "defined(__ARM_FEATURE_BF16_VECTOR_ARITHMETIC)" in {
+  def SPLAT_BF  : WInst<"splat_lane", ".(!q)I", "bQb">;
+  def SPLATQ_BF : WInst<"splat_laneq", ".(!Q)I", "bQb"> {
+let isLaneQ = 1;
+  }
+}
 
 //===--===//
 // Intrinsics
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D80079: [clang-format] [NFC] isCpp() is inconsistently used to mean both C++ and Objective C, add language specific isXXX() functions

2020-05-18 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay marked 2 inline comments as done.
MyDeveloperDay added inline comments.



Comment at: clang/lib/Format/TokenAnnotator.cpp:3443
- Style.Language == FormatStyle::LK_TextProto) {
+  } else if (Style.isCpp() || Style.isProtoBuf() || Style.isTableGen() ||
+ Style.isTextProtoBuf()) {
 if (Left.isStringLiteral() && Right.isStringLiteral())
   return true;

Here is an example of where the language is checked to be both LK_cpp and 
LK_ObjC when just one isCpp() would have done.



Comment at: clang/lib/Format/TokenAnnotator.cpp:3645
-  Left.is(tok::l_paren) && Left.BlockParameterCount > 0 &&
+  if ((Style.isCpp()) && Left.is(tok::l_paren) &&
+  Left.BlockParameterCount > 0 &&
   !Right.isOneOf(tok::l_paren, TT_LambdaLSquare)) {
 // Multiple lambdas in the same function call force line breaks.

Again here, why not isCpp() here?


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

https://reviews.llvm.org/D80079



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


[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

2020-05-18 Thread Ties Stuij via Phabricator via cfe-commits
stuij updated this revision to Diff 264562.
stuij added a comment.

redo: addressing review comments and adding Simon Tatham to contributers


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76077

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang-c/Index.h
  clang/include/clang/AST/ASTContext.h
  clang/include/clang/AST/BuiltinTypes.def
  clang/include/clang/AST/Type.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/Specifiers.h
  clang/include/clang/Basic/TargetBuiltins.h
  clang/include/clang/Basic/TargetInfo.h
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Sema/DeclSpec.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/ASTContext.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/MicrosoftMangle.cpp
  clang/lib/AST/NSAPI.cpp
  clang/lib/AST/PrintfFormatString.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypeLoc.cpp
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/AArch64.h
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Basic/Targets/ARM.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/lib/CodeGen/CodeGenTypeCache.h
  clang/lib/CodeGen/CodeGenTypes.cpp
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Format/FormatToken.cpp
  clang/lib/Index/USRGeneration.cpp
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Parse/ParseTentative.cpp
  clang/lib/Sema/DeclSpec.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/lib/Sema/SemaTemplateVariadic.cpp
  clang/lib/Sema/SemaType.cpp
  clang/lib/Serialization/ASTCommon.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/test/CodeGen/arm-bf16-params-returns.c
  clang/test/CodeGen/arm-mangle-16bit-float.cpp
  clang/test/Sema/arm-bf16-forbidden-ops.c
  clang/test/Sema/arm-bf16-forbidden-ops.cpp
  clang/test/Sema/arm-bfloat.cpp
  clang/tools/libclang/CXType.cpp

Index: clang/tools/libclang/CXType.cpp
===
--- clang/tools/libclang/CXType.cpp
+++ clang/tools/libclang/CXType.cpp
@@ -608,6 +608,7 @@
 TKIND(Elaborated);
 TKIND(Pipe);
 TKIND(Attributed);
+TKIND(BFloat16);
 #define IMAGE_TYPE(ImgType, Id, SingletonId, Access, Suffix) TKIND(Id);
 #include "clang/Basic/OpenCLImageTypes.def"
 #undef IMAGE_TYPE
Index: clang/test/Sema/arm-bfloat.cpp
===
--- /dev/null
+++ clang/test/Sema/arm-bfloat.cpp
@@ -0,0 +1,29 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 \
+// RUN: -triple aarch64-arm-none-eabi -target-cpu cortex-a75 \
+// RUN: -target-feature +bf16 -target-feature +neon %s
+// RUN: %clang_cc1 -fsyntax-only -verify -std=c++11 \
+// RUN: -triple arm-arm-none-eabi -target-cpu cortex-a53 \
+// RUN: -target-feature +bf16 -target-feature +neon %s
+
+void test(bool b) {
+  __bf16 bf16;
+
+  bf16 + bf16; // expected-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
+  bf16 - bf16; // expected-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
+  bf16 * bf16; // expected-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
+  bf16 / bf16; // expected-error {{invalid operands to binary expression ('__bf16' and '__bf16')}}
+
+  __fp16 fp16;
+
+  bf16 + fp16; // expected-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
+  fp16 + bf16; // expected-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
+  bf16 - fp16; // expected-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
+  fp16 - bf16; // expected-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
+  bf16 * fp16; // expected-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
+  fp16 * bf16; // expected-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
+  bf16 / fp16; // expected-error {{invalid operands to binary expression ('__bf16' and '__fp16')}}
+  fp16 / bf16; // expected-error {{invalid operands to binary expression ('__fp16' and '__bf16')}}
+  bf16 = fp16; // expected-error {{assigning to '__bf16' from incompatible type '__fp16'}}
+  fp16 = bf16; // expected-error {{assigning to '__fp16' from incompatible type '__bf16'}}
+  bf16 + (b ? fp16 : bf16); // expected-error {{incompatible operand types ('__fp16' and '__bf16')}}
+}
Index: clang/test/Sema/arm-bf16-forbidden-ops.cpp
===
--- /dev/null
+++ clang/test/Sema/arm-bf16-forbidden-ops.cpp
@@ -0,0 +1,71 @@
+// RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64 -target-feature +bf16 %s

[PATCH] D80109: [AST][RecoveryExpr] Preserve type for broken member call expr.

2020-05-18 Thread Haojian Wu via Phabricator via cfe-commits
hokein marked an inline comment as done.
hokein added inline comments.



Comment at: clang/lib/Sema/SemaOverload.cpp:14105
 
 case OR_No_Viable_Function:
   CandidateSet.NoteCandidates(

It is a bit sad that the broken function call cases (too many/few agguments) 
are failing into this group, all candidates are not viable -- this means we 
don't get any benefits (no `Best`), for some cases, it is suboptimal even 
though the best candidate looks like obvious.

```
class Collection {
  const char *find(int) const;
  char* find(int);
};
void test1(const Collection ) {
 C.find(); // we want const char*, but all overloads are not viable and return 
types are not the same, so no type captured here.
}
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80109



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


[clang-tools-extra] 4f0cc10 - [NFC][clang-tidy] use hasOperands in place of hasEitherOperand

2020-05-18 Thread Nathan James via cfe-commits

Author: Nathan James
Date: 2020-05-18T10:11:22+01:00
New Revision: 4f0cc10bf5d0009a9d00565fedb34933c2adf8f6

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

LOG: [NFC][clang-tidy] use hasOperands in place of hasEitherOperand

Added: 


Modified: 
clang-tools-extra/clang-tidy/abseil/StringFindStartswithCheck.cpp
clang-tools-extra/clang-tidy/bugprone/SizeofExpressionCheck.cpp
clang-tools-extra/clang-tidy/bugprone/SuspiciousEnumUsageCheck.cpp
clang-tools-extra/clang-tidy/bugprone/SuspiciousStringCompareCheck.cpp
clang-tools-extra/clang-tidy/misc/RedundantExpressionCheck.cpp
clang-tools-extra/clang-tidy/readability/DeleteNullPointerCheck.cpp
clang-tools-extra/clang-tidy/readability/RedundantSmartptrGetCheck.cpp
clang-tools-extra/clang-tidy/readability/StringCompareCheck.cpp

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/abseil/StringFindStartswithCheck.cpp 
b/clang-tools-extra/clang-tidy/abseil/StringFindStartswithCheck.cpp
index 513714e99cb8..9539e28cd790 100644
--- a/clang-tools-extra/clang-tidy/abseil/StringFindStartswithCheck.cpp
+++ b/clang-tools-extra/clang-tidy/abseil/StringFindStartswithCheck.cpp
@@ -52,8 +52,8 @@ void StringFindStartswithCheck::registerMatchers(MatchFinder 
*Finder) {
   // Match [=!]= with a zero on one side and a string.find on the other.
   binaryOperator(
   hasAnyOperatorName("==", "!="),
-  hasEitherOperand(ignoringParenImpCasts(ZeroLiteral)),
-  hasEitherOperand(ignoringParenImpCasts(StringFind.bind("findexpr"
+  hasOperands(ignoringParenImpCasts(ZeroLiteral),
+  ignoringParenImpCasts(StringFind.bind("findexpr"
   .bind("expr"),
   this);
 }

diff  --git a/clang-tools-extra/clang-tidy/bugprone/SizeofExpressionCheck.cpp 
b/clang-tools-extra/clang-tidy/bugprone/SizeofExpressionCheck.cpp
index ecaee65b2ea6..39526dab79ae 100644
--- a/clang-tools-extra/clang-tidy/bugprone/SizeofExpressionCheck.cpp
+++ b/clang-tools-extra/clang-tidy/bugprone/SizeofExpressionCheck.cpp
@@ -163,10 +163,10 @@ void SizeofExpressionCheck::registerMatchers(MatchFinder 
*Finder) {
   if (WarnOnSizeOfCompareToConstant) {
 Finder->addMatcher(
 binaryOperator(matchers::isRelationalOperator(),
-   hasEitherOperand(ignoringParenImpCasts(SizeOfExpr)),
-   hasEitherOperand(ignoringParenImpCasts(
-   anyOf(integerLiteral(equals(0)),
- integerLiteral(isBiggerThan(0x8))
+   hasOperands(ignoringParenImpCasts(SizeOfExpr),
+   ignoringParenImpCasts(anyOf(
+   integerLiteral(equals(0)),
+   
integerLiteral(isBiggerThan(0x8))
 .bind("sizeof-compare-constant"),
 this);
   }
@@ -205,10 +205,11 @@ void SizeofExpressionCheck::registerMatchers(MatchFinder 
*Finder) {
 
   Finder->addMatcher(
   binaryOperator(hasOperatorName("*"),
- hasEitherOperand(ignoringParenImpCasts(SizeOfExpr)),
- hasEitherOperand(ignoringParenImpCasts(binaryOperator(
- hasOperatorName("*"),
- 
hasEitherOperand(ignoringParenImpCasts(SizeOfExpr))
+ hasOperands(ignoringParenImpCasts(SizeOfExpr),
+ ignoringParenImpCasts(binaryOperator(
+ hasOperatorName("*"),
+ hasEitherOperand(
+ ignoringParenImpCasts(SizeOfExpr))
   .bind("sizeof-multiply-sizeof"),
   this);
 
@@ -232,12 +233,12 @@ void SizeofExpressionCheck::registerMatchers(MatchFinder 
*Finder) {
   Finder->addMatcher(
   binaryOperator(
   hasAnyOperatorName("==", "!=", "<", "<=", ">", ">=", "+", "-"),
-  hasEitherOperand(expr(anyOf(
-  ignoringParenImpCasts(SizeOfExpr),
-  ignoringParenImpCasts(binaryOperator(
-  hasOperatorName("*"),
-  hasEitherOperand(ignoringParenImpCasts(SizeOfExpr))),
-  hasEitherOperand(ignoringParenImpCasts(PtrDiffExpr)))
+  hasOperands(expr(anyOf(ignoringParenImpCasts(SizeOfExpr),
+ ignoringParenImpCasts(binaryOperator(
+ hasOperatorName("*"),
+ hasEitherOperand(
+ 
ignoringParenImpCasts(SizeOfExpr)),
+  ignoringParenImpCasts(PtrDiffExpr)))
   .bind("sizeof-in-ptr-arithmetic-mul"),
   this);
 

diff  --git 

[PATCH] D79992: [WIP][clangd] Patch PP directives to use stale preambles while building ASTs

2020-05-18 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet updated this revision to Diff 264567.
kadircet added a comment.

- Only store defines
- Make use of source text directly instead of printing tokens


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79992

Files:
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/unittests/PreambleTests.cpp

Index: clang-tools-extra/clangd/unittests/PreambleTests.cpp
===
--- clang-tools-extra/clangd/unittests/PreambleTests.cpp
+++ clang-tools-extra/clangd/unittests/PreambleTests.cpp
@@ -26,6 +26,7 @@
 #include 
 #include 
 
+using testing::Contains;
 using testing::Field;
 
 namespace clang {
@@ -181,6 +182,61 @@
   ElementsAre(AllOf(Field(::Written, "\"a.h\""),
 Field(::Resolved, testPath("a.h");
 }
+
+llvm::Optional createPatchedAST(llvm::StringRef Baseline,
+   llvm::StringRef Modified) {
+  auto BaselinePreamble = TestTU::withCode(Baseline).buildPreamble();
+  if (!BaselinePreamble) {
+ADD_FAILURE() << "Failed to build baseline preamble";
+return llvm::None;
+  }
+
+  IgnoreDiagnostics Diags;
+  auto TU = TestTU::withCode(Modified);
+  auto CI = buildCompilerInvocation(TU.inputs(), Diags);
+  if (!CI) {
+ADD_FAILURE() << "Failed to build compiler invocation";
+return llvm::None;
+  }
+  return ParsedAST::build(testPath("main.cpp"), TU.inputs(), std::move(CI), {},
+  BaselinePreamble);
+}
+
+TEST(PreamblePatchTest, Define) {
+  // BAR should be defined while parsing the AST.
+  llvm::StringLiteral Cases[] = {
+  R"cpp(
+#define BAR(X) X
+[[BAR]](int y);)cpp",
+  // multiline macro
+  R"cpp(
+#define BAR(X) \
+X
+[[BAR]](int y);)cpp",
+  };
+
+  for (llvm::StringLiteral Case : Cases) {
+Annotations Modified(Case);
+auto AST = createPatchedAST("", Modified.code());
+ASSERT_TRUE(AST);
+EXPECT_THAT(AST->getDiagnostics(),
+Not(Contains(Field(::Range, Modified.range();
+  }
+}
+
+TEST(PreamblePatchTest, OrderingPreserved) {
+  llvm::StringLiteral Baseline = "#define BAR(X) X";
+  Annotations Modified(R"cpp(
+#define BAR(X, Y) X Y
+#define BAR(X) X
+[[BAR]](int y);
+  )cpp");
+
+  auto AST = createPatchedAST(Baseline, Modified.code());
+  ASSERT_TRUE(AST);
+  EXPECT_THAT(AST->getDiagnostics(),
+  Not(Contains(Field(::Range, Modified.range();
+}
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/Preamble.cpp
===
--- clang-tools-extra/clangd/Preamble.cpp
+++ clang-tools-extra/clangd/Preamble.cpp
@@ -15,6 +15,7 @@
 #include "clang/Basic/Diagnostic.h"
 #include "clang/Basic/LangOptions.h"
 #include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/SourceManager.h"
 #include "clang/Basic/TokenKinds.h"
 #include "clang/Frontend/CompilerInvocation.h"
 #include "clang/Frontend/FrontendActions.h"
@@ -106,14 +107,64 @@
   const SourceManager *SourceMgr = nullptr;
 };
 
-/// Gets the includes in the preamble section of the file by running
-/// preprocessor over \p Contents. Returned includes do not contain resolved
-/// paths. \p VFS and \p Cmd is used to build the compiler invocation, which
-/// might stat/read files.
-llvm::Expected>
-scanPreambleIncludes(llvm::StringRef Contents,
- llvm::IntrusiveRefCntPtr VFS,
- const tooling::CompileCommand ) {
+struct TextualPPDirective {
+  unsigned DirectiveLine;
+  // Full text that's representing the directive, including the `#`.
+  std::string Text;
+
+  bool operator==(const TextualPPDirective ) const {
+return std::tie(DirectiveLine, Text) ==
+   std::tie(RHS.DirectiveLine, RHS.Text);
+  }
+};
+
+// Collects #define directives inside the main file.
+struct DirectiveCollector : public PPCallbacks {
+  DirectiveCollector(const Preprocessor ,
+ std::vector )
+  : SM(PP.getSourceManager()), TextualDirectives(TextualDirectives) {}
+
+  void FileChanged(SourceLocation Loc, FileChangeReason Reason,
+   SrcMgr::CharacteristicKind FileType,
+   FileID PrevFID) override {
+InMainFile = SM.isWrittenInMainFile(Loc);
+  }
+
+  void MacroDefined(const Token ,
+const MacroDirective *MD) override {
+if (!InMainFile)
+  return;
+TextualDirectives.emplace_back();
+TextualPPDirective  = TextualDirectives.back();
+
+auto DecompLoc = SM.getDecomposedLoc(MacroNameTok.getLocation());
+TD.DirectiveLine = SM.getLineNumber(DecompLoc.first, DecompLoc.second);
+
+SourceRange DefRange(MD->getMacroInfo()->getDefinitionLoc(),
+ MD->getMacroInfo()->getDefinitionEndLoc());
+llvm::raw_string_ostream OS(TD.Text);
+

[PATCH] D80025: [ASTMatcher] Correct memoization bug ignoring direction (descendants or ancestors)

2020-05-18 Thread Nathan James via Phabricator via cfe-commits
njames93 added a comment.

This needs rebasing against trunk


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80025



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


[PATCH] D80025: [ASTMatcher] Correct memoization bug ignoring direction (descendants or ancestors)

2020-05-18 Thread Manuel Klimek via Phabricator via cfe-commits
klimek added inline comments.



Comment at: clang/lib/ASTMatchers/ASTMatchFinder.cpp:46-49
+enum class MatchDirection {
+  Ancestors,
+  Descendants
+};

Nice find! Why don't we need more states though?
1. wouldn't hasParent() followed by a hasAncestor() also trigger the 
memoization? (if so, we'd need transitive / non-transitive)
2. can we trigger a directional match and a non-directional (non-traversal, for 
example, explicit) match in the same memoization scope?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80025



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


[clang-tools-extra] 968d293 - [clang-tidy] NFC: Cleanup Python scripts

2020-05-18 Thread Kirill Bobyrev via cfe-commits

Author: Kirill Bobyrev
Date: 2020-05-18T12:21:27+02:00
New Revision: 968d293063bc008ff93ff8fcf363039ce61574a2

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

LOG: [clang-tidy] NFC: Cleanup Python scripts

Summary: Silence few PEP8 warnings.

Reviewers: hokein

Reviewed By: hokein

Subscribers: Eugene.Zelenko, xazax.hun, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang-tools-extra/clang-tidy/add_new_check.py
clang-tools-extra/clang-tidy/rename_check.py
clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
clang-tools-extra/clang-tidy/tool/run-clang-tidy.py

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/add_new_check.py 
b/clang-tools-extra/clang-tidy/add_new_check.py
index 4477444cc127..454d128a5dcb 100755
--- a/clang-tools-extra/clang-tidy/add_new_check.py
+++ b/clang-tools-extra/clang-tidy/add_new_check.py
@@ -1,12 +1,12 @@
 #!/usr/bin/env python
 #
-#===- add_new_check.py - clang-tidy check generator --*- python 
-*--===#
+#===- add_new_check.py - clang-tidy check generator -*- python -*--===#
 #
 # Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 # See https://llvm.org/LICENSE.txt for license information.
 # SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 #
-#======#
+#===---===#
 
 from __future__ import print_function
 
@@ -15,8 +15,9 @@
 import re
 import sys
 
-# Adapts the module's CMakelist file. Returns 'True' if it could add a new 
entry
-# and 'False' if the entry already existed.
+
+# Adapts the module's CMakelist file. Returns 'True' if it could add a new
+# entry and 'False' if the entry already existed.
 def adapt_cmake(module_path, check_name_camel):
   filename = os.path.join(module_path, 'CMakeLists.txt')
   with open(filename, 'r') as f:
@@ -227,7 +228,6 @@ def add_release_notes(module_path, module, check_name):
   with open(filename, 'w') as f:
 note_added = False
 header_found = False
-next_header_found = False
 add_note_here = False
 
 for line in lines:
@@ -241,7 +241,6 @@ def add_release_notes(module_path, module, check_name):
 add_note_here = True
 
 if match_next:
-  next_header_found = True
   add_note_here = True
 
 if match:

diff  --git a/clang-tools-extra/clang-tidy/rename_check.py 
b/clang-tools-extra/clang-tidy/rename_check.py
index 528c2a19a2b7..4d5311c9a293 100755
--- a/clang-tools-extra/clang-tidy/rename_check.py
+++ b/clang-tools-extra/clang-tidy/rename_check.py
@@ -1,12 +1,12 @@
 #!/usr/bin/env python
 #
-#===- rename_check.py - clang-tidy check renamer -*- python 
-*--===#
+#===- rename_check.py - clang-tidy check renamer *- python -*--===#
 #
 # Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 # See https://llvm.org/LICENSE.txt for license information.
 # SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 #
-#======#
+#===---===#
 
 import argparse
 import glob
@@ -26,6 +26,7 @@ def replaceInFileRegex(fileName, sFrom, sTo):
   with open(fileName, "w") as f:
 f.write(txt)
 
+
 def replaceInFile(fileName, sFrom, sTo):
   if sFrom == sTo:
 return
@@ -66,6 +67,7 @@ def fileRename(fileName, sFrom, sTo):
   os.rename(fileName, newFileName)
   return newFileName
 
+
 def deleteMatchingLines(fileName, pattern):
   lines = None
   with open(fileName, "r") as f:
@@ -82,6 +84,7 @@ def deleteMatchingLines(fileName, pattern):
 
   return True
 
+
 def getListOfFiles(clang_tidy_path):
   files = glob.glob(os.path.join(clang_tidy_path, '*'))
   for dirname in files:
@@ -93,8 +96,9 @@ def getListOfFiles(clang_tidy_path):
   'clang-tidy', 'checks', '*'))
   return [filename for filename in files if os.path.isfile(filename)]
 
-# Adapts the module's CMakelist file. Returns 'True' if it could add a new 
entry
-# and 'False' if the entry already existed.
+
+# Adapts the module's CMakelist file. Returns 'True' if it could add a new
+# entry and 'False' if the entry already existed.
 def adapt_cmake(module_path, check_name_camel):
   filename = os.path.join(module_path, 'CMakeLists.txt')
   with open(filename, 'r') as f:
@@ -177,7 +181,6 @@ def add_release_notes(clang_tidy_path, old_check_name, 
new_check_name):
   with open(filename, 'wb') as f:
 note_added = False
 header_found = False
-next_header_found = False
 add_note_here = False
 
 for line in lines:
@@ 

[PATCH] D79330: [Analyzer][VLASizeChecker] Check for VLA size overflow.

2020-05-18 Thread Balázs Kéri via Phabricator via cfe-commits
balazske updated this revision to Diff 264572.
balazske added a comment.

Rebase, added checker name to overflow test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79330

Files:
  clang/lib/StaticAnalyzer/Checkers/VLASizeChecker.cpp
  clang/test/Analysis/vla-overflow.c

Index: clang/test/Analysis/vla-overflow.c
===
--- /dev/null
+++ clang/test/Analysis/vla-overflow.c
@@ -0,0 +1,25 @@
+// RUN: %clang_analyze_cc1 -triple x86_64-pc-linux-gnu -analyzer-checker=core -verify %s
+
+typedef unsigned long size_t;
+#define BIGINDEX 65536U
+
+size_t check_VLA_overflow_sizeof(unsigned int x) {
+  if (x == BIGINDEX) {
+// We expect here that size_t is a 64 bit value.
+// Size of this array should be the first to overflow.
+size_t s = sizeof(char[x][x][x][x]); // expected-warning{{Declared variable-length array (VLA) has too large size [core.VLASize]}}
+return s;
+  }
+  return 0;
+}
+
+void check_VLA_overflow_typedef() {
+  unsigned int x = BIGINDEX;
+  typedef char VLA[x][x][x][x]; // expected-warning{{Declared variable-length array (VLA) has too large size [core.VLASize]}}
+}
+
+void check_VLA_no_overflow() {
+  unsigned int x = BIGINDEX;
+  typedef char VLA[x][x][x][x - 1];
+  typedef char VLA1[0xu];
+}
Index: clang/lib/StaticAnalyzer/Checkers/VLASizeChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/VLASizeChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/VLASizeChecker.cpp
@@ -34,24 +34,24 @@
 : public Checker,
  check::PreStmt> {
   mutable std::unique_ptr BT;
-  enum VLASize_Kind { VLA_Garbage, VLA_Zero, VLA_Tainted, VLA_Negative };
+  enum VLASize_Kind {
+VLA_Garbage,
+VLA_Zero,
+VLA_Tainted,
+VLA_Negative,
+VLA_Overflow
+  };
 
   /// Check a VLA for validity.
-  /// Every dimension of the array is checked for validity, and
-  /// dimension sizes are collected into 'VLASizes'. 'VLALast' is set to the
-  /// innermost VLA that was encountered.
-  /// In "int vla[x][2][y][3]" this will be the array for index "y" (with type
-  /// int[3]). 'VLASizes' contains 'x', '2', and 'y'. Returns null or a new
-  /// state where the size is validated for every dimension.
-  ProgramStateRef checkVLA(CheckerContext , ProgramStateRef State,
-   const VariableArrayType *VLA,
-   const VariableArrayType *,
-   llvm::SmallVector ) const;
-
-  /// Check one VLA dimension for validity.
+  /// Every dimension of the array and the total size is checked for validity.
   /// Returns null or a new state where the size is validated.
-  ProgramStateRef checkVLASize(CheckerContext , ProgramStateRef State,
-   const Expr *SizeE) const;
+  /// 'ArraySize' will contain SVal that refers to the total size (in char)
+  /// of the array.
+  ProgramStateRef checkVLA(CheckerContext , ProgramStateRef State,
+   const VariableArrayType *VLA, SVal ) const;
+  /// Check a single VLA index size expression for validity.
+  ProgramStateRef checkVLAIndexSize(CheckerContext , ProgramStateRef State,
+const Expr *SizeE) const;
 
   void reportBug(VLASize_Kind Kind, const Expr *SizeE, ProgramStateRef State,
  CheckerContext ,
@@ -64,20 +64,25 @@
 };
 } // end anonymous namespace
 
-ProgramStateRef
-VLASizeChecker::checkVLA(CheckerContext , ProgramStateRef State,
- const VariableArrayType *VLA,
- const VariableArrayType *,
- llvm::SmallVector ) const {
+ProgramStateRef VLASizeChecker::checkVLA(CheckerContext ,
+ ProgramStateRef State,
+ const VariableArrayType *VLA,
+ SVal ) const {
   assert(VLA && "Function should be called with non-null VLA argument.");
 
-  VLALast = nullptr;
+  const VariableArrayType *VLALast = nullptr;
+  llvm::SmallVector VLASizes;
+
   // Walk over the VLAs for every dimension until a non-VLA is found.
   // There is a VariableArrayType for every dimension (fixed or variable) until
   // the most inner array that is variably modified.
+  // Dimension sizes are collected into 'VLASizes'. 'VLALast' is set to the
+  // innermost VLA that was encountered.
+  // In "int vla[x][2][y][3]" this will be the array for index "y" (with type
+  // int[3]). 'VLASizes' contains 'x', '2', and 'y'.
   while (VLA) {
 const Expr *SizeE = VLA->getSizeExpr();
-State = checkVLASize(C, State, SizeE);
+State = checkVLAIndexSize(C, State, SizeE);
 if (!State)
   return nullptr;
 VLASizes.push_back(SizeE);
@@ -87,12 +92,61 @@
   assert(VLALast &&
  "Array should have at least one 

[PATCH] D78985: [clang-tidy] NFC: Cleanup Python scripts

2020-05-18 Thread Kirill Bobyrev via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG968d293063bc: [clang-tidy] NFC: Cleanup Python scripts 
(authored by kbobyrev).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78985

Files:
  clang-tools-extra/clang-tidy/add_new_check.py
  clang-tools-extra/clang-tidy/rename_check.py
  clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
  clang-tools-extra/clang-tidy/tool/run-clang-tidy.py

Index: clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
===
--- clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
+++ clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
@@ -1,14 +1,15 @@
 #!/usr/bin/env python
 #
-#===- run-clang-tidy.py - Parallel clang-tidy runner -*- python -*--===#
+#===- run-clang-tidy.py - Parallel clang-tidy runner *- python -*--===#
 #
 # Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 # See https://llvm.org/LICENSE.txt for license information.
 # SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 #
-#======#
+#===---===#
 # FIXME: Integrate with clang-tidy-diff.py
 
+
 """
 Parallel clang-tidy runner
 ==
@@ -60,6 +61,7 @@
 else:
 import queue as queue
 
+
 def find_compilation_database(path):
   """Adjusts the directory until a compilation database is found."""
   result = './'
@@ -112,7 +114,7 @@
   """Merge all replacement files in a directory into a single file"""
   # The fixes suggested by clang-tidy >= 4.0.0 are given under
   # the top level key 'Diagnostics' in the output yaml files
-  mergekey="Diagnostics"
+  mergekey = "Diagnostics"
   merged=[]
   for replacefile in glob.iglob(os.path.join(tmpdir, '*.yaml')):
 content = yaml.safe_load(open(replacefile, 'r'))
@@ -125,7 +127,7 @@
 # include/clang/Tooling/ReplacementsYaml.h, but the value
 # is actually never used inside clang-apply-replacements,
 # so we set it to '' here.
-output = { 'MainSourceFile': '', mergekey: merged }
+output = {'MainSourceFile': '', mergekey: merged}
 with open(mergefile, 'w') as out:
   yaml.safe_dump(output, out)
   else:
@@ -324,11 +326,12 @@
 except:
   print('Error applying fixes.\n', file=sys.stderr)
   traceback.print_exc()
-  return_code=1
+  return_code = 1
 
   if tmpdir:
 shutil.rmtree(tmpdir)
   sys.exit(return_code)
 
+
 if __name__ == '__main__':
   main()
Index: clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
===
--- clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
+++ clang-tools-extra/clang-tidy/tool/clang-tidy-diff.py
@@ -1,12 +1,12 @@
 #!/usr/bin/env python
 #
-#===- clang-tidy-diff.py - ClangTidy Diff Checker *- python -*--===#
+#===- clang-tidy-diff.py - ClangTidy Diff Checker ---*- python -*--===#
 #
 # Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
 # See https://llvm.org/LICENSE.txt for license information.
 # SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 #
-#======#
+#===---===#
 
 r"""
 ClangTidy Diff Checker
@@ -75,7 +75,7 @@
 sys.stderr.write('Failed: ' + str(e) + ': '.join(command) + '\n')
 finally:
   with lock:
-if (not timeout is None) and (not watchdog is None):
+if not (timeout is None or watchdog is None):
   if not watchdog.is_alive():
   sys.stderr.write('Terminated by timeout: ' +
' '.join(command) + '\n')
@@ -89,6 +89,7 @@
 t.daemon = True
 t.start()
 
+
 def merge_replacement_files(tmpdir, mergefile):
   """Merge all replacement files in a directory into a single file"""
   # The fixes suggested by clang-tidy >= 4.0.0 are given under
@@ -106,7 +107,7 @@
 # include/clang/Tooling/ReplacementsYaml.h, but the value
 # is actually never used inside clang-apply-replacements,
 # so we set it to '' here.
-output = { 'MainSourceFile': '', mergekey: merged }
+output = {'MainSourceFile': '', mergekey: merged}
 with open(mergefile, 'w') as out:
   yaml.safe_dump(output, out)
   else:
Index: clang-tools-extra/clang-tidy/rename_check.py
===
--- clang-tools-extra/clang-tidy/rename_check.py
+++ clang-tools-extra/clang-tidy/rename_check.py
@@ -1,12 +1,12 @@
 #!/usr/bin/env python
 #
-#===- rename_check.py - clang-tidy check renamer -*- python -*--===#
+#===- rename_check.py - clang-tidy check renamer *- python -*--===#
 #
 # Part of the LLVM 

[PATCH] D80115: [clang-format] [PR45816] Add AlignConsecutiveBitFields

2020-05-18 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay created this revision.
MyDeveloperDay added reviewers: krasimir, mitchell-stellar, JakeMerdichAMD, 
curdeius, owenpan.
MyDeveloperDay added projects: clang, clang-format.
MyDeveloperDay updated this revision to Diff 264575.
MyDeveloperDay added a comment.
MyDeveloperDay edited the summary of this revision.
MyDeveloperDay edited the summary of this revision.

clang-format


https://bugs.llvm.org/show_bug.cgi?id=45816

The following revision adds the ability to align consecutive bitfield similar 
to AlignConsecutiveAssignments and AlignConsecutiveDeclarations

This will format the following code from

  struct Options {
bool some_field : 1;
bool some_another_field : 1;
int yet_another_field : 1;
  };

With the following consiguration change

  ...
  AlignConsecutiveBitFields: 'true'
  ...

To be

  struct Options {
bool some_field : 1;
bool some_another_field : 1;
int  yet_another_field  : 1;
  };


https://reviews.llvm.org/D80115

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/WhitespaceManager.cpp
  clang/lib/Format/WhitespaceManager.h
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -13005,6 +13005,7 @@
   CHECK_PARSE_BOOL(AlignOperands);
   CHECK_PARSE_BOOL(AlignTrailingComments);
   CHECK_PARSE_BOOL(AlignConsecutiveAssignments);
+  CHECK_PARSE_BOOL(AlignConsecutiveBitFields);
   CHECK_PARSE_BOOL(AlignConsecutiveDeclarations);
   CHECK_PARSE_BOOL(AlignConsecutiveMacros);
   CHECK_PARSE_BOOL(AllowAllArgumentsOnNextLine);
@@ -15849,6 +15850,22 @@
   verifyFormat("operator&&(int(&&)(), class Foo);", Style);
 }
 
+TEST_F(FormatTest, AlignConsecutiveBitFields) {
+  FormatStyle Alignment = getLLVMStyle();
+  Alignment.AlignConsecutiveMacros = false;
+  Alignment.AlignConsecutiveAssignments = false;
+  Alignment.AlignConsecutiveBitFields = false;
+
+  verifyFormat("bool a : 1;\n"
+   "bool oneTwoThree : 1;",
+   Alignment);
+
+  Alignment.AlignConsecutiveBitFields = true;
+  verifyFormat("bool a   : 1;\n"
+   "bool oneTwoThree : 1;",
+   Alignment);
+}
+
 } // namespace
 } // namespace format
 } // namespace clang
Index: clang/lib/Format/WhitespaceManager.h
===
--- clang/lib/Format/WhitespaceManager.h
+++ clang/lib/Format/WhitespaceManager.h
@@ -178,6 +178,9 @@
   /// Align consecutive assignments over all \c Changes.
   void alignConsecutiveAssignments();
 
+  /// Align consecutive bitfields over all \c Changes.
+  void alignConsecutiveBitFields();
+
   /// Align consecutive declarations over all \c Changes.
   void alignConsecutiveDeclarations();
 
Index: clang/lib/Format/WhitespaceManager.cpp
===
--- clang/lib/Format/WhitespaceManager.cpp
+++ clang/lib/Format/WhitespaceManager.cpp
@@ -95,6 +95,7 @@
   alignConsecutiveMacros();
   alignConsecutiveDeclarations();
   alignConsecutiveAssignments();
+  alignConsecutiveBitFields();
   alignTrailingComments();
   alignEscapedNewlines();
   generateChanges();
@@ -574,6 +575,22 @@
   Changes, /*StartAt=*/0);
 }
 
+void WhitespaceManager::alignConsecutiveBitFields() {
+  if (!Style.AlignConsecutiveBitFields)
+return;
+
+  AlignTokens(
+  Style,
+  [&](const Change ) {
+if (!C.Tok->Previous)
+  return false;
+
+return C.Tok->Previous->startsSequence(tok::identifier, tok::colon,
+   tok::numeric_constant);
+  },
+  Changes, /*StartAt=*/0);
+}
+
 void WhitespaceManager::alignConsecutiveDeclarations() {
   if (!Style.AlignConsecutiveDeclarations)
 return;
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -387,14 +387,18 @@
 
 IO.mapOptional("AccessModifierOffset", Style.AccessModifierOffset);
 IO.mapOptional("AlignAfterOpenBracket", Style.AlignAfterOpenBracket);
-IO.mapOptional("AlignConsecutiveMacros", Style.AlignConsecutiveMacros);
+
 IO.mapOptional("AlignConsecutiveAssignments",
Style.AlignConsecutiveAssignments);
+IO.mapOptional("AlignConsecutiveBitFields",
+   Style.AlignConsecutiveBitFields);
 IO.mapOptional("AlignConsecutiveDeclarations",
Style.AlignConsecutiveDeclarations);
+IO.mapOptional("AlignConsecutiveMacros", Style.AlignConsecutiveMacros);
 IO.mapOptional("AlignEscapedNewlines", Style.AlignEscapedNewlines);
 IO.mapOptional("AlignOperands", Style.AlignOperands);
 IO.mapOptional("AlignTrailingComments", 

[PATCH] D80115: [clang-format] [PR45816] Add AlignConsecutiveBitFields

2020-05-18 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay updated this revision to Diff 264575.
MyDeveloperDay added a comment.

clang-format


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

https://reviews.llvm.org/D80115

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/WhitespaceManager.cpp
  clang/lib/Format/WhitespaceManager.h
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -13005,6 +13005,7 @@
   CHECK_PARSE_BOOL(AlignOperands);
   CHECK_PARSE_BOOL(AlignTrailingComments);
   CHECK_PARSE_BOOL(AlignConsecutiveAssignments);
+  CHECK_PARSE_BOOL(AlignConsecutiveBitFields);
   CHECK_PARSE_BOOL(AlignConsecutiveDeclarations);
   CHECK_PARSE_BOOL(AlignConsecutiveMacros);
   CHECK_PARSE_BOOL(AllowAllArgumentsOnNextLine);
@@ -15849,6 +15850,22 @@
   verifyFormat("operator&&(int(&&)(), class Foo);", Style);
 }
 
+TEST_F(FormatTest, AlignConsecutiveBitFields) {
+  FormatStyle Alignment = getLLVMStyle();
+  Alignment.AlignConsecutiveMacros = false;
+  Alignment.AlignConsecutiveAssignments = false;
+  Alignment.AlignConsecutiveBitFields = false;
+
+  verifyFormat("bool a : 1;\n"
+   "bool oneTwoThree : 1;",
+   Alignment);
+
+  Alignment.AlignConsecutiveBitFields = true;
+  verifyFormat("bool a   : 1;\n"
+   "bool oneTwoThree : 1;",
+   Alignment);
+}
+
 } // namespace
 } // namespace format
 } // namespace clang
Index: clang/lib/Format/WhitespaceManager.h
===
--- clang/lib/Format/WhitespaceManager.h
+++ clang/lib/Format/WhitespaceManager.h
@@ -178,6 +178,9 @@
   /// Align consecutive assignments over all \c Changes.
   void alignConsecutiveAssignments();
 
+  /// Align consecutive bitfields over all \c Changes.
+  void alignConsecutiveBitFields();
+
   /// Align consecutive declarations over all \c Changes.
   void alignConsecutiveDeclarations();
 
Index: clang/lib/Format/WhitespaceManager.cpp
===
--- clang/lib/Format/WhitespaceManager.cpp
+++ clang/lib/Format/WhitespaceManager.cpp
@@ -95,6 +95,7 @@
   alignConsecutiveMacros();
   alignConsecutiveDeclarations();
   alignConsecutiveAssignments();
+  alignConsecutiveBitFields();
   alignTrailingComments();
   alignEscapedNewlines();
   generateChanges();
@@ -574,6 +575,22 @@
   Changes, /*StartAt=*/0);
 }
 
+void WhitespaceManager::alignConsecutiveBitFields() {
+  if (!Style.AlignConsecutiveBitFields)
+return;
+
+  AlignTokens(
+  Style,
+  [&](const Change ) {
+if (!C.Tok->Previous)
+  return false;
+
+return C.Tok->Previous->startsSequence(tok::identifier, tok::colon,
+   tok::numeric_constant);
+  },
+  Changes, /*StartAt=*/0);
+}
+
 void WhitespaceManager::alignConsecutiveDeclarations() {
   if (!Style.AlignConsecutiveDeclarations)
 return;
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -387,14 +387,18 @@
 
 IO.mapOptional("AccessModifierOffset", Style.AccessModifierOffset);
 IO.mapOptional("AlignAfterOpenBracket", Style.AlignAfterOpenBracket);
-IO.mapOptional("AlignConsecutiveMacros", Style.AlignConsecutiveMacros);
+
 IO.mapOptional("AlignConsecutiveAssignments",
Style.AlignConsecutiveAssignments);
+IO.mapOptional("AlignConsecutiveBitFields",
+   Style.AlignConsecutiveBitFields);
 IO.mapOptional("AlignConsecutiveDeclarations",
Style.AlignConsecutiveDeclarations);
+IO.mapOptional("AlignConsecutiveMacros", Style.AlignConsecutiveMacros);
 IO.mapOptional("AlignEscapedNewlines", Style.AlignEscapedNewlines);
 IO.mapOptional("AlignOperands", Style.AlignOperands);
 IO.mapOptional("AlignTrailingComments", Style.AlignTrailingComments);
+
 IO.mapOptional("AllowAllArgumentsOnNextLine",
Style.AllowAllArgumentsOnNextLine);
 IO.mapOptional("AllowAllConstructorInitializersOnNextLine",
@@ -753,6 +757,7 @@
   LLVMStyle.AlignOperands = true;
   LLVMStyle.AlignTrailingComments = true;
   LLVMStyle.AlignConsecutiveAssignments = false;
+  LLVMStyle.AlignConsecutiveBitFields = false;
   LLVMStyle.AlignConsecutiveDeclarations = false;
   LLVMStyle.AlignConsecutiveMacros = false;
   LLVMStyle.AllowAllArgumentsOnNextLine = true;
Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -108,6 +108,17 @@
   /// \endcode
   bool AlignConsecutiveAssignments;
 

[PATCH] D76793: [Matrix] Implement + and - operators for MatrixType.

2020-05-18 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added a comment.

ping :)

this patch should be ready to be reviewed independently (it's marked as 
dependent on D76791  in Phab, but it can be 
applied independently and changing the relationship in Phab will trigger a 
bunch of unnecessary emails)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76793



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


[clang] a6a237f - [OpenCL] Added addrspace_cast operator in C++ mode.

2020-05-18 Thread Anastasia Stulova via cfe-commits

Author: Anastasia Stulova
Date: 2020-05-18T12:07:54+01:00
New Revision: a6a237f2046ad8993db30481c8b61aeb2f73a5ad

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

LOG: [OpenCL] Added addrspace_cast operator in C++ mode.

This operator is intended for casting between
pointers to objects in different address spaces
and follows similar logic as const_cast in C++.

Tags: #clang

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

Added: 
clang/test/CodeGenOpenCLCXX/addrspace_cast.cl
clang/test/Index/cxx.cl
clang/test/SemaOpenCLCXX/addrspace_cast.cl
clang/test/SemaOpenCLCXX/addrspace_cast_ast_dump.cl

Modified: 
clang/include/clang-c/Index.h
clang/include/clang/AST/ExprCXX.h
clang/include/clang/AST/RecursiveASTVisitor.h
clang/include/clang/Basic/DiagnosticParseKinds.td
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/include/clang/Basic/StmtNodes.td
clang/include/clang/Basic/TokenKinds.def
clang/include/clang/Sema/Sema.h
clang/include/clang/Serialization/ASTBitCodes.h
clang/lib/AST/Expr.cpp
clang/lib/AST/ExprCXX.cpp
clang/lib/AST/ExprClassification.cpp
clang/lib/AST/ExprConstant.cpp
clang/lib/AST/ItaniumMangle.cpp
clang/lib/AST/StmtPrinter.cpp
clang/lib/AST/StmtProfile.cpp
clang/lib/CodeGen/CGExpr.cpp
clang/lib/Parse/ParseExpr.cpp
clang/lib/Parse/ParseExprCXX.cpp
clang/lib/Sema/SemaCast.cpp
clang/lib/Sema/SemaExceptionSpec.cpp
clang/lib/Sema/TreeTransform.h
clang/lib/Serialization/ASTReaderStmt.cpp
clang/lib/Serialization/ASTWriter.cpp
clang/lib/Serialization/ASTWriterStmt.cpp
clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
clang/tools/libclang/CIndex.cpp
clang/tools/libclang/CXCursor.cpp

Removed: 




diff  --git a/clang/include/clang-c/Index.h b/clang/include/clang-c/Index.h
index 8e367b617bd3..3a8a1fdcae0c 100644
--- a/clang/include/clang-c/Index.h
+++ b/clang/include/clang-c/Index.h
@@ -2052,58 +2052,62 @@ enum CXCursorKind {
*/
   CXCursor_CXXFunctionalCastExpr = 128,
 
+  /** OpenCL's addrspace_cast<> expression.
+   */
+  CXCursor_CXXAddrspaceCastExpr = 129,
+
   /** A C++ typeid expression (C++ [expr.typeid]).
*/
-  CXCursor_CXXTypeidExpr = 129,
+  CXCursor_CXXTypeidExpr = 130,
 
   /** [C++ 2.13.5] C++ Boolean Literal.
*/
-  CXCursor_CXXBoolLiteralExpr = 130,
+  CXCursor_CXXBoolLiteralExpr = 131,
 
   /** [C++0x 2.14.7] C++ Pointer Literal.
*/
-  CXCursor_CXXNullPtrLiteralExpr = 131,
+  CXCursor_CXXNullPtrLiteralExpr = 132,
 
   /** Represents the "this" expression in C++
*/
-  CXCursor_CXXThisExpr = 132,
+  CXCursor_CXXThisExpr = 133,
 
   /** [C++ 15] C++ Throw Expression.
*
* This handles 'throw' and 'throw' assignment-expression. When
* assignment-expression isn't present, Op will be null.
*/
-  CXCursor_CXXThrowExpr = 133,
+  CXCursor_CXXThrowExpr = 134,
 
   /** A new expression for memory allocation and constructor calls, e.g:
* "new CXXNewExpr(foo)".
*/
-  CXCursor_CXXNewExpr = 134,
+  CXCursor_CXXNewExpr = 135,
 
   /** A delete expression for memory deallocation and destructor calls,
* e.g. "delete[] pArray".
*/
-  CXCursor_CXXDeleteExpr = 135,
+  CXCursor_CXXDeleteExpr = 136,
 
   /** A unary expression. (noexcept, sizeof, or other traits)
*/
-  CXCursor_UnaryExpr = 136,
+  CXCursor_UnaryExpr = 137,
 
   /** An Objective-C string literal i.e. @"foo".
*/
-  CXCursor_ObjCStringLiteral = 137,
+  CXCursor_ObjCStringLiteral = 138,
 
   /** An Objective-C \@encode expression.
*/
-  CXCursor_ObjCEncodeExpr = 138,
+  CXCursor_ObjCEncodeExpr = 139,
 
   /** An Objective-C \@selector expression.
*/
-  CXCursor_ObjCSelectorExpr = 139,
+  CXCursor_ObjCSelectorExpr = 140,
 
   /** An Objective-C \@protocol expression.
*/
-  CXCursor_ObjCProtocolExpr = 140,
+  CXCursor_ObjCProtocolExpr = 141,
 
   /** An Objective-C "bridged" cast expression, which casts between
* Objective-C pointers and C pointers, transferring ownership in the 
process.
@@ -2112,7 +2116,7 @@ enum CXCursorKind {
*   NSString *str = (__bridge_transfer NSString *)CFCreateString();
* \endcode
*/
-  CXCursor_ObjCBridgedCastExpr = 141,
+  CXCursor_ObjCBridgedCastExpr = 142,
 
   /** Represents a C++0x pack expansion that produces a sequence of
* expressions.
@@ -2127,7 +2131,7 @@ enum CXCursorKind {
* }
* \endcode
*/
-  CXCursor_PackExpansionExpr = 142,
+  CXCursor_PackExpansionExpr = 143,
 
   /** Represents an expression that computes the length of a parameter
* pack.
@@ -2139,7 +2143,7 @@ enum CXCursorKind {
* };
* \endcode
*/
-  CXCursor_SizeOfPackExpr = 143,
+  CXCursor_SizeOfPackExpr = 144,
 
   /* Represents a C++ lambda expression that produces a local function

[PATCH] D60193: [OpenCL] Added addrspace_cast operator

2020-05-18 Thread Anastasia Stulova via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa6a237f2046a: [OpenCL] Added addrspace_cast operator in C++ 
mode. (authored by Anastasia).
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D60193?vs=263085=264581#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D60193

Files:
  clang/include/clang-c/Index.h
  clang/include/clang/AST/ExprCXX.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Basic/StmtNodes.td
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprCXX.cpp
  clang/lib/AST/ExprClassification.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/StmtPrinter.cpp
  clang/lib/AST/StmtProfile.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Parse/ParseExprCXX.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaExceptionSpec.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReaderStmt.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/lib/Serialization/ASTWriterStmt.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/test/CodeGenOpenCLCXX/addrspace_cast.cl
  clang/test/Index/cxx.cl
  clang/test/SemaOpenCLCXX/addrspace_cast.cl
  clang/test/SemaOpenCLCXX/addrspace_cast_ast_dump.cl
  clang/tools/libclang/CIndex.cpp
  clang/tools/libclang/CXCursor.cpp

Index: clang/tools/libclang/CXCursor.cpp
===
--- clang/tools/libclang/CXCursor.cpp
+++ clang/tools/libclang/CXCursor.cpp
@@ -491,6 +491,10 @@
 K = CXCursor_CXXFunctionalCastExpr;
 break;
 
+  case Stmt::CXXAddrspaceCastExprClass:
+K = CXCursor_CXXAddrspaceCastExpr;
+break;
+
   case Stmt::CXXTypeidExprClass:
 K = CXCursor_CXXTypeidExpr;
 break;
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -5239,6 +5239,8 @@
 return cxstring::createRef("CXXConstCastExpr");
   case CXCursor_CXXFunctionalCastExpr:
 return cxstring::createRef("CXXFunctionalCastExpr");
+  case CXCursor_CXXAddrspaceCastExpr:
+return cxstring::createRef("CXXAddrspaceCastExpr");
   case CXCursor_CXXTypeidExpr:
 return cxstring::createRef("CXXTypeidExpr");
   case CXCursor_CXXBoolLiteralExpr:
Index: clang/test/SemaOpenCLCXX/addrspace_cast_ast_dump.cl
===
--- /dev/null
+++ clang/test/SemaOpenCLCXX/addrspace_cast_ast_dump.cl
@@ -0,0 +1,13 @@
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=clc++ -pedantic -verify -ast-dump | FileCheck %s
+
+// expected-no-diagnostics
+
+//CHECK:`-FunctionDecl {{.*}} bar 'void (__global int *__private)'
+//CHECK:  |-ParmVarDecl {{.*}} used gl '__global int *__private'
+//CHECK:  `-VarDecl {{.*}} gen '__generic int *__private' cinit
+//CHECK:`-CXXAddrspaceCastExpr {{.*}} '__generic int *' addrspace_cast<__generic int *> 
+//CHECK:  `-DeclRefExpr {{.*}} '__global int *__private' lvalue ParmVar {{.*}} 'gl' '__global int *__private'
+
+void bar(global int *gl) {
+  int *gen = addrspace_cast(gl);
+}
Index: clang/test/SemaOpenCLCXX/addrspace_cast.cl
===
--- /dev/null
+++ clang/test/SemaOpenCLCXX/addrspace_cast.cl
@@ -0,0 +1,39 @@
+// RUN: %clang_cc1 %s -triple spir-unknown-unknown -cl-std=clc++ -pedantic -verify -fsyntax-only
+
+void foo(global int *gl, const global int *gl_const, global int _ref) {
+  //FIXME: Diagnostics can be improved to be more specific in some cases.
+  float *gen_fl = addrspace_cast(gl); //expected-error{{addrspace_cast from '__global int *__private' to '__generic float *' is not allowed}}
+
+  int i = addrspace_cast(gl); //expected-error{{addrspace_cast from '__global int *__private' to 'int' is not allowed}}
+
+  int *gen = addrspace_cast(*gl); //expected-error{{addrspace_cast from '__global int' to '__generic int *' is not allowed}}
+
+  local int *loc = addrspace_cast(gl); //expected-error{{addrspace_cast from '__global int *__private' to '__local int *' converts between mismatching address spaces}}
+
+  int *gen2 = addrspace_cast(gl_const); //expected-error{{addrspace_cast from 'const __global int *__private' to '__generic int *' is not allowed}}
+
+  //FIXME: Do we expect this behavior? This will get cast successfully as reinterpret_cast.
+  int _ref = addrspace_cast(gl_ref); //expected-error{{addrspace_cast from '__global int' to '__generic int &' is not allowed}}
+
+  __private int *priv = addrspace_cast<__private int *>();
+}
+
+template 
+void 

[PATCH] D80016: [analyzer] StdLibraryFunctionsChecker: Add support to lookup types

2020-05-18 Thread Balázs Kéri via Phabricator via cfe-commits
balazske added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:747
+  : *FilePtrTy)
+: None;
+

The `Optional` can be left out from the right side expressions (in 
the `?` operator part). (A `QualType` should be assignable to 
`Optional`.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80016



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


[clang] 87b235d - Turn -Wmax-tokens off by default

2020-05-18 Thread Hans Wennborg via cfe-commits

Author: Hans Wennborg
Date: 2020-05-18T13:21:46+02:00
New Revision: 87b235db63a3d8d5b82d60ef6202b92b94a7d9d2

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

LOG: Turn -Wmax-tokens off by default

On the one hand, one might interpret the use of the max-token pragmas or
-fmax-tokens flag as an opt-in to the warning. However, in Chromium
we've found it useful to only opt in selected build configurations, even
though we have the pragmas in the code. For that reason, we think it
makes sense to turn it off by default.

Differential revision: https://reviews.llvm.org/D80014

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticGroups.td
clang/include/clang/Basic/DiagnosticParseKinds.td
clang/test/Parser/max-tokens.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticGroups.td 
b/clang/include/clang/Basic/DiagnosticGroups.td
index b6a252ac01a9..c9104da66f1f 100644
--- a/clang/include/clang/Basic/DiagnosticGroups.td
+++ b/clang/include/clang/Basic/DiagnosticGroups.td
@@ -1202,5 +1202,8 @@ the token limit, which can be set in three ways:
 These limits can be helpful in limiting code growth through included files.
 
 Setting a token limit of zero means no limit.
+
+Note that the warning is disabled by default, so -Wmax-tokens must be used
+in addition with the pragmas or -fmax-tokens flag to get any warnings.
 }];
 }

diff  --git a/clang/include/clang/Basic/DiagnosticParseKinds.td 
b/clang/include/clang/Basic/DiagnosticParseKinds.td
index f32ff65948b0..5d57cfd6e71d 100644
--- a/clang/include/clang/Basic/DiagnosticParseKinds.td
+++ b/clang/include/clang/Basic/DiagnosticParseKinds.td
@@ -1428,11 +1428,11 @@ def err_placeholder_expected_auto_or_decltype_auto : 
Error<
 
 def warn_max_tokens : Warning<
   "the number of preprocessor source tokens (%0) exceeds this token limit 
(%1)">,
-  InGroup;
+  InGroup, DefaultIgnore;
 
 def warn_max_tokens_total : Warning<
   "the total number of preprocessor source tokens (%0) exceeds the token limit 
(%1)">,
-  InGroup;
+  InGroup, DefaultIgnore;
 
 def note_max_tokens_total_override : Note<"total token limit set here">;
 

diff  --git a/clang/test/Parser/max-tokens.cpp 
b/clang/test/Parser/max-tokens.cpp
index 5be892773fe4..f98332d21afd 100644
--- a/clang/test/Parser/max-tokens.cpp
+++ b/clang/test/Parser/max-tokens.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
-// RUN: %clang_cc1 -fsyntax-only -verify %s -DMAX_TOKENS  
-fmax-tokens=2
-// RUN: %clang_cc1 -fsyntax-only -verify %s -DMAX_TOKENS_OVERRIDE 
-fmax-tokens=9
+// RUN: %clang_cc1 -fsyntax-only -verify %s -Wmax-tokens
+// RUN: %clang_cc1 -fsyntax-only -verify %s -Wmax-tokens -DMAX_TOKENS  
-fmax-tokens=2
+// RUN: %clang_cc1 -fsyntax-only -verify %s -Wmax-tokens -DMAX_TOKENS_OVERRIDE 
-fmax-tokens=9
 
 int x, y, z;
 



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


[PATCH] D80117: [analyzer] Introduce reasoning about symbolic remainder operator

2020-05-18 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko created this revision.
vsavchenko added reviewers: NoQ, dcoughlin, xazax.hun, ASDenysPetrov.
Herald added subscribers: cfe-commits, martong, Charusso, dkrupp, donat.nagy, 
Szelethus, mikhail.ramalho, a.sidorin, rnkovacs, szepet, baloghadamsoftware.
Herald added a project: clang.

New logic tries to narrow possible result values of the remainder operation
based on its operands and their ranges.  It also tries to be conservative
with negative operands because according to the standard the sign of
the result is implementation-defined.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80117

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/PR35418.cpp
  clang/test/Analysis/constant-folding.c
  clang/test/Analysis/uninit-bug-first-iteration-init.c

Index: clang/test/Analysis/uninit-bug-first-iteration-init.c
===
--- /dev/null
+++ clang/test/Analysis/uninit-bug-first-iteration-init.c
@@ -0,0 +1,27 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core -verify %s
+
+// rdar://problem/44978988
+// expected-no-diagnostics
+
+int foo();
+
+int gTotal;
+
+double bar(int start, int end) {
+  int i, cnt, processed, size;
+  double result, inc;
+
+  result = 0;
+  processed = start;
+  size = gTotal * 2;
+  cnt = (end - start + 1) * size;
+
+  for (i = 0; i < cnt; i += 2) {
+if ((i % size) == 0) {
+  inc = foo();
+  processed++;
+}
+result += inc * inc; // no-warning
+  }
+  return result;
+}
Index: clang/test/Analysis/constant-folding.c
===
--- clang/test/Analysis/constant-folding.c
+++ clang/test/Analysis/constant-folding.c
@@ -174,3 +174,64 @@
 clang_analyzer_eval((a & 1) <= 1); // expected-warning{{TRUE}}
   }
 }
+
+void testRemainderRules(unsigned int a, unsigned int b, int c, int d) {
+  // Check that we know that remainder of zero divided by any number is still 0.
+  clang_analyzer_eval((0 % c) == 0); // expected-warning{{TRUE}}
+
+  clang_analyzer_eval((10 % a) <= 10); // expected-warning{{TRUE}}
+
+  if (a <= 30 && b <= 50) {
+clang_analyzer_eval((40 % a) < 30); // expected-warning{{TRUE}}
+clang_analyzer_eval((a % b) < 50);  // expected-warning{{TRUE}}
+clang_analyzer_eval((b % a) < 30);  // expected-warning{{TRUE}}
+
+if (a >= 10) {
+  // Even though it seems like a valid assumption, it is not.
+  // Check that we are not making this mistake.
+  clang_analyzer_eval((a % b) >= 10); // expected-warning{{UNKNOWN}}
+
+  // Check that we can we can infer when remainder is equal
+  // to the dividend.
+  clang_analyzer_eval((4 % a) == 4); // expected-warning{{TRUE}}
+  if (b < 7) {
+clang_analyzer_eval((b % a) < 7); // expected-warning{{TRUE}}
+  }
+}
+  }
+
+  // Check that we can reason about signed integers when they are
+  // known to be positive.
+  if (c >= 10 && c <= 30 && d >= 20 && d <= 50) {
+clang_analyzer_eval((5 % c) == 5);  // expected-warning{{TRUE}}
+clang_analyzer_eval((c % d) <= 30); // expected-warning{{TRUE}}
+clang_analyzer_eval((c % d) >= 0);  // expected-warning{{TRUE}}
+clang_analyzer_eval((d % c) < 30);  // expected-warning{{TRUE}}
+clang_analyzer_eval((d % c) >= 0);  // expected-warning{{TRUE}}
+  }
+
+  if (c >= -30 && c <= -10 && d >= -20 && d <= 50) {
+// Test positive LHS with negative RHS.
+clang_analyzer_eval((40 % c) < 30);  // expected-warning{{TRUE}}
+clang_analyzer_eval((40 % c) > -30); // expected-warning{{TRUE}}
+
+// Test negative LHS with possibly negative RHS.
+clang_analyzer_eval((-10 % d) < 50);  // expected-warning{{TRUE}}
+clang_analyzer_eval((-20 % d) > -50); // expected-warning{{TRUE}}
+
+// Check that we don't make wrong assumptions
+clang_analyzer_eval((-20 % d) > -20); // expected-warning{{UNKNOWN}}
+
+// Check that we can reason about negative ranges...
+clang_analyzer_eval((c % d) < 50); // expected-warning{{TRUE}}
+/// ...both ways
+clang_analyzer_eval((d % c) < 30); // expected-warning{{TRUE}}
+
+if (a <= 10) {
+  // Result is unsigned.  This means that 'c' is casted to unsigned.
+  // We don't want to reason about ranges changing boundaries with
+  // conversions.
+  clang_analyzer_eval((a % c) < 30); // expected-warning{{UNKNOWN}}
+}
+  }
+}
Index: clang/test/Analysis/PR35418.cpp
===
--- /dev/null
+++ clang/test/Analysis/PR35418.cpp
@@ -0,0 +1,28 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core -verify %s
+
+// expected-no-diagnostics
+
+void halt() __attribute__((__noreturn__));
+void assert(int b) {
+  if (!b)
+halt();
+}
+
+void decode(unsigned width) {
+  assert(width > 0);
+
+  int base;
+  bool inited = false;
+
+  int i = 0;
+
+  if (i % width == 0) {
+base = 512;
+inited = true;
+  }
+
+  base += 1; // 

[PATCH] D78442: Create a warning flag for 'warn_conv_*_not_used'

2020-05-18 Thread Ronald Wampler via Phabricator via cfe-commits
rdwampler added a comment.

Ping.


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

https://reviews.llvm.org/D78442



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


[PATCH] D79708: [clang][BFloat] add NEON emitter for bfloat

2020-05-18 Thread Ties Stuij via Phabricator via cfe-commits
stuij updated this revision to Diff 264587.
stuij added a comment.

adhere to patch attribution conventions


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79708

Files:
  clang/include/clang/Basic/arm_bf16.td
  clang/include/clang/Basic/arm_neon_incl.td
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/Basic/Targets/ARM.cpp
  clang/lib/Headers/CMakeLists.txt
  clang/test/Preprocessor/aarch64-target-features.c
  clang/test/Preprocessor/arm-target-features.c
  clang/utils/TableGen/NeonEmitter.cpp
  clang/utils/TableGen/TableGen.cpp
  clang/utils/TableGen/TableGenBackends.h

Index: clang/utils/TableGen/TableGenBackends.h
===
--- clang/utils/TableGen/TableGenBackends.h
+++ clang/utils/TableGen/TableGenBackends.h
@@ -85,6 +85,7 @@
 
 void EmitNeon(llvm::RecordKeeper , llvm::raw_ostream );
 void EmitFP16(llvm::RecordKeeper , llvm::raw_ostream );
+void EmitBF16(llvm::RecordKeeper , llvm::raw_ostream );
 void EmitNeonSema(llvm::RecordKeeper , llvm::raw_ostream );
 void EmitNeonTest(llvm::RecordKeeper , llvm::raw_ostream );
 void EmitNeon2(llvm::RecordKeeper , llvm::raw_ostream );
Index: clang/utils/TableGen/TableGen.cpp
===
--- clang/utils/TableGen/TableGen.cpp
+++ clang/utils/TableGen/TableGen.cpp
@@ -63,6 +63,7 @@
   GenClangOpenCLBuiltins,
   GenArmNeon,
   GenArmFP16,
+  GenArmBF16,
   GenArmNeonSema,
   GenArmNeonTest,
   GenArmMveHeader,
@@ -186,6 +187,7 @@
"Generate OpenCL builtin declaration handlers"),
 clEnumValN(GenArmNeon, "gen-arm-neon", "Generate arm_neon.h for clang"),
 clEnumValN(GenArmFP16, "gen-arm-fp16", "Generate arm_fp16.h for clang"),
+clEnumValN(GenArmBF16, "gen-arm-bf16", "Generate arm_bf16.h for clang"),
 clEnumValN(GenArmNeonSema, "gen-arm-neon-sema",
"Generate ARM NEON sema support for clang"),
 clEnumValN(GenArmNeonTest, "gen-arm-neon-test",
@@ -360,6 +362,9 @@
   case GenArmFP16:
 EmitFP16(Records, OS);
 break;
+  case GenArmBF16:
+EmitBF16(Records, OS);
+break;
   case GenArmNeonSema:
 EmitNeonSema(Records, OS);
 break;
Index: clang/utils/TableGen/NeonEmitter.cpp
===
--- clang/utils/TableGen/NeonEmitter.cpp
+++ clang/utils/TableGen/NeonEmitter.cpp
@@ -99,7 +99,8 @@
   Poly128,
   Float16,
   Float32,
-  Float64
+  Float64,
+  BFloat16
 };
 
 } // end namespace NeonTypeFlags
@@ -147,6 +148,7 @@
 SInt,
 UInt,
 Poly,
+BFloat16,
   };
   TypeKind Kind;
   bool Immediate, Constant, Pointer;
@@ -199,6 +201,7 @@
   bool isInt() const { return isInteger() && ElementBitwidth == 32; }
   bool isLong() const { return isInteger() && ElementBitwidth == 64; }
   bool isVoid() const { return Kind == Void; }
+  bool isBFloat16() const { return Kind == BFloat16; }
   unsigned getNumElements() const { return Bitwidth / ElementBitwidth; }
   unsigned getSizeInBits() const { return Bitwidth; }
   unsigned getElementSizeInBits() const { return ElementBitwidth; }
@@ -585,8 +588,11 @@
   // runFP16 - Emit arm_fp16.h.inc
   void runFP16(raw_ostream );
 
-  // runHeader - Emit all the __builtin prototypes used in arm_neon.h
-	// and arm_fp16.h
+  // runBF16 - Emit arm_bf16.h.inc
+  void runBF16(raw_ostream );
+
+  // runHeader - Emit all the __builtin prototypes used in arm_neon.h,
+  // arm_fp16.h and arm_bf16.h
   void runHeader(raw_ostream );
 
   // runTests - Emit tests for all the Neon intrinsics.
@@ -611,12 +617,15 @@
 S += "poly";
   else if (isFloating())
 S += "float";
+  else if (isBFloat16())
+S += "bfloat";
   else
 S += "int";
 
   S += utostr(ElementBitwidth);
   if (isVector())
 S += "x" + utostr(getNumElements());
+
   if (NumVectors > 1)
 S += "x" + utostr(NumVectors);
   S += "_t";
@@ -650,7 +659,10 @@
 case 128: S += "LLLi"; break;
 default: llvm_unreachable("Unhandled case!");
 }
-  else
+  else if (isBFloat16()) {
+assert(ElementBitwidth == 16 && "BFloat16 can only be 16 bits");
+S += "y";
+  } else
 switch (ElementBitwidth) {
 case 16: S += "h"; break;
 case 32: S += "f"; break;
@@ -704,6 +716,11 @@
 Base = (unsigned)NeonTypeFlags::Float16 + (Addend - 1);
   }
 
+  if (isBFloat16()) {
+assert(Addend == 1 && "BFloat16 is only 16 bit");
+Base = (unsigned)NeonTypeFlags::BFloat16;
+  }
+
   if (Bitwidth == 128)
 Base |= (unsigned)NeonTypeFlags::QuadFlag;
   if (isInteger() && !isSigned())
@@ -727,6 +744,9 @@
   } else if (Name.startswith("poly")) {
 T.Kind = Poly;
 Name = Name.drop_front(4);
+  } else if (Name.startswith("bfloat")) {
+T.Kind = BFloat16;
+Name = Name.drop_front(6);
   } else {
 assert(Name.startswith("int"));
 Name = Name.drop_front(3);
@@ -825,6 +845,10 @@
   if (isPoly())
 

[PATCH] D79711: [ARM][BFloat] Add poly64_t on AArch32.

2020-05-18 Thread Ties Stuij via Phabricator via cfe-commits
stuij updated this revision to Diff 264586.
stuij added a comment.

adhere to attribution conventions


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79711

Files:
  clang/include/clang/Basic/TargetBuiltins.h
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/Sema/SemaType.cpp
  clang/utils/TableGen/NeonEmitter.cpp


Index: clang/utils/TableGen/NeonEmitter.cpp
===
--- clang/utils/TableGen/NeonEmitter.cpp
+++ clang/utils/TableGen/NeonEmitter.cpp
@@ -2235,6 +2235,7 @@
   OS << "#else\n";
   OS << "typedef int8_t poly8_t;\n";
   OS << "typedef int16_t poly16_t;\n";
+  OS << "typedef int64_t poly64_t;\n";
   OS << "#endif\n";
 
   // Emit Neon vector typedefs.
@@ -2247,7 +2248,7 @@
   for (auto  : TDTypeVec) {
 bool IsA64 = false;
 Type T(TS, ".");
-if (T.isDouble() || (T.isPoly() && T.getElementSizeInBits() == 64))
+if (T.isDouble())
   IsA64 = true;
 
 if (InIfdef && !IsA64) {
@@ -2280,7 +2281,7 @@
 for (auto  : TDTypeVec) {
   bool IsA64 = false;
   Type T(TS, ".");
-  if (T.isDouble() || (T.isPoly() && T.getElementSizeInBits() == 64))
+  if (T.isDouble())
 IsA64 = true;
 
   if (InIfdef && !IsA64) {
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -7649,15 +7649,16 @@
 Triple.getArch() == llvm::Triple::aarch64_be;
   if (VecKind == VectorType::NeonPolyVector) {
 if (IsPolyUnsigned) {
-  // AArch64 polynomial vectors are unsigned and support poly64.
+  // AArch64 polynomial vectors are unsigned.
   return BTy->getKind() == BuiltinType::UChar ||
  BTy->getKind() == BuiltinType::UShort ||
  BTy->getKind() == BuiltinType::ULong ||
  BTy->getKind() == BuiltinType::ULongLong;
 } else {
-  // AArch32 polynomial vector are signed.
+  // AArch32 polynomial vectors are signed.
   return BTy->getKind() == BuiltinType::SChar ||
- BTy->getKind() == BuiltinType::Short;
+ BTy->getKind() == BuiltinType::Short ||
+ BTy->getKind() == BuiltinType::LongLong;
 }
   }
 
Index: clang/lib/AST/ItaniumMangle.cpp
===
--- clang/lib/AST/ItaniumMangle.cpp
+++ clang/lib/AST/ItaniumMangle.cpp
@@ -3167,6 +3167,7 @@
 case BuiltinType::UShort:
   EltName = "poly16_t";
   break;
+case BuiltinType::LongLong:
 case BuiltinType::ULongLong:
   EltName = "poly64_t";
   break;
Index: clang/include/clang/Basic/TargetBuiltins.h
===
--- clang/include/clang/Basic/TargetBuiltins.h
+++ clang/include/clang/Basic/TargetBuiltins.h
@@ -157,7 +157,7 @@
 EltType getEltType() const { return (EltType)(Flags & EltTypeMask); }
 bool isPoly() const {
   EltType ET = getEltType();
-  return ET == Poly8 || ET == Poly16;
+  return ET == Poly8 || ET == Poly16 || ET == Poly64;
 }
 bool isUnsigned() const { return (Flags & UnsignedFlag) != 0; }
 bool isQuad() const { return (Flags & QuadFlag) != 0; }


Index: clang/utils/TableGen/NeonEmitter.cpp
===
--- clang/utils/TableGen/NeonEmitter.cpp
+++ clang/utils/TableGen/NeonEmitter.cpp
@@ -2235,6 +2235,7 @@
   OS << "#else\n";
   OS << "typedef int8_t poly8_t;\n";
   OS << "typedef int16_t poly16_t;\n";
+  OS << "typedef int64_t poly64_t;\n";
   OS << "#endif\n";
 
   // Emit Neon vector typedefs.
@@ -2247,7 +2248,7 @@
   for (auto  : TDTypeVec) {
 bool IsA64 = false;
 Type T(TS, ".");
-if (T.isDouble() || (T.isPoly() && T.getElementSizeInBits() == 64))
+if (T.isDouble())
   IsA64 = true;
 
 if (InIfdef && !IsA64) {
@@ -2280,7 +2281,7 @@
 for (auto  : TDTypeVec) {
   bool IsA64 = false;
   Type T(TS, ".");
-  if (T.isDouble() || (T.isPoly() && T.getElementSizeInBits() == 64))
+  if (T.isDouble())
 IsA64 = true;
 
   if (InIfdef && !IsA64) {
Index: clang/lib/Sema/SemaType.cpp
===
--- clang/lib/Sema/SemaType.cpp
+++ clang/lib/Sema/SemaType.cpp
@@ -7649,15 +7649,16 @@
 Triple.getArch() == llvm::Triple::aarch64_be;
   if (VecKind == VectorType::NeonPolyVector) {
 if (IsPolyUnsigned) {
-  // AArch64 polynomial vectors are unsigned and support poly64.
+  // AArch64 polynomial vectors are unsigned.
   return BTy->getKind() == BuiltinType::UChar ||
  BTy->getKind() == BuiltinType::UShort ||
  BTy->getKind() == BuiltinType::ULong ||
  BTy->getKind() == BuiltinType::ULongLong;
 } else {
-  // AArch32 polynomial vector are signed.
+  // 

[PATCH] D79710: [clang][BFloat] add create/set/get/dup intrinsics

2020-05-18 Thread Ties Stuij via Phabricator via cfe-commits
stuij updated this revision to Diff 264588.
stuij added a comment.

adhere to patch attribution conventions: change author to Ties, add all the 
contributors


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79710

Files:
  clang/include/clang/Basic/arm_neon.td
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/aarch64-bf16-getset-intrinsics.c

Index: clang/test/CodeGen/aarch64-bf16-getset-intrinsics.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-bf16-getset-intrinsics.c
@@ -0,0 +1,120 @@
+// RUN: %clang_cc1 -triple aarch64-arm-none-eabi -target-feature +neon -target-feature +bf16 \
+// RUN:  -O2 -fallow-half-arguments-and-returns -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK64
+// RUN: %clang_cc1 -triple armv8.6a-arm-none-eabi -target-feature +neon -target-feature +bf16 -mfloat-abi hard \
+// RUN:  -O2 -fallow-half-arguments-and-returns -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK32
+
+#include 
+
+bfloat16x4_t test_vcreate_bf16(uint64_t a) {
+  return vcreate_bf16(a);
+}
+// CHECK-LABEL: test_vcreate_bf16
+// CHECK64: %0 = bitcast i64 %a to <4 x bfloat>
+// CHECK32: %0 = bitcast i64 %a to <4 x bfloat>
+
+bfloat16x4_t test_vdup_n_bf16(bfloat16_t v) {
+  return vdup_n_bf16(v);
+}
+// CHECK-LABEL: test_vdup_n_bf16
+// CHECK64: %vecinit.i = insertelement <4 x bfloat> undef, bfloat %v, i32 0
+// CHECK32: %vecinit.i = insertelement <4 x bfloat> undef, bfloat %v, i32 0
+// CHECK: %vecinit{{.*}} = shufflevector <4 x bfloat> %vecinit.i, <4 x bfloat> undef, <4 x i32> zeroinitializer
+
+bfloat16x8_t test_vdupq_n_bf16(bfloat16_t v) {
+  return vdupq_n_bf16(v);
+}
+// CHECK-LABEL: test_vdupq_n_bf16
+// CHECK64: %vecinit.i = insertelement <8 x bfloat> undef, bfloat %v, i32 0
+// CHECK32: %vecinit.i = insertelement <8 x bfloat> undef, bfloat %v, i32 0
+// CHECK:   %vecinit{{.*}} = shufflevector <8 x bfloat> %vecinit.i, <8 x bfloat> undef, <8 x i32> zeroinitializer
+
+bfloat16x4_t test_vdup_lane_bf16(bfloat16x4_t v) {
+  return vdup_lane_bf16(v, 1);
+}
+// CHECK-LABEL: test_vdup_lane_bf16
+// CHECK64: %lane = shufflevector <4 x bfloat> %v, <4 x bfloat> undef, <4 x i32> 
+// CHECK32: %lane = shufflevector <4 x bfloat> %v, <4 x bfloat> undef, <4 x i32> 
+
+bfloat16x8_t test_vdupq_lane_bf16(bfloat16x4_t v) {
+  return vdupq_lane_bf16(v, 1);
+}
+// CHECK-LABEL: test_vdupq_lane_bf16
+// CHECK64: %lane = shufflevector <4 x bfloat> %v, <4 x bfloat> undef, <8 x i32> 
+// CHECK32: %lane = shufflevector <4 x bfloat> %v, <4 x bfloat> undef, <8 x i32> 
+
+bfloat16x4_t test_vdup_laneq_bf16(bfloat16x8_t v) {
+  return vdup_laneq_bf16(v, 7);
+}
+// CHECK-LABEL: test_vdup_laneq_bf16
+// CHECK64: %lane = shufflevector <8 x bfloat> %v, <8 x bfloat> undef, <4 x i32> 
+// CHECK32: %lane = shufflevector <8 x bfloat> %v, <8 x bfloat> undef, <4 x i32> 
+
+bfloat16x8_t test_vdupq_laneq_bf16(bfloat16x8_t v) {
+  return vdupq_laneq_bf16(v, 7);
+}
+// CHECK-LABEL: test_vdupq_laneq_bf16
+// CHECK64: %lane = shufflevector <8 x bfloat> %v, <8 x bfloat> undef, <8 x i32> 
+// CHECK32: %lane = shufflevector <8 x bfloat> %v, <8 x bfloat> undef, <8 x i32> 
+
+bfloat16x8_t test_vcombine_bf16(bfloat16x4_t low, bfloat16x4_t high) {
+  return vcombine_bf16(low, high);
+}
+// CHECK-LABEL: test_vcombine_bf16
+// CHECK64: %shuffle.i = shufflevector <4 x bfloat> %low, <4 x bfloat> %high, <8 x i32> 
+// CHECK32: %shuffle.i = shufflevector <4 x bfloat> %low, <4 x bfloat> %high, <8 x i32> 
+
+bfloat16x4_t test_vget_high_bf16(bfloat16x8_t a) {
+  return vget_high_bf16(a);
+}
+// CHECK-LABEL: test_vget_high_bf16
+// CHECK64: %shuffle.i = shufflevector <8 x bfloat> %a, <8 x bfloat> undef, <4 x i32> 
+// CHECK32: %shuffle.i = shufflevector <8 x bfloat> %a, <8 x bfloat> undef, <4 x i32> 
+
+bfloat16x4_t test_vget_low_bf16(bfloat16x8_t a) {
+  return vget_low_bf16(a);
+}
+// CHECK-LABEL: test_vget_low_bf16
+// CHECK64: %shuffle.i = shufflevector <8 x bfloat> %a, <8 x bfloat> undef, <4 x i32> 
+// CHECK32: %shuffle.i = shufflevector <8 x bfloat> %a, <8 x bfloat> undef, <4 x i32> 
+
+bfloat16_t test_vget_lane_bf16(bfloat16x4_t v) {
+  return vget_lane_bf16(v, 1);
+}
+// CHECK-LABEL: test_vget_lane_bf16
+// CHECK64: %vget_lane = extractelement <4 x bfloat> %v, i32 1
+// CHECK32: %vget_lane = extractelement <4 x bfloat> %v, i32 1
+
+bfloat16_t test_vgetq_lane_bf16(bfloat16x8_t v) {
+  return vgetq_lane_bf16(v, 7);
+}
+// CHECK-LABEL: test_vgetq_lane_bf16
+// CHECK64: %vgetq_lane = extractelement <8 x bfloat> %v, i32 7
+// CHECK32: %vget_lane = extractelement <8 x bfloat> %v, i32 7
+
+bfloat16x4_t test_vset_lane_bf16(bfloat16_t a, bfloat16x4_t v) {
+  return vset_lane_bf16(a, v, 1);
+}
+// CHECK-LABEL: test_vset_lane_bf16
+// CHECK64: %vset_lane = insertelement <4 x bfloat> %v, bfloat %a, i32 1
+// CHECK32: %vset_lane = insertelement <4 x bfloat> %v, bfloat %a, i32 1
+
+bfloat16x8_t 

[PATCH] D80014: Turn -Wmax-tokens off by default

2020-05-18 Thread Hans Wennborg via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG87b235db63a3: Turn -Wmax-tokens off by default (authored by 
hans).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80014

Files:
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/test/Parser/max-tokens.cpp


Index: clang/test/Parser/max-tokens.cpp
===
--- clang/test/Parser/max-tokens.cpp
+++ clang/test/Parser/max-tokens.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
-// RUN: %clang_cc1 -fsyntax-only -verify %s -DMAX_TOKENS  
-fmax-tokens=2
-// RUN: %clang_cc1 -fsyntax-only -verify %s -DMAX_TOKENS_OVERRIDE 
-fmax-tokens=9
+// RUN: %clang_cc1 -fsyntax-only -verify %s -Wmax-tokens
+// RUN: %clang_cc1 -fsyntax-only -verify %s -Wmax-tokens -DMAX_TOKENS  
-fmax-tokens=2
+// RUN: %clang_cc1 -fsyntax-only -verify %s -Wmax-tokens -DMAX_TOKENS_OVERRIDE 
-fmax-tokens=9
 
 int x, y, z;
 
Index: clang/include/clang/Basic/DiagnosticParseKinds.td
===
--- clang/include/clang/Basic/DiagnosticParseKinds.td
+++ clang/include/clang/Basic/DiagnosticParseKinds.td
@@ -1428,11 +1428,11 @@
 
 def warn_max_tokens : Warning<
   "the number of preprocessor source tokens (%0) exceeds this token limit 
(%1)">,
-  InGroup;
+  InGroup, DefaultIgnore;
 
 def warn_max_tokens_total : Warning<
   "the total number of preprocessor source tokens (%0) exceeds the token limit 
(%1)">,
-  InGroup;
+  InGroup, DefaultIgnore;
 
 def note_max_tokens_total_override : Note<"total token limit set here">;
 
Index: clang/include/clang/Basic/DiagnosticGroups.td
===
--- clang/include/clang/Basic/DiagnosticGroups.td
+++ clang/include/clang/Basic/DiagnosticGroups.td
@@ -1202,5 +1202,8 @@
 These limits can be helpful in limiting code growth through included files.
 
 Setting a token limit of zero means no limit.
+
+Note that the warning is disabled by default, so -Wmax-tokens must be used
+in addition with the pragmas or -fmax-tokens flag to get any warnings.
 }];
 }


Index: clang/test/Parser/max-tokens.cpp
===
--- clang/test/Parser/max-tokens.cpp
+++ clang/test/Parser/max-tokens.cpp
@@ -1,6 +1,6 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s
-// RUN: %clang_cc1 -fsyntax-only -verify %s -DMAX_TOKENS  -fmax-tokens=2
-// RUN: %clang_cc1 -fsyntax-only -verify %s -DMAX_TOKENS_OVERRIDE -fmax-tokens=9
+// RUN: %clang_cc1 -fsyntax-only -verify %s -Wmax-tokens
+// RUN: %clang_cc1 -fsyntax-only -verify %s -Wmax-tokens -DMAX_TOKENS  -fmax-tokens=2
+// RUN: %clang_cc1 -fsyntax-only -verify %s -Wmax-tokens -DMAX_TOKENS_OVERRIDE -fmax-tokens=9
 
 int x, y, z;
 
Index: clang/include/clang/Basic/DiagnosticParseKinds.td
===
--- clang/include/clang/Basic/DiagnosticParseKinds.td
+++ clang/include/clang/Basic/DiagnosticParseKinds.td
@@ -1428,11 +1428,11 @@
 
 def warn_max_tokens : Warning<
   "the number of preprocessor source tokens (%0) exceeds this token limit (%1)">,
-  InGroup;
+  InGroup, DefaultIgnore;
 
 def warn_max_tokens_total : Warning<
   "the total number of preprocessor source tokens (%0) exceeds the token limit (%1)">,
-  InGroup;
+  InGroup, DefaultIgnore;
 
 def note_max_tokens_total_override : Note<"total token limit set here">;
 
Index: clang/include/clang/Basic/DiagnosticGroups.td
===
--- clang/include/clang/Basic/DiagnosticGroups.td
+++ clang/include/clang/Basic/DiagnosticGroups.td
@@ -1202,5 +1202,8 @@
 These limits can be helpful in limiting code growth through included files.
 
 Setting a token limit of zero means no limit.
+
+Note that the warning is disabled by default, so -Wmax-tokens must be used
+in addition with the pragmas or -fmax-tokens flag to get any warnings.
 }];
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D79903: FastMathFlags.allowContract should be init from FPFeatures.allowFPContractAcrossStatement

2020-05-18 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: clang/lib/Frontend/CompilerInvocation.cpp:2943
+  if (Opts.FastRelaxedMath)
+Opts.setDefaultFPContractMode(LangOptions::FPM_Fast);
   Opts.HexagonQdsp6Compat = Args.hasArg(OPT_mqdsp6_compat);

mibintc wrote:
> mibintc wrote:
> > rjmccall wrote:
> > > michele.scandale wrote:
> > > > mibintc wrote:
> > > > > mibintc wrote:
> > > > > > rjmccall wrote:
> > > > > > > mibintc wrote:
> > > > > > > > rjmccall wrote:
> > > > > > > > > mibintc wrote:
> > > > > > > > > > I changed this because the FAST version of this test 
> > > > > > > > > > clang/test/CodeGenOpenCL/relaxed-fpmath.cl wants the 'fast' 
> > > > > > > > > > attribute on the instruction dump.  All the LLVM FMF bits 
> > > > > > > > > > must be set for the fast attribute print.  By default, the 
> > > > > > > > > > value for OpenCL is ffp-contract=on
> > > > > > > > > Is there an overall behavior change for OpenCL across these 
> > > > > > > > > patches?
> > > > > > > > I think the answer to your question is no.  Here is more 
> > > > > > > > details: OpenCL sets the default behavior to ffp-contract=on.  
> > > > > > > > In https://reviews.llvm.org/D72841 I added the function 
> > > > > > > > UpdateFastMathFlags, that function set the llvm 
> > > > > > > > FMF.allowContract bit to be ( ffp-contract=on or 
> > > > > > > > ffp-contract=fast).  This patch just drops the check on 
> > > > > > > > ffp-contract=on.   I didn't wind back to see how the llvm fast 
> > > > > > > > attribute was being set for this [opencl] test case originally. 
> > > > > > > Well, to what extent are there (including this patch) overall 
> > > > > > > test changes for the OpenCL tests, and what are tthey?
> > > > > > In the #pragma float_control patch https://reviews.llvm.org/D72841, 
> > > > > > I changed 2 CodeGen/OpenCL tests: relaxed-fp-math.cl in the 
> > > > > > non-FAST cases to show the contract bit.  Also 1 line in 
> > > > > > single-precision-constant.cl for the same reason, to show the 
> > > > > > contract bit.  This patch undoes those test changes. I'll do more 
> > > > > > investigation to understand why the fast bit isn't being set in the 
> > > > > > FAST case in relaxed-fpmath.cl without the change to 
> > > > > > CompilerInovcaton
> > > > > Prior to the patch for #pragma float_control, the llvm.FastMathFlags 
> > > > > was initialized from LangArgs.FastMath in the CodeGenFunction 
> > > > > constructor approximately line 74, and the FMF values in IRBuilder 
> > > > > were never changed--For the test 
> > > > > clang/test/CodeGenOpenCL/relaxed-fpmath.cl with option 
> > > > > -cl-fast-relaxed-math.  (In ParseLangArgs,  Opts.FastMath = 
> > > > > Args.hasArg(OPT_ffast_math) ||  
> > > > > Args.hasArg(OPT_cl_fast_relaxed_math))  If FastMath is on, then all 
> > > > > the llvm.FMF flags are set.
> > > > > 
> > > > > The #pragma float_control patch does change the IRBuilder settings in 
> > > > > the course of visiting the Expr nodes, using the information in the 
> > > > > Expr nodes, but the initial setting of FPFeatures from the command 
> > > > > line overlooked the fact that FastMath, and therefore 
> > > > > ffp-contract=fast, is enabled. 
> > > > Prior to D72841 compiling something with `-ffast-math 
> > > > -ffp-contract={on,off}` was still producing `fast` as fast-math flags 
> > > > on the instructions for the same reason.
> > > > The clang driver does not consider the contraction mode for passing 
> > > > `-ffast-math` to CC1, which is consistent with the GCC behavior (I 
> > > > checked if the `__FAST_MATH__` is defined if I compile with 
> > > > `-ffast-math -ffp-contract=off`).
> > > > According to this, the code in `CodeGenFunction`:
> > > > ```
> > > > if (LangOpts.FastMath)
> > > >   FMF.setFast();
> > > > ```
> > > > is not correct.
> > > > 
> > > > The OpenCL option `-cl-fast-relaxed-math` should be equivalent to 
> > > > `-ffast-math` for the user. I don't know what the interaction between 
> > > > `-cl-fast-relaxed-math` and `-ffp-contract={on, off,fast}`.
> > > > 
> > > > If we need to keep `-cl-fast-relaxed-math` a CC1 option, I guess the 
> > > > following might work:
> > > > ```
> > > > if (Args.hasArg(OPTS_cl_fast_relaxed_math) && 
> > > > !Arg.hasArg(OPT_ffp_contractEQ))
> > > >   Opts.setDefaultFPContractMode)LangOptions::FPM_Fast);
> > > > ```
> > > Okay, thanks for the investigation, I agree that that all makes sense.  
> > > I'm not sure what it would mean to enable fast math but disable 
> > > contraction — that combination doesn't seem useful.
> > > 
> > > I'm fine with going forward with the OpenCL changes as they are, but you 
> > > might want to specifically reach out to the OpenCL people and let them 
> > > know what's going on.
> > @arsenm Matt, I'm making this change to CompilerInvocation to fix a bug 
> > that was introduced by https://reviews.llvm.org/D72841  I see that you 
> > contribute to OpenCL will you please let interested folks 

[PATCH] D68115: Zero initialize padding in unions

2020-05-18 Thread Thorsten via Phabricator via cfe-commits
tschuett added a comment.

I watched the talk, but I still prefer compile-time errors over runtime crashes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D68115



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


[PATCH] D80025: [ASTMatcher] Correct memoization bug ignoring direction (descendants or ancestors)

2020-05-18 Thread Loïc Joly via Phabricator via cfe-commits
loic-joly-sonarsource updated this revision to Diff 264709.
loic-joly-sonarsource added a comment.

Take into account transitive/non transitive request
Clarify unit tests


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

https://reviews.llvm.org/D80025

Files:
  clang/lib/ASTMatchers/ASTMatchFinder.cpp
  clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp


Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -2689,6 +2689,34 @@
 compoundStmt(hasParent(ifStmt();
 }
 
+TEST(MatcherMemoize, HasParentDiffersFromHas) {
+  // Test introduced after detecting a bug in memoization
+  constexpr auto code = "void f() { throw 1; }";
+  EXPECT_TRUE(notMatches(
+code,
+cxxThrowExpr(hasParent(expr();
+  EXPECT_TRUE(matches(
+code,
+cxxThrowExpr(has(expr();
+  EXPECT_TRUE(matches(
+code,
+cxxThrowExpr(anyOf(hasParent(expr()), has(expr());
+}
+
+TEST(MatcherMemoize, HasDiffersFromHasDescendant) {
+  // Test introduced after detecting a bug in memoization
+  constexpr auto code = "void f() { throw 1+1; }";
+  EXPECT_TRUE(notMatches(
+code,
+cxxThrowExpr(has(integerLiteral();
+  EXPECT_TRUE(matches(
+code,
+cxxThrowExpr(hasDescendant(integerLiteral();
+  EXPECT_TRUE(notMatches(code, 
+cxxThrowExpr(allOf(
+  hasDescendant(integerLiteral()),
+  has(integerLiteral());
+}
 TEST(HasAncestor, MatchesAllAncestors) {
   EXPECT_TRUE(matches(
 "template  struct C { static void f() { 42; } };"
Index: clang/lib/ASTMatchers/ASTMatchFinder.cpp
===
--- clang/lib/ASTMatchers/ASTMatchFinder.cpp
+++ clang/lib/ASTMatchers/ASTMatchFinder.cpp
@@ -43,6 +43,13 @@
 // optimize this on.
 static const unsigned MaxMemoizationEntries = 1;
 
+enum class MatchType {
+  Ancestors,
+  Descendants,
+  Parent,
+  Child
+};
+
 // We use memoization to avoid running the same matcher on the same
 // AST node twice.  This struct is the key for looking up match
 // result.  It consists of an ID of the MatcherInterface (for
@@ -60,10 +67,11 @@
   DynTypedNode Node;
   BoundNodesTreeBuilder BoundNodes;
   TraversalKind Traversal = TK_AsIs;
+  MatchType Type;
 
   bool operator<(const MatchKey ) const {
-return std::tie(Traversal, MatcherID, Node, BoundNodes) <
-   std::tie(Other.Traversal, Other.MatcherID, Other.Node,
+return std::tie(Traversal, Type, MatcherID, Node, BoundNodes) <
+   std::tie(Other.Traversal, Other.Type, Other.MatcherID, Other.Node,
 Other.BoundNodes);
   }
 };
@@ -456,7 +464,7 @@
 // Note that we key on the bindings *before* the match.
 Key.BoundNodes = *Builder;
 Key.Traversal = Ctx.getParentMapContext().getTraversalKind();
-
+Key.Type = MaxDepth == 1 ? MatchType::Child : MatchType::Descendants;
 MemoizationMap::iterator I = ResultCache.find(Key);
 if (I != ResultCache.end()) {
   *Builder = I->second.Nodes;
@@ -702,6 +710,8 @@
 Key.Node = Node;
 Key.BoundNodes = *Builder;
 Key.Traversal = Ctx.getParentMapContext().getTraversalKind();
+Key.Type = MatchMode == AncestorMatchMode::AMM_ParentOnly ? 
+  MatchType::Parent : MatchType::Ancestors;
 
 // Note that we cannot use insert and reuse the iterator, as recursive
 // calls to match might invalidate the result cache iterators.


Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -2689,6 +2689,34 @@
 compoundStmt(hasParent(ifStmt();
 }
 
+TEST(MatcherMemoize, HasParentDiffersFromHas) {
+  // Test introduced after detecting a bug in memoization
+  constexpr auto code = "void f() { throw 1; }";
+  EXPECT_TRUE(notMatches(
+code,
+cxxThrowExpr(hasParent(expr();
+  EXPECT_TRUE(matches(
+code,
+cxxThrowExpr(has(expr();
+  EXPECT_TRUE(matches(
+code,
+cxxThrowExpr(anyOf(hasParent(expr()), has(expr());
+}
+
+TEST(MatcherMemoize, HasDiffersFromHasDescendant) {
+  // Test introduced after detecting a bug in memoization
+  constexpr auto code = "void f() { throw 1+1; }";
+  EXPECT_TRUE(notMatches(
+code,
+cxxThrowExpr(has(integerLiteral();
+  EXPECT_TRUE(matches(
+code,
+cxxThrowExpr(hasDescendant(integerLiteral();
+  EXPECT_TRUE(notMatches(code, 
+cxxThrowExpr(allOf(
+  hasDescendant(integerLiteral()),
+  has(integerLiteral());
+}
 TEST(HasAncestor, MatchesAllAncestors) {
   EXPECT_TRUE(matches(
 "template  struct C { static void f() { 42; } };"
Index: clang/lib/ASTMatchers/ASTMatchFinder.cpp

[PATCH] D74572: [BPF] preserve debuginfo types for builtin __builtin__btf_type_id()

2020-05-18 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added subscribers: JDevlieghere, probinson, aprantl, echristo, 
dblaikie.
dblaikie added a comment.

This seems like a fairly invasive way to preserve certain DWARF types.

Are you in a position to make source changes to help here? Would it be 
reasonable to annotate these types with __attribute__((used)), for instance? I 
think it'd probably be useful on the compiler end to support using that 
attribute to communicate the need for that type to be emitted into the debug 
info - and that could be powered by adding the attributed type to the 
DICompileUnit's "retainedTypes" list.

(& even if attribute used can't be used in your case, because you need to deal 
with the code as it's currently written - perhaps this whole feature could be 
replaced with a front-end tweak to add these particular types to the 
retainedTypes list under the same conditions you're doing all this other stuff? 
Without the need for the synthetic function calls, pass to remove them, etc)

(also, when making changes for/to debug info - probably worth including 
either/at least the debug-info tag and/or some of the usual debug info 
contributors (myself, @echristo, @aprantl, @JDevlieghere, @probinson, etc))


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74572



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


[PATCH] D74572: [BPF] preserve debuginfo types for builtin __builtin__btf_type_id()

2020-05-18 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

I think it'd probably be good to revert this/other patches, and maybe have a 
design discussion on cfe-dev. Could you do that?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74572



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


[PATCH] D80055: Diagnose union tail padding

2020-05-18 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

I'm not convinced that this is an especially useful diagnostic (much like with 
`-Wpadded`), but I'm also not opposed if you are aware of cases where it would 
be used.

It seems worth pointing out that, at least in C, merely assigning to a union 
member results in all padding becoming unspecified (6.2.6.1/7). So the 
suggestion to `memset` the union to zero and then assign to a specific union 
member does not work.




Comment at: clang/include/clang/Basic/DiagnosticFrontendKinds.td:264
+def warn_union_tail_padding_uninitialized : Warning<
+  "Initializing union %0 field %1 only initializes the first %2 of %3 bytes, 
leaving the remaining %4 bytes undefined">,
+  InGroup;

jfb wrote:
> Something which I'm not sure matters:
> 
> ```
> union Unnamed {
>   union {
> int i;
> float f;
>   };
>   char bytes[8];
> };
> 
> union Unnamed unnamed = { 42 };
> ```
> 
> Will generate the following diagnostic:
> 
> ```
> warning: Initializing union 'Unnamed' field '' only initializes the first 4 
> of 8 bytes, leaving the remaining 4 bytes undefined [-Wunion-tail-padding]
> union Unnamed unnamed = { 42 };
> ^
> ```
> 
> I think that's generally how we handle unnamed members anyways?
Please start diagnostic messages with a lowercase letter.

In the case you identify, it'd be nice to say "initializing union `Unnamed` 
field `i` only initializes [...]". (We should probably special-case formatting 
a declaration with an empty name and print out something like `''` 
instead, but that's not specific to this diagnostic.)

Also, I think this would read more naturally as "initializing field `i` of 
union `Unnamed` only initializes [...]".



Comment at: clang/include/clang/Basic/DiagnosticGroups.td:825
+def Padding : DiagGroup<"padding", [UnionTailPadding]>,
+  DiagCategory<"Padding Issue">;
+

jfb wrote:
> I'd like to hear what other diagnostics folks think should fit under the 
> `Padding` group. I've focused not on declarations which have padding, but 
> rather on initializations which leave uninitialized padding behind. It seems 
> like internal padding for structs and between array elements would be 
> desirable.
It seems to me that including this in the existing `-Wpadded` warning group 
would be reasonable (I prefer the name `-Wpadding` over `-Wpadded` for what 
it's worth, but it seems problematic to include both with different meanings.)

`-Wpadded` currently warns whenever struct layout inserts interior or tail 
padding. Also warning on union fields that, when active, would result in tail 
padding seems reasonable to me too.

(The new warning seems like something that would be hard to enable on any 
sizeable codebase, or with any headers that aren't under the end-user's 
control, which I find somewhat concerning. But the old `-Wpadded` warning has 
the same issues, so this seems like it's not making things worse.)



Comment at: clang/lib/CodeGen/CGExprConstant.cpp:608-612
+  // The tail padding of the union isn't being initialized.
+  CGM.getDiags().Report(loc, diag::warn_union_tail_padding_uninitialized)
+  << Field->getParent() << Field << (unsigned)InitSize.getQuantity()
+  << (unsigned)UnionSize.getQuantity()
+  << (unsigned)(UnionSize - InitSize).getQuantity();

I don't think it's acceptable to produce a warning such as this from IR 
generation, and especially not from here -- which we may or may not reach 
depending on a diverse set of factors (in particular, whether the initializer 
happens to be a constant).

I think either you should warn from record layout, like we do for `-Wpadded`, 
or from `SemaInit` (if you only want this to apply if the narrower field is 
actually initialized).



Comment at: clang/test/CodeGen/union-tail-padding.c:28-36
+union Front {
+  int i;
+  long long ll;
+};
+
+union Front front1;
+union Front front2 = {};// expected-warning {{Initializing union 
'Front' field 'i' only initializes the first 4 of 8 bytes, leaving the 
remaining 4 bytes undefined}}

dexonsmith wrote:
> jfb wrote:
> > dexonsmith wrote:
> > > jfb wrote:
> > > > dexonsmith wrote:
> > > > > Are these warnings actionable?  What should users do when they see 
> > > > > this warning?
> > > > Good point!
> > > > 
> > > > I was thinking about this, and was wondering if I should add a fixit 
> > > > which suggests using the first wider member of the union. The problem 
> > > > is to offer the same object representation... that's tricky on its own 
> > > > (there isn't always an exact match), and then we have to deal with type 
> > > > punning (in C++, not in C).
> > > > 
> > > > So I'd love ideas, because I'm not sure what to do. That being said, I 
> > > > wrote this partly because D68115 was surprising to folks, and partly 
> > > > because developers would like to opt-in to this diagnostic to find 
> > > > 

[PATCH] D79456: [clangd] Complete filenames after < / ".

2020-05-18 Thread Sam McCall via Phabricator via cfe-commits
sammccall updated this revision to Diff 264721.
sammccall added a comment.

Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79456

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/CodeComplete.h
  clang-tools-extra/clangd/test/initialize-params.test
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp

Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -25,6 +25,7 @@
 #include "clang/Tooling/CompilationDatabase.h"
 #include "llvm/Support/Error.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Testing/Support/Annotations.h"
 #include "llvm/Testing/Support/Error.h"
 #include "gmock/gmock.h"
 #include "gtest/gtest.h"
@@ -2828,6 +2829,34 @@
   ElementsAre(AllOf(Qualifier(""), Scope("a::";
 }
 
+TEST(AllowImplicitCompletion, All) {
+  const char *Yes[] = {
+  "foo.^bar",
+  "foo->^bar",
+  "foo::^bar",
+  "  #  include <^foo.h>",
+  "#import ",
+  "#include_next \"^",
+  };
+  const char *No[] = {
+  "foo>^bar",
+  "foo:^bar",
+  "foo\n^bar",
+  "#include  //^",
+  "#include \"foo.h\"^",
+  "#error <^",
+  "#<^",
+  };
+  for (const char *Test : Yes) {
+llvm::Annotations A(Test);
+EXPECT_TRUE(allowImplicitCompletion(A.code(), A.point())) << Test;
+  }
+  for (const char *Test : No) {
+llvm::Annotations A(Test);
+EXPECT_FALSE(allowImplicitCompletion(A.code(), A.point())) << Test;
+  }
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/test/initialize-params.test
===
--- clang-tools-extra/clangd/test/initialize-params.test
+++ clang-tools-extra/clangd/test/initialize-params.test
@@ -11,8 +11,11 @@
 # CHECK-NEXT:"resolveProvider": false,
 # CHECK-NEXT:"triggerCharacters": [
 # CHECK-NEXT:  ".",
+# CHECK-NEXT:  "<",
 # CHECK-NEXT:  ">",
-# CHECK-NEXT:  ":"
+# CHECK-NEXT:  ":",
+# CHECK-NEXT:  "\"",
+# CHECK-NEXT:  "/"
 # CHECK-NEXT:]
 # CHECK-NEXT:  },
 # CHECK-NEXT:  "declarationProvider": true,
Index: clang-tools-extra/clangd/CodeComplete.h
===
--- clang-tools-extra/clangd/CodeComplete.h
+++ clang-tools-extra/clangd/CodeComplete.h
@@ -314,6 +314,10 @@
 CompletionPrefix guessCompletionPrefix(llvm::StringRef Content,
unsigned Offset);
 
+// Whether it makes sense to complete at the point based on typed characters.
+// For instance, we implicitly trigger at `a->^` but not at `a>^`.
+bool allowImplicitCompletion(llvm::StringRef Content, unsigned Offset);
+
 } // namespace clangd
 } // namespace clang
 
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -1912,5 +1912,43 @@
   return OS;
 }
 
+// Heuristically detect whether the `Line` is an unterminated include filename.
+bool isIncludeFile(llvm::StringRef Line) {
+  Line = Line.ltrim();
+  if (!Line.consume_front("#"))
+return false;
+  Line = Line.ltrim();
+  if (!(Line.consume_front("include_next") || Line.consume_front("include") ||
+Line.consume_front("import")))
+return false;
+  Line = Line.ltrim();
+  if (Line.consume_front("<"))
+return Line.count('>') == 0;
+  if (Line.consume_front("\""))
+return Line.count('"') == 0;
+  return false;
+}
+
+bool allowImplicitCompletion(llvm::StringRef Content, unsigned Offset) {
+  // Look at last line before completion point only.
+  Content = Content.take_front(Offset);
+  auto Pos = Content.rfind('\n');
+  if (Pos != llvm::StringRef::npos)
+Content = Content.substr(Pos + 1);
+
+  // Complete after scope operators.
+  if (Content.endswith(".") || Content.endswith("->") || Content.endswith("::"))
+return true;
+  // Complete after `#include <` and #include 

[PATCH] D79456: [clangd] Complete filenames after < / ".

2020-05-18 Thread Sam McCall via Phabricator via cfe-commits
sammccall marked 3 inline comments as done.
sammccall added a comment.

*finally* getting back to this...




Comment at: clang-tools-extra/clangd/CodeComplete.cpp:1922
+  Line.consume_front("include") || Line.consume_front("import") ||
+  Line.consume_front("import_next");
+  Line = Line.ltrim();

adamcz wrote:
> Did you mean include_next?
> 
> Also, this will never trigger, because you already consumed import before, so 
> you'd need "#importimport_next" ;-) Reverse the order.
> 
> You should also return false if the whole || thing is not true.
I have to get points for the number of bugs on one line, right?

(The import vs import_next overlap I have a reasonable excuse - these had 
trailing spaces until I learned that `#include` is legal!)

Added more tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79456



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


[PATCH] D80055: Diagnose union tail padding

2020-05-18 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith added inline comments.



Comment at: clang/test/CodeGen/union-tail-padding.c:28-36
+union Front {
+  int i;
+  long long ll;
+};
+
+union Front front1;
+union Front front2 = {};// expected-warning {{Initializing union 
'Front' field 'i' only initializes the first 4 of 8 bytes, leaving the 
remaining 4 bytes undefined}}

jfb wrote:
> dexonsmith wrote:
> > jfb wrote:
> > > dexonsmith wrote:
> > > > Are these warnings actionable?  What should users do when they see this 
> > > > warning?
> > > Good point!
> > > 
> > > I was thinking about this, and was wondering if I should add a fixit 
> > > which suggests using the first wider member of the union. The problem is 
> > > to offer the same object representation... that's tricky on its own 
> > > (there isn't always an exact match), and then we have to deal with type 
> > > punning (in C++, not in C).
> > > 
> > > So I'd love ideas, because I'm not sure what to do. That being said, I 
> > > wrote this partly because D68115 was surprising to folks, and partly 
> > > because developers would like to opt-in to this diagnostic to find places 
> > > where initialization isn't doing what they think.
> > > 
> > > Maybe instead we should suggest to leave uninitialized, and use an 
> > > assignment, or `memset`?
> > > Maybe instead we should suggest to leave uninitialized, and use an 
> > > assignment, or `memset`?
> > 
> > It's not clear to me that those are better.  For example, `memset` doesn't 
> > seem right for non-PODs in C++.  I'm not sure what to suggest though.
> I'd argue that non-PODs in unions don't seem right either ;-)
> It would be easy to diagnose non-trivially-copyable types differently in this 
> circumstance.
> It would be easy to diagnose non-trivially-copyable types differently in this 
> circumstance.

Good point.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80055



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


[clang] 9d69072 - [analyzer][NFC] Introduce CXXDeallocatorCall, deploy it in MallocChecker

2020-05-18 Thread Kirstóf Umann via cfe-commits

Author: Kirstóf Umann
Date: 2020-05-19T00:18:38+02:00
New Revision: 9d69072fb80755a0029a01c74892b4bf03f20f65

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

LOG: [analyzer][NFC] Introduce CXXDeallocatorCall, deploy it in MallocChecker

One of the pain points in simplifying MallocCheckers interface by gradually
changing to CallEvent is that a variety of C++ allocation and deallocation
functionalities are modeled through preStmt<...> where CallEvent is unavailable,
and a single one of these callbacks can prevent a mass parameter change.

This patch introduces a new CallEvent, CXXDeallocatorCall, which happens after
preStmt, and can completely replace that callback as
demonstrated.

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

Added: 
clang/unittests/StaticAnalyzer/CallEventTest.cpp

Modified: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
clang/lib/StaticAnalyzer/Checkers/DeleteWithNonVirtualDtorChecker.cpp
clang/lib/StaticAnalyzer/Checkers/MallocChecker.cpp
clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
clang/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
clang/test/Analysis/cxx-dynamic-memory-analysis-order.cpp
clang/unittests/StaticAnalyzer/CMakeLists.txt

Removed: 




diff  --git a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h 
b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
index bc562a4ca6f1..871875b45b1b 100644
--- a/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
+++ b/clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
@@ -67,8 +67,9 @@ enum CallEventKind {
   CE_BEG_CXX_CONSTRUCTOR_CALLS = CE_CXXConstructor,
   CE_END_CXX_CONSTRUCTOR_CALLS = CE_CXXInheritedConstructor,
   CE_CXXAllocator,
+  CE_CXXDeallocator,
   CE_BEG_FUNCTION_CALLS = CE_Function,
-  CE_END_FUNCTION_CALLS = CE_CXXAllocator,
+  CE_END_FUNCTION_CALLS = CE_CXXDeallocator,
   CE_Block,
   CE_ObjCMessage
 };
@@ -1045,6 +1046,55 @@ class CXXAllocatorCall : public AnyFunctionCall {
   }
 };
 
+/// Represents the memory deallocation call in a C++ delete-expression.
+///
+/// This is a call to "operator delete".
+// FIXME: CXXDeleteExpr isn't present for custom delete operators, or even for
+// some those that are in the standard library, like the no-throw or align_val
+// versions.
+// Some pointers:
+// http://lists.llvm.org/pipermail/cfe-dev/2020-April/065080.html
+// clang/test/Analysis/cxx-dynamic-memory-analysis-order.cpp
+// clang/unittests/StaticAnalyzer/CallEventTest.cpp
+class CXXDeallocatorCall : public AnyFunctionCall {
+  friend class CallEventManager;
+
+protected:
+  CXXDeallocatorCall(const CXXDeleteExpr *E, ProgramStateRef St,
+ const LocationContext *LCtx)
+  : AnyFunctionCall(E, St, LCtx) {}
+  CXXDeallocatorCall(const CXXDeallocatorCall ) = default;
+
+  void cloneTo(void *Dest) const override {
+new (Dest) CXXDeallocatorCall(*this);
+  }
+
+public:
+  virtual const CXXDeleteExpr *getOriginExpr() const {
+return cast(AnyFunctionCall::getOriginExpr());
+  }
+
+  const FunctionDecl *getDecl() const override {
+return getOriginExpr()->getOperatorDelete();
+  }
+
+  unsigned getNumArgs() const override { return getDecl()->getNumParams(); }
+
+  const Expr *getArgExpr(unsigned Index) const override {
+// CXXDeleteExpr's only have a single argument.
+return getOriginExpr()->getArgument();
+  }
+
+  Kind getKind() const override { return CE_CXXDeallocator; }
+  virtual StringRef getKindAsString() const override {
+return "CXXDeallocatorCall";
+  }
+
+  static bool classof(const CallEvent *CE) {
+return CE->getKind() == CE_CXXDeallocator;
+  }
+};
+
 /// Represents the ways an Objective-C message send can occur.
 //
 // Note to maintainers: OCM_Message should always be last, since it does not
@@ -1367,6 +1417,12 @@ class CallEventManager {
   const LocationContext *LCtx) {
 return create(E, State, LCtx);
   }
+
+  CallEventRef
+  getCXXDeallocatorCall(const CXXDeleteExpr *E, ProgramStateRef State,
+const LocationContext *LCtx) {
+return create(E, State, LCtx);
+  }
 };
 
 template 

diff  --git 
a/clang/lib/StaticAnalyzer/Checkers/DeleteWithNonVirtualDtorChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/DeleteWithNonVirtualDtorChecker.cpp
index 97556ca856a0..7c5833762008 100644
--- a/clang/lib/StaticAnalyzer/Checkers/DeleteWithNonVirtualDtorChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/DeleteWithNonVirtualDtorChecker.cpp
@@ -92,6 +92,8 @@ void DeleteWithNonVirtualDtorChecker::checkPreStmt(const 
CXXDeleteExpr *DE,
  "Logic error"));
 
   ExplodedNode *N = C.generateNonFatalErrorNode();

[PATCH] D79627: [AST] Fix an assertion violation in FieldDecl::getParent.

2020-05-18 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added a subscriber: rsmith.
sammccall added a comment.
This revision is now accepted and ready to land.

Sorry for stalling this. This is a sad situation, the API is actively 
misleading about the invariants.

Even the new API isn't very safe: getParent() isn't a great name if it only 
works on *some* things that have parents.
@rsmith any opinion on what we should do with this one? Would a rename to 
`getParentRecord()` help much? Something more invasive?

Approving since this is already a bit better and we can fix a crash.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79627



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


[PATCH] D80154: [AST] Fix recovery-AST crash: dependent overloaded call exprs are now possible.

2020-05-18 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

(Haha, I tried to send this 5 hours ago and found it waiting for me to confirm 
that clang-format could add a single space...)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80154



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


[clang] ef649e8 - Revert "[CUDA][HIP] Workaround for resolving host device function against wrong-sided function"

2020-05-18 Thread Artem Belevich via cfe-commits

Author: Artem Belevich
Date: 2020-05-18T12:22:55-07:00
New Revision: ef649e8fd5d1748764a9afca3ce0b80113a6a239

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

LOG: Revert "[CUDA][HIP] Workaround for resolving host device function against 
wrong-sided function"

Still breaks CUDA compilation.

This reverts commit e03394c6a6ff5832aa43259d4b8345f40ca6a22c.

Added: 


Modified: 
clang/include/clang/Sema/Sema.h
clang/lib/Sema/SemaCUDA.cpp
clang/lib/Sema/SemaOverload.cpp
clang/test/SemaCUDA/function-overload.cu

Removed: 




diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index 7a5820761bcd..831ea1f6163c 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -11666,8 +11666,6 @@ class Sema final {
 return IdentifyCUDATarget(dyn_cast(CurContext));
   }
 
-  static bool IsCUDAImplicitHostDeviceFunction(const FunctionDecl *D);
-
   // CUDA function call preference. Must be ordered numerically from
   // worst to best.
   enum CUDAFunctionPreference {

diff  --git a/clang/lib/Sema/SemaCUDA.cpp b/clang/lib/Sema/SemaCUDA.cpp
index eecea94e0dad..73d190891b0f 100644
--- a/clang/lib/Sema/SemaCUDA.cpp
+++ b/clang/lib/Sema/SemaCUDA.cpp
@@ -211,20 +211,6 @@ Sema::IdentifyCUDAPreference(const FunctionDecl *Caller,
   llvm_unreachable("All cases should've been handled by now.");
 }
 
-template  static bool hasImplicitAttr(const FunctionDecl *D) {
-  if (!D)
-return false;
-  if (auto *A = D->getAttr())
-return A->isImplicit();
-  return D->isImplicit();
-}
-
-bool Sema::IsCUDAImplicitHostDeviceFunction(const FunctionDecl *D) {
-  bool IsImplicitDevAttr = hasImplicitAttr(D);
-  bool IsImplicitHostAttr = hasImplicitAttr(D);
-  return IsImplicitDevAttr && IsImplicitHostAttr;
-}
-
 void Sema::EraseUnwantedCUDAMatches(
 const FunctionDecl *Caller,
 SmallVectorImpl> ) {

diff  --git a/clang/lib/Sema/SemaOverload.cpp b/clang/lib/Sema/SemaOverload.cpp
index 18ce491580c1..1b00b2b18572 100644
--- a/clang/lib/Sema/SemaOverload.cpp
+++ b/clang/lib/Sema/SemaOverload.cpp
@@ -9374,22 +9374,16 @@ static Comparison compareEnableIfAttrs(const Sema , 
const FunctionDecl *Cand1,
   return Comparison::Equal;
 }
 
-static Comparison
-isBetterMultiversionCandidate(const OverloadCandidate ,
-  const OverloadCandidate ) {
+static bool isBetterMultiversionCandidate(const OverloadCandidate ,
+  const OverloadCandidate ) {
   if (!Cand1.Function || !Cand1.Function->isMultiVersion() || !Cand2.Function 
||
   !Cand2.Function->isMultiVersion())
-return Comparison::Equal;
+return false;
 
-  // If both are invalid, they are equal. If one of them is invalid, the other
-  // is better.
-  if (Cand1.Function->isInvalidDecl()) {
-if (Cand2.Function->isInvalidDecl())
-  return Comparison::Equal;
-return Comparison::Worse;
-  }
-  if (Cand2.Function->isInvalidDecl())
-return Comparison::Better;
+  // If Cand1 is invalid, it cannot be a better match, if Cand2 is invalid, 
this
+  // is obviously better.
+  if (Cand1.Function->isInvalidDecl()) return false;
+  if (Cand2.Function->isInvalidDecl()) return true;
 
   // If this is a cpu_dispatch/cpu_specific multiversion situation, prefer
   // cpu_dispatch, else arbitrarily based on the identifiers.
@@ -9399,18 +9393,16 @@ isBetterMultiversionCandidate(const OverloadCandidate 
,
   const auto *Cand2CPUSpec = Cand2.Function->getAttr();
 
   if (!Cand1CPUDisp && !Cand2CPUDisp && !Cand1CPUSpec && !Cand2CPUSpec)
-return Comparison::Equal;
+return false;
 
   if (Cand1CPUDisp && !Cand2CPUDisp)
-return Comparison::Better;
+return true;
   if (Cand2CPUDisp && !Cand1CPUDisp)
-return Comparison::Worse;
+return false;
 
   if (Cand1CPUSpec && Cand2CPUSpec) {
 if (Cand1CPUSpec->cpus_size() != Cand2CPUSpec->cpus_size())
-  return Cand1CPUSpec->cpus_size() < Cand2CPUSpec->cpus_size()
- ? Comparison::Better
- : Comparison::Worse;
+  return Cand1CPUSpec->cpus_size() < Cand2CPUSpec->cpus_size();
 
 std::pair
 FirstDiff = std::mismatch(
@@ -9423,9 +9415,7 @@ isBetterMultiversionCandidate(const OverloadCandidate 
,
 assert(FirstDiff.first != Cand1CPUSpec->cpus_end() &&
"Two 
diff erent cpu-specific versions should not have the same "
"identifier list, otherwise they'd be the same decl!");
-return (*FirstDiff.first)->getName() < (*FirstDiff.second)->getName()
-   ? Comparison::Better
-   : Comparison::Worse;
+return (*FirstDiff.first)->getName() < (*FirstDiff.second)->getName();
   }
   llvm_unreachable("No way to get here unless both had cpu_dispatch");
 }
@@ -9485,66 +9475,6 @@ 

[clang-tools-extra] d19265b - [clangd] Avoid wasteful data structures in RefSlab::Builder

2020-05-18 Thread Sam McCall via cfe-commits

Author: Sam McCall
Date: 2020-05-18T22:34:59+02:00
New Revision: d19265b31e65c84ad908abce6e7f6e6d15c22258

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

LOG: [clangd] Avoid wasteful data structures in RefSlab::Builder

Summary: This is worth another 10% or so on InedxBenchmark.DexBuild.

Reviewers: kbobyrev

Subscribers: ilya-biryukov, MaskRay, jkorous, mgrang, arphaman, kadircet, 
usaxena95, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang-tools-extra/clangd/index/Ref.cpp
clang-tools-extra/clangd/index/Ref.h
clang-tools-extra/clangd/index/SymbolLocation.cpp
clang-tools-extra/clangd/index/SymbolLocation.h

Removed: 




diff  --git a/clang-tools-extra/clangd/index/Ref.cpp 
b/clang-tools-extra/clangd/index/Ref.cpp
index 115894ce6743..e622a3f78e42 100644
--- a/clang-tools-extra/clangd/index/Ref.cpp
+++ b/clang-tools-extra/clangd/index/Ref.cpp
@@ -7,6 +7,7 @@
 
//===--===//
 
 #include "Ref.h"
+#include "llvm/ADT/STLExtras.h"
 
 namespace clang {
 namespace clangd {
@@ -33,27 +34,34 @@ llvm::raw_ostream <<(llvm::raw_ostream , const 
Ref ) {
 }
 
 void RefSlab::Builder::insert(const SymbolID , const Ref ) {
-  auto  = Refs[ID];
-  if (M.count(S))
-return;
-  Ref R = S;
-  R.Location.FileURI =
-  UniqueStrings.save(R.Location.FileURI).data();
-  M.insert(std::move(R));
+  Entry E = {ID, S};
+  E.Reference.Location.FileURI = UniqueStrings.save(S.Location.FileURI).data();
+  Entries.insert(std::move(E));
 }
 
 RefSlab RefSlab::Builder::build() && {
-  // We can reuse the arena, as it only has unique strings and we need them 
all.
-  // Reallocate refs on the arena to reduce waste and indirections when 
reading.
   std::vector>> Result;
-  Result.reserve(Refs.size());
-  size_t NumRefs = 0;
-  for (auto  : Refs) {
-std::vector SymRefs(Sym.second.begin(), Sym.second.end());
-NumRefs += SymRefs.size();
-Result.emplace_back(Sym.first, llvm::ArrayRef(SymRefs).copy(Arena));
+  // We'll reuse the arena, as it only has unique strings and we need them all.
+  // We need to group refs by symbol and form contiguous arrays on the arena.
+  std::vector> Flat;
+  Flat.reserve(Entries.size());
+  for (const Entry  : Entries)
+Flat.emplace_back(E.Symbol, );
+  // Group by SymbolID.
+  llvm::sort(Flat, llvm::less_first());
+  std::vector Refs;
+  // Loop over symbols, copying refs for each onto the arena.
+  for (auto I = Flat.begin(), End = Flat.end(); I != End;) {
+SymbolID Sym = I->first;
+Refs.clear();
+do {
+  Refs.push_back(*I->second);
+  ++I;
+} while (I != End && I->first == Sym);
+llvm::sort(Refs); // By file, affects xrefs display order.
+Result.emplace_back(Sym, llvm::ArrayRef(Refs).copy(Arena));
   }
-  return RefSlab(std::move(Result), std::move(Arena), NumRefs);
+  return RefSlab(std::move(Result), std::move(Arena), Entries.size());
 }
 
 } // namespace clangd

diff  --git a/clang-tools-extra/clangd/index/Ref.h 
b/clang-tools-extra/clangd/index/Ref.h
index 382ade712017..cba8adaee7c2 100644
--- a/clang-tools-extra/clangd/index/Ref.h
+++ b/clang-tools-extra/clangd/index/Ref.h
@@ -13,6 +13,8 @@
 #include "SymbolLocation.h"
 #include "clang/Index/IndexSymbol.h"
 #include "llvm/ADT/DenseMap.h"
+#include "llvm/ADT/Hashing.h"
+#include "llvm/Support/Allocator.h"
 #include "llvm/Support/StringSaver.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
@@ -132,9 +134,17 @@ class RefSlab {
 RefSlab build() &&;
 
   private:
+// A ref we're storing with its symbol to consume with build().
+// All strings are interned, so DenseMapInfo can use pointer comparisons.
+struct Entry {
+  SymbolID Symbol;
+  Ref Reference;
+};
+friend struct llvm::DenseMapInfo;
+
 llvm::BumpPtrAllocator Arena;
 llvm::UniqueStringSaver UniqueStrings; // Contents on the arena.
-llvm::DenseMap> Refs;
+llvm::DenseSet Entries;
   };
 
 private:
@@ -151,4 +161,31 @@ class RefSlab {
 } // namespace clangd
 } // namespace clang
 
+namespace llvm {
+template <> struct DenseMapInfo {
+  using Entry = clang::clangd::RefSlab::Builder::Entry;
+  static inline Entry getEmptyKey() {
+static Entry E{clang::clangd::SymbolID(""), {}};
+return E;
+  }
+  static inline Entry getTombstoneKey() {
+static Entry E{clang::clangd::SymbolID("TOMBSTONE"), {}};
+return E;
+  }
+  static unsigned getHashValue(const Entry ) {
+return llvm::hash_combine(
+Val.Symbol, 
reinterpret_cast(Val.Reference.Location.FileURI),
+Val.Reference.Location.Start.rep(), Val.Reference.Location.End.rep());
+  }
+  static bool isEqual(const Entry , const Entry ) {
+return 

[PATCH] D79945: [Sema] Comparison of pointers to complete and incomplete types

2020-05-18 Thread Benson Chu via Phabricator via cfe-commits
pestctrl updated this revision to Diff 264697.
pestctrl edited the summary of this revision.
pestctrl added a comment.

Rebased on top of master


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79945

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Sema/compare.c


Index: clang/test/Sema/compare.c
===
--- clang/test/Sema/compare.c
+++ clang/test/Sema/compare.c
@@ -405,3 +405,12 @@
   if (x == y) x = y; // no warning
   if (y == x) y = x; // no warning
 }
+
+int incomplete[]; // expected-warning {{tentative array definition assumed to 
have one element}}
+int complete[5];
+
+void test13() {
+  if ( < ) { // expected-error {{ordered comparison of 
complete and incomplete pointers}}
+return;
+  }
+}
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -11424,8 +11424,15 @@
 // C99 6.5.9p2 and C99 6.5.8p2
 if (Context.typesAreCompatible(LCanPointeeTy.getUnqualifiedType(),
RCanPointeeTy.getUnqualifiedType())) {
-  // Valid unless a relational comparison of function pointers
-  if (IsRelational && LCanPointeeTy->isFunctionType()) {
+  // Pointers both need to point to complete or incomplete types
+  if (LCanPointeeTy->isIncompleteType() !=
+  RCanPointeeTy->isIncompleteType()) {
+Diag(Loc,
+ diag::err_typecheck_comparison_of_complete_and_incomplete_types)
+<< LHSType << RHSType << LHS.get()->getSourceRange()
+<< RHS.get()->getSourceRange();
+  } else if (IsRelational && LCanPointeeTy->isFunctionType()) {
+// Valid unless a relational comparison of function pointers
 Diag(Loc, diag::ext_typecheck_ordered_comparison_of_function_pointers)
   << LHSType << RHSType << LHS.get()->getSourceRange()
   << RHS.get()->getSourceRange();
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -6434,6 +6434,8 @@
   "ordered comparison between pointer and zero (%0 and %1)">;
 def err_typecheck_three_way_comparison_of_pointer_and_zero : Error<
   "three-way comparison between pointer and zero">;
+def err_typecheck_comparison_of_complete_and_incomplete_types : Error<
+  "ordered comparison of complete and incomplete pointers (%0 and %1)">;
 def ext_typecheck_ordered_comparison_of_function_pointers : ExtWarn<
   "ordered comparison of function pointers (%0 and %1)">,
   InGroup>;


Index: clang/test/Sema/compare.c
===
--- clang/test/Sema/compare.c
+++ clang/test/Sema/compare.c
@@ -405,3 +405,12 @@
   if (x == y) x = y; // no warning
   if (y == x) y = x; // no warning
 }
+
+int incomplete[]; // expected-warning {{tentative array definition assumed to have one element}}
+int complete[5];
+
+void test13() {
+  if ( < ) { // expected-error {{ordered comparison of complete and incomplete pointers}}
+return;
+  }
+}
Index: clang/lib/Sema/SemaExpr.cpp
===
--- clang/lib/Sema/SemaExpr.cpp
+++ clang/lib/Sema/SemaExpr.cpp
@@ -11424,8 +11424,15 @@
 // C99 6.5.9p2 and C99 6.5.8p2
 if (Context.typesAreCompatible(LCanPointeeTy.getUnqualifiedType(),
RCanPointeeTy.getUnqualifiedType())) {
-  // Valid unless a relational comparison of function pointers
-  if (IsRelational && LCanPointeeTy->isFunctionType()) {
+  // Pointers both need to point to complete or incomplete types
+  if (LCanPointeeTy->isIncompleteType() !=
+  RCanPointeeTy->isIncompleteType()) {
+Diag(Loc,
+ diag::err_typecheck_comparison_of_complete_and_incomplete_types)
+<< LHSType << RHSType << LHS.get()->getSourceRange()
+<< RHS.get()->getSourceRange();
+  } else if (IsRelational && LCanPointeeTy->isFunctionType()) {
+// Valid unless a relational comparison of function pointers
 Diag(Loc, diag::ext_typecheck_ordered_comparison_of_function_pointers)
   << LHSType << RHSType << LHS.get()->getSourceRange()
   << RHS.get()->getSourceRange();
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -6434,6 +6434,8 @@
   "ordered comparison between pointer and zero (%0 and %1)">;
 def err_typecheck_three_way_comparison_of_pointer_and_zero : Error<
   "three-way comparison between pointer and zero">;
+def 

[PATCH] D79526: [CUDA][HIP] Workaround for resolving host device function against wrong-sided function

2020-05-18 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

e03394c6a6ff5832aa43259d4b8345f40ca6a22c 
 Still 
breaks some of the existing CUDA code (got failures in pytorch and Eigen). I'll 
revert the patch and will send you a reduced reproducer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79526



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


[PATCH] D79862: [clangd-remote] Replace YAML serialization with proper Protobuf messages

2020-05-18 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

Just more stuff about simplifying the tests :-(

This is really just about converting between a struct and a proto, if we have 
to add indexing-related fixtures to shared libraries something seems to have 
gone a bit off the rails.
In the worst case we could just create a few symbols with fields populated by 
hand, it's probably easier to see what parts of the code are being covered by 
the test...




Comment at: clang-tools-extra/clangd/unittests/TestTU.cpp:128
+  SymbolSlab::Builder Merger;
+  for (const auto  : MainCodeSymbols)
+Merger.insert(Sym);

can you structure the tests to avoid doing this (untested) merge?

Why do we need the example symbols split over multiple files at all?
If we need such symbols can we just construct them manually instead?



Comment at: clang-tools-extra/clangd/unittests/TestTU.h:73
   SymbolSlab headerSymbols() const;
+  RefSlab headerRefs() const;
+  // Returns all symbols from the header and main file.

please don't add these for a single test, we can do this inline in the test 
unless it becomes a common thing



Comment at: clang-tools-extra/clangd/unittests/remote/CMakeLists.txt:2
+set(LLVM_LINK_COMPONENTS
+  Support
+  )

Can we conditionally include these tests into the main ClangdTests, instead of 
setting up another set of targets?



Comment at: clang-tools-extra/clangd/unittests/remote/CMakeLists.txt:18
+
+  ../TestTU.cpp
+  ../TestFS.cpp

I don't think including the same source files in multiple targets is a great 
path to go down.



Comment at: clang-tools-extra/clangd/unittests/remote/MarshallingTests.cpp:20
+
+class RemoteMarshallingTest : public ::testing::Test {
+public:

Using inheritance to define test *cases* is a bit of a trap, and not 
particularly idiomatic.
Can we just write a function `indexSampleData()` that returns a `SlabTuple`, 
and call it from the tests?



Comment at: clang-tools-extra/clangd/unittests/remote/MarshallingTests.cpp:62
+  TestTU TU;
+  llvm::BumpPtrAllocator NewArena;
+};

similarly i'd consider just inlining the stringsaver/arena into the tests, 
seems easier to read



Comment at: clang-tools-extra/clangd/unittests/remote/MarshallingTests.cpp:66
+TEST_F(RemoteMarshallingTest, SymbolSerialization) {
+  for (auto  : symbols()) {
+const auto ProtobufMeessage = toProtobuf(Sym);

if you want to define the symbols indirectly like this, you probably also want 
to assert that there are more than 5 or something, to guard against the test 
fixture being broken


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79862



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


[PATCH] D79938: [clangd] Add a flag to preserve type for recovery expression.

2020-05-18 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/clangd/CodeComplete.cpp:1072
   ParseInput.Contents = std::string(Input.Contents);
+  // FIXME: setup the recoveryAST and recoveryASTType in ParseInput properly.
 

hokein wrote:
> unfortunately, we don't have the `ParseOptions` structure in code completion 
> code path, maybe we can add two flags in `SemaCompleteInput`.
I think we should just make the public interface to `codeComplete` take 
ParseInputs, it's mostly overlap anyway


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79938



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


[PATCH] D79743: [clang][asm goto][slh] Warn if asm goto + SLH

2020-05-18 Thread Zola Bridges via Phabricator via cfe-commits
zbrid marked 3 inline comments as done.
zbrid added a comment.

> Do you mean runtime crash? If so, I think error should be emit, so that 
> programmer can remove use of "asm goto" and recompile.

This would be a compile time crash. At some point the 
X86SpeculativeLoadHardening pass in the backend will notice asm goto is being 
used and give up. As far as I can tell it's hard to determine that asm goto was 
the root cause of that crash in the backend, so I want to emit it earlier in 
Clang. Does that make sense? Let me know if not :)

> It to me,  you can emit error somewhere in ParseAsmStatement when “goto” is 
> parsed.  Let me know if you have problem.

Thanks for the pointer! I'll send an update that emits at that point.

In D79743#2036814 , @jyu2 wrote:

> I don’t know what consequences is of using asm goto under SLH.
>
> In general, if asm-goto is not allowed, the diagnostic should be emitted 
> during the parser.  If asm-goto is not allowed under specified condition, the 
> diagnostic should be emitted during sema.  Diagnostic should not be emitted 
> in the lower(codegen) in general (exception may be for target related).


Ah okay. Asm goto isn't allowed with SLH in general, so sounds like this should 
be in the parser based on your comment here. Thanks for the explanation.

Thanks for the comments, everyone.




Comment at: clang/include/clang/Basic/DiagnosticCommonKinds.td:248-249
+  def warn_slh_does_not_support_gcc_asm_goto : Warning<
+"speculative load hardening does not support use of GCC asm goto. asm goto 
"
+"detected with SLH">, InGroup>;
 }

mattdr wrote:
> I think at the UI level this feature is just called "asm goto" with no "GCC". 
> See e.g. https://lists.llvm.org/pipermail/llvm-dev/2018-October/127239.html
> 
> Also, since this is a warning (vs. an error), we probably want to hint about 
> the consequences of continuing despite the warning.
> 
> My attempt:
> "Speculative load hardening may not fully protect functions with 'asm goto'"
> 
I believe the DiagGroup is required for all new warnings (see: 
https://github.com/llvm/llvm-project/blob/master/clang/test/Misc/warning-flags.c)
  and I didn't notice one that fit this particular flag well. In addition I saw 
that adding a diag group in this way was used in the other places (like the 
warning right before the one I added), so I think this is an okay addition. If 
we add other slh related flags, we could perhaps generalize the diagnostic 
group to cover all those flags at that point.

Good points wrt the error message. I'll update it not to mention gcc and to 
explain what will happen if they use asm goto with SLH.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79743



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


[PATCH] D79950: [clangd] Avoid wasteful data structures in RefSlab::Builder

2020-05-18 Thread Sam McCall via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
sammccall marked 2 inline comments as done.
Closed by commit rGd19265b31e65: [clangd] Avoid wasteful data structures in 
RefSlab::Builder (authored by sammccall).

Changed prior to commit:
  https://reviews.llvm.org/D79950?vs=264024=264719#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79950

Files:
  clang-tools-extra/clangd/index/Ref.cpp
  clang-tools-extra/clangd/index/Ref.h
  clang-tools-extra/clangd/index/SymbolLocation.cpp
  clang-tools-extra/clangd/index/SymbolLocation.h

Index: clang-tools-extra/clangd/index/SymbolLocation.h
===
--- clang-tools-extra/clangd/index/SymbolLocation.h
+++ clang-tools-extra/clangd/index/SymbolLocation.h
@@ -30,22 +30,23 @@
   // Position is encoded into 32 bits to save space.
   // If Line/Column overflow, the value will be their maximum value.
   struct Position {
-Position() : Line(0), Column(0) {}
+Position() : LineColumnPacked(0) {}
 void setLine(uint32_t Line);
-uint32_t line() const { return Line; }
+uint32_t line() const { return LineColumnPacked >> ColumnBits; }
 void setColumn(uint32_t Column);
-uint32_t column() const { return Column; }
+uint32_t column() const { return LineColumnPacked & MaxColumn; }
+uint32_t rep() const { return LineColumnPacked; }
 
 bool hasOverflow() const {
-  return Line >= MaxLine || Column >= MaxColumn;
+  return line() == MaxLine || column() == MaxColumn;
 }
 
-static constexpr uint32_t MaxLine = (1 << 20) - 1;
-static constexpr uint32_t MaxColumn = (1 << 12) - 1;
+static constexpr unsigned ColumnBits = 12;
+static constexpr uint32_t MaxLine = (1 << (32 - ColumnBits)) - 1;
+static constexpr uint32_t MaxColumn = (1 << ColumnBits) - 1;
 
   private:
-uint32_t Line : 20;   // 0-based
-uint32_t Column : 12; // 0-based
+uint32_t LineColumnPacked; // Top 20 bit line, bottom 12 bits column.
   };
 
   /// The symbol range, using half-open range [Start, End).
Index: clang-tools-extra/clangd/index/SymbolLocation.cpp
===
--- clang-tools-extra/clangd/index/SymbolLocation.cpp
+++ clang-tools-extra/clangd/index/SymbolLocation.cpp
@@ -15,18 +15,14 @@
 constexpr uint32_t SymbolLocation::Position::MaxColumn;
 
 void SymbolLocation::Position::setLine(uint32_t L) {
-  if (L > MaxLine) {
-Line = MaxLine;
-return;
-  }
-  Line = L;
+  if (L > MaxLine)
+L = MaxLine;
+  LineColumnPacked = (L << ColumnBits) | column();
 }
 void SymbolLocation::Position::setColumn(uint32_t Col) {
-  if (Col > MaxColumn) {
-Column = MaxColumn;
-return;
-  }
-  Column = Col;
+  if (Col > MaxColumn)
+Col = MaxColumn;
+  LineColumnPacked = (LineColumnPacked & ~MaxColumn) | Col;
 }
 
 llvm::raw_ostream <<(llvm::raw_ostream , const SymbolLocation ) {
Index: clang-tools-extra/clangd/index/Ref.h
===
--- clang-tools-extra/clangd/index/Ref.h
+++ clang-tools-extra/clangd/index/Ref.h
@@ -13,6 +13,8 @@
 #include "SymbolLocation.h"
 #include "clang/Index/IndexSymbol.h"
 #include "llvm/ADT/DenseMap.h"
+#include "llvm/ADT/Hashing.h"
+#include "llvm/Support/Allocator.h"
 #include "llvm/Support/StringSaver.h"
 #include "llvm/Support/raw_ostream.h"
 #include 
@@ -132,9 +134,17 @@
 RefSlab build() &&;
 
   private:
+// A ref we're storing with its symbol to consume with build().
+// All strings are interned, so DenseMapInfo can use pointer comparisons.
+struct Entry {
+  SymbolID Symbol;
+  Ref Reference;
+};
+friend struct llvm::DenseMapInfo;
+
 llvm::BumpPtrAllocator Arena;
 llvm::UniqueStringSaver UniqueStrings; // Contents on the arena.
-llvm::DenseMap> Refs;
+llvm::DenseSet Entries;
   };
 
 private:
@@ -151,4 +161,31 @@
 } // namespace clangd
 } // namespace clang
 
+namespace llvm {
+template <> struct DenseMapInfo {
+  using Entry = clang::clangd::RefSlab::Builder::Entry;
+  static inline Entry getEmptyKey() {
+static Entry E{clang::clangd::SymbolID(""), {}};
+return E;
+  }
+  static inline Entry getTombstoneKey() {
+static Entry E{clang::clangd::SymbolID("TOMBSTONE"), {}};
+return E;
+  }
+  static unsigned getHashValue(const Entry ) {
+return llvm::hash_combine(
+Val.Symbol, reinterpret_cast(Val.Reference.Location.FileURI),
+Val.Reference.Location.Start.rep(), Val.Reference.Location.End.rep());
+  }
+  static bool isEqual(const Entry , const Entry ) {
+return std::tie(LHS.Symbol, LHS.Reference.Location.FileURI,
+LHS.Reference.Kind) ==
+   std::tie(RHS.Symbol, RHS.Reference.Location.FileURI,
+RHS.Reference.Kind) &&
+   LHS.Reference.Location.Start == RHS.Reference.Location.Start 

[PATCH] D80025: [ASTMatcher] Correct memoization bug ignoring direction (descendants or ancestors)

2020-05-18 Thread Loïc Joly via Phabricator via cfe-commits
loic-joly-sonarsource added a comment.

In D80025#2041247 , @njames93 wrote:

> This needs rebasing against trunk


I'm doing it




Comment at: clang/lib/ASTMatchers/ASTMatchFinder.cpp:46-49
+enum class MatchDirection {
+  Ancestors,
+  Descendants
+};

klimek wrote:
> Nice find! Why don't we need more states though?
> 1. wouldn't hasParent() followed by a hasAncestor() also trigger the 
> memoization? (if so, we'd need transitive / non-transitive)
> 2. can we trigger a directional match and a non-directional (non-traversal, 
> for example, explicit) match in the same memoization scope?
1. Yes, I'm going to add it
2. Sorry, I did not understand what you mean...



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

https://reviews.llvm.org/D80025



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


[PATCH] D80160: [Tooling] Drop leading/trailing whitespace from compile_flags.txt lines

2020-05-18 Thread Sam McCall via Phabricator via cfe-commits
sammccall created this revision.
sammccall added a reviewer: kadircet.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

These files tend to be hand-authored, and people get very confused.
I can't think of any reason that such whitespace would be intended.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80160

Files:
  clang/lib/Tooling/CompilationDatabase.cpp
  clang/test/Tooling/fixed-database.cpp


Index: clang/test/Tooling/fixed-database.cpp
===
--- clang/test/Tooling/fixed-database.cpp
+++ clang/test/Tooling/fixed-database.cpp
@@ -3,9 +3,10 @@
 // RUN: cp "%s" "%t/Src/test.cpp"
 // RUN: mkdir -p %t/Include
 // RUN: cp "%S/Inputs/fixed-header.h" "%t/Include/"
+// RUN: echo '# this is a comment' >> %t/compile_flags.txt
 // -I flag is relative to %t (where compile_flags is), not Src/.
 // RUN: echo '-IInclude/' >> %t/compile_flags.txt
-// RUN: echo "-Dklazz=class" >> %t/compile_flags.txt
+// RUN: echo "  -Dklazz=class   " >> %t/compile_flags.txt
 // RUN: echo '-std=c++11' >> %t/compile_flags.txt
 // RUN: clang-check "%t/Src/test.cpp" 2>&1
 // RUN: echo > %t/compile_flags.txt
Index: clang/lib/Tooling/CompilationDatabase.cpp
===
--- clang/lib/Tooling/CompilationDatabase.cpp
+++ clang/lib/Tooling/CompilationDatabase.cpp
@@ -368,8 +368,14 @@
 ErrorMsg = "Error while opening fixed database: " + Result.message();
 return nullptr;
   }
-  std::vector Args{llvm::line_iterator(**File),
-llvm::line_iterator()};
+  std::vector Args;
+  for (llvm::StringRef Line :
+   llvm::make_range(llvm::line_iterator(**File), llvm::line_iterator())) {
+// Stray whitespace is almost certainly unintended.
+Line = Line.trim();
+if (!Line.empty())
+  Args.push_back(Line.str());
+  }
   return std::make_unique(
   llvm::sys::path::parent_path(Path), std::move(Args));
 }


Index: clang/test/Tooling/fixed-database.cpp
===
--- clang/test/Tooling/fixed-database.cpp
+++ clang/test/Tooling/fixed-database.cpp
@@ -3,9 +3,10 @@
 // RUN: cp "%s" "%t/Src/test.cpp"
 // RUN: mkdir -p %t/Include
 // RUN: cp "%S/Inputs/fixed-header.h" "%t/Include/"
+// RUN: echo '# this is a comment' >> %t/compile_flags.txt
 // -I flag is relative to %t (where compile_flags is), not Src/.
 // RUN: echo '-IInclude/' >> %t/compile_flags.txt
-// RUN: echo "-Dklazz=class" >> %t/compile_flags.txt
+// RUN: echo "  -Dklazz=class   " >> %t/compile_flags.txt
 // RUN: echo '-std=c++11' >> %t/compile_flags.txt
 // RUN: clang-check "%t/Src/test.cpp" 2>&1
 // RUN: echo > %t/compile_flags.txt
Index: clang/lib/Tooling/CompilationDatabase.cpp
===
--- clang/lib/Tooling/CompilationDatabase.cpp
+++ clang/lib/Tooling/CompilationDatabase.cpp
@@ -368,8 +368,14 @@
 ErrorMsg = "Error while opening fixed database: " + Result.message();
 return nullptr;
   }
-  std::vector Args{llvm::line_iterator(**File),
-llvm::line_iterator()};
+  std::vector Args;
+  for (llvm::StringRef Line :
+   llvm::make_range(llvm::line_iterator(**File), llvm::line_iterator())) {
+// Stray whitespace is almost certainly unintended.
+Line = Line.trim();
+if (!Line.empty())
+  Args.push_back(Line.str());
+  }
   return std::make_unique(
   llvm::sys::path::parent_path(Path), std::move(Args));
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D74668: [Clang][BPF] implement __builtin_btf_type_id() builtin function

2020-05-18 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

(mentioned also on the LLVM side of this D74572 
)

If this is in the interests of retaining certain types in the emitted debug 
info - it seems quite complicated compared to what I'd hope for. Would it be 
sufficient to support __attribute__((used)) on a type and have that force the 
type to be emitted into DWARF (this could be implemented using DICompileUNit's 
"retainedTypes" list (& is similar to what LLVM does for references to enum 
constants where the enum isn't otherwise used as a type in a function 
signature, variable, etc - attaching them to the DICompileUnit's "enums" 
list)). That seems like a more general purpose and tidier way that 
adding/removing things, having extra transformation passes, etc. (& even if 
__attribute__((used)) isn't suitable for your needs - at least, hopefully, you 
could still use DICompileUnit's retainedTypes list to save your types detected 
through some other means, and not need the backend pass to strip out these 
extra intrinsic calls, etc)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74668



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


[PATCH] D80144: [clang-format] @lefticus just taught the world how to use [[unlikely]] but we forgot to teach clang-format

2020-05-18 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay updated this revision to Diff 264717.
MyDeveloperDay added a comment.

rebase


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

https://reviews.llvm.org/D80144

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


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -16306,6 +16306,36 @@
  Style));
 }
 
+TEST_F(FormatTest, LikelyUnlikely) {
+  FormatStyle Style = getLLVMStyle();
+
+  verifyFormat("if (argc > 5) [[unlikely]] {\n"
+   "  return 29;\n"
+   "}",
+   Style);
+
+  verifyFormat("if (argc > 5) [[likely]] {\n"
+   "  return 29;\n"
+   "}",
+   Style);
+
+  verifyFormat("if (argc > 5) [[unlikely]] {\n"
+   "  return 29;\n"
+   "} else [[likely]] {\n"
+   "  return 42;\n"
+   "}\n",
+   Style);
+
+  verifyFormat("if (argc > 5) [[unlikely]] {\n"
+   "  return 29;\n"
+   "} else if (argc > 10) [[likely]] {\n"
+   "  return 99;\n"
+   "} else {\n"
+   "  return 42;\n"
+   "}\n",
+   Style);
+}
+
 } // namespace
 } // namespace format
 } // namespace clang
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -1956,6 +1956,9 @@
 nextToken();
   if (FormatTok->Tok.is(tok::l_paren))
 parseParens();
+  // handle [[likely]] / [[unlikely]]
+  if (FormatTok->is(tok::l_square))
+parseSquare();
   bool NeedsUnwrappedLine = false;
   if (FormatTok->Tok.is(tok::l_brace)) {
 CompoundStatementIndenter Indenter(this, Style, Line->Level);
@@ -1972,6 +1975,9 @@
   }
   if (FormatTok->Tok.is(tok::kw_else)) {
 nextToken();
+// handle [[likely]] / [[unlikely]]
+if (FormatTok->is(tok::l_square))
+  parseSquare();
 if (FormatTok->Tok.is(tok::l_brace)) {
   CompoundStatementIndenter Indenter(this, Style, Line->Level);
   parseBlock(/*MustBeDeclaration=*/false);


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -16306,6 +16306,36 @@
  Style));
 }
 
+TEST_F(FormatTest, LikelyUnlikely) {
+  FormatStyle Style = getLLVMStyle();
+
+  verifyFormat("if (argc > 5) [[unlikely]] {\n"
+   "  return 29;\n"
+   "}",
+   Style);
+
+  verifyFormat("if (argc > 5) [[likely]] {\n"
+   "  return 29;\n"
+   "}",
+   Style);
+
+  verifyFormat("if (argc > 5) [[unlikely]] {\n"
+   "  return 29;\n"
+   "} else [[likely]] {\n"
+   "  return 42;\n"
+   "}\n",
+   Style);
+
+  verifyFormat("if (argc > 5) [[unlikely]] {\n"
+   "  return 29;\n"
+   "} else if (argc > 10) [[likely]] {\n"
+   "  return 99;\n"
+   "} else {\n"
+   "  return 42;\n"
+   "}\n",
+   Style);
+}
+
 } // namespace
 } // namespace format
 } // namespace clang
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -1956,6 +1956,9 @@
 nextToken();
   if (FormatTok->Tok.is(tok::l_paren))
 parseParens();
+  // handle [[likely]] / [[unlikely]]
+  if (FormatTok->is(tok::l_square))
+parseSquare();
   bool NeedsUnwrappedLine = false;
   if (FormatTok->Tok.is(tok::l_brace)) {
 CompoundStatementIndenter Indenter(this, Style, Line->Level);
@@ -1972,6 +1975,9 @@
   }
   if (FormatTok->Tok.is(tok::kw_else)) {
 nextToken();
+// handle [[likely]] / [[unlikely]]
+if (FormatTok->is(tok::l_square))
+  parseSquare();
 if (FormatTok->Tok.is(tok::l_brace)) {
   CompoundStatementIndenter Indenter(this, Style, Line->Level);
   parseBlock(/*MustBeDeclaration=*/false);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] e2cc12e - [SveEmitter] Builtins for SVE matrix multiply `mmla`.

2020-05-18 Thread Francesco Petrogalli via cfe-commits

Author: Francesco Petrogalli
Date: 2020-05-18T22:02:19Z
New Revision: e2cc12e412821b05b4c31b74068976a90f167f1e

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

LOG: [SveEmitter] Builtins for SVE matrix multiply `mmla`.

Summary:
Guarded by __ARM_FEATURE_SVE_MATMUL_INT8:

* svmmla_u32
* svmmla_s32
* svusmmla_s32

Guarded by __ARM_FEATURE_SVE_MATMUL_FP32:

* svmmla_f32

Guarded by __ARM_FEATURE_SVE_MATMUL_FP64:

* svmmla_f64

Reviewers: sdesmalen, kmclaughlin, efriedma, rengolin

Subscribers: tschuett, kristof.beyls, cfe-commits

Tags: #clang

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

Added: 
clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_matmul_fp32.c
clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_matmul_fp64.c
clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_mmla.c

Modified: 
clang/include/clang/Basic/arm_sve.td
clang/utils/TableGen/SveEmitter.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/arm_sve.td 
b/clang/include/clang/Basic/arm_sve.td
index e8e05902102a..4b77b0575637 100644
--- a/clang/include/clang/Basic/arm_sve.td
+++ b/clang/include/clang/Basic/arm_sve.td
@@ -69,6 +69,7 @@
 // R: scalar of 1/2 width element type (splat to vector type)
 // r: scalar of 1/4 width element type (splat to vector type)
 // e: 1/2 width unsigned elements, 2x element count
+// b: 1/4 width unsigned elements, 4x element count
 // h: 1/2 width elements, 2x element count
 // q: 1/4 width elements, 4x element count
 // o: 4x width elements, 1/4 element count
@@ -1235,6 +1236,21 @@ def SVQINCP_N_S64 : SInst<"svqincp[_n_s64]_{d}", "llP", 
"PcPsPiPl", MergeNone, "
 def SVQINCP_N_U32 : SInst<"svqincp[_n_u32]_{d}", "mmP", "PcPsPiPl", MergeNone, 
"aarch64_sve_uqincp_n32">;
 def SVQINCP_N_U64 : SInst<"svqincp[_n_u64]_{d}", "nnP", "PcPsPiPl", MergeNone, 
"aarch64_sve_uqincp_n64">;
 
+let ArchGuard = "defined(__ARM_FEATURE_SVE_MATMUL_INT8)" in {
+def SVMLLA_S32   : SInst<"svmmla[_s32]",   "ddqq","i",  MergeNone, 
"aarch64_sve_smmla">;
+def SVMLLA_U32   : SInst<"svmmla[_u32]",   "ddqq","Ui", MergeNone, 
"aarch64_sve_ummla">;
+def SVUSMLLA_S32 : SInst<"svusmmla[_s32]", "ddbq","i",  MergeNone, 
"aarch64_sve_usmmla">;
+}
+
+let ArchGuard = "defined(__ARM_FEATURE_SVE_MATMUL_FP32)" in {
+def SVMLLA_F32 : SInst<"svmmla[_f32]", "","f", MergeNone, 
"aarch64_sve_fmmla">;
+}
+
+let ArchGuard = "defined(__ARM_FEATURE_SVE_MATMUL_FP64)" in {
+def SVMLLA_F64 : SInst<"svmmla[_f64]", "","d", MergeNone, 
"aarch64_sve_fmmla">;
+}
+
+
 

 // SVE2 WhileGE/GT
 let ArchGuard = "defined(__ARM_FEATURE_SVE2)" in {

diff  --git a/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_matmul_fp32.c 
b/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_matmul_fp32.c
new file mode 100644
index ..422115c7aba5
--- /dev/null
+++ b/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_matmul_fp32.c
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -D__ARM_FEATURE_SVE_MATMUL_FP32 -triple 
aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns 
-S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -D__ARM_FEATURE_SVE_MATMUL_FP32 
-DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve 
-fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | 
FileCheck %s
+
+#include 
+
+#ifdef SVE_OVERLOADED_FORMS
+// A simple used,unused... macro, long enough to represent any SVE builtin.
+#define SVE_ACLE_FUNC(A1, A2_UNUSED, A3, A4_UNUSED) A1##A3
+#else
+#define SVE_ACLE_FUNC(A1, A2, A3, A4) A1##A2##A3##A4
+#endif
+
+svfloat32_t test_svmmla_f32(svfloat32_t x, svfloat32_t y, svfloat32_t z) {
+  // CHECK-LABEL: test_svmmla_f32
+  // CHECK: %[[RET:.*]] = call  
@llvm.aarch64.sve.fmmla.nxv4f32( %x,  
%y,  %z)
+  // CHECK: ret  %[[RET]]
+  return SVE_ACLE_FUNC(svmmla,_f32,,)(x, y, z);
+}

diff  --git a/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_matmul_fp64.c 
b/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_matmul_fp64.c
new file mode 100644
index ..e918d271e53b
--- /dev/null
+++ b/clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_matmul_fp64.c
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -D__ARM_FEATURE_SVE_MATMUL_FP64 -triple 
aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns 
-S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -D__ARM_FEATURE_SVE_MATMUL_FP64 
-DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve 
-fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | 
FileCheck %s
+
+#include 
+
+#ifdef SVE_OVERLOADED_FORMS
+// A simple used,unused... macro, 

[PATCH] D79526: [CUDA][HIP] Workaround for resolving host device function against wrong-sided function

2020-05-18 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

Reduced test case:

  struct a {
__attribute__((device)) a(short);
__attribute__((device)) operator unsigned() const;
__attribute__((device)) operator int() const;
  };
  struct b {
a d;
  };
  void f(b g) { b e = g; }

Failure:

  $ bin/clang++ -x cuda aten.cc -fsyntax-only  
--cuda-path=$HOME/local/cuda-10.1 --cuda-device-only --cuda-gpu-arch=sm_60 
-stdlib=libc++ -std=c++17 -ferror-limit=1
  
  aten.cc:6:8: error: conversion from 'const a' to 'short' is ambiguous
  struct b {
 ^
  aten.cc:9:21: note: in implicit copy constructor for 'b' first required here
  void f(b g) { b e = g; }
  ^
  aten.cc:3:27: note: candidate function
__attribute__((device)) operator unsigned() const;
^
  aten.cc:4:27: note: candidate function
__attribute__((device)) operator int() const;
^
  aten.cc:2:34: note: passing argument to parameter here
__attribute__((device)) a(short);
   ^
  1 error generated when compiling for sm_60.

The same code compiles fine in C++ and I would expect it to work on device side 
the same way.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79526



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


[PATCH] D79121: Add nomerge function attribute to clang

2020-05-18 Thread Reid Kleckner via Phabricator via cfe-commits
rnk accepted this revision.
rnk added a comment.
This revision is now accepted and ready to land.

I think this looks good and @zequanwu has addressed the concerns of other 
reviewers. Please wait until Wednesday before pushing in case they raise other 
concerns.




Comment at: clang/lib/Sema/SemaStmtAttr.cpp:175
+namespace {
+class CallExprFinder : public ConstEvaluatedExprVisitor {
+  bool FoundCallExpr = false;

I guess I'm a little concerned that we have to break out CRTP and walk the 
whole sub statement to make this warning work, but we do that kind of stuff 
everywhere I guess. :( I wish we had a cheaper way to do this.


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

https://reviews.llvm.org/D79121



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


[PATCH] D80153: [AST] Mangle LambdaContextDecl for top level decl

2020-05-18 Thread Zequan Wu via Phabricator via cfe-commits
zequanwu created this revision.
zequanwu added reviewers: CaseyCarter, rnk.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Bug filed here: https://bugs.llvm.org/show_bug.cgi?id=45213

To resolve it, we could mangle the `LambdaContextDecl` if it is top level decl.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80153

Files:
  clang/lib/AST/MicrosoftMangle.cpp


Index: clang/lib/AST/MicrosoftMangle.cpp
===
--- clang/lib/AST/MicrosoftMangle.cpp
+++ clang/lib/AST/MicrosoftMangle.cpp
@@ -948,11 +948,13 @@
   mangleSourceName(Name);
 
   // If the context of a closure type is an initializer for a class
-  // member (static or nonstatic), it is encoded in a qualified name.
+  // member (static or nonstatic) or is a top level decl, it is encoded
+  // in a qualified name.
   if (LambdaManglingNumber && LambdaContextDecl) {
 if ((isa(LambdaContextDecl) ||
  isa(LambdaContextDecl)) &&
-LambdaContextDecl->getDeclContext()->isRecord()) {
+(LambdaContextDecl->getDeclContext()->isRecord() ||
+ LambdaContextDecl->getDeclContext()->isTranslationUnit())) {
   mangleUnqualifiedName(cast(LambdaContextDecl));
 }
   }


Index: clang/lib/AST/MicrosoftMangle.cpp
===
--- clang/lib/AST/MicrosoftMangle.cpp
+++ clang/lib/AST/MicrosoftMangle.cpp
@@ -948,11 +948,13 @@
   mangleSourceName(Name);
 
   // If the context of a closure type is an initializer for a class
-  // member (static or nonstatic), it is encoded in a qualified name.
+  // member (static or nonstatic) or is a top level decl, it is encoded
+  // in a qualified name.
   if (LambdaManglingNumber && LambdaContextDecl) {
 if ((isa(LambdaContextDecl) ||
  isa(LambdaContextDecl)) &&
-LambdaContextDecl->getDeclContext()->isRecord()) {
+(LambdaContextDecl->getDeclContext()->isRecord() ||
+ LambdaContextDecl->getDeclContext()->isTranslationUnit())) {
   mangleUnqualifiedName(cast(LambdaContextDecl));
 }
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D80154: [AST] Fix recovery-AST crash: dependent overloaded call exprs are now possible.

2020-05-18 Thread Sam McCall via Phabricator via cfe-commits
sammccall created this revision.
sammccall added a reviewer: hokein.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
sammccall added a comment.

(Haha, I tried to send this 5 hours ago and found it waiting for me to confirm 
that clang-format could add a single space...)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80154

Files:
  clang/lib/AST/StmtProfile.cpp
  clang/test/AST/ast-dump-recovery.cpp


Index: clang/test/AST/ast-dump-recovery.cpp
===
--- clang/test/AST/ast-dump-recovery.cpp
+++ clang/test/AST/ast-dump-recovery.cpp
@@ -177,3 +177,11 @@
   // CHECK: `-VarDecl {{.*}} invalid unresolved_typo 'auto'
   auto unresolved_typo = gned.*[] {};
 }
+
+// CHECK:  `-TypeAliasDecl {{.*}} Escape 'decltype([] {
+// CHECK-NEXT:   return (undef);
+// CHECK-NEXT: }())'
+// CHECK-NEXT:   `-DecltypeType {{.*}} 'decltype([] {
+// CHECK-NEXT: return (undef);
+// CHECK-NEXT:   }())' dependent
+using Escape = decltype([] { return undef(); }());
Index: clang/lib/AST/StmtProfile.cpp
===
--- clang/lib/AST/StmtProfile.cpp
+++ clang/lib/AST/StmtProfile.cpp
@@ -1446,7 +1446,6 @@
   case OO_Array_New:
   case OO_Array_Delete:
   case OO_Arrow:
-  case OO_Call:
   case OO_Conditional:
   case NUM_OVERLOADED_OPERATORS:
 llvm_unreachable("Invalid operator call kind");
@@ -1620,6 +1619,9 @@
   case OO_Subscript:
 return Stmt::ArraySubscriptExprClass;
 
+  case OO_Call:
+return Stmt::CallExprClass;
+
   case OO_Coawait:
 UnaryOp = UO_Coawait;
 return Stmt::UnaryOperatorClass;
@@ -1660,7 +1662,7 @@
  SC == Stmt::CompoundAssignOperatorClass)
   ID.AddInteger(BinaryOp);
 else
-  assert(SC == Stmt::ArraySubscriptExprClass);
+  assert(SC == Stmt::ArraySubscriptExprClass || SC == Stmt::CallExprClass);
 
 return;
   }


Index: clang/test/AST/ast-dump-recovery.cpp
===
--- clang/test/AST/ast-dump-recovery.cpp
+++ clang/test/AST/ast-dump-recovery.cpp
@@ -177,3 +177,11 @@
   // CHECK: `-VarDecl {{.*}} invalid unresolved_typo 'auto'
   auto unresolved_typo = gned.*[] {};
 }
+
+// CHECK:  `-TypeAliasDecl {{.*}} Escape 'decltype([] {
+// CHECK-NEXT:   return (undef);
+// CHECK-NEXT: }())'
+// CHECK-NEXT:   `-DecltypeType {{.*}} 'decltype([] {
+// CHECK-NEXT: return (undef);
+// CHECK-NEXT:   }())' dependent
+using Escape = decltype([] { return undef(); }());
Index: clang/lib/AST/StmtProfile.cpp
===
--- clang/lib/AST/StmtProfile.cpp
+++ clang/lib/AST/StmtProfile.cpp
@@ -1446,7 +1446,6 @@
   case OO_Array_New:
   case OO_Array_Delete:
   case OO_Arrow:
-  case OO_Call:
   case OO_Conditional:
   case NUM_OVERLOADED_OPERATORS:
 llvm_unreachable("Invalid operator call kind");
@@ -1620,6 +1619,9 @@
   case OO_Subscript:
 return Stmt::ArraySubscriptExprClass;
 
+  case OO_Call:
+return Stmt::CallExprClass;
+
   case OO_Coawait:
 UnaryOp = UO_Coawait;
 return Stmt::UnaryOperatorClass;
@@ -1660,7 +1662,7 @@
  SC == Stmt::CompoundAssignOperatorClass)
   ID.AddInteger(BinaryOp);
 else
-  assert(SC == Stmt::ArraySubscriptExprClass);
+  assert(SC == Stmt::ArraySubscriptExprClass || SC == Stmt::CallExprClass);
 
 return;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D80055: Diagnose union tail padding

2020-05-18 Thread JF Bastien via Phabricator via cfe-commits
jfb marked an inline comment as done.
jfb added inline comments.



Comment at: clang/test/CodeGen/union-tail-padding.c:28-36
+union Front {
+  int i;
+  long long ll;
+};
+
+union Front front1;
+union Front front2 = {};// expected-warning {{Initializing union 
'Front' field 'i' only initializes the first 4 of 8 bytes, leaving the 
remaining 4 bytes undefined}}

dexonsmith wrote:
> jfb wrote:
> > dexonsmith wrote:
> > > Are these warnings actionable?  What should users do when they see this 
> > > warning?
> > Good point!
> > 
> > I was thinking about this, and was wondering if I should add a fixit which 
> > suggests using the first wider member of the union. The problem is to offer 
> > the same object representation... that's tricky on its own (there isn't 
> > always an exact match), and then we have to deal with type punning (in C++, 
> > not in C).
> > 
> > So I'd love ideas, because I'm not sure what to do. That being said, I 
> > wrote this partly because D68115 was surprising to folks, and partly 
> > because developers would like to opt-in to this diagnostic to find places 
> > where initialization isn't doing what they think.
> > 
> > Maybe instead we should suggest to leave uninitialized, and use an 
> > assignment, or `memset`?
> > Maybe instead we should suggest to leave uninitialized, and use an 
> > assignment, or `memset`?
> 
> It's not clear to me that those are better.  For example, `memset` doesn't 
> seem right for non-PODs in C++.  I'm not sure what to suggest though.
I'd argue that non-PODs in unions don't seem right either ;-)
It would be easy to diagnose non-trivially-copyable types differently in this 
circumstance.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80055



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


[PATCH] D72531: Set traversal explicitly where needed in tests

2020-05-18 Thread Stephen Kelly via Phabricator via cfe-commits
steveire marked an inline comment as done.
steveire added inline comments.



Comment at: clang/unittests/Tooling/StencilTest.cpp:63
   ASTContext  = AstUnit->getASTContext();
-  auto Matches = ast_matchers::match(wrapMatcher(Matcher), Context);
+  auto Matches = ast_matchers::match(
+  traverse(ast_type_traits::TK_AsIs, wrapMatcher(Matcher)), Context);

aaron.ballman wrote:
> steveire wrote:
> > aaron.ballman wrote:
> > > Was this change made because you didn't want to accept the traversal mode 
> > > as a parameter to `matchStmt` and force each caller to decide which mode 
> > > they use? Or is there some other reason why this change was needed?
> > Yes, the test currently expects `AsIs`. If someone wanted to change that in 
> > the future, that is an issue for future work.
> You say "the test" as though there's only one. There are numerous tests which 
> use `matchStmt`. Do *all* of the tests require `AsIs`? (I think that's an 
> example of what's causing some of the confusion @shafik and I had and I'm 
> trying to ensure his question gets answered and that I'm fully understanding 
> your changes.) From spot-checking, it looks like there are tests using 
> `matchStmt` that don't need `AsIs` traversal and that this sort of cleanup 
> work could happen in the future, but for now you're going with the easiest 
> approach instead of expanding the test coverage for ignoring implicit nodes; 
> is that correct?
I said "the" test because there is one `StencilTest` class inside one 
`StencilTest.cpp`. Perhaps not a word you would use, but that's not something 
to get stuck on hopefully.

Yes, it is possible that someone could make `matchStmt` take an explicit 
`TraversalKind`, but I didn't see the need to do that in this patch. This patch 
maintains the status quo as much as possible while also making it possible to 
change the default.





Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72531



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


[PATCH] D79950: [clangd] Avoid wasteful data structures in RefSlab::Builder

2020-05-18 Thread Sam McCall via Phabricator via cfe-commits
sammccall marked 4 inline comments as done.
sammccall added inline comments.



Comment at: clang-tools-extra/clangd/index/Ref.cpp:11
+#include "llvm/ADT/STLExtras.h"
+#include "llvm/Support/Allocator.h"
+#include "llvm/Support/StringSaver.h"

kbobyrev wrote:
> This defines `BumpPtrAllocator`, right? I think it should be included in 
> `clang-tools-extra/clangd/index/Ref.h`, not here if the intent is to 
> explicitly include used headers. Same for `StringSaver.h`, this source file 
> does not use any additional variables of these types.
Yup, that's right, thanks.
(An intermediate version of the code used the overloaded new from allocator.h)



Comment at: clang-tools-extra/clangd/index/Ref.h:140
+  SymbolID Symbol;
+  Ref R;
+};

kbobyrev wrote:
> nit: I know you like the short names, but with `R` I had to get back to 
> `Entry` definition each time I saw it (I was thinking "wait, `R`? is there an 
> `L` somewhere here?". Maybe it's just me, but one-letter fields seem scary. 
> Maybe `Reference`?
Oops, I agree but forgot to do this, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79950



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


[PATCH] D80148: [OPENMP50]Add initial support for 'affinity' clause.

2020-05-18 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert accepted this revision.
jdoerfert added a comment.
This revision is now accepted and ready to land.

LGTM with minor comments.




Comment at: clang/lib/Parse/ParseOpenMP.cpp:3458
+   EnterScope(Scope::OpenMPDirectiveScope | Scope::DeclScope),
+   ParseOpenMPIteratorsExpr()));
 Tail = Actions.ActOnFinishFullExpr(Tail.get(), T.getOpenLocation(),

Please make this a conditional. Having a 5 line expression with ternary and 
comma operator is hard to read.



Comment at: clang/lib/Sema/SemaOpenMP.cpp:18836
+}
+Vars.push_back(RefExpr->IgnoreParenImpCasts());
+  }

I you can, reuse SimpleExpr here and above.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80148



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


[PATCH] D79639: [SveEmitter] Builtins for SVE matrix multiply `mmla`.

2020-05-18 Thread Francesco Petrogalli via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe2cc12e41282: [SveEmitter] Builtins for SVE matrix multiply 
`mmla`. (authored by fpetrogalli).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79639

Files:
  clang/include/clang/Basic/arm_sve.td
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_matmul_fp32.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_matmul_fp64.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_mmla.c
  clang/utils/TableGen/SveEmitter.cpp

Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -513,6 +513,11 @@
   case 'q':
 ElementBitwidth /= 4;
 break;
+  case 'b':
+Signed = false;
+Float = false;
+ElementBitwidth /= 4;
+break;
   case 'o':
 ElementBitwidth *= 4;
 break;
Index: clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_mmla.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_mmla.c
@@ -0,0 +1,32 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -D__ARM_FEATURE_SVE_MATMUL_INT8 -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -D__ARM_FEATURE_SVE_MATMUL_INT8 -DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+
+#include 
+
+#ifdef SVE_OVERLOADED_FORMS
+// A simple used,unused... macro, long enough to represent any SVE builtin.
+#define SVE_ACLE_FUNC(A1, A2_UNUSED, A3, A4_UNUSED) A1##A3
+#else
+#define SVE_ACLE_FUNC(A1, A2, A3, A4) A1##A2##A3##A4
+#endif
+
+svint32_t test_svmmla_s32(svint32_t x, svint8_t y, svint8_t z) {
+  // CHECK-LABEL: test_svmmla_s32
+  // CHECK: %[[RET:.*]] = call  @llvm.aarch64.sve.smmla.nxv4i32( %x,  %y,  %z)
+  // CHECK: ret  %[[RET]]
+  return SVE_ACLE_FUNC(svmmla,_s32,,)(x, y, z);
+}
+
+svuint32_t test_svmmla_u32(svuint32_t x, svuint8_t y, svuint8_t z) {
+  // CHECK-LABEL: test_svmmla_u32
+  // CHECK: %[[RET:.*]] = call  @llvm.aarch64.sve.ummla.nxv4i32( %x,  %y,  %z)
+  // CHECK: ret  %[[RET]]
+  return SVE_ACLE_FUNC(svmmla,_u32,,)(x, y, z);
+}
+
+svint32_t test_svusmmla_s32(svint32_t x, svuint8_t y, svint8_t z) {
+  // CHECK-LABEL: test_svusmmla_s32
+  // CHECK: %[[RET:.*]] = call  @llvm.aarch64.sve.usmmla.nxv4i32( %x,  %y,  %z)
+  // CHECK: ret  %[[RET]]
+  return SVE_ACLE_FUNC(svusmmla,_s32,,)(x, y, z);
+}
Index: clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_matmul_fp64.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_matmul_fp64.c
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -D__ARM_FEATURE_SVE_MATMUL_FP64 -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -D__ARM_FEATURE_SVE_MATMUL_FP64 -DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+
+#include 
+
+#ifdef SVE_OVERLOADED_FORMS
+// A simple used,unused... macro, long enough to represent any SVE builtin.
+#define SVE_ACLE_FUNC(A1, A2_UNUSED, A3, A4_UNUSED) A1##A3
+#else
+#define SVE_ACLE_FUNC(A1, A2, A3, A4) A1##A2##A3##A4
+#endif
+
+svfloat64_t test_svmmla_f64(svfloat64_t x, svfloat64_t y, svfloat64_t z) {
+  // CHECK-LABEL: test_svmmla_f64
+  // CHECK: %[[RET:.*]] = call  @llvm.aarch64.sve.fmmla.nxv2f64( %x,  %y,  %z)
+  // CHECK: ret  %[[RET]]
+  return SVE_ACLE_FUNC(svmmla,_f64,,)(x, y, z);
+}
Index: clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_matmul_fp32.c
===
--- /dev/null
+++ clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_matmul_fp32.c
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -D__ARM_FEATURE_SVE_MATMUL_FP32 -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -D__ARM_FEATURE_SVE -D__ARM_FEATURE_SVE_MATMUL_FP32 -DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+
+#include 
+
+#ifdef SVE_OVERLOADED_FORMS
+// A simple used,unused... macro, long enough to represent any SVE builtin.
+#define SVE_ACLE_FUNC(A1, A2_UNUSED, A3, A4_UNUSED) A1##A3
+#else
+#define SVE_ACLE_FUNC(A1, A2, A3, A4) A1##A2##A3##A4
+#endif
+
+svfloat32_t test_svmmla_f32(svfloat32_t x, svfloat32_t y, svfloat32_t z) {
+  // CHECK-LABEL: 

[PATCH] D80041: [clang-format] [PR45198] deletes whitespace inside of a noexcept specifier

2020-05-18 Thread Jake Merdich via Phabricator via cfe-commits
JakeMerdichAMD added a comment.

I mainly have concerns with the search for noexcept being too brittle and not 
looking far enough back. Implementing that may have performance implications 
though, so I have no issue ignoring that problem if it's proven sufficiently 
rare.

Also: should this do the same thing for throw()? It has pretty much the same 
constraints/context and would be trivial to add, although it's deprecated 
and/or removed in recent C++ versions. I'm not particularly inclined to 
implement that, but the question ought to be raised since it theoretically has 
the same problem.




Comment at: clang/lib/Format/TokenAnnotator.cpp:1933
+if (PrevPrevToken) {
+  const FormatToken *PrevPrevPrevToken =
+  PrevPrevToken->getPreviousNonComment();

Doesn't this not handle nested templates? For example, 
`noexcept(Foo>::value && Baz)` would not work here. Ditto on expressions 
like `Foo`.

I'm having trouble thinking of a clean generic solution, but the most robust 
thing I can think of is to search the current line for the previous opening 
parens and check if noexcept is before it (if they use multiple sets of parens, 
the other heuristics seem to cover it). 


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

https://reviews.llvm.org/D80041



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


[PATCH] D72959: Relative VTables ABI on Fuchsia

2020-05-18 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan added inline comments.



Comment at: clang/lib/CodeGen/CGVTables.cpp:646
+
+// Take offset from stub to the vtable component.
+llvm::Function *HiddenFunc = M.getFunction(StubName);

rjmccall wrote:
> That's not what this block is doing.
> 
> I think it would make sense to build this stub in a helper function.
> 
> Can you just avoid making the stub entirely if the function is known to be 
> defined in this translation unit (which will include all the internal-linkage 
> cases, but also things like `hidden linkonce_odr`)?
Done and added a test for it. Was planning to add this later as a followup but 
it turned out to be pretty simple to implement.



Comment at: clang/lib/CodeGen/CGVTables.cpp:895
+size_t thisIndex = layout.getVTableOffset(VTableIdx);
+size_t nextIndex = thisIndex + layout.getVTableSize(VTableIdx);
+unsigned LastAddressPoint = thisIndex;

rjmccall wrote:
> Please use the same local-variable capitalization conventions as the existing 
> code, and please don't recompute `getNumVTables()` each time through the loop.
> 
> I agree that `vtableIndex` is a clearer name than `i`, but if you're going to 
> rename locals for readability, please also rename `thisIndex` and `nextIndex`.
Updated naming in `addVTableComponent` and `addRelativeComponent` also.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72959



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


[PATCH] D80148: [OPENMP50]Add initial support for 'affinity' clause.

2020-05-18 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev created this revision.
ABataev added a reviewer: jdoerfert.
Herald added subscribers: llvm-commits, arphaman, guansong, yaxunl.
Herald added projects: clang, LLVM.

Added parsing/sema/serialization support for affinity clause in task
directives.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80148

Files:
  clang/include/clang/AST/OpenMPClause.h
  clang/include/clang/AST/RecursiveASTVisitor.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/OpenMPClause.cpp
  clang/lib/AST/StmtProfile.cpp
  clang/lib/Basic/OpenMPKinds.cpp
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/Parse/ParseOpenMP.cpp
  clang/lib/Sema/SemaOpenMP.cpp
  clang/lib/Sema/TreeTransform.h
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/OpenMP/task_affinity_messages.cpp
  clang/test/OpenMP/task_ast_print.cpp
  clang/tools/libclang/CIndex.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def

Index: llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
===
--- llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
+++ llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
@@ -197,6 +197,7 @@
 __OMP_CLAUSE(inclusive, OMPInclusiveClause)
 __OMP_CLAUSE(exclusive, OMPExclusiveClause)
 __OMP_CLAUSE(uses_allocators, OMPUsesAllocatorsClause)
+__OMP_CLAUSE(affinity, OMPAffinityClause)
 
 __OMP_CLAUSE_NO_CLASS(uniform)
 __OMP_CLAUSE_NO_CLASS(device_type)
@@ -865,6 +866,7 @@
 __OMP_DIRECTIVE_CLAUSE(task, 1, ~0, in_reduction)
 __OMP_DIRECTIVE_CLAUSE(task, 1, ~0, allocate)
 __OMP_DIRECTIVE_CLAUSE(task, 50, ~0, detach)
+__OMP_DIRECTIVE_CLAUSE(task, 50, ~0, affinity)
 
 __OMP_DIRECTIVE_CLAUSE(atomic, 1, ~0, read)
 __OMP_DIRECTIVE_CLAUSE(atomic, 1, ~0, write)
Index: clang/tools/libclang/CIndex.cpp
===
--- clang/tools/libclang/CIndex.cpp
+++ clang/tools/libclang/CIndex.cpp
@@ -2508,6 +2508,11 @@
 Visitor->AddStmt(D.AllocatorTraits);
   }
 }
+void OMPClauseEnqueue::VisitOMPAffinityClause(const OMPAffinityClause *C) {
+  Visitor->AddStmt(C->getModifier());
+  for (const Expr *E : C->varlists())
+Visitor->AddStmt(E);
+}
 } // namespace
 
 void EnqueueVisitor::EnqueueChildren(const OMPClause *S) {
Index: clang/test/OpenMP/task_ast_print.cpp
===
--- clang/test/OpenMP/task_ast_print.cpp
+++ clang/test/OpenMP/task_ast_print.cpp
@@ -34,7 +34,7 @@
 omp_depend_t x;
 omp_event_handle_t evt;
 #pragma omp taskgroup allocate(b) task_reduction(+:b)
-#pragma omp task private(a) private(this->a) private(T::a) in_reduction(+:this->b) allocate(b) depend(depobj:x) detach(evt) depend(iterator(i=0:10:1, T *k = :), in: c[i], d[(int)(k-)])
+#pragma omp task private(a) private(this->a) private(T::a) in_reduction(+:this->b) allocate(b) depend(depobj:x) detach(evt) depend(iterator(i=0:10:1, T *k = :), in: c[i], d[(int)(k-)]) affinity(iterator(i=0:10:1, T *k = :): c[i], d[(int)(k-)])
 for (int k = 0; k < a.a; ++k)
   ++this->a.a;
   }
@@ -47,9 +47,9 @@
 };
 
 // CHECK: #pragma omp taskgroup allocate(this->b) task_reduction(+: this->b)
-// CHECK: #pragma omp task private(this->a) private(this->a) private(T::a) in_reduction(+: this->b) allocate(this->b) depend(depobj : x) detach(evt) depend(iterator(int i = 0:10:1, T * k = >a:>b), in : this->c[i],this->d[(int)(k - >a)]){{$}}
+// CHECK: #pragma omp task private(this->a) private(this->a) private(T::a) in_reduction(+: this->b) allocate(this->b) depend(depobj : x) detach(evt) depend(iterator(int i = 0:10:1, T * k = >a:>b), in : this->c[i],this->d[(int)(k - >a)]) affinity(iterator(int i = 0:10:1, T * k = >a:>b) : this->c[i],this->d[(int)(k - >a)]){{$}}
 // CHECK: #pragma omp task private(this->a) private(this->a)
-// CHECK: #pragma omp task private(this->a) private(this->a) private(this->S1::a) in_reduction(+: this->b) allocate(this->b) depend(depobj : x) detach(evt) depend(iterator(int i = 0:10:1, S1 * k = >a:>b), in : this->c[i],this->d[(int)(k - >a)])
+// CHECK: #pragma omp task private(this->a) private(this->a) private(this->S1::a) in_reduction(+: this->b) allocate(this->b) depend(depobj : x) detach(evt) depend(iterator(int i = 0:10:1, S1 * k = >a:>b), in : this->c[i],this->d[(int)(k - >a)]) affinity(iterator(int i = 0:10:1, S1 * k = >a:>b) : this->c[i],this->d[(int)(k - >a)])
 
 class S8 : public S7 {
   S8() {}
@@ -101,7 +101,7 @@
   omp_event_handle_t evt;
 #pragma omp task untied depend(in : argc, argv[b:argc], arr[:], ([argc][sizeof(T)])argv) if (task : argc > 0) depend(depobj: x) detach(evt)
   a = 2;
-#pragma omp task default(none), private(argc, b) firstprivate(argv) shared(d) if (argc > 0) final(S::TS > 0) priority(argc)
+#pragma omp task default(none), private(argc, b) firstprivate(argv) shared(d) if (argc > 0) final(S::TS > 0) priority(argc) affinity(argc, argv[b:argc], arr[:], ([argc][sizeof(T)])argv)
   foo();
 #pragma omp taskgroup task_reduction(-: argc)
 

[PATCH] D79434: [analyzer] Generalize bitwise AND rules for ranges

2020-05-18 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko updated this revision to Diff 264606.
vsavchenko added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79434

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/constant-folding.c
  clang/test/Analysis/switch-case.c
  clang/test/Analysis/uninit-exhaustive-switch-bug.c

Index: clang/test/Analysis/uninit-exhaustive-switch-bug.c
===
--- /dev/null
+++ clang/test/Analysis/uninit-exhaustive-switch-bug.c
@@ -0,0 +1,20 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core -verify %s
+
+// rdar://problem/54359410
+// expected-no-diagnostics
+
+int rand();
+
+void test() {
+  int offset = 0;
+  int value;
+  int test = rand();
+  switch (test & 0x1) {
+  case 0:
+  case 1:
+value = 0;
+break;
+  }
+
+  offset += value; // no-warning
+}
Index: clang/test/Analysis/switch-case.c
===
--- clang/test/Analysis/switch-case.c
+++ clang/test/Analysis/switch-case.c
@@ -218,3 +218,14 @@
 break;
   }
 }
+
+void testExhaustiveSwitch(unsigned int a) {
+  switch (a & 5) {
+  case 0 ... 5:
+clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+break;
+  default:
+clang_analyzer_warnIfReached(); // no-warning
+break;
+  }
+}
Index: clang/test/Analysis/constant-folding.c
===
--- clang/test/Analysis/constant-folding.c
+++ clang/test/Analysis/constant-folding.c
@@ -78,19 +78,20 @@
 }
 
 void testBitwiseRules(unsigned int a, int b, int c) {
-  clang_analyzer_eval((a | 1) >= 1); // expected-warning{{TRUE}}
+  clang_analyzer_eval((a | 1) >= 1);   // expected-warning{{TRUE}}
   clang_analyzer_eval((a | -1) >= -1); // expected-warning{{TRUE}}
-  clang_analyzer_eval((a | 2) >= 2); // expected-warning{{TRUE}}
-  clang_analyzer_eval((a | 5) >= 5); // expected-warning{{TRUE}}
+  clang_analyzer_eval((a | 2) >= 2);   // expected-warning{{TRUE}}
+  clang_analyzer_eval((a | 5) >= 5);   // expected-warning{{TRUE}}
   clang_analyzer_eval((a | 10) >= 10); // expected-warning{{TRUE}}
 
   // Argument order should not influence this
   clang_analyzer_eval((1 | a) >= 1); // expected-warning{{TRUE}}
 
-  clang_analyzer_eval((a & 1) <= 1); // expected-warning{{TRUE}}
-  clang_analyzer_eval((a & 2) <= 2); // expected-warning{{TRUE}}
-  clang_analyzer_eval((a & 5) <= 5); // expected-warning{{TRUE}}
-  clang_analyzer_eval((a & 10) <= 10); // expected-warning{{TRUE}}
+  clang_analyzer_eval((a & 1) <= 1);// expected-warning{{TRUE}}
+  clang_analyzer_eval((a & 1) >= 0);// expected-warning{{TRUE}}
+  clang_analyzer_eval((a & 2) <= 2);// expected-warning{{TRUE}}
+  clang_analyzer_eval((a & 5) <= 5);// expected-warning{{TRUE}}
+  clang_analyzer_eval((a & 10) <= 10);  // expected-warning{{TRUE}}
   clang_analyzer_eval((a & -10) <= 10); // expected-warning{{UNKNOWN}}
 
   // Again, check for different argument order.
@@ -104,22 +105,37 @@
   clang_analyzer_eval((b | 1) > 0); // expected-warning{{UNKNOWN}}
 
   // Even for signed values, bitwise OR with a non-zero is always non-zero.
-  clang_analyzer_eval((b | 1) == 0); // expected-warning{{FALSE}}
+  clang_analyzer_eval((b | 1) == 0);  // expected-warning{{FALSE}}
   clang_analyzer_eval((b | -2) == 0); // expected-warning{{FALSE}}
   clang_analyzer_eval((b | 10) == 0); // expected-warning{{FALSE}}
-  clang_analyzer_eval((b | 0) == 0); // expected-warning{{UNKNOWN}}
+  clang_analyzer_eval((b | 0) == 0);  // expected-warning{{UNKNOWN}}
   clang_analyzer_eval((b | -2) >= 0); // expected-warning{{FALSE}}
 
   // Check that we can operate with negative ranges
   if (b < 0) {
 clang_analyzer_eval((b | -1) == -1);   // expected-warning{{TRUE}}
 clang_analyzer_eval((b | -10) >= -10); // expected-warning{{TRUE}}
+clang_analyzer_eval((b & 0) == 0); // expected-warning{{TRUE}}
+clang_analyzer_eval((b & -10) <= -10); // expected-warning{{TRUE}}
+clang_analyzer_eval((b & 5) >= 0); // expected-warning{{TRUE}}
 
 int e = (b | -5);
 clang_analyzer_eval(e >= -5 && e <= -1); // expected-warning{{TRUE}}
 
 if (b < -20) {
-  clang_analyzer_eval((b | e) >= -5); // expected-warning{{TRUE}}
+  clang_analyzer_eval((b | e) >= -5);// expected-warning{{TRUE}}
+  clang_analyzer_eval((b & -10) < -20);  // expected-warning{{TRUE}}
+  clang_analyzer_eval((b & e) < -20);// expected-warning{{TRUE}}
+  clang_analyzer_eval((b & -30) <= -30); // expected-warning{{TRUE}}
+
+  if (c >= -30 && c <= -10) {
+clang_analyzer_eval((b & c) <= -20); // expected-warning{{TRUE}}
+  }
+}
+
+if (a <= 40) {
+  int g = (int)a & b;
+  clang_analyzer_eval(g <= 40 && g >= 0); // expected-warning{{TRUE}}
 }
 
 // Check that we can reason about the result even if know 

[PATCH] D80015: [Analyzer][StreamChecker] Added support for 'fread' and 'fwrite'.

2020-05-18 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added a comment.

I think the warning about EOF could be a separate patch, and it could be 
implemented for most stream operations. The patch in large looks great, but I'm 
just not sure why we handle fwrite so differently. Could you please explain?




Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:56
+  bool operator!=(const StreamErrorState ) const {
+return NoError != ES.NoError || FEof != ES.FEof || FError != ES.FError;
+  }

How about `return !(*this == ES)`?



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:456-463
+  SymbolRef Sym = StreamVal.getAsSymbol();
+  if (Sym && State->get(Sym)) {
+const StreamState *SS = State->get(Sym);
+if (SS->ErrorState & ErrorFEof)
+  reportFEofWarning(C, State);
+  } else {
+C.addTransition(State);

Do we not want this for `fwrite` as well?



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:495
+return;
+  Optional CountVal = Call.getArgSVal(2).getAs();
+  if (!CountVal)

`// The standard refers to this parameter as "nmemb", but almost everywhere 
else its called "count".`



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:523
+  // FEOF).
+  if (!IsFread || (SS->ErrorState != ErrorFEof)) {
+ProgramStateRef StateNotFailed =

Aaaah okay it took me a while. I think `SS->ErrorState != ErrorFEof` isn't as 
talkative as `isConstrained.*`, could you add just a line like "if we **know** 
the state to be EOF..."?

On another note, why is fwrite so special in this context?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80015



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


[PATCH] D80117: [analyzer] Introduce reasoning about symbolic remainder operator

2020-05-18 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko updated this revision to Diff 264605.
vsavchenko added a comment.

Rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80117

Files:
  clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
  clang/test/Analysis/PR35418.cpp
  clang/test/Analysis/constant-folding.c
  clang/test/Analysis/uninit-bug-first-iteration-init.c

Index: clang/test/Analysis/uninit-bug-first-iteration-init.c
===
--- /dev/null
+++ clang/test/Analysis/uninit-bug-first-iteration-init.c
@@ -0,0 +1,27 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core -verify %s
+
+// rdar://problem/44978988
+// expected-no-diagnostics
+
+int foo();
+
+int gTotal;
+
+double bar(int start, int end) {
+  int i, cnt, processed, size;
+  double result, inc;
+
+  result = 0;
+  processed = start;
+  size = gTotal * 2;
+  cnt = (end - start + 1) * size;
+
+  for (i = 0; i < cnt; i += 2) {
+if ((i % size) == 0) {
+  inc = foo();
+  processed++;
+}
+result += inc * inc; // no-warning
+  }
+  return result;
+}
Index: clang/test/Analysis/constant-folding.c
===
--- clang/test/Analysis/constant-folding.c
+++ clang/test/Analysis/constant-folding.c
@@ -174,3 +174,64 @@
 clang_analyzer_eval((a & 1) <= 1); // expected-warning{{TRUE}}
   }
 }
+
+void testRemainderRules(unsigned int a, unsigned int b, int c, int d) {
+  // Check that we know that remainder of zero divided by any number is still 0.
+  clang_analyzer_eval((0 % c) == 0); // expected-warning{{TRUE}}
+
+  clang_analyzer_eval((10 % a) <= 10); // expected-warning{{TRUE}}
+
+  if (a <= 30 && b <= 50) {
+clang_analyzer_eval((40 % a) < 30); // expected-warning{{TRUE}}
+clang_analyzer_eval((a % b) < 50);  // expected-warning{{TRUE}}
+clang_analyzer_eval((b % a) < 30);  // expected-warning{{TRUE}}
+
+if (a >= 10) {
+  // Even though it seems like a valid assumption, it is not.
+  // Check that we are not making this mistake.
+  clang_analyzer_eval((a % b) >= 10); // expected-warning{{UNKNOWN}}
+
+  // Check that we can we can infer when remainder is equal
+  // to the dividend.
+  clang_analyzer_eval((4 % a) == 4); // expected-warning{{TRUE}}
+  if (b < 7) {
+clang_analyzer_eval((b % a) < 7); // expected-warning{{TRUE}}
+  }
+}
+  }
+
+  // Check that we can reason about signed integers when they are
+  // known to be positive.
+  if (c >= 10 && c <= 30 && d >= 20 && d <= 50) {
+clang_analyzer_eval((5 % c) == 5);  // expected-warning{{TRUE}}
+clang_analyzer_eval((c % d) <= 30); // expected-warning{{TRUE}}
+clang_analyzer_eval((c % d) >= 0);  // expected-warning{{TRUE}}
+clang_analyzer_eval((d % c) < 30);  // expected-warning{{TRUE}}
+clang_analyzer_eval((d % c) >= 0);  // expected-warning{{TRUE}}
+  }
+
+  if (c >= -30 && c <= -10 && d >= -20 && d <= 50) {
+// Test positive LHS with negative RHS.
+clang_analyzer_eval((40 % c) < 30);  // expected-warning{{TRUE}}
+clang_analyzer_eval((40 % c) > -30); // expected-warning{{TRUE}}
+
+// Test negative LHS with possibly negative RHS.
+clang_analyzer_eval((-10 % d) < 50);  // expected-warning{{TRUE}}
+clang_analyzer_eval((-20 % d) > -50); // expected-warning{{TRUE}}
+
+// Check that we don't make wrong assumptions
+clang_analyzer_eval((-20 % d) > -20); // expected-warning{{UNKNOWN}}
+
+// Check that we can reason about negative ranges...
+clang_analyzer_eval((c % d) < 50); // expected-warning{{TRUE}}
+/// ...both ways
+clang_analyzer_eval((d % c) < 30); // expected-warning{{TRUE}}
+
+if (a <= 10) {
+  // Result is unsigned.  This means that 'c' is casted to unsigned.
+  // We don't want to reason about ranges changing boundaries with
+  // conversions.
+  clang_analyzer_eval((a % c) < 30); // expected-warning{{UNKNOWN}}
+}
+  }
+}
Index: clang/test/Analysis/PR35418.cpp
===
--- /dev/null
+++ clang/test/Analysis/PR35418.cpp
@@ -0,0 +1,28 @@
+// RUN: %clang_analyze_cc1 -analyzer-checker=core -verify %s
+
+// expected-no-diagnostics
+
+void halt() __attribute__((__noreturn__));
+void assert(int b) {
+  if (!b)
+halt();
+}
+
+void decode(unsigned width) {
+  assert(width > 0);
+
+  int base;
+  bool inited = false;
+
+  int i = 0;
+
+  if (i % width == 0) {
+base = 512;
+inited = true;
+  }
+
+  base += 1; // no-warning
+
+  if (base >> 10)
+assert(false);
+}
Index: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
===
--- clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
+++ clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp
@@ -388,6 +388,8 @@
   return VisitBinaryOperator(LHS, RHS, T);
 case BO_And:
   

[PATCH] D79967: Fix debug info for NoDebug attr

2020-05-18 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl updated this revision to Diff 264622.
yaxunl marked 2 inline comments as done.
yaxunl added a comment.

Fix the tests and move the logic to CGDebugInfo::EmitFuncDeclForCallSite to 
make it clearer.


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

https://reviews.llvm.org/D79967

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGen/nodebug-attr.c
  clang/test/CodeGenCUDA/kernel-dbg-info.cu


Index: clang/test/CodeGenCUDA/kernel-dbg-info.cu
===
--- clang/test/CodeGenCUDA/kernel-dbg-info.cu
+++ clang/test/CodeGenCUDA/kernel-dbg-info.cu
@@ -2,11 +2,28 @@
 
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm %s -O0 \
 // RUN:   -fcuda-include-gpubinary %t -debug-info-kind=limited \
-// RUN:   -o - -x hip | FileCheck %s
+// RUN:   -o - -x hip | FileCheck -check-prefixes=CHECK,O0 %s
 // RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -emit-llvm %s -O0 \
 // RUN:   -fcuda-include-gpubinary %t -debug-info-kind=limited \
 // RUN:   -o - -x hip -fcuda-is-device | FileCheck -check-prefix=DEV %s
 
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm %s -O0 \
+// RUN:   -fcuda-include-gpubinary %t -debug-info-kind=limited \
+// RUN:   -o - -x hip -debugger-tuning=gdb -dwarf-version=4 \
+// RUN:   | FileCheck -check-prefixes=CHECK,O0 %s
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -emit-llvm %s -O0 \
+// RUN:   -fcuda-include-gpubinary %t -debug-info-kind=limited \
+// RUN:   -o - -x hip -debugger-tuning=gdb -dwarf-version=4 \
+// RUN:   -fcuda-is-device | FileCheck -check-prefix=DEV %s
+
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm %s -O3 \
+// RUN:   -fcuda-include-gpubinary %t -debug-info-kind=limited \
+// RUN:   -o - -x hip -debugger-tuning=gdb -dwarf-version=4 | FileCheck %s
+// RUN: %clang_cc1 -triple amdgcn-amd-amdhsa -emit-llvm %s -O3 \
+// RUN:   -fcuda-include-gpubinary %t -debug-info-kind=limited \
+// RUN:   -o - -x hip -debugger-tuning=gdb -dwarf-version=4 \
+// RUN:   -fcuda-is-device | FileCheck -check-prefix=DEV %s
+
 #include "Inputs/cuda.h"
 
 extern "C" __global__ void ckernel(int *a) {
@@ -20,14 +37,14 @@
 // DEV:  store {{.*}}!dbg
 // DEV:  ret {{.*}}!dbg
 
-// CHECK-NOT: define {{.*}}@__device_stub__ckernel{{.*}}!dbg
-// CHECK: define {{.*}}@[[CSTUB:__device_stub__ckernel]]
+// Make sure there is no !dbg between function attributes and '{'
+// CHECK: define void @[[CSTUB:__device_stub__ckernel]]{{.*}} #{{[0-9]+}} {
 // CHECK-NOT: call {{.*}}@hipLaunchByPtr{{.*}}!dbg
 // CHECK: call {{.*}}@hipLaunchByPtr{{.*}}@[[CSTUB]]
 // CHECK-NOT: ret {{.*}}!dbg
 
 // CHECK-LABEL: define {{.*}}@_Z8hostfuncPi{{.*}}!dbg
-// CHECK: call void @[[CSTUB]]{{.*}}!dbg
+// O0: call void @[[CSTUB]]{{.*}}!dbg
 void hostfunc(int *a) {
   ckernel<<<1, 1>>>(a);
 }
Index: clang/test/CodeGen/nodebug-attr.c
===
--- /dev/null
+++ clang/test/CodeGen/nodebug-attr.c
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm %s -O3 \
+// RUN:   -debug-info-kind=limited -o - -debugger-tuning=gdb -dwarf-version=4 \
+// RUN:   | FileCheck %s
+
+// Makes sure there is no !dbg between function attributes and '{'.
+// CHECK-LABEL: define void @foo{{.*}} #{{[0-9]+}} {
+// CHECK-NOT: ret {{.*}}!dbg
+__attribute__((nodebug)) void foo(int *a) {
+  *a = 1;
+}
+
+// CHECK-LABEL: define {{.*}}@bar{{.*}}!dbg
+void bar(int *a) {
+  foo(a);
+}
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -3844,12 +3844,12 @@
   if (Func->getSubprogram())
 return;
 
-  // Do not emit a declaration subprogram for a builtin or if call site info
-  // isn't required. Also, elide declarations for functions with reserved 
names,
-  // as call site-related features aren't interesting in this case (& also, the
-  // compiler may emit calls to these functions without debug locations, which
-  // makes the verifier complain).
-  if (CalleeDecl->getBuiltinID() != 0 ||
+  // Do not emit a declaration subprogram for a builtin, a function with 
nodebug
+  // attribute, or if call site info isn't required. Also, elide declarations
+  // for functions with reserved names, as call site-related features aren't
+  // interesting in this case (& also, the compiler may emit calls to these
+  // functions without debug locations, which makes the verifier complain).
+  if (CalleeDecl->getBuiltinID() != 0 || CalleeDecl->hasAttr() ||
   getCallSiteRelatedAttrs() == llvm::DINode::FlagZero)
 return;
   if (const auto *Id = CalleeDecl->getIdentifier())


Index: clang/test/CodeGenCUDA/kernel-dbg-info.cu
===
--- clang/test/CodeGenCUDA/kernel-dbg-info.cu
+++ clang/test/CodeGenCUDA/kernel-dbg-info.cu
@@ -2,11 +2,28 @@
 
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -emit-llvm %s -O0 \
 // RUN:   

[PATCH] D80015: [Analyzer][StreamChecker] Added support for 'fread' and 'fwrite'.

2020-05-18 Thread Balázs Kéri via Phabricator via cfe-commits
balazske marked 4 inline comments as done.
balazske added a comment.

The difference of fread and fwrite comes from the fact that `fwrite` can always 
succeed, `fread` does not succeed in EOF state.
The plan is to add the file functions sequentially. From the currently 
implemented functions only `fread` needs the warning in EOF state. When any 
later function is added that fails in EOF state, the warning should be added 
for that function at that time.




Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:56
+  bool operator!=(const StreamErrorState ) const {
+return NoError != ES.NoError || FEof != ES.FEof || FError != ES.FError;
+  }

Szelethus wrote:
> How about `return !(*this == ES)`?
Probably better (does not look better but is more bug-safe).



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:456-463
+  SymbolRef Sym = StreamVal.getAsSymbol();
+  if (Sym && State->get(Sym)) {
+const StreamState *SS = State->get(Sym);
+if (SS->ErrorState & ErrorFEof)
+  reportFEofWarning(C, State);
+  } else {
+C.addTransition(State);

Szelethus wrote:
> Do we not want this for `fwrite` as well?
It should be no problem to write into a file at the end of the file, the file 
is extended.



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:495
+return;
+  Optional CountVal = Call.getArgSVal(2).getAs();
+  if (!CountVal)

Szelethus wrote:
> `// The standard refers to this parameter as "nmemb", but almost everywhere 
> else its called "count".`
I looked up the functions in [[ https://en.cppreference.com/w/c/io/fread | 
cppreference.com ]], there it is called `count`. But probably it is better to 
use the standard name here?



Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:523
+  // FEOF).
+  if (!IsFread || (SS->ErrorState != ErrorFEof)) {
+ProgramStateRef StateNotFailed =

Szelethus wrote:
> Aaaah okay it took me a while. I think `SS->ErrorState != ErrorFEof` isn't as 
> talkative as `isConstrained.*`, could you add just a line like "if we 
> **know** the state to be EOF..."?
> 
> On another note, why is fwrite so special in this context?
If it is an `fwrite`, the function call can always succeed (even after a 
previously EOF or error).
If it is an `fread`, it can succeed but not after an exactly-EOF state.

A success transition is not needed in an `fread` with exactly EOF condition. 
(If we have fread with non-exactly EOF, for example `ErrorFEof` and 
`ErrorFError`, the success is needed because the read in `ErrorFError` can 
succeed.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80015



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


[PATCH] D80115: [clang-format] [PR45816] Add AlignConsecutiveBitFields

2020-05-18 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay planned changes to this revision.
MyDeveloperDay marked an inline comment as done.
MyDeveloperDay added inline comments.



Comment at: clang/lib/Format/WhitespaceManager.cpp:588-590
+return C.Tok->Previous->startsSequence(tok::identifier, tok::colon,
+   tok::numeric_constant);
+  },

JakeMerdichAMD wrote:
> TT_BitFieldColon should match this criteria exactly. 
I think using TT_BitFieldColon is a better idea


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

https://reviews.llvm.org/D80115



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


[PATCH] D79905: [clang-format] [PR44476] Add space between template and attribute

2020-05-18 Thread Jake Merdich via Phabricator via cfe-commits
JakeMerdichAMD accepted this revision.
JakeMerdichAMD added a comment.
This revision is now accepted and ready to land.

LGTM


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

https://reviews.llvm.org/D79905



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


[clang] 1907f28 - [Analyzer][StreamChecker] Fixed compile error - NFC.

2020-05-18 Thread Balázs Kéri via cfe-commits

Author: Balázs Kéri
Date: 2020-05-18T17:14:39+02:00
New Revision: 1907f28b47cfe9c951df43309d121679895b0edf

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

LOG: [Analyzer][StreamChecker] Fixed compile error - NFC.

Added: 


Modified: 
clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
index d079951221d0..c94cae045239 100644
--- a/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
@@ -108,10 +108,10 @@ struct StreamState {
 return StreamState{L, Opened, ES};
   }
   static StreamState getClosed(const FnDescription *L) {
-return StreamState{L, Closed};
+return StreamState{L, Closed, {}};
   }
   static StreamState getOpenFailed(const FnDescription *L) {
-return StreamState{L, OpenFailed};
+return StreamState{L, OpenFailed, {}};
   }
 
   void Profile(llvm::FoldingSetNodeID ) const {



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


[PATCH] D80015: [Analyzer][StreamChecker] Added support for 'fread' and 'fwrite'.

2020-05-18 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added a comment.

In D80015#2041653 , @balazske wrote:

> The difference of fread and fwrite comes from the fact that `fwrite` can 
> always succeed, `fread` does not succeed in EOF state.
>  The plan is to add the file functions sequentially. From the currently 
> implemented functions only `fread` needs the warning in EOF state. When any 
> later function is added that fails in EOF state, the warning should be added 
> for that function at that time.


Ah, silly me. Like, obviously, where would you like write the file, if not at 
the end of it...

In any case, the warning would be a better fit as a standalone revision because 
FERROR also deserves a similar warning I think, not to mention that plenty of 
other stream operations should check against this.




Comment at: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp:495
+return;
+  Optional CountVal = Call.getArgSVal(2).getAs();
+  if (!CountVal)

balazske wrote:
> Szelethus wrote:
> > `// The standard refers to this parameter as "nmemb", but almost everywhere 
> > else its called "count".`
> I looked up the functions in [[ https://en.cppreference.com/w/c/io/fread | 
> cppreference.com ]], there it is called `count`. But probably it is better to 
> use the standard name here?
Its not a big deal, either a comment or a variable name change should be fine. 
I'll leave it to your judgement, but its not a bad idea to leave a line about 
the most commonly referred name ("count") is not the same as the standard one 
("nmemb").


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80015



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


[PATCH] D80015: [Analyzer][StreamChecker] Added support for 'fread' and 'fwrite'.

2020-05-18 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added a comment.

But just to assure you, this patch is practically perfect. I don't think we're 
going to have any hiccups moving forward with this. Again, thank you for all 
the patience!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80015



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


[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

2020-05-18 Thread Sjoerd Meijer via Phabricator via cfe-commits
SjoerdMeijer added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:8111
   "pointer cannot be cast to type %0">;
+def err_cast_to_bfloat : Error<"cannot type-cast to __bf16">;
+def err_cast_from_bfloat : Error<"cannot type-cast from __bf16">;

Nit: was wondering if `err_cast_to_bfloat16` would be more consistent



Comment at: clang/lib/AST/ASTContext.cpp:6007
 case Float16Rank:
 case HalfRank: llvm_unreachable("Complex half is not supported");
 case FloatRank:  return FloatComplexTy;

nit: perhaps this error message is not entirely accurate for bfloat16?



Comment at: clang/lib/Basic/Targets/AArch64.cpp:74
+  BFloat16Width = BFloat16Align = 16;
+  BFloat16Format = ::APFloat::BFloat();
+

Nit: we use bfloat16 everywhere, would `llvm::APFloat::BFloat16()` be better 
for consistency?



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:115
   HalfTy = llvm::Type::getHalfTy(LLVMContext);
+  BFloatTy = llvm::Type::getBFloatTy(LLVMContext);
   FloatTy = llvm::Type::getFloatTy(LLVMContext);

nit: perhaps `getBFloat16Ty()`



Comment at: clang/lib/CodeGen/CodeGenTypeCache.h:39
+  /// half, bfloat, float, double
+  llvm::Type *HalfTy, *BFloatTy, *FloatTy, *DoubleTy;
 

And so here too, BFloat16Ty?



Comment at: clang/lib/CodeGen/TargetInfo.cpp:5844
   ABIKind Kind;
+  bool IsSoftFloatABI;
 

Nit: to distinguish the unfortunate float ABI names, I was wondering whether 
`IsFloatABISoftFP` is clearer, or something along those lines, just to make 
clear it is not the "soft" but the "softfp" variant


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76077



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


[PATCH] D79704: [Analyzer] [NFC] Parameter Regions

2020-05-18 Thread Gabor Marton via Phabricator via cfe-commits
martong added a comment.

Wow, this is some nice work and huge effort from all the participants, it was 
pretty informative to read through. Thanks @baloghadamsoftware and @NoQ for 
working on this!

> This means that we always found a Decl. However, this Decl is not stored but 
> retrieved always based on the actual stack frame: we get the Decl of the 
> function/method/block/etc. from the stack frame and find its parameter using 
> the Index. This is always successful, at least in all the analyzer tests.

Can we find the FunctionDecl if the call happens through a function pointer? Or 
in that case do we actually find the VarDecl of the function pointer?

> Without stack frame we do not create ParamRegion. The other two functions 
> creating ParamRegion (CallEvent::addParameterValuesToBindings and the newly 
> created MemRegionManager::getRegionForParam) start from ParmVarDecl which 
> always belongs to a Decl. So we can safely assume that currently all 
> parameter regions have a Decl. Of course, this can be changed in the future, 
> but I must not include dead code in a patch that cannot even be tested in the 
> current phase. Even creation of callee stack frame for functions without 
> definition is not part of this patch, but of the subsequent one.

So, in this patch, we are trying to solve only that problem when the callee 
`FunctionDecl` does not have a definition?

> If Decl is missing, then we cannot get its AnalysisDeclContext either, so how 
> can we get a stack frame? However, currently we need a solution where we can 
> get stack frame for callees with Decl but without definition.

This happens in case of top-level params and in case of function pointers, plus 
the special argument construction, am I right?

Based on the answers to the above questions, possibly we are trying to solve 
two problems here. Could we split then this patch into two?

1. callee FunctionDecl does not have a definition. This could assert on having 
an accessable Decl in ParamVarRegion. Here we could have the foundations of the 
next patch, i.e. we could have ParamVarRegion and NonParamVarRegion.
2. function pointers, plus the special argument construction: ParamVarRegion 
may not have a Decl and we'd remove the related lines from 
getCalleeAnalysisDeclContext. This obviously requires more tests. And more 
brainstorming to get the AnalysisDeclContext when there is no Decl available 
for the function in getCalleeAnalysisDeclContext.

What do you think?




Comment at: clang/lib/StaticAnalyzer/Checkers/ValistChecker.cpp:176-180
   if (const auto *DeclReg = Reg->getAs()) {
 if (isa(DeclReg->getDecl()))
   Reg = C.getState()->getSVal(SV.castAs()).getAsRegion();
+  } else if (const auto *ParamReg = Reg->getAs()) {
+Reg = C.getState()->getSVal(SV.castAs()).getAsRegion();

balazske wrote:
> baloghadamsoftware wrote:
> > balazske wrote:
> > > baloghadamsoftware wrote:
> > > > Szelethus wrote:
> > > > > This is interesting. I looked up `DeclRegion`, and it seems to be the 
> > > > > region that is tied to a `ValueDecl`. `VarDecl` is a subtype of 
> > > > > `ValueDecl`, and `ParmVarDecl` is a subtype of `VarDecl`, so wouldn't 
> > > > > it make sense for `ParamRegion` to be a subtype of `VarRegion`?
> > > > `DeclRegion` stores the `Decl`, `ParamRegion` retrieves it based on the 
> > > > `Index` it stores. There is no is-a relation between them.
> > > During the lifetime of a `ParamRegion` is it possible that it will return 
> > > different `Decl` objects?
> > @NoQ?
> Purpose of the question is that if the answer is "no", the decl could be 
> stored at construction of a `ParamRegion` and it could be a subclass of 
> `DeclRegion`. From the code I do not see that the belonging `Decl` can 
> change, probably yes if the stack frame changes somehow. So the reason to 
> have the `ParamRegion` seems to be to have the expression and index 
> available, maybe use these for profiling (instead of a `Decl`). Still it 
> could be made a subclass of `DeclRegion` that stores additionally the expr 
> and index and profiling works with these values.
> During the lifetime of a ParamRegion is it possible that it will return 
> different Decl objects?

AFAIU, Yes. The `CallExpr` may refer to a `FunctionDecl` (the callee), but that 
Decl may not be the Canonical Decl of the redeclaration chain.



Comment at: clang/lib/StaticAnalyzer/Core/MemRegion.cpp:191
+const ParmVarDecl *ParamRegion::getDecl() const {
+  const Decl *D = getStackFrame()->getDecl();
+

baloghadamsoftware wrote:
> NoQ wrote:
> > baloghadamsoftware wrote:
> > > NoQ wrote:
> > > > baloghadamsoftware wrote:
> > > > > NoQ wrote:
> > > > > > baloghadamsoftware wrote:
> > > > > > > NoQ wrote:
> > > > > > > > This doesn't work when the callee is unknown.
> > > > > > > Please give me an example where the callee is unknown. As I 
> > > > > > > wrote, originally I put a `getExpr()` method here as well and 
> > > > > 

[PATCH] D68049: Propeller: Clang options for basic block sections

2020-05-18 Thread Sriraman Tallam via Phabricator via cfe-commits
tmsriram added a comment.

Ping.




Comment at: clang/include/clang/Basic/CodeGenOptions.h:114-127
+  // -fbasic-block-sections=.  The allowed values with this option are:
+  // {"labels", "all", "", "none"}.
+  //
+  // "labels": Only generate basic block symbols (labels) for all basic
+  //   blocks, do not generate unique sections for basic blocks.
+  //   Use the machine basic block id in the symbol name to
+  //   associate profile info from virtual address to machine

rsmith wrote:
> This comment appears to be out of date with respect to the `list=` change.
Fixed, sorry.


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

https://reviews.llvm.org/D68049



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


[PATCH] D80109: [AST][RecoveryExpr] Preserve type for broken member call expr.

2020-05-18 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/lib/Sema/SemaOverload.cpp:14083
 OverloadCandidateSet::iterator Best;
+bool Succeeded = true;
 switch (CandidateSet.BestViableFunction(*this, UnresExpr->getBeginLoc(),

seems like `bool Success = false` would be a "safer" default and have to be set 
in fewer places



Comment at: clang/lib/Sema/SemaOverload.cpp:14105
 
 case OR_No_Viable_Function:
   CandidateSet.NoteCandidates(

hokein wrote:
> It is a bit sad that the broken function call cases (too many/few agguments) 
> are failing into this group, all candidates are not viable -- this means we 
> don't get any benefits (no `Best`), for some cases, it is suboptimal even 
> though the best candidate looks like obvious.
> 
> ```
> class Collection {
>   const char *find(int) const;
>   char* find(int);
> };
> void test1(const Collection ) {
>  C.find(); // we want const char*, but all overloads are not viable and 
> return types are not the same, so no type captured here.
> }
> ```
Yeah, at some point we can add more heuristics (discard non-viable or hidden 
functions using heuristics) to handle this case, like I did in 
SemaCodeComplete...



Comment at: clang/lib/Sema/SemaOverload.cpp:14133
 }
+// Overload resolvation fails, try to recover.
+if (!Succeeded)

resolvation -> resolution



Comment at: clang/test/AST/ast-dump-recovery.cpp:123
+
+  // FIXME: capture the type!
+  f.func(1);

why does this not work?
isn't there only one candidate, so chooseRecoveryType should pick it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80109



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


[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

2020-05-18 Thread Sjoerd Meijer via Phabricator via cfe-commits
SjoerdMeijer added a comment.

There are Sema and CodeGen tests, but was wondering if there would be some 
value in having an AST test too? There are some other types that do have AST 
tests.




Comment at: clang/lib/AST/ASTContext.cpp:2052
+  Width = Target->getBFloat16Width();
+  Align = Target->getBFloat16Align();
 case BuiltinType::Float16:

Is a `break` missing here?



Comment at: clang/lib/CodeGen/CodeGenTypes.cpp:307
+else
+  return llvm::Type::getInt16Ty(VMContext);
+  }

Is this covered in tests?



Comment at: clang/lib/CodeGen/TargetInfo.cpp:6454
+// types into integer vectors.
+// We do not depend on haslegalhalf type for bfloat as it is a
+// separate IR type

nit: camelcase fase for haslegalhalf



Comment at: clang/test/CodeGen/arm-mangle-16bit-float.cpp:4
+
+// CHECK64: define {{.*}}void @_Z3foou6__bf16(half %b)
+// CHECK32: define {{.*}}void @_Z3foou6__bf16(i32 %b.coerce)

LukeGeeson wrote:
> craig.topper wrote:
> > How can bfloat16 be passed as half? Don't they have a different format?
> see the above comment about soft-abis
Probably I am bit confused too now... are the three possible types that we are 
expecing not bfloat, i32, or i16? 



Comment at: clang/test/CodeGen/arm-mangle-16bit-float.cpp:2
+// RUN: %clang_cc1 -triple aarch64-arm-none-eabi 
-fallow-half-arguments-and-returns -target-feature +bf16 -target-feature 
+fullfp16 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK64
+// RUN: %clang_cc1 -triple arm-arm-none-eabi 
-fallow-half-arguments-and-returns -target-feature +bf16 -target-feature 
+fullfp16 -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK32
+

Do you need to pass `+fullfp16`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76077



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


[PATCH] D80117: [analyzer] Introduce reasoning about symbolic remainder operator

2020-05-18 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko marked 2 inline comments as done.
vsavchenko added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:459
+bool CoversTheWholeType =
+(Origin.From().isMinSignedValue() || Origin.To().isMaxValue());
+

NoQ wrote:
> `(Origin.From() + 1).isMinSignedValue()` is another sufficient condition(?)
I'm sorry, I don't quite get what cases does this check cover.  Can you please 
explain what you have in mind?



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:462
+if (CoversTheWholeType) {
+  return {ValueFactory.getMinValue(RangeType),
+  ValueFactory.getMaxValue(RangeType)};

NoQ wrote:
> You mean zero, right?
No, not always.  It still can be signed at this point.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80117



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


[PATCH] D80115: [clang-format] [PR45816] Add AlignConsecutiveBitFields

2020-05-18 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.

How about I abandon and we use yours (but would you please consider changing 
the name to be AlignConsecutiveBitFields )  (capital F) as that was in the 
orignal request


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

https://reviews.llvm.org/D80115



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


[PATCH] D80117: [analyzer] Introduce reasoning about symbolic remainder operator

2020-05-18 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:462
+if (CoversTheWholeType) {
+  return {ValueFactory.getMinValue(RangeType),
+  ValueFactory.getMaxValue(RangeType)};

vsavchenko wrote:
> NoQ wrote:
> > You mean zero, right?
> No, not always.  It still can be signed at this point.
Ok, so i misunderstood. This function computes range of `abs($x)` aka `|$x|` 
given the range for `$x`, right?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80117



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


[PATCH] D79992: [WIP][clangd] Patch PP directives to use stale preambles while building ASTs

2020-05-18 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet updated this revision to Diff 264666.
kadircet added a comment.

- MacroInfo's definition range is a token range, convert it to a char range.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79992

Files:
  clang-tools-extra/clangd/Preamble.cpp
  clang-tools-extra/clangd/unittests/PreambleTests.cpp

Index: clang-tools-extra/clangd/unittests/PreambleTests.cpp
===
--- clang-tools-extra/clangd/unittests/PreambleTests.cpp
+++ clang-tools-extra/clangd/unittests/PreambleTests.cpp
@@ -26,6 +26,7 @@
 #include 
 #include 
 
+using testing::Contains;
 using testing::Field;
 
 namespace clang {
@@ -181,6 +182,67 @@
   ElementsAre(AllOf(Field(::Written, "\"a.h\""),
 Field(::Resolved, testPath("a.h");
 }
+
+llvm::Optional createPatchedAST(llvm::StringRef Baseline,
+   llvm::StringRef Modified) {
+  auto BaselinePreamble = TestTU::withCode(Baseline).buildPreamble();
+  if (!BaselinePreamble) {
+ADD_FAILURE() << "Failed to build baseline preamble";
+return llvm::None;
+  }
+
+  IgnoreDiagnostics Diags;
+  auto TU = TestTU::withCode(Modified);
+  auto CI = buildCompilerInvocation(TU.inputs(), Diags);
+  if (!CI) {
+ADD_FAILURE() << "Failed to build compiler invocation";
+return llvm::None;
+  }
+  return ParsedAST::build(testPath("main.cpp"), TU.inputs(), std::move(CI), {},
+  BaselinePreamble);
+}
+
+TEST(PreamblePatchTest, Define) {
+  // BAR should be defined while parsing the AST.
+  llvm::StringLiteral Cases[] = {
+  R"cpp(
+#define BAR
+[[BAR]])cpp",
+  // multiline macro
+  R"cpp(
+#define BAR \
+
+[[BAR]])cpp",
+  // multiline macro
+  R"cpp(
+#define \
+BAR
+[[BAR]])cpp",
+  };
+
+  for (llvm::StringLiteral Case : Cases) {
+SCOPED_TRACE(Case);
+Annotations Modified(Case);
+auto AST = createPatchedAST("", Modified.code());
+ASSERT_TRUE(AST);
+EXPECT_THAT(AST->getDiagnostics(),
+Not(Contains(Field(::Range, Modified.range();
+  }
+}
+
+TEST(PreamblePatchTest, OrderingPreserved) {
+  llvm::StringLiteral Baseline = "#define BAR(X) X";
+  Annotations Modified(R"cpp(
+#define BAR(X, Y) X Y
+#define BAR(X) X
+[[BAR]](int y);
+  )cpp");
+
+  auto AST = createPatchedAST(Baseline, Modified.code());
+  ASSERT_TRUE(AST);
+  EXPECT_THAT(AST->getDiagnostics(),
+  Not(Contains(Field(::Range, Modified.range();
+}
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/Preamble.cpp
===
--- clang-tools-extra/clangd/Preamble.cpp
+++ clang-tools-extra/clangd/Preamble.cpp
@@ -15,6 +15,7 @@
 #include "clang/Basic/Diagnostic.h"
 #include "clang/Basic/LangOptions.h"
 #include "clang/Basic/SourceLocation.h"
+#include "clang/Basic/SourceManager.h"
 #include "clang/Basic/TokenKinds.h"
 #include "clang/Frontend/CompilerInvocation.h"
 #include "clang/Frontend/FrontendActions.h"
@@ -106,14 +107,68 @@
   const SourceManager *SourceMgr = nullptr;
 };
 
-/// Gets the includes in the preamble section of the file by running
-/// preprocessor over \p Contents. Returned includes do not contain resolved
-/// paths. \p VFS and \p Cmd is used to build the compiler invocation, which
-/// might stat/read files.
-llvm::Expected>
-scanPreambleIncludes(llvm::StringRef Contents,
- llvm::IntrusiveRefCntPtr VFS,
- const tooling::CompileCommand ) {
+struct TextualPPDirective {
+  unsigned DirectiveLine;
+  // Full text that's representing the directive, including the `#`.
+  std::string Text;
+
+  bool operator==(const TextualPPDirective ) const {
+return std::tie(DirectiveLine, Text) ==
+   std::tie(RHS.DirectiveLine, RHS.Text);
+  }
+};
+
+// Collects #define directives inside the main file.
+struct DirectiveCollector : public PPCallbacks {
+  DirectiveCollector(const Preprocessor ,
+ std::vector )
+  : LangOpts(PP.getLangOpts()), SM(PP.getSourceManager()),
+TextualDirectives(TextualDirectives) {}
+
+  void FileChanged(SourceLocation Loc, FileChangeReason Reason,
+   SrcMgr::CharacteristicKind FileType,
+   FileID PrevFID) override {
+InMainFile = SM.isWrittenInMainFile(Loc);
+  }
+
+  void MacroDefined(const Token ,
+const MacroDirective *MD) override {
+if (!InMainFile)
+  return;
+TextualDirectives.emplace_back();
+TextualPPDirective  = TextualDirectives.back();
+
+auto DecompLoc = SM.getDecomposedLoc(MacroNameTok.getLocation());
+TD.DirectiveLine = SM.getLineNumber(DecompLoc.first, DecompLoc.second);
+
+SourceRange DefRange(
+

[PATCH] D75791: [clang-format] Added new option IndentExternBlock

2020-05-18 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.

I think it needs to be:

`LLVMStyle.IndentExternBlock = FormatStyle::IEBS_NoIndent;`

I'm wondering if the GNU style also needs

`Expanded.IndentExternBlock = FormatStyle::IEBS_Indent;`


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

https://reviews.llvm.org/D75791



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


[PATCH] D79895: Add a new warning to warn when passing uninitialized variables as const reference parameters to a function

2020-05-18 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks added inline comments.



Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:2110
+def warn_uninit_const_reference : Warning<
+  "variable %0 is uninitialized when passes as a const reference parameter "
+  "here">, InGroup, DefaultIgnore;

s/passes/passed



Comment at: clang/test/SemaCXX/warn-uninitialized-const-reference.cpp:23
+int k = const_use(k); // expected-warning {{variable 'k' is uninitialized 
when used within its own initialization}}
+A a2 = const_use_A(a2); // expected-warning {{variable 'a2' is 
uninitialized when used within its own initialization}}
+A a3(const_ref_use_A(a3)); // expected-warning {{variable 'a3' is 
uninitialized when passes as a const reference parameter here}}

For my knowledge, is this to make sure that this other warning takes precedence 
over the one introduced in this change? If it is, a comment would be nice.


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

https://reviews.llvm.org/D79895



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


[PATCH] D76077: [ARM] Add __bf16 as new Bfloat16 C Type

2020-05-18 Thread Sjoerd Meijer via Phabricator via cfe-commits
SjoerdMeijer added inline comments.



Comment at: clang/docs/LanguageExtensions.rst:518
+Clang supports three half-precision (16-bit) floating point types: ``__fp16``,
+``_Float16`` and ``__bf16``.  These types are supported in all language modes.
 

stuij wrote:
> SjoerdMeijer wrote:
> > stuij wrote:
> > > SjoerdMeijer wrote:
> > > > Not my field of expertise, and sorry if I've missed this somewhere, but 
> > > > was wondering if this (i.e. all language modes) means we need C++ name 
> > > > mangling support for bfloat? In the AArch64 backend I saw this:
> > > > 
> > > >   getBFloat16Mangling() const override { return "u6__bf16"; }
> > > > 
> > > > But that's something else I guess, and I was guessing a 2 letter 
> > > > mangling needs to be added here?
> > > > 
> > > > https://itanium-cxx-abi.github.io/cxx-abi/abi.html#mangling-builtin
> > > Yes, we need name-mangling support, and yes that method you mentioned 
> > > does that. There's one for AArch32 as well. And yes we have documented it 
> > > in the 'C++ ABI for the latest Arm Architecture' docs:
> > > 
> > > aarch32: https://developer.arm.com/docs/ihi0041/latest
> > > aarch64: https://developer.arm.com/docs/ihi0059/latest
> > But does that mean that for other targets this is not (yet) supported?
> Currently bfloat is a vendor-extended type, hence the 'u' prefix. So to me it 
> would make sense that backends should implement their own naming, as there's 
> no guarantee that the naming scheme chosen for Arm is compatible with all 
> backends.
Ok, true, fair enough


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76077



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


[PATCH] D79967: Fix debug info for NoDebug attr

2020-05-18 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added subscribers: djtodoro, dexonsmith.
dblaikie added a comment.

In D79967#2041595 , @yaxunl wrote:

> In D79967#2039153 , @dblaikie wrote:
>
> > Could you check the commit history for this feature and rope in some folks 
> > who added the function declaration work (it's for debug call sites) - maybe 
> > @vsk is the right person, or knows who is, to check this is the right fix 
> > for it/doesn't adversely affect the feature this code was added to 
> > implement.
>
>
> Anders Carlsson introduced support of nodebug attribute by the following two 
> commits:
>
> https://github.com/llvm/llvm-project/commit/76187b4d689a6ce601f2055b3dad5be6a4ab1012
>  
> https://github.com/llvm/llvm-project/commit/63784f4e5e125b7a81c92c2cf176797ce67b2e6d
>
> However, it seems he is not in Phabricator.
>
> Based on documentation of nodebug attribute:
>
> https://clang.llvm.org/docs/AttributeReference.html#nodebug
>
> clang should not emit any debug information for functions with nodebug attr.


Oh, sorry - I didn't mean the nodebug attribute feature I meant the "emitting 
function declarations" feature - looks like @vsk and @djtodoro have worked on 
that support & I'd like them to chime in on this.

> When control flow goes to
> 
> https://github.com/llvm/llvm-project/blob/5b0502dff5b6f510fbf823059faa042dd1523cef/llvm/lib/CodeGen/LexicalScopes.cpp#L53
> 
> Since getUnit() is nullptr, clang crashes.

Hmm, this sort of seems like it might lead to other bugs - @vsk wouldn't this 
assert/fail under LTO too? (we might emit a DISubprogram declaration for a 
function in one translation unit, but if another translation unit that defines 
that function is emitted without debug info - would the DISubprogram 
declaration (with no unit field) get attached to the definition and lead to 
this sort of crash?)? hmm, nope, because these things are never attached to 
definitions usually. So then a side question becomes "how did this end up 
attached to a definition?" (I guess "because there was a definition")

@vsk - we might need to have some broader design discussion. I see that these 
function declarations end up in the CU's retainedTypes field (I might've been 
involved in the discussion that got them there? I'm not sure - either way, in 
retrospect/now that I see it, I have concerns). This means the declarations 
persist through LTO and don't get deduplicated against the definitions - that's 
not ideal/will bloat up LTO and ThinLTO bitcode, and persist through other 
optimizations (eg: if the function gets optimized away/all call sites are dead 
and optimized out, etc) - it's /probably/ better they get attached to the 
llvm::Function declaration so it can be cleaned up as needed. That's why 
DISubprogram moved to be attached to an llvm::Function (previously all 
DISubprograms were listed on the CU and DISubprograms pointed to 
llvm::Functions) to aid in LTO (@aprantl and @dexonsmith who were involved in 
that migration).

But as it pertains to this bug - I /imagine/ the fix proposed right now is 
about right, but I'd like @vsk or similar to chime in to confirm (& then maybe 
start another thread on ^)


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

https://reviews.llvm.org/D79967



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


[PATCH] D80055: Diagnose union tail padding

2020-05-18 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith added inline comments.



Comment at: clang/test/CodeGen/union-tail-padding.c:28-36
+union Front {
+  int i;
+  long long ll;
+};
+
+union Front front1;
+union Front front2 = {};// expected-warning {{Initializing union 
'Front' field 'i' only initializes the first 4 of 8 bytes, leaving the 
remaining 4 bytes undefined}}

jfb wrote:
> dexonsmith wrote:
> > Are these warnings actionable?  What should users do when they see this 
> > warning?
> Good point!
> 
> I was thinking about this, and was wondering if I should add a fixit which 
> suggests using the first wider member of the union. The problem is to offer 
> the same object representation... that's tricky on its own (there isn't 
> always an exact match), and then we have to deal with type punning (in C++, 
> not in C).
> 
> So I'd love ideas, because I'm not sure what to do. That being said, I wrote 
> this partly because D68115 was surprising to folks, and partly because 
> developers would like to opt-in to this diagnostic to find places where 
> initialization isn't doing what they think.
> 
> Maybe instead we should suggest to leave uninitialized, and use an 
> assignment, or `memset`?
> Maybe instead we should suggest to leave uninitialized, and use an 
> assignment, or `memset`?

It's not clear to me that those are better.  For example, `memset` doesn't seem 
right for non-PODs in C++.  I'm not sure what to suggest though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80055



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


[PATCH] D80117: [analyzer] Introduce reasoning about symbolic remainder operator

2020-05-18 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko marked an inline comment as done.
vsavchenko added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:462
+if (CoversTheWholeType) {
+  return {ValueFactory.getMinValue(RangeType),
+  ValueFactory.getMaxValue(RangeType)};

NoQ wrote:
> vsavchenko wrote:
> > NoQ wrote:
> > > You mean zero, right?
> > No, not always.  It still can be signed at this point.
> Ok, so i misunderstood. This function computes range of `abs($x)` aka `|$x|` 
> given the range for `$x`, right?
I guess I should fix my comments (and maybe the name for this function).
This function finds absolute maximum, i.e. the value `C: |$x| <= C` and returns 
the range `[-C, C]` for signed `$x`s and `[0, C]` for unsigned `$x`s.

So this new range is guaranteed to include the original range.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80117



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


[PATCH] D80117: [analyzer] Introduce reasoning about symbolic remainder operator

2020-05-18 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:459
+bool CoversTheWholeType =
+(Origin.From().isMinSignedValue() || Origin.To().isMaxValue());
+

vsavchenko wrote:
> NoQ wrote:
> > `(Origin.From() + 1).isMinSignedValue()` is another sufficient condition(?)
> I'm sorry, I don't quite get what cases does this check cover.  Can you 
> please explain what you have in mind?
Aha, ok, nvm, a different issue then: For range `[INT_MIN + 1, INT_MAX]`, the 
correct answer should be ``[INT_MIN + 1, INT_MAX]` (which is `[-C, C]` for `C = 
INT_MAX]`) rather than `[INT_MIN, INT_MAX]`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80117



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


[PATCH] D80144: [clang-format] @lefticus just taught the world how to use [[unlikely]] but we forgot to teach clang-format

2020-05-18 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay created this revision.
MyDeveloperDay added reviewers: krasimir, mitchell-stellar, JakeMerdichAMD, 
curdeius, lefticus.
MyDeveloperDay added projects: clang, clang-format.

https://twitter.com/lefticus/status/1262392152950288384?s=20

Jason Turner's (@lefticus) most recent C++ weekly explains the usage of 
[[likely]] and [[unlikely]] in an 'if/else' context in C++ 20

clang-format leaves the code a little messy afterwards..

  if (argc > 5)
[[unlikely]] {
  // ...
}
  else if (argc < 0)
[[likely]] {
  // ...
}
  else
[[likely]] {
  // ...
}

try to improve the situation

  if (argc > 5) [[unlikely]] {
// ...
  } else if (argc < 0) [[likely]] {
// ...
  } else [[likely]] {
// ...
  }




Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D80144

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


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -15849,6 +15849,36 @@
   verifyFormat("operator&&(int(&&)(), class Foo);", Style);
 }
 
+TEST_F(FormatTest, LikelyUnlikely) {
+  FormatStyle Style = getLLVMStyle();
+
+  verifyFormat("if (argc > 5) [[unlikely]] {\n"
+   "  return 29;\n"
+   "}",
+   Style);
+
+  verifyFormat("if (argc > 5) [[likely]] {\n"
+   "  return 29;\n"
+   "}",
+   Style);
+
+  verifyFormat("if (argc > 5) [[unlikely]] {\n"
+   "  return 29;\n"
+   "} else [[likely]] {\n"
+   "  return 42;\n"
+   "}\n",
+   Style);
+
+  verifyFormat("if (argc > 5) [[unlikely]] {\n"
+   "  return 29;\n"
+   "} else if (argc > 10) [[likely]] {\n"
+   "  return 99;\n"
+   "} else {\n"
+   "  return 42;\n"
+   "}\n",
+   Style);
+}
+
 } // namespace
 } // namespace format
 } // namespace clang
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -1954,6 +1954,9 @@
 nextToken();
   if (FormatTok->Tok.is(tok::l_paren))
 parseParens();
+  // handle [[likely]] / [[unlikely]]
+  if (FormatTok->is(tok::l_square))
+parseSquare();
   bool NeedsUnwrappedLine = false;
   if (FormatTok->Tok.is(tok::l_brace)) {
 CompoundStatementIndenter Indenter(this, Style, Line->Level);
@@ -1970,6 +1973,9 @@
   }
   if (FormatTok->Tok.is(tok::kw_else)) {
 nextToken();
+// handle [[likely]] / [[unlikely]]
+if (FormatTok->is(tok::l_square))
+  parseSquare();
 if (FormatTok->Tok.is(tok::l_brace)) {
   CompoundStatementIndenter Indenter(this, Style, Line->Level);
   parseBlock(/*MustBeDeclaration=*/false);


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -15849,6 +15849,36 @@
   verifyFormat("operator&&(int(&&)(), class Foo);", Style);
 }
 
+TEST_F(FormatTest, LikelyUnlikely) {
+  FormatStyle Style = getLLVMStyle();
+
+  verifyFormat("if (argc > 5) [[unlikely]] {\n"
+   "  return 29;\n"
+   "}",
+   Style);
+
+  verifyFormat("if (argc > 5) [[likely]] {\n"
+   "  return 29;\n"
+   "}",
+   Style);
+
+  verifyFormat("if (argc > 5) [[unlikely]] {\n"
+   "  return 29;\n"
+   "} else [[likely]] {\n"
+   "  return 42;\n"
+   "}\n",
+   Style);
+
+  verifyFormat("if (argc > 5) [[unlikely]] {\n"
+   "  return 29;\n"
+   "} else if (argc > 10) [[likely]] {\n"
+   "  return 99;\n"
+   "} else {\n"
+   "  return 42;\n"
+   "}\n",
+   Style);
+}
+
 } // namespace
 } // namespace format
 } // namespace clang
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -1954,6 +1954,9 @@
 nextToken();
   if (FormatTok->Tok.is(tok::l_paren))
 parseParens();
+  // handle [[likely]] / [[unlikely]]
+  if (FormatTok->is(tok::l_square))
+parseSquare();
   bool NeedsUnwrappedLine = false;
   if (FormatTok->Tok.is(tok::l_brace)) {
 CompoundStatementIndenter Indenter(this, Style, Line->Level);
@@ -1970,6 +1973,9 @@
   }
   if (FormatTok->Tok.is(tok::kw_else)) {
 nextToken();
+// handle [[likely]] / [[unlikely]]
+if (FormatTok->is(tok::l_square))
+  parseSquare();
 if (FormatTok->Tok.is(tok::l_brace)) {
   CompoundStatementIndenter Indenter(this, 

[PATCH] D68049: Propeller: Clang options for basic block sections

2020-05-18 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

Clang side LG with some minor changes.




Comment at: clang/docs/ClangCommandLineReference.rst:1336
+
+Generate labels for each basic block or place each basic block or a subset of 
basic blocks in its own section
+

This file is automatically generated from the .td file; this text will be lost 
when the file is auto-generated. To include a custom description here, it 
should be specified as a `DocBrief` annotation on the option. (Otherwise we 
default to using the `HelpText`.)



Comment at: clang/docs/UsersManual.rst:1704
+  Controls whether Clang emits a label for each basic block.  Further, with
+  values "all" and "list=arg", each basic block or a subset of basic blocks
+  can be placed in its own unique section.

Please either explain here or link to an explanation elsewhere of what "arg" is 
and how to format it.



Comment at: clang/lib/CodeGen/BackendUtil.cpp:503-504
+if (!MBOrErr)
+  errs() << "Error loading basic block sections function list file: "
+ << MBOrErr.getError().message() << "\n";
+else

rsmith wrote:
> Please emit a proper diagnostic for this rather than writing to stderr 
> directly. We should be able to pass the `DiagnosticsEngine` into here.
Can you register a regular diagnostic message for this (it looks like we 
register CodeGen diagnostics in include/clang/Basic/DiagnosticFrontendKinds.td) 
rather than emitting a custom diagnostic?


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

https://reviews.llvm.org/D68049



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


Re: [PATCH] D79595: Fix bugs when an included file name is typo corrected.

2020-05-18 Thread Hans Wennborg via cfe-commits
+thakis who I think fell off the cc list

On Thu, May 14, 2020 at 12:51 AM Abhinav Gaba via Phabricator
 wrote:
>
> abhinavgaba added inline comments.
>
>
> 
> Comment at: clang/test/Lexer/case-insensitive-include-win.c:8
>  // RUN: touch %t.dir/foo.h
> -// RUN: not %clang_cl /FI\\?\%t.dir\FOO.h /WX -Xclang -verify -fsyntax-only 
> %s 2>&1 | FileCheck %s
> +// RUN: not %clang_cl /FI\\?\%t.dir\FOO.h /WX -fsyntax-only %s 2>&1 | 
> FileCheck %s
>
> 
> abhinavgaba wrote:
> > The test is currently failing if path of an existing directory in a network 
> > mounted drive, using forward slashes, is in CPATH. (e.g. `export 
> > CPATH=//abc.def.com/dir1`).
> >
> > The error in that case is:
> > ```
> > fatal error: cannot open file
> >   
> > '//abc.def.com/dir1\?\\test\Lexer\Output\case-insensitive-include-win.c.tmp.dir\FOO.h':
> >   The specified path is invalid.
> > ```
> >
> Did you get a chance to look at this?
>
>
> Repository:
>   rG LLVM Github Monorepo
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D79595/new/
>
> https://reviews.llvm.org/D79595
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


  1   2   >