[PATCH] D58106: [compiler-rt] [profile] Provide lprofGetHostName for all windows environments

2019-02-12 Thread Martin Storsjö via Phabricator via cfe-commits
mstorsjo created this revision.
mstorsjo added reviewers: rnk, compnerd.
Herald added subscribers: Sanitizers, llvm-commits, jdoerfert, dberris.
Herald added projects: LLVM, Sanitizers.

This function doesn't use anything MSVC specific but works fine for any 
`_WIN32` target.


Repository:
  rCRT Compiler Runtime

https://reviews.llvm.org/D58106

Files:
  lib/profile/InstrProfilingUtil.c


Index: lib/profile/InstrProfilingUtil.c
===
--- lib/profile/InstrProfilingUtil.c
+++ lib/profile/InstrProfilingUtil.c
@@ -81,7 +81,7 @@
 
 #endif
 
-#ifdef _MSC_VER
+#ifdef _WIN32
 COMPILER_RT_VISIBILITY int lprofGetHostName(char *Name, int Len) {
   WCHAR Buffer[COMPILER_RT_MAX_HOSTLEN];
   DWORD BufferSize = sizeof(Buffer);


Index: lib/profile/InstrProfilingUtil.c
===
--- lib/profile/InstrProfilingUtil.c
+++ lib/profile/InstrProfilingUtil.c
@@ -81,7 +81,7 @@
 
 #endif
 
-#ifdef _MSC_VER
+#ifdef _WIN32
 COMPILER_RT_VISIBILITY int lprofGetHostName(char *Name, int Len) {
   WCHAR Buffer[COMPILER_RT_MAX_HOSTLEN];
   DWORD BufferSize = sizeof(Buffer);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r353495 - Variable auto-init: fix __block initialization

2019-02-12 Thread Hans Wennborg via cfe-commits
Merged to release_80 in r353807.

On Fri, Feb 8, 2019 at 2:28 AM JF Bastien via cfe-commits
 wrote:
>
> Author: jfb
> Date: Thu Feb  7 17:29:17 2019
> New Revision: 353495
>
> URL: http://llvm.org/viewvc/llvm-project?rev=353495&view=rev
> Log:
> Variable auto-init: fix __block initialization
>
> Summary:
> Automatic initialization [1] of __block variables was trampling over the 
> block's
> headers after they'd been initialized, which caused self-init usage to crash,
> such as here:
>
>   typedef struct XYZ { void (^block)(); } *xyz_t;
>   __attribute__((noinline))
>   xyz_t create(void (^block)()) {
> xyz_t myself = malloc(sizeof(struct XYZ));
> myself->block = block;
> return myself;
>   }
>   int main() {
> __block xyz_t captured = create(^(){ (void)captured; });
>   }
>
> This type of code shouldn't be broken by variable auto-init, even if it's
> sketchy.
>
> [1] With -ftrivial-auto-var-init=pattern
>
> 
>
> Reviewers: rjmccall, pcc, kcc
>
> Subscribers: jkorous, dexonsmith, cfe-commits
>
> Tags: #clang
>
> Differential Revision: https://reviews.llvm.org/D57797
>
> Modified:
> cfe/trunk/lib/CodeGen/CGDecl.cpp
> cfe/trunk/test/CodeGenCXX/trivial-auto-var-init.cpp
>
> Modified: cfe/trunk/lib/CodeGen/CGDecl.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDecl.cpp?rev=353495&r1=353494&r2=353495&view=diff
> ==
> --- cfe/trunk/lib/CodeGen/CGDecl.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDecl.cpp Thu Feb  7 17:29:17 2019
> @@ -1633,11 +1633,15 @@ void CodeGenFunction::EmitAutoVarInit(co
>? LangOptions::TrivialAutoVarInitKind::Uninitialized
>: getContext().getLangOpts().getTrivialAutoVarInit()));
>
> -  auto initializeWhatIsTechnicallyUninitialized = [&]() {
> +  auto initializeWhatIsTechnicallyUninitialized = [&](Address Loc) {
>  if (trivialAutoVarInit ==
>  LangOptions::TrivialAutoVarInitKind::Uninitialized)
>return;
>
> +// Only initialize a __block's storage: we always initialize the header.
> +if (emission.IsEscapingByRef)
> +  Loc = emitBlockByrefAddress(Loc, &D, /*follow=*/false);
> +
>  CharUnits Size = getContext().getTypeSizeInChars(type);
>  if (!Size.isZero()) {
>switch (trivialAutoVarInit) {
> @@ -1714,7 +1718,7 @@ void CodeGenFunction::EmitAutoVarInit(co
>};
>
>if (isTrivialInitializer(Init)) {
> -initializeWhatIsTechnicallyUninitialized();
> +initializeWhatIsTechnicallyUninitialized(Loc);
>  return;
>}
>
> @@ -1728,7 +1732,7 @@ void CodeGenFunction::EmitAutoVarInit(co
>}
>
>if (!constant) {
> -initializeWhatIsTechnicallyUninitialized();
> +initializeWhatIsTechnicallyUninitialized(Loc);
>  LValue lv = MakeAddrLValue(Loc, type);
>  lv.setNonGC(true);
>  return EmitExprAsInit(Init, &D, lv, capturedByInit);
>
> Modified: cfe/trunk/test/CodeGenCXX/trivial-auto-var-init.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/trivial-auto-var-init.cpp?rev=353495&r1=353494&r2=353495&view=diff
> ==
> --- cfe/trunk/test/CodeGenCXX/trivial-auto-var-init.cpp (original)
> +++ cfe/trunk/test/CodeGenCXX/trivial-auto-var-init.cpp Thu Feb  7 17:29:17 
> 2019
> @@ -30,6 +30,32 @@ void test_block() {
>used(block);
>  }
>
> +// Using the variable being initialized is typically UB in C, but for blocks 
> we
> +// can be nice: they imply extra book-keeping and we can do the auto-init 
> before
> +// any of said book-keeping.
> +//
> +// UNINIT-LABEL:  test_block_self_init(
> +// ZERO-LABEL:test_block_self_init(
> +// ZERO:  %block = alloca <{ i8*, i32, i32, i8*, 
> %struct.__block_descriptor*, i8* }>, align 8
> +// ZERO:  %captured1 = getelementptr inbounds 
> %struct.__block_byref_captured, %struct.__block_byref_captured* %captured, 
> i32 0, i32 4
> +// ZERO-NEXT: store %struct.XYZ* null, %struct.XYZ** %captured1, align 8
> +// ZERO:  %call = call %struct.XYZ* @create(
> +// PATTERN-LABEL: test_block_self_init(
> +// PATTERN:   %block = alloca <{ i8*, i32, i32, i8*, 
> %struct.__block_descriptor*, i8* }>, align 8
> +// PATTERN:   %captured1 = getelementptr inbounds 
> %struct.__block_byref_captured, %struct.__block_byref_captured* %captured, 
> i32 0, i32 4
> +// PATTERN-NEXT:  store %struct.XYZ* inttoptr (i64 -6148914691236517206 to 
> %struct.XYZ*), %struct.XYZ** %captured1, align 8
> +// PATTERN:   %call = call %struct.XYZ* @create(
> +void test_block_self_init() {
> +  using Block = void (^)();
> +  typedef struct XYZ {
> +Block block;
> +  } * xyz_t;
> +  extern xyz_t create(Block block);
> +  __block xyz_t captured = create(^() {
> +(void)captured;
> +  });
> +}
> +
>  // This type of code is currently not handled by zero / pattern 
> initialization.
>  // The test will break when that is fixed.

[PATCH] D57984: PR40642: Fix determination of whether the final statement of a statementexpression is a discarded-value expression.

2019-02-12 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.
Herald added a subscriber: jdoerfert.

In D57984#1394167 , @rsmith wrote:

> In D57984#1394067 , @ABataev wrote:
>
> > In D57984#1394050 , @rsmith wrote:
> >
> > > @ABataev Is it intentional that we do not propagate `Allowed` through 
> > > labels? For example:
> > >
> > >   void f() {
> > > #pragma omp barrier // ok
> > >  
> > >   label:
> > > #pragma omp barrier // error, "cannot be an immediate substatement"
> > >  
> > >   label:
> > > ;
> > > #pragma omp barrier // ok
> > >   }
> > >
> > >
> > > ?
> >
> >
> > No, it is a bug.
>
>
> Great, then I'll unify this new flag with the `Allowed` mechanism and fix the 
> bug as part of this change. Thanks!


Sure, thanks!


Repository:
  rC Clang

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

https://reviews.llvm.org/D57984



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


[PATCH] D57427: [CodeGen][ObjC] Fix assert on calling `__builtin_constant_p` with ObjC objects.

2019-02-12 Thread Hans Wennborg via Phabricator via cfe-commits
hans added a comment.
Herald added a subscriber: jdoerfert.

> Also looks like in practice it shouldn't be a serious problem, 
> `__builtin_constant_p` can be optimized out. For example, see 
> https://godbolt.org/z/e1b4dB

Okay, I'm not going to worry about it then. Thanks.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D57427



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


[PATCH] D41005: Reuse preamble even if an unsaved file does not exist

2019-02-12 Thread Nikolai Kosjar via Phabricator via cfe-commits
nik updated this revision to Diff 186429.
nik marked an inline comment as done.
nik added a comment.
Herald added a subscriber: jdoerfert.
Herald added a project: clang.

Addressed comment.


Repository:
  rC Clang

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

https://reviews.llvm.org/D41005

Files:
  include/clang/Frontend/ASTUnit.h
  lib/Frontend/ASTUnit.cpp
  lib/Frontend/PrecompiledPreamble.cpp
  unittests/Frontend/PCHPreambleTest.cpp

Index: unittests/Frontend/PCHPreambleTest.cpp
===
--- unittests/Frontend/PCHPreambleTest.cpp
+++ unittests/Frontend/PCHPreambleTest.cpp
@@ -52,7 +52,10 @@
   FileSystemOptions FSOpts;
 
 public:
-  void SetUp() override {
+  void SetUp() override { ResetVFS(); }
+  void TearDown() override {}
+
+  void ResetVFS() {
 VFS = new ReadCountingInMemoryFileSystem();
 // We need the working directory to be set to something absolute,
 // otherwise it ends up being inadvertently set to the current
@@ -63,9 +66,6 @@
 VFS->setCurrentWorkingDirectory("//./");
   }
 
-  void TearDown() override {
-  }
-
   void AddFile(const std::string &Filename, const std::string &Contents) {
 ::time_t now;
 ::time(&now);
@@ -123,6 +123,72 @@
   }
 };
 
+TEST_F(PCHPreambleTest, ReparseReusesPreambleWithUnsavedFileNotExistingOnDisk) {
+  std::string Header1 = "//./header1.h";
+  std::string MainName = "//./main.cpp";
+  AddFile(MainName, R"cpp(
+#include "//./header1.h"
+int main() { return ZERO; }
+)cpp");
+  RemapFile(Header1, "#define ZERO 0\n");
+
+  // Parse with header file provided as unsaved file, which does not exist on
+  // disk.
+  std::unique_ptr AST(ParseAST(MainName));
+  ASSERT_TRUE(AST.get());
+  ASSERT_FALSE(AST->getDiagnostics().hasErrorOccurred());
+
+  // Reparse and check that the preamble was reused.
+  ASSERT_TRUE(ReparseAST(AST));
+  ASSERT_EQ(AST->getPreambleCounterForTests(), 1U);
+}
+
+TEST_F(PCHPreambleTest, ReparseReusesPreambleAfterUnsavedFileWasCreatedOnDisk) {
+  std::string Header1 = "//./header1.h";
+  std::string MainName = "//./main.cpp";
+  AddFile(MainName, R"cpp(
+#include "//./header1.h"
+int main() { return ZERO; }
+)cpp");
+  RemapFile(Header1, "#define ZERO 0\n");
+
+  // Parse with header file provided as unsaved file, which does not exist on
+  // disk.
+  std::unique_ptr AST(ParseAST(MainName));
+  ASSERT_TRUE(AST.get());
+  ASSERT_FALSE(AST->getDiagnostics().hasErrorOccurred());
+
+  // Create the unsaved file also on disk and check that preamble was reused.
+  AddFile(Header1, "#define ZERO 0\n");
+  ASSERT_TRUE(ReparseAST(AST));
+  ASSERT_EQ(AST->getPreambleCounterForTests(), 1U);
+}
+
+TEST_F(PCHPreambleTest,
+   ReparseReusesPreambleAfterUnsavedFileWasRemovedFromDisk) {
+  std::string Header1 = "//./foo/header1.h";
+  std::string MainName = "//./main.cpp";
+  std::string MainFileContent = R"cpp(
+#include "//./header1.h"
+int main() { return ZERO; }
+)cpp";
+  AddFile(MainName, MainFileContent);
+  AddFile(Header1, "#define ZERO 0\n");
+  RemapFile(Header1, "#define ZERO 0\n");
+
+  // Parse with header file provided as unsaved file, which exists on disk.
+  std::unique_ptr AST(ParseAST(MainName));
+  ASSERT_TRUE(AST.get());
+  ASSERT_FALSE(AST->getDiagnostics().hasErrorOccurred());
+  ASSERT_EQ(AST->getPreambleCounterForTests(), 1U);
+
+  // Remove the unsaved file from disk and check that the preamble was reused.
+  ResetVFS();
+  AddFile(MainName, MainFileContent);
+  ASSERT_TRUE(ReparseAST(AST));
+  ASSERT_EQ(AST->getPreambleCounterForTests(), 1U);
+}
+
 TEST_F(PCHPreambleTest, ReparseWithOverriddenFileDoesNotInvalidatePreamble) {
   std::string Header1 = "//./header1.h";
   std::string Header2 = "//./header2.h";
Index: lib/Frontend/PrecompiledPreamble.cpp
===
--- lib/Frontend/PrecompiledPreamble.cpp
+++ lib/Frontend/PrecompiledPreamble.cpp
@@ -28,6 +28,7 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Mutex.h"
 #include "llvm/Support/MutexGuard.h"
+#include "llvm/Support/Path.h"
 #include "llvm/Support/Process.h"
 #include "llvm/Support/VirtualFileSystem.h"
 #include 
@@ -451,20 +452,32 @@
 Status.getSize(), llvm::sys::toTimeT(Status.getLastModificationTime()));
   }
 
+  llvm::StringMap OverridenFileBuffers;
   for (const auto &RB : PreprocessorOpts.RemappedFileBuffers) {
-llvm::vfs::Status Status;
-if (!moveOnNoError(VFS->status(RB.first), Status))
-  return false;
-
-OverriddenFiles[Status.getUniqueID()] =
+const PrecompiledPreamble::PreambleFileHash PreambleHash =
 PreambleFileHash::createForMemoryBuffer(RB.second);
+llvm::vfs::Status Status;
+if (moveOnNoError(VFS->status(RB.first), Status))
+  OverriddenFiles[Status.getUniqueID()] = PreambleHash;
+else
+  OverridenFileBuffers[RB.first] = PreambleHash;
   }
 
   // Check whether anything has changed.
   for (const auto &F : FilesInPreamble) {
+

[clang-tools-extra] r353821 - [clangd] Fix use-after-free in XRefs

2019-02-12 Thread Sam McCall via cfe-commits
Author: sammccall
Date: Tue Feb 12 02:38:45 2019
New Revision: 353821

URL: http://llvm.org/viewvc/llvm-project?rev=353821&view=rev
Log:
[clangd] Fix use-after-free in XRefs

Modified:
clang-tools-extra/trunk/clangd/XRefs.cpp

Modified: clang-tools-extra/trunk/clangd/XRefs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/XRefs.cpp?rev=353821&r1=353820&r2=353821&view=diff
==
--- clang-tools-extra/trunk/clangd/XRefs.cpp (original)
+++ clang-tools-extra/trunk/clangd/XRefs.cpp Tue Feb 12 02:38:45 2019
@@ -92,19 +92,18 @@ SymbolLocation toIndexLocation(const Loc
 
 // Returns the preferred location between an AST location and an index 
location.
 SymbolLocation getPreferredLocation(const Location &ASTLoc,
-const SymbolLocation &IdxLoc) {
+const SymbolLocation &IdxLoc,
+std::string &Scratch) {
   // Also use a dummy symbol for the index location so that other fields (e.g.
   // definition) are not factored into the preferrence.
   Symbol ASTSym, IdxSym;
   ASTSym.ID = IdxSym.ID = SymbolID("dummy_id");
-  std::string URIStore;
-  ASTSym.CanonicalDeclaration = toIndexLocation(ASTLoc, URIStore);
+  ASTSym.CanonicalDeclaration = toIndexLocation(ASTLoc, Scratch);
   IdxSym.CanonicalDeclaration = IdxLoc;
   auto Merged = mergeSymbol(ASTSym, IdxSym);
   return Merged.CanonicalDeclaration;
 }
 
-
 struct MacroDecl {
   llvm::StringRef Name;
   const MacroInfo *Info;
@@ -352,6 +351,7 @@ std::vector locateSymbolA
 LookupRequest QueryRequest;
 for (auto It : ResultIndex)
   QueryRequest.IDs.insert(It.first);
+std::string Scratch;
 Index->lookup(QueryRequest, [&](const Symbol &Sym) {
   auto &R = Result[ResultIndex.lookup(Sym.ID)];
 
@@ -367,10 +367,10 @@ std::vector locateSymbolA
   // Use merge logic to choose AST or index declaration.
   // We only do this for declarations as definitions from AST
   // is generally preferred (e.g. definitions in main file).
-  if (auto Loc =
-  toLSPLocation(getPreferredLocation(R.PreferredDeclaration,
- Sym.CanonicalDeclaration),
-*MainFilePath))
+  if (auto Loc = toLSPLocation(
+  getPreferredLocation(R.PreferredDeclaration,
+   Sym.CanonicalDeclaration, Scratch),
+  *MainFilePath))
 R.PreferredDeclaration = *Loc;
 }
   }


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


[PATCH] D58111: [Sema] Fix a crash in access checking for deduction guides

2019-02-12 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov created this revision.
ilya-biryukov added a reviewer: sammccall.
Herald added a project: clang.

See the added test for a repro.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D58111

Files:
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/Sema/crash-deduction-guide-access.cpp


Index: clang/test/Sema/crash-deduction-guide-access.cpp
===
--- /dev/null
+++ clang/test/Sema/crash-deduction-guide-access.cpp
@@ -0,0 +1,11 @@
+// RUN: not %clang_cc1 -x c++ -std=c++17 -fsyntax-only %s
+template 
+class Imp {
+  template 
+  explicit Imp(F f);
+};
+
+template 
+class Cls {
+  explicit Imp() : f() {}
+};
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -3175,7 +3175,11 @@
 //   declared] with the same access [as the template].
 if (auto *DG = dyn_cast(NonTemplateMember)) {
   auto *TD = DG->getDeducedTemplate();
-  if (AS != TD->getAccess()) {
+  bool InSameScope = TD->getDeclContext()->getRedeclContext()->Equals(
+  DG->getDeclContext()->getRedeclContext());
+  // Access specifiers are only meaningful if both the template and the
+  // deduction guide are from the same scope.
+  if (InSameScope && AS != TD->getAccess()) {
 Diag(DG->getBeginLoc(), diag::err_deduction_guide_wrong_access);
 Diag(TD->getBeginLoc(), diag::note_deduction_guide_template_access)
 << TD->getAccess();


Index: clang/test/Sema/crash-deduction-guide-access.cpp
===
--- /dev/null
+++ clang/test/Sema/crash-deduction-guide-access.cpp
@@ -0,0 +1,11 @@
+// RUN: not %clang_cc1 -x c++ -std=c++17 -fsyntax-only %s
+template 
+class Imp {
+  template 
+  explicit Imp(F f);
+};
+
+template 
+class Cls {
+  explicit Imp() : f() {}
+};
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -3175,7 +3175,11 @@
 //   declared] with the same access [as the template].
 if (auto *DG = dyn_cast(NonTemplateMember)) {
   auto *TD = DG->getDeducedTemplate();
-  if (AS != TD->getAccess()) {
+  bool InSameScope = TD->getDeclContext()->getRedeclContext()->Equals(
+  DG->getDeclContext()->getRedeclContext());
+  // Access specifiers are only meaningful if both the template and the
+  // deduction guide are from the same scope.
+  if (InSameScope && AS != TD->getAccess()) {
 Diag(DG->getBeginLoc(), diag::err_deduction_guide_wrong_access);
 Diag(TD->getBeginLoc(), diag::note_deduction_guide_template_access)
 << TD->getAccess();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D41005: Reuse preamble even if an unsaved file does not exist

2019-02-12 Thread Nikolai Kosjar via Phabricator via cfe-commits
nik added a comment.

Meh, something changed in the meanwhile. 
ReparseReusesPreambleAfterUnsavedFileWasRemovedFromDisk fails now. Looking into 
it.


Repository:
  rC Clang

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

https://reviews.llvm.org/D41005



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


Re: r353411 - Fix r350643 to limit COFF emission to <= 32 BYTES instead of BITS.

2019-02-12 Thread Hans Wennborg via cfe-commits
Merged to 8.0 in r353825.

On Thu, Feb 7, 2019 at 4:13 PM Erich Keane via cfe-commits
 wrote:
>
> Author: erichkeane
> Date: Thu Feb  7 07:14:11 2019
> New Revision: 353411
>
> URL: http://llvm.org/viewvc/llvm-project?rev=353411&view=rev
> Log:
> Fix r350643 to limit COFF emission to <= 32 BYTES instead of BITS.
>
> The patch in r350643 incorrectly sets the COFF emission based on bits
> instead of bytes. This patch converts the 32 via CharUnits to bits to
> compare the correct values.
>
> Change-Id: Icf38a16470ad5ae3531374969c033557ddb0d323
>
> Modified:
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/test/CodeGen/microsoft-no-common-align.c
>
> Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=353411&r1=353410&r2=353411&view=diff
> ==
> --- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Thu Feb  7 07:14:11 2019
> @@ -3775,13 +3775,15 @@ static bool isVarDeclStrongDefinition(co
>  }
>}
>
> -  // Microsoft's link.exe doesn't support alignments greater than 32 for 
> common
> -  // symbols, so symbols with greater alignment requirements cannot be 
> common.
> +  // Microsoft's link.exe doesn't support alignments greater than 32 bytes 
> for
> +  // common symbols, so symbols with greater alignment requirements cannot be
> +  // common.
>// Other COFF linkers (ld.bfd and LLD) support arbitrary power-of-two
>// alignments for common symbols via the aligncomm directive, so this
>// restriction only applies to MSVC environments.
>if (Context.getTargetInfo().getTriple().isKnownWindowsMSVCEnvironment() &&
> -  Context.getTypeAlignIfKnown(D->getType()) > 32)
> +  Context.getTypeAlignIfKnown(D->getType()) >
> +  Context.toBits(CharUnits::fromQuantity(32)))
>  return true;
>
>return false;
>
> Modified: cfe/trunk/test/CodeGen/microsoft-no-common-align.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/microsoft-no-common-align.c?rev=353411&r1=353410&r2=353411&view=diff
> ==
> --- cfe/trunk/test/CodeGen/microsoft-no-common-align.c (original)
> +++ cfe/trunk/test/CodeGen/microsoft-no-common-align.c Thu Feb  7 07:14:11 
> 2019
> @@ -6,3 +6,6 @@ TooLargeAlignment TooBig;
>  // CHECK: @TooBig = dso_local global <16 x float>  zeroinitializer, align 64
>  NormalAlignment JustRight;
>  // CHECK: @JustRight = common dso_local global <1 x float>  zeroinitializer, 
> align 4
> +
> +TooLargeAlignment *IsAPointer;
> +// CHECK: @IsAPointer = common dso_local global <16 x float>* null, align 8
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D58111: [Sema] Fix a crash in access checking for deduction guides

2019-02-12 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/SemaDeclCXX.cpp:3178
   auto *TD = DG->getDeducedTemplate();
-  if (AS != TD->getAccess()) {
+  bool InSameScope = TD->getDeclContext()->getRedeclContext()->Equals(
+  DG->getDeclContext()->getRedeclContext());

this isn't quite trivial, you might want to short circuit with &&, checking AS 
!= TD->getAccess() first?
I don't think readability is too bad if you keep the existing comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D58111



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


Re: r353431 - [OpenCL][PR40603] In C++ preserve compatibility with OpenCL C v2.0

2019-02-12 Thread Hans Wennborg via cfe-commits
Merged to 8.0 in r353826.

On Thu, Feb 7, 2019 at 6:32 PM Anastasia Stulova via cfe-commits
 wrote:
>
> Author: stulova
> Date: Thu Feb  7 09:32:37 2019
> New Revision: 353431
>
> URL: http://llvm.org/viewvc/llvm-project?rev=353431&view=rev
> Log:
> [OpenCL][PR40603] In C++ preserve compatibility with OpenCL C v2.0
>
> Valid OpenCL C code should still compile in C++ mode.
>
> This change enables extensions and OpenCL types.
>
> Differential Revision: https://reviews.llvm.org/D57824
>
>
> Modified:
> cfe/trunk/include/clang/Basic/OpenCLOptions.h
> cfe/trunk/lib/Frontend/InitPreprocessor.cpp
> cfe/trunk/lib/Parse/ParsePragma.cpp
> cfe/trunk/lib/Sema/Sema.cpp
> cfe/trunk/test/SemaOpenCL/extension-version.cl
> cfe/trunk/test/SemaOpenCL/extensions.cl
>
> Modified: cfe/trunk/include/clang/Basic/OpenCLOptions.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/OpenCLOptions.h?rev=353431&r1=353430&r2=353431&view=diff
> ==
> --- cfe/trunk/include/clang/Basic/OpenCLOptions.h (original)
> +++ cfe/trunk/include/clang/Basic/OpenCLOptions.h Thu Feb  7 09:32:37 2019
> @@ -14,6 +14,7 @@
>  #ifndef LLVM_CLANG_BASIC_OPENCLOPTIONS_H
>  #define LLVM_CLANG_BASIC_OPENCLOPTIONS_H
>
> +#include "clang/Basic/LangOptions.h"
>  #include "llvm/ADT/StringMap.h"
>
>  namespace clang {
> @@ -41,25 +42,29 @@ public:
>
>// Is supported as either an extension or an (optional) core feature for
>// OpenCL version \p CLVer.
> -  bool isSupported(llvm::StringRef Ext, unsigned CLVer) const {
> +  bool isSupported(llvm::StringRef Ext, LangOptions LO) const {
> +// In C++ mode all extensions should work at least as in v2.0.
> +auto CLVer = LO.OpenCLCPlusPlus ? 200 : LO.OpenCLVersion;
>  auto I = OptMap.find(Ext)->getValue();
>  return I.Supported && I.Avail <= CLVer;
>}
>
>// Is supported (optional) OpenCL core features for OpenCL version \p 
> CLVer.
>// For supported extension, return false.
> -  bool isSupportedCore(llvm::StringRef Ext, unsigned CLVer) const {
> +  bool isSupportedCore(llvm::StringRef Ext, LangOptions LO) const {
> +// In C++ mode all extensions should work at least as in v2.0.
> +auto CLVer = LO.OpenCLCPlusPlus ? 200 : LO.OpenCLVersion;
>  auto I = OptMap.find(Ext)->getValue();
> -return I.Supported && I.Avail <= CLVer &&
> -  I.Core != ~0U && CLVer >= I.Core;
> +return I.Supported && I.Avail <= CLVer && I.Core != ~0U && CLVer >= 
> I.Core;
>}
>
>// Is supported OpenCL extension for OpenCL version \p CLVer.
>// For supported (optional) core feature, return false.
> - bool isSupportedExtension(llvm::StringRef Ext, unsigned CLVer) const {
> +  bool isSupportedExtension(llvm::StringRef Ext, LangOptions LO) const {
> +// In C++ mode all extensions should work at least as in v2.0.
> +auto CLVer = LO.OpenCLCPlusPlus ? 200 : LO.OpenCLVersion;
>  auto I = OptMap.find(Ext)->getValue();
> -return I.Supported && I.Avail <= CLVer &&
> -  (I.Core == ~0U || CLVer < I.Core);
> +return I.Supported && I.Avail <= CLVer && (I.Core == ~0U || CLVer < 
> I.Core);
>}
>
>void enable(llvm::StringRef Ext, bool V = true) {
> @@ -121,10 +126,10 @@ public:
>I->second.Enabled = false;
>}
>
> -  void enableSupportedCore(unsigned CLVer) {
> -for (llvm::StringMap::iterator I = OptMap.begin(),
> - E = OptMap.end(); I != E; ++I)
> -  if (isSupportedCore(I->getKey(), CLVer))
> +  void enableSupportedCore(LangOptions LO) {
> +for (llvm::StringMap::iterator I = OptMap.begin(), E = 
> OptMap.end();
> + I != E; ++I)
> +  if (isSupportedCore(I->getKey(), LO))
>  I->second.Enabled = true;
>}
>
> @@ -132,6 +137,6 @@ public:
>friend class ASTReader;
>  };
>
> -}  // end namespace clang
> +} // end namespace clang
>
>  #endif
>
> Modified: cfe/trunk/lib/Frontend/InitPreprocessor.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/InitPreprocessor.cpp?rev=353431&r1=353430&r2=353431&view=diff
> ==
> --- cfe/trunk/lib/Frontend/InitPreprocessor.cpp (original)
> +++ cfe/trunk/lib/Frontend/InitPreprocessor.cpp Thu Feb  7 09:32:37 2019
> @@ -1058,10 +1058,9 @@ static void InitializePredefinedMacros(c
>
>// OpenCL definitions.
>if (LangOpts.OpenCL) {
> -#define OPENCLEXT(Ext) \
> -if (TI.getSupportedOpenCLOpts().isSupported(#Ext, \
> -LangOpts.OpenCLVersion)) \
> -  Builder.defineMacro(#Ext);
> +#define OPENCLEXT(Ext)   
>   \
> +  if (TI.getSupportedOpenCLOpts().isSupported(#Ext, LangOpts))   
>   \
> +Builder.defineMacro(#Ext);
>  #include "clang/Basic/OpenCLExtensions.def"
>
>  auto Arch = TI.getTriple().getArch();
>
> Modified: cfe/trunk/lib/Parse/ParsePragma.cpp
> URL: 
> http://llvm.org/viewvc/llvm

Re: r353493 - [COFF, ARM64] Fix types for _ReadStatusReg, _WriteStatusReg

2019-02-12 Thread Hans Wennborg via cfe-commits
Merged to 8.0 in r353828.

On Fri, Feb 8, 2019 at 2:17 AM Eli Friedman via cfe-commits
 wrote:
>
> Author: efriedma
> Date: Thu Feb  7 17:17:49 2019
> New Revision: 353493
>
> URL: http://llvm.org/viewvc/llvm-project?rev=353493&view=rev
> Log:
> [COFF, ARM64] Fix types for _ReadStatusReg, _WriteStatusReg
>
> r344765 added those intrinsics, but used the wrong types.
>
> Patch by Mike Hommey
>
> Differential Revision: https://reviews.llvm.org/D57636
>
>
> Modified:
> cfe/trunk/include/clang/Basic/BuiltinsAArch64.def
> cfe/trunk/lib/CodeGen/CGBuiltin.cpp
> cfe/trunk/lib/Headers/intrin.h
> cfe/trunk/test/CodeGen/arm64-microsoft-status-reg.cpp
>
> Modified: cfe/trunk/include/clang/Basic/BuiltinsAArch64.def
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsAArch64.def?rev=353493&r1=353492&r2=353493&view=diff
> ==
> --- cfe/trunk/include/clang/Basic/BuiltinsAArch64.def (original)
> +++ cfe/trunk/include/clang/Basic/BuiltinsAArch64.def Thu Feb  7 17:17:49 2019
> @@ -203,8 +203,8 @@ TARGET_HEADER_BUILTIN(_InterlockedDecrem
>
>  TARGET_HEADER_BUILTIN(_ReadWriteBarrier, "v", "nh", "intrin.h", 
> ALL_MS_LANGUAGES, "")
>  TARGET_HEADER_BUILTIN(__getReg, "ULLii", "nh", "intrin.h", ALL_MS_LANGUAGES, 
> "")
> -TARGET_HEADER_BUILTIN(_ReadStatusReg,  "ii",  "nh", "intrin.h", 
> ALL_MS_LANGUAGES, "")
> -TARGET_HEADER_BUILTIN(_WriteStatusReg, "vii", "nh", "intrin.h", 
> ALL_MS_LANGUAGES, "")
> +TARGET_HEADER_BUILTIN(_ReadStatusReg,  "LLii",  "nh", "intrin.h", 
> ALL_MS_LANGUAGES, "")
> +TARGET_HEADER_BUILTIN(_WriteStatusReg, "viLLi", "nh", "intrin.h", 
> ALL_MS_LANGUAGES, "")
>  TARGET_HEADER_BUILTIN(_AddressOfReturnAddress, "v*", "nh", "intrin.h", 
> ALL_MS_LANGUAGES, "")
>
>  #undef BUILTIN
>
> Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=353493&r1=353492&r2=353493&view=diff
> ==
> --- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Thu Feb  7 17:17:49 2019
> @@ -7076,19 +7076,16 @@ Value *CodeGenFunction::EmitAArch64Built
>  llvm::Value *Metadata = llvm::MetadataAsValue::get(Context, RegName);
>
>  llvm::Type *RegisterType = Int64Ty;
> -llvm::Type *ValueType = Int32Ty;
>  llvm::Type *Types[] = { RegisterType };
>
>  if (BuiltinID == AArch64::BI_ReadStatusReg) {
>llvm::Function *F = CGM.getIntrinsic(llvm::Intrinsic::read_register, 
> Types);
> -  llvm::Value *Call = Builder.CreateCall(F, Metadata);
>
> -  return Builder.CreateTrunc(Call, ValueType);
> +  return Builder.CreateCall(F, Metadata);
>  }
>
>  llvm::Function *F = CGM.getIntrinsic(llvm::Intrinsic::write_register, 
> Types);
>  llvm::Value *ArgValue = EmitScalarExpr(E->getArg(1));
> -ArgValue = Builder.CreateZExt(ArgValue, RegisterType);
>
>  return Builder.CreateCall(F, { Metadata, ArgValue });
>}
>
> Modified: cfe/trunk/lib/Headers/intrin.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/intrin.h?rev=353493&r1=353492&r2=353493&view=diff
> ==
> --- cfe/trunk/lib/Headers/intrin.h (original)
> +++ cfe/trunk/lib/Headers/intrin.h Thu Feb  7 17:17:49 2019
> @@ -554,8 +554,8 @@ __nop(void) {
>  #if defined(__aarch64__)
>  unsigned __int64 __getReg(int);
>  long _InterlockedAdd(long volatile *Addend, long Value);
> -int _ReadStatusReg(int);
> -void _WriteStatusReg(int, int);
> +__int64 _ReadStatusReg(int);
> +void _WriteStatusReg(int, __int64);
>
>  static inline unsigned short _byteswap_ushort (unsigned short val) {
>return __builtin_bswap16(val);
>
> Modified: cfe/trunk/test/CodeGen/arm64-microsoft-status-reg.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/arm64-microsoft-status-reg.cpp?rev=353493&r1=353492&r2=353493&view=diff
> ==
> --- cfe/trunk/test/CodeGen/arm64-microsoft-status-reg.cpp (original)
> +++ cfe/trunk/test/CodeGen/arm64-microsoft-status-reg.cpp Thu Feb  7 17:17:49 
> 2019
> @@ -23,88 +23,112 @@
>  #define ARM64_TPIDRRO_EL0   ARM64_SYSREG(3,3,13, 0,3)  // Thread ID 
> Register, User Read Only [CP15_TPIDRURO]
>  #define ARM64_TPIDR_EL1 ARM64_SYSREG(3,0,13, 0,4)  // Thread ID 
> Register, Privileged Only [CP15_TPIDRPRW]
>
> -void check_ReadWriteStatusReg(int v) {
> -  int ret;
> +// From intrin.h
> +__int64 _ReadStatusReg(int);
> +void _WriteStatusReg(int, __int64);
> +
> +void check_ReadWriteStatusReg(__int64 v) {
> +  __int64 ret;
>ret = _ReadStatusReg(ARM64_CNTVCT);
> -// CHECK-ASM: mrs x8, CNTVCT_EL0
> -// CHECK-IR: call i64 @llvm.read_register.i64(metadata ![[MD2:.*]])
> +// CHECK-ASM: mrs x0, CNTVCT_EL0
> +// CHECK-IR: %[[VAR:.*]] = call i64 @l

Re: r353402 - [clang-cl] support /Oy- on aarch64

2019-02-12 Thread Hans Wennborg via cfe-commits
Merged to 8.0 in r353829.

On Thu, Feb 7, 2019 at 1:46 PM Martin Storsjo via cfe-commits
 wrote:
>
> Author: mstorsjo
> Date: Thu Feb  7 04:46:49 2019
> New Revision: 353402
>
> URL: http://llvm.org/viewvc/llvm-project?rev=353402&view=rev
> Log:
> [clang-cl] support /Oy- on aarch64
>
> MSVC supports /Oy- on aarch64, so clang-cl should too.
>
> Patch by Nathan Froyd!
>
> Differential Revision: https://reviews.llvm.org/D57838
>
> Modified:
> cfe/trunk/lib/Driver/ToolChains/MSVC.cpp
> cfe/trunk/test/Driver/cl-options.c
>
> Modified: cfe/trunk/lib/Driver/ToolChains/MSVC.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/MSVC.cpp?rev=353402&r1=353401&r2=353402&view=diff
> ==
> --- cfe/trunk/lib/Driver/ToolChains/MSVC.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/MSVC.cpp Thu Feb  7 04:46:49 2019
> @@ -1407,10 +1407,10 @@ static void TranslateOptArg(Arg *A, llvm
>DAL.AddFlagArg(
>A, Opts.getOption(options::OPT_fno_omit_frame_pointer));
>} else {
> -// Don't warn about /Oy- in 64-bit builds (where
> +// Don't warn about /Oy- in x86-64 builds (where
>  // SupportsForcingFramePointer is false).  The flag having no effect
>  // there is a compiler-internal optimization, and people shouldn't 
> have
> -// to special-case their build files for 64-bit clang-cl.
> +// to special-case their build files for x86-64 clang-cl.
>  A->claim();
>}
>break;
> @@ -1441,8 +1441,8 @@ MSVCToolChain::TranslateArgs(const llvm:
>DerivedArgList *DAL = new DerivedArgList(Args.getBaseArgs());
>const OptTable &Opts = getDriver().getOpts();
>
> -  // /Oy and /Oy- only has an effect under X86-32.
> -  bool SupportsForcingFramePointer = getArch() == llvm::Triple::x86;
> +  // /Oy and /Oy- don't have an effect on X86-64
> +  bool SupportsForcingFramePointer = getArch() != llvm::Triple::x86_64;
>
>// The -O[12xd] flag actually expands to several flags.  We must desugar 
> the
>// flags so that options embedded can be negated.  For example, the '-O2' 
> flag
>
> Modified: cfe/trunk/test/Driver/cl-options.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cl-options.c?rev=353402&r1=353401&r2=353402&view=diff
> ==
> --- cfe/trunk/test/Driver/cl-options.c (original)
> +++ cfe/trunk/test/Driver/cl-options.c Thu Feb  7 04:46:49 2019
> @@ -178,6 +178,10 @@
>  // Oy_2: -momit-leaf-frame-pointer
>  // Oy_2: -O2
>
> +// RUN: %clang_cl --target=aarch64-pc-windows-msvc -Werror /Oy- /O2 -### -- 
> %s 2>&1 | FileCheck -check-prefix=Oy_aarch64 %s
> +// Oy_aarch64: -mdisable-fp-elim
> +// Oy_aarch64: -O2
> +
>  // RUN: %clang_cl --target=i686-pc-win32 -Werror /O2 /O2 -### -- %s 2>&1 | 
> FileCheck -check-prefix=O2O2 %s
>  // O2O2: "-O2"
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r353656 - long double is double on OpenBSD/NetBSD/PPC.

2019-02-12 Thread Hans Wennborg via cfe-commits
Merged to 8.0 in r353831.

On Mon, Feb 11, 2019 at 3:52 AM Brad Smith via cfe-commits
 wrote:
>
> Author: brad
> Date: Sun Feb 10 18:53:16 2019
> New Revision: 353656
>
> URL: http://llvm.org/viewvc/llvm-project?rev=353656&view=rev
> Log:
> long double is double on OpenBSD/NetBSD/PPC.
>
> Patch by George Koehler.
>
> Modified:
> cfe/trunk/lib/Basic/Targets/PPC.h
> cfe/trunk/test/CodeGen/powerpc_types.c
>
> Modified: cfe/trunk/lib/Basic/Targets/PPC.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/PPC.h?rev=353656&r1=353655&r2=353656&view=diff
> ==
> --- cfe/trunk/lib/Basic/Targets/PPC.h (original)
> +++ cfe/trunk/lib/Basic/Targets/PPC.h Sun Feb 10 18:53:16 2019
> @@ -330,9 +330,15 @@ public:
>break;
>  }
>
> -if (getTriple().isOSFreeBSD()) {
> +switch (getTriple().getOS()) {
> +case llvm::Triple::FreeBSD:
> +case llvm::Triple::NetBSD:
> +case llvm::Triple::OpenBSD:
>LongDoubleWidth = LongDoubleAlign = 64;
>LongDoubleFormat = &llvm::APFloat::IEEEdouble();
> +  break;
> +default:
> +  break;
>  }
>
>  // PPC32 supports atomics up to 4 bytes.
>
> Modified: cfe/trunk/test/CodeGen/powerpc_types.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/powerpc_types.c?rev=353656&r1=353655&r2=353656&view=diff
> ==
> --- cfe/trunk/test/CodeGen/powerpc_types.c (original)
> +++ cfe/trunk/test/CodeGen/powerpc_types.c Sun Feb 10 18:53:16 2019
> @@ -1,4 +1,6 @@
>  // RUN: %clang_cc1 -triple powerpc-unknown-freebsd -emit-llvm -o - %s| 
> FileCheck -check-prefix=SVR4-CHECK %s
> +// RUN: %clang_cc1 -triple powerpc-unknown-netbsd -emit-llvm -o - %s| 
> FileCheck -check-prefix=SVR4-CHECK %s
> +// RUN: %clang_cc1 -triple powerpc-unknown-openbsd -emit-llvm -o - %s| 
> FileCheck -check-prefix=SVR4-CHECK %s
>
>  #include 
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D41005: Reuse preamble even if an unsaved file does not exist

2019-02-12 Thread Nikolai Kosjar via Phabricator via cfe-commits
nik updated this revision to Diff 186436.
nik added a comment.

> Meh, something changed in the meanwhile. 
> ReparseReusesPreambleAfterUnsavedFileWasRemovedFromDisk fails now. Looking 
> into it.

No, it's just me ;) I've referenced the header file wrong.


Repository:
  rC Clang

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

https://reviews.llvm.org/D41005

Files:
  include/clang/Frontend/ASTUnit.h
  lib/Frontend/ASTUnit.cpp
  lib/Frontend/PrecompiledPreamble.cpp
  unittests/Frontend/PCHPreambleTest.cpp

Index: unittests/Frontend/PCHPreambleTest.cpp
===
--- unittests/Frontend/PCHPreambleTest.cpp
+++ unittests/Frontend/PCHPreambleTest.cpp
@@ -52,7 +52,10 @@
   FileSystemOptions FSOpts;
 
 public:
-  void SetUp() override {
+  void SetUp() override { ResetVFS(); }
+  void TearDown() override {}
+
+  void ResetVFS() {
 VFS = new ReadCountingInMemoryFileSystem();
 // We need the working directory to be set to something absolute,
 // otherwise it ends up being inadvertently set to the current
@@ -63,9 +66,6 @@
 VFS->setCurrentWorkingDirectory("//./");
   }
 
-  void TearDown() override {
-  }
-
   void AddFile(const std::string &Filename, const std::string &Contents) {
 ::time_t now;
 ::time(&now);
@@ -123,6 +123,72 @@
   }
 };
 
+TEST_F(PCHPreambleTest, ReparseReusesPreambleWithUnsavedFileNotExistingOnDisk) {
+  std::string Header1 = "//./header1.h";
+  std::string MainName = "//./main.cpp";
+  AddFile(MainName, R"cpp(
+#include "//./header1.h"
+int main() { return ZERO; }
+)cpp");
+  RemapFile(Header1, "#define ZERO 0\n");
+
+  // Parse with header file provided as unsaved file, which does not exist on
+  // disk.
+  std::unique_ptr AST(ParseAST(MainName));
+  ASSERT_TRUE(AST.get());
+  ASSERT_FALSE(AST->getDiagnostics().hasErrorOccurred());
+
+  // Reparse and check that the preamble was reused.
+  ASSERT_TRUE(ReparseAST(AST));
+  ASSERT_EQ(AST->getPreambleCounterForTests(), 1U);
+}
+
+TEST_F(PCHPreambleTest, ReparseReusesPreambleAfterUnsavedFileWasCreatedOnDisk) {
+  std::string Header1 = "//./header1.h";
+  std::string MainName = "//./main.cpp";
+  AddFile(MainName, R"cpp(
+#include "//./header1.h"
+int main() { return ZERO; }
+)cpp");
+  RemapFile(Header1, "#define ZERO 0\n");
+
+  // Parse with header file provided as unsaved file, which does not exist on
+  // disk.
+  std::unique_ptr AST(ParseAST(MainName));
+  ASSERT_TRUE(AST.get());
+  ASSERT_FALSE(AST->getDiagnostics().hasErrorOccurred());
+
+  // Create the unsaved file also on disk and check that preamble was reused.
+  AddFile(Header1, "#define ZERO 0\n");
+  ASSERT_TRUE(ReparseAST(AST));
+  ASSERT_EQ(AST->getPreambleCounterForTests(), 1U);
+}
+
+TEST_F(PCHPreambleTest,
+   ReparseReusesPreambleAfterUnsavedFileWasRemovedFromDisk) {
+  std::string Header1 = "//./foo/header1.h";
+  std::string MainName = "//./main.cpp";
+  std::string MainFileContent = R"cpp(
+#include "//./foo/header1.h"
+int main() { return ZERO; }
+)cpp";
+  AddFile(MainName, MainFileContent);
+  AddFile(Header1, "#define ZERO 0\n");
+  RemapFile(Header1, "#define ZERO 0\n");
+
+  // Parse with header file provided as unsaved file, which exists on disk.
+  std::unique_ptr AST(ParseAST(MainName));
+  ASSERT_TRUE(AST.get());
+  ASSERT_FALSE(AST->getDiagnostics().hasErrorOccurred());
+  ASSERT_EQ(AST->getPreambleCounterForTests(), 1U);
+
+  // Remove the unsaved file from disk and check that the preamble was reused.
+  ResetVFS();
+  AddFile(MainName, MainFileContent);
+  ASSERT_TRUE(ReparseAST(AST));
+  ASSERT_EQ(AST->getPreambleCounterForTests(), 1U);
+}
+
 TEST_F(PCHPreambleTest, ReparseWithOverriddenFileDoesNotInvalidatePreamble) {
   std::string Header1 = "//./header1.h";
   std::string Header2 = "//./header2.h";
Index: lib/Frontend/PrecompiledPreamble.cpp
===
--- lib/Frontend/PrecompiledPreamble.cpp
+++ lib/Frontend/PrecompiledPreamble.cpp
@@ -28,6 +28,7 @@
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Mutex.h"
 #include "llvm/Support/MutexGuard.h"
+#include "llvm/Support/Path.h"
 #include "llvm/Support/Process.h"
 #include "llvm/Support/VirtualFileSystem.h"
 #include 
@@ -451,20 +452,32 @@
 Status.getSize(), llvm::sys::toTimeT(Status.getLastModificationTime()));
   }
 
+  llvm::StringMap OverridenFileBuffers;
   for (const auto &RB : PreprocessorOpts.RemappedFileBuffers) {
-llvm::vfs::Status Status;
-if (!moveOnNoError(VFS->status(RB.first), Status))
-  return false;
-
-OverriddenFiles[Status.getUniqueID()] =
+const PrecompiledPreamble::PreambleFileHash PreambleHash =
 PreambleFileHash::createForMemoryBuffer(RB.second);
+llvm::vfs::Status Status;
+if (moveOnNoError(VFS->status(RB.first), Status))
+  OverriddenFiles[Status.getUniqueID()] = PreambleHash;
+else
+  OverridenFileBuffers[RB.first] = PreambleHash;
   }
 
   // Check whe

r353836 - Disable test after r353718, r353725, r353729 while I investigate

2019-02-12 Thread Nico Weber via cfe-commits
Author: nico
Date: Tue Feb 12 04:40:56 2019
New Revision: 353836

URL: http://llvm.org/viewvc/llvm-project?rev=353836&view=rev
Log:
Disable test after r353718, r353725, r353729 while I investigate

Modified:
cfe/trunk/test/CodeGen/ms-x86-intrinsics.c

Modified: cfe/trunk/test/CodeGen/ms-x86-intrinsics.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/ms-x86-intrinsics.c?rev=353836&r1=353835&r2=353836&view=diff
==
--- cfe/trunk/test/CodeGen/ms-x86-intrinsics.c (original)
+++ cfe/trunk/test/CodeGen/ms-x86-intrinsics.c Tue Feb 12 04:40:56 2019
@@ -143,29 +143,33 @@ unsigned __int64 test__shiftleft128(unsi
 unsigned char d) {
   return __shiftleft128(l, h, d);
 }
+// FIXME: Add ':' after all the CHECK-X64 lines here once it's understood
+// why the order of the output is different when using clang or gcc as host cc.
 // CHECK-X64-LABEL: define dso_local i64 @test__shiftleft128(i64 %l, i64 %h, 
i8 %d)
 // CHECK-X64:  = zext i64 %{{.*}} to i128
-// CHECK-X64:  = shl nuw i128 %{{.*}}, 64
-// CHECK-X64:  = zext i64 %{{.*}} to i128
-// CHECK-X64:  = or i128 %
-// CHECK-X64:  = and i8 %{{.*}}, 63
-// CHECK-X64:  = shl i128 %
-// CHECK-X64:  = lshr i128 %
-// CHECK-X64:  = trunc i128 %
+// CHECK-X64  = shl nuw i128 %{{.*}}, 64
+// CHECK-X64  = zext i64 %{{.*}} to i128
+// CHECK-X64  = or i128 %
+// CHECK-X64  = and i8 %{{.*}}, 63
+// CHECK-X64  = shl i128 %
+// CHECK-X64  = lshr i128 %
+// CHECK-X64  = trunc i128 %
 // CHECK-X64:  ret i64 %
 
 unsigned __int64 test__shiftright128(unsigned __int64 l, unsigned __int64 h,
  unsigned char d) {
   return __shiftright128(l, h, d);
 }
+// FIXME: Add ':' after all the CHECK-X64 lines here once it's understood
+// why the order of the output is different when using clang or gcc as host cc.
 // CHECK-X64-LABEL: define dso_local i64 @test__shiftright128(i64 %l, i64 %h, 
i8 %d)
 // CHECK-X64:  = zext i64 %{{.*}} to i128
-// CHECK-X64:  = shl nuw i128 %{{.*}}, 64
-// CHECK-X64:  = zext i64 %{{.*}} to i128
-// CHECK-X64:  = or i128 %
-// CHECK-X64:  = and i8 %{{.*}}, 63
-// CHECK-X64:  = lshr i128 %
-// CHECK-X64:  = trunc i128 %
+// CHECK-X64  = shl nuw i128 %{{.*}}, 64
+// CHECK-X64  = zext i64 %{{.*}} to i128
+// CHECK-X64  = or i128 %
+// CHECK-X64  = and i8 %{{.*}}, 63
+// CHECK-X64  = lshr i128 %
+// CHECK-X64  = trunc i128 %
 // CHECK-X64:  ret i64 %
 
 #endif // defined(__x86_64__)


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


Re: r353729 - Attempt to pacify bots more after r353718 and r353725

2019-02-12 Thread Nico Weber via cfe-commits
Thanks for reporting that this depends on the host compiler.

I disabled the test again in r353836 and will look into why the output is
different depending on if host cc is gcc or clang.

On Tue, Feb 12, 2019 at 2:40 AM Mikael Holmén 
wrote:

> Same thing for me with our downstream build bots.
>
> When we compile clang with gcc 7.4 and then run the testcase I get this
> output
>
> define dso_local i64 @test__shiftleft128(i64 %l, i64 %h, i8 %d)
> local_unnamed_addr #0 {
> entry:
>%0 = zext i64 %l to i128
>%1 = zext i64 %h to i128
>%2 = shl nuw i128 %1, 64
>%3 = or i128 %2, %0
>%4 = and i8 %d, 63
>%5 = zext i8 %4 to i128
>%6 = shl i128 %3, %5
>%7 = lshr i128 %6, 64
>%8 = trunc i128 %7 to i64
>ret i64 %8
> }
>
> and when I compile clang with clang 3.6 and run the test I get this:
>
> define dso_local i64 @test__shiftleft128(i64 %l, i64 %h, i8 %d)
> local_unnamed_addr #0 {
> entry:
>%0 = zext i64 %h to i128
>%1 = shl nuw i128 %0, 64
>%2 = zext i64 %l to i128
>%3 = or i128 %1, %2
>%4 = and i8 %d, 63
>%5 = zext i8 %4 to i128
>%6 = shl i128 %3, %5
>%7 = lshr i128 %6, 64
>%8 = trunc i128 %7 to i64
>ret i64 %8
> }
>
> /Mikael
>
> On 2/12/19 2:03 AM, Nico Weber via cfe-commits wrote:
> > Thank you for the .ll files!
> >
> > the -4.ll file you sent me contains:
> >
> > define dso_local i64 @"?test__shiftleft128@@YA_K_K0E@Z"(i64 %l, i64 %h,
> > i8 %d) local_unnamed_addr #0 {
> > entry:
> >%0 = zext i64 %h to i128
> >%1 = shl nuw i128 %0, 64
> >%2 = zext i64 %l to i128
> >%3 = or i128 %1, %2
> >%4 = and i8 %d, 63
> >%5 = zext i8 %4 to i128
> >%6 = shl i128 %3, %5
> >%7 = lshr i128 %6, 64
> >%8 = trunc i128 %7 to i64
> >ret i64 %8
> > }
> >
> > On my local system, I get
> >
> > ; Function Attrs: minsize norecurse nounwind optsize readnone
> > define dso_local i64 @test__shiftleft128(i64 %l, i64 %h, i8 %d)
> > local_unnamed_addr #0 {
> > entry:
> >%0 = zext i64 %l to i128
> >%1 = zext i64 %h to i128
> >%2 = shl nuw i128 %1, 64
> >%3 = or i128 %2, %0
> >%4 = and i8 %d, 63
> >%5 = zext i8 %4 to i128
> >%6 = shl i128 %3, %5
> >%7 = lshr i128 %6, 64
> >%8 = trunc i128 %7 to i64
> >ret i64 %8
> > }
> >
> > That's identical except for the order of the instructions (which in turn
> > changes some % numbers).
> >
> > That's surprising to me; I thought LLVM IR is deterministic (and if it
> > wasn't, many other tests wouldn't work either).
> >
> > On Mon, Feb 11, 2019 at 4:20 PM Galina Kistanova  > > wrote:
> >
> > Hello Nico,
> >
> > This builders fail on your test as well -
> >
> http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/15736
> ,
> > http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/4242
> .
> >
> > Please find attached the 2 temp files you can use to reliably run
> > against your FileCheck patterns.
> > Hope this would help debugging.
> >
> > Please also notice the warnings each of the RUN command produces.
> > The warnings should be quite easy to reproduce and address.
> >
> > In the mean time, could you revert the change unless you expect the
> > fix coming really soon, please?
> > It is not a good idea to keep the bots red for long.
> >
> > Here is the log:
> >
>  --
> >
> >
>  
> C:\>c:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\bin\clang.exe
> > -cc1 -internal-isystem
> >
>  
> c:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\lib\clang\9.0.0\include
> > -nostdsysteminc -ffreestanding -fms-extensions -fms-compatibility
> > -fms-compatibility-version=17.00 -triple i686--windows -Oz
> > -emit-llvm
> >
>  
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\CodeGen\ms-x86-intrinsics.c
> > -o - > \tmp-1\ms-x86-intrinsics-1.ll
> >
>  
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\CodeGen\ms-x86-intrinsics.c:10:10:
> > warning: implicitly declaring library function '__readfsbyte' with
> > type 'unsigned char (unsigned long)'
> >return __readfsbyte(++Offset);
> >   ^
> >
>  
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\CodeGen\ms-x86-intrinsics.c:10:10:
> > note: include the header  or explicitly provide a
> > declaration for '__readfsbyte'
> >
>  
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\CodeGen\ms-x86-intrinsics.c:19:10:
> > warning: implicitly declaring library function '__readfsword' with
> > type 'unsigned short (unsigned long)'
> >return __readfsword(++Offset);
> >   ^
> >
>  
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10

[PATCH] D54978: Move the SMT API to LLVM

2019-02-12 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.
Herald added a subscriber: jdoerfert.

>> If so, I don't understand why the default setting is important to you and 
>> why this doesn't work for you. (I don't disagree with the default being off, 
>> I'm just confused why things don't work for you.)
> 
> As I have stated several times, the CMake option `-D 
> LLVM_OPTIMIZED_TABLEGEN=ON` spawns a sub-command of CMake and **is required 
> for the break to occur**. I don't know how to make this any more clear: if 
> you build with optimized tablegen, it breaks. I strongly suspect an 
> interaction between LLVM's top-level CMake and the TableGen one but I haven't 
> had time to debug it down to the exact cause.
> 
> It is important to me because the detection of the correct version of Z3 is 
> imprecise, at best.  If a Z3 library is found  I have no way to guarantee a 
> build I run will not attempt to include the library.

Got it now, sorry about being dense.

mikhail.ramalho: My guess is that we need to pass on LLVM_OPTIMIZED_TABLEGEN to 
the child cmake invocation in 
http://llvm-cs.pcc.me.uk/cmake/modules/CrossCompile.cmake#50 (like we pass on a 
few other variables) to fix this.


Repository:
  rC Clang

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

https://reviews.llvm.org/D54978



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


[PATCH] D17444: PR26672: [MSVC] Clang does not recognize "static_assert" keyword in C mode

2019-02-12 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.
Herald added a subscriber: jdoerfert.

I don't have an opinion if this patch here or the assert wrapper is better, but 
I feel somewhat strongly that we should land one or the other so that the 
standard C program

  #include 
  
  static_assert(4 == 4 , "");

builds in clang-cl like it does in every other compiler.

Sounds like rnk and rsmith are the champions for each approach, so maybe the 
two of you could have a meeting of the minds somewhere and Decide What To Do 
Here?


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

https://reviews.llvm.org/D17444



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


r353837 - Fixing a typo; NFC.

2019-02-12 Thread Aaron Ballman via cfe-commits
Author: aaronballman
Date: Tue Feb 12 05:04:11 2019
New Revision: 353837

URL: http://llvm.org/viewvc/llvm-project?rev=353837&view=rev
Log:
Fixing a typo; NFC.

Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaDeclAttr.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=353837&r1=353836&r2=353837&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Tue Feb 12 05:04:11 
2019
@@ -2527,7 +2527,7 @@ def err_attribute_argument_n_type : Erro
 def err_attribute_argument_type : Error<
   "%0 attribute requires %select{int or bool|an integer "
   "constant|a string|an identifier}1">;
-def err_attribute_argument_outof_range : Error<
+def err_attribute_argument_out_of_range : Error<
   "%0 attribute requires integer constant between %1 and %2 inclusive">;
 def err_init_priority_object_attr : Error<
   "can only use 'init_priority' attribute on file-scope definitions "

Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=353837&r1=353836&r2=353837&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Tue Feb 12 05:04:11 2019
@@ -1118,7 +1118,7 @@ static void handlePassObjectSizeAttr(Sem
   // __builtin_object_size. So, it has the same constraints as that second
   // argument; namely, it must be in the range [0, 3].
   if (Type > 3) {
-S.Diag(E->getBeginLoc(), diag::err_attribute_argument_outof_range)
+S.Diag(E->getBeginLoc(), diag::err_attribute_argument_out_of_range)
 << AL << 0 << 3 << E->getSourceRange();
 return;
   }
@@ -3299,7 +3299,7 @@ static void handleInitPriorityAttr(Sema
   }
 
   if (prioritynum < 101 || prioritynum > 65535) {
-S.Diag(AL.getLoc(), diag::err_attribute_argument_outof_range)
+S.Diag(AL.getLoc(), diag::err_attribute_argument_out_of_range)
 << E->getSourceRange() << AL << 101 << 65535;
 AL.setInvalid();
 return;
@@ -6434,7 +6434,7 @@ static void handleFortifyStdLib(Sema &S,
 
   if (BOSType > 3) {
 S.Diag(AL.getArgAsExpr(0)->getBeginLoc(),
-   diag::err_attribute_argument_outof_range)
+   diag::err_attribute_argument_out_of_range)
 << AL << 0 << 3;
 return;
   }


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


r353838 - Renaming this diagnostic to not conflict with another; NFC.

2019-02-12 Thread Aaron Ballman via cfe-commits
Author: aaronballman
Date: Tue Feb 12 05:13:35 2019
New Revision: 353838

URL: http://llvm.org/viewvc/llvm-project?rev=353838&view=rev
Log:
Renaming this diagnostic to not conflict with another; NFC.

Amends r353837 which renamed the diagnostics to conflict.

Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaDeclAttr.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=353838&r1=353837&r2=353838&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Tue Feb 12 05:13:35 
2019
@@ -3023,7 +3023,7 @@ def warn_thread_attribute_decl_not_locka
 def warn_thread_attribute_decl_not_pointer : Warning<
   "%0 only applies to pointer types; type here is %1">,
   InGroup, DefaultIgnore;
-def err_attribute_argument_out_of_range : Error<
+def err_attribute_argument_out_of_bounds : Error<
   "%0 attribute parameter %1 is out of bounds: "
   "%plural{0:no parameters to index into|"
   "1:can only be 1, since there is one parameter|"

Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=353838&r1=353837&r2=353838&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Tue Feb 12 05:13:35 2019
@@ -716,7 +716,7 @@ static void checkAttrArgsAreCapabilityOb
 uint64_t ParamIdxFromOne = ArgValue.getZExtValue();
 uint64_t ParamIdxFromZero = ParamIdxFromOne - 1;
 if (!ArgValue.isStrictlyPositive() || ParamIdxFromOne > NumParams) {
-  S.Diag(AL.getLoc(), diag::err_attribute_argument_out_of_range)
+  S.Diag(AL.getLoc(), diag::err_attribute_argument_out_of_bounds)
   << AL << Idx + 1 << NumParams;
   continue;
 }


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


r353839 - Renaming yet another diagnostic to not conflict; NFC.

2019-02-12 Thread Aaron Ballman via cfe-commits
Author: aaronballman
Date: Tue Feb 12 05:19:02 2019
New Revision: 353839

URL: http://llvm.org/viewvc/llvm-project?rev=353839&view=rev
Log:
Renaming yet another diagnostic to not conflict; NFC.

Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaDeclAttr.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=353839&r1=353838&r2=353839&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Tue Feb 12 05:19:02 
2019
@@ -3023,7 +3023,7 @@ def warn_thread_attribute_decl_not_locka
 def warn_thread_attribute_decl_not_pointer : Warning<
   "%0 only applies to pointer types; type here is %1">,
   InGroup, DefaultIgnore;
-def err_attribute_argument_out_of_bounds : Error<
+def err_attribute_argument_out_of_bounds_extra_info : Error<
   "%0 attribute parameter %1 is out of bounds: "
   "%plural{0:no parameters to index into|"
   "1:can only be 1, since there is one parameter|"

Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=353839&r1=353838&r2=353839&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Tue Feb 12 05:19:02 2019
@@ -716,7 +716,8 @@ static void checkAttrArgsAreCapabilityOb
 uint64_t ParamIdxFromOne = ArgValue.getZExtValue();
 uint64_t ParamIdxFromZero = ParamIdxFromOne - 1;
 if (!ArgValue.isStrictlyPositive() || ParamIdxFromOne > NumParams) {
-  S.Diag(AL.getLoc(), diag::err_attribute_argument_out_of_bounds)
+  S.Diag(AL.getLoc(),
+ diag::err_attribute_argument_out_of_bounds_extra_info)
   << AL << Idx + 1 << NumParams;
   continue;
 }


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


[PATCH] D57984: PR40642: Fix determination of whether the final statement of a statementexpression is a discarded-value expression.

2019-02-12 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Considering that this has been fertile ground for buggy edge cases, should we 
revert my original changes from the 8.0 branch to give this more time to bake 
on trunk before releasing? Or do you think this is fine to move onto the 
release branch once finalized?




Comment at: include/clang/AST/Stmt.h:1598-1602
+  const Expr *getExprStmt() const;
+  Expr *getExprStmt() {
+const ValueStmt *ConstThis = this;
+return const_cast(ConstThis->getExprStmt());
+  }

rsmith wrote:
> aaron.ballman wrote:
> > We typically implement this in reverse, where the non-const version holds 
> > the actual implementation and the const version performs a `const_cast`.
> We do. Do you think that's preferable? I like that this way around proves 
> that the `const` version is const-correct, but it's a tiny benefit and I'm 
> fine with just being consistent.
Personally, I prefer the way you have it here (though I wish we had a global 
helper function to hide the dispatch dance).



Comment at: include/clang/Parse/Parser.h:374
+  /// a statement expression and builds a suitable expression statement.
+  StmtResult handleExprStmt(ExprResult E, WithinStmtExpr IsInStmtExpr);
 

rsmith wrote:
> aaron.ballman wrote:
> > Rather than passing around `IsInStmtExpr` to a bunch of parser APIs, would 
> > it make more sense to add an RAII object that sets some state on `Parser` 
> > to test it? The proliferation of arguments seems unfortunate given how much 
> > of a corner case statement expressions are.
> Yeah, I tried that approach first, but the parser state turns out to be much 
> worse, because it puts a burden on every form of statement that constructs a 
> nested parsing context to reset that state. We can put the resetting on 
> `ParseScope`, but it still needs to have an effect in the case where the 
> scope is disabled, which is surprising, and there's no guarantee such 
> statement constructs that can end in an expression will have a nested scope 
> (consider, for instance, constructs like `return x;` or `goto *label;`). This 
> is really local state that should only be propagated through a very small 
> number of syntactic constructs rather than global state.
> 
> Maybe we could combine the new flag with the `AllowOpenMPStandalone` / 
> `AllowedConstructsKind` flag into a more general kind of "statement context". 
> The propagation rules aren't quite the same (`AllowOpenMPStandalone` doesn't 
> get propagated through labels whereas `IsInStmtExpr` does), which is a little 
> awkward, but maybe that's not so bad -- and maybe that's actually a bug in 
> the OpenMP implementation?
> Maybe we could combine the new flag with the AllowOpenMPStandalone / 
> AllowedConstructsKind flag into a more general kind of "statement context".

That seems like a sensible approach to me.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57984



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


[PATCH] D58095: [clang-tidy] Make google-objc-function-naming ignore implicit functions 🙈

2019-02-12 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.
Herald added a subscriber: jdoerfert.



Comment at: clang-tools-extra/test/clang-tidy/google-objc-function-naming.m:10
+// function would be declared in a system header.
+int printf(const char *, ...);  // NOLINT(google-objc-function-naming)
+

stephanemoore wrote:
> Thus far I have been unsuccessful in using line markers to simulate this 
> declaration being in a system header but I did discover precedence for using 
> NOLINT to suppress diagnostics in some of the clang-tidy tests:
> https://github.com/llvm/llvm-project/blob/master/clang-tools-extra/test/clang-tidy/google-runtime-int-std.cpp#L11
> https://github.com/llvm/llvm-project/blob/master/clang-tools-extra/test/clang-tidy/google-runtime-int.cpp#L6
> 
> I think it should be reasonable to suppress the diagnostic here with a 
> comment explaining why. Let me know if you don't think that's an appropriate 
> solution and I can continue investigating for a potential solution using line 
> markers.
Personally, I would recommend adding stdio.h to 
extra\test\clang-tidy\Inputs\Headers and adding a `-isystem` to this test's RUN 
line. You could also add `#pragma clang system_header` to the file to be really 
sure it's treated as a system header. This gives us a place to add more stdio.h 
declarations in the future as well.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D58095



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


[PATCH] D57236: [ASTImporter] Unify redecl chain tests as type parameterized tests

2019-02-12 Thread Gabor Marton via Phabricator via cfe-commits
martong updated this revision to Diff 186445.
martong added a comment.
Herald added a subscriber: jdoerfert.

- Remove numbers when possible
- Use disabled tests instead of commented out tests


Repository:
  rC Clang

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

https://reviews.llvm.org/D57236

Files:
  unittests/AST/ASTImporterTest.cpp

Index: unittests/AST/ASTImporterTest.cpp
===
--- unittests/AST/ASTImporterTest.cpp
+++ unittests/AST/ASTImporterTest.cpp
@@ -73,6 +73,11 @@
 
 };
 
+auto DefaultTestValuesForRunOptions = ::testing::Values(
+ArgVector(), ArgVector{"-fdelayed-template-parsing"},
+ArgVector{"-fms-compatibility"},
+ArgVector{"-fdelayed-template-parsing", "-fms-compatibility"});
+
 // Base class for those tests which use the family of `testImport` functions.
 class TestImportBase : public ParameterizedTestsFixture {
 
@@ -1976,33 +1981,6 @@
 
 struct ImportFunctions : ASTImporterTestBase {};
 
-TEST_P(ImportFunctions,
-   DefinitionShouldBeImportedAsDefintionWhenThereIsAPrototype) {
-  Decl *FromTU = getTuDecl("void f(); void f() {}", Lang_CXX);
-  auto Pattern = functionDecl(hasName("f"));
-  FunctionDecl *FromD = // Definition
-  LastDeclMatcher().match(FromTU, Pattern);
-
-  Decl *ImportedD = Import(FromD, Lang_CXX);
-  Decl *ToTU = ImportedD->getTranslationUnitDecl();
-
-  EXPECT_EQ(DeclCounter().match(ToTU, Pattern), 2u);
-  EXPECT_TRUE(cast(ImportedD)->doesThisDeclarationHaveABody());
-}
-
-TEST_P(ImportFunctions, DefinitionShouldBeImportedAsADefinition) {
-  Decl *FromTU = getTuDecl("void f() {}", Lang_CXX);
-  auto Pattern = functionDecl(hasName("f"));
-  FunctionDecl *FromD =
-  FirstDeclMatcher().match(FromTU, Pattern);
-
-  Decl *ImportedD = Import(FromD, Lang_CXX);
-  Decl *ToTU = ImportedD->getTranslationUnitDecl();
-
-  EXPECT_EQ(DeclCounter().match(ToTU, Pattern), 1u);
-  EXPECT_TRUE(cast(ImportedD)->doesThisDeclarationHaveABody());
-}
-
 TEST_P(ImportFunctions, ImportPrototypeOfRecursiveFunction) {
   Decl *FromTU = getTuDecl("void f(); void f() { f(); }", Lang_CXX);
   auto Pattern = functionDecl(hasName("f"));
@@ -2039,138 +2017,6 @@
   EXPECT_EQ(To1->getPreviousDecl(), To0);
 }
 
-TEST_P(ImportFunctions, ImportPrototypes) {
-  auto Pattern = functionDecl(hasName("f"));
-
-  Decl *ImportedD;
-  {
-Decl *FromTU = getTuDecl("void f();", Lang_CXX, "input0.cc");
-auto *FromD = FirstDeclMatcher().match(FromTU, Pattern);
-
-ImportedD = Import(FromD, Lang_CXX);
-  }
-  {
-Decl *FromTU = getTuDecl("void f();", Lang_CXX, "input1.cc");
-auto *FromD = FirstDeclMatcher().match(FromTU, Pattern);
-Import(FromD, Lang_CXX);
-  }
-
-  Decl *ToTU = ImportedD->getTranslationUnitDecl();
-
-  EXPECT_EQ(DeclCounter().match(ToTU, Pattern), 2u);
-  auto *To0 = FirstDeclMatcher().match(ToTU, Pattern);
-  auto *To1 = LastDeclMatcher().match(ToTU, Pattern);
-  EXPECT_TRUE(ImportedD == To0);
-  EXPECT_FALSE(To0->doesThisDeclarationHaveABody());
-  EXPECT_FALSE(To1->doesThisDeclarationHaveABody());
-  EXPECT_EQ(To1->getPreviousDecl(), To0);
-}
-
-TEST_P(ImportFunctions, ImportDefinitions) {
-  auto Pattern = functionDecl(hasName("f"));
-
-  Decl *ImportedD;
-  {
-Decl *FromTU = getTuDecl("void f(){}", Lang_CXX, "input0.cc");
-auto *FromD = FirstDeclMatcher().match(FromTU, Pattern);
-ImportedD = Import(FromD, Lang_CXX);
-  }
-  {
-Decl *FromTU = getTuDecl("void f(){};", Lang_CXX, "input1.cc");
-auto *FromD = FirstDeclMatcher().match(FromTU, Pattern);
-Import(FromD, Lang_CXX);
-  }
-
-  Decl *ToTU = ImportedD->getTranslationUnitDecl();
-
-  EXPECT_EQ(DeclCounter().match(ToTU, Pattern), 1u);
-  auto *To0 = FirstDeclMatcher().match(ToTU, Pattern);
-  EXPECT_TRUE(ImportedD == To0);
-  EXPECT_TRUE(To0->doesThisDeclarationHaveABody());
-}
-
-TEST_P(ImportFunctions, ImportDefinitionThenPrototype) {
-  auto Pattern = functionDecl(hasName("f"));
-
-  Decl *ImportedD;
-  {
-Decl *FromTU = getTuDecl("void f(){}", Lang_CXX, "input0.cc");
-auto *FromD = FirstDeclMatcher().match(FromTU, Pattern);
-ImportedD = Import(FromD, Lang_CXX);
-  }
-  {
-Decl *FromTU = getTuDecl("void f();", Lang_CXX, "input1.cc");
-auto *FromD = FirstDeclMatcher().match(FromTU, Pattern);
-Import(FromD, Lang_CXX);
-  }
-
-  Decl *ToTU = ToAST->getASTContext().getTranslationUnitDecl();
-
-  EXPECT_EQ(DeclCounter().match(ToTU, Pattern), 2u);
-  auto *To0 = FirstDeclMatcher().match(ToTU, Pattern);
-  auto *To1 = LastDeclMatcher().match(ToTU, Pattern);
-  EXPECT_TRUE(ImportedD == To0);
-  EXPECT_TRUE(To0->doesThisDeclarationHaveABody());
-  EXPECT_FALSE(To1->doesThisDeclarationHaveABody());
-  EXPECT_EQ(To1->getPreviousDecl(), To0);
-}
-
-TEST_P(ImportFunctions, ImportPrototypeThenDefinition) {
-  auto Pattern = functionDecl(hasName("f"));
-
-  {
-Decl *FromTU = getTuDecl("void f();", Lang_CXX, "input0.cc");
-FunctionDecl *FromD =
-FirstDeclMatcher().match

[PATCH] D57236: [ASTImporter] Unify redecl chain tests as type parameterized tests

2019-02-12 Thread Gabor Marton via Phabricator via cfe-commits
martong marked 4 inline comments as done.
martong added a comment.

Thanks for the review Alexei!




Comment at: unittests/AST/ASTImporterTest.cpp:3549
+  void TypedTest_ImportDefinitionThenPrototype() {
+Decl *FromTU0 = getTuDecl(getDefinition(), Lang_CXX, "input0.cc");
+Decl *FromTU1 = getTuDecl(getPrototype(), Lang_CXX, "input1.cc");

a_sidorin wrote:
> I would ask you not to use numbers when possible: these names are hard to 
> keep in mind. There can be a nice naming scheme like 
> "FromTUDef/FromTUProto/FromTUProtoDef|, I think it would be much better.
Ok. I have removed the numbers where it makes sense: where we have a proto and 
a definition. However, there are cases when we import two similar nodes (e.g. 
two prototypes) then I think the numbering is needed to identify the first and 
second node.



Comment at: unittests/AST/ASTImporterTest.cpp:3704
+// FIXME This does not pass, possible error with Class import.
+//ASTIMPORTER_INSTANTIATE_TYPED_TEST_CASE(RedeclChain, Class,
+
//ImportDefinitionAfterImportedPrototype);

a_sidorin wrote:
> Is it possible to disable the tests instead of commenting them out?
Okay, I have changed the macro so we can disable the tests.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57236



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


Re: r353729 - Attempt to pacify bots more after r353718 and r353725

2019-02-12 Thread Mikael Holmén via cfe-commits


On 2/12/19 1:41 PM, Nico Weber wrote:
> Thanks for reporting that this depends on the host compiler.
> 
> I disabled the test again in r353836 and will look into why the output 
> is different depending on if host cc is gcc or clang.
> 

Good. Thanks!

When I've seen things like this before it's often something like 
iterating over a set or similar where the iteration order isn't 
deterministic.

/Mikael

> On Tue, Feb 12, 2019 at 2:40 AM Mikael Holmén 
> mailto:mikael.hol...@ericsson.com>> wrote:
> 
> Same thing for me with our downstream build bots.
> 
> When we compile clang with gcc 7.4 and then run the testcase I get this
> output
> 
> define dso_local i64 @test__shiftleft128(i64 %l, i64 %h, i8 %d)
> local_unnamed_addr #0 {
> entry:
>     %0 = zext i64 %l to i128
>     %1 = zext i64 %h to i128
>     %2 = shl nuw i128 %1, 64
>     %3 = or i128 %2, %0
>     %4 = and i8 %d, 63
>     %5 = zext i8 %4 to i128
>     %6 = shl i128 %3, %5
>     %7 = lshr i128 %6, 64
>     %8 = trunc i128 %7 to i64
>     ret i64 %8
> }
> 
> and when I compile clang with clang 3.6 and run the test I get this:
> 
> define dso_local i64 @test__shiftleft128(i64 %l, i64 %h, i8 %d)
> local_unnamed_addr #0 {
> entry:
>     %0 = zext i64 %h to i128
>     %1 = shl nuw i128 %0, 64
>     %2 = zext i64 %l to i128
>     %3 = or i128 %1, %2
>     %4 = and i8 %d, 63
>     %5 = zext i8 %4 to i128
>     %6 = shl i128 %3, %5
>     %7 = lshr i128 %6, 64
>     %8 = trunc i128 %7 to i64
>     ret i64 %8
> }
> 
> /Mikael
> 
> On 2/12/19 2:03 AM, Nico Weber via cfe-commits wrote:
>  > Thank you for the .ll files!
>  >
>  > the -4.ll file you sent me contains:
>  >
>  > define dso_local i64 @"?test__shiftleft128@@YA_K_K0E@Z"(i64 %l,
> i64 %h,
>  > i8 %d) local_unnamed_addr #0 {
>  > entry:
>  >    %0 = zext i64 %h to i128
>  >    %1 = shl nuw i128 %0, 64
>  >    %2 = zext i64 %l to i128
>  >    %3 = or i128 %1, %2
>  >    %4 = and i8 %d, 63
>  >    %5 = zext i8 %4 to i128
>  >    %6 = shl i128 %3, %5
>  >    %7 = lshr i128 %6, 64
>  >    %8 = trunc i128 %7 to i64
>  >    ret i64 %8
>  > }
>  >
>  > On my local system, I get
>  >
>  > ; Function Attrs: minsize norecurse nounwind optsize readnone
>  > define dso_local i64 @test__shiftleft128(i64 %l, i64 %h, i8 %d)
>  > local_unnamed_addr #0 {
>  > entry:
>  >    %0 = zext i64 %l to i128
>  >    %1 = zext i64 %h to i128
>  >    %2 = shl nuw i128 %1, 64
>  >    %3 = or i128 %2, %0
>  >    %4 = and i8 %d, 63
>  >    %5 = zext i8 %4 to i128
>  >    %6 = shl i128 %3, %5
>  >    %7 = lshr i128 %6, 64
>  >    %8 = trunc i128 %7 to i64
>  >    ret i64 %8
>  > }
>  >
>  > That's identical except for the order of the instructions (which
> in turn
>  > changes some % numbers).
>  >
>  > That's surprising to me; I thought LLVM IR is deterministic (and
> if it
>  > wasn't, many other tests wouldn't work either).
>  >
>  > On Mon, Feb 11, 2019 at 4:20 PM Galina Kistanova
> mailto:gkistan...@gmail.com>
>  > >> wrote:
>  >
>  >     Hello Nico,
>  >
>  >     This builders fail on your test as well -
>  >
> 
> http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/15736,
>  > http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/4242.
>  >
>  >     Please find attached the 2 temp files you can use to reliably run
>  >     against your FileCheck patterns.
>  >     Hope this would help debugging.
>  >
>  >     Please also notice the warnings each of the RUN command produces.
>  >     The warnings should be quite easy to reproduce and address.
>  >
>  >     In the mean time, could you revert the change unless you
> expect the
>  >     fix coming really soon, please?
>  >     It is not a good idea to keep the bots red for long.
>  >
>  >     Here is the log:
>  >   
>   --
>  >
>  >   
>   
> C:\>c:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\bin\clang.exe
>  >     -cc1 -internal-isystem
>  >   
>   
> c:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\lib\clang\9.0.0\include
>  >     -nostdsysteminc -ffreestanding -fms-extensions -fms-compatibility
>  >     -fms-compatibility-version=17.00 -triple i686--windows -Oz
>  >     -emit-llvm
>  >   
>   
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\CodeGen\ms-x86-intrinsics.c
>  >     -o - > \tmp-1\ms-x86-intrinsics-1.ll
>  >   
>   
> C:\ps4-bu

[PATCH] D58111: [Sema] Fix a crash in access checking for deduction guides

2019-02-12 Thread Ilya Biryukov via Phabricator via cfe-commits
ilya-biryukov updated this revision to Diff 186447.
ilya-biryukov marked an inline comment as done.
ilya-biryukov added a comment.

- Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D58111

Files:
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/Sema/crash-deduction-guide-access.cpp


Index: clang/test/Sema/crash-deduction-guide-access.cpp
===
--- /dev/null
+++ clang/test/Sema/crash-deduction-guide-access.cpp
@@ -0,0 +1,11 @@
+// RUN: not %clang_cc1 -x c++ -std=c++17 -fsyntax-only %s
+template 
+class Imp {
+  template 
+  explicit Imp(F f);
+};
+
+template 
+class Cls {
+  explicit Imp() : f() {}
+};
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -3175,7 +3175,11 @@
 //   declared] with the same access [as the template].
 if (auto *DG = dyn_cast(NonTemplateMember)) {
   auto *TD = DG->getDeducedTemplate();
-  if (AS != TD->getAccess()) {
+  // Access specifiers are only meaningful if both the template and the
+  // deduction guide are from the same scope.
+  if (AS != TD->getAccess() &&
+  TD->getDeclContext()->getRedeclContext()->Equals(
+  DG->getDeclContext()->getRedeclContext())) {
 Diag(DG->getBeginLoc(), diag::err_deduction_guide_wrong_access);
 Diag(TD->getBeginLoc(), diag::note_deduction_guide_template_access)
 << TD->getAccess();


Index: clang/test/Sema/crash-deduction-guide-access.cpp
===
--- /dev/null
+++ clang/test/Sema/crash-deduction-guide-access.cpp
@@ -0,0 +1,11 @@
+// RUN: not %clang_cc1 -x c++ -std=c++17 -fsyntax-only %s
+template 
+class Imp {
+  template 
+  explicit Imp(F f);
+};
+
+template 
+class Cls {
+  explicit Imp() : f() {}
+};
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -3175,7 +3175,11 @@
 //   declared] with the same access [as the template].
 if (auto *DG = dyn_cast(NonTemplateMember)) {
   auto *TD = DG->getDeducedTemplate();
-  if (AS != TD->getAccess()) {
+  // Access specifiers are only meaningful if both the template and the
+  // deduction guide are from the same scope.
+  if (AS != TD->getAccess() &&
+  TD->getDeclContext()->getRedeclContext()->Equals(
+  DG->getDeclContext()->getRedeclContext())) {
 Diag(DG->getBeginLoc(), diag::err_deduction_guide_wrong_access);
 Diag(TD->getBeginLoc(), diag::note_deduction_guide_template_access)
 << TD->getAccess();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57948: [Sema] Fix a regression introduced in "[AST][Sema] Remove CallExpr::setNumArgs"

2019-02-12 Thread Bruno Ricci via Phabricator via cfe-commits
riccibruno updated this revision to Diff 186449.
riccibruno added a comment.

Rewrote the patch to make it local to `BuildResolvedCallExpr`. It is still a 
hack though.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57948

Files:
  include/clang/AST/Expr.h
  lib/Sema/SemaExpr.cpp
  test/Sema/typo-correction.c


Index: test/Sema/typo-correction.c
===
--- test/Sema/typo-correction.c
+++ test/Sema/typo-correction.c
@@ -100,3 +100,18 @@
   structVar1.fieldName1.member1, //expected-error{{use of undeclared 
identifier 'structVar1'}}
   structVar2.fieldName2.member2); //expected-error{{use of undeclared 
identifier 'structVar2'}}
 }
+
+void PR40286_g(int x, int y);
+void PR40286_h(int x, int y, int z);
+void PR40286_1(int the_value) {
+  PR40286_g(the_walue); // expected-error {{use of undeclared identifier 
'the_walue'}}
+}
+void PR40286_2(int the_value) {
+  PR40286_h(the_value, the_walue); // expected-error {{use of undeclared 
identifier 'the_walue'}}
+}
+void PR40286_3(int the_value) {
+  PR40286_h(the_walue); // expected-error {{use of undeclared identifier 
'the_walue'}}
+}
+void PR40286_4(int the_value) { // expected-note {{'the_value' declared here}}
+  PR40286_h(the_value, the_value, the_walue); // expected-error {{use of 
undeclared identifier 'the_walue'; did you mean 'the_value'?}}
+}
Index: lib/Sema/SemaExpr.cpp
===
--- lib/Sema/SemaExpr.cpp
+++ lib/Sema/SemaExpr.cpp
@@ -5793,18 +5793,36 @@
   }
 
   if (!getLangOpts().CPlusPlus) {
+// Forget about the nulled arguments since typo correction
+// do not handle them well.
+TheCall->shrinkNumArgs(Args.size());
 // C cannot always handle TypoExpr nodes in builtin calls and direct
 // function calls as their argument checking don't necessarily handle
 // dependent types properly, so make sure any TypoExprs have been
 // dealt with.
 ExprResult Result = CorrectDelayedTyposInExpr(TheCall);
 if (!Result.isUsable()) return ExprError();
+CallExpr *TheOldCall = TheCall;
 TheCall = dyn_cast(Result.get());
+bool CorrectedTypos = TheCall != TheOldCall;
 if (!TheCall) return Result;
-// TheCall at this point has max(Args.size(), NumParams) arguments,
-// with extra arguments nulled. We don't want to introduce nulled
-// arguments in Args and so we only take the first Args.size() arguments.
-Args = llvm::makeArrayRef(TheCall->getArgs(), Args.size());
+Args = llvm::makeArrayRef(TheCall->getArgs(), TheCall->getNumArgs());
+
+// A new call expression node was created if some typos were corrected.
+// However it may not have been constructed with enough storage. In this
+// case, rebuild the node with enough storage. The waste of space is
+// immaterial since this only happens when some typos were corrected.
+if (CorrectedTypos && Args.size() < NumParams) {
+  if (Config)
+TheCall = CUDAKernelCallExpr::Create(
+Context, Fn, cast(Config), Args, ResultTy, VK_RValue,
+RParenLoc, NumParams);
+  else
+TheCall = CallExpr::Create(Context, Fn, Args, ResultTy, VK_RValue,
+   RParenLoc, NumParams, UsesADL);
+}
+// We can now handle the nulled arguments for the default arguments.
+TheCall->setNumArgsUnsafe(std::max(Args.size(), NumParams));
   }
 
   // Bail out early if calling a builtin with custom type checking.
