[PATCH] D66951: [ASTImporter] Add comprehensive tests for ODR violation handling strategies

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added inline comments.



Comment at: clang/unittests/AST/ASTImporterODRStrategiesTest.cpp:151
+};
+
+template 

martong wrote:
> balazske wrote:
> > `FunctionTemplate` and `FunctionTemplateSpec` are missing?
> Yes, because `FunctionTemplates` overload with each other. So they are 
> imported always "liberally".
> 
> There is no point to liberally import conflicting 
> `FunctionTemplateSpecializations`.
> The only thing we can do in that case is to omit the conflicting declaration.
> And this is true in case of `ClassTemplateSpecialization`s too.
> 
> Perhaps we should remove `struct ClassTemplateSpec` as well from here (?).
> Because they are never going to be handled "liberally".
> 
> @shafik , what do you think about this?
What you say about `FunctionTemplateSpecializations` and 
`ClassTemplateSpecializations` seems to make sense, importing them liberally 
would require more than work in the importer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66951



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

[PATCH] D66951: [ASTImporter] Add comprehensive tests for ODR violation handling strategies

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added inline comments.



Comment at: clang/unittests/AST/ASTImporterODRStrategiesTest.cpp:118
+  template 
+  constexpr T X;
+  )";

shafik wrote:
> Note this is not well-formed b/c it is not initialized, [see 
> godbolt](https://godbolt.org/z/8xvFwh)
But it would be ok combined w/ a specialization:

```
template <>
constexpr int X = 0;
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66951



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

[PATCH] D66951: [ASTImporter] Add comprehensive tests for ODR violation handling strategies

[Shafik Yaghmour via Phabricator via cfe-commits]

shafik added inline comments.



Comment at: clang/unittests/AST/ASTImporterODRStrategiesTest.cpp:118
+  template 
+  constexpr T X;
+  )";

Note this is not well-formed b/c it is not initialized, [see 
godbolt](https://godbolt.org/z/8xvFwh)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66951



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

[PATCH] D67425: [WebAssembly] Narrowing and widening SIMD ops

[Thomas Lively via Phabricator via cfe-commits]

tlively planned changes to this revision.
tlively added a comment.

I missed the fact that the narrows are supposed to be binary operations. Oops.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67425



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

[PATCH] D63607: [clang][driver] Add basic --driver-mode=fortran support for flang

[Hal Finkel via Phabricator via cfe-commits]

hfinkel added inline comments.



Comment at: clang/lib/Driver/ToolChains/Flang.cpp:73
+  } else {
+assert(Output.isNothing() && "Input output.");
+  }

Should this say "Invalid output"?


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

https://reviews.llvm.org/D63607



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

[PATCH] D67429: Improve code generation for thread_local variables:

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

rsmith created this revision.
rsmith added a reviewer: rjmccall.
Herald added a reviewer: jdoerfert.
Herald added a project: clang.

- Don't bother using a thread wrapper when the variable is known to have 
constant initialization.
- Emit the thread wrapper as discardable-if-unused in TUs that don't contain a 
definition of the thread_local variable.
- Don't emit the thread wrapper at all if the thread_local variable is unused 
and discardable; it will be emitted by all TUs that need it.


Repository:
  rC Clang

https://reviews.llvm.org/D67429

Files:
  include/clang/Basic/Linkage.h
  lib/CodeGen/CGCXXABI.h
  lib/CodeGen/CGExpr.cpp
  lib/CodeGen/ItaniumCXXABI.cpp
  lib/CodeGen/MicrosoftCXXABI.cpp
  test/CodeGen/windows-on-arm-itanium-thread-local.c
  test/CodeGenCXX/cxx11-thread-local.cpp
  test/CodeGenCXX/cxx2a-thread-local-constinit.cpp
  test/CodeGenCXX/tls-init-funcs.cpp
  test/CodeGenCXX/windows-on-arm-itanium-thread-local.cpp
  test/OpenMP/parallel_copyin_codegen.cpp

Index: test/OpenMP/parallel_copyin_codegen.cpp
===
--- test/OpenMP/parallel_copyin_codegen.cpp
+++ test/OpenMP/parallel_copyin_codegen.cpp
@@ -101,8 +101,7 @@
   // LAMBDA: define{{.*}} internal{{.*}} void [[OUTER_LAMBDA]](
   // LAMBDA: call {{.*}}void {{.+}} @__kmpc_fork_call({{.+}}, i32 0, {{.+}}* [[OMP_REGION:@.+]] to {{.+}})
 
-  // TLS-LAMBDA: [[G_CPY_VAL:%.+]] = call{{( cxx_fast_tlscc)?}} i{{[0-9]+}}* [[G_CTOR:@.+]]()
-  // TLS-LAMBDA: call {{.*}}void {{.+}} @__kmpc_fork_call({{.+}}, i32 1, {{.+}}* [[OMP_REGION:@.+]] to {{.+}}, i32* [[G_CPY_VAL]])
+  // TLS-LAMBDA: call {{.*}}void {{.+}} @__kmpc_fork_call({{.+}}, i32 1, {{.+}}* [[OMP_REGION:@.+]] to {{.+}}, i32* @g)
 
 #pragma omp parallel copyin(g)
   {
@@ -120,14 +119,12 @@
 // LAMBDA: [[DONE]]
 
 // TLS-LAMBDA-DAG: [[G_CAPTURE_SRC:%.+]] = load i{{[0-9]+}}*, i{{[0-9]+}}** %
-// TLS-LAMBDA-DAG: [[G_CAPTURE_DST:%.+]] = call{{( cxx_fast_tlscc)?}} i{{[0-9]+}}* [[G_CTOR]]()
 // TLS-LAMBDA-DAG: [[G_CAPTURE_SRCC:%.+]] = ptrtoint i{{[0-9]+}}* [[G_CAPTURE_SRC]] to i{{[0-9]+}}
-// TLS-LAMBDA-DAG: [[G_CAPTURE_DSTC:%.+]] = ptrtoint i{{[0-9]+}}* [[G_CAPTURE_DST]] to i{{[0-9]+}}
-// TLS-LAMBDA: icmp ne i{{[0-9]+}} {{%.+}}, {{%.+}}
+// TLS-LAMBDA: icmp ne i{{[0-9]+}} {{%.+}}, ptrtoint (i{{[0-9]+}}* @g to i{{[0-9]+}})
 // TLS-LAMBDA: br i1 %{{.+}}, label %[[NOT_MASTER:.+]], label %[[DONE:.+]]
 // TLS-LAMBDA: [[NOT_MASTER]]
 // TLS-LAMBDA: load i{{[0-9]+}}, i{{[0-9]+}}* [[G_CAPTURE_SRC]],
-// TLS-LAMBDA: store volatile i{{[0-9]+}} %{{.+}}, i{{[0-9]+}}* [[G_CAPTURE_DST]], align 128
+// TLS-LAMBDA: store volatile i{{[0-9]+}} %{{.+}}, i{{[0-9]+}}* @g, align 128
 // TLS-LAMBDA: [[DONE]]
 
 // LAMBDA: call {{.*}}void @__kmpc_barrier(
@@ -136,18 +133,13 @@
 // LAMBDA: call{{.*}} void [[INNER_LAMBDA:@.+]](%{{.+}}*
 // TLS-LAMBDA: call{{.*}} void [[INNER_LAMBDA:@.+]](%{{.+}}*
 
-// TLS-LAMBDA: define {{.*}}i{{[0-9]+}}* [[G_CTOR]]()
-// TLS-LAMBDA: ret i{{[0-9]+}}* [[G]]
-// TLS-LAMBDA: }
-
 [&]() {
   // LAMBDA: define {{.+}} void [[INNER_LAMBDA]](%{{.+}}* [[ARG_PTR:%.+]])
   // LAMBDA: store %{{.+}}* [[ARG_PTR]], %{{.+}}** [[ARG_PTR_REF:%.+]],
   g = 2;
   // LAMBDA: [[ARG_PTR:%.+]] = load %{{.+}}*, %{{.+}}** [[ARG_PTR_REF]]
 
-  // TLS-LAMBDA: [[G_CAPTURE_DST:%.+]] = call{{( cxx_fast_tlscc)?}} i{{[0-9]+}}* [[G_CTOR]]()
-  // TLS-LAMBDA: store volatile i{{[0-9]+}} 2, i{{[0-9]+}}* [[G_CAPTURE_DST]], align 128
+  // TLS-LAMBDA: store volatile i{{[0-9]+}} 2, i{{[0-9]+}}* @g, align 128
 }();
   }
   }();
@@ -164,8 +156,7 @@
   // BLOCKS: define{{.*}} internal{{.*}} void {{.+}}(i8*
   // BLOCKS: call {{.*}}void {{.+}} @__kmpc_fork_call({{.+}}, i32 0, {{.+}}* [[OMP_REGION:@.+]] to {{.+}})
 
-  // TLS-BLOCKS: [[G_CPY_VAL:%.+]] = call{{( cxx_fast_tlscc)?}} i{{[0-9]+}}* [[G_CTOR:@.+]]()
-  // TLS-BLOCKS: call {{.*}}void {{.+}} @__kmpc_fork_call({{.+}}, i32 1, {{.+}}* [[OMP_REGION:@.+]] to {{.+}}, i32* [[G_CPY_VAL]])
+  // TLS-BLOCKS: call {{.*}}void {{.+}} @__kmpc_fork_call({{.+}}, i32 1, {{.+}}* [[OMP_REGION:@.+]] to {{.+}}, i32* @g)
 
 #pragma omp parallel copyin(g)
   {
@@ -183,14 +174,12 @@
 // BLOCKS: [[DONE]]
 
 // TLS-BLOCKS-DAG: [[G_CAPTURE_SRC:%.+]] = load i{{[0-9]+}}*, i{{[0-9]+}}** %
-// TLS-BLOCKS-DAG: [[G_CAPTURE_DST:%.+]] = call{{( cxx_fast_tlscc)?}} i{{[0-9]+}}* [[G_CTOR]]()
 // TLS-BLOCKS-DAG: [[G_CAPTURE_SRCC:%.+]] = ptrtoint i{{[0-9]+}}* [[G_CAPTURE_SRC]] to i{{[0-9]+}}
-// TLS-BLOCKS-DAG: [[G_CAPTURE_DSTC:%.+]] = ptrtoint i{{[0-9]+}}* [[G_CAPTURE_DST]] to i{{[0-9]+}}
-// TLS-BLOCKS: icmp ne i{{[0-9]+}} {{%.+}}, {{%.+}}
+// TLS-BLOCKS: icmp ne i{{[0-9]+}} {{%.+}}, ptrtoint (i{{[0-9]+}}* @g to i{{[0-9]+}})
 // TLS-BLOCKS: br i1 %{{.+}}, label %[[NOT_MASTER:.+]], label %[[DONE:.+]]
 // TLS-BLOCKS: [[NOT_MASTER]]
 // TLS-BLOCKS: load i{{[0-9]+}}, 

[PATCH] D59754: [Sema] Add c++2a designated initializer warnings

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

Another question about this, sorry. Do you know _why_ C++20 is more restrictive 
than C99 wrt "mixture of designated and non-designated initializers in the same 
initializer list is a C99 extension"? Is there some interaction with other C++ 
features that makes the C99 behavior difficult in C++20?


Repository:
  rL LLVM

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

https://reviews.llvm.org/D59754



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

[PATCH] D67058: [clang][CodeGen] Add alias for cpu_dispatch function with IFunc & Fix resolver linkage type

[Fangrui Song via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL371586: [CodeGen] Add alias for cpu_dispatch function with 
IFunc  Fix resolver linkage… (authored by MaskRay, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67058?vs=219568=219651#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67058

Files:
  cfe/trunk/lib/CodeGen/CodeGenModule.cpp
  cfe/trunk/test/CodeGen/attr-cpuspecific.c
  cfe/trunk/test/CodeGen/attr-target-mv-func-ptrs.c
  cfe/trunk/test/CodeGen/attr-target-mv-va-args.c
  cfe/trunk/test/CodeGen/attr-target-mv.c
  cfe/trunk/test/CodeGenCXX/attr-cpuspecific.cpp
  cfe/trunk/test/CodeGenCXX/attr-target-mv-diff-ns.cpp
  cfe/trunk/test/CodeGenCXX/attr-target-mv-inalloca.cpp
  cfe/trunk/test/CodeGenCXX/attr-target-mv-member-funcs.cpp
  cfe/trunk/test/CodeGenCXX/attr-target-mv-modules.cpp
  cfe/trunk/test/CodeGenCXX/attr-target-mv-out-of-line-defs.cpp
  cfe/trunk/test/CodeGenCXX/attr-target-mv-overloads.cpp

Index: cfe/trunk/test/CodeGen/attr-target-mv.c
===
--- cfe/trunk/test/CodeGen/attr-target-mv.c
+++ cfe/trunk/test/CodeGen/attr-target-mv.c
@@ -47,12 +47,12 @@
   fwd_decl_avx();
 }
 
-// LINUX: @foo.ifunc = ifunc i32 (), i32 ()* ()* @foo.resolver
-// LINUX: @foo_inline.ifunc = ifunc i32 (), i32 ()* ()* @foo_inline.resolver
-// LINUX: @foo_decls.ifunc = ifunc void (), void ()* ()* @foo_decls.resolver
-// LINUX: @foo_multi.ifunc = ifunc void (i32, double), void (i32, double)* ()* @foo_multi.resolver
-// LINUX: @fwd_decl_default.ifunc = ifunc i32 (), i32 ()* ()* @fwd_decl_default.resolver
-// LINUX: @fwd_decl_avx.ifunc = ifunc i32 (), i32 ()* ()* @fwd_decl_avx.resolver
+// LINUX: @foo.ifunc = weak_odr ifunc i32 (), i32 ()* ()* @foo.resolver
+// LINUX: @foo_inline.ifunc = weak_odr ifunc i32 (), i32 ()* ()* @foo_inline.resolver
+// LINUX: @foo_decls.ifunc = weak_odr ifunc void (), void ()* ()* @foo_decls.resolver
+// LINUX: @foo_multi.ifunc = weak_odr ifunc void (i32, double), void (i32, double)* ()* @foo_multi.resolver
+// LINUX: @fwd_decl_default.ifunc = weak_odr ifunc i32 (), i32 ()* ()* @fwd_decl_default.resolver
+// LINUX: @fwd_decl_avx.ifunc = weak_odr ifunc i32 (), i32 ()* ()* @fwd_decl_avx.resolver
 
 // LINUX: define i32 @foo.sse4.2()
 // LINUX: ret i32 0
@@ -72,14 +72,14 @@
 // WINDOWS: define dso_local i32 @bar()
 // WINDOWS: call i32 @foo.resolver()
 
-// LINUX: define i32 ()* @foo.resolver() comdat
+// LINUX: define weak_odr i32 ()* @foo.resolver() comdat
 // LINUX: call void @__cpu_indicator_init()
 // LINUX: ret i32 ()* @foo.arch_sandybridge
 // LINUX: ret i32 ()* @foo.arch_ivybridge
 // LINUX: ret i32 ()* @foo.sse4.2
 // LINUX: ret i32 ()* @foo
 
-// WINDOWS: define dso_local i32 @foo.resolver() comdat
+// WINDOWS: define weak_odr dso_local i32 @foo.resolver() comdat
 // WINDOWS: call void @__cpu_indicator_init()
 // WINDOWS: call i32 @foo.arch_sandybridge
 // WINDOWS: call i32 @foo.arch_ivybridge
@@ -92,14 +92,14 @@
 // WINDOWS: define dso_local i32 @bar2()
 // WINDOWS: call i32 @foo_inline.resolver()
 
-// LINUX: define i32 ()* @foo_inline.resolver() comdat
+// LINUX: define weak_odr i32 ()* @foo_inline.resolver() comdat
 // LINUX: call void @__cpu_indicator_init()
 // LINUX: ret i32 ()* @foo_inline.arch_sandybridge
 // LINUX: ret i32 ()* @foo_inline.arch_ivybridge
 // LINUX: ret i32 ()* @foo_inline.sse4.2
 // LINUX: ret i32 ()* @foo_inline
 
-// WINDOWS: define dso_local i32 @foo_inline.resolver() comdat
+// WINDOWS: define weak_odr dso_local i32 @foo_inline.resolver() comdat
 // WINDOWS: call void @__cpu_indicator_init()
 // WINDOWS: call i32 @foo_inline.arch_sandybridge
 // WINDOWS: call i32 @foo_inline.arch_ivybridge
@@ -112,11 +112,11 @@
 // WINDOWS: define dso_local void @bar3()
 // WINDOWS: call void @foo_decls.resolver()
 
-// LINUX: define void ()* @foo_decls.resolver() comdat
+// LINUX: define weak_odr void ()* @foo_decls.resolver() comdat
 // LINUX: ret void ()* @foo_decls.sse4.2
 // LINUX: ret void ()* @foo_decls
 
-// WINDOWS: define dso_local void @foo_decls.resolver() comdat
+// WINDOWS: define weak_odr dso_local void @foo_decls.resolver() comdat
 // WINDOWS: call void @foo_decls.sse4.2
 // WINDOWS: call void @foo_decls
 
@@ -126,7 +126,7 @@
 // WINDOWS: define dso_local void @bar4()
 // WINDOWS: call void @foo_multi.resolver(i32 1, double 5.{{[0+e]*}})
 
-// LINUX: define void (i32, double)* @foo_multi.resolver() comdat
+// LINUX: define weak_odr void (i32, double)* @foo_multi.resolver() comdat
 // LINUX: and i32 %{{.*}}, 4352
 // LINUX: icmp eq i32 %{{.*}}, 4352
 // LINUX: ret void (i32, double)* @foo_multi.fma4_sse4.2
@@ -139,7 +139,7 @@
 // LINUX: ret void (i32, double)* @foo_multi.avx_sse4.2
 // LINUX: ret void (i32, double)* @foo_multi
 
-// WINDOWS: define dso_local void @foo_multi.resolver(i32 %0, 

r371586 - [CodeGen] Add alias for cpu_dispatch function with IFunc & Fix resolver linkage type

[Fangrui Song via cfe-commits]

Author: maskray
Date: Tue Sep 10 18:54:48 2019
New Revision: 371586

URL: http://llvm.org/viewvc/llvm-project?rev=371586=rev
Log:
[CodeGen] Add alias for cpu_dispatch function with IFunc & Fix resolver linkage 
type

Multi-versioned functions defined by cpu_dispatch and implemented with IFunc
can not be called outside the translation units where they are defined due to
lack of symbols. This patch add function aliases for these functions and thus
make them visible outside.

Differential Revision: https://reviews.llvm.org/D67058
Patch by Senran Zhang

Modified:
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/test/CodeGen/attr-cpuspecific.c
cfe/trunk/test/CodeGen/attr-target-mv-func-ptrs.c
cfe/trunk/test/CodeGen/attr-target-mv-va-args.c
cfe/trunk/test/CodeGen/attr-target-mv.c
cfe/trunk/test/CodeGenCXX/attr-cpuspecific.cpp
cfe/trunk/test/CodeGenCXX/attr-target-mv-diff-ns.cpp
cfe/trunk/test/CodeGenCXX/attr-target-mv-inalloca.cpp
cfe/trunk/test/CodeGenCXX/attr-target-mv-member-funcs.cpp
cfe/trunk/test/CodeGenCXX/attr-target-mv-modules.cpp
cfe/trunk/test/CodeGenCXX/attr-target-mv-out-of-line-defs.cpp
cfe/trunk/test/CodeGenCXX/attr-target-mv-overloads.cpp

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=371586=371585=371586=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Tue Sep 10 18:54:48 2019
@@ -2836,11 +2836,13 @@ void CodeGenModule::emitMultiVersionFunc
 llvm::Function *ResolverFunc;
 const TargetInfo  = getTarget();
 
-if (TI.supportsIFunc() || FD->isTargetMultiVersion())
+if (TI.supportsIFunc() || FD->isTargetMultiVersion()) {
   ResolverFunc = cast(
   GetGlobalValue((getMangledName(GD) + ".resolver").str()));
-else
+  ResolverFunc->setLinkage(llvm::Function::WeakODRLinkage);
+} else {
   ResolverFunc = cast(GetGlobalValue(getMangledName(GD)));
+}
 
 if (supportsCOMDAT())
   ResolverFunc->setComdat(
@@ -2884,6 +2886,10 @@ void CodeGenModule::emitCPUDispatchDefin
 
   auto *ResolverFunc = cast(GetOrCreateLLVMFunction(
   ResolverName, ResolverType, ResolverGD, /*ForVTable=*/false));
+  ResolverFunc->setLinkage(llvm::Function::WeakODRLinkage);
+  if (supportsCOMDAT())
+ResolverFunc->setComdat(
+getModule().getOrInsertComdat(ResolverFunc->getName()));
 
   SmallVector Options;
   const TargetInfo  = getTarget();
@@ -2948,6 +2954,21 @@ void CodeGenModule::emitCPUDispatchDefin
 
   CodeGenFunction CGF(*this);
   CGF.EmitMultiVersionResolver(ResolverFunc, Options);
+
+  if (getTarget().supportsIFunc()) {
+std::string AliasName = getMangledNameImpl(
+*this, GD, FD, /*OmitMultiVersionMangling=*/true);
+llvm::Constant *AliasFunc = GetGlobalValue(AliasName);
+if (!AliasFunc) {
+  auto *IFunc = cast(GetOrCreateLLVMFunction(
+  AliasName, DeclTy, GD, /*ForVTable=*/false, /*DontDefer=*/true,
+  /*IsThunk=*/false, llvm::AttributeList(), NotForDefinition));
+  auto *GA = llvm::GlobalAlias::create(
+ DeclTy, 0, getFunctionLinkage(GD), AliasName, IFunc, ());
+  GA->setLinkage(llvm::Function::WeakODRLinkage);
+  SetCommonAttributes(GD, GA);
+}
+  }
 }
 
 /// If a dispatcher for the specified mangled name is not in the module, create
@@ -2984,7 +3005,7 @@ llvm::Constant *CodeGenModule::GetOrCrea
 MangledName + ".resolver", ResolverType, GlobalDecl{},
 /*ForVTable=*/false);
 llvm::GlobalIFunc *GIF = llvm::GlobalIFunc::create(
-DeclTy, 0, llvm::Function::ExternalLinkage, "", Resolver, 
());
+DeclTy, 0, llvm::Function::WeakODRLinkage, "", Resolver, ());
 GIF->setName(ResolverName);
 SetCommonAttributes(FD, GIF);
 

Modified: cfe/trunk/test/CodeGen/attr-cpuspecific.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/attr-cpuspecific.c?rev=371586=371585=371586=diff
==
--- cfe/trunk/test/CodeGen/attr-cpuspecific.c (original)
+++ cfe/trunk/test/CodeGen/attr-cpuspecific.c Tue Sep 10 18:54:48 2019
@@ -7,11 +7,27 @@
 #define ATTR(X) __attribute__((X))
 #endif // _MSC_VER
 
-// Each called version should have an IFunc.
-// LINUX: @SingleVersion.ifunc = ifunc void (), void ()* ()* 
@SingleVersion.resolver
-// LINUX: @TwoVersions.ifunc = ifunc void (), void ()* ()* 
@TwoVersions.resolver
-// LINUX: @TwoVersionsSameAttr.ifunc = ifunc void (), void ()* ()* 
@TwoVersionsSameAttr.resolver
-// LINUX: @ThreeVersionsSameAttr.ifunc = ifunc void (), void ()* ()* 
@ThreeVersionsSameAttr.resolver
+// Each version should have an IFunc and an alias.
+// LINUX: @TwoVersions = weak_odr alias void (), void ()* @TwoVersions.ifunc
+// LINUX: @TwoVersionsSameAttr = weak_odr alias void (), void ()* 

[PATCH] D66324: clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM

[Petr Hosek via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL371584: clang-misexpect: Profile Guided Validation of 
Performance Annotations in LLVM (authored by phosek, committed by ).
Herald added a subscriber: delcypher.

Changed prior to commit:
  https://reviews.llvm.org/D66324?vs=219617=219645#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D66324

Files:
  cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
  cfe/trunk/include/clang/Basic/DiagnosticGroups.td
  cfe/trunk/lib/CodeGen/CodeGenAction.cpp
  cfe/trunk/lib/Frontend/CompilerInvocation.cpp
  cfe/trunk/test/Profile/Inputs/misexpect-branch-nonconst-expect-arg.proftext
  cfe/trunk/test/Profile/Inputs/misexpect-branch.proftext
  cfe/trunk/test/Profile/Inputs/misexpect-switch-default-only.proftext
  cfe/trunk/test/Profile/Inputs/misexpect-switch-default.proftext
  cfe/trunk/test/Profile/Inputs/misexpect-switch-nonconst.proftext
  cfe/trunk/test/Profile/Inputs/misexpect-switch.proftext
  cfe/trunk/test/Profile/misexpect-branch-cold.c
  cfe/trunk/test/Profile/misexpect-branch-nonconst-expected-val.c
  cfe/trunk/test/Profile/misexpect-branch-unpredictable.c
  cfe/trunk/test/Profile/misexpect-branch.c
  cfe/trunk/test/Profile/misexpect-switch-default.c
  cfe/trunk/test/Profile/misexpect-switch-nonconst.c
  cfe/trunk/test/Profile/misexpect-switch-only-default-case.c
  cfe/trunk/test/Profile/misexpect-switch.c
  compiler-rt/trunk/lib/profile/xxhash.c
  compiler-rt/trunk/lib/profile/xxhash.h
  llvm/trunk/include/llvm/IR/DiagnosticInfo.h
  llvm/trunk/include/llvm/IR/FixedMetadataKinds.def
  llvm/trunk/include/llvm/IR/MDBuilder.h
  llvm/trunk/include/llvm/Transforms/Utils/MisExpect.h
  llvm/trunk/lib/IR/DiagnosticInfo.cpp
  llvm/trunk/lib/IR/MDBuilder.cpp
  llvm/trunk/lib/Transforms/IPO/SampleProfile.cpp
  llvm/trunk/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
  llvm/trunk/lib/Transforms/Scalar/LowerExpectIntrinsic.cpp
  llvm/trunk/lib/Transforms/Utils/CMakeLists.txt
  llvm/trunk/lib/Transforms/Utils/MisExpect.cpp
  llvm/trunk/test/ThinLTO/X86/lazyload_metadata.ll
  llvm/trunk/test/Transforms/LowerExpectIntrinsic/basic.ll
  llvm/trunk/test/Transforms/PGOProfile/Inputs/misexpect-branch-correct.proftext
  llvm/trunk/test/Transforms/PGOProfile/Inputs/misexpect-branch.proftext
  llvm/trunk/test/Transforms/PGOProfile/Inputs/misexpect-switch-correct.proftext
  llvm/trunk/test/Transforms/PGOProfile/Inputs/misexpect-switch.proftext
  llvm/trunk/test/Transforms/PGOProfile/misexpect-branch-correct.ll
  llvm/trunk/test/Transforms/PGOProfile/misexpect-branch-stripped.ll
  llvm/trunk/test/Transforms/PGOProfile/misexpect-branch-unpredictable.ll
  llvm/trunk/test/Transforms/PGOProfile/misexpect-branch.ll
  llvm/trunk/test/Transforms/PGOProfile/misexpect-switch-default.ll
  llvm/trunk/test/Transforms/PGOProfile/misexpect-switch.ll

Index: llvm/trunk/include/llvm/IR/MDBuilder.h
===
--- llvm/trunk/include/llvm/IR/MDBuilder.h
+++ llvm/trunk/include/llvm/IR/MDBuilder.h
@@ -16,6 +16,7 @@
 
 #include "llvm/ADT/DenseSet.h"
 #include "llvm/ADT/StringRef.h"
+#include "llvm/IR/Constants.h"
 #include "llvm/IR/GlobalValue.h"
 #include "llvm/Support/DataTypes.h"
 #include 
@@ -75,6 +76,10 @@
   /// Return metadata containing the section prefix for a function.
   MDNode *createFunctionSectionPrefix(StringRef Prefix);
 
+  /// return metadata containing expected value
+  MDNode *createMisExpect(uint64_t Index, uint64_t LikelyWeight,
+  uint64_t UnlikelyWeight);
+
   //===--===//
   // Range metadata.
   //===--===//
Index: llvm/trunk/include/llvm/IR/FixedMetadataKinds.def
===
--- llvm/trunk/include/llvm/IR/FixedMetadataKinds.def
+++ llvm/trunk/include/llvm/IR/FixedMetadataKinds.def
@@ -39,3 +39,4 @@
 LLVM_FIXED_MD_KIND(MD_access_group, "llvm.access.group", 25)
 LLVM_FIXED_MD_KIND(MD_callback, "callback", 26)
 LLVM_FIXED_MD_KIND(MD_preserve_access_index, "llvm.preserve.access.index", 27)
+LLVM_FIXED_MD_KIND(MD_misexpect, "misexpect", 28)
Index: llvm/trunk/include/llvm/IR/DiagnosticInfo.h
===
--- llvm/trunk/include/llvm/IR/DiagnosticInfo.h
+++ llvm/trunk/include/llvm/IR/DiagnosticInfo.h
@@ -75,7 +75,8 @@
   DK_MIRParser,
   DK_PGOProfile,
   DK_Unsupported,
-  DK_FirstPluginKind
+  DK_FirstPluginKind,
+  DK_MisExpect
 };
 
 /// Get the next available kind ID for a plugin diagnostic.
@@ -1002,6 +1003,25 @@
   void print(DiagnosticPrinter ) const override;
 };
 
+/// Diagnostic information for MisExpect analysis.
+class DiagnosticInfoMisExpect : public DiagnosticInfoWithLocationBase {
+public:
+DiagnosticInfoMisExpect(const 

r371584 - clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM

[Petr Hosek via cfe-commits]

Author: phosek
Date: Tue Sep 10 18:09:16 2019
New Revision: 371584

URL: http://llvm.org/viewvc/llvm-project?rev=371584=rev
Log:
clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM

This patch contains the basic functionality for reporting potentially
incorrect usage of __builtin_expect() by comparing the developer's
annotation against a collected PGO profile. A more detailed proposal and
discussion appears on the CFE-dev mailing list
(http://lists.llvm.org/pipermail/cfe-dev/2019-July/062971.html) and a
prototype of the initial frontend changes appear here in D65300

We revised the work in D65300 by moving the misexpect check into the
LLVM backend, and adding support for IR and sampling based profiles, in
addition to frontend instrumentation.

We add new misexpect metadata tags to those instructions directly
influenced by the llvm.expect intrinsic (branch, switch, and select)
when lowering the intrinsics. The misexpect metadata contains
information about the expected target of the intrinsic so that we can
check against the correct PGO counter when emitting diagnostics, and the
compiler's values for the LikelyBranchWeight and UnlikelyBranchWeight.
We use these branch weight values to determine when to emit the
diagnostic to the user.

A future patch should address the comment at the top of
LowerExpectIntrisic.cpp to hoist the LikelyBranchWeight and
UnlikelyBranchWeight values into a shared space that can be accessed
outside of the LowerExpectIntrinsic pass. Once that is done, the
misexpect metadata can be updated to be smaller.

In the long term, it is possible to reconstruct portions of the
misexpect metadata from the existing profile data. However, we have
avoided this to keep the code simple, and because some kind of metadata
tag will be required to identify which branch/switch/select instructions
are influenced by the use of llvm.expect

Patch By: paulkirth
Differential Revision: https://reviews.llvm.org/D66324

Added:
cfe/trunk/test/Profile/Inputs/misexpect-branch-nonconst-expect-arg.proftext
cfe/trunk/test/Profile/Inputs/misexpect-branch.proftext
cfe/trunk/test/Profile/Inputs/misexpect-switch-default-only.proftext
cfe/trunk/test/Profile/Inputs/misexpect-switch-default.proftext
cfe/trunk/test/Profile/Inputs/misexpect-switch-nonconst.proftext
cfe/trunk/test/Profile/Inputs/misexpect-switch.proftext
cfe/trunk/test/Profile/misexpect-branch-cold.c
cfe/trunk/test/Profile/misexpect-branch-nonconst-expected-val.c
cfe/trunk/test/Profile/misexpect-branch-unpredictable.c
cfe/trunk/test/Profile/misexpect-branch.c
cfe/trunk/test/Profile/misexpect-switch-default.c
cfe/trunk/test/Profile/misexpect-switch-nonconst.c
cfe/trunk/test/Profile/misexpect-switch-only-default-case.c
cfe/trunk/test/Profile/misexpect-switch.c
Modified:
cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
cfe/trunk/include/clang/Basic/DiagnosticGroups.td
cfe/trunk/lib/CodeGen/CodeGenAction.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td?rev=371584=371583=371584=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticFrontendKinds.td Tue Sep 10 
18:09:16 2019
@@ -275,7 +275,12 @@ def warn_profile_data_missing : Warning<
 def warn_profile_data_unprofiled : Warning<
   "no profile data available for file \"%0\"">,
   InGroup;
-
+def warn_profile_data_misexpect : Warning<
+  "Potential performance regression from use of __builtin_expect(): "
+  "Annotation was correct on %0 of profiled executions.">,
+  BackendInfo,
+  InGroup,
+  DefaultIgnore;
 } // end of instrumentation issue category
 
 }

Modified: cfe/trunk/include/clang/Basic/DiagnosticGroups.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticGroups.td?rev=371584=371583=371584=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticGroups.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticGroups.td Tue Sep 10 18:09:16 2019
@@ -1042,6 +1042,7 @@ def BackendOptimizationFailure : DiagGro
 def ProfileInstrMissing : DiagGroup<"profile-instr-missing">;
 def ProfileInstrOutOfDate : DiagGroup<"profile-instr-out-of-date">;
 def ProfileInstrUnprofiled : DiagGroup<"profile-instr-unprofiled">;
+def MisExpect : DiagGroup<"misexpect">;
 
 // AddressSanitizer frontend instrumentation remarks.
 def SanitizeAddressRemarks : DiagGroup<"sanitize-address">;

Modified: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenAction.cpp?rev=371584=371583=371584=diff

[PATCH] D67304: Emit -Wmicrosoft-enum-value warning instead of error in MS ABI

[Reid Kleckner via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL371581: Emit -Wmicrosoft-enum-value warning instead of error 
in MS ABI (authored by rnk, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67304?vs=219425=219643#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67304

Files:
  cfe/trunk/lib/Sema/SemaDecl.cpp
  cfe/trunk/test/Sema/MicrosoftCompatibility.c


Index: cfe/trunk/test/Sema/MicrosoftCompatibility.c
===
--- cfe/trunk/test/Sema/MicrosoftCompatibility.c
+++ cfe/trunk/test/Sema/MicrosoftCompatibility.c
@@ -1,10 +1,18 @@
-// RUN: %clang_cc1 %s -fsyntax-only -Wno-unused-value -Wmicrosoft -verify 
-fms-compatibility -triple i686-pc-win32
+// RUN: %clang_cc1 %s -fsyntax-only -Wno-unused-value -Wmicrosoft -verify 
-fms-compatibility -DMSVCCOMPAT -triple i686-pc-win32
+// RUN: %clang_cc1 %s -fsyntax-only -Wno-unused-value -Wmicrosoft -verify 
-fms-extensions -triple i686-pc-win32
 
+#ifdef MSVCCOMPAT
 enum ENUM1; // expected-warning {{forward references to 'enum' types are a 
Microsoft extension}}
 enum ENUM1 var1 = 3;
 enum ENUM1* var2 = 0;
+#else
+enum ENUM1; // expected-note {{forward declaration of}}
+enum ENUM1 var1 = 3; // expected-error {{variable has incomplete type 'enum 
ENUM1'}}
+enum ENUM1* var2 = 0;
+#endif
 
 
+// FIXME: The rest of this seems to be controlled by -fms-extensions. Move it.
 enum ENUM2 {
   ENUM2_a = (enum ENUM2) 4,
   ENUM2_b = 0x9FFF, // expected-warning {{enumerator value is not 
representable in the underlying type 'int'}}
@@ -22,4 +30,8 @@
 
 __declspec(__noreturn__) void f7(void); /* expected-warning {{__declspec 
attribute '__noreturn__' is not supported}} */
 
+#ifdef MSVCCOMPAT
 size_t x;
+#else
+size_t x; // expected-error {{unknown type name 'size_t'}}
+#endif
Index: cfe/trunk/lib/Sema/SemaDecl.cpp
===
--- cfe/trunk/lib/Sema/SemaDecl.cpp
+++ cfe/trunk/lib/Sema/SemaDecl.cpp
@@ -14723,7 +14723,7 @@
   UPPC_FixedUnderlyingType))
 EnumUnderlying = Context.IntTy.getTypePtr();
 
-} else if (Context.getTargetInfo().getCXXABI().isMicrosoft()) {
+} else if (Context.getTargetInfo().getTriple().isWindowsMSVCEnvironment()) 
{
   // For MSVC ABI compatibility, unfixed enums must use an underlying type
   // of 'int'. However, if this is an unfixed forward declaration, don't 
set
   // the underlying type unless the user enables -fms-compatibility. This
@@ -16850,8 +16850,7 @@
 if (Enum->isDependentType() || Val->isTypeDependent())
   EltTy = Context.DependentTy;
 else {
-  if (getLangOpts().CPlusPlus11 && Enum->isFixed() &&
-  !getLangOpts().MSVCCompat) {
+  if (getLangOpts().CPlusPlus11 && Enum->isFixed()) {
 // C++11 [dcl.enum]p5: If the underlying type is fixed, [...] the
 // constant-expression in the enumerator-definition shall be a 
converted
 // constant expression of the underlying type.
@@ -16876,15 +16875,19 @@
   // we perform a non-narrowing conversion as part of converted 
constant
   // expression checking.
   if (!isRepresentableIntegerValue(Context, EnumVal, EltTy)) {
-if (getLangOpts().MSVCCompat) {
+if (Context.getTargetInfo()
+.getTriple()
+.isWindowsMSVCEnvironment()) {
   Diag(IdLoc, diag::ext_enumerator_too_large) << EltTy;
-  Val = ImpCastExprToType(Val, EltTy, CK_IntegralCast).get();
-} else
+} else {
   Diag(IdLoc, diag::err_enumerator_too_large) << EltTy;
-  } else
-Val = ImpCastExprToType(Val, EltTy,
-EltTy->isBooleanType() ?
-CK_IntegralToBoolean : CK_IntegralCast)
+}
+  }
+
+  // Cast to the underlying type.
+  Val = ImpCastExprToType(Val, EltTy,
+  EltTy->isBooleanType() ? CK_IntegralToBoolean
+ : CK_IntegralCast)
 .get();
 } else if (getLangOpts().CPlusPlus) {
   // C++11 [dcl.enum]p5:


Index: cfe/trunk/test/Sema/MicrosoftCompatibility.c
===
--- cfe/trunk/test/Sema/MicrosoftCompatibility.c
+++ cfe/trunk/test/Sema/MicrosoftCompatibility.c
@@ -1,10 +1,18 @@
-// RUN: %clang_cc1 %s -fsyntax-only -Wno-unused-value -Wmicrosoft -verify -fms-compatibility -triple i686-pc-win32
+// RUN: %clang_cc1 %s -fsyntax-only -Wno-unused-value -Wmicrosoft -verify -fms-compatibility -DMSVCCOMPAT -triple i686-pc-win32
+// RUN: %clang_cc1 %s -fsyntax-only 

r371581 - Emit -Wmicrosoft-enum-value warning instead of error in MS ABI

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Tue Sep 10 18:01:06 2019
New Revision: 371581

URL: http://llvm.org/viewvc/llvm-project?rev=371581=rev
Log:
Emit -Wmicrosoft-enum-value warning instead of error in MS ABI

Summary:
The first NFC change is to replace a getCXXABI().isMicrosoft() check
with getTriple().isWindowsMSVCEnvironment(). This code takes effect in
non-C++ compilations, so it doesn't make sense to check the C++ ABI. In
the MS ABI, enums are always considered to be "complete" because the
underlying type of an unfixed enum will always be 'int'. This behavior
was moved from -fms-compatibility to MS ABI back in r249656.

The second change is functional, and it downgrades an error to a warning
when the MS ABI is used rather than only under -fms-compatibility. The
reasoning is that it's unreasonable for the following code to reject the
following code for all MS ABI targets with -fno-ms-compatibility:
  enum Foo { Foo_Val = 0xDEADBEEF };
This is valid code for any other target, but in the MS ABI, Foo_Val just
happens to be negative. With this change, clang emits a
-Wmicrosoft-enum-value warning on this code, but compiles it without
error.

Fixes PR38478

Reviewers: hans, rsmith, STL_MSFT

Subscribers: cfe-commits

Tags: #clang

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

Modified:
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/test/Sema/MicrosoftCompatibility.c

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=371581=371580=371581=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Tue Sep 10 18:01:06 2019
@@ -14723,7 +14723,7 @@ Decl *Sema::ActOnTag(Scope *S, unsigned
   UPPC_FixedUnderlyingType))
 EnumUnderlying = Context.IntTy.getTypePtr();
 
-} else if (Context.getTargetInfo().getCXXABI().isMicrosoft()) {
+} else if (Context.getTargetInfo().getTriple().isWindowsMSVCEnvironment()) 
{
   // For MSVC ABI compatibility, unfixed enums must use an underlying type
   // of 'int'. However, if this is an unfixed forward declaration, don't 
set
   // the underlying type unless the user enables -fms-compatibility. This
@@ -16850,8 +16850,7 @@ EnumConstantDecl *Sema::CheckEnumConstan
 if (Enum->isDependentType() || Val->isTypeDependent())
   EltTy = Context.DependentTy;
 else {
-  if (getLangOpts().CPlusPlus11 && Enum->isFixed() &&
-  !getLangOpts().MSVCCompat) {
+  if (getLangOpts().CPlusPlus11 && Enum->isFixed()) {
 // C++11 [dcl.enum]p5: If the underlying type is fixed, [...] the
 // constant-expression in the enumerator-definition shall be a 
converted
 // constant expression of the underlying type.
@@ -16876,15 +16875,19 @@ EnumConstantDecl *Sema::CheckEnumConstan
   // we perform a non-narrowing conversion as part of converted 
constant
   // expression checking.
   if (!isRepresentableIntegerValue(Context, EnumVal, EltTy)) {
-if (getLangOpts().MSVCCompat) {
+if (Context.getTargetInfo()
+.getTriple()
+.isWindowsMSVCEnvironment()) {
   Diag(IdLoc, diag::ext_enumerator_too_large) << EltTy;
-  Val = ImpCastExprToType(Val, EltTy, CK_IntegralCast).get();
-} else
+} else {
   Diag(IdLoc, diag::err_enumerator_too_large) << EltTy;
-  } else
-Val = ImpCastExprToType(Val, EltTy,
-EltTy->isBooleanType() ?
-CK_IntegralToBoolean : CK_IntegralCast)
+}
+  }
+
+  // Cast to the underlying type.
+  Val = ImpCastExprToType(Val, EltTy,
+  EltTy->isBooleanType() ? CK_IntegralToBoolean
+ : CK_IntegralCast)
 .get();
 } else if (getLangOpts().CPlusPlus) {
   // C++11 [dcl.enum]p5:

Modified: cfe/trunk/test/Sema/MicrosoftCompatibility.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/MicrosoftCompatibility.c?rev=371581=371580=371581=diff
==
--- cfe/trunk/test/Sema/MicrosoftCompatibility.c (original)
+++ cfe/trunk/test/Sema/MicrosoftCompatibility.c Tue Sep 10 18:01:06 2019
@@ -1,10 +1,18 @@
-// RUN: %clang_cc1 %s -fsyntax-only -Wno-unused-value -Wmicrosoft -verify 
-fms-compatibility -triple i686-pc-win32
+// RUN: %clang_cc1 %s -fsyntax-only -Wno-unused-value -Wmicrosoft -verify 
-fms-compatibility -DMSVCCOMPAT -triple i686-pc-win32
+// RUN: %clang_cc1 %s -fsyntax-only -Wno-unused-value -Wmicrosoft -verify 
-fms-extensions -triple i686-pc-win32
 
+#ifdef MSVCCOMPAT
 enum ENUM1; // expected-warning {{forward references to 'enum' types are a 
Microsoft 

[PATCH] D67425: [WebAssembly] Narrowing and widening SIMD ops

[Heejin Ahn via Phabricator via cfe-commits]

aheejin added a comment.

Can you give the link for the spec of these new instructions?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67425



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

[PATCH] D67426: Don't warn about selectany on implicitly inline variables

[Reid Kleckner via Phabricator via cfe-commits]

rnk created this revision.
rnk added reviewers: epastor, thakis, hans.
Herald added a project: clang.

This avoids a -Wignored-attribute warning on the code pattern Microsoft
recommends for integral const static data members defined in headers
here:
https://docs.microsoft.com/en-us/cpp/build/reference/microsoft-extensions-to-c-and-cpp?view=vs-2019

The attribute is redundant, but it is necessary when compiling in C++14
modes with /Za, which disables MSVC's extension that treats such
variables as implicitly inline.

Fixes PR43270


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D67426

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/SemaCXX/declspec-selectany.cpp


Index: clang/test/SemaCXX/declspec-selectany.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/declspec-selectany.cpp
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -std=c++14 %s -triple x86_64-windows-msvc -fdeclspec -verify
+// RUN: %clang_cc1 -std=c++17 %s -triple x86_64-windows-msvc -fdeclspec -verify
+// RUN: %clang_cc1 -std=c++14 %s -triple x86_64-scei-ps4 -fdeclspec -verify
+
+// MSVC emits this error too.
+const int __declspec(selectany) test1 = 0; // expected-error {{'selectany' can 
only be applied to data items with external linkage}}
+
+extern const int test2;
+const int test2 = 42; // expected-note {{previous definition is here}}
+extern __declspec(selectany) const int test2; // expected-warning {{attribute 
declaration must precede definition}}
+
+extern const int test3;
+const int __declspec(selectany) test3 = 42; // Standard usage.
+
+struct Test4 {
+  static constexpr int sdm = 0;
+};
+__declspec(selectany) constexpr int Test4::sdm; // no warning
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -2652,6 +2652,15 @@
 --E;
 continue;
   }
+} else if (isa(NewAttribute) &&
+   cast(New)->isInline() &&
+   !cast(New)->isInlineSpecified()) {
+  // Don't warn about applying selectany to implicitly inline variables.
+  // Older compilers and language modes would require the use of selectany
+  // to make such variables inline, and it would have no effect if we
+  // honored it.
+  ++I;
+  continue;
 }
 
 S.Diag(NewAttribute->getLocation(),


Index: clang/test/SemaCXX/declspec-selectany.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/declspec-selectany.cpp
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -std=c++14 %s -triple x86_64-windows-msvc -fdeclspec -verify
+// RUN: %clang_cc1 -std=c++17 %s -triple x86_64-windows-msvc -fdeclspec -verify
+// RUN: %clang_cc1 -std=c++14 %s -triple x86_64-scei-ps4 -fdeclspec -verify
+
+// MSVC emits this error too.
+const int __declspec(selectany) test1 = 0; // expected-error {{'selectany' can only be applied to data items with external linkage}}
+
+extern const int test2;
+const int test2 = 42; // expected-note {{previous definition is here}}
+extern __declspec(selectany) const int test2; // expected-warning {{attribute declaration must precede definition}}
+
+extern const int test3;
+const int __declspec(selectany) test3 = 42; // Standard usage.
+
+struct Test4 {
+  static constexpr int sdm = 0;
+};
+__declspec(selectany) constexpr int Test4::sdm; // no warning
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -2652,6 +2652,15 @@
 --E;
 continue;
   }
+} else if (isa(NewAttribute) &&
+   cast(New)->isInline() &&
+   !cast(New)->isInlineSpecified()) {
+  // Don't warn about applying selectany to implicitly inline variables.
+  // Older compilers and language modes would require the use of selectany
+  // to make such variables inline, and it would have no effect if we
+  // honored it.
+  ++I;
+  continue;
 }
 
 S.Diag(NewAttribute->getLocation(),
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r371578 - [clang-scan-deps][NFC] Fix tests - prevent FileCheck matching test dir path

[Jan Korous via cfe-commits]

Author: jkorous
Date: Tue Sep 10 17:30:26 2019
New Revision: 371578

URL: http://llvm.org/viewvc/llvm-project?rev=371578=rev
Log:
[clang-scan-deps][NFC] Fix tests - prevent FileCheck matching test dir path

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

Modified:
cfe/trunk/test/ClangScanDeps/Inputs/header_stat_before_open_cdb.json
cfe/trunk/test/ClangScanDeps/Inputs/no-werror.json
cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json
cfe/trunk/test/ClangScanDeps/Inputs/subframework_header_dir_symlink_cdb.json
cfe/trunk/test/ClangScanDeps/Inputs/symlink_cdb.json
cfe/trunk/test/ClangScanDeps/Inputs/vfsoverlay_cdb.json
cfe/trunk/test/ClangScanDeps/error.cpp
cfe/trunk/test/ClangScanDeps/header_stat_before_open.m
cfe/trunk/test/ClangScanDeps/no-werror.cpp
cfe/trunk/test/ClangScanDeps/regular_cdb.cpp
cfe/trunk/test/ClangScanDeps/subframework_header_dir_symlink.m
cfe/trunk/test/ClangScanDeps/symlink.cpp
cfe/trunk/test/ClangScanDeps/vfsoverlay.cpp

Modified: cfe/trunk/test/ClangScanDeps/Inputs/header_stat_before_open_cdb.json
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/header_stat_before_open_cdb.json?rev=371578=371577=371578=diff
==
--- cfe/trunk/test/ClangScanDeps/Inputs/header_stat_before_open_cdb.json 
(original)
+++ cfe/trunk/test/ClangScanDeps/Inputs/header_stat_before_open_cdb.json Tue 
Sep 10 17:30:26 2019
@@ -1,7 +1,7 @@
 [
 {
   "directory": "DIR",
-  "command": "clang -E DIR/header_stat_before_open.m -iframework 
Inputs/frameworks",
-  "file": "DIR/header_stat_before_open.m"
+  "command": "clang -E DIR/header_stat_before_open_input.m -iframework 
Inputs/frameworks",
+  "file": "DIR/header_stat_before_open_input.m"
 }
 ]

Modified: cfe/trunk/test/ClangScanDeps/Inputs/no-werror.json
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/no-werror.json?rev=371578=371577=371578=diff
==
--- cfe/trunk/test/ClangScanDeps/Inputs/no-werror.json (original)
+++ cfe/trunk/test/ClangScanDeps/Inputs/no-werror.json Tue Sep 10 17:30:26 2019
@@ -1,7 +1,7 @@
 [
 {
   "directory": "DIR",
-  "command": "clang -E DIR/no-werror.cpp -IInputs -std=c++17 -Weverything 
-Werror",
+  "command": "clang -E DIR/no-werror_input.cpp -IInputs -std=c++17 
-Weverything -Werror",
   "file": "DIR/no-werror.cpp"
 }
 ]

Modified: cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json?rev=371578=371577=371578=diff
==
--- cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json (original)
+++ cfe/trunk/test/ClangScanDeps/Inputs/regular_cdb.json Tue Sep 10 17:30:26 
2019
@@ -1,12 +1,12 @@
 [
 {
   "directory": "DIR",
-  "command": "clang -E -fsyntax-only DIR/regular_cdb2.cpp -IInputs -D 
INCLUDE_HEADER2 -MD -MF DIR/regular_cdb2.d",
-  "file": "DIR/regular_cdb2.cpp"
+  "command": "clang -E -fsyntax-only DIR/regular_cdb_input2.cpp -IInputs -D 
INCLUDE_HEADER2 -MD -MF DIR/regular_cdb2.d",
+  "file": "DIR/regular_cdb_input2.cpp"
 },
 {
   "directory": "DIR",
-  "command": "clang -E DIR/regular_cdb.cpp -IInputs",
-  "file": "DIR/regular_cdb.cpp"
+  "command": "clang -E DIR/regular_cdb_input.cpp -IInputs",
+  "file": "DIR/regular_cdb_input.cpp"
 }
 ]

Modified: 
cfe/trunk/test/ClangScanDeps/Inputs/subframework_header_dir_symlink_cdb.json
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/subframework_header_dir_symlink_cdb.json?rev=371578=371577=371578=diff
==
--- 
cfe/trunk/test/ClangScanDeps/Inputs/subframework_header_dir_symlink_cdb.json 
(original)
+++ 
cfe/trunk/test/ClangScanDeps/Inputs/subframework_header_dir_symlink_cdb.json 
Tue Sep 10 17:30:26 2019
@@ -1,12 +1,12 @@
 [
 {
   "directory": "DIR",
-  "command": "clang -E DIR/subframework_header_dir_symlink.m -D EMPTY 
-iframework Inputs/frameworks",
+  "command": "clang -E DIR/subframework_header_dir_symlink_input.m -D EMPTY 
-iframework Inputs/frameworks",
   "file": "DIR/subframework_header_dir_symlink.m"
 },
 {
   "directory": "DIR",
-  "command": "clang -E DIR/subframework_header_dir_symlink2.m 
-FInputs/frameworks -iframework Inputs/frameworks_symlink",
+  "command": "clang -E DIR/subframework_header_dir_symlink_input2.m 
-FInputs/frameworks -iframework Inputs/frameworks_symlink",
   "file": "DIR/subframework_header_dir_symlink2.m"
 }
 ]

Modified: cfe/trunk/test/ClangScanDeps/Inputs/symlink_cdb.json
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/ClangScanDeps/Inputs/symlink_cdb.json?rev=371578=371577=371578=diff
==
--- cfe/trunk/test/ClangScanDeps/Inputs/symlink_cdb.json 

[PATCH] D47956: [MS] Consder constexpr globals to be inline, as in C++17

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

In D47956#1138555 , @rnk wrote:

> In D47956#1138521 , @rsmith wrote:
>
> > Can we now remove the corresponding MSVC-specific hacks elsewhere (eg, 
> > `ASTContext::isMSStaticDataMemberInlineDefinition`), or do we still need 
> > those for `const`-but-not-`constexpr` static data members?
>
>
> We should be able to do that, but unfortunately it drastically changes the 
> diagnostics we emit, as you can see from the tortured ifdefs in my test case 
> updates. I gave up before attempting it.


Coming back to this a year later, I think I got confused. This patch is good to 
go, but I never landed it because I wanted to implement Richard's comment. I 
guess I'll go forward with this and see what breaks. The main thing seems to be 
that now applying dllexport to some static data members outside the class body 
becomes a warning instead of a hard error. So, we should be more accepting with 
this than we were previously.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D47956



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

[PATCH] D67425: [WebAssembly] Narrowing and widening SIMD ops

[Thomas Lively via Phabricator via cfe-commits]

tlively created this revision.
tlively added a reviewer: aheejin.
Herald added subscribers: llvm-commits, cfe-commits, sunfish, hiraditya, 
jgravelle-google, sbc100, dschuff.
Herald added projects: clang, LLVM.

Implements target-specific LLVM intrinsics and clang builtins for
these new SIMD operations.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D67425

Files:
  clang/include/clang/Basic/BuiltinsWebAssembly.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-wasm.c
  llvm/include/llvm/IR/IntrinsicsWebAssembly.td
  llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
  llvm/test/MC/WebAssembly/simd-encodings.s

Index: llvm/test/MC/WebAssembly/simd-encodings.s
===
--- llvm/test/MC/WebAssembly/simd-encodings.s
+++ llvm/test/MC/WebAssembly/simd-encodings.s
@@ -463,4 +463,40 @@
 # CHECK: f64x2.convert_i64x2_u # encoding: [0xfd,0xb2,0x01]
 f64x2.convert_i64x2_u
 
+# CHECK: i8x16.narrow_i16x8_s # encoding: [0xfd,0xc6,0x01]
+i8x16.narrow_i16x8_s
+
+# CHECK: i8x16.narrow_i16x8_u # encoding: [0xfd,0xc7,0x01]
+i8x16.narrow_i16x8_u
+
+# CHECK: i16x8.narrow_i32x4_s # encoding: [0xfd,0xc8,0x01]
+i16x8.narrow_i32x4_s
+
+# CHECK: i16x8.narrow_i32x4_u # encoding: [0xfd,0xc9,0x01]
+i16x8.narrow_i32x4_u
+
+# CHECK: i16x8.widen_low_i8x16_s # encoding: [0xfd,0xca,0x01]
+i16x8.widen_low_i8x16_s
+
+# CHECK: i16x8.widen_high_i8x16_s # encoding: [0xfd,0xcb,0x01]
+i16x8.widen_high_i8x16_s
+
+# CHECK: i16x8.widen_low_i8x16_u # encoding: [0xfd,0xcc,0x01]
+i16x8.widen_low_i8x16_u
+
+# CHECK: i16x8.widen_high_i8x16_u # encoding: [0xfd,0xcd,0x01]
+i16x8.widen_high_i8x16_u
+
+# CHECK: i32x4.widen_low_i16x8_s # encoding: [0xfd,0xce,0x01]
+i32x4.widen_low_i16x8_s
+
+# CHECK: i32x4.widen_high_i16x8_s # encoding: [0xfd,0xcf,0x01]
+i32x4.widen_high_i16x8_s
+
+# CHECK: i32x4.widen_low_i16x8_u # encoding: [0xfd,0xd0,0x01]
+i32x4.widen_low_i16x8_u
+
+# CHECK: i32x4.widen_high_i16x8_u # encoding: [0xfd,0xd1,0x01]
+i32x4.widen_high_i16x8_u
+
 end_function
Index: llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
===
--- llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
+++ llvm/lib/Target/WebAssembly/WebAssemblyInstrSIMD.td
@@ -712,6 +712,33 @@
 defm "" : SIMDConvert;
 defm "" : SIMDConvert;
 
+// Narrowing operations
+multiclass SIMDNarrow baseInst> {
+  defm "" : SIMDConvert;
+  defm "" : SIMDConvert;
+}
+defm "" : SIMDNarrow;
+defm "" : SIMDNarrow;
+
+// Widening operations
+multiclass SIMDWiden baseInst> {
+  defm "" : SIMDConvert;
+  defm "" : SIMDConvert;
+  defm "" : SIMDConvert;
+  defm "" : SIMDConvert;
+}
+
+defm "" : SIMDWiden;
+defm "" : SIMDWiden;
+
 // Lower llvm.wasm.trunc.saturate.* to saturating instructions
 def : Pat<(v4i32 (int_wasm_trunc_saturate_signed (v4f32 V128:$src))),
   (fp_to_sint_v4i32_v4f32 (v4f32 V128:$src))>;
Index: llvm/include/llvm/IR/IntrinsicsWebAssembly.td
===
--- llvm/include/llvm/IR/IntrinsicsWebAssembly.td
+++ llvm/include/llvm/IR/IntrinsicsWebAssembly.td
@@ -117,6 +117,31 @@
   Intrinsic<[llvm_anyvector_ty],
 [LLVMMatchType<0>, LLVMMatchType<0>, LLVMMatchType<0>],
 [IntrNoMem, IntrSpeculatable]>;
+def int_wasm_narrow_signed :
+  Intrinsic<[llvm_anyvector_ty],
+[llvm_anyvector_ty],
+[IntrNoMem, IntrSpeculatable]>;
+def int_wasm_narrow_unsigned :
+  Intrinsic<[llvm_anyvector_ty],
+[llvm_anyvector_ty],
+[IntrNoMem, IntrSpeculatable]>;
+def int_wasm_widen_low_signed :
+  Intrinsic<[llvm_anyvector_ty],
+[llvm_anyvector_ty],
+[IntrNoMem, IntrSpeculatable]>;
+def int_wasm_widen_high_signed :
+  Intrinsic<[llvm_anyvector_ty],
+[llvm_anyvector_ty],
+[IntrNoMem, IntrSpeculatable]>;
+def int_wasm_widen_low_unsigned :
+  Intrinsic<[llvm_anyvector_ty],
+[llvm_anyvector_ty],
+[IntrNoMem, IntrSpeculatable]>;
+def int_wasm_widen_high_unsigned :
+  Intrinsic<[llvm_anyvector_ty],
+[llvm_anyvector_ty],
+[IntrNoMem, IntrSpeculatable]>;
+
 
 //===--===//
 // Bulk memory intrinsics
Index: clang/test/CodeGen/builtins-wasm.c
===
--- clang/test/CodeGen/builtins-wasm.c
+++ clang/test/CodeGen/builtins-wasm.c
@@ -463,3 +463,75 @@
   // WEBASSEMBLY: call <2 x i64> @llvm.wasm.trunc.saturate.unsigned.v2i64.v2f64(<2 x double> %f)
   // WEBASSEMBLY-NEXT: ret
 }
+
+i8x16 narrow_s_i8x16_i16x8(i16x8 v) {
+  return __builtin_wasm_narrow_s_i8x16_i16x8(v);
+  // WEBASSEMBLY: call <16 x i8> @llvm.wasm.narrow.signed.v16i8.v8i16(<8 x i16> %v)
+  // WEBASSEMBLY: ret
+}
+
+i8x16 narrow_u_i8x16_i16x8(i16x8 v) {
+ 

[PATCH] D47956: [MS] Consder constexpr globals to be inline, as in C++17

[Reid Kleckner via Phabricator via cfe-commits]

rnk updated this revision to Diff 219638.
rnk added a comment.
Herald added a subscriber: mstorsjo.
Herald added a project: clang.

- rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D47956

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/CXX/dcl.dcl/dcl.spec/dcl.constexpr/p1.cpp
  clang/test/CXX/drs/dr7xx.cpp
  clang/test/SemaCXX/cxx1y-variable-templates_in_class.cpp
  clang/test/SemaCXX/dllexport.cpp
  clang/test/SemaCXX/dllimport.cpp

Index: clang/test/SemaCXX/dllimport.cpp
===
--- clang/test/SemaCXX/dllimport.cpp
+++ clang/test/SemaCXX/dllimport.cpp
@@ -2,6 +2,7 @@
 // RUN: %clang_cc1 -triple x86_64-win32   -fsyntax-only -fms-extensions -verify -std=c++1y -Wunsupported-dll-base-class-template -DMS %s
 // RUN: %clang_cc1 -triple i686-mingw32   -fsyntax-only -fms-extensions -verify -std=c++1y -Wunsupported-dll-base-class-template -DGNU %s
 // RUN: %clang_cc1 -triple x86_64-mingw32 -fsyntax-only -fms-extensions -verify -std=c++11 -Wunsupported-dll-base-class-template -DGNU %s
+// RUN: %clang_cc1 -triple x86_64-mingw32 -fsyntax-only -fms-extensions -verify -std=c++17 -Wunsupported-dll-base-class-template -DGNU %s
 
 // Helper structs to make templates more expressive.
 struct ImplicitInst_Imported {};
@@ -586,7 +587,10 @@
   __declspec(dllimport) static  const  int  StaticConstFieldEqualInit = 1;
   __declspec(dllimport) static  const  int  StaticConstFieldBraceInit{1};
   __declspec(dllimport) constexpr static int ConstexprField = 1;
-  __declspec(dllimport) constexpr static int ConstexprFieldDef = 1; // expected-note{{attribute is here}}
+#if __cplusplus < 201703L && !defined(MS)
+  // expected-note@+2{{attribute is here}}
+#endif
+  __declspec(dllimport) constexpr static int ConstexprFieldDef = 1;
 };
 
 #ifdef MS
@@ -631,7 +635,10 @@
 
int  ImportMembers::StaticFieldDef; // expected-error{{definition of dllimport static field not allowed}}
 const  int  ImportMembers::StaticConstFieldDef = 1; // expected-error{{definition of dllimport static field not allowed}}
-constexpr int ImportMembers::ConstexprFieldDef; // expected-error{{definition of dllimport static field not allowed}}
+#if __cplusplus < 201703L && !defined(MS)
+// expected-error@+2{{definition of dllimport static field not allowed}}
+#endif
+constexpr int ImportMembers::ConstexprFieldDef;
 
 
 // Import on member definitions.
@@ -667,7 +674,11 @@
 
 __declspec(dllimport)int  ImportMemberDefs::StaticField; // expected-error{{definition of dllimport static field not allowed}} expected-note{{attribute is here}}
 __declspec(dllimport) const  int  ImportMemberDefs::StaticConstField = 1; // expected-error{{definition of dllimport static field not allowed}} expected-note{{attribute is here}}
-__declspec(dllimport) constexpr int ImportMemberDefs::ConstexprField; // expected-error{{definition of dllimport static field not allowed}} expected-note{{attribute is here}}
+#if __cplusplus < 201703L && !defined(MS)
+// expected-error@+3{{definition of dllimport static field not allowed}}
+// expected-note@+2{{attribute is here}}
+#endif
+__declspec(dllimport) constexpr int ImportMemberDefs::ConstexprField;
 
 
 // Import special member functions.
@@ -800,7 +811,7 @@
 
   static int  StaticField; // expected-note{{previous declaration is here}}
   static  const  int  StaticConstField;// expected-note{{previous declaration is here}}
-  constexpr static int ConstexprField = 1; // expected-note{{previous declaration is here}}
+  constexpr static int ConstexprField = 1; // expected-note-re{{previous {{(declaration|definition)}} is here}}
 };
 
 __declspec(dllimport)void MemberRedecl::normalDef() {} // expected-error{{redeclaration of 'MemberRedecl::normalDef' cannot add 'dllimport' attribute}}
@@ -831,9 +842,15 @@
 __declspec(dllimport) const  int  MemberRedecl::StaticConstField = 1;  // expected-error{{redeclaration of 'MemberRedecl::StaticConstField' cannot add 'dllimport' attribute}}
// expected-error@-1{{definition of dllimport static field not allowed}}
// expected-note@-2{{attribute is here}}
-__declspec(dllimport) constexpr int MemberRedecl::ConstexprField;  // expected-error{{redeclaration of 'MemberRedecl::ConstexprField' cannot add 'dllimport' attribute}}
-   // expected-error@-1{{definition of dllimport static field not allowed}}
-   // expected-note@-2{{attribute is here}}
+
+#if __cplusplus < 201703L && !defined(MS)
+// expected-error@+6{{redeclaration of 'MemberRedecl::ConstexprField' cannot add 'dllimport' attribute}}
+// expected-error@+5{{definition of dllimport 

[PATCH] D67422: [analyzer] NFC: Move path diagnostic consumer implementations to libAnalysis.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ created this revision.
NoQ added reviewers: dcoughlin, xazax.hun, a_sidorin, rnkovacs, Szelethus, 
baloghadamsoftware, Charusso, alexfh, gribozavr.
Herald added subscribers: cfe-commits, dkrupp, donat.nagy, mikhail.ramalho, 
a.sidorin, szepet.
Herald added a project: clang.
NoQ added a parent revision: D67421: [analyzer] NFC: Move IssueHash to 
libAnalysis..

We're finally more or less ready to allow users outside of the Static Analyzer 
to take advantage of path diagnostic consumers for emitting their warnings in 
different formats. I didn't really try to do that in practice, but most of the 
necessary APIs should be at least available now.

I'm not planning to convert Clang-Tidy to use these APIs directly because i 
understand that they're more complicated than Clang-Tidy really needs them to 
be. I'll either simplify these APIs (if they indeed can be simplified) or (more 
likely) introduce a convenient wrapper for easily building path diagnostics.

I'm not sure about renaming these classes to get rid of the "Path" prefix. 
These diagnostics aren't necessarily displaying the path (and they never did), 
but they're flexible enough for displaying paths and that's still the primary 
difference between our path diagnostics and ordinary diagnostics. Also if we 
just call them "Diagnostics" it'll be too generic and hard to distinguish from 
the Clang diagnostic engine. Suggestions are welcome :)


Repository:
  rC Clang

https://reviews.llvm.org/D67422

Files:
  clang/include/clang/Analysis/PathDiagnosticConsumers.def
  clang/include/clang/Analysis/PathDiagnosticConsumers.h
  clang/include/clang/StaticAnalyzer/Core/Analyses.def
  clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
  clang/include/clang/StaticAnalyzer/Core/PathDiagnosticConsumers.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
  clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
  clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
  clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp

Index: clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
===
--- clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
+++ clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
@@ -13,6 +13,7 @@
 #include "clang/StaticAnalyzer/Frontend/AnalysisConsumer.h"
 #include "ModelInjector.h"
 #include "clang/Analysis/PathDiagnostic.h"
+#include "clang/Analysis/PathDiagnosticConsumers.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/DeclCXX.h"
 #include "clang/AST/DeclObjC.h"
@@ -29,7 +30,6 @@
 #include "clang/StaticAnalyzer/Core/AnalyzerOptions.h"
 #include "clang/StaticAnalyzer/Core/BugReporter/BugReporter.h"
 #include "clang/StaticAnalyzer/Core/CheckerManager.h"
-#include "clang/StaticAnalyzer/Core/PathDiagnosticConsumers.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h"
 #include "clang/StaticAnalyzer/Frontend/CheckerRegistration.h"
@@ -277,7 +277,7 @@
   case PD_##NAME:  \
 CREATEFN(Opts->getDiagOpts(), PathConsumers, OutDir, PP, CTU); \
 break;
-#include "clang/StaticAnalyzer/Core/Analyses.def"
+#include "clang/Analysis/PathDiagnosticConsumers.def"
 }
   }
 }
Index: clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
===
--- clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
+++ clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
@@ -11,9 +11,9 @@
 //===--===//
 
 #include "clang/Analysis/PathDiagnostic.h"
+#include "clang/Analysis/PathDiagnosticConsumers.h"
 #include "clang/Basic/Version.h"
 #include "clang/Lex/Preprocessor.h"
-#include "clang/StaticAnalyzer/Core/PathDiagnosticConsumers.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringMap.h"
 #include "llvm/Support/JSON.h"
Index: clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
===
--- clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
+++ clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
@@ -12,6 +12,7 @@
 
 #include "clang/Analysis/IssueHash.h"
 #include "clang/Analysis/PathDiagnostic.h"
+#include "clang/Analysis/PathDiagnosticConsumers.h"
 #include "clang/Basic/FileManager.h"
 #include "clang/Basic/PlistSupport.h"
 #include "clang/Basic/SourceManager.h"
@@ -21,7 +22,6 @@
 #include "clang/Lex/Preprocessor.h"
 #include "clang/Lex/TokenConcatenation.h"
 #include "clang/Rewrite/Core/HTMLRewrite.h"
-#include "clang/StaticAnalyzer/Core/PathDiagnosticConsumers.h"
 #include "llvm/ADT/SmallPtrSet.h"
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/Statistic.h"
Index: clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp

[PATCH] D67421: [analyzer] NFC: Move IssueHash to libAnalysis.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ created this revision.
NoQ added reviewers: dcoughlin, xazax.hun, a_sidorin, rnkovacs, Szelethus, 
baloghadamsoftware, Charusso, alexfh, gribozavr.
Herald added subscribers: cfe-commits, dkrupp, donat.nagy, mikhail.ramalho, 
a.sidorin, szepet, mgorny.
Herald added a project: clang.

`IssueHash` is an attempt to introduce stable warning identifiers that won't 
change when code around them gets moved around. Path diagnostic consumers print 
issue hashes for the emitted diagnostics.

This move will allow us to ultimately move path diagnostic consumers to 
`libAnalysis`.


Repository:
  rC Clang

https://reviews.llvm.org/D67421

Files:
  clang/include/clang/Analysis/IssueHash.h
  clang/include/clang/StaticAnalyzer/Core/IssueHash.h
  clang/lib/Analysis/CMakeLists.txt
  clang/lib/Analysis/IssueHash.cpp
  clang/lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp
  clang/lib/StaticAnalyzer/Core/CMakeLists.txt
  clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
  clang/lib/StaticAnalyzer/Core/IssueHash.cpp
  clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp


Index: clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
===
--- clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
+++ clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
@@ -10,6 +10,7 @@
 //
 
//===--===//
 
+#include "clang/Analysis/IssueHash.h"
 #include "clang/Analysis/PathDiagnostic.h"
 #include "clang/Basic/FileManager.h"
 #include "clang/Basic/PlistSupport.h"
@@ -20,7 +21,6 @@
 #include "clang/Lex/Preprocessor.h"
 #include "clang/Lex/TokenConcatenation.h"
 #include "clang/Rewrite/Core/HTMLRewrite.h"
-#include "clang/StaticAnalyzer/Core/IssueHash.h"
 #include "clang/StaticAnalyzer/Core/PathDiagnosticConsumers.h"
 #include "llvm/ADT/SmallPtrSet.h"
 #include "llvm/ADT/SmallVector.h"
Index: clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
===
--- clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
+++ clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
@@ -10,6 +10,7 @@
 //
 
//===--===//
 
+#include "clang/Analysis/IssueHash.h"
 #include "clang/Analysis/PathDiagnostic.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/DeclBase.h"
@@ -23,7 +24,6 @@
 #include "clang/Lex/Token.h"
 #include "clang/Rewrite/Core/HTMLRewrite.h"
 #include "clang/Rewrite/Core/Rewriter.h"
-#include "clang/StaticAnalyzer/Core/IssueHash.h"
 #include "clang/StaticAnalyzer/Core/PathDiagnosticConsumers.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/SmallString.h"
Index: clang/lib/StaticAnalyzer/Core/CMakeLists.txt
===
--- clang/lib/StaticAnalyzer/Core/CMakeLists.txt
+++ clang/lib/StaticAnalyzer/Core/CMakeLists.txt
@@ -26,7 +26,6 @@
   ExprEngineObjC.cpp
   FunctionSummary.cpp
   HTMLDiagnostics.cpp
-  IssueHash.cpp
   LoopUnrolling.cpp
   LoopWidening.cpp
   MemRegion.cpp
Index: clang/lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/ExprInspectionChecker.cpp
@@ -6,11 +6,11 @@
 //
 
//===--===//
 
+#include "clang/Analysis/IssueHash.h"
 #include "clang/StaticAnalyzer/Checkers/BuiltinCheckerRegistration.h"
 #include "clang/StaticAnalyzer/Checkers/SValExplainer.h"
 #include "clang/StaticAnalyzer/Core/BugReporter/BugType.h"
 #include "clang/StaticAnalyzer/Core/Checker.h"
-#include "clang/StaticAnalyzer/Core/IssueHash.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/CheckerContext.h"
 #include "llvm/ADT/StringSwitch.h"
Index: clang/lib/Analysis/IssueHash.cpp
===
--- clang/lib/Analysis/IssueHash.cpp
+++ clang/lib/Analysis/IssueHash.cpp
@@ -5,7 +5,8 @@
 // SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 
//===--===//
-#include "clang/StaticAnalyzer/Core/IssueHash.h"
+
+#include "clang/Analysis/IssueHash.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/DeclCXX.h"
Index: clang/lib/Analysis/CMakeLists.txt
===
--- clang/lib/Analysis/CMakeLists.txt
+++ clang/lib/Analysis/CMakeLists.txt
@@ -16,6 +16,7 @@
   CodeInjector.cpp
   Dominators.cpp
   ExprMutationAnalyzer.cpp
+  IssueHash.cpp
   LiveVariables.cpp
   ObjCNoReturn.cpp
   PathDiagnostic.cpp


Index: clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
===
--- 

[PATCH] D67420: [analyzer] NFC: Separate PathDiagnosticConsumer options from AnalyzerOptions.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ created this revision.
NoQ added reviewers: dcoughlin, xazax.hun, a_sidorin, rnkovacs, Szelethus, 
baloghadamsoftware, Charusso.
Herald added subscribers: cfe-commits, dkrupp, donat.nagy, mikhail.ramalho, 
a.sidorin, szepet.
Herald added a project: clang.
NoQ added reviewers: alexfh, gribozavr.
NoQ added a parent revision: D67419: [analyzer] NFC: Move PathDiagnostic to 
libAnalysis..

The `AnalyzerOptions` object contains too much information that's completely 
specific to the Analyzer. It is also being referenced by path diagnostic 
consumers to tweak their behavior. If we want path diagnostic consumers to 
function separately from the Analyzer, we'll have to make a smaller options 
object that only contains relevant options.

@Szelethus: I could have stored `PathDiagnosticConsumerOptions` in 
`AnalyzerOptions` by value and pass a const reference around, but it wasn't 
pleasant to integrate with `AnalyzerOptions.def`. I.e., i'd have to implement a 
new kind of option that doesn't allocate its own field but instead re-uses a 
field within a sub-object. Do you want me to go for it or is this 
implementation good enough or do you have other approaches in mind?


Repository:
  rC Clang

https://reviews.llvm.org/D67420

Files:
  clang/include/clang/Analysis/PathDiagnostic.h
  clang/include/clang/StaticAnalyzer/Core/AnalyzerOptions.h
  clang/include/clang/StaticAnalyzer/Core/PathDiagnosticConsumers.h
  clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
  clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
  clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
  clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp

Index: clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
===
--- clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
+++ clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
@@ -65,16 +65,18 @@
 //===--===//
 
 void ento::createPlistHTMLDiagnosticConsumer(
-AnalyzerOptions , PathDiagnosticConsumers ,
+PathDiagnosticConsumerOptions &, PathDiagnosticConsumers ,
 const std::string , const Preprocessor ,
 const cross_tu::CrossTranslationUnitContext ) {
-  createHTMLDiagnosticConsumer(AnalyzerOpts, C,
+  // Duplicate the DiagOpts object into both consumers.
+  createHTMLDiagnosticConsumer(PathDiagnosticConsumerOptions(DiagOpts), C,
llvm::sys::path::parent_path(prefix), PP, CTU);
-  createPlistMultiFileDiagnosticConsumer(AnalyzerOpts, C, prefix, PP, CTU);
+  createPlistMultiFileDiagnosticConsumer(
+  PathDiagnosticConsumerOptions(DiagOpts), C, prefix, PP, CTU);
 }
 
 void ento::createTextPathDiagnosticConsumer(
-AnalyzerOptions , PathDiagnosticConsumers ,
+PathDiagnosticConsumerOptions &, PathDiagnosticConsumers ,
 const std::string , const clang::Preprocessor ,
 const cross_tu::CrossTranslationUnitContext ) {
   llvm_unreachable("'text' consumer should be enabled on ClangDiags");
@@ -273,7 +275,7 @@
 default:
 #define ANALYSIS_DIAGNOSTICS(NAME, CMDFLAG, DESC, CREATEFN)\
   case PD_##NAME:  \
-CREATEFN(*Opts.get(), PathConsumers, OutDir, PP, CTU); \
+CREATEFN(Opts->getDiagOpts(), PathConsumers, OutDir, PP, CTU); \
 break;
 #include "clang/StaticAnalyzer/Core/Analyses.def"
 }
Index: clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
===
--- clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
+++ clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
@@ -13,7 +13,6 @@
 #include "clang/Analysis/PathDiagnostic.h"
 #include "clang/Basic/Version.h"
 #include "clang/Lex/Preprocessor.h"
-#include "clang/StaticAnalyzer/Core/AnalyzerOptions.h"
 #include "clang/StaticAnalyzer/Core/PathDiagnosticConsumers.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringMap.h"
@@ -29,7 +28,7 @@
   std::string OutputFile;
 
 public:
-  SarifDiagnostics(AnalyzerOptions &, const std::string )
+  SarifDiagnostics(const std::string )
   : OutputFile(Output) {}
   ~SarifDiagnostics() override = default;
 
@@ -44,10 +43,10 @@
 } // end anonymous namespace
 
 void ento::createSarifDiagnosticConsumer(
-AnalyzerOptions , PathDiagnosticConsumers ,
+PathDiagnosticConsumerOptions &, PathDiagnosticConsumers ,
 const std::string , const Preprocessor &,
 const cross_tu::CrossTranslationUnitContext &) {
-  C.push_back(new SarifDiagnostics(AnalyzerOpts, Output));
+  C.push_back(new SarifDiagnostics(Output));
 }
 
 static StringRef getFileName(const FileEntry ) {
Index: clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
===
--- clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
+++ clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
@@ -20,7 +20,6 @@
 

[PATCH] D67419: [analyzer] NFC: Move PathDiagnostic to libAnalysis.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ created this revision.
NoQ added reviewers: dcoughlin, xazax.hun, a_sidorin, rnkovacs, Szelethus, 
baloghadamsoftware, Charusso, alexfh, gribozavr.
Herald added subscribers: cfe-commits, dkrupp, donat.nagy, mikhail.ramalho, 
a.sidorin, szepet, mgorny.
Herald added a project: clang.
NoQ added a parent revision: D67418: [analyzer] NFC: Move 
PathDiagnostic::resetDiagnosticLocationToMainFile to bug reporter..

At this point `PathDiagnostic`, `PathDiagnosticLocation`, `PathDiagnosticPiece` 
structures no longer rely on anything specific to Static Analyzer, so we can 
move them out for everybody to use.

It's not the point where I'm happy with the API that i'm exposing this way; 
it's just the point where i expose it "because i can", i.e. the technical 
difficulties have been sorted out and a relatively clear separation between 
aspects of the API that are specific to the Analyzer and the aspects that 
aren't necessarily specific to the Analyzer has been achieved.

`PathDiagnosticConsumer`s are still to be handed off.


Repository:
  rC Clang

https://reviews.llvm.org/D67419

Files:
  clang-tools-extra/clang-tidy/ClangTidy.cpp
  clang/include/clang/Analysis/PathDiagnostic.h
  clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
  clang/include/clang/StaticAnalyzer/Core/BugReporter/PathDiagnostic.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h
  clang/lib/Analysis/CMakeLists.txt
  clang/lib/Analysis/PathDiagnostic.cpp
  clang/lib/StaticAnalyzer/Checkers/CheckObjCDealloc.cpp
  clang/lib/StaticAnalyzer/Checkers/CheckObjCInstMethSignature.cpp
  clang/lib/StaticAnalyzer/Checkers/ObjCMissingSuperCallChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/ObjCUnusedIVarsChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/RetainCountChecker/RetainCountChecker.h
  clang/lib/StaticAnalyzer/Checkers/RetainCountChecker/RetainCountDiagnostics.h
  clang/lib/StaticAnalyzer/Core/BugReporter.cpp
  clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
  clang/lib/StaticAnalyzer/Core/CMakeLists.txt
  clang/lib/StaticAnalyzer/Core/CallEvent.cpp
  clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp
  clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
  clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
  clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
  clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp

Index: clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
===
--- clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
+++ clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp
@@ -12,6 +12,7 @@
 
 #include "clang/StaticAnalyzer/Frontend/AnalysisConsumer.h"
 #include "ModelInjector.h"
+#include "clang/Analysis/PathDiagnostic.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/DeclCXX.h"
 #include "clang/AST/DeclObjC.h"
@@ -27,7 +28,6 @@
 #include "clang/StaticAnalyzer/Checkers/LocalCheckers.h"
 #include "clang/StaticAnalyzer/Core/AnalyzerOptions.h"
 #include "clang/StaticAnalyzer/Core/BugReporter/BugReporter.h"
-#include "clang/StaticAnalyzer/Core/BugReporter/PathDiagnostic.h"
 #include "clang/StaticAnalyzer/Core/CheckerManager.h"
 #include "clang/StaticAnalyzer/Core/PathDiagnosticConsumers.h"
 #include "clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h"
Index: clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
===
--- clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
+++ clang/lib/StaticAnalyzer/Core/SarifDiagnostics.cpp
@@ -10,10 +10,10 @@
 //
 //===--===//
 
+#include "clang/Analysis/PathDiagnostic.h"
 #include "clang/Basic/Version.h"
 #include "clang/Lex/Preprocessor.h"
 #include "clang/StaticAnalyzer/Core/AnalyzerOptions.h"
-#include "clang/StaticAnalyzer/Core/BugReporter/PathDiagnostic.h"
 #include "clang/StaticAnalyzer/Core/PathDiagnosticConsumers.h"
 #include "llvm/ADT/STLExtras.h"
 #include "llvm/ADT/StringMap.h"
Index: clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
===
--- clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
+++ clang/lib/StaticAnalyzer/Core/PlistDiagnostics.cpp
@@ -10,6 +10,7 @@
 //
 //===--===//
 
+#include "clang/Analysis/PathDiagnostic.h"
 #include "clang/Basic/FileManager.h"
 #include "clang/Basic/PlistSupport.h"
 #include "clang/Basic/SourceManager.h"
@@ -20,7 +21,6 @@
 #include "clang/Lex/TokenConcatenation.h"
 #include "clang/Rewrite/Core/HTMLRewrite.h"
 #include "clang/StaticAnalyzer/Core/AnalyzerOptions.h"
-#include "clang/StaticAnalyzer/Core/BugReporter/PathDiagnostic.h"
 #include "clang/StaticAnalyzer/Core/IssueHash.h"
 #include "clang/StaticAnalyzer/Core/PathDiagnosticConsumers.h"
 #include "llvm/ADT/SmallPtrSet.h"
Index: clang/lib/StaticAnalyzer/Core/HTMLDiagnostics.cpp

[PATCH] D67419: [analyzer] NFC: Move PathDiagnostic to libAnalysis.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ marked an inline comment as done.
NoQ added inline comments.



Comment at: clang-tools-extra/clang-tidy/ClangTidy.cpp:26
 #include "clang/ASTMatchers/ASTMatchFinder.h"
-#include "clang/Config/config.h"
 #include "clang/Format/Format.h"

This needed to go up because that's where `CLANG_ENABLE_STATIC_ANALYZER` is 
defined.


Repository:
  rC Clang

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

https://reviews.llvm.org/D67419



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

[PATCH] D67304: Emit -Wmicrosoft-enum-value warning instead of error in MS ABI

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

In D67304#1664696 , @thakis wrote:

> We have the old TODO of changing this warning to be emitted at enum use time 
> (e.g. when Foo_Val is compared to 0) instead of declaration time. Maybe 
> that's a better fix. Or is implementing that very involved?


I guess it would depend on the logic of the point-of-use warning. We could make 
it very simple. We could:

- mark all enum types with coerced enumerators (maybe we already know this)
- warn on all ordering comparisons that use that enum type

If the user explicitly casts to any other integer type to do the comparison, we 
can expect them to know the rules.

I think it can't allow false negatives, though. -Wmicrosoft is kind of like our 
-pedantic mode for standard C. It basically says, if your code is -Wmicrosoft 
clean, we promise that it is not relying on Microsoft-specific behavior. The 
simplest way to do that is to soften the existing error to a warning, which is 
what this does.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67304



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

[PATCH] D67418: [analyzer] NFC: Move PathDiagnostic::resetDiagnosticLocationToMainFile to bug reporter.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ created this revision.
NoQ added reviewers: dcoughlin, xazax.hun, a_sidorin, rnkovacs, Szelethus, 
baloghadamsoftware, Charusso.
Herald added subscribers: cfe-commits, dkrupp, donat.nagy, mikhail.ramalho, 
a.sidorin, szepet.
Herald added a project: clang.
NoQ added a parent revision: D67382: [analyzer] NFC: Move getStmt() and 
createEndOfPath() out of PathDiagnostic..

This function uses `AnalysisManager`, which is Static Analyzer-specific entity, 
but i want path diagnostics to be independent of the Static Analyzer.

In fact it only uses `AnalysisManager::isInCodeFile()` which is essentially 
static and might be useful outside of the Analyzer; however, Clang-Tidy has its 
own idea of what code to analyze, so i feel i can't enforce this method on them.

More importantly, though, i'm only handing off the PathDiagnostic data 
structure, but not the procedure of constructing those particularly neat 
analyzer-like path diagnostics. And this whole function is definitely part of 
the construction procedure, not of the data structure itself, so it shouldn't 
be handed off.


Repository:
  rC Clang

https://reviews.llvm.org/D67418

Files:
  clang/include/clang/StaticAnalyzer/Core/BugReporter/PathDiagnostic.h
  clang/lib/StaticAnalyzer/Core/BugReporter.cpp
  clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp

Index: clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
===
--- clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
+++ clang/lib/StaticAnalyzer/Core/PathDiagnostic.cpp
@@ -29,7 +29,6 @@
 #include "clang/Basic/LLVM.h"
 #include "clang/Basic/SourceLocation.h"
 #include "clang/Basic/SourceManager.h"
-#include "clang/StaticAnalyzer/Core/PathSensitive/AnalysisManager.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/FoldingSet.h"
 #include "llvm/ADT/None.h"
@@ -130,69 +129,6 @@
   UniqueingDecl(DeclToUnique), ExecutedLines(std::move(ExecutedLines)),
   path(pathImpl) {}
 
-static PathDiagnosticCallPiece *
-getFirstStackedCallToHeaderFile(PathDiagnosticCallPiece *CP,
-const SourceManager ) {
-  SourceLocation CallLoc = CP->callEnter.asLocation();
-
-  // If the call is within a macro, don't do anything (for now).
-  if (CallLoc.isMacroID())
-return nullptr;
-
-  assert(AnalysisManager::isInCodeFile(CallLoc, SMgr) &&
- "The call piece should not be in a header file.");
-
-  // Check if CP represents a path through a function outside of the main file.
-  if (!AnalysisManager::isInCodeFile(CP->callEnterWithin.asLocation(), SMgr))
-return CP;
-
-  const PathPieces  = CP->path;
-  if (Path.empty())
-return nullptr;
-
-  // Check if the last piece in the callee path is a call to a function outside
-  // of the main file.
-  if (auto *CPInner = dyn_cast(Path.back().get()))
-return getFirstStackedCallToHeaderFile(CPInner, SMgr);
-
-  // Otherwise, the last piece is in the main file.
-  return nullptr;
-}
-
-void PathDiagnostic::resetDiagnosticLocationToMainFile() {
-  if (path.empty())
-return;
-
-  PathDiagnosticPiece *LastP = path.back().get();
-  assert(LastP);
-  const SourceManager  = LastP->getLocation().getManager();
-
-  // We only need to check if the report ends inside headers, if the last piece
-  // is a call piece.
-  if (auto *CP = dyn_cast(LastP)) {
-CP = getFirstStackedCallToHeaderFile(CP, SMgr);
-if (CP) {
-  // Mark the piece.
-   CP->setAsLastInMainSourceFile();
-
-  // Update the path diagnostic message.
-  const auto *ND = dyn_cast(CP->getCallee());
-  if (ND) {
-SmallString<200> buf;
-llvm::raw_svector_ostream os(buf);
-os << " (within a call to '" << ND->getDeclName() << "')";
-appendToDesc(os.str());
-  }
-
-  // Reset the report containing declaration and location.
-  DeclWithIssue = CP->getCaller();
-  Loc = CP->getLocation();
-
-  return;
-}
-  }
-}
-
 void PathDiagnosticConsumer::anchor() {}
 
 PathDiagnosticConsumer::~PathDiagnosticConsumer() {
Index: clang/lib/StaticAnalyzer/Core/BugReporter.cpp
===
--- clang/lib/StaticAnalyzer/Core/BugReporter.cpp
+++ clang/lib/StaticAnalyzer/Core/BugReporter.cpp
@@ -3130,6 +3130,71 @@
   return Out;
 }
 
+static PathDiagnosticCallPiece *
+getFirstStackedCallToHeaderFile(PathDiagnosticCallPiece *CP,
+const SourceManager ) {
+  SourceLocation CallLoc = CP->callEnter.asLocation();
+
+  // If the call is within a macro, don't do anything (for now).
+  if (CallLoc.isMacroID())
+return nullptr;
+
+  assert(AnalysisManager::isInCodeFile(CallLoc, SMgr) &&
+ "The call piece should not be in a header file.");
+
+  // Check if CP represents a path through a function outside of the main file.
+  if (!AnalysisManager::isInCodeFile(CP->callEnterWithin.asLocation(), SMgr))
+return CP;
+
+  const PathPieces  = CP->path;
+  if (Path.empty())
+

[PATCH] D67395: [clang-format] Apply BAS_AlwaysBreak to C++11 braced lists

[Owen Pan via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL371571: [clang-format] Apply BAS_AlwaysBreak to C++11 braced 
lists (authored by owenpan, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67395?vs=219528=219626#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67395

Files:
  cfe/trunk/lib/Format/ContinuationIndenter.cpp
  cfe/trunk/unittests/Format/FormatTest.cpp


Index: cfe/trunk/unittests/Format/FormatTest.cpp
===
--- cfe/trunk/unittests/Format/FormatTest.cpp
+++ cfe/trunk/unittests/Format/FormatTest.cpp
@@ -7835,6 +7835,16 @@
   "};",
   NoBinPacking);
 
+  NoBinPacking.AlignAfterOpenBracket = FormatStyle::BAS_AlwaysBreak;
+  EXPECT_EQ("static uint8 CddDp83848Reg[] = {\n"
+"CDDDP83848_BMCR_REGISTER,\n"
+"CDDDP83848_BMSR_REGISTER,\n"
+"CDDDP83848_RBR_REGISTER};",
+format("static uint8 CddDp83848Reg[] = 
{CDDDP83848_BMCR_REGISTER,\n"
+   "
CDDDP83848_BMSR_REGISTER,\n"
+   "CDDDP83848_RBR_REGISTER};",
+   NoBinPacking));
+
   // FIXME: The alignment of these trailing comments might be bad. Then again,
   // this might be utterly useless in real code.
   verifyFormat("Constructor::Constructor()\n"
Index: cfe/trunk/lib/Format/ContinuationIndenter.cpp
===
--- cfe/trunk/lib/Format/ContinuationIndenter.cpp
+++ cfe/trunk/lib/Format/ContinuationIndenter.cpp
@@ -606,7 +606,9 @@
   // disallowing any further line breaks if there is no line break after the
   // opening parenthesis. Don't break if it doesn't conserve columns.
   if (Style.AlignAfterOpenBracket == FormatStyle::BAS_AlwaysBreak &&
-  Previous.isOneOf(tok::l_paren, TT_TemplateOpener, tok::l_square) &&
+  (Previous.isOneOf(tok::l_paren, TT_TemplateOpener, tok::l_square) ||
+   (Previous.is(tok::l_brace) && Previous.BlockKind != BK_Block &&
+Style.Cpp11BracedListStyle)) &&
   State.Column > getNewLineColumn(State) &&
   (!Previous.Previous || !Previous.Previous->isOneOf(
  tok::kw_for, tok::kw_while, tok::kw_switch)) 
&&


Index: cfe/trunk/unittests/Format/FormatTest.cpp
===
--- cfe/trunk/unittests/Format/FormatTest.cpp
+++ cfe/trunk/unittests/Format/FormatTest.cpp
@@ -7835,6 +7835,16 @@
   "};",
   NoBinPacking);
 
+  NoBinPacking.AlignAfterOpenBracket = FormatStyle::BAS_AlwaysBreak;
+  EXPECT_EQ("static uint8 CddDp83848Reg[] = {\n"
+"CDDDP83848_BMCR_REGISTER,\n"
+"CDDDP83848_BMSR_REGISTER,\n"
+"CDDDP83848_RBR_REGISTER};",
+format("static uint8 CddDp83848Reg[] = {CDDDP83848_BMCR_REGISTER,\n"
+   "CDDDP83848_BMSR_REGISTER,\n"
+   "CDDDP83848_RBR_REGISTER};",
+   NoBinPacking));
+
   // FIXME: The alignment of these trailing comments might be bad. Then again,
   // this might be utterly useless in real code.
   verifyFormat("Constructor::Constructor()\n"
Index: cfe/trunk/lib/Format/ContinuationIndenter.cpp
===
--- cfe/trunk/lib/Format/ContinuationIndenter.cpp
+++ cfe/trunk/lib/Format/ContinuationIndenter.cpp
@@ -606,7 +606,9 @@
   // disallowing any further line breaks if there is no line break after the
   // opening parenthesis. Don't break if it doesn't conserve columns.
   if (Style.AlignAfterOpenBracket == FormatStyle::BAS_AlwaysBreak &&
-  Previous.isOneOf(tok::l_paren, TT_TemplateOpener, tok::l_square) &&
+  (Previous.isOneOf(tok::l_paren, TT_TemplateOpener, tok::l_square) ||
+   (Previous.is(tok::l_brace) && Previous.BlockKind != BK_Block &&
+Style.Cpp11BracedListStyle)) &&
   State.Column > getNewLineColumn(State) &&
   (!Previous.Previous || !Previous.Previous->isOneOf(
  tok::kw_for, tok::kw_while, tok::kw_switch)) &&
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r371571 - [clang-format] Apply BAS_AlwaysBreak to C++11 braced lists

[Owen Pan via cfe-commits]

Author: owenpan
Date: Tue Sep 10 16:26:45 2019
New Revision: 371571

URL: http://llvm.org/viewvc/llvm-project?rev=371571=rev
Log:
[clang-format] Apply BAS_AlwaysBreak to C++11 braced lists

See PR18455.

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

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=371571=371570=371571=diff
==
--- cfe/trunk/lib/Format/ContinuationIndenter.cpp (original)
+++ cfe/trunk/lib/Format/ContinuationIndenter.cpp Tue Sep 10 16:26:45 2019
@@ -606,7 +606,9 @@ void ContinuationIndenter::addTokenOnCur
   // disallowing any further line breaks if there is no line break after the
   // opening parenthesis. Don't break if it doesn't conserve columns.
   if (Style.AlignAfterOpenBracket == FormatStyle::BAS_AlwaysBreak &&
-  Previous.isOneOf(tok::l_paren, TT_TemplateOpener, tok::l_square) &&
+  (Previous.isOneOf(tok::l_paren, TT_TemplateOpener, tok::l_square) ||
+   (Previous.is(tok::l_brace) && Previous.BlockKind != BK_Block &&
+Style.Cpp11BracedListStyle)) &&
   State.Column > getNewLineColumn(State) &&
   (!Previous.Previous || !Previous.Previous->isOneOf(
  tok::kw_for, tok::kw_while, tok::kw_switch)) 
&&

Modified: cfe/trunk/unittests/Format/FormatTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/FormatTest.cpp?rev=371571=371570=371571=diff
==
--- cfe/trunk/unittests/Format/FormatTest.cpp (original)
+++ cfe/trunk/unittests/Format/FormatTest.cpp Tue Sep 10 16:26:45 2019
@@ -7835,6 +7835,16 @@ TEST_F(FormatTest, LayoutCxx11BraceIniti
   "};",
   NoBinPacking);
 
+  NoBinPacking.AlignAfterOpenBracket = FormatStyle::BAS_AlwaysBreak;
+  EXPECT_EQ("static uint8 CddDp83848Reg[] = {\n"
+"CDDDP83848_BMCR_REGISTER,\n"
+"CDDDP83848_BMSR_REGISTER,\n"
+"CDDDP83848_RBR_REGISTER};",
+format("static uint8 CddDp83848Reg[] = 
{CDDDP83848_BMCR_REGISTER,\n"
+   "
CDDDP83848_BMSR_REGISTER,\n"
+   "CDDDP83848_RBR_REGISTER};",
+   NoBinPacking));
+
   // FIXME: The alignment of these trailing comments might be bad. Then again,
   // this might be utterly useless in real code.
   verifyFormat("Constructor::Constructor()\n"


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

[PATCH] D66121: Debug Info: Nest Objective-C property function decls inside their container.

[Adrian Prantl via Phabricator via cfe-commits]

aprantl added a comment.

In D66121#1656442 , @rjmccall wrote:

> Can you prepare an NFC patch with just the changes relating to adding 
> `ObjCPropertyImplDecl::get{Getter,Setter}MethodDecl`?


Sure, I will do that.

> I don't get why the redeclaration logic is changing.  What happens when a 
> normal method is implemented?  Is that not linked up as a redeclaration?

From what I can tell from injecting an assertion into 
`ObjCMethodDecl::setAsRedeclaration()` only redeclarations within the same 
protocol/interface/category are linked up as redeclarations. An implementation 
of an interface is not a redeclaration in the SemaObjC sense. Digging further, 
this is implemented in 
https://github.com/llvm/llvm-project/blob/244e738485445fa4b72bfef9b9b2f9625cee989e/clang/lib/Sema/SemaDeclObjC.cpp#L3930
 by checking whether a method's selector has been processed before within the 
same property/interface/category.

That's very different from what my patch is doing. The following example is 
extracted from `clang/test/CodeGenObjC/newproperty-nested-synthesis-1.m`:

   1@interface Tester : Object
   2@property char PropertyAtomic_char;
   3@end
   4
   5@implementation Tester
   6@dynamic PropertyAtomic_char;
   7@end
   8
   9@interface SubClass : Tester
  10{
  11char PropertyAtomic_char;
  12}
  13@end
  14
  15@implementation SubClass
  16@synthesize PropertyAtomic_char;
  17@end

My patch sets the getter synthesized at line 6 up as a redeclaration of getter 
from the interface on line 2 and the getter from `SubClass` on line 16 as a 
redeclaration of the getter from `Tester` on line 6. That must be wrong: If 
there were another subclass of `Tester` with another getter, the compiler would 
assert, because each Objective-C method declaration can have at most one 
redeclaration.

So in summary I think what I was trying to do doesn't make sense in the 
existing infrastructure and I shouldn't be trying to set up methods as 
redeclarations between *different* interfaces/protocols/implementations. Do you 
agree with this assessment? If yes I'll try to redo the patch without using the 
redeclaration mechanism.


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

https://reviews.llvm.org/D66121



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

r371568 - Reland "Change the X86 datalayout to add three address spaces

[Amy Huang via cfe-commits]

Author: akhuang
Date: Tue Sep 10 16:15:38 2019
New Revision: 371568

URL: http://llvm.org/viewvc/llvm-project?rev=371568=rev
Log:
Reland "Change the X86 datalayout to add three address spaces
 for 32 bit signed, 32 bit unsigned, and 64 bit pointers."
This reverts 57076d3199fc2b0af4a3736b7749dd5462cacda5.

Original review at https://reviews.llvm.org/D64931.
Review for added fix at https://reviews.llvm.org/D66843.

Modified:
cfe/trunk/lib/Basic/Targets/OSTargets.h
cfe/trunk/lib/Basic/Targets/X86.h
cfe/trunk/test/CodeGen/Inputs/thinlto-multi-module.ll
cfe/trunk/test/CodeGen/Inputs/thinlto_backend.ll
cfe/trunk/test/CodeGen/Inputs/thinlto_backend_local_name_conflict1.ll
cfe/trunk/test/CodeGen/Inputs/thinlto_backend_local_name_conflict2.ll
cfe/trunk/test/CodeGen/iamcu-abi.c
cfe/trunk/test/CodeGen/target-data.c
cfe/trunk/test/CodeGen/thinlto-diagnostic-handler-remarks-with-hotness.ll
cfe/trunk/test/CodeGen/thinlto-distributed-backend-skip.ll
cfe/trunk/test/CodeGen/thinlto-distributed-cfi-devirt.ll
cfe/trunk/test/CodeGen/thinlto-distributed-cfi.ll
cfe/trunk/test/CodeGen/thinlto-distributed.ll
cfe/trunk/test/CodeGen/thinlto-multi-module.ll
cfe/trunk/test/CodeGen/thinlto_backend.ll
cfe/trunk/test/CodeGen/thinlto_backend_local_name_conflict.ll

Modified: cfe/trunk/lib/Basic/Targets/OSTargets.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/OSTargets.h?rev=371568=371567=371568=diff
==
--- cfe/trunk/lib/Basic/Targets/OSTargets.h (original)
+++ cfe/trunk/lib/Basic/Targets/OSTargets.h Tue Sep 10 16:15:38 2019
@@ -775,9 +775,11 @@ public:
 if (Triple.getArch() == llvm::Triple::arm) {
   // Handled in ARM's setABI().
 } else if (Triple.getArch() == llvm::Triple::x86) {
-  this->resetDataLayout("e-m:e-p:32:32-i64:64-n8:16:32-S128");
+  this->resetDataLayout("e-m:e-p:32:32-p270:32:32-p271:32:32-p272:64:64-"
+"i64:64-n8:16:32-S128");
 } else if (Triple.getArch() == llvm::Triple::x86_64) {
-  this->resetDataLayout("e-m:e-p:32:32-i64:64-n8:16:32:64-S128");
+  this->resetDataLayout("e-m:e-p:32:32-p270:32:32-p271:32:32-p272:64:64-"
+"i64:64-n8:16:32:64-S128");
 } else if (Triple.getArch() == llvm::Triple::mipsel) {
   // Handled on mips' setDataLayout.
 } else {

Modified: cfe/trunk/lib/Basic/Targets/X86.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/X86.h?rev=371568=371567=371568=diff
==
--- cfe/trunk/lib/Basic/Targets/X86.h (original)
+++ cfe/trunk/lib/Basic/Targets/X86.h Tue Sep 10 16:15:38 2019
@@ -339,7 +339,8 @@ public:
 LongDoubleWidth = 96;
 LongDoubleAlign = 32;
 SuitableAlign = 128;
-resetDataLayout("e-m:e-p:32:32-f64:32:64-f80:32-n8:16:32-S128");
+resetDataLayout("e-m:e-p:32:32-p270:32:32-p271:32:32-p272:64:64-f64:32:64-"
+"f80:32-n8:16:32-S128");
 SizeType = UnsignedInt;
 PtrDiffType = SignedInt;
 IntPtrType = SignedInt;
@@ -439,7 +440,8 @@ public:
   UseSignedCharForObjCBool = false;
 SizeType = UnsignedLong;
 IntPtrType = SignedLong;
-resetDataLayout("e-m:o-p:32:32-f64:32:64-f80:128-n8:16:32-S128");
+resetDataLayout("e-m:o-p:32:32-p270:32:32-p271:32:32-p272:64:64-f64:32:64-"
+"f80:128-n8:16:32-S128");
 HasAlignMac68kSupport = true;
   }
 
@@ -464,9 +466,10 @@ public:
 DoubleAlign = LongLongAlign = 64;
 bool IsWinCOFF =
 getTriple().isOSWindows() && getTriple().isOSBinFormatCOFF();
-resetDataLayout(IsWinCOFF
-? "e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32"
-: "e-m:e-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32");
+resetDataLayout(IsWinCOFF ? "e-m:x-p:32:32-p270:32:32-p271:32:32-p272:64:"
+"64-i64:64-f80:32-n8:16:32-a:0:32-S32"
+  : "e-m:e-p:32:32-p270:32:32-p271:32:32-p272:64:"
+"64-i64:64-f80:32-n8:16:32-a:0:32-S32");
   }
 };
 
@@ -514,7 +517,8 @@ public:
   : X86_32TargetInfo(Triple, Opts) {
 this->WCharType = TargetInfo::UnsignedShort;
 DoubleAlign = LongLongAlign = 64;
-resetDataLayout("e-m:x-p:32:32-i64:64-f80:32-n8:16:32-a:0:32-S32");
+
resetDataLayout("e-m:x-p:32:32-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:"
+"32-n8:16:32-a:0:32-S32");
   }
 
   void getTargetDefines(const LangOptions ,
@@ -551,7 +555,8 @@ public:
   : X86_32TargetInfo(Triple, Opts) {
 LongDoubleWidth = 64;
 LongDoubleFormat = ::APFloat::IEEEdouble();
-resetDataLayout("e-m:e-p:32:32-i64:32-f64:32-f128:32-n8:16:32-a:0:32-S32");
+
resetDataLayout("e-m:e-p:32:32-p270:32:32-p271:32:32-p272:64:64-i64:32-f64:"
+"32-f128:32-n8:16:32-a:0:32-S32");
 

[PATCH] D66324: clang-misexpect: Profile Guided Validation of Performance Annotations in LLVM

[Paul Kirth via Phabricator via cfe-commits]

paulkirth updated this revision to Diff 219617.
paulkirth added a comment.

Add a new profdata file to use w/ misexpect-nonconst-switch.c

ASAN exposed an issue where a function may hash the same even if the number of 
counters is different. This means that when a PGO profile is read in, it is 
possible for an out of bounds write to occur due to a mismatch in the number of 
statements that require profile counters, and the number of counters 
initialized from the profile that was read in.

This change should allow the misexpect patch to reland w/o issue.


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

https://reviews.llvm.org/D66324

Files:
  clang/include/clang/Basic/DiagnosticFrontendKinds.td
  clang/include/clang/Basic/DiagnosticGroups.td
  clang/lib/CodeGen/CodeGenAction.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Profile/Inputs/misexpect-branch-nonconst-expect-arg.proftext
  clang/test/Profile/Inputs/misexpect-branch.proftext
  clang/test/Profile/Inputs/misexpect-switch-default-only.proftext
  clang/test/Profile/Inputs/misexpect-switch-default.proftext
  clang/test/Profile/Inputs/misexpect-switch-nonconst.proftext
  clang/test/Profile/Inputs/misexpect-switch.proftext
  clang/test/Profile/misexpect-branch-cold.c
  clang/test/Profile/misexpect-branch-nonconst-expected-val.c
  clang/test/Profile/misexpect-branch-unpredictable.c
  clang/test/Profile/misexpect-branch.c
  clang/test/Profile/misexpect-switch-default.c
  clang/test/Profile/misexpect-switch-nonconst.c
  clang/test/Profile/misexpect-switch-only-default-case.c
  clang/test/Profile/misexpect-switch.c
  llvm/include/llvm/IR/DiagnosticInfo.h
  llvm/include/llvm/IR/FixedMetadataKinds.def
  llvm/include/llvm/IR/MDBuilder.h
  llvm/include/llvm/Transforms/Utils/MisExpect.h
  llvm/lib/IR/DiagnosticInfo.cpp
  llvm/lib/IR/MDBuilder.cpp
  llvm/lib/Transforms/IPO/SampleProfile.cpp
  llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
  llvm/lib/Transforms/Scalar/LowerExpectIntrinsic.cpp
  llvm/lib/Transforms/Utils/CMakeLists.txt
  llvm/lib/Transforms/Utils/MisExpect.cpp
  llvm/test/ThinLTO/X86/lazyload_metadata.ll
  llvm/test/Transforms/LowerExpectIntrinsic/basic.ll
  llvm/test/Transforms/PGOProfile/Inputs/misexpect-branch-correct.proftext
  llvm/test/Transforms/PGOProfile/Inputs/misexpect-branch.proftext
  llvm/test/Transforms/PGOProfile/Inputs/misexpect-switch-correct.proftext
  llvm/test/Transforms/PGOProfile/Inputs/misexpect-switch.proftext
  llvm/test/Transforms/PGOProfile/misexpect-branch-correct.ll
  llvm/test/Transforms/PGOProfile/misexpect-branch-stripped.ll
  llvm/test/Transforms/PGOProfile/misexpect-branch-unpredictable.ll
  llvm/test/Transforms/PGOProfile/misexpect-branch.ll
  llvm/test/Transforms/PGOProfile/misexpect-switch-default.ll
  llvm/test/Transforms/PGOProfile/misexpect-switch.ll

Index: llvm/test/Transforms/PGOProfile/misexpect-switch.ll
===
--- /dev/null
+++ llvm/test/Transforms/PGOProfile/misexpect-switch.ll
@@ -0,0 +1,293 @@
+
+; RUN: llvm-profdata merge %S/Inputs/misexpect-switch.proftext -o %t.profdata
+; RUN: llvm-profdata merge %S/Inputs/misexpect-switch-correct.proftext -o %t.c.profdata
+
+; RUN: opt < %s -lower-expect -pgo-instr-use -pgo-test-profile-file=%t.profdata -S -pgo-warn-misexpect 2>&1 | FileCheck %s --check-prefix=WARNING
+; RUN: opt < %s -lower-expect -pgo-instr-use -pgo-test-profile-file=%t.profdata -S -pass-remarks=misexpect 2>&1 | FileCheck %s --check-prefix=REMARK
+; RUN: opt < %s -lower-expect -pgo-instr-use -pgo-test-profile-file=%t.profdata -S -pgo-warn-misexpect -pass-remarks=misexpect 2>&1 | FileCheck %s --check-prefix=BOTH
+; RUN: opt < %s -lower-expect -pgo-instr-use -pgo-test-profile-file=%t.profdata -S 2>&1 | FileCheck %s --check-prefix=DISABLED
+
+; New PM
+; RUN: opt < %s -passes="function(lower-expect),pgo-instr-use" -pgo-test-profile-file=%t.profdata -pgo-warn-misexpect -S 2>&1 | FileCheck %s --check-prefix=WARNING
+; RUN: opt < %s -passes="function(lower-expect),pgo-instr-use" -pgo-test-profile-file=%t.profdata -pass-remarks=misexpect -S 2>&1 | FileCheck %s --check-prefix=REMARK
+; RUN: opt < %s -passes="function(lower-expect),pgo-instr-use" -pgo-test-profile-file=%t.profdata -pgo-warn-misexpect -pass-remarks=misexpect -S 2>&1 | FileCheck %s --check-prefix=BOTH
+; RUN: opt < %s -passes="function(lower-expect),pgo-instr-use" -pgo-test-profile-file=%t.profdata -S 2>&1 | FileCheck %s --check-prefix=DISABLED
+
+; RUN: opt < %s -lower-expect -pgo-instr-use -pgo-test-profile-file=%t.c.profdata -S -pgo-warn-misexpect -pass-remarks=misexpect 2>&1 | FileCheck %s --check-prefix=CORRECT
+; RUN: opt < %s -passes="function(lower-expect),pgo-instr-use" -pgo-test-profile-file=%t.c.profdata -pgo-warn-misexpect -pass-remarks=misexpect -S 2>&1 | FileCheck %s --check-prefix=CORRECT
+
+; WARNING-DAG: warning: misexpect-switch.c:26:5: 0.00%
+; WARNING-NOT: remark: misexpect-switch.c:26:5: Potential performance 

[PATCH] D64146: [Clang Interpreter] Initial patch for the constexpr interpreter

[Simon Pilgrim via Phabricator via cfe-commits]

RKSimon added a comment.

In D64146#1665003 , @nand wrote:

> Totally missed that - thanks for noticing. I must have forgotten to remove 
> stuff from the header since clang/gcc don't warn about it.
>  I'll get hold of a Windows machine soon-ish and I'll make sure to fix this 
> problem.
>  Thanks!


If you remove those 3 declarations from the headers and update the patch I can 
test it on my windows machines for you.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64146



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

r371559 - Actually reorder not and env in crash-recovery-modules.m

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Tue Sep 10 14:54:16 2019
New Revision: 371559

URL: http://llvm.org/viewvc/llvm-project?rev=371559=rev
Log:
Actually reorder not and env in crash-recovery-modules.m

Modified:
cfe/trunk/test/Index/crash-recovery-modules.m

Modified: cfe/trunk/test/Index/crash-recovery-modules.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Index/crash-recovery-modules.m?rev=371559=371558=371559=diff
==
--- cfe/trunk/test/Index/crash-recovery-modules.m (original)
+++ cfe/trunk/test/Index/crash-recovery-modules.m Tue Sep 10 14:54:16 2019
@@ -26,10 +26,10 @@ void test() {
 
 // RUN: rm -rf %t
 // Check that libclang crash-recovery works; both with a module building 
crash...
-// RUN: not env CINDEXTEST_FAILONERROR=1 c-index-test -test-load-source all 
-fmodules -fmodules-cache-path=%t -Xclang -fdisable-module-hash -I 
%S/Inputs/Headers -DCRASH -DLIBCLANG_CRASH %s > /dev/null 2> %t.err
+// RUN: env CINDEXTEST_FAILONERROR=1 not c-index-test -test-load-source all 
-fmodules -fmodules-cache-path=%t -Xclang -fdisable-module-hash -I 
%S/Inputs/Headers -DCRASH -DLIBCLANG_CRASH %s > /dev/null 2> %t.err
 // RUN: FileCheck < %t.err -check-prefix=CHECK-LIBCLANG-CRASH %s
 // ...and with module building successful.
-// RUN: not env CINDEXTEST_FAILONERROR=1 c-index-test -test-load-source all 
-fmodules -fmodules-cache-path=%t -Xclang -fdisable-module-hash -I 
%S/Inputs/Headers -DLIBCLANG_CRASH %s > /dev/null 2> %t.err
+// RUN: env CINDEXTEST_FAILONERROR=1 not c-index-test -test-load-source all 
-fmodules -fmodules-cache-path=%t -Xclang -fdisable-module-hash -I 
%S/Inputs/Headers -DLIBCLANG_CRASH %s > /dev/null 2> %t.err
 // RUN: FileCheck < %t.err -check-prefix=CHECK-LIBCLANG-CRASH %s
 // CHECK-LIBCLANG-CRASH: libclang: crash detected during parsing
 // CHECK-LIBCLANG-CRASH: Unable to load translation unit!


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

[PATCH] D66559: [OPENMP] Update the diagnosis message for canonical loop form

[Alexey Bataev via Phabricator via cfe-commits]

ABataev added a comment.

In D66559#1665289 , @cchen wrote:

> Oh, I was thinking that I could use "arc land" to commit my patch, but just 
> now realize that I don't have the commit privileges. Would you please commit 
> for me? Thanks.


Sure, will do this tomorrow.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66559



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

[PATCH] D66559: [OPENMP] Update the diagnosis message for canonical loop form

[Chi Chun Chen via Phabricator via cfe-commits]

cchen added a comment.

Oh, I was thinking that I could use "arc land" to commit my patch, but just now 
realize that I don't have the commit privileges. Would you please commit for 
me? Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D66559



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

[PATCH] D67249: [Modules][PCH] Hash input files content

[Bruno Cardoso Lopes via Phabricator via cfe-commits]

bruno updated this revision to Diff 219607.
bruno added a comment.

Update the patch to use two ::Fixed, 32 in abbrev to encode hash.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67249

Files:
  clang/include/clang/Basic/DiagnosticSerializationKinds.td
  clang/include/clang/Driver/Options.td
  clang/include/clang/Lex/HeaderSearchOptions.h
  clang/include/clang/Serialization/ASTBitCodes.h
  clang/include/clang/Serialization/ASTReader.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Serialization/ASTReader.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/test/Modules/validate-file-content.m
  clang/test/PCH/validate-file-content.m

Index: clang/test/PCH/validate-file-content.m
===
--- /dev/null
+++ clang/test/PCH/validate-file-content.m
@@ -0,0 +1,29 @@
+// REQUIRES: shell
+//
+// Check driver works
+// RUN: %clang -x objective-c-header -fsyntax-only -fpch-validate-input-files-content %t/a.h -### 2>&1 | FileCheck --check-prefix=CHECK-CC1 %s
+// CHECK-CC1: -fvalidate-ast-input-files-content
+//
+// PCH only: Test that a mtime mismatch without content change is fine
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: echo '// m.h' > %t/m.h
+// RUN: echo '#include "m.h"' > %t/a.h
+// RUN: %clang_cc1 -emit-pch -o %t/a.pch -I %t -x objective-c-header %t/a.h -fvalidate-ast-input-files-content
+// RUN: touch -m -a -t 20290101 %t/m.h
+// RUN: %clang_cc1 -fsyntax-only -I %t -include-pch %t/a.pch %s -verify -fvalidate-ast-input-files-content
+//
+// PCH only: Test that a mtime mismatch with content change
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: echo '// m.h' > %t/m.h
+// RUN: echo '#include "m.h"' > %t/a.h
+// RUN: %clang_cc1 -emit-pch -o %t/a.pch -I %t -x objective-c-header %t/a.h -fvalidate-ast-input-files-content
+// RUN: echo '// m.x' > %t/m.h
+// RUN: touch -m -a -t 20290101 %t/m.h
+// RUN: not %clang_cc1 -fsyntax-only -I %t -include-pch %t/a.pch %s -fvalidate-ast-input-files-content 2> %t/stderr
+// RUN: FileCheck %s < %t/stderr
+//
+// CHECK: file '[[M_H:.*[/\\]m\.h]]' has been modified since the precompiled header '[[A_PCH:.*/a\.pch]]' was built: content changed
+// CHECK: please rebuild precompiled header '[[A_PCH]]'
+// expected-no-diagnostics
Index: clang/test/Modules/validate-file-content.m
===
--- /dev/null
+++ clang/test/Modules/validate-file-content.m
@@ -0,0 +1,33 @@
+// REQUIRES: shell
+//
+// Check driver works
+// RUN: %clang -fmodules -fsyntax-only -fmodules-validate-input-files-content %s -### 2>&1 | FileCheck --check-prefix=CHECK-CC1 %s
+// CHECK-CC1: -fvalidate-ast-input-files-content
+//
+// PCH+Modules: Test that a mtime mismatch without content change is fine
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: echo '// m.h' > %t/m.h
+// RUN: echo '#include "m.h"' > %t/a.h
+// RUN: echo 'module m { header "m.h" }' > %t/module.modulemap
+// RUN: %clang_cc1 -emit-pch -fmodules-cache-path=%t/cache -fmodules -fimplicit-module-maps -o %t/a.pch -I %t -x objective-c-header %t/a.h -fvalidate-ast-input-files-content
+// RUN: touch -m -a -t 20290101 %t/m.h
+// RUN: %clang_cc1 -fsyntax-only -fmodules-cache-path=%t/cache -fmodules -fimplicit-module-maps -I %t -include-pch %t/a.pch %s -verify -fvalidate-ast-input-files-content
+//
+// PCH+Modules: Test that a mtime mismatch with content change
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: echo '// m.h' > %t/m.h
+// RUN: echo '#include "m.h"' > %t/a.h
+// RUN: echo 'module m { header "m.h" }' > %t/module.modulemap
+// RUN: %clang_cc1 -emit-pch -fmodules-cache-path=%t/cache -fmodules -fimplicit-module-maps -o %t/a.pch -I %t -x objective-c-header %t/a.h -fvalidate-ast-input-files-content
+// RUN: echo '// m.x' > %t/m.h
+// RUN: touch -m -a -t 20290101 %t/m.h
+// RUN: not %clang_cc1 -fsyntax-only -fmodules-cache-path=%t/cache -fmodules -fimplicit-module-maps -I %t -include-pch %t/a.pch %s -fvalidate-ast-input-files-content 2> %t/stderr
+// RUN: FileCheck %s < %t/stderr
+//
+// CHECK: file '[[M_H:.*[/\\]m\.h]]' has been modified since the precompiled header '[[A_PCH:.*/a\.pch]]' was built: content changed
+// CHECK: '[[M_H]]' required by '[[M_PCM:.*[/\\]m.*\.pcm]]'
+// CHECK: '[[M_PCM]]' required by '[[A_PCH]]'
+// CHECK: please rebuild precompiled header '[[A_PCH]]'
+// expected-no-diagnostics
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -1098,6 +1098,7 @@
 
   BLOCK(INPUT_FILES_BLOCK);
   RECORD(INPUT_FILE);
+  RECORD(INPUT_FILE_HASH);
 
   // AST Top-Level Block.
   BLOCK(AST_BLOCK);
@@ -1763,6 +1764,7 @@
   bool IsTransient;
   bool BufferOverridden;
   bool IsTopLevelModuleMap;
+  uint32_t 

Re: r359367 - Reinstate r359059, reverted in r359361, with a fix to properly prevent

[Richard Smith via cfe-commits]

Thanks, fixed in r371557.

On Mon, 9 Sep 2019 at 19:12, Michael Spencer via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Fri, Apr 26, 2019 at 7:56 PM Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: rsmith
>> Date: Fri Apr 26 19:58:17 2019
>> New Revision: 359367
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=359367=rev
>> Log:
>> Reinstate r359059, reverted in r359361, with a fix to properly prevent
>> us emitting the operand of __builtin_constant_p if it has side-effects.
>>
>> Original commit message:
>>
>> Fix interactions between __builtin_constant_p and constexpr to match
>> current trunk GCC.
>>
>> GCC permits information from outside the operand of
>> __builtin_constant_p (but in the same constant evaluation context) to be
>> used within that operand; clang now does so too. A few other minor
>> deviations from GCC's behavior showed up in my testing and are also
>> fixed (matching GCC):
>>   * Clang now supports nullptr_t as the argument type for
>> __builtin_constant_p
>> * Clang now returns true from __builtin_constant_p if called with a
>> null pointer
>> * Clang now returns true from __builtin_constant_p if called with an
>> integer cast to pointer type
>>
>> Added:
>> cfe/trunk/test/SemaCXX/builtin-constant-p.cpp
>> Modified:
>> cfe/trunk/lib/AST/ExprConstant.cpp
>> cfe/trunk/lib/CodeGen/CGBuiltin.cpp
>> cfe/trunk/lib/Sema/SemaChecking.cpp
>> cfe/trunk/test/CodeGen/builtin-constant-p.c
>> cfe/trunk/test/SemaCXX/enable_if.cpp
>>
>> Modified: cfe/trunk/lib/AST/ExprConstant.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=359367=359366=359367=diff
>>
>> ==
>> --- cfe/trunk/lib/AST/ExprConstant.cpp (original)
>> +++ cfe/trunk/lib/AST/ExprConstant.cpp Fri Apr 26 19:58:17 2019
>> @@ -7801,19 +7801,33 @@ EvaluateBuiltinClassifyType(const CallEx
>>  }
>>
>>  /// EvaluateBuiltinConstantPForLValue - Determine the result of
>> -/// __builtin_constant_p when applied to the given lvalue.
>> +/// __builtin_constant_p when applied to the given pointer.
>>  ///
>> -/// An lvalue is only "constant" if it is a pointer or reference to the
>> first
>> -/// character of a string literal.
>> -template
>> -static bool EvaluateBuiltinConstantPForLValue(const LValue ) {
>> -  const Expr *E = LV.getLValueBase().template dyn_cast();
>> -  return E && isa(E) && LV.getLValueOffset().isZero();
>> +/// A pointer is only "constant" if it is null (or a pointer cast to
>> integer)
>> +/// or it points to the first character of a string literal.
>> +static bool EvaluateBuiltinConstantPForLValue(const APValue ) {
>> +  APValue::LValueBase Base = LV.getLValueBase();
>> +  if (Base.isNull()) {
>> +// A null base is acceptable.
>> +return true;
>> +  } else if (const Expr *E = Base.dyn_cast()) {
>> +if (!isa(E))
>> +  return false;
>> +return LV.getLValueOffset().isZero();
>> +  } else {
>> +// Any other base is not constant enough for GCC.
>> +return false;
>> +  }
>>  }
>>
>>  /// EvaluateBuiltinConstantP - Evaluate __builtin_constant_p as
>> similarly to
>>  /// GCC as we can manage.
>> -static bool EvaluateBuiltinConstantP(ASTContext , const Expr *Arg) {
>> +static bool EvaluateBuiltinConstantP(EvalInfo , const Expr *Arg) {
>> +  // Constant-folding is always enabled for the operand of
>> __builtin_constant_p
>> +  // (even when the enclosing evaluation context otherwise requires a
>> strict
>> +  // language-specific constant expression).
>> +  FoldConstant Fold(Info, true);
>> +
>>QualType ArgType = Arg->getType();
>>
>>// __builtin_constant_p always has one operand. The rules which gcc
>> follows
>> @@ -7821,34 +7835,30 @@ static bool EvaluateBuiltinConstantP(AST
>>//
>>//  - If the operand is of integral, floating, complex or enumeration
>> type,
>>//and can be folded to a known value of that type, it returns 1.
>> -  //  - If the operand and can be folded to a pointer to the first
>> character
>> -  //of a string literal (or such a pointer cast to an integral
>> type), it
>> -  //returns 1.
>> +  //  - If the operand can be folded to a pointer to the first character
>> +  //of a string literal (or such a pointer cast to an integral type)
>> +  //or to a null pointer or an integer cast to a pointer, it returns
>> 1.
>>//
>>// Otherwise, it returns 0.
>>//
>>// FIXME: GCC also intends to return 1 for literals of aggregate
>> types, but
>> -  // its support for this does not currently work.
>> -  if (ArgType->isIntegralOrEnumerationType()) {
>> -Expr::EvalResult Result;
>> -if (!Arg->EvaluateAsRValue(Result, Ctx) || Result.HasSideEffects)
>> +  // its support for this did not work prior to GCC 9 and is not yet well
>> +  // understood.
>> +  if (ArgType->isIntegralOrEnumerationType() ||
>> ArgType->isFloatingType() ||
>> +  

r371557 - When evaluating a __builtin_constant_p conditional, always enter

[Richard Smith via cfe-commits]

Author: rsmith
Date: Tue Sep 10 14:24:09 2019
New Revision: 371557

URL: http://llvm.org/viewvc/llvm-project?rev=371557=rev
Log:
When evaluating a __builtin_constant_p conditional, always enter
constant-folding mode regardless of the original evaluation mode.

In order for this to be correct, we need to track whether we're checking
for a potential constant expression or checking for undefined behavior
separately from the evaluation mode enum, since we don't want to clobber
those states when entering constant-folding mode.

Modified:
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/test/Sema/i-c-e.c

Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=371557=371556=371557=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Tue Sep 10 14:24:09 2019
@@ -794,58 +794,47 @@ namespace {
 /// constant value.
 bool InConstantContext;
 
+/// Whether we're checking that an expression is a potential constant
+/// expression. If so, do not fail on constructs that could become constant
+/// later on (such as a use of an undefined global).
+bool CheckingPotentialConstantExpression = false;
+
+/// Whether we're checking for an expression that has undefined behavior.
+/// If so, we will produce warnings if we encounter an operation that is
+/// always undefined.
+bool CheckingForUndefinedBehavior = false;
+
 enum EvaluationMode {
   /// Evaluate as a constant expression. Stop if we find that the 
expression
   /// is not a constant expression.
   EM_ConstantExpression,
 
-  /// Evaluate as a potential constant expression. Keep going if we hit a
-  /// construct that we can't evaluate yet (because we don't yet know the
-  /// value of something) but stop if we hit something that could never be
-  /// a constant expression.
-  EM_PotentialConstantExpression,
+  /// Evaluate as a constant expression. Stop if we find that the 
expression
+  /// is not a constant expression. Some expressions can be retried in the
+  /// optimizer if we don't constant fold them here, but in an unevaluated
+  /// context we try to fold them immediately since the optimizer never
+  /// gets a chance to look at it.
+  EM_ConstantExpressionUnevaluated,
 
   /// Fold the expression to a constant. Stop if we hit a side-effect that
   /// we can't model.
   EM_ConstantFold,
 
-  /// Evaluate the expression looking for integer overflow and similar
-  /// issues. Don't worry about side-effects, and try to visit all
-  /// subexpressions.
-  EM_EvaluateForOverflow,
-
   /// Evaluate in any way we know how. Don't worry about side-effects that
   /// can't be modeled.
   EM_IgnoreSideEffects,
-
-  /// Evaluate as a constant expression. Stop if we find that the 
expression
-  /// is not a constant expression. Some expressions can be retried in the
-  /// optimizer if we don't constant fold them here, but in an unevaluated
-  /// context we try to fold them immediately since the optimizer never
-  /// gets a chance to look at it.
-  EM_ConstantExpressionUnevaluated,
-
-  /// Evaluate as a potential constant expression. Keep going if we hit a
-  /// construct that we can't evaluate yet (because we don't yet know the
-  /// value of something) but stop if we hit something that could never be
-  /// a constant expression. Some expressions can be retried in the
-  /// optimizer if we don't constant fold them here, but in an unevaluated
-  /// context we try to fold them immediately since the optimizer never
-  /// gets a chance to look at it.
-  EM_PotentialConstantExpressionUnevaluated,
 } EvalMode;
 
 /// Are we checking whether the expression is a potential constant
 /// expression?
 bool checkingPotentialConstantExpression() const {
-  return EvalMode == EM_PotentialConstantExpression ||
- EvalMode == EM_PotentialConstantExpressionUnevaluated;
+  return CheckingPotentialConstantExpression;
 }
 
 /// Are we checking an expression for overflow?
 // FIXME: We should check for any kind of undefined or suspicious behavior
 // in such constructs, not just overflow.
-bool checkingForOverflow() { return EvalMode == EM_EvaluateForOverflow; }
+bool checkingForUndefinedBehavior() { return CheckingForUndefinedBehavior; 
}
 
 EvalInfo(const ASTContext , Expr::EvalStatus , EvaluationMode Mode)
   : Ctx(const_cast(C)), EvalStatus(S), CurrentCall(nullptr),
@@ -932,15 +921,12 @@ namespace {
   switch (EvalMode) {
   case EM_ConstantFold:
   case EM_IgnoreSideEffects:
-  case EM_EvaluateForOverflow:
 if (!HasFoldFailureDiagnostic)
   break;
 // We've 

[PATCH] D67249: [Modules][PCH] Hash input files content

[Bruno Cardoso Lopes via Phabricator via cfe-commits]

bruno marked an inline comment as done.
bruno added inline comments.



Comment at: clang/lib/Serialization/ASTWriter.cpp:1767
   bool IsTopLevelModuleMap;
+  uint32_t ContentHash[2];
 };

ributzka wrote:
> bruno wrote:
> > aprantl wrote:
> > > Why is this not a uint64_t?
> > Serializing a `uint64_t` directly instead of two `uint32_t` gives me a 
> > slightly bigger final cache. One could argue that the value is negligible 
> > (+800 bytes for a 40MB cache), but here's the rationale :)
> Creating an abbrev might fix this, because this should be a fixed size field. 
> The generic emission code for a record without an abbrev is not very space 
> efficient for single fields.
Right, I did more experiments, and although VBR::64 or Fixed::64 aren't 
supported, I could shave off 10KB by using abbrev + two ::Fixed, 32. Using two 
::VBR:32 is actually 400 bytes worse than the current approach. Thanks for the 
suggestion, gonna update the patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67249



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

[PATCH] D67414: [AST] Treat "inline gnu_inline" the same way as "extern inline gnu_inline" in C++ mode

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo created this revision.
mstorsjo added reviewers: dblaikie, pcc, efriedma.
Herald added a project: clang.

This matches how GCC handles it, see e.g. https://gcc.godbolt.org/z/HPplnl.

The previous behaviour of gnu_inline in C++, without the extern keyword, can be 
traced back to the original commit that added support for gnu_inline, SVN 
r69045.


Repository:
  rC Clang

https://reviews.llvm.org/D67414

Files:
  lib/AST/Decl.cpp
  test/CodeGen/inline.c


Index: test/CodeGen/inline.c
===
--- test/CodeGen/inline.c
+++ test/CodeGen/inline.c
@@ -52,7 +52,7 @@
 // CHECK3-LABEL: define i32 @_Z3barv()
 // CHECK3-LABEL: define linkonce_odr i32 @_Z3foov()
 // CHECK3-NOT: unreferenced
-// CHECK3-LABEL: define void @_Z10gnu_inlinev()
+// CHECK3-LABEL: define available_externally void @_Z10gnu_inlinev()
 // CHECK3-LABEL: define available_externally void @_Z13gnu_ei_inlinev()
 // CHECK3-NOT: @_Z5testCv
 // CHECK3-LABEL: define linkonce_odr i32 @_Z2eiv()
@@ -85,6 +85,7 @@
 extern __inline void unreferenced2() {}
 
 __inline __attribute((__gnu_inline__)) void gnu_inline() {}
+void (*P1)() = gnu_inline;
 
 // PR3988
 extern __inline __attribute__((gnu_inline)) void gnu_ei_inline() {}
Index: lib/AST/Decl.cpp
===
--- lib/AST/Decl.cpp
+++ lib/AST/Decl.cpp
@@ -3257,7 +3257,8 @@
 //
 // FIXME: What happens if gnu_inline gets added on after the first
 // declaration?
-if (!isInlineSpecified() || getStorageClass() == SC_Extern)
+if (!isInlineSpecified() || getStorageClass() == SC_Extern ||
+Context.getLangOpts().CPlusPlus)
   return false;
 
 const FunctionDecl *Prev = this;
@@ -3360,6 +3361,8 @@
 // If it's not the case that both 'inline' and 'extern' are
 // specified on the definition, then this inline definition is
 // externally visible.
+if (Context.getLangOpts().CPlusPlus)
+  return false;
 if (!(isInlineSpecified() && getStorageClass() == SC_Extern))
   return true;
 


Index: test/CodeGen/inline.c
===
--- test/CodeGen/inline.c
+++ test/CodeGen/inline.c
@@ -52,7 +52,7 @@
 // CHECK3-LABEL: define i32 @_Z3barv()
 // CHECK3-LABEL: define linkonce_odr i32 @_Z3foov()
 // CHECK3-NOT: unreferenced
-// CHECK3-LABEL: define void @_Z10gnu_inlinev()
+// CHECK3-LABEL: define available_externally void @_Z10gnu_inlinev()
 // CHECK3-LABEL: define available_externally void @_Z13gnu_ei_inlinev()
 // CHECK3-NOT: @_Z5testCv
 // CHECK3-LABEL: define linkonce_odr i32 @_Z2eiv()
@@ -85,6 +85,7 @@
 extern __inline void unreferenced2() {}
 
 __inline __attribute((__gnu_inline__)) void gnu_inline() {}
+void (*P1)() = gnu_inline;
 
 // PR3988
 extern __inline __attribute__((gnu_inline)) void gnu_ei_inline() {}
Index: lib/AST/Decl.cpp
===
--- lib/AST/Decl.cpp
+++ lib/AST/Decl.cpp
@@ -3257,7 +3257,8 @@
 //
 // FIXME: What happens if gnu_inline gets added on after the first
 // declaration?
-if (!isInlineSpecified() || getStorageClass() == SC_Extern)
+if (!isInlineSpecified() || getStorageClass() == SC_Extern ||
+Context.getLangOpts().CPlusPlus)
   return false;
 
 const FunctionDecl *Prev = this;
@@ -3360,6 +3361,8 @@
 // If it's not the case that both 'inline' and 'extern' are
 // specified on the definition, then this inline definition is
 // externally visible.
+if (Context.getLangOpts().CPlusPlus)
+  return false;
 if (!(isInlineSpecified() && getStorageClass() == SC_Extern))
   return true;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D66856: [Sema] Suppress -Wformat diagnostics for bool types when printed using %hhd

[Erik Pilkington via Phabricator via cfe-commits]

erik.pilkington updated this revision to Diff 219598.
erik.pilkington added a comment.

Address review comments.


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

https://reviews.llvm.org/D66856

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/AST/Expr.cpp
  clang/lib/AST/FormatString.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/test/Sema/format-bool.c

Index: clang/test/Sema/format-bool.c
===
--- /dev/null
+++ clang/test/Sema/format-bool.c
@@ -0,0 +1,46 @@
+// RUN: %clang_cc1 -xc %s -verify -DBOOL=_Bool
+// RUN: %clang_cc1 -xc++ %s -verify -DBOOL=bool
+// RUN: %clang_cc1 -xobjective-c %s -verify -DBOOL=_Bool
+// RUN: %clang_cc1 -xc %s -verify -DBOOL=_Bool -Wformat-pedantic -DPEDANTIC
+// RUN: %clang_cc1 -xc++ %s -verify -DBOOL=bool -Wformat-pedantic -DPEDANTIC
+
+__attribute__((format(__printf__, 1, 2)))
+int p(const char *fmt, ...);
+
+BOOL b;
+
+#ifdef __OBJC__
+@interface NSString
++(NSString *)stringWithFormat:(NSString *)fmt, ...
+__attribute__((format(__NSString__, 1, 2)));
+@end
+
+#define YES __objc_yes
+#define NO __objc_no
+#endif
+
+int main() {
+  p("%d", b);
+  p("%hd", b);
+#ifdef PEDANTIC
+  // expected-warning@-2 {{format specifies type 'short' but the argument has type}}
+#endif
+  p("%hhd", b);
+  p("%u", b);
+  p("%hu", b);
+#ifdef PEDANTIC
+  // expected-warning@-2 {{format specifies type 'unsigned short' but the argument has type}}
+#endif
+  p("%hhu", b);
+  p("%c", b); // expected-warning {{format specifies a character but argument has boolean value}}
+  p("%lc", b); // expected-warning {{format specifies a character but argument has boolean value}}
+  p("%c", 1 == 1); // expected-warning {{format specifies a character but argument has boolean value}}
+  p("%f", b); // expected-warning{{format specifies type 'double' but the argument has type}}
+  p("%ld", b); // expected-warning{{format specifies type 'long' but the argument has type}}
+  p("%lld", b); // expected-warning{{format specifies type 'long long' but the argument has type}}
+
+#ifdef __OBJC__
+  [NSString stringWithFormat: @"%c", 0]; // probably fine?
+  [NSString stringWithFormat: @"%c", NO]; // expected-warning {{format specifies a character but argument has boolean value}}
+#endif
+}
Index: clang/lib/Sema/SemaChecking.cpp
===
--- clang/lib/Sema/SemaChecking.cpp
+++ clang/lib/Sema/SemaChecking.cpp
@@ -8109,6 +8109,20 @@
 ExprTy = TET->getUnderlyingExpr()->getType();
   }
 
+  // Diagnose attempts to print a boolean value as a character. Unlike other
+  // -Wformat diagnostics, this is fine from a type perspective, but it still
+  // doesn't make sense.
+  if (FS.getConversionSpecifier().getKind() == ConversionSpecifier::cArg &&
+  E->isKnownToHaveBooleanValue()) {
+const CharSourceRange  =
+getSpecifierRange(StartSpecifier, SpecifierLen);
+SourceLocation ExprLoc = E->getExprLoc();
+EmitFormatDiagnostic(S.PDiag(diag::warn_format_bool_as_character)
+ << ExprLoc,
+ ExprLoc, false, CSR);
+return true;
+  }
+
   const analyze_printf::ArgType::MatchKind Match =
   AT.matchesType(S.Context, ExprTy);
   bool Pedantic = Match == analyze_printf::ArgType::NoMatchPedantic;
Index: clang/lib/AST/FormatString.cpp
===
--- clang/lib/AST/FormatString.cpp
+++ clang/lib/AST/FormatString.cpp
@@ -359,6 +359,7 @@
   case BuiltinType::SChar:
   case BuiltinType::UChar:
   case BuiltinType::Char_U:
+  case BuiltinType::Bool:
 return Match;
 }
   return NoMatch;
@@ -386,6 +387,7 @@
   case BuiltinType::SChar:
   case BuiltinType::Char_U:
   case BuiltinType::UChar:
+  case BuiltinType::Bool:
 if (T == C.UnsignedShortTy || T == C.ShortTy)
   return NoMatchPedantic;
 return T == C.UnsignedCharTy || T == C.SignedCharTy ? Match
Index: clang/lib/AST/Expr.cpp
===
--- clang/lib/AST/Expr.cpp
+++ clang/lib/AST/Expr.cpp
@@ -185,6 +185,9 @@
 return CO->getTrueExpr()->isKnownToHaveBooleanValue() &&
CO->getFalseExpr()->isKnownToHaveBooleanValue();
 
+  if (isa(E))
+return true;
+
   return false;
 }
 
Index: clang/include/clang/Basic/DiagnosticSemaKinds.td
===
--- clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -8119,6 +8119,9 @@
 def warn_scanf_scanlist_incomplete : Warning<
   "no closing ']' for '%%[' in scanf format string">,
   InGroup;
+def warn_format_bool_as_character : Warning<
+  "format specifies a character but argument has boolean value">,
+  InGroup;
 def note_format_string_defined : Note<"format 

r371553 - [OPENMP5.0]Allow teams directive outside of the target directives.

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Tue Sep 10 13:19:58 2019
New Revision: 371553

URL: http://llvm.org/viewvc/llvm-project?rev=371553=rev
Log:
[OPENMP5.0]Allow teams directive outside of the target directives.

According to OpenMP 5.0, teams directives are allowed not only in the
target context, but also in the implicit parallel regions.

Modified:
cfe/trunk/lib/Sema/SemaOpenMP.cpp
cfe/trunk/test/OpenMP/teams_ast_print.cpp
cfe/trunk/test/OpenMP/teams_codegen.cpp
cfe/trunk/test/OpenMP/teams_messages.cpp

Modified: cfe/trunk/lib/Sema/SemaOpenMP.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaOpenMP.cpp?rev=371553=371552=371553=diff
==
--- cfe/trunk/lib/Sema/SemaOpenMP.cpp (original)
+++ cfe/trunk/lib/Sema/SemaOpenMP.cpp Tue Sep 10 13:19:58 2019
@@ -3876,7 +3876,10 @@ static bool checkNestingOfRegions(Sema &
   // OpenMP [2.16, Nesting of Regions]
   // If specified, a teams construct must be contained within a target
   // construct.
-  NestingProhibited = ParentRegion != OMPD_target;
+  NestingProhibited =
+  (SemaRef.LangOpts.OpenMP <= 45 && ParentRegion != OMPD_target) ||
+  (SemaRef.LangOpts.OpenMP >= 50 && ParentRegion != OMPD_unknown &&
+   ParentRegion != OMPD_target);
   OrphanSeen = ParentRegion == OMPD_unknown;
   Recommend = ShouldBeInTargetRegion;
 }

Modified: cfe/trunk/test/OpenMP/teams_ast_print.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/teams_ast_print.cpp?rev=371553=371552=371553=diff
==
--- cfe/trunk/test/OpenMP/teams_ast_print.cpp (original)
+++ cfe/trunk/test/OpenMP/teams_ast_print.cpp Tue Sep 10 13:19:58 2019
@@ -1,6 +1,9 @@
 // RUN: %clang_cc1 -verify -fopenmp -ast-print %s | FileCheck %s
 // RUN: %clang_cc1 -fopenmp -x c++ -std=c++11 -emit-pch -o %t %s
 // RUN: %clang_cc1 -fopenmp -std=c++11 -include-pch %t -fsyntax-only -verify 
%s -ast-print | FileCheck %s
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=50 -DOMP5 -ast-print %s | 
FileCheck %s --check-prefix=CHECK --check-prefix=OMP5
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -DOMP5 -x c++ -std=c++11 
-emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -DOMP5 -std=c++11 -include-pch 
%t -fsyntax-only -verify %s -ast-print | FileCheck %s --check-prefix=CHECK 
--check-prefix=OMP5
 
 // RUN: %clang_cc1 -verify -fopenmp-simd -ast-print %s | FileCheck %s
 // RUN: %clang_cc1 -fopenmp-simd -x c++ -std=c++11 -emit-pch -o %t %s
@@ -37,6 +40,10 @@ T tmain(T argc, T *argv) {
   T b = argc, c, d, e, f, g;
   static T a;
   S s;
+#ifdef OMP5
+#pragma omp teams
+  a=2;
+#endif // OMP5
 #pragma omp target
 #pragma omp teams
   a=2;
@@ -53,6 +60,8 @@ T tmain(T argc, T *argv) {
 // CHECK-NEXT: T b = argc, c, d, e, f, g;
 // CHECK-NEXT: static T a;
 // CHECK-NEXT: S s;
+// OMP5-NEXT:  #pragma omp teams
+// OMP5-NEXT:  a = 2;
 // CHECK-NEXT: #pragma omp target
 // CHECK-NEXT: #pragma omp teams{{$}}
 // CHECK-NEXT: a = 2;
@@ -66,6 +75,8 @@ T tmain(T argc, T *argv) {
 // CHECK-NEXT: int b = argc, c, d, e, f, g;
 // CHECK-NEXT: static int a;
 // CHECK-NEXT: S s;
+// OMP5-NEXT:  #pragma omp teams
+// OMP5-NEXT:  a = 2;
 // CHECK-NEXT: #pragma omp target
 // CHECK-NEXT: #pragma omp teams
 // CHECK-NEXT: a = 2;
@@ -79,6 +90,8 @@ T tmain(T argc, T *argv) {
 // CHECK-NEXT: long b = argc, c, d, e, f, g;
 // CHECK-NEXT: static long a;
 // CHECK-NEXT: S s;
+// OMP5-NEXT:  #pragma omp teams
+// OMP5-NEXT:  a = 2;
 // CHECK-NEXT: #pragma omp target
 // CHECK-NEXT: #pragma omp teams
 // CHECK-NEXT: a = 2;

Modified: cfe/trunk/test/OpenMP/teams_codegen.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/teams_codegen.cpp?rev=371553=371552=371553=diff
==
--- cfe/trunk/test/OpenMP/teams_codegen.cpp (original)
+++ cfe/trunk/test/OpenMP/teams_codegen.cpp Tue Sep 10 13:19:58 2019
@@ -394,4 +394,31 @@ int main (int argc, char **argv) {
 // CK5-NEXT: }
 
 #endif // CK5
+
+// Test host codegen.
+// RUN: %clang_cc1 -DCK6 -verify -fopenmp -fopenmp-version=50 -x c++ -triple 
powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu 
-emit-llvm %s -o - | FileCheck %s --check-prefix CK6 --check-prefix CK6-64
+// RUN: %clang_cc1 -DCK6 -fopenmp -fopenmp-version=50 -x c++ -std=c++11 
-triple powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu 
-emit-pch -o %t %s
+// RUN: %clang_cc1 -DCK6 -fopenmp-version=50 -fopenmp -x c++ -triple 
powerpc64le-unknown-unknown -fopenmp-targets=powerpc64le-ibm-linux-gnu 
-std=c++11 -include-pch %t -verify %s -emit-llvm -o - | FileCheck %s 
--check-prefix CK6 --check-prefix CK6-64
+// RUN: %clang_cc1 -DCK6 -verify -fopenmp -fopenmp-version=50 -x c++ -triple 
i386-unknown-unknown -fopenmp-targets=i386-pc-linux-gnu -emit-llvm %s -o - | 
FileCheck %s 

r371552 - Re-land Remove REQUIRES:shell from tests that pass for me on Windows

[Reid Kleckner via cfe-commits]

Author: rnk
Date: Tue Sep 10 13:15:45 2019
New Revision: 371552

URL: http://llvm.org/viewvc/llvm-project?rev=371552=rev
Log:
Re-land Remove REQUIRES:shell from tests that pass for me on Windows

This reverts r371497 (git commit 3d7e9ab7b9f8c53aa41420c54970f0fb421004a2)

Reorder `not` with `env` in these two tests so they pass:
  Driver/rewrite-map-in-diagnostics.c
  Index/crash-recovery-modules.m.

This will not be necessary after D66531 lands.

Modified:
cfe/trunk/test/Analysis/crash-trace.c
cfe/trunk/test/CodeGen/thinlto_backend.ll
cfe/trunk/test/Driver/check-time-trace-sections.cpp
cfe/trunk/test/Driver/check-time-trace.cpp
cfe/trunk/test/Driver/clang-offload-bundler.c
cfe/trunk/test/Driver/crash-report-crashfile.m
cfe/trunk/test/Driver/rewrite-map-in-diagnostics.c
cfe/trunk/test/Format/style-on-command-line.cpp
cfe/trunk/test/Frontend/dependency-gen-has-include.c
cfe/trunk/test/Index/crash-recovery-modules.m
cfe/trunk/test/Modules/at-import-in-framework-header.m
cfe/trunk/test/Modules/builtins.m
cfe/trunk/test/Modules/dependency-dump-dependent-module.m
cfe/trunk/test/Modules/dependency-dump.m
cfe/trunk/test/Modules/implicit-invalidate-common.c
cfe/trunk/test/OpenMP/task_firstprivate_codegen.cpp
cfe/trunk/test/OpenMP/task_private_codegen.cpp
cfe/trunk/test/OpenMP/taskloop_firstprivate_codegen.cpp
cfe/trunk/test/OpenMP/taskloop_lastprivate_codegen.cpp
cfe/trunk/test/OpenMP/taskloop_private_codegen.cpp
cfe/trunk/test/OpenMP/taskloop_simd_firstprivate_codegen.cpp
cfe/trunk/test/OpenMP/taskloop_simd_lastprivate_codegen.cpp
cfe/trunk/test/OpenMP/taskloop_simd_private_codegen.cpp
cfe/trunk/test/PCH/modified-header-error.c
cfe/trunk/test/Parser/crash-report.c

Modified: cfe/trunk/test/Analysis/crash-trace.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Analysis/crash-trace.c?rev=371552=371551=371552=diff
==
--- cfe/trunk/test/Analysis/crash-trace.c (original)
+++ cfe/trunk/test/Analysis/crash-trace.c Tue Sep 10 13:15:45 2019
@@ -1,9 +1,8 @@
 // RUN: not --crash %clang_analyze_cc1 -analyzer-checker=debug.ExprInspection 
%s 2>&1 | FileCheck %s
 // REQUIRES: crash-recovery
 
-// FIXME: CHECKs might be incompatible to win32.
-// Stack traces also require back traces.
-// REQUIRES: shell, backtrace
+// Stack traces require back traces.
+// REQUIRES: backtrace
 
 void clang_analyzer_crash(void);
 
@@ -18,6 +17,6 @@ void test() {
 // CHECK: 0.   Program arguments: {{.*}}clang
 // CHECK-NEXT: 1.   parser at end of file
 // CHECK-NEXT: 2. While analyzing stack: 
-// CHECK-NEXT:  #0 Calling inlined at line 15
+// CHECK-NEXT:  #0 Calling inlined at line 14
 // CHECK-NEXT:  #1 Calling test
 // CHECK-NEXT: 3.  {{.*}}crash-trace.c:{{[0-9]+}}:3: Error evaluating 
statement

Modified: cfe/trunk/test/CodeGen/thinlto_backend.ll
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/thinlto_backend.ll?rev=371552=371551=371552=diff
==
--- cfe/trunk/test/CodeGen/thinlto_backend.ll (original)
+++ cfe/trunk/test/CodeGen/thinlto_backend.ll Tue Sep 10 13:15:45 2019
@@ -1,5 +1,4 @@
-; shell required since the windows bot does not like the "(cd ..."
-; REQUIRES: x86-registered-target, shell
+; REQUIRES: x86-registered-target
 
 ; RUN: opt -module-summary -o %t1.o %s
 ; RUN: opt -module-summary -o %t2.o %S/Inputs/thinlto_backend.ll
@@ -32,10 +31,14 @@
 ; RUN: %clang -target x86_64-unknown-linux-gnu -O2 -o %t3.o -x ir %t1.o -c 
-fthinlto-index=%t.thinlto.bc -save-temps=obj
 ; RUN: llvm-dis %t1.s.3.import.bc -o - | FileCheck --check-prefix=CHECK-IMPORT 
%s
 ; RUN: mkdir -p %T/dir1
-; RUN: (cd %T/dir1 && %clang -target x86_64-unknown-linux-gnu -O2 -o %t3.o -x 
ir %t1.o -c -fthinlto-index=%t.thinlto.bc -save-temps=cwd)
+; RUN: cd %T/dir1
+; RUN: %clang -target x86_64-unknown-linux-gnu -O2 -o %t3.o -x ir %t1.o -c 
-fthinlto-index=%t.thinlto.bc -save-temps=cwd
+; RUN: cd ../..
 ; RUN: llvm-dis %T/dir1/*1.s.3.import.bc -o - | FileCheck 
--check-prefix=CHECK-IMPORT %s
 ; RUN: mkdir -p %T/dir2
-; RUN: (cd %T/dir2 && %clang -target x86_64-unknown-linux-gnu -O2 -o %t3.o -x 
ir %t1.o -c -fthinlto-index=%t.thinlto.bc -save-temps)
+; RUN: cd %T/dir2
+; RUN: %clang -target x86_64-unknown-linux-gnu -O2 -o %t3.o -x ir %t1.o -c 
-fthinlto-index=%t.thinlto.bc -save-temps
+; RUN: cd ../..
 ; RUN: llvm-dis %T/dir2/*1.s.3.import.bc -o - | FileCheck 
--check-prefix=CHECK-IMPORT %s
 ; CHECK-IMPORT: define available_externally void @f2()
 ; RUN: llvm-nm %t3.o | FileCheck --check-prefix=CHECK-OBJ %s

Modified: cfe/trunk/test/Driver/check-time-trace-sections.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/check-time-trace-sections.cpp?rev=371552=371551=371552=diff
==
--- 

[PATCH] D67246: clang-format: Add support for formatting lambdas with explicit template parameters.

[Nico Weber via Phabricator via cfe-commits]

thakis updated this revision to Diff 219589.
thakis added a comment.

fix nits


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

https://reviews.llvm.org/D67246

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


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -12888,6 +12888,10 @@
"  return 1; //\n"
"};");
 
+  // Lambdas with explicit template argument lists.
+  verifyFormat(
+  "auto L = [] class T, class U>(T &) {};\n");
+
   // Multiple lambdas in the same parentheses change indentation rules. These
   // lambdas are forced to start on new lines.
   verifyFormat("SomeFunction(\n"
@@ -12905,8 +12909,8 @@
"},\n"
"1);\n");
 
-  // A multi-line lambda passed as arg1 forces arg0 to be pushed out, just 
like the arg0
-  // case above.
+  // A multi-line lambda passed as arg1 forces arg0 to be pushed out, just like
+  // the arg0 case above.
   auto Style = getGoogleStyle();
   Style.BinPackArguments = false;
   verifyFormat("SomeFunction(\n"
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -1440,8 +1440,11 @@
 case tok::identifier:
 case tok::numeric_constant:
 case tok::coloncolon:
+case tok::kw_class:
 case tok::kw_mutable:
 case tok::kw_noexcept:
+case tok::kw_template:
+case tok::kw_typename:
   nextToken();
   break;
 // Specialization of a template with an integer parameter can contain
@@ -1455,6 +1458,9 @@
 // followed by an `a->b` expression, such as:
 // ([obj func:arg] + a->b)
 // Otherwise the code below would parse as a lambda.
+//
+// FIXME: This heuristic is incorrect for C++20 generic lambdas with
+// explicit template lists: [](U &){}
 case tok::plus:
 case tok::minus:
 case tok::exclaim:
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -40,6 +40,21 @@
   return Tok.Tok.getIdentifierInfo() != nullptr;
 }
 
+/// With `Left` being '(', check if we're at either `[...](` or
+/// `[...]<...>(`, where the [ opens a lambda capture list.
+static bool isLambdaParameterList(const FormatToken *Left) {
+  // Skip <...> if present.
+  if (Left->Previous && Left->Previous->is(tok::greater) &&
+  Left->Previous->MatchingParen &&
+  Left->Previous->MatchingParen->is(TT_TemplateOpener))
+Left = Left->Previous->MatchingParen;
+
+  // Check for `[...]`.
+  return Left->Previous && Left->Previous->is(tok::r_square) &&
+ Left->Previous->MatchingParen &&
+ Left->Previous->MatchingParen->is(TT_LambdaLSquare);
+}
+
 /// A parser that gathers additional information about tokens.
 ///
 /// The \c TokenAnnotator tries to match parenthesis and square brakets and
@@ -191,9 +206,7 @@
Left->Previous->is(TT_JsTypeColon)) {
   // let x: (SomeType);
   Contexts.back().IsExpression = false;
-} else if (Left->Previous && Left->Previous->is(tok::r_square) &&
-   Left->Previous->MatchingParen &&
-   Left->Previous->MatchingParen->is(TT_LambdaLSquare)) {
+} else if (isLambdaParameterList(Left)) {
   // This is a parameter list of a lambda expression.
   Contexts.back().IsExpression = false;
 } else if (Line.InPPDirective &&


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -12888,6 +12888,10 @@
"  return 1; //\n"
"};");
 
+  // Lambdas with explicit template argument lists.
+  verifyFormat(
+  "auto L = [] class T, class U>(T &) {};\n");
+
   // Multiple lambdas in the same parentheses change indentation rules. These
   // lambdas are forced to start on new lines.
   verifyFormat("SomeFunction(\n"
@@ -12905,8 +12909,8 @@
"},\n"
"1);\n");
 
-  // A multi-line lambda passed as arg1 forces arg0 to be pushed out, just like the arg0
-  // case above.
+  // A multi-line lambda passed as arg1 forces arg0 to be pushed out, just like
+  // the arg0 case above.
   auto Style = getGoogleStyle();
   Style.BinPackArguments = false;
   verifyFormat("SomeFunction(\n"
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -1440,8 +1440,11 @@
 case tok::identifier:
 case 

[PATCH] D67395: [clang-format] Apply BAS_AlwaysBreak to C++11 braced lists

[MyDeveloperDay via Phabricator via cfe-commits]

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

Thank you for this patch, i've seen a number of PRs raise to this effect.. this 
looks to be a great start in this area

LGTM


Repository:
  rC Clang

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

https://reviews.llvm.org/D67395



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

[PATCH] D67246: clang-format: Add support for formatting lambdas with explicit template parameters.

[Nico Weber via Phabricator via cfe-commits]

thakis marked 3 inline comments as done.
thakis added a comment.

Thanks for the thorough review! Indeed, this still gets `[](A &){}();` wrong, for the reason you mention.




Comment at: clang/lib/Format/TokenAnnotator.cpp:50
+  // Skip <...> if present.
+  if (Left->Previous && Left->Previous->is(tok::greater) &&
+  Left->Previous->MatchingParen &&

krasimir wrote:
> The first `Left->Previous` check is unnecessary here, following the previous 
> `if`.
I removed the previous `if`, it makes the function more symmetric.


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

https://reviews.llvm.org/D67246



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

[PATCH] D67037: [ClangFormat] Add new style option IndentGotoLabels

[Alex Cameron via Phabricator via cfe-commits]

tetsuo-cpp added a comment.

@MyDeveloperDay
Thanks for your suggestions! I think it's better now.
This is my first LLVM patch (hopefully first of many) so I don't have commit 
permissions yet. If you're still happy with this change, could you please 
commit on my behalf?


Repository:
  rC Clang

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

https://reviews.llvm.org/D67037



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

[PATCH] D67037: [ClangFormat] Add new style option IndentGotoLabels

[Alex Cameron via Phabricator via cfe-commits]

tetsuo-cpp updated this revision to Diff 219582.
tetsuo-cpp added a comment.

Addressed review comments.


Repository:
  rC Clang

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

https://reviews.llvm.org/D67037

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

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -1408,6 +1408,30 @@
"test_label:;\n"
"  int i = 0;\n"
"}");
+  FormatStyle Style = getLLVMStyle();
+  Style.IndentGotoLabels = false;
+  verifyFormat("void f() {\n"
+   "  some_code();\n"
+   "test_label:\n"
+   "  some_other_code();\n"
+   "  {\n"
+   "some_more_code();\n"
+   "another_label:\n"
+   "some_more_code();\n"
+   "  }\n"
+   "}",
+   Style);
+  verifyFormat("{\n"
+   "  some_code();\n"
+   "test_label:\n"
+   "  some_other_code();\n"
+   "}",
+   Style);
+  verifyFormat("{\n"
+   "  some_code();\n"
+   "test_label:;\n"
+   "  int i = 0;\n"
+   "}");
 }
 
 //===--===//
@@ -11769,6 +11793,7 @@
   CHECK_PARSE_BOOL_FIELD(DerivePointerAlignment, "DerivePointerBinding");
   CHECK_PARSE_BOOL(DisableFormat);
   CHECK_PARSE_BOOL(IndentCaseLabels);
+  CHECK_PARSE_BOOL(IndentGotoLabels);
   CHECK_PARSE_BOOL(IndentWrappedFunctionNames);
   CHECK_PARSE_BOOL(KeepEmptyLinesAtTheStartOfBlocks);
   CHECK_PARSE_BOOL(ObjCSpaceAfterProperty);
Index: clang/lib/Format/UnwrappedLineParser.h
===
--- clang/lib/Format/UnwrappedLineParser.h
+++ clang/lib/Format/UnwrappedLineParser.h
@@ -106,7 +106,7 @@
   void parseTryCatch();
   void parseForOrWhileLoop();
   void parseDoWhile();
-  void parseLabel();
+  void parseLabel(bool LeftAlignLabel = false);
   void parseCaseLabel();
   void parseSwitch();
   void parseNamespace();
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -1351,7 +1351,7 @@
   (TokenCount == 2 && Line->Tokens.front().Tok->is(tok::comment))) {
 if (FormatTok->Tok.is(tok::colon) && !Line->MustBeDeclaration) {
   Line->Tokens.begin()->Tok->MustBreakBefore = true;
-  parseLabel();
+  parseLabel(!Style.IndentGotoLabels);
   return;
 }
 // Recognize function-like macro usages without trailing semicolon as
@@ -1970,11 +1970,13 @@
   parseStructuralElement();
 }
 
-void UnwrappedLineParser::parseLabel() {
+void UnwrappedLineParser::parseLabel(bool LeftAlignLabel) {
   nextToken();
   unsigned OldLineLevel = Line->Level;
   if (Line->Level > 1 || (!Line->InPPDirective && Line->Level > 0))
 --Line->Level;
+  if (LeftAlignLabel)
+Line->Level = 0;
   if (CommentsBeforeNextToken.empty() && FormatTok->Tok.is(tok::l_brace)) {
 CompoundStatementIndenter Indenter(this, Line->Level,
Style.BraceWrapping.AfterCaseLabel,
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -453,6 +453,7 @@
 IO.mapOptional("IncludeCategories", Style.IncludeStyle.IncludeCategories);
 IO.mapOptional("IncludeIsMainRegex", Style.IncludeStyle.IncludeIsMainRegex);
 IO.mapOptional("IndentCaseLabels", Style.IndentCaseLabels);
+IO.mapOptional("IndentGotoLabels", Style.IndentGotoLabels);
 IO.mapOptional("IndentPPDirectives", Style.IndentPPDirectives);
 IO.mapOptional("IndentWidth", Style.IndentWidth);
 IO.mapOptional("IndentWrappedFunctionNames",
@@ -725,6 +726,7 @@
   LLVMStyle.IncludeStyle.IncludeIsMainRegex = "(Test)?$";
   LLVMStyle.IncludeStyle.IncludeBlocks = tooling::IncludeStyle::IBS_Preserve;
   LLVMStyle.IndentCaseLabels = false;
+  LLVMStyle.IndentGotoLabels = true;
   LLVMStyle.IndentPPDirectives = FormatStyle::PPDIS_None;
   LLVMStyle.IndentWrappedFunctionNames = false;
   LLVMStyle.IndentWidth = 2;
Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -1265,6 +1265,22 @@
   /// \endcode
   bool IndentCaseLabels;
 
+  /// Indent goto labels.
+  ///
+  /// When ``false``, goto labels are flushed left.
+  /// \code
+  ///   

r371548 - Fix for PR43175: compiler crash when trying to emit noncapturable

[Alexey Bataev via cfe-commits]

Author: abataev
Date: Tue Sep 10 12:16:56 2019
New Revision: 371548

URL: http://llvm.org/viewvc/llvm-project?rev=371548=rev
Log:
Fix for PR43175: compiler crash when trying to emit noncapturable
constant.

If the constexpr variable is partially initialized, the initializer can
be emitted as the structure, not as an array, because of some early
optimizations. The llvm variable gets the type from this constant and,
thus, gets the type which is pointer to struct rather than pointer to an
array. We need to convert this type to be truely array, otherwise it may
lead to the compiler crash when trying to emit array subscript
expression.

Added:
cfe/trunk/test/OpenMP/constexpr_partial_array.cpp
Modified:
cfe/trunk/lib/CodeGen/CGExpr.cpp

Modified: cfe/trunk/lib/CodeGen/CGExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGExpr.cpp?rev=371548=371547=371548=diff
==
--- cfe/trunk/lib/CodeGen/CGExpr.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGExpr.cpp Tue Sep 10 12:16:56 2019
@@ -2539,6 +2539,11 @@ LValue CodeGenFunction::EmitDeclRefLValu
 // Spill the constant value to a global.
 Addr = CGM.createUnnamedGlobalFrom(*VD, Val,
getContext().getDeclAlign(VD));
+llvm::Type *VarTy = getTypes().ConvertTypeForMem(VD->getType());
+auto *PTy = llvm::PointerType::get(
+VarTy, getContext().getTargetAddressSpace(VD->getType()));
+if (PTy != Addr.getType())
+  Addr = Builder.CreatePointerBitCastOrAddrSpaceCast(Addr, PTy);
   } else {
 // Should we be using the alignment of the constant pointer we emitted?
 CharUnits Alignment =

Added: cfe/trunk/test/OpenMP/constexpr_partial_array.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/OpenMP/constexpr_partial_array.cpp?rev=371548=auto
==
--- cfe/trunk/test/OpenMP/constexpr_partial_array.cpp (added)
+++ cfe/trunk/test/OpenMP/constexpr_partial_array.cpp Tue Sep 10 12:16:56 2019
@@ -0,0 +1,10 @@
+// RUN: %clang_cc1 -verify -triple x86_64-pc-windows-msvc19.22.27905 
-emit-llvm -o - -fopenmp %s | FileCheck %s
+// expected-no-diagnostics
+
+// CHECK: [[C_VAR_VAL:@.+]] = private unnamed_addr constant <{ i8, [26 x i8] 
}> <{ i8 1, [26 x i8] zeroinitializer }>,
+char a;
+bool b() {
+  static constexpr bool c[27]{1};
+  // CHECK: getelementptr inbounds [27 x i8], [27 x i8]* bitcast (<{ i8, [26 x 
i8] }>* [[C_VAR_VAL]] to [27 x i8]*),
+  return c[a];
+}


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

[PATCH] D67135: [clang-tidy] performance-inefficient-vector-operation: Support proto repeated field

[Cong Liu via Phabricator via cfe-commits]

congliu updated this revision to Diff 219576.
congliu marked 6 inline comments as done.
congliu added a comment.

Addressed Haojian's comments.


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

https://reviews.llvm.org/D67135

Files:
  clang-tools-extra/clang-tidy/performance/InefficientVectorOperationCheck.cpp
  clang-tools-extra/clang-tidy/performance/InefficientVectorOperationCheck.h
  
clang-tools-extra/docs/clang-tidy/checks/performance-inefficient-vector-operation.rst
  clang-tools-extra/test/clang-tidy/performance-inefficient-vector-operation.cpp

Index: clang-tools-extra/test/clang-tidy/performance-inefficient-vector-operation.cpp
===
--- clang-tools-extra/test/clang-tidy/performance-inefficient-vector-operation.cpp
+++ clang-tools-extra/test/clang-tidy/performance-inefficient-vector-operation.cpp
@@ -1,4 +1,7 @@
-// RUN: %check_clang_tidy %s performance-inefficient-vector-operation %t -- -format-style=llvm
+// RUN: %check_clang_tidy %s performance-inefficient-vector-operation %t -- \
+// RUN: -format-style=llvm \
+// RUN: -config='{CheckOptions: \
+// RUN:  [{key: performance-inefficient-vector-operation.EnableProto, value: 1}]}'
 
 namespace std {
 
@@ -62,13 +65,35 @@
 
 int Op(int);
 
+namespace proto2 {
+class MessageLite {};
+class Message : public MessageLite {};
+} // namespace proto2
+
+class FooProto : public proto2::Message {
+ public:
+  int *add_x();  // repeated int x;
+  void add_x(int x);
+  void mutable_x();
+  void mutable_y();
+  int add_z() const; // optional int add_z;
+};
+
+class BarProto : public proto2::Message {
+ public:
+  int *add_x();
+  void add_x(int x);
+  void mutable_x();
+  void mutable_y();
+};
+
 void f(std::vector& t) {
   {
 std::vector v0;
 // CHECK-FIXES: v0.reserve(10);
 for (int i = 0; i < 10; ++i)
   v0.push_back(i);
-  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: 'push_back' is called inside a loop; consider pre-allocating the vector capacity before the loop
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: 'push_back' is called inside a loop; consider pre-allocating the container capacity before the loop
   }
   {
 std::vector v1;
@@ -162,6 +187,15 @@
 }
   }
 
+  {
+FooProto foo;
+// CHECK-FIXES: foo.mutable_x()->Reserve(5);
+for (int i = 0; i < 5; i++) {
+  foo.add_x(i);
+  // CHECK-MESSAGES: :[[@LINE-1]]:7: warning: 'add_x' is called inside a loop; consider pre-allocating the container capacity before the loop
+}
+  }
+
   //  Non-fixed Cases 
   {
 std::vector z0;
@@ -274,4 +308,54 @@
   z12.push_back(e);
 }
   }
+
+  {
+FooProto foo;
+foo.mutable_x();
+// CHECK-FIXES-NOT: foo.mutable_x->Reserve(5);
+for (int i = 0; i < 5; i++) {
+  foo.add_x(i);
+}
+  }
+  {
+FooProto foo;
+// CHECK-FIXES-NOT: foo.mutable_x->Reserve(5);
+for (int i = 0; i < 5; i++) {
+  foo.add_x(i);
+  foo.add_x(i);
+}
+  }
+  {
+FooProto foo;
+// CHECK-FIXES-NOT: foo.mutable_x->Reserve(5);
+foo.add_x(-1);
+for (int i = 0; i < 5; i++) {
+  foo.add_x(i);
+}
+  }
+  {
+FooProto foo;
+BarProto bar;
+bar.mutable_x();
+// CHECK-FIXES-NOT: foo.mutable_x->Reserve(5);
+for (int i = 0; i < 5; i++) {
+  foo.add_x();
+  bar.add_x();
+}
+  }
+  {
+FooProto foo;
+foo.mutable_y();
+// CHECK-FIXES-NOT: foo.mutable_x()->Reserve(5);
+for (int i = 0; i < 5; i++) {
+  foo.add_x(i);
+}
+  }
+  {
+FooProto foo;
+// CHECK-FIXES-NOT: foo.mutable_z->Reserve(5);
+for (int i = 0; i < 5; i++) {
+  foo.add_z();
+}
+  }
 }
Index: clang-tools-extra/docs/clang-tidy/checks/performance-inefficient-vector-operation.rst
===
--- clang-tools-extra/docs/clang-tidy/checks/performance-inefficient-vector-operation.rst
+++ clang-tools-extra/docs/clang-tidy/checks/performance-inefficient-vector-operation.rst
@@ -6,6 +6,10 @@
 Finds possible inefficient ``std::vector`` operations (e.g. ``push_back``,
 ``emplace_back``) that may cause unnecessary memory reallocations.
 
+It can also find calls that add element to protobuf repeated field in a loop
+without calling Reserve() before the loop. Calling Reserve() first can avoid
+unnecessary memory reallocations.
+
 Currently, the check only detects following kinds of loops with a single
 statement body:
 
@@ -21,6 +25,13 @@
 // statement before the for statement.
   }
 
+  SomeProto p;
+  for (int i = 0; i < n; ++i) {
+p.add_xxx(n);
+// This will trigger the warning since the add_xxx may cause multiple memory
+// relloacations. This can be avoid by inserting a
+// 'p.mutable_xxx().Reserve(n)' statement before the for statement.
+  }
 
 * For-range loops like ``for (range-declaration : range_expression)``, the type
   of ``range_expression`` can be ``std::vector``, ``std::array``,
@@ -47,3 +58,8 @@
 

[PATCH] D67409: [RISCV] enable LTO support, pass some options to linker.

[Kuan Hsu Chen via Phabricator via cfe-commits]

khchen created this revision.
khchen added a project: clang.
Herald added subscribers: pzheng, s.egerton, lenary, Jim, benna, psnobl, 
jocewei, PkmX, rkruppe, dexonsmith, the_o, brucehoult, MartinMosbeck, rogfer01, 
steven_wu, edward-jones, zzheng, MaskRay, jrtc27, shiva0217, kito-cheng, 
niosHD, sabuasal, apazos, simoncook, johnrusso, rbar, asb, inglorion, 
mehdi_amini.

If enable -flto we need to pass the target feature and ABIName to linker for 
generate correct result.


Repository:
  rC Clang

https://reviews.llvm.org/D67409

Files:
  clang/lib/Driver/ToolChains/RISCVToolchain.cpp
  clang/lib/Driver/ToolChains/RISCVToolchain.h
  clang/test/Driver/gold-lto.c


Index: clang/test/Driver/gold-lto.c
===
--- clang/test/Driver/gold-lto.c
+++ clang/test/Driver/gold-lto.c
@@ -26,3 +26,11 @@
 // RUN: %clang -target i686-linux-android -### %t.o -flto 2>&1 \
 // RUN: | FileCheck %s --check-prefix=CHECK-X86-ANDROID
 // CHECK-X86-ANDROID: "-plugin" "{{.*}}{{[/\\]}}LLVMgold.{{dll|dylib|so}}"
+//
+// RUN: %clang -target riscv64-unknown-elf -### %t.o -flto 2>&1 \
+// RUN: -march=rv64imf -mabi=lp64f \
+// RUN: | FileCheck %s --check-prefix=CHECK-RISCV
+// CHECK-RISCV: "-plugin-opt=--mattr=+m"
+// CHECK-RISCV: "-plugin-opt=--mattr=+f"
+// CHECK-RISCV: "-plugin-opt=--mattr=+relax"
+// CHECK-RISCV: "-plugin-opt=-target-abi=lp64f"
Index: clang/lib/Driver/ToolChains/RISCVToolchain.h
===
--- clang/lib/Driver/ToolChains/RISCVToolchain.h
+++ clang/lib/Driver/ToolChains/RISCVToolchain.h
@@ -25,6 +25,7 @@
   void addClangTargetOptions(const llvm::opt::ArgList ,
  llvm::opt::ArgStringList ,
  Action::OffloadKind) const override;
+  bool HasNativeLLVMSupport() const override { return true; }
   void
   AddClangSystemIncludeArgs(const llvm::opt::ArgList ,
 llvm::opt::ArgStringList ) const override;
Index: clang/lib/Driver/ToolChains/RISCVToolchain.cpp
===
--- clang/lib/Driver/ToolChains/RISCVToolchain.cpp
+++ clang/lib/Driver/ToolChains/RISCVToolchain.cpp
@@ -7,6 +7,7 @@
 
//===--===//
 
 #include "RISCVToolchain.h"
+#include "Arch/RISCV.h"
 #include "CommonArgs.h"
 #include "InputInfo.h"
 #include "clang/Driver/Compilation.h"
@@ -100,6 +101,46 @@
 
   std::string Linker = getToolChain().GetProgramPath(getShortName());
 
+  if (D.isUsingLTO()) {
+assert(!Inputs.empty() && "Must have at least one input.");
+AddGoldPlugin(ToolChain, Args, CmdArgs, Output, Inputs[0],
+  D.getLTOMode() == LTOK_Thin);
+
+// Pass the features to linker.
+std::vector Features;
+riscv::getRISCVTargetFeatures(D, Args, Features);
+
+// Find the last of each feature.
+llvm::StringMap LastOpt;
+for (unsigned I = 0, N = Features.size(); I < N; ++I) {
+  StringRef Name = Features[I];
+  assert(Name[0] == '-' || Name[0] == '+');
+  LastOpt[Name.drop_front(1)] = I;
+}
+
+for (unsigned I = 0, N = Features.size(); I < N; ++I) {
+  // If this feature was overridden,
+  // ignore it.
+  StringRef Name = Features[I];
+  llvm::StringMap::iterator LastI =
+  LastOpt.find(Name.drop_front(1));
+  assert(LastI != LastOpt.end());
+  unsigned Last = LastI->second;
+  if (Last != I)
+continue;
+
+  CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=--"
+ "mattr=") +
+   Name));
+}
+
+// Pass the ABIName to linker.
+StringRef ABIName = tools::riscv::getRISCVABI(Args, ToolChain.getTriple());
+CmdArgs.push_back(Args.MakeArgString(Twine("-plugin-opt=-target-"
+   "abi=") +
+ ABIName));
+  }
+
   bool WantCRTs =
   !Args.hasArg(options::OPT_nostdlib, options::OPT_nostartfiles);
 


Index: clang/test/Driver/gold-lto.c
===
--- clang/test/Driver/gold-lto.c
+++ clang/test/Driver/gold-lto.c
@@ -26,3 +26,11 @@
 // RUN: %clang -target i686-linux-android -### %t.o -flto 2>&1 \
 // RUN: | FileCheck %s --check-prefix=CHECK-X86-ANDROID
 // CHECK-X86-ANDROID: "-plugin" "{{.*}}{{[/\\]}}LLVMgold.{{dll|dylib|so}}"
+//
+// RUN: %clang -target riscv64-unknown-elf -### %t.o -flto 2>&1 \
+// RUN: -march=rv64imf -mabi=lp64f \
+// RUN: | FileCheck %s --check-prefix=CHECK-RISCV
+// CHECK-RISCV: "-plugin-opt=--mattr=+m"
+// CHECK-RISCV: "-plugin-opt=--mattr=+f"
+// CHECK-RISCV: "-plugin-opt=--mattr=+relax"
+// CHECK-RISCV: "-plugin-opt=-target-abi=lp64f"
Index: clang/lib/Driver/ToolChains/RISCVToolchain.h
===

[PATCH] D67058: [clang][CodeGen] Add alias for cpu_dispatch function with IFunc & Fix resolver linkage type

[Sr.Zhang via Phabricator via cfe-commits]

zsrkmyn marked 18 inline comments as done.
zsrkmyn added a comment.

All done IMO. :-)


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

https://reviews.llvm.org/D67058



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

[PATCH] D64146: [Clang Interpreter] Initial patch for the constexpr interpreter

[Nandor Licker via Phabricator via cfe-commits]

nand added a comment.

Totally missed that - thanks for noticing. I must have forgotten to remove 
stuff from the header since clang/gcc don't warn about it.
I'll get hold of a Windows machine soon-ish and I'll make sure to fix this 
problem.
Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D64146



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

[PATCH] D67058: [clang][CodeGen] Add alias for cpu_dispatch function with IFunc & Fix resolver linkage type

[Sr.Zhang via Phabricator via cfe-commits]

zsrkmyn updated this revision to Diff 219568.

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

https://reviews.llvm.org/D67058

Files:
  clang/lib/CodeGen/CodeGenModule.cpp
  clang/test/CodeGen/attr-cpuspecific.c
  clang/test/CodeGen/attr-target-mv-func-ptrs.c
  clang/test/CodeGen/attr-target-mv-va-args.c
  clang/test/CodeGen/attr-target-mv.c
  clang/test/CodeGenCXX/attr-cpuspecific.cpp
  clang/test/CodeGenCXX/attr-target-mv-diff-ns.cpp
  clang/test/CodeGenCXX/attr-target-mv-inalloca.cpp
  clang/test/CodeGenCXX/attr-target-mv-member-funcs.cpp
  clang/test/CodeGenCXX/attr-target-mv-modules.cpp
  clang/test/CodeGenCXX/attr-target-mv-out-of-line-defs.cpp
  clang/test/CodeGenCXX/attr-target-mv-overloads.cpp

Index: clang/test/CodeGenCXX/attr-target-mv-overloads.cpp
===
--- clang/test/CodeGenCXX/attr-target-mv-overloads.cpp
+++ clang/test/CodeGenCXX/attr-target-mv-overloads.cpp
@@ -14,8 +14,8 @@
   return foo_overload() + foo_overload(1);
 }
 
-// LINUX: @_Z12foo_overloadv.ifunc = ifunc i32 (), i32 ()* ()* @_Z12foo_overloadv.resolver
-// LINUX: @_Z12foo_overloadi.ifunc = ifunc i32 (i32), i32 (i32)* ()* @_Z12foo_overloadi.resolver
+// LINUX: @_Z12foo_overloadv.ifunc = weak_odr ifunc i32 (), i32 ()* ()* @_Z12foo_overloadv.resolver
+// LINUX: @_Z12foo_overloadi.ifunc = weak_odr ifunc i32 (i32), i32 (i32)* ()* @_Z12foo_overloadi.resolver
 
 // LINUX: define i32 @_Z12foo_overloadi.sse4.2(i32 %0)
 // LINUX: ret i32 0
@@ -51,25 +51,25 @@
 // WINDOWS: call i32 @"?foo_overload@@YAHXZ.resolver"()
 // WINDOWS: call i32 @"?foo_overload@@YAHH@Z.resolver"(i32 1)
 
-// LINUX: define i32 ()* @_Z12foo_overloadv.resolver() comdat
+// LINUX: define weak_odr i32 ()* @_Z12foo_overloadv.resolver() comdat
 // LINUX: ret i32 ()* @_Z12foo_overloadv.arch_sandybridge
 // LINUX: ret i32 ()* @_Z12foo_overloadv.arch_ivybridge
 // LINUX: ret i32 ()* @_Z12foo_overloadv.sse4.2
 // LINUX: ret i32 ()* @_Z12foo_overloadv
 
-// WINDOWS: define dso_local i32 @"?foo_overload@@YAHXZ.resolver"() comdat
+// WINDOWS: define weak_odr dso_local i32 @"?foo_overload@@YAHXZ.resolver"() comdat
 // WINDOWS: call i32 @"?foo_overload@@YAHXZ.arch_sandybridge"
 // WINDOWS: call i32 @"?foo_overload@@YAHXZ.arch_ivybridge"
 // WINDOWS: call i32 @"?foo_overload@@YAHXZ.sse4.2"
 // WINDOWS: call i32 @"?foo_overload@@YAHXZ"
 
-// LINUX: define i32 (i32)* @_Z12foo_overloadi.resolver() comdat
+// LINUX: define weak_odr i32 (i32)* @_Z12foo_overloadi.resolver() comdat
 // LINUX: ret i32 (i32)* @_Z12foo_overloadi.arch_sandybridge
 // LINUX: ret i32 (i32)* @_Z12foo_overloadi.arch_ivybridge
 // LINUX: ret i32 (i32)* @_Z12foo_overloadi.sse4.2
 // LINUX: ret i32 (i32)* @_Z12foo_overloadi
 
-// WINDOWS: define dso_local i32 @"?foo_overload@@YAHH@Z.resolver"(i32 %0) comdat
+// WINDOWS: define weak_odr dso_local i32 @"?foo_overload@@YAHH@Z.resolver"(i32 %0) comdat
 // WINDOWS: call i32 @"?foo_overload@@YAHH@Z.arch_sandybridge"
 // WINDOWS: call i32 @"?foo_overload@@YAHH@Z.arch_ivybridge"
 // WINDOWS: call i32 @"?foo_overload@@YAHH@Z.sse4.2"
Index: clang/test/CodeGenCXX/attr-target-mv-out-of-line-defs.cpp
===
--- clang/test/CodeGenCXX/attr-target-mv-out-of-line-defs.cpp
+++ clang/test/CodeGenCXX/attr-target-mv-out-of-line-defs.cpp
@@ -16,7 +16,7 @@
   return s.foo(0);
 }
 
-// LINUX: @_ZN1S3fooEi.ifunc = ifunc i32 (%struct.S*, i32), i32 (%struct.S*, i32)* ()* @_ZN1S3fooEi.resolver
+// LINUX: @_ZN1S3fooEi.ifunc = weak_odr ifunc i32 (%struct.S*, i32), i32 (%struct.S*, i32)* ()* @_ZN1S3fooEi.resolver
 
 // LINUX: define i32 @_ZN1S3fooEi(%struct.S* %this, i32 %0)
 // LINUX: ret i32 2
@@ -44,13 +44,13 @@
 // WINDOWS: %s = alloca %struct.S, align 1
 // WINDOWS: %call = call i32 @"?foo@S@@QEAAHH@Z.resolver"(%struct.S* %s, i32 0)
 
-// LINUX: define i32 (%struct.S*, i32)* @_ZN1S3fooEi.resolver() comdat
+// LINUX: define weak_odr i32 (%struct.S*, i32)* @_ZN1S3fooEi.resolver() comdat
 // LINUX: ret i32 (%struct.S*, i32)* @_ZN1S3fooEi.arch_sandybridge
 // LINUX: ret i32 (%struct.S*, i32)* @_ZN1S3fooEi.arch_ivybridge
 // LINUX: ret i32 (%struct.S*, i32)* @_ZN1S3fooEi.sse4.2
 // LINUX: ret i32 (%struct.S*, i32)* @_ZN1S3fooEi
 
-// WINDOWS: define dso_local i32 @"?foo@S@@QEAAHH@Z.resolver"(%struct.S* %0, i32 %1) comdat
+// WINDOWS: define weak_odr dso_local i32 @"?foo@S@@QEAAHH@Z.resolver"(%struct.S* %0, i32 %1) comdat
 // WINDOWS: call i32 @"?foo@S@@QEAAHH@Z.arch_sandybridge"(%struct.S* %0, i32 %1)
 // WINDOWS: call i32 @"?foo@S@@QEAAHH@Z.arch_ivybridge"(%struct.S* %0, i32 %1)
 // WINDOWS: call i32 @"?foo@S@@QEAAHH@Z.sse4.2"(%struct.S* %0, i32 %1)
Index: clang/test/CodeGenCXX/attr-target-mv-modules.cpp
===
--- clang/test/CodeGenCXX/attr-target-mv-modules.cpp
+++ clang/test/CodeGenCXX/attr-target-mv-modules.cpp
@@ -22,7 +22,7 @@
 void g() { f(); }
 
 // Negative tests to validate that the 

[PATCH] D67140: [analyzer][NFC] Fix inconsistent references to checkers as "checks"

[Artem Dergachev via Phabricator via cfe-commits]

NoQ added a comment.

In D67140#1664406 , @gribozavr wrote:

> %select




In D67140#1664921 , @aaron.ballman 
wrote:

> `%select{}`


Whoa, this could actually work then. I like it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67140



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

[PATCH] D67140: [analyzer][NFC] Fix inconsistent references to checkers as "checks"

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D67140#1664406 , @gribozavr wrote:

> In D67140#1664106 , @NoQ wrote:
>
> > In D67140#1659982 , @gribozavr 
> > wrote:
> >
> > > We should take a page from desktop software here. If the messages were in 
> > > a separate file, there would be a lot of people capable of mass-editing 
> > > them. When messages are hardcoded in the tool code, navigating and 
> > > editing them requires more skill, and definitely a lot more jumping 
> > > around.
> >
> >
> > In the Static Analyzer there's often an explosive amount of dynamically 
> > generated messages that are going to be pretty hard to stuff into a 
> > tablegen pattern. Say, you can probably turn this 
> > 
> >  into "`%0 %1 %2 with a %3 retain count into an out parameter %4%5`" but 
> > would it really help?
>
>
> Unfortunately, that message is already not following best practices. One 
> should not be passing snippets in natural language into substitutions. Every 
> character that is a natural language construct should be in the message 
> string. The only allowed substitutions are types, names, numbers and such. We 
> already support %select in message strings, but there are frameworks that are 
> more flexible -- we can port features from them into our message strings as 
> needed.


I think this is a great goal. Clang doesn't always use `%select{}` to best 
effect (sometimes we still pass in hard-coded strings), but that's the 
exception rather than the rule.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67140



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

[PATCH] D67058: [clang][CodeGen] Add alias for cpu_dispatch function with IFunc & Fix resolver linkage type

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:3002
 false);
 llvm::Constant *Resolver = GetOrCreateLLVMFunction(
 MangledName + ".resolver", ResolverType, GlobalDecl{},

zsrkmyn wrote:
> erichkeane wrote:
> > zsrkmyn wrote:
> > > erichkeane wrote:
> > > > zsrkmyn wrote:
> > > > > erichkeane wrote:
> > > > > > zsrkmyn wrote:
> > > > > > > zsrkmyn wrote:
> > > > > > > > erichkeane wrote:
> > > > > > > > > zsrkmyn wrote:
> > > > > > > > > > erichkeane wrote:
> > > > > > > > > > > This Resolver should have the same linkage as below.
> > > > > > > > > > Actually, I wanted to set linkage here at the first time, 
> > > > > > > > > > but failed. When compiling code with cpu_specific but no 
> > > > > > > > > > cpu_dispatch, we cannot set it as LinkOnceODR or WeakODR. 
> > > > > > > > > > E.g.:
> > > > > > > > > > 
> > > > > > > > > > ```
> > > > > > > > > > $ cat specific_only.c
> > > > > > > > > > __declspec(cpu_specific(pentium_iii))
> > > > > > > > > > int foo(void) { return 0; }
> > > > > > > > > > int usage() { return foo(); }
> > > > > > > > > > 
> > > > > > > > > > $ clang -fdeclspec specific_only.c  
> > > > > > > > > >
> > > > > > > > > > Global is external, but doesn't have external or weak 
> > > > > > > > > > linkage!
> > > > > > > > > > 
> > > > > > > > > > i32 ()* ()* @foo.resolver   
> > > > > > > > > > 
> > > > > > > > > >   
> > > > > > > > > > fatal error: error in backend: Broken module found, 
> > > > > > > > > > compilation aborted!   
> > > > > > > > > > ```
> > > > > > > > > > 
> > > > > > > > > > This is found by lit test test/CodeGen/attr-cpuspecific.c, 
> > > > > > > > > > in which 'SingleVersion()' doesn't have a cpu_dispatch 
> > > > > > > > > > declaration.
> > > > > > > > > The crash message is complaining it isn't external/weak.  
> > > > > > > > > However, WeakODR should count, right?  Can you look into it a 
> > > > > > > > > bit more to see what it thinks is broken?
> > > > > > > > No, actually I've tried it earlier with the example I mentioned 
> > > > > > > > in my last comment, but WeakODR still makes compiler 
> > > > > > > > complaining. I think it's `foo.resolver` that cannot be 
> > > > > > > > declared with as WeakODR/LinkOnceODR without definition. But 
> > > > > > > > I'm really not familiar with these rules.
> > > > > > > According to the `Verifier::visitGlobalValue()` in Verify.cpp, an 
> > > > > > > declaration can only be `ExternalLinkage` or 
> > > > > > > `ExternalWeakLinkage`. So I still believe we cannot set the 
> > > > > > > resolver to `LinkOnceODRLinkage/WeakODRLinkage` here, as they are 
> > > > > > > declared but not defined when we only have `cpu_specified` but no 
> > > > > > > `cpu_dispatch` in a TU as the example above.
> > > > > > That doesn't seem right then.  IF it allows ExternalWeakLinkage I'd 
> > > > > > expect WeakODR to work as well, since it is essentially the same 
> > > > > > thing.
> > > > > I think we should have a double check. It is said "It is illegal for 
> > > > > a function declaration to have any linkage type other than `external` 
> > > > > or `extern_weak`" at the last line of section Linkage Type in the 
> > > > > reference manual [1]. I guess `weak_odr` is not designed for 
> > > > > declaration purpose and should be only used by definition.
> > > > > 
> > > > > [1] https://llvm.org/docs/LangRef.html#linkage-types
> > > > I had typed a reply, but apparently it didn't submit: Ah, nvm, I see 
> > > > now that external-weak is different from weak.
> > > > 
> > > > I don't really get the linkages sufficiently to know what the right 
> > > > thing to do is then.  If we DO have a definition, I'd say weak_odr so 
> > > > it can be merged, right?  If we do NOT, could externally_available work?
> > > No, I think it should be `external` instead of `available_externally`. 
> > > The later cannot used for declaration as well.
> > > 
> > > So, getting back to the example, **1)** if we have `cpu_dispatch` and 
> > > `cpu_specific` in same TU, it's okay to use `weak_odr` for `foo.resolver` 
> > > as it is defined when `emitCPUDispatchDefinition` and it can be merged. 
> > > **2)** If we only have `cpu_specific` in a TU and have a reference to the 
> > > dispatched function, `foo.resolver` will be referenced without 
> > > definition, and `external` is the proper linkage to make it work.
> > > 
> > > That's why I didn't set linkage type at this line.
> > > No, I think it should be external instead of available_externally. The 
> > > later cannot used for declaration as well.
> > 
> > Wouldn't that make it un-mergable later?  Meaning, if you emitted the 
> > declaration from one TU, and the definition from another that you'd get a 
> > link error?
> > 

[PATCH] D67058: [clang][CodeGen] Add alias for cpu_dispatch function with IFunc & Fix resolver linkage type

[Sr.Zhang via Phabricator via cfe-commits]

zsrkmyn added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:3002
 false);
 llvm::Constant *Resolver = GetOrCreateLLVMFunction(
 MangledName + ".resolver", ResolverType, GlobalDecl{},

erichkeane wrote:
> zsrkmyn wrote:
> > erichkeane wrote:
> > > zsrkmyn wrote:
> > > > erichkeane wrote:
> > > > > zsrkmyn wrote:
> > > > > > zsrkmyn wrote:
> > > > > > > erichkeane wrote:
> > > > > > > > zsrkmyn wrote:
> > > > > > > > > erichkeane wrote:
> > > > > > > > > > This Resolver should have the same linkage as below.
> > > > > > > > > Actually, I wanted to set linkage here at the first time, but 
> > > > > > > > > failed. When compiling code with cpu_specific but no 
> > > > > > > > > cpu_dispatch, we cannot set it as LinkOnceODR or WeakODR. 
> > > > > > > > > E.g.:
> > > > > > > > > 
> > > > > > > > > ```
> > > > > > > > > $ cat specific_only.c
> > > > > > > > > __declspec(cpu_specific(pentium_iii))
> > > > > > > > > int foo(void) { return 0; }
> > > > > > > > > int usage() { return foo(); }
> > > > > > > > > 
> > > > > > > > > $ clang -fdeclspec specific_only.c
> > > > > > > > >  
> > > > > > > > > Global is external, but doesn't have external or weak 
> > > > > > > > > linkage!  
> > > > > > > > >   
> > > > > > > > > i32 ()* ()* @foo.resolver 
> > > > > > > > >   
> > > > > > > > >   
> > > > > > > > > fatal error: error in backend: Broken module found, 
> > > > > > > > > compilation aborted!   
> > > > > > > > > ```
> > > > > > > > > 
> > > > > > > > > This is found by lit test test/CodeGen/attr-cpuspecific.c, in 
> > > > > > > > > which 'SingleVersion()' doesn't have a cpu_dispatch 
> > > > > > > > > declaration.
> > > > > > > > The crash message is complaining it isn't external/weak.  
> > > > > > > > However, WeakODR should count, right?  Can you look into it a 
> > > > > > > > bit more to see what it thinks is broken?
> > > > > > > No, actually I've tried it earlier with the example I mentioned 
> > > > > > > in my last comment, but WeakODR still makes compiler complaining. 
> > > > > > > I think it's `foo.resolver` that cannot be declared with as 
> > > > > > > WeakODR/LinkOnceODR without definition. But I'm really not 
> > > > > > > familiar with these rules.
> > > > > > According to the `Verifier::visitGlobalValue()` in Verify.cpp, an 
> > > > > > declaration can only be `ExternalLinkage` or `ExternalWeakLinkage`. 
> > > > > > So I still believe we cannot set the resolver to 
> > > > > > `LinkOnceODRLinkage/WeakODRLinkage` here, as they are declared but 
> > > > > > not defined when we only have `cpu_specified` but no `cpu_dispatch` 
> > > > > > in a TU as the example above.
> > > > > That doesn't seem right then.  IF it allows ExternalWeakLinkage I'd 
> > > > > expect WeakODR to work as well, since it is essentially the same 
> > > > > thing.
> > > > I think we should have a double check. It is said "It is illegal for a 
> > > > function declaration to have any linkage type other than `external` or 
> > > > `extern_weak`" at the last line of section Linkage Type in the 
> > > > reference manual [1]. I guess `weak_odr` is not designed for 
> > > > declaration purpose and should be only used by definition.
> > > > 
> > > > [1] https://llvm.org/docs/LangRef.html#linkage-types
> > > I had typed a reply, but apparently it didn't submit: Ah, nvm, I see now 
> > > that external-weak is different from weak.
> > > 
> > > I don't really get the linkages sufficiently to know what the right thing 
> > > to do is then.  If we DO have a definition, I'd say weak_odr so it can be 
> > > merged, right?  If we do NOT, could externally_available work?
> > No, I think it should be `external` instead of `available_externally`. The 
> > later cannot used for declaration as well.
> > 
> > So, getting back to the example, **1)** if we have `cpu_dispatch` and 
> > `cpu_specific` in same TU, it's okay to use `weak_odr` for `foo.resolver` 
> > as it is defined when `emitCPUDispatchDefinition` and it can be merged. 
> > **2)** If we only have `cpu_specific` in a TU and have a reference to the 
> > dispatched function, `foo.resolver` will be referenced without definition, 
> > and `external` is the proper linkage to make it work.
> > 
> > That's why I didn't set linkage type at this line.
> > No, I think it should be external instead of available_externally. The 
> > later cannot used for declaration as well.
> 
> Wouldn't that make it un-mergable later?  Meaning, if you emitted the 
> declaration from one TU, and the definition from another that you'd get a 
> link error?
> 
> I think the rules are more subtle than that.  Any time you have a 
> `cpu_dispatch`, the resolver is weak_odr so that it can be merged later.  The 
> presence of `cpu_specific` 

[PATCH] D67405: Make FormatToken::Type private.

[Manuel Klimek via Phabricator via cfe-commits]

klimek created this revision.
klimek added a reviewer: sammccall.
Herald added a project: clang.

This enables us to intercept changes to the token type via setType(), which
is a precondition for being able to use multi-pass formatting for macro
arguments.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D67405

Files:
  clang/lib/Format/Format.cpp
  clang/lib/Format/FormatToken.cpp
  clang/lib/Format/FormatToken.h
  clang/lib/Format/FormatTokenLexer.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/lib/Format/UnwrappedLineParser.cpp

Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -327,9 +327,9 @@
   bool SwitchLabelEncountered = false;
   do {
 tok::TokenKind kind = FormatTok->Tok.getKind();
-if (FormatTok->Type == TT_MacroBlockBegin) {
+if (FormatTok->getType() == TT_MacroBlockBegin) {
   kind = tok::l_brace;
-} else if (FormatTok->Type == TT_MacroBlockEnd) {
+} else if (FormatTok->getType() == TT_MacroBlockEnd) {
   kind = tok::r_brace;
 }
 
@@ -984,11 +984,11 @@
   case tok::kw_asm:
 nextToken();
 if (FormatTok->is(tok::l_brace)) {
-  FormatTok->Type = TT_InlineASMBrace;
+  FormatTok->setType(TT_InlineASMBrace);
   nextToken();
   while (FormatTok && FormatTok->isNot(tok::eof)) {
 if (FormatTok->is(tok::r_brace)) {
-  FormatTok->Type = TT_InlineASMBrace;
+  FormatTok->setType(TT_InlineASMBrace);
   nextToken();
   addUnwrappedLine();
   break;
@@ -1279,7 +1279,7 @@
 // for them (the one we know is missing are lambdas).
 if (Style.BraceWrapping.AfterFunction)
   addUnwrappedLine();
-FormatTok->Type = TT_FunctionLBrace;
+FormatTok->setType(TT_FunctionLBrace);
 parseBlock(/*MustBeDeclaration=*/false);
 addUnwrappedLine();
 return;
@@ -1483,7 +1483,7 @@
   // This might or might not actually be a lambda arrow (this could be an
   // ObjC method invocation followed by a dereferencing arrow). We might
   // reset this back to TT_Unknown in TokenAnnotator.
-  FormatTok->Type = TT_LambdaArrow;
+  FormatTok->setType(TT_LambdaArrow);
   SeenArrow = true;
   nextToken();
   break;
@@ -1491,8 +1491,8 @@
   return true;
 }
   }
-  FormatTok->Type = TT_LambdaLBrace;
-  LSquare.Type = TT_LambdaLSquare;
+  FormatTok->setType(TT_LambdaLBrace);
+  LSquare.setType(TT_LambdaLSquare);
   parseChildBlock();
   return true;
 }
@@ -1525,7 +1525,7 @@
 
   // Consume * (generator function). Treat it like C++'s overloaded operators.
   if (FormatTok->is(tok::star)) {
-FormatTok->Type = TT_OverloadedOperator;
+FormatTok->setType(TT_OverloadedOperator);
 nextToken();
   }
 
@@ -2440,8 +2440,8 @@
 E = Line.Tokens.end();
I != E; ++I) {
 llvm::dbgs() << I->Tok->Tok.getName() << "["
- << "T=" << I->Tok->Type << ", OC=" << I->Tok->OriginalColumn
- << "] ";
+ << "T=" << I->Tok->getType()
+ << ", OC=" << I->Tok->OriginalColumn << "] ";
   }
   for (std::list::const_iterator I = Line.Tokens.begin(),
 E = Line.Tokens.end();
@@ -2711,14 +2711,14 @@
   flushComments(isOnNewLine(*FormatTok));
   parsePPDirective();
 }
-while (FormatTok->Type == TT_ConflictStart ||
-   FormatTok->Type == TT_ConflictEnd ||
-   FormatTok->Type == TT_ConflictAlternative) {
-  if (FormatTok->Type == TT_ConflictStart) {
+while (FormatTok->getType() == TT_ConflictStart ||
+   FormatTok->getType() == TT_ConflictEnd ||
+   FormatTok->getType() == TT_ConflictAlternative) {
+  if (FormatTok->getType() == TT_ConflictStart) {
 conditionalCompilationStart(/*Unreachable=*/false);
-  } else if (FormatTok->Type == TT_ConflictAlternative) {
+  } else if (FormatTok->getType() == TT_ConflictAlternative) {
 conditionalCompilationAlternative();
-  } else if (FormatTok->Type == TT_ConflictEnd) {
+  } else if (FormatTok->getType() == TT_ConflictEnd) {
 conditionalCompilationEnd();
   }
   FormatTok = Tokens->getNextToken();
Index: clang/lib/Format/TokenAnnotator.cpp
===
--- clang/lib/Format/TokenAnnotator.cpp
+++ clang/lib/Format/TokenAnnotator.cpp
@@ -102,9 +102,9 @@
 if (Style.Language == FormatStyle::LK_TextProto ||
 (Style.Language == FormatStyle::LK_Proto && Left->Previous &&
  Left->Previous->isOneOf(TT_SelectorName, TT_DictLiteral)))
-  CurrentToken->Type = TT_DictLiteral;
+  CurrentToken->setType(TT_DictLiteral);
 else
-  CurrentToken->Type = TT_TemplateCloser;
+  

[PATCH] D67399: [ARM] Follow AACPS standard for volatile bitfields

[JF Bastien via Phabricator via cfe-commits]

jfb added inline comments.



Comment at: clang/test/CodeGen/aapcs-bitfield.c:541
 // BE-NEXT:[[TMP0:%.*]] = getelementptr inbounds [[STRUCT_ST9:%.*]], 
%struct.st9* [[M:%.*]], i32 0, i32 0
+// BE-NEXT:[[BF_LOAD:%.*]] = load volatile i8, i8* [[TMP0]], align 4
 // BE-NEXT:store volatile i8 1, i8* [[TMP0]], align 4

These are just extra loads? Why?



Comment at: clang/test/CodeGen/aapcs-bitfield.c:552
 // LE-NEXT:[[TMP0:%.*]] = getelementptr inbounds [[STRUCT_ST9:%.*]], 
%struct.st9* [[M:%.*]], i32 0, i32 0
 // LE-NEXT:[[BF_LOAD:%.*]] = load volatile i8, i8* [[TMP0]], align 4
 // LE-NEXT:[[INC:%.*]] = add i8 [[BF_LOAD]], 1

Why isn't this load sufficient?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67399



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

[PATCH] D67373: Don't emit .gnu_pubnames when tuning for LLDB

[Phabricator via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL371530: Dont emit .gnu_pubnames when tuning for LLDB. 
(authored by adrian, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67373?vs=219437=219553#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67373

Files:
  cfe/trunk/lib/Driver/ToolChains/Clang.cpp
  cfe/trunk/test/Driver/debug-options.c


Index: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp
@@ -3397,7 +3397,6 @@
   Args.getLastArg(options::OPT_ggnu_pubnames, 
options::OPT_gno_gnu_pubnames,
   options::OPT_gpubnames, options::OPT_gno_pubnames);
   if (DwarfFission != DwarfFissionKind::None ||
-  DebuggerTuning == llvm::DebuggerKind::LLDB ||
   (PubnamesArg && checkDebugInfoOption(PubnamesArg, Args, D, TC)))
 if (!PubnamesArg ||
 (!PubnamesArg->getOption().matches(options::OPT_gno_gnu_pubnames) &&
Index: cfe/trunk/test/Driver/debug-options.c
===
--- cfe/trunk/test/Driver/debug-options.c
+++ cfe/trunk/test/Driver/debug-options.c
@@ -197,7 +197,7 @@
 // RUN: %clang -### -c %s 2>&1 | FileCheck -check-prefix=NORNGBSE %s
 // RUN: %clang -### -c -fdebug-ranges-base-address 
-fno-debug-ranges-base-address %s 2>&1 | FileCheck -check-prefix=NORNGBSE %s
 //
-// RUN: %clang -### -c -glldb %s 2>&1 | FileCheck -check-prefix=GPUB %s
+// RUN: %clang -### -c -glldb %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 // RUN: %clang -### -c -glldb -gno-pubnames %s 2>&1 | FileCheck 
-check-prefix=NOPUB %s
 //
 // RUN: %clang -### -c -gdwarf-aranges %s 2>&1 | FileCheck 
-check-prefix=GARANGE %s


Index: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp
@@ -3397,7 +3397,6 @@
   Args.getLastArg(options::OPT_ggnu_pubnames, options::OPT_gno_gnu_pubnames,
   options::OPT_gpubnames, options::OPT_gno_pubnames);
   if (DwarfFission != DwarfFissionKind::None ||
-  DebuggerTuning == llvm::DebuggerKind::LLDB ||
   (PubnamesArg && checkDebugInfoOption(PubnamesArg, Args, D, TC)))
 if (!PubnamesArg ||
 (!PubnamesArg->getOption().matches(options::OPT_gno_gnu_pubnames) &&
Index: cfe/trunk/test/Driver/debug-options.c
===
--- cfe/trunk/test/Driver/debug-options.c
+++ cfe/trunk/test/Driver/debug-options.c
@@ -197,7 +197,7 @@
 // RUN: %clang -### -c %s 2>&1 | FileCheck -check-prefix=NORNGBSE %s
 // RUN: %clang -### -c -fdebug-ranges-base-address -fno-debug-ranges-base-address %s 2>&1 | FileCheck -check-prefix=NORNGBSE %s
 //
-// RUN: %clang -### -c -glldb %s 2>&1 | FileCheck -check-prefix=GPUB %s
+// RUN: %clang -### -c -glldb %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 // RUN: %clang -### -c -glldb -gno-pubnames %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 //
 // RUN: %clang -### -c -gdwarf-aranges %s 2>&1 | FileCheck -check-prefix=GARANGE %s
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r371530 - Don't emit .gnu_pubnames when tuning for LLDB.

[Adrian Prantl via cfe-commits]

Author: adrian
Date: Tue Sep 10 08:53:18 2019
New Revision: 371530

URL: http://llvm.org/viewvc/llvm-project?rev=371530=rev
Log:
Don't emit .gnu_pubnames when tuning for LLDB.

LLDB reads the various .apple* accelerator tables (and in the near
future: the DWARF 5 accelerator tables) which should make
.gnu_pubnames redundant. This changes the Clang driver to no longer
pass -ggnu-pubnames when tuning for LLDB.

Thanks to David Blaikie for pointing this out!
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190422/thread.html#646062

rdar://problem/50142073

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

Modified:
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/test/Driver/debug-options.c

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=371530=371529=371530=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Tue Sep 10 08:53:18 2019
@@ -3397,7 +3397,6 @@ static void RenderDebugOptions(const Too
   Args.getLastArg(options::OPT_ggnu_pubnames, 
options::OPT_gno_gnu_pubnames,
   options::OPT_gpubnames, options::OPT_gno_pubnames);
   if (DwarfFission != DwarfFissionKind::None ||
-  DebuggerTuning == llvm::DebuggerKind::LLDB ||
   (PubnamesArg && checkDebugInfoOption(PubnamesArg, Args, D, TC)))
 if (!PubnamesArg ||
 (!PubnamesArg->getOption().matches(options::OPT_gno_gnu_pubnames) &&

Modified: cfe/trunk/test/Driver/debug-options.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/debug-options.c?rev=371530=371529=371530=diff
==
--- cfe/trunk/test/Driver/debug-options.c (original)
+++ cfe/trunk/test/Driver/debug-options.c Tue Sep 10 08:53:18 2019
@@ -197,7 +197,7 @@
 // RUN: %clang -### -c %s 2>&1 | FileCheck -check-prefix=NORNGBSE %s
 // RUN: %clang -### -c -fdebug-ranges-base-address 
-fno-debug-ranges-base-address %s 2>&1 | FileCheck -check-prefix=NORNGBSE %s
 //
-// RUN: %clang -### -c -glldb %s 2>&1 | FileCheck -check-prefix=GPUB %s
+// RUN: %clang -### -c -glldb %s 2>&1 | FileCheck -check-prefix=NOPUB %s
 // RUN: %clang -### -c -glldb -gno-pubnames %s 2>&1 | FileCheck 
-check-prefix=NOPUB %s
 //
 // RUN: %clang -### -c -gdwarf-aranges %s 2>&1 | FileCheck 
-check-prefix=GARANGE %s


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

[PATCH] D67058: [clang][CodeGen] Add alias for cpu_dispatch function with IFunc & Fix resolver linkage type

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:3002
 false);
 llvm::Constant *Resolver = GetOrCreateLLVMFunction(
 MangledName + ".resolver", ResolverType, GlobalDecl{},

zsrkmyn wrote:
> erichkeane wrote:
> > zsrkmyn wrote:
> > > erichkeane wrote:
> > > > zsrkmyn wrote:
> > > > > zsrkmyn wrote:
> > > > > > erichkeane wrote:
> > > > > > > zsrkmyn wrote:
> > > > > > > > erichkeane wrote:
> > > > > > > > > This Resolver should have the same linkage as below.
> > > > > > > > Actually, I wanted to set linkage here at the first time, but 
> > > > > > > > failed. When compiling code with cpu_specific but no 
> > > > > > > > cpu_dispatch, we cannot set it as LinkOnceODR or WeakODR. E.g.:
> > > > > > > > 
> > > > > > > > ```
> > > > > > > > $ cat specific_only.c
> > > > > > > > __declspec(cpu_specific(pentium_iii))
> > > > > > > > int foo(void) { return 0; }
> > > > > > > > int usage() { return foo(); }
> > > > > > > > 
> > > > > > > > $ clang -fdeclspec specific_only.c  
> > > > > > > >
> > > > > > > > Global is external, but doesn't have external or weak linkage!  
> > > > > > > >   
> > > > > > > > i32 ()* ()* @foo.resolver   
> > > > > > > >   
> > > > > > > > fatal error: error in backend: Broken module found, compilation 
> > > > > > > > aborted!   
> > > > > > > > ```
> > > > > > > > 
> > > > > > > > This is found by lit test test/CodeGen/attr-cpuspecific.c, in 
> > > > > > > > which 'SingleVersion()' doesn't have a cpu_dispatch declaration.
> > > > > > > The crash message is complaining it isn't external/weak.  
> > > > > > > However, WeakODR should count, right?  Can you look into it a bit 
> > > > > > > more to see what it thinks is broken?
> > > > > > No, actually I've tried it earlier with the example I mentioned in 
> > > > > > my last comment, but WeakODR still makes compiler complaining. I 
> > > > > > think it's `foo.resolver` that cannot be declared with as 
> > > > > > WeakODR/LinkOnceODR without definition. But I'm really not familiar 
> > > > > > with these rules.
> > > > > According to the `Verifier::visitGlobalValue()` in Verify.cpp, an 
> > > > > declaration can only be `ExternalLinkage` or `ExternalWeakLinkage`. 
> > > > > So I still believe we cannot set the resolver to 
> > > > > `LinkOnceODRLinkage/WeakODRLinkage` here, as they are declared but 
> > > > > not defined when we only have `cpu_specified` but no `cpu_dispatch` 
> > > > > in a TU as the example above.
> > > > That doesn't seem right then.  IF it allows ExternalWeakLinkage I'd 
> > > > expect WeakODR to work as well, since it is essentially the same thing.
> > > I think we should have a double check. It is said "It is illegal for a 
> > > function declaration to have any linkage type other than `external` or 
> > > `extern_weak`" at the last line of section Linkage Type in the reference 
> > > manual [1]. I guess `weak_odr` is not designed for declaration purpose 
> > > and should be only used by definition.
> > > 
> > > [1] https://llvm.org/docs/LangRef.html#linkage-types
> > I had typed a reply, but apparently it didn't submit: Ah, nvm, I see now 
> > that external-weak is different from weak.
> > 
> > I don't really get the linkages sufficiently to know what the right thing 
> > to do is then.  If we DO have a definition, I'd say weak_odr so it can be 
> > merged, right?  If we do NOT, could externally_available work?
> No, I think it should be `external` instead of `available_externally`. The 
> later cannot used for declaration as well.
> 
> So, getting back to the example, **1)** if we have `cpu_dispatch` and 
> `cpu_specific` in same TU, it's okay to use `weak_odr` for `foo.resolver` as 
> it is defined when `emitCPUDispatchDefinition` and it can be merged. **2)** 
> If we only have `cpu_specific` in a TU and have a reference to the dispatched 
> function, `foo.resolver` will be referenced without definition, and 
> `external` is the proper linkage to make it work.
> 
> That's why I didn't set linkage type at this line.
> No, I think it should be external instead of available_externally. The later 
> cannot used for declaration as well.

Wouldn't that make it un-mergable later?  Meaning, if you emitted the 
declaration from one TU, and the definition from another that you'd get a link 
error?

I think the rules are more subtle than that.  Any time you have a 
`cpu_dispatch`, the resolver is weak_odr so that it can be merged later.  The 
presence of `cpu_specific` shouldn't matter.

For 2, I think you're mostly correct, as long as the linker can still merge 
them.


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

https://reviews.llvm.org/D67058



___
cfe-commits mailing 

[PATCH] D67058: [clang][CodeGen] Add alias for cpu_dispatch function with IFunc & Fix resolver linkage type

[Sr.Zhang via Phabricator via cfe-commits]

zsrkmyn added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:3002
 false);
 llvm::Constant *Resolver = GetOrCreateLLVMFunction(
 MangledName + ".resolver", ResolverType, GlobalDecl{},

erichkeane wrote:
> zsrkmyn wrote:
> > erichkeane wrote:
> > > zsrkmyn wrote:
> > > > zsrkmyn wrote:
> > > > > erichkeane wrote:
> > > > > > zsrkmyn wrote:
> > > > > > > erichkeane wrote:
> > > > > > > > This Resolver should have the same linkage as below.
> > > > > > > Actually, I wanted to set linkage here at the first time, but 
> > > > > > > failed. When compiling code with cpu_specific but no 
> > > > > > > cpu_dispatch, we cannot set it as LinkOnceODR or WeakODR. E.g.:
> > > > > > > 
> > > > > > > ```
> > > > > > > $ cat specific_only.c
> > > > > > > __declspec(cpu_specific(pentium_iii))
> > > > > > > int foo(void) { return 0; }
> > > > > > > int usage() { return foo(); }
> > > > > > > 
> > > > > > > $ clang -fdeclspec specific_only.c
> > > > > > >  
> > > > > > > Global is external, but doesn't have external or weak linkage!
> > > > > > > 
> > > > > > > i32 ()* ()* @foo.resolver 
> > > > > > > 
> > > > > > > fatal error: error in backend: Broken module found, compilation 
> > > > > > > aborted!   
> > > > > > > ```
> > > > > > > 
> > > > > > > This is found by lit test test/CodeGen/attr-cpuspecific.c, in 
> > > > > > > which 'SingleVersion()' doesn't have a cpu_dispatch declaration.
> > > > > > The crash message is complaining it isn't external/weak.  However, 
> > > > > > WeakODR should count, right?  Can you look into it a bit more to 
> > > > > > see what it thinks is broken?
> > > > > No, actually I've tried it earlier with the example I mentioned in my 
> > > > > last comment, but WeakODR still makes compiler complaining. I think 
> > > > > it's `foo.resolver` that cannot be declared with as 
> > > > > WeakODR/LinkOnceODR without definition. But I'm really not familiar 
> > > > > with these rules.
> > > > According to the `Verifier::visitGlobalValue()` in Verify.cpp, an 
> > > > declaration can only be `ExternalLinkage` or `ExternalWeakLinkage`. So 
> > > > I still believe we cannot set the resolver to 
> > > > `LinkOnceODRLinkage/WeakODRLinkage` here, as they are declared but not 
> > > > defined when we only have `cpu_specified` but no `cpu_dispatch` in a TU 
> > > > as the example above.
> > > That doesn't seem right then.  IF it allows ExternalWeakLinkage I'd 
> > > expect WeakODR to work as well, since it is essentially the same thing.
> > I think we should have a double check. It is said "It is illegal for a 
> > function declaration to have any linkage type other than `external` or 
> > `extern_weak`" at the last line of section Linkage Type in the reference 
> > manual [1]. I guess `weak_odr` is not designed for declaration purpose and 
> > should be only used by definition.
> > 
> > [1] https://llvm.org/docs/LangRef.html#linkage-types
> I had typed a reply, but apparently it didn't submit: Ah, nvm, I see now that 
> external-weak is different from weak.
> 
> I don't really get the linkages sufficiently to know what the right thing to 
> do is then.  If we DO have a definition, I'd say weak_odr so it can be 
> merged, right?  If we do NOT, could externally_available work?
No, I think it should be `external` instead of `available_externally`. The 
later cannot used for declaration as well.

So, getting back to the example, **1)** if we have `cpu_dispatch` and 
`cpu_specific` in same TU, it's okay to use `weak_odr` for `foo.resolver` as it 
is defined when `emitCPUDispatchDefinition` and it can be merged. **2)** If we 
only have `cpu_specific` in a TU and have a reference to the dispatched 
function, `foo.resolver` will be referenced without definition, and `external` 
is the proper linkage to make it work.

That's why I didn't set linkage type at this line.


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

https://reviews.llvm.org/D67058



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

[PATCH] D67399: [ARM] Follow AACPS standard for volatile bitfields

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a comment.

In D67399#1664785 , @dnsampaio wrote:

> @ostannard might prove me wrong, but according to the AACPS:
>
>   When a volatile bit-field is written, and its container does not overlap 
> with any non-bit-field member, its
>container must be read exactly once and written exactly once using the 
> access width appropriate to the
>type of the container. The two accesses are not atomic.
>
> This rule does not define that the load is done if required. It states that 
> it will be read once. It even gives the example that an increment will always 
> perform two reads and one write, bitwidth agnostic. It writes just after:


While it can be read as "just always read volatile bitfield before overwriting 
it", i'm not sure that makes any sense.
Why exactly would you want do to that load, if you don't use it's results? What 
side-effects does it cause?

What it should be saying is: "when you have a bitfield, and you want to update 
several of it's fields but not all,
first do one read to get the old contents, then merge old-new data, and then 
perform a single store replacing the entire contents at once".
That is the only sane behavior it can require.

>   Note: Note the volatile access rules apply even when the width and 
> alignment of the bit-field imply that
>the access could be achieved more efficiently using a narrower type. For a 
> write operation the read must
>always occur even if the entire contents of the container will be replaced.
> 
> The rationale is to provide a uniform behavior for volatile bitfields 
> independent of their width (as far they do not overlap with non-bitfields).




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67399



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

[PATCH] D67399: [ARM] Follow AACPS standard for volatile bitfields

[Diogo N. Sampaio via Phabricator via cfe-commits]

dnsampaio added a comment.

@ostannard might prove me wrong, but according to the AACPS:

  When a volatile bit-field is written, and its container does not overlap with 
any non-bit-field member, its
  container must be read exactly once and written exactly once using the access 
width appropriate to the
  type of the container. The two accesses are not atomic.

This rule does not define that the load is done if required. It states that it 
will be read once. It even gives the example that an increment will always 
perform two reads and one write, bitwidth agnostic. It writes just after:

  Note: Note the volatile access rules apply even when the width and alignment 
of the bit-field imply that
  the access could be achieved more efficiently using a narrower type. For a 
write operation the read must
  always occur even if the entire contents of the container will be replaced.

The rationale is to provide a uniform behavior for volatile bitfields 
independent of their width (as far they do not overlap with non-bitfields).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67399



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

[PATCH] D67399: [ARM] Follow AACPS standard for volatile bitfields

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri resigned from this revision.
lebedev.ri added a reviewer: jfb.
lebedev.ri added a comment.
Herald added a subscriber: dexonsmith.

I'm not sure why i'm added as a reviewer here.

That being said i don't see why that load is needed there.
As i read it, the document only states that if load is needed,
then it must be a single load, likewise for store.
I.e. i'm not sure why it requires a load when it isn't needed.
Unlike atomics, volatiles don't enforce any ordering.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67399



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

[PATCH] D67399: [ARM] Follow AACPS standard for volatile bitfields

[Diogo N. Sampaio via Phabricator via cfe-commits]

dnsampaio added a comment.

This patch could hack clang to generate an extra load. However, my knowledge in 
the clang code base is not extensive. How could we ensure that the width of 
loads and stores are the size of the container, and  that they don't overlap 
non-bitfields?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67399



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

[PATCH] D67399: [ARM] Follow AACPS standard for volatile bitfields

[Diogo N. Sampaio via Phabricator via cfe-commits]

dnsampaio created this revision.
dnsampaio added reviewers: lebedev.ri, ostannard.
Herald added subscribers: cfe-commits, jfb, kristof.beyls.
Herald added a project: clang.

Bug 43264
This is a first draft to understand what has to be
done to fix volatale bitfield access, as to conform
to the AACPS


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D67399

Files:
  clang/lib/CodeGen/CGExpr.cpp
  clang/test/CodeGen/aapcs-bitfield.c


Index: clang/test/CodeGen/aapcs-bitfield.c
===
--- clang/test/CodeGen/aapcs-bitfield.c
+++ clang/test/CodeGen/aapcs-bitfield.c
@@ -531,12 +531,14 @@
 // LE-LABEL: @store_st9(
 // LE-NEXT:  entry:
 // LE-NEXT:[[TMP0:%.*]] = getelementptr inbounds [[STRUCT_ST9:%.*]], 
%struct.st9* [[M:%.*]], i32 0, i32 0
+// LE-NEXT:[[BF_LOAD:%.*]] = load volatile i8, i8* [[TMP0]], align 4
 // LE-NEXT:store volatile i8 1, i8* [[TMP0]], align 4
 // LE-NEXT:ret void
 //
 // BE-LABEL: @store_st9(
 // BE-NEXT:  entry:
 // BE-NEXT:[[TMP0:%.*]] = getelementptr inbounds [[STRUCT_ST9:%.*]], 
%struct.st9* [[M:%.*]], i32 0, i32 0
+// BE-NEXT:[[BF_LOAD:%.*]] = load volatile i8, i8* [[TMP0]], align 4
 // BE-NEXT:store volatile i8 1, i8* [[TMP0]], align 4
 // BE-NEXT:ret void
 //
@@ -549,6 +551,7 @@
 // LE-NEXT:[[TMP0:%.*]] = getelementptr inbounds [[STRUCT_ST9:%.*]], 
%struct.st9* [[M:%.*]], i32 0, i32 0
 // LE-NEXT:[[BF_LOAD:%.*]] = load volatile i8, i8* [[TMP0]], align 4
 // LE-NEXT:[[INC:%.*]] = add i8 [[BF_LOAD]], 1
+// LE-NEXT:[[BF_LOAD1:%.*]] = load volatile i8, i8* [[TMP0]], align 4
 // LE-NEXT:store volatile i8 [[INC]], i8* [[TMP0]], align 4
 // LE-NEXT:ret void
 //
@@ -557,6 +560,7 @@
 // BE-NEXT:[[TMP0:%.*]] = getelementptr inbounds [[STRUCT_ST9:%.*]], 
%struct.st9* [[M:%.*]], i32 0, i32 0
 // BE-NEXT:[[BF_LOAD:%.*]] = load volatile i8, i8* [[TMP0]], align 4
 // BE-NEXT:[[INC:%.*]] = add i8 [[BF_LOAD]], 1
+// BE-NEXT:[[BF_LOAD1:%.*]] = load volatile i8, i8* [[TMP0]], align 4
 // BE-NEXT:store volatile i8 [[INC]], i8* [[TMP0]], align 4
 // BE-NEXT:ret void
 //
@@ -667,12 +671,14 @@
 // LE-LABEL: @store_st11(
 // LE-NEXT:  entry:
 // LE-NEXT:[[F:%.*]] = getelementptr inbounds [[STRUCT_ST11:%.*]], 
%struct.st11* [[M:%.*]], i32 0, i32 1
+// LE-NEXT:[[BF_LOAD:%.*]] = load volatile i16, i16* [[F]], align 1
 // LE-NEXT:store volatile i16 1, i16* [[F]], align 1
 // LE-NEXT:ret void
 //
 // BE-LABEL: @store_st11(
 // BE-NEXT:  entry:
 // BE-NEXT:[[F:%.*]] = getelementptr inbounds [[STRUCT_ST11:%.*]], 
%struct.st11* [[M:%.*]], i32 0, i32 1
+// BE-NEXT:[[BF_LOAD:%.*]] = load volatile i16, i16* [[F]], align 1
 // BE-NEXT:store volatile i16 1, i16* [[F]], align 1
 // BE-NEXT:ret void
 //
@@ -685,6 +691,7 @@
 // LE-NEXT:[[F:%.*]] = getelementptr inbounds [[STRUCT_ST11:%.*]], 
%struct.st11* [[M:%.*]], i32 0, i32 1
 // LE-NEXT:[[BF_LOAD:%.*]] = load volatile i16, i16* [[F]], align 1
 // LE-NEXT:[[INC:%.*]] = add i16 [[BF_LOAD]], 1
+// LE-NEXT:[[BF_LOAD1:%.*]] = load volatile i16, i16* [[F]], align 1
 // LE-NEXT:store volatile i16 [[INC]], i16* [[F]], align 1
 // LE-NEXT:ret void
 //
@@ -693,6 +700,7 @@
 // BE-NEXT:[[F:%.*]] = getelementptr inbounds [[STRUCT_ST11:%.*]], 
%struct.st11* [[M:%.*]], i32 0, i32 1
 // BE-NEXT:[[BF_LOAD:%.*]] = load volatile i16, i16* [[F]], align 1
 // BE-NEXT:[[INC:%.*]] = add i16 [[BF_LOAD]], 1
+// BE-NEXT:[[BF_LOAD1:%.*]] = load volatile i16, i16* [[F]], align 1
 // BE-NEXT:store volatile i16 [[INC]], i16* [[F]], align 1
 // BE-NEXT:ret void
 //
Index: clang/lib/CodeGen/CGExpr.cpp
===
--- clang/lib/CodeGen/CGExpr.cpp
+++ clang/lib/CodeGen/CGExpr.cpp
@@ -2061,6 +2061,13 @@
 SrcVal = Builder.CreateOr(Val, SrcVal, "bf.set");
   } else {
 assert(Info.Offset == 0);
+// Acording to the AACPS:
+// When a volatile bit-field is written, and its container does not overlap
+// with any non-bit-field member, its container must be read exactly once 
and
+// written exactly once using the access width appropriate to the type of 
the
+// container. The two accesses are not atomic.
+if ( (CGM.getTarget().getABI() == "aapcs") && Dst.isVolatileQualified() )
+  Builder.CreateLoad(Ptr, Dst.isVolatileQualified(), "bf.load");
   }
 
   // Write the new value back out.


Index: clang/test/CodeGen/aapcs-bitfield.c
===
--- clang/test/CodeGen/aapcs-bitfield.c
+++ clang/test/CodeGen/aapcs-bitfield.c
@@ -531,12 +531,14 @@
 // LE-LABEL: @store_st9(
 // LE-NEXT:  entry:
 // LE-NEXT:[[TMP0:%.*]] = getelementptr inbounds [[STRUCT_ST9:%.*]], %struct.st9* [[M:%.*]], i32 0, i32 0
+// LE-NEXT:[[BF_LOAD:%.*]] = load volatile i8, i8* [[TMP0]], align 4
 // LE-NEXT:store volatile i8 1, i8* [[TMP0]], align 4
 // 

[PATCH] D67304: Emit -Wmicrosoft-enum-value warning instead of error in MS ABI

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

We have the old TODO of changing this warning to be emitted at enum use time 
(e.g. when Foo_Val is compared to 0) instead of declaration time. Maybe that's 
a better fix. Or is implementing that very involved?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67304



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

r371522 - [clang][codegen][NFC] Make test patterns more permissive.

[Clement Courbet via cfe-commits]

Author: courbet
Date: Tue Sep 10 07:20:08 2019
New Revision: 371522

URL: http://llvm.org/viewvc/llvm-project?rev=371522=rev
Log:
[clang][codegen][NFC] Make test patterns more permissive.

See the discussion in:
http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20190909/692736.html

Modified:
cfe/trunk/test/CodeGenCXX/auto-var-init.cpp

Modified: cfe/trunk/test/CodeGenCXX/auto-var-init.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/auto-var-init.cpp?rev=371522=371521=371522=diff
==
--- cfe/trunk/test/CodeGenCXX/auto-var-init.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/auto-var-init.cpp Tue Sep 10 07:20:08 2019
@@ -1042,8 +1042,7 @@ TEST_UNINIT(intptr4, int*[4]);
 // CHECK:%uninit = alloca [4 x i32*], align
 // CHECK-NEXT:   call void @{{.*}}used{{.*}}%uninit)
 // PATTERN-O1-LABEL: @test_intptr4_uninit()
-// PATTERN-O1:   %1 = bitcast [4 x i32*]* %uninit to i8*
-// PATTERN-O1-NEXT:  call void @llvm.memset.p0i8.i64(i8* nonnull align 16  
dereferenceable(32) %1, i8 -86, i64 32, i1 false)
+// PATTERN-O1:  call void @llvm.memset.p0i8.i64(i8* nonnull align 16  
dereferenceable(32) %{{[0-9*]}}, i8 -86, i64 32, i1 false)
 // ZERO-LABEL:   @test_intptr4_uninit()
 // ZERO: call void @llvm.memset{{.*}}, i8 0,
 


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

[PATCH] D65050: [SemaTemplate] Mark a function type as dependent when its parameter list contains pack expansion

[S. B. Tam via Phabricator via cfe-commits]

cpplearner added a comment.

In D65050#1608777 , @efriedma wrote:

> > this looks like it could be a Core Issue
>
> I think the issue is clang-specific. clang splits the standard notion of a 
> dependent type into two separate bits, for the sake of diagnostics: 
> `isDependentType()`, and `isInstantiationDependentType()`.  
> `isInstantiationDependentType()` reflects the actual standard definition of a 
> dependent type; `isDependentType()` is a type that can actually vary across 
> instantiations.


According to comment in `include/clang/AST/Type.h` 
(https://github.com/llvm/llvm-project/blob/llvmorg-8.0.1/clang/include/clang/AST/Type.h#L1426),
 `Dependent` reflects the standard definition, while `InstantiationDependent` 
reflects "whether this type somehow involves a template parameter, even if the 
resolution of the type does not depend on a template parameter" (e.g. 
`decltype(sizeof(T))`).

Therefore, I agree with Aaron that this could be a Core issue.


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

https://reviews.llvm.org/D65050



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

[PATCH] D63607: [clang][driver] Add basic --driver-mode=fortran support for flang

[Peter Waller via Phabricator via cfe-commits]

peterwaller-arm updated this revision to Diff 219538.
peterwaller-arm retitled this revision from "[clang][driver] Prototype  
--driver-mode=fortran support for new flang" to "[clang][driver] Add basic 
--driver-mode=fortran support for flang".
peterwaller-arm added a comment.

I updated this "prototype" revision into the real thing I would like to submit. 
Please let me know if that was the wrong thing to do and I will resubmit it.

This is an initial implementation which naturally doesn't implement very much. 
More will come in future patches.


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

https://reviews.llvm.org/D63607

Files:
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/ToolChain.h
  clang/include/clang/Driver/Types.h
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Flang.cpp
  clang/lib/Driver/ToolChains/Flang.h
  clang/lib/Driver/Types.cpp
  clang/test/Driver/flang/flang.F90
  clang/test/Driver/flang/flang.f90
  clang/test/Driver/fortran.f95
  clang/test/Driver/lit.local.cfg

Index: clang/test/Driver/lit.local.cfg
===
--- clang/test/Driver/lit.local.cfg
+++ clang/test/Driver/lit.local.cfg
@@ -1,4 +1,4 @@
-config.suffixes = ['.c', '.cpp', '.h', '.m', '.mm', '.S', '.s', '.f90', '.f95',
+config.suffixes = ['.c', '.cpp', '.h', '.m', '.mm', '.S', '.s', '.f90', '.F90', '.f95',
'.cu', '.rs', '.cl', '.hip']
 config.substitutions = list(config.substitutions)
 config.substitutions.insert(0,
Index: clang/test/Driver/fortran.f95
===
--- clang/test/Driver/fortran.f95
+++ clang/test/Driver/fortran.f95
@@ -1,21 +1,21 @@
-// Check that the clang driver can invoke gcc to compile Fortran.
+! Check that the clang driver can invoke gcc to compile Fortran.
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -integrated-as -c %s -### 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-OBJECT %s
-// CHECK-OBJECT: gcc
-// CHECK-OBJECT: "-c"
-// CHECK-OBJECT: "-x" "f95"
-// CHECK-OBJECT-NOT: cc1as
+! RUN: %clang -target x86_64-unknown-linux-gnu -integrated-as -c %s -### 2>&1 \
+! RUN:   | FileCheck --check-prefix=CHECK-OBJECT %s
+! CHECK-OBJECT: gcc
+! CHECK-OBJECT: "-c"
+! CHECK-OBJECT: "-x" "f95"
+! CHECK-OBJECT-NOT: cc1as
 
-// RUN: %clang -target x86_64-unknown-linux-gnu -integrated-as -S %s -### 2>&1 \
-// RUN:   | FileCheck --check-prefix=CHECK-ASM %s
-// CHECK-ASM: gcc
-// CHECK-ASM: "-S"
-// CHECK-ASM: "-x" "f95"
-// CHECK-ASM-NOT: cc1
+! RUN: %clang -target x86_64-unknown-linux-gnu -integrated-as -S %s -### 2>&1 \
+! RUN:   | FileCheck --check-prefix=CHECK-ASM %s
+! CHECK-ASM: gcc
+! CHECK-ASM: "-S"
+! CHECK-ASM: "-x" "f95"
+! CHECK-ASM-NOT: cc1
 
-// RUN: %clang -Wall -target x86_64-unknown-linux-gnu -integrated-as %s -o %t -### 2>&1 | FileCheck --check-prefix=CHECK-WARN %s
-// CHECK-WARN: gcc
-// CHECK-WARN-NOT: "-Wall"
-// CHECK-WARN: ld
-// CHECK-WARN-NOT: "-Wall"
+! RUN: %clang -Wall -target x86_64-unknown-linux-gnu -integrated-as %s -o %t -### 2>&1 | FileCheck --check-prefix=CHECK-WARN %s
+! CHECK-WARN: gcc
+! CHECK-WARN-NOT: "-Wall"
+! CHECK-WARN: ld
+! CHECK-WARN-NOT: "-Wall"
Index: clang/test/Driver/flang/flang.f90
===
--- /dev/null
+++ clang/test/Driver/flang/flang.f90
@@ -0,0 +1,56 @@
+! Check that flang -fc1 is invoked when in --driver-mode=fortran.
+
+! See also: flang.F90 - "an input which also requires preprocessing".
+
+! Test various output types:
+! * The default (-emit-obj)
+! * -fsyntax-only
+! * -emit-llvm
+! * -emit-llvm -S
+! * -S
+
+! Most tests use ALL-LABEL to bracket the checks with the compiler invocation and the source, which appear at the beginning and end.
+! Use of "...-DAG" allows the order of options to change within that bracket.
+
+
+! All invocations should begin with flang -fc1, consume up to here.
+! ALL-LABEL: "{{[^"]*}}flang" "-fc1"
+
+! RUN: %clang --driver-mode=fortran -### %s 2>&1 | FileCheck --check-prefixes=ALL,CHECK-PLAIN %s
+! CHECK-PLAIN-DAG: "-triple"
+! CHECK-PLAIN-DAG: "-emit-obj"
+! CHECK-PLAIN-DAG: "-o" "{{[^"]*}}.o"
+
+! RUN: %clang --driver-mode=fortran -emit-ast-### %s 2>&1 | FileCheck --check-prefixes=ALL,CHECK-EMIT-AST %s
+! CHECK-EMIT-AST-DAG: "-triple"
+! CHECK-EMIT-AST-DAG: "-emit-ast"
+! CHECK-EMIT-AST-DAG: "-o" "{{[^"]*}}.ast"
+
+! RUN: %clang --driver-mode=fortran -fsyntax-only   -### %s 2>&1 | FileCheck --check-prefixes=ALL,CHECK-SYNTAX-ONLY %s
+! CHECK-SYNTAX-ONLY-NOT: "-o"
+! CHECK-SYNTAX-ONLY-DAG: "-fsyntax-only"
+
+! RUN: %clang --driver-mode=fortran -emit-llvm  -### %s 2>&1 | FileCheck --check-prefixes=ALL,CHECK-EMIT-LLVM %s
+! CHECK-EMIT-LLVM-NOT: "-emit-llvm"
+! CHECK-EMIT-LLVM-DAG: "-emit-llvm-uselists"
+! CHECK-EMIT-LLVM-DAG: "-emit-llvm-bc"
+! CHECK-EMIT-LLVM-DAG: "-o" 

[PATCH] D65050: [SemaTemplate] Mark a function type as dependent when its parameter list contains pack expansion

[S. B. Tam via Phabricator via cfe-commits]

cpplearner added a comment.

ping @rsmith


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

https://reviews.llvm.org/D65050



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

[PATCH] D67058: [clang][CodeGen] Add alias for cpu_dispatch function with IFunc & Fix resolver linkage type

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:3002
 false);
 llvm::Constant *Resolver = GetOrCreateLLVMFunction(
 MangledName + ".resolver", ResolverType, GlobalDecl{},

zsrkmyn wrote:
> erichkeane wrote:
> > zsrkmyn wrote:
> > > zsrkmyn wrote:
> > > > erichkeane wrote:
> > > > > zsrkmyn wrote:
> > > > > > erichkeane wrote:
> > > > > > > This Resolver should have the same linkage as below.
> > > > > > Actually, I wanted to set linkage here at the first time, but 
> > > > > > failed. When compiling code with cpu_specific but no cpu_dispatch, 
> > > > > > we cannot set it as LinkOnceODR or WeakODR. E.g.:
> > > > > > 
> > > > > > ```
> > > > > > $ cat specific_only.c
> > > > > > __declspec(cpu_specific(pentium_iii))
> > > > > > int foo(void) { return 0; }
> > > > > > int usage() { return foo(); }
> > > > > > 
> > > > > > $ clang -fdeclspec specific_only.c  
> > > > > >
> > > > > > Global is external, but doesn't have external or weak linkage!  
> > > > > >   
> > > > > > i32 ()* ()* @foo.resolver   
> > > > > >   
> > > > > > fatal error: error in backend: Broken module found, compilation 
> > > > > > aborted!   
> > > > > > ```
> > > > > > 
> > > > > > This is found by lit test test/CodeGen/attr-cpuspecific.c, in which 
> > > > > > 'SingleVersion()' doesn't have a cpu_dispatch declaration.
> > > > > The crash message is complaining it isn't external/weak.  However, 
> > > > > WeakODR should count, right?  Can you look into it a bit more to see 
> > > > > what it thinks is broken?
> > > > No, actually I've tried it earlier with the example I mentioned in my 
> > > > last comment, but WeakODR still makes compiler complaining. I think 
> > > > it's `foo.resolver` that cannot be declared with as WeakODR/LinkOnceODR 
> > > > without definition. But I'm really not familiar with these rules.
> > > According to the `Verifier::visitGlobalValue()` in Verify.cpp, an 
> > > declaration can only be `ExternalLinkage` or `ExternalWeakLinkage`. So I 
> > > still believe we cannot set the resolver to 
> > > `LinkOnceODRLinkage/WeakODRLinkage` here, as they are declared but not 
> > > defined when we only have `cpu_specified` but no `cpu_dispatch` in a TU 
> > > as the example above.
> > That doesn't seem right then.  IF it allows ExternalWeakLinkage I'd expect 
> > WeakODR to work as well, since it is essentially the same thing.
> I think we should have a double check. It is said "It is illegal for a 
> function declaration to have any linkage type other than `external` or 
> `extern_weak`" at the last line of section Linkage Type in the reference 
> manual [1]. I guess `weak_odr` is not designed for declaration purpose and 
> should be only used by definition.
> 
> [1] https://llvm.org/docs/LangRef.html#linkage-types
I had typed a reply, but apparently it didn't submit: Ah, nvm, I see now that 
external-weak is different from weak.

I don't really get the linkages sufficiently to know what the right thing to do 
is then.  If we DO have a definition, I'd say weak_odr so it can be merged, 
right?  If we do NOT, could externally_available work?


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

https://reviews.llvm.org/D67058



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

[PATCH] D67395: [clang-format] Apply BAS_AlwaysBreak to C++11 braced lists

[Owen Pan via Phabricator via cfe-commits]

owenpan created this revision.
owenpan added reviewers: sammccall, MyDeveloperDay, klimek.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
owenpan added a reviewer: djasper.

See PR18455  and this message 
.


Repository:
  rC Clang

https://reviews.llvm.org/D67395

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


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7835,6 +7835,16 @@
   "};",
   NoBinPacking);
 
+  NoBinPacking.AlignAfterOpenBracket = FormatStyle::BAS_AlwaysBreak;
+  EXPECT_EQ("static uint8 CddDp83848Reg[] = {\n"
+"CDDDP83848_BMCR_REGISTER,\n"
+"CDDDP83848_BMSR_REGISTER,\n"
+"CDDDP83848_RBR_REGISTER};",
+format("static uint8 CddDp83848Reg[] = 
{CDDDP83848_BMCR_REGISTER,\n"
+   "
CDDDP83848_BMSR_REGISTER,\n"
+   "CDDDP83848_RBR_REGISTER};",
+   NoBinPacking));
+
   // FIXME: The alignment of these trailing comments might be bad. Then again,
   // this might be utterly useless in real code.
   verifyFormat("Constructor::Constructor()\n"
Index: clang/lib/Format/ContinuationIndenter.cpp
===
--- clang/lib/Format/ContinuationIndenter.cpp
+++ clang/lib/Format/ContinuationIndenter.cpp
@@ -606,7 +606,9 @@
   // disallowing any further line breaks if there is no line break after the
   // opening parenthesis. Don't break if it doesn't conserve columns.
   if (Style.AlignAfterOpenBracket == FormatStyle::BAS_AlwaysBreak &&
-  Previous.isOneOf(tok::l_paren, TT_TemplateOpener, tok::l_square) &&
+  (Previous.isOneOf(tok::l_paren, TT_TemplateOpener, tok::l_square) ||
+   (Previous.is(tok::l_brace) && Previous.BlockKind != BK_Block &&
+Style.Cpp11BracedListStyle)) &&
   State.Column > getNewLineColumn(State) &&
   (!Previous.Previous || !Previous.Previous->isOneOf(
  tok::kw_for, tok::kw_while, tok::kw_switch)) 
&&


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -7835,6 +7835,16 @@
   "};",
   NoBinPacking);
 
+  NoBinPacking.AlignAfterOpenBracket = FormatStyle::BAS_AlwaysBreak;
+  EXPECT_EQ("static uint8 CddDp83848Reg[] = {\n"
+"CDDDP83848_BMCR_REGISTER,\n"
+"CDDDP83848_BMSR_REGISTER,\n"
+"CDDDP83848_RBR_REGISTER};",
+format("static uint8 CddDp83848Reg[] = {CDDDP83848_BMCR_REGISTER,\n"
+   "CDDDP83848_BMSR_REGISTER,\n"
+   "CDDDP83848_RBR_REGISTER};",
+   NoBinPacking));
+
   // FIXME: The alignment of these trailing comments might be bad. Then again,
   // this might be utterly useless in real code.
   verifyFormat("Constructor::Constructor()\n"
Index: clang/lib/Format/ContinuationIndenter.cpp
===
--- clang/lib/Format/ContinuationIndenter.cpp
+++ clang/lib/Format/ContinuationIndenter.cpp
@@ -606,7 +606,9 @@
   // disallowing any further line breaks if there is no line break after the
   // opening parenthesis. Don't break if it doesn't conserve columns.
   if (Style.AlignAfterOpenBracket == FormatStyle::BAS_AlwaysBreak &&
-  Previous.isOneOf(tok::l_paren, TT_TemplateOpener, tok::l_square) &&
+  (Previous.isOneOf(tok::l_paren, TT_TemplateOpener, tok::l_square) ||
+   (Previous.is(tok::l_brace) && Previous.BlockKind != BK_Block &&
+Style.Cpp11BracedListStyle)) &&
   State.Column > getNewLineColumn(State) &&
   (!Previous.Previous || !Previous.Previous->isOneOf(
  tok::kw_for, tok::kw_while, tok::kw_switch)) &&
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D66524: [SVE][Inline-Asm] Add constraints for SVE predicate registers

[Kerry McLaughlin via Phabricator via cfe-commits]

kmclaughlin marked 3 inline comments as done.
kmclaughlin added inline comments.



Comment at: docs/LangRef.rst:3818
+- ``Upl``: One of the low eight SVE predicate registers (P0 to P7)
+- ``Upa``: Any of the SVE predicate registers (P0 to P15)
 

greened wrote:
> What do these names mean?  " predicate lower|all?"  I see they are 
> the names used in gcc, so I guess it makes sense to use them here.  Are these 
> names used in the SVE architecture manual somewhere?  I cannot find them.
The length of the constraint depends on the first letter, and for AArch64 'U' 
was chosen to indicate a 3-letter constraint. These are not in the SVE 
architecture manual as they are only for compatibility with GCC inline asm (see 
https://gcc.gnu.org/onlinedocs/gcc/Machine-Constraints.html#Machine-Constraints)



Comment at: lib/Target/AArch64/AArch64ISelLowering.cpp:5747
+
+PredicateConstraint isPredicateConstraint(StringRef Constraint) {
+  PredicateConstraint P = PredicateConstraint::Invalid;

greened wrote:
> rovka wrote:
> > Nit: I think get- or parsePredicateConstraint reads better, since this 
> > doesn't return a simple yes/no answer.
> +1.
Thanks for the suggestion @rovka - I have changed this to 
parsePredicateConstraint


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

https://reviews.llvm.org/D66524



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

[PATCH] D66524: [SVE][Inline-Asm] Add constraints for SVE predicate registers

[Kerry McLaughlin via Phabricator via cfe-commits]

kmclaughlin updated this revision to Diff 219526.
kmclaughlin added a comment.

- Renamed the //isPredicateConstraint// function to //parsePredicateConstraint//
- Added more thorough checks to the tests in aarch64-sve-asm.ll


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

https://reviews.llvm.org/D66524

Files:
  docs/LangRef.rst
  lib/IR/InlineAsm.cpp
  lib/Target/AArch64/AArch64AsmPrinter.cpp
  lib/Target/AArch64/AArch64ISelLowering.cpp
  lib/Target/AArch64/AArch64InstrInfo.cpp
  test/CodeGen/AArch64/aarch64-sve-asm.ll

Index: test/CodeGen/AArch64/aarch64-sve-asm.ll
===
--- test/CodeGen/AArch64/aarch64-sve-asm.ll
+++ test/CodeGen/AArch64/aarch64-sve-asm.ll
@@ -8,6 +8,7 @@
 ; CHECK: [[ARG2:%[0-9]+]]:zpr = COPY $z0
 ; CHECK: [[ARG3:%[0-9]+]]:zpr = COPY [[ARG2]]
 ; CHECK: [[ARG4:%[0-9]+]]:zpr_3b = COPY [[ARG1]]
+; CHECK: INLINEASM {{.*}} [[ARG4]]
 define  @test_svadd_i8( %Zn,  %Zm) {
   %1 = tail call  asm "add $0.b, $1.b, $2.b", "=w,w,y"( %Zn,  %Zm)
   ret  %1
@@ -18,6 +19,7 @@
 ; CHECK: [[ARG2:%[0-9]+]]:zpr = COPY $z0
 ; CHECK: [[ARG3:%[0-9]+]]:zpr = COPY [[ARG2]]
 ; CHECK: [[ARG4:%[0-9]+]]:zpr_4b = COPY [[ARG1]]
+; CHECK: INLINEASM {{.*}} [[ARG4]]
 define  @test_svsub_i64( %Zn,  %Zm) {
   %1 = tail call  asm "sub $0.d, $1.d, $2.d", "=w,w,x"( %Zn,  %Zm)
   ret  %1
@@ -28,6 +30,7 @@
 ; CHECK: [[ARG2:%[0-9]+]]:zpr = COPY $z0
 ; CHECK: [[ARG3:%[0-9]+]]:zpr = COPY [[ARG2]]
 ; CHECK: [[ARG4:%[0-9]+]]:zpr_3b = COPY [[ARG1]]
+; CHECK: INLINEASM {{.*}} [[ARG4]]
 define  @test_svfmul_f16( %Zn,  %Zm) {
   %1 = tail call  asm "fmul $0.h, $1.h, $2.h", "=w,w,y"( %Zn,  %Zm)
   ret  %1
@@ -38,7 +41,30 @@
 ; CHECK: [[ARG2:%[0-9]+]]:zpr = COPY $z0
 ; CHECK: [[ARG3:%[0-9]+]]:zpr = COPY [[ARG2]]
 ; CHECK: [[ARG4:%[0-9]+]]:zpr_4b = COPY [[ARG1]]
+; CHECK: INLINEASM {{.*}} [[ARG4]]
 define  @test_svfmul_f( %Zn,  %Zm) {
   %1 = tail call  asm "fmul $0.s, $1.s, $2.s", "=w,w,x"( %Zn,  %Zm)
   ret  %1
 }
+
+; Function Attrs: nounwind readnone
+; CHECK: [[ARG1:%[0-9]+]]:zpr = COPY $z1
+; CHECK: [[ARG2:%[0-9]+]]:zpr = COPY $z0
+; CHECK: [[ARG3:%[0-9]+]]:ppr = COPY $p0
+; CHECK: [[ARG4:%[0-9]+]]:ppr_3b = COPY [[ARG3]]
+; CHECK: INLINEASM {{.*}} [[ARG4]]
+define  @test_svfadd_f16( %Pg,  %Zn,  %Zm) {
+  %1 = tail call  asm "fadd $0.h, $1/m, $2.h, $3.h", "=w,@3Upl,w,w"( %Pg,  %Zn,  %Zm)
+  ret  %1
+}
+
+; Function Attrs: nounwind readnone
+; CHECK: [[ARG1:%[0-9]+]]:zpr = COPY $z0
+; CHECK: [[ARG2:%[0-9]+]]:ppr = COPY $p0
+; CHECK: [[ARG3:%[0-9]+]]:ppr = COPY [[ARG2]]
+; CHECK: [[ARG4:%[0-9]+]]:zpr = COPY [[ARG1]]
+; CHECK: INLINEASM {{.*}} [[ARG3]]
+define  @test_incp( %Pg,  %Zn) {
+  %1 = tail call  asm "incp $0.s, $1", "=w,@3Upa,0"( %Pg,  %Zn)
+  ret  %1
+}
Index: lib/Target/AArch64/AArch64InstrInfo.cpp
===
--- lib/Target/AArch64/AArch64InstrInfo.cpp
+++ lib/Target/AArch64/AArch64InstrInfo.cpp
@@ -2484,6 +2484,17 @@
 return;
   }
 
+  // Copy a Predicate register by ORRing with itself.
+  if (AArch64::PPRRegClass.contains(DestReg) &&
+  AArch64::PPRRegClass.contains(SrcReg)) {
+assert(Subtarget.hasSVE() && "Unexpected SVE register.");
+BuildMI(MBB, I, DL, get(AArch64::ORR_PPzPP), DestReg)
+  .addReg(SrcReg) // Pg
+  .addReg(SrcReg)
+  .addReg(SrcReg, getKillRegState(KillSrc));
+return;
+  }
+
   // Copy a Z register by ORRing with itself.
   if (AArch64::ZPRRegClass.contains(DestReg) &&
   AArch64::ZPRRegClass.contains(SrcReg)) {
Index: lib/Target/AArch64/AArch64ISelLowering.cpp
===
--- lib/Target/AArch64/AArch64ISelLowering.cpp
+++ lib/Target/AArch64/AArch64ISelLowering.cpp
@@ -5738,6 +5738,21 @@
   return "r";
 }
 
+enum PredicateConstraint {
+  Upl,
+  Upa,
+  Invalid
+};
+
+PredicateConstraint parsePredicateConstraint(StringRef Constraint) {
+  PredicateConstraint P = PredicateConstraint::Invalid;
+  if (Constraint == "Upa")
+P = PredicateConstraint::Upa;
+  if (Constraint == "Upl")
+P = PredicateConstraint::Upl;
+  return P;
+}
+
 /// getConstraintType - Given a constraint letter, return the type of
 /// constraint it is for this target.
 AArch64TargetLowering::ConstraintType
@@ -5767,7 +5782,9 @@
 case 'S': // A symbolic address
   return C_Other;
 }
-  }
+  } else if (parsePredicateConstraint(Constraint) !=
+ PredicateConstraint::Invalid)
+  return C_RegisterClass;
   return TargetLowering::getConstraintType(Constraint);
 }
 
@@ -5798,6 +5815,10 @@
   case 'z':
 weight = CW_Constant;
 break;
+  case 'U':
+if (parsePredicateConstraint(constraint) != PredicateConstraint::Invalid)
+  weight = CW_Register;
+break;
   }
   return weight;
 }
@@ -5841,6 +5862,14 @@
 return std::make_pair(0U, ::ZPR_3bRegClass);
   break;
 }
+  } else {
+PredicateConstraint PC = parsePredicateConstraint(Constraint);
+if (PC != 

[PATCH] D67391: Fix the "git modified" issue on the preserve-comments-crlf.s.

[Haojian Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL371513:  Fix the git modified issue on the 
preserve-comments-crlf.s. (authored by hokein, committed by ).

Changed prior to commit:
  https://reviews.llvm.org/D67391?vs=219522=219525#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67391

Files:
  llvm/trunk/.gitattributes


Index: llvm/trunk/.gitattributes
===
--- llvm/trunk/.gitattributes
+++ llvm/trunk/.gitattributes
@@ -13,5 +13,7 @@
 test/MC/AsmParser/incbin_abcd binary
 test/YAMLParser/spec-09-02.test binary
 
-# Windows line ending test
-test/MC/AsmParser/preserve-comments-crlf.s text eol=crlf
+# This file must have CRLF line endings, therefore git should treat it as
+# binary and not autoconvert line endings (for example, when core.autocrlf is
+# on).
+test/MC/AsmParser/preserve-comments-crlf.s binary


Index: llvm/trunk/.gitattributes
===
--- llvm/trunk/.gitattributes
+++ llvm/trunk/.gitattributes
@@ -13,5 +13,7 @@
 test/MC/AsmParser/incbin_abcd binary
 test/YAMLParser/spec-09-02.test binary
 
-# Windows line ending test
-test/MC/AsmParser/preserve-comments-crlf.s text eol=crlf
+# This file must have CRLF line endings, therefore git should treat it as
+# binary and not autoconvert line endings (for example, when core.autocrlf is
+# on).
+test/MC/AsmParser/preserve-comments-crlf.s binary
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67391: Copy llvm .gitattributes to the monorepository.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 219522.
hokein added a comment.

Update the patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67391

Files:
  llvm/.gitattributes


Index: llvm/.gitattributes
===
--- llvm/.gitattributes
+++ llvm/.gitattributes
@@ -13,5 +13,7 @@
 test/MC/AsmParser/incbin_abcd binary
 test/YAMLParser/spec-09-02.test binary
 
-# Windows line ending test
-test/MC/AsmParser/preserve-comments-crlf.s text eol=crlf
+# This file must have CRLF line endings, therefore git should treat it as
+# binary and not autoconvert line endings (for example, when core.autocrlf is
+# on).
+test/MC/AsmParser/preserve-comments-crlf.s binary


Index: llvm/.gitattributes
===
--- llvm/.gitattributes
+++ llvm/.gitattributes
@@ -13,5 +13,7 @@
 test/MC/AsmParser/incbin_abcd binary
 test/YAMLParser/spec-09-02.test binary
 
-# Windows line ending test
-test/MC/AsmParser/preserve-comments-crlf.s text eol=crlf
+# This file must have CRLF line endings, therefore git should treat it as
+# binary and not autoconvert line endings (for example, when core.autocrlf is
+# on).
+test/MC/AsmParser/preserve-comments-crlf.s binary
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D66796: [clang] Loop pragma vectorize(disable)

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer added a comment.

> Now on the practical side. If whatever we decide here changes how the pragma 
> behaves from today, we need to have a wider discussion and agreement at 
> llvm-dev.

Yep, forgot about that, thanks for the suggestion. I've just posted this 
message to the list:

http://lists.llvm.org/pipermail/llvm-dev/2019-September/135016.html


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

https://reviews.llvm.org/D66796



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

[PATCH] D67391: Copy llvm .gitattributes to the monorepository.

[Haojian Wu via Phabricator via cfe-commits]

hokein created this revision.
hokein added a reviewer: gribozavr.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

This will fix the git "modified" change of 
llvm/trunk/test/MC/AsmParser/preserve-comments-crlf.s on linux.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D67391

Files:
  .gitattributes


Index: .gitattributes
===
--- /dev/null
+++ .gitattributes
@@ -0,0 +1,17 @@
+# binary files
+llvm/test/Object/Inputs/*.a-* binary
+llvm/test/tools/dsymutil/Inputs/*.o binary
+llvm/test/tools/dsymutil/Inputs/*.a binary
+llvm/test/tools/dsymutil/Inputs/*.i386 binary
+llvm/test/tools/dsymutil/Inputs/*.x86_64 binary
+llvm/test/tools/dsymutil/Inputs/*.armv7m binary
+llvm/test/tools/dsymutil/Inputs/*.dylib binary
+llvm/test/tools/llvm-ar/Inputs/*.lib binary
+llvm/test/tools/llvm-objdump/Inputs/*.a binary
+llvm/test/tools/llvm-rc/Inputs/* binary
+llvm/test/tools/llvm-strings/Inputs/numbers binary
+llvm/test/MC/AsmParser/incbin_abcd binary
+llvm/test/YAMLParser/spec-09-02.test binary
+
+# Windows line ending test
+llvm/test/MC/AsmParser/preserve-comments-crlf.s text eol=crlf


Index: .gitattributes
===
--- /dev/null
+++ .gitattributes
@@ -0,0 +1,17 @@
+# binary files
+llvm/test/Object/Inputs/*.a-* binary
+llvm/test/tools/dsymutil/Inputs/*.o binary
+llvm/test/tools/dsymutil/Inputs/*.a binary
+llvm/test/tools/dsymutil/Inputs/*.i386 binary
+llvm/test/tools/dsymutil/Inputs/*.x86_64 binary
+llvm/test/tools/dsymutil/Inputs/*.armv7m binary
+llvm/test/tools/dsymutil/Inputs/*.dylib binary
+llvm/test/tools/llvm-ar/Inputs/*.lib binary
+llvm/test/tools/llvm-objdump/Inputs/*.a binary
+llvm/test/tools/llvm-rc/Inputs/* binary
+llvm/test/tools/llvm-strings/Inputs/numbers binary
+llvm/test/MC/AsmParser/incbin_abcd binary
+llvm/test/YAMLParser/spec-09-02.test binary
+
+# Windows line ending test
+llvm/test/MC/AsmParser/preserve-comments-crlf.s text eol=crlf
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D67264: [clangd] Collect location of macro definition in the ParsedAST

[Haojian Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL371504: [clangd] Collect location of macro definition in the 
ParsedAST (authored by hokein, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D67264?vs=219501=219505#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D67264

Files:
  clang-tools-extra/trunk/clangd/ParsedAST.cpp
  clang-tools-extra/trunk/clangd/ParsedAST.h
  clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
  clang-tools-extra/trunk/clangd/unittests/ParsedASTTests.cpp
  clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/trunk/clangd/ParsedAST.cpp
===
--- clang-tools-extra/trunk/clangd/ParsedAST.cpp
+++ clang-tools-extra/trunk/clangd/ParsedAST.cpp
@@ -98,23 +98,30 @@
   std::vector TopLevelDecls;
 };
 
-// This collects macro expansions in the main file.
+// This collects macro expansions/definitions in the main file.
 // (Contrast with CollectMainFileMacros in Preamble.cpp, which collects macro
 // *definitions* in the preamble region of the main file).
-class CollectMainFileMacroExpansions : public PPCallbacks {
+class CollectMainFileMacros : public PPCallbacks {
   const SourceManager 
   std::vector 
 
+  void addLoc(SourceLocation Loc) {
+if (!Loc.isMacroID() && isInsideMainFile(Loc, SM))
+  MainFileMacroLocs.push_back(Loc);
+  }
+
 public:
-  CollectMainFileMacroExpansions(const SourceManager ,
- std::vector )
+  CollectMainFileMacros(const SourceManager ,
+std::vector )
   : SM(SM), MainFileMacroLocs(MainFileMacroLocs) {}
 
+  void MacroDefined(const Token ,
+const MacroDirective *MD) override {
+addLoc(MacroNameTok.getLocation());
+  }
   void MacroExpands(const Token , const MacroDefinition ,
 SourceRange Range, const MacroArgs *Args) override {
-SourceLocation L = MacroNameTok.getLocation();
-if (!L.isMacroID() && isInsideMainFile(L, SM))
-  MainFileMacroLocs.push_back(L);
+addLoc(MacroNameTok.getLocation());
   }
 };
 
@@ -358,8 +365,8 @@
   // Collect the macro expansions in the main file.
   std::vector MainFileMacroExpLocs;
   Clang->getPreprocessor().addPPCallbacks(
-  std::make_unique(
-  Clang->getSourceManager(), MainFileMacroExpLocs));
+  std::make_unique(Clang->getSourceManager(),
+  MainFileMacroExpLocs));
 
   // Copy over the includes from the preamble, then combine with the
   // non-preamble includes below.
@@ -453,8 +460,8 @@
   return LocalTopLevelDecls;
 }
 
-llvm::ArrayRef ParsedAST::getMainFileExpansions() const {
-  return MainFileMacroExpLocs;
+llvm::ArrayRef ParsedAST::getMacros() const {
+  return MacroIdentifierLocs;
 }
 
 const std::vector ::getDiagnostics() const { return Diags; }
@@ -503,13 +510,13 @@
  std::unique_ptr Clang,
  std::unique_ptr Action,
  syntax::TokenBuffer Tokens,
- std::vector MainFileMacroExpLocs,
+ std::vector MacroIdentifierLocs,
  std::vector LocalTopLevelDecls,
  std::vector Diags, IncludeStructure Includes,
  CanonicalIncludes CanonIncludes)
 : Preamble(std::move(Preamble)), Clang(std::move(Clang)),
   Action(std::move(Action)), Tokens(std::move(Tokens)),
-  MainFileMacroExpLocs(std::move(MainFileMacroExpLocs)),
+  MacroIdentifierLocs(std::move(MacroIdentifierLocs)),
   Diags(std::move(Diags)),
   LocalTopLevelDecls(std::move(LocalTopLevelDecls)),
   Includes(std::move(Includes)), CanonIncludes(std::move(CanonIncludes)) {
Index: clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp
@@ -427,18 +427,19 @@
   R"cpp(
   #define DEF_MULTIPLE(X) namespace X { class X { int X; }; }
   #define DEF_CLASS(T) class T {};
+  // Preamble ends.
   $Macro[[DEF_MULTIPLE]](XYZ);
   $Macro[[DEF_MULTIPLE]](XYZW);
   $Macro[[DEF_CLASS]]($Class[[A]])
-  #define MACRO_CONCAT(X, V, T) T foo##X = V
-  #define DEF_VAR(X, V) int X = V
-  #define DEF_VAR_T(T, X, V) T X = V
-  #define DEF_VAR_REV(V, X) DEF_VAR(X, V)
-  #define CPY(X) X
-  #define DEF_VAR_TYPE(X, Y) X Y
-  #define SOME_NAME variable
-  #define SOME_NAME_SET variable2 = 123
-  #define INC_VAR(X) X += 2
+  #define $Macro[[MACRO_CONCAT]](X, V, T) T foo##X = V
+  #define $Macro[[DEF_VAR]](X, V) int X = V
+  

[clang-tools-extra] r371504 - [clangd] Collect location of macro definition in the ParsedAST

[Haojian Wu via cfe-commits]

Author: hokein
Date: Tue Sep 10 03:10:36 2019
New Revision: 371504

URL: http://llvm.org/viewvc/llvm-project?rev=371504=rev
Log:
[clangd] Collect location of macro definition in the ParsedAST

allows semantic hightlighting macro definition

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

Tags: #clang

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

Modified:
clang-tools-extra/trunk/clangd/ParsedAST.cpp
clang-tools-extra/trunk/clangd/ParsedAST.h
clang-tools-extra/trunk/clangd/SemanticHighlighting.cpp
clang-tools-extra/trunk/clangd/unittests/ParsedASTTests.cpp
clang-tools-extra/trunk/clangd/unittests/SemanticHighlightingTests.cpp

Modified: clang-tools-extra/trunk/clangd/ParsedAST.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ParsedAST.cpp?rev=371504=371503=371504=diff
==
--- clang-tools-extra/trunk/clangd/ParsedAST.cpp (original)
+++ clang-tools-extra/trunk/clangd/ParsedAST.cpp Tue Sep 10 03:10:36 2019
@@ -98,23 +98,30 @@ private:
   std::vector TopLevelDecls;
 };
 
-// This collects macro expansions in the main file.
+// This collects macro expansions/definitions in the main file.
 // (Contrast with CollectMainFileMacros in Preamble.cpp, which collects macro
 // *definitions* in the preamble region of the main file).
-class CollectMainFileMacroExpansions : public PPCallbacks {
+class CollectMainFileMacros : public PPCallbacks {
   const SourceManager 
   std::vector 
 
+  void addLoc(SourceLocation Loc) {
+if (!Loc.isMacroID() && isInsideMainFile(Loc, SM))
+  MainFileMacroLocs.push_back(Loc);
+  }
+
 public:
-  CollectMainFileMacroExpansions(const SourceManager ,
- std::vector 
)
+  CollectMainFileMacros(const SourceManager ,
+std::vector )
   : SM(SM), MainFileMacroLocs(MainFileMacroLocs) {}
 
+  void MacroDefined(const Token ,
+const MacroDirective *MD) override {
+addLoc(MacroNameTok.getLocation());
+  }
   void MacroExpands(const Token , const MacroDefinition ,
 SourceRange Range, const MacroArgs *Args) override {
-SourceLocation L = MacroNameTok.getLocation();
-if (!L.isMacroID() && isInsideMainFile(L, SM))
-  MainFileMacroLocs.push_back(L);
+addLoc(MacroNameTok.getLocation());
   }
 };
 
@@ -358,8 +365,8 @@ ParsedAST::build(std::unique_ptr MainFileMacroExpLocs;
   Clang->getPreprocessor().addPPCallbacks(
-  std::make_unique(
-  Clang->getSourceManager(), MainFileMacroExpLocs));
+  std::make_unique(Clang->getSourceManager(),
+  MainFileMacroExpLocs));
 
   // Copy over the includes from the preamble, then combine with the
   // non-preamble includes below.
@@ -453,8 +460,8 @@ llvm::ArrayRef ParsedAST::getLoc
   return LocalTopLevelDecls;
 }
 
-llvm::ArrayRef ParsedAST::getMainFileExpansions() const {
-  return MainFileMacroExpLocs;
+llvm::ArrayRef ParsedAST::getMacros() const {
+  return MacroIdentifierLocs;
 }
 
 const std::vector ::getDiagnostics() const { return Diags; }
@@ -503,13 +510,13 @@ ParsedAST::ParsedAST(std::shared_ptr Clang,
  std::unique_ptr Action,
  syntax::TokenBuffer Tokens,
- std::vector MainFileMacroExpLocs,
+ std::vector MacroIdentifierLocs,
  std::vector LocalTopLevelDecls,
  std::vector Diags, IncludeStructure Includes,
  CanonicalIncludes CanonIncludes)
 : Preamble(std::move(Preamble)), Clang(std::move(Clang)),
   Action(std::move(Action)), Tokens(std::move(Tokens)),
-  MainFileMacroExpLocs(std::move(MainFileMacroExpLocs)),
+  MacroIdentifierLocs(std::move(MacroIdentifierLocs)),
   Diags(std::move(Diags)),
   LocalTopLevelDecls(std::move(LocalTopLevelDecls)),
   Includes(std::move(Includes)), CanonIncludes(std::move(CanonIncludes)) {

Modified: clang-tools-extra/trunk/clangd/ParsedAST.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/ParsedAST.h?rev=371504=371503=371504=diff
==
--- clang-tools-extra/trunk/clangd/ParsedAST.h (original)
+++ clang-tools-extra/trunk/clangd/ParsedAST.h Tue Sep 10 03:10:36 2019
@@ -89,9 +89,10 @@ public:
   const IncludeStructure () const;
   const CanonicalIncludes () const;
 
-  /// The start locations of all macro expansions spelled inside the main file.
-  /// Does not include expansions from inside other macro expansions.
-  llvm::ArrayRef getMainFileExpansions() const;
+  /// Gets all macro locations (definition, expansions) present in the main
+  /// file.
+  /// NOTE: macros inside the preamble are not included.
+  llvm::ArrayRef getMacros() const;
   /// Tokens recorded while parsing the main file.
   /// (!) does not have 

[PATCH] D67065: [RISCV] Define __riscv_cmodel_medlow and __riscv_cmodel_medany correctly

[Sam Elliott via Phabricator via cfe-commits]

lenary added a comment.

LGTM, now I've looked at how LLVM itself supports code models. I don't mind if 
that TODO is or isn't deleted.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67065



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

[PATCH] D67341: [clangd] Simplify semantic highlighting visitor

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added inline comments.



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:169
 private:
-  void addTokenForTypedef(SourceLocation Loc, const TypedefNameDecl *TD) {
-auto *TSI = TD->getTypeSourceInfo();
-if (!TSI)
-  return;
-// Try to highlight as underlying type.
-if (addType(Loc, TSI->getType().getTypePtrOrNull()))
-  return;
-// Fallback to the typedef highlighting kind.
-addToken(Loc, HighlightingKind::Typedef);
-  }
-
-  bool addType(SourceLocation Loc, const Type *TP) {
+  llvm::Optional kindForType(const Type *TP) {
 if (!TP)

hokein wrote:
> how about moving out this method (and `kindForDecl`) of the class, they seem 
> to not depend on any fields of the class?
Makes sense. Done.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67341



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

[PATCH] D67341: [clangd] Simplify semantic highlighting visitor

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov updated this revision to Diff 219503.
ilya-biryukov marked 6 inline comments as done.
ilya-biryukov added a comment.

- Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67341

Files:
  clang-tools-extra/clangd/SemanticHighlighting.cpp

Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -14,6 +14,7 @@
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Decl.h"
 #include "clang/AST/DeclCXX.h"
+#include "clang/AST/DeclarationName.h"
 #include "clang/AST/RecursiveASTVisitor.h"
 #include "clang/AST/Type.h"
 #include "clang/AST/TypeLoc.h"
@@ -24,6 +25,77 @@
 namespace clangd {
 namespace {
 
+/// Some names are not written in the source code and cannot be highlighted,
+/// e.g. anonymous classes. This function detects those cases.
+bool canHighlightName(DeclarationName Name) {
+  if (Name.getNameKind() == DeclarationName::CXXConstructorName ||
+  Name.getNameKind() == DeclarationName::CXXUsingDirective)
+return true;
+  auto *II = Name.getAsIdentifierInfo();
+  return II && !II->getName().empty();
+}
+
+llvm::Optional kindForType(const Type *TP);
+llvm::Optional kindForDecl(const NamedDecl *D) {
+  if (auto *TD = dyn_cast(D)) {
+// We try to highlight typedefs as their underlying type.
+if (auto K = kindForType(TD->getUnderlyingType().getTypePtrOrNull()))
+  return K;
+// And fallback to a generic kind if this fails.
+return HighlightingKind::Typedef;
+  }
+  // We highlight class decls, constructor decls and destructor decls as
+  // `Class` type. The destructor decls are handled in `VisitTypeLoc` (we
+  // will visit a TypeLoc where the underlying Type is a CXXRecordDecl).
+  if (auto *RD = llvm::dyn_cast(D)) {
+// We don't want to highlight lambdas like classes.
+if (RD->isLambda())
+  return llvm::None;
+return HighlightingKind::Class;
+  }
+  if (isa(D) || isa(D) ||
+  isa(D))
+return HighlightingKind::Class;
+  if (auto *MD = dyn_cast(D))
+return MD->isStatic() ? HighlightingKind::StaticMethod
+  : HighlightingKind::Method;
+  if (isa(D))
+return HighlightingKind::Field;
+  if (isa(D))
+return HighlightingKind::Enum;
+  if (isa(D))
+return HighlightingKind::EnumConstant;
+  if (isa(D))
+return HighlightingKind::Parameter;
+  if (auto *VD = dyn_cast(D))
+return VD->isStaticDataMember()
+   ? HighlightingKind::StaticField
+   : VD->isLocalVarDecl() ? HighlightingKind::LocalVariable
+  : HighlightingKind::Variable;
+  if (isa(D))
+return HighlightingKind::Variable;
+  if (isa(D))
+return HighlightingKind::Function;
+  if (isa(D) || isa(D) ||
+  isa(D))
+return HighlightingKind::Namespace;
+  if (isa(D) || isa(D) ||
+  isa(D))
+return HighlightingKind::TemplateParameter;
+  return llvm::None;
+}
+llvm::Optional kindForType(const Type *TP) {
+  if (!TP)
+return llvm::None;
+  if (TP->isBuiltinType()) // Builtins are special, they do not have decls.
+return HighlightingKind::Primitive;
+  if (auto *TD = dyn_cast(TP))
+return kindForDecl(TD->getDecl());
+  if (auto *TD = TP->getAsTagDecl())
+return kindForDecl(TD);
+  return llvm::None;
+}
+
 // Collects all semantic tokens in an ASTContext.
 class HighlightingTokenCollector
 : public RecursiveASTVisitor {
@@ -72,66 +144,30 @@
 
   bool VisitNamespaceAliasDecl(NamespaceAliasDecl *NAD) {
 // The target namespace of an alias can not be found in any other way.
-addToken(NAD->getTargetNameLoc(), HighlightingKind::Namespace);
+addToken(NAD->getTargetNameLoc(), NAD->getAliasedNamespace());
 return true;
   }
 
   bool VisitMemberExpr(MemberExpr *ME) {
-const auto *MD = ME->getMemberDecl();
-if (isa(MD))
-  // When calling the destructor manually like: AAA::~A(); The ~ is a
-  // MemberExpr. Other methods should still be highlighted though.
-  return true;
-if (isa(MD))
-  // The MemberLoc is invalid for C++ conversion operators. We do not
-  // attempt to add tokens with invalid locations.
-  return true;
-addToken(ME->getMemberLoc(), MD);
+if (canHighlightName(ME->getMemberNameInfo().getName()))
+  addToken(ME->getMemberLoc(), ME->getMemberDecl());
 return true;
   }
 
   bool VisitNamedDecl(NamedDecl *ND) {
-// UsingDirectiveDecl's namespaces do not show up anywhere else in the
-// Visit/Traverse mehods. But they should also be highlighted as a
-// namespace.
-if (const auto *UD = dyn_cast(ND)) {
-  addToken(UD->getIdentLocation(), HighlightingKind::Namespace);
-  return true;
-}
-
-// Constructors' TypeLoc has a TypePtr that is a FunctionProtoType. It has
-// no 

[PATCH] D67264: [clangd] Collect location of macro definition in the ParsedAST

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 219501.
hokein marked an inline comment as done.
hokein added a comment.

address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67264

Files:
  clang-tools-extra/clangd/ParsedAST.cpp
  clang-tools-extra/clangd/ParsedAST.h
  clang-tools-extra/clangd/SemanticHighlighting.cpp
  clang-tools-extra/clangd/unittests/ParsedASTTests.cpp
  clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp

Index: clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
===
--- clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
+++ clang-tools-extra/clangd/unittests/SemanticHighlightingTests.cpp
@@ -392,18 +392,19 @@
   R"cpp(
   #define DEF_MULTIPLE(X) namespace X { class X { int X; }; }
   #define DEF_CLASS(T) class T {};
+  // Preamble ends.
   $Macro[[DEF_MULTIPLE]](XYZ);
   $Macro[[DEF_MULTIPLE]](XYZW);
   $Macro[[DEF_CLASS]]($Class[[A]])
-  #define MACRO_CONCAT(X, V, T) T foo##X = V
-  #define DEF_VAR(X, V) int X = V
-  #define DEF_VAR_T(T, X, V) T X = V
-  #define DEF_VAR_REV(V, X) DEF_VAR(X, V)
-  #define CPY(X) X
-  #define DEF_VAR_TYPE(X, Y) X Y
-  #define SOME_NAME variable
-  #define SOME_NAME_SET variable2 = 123
-  #define INC_VAR(X) X += 2
+  #define $Macro[[MACRO_CONCAT]](X, V, T) T foo##X = V
+  #define $Macro[[DEF_VAR]](X, V) int X = V
+  #define $Macro[[DEF_VAR_T]](T, X, V) T X = V
+  #define $Macro[[DEF_VAR_REV]](V, X) DEF_VAR(X, V)
+  #define $Macro[[CPY]](X) X
+  #define $Macro[[DEF_VAR_TYPE]](X, Y) X Y
+  #define $Macro[[SOME_NAME]] variable
+  #define $Macro[[SOME_NAME_SET]] variable2 = 123
+  #define $Macro[[INC_VAR]](X) X += 2
   $Primitive[[void]] $Function[[foo]]() {
 $Macro[[DEF_VAR]]($LocalVariable[[X]],  123);
 $Macro[[DEF_VAR_REV]](908, $LocalVariable[[XY]]);
@@ -422,8 +423,8 @@
   $Macro[[DEF_VAR]]($Variable[[XYZ]], 567);
   $Macro[[DEF_VAR_REV]](756, $Variable[[AB]]);
 
-  #define CALL_FN(F) F();
-  #define DEF_FN(F) void F ()
+  #define $Macro[[CALL_FN]](F) F();
+  #define $Macro[[DEF_FN]](F) void F ()
   $Macro[[DEF_FN]]($Function[[g]]) {
 $Macro[[CALL_FN]]($Function[[foo]]);
   }
@@ -431,6 +432,7 @@
   R"cpp(
   #define fail(expr) expr
   #define assert(COND) if (!(COND)) { fail("assertion failed" #COND); }
+  // Preamble ends.
   $Primitive[[int]] $Variable[[x]];
   $Primitive[[int]] $Variable[[y]];
   $Primitive[[int]] $Function[[f]]();
@@ -439,7 +441,7 @@
 $Macro[[assert]]($Variable[[x]] != $Function[[f]]());
   }
 )cpp",
-R"cpp(
+  R"cpp(
   struct $Class[[S]] {
 $Primitive[[float]] $Field[[Value]];
 $Class[[S]] *$Field[[Next]];
Index: clang-tools-extra/clangd/unittests/ParsedASTTests.cpp
===
--- clang-tools-extra/clangd/unittests/ParsedASTTests.cpp
+++ clang-tools-extra/clangd/unittests/ParsedASTTests.cpp
@@ -230,26 +230,28 @@
 TEST(ParsedASTTest, CollectsMainFileMacroExpansions) {
   Annotations TestCase(R"cpp(
 #define MACRO_ARGS(X, Y) X Y
+// - premable ends, macros inside preamble are not considered in main file.
 ^ID(int A);
 // Macro arguments included.
 ^MACRO_ARGS(^MACRO_ARGS(^MACRO_EXP(int), A), ^ID(= 2));
 
 // Macro names inside other macros not included.
-#define FOO BAR
-#define BAR 1
+#define ^MACRO_ARGS2(X, Y) X Y
+#define ^FOO BAR
+#define ^BAR 1
 int A = ^FOO;
 
 // Macros from token concatenations not included.
-#define CONCAT(X) X##A()
-#define PREPEND(X) MACRO##X()
-#define MACROA() 123
+#define ^CONCAT(X) X##A()
+#define ^PREPEND(X) MACRO##X()
+#define ^MACROA() 123
 int B = ^CONCAT(MACRO);
 int D = ^PREPEND(A)
 
 // Macros included not from preamble not included.
 #include "foo.inc"
 
-#define assert(COND) if (!(COND)) { printf("%s", #COND); exit(0); }
+#define ^assert(COND) if (!(COND)) { printf("%s", #COND); exit(0); }
 
 void test() {
   // Includes macro expansions in arguments that are expressions
@@ -268,8 +270,7 @@
 int D = DEF;
   )cpp";
   ParsedAST AST = TU.build();
-  const std::vector  =
-  AST.getMainFileExpansions();
+  const std::vector  = AST.getMacros();
   std::vector MacroExpansionPositions;
   for (const auto  : MacroExpansionLocations)
 MacroExpansionPositions.push_back(
Index: clang-tools-extra/clangd/SemanticHighlighting.cpp
===
--- clang-tools-extra/clangd/SemanticHighlighting.cpp
+++ clang-tools-extra/clangd/SemanticHighlighting.cpp
@@ -35,10 +35,8 @@
 TraverseAST(AST.getASTContext());
 // Add highlightings for macro expansions as they 

[PATCH] D67264: [clangd] Collect location of macro definition in the ParsedAST

[Haojian Wu via Phabricator via cfe-commits]

hokein added a comment.

In D67264#1663285 , @ilya-biryukov 
wrote:

> LGTM.
>
> We should probably also take a look at highlighting macros inside the 
> preamble part of the main file.
>  @hokein, are you planning to do this or should we just file a bug for this 
> for now?


I will file a bug in case we don't forget it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67264



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

[PATCH] D67185: [RISCV] Add support for -ffixed-xX flags

[Sam Elliott via Phabricator via cfe-commits]

lenary added a subscriber: luismarques.
lenary added a comment.

Nice, I like this new approach! One naming nit, but overall I think this is 
much better than the first version of the patch.

LGTM but I would like @luismarques to take a look too.




Comment at: llvm/lib/Target/RISCV/RISCVSubtarget.h:49
   RISCVABI::ABI TargetABI = RISCVABI::ABI_Unknown;
+  BitVector ReserveRegister;
   RISCVFrameLowering FrameLowering;

Nit: Can this have a name that reveals it is for registers that are reserved by 
the user, rather than generally reserved? 

We would like to differentiate `ra` being reserved because of the calling 
convention, vs `ra` being reserved because a user asked for `-ffixed-x1`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67185



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

[PATCH] D67246: clang-format: Add support for formatting lambdas with explicit template parameters.

[Krasimir Georgiev via Phabricator via cfe-commits]

krasimir added a comment.

I'll need some more time to investigate the implications of this with respect 
to Objective-C disambiguation stuff. 
Specifically, this may interact with funny ways with the heuristic outlined in 
(old) UnwrappedLineParser.cpp line 1453:

  // In a C++ lambda a template type can only occur after an arrow. We use
  // this as an heuristic to distinguish between Objective-C expressions
  // followed by an `a->b` expression, such as:
  // ([obj func:arg] + a->b)

At least we'll have to update this comment accordingly, otherwise it will be 
confusing.




Comment at: clang/lib/Format/TokenAnnotator.cpp:44
+/// With `Left` being '(', check if we're at either `[...](` or
+/// `...]<...>(`.
+static bool isLambdaParameterList(const FormatToken *Left) {

nit: add a `[` in the second case, like `[...]<...>(`. Also I'd suggest 
extending this sentence with: ", where the `[` opens a lambda capture list", 
because we explicitly check the `[` for that and to disambiguate between the 
case this is interested in and Objective-C method calls followed by 
function-invocation style call, like in `[obj meth]()`.



Comment at: clang/lib/Format/TokenAnnotator.cpp:50
+  // Skip <...> if present.
+  if (Left->Previous && Left->Previous->is(tok::greater) &&
+  Left->Previous->MatchingParen &&

The first `Left->Previous` check is unnecessary here, following the previous 
`if`.



Comment at: clang/lib/Format/TokenAnnotator.cpp:55
+
+  // Check for `[...](`.
+  return Left->Previous && Left->Previous->is(tok::r_square) &&

nit: consider replacing with 
```
Check for `[...]`
```


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

https://reviews.llvm.org/D67246



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

[PATCH] D67140: [analyzer][NFC] Fix inconsistent references to checkers as "checks"

[Dmitri Gribenko via Phabricator via cfe-commits]

gribozavr added a comment.

In D67140#1664106 , @NoQ wrote:

> In D67140#1659982 , @gribozavr wrote:
>
> > We should take a page from desktop software here. If the messages were in a 
> > separate file, there would be a lot of people capable of mass-editing them. 
> > When messages are hardcoded in the tool code, navigating and editing them 
> > requires more skill, and definitely a lot more jumping around.
>
>
> In the Static Analyzer there's often an explosive amount of dynamically 
> generated messages that are going to be pretty hard to stuff into a tablegen 
> pattern. Say, you can probably turn this 
> 
>  into "`%0 %1 %2 with a %3 retain count into an out parameter %4%5`" but 
> would it really help?


Unfortunately, that message is already not following best practices. One should 
not be passing snippets in natural language into substitutions. Every character 
that is a natural language construct should be in the message string. The only 
allowed substitutions are types, names, numbers and such. We already support 
%select in message strings, but there are frameworks that are more flexible -- 
we can port features from them into our message strings as needed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67140



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

[PATCH] D67058: [clang][CodeGen] Add alias for cpu_dispatch function with IFunc & Fix resolver linkage type

[Sr.Zhang via Phabricator via cfe-commits]

zsrkmyn added inline comments.



Comment at: clang/lib/CodeGen/CodeGenModule.cpp:3002
 false);
 llvm::Constant *Resolver = GetOrCreateLLVMFunction(
 MangledName + ".resolver", ResolverType, GlobalDecl{},

erichkeane wrote:
> zsrkmyn wrote:
> > zsrkmyn wrote:
> > > erichkeane wrote:
> > > > zsrkmyn wrote:
> > > > > erichkeane wrote:
> > > > > > This Resolver should have the same linkage as below.
> > > > > Actually, I wanted to set linkage here at the first time, but failed. 
> > > > > When compiling code with cpu_specific but no cpu_dispatch, we cannot 
> > > > > set it as LinkOnceODR or WeakODR. E.g.:
> > > > > 
> > > > > ```
> > > > > $ cat specific_only.c
> > > > > __declspec(cpu_specific(pentium_iii))
> > > > > int foo(void) { return 0; }
> > > > > int usage() { return foo(); }
> > > > > 
> > > > > $ clang -fdeclspec specific_only.c
> > > > >  
> > > > > Global is external, but doesn't have external or weak linkage!
> > > > > 
> > > > > i32 ()* ()* @foo.resolver 
> > > > > 
> > > > > fatal error: error in backend: Broken module found, compilation 
> > > > > aborted!   
> > > > > ```
> > > > > 
> > > > > This is found by lit test test/CodeGen/attr-cpuspecific.c, in which 
> > > > > 'SingleVersion()' doesn't have a cpu_dispatch declaration.
> > > > The crash message is complaining it isn't external/weak.  However, 
> > > > WeakODR should count, right?  Can you look into it a bit more to see 
> > > > what it thinks is broken?
> > > No, actually I've tried it earlier with the example I mentioned in my 
> > > last comment, but WeakODR still makes compiler complaining. I think it's 
> > > `foo.resolver` that cannot be declared with as WeakODR/LinkOnceODR 
> > > without definition. But I'm really not familiar with these rules.
> > According to the `Verifier::visitGlobalValue()` in Verify.cpp, an 
> > declaration can only be `ExternalLinkage` or `ExternalWeakLinkage`. So I 
> > still believe we cannot set the resolver to 
> > `LinkOnceODRLinkage/WeakODRLinkage` here, as they are declared but not 
> > defined when we only have `cpu_specified` but no `cpu_dispatch` in a TU as 
> > the example above.
> That doesn't seem right then.  IF it allows ExternalWeakLinkage I'd expect 
> WeakODR to work as well, since it is essentially the same thing.
I think we should have a double check. It is said "It is illegal for a function 
declaration to have any linkage type other than `external` or `extern_weak`" at 
the last line of section Linkage Type in the reference manual [1]. I guess 
`weak_odr` is not designed for declaration purpose and should be only used by 
definition.

[1] https://llvm.org/docs/LangRef.html#linkage-types


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

https://reviews.llvm.org/D67058



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

[libunwind] r371500 - Creating release candidate rc4 from release_900 branch

[Hans Wennborg via cfe-commits]

Author: hans
Date: Tue Sep 10 02:05:55 2019
New Revision: 371500

URL: http://llvm.org/viewvc/llvm-project?rev=371500=rev
Log:
Creating release candidate rc4 from release_900 branch

Added:
libunwind/tags/RELEASE_900/rc4/
  - copied from r371499, libunwind/branches/release_90/

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

[libclc] r371500 - Creating release candidate rc4 from release_900 branch

[Hans Wennborg via cfe-commits]

Author: hans
Date: Tue Sep 10 02:05:55 2019
New Revision: 371500

URL: http://llvm.org/viewvc/llvm-project?rev=371500=rev
Log:
Creating release candidate rc4 from release_900 branch

Added:
libclc/tags/RELEASE_900/rc4/
  - copied from r371499, libclc/branches/release_90/

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

[PATCH] D67341: [clangd] Simplify semantic highlighting visitor

[Haojian Wu via Phabricator via cfe-commits]

hokein added a comment.

thanks, looks good, just a few nits.




Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:34
+return true;
+  if (!Name.isIdentifier())
+return false;

nit: I think the check is redundant, getAsIdentifierInfo() will return nullptr 
if `!Name.isIdentifier()`.



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:37
+  auto *II = Name.getAsIdentifierInfo();
+  return II && II->getName() != "";
+}

nit: `!II->getName().empty()`



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:169
 private:
-  void addTokenForTypedef(SourceLocation Loc, const TypedefNameDecl *TD) {
-auto *TSI = TD->getTypeSourceInfo();
-if (!TSI)
-  return;
-// Try to highlight as underlying type.
-if (addType(Loc, TSI->getType().getTypePtrOrNull()))
-  return;
-// Fallback to the typedef highlighting kind.
-addToken(Loc, HighlightingKind::Typedef);
-  }
-
-  bool addType(SourceLocation Loc, const Type *TP) {
+  llvm::Optional kindForType(const Type *TP) {
 if (!TP)

how about moving out this method (and `kindForDecl`) of the class, they seem to 
not depend on any fields of the class?



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:212
+  return HighlightingKind::Parameter;
+if (const VarDecl *VD = dyn_cast(D))
+  return VD->isStaticDataMember()

nit: auto



Comment at: clang-tools-extra/clangd/SemanticHighlighting.cpp:260
+  void addToken(SourceLocation Loc, const NamedDecl *D) {
+auto K = kindForDecl(D);
+if (!K)

maybe 

```
if (auto K = kindForDecl(D))
   addToken(Loc, *K);
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67341



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

[PATCH] D67135: [clang-tidy] performance-inefficient-vector-operation: Support proto repeated field

[Haojian Wu via Phabricator via cfe-commits]

hokein added inline comments.



Comment at: 
clang-tools-extra/clang-tidy/performance/InefficientVectorOperationCheck.cpp:227
+std::string MutableFieldName =
+("mutable_" + ProtoAddFieldCall->getMethodDecl()->getName().substr(4))
+.str();

congliu wrote:
> hokein wrote:
> > nit: getName().drop_front(sizeof("add_")).
> Used 'sizeof("add_")-1' since "add_" is const char [5].
how about?

```
llvm::StringRef FieldName =
ProtoAddFieldCall->getMethodDecl()->getName();
FieldName.consume_front("add_");
std::string MutableFieldName = ...;
```



Comment at: 
clang-tools-extra/clang-tidy/performance/InefficientVectorOperationCheck.cpp:233
+  if (Matches.empty()) {
+// There is no method with name "mutable_xxx".
+return;

congliu wrote:
> hokein wrote:
> > for repeated fields, there should be `add_foo`, `mutable_foo` methods in 
> > the proto generated code 
> > (https://developers.google.com/protocol-buffers/docs/reference/cpp-generated#repeatednumeric).
> > 
> > So I think we can remove this check here.
> I intended to rule out the corner cases when a proto field name is "add_xxx". 
> But now I think checking whether there is a "mutable_xxx" method is not a 
> effective way to rule out the corner case. A simpler way is just checking 
> whether add_xxx is const... I have updated the matcher to exclude const 
> methods.
I wasn't aware of this corner case, could you add a comment describing the 
heuristic we use here (around the matcher)?



Comment at: 
clang-tools-extra/clang-tidy/performance/InefficientVectorOperationCheck.cpp:15
 #include "../utils/OptionsUtils.h"
+#include 
"third_party/llvm/llvm/tools/clang/include/clang/ASTMatchers/ASTMatchers.h"
 

the include (probably added by clangd) is for google internal style, I believe 
you are developing at google internal codebase (rather than the opensource LLVM 
codebase)?



Comment at: 
clang-tools-extra/clang-tidy/performance/InefficientVectorOperationCheck.cpp:192
 
+  const CXXMemberCallExpr *AppendCall = VectorAppendCall;
+  if (!AppendCall)

nit:  `const CXXMemberCallExpr *AppendCall =VectorAppendCall? 
VectorAppendCall:ProtoAddFieldCall;`



Comment at: 
clang-tools-extra/clang-tidy/performance/InefficientVectorOperationCheck.cpp:195
+AppendCall = ProtoAddFieldCall;
+  if (!AppendCall)
+return;

In theory, this case should not be happened -- the callback is only invoked 
when we find a match for the interesting vector/proto cases. 

Just use `assert(AppendCall) << "no append call expression"`.



Comment at: 
clang-tools-extra/clang-tidy/performance/InefficientVectorOperationCheck.cpp:263
+  << AppendCall->getMethodDecl()->getDeclName()
+  << (VectorAppendCall != nullptr ? "vector" : "repeated field");
+  if (!ReserveSize.empty()) {

I think the container name doesn't provide much information in the diag 
message, maybe just use 
`%0 is called inside a loop; consider pre-allocating the container capacity 
before the loop`?


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

https://reviews.llvm.org/D67135



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

[PATCH] D67304: Emit -Wmicrosoft-enum-value warning instead of error in MS ABI

[Hans Wennborg via Phabricator via cfe-commits]

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

lgtm


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D67304



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

[PATCH] D66003: [RISCV] Make -march=rv{32, 64}gc the default in RISC-V Linux

[Roger Ferrer Ibanez via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL371496: [RISCV] Make -march=rv{32,64}gc the default in 
RISC-V Linux (authored by rogfer01, committed by ).
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Changed prior to commit:
  https://reviews.llvm.org/D66003?vs=214345=219488#toc

Repository:
  rL LLVM

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

https://reviews.llvm.org/D66003

Files:
  cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp
  cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.h
  cfe/trunk/lib/Driver/ToolChains/Clang.cpp
  cfe/trunk/test/Driver/riscv-features.c


Index: cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.h
===
--- cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.h
+++ cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.h
@@ -19,7 +19,8 @@
 namespace driver {
 namespace tools {
 namespace riscv {
-void getRISCVTargetFeatures(const Driver , const llvm::opt::ArgList ,
+void getRISCVTargetFeatures(const Driver , const llvm::Triple ,
+const llvm::opt::ArgList ,
 std::vector );
 StringRef getRISCVABI(const llvm::opt::ArgList ,
   const llvm::Triple );
Index: cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp
@@ -12,6 +12,7 @@
 #include "clang/Driver/DriverDiagnostic.h"
 #include "clang/Driver/Options.h"
 #include "llvm/Option/ArgList.h"
+#include "llvm/ADT/Optional.h"
 #include "llvm/Support/TargetParser.h"
 #include "llvm/Support/raw_ostream.h"
 #include "ToolChains/CommonArgs.h"
@@ -353,14 +354,18 @@
   return true;
 }
 
-void riscv::getRISCVTargetFeatures(const Driver , const ArgList ,
+void riscv::getRISCVTargetFeatures(const Driver , const llvm::Triple ,
+   const ArgList ,
std::vector ) {
-  if (const Arg *A = Args.getLastArg(options::OPT_march_EQ)) {
-StringRef MArch = A->getValue();
+  llvm::Optional MArch;
+  if (const Arg *A = Args.getLastArg(options::OPT_march_EQ))
+MArch = A->getValue();
+  else if (Triple.getOS() == llvm::Triple::Linux)
+// RISC-V Linux defaults to rv{32,64}gc.
+MArch = Triple.getArch() == llvm::Triple::riscv32 ? "rv32gc" : "rv64gc";
 
-if (!getArchFeatures(D, MArch, Features, Args))
-  return;
-  }
+  if (MArch.hasValue() && !getArchFeatures(D, *MArch, Features, Args))
+return;
 
   // -mrelax is default, unless -mno-relax is specified.
   if (Args.hasFlag(options::OPT_mrelax, options::OPT_mno_relax, true))
Index: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
===
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp
@@ -336,7 +336,7 @@
 break;
   case llvm::Triple::riscv32:
   case llvm::Triple::riscv64:
-riscv::getRISCVTargetFeatures(D, Args, Features);
+riscv::getRISCVTargetFeatures(D, Triple, Args, Features);
 break;
   case llvm::Triple::systemz:
 systemz::getSystemZTargetFeatures(Args, Features);
Index: cfe/trunk/test/Driver/riscv-features.c
===
--- cfe/trunk/test/Driver/riscv-features.c
+++ cfe/trunk/test/Driver/riscv-features.c
@@ -18,4 +18,15 @@
 
 // SAVE-RESTORE: warning: the clang compiler does not support '-msave-restore'
 // NO-SAVE-RESTORE-NOT: warning: the clang compiler does not support
-// DEFAULT-NOT: warning: the clang compiler does not support
\ No newline at end of file
+// DEFAULT-NOT: warning: the clang compiler does not support
+
+// RUN: %clang -target riscv32-linux -### %s -fsyntax-only 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=DEFAULT-LINUX
+// RUN: %clang -target riscv64-linux -### %s -fsyntax-only 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=DEFAULT-LINUX
+
+// DEFAULT-LINUX: "-target-feature" "+m"
+// DEFAULT-LINUX-SAME: "-target-feature" "+a"
+// DEFAULT-LINUX-SAME: "-target-feature" "+f"
+// DEFAULT-LINUX-SAME: "-target-feature" "+d"
+// DEFAULT-LINUX-SAME: "-target-feature" "+c"


Index: cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.h
===
--- cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.h
+++ cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.h
@@ -19,7 +19,8 @@
 namespace driver {
 namespace tools {
 namespace riscv {
-void getRISCVTargetFeatures(const Driver , const llvm::opt::ArgList ,
+void getRISCVTargetFeatures(const Driver , const llvm::Triple ,
+const llvm::opt::ArgList ,
 std::vector );
 StringRef getRISCVABI(const llvm::opt::ArgList ,
   const llvm::Triple );
Index: cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp

r371496 - [RISCV] Make -march=rv{32, 64}gc the default in RISC-V Linux

[Roger Ferrer Ibanez via cfe-commits]

Author: rogfer01
Date: Tue Sep 10 01:16:24 2019
New Revision: 371496

URL: http://llvm.org/viewvc/llvm-project?rev=371496=rev
Log:
[RISCV] Make -march=rv{32,64}gc the default in RISC-V Linux

This is the logical follow-up of D65634.

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

Modified:
cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp
cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.h
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/test/Driver/riscv-features.c

Modified: cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp?rev=371496=371495=371496=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.cpp Tue Sep 10 01:16:24 2019
@@ -12,6 +12,7 @@
 #include "clang/Driver/DriverDiagnostic.h"
 #include "clang/Driver/Options.h"
 #include "llvm/Option/ArgList.h"
+#include "llvm/ADT/Optional.h"
 #include "llvm/Support/TargetParser.h"
 #include "llvm/Support/raw_ostream.h"
 #include "ToolChains/CommonArgs.h"
@@ -353,14 +354,18 @@ static bool getArchFeatures(const Driver
   return true;
 }
 
-void riscv::getRISCVTargetFeatures(const Driver , const ArgList ,
+void riscv::getRISCVTargetFeatures(const Driver , const llvm::Triple ,
+   const ArgList ,
std::vector ) {
-  if (const Arg *A = Args.getLastArg(options::OPT_march_EQ)) {
-StringRef MArch = A->getValue();
+  llvm::Optional MArch;
+  if (const Arg *A = Args.getLastArg(options::OPT_march_EQ))
+MArch = A->getValue();
+  else if (Triple.getOS() == llvm::Triple::Linux)
+// RISC-V Linux defaults to rv{32,64}gc.
+MArch = Triple.getArch() == llvm::Triple::riscv32 ? "rv32gc" : "rv64gc";
 
-if (!getArchFeatures(D, MArch, Features, Args))
-  return;
-  }
+  if (MArch.hasValue() && !getArchFeatures(D, *MArch, Features, Args))
+return;
 
   // -mrelax is default, unless -mno-relax is specified.
   if (Args.hasFlag(options::OPT_mrelax, options::OPT_mno_relax, true))

Modified: cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.h?rev=371496=371495=371496=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.h (original)
+++ cfe/trunk/lib/Driver/ToolChains/Arch/RISCV.h Tue Sep 10 01:16:24 2019
@@ -19,7 +19,8 @@ namespace clang {
 namespace driver {
 namespace tools {
 namespace riscv {
-void getRISCVTargetFeatures(const Driver , const llvm::opt::ArgList ,
+void getRISCVTargetFeatures(const Driver , const llvm::Triple ,
+const llvm::opt::ArgList ,
 std::vector );
 StringRef getRISCVABI(const llvm::opt::ArgList ,
   const llvm::Triple );

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=371496=371495=371496=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Tue Sep 10 01:16:24 2019
@@ -336,7 +336,7 @@ static void getTargetFeatures(const Tool
 break;
   case llvm::Triple::riscv32:
   case llvm::Triple::riscv64:
-riscv::getRISCVTargetFeatures(D, Args, Features);
+riscv::getRISCVTargetFeatures(D, Triple, Args, Features);
 break;
   case llvm::Triple::systemz:
 systemz::getSystemZTargetFeatures(Args, Features);

Modified: cfe/trunk/test/Driver/riscv-features.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/riscv-features.c?rev=371496=371495=371496=diff
==
--- cfe/trunk/test/Driver/riscv-features.c (original)
+++ cfe/trunk/test/Driver/riscv-features.c Tue Sep 10 01:16:24 2019
@@ -18,4 +18,15 @@
 
 // SAVE-RESTORE: warning: the clang compiler does not support '-msave-restore'
 // NO-SAVE-RESTORE-NOT: warning: the clang compiler does not support
-// DEFAULT-NOT: warning: the clang compiler does not support
\ No newline at end of file
+// DEFAULT-NOT: warning: the clang compiler does not support
+
+// RUN: %clang -target riscv32-linux -### %s -fsyntax-only 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=DEFAULT-LINUX
+// RUN: %clang -target riscv64-linux -### %s -fsyntax-only 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=DEFAULT-LINUX
+
+// DEFAULT-LINUX: "-target-feature" "+m"
+// DEFAULT-LINUX-SAME: "-target-feature" "+a"
+// DEFAULT-LINUX-SAME: "-target-feature" "+f"
+// DEFAULT-LINUX-SAME: "-target-feature" "+d"
+// DEFAULT-LINUX-SAME: "-target-feature" "+c"


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