Re: r338899 - [OpenCL] Always emit alloca in entry block for enqueue_kernel builtin

[via cfe-commits]

I can't seem to reproduce the ASan failure locally, even after building 
a clang with the latest compiler-rt, and then rebuilding my patch with 
LLVM_USE_SANITIZER=Address


I am pretty confident the problem should be fixed with a one-line change 
to my patch:


-auto CreateArrayForSizeVar = [=](unsigned First) {
+auto CreateArrayForSizeVar = [=](unsigned First)
+-> std::tuple {

I don't want to commit something and then immediately have to revert, 
though. Can you think of anything I might be missing locally to 
reproduce the ASan failure?


Thanks,
Scott

On 2018-08-03 13:48, Vlad Tsyrklevich wrote:

This change is causing ASan failures on the sanitizer bots:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/21898/steps/check-clang%20asan/logs/stdio
[9]

I've reverted it in r338904.

On Fri, Aug 3, 2018 at 8:51 AM Scott Linder via cfe-commits
 wrote:


Author: scott.linder
Date: Fri Aug 3 08:50:52 2018
New Revision: 338899

URL: http://llvm.org/viewvc/llvm-project?rev=338899&view=rev [1]
Log:
[OpenCL] Always emit alloca in entry block for enqueue_kernel
builtin

Ensures the statically sized alloca is not converted to
DYNAMIC_STACKALLOC
later because it is not in the entry block.

Differential Revision: https://reviews.llvm.org/D50104 [2]

Added:
cfe/trunk/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl
[3]
Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/test/CodeGenOpenCL/cl20-device-side-enqueue.cl [4]

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL:


http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=338899&r1=338898&r2=338899&view=diff

[5]


==

--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Fri Aug 3 08:50:52 2018
@@ -3338,23 +3338,29 @@ RValue CodeGenFunction::EmitBuiltinExpr(
// Create a temporary array to hold the sizes of local pointer
arguments
// for the block. \p First is the position of the first size
argument.
auto CreateArrayForSizeVar = [=](unsigned First) {
- auto *AT = llvm::ArrayType::get(SizeTy, NumArgs - First);
- auto *Arr = Builder.CreateAlloca(AT);
- llvm::Value *Ptr;
+ llvm::APInt ArraySize(32, NumArgs - First);
+ QualType SizeArrayTy = getContext().getConstantArrayType(
+ getContext().getSizeType(), ArraySize, ArrayType::Normal,
+ /*IndexTypeQuals=*/0);
+ auto Tmp = CreateMemTemp(SizeArrayTy, "block_sizes");
+ llvm::Value *TmpPtr = Tmp.getPointer();
+ llvm::Value *TmpSize = EmitLifetimeStart(
+
CGM.getDataLayout().getTypeAllocSize(Tmp.getElementType()), TmpPtr);
+ llvm::Value *ElemPtr;
// Each of the following arguments specifies the size of the
corresponding
// argument passed to the enqueued block.
auto *Zero = llvm::ConstantInt::get(IntTy, 0);
for (unsigned I = First; I < NumArgs; ++I) {
auto *Index = llvm::ConstantInt::get(IntTy, I - First);
- auto *GEP = Builder.CreateGEP(Arr, {Zero, Index});
+ auto *GEP = Builder.CreateGEP(TmpPtr, {Zero, Index});
if (I == First)
- Ptr = GEP;
+ ElemPtr = GEP;
auto *V =
Builder.CreateZExtOrTrunc(EmitScalarExpr(E->getArg(I)),
SizeTy);
Builder.CreateAlignedStore(
V, GEP,
CGM.getDataLayout().getPrefTypeAlignment(SizeTy));
}
- return Ptr;
+ return std::tie(ElemPtr, TmpSize, TmpPtr);
};

// Could have events and/or varargs.
@@ -3366,24 +3372,27 @@ RValue CodeGenFunction::EmitBuiltinExpr(
llvm::Value *Kernel =
Builder.CreatePointerCast(Info.Kernel, GenericVoidPtrTy);
auto *Block = Builder.CreatePointerCast(Info.BlockArg,
GenericVoidPtrTy);
- auto *PtrToSizeArray = CreateArrayForSizeVar(4);
+ llvm::Value *ElemPtr, *TmpSize, *TmpPtr;
+ std::tie(ElemPtr, TmpSize, TmpPtr) =
CreateArrayForSizeVar(4);

// Create a vector of the arguments, as well as a constant
value to
// express to the runtime the number of variadic arguments.
std::vector Args = {
Queue, Flags, Range,
Kernel, Block, ConstantInt::get(IntTy, NumArgs - 4),
- PtrToSizeArray};
+ ElemPtr};
std::vector ArgTys = {
- QueueTy, IntTy, RangeTy,
- GenericVoidPtrTy, GenericVoidPtrTy, IntTy,
- PtrToSizeArray->getType()};
+ QueueTy, IntTy, RangeTy,
GenericVoidPtrTy,
+ GenericVoidPtrTy, IntTy, ElemPtr->getType()};

llvm::FunctionType *FTy = llvm::FunctionType::get(
Int32Ty, llvm::ArrayRef(ArgTys), false);
- return RValue::get(
- Builder.CreateCall(CGM.CreateRuntimeFunction(FTy, Name),
- llvm::ArrayRef(Args)));
+ auto Call =
+
RValue::get(Builder.CreateCall(CGM.CreateRuntimeFunction(FTy, Name),
+ llvm::ArrayRef(Args)));
+ if (TmpSize)
+ EmitLifetimeEnd(TmpSize, TmpPtr);
+ return Call;
}
// Any calls now have event arguments passed.
if (NumArgs >= 7) {
@@ -3430,15 +3439,19 @@ RValue CodeGenFunction::EmitBuiltinExpr(
ArgTys.push_back(Int32Ty);
Name = "__enqueue_kernel_events_varargs";

- auto *PtrToSizeArray = CreateArrayForSizeVar(7);
- Args.push_back(PtrToSizeArray);
- ArgTys.push_back(PtrToSizeArray->getType());
+ llvm

Re: r338899 - [OpenCL] Always emit alloca in entry block for enqueue_kernel builtin

[via cfe-commits]

That's what I was missing; I should have looked more closely at the 
buildbot logs, I see the export there now.


Thanks!
Scott

On 2018-08-06 12:51, Vlad Tsyrklevich wrote:

Have you tried setting detect_stack_use_after_return in ASAN_OPTIONS?
The ASan buildbot sets the following ASAN_OPTIONS prior to running
tests:
export
ASAN_OPTIONS="check_initialization_order=true:detect_stack_use_after_return=1:detect_leaks=1"

On Mon, Aug 6, 2018 at 7:34 AM  wrote:


I can't seem to reproduce the ASan failure locally, even after
building
a clang with the latest compiler-rt, and then rebuilding my patch
with
LLVM_USE_SANITIZER=Address

I am pretty confident the problem should be fixed with a one-line
change
to my patch:

- auto CreateArrayForSizeVar = [=](unsigned First) {
+ auto CreateArrayForSizeVar = [=](unsigned First)
+ -> std::tuple
{

I don't want to commit something and then immediately have to
revert,
though. Can you think of anything I might be missing locally to
reproduce the ASan failure?

Thanks,
Scott

On 2018-08-03 13:48, Vlad Tsyrklevich wrote:

This change is causing ASan failures on the sanitizer bots:




http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/21898/steps/check-clang%20asan/logs/stdio

[1]

[9]

I've reverted it in r338904.

On Fri, Aug 3, 2018 at 8:51 AM Scott Linder via cfe-commits
 wrote:


Author: scott.linder
Date: Fri Aug 3 08:50:52 2018
New Revision: 338899

URL: http://llvm.org/viewvc/llvm-project?rev=338899&view=rev [2]

[1]

Log:
[OpenCL] Always emit alloca in entry block for enqueue_kernel
builtin

Ensures the statically sized alloca is not converted to
DYNAMIC_STACKALLOC
later because it is not in the entry block.

Differential Revision: https://reviews.llvm.org/D50104 [3] [2]

Added:
cfe/trunk/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl

[4]

[3]
Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/test/CodeGenOpenCL/cl20-device-side-enqueue.cl [5] [4]

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL:






http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=338899&r1=338898&r2=338899&view=diff

[6]

[5]






==

--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Fri Aug 3 08:50:52 2018
@@ -3338,23 +3338,29 @@ RValue CodeGenFunction::EmitBuiltinExpr(
// Create a temporary array to hold the sizes of local pointer
arguments
// for the block. \p First is the position of the first size
argument.
auto CreateArrayForSizeVar = [=](unsigned First) {
- auto *AT = llvm::ArrayType::get(SizeTy, NumArgs - First);
- auto *Arr = Builder.CreateAlloca(AT);
- llvm::Value *Ptr;
+ llvm::APInt ArraySize(32, NumArgs - First);
+ QualType SizeArrayTy = getContext().getConstantArrayType(
+ getContext().getSizeType(), ArraySize, ArrayType::Normal,
+ /*IndexTypeQuals=*/0);
+ auto Tmp = CreateMemTemp(SizeArrayTy, "block_sizes");
+ llvm::Value *TmpPtr = Tmp.getPointer();
+ llvm::Value *TmpSize = EmitLifetimeStart(
+
CGM.getDataLayout().getTypeAllocSize(Tmp.getElementType()),

TmpPtr);

+ llvm::Value *ElemPtr;
// Each of the following arguments specifies the size of the
corresponding
// argument passed to the enqueued block.
auto *Zero = llvm::ConstantInt::get(IntTy, 0);
for (unsigned I = First; I < NumArgs; ++I) {
auto *Index = llvm::ConstantInt::get(IntTy, I - First);
- auto *GEP = Builder.CreateGEP(Arr, {Zero, Index});
+ auto *GEP = Builder.CreateGEP(TmpPtr, {Zero, Index});
if (I == First)
- Ptr = GEP;
+ ElemPtr = GEP;
auto *V =
Builder.CreateZExtOrTrunc(EmitScalarExpr(E->getArg(I)),
SizeTy);
Builder.CreateAlignedStore(
V, GEP,
CGM.getDataLayout().getPrefTypeAlignment(SizeTy));
}
- return Ptr;
+ return std::tie(ElemPtr, TmpSize, TmpPtr);
};

// Could have events and/or varargs.
@@ -3366,24 +3372,27 @@ RValue CodeGenFunction::EmitBuiltinExpr(
llvm::Value *Kernel =
Builder.CreatePointerCast(Info.Kernel, GenericVoidPtrTy);
auto *Block = Builder.CreatePointerCast(Info.BlockArg,
GenericVoidPtrTy);
- auto *PtrToSizeArray = CreateArrayForSizeVar(4);
+ llvm::Value *ElemPtr, *TmpSize, *TmpPtr;
+ std::tie(ElemPtr, TmpSize, TmpPtr) =
CreateArrayForSizeVar(4);

// Create a vector of the arguments, as well as a constant
value to
// express to the runtime the number of variadic arguments.
std::vector Args = {
Queue, Flags, Range,
Kernel, Block, ConstantInt::get(IntTy, NumArgs - 4),
- PtrToSizeArray};
+ ElemPtr};
std::vector ArgTys = {
- QueueTy, IntTy, RangeTy,
- GenericVoidPtrTy, GenericVoidPtrTy, IntTy,
- PtrToSizeArray->getType()};
+ QueueTy, IntTy, RangeTy,
GenericVoidPtrTy,
+ GenericVoidPtrTy, IntTy, ElemPtr->getType()};

llvm::FunctionType *FTy = llvm::FunctionType::get(
Int32Ty, llvm::ArrayRef(ArgTys), false);
- return RValue::get(
- Builder.CreateCall(CGM.CreateRuntimeFunction(FTy, Name),
- llvm::ArrayRef(Args)));
+ auto Call =
+
RValue::get(Builder.CreateCall

RE: r339185 - Make test more robust by not checking hard coded debug info values, but instead check the relationships between them.

[via cfe-commits]

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of
> Douglas Yung via cfe-commits
> Sent: Tuesday, August 07, 2018 5:23 PM
> To: cfe-commits@lists.llvm.org
> Subject: r339185 - Make test more robust by not checking hard coded debug
> info values, but instead check the relationships between them.
> 
> Author: dyung
> Date: Tue Aug  7 14:22:49 2018
> New Revision: 339185
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=339185&view=rev
> Log:
> Make test more robust by not checking hard coded debug info values, but
> instead check the relationships between them.
> 
> Modified:
> cfe/trunk/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl
> 
> Modified: cfe/trunk/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/test/CodeGenOpenCL/enqueue-kernel-non-entry-
> block.cl?rev=339185&r1=339184&r2=339185&view=diff
> ==
> 
> --- cfe/trunk/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl
> (original)
> +++ cfe/trunk/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl Tue Aug
> 7 14:22:49 2018
> @@ -16,7 +16,7 @@ kernel void test(int i) {
>  // SPIR64: %block_sizes = alloca [1 x i64]
>  // COMMON-LABEL: if.then:
>  // COMMON-NOT: alloca
> -// CHECK-DEBUG: getelementptr {{.*}} %block_sizes, {{.*}} !dbg !34
> +// CHECK-DEBUG: getelementptr {{.*}} %block_sizes, {{.*}} !dbg
> ![[TEMPLOCATION:[0-9]+]]
>  // COMMON-LABEL: if.end
>queue_t default_queue;
>unsigned flags = 0;
> @@ -27,5 +27,7 @@ kernel void test(int i) {
> 
>  // Check that the temporary is scoped to the `if`
> 
> -// CHECK-DEBUG: !32 = distinct !DILexicalBlock(scope: !7, file: !1, line:
> 24)
> -// CHECK-DEBUG: !34 = !DILocation(line: 25, scope: !32)
> +// CHECK-DEBUG: ![[TESTFILE:[0-9]+]] = !DIFile(filename: ""
> +// CHECK-DEBUG: ![[TESTSCOPE:[0-9]+]] = distinct !DISubprogram(name:
> "test", {{.*}} file: ![[TESTFILE]]
> +// CHECK-DEBUG: ![[IFSCOPE:[0-9]+]] = distinct !DILexicalBlock(scope:
> ![[TESTSCOPE]], file: !1, line: 24)

You missed a hard-coded !1 here, should be [[TESTFILE]].

> +// CHECK-DEBUG: ![[TEMPLOCATION]] = !DILocation(line: 25, scope:
> ![[IFSCOPE]])
> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: r339307 - [CMake] Use normalized Windows target triples

[via cfe-commits]

Hi Petr,
Various Windows bots have been failing with ~270 test failures, and this
commit seems like the most probable culprit.  For example:
http://lab.llvm.org:8011/builders/clang-x86-ninja-win7/builds/12460

Could you please investigate?
Thanks,
--paulr

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of
> Petr Hosek via cfe-commits
> Sent: Wednesday, August 08, 2018 10:16 PM
> To: cfe-commits@lists.llvm.org
> Subject: r339307 - [CMake] Use normalized Windows target triples
> 
> Author: phosek
> Date: Wed Aug  8 19:16:18 2018
> New Revision: 339307
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=339307&view=rev
> Log:
> [CMake] Use normalized Windows target triples
> 
> Changes the default Windows target triple returned by
> GetHostTriple.cmake from the old environment names (which we wanted to
> move away from) to newer, normalized ones. This also requires updating
> all tests to use the new systems names in constraints.
> 
> Differential Revision: https://reviews.llvm.org/D47381
> 
> Modified:
> cfe/trunk/test/CodeGen/2007-06-18-SextAttrAggregate.c
> cfe/trunk/test/CodeGenCXX/vtable-debug-info.cpp
> cfe/trunk/test/Driver/coverage_no_integrated_as.c
> cfe/trunk/test/Driver/crash-report-null.test
> cfe/trunk/test/Driver/inhibit-downstream-commands.c
> cfe/trunk/test/Driver/linker-opts.c
> cfe/trunk/test/Driver/no-integrated-as.s
> cfe/trunk/test/Lexer/cross-windows-on-linux.cpp
> cfe/trunk/test/Modules/crash-vfs-path-emptydir-entries.m
> cfe/trunk/test/Modules/crash-vfs-path-symlink-component.m
> cfe/trunk/test/Modules/crash-vfs-path-symlink-topheader.m
> cfe/trunk/test/Modules/crash-vfs-path-traversal.m
> cfe/trunk/test/Modules/crash-vfs-relative-overlay.m
> cfe/trunk/test/Modules/crash-vfs-umbrella-frameworks.m
> cfe/trunk/test/SemaTemplate/instantiation-depth-default.cpp
> cfe/trunk/test/VFS/umbrella-framework-import-skipnonexist.m
> cfe/trunk/test/lit.cfg.py
> 
> Modified: cfe/trunk/test/CodeGen/2007-06-18-SextAttrAggregate.c
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/2007-06-
> 18-SextAttrAggregate.c?rev=339307&r1=339306&r2=339307&view=diff
> ==
> 
> --- cfe/trunk/test/CodeGen/2007-06-18-SextAttrAggregate.c (original)
> +++ cfe/trunk/test/CodeGen/2007-06-18-SextAttrAggregate.c Wed Aug  8
> 19:16:18 2018
> @@ -1,5 +1,5 @@
>  // RUN: %clang_cc1 %s -o - -emit-llvm | FileCheck %s
> -// XFAIL: aarch64, arm64, x86_64-pc-win32, x86_64-w64-mingw32, x86_64-pc-
> windows-gnu
> +// XFAIL: aarch64, arm64, x86_64-pc-windows-msvc, x86_64-w64-windows-gnu,
> x86_64-pc-windows-gnu
> 
>  // PR1513
> 
> 
> Modified: cfe/trunk/test/CodeGenCXX/vtable-debug-info.cpp
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/vtable-
> debug-info.cpp?rev=339307&r1=339306&r2=339307&view=diff
> ==
> 
> --- cfe/trunk/test/CodeGenCXX/vtable-debug-info.cpp (original)
> +++ cfe/trunk/test/CodeGenCXX/vtable-debug-info.cpp Wed Aug  8 19:16:18
> 2018
> @@ -1,6 +1,6 @@
>  // RUN: %clang -emit-llvm -S -g %s -o /dev/null
>  // Radar 8730409
> -// XFAIL: win32
> +// XFAIL: windows-msvc
> 
>  // FIXME: This test crashes on *-pc-win32
>  // for lack of debugging support on -integrated-as (MCCOFF).
> 
> Modified: cfe/trunk/test/Driver/coverage_no_integrated_as.c
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/test/Driver/coverage_no_integrated_as.c?rev=339307&r1=33
> 9306&r2=339307&view=diff
> ==
> 
> --- cfe/trunk/test/Driver/coverage_no_integrated_as.c (original)
> +++ cfe/trunk/test/Driver/coverage_no_integrated_as.c Wed Aug  8 19:16:18
> 2018
> @@ -1,5 +1,5 @@
>  // REQUIRES: clang-driver
> -// XFAIL: win32,win64
> +// XFAIL: windows-msvc
> 
>  // RUN: %clang -### -S -fprofile-arcs %s 2>&1 | FileCheck -check-
> prefix=CHECK-GCNO-DEFAULT-LOCATION %s
>  // RUN: %clang -### -S -fprofile-arcs -no-integrated-as %s 2>&1 |
> FileCheck -check-prefix=CHECK-GCNO-DEFAULT-LOCATION %s
> 
> Modified: cfe/trunk/test/Driver/crash-report-null.test
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/crash-
> report-null.test?rev=339307&r1=339306&r2=339307&view=diff
> ==
> 
> --- cfe/trunk/test/Driver/crash-report-null.test (original)
> +++ cfe/trunk/test/Driver/crash-report-null.test Wed Aug  8 19:16:18 2018
>

RE: r333311 - [DebugInfo] Don't bother with MD5 checksums of preprocessed files.

[via cfe-commits]

Reverted in r19 because I got failure notices from
http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/17262
and (for stage 1, but not stage 2, which is pretty weird)
http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/10824

The Bots Know when I'm about to go out of town... I'll have to
revisit this later.
--paulr

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of
> Paul Robinson via cfe-commits
> Sent: Friday, May 25, 2018 4:59 PM
> To: cfe-commits@lists.llvm.org
> Subject: r11 - [DebugInfo] Don't bother with MD5 checksums of
> preprocessed files.
> 
> Author: probinson
> Date: Fri May 25 13:59:29 2018
> New Revision: 11
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=11&view=rev
> Log:
> [DebugInfo] Don't bother with MD5 checksums of preprocessed files.
> 
> The checksum will not reflect the real source, so there's no clear
> reason to include them in the debug info.  Also this was causing a
> crash on the DWARF side.
> 
> Differential Revision: https://reviews.llvm.org/D47260
> 
> Added:
> cfe/trunk/test/CodeGen/md5-checksum-crash.c
> Modified:
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> cfe/trunk/lib/CodeGen/CGDebugInfo.h
> 
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=11&r1=10&r2=
> 11&view=diff
> ==
> 
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri May 25 13:59:29 2018
> @@ -67,6 +67,8 @@ CGDebugInfo::CGDebugInfo(CodeGenModule &
>DBuilder(CGM.getModule()) {
>for (const auto &KV : CGM.getCodeGenOpts().DebugPrefixMap)
>  DebugPrefixMap[KV.first] = KV.second;
> +  EmitFileChecksums = CGM.getCodeGenOpts().EmitCodeView ||
> +  CGM.getCodeGenOpts().DwarfVersion >= 5;
>CreateCompileUnit();
>  }
> 
> @@ -365,15 +367,21 @@ Optional
>  CGDebugInfo::computeChecksum(FileID FID, SmallString<32> &Checksum) const
> {
>Checksum.clear();
> 
> -  if (!CGM.getCodeGenOpts().EmitCodeView &&
> -  CGM.getCodeGenOpts().DwarfVersion < 5)
> +  if (!EmitFileChecksums)
>  return None;
> 
>SourceManager &SM = CGM.getContext().getSourceManager();
>bool Invalid;
> -  llvm::MemoryBuffer *MemBuffer = SM.getBuffer(FID, &Invalid);
> -  if (Invalid)
> +  const SrcMgr::SLocEntry &Entry = SM.getSLocEntry(FID, &Invalid);
> +  if (Invalid || !Entry.isFile())
>  return None;
> +  if (Entry.getFile().hasLineDirectives()) {
> +// This must be a preprocessed file; its content won't match the
> original
> +// source; therefore checksumming the text we have is pointless or
> wrong.
> +EmitFileChecksums = false;
> +return None;
> +  }
> +  llvm::MemoryBuffer *MemBuffer = SM.getBuffer(FID);
> 
>llvm::MD5 Hash;
>llvm::MD5::MD5Result Result;
> 
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.h
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/CodeGen/CGDebugInfo.h?rev=11&r1=10&r2=11
> &view=diff
> ==
> 
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.h (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.h Fri May 25 13:59:29 2018
> @@ -57,6 +57,7 @@ class CGDebugInfo {
>CodeGenModule &CGM;
>const codegenoptions::DebugInfoKind DebugKind;
>bool DebugTypeExtRefs;
> +  mutable bool EmitFileChecksums;
>llvm::DIBuilder DBuilder;
>llvm::DICompileUnit *TheCU = nullptr;
>ModuleMap *ClangModuleMap = nullptr;
> 
> Added: cfe/trunk/test/CodeGen/md5-checksum-crash.c
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/md5-
> checksum-crash.c?rev=11&view=auto
> ==
> 
> --- cfe/trunk/test/CodeGen/md5-checksum-crash.c (added)
> +++ cfe/trunk/test/CodeGen/md5-checksum-crash.c Fri May 25 13:59:29 2018
> @@ -0,0 +1,13 @@
> +// RUN: %clang_cc1 -triple %itanium_abi_triple -debug-info-kind=limited -
> dwarf-version=5 %s -emit-llvm -o- | FileCheck %s
> +// RUN: %clang_cc1 -triple %ms_abi_triple -gcodeview -debug-info-
> kind=limited %s -emit-llvm -o- | FileCheck %s
> +
> +// This had been crashing, no MD5 checksum for string.h.
> +// Now if there are #line directives, don't bother with checksums
> +// as a preprocessed file won't properly reflect the original source.
> +#def

r341309 - [OpenCL] Traverse vector types for ocl extensions support

[via cfe-commits]

Author: AlexeySotkin
Date: Mon Sep  3 04:43:22 2018
New Revision: 341309

URL: http://llvm.org/viewvc/llvm-project?rev=341309&view=rev
Log:
[OpenCL] Traverse vector types for ocl extensions support

Summary:
Given the following kernel:
__kernel void foo() {
  double d;
  double4 dd;
}

and cl_khr_fp64 is disabled, the compilation would fail due to
the presence of 'double d', but when removed, it passes.

The expectation is that extended vector types of unsupported types
will also be unsupported.

The patch adds the check for this scenario.

Patch by: Ofir Cohen

Reviewers: bader, Anastasia, AlexeySotkin, yaxunl

Reviewed By: Anastasia

Subscribers: cfe-commits

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

Modified:
cfe/trunk/lib/Sema/Sema.cpp
cfe/trunk/test/SemaOpenCL/extensions.cl

Modified: cfe/trunk/lib/Sema/Sema.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/Sema.cpp?rev=341309&r1=341308&r2=341309&view=diff
==
--- cfe/trunk/lib/Sema/Sema.cpp (original)
+++ cfe/trunk/lib/Sema/Sema.cpp Mon Sep  3 04:43:22 2018
@@ -1889,6 +1889,14 @@ bool Sema::checkOpenCLDisabledTypeDeclSp
   if (auto TagT = dyn_cast(QT.getCanonicalType().getTypePtr()))
 Decl = TagT->getDecl();
   auto Loc = DS.getTypeSpecTypeLoc();
+
+  // Check extensions for vector types.
+  // e.g. double4 is not allowed when cl_khr_fp64 is absent.
+  if (QT->isExtVectorType()) {
+auto TypePtr = QT->castAs()->getElementType().getTypePtr();
+return checkOpenCLDisabledTypeOrDecl(TypePtr, Loc, QT, OpenCLTypeExtMap);
+  }
+
   if (checkOpenCLDisabledTypeOrDecl(Decl, Loc, QT, OpenCLDeclExtMap))
 return true;
 

Modified: cfe/trunk/test/SemaOpenCL/extensions.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaOpenCL/extensions.cl?rev=341309&r1=341308&r2=341309&view=diff
==
--- cfe/trunk/test/SemaOpenCL/extensions.cl (original)
+++ cfe/trunk/test/SemaOpenCL/extensions.cl Mon Sep  3 04:43:22 2018
@@ -70,6 +70,13 @@ void f2(void) {
 // expected-error@-2{{use of type 'double' requires cl_khr_fp64 extension to 
be enabled}}
 #endif
 
+  typedef double double4 __attribute__((ext_vector_type(4)));
+  double4 d4 = {0.0f, 2.0f, 3.0f, 1.0f};
+#ifdef NOFP64
+// expected-error@-3 {{use of type 'double' requires cl_khr_fp64 extension to 
be enabled}}
+// expected-error@-3 {{use of type 'double4' (vector of 4 'double' values) 
requires cl_khr_fp64 extension to be enabled}}
+#endif
+
   (void) 1.0;
 
 #ifdef NOFP64


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

r341314 - [Index] Update tests allowing double4 type to be "invalid"

[via cfe-commits]

Author: AlexeySotkin
Date: Mon Sep  3 05:43:26 2018
New Revision: 341314

URL: http://llvm.org/viewvc/llvm-project?rev=341314&view=rev
Log:
[Index] Update tests allowing double4 type to be "invalid"

Fixes test failure after r341309

Modified:
cfe/trunk/test/Index/opencl-types.cl

Modified: cfe/trunk/test/Index/opencl-types.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/opencl-types.cl?rev=341314&r1=341313&r2=341314&view=diff
==
--- cfe/trunk/test/Index/opencl-types.cl (original)
+++ cfe/trunk/test/Index/opencl-types.cl Mon Sep  3 05:43:26 2018
@@ -21,7 +21,7 @@ void kernel testFloatTypes() {
 // CHECK: VarDecl=scalarFloat:13:9 (Definition) [type=float] [typekind=Float] 
[isPOD=1]
 // CHECK: VarDecl=vectorFloat:14:10 (Definition) [type=float4] 
[typekind=Typedef] [canonicaltype=float __attribute__((ext_vector_type(4)))] 
[canonicaltypekind=Unexposed] [isPOD=1]
 // CHECK: VarDecl=scalarDouble:15:10 (Definition){{( \(invalid\))?}} 
[type=double] [typekind=Double] [isPOD=1]
-// CHECK: VarDecl=vectorDouble:16:11 (Definition) [type=double4] 
[typekind=Typedef] [canonicaltype=double __attribute__((ext_vector_type(4)))] 
[canonicaltypekind=Unexposed] [isPOD=1]
+// CHECK: VarDecl=vectorDouble:16:11 (Definition){{( \(invalid\))?}} 
[type=double4] [typekind=Typedef] [canonicaltype=double 
__attribute__((ext_vector_type(4)))] [canonicaltypekind=Unexposed] [isPOD=1]
 
 #pragma OPENCL EXTENSION cl_khr_gl_msaa_sharing : enable
 


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

Re: r338299 - [DebugInfo][OpenCL] Generate correct block literal debug info for OpenCL

[via cfe-commits]

Sorry for the delay, this should be fixed in r338321.

Scott

On 2018-07-30 17:19, Benjamin Kramer wrote:

On Mon, Jul 30, 2018 at 10:37 PM Scott Linder via cfe-commits
 wrote:


Author: scott.linder
Date: Mon Jul 30 13:31:11 2018
New Revision: 338299

URL: http://llvm.org/viewvc/llvm-project?rev=338299&view=rev [1]
Log:
[DebugInfo][OpenCL] Generate correct block literal debug info for
OpenCL

OpenCL block literal structs have different fields which are now
correctly
identified in the debug info.

Differential Revision: https://reviews.llvm.org/D49930 [2]

Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/test/CodeGenOpenCL/blocks.cl [3]

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL:


http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=338299&r1=338298&r2=338299&view=diff

[4]


==

--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Mon Jul 30 13:31:11 2018
@@ -971,20 +971,25 @@ llvm::DIType *CGDebugInfo::CreateType(co
auto *DescTy = DBuilder.createPointerType(EltTy, Size);

FieldOffset = 0;
- FType = CGM.getContext().getPointerType(CGM.getContext().VoidTy);
- EltTys.push_back(CreateMemberType(Unit, FType, "__isa",
&FieldOffset));
- FType = CGM.getContext().IntTy;
- EltTys.push_back(CreateMemberType(Unit, FType, "__flags",
&FieldOffset));
- EltTys.push_back(CreateMemberType(Unit, FType, "__reserved",
&FieldOffset));
- FType = CGM.getContext().getPointerType(Ty->getPointeeType());
- EltTys.push_back(CreateMemberType(Unit, FType, "__FuncPtr",
&FieldOffset));
-
- FType = CGM.getContext().getPointerType(CGM.getContext().VoidTy);
- FieldSize = CGM.getContext().getTypeSize(Ty);
- FieldAlign = CGM.getContext().getTypeAlign(Ty);
- EltTys.push_back(DBuilder.createMemberType(
- Unit, "__descriptor", nullptr, LineNo, FieldSize, FieldAlign,
FieldOffset,
- llvm::DINode::FlagZero, DescTy));
+ if (CGM.getLangOpts().OpenCL) {
+ FType = CGM.getContext().IntTy;
+ EltTys.push_back(CreateMemberType(Unit, FType, "__size",
&FieldOffset));
+ EltTys.push_back(CreateMemberType(Unit, FType, "__align",
&FieldOffset));
+ } else {
+ FType =
CGM.getContext().getPointerType(CGM.getContext().VoidTy);
+ EltTys.push_back(CreateMemberType(Unit, FType, "__isa",
&FieldOffset));
+ FType = CGM.getContext().IntTy;
+ EltTys.push_back(CreateMemberType(Unit, FType, "__flags",
&FieldOffset));
+ EltTys.push_back(CreateMemberType(Unit, FType, "__reserved",
&FieldOffset));
+ FType = CGM.getContext().getPointerType(Ty->getPointeeType());
+ EltTys.push_back(CreateMemberType(Unit, FType, "__FuncPtr",
&FieldOffset));
+ FType =
CGM.getContext().getPointerType(CGM.getContext().VoidTy);
+ FieldSize = CGM.getContext().getTypeSize(Ty);
+ FieldAlign = CGM.getContext().getTypeAlign(Ty);
+ EltTys.push_back(DBuilder.createMemberType(
+ Unit, "__descriptor", nullptr, LineNo, FieldSize,
FieldAlign, FieldOffset,
+ llvm::DINode::FlagZero, DescTy));
+ }


llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp:974:7: error: variable
'FieldSize' is used uninitialized whenever 'if' condition is true
[-Werror,-Wsometimes-uninitialized]
  if (CGM.getLangOpts().OpenCL) {
  ^~~~
llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp:994:18: note:
uninitialized use occurs here
  FieldOffset += FieldSize;
 ^
llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp:974:3: note: remove the
'if' if its condition is always false
  if (CGM.getLangOpts().OpenCL) {
  ^~~
llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp:949:21: note: initialize
the variable 'FieldSize' to silence this warning
  uint64_t FieldSize, FieldOffset;
^
 = 0
1 error generated.


FieldOffset += FieldSize;
Elements = DBuilder.getOrCreateArray(EltTys);
@@ -3847,26 +3852,35 @@ void CGDebugInfo::EmitDeclareOfBlockLite
CGM.getDataLayout().getStructLayout(block.StructureType);

SmallVector fields;
- fields.push_back(createFieldType("__isa", C.VoidPtrTy, loc,
AS_public,
-
blockLayout->getElementOffsetInBits(0),
- tunit, tunit));
- fields.push_back(createFieldType("__flags", C.IntTy, loc,
AS_public,
-
blockLayout->getElementOffsetInBits(1),
- tunit, tunit));
- fields.push_back(createFieldType("__reserved", C.IntTy, loc,
AS_public,
-
blockLayout->getElementOffsetInBits(2),
- tunit, tunit));
- auto *FnTy = block.getBlockExpr()->getFunctionType();
- auto FnPtrType =
CGM.getContext().getPointerType(FnTy->desugar());
- fields.push_back(createFieldType("__FuncPtr", FnPtrType, loc,
AS_public,
-
blockLayout->getElementOffsetInBits(3),
- tunit, tunit));
- fields.push_back(createFieldType(
- "__descrip

Re: r338321 - Fix use of uninitialized variable in r338299

[via cfe-commits]

I think this version is right; the FieldOffset for OpenCL here will be 2 
* getTypeSize(IntTy). The final `FieldOffset += FieldSize` that was 
moved only applies to the non-OpenCL "__descriptor" field.


Scott

On 2018-07-30 19:22, Eric Christopher wrote:

Is 0 right for FieldOffset for OpenCL here? Seems a little odd.

-eric

On Mon, Jul 30, 2018 at 3:56 PM Scott Linder via cfe-commits
 wrote:


Author: scott.linder
Date: Mon Jul 30 15:52:07 2018
New Revision: 338321

URL: http://llvm.org/viewvc/llvm-project?rev=338321&view=rev [1]
Log:
Fix use of uninitialized variable in r338299

Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL:


http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=338321&r1=338320&r2=338321&view=diff

[2]


==

--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Mon Jul 30 15:52:07 2018
@@ -989,9 +989,9 @@ llvm::DIType *CGDebugInfo::CreateType(co
EltTys.push_back(DBuilder.createMemberType(
Unit, "__descriptor", nullptr, LineNo, FieldSize,
FieldAlign, FieldOffset,
llvm::DINode::FlagZero, DescTy));
+ FieldOffset += FieldSize;
}

- FieldOffset += FieldSize;
Elements = DBuilder.getOrCreateArray(EltTys);

// The __block_literal_generic structs are marked with a special

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits [3]



Links:
--
[1] http://llvm.org/viewvc/llvm-project?rev=338321&view=rev
[2]
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=338321&r1=338320&r2=338321&view=diff
[3] http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

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

r338427 - [OpenCL] Check for invalid kernel arguments in array types

[via cfe-commits]

Author: AlexeySotkin
Date: Tue Jul 31 12:47:19 2018
New Revision: 338427

URL: http://llvm.org/viewvc/llvm-project?rev=338427&view=rev
Log:
[OpenCL] Check for invalid kernel arguments in array types

Summary:
OpenCL specification forbids use of several types as kernel arguments.
This patch improves existing diagnostic to look through arrays.

Patch by: Andrew Savonichev

Reviewers: Anastasia, yaxunl

Subscribers: yaxunl, Anastasia, cfe-commits

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

Modified:
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/test/SemaOpenCL/invalid-kernel-parameters.cl

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=338427&r1=338426&r2=338427&view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Tue Jul 31 12:47:19 2018
@@ -8079,6 +8079,15 @@ static OpenCLParamType getOpenCLKernelPa
   if (PT->isRecordType())
 return RecordKernelParam;
 
+  // Look into an array argument to check if it has a forbidden type.
+  if (PT->isArrayType()) {
+const Type *UnderlyingTy = PT->getPointeeOrArrayElementType();
+// Call ourself to check an underlying type of an array. Since the
+// getPointeeOrArrayElementType returns an innermost type which is not an
+// array, this recusive call only happens once.
+return getOpenCLKernelParameterType(S, QualType(UnderlyingTy, 0));
+  }
+
   return ValidKernelParam;
 }
 
@@ -8146,9 +8155,14 @@ static void checkIsValidOpenCLKernelPara
   SmallVector HistoryStack;
   HistoryStack.push_back(nullptr);
 
-  const RecordDecl *PD = PT->castAs()->getDecl();
-  VisitStack.push_back(PD);
+  // At this point we already handled everything except of a RecordType or
+  // an ArrayType of a RecordType.
+  assert((PT->isArrayType() || PT->isRecordType()) && "Unexpected type.");
+  const RecordType *RecTy =
+  PT->getPointeeOrArrayElementType()->getAs();
+  const RecordDecl *OrigRecDecl = RecTy->getDecl();
 
+  VisitStack.push_back(RecTy->getDecl());
   assert(VisitStack.back() && "First decl null?");
 
   do {
@@ -8167,7 +8181,15 @@ static void checkIsValidOpenCLKernelPara
 const RecordDecl *RD;
 if (const FieldDecl *Field = dyn_cast(Next)) {
   HistoryStack.push_back(Field);
-  RD = Field->getType()->castAs()->getDecl();
+
+  QualType FieldTy = Field->getType();
+  // Other field types (known to be valid or invalid) are handled while we
+  // walk around RecordDecl::fields().
+  assert((FieldTy->isArrayType() || FieldTy->isRecordType()) &&
+ "Unexpected type.");
+  const Type *FieldRecTy = FieldTy->getPointeeOrArrayElementType();
+
+  RD = FieldRecTy->castAs()->getDecl();
 } else {
   RD = cast(Next);
 }
@@ -8204,8 +8226,8 @@ static void checkIsValidOpenCLKernelPara
 S.Diag(Param->getLocation(), diag::err_bad_kernel_param_type) << PT;
   }
 
-  S.Diag(PD->getLocation(), diag::note_within_field_of_type)
-<< PD->getDeclName();
+  S.Diag(OrigRecDecl->getLocation(), diag::note_within_field_of_type)
+  << OrigRecDecl->getDeclName();
 
   // We have an error, now let's go back up through history and show where
   // the offending field came from

Modified: cfe/trunk/test/SemaOpenCL/invalid-kernel-parameters.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaOpenCL/invalid-kernel-parameters.cl?rev=338427&r1=338426&r2=338427&view=diff
==
--- cfe/trunk/test/SemaOpenCL/invalid-kernel-parameters.cl (original)
+++ cfe/trunk/test/SemaOpenCL/invalid-kernel-parameters.cl Tue Jul 31 12:47:19 
2018
@@ -136,3 +136,16 @@ struct AlsoUser // expected-note{{within
 };
 
 kernel void pointer_in_nested_struct_arg_2(struct Valid valid, struct 
NestedPointer arg, struct AlsoUser also) { } // expected-error 2 {{struct 
kernel parameters may not contain pointers}}
+
+struct ArrayOfPtr // expected-note{{within field of type 'ArrayOfPtr' declared 
here}}
+{
+  float *arr[3]; // expected-note{{field of illegal type 'float *[3]' declared 
here}}
+ // expected-note@-1{{field of illegal type 'float *[3]' 
declared here}}
+};
+kernel void array_of_ptr(struct ArrayOfPtr arr) {} // expected-error{{struct 
kernel parameters may not contain pointers}}
+
+struct ArrayOfStruct // expected-note{{within field of type 'ArrayOfStruct' 
declared here}}
+{
+  struct ArrayOfPtr arr[3]; // expected-note{{within field of type 'struct 
ArrayOfPtr [3]' declared here}}
+};
+kernel void array_of_struct(struct ArrayOfStruct arr) {} // 
expected-error{{struct kernel parameters may not contain pointers}}


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

r338432 - [OpenCL] Forbid size dependent types used as kernel arguments

[via cfe-commits]

Author: AlexeySotkin
Date: Tue Jul 31 13:26:43 2018
New Revision: 338432

URL: http://llvm.org/viewvc/llvm-project?rev=338432&view=rev
Log:
[OpenCL] Forbid size dependent types used as kernel arguments

Summary:
Size_t, intptr_t, uintptr_t and ptrdiff_t cannot be used as kernel
arguments, according to OpenCL Specification s6.9k:
The size in bytes of these types are implementation-defined and in
addition can also be different for the OpenCL device and the host
processor making it difficult to allocate buffer objects to be passed
as arguments to a kernel declared as pointer to these types.

Patch by: Andrew Savonichev

Reviewers: Anastasia, yaxunl

Subscribers: yaxunl, Anastasia, cfe-commits

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

Modified:
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/test/SemaOpenCL/invalid-kernel-parameters.cl

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=338432&r1=338431&r2=338432&view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Tue Jul 31 13:26:43 2018
@@ -8049,6 +8049,29 @@ enum OpenCLParamType {
   RecordKernelParam
 };
 
+static bool isOpenCLSizeDependentType(ASTContext &C, QualType Ty) {
+  // Size dependent types are just typedefs to normal integer types
+  // (e.g. unsigned long), so we cannot distinguish them from other typedefs to
+  // integers other than by their names.
+  StringRef SizeTypeNames[] = {"size_t", "intptr_t", "uintptr_t", "ptrdiff_t"};
+
+  // Remove typedefs one by one until we reach a typedef
+  // for a size dependent type.
+  QualType DesugaredTy = Ty;
+  do {
+ArrayRef Names(SizeTypeNames);
+auto Match =
+std::find(Names.begin(), Names.end(), DesugaredTy.getAsString());
+if (Names.end() != Match)
+  return true;
+
+Ty = DesugaredTy;
+DesugaredTy = Ty.getSingleStepDesugaredType(C);
+  } while (DesugaredTy != Ty);
+
+  return false;
+}
+
 static OpenCLParamType getOpenCLKernelParameterType(Sema &S, QualType PT) {
   if (PT->isPointerType()) {
 QualType PointeeType = PT->getPointeeType();
@@ -8061,8 +8084,13 @@ static OpenCLParamType getOpenCLKernelPa
 return PtrKernelParam;
   }
 
-  // TODO: Forbid the other integer types (size_t, ptrdiff_t...) when they can
-  // be used as builtin types.
+  // OpenCL v1.2 s6.9.k:
+  // Arguments to kernel functions in a program cannot be declared with the
+  // built-in scalar types bool, half, size_t, ptrdiff_t, intptr_t, and
+  // uintptr_t or a struct and/or union that contain fields declared to be one
+  // of these built-in scalar types.
+  if (isOpenCLSizeDependentType(S.getASTContext(), PT))
+return InvalidKernelParam;
 
   if (PT->isImageType())
 return PtrKernelParam;
@@ -8133,8 +8161,20 @@ static void checkIsValidOpenCLKernelPara
 // of event_t type.
 // Do not diagnose half type since it is diagnosed as invalid argument
 // type for any function elsewhere.
-if (!PT->isHalfType())
+if (!PT->isHalfType()) {
   S.Diag(Param->getLocation(), diag::err_bad_kernel_param_type) << PT;
+
+  // Explain what typedefs are involved.
+  const TypedefType *Typedef = nullptr;
+  while ((Typedef = PT->getAs())) {
+SourceLocation Loc = Typedef->getDecl()->getLocation();
+// SourceLocation may be invalid for a built-in type.
+if (Loc.isValid())
+  S.Diag(Loc, diag::note_entity_declared_at) << PT;
+PT = Typedef->desugar();
+  }
+}
+
 D.setInvalidType();
 return;
 

Modified: cfe/trunk/test/SemaOpenCL/invalid-kernel-parameters.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaOpenCL/invalid-kernel-parameters.cl?rev=338432&r1=338431&r2=338432&view=diff
==
--- cfe/trunk/test/SemaOpenCL/invalid-kernel-parameters.cl (original)
+++ cfe/trunk/test/SemaOpenCL/invalid-kernel-parameters.cl Tue Jul 31 13:26:43 
2018
@@ -9,7 +9,35 @@ kernel void half_arg(half x) { } // expe
 // bool, half, size_t, ptrdiff_t, intptr_t, and uintptr_t
 // or a struct / union with any of these types in them
 
-// TODO: Ban int types, size_t, ptrdiff_t ...
+typedef __SIZE_TYPE__ size_t; // expected-note{{'size_t' (aka 'unsigned int') 
declared here}}
+  // expected-note@-1{{'size_t' (aka 'unsigned 
int') declared here}}
+typedef __PTRDIFF_TYPE__ ptrdiff_t; // expected-note{{'ptrdiff_t' (aka 'int') 
declared here}}
+typedef __INTPTR_TYPE__ intptr_t; // expected-note{{'intptr_t' (aka 'int') 
declared here}}
+typedef __UINTPTR_TYPE__ uintptr_t; // expected-note{{'uintptr_t' (aka 
'unsigned int') declared here}}
+
+kernel void size_t_arg(size_t x) {} // expected-error{{'size_t' (aka 'unsigned 
int') cannot be used as the type of a kernel parameter}}
+
+kernel void ptrdiff_t_arg(ptrdiff_t x) {} // expect

Re: r338321 - Fix use of uninitialized variable in r338299

[via cfe-commits]

What might be missing is the impl of CreateMemberType:

llvm::DIType *CGDebugInfo::CreateMemberType(llvm::DIFile *Unit, QualType 
FType,
StringRef Name, uint64_t 
*Offset) {

  llvm::DIType *FieldTy = CGDebugInfo::getOrCreateType(FType, Unit);
  uint64_t FieldSize = CGM.getContext().getTypeSize(FType);
  auto FieldAlign = getTypeAlignIfRequired(FType, CGM.getContext());
  llvm::DIType *Ty =
  DBuilder.createMemberType(Unit, Name, Unit, 0, FieldSize, 
FieldAlign,
*Offset, llvm::DINode::FlagZero, 
FieldTy);

  *Offset += FieldSize;
  return Ty;
}

The FieldOffset is advanced twice in the OpenCL case, each time by
getTypeSize(IntTy). I'm not certain why CreateMemberType is not used
for __descriptor in the non-OpenCL case; it looks like it is
because it needs to handle FieldTy in a special way?

Scott

On 2018-07-31 18:03, Eric Christopher wrote:

I'm probably missing something, from looking here:

  FieldOffset = 0;
  if (CGM.getLangOpts().OpenCL) {
FType = CGM.getContext().IntTy;
EltTys.push_back(CreateMemberType(Unit, FType, "__size",
&FieldOffset));
EltTys.push_back(CreateMemberType(Unit, FType, "__align",
&FieldOffset));
  } else {
FType = CGM.getContext().getPointerType(CGM.getContext().VoidTy);
EltTys.push_back(CreateMemberType(Unit, FType, "__isa",
&FieldOffset));
FType = CGM.getContext().IntTy;
EltTys.push_back(CreateMemberType(Unit, FType, "__flags",
&FieldOffset));
EltTys.push_back(CreateMemberType(Unit, FType, "__reserved",
&FieldOffset));
FType = CGM.getContext().getPointerType(Ty->getPointeeType());
EltTys.push_back(CreateMemberType(Unit, FType, "__FuncPtr",
&FieldOffset));
FType = CGM.getContext().getPointerType(CGM.getContext().VoidTy);
FieldSize = CGM.getContext().getTypeSize(Ty);
FieldAlign = CGM.getContext().getTypeAlign(Ty);
EltTys.push_back(DBuilder.createMemberType(
Unit, "__descriptor", nullptr, LineNo, FieldSize, FieldAlign,
FieldOffset,
llvm::DINode::FlagZero, DescTy));
FieldOffset += FieldSize;
  }

FieldOffset is only advanced for non opencl blocks. And then just used
in the type.

I'll be honest none of that makes any particular sense, but in
particular these two definitely don't match for the type.

Thoughts? At any rate if you could document what the intended code is
here I'd appreciate it.

-eric

On Tue, Jul 31, 2018 at 9:18 AM  wrote:


I think this version is right; the FieldOffset for OpenCL here will
be 2
* getTypeSize(IntTy). The final `FieldOffset += FieldSize` that was
moved only applies to the non-OpenCL "__descriptor" field.

Scott

On 2018-07-30 19:22, Eric Christopher wrote:

Is 0 right for FieldOffset for OpenCL here? Seems a little odd.

-eric

On Mon, Jul 30, 2018 at 3:56 PM Scott Linder via cfe-commits
 wrote:


Author: scott.linder
Date: Mon Jul 30 15:52:07 2018
New Revision: 338321

URL: http://llvm.org/viewvc/llvm-project?rev=338321&view=rev [1]

[1]

Log:
Fix use of uninitialized variable in r338299

Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL:






http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=338321&r1=338320&r2=338321&view=diff

[2]

[2]






==

--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Mon Jul 30 15:52:07

2018

@@ -989,9 +989,9 @@ llvm::DIType *CGDebugInfo::CreateType(co
EltTys.push_back(DBuilder.createMemberType(
Unit, "__descriptor", nullptr, LineNo, FieldSize,
FieldAlign, FieldOffset,
llvm::DINode::FlagZero, DescTy));
+ FieldOffset += FieldSize;
}

- FieldOffset += FieldSize;
Elements = DBuilder.getOrCreateArray(EltTys);

// The __block_literal_generic structs are marked with a special

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits [3]

[3]



Links:
--
[1] http://llvm.org/viewvc/llvm-project?rev=338321&view=rev

[4]

[2]




http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=338321&r1=338320&r2=338321&view=diff

[5]

[3] http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits [3]



Links:
--
[1] http://llvm.org/viewvc/llvm-project?rev=338321&view=rev
[2]
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=338321&r1=338320&r2=338321&view=diff
[3] http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[4] http://llvm.org/viewvc/llvm-project?rev=338321&view=rev
[5]
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=338321&r1=338320&r2=338321&view=diff

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

Re: r338899 - [OpenCL] Always emit alloca in entry block for enqueue_kernel builtin

[via cfe-commits]

Looks like I missed that the inferred types for the returned tuple 
elements are references; I will rebuild with ASan and

confirm my fix is correct, then commit again.

Thanks,
Scott

On 2018-08-03 13:48, Vlad Tsyrklevich wrote:

This change is causing ASan failures on the sanitizer bots:
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-fast/builds/21898/steps/check-clang%20asan/logs/stdio
[9]

I've reverted it in r338904.

On Fri, Aug 3, 2018 at 8:51 AM Scott Linder via cfe-commits
 wrote:


Author: scott.linder
Date: Fri Aug 3 08:50:52 2018
New Revision: 338899

URL: http://llvm.org/viewvc/llvm-project?rev=338899&view=rev [1]
Log:
[OpenCL] Always emit alloca in entry block for enqueue_kernel
builtin

Ensures the statically sized alloca is not converted to
DYNAMIC_STACKALLOC
later because it is not in the entry block.

Differential Revision: https://reviews.llvm.org/D50104 [2]

Added:
cfe/trunk/test/CodeGenOpenCL/enqueue-kernel-non-entry-block.cl
[3]
Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/test/CodeGenOpenCL/cl20-device-side-enqueue.cl [4]

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL:


http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=338899&r1=338898&r2=338899&view=diff

[5]


==

--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Fri Aug 3 08:50:52 2018
@@ -3338,23 +3338,29 @@ RValue CodeGenFunction::EmitBuiltinExpr(
// Create a temporary array to hold the sizes of local pointer
arguments
// for the block. \p First is the position of the first size
argument.
auto CreateArrayForSizeVar = [=](unsigned First) {
- auto *AT = llvm::ArrayType::get(SizeTy, NumArgs - First);
- auto *Arr = Builder.CreateAlloca(AT);
- llvm::Value *Ptr;
+ llvm::APInt ArraySize(32, NumArgs - First);
+ QualType SizeArrayTy = getContext().getConstantArrayType(
+ getContext().getSizeType(), ArraySize, ArrayType::Normal,
+ /*IndexTypeQuals=*/0);
+ auto Tmp = CreateMemTemp(SizeArrayTy, "block_sizes");
+ llvm::Value *TmpPtr = Tmp.getPointer();
+ llvm::Value *TmpSize = EmitLifetimeStart(
+
CGM.getDataLayout().getTypeAllocSize(Tmp.getElementType()), TmpPtr);
+ llvm::Value *ElemPtr;
// Each of the following arguments specifies the size of the
corresponding
// argument passed to the enqueued block.
auto *Zero = llvm::ConstantInt::get(IntTy, 0);
for (unsigned I = First; I < NumArgs; ++I) {
auto *Index = llvm::ConstantInt::get(IntTy, I - First);
- auto *GEP = Builder.CreateGEP(Arr, {Zero, Index});
+ auto *GEP = Builder.CreateGEP(TmpPtr, {Zero, Index});
if (I == First)
- Ptr = GEP;
+ ElemPtr = GEP;
auto *V =
Builder.CreateZExtOrTrunc(EmitScalarExpr(E->getArg(I)),
SizeTy);
Builder.CreateAlignedStore(
V, GEP,
CGM.getDataLayout().getPrefTypeAlignment(SizeTy));
}
- return Ptr;
+ return std::tie(ElemPtr, TmpSize, TmpPtr);
};

// Could have events and/or varargs.
@@ -3366,24 +3372,27 @@ RValue CodeGenFunction::EmitBuiltinExpr(
llvm::Value *Kernel =
Builder.CreatePointerCast(Info.Kernel, GenericVoidPtrTy);
auto *Block = Builder.CreatePointerCast(Info.BlockArg,
GenericVoidPtrTy);
- auto *PtrToSizeArray = CreateArrayForSizeVar(4);
+ llvm::Value *ElemPtr, *TmpSize, *TmpPtr;
+ std::tie(ElemPtr, TmpSize, TmpPtr) =
CreateArrayForSizeVar(4);

// Create a vector of the arguments, as well as a constant
value to
// express to the runtime the number of variadic arguments.
std::vector Args = {
Queue, Flags, Range,
Kernel, Block, ConstantInt::get(IntTy, NumArgs - 4),
- PtrToSizeArray};
+ ElemPtr};
std::vector ArgTys = {
- QueueTy, IntTy, RangeTy,
- GenericVoidPtrTy, GenericVoidPtrTy, IntTy,
- PtrToSizeArray->getType()};
+ QueueTy, IntTy, RangeTy,
GenericVoidPtrTy,
+ GenericVoidPtrTy, IntTy, ElemPtr->getType()};

llvm::FunctionType *FTy = llvm::FunctionType::get(
Int32Ty, llvm::ArrayRef(ArgTys), false);
- return RValue::get(
- Builder.CreateCall(CGM.CreateRuntimeFunction(FTy, Name),
- llvm::ArrayRef(Args)));
+ auto Call =
+
RValue::get(Builder.CreateCall(CGM.CreateRuntimeFunction(FTy, Name),
+ llvm::ArrayRef(Args)));
+ if (TmpSize)
+ EmitLifetimeEnd(TmpSize, TmpPtr);
+ return Call;
}
// Any calls now have event arguments passed.
if (NumArgs >= 7) {
@@ -3430,15 +3439,19 @@ RValue CodeGenFunction::EmitBuiltinExpr(
ArgTys.push_back(Int32Ty);
Name = "__enqueue_kernel_events_varargs";

- auto *PtrToSizeArray = CreateArrayForSizeVar(7);
- Args.push_back(PtrToSizeArray);
- ArgTys.push_back(PtrToSizeArray->getType());
+ llvm::Value *ElemPtr, *TmpSize, *TmpPtr;
+ std::tie(ElemPtr, TmpSize, TmpPtr) =
CreateArrayForSizeVar(7);
+ Args.push_back(ElemPtr);
+ ArgTys.push_back(ElemPtr->getType());

llvm::FunctionType *FTy = llvm::FunctionType::get(
Int32Ty, llvm::ArrayRef(ArgTys), false);
- return RValue::get(
- Builder.CreateCall(CGM.CreateRuntimeFunction(FTy, Name),
- llvm::ArrayRef(Args)));
+ auto Call =
+
RValue::get(Builder.CreateCall(CGM.Cr

RE: r325175 - [Debug] Annotate compiler generated range-for loop variables.

[via cfe-commits]

From: Galina Kistanova [mailto:gkistan...@gmail.com] 
> Sent: Thursday, February 15, 2018 9:33 AM
> To: Davis, Matthew 
> Cc: cfe-commits 
> Subject: Re: r325175 - [Debug] Annotate compiler generated range-for loop 
> variables.
>
> Hello Matt,
> 
> This commit broke tests on one of our builders:
> http://lab.llvm.org:8011/builders/llvm-clang-x86_64-expensive-checks-win/builds/7920
> . . .
> Failing Tests (1):
>    Clang :: CodeGenCXX/debug-info-range-for-var-names.cpp
>
> Please have a look?
>
> Thanks
>
> Galina

Thanks Galina, I will look.
-Matt
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: r325291 - [Coroutines] Use allocator overload when available

[via cfe-commits]

Hi Brian,

Your change is causing a test failure on the clang-cmake-armv7-a15 bot in the 
test Clang::SemaCXX/coroutines.cpp.

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/15742

error: 'error' diagnostics seen but not expected: 
  File 
/home/buildslave/buildslave/clang-cmake-armv7-a15/llvm/tools/clang/test/SemaCXX/coroutines.cpp
 Line 790: 'operator new' takes type size_t ('unsigned int') as first parameter
  File 
/home/buildslave/buildslave/clang-cmake-armv7-a15/llvm/tools/clang/test/SemaCXX/coroutines.cpp
 Line 806: 'operator new' takes type size_t ('unsigned int') as first parameter
  File 
/home/buildslave/buildslave/clang-cmake-armv7-a15/llvm/tools/clang/test/SemaCXX/coroutines.cpp
 Line 816: 'operator new' takes type size_t ('unsigned int') as first parameter
  File 
/home/buildslave/buildslave/clang-cmake-armv7-a15/llvm/tools/clang/test/SemaCXX/coroutines.cpp
 Line 839: 'operator new' takes type size_t ('unsigned int') as first parameter
  File 
/home/buildslave/buildslave/clang-cmake-armv7-a15/llvm/tools/clang/test/SemaCXX/coroutines.cpp
 Line 856: 'operator new' takes type size_t ('unsigned int') as first parameter
  File 
/home/buildslave/buildslave/clang-cmake-armv7-a15/llvm/tools/clang/test/SemaCXX/coroutines.cpp
 Line 872: 'operator new' takes type size_t ('unsigned int') as first parameter
error: 'note' diagnostics expected but not seen: 
  File 
/home/buildslave/buildslave/clang-cmake-armv7-a15/llvm/tools/clang/test/SemaCXX/coroutines.cpp
 Line 816 (directive at 
/home/buildslave/buildslave/clang-cmake-armv7-a15/llvm/tools/clang/test/SemaCXX/coroutines.cpp:815):
 candidate function not viable: requires 2 arguments, but 1 was provided
  File 
/home/buildslave/buildslave/clang-cmake-armv7-a15/llvm/tools/clang/test/SemaCXX/coroutines.cpp
 Line 839 (directive at 
/home/buildslave/buildslave/clang-cmake-armv7-a15/llvm/tools/clang/test/SemaCXX/coroutines.cpp:838):
 candidate function not viable: requires 4 arguments, but 1 was provided
8 errors generated.

Can you take a look?

Douglas Yung

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of
> Brian Gesiak via cfe-commits
> Sent: Thursday, February 15, 2018 12:37
> To: cfe-commits@lists.llvm.org
> Subject: r325291 - [Coroutines] Use allocator overload when available
> 
> Author: modocache
> Date: Thu Feb 15 12:37:22 2018
> New Revision: 325291
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=325291&view=rev
> Log:
> [Coroutines] Use allocator overload when available
> 
> Summary:
> Depends on https://reviews.llvm.org/D42605.
> 
> An implementation of the behavior described in `[dcl.fct.def.coroutine]/7`:
> when a promise type overloads `operator new` using a "placement new"
> that takes the same argument types as the coroutine function, that overload is
> used when allocating the coroutine frame.
> 
> Simply passing references to the coroutine function parameters directly to
> `operator new` results in invariant violations in LLVM's coroutine splitting
> pass, so this implementation modifies Clang codegen to produce allocator-
> specific alloc/store/loads for each parameter being forwarded to the
> allocator.
> 
> Test Plan: `check-clang`
> 
> Reviewers: rsmith, GorNishanov, eric_niebler
> 
> Reviewed By: GorNishanov
> 
> Subscribers: lewissbaker, EricWF, cfe-commits
> 
> Differential Revision: https://reviews.llvm.org/D42606
> 
> Modified:
> cfe/trunk/lib/Sema/SemaCoroutine.cpp
> cfe/trunk/test/CodeGenCoroutines/coro-alloc.cpp
> cfe/trunk/test/CodeGenCoroutines/coro-gro-nrvo.cpp
> cfe/trunk/test/CodeGenCoroutines/coro-params.cpp
> cfe/trunk/test/SemaCXX/coroutines.cpp
> 
> Modified: cfe/trunk/lib/Sema/SemaCoroutine.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/Sema/SemaCoroutine.cpp?rev=325291&r1=325290&r2=325291&vi
> ew=diff
> ==
> --- cfe/trunk/lib/Sema/SemaCoroutine.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaCoroutine.cpp Thu Feb 15 12:37:22 2018
> @@ -12,6 +12,7 @@
>  //===--
> ===//
> 
>  #include "CoroutineStmtBuilder.h"
> +#include "clang/AST/ASTLambda.h"
>  #include "clang/AST/Decl.h"
>  #include "clang/AST/ExprCXX.h"
>  #include "clang/AST/StmtCXX.h"
> @@ -506,24 +507,15 @@ VarDecl *Sema::buildCoroutinePromise(Sou
> 
>  auto RefExpr = ExprEmpty();
>  auto Move = Moves.find(PD);
> -if (Move != Moves.end()) {
> -  // If a reference to the functio

RE: r325691 - [clang-format] New API guessLanguage()

[via cfe-commits]

Hi Ben,

Your change is causing a test failure on one of the bots, can you take a look?

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/25515

FAIL: Clang Tools :: clang-apply-replacements/format.cpp (12526 of 38114)
 TEST 'Clang Tools :: clang-apply-replacements/format.cpp' 
FAILED 
Script:
--
mkdir -p 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/tools/extra/test/clang-apply-replacements/Output/Inputs/format
grep -Ev "// *[A-Z-]+:" 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/tools/extra/test/clang-apply-replacements/Inputs/format/yes.cpp
 > 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/tools/extra/test/clang-apply-replacements/Output/Inputs/format/yes.cpp
grep -Ev "// *[A-Z-]+:" 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/tools/extra/test/clang-apply-replacements/Inputs/format/no.cpp
 > 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/tools/extra/test/clang-apply-replacements/Output/Inputs/format/no.cpp
sed 
"s#\$(path)#/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/tools/extra/test/clang-apply-replacements/Output/Inputs/format#"
 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/tools/extra/test/clang-apply-replacements/Inputs/format/yes.yaml
 > 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/tools/extra/test/clang-apply-replacements/Output/Inputs/format/yes.yaml
sed 
"s#\$(path)#/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/tools/extra/test/clang-apply-replacements/Output/Inputs/format#"
 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/tools/extra/test/clang-apply-replacements/Inputs/format/no.yaml
 > 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/tools/extra/test/clang-apply-replacements/Output/Inputs/format/no.yaml
clang-apply-replacements -format 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/tools/extra/test/clang-apply-replacements/Output/Inputs/format
FileCheck --strict-whitespace 
-input-file=/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/tools/extra/test/clang-apply-replacements/Output/Inputs/format/yes.cpp
 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/tools/extra/test/clang-apply-replacements/Inputs/format/yes.cpp
FileCheck --strict-whitespace 
-input-file=/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/tools/extra/test/clang-apply-replacements/Output/Inputs/format/no.cpp
 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/tools/extra/test/clang-apply-replacements/Inputs/format/no.cpp
--
Exit Code: 134

Command Output (stderr):
--
clang-apply-replacements: 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/lib/Basic/SourceManager.cpp:393:
 const clang::SrcMgr::ContentCache 
*clang::SourceManager::getOrCreateContentCache(const clang::FileEntry *, bool): 
Assertion `FileEnt && "Didn't specify a file entry to use?"' failed.
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/tools/extra/test/clang-apply-replacements/Output/format.cpp.script:
 line 8: 49680 Aborted (core dumped) clang-apply-replacements 
-format 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/tools/extra/test/clang-apply-replacements/Output/Inputs/format

--



Douglas Yung


> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of Ben
> Hamilton via cfe-commits
> Sent: Wednesday, February 21, 2018 7:55
> To: cfe-commits@lists.llvm.org
> Subject: r325691 - [clang-format] New API guessLanguage()
> 
> Author: benhamilton
> Date: Wed Feb 21 07:54:31 2018
> New Revision: 325691
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=325691&view=rev
> Log:
> [clang-format] New API guessLanguage()
> 
> Summary:
> For clients which don't have a filesystem, calling getStyle() doesn't make
> much sense (there's no .clang-format files to search for).
> 
> In this diff, I hoist out the language-guessing logic from getStyle() and move
> it into a new API guessLanguage().
> 
&g

r325771 - [OpenCL] Add '-cl-uniform-work-group-size' compile option

[via cfe-commits]

Author: AlexeySotkin
Date: Thu Feb 22 03:54:14 2018
New Revision: 325771

URL: http://llvm.org/viewvc/llvm-project?rev=325771&view=rev
Log:
[OpenCL] Add '-cl-uniform-work-group-size' compile option

Summary:
OpenCL 2.0 specification defines '-cl-uniform-work-group-size' option,
which requires that the global work-size be a multiple of the work-group
size specified to clEnqueueNDRangeKernel and allows optimizations that
are made possible by this restriction.

The patch introduces the support of this option.

To keep information about whether an OpenCL kernel has uniform work
group size or not, clang generates 'uniform-work-group-size' function
attribute for every kernel:
- "uniform-work-group-size"="true" for OpenCL 1.2 and lower,
- "uniform-work-group-size"="true" for OpenCL 2.0 and higher if
 '-cl-uniform-work-group-size' option was specified,
- "uniform-work-group-size"="false" for OpenCL 2.0 and higher if no
 '-cl-uniform-work-group-size' options was specified.

If the function is not an OpenCL kernel, 'uniform-work-group-size'
attribute isn't generated.

Patch by: krisb

Reviewers: yaxunl, Anastasia, b-sumner

Reviewed By: yaxunl, Anastasia

Subscribers: nhaehnle, yaxunl, Anastasia, cfe-commits

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

Added:
cfe/trunk/test/CodeGenOpenCL/cl-uniform-wg-size.cl
Modified:
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/CodeGenOpenCL/amdgpu-abi-struct-coerce.cl
cfe/trunk/test/CodeGenOpenCL/convergent.cl
cfe/trunk/test/Driver/opencl.cl

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=325771&r1=325770&r2=325771&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Thu Feb 22 03:54:14 2018
@@ -518,6 +518,8 @@ def cl_denorms_are_zero : Flag<["-"], "c
   HelpText<"OpenCL only. Allow denormals to be flushed to zero.">;
 def cl_fp32_correctly_rounded_divide_sqrt : Flag<["-"], 
"cl-fp32-correctly-rounded-divide-sqrt">, Group, 
Flags<[CC1Option]>,
   HelpText<"OpenCL only. Specify that single precision floating-point divide 
and sqrt used in the program source are correctly rounded.">;
+def cl_uniform_work_group_size : Flag<["-"], "cl-uniform-work-group-size">, 
Group, Flags<[CC1Option]>,
+  HelpText<"OpenCL only. Defines that the global work-size be a multiple of 
the work-group size specified to clEnqueueNDRangeKernel">;
 def client__name : JoinedOrSeparate<["-"], "client_name">;
 def combine : Flag<["-", "--"], "combine">, Flags<[DriverOption, Unsupported]>;
 def compatibility__version : JoinedOrSeparate<["-"], "compatibility_version">;

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=325771&r1=325770&r2=325771&view=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Thu Feb 22 03:54:14 2018
@@ -128,6 +128,7 @@ CODEGENOPT(NoTrappingMath, 1, 0) ///
 CODEGENOPT(NoNaNsFPMath  , 1, 0) ///< Assume FP arguments, results not NaN.
 CODEGENOPT(FlushDenorm   , 1, 0) ///< Allow FP denorm numbers to be 
flushed to zero
 CODEGENOPT(CorrectlyRoundedDivSqrt, 1, 0) ///< 
-cl-fp32-correctly-rounded-divide-sqrt
+CODEGENOPT(UniformWGSize , 1, 0) ///< -cl-uniform-work-group-size
 CODEGENOPT(NoZeroInitializedInBSS , 1, 0) ///< -fno-zero-initialized-in-bss.
 /// \brief Method of Objective-C dispatch to use.
 ENUM_CODEGENOPT(ObjCDispatchMethod, ObjCDispatchMethodKind, 2, Legacy)

Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=325771&r1=325770&r2=325771&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Thu Feb 22 03:54:14 2018
@@ -1870,6 +1870,21 @@ void CodeGenModule::ConstructAttributeLi
 }
   }
 
+  if (TargetDecl && TargetDecl->hasAttr()) {
+if (getLangOpts().OpenCLVersion <= 120) {
+  // OpenCL v1.2 Work groups are always uniform
+  FuncAttrs.addAttribute("uniform-work-group-size", "true");
+} else {
+  // OpenCL v2.0 Work groups may be whether uniform or not.
+  // '-cl-uniform-work-group-size' compile option gets a hint
+  // to the compiler that the global work-size be a multiple of
+  // the work-group size specified to clEnqueueNDRangeKernel
+  // (i.e. work groups are uniform).
+  FuncAttrs.addAttribute("uniform-work-grou

RE: r325850 - [Darwin] Add a test to check clang produces accelerator tables.

[via cfe-commits]

Hi Davide,
Clang does not have end-to-end tests like this.  To verify we produce the
apple accelerator tables, you want a .ll source in llvm/test/CodeGen/X86.
In the meantime I've reverted the commit in r325920.
Thanks,
--paulr

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of
> Yvan Roux via cfe-commits
> Sent: Friday, February 23, 2018 5:34 AM
> To: Davide Italiano
> Cc: cfe-commits
> Subject: Re: r325850 - [Darwin] Add a test to check clang produces
> accelerator tables.
> 
> Hi Davide,
> 
> 
> This patch broke ARM and AArch64 bots (x86_64 apple targets are not
> available on these bots).
> Logs are available here:
> http://lab.llvm.org:8011/builders/clang-cmake-armv7-
> a15/builds/15940/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Adebug-
> info-section-macho.c
> 
> Thanks
> Yvan
> 
> On 23 February 2018 at 02:25, Davide Italiano via cfe-commits
>  wrote:
> > Author: davide
> > Date: Thu Feb 22 17:25:03 2018
> > New Revision: 325850
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=325850&view=rev
> > Log:
> > [Darwin] Add a test to check clang produces accelerator tables.
> >
> > This test was previously in lldb, and was only checking that clang
> > was emitting the correct section. So, it belongs here and not
> > in the debugger.
> >
> > Added:
> > cfe/trunk/test/CodeGen/debug-info-section-macho.c
> >
> > Added: cfe/trunk/test/CodeGen/debug-info-section-macho.c
> > URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/debug-
> info-section-macho.c?rev=325850&view=auto
> >
> ==
> 
> > --- cfe/trunk/test/CodeGen/debug-info-section-macho.c (added)
> > +++ cfe/trunk/test/CodeGen/debug-info-section-macho.c Thu Feb 22
> 17:25:03 2018
> > @@ -0,0 +1,16 @@
> > +// Test that clang produces the __apple accelerator tables,
> > +// e.g., __apple_types, correctly.
> > +// RUN: %clang %s -target x86_64-apple-macosx10.13.0 -c -g -o %t-ex
> > +// RUN: llvm-objdump -section-headers %t-ex | FileCheck %s
> > +
> > +int main (int argc, char const *argv[]) { return argc; }
> > +
> > +// CHECK: __debug_str
> > +// CHECK-NEXT: __debug_abbrev
> > +// CHECK-NEXT: __debug_info
> > +// CHECK-NEXT: __debug_ranges
> > +// CHECK-NEXT: __debug_macinfo
> > +// CHECK-NEXT: __apple_names
> > +// CHECK-NEXT: __apple_objc
> > +// CHECK-NEXT: __apple_namespac
> > +// CHECK-NEXT: __apple_types
> >
> >
> > ___
> > cfe-commits mailing list
> > cfe-commits@lists.llvm.org
> > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D34563: [ubsan] Disable the object-size check at -O0

[via cfe-commits]

Good point, it makes sense to hand users a warning when they explicitly enable -fsanitize=object-size at -O0. I've added in the diagnostic. PTAL.


disable-object-size-check-O0.diff
Description: Binary data
vedantOn Jun 23, 2017, at 1:05 PM, Justin Bogner  wrote:+++ test/Driver/fsanitize-object-size.c@@ -0,0 +1,25 @@+// Check that the object size check is disabled at -O0.+//+// RUN: %clang -target x86_64-linux-gnu -fsanitize=object-size %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-OSIZE+// RUN: %clang -target x86_64-linux-gnu -fsanitize=object-size %s -O0 -### 2>&1 | FileCheck %s --check-prefix=CHECK-NO-OSIZEThis isn't great - the user explicitly opted in to object-size but theydon't get it. We should either diagnose this and behave as is, or justenable the sanitizer even though it's not effective for forwardscompatibility.___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r326566 - Add possibility to specify output stream for CompilerInstance

[via cfe-commits]

Author: AlexeySotkin
Date: Fri Mar  2 04:11:40 2018
New Revision: 326566

URL: http://llvm.org/viewvc/llvm-project?rev=326566&view=rev
Log:
Add possibility to specify output stream for CompilerInstance

Patch by: krisb

Reviewers: teemperor

Reviewed By: teemperor

Subscribers: klimek, mgorny, cfe-commits

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

Added:
cfe/trunk/unittests/Frontend/OutputStreamTest.cpp
Modified:
cfe/trunk/include/clang/Frontend/CompilerInstance.h
cfe/trunk/lib/CodeGen/CodeGenAction.cpp
cfe/trunk/unittests/Frontend/CMakeLists.txt

Modified: cfe/trunk/include/clang/Frontend/CompilerInstance.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CompilerInstance.h?rev=326566&r1=326565&r2=326566&view=diff
==
--- cfe/trunk/include/clang/Frontend/CompilerInstance.h (original)
+++ cfe/trunk/include/clang/Frontend/CompilerInstance.h Fri Mar  2 04:11:40 2018
@@ -183,6 +183,9 @@ class CompilerInstance : public ModuleLo
   /// The list of active output files.
   std::list OutputFiles;
 
+  /// Force an output buffer.
+  std::unique_ptr OutputStream;
+
   CompilerInstance(const CompilerInstance &) = delete;
   void operator=(const CompilerInstance &) = delete;
 public:
@@ -773,6 +776,14 @@ public:
 
   /// }
 
+  void setOutputStream(std::unique_ptr OutStream) {
+OutputStream = std::move(OutStream);
+  }
+
+  std::unique_ptr takeOutputStream() {
+return std::move(OutputStream);
+  }
+
   // Create module manager.
   void createModuleManager();
 

Modified: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenAction.cpp?rev=326566&r1=326565&r2=326566&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenAction.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp Fri Mar  2 04:11:40 2018
@@ -846,7 +846,10 @@ GetOutputStream(CompilerInstance &CI, St
 std::unique_ptr
 CodeGenAction::CreateASTConsumer(CompilerInstance &CI, StringRef InFile) {
   BackendAction BA = static_cast(Act);
-  std::unique_ptr OS = GetOutputStream(CI, InFile, BA);
+  std::unique_ptr OS = CI.takeOutputStream();
+  if (!OS)
+OS = GetOutputStream(CI, InFile, BA);
+
   if (BA != Backend_EmitNothing && !OS)
 return nullptr;
 

Modified: cfe/trunk/unittests/Frontend/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Frontend/CMakeLists.txt?rev=326566&r1=326565&r2=326566&view=diff
==
--- cfe/trunk/unittests/Frontend/CMakeLists.txt (original)
+++ cfe/trunk/unittests/Frontend/CMakeLists.txt Fri Mar  2 04:11:40 2018
@@ -9,6 +9,7 @@ add_clang_unittest(FrontendTests
   CodeGenActionTest.cpp
   ParsedSourceLocationTest.cpp
   PCHPreambleTest.cpp
+  OutputStreamTest.cpp
   )
 target_link_libraries(FrontendTests
   PRIVATE
@@ -18,4 +19,5 @@ target_link_libraries(FrontendTests
   clangLex
   clangSema
   clangCodeGen
+  clangFrontendTool
   )

Added: cfe/trunk/unittests/Frontend/OutputStreamTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Frontend/OutputStreamTest.cpp?rev=326566&view=auto
==
--- cfe/trunk/unittests/Frontend/OutputStreamTest.cpp (added)
+++ cfe/trunk/unittests/Frontend/OutputStreamTest.cpp Fri Mar  2 04:11:40 2018
@@ -0,0 +1,46 @@
+//===- unittests/Frontend/OutputStreamTest.cpp --- FrontendAction tests --===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "clang/CodeGen/BackendUtil.h"
+#include "clang/CodeGen/CodeGenAction.h"
+#include "clang/Frontend/CompilerInstance.h"
+#include "clang/FrontendTool/Utils.h"
+#include "clang/Lex/PreprocessorOptions.h"
+#include "gtest/gtest.h"
+
+using namespace llvm;
+using namespace clang;
+using namespace clang::frontend;
+
+namespace {
+
+TEST(FrontendOutputTests, TestOutputStream) {
+  auto Invocation = std::make_shared();
+  Invocation->getPreprocessorOpts().addRemappedFile(
+  "test.cc", MemoryBuffer::getMemBuffer("").release());
+  Invocation->getFrontendOpts().Inputs.push_back(
+  FrontendInputFile("test.cc", InputKind::CXX));
+  Invocation->getFrontendOpts().ProgramAction = EmitBC;
+  Invocation->getTargetOpts().Triple = "i386-unknown-linux-gnu";
+  CompilerInstance Compiler;
+
+  SmallVector IRBuffer;
+  std::unique_ptr IRStream(
+  new raw_svector_ostream(IRBuffer));
+
+  Compiler.setOutputStream(std::move(IRStream));
+  Compiler.setInvocation(std::move(Invocation));
+  Compiler.createDiagnostics();
+
+  bool Success = ExecuteCompilerInvocation(&Compiler);
+  EXPECT_TRUE(Success

RE: [PATCH] D44218: Correct the alignment for the PS4 target

[via cfe-commits]

Thanks! I’ll commit this.

From: Eric Christopher [mailto:echri...@gmail.com]
Sent: Wednesday, March 7, 2018 12:33 PM
To: reviews+d44218+public+fd8ca19cc9985...@reviews.llvm.org
Cc: cfe-commits@lists.llvm.org; craig.top...@gmail.com; erich.ke...@intel.com; 
filcab+llvm.phabrica...@gmail.com; Voss, Matthew; rich...@metafoo.co.uk
Subject: Re: [PATCH] D44218: Correct the alignment for the PS4 target

LGTM.
On Wed, Mar 7, 2018, 11:02 AM Matthew Voss via Phabricator 
mailto:revi...@reviews.llvm.org>> wrote:
ormris created this revision.
ormris added reviewers: rsmith, craig.topper, echristo, erichkeane.

See above.


Repository:
  rC Clang

https://reviews.llvm.org/D44218

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


Index: test/Preprocessor/init.c
===
--- test/Preprocessor/init.c
+++ test/Preprocessor/init.c
@@ -8965,6 +8965,9 @@
 // PS4:#define __x86_64__ 1
 // PS4:#define unix 1
 //
+// RUN: %clang_cc1 -x c++ -E -dM -ffreestanding -triple=x86_64-scei-ps4 < 
/dev/null | FileCheck -match-full-lines -check-prefix PS4-CXX %s
+// PS4-CXX:#define __STDCPP_DEFAULT_NEW_ALIGNMENT__ 32UL
+//
 // RUN: %clang_cc1 -E -dM -triple=x86_64-pc-mingw32 < /dev/null | FileCheck 
-match-full-lines -check-prefix X86-64-DECLSPEC %s
 // RUN: %clang_cc1 -E -dM -fms-extensions -triple=x86_64-unknown-mingw32 < 
/dev/null | FileCheck -match-full-lines -check-prefix X86-64-DECLSPEC %s
 // X86-64-DECLSPEC: #define __declspec{{.*}}
Index: lib/Basic/Targets/OSTargets.h
===
--- lib/Basic/Targets/OSTargets.h
+++ lib/Basic/Targets/OSTargets.h
@@ -485,6 +485,7 @@
 default:
 case llvm::Triple::x86_64:
   this->MCountName = ".mcount";
+  this->NewAlign = 256;
   break;
 }
   }

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

RE: [clang-tools-extra] r327295 - Reland "[clang-doc] Setup clang-doc frontend framework"

[via cfe-commits]

Hi Julie,

It looks like this commit is causing Clang tests in Windows bots to crash. 
Could you take a look?

http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/9413

Thanks,
Matthew

-Original Message-
From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of 
Julie Hockett via cfe-commits
Sent: Monday, March 12, 2018 10:05 AM
To: cfe-commits@lists.llvm.org
Subject: [clang-tools-extra] r327295 - Reland "[clang-doc] Setup clang-doc 
frontend framework"

Author: juliehockett
Date: Mon Mar 12 10:05:14 2018
New Revision: 327295

URL: http://llvm.org/viewvc/llvm-project?rev=327295&view=rev
Log:
Reland "[clang-doc] Setup clang-doc frontend framework"

There was a missing newline in the docs, and a static_assert that needed
to be a normal assert.

Added:
clang-tools-extra/trunk/clang-doc/BitcodeWriter.cpp
clang-tools-extra/trunk/clang-doc/BitcodeWriter.h
clang-tools-extra/trunk/clang-doc/CMakeLists.txt
clang-tools-extra/trunk/clang-doc/ClangDoc.cpp
clang-tools-extra/trunk/clang-doc/ClangDoc.h
clang-tools-extra/trunk/clang-doc/Mapper.cpp
clang-tools-extra/trunk/clang-doc/Mapper.h
clang-tools-extra/trunk/clang-doc/Representation.h
clang-tools-extra/trunk/clang-doc/Serialize.cpp
clang-tools-extra/trunk/clang-doc/Serialize.h
clang-tools-extra/trunk/clang-doc/tool/CMakeLists.txt
clang-tools-extra/trunk/clang-doc/tool/ClangDocMain.cpp
clang-tools-extra/trunk/docs/clang-doc.rst
clang-tools-extra/trunk/test/clang-doc/mapper-class-in-class.cpp
clang-tools-extra/trunk/test/clang-doc/mapper-class-in-function.cpp
clang-tools-extra/trunk/test/clang-doc/mapper-class.cpp
clang-tools-extra/trunk/test/clang-doc/mapper-comments.cpp
clang-tools-extra/trunk/test/clang-doc/mapper-enum.cpp
clang-tools-extra/trunk/test/clang-doc/mapper-function.cpp
clang-tools-extra/trunk/test/clang-doc/mapper-method.cpp
clang-tools-extra/trunk/test/clang-doc/mapper-namespace.cpp
clang-tools-extra/trunk/test/clang-doc/mapper-struct.cpp
clang-tools-extra/trunk/test/clang-doc/mapper-union.cpp
Modified:
clang-tools-extra/trunk/CMakeLists.txt
clang-tools-extra/trunk/test/CMakeLists.txt

Modified: clang-tools-extra/trunk/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/CMakeLists.txt?rev=327295&r1=327294&r2=327295&view=diff
==
--- clang-tools-extra/trunk/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/CMakeLists.txt Mon Mar 12 10:05:14 2018
@@ -7,6 +7,7 @@ add_subdirectory(clang-tidy-vs)
 endif()
 
 add_subdirectory(change-namespace)
+add_subdirectory(clang-doc)
 add_subdirectory(clang-query)
 add_subdirectory(clang-move)
 add_subdirectory(clangd)

Added: clang-tools-extra/trunk/clang-doc/BitcodeWriter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-doc/BitcodeWriter.cpp?rev=327295&view=auto
==
--- clang-tools-extra/trunk/clang-doc/BitcodeWriter.cpp (added)
+++ clang-tools-extra/trunk/clang-doc/BitcodeWriter.cpp Mon Mar 12 10:05:14 2018
@@ -0,0 +1,515 @@
+//===--  BitcodeWriter.cpp - ClangDoc Bitcode Writer *- C++ 
-*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "BitcodeWriter.h"
+#include "llvm/ADT/IndexedMap.h"
+
+namespace clang {
+namespace doc {
+
+// Since id enums are not zero-indexed, we need to transform the given id into
+// its associated index.
+struct BlockIdToIndexFunctor {
+  using argument_type = unsigned;
+  unsigned operator()(unsigned ID) const { return ID - BI_FIRST; }
+};
+
+struct RecordIdToIndexFunctor {
+  using argument_type = unsigned;
+  unsigned operator()(unsigned ID) const { return ID - RI_FIRST; }
+};
+
+using AbbrevDsc = void (*)(std::shared_ptr &Abbrev);
+
+static void AbbrevGen(std::shared_ptr &Abbrev,
+  const std::initializer_list Ops) {
+  for (const auto &Op : Ops)
+Abbrev->Add(Op);
+}
+
+static void BoolAbbrev(std::shared_ptr &Abbrev) {
+  AbbrevGen(Abbrev,
+{// 0. Boolean
+ llvm::BitCodeAbbrevOp(llvm::BitCodeAbbrevOp::Fixed,
+   BitCodeConstants::BoolSize)});
+}
+
+static void IntAbbrev(std::shared_ptr &Abbrev) {
+  AbbrevGen(Abbrev,
+{// 0. Fixed-size integer
+ llvm::BitCodeAbbrevOp(llvm::BitCodeAbbrevOp::Fixed,
+   BitCodeConstants::IntSize)});
+}
+
+static void SymbolIDAbbrev(std::shared_ptr &Abbrev) {
+  AbbrevGen(Abbrev,
+{// 0. Fixed-size integer (len

RE: r327322 - [Tooling] Clear the PreambleSrcLocCache when preamble is discarded during reparsing

[via cfe-commits]

Hi Alex,

The test you added in this commit seems to be failing on the Windows bot 
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/15855:

FAIL: Clang :: Index/reparsed-live-issue.cpp (7841 of 38815)
 TEST 'Clang :: Index/reparsed-live-issue.cpp' FAILED 

Script:
--
CINDEXTEST_EDITING=1 LIBCLANG_DISABLE_CRASH_RECOVERY=1 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\bin\c-index-test.EXE
 -test-load-source-reparse 2 none 
-remap-file-0=C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Index/Inputs/reparse-issue.h,C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Index/Inputs/reparse-issue.h-0
 
-remap-file-1=C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Index/Inputs/reparse-issue.h,C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Index/Inputs/reparse-issue.h-1
 -- 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Index\reparsed-live-issue.cpp
 2>&1 | 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\bin\FileCheck.EXE
 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Index\reparsed-live-issue.cpp
--
Exit Code: 127

Command Output (stdout):
--
$ "CINDEXTEST_EDITING=1" "LIBCLANG_DISABLE_CRASH_RECOVERY=1" 
"C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\bin\c-index-test.EXE"
 "-test-load-source-reparse" "2" "none" 
"-remap-file-0=C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Index/Inputs/reparse-issue.h,C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Index/Inputs/reparse-issue.h-0"
 
"-remap-file-1=C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Index/Inputs/reparse-issue.h,C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Index/Inputs/reparse-issue.h-1"
 "--" 
"C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Index\reparsed-live-issue.cpp"
# command stderr:
'CINDEXTEST_EDITING=1': command not found
error: command failed with exit status: 127

--



It seems perhaps you forgot to prefix the test line with "env"?

Douglas Yung

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of
> Alex Lorenz via cfe-commits
> Sent: Monday, March 12, 2018 12:36
> To: cfe-commits@lists.llvm.org
> Subject: r327322 - [Tooling] Clear the PreambleSrcLocCache when preamble is
> discarded during reparsing
> 
> Author: arphaman
> Date: Mon Mar 12 12:36:29 2018
> New Revision: 327322
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=327322&view=rev
> Log:
> [Tooling] Clear the PreambleSrcLocCache when preamble is discarded during
> reparsing
> 
> This ensures that diagnostics are not remapped to incorrect preamble locations
> after the second reparse with a remapped header file occurs.
> 
> rdar://37502480
> 
> Added:
> cfe/trunk/test/Index/Inputs/reparse-issue.h
> cfe/trunk/test/Index/Inputs/reparse-issue.h-0
> cfe/trunk/test/Index/Inputs/reparse-issue.h-1
> cfe/trunk/test/Index/reparsed-live-issue.cpp
> Modified:
> cfe/trunk/lib/Frontend/ASTUnit.cpp
> 
> Modified: cfe/trunk/lib/Frontend/ASTUnit.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/Frontend/ASTUnit.cpp?rev=327322&r1=327321&r2=327322&view
> =diff
> ==
> --- cfe/trunk/lib/Frontend/ASTUnit.cpp (original)
> +++ cfe/trunk/lib/Frontend/ASTUnit.cpp Mon Mar 12 12:36:29 2018
> @@ -1259,6 +1259,7 @@ ASTUnit::getMainBufferWithPrecompiledPre
>Preamble.reset();
>PreambleDiagnostics.clear();
>TopLevelDeclsInPreamble.clear();
> +  PreambleSrcLocCache.clear();
>PreambleRebuildCounter = 1;
>  }
>}
> 
> Added: cfe/trunk/test/Index/Inputs/reparse-issue.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/Inputs/reparse-
> issue.h?rev=327322&view=auto
> ==
> --- cfe/trunk/test/Index/Inputs/reparse-issue.h (added)
> +++ cfe/trunk/test/Index/Inputs/reparse-issue.h Mon Mar 12 12:36:29 2018
> @@ -0,0 +1,3 @@
> +
> +asdf;
> +
> 
> Added: cfe/trunk/test/Index/Inputs/reparse-issue.h-0
> URL: http:

RE: [clang-tools-extra] r327833 - [clang-tidy] New check bugprone-unused-return-value

[via cfe-commits]

This should be fixed by r327911.

Douglas Yung

From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of 
Galina Kistanova via cfe-commits
Sent: Monday, March 19, 2018 13:13
To: Alexander Kornienko
Cc: cfe-commits
Subject: Re: [clang-tools-extra] r327833 - [clang-tidy] New check 
bugprone-unused-return-value

Hello Alexander,

This commit broke at least two of our builders:

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/26909
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast

. . .
Failing Tests (1):
Clang Tools :: clang-tidy/bugprone-unused-return-value.cpp

Please have a look?

It is not good idea to keep the bot red for too long. This hides new problem 
which later hard to track down.

Thanks

Galina

On Mon, Mar 19, 2018 at 6:02 AM, Alexander Kornienko via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: alexfh
Date: Mon Mar 19 06:02:32 2018
New Revision: 327833

URL: http://llvm.org/viewvc/llvm-project?rev=327833&view=rev
Log:
[clang-tidy] New check bugprone-unused-return-value

Summary:
Detects function calls where the return value is unused.

Checked functions can be configured.

Reviewers: alexfh, aaron.ballman, ilya-biryukov, hokein

Reviewed By: alexfh, aaron.ballman

Subscribers: hintonda, JonasToth, Eugene.Zelenko, mgorny, xazax.hun, cfe-commits

Tags: #clang-tools-extra

Patch by Kalle Huttunen!

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

Added:
clang-tools-extra/trunk/clang-tidy/bugprone/UnusedReturnValueCheck.cpp
clang-tools-extra/trunk/clang-tidy/bugprone/UnusedReturnValueCheck.h

clang-tools-extra/trunk/docs/clang-tidy/checks/bugprone-unused-return-value.rst

clang-tools-extra/trunk/test/clang-tidy/bugprone-unused-return-value-custom.cpp
clang-tools-extra/trunk/test/clang-tidy/bugprone-unused-return-value.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/bugprone/BugproneTidyModule.cpp
clang-tools-extra/trunk/clang-tidy/bugprone/CMakeLists.txt
clang-tools-extra/trunk/docs/ReleaseNotes.rst
clang-tools-extra/trunk/docs/clang-tidy/checks/list.rst

Modified: clang-tools-extra/trunk/clang-tidy/bugprone/BugproneTidyModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/bugprone/BugproneTidyModule.cpp?rev=327833&r1=327832&r2=327833&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/bugprone/BugproneTidyModule.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/bugprone/BugproneTidyModule.cpp Mon Mar 
19 06:02:32 2018
@@ -43,6 +43,7 @@
 #include "UndefinedMemoryManipulationCheck.h"
 #include "UndelegatedConstructorCheck.h"
 #include "UnusedRaiiCheck.h"
+#include "UnusedReturnValueCheck.h"
 #include "UseAfterMoveCheck.h"
 #include "VirtualNearMissCheck.h"

@@ -119,6 +120,8 @@ public:
 "bugprone-undelegated-constructor");
 CheckFactories.registerCheck(
 "bugprone-unused-raii");
+CheckFactories.registerCheck(
+"bugprone-unused-return-value");
 CheckFactories.registerCheck(
 "bugprone-use-after-move");
 CheckFactories.registerCheck(

Modified: clang-tools-extra/trunk/clang-tidy/bugprone/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/bugprone/CMakeLists.txt?rev=327833&r1=327832&r2=327833&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/bugprone/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clang-tidy/bugprone/CMakeLists.txt Mon Mar 19 
06:02:32 2018
@@ -35,6 +35,7 @@ add_clang_library(clangTidyBugproneModul
   UndefinedMemoryManipulationCheck.cpp
   UndelegatedConstructorCheck.cpp
   UnusedRaiiCheck.cpp
+  UnusedReturnValueCheck.cpp
   UseAfterMoveCheck.cpp
   VirtualNearMissCheck.cpp


Added: clang-tools-extra/trunk/clang-tidy/bugprone/UnusedReturnValueCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/bugprone/UnusedReturnValueCheck.cpp?rev=327833&view=auto
==
--- clang-tools-extra/trunk/clang-tidy/bugprone/UnusedReturnValueCheck.cpp 
(added)
+++ clang-tools-extra/trunk/clang-tidy/bugprone/UnusedReturnValueCheck.cpp Mon 
Mar 19 06:02:32 2018
@@ -0,0 +1,82 @@
+//===--- UnusedReturnValueCheck.cpp - 
clang-tidy---===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "UnusedReturnValueCheck.h"
+#include "../utils/OptionsUtils.h"
+#include 

RE: r334418 - Enable crash recovery tests on Windows, globs work in the lit internal shell now

[via cfe-commits]

ash-report-modules.m"
 "-I" 
"C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Driver/Inputs/module"
 "-isysroot" 
"C:/ps4-buildslave2/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/llvm.obj/tools/clang/test/Driver/Output/crash-report-modules.m.tmp/i/"
 "-fmodules" 
"-fmodules-cache-path=C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\tools\clang\test\Driver\Output\crash-report-modules.m.tmp/m/"
 "-DFOO=BAR"
note: command had no output on stdout or stderr
error: command failed with exit status: 1
$ 
"C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\bin\FileCheck.EXE"
 
"C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Driver\crash-report-modules.m"
# command stderr:
FileCheck error: '-' is empty.

FileCheck command line:  
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\bin\FileCheck.EXE
 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Driver\crash-report-modules.m


error: command failed with exit status: 2

Douglas Yung

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of Reid Kleckner via cfe-commits
> Sent: Monday, June 11, 2018 9:50
> To: cfe-commits@lists.llvm.org
> Subject: r334418 - Enable crash recovery tests on Windows, globs work
> in the lit internal shell now
> 
> Author: rnk
> Date: Mon Jun 11 09:50:07 2018
> New Revision: 334418
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=334418&view=rev
> Log:
> Enable crash recovery tests on Windows, globs work in the lit internal
> shell now
> 
> Modified:
> cfe/trunk/test/Driver/crash-report-header.h
> cfe/trunk/test/Driver/crash-report-modules.m
> cfe/trunk/test/Driver/crash-report-spaces.c
> cfe/trunk/test/Driver/crash-report.c
> 
> Modified: cfe/trunk/test/Driver/crash-report-header.h
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/crash-
> report-header.h?rev=334418&r1=334417&r2=334418&view=diff
> ===
> ===
> --- cfe/trunk/test/Driver/crash-report-header.h (original)
> +++ cfe/trunk/test/Driver/crash-report-header.h Mon Jun 11 09:50:07
> 2018
> @@ -5,9 +5,6 @@
>  // RUN: cat %t/crash-report-header-*.sh | FileCheck --check-
> prefix=CHECKSH "%s"
>  // REQUIRES: crash-recovery
> 
> -// because of the glob (*.h, *.sh)
> -// REQUIRES: shell
> -
>  #pragma clang __debug parser_crash
>  // CHECK: Preprocessed source(s) and associated run script(s) are
> located at:
>  // CHECK-NEXT: note: diagnostic msg: {{.*}}.h
> 
> Modified: cfe/trunk/test/Driver/crash-report-modules.m
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/crash-
> report-modules.m?rev=334418&r1=334417&r2=334418&view=diff
> ===
> ===
> --- cfe/trunk/test/Driver/crash-report-modules.m (original)
> +++ cfe/trunk/test/Driver/crash-report-modules.m Mon Jun 11 09:50:07
> 2018
> @@ -9,12 +9,6 @@
>  // RUN: FileCheck --check-prefix=CHECKSH %s -input-file %t/crash-
> report-*.sh
>  // REQUIRES: crash-recovery
> 
> -// because of the glob (*.m, *.sh)
> -// REQUIRES: shell
> -
> -// FIXME: This XFAIL is cargo-culted from crash-report.c. Do we need
> it?
> -// XFAIL: mingw32
> -
>  @import simple;
>  const int x = MODULE_MACRO;
> 
> @@ -34,4 +28,4 @@ const int x = MODULE_MACRO;
>  // CHECKSH: "-D" "FOO=BAR"
>  // CHECKSH-NOT: "-fmodules-cache-path="
>  // CHECKSH: "crash-report-modules-{{[^ ]*}}.m"
> -// CHECKSH: "-ivfsoverlay" "crash-report-modules-{{[^
> ]*}}.cache/vfs/vfs.yaml"
> +// CHECKSH: "-ivfsoverlay" "crash-report-modules-{{[^
> ]*}}.cache{{(/|)}}vfs{{(/|)}}vfs.yaml"
> 
> Modified: cfe/trunk/test/Driver/crash-report-spaces.c
> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/crash-
> report-spaces.c?rev=334418&r1=334417&r2=334418&view=diff
> ===
> ===
> --- cfe/trunk/test/Driver/crash-report-spaces.c (original)
> +++ cfe/trunk/test/Driver/crash-report-spaces.c Mon Jun 11 09:50:07
> 2018
> @@ -6,9 +6,6 @@
>  // RUN: cat "%t/crash report spaces"-*.sh | FileCheck --check-
> prefix=CHECKSH "%s"
>  // REQUIRES: crash-recovery
> 
> -// because of the glob (*.c, *.sh)
> -// REQUIRES: shell
> -
>  #pragma clang __debug pars

RE: r334418 - Enable crash recovery tests on Windows, globs work in the lit internal shell now

[via cfe-commits]

Hi Reid,

Actually, it seems all four tests you changed are failing on one Windows bot 
http://lab.llvm.org:8011/builders/clang-x86-windows-msvc2015/builds/12464.

Can you please take a look and fix the tests?

Douglas Yung

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of via cfe-commits
> Sent: Monday, June 11, 2018 18:37
> To: r...@google.com
> Cc: cfe-commits@lists.llvm.org
> Subject: RE: r334418 - Enable crash recovery tests on Windows, globs
> work in the lit internal shell now
> 
> Hi Reid,
> 
> I don't know if you noticed, but one of the tests you changed with this
> commit is failing on the PS4 Windows bot. Can you take a look?
> 
> http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-
> windows10pro-fast/builds/17695/
> 
> FAIL: Clang :: Driver/crash-report-modules.m (7229 of 40862)
>  TEST 'Clang :: Driver/crash-report-modules.m'
> FAILED 
> Script:
> --
> : 'RUN: at line 1';   rm -rf C:\ps4-buildslave2\llvm-clang-lld-x86_64-
> scei-ps4-windows10pro-
> fast\llvm.obj\tools\clang\test\Driver\Output\crash-report-modules.m.tmp
> : 'RUN: at line 2';   mkdir -p C:\ps4-buildslave2\llvm-clang-lld-
> x86_64-scei-ps4-windows10pro-
> fast\llvm.obj\tools\clang\test\Driver\Output\crash-report-
> modules.m.tmp/i C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-
> windows10pro-fast\llvm.obj\tools\clang\test\Driver\Output\crash-report-
> modules.m.tmp/m C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-
> windows10pro-fast\llvm.obj\tools\clang\test\Driver\Output\crash-report-
> modules.m.tmp
> : 'RUN: at line 4';   not env FORCE_CLANG_DIAGNOSTICS_CRASH=
> TMPDIR=C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-
> fast\llvm.obj\tools\clang\test\Driver\Output\crash-report-modules.m.tmp
> TEMP=C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-
> fast\llvm.obj\tools\clang\test\Driver\Output\crash-report-modules.m.tmp
> TMP=C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-
> fast\llvm.obj\tools\clang\test\Driver\Output\crash-report-modules.m.tmp
> c:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-
> fast\llvm.obj\bin\clang.EXE -fsyntax-only C:\ps4-buildslave2\llvm-
> clang-lld-x86_64-scei-ps4-windows10pro-
> fast\llvm.src\tools\clang\test\Driver\crash-report-modules.m -I C:\ps4-
> buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-
> fast\llvm.src\tools\clang\test\Driver/Inputs/module -isysroot C:/ps4-
> buildslave2/llvm-clang-lld-x86_64-scei-ps4-windows10pro-
> fast/llvm.obj/tools/clang/test/Driver/Output/crash-report-
> modules.m.tmp/i/ -fmodules -fmodules-cache-path=C:\ps4-
> buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-
> fast\llvm.obj\tools\clang\test\Driver\Output\crash-report-
> modules.m.tmp/m/ -DFOO=BAR 2>&1 | C:\ps4-buildslave2\llvm-clang-lld-
> x86_64-scei-ps4-windows10pro-fast\llvm.obj\bin\FileCheck.EXE C:\ps4-
> buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-
> fast\llvm.src\tools\clang\test\Driver\crash-report-modules.m
> : 'RUN: at line 8';   C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-
> ps4-windows10pro-fast\llvm.obj\bin\FileCheck.EXE --check-
> prefix=CHECKSRC C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-
> windows10pro-fast\llvm.src\tools\clang\test\Driver\crash-report-
> modules.m -input-file C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-
> ps4-windows10pro-fast\llvm.obj\tools\clang\test\Driver\Output\crash-
> report-modules.m.tmp/crash-report-*.m
> : 'RUN: at line 9';   C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-
> ps4-windows10pro-fast\llvm.obj\bin\FileCheck.EXE --check-prefix=CHECKSH
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-
> fast\llvm.src\tools\clang\test\Driver\crash-report-modules.m -input-
> file C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-
> fast\llvm.obj\tools\clang\test\Driver\Output\crash-report-
> modules.m.tmp/crash-report-*.sh
> --
> Exit Code: 2
> 
> Command Output (stdout):
> --
> $ ":" "RUN: at line 1"
> $ "rm" "-rf" "C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-
> windows10pro-fast\llvm.obj\tools\clang\test\Driver\Output\crash-report-
> modules.m.tmp"
> $ ":" "RUN: at line 2"
> $ "mkdir" "-p" "C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-
> windows10pro-fast\llvm.obj\tools\clang\test\Driver\Output\crash-report-
> modules.m.tmp/i" "C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-
> windows10pro-fast\llvm.obj\tools\clang\test\Driver\Output\crash-report-
> modules.m.tmp/m" "C:\ps4-buildsla

RE: r335159 - Fixed test in prior build where FileCheck tried to match against

[via cfe-commits]

(Using the right commits list this time...)

See inline (same as previous).

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of
> Leonard Chan via cfe-commits
> Sent: Wednesday, June 20, 2018 3:34 PM
> To: cfe-commits@lists.llvm.org
> Subject: r335159 - Fixed test in prior build where FileCheck tried to
> match against
> 
> Author: leonardchan
> Date: Wed Jun 20 12:34:05 2018
> New Revision: 335159
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=335159&view=rev
> Log:
> Fixed test in prior build where FileCheck tried to match against
> `common` when declaring a global variable when we primarily care about
> the value assigned in the test.
> 
> Modified:
> cfe/trunk/test/Frontend/fixed_point_declarations.c
> 
> Modified: cfe/trunk/test/Frontend/fixed_point_declarations.c
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/test/Frontend/fixed_point_declarations.c?rev=335159&r1=3
> 35158&r2=335159&view=diff
> ==
> 
> --- cfe/trunk/test/Frontend/fixed_point_declarations.c (original)
> +++ cfe/trunk/test/Frontend/fixed_point_declarations.c Wed Jun 20 12:34:05
> 2018
> @@ -1,4 +1,4 @@
> -// RUN: %clang -ffixed-point -S -emit-llvm %s -o - | FileCheck %s
> +// RUN: %clang -ffixed-point -S -emit-llvm %s -o - --target=x86_64-linux
> | FileCheck %s
>  // RUN: %clang -ffixed-point -S -emit-llvm %s -o - --target=x86_64-scei-
> ps4-ubuntu-fast | FileCheck %s

By the way, "x86_64-scei-ps4-ubuntu-fast" is not a real triple.  The PS4
triple is "x86_64-scei-ps4" (although there is an ubuntu-fast bot, which
might be where the confusion arises).

Is there any particular reason to want to use the PS4 triple in addition
to Linux?  I haven't really been watching the fixed-point stuff.
Thanks,
--paulr
PS4 code owner

> 
>  // Primary fixed point types
> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Fix bug 26547

[via cfe-commits]

This is a patch to fix bug 26547
(https://bugs.llvm.org/show_bug.cgi?id=26547)

This is my first patch, so please give feedback! This should be correct
though, and I've tested it on both Windows x86 (where it does nothing), and
Linux x86 (where it correctly returns alignof(double) = 4, __alignof(double)
= 8).

I'm not sure where to put a unit test for this, and I'm also unsure how to
test for CPU and OS; as far as I know, it's only really an issue with x86
SysV's double.

---

diff --git a/include/clang/ASTMatchers/ASTMatchers.h
b/include/clang/ASTMatchers/ASTMatchers.h
index eb07ff70a9..3f8690bd8a 100644
--- a/include/clang/ASTMatchers/ASTMatchers.h
+++ b/include/clang/ASTMatchers/ASTMatchers.h
@@ -2425,8 +2425,9 @@ AST_MATCHER_P(UnaryExprOrTypeTraitExpr, ofKind,
UnaryExprOrTypeTrait, Kind) {
 /// alignof.
 inline internal::Matcher alignOfExpr(
 const internal::Matcher &InnerMatcher) {
-  return stmt(unaryExprOrTypeTraitExpr(allOf(
-  ofKind(UETT_AlignOf), InnerMatcher)));
+  return stmt(unaryExprOrTypeTraitExpr(
+  allOf(anyOf(ofKind(UETT_AlignOf), ofKind(UETT_PreferredAlignOf)),
+InnerMatcher)));
 }
 
 /// Same as unaryExprOrTypeTraitExpr, but only matching
diff --git a/include/clang/Basic/LangOptions.h
b/include/clang/Basic/LangOptions.h
index 30ee20395b..2ac4ae52e3 100644
--- a/include/clang/Basic/LangOptions.h
+++ b/include/clang/Basic/LangOptions.h
@@ -124,6 +124,13 @@ public:
 /// whether we reuse base class tail padding in some ABIs.
 Ver6,
 
+/// Attempt to be ABI-compatible with code generated by Clang 7.0.x
+/// (SVN r344257). This causes alignof (C++) and _Alignof (C11) to be
+/// compatible with __alignof (i.e., return the preferred alignment)
+/// rather than returning the required alignment.
+/// see https://bugs.llvm.org/show_bug.cgi?id=26547 for explanation
+Ver7,
+
 /// Conform to the underlying platform's C and C++ ABIs as closely
 /// as we can.
 Latest
@@ -273,8 +280,8 @@ public:
 /// Floating point control options
 class FPOptions {
 public:
-  FPOptions() : fp_contract(LangOptions::FPC_Off), 
-fenv_access(LangOptions::FEA_Off) {}
+  FPOptions()
+  : fp_contract(LangOptions::FPC_Off),
fenv_access(LangOptions::FEA_Off) {}
 
   // Used for serializing.
   explicit FPOptions(unsigned I)
@@ -319,7 +326,7 @@ public:
   unsigned getInt() const { return fp_contract | (fenv_access << 2); }
 
 private:
-  /// Adjust BinaryOperator::FPFeatures to match the total bit-field size 
+  /// Adjust BinaryOperator::FPFeatures to match the total bit-field size
   /// of these two.
   unsigned fp_contract : 2;
   unsigned fenv_access : 1;
diff --git a/include/clang/Basic/TypeTraits.h
b/include/clang/Basic/TypeTraits.h
index bdb426834a..e4e54d4822 100644
--- a/include/clang/Basic/TypeTraits.h
+++ b/include/clang/Basic/TypeTraits.h
@@ -96,6 +96,12 @@ namespace clang {
   /// Names for the "expression or type" traits.
   enum UnaryExprOrTypeTrait {
 UETT_SizeOf,
+// used for GCC's __alignof,
+UETT_PreferredAlignOf,
+// used for C's _Alignof and C++'s alignof
+// this distinction is important because __alignof
+// returns preferred alignment
+// _Alignof and alignof return the required alignment
 UETT_AlignOf,
 UETT_VecStep,
 UETT_OpenMPRequiredSimdAlign,
diff --git a/lib/AST/ASTDumper.cpp b/lib/AST/ASTDumper.cpp
index 38a2fe9caf..56592b8c65 100644
--- a/lib/AST/ASTDumper.cpp
+++ b/lib/AST/ASTDumper.cpp
@@ -2272,6 +2272,9 @@ void ASTDumper::VisitUnaryExprOrTypeTraitExpr(
   case UETT_SizeOf:
 OS << " sizeof";
 break;
+  case UETT_PreferredAlignOf:
+OS << " __alignof";
+break;
   case UETT_AlignOf:
 OS << " alignof";
 break;
diff --git a/lib/AST/Expr.cpp b/lib/AST/Expr.cpp
index 651981374d..7ff90f176f 100644
--- a/lib/AST/Expr.cpp
+++ b/lib/AST/Expr.cpp
@@ -1446,7 +1446,7 @@ UnaryExprOrTypeTraitExpr::UnaryExprOrTypeTraitExpr(
 
   // Check to see if we are in the situation where alignof(decl) should be
   // dependent because decl's alignment is dependent.
-  if (ExprKind == UETT_AlignOf) {
+  if (ExprKind == UETT_AlignOf || ExprKind == UETT_PreferredAlignOf) {
 if (!isValueDependent() || !isInstantiationDependent()) {
   E = E->IgnoreParens();
 
diff --git a/lib/AST/ExprConstant.cpp b/lib/AST/ExprConstant.cpp
index d2258cc212..4ed8198e60 100644
--- a/lib/AST/ExprConstant.cpp
+++ b/lib/AST/ExprConstant.cpp
@@ -5946,21 +5946,33 @@ bool PointerExprEvaluator::VisitCastExpr(const
CastExpr *E) {
   return ExprEvaluatorBaseTy::VisitCastExpr(E);
 }
 
-static CharUnits GetAlignOfType(EvalInfo &Info, QualType T) {
+static CharUnits GetAlignOfType(EvalInfo &Info, QualType T,
+bool PreferredAlignOf) {
   // C++ [expr.alignof]p3:
   // When alignof is applied to a reference type, the result is the
   // alignment of the referenced type.
   if (const ReferenceType *Ref = T->getAs())
 T = Ref->getPointeeType();
 
-  // __

RE: r344337 - Remove top-level using declaration from header files, as these aliases leak.

[via cfe-commits]

Hi Sam,

Your change is causing build failures on the PS4 Windows bot. Can you take a 
look?

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/20638
FAILED: tools/clang/lib/Driver/CMakeFiles/clangDriver.dir/Compilation.cpp.obj 
C:\PROGRA~2\MICROS~1.0\VC\bin\cl.exe  /nologo /TP -DGTEST_HAS_RTTI=0 -DUNICODE 
-D_CRT_NONSTDC_NO_DEPRECATE -D_CRT_NONSTDC_NO_WARNINGS 
-D_CRT_SECURE_NO_DEPRECATE -D_CRT_SECURE_NO_WARNINGS -D_FILE_OFFSET_BITS=64 
-D_GNU_SOURCE -D_HAS_EXCEPTIONS=0 -D_LARGEFILE_SOURCE 
-D_SCL_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_WARNINGS -D_UNICODE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-Itools\clang\lib\Driver 
-IC:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\lib\Driver
 
-IC:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\include
 -Itools\clang\include -Iinclude 
-IC:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\include
 /DWIN32 /D_WINDOWS   /Zc:inline /Zc:strictStrings /Oi /Zc:rvalueCast /W4 
-wd4141 -wd4146 -wd4180 -wd4244 -wd4258 -wd4267 -wd4291 -wd4345 -wd4351 -wd4355 
-wd4456 -wd4457 -wd4458 -wd4459 -wd4503 -wd4624 -wd4722 -wd4800 -wd4100 -wd4127 
-wd4512 -wd4505 -wd4610 -wd4510 -wd4702 -wd4245 -wd4706 -wd4310 -wd4701 -wd4703 
-wd4389 -wd4611 -wd4805 -wd4204 -wd4577 -wd4091 -wd4592 -wd4319 -wd4324 -w14062 
-we4238 /MD /O2 /Ob2   -UNDEBUG  /EHs-c- /GR- /showIncludes 
/Fotools\clang\lib\Driver\CMakeFiles\clangDriver.dir\Compilation.cpp.obj 
/Fdtools\clang\lib\Driver\CMakeFiles\clangDriver.dir\clangDriver.pdb /FS -c 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\lib\Driver\Compilation.cpp
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\lib\Driver\Compilation.cpp(130):
 error C2872: 'ArgStringList': ambiguous symbol
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\include\clang/Driver/Job.h(33):
 note: could be 'llvm::opt::ArgStringList clang::driver::ArgStringList'
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\include\llvm/Option/Option.h(31):
 note: or   'llvm::opt::ArgStringList'

Douglas Yung

-Original Message-
From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of Sam 
McCall via cfe-commits
Sent: Friday, October 12, 2018 5:22 AM
To: cfe-commits@lists.llvm.org
Subject: r344337 - Remove top-level using declaration from header files, as 
these aliases leak.

Author: sammccall
Date: Fri Oct 12 05:21:29 2018
New Revision: 344337

URL: http://llvm.org/viewvc/llvm-project?rev=344337&view=rev
Log:
Remove top-level using declaration from header files, as these aliases leak.

Reviewers: ilya-biryukov

Subscribers: arphaman, cfe-commits

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

Modified:
cfe/trunk/include/clang/Driver/Job.h
cfe/trunk/include/clang/Frontend/PCHContainerOperations.h
cfe/trunk/include/clang/Serialization/GlobalModuleIndex.h
cfe/trunk/lib/Frontend/FrontendAction.cpp

cfe/trunk/lib/StaticAnalyzer/Checkers/RetainCountChecker/RetainCountChecker.h
cfe/trunk/utils/TableGen/TableGenBackends.h

Modified: cfe/trunk/include/clang/Driver/Job.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Job.h?rev=344337&r1=344336&r2=344337&view=diff
==
--- cfe/trunk/include/clang/Driver/Job.h (original)
+++ cfe/trunk/include/clang/Driver/Job.h Fri Oct 12 05:21:29 2018
@@ -30,7 +30,7 @@ class InputInfo;
 class Tool;
 
 // Re-export this as clang::driver::ArgStringList.
-using llvm::opt::ArgStringList;
+using ArgStringList = llvm::opt::ArgStringList;
 
 struct CrashReportInfo {
   StringRef Filename;

Modified: cfe/trunk/include/clang/Frontend/PCHContainerOperations.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/PCHContainerOperations.h?rev=344337&r1=344336&r2=344337&view=diff
==
--- cfe/trunk/include/clang/Frontend/PCHContainerOperations.h (original)
+++ cfe/trunk/include/clang/Frontend/PCHContainerOperations.h Fri Oct 12 
+++ 05:21:29 2018
@@ -20,8 +20,6 @@ namespace llvm {
 class raw_pwrite_stream;
 }
 
-using llvm::StringRef;
-
 namespace clang {
 
 class ASTConsumer;
@@ -41,7 +39,7 @@ struct PCHBuffer {
 class PCHContainerWriter {
 public:
   virtual ~PCHContainerWriter() = 0;
-  virtual StringRef getFormat() const = 0;
+  virtual llvm::StringRef getFormat() const = 0;
 
   /// Return an ASTConsumer that can be chained with a
   /// PCHGenerator that produces a wrapper file format containing a @@ -61,15 
+59,15 @@ class PCHContainerReader {
 public:
   virtual ~PCHContainerReader() = 0;
   /// Equivalent to the format passed to -fmodule-format=
-

RE: [clang-tools-extra] r344513 - [clangd] Minimal implementation of automatic static index (not enabled).

[via cfe-commits]

Hi Sam,

The test you added in this commit is timing out when run on the PS4 Windows bot:

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/20724/steps/test/logs/stdio

command timed out: 1200 seconds without output running ['ninja', '-j', '36', 
'check-all'], attempting to kill
FAIL: Extra Tools Unit Tests :: 
clangd/./ClangdTests.exe/BackgroundIndexTest.IndexTwoFiles (44401 of 44401)
 TEST 'Extra Tools Unit Tests :: 
clangd/./ClangdTests.exe/BackgroundIndexTest.IndexTwoFiles' FAILED 

Note: Google Test filter = BackgroundIndexTest.IndexTwoFiles

[==] Running 1 test from 1 test case.

[--] Global test environment set-up.

[--] 1 test from BackgroundIndexTest

[ RUN  ] BackgroundIndexTest.IndexTwoFiles



program finished with exit code 1
elapsedTime=1446.10

Can you take a look?

Douglas Yung

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of Sam McCall via cfe-commits
> Sent: Monday, October 15, 2018 6:34
> To: cfe-commits@lists.llvm.org
> Subject: [clang-tools-extra] r344513 - [clangd] Minimal implementation
> of automatic static index (not enabled).
> 
> Author: sammccall
> Date: Mon Oct 15 06:34:10 2018
> New Revision: 344513
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=344513&view=rev
> Log:
> [clangd] Minimal implementation of automatic static index (not
> enabled).
> 
> Summary:
> See tinyurl.com/clangd-automatic-index for design and goals.
> 
> Lots of limitations to keep this patch smallish, TODOs everywhere:
>  - no serialization to disk
>  - no changes to dynamic index, which now has a much simpler job
>  - no partitioning of symbols by file to avoid duplication of header
> symbols
>  - no reindexing of edited files
>  - only a single worker thread
>  - compilation database is slurped synchronously (doesn't scale)
>  - uses memindex, rebuilds after every file (should be dex,
> periodically)
> 
> It's not hooked up to ClangdServer/ClangdLSPServer yet: the layering
> isn't clear (it should really be in ClangdServer, but ClangdLSPServer
> has all the CDB interactions).
> 
> Reviewers: ioeric
> 
> Subscribers: mgorny, ilya-biryukov, MaskRay, jkorous, arphaman,
> kadircet, jfb, cfe-commits
> 
> Differential Revision: https://reviews.llvm.org/D53032
> 
> Added:
> clang-tools-extra/trunk/clangd/index/Background.cpp
> clang-tools-extra/trunk/clangd/index/Background.h
> clang-tools-extra/trunk/unittests/clangd/BackgroundIndexTests.cpp
> Modified:
> clang-tools-extra/trunk/clangd/CMakeLists.txt
> clang-tools-extra/trunk/unittests/clangd/CMakeLists.txt
> clang-tools-extra/trunk/unittests/clangd/SyncAPI.cpp
> clang-tools-extra/trunk/unittests/clangd/SyncAPI.h
> 
> Modified: clang-tools-extra/trunk/clangd/CMakeLists.txt
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-
> extra/trunk/clangd/CMakeLists.txt?rev=344513&r1=344512&r2=344513&view=d
> iff
> ===
> ===
> --- clang-tools-extra/trunk/clangd/CMakeLists.txt (original)
> +++ clang-tools-extra/trunk/clangd/CMakeLists.txt Mon Oct 15 06:34:10
> 2018
> @@ -38,6 +38,7 @@ add_clang_library(clangDaemon
>URI.cpp
>XRefs.cpp
> 
> +  index/Background.cpp
>index/CanonicalIncludes.cpp
>index/FileIndex.cpp
>index/Index.cpp
> 
> Added: clang-tools-extra/trunk/clangd/index/Background.cpp
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-
> extra/trunk/clangd/index/Background.cpp?rev=344513&view=auto
> ===
> ===
> --- clang-tools-extra/trunk/clangd/index/Background.cpp (added)
> +++ clang-tools-extra/trunk/clangd/index/Background.cpp Mon Oct 15
> 06:34:10 2018
> @@ -0,0 +1,191 @@
> +//===-- Background.cpp - Build an index in a background thread ---
> -===//
> +//
> +// The LLVM Compiler Infrastructure
> +//
> +// This file is distributed under the University of Illinois Open
> Source
> +// License. See LICENSE.TXT for details.
> +//
> +//===-
> -===//
> +
> +#include "index/Background.h"
> +#include "ClangdUnit.h"
> +#include "Compiler.h"
> +#include "Logger.h"
> +#include "Trace.h"
> +#include "index/IndexAction.h"
> +#include "index/MemIndex.h"
> +#include "index/Serialization.h"
> +#include "llvm/Support/SHA1

RE: r345676 - [Win64] Handle passing i128 by value

[via cfe-commits]

Also, don't we usually put ABI changes under an ABI compatibility check?  This 
would be making Clang incompatible with itself.
--paulr

From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of 
Richard Trieu via cfe-commits
Sent: Tuesday, October 30, 2018 10:16 PM
To: Reid Kleckner
Cc: cfe-commits
Subject: Re: r345676 - [Win64] Handle passing i128 by value

I have reverted this in r345691 because it caused test 
CodeGen/mingw-long-double.c to start failing.

Command Output (stderr):
--
/usr/local/google/clang/install/llvm/tools/clang/test/CodeGen/mingw-long-double.c:36:11:
 error: MSC64: expected string not found in input
// MSC64: define dso_local double @TestLD(double %x)
  ^
:12:1: note: scanning from here
; Function Attrs: noinline nounwind optnone
^
:35:1: note: possible intended match here
define dso_local void @TestLDC({ double, double }* noalias sret %agg.result, { 
double, double }* %x) #2 {
^

--

I suspect your patch has changed the type of "double" to a different floating 
point type, causing the failure.


On Tue, Oct 30, 2018 at 5:00 PM Reid Kleckner via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: rnk
Date: Tue Oct 30 16:58:41 2018
New Revision: 345676

URL: http://llvm.org/viewvc/llvm-project?rev=345676&view=rev
Log:
[Win64] Handle passing i128 by value

For arguments, pass it indirectly, since the ABI doc says pretty clearly
that arguments larger than 8 bytes are passed indirectly. This makes
va_list handling easier, anyway.

When returning, GCC returns in XMM0, and we match them.

Fixes PR39492.

Added:
cfe/trunk/test/CodeGen/win64-i128.c
Modified:
cfe/trunk/lib/CodeGen/TargetInfo.cpp

Modified: cfe/trunk/lib/CodeGen/TargetInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/TargetInfo.cpp?rev=345676&r1=345675&r2=345676&view=diff
==
--- cfe/trunk/lib/CodeGen/TargetInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/TargetInfo.cpp Tue Oct 30 16:58:41 2018
@@ -3944,18 +3944,39 @@ ABIArgInfo WinX86_64ABIInfo::classify(Qu
 return ABIArgInfo::getDirect(llvm::IntegerType::get(getVMContext(), 
Width));
   }

-  // Bool type is always extended to the ABI, other builtin types are not
-  // extended.
-  const BuiltinType *BT = Ty->getAs();
-  if (BT && BT->getKind() == BuiltinType::Bool)
-return ABIArgInfo::getExtend(Ty);
-
-  // Mingw64 GCC uses the old 80 bit extended precision floating point unit. It
-  // passes them indirectly through memory.
-  if (IsMingw64 && BT && BT->getKind() == BuiltinType::LongDouble) {
-const llvm::fltSemantics *LDF = &getTarget().getLongDoubleFormat();
-if (LDF == &llvm::APFloat::x87DoubleExtended())
-  return ABIArgInfo::getIndirect(Align, /*ByVal=*/false);
+  if (const BuiltinType *BT = Ty->getAs()) {
+switch (BT->getKind()) {
+case BuiltinType::Bool:
+  // Bool type is always extended to the ABI, other builtin types are not
+  // extended.
+  return ABIArgInfo::getExtend(Ty);
+
+case BuiltinType::LongDouble:
+  // Mingw64 GCC uses the old 80 bit extended precision floating point
+  // unit. It passes them indirectly through memory.
+  if (IsMingw64) {
+const llvm::fltSemantics *LDF = &getTarget().getLongDoubleFormat();
+if (LDF == &llvm::APFloat::x87DoubleExtended())
+  return ABIArgInfo::getIndirect(Align, /*ByVal=*/false);
+break;
+  }
+
+case BuiltinType::Int128:
+case BuiltinType::UInt128:
+  // If it's a parameter type, the normal ABI rule is that arguments larger
+  // than 8 bytes are passed indirectly. GCC follows it. We follow it too,
+  // even though it isn't particularly efficient.
+  if (!IsReturnType)
+return ABIArgInfo::getIndirect(Align, /*ByVal=*/false);
+
+  // Mingw64 GCC returns i128 in XMM0. Coerce to v2i64 to handle that.
+  // Clang matches them for compatibility.
+  return ABIArgInfo::getDirect(
+  llvm::VectorType::get(llvm::Type::getInt64Ty(getVMContext()), 2));
+
+default:
+  break;
+}
   }

   return ABIArgInfo::getDirect();

Added: cfe/trunk/test/CodeGen/win64-i128.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/win64-i128.c?rev=345676&view=auto
==
--- cfe/trunk/test/CodeGen/win64-i128.c (added)
+++ cfe/trunk/test/CodeGen/win64-i128.c Tue Oct 30 16:58:41 2018
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -triple x86_64-windows-gnu -emit-llvm -o - %s \
+// RUN:| FileCheck %s --check-prefix=GNU64
+// RUN: %clang_cc1 -triple x86_64-windows-msvc -emit-llvm -o - %s \
+// RUN:| FileCheck %s --check-prefix=MSC64
+
+typedef int int128_t __attribute__((mode(TI)));
+
+int128_t foo() { return 0; }
+
+// GNU64: define dso_local <2 x i64> @foo()
+/

r346838 - [OpenCL] Fix invalid address space generation for clk_event_t

[via cfe-commits]

Author: AlexeySotkin
Date: Wed Nov 14 01:40:05 2018
New Revision: 346838

URL: http://llvm.org/viewvc/llvm-project?rev=346838&view=rev
Log:
[OpenCL] Fix invalid address space generation for clk_event_t

Summary:
Addrspace(32) was generated when putting 0 in clk_event_t * event_ret
parameter for enqueue_kernel function.

Patch by Viktoria Maksimova

Reviewers: Anastasia, yaxunl, AlexeySotkin

Reviewed By:  Anastasia, AlexeySotkin

Subscribers: cfe-commits

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

Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/test/CodeGenOpenCL/cl20-device-side-enqueue.cl

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=346838&r1=346837&r2=346838&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Wed Nov 14 01:40:05 2018
@@ -3610,7 +3610,9 @@ RValue CodeGenFunction::EmitBuiltinExpr(
   llvm::Value *ClkEvent = EmitScalarExpr(E->getArg(5));
   // Convert to generic address space.
   EventList = Builder.CreatePointerCast(EventList, EventPtrTy);
-  ClkEvent = Builder.CreatePointerCast(ClkEvent, EventPtrTy);
+  ClkEvent = ClkEvent->getType()->isIntegerTy()
+   ? Builder.CreateBitOrPointerCast(ClkEvent, EventPtrTy)
+   : Builder.CreatePointerCast(ClkEvent, EventPtrTy);
   auto Info =
   CGM.getOpenCLRuntime().emitOpenCLEnqueuedBlock(*this, E->getArg(6));
   llvm::Value *Kernel =

Modified: cfe/trunk/test/CodeGenOpenCL/cl20-device-side-enqueue.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCL/cl20-device-side-enqueue.cl?rev=346838&r1=346837&r2=346838&view=diff
==
--- cfe/trunk/test/CodeGenOpenCL/cl20-device-side-enqueue.cl (original)
+++ cfe/trunk/test/CodeGenOpenCL/cl20-device-side-enqueue.cl Wed Nov 14 
01:40:05 2018
@@ -106,6 +106,13 @@ kernel void device_side_enqueue(global i
a[i] = b[i];
  });
 
+  // COMMON-LABEL: call i32 @__enqueue_kernel_basic_events
+  // COMMON-SAME: (%opencl.queue_t{{.*}}* {{%[0-9]+}}, i32 {{%[0-9]+}}, 
%struct.ndrange_t* {{.*}}, i32 1, %opencl.clk_event_t{{.*}}* addrspace(4)* 
{{%[0-9]+}}, %opencl.clk_event_t{{.*}}* addrspace(4)* null,
+  enqueue_kernel(default_queue, flags, ndrange, 1, &event_wait_list, 0,
+ ^(void) {
+   return;
+ });
+
   // Emits global block literal [[BLG1]] and block kernel [[INVGK1]].
   // COMMON: [[DEF_Q:%[0-9]+]] = load %opencl.queue_t{{.*}}*, 
%opencl.queue_t{{.*}}** %default_queue
   // COMMON: [[FLAGS:%[0-9]+]] = load i32, i32* %flags
@@ -390,7 +397,7 @@ kernel void device_side_enqueue(global i
 // COMMON: define internal spir_kernel void [[INVGK5]](i8 addrspace(4)*{{.*}}, 
i8 addrspace(3)*{{.*}})
 // COMMON: define internal spir_kernel void [[INVGK6]](i8 addrspace(4)*, i8 
addrspace(3)*, i8 addrspace(3)*, i8 addrspace(3)*) #{{[0-9]+}} {
 // COMMON: entry:
-// COMMON:  call void @__device_side_enqueue_block_invoke_8(i8 addrspace(4)* 
%0, i8 addrspace(3)* %1, i8 addrspace(3)* %2, i8 addrspace(3)* %3)
+// COMMON:  call void @__device_side_enqueue_block_invoke_9(i8 addrspace(4)* 
%0, i8 addrspace(3)* %1, i8 addrspace(3)* %2, i8 addrspace(3)* %3)
 // COMMON:  ret void
 // COMMON: }
 // COMMON: define internal spir_kernel void [[INVGK7]](i8 addrspace(4)*{{.*}}, 
i8 addrspace(3)*{{.*}})


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

RE: r354843 - [CGDebugInfo] Set NonTrivial DIFlag to a c++ record if it's not trivial

[via cfe-commits]

Hi Aaron,
I think I am less clever than David, and it's not clear what the difference is 
between the two flags. In the review, Zach asked the question but I did not see 
a straight answer. What do these flags actually mean? What is the third state, 
with both flags off, implying not Trivial and not NonTrivial?  (At the very 
least it seems that the names could be improved.)
Thanks,
--paulr

From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of 
Aaron Smith via cfe-commits
Sent: Monday, March 04, 2019 6:22 PM
To: David Blaikie; Reid Kleckner; Adrian Prantl; Jonas Devlieghere
Cc: cfe-commits@lists.llvm.org
Subject: Re: r354843 - [CGDebugInfo] Set NonTrivial DIFlag to a c++ record if 
it's not trivial

Hi David, I can take a look at adding another test. Please read the code review 
which answers your question. A new flag is required. Thanks.


From: David Blaikie 
Sent: Tuesday, March 5, 2019 12:51:27 AM
To: Aaron Smith; Reid Kleckner; Adrian Prantl; Jonas Devlieghere
Cc: cfe-commits@lists.llvm.org
Subject: Re: r354843 - [CGDebugInfo] Set NonTrivial DIFlag to a c++ record if 
it's not trivial

Hi Aaron,

I don't see any mention of this in D44406 - so it might have been good to have 
a separate review for this (or included this in the review of D44406, which I 
think is possible with the monorepo).

Specifically - this change is missing test coverage (there should be a clang 
test that goes from C++ source code to LLVM IR & demonstrates the flag being 
emitted into the IR, etc).

Also - what's the reason the non-triviality can't be implied by the absence of 
the trivial flag? (or the other way around) - the flags seem redundant with one 
another.
On Mon, Feb 25, 2019 at 8:02 PM Aaron Smith via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: asmith
Date: Mon Feb 25 19:49:05 2019
New Revision: 354843

URL: 
http://llvm.org/viewvc/llvm-project?rev=354843&view=rev<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fllvm.org%2Fviewvc%2Fllvm-project%3Frev%3D354843%26view%3Drev&data=02%7C01%7Caaron.smith%40microsoft.com%7C9ee22645e4544a8a54a808d6a0b94a7a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636873115022346268&sdata=jkLruyBw16u7MYD8G0vjNH5BAmhJbUxWM0mGPctzhxE%3D&reserved=0>
Log:
[CGDebugInfo] Set NonTrivial DIFlag to a c++ record if it's not trivial

This goes with 
https://reviews.llvm.org/D44406<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD44406&data=02%7C01%7Caaron.smith%40microsoft.com%7C9ee22645e4544a8a54a808d6a0b94a7a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636873115022346268&sdata=YBPvy0l%2BVVCzPWSXB0VYUPRS2AVHOA6pGH0sKIfM6D4%3D&reserved=0>


Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=354843&r1=354842&r2=354843&view=diff<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fllvm.org%2Fviewvc%2Fllvm-project%2Fcfe%2Ftrunk%2Flib%2FCodeGen%2FCGDebugInfo.cpp%3Frev%3D354843%26r1%3D354842%26r2%3D354843%26view%3Ddiff&data=02%7C01%7Caaron.smith%40microsoft.com%7C9ee22645e4544a8a54a808d6a0b94a7a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636873115022356269&sdata=jkg1JEzzsmEyAfaBggFOy84iEVR%2Foqn0y%2Fj1ohXQcVk%3D&reserved=0>
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Mon Feb 25 19:49:05 2019
@@ -3031,6 +3031,8 @@ llvm::DICompositeType *CGDebugInfo::Crea
 // Record if a C++ record is trivial type.
 if (CXXRD->isTrivial())
   Flags |= llvm::DINode::FlagTrivial;
+else
+  Flags |= llvm::DINode::FlagNonTrivial;
   }

   llvm::DICompositeType *RealDecl = DBuilder.createReplaceableCompositeType(


___
cfe-commits mailing list
cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.llvm.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fcfe-commits&data=02%7C01%7Caaron.smith%40microsoft.com%7C9ee22645e4544a8a54a808d6a0b94a7a%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C1%7C636873115022366259&sdata=yJtEfwH0KXKsMScvooRpNZGXiLshTqIRIwOBSoVxUio%3D&reserved=0>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: r354843 - [CGDebugInfo] Set NonTrivial DIFlag to a c++ record if it's not trivial

[via cfe-commits]

Hi Aaron,
The additional tests tell me that every composite type is either Trivial or 
NonTrivial, which does not answer the question: Why do you need two flags? 
DIFlags are not a plentiful resource and we should be reluctant to use them up.
Thanks,
--paulr

From: Aaron Smith [mailto:aaron.sm...@microsoft.com]
Sent: Wednesday, March 13, 2019 4:05 PM
To: Robinson, Paul; dblai...@gmail.com; r...@google.com; apra...@apple.com; 
jdevliegh...@apple.com
Cc: cfe-commits@lists.llvm.org
Subject: Re: r354843 - [CGDebugInfo] Set NonTrivial DIFlag to a c++ record if 
it's not trivial

Hi Paul,

There are additional tests here that may answer your questions,
https://reviews.llvm.org/rGe8475f78e2634d5d348d7ad746efc1e6526e72f5

Aaron

From: "paul.robin...@sony.com" 
Date: Wednesday, March 13, 2019 at 12:49 PM
To: Aaron Smith , "dblai...@gmail.com" 
, "r...@google.com" , "apra...@apple.com" 
, "jdevliegh...@apple.com" 
Cc: "cfe-commits@lists.llvm.org" 
Subject: RE: r354843 - [CGDebugInfo] Set NonTrivial DIFlag to a c++ record if 
it's not trivial

Hi Aaron,
I think I am less clever than David, and it's not clear what the difference is 
between the two flags. In the review, Zach asked the question but I did not see 
a straight answer. What do these flags actually mean? What is the third state, 
with both flags off, implying not Trivial and not NonTrivial?  (At the very 
least it seems that the names could be improved.)
Thanks,
--paulr

From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of 
Aaron Smith via cfe-commits
Sent: Monday, March 04, 2019 6:22 PM
To: David Blaikie; Reid Kleckner; Adrian Prantl; Jonas Devlieghere
Cc: cfe-commits@lists.llvm.org
Subject: Re: r354843 - [CGDebugInfo] Set NonTrivial DIFlag to a c++ record if 
it's not trivial

Hi David, I can take a look at adding another test. Please read the code review 
which answers your question. A new flag is required. Thanks.


From: David Blaikie 
Sent: Tuesday, March 5, 2019 12:51:27 AM
To: Aaron Smith; Reid Kleckner; Adrian Prantl; Jonas Devlieghere
Cc: cfe-commits@lists.llvm.org
Subject: Re: r354843 - [CGDebugInfo] Set NonTrivial DIFlag to a c++ record if 
it's not trivial

Hi Aaron,

I don't see any mention of this in D44406 - so it might have been good to have 
a separate review for this (or included this in the review of D44406, which I 
think is possible with the monorepo).

Specifically - this change is missing test coverage (there should be a clang 
test that goes from C++ source code to LLVM IR & demonstrates the flag being 
emitted into the IR, etc).

Also - what's the reason the non-triviality can't be implied by the absence of 
the trivial flag? (or the other way around) - the flags seem redundant with one 
another.
On Mon, Feb 25, 2019 at 8:02 PM Aaron Smith via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: asmith
Date: Mon Feb 25 19:49:05 2019
New Revision: 354843

URL: 
http://llvm.org/viewvc/llvm-project?rev=354843&view=rev<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fllvm.org%2Fviewvc%2Fllvm-project%3Frev%3D354843%26view%3Drev&data=02%7C01%7Caaron.smith%40microsoft.com%7Ca81fbd6197e04e329a7708d6a7ecf4ce%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636881033496912406&sdata=lSb5rDLYvfn3Fx25%2FISjPJ1z6sUyvNHnlPBIUFM22aQ%3D&reserved=0>
Log:
[CGDebugInfo] Set NonTrivial DIFlag to a c++ record if it's not trivial

This goes with 
https://reviews.llvm.org/D44406<https://nam06.safelinks.protection.outlook.com/?url=https%3A%2F%2Freviews.llvm.org%2FD44406&data=02%7C01%7Caaron.smith%40microsoft.com%7Ca81fbd6197e04e329a7708d6a7ecf4ce%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636881033496912406&sdata=mJz7kzeqyH%2B5mAld8TA%2BELQ4ouBkVyr2opJyICfEM60%3D&reserved=0>


Modified:
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=354843&r1=354842&r2=354843&view=diff<https://nam06.safelinks.protection.outlook.com/?url=http%3A%2F%2Fllvm.org%2Fviewvc%2Fllvm-project%2Fcfe%2Ftrunk%2Flib%2FCodeGen%2FCGDebugInfo.cpp%3Frev%3D354843%26r1%3D354842%26r2%3D354843%26view%3Ddiff&data=02%7C01%7Caaron.smith%40microsoft.com%7Ca81fbd6197e04e329a7708d6a7ecf4ce%7C72f988bf86f141af91ab2d7cd011db47%7C1%7C0%7C636881033496922411&sdata=Y%2BVdpDTdlUcyZzPpcs4TMB3DQT7eAK%2F5ASLmWM%2Fg73A%3D&reserved=0>
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Mon Feb 25 19:49:05 2019
@@ -3031,6 +3031,8 @@ llvm::DICompositeType *CGDebugInfo::Crea
 // Record if a C++ record is trivial type.
 if (CXXRD->isTrivial())
   Flags |= llvm::DINode::FlagTrivial;
+else
+  

RE: [clang-tools-extra] r356565 - Reland r356547 after fixing the tests for Linux.

[via cfe-commits]

: annotate this
  ^
:1:1: note: scanning from here
Traceback (most recent call last):
^
:1:1: note: with expression "@LINE-2" equal to "16"
Traceback (most recent call last):
^
:2:175: note: possible intended match here
 File 
"/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/tools/extra/test/../test/../clang-tidy/tool/clang-tidy-diff.py",
 line 38, in 

            
  ^

--



Can you please take a look?

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of Zinovy Nis 
via cfe-commits
Sent: Wednesday, March 20, 2019 8:50
To: cfe-commits@lists.llvm.org
Subject: [clang-tools-extra] r356565 - Reland r356547 after fixing the tests 
for Linux.

Author: zinovy.nis
Date: Wed Mar 20 08:50:26 2019
New Revision: 356565

URL: http://llvm.org/viewvc/llvm-project?rev=356565&view=rev
Log:
Reland r356547 after fixing the tests for Linux.

[clang-tidy] Parallelize clang-tidy-diff.py

This patch has 2 rationales:

- large patches lead to long command lines and often cause max command line 
length restrictions imposed by OS;
- clang-tidy runs on modified files are independent and can be done in 
parallel, the same as done for run-clang-tidy.

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


Modified:
clang-tools-extra/trunk/clang-tidy/tool/clang-tidy-diff.py

Modified: clang-tools-extra/trunk/clang-tidy/tool/clang-tidy-diff.py
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/tool/clang-tidy-diff.py?rev=356565&r1=356564&r2=356565&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/tool/clang-tidy-diff.py (original)
+++ clang-tools-extra/trunk/clang-tidy/tool/clang-tidy-diff.py Wed Mar 
+++ 20 08:50:26 2019
@@ -24,10 +24,90 @@ Example usage for git/svn users:
 """
 
 import argparse
+import glob
 import json
+import multiprocessing
+import os
 import re
+import shutil
 import subprocess
 import sys
+import tempfile
+import threading
+import traceback
+import yaml
+
+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 timeout is not None:
+watchdog = threading.Timer(timeout, proc.kill)
+watchdog.start()
+
+  stdout, stderr = proc.communicate()
+
+  with lock:
+sys.stdout.write(stdout.decode('utf-8') + '\n')
+sys.stdout.flush()
+if stderr:
+  sys.stderr.write(stderr.decode('utf-8') + '\n')
+  sys.stderr.flush()
+except Exception as e:
+  with lock:
+sys.stderr.write('Failed: ' + str(e) + ': '.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 start_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 merge_replacement_files(tmpdir, mergefile):
+  """Merge all replacement files in a directory into a single file"""
+  # The fixes suggested by clang-tidy >= 4.0.0 are given under
+  # the top level key 'Diagnostics' in the output yaml files
+  mergekey = "Diagnostics"
+  merged = []
+  for replacefile in glob.iglob(os.path.join(tmpdir, '*.yaml')):
+content = yaml.safe_load(open(replacefile, 'r'))
+if not content:
+  continue # Skip empty files.
+merged.extend(content.get(mergekey, []))
+
+  if merged:
+# MainSourceFile: The key is required by the definition inside
+# include/clang/Tooling/ReplacementsYaml.h, but the value
+# is actually never used inside clang-apply-replacements,
+# so we set it to '' here.
+output = { 'MainSourceFile': '', mergekey: merged }
+with open(mergefile, 'w') as out:
+  yaml.safe_dump(output, out)
+  else:
+# Empty the file:
+open(mergefile, 'w').close()
 
 
 def main():
@@ -47,7 +127,10 @@ def main():
   r'.*\.(cpp|cc|c\+\+

RE: [clang-tools-extra] r356565 - Reland r356547 after fixing the tests for Linux.

[via cfe-commits]

Hi Zinovy,

I have reverted this change in r356630 in order to get the build bots back to 
green.

I was able to reproduce the issue locally on my machine, it appears that your 
use of “import yaml” is not part of the standard python distribution and so is 
not found.

Douglas Yung

From: cfe-commits  On Behalf Of Galina 
Kistanova via cfe-commits
Sent: Wednesday, March 20, 2019 14:03
To: Zinovy Nis 
Cc: cfe-commits 
Subject: Re: [clang-tools-extra] r356565 - Reland r356547 after fixing the 
tests for Linux.

Hello Zinovy,

This commit broke test on the next builder:
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/45557
. . .
Failing Tests (1):
Clang Tools :: clang-tidy/clang-tidy-diff.cpp

Please have a look?

Thanks

Galina


On Wed, Mar 20, 2019 at 8:49 AM Zinovy Nis via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: zinovy.nis
Date: Wed Mar 20 08:50:26 2019
New Revision: 356565

URL: http://llvm.org/viewvc/llvm-project?rev=356565&view=rev
Log:
Reland r356547 after fixing the tests for Linux.

[clang-tidy] Parallelize clang-tidy-diff.py

This patch has 2 rationales:

- large patches lead to long command lines and often cause max command line 
length restrictions imposed by OS;
- clang-tidy runs on modified files are independent and can be done in 
parallel, the same as done for run-clang-tidy.

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


Modified:
clang-tools-extra/trunk/clang-tidy/tool/clang-tidy-diff.py

Modified: clang-tools-extra/trunk/clang-tidy/tool/clang-tidy-diff.py
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/tool/clang-tidy-diff.py?rev=356565&r1=356564&r2=356565&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/tool/clang-tidy-diff.py (original)
+++ clang-tools-extra/trunk/clang-tidy/tool/clang-tidy-diff.py Wed Mar 20 
08:50:26 2019
@@ -24,10 +24,90 @@ Example usage for git/svn users:
 """

 import argparse
+import glob
 import json
+import multiprocessing
+import os
 import re
+import shutil
 import subprocess
 import sys
+import tempfile
+import threading
+import traceback
+import yaml
+
+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 timeout is not None:
+watchdog = threading.Timer(timeout, proc.kill)
+watchdog.start()
+
+  stdout, stderr = proc.communicate()
+
+  with lock:
+sys.stdout.write(stdout.decode('utf-8') + '\n')
+sys.stdout.flush()
+if stderr:
+  sys.stderr.write(stderr.decode('utf-8') + '\n')
+  sys.stderr.flush()
+except Exception as e:
+  with lock:
+sys.stderr.write('Failed: ' + str(e) + ': '.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 start_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 merge_replacement_files(tmpdir, mergefile):
+  """Merge all replacement files in a directory into a single file"""
+  # The fixes suggested by clang-tidy >= 4.0.0 are given under
+  # the top level key 'Diagnostics' in the output yaml files
+  mergekey = "Diagnostics"
+  merged = []
+  for replacefile in glob.iglob(os.path.join(tmpdir, '*.yaml')):
+content = yaml.safe_load(open(replacefile, 'r'))
+if not content:
+  continue # Skip empty files.
+merged.extend(content.get(mergekey, []))
+
+  if merged:
+# MainSourceFile: The key is required by the definition inside
+# include/clang/Tooling/ReplacementsYaml.h, but the value
+# is actually never used inside clang-apply-replacements,
+# so we set it to '' here.
+output = { 'MainSourceFile': '', mergekey: merged }
+with open(mergefile, 'w') as out:
+  yaml.safe_dump(output, out)
+  else:
+# Empty the file:
+open(mergefile, 'w').close()


 def main():
@@ -47,7 +127,10 @@ def main():
   r'.*\.(cpp|cc|c\+\+|cxx|c|cl|h|hpp|m|mm|inc)',

RE: [clang-tools-extra] r356849 - [pp-trace] Modernize the code

[via cfe-commits]

:Error::Error'
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\include\llvm/Support/Error.h(157):
 note: see declaration of 'llvm::Error'

Can you take a look?

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of Fangrui 
Song via cfe-commits
Sent: Saturday, March 23, 2019 23:55
To: cfe-commits@lists.llvm.org
Subject: [clang-tools-extra] r356849 - [pp-trace] Modernize the code

Author: maskray
Date: Sat Mar 23 23:55:08 2019
New Revision: 356849

URL: http://llvm.org/viewvc/llvm-project?rev=356849&view=rev
Log:
[pp-trace] Modernize the code

Use InitLLVM and WithColor
Delete PPTraceConsumer, add the callback in PPTraceAction Migrae to 
tooling::createExecutorFromCommandLineArgs
Don't specialize empty OutputFileName

Modified:
clang-tools-extra/trunk/pp-trace/PPTrace.cpp
clang-tools-extra/trunk/test/pp-trace/pp-trace-conditional.cpp
clang-tools-extra/trunk/test/pp-trace/pp-trace-filter.cpp
clang-tools-extra/trunk/test/pp-trace/pp-trace-ident.cpp
clang-tools-extra/trunk/test/pp-trace/pp-trace-include.cpp
clang-tools-extra/trunk/test/pp-trace/pp-trace-macro.cpp
clang-tools-extra/trunk/test/pp-trace/pp-trace-modules.cpp
clang-tools-extra/trunk/test/pp-trace/pp-trace-pragma-general.cpp
clang-tools-extra/trunk/test/pp-trace/pp-trace-pragma-ms.cpp
clang-tools-extra/trunk/test/pp-trace/pp-trace-pragma-opencl.cpp

Modified: clang-tools-extra/trunk/pp-trace/PPTrace.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/pp-trace/PPTrace.cpp?rev=356849&r1=356848&r2=356849&view=diff
==
--- clang-tools-extra/trunk/pp-trace/PPTrace.cpp (original)
+++ clang-tools-extra/trunk/pp-trace/PPTrace.cpp Sat Mar 23 23:55:08 
+++ 2019
@@ -34,6 +34,7 @@
 #include "clang/Frontend/FrontendActions.h"
 #include "clang/Lex/Preprocessor.h"
 #include "clang/Tooling/CompilationDatabase.h"
+#include "clang/Tooling/Execution.h"
 #include "clang/Tooling/Tooling.h"
 #include "llvm/Option/Arg.h"
 #include "llvm/Option/ArgList.h"
@@ -42,6 +43,7 @@
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/GlobPattern.h"
+#include "llvm/Support/InitLLVM.h"
 #include "llvm/Support/MemoryBuffer.h"
 #include "llvm/Support/Path.h"
 #include "llvm/Support/ToolOutputFile.h"
@@ -56,108 +58,79 @@ using namespace clang;  using namespace clang::tooling;  
using namespace llvm;
 
-// Options:
-
-// Collect the source files.
-static cl::list SourcePaths(cl::Positional,
- cl::desc(" [... ]"),
- cl::OneOrMore);
+static cl::OptionCategory Cat("pp-trace options");
 
 static cl::opt Callbacks(
 "callbacks", cl::init("*"),
 cl::desc("Comma-separated list of globs describing the list of callbacks "
  "to output. Globs are processed in order of appearance. Globs "
  "with the '-' prefix remove callbacks from the set. e.g. "
- "'*,-Macro*'."));
+ "'*,-Macro*'."),
+cl::cat(Cat));
 
-// Option to specify the trace output file name.
 static cl::opt OutputFileName(
-"output", cl::init(""),
-cl::desc("Output trace to the given file name or '-' for stdout."));
-
-// Collect all other arguments, which will be passed to the front end.
-static cl::list
-CC1Arguments(cl::ConsumeAfter,
- cl::desc("..."));
-
-// Frontend action stuff:
+"output", cl::init("-"),
+cl::desc("Output trace to the given file name or '-' for stdout."),
+cl::cat(Cat));
+
+LLVM_ATTRIBUTE_NORETURN static void error(Twine Message) {
+  WithColor::error() << Message << '\n';
+  exit(1);
+}
 
 namespace {
-// Consumer is responsible for setting up the callbacks.
-class PPTraceConsumer : public ASTConsumer {
-public:
-  PPTraceConsumer(const FilterType &Filters,
-  std::vector &CallbackCalls, Preprocessor &PP) {
-// PP takes ownership.
-PP.addPPCallbacks(
-llvm::make_unique(Filters, CallbackCalls, PP));
-  }
-};
 
-class PPTraceAction : public SyntaxOnlyAction {
+class PPTraceAction : public ASTFrontendAction {
 public:
-  PPTraceAction(const FilterType &Filters,
-std::vector &CallbackCalls)
-  : Filters(Filters), CallbackCalls(CallbackCalls) {}
+  PPTraceAction(const FilterType &Filters, raw_ostream &OS)
+  : Filters(Filters), OS(OS) {}
 
 protected:
   std::unique_ptr
   CreateASTConsumer(CompilerInstance &CI, StringRef InFile) ov

RE: [clang-tools-extra] r356849 - [pp-trace] Modernize the code

[via cfe-commits]

ionFactory,FilterType&,llvm::raw_fd_ostream&,0>(FilterType
>  &,llvm::raw_fd_ostream &)' [found using argument-dependent lookup]
> with
> [
> _Ty=`anonymous-namespace'::PPTraceFrontendActionFactory
> ]
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\pp-trace\PPTrace.cpp(155):
>  note: while trying to match the argument list '(FilterType, 
> llvm::raw_fd_ostream)'
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\pp-trace\PPTrace.cpp(155):
>  error C2248: 'llvm::Error::Error': cannot access protected member declared 
> in class 'llvm::Error'
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\include\llvm/Support/Error.h(176):
>  note: see declaration of 'llvm::Error::Error'
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\include\llvm/Support/Error.h(157):
>  note: see declaration of 'llvm::Error'
>
> Can you take a look?
>
> Douglas Yung
>
> -Original Message-
> From: cfe-commits  On Behalf Of 
> Fangrui Song via cfe-commits
> Sent: Saturday, March 23, 2019 23:55
> To: cfe-commits@lists.llvm.org
> Subject: [clang-tools-extra] r356849 - [pp-trace] Modernize the code
>
> Author: maskray
> Date: Sat Mar 23 23:55:08 2019
> New Revision: 356849
>
> URL: http://llvm.org/viewvc/llvm-project?rev=356849&view=rev
> Log:
> [pp-trace] Modernize the code
>
> Use InitLLVM and WithColor
> Delete PPTraceConsumer, add the callback in PPTraceAction Migrae to 
> tooling::createExecutorFromCommandLineArgs
> Don't specialize empty OutputFileName
>
> Modified:
> clang-tools-extra/trunk/pp-trace/PPTrace.cpp
> clang-tools-extra/trunk/test/pp-trace/pp-trace-conditional.cpp
> clang-tools-extra/trunk/test/pp-trace/pp-trace-filter.cpp
> clang-tools-extra/trunk/test/pp-trace/pp-trace-ident.cpp
> clang-tools-extra/trunk/test/pp-trace/pp-trace-include.cpp
> clang-tools-extra/trunk/test/pp-trace/pp-trace-macro.cpp
> clang-tools-extra/trunk/test/pp-trace/pp-trace-modules.cpp
> clang-tools-extra/trunk/test/pp-trace/pp-trace-pragma-general.cpp
> clang-tools-extra/trunk/test/pp-trace/pp-trace-pragma-ms.cpp
> clang-tools-extra/trunk/test/pp-trace/pp-trace-pragma-opencl.cpp
>
> Modified: clang-tools-extra/trunk/pp-trace/PPTrace.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/pp-trace/P
> PTrace.cpp?rev=356849&r1=356848&r2=356849&view=diff
> ==
> 
> --- clang-tools-extra/trunk/pp-trace/PPTrace.cpp (original)
> +++ clang-tools-extra/trunk/pp-trace/PPTrace.cpp Sat Mar 23 23:55:08
> +++ 2019
> @@ -34,6 +34,7 @@
>  #include "clang/Frontend/FrontendActions.h"
>  #include "clang/Lex/Preprocessor.h"
>  #include "clang/Tooling/CompilationDatabase.h"
> +#include "clang/Tooling/Execution.h"
>  #include "clang/Tooling/Tooling.h"
>  #include "llvm/Option/Arg.h"
>  #include "llvm/Option/ArgList.h"
> @@ -42,6 +43,7 @@
>  #include "llvm/Support/CommandLine.h"
>  #include "llvm/Support/FileSystem.h"
>  #include "llvm/Support/GlobPattern.h"
> +#include "llvm/Support/InitLLVM.h"
>  #include "llvm/Support/MemoryBuffer.h"
>  #include "llvm/Support/Path.h"
>  #include "llvm/Support/ToolOutputFile.h"
> @@ -56,108 +58,79 @@ using namespace clang;  using namespace 
> clang::tooling;  using namespace llvm;
>
> -// Options:
> -
> -// Collect the source files.
> -static cl::list SourcePaths(cl::Positional,
> - cl::desc(" [... 
> ]"),
> - cl::OneOrMore);
> +static cl::OptionCategory Cat("pp-trace options");
>
>  static cl::opt Callbacks(
>  "callbacks", cl::init("*"),
>  cl::desc("Comma-separated list of globs describing the list of callbacks 
> "
>   "to output. Globs are processed in order of appearance. Globs "
>   "with the '-' prefix remove callbacks from the set. e.g. "
> - "'*,-Macro*'."));
> + "'*,-Macro*'."),
> +cl::cat(Cat));
>
> -// Option to specify the trace output file name.
>  static cl::opt OutputFileName(
> -"output", cl::init(""),
> -cl::desc("Output trace to the give

RE: [clang-tools-extra] r358103 - clangd: fix the build with XPC

[via cfe-commits]

Hi Saleem,

This fix does not seem to work on the PS4 linux build bot. Can you take a look?

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/46575

FAILED: 
tools/clang/tools/extra/clangd/fuzzer/CMakeFiles/clangd-fuzzer.dir/clangd-fuzzer.cpp.o
 
/usr/bin/clang++  -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE 
-D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-Itools/clang/tools/extra/clangd/fuzzer 
-I/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/tools/extra/clangd/fuzzer
 
-I/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/include
 -Itools/clang/include -Iinclude 
-I/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/include
 
-I/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/tools/extra/clangd/fuzzer/..
 -std=c++11 -Wdocumentation -Wno-documentation-deprecated-sync -fPIC 
-fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -std=c++11 -Wall -Wextra 
-Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers 
-pedantic -Wno-long-long -Wimplicit-fallthrough -Wcovered-switch-default 
-Wno-noexcept-type -Wnon-virtual-dtor -Wdelete-non-virtual-dtor 
-Wstring-conversion -fdiagnostics-color -ffunction-sections -fdata-sections 
-fno-common -Woverloaded-virtual -Wno-nested-anon-types -O3-UNDEBUG  
-fno-exceptions -fno-rtti -MD -MT 
tools/clang/tools/extra/clangd/fuzzer/CMakeFiles/clangd-fuzzer.dir/clangd-fuzzer.cpp.o
 -MF 
tools/clang/tools/extra/clangd/fuzzer/CMakeFiles/clangd-fuzzer.dir/clangd-fuzzer.cpp.o.d
 -o 
tools/clang/tools/extra/clangd/fuzzer/CMakeFiles/clangd-fuzzer.dir/clangd-fuzzer.cpp.o
 -c 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/tools/extra/clangd/fuzzer/clangd-fuzzer.cpp
In file included from 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/tools/extra/clangd/fuzzer/clangd-fuzzer.cpp:15:
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/tools/extra/clangd/fuzzer/../ClangdLSPServer.h:14:10:
 fatal error: 'Features.inc' file not found
#include "Features.inc"
 ^~

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of Saleem 
Abdulrasool via cfe-commits
Sent: Wednesday, April 10, 2019 9:49
To: cfe-commits@lists.llvm.org
Subject: [clang-tools-extra] r358103 - clangd: fix the build with XPC

Author: compnerd
Date: Wed Apr 10 09:48:52 2019
New Revision: 358103

URL: http://llvm.org/viewvc/llvm-project?rev=358103&view=rev
Log:
clangd: fix the build with XPC

`Transport.h` does not include `Features.inc`.  However, since it is used in a 
subdirectory, it cannot directly include the header as it is not available.
Include `Features.inc` in `ClangdLSPServer.h` prior to the inclusion of 
`Transport.h` which will provide the interfaces in `ClangdMain.cpp` where the 
symbol `newXPCTransport` will not be defined due to it being preprocessed away 
since the configuration is not passed along to the initial inclusion.

Modified:
clang-tools-extra/trunk/clangd/ClangdLSPServer.h

Modified: clang-tools-extra/trunk/clangd/ClangdLSPServer.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdLSPServer.h?rev=358103&r1=358102&r2=358103&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdLSPServer.h (original)
+++ clang-tools-extra/trunk/clangd/ClangdLSPServer.h Wed Apr 10 09:48:52 
+++ 2019
@@ -11,6 +11,7 @@
 
 #include "ClangdServer.h"
 #include "DraftStore.h"
+#include "Features.inc"
 #include "FindSymbols.h"
 #include "GlobalCompilationDatabase.h"
 #include "Path.h"


___
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: r358104 - Don't emit an unreachable return block.

[via cfe-commits]

Hi, 
This commit seems to be causing a test failure on several buildbots (e.g. 
http://lab.llvm.org:8011/builders/clang-ppc64be-linux-lnt/builds/26305). 
instrprof-shared-gcov-flush.test is failing because of differences in profile 
info. The test passes when I revert your change, so perhaps it's just a case of 
updating the test.
Could you please take a look? 

Thanks,
Wolfgang Pieb

-Original Message-
From: cfe-commits  On Behalf Of John McCall 
via cfe-commits
Sent: Wednesday, April 10, 2019 10:03 AM
To: cfe-commits@lists.llvm.org
Subject: r358104 - Don't emit an unreachable return block.

Author: rjmccall
Date: Wed Apr 10 10:03:09 2019
New Revision: 358104

URL: http://llvm.org/viewvc/llvm-project?rev=358104&view=rev
Log:
Don't emit an unreachable return block.

Patch by Brad Moody.

Added:
cfe/trunk/test/CodeGen/unreachable-ret.c
Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
cfe/trunk/test/OpenMP/parallel_reduction_codegen.cpp

Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=358104&r1=358103&r2=358104&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Wed Apr 10 10:03:09 2019
@@ -2873,15 +2873,6 @@ void CodeGenFunction::EmitFunctionEpilog
 RV = SI->getValueOperand();
 SI->eraseFromParent();
 
-// If that was the only use of the return value, nuke it as well now.
-auto returnValueInst = ReturnValue.getPointer();
-if (returnValueInst->use_empty()) {
-  if (auto alloca = dyn_cast(returnValueInst)) {
-alloca->eraseFromParent();
-ReturnValue = Address::invalid();
-  }
-}
-
   // Otherwise, we have to do a simple load.
   } else {
 RV = Builder.CreateLoad(ReturnValue);

Modified: cfe/trunk/lib/CodeGen/CodeGenFunction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenFunction.cpp?rev=358104&r1=358103&r2=358104&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenFunction.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenFunction.cpp Wed Apr 10 10:03:09 2019
@@ -255,6 +255,7 @@ llvm::DebugLoc CodeGenFunction::EmitRetu
 if (CurBB->empty() || ReturnBlock.getBlock()->use_empty()) {
   ReturnBlock.getBlock()->replaceAllUsesWith(CurBB);
   delete ReturnBlock.getBlock();
+  ReturnBlock = JumpDest();
 } else
   EmitBlock(ReturnBlock.getBlock());
 return llvm::DebugLoc();
@@ -274,6 +275,7 @@ llvm::DebugLoc CodeGenFunction::EmitRetu
   Builder.SetInsertPoint(BI->getParent());
   BI->eraseFromParent();
   delete ReturnBlock.getBlock();
+  ReturnBlock = JumpDest();
   return Loc;
 }
   }
@@ -448,6 +450,19 @@ void CodeGenFunction::FinishFunction(Sou
   // 5. Width of vector aguments and return types for functions called by this
   //function.
   CurFn->addFnAttr("min-legal-vector-width", llvm::utostr(LargestVectorWidth));
+
+  // If we generated an unreachable return block, delete it now.
+  if (ReturnBlock.isValid() && ReturnBlock.getBlock()->use_empty()) {
+Builder.ClearInsertionPoint();
+ReturnBlock.getBlock()->eraseFromParent();
+  }
+  if (ReturnValue.isValid()) {
+auto *RetAlloca = dyn_cast(ReturnValue.getPointer());
+if (RetAlloca && RetAlloca->use_empty()) {
+  RetAlloca->eraseFromParent();
+  ReturnValue = Address::invalid();
+}
+  }
 }
 
 /// ShouldInstrumentFunction - Return true if the current function should be

Added: cfe/trunk/test/CodeGen/unreachable-ret.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/unreachable-ret.c?rev=358104&view=auto
==
--- cfe/trunk/test/CodeGen/unreachable-ret.c (added)
+++ cfe/trunk/test/CodeGen/unreachable-ret.c Wed Apr 10 10:03:09 2019
@@ -0,0 +1,23 @@
+// RUN: %clang_cc1 -emit-llvm -o - %s | FileCheck %s
+
+extern void abort() __attribute__((noreturn));
+
+void f1() {
+  abort();
+}
+// CHECK-LABEL: define void @f1()
+// CHECK-NEXT: entry:
+// CHECK-NEXT:   call void @abort()
+// CHECK-NEXT:   unreachable
+// CHECK-NEXT: }
+
+void *f2() {
+  abort();
+  return 0;
+}
+// CHECK-LABEL: define i8* @f2()
+// CHECK-NEXT: entry:
+// CHECK-NEXT:   call void @abort()
+// CHECK-NEXT:   unreachable
+// CHECK-NEXT: }
+

Modified: cfe/trunk/test/OpenMP/parallel_reduction_codegen.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/parallel_reduction_codegen.cpp?rev=358104&r1=358103&r2=358104&view=diff
==
--- cfe/trunk/test/OpenMP/parallel_reduction

RE: r357877 - [clang-format] Fix bug https://bugs.llvm.org/show_bug.cgi?id=41413

[via cfe-commits]

Hi Owen,

FYI, putting a URL in the headline of the commit message takes up
space and doesn't really describe the fix to a casual reader. The
subject line of your Phabricator review looks like it would have
been perfectly fine to use for the commit as well.

Citing the bug in the body of the commit message is enough to let
people track down the original report, although even there we usually 
abbreviate it to 'PR' (so PR41413 in this example).

Thanks!
--paulr

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of
> Owen Pan via cfe-commits
> Sent: Sunday, April 07, 2019 5:06 PM
> To: cfe-commits@lists.llvm.org
> Subject: r357877 - [clang-format] Fix bug
> https://bugs.llvm.org/show_bug.cgi?id=41413
> 
> Author: owenpan
> Date: Sun Apr  7 14:05:52 2019
> New Revision: 357877
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=357877&view=rev
> Log:
> [clang-format] Fix bug https://bugs.llvm.org/show_bug.cgi?id=41413
> 
> Differential Revision: https://reviews.llvm.org/D60374
> 
> Modified:
> cfe/trunk/lib/Format/ContinuationIndenter.cpp
> cfe/trunk/unittests/Format/FormatTest.cpp
> 
> Modified: cfe/trunk/lib/Format/ContinuationIndenter.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/Format/ContinuationIndenter.cpp?rev=357877&r1=357876
> &r2=357877&view=diff
> ==
> 
> --- cfe/trunk/lib/Format/ContinuationIndenter.cpp (original)
> +++ cfe/trunk/lib/Format/ContinuationIndenter.cpp Sun Apr  7 14:05:52 2019
> @@ -945,18 +945,24 @@ unsigned ContinuationIndenter::getNewLin
>return State.Stack[State.Stack.size() - 2].LastSpace;
>  return State.FirstIndent;
>}
> -  // Indent a closing parenthesis at the previous level if followed by a
> semi or
> -  // opening brace. This allows indentations such as:
> +  // Indent a closing parenthesis at the previous level if followed by a
> semi,
> +  // const, or opening brace. This allows indentations such as:
>// foo(
>//   a,
>// );
> +  // int Foo::getter(
> +  // //
> +  // ) const {
> +  //   return foo;
> +  // }
>// function foo(
>//   a,
>// ) {
>//   code(); //
>// }
>if (Current.is(tok::r_paren) && State.Stack.size() > 1 &&
> -  (!Current.Next || Current.Next->isOneOf(tok::semi, tok::l_brace)))
> +  (!Current.Next ||
> +   Current.Next->isOneOf(tok::semi, tok::kw_const, tok::l_brace)))
>  return State.Stack[State.Stack.size() - 2].LastSpace;
>if (NextNonComment->is(TT_TemplateString) && NextNonComment-
> >closesScope())
>  return State.Stack[State.Stack.size() - 2].LastSpace;
> 
> Modified: cfe/trunk/unittests/Format/FormatTest.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=357877&r1=357876&r2=
> 357877&view=diff
> ==
> 
> --- cfe/trunk/unittests/Format/FormatTest.cpp (original)
> +++ cfe/trunk/unittests/Format/FormatTest.cpp Sun Apr  7 14:05:52 2019
> @@ -12822,6 +12822,24 @@ TEST_F(FormatTest, ConfigurableContinuat
>  format("int i = longFunction(arg);", SixIndent));
>  }
> 
> +TEST_F(FormatTest, WrappedClosingParenthesisIndent) {
> +  FormatStyle Style = getLLVMStyle();
> +  verifyFormat(
> +  "int Foo::getter(\n"
> +  "//\n"
> +  ") const {\n"
> +  "  return foo;\n"
> +  "}",
> +  Style);
> +  verifyFormat(
> +  "void Foo::setter(\n"
> +  "//\n"
> +  ") {\n"
> +  "  foo = 1;\n"
> +  "}",
> +  Style);
> +}
> +
>  TEST_F(FormatTest, SpacesInAngles) {
>FormatStyle Spaces = getLLVMStyle();
>Spaces.SpacesInAngles = true;
> 
> 
> ___
> 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: r358355 - [c++20] Enable driver and frontend support for building and using

[via cfe-commits]

Hi Richard,

The driver test you added (modules.cpp) seems to fail if the compiler 
configuration uses an external assembler. Is there any way that the test can be 
rewritten so that it works with both the integrated and an external assembler 
configurations?

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of Richard 
Smith via cfe-commits
Sent: Sunday, April 14, 2019 4:12
To: cfe-commits@lists.llvm.org
Subject: r358355 - [c++20] Enable driver and frontend support for building and 
using

Author: rsmith
Date: Sun Apr 14 04:11:37 2019
New Revision: 358355

URL: http://llvm.org/viewvc/llvm-project?rev=358355&view=rev
Log:
[c++20] Enable driver and frontend support for building and using modules when 
-std=c++2a is specified.

Added:
cfe/trunk/test/CXX/module/module.unit/p8.cpp
cfe/trunk/test/Driver/modules.cpp
Modified:
cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/lib/Frontend/FrontendActions.cpp
cfe/trunk/lib/Parse/Parser.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=358355&r1=358354&r2=358355&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Sun Apr 14 
+++ 04:11:37 2019
@@ -173,10 +173,11 @@ def note_incompatible_analyzer_plugin_ap
 
 def err_module_build_requires_fmodules : Error<
   "module compilation requires '-fmodules'">; -def 
err_module_interface_requires_modules_ts : Error<
-  "module interface compilation requires '-fmodules-ts'">;
+def err_module_interface_requires_cpp_modules : Error<
+  "module interface compilation requires '-std=c++2a' or 
+'-fmodules-ts'">;
 def err_header_module_requires_modules : Error<
-  "header module compilation requires '-fmodules' or '-fmodules-ts'">;
+  "header module compilation requires '-fmodules', '-std=c++2a', or "
+  "'-fmodules-ts'">;
 def warn_module_config_mismatch : Warning<
   "module file %0 cannot be loaded due to a configuration mismatch with the 
current "
   "compilation">, InGroup>, 
DefaultError;

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=358355&r1=358354&r2=358355&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Sun Apr 14 04:11:37 2019
@@ -2721,7 +2721,7 @@ static void RenderModulesOptions(Compila
 }
   }
 
-  HaveModules = HaveClangModules;
+  HaveModules |= HaveClangModules;
   if (Args.hasArg(options::OPT_fmodules_ts)) {
 CmdArgs.push_back("-fmodules-ts");
 HaveModules = true;
@@ -4259,7 +4259,8 @@ void Clang::ConstructJob(Compilation &C,
   // If a std is supplied, only add -trigraphs if it follows the
   // option.
   bool ImplyVCPPCXXVer = false;
-  if (Arg *Std = Args.getLastArg(options::OPT_std_EQ, options::OPT_ansi)) {
+  const Arg *Std = Args.getLastArg(options::OPT_std_EQ, 
+ options::OPT_ansi);  if (Std) {
 if (Std->getOption().matches(options::OPT_ansi))
   if (types::isCXX(InputType))
 CmdArgs.push_back("-std=c++98"); @@ -4696,9 +4697,6 @@ void 
Clang::ConstructJob(Compilation &C,
   Args.AddLastArg(CmdArgs, options::OPT_fdouble_square_bracket_attributes,
   options::OPT_fno_double_square_bracket_attributes);
 
-  bool HaveModules = false;
-  RenderModulesOptions(C, D, Args, Input, Output, CmdArgs, HaveModules);
-
   // -faccess-control is default.
   if (Args.hasFlag(options::OPT_fno_access_control,
options::OPT_faccess_control, false)) @@ -4765,6 +4763,7 @@ 
void Clang::ConstructJob(Compilation &C,
   if (ImplyVCPPCXXVer) {
 StringRef LanguageStandard;
 if (const Arg *StdArg = Args.getLastArg(options::OPT__SLASH_std)) {
+  Std = StdArg;
   LanguageStandard = llvm::StringSwitch(StdArg->getValue())
  .Case("c++14", "-std=c++14")
  .Case("c++17", "-std=c++17") @@ -4830,6 +4829,12 
@@ void Clang::ConstructJob(Compilation &C,
options::OPT_fno_inline_functions))
 InlineArg->render(Args, CmdArgs);
 
+  // FIXME: Find a better way to determine whether the language has 
+ modules  // support by default, or just assume that all languages do.
+  bool HaveModules =
+  Std && (Std->containsVa

RE: r358355 - [c++20] Enable driver and frontend support for building and using

[via cfe-commits]

Hi Richard,

That helps a little bit! Our main problem is that the environment where the 
compiler is built and tested (using lit) does not have the external assembler 
installed, so all of the compiler commands which try to use "-c" fail when 
trying to run the external assembler. I find that if I change the test to use 
"-S" instead of "-c" it will pass in our build environment. Would that change 
defeat the purpose of the test?

Douglas Yung

-Original Message-
From: Richard Smith  
Sent: Monday, April 15, 2019 18:44
To: Yung, Douglas 
Cc: cfe-commits 
Subject: Re: r358355 - [c++20] Enable driver and frontend support for building 
and using

On Mon, 15 Apr 2019 at 18:14, via cfe-commits  
wrote:
>
> Hi Richard,
>
> The driver test you added (modules.cpp) seems to fail if the compiler 
> configuration uses an external assembler. Is there any way that the test can 
> be rewritten so that it works with both the integrated and an external 
> assembler configurations?

Sorry about that. r358470 fixes the test to pass if I add -fno-integrated-as to 
all the clang invocations. Does that resolve the problem you're seeing?

> Douglas Yung
>
> -Original Message-
> From: cfe-commits  On Behalf Of 
> Richard Smith via cfe-commits
> Sent: Sunday, April 14, 2019 4:12
> To: cfe-commits@lists.llvm.org
> Subject: r358355 - [c++20] Enable driver and frontend support for 
> building and using
>
> Author: rsmith
> Date: Sun Apr 14 04:11:37 2019
> New Revision: 358355
>
> URL: http://llvm.org/viewvc/llvm-project?rev=358355&view=rev
> Log:
> [c++20] Enable driver and frontend support for building and using modules 
> when -std=c++2a is specified.
>
> Added:
> cfe/trunk/test/CXX/module/module.unit/p8.cpp
> cfe/trunk/test/Driver/modules.cpp
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> cfe/trunk/lib/Frontend/FrontendActions.cpp
> cfe/trunk/lib/Parse/Parser.cpp
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Diag
> nosticFrontendKinds.td?rev=358355&r1=358354&r2=358355&view=diff
> ==
> 
> --- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td 
> (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Sun Apr 
> +++ 14
> +++ 04:11:37 2019
> @@ -173,10 +173,11 @@ def note_incompatible_analyzer_plugin_ap
>
>  def err_module_build_requires_fmodules : Error<
>"module compilation requires '-fmodules'">; -def 
> err_module_interface_requires_modules_ts : Error<
> -  "module interface compilation requires '-fmodules-ts'">;
> +def err_module_interface_requires_cpp_modules : Error<
> +  "module interface compilation requires '-std=c++2a' or 
> +'-fmodules-ts'">;
>  def err_header_module_requires_modules : Error<
> -  "header module compilation requires '-fmodules' or 
> '-fmodules-ts'">;
> +  "header module compilation requires '-fmodules', '-std=c++2a', or "
> +  "'-fmodules-ts'">;
>  def warn_module_config_mismatch : Warning<
>"module file %0 cannot be loaded due to a configuration mismatch with the 
> current "
>"compilation">, InGroup>, 
> DefaultError;
>
> Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Cl
> ang.cpp?rev=358355&r1=358354&r2=358355&view=diff
> ==
> 
> --- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Sun Apr 14 04:11:37 2019
> @@ -2721,7 +2721,7 @@ static void RenderModulesOptions(Compila
>  }
>}
>
> -  HaveModules = HaveClangModules;
> +  HaveModules |= HaveClangModules;
>if (Args.hasArg(options::OPT_fmodules_ts)) {
>  CmdArgs.push_back("-fmodules-ts");
>  HaveModules = true;
> @@ -4259,7 +4259,8 @@ void Clang::ConstructJob(Compilation &C,
>// If a std is supplied, only add -trigraphs if it follows the
>// option.
>bool ImplyVCPPCXXVer = false;
> -  if (Arg *Std = Args.getLastArg(options::OPT_std_EQ, 
> options::OPT_ansi)) {
> +  const Arg *Std = Args.getLastArg(options::OPT_std_EQ,
> + options::OPT_ansi);  if (Std) {
>  if (Std->getOption().matches(options::OPT_ansi))
>if (types::isCXX(Input

RE: r358355 - [c++20] Enable driver and frontend support for building and using

[via cfe-commits]

Both work, although using -### requires a few more changes to the test than 
just changing –c to –S because all arguments are enclosed in double quotes. I 
think it would be simplest to just change “-c” to “-S” , and if that is okay 
with you, I can make the change.

Douglas Yung

From: Richard Smith 
Sent: Monday, April 15, 2019 19:12
To: Yung, Douglas 
Cc: cfe-commits 
Subject: Re: r358355 - [c++20] Enable driver and frontend support for building 
and using

On Mon, 15 Apr 2019, 19:08 via cfe-commits, 
mailto:cfe-commits@lists.llvm.org>> wrote:
Hi Richard,

That helps a little bit! Our main problem is that the environment where the 
compiler is built and tested (using lit) does not have the external assembler 
installed, so all of the compiler commands which try to use "-c" fail when 
trying to run the external assembler. I find that if I change the test to use 
"-S" instead of "-c" it will pass in our build environment. Would that change 
defeat the purpose of the test?

That's fine. You could also try changing the -c tests from using -v to using 
-### so they don't actually run the compilation step, but we do need to run the 
steps that produce .pcm files or the later steps will fail.

Douglas Yung

-Original Message-
From: Richard Smith mailto:rich...@metafoo.co.uk>>
Sent: Monday, April 15, 2019 18:44
To: Yung, Douglas mailto:douglas.y...@sony.com>>
Cc: cfe-commits mailto:cfe-commits@lists.llvm.org>>
Subject: Re: r358355 - [c++20] Enable driver and frontend support for building 
and using

On Mon, 15 Apr 2019 at 18:14, via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
>
> Hi Richard,
>
> The driver test you added (modules.cpp) seems to fail if the compiler 
> configuration uses an external assembler. Is there any way that the test can 
> be rewritten so that it works with both the integrated and an external 
> assembler configurations?

Sorry about that. r358470 fixes the test to pass if I add -fno-integrated-as to 
all the clang invocations. Does that resolve the problem you're seeing?

> Douglas Yung
>
> -Original Message-----
> From: cfe-commits 
> mailto:cfe-commits-boun...@lists.llvm.org>>
>  On Behalf Of
> Richard Smith via cfe-commits
> Sent: Sunday, April 14, 2019 4:12
> To: cfe-commits@lists.llvm.org<mailto:cfe-commits@lists.llvm.org>
> Subject: r358355 - [c++20] Enable driver and frontend support for
> building and using
>
> Author: rsmith
> Date: Sun Apr 14 04:11:37 2019
> New Revision: 358355
>
> URL: http://llvm.org/viewvc/llvm-project?rev=358355&view=rev
> Log:
> [c++20] Enable driver and frontend support for building and using modules 
> when -std=c++2a is specified.
>
> Added:
> cfe/trunk/test/CXX/module/module.unit/p8.cpp
> cfe/trunk/test/Driver/modules.cpp
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> cfe/trunk/lib/Frontend/FrontendActions.cpp
> cfe/trunk/lib/Parse/Parser.cpp
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Diag
> nosticFrontendKinds.td?rev=358355&r1=358354&r2=358355&view=diff
> ==
> 
> --- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
> (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Sun Apr
> +++ 14
> +++ 04:11:37 2019
> @@ -173,10 +173,11 @@ def note_incompatible_analyzer_plugin_ap
>
>  def err_module_build_requires_fmodules : Error<
>"module compilation requires '-fmodules'">; -def
> err_module_interface_requires_modules_ts : Error<
> -  "module interface compilation requires '-fmodules-ts'">;
> +def err_module_interface_requires_cpp_modules : Error<
> +  "module interface compilation requires '-std=c++2a' or
> +'-fmodules-ts'">;
>  def err_header_module_requires_modules : Error<
> -  "header module compilation requires '-fmodules' or
> '-fmodules-ts'">;
> +  "header module compilation requires '-fmodules', '-std=c++2a', or "
> +  "'-fmodules-ts'">;
>  def warn_module_config_mismatch : Warning<
>"module file %0 cannot be loaded due to a configuration mismatch with the 
> current "
>"compilation">, InGroup>,
> DefaultError;
>
> Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Cl
> ang.cpp?rev=358355&r1=358354&r2=358355&

Re: r359814 - [Sema] Emit warning for visibility attribute on internal-linkage declaration

[via cfe-commits]

Hi Richard,Thank you for the heads up. Feel free to revert, or I can when I can get back to a terminal. I'm not sure where the right place is to warn if using the linkage calculator here is too early, so it might take a bit of time for me to fix the patch.Thanks,ScottOn May 2, 2019 9:42 PM, Richard Smith  wrote:This will trigger computation and caching the linkage of the

declaration too early (before we actually know it) in some cases. For

instance, I believe this is causing a rejects-valid on:



typedef struct __attribute__((visibility("hidden"))) {} A;



... which we used to accept but now reject with:



:1:31: warning: 'visibility' attribute is ignored on a

non-external symbol [-Wignored-attributes]

typedef struct __attribute__((visibility("hidden"))) {} A;

  ^

:1:57: error: unsupported: typedef changes linkage of anonymous

type, but linkage was already computed

typedef struct __attribute__((visibility("hidden"))) {} A;

    ^

:1:15: note: use a tag name here to establish linkage prior to definition

typedef struct __attribute__((visibility("hidden"))) {} A;

  ^

   A



In addition to the error, note that the warning is wrong, because the

linkage was computed too early (before it was known).



On Thu, 2 May 2019 at 12:01, Scott Linder via cfe-commits

 wrote:

>

> Author: scott.linder

> Date: Thu May  2 12:03:57 2019

> New Revision: 359814

>

> URL: http://llvm.org/viewvc/llvm-project?rev=359814&view=rev

> Log:

> [Sema] Emit warning for visibility attribute on internal-linkage declaration

>

> GCC warns on these cases, but we currently just silently ignore the attribute.

>

> Differential Revision: https://reviews.llvm.org/D61097

>

> Modified:

> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td

> cfe/trunk/lib/Sema/SemaDeclAttr.cpp

> cfe/trunk/test/Sema/attr-visibility.c

> cfe/trunk/test/SemaCXX/ast-print.cpp

> cfe/trunk/test/SemaCXX/attr-visibility.cpp

>

> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td

> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=359814&r1=359813&r2=359814&view=diff

> ==

> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)

> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu May  2 12:03:57 2019

> @@ -2778,6 +2778,9 @@ def warn_attribute_ignored : Warning<"%0

>  def warn_attribute_ignored_on_inline :

>    Warning<"%0 attribute ignored on inline function">,

>    InGroup;

> +def warn_attribute_ignored_on_non_external :

> +  Warning<"%0 attribute is ignored on a non-external symbol">,

> +  InGroup;

>  def warn_nocf_check_attribute_ignored :

>    Warning<"'nocf_check' attribute ignored; use -fcf-protection to enable the attribute">,

>    InGroup;

>

> Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp

> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=359814&r1=359813&r2=359814&view=diff

> ==

> --- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)

> +++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Thu May  2 12:03:57 2019

> @@ -2615,6 +2615,14 @@ static void handleVisibilityAttr(Sema &S

>  return;

>    }

>

> +  // Visibility attributes have no effect on symbols with internal linkage.

> +  if (const auto *ND = dyn_cast(D)) {

> +    if (!ND->isExternallyVisible())

> +  S.Diag(AL.getRange().getBegin(),

> + diag::warn_attribute_ignored_on_non_external)

> +  << AL;

> +  }

> +

>    // Check that the argument is a string literal.

>    StringRef TypeStr;

>    SourceLocation LiteralLoc;

>

> Modified: cfe/trunk/test/Sema/attr-visibility.c

> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/attr-visibility.c?rev=359814&r1=359813&r2=359814&view=diff

> ==

> --- cfe/trunk/test/Sema/attr-visibility.c (original)

> +++ cfe/trunk/test/Sema/attr-visibility.c Thu May  2 12:03:57 2019

> @@ -26,3 +26,9 @@ typedef int __attribute__((visibility("d

>  int x __attribute__((type_visibility("default"))); // expected-error {{'type_visibility' attribute only applies to types and namespaces}}

>

>  int PR17105 __attribute__((visibility(hidden))); // expected-error {{'visibility' attribute requires a string}}

> +

> +static int te

r360018 - Enable intrinsics of AVX512_BF16, which are supported for BFLOAT16 in Cooper Lake

[via cfe-commits]

Author: luoyuanke
Date: Mon May  6 01:25:11 2019
New Revision: 360018

URL: http://llvm.org/viewvc/llvm-project?rev=360018&view=rev
Log:
Enable intrinsics of AVX512_BF16, which are supported for BFLOAT16 in Cooper 
Lake

Summary:
1. Enable infrastructure of AVX512_BF16, which is supported for BFLOAT16 in 
Cooper Lake;
2. Enable intrinsics for VCVTNE2PS2BF16, VCVTNEPS2BF16 and DPBF16PS 
instructions, which are Vector Neural Network Instructions supporting BFLOAT16 
inputs and conversion instructions from IEEE single precision.
For more details about BF16 intrinsic, please refer to the latest ISE document: 
https://software.intel.com/en-us/download/intel-architecture-instruction-set-extensions-programming-reference

Patch by LiuTianle

Reviewers: craig.topper, smaslov, LuoYuanke, wxiao3, annita.zhang, spatel, 
RKSimon

Reviewed By: craig.topper

Subscribers: mgorny, cfe-commits

Tags: #clang

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

Modified:
cfe/trunk/docs/ClangCommandLineReference.rst
cfe/trunk/include/clang/Basic/BuiltinsX86.def
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/lib/Basic/Targets/X86.cpp
cfe/trunk/lib/Basic/Targets/X86.h
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/lib/Headers/CMakeLists.txt
cfe/trunk/lib/Headers/cpuid.h
cfe/trunk/lib/Headers/immintrin.h
cfe/trunk/test/CodeGen/attr-target-x86.c
cfe/trunk/test/Driver/x86-target-features.c
cfe/trunk/test/Preprocessor/x86_target_features.c

Modified: cfe/trunk/docs/ClangCommandLineReference.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ClangCommandLineReference.rst?rev=360018&r1=360017&r2=360018&view=diff
==
--- cfe/trunk/docs/ClangCommandLineReference.rst (original)
+++ cfe/trunk/docs/ClangCommandLineReference.rst Mon May  6 01:25:11 2019
@@ -2610,6 +2610,8 @@ X86
 
 .. option:: -mavx512bitalg, -mno-avx512bitalg
 
+.. option:: -mavx512bf16, -mno-avx512bf16
+
 .. option:: -mavx512bw, -mno-avx512bw
 
 .. option:: -mavx512cd, -mno-avx512cd

Modified: cfe/trunk/include/clang/Basic/BuiltinsX86.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/BuiltinsX86.def?rev=360018&r1=360017&r2=360018&view=diff
==
--- cfe/trunk/include/clang/Basic/BuiltinsX86.def (original)
+++ cfe/trunk/include/clang/Basic/BuiltinsX86.def Mon May  6 01:25:11 2019
@@ -1831,6 +1831,24 @@ TARGET_BUILTIN(__builtin_ia32_cvtusi2ss3
 TARGET_BUILTIN(__builtin_ia32_vpmultishiftqb512, "V64cV64cV64c", "ncV:512:", 
"avx512vbmi")
 TARGET_BUILTIN(__builtin_ia32_vpmultishiftqb128, "V16cV16cV16c", "ncV:128:", 
"avx512vbmi,avx512vl")
 TARGET_BUILTIN(__builtin_ia32_vpmultishiftqb256, "V32cV32cV32c", "ncV:256:", 
"avx512vbmi,avx512vl")
+TARGET_BUILTIN(__builtin_ia32_cvtne2ps2bf16_128, "V8sV4fV4f", "ncV:128:",
+ "avx512bf16,avx512vl")
+TARGET_BUILTIN(__builtin_ia32_cvtne2ps2bf16_256, "V16sV8fV8f", "ncV:256:",
+ "avx512bf16,avx512vl")
+TARGET_BUILTIN(__builtin_ia32_cvtne2ps2bf16_512, "V32sV16fV16f", "ncV:512:",
+ "avx512bf16")
+TARGET_BUILTIN(__builtin_ia32_cvtneps2bf16_128_mask, "V8sV4fV8sUc", "ncV:128:",
+"avx512bf16,avx512vl")
+TARGET_BUILTIN(__builtin_ia32_cvtneps2bf16_256, "V8sV8f", "ncV:256:",
+"avx512bf16,avx512vl")
+TARGET_BUILTIN(__builtin_ia32_cvtneps2bf16_512, "V16sV16f", "ncV:512:",
+"avx512bf16")
+TARGET_BUILTIN(__builtin_ia32_dpbf16ps_128, "V4fV4fV4iV4i", "ncV:128:",
+"avx512bf16,avx512vl")
+TARGET_BUILTIN(__builtin_ia32_dpbf16ps_256, "V8fV8fV8iV8i", "ncV:256:",
+"avx512bf16,avx512vl")
+TARGET_BUILTIN(__builtin_ia32_dpbf16ps_512, "V16fV16fV16iV16i", "ncV:512:",
+"avx512bf16")
 
 // generic select intrinsics
 TARGET_BUILTIN(__builtin_ia32_selectb_128, "V16cUsV16cV16c", "ncV:128:", 
"avx512bw,avx512vl")

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=360018&r1=360017&r2=360018&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Mon May  6 01:25:11 2019
@@ -2854,6 +2854,8 @@ def mavx2 : Flag<["-"], "mavx2">, Group<
 def mno_avx2 : Flag<["-"], "mno-avx2">, Group;
 def mavx512f : Flag<["-"], "mavx512f">, Group;
 def mno_avx512f : Flag<["-"], "mno-avx512f">, Group;
+def mavx512bf16 : Flag<["-"], "mavx512bf16">, Group;
+def mno_avx512bf16 : Flag<["-"], "mno-avx512bf16">, 
Group;
 def mavx512bit

RE: r342501 - Fix logic around determining use of frame pointer with -pg.

[via cfe-commits]

Hi Stephen,

Your change is causing a test failure on the PS4 linux bot, can you please take 
a look?

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/36712/steps/test/logs/stdio

FAIL: Clang :: Driver/clang_f_opts.c (8141 of 44013)
 TEST 'Clang :: Driver/clang_f_opts.c' FAILED 

...
Command Output (stderr):
--
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/clang_f_opts.c:537:29:
 error: CHECK-NO-MIX-OMIT-FP-PG: expected string not found in input
// CHECK-NO-MIX-OMIT-FP-PG: '-fomit-frame-pointer' not allowed with '-pg'
^
:1:1: note: scanning from here
clang version 8.0.0 (trunk 342502)
^
:5:934: note: possible intended match here
 
"/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/bin/clang-8"
 "-cc1" "-triple" "x86_64-scei-ps4" "-S" "-disable-free" "-main-file-name" 
"clang_f_opts.c" "-mrelocation-model" "pic" "-pic-level" "2" "-mthread-model" 
"posix" "-masm-verbose" "-mconstructor-aliases" "-munwind-tables" "-target-cpu" 
"btver2" "-debugger-tuning=sce" "-mllvm" "-generate-arange-section" 
"-debug-forward-template-params" "-dwarf-explicit-import" 
"-coverage-notes-file" 
"/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/test/Driver/clang_f_opts.gcno"
 "-resource-dir" 
"/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/lib/clang/8.0.0"
 "-fdebug-compilation-dir" 
"/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/test/Driver"
 "-fstack-size-section" "-ferror-limit" "19" "-fmessage-length" "0" "-pg" 
"-stack-protector" "2" "-fdeclspec" "-fobjc-runtime=gnustep" 
"-fdiagnostics-show-option" "-o" "clang_f_opts.s" "-x" "c" 
"/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/test/Driver/clang_f_opts.c"
 "-faddrsig"







            



 ^

Douglas Yung

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of Stephen Hines via cfe-commits
> Sent: Tuesday, September 18, 2018 11:35
> To: cfe-commits@lists.llvm.org
> Subject: r342501 - Fix logic around determining use of frame pointer
> with -pg.
> 
> Author: srhines
> Date: Tue Sep 18 11:34:33 2018
> New Revision: 342501
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=342501&view=rev
> Log:
> Fix logic around determining use of frame pointer with -pg.
> 
> Summary:
> As part of r342165, I rewrote the logic to check whether
> -fno-omit-frame-pointer was passed after a -fomit-frame-pointer
> argument. This CL switches that logic to use the consolidated
> shouldUseFramePointer() function. This fixes a potential issue where -
> pg
> gets used with -fomit-frame-pointer on a platform that must always
> retain
> frame pointers.
> 
> Reviewers: dblaikie
> 
> Reviewed By: dblaikie
> 
> Subscribers: cfe-commits
> 
> Differential Revision: https://reviews.llvm.org/D52191
> 
> Modified:
> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> 
> Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=342501&r1=342500&
> r2=342501&view=diff
> 

RE: r342668 - Add testcases for r342667.

[via cfe-commits]

Hi Eric,

The test that you added in this commit is failing on the PS4 Windows bot. Can 
you please take a look?

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/20052

FAIL: Clang :: Preprocessor/include-leading-nonalpha-suggest.c (10765 of 43992)
 TEST 'Clang :: 
Preprocessor/include-leading-nonalpha-suggest.c' FAILED 
Script:
--
: 'RUN: at line 1';   
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\8.0.0\include
 -nostdsysteminc 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Preprocessor\include-leading-nonalpha-suggest.c
 -verify
--
Exit Code: 1

Command Output (stdout):
--
$ ":" "RUN: at line 1"
$ 
"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\8.0.0\include"
 "-nostdsysteminc" 
"C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Preprocessor\include-leading-nonalpha-suggest.c"
 "-verify"
# command stderr:
error: 'error' diagnostics expected but not seen: 

  File 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Preprocessor\include-leading-nonalpha-suggest.c
 Line 3: '/empty_file_to_include.h' file not found, did you mean 
'empty_file_to_include.h'?

1 error generated.


error: command failed with exit status: 1

Douglas Yung

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of Eric Christopher via cfe-commits
> Sent: Thursday, September 20, 2018 10:23
> To: cfe-commits@lists.llvm.org
> Subject: r342668 - Add testcases for r342667.
> 
> Author: echristo
> Date: Thu Sep 20 10:22:43 2018
> New Revision: 342668
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=342668&view=rev
> Log:
> Add testcases for r342667.
> 
> Added:
> cfe/trunk/test/Preprocessor/include-leading-nonalpha-no-suggest.c
> cfe/trunk/test/Preprocessor/include-leading-nonalpha-suggest.c
> 
> Added: cfe/trunk/test/Preprocessor/include-leading-nonalpha-no-
> suggest.c
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/test/Preprocessor/include-leading-nonalpha-no-
> suggest.c?rev=342668&view=auto
> ===
> ===
> --- cfe/trunk/test/Preprocessor/include-leading-nonalpha-no-suggest.c
> (added)
> +++ cfe/trunk/test/Preprocessor/include-leading-nonalpha-no-suggest.c
> Thu Sep 20 10:22:43 2018
> @@ -0,0 +1,3 @@
> +// RUN: %clang_cc1 %s -verify
> +
> +#include "/non_existing_file_to_include.h" // expected-error
> {{'/non_existing_file_to_include.h' file not found}}
> 
> Added: cfe/trunk/test/Preprocessor/include-leading-nonalpha-suggest.c
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/test/Preprocessor/include-leading-nonalpha-
> suggest.c?rev=342668&view=auto
> ===
> ===
> --- cfe/trunk/test/Preprocessor/include-leading-nonalpha-suggest.c
> (added)
> +++ cfe/trunk/test/Preprocessor/include-leading-nonalpha-suggest.c Thu
> Sep 20 10:22:43 2018
> @@ -0,0 +1,3 @@
> +// RUN: %clang_cc1 %s -verify
> +
> +#include "/empty_file_to_include.h" // expected-error
> {{'/empty_file_to_include.h' file not found, did you mean
> 'empty_file_to_include.h'?}}
> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: [clang-tools-extra] r343576 - [clangd] Cache FS stat() calls when building preamble.

[via cfe-commits]

Hi Eric,

One of the tests you added in this commit is causing a failure on the PS4 
Windows bot:

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/20347/steps/test/logs/stdio:

FAIL: Extra Tools Unit Tests :: 
clangd/./ClangdTests.exe/ClangdTests.PreambleVFSStatCache (87 of 344)
 TEST 'Extra Tools Unit Tests :: 
clangd/./ClangdTests.exe/ClangdTests.PreambleVFSStatCache' FAILED 

Note: Google Test filter = ClangdTests.PreambleVFSStatCache

[==] Running 1 test from 1 test case.

[--] Global test environment set-up.

[--] 1 test from ClangdTests

[ RUN  ] ClangdTests.PreambleVFSStatCache

C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\unittests\clangd\ClangdTests.cpp(1026):
 error:   Expected: CountStats["foo.h"]

  Which is: 2

To be equal to: 1u

  Which is: 1

[  FAILED  ] ClangdTests.PreambleVFSStatCache (441 ms)

[--] 1 test from ClangdTests (441 ms total)



[--] Global test environment tear-down

[==] 1 test from 1 test case ran. (441 ms total)

[  PASSED  ] 0 tests.

[  FAILED  ] 1 test, listed below:

[  FAILED  ] ClangdTests.PreambleVFSStatCache



 1 FAILED TEST

Updating file C:\clangd-test\foo.cpp with command [C:\clangd-test] clang 
-ffreestanding C:\clangd-test\foo.cpp 
-resource-dir=C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\tools\clang\tools\extra\unittests\clangd\..\lib\clang\8.0.0

Preamble for file C:\clangd-test\foo.cpp cannot be reused. Attempting to 
rebuild it.

Built preamble of size 185492 for file C:\clangd-test\foo.cpp

Code complete: sema context Statement, query scopes [] (AnyScope=false)

Code complete: 1 results from Sema, 0 from Index, 0 matched, 1 returned.



Can you please take a look?

Douglas Yung

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of Eric Liu via cfe-commits
> Sent: Tuesday, October 02, 2018 3:44
> To: cfe-commits@lists.llvm.org
> Subject: [clang-tools-extra] r343576 - [clangd] Cache FS stat() calls
> when building preamble.
> 
> Author: ioeric
> Date: Tue Oct  2 03:43:55 2018
> New Revision: 343576
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=343576&view=rev
> Log:
> [clangd] Cache FS stat() calls when building preamble.
> 
> Summary:
> The file stats can be reused when preamble is reused (e.g. code
> completion). It's safe to assume that cached status is not outdated as
> we
> assume preamble files to remain unchanged.
> 
> On real file system, this made code completion ~20% faster on a
> measured file
> (with big preamble). The preamble build time doesn't change much.
> 
> Reviewers: sammccall, ilya-biryukov
> 
> Reviewed By: sammccall
> 
> Subscribers: mgorny, MaskRay, jkorous, arphaman, kadircet, cfe-commits
> 
> Differential Revision: https://reviews.llvm.org/D52419
> 
> Added:
> clang-tools-extra/trunk/clangd/FS.cpp
> clang-tools-extra/trunk/clangd/FS.h
> clang-tools-extra/trunk/unittests/clangd/FSTests.cpp
> Modified:
> clang-tools-extra/trunk/clangd/CMakeLists.txt
> clang-tools-extra/trunk/clangd/ClangdServer.cpp
> clang-tools-extra/trunk/clangd/ClangdUnit.cpp
> clang-tools-extra/trunk/clangd/ClangdUnit.h
> clang-tools-extra/trunk/clangd/CodeComplete.cpp
> clang-tools-extra/trunk/clangd/CodeComplete.h
> clang-tools-extra/trunk/unittests/clangd/CMakeLists.txt
> clang-tools-extra/trunk/unittests/clangd/ClangdTests.cpp
> clang-tools-extra/trunk/unittests/clangd/TestFS.cpp
> 
> Modified: clang-tools-extra/trunk/clangd/CMakeLists.txt
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-
> extra/trunk/clangd/CMakeLists.txt?rev=343576&r1=343575&r2=343576&view=d
> iff
> ===
> ===
> --- clang-tools-extra/trunk/clangd/CMakeLists.txt (original)
> +++ clang-tools-extra/trunk/clangd/CMakeLists.txt Tue Oct  2 03:43:55
> 2018
> @@ -21,6 +21,7 @@ add_clang_library(clangDaemon
>DraftStore.cpp
>FindSymbols.cpp
>FileDistance.cpp
> +  FS.cpp
>FuzzyMatch.cpp
>GlobalCompilationDatabase.cpp
>Headers.cpp
> 
> Modified: clang-tools-extra/trunk/clangd/ClangdServer.cpp
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-
> extra/trunk/clangd/ClangdServer.cpp?rev=343576&r1=343575&r2=343576&view
> =diff
> ===
> ===
> --- clang-tools-extra/trunk/clangd/ClangdServer.cpp (original)
> +++ clang-tools-extra/trunk/clangd/ClangdServer.cpp Tue Oct  2 03:43:55
> 2018
> @

RE: [clang-tools-extra] r343780 - [clangd] expose MergedIndex class

[via cfe-commits]

Hi Sam,

Your change is causing a build failure on one of the build bots. Can you take a 
look?

http://lab.llvm.org:8011/builders/clang-x86_64-linux-abi-test/builds/33139

FAILED: 
tools/clang/tools/extra/unittests/clangd/CMakeFiles/ClangdTests.dir/TestTU.cpp.o
 
/usr/bin/c++   -DGTEST_HAS_RTTI=0 -DGTEST_HAS_TR1_TUPLE=0 -DGTEST_LANG_CXX11=1 
-D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS 
-D__STDC_LIMIT_MACROS -Itools/clang/tools/extra/unittests/clangd 
-I/home/buildslave/buildslave1a/clang-x86_64-linux-abi-test/llvm/tools/clang/tools/extra/unittests/clangd
 
-I/home/buildslave/buildslave1a/clang-x86_64-linux-abi-test/llvm/tools/clang/include
 -Itools/clang/include -Iinclude 
-I/home/buildslave/buildslave1a/clang-x86_64-linux-abi-test/llvm/include 
-I/home/buildslave/buildslave1a/clang-x86_64-linux-abi-test/llvm/tools/clang/tools/extra/clangd
 
-I/home/buildslave/buildslave1a/clang-x86_64-linux-abi-test/llvm/utils/unittest/googletest/include
 
-I/home/buildslave/buildslave1a/clang-x86_64-linux-abi-test/llvm/utils/unittest/googlemock/include
 -fPIC -fvisibility-inlines-hidden -std=c++11 -Wall -Wextra 
-Wno-unused-parameter -Wwrite-strings -Wcast-qual 
-Wno-missing-field-initializers -pedantic -Wno-long-long 
-Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment 
-ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual 
-fno-strict-aliasing -O3-UNDEBUG  -Wno-variadic-macros -fno-exceptions 
-fno-rtti -MD -MT 
tools/clang/tools/extra/unittests/clangd/CMakeFiles/ClangdTests.dir/TestTU.cpp.o
 -MF 
tools/clang/tools/extra/unittests/clangd/CMakeFiles/ClangdTests.dir/TestTU.cpp.o.d
 -o 
tools/clang/tools/extra/unittests/clangd/CMakeFiles/ClangdTests.dir/TestTU.cpp.o
 -c 
/home/buildslave/buildslave1a/clang-x86_64-linux-abi-test/llvm/tools/clang/tools/extra/unittests/clangd/TestTU.cpp
/home/buildslave/buildslave1a/clang-x86_64-linux-abi-test/llvm/tools/clang/tools/extra/unittests/clangd/TestTU.cpp:
 In member function ‘std::unique_ptr 
clang::clangd::TestTU::index() const’:
/home/buildslave/buildslave1a/clang-x86_64-linux-abi-test/llvm/tools/clang/tools/extra/unittests/clangd/TestTU.cpp:56:10:
 error: could not convert ‘Idx’ from 
‘std::unique_ptr’ to 
‘std::unique_ptr’
   return Idx;
  ^
/home/buildslave/buildslave1a/clang-x86_64-linux-abi-test/llvm/tools/clang/tools/extra/unittests/clangd/TestTU.cpp:57:1:
 warning: control reaches end of non-void function [-Wreturn-type]
 }
 ^

Douglas Yung

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of Sam McCall via cfe-commits
> Sent: Thursday, October 04, 2018 7:20
> To: cfe-commits@lists.llvm.org
> Subject: [clang-tools-extra] r343780 - [clangd] expose MergedIndex
> class
> 
> Author: sammccall
> Date: Thu Oct  4 07:20:22 2018
> New Revision: 343780
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=343780&view=rev
> Log:
> [clangd] expose MergedIndex class
> 
> Summary:
> This allows inheriting from it, so index() can ga away and allowing
> TestTU::index) to be fixed.
> 
> Reviewers: ioeric
> 
> Subscribers: ilya-biryukov, MaskRay, jkorous, arphaman, kadircet, cfe-
> commits
> 
> Differential Revision: https://reviews.llvm.org/D52250
> 
> Modified:
> clang-tools-extra/trunk/clangd/ClangdServer.cpp
> clang-tools-extra/trunk/clangd/ClangdServer.h
> clang-tools-extra/trunk/clangd/index/FileIndex.cpp
> clang-tools-extra/trunk/clangd/index/FileIndex.h
> clang-tools-extra/trunk/clangd/index/Merge.cpp
> clang-tools-extra/trunk/clangd/index/Merge.h
> clang-tools-extra/trunk/unittests/clangd/FileIndexTests.cpp
> clang-tools-extra/trunk/unittests/clangd/IndexTests.cpp
> clang-tools-extra/trunk/unittests/clangd/TestTU.cpp
> 
> Modified: clang-tools-extra/trunk/clangd/ClangdServer.cpp
> URL: http://llvm.org/viewvc/llvm-project/clang-tools-
> extra/trunk/clangd/ClangdServer.cpp?rev=343780&r1=343779&r2=343780&view
> =diff
> ===
> ===
> --- clang-tools-extra/trunk/clangd/ClangdServer.cpp (original)
> +++ clang-tools-extra/trunk/clangd/ClangdServer.cpp Thu Oct  4 07:20:22
> 2018
> @@ -117,20 +117,17 @@ ClangdServer::ClangdServer(GlobalCompila
> : nullptr,
>  Opts.UpdateDebounce, Opts.RetentionPolicy) {
>if (DynamicIdx && Opts.StaticIndex) {
> -MergedIndex = mergeIndex(&DynamicIdx->index(), Opts.StaticIndex);
> -Index = MergedIndex.get();
> +MergedIdx =
> +llvm::make_unique(DynamicIdx.get(),
> Opts.StaticIndex);
> +Index = MergedIdx.get();
>} else if (DynamicIdx)
> -Index = &DynamicIdx->index();
> +Index = DynamicIdx.get();
>else if (Opts.StaticIndex)

RE: [clang-tools-extra] r343778 - [clangd] clangd-indexer gathers refs and stores them in index files.

[via cfe-commits]

Hi Sam,

Our internal build bot hit an assertion failure in the changes you made in this 
commit that I was able to reproduce by building your change on my machine on 
Windows 7 using Visual Studio 2015. None of the public build bots seem to have 
hit this issue, though I am not sure why at the moment.

Here is the assertion failure that is hit while running ClangdTests.exe:

[--] 2 tests from SerializationTest
[ RUN  ] SerializationTest.YAMLConversions
[   OK ] SerializationTest.YAMLConversions (0 ms)
[ RUN  ] SerializationTest.BinaryConversions
Assertion failed: OutBufCur == OutBufStart && "raw_ostream destructor called 
with non-empty buffer!", file 
C:\src\upstream\llvm2\lib\Support\raw_ostream.cpp, line 73
0x00013FA74405 (0x0016 0x0200 0x06D100230006 
0x07FEEA9BAA51), HandleAbort() + 0x5 bytes(s), 
c:\src\upstream\llvm2\lib\support\windows\signals.inc, line 409
0x07FEEAA1DC17 (0x0001 0x0001 0x 
0x009BF460), raise() + 0x1E7 bytes(s)
0x07FEEAA1EAA1 (0x07FE0003 0x07FE0003 0x0001413AF810 
0x0001413AF790), abort() + 0x31 bytes(s)
0x07FEEAA20751 (0x0049 0x0001413AF810 0x0122 
0x07FEEA9C05D6), _get_wpgmptr() + 0x1BE1 bytes(s)
0x07FEEAA20A5F (0x009BF890 0x009BF680 0x00B05AB0 
0x00014126F8C5), _wassert() + 0x3F bytes(s)
0x00013FA40677 (0x 0x00A8 0x009BF890 
0x00013FA41A2E), llvm::raw_ostream::~raw_ostream() + 0x37 bytes(s), 
c:\src\upstream\llvm2\lib\support\raw_ostream.cpp, line 75
0x00013FA4057C (0x04BA1FF0 0x009BF680 0x00B05AB0 
0x00B05AB0), llvm::raw_fd_ostream::~raw_fd_ostream() + 0x11C bytes(s), 
c:\src\upstream\llvm2\lib\support\raw_ostream.cpp, line 617
0x00013F96A4CC (0x04BA1FF0 0x00B05AB0 0x00B05AB0 
0x04BA1FF0), clang::clangd::`anonymous 
namespace'::SerializationTest_BinaryConversions_Test::TestBody() + 0x34C 
bytes(s), 
c:\src\upstream\llvm2\tools\clang\tools\extra\unittests\clangd\serializationtests.cpp,
 line 166
0x00013FAE201C (0x04BA1FF0 0x00B05AB0 0x0001413C4B68 
0x07FEEAA954B8), 
testing::internal::HandleSehExceptionsInMethodIfSupported() 
+ 0xC bytes(s), c:\src\upstream\llvm2\utils\unittest\googletest\src\gtest.cc, 
line 2387 + 0x2 byte(s)
0x00013FB09E5B (0x04BA1FF0 0x00B05AB0 0x0001413C4D30 
0x009BF9E8), testing::Test::Run() + 0x7B bytes(s), 
c:\src\upstream\llvm2\utils\unittest\googletest\src\gtest.cc, line 2481
0x00013FB0A0DB (0x016641B94CAF 0x00B05AB0 0x00B1DE30 
0x00AFF560), testing::TestInfo::Run() + 0xAB bytes(s), 
c:\src\upstream\llvm2\utils\unittest\googletest\src\gtest.cc, line 2660
0x00013FB09F72 (0x0023 0x 0x00B05AB0 
0x00AFF560), testing::TestCase::Run() + 0xB2 bytes(s), 
c:\src\upstream\llvm2\utils\unittest\googletest\src\gtest.cc, line 2774 + 0x12 
byte(s)
0x00013FB0A529 (0x00AFF410 0x 0x0001 
0x07FE0001), testing::internal::UnitTestImpl::RunAllTests() + 0x229 
bytes(s), c:\src\upstream\llvm2\utils\unittest\googletest\src\gtest.cc, line 
4649 + 0x39 byte(s)
0x00013FAE213C (0x00AFF410 0x 0x0001413C54A8 
0x), 
testing::internal::HandleSehExceptionsInMethodIfSupported()
 + 0xC bytes(s), c:\src\upstream\llvm2\utils\unittest\googletest\src\gtest.cc, 
line 2387 + 0x2 byte(s)
0x00013FB0A27C (0x8002 0x 0x 
0x), testing::UnitTest::Run() + 0xEC bytes(s), 
c:\src\upstream\llvm2\utils\unittest\googletest\src\gtest.cc, line 4257 + 0x17 
byte(s)
0x000141299397 (0x00010001 0x 0x 
0x01D45C4625BC735E), main() + 0xB7 bytes(s), 
c:\src\upstream\llvm2\utils\unittest\unittestmain\testmain.cpp, line 52
0x0001412707C1 (0x 0x 0x 
0x), __scrt_common_main_seh() + 0x11D bytes(s), 
f:\dd\vctools\crt\vcstartup\src\startup\exe_common.inl, line 253 + 0x22 byte(s)
0x76C159CD (0x 0x 0x 
0x), BaseThreadInitThunk() + 0xD bytes(s)
0x76E7385D (0x 0x 0x 
0x), RtlUserThreadStart() + 0x1D bytes(s)

Could you take a look into this?

Douglas Yung

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf
> Of Sam McCall via cfe-commits
> Sent: Thursday, October 04, 2018 7:10
> To: cfe-commits@lists.llvm.org
> Subject: [clang-tools-extra] r343778 - [clangd] clangd-indexer gathers
> refs and stores them in index files.
> 
> Author: sammccall
> Date: Thu Oct  

RE: r353569 - [Sema] Make string literal init an rvalue.

[via cfe-commits]

Hi Eli,

Your commit is causing a failure on the PS4 linux bot, can you please take a 
look?

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/43625

FAIL: Clang Tools :: clang-tidy/bugprone-string-constructor.cpp (14325 of 46835)
 TEST 'Clang Tools :: 
clang-tidy/bugprone-string-constructor.cpp' FAILED 
Script:
--
: 'RUN: at line 1';   /usr/bin/python2.7 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/tools/extra/test/../test/clang-tidy/check_clang_tidy.py
 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/tools/extra/test/clang-tidy/bugprone-string-constructor.cpp
 bugprone-string-constructor 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/tools/extra/test/clang-tidy/Output/bugprone-string-constructor.cpp.tmp
--
Exit Code: 1

Command Output (stdout):
--
Running ['clang-tidy', 
'/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/tools/extra/test/clang-tidy/Output/bugprone-string-constructor.cpp.tmp.cpp',
 '-fix', '--checks=-*,bugprone-string-constructor', '--', '--std=c++11', 
'-nostdinc++']...
clang-tidy failed:
clang-tidy: 
/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/lib/AST/ExprConstant.cpp:3374:
 bool handleLValueToRValueConversion((anonymous namespace)::EvalInfo &, const 
clang::Expr *, clang::QualType, const (anonymous namespace)::LValue &, 
clang::APValue &): Assertion `LVal.Designator.Entries.size() == 1 && "Can only 
read characters from string literals"' failed.
 #0 0x004ad2c4 (clang-tidy+0x4ad2c4)
 #1 0x004ab03c (clang-tidy+0x4ab03c)
 #2 0x004ad878 (clang-tidy+0x4ad878)
 #3 0x7f034560b890 __restore_rt 
(/lib/x86_64-linux-gnu/libpthread.so.0+0x12890)
 #4 0x7f03442d1e97 gsignal (/lib/x86_64-linux-gnu/libc.so.6+0x3ee97)
 #5 0x7f03442d3801 abort (/lib/x86_64-linux-gnu/libc.so.6+0x40801)
 #6 0x7f03442c339a (/lib/x86_64-linux-gnu/libc.so.6+0x3039a)
 #7 0x7f03442c3412 (/lib/x86_64-linux-gnu/libc.so.6+0x30412)
 #8 0x01941c9d (clang-tidy+0x1941c9d)
 #9 0x0192b797 (clang-tidy+0x192b797)
#10 0x019266be (clang-tidy+0x19266be)
#11 0x005771f9 (clang-tidy+0x5771f9)
#12 0x01769d11 (clang-tidy+0x1769d11)
#13 0x01782d4b (clang-tidy+0x1782d4b)
#14 0x01769497 (clang-tidy+0x1769497)
#15 0x01774613 (clang-tidy+0x1774613)
#16 0x0177161f (clang-tidy+0x177161f)
#17 0x01782ad2 (clang-tidy+0x1782ad2)
#18 0x0176b3e6 (clang-tidy+0x176b3e6)
#19 0x0177f17d (clang-tidy+0x177f17d)
#20 0x0177161f (clang-tidy+0x177161f)
#21 0x017829f3 (clang-tidy+0x17829f3)
#22 0x0176b0bd (clang-tidy+0x176b0bd)
#23 0x0176e8b7 (clang-tidy+0x176e8b7)
#24 0x0176cfae (clang-tidy+0x176cfae)
#25 0x0174981f (clang-tidy+0x174981f)
#26 0x00c5020c (clang-tidy+0xc5020c)
#27 0x00d98873 (clang-tidy+0xd98873)
#28 0x00c381c0 (clang-tidy+0xc381c0)
#29 0x00bdcd31 (clang-tidy+0xbdcd31)
#30 0x00834386 (clang-tidy+0x834386)
#31 0x004ccba5 (clang-tidy+0x4ccba5)
#32 0x008340f6 (clang-tidy+0x8340f6)
#33 0x00833997 (clang-tidy+0x833997)
#34 0x0083579c (clang-tidy+0x83579c)
#35 0x004c9505 (clang-tidy+0x4c9505)
#36 0x0041d427 (clang-tidy+0x41d427)
#37 0x7f03442b4b97 __libc_start_main 
(/lib/x86_64-linux-gnu/libc.so.6+0x21b97)
#38 0x0041b2fa (clang-tidy+0x41b2fa)


--
Command Output (stderr):
--
Traceback (most recent call last):
  File 
"/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/tools/extra/test/../test/clang-tidy/check_clang_tidy.py",
 line 207, in 
main()
  File 
"/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.src/tools/clang/tools/extra/test/../test/clang-tidy/check_clang_tidy.py",
 line 147, in main
subprocess.check_output(args, stderr=subprocess.STDOUT).decode()
  File "/usr/lib/python2.7/subprocess.py", line 223, in check_output
raise CalledProcessError(retcode, cmd, output=output)
subprocess.CalledProcessError: Command '['clang-tidy', 
'/home/buildslave/ps4-buildslave4/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/llvm.obj/tools/clang/tools/extra/test/clang-tidy/Output/bugprone-string-constructor.cpp.tmp.cpp',
 '-fix', '--checks=-*,bugprone-string-constructor', '--', '--std=c++11', 
'-nostdinc++']' returned non-zero exit status -6

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of Eli 
Friedman via cfe-commit

RE: r353718 - Make test actually test something (colons were missing)

[via cfe-commits]

I thin the Best Fix is probably to make FileCheck diag if a line starts with 
(after a few whitelisted comment chars like // and #) a check-prefix but then 
isn't followed by : (maybe after -NOT, -SAME, -LABEL etc).

FileCheck doesn't explicitly pass over leading comment characters, it just 
pattern-matches the check names followed by colon or hyphen. You can put 
arbitrary text in front of a check name and FileCheck won't care (although your 
reviewers might).
I can see the value in a diag like this.  It does mean any use of a check name 
that isn't *intended* to be a directive would be flagged (e.g., in a random 
comment within the test).  That pattern-match is case-sensitive and our 
convention is to use uppercase check names, so it probably wouldn't be TOO bad.
If anybody wants to do this I'm happy to review it.  Or file a PR and cc me.
--paulr
who has done a lot of FileCheck patch reviewing lately

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

RE: r353370 - Generalised the SMT state constraints

[via cfe-commits]

Hi Mikhail,

Your commit seems to be causing a build failure on our internal Windows build 
bot that uses Visual Studio 2015. Can you take a look?

C:\src\upstream\llvm_clean\tools\clang\include\clang/StaticAnalyzer/Core/PathSensitive/SMTConstraintManager.h(23):
 error C2872: 'ConstraintSMTTy': ambiguous symbol 
[C:\src\upstream\353370-PS4-Release\tools\clang\lib\StaticAnalyzer\Core\clangStaticAnalyzerCore.vcxproj]
  
C:\src\upstream\llvm_clean\tools\clang\include\clang/StaticAnalyzer/Core/PathSensitive/SMTConstraintManager.h(22):
 note: could be 'llvm::ImmutableSet,llvm::ImutContainerInfo> ConstraintSMTTy'
  with
  [
  ValT=std::pair
  ]
  
C:\src\upstream\llvm_clean\tools\clang\include\clang/StaticAnalyzer/Core/PathSensitive/SMTConstraintManager.h(23):
 note: or   '`anonymous-namespace'::ConstraintSMTTy'

I was able to reproduce the build failure locally on my Windows machine using 
Visual Studio 2015 Update 3 (version 19.00.24215.1). Here are the cmake and 
build commands I used:

CMake.exe -G "Visual Studio 14 Win64" -DCMAKE_BUILD_TYPE=Release 
-DLLVM_ENABLE_ASSERTIONS=ON -DLLVM_DEFAULT_TARGET_TRIPLE=x86_64-scei-ps4 
-DLLVM_TOOL_COMPILER_RT_BUILD:BOOL=OFF -DLLVM_BUILD_TESTS:BOOL=ON 
-DLLVM_BUILD_EXAMPLES:BOOL=ON -DCLANG_BUILD_EXAMPLES:BOOL=ON 
-DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_LIT_ARGS="-v -j8" C:\src\upstream\llvm_clean

Douglas Yung

-Original Message-----
From: cfe-commits  On Behalf Of Mikhail R. 
Gadelha via cfe-commits
Sent: Wednesday, February 6, 2019 19:18
To: cfe-commits@lists.llvm.org
Subject: r353370 - Generalised the SMT state constraints

Author: mramalho
Date: Wed Feb  6 19:17:36 2019
New Revision: 353370

URL: http://llvm.org/viewvc/llvm-project?rev=353370&view=rev
Log:
Generalised the SMT state constraints

This patch moves the ConstraintSMT definition to the SMTConstraintManager 
header to make it easier to move the Z3 backend around.

We achieve this by not using shared_ptr  anymore, as llvm::ImmutableSet doesn't 
seem to like it.

The solver specific exprs and sorts are cached in the Z3Solver object now and 
we move pointers to those objects around.

As a nice side-effect, SMTConstraintManager doesn't have to be a template 
anymore. Yay!

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

Modified:

cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SMTConstraintManager.h
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SMTExpr.h
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SMTSolver.h
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SMTSort.h
cfe/trunk/lib/StaticAnalyzer/Core/Z3ConstraintManager.cpp

Modified: 
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SMTConstraintManager.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SMTConstraintManager.h?rev=353370&r1=353369&r2=353370&view=diff
==
--- 
cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SMTConstraintManager.h
 (original)
+++ cfe/trunk/include/clang/StaticAnalyzer/Core/PathSensitive/SMTConstra
+++ intManager.h Wed Feb  6 19:17:36 2019
@@ -17,10 +17,14 @@
 #include "clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/SMTConv.h"
 
+typedef llvm::ImmutableSet<
+std::pair>
+ConstraintSMTTy;
+REGISTER_TRAIT_WITH_PROGRAMSTATE(ConstraintSMT, ConstraintSMTTy)
+
 namespace clang {
 namespace ento {
 
-template   class 
SMTConstraintManager : public clang::ento::SimpleConstraintManager {
   SMTSolverRef &Solver;
 
@@ -212,7 +216,7 @@ public:
 OS << nl << sep << "Constraints:";
 for (auto I = CZ.begin(), E = CZ.end(); I != E; ++I) {
   OS << nl << ' ' << I->first << " : ";
-  I->second.print(OS);
+  I->second->print(OS);
 }
 OS << nl;
   }
@@ -272,8 +276,7 @@ protected:
  const SMTExprRef &Exp) {
 // Check the model, avoid simplifying AST to save time
 if (checkModel(State, Sym, Exp).isConstrainedTrue())
-  return State->add(
-  std::make_pair(Sym, static_cast(*Exp)));
+  return State->add(std::make_pair(Sym, Exp));
 
 return nullptr;
   }
@@ -289,9 +292,9 @@ protected:
 if (I != IE) {
   std::vector ASTs;
 
-  SMTExprRef Constraint = Solver->newExprRef(I++->second);
+  SMTExprRef Constraint = I++->second;
   while (I != IE) {
-Constraint = Solver->mkAnd(Constraint, 
Solver->newExprRef(I++->second));
+Constraint = Solver->mkAnd(Constraint, I++->second);
   }
 
   Solver->addConstraint(Constraint);
@@ -301,8 +304,8 @@ protected:
   // Generat

RE: [clang-tools-extra] r354517 - [clang-tidy] refactor ExceptionAnalyzer further to give ternary answer

[via cfe-commits]

Hi Jonas,

Your commit seems to hit a compilation error on our internal build bot when 
built on Windows using Visual Studio 2015. Can you take a look?

  ExceptionAnalyzer.cpp
c:\src\upstream\llvm_clean\tools\clang\tools\extra\clang-tidy\utils\ExceptionAnalyzer.h(112):
 error C3431: 'State': a scoped enumeration cannot be redeclared as an unscoped 
enumeration 
[C:\src\upstream\354517-win32-Release\tools\clang\tools\extra\clang-tidy\utils\clangTidyUtils.vcxproj]

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of Jonas Toth 
via cfe-commits
Sent: Wednesday, February 20, 2019 13:05
To: cfe-commits@lists.llvm.org
Subject: [clang-tools-extra] r354517 - [clang-tidy] refactor ExceptionAnalyzer 
further to give ternary answer

Author: jonastoth
Date: Wed Feb 20 13:04:36 2019
New Revision: 354517

URL: http://llvm.org/viewvc/llvm-project?rev=354517&view=rev
Log:
[clang-tidy] refactor ExceptionAnalyzer further to give ternary answer

Summary:
The analsis on the throwing behvaiour on functions and statements gave only a 
binary answer whether an exception could occur and if yes which types are 
thrown.
This refactoring allows keeping track if there is a unknown factor, because the 
code calls to some functions with unavailable source code with no `noexcept` 
information.
This 'potential Unknown' information is propagated properly and can be queried 
separately.

Reviewers: lebedev.ri, aaron.ballman, baloghadamsoftware, alexfh

Reviewed By: lebedev.ri, baloghadamsoftware

Subscribers: xazax.hun, rnkovacs, a.sidorin, Szelethus, donat.nagy, dkrupp, 
cfe-commits

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clang-tidy/bugprone/ExceptionEscapeCheck.cpp
clang-tools-extra/trunk/clang-tidy/utils/ExceptionAnalyzer.cpp
clang-tools-extra/trunk/clang-tidy/utils/ExceptionAnalyzer.h

Modified: clang-tools-extra/trunk/clang-tidy/bugprone/ExceptionEscapeCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/bugprone/ExceptionEscapeCheck.cpp?rev=354517&r1=354516&r2=354517&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/bugprone/ExceptionEscapeCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/bugprone/ExceptionEscapeCheck.cpp 
+++ Wed Feb 20 13:04:36 2019
@@ -42,6 +42,7 @@ ExceptionEscapeCheck::ExceptionEscapeChe
   IgnoredExceptions.insert(IgnoredExceptionsVec.begin(),
IgnoredExceptionsVec.end());
   Tracer.ignoreExceptions(std::move(IgnoredExceptions));
+  Tracer.ignoreBadAlloc(true);
 }
 
 void ExceptionEscapeCheck::storeOptions(ClangTidyOptions::OptionMap &Opts) { 
@@ -70,7 +71,8 @@ void ExceptionEscapeCheck::check(const M
   if (!MatchedDecl)
 return;
 
-  if (Tracer.throwsException(MatchedDecl))
+  if (Tracer.analyze(MatchedDecl).getBehaviour() ==
+  utils::ExceptionAnalyzer::State::Throwing)
 // FIXME: We should provide more information about the exact location where
 // the exception is thrown, maybe the full path the exception escapes
 diag(MatchedDecl->getLocation(),

Modified: clang-tools-extra/trunk/clang-tidy/utils/ExceptionAnalyzer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/utils/ExceptionAnalyzer.cpp?rev=354517&r1=354516&r2=354517&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/utils/ExceptionAnalyzer.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/utils/ExceptionAnalyzer.cpp Wed 
+++ Feb 20 13:04:36 2019
@@ -8,10 +8,44 @@
 
 #include "ExceptionAnalyzer.h"
 
-#include "clang/AST/ASTContext.h"
-#include "clang/ASTMatchers/ASTMatchFinder.h"
-
 namespace clang {
+namespace tidy {
+namespace utils {
+
+void ExceptionAnalyzer::ExceptionInfo::registerException(
+const Type *ExceptionType) {
+  assert(ExceptionType != nullptr && "Only valid types are accepted");
+  Behaviour = State::Throwing;
+  ThrownExceptions.insert(ExceptionType);
+}
+
+void ExceptionAnalyzer::ExceptionInfo::registerExceptions(
+const Throwables &Exceptions) {
+  if (Exceptions.size() == 0)
+return;
+  Behaviour = State::Throwing;
+  ThrownExceptions.insert(Exceptions.begin(), Exceptions.end()); }
+
+ExceptionAnalyzer::ExceptionInfo &ExceptionAnalyzer::ExceptionInfo::merge(
+const ExceptionAnalyzer::ExceptionInfo &Other) {
+  // Only the following two cases require an update to the local
+  // 'Behaviour'. If the local entity is already throwing there will be 
+no
+  // change and if the other entity is throwing the merged entity will 
+throw
+  // as well.
+  // If one of both entities is 'Unknown' and the other one does not 
+throw
+  // the merged entity is 'Unknown' as well.
+  if (Other.Behaviour == Sta

RE: [clang-tools-extra] r354517 - [clang-tidy] refactor ExceptionAnalyzer further to give ternary answer

[via cfe-commits]

Hi Jonas,

I've committed what I think should be a fix for the build issue in r354545.

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of via 
cfe-commits
Sent: Wednesday, February 20, 2019 16:57
To: jonas.t...@gmail.com
Cc: cfe-commits@lists.llvm.org
Subject: RE: [clang-tools-extra] r354517 - [clang-tidy] refactor 
ExceptionAnalyzer further to give ternary answer

Hi Jonas,

Your commit seems to hit a compilation error on our internal build bot when 
built on Windows using Visual Studio 2015. Can you take a look?

  ExceptionAnalyzer.cpp
c:\src\upstream\llvm_clean\tools\clang\tools\extra\clang-tidy\utils\ExceptionAnalyzer.h(112):
 error C3431: 'State': a scoped enumeration cannot be redeclared as an unscoped 
enumeration 
[C:\src\upstream\354517-win32-Release\tools\clang\tools\extra\clang-tidy\utils\clangTidyUtils.vcxproj]

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of Jonas Toth 
via cfe-commits
Sent: Wednesday, February 20, 2019 13:05
To: cfe-commits@lists.llvm.org
Subject: [clang-tools-extra] r354517 - [clang-tidy] refactor ExceptionAnalyzer 
further to give ternary answer

Author: jonastoth
Date: Wed Feb 20 13:04:36 2019
New Revision: 354517

URL: http://llvm.org/viewvc/llvm-project?rev=354517&view=rev
Log:
[clang-tidy] refactor ExceptionAnalyzer further to give ternary answer

Summary:
The analsis on the throwing behvaiour on functions and statements gave only a 
binary answer whether an exception could occur and if yes which types are 
thrown.
This refactoring allows keeping track if there is a unknown factor, because the 
code calls to some functions with unavailable source code with no `noexcept` 
information.
This 'potential Unknown' information is propagated properly and can be queried 
separately.

Reviewers: lebedev.ri, aaron.ballman, baloghadamsoftware, alexfh

Reviewed By: lebedev.ri, baloghadamsoftware

Subscribers: xazax.hun, rnkovacs, a.sidorin, Szelethus, donat.nagy, dkrupp, 
cfe-commits

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clang-tidy/bugprone/ExceptionEscapeCheck.cpp
clang-tools-extra/trunk/clang-tidy/utils/ExceptionAnalyzer.cpp
clang-tools-extra/trunk/clang-tidy/utils/ExceptionAnalyzer.h

Modified: clang-tools-extra/trunk/clang-tidy/bugprone/ExceptionEscapeCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/bugprone/ExceptionEscapeCheck.cpp?rev=354517&r1=354516&r2=354517&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/bugprone/ExceptionEscapeCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/bugprone/ExceptionEscapeCheck.cpp
+++ Wed Feb 20 13:04:36 2019
@@ -42,6 +42,7 @@ ExceptionEscapeCheck::ExceptionEscapeChe
   IgnoredExceptions.insert(IgnoredExceptionsVec.begin(),
IgnoredExceptionsVec.end());
   Tracer.ignoreExceptions(std::move(IgnoredExceptions));
+  Tracer.ignoreBadAlloc(true);
 }
 
 void ExceptionEscapeCheck::storeOptions(ClangTidyOptions::OptionMap &Opts) { 
@@ -70,7 +71,8 @@ void ExceptionEscapeCheck::check(const M
   if (!MatchedDecl)
 return;
 
-  if (Tracer.throwsException(MatchedDecl))
+  if (Tracer.analyze(MatchedDecl).getBehaviour() ==
+  utils::ExceptionAnalyzer::State::Throwing)
 // FIXME: We should provide more information about the exact location where
 // the exception is thrown, maybe the full path the exception escapes
 diag(MatchedDecl->getLocation(),

Modified: clang-tools-extra/trunk/clang-tidy/utils/ExceptionAnalyzer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/utils/ExceptionAnalyzer.cpp?rev=354517&r1=354516&r2=354517&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/utils/ExceptionAnalyzer.cpp (original)
+++ clang-tools-extra/trunk/clang-tidy/utils/ExceptionAnalyzer.cpp Wed 
+++ Feb 20 13:04:36 2019
@@ -8,10 +8,44 @@
 
 #include "ExceptionAnalyzer.h"
 
-#include "clang/AST/ASTContext.h"
-#include "clang/ASTMatchers/ASTMatchFinder.h"
-
 namespace clang {
+namespace tidy {
+namespace utils {
+
+void ExceptionAnalyzer::ExceptionInfo::registerException(
+const Type *ExceptionType) {
+  assert(ExceptionType != nullptr && "Only valid types are accepted");
+  Behaviour = State::Throwing;
+  ThrownExceptions.insert(ExceptionType);
+}
+
+void ExceptionAnalyzer::ExceptionInfo::registerExceptions(
+const Throwables &Exceptions) {
+  if (Exceptions.size() == 0)
+return;
+  Behaviour = State::Throwing;
+  ThrownExceptions.insert(Exceptions.begin(), Exceptions.end()); }
+
+ExceptionAnalyzer::ExceptionInfo &ExceptionAnalyzer::ExceptionInfo::merge(
+const ExceptionAnalyzer::ExceptionInfo &Other) {
+  // Only the followin

RE: r362856 - DebugInfo: Add support for 'nodebug' attribute on typedefs and alias templates

[via cfe-commits]

Is this really measurable?  All you're suppressing are the typedef DIEs
and their names; the DIEs are small, although I admit the names can take
up space.
(I'm not really objecting, it's just hard to intuit a big size benefit.)
--paulr

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of
> David Blaikie via cfe-commits
> Sent: Friday, June 07, 2019 8:01 PM
> To: cfe-commits@lists.llvm.org
> Subject: r362856 - DebugInfo: Add support for 'nodebug' attribute on
> typedefs and alias templates
> 
> Author: dblaikie
> Date: Fri Jun  7 17:01:21 2019
> New Revision: 362856
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=362856&view=rev
> Log:
> DebugInfo: Add support for 'nodebug' attribute on typedefs and alias
> templates
> 
> Seems like a logical extension to me - and of interest because it might
> help reduce the debug info size of libc++ by applying this attribute to
> type traits that have a disproportionate debug info cost compared to the
> benefit (& possibly harm/confusion) they cause users.
> 
> Modified:
> cfe/trunk/include/clang/Basic/Attr.td
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> cfe/trunk/test/CodeGenCXX/debug-info-nodebug.cpp
> cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test
> cfe/trunk/test/Sema/attr-nodebug.c
> 
> Modified: cfe/trunk/include/clang/Basic/Attr.td
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/include/clang/Basic/Attr.td?rev=362856&r1=362855&r2=3628
> 56&view=diff
> ==
> 
> --- cfe/trunk/include/clang/Basic/Attr.td (original)
> +++ cfe/trunk/include/clang/Basic/Attr.td Fri Jun  7 17:01:21 2019
> @@ -1434,7 +1434,7 @@ def NoCommon : InheritableAttr {
> 
>  def NoDebug : InheritableAttr {
>let Spellings = [GCC<"nodebug">];
> -  let Subjects = SubjectList<[FunctionLike, ObjCMethod, NonParmVar]>;
> +  let Subjects = SubjectList<[TypedefName, FunctionLike, ObjCMethod,
> NonParmVar]>;
>let Documentation = [NoDebugDocs];
>  }
> 
> 
> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=362856&r1=362855&r2=3628
> 56&view=diff
> ==
> 
> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Jun  7 17:01:21 2019
> @@ -1091,15 +1091,18 @@ llvm::DIType *CGDebugInfo::CreateType(co
>assert(Ty->isTypeAlias());
>llvm::DIType *Src = getOrCreateType(Ty->getAliasedType(), Unit);
> 
> +  auto *AliasDecl =
> +  cast(Ty-
> >getTemplateName().getAsTemplateDecl())
> +  ->getTemplatedDecl();
> +
> +  if (AliasDecl->hasAttr())
> +return Src;
> +
>SmallString<128> NS;
>llvm::raw_svector_ostream OS(NS);
>Ty->getTemplateName().print(OS, getPrintingPolicy(), /*qualified*/
> false);
>printTemplateArgumentList(OS, Ty->template_arguments(),
> getPrintingPolicy());
> 
> -  auto *AliasDecl =
> -  cast(Ty-
> >getTemplateName().getAsTemplateDecl())
> -  ->getTemplatedDecl();
> -
>SourceLocation Loc = AliasDecl->getLocation();
>return DBuilder.createTypedef(Src, OS.str(), getOrCreateFile(Loc),
>  getLineNumber(Loc),
> @@ -1108,15 +,20 @@ llvm::DIType *CGDebugInfo::CreateType(co
> 
>  llvm::DIType *CGDebugInfo::CreateType(const TypedefType *Ty,
>llvm::DIFile *Unit) {
> +  llvm::DIType *Underlying =
> +  getOrCreateType(Ty->getDecl()->getUnderlyingType(), Unit);
> +
> +  if (Ty->getDecl()->hasAttr())
> +return Underlying;
> +
>// We don't set size information, but do specify where the typedef was
>// declared.
>SourceLocation Loc = Ty->getDecl()->getLocation();
> 
>// Typedefs are derived from some other type.
> -  return DBuilder.createTypedef(
> -  getOrCreateType(Ty->getDecl()->getUnderlyingType(), Unit),
> -  Ty->getDecl()->getName(), getOrCreateFile(Loc), getLineNumber(Loc),
> -  getDeclContextDescriptor(Ty->getDecl()));
> +  return DBuilder.createTypedef(Underlying, Ty->getDecl()->getName(),
> +getOrCreateFile(Loc), getLineNumber(Loc),
> +getDeclContextDescriptor(Ty->getDecl()));
>  }
> 
>  static unsigned getDwarfCC(CallingConv CC) {
> 
> Modified: cfe/trunk/test/CodeGenCXX/debug-info-nodebug.cp

RE: r363204 - [clang-scan-deps] initial outline of the tool that runs preprocessor to find

[via cfe-commits]

Hi Alex,

In the test you added here, the json file contains compile commands that 
includes "-c". Is that really necessary for the test to work properly?

The reason I ask is that if you run in a configuration which does not use the 
integrated assembler, the test fails with an error due to the fact that an 
external assembler must be invoked:

error: unable to handle compilation, expected exactly one compiler job in ' 
"clang" "-cc1" ...; "/usr/bin/as" "--64" "-I" "Inputs" "-o" "/dev/null"

Changing the "-c" to "-S" still shows the test passing when I run it locally, 
so if the "-c" is not really needed, can it be changed to "-S" to work 
correctly where the integrated assembler is not the default option?

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of Alex Lorenz 
via cfe-commits
Sent: Wednesday, June 12, 2019 14:33
To: cfe-commits@lists.llvm.org
Subject: r363204 - [clang-scan-deps] initial outline of the tool that runs 
preprocessor to find

Author: arphaman
Date: Wed Jun 12 14:32:49 2019
New Revision: 363204

URL: http://llvm.org/viewvc/llvm-project?rev=363204&view=rev
Log:
[clang-scan-deps] initial outline of the tool that runs preprocessor to find 
dependencies over a JSON compilation database

This commit introduces an outline for the clang-scan-deps tool that will be 
used to implement fast dependency discovery phase using implicit modules for 
explicit module builds.

The initial version of the tool works by computing non-modular header 
dependencies for files in the compilation database without any optimizations 
(i.e. without source minimization from r362459).
The tool spawns a number of worker threads to run the clang compiler workers in 
parallel.

The immediate goal for clang-scan-deps is to create a ClangScanDeps library 
which will be used to build up this tool to use the source minimization and 
caching multi-threaded filesystem to implement the optimized non-incremental 
dependency scanning phase for a non-modular build. This will allow us to do 
benchmarks and comparisons for performance that the minimization and caching 
give us

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

Added:
cfe/trunk/test/ClangScanDeps/
cfe/trunk/test/ClangScanDeps/Inputs/
cfe/trunk/test/ClangScanDeps/Inputs/header.h
cfe/trunk/test/ClangScanDeps/Inputs/header2.h
cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json
cfe/trunk/test/ClangScanDeps/regular_cdb.cpp
cfe/trunk/tools/clang-scan-deps/
cfe/trunk/tools/clang-scan-deps/CMakeLists.txt
cfe/trunk/tools/clang-scan-deps/ClangScanDeps.cpp
Modified:
cfe/trunk/test/CMakeLists.txt
cfe/trunk/tools/CMakeLists.txt

Modified: cfe/trunk/test/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CMakeLists.txt?rev=363204&r1=363203&r2=363204&view=diff
==
--- cfe/trunk/test/CMakeLists.txt (original)
+++ cfe/trunk/test/CMakeLists.txt Wed Jun 12 14:32:49 2019
@@ -57,6 +57,7 @@ list(APPEND CLANG_TEST_DEPS
   clang-rename
   clang-refactor
   clang-diff
+  clang-scan-deps
   diagtool
   hmaptool
   )

Added: cfe/trunk/test/ClangScanDeps/Inputs/header.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/header.h?rev=363204&view=auto
==
--- cfe/trunk/test/ClangScanDeps/Inputs/header.h (added)
+++ cfe/trunk/test/ClangScanDeps/Inputs/header.h Wed Jun 12 14:32:49 
+++ 2019
@@ -0,0 +1,3 @@
+#ifdef INCLUDE_HEADER2
+#include "header2.h"
+#endif

Added: cfe/trunk/test/ClangScanDeps/Inputs/header2.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/header2.h?rev=363204&view=auto
==
--- cfe/trunk/test/ClangScanDeps/Inputs/header2.h (added)
+++ cfe/trunk/test/ClangScanDeps/Inputs/header2.h Wed Jun 12 14:32:49 
+++ 2019
@@ -0,0 +1 @@
+// header 2.

Added: cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json?rev=363204&view=auto
==
--- cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json (added)
+++ cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json Wed Jun 12 
+++ 14:32:49 2019
@@ -0,0 +1,12 @@
+[
+{
+  "directory": "DIR",
+  "command": "clang -c DIR/regular_cdb.cpp -IInputs -MD -MF 
+DIR/regular_cdb.d",
+  "file": "DIR/regular_cdb.cpp"
+},
+{
+  "directory": "DIR",
+  "command": "clang -c DIR/regula

RE: r363548 - Promote -fdebug-compilation-dir from a cc1 flag to clang and clang-cl driver flags

[via cfe-commits]

Hi Nico,

The test you added in cfe/trunk/test/Driver/clang_f_opts.c fails if a target 
does not use the integrated assembler. You can see what happens if you add 
"-fno-integrated-as" to the command line:

/home/dyung/src/upstream/363548-linux/bin/clang -### -fno-integrated-as 
-fdebug-compilation-dir . -x assembler clang_f_opts.c
clang version 9.0.0 (trunk 363548)
Target: x86_64-unknown-linux-gnu
Thread model: posix
InstalledDir: /home/dyung/src/upstream/363548-linux/bin
clang-9: warning: argument unused during compilation: '-fdebug-compilation-dir 
.' [-Wunused-command-line-argument]
 "/usr/bin/as" "--64" "-o" "/tmp/clang_f_opts-f2e231.o" "clang_f_opts.c"
 "/usr/bin/ld" "-z" "relro" "--hash-style=gnu" "--eh-frame-hdr" "-m" 
"elf_x86_64" "-dynamic-linker" "/lib64/ld-linux-x86-64.so.2" "-o" "a.out" 
"/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crt1.o" 
"/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crti.o" 
"/usr/lib/gcc/x86_64-linux-gnu/8/crtbegin.o" 
"-L/usr/lib/gcc/x86_64-linux-gnu/8" 
"-L/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu" 
"-L/lib/x86_64-linux-gnu" "-L/lib/../lib64" "-L/usr/lib/x86_64-linux-gnu" 
"-L/usr/lib/gcc/x86_64-linux-gnu/8/../../.." 
"-L/home/dyung/src/upstream/363548-linux/bin/../lib" "-L/lib" "-L/usr/lib" 
"/tmp/clang_f_opts-f2e231.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" 
"-lc" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" 
"/usr/lib/gcc/x86_64-linux-gnu/8/crtend.o" 
"/usr/lib/gcc/x86_64-linux-gnu/8/../../../x86_64-linux-gnu/crtn.o"

Can you take a look to see if you can fix the test to work if a target does not 
use the integrated assembler?

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of Nico Weber 
via cfe-commits
Sent: Monday, June 17, 2019 5:11
To: cfe-commits@lists.llvm.org
Subject: r363548 - Promote -fdebug-compilation-dir from a cc1 flag to clang and 
clang-cl driver flags

Author: nico
Date: Mon Jun 17 05:10:40 2019
New Revision: 363548

URL: http://llvm.org/viewvc/llvm-project?rev=363548&view=rev
Log:
Promote -fdebug-compilation-dir from a cc1 flag to clang and clang-cl driver 
flags

The flag is useful when wanting to create .o files that are independent from 
the absolute path to the build directory. -fdebug-prefix-map= can be used to 
the same effect, but it requires putting the absolute path to the build 
directory on the build command line, so it still requires the build command 
line to be dependent on the absolute path of the build directory. With this 
flag, "-fdebug-compilation-dir ." makes it so that both debug info and the 
compile command itself are independent of the absolute path of the build 
directory, which is good for build determinism (in the sense that the build is 
independent of which directory it happens in) and for caching compile results.
(The tradeoff is that the debugger needs explicit configuration to know the 
build directory. See also http://dwarfstd.org/ShowIssue.php?issue=171130.2)

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

Modified:
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/test/Driver/cl-options.c
cfe/trunk/test/Driver/clang_f_opts.c

Modified: cfe/trunk/include/clang/Driver/CC1Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=363548&r1=363547&r2=363548&view=diff
==
--- cfe/trunk/include/clang/Driver/CC1Options.td (original)
+++ cfe/trunk/include/clang/Driver/CC1Options.td Mon Jun 17 05:10:40 
+++ 2019
@@ -190,8 +190,6 @@ def default_function_attr : Separate<["-
   HelpText<"Apply given attribute to all functions">;  def dwarf_version_EQ : 
Joined<["-"], "dwarf-version=">;  def debugger_tuning_EQ : Joined<["-"], 
"debugger-tuning=">; -def fdebug_compilation_dir : Separate<["-"], 
"fdebug-compilation-dir">,
-  HelpText<"The compilation directory to embed in the debug info.">;  def 
dwarf_debug_flags : Separate<["-"], "dwarf-debug-flags">,
   HelpText<"The string to embed in the Dwarf debug flags record.">;  def 
record_command_line : Separate<["-"], "record-command-line">,

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/in

RE: r363855 - [clang] Adapt ASTMatcher to explicit(bool) specifier

[via cfe-commits]

Hi Gauthier,

Your commit seemed to have broken the build on Windows. Can you take a look?

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/110

494.204 [1215/36/2881] Linking CXX executable bin\clang-query.exe
FAILED: bin/clang-query.exe 
cmd.exe /C "cd . && "C:\Program Files (x86)\CMake\bin\cmake.exe" -E vs_link_exe 
--intdir=tools\clang\tools\extra\clang-query\tool\CMakeFiles\clang-query.dir 
--manifests  -- 
C:\PROGRA~2\MIB055~1\2017\COMMUN~1\VC\Tools\MSVC\1416~1.270\bin\Hostx64\x64\link.exe
 /nologo 
tools\clang\tools\extra\clang-query\tool\CMakeFiles\clang-query.dir\ClangQuery.cpp.obj
 
tools\clang\tools\extra\clang-query\tool\CMakeFiles\clang-query.dir\__\__\__\__\__\__\resources\windows_version_resource.rc.res
  /out:bin\clang-query.exe /implib:lib\clang-query.lib /pdb:bin\clang-query.pdb 
/version:0.0  /machine:x64 /STACK:1000 /INCREMENTAL:NO /subsystem:console  
lib\LLVMLineEditor.lib lib\LLVMSupport.lib lib\clangAST.lib 
lib\clangASTMatchers.lib lib\clangBasic.lib lib\clangDynamicASTMatchers.lib 
lib\clangFrontend.lib lib\clangQuery.lib lib\clangSerialization.lib 
lib\clangTooling.lib lib\LLVMLineEditor.lib lib\clangDynamicASTMatchers.lib 
lib\clangFrontend.lib lib\clangParse.lib lib\LLVMMCParser.lib 
lib\LLVMProfileData.lib lib\clangSerialization.lib lib\clangSema.lib 
lib\clangEdit.lib lib\clangAnalysis.lib lib\clangASTMatchers.lib 
lib\LLVMBitReader.lib lib\clangDriver.lib version.lib lib\LLVMOption.lib 
lib\clangFormat.lib lib\clangToolingInclusions.lib lib\clangToolingCore.lib 
lib\clangAST.lib lib\clangRewrite.lib lib\clangLex.lib lib\clangBasic.lib 
lib\LLVMCore.lib lib\LLVMRemarks.lib lib\LLVMMC.lib lib\LLVMBinaryFormat.lib 
lib\LLVMDebugInfoCodeView.lib lib\LLVMDebugInfoMSF.lib lib\LLVMSupport.lib 
psapi.lib shell32.lib ole32.lib uuid.lib advapi32.lib delayimp.lib 
-delayload:shell32.dll -delayload:ole32.dll lib\LLVMDemangle.lib kernel32.lib 
user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib 
comdlg32.lib advapi32.lib && cd ."
LINK: command 
"C:\PROGRA~2\MIB055~1\2017\COMMUN~1\VC\Tools\MSVC\1416~1.270\bin\Hostx64\x64\link.exe
 /nologo 
tools\clang\tools\extra\clang-query\tool\CMakeFiles\clang-query.dir\ClangQuery.cpp.obj
 
tools\clang\tools\extra\clang-query\tool\CMakeFiles\clang-query.dir\__\__\__\__\__\__\resources\windows_version_resource.rc.res
 /out:bin\clang-query.exe /implib:lib\clang-query.lib /pdb:bin\clang-query.pdb 
/version:0.0 /machine:x64 /STACK:1000 /INCREMENTAL:NO /subsystem:console 
lib\LLVMLineEditor.lib lib\LLVMSupport.lib lib\clangAST.lib 
lib\clangASTMatchers.lib lib\clangBasic.lib lib\clangDynamicASTMatchers.lib 
lib\clangFrontend.lib lib\clangQuery.lib lib\clangSerialization.lib 
lib\clangTooling.lib lib\LLVMLineEditor.lib lib\clangDynamicASTMatchers.lib 
lib\clangFrontend.lib lib\clangParse.lib lib\LLVMMCParser.lib 
lib\LLVMProfileData.lib lib\clangSerialization.lib lib\clangSema.lib 
lib\clangEdit.lib lib\clangAnalysis.lib lib\clangASTMatchers.lib 
lib\LLVMBitReader.lib lib\clangDriver.lib version.lib lib\LLVMOption.lib 
lib\clangFormat.lib lib\clangToolingInclusions.lib lib\clangToolingCore.lib 
lib\clangAST.lib lib\clangRewrite.lib lib\clangLex.lib lib\clangBasic.lib 
lib\LLVMCore.lib lib\LLVMRemarks.lib lib\LLVMMC.lib lib\LLVMBinaryFormat.lib 
lib\LLVMDebugInfoCodeView.lib lib\LLVMDebugInfoMSF.lib lib\LLVMSupport.lib 
psapi.lib shell32.lib ole32.lib uuid.lib advapi32.lib delayimp.lib 
-delayload:shell32.dll -delayload:ole32.dll lib\LLVMDemangle.lib kernel32.lib 
user32.lib gdi32.lib winspool.lib shell32.lib ole32.lib oleaut32.lib uuid.lib 
comdlg32.lib advapi32.lib /MANIFEST /MANIFESTFILE:bin\clang-query.exe.manifest" 
failed (exit code 1120) with the following output:
clangDynamicASTMatchers.lib(Registry.cpp.obj) : error LNK2019: unresolved 
external symbol "class 
clang::ast_matchers::internal::VariadicDynCastAllOfMatcher const 
clang::ast_matchers::cxxDeductionGuideDecl" 
(?cxxDeductionGuideDecl@ast_matchers@clang@@3V?$VariadicDynCastAllOfMatcher@VDecl@clang@@VCXXDeductionGuideDecl@2@@internal@12@B)
 referenced in function "public: __cdecl 
clang::ast_matchers::dynamic::`anonymous 
namespace'::RegistryMaps::RegistryMaps(void)" 
(??0RegistryMaps@?A0x914e59e4@dynamic@ast_matchers@clang@@QEAA@XZ)
bin\clang-query.exe : fatal error LNK1120: 1 unresolved externals

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of Gauthier 
Harnisch via cfe-commits
Sent: Wednesday, June 19, 2019 11:28
To: cfe-commits@lists.llvm.org
Subject: r363855 - [clang] Adapt ASTMatcher to explicit(bool) specifier

Author: tyker
Date: Wed Jun 19 11:27:56 2019
New Revision: 363855

URL: http://llvm.org/viewvc/llvm-project?rev=363855&view=rev
Log:
[clang] Adapt ASTMatcher to explicit(bool) specifier

Summary:
Changes:
 - add an ast matcher for deductiong guide.
 - allow isExplicit matcher for deductiong guide.
 - 

RE: [clang-tools-extra] r365937 - [clang-doc] Add html links to references

[via cfe-commits]

Hi Diego and Julie,

The tests you modified, emitFunctionHTML and emitRecordHTML are failing when 
run on Windows due to path separator differences.

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/26925

FAIL: Extra Tools Unit Tests :: 
clang-doc/./ClangDocTests.exe/HTMLGeneratorTest.emitFunctionHTML (20152 of 
51140)
 TEST 'Extra Tools Unit Tests :: 
clang-doc/./ClangDocTests.exe/HTMLGeneratorTest.emitFunctionHTML' FAILED 

Note: Google Test filter = HTMLGeneratorTest.emitFunctionHTML

[==] Running 1 test from 1 test case.

[--] Global test environment set-up.

[--] 1 test from HTMLGeneratorTest

[ RUN  ] HTMLGeneratorTest.emitFunctionHTML

C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\unittests\clang-doc\HTMLGeneratorTest.cpp(174):
 error:   Expected: Expected

  Which is: "\n\n\n\n  f\n  \nfloat\n f(\nint\n P)\n  \n  \nDefined at line 
10 of test.cpp\n  \n\n"

To be equal to: Actual.str()

  Which is: "\n\n\n\n  f\n  \nfloat\n f(\nint\n P)\n  \n  \nDefined at line 
10 of test.cpp\n  \n\n"

With diff:

@@ -5,7 +5,7 @@

   f

   

-float

+float

  f(

-int

+int

  P)

   



[  FAILED  ] HTMLGeneratorTest.emitFunctionHTML (1 ms)

[--] 1 test from HTMLGeneratorTest (1 ms total)



[--] Global test environment tear-down

[==] 1 test from 1 test case ran. (1 ms total)

[  PASSED  ] 0 tests.

[  FAILED  ] 1 test, listed below:

[  FAILED  ] HTMLGeneratorTest.emitFunctionHTML



 1 FAILED TEST



PASS: Clangd Unit Tests :: ./ClangdTests.exe/CompletionTest.CompletionOptions 
(20153 of 51140)
FAIL: Extra Tools Unit Tests :: 
clang-doc/./ClangDocTests.exe/HTMLGeneratorTest.emitRecordHTML (20154 of 51140)
 TEST 'Extra Tools Unit Tests :: 
clang-doc/./ClangDocTests.exe/HTMLGeneratorTest.emitRecordHTML' FAILED 

Note: Google Test filter = HTMLGeneratorTest.emitRecordHTML

[==] Running 1 test from 1 test case.

[--] Global test environment set-up.

[--] 1 test from HTMLGeneratorTest

[ RUN  ] HTMLGeneratorTest.emitRecordHTML

C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\unittests\clang-doc\HTMLGeneratorTest.cpp(135):
 error:   Expected: Expected

  Which is: "\n\nclass 
r\n\n  class r\n  \nDefined at line 10 of 
test.cpp\n  \n  \nInherits from \nF\n, G\n  \n  Members\n  
\nprivate int X\n  \n  
Records\n  \nChildStruct\n  \n  
Functions\n  \nOneFunction\n\n  
OneFunction()\n\n  \n  Enums\n  \nenum 
OneEnum\n  \n\n"

To be equal to: Actual.str()

  Which is: "\n\nclass 
r\n\n  class r\n  \nDefined at line 10 of 
test.cpp\n  \n  \nInherits from \nF\n, G\n  \n  
Members\n  \nprivate int 
X\n  \n  Records\n  \nChildStruct\n  
\n  Functions\n  \nOneFunction\n\n  
OneFunction()\n\n  \n  Enums\n  \nenum 
OneEnum\n  \n\n"

With diff:

@@ -9,5 +9,5 @@

   

 Inherits from 

-F

+F

 , G

   

@@ -14,5 +14,5 @@

   Members

   

-private int X

+private int X

   

   Records



[  FAILED  ] HTMLGeneratorTest.emitRecordHTML (1 ms)

[--] 1 test from HTMLGeneratorTest (1 ms total)



[--] Global test environment tear-down

[==] 1 test from 1 test case ran. (1 ms total)

[  PASSED  ] 0 tests.

[  FAILED  ] 1 test, listed below:

[  FAILED  ] HTMLGeneratorTest.emitRecordHTML



 1 FAILED TEST

Can you please take a look?

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of Julie 
Hockett via cfe-commits
Sent: Friday, July 12, 2019 11:32
To: cfe-commits@lists.llvm.org
Subject: [clang-tools-extra] r365937 - [clang-doc] Add html links to references

Author: juliehockett
Date: Fri Jul 12 11:32:00 2019
New Revision: 365937

URL: http://llvm.org/viewvc/llvm-project?rev=365937&view=rev
Log:
[clang-doc] Add html links to references

 tags are added for the parents and members of records and return type and
params of functions. The link redirects to the reference's info file.

The directory path where each info file will be saved is now generated in the
serialization phase and stored as an attribute in each Info.

Bitcode writer and reader were modified to handle the new attributes.

Committed on behalf of Diego Astiazarán (diegoaa...@gmail.com).

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

Modified:
clang-tools-extra/trunk/clang-doc/BitcodeReader.cpp
clang-tools-extra/trunk/clang-doc/BitcodeWriter.cpp
clang-tools-extra/trunk/clang-doc/BitcodeWriter.h
clang-tools-extra/trunk/clang-doc/Generators.cpp
clang-tools-extra/trunk/clang-doc/Generators.h
clang-tools-extra/tr

RE: [clang-tools-extra] r363975 - [clang-tidy] Fail gracefully upon empty database fields

[via cfe-commits]

Hi Serge,

The test you added here is failing on the PS4 Windows build bot, can you take a 
look?

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/26513/steps/test/logs/stdio

FAIL: Clang Tools :: clang-tidy/empty-database.cpp (14917 of 50455)
 TEST 'Clang Tools :: clang-tidy/empty-database.cpp' FAILED 

Script:
--
: 'RUN: at line 1';   not clang-tidy -p 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy/Inputs/empty-database
 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp
 2>&1 | FileCheck 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp
--
Exit Code: 1

Command Output (stdout):
--
$ ":" "RUN: at line 1"
$ "not" "clang-tidy" "-p" 
"C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy/Inputs/empty-database"
 
"C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp"
note: command had no output on stdout or stderr
error: command failed with exit status: 1
$ "FileCheck" 
"C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp"
# command stderr:
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp:3:11:
 error: CHECK: expected string not found in input

// CHECK: LLVM ERROR: Cannot chdir into ""!

  ^

:1:1: note: scanning from here

Skipping 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp.
 Compile command not found.

^

:1:150: note: possible intended match here

Skipping 
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\tools\extra\test\clang-tidy\empty-database.cpp.
 Compile command not found.


 ^


error: command failed with exit status: 1

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of Serge 
Guelton via cfe-commits
Sent: Thursday, June 20, 2019 13:26
To: cfe-commits@lists.llvm.org
Subject: [clang-tools-extra] r363975 - [clang-tidy] Fail gracefully upon empty 
database fields

Author: serge_sans_paille
Date: Thu Jun 20 13:25:59 2019
New Revision: 363975

URL: http://llvm.org/viewvc/llvm-project?rev=363975&view=rev
Log:
[clang-tidy] Fail gracefully upon empty database fields

Fix bz#42281

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

Added:
clang-tools-extra/trunk/test/clang-tidy/empty-database/
clang-tools-extra/trunk/test/clang-tidy/empty-database.cpp
clang-tools-extra/trunk/test/clang-tidy/empty-database/compile_commands.json

Added: clang-tools-extra/trunk/test/clang-tidy/empty-database.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/empty-database.cpp?rev=363975&view=auto
==
--- clang-tools-extra/trunk/test/clang-tidy/empty-database.cpp (added)
+++ clang-tools-extra/trunk/test/clang-tidy/empty-database.cpp Thu Jun 20 
13:25:59 2019
@@ -0,0 +1,3 @@
+// RUN: not clang-tidy -p %S/empty-database %s 2>&1 | FileCheck %s
+
+// CHECK: LLVM ERROR: Cannot chdir into ""!

Added: 
clang-tools-extra/trunk/test/clang-tidy/empty-database/compile_commands.json
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/empty-database/compile_commands.json?rev=363975&view=auto
==
--- 
clang-tools-extra/trunk/test/clang-tidy/empty-database/compile_commands.json 
(added)
+++ 
clang-tools-extra/trunk/test/clang-tidy/empty-database/compile_commands.json 
Thu Jun 20 13:25:59 2019
@@ -0,0 +1,4 @@
+[{
+"directory":"",
+"file":"/tmp/","arguments":[]
+}]


___
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: r363985 - [test][Driver] Fix Clang :: Driver/cl-response-file.c

[via cfe-commits]

nal-isystem" 
"C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.17763.0\\shared" 
"-internal-isystem" "C:\\Program Files (x86)\\Windows 
Kits\\10\\include\\10.0.17763.0\\um" "-internal-isystem" "C:\\Program Files 
(x86)\\Windows Kits\\10\\include\\10.0.17763.0\\winrt" "-internal-isystem" 
"C:\\Program Files (x86)\\Windows Kits\\10\\include\\10.0.17763.0\\cppwinrt" 
"-fdebug-compilation-dir" 
"C:\\ps4-buildslave2\\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\\llvm.obj\\tools\\clang\\test\\Driver"
 "-ferror-limit" "19" "-fmessage-length" "0" "-fno-use-cxa-atexit" 
"-fms-extensions" "-fms-compatibility" "-fms-compatibility-version=19.16.27026" 
"-fdelayed-template-parsing" "-fobjc-runtime=gcc" "-fdiagnostics-show-option" 
"-faddrsig" "-o" "cl-response-file.obj" "-x" "c" 
"C:\\ps4-buildslave2\\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\\llvm.src\\tools\\clang\\test\\Driver\\cl-response-file.c"























            






   ^


error: command failed with exit status: 1


Looking into this locally, the path contains "\t", so the response file that is 
generated looks like this:

C:\src\git\merge\llvm\tools\clang\test\Driver>type cl-response-file.c.tmp.rsp
/IC:\src\git\merge\llvm ools

Can you take a look to see if there is something that works for all platforms 
including Windows?

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of Rainer Orth 
via cfe-commits
Sent: Thursday, June 20, 2019 14:33
To: cfe-commits@lists.llvm.org
Subject: r363985 - [test][Driver] Fix Clang :: Driver/cl-response-file.c

Author: ro
Date: Thu Jun 20 14:33:09 2019
New Revision: 363985

URL: http://llvm.org/viewvc/llvm-project?rev=363985&view=rev
Log:
[test][Driver] Fix Clang :: Driver/cl-response-file.c

Clang :: Driver/cl-response-file.c currently FAILs on Solaris:

  Command Output (stderr):
  --
  /vol/llvm/src/clang/dist/test/Driver/cl-response-file.c:10:11: error: CHECK: 
expected string not found in input
  // CHECK: "-I" "{{.*}}\\Inputs\\cl-response-file\\" "-D" "FOO=2"
^

Looking at the generated response file reveals that this is no surprise:

  /I/vol/llvm/src/clang/dist/test/Driver\Inputs

with no newline at the end.  The echo command used to create it boils down to

  echo 'a\cb'

However, one cannot expect \c to be emitted literally: e.g. b

RE: r363985 - [test][Driver] Fix Clang :: Driver/cl-response-file.c

[via cfe-commits]

Hi Rainer,

I tried your patch and it still has problems. First, the "%s" was being 
replaced with the actual path by LIT, so I replaced that with "%%s" which then 
created the response file correctly, but now the response file contains this:

/IC:\src\git\dev\llvm\tools\clang\test\Driver\Inputs\\cl-response-file\ /DFOO=2

Which unfortunately gets interpreted by the compiler as:

"-I" 
"C:\\src\\git\\dev\\llvm\\tools\\clang\\test\\Driver\\Inputscl-response-file\\"
 "-D" "FOO=2"

Which doesn't match the CHECK line. Note the 4 backslashes. I think this could 
probably be fixed by just using a regex to match 1 or more backslashes?

Douglas Yung

-Original Message-
From: Rainer Orth  
Sent: Friday, June 21, 2019 7:02
To: Yung, Douglas 
Cc: r...@gcc.gnu.org; cfe-commits@lists.llvm.org
Subject: Re: r363985 - [test][Driver] Fix Clang :: Driver/cl-response-file.c

Hi Douglas,

> Your change appears to have broken the one platform you didn't test, 
> Windows. :)

sorry about that.  Unfortunately, I know next to nothing about Windows and 
don't have access to any system to test.

That said...

> Script:
> --
> : 'RUN: at line 7'; printf
> '/IC:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast
> \llvm.src\tools\clang\test\Driver\Inputs\\cl-response-file\
> /DFOO=2' >
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\ll
> vm.obj\tools\clang\test\Driver\Output\cl-response-file.c.tmp.rsp

... I should have looked at the autoconf manual first which has a whole section 
on the can of worms that is echo and how to properly use printf instead.

> Looking into this locally, the path contains "\t", so the response file that 
> is generated looks like this:
>
> C:\src\git\merge\llvm\tools\clang\test\Driver>type 
> cl-response-file.c.tmp.rsp /IC:\src\git\merge\llvm ools

The path not only contains \t, but \c as well, so the path is truncated after " 
ools".

> Can you take a look to see if there is something that works for all platforms 
> including Windows?

Judging from both the autoconf manual and my local testing, the following 
should work properly:

// RUN: printf '%s\n' '/I%S\Inputs\\cl-response-file\ /DFOO=2' > %t.rsp

i.e. use printf '%s\n' to do the printing.  I should have done this in the 
first place since otherwise the response file wasn't newline-terminated.  
Obviously that didn't matter on Solaris and Linux.

Once you've confirmed this works on Windows, I'll submit a proper follow-up 
patch.

Rainer

--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: r363985 - [test][Driver] Fix Clang :: Driver/cl-response-file.c

[via cfe-commits]

Hi Rainer,

I figured it out. Because you are using printf, you no longer need the '\\c'. 
If I use the following RUN line, the test passes on both Windows/linux (I don't 
have solaris to test unfortunately):

// RUN: printf '%%s\n' '/I%S\Inputs\cl-response-file\ /DFOO=2' > %t.rsp

I can submit this patch for you if you would like.

Douglas Yung

-Original Message-
From: Rainer Orth  
Sent: Friday, June 21, 2019 7:02
To: Yung, Douglas 
Cc: r...@gcc.gnu.org; cfe-commits@lists.llvm.org
Subject: Re: r363985 - [test][Driver] Fix Clang :: Driver/cl-response-file.c

Hi Douglas,

> Your change appears to have broken the one platform you didn't test, 
> Windows. :)

sorry about that.  Unfortunately, I know next to nothing about Windows and 
don't have access to any system to test.

That said...

> Script:
> --
> : 'RUN: at line 7'; printf
> '/IC:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast
> \llvm.src\tools\clang\test\Driver\Inputs\\cl-response-file\
> /DFOO=2' >
> C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\ll
> vm.obj\tools\clang\test\Driver\Output\cl-response-file.c.tmp.rsp

... I should have looked at the autoconf manual first which has a whole section 
on the can of worms that is echo and how to properly use printf instead.

> Looking into this locally, the path contains "\t", so the response file that 
> is generated looks like this:
>
> C:\src\git\merge\llvm\tools\clang\test\Driver>type 
> cl-response-file.c.tmp.rsp /IC:\src\git\merge\llvm ools

The path not only contains \t, but \c as well, so the path is truncated after " 
ools".

> Can you take a look to see if there is something that works for all platforms 
> including Windows?

Judging from both the autoconf manual and my local testing, the following 
should work properly:

// RUN: printf '%s\n' '/I%S\Inputs\\cl-response-file\ /DFOO=2' > %t.rsp

i.e. use printf '%s\n' to do the printing.  I should have done this in the 
first place since otherwise the response file wasn't newline-terminated.  
Obviously that didn't matter on Solaris and Linux.

Once you've confirmed this works on Windows, I'll submit a proper follow-up 
patch.

Rainer

--
-
Rainer Orth, Center for Biotechnology, Bielefeld University
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: r363985 - [test][Driver] Fix Clang :: Driver/cl-response-file.c

[via cfe-commits]

I see Reid has reverted your original fix so instead of directly submitting, I 
have put the patch up for review first at https://reviews.llvm.org/D63678.

Douglas Yung

-Original Message-
From: Rainer Orth  
Sent: Friday, June 21, 2019 14:46
To: Yung, Douglas 
Cc: cfe-commits@lists.llvm.org
Subject: Re: r363985 - [test][Driver] Fix Clang :: Driver/cl-response-file.c

Hi Douglas,

> I figured it out. Because you are using printf, you no longer need the 
> '\\c'. If I use the following RUN line, the test passes on both 
> Windows/linux (I don't have solaris to test unfortunately):
>
> // RUN: printf '%%s\n' '/I%S\Inputs\cl-response-file\ /DFOO=2' > 
> %t.rsp

I've now tested it myself successfully on amd64-pc-solaris2.11.  I'd figured 
the \\c -> \c part out already, but had to leave before understanding the %s 
problem.

> I can submit this patch for you if you would like.

That would be great, thanks a lot.

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

RE: [clang-tools-extra] r365123 - [clangd] Make HadErrors part of background index's internal state

[via cfe-commits]

Hi Kadir,

Your change is causing a build failure on our internal linux build bot running 
gcc 5.4:

FAILED: CCACHE_CPP2=yes CCACHE_HASHDIR=yes /usr/bin/ccache /usr/lib/ccache/g++  
 -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -Itools/clang/tools/extra/clangd 
-I/home/siadmin/jenkins/w/opensource/opensource_build/llvm/tools/clang/tools/extra/clangd
 -I/home/siadmin/jenkins/w/opensource/opensource_build/llvm/tools/clang/include 
-Itools/clang/include -Iinclude 
-I/home/siadmin/jenkins/w/opensource/opensource_build/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 
-Wno-maybe-uninitialized -Wdelete-non-virtual-dtor -Wno-comment 
-fdiagnostics-color -ffunction-sections -fdata-sections -fno-common 
-Woverloaded-virtual -fno-strict-aliasing -O3-UNDEBUG  -fno-exceptions 
-fno-rtti -MMD -MT 
tools/clang/tools/extra/clangd/CMakeFiles/obj.clangDaemon.dir/ClangdLSPServer.cpp.o
 -MF 
tools/clang/tools/extra/clangd/CMakeFiles/obj.clangDaemon.dir/ClangdLSPServer.cpp.o.d
 -o 
tools/clang/tools/extra/clangd/CMakeFiles/obj.clangDaemon.dir/ClangdLSPServer.cpp.o
 -c 
/home/siadmin/jenkins/w/opensource/opensource_build/llvm/tools/clang/tools/extra/clangd/ClangdLSPServer.cpp
In file included from 
/home/siadmin/jenkins/w/opensource/opensource_build/llvm/tools/clang/tools/extra/clangd/ClangdServer.h:24:0,
 from 
/home/siadmin/jenkins/w/opensource/opensource_build/llvm/tools/clang/tools/extra/clangd/ClangdLSPServer.h:12,
 from 
/home/siadmin/jenkins/w/opensource/opensource_build/llvm/tools/clang/tools/extra/clangd/ClangdLSPServer.cpp:9:
/home/siadmin/jenkins/w/opensource/opensource_build/llvm/tools/clang/tools/extra/clangd/index/Background.h:99:24:
 error: array must be initialized with a brace-enclosed initializer
 FileDigest Digest{0};
^

Can you please take a look?

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of Kadir 
Cetinkaya via cfe-commits
Sent: Thursday, July 4, 2019 2:52
To: cfe-commits@lists.llvm.org
Subject: [clang-tools-extra] r365123 - [clangd] Make HadErrors part of 
background index's internal state

Author: kadircet
Date: Thu Jul  4 02:52:12 2019
New Revision: 365123

URL: http://llvm.org/viewvc/llvm-project?rev=365123&view=rev
Log:
[clangd] Make HadErrors part of background index's internal state

Reviewers: sammccall

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

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clangd/index/Background.cpp
clang-tools-extra/trunk/clangd/index/Background.h
clang-tools-extra/trunk/clangd/unittests/BackgroundIndexTests.cpp

Modified: clang-tools-extra/trunk/clangd/index/Background.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/index/Background.cpp?rev=365123&r1=365122&r2=365123&view=diff
==
--- clang-tools-extra/trunk/clangd/index/Background.cpp (original)
+++ clang-tools-extra/trunk/clangd/index/Background.cpp Thu Jul  4 
+++ 02:52:12 2019
@@ -101,28 +101,6 @@ IncludeGraph getSubGraph(const URI &U, c
   return IG;
 }
 
-// Creates a filter to not collect index results from files with unchanged -// 
digests.
-// \p FileDigests contains file digests for the current indexed files.
-decltype(SymbolCollector::Options::FileFilter)
-createFileFilter(const llvm::StringMap &FileDigests) {
-  return [&FileDigests](const SourceManager &SM, FileID FID) {
-const auto *F = SM.getFileEntryForID(FID);
-if (!F)
-  return false; // Skip invalid files.
-auto AbsPath = getCanonicalPath(F, SM);
-if (!AbsPath)
-  return false; // Skip files without absolute path.
-auto Digest = digestFile(SM, FID);
-if (!Digest)
-  return false;
-auto D = FileDigests.find(*AbsPath);
-if (D != FileDigests.end() && D->second == Digest)
-  return false; // Skip files that haven't changed.
-return true;
-  };
-}
-
 // We cannot use vfs->makeAbsolute because Cmd.FileName is either absolute or  
// relative to Cmd.Directory, which might not be the same as current working  
// directory.
@@ -274,12 +252,12 @@ void BackgroundIndex::enqueueTask(Task T  }
 
 /// Given index results from a TU, only update symbols coming from files that 
-/// are different or missing from than \p DigestsSnapshot. Also stores new 
index -/// information on IndexStorage.
-void BackgroundIndex::update(llvm::StringRef MainFile, IndexFileIn Index,
- const llvm::StringMap 
&DigestsSnapshot,
- BackgroundIndexStorage *IndexStorage,
- bool HadErrors) {
+/// 

RE: r360452 - Replace 'REQUIRES: nozlib' with '!zlib' because we don't need two ways

[via cfe-commits]

There's no practical difference.  I view it as a matter of documentation of 
intent, see my commit log comment for r360603.
Arguably we could eliminate UNSUPPORTED and move all the expressions into 
REQUIRES (appropriately negated), but I'm not sure that's a net win for 
readability.
--paulr

From: David Blaikie [mailto:dblai...@gmail.com]
Sent: Monday, May 13, 2019 10:48 AM
To: Robinson, Paul
Cc: cfe-commits
Subject: Re: r360452 - Replace 'REQUIRES: nozlib' with '!zlib' because we don't 
need two ways

What's the practical difference between "UNSUPPORTED: foo" and "REQUIRES: 
!foo"? (I see some of the fixes you've made go one way, some the other way)

On Fri, May 10, 2019 at 11:30 AM Paul Robinson via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: probinson
Date: Fri May 10 11:32:53 2019
New Revision: 360452

URL: http://llvm.org/viewvc/llvm-project?rev=360452&view=rev
Log:
Replace 'REQUIRES: nozlib' with '!zlib' because we don't need two ways
to say the same thing.

Modified:
cfe/trunk/test/Driver/nozlibcompress.c

Modified: cfe/trunk/test/Driver/nozlibcompress.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/nozlibcompress.c?rev=360452&r1=360451&r2=360452&view=diff
==
--- cfe/trunk/test/Driver/nozlibcompress.c (original)
+++ cfe/trunk/test/Driver/nozlibcompress.c Fri May 10 11:32:53 2019
@@ -1,4 +1,4 @@
-// REQUIRES: nozlib
+// REQUIRES: !zlib

 // RUN: %clang -### -fintegrated-as -gz -c %s 2>&1 | FileCheck %s 
-check-prefix CHECK-WARN
 // RUN: %clang -### -fintegrated-as -gz=none -c %s 2>&1 | FileCheck 
-allow-empty -check-prefix CHECK-NOWARN %s


___
cfe-commits mailing list
cfe-commits@lists.llvm.org<mailto: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: r360452 - Replace 'REQUIRES: nozlib' with '!zlib' because we don't need two ways

[via cfe-commits]

> -Original Message-
> From: David Blaikie [mailto:dblai...@gmail.com]
> Sent: Tuesday, May 14, 2019 1:47 PM
> To: Robinson, Paul
> Cc: cfe-commits
> Subject: Re: r360452 - Replace 'REQUIRES: nozlib' with '!zlib' because we
> don't need two ways
> 
> Fair enough - since they're already there I don't feel super serious
> about converging on one (though I probably wouldn't've been in favor
> of adding a second spelling at the point it was proposed).

UNSUPPORTED came first, in 2014, followed by the rare REQUIRES-ANY
in 2016, followed by boolean expression syntax in 2017.  UNSUPPORTED
is particularly popular in the libcxx suite (over 2000 tests) so I
doubt there's enough motivation to remove it.  REQUIRES-ANY could be 
tossed though, 17 occurrences across clang and compiler-rt.

I do see one test in clang that uses UNSUPPORTED as a FileCheck prefix,
I'll make a note to change that next time I need a break from real work.
--paulr

> 
> On Tue, May 14, 2019 at 8:03 AM  wrote:
> >
> > There's no practical difference.  I view it as a matter of documentation
> of intent, see my commit log comment for r360603.
> >
> > Arguably we could eliminate UNSUPPORTED and move all the expressions
> into REQUIRES (appropriately negated), but I'm not sure that's a net win
> for readability.
> >
> > --paulr
> >
> >
> >
> > From: David Blaikie [mailto:dblai...@gmail.com]
> > Sent: Monday, May 13, 2019 10:48 AM
> > To: Robinson, Paul
> > Cc: cfe-commits
> > Subject: Re: r360452 - Replace 'REQUIRES: nozlib' with '!zlib' because
> we don't need two ways
> >
> >
> >
> > What's the practical difference between "UNSUPPORTED: foo" and
> "REQUIRES: !foo"? (I see some of the fixes you've made go one way, some
> the other way)
> >
> >
> >
> > On Fri, May 10, 2019 at 11:30 AM Paul Robinson via cfe-commits  comm...@lists.llvm.org> wrote:
> >
> > Author: probinson
> > Date: Fri May 10 11:32:53 2019
> > New Revision: 360452
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=360452&view=rev
> > Log:
> > Replace 'REQUIRES: nozlib' with '!zlib' because we don't need two ways
> > to say the same thing.
> >
> > Modified:
> > cfe/trunk/test/Driver/nozlibcompress.c
> >
> > Modified: cfe/trunk/test/Driver/nozlibcompress.c
> > URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/test/Driver/nozlibcompress.c?rev=360452&r1=360451&r2=360
> 452&view=diff
> >
> ==
> 
> > --- cfe/trunk/test/Driver/nozlibcompress.c (original)
> > +++ cfe/trunk/test/Driver/nozlibcompress.c Fri May 10 11:32:53 2019
> > @@ -1,4 +1,4 @@
> > -// REQUIRES: nozlib
> > +// REQUIRES: !zlib
> >
> >  // RUN: %clang -### -fintegrated-as -gz -c %s 2>&1 | FileCheck %s -
> check-prefix CHECK-WARN
> >  // RUN: %clang -### -fintegrated-as -gz=none -c %s 2>&1 | FileCheck -
> allow-empty -check-prefix CHECK-NOWARN %s
> >
> >
> > ___
> > 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: r360833 - [Clang][PP] Add the __FILE_NAME__ builtin macro.

[via cfe-commits]

Hi Kristina,

Your change does not seem to be working on Windows. Can you take a look?

http://lab.llvm.org:8011/builders/clang-x64-windows-msvc/builds/6860

FAIL: Clang :: Preprocessor/file_name_macro.c (7959 of 14753)
 TEST 'Clang :: Preprocessor/file_name_macro.c' FAILED 

Script:
--
: 'RUN: at line 1';   
c:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\clang.exe -cc1 
-internal-isystem 
c:\b\slave\clang-x64-windows-msvc\build\build\stage1\lib\clang\9.0.0\include 
-nostdsysteminc -E 
C:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\clang\test\Preprocessor\file_name_macro.c
 
-IC:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\clang\test\Preprocessor/Inputs
 | c:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\filecheck.exe 
-strict-whitespace 
C:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\clang\test\Preprocessor\file_name_macro.c
: 'RUN: at line 2';   
c:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\clang.exe -cc1 
-internal-isystem 
c:\b\slave\clang-x64-windows-msvc\build\build\stage1\lib\clang\9.0.0\include 
-nostdsysteminc -fms-compatibility -DMS -E 
C:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\clang\test\Preprocessor\file_name_macro.c
 
-IC:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\clang\test\Preprocessor/Inputs
 | c:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\filecheck.exe 
-check-prefix=CHECK-MS -strict-whitespace 
C:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\clang\test\Preprocessor\file_name_macro.c
: 'RUN: at line 3';   
c:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\clang.exe -cc1 
-internal-isystem 
c:\b\slave\clang-x64-windows-msvc\build\build\stage1\lib\clang\9.0.0\include 
-nostdsysteminc -E 
C:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\clang\test\Preprocessor\file_name_macro.c
 
-IC:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\clang\test\Preprocessor/Inputs
 -DBADINC -verify
--
Exit Code: 1

Command Output (stdout):
--
$ ":" "RUN: at line 1"
$ "c:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\clang.exe" "-cc1" 
"-internal-isystem" 
"c:\b\slave\clang-x64-windows-msvc\build\build\stage1\lib\clang\9.0.0\include" 
"-nostdsysteminc" "-E" 
"C:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\clang\test\Preprocessor\file_name_macro.c"
 
"-IC:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\clang\test\Preprocessor/Inputs"
$ "c:\b\slave\clang-x64-windows-msvc\build\build\stage1\bin\filecheck.exe" 
"-strict-whitespace" 
"C:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\clang\test\Preprocessor\file_name_macro.c"
# command stderr:
C:\b\slave\clang-x64-windows-msvc\build\llvm.src\tools\clang\test\Preprocessor\file_name_macro.c:22:11:
 error: CHECK: expected string not found in input

// CHECK: {{^}}2: "file_name_macro.c"

  ^

:12:1: note: scanning from here

2: 
"C:\\b\\slave\\clang-x64-windows-msvc\\build\\llvm.src\\tools\\clang\\test\\Preprocessor\\file_name_macro.c"

^

:12:87: note: possible intended match here

2: 
"C:\\b\\slave\\clang-x64-windows-msvc\\build\\llvm.src\\tools\\clang\\test\\Preprocessor\\file_name_macro.c"

            
  ^


error: command failed with exit status: 1

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of Kristina 
Brooks via cfe-commits
Sent: Wednesday, May 15, 2019 17:53
To: cfe-commits@lists.llvm.org
Subject: r360833 - [Clang][PP] Add the __FILE_NAME__ builtin macro.

Author: kristina
Date: Wed May 15 17:52:41 2019
New Revision: 360833

URL: http://llvm.org/viewvc/llvm-project?rev=360833&view=rev
Log:
[Clang][PP] Add the __FILE_NAME__ builtin macro.

This patch adds the `__FILE_NAME__` macro that expands to the last component of 
the path, similar to `__FILE__` except with a guarantee that only the last path 
component (without the
separator) will be rendered.

I intend to follow through with discussion of this with WG14 as a potential 
inclusion in the C standard or failing that, try to discuss this with GCC 
developers since this extension is desired by GCC and Clang users/developers 
alike.

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


Added:
cfe/trunk/test/Preprocessor/Inputs/include-subdir/
cfe/trunk/test/Preprocessor/Inputs/include-subdir/file_name_macro_include.h
cfe/trunk/test/Preprocessor/Inputs/include-subdir/h
cfe/trunk/test/Preprocessor/Inputs/include-subdir/subdir1/
cfe/trunk/test/Preprocessor/Inputs/include-subdir/subdir1/hdr1.h
cfe/trunk/test/Preprocessor/Inputs/include-subdir/subdir1/hdr2.h
cfe/trunk/test/Preprocessor/file_name_macro.c
Modified:
cfe/trunk/include/clang/Lex/Preprocessor.h
cfe/trunk/lib/

RE: r360974 - Refactor constant evaluation of typeid(T) to track a symbolic type_info

[via cfe-commits]

I'm not sure that is problem. Our internal linux build bot also hit the same 
problem and it has a 64-bit CPU.

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of Chris 
Bieneman via cfe-commits
Sent: Thursday, May 16, 2019 22:45
To: Chris Bieneman 
Cc: Richard Smith ; cfe-commits@lists.llvm.org
Subject: Re: r360974 - Refactor constant evaluation of typeid(T) to track a 
symbolic type_info

I did some digging before reverting. The bots your patch is failing on are 
32-bit CPUs. It looks like your static_assert is assuming 8-byte aligned 
pointers, so it always fails on the 32-bit builders.

-Chris

> On May 16, 2019, at 10:14 PM, Chris Bieneman  wrote:
> 
> Sorry to do this, but I'm also reverting r360977, because it seems to be on 
> top of this one.
> 
> -Chris
> 
>> On May 16, 2019, at 9:58 PM, Chris Bieneman via cfe-commits 
>>  wrote:
>> 
>> Hey Richard,
>> 
>> This change is tripping up a bunch of the bots:
>> 
>> http://lab.llvm.org:8011/builders/clang-cmake-armv8-lld/builds/1397
>> 
>> I'm going to revert it so that we don't leave the bots broken overnight.
>> 
>> -Chris
>> 
>>> On May 16, 2019, at 6:46 PM, Richard Smith via cfe-commits 
>>>  wrote:
>>> 
>>> Author: rsmith
>>> Date: Thu May 16 18:46:05 2019
>>> New Revision: 360974
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=360974&view=rev
>>> Log:
>>> Refactor constant evaluation of typeid(T) to track a symbolic 
>>> type_info object rather than tracking the originating expression.
>>> 
>>> This is groundwork for supporting polymorphic typeid expressions. 
>>> (Note that this somewhat regresses our support for DR1968, but it 
>>> turns out that that never actually worked anyway, at least in 
>>> non-trivial cases.)
>>> 
>>> Modified:
>>>  cfe/trunk/include/clang/AST/APValue.h
>>>  cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td
>>>  cfe/trunk/lib/AST/APValue.cpp
>>>  cfe/trunk/lib/AST/ExprConstant.cpp
>>>  cfe/trunk/lib/CodeGen/CGExprConstant.cpp
>>>  cfe/trunk/lib/Sema/SemaTemplate.cpp
>>>  cfe/trunk/test/CXX/drs/dr19xx.cpp
>>>  cfe/trunk/test/Parser/MicrosoftExtensions.cpp
>>>  cfe/trunk/test/SemaCXX/builtin-constant-p.cpp
>>>  cfe/trunk/test/SemaCXX/typeid.cpp
>>>  cfe/trunk/www/cxx_dr_status.html
>>> 
>>> Modified: cfe/trunk/include/clang/AST/APValue.h
>>> URL: 
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/APVa
>>> lue.h?rev=360974&r1=360973&r2=360974&view=diff
>>> 
>>> ==
>>> --- cfe/trunk/include/clang/AST/APValue.h (original)
>>> +++ cfe/trunk/include/clang/AST/APValue.h Thu May 16 18:46:05 2019
>>> @@ -24,14 +24,52 @@ namespace clang { class AddrLabelExpr; class 
>>> ASTContext; class CharUnits;
>>> +  class CXXRecordDecl;
>>> +  class Decl;
>>> class DiagnosticBuilder;
>>> class Expr;
>>> class FieldDecl;
>>> -  class Decl;
>>> +  struct PrintingPolicy;
>>> +  class Type;
>>> class ValueDecl;
>>> -  class CXXRecordDecl;
>>> -  class QualType;
>>> 
>>> +/// Symbolic representation of typeid(T) for some type T.
>>> +class TypeInfoLValue {
>>> +  const Type *T;
>>> +
>>> +public:
>>> +  TypeInfoLValue() : T() {}
>>> +  explicit TypeInfoLValue(const Type *T);
>>> +
>>> +  const Type *getType() const { return T; }  explicit operator 
>>> + bool() const { return T; }
>>> +
>>> +  void *getOpaqueValue() { return const_cast(T); }  static 
>>> + TypeInfoLValue getFromOpaqueValue(void *Value) {
>>> +TypeInfoLValue V;
>>> +V.T = reinterpret_cast(Value);
>>> +return V;
>>> +  }
>>> +
>>> +  void print(llvm::raw_ostream &Out, const PrintingPolicy &Policy) 
>>> +const; }; }
>>> +
>>> +namespace llvm {
>>> +template<> struct PointerLikeTypeTraits {
>>> +  static void *getAsVoidPointer(clang::TypeInfoLValue V) {
>>> +return V.getOpaqueValue();
>>> +  }
>>> +  static clang::TypeInfoLValue getFromVoidPointer(void *P) {
>>> +return clang::TypeInfoLValue::getFromOpaqueValue(P);
>>> +  }
>>> +  // Validated by static_assert in APValue.cpp; hardcoded to avoid 
>>> +needing
>>> +  // to inclu

RE: r361278 - [clang][Darwin] Refactor header search path logic into the driver

[via cfe-commits]

Hi Louis,

The three tests you added all seem to be failing when run on Windows. I suspect 
the reason is because you define TOOLCHAIN as an argument to FileCheck, which 
causes the line separators to be escaped, which then causes the FileCheck to 
fail.

For example, see this test output 
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/25983/steps/test/logs/stdio:

FAIL: Clang :: Driver/darwin-header-search-libstdcxx.cpp (8570 of 49179)
...
$ 
"c:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.obj\bin\filecheck.exe"
 
"-DTOOLCHAIN=C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Driver/Inputs/basic_darwin_toolchain"
 "--check-prefix=CHECK-LIBCXX-TOOLCHAIN-1" 
"C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Driver\darwin-header-search-libcxx.cpp"
# command stderr:
C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Driver\darwin-header-search-libcxx.cpp:23:30:
 error: CHECK-LIBCXX-TOOLCHAIN-1: expected string not found in input
...
:5:107: note: with variable "TOOLCHAIN" equal to 
"C:ps4-buildslave2llvm-clang-lld-x86_64-scei-ps4-windows10pro-fastllvm\\.srctoolsclangtestDriver/Inputs/basic_darwin_toolchain"
...
:5:901: note: possible intended match here

 
"c:\\ps4-buildslave2\\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\\llvm.obj\\bin\\clang.exe"
 "-cc1" "-triple" "x86_64-apple-macosx10.4.0" "-Wdeprecated-objc-isa-usage" 
"-Werror=deprecated-objc-isa-usage" "-fsyntax-only" "-disable-free" 
"-main-file-name" "darwin-header-search-libcxx.cpp" "-mrelocation-model" "pic" 
"-pic-level" "2" "-mthread-model" "posix" "-mdisable-fp-elim" "-masm-verbose" 
"-munwind-tables" "-faligned-alloc-unavailable" "-target-cpu" "core2" 
"-dwarf-column-info" "-debugger-tuning=lldb" "-ggnu-pubnames" "-resource-dir" 
"c:\\ps4-buildslave2\\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\\llvm.obj\\lib\\clang\\9.0.0"
 "-stdlib=libc++" "-internal-isystem" 
"C:\\ps4-buildslave2\\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\\llvm.src\\tools\\clang\\test\\Driver/Inputs/basic_darwin_toolchain/usr/bin\\..\\include\\c++\\v1"
 "-internal-isystem" "/usr\\include\\c++\\v1" "-internal-isystem" 
"/usr\\local\\include" "-internal-isystem" 
"c:\\ps4-buildslave2\\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\\llvm.obj\\lib\\clang\\9.0.0\\include"
 "-internal-externc-isystem" "/usr\\include" "-fdeprecated-macro" 
"-fdebug-compilation-dir" 
"C:\\ps4-buildslave2\\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\\llvm.obj\\tools\\clang\\test\\Driver"
 "-ferror-limit" "19" "-fmessage-length" "0" "-fblocks" 
"-fblocks-runtime-optional" "-fencode-extended-block-signature" 
"-fregister-global-dtors-with-atexit" "-fobjc-runtime=macosx-10.4.0" 
"-fobjc-dispatch-method=non-legacy" "-fcxx-exceptions" "-fexceptions" 
"-fmax-type-align=16" "-fdiagnostics-show-option" "-x" "c++" 
"C:\\ps4-buildslave2\\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\\llvm.src\\tools\\clang\\test\\Driver\\darwin-header-search-libcxx.cpp"


Note that the path as passed as an argument to FileCheck is 
"C:\ps4-buildslave2\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\llvm.src\tools\clang\test\Driver/Inputs/basic_darwin_toolchain",
 the value of TOOLCHAIN as expected by FileCheck is 
"C:ps4-buildslave2llvm-clang-lld-x86_64-scei-ps4-windows10pro-fastllvm\\.srctoolsclangtestDriver/Inputs/basic_darwin_toolchain",
 but the value in what it likely would match is " 
C:\\ps4-buildslave2\\llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast\\llvm.src\\tools\\clang\\test\\Driver/Inputs/basic_darwin_toolchain".

Can you take a look and fix the test on Windows please?

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of Louis 
Dionne via cfe-commits
Sent: Tuesday, May 21, 2019 10:48
To: cfe-commits@lists.llvm.org
Subject: r361278 - [clang][Darwin] Refactor header search path logic into the 
driver

Author: ldionne
Date: Tue May 21 10:48:04 2019
New Revision: 361278

URL: http://llvm.org/viewvc/llvm-project?rev=361278&view=rev
Log:
[clang][Darwin] Refactor header search path logic into the driver

Summary:
This commit moves the logic for determin

RE: r361562 - Use clang_cc1 instead of clang in CodeGen test.

[via cfe-commits]

Hi Alina,

This test that you added seems to fail on targets that don't build the x86 
backend, for example:

http://lab.llvm.org:8011/builders/clang-cmake-armv7-selfhost-neon/builds/1855

 TEST 'Clang :: CodeGen/loop-vectorize.c' FAILED 

Script:
--
: 'RUN: at line 1';   
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/stage2/bin/clang 
-cc1 -internal-isystem 
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/stage2/lib/clang/9.0.0/include
 -nostdsysteminc -triple x86_64 -target-cpu x86-64 -S -O1 -vectorize-loops 
-emit-llvm -o - 
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/llvm/tools/clang/test/CodeGen/loop-vectorize.c
 | 
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/stage2/bin/FileCheck
 
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/llvm/tools/clang/test/CodeGen/loop-vectorize.c
 -check-prefix=CHECK-ENABLE-VECT
: 'RUN: at line 2';   
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/stage2/bin/clang 
-cc1 -internal-isystem 
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/stage2/lib/clang/9.0.0/include
 -nostdsysteminc -triple x86_64 -target-cpu x86-64 -S -O1 -emit-llvm -o - 
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/llvm/tools/clang/test/CodeGen/loop-vectorize.c
 | 
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/stage2/bin/FileCheck
 
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/llvm/tools/clang/test/CodeGen/loop-vectorize.c
 -check-prefix=CHECK-DISABLE-VECT
: 'RUN: at line 3';   
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/stage2/bin/clang 
-cc1 -internal-isystem 
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/stage2/lib/clang/9.0.0/include
 -nostdsysteminc -triple x86_64 -target-cpu x86-64 
-fexperimental-new-pass-manager -S -O1 -vectorize-loops -emit-llvm -o - 
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/llvm/tools/clang/test/CodeGen/loop-vectorize.c
 | 
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/stage2/bin/FileCheck
 
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/llvm/tools/clang/test/CodeGen/loop-vectorize.c
 -check-prefix=CHECK-ENABLE-VECT
: 'RUN: at line 4';   
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/stage2/bin/clang 
-cc1 -internal-isystem 
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/stage2/lib/clang/9.0.0/include
 -nostdsysteminc -triple x86_64 -target-cpu x86-64 
-fexperimental-new-pass-manager -S -O1 -emit-llvm -o - 
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/llvm/tools/clang/test/CodeGen/loop-vectorize.c
 | 
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/stage2/bin/FileCheck
 
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/llvm/tools/clang/test/CodeGen/loop-vectorize.c
 -check-prefix=CHECK-DISABLE-VECT
--
Exit Code: 1

Command Output (stderr):
--
/home/buildslave/buildslave/clang-cmake-armv7-selfhost-neon/llvm/tools/clang/test/CodeGen/loop-vectorize.c:7:23:
 error: CHECK-ENABLE-VECT: expected string not found in input
// CHECK-ENABLE-VECT: fmul <{{[0-9]+}} x double>
  ^
:9:25: note: scanning from here
define void @for_test() local_unnamed_addr #0 {
^
:11:5: note: possible intended match here
 %A = alloca [1000 x double], align 16
^

--

Can you take a look into fixing the test or running it only when the x86 
backend is present?

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of Alina 
Sbirlea via cfe-commits
Sent: Thursday, May 23, 2019 15:08
To: cfe-commits@lists.llvm.org
Subject: r361562 - Use clang_cc1 instead of clang in CodeGen test.

Author: asbirlea
Date: Thu May 23 15:07:37 2019
New Revision: 361562

URL: http://llvm.org/viewvc/llvm-project?rev=361562&view=rev
Log:
Use clang_cc1 instead of clang in CodeGen test.

Modified:
cfe/trunk/test/CodeGen/loop-vectorize.c

Modified: cfe/trunk/test/CodeGen/loop-vectorize.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/loop-vectorize.c?rev=361562&r1=361561&r2=361562&view=diff
==
--- cfe/trunk/test/CodeGen/loop-vectorize.c (original)
+++ cfe/trunk/test/CodeGen/loop-vectorize.c Thu May 23 15:07:37 2019
@@ -1,7 +1,7 @@
-// RUN: %clang -target x86_64 -S -c -O1 -fvectorize -emit-llvm -o - %s | 
FileCheck %s -check-prefix=CHECK-ENABLE-VECT -// RUN: %clang -target x86_64 -S 
-c -O1 -fno-vectorize -emit-llvm -o - %s | FileCheck %s 
-check-prefix=CHECK-DISABLE-VECT -// RUN: %clang -target x86_64 
-fexperimental-new-pass-manager -S -c -O1 -fvectorize -emit-llvm -o - %s | 
FileCheck %s -check-prefix=CHECK-ENABLE-VECT -// RUN: %clang -target x86_64 
-fexperimental-new-pass-manager -S -c -O1 -fno-vectorize -emit-llvm -o - %s | 
FileCheck %s -check-prefix=CHECK-DISABLE-VECT
+// RUN: %clang_

RE: [clang-tools-extra] r349038 - [clang-tidy] Share the forced linking code between clang-tidy tool and plugin

[via cfe-commits]

I have reverted this commit in r349121. Ivan, please do not leave in commits 
that cause failures as they make the bots red which can mask other failures.

Douglas Yung

From: cfe-commits  On Behalf Of Galina 
Kistanova via cfe-commits
Sent: Thursday, December 13, 2018 17:41
To: ivan.donchevs...@qt.io
Cc: cfe-commits 
Subject: Re: [clang-tools-extra] r349038 - [clang-tidy] Share the forced 
linking code between clang-tidy tool and plugin

Hello Ivan,

This commit broke tests to few our builders:

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast/builds/40886
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast

. . .
Failing Tests (2):
Clang Tools :: clang-tidy/mpi-buffer-deref.cpp
Clang Tools :: clang-tidy/mpi-type-mismatch.cpp

Please have a look ASAP?

Thanks

Galina

On Thu, Dec 13, 2018 at 6:40 AM Ivan Donchevskii via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: yvvan
Date: Thu Dec 13 06:37:17 2018
New Revision: 349038

URL: http://llvm.org/viewvc/llvm-project?rev=349038&view=rev
Log:
[clang-tidy] Share the forced linking code between clang-tidy tool and plugin

Extract code that forces linking to the separate header and include it in both 
plugin and standalone tool

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

Added:
clang-tools-extra/trunk/clang-tidy/ClangTidyForceLinker.h
Modified:
clang-tools-extra/trunk/clang-tidy/plugin/ClangTidyPlugin.cpp
clang-tools-extra/trunk/clang-tidy/tool/ClangTidyMain.cpp

Added: clang-tools-extra/trunk/clang-tidy/ClangTidyForceLinker.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/ClangTidyForceLinker.h?rev=349038&view=auto
==
--- clang-tools-extra/trunk/clang-tidy/ClangTidyForceLinker.h (added)
+++ clang-tools-extra/trunk/clang-tidy/ClangTidyForceLinker.h Thu Dec 13 
06:37:17 2018
@@ -0,0 +1,108 @@
+//===- ClangTidyForceLinker.h - clang-tidy 
===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "llvm/Support/Compiler.h"
+
+namespace clang {
+namespace tidy {
+
+// This anchor is used to force the linker to link the CERTModule.
+extern volatile int CERTModuleAnchorSource;
+static int LLVM_ATTRIBUTE_UNUSED CERTModuleAnchorDestination =
+CERTModuleAnchorSource;
+
+// This anchor is used to force the linker to link the AbseilModule.
+extern volatile int AbseilModuleAnchorSource;
+static int LLVM_ATTRIBUTE_UNUSED AbseilModuleAnchorDestination =
+AbseilModuleAnchorSource;
+
+// This anchor is used to force the linker to link the BoostModule.
+extern volatile int BoostModuleAnchorSource;
+static int LLVM_ATTRIBUTE_UNUSED BoostModuleAnchorDestination =
+BoostModuleAnchorSource;
+
+// This anchor is used to force the linker to link the BugproneModule.
+extern volatile int BugproneModuleAnchorSource;
+static int LLVM_ATTRIBUTE_UNUSED BugproneModuleAnchorDestination =
+BugproneModuleAnchorSource;
+
+// This anchor is used to force the linker to link the LLVMModule.
+extern volatile int LLVMModuleAnchorSource;
+static int LLVM_ATTRIBUTE_UNUSED LLVMModuleAnchorDestination =
+LLVMModuleAnchorSource;
+
+// This anchor is used to force the linker to link the CppCoreGuidelinesModule.
+extern volatile int CppCoreGuidelinesModuleAnchorSource;
+static int LLVM_ATTRIBUTE_UNUSED CppCoreGuidelinesModuleAnchorDestination =
+CppCoreGuidelinesModuleAnchorSource;
+
+// This anchor is used to force the linker to link the FuchsiaModule.
+extern volatile int FuchsiaModuleAnchorSource;
+static int LLVM_ATTRIBUTE_UNUSED FuchsiaModuleAnchorDestination =
+FuchsiaModuleAnchorSource;
+
+// This anchor is used to force the linker to link the GoogleModule.
+extern volatile int GoogleModuleAnchorSource;
+static int LLVM_ATTRIBUTE_UNUSED GoogleModuleAnchorDestination =
+GoogleModuleAnchorSource;
+
+// This anchor is used to force the linker to link the AndroidModule.
+extern volatile int AndroidModuleAnchorSource;
+static int LLVM_ATTRIBUTE_UNUSED AndroidModuleAnchorDestination =
+AndroidModuleAnchorSource;
+
+// This anchor is used to force the linker to link the MiscModule.
+extern volatile int MiscModuleAnchorSource;
+static int LLVM_ATTRIBUTE_UNUSED MiscModuleAnchorDestination =
+MiscModuleAnchorSource;
+
+// This anchor is used to force the linker to link the ModernizeModule.
+extern volatile int ModernizeModuleAnchorSource;
+static int LLVM_ATTRIBUTE_UNUSED ModernizeModuleAnchorDestination =
+ModernizeModuleAnchorSource;
+
+#if CLANG_ENABLE_STATIC_ANALYZER
+// This anchor is used to force the linker to link the MPIModule.
+extern volatile int MPIModuleA

RE: r349053 - [CodeComplete] Fill preferred type on binary expressions

[via cfe-commits]

Hi, I think this test is still broken on Windows when you are building a cross 
compiler as we at Sony do. I have put the details in PR40033. Can somebody take 
a look?

Douglas Yung

From: cfe-commits  On Behalf Of Reid 
Kleckner via cfe-commits
Sent: Thursday, December 13, 2018 13:51
To: Ilya Biryukov 
Cc: cfe-commits 
Subject: Re: r349053 - [CodeComplete] Fill preferred type on binary expressions

r349086 should take care of it, but you may want to tweak it.

On Thu, Dec 13, 2018 at 1:30 PM Reid Kleckner 
mailto:r...@google.com>> wrote:
This new test doesn't pass on Windows. I think it's an LLP64-ness bug based on 
the output:
Note: Google Test filter = PreferredTypeTest.Binar*
[==] Running 1 test from 1 test case.
[--] Global test environment set-up.
[--] 1 test from PreferredTypeTest
[ RUN  ] PreferredTypeTest.BinaryExpr
test.cc:4:45: error: invalid operands to binary expression ('float' and 'int')
  x += 10; x -= 10; x *= 10; x /= 10; x %= 10;
  ~ ^  ~~
1 error generated.
test.cc:4:45: error: invalid operands to binary expression ('float' and 'int')
  x += 10; x -= 10; x *= 10; x /= 10; x %= 10;
  ~ ^  ~~
1 error generated.
test.cc:4:45: error: invalid operands to binary expression ('float' and 'int')
  x += 10; x -= 10; x *= 10; x /= 10; x %= 10;
  ~ ^  ~~
1 error generated.
test.cc:4:45: error: invalid operands to binary expression ('float' and 'int')
  x += 10; x -= 10; x *= 10; x /= 10; x %= 10;
  ~ ^  ~~
1 error generated.
test.cc:4:45: error: invalid operands to binary expression ('float' and 'int')
  x += 10; x -= 10; x *= 10; x /= 10; x %= 10;
  ~ ^  ~~
1 error generated.
C:\src\llvm-project\clang\unittests\Sema\CodeCompleteTest.cpp(216): error: 
Value of: collectPreferredTypes(Code)
Expected: only contains elements that is equal to "long"
  Actual: { "long long", "long long", "long long" }, whose element #0 doesn't 
match

On Thu, Dec 13, 2018 at 8:09 AM Ilya Biryukov via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Author: ibiryukov
Date: Thu Dec 13 08:06:11 2018
New Revision: 349053

URL: http://llvm.org/viewvc/llvm-project?rev=349053&view=rev
Log:
[CodeComplete] Fill preferred type on binary expressions

Reviewers: kadircet

Reviewed By: kadircet

Subscribers: arphaman, cfe-commits

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

Modified:
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Parse/ParseExpr.cpp
cfe/trunk/lib/Sema/SemaCodeComplete.cpp
cfe/trunk/test/Index/complete-exprs.c
cfe/trunk/unittests/Sema/CodeCompleteTest.cpp

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=349053&r1=349052&r2=349053&view=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Thu Dec 13 08:06:11 2018
@@ -10350,7 +10350,7 @@ public:
   void CodeCompleteInitializer(Scope *S, Decl *D);
   void CodeCompleteReturn(Scope *S);
   void CodeCompleteAfterIf(Scope *S);
-  void CodeCompleteAssignmentRHS(Scope *S, Expr *LHS);
+  void CodeCompleteBinaryRHS(Scope *S, Expr *LHS, tok::TokenKind Op);

   void CodeCompleteQualifiedId(Scope *S, CXXScopeSpec &SS,
bool EnteringContext, QualType BaseType);

Modified: cfe/trunk/lib/Parse/ParseExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Parse/ParseExpr.cpp?rev=349053&r1=349052&r2=349053&view=diff
==
--- cfe/trunk/lib/Parse/ParseExpr.cpp (original)
+++ cfe/trunk/lib/Parse/ParseExpr.cpp Thu Dec 13 08:06:11 2018
@@ -393,10 +393,11 @@ Parser::ParseRHSOfBinaryExpression(ExprR
   }
 }

-// Code completion for the right-hand side of an assignment expression
-// goes through a special hook that takes the left-hand side into account.
-if (Tok.is(tok::code_completion) && NextTokPrec == prec::Assignment) {
-  Actions.CodeCompleteAssignmentRHS(getCurScope(), LHS.get());
+// Code completion for the right-hand side of a binary expression goes
+// through a special hook that takes the left-hand side into account.
+if (Tok.is(tok::code_completion)) {
+  Actions.CodeCompleteBinaryRHS(getCurScope(), LHS.get(),
+OpToken.getKind());
   cutOffParsing();
   return ExprError();
 }

Modified: cfe/trunk/lib/Sema/SemaCodeComplete.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaCodeCom

RE: r349281 - [analyzer][MallocChecker][NFC] Document and reorganize some functions

[via cfe-commits]

Hi Kristof,

Your change seems to have caused 7 new test failures on the PS4 Windows bot:

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/22257/

Clang :: Analysis/Malloc+MismatchedDeallocator+NewDelete.cpp
Clang :: Analysis/MismatchedDeallocator-path-notes.cpp
Clang :: Analysis/NewDelete-intersections.mm
Clang :: Analysis/free.c
Clang :: Analysis/inner-pointer.cpp
Clang :: Analysis/malloc.c
Clang :: Analysis/malloc.mm

Can you please take a look?

Douglas Yung

-Original Message-
From: cfe-commits  On Behalf Of Kristof 
Umann via cfe-commits
Sent: Saturday, December 15, 2018 10:34
To: cfe-commits@lists.llvm.org
Subject: r349281 - [analyzer][MallocChecker][NFC] Document and reorganize some 
functions

Author: szelethus
Date: Sat Dec 15 10:34:00 2018
New Revision: 349281

URL: http://llvm.org/viewvc/llvm-project?rev=349281&view=rev
Log:
[analyzer][MallocChecker][NFC] Document and reorganize some functions

This patch merely reorganizes some things, and features no functional change.

In detail:

* Provided documentation, or moved existing documentation in more obvious
places.
* Added dividers. (the //===--===// thing).
* Moved getAllocationFamily, printAllocDeallocName, printExpectedAllocName and
printExpectedDeallocName in the global namespace on top of the file where
AllocationFamily is declared, as they are very strongly related.
* Moved isReleased and MallocUpdateRefState near RefState's definition for the
same reason.
* Realloc modeling was very poor in terms of variable and structure naming, as
well as documentation, so I renamed some of them and added much needed docs.
* Moved function IdentifierInfos to a separate struct, and moved isMemFunction,
isCMemFunction adn isStandardNewDelete inside it. This makes the patch affect
quite a lot of lines, should I extract it to a separate one?
* Moved MallocBugVisitor out of MallocChecker.
* Preferred switches to long else-if branches in some places.
* Neatly organized some RUN: lines.

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

Modified:
cfe/trunk/lib/StaticAnalyzer/Checkers/MallocChecker.cpp
cfe/trunk/test/Analysis/malloc-annotations.c
cfe/trunk/test/Analysis/malloc.c

Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/MallocChecker.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/MallocChecker.cpp?rev=349281&r1=349280&r2=349281&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/MallocChecker.cpp (original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/MallocChecker.cpp Sat Dec 15 10:34:00 
2018
@@ -7,8 +7,41 @@
 //
 
//===--===//
 //
-// This file defines malloc/free checker, which checks for potential memory
-// leaks, double free, and use-after-free problems.
+// This file defines a variety of memory management related checkers, such as
+// leak, double free, and use-after-free.
+//
+// The following checkers are defined here:
+//
+//   * MallocChecker
+//   Despite its name, it models all sorts of memory allocations and
+//   de- or reallocation, including but not limited to malloc, free,
+//   relloc, new, delete. It also reports on a variety of memory misuse
+//   errors.
+//   Many other checkers interact very closely with this checker, in fact,
+//   most are merely options to this one. Other checkers may register
+//   MallocChecker, but do not enable MallocChecker's reports (more details
+//   to follow around its field, ChecksEnabled).
+//   It also has a boolean "Optimistic" checker option, which if set to 
true
+//   will cause the checker to model user defined memory management related
+//   functions annotated via the attribute ownership_takes, ownership_holds
+//   and ownership_returns.
+//
+//   * NewDeleteChecker
+//   Enables the modeling of new, new[], delete, delete[] in MallocChecker,
+//   and checks for related double-free and use-after-free errors.
+//
+//   * NewDeleteLeaksChecker
+//   Checks for leaks related to new, new[], delete, delete[].
+//   Depends on NewDeleteChecker.
+//
+//   * MismatchedDeallocatorChecker
+//   Enables checking whether memory is deallocated with the correspending
+//   allocation function in MallocChecker, such as malloc() allocated
+//   regions are only freed by free(), new by delete, new[] by delete[].
+//
+//  InnerPointerChecker interacts very closely with MallocChecker, but unlike
+//  the above checkers, it has it's own file, hence the many 
InnerPointerChecker
+//  related headers and non-static functions.
 //
 
//===--===//
 
@@ -37,6 +70,10 @@
 using namespace clang;
 using namespace ento;
 
+//===---

Re: r372903 - [Mangle] Add flag to asm labels to disable '\01' prefixing

[via cfe-commits]

Thank you, sorry for the trouble.

vedant

> On Sep 25, 2019, at 3:36 PM, Evgenii Stepanov  
> wrote:
> 
> FYI I've fixed a memory leak in the new test in r372925.
> 
> On Wed, Sep 25, 2019 at 10:58 AM Vedant Kumar via cfe-commits
>  wrote:
>> 
>> Author: vedantk
>> Date: Wed Sep 25 11:00:31 2019
>> New Revision: 372903
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=372903&view=rev
>> Log:
>> [Mangle] Add flag to asm labels to disable '\01' prefixing
>> 
>> LLDB synthesizes decls using asm labels. These decls cannot have a mangle
>> different than the one specified in the label name. I.e., the '\01' prefix
>> should not be added.
>> 
>> Fixes an expression evaluation failure in lldb's TestVirtual.py on iOS.
>> 
>> rdar://45827323
>> 
>> Differential Revision: https://reviews.llvm.org/D67774
>> 
>> Modified:
>>cfe/trunk/include/clang/Basic/Attr.td
>>cfe/trunk/include/clang/Basic/AttrDocs.td
>>cfe/trunk/lib/AST/Mangle.cpp
>>cfe/trunk/lib/Sema/SemaDecl.cpp
>>cfe/trunk/unittests/AST/DeclTest.cpp
>> 
>> Modified: cfe/trunk/include/clang/Basic/Attr.td
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=372903&r1=372902&r2=372903&view=diff
>> ==
>> --- cfe/trunk/include/clang/Basic/Attr.td (original)
>> +++ cfe/trunk/include/clang/Basic/Attr.td Wed Sep 25 11:00:31 2019
>> @@ -722,9 +722,25 @@ def AVRSignal : InheritableAttr, TargetS
>> 
>> def AsmLabel : InheritableAttr {
>>   let Spellings = [Keyword<"asm">, Keyword<"__asm__">];
>> -  let Args = [StringArgument<"Label">];
>> +  let Args = [
>> +// Label specifies the mangled name for the decl.
>> +StringArgument<"Label">,
>> +
>> +// IsLiteralLabel specifies whether the label is literal (i.e. 
>> suppresses
>> +// the global C symbol prefix) or not. If not, the mangle-suppression 
>> prefix
>> +// ('\01') is omitted from the decl name at the LLVM IR level.
>> +//
>> +// Non-literal labels are used by some external AST sources like LLDB.
>> +BoolArgument<"IsLiteralLabel", /*optional=*/0, /*fake=*/1>
>> +  ];
>>   let SemaHandler = 0;
>> -  let Documentation = [Undocumented];
>> +  let Documentation = [AsmLabelDocs];
>> +  let AdditionalMembers =
>> +[{
>> +bool isEquivalent(AsmLabelAttr *Other) const {
>> +  return getLabel() == Other->getLabel() && getIsLiteralLabel() == 
>> Other->getIsLiteralLabel();
>> +}
>> +}];
>> }
>> 
>> def Availability : InheritableAttr {
>> 
>> Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=372903&r1=372902&r2=372903&view=diff
>> ==
>> --- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
>> +++ cfe/trunk/include/clang/Basic/AttrDocs.td Wed Sep 25 11:00:31 2019
>> @@ -2558,6 +2558,30 @@ manipulating bits of the enumerator when
>>   }];
>> }
>> 
>> +def AsmLabelDocs : Documentation {
>> +  let Category = DocCatDecl;
>> +  let Content = [{
>> +This attribute can be used on a function or variable to specify its symbol 
>> name.
>> +
>> +On some targets, all C symbols are prefixed by default with a single 
>> character, typically ``_``.  This was done historically to distinguish them 
>> from symbols used by other languages.  (This prefix is also added to the 
>> standard Itanium C++ ABI prefix on "mangled" symbol names, so that e.g. on 
>> such targets the true symbol name for a C++ variable declared as ``int 
>> cppvar;`` would be ``__Z6cppvar``; note the two underscores.)  This prefix 
>> is *not* added to the symbol names specified by the ``asm`` attribute; 
>> programmers wishing to match a C symbol name must compensate for this.
>> +
>> +For example, consider the following C code:
>> +
>> +.. code-block:: c
>> +
>> +  int var1 asm("altvar") = 1;  // "altvar" in symbol table.
>> +  int var2 = 1; // "_var2" in symbol table.
>> +
>> +  void func1(void) asm("altfunc");
>> +  void func1(void) {} // "altfunc" in symbol table.
>> +  void fu

RE: r330244 - [MinGW] Look for a cross sysroot relative to the clang binary

[via cfe-commits]

Hi Martin,

Your commit is causing a few test failures on the PS4 Windows bot, can you take 
a look?

http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/16544

Failing Tests (13):
Clang :: CodeGenCXX/mingw-w64-exceptions.c
Clang :: Driver/clang-translation.c
Clang :: Driver/cxa-atexit.cpp
Clang :: Driver/default-image-name.c
Clang :: Driver/fsjlj-exceptions.c
Clang :: Driver/incremental-linker-compatible.c
Clang :: Driver/mingw-libgcc.c
Clang :: Driver/mingw-msvcrt.c
Clang :: Driver/no-integrated-as-win.c
Clang :: Driver/pic.c
Clang :: Driver/windows-pic.cpp
Clang :: Index/index-attrs.c
Clang :: Index/index-attrs.cpp

Douglas Yung

> -Original Message-
> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of
> Martin Storsjo via cfe-commits
> Sent: Wednesday, April 18, 2018 1:47
> To: cfe-commits@lists.llvm.org
> Subject: r330244 - [MinGW] Look for a cross sysroot relative to the clang
> binary
> 
> Author: mstorsjo
> Date: Wed Apr 18 01:47:26 2018
> New Revision: 330244
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=330244&view=rev
> Log:
> [MinGW] Look for a cross sysroot relative to the clang binary
> 
> If found, prefer this over looking for a similar gcc later in the
> system path.
> 
> Differential Revision: https://reviews.llvm.org/D45504
> 
> Modified:
> cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
> cfe/trunk/lib/Driver/ToolChains/MinGW.h
> 
> Modified: cfe/trunk/lib/Driver/ToolChains/MinGW.cpp
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/Driver/ToolChains/MinGW.cpp?rev=330244&r1=330243&r2=3302
> 44&view=diff
> ==
> --- cfe/trunk/lib/Driver/ToolChains/MinGW.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains/MinGW.cpp Wed Apr 18 01:47:26 2018
> @@ -275,7 +275,8 @@ void toolchains::MinGW::findGccLibDir()
>Archs.emplace_back(getTriple().getArchName());
>Archs[0] += "-w64-mingw32";
>Archs.emplace_back("mingw32");
> -  Arch = Archs[0].str();
> +  if (Arch.empty())
> +Arch = Archs[0].str();
>// lib: Arch Linux, Ubuntu, Windows
>// lib64: openSUSE Linux
>for (StringRef CandidateLib : {"lib", "lib64"}) {
> @@ -302,6 +303,24 @@ llvm::ErrorOr toolchains::M
>return make_error_code(std::errc::no_such_file_or_directory);
>  }
> 
> +llvm::ErrorOr toolchains::MinGW::findClangRelativeSysroot() {
> +  llvm::SmallVector, 2> Subdirs;
> +  Subdirs.emplace_back(getTriple().str());
> +  Subdirs.emplace_back(getTriple().getArchName());
> +  Subdirs[1] += "-w64-mingw32";
> +  Twine ClangRoot =
> +  llvm::sys::path::parent_path(getDriver().getInstalledDir()) +
> +  llvm::sys::path::get_separator();
> +  for (StringRef CandidateSubdir : Subdirs) {
> +Twine Subdir = ClangRoot + CandidateSubdir;
> +if (llvm::sys::fs::is_directory(Subdir)) {
> +  Arch = CandidateSubdir;
> +  return Subdir.str();
> +}
> +  }
> +  return make_error_code(std::errc::no_such_file_or_directory);
> +}
> +
>  toolchains::MinGW::MinGW(const Driver &D, const llvm::Triple &Triple,
>   const ArgList &Args)
>  : ToolChain(D, Triple, Args), CudaInstallation(D, Triple, Args) {
> @@ -309,6 +328,10 @@ toolchains::MinGW::MinGW(const Driver &D
> 
>if (getDriver().SysRoot.size())
>  Base = getDriver().SysRoot;
> +  // Look for /../; if found, use /.. as the
> +  // base as it could still be a base for a gcc setup with libgcc.
> +  else if (llvm::ErrorOr TargetSubdir =
> findClangRelativeSysroot())
> +Base = llvm::sys::path::parent_path(TargetSubdir.get());
>else if (llvm::ErrorOr GPPName = findGcc())
>  Base = llvm::sys::path::parent_path(
>  llvm::sys::path::parent_path(GPPName.get()));
> 
> Modified: cfe/trunk/lib/Driver/ToolChains/MinGW.h
> URL: http://llvm.org/viewvc/llvm-
> project/cfe/trunk/lib/Driver/ToolChains/MinGW.h?rev=330244&r1=330243&r2=330244
> &view=diff
> ==
> --- cfe/trunk/lib/Driver/ToolChains/MinGW.h (original)
> +++ cfe/trunk/lib/Driver/ToolChains/MinGW.h Wed Apr 18 01:47:26 2018
> @@ -96,6 +96,7 @@ private:
>mutable std::unique_ptr Compiler;
>void findGccLibDir();
>llvm::ErrorOr findGcc();
> +  llvm::ErrorOr findClangRelativeSysroot();
>  };
> 
>  } // end namespace toolchains
> 
> 
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r330404 - [OpenCL] Add 'denorms-are-zero' function attribute

[via cfe-commits]

Author: AlexeySotkin
Date: Fri Apr 20 01:08:04 2018
New Revision: 330404

URL: http://llvm.org/viewvc/llvm-project?rev=330404&view=rev
Log:
[OpenCL] Add 'denorms-are-zero' function attribute

Summary:
Generate attribute 'denorms-are-zero'='true' if '-cl-denorms-are-zero'
compile option was specified and 'denorms-are-zero'='false' otherwise.

Patch by krisb

Reviewers: Anastasia, yaxunl

Reviewed By:  yaxunl 

Subscribers: cfe-commits

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


Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/test/CodeGenOpenCL/denorms-are-zero.cl

Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=330404&r1=330403&r2=330404&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Fri Apr 20 01:08:04 2018
@@ -1745,6 +1745,10 @@ void CodeGenModule::ConstructDefaultFnAt
 "correctly-rounded-divide-sqrt-fp-math",
 llvm::toStringRef(CodeGenOpts.CorrectlyRoundedDivSqrt));
 
+if (getLangOpts().OpenCL)
+  FuncAttrs.addAttribute("denorms-are-zero",
+ llvm::toStringRef(CodeGenOpts.FlushDenorm));
+
 // TODO: Reciprocal estimate codegen options should apply to instructions?
 const std::vector &Recips = CodeGenOpts.Reciprocals;
 if (!Recips.empty())

Modified: cfe/trunk/test/CodeGenOpenCL/denorms-are-zero.cl
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenOpenCL/denorms-are-zero.cl?rev=330404&r1=330403&r2=330404&view=diff
==
--- cfe/trunk/test/CodeGenOpenCL/denorms-are-zero.cl (original)
+++ cfe/trunk/test/CodeGenOpenCL/denorms-are-zero.cl Fri Apr 20 01:08:04 2018
@@ -1,19 +1,25 @@
-// RUN: %clang_cc1 -S -cl-denorms-are-zero -o - %s 2>&1
-// RUN: %clang_cc1 -emit-llvm -cl-denorms-are-zero -o - -triple amdgcn--amdhsa 
-target-cpu fiji %s | FileCheck %s
-// RUN: %clang_cc1 -emit-llvm -o - -triple amdgcn--amdhsa -target-cpu fiji %s 
| FileCheck %s --check-prefix=CHECK-DENORM
-// RUN: %clang_cc1 -emit-llvm -target-feature +fp32-denormals -target-feature 
-fp64-fp16-denormals -cl-denorms-are-zero -o - -triple amdgcn--amdhsa 
-target-cpu fiji %s | FileCheck --check-prefix=CHECK-FEATURE %s
+// RUN: %clang_cc1 -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -emit-llvm -cl-denorms-are-zero -o - %s | FileCheck %s 
--check-prefix=DENORM-ZERO
+// RUN: %clang_cc1 -emit-llvm -cl-denorms-are-zero -o - -triple amdgcn--amdhsa 
-target-cpu fiji %s | FileCheck %s --check-prefix=AMDGCN
+// RUN: %clang_cc1 -emit-llvm -o - -triple amdgcn--amdhsa -target-cpu fiji %s 
| FileCheck %s --check-prefix=AMDGCN-DENORM
+// RUN: %clang_cc1 -emit-llvm -target-feature +fp32-denormals -target-feature 
-fp64-fp16-denormals -cl-denorms-are-zero -o - -triple amdgcn--amdhsa 
-target-cpu fiji %s | FileCheck --check-prefix=AMDGCN-FEATURE %s
 
-// For non-amdgcn targets, this test just checks that the -cl-denorms-are-zero 
argument is accepted
-// by clang.  This option is currently a no-op, which is allowed by the
-// OpenCL specification.
+// For all targets 'denorms-are-zero' attribute is set to 'true'
+// if '-cl-denorms-are-zero' was specified and  to 'false' otherwise.
+
+// CHECK-LABEL: define void @f()
+// CHECK: attributes #{{[0-9]*}} = {{{[^}]*}} "denorms-are-zero"="false"
+//
+// DENORM-ZERO-LABEL: define void @f()
+// DENORM-ZERO: attributes #{{[0-9]*}} = {{{[^}]*}} "denorms-are-zero"="true"
 
 // For amdgcn target cpu fiji, fp32 should be flushed since fiji does not 
support fp32 denormals, unless +fp32-denormals is
 // explicitly set. amdgcn target always do not flush fp64 denormals. The 
control for fp64 and fp16 denormals is the same.
 
-// CHECK-DENORM-LABEL: define void @f()
-// CHECK-DENORM: attributes #{{[0-9]*}} = {{{[^}]*}} 
"target-features"="{{[^"]*}}+fp64-fp16-denormals,{{[^"]*}}-fp32-denormals{{[^"]*}}"
-// CHECK-LABEL: define void @f()
-// CHECK: attributes #{{[0-9]*}} = {{{[^}]*}} 
"target-features"="{{[^"]*}}+fp64-fp16-denormals,{{[^"]*}}-fp32-denormals{{[^"]*}}"
-// CHECK-FEATURE-LABEL: define void @f()
-// CHECK-FEATURE: attributes #{{[0-9]*}} = {{{[^}]*}} 
"target-features"="{{[^"]*}}+fp32-denormals,{{[^"]*}}-fp64-fp16-denormals{{[^"]*}}"
+// AMDGCN-LABEL: define void @f()
+// AMDGCN: attributes #{{[0-9]*}} = {{{[^}]*}} "denorms-are-zero"="true" 
{{.*}} 
"target-features"="{{[^"]*}}+fp64-fp16-denormals,{{[^"]*}}-fp32-denormals{{[^"]*}}"
+// AMDGCN-DENORM-LABEL: define void @f()
+// AMDGCN-DENORM: attributes #{{[0-9]*}} = {{{[^}]*}} 
"denorms-are-zero"="false" {{.*}} 
"target-features"="{{[^"]*}}+fp64-fp16-denormals,{{[^"]*}}-fp32-denormals{{[^"]*}}"
+// AMDGCN-FEATURE-LABEL: define void @f()
+// AMDGCN-FEATURE: attributes #{{[0-9]*}} = {{{[^}]*}} 
"denorms-are-zero"="true" {{.*}} 
"target-features"="{{[^"]*}}+fp32-denormals,{{[^"]*}}-fp64-fp16-d

If I want to disable certain attributes, such as "swiftcall", is there any way to do it now?

[???? via cfe-commits]

As the title says,thanks.___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

?????? If I want to disable certain attributes, such as "swiftcall", isthere any way to do it now?

[???? via cfe-commits]

Thanks.
 
If I remove some specific attributes, now I can think of the following 
method.First of all, let me talk about my method.
 
1.Define target platforms that do not support attributes.such as def 
TargetPower : TargetArch<["ppc", "ppc64", "ppc64le"]>;
 
2.Define TargetNotSupportedAttr class.such as class 
TargetNotSupportedAttr ;
 
3.Using this approach, we need to modify the 
cfe-4.0.1.src/utils/TableGen/ClangAttrEmitter.cpp file.Modifying the code in 
the GenerateHasAttrSpellingStringSwitch function looks like this:
 
if(Attr->isSubClassOf("TargetNotSupportedAttr")) {   // add 
 
#define GenerateTargetNotSupportedAttrChecks GenerateTargetSpecificAttrChecks 
// add
 
const Record *R = Attr->getValueAsDef("Target");   // add
 
std::vector Arches = R->getValueAsListOfStrings("Arches"); 
// add
 
GenerateTargetNotSupportedAttrChecks(R, Arches, Test, nullptr); // 
add 
 
TestStr = !Test.empty() ? Test + " ? "  + " 0 :" + 
llvm::itostr(Version) : "0"; // add 
 
} else if (Attr->isSubClassOf("TargetSpecificAttr"))
 
4.And for classes that inherit from TargetNotSupportedAttr<> class, we don??t 
need to generate the attribute class, so add the following code in 
EmitClangAttrClass
 
if (R->getName() != "TargetSpecificAttr" &&
 
  R->getName() != "TargetNotSupportedAttr?? &&  //add
 
  SuperName.empty())
 
SuperName = R->getName();
 


 
If I use this method, is it correct?






--  --
??: "Aaron Ballman"; 
: 2018??4??29??(??) 3:07
??: ""<772847...@qq.com>; 
: "cfe-commits"; 
: Re: If I want to disable certain attributes, such as "swiftcall", isthere 
any way to do it now?



On Fri, Apr 27, 2018 at 11:23 PM,  via cfe-commits
 wrote:
>As the title says,thanks.

You could build a custom clang with specific attributes removed, but
there are no compiler flags that allow you to disable arbitrary
attributes like swiftcall.

~Aaron___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

?????? If I want to disable certain attributes, such as "swiftcall",isthere any way to do it now?

[???? via cfe-commits]

hi, Aaron
 
  The reason why i not use of TargetSpecificAttr is as follows.If I plan to 
support a new platform, I don't want to let users use certain attributes 
because of hardware or simply not want to. Yes, we can use TargetSpecificAttr, 
but if we use TargetSpecificAttr that we need to include platforms other than 
unsupported platforms, but we just need to exclude that platform, using 
TargetSpecificAttr may not be a good idea.





--  --
??: "Aaron Ballman";
: 2018??5??2??(??) 10:05
??: ""<772847...@qq.com>;
: "cfe-commits"; 
: Re: If I want to disable certain attributes, such as "swiftcall",isthere 
any way to do it now?



On Wed, May 2, 2018 at 4:59 AM,  <772847...@qq.com> wrote:
> Thanks.
>
> If I remove some specific attributes, now I can think of the following
> method.First of all, let me talk about my method.
>
> 1.Define target platforms that do not support attributes.such as def
> TargetPower : TargetArch<["ppc", "ppc64", "ppc64le"]>;
>
> 2.Define TargetNotSupportedAttr class.such as class
> TargetNotSupportedAttr ;

Why not make use of TargetSpecificAttr to mark the attributes that are
specific to a target rather than marking the attributes not supported
by a target?

> 3.Using this approach, we need to modify the
> cfe-4.0.1.src/utils/TableGen/ClangAttrEmitter.cpp file.Modifying the code in
> the GenerateHasAttrSpellingStringSwitch function looks like this:
>
> if(Attr->isSubClassOf("TargetNotSupportedAttr")) {   // add
>
> #define GenerateTargetNotSupportedAttrChecks
> GenerateTargetSpecificAttrChecks // add
>
> const Record *R = Attr->getValueAsDef("Target");   // add
>
> std::vector Arches =
> R->getValueAsListOfStrings("Arches"); // add
>
> GenerateTargetNotSupportedAttrChecks(R, Arches, Test, nullptr);
> // add
>
> TestStr = !Test.empty() ? Test + " ? "  + " 0 :" +
> llvm::itostr(Version) : "0"; // add
>
> } else if (Attr->isSubClassOf("TargetSpecificAttr"))
>
> 4.And for classes that inherit from TargetNotSupportedAttr<> class, we don??t
> need to generate the attribute class, so add the following code in
> EmitClangAttrClass
>
> if (R->getName() != "TargetSpecificAttr" &&
>
>   R->getName() != "TargetNotSupportedAttr?? &&  //add
>
>   SuperName.empty())
>
> SuperName = R->getName();
>
>
> If I use this method, is it correct?

It seems like it would work, yes.

~Aaron

>
>
>
>
> --  --
> ??: "Aaron Ballman";
> : 2018??4??29??(??) 3:07
> ??: ""<772847...@qq.com>;
> : "cfe-commits";
> : Re: If I want to disable certain attributes, such as "swiftcall",
> isthere any way to do it now?
>
> On Fri, Apr 27, 2018 at 11:23 PM,  via cfe-commits
>  wrote:
>>As the title says,thanks.
>
> You could build a custom clang with specific attributes removed, but
> there are no compiler flags that allow you to disable arbitrary
> attributes like swiftcall.
>
> ~Aaron___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

?????? If I want to disable certain attributes, such as"swiftcall",isthere any way to do it now?

[???? via cfe-commits]

Thanks.




--  --
??: "Aaron Ballman";
: 2018??5??3??(??) 7:40
??: ""<772847...@qq.com>;
: "cfe-commits"; 
: Re: If I want to disable certain attributes, such as"swiftcall",isthere 
any way to do it now?



On Thu, May 3, 2018 at 1:25 AM,  <772847...@qq.com> wrote:
> hi, Aaron
>
>   The reason why i not use of TargetSpecificAttr is as follows.If I plan to
> support a new platform, I don't want to let users use certain attributes
> because of hardware or simply not want to. Yes, we can use
> TargetSpecificAttr, but if we use TargetSpecificAttr that we need to include
> platforms other than unsupported platforms, but we just need to exclude that
> platform, using TargetSpecificAttr may not be a good idea.

Okay, that makes sense to me. Your design seems like a reasonable one.

~Aaron

>
>
>
> --  --
> ??: "Aaron Ballman";
> : 2018??5??2??(??) 10:05
> ??: ""<772847...@qq.com>;
> : "cfe-commits";
> : Re: If I want to disable certain attributes, such as "swiftcall",isthere
> any way to do it now?
>
> On Wed, May 2, 2018 at 4:59 AM,  <772847...@qq.com> wrote:
>> Thanks.
>>
>> If I remove some specific attributes, now I can think of the following
>> method.First of all, let me talk about my method.
>>
>> 1.Define target platforms that do not support attributes.such as def
>> TargetPower : TargetArch<["ppc", "ppc64", "ppc64le"]>;
>>
>> 2.Define TargetNotSupportedAttr class.such as class
>> TargetNotSupportedAttr ;
>
> Why not make use of TargetSpecificAttr to mark the attributes that are
> specific to a target rather than marking the attributes not supported
> by a target?
>
>> 3.Using this approach, we need to modify the
>> cfe-4.0.1.src/utils/TableGen/ClangAttrEmitter.cpp file.Modifying the code
>> in
>> the GenerateHasAttrSpellingStringSwitch function looks like this:
>>
>> if(Attr->isSubClassOf("TargetNotSupportedAttr")) {   // add
>>
>> #define GenerateTargetNotSupportedAttrChecks
>> GenerateTargetSpecificAttrChecks // add
>>
>> const Record *R = Attr->getValueAsDef("Target");   // add
>>
>> std::vector Arches =
>> R->getValueAsListOfStrings("Arches"); // add
>>
>> GenerateTargetNotSupportedAttrChecks(R, Arches, Test, nullptr);
>> // add
>>
>> TestStr = !Test.empty() ? Test + " ? "  + " 0 :" +
>> llvm::itostr(Version) : "0"; // add
>>
>> } else if (Attr->isSubClassOf("TargetSpecificAttr"))
>>
>> 4.And for classes that inherit from TargetNotSupportedAttr<> class, we
>> don??t
>> need to generate the attribute class, so add the following code in
>> EmitClangAttrClass
>>
>> if (R->getName() != "TargetSpecificAttr" &&
>>
>>   R->getName() != "TargetNotSupportedAttr?? &&  //add
>>
>>   SuperName.empty())
>>
>> SuperName = R->getName();
>>
>>
>> If I use this method, is it correct?
>
> It seems like it would work, yes.
>
> ~Aaron
>
>>
>>
>>
>>
>> --  --
>> ??: "Aaron Ballman";
>> : 2018??4??29??(??) 3:07
>> ??: ""<772847...@qq.com>;
>> : "cfe-commits";
>> : Re: If I want to disable certain attributes, such as "swiftcall",
>> isthere any way to do it now?
>>
>> On Fri, Apr 27, 2018 at 11:23 PM,  via cfe-commits
>>  wrote:
>>>As the title says,thanks.
>>
>> You could build a custom clang with specific attributes removed, but
>> there are no compiler flags that allow you to disable arbitrary
>> attributes like swiftcall.
>>
>> ~Aaron___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

OpenCL Header: Guard all half float usage based on cl_khr_fp16 extension

[via cfe-commits]

Hi,
 
this patch guards all missed half float functions based on the availabiltiy of 
the OpenCL extension cl_khr_fp16.
 
Best regards,
 
JerryIndex: lib/Headers/opencl-c.h
===
--- lib/Headers/opencl-c.h	(revision 331598)
+++ lib/Headers/opencl-c.h	(working copy)
@@ -6668,12 +6668,12 @@
 // OpenCL v1.1 s6.9, v1.2/2.0 s6.10 - Function qualifiers
 
 #define __kernel_exec(X, typen) __kernel \
-	__attribute__((work_group_size_hint(X, 1, 1))) \
-	__attribute__((vec_type_hint(typen)))
+__attribute__((work_group_size_hint(X, 1, 1))) \
+__attribute__((vec_type_hint(typen)))
 
 #define kernel_exec(X, typen) __kernel \
-	__attribute__((work_group_size_hint(X, 1, 1))) \
-	__attribute__((vec_type_hint(typen)))
+__attribute__((work_group_size_hint(X, 1, 1))) \
+__attribute__((vec_type_hint(typen)))
 
 // OpenCL v1.1 s6.11.1, v1.2 s6.12.1, v2.0 s6.13.1 - Work-item Functions
 
@@ -11540,7 +11540,7 @@
  *
  * vstoren write sizeof (gentypen) bytes given by data to address (p + (offset * n)).
  *
- * The address computed as (p + (offset * n)) must be 
+ * The address computed as (p + (offset * n)) must be
  * 8-bit aligned if gentype is char, uchar;
  * 16-bit aligned if gentype is short, ushort, half;
  * 32-bit aligned if gentype is int, uint, float;
@@ -12093,6 +12093,7 @@
  * The read address computed as (p + offset)
  * must be 16-bit aligned.
  */
+#ifdef cl_khr_fp16
 float __ovld vload_half(size_t offset, const __constant half *p);
 #if __OPENCL_C_VERSION__ >= CL_VERSION_2_0
 float __ovld vload_half(size_t offset, const half *p);
@@ -12101,6 +12102,7 @@
 float __ovld vload_half(size_t offset, const __local half *p);
 float __ovld vload_half(size_t offset, const __private half *p);
 #endif //__OPENCL_C_VERSION__ >= CL_VERSION_2_0
+#endif //cl_khr_fp16
 
 /**
  * Read sizeof (halfn) bytes of data from address
@@ -12110,6 +12112,7 @@
  * value is returned. The read address computed
  * as (p + (offset * n)) must be 16-bit aligned.
  */
+#ifdef cl_khr_fp16
 float2 __ovld vload_half2(size_t offset, const __constant half *p);
 float3 __ovld vload_half3(size_t offset, const __constant half *p);
 float4 __ovld vload_half4(size_t offset, const __constant half *p);
@@ -12138,6 +12141,7 @@
 float8 __ovld vload_half8(size_t offset, const __private half *p);
 float16 __ovld vload_half16(size_t offset, const __private half *p);
 #endif //__OPENCL_C_VERSION__ >= CL_VERSION_2_0
+#endif //cl_khr_fp16
 
 /**
  * The float value given by data is first
@@ -12150,6 +12154,7 @@
  * The default current rounding mode is round to
  * nearest even.
  */
+#ifdef cl_khr_fp16
 #if __OPENCL_C_VERSION__ >= CL_VERSION_2_0
 void __ovld vstore_half(float data, size_t offset, half *p);
 void __ovld vstore_half_rte(float data, size_t offset, half *p);
@@ -12197,6 +12202,7 @@
 void __ovld vstore_half_rtn(double data, size_t offset, __private half *p);
 #endif //cl_khr_fp64
 #endif //__OPENCL_C_VERSION__ >= CL_VERSION_2_0
+#endif //cl_khr_fp16
 
 /**
  * The floatn value given by data is converted to
@@ -12209,6 +12215,7 @@
  * The default current rounding mode is round to
  * nearest even.
  */
+#ifdef cl_khr_fp16
 #if __OPENCL_C_VERSION__ >= CL_VERSION_2_0
 void __ovld vstore_half2(float2 data, size_t offset, half *p);
 void __ovld vstore_half3(float3 data, size_t offset, half *p);
@@ -12416,6 +12423,7 @@
 void __ovld vstore_half16_rtn(double16 data, size_t offset, __private half *p);
 #endif //cl_khr_fp64
 #endif //__OPENCL_C_VERSION__ >= CL_VERSION_2_0
+#endif //cl_khr_fp16
 
 /**
  * For n = 1, 2, 4, 8 and 16 read sizeof (halfn)
@@ -12430,6 +12438,7 @@
  * The address computed as (p + (offset * 4))
  * must be aligned to sizeof (half) * 4 bytes.
  */
+#ifdef cl_khr_fp16
 float __ovld vloada_half(size_t offset, const __constant half *p);
 float2 __ovld vloada_half2(size_t offset, const __constant half *p);
 float3 __ovld vloada_half3(size_t offset, const __constant half *p);
@@ -12463,6 +12472,7 @@
 float8 __ovld vloada_half8(size_t offset, const __private half *p);
 float16 __ovld vloada_half16(size_t offset, const __private half *p);
 #endif //__OPENCL_C_VERSION__ >= CL_VERSION_2_0
+#endif //cl_khr_fp16
 
 /**
  * The floatn value given by data is converted to
@@ -12480,6 +12490,7 @@
  * mode. The default current rounding mode is
  * round to nearest even.
  */
+#ifdef cl_khr_fp16
 #if __OPENCL_C_VERSION__ >= CL_VERSION_2_0
 void __ovld vstorea_half(float data, size_t offset, half *p);
 void __ovld vstorea_half2(float2 data, size_t offset, half *p);
@@ -12766,6 +12777,7 @@
 void __ovld vstorea_half16_rtn(double16 data,size_t offset, __private half *p);
 #endif //cl_khr_fp64
 #endif //__OPENCL_C_VERSION__ >= CL_VERSION_2_0
+#endif //cl_khr_fp16
 
 // OpenCL v1.1 s6.11.8, v1.2 s6.12.8, v2.0 s6.13.8 - Synchronization Functions
 
@@ -12888,7 +12900,7 @@
 cl_mem_fence_flags __ovld get_fence(const void *ptr);
 cl_mem_fence_flags __ovld get_fence(void *ptr);
 

?????? If I want to disable certain attributes, such as"swiftcall",isthere any way to do it now?

[???? via cfe-commits]

hi, Aaron
   
   Can I ask you some questions?Is there such a demand for me in the community? 
Does my code need to be submitted to the community?
   Thanks.
--  --
??: "Aaron Ballman";
: 2018??5??3??(??) 7:40
??: ""<772847...@qq.com>;
: "cfe-commits"; 
: Re: If I want to disable certain attributes, such as"swiftcall",isthere 
any way to do it now?



On Thu, May 3, 2018 at 1:25 AM,  <772847...@qq.com> wrote:
> hi, Aaron
>
>   The reason why i not use of TargetSpecificAttr is as follows.If I plan to
> support a new platform, I don't want to let users use certain attributes
> because of hardware or simply not want to. Yes, we can use
> TargetSpecificAttr, but if we use TargetSpecificAttr that we need to include
> platforms other than unsupported platforms, but we just need to exclude that
> platform, using TargetSpecificAttr may not be a good idea.

Okay, that makes sense to me. Your design seems like a reasonable one.

~Aaron

>
>
>
> --  --
> ??: "Aaron Ballman";
> : 2018??5??2??(??) 10:05
> ??: ""<772847...@qq.com>;
> : "cfe-commits";
> : Re: If I want to disable certain attributes, such as "swiftcall",isthere
> any way to do it now?
>
> On Wed, May 2, 2018 at 4:59 AM,  <772847...@qq.com> wrote:
>> Thanks.
>>
>> If I remove some specific attributes, now I can think of the following
>> method.First of all, let me talk about my method.
>>
>> 1.Define target platforms that do not support attributes.such as def
>> TargetPower : TargetArch<["ppc", "ppc64", "ppc64le"]>;
>>
>> 2.Define TargetNotSupportedAttr class.such as class
>> TargetNotSupportedAttr ;
>
> Why not make use of TargetSpecificAttr to mark the attributes that are
> specific to a target rather than marking the attributes not supported
> by a target?
>
>> 3.Using this approach, we need to modify the
>> cfe-4.0.1.src/utils/TableGen/ClangAttrEmitter.cpp file.Modifying the code
>> in
>> the GenerateHasAttrSpellingStringSwitch function looks like this:
>>
>> if(Attr->isSubClassOf("TargetNotSupportedAttr")) {   // add
>>
>> #define GenerateTargetNotSupportedAttrChecks
>> GenerateTargetSpecificAttrChecks // add
>>
>> const Record *R = Attr->getValueAsDef("Target");   // add
>>
>> std::vector Arches =
>> R->getValueAsListOfStrings("Arches"); // add
>>
>> GenerateTargetNotSupportedAttrChecks(R, Arches, Test, nullptr);
>> // add
>>
>> TestStr = !Test.empty() ? Test + " ? "  + " 0 :" +
>> llvm::itostr(Version) : "0"; // add
>>
>> } else if (Attr->isSubClassOf("TargetSpecificAttr"))
>>
>> 4.And for classes that inherit from TargetNotSupportedAttr<> class, we
>> don??t
>> need to generate the attribute class, so add the following code in
>> EmitClangAttrClass
>>
>> if (R->getName() != "TargetSpecificAttr" &&
>>
>>   R->getName() != "TargetNotSupportedAttr?? &&  //add
>>
>>   SuperName.empty())
>>
>> SuperName = R->getName();
>>
>>
>> If I use this method, is it correct?
>
> It seems like it would work, yes.
>
> ~Aaron
>
>>
>>
>>
>>
>> --  --
>> ??: "Aaron Ballman";
>> : 2018??4??29??(??) 3:07
>> ??: ""<772847...@qq.com>;
>> : "cfe-commits";
>> : Re: If I want to disable certain attributes, such as "swiftcall",
>> isthere any way to do it now?
>>
>> On Fri, Apr 27, 2018 at 11:23 PM,  via cfe-commits
>>  wrote:
>>>As the title says,thanks.
>>
>> You could build a custom clang with specific attributes removed, but
>> there are no compiler flags that allow you to disable arbitrary
>> attributes like swiftcall.
>>
>> ~Aaron___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

?????? If I want to disable certain attributes, such as"swiftcall",isthereany way to do it now?

[???? via cfe-commits]

nerateTargetSpecificAttrChecks // add
>>>
>>> const Record *R = Attr->getValueAsDef("Target");   // add
>>>
>>> std::vector Arches =
>>> R->getValueAsListOfStrings("Arches"); // add
>>>
>>> GenerateTargetNotSupportedAttrChecks(R, Arches, Test, nullptr);
>>> // add
>>>
>>> TestStr = !Test.empty() ? Test + " ? "  + " 0 :" +
>>> llvm::itostr(Version) : "0"; // add
>>>
>>> } else if (Attr->isSubClassOf("TargetSpecificAttr"))
>>>
>>> 4.And for classes that inherit from TargetNotSupportedAttr<> class, we
>>> don??t
>>> need to generate the attribute class, so add the following code in
>>> EmitClangAttrClass
>>>
>>> if (R->getName() != "TargetSpecificAttr" &&
>>>
>>>   R->getName() != "TargetNotSupportedAttr?? &&  //add
>>>
>>>   SuperName.empty())
>>>
>>> SuperName = R->getName();
>>>
>>>
>>> If I use this method, is it correct?
>>
>> It seems like it would work, yes.
>>
>> ~Aaron
>>
>>>
>>>
>>>
>>>
>>> --  --
>>> ??: "Aaron Ballman";
>>> : 2018??4??29??(??) 3:07
>>> ??: ""<772847...@qq.com>;
>>> : "cfe-commits";
>>> : Re: If I want to disable certain attributes, such as "swiftcall",
>>> isthere any way to do it now?
>>>
>>> On Fri, Apr 27, 2018 at 11:23 PM,  via cfe-commits
>>>  wrote:
>>>>As the title says,thanks.
>>>
>>> You could build a custom clang with specific attributes removed, but
>>> there are no compiler flags that allow you to disable arbitrary
>>> attributes like swiftcall.
>>>
>>> ~Aaron___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

RE: r335740 - [analyzer] Allow registering custom statically-linked analyzer checkers

[via cfe-commits]

Hi, this commit also broke our internal bot for a different reason:

FAILED: /usr/lib/ccache/clang++   -DGTEST_HAS_RTTI=0 -DGTEST_HAS_TR1_TUPLE=0 
-DGTEST_LANG_CXX11=1 -D_DEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-Itools/clang/unittests/StaticAnalyzer 
-I/home/siadmin/jenkins/w/opensource/opensource_build/llvm/tools/clang/unittests/StaticAnalyzer
 -I/home/siadmin/jenkins/w/opensource/opensource_build/llvm/tools/clang/include 
-Itools/clang/include -Iinclude 
-I/home/siadmin/jenkins/w/opensource/opensource_build/llvm/include 
-I/home/siadmin/jenkins/w/opensource/opensource_build/llvm/utils/unittest/googletest/include
 
-I/home/siadmin/jenkins/w/opensource/opensource_build/llvm/utils/unittest/googlemock/include
 -fPIC -fvisibility-inlines-hidden -Werror=date-time -std=c++11 -Wall -Wextra 
-Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers 
-pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color 
-ffunction-sections -fdata-sections -fno-common -Woverloaded-virtual 
-Wno-nested-anon-types -O3-UNDEBUG  -Wno-variadic-macros 
-Wno-gnu-zero-variadic-macro-arguments -fno-exceptions -fno-rtti -MMD -MT 
tools/clang/unittests/StaticAnalyzer/CMakeFiles/StaticAnalysisTests.dir/RegisterCustomCheckersTest.cpp.o
 -MF 
tools/clang/unittests/StaticAnalyzer/CMakeFiles/StaticAnalysisTests.dir/RegisterCustomCheckersTest.cpp.o.d
 -o 
tools/clang/unittests/StaticAnalyzer/CMakeFiles/StaticAnalysisTests.dir/RegisterCustomCheckersTest.cpp.o
 -c 
/home/siadmin/jenkins/w/opensource/opensource_build/llvm/tools/clang/unittests/StaticAnalyzer/RegisterCustomCheckersTest.cpp
/home/siadmin/jenkins/w/opensource/opensource_build/llvm/tools/clang/unittests/StaticAnalyzer/RegisterCustomCheckersTest.cpp:64:12:
 error: no viable conversion from 
'unique_ptr' to 
'unique_ptr'
return AnalysisConsumer;
   ^~~~
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/unique_ptr.h:157:17:
 note: candidate constructor not viable: no known conversion from 
'std::unique_ptr' to 'nullptr_t' for 1st argument
  constexpr unique_ptr(nullptr_t) noexcept : unique_ptr() { }
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/unique_ptr.h:160:7:
 note: candidate constructor not viable: no known conversion from 
'std::unique_ptr' to 'std::unique_ptr > &&' for 1st argument
  unique_ptr(unique_ptr&& __u) noexcept
  ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/unique_ptr.h:169:2:
 note: candidate constructor [with _Up = clang::ento::AnalysisASTConsumer, _Ep 
= std::default_delete, $2 = void] not viable: 
no known conversion from 'std::unique_ptr' to 
'unique_ptr > &&' for 1st argument
unique_ptr(unique_ptr<_Up, _Ep>&& __u) noexcept
^
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/unique_ptr.h:273:7:
 note: candidate constructor not viable: no known conversion from 
'std::unique_ptr' to 'const 
std::unique_ptr > 
&' for 1st argument
  unique_ptr(const unique_ptr&) = delete;
  ^
/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../../include/c++/4.8/bits/unique_ptr.h:176:2:
 note: candidate template ignored: could not match 'auto_ptr' against 
'unique_ptr'
unique_ptr(auto_ptr<_Up>&& __u) noexcept;
^
1 error generated.

Douglas Yung

From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of 
Artem Belevich via cfe-commits
Sent: Wednesday, June 27, 2018 14:30
To: Alexander Kornienko
Cc: cfe-commits
Subject: Re: r335740 - [analyzer] Allow registering custom statically-linked 
analyzer checkers

FYI,

This commit breaks clang tests. It appears that StaticAnalysisTests misses 
dependency on clangFrontend.

--Artem

[60/134] Linking CXX executable 
tools/clang/unittests/StaticAnalyzer/StaticAnalysisTests
FAILED: tools/clang/unittests/StaticAnalyzer/StaticAnalysisTests
: && /usr/local/google/home/tra/local/clang/bin/clang++   -fPIC 
-fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -std=c++11 -Wall -Wextra 
-Wno-unused-parameter -Wwrite-strings -Wcast-qual -Wmissing-field-initializers 
-pedantic -Wno-long-long -Wcovered-switch-default -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wstring-conversion -fdiagnostics-color -fno-common 
-Woverloaded-virtual -Wno-nested-anon-types -g  -fuse-ld=lld -Xlinker 
--gdb-index -fuse-ld=lld -Wl,--color-diagnostics -Wl,-allow-shlib-undefined 
tools/clang/unittests/StaticAnalyzer/CMakeFiles/StaticAnalysisTests.dir/AnalyzerOptionsTest.cpp.o
 
tools/clang/unittests/StaticAnalyzer/CMakeFiles/StaticAnalysisTests.dir/RegisterCustomCheckersTes

RE: [clang-tools-extra] r336177 - [clangd] Incorporate transitive #includes into code complete proximity scoring.

[via cfe-commits]

Hi Sam,

This commit is causing failures on windows buildbots.

  Testing Time: 211.19s
  
  Failing Tests (1):
  Extra Tools Unit Tests :: 
clangd/Checking/./ClangdTests.exe/FileDistanceTests.URI


Example build: 
http://lab.llvm.org:8011/builders/llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast/builds/18166

These failures are also occurring on our internal bots. Could you take a look 
at this?

Thanks,
Matthew

-Original Message-
From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of Sam 
McCall via cfe-commits
Sent: Tuesday, July 3, 2018 1:09 AM
To: cfe-commits@lists.llvm.org
Subject: [clang-tools-extra] r336177 - [clangd] Incorporate transitive 
#includes into code complete proximity scoring.

Author: sammccall
Date: Tue Jul  3 01:09:29 2018
New Revision: 336177

URL: http://llvm.org/viewvc/llvm-project?rev=336177&view=rev
Log:
[clangd] Incorporate transitive #includes into code complete proximity scoring.

Summary:
We now compute a distance from the main file to the symbol header, which
is a weighted count of:
 - some number of #include traversals from source file --> included file
 - some number of FS traversals from file --> parent directory
 - some number of FS traversals from parent directory --> child file/dir
This calculation is performed in the appropriate URI scheme.

This means we'll get some proximity boost from header files in main-file
contexts, even when these are in different directory trees.

This extended file proximity model is not yet incorporated in the index
interface/implementation.

Reviewers: ioeric

Subscribers: mgorny, ilya-biryukov, MaskRay, jkorous, cfe-commits

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

Added:
clang-tools-extra/trunk/clangd/FileDistance.cpp
clang-tools-extra/trunk/clangd/FileDistance.h
clang-tools-extra/trunk/unittests/clangd/FileDistanceTests.cpp
Modified:
clang-tools-extra/trunk/clangd/CMakeLists.txt
clang-tools-extra/trunk/clangd/ClangdServer.cpp
clang-tools-extra/trunk/clangd/ClangdUnit.cpp
clang-tools-extra/trunk/clangd/ClangdUnit.h
clang-tools-extra/trunk/clangd/CodeComplete.cpp
clang-tools-extra/trunk/clangd/CodeComplete.h
clang-tools-extra/trunk/clangd/Headers.cpp
clang-tools-extra/trunk/clangd/Headers.h
clang-tools-extra/trunk/clangd/Quality.cpp
clang-tools-extra/trunk/clangd/Quality.h
clang-tools-extra/trunk/clangd/XRefs.cpp
clang-tools-extra/trunk/unittests/clangd/CMakeLists.txt
clang-tools-extra/trunk/unittests/clangd/HeadersTests.cpp
clang-tools-extra/trunk/unittests/clangd/QualityTests.cpp

Modified: clang-tools-extra/trunk/clangd/CMakeLists.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/CMakeLists.txt?rev=336177&r1=336176&r2=336177&view=diff
==
--- clang-tools-extra/trunk/clangd/CMakeLists.txt (original)
+++ clang-tools-extra/trunk/clangd/CMakeLists.txt Tue Jul  3 01:09:29 2018
@@ -19,6 +19,7 @@ add_clang_library(clangDaemon
   Diagnostics.cpp
   DraftStore.cpp
   FindSymbols.cpp
+  FileDistance.cpp
   FuzzyMatch.cpp
   GlobalCompilationDatabase.cpp
   Headers.cpp

Modified: clang-tools-extra/trunk/clangd/ClangdServer.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdServer.cpp?rev=336177&r1=336176&r2=336177&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdServer.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdServer.cpp Tue Jul  3 01:09:29 2018
@@ -167,7 +167,7 @@ void ClangdServer::codeComplete(PathRef
 // both the old and the new version in case only one of them matches.
 CodeCompleteResult Result = clangd::codeComplete(
 File, IP->Command, PreambleData ? &PreambleData->Preamble : nullptr,
-PreambleData ? PreambleData->Inclusions : std::vector(),
+PreambleData ? PreambleData->Includes : IncludeStructure(),
 IP->Contents, Pos, FS, PCHs, CodeCompleteOpts);
 CB(std::move(Result));
   };

Modified: clang-tools-extra/trunk/clangd/ClangdUnit.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ClangdUnit.cpp?rev=336177&r1=336176&r2=336177&view=diff
==
--- clang-tools-extra/trunk/clangd/ClangdUnit.cpp (original)
+++ clang-tools-extra/trunk/clangd/ClangdUnit.cpp Tue Jul  3 01:09:29 2018
@@ -88,7 +88,7 @@ public:
   CppFilePreambleCallbacks(PathRef File, PreambleParsedCallback ParsedCallback)
   : File(File), ParsedCallback(ParsedCallback) {}
 
-  std::vector takeInclusions() { return std::move(Inclusions); }
+  IncludeStructure takeIncludes() { return std::move(Includes); }
 
   void AfterExecute(CompilerInstance &CI) override {
 if (!ParsedCallback)
@@ -103,15 +103,

[clang] 1ae8e8d - Don't add -fsplit-lto-unit for thin LTO builds with PS4 and Darwin toolchains

[via cfe-commits]

Author: evgeny
Date: 2019-10-24T14:10:03+03:00
New Revision: 1ae8e8d25fd87048d3d8d7429308e52b236c79a1

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

LOG: Don't add -fsplit-lto-unit for thin LTO builds with PS4 and Darwin 
toolchains

These toolchains use legacy thin LTO API, which is not capable of unit splitting
Differential revision: https://reviews.llvm.org/D69173

Added: 


Modified: 
clang/include/clang/Driver/ToolChain.h
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Driver/ToolChains/Darwin.h
clang/lib/Driver/ToolChains/PS4CPU.h
clang/test/Driver/split-lto-unit.c

Removed: 




diff  --git a/clang/include/clang/Driver/ToolChain.h 
b/clang/include/clang/Driver/ToolChain.h
index f0676eee2d6c..c40af1e6e01f 100644
--- a/clang/include/clang/Driver/ToolChain.h
+++ b/clang/include/clang/Driver/ToolChain.h
@@ -600,6 +600,10 @@ class ToolChain {
   virtual SanitizerMask getDefaultSanitizers() const {
 return SanitizerMask();
   }
+
+  /// Returns true when it's possible to split LTO unit to use whole
+  /// program devirtualization and CFI santiizers.
+  virtual bool canSplitThinLTOUnit() const { return true; }
 };
 
 /// Set a ToolChain's effective triple. Reset it when the registration object

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index 55d631733add..198b0b5b228f 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -5395,7 +5395,9 @@ void Clang::ConstructJob(Compilation &C, const JobAction 
&JA,
 CmdArgs.push_back("-fwhole-program-vtables");
   }
 
-  bool DefaultsSplitLTOUnit = WholeProgramVTables || Sanitize.needsLTO();
+  bool DefaultsSplitLTOUnit =
+  (WholeProgramVTables || Sanitize.needsLTO()) &&
+  (D.getLTOMode() == LTOK_Full || TC.canSplitThinLTOUnit());
   bool SplitLTOUnit =
   Args.hasFlag(options::OPT_fsplit_lto_unit,
options::OPT_fno_split_lto_unit, DefaultsSplitLTOUnit);

diff  --git a/clang/lib/Driver/ToolChains/Darwin.h 
b/clang/lib/Driver/ToolChains/Darwin.h
index 2dc7c85880f7..1b1c358c40a4 100644
--- a/clang/lib/Driver/ToolChains/Darwin.h
+++ b/clang/lib/Driver/ToolChains/Darwin.h
@@ -258,6 +258,9 @@ class LLVM_LIBRARY_VISIBILITY MachO : public ToolChain {
 return "";
   }
 
+  // Darwin toolchain uses legacy thin LTO API, which is not
+  // capable of unit splitting.
+  bool canSplitThinLTOUnit() const override { return false; }
   /// }
 };
 

diff  --git a/clang/lib/Driver/ToolChains/PS4CPU.h 
b/clang/lib/Driver/ToolChains/PS4CPU.h
index e9f0891c1194..18852b2808cb 100644
--- a/clang/lib/Driver/ToolChains/PS4CPU.h
+++ b/clang/lib/Driver/ToolChains/PS4CPU.h
@@ -84,6 +84,10 @@ class LLVM_LIBRARY_VISIBILITY PS4CPU : public Generic_ELF {
 
   SanitizerMask getSupportedSanitizers() const override;
 
+  // PS4 toolchain uses legacy thin LTO API, which is not
+  // capable of unit splitting.
+  bool canSplitThinLTOUnit() const override { return false; }
+
 protected:
   Tool *buildAssembler() const override;
   Tool *buildLinker() const override;

diff  --git a/clang/test/Driver/split-lto-unit.c 
b/clang/test/Driver/split-lto-unit.c
index d2ed253ca201..66314161c942 100644
--- a/clang/test/Driver/split-lto-unit.c
+++ b/clang/test/Driver/split-lto-unit.c
@@ -3,6 +3,10 @@
 // RUN: %clang -target x86_64-unknown-linux -### %s -flto=thin 
-fno-split-lto-unit 2>&1 | FileCheck --check-prefix=NOUNIT %s
 // RUN: %clang -target x86_64-unknown-linux -### %s -flto=thin 
-fno-split-lto-unit -fwhole-program-vtables 2>&1 | FileCheck 
--check-prefix=ERROR1 %s
 // RUN: %clang -target x86_64-unknown-linux -### %s -flto=thin 
-fno-split-lto-unit -fsanitize=cfi 2>&1 | FileCheck --check-prefix=ERROR2 %s
+// RUN: %clang -target x86_64-apple-darwin13.3.0 -### %s 
-fwhole-program-vtables -flto=full 2>&1 | FileCheck --check-prefix=UNIT %s
+// RUN: %clang -target x86_64-apple-darwin13.3.0 -### %s 
-fwhole-program-vtables -flto=thin 2>&1 | FileCheck --check-prefix=NOUNIT %s
+// RUN: %clang -target x86_64-scei-ps4 -### %s -fwhole-program-vtables 
-flto=full 2>&1 | FileCheck --check-prefix=UNIT %s
+// RUN: %clang -target x86_64-scei-ps4 -### %s -fwhole-program-vtables 
-flto=thin 2>&1 | FileCheck --check-prefix=NOUNIT %s
 
 // UNIT: "-fsplit-lto-unit"
 // NOUNIT-NOT: "-fsplit-lto-unit"



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

[clang] ec66603 - [clang-format] Remove the dependency on frontend

[via cfe-commits]

Author: paulhoad
Date: 2019-10-24T19:03:57+01:00
New Revision: ec66603ac7ea655be5c2c5f508c5bf0d5eaeb65b

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

LOG: [clang-format] Remove the dependency on frontend

Summary:
Address review comments from {D68554} by trying to drop the dependency again on 
Frontend whilst keeping the same format diagnostic messages

Not completely happy with having to do a split in order to get the StringRef 
for the Line the error occurred on, but could see a way to use SourceManager 
and SourceLocation to give me a single line?

But this removes the dependency on frontend which should keep the binary size 
down.

Reviewers: thakis, klimek, mitchell-stellar

Reviewed By: klimek

Subscribers: mgorny, cfe-commits

Tags: #clang, #clang-format

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

Added: 


Modified: 
clang/tools/clang-format/CMakeLists.txt
clang/tools/clang-format/ClangFormat.cpp

Removed: 




diff  --git a/clang/tools/clang-format/CMakeLists.txt 
b/clang/tools/clang-format/CMakeLists.txt
index 28ac4fb5913e..35ecdb11253c 100644
--- a/clang/tools/clang-format/CMakeLists.txt
+++ b/clang/tools/clang-format/CMakeLists.txt
@@ -7,7 +7,6 @@ add_clang_tool(clang-format
 set(CLANG_FORMAT_LIB_DEPS
   clangBasic
   clangFormat
-  clangFrontend
   clangRewrite
   clangToolingCore
   )

diff  --git a/clang/tools/clang-format/ClangFormat.cpp 
b/clang/tools/clang-format/ClangFormat.cpp
index f39c18bae3ff..a10541d88f07 100644
--- a/clang/tools/clang-format/ClangFormat.cpp
+++ b/clang/tools/clang-format/ClangFormat.cpp
@@ -18,7 +18,6 @@
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/Version.h"
 #include "clang/Format/Format.h"
-#include "clang/Frontend/TextDiagnosticPrinter.h"
 #include "clang/Rewrite/Core/Rewriter.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/FileSystem.h"
@@ -325,12 +324,9 @@ emitReplacementWarnings(const Replacements &Replaces, 
StringRef AssumedFileName,
   IntrusiveRefCntPtr DiagOpts = new DiagnosticOptions();
   DiagOpts->ShowColors = (ShowColors && !NoShowColors);
 
-  TextDiagnosticPrinter *DiagsBuffer =
-  new TextDiagnosticPrinter(llvm::errs(), &*DiagOpts, false);
-
   IntrusiveRefCntPtr DiagID(new DiagnosticIDs());
   IntrusiveRefCntPtr Diags(
-  new DiagnosticsEngine(DiagID, &*DiagOpts, DiagsBuffer));
+  new DiagnosticsEngine(DiagID, &*DiagOpts));
 
   IntrusiveRefCntPtr InMemoryFileSystem(
   new llvm::vfs::InMemoryFileSystem);
@@ -339,24 +335,40 @@ emitReplacementWarnings(const Replacements &Replaces, 
StringRef AssumedFileName,
   FileID FileID = createInMemoryFile(AssumedFileName, Code.get(), Sources,
  Files, InMemoryFileSystem.get());
 
-  const unsigned ID = Diags->getCustomDiagID(
-  WarningsAsErrors ? clang::DiagnosticsEngine::Error
-   : clang::DiagnosticsEngine::Warning,
-  "code should be clang-formatted [-Wclang-format-violations]");
+  FileManager &FileMgr = Sources.getFileManager();
+  llvm::ErrorOr FileEntryPtr =
+  FileMgr.getFile(AssumedFileName);
 
   unsigned Errors = 0;
-  DiagsBuffer->BeginSourceFile(LangOptions(), nullptr);
   if (WarnFormat && !NoWarnFormat) {
 for (const auto &R : Replaces) {
-  Diags->Report(
-  Sources.getLocForStartOfFile(FileID).getLocWithOffset(R.getOffset()),
-  ID);
+  PresumedLoc PLoc = Sources.getPresumedLoc(
+  
Sources.getLocForStartOfFile(FileID).getLocWithOffset(R.getOffset()));
+
+  SourceLocation LineBegin =
+  Sources.translateFileLineCol(FileEntryPtr.get(), PLoc.getLine(), 1);
+  SourceLocation NextLineBegin = Sources.translateFileLineCol(
+  FileEntryPtr.get(), PLoc.getLine() + 1, 1);
+
+  const char *StartBuf = Sources.getCharacterData(LineBegin);
+  const char *EndBuf = Sources.getCharacterData(NextLineBegin);
+
+  StringRef Line(StartBuf, (EndBuf - StartBuf) - 1);
+
+  SMDiagnostic Diags(
+  llvm::SourceMgr(), SMLoc(), AssumedFileName, PLoc.getLine(),
+  PLoc.getColumn(),
+  WarningsAsErrors ? SourceMgr::DiagKind::DK_Error
+   : SourceMgr::DiagKind::DK_Warning,
+  "code should be clang-formatted [-Wclang-format-violations]", Line,
+  ArrayRef>());
+
+  Diags.print(nullptr, llvm::errs(), (ShowColors && !NoShowColors));
   Errors++;
   if (ErrorLimit && Errors >= ErrorLimit)
 break;
 }
   }
-  DiagsBuffer->EndSourceFile();
   return WarningsAsErrors;
 }
 



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

[clang] 8fa5e98 - [clang-format] Remove duplciate code from Invalid BOM detection

[via cfe-commits]

Author: paulhoad
Date: 2019-10-24T20:24:44+01:00
New Revision: 8fa5e98fd191d02fc7e0e220d74af267b9140e6a

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

LOG: [clang-format] Remove duplciate code from Invalid BOM detection

Summary:
Review comments on {D68767} asked that this duplicated code in clang-format was 
moved to one central location that being SourceManager (where it had originally 
be copied from I assume)

Moved function into static function  ContentCache::getInvalidBOM(...)  - 
(closest class to where it was defined before)
Updated clang-format to call this static function

Added unit tests for said new function in BasicTests

Sorry not my normal code area so may have the wrong reviewers. (but your names 
were on the recent history)

Reviewers: bruno, arphaman, klimek, owenpan, mitchell-stellar, dexonsmith

Reviewed By: owenpan

Subscribers: cfe-commits

Tags: #clang, #clang-format, #clang-tools-extra

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

Added: 


Modified: 
clang/include/clang/Basic/SourceManager.h
clang/lib/Basic/SourceManager.cpp
clang/tools/clang-format/ClangFormat.cpp
clang/unittests/Basic/SourceManagerTest.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/SourceManager.h 
b/clang/include/clang/Basic/SourceManager.h
index 3185ca0f4a25..ec1b0bcf9897 100644
--- a/clang/include/clang/Basic/SourceManager.h
+++ b/clang/include/clang/Basic/SourceManager.h
@@ -226,6 +226,10 @@ namespace SrcMgr {
 bool shouldFreeBuffer() const {
   return (Buffer.getInt() & DoNotFreeFlag) == 0;
 }
+
+// If BufStr has an invalid BOM, returns the BOM name; otherwise, returns
+// nullptr
+static const char *getInvalidBOM(StringRef BufStr);
   };
 
   // Assert that the \c ContentCache objects will always be 8-byte aligned so

diff  --git a/clang/lib/Basic/SourceManager.cpp 
b/clang/lib/Basic/SourceManager.cpp
index 58b95289eaf2..5f457d6f9e3d 100644
--- a/clang/lib/Basic/SourceManager.cpp
+++ b/clang/lib/Basic/SourceManager.cpp
@@ -95,6 +95,29 @@ void ContentCache::replaceBuffer(const llvm::MemoryBuffer 
*B, bool DoNotFree) {
   Buffer.setInt((B && DoNotFree) ? DoNotFreeFlag : 0);
 }
 
+const char *ContentCache::getInvalidBOM(StringRef BufStr) {
+  // If the buffer is valid, check to see if it has a UTF Byte Order Mark
+  // (BOM).  We only support UTF-8 with and without a BOM right now.  See
+  // http://en.wikipedia.org/wiki/Byte_order_mark for more information.
+  const char *InvalidBOM =
+  llvm::StringSwitch(BufStr)
+  .StartsWith(llvm::StringLiteral::withInnerNUL("\x00\x00\xFE\xFF"),
+  "UTF-32 (BE)")
+  .StartsWith(llvm::StringLiteral::withInnerNUL("\xFF\xFE\x00\x00"),
+  "UTF-32 (LE)")
+  .StartsWith("\xFE\xFF", "UTF-16 (BE)")
+  .StartsWith("\xFF\xFE", "UTF-16 (LE)")
+  .StartsWith("\x2B\x2F\x76", "UTF-7")
+  .StartsWith("\xF7\x64\x4C", "UTF-1")
+  .StartsWith("\xDD\x73\x66\x73", "UTF-EBCDIC")
+  .StartsWith("\x0E\xFE\xFF", "SCSU")
+  .StartsWith("\xFB\xEE\x28", "BOCU-1")
+  .StartsWith("\x84\x31\x95\x33", "GB-18030")
+  .Default(nullptr);
+
+  return InvalidBOM;
+}
+
 const llvm::MemoryBuffer *ContentCache::getBuffer(DiagnosticsEngine &Diag,
   FileManager &FM,
   SourceLocation Loc,
@@ -190,20 +213,7 @@ const llvm::MemoryBuffer 
*ContentCache::getBuffer(DiagnosticsEngine &Diag,
   // (BOM).  We only support UTF-8 with and without a BOM right now.  See
   // http://en.wikipedia.org/wiki/Byte_order_mark for more information.
   StringRef BufStr = Buffer.getPointer()->getBuffer();
-  const char *InvalidBOM = llvm::StringSwitch(BufStr)
-.StartsWith(llvm::StringLiteral::withInnerNUL("\x00\x00\xFE\xFF"),
-  "UTF-32 (BE)")
-.StartsWith(llvm::StringLiteral::withInnerNUL("\xFF\xFE\x00\x00"),
-  "UTF-32 (LE)")
-.StartsWith("\xFE\xFF", "UTF-16 (BE)")
-.StartsWith("\xFF\xFE", "UTF-16 (LE)")
-.StartsWith("\x2B\x2F\x76", "UTF-7")
-.StartsWith("\xF7\x64\x4C", "UTF-1")
-.StartsWith("\xDD\x73\x66\x73", "UTF-EBCDIC")
-.StartsWith("\x0E\xFE\xFF", "SCSU")
-.StartsWith("\xFB\xEE\x28", "BOCU-1")
-.StartsWith("\x84\x31\x95\x33", "GB-18030")
-.Default(nullptr);
+  const char *InvalidBOM = getInvalidBOM(BufStr);
 
   if (InvalidBOM) {
 Diag.Report(Loc, diag::err_unsupported_bom)

diff  --git a/clang/tools/clang-format/ClangFormat.cpp 
b/clang/tools/clang-format/ClangFormat.cpp
index a10541d88f07..cbbb52bd0aa8 100644
--- a/clang/tools/clang-format/ClangFormat.cpp
+++ b/clang/

[clang] 23b7836 - [clang-format] update documentation

[via cfe-commits]

Author: paulhoad
Date: 2019-10-24T21:10:13+01:00
New Revision: 23b78364150cd946a8b111e87defdf179eecbc8f

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

LOG: [clang-format] update documentation

Summary:
  - Added example code for BreakStringLiterals;

Reviewers: MyDeveloperDay

Reviewed By: MyDeveloperDay

Patch By: mrexodia

Subscribers: cfe-commits, MyDeveloperDay

Tags: #clang-tools-extra, #clang-format, #clang

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

Added: 


Modified: 
clang/docs/ClangFormatStyleOptions.rst
clang/include/clang/Format/Format.h

Removed: 




diff  --git a/clang/docs/ClangFormatStyleOptions.rst 
b/clang/docs/ClangFormatStyleOptions.rst
index 3cd47d3c0ac0..cadb6d4f4919 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -1321,6 +1321,17 @@ the configuration (without a prefix: ``Auto``).
 **BreakStringLiterals** (``bool``)
   Allow breaking string literals when formatting.
 
+  .. code-block:: c++
+
+ true:
+ const char* x = "veryVeryVeryVeryVeryVe"
+ "ryVeryVeryVeryVeryVery"
+ "VeryLongString";
+
+ false:
+ const char* x =
+   "veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongString";
+
 **ColumnLimit** (``unsigned``)
   The column limit.
 

diff  --git a/clang/include/clang/Format/Format.h 
b/clang/include/clang/Format/Format.h
index 7e71b7e8b167..1095821eb664 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -782,7 +782,7 @@ struct FormatStyle {
   /// The brace breaking style to use.
   BraceBreakingStyle BreakBeforeBraces;
 
-  // Different ways to wrap braces after control statements.
+  /// Different ways to wrap braces after control statements.
   enum BraceWrappingAfterControlStatementStyle {
 /// Never wrap braces after a control statement.
 /// \code
@@ -1077,6 +1077,16 @@ struct FormatStyle {
   bool BreakAfterJavaFieldAnnotations;
 
   /// Allow breaking string literals when formatting.
+  /// \code
+  ///true:
+  ///const char* x = "veryVeryVeryVeryVeryVe"
+  ///"ryVeryVeryVeryVeryVery"
+  ///"VeryLongString";
+  ///
+  ///false:
+  ///const char* x =
+  ///  "veryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryVeryLongString";
+  /// \endcode
   bool BreakStringLiterals;
 
   /// The column limit.
@@ -1985,7 +1995,6 @@ struct FormatStyle {
 /// Latest: Parse and format using the latest supported language version.
 /// 'Cpp11' is an alias for LS_Latest for historical reasons.
 LS_Latest,
-
 /// Auto: Automatic detection based on the input.
 /// Parse using the latest language version. Format based on detected 
input.
 LS_Auto,



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

[clang] 6df7ef0 - [clang-format] [NFC] update the documentation in Format.h to allow dump_format_style.py to get a little closer to being correct.

[via cfe-commits]

Author: paulhoad
Date: 2019-10-25T14:46:19+01:00
New Revision: 6df7ef0d8baac34259e2c93043d843f27812c534

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

LOG: [clang-format] [NFC] update the documentation in Format.h to allow 
dump_format_style.py to get a little closer to being correct.

Summary:
Running dump_format_style.py on the tip of the trunk causes 
ClangFormatStyleOptions.rst to have changes, which I think ideally it shouldn't.

Some recent commits have meant Format.h and ClangFormatStyleOptions.rst have 
become out of sync such that dump_format_style.py either couldn't be run or 
generated incorrect .rst files.

It's also important to remember to edit the IncludeStyles from Tooling.

Make a couple of changes {D6833} {D64695} which came from recent clang-format 
commits that missed this step. There are still a couple of other changes  from 
commit {D67541} {D68296} which also need to be looked at, but I'd like to park 
these first two changes first.

The authors of these original commits I've included in the reviewers, I'm happy 
to work on the changes, just really need to know which is the ground truth of 
the changes you want to keep (whats in the Format.h) or what is in the 
ClangFormatStyleOptions.rst

Reviewers: klimek, mitchell-stellar, owenpan, jvoung, Manikishan, sammccall

Reviewed By: mitchell-stellar

Subscribers: cfe-commits

Tags: #clang-format, #clang

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

Added: 


Modified: 
clang/include/clang/Format/Format.h
clang/include/clang/Tooling/Inclusions/IncludeStyle.h

Removed: 




diff  --git a/clang/include/clang/Format/Format.h 
b/clang/include/clang/Format/Format.h
index 1095821eb664..b38d1f7d9402 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -706,21 +706,19 @@ struct FormatStyle {
 ///   };
 /// \endcode
 BS_Allman,
-/// Always break before braces and add an extra level of indentation to
-/// braces of control statements, not to those of class, function
-/// or other definitions.
+/// Like ``Allman`` but always indent braces and line up code with braces.
 /// \code
-///   try
+///try
 /// {
-///   foo();
+/// foo();
 /// }
 ///   catch ()
 /// {
 /// }
 ///   void foo() { bar(); }
 ///   class foo
-///   {
-///   };
+/// {
+/// };
 ///   if (foo())
 /// {
 /// }
@@ -728,25 +726,27 @@ struct FormatStyle {
 /// {
 /// }
 ///   enum X : int
-///   {
+/// {
 /// A,
 /// B
-///   };
+/// };
 /// \endcode
 BS_Whitesmiths,
-/// Like ``Allman`` but always indent braces and line up code with braces.
+/// Always break before braces and add an extra level of indentation to
+/// braces of control statements, not to those of class, function
+/// or other definitions.
 /// \code
-///try
+///   try
 /// {
-/// foo();
+///   foo();
 /// }
 ///   catch ()
 /// {
 /// }
 ///   void foo() { bar(); }
 ///   class foo
-/// {
-/// };
+///   {
+///   };
 ///   if (foo())
 /// {
 /// }
@@ -754,10 +754,10 @@ struct FormatStyle {
 /// {
 /// }
 ///   enum X : int
-/// {
+///   {
 /// A,
 /// B
-/// };
+///   };
 /// \endcode
 BS_GNU,
 /// Like ``Attach``, but break before functions.

diff  --git a/clang/include/clang/Tooling/Inclusions/IncludeStyle.h 
b/clang/include/clang/Tooling/Inclusions/IncludeStyle.h
index 266763a5b1bd..9cade29a8545 100644
--- a/clang/include/clang/Tooling/Inclusions/IncludeStyle.h
+++ b/clang/include/clang/Tooling/Inclusions/IncludeStyle.h
@@ -84,18 +84,27 @@ struct IncludeStyle {
   /// (https://llvm.org/docs/CodingStandards.html#include-style). However, you
   /// can also assign negative priorities if you have certain headers that
   /// always need to be first.
+  /// 
+  /// There is a third and optional field ``SortPriority`` which can used while
+  /// ``IncludeBloks = IBS_Regroup`` to define the priority in which 
``#includes``
+  /// should be ordered, and value of ``Priority`` defines the order of
+  /// ``#include blocks`` and also enables to group ``#includes`` of 
diff erent
+  /// priority for order.``SortPriority`` is set to the value of ``Priority``
+  /// as default if it is not assigned.
   ///
   /// To configure this in the .clang-format file, use:
   /// \code{.yaml}
   ///   IncludeCategories:
   /// - Regex:   '^"(llvm|llvm-c|clang|clang-c)/'
   ///   Priority:2
+  ///   SortPriority:  

[clang] 5d35b7d - [ARM][AArch64] Implement __arm_rsrf, __arm_rsrf64, __arm_wsrf & __arm_wsrf64

[via cfe-commits]

Author: vhscampos
Date: 2019-10-28T10:59:18Z
New Revision: 5d35b7d9e1a34b45c19609f754050e4263bee4ce

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

LOG: [ARM][AArch64] Implement __arm_rsrf, __arm_rsrf64, __arm_wsrf & 
__arm_wsrf64

Summary:
Adding support for ACLE intrinsics.

Patch by Michael Platings.

Reviewers: chill, t.p.northover, efriedma

Reviewed By: chill

Subscribers: kristof.beyls, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/lib/Headers/arm_acle.h
clang/test/CodeGen/arm_acle.c

Removed: 




diff  --git a/clang/lib/Headers/arm_acle.h b/clang/lib/Headers/arm_acle.h
index 0510e6fd809f..942172f9f8ed 100644
--- a/clang/lib/Headers/arm_acle.h
+++ b/clang/lib/Headers/arm_acle.h
@@ -609,9 +609,13 @@ __jcvt(double __a) {
 #define __arm_rsr(sysreg) __builtin_arm_rsr(sysreg)
 #define __arm_rsr64(sysreg) __builtin_arm_rsr64(sysreg)
 #define __arm_rsrp(sysreg) __builtin_arm_rsrp(sysreg)
+#define __arm_rsrf(sysreg) __builtin_bit_cast(float, __arm_rsr(sysreg))
+#define __arm_rsrf64(sysreg) __builtin_bit_cast(double, __arm_rsr64(sysreg))
 #define __arm_wsr(sysreg, v) __builtin_arm_wsr(sysreg, v)
 #define __arm_wsr64(sysreg, v) __builtin_arm_wsr64(sysreg, v)
 #define __arm_wsrp(sysreg, v) __builtin_arm_wsrp(sysreg, v)
+#define __arm_wsrf(sysreg, v) __arm_wsr(sysreg, __builtin_bit_cast(uint32_t, 
v))
+#define __arm_wsrf64(sysreg, v) __arm_wsr64(sysreg, 
__builtin_bit_cast(uint64_t, v))
 
 /* Memory Tagging Extensions (MTE) Intrinsics */
 #if __ARM_FEATURE_MEMORY_TAGGING

diff  --git a/clang/test/CodeGen/arm_acle.c b/clang/test/CodeGen/arm_acle.c
index ce2c5fac70b2..7463d0d8e1d5 100644
--- a/clang/test/CodeGen/arm_acle.c
+++ b/clang/test/CodeGen/arm_acle.c
@@ -822,6 +822,55 @@ void test_wsrp(void *v) {
   __arm_wsrp("sysreg", v);
 }
 
+// ARM-LABEL: test_rsrf
+// AArch64: call i64 @llvm.read_register.i64(metadata ![[M0:[0-9]]])
+// AArch32: call i32 @llvm.read_register.i32(metadata ![[M2:[0-9]]])
+// ARM-NOT: uitofp
+// ARM: bitcast
+float test_rsrf() {
+#ifdef __ARM_32BIT_STATE
+  return __arm_rsrf("cp1:2:c3:c4:5");
+#else
+  return __arm_rsrf("1:2:3:4:5");
+#endif
+}
+// ARM-LABEL: test_rsrf64
+// AArch64: call i64 @llvm.read_register.i64(metadata ![[M0:[0-9]]])
+// AArch32: call i64 @llvm.read_register.i64(metadata ![[M3:[0-9]]])
+// ARM-NOT: uitofp
+// ARM: bitcast
+double test_rsrf64() {
+#ifdef __ARM_32BIT_STATE
+  return __arm_rsrf64("cp1:2:c3");
+#else
+  return __arm_rsrf64("1:2:3:4:5");
+#endif
+}
+// ARM-LABEL: test_wsrf
+// ARM-NOT: fptoui
+// ARM: bitcast
+// AArch64: call void @llvm.write_register.i64(metadata ![[M0:[0-9]]], i64 
%{{.*}})
+// AArch32: call void @llvm.write_register.i32(metadata ![[M2:[0-9]]], i32 
%{{.*}})
+void test_wsrf(float v) {
+#ifdef __ARM_32BIT_STATE
+  __arm_wsrf("cp1:2:c3:c4:5", v);
+#else
+  __arm_wsrf("1:2:3:4:5", v);
+#endif
+}
+// ARM-LABEL: test_wsrf64
+// ARM-NOT: fptoui
+// ARM: bitcast
+// AArch64: call void @llvm.write_register.i64(metadata ![[M0:[0-9]]], i64 
%{{.*}})
+// AArch32: call void @llvm.write_register.i64(metadata ![[M3:[0-9]]], i64 
%{{.*}})
+void test_wsrf64(double v) {
+#ifdef __ARM_32BIT_STATE
+  __arm_wsrf64("cp1:2:c3", v);
+#else
+  __arm_wsrf64("1:2:3:4:5", v);
+#endif
+}
+
 // AArch32: ![[M2]] = !{!"cp1:2:c3:c4:5"}
 // AArch32: ![[M3]] = !{!"cp1:2:c3"}
 // AArch32: ![[M4]] = !{!"sysreg"}



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

[clang] f6e11a3 - [ARM][AArch64] Implement __cls, __clsl and __clsll intrinsics from ACLE

[via cfe-commits]

Author: vhscampos
Date: 2019-10-28T11:06:58Z
New Revision: f6e11a36c49c065cd71e9c54e4fba917da5bbf2e

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

LOG: [ARM][AArch64] Implement __cls,  __clsl and __clsll intrinsics from ACLE

Summary:
Writing support for three ACLE functions:
  unsigned int __cls(uint32_t x)
  unsigned int __clsl(unsigned long x)
  unsigned int __clsll(uint64_t x)

CLS stands for "Count number of leading sign bits".

In AArch64, these two intrinsics can be translated into the 'cls'
instruction directly. In AArch32, on the other hand, this functionality
is achieved by implementing it in terms of clz (count number of leading
zeros).

Reviewers: compnerd

Reviewed By: compnerd

Subscribers: kristof.beyls, hiraditya, cfe-commits, llvm-commits

Tags: #clang, #llvm

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

Added: 
llvm/test/CodeGen/AArch64/cls.ll
llvm/test/CodeGen/ARM/cls.ll

Modified: 
clang/include/clang/Basic/BuiltinsAArch64.def
clang/include/clang/Basic/BuiltinsARM.def
clang/lib/CodeGen/CGBuiltin.cpp
clang/lib/Headers/arm_acle.h
clang/test/CodeGen/arm_acle.c
clang/test/CodeGen/builtins-arm.c
clang/test/CodeGen/builtins-arm64.c
llvm/include/llvm/IR/IntrinsicsAArch64.td
llvm/include/llvm/IR/IntrinsicsARM.td
llvm/lib/Target/AArch64/AArch64InstrInfo.td
llvm/lib/Target/ARM/ARMISelLowering.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/BuiltinsAArch64.def 
b/clang/include/clang/Basic/BuiltinsAArch64.def
index 4df8d5a16762..f07c567053de 100644
--- a/clang/include/clang/Basic/BuiltinsAArch64.def
+++ b/clang/include/clang/Basic/BuiltinsAArch64.def
@@ -33,6 +33,8 @@ BUILTIN(__builtin_arm_clrex, "v", "")
 // Bit manipulation
 BUILTIN(__builtin_arm_rbit, "UiUi", "nc")
 BUILTIN(__builtin_arm_rbit64, "WUiWUi", "nc")
+BUILTIN(__builtin_arm_cls, "UiZUi", "nc")
+BUILTIN(__builtin_arm_cls64, "UiWUi", "nc")
 
 // HINT
 BUILTIN(__builtin_arm_nop, "v", "")

diff  --git a/clang/include/clang/Basic/BuiltinsARM.def 
b/clang/include/clang/Basic/BuiltinsARM.def
index 5f8308d29318..81991a57e2bd 100644
--- a/clang/include/clang/Basic/BuiltinsARM.def
+++ b/clang/include/clang/Basic/BuiltinsARM.def
@@ -115,6 +115,8 @@ BUILTIN(__builtin_arm_smusdx, "iii", "nc")
 
 // Bit manipulation
 BUILTIN(__builtin_arm_rbit, "UiUi", "nc")
+BUILTIN(__builtin_arm_cls, "UiZUi", "nc")
+BUILTIN(__builtin_arm_cls64, "UiWUi", "nc")
 
 // Store and load exclusive
 BUILTIN(__builtin_arm_ldrexd, "LLUiv*", "")

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 9a56116173ec..648837a6d151 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -6055,6 +6055,16 @@ Value *CodeGenFunction::EmitARMBuiltinExpr(unsigned 
BuiltinID,
 CGM.getIntrinsic(Intrinsic::bitreverse, Arg->getType()), Arg, "rbit");
   }
 
+  if (BuiltinID == ARM::BI__builtin_arm_cls) {
+llvm::Value *Arg = EmitScalarExpr(E->getArg(0));
+return Builder.CreateCall(CGM.getIntrinsic(Intrinsic::arm_cls), Arg, 
"cls");
+  }
+  if (BuiltinID == ARM::BI__builtin_arm_cls64) {
+llvm::Value *Arg = EmitScalarExpr(E->getArg(0));
+return Builder.CreateCall(CGM.getIntrinsic(Intrinsic::arm_cls64), Arg,
+  "cls");
+  }
+
   if (BuiltinID == ARM::BI__clear_cache) {
 assert(E->getNumArgs() == 2 && "__clear_cache takes 2 arguments");
 const FunctionDecl *FD = E->getDirectCallee();
@@ -7108,6 +7118,17 @@ Value *CodeGenFunction::EmitAArch64BuiltinExpr(unsigned 
BuiltinID,
 CGM.getIntrinsic(Intrinsic::bitreverse, Arg->getType()), Arg, "rbit");
   }
 
+  if (BuiltinID == AArch64::BI__builtin_arm_cls) {
+llvm::Value *Arg = EmitScalarExpr(E->getArg(0));
+return Builder.CreateCall(CGM.getIntrinsic(Intrinsic::aarch64_cls), Arg,
+  "cls");
+  }
+  if (BuiltinID == AArch64::BI__builtin_arm_cls64) {
+llvm::Value *Arg = EmitScalarExpr(E->getArg(0));
+return Builder.CreateCall(CGM.getIntrinsic(Intrinsic::aarch64_cls64), Arg,
+  "cls");
+  }
+
   if (BuiltinID == AArch64::BI__builtin_arm_jcvt) {
 assert((getContext().getTypeSize(E->getType()) == 32) &&
"__jcvt of unusual size!");

diff  --git a/clang/lib/Headers/arm_acle.h b/clang/lib/Headers/arm_acle.h
index 942172f9f8ed..137092fb9d76 100644
--- a/clang/lib/Headers/arm_acle.h
+++ b/clang/lib/Headers/arm_acle.h
@@ -139,6 +139,26 @@ __clzll(uint64_t __t) {
   return __builtin_clzll(__t);
 }
 
+/* CLS */
+static __inline__ uint32_t __attribute__((__always_inline__, __nodebug__))
+__cls(uint32_t __t) {
+  return __builtin_arm_cls(__t);
+}
+
+static __inline__ uint32_t __attribute__((__always_inline__, __nodebug__))
+__clsl(unsigned long __t) {
+#if __

[clang] e71c537 - [clang-format] Fix line lengths w/ comments in align

[via cfe-commits]

Author: mydeveloperday
Date: 2020-05-20T07:22:01+01:00
New Revision: e71c537a487cacaa00265e1acb765235943d5172

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

LOG: [clang-format] Fix line lengths w/ comments in align

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

When a '//comment' trails a consecutive alignment, it adds a whitespace
replacement within the comment token. This wasn't handled correctly in
the alignment code, which treats it as a whole token and thus double
counts it.

This can wrongly trigger the "line too long, it'll wrap" alignment-break
condition with specific lengths, causing the alignment to break for
seemingly no reason.

Patch By:  JakeMerdichAMD

Reviewed By: MyDeveloperDay

Subscribers: kostyakozko, cfe-commits

Tags: #clang, #clang-format

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

Added: 


Modified: 
clang/lib/Format/WhitespaceManager.cpp
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/lib/Format/WhitespaceManager.cpp 
b/clang/lib/Format/WhitespaceManager.cpp
index 000141a7a1b0..fd1d74933925 100644
--- a/clang/lib/Format/WhitespaceManager.cpp
+++ b/clang/lib/Format/WhitespaceManager.cpp
@@ -445,8 +445,16 @@ static unsigned AlignTokens(const FormatStyle &Style, F 
&&Matches,
 
 unsigned ChangeMinColumn = Changes[i].StartOfTokenColumn;
 int LineLengthAfter = Changes[i].TokenLength;
-for (unsigned j = i + 1; j != e && Changes[j].NewlinesBefore == 0; ++j)
-  LineLengthAfter += Changes[j].Spaces + Changes[j].TokenLength;
+for (unsigned j = i + 1; j != e && Changes[j].NewlinesBefore == 0; ++j) {
+  LineLengthAfter += Changes[j].Spaces;
+  // Changes are generally 1:1 with the tokens, but a change could also be
+  // inside of a token, in which case it's counted more than once: once for
+  // the whitespace surrounding the token (!IsInsideToken) and once for
+  // each whitespace change within it (IsInsideToken).
+  // Therefore, changes inside of a token should only count the space.
+  if (!Changes[j].IsInsideToken)
+LineLengthAfter += Changes[j].TokenLength;
+}
 unsigned ChangeMaxColumn = Style.ColumnLimit - LineLengthAfter;
 
 // If we are restricted by the maximum column width, end the sequence.

diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index a0b1dc7331e1..5eefe99214b2 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -12010,6 +12010,16 @@ TEST_F(FormatTest, AlignConsecutiveAssignments) {
"  x = 1;\n"
"y = 1;\n",
Alignment);
+
+  Alignment.ReflowComments = true;
+  Alignment.ColumnLimit = 50;
+  EXPECT_EQ("int x   = 0;\n"
+"int yy  = 1; /// specificlennospace\n"
+"int zzz = 2;\n",
+format("int x   = 0;\n"
+   "int yy  = 1; ///specificlennospace\n"
+   "int zzz = 2;\n",
+   Alignment));
 }
 
 TEST_F(FormatTest, AlignConsecutiveDeclarations) {



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

[clang] b99bf0e - [clang-format][PR45816] Add AlignConsecutiveBitFields

[via cfe-commits]

Author: mydeveloperday
Date: 2020-05-20T07:42:58+01:00
New Revision: b99bf0e08be4faa4527709541dfdc29240e0c75c

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

LOG: [clang-format][PR45816] Add AlignConsecutiveBitFields

Summary:
The following revision follows D80115 since @MyDeveloperDay and I apparently 
both had the same idea at the same time, for 
https://bugs.llvm.org/show_bug.cgi?id=45816 and my efforts on tooling support 
for AMDVLK, respectively.

This option aligns adjacent bitfield separators across lines, in a manner 
similar to AlignConsecutiveAssignments and friends.

Example:
```
struct RawFloat {
  uint32_t sign : 1;
  uint32_t exponent : 8;
  uint32_t mantissa : 23;
};
```
would become
```
struct RawFloat {
  uint32_t sign : 1;
  uint32_t exponent : 8;
  uint32_t mantissa : 23;
};
```

This also handles c++2a style bitfield-initializers with 
AlignConsecutiveAssignments.
```
struct RawFloat {
  uint32_t sign : 1  = 0;
  uint32_t exponent : 8  = 127;
  uint32_t mantissa : 23 = 0;
}; // defaults to 1.0f
```

Things this change does not do:
 - Align multiple comma-chained bitfield variables. None of the other
   AlignConsecutive* options seem to implement that either.
 - Detect bitfields that have a width specified with something other
   than a numeric literal (ie, `int a : SOME_MACRO;`). That'd be fairly
   difficult to parse and is rare.

Patch By:  JakeMerdichAMD

Reviewed By: MyDeveloperDay

Subscribers: cfe-commits, MyDeveloperDay

Tags: #clang, #clang-format

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

Added: 


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

Removed: 




diff  --git a/clang/docs/ClangFormatStyleOptions.rst 
b/clang/docs/ClangFormatStyleOptions.rst
index e367c3620e16..c4d6c1d50d13 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -204,6 +204,18 @@ the configuration (without a prefix: ``Auto``).
 int b= 23;
 int ccc  = 23;
 
+**AlignConsecutiveBitFields** (``bool``)
+  If ``true``, aligns consecutive bitfield members.
+
+  This will align the bitfield separators of consecutive lines. This
+  will result in formattings like
+
+  .. code-block:: c++
+
+int  : 1;
+int b: 12;
+int ccc  : 8;
+
 **AlignConsecutiveDeclarations** (``bool``)
   If ``true``, aligns consecutive declarations.
 

diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 8dd22887a195..06b01420ca4e 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -297,6 +297,21 @@ clang-format
   bar();
 });
 
+- Option ``AlignConsecutiveBitFields`` has been added to align bit field
+  declarations across multiple adjacent lines
+
+  .. code-block:: c++
+
+  true:
+bool aaa  : 1;
+bool a: 1;
+bool bb   : 1;
+
+  false:
+bool aaa : 1;
+bool a : 1;
+bool bb : 1;
+
 libclang
 
 

diff  --git a/clang/include/clang/Format/Format.h 
b/clang/include/clang/Format/Format.h
old mode 100644
new mode 100755
index 9bc08a775647..7083a46b5b14
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -108,6 +108,17 @@ struct FormatStyle {
   /// \endcode
   bool AlignConsecutiveAssignments;
 
+  /// If ``true``, aligns consecutive bitfield members.
+  ///
+  /// This will align the bitfield separators of consecutive lines. This
+  /// will result in formattings like
+  /// \code
+  ///   int  : 1;
+  ///   int b: 12;
+  ///   int ccc  : 8;
+  /// \endcode
+  bool AlignConsecutiveBitFields;
+
   /// If ``true``, aligns consecutive declarations.
   ///
   /// This will align the declaration names of consecutive lines. This
@@ -2011,8 +2022,8 @@ struct FormatStyle {
 /// \endcode
 SBPO_ControlStatements,
 /// Same as ``SBPO_ControlStatements`` except this option doesn't apply to
-/// ForEach macros. This is useful in projects where ForEach macros are 
-/// treated as function calls instead of control statements. 
+/// ForEach macros. This is useful in projects where ForEach macros are
+/// treated as function calls instead of control statements.
 /// \code
 ///void f() {
 ///  Q_FOREACH(...) {
@@ -2218,6 +2229,7 @@ struct FormatStyle {
 return AccessModifierOffset == R.AccessModifierOffset &&
AlignAfterOpenBracket == R.AlignAfterOpenBracket &&
AlignConsecutiveAssignments == R.AlignConsecutiveAssignments &&
+   AlignConsecutiveBitFi

[clang] cc918e9 - [clang-format] [PR33890] Add support for Microsoft C++/CLI non standard for each looping extension

[via cfe-commits]

Author: mydeveloperday
Date: 2020-05-20T07:44:36+01:00
New Revision: cc918e90c048c6c9a59ed08e7b2a2f92b4ac8140

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

LOG: [clang-format] [PR33890] Add support for Microsoft C++/CLI non standard 
for each looping extension

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

This revision allow the microsoft `for each( in ...` nonstandard C++ 
extension which can be used in C++/CLI to be handled as a ForEach macro.

This prevents the breaking between the for and each onto a new line

Reviewed By: JakeMerdichAMD

Subscribers: cfe-commits

Tags: #clang, #clang-format

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

Added: 


Modified: 
clang/lib/Format/FormatTokenLexer.cpp
clang/lib/Format/FormatTokenLexer.h
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/lib/Format/FormatTokenLexer.cpp 
b/clang/lib/Format/FormatTokenLexer.cpp
index 249d3ac39c3e..b6cbebdcbe7f 100644
--- a/clang/lib/Format/FormatTokenLexer.cpp
+++ b/clang/lib/Format/FormatTokenLexer.cpp
@@ -74,6 +74,8 @@ void FormatTokenLexer::tryMergePreviousTokens() {
 return;
   if (tryMergeLessLess())
 return;
+  if (tryMergeForEach())
+return;
 
   if (Style.isCSharp()) {
 if (tryMergeCSharpKeywordVariables())
@@ -359,6 +361,28 @@ bool FormatTokenLexer::tryTransformCSharpForEach() {
   return true;
 }
 
+bool FormatTokenLexer::tryMergeForEach() {
+  if (Tokens.size() < 2)
+return false;
+  auto &For = *(Tokens.end() - 2);
+  auto &Each = *(Tokens.end() - 1);
+  if (!For->is(tok::kw_for))
+return false;
+  if (!Each->is(tok::identifier))
+return false;
+  if (Each->TokenText != "each")
+return false;
+
+  For->setType(TT_ForEachMacro);
+  For->Tok.setKind(tok::kw_for);
+
+  For->TokenText = StringRef(For->TokenText.begin(),
+ Each->TokenText.end() - For->TokenText.begin());
+  For->ColumnWidth += Each->ColumnWidth;
+  Tokens.erase(Tokens.end() - 1);
+  return true;
+}
+
 bool FormatTokenLexer::tryMergeLessLess() {
   // Merge X,less,less,Y into X,lessless,Y unless X or Y is less.
   if (Tokens.size() < 3)

diff  --git a/clang/lib/Format/FormatTokenLexer.h 
b/clang/lib/Format/FormatTokenLexer.h
index 192e26a10d4a..be11020270a3 100644
--- a/clang/lib/Format/FormatTokenLexer.h
+++ b/clang/lib/Format/FormatTokenLexer.h
@@ -55,6 +55,7 @@ class FormatTokenLexer {
   bool tryMergeCSharpDoubleQuestion();
   bool tryMergeCSharpNullConditional();
   bool tryTransformCSharpForEach();
+  bool tryMergeForEach();
 
   bool tryMergeTokens(ArrayRef Kinds, TokenType NewType);
 

diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index 9f1b88bf6a6f..dada02e5841c 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -994,6 +994,9 @@ TEST_F(FormatTest, ForEachLoops) {
"#define Q_FOREACH (x, y)\n"
"#define BOOST_FOREACH (x, y)\n"
"#define UNKNOWN_FOREACH (x, y)\n");
+
+  // handle microsoft non standard extension
+  verifyFormat("for each (char c in x->MyStringProperty)");
 }
 
 TEST_F(FormatTest, FormatsWhileLoop) {



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

[clang] 807ab2c - [clang-format] [PR42164] Add Option to Break before While

[via cfe-commits]

Author: mydeveloperday
Date: 2020-05-20T07:48:45+01:00
New Revision: 807ab2cd0db398c420ca5b8a7fc260aaea5051a1

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

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

Summary:
Its currently not possible to recreate the GNU style using the 
`BreakBeforeBraces: Custom` style due to a lack of missing `BeforeWhile` in the 
`BraceWrappingFlags`

The following request was raised to add `BeforeWhile` in a `do..while` context 
like `BeforeElse` and `BeforeCatch` to give greater control over the 
positioning of the `while`

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

Reviewers: krasimir, mitchell-stellar, sammccall

Reviewed By: krasimir

Subscribers: cfe-commits

Tags: #clang, #clang-format

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

Added: 


Modified: 
clang/docs/ClangFormatStyleOptions.rst
clang/docs/ReleaseNotes.rst
clang/include/clang/Format/Format.h
clang/lib/Format/Format.cpp
clang/lib/Format/UnwrappedLineParser.cpp
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/docs/ClangFormatStyleOptions.rst 
b/clang/docs/ClangFormatStyleOptions.rst
index c4d6c1d50d13..e5a5fd154849 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -1025,6 +1025,21 @@ the configuration (without a prefix: ``Auto``).
 bar();
   });
 
+  * ``bool BeforeWhile`` Wrap before ``while``.
+
+.. code-block:: c++
+
+  true:
+  do {
+foo();
+  }
+  while (1);
+
+  false:
+  do {
+foo();
+  } while (1);
+
   * ``bool IndentBraces`` Indent the wrapped braces themselves.
 
   * ``bool SplitEmptyFunction`` If ``false``, empty function body can be put 
on a single line.

diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 06b01420ca4e..48c1c9ea019d 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -312,6 +312,27 @@ clang-format
 bool a : 1;
 bool bb : 1;
 
+- Option ``BraceWrapping.BeforeWhile`` has been added to allow wrapping
+  before the ```while`` in a do..while loop. By default the value is 
(``false``)
+
+  In previous releases ``IndentBraces`` implied ``BraceWrapping.BeforeWhile``.
+  If using a Custom BraceWrapping style you may need to now set 
+  ``BraceWrapping.BeforeWhile`` to (``true``) to be explicit.
+
+  .. code-block:: c++
+
+  true:
+  do {
+foo();
+  }
+  while(1);
+
+  false:
+  do {
+foo();
+  } while(1);
+
+
 libclang
 
 

diff  --git a/clang/include/clang/Format/Format.h 
b/clang/include/clang/Format/Format.h
index 7083a46b5b14..05a9cd2d418d 100755
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -1076,6 +1076,20 @@ struct FormatStyle {
 ///   });
 /// \endcode
 bool BeforeLambdaBody;
+/// Wrap before ``while``.
+/// \code
+///   true:
+///   do {
+/// foo();
+///   }
+///   while (1);
+///
+///   false:
+///   do {
+/// foo();
+///   } while (1);
+/// \endcode
+bool BeforeWhile;
 /// Indent the wrapped braces themselves.
 bool IndentBraces;
 /// If ``false``, empty function body can be put on a single line.

diff  --git a/clang/lib/Format/Format.cpp b/clang/lib/Format/Format.cpp
index 418ace7376ff..79e9f35de707 100644
--- a/clang/lib/Format/Format.cpp
+++ b/clang/lib/Format/Format.cpp
@@ -604,6 +604,7 @@ template <> struct 
MappingTraits {
 IO.mapOptional("BeforeCatch", Wrapping.BeforeCatch);
 IO.mapOptional("BeforeElse", Wrapping.BeforeElse);
 IO.mapOptional("BeforeLambdaBody", Wrapping.BeforeLambdaBody);
+IO.mapOptional("BeforeWhile", Wrapping.BeforeWhile);
 IO.mapOptional("IndentBraces", Wrapping.IndentBraces);
 IO.mapOptional("SplitEmptyFunction", Wrapping.SplitEmptyFunction);
 IO.mapOptional("SplitEmptyRecord", Wrapping.SplitEmptyRecord);
@@ -687,12 +688,24 @@ static FormatStyle expandPresets(const FormatStyle 
&Style) {
   if (Style.BreakBeforeBraces == FormatStyle::BS_Custom)
 return Style;
   FormatStyle Expanded = Style;
-  Expanded.BraceWrapping = {false, false, FormatStyle::BWACS_Never,
-false, false, false,
-false, false, false,
-false, false, false,
-false, false, true,
-true,  true};
+  Expanded.BraceWrapping = {/*AfterCaseLabel=*/false,
+/*AfterClass=*/false,
+/*AfterControlStatement=*/FormatStyle::BWACS_Never,
+/*AfterEnum=*/false,
+/*AfterFu

[clang] 166ebef - [clang-format] Set of unit test to begin to validate that we don't change defaults

[via cfe-commits]

Author: mydeveloperday
Date: 2020-05-20T21:11:10+01:00
New Revision: 166ebefd27ac71e3f911f3d7ba0e168464d372af

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

LOG: [clang-format] Set of unit test to begin to validate that we don't change 
defaults

Summary:
This revision is to complement {D75791} so we can be sure that we don't change 
any default behavior.

For now just add rules to cover AfterExternBlock, but in the future we should 
add cases to cover the other BraceWrapping rules for each style. This will help 
guard us when we change code inside of the various getXXXStyle() functions to 
ensure we are not breaking everyone.

Reviewed By: MarcusJohnson91

Subscribers: cfe-commits

Tags: #clang, #clang-format

Differential Revision: https:

Added: 


Modified: 
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/unittests/Format/FormatTest.cpp 
b/clang/unittests/Format/FormatTest.cpp
index 356edf248e67..ff31601e537a 100644
--- a/clang/unittests/Format/FormatTest.cpp
+++ b/clang/unittests/Format/FormatTest.cpp
@@ -16466,6 +16466,58 @@ TEST_F(FormatTest, LikelyUnlikely) {
Style);
 }
 
+TEST_F(FormatTest, LLVMDefaultStyle) {
+  FormatStyle Style = getLLVMStyle();
+  verifyFormat("extern \"C\" {\n"
+   "int foo();\n"
+   "}",
+   Style);
+}
+TEST_F(FormatTest, GNUDefaultStyle) {
+  FormatStyle Style = getGNUStyle();
+  verifyFormat("extern \"C\"\n"
+   "{\n"
+   "  int foo ();\n"
+   "}",
+   Style);
+}
+TEST_F(FormatTest, MozillaDefaultStyle) {
+  FormatStyle Style = getMozillaStyle();
+  verifyFormat("extern \"C\"\n"
+   "{\n"
+   "  int foo();\n"
+   "}",
+   Style);
+}
+TEST_F(FormatTest, GoogleDefaultStyle) {
+  FormatStyle Style = getGoogleStyle();
+  verifyFormat("extern \"C\" {\n"
+   "int foo();\n"
+   "}",
+   Style);
+}
+TEST_F(FormatTest, ChromiumDefaultStyle) {
+  FormatStyle Style = getChromiumStyle(FormatStyle::LanguageKind::LK_Cpp);
+  verifyFormat("extern \"C\" {\n"
+   "int foo();\n"
+   "}",
+   Style);
+}
+TEST_F(FormatTest, MicrosoftDefaultStyle) {
+  FormatStyle Style = getMicrosoftStyle(FormatStyle::LanguageKind::LK_Cpp);
+  verifyFormat("extern \"C\"\n"
+   "{\n"
+   "int foo();\n"
+   "}",
+   Style);
+}
+TEST_F(FormatTest, WebKitDefaultStyle) {
+  FormatStyle Style = getWebKitStyle();
+  verifyFormat("extern \"C\" {\n"
+   "int foo();\n"
+   "}",
+   Style);
+}
 } // namespace
 } // namespace format
 } // namespace clang



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