Index: include/clang/AST/Expr.h
===
--- include/clang/AST/Expr.h
+++ include/clang/AST/Expr.h
@@ -2610,6 +2610,11 @@
 NumArgs = NewNumArgs;
   }
 
+  /// Bluntly set a new number of arguments without doing any checks 
whatsoever.
+  /// Only used during construction of a CallExpr in a few places in Sema.
+  /// FIXME: Find a way to remove it.
+  void setNumArgsUnsafe(unsigned NewNumArgs) { NumArgs = NewNumArgs; }
+
   typedef ExprIterator arg_iterator;
   typedef ConstExprIterator const_arg_iterator;
   typedef llvm::iterator_range arg_range;


Index: test/Sema/typo-correction.c
===
--- test/Sema/typo-correction.c
+++ test/Sema/typo-correction.c
@@ -100,3 +100,18 @@
   structVar1.fieldName1.member1, //expected-error{{use of undeclared identifier 'structVar1'}}
   structVar2.fieldName2.member2); //expected-error{{use of undeclared identifier 'structVar2'}}
 }
+
+void PR40286_g(int x, int y);
+void PR40286_h(int x, int y, int z);
+void PR40286_1(int the_value) {
+  PR40286_g(the_walue); // expected-error {{use of undeclared identifier 'the_walue'}}
+}
+void PR40286_2(int the_value) {
+  PR40286_h(the_value, the_walue); // expected-error {{use of undeclared identifier 'the_walue'}}
+}
+void PR40286_3(int the_value) {
+  PR40286_h(the_walue); // expect

[PATCH] D58111: [Sema] Fix a crash in access checking for deduction guides

2019-02-12 Thread Phabricator via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rC353840: [Sema] Fix a crash in access checking for deduction 
guides (authored by ibiryukov, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D58111?vs=186447&id=186450#toc

Repository:
  rC Clang

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

https://reviews.llvm.org/D58111

Files:
  lib/Sema/SemaDeclCXX.cpp
  test/Sema/crash-deduction-guide-access.cpp


Index: test/Sema/crash-deduction-guide-access.cpp
===
--- test/Sema/crash-deduction-guide-access.cpp
+++ test/Sema/crash-deduction-guide-access.cpp
@@ -0,0 +1,11 @@
+// RUN: not %clang_cc1 -x c++ -std=c++17 -fsyntax-only %s
+template 
+class Imp {
+  template 
+  explicit Imp(F f);
+};
+
+template 
+class Cls {
+  explicit Imp() : f() {}
+};
Index: lib/Sema/SemaDeclCXX.cpp
===
--- lib/Sema/SemaDeclCXX.cpp
+++ lib/Sema/SemaDeclCXX.cpp
@@ -3175,7 +3175,11 @@
 //   declared] with the same access [as the template].
 if (auto *DG = dyn_cast(NonTemplateMember)) {
   auto *TD = DG->getDeducedTemplate();
-  if (AS != TD->getAccess()) {
+  // Access specifiers are only meaningful if both the template and the
+  // deduction guide are from the same scope.
+  if (AS != TD->getAccess() &&
+  TD->getDeclContext()->getRedeclContext()->Equals(
+  DG->getDeclContext()->getRedeclContext())) {
 Diag(DG->getBeginLoc(), diag::err_deduction_guide_wrong_access);
 Diag(TD->getBeginLoc(), diag::note_deduction_guide_template_access)
 << TD->getAccess();


Index: test/Sema/crash-deduction-guide-access.cpp
===
--- test/Sema/crash-deduction-guide-access.cpp
+++ test/Sema/crash-deduction-guide-access.cpp
@@ -0,0 +1,11 @@
+// RUN: not %clang_cc1 -x c++ -std=c++17 -fsyntax-only %s
+template 
+class Imp {
+  template 
+  explicit Imp(F f);
+};
+
+template 
+class Cls {
+  explicit Imp() : f() {}
+};
Index: lib/Sema/SemaDeclCXX.cpp
===
--- lib/Sema/SemaDeclCXX.cpp
+++ lib/Sema/SemaDeclCXX.cpp
@@ -3175,7 +3175,11 @@
 //   declared] with the same access [as the template].
 if (auto *DG = dyn_cast(NonTemplateMember)) {
   auto *TD = DG->getDeducedTemplate();
-  if (AS != TD->getAccess()) {
+  // Access specifiers are only meaningful if both the template and the
+  // deduction guide are from the same scope.
+  if (AS != TD->getAccess() &&
+  TD->getDeclContext()->getRedeclContext()->Equals(
+  DG->getDeclContext()->getRedeclContext())) {
 Diag(DG->getBeginLoc(), diag::err_deduction_guide_wrong_access);
 Diag(TD->getBeginLoc(), diag::note_deduction_guide_template_access)
 << TD->getAccess();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


r353840 - [Sema] Fix a crash in access checking for deduction guides

2019-02-12 Thread Ilya Biryukov via cfe-commits
Author: ibiryukov
Date: Tue Feb 12 06:21:44 2019
New Revision: 353840

URL: http://llvm.org/viewvc/llvm-project?rev=353840&view=rev
Log:
[Sema] Fix a crash in access checking for deduction guides

Summary: See the added test for a repro.

Reviewers: sammccall

Reviewed By: sammccall

Subscribers: cfe-commits

Tags: #clang

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

Added:
cfe/trunk/test/Sema/crash-deduction-guide-access.cpp
Modified:
cfe/trunk/lib/Sema/SemaDeclCXX.cpp

Modified: cfe/trunk/lib/Sema/SemaDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclCXX.cpp?rev=353840&r1=353839&r2=353840&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclCXX.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclCXX.cpp Tue Feb 12 06:21:44 2019
@@ -3175,7 +3175,11 @@ Sema::ActOnCXXMemberDeclarator(Scope *S,
 //   declared] with the same access [as the template].
 if (auto *DG = dyn_cast(NonTemplateMember)) {
   auto *TD = DG->getDeducedTemplate();
-  if (AS != TD->getAccess()) {
+  // Access specifiers are only meaningful if both the template and the
+  // deduction guide are from the same scope.
+  if (AS != TD->getAccess() &&
+  TD->getDeclContext()->getRedeclContext()->Equals(
+  DG->getDeclContext()->getRedeclContext())) {
 Diag(DG->getBeginLoc(), diag::err_deduction_guide_wrong_access);
 Diag(TD->getBeginLoc(), diag::note_deduction_guide_template_access)
 << TD->getAccess();

Added: cfe/trunk/test/Sema/crash-deduction-guide-access.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/crash-deduction-guide-access.cpp?rev=353840&view=auto
==
--- cfe/trunk/test/Sema/crash-deduction-guide-access.cpp (added)
+++ cfe/trunk/test/Sema/crash-deduction-guide-access.cpp Tue Feb 12 06:21:44 
2019
@@ -0,0 +1,11 @@
+// RUN: not %clang_cc1 -x c++ -std=c++17 -fsyntax-only %s
+template 
+class Imp {
+  template 
+  explicit Imp(F f);
+};
+
+template 
+class Cls {
+  explicit Imp() : f() {}
+};


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


[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

2019-02-12 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.
Herald added a subscriber: jdoerfert.

Also, need some kind of the stubbed codegen for the mapper




Comment at: include/clang/AST/OpenMPClause.h:4236
+  static OMPMapClause *
+  Create(const ASTContext &C, SourceLocation StartLoc, SourceLocation 
LParenLoc,
+ SourceLocation EndLoc, ArrayRef Vars,

The function has more than 10 parameters, it is not too good. Would be good to 
pack some of them into some kind of structure.



Comment at: include/clang/Sema/Sema.h:9347
   ArrayRef MapTypeModifiersLoc,
+  CXXScopeSpec &MapperIdScopeSpec, DeclarationNameInfo &MapperId,
   OpenMPMapClauseKind MapType, bool IsMapTypeImplicit,

Also would be good to pack some of the params into structure



Comment at: include/clang/Sema/Sema.h:9431
+  OMPClause *ActOnOpenMPMapClause(
+  ArrayRef MapTypeModifiers,
+  ArrayRef MapTypeModifiersLoc,

Same, too many params



Comment at: lib/Sema/SemaLookup.cpp:1074
 
+  if (NameKind == LookupOMPMapperName) {
+// Skip out-of-scope declarations.

Why do we need special processing of the mapper here?



Comment at: lib/Sema/SemaLookup.cpp:1793
   continue;
+else if (NameKind == LookupOMPMapperName) {
+  // Skip out-of-scope declarations.

Again, what's so special in mapper lookup?



Comment at: lib/Sema/SemaOpenMP.cpp:13186-13192
+if (ER.isInvalid()) {
+  continue;
+} else if (ER.isUsable()) {
+  MVLI.UDMapperList.push_back(ER.get());
+} else {
+  MVLI.UDMapperList.push_back(nullptr);
+}

I think this can be simplified:
```
if (ER.isInvalid())
  continue;
MVLI.UDMapperList.push_back(ER.get());
```



Comment at: lib/Sema/SemaOpenMP.cpp:13232-13238
+if (ER.isInvalid()) {
+  continue;
+} else if (ER.isUsable()) {
+  MVLI.UDMapperList.push_back(ER.get());
+} else {
+  MVLI.UDMapperList.push_back(nullptr);
+}

Also can be simplified.



Comment at: lib/Sema/SemaOpenMP.cpp:13363-13369
+  if (ER.isInvalid()) {
+continue;
+  } else if (ER.isUsable()) {
+MVLI.UDMapperList.push_back(ER.get());
+  } else {
+MVLI.UDMapperList.push_back(nullptr);
+  }

Again, simplify



Comment at: lib/Sema/TreeTransform.h:8845
+} else
+  UnresolvedMappers.push_back(nullptr);
+  }

Enclose into braces



Comment at: lib/Serialization/ASTReader.cpp:12312
+  UDMappers.reserve(NumVars);
+  for (unsigned i = 0; i < NumVars; ++i)
+UDMappers.push_back(Record.readExpr());

`i`->`I`


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

https://reviews.llvm.org/D58074



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


[PATCH] D45978: dllexport const variables must have external linkage.

2019-02-12 Thread Zahira Ammarguellat via Phabricator via cfe-commits
zahiraam added a subscriber: z.
zahiraam added inline comments.



Comment at: test/Sema/dllexport-1.c:8
+
+// CHECK: @y = common dso_local dllexport global i32 0, align 4
+

aaron.ballman wrote:
> Are x and z also exported as expected?
Only x and y are exported.


**@x = dso_local dllexport constant i32 3, align 4**
@z = dso_local constant i32 4, align 4
**@y = common dso_local dllexport global i32 0, align 4**

But then if I take this simple case:
extern int const z = 4;

int main() {
  int a = z + 2;
  return a;
}
ksh-3.2$ clang -c test3.c
test3.c:1:18: warning: 'extern' variable has an initializer 
[-Wextern-initializer]
extern int const z = 4;
 ^
1 warning generated.
ksh-3.2$ dumpbin /symbols test3.o | grep External
00F  SECT1  notype ()External | main
**010  SECT5  notype   External | z**
ksh-3.2$
When emitting the IR, z is declared as a local constant (not exported):
@z = dso_local constant i32 4, align 4




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

https://reviews.llvm.org/D45978



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


[PATCH] D45978: dllexport const variables must have external linkage.

2019-02-12 Thread Zahira Ammarguellat via Phabricator via cfe-commits
zahiraam updated this revision to Diff 186460.
zahiraam marked 3 inline comments as done.

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

https://reviews.llvm.org/D45978

Files:
  lib/Sema/SemaDecl.cpp
  test/CodeGen/dllexport.c
  test/Sema/dllexport-1.cpp
  test/Sema/dllexport-2.cpp


Index: test/Sema/dllexport-2.cpp
===
--- /dev/null
+++ test/Sema/dllexport-2.cpp
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -triple i686-win32 -fsyntax-only -fms-extensions -verify %s
+// RUN: %clang_cc1 -triple x86_64-win32 -fsyntax-only -fms-extensions -verify 
-std=c++11 %s
+
+// Export const variable.
+
+__declspec(dllexport) int const j; // expected-error {{default initialization 
of an object of const type 'const int'}} // expected-error {{'j' must have 
external linkage when declared 'dllexport'}}
Index: test/Sema/dllexport-1.cpp
===
--- /dev/null
+++ test/Sema/dllexport-1.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple i686-win32 -fsyntax-only -fms-extensions -verify %s
+// RUN: %clang_cc1 -triple x86_64-win32 -fsyntax-only -fms-extensions -verify 
-std=c++11 %s
+
+// CHECK: @"?x@@3HB" = dso_local dllexport constant i32 3, align 4
+
+// Export const variable initialization.
+
+// expected-no-diagnostics
+__declspec(dllexport) int const x = 3;
Index: test/CodeGen/dllexport.c
===
--- test/CodeGen/dllexport.c
+++ test/CodeGen/dllexport.c
@@ -113,3 +113,29 @@
 // CHECK-DAG: define dso_local dllexport void @precedenceRedecl2()
 void __declspec(dllexport) precedenceRedecl2(void);
 void __declspec(dllimport) precedenceRedecl2(void) {}
+
+// Export const variable.
+
+// CHECK-DAG: @x = dso_local dllexport constant i32 3, align 4
+// CHECK-DAG: @z = dso_local constant i32 4, align 4
+// CHECK-DAG: @y = common dso_local dllexport global i32 0, align 4
+
+__declspec(dllexport) int const x = 3;
+__declspec(dllexport) const int y;
+extern int const z = 4; // expected-warning{{'extern' variable has an 
initializer}}
+
+int main() {
+  int a = x + y + z;
+  return a;
+}
+
+// CHECK-DAG: @a = dso_local dllexport constant i32 3, align 4
+// CHECK-DAG: @b = dso_local constant i32 4, align 4
+
+__declspec(dllexport) int const a = 3;
+extern int const b = 4; // expected-warning{{'extern' variable has an 
initializer}}
+
+int foo() {
+  int c = a + b;
+  return c;
+}
Index: lib/Sema/SemaDecl.cpp
===
--- lib/Sema/SemaDecl.cpp
+++ lib/Sema/SemaDecl.cpp
@@ -11367,6 +11367,16 @@
 !isTemplateInstantiation(VDecl->getTemplateSpecializationKind()))
   Diag(VDecl->getLocation(), diag::warn_extern_init);
 
+// In Microsoft C++ mode, a const variable defined in namespace scope has
+// external linkage by default if the variable is declared with
+// __declspec(dllexport).
+if (Context.getTargetInfo().getCXXABI().isMicrosoft() &&
+getLangOpts().CPlusPlus &&
+VDecl->getType().isLocalConstQualified() &&
+VDecl->hasAttr() &&
+VDecl->getDefinition())
+  VDecl->setStorageClass(SC_Extern);
+
 // C99 6.7.8p4. All file scoped initializers need to be constant.
 if (!getLangOpts().CPlusPlus && !VDecl->isInvalidDecl())
   CheckForConstantInitializer(Init, DclT);


Index: test/Sema/dllexport-2.cpp
===
--- /dev/null
+++ test/Sema/dllexport-2.cpp
@@ -0,0 +1,6 @@
+// RUN: %clang_cc1 -triple i686-win32 -fsyntax-only -fms-extensions -verify %s
+// RUN: %clang_cc1 -triple x86_64-win32 -fsyntax-only -fms-extensions -verify -std=c++11 %s
+
+// Export const variable.
+
+__declspec(dllexport) int const j; // expected-error {{default initialization of an object of const type 'const int'}} // expected-error {{'j' must have external linkage when declared 'dllexport'}}
Index: test/Sema/dllexport-1.cpp
===
--- /dev/null
+++ test/Sema/dllexport-1.cpp
@@ -0,0 +1,9 @@
+// RUN: %clang_cc1 -triple i686-win32 -fsyntax-only -fms-extensions -verify %s
+// RUN: %clang_cc1 -triple x86_64-win32 -fsyntax-only -fms-extensions -verify -std=c++11 %s
+
+// CHECK: @"?x@@3HB" = dso_local dllexport constant i32 3, align 4
+
+// Export const variable initialization.
+
+// expected-no-diagnostics
+__declspec(dllexport) int const x = 3;
Index: test/CodeGen/dllexport.c
===
--- test/CodeGen/dllexport.c
+++ test/CodeGen/dllexport.c
@@ -113,3 +113,29 @@
 // CHECK-DAG: define dso_local dllexport void @precedenceRedecl2()
 void __declspec(dllexport) precedenceRedecl2(void);
 void __declspec(dllimport) precedenceRedecl2(void) {}
+
+// Export const variable.
+
+// CHECK-DAG: @x = dso_local dllexport constant i32 3, align 4
+// CHECK-DAG: @z = dso_local constant i32 4, align 4
+// 

[PATCH] D58120: [Builtins] Treat `bcmp` as a builtin.

2019-02-12 Thread Clement Courbet via Phabricator via cfe-commits
courbet created this revision.
courbet added a reviewer: jyknight.
Herald added a subscriber: kristina.
Herald added a project: clang.

This makes it consistent with `memcmp` and `__builtin_bcmp`.

Also see the discussion in https://reviews.llvm.org/D56593.


Repository:
  rC Clang

https://reviews.llvm.org/D58120

Files:
  include/clang/Basic/Builtins.def
  lib/AST/Decl.cpp
  lib/AST/ExprConstant.cpp
  lib/Sema/SemaChecking.cpp

Index: lib/Sema/SemaChecking.cpp
===
--- lib/Sema/SemaChecking.cpp
+++ lib/Sema/SemaChecking.cpp
@@ -9174,23 +9174,23 @@
 getContainedDynamicClass(PointeeTy, IsContained)) {
 
   unsigned OperationType = 0;
+  const bool IsCmp = BId == Builtin::BImemcmp || BId == Builtin::BIbcmp;
   // "overwritten" if we're warning about the destination for any call
   // but memcmp; otherwise a verb appropriate to the call.
-  if (ArgIdx != 0 || BId == Builtin::BImemcmp) {
+  if (ArgIdx != 0 || IsCmp) {
 if (BId == Builtin::BImemcpy)
   OperationType = 1;
 else if(BId == Builtin::BImemmove)
   OperationType = 2;
-else if (BId == Builtin::BImemcmp)
+else if (IsCmp)
   OperationType = 3;
   }
 
-  DiagRuntimeBehavior(
-Dest->getExprLoc(), Dest,
-PDiag(diag::warn_dyn_class_memaccess)
-  << (BId == Builtin::BImemcmp ? ArgIdx + 2 : ArgIdx)
-  << FnName << IsContained << ContainedRD << OperationType
-  << Call->getCallee()->getSourceRange());
+  DiagRuntimeBehavior(Dest->getExprLoc(), Dest,
+  PDiag(diag::warn_dyn_class_memaccess)
+  << (IsCmp ? ArgIdx + 2 : ArgIdx) << FnName
+  << IsContained << ContainedRD << OperationType
+  << Call->getCallee()->getSourceRange());
 } else if (PointeeTy.hasNonTrivialObjCLifetime() &&
  BId != Builtin::BImemset)
   DiagRuntimeBehavior(
Index: lib/AST/ExprConstant.cpp
===
--- lib/AST/ExprConstant.cpp
+++ lib/AST/ExprConstant.cpp
@@ -8426,6 +8426,7 @@
   case Builtin::BIstrncmp:
   case Builtin::BIwcsncmp:
   case Builtin::BImemcmp:
+  case Builtin::BIbcmp:
   case Builtin::BIwmemcmp:
 // A call to strlen is not a constant expression.
 if (Info.getLangOpts().CPlusPlus11)
@@ -8440,6 +8441,7 @@
   case Builtin::BI__builtin_strncmp:
   case Builtin::BI__builtin_wcsncmp:
   case Builtin::BI__builtin_memcmp:
+  case Builtin::BI__builtin_bcmp:
   case Builtin::BI__builtin_wmemcmp: {
 LValue String1, String2;
 if (!EvaluatePointer(E->getArg(0), String1, Info) ||
@@ -8470,7 +8472,9 @@
 QualType CharTy2 = String2.Designator.getType(Info.Ctx);
 
 bool IsRawByte = BuiltinOp == Builtin::BImemcmp ||
- BuiltinOp == Builtin::BI__builtin_memcmp;
+ BuiltinOp == Builtin::BIbcmp ||
+ BuiltinOp == Builtin::BI__builtin_memcmp ||
+ BuiltinOp == Builtin::BI__builtin_bcmp;
 
 assert(IsRawByte ||
(Info.Ctx.hasSameUnqualifiedType(
@@ -8538,10 +8542,12 @@
   return Success(0, E);
 }
 
-bool StopAtNull = (BuiltinOp != Builtin::BImemcmp &&
-   BuiltinOp != Builtin::BIwmemcmp &&
-   BuiltinOp != Builtin::BI__builtin_memcmp &&
-   BuiltinOp != Builtin::BI__builtin_wmemcmp);
+bool StopAtNull =
+(BuiltinOp != Builtin::BImemcmp && BuiltinOp != Builtin::BIbcmp &&
+ BuiltinOp != Builtin::BIwmemcmp &&
+ BuiltinOp != Builtin::BI__builtin_memcmp &&
+ BuiltinOp != Builtin::BI__builtin_bcmp &&
+ BuiltinOp != Builtin::BI__builtin_wmemcmp);
 bool IsWide = BuiltinOp == Builtin::BIwcscmp ||
   BuiltinOp == Builtin::BIwcsncmp ||
   BuiltinOp == Builtin::BIwmemcmp ||
Index: lib/AST/Decl.cpp
===
--- lib/AST/Decl.cpp
+++ lib/AST/Decl.cpp
@@ -3672,6 +3672,10 @@
   case Builtin::BImemcmp:
 return Builtin::BImemcmp;
 
+  case Builtin::BI__builtin_bcmp:
+  case Builtin::BIbcmp:
+return Builtin::BIbcmp;
+
   case Builtin::BI__builtin_strncpy:
   case Builtin::BI__builtin___strncpy_chk:
   case Builtin::BIstrncpy:
@@ -3712,6 +3716,8 @@
 return Builtin::BImemmove;
   else if (FnInfo->isStr("memcmp"))
 return Builtin::BImemcmp;
+  else if (FnInfo->isStr("bcmp"))
+return Builtin::BIbcmp;
   else if (FnInfo->isStr("strncpy"))
 return Builtin::BIstrncpy;
   else if (FnInfo->isStr("strncmp"))
Index: include/clang/Basic/Builtins.def
===
--- include/clang/Basic/Builtins.def
+++ include/clang/Basic/Builtins.def
@@ -953,6 +953,7 @@
 LIBBUILTIN(index, "c*cC*i",   "f", "strings.h", ALL_

[PATCH] D58121: [analyzer][WIP] Attempt to fix traversing bindings of non-base regions in ClusterAnalysis

2019-02-12 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun created this revision.
xazax.hun added a reviewer: NoQ.
Herald added subscribers: gamesh411, dkrupp, donat.nagy, Szelethus, 
mikhail.ramalho, a.sidorin, rnkovacs, szepet, baloghadamsoftware, whisperity.
Herald added a project: clang.

Follow up for a problem described in https://reviews.llvm.org/D57230

I think the ClusterAnalysis is fundamentally flawed at this point and it does 
not support non-base regions properly. The reason we could get away with this 
so far is that it is very rare to have non-base regions there.

I made an attempt to fix this and I successfully fixes the false positive 
described by Artem in https://reviews.llvm.org/D57230 but it introduced some 
other problems.
Nevertheless, I wanted to share the work in progress solution to get some 
feedback about the directions.


Repository:
  rC Clang

https://reviews.llvm.org/D58121

Files:
  lib/StaticAnalyzer/Core/CallEvent.cpp
  lib/StaticAnalyzer/Core/RegionStore.cpp


Index: lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- lib/StaticAnalyzer/Core/RegionStore.cpp
+++ lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -654,7 +654,6 @@
 template 
 class ClusterAnalysis  {
 protected:
-  typedef llvm::DenseMap 
ClusterMap;
   typedef const MemRegion * WorkListElement;
   typedef SmallVector WorkList;
 
@@ -726,7 +725,8 @@
   WorkListElement E = WL.pop_back_val();
   const MemRegion *BaseR = E;
 
-  static_cast(this)->VisitCluster(BaseR, getCluster(BaseR));
+  static_cast(this)->VisitCluster(
+  BaseR, getCluster(BaseR->getBaseRegion()));
 }
   }
 
@@ -984,7 +984,7 @@
   bool doNotInvalidateSuperRegion = ITraits.hasTrait(
   R, RegionAndSymbolInvalidationTraits::TK_DoNotInvalidateSuperRegion);
   const MemRegion *BaseR = doNotInvalidateSuperRegion ? R : R->getBaseRegion();
-  return AddToWorkList(WorkListElement(BaseR), getCluster(BaseR));
+  return AddToWorkList(WorkListElement(BaseR), getCluster(R->getBaseRegion()));
 }
 
 void InvalidateRegionsWorker::VisitBinding(SVal V) {
@@ -1020,13 +1020,23 @@
RegionAndSymbolInvalidationTraits::TK_PreserveContents);
 
   if (C) {
-for (ClusterBindings::iterator I = C->begin(), E = C->end(); I != E; ++I)
-  VisitBinding(I.getData());
+const MemRegion *realBase = baseR->getBaseRegion();
+if (realBase == baseR) {
+  for (ClusterBindings::iterator I = C->begin(), E = C->end(); I != E; ++I)
+VisitBinding(I.getData());
+} else {
+  if (const SVal *Direct =
+  C->lookup(BindingKey::Make(baseR, BindingKey::Direct)))
+VisitBinding(*Direct);
+  else if (const SVal *Default =
+   C->lookup(BindingKey::Make(baseR, BindingKey::Default)))
+VisitBinding(*Default);
+}
 
 // Invalidate regions contents.
 if (!PreserveRegionsContents)
   B = B.remove(baseR);
-  }
+  } 
 
   if (const auto *TO = dyn_cast(baseR)) {
 if (const auto *RD = TO->getValueType()->getAsCXXRecordDecl()) {
Index: lib/StaticAnalyzer/Core/CallEvent.cpp
===
--- lib/StaticAnalyzer/Core/CallEvent.cpp
+++ lib/StaticAnalyzer/Core/CallEvent.cpp
@@ -314,7 +314,7 @@
   }
 }
   }
-  // todo: factor this out + handle the lower level const pointers.
+  // TODO: factor this out + handle the lower level const pointers.
   if (PreserveArgs.count(Idx))
 ETraits.setTrait(
 UseBaseRegion ? MR->getBaseRegion() : MR,


Index: lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- lib/StaticAnalyzer/Core/RegionStore.cpp
+++ lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -654,7 +654,6 @@
 template 
 class ClusterAnalysis  {
 protected:
-  typedef llvm::DenseMap ClusterMap;
   typedef const MemRegion * WorkListElement;
   typedef SmallVector WorkList;
 
@@ -726,7 +725,8 @@
   WorkListElement E = WL.pop_back_val();
   const MemRegion *BaseR = E;
 
-  static_cast(this)->VisitCluster(BaseR, getCluster(BaseR));
+  static_cast(this)->VisitCluster(
+  BaseR, getCluster(BaseR->getBaseRegion()));
 }
   }
 
@@ -984,7 +984,7 @@
   bool doNotInvalidateSuperRegion = ITraits.hasTrait(
   R, RegionAndSymbolInvalidationTraits::TK_DoNotInvalidateSuperRegion);
   const MemRegion *BaseR = doNotInvalidateSuperRegion ? R : R->getBaseRegion();
-  return AddToWorkList(WorkListElement(BaseR), getCluster(BaseR));
+  return AddToWorkList(WorkListElement(BaseR), getCluster(R->getBaseRegion()));
 }
 
 void InvalidateRegionsWorker::VisitBinding(SVal V) {
@@ -1020,13 +1020,23 @@
RegionAndSymbolInvalidationTraits::TK_PreserveContents);
 
   if (C) {
-for (ClusterBindings::iterator I = C->begin(), E = C->end(); I != E; ++I)
-  VisitBinding(I.getData());
+const MemRegion *realBase = baseR->getBaseRegion();
+if (realBase == baseR) {
+  for (C

[PATCH] D57230: [analyzer] Toning down invalidation a bit

2019-02-12 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun added a comment.
Herald added a subscriber: jdoerfert.

Experimental patch is up in https://reviews.llvm.org/D58121
Unfortunately, it is not perfect yet.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D57230



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


[PATCH] D57898: CodeGen: Fix PR40605: split constant structures generated by -ftrivial-auto-var-init when emitting initializators

2019-02-12 Thread Alexander Potapenko via Phabricator via cfe-commits
glider marked 4 inline comments as done.
glider added inline comments.
Herald added a subscriber: jdoerfert.



Comment at: tools/clang/test/CodeGenCXX/auto-var-init.cpp:496
 // ZERO-LABEL: @test_smallpartinit_uninit()
 // ZERO: call void @llvm.memset{{.*}}, i8 0,
 

jfb wrote:
> I wonder if (maybe in a separate patch) you also want to avoid `memset` when 
> something is pretty small.
If I'm understanding your request correctly, the same code also handles the 
memset() case for zero-initialization.


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

https://reviews.llvm.org/D57898



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


[PATCH] D58122: Restore Check for Unreachable Exit Block in -Winfinite-recursion

2019-02-12 Thread Robert Widmann via Phabricator via cfe-commits
CodaFi created this revision.
CodaFi added reviewers: steven_wu, rtrieu.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

When this was rewritten in D43737 , the logic 
changed to better explore infinite loops. The check for a reachable exit block 
was deleted which accidentally introduced false positives in case the exit node 
was unreachable.

We were testing for cases like this, but @steven_wu provided an additional test 
case that I've included in the regression tests for this patch.


Repository:
  rC Clang

https://reviews.llvm.org/D58122

Files:
  lib/Sema/AnalysisBasedWarnings.cpp
  test/SemaCXX/warn-infinite-recursion.cpp


Index: test/SemaCXX/warn-infinite-recursion.cpp
===
--- test/SemaCXX/warn-infinite-recursion.cpp
+++ test/SemaCXX/warn-infinite-recursion.cpp
@@ -53,19 +53,28 @@
   return 5 + j();
 }
 
-void k() {  // expected-warning{{call itself}}
+// Don't warn on infinite loops
+void k() {
   while(true) {
 k();
   }
 }
 
-// Don't warn on infinite loops
 void l() {
   while (true) {}
 
   l();
 }
 
+void m() {
+  static int count = 5;
+  if (count >0) {
+count--;
+l();
+  }
+  while (true) {}
+}
+
 class S {
   static void a();
   void b();
Index: lib/Sema/AnalysisBasedWarnings.cpp
===
--- lib/Sema/AnalysisBasedWarnings.cpp
+++ lib/Sema/AnalysisBasedWarnings.cpp
@@ -249,6 +249,10 @@
   CFG *cfg = AC.getCFG();
   if (!cfg) return;
 
+  // If the exit block is unreachable, skip processing the function.
+  if (cfg->getExit().pred_empty())
+return;
+
   // Emit diagnostic if a recursive function call is detected for all paths.
   if (checkForRecursiveFunctionCall(FD, cfg))
 S.Diag(Body->getBeginLoc(), diag::warn_infinite_recursive_function);


Index: test/SemaCXX/warn-infinite-recursion.cpp
===
--- test/SemaCXX/warn-infinite-recursion.cpp
+++ test/SemaCXX/warn-infinite-recursion.cpp
@@ -53,19 +53,28 @@
   return 5 + j();
 }
 
-void k() {  // expected-warning{{call itself}}
+// Don't warn on infinite loops
+void k() {
   while(true) {
 k();
   }
 }
 
-// Don't warn on infinite loops
 void l() {
   while (true) {}
 
   l();
 }
 
+void m() {
+  static int count = 5;
+  if (count >0) {
+count--;
+l();
+  }
+  while (true) {}
+}
+
 class S {
   static void a();
   void b();
Index: lib/Sema/AnalysisBasedWarnings.cpp
===
--- lib/Sema/AnalysisBasedWarnings.cpp
+++ lib/Sema/AnalysisBasedWarnings.cpp
@@ -249,6 +249,10 @@
   CFG *cfg = AC.getCFG();
   if (!cfg) return;
 
+  // If the exit block is unreachable, skip processing the function.
+  if (cfg->getExit().pred_empty())
+return;
+
   // Emit diagnostic if a recursive function call is detected for all paths.
   if (checkForRecursiveFunctionCall(FD, cfg))
 S.Diag(Body->getBeginLoc(), diag::warn_infinite_recursive_function);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D58067: [Analyzer] Crash fix for FindLastStoreBRVisitor

2019-02-12 Thread Balogh, Ádám via Phabricator via cfe-commits
baloghadamsoftware updated this revision to Diff 186470.
baloghadamsoftware marked 3 inline comments as not done.
baloghadamsoftware added a comment.
Herald added a subscriber: jdoerfert.

Function renamed, comment updated.


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

https://reviews.llvm.org/D58067

Files:
  lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
  test/Analysis/PR40625.cpp
  test/Analysis/const_array.cpp
  test/Analysis/uninit-vals.m

Index: test/Analysis/uninit-vals.m
===
--- test/Analysis/uninit-vals.m
+++ test/Analysis/uninit-vals.m
@@ -394,11 +394,11 @@
   struct {
 int : 4;
 int y : 4;
-  } a, b, c;
+  } a, b, c; // expected-note{{'c' initialized here}}
 
   a.y = 2;
 
-  b = a; // expected-note{{Value assigned to 'c'}}
+  b = a;
   clang_analyzer_eval(b.y == 2); // expected-warning{{TRUE}}
  // expected-note@-1{{TRUE}}
 
@@ -411,11 +411,11 @@
   struct {
 int x : 4;
 int : 4;
-  } a, b, c;
+  } a, b, c; // expected-note{{'c' initialized here}}
 
   a.x = 1;
 
-  b = a; // expected-note{{Value assigned to 'c'}}
+  b = a;
   clang_analyzer_eval(b.x == 1); // expected-warning{{TRUE}}
  // expected-note@-1{{TRUE}}
 
Index: test/Analysis/const_array.cpp
===
--- test/Analysis/const_array.cpp
+++ /dev/null
@@ -1,22 +0,0 @@
-// RUN: %clang_analyze_cc1 -std=c++11 -analyzer-checker=core,alpha.core.CallAndMessageUnInitRefArg  %s -verify
-
-// expect-no-diagnostics
-
-const int arr[] = {1, 2, 3, 4, 5, 6, 7, 8, 9, 10};
-
-void f(const int *begin, const int *end) {
-  int sum = 0;
-  for (const int *p = begin; p != end; ++p) {
-sum += *p;
-  }
-}
-
-typedef const int intarray[10];
-
-void g(const intarray &arrr) {
-  f(arrr, arrr+sizeof(arrr));
-}
-
-void h() {
-  g(arr);
-}
Index: test/Analysis/PR40625.cpp
===
--- /dev/null
+++ test/Analysis/PR40625.cpp
@@ -0,0 +1,16 @@
+// RUN: %clang_analyze_cc1 -std=c++11 -analyzer-checker=core,alpha.core.CallAndMessageUnInitRefArg  %s -verify
+
+void f(const int *end);
+
+void g(const int (&arrr)[10]) {
+  f(arrr+sizeof(arrr)); // expected-warning{{1st function call argument is a pointer to uninitialized value}}
+  // FIXME: This is a false positive that should be fixed. Until then this
+  //tests the crash fix in FindLastStoreBRVisitor (beside
+  //uninit-vals.m).
+}
+
+void h() {
+  int arr[10];
+
+  g(arr);
+}
Index: lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
===
--- lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
+++ lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
@@ -153,6 +153,32 @@
   return E;
 }
 
+/// Comparing internal representations of symbolic values (via
+/// SVal::operator==()) is a valid way to check if the value was updated,
+/// unless it's a LazyCompoundVal that may have a different internal
+/// representation every time it is loaded from the state. In this function we
+/// do an approximate comparison for lazy compound values, checking that they
+/// are the immediate snapshots of the tracked region's bindings within the
+/// node's respective states but not really checking that these snapshots
+/// actually contain the same set of bindings.
+bool hasVisibleUpdate(const ExplodedNode *LeftNode, SVal LeftVal,
+  const ExplodedNode *RightNode, SVal RightVal) {
+  if (LeftVal == RightVal)
+return true;
+
+  const auto LLCV = LeftVal.getAs();
+  if (!LLCV)
+return false;
+
+  const auto RLCV = RightVal.getAs();
+  if (!RLCV)
+return false;
+
+  return LLCV->getRegion() == RLCV->getRegion() &&
+LLCV->getStore() == LeftNode->getState()->getStore() &&
+RLCV->getStore() == RightNode->getState()->getStore();
+}
+
 //===--===//
 // Definitions for bug reporter visitors.
 //===--===//
@@ -1177,7 +1203,7 @@
 if (Succ->getState()->getSVal(R) != V)
   return nullptr;
 
-if (Pred->getState()->getSVal(R) == V) {
+if (hasVisibleUpdate(Pred, Pred->getState()->getSVal(R), Succ, V)) {
   Optional PS = Succ->getLocationAs();
   if (!PS || PS->getLocationValue() != R)
 return nullptr;
@@ -1198,6 +1224,7 @@
 // UndefinedVal.)
 if (Optional CE = Succ->getLocationAs()) {
   if (const auto *VR = dyn_cast(R)) {
+
 const auto *Param = cast(VR->getDecl());
 
 ProgramStateManager &StateMgr = BRC.getStateManager();
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57898: CodeGen: Fix PR40605: split constant structures generated by -ftrivial-auto-var-init when emitting initializators

2019-02-12 Thread Alexander Potapenko via Phabricator via cfe-commits
glider updated this revision to Diff 186469.
glider marked an inline comment as done.
glider added a subscriber: pcc.
glider added a comment.

Added a helper function to decide whether we want to break the structure or not.
Right now it only checks for optimization level and structure size.

The constant 64 is picked to match the cacheline size. Other interesting 
numbers I've considered  were:

- 160 - a size of a kernel structure for which the initialization was inlined 
without any noticeable profit (no stores to that uninit structure in the same 
function)
- 256 - the maximum size for an inlined memset/memcpy with -mno-sse
- 512 - the maximum size for an inlined memset/memcpy with SSE enabled/

I don't think we have enough data to back any of the choices though.

I've also fixed the code to skip zero-size memset() calls.


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

https://reviews.llvm.org/D57898

Files:
  tools/clang/lib/CodeGen/CGDecl.cpp
  tools/clang/test/CodeGenCXX/auto-var-init.cpp

Index: tools/clang/test/CodeGenCXX/auto-var-init.cpp
===
--- tools/clang/test/CodeGenCXX/auto-var-init.cpp
+++ tools/clang/test/CodeGenCXX/auto-var-init.cpp
@@ -1,6 +1,8 @@
 // RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -fblocks %s -emit-llvm -o - | FileCheck %s
-// RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -fblocks -ftrivial-auto-var-init=pattern %s -emit-llvm -o - | FileCheck %s -check-prefix=PATTERN
-// RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -fblocks -ftrivial-auto-var-init=zero %s -emit-llvm -o - | FileCheck %s -check-prefix=ZERO
+// RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -fblocks -ftrivial-auto-var-init=pattern %s -emit-llvm -o - | FileCheck %s -check-prefixes=PATTERN,PATTERN-O0
+// RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -fblocks -ftrivial-auto-var-init=pattern %s -O1 -emit-llvm -o - | FileCheck %s -check-prefixes=PATTERN,PATTERN-O1
+// RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -fblocks -ftrivial-auto-var-init=zero %s -emit-llvm -o - | FileCheck %s -check-prefixes=ZERO,ZERO-O0
+// RUN: %clang_cc1 -std=c++14 -triple x86_64-unknown-unknown -fblocks -ftrivial-auto-var-init=zero %s -O1 -emit-llvm -o - | FileCheck %s -check-prefixes=ZERO,ZERO-O1
 
 template void used(T &) noexcept;
 
@@ -30,104 +32,104 @@
 // PATTERN-NOT: undef
 // ZERO-NOT: undef
 
-// PATTERN: @__const.test_empty_uninit.uninit = private unnamed_addr constant %struct.empty { i8 -86 }, align 1
+// PATTERN-O0: @__const.test_empty_uninit.uninit = private unnamed_addr constant %struct.empty { i8 -86 }, align 1
 struct empty {};
-// PATTERN: @__const.test_small_uninit.uninit = private unnamed_addr constant %struct.small { i8 -86 }, align 1
-// PATTERN: @__const.test_small_custom.custom = private unnamed_addr constant %struct.small { i8 42 }, align 1
-// ZERO: @__const.test_small_custom.custom = private unnamed_addr constant %struct.small { i8 42 }, align 1
+// PATTERN-O0: @__const.test_small_uninit.uninit = private unnamed_addr constant %struct.small { i8 -86 }, align 1
+// PATTERN-O0: @__const.test_small_custom.custom = private unnamed_addr constant %struct.small { i8 42 }, align 1
+// ZERO-O0: @__const.test_small_custom.custom = private unnamed_addr constant %struct.small { i8 42 }, align 1
 struct small { char c; };
-// PATTERN: @__const.test_smallinit_uninit.uninit = private unnamed_addr constant %struct.smallinit { i8 -86 }, align 1
-// PATTERN: @__const.test_smallinit_braces.braces = private unnamed_addr constant %struct.smallinit { i8 -86 }, align 1
-// PATTERN: @__const.test_smallinit_custom.custom = private unnamed_addr constant %struct.smallinit { i8 -86 }, align 1
+// PATTERN-O0: @__const.test_smallinit_uninit.uninit = private unnamed_addr constant %struct.smallinit { i8 -86 }, align 1
+// PATTERN-O0: @__const.test_smallinit_braces.braces = private unnamed_addr constant %struct.smallinit { i8 -86 }, align 1
+// PATTERN-O0: @__const.test_smallinit_custom.custom = private unnamed_addr constant %struct.smallinit { i8 -86 }, align 1
 struct smallinit { char c = 42; };
-// PATTERN: @__const.test_smallpartinit_uninit.uninit = private unnamed_addr constant %struct.smallpartinit { i8 -86, i8 -86 }, align 1
-// PATTERN: @__const.test_smallpartinit_braces.braces = private unnamed_addr constant %struct.smallpartinit { i8 -86, i8 -86 }, align 1
-// PATTERN: @__const.test_smallpartinit_custom.custom = private unnamed_addr constant %struct.smallpartinit { i8 -86, i8 -86 }, align 1
+// PATTERN-O0: @__const.test_smallpartinit_uninit.uninit = private unnamed_addr constant %struct.smallpartinit { i8 -86, i8 -86 }, align 1
+// PATTERN-O0: @__const.test_smallpartinit_braces.braces = private unnamed_addr constant %struct.smallpartinit { i8 -86, i8 -86 }, align 1
+// PATTERN-O0: @__const.test_smallpartinit_custom.custom = private unnamed_addr constant %struct.smallpartinit { i8 

[PATCH] D54978: Move the SMT API to LLVM

2019-02-12 Thread Brian Rzycki via Phabricator via cfe-commits
brzycki added a comment.

In D54978#1394613 , @thakis wrote:

> Got it now, sorry about being dense.


No problem, I appreciate you looking into this. :)

I hope to have some time in the next few days to help out and debug this 
further.


Repository:
  rC Clang

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

https://reviews.llvm.org/D54978



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


[PATCH] D58126: [clangd] Fix a lit-test.

2019-02-12 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet created this revision.
kadircet added a reviewer: sammccall.
Herald added subscribers: cfe-commits, arphaman, jkorous, MaskRay, ioeric, 
ilya-biryukov.
Herald added a project: clang.

Fixes https://bugs.llvm.org/show_bug.cgi?id=40593.
Non-percent-encoded chars doesn't cause any problems on the input-side since we
assume everything after authority section is data and don't interpret them as
delimeters.


Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D58126

Files:
  test/clangd/Inputs/background-index/definition.jsonrpc


Index: test/clangd/Inputs/background-index/definition.jsonrpc
===
--- test/clangd/Inputs/background-index/definition.jsonrpc
+++ test/clangd/Inputs/background-index/definition.jsonrpc
@@ -44,7 +44,7 @@
 }
   }
 }
-# CHECK: "uri": "file://DIRECTORY/foo.cpp"
+# CHECK: "uri": "file://{{.*}}/foo.cpp"
 ---
 {"jsonrpc":"2.0","id":3,"method":"shutdown"}
 ---


Index: test/clangd/Inputs/background-index/definition.jsonrpc
===
--- test/clangd/Inputs/background-index/definition.jsonrpc
+++ test/clangd/Inputs/background-index/definition.jsonrpc
@@ -44,7 +44,7 @@
 }
   }
 }
-# CHECK: "uri": "file://DIRECTORY/foo.cpp"
+# CHECK: "uri": "file://{{.*}}/foo.cpp"
 ---
 {"jsonrpc":"2.0","id":3,"method":"shutdown"}
 ---
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D45978: dllexport const variables must have external linkage.

2019-02-12 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: test/Sema/dllexport-1.c:1
+// RUN: %clang_cc1 -triple i686-win32 -emit-llvm -fms-extensions -std=c99 < 
%s| FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-win32 -emit-llvm -fms-extensions -std=c11 < 
%s | FileCheck %s

aaron.ballman wrote:
> This test should live in CodeGen not Sema.
Do we need this many RUN lines? Also, why the different language modes? Also, 
do you need to use `<` in the command?



Comment at: test/Sema/dllexport-1.c:8
+
+// CHECK: @y = common dso_local dllexport global i32 0, align 4
+

zahiraam wrote:
> aaron.ballman wrote:
> > Are x and z also exported as expected?
> Only x and y are exported.
> 
> 
> **@x = dso_local dllexport constant i32 3, align 4**
> @z = dso_local constant i32 4, align 4
> **@y = common dso_local dllexport global i32 0, align 4**
> 
> But then if I take this simple case:
> extern int const z = 4;
> 
> int main() {
>   int a = z + 2;
>   return a;
> }
> ksh-3.2$ clang -c test3.c
> test3.c:1:18: warning: 'extern' variable has an initializer 
> [-Wextern-initializer]
> extern int const z = 4;
>  ^
> 1 warning generated.
> ksh-3.2$ dumpbin /symbols test3.o | grep External
> 00F  SECT1  notype ()External | main
> **010  SECT5  notype   External | z**
> ksh-3.2$
> When emitting the IR, z is declared as a local constant (not exported):
> @z = dso_local constant i32 4, align 4
> 
> 
Okay, please add the expected CHECK lines for `x` and `z` to the test. Thank 
you for clarifying!



Comment at: test/Sema/dllexport-1.cpp:2
+// RUN: %clang_cc1 -triple i686-win32 -fsyntax-only -fms-extensions -verify %s
+// RUN: %clang_cc1 -triple x86_64-win32 -fsyntax-only -fms-extensions -verify 
-std=c++11 %s
+

I don't think we need this RUN line. I don't know if we need the triple in the 
previous RUN line either.



Comment at: test/Sema/dllexport-1.cpp:4
+
+// CHECK: @"?x@@3HB" = dso_local dllexport constant i32 3, align 4
+

aaron.ballman wrote:
> This test has no FileCheck line.
> 
> The goal here is for the tests in Sema to test the semantic behavior (that 
> warnings are issued when expected and not issued when not expected) and to 
> add tests in CodeGen to test the generated code (are things properly 
> exported, are things we don't expect to be exported not exported, etc). I 
> think you should split your tests accordingly rather than try to verify too 
> much at once.
This CHECK line still has no impact; I think it should be removed from the test.



Comment at: test/Sema/dllexport-2.cpp:2
+// RUN: %clang_cc1 -triple i686-win32 -fsyntax-only -fms-extensions -verify %s
+// RUN: %clang_cc1 -triple x86_64-win32 -fsyntax-only -fms-extensions -verify 
-std=c++11 %s
+

I don't think we need this RUN line. I don't know if we need the triple in the 
previous RUN line either.


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

https://reviews.llvm.org/D45978



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


[PATCH] D45978: dllexport const variables must have external linkage.

2019-02-12 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

Oops, sorry, I think I added some comments to a previous revision of the 
review. To recap:

1. Remove the CHECK line from test/Sema/dllexport-1.cpp
2. Remove the second RUN line from test/Sema/dllexport-1.cpp and 
test/Sema/dllexport-2.cpp
3. Possibly remove the triples from the RUN line in test/Sema/dllexport-1.cpp 
and test/Sema/dllexport-2.cpp


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

https://reviews.llvm.org/D45978



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


[PATCH] D58065: [analyzer] Document the frontend library

2019-02-12 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added a comment.
Herald added a subscriber: jdoerfert.

Please, in the first round of reviews, if you could make high level comments 
about what should or should not be here would be great, perfectly wrapping 
around the 80 column limit and finding typos don't concern me as much before 
the actual content is ready.


Repository:
  rC Clang

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

https://reviews.llvm.org/D58065



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


[PATCH] D58126: [clangd] Fix a lit-test.

2019-02-12 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

Hmm, this removes a useful assertion, and still leaves us sending invalid (or 
at least non-canonical) URIs in the input.
But I don't see a better fix really - lit tests are painful :-(


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D58126



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


r353853 - [CMake][Fuchsia] Pass -ldl -lpthread LDFLAGS to second stage

2019-02-12 Thread Petr Hosek via cfe-commits
Author: phosek
Date: Tue Feb 12 08:24:46 2019
New Revision: 353853

URL: http://llvm.org/viewvc/llvm-project?rev=353853&view=rev
Log:
[CMake][Fuchsia] Pass -ldl -lpthread LDFLAGS to second stage

We're using static libc++ for the second stage which requires explicitly
linking -ldl and -lpthread.

Modified:
cfe/trunk/cmake/caches/Fuchsia.cmake

Modified: cfe/trunk/cmake/caches/Fuchsia.cmake
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/cmake/caches/Fuchsia.cmake?rev=353853&r1=353852&r2=353853&view=diff
==
--- cfe/trunk/cmake/caches/Fuchsia.cmake (original)
+++ cfe/trunk/cmake/caches/Fuchsia.cmake Tue Feb 12 08:24:46 2019
@@ -74,6 +74,12 @@ if(BOOTSTRAP_CMAKE_SYSTEM_NAME)
   endif()
 endif()
 
+if(UNIX)
+  set(BOOTSTRAP_CMAKE_SHARED_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
+  set(BOOTSTRAP_CMAKE_MODULE_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
+  set(BOOTSTRAP_CMAKE_EXE_LINKER_FLAGS "-ldl -lpthread" CACHE STRING "")
+endif()
+
 set(BOOTSTRAP_LLVM_ENABLE_LTO ON CACHE BOOL "")
 if(NOT APPLE)
   set(BOOTSTRAP_LLVM_ENABLE_LLD ON CACHE BOOL "")


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


[PATCH] D58128: [PowerPC] Stop defining _ARCH_PWR6X on POWER7 and up

2019-02-12 Thread Hubert Tong via Phabricator via cfe-commits
hubert.reinterpretcast created this revision.
hubert.reinterpretcast added reviewers: echristo, hfinkel, kbarton, nemanjai, 
wschmidt.
Herald added a subscriber: jsji.
Herald added a project: clang.

The predefined macro `_ARCH_PWR6X` is associated with GCC's `-mcpu=power6x` 
option, which enables generation of P6  "raw mode" 
instructions such as `mftgpr`.

Later POWER processors build upon the "architected mode", not the raw one. 
`_ARCH_PWR6X` should not be defined for these later processors.

Fixes PR#40236.


Repository:
  rC Clang

https://reviews.llvm.org/D58128

Files:
  lib/Basic/Targets/PPC.h
  test/Preprocessor/init.c


Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -5991,7 +5991,7 @@
 // PPC64LE:#define _ARCH_PWR5 1
 // PPC64LE:#define _ARCH_PWR5X 1
 // PPC64LE:#define _ARCH_PWR6 1
-// PPC64LE:#define _ARCH_PWR6X 1
+// PPC64LE-NOT:#define _ARCH_PWR6X 1
 // PPC64LE:#define _ARCH_PWR7 1
 // PPC64LE:#define _CALL_ELF 2
 // PPC64LE:#define _LITTLE_ENDIAN 1
@@ -6331,7 +6331,7 @@
 // PPCPWR7:#define _ARCH_PWR5 1
 // PPCPWR7:#define _ARCH_PWR5X 1
 // PPCPWR7:#define _ARCH_PWR6 1
-// PPCPWR7:#define _ARCH_PWR6X 1
+// PPCPWR7-NOT:#define _ARCH_PWR6X 1
 // PPCPWR7:#define _ARCH_PWR7 1
 //
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-none-none 
-target-cpu power7 -fno-signed-char < /dev/null | FileCheck -match-full-lines 
-check-prefix PPCPOWER7 %s
@@ -6344,7 +6344,7 @@
 // PPCPOWER7:#define _ARCH_PWR5 1
 // PPCPOWER7:#define _ARCH_PWR5X 1
 // PPCPOWER7:#define _ARCH_PWR6 1
-// PPCPOWER7:#define _ARCH_PWR6X 1
+// PPCPOWER7-NOT:#define _ARCH_PWR6X 1
 // PPCPOWER7:#define _ARCH_PWR7 1
 //
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-none-none 
-target-cpu pwr8 -fno-signed-char < /dev/null | FileCheck -match-full-lines 
-check-prefix PPCPWR8 %s
@@ -6357,7 +6357,7 @@
 // PPCPWR8:#define _ARCH_PWR5 1
 // PPCPWR8:#define _ARCH_PWR5X 1
 // PPCPWR8:#define _ARCH_PWR6 1
-// PPCPWR8:#define _ARCH_PWR6X 1
+// PPCPWR8-NOT:#define _ARCH_PWR6X 1
 // PPCPWR8:#define _ARCH_PWR7 1
 // PPCPWR8:#define _ARCH_PWR8 1
 //
@@ -6374,7 +6374,7 @@
 // PPCPOWER8:#define _ARCH_PWR5 1
 // PPCPOWER8:#define _ARCH_PWR5X 1
 // PPCPOWER8:#define _ARCH_PWR6 1
-// PPCPOWER8:#define _ARCH_PWR6X 1
+// PPCPOWER8-NOT:#define _ARCH_PWR6X 1
 // PPCPOWER8:#define _ARCH_PWR7 1
 // PPCPOWER8:#define _ARCH_PWR8 1
 //
@@ -6388,7 +6388,7 @@
 // PPCPWR9:#define _ARCH_PWR5 1
 // PPCPWR9:#define _ARCH_PWR5X 1
 // PPCPWR9:#define _ARCH_PWR6 1
-// PPCPWR9:#define _ARCH_PWR6X 1
+// PPCPWR9-NOT:#define _ARCH_PWR6X 1
 // PPCPWR9:#define _ARCH_PWR7 1
 // PPCPWR9:#define _ARCH_PWR9 1
 //
@@ -6402,7 +6402,7 @@
 // PPCPOWER9:#define _ARCH_PWR5 1
 // PPCPOWER9:#define _ARCH_PWR5X 1
 // PPCPOWER9:#define _ARCH_PWR6 1
-// PPCPOWER9:#define _ARCH_PWR6X 1
+// PPCPOWER9-NOT:#define _ARCH_PWR6X 1
 // PPCPOWER9:#define _ARCH_PWR7 1
 // PPCPOWER9:#define _ARCH_PWR9 1
 //
Index: lib/Basic/Targets/PPC.h
===
--- lib/Basic/Targets/PPC.h
+++ lib/Basic/Targets/PPC.h
@@ -131,19 +131,18 @@
 ArchDefinePwr5 | ArchDefinePwr4 | ArchDefinePpcgr |
 ArchDefinePpcsq)
   .Cases("power7", "pwr7",
-ArchDefinePwr7 | ArchDefinePwr6x | ArchDefinePwr6 |
-ArchDefinePwr5x | ArchDefinePwr5 | ArchDefinePwr4 |
-ArchDefinePpcgr | ArchDefinePpcsq)
+ ArchDefinePwr7 | ArchDefinePwr6 | ArchDefinePwr5x |
+ ArchDefinePwr5 | ArchDefinePwr4 | ArchDefinePpcgr |
+ ArchDefinePpcsq)
   // powerpc64le automatically defaults to at least power8.
   .Cases("power8", "pwr8", "ppc64le",
-ArchDefinePwr8 | ArchDefinePwr7 | ArchDefinePwr6x |
-ArchDefinePwr6 | ArchDefinePwr5x | ArchDefinePwr5 |
-ArchDefinePwr4 | ArchDefinePpcgr | ArchDefinePpcsq)
+ ArchDefinePwr8 | ArchDefinePwr7 | ArchDefinePwr6 |
+ ArchDefinePwr5x | ArchDefinePwr5 | ArchDefinePwr4 |
+ ArchDefinePpcgr | ArchDefinePpcsq)
   .Cases("power9", "pwr9",
-ArchDefinePwr9 | ArchDefinePwr8 | ArchDefinePwr7 |
-ArchDefinePwr6x | ArchDefinePwr6 | ArchDefinePwr5x |
-ArchDefinePwr5 | ArchDefinePwr4 | ArchDefinePpcgr |
-ArchDefinePpcsq)
+ ArchDefinePwr9 | ArchDefinePwr8 | ArchDefinePwr7 |
+ ArchDefinePwr6 | ArchDefinePwr5x | ArchDefinePwr5 |
+ ArchDefinePwr4 | ArchDefinePpcgr | ArchDefinePpcsq)
   .Default(ArchDefineNone);
 }
 return CPUKnown;


Index: test/Preprocessor/init.c
===

[PATCH] D58133: [clangd] Testcase for bug 39811

2019-02-12 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet created this revision.
Herald added subscribers: cfe-commits, jdoerfert, arphaman, jkorous, MaskRay, 
ioeric, ilya-biryukov.
Herald added a project: clang.

Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D58133

Files:
  unittests/clangd/XRefsTests.cpp


Index: unittests/clangd/XRefsTests.cpp
===
--- unittests/clangd/XRefsTests.cpp
+++ unittests/clangd/XRefsTests.cpp
@@ -1389,6 +1389,35 @@
   }
 }
 
+TEST(GoTo, WithSysRoot) {
+  const char *CustoomRoot = "/sys/root/";
+  Annotations Main(R"cpp(
+  #include "header.h"
+  int main() {
+return f^oo();
+  })cpp");
+  Annotations Header("int [[foo]](){return 42;}");
+
+  MockCompilationDatabase CDB;
+  CDB.ExtraClangFlags = {"--sysroot", CustoomRoot};
+  IgnoreDiagnostics DiagConsumer;
+  MockFSProvider FS;
+  ClangdServer Server(CDB, FS, DiagConsumer, ClangdServer::optsForTest());
+
+  // Fill the filesystem.
+  auto FooCpp = testPath("foo.cpp");
+  FS.Files[FooCpp] = Main.code();
+  auto HeaderPath = (llvm::StringRef(CustoomRoot) + "include/header.h").str();
+  FS.Files[HeaderPath] = Header.code();
+
+  runAddDocument(Server, FooCpp, Main.code());
+
+  // Go to a definition in main source file.
+  auto Locations = runLocateSymbolAt(Server, FooCpp, Main.point());
+  EXPECT_TRUE(bool(Locations)) << "findDefinitions returned an error";
+  EXPECT_THAT(*Locations, ElementsAre(Sym("foo", Header.range(;
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang


Index: unittests/clangd/XRefsTests.cpp
===
--- unittests/clangd/XRefsTests.cpp
+++ unittests/clangd/XRefsTests.cpp
@@ -1389,6 +1389,35 @@
   }
 }
 
+TEST(GoTo, WithSysRoot) {
+  const char *CustoomRoot = "/sys/root/";
+  Annotations Main(R"cpp(
+  #include "header.h"
+  int main() {
+return f^oo();
+  })cpp");
+  Annotations Header("int [[foo]](){return 42;}");
+
+  MockCompilationDatabase CDB;
+  CDB.ExtraClangFlags = {"--sysroot", CustoomRoot};
+  IgnoreDiagnostics DiagConsumer;
+  MockFSProvider FS;
+  ClangdServer Server(CDB, FS, DiagConsumer, ClangdServer::optsForTest());
+
+  // Fill the filesystem.
+  auto FooCpp = testPath("foo.cpp");
+  FS.Files[FooCpp] = Main.code();
+  auto HeaderPath = (llvm::StringRef(CustoomRoot) + "include/header.h").str();
+  FS.Files[HeaderPath] = Header.code();
+
+  runAddDocument(Server, FooCpp, Main.code());
+
+  // Go to a definition in main source file.
+  auto Locations = runLocateSymbolAt(Server, FooCpp, Main.point());
+  EXPECT_TRUE(bool(Locations)) << "findDefinitions returned an error";
+  EXPECT_THAT(*Locations, ElementsAre(Sym("foo", Header.range(;
+}
+
 } // namespace
 } // namespace clangd
 } // namespace clang
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D58121: [analyzer][WIP] Attempt to fix traversing bindings of non-base regions in ClusterAnalysis

2019-02-12 Thread Gábor Horváth via Phabricator via cfe-commits
xazax.hun updated this revision to Diff 186489.
xazax.hun marked an inline comment as done.
xazax.hun edited the summary of this revision.
xazax.hun added a comment.
Herald added a subscriber: jdoerfert.

- Fix test failures.


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

https://reviews.llvm.org/D58121

Files:
  lib/StaticAnalyzer/Core/CallEvent.cpp
  lib/StaticAnalyzer/Core/RegionStore.cpp


Index: lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- lib/StaticAnalyzer/Core/RegionStore.cpp
+++ lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -654,7 +654,6 @@
 template 
 class ClusterAnalysis  {
 protected:
-  typedef llvm::DenseMap 
ClusterMap;
   typedef const MemRegion * WorkListElement;
   typedef SmallVector WorkList;
 
@@ -726,7 +725,8 @@
   WorkListElement E = WL.pop_back_val();
   const MemRegion *BaseR = E;
 
-  static_cast(this)->VisitCluster(BaseR, getCluster(BaseR));
+  static_cast(this)->VisitCluster(
+  BaseR, getCluster(BaseR->getBaseRegion()));
 }
   }
 
@@ -984,7 +984,7 @@
   bool doNotInvalidateSuperRegion = ITraits.hasTrait(
   R, RegionAndSymbolInvalidationTraits::TK_DoNotInvalidateSuperRegion);
   const MemRegion *BaseR = doNotInvalidateSuperRegion ? R : R->getBaseRegion();
-  return AddToWorkList(WorkListElement(BaseR), getCluster(BaseR));
+  return AddToWorkList(WorkListElement(BaseR), getCluster(R));
 }
 
 void InvalidateRegionsWorker::VisitBinding(SVal V) {
@@ -1020,13 +1020,23 @@
RegionAndSymbolInvalidationTraits::TK_PreserveContents);
 
   if (C) {
-for (ClusterBindings::iterator I = C->begin(), E = C->end(); I != E; ++I)
-  VisitBinding(I.getData());
+const MemRegion *realBase = baseR->getBaseRegion();
+if (realBase == baseR) {
+  for (ClusterBindings::iterator I = C->begin(), E = C->end(); I != E; ++I)
+VisitBinding(I.getData());
+} else {
+  if (const SVal *Direct =
+  C->lookup(BindingKey::Make(baseR, BindingKey::Direct)))
+VisitBinding(*Direct);
+  else if (const SVal *Default =
+   C->lookup(BindingKey::Make(baseR, BindingKey::Default)))
+VisitBinding(*Default);
+}
 
 // Invalidate regions contents.
 if (!PreserveRegionsContents)
   B = B.remove(baseR);
-  }
+  } 
 
   if (const auto *TO = dyn_cast(baseR)) {
 if (const auto *RD = TO->getValueType()->getAsCXXRecordDecl()) {
Index: lib/StaticAnalyzer/Core/CallEvent.cpp
===
--- lib/StaticAnalyzer/Core/CallEvent.cpp
+++ lib/StaticAnalyzer/Core/CallEvent.cpp
@@ -314,7 +314,7 @@
   }
 }
   }
-  // todo: factor this out + handle the lower level const pointers.
+  // TODO: factor this out + handle the lower level const pointers.
   if (PreserveArgs.count(Idx))
 ETraits.setTrait(
 UseBaseRegion ? MR->getBaseRegion() : MR,


Index: lib/StaticAnalyzer/Core/RegionStore.cpp
===
--- lib/StaticAnalyzer/Core/RegionStore.cpp
+++ lib/StaticAnalyzer/Core/RegionStore.cpp
@@ -654,7 +654,6 @@
 template 
 class ClusterAnalysis  {
 protected:
-  typedef llvm::DenseMap ClusterMap;
   typedef const MemRegion * WorkListElement;
   typedef SmallVector WorkList;
 
@@ -726,7 +725,8 @@
   WorkListElement E = WL.pop_back_val();
   const MemRegion *BaseR = E;
 
-  static_cast(this)->VisitCluster(BaseR, getCluster(BaseR));
+  static_cast(this)->VisitCluster(
+  BaseR, getCluster(BaseR->getBaseRegion()));
 }
   }
 
@@ -984,7 +984,7 @@
   bool doNotInvalidateSuperRegion = ITraits.hasTrait(
   R, RegionAndSymbolInvalidationTraits::TK_DoNotInvalidateSuperRegion);
   const MemRegion *BaseR = doNotInvalidateSuperRegion ? R : R->getBaseRegion();
-  return AddToWorkList(WorkListElement(BaseR), getCluster(BaseR));
+  return AddToWorkList(WorkListElement(BaseR), getCluster(R));
 }
 
 void InvalidateRegionsWorker::VisitBinding(SVal V) {
@@ -1020,13 +1020,23 @@
RegionAndSymbolInvalidationTraits::TK_PreserveContents);
 
   if (C) {
-for (ClusterBindings::iterator I = C->begin(), E = C->end(); I != E; ++I)
-  VisitBinding(I.getData());
+const MemRegion *realBase = baseR->getBaseRegion();
+if (realBase == baseR) {
+  for (ClusterBindings::iterator I = C->begin(), E = C->end(); I != E; ++I)
+VisitBinding(I.getData());
+} else {
+  if (const SVal *Direct =
+  C->lookup(BindingKey::Make(baseR, BindingKey::Direct)))
+VisitBinding(*Direct);
+  else if (const SVal *Default =
+   C->lookup(BindingKey::Make(baseR, BindingKey::Default)))
+VisitBinding(*Default);
+}
 
 // Invalidate regions contents.
 if (!PreserveRegionsContents)
   B = B.remove(baseR);
-  }
+  } 
 
   if (const auto *TO = dyn_cast(baseR)) {
 if (con

[clang-tools-extra] r353857 - [clangd] Fix a lit-test.

2019-02-12 Thread Kadir Cetinkaya via cfe-commits
Author: kadircet
Date: Tue Feb 12 08:54:47 2019
New Revision: 353857

URL: http://llvm.org/viewvc/llvm-project?rev=353857&view=rev
Log:
[clangd] Fix a lit-test.

Summary:
Fixes https://bugs.llvm.org/show_bug.cgi?id=40593.
Non-percent-encoded chars doesn't cause any problems on the input-side since we
assume everything after authority section is data and don't interpret them as
delimeters.

Reviewers: sammccall

Subscribers: ilya-biryukov, ioeric, MaskRay, jkorous, arphaman, cfe-commits

Tags: #clang

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

Modified:

clang-tools-extra/trunk/test/clangd/Inputs/background-index/definition.jsonrpc

Modified: 
clang-tools-extra/trunk/test/clangd/Inputs/background-index/definition.jsonrpc
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clangd/Inputs/background-index/definition.jsonrpc?rev=353857&r1=353856&r2=353857&view=diff
==
--- 
clang-tools-extra/trunk/test/clangd/Inputs/background-index/definition.jsonrpc 
(original)
+++ 
clang-tools-extra/trunk/test/clangd/Inputs/background-index/definition.jsonrpc 
Tue Feb 12 08:54:47 2019
@@ -44,7 +44,7 @@
 }
   }
 }
-# CHECK: "uri": "file://DIRECTORY/foo.cpp"
+# CHECK: "uri": "file://{{.*}}/foo.cpp"
 ---
 {"jsonrpc":"2.0","id":3,"method":"shutdown"}
 ---


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


[PATCH] D58126: [clangd] Fix a lit-test.

2019-02-12 Thread Kadir Cetinkaya via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rCTE353857: [clangd] Fix a lit-test. (authored by kadircet, 
committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D58126?vs=186475&id=186490#toc

Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D58126

Files:
  test/clangd/Inputs/background-index/definition.jsonrpc


Index: test/clangd/Inputs/background-index/definition.jsonrpc
===
--- test/clangd/Inputs/background-index/definition.jsonrpc
+++ test/clangd/Inputs/background-index/definition.jsonrpc
@@ -44,7 +44,7 @@
 }
   }
 }
-# CHECK: "uri": "file://DIRECTORY/foo.cpp"
+# CHECK: "uri": "file://{{.*}}/foo.cpp"
 ---
 {"jsonrpc":"2.0","id":3,"method":"shutdown"}
 ---


Index: test/clangd/Inputs/background-index/definition.jsonrpc
===
--- test/clangd/Inputs/background-index/definition.jsonrpc
+++ test/clangd/Inputs/background-index/definition.jsonrpc
@@ -44,7 +44,7 @@
 }
   }
 }
-# CHECK: "uri": "file://DIRECTORY/foo.cpp"
+# CHECK: "uri": "file://{{.*}}/foo.cpp"
 ---
 {"jsonrpc":"2.0","id":3,"method":"shutdown"}
 ---
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D58134: [Analysis] -Wunreachable-code shouldn't fire on the increment of a foreach loop

2019-02-12 Thread Sam McCall via Phabricator via cfe-commits
sammccall created this revision.
sammccall added reviewers: ilya-biryukov, ioeric.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

The idea is that the code here isn't written, so doesn't indicate a bug.
Similar to code expanded from macros.

This means the warning no longer fires on this code:

  for (auto C : collection) {
process(C);
return;
  }
  handleEmptyCollection();

Unclear whether this is more often a bug or not in practice, I think it's a
reasonable idiom in some cases.
Either way, if we want to warn on "loop that doesn't loop", I think it should be
a separate warning, and catch `while(1) break;`


Repository:
  rC Clang

https://reviews.llvm.org/D58134

Files:
  lib/Analysis/ReachableCode.cpp
  test/SemaCXX/unreachable-code.cpp


Index: test/SemaCXX/unreachable-code.cpp
===
--- test/SemaCXX/unreachable-code.cpp
+++ test/SemaCXX/unreachable-code.cpp
@@ -52,6 +52,11 @@
   }
 }
 
+void test4() {
+  for (char c : "abc") // no-warning
+break;
+}
+
 // PR 6130 - Don't warn about bogus unreachable code with throw's and
 // temporary objects.
 class PR6130 {
Index: lib/Analysis/ReachableCode.cpp
===
--- lib/Analysis/ReachableCode.cpp
+++ lib/Analysis/ReachableCode.cpp
@@ -631,6 +631,10 @@
 // a for/for-range loop.  This is the block that contains
 // the increment code.
 if (const Stmt *LoopTarget = B->getLoopTarget()) {
+  // The increment on a foreach statement is not written.
+  if (isa(LoopTarget))
+return;
+
   SourceLocation Loc = LoopTarget->getBeginLoc();
   SourceRange R1(Loc, Loc), R2;
 


Index: test/SemaCXX/unreachable-code.cpp
===
--- test/SemaCXX/unreachable-code.cpp
+++ test/SemaCXX/unreachable-code.cpp
@@ -52,6 +52,11 @@
   }
 }
 
+void test4() {
+  for (char c : "abc") // no-warning
+break;
+}
+
 // PR 6130 - Don't warn about bogus unreachable code with throw's and
 // temporary objects.
 class PR6130 {
Index: lib/Analysis/ReachableCode.cpp
===
--- lib/Analysis/ReachableCode.cpp
+++ lib/Analysis/ReachableCode.cpp
@@ -631,6 +631,10 @@
 // a for/for-range loop.  This is the block that contains
 // the increment code.
 if (const Stmt *LoopTarget = B->getLoopTarget()) {
+  // The increment on a foreach statement is not written.
+  if (isa(LoopTarget))
+return;
+
   SourceLocation Loc = LoopTarget->getBeginLoc();
   SourceRange R1(Loc, Loc), R2;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57898: CodeGen: Fix PR40605: split constant structures generated by -ftrivial-auto-var-init when emitting initializators

2019-02-12 Thread Alexander Potapenko via Phabricator via cfe-commits
glider added a comment.

This patch shaved off 2.5% of performance slowdown on 
https://github.com/kamalmarhubi/linux-ipc-benchmarks/blob/master/af_inet_loopback.c
 on a kernel built in pattern-initialization mode.
The .rodata size went down by only 12K (0.5%, since we now split only 
structures smaller than 64 bytes)
The .text size went down by 19K (0.4%)


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

https://reviews.llvm.org/D57898



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


[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

2019-02-12 Thread Lingda Li via Phabricator via cfe-commits
lildmh marked 11 inline comments as done.
lildmh added a comment.

Hi Alexey,

Thanks very much for your quick review!

For the codegen, currently I'm thinking to do it within declare target codegen 
functions. So there is not a very clear interface to do mapper codegen (also, 
there is not a clear interface to do map clause codegen now), and that's why I 
didn't have a stub left in this patch. Please see other detailed responses 
inline.




Comment at: include/clang/AST/OpenMPClause.h:4236
+  static OMPMapClause *
+  Create(const ASTContext &C, SourceLocation StartLoc, SourceLocation 
LParenLoc,
+ SourceLocation EndLoc, ArrayRef Vars,

ABataev wrote:
> The function has more than 10 parameters, it is not too good. Would be good 
> to pack some of them into some kind of structure.
I can define a structure `OMPMapClauseModifier` within `OMPMapClause` to 
include all modifier related info. What do you think?



Comment at: lib/Sema/SemaLookup.cpp:1074
 
+  if (NameKind == LookupOMPMapperName) {
+// Skip out-of-scope declarations.

ABataev wrote:
> Why do we need special processing of the mapper here?
The declare mapper lookup needs to find all `OMPDeclareMapperDecl`s with the 
same name (the same as declare reduction lookup), and thus it goes through all 
scopes from the innermost to the outtermost.

Then it looks up a parent scope S (e.g., the outter {} in the following 
example), all `OMPDeclareMapperDecl`s declared in the children scopes of S will 
appear in the range between `IdResolver.begin(Name)` and `IdResolver.end()`. 
Also, the `declare mapper(id: struct S s)` will appear before `omp declare 
mapper(id: struct SS ss)`. This can cause the lookup function to ignore later 
`omp declare mapper(id: struct SS ss)` declared in the outter scope. As a 
result, we may not find the corrent mapper.

```
{
  #pragma omp declare mapper(id: struct S s) (s.a)
  {
#pragma omp declare mapper(id: struct SS ss) (ss.b)
...
  }
}
```

To fix this problem, the purpose of this part of code is to ignore all 
`OMPDeclareMapperDecl`s in inner scopes, which are already found in previous 
calls to `LookupParsedName()` from `buildUserDefinedMapperRef`.

I also found that the declare reduction lookup has the same problem. I'll push 
out a similar fix for the declare reduction later.



Comment at: lib/Sema/SemaLookup.cpp:1793
   continue;
+else if (NameKind == LookupOMPMapperName) {
+  // Skip out-of-scope declarations.

ABataev wrote:
> Again, what's so special in mapper lookup?
The same as above. This is to fix C lookup, and the above is for C++



Comment at: lib/Serialization/ASTReader.cpp:12312
+  UDMappers.reserve(NumVars);
+  for (unsigned i = 0; i < NumVars; ++i)
+UDMappers.push_back(Record.readExpr());

ABataev wrote:
> `i`->`I`
I fixed it. Lower case `i` is also used in other loops in this function. Would 
you like me to fix them as well?


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

https://reviews.llvm.org/D58074



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


[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

2019-02-12 Thread Lingda Li via Phabricator via cfe-commits
lildmh updated this revision to Diff 186492.
lildmh marked 3 inline comments as done.
lildmh added a comment.

Fix part of Alexey's comments


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

https://reviews.llvm.org/D58074

Files:
  include/clang/AST/OpenMPClause.h
  include/clang/Basic/DiagnosticParseKinds.td
  include/clang/Basic/DiagnosticSemaKinds.td
  include/clang/Basic/OpenMPKinds.def
  include/clang/Parse/Parser.h
  include/clang/Sema/Sema.h
  lib/AST/OpenMPClause.cpp
  lib/Parse/ParseOpenMP.cpp
  lib/Sema/SemaLookup.cpp
  lib/Sema/SemaOpenMP.cpp
  lib/Sema/SemaTemplateInstantiateDecl.cpp
  lib/Sema/TreeTransform.h
  lib/Serialization/ASTReader.cpp
  lib/Serialization/ASTWriter.cpp
  test/OpenMP/declare_mapper_ast_print.c
  test/OpenMP/declare_mapper_ast_print.cpp
  test/OpenMP/declare_mapper_messages.c
  test/OpenMP/declare_mapper_messages.cpp
  test/OpenMP/target_map_messages.cpp
  test/OpenMP/target_parallel_for_map_messages.cpp
  test/OpenMP/target_parallel_for_simd_map_messages.cpp
  test/OpenMP/target_parallel_map_messages.cpp
  test/OpenMP/target_simd_map_messages.cpp
  test/OpenMP/target_teams_distribute_map_messages.cpp
  test/OpenMP/target_teams_distribute_parallel_for_map_messages.cpp
  test/OpenMP/target_teams_distribute_parallel_for_simd_map_messages.cpp
  test/OpenMP/target_teams_distribute_simd_map_messages.cpp
  test/OpenMP/target_teams_map_messages.cpp

Index: test/OpenMP/target_teams_map_messages.cpp
===
--- test/OpenMP/target_teams_map_messages.cpp
+++ test/OpenMP/target_teams_map_messages.cpp
@@ -454,7 +454,7 @@
 
 #pragma omp target data map(always, tofrom: x)
 #pragma omp target data map(always: x) // expected-error {{missing map type}}
-#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
 #pragma omp target data map(always, tofrom: always, tofrom, x)
 #pragma omp target teams map(tofrom j) // expected-error {{expected ',' or ')' in 'map' clause}}
   foo();
@@ -529,7 +529,7 @@
 
 #pragma omp target data map(always, tofrom: x)
 #pragma omp target data map(always: x) // expected-error {{missing map type}}
-#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target data map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
 #pragma omp target data map(always, tofrom: always, tofrom, x)
 #pragma omp target teams map(tofrom j) // expected-error {{expected ',' or ')' in 'map' clause}}
   foo();
Index: test/OpenMP/target_teams_distribute_simd_map_messages.cpp
===
--- test/OpenMP/target_teams_distribute_simd_map_messages.cpp
+++ test/OpenMP/target_teams_distribute_simd_map_messages.cpp
@@ -163,7 +163,7 @@
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always: x) // expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always, tofrom: always, tofrom, x)
   for (i = 0; i < argc; ++i) foo();
@@ -271,7 +271,7 @@
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always: x) // expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
-#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always' or 'close'}} expected-error {{missing map type}}
+#pragma omp target teams distribute simd map(tofrom, always: x) // expected-error {{incorrect map type modifier, expected 'always', 'close', or 'mapper'}} expected-error {{missing map type}}
   for (i = 0; i < argc; ++i) foo();
 #pragma omp target teams distribute simd map(always, tofrom: always, tofrom, x)
   for (i = 0; i < argc; ++i) foo();
Index: test/OpenMP/target_teams_distribute_parallel_for_simd_map_messages.cpp
===
--- test/OpenMP/target_teams_distribute_parallel_for_simd_map_messages.cpp
+++ test/OpenMP/target_teams_distribute_parallel_for_simd_map_messages.cpp
@@ -163,7 +163,7 @@
   for (i = 0; i < argc; ++i) foo();
 #pra

[PATCH] D58128: [PowerPC] Stop defining _ARCH_PWR6X on POWER7 and up

2019-02-12 Thread Hal Finkel via Phabricator via cfe-commits
hfinkel accepted this revision.
hfinkel added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rC Clang

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

https://reviews.llvm.org/D58128



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


[PATCH] D58135: [clangd] Handle a few more diag kinds in include fixer.

2019-02-12 Thread Eric Liu via Phabricator via cfe-commits
ioeric created this revision.
ioeric added a reviewer: sammccall.
Herald added subscribers: cfe-commits, kadircet, arphaman, jkorous, MaskRay, 
ilya-biryukov.
Herald added a project: clang.

Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D58135

Files:
  clangd/IncludeFixer.cpp
  unittests/clangd/DiagnosticsTests.cpp


Index: unittests/clangd/DiagnosticsTests.cpp
===
--- unittests/clangd/DiagnosticsTests.cpp
+++ unittests/clangd/DiagnosticsTests.cpp
@@ -368,11 +368,14 @@
   Annotations Test(R"cpp(
 $insert[[]]namespace ns {
 void foo() {
-  $unqualified[[X]] x;
+  $unqualified1[[X]] x;
+  $unqualified2[[X]]::Nested n;
 }
 }
 void bar() {
-  ns::$qualified[[X]] x; // ns:: is valid.
+  ns::$qualified1[[X]] x; // ns:: is valid.
+  ns::$qualified2[[X]](); // Error: no member in namespace
+
   ::$global[[Global]] glob;
 }
   )cpp");
@@ -385,13 +388,21 @@
   EXPECT_THAT(
   TU.build().getDiagnostics(),
   UnorderedElementsAre(
-  AllOf(Diag(Test.range("unqualified"), "unknown type name 'X'"),
+  AllOf(Diag(Test.range("unqualified1"), "unknown type name 'X'"),
+WithFix(Fix(Test.range("insert"), "#include \"x.h\"\n",
+"Add include \"x.h\" for symbol ns::X"))),
+  AllOf(Diag(Test.range("unqualified2"),
+ "use of undeclared identifier 'X'"),
 WithFix(Fix(Test.range("insert"), "#include \"x.h\"\n",
 "Add include \"x.h\" for symbol ns::X"))),
-  AllOf(Diag(Test.range("qualified"),
+  AllOf(Diag(Test.range("qualified1"),
  "no type named 'X' in namespace 'ns'"),
 WithFix(Fix(Test.range("insert"), "#include \"x.h\"\n",
 "Add include \"x.h\" for symbol ns::X"))),
+  AllOf(Diag(Test.range("qualified2"),
+ "no member named 'X' in namespace 'ns'"),
+WithFix(Fix(Test.range("insert"), "#include \"x.h\"\n",
+"Add include \"x.h\" for symbol ns::X"))),
   AllOf(Diag(Test.range("global"),
  "no type named 'Global' in the global namespace"),
 WithFix(Fix(Test.range("insert"), "#include \"global.h\"\n",
Index: clangd/IncludeFixer.cpp
===
--- clangd/IncludeFixer.cpp
+++ clangd/IncludeFixer.cpp
@@ -79,6 +79,12 @@
   case diag::err_typename_nested_not_found:
   case diag::err_no_template:
   case diag::err_no_template_suggest:
+  case diag::err_undeclared_use:
+  case diag::err_undeclared_use_suggest:
+  case diag::err_undeclared_var_use:
+  case diag::err_undeclared_var_use_suggest:
+  case diag::err_no_member: // Could be no member in namespace.
+  case diag::err_no_member_suggest:
 if (LastUnresolvedName) {
   // Try to fix unresolved name caused by missing declaraion.
   // E.g.


Index: unittests/clangd/DiagnosticsTests.cpp
===
--- unittests/clangd/DiagnosticsTests.cpp
+++ unittests/clangd/DiagnosticsTests.cpp
@@ -368,11 +368,14 @@
   Annotations Test(R"cpp(
 $insert[[]]namespace ns {
 void foo() {
-  $unqualified[[X]] x;
+  $unqualified1[[X]] x;
+  $unqualified2[[X]]::Nested n;
 }
 }
 void bar() {
-  ns::$qualified[[X]] x; // ns:: is valid.
+  ns::$qualified1[[X]] x; // ns:: is valid.
+  ns::$qualified2[[X]](); // Error: no member in namespace
+
   ::$global[[Global]] glob;
 }
   )cpp");
@@ -385,13 +388,21 @@
   EXPECT_THAT(
   TU.build().getDiagnostics(),
   UnorderedElementsAre(
-  AllOf(Diag(Test.range("unqualified"), "unknown type name 'X'"),
+  AllOf(Diag(Test.range("unqualified1"), "unknown type name 'X'"),
+WithFix(Fix(Test.range("insert"), "#include \"x.h\"\n",
+"Add include \"x.h\" for symbol ns::X"))),
+  AllOf(Diag(Test.range("unqualified2"),
+ "use of undeclared identifier 'X'"),
 WithFix(Fix(Test.range("insert"), "#include \"x.h\"\n",
 "Add include \"x.h\" for symbol ns::X"))),
-  AllOf(Diag(Test.range("qualified"),
+  AllOf(Diag(Test.range("qualified1"),
  "no type named 'X' in namespace 'ns'"),
 WithFix(Fix(Test.range("insert"), "#include \"x.h\"\n",
 "Add include \"x.h\" for symbol ns::X"))),
+  AllOf(Diag(Test.range("qualified2"),
+ "no member named 'X' in namespace 'ns'"),
+WithFix(Fix(Test.range("insert"), "#include \"x.h\"\n",
+"Add include \"x.h\" for symbol ns::X"))),
   AllOf(Diag(Test.range("global"),
  "no type named 'Global' in the global namespace"),
 WithFix(Fix(Test.range("insert"), "#include \"global.h\"\n",
Index: clangd/In

[PATCH] D57898: CodeGen: Fix PR40605: split constant structures generated by -ftrivial-auto-var-init when emitting initializators

2019-02-12 Thread JF Bastien via Phabricator via cfe-commits
jfb added a comment.

Overall this LGTM besides a few nits, and wanting input from @rjmccall.

As follow-ups (which I can take on):

- Handle the case where the types don't match (because `Loc` was adjusted).
- Handle small arrays (and any other cases where the struct stores get broken 
down into components which still contain a `memcpy`/ `memset`).




Comment at: tools/clang/lib/CodeGen/CGDecl.cpp:975
+static bool shouldSplitStructStore(CodeGenModule &CGM, llvm::Constant *Init,
+   uint64_t GlobalSize) {
+  // Don't break structures that occupy more than one cacheline.

You don't use `Init` in the function.



Comment at: tools/clang/lib/CodeGen/CGDecl.cpp:979
+  if (CGM.getCodeGenOpts().OptimizationLevel == 0)
+return false;
+  if (GlobalSize <= SizeLimit)

The general 64-byte heuristic is fine with me. It's just a bit weird to 
special-case `-O0`, but we do it elsewhere too (and it keeps the current 
status-quo of letting the backend decide what to do). From that perspective I'm 
fine with it.

@rjmccall do you have a strong preference either way?

One small nit: can you use `ByteSize` instead of just `Size`? Makes it easier 
to figure out what's going on in code IMO.



Comment at: tools/clang/test/CodeGenCXX/auto-var-init.cpp:476
 // CHECK-NEXT:  call void @{{.*}}used{{.*}}%uninit)
 // PATTERN-LABEL: @test_empty_uninit()
+// PATTERN-O0: call void @llvm.memcpy{{.*}} @__const.test_empty_uninit.uninit

The tests aren't matching labels anymore: `PATTERN-LABEL` is a dead label check 
now. I think forking things at `-O0` and `-O1` is fine, but I think you want a 
small `-O0` test (separate from this patch) which does one or two things, and 
then you want this test to only look at `-O1`. That way you don't need so much 
stuff changing in the test (and `-O0` is still tested).


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

https://reviews.llvm.org/D57898



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


[PATCH] D58135: [clangd] Handle a few more diag kinds in include fixer.

2019-02-12 Thread Sam McCall via Phabricator via cfe-commits
sammccall accepted this revision.
sammccall added a comment.
This revision is now accepted and ready to land.

Nice!


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D58135



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


[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

2019-02-12 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D58074#1394993 , @lildmh wrote:

> Hi Alexey,
>
> Thanks very much for your quick review!
>
> For the codegen, currently I'm thinking to do it within declare target 
> codegen functions. So there is not a very clear interface to do mapper 
> codegen (also, there is not a clear interface to do map clause codegen now), 
> and that's why I didn't have a stub left in this patch. Please see other 
> detailed responses inline.


This till must be handled somehow in codegen, better to ignore for now, I think.




Comment at: include/clang/AST/OpenMPClause.h:4236
+  static OMPMapClause *
+  Create(const ASTContext &C, SourceLocation StartLoc, SourceLocation 
LParenLoc,
+ SourceLocation EndLoc, ArrayRef Vars,

lildmh wrote:
> ABataev wrote:
> > The function has more than 10 parameters, it is not too good. Would be good 
> > to pack some of them into some kind of structure.
> I can define a structure `OMPMapClauseModifier` within `OMPMapClause` to 
> include all modifier related info. What do you think?
Yes, it would be good



Comment at: lib/Sema/SemaLookup.cpp:1074
 
+  if (NameKind == LookupOMPMapperName) {
+// Skip out-of-scope declarations.

lildmh wrote:
> ABataev wrote:
> > Why do we need special processing of the mapper here?
> The declare mapper lookup needs to find all `OMPDeclareMapperDecl`s with the 
> same name (the same as declare reduction lookup), and thus it goes through 
> all scopes from the innermost to the outtermost.
> 
> Then it looks up a parent scope S (e.g., the outter {} in the following 
> example), all `OMPDeclareMapperDecl`s declared in the children scopes of S 
> will appear in the range between `IdResolver.begin(Name)` and 
> `IdResolver.end()`. Also, the `declare mapper(id: struct S s)` will appear 
> before `omp declare mapper(id: struct SS ss)`. This can cause the lookup 
> function to ignore later `omp declare mapper(id: struct SS ss)` declared in 
> the outter scope. As a result, we may not find the corrent mapper.
> 
> ```
> {
>   #pragma omp declare mapper(id: struct S s) (s.a)
>   {
> #pragma omp declare mapper(id: struct SS ss) (ss.b)
> ...
>   }
> }
> ```
> 
> To fix this problem, the purpose of this part of code is to ignore all 
> `OMPDeclareMapperDecl`s in inner scopes, which are already found in previous 
> calls to `LookupParsedName()` from `buildUserDefinedMapperRef`.
> 
> I also found that the declare reduction lookup has the same problem. I'll 
> push out a similar fix for the declare reduction later.
I don't think this is the correct behavior. For user-defined reductions, the 
standard says "This match is done by means of a name lookup in the base 
language." It means we should use the lookup rules of C/C++. For mapper, seems 
to me, we also should completely rely on the visibility/accessibility rules 
used by C/C++.



Comment at: lib/Serialization/ASTReader.cpp:12312
+  UDMappers.reserve(NumVars);
+  for (unsigned i = 0; i < NumVars; ++i)
+UDMappers.push_back(Record.readExpr());

lildmh wrote:
> ABataev wrote:
> > `i`->`I`
> I fixed it. Lower case `i` is also used in other loops in this function. 
> Would you like me to fix them as well?
This is the old code that was committed before the rules were defined. Soon 
they're going again to update the coding standard to allow lowCamel for the 
variables, but currently, only CamelCase is used for variables.
No, don't do this.


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

https://reviews.llvm.org/D58074



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


[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

2019-02-12 Thread Lingda Li via Phabricator via cfe-commits
lildmh marked 2 inline comments as done.
lildmh added inline comments.



Comment at: include/clang/AST/OpenMPClause.h:4236
+  static OMPMapClause *
+  Create(const ASTContext &C, SourceLocation StartLoc, SourceLocation 
LParenLoc,
+ SourceLocation EndLoc, ArrayRef Vars,

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > The function has more than 10 parameters, it is not too good. Would be 
> > > good to pack some of them into some kind of structure.
> > I can define a structure `OMPMapClauseModifier` within `OMPMapClause` to 
> > include all modifier related info. What do you think?
> Yes, it would be good
Then I'll do that. Thanks



Comment at: lib/Sema/SemaLookup.cpp:1074
 
+  if (NameKind == LookupOMPMapperName) {
+// Skip out-of-scope declarations.

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > Why do we need special processing of the mapper here?
> > The declare mapper lookup needs to find all `OMPDeclareMapperDecl`s with 
> > the same name (the same as declare reduction lookup), and thus it goes 
> > through all scopes from the innermost to the outtermost.
> > 
> > Then it looks up a parent scope S (e.g., the outter {} in the following 
> > example), all `OMPDeclareMapperDecl`s declared in the children scopes of S 
> > will appear in the range between `IdResolver.begin(Name)` and 
> > `IdResolver.end()`. Also, the `declare mapper(id: struct S s)` will appear 
> > before `omp declare mapper(id: struct SS ss)`. This can cause the lookup 
> > function to ignore later `omp declare mapper(id: struct SS ss)` declared in 
> > the outter scope. As a result, we may not find the corrent mapper.
> > 
> > ```
> > {
> >   #pragma omp declare mapper(id: struct S s) (s.a)
> >   {
> > #pragma omp declare mapper(id: struct SS ss) (ss.b)
> > ...
> >   }
> > }
> > ```
> > 
> > To fix this problem, the purpose of this part of code is to ignore all 
> > `OMPDeclareMapperDecl`s in inner scopes, which are already found in 
> > previous calls to `LookupParsedName()` from `buildUserDefinedMapperRef`.
> > 
> > I also found that the declare reduction lookup has the same problem. I'll 
> > push out a similar fix for the declare reduction later.
> I don't think this is the correct behavior. For user-defined reductions, the 
> standard says "This match is done by means of a name lookup in the base 
> language." It means we should use the lookup rules of C/C++. For mapper, 
> seems to me, we also should completely rely on the visibility/accessibility 
> rules used by C/C++.
Again, thanks for your quick response!

```
{
  #pragma omp declare mapper(id: struct S s) (s.a)
  {
#pragma omp declare mapper(id: struct SS ss) (ss.b)
struct S kk;
#pragma omp target map(mapper(id), tofrom: kk)
{}
  }
}
```

If I don't add this code, the above code will report error that it cannnot find 
a mapper with name `id` for type `struct S`, because it can only find the 
second mapper for type `struct SS`. This doesn't look like correct behavior to 
me.

I think we are still following the lookup rules of C/C++ with this fix. It's 
because for declare mapper and reduction, we call `LookupParsedName` multiple 
times on different scopes. In other cases, `LookupParsedName` is always called 
once. Because of this difference, I think this fix is appropriate. What is your 
thought?


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

https://reviews.llvm.org/D58074



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


[PATCH] D56305: [AArch64] Support reserving arbitrary general purpose registers

2019-02-12 Thread Tri Vo via Phabricator via cfe-commits
trong added inline comments.
Herald added a project: LLVM.



Comment at: clang/lib/Driver/ToolChains/Arch/AArch64.cpp:318
 
+  if (Args.hasArg(options::OPT_ffixed_x0))
+Features.push_back("+reserve-x0");

phosek wrote:
> trong wrote:
> > What happens (should happen) if we reserve x0 and compile a function with a 
> > return value?
> Clang throws `error: AArch64 doesn't support function calls if any of the 
> argument registers is reserved.` as for any other argument register.
Yes, if x0 is reserved, it can't be used to pass arguments. But what happens if 
x0 is used to return a value? For example:
```
int foo() {
return 1;
}
```
It would be helpful if compiling `foo()` with x0 reserved threw an error.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D56305



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


[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

2019-02-12 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added inline comments.



Comment at: lib/Sema/SemaLookup.cpp:1074
 
+  if (NameKind == LookupOMPMapperName) {
+// Skip out-of-scope declarations.

lildmh wrote:
> ABataev wrote:
> > lildmh wrote:
> > > ABataev wrote:
> > > > Why do we need special processing of the mapper here?
> > > The declare mapper lookup needs to find all `OMPDeclareMapperDecl`s with 
> > > the same name (the same as declare reduction lookup), and thus it goes 
> > > through all scopes from the innermost to the outtermost.
> > > 
> > > Then it looks up a parent scope S (e.g., the outter {} in the following 
> > > example), all `OMPDeclareMapperDecl`s declared in the children scopes of 
> > > S will appear in the range between `IdResolver.begin(Name)` and 
> > > `IdResolver.end()`. Also, the `declare mapper(id: struct S s)` will 
> > > appear before `omp declare mapper(id: struct SS ss)`. This can cause the 
> > > lookup function to ignore later `omp declare mapper(id: struct SS ss)` 
> > > declared in the outter scope. As a result, we may not find the corrent 
> > > mapper.
> > > 
> > > ```
> > > {
> > >   #pragma omp declare mapper(id: struct S s) (s.a)
> > >   {
> > > #pragma omp declare mapper(id: struct SS ss) (ss.b)
> > > ...
> > >   }
> > > }
> > > ```
> > > 
> > > To fix this problem, the purpose of this part of code is to ignore all 
> > > `OMPDeclareMapperDecl`s in inner scopes, which are already found in 
> > > previous calls to `LookupParsedName()` from `buildUserDefinedMapperRef`.
> > > 
> > > I also found that the declare reduction lookup has the same problem. I'll 
> > > push out a similar fix for the declare reduction later.
> > I don't think this is the correct behavior. For user-defined reductions, 
> > the standard says "This match is done by means of a name lookup in the base 
> > language." It means we should use the lookup rules of C/C++. For mapper, 
> > seems to me, we also should completely rely on the visibility/accessibility 
> > rules used by C/C++.
> Again, thanks for your quick response!
> 
> ```
> {
>   #pragma omp declare mapper(id: struct S s) (s.a)
>   {
> #pragma omp declare mapper(id: struct SS ss) (ss.b)
> struct S kk;
> #pragma omp target map(mapper(id), tofrom: kk)
> {}
>   }
> }
> ```
> 
> If I don't add this code, the above code will report error that it cannnot 
> find a mapper with name `id` for type `struct S`, because it can only find 
> the second mapper for type `struct SS`. This doesn't look like correct 
> behavior to me.
> 
> I think we are still following the lookup rules of C/C++ with this fix. It's 
> because for declare mapper and reduction, we call `LookupParsedName` multiple 
> times on different scopes. In other cases, `LookupParsedName` is always 
> called once. Because of this difference, I think this fix is appropriate. 
> What is your thought?
No, in your case we don't. According to the C/C++ rules, if the variable is 
redeclared, the latest declaration is used. The same rule must be applied to 
the mapper (according to the standard "The visibility and accessibility of this 
declaration are the same as those of a variable declared at the same point in 
the program.")
I think that the code should fail in this case, because you would the error 
message in case of the variables declarations with the same names in those 
scopes.


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

https://reviews.llvm.org/D58074



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


[PATCH] D57232: [ASTImporter] Check visibility/linkage of functions and variables

2019-02-12 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik accepted this revision.
shafik added a comment.
This revision is now accepted and ready to land.
Herald added a subscriber: jdoerfert.

I ran `check-lldb` locally and it looks good.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57232



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


[PATCH] D57736: [WebAssembly] Bulk memory intrinsics and builtins

2019-02-12 Thread Thomas Lively via Phabricator via cfe-commits
tlively updated this revision to Diff 186504.
tlively added a comment.

- Update tests to check full polymorphism of llvm.memcpy and llvm.memmove


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D57736

Files:
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-wasm.c
  llvm/include/llvm/IR/IntrinsicsWebAssembly.td
  llvm/lib/Target/WebAssembly/WebAssemblyInstrBulkMemory.td
  llvm/lib/Target/WebAssembly/WebAssemblySelectionDAGInfo.cpp
  llvm/test/CodeGen/WebAssembly/bulk-memory-intrinsics.ll
  llvm/test/CodeGen/WebAssembly/bulk-memory.ll

Index: llvm/test/CodeGen/WebAssembly/bulk-memory.ll
===
--- llvm/test/CodeGen/WebAssembly/bulk-memory.ll
+++ llvm/test/CodeGen/WebAssembly/bulk-memory.ll
@@ -6,40 +6,39 @@
 target datalayout = "e-m:e-p:32:32-i64:64-n32:64-S128"
 target triple = "wasm32-unknown-unknown"
 
+declare void @llvm.memcpy.p0i8.p0i8.i8(i8*, i8*, i8, i1)
+declare void @llvm.memcpy.p0i8.p0i8.i32(i8*, i8*, i32, i1)
+declare void @llvm.memcpy.p0i32.p0i32.i32(i32*, i32*, i32, i1)
+
+declare void @llvm.memmove.p0i8.p0i8.i8(i8*, i8*, i8, i1)
+declare void @llvm.memmove.p0i8.p0i8.i32(i8*, i8*, i32, i1)
+declare void @llvm.memmove.p0i32.p0i32.i32(i32*, i32*, i32, i1)
+
 ; CHECK-LABEL: memcpy_i8:
 ; NO-BULK-MEM-NOT: memory.copy
 ; BULK-MEM-NEXT: .functype memcpy_i8 (i32, i32, i32) -> ()
-; BULK-MEM-NEXT: memory.copy $0, $1, $2
+; BULK-MEM-NEXT: memory.copy 0, 0, $0, $1, $2
 ; BULK-MEM-NEXT: return
-declare void @llvm.memcpy.p0i8.p0i8.i32(
-  i8* %dest, i8* %src, i32 %len, i1 %volatile
-)
-define void @memcpy_i8(i8* %dest, i8* %src, i32 %len) {
-  call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 %len, i1 0)
+define void @memcpy_i8(i8* %dest, i8* %src, i8 zeroext %len) {
+  call void @llvm.memcpy.p0i8.p0i8.i8(i8* %dest, i8* %src, i8 %len, i1 0)
   ret void
 }
 
 ; CHECK-LABEL: memmove_i8:
 ; NO-BULK-MEM-NOT: memory.copy
 ; BULK-MEM-NEXT: .functype memmove_i8 (i32, i32, i32) -> ()
-; BULK-MEM-NEXT: memory.copy $0, $1, $2
+; BULK-MEM-NEXT: memory.copy 0, 0, $0, $1, $2
 ; BULK-MEM-NEXT: return
-declare void @llvm.memmove.p0i8.p0i8.i32(
-  i8* %dest, i8* %src, i32 %len, i1 %volatile
-)
-define void @memmove_i8(i8* %dest, i8* %src, i32 %len) {
-  call void @llvm.memmove.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 %len, i1 0)
+define void @memmove_i8(i8* %dest, i8* %src, i8 zeroext %len) {
+  call void @llvm.memmove.p0i8.p0i8.i8(i8* %dest, i8* %src, i8 %len, i1 0)
   ret void
 }
 
 ; CHECK-LABEL: memcpy_i32:
 ; NO-BULK-MEM-NOT: memory.copy
 ; BULK-MEM-NEXT: .functype memcpy_i32 (i32, i32, i32) -> ()
-; BULK-MEM-NEXT: memory.copy $0, $1, $2
+; BULK-MEM-NEXT: memory.copy 0, 0, $0, $1, $2
 ; BULK-MEM-NEXT: return
-declare void @llvm.memcpy.p0i32.p0i32.i32(
-  i32* %dest, i32* %src, i32 %len, i1 %volatile
-)
 define void @memcpy_i32(i32* %dest, i32* %src, i32 %len) {
   call void @llvm.memcpy.p0i32.p0i32.i32(i32* %dest, i32* %src, i32 %len, i1 0)
   ret void
@@ -48,11 +47,8 @@
 ; CHECK-LABEL: memmove_i32:
 ; NO-BULK-MEM-NOT: memory.copy
 ; BULK-MEM-NEXT: .functype memmove_i32 (i32, i32, i32) -> ()
-; BULK-MEM-NEXT: memory.copy $0, $1, $2
+; BULK-MEM-NEXT: memory.copy 0, 0, $0, $1, $2
 ; BULK-MEM-NEXT: return
-declare void @llvm.memmove.p0i32.p0i32.i32(
-  i32* %dest, i32* %src, i32 %len, i1 %volatile
-)
 define void @memmove_i32(i32* %dest, i32* %src, i32 %len) {
   call void @llvm.memmove.p0i32.p0i32.i32(i32* %dest, i32* %src, i32 %len, i1 0)
   ret void
@@ -82,7 +78,7 @@
 ; NO-BULK-MEM-NOT: memory.copy
 ; BULK-MEM-NEXT: .functype memcpy_1024 (i32, i32) -> ()
 ; BULK-MEM-NEXT: i32.const $push[[L0:[0-9]+]]=, 1024
-; BULK-MEM-NEXT: memory.copy $0, $1, $pop[[L0]]
+; BULK-MEM-NEXT: memory.copy 0, 0, $0, $1, $pop[[L0]]
 ; BULK-MEM-NEXT: return
 define void @memcpy_1024(i8* %dest, i8* %src) {
   call void @llvm.memcpy.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 1024, i1 0)
@@ -93,7 +89,7 @@
 ; NO-BULK-MEM-NOT: memory.copy
 ; BULK-MEM-NEXT: .functype memmove_1024 (i32, i32) -> ()
 ; BULK-MEM-NEXT: i32.const $push[[L0:[0-9]+]]=, 1024
-; BULK-MEM-NEXT: memory.copy $0, $1, $pop[[L0]]
+; BULK-MEM-NEXT: memory.copy 0, 0, $0, $1, $pop[[L0]]
 ; BULK-MEM-NEXT: return
 define void @memmove_1024(i8* %dest, i8* %src) {
   call void @llvm.memmove.p0i8.p0i8.i32(i8* %dest, i8* %src, i32 1024, i1 0)
Index: llvm/test/CodeGen/WebAssembly/bulk-memory-intrinsics.ll
===
--- /dev/null
+++ llvm/test/CodeGen/WebAssembly/bulk-memory-intrinsics.ll
@@ -0,0 +1,28 @@
+; RUN: llc < %s -asm-verbose=false -verify-machineinstrs -disable-wasm-fallthrough-return-opt -wasm-disable-explicit-locals -wasm-keep-registers -mattr=+bulk-memory | FileCheck %s
+
+; Test that bulk memory intrinsics lower correctly
+
+target datalayout = "e-m:e-p:32:32-i64:64-n32:64-S128"
+target triple = "wasm32-

[PATCH] D56305: [AArch64] Support reserving arbitrary general purpose registers

2019-02-12 Thread Tri Vo via Phabricator via cfe-commits
trong accepted this revision.
trong added inline comments.
This revision is now accepted and ready to land.



Comment at: clang/lib/Driver/ToolChains/Arch/AArch64.cpp:318
 
+  if (Args.hasArg(options::OPT_ffixed_x0))
+Features.push_back("+reserve-x0");

trong wrote:
> phosek wrote:
> > trong wrote:
> > > What happens (should happen) if we reserve x0 and compile a function with 
> > > a return value?
> > Clang throws `error: AArch64 doesn't support function calls if any of the 
> > argument registers is reserved.` as for any other argument register.
> Yes, if x0 is reserved, it can't be used to pass arguments. But what happens 
> if x0 is used to return a value? For example:
> ```
> int foo() {
> return 1;
> }
> ```
> It would be helpful if compiling `foo()` with x0 reserved threw an error.
OTOH, [[ https://godbolt.org/z/jWW09Y | gcc ]] doesn't complain, so maybe we're 
OK here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D56305



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


[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

2019-02-12 Thread Lingda Li via Phabricator via cfe-commits
lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/Sema/SemaLookup.cpp:1074
 
+  if (NameKind == LookupOMPMapperName) {
+// Skip out-of-scope declarations.

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > Why do we need special processing of the mapper here?
> > > > The declare mapper lookup needs to find all `OMPDeclareMapperDecl`s 
> > > > with the same name (the same as declare reduction lookup), and thus it 
> > > > goes through all scopes from the innermost to the outtermost.
> > > > 
> > > > Then it looks up a parent scope S (e.g., the outter {} in the following 
> > > > example), all `OMPDeclareMapperDecl`s declared in the children scopes 
> > > > of S will appear in the range between `IdResolver.begin(Name)` and 
> > > > `IdResolver.end()`. Also, the `declare mapper(id: struct S s)` will 
> > > > appear before `omp declare mapper(id: struct SS ss)`. This can cause 
> > > > the lookup function to ignore later `omp declare mapper(id: struct SS 
> > > > ss)` declared in the outter scope. As a result, we may not find the 
> > > > corrent mapper.
> > > > 
> > > > ```
> > > > {
> > > >   #pragma omp declare mapper(id: struct S s) (s.a)
> > > >   {
> > > > #pragma omp declare mapper(id: struct SS ss) (ss.b)
> > > > ...
> > > >   }
> > > > }
> > > > ```
> > > > 
> > > > To fix this problem, the purpose of this part of code is to ignore all 
> > > > `OMPDeclareMapperDecl`s in inner scopes, which are already found in 
> > > > previous calls to `LookupParsedName()` from `buildUserDefinedMapperRef`.
> > > > 
> > > > I also found that the declare reduction lookup has the same problem. 
> > > > I'll push out a similar fix for the declare reduction later.
> > > I don't think this is the correct behavior. For user-defined reductions, 
> > > the standard says "This match is done by means of a name lookup in the 
> > > base language." It means we should use the lookup rules of C/C++. For 
> > > mapper, seems to me, we also should completely rely on the 
> > > visibility/accessibility rules used by C/C++.
> > Again, thanks for your quick response!
> > 
> > ```
> > {
> >   #pragma omp declare mapper(id: struct S s) (s.a)
> >   {
> > #pragma omp declare mapper(id: struct SS ss) (ss.b)
> > struct S kk;
> > #pragma omp target map(mapper(id), tofrom: kk)
> > {}
> >   }
> > }
> > ```
> > 
> > If I don't add this code, the above code will report error that it cannnot 
> > find a mapper with name `id` for type `struct S`, because it can only find 
> > the second mapper for type `struct SS`. This doesn't look like correct 
> > behavior to me.
> > 
> > I think we are still following the lookup rules of C/C++ with this fix. 
> > It's because for declare mapper and reduction, we call `LookupParsedName` 
> > multiple times on different scopes. In other cases, `LookupParsedName` is 
> > always called once. Because of this difference, I think this fix is 
> > appropriate. What is your thought?
> No, in your case we don't. According to the C/C++ rules, if the variable is 
> redeclared, the latest declaration is used. The same rule must be applied to 
> the mapper (according to the standard "The visibility and accessibility of 
> this declaration are the same as those of a variable declared at the same 
> point in the program.")
> I think that the code should fail in this case, because you would the error 
> message in case of the variables declarations with the same names in those 
> scopes.
Hi Alexey,

Thanks for your quick response! I don't think it's redeclared in this case, 
because a mapper has two properties: name and type, just as declare reduction. 
Only when both name and type are the same, it should be considered as 
redeclaration.

If we consider the above example as redeclaration of a mapper, then we can 
always just call `LookupParsedName` once to find the most relevant 
mapper/reductor. Then why do you need to search reductors in a while loop in 
`buildDeclareReductionRef`?

Also, the following example will be correct using the original lookup 
functions, without my fix:

```
{
  #pragma omp declare mapper(id: struct S s) (s.a)
#pragma omp declare mapper(id: struct SS ss) (ss.b)
struct S kk;
#pragma omp target map(mapper(id), tofrom: kk)
{}
}
```

If we consider the second mapper as a redeclaration of the first one, this 
should fail as well. What do you think?


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

https://reviews.llvm.org/D58074



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


[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

2019-02-12 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added inline comments.



Comment at: lib/Sema/SemaLookup.cpp:1074
 
+  if (NameKind == LookupOMPMapperName) {
+// Skip out-of-scope declarations.

lildmh wrote:
> ABataev wrote:
> > lildmh wrote:
> > > ABataev wrote:
> > > > lildmh wrote:
> > > > > ABataev wrote:
> > > > > > Why do we need special processing of the mapper here?
> > > > > The declare mapper lookup needs to find all `OMPDeclareMapperDecl`s 
> > > > > with the same name (the same as declare reduction lookup), and thus 
> > > > > it goes through all scopes from the innermost to the outtermost.
> > > > > 
> > > > > Then it looks up a parent scope S (e.g., the outter {} in the 
> > > > > following example), all `OMPDeclareMapperDecl`s declared in the 
> > > > > children scopes of S will appear in the range between 
> > > > > `IdResolver.begin(Name)` and `IdResolver.end()`. Also, the `declare 
> > > > > mapper(id: struct S s)` will appear before `omp declare mapper(id: 
> > > > > struct SS ss)`. This can cause the lookup function to ignore later 
> > > > > `omp declare mapper(id: struct SS ss)` declared in the outter scope. 
> > > > > As a result, we may not find the corrent mapper.
> > > > > 
> > > > > ```
> > > > > {
> > > > >   #pragma omp declare mapper(id: struct S s) (s.a)
> > > > >   {
> > > > > #pragma omp declare mapper(id: struct SS ss) (ss.b)
> > > > > ...
> > > > >   }
> > > > > }
> > > > > ```
> > > > > 
> > > > > To fix this problem, the purpose of this part of code is to ignore 
> > > > > all `OMPDeclareMapperDecl`s in inner scopes, which are already found 
> > > > > in previous calls to `LookupParsedName()` from 
> > > > > `buildUserDefinedMapperRef`.
> > > > > 
> > > > > I also found that the declare reduction lookup has the same problem. 
> > > > > I'll push out a similar fix for the declare reduction later.
> > > > I don't think this is the correct behavior. For user-defined 
> > > > reductions, the standard says "This match is done by means of a name 
> > > > lookup in the base language." It means we should use the lookup rules 
> > > > of C/C++. For mapper, seems to me, we also should completely rely on 
> > > > the visibility/accessibility rules used by C/C++.
> > > Again, thanks for your quick response!
> > > 
> > > ```
> > > {
> > >   #pragma omp declare mapper(id: struct S s) (s.a)
> > >   {
> > > #pragma omp declare mapper(id: struct SS ss) (ss.b)
> > > struct S kk;
> > > #pragma omp target map(mapper(id), tofrom: kk)
> > > {}
> > >   }
> > > }
> > > ```
> > > 
> > > If I don't add this code, the above code will report error that it 
> > > cannnot find a mapper with name `id` for type `struct S`, because it can 
> > > only find the second mapper for type `struct SS`. This doesn't look like 
> > > correct behavior to me.
> > > 
> > > I think we are still following the lookup rules of C/C++ with this fix. 
> > > It's because for declare mapper and reduction, we call `LookupParsedName` 
> > > multiple times on different scopes. In other cases, `LookupParsedName` is 
> > > always called once. Because of this difference, I think this fix is 
> > > appropriate. What is your thought?
> > No, in your case we don't. According to the C/C++ rules, if the variable is 
> > redeclared, the latest declaration is used. The same rule must be applied 
> > to the mapper (according to the standard "The visibility and accessibility 
> > of this declaration are the same as those of a variable declared at the 
> > same point in the program.")
> > I think that the code should fail in this case, because you would the error 
> > message in case of the variables declarations with the same names in those 
> > scopes.
> Hi Alexey,
> 
> Thanks for your quick response! I don't think it's redeclared in this case, 
> because a mapper has two properties: name and type, just as declare 
> reduction. Only when both name and type are the same, it should be considered 
> as redeclaration.
> 
> If we consider the above example as redeclaration of a mapper, then we can 
> always just call `LookupParsedName` once to find the most relevant 
> mapper/reductor. Then why do you need to search reductors in a while loop in 
> `buildDeclareReductionRef`?
> 
> Also, the following example will be correct using the original lookup 
> functions, without my fix:
> 
> ```
> {
>   #pragma omp declare mapper(id: struct S s) (s.a)
> #pragma omp declare mapper(id: struct SS ss) (ss.b)
> struct S kk;
> #pragma omp target map(mapper(id), tofrom: kk)
> {}
> }
> ```
> 
> If we consider the second mapper as a redeclaration of the first one, this 
> should fail as well. What do you think?
The standard clearly states that "The visibility and accessibility of this 
declaration are the same as those of a variable declared at the same point in 
the program.". For variables (btw, they also have 2 attributes - name and type) 
the inner declaration makes the outer one not visible. The same rule should be 
a

[PATCH] D58137: [clang-tidy] Add the abseil-time-subtraction check

2019-02-12 Thread Hyrum Wright via Phabricator via cfe-commits
hwright created this revision.
hwright added reviewers: ioeric, hokein, JonasToth, aaron.ballman.
hwright added a project: clang-tools-extra.
Herald added subscribers: cfe-commits, jdoerfert, xazax.hun, mgorny.
Herald added a project: clang.

Repository:
  rCTE Clang Tools Extra

https://reviews.llvm.org/D58137

Files:
  clang-tidy/abseil/AbseilTidyModule.cpp
  clang-tidy/abseil/CMakeLists.txt
  clang-tidy/abseil/DurationRewriter.cpp
  clang-tidy/abseil/DurationRewriter.h
  clang-tidy/abseil/TimeSubtractionCheck.cpp
  clang-tidy/abseil/TimeSubtractionCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/abseil-time-subtraction.rst
  docs/clang-tidy/checks/list.rst
  test/clang-tidy/abseil-time-subtraction.cpp

Index: test/clang-tidy/abseil-time-subtraction.cpp
===
--- /dev/null
+++ test/clang-tidy/abseil-time-subtraction.cpp
@@ -0,0 +1,78 @@
+// RUN: %check_clang_tidy %s abseil-time-subtraction %t -- -- -I%S/Inputs
+
+#include "absl/time/time.h"
+
+void g(absl::Duration d);
+
+void f() {
+  absl::Time t;
+  int x, y;
+  absl::Duration d;
+
+  d = absl::Hours(absl::ToUnixHours(t) - x);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform subtraction in the time domain [abseil-time-subtraction]
+  // CHECK-FIXES: d = (t - absl::FromUnixHours(x));
+  d = absl::Minutes(absl::ToUnixMinutes(t) - x);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform subtraction in the time domain [abseil-time-subtraction]
+  // CHECK-FIXES: d = (t - absl::FromUnixMinutes(x));
+  d = absl::Seconds(absl::ToUnixSeconds(t) - x);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform subtraction in the time domain [abseil-time-subtraction]
+  // CHECK-FIXES: d = (t - absl::FromUnixSeconds(x));
+  d = absl::Milliseconds(absl::ToUnixMillis(t) - x);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform subtraction in the time domain [abseil-time-subtraction]
+  // CHECK-FIXES: d = (t - absl::FromUnixMillis(x));
+  d = absl::Microseconds(absl::ToUnixMicros(t) - x);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform subtraction in the time domain [abseil-time-subtraction]
+  // CHECK-FIXES: d = (t - absl::FromUnixMicros(x));
+  d = absl::Nanoseconds(absl::ToUnixNanos(t) - x);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform subtraction in the time domain [abseil-time-subtraction]
+  // CHECK-FIXES: d = (t - absl::FromUnixNanos(x));
+
+  y = x - absl::ToUnixHours(t);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform subtraction in the time domain [abseil-time-subtraction]
+  // CHECK-FIXES: y = absl::ToInt64Hours(absl::FromUnixHours(x) - t);
+  y = x - absl::ToUnixMinutes(t);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform subtraction in the time domain [abseil-time-subtraction]
+  // CHECK-FIXES: y = absl::ToInt64Minutes(absl::FromUnixMinutes(x) - t);
+  y = x - absl::ToUnixSeconds(t);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform subtraction in the time domain [abseil-time-subtraction]
+  // CHECK-FIXES: y = absl::ToInt64Seconds(absl::FromUnixSeconds(x) - t);
+  y = x - absl::ToUnixMillis(t);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform subtraction in the time domain [abseil-time-subtraction]
+  // CHECK-FIXES: y = absl::ToInt64Milliseconds(absl::FromUnixMillis(x) - t);
+  y = x - absl::ToUnixMicros(t);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform subtraction in the time domain [abseil-time-subtraction]
+  // CHECK-FIXES: y = absl::ToInt64Microseconds(absl::FromUnixMicros(x) - t);
+  y = x - absl::ToUnixNanos(t);
+  // CHECK-MESSAGES: [[@LINE-1]]:7: warning: perform subtraction in the time domain [abseil-time-subtraction]
+  // CHECK-FIXES: y = absl::ToInt64Nanoseconds(absl::FromUnixNanos(x) - t);
+
+  // Check parenthesis placement
+  d = 5 * absl::Seconds(absl::ToUnixSeconds(t) - x);
+  // CHECK-MESSAGES: [[@LINE-1]]:11: warning: perform subtraction in the time domain [abseil-time-subtraction]
+  // CHECK-FIXES: d = 5 * (t - absl::FromUnixSeconds(x));
+
+  // No extra parens around arguments
+  g(absl::Seconds(absl::ToUnixSeconds(t) - x));
+  // CHECK-MESSAGES: [[@LINE-1]]:5: warning: perform subtraction in the time domain [abseil-time-subtraction]
+  // CHECK-FIXES: g(t - absl::FromUnixSeconds(x));
+  g(absl::Seconds(x - absl::ToUnixSeconds(t)));
+  // CHECK-MESSAGES: [[@LINE-1]]:5: warning: perform subtraction in the time domain [abseil-time-subtraction]
+  // CHECK-FIXES: g(absl::FromUnixSeconds(x) - t);
+
+  // These should not trigger; they are likely bugs
+  d = absl::Milliseconds(absl::ToUnixSeconds(t) - x);
+  d = absl::Seconds(absl::ToUnixMicros(t) - x);
+}
+
+absl::Duration parens_in_return() {
+  absl::Time t;
+  int x;
+
+  return absl::Seconds(absl::ToUnixSeconds(t) - x);
+  // CHECK-MESSAGES: [[@LINE-1]]:10: warning: perform subtraction in the time domain [abseil-time-subtraction]
+  // CHECK-FIXES: return t - absl::FromUnixSeconds(x);
+  return absl::Seconds(x - absl::ToUnixSeconds(t));
+  // CHECK-MESSAGES: 

[PATCH] D54978: Move the SMT API to LLVM

2019-02-12 Thread Brian Rzycki via Phabricator via cfe-commits
brzycki added a comment.

The following patch:

  diff --git a/llvm/cmake/modules/CrossCompile.cmake 
b/llvm/cmake/modules/CrossCompile.cmake
  index bc3b210f018..0c30b88f80f 100644
  --- a/llvm/cmake/modules/CrossCompile.cmake
  +++ b/llvm/cmake/modules/CrossCompile.cmake
  @@ -53,6 +53,7 @@ function(llvm_create_cross_target_internal target_name 
toolchain buildtype)
   -DLLVM_DEFAULT_TARGET_TRIPLE="${TARGET_TRIPLE}"
   -DLLVM_TARGET_ARCH="${LLVM_TARGET_ARCH}"
   
-DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN="${LLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN}"
  +-DLLVM_ENABLE_Z3_SOLVER="${LLVM_ENABLE_Z3_SOLVER}"
   ${build_type_flags} ${linker_flag} ${external_clang_dir}
   WORKING_DIRECTORY ${LLVM_${target_name}_BUILD}
   DEPENDS CREATE_LLVM_${target_name}

fixes the build break when CMake is called in the following manner:

  cmake -v -G Ninja  -D LLVM_OPTIMIZED_TABLEGEN=ON -D LLVM_ENABLE_Z3_SOLVER=OFF 
../llvm-project/llvm

However, the custom command sub-call to CMake always fails in the same way with 
either of these invocations:

  cmake -v -G Ninja  -D LLVM_OPTIMIZED_TABLEGEN=ON -D LLVM_ENABLE_Z3_SOLVER=ON 
../llvm-project/llvm
  cmake -v -G Ninja  -D LLVM_OPTIMIZED_TABLEGEN=ON ../llvm-project/llvm

The error is the following:

  [209/2543] /usr/bin/c++  -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-Iutils/TableGen -I/work/brzycki/llvm-project/llvm/utils/TableGen 
-I/usr/include/libxml2 -Iinclude -I/work/brzycki/llvm-project/llvm/include 
-fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -Wextra 
-Wno-unused-parameter -Wwrite-strings -Wcast-qual 
-Wno-missing-field-initializers -pedantic -Wno-long-long -Wimplicit-fallthrough 
-Wno-maybe-uninitialized -Wno-noexcept-type -Wdelete-non-virtual-dtor 
-Wno-comment -fdiagnostics-color -g-fno-exceptions -fno-rtti -MD -MT 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/GlobalISelEmitter.cpp.o -MF 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/GlobalISelEmitter.cpp.o.d -o 
utils/TableGen/CMakeFiles/llvm-tblgen.dir/GlobalISelEmitter.cpp.o -c 
/work/brzycki/llvm-project/llvm/utils/TableGen/GlobalISelEmitter.cpp
  [210/2543] cd /work/brzycki/build/NATIVE && 
/sarc-c/compiler_tmp/tools/build/cmake-3.13.3/bin/cmake -G Ninja 
-DCMAKE_MAKE_PROGRAM="/sarc-c/compiler_tmp/tools/build/ninja-1.8.2/ninja" 
-DCMAKE_C_COMPILER=/usr/bin/cc -DCMAKE_CXX_COMPILER=/usr/bin/c++ 
/work/brzycki/llvm-project/llvm -DLLVM_TARGET_IS_CROSSCOMPILE_HOST=TRUE 
-DLLVM_TARGETS_TO_BUILD="AArch64;AMDGPU;ARM;BPF;Hexagon;Lanai;Mips;MSP430;NVPTX;PowerPC;Sparc;SystemZ;WebAssembly;X86;XCore"
 -DLLVM_EXPERIMENTAL_TARGETS_TO_BUILD="" 
-DLLVM_DEFAULT_TARGET_TRIPLE="x86_64-unknown-linux-gnu" 
-DLLVM_TARGET_ARCH="host" -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN="OFF" 
-DLLVM_ENABLE_Z3_SOLVER="ON" -DCMAKE_BUILD_TYPE=Release
  -- The C compiler identification is GNU 7.3.0
  -- The CXX compiler identification is GNU 7.3.0
  -- The ASM compiler identification is GNU
  -- Found assembler: /usr/bin/cc
  ...
  ...
  -- Performing Test HAVE_GNU_POSIX_REGEX -- failed to compile
  -- Performing Test HAVE_POSIX_REGEX
  -- Performing Test HAVE_POSIX_REGEX
  -- Performing Test HAVE_POSIX_REGEX -- success
  -- Performing Test HAVE_STEADY_CLOCK
  -- Performing Test HAVE_STEADY_CLOCK
  -- Performing Test HAVE_STEADY_CLOCK -- success
  -- Configuring done
  -- Generating done
  -- Build files have been written to: /work/brzycki/build/NATIVE
  ninja: build stopped: subcommand failed.

I tried passing more information to the sub CMake call, but it yielded the 
exact same results:

  +-DLLVM_ENABLE_Z3_SOLVER="${LLVM_ENABLE_Z3_SOLVER}"
  +-DLLVM_Z3_INSTALL_DIR="${LLVM_Z3_INSTALL_DIR}"
  +-DZ3_EXECUTABLE="${Z3_EXECUTABLE}"
  +-DZ3_INCLUDE_DIR="${Z3_INCLUDE_DIR}"
  +-DZ3_LIBRARIES="${Z3_LIBRARIES}"

When I diff the successful sub-CMake with the failing one, the only difference 
is the detection of the Z3 solver library:

  $ diff -u good_submake.txt bad_submake.txt
  --- good_submake.txt2019-02-12 11:41:54.638892191 -0600
  +++ bad_submake.txt 2019-02-12 11:43:30.096484824 -0600
  @@ -14,7 +14,7 @@
   -- Detecting CXX compiler ABI info - done
   -- Detecting CXX compile features
   -- Detecting CXX compile features - done
  --- Could NOT find Z3 (missing: Z3_LIBRARIES Z3_INCLUDE_DIR) (Required is at 
least version "4.7.1")
  +-- Found Z3: /usr/lib/x86_64-linux-gnu/libz3.so (Required is at least 
version "4.7.1")
   -- Looking for dlfcn.h
   -- Looking for dlfcn.h - found
   -- Looking for errno.h


Repository:
  rC Clang

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

https://reviews.llvm.org/D54978



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


r353870 - [AMDGPU] Require at least protected visibility for certain symbols

2019-02-12 Thread Scott Linder via cfe-commits
Author: scott.linder
Date: Tue Feb 12 10:30:38 2019
New Revision: 353870

URL: http://llvm.org/viewvc/llvm-project?rev=353870&view=rev
Log:
[AMDGPU] Require at least protected visibility for certain symbols

This allows the global visibility controls to be restrictive while still
populating the dynamic symbol table where required.

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

Added:
cfe/trunk/test/CodeGenOpenCL/visibility.cl
Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/TargetInfo.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=353870&r1=353869&r2=353870&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Tue Feb 12 10:30:38 2019
@@ -3212,6 +3212,9 @@ CodeGenModule::GetOrCreateLLVMGlobal(Str
 return getTargetCodeGenInfo().performAddrSpaceCast(*this, GV, AddrSpace,
ExpectedAS, Ty);
 
+  if (GV->isDeclaration())
+getTargetCodeGenInfo().setTargetAttributes(D, GV, *this);
+
   return GV;
 }
 

Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=353870&r1=353869&r2=353870&view=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Tue Feb 12 10:30:38 2019
@@ -7763,8 +7763,23 @@ public:
 };
 }
 
+static bool requiresAMDGPUProtectedVisibility(const Decl *D,
+  llvm::GlobalValue *GV) {
+  if (GV->getVisibility() != llvm::GlobalValue::HiddenVisibility)
+return false;
+
+  return D->hasAttr() ||
+ (isa(D) && D->hasAttr()) ||
+ (isa(D) && D->hasAttr());
+}
+
 void AMDGPUTargetCodeGenInfo::setTargetAttributes(
 const Decl *D, llvm::GlobalValue *GV, CodeGen::CodeGenModule &M) const {
+  if (requiresAMDGPUProtectedVisibility(D, GV)) {
+GV->setVisibility(llvm::GlobalValue::ProtectedVisibility);
+GV->setDSOLocal(true);
+  }
+
   if (GV->isDeclaration())
 return;
   const FunctionDecl *FD = dyn_cast_or_null(D);

Added: cfe/trunk/test/CodeGenOpenCL/visibility.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCL/visibility.cl?rev=353870&view=auto
==
--- cfe/trunk/test/CodeGenOpenCL/visibility.cl (added)
+++ cfe/trunk/test/CodeGenOpenCL/visibility.cl Tue Feb 12 10:30:38 2019
@@ -0,0 +1,77 @@
+// RUN: %clang_cc1 -std=cl2.0 -fapply-global-visibility-to-externs 
-fvisibility default -triple amdgcn-unknown-unknown -S -emit-llvm -o - %s | 
FileCheck --check-prefix=FVIS-DEFAULT %s
+// RUN: %clang_cc1 -std=cl2.0 -fapply-global-visibility-to-externs 
-fvisibility protected -triple amdgcn-unknown-unknown -S -emit-llvm -o - %s | 
FileCheck --check-prefix=FVIS-PROTECTED %s
+// RUN: %clang_cc1 -std=cl2.0 -fapply-global-visibility-to-externs 
-fvisibility hidden -triple amdgcn-unknown-unknown -S -emit-llvm -o - %s | 
FileCheck --check-prefix=FVIS-HIDDEN %s
+
+// REQUIRES: amdgpu-registered-target
+
+// FVIS-DEFAULT:  @glob = local_unnamed_addr
+// FVIS-PROTECTED: @glob = protected local_unnamed_addr
+// FVIS-HIDDEN: @glob = hidden local_unnamed_addr
+int glob = 0;
+// FVIS-DEFAULT:  @glob_hidden = hidden local_unnamed_addr
+// FVIS-PROTECTED: @glob_hidden = hidden local_unnamed_addr
+// FVIS-HIDDEN: @glob_hidden = hidden local_unnamed_addr
+__attribute__((visibility("hidden"))) int glob_hidden = 0;
+// FVIS-DEFAULT:  @glob_protected = protected local_unnamed_addr
+// FVIS-PROTECTED: @glob_protected = protected local_unnamed_addr
+// FVIS-HIDDEN: @glob_protected = protected local_unnamed_addr
+__attribute__((visibility("protected"))) int glob_protected = 0;
+// FVIS-DEFAULT:  @glob_default = local_unnamed_addr
+// FVIS-PROTECTED: @glob_default = local_unnamed_addr
+// FVIS-HIDDEN: @glob_default = local_unnamed_addr
+__attribute__((visibility("default"))) int glob_default = 0;
+
+// FVIS-DEFAULT:  @ext = external local_unnamed_addr
+// FVIS-PROTECTED: @ext = external protected local_unnamed_addr
+// FVIS-HIDDEN: @ext = external hidden local_unnamed_addr
+extern int ext;
+// FVIS-DEFAULT:  @ext_hidden = external hidden local_unnamed_addr
+// FVIS-PROTECTED: @ext_hidden = external hidden local_unnamed_addr
+// FVIS-HIDDEN: @ext_hidden = external hidden local_unnamed_addr
+__attribute__((visibility("hidden"))) extern int ext_hidden;
+// FVIS-DEFAULT:  @ext_protected = external protected local_unnamed_addr
+// FVIS-PROTECTED: @ext_protected = external protected local_unnamed_addr
+// FVIS-HIDDEN: @ext_protected = external protected local_unnamed_addr
+__attribute__((visibility("protected"))) extern int ext_protected;
+// FVIS-DEFAULT:  @ex

Re: [PATCH] D57984: PR40642: Fix determination of whether the final statement of a statementexpression is a discarded-value expression.

2019-02-12 Thread Richard Smith via cfe-commits
On Tue, 12 Feb 2019, 05:28 Aaron Ballman via Phabricator via cfe-commits, <
cfe-commits@lists.llvm.org> wrote:

> aaron.ballman added a comment.
>
> Considering that this has been fertile ground for buggy edge cases, should
> we revert my original changes from the 8.0 branch to give this more time to
> bake on trunk before releasing? Or do you think this is fine to move onto
> the release branch once finalized?
>

Let's revert your change for 8.0 and fix forward on trunk.


> Comment at: include/clang/AST/Stmt.h:1598-1602
> +  const Expr *getExprStmt() const;
> +  Expr *getExprStmt() {
> +const ValueStmt *ConstThis = this;
> +return const_cast(ConstThis->getExprStmt());
> +  }
> 
> rsmith wrote:
> > aaron.ballman wrote:
> > > We typically implement this in reverse, where the non-const version
> holds the actual implementation and the const version performs a
> `const_cast`.
> > We do. Do you think that's preferable? I like that this way around
> proves that the `const` version is const-correct, but it's a tiny benefit
> and I'm fine with just being consistent.
> Personally, I prefer the way you have it here (though I wish we had a
> global helper function to hide the dispatch dance).
>
>
> 
> Comment at: include/clang/Parse/Parser.h:374
> +  /// a statement expression and builds a suitable expression statement.
> +  StmtResult handleExprStmt(ExprResult E, WithinStmtExpr IsInStmtExpr);
>
> 
> rsmith wrote:
> > aaron.ballman wrote:
> > > Rather than passing around `IsInStmtExpr` to a bunch of parser APIs,
> would it make more sense to add an RAII object that sets some state on
> `Parser` to test it? The proliferation of arguments seems unfortunate given
> how much of a corner case statement expressions are.
> > Yeah, I tried that approach first, but the parser state turns out to be
> much worse, because it puts a burden on every form of statement that
> constructs a nested parsing context to reset that state. We can put the
> resetting on `ParseScope`, but it still needs to have an effect in the case
> where the scope is disabled, which is surprising, and there's no guarantee
> such statement constructs that can end in an expression will have a nested
> scope (consider, for instance, constructs like `return x;` or `goto
> *label;`). This is really local state that should only be propagated
> through a very small number of syntactic constructs rather than global
> state.
> >
> > Maybe we could combine the new flag with the `AllowOpenMPStandalone` /
> `AllowedConstructsKind` flag into a more general kind of "statement
> context". The propagation rules aren't quite the same
> (`AllowOpenMPStandalone` doesn't get propagated through labels whereas
> `IsInStmtExpr` does), which is a little awkward, but maybe that's not so
> bad -- and maybe that's actually a bug in the OpenMP implementation?
> > Maybe we could combine the new flag with the AllowOpenMPStandalone /
> AllowedConstructsKind flag into a more general kind of "statement context".
>
> That seems like a sensible approach to me.
>
>
> Repository:
>   rC Clang
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D57984/new/
>
> https://reviews.llvm.org/D57984
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D56871: [AMDGPU] Require at least protected visibility for certain symbols

2019-02-12 Thread Scott Linder via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL353870: [AMDGPU] Require at least protected visibility for 
certain symbols (authored by scott.linder, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D56871?vs=182561&id=186512#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D56871

Files:
  cfe/trunk/lib/CodeGen/CodeGenModule.cpp
  cfe/trunk/lib/CodeGen/TargetInfo.cpp
  cfe/trunk/test/CodeGenOpenCL/visibility.cl

Index: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
===
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp
@@ -3212,6 +3212,9 @@
 return getTargetCodeGenInfo().performAddrSpaceCast(*this, GV, AddrSpace,
ExpectedAS, Ty);
 
+  if (GV->isDeclaration())
+getTargetCodeGenInfo().setTargetAttributes(D, GV, *this);
+
   return GV;
 }
 
Index: cfe/trunk/lib/CodeGen/TargetInfo.cpp
===
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp
@@ -7763,8 +7763,23 @@
 };
 }
 
+static bool requiresAMDGPUProtectedVisibility(const Decl *D,
+  llvm::GlobalValue *GV) {
+  if (GV->getVisibility() != llvm::GlobalValue::HiddenVisibility)
+return false;
+
+  return D->hasAttr() ||
+ (isa(D) && D->hasAttr()) ||
+ (isa(D) && D->hasAttr());
+}
+
 void AMDGPUTargetCodeGenInfo::setTargetAttributes(
 const Decl *D, llvm::GlobalValue *GV, CodeGen::CodeGenModule &M) const {
+  if (requiresAMDGPUProtectedVisibility(D, GV)) {
+GV->setVisibility(llvm::GlobalValue::ProtectedVisibility);
+GV->setDSOLocal(true);
+  }
+
   if (GV->isDeclaration())
 return;
   const FunctionDecl *FD = dyn_cast_or_null(D);
Index: cfe/trunk/test/CodeGenOpenCL/visibility.cl
===
--- cfe/trunk/test/CodeGenOpenCL/visibility.cl
+++ cfe/trunk/test/CodeGenOpenCL/visibility.cl
@@ -0,0 +1,77 @@
+// RUN: %clang_cc1 -std=cl2.0 -fapply-global-visibility-to-externs -fvisibility default -triple amdgcn-unknown-unknown -S -emit-llvm -o - %s | FileCheck --check-prefix=FVIS-DEFAULT %s
+// RUN: %clang_cc1 -std=cl2.0 -fapply-global-visibility-to-externs -fvisibility protected -triple amdgcn-unknown-unknown -S -emit-llvm -o - %s | FileCheck --check-prefix=FVIS-PROTECTED %s
+// RUN: %clang_cc1 -std=cl2.0 -fapply-global-visibility-to-externs -fvisibility hidden -triple amdgcn-unknown-unknown -S -emit-llvm -o - %s | FileCheck --check-prefix=FVIS-HIDDEN %s
+
+// REQUIRES: amdgpu-registered-target
+
+// FVIS-DEFAULT:  @glob = local_unnamed_addr
+// FVIS-PROTECTED: @glob = protected local_unnamed_addr
+// FVIS-HIDDEN: @glob = hidden local_unnamed_addr
+int glob = 0;
+// FVIS-DEFAULT:  @glob_hidden = hidden local_unnamed_addr
+// FVIS-PROTECTED: @glob_hidden = hidden local_unnamed_addr
+// FVIS-HIDDEN: @glob_hidden = hidden local_unnamed_addr
+__attribute__((visibility("hidden"))) int glob_hidden = 0;
+// FVIS-DEFAULT:  @glob_protected = protected local_unnamed_addr
+// FVIS-PROTECTED: @glob_protected = protected local_unnamed_addr
+// FVIS-HIDDEN: @glob_protected = protected local_unnamed_addr
+__attribute__((visibility("protected"))) int glob_protected = 0;
+// FVIS-DEFAULT:  @glob_default = local_unnamed_addr
+// FVIS-PROTECTED: @glob_default = local_unnamed_addr
+// FVIS-HIDDEN: @glob_default = local_unnamed_addr
+__attribute__((visibility("default"))) int glob_default = 0;
+
+// FVIS-DEFAULT:  @ext = external local_unnamed_addr
+// FVIS-PROTECTED: @ext = external protected local_unnamed_addr
+// FVIS-HIDDEN: @ext = external hidden local_unnamed_addr
+extern int ext;
+// FVIS-DEFAULT:  @ext_hidden = external hidden local_unnamed_addr
+// FVIS-PROTECTED: @ext_hidden = external hidden local_unnamed_addr
+// FVIS-HIDDEN: @ext_hidden = external hidden local_unnamed_addr
+__attribute__((visibility("hidden"))) extern int ext_hidden;
+// FVIS-DEFAULT:  @ext_protected = external protected local_unnamed_addr
+// FVIS-PROTECTED: @ext_protected = external protected local_unnamed_addr
+// FVIS-HIDDEN: @ext_protected = external protected local_unnamed_addr
+__attribute__((visibility("protected"))) extern int ext_protected;
+// FVIS-DEFAULT:  @ext_default = external local_unnamed_addr
+// FVIS-PROTECTED: @ext_default = external local_unnamed_addr
+// FVIS-HIDDEN: @ext_default = external local_unnamed_addr
+__attribute__((visibility("default"))) extern int ext_default;
+
+// FVIS-DEFAULT: define amdgpu_kernel void @kern()
+// FVIS-PROTECTED: define protected amdgpu_kernel void @kern()
+// FVIS-HIDDEN: define protected amdgpu_kernel void @kern()
+kernel void kern() {}
+// FVIS-DEFAULT: define protected am

[PATCH] D58107: [MinGW] Add the profiling library when necessary

2019-02-12 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.

lgtm


Repository:
  rC Clang

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

https://reviews.llvm.org/D58107



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


[PATCH] D58106: [compiler-rt] [profile] Provide lprofGetHostName for all windows environments

2019-02-12 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.

lgtm


Repository:
  rCRT Compiler Runtime

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

https://reviews.llvm.org/D58106



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


[PATCH] D57662: [clang-tidy] Parallelise clang-tidy-diff.py

2019-02-12 Thread Zinovy Nis via Phabricator via cfe-commits
zinovy.nis updated this revision to Diff 186514.
zinovy.nis added a comment.

`-j` and `-export-fixes` were made mutually exclusive.


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

https://reviews.llvm.org/D57662

Files:
  clang-tidy/tool/clang-tidy-diff.py

Index: clang-tidy/tool/clang-tidy-diff.py
===
--- clang-tidy/tool/clang-tidy-diff.py
+++ clang-tidy/tool/clang-tidy-diff.py
@@ -25,9 +25,56 @@
 
 import argparse
 import json
+import multiprocessing
+import os
 import re
 import subprocess
 import sys
+import threading
+
+is_py2 = sys.version[0] == '2'
+
+if is_py2:
+import Queue as queue
+else:
+import queue as queue
+
+def run_tidy(task_queue, lock, timeout):
+  watchdog = None
+  while True:
+command = task_queue.get()
+try:
+  proc = subprocess.Popen(command,
+  stdout=subprocess.PIPE,
+  stderr=subprocess.PIPE)
+
+  if not timeout is None:
+watchdog = threading.Timer(timeout, proc.kill)
+watchdog.start()
+
+  stdout, stderr = proc.communicate()
+
+  with lock:
+sys.stdout.write(' '.join(command) + '\n' + stdout.decode('utf-8') + '\n')
+if stderr:
+  sys.stderr.write(stderr.decode('utf-8') + '\n')
+except:
+  with lock:
+sys.stderr.write('Failed: ' + str(sys.exc_info()[0]) + ' '.join(command) + '\n')
+finally:
+  with lock:
+if (not timeout is None) and (not watchdog is None):
+  if not watchdog.is_alive():
+  sys.stderr.write('Terminated by timeout: ' + ' '.join(command) + '\n')
+  watchdog.cancel()
+  task_queue.task_done()
+
+
+def run_workers(max_tasks, tidy_caller, task_queue, lock, timeout):
+  for _ in range(max_tasks):
+t = threading.Thread(target=tidy_caller, args=(task_queue, lock, timeout))
+t.daemon = True
+t.start()
 
 
 def main():
@@ -48,6 +95,10 @@
   help='custom pattern selecting file paths to check '
   '(case insensitive, overridden by -regex)')
 
+  parser.add_argument('-j', type=int, default=0,
+  help='number of tidy instances to be run in parallel.')
+  parser.add_argument('-timeout', type=int, default=None,
+  help='timeout per each file in seconds.')
   parser.add_argument('-fix', action='store_true', default=False,
   help='apply suggested fixes')
   parser.add_argument('-checks',
@@ -77,6 +128,11 @@
 
   args = parser.parse_args(argv)
 
+  if args.j == 0 or args.j > 1:
+if args.export_fixes:
+  print("error: -export-fixes and -j are mutually exclusive.")
+  sys.exit(1)
+
   # Extract changed lines for each file.
   filename = None
   lines_by_file = {}
@@ -84,7 +140,7 @@
 match = re.search('^\+\+\+\ \"?(.*?/){%s}([^ \t\n\"]*)' % args.p, line)
 if match:
   filename = match.group(2)
-if filename == None:
+if filename is None:
   continue
 
 if args.regex is not None:
@@ -102,44 +158,64 @@
 line_count = int(match.group(3))
   if line_count == 0:
 continue
-  end_line = start_line + line_count - 1;
+  end_line = start_line + line_count - 1
   lines_by_file.setdefault(filename, []).append([start_line, end_line])
 
-  if len(lines_by_file) == 0:
+  if not any(lines_by_file):
 print("No relevant changes found.")
 sys.exit(0)
 
-  line_filter_json = json.dumps(
-[{"name" : name, "lines" : lines_by_file[name]} for name in lines_by_file],
-separators = (',', ':'))
+  max_task = args.j
+  if max_task == 0:
+  max_task = multiprocessing.cpu_count()
+  max_task = min(len(lines_by_file), max_task)
+
+  # Tasks for clang-tidy.
+  task_queue = queue.Queue(max_task)
+  # A lock for console output.
+  lock = threading.Lock()
 
-  quote = "";
-  if sys.platform == 'win32':
-line_filter_json=re.sub(r'"', r'"""', line_filter_json)
-  else:
-quote = "'";
+  # Run a pool of clang-tidy workers.
+  run_workers(max_task, run_tidy, task_queue, lock, args.timeout)
 
-  # Run clang-tidy on files containing changes.
-  command = [args.clang_tidy_binary]
-  command.append('-line-filter=' + quote + line_filter_json + quote)
+  quote = ""
+  if sys.platform != 'win32':
+quote = "'"
+
+  # Form the common args list.
+  common_clang_tidy_args = []
   if args.fix:
-command.append('-fix')
+common_clang_tidy_args.append('-fix')
   if args.export_fixes:
-command.append('-export-fixes=' + args.export_fixes)
+common_clang_tidy_args.append('-export-fixes=' + args.export_fixes)
   if args.checks != '':
-command.append('-checks=' + quote + args.checks + quote)
+common_clang_tidy_args.append('-checks=' + quote + args.checks + quote)
   if args.quiet:
-command.append('-quiet')
+common_clang_tidy_args.append('-quiet')
   if args.build_path is not None:
-command.append('-p=%s' % args.build_path)
-  

[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

2019-02-12 Thread Lingda Li via Phabricator via cfe-commits
lildmh marked an inline comment as done.
lildmh added inline comments.



Comment at: lib/Sema/SemaLookup.cpp:1074
 
+  if (NameKind == LookupOMPMapperName) {
+// Skip out-of-scope declarations.

ABataev wrote:
> lildmh wrote:
> > ABataev wrote:
> > > lildmh wrote:
> > > > ABataev wrote:
> > > > > lildmh wrote:
> > > > > > ABataev wrote:
> > > > > > > Why do we need special processing of the mapper here?
> > > > > > The declare mapper lookup needs to find all `OMPDeclareMapperDecl`s 
> > > > > > with the same name (the same as declare reduction lookup), and thus 
> > > > > > it goes through all scopes from the innermost to the outtermost.
> > > > > > 
> > > > > > Then it looks up a parent scope S (e.g., the outter {} in the 
> > > > > > following example), all `OMPDeclareMapperDecl`s declared in the 
> > > > > > children scopes of S will appear in the range between 
> > > > > > `IdResolver.begin(Name)` and `IdResolver.end()`. Also, the `declare 
> > > > > > mapper(id: struct S s)` will appear before `omp declare mapper(id: 
> > > > > > struct SS ss)`. This can cause the lookup function to ignore later 
> > > > > > `omp declare mapper(id: struct SS ss)` declared in the outter 
> > > > > > scope. As a result, we may not find the corrent mapper.
> > > > > > 
> > > > > > ```
> > > > > > {
> > > > > >   #pragma omp declare mapper(id: struct S s) (s.a)
> > > > > >   {
> > > > > > #pragma omp declare mapper(id: struct SS ss) (ss.b)
> > > > > > ...
> > > > > >   }
> > > > > > }
> > > > > > ```
> > > > > > 
> > > > > > To fix this problem, the purpose of this part of code is to ignore 
> > > > > > all `OMPDeclareMapperDecl`s in inner scopes, which are already 
> > > > > > found in previous calls to `LookupParsedName()` from 
> > > > > > `buildUserDefinedMapperRef`.
> > > > > > 
> > > > > > I also found that the declare reduction lookup has the same 
> > > > > > problem. I'll push out a similar fix for the declare reduction 
> > > > > > later.
> > > > > I don't think this is the correct behavior. For user-defined 
> > > > > reductions, the standard says "This match is done by means of a name 
> > > > > lookup in the base language." It means we should use the lookup rules 
> > > > > of C/C++. For mapper, seems to me, we also should completely rely on 
> > > > > the visibility/accessibility rules used by C/C++.
> > > > Again, thanks for your quick response!
> > > > 
> > > > ```
> > > > {
> > > >   #pragma omp declare mapper(id: struct S s) (s.a)
> > > >   {
> > > > #pragma omp declare mapper(id: struct SS ss) (ss.b)
> > > > struct S kk;
> > > > #pragma omp target map(mapper(id), tofrom: kk)
> > > > {}
> > > >   }
> > > > }
> > > > ```
> > > > 
> > > > If I don't add this code, the above code will report error that it 
> > > > cannnot find a mapper with name `id` for type `struct S`, because it 
> > > > can only find the second mapper for type `struct SS`. This doesn't look 
> > > > like correct behavior to me.
> > > > 
> > > > I think we are still following the lookup rules of C/C++ with this fix. 
> > > > It's because for declare mapper and reduction, we call 
> > > > `LookupParsedName` multiple times on different scopes. In other cases, 
> > > > `LookupParsedName` is always called once. Because of this difference, I 
> > > > think this fix is appropriate. What is your thought?
> > > No, in your case we don't. According to the C/C++ rules, if the variable 
> > > is redeclared, the latest declaration is used. The same rule must be 
> > > applied to the mapper (according to the standard "The visibility and 
> > > accessibility of this declaration are the same as those of a variable 
> > > declared at the same point in the program.")
> > > I think that the code should fail in this case, because you would the 
> > > error message in case of the variables declarations with the same names 
> > > in those scopes.
> > Hi Alexey,
> > 
> > Thanks for your quick response! I don't think it's redeclared in this case, 
> > because a mapper has two properties: name and type, just as declare 
> > reduction. Only when both name and type are the same, it should be 
> > considered as redeclaration.
> > 
> > If we consider the above example as redeclaration of a mapper, then we can 
> > always just call `LookupParsedName` once to find the most relevant 
> > mapper/reductor. Then why do you need to search reductors in a while loop 
> > in `buildDeclareReductionRef`?
> > 
> > Also, the following example will be correct using the original lookup 
> > functions, without my fix:
> > 
> > ```
> > {
> >   #pragma omp declare mapper(id: struct S s) (s.a)
> > #pragma omp declare mapper(id: struct SS ss) (ss.b)
> > struct S kk;
> > #pragma omp target map(mapper(id), tofrom: kk)
> > {}
> > }
> > ```
> > 
> > If we consider the second mapper as a redeclaration of the first one, this 
> > should fail as well. What do you think?
> The standard clearly states that "The visibil

[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

2019-02-12 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added inline comments.



Comment at: lib/Sema/SemaLookup.cpp:1074
 
+  if (NameKind == LookupOMPMapperName) {
+// Skip out-of-scope declarations.

lildmh wrote:
> ABataev wrote:
> > lildmh wrote:
> > > ABataev wrote:
> > > > lildmh wrote:
> > > > > ABataev wrote:
> > > > > > lildmh wrote:
> > > > > > > ABataev wrote:
> > > > > > > > Why do we need special processing of the mapper here?
> > > > > > > The declare mapper lookup needs to find all 
> > > > > > > `OMPDeclareMapperDecl`s with the same name (the same as declare 
> > > > > > > reduction lookup), and thus it goes through all scopes from the 
> > > > > > > innermost to the outtermost.
> > > > > > > 
> > > > > > > Then it looks up a parent scope S (e.g., the outter {} in the 
> > > > > > > following example), all `OMPDeclareMapperDecl`s declared in the 
> > > > > > > children scopes of S will appear in the range between 
> > > > > > > `IdResolver.begin(Name)` and `IdResolver.end()`. Also, the 
> > > > > > > `declare mapper(id: struct S s)` will appear before `omp declare 
> > > > > > > mapper(id: struct SS ss)`. This can cause the lookup function to 
> > > > > > > ignore later `omp declare mapper(id: struct SS ss)` declared in 
> > > > > > > the outter scope. As a result, we may not find the corrent mapper.
> > > > > > > 
> > > > > > > ```
> > > > > > > {
> > > > > > >   #pragma omp declare mapper(id: struct S s) (s.a)
> > > > > > >   {
> > > > > > > #pragma omp declare mapper(id: struct SS ss) (ss.b)
> > > > > > > ...
> > > > > > >   }
> > > > > > > }
> > > > > > > ```
> > > > > > > 
> > > > > > > To fix this problem, the purpose of this part of code is to 
> > > > > > > ignore all `OMPDeclareMapperDecl`s in inner scopes, which are 
> > > > > > > already found in previous calls to `LookupParsedName()` from 
> > > > > > > `buildUserDefinedMapperRef`.
> > > > > > > 
> > > > > > > I also found that the declare reduction lookup has the same 
> > > > > > > problem. I'll push out a similar fix for the declare reduction 
> > > > > > > later.
> > > > > > I don't think this is the correct behavior. For user-defined 
> > > > > > reductions, the standard says "This match is done by means of a 
> > > > > > name lookup in the base language." It means we should use the 
> > > > > > lookup rules of C/C++. For mapper, seems to me, we also should 
> > > > > > completely rely on the visibility/accessibility rules used by C/C++.
> > > > > Again, thanks for your quick response!
> > > > > 
> > > > > ```
> > > > > {
> > > > >   #pragma omp declare mapper(id: struct S s) (s.a)
> > > > >   {
> > > > > #pragma omp declare mapper(id: struct SS ss) (ss.b)
> > > > > struct S kk;
> > > > > #pragma omp target map(mapper(id), tofrom: kk)
> > > > > {}
> > > > >   }
> > > > > }
> > > > > ```
> > > > > 
> > > > > If I don't add this code, the above code will report error that it 
> > > > > cannnot find a mapper with name `id` for type `struct S`, because it 
> > > > > can only find the second mapper for type `struct SS`. This doesn't 
> > > > > look like correct behavior to me.
> > > > > 
> > > > > I think we are still following the lookup rules of C/C++ with this 
> > > > > fix. It's because for declare mapper and reduction, we call 
> > > > > `LookupParsedName` multiple times on different scopes. In other 
> > > > > cases, `LookupParsedName` is always called once. Because of this 
> > > > > difference, I think this fix is appropriate. What is your thought?
> > > > No, in your case we don't. According to the C/C++ rules, if the 
> > > > variable is redeclared, the latest declaration is used. The same rule 
> > > > must be applied to the mapper (according to the standard "The 
> > > > visibility and accessibility of this declaration are the same as those 
> > > > of a variable declared at the same point in the program.")
> > > > I think that the code should fail in this case, because you would the 
> > > > error message in case of the variables declarations with the same names 
> > > > in those scopes.
> > > Hi Alexey,
> > > 
> > > Thanks for your quick response! I don't think it's redeclared in this 
> > > case, because a mapper has two properties: name and type, just as declare 
> > > reduction. Only when both name and type are the same, it should be 
> > > considered as redeclaration.
> > > 
> > > If we consider the above example as redeclaration of a mapper, then we 
> > > can always just call `LookupParsedName` once to find the most relevant 
> > > mapper/reductor. Then why do you need to search reductors in a while loop 
> > > in `buildDeclareReductionRef`?
> > > 
> > > Also, the following example will be correct using the original lookup 
> > > functions, without my fix:
> > > 
> > > ```
> > > {
> > >   #pragma omp declare mapper(id: struct S s) (s.a)
> > > #pragma omp declare mapper(id: struct SS ss) (ss.b)
> > > struct S kk;
> > > #pragma omp target map(mapper(id), tofrom: kk)
> > > {}
> > >

[PATCH] D57977: [HIP] compile option code-object-v3 propagate to llc

2019-02-12 Thread Aaron Enye Shi via Phabricator via cfe-commits
ashi1 updated this revision to Diff 186519.
ashi1 added a comment.
Herald added a subscriber: jdoerfert.

Changed patch to us handleTargetFeatures, to consume all -m options passed into 
clang.


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

https://reviews.llvm.org/D57977

Files:
  lib/Driver/ToolChains/HIP.cpp


Index: lib/Driver/ToolChains/HIP.cpp
===
--- lib/Driver/ToolChains/HIP.cpp
+++ lib/Driver/ToolChains/HIP.cpp
@@ -162,9 +162,26 @@
   // AMDGPUPromoteAlloca pass which cause invalid memory access in PyTorch.
   // Remove this once the issue is fixed.
   ArgStringList LlcArgs{InputFileName, "-mtriple=amdgcn-amd-amdhsa",
-"-filetype=obj", "-mattr=-code-object-v3",
+"-filetype=obj",
 "-disable-promote-alloca-to-lds",
-Args.MakeArgString("-mcpu=" + SubArchName), "-o"};
+Args.MakeArgString("-mcpu=" + SubArchName)};
+
+  // Extract all the -m options
+  std::vector Features;
+  handleTargetFeaturesGroup(
+Args, Features, options::OPT_m_amdgpu_Features_Group);
+
+  // Add features to mattr such as code-object-v3 and xnack
+  std::string MAttrString = "-mattr=";
+  for(auto OneFeature : Features) {
+MAttrString.append(Args.MakeArgString(OneFeature));
+if (OneFeature != Features.back())
+  MAttrString.append(",");
+  }
+  LlcArgs.push_back(Args.MakeArgString(MAttrString));
+
+  // Add output filename
+  LlcArgs.push_back("-o");
   std::string LlcOutputFileName =
   C.getDriver().GetTemporaryPath(OutputFilePrefix, "o");
   const char *LlcOutputFile =


Index: lib/Driver/ToolChains/HIP.cpp
===
--- lib/Driver/ToolChains/HIP.cpp
+++ lib/Driver/ToolChains/HIP.cpp
@@ -162,9 +162,26 @@
   // AMDGPUPromoteAlloca pass which cause invalid memory access in PyTorch.
   // Remove this once the issue is fixed.
   ArgStringList LlcArgs{InputFileName, "-mtriple=amdgcn-amd-amdhsa",
-"-filetype=obj", "-mattr=-code-object-v3",
+"-filetype=obj",
 "-disable-promote-alloca-to-lds",
-Args.MakeArgString("-mcpu=" + SubArchName), "-o"};
+Args.MakeArgString("-mcpu=" + SubArchName)};
+
+  // Extract all the -m options
+  std::vector Features;
+  handleTargetFeaturesGroup(
+Args, Features, options::OPT_m_amdgpu_Features_Group);
+
+  // Add features to mattr such as code-object-v3 and xnack
+  std::string MAttrString = "-mattr=";
+  for(auto OneFeature : Features) {
+MAttrString.append(Args.MakeArgString(OneFeature));
+if (OneFeature != Features.back())
+  MAttrString.append(",");
+  }
+  LlcArgs.push_back(Args.MakeArgString(MAttrString));
+
+  // Add output filename
+  LlcArgs.push_back("-o");
   std::string LlcOutputFileName =
   C.getDriver().GetTemporaryPath(OutputFilePrefix, "o");
   const char *LlcOutputFile =
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D57977: [HIP] compile option code-object-v3 propagate to llc

2019-02-12 Thread Konstantin Zhuravlyov via Phabricator via cfe-commits
kzhuravl added a comment.

Can you add some tests? Preferably with -mxnack/-mno-xnack, 
-msram-ecc/-mno-sram-ecc, -mcode-object-v3/-mno-code-object-v3


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

https://reviews.llvm.org/D57977



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


[PATCH] D57991: [Driver][Darwin] Emit an error when using -pg on OS without support for it.

2019-02-12 Thread Volodymyr Sapsai via Phabricator via cfe-commits
vsapsai updated this revision to Diff 186522.
vsapsai added a comment.
Herald added a subscriber: jdoerfert.

- Use `%select` per Steven's recommendation.


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

https://reviews.llvm.org/D57991

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/test/Driver/darwin-ld.c


Index: clang/test/Driver/darwin-ld.c
===
--- clang/test/Driver/darwin-ld.c
+++ clang/test/Driver/darwin-ld.c
@@ -203,6 +203,14 @@
 // LINK_PG: -lgcrt1.o
 // LINK_PG: -no_new_main
 
+// RUN: %clang -target i386-apple-darwin13 -pg -### %t.o 2> %t.log
+// RUN: FileCheck -check-prefix=LINK_PG_NO_SUPPORT_OSX %s < %t.log
+// LINK_PG_NO_SUPPORT_OSX: error: the clang compiler does not support -pg 
option on versions of OS X
+
+// RUN: %clang -target x86_64-apple-ios5.0 -pg -### %t.o 2> %t.log
+// RUN: FileCheck -check-prefix=LINK_PG_NO_SUPPORT %s < %t.log
+// LINK_PG_NO_SUPPORT: error: the clang compiler does not support -pg option 
on Darwin
+
 // Check that clang links with libgcc_s.1 for iOS 4 and earlier, but not arm64.
 // RUN: %clang -target armv7-apple-ios4.0 -miphoneos-version-min=4.0 -### %t.o 
2> %t.log
 // RUN: FileCheck -check-prefix=LINK_IOS_LIBGCC_S %s < %t.log
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -2289,22 +2289,27 @@
   }
 } else {
   if (Args.hasArg(options::OPT_pg) && SupportsProfiling()) {
-if (Args.hasArg(options::OPT_static) ||
-Args.hasArg(options::OPT_object) ||
-Args.hasArg(options::OPT_preload)) {
-  CmdArgs.push_back("-lgcrt0.o");
-} else {
-  CmdArgs.push_back("-lgcrt1.o");
+if (isTargetMacOS() && isMacosxVersionLT(10, 9)) {
+  if (Args.hasArg(options::OPT_static) ||
+  Args.hasArg(options::OPT_object) ||
+  Args.hasArg(options::OPT_preload)) {
+CmdArgs.push_back("-lgcrt0.o");
+  } else {
+CmdArgs.push_back("-lgcrt1.o");
 
-  // darwin_crt2 spec is empty.
+// darwin_crt2 spec is empty.
+  }
+  // By default on OS X 10.8 and later, we don't link with a crt1.o
+  // file and the linker knows to use _main as the entry point.  But,
+  // when compiling with -pg, we need to link with the gcrt1.o file,
+  // so pass the -no_new_main option to tell the linker to use the
+  // "start" symbol as the entry point.
+  if (isTargetMacOS() && !isMacosxVersionLT(10, 8))
+CmdArgs.push_back("-no_new_main");
+} else {
+  getDriver().Diag(diag::err_drv_clang_unsupported_opt_pg_darwin)
+  << isTargetMacOS();
 }
-// By default on OS X 10.8 and later, we don't link with a crt1.o
-// file and the linker knows to use _main as the entry point.  But,
-// when compiling with -pg, we need to link with the gcrt1.o file,
-// so pass the -no_new_main option to tell the linker to use the
-// "start" symbol as the entry point.
-if (isTargetMacOS() && !isMacosxVersionLT(10, 8))
-  CmdArgs.push_back("-no_new_main");
   } else {
 if (Args.hasArg(options::OPT_static) ||
 Args.hasArg(options::OPT_object) ||
Index: clang/include/clang/Basic/DiagnosticDriverKinds.td
===
--- clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -96,6 +96,8 @@
   "the clang compiler does not support '%0'">;
 def err_drv_clang_unsupported_opt_cxx_darwin_i386 : Error<
   "the clang compiler does not support '%0' for C++ on Darwin/i386">;
+def err_drv_clang_unsupported_opt_pg_darwin: Error<
+  "the clang compiler does not support -pg option on %select{Darwin|versions 
of OS X 10.9 and later}0">;
 def err_drv_clang_unsupported_opt_faltivec : Error<
   "the clang compiler does not support '%0', %1">;
 def err_drv_command_failed : Error<


Index: clang/test/Driver/darwin-ld.c
===
--- clang/test/Driver/darwin-ld.c
+++ clang/test/Driver/darwin-ld.c
@@ -203,6 +203,14 @@
 // LINK_PG: -lgcrt1.o
 // LINK_PG: -no_new_main
 
+// RUN: %clang -target i386-apple-darwin13 -pg -### %t.o 2> %t.log
+// RUN: FileCheck -check-prefix=LINK_PG_NO_SUPPORT_OSX %s < %t.log
+// LINK_PG_NO_SUPPORT_OSX: error: the clang compiler does not support -pg option on versions of OS X
+
+// RUN: %clang -target x86_64-apple-ios5.0 -pg -### %t.o 2> %t.log
+// RUN: FileCheck -check-prefix=LINK_PG_NO_SUPPORT %s < %t.log
+// LINK_PG_NO_SUPPORT: error: the clang compiler does not support -pg option on Darwin
+
 // Check that clang links with libgcc_s.1 for iOS 4 and 

[PATCH] D58074: [OpenMP 5.0] Parsing/sema support for map clause with mapper modifier

2019-02-12 Thread Kelvin Li via Phabricator via cfe-commits
kkwli0 added inline comments.



Comment at: include/clang/AST/OpenMPClause.h:4077
 
+  /// C++ nested name specifier for the assoicated user-defined mapper.
+  NestedNameSpecifierLoc MapperQualifierLoc;

assoicated -> associated



Comment at: include/clang/AST/OpenMPClause.h:4212
+assert(DMDs.size() == varlist_size() &&
+   "Unexpected amount of user-defined mappers.");
+std::copy(DMDs.begin(), DMDs.end(), getUDMapperRefs().begin());

amount -> number?



Comment at: include/clang/AST/OpenMPClause.h:4229
   /// \param MapModifiersLoc Location of map-type-modifiers.
+  /// \param UDMQualifierLoc C++ nested name specifier for the assoicated
+  /// user-defined mapper.

assoicated -> associated



Comment at: lib/Parse/ParseOpenMP.cpp:2144
+parseMapType(*this, Data);
 }
 if (Data.MapType == OMPC_MAP_unknown) {

Although it is an error situation, will we have different behavior?

```
... map(xclose, to: x)
```

Previously, it always parses both modifier and type.  After the change, the 
call of `parseMapType` is skipped.  If it `OMPC_MAP_unknown`, 
`IsMapTypeImplicit` is set.


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

https://reviews.llvm.org/D58074



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


[PATCH] D58062: Support framework import/include auto-completion

2019-02-12 Thread David Goldman via Phabricator via cfe-commits
dgoldman updated this revision to Diff 186524.
dgoldman marked 9 inline comments as done.
dgoldman added a comment.
Herald added a subscriber: jdoerfert.

- Misc fixes


Repository:
  rC Clang

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

https://reviews.llvm.org/D58062

Files:
  lib/Sema/SemaCodeComplete.cpp


Index: lib/Sema/SemaCodeComplete.cpp
===
--- lib/Sema/SemaCodeComplete.cpp
+++ lib/Sema/SemaCodeComplete.cpp
@@ -8371,10 +8371,23 @@
   };
 
   // Helper: scans IncludeDir for nice files, and adds results for each.
-  auto AddFilesFromIncludeDir = [&](StringRef IncludeDir, bool IsSystem) {
+  auto AddFilesFromIncludeDir = [&](StringRef IncludeDir,
+bool IsSystem,
+DirectoryLookup::LookupType_t LookupType) {
 llvm::SmallString<128> Dir = IncludeDir;
-if (!NativeRelDir.empty())
-  llvm::sys::path::append(Dir, NativeRelDir);
+if (!NativeRelDir.empty()) {
+  if (LookupType == DirectoryLookup::LT_Framework) {
+// For a framework dir, #include  actually maps to
+// a path of Foo.framework/Headers/Bar/.
+auto Begin = llvm::sys::path::begin(NativeRelDir);
+auto End = llvm::sys::path::end(NativeRelDir);
+
+llvm::sys::path::append(Dir, *Begin + ".framework", "Headers");
+llvm::sys::path::append(Dir, ++Begin, End);
+  } else {
+llvm::sys::path::append(Dir, NativeRelDir);
+  }
+}
 
 std::error_code EC;
 unsigned Count = 0;
@@ -8385,6 +8398,16 @@
   StringRef Filename = llvm::sys::path::filename(It->path());
   switch (It->type()) {
   case llvm::sys::fs::file_type::directory_file:
+// All entries in a framework directory must have a ".framework" 
suffix,
+// but the suffix does not appear in the source code's include/import.
+if (LookupType == DirectoryLookup::LT_Framework) {
+  if (!Filename.endswith(".framework")) {
+break;
+  }
+  if (NativeRelDir.empty()) {
+Filename.consume_back(".framework");
+  }
+}
 AddCompletion(Filename, /*IsDirectory=*/true);
 break;
   case llvm::sys::fs::file_type::regular_file:
@@ -8413,10 +8436,12 @@
   // header maps are not (currently) enumerable.
   break;
 case DirectoryLookup::LT_NormalDir:
-  AddFilesFromIncludeDir(IncludeDir.getDir()->getName(), IsSystem);
+  AddFilesFromIncludeDir(IncludeDir.getDir()->getName(), IsSystem,
+ DirectoryLookup::LT_NormalDir);
   break;
 case DirectoryLookup::LT_Framework:
-  AddFilesFromIncludeDir(IncludeDir.getFrameworkDir()->getName(), 
IsSystem);
+  AddFilesFromIncludeDir(IncludeDir.getFrameworkDir()->getName(), IsSystem,
+ DirectoryLookup::LT_Framework);
   break;
 }
   };
@@ -8430,7 +8455,8 @@
 // The current directory is on the include path for "quoted" includes.
 auto *CurFile = PP.getCurrentFileLexer()->getFileEntry();
 if (CurFile && CurFile->getDir())
-  AddFilesFromIncludeDir(CurFile->getDir()->getName(), false);
+  AddFilesFromIncludeDir(CurFile->getDir()->getName(), false,
+ DirectoryLookup::LT_NormalDir);
 for (const auto &D : make_range(S.quoted_dir_begin(), S.quoted_dir_end()))
   AddFilesFromDirLookup(D, false);
   }


Index: lib/Sema/SemaCodeComplete.cpp
===
--- lib/Sema/SemaCodeComplete.cpp
+++ lib/Sema/SemaCodeComplete.cpp
@@ -8371,10 +8371,23 @@
   };
 
   // Helper: scans IncludeDir for nice files, and adds results for each.
-  auto AddFilesFromIncludeDir = [&](StringRef IncludeDir, bool IsSystem) {
+  auto AddFilesFromIncludeDir = [&](StringRef IncludeDir,
+bool IsSystem,
+DirectoryLookup::LookupType_t LookupType) {
 llvm::SmallString<128> Dir = IncludeDir;
-if (!NativeRelDir.empty())
-  llvm::sys::path::append(Dir, NativeRelDir);
+if (!NativeRelDir.empty()) {
+  if (LookupType == DirectoryLookup::LT_Framework) {
+// For a framework dir, #include  actually maps to
+// a path of Foo.framework/Headers/Bar/.
+auto Begin = llvm::sys::path::begin(NativeRelDir);
+auto End = llvm::sys::path::end(NativeRelDir);
+
+llvm::sys::path::append(Dir, *Begin + ".framework", "Headers");
+llvm::sys::path::append(Dir, ++Begin, End);
+  } else {
+llvm::sys::path::append(Dir, NativeRelDir);
+  }
+}
 
 std::error_code EC;
 unsigned Count = 0;
@@ -8385,6 +8398,16 @@
   StringRef Filename = llvm::sys::path::filename(It->path());
   switch (It->type()) {
   case llvm::sys::fs::file_type::directory_file:
+// All entries in a framework directory must have a ".framework" suffix,
+  

[PATCH] D58072: Make ModuleDependencyCollector's method virtual (NFC)

2019-02-12 Thread Bruno Cardoso Lopes via Phabricator via cfe-commits
bruno added a comment.

I missed that the `DependencyCollector` already marks them virtual, you are 
just making it obvious here.  I think you can omit the ones that are already 
virtual and only add to the ones that are on the intend of this patch.


Repository:
  rC Clang

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

https://reviews.llvm.org/D58072



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


[PATCH] D58137: [clang-tidy] Add the abseil-time-subtraction check

2019-02-12 Thread Eugene Zelenko via Phabricator via cfe-commits
Eugene.Zelenko added inline comments.



Comment at: docs/ReleaseNotes.rst:91
+
+  Finds and fixes `absl::Time` subtraction expressions to do subtraction
+  in the Time domain instead of the numeric domain.

Please use two not one ` for language constructs.



Comment at: docs/clang-tidy/checks/abseil-time-subtraction.rst:11
+information:
+ - When the result is a ``Duration`` and the first argument is a ``Time``.
+ - When the second argument is a ``Time``.

Will be good idea to always use //absl::// prefix. Same in other places.



Comment at: docs/clang-tidy/checks/abseil-time-subtraction.rst:25
+
+  // Original - `Duration` result and first operand is a `Time`.
+  absl::Duration d = absl::Seconds(absl::ToUnixSeconds(t) - x);

` doesn't make sense in comments. Same below.


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D58137



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


[PATCH] D57961: [X86] Add explicit alignment to __m128/__m128i/__m128d/etc. to allow matching of MSVC behavior with #pragma pack.

2019-02-12 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.
Herald added a subscriber: jdoerfert.

Hm, looks like this broke a bunch of code in chromium:
bad build: 
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/ToTWin%28dbg%29/2342
good build: 
https://ci.chromium.org/p/chromium/builders/luci.chromium.ci/ToTWin%28dbg%29/2341

A trace from one of the crashing tests:

  [ RUN  ] 
AudioDecoderTestScenarios/AudioDecoderTest.DecodesFramesWithVaryingDuration/3
  Received fatal exception EXCEPTION_ACCESS_VIOLATION
  Backtrace:
xcorr_kernel_sse [0x00D4CEF7+199] 
(C:\b\s\w\ir\cache\builder\src\third_party\opus\src\celt\x86\pitch_sse.c:54)
celt_pitch_xcorr_c [0x00DBC09C+156] 
(C:\b\s\w\ir\cache\builder\src\third_party\opus\src\celt\pitch.c:264)
_celt_autocorr [0x00DBAF20+368] 
(C:\b\s\w\ir\cache\builder\src\third_party\opus\src\celt\celt_lpc.c:266)
pitch_downsample [0x00DBBC98+536] 
(C:\b\s\w\ir\cache\builder\src\third_party\opus\src\celt\pitch.c:182)
run_prefilter [0x00D4093F+703] 
(C:\b\s\w\ir\cache\builder\src\third_party\opus\src\celt\celt_encoder.c:1144)
celt_encode_with_ec [0x00D3C915+3701] 
(C:\b\s\w\ir\cache\builder\src\third_party\opus\src\celt\celt_encoder.c:1606)
opus_encode_native [0x00CBBF8A+16810] 
(C:\b\s\w\ir\cache\builder\src\third_party\opus\src\src\opus_encoder.c:2068)
opus_encode [0x00CBE1C6+374] 
(C:\b\s\w\ir\cache\builder\src\third_party\opus\src\src\opus_encoder.c:2241)
media::cast::AudioDecoderTest::FeedMoreAudio [0x0017F0B8+1064] 
(C:\b\s\w\ir\cache\builder\src\media\cast\receiver\audio_decoder_unittest.cc:111)

The code in question is calling _mm_loadu_ps:
https://cs.chromium.org/chromium/src/third_party/opus/src/celt/x86/pitch_sse.c?type=cs&q=%22opus/src/celt/x86/pitch_sse.c%22&sq=package:chromium&g=0&l=54

  for (j = 0; j < len-3; j += 4)
  {
 __m128 x0 = _mm_loadu_ps(x+j);
 __m128 yj = _mm_loadu_ps(y+j);
 __m128 y3 = _mm_loadu_ps(y+j+3); // crashes




Comment at: lib/Headers/xmmintrin.h:1754
 static __inline__ __m128 __DEFAULT_FN_ATTRS
 _mm_loadu_ps(const float *__p)
 {

I guess we just missed this.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57961



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


[PATCH] D57961: [X86] Add explicit alignment to __m128/__m128i/__m128d/etc. to allow matching of MSVC behavior with #pragma pack.

2019-02-12 Thread Reid Kleckner via Phabricator via cfe-commits
rnk added a comment.

I audited all the intrin header uses of __packed__, and I think this was the 
only one that was missing, so I'll try to fix forward.


Repository:
  rC Clang

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

https://reviews.llvm.org/D57961



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


[PATCH] D54978: Move the SMT API to LLVM

2019-02-12 Thread Brian Rzycki via Phabricator via cfe-commits
brzycki added a comment.

I think I found why others are struggling to recreate this issue. I did not 
have the package `z3/bionic` installed. This provides the `/usr/bin/z3` 
executable which `llvm/cmake/modules/FindZ3.cmake` relies upon to determine the 
correct `Z3_VERSION_STRING`.

If I perform the following on an unpatched checkout of sha b0a227049fda 
 the build 
works :

  sudo apt install -y z3 libz3-4 libz3-dev
  mkdir build && cd build

Either of the following CMake commands build successfully:

  cmake -G Ninja -D LLVM_OPTIMIZED_TABLEGEN=ON ../llvm-project/llvm
  cmake -G Ninja -D LLVM_OPTIMIZED_TABLEGEN=ON -D LLVM_ENABLE_Z3_SOLVER=OFF 
../llvm-project/llvm

And if I try `-D LLVM_ENABLE_Z3_SOLVER=ON` I receive a top-leve CMake error 
immediately:

  -- Could NOT find Z3: Found unsuitable version "4.4.1", but required is at 
least "4.7.1" (found /usr/lib/x86_64-linux-gnu/libz3.so)
  CMake Error at CMakeLists.txt:406 (message):
LLVM_ENABLE_Z3_SOLVER cannot be enabled when Z3 is not available.
  
  
  -- Configuring incomplete, errors occurred!
  See also "/work/brzycki/build/CMakeFiles/CMakeOutput.log".
  ninja: error: loading 'build.ninja': No such file or directory

Unfortunately it's completely valid to install packages `libz3-4` and 
`libz3-dev` without pulling in `z3` on Ubuntu 18.04.  I've added this to my 
internal build notes.

I'm also looking to see if there's a way to better  handle this case inside the 
`find_package(Z3 ...)` subsystem of llvm.


Repository:
  rC Clang

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

https://reviews.llvm.org/D54978



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


r353875 - [NFC] typo

2019-02-12 Thread JF Bastien via cfe-commits
Author: jfb
Date: Tue Feb 12 12:19:16 2019
New Revision: 353875

URL: http://llvm.org/viewvc/llvm-project?rev=353875&view=rev
Log:
[NFC] typo

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

Modified: cfe/trunk/include/clang/AST/Decl.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Decl.h?rev=353875&r1=353874&r2=353875&view=diff
==
--- cfe/trunk/include/clang/AST/Decl.h (original)
+++ cfe/trunk/include/clang/AST/Decl.h Tue Feb 12 12:19:16 2019
@@ -3851,7 +3851,7 @@ public:
   static bool classofKind(Kind K) { return K == FileScopeAsm; }
 };
 
-/// Pepresents a block literal declaration, which is like an
+/// Represents a block literal declaration, which is like an
 /// unnamed FunctionDecl.  For example:
 /// ^{ statement-body }   or   ^(int arg1, float arg2){ statement-body }
 class BlockDecl : public Decl, public DeclContext {


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


[PATCH] D57977: [HIP] compile option code-object-v3 propagate to llc

2019-02-12 Thread Aaron Enye Shi via Phabricator via cfe-commits
ashi1 updated this revision to Diff 186528.
ashi1 added a comment.

I've added a lit test to check for options such as -mxnack/-mno-xnack, 
-msram-ecc/-mno-sram-ecc, -mcode-object-v3/-mno-code-object-v3


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

https://reviews.llvm.org/D57977

Files:
  lib/Driver/ToolChains/HIP.cpp
  test/Driver/hip-toolchain-features.hip


Index: test/Driver/hip-toolchain-features.hip
===
--- /dev/null
+++ test/Driver/hip-toolchain-features.hip
@@ -0,0 +1,48 @@
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// REQUIRES: amdgpu-registered-target
+
+// RUN: %clang -### -c -target x86_64-linux-gnu -fgpu-rdc \
+// RUN:   -x hip --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN:   -mcode-object-v3 2>&1 | FileCheck %s -check-prefix=COV3
+// RUN: %clang -### -c -target x86_64-linux-gnu -fgpu-rdc \
+// RUN:   -x hip --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN:   -mno-code-object-v3 2>&1 | FileCheck %s -check-prefix=NOCOV3
+
+// COV3: {{.*}}clang{{.*}}"-target-feature" "+code-object-v3"
+// NOCOV3: {{.*}}clang{{.*}}"-target-feature" "-code-object-v3"
+
+
+// RUN: %clang -### -c -target x86_64-linux-gnu -fgpu-rdc \
+// RUN:   -x hip --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN:   -mxnack 2>&1 | FileCheck %s -check-prefix=XNACK
+// RUN: %clang -### -c -target x86_64-linux-gnu -fgpu-rdc \
+// RUN:   -x hip --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN:   -mno-xnack 2>&1 | FileCheck %s -check-prefix=NOXNACK
+
+// XNACK: {{.*}}clang{{.*}}"-target-feature" "+xnack"
+// NOXNACK: {{.*}}clang{{.*}}"-target-feature" "-xnack"
+
+
+// RUN: %clang -### -c -target x86_64-linux-gnu -fgpu-rdc \
+// RUN:   -x hip --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN:   -msram-ecc 2>&1 | FileCheck %s -check-prefix=SRAM
+// RUN: %clang -### -c -target x86_64-linux-gnu -fgpu-rdc \
+// RUN:   -x hip --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN:   -mno-sram-ecc 2>&1 | FileCheck %s -check-prefix=NOSRAM
+
+// SRAM: {{.*}}clang{{.*}}"-target-feature" "+sram-ecc"
+// NOSRAM: {{.*}}clang{{.*}}"-target-feature" "-sram-ecc"
+
+
+// RUN: %clang -### -c -target x86_64-linux-gnu -fgpu-rdc \
+// RUN:   -x hip --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN:   -mcode-object-v3 -mxnack -msram-ecc \
+// RUN:   2>&1 | FileCheck %s -check-prefix=ALL3
+// RUN: %clang -### -c -target x86_64-linux-gnu -fgpu-rdc \
+// RUN:   -x hip --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN:   -mno-code-object-v3 -mno-xnack -mno-sram-ecc \
+// RUN:   2>&1 | FileCheck %s -check-prefix=NOALL3
+
+// ALL3: {{.*}}clang{{.*}}"-target-feature" "+code-object-v3" 
"-target-feature" "+xnack" "-target-feature" "+sram-ecc"
+// NOALL3: {{.*}}clang{{.*}}"-target-feature" "-code-object-v3" 
"-target-feature" "-xnack" "-target-feature" "-sram-ecc"
Index: lib/Driver/ToolChains/HIP.cpp
===
--- lib/Driver/ToolChains/HIP.cpp
+++ lib/Driver/ToolChains/HIP.cpp
@@ -162,9 +162,26 @@
   // AMDGPUPromoteAlloca pass which cause invalid memory access in PyTorch.
   // Remove this once the issue is fixed.
   ArgStringList LlcArgs{InputFileName, "-mtriple=amdgcn-amd-amdhsa",
-"-filetype=obj", "-mattr=-code-object-v3",
+"-filetype=obj",
 "-disable-promote-alloca-to-lds",
-Args.MakeArgString("-mcpu=" + SubArchName), "-o"};
+Args.MakeArgString("-mcpu=" + SubArchName)};
+
+  // Extract all the -m options
+  std::vector Features;
+  handleTargetFeaturesGroup(
+Args, Features, options::OPT_m_amdgpu_Features_Group);
+
+  // Add features to mattr such as code-object-v3 and xnack
+  std::string MAttrString = "-mattr=";
+  for(auto OneFeature : Features) {
+MAttrString.append(Args.MakeArgString(OneFeature));
+if (OneFeature != Features.back())
+  MAttrString.append(",");
+  }
+  LlcArgs.push_back(Args.MakeArgString(MAttrString));
+
+  // Add output filename
+  LlcArgs.push_back("-o");
   std::string LlcOutputFileName =
   C.getDriver().GetTemporaryPath(OutputFilePrefix, "o");
   const char *LlcOutputFile =


Index: test/Driver/hip-toolchain-features.hip
===
--- /dev/null
+++ test/Driver/hip-toolchain-features.hip
@@ -0,0 +1,48 @@
+// REQUIRES: clang-driver
+// REQUIRES: x86-registered-target
+// REQUIRES: amdgpu-registered-target
+
+// RUN: %clang -### -c -target x86_64-linux-gnu -fgpu-rdc \
+// RUN:   -x hip --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN:   -mcode-object-v3 2>&1 | FileCheck %s -check-prefix=COV3
+// RUN: %clang -### -c -target x86_64-linux-gnu -fgpu-rdc \
+// RUN:   -x hip --cuda-gpu-arch=gfx803 --cuda-gpu-arch=gfx900 %s \
+// RUN:   -mno-code-object-v3 2>&1 | FileCheck %s -check-prefix=NOCOV3
+
+// CO

[PATCH] D54978: Move the SMT API to LLVM

2019-02-12 Thread Dominic Chen via Phabricator via cfe-commits
ddcc added a comment.

In D54978#1395268 , @brzycki wrote:

> I think I found why others are struggling to recreate this issue. I did not 
> have the package `z3/bionic` installed. This provides the `/usr/bin/z3` 
> executable which `llvm/cmake/modules/FindZ3.cmake` relies upon to determine 
> the correct `Z3_VERSION_STRING`.


Yeah, that's what I meant by best-effort only. Due to upstream Z3's design, 
without the binary, there is no easy way to retrieve the current installed 
version, so when I originally wrote the Z3 integration, it seemed fine to let 
the version check pass. Given the issues that have come up, it might make more 
sense to at least emit a warning, or explicitly fail if the version can't be 
determined, and prompt the user to install the binary.


Repository:
  rC Clang

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

https://reviews.llvm.org/D54978



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


[PATCH] D57977: [HIP] compile option code-object-v3 propagate to llc

2019-02-12 Thread Konstantin Zhuravlyov via Phabricator via cfe-commits
kzhuravl added a comment.

Is it still code object v2 by default?


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

https://reviews.llvm.org/D57977



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


[PATCH] D57977: [HIP] compile option code-object-v3 propagate to llc

2019-02-12 Thread Aaron Enye Shi via Phabricator via cfe-commits
ashi1 added a comment.

Yes, but it will need this PR: 
https://github.com/ROCm-Developer-Tools/HIP/pull/910
So that the default is set.


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

https://reviews.llvm.org/D57977



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


[PATCH] D57977: [HIP] compile option code-object-v3 propagate to llc

2019-02-12 Thread Konstantin Zhuravlyov via Phabricator via cfe-commits
kzhuravl accepted this revision.
kzhuravl added a comment.
This revision is now accepted and ready to land.

LGTM. Please make sure to update your commit message as your patch processes 
all m options now.


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

https://reviews.llvm.org/D57977



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


r353877 - Disable PIC/PIE for MSP430 target

2019-02-12 Thread Anton Korobeynikov via cfe-commits
Author: asl
Date: Tue Feb 12 12:46:00 2019
New Revision: 353877

URL: http://llvm.org/viewvc/llvm-project?rev=353877&view=rev
Log:
Disable PIC/PIE for MSP430 target

Relocatable code generation is meaningless on MSP430, as the platform is too 
small to use shared libraries.

Patch by Dmitry Mikushev!

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

Added:
cfe/trunk/test/CodeGen/msp430-reloc.c
Modified:
cfe/trunk/lib/Driver/ToolChains/MSP430.h

Modified: cfe/trunk/lib/Driver/ToolChains/MSP430.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/MSP430.h?rev=353877&r1=353876&r2=353877&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/MSP430.h (original)
+++ cfe/trunk/lib/Driver/ToolChains/MSP430.h Tue Feb 12 12:46:00 2019
@@ -36,6 +36,10 @@ public:
  llvm::opt::ArgStringList &CC1Args,
  Action::OffloadKind) const override;
 
+  bool isPICDefault() const override { return false; }
+  bool isPIEDefault() const override { return false; }
+  bool isPICDefaultForced() const override { return true; }
+
 protected:
   Tool *buildLinker() const override;
 

Added: cfe/trunk/test/CodeGen/msp430-reloc.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/msp430-reloc.c?rev=353877&view=auto
==
--- cfe/trunk/test/CodeGen/msp430-reloc.c (added)
+++ cfe/trunk/test/CodeGen/msp430-reloc.c Tue Feb 12 12:46:00 2019
@@ -0,0 +1,30 @@
+// REQUIRES: msp430-registered-target
+// RUN: %clang -target msp430 -fPIC -S %s -o - | FileCheck %s
+
+// Check the compilation does not crash as it was crashing before with "-fPIC" 
enabled
+
+void *alloca(unsigned int size);
+
+// CHECK: .globl foo
+short foo(char** data, char encoding)
+{
+   char* encoding_addr = alloca(sizeof(char));
+   *encoding_addr = encoding;
+
+   char tmp3 = *encoding_addr;
+   short conv2 = tmp3;
+   short and = conv2 & 0xf;
+
+   switch (and)
+   {
+   case 0 :
+   case 4 :
+   case 10 :
+   return 1;
+   case 11 :
+   return 2;
+   }
+
+   return 0;
+}
+


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


[PATCH] D56927: Disable PIC/PIE for MSP430 target

2019-02-12 Thread Anton Korobeynikov via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rL353877: Disable PIC/PIE for MSP430 target (authored by asl, 
committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Repository:
  rL LLVM

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

https://reviews.llvm.org/D56927

Files:
  cfe/trunk/lib/Driver/ToolChains/MSP430.h
  cfe/trunk/test/CodeGen/msp430-reloc.c


Index: cfe/trunk/test/CodeGen/msp430-reloc.c
===
--- cfe/trunk/test/CodeGen/msp430-reloc.c
+++ cfe/trunk/test/CodeGen/msp430-reloc.c
@@ -0,0 +1,30 @@
+// REQUIRES: msp430-registered-target
+// RUN: %clang -target msp430 -fPIC -S %s -o - | FileCheck %s
+
+// Check the compilation does not crash as it was crashing before with "-fPIC" 
enabled
+
+void *alloca(unsigned int size);
+
+// CHECK: .globl foo
+short foo(char** data, char encoding)
+{
+   char* encoding_addr = alloca(sizeof(char));
+   *encoding_addr = encoding;
+
+   char tmp3 = *encoding_addr;
+   short conv2 = tmp3;
+   short and = conv2 & 0xf;
+
+   switch (and)
+   {
+   case 0 :
+   case 4 :
+   case 10 :
+   return 1;
+   case 11 :
+   return 2;
+   }
+
+   return 0;
+}
+
Index: cfe/trunk/lib/Driver/ToolChains/MSP430.h
===
--- cfe/trunk/lib/Driver/ToolChains/MSP430.h
+++ cfe/trunk/lib/Driver/ToolChains/MSP430.h
@@ -36,6 +36,10 @@
  llvm::opt::ArgStringList &CC1Args,
  Action::OffloadKind) const override;
 
+  bool isPICDefault() const override { return false; }
+  bool isPIEDefault() const override { return false; }
+  bool isPICDefaultForced() const override { return true; }
+
 protected:
   Tool *buildLinker() const override;
 


Index: cfe/trunk/test/CodeGen/msp430-reloc.c
===
--- cfe/trunk/test/CodeGen/msp430-reloc.c
+++ cfe/trunk/test/CodeGen/msp430-reloc.c
@@ -0,0 +1,30 @@
+// REQUIRES: msp430-registered-target
+// RUN: %clang -target msp430 -fPIC -S %s -o - | FileCheck %s
+
+// Check the compilation does not crash as it was crashing before with "-fPIC" enabled
+
+void *alloca(unsigned int size);
+
+// CHECK: .globl foo
+short foo(char** data, char encoding)
+{
+	char* encoding_addr = alloca(sizeof(char));
+	*encoding_addr = encoding;
+
+	char tmp3 = *encoding_addr;
+	short conv2 = tmp3;
+	short and = conv2 & 0xf;
+
+	switch (and)
+	{
+	case 0 :
+	case 4 :
+	case 10 :
+		return 1;
+	case 11 :
+		return 2;
+	}
+
+	return 0;
+}
+
Index: cfe/trunk/lib/Driver/ToolChains/MSP430.h
===
--- cfe/trunk/lib/Driver/ToolChains/MSP430.h
+++ cfe/trunk/lib/Driver/ToolChains/MSP430.h
@@ -36,6 +36,10 @@
  llvm::opt::ArgStringList &CC1Args,
  Action::OffloadKind) const override;
 
+  bool isPICDefault() const override { return false; }
+  bool isPIEDefault() const override { return false; }
+  bool isPICDefaultForced() const override { return true; }
+
 protected:
   Tool *buildLinker() const override;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D58072: Make ModuleDependencyCollector's method virtual (NFC)

2019-02-12 Thread Jonas Devlieghere via Phabricator via cfe-commits
JDevlieghere added a comment.

Alright, I'll split this up in two patches


Repository:
  rC Clang

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

https://reviews.llvm.org/D58072



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


r353878 - [X86] Use __m128_u for _mm_loadu_ps after r353555

2019-02-12 Thread Reid Kleckner via cfe-commits
Author: rnk
Date: Tue Feb 12 13:04:21 2019
New Revision: 353878

URL: http://llvm.org/viewvc/llvm-project?rev=353878&view=rev
Log:
[X86] Use __m128_u for _mm_loadu_ps after r353555

Add secondary triple to existing SSE test for it.  I audited other uses
of __attribute__((__packed__)) in the intrinsic headers, and this seemed
to be the only missing one.

Modified:
cfe/trunk/lib/Headers/xmmintrin.h
cfe/trunk/test/CodeGen/sse-builtins.c

Modified: cfe/trunk/lib/Headers/xmmintrin.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/xmmintrin.h?rev=353878&r1=353877&r2=353878&view=diff
==
--- cfe/trunk/lib/Headers/xmmintrin.h (original)
+++ cfe/trunk/lib/Headers/xmmintrin.h Tue Feb 12 13:04:21 2019
@@ -1754,7 +1754,7 @@ static __inline__ __m128 __DEFAULT_FN_AT
 _mm_loadu_ps(const float *__p)
 {
   struct __loadu_ps {
-__m128 __v;
+__m128_u __v;
   } __attribute__((__packed__, __may_alias__));
   return ((struct __loadu_ps*)__p)->__v;
 }

Modified: cfe/trunk/test/CodeGen/sse-builtins.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/sse-builtins.c?rev=353878&r1=353877&r2=353878&view=diff
==
--- cfe/trunk/test/CodeGen/sse-builtins.c (original)
+++ cfe/trunk/test/CodeGen/sse-builtins.c Tue Feb 12 13:04:21 2019
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -ffreestanding %s -triple=x86_64-apple-darwin 
-target-feature +sse -emit-llvm -o - -Wall -Werror | FileCheck %s
+// RUN: %clang_cc1 -fms-extensions -fms-compatibility -ffreestanding %s 
-triple=x86_64-windows-msvc -target-feature +sse -emit-llvm -o - -Wall -Werror 
| FileCheck %s
 
 
 #include 


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


  1   2   >