[clang] aaf7ffd - Teach `-fsanitize=fuzzer` to respect `-static` and `-static-libstdc++` when adding C++ standard libraries.

[Chandler Carruth via cfe-commits]

Author: Chandler Carruth
Date: 2020-10-27T01:36:54Z
New Revision: aaf7ffd4e1aa81c7f4cc8da4f943982ca2e131f4

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

LOG: Teach `-fsanitize=fuzzer` to respect `-static` and `-static-libstdc++` 
when adding C++ standard libraries.

Summary:
Makes linking the sanitizers follow the same logic as the rest of the
driver with respect to the static linking strategy for the C++ standard
library.

Subscribers: mcrosier, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/CommonArgs.cpp
clang/test/Driver/fuzzer.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp 
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index 692d0600bad3..23522e0886ff 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -833,8 +833,15 @@ bool tools::addSanitizerRuntimes(const ToolChain , 
const ArgList ,
 if (SanArgs.needsFuzzerInterceptors())
   addSanitizerRuntime(TC, Args, CmdArgs, "fuzzer_interceptors", false,
   true);
-if (!Args.hasArg(clang::driver::options::OPT_nostdlibxx))
+if (!Args.hasArg(clang::driver::options::OPT_nostdlibxx)) {
+  bool OnlyLibstdcxxStatic = Args.hasArg(options::OPT_static_libstdcxx) &&
+ !Args.hasArg(options::OPT_static);
+  if (OnlyLibstdcxxStatic)
+CmdArgs.push_back("-Bstatic");
   TC.AddCXXStdlibLibArgs(Args, CmdArgs);
+  if (OnlyLibstdcxxStatic)
+CmdArgs.push_back("-Bdynamic");
+}
   }
 
   for (auto RT : SharedRuntimes)

diff  --git a/clang/test/Driver/fuzzer.c b/clang/test/Driver/fuzzer.c
index 3fdf5ab9c9b9..d91dd573dec3 100644
--- a/clang/test/Driver/fuzzer.c
+++ b/clang/test/Driver/fuzzer.c
@@ -29,6 +29,23 @@
 // RUN: %clang -fsanitize=fuzzer -fsanitize-coverage=trace-pc %s -### 2>&1 | 
FileCheck --check-prefixes=CHECK-MSG %s
 // CHECK-MSG-NOT: argument unused during compilation
 
+// Check that we respect whether thes tandard library should be linked
+// statically.
+//
+// RUN: %clang -fsanitize=fuzzer -target i386-unknown-linux -stdlib=libstdc++ 
%s -### 2>&1 | FileCheck --check-prefixes=CHECK-LIBSTDCXX-DYNAMIC %s
+// CHECK-LIBSTDCXX-DYNAMIC-NOT: -Bstatic
+// CHECK-LIBSTDCXX-DYNAMIC: -lstdc++
+//
+// RUN: %clang -fsanitize=fuzzer -target i386-unknown-linux -stdlib=libstdc++ 
-static-libstdc++ %s -### 2>&1 | FileCheck 
--check-prefixes=CHECK-LIBSTDCXX-STATIC %s
+// CHECK-LIBSTDCXX-STATIC: "-Bstatic" "-lstdc++"
+//
+// RUN: %clang -fsanitize=fuzzer -target i386-unknown-linux -stdlib=libc++ %s 
-### 2>&1 | FileCheck --check-prefixes=CHECK-LIBCXX-DYNAMIC %s
+// CHECK-LIBCXX-DYNAMIC-NOT: -Bstatic
+// CHECK-LIBCXX-DYNAMIC: -lc++
+//
+// RUN: %clang -fsanitize=fuzzer -target i386-unknown-linux -stdlib=libc++ 
-static-libstdc++ %s -### 2>&1 | FileCheck --check-prefixes=CHECK-LIBCXX-STATIC 
%s
+// CHECK-LIBCXX-STATIC: "-Bstatic" "-lc++"
+
 int LLVMFuzzerTestOneInput(const char *Data, long Size) {
   return 0;
 }



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

[clang] dc1499b - Improve Clang's getting involved document and make it more inclusive in wording.

[Chandler Carruth via cfe-commits]

Author: Chandler Carruth
Date: 2019-10-23T16:11:24-07:00
New Revision: dc1499b90dc41838e1ee8c7052bbe9535b3609bb

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

LOG: Improve Clang's getting involved document and make it more inclusive in 
wording.

Summary: Working with Meike and others to improve the wording in this document.

Reviewers: klimek

Subscribers: mcrosier, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/www/get_involved.html

Removed: 




diff  --git a/clang/www/get_involved.html b/clang/www/get_involved.html
index ed961ca0b61c..fabaec46bda3 100755
--- a/clang/www/get_involved.html
+++ b/clang/www/get_involved.html
@@ -50,8 +50,8 @@ Follow what's going on
 as well.
 
 
-The best way to talk with other developers on the project is through the http://lists.llvm.org/mailman/listinfo/cfe-dev;>cfe-dev mailing
+The most common way to talk with other developers on the project is through
+the http://lists.llvm.org/mailman/listinfo/cfe-dev;>cfe-dev mailing
 list.  The clang mailing list is a very friendly place and we welcome
 newcomers.  In addition to the cfe-dev list, a significant amount of design
 discussion takes place on the Follow what's going on
 
 Contributing Extensions to Clang
 
-Clang has always been designed as a platform for experimentation,
+Clang is designed to support experimentation,
 allowing programmers to easily extend the compiler to support great
 new language features and tools. At some point, the authors of these
 extensions may propose that the extensions become a part of Clang
-itself, to benefit the whole Clang community. But not every idea--not
-even every great idea--should become part of Clang. Extensions
-(particularly language extensions) pose a long-term maintenance burden
-on Clang, and therefore the benefits of the extension must outweigh
-those costs. Hence, these are the seven criteria used to evaluate the
-merits of a proposed extension:
+itself, to benefit the whole Clang community. However, extensions
+(particularly language extensions) have long-term maintenance costs
+for Clang. The benefits of the extension need to be evaluated against
+these costs. The Clang project uses the following criteria for this
+evaluation:
 
 
-  Evidence of a significant user community: This is based on a number of 
factors, including an actual, existing user community, the perceived likelihood 
that users would adopt such a feature if it were available, and any 
"trickle-down" effects that come from, e.g., a library adopting the feature and 
providing benefits to its users.
-
-  A specific need to reside within the Clang tree: There are some 
extensions that would be better expressed as a separate tool, and should remain 
as separate tools even if they end up being hosted as part of the LLVM umbrella 
project.
-
-  A complete specification: The specification must be sufficient to 
understand the design of the feature as well as interpret the meaning of 
specific examples. The specification should be detailed enough that another 
compiler vendor could conceivably implement the feature.
-
-  Representation within the appropriate governing organization: For 
extensions to a language governed by a standards committee (C, C++, OpenCL), 
the extension itself must have an active proposal and proponent within that 
committee and have a reasonable chance of acceptance. Clang should drive the 
standard, not diverge from it. This criterion does not apply to all extensions, 
since some extensions fall outside of the realm of the standards bodies.
-
-  A long-term support plan: Contributing a non-trivial extension to Clang 
implies a commitment to supporting that extension, improving the implementation 
and specification as Clang evolves. The capacity of the contributor to make 
that commitment is as important as the commitment itself.
-
-  A high-quality implementation: The implementation must fit well into 
Clang's architecture, follow LLVM's coding conventions, and meet Clang's 
quality standards, including high-quality diagnostics and rich AST 
representations. This is particularly important for language extensions, 
because users will learn how those extensions work through the behavior of the 
compiler.
-
-  A proper test suite: Extensive testing is crucial to ensure that the 
language extension is not broken by ongoing maintenance in Clang. The test 
suite should be complete enough that another compiler vendor could conceivably 
validate their implementation of the feature against it.
+  Evidence of a significant user community: This is based on a number of
+  factors, including an existing user community, the perceived likelihood that
+  users would adopt such a feature if it were available, 

Re: r351629 - Emit !callback metadata and introduce the callback attribute

[Chandler Carruth via cfe-commits]

On Sat, Jan 19, 2019 at 2:18 AM Johannes Doerfert via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: jdoerfert
> Date: Fri Jan 18 21:36:54 2019
> New Revision: 351629
>
> URL: http://llvm.org/viewvc/llvm-project?rev=351629=rev
> Log:
> Emit !callback metadata and introduce the callback attribute
>
>   With commit r351627, LLVM gained the ability to apply (existing) IPO
>   optimizations on indirections through callbacks, or transitive calls.
>   The general idea is that we use an abstraction to hide the middle man
>   and represent the callback call in the context of the initial caller.
>   It is described in more detail in the commit message of the LLVM patch
>   r351627, the llvm::AbstractCallSite class description, and the
>   language reference section on callback-metadata.
>
>   This commit enables clang to emit !callback metadata that is
>   understood by LLVM. It does so in three different cases:
> 1) For known broker functions declarations that are directly
>generated, e.g., __kmpc_fork_call for the OpenMP pragma parallel.
> 2) For known broker functions that are identified by their name and
>source location through the builtin detection, e.g.,
>pthread_create from the POSIX thread API.
> 3) For user annotated functions that carry the "callback(callee, ...)"
>attribute. The attribute has to include the name, or index, of
>the callback callee and how the passed arguments can be
>identified (as many as the callback callee has). See the callback
>attribute documentation for detailed information.
>
> Differential Revision: https://reviews.llvm.org/D55483
>
> Added:
> cfe/trunk/test/CodeGen/attr-callback.c
> cfe/trunk/test/CodeGen/callback_annotated.c
> cfe/trunk/test/CodeGen/callback_openmp.c
> cfe/trunk/test/CodeGen/callback_pthread_create.c
> cfe/trunk/test/CodeGenCXX/attr-callback.cpp
> cfe/trunk/test/Sema/attr-callback-broken.c
> cfe/trunk/test/Sema/attr-callback.c
> cfe/trunk/test/SemaCXX/attr-callback-broken.cpp
> cfe/trunk/test/SemaCXX/attr-callback.cpp
> Modified:
> cfe/trunk/include/clang/AST/ASTContext.h
> cfe/trunk/include/clang/Basic/Attr.td
> cfe/trunk/include/clang/Basic/AttrDocs.td
> cfe/trunk/include/clang/Basic/Builtins.def
> cfe/trunk/include/clang/Basic/Builtins.h
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/lib/AST/ASTContext.cpp
> cfe/trunk/lib/Basic/Builtins.cpp
> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/lib/Parse/ParseDecl.cpp
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> cfe/trunk/test/Analysis/retain-release.m
> cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test
> cfe/trunk/test/OpenMP/parallel_codegen.cpp
> cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp
>
> Modified: cfe/trunk/include/clang/AST/ASTContext.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=351629=351628=351629=diff
>
> ==
> --- cfe/trunk/include/clang/AST/ASTContext.h (original)
> +++ cfe/trunk/include/clang/AST/ASTContext.h Fri Jan 18 21:36:54 2019
> @@ -2003,6 +2003,9 @@ public:
>  /// No error
>  GE_None,
>
> +/// Missing a type
> +GE_Missing_type,
> +
>  /// Missing a type from 
>  GE_Missing_stdio,
>
>
> Modified: cfe/trunk/include/clang/Basic/Attr.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=351629=351628=351629=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/Attr.td (original)
> +++ cfe/trunk/include/clang/Basic/Attr.td Fri Jan 18 21:36:54 2019
> @@ -190,6 +190,9 @@ class VariadicIdentifierArgument  // Like VariadicUnsignedArgument except values are ParamIdx.
>  class VariadicParamIdxArgument : Argument;
>
> +// A list of identifiers matching parameters or ParamIdx indices.
> +class VariadicParamOrParamIdxArgument : Argument;
> +
>  // Like VariadicParamIdxArgument but for a single function parameter
> index.
>  class ParamIdxArgument : Argument;
>
> @@ -1210,6 +1213,13 @@ def FormatArg : InheritableAttr {
>let Documentation = [Undocumented];
>  }
>
> +def Callback : InheritableAttr {
> +  let Spellings = [Clang<"callback">];
> +  let Args = [VariadicParamOrParamIdxArgument<"Encoding">];
> +  let Subjects = SubjectList<[Function]>;
> +  let Documentation = [CallbackDocs];
> +}
> +
>  def GNUInline : InheritableAttr {
>let Spellings = [GCC<"gnu_inline">];
>let Subjects = SubjectList<[Function]>;
>
> Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=351629=351628=351629=diff
>
> 

Re: r351629 - Emit !callback metadata and introduce the callback attribute

[Chandler Carruth via cfe-commits]

On Sat, Jan 19, 2019 at 2:18 AM Johannes Doerfert via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: jdoerfert
> Date: Fri Jan 18 21:36:54 2019
> New Revision: 351629
>
> URL: http://llvm.org/viewvc/llvm-project?rev=351629=rev
> Log:
> Emit !callback metadata and introduce the callback attribute
>
>   With commit r351627, LLVM gained the ability to apply (existing) IPO
>   optimizations on indirections through callbacks, or transitive calls.
>   The general idea is that we use an abstraction to hide the middle man
>   and represent the callback call in the context of the initial caller.
>   It is described in more detail in the commit message of the LLVM patch
>   r351627, the llvm::AbstractCallSite class description, and the
>   language reference section on callback-metadata.
>
>   This commit enables clang to emit !callback metadata that is
>   understood by LLVM. It does so in three different cases:
> 1) For known broker functions declarations that are directly
>generated, e.g., __kmpc_fork_call for the OpenMP pragma parallel.
> 2) For known broker functions that are identified by their name and
>source location through the builtin detection, e.g.,
>pthread_create from the POSIX thread API.
> 3) For user annotated functions that carry the "callback(callee, ...)"
>attribute. The attribute has to include the name, or index, of
>the callback callee and how the passed arguments can be
>identified (as many as the callback callee has). See the callback
>attribute documentation for detailed information.
>
> Differential Revision: https://reviews.llvm.org/D55483
>
> Added:
> cfe/trunk/test/CodeGen/attr-callback.c
> cfe/trunk/test/CodeGen/callback_annotated.c
> cfe/trunk/test/CodeGen/callback_openmp.c
> cfe/trunk/test/CodeGen/callback_pthread_create.c
> cfe/trunk/test/CodeGenCXX/attr-callback.cpp
> cfe/trunk/test/Sema/attr-callback-broken.c
> cfe/trunk/test/Sema/attr-callback.c
> cfe/trunk/test/SemaCXX/attr-callback-broken.cpp
> cfe/trunk/test/SemaCXX/attr-callback.cpp
> Modified:
> cfe/trunk/include/clang/AST/ASTContext.h
> cfe/trunk/include/clang/Basic/Attr.td
> cfe/trunk/include/clang/Basic/AttrDocs.td
> cfe/trunk/include/clang/Basic/Builtins.def
> cfe/trunk/include/clang/Basic/Builtins.h
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/lib/AST/ASTContext.cpp
> cfe/trunk/lib/Basic/Builtins.cpp
> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/lib/Parse/ParseDecl.cpp
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> cfe/trunk/test/Analysis/retain-release.m
> cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test
> cfe/trunk/test/OpenMP/parallel_codegen.cpp
> cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp
>
> Modified: cfe/trunk/include/clang/AST/ASTContext.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=351629=351628=351629=diff
>
> ==
> --- cfe/trunk/include/clang/AST/ASTContext.h (original)
> +++ cfe/trunk/include/clang/AST/ASTContext.h Fri Jan 18 21:36:54 2019
> @@ -2003,6 +2003,9 @@ public:
>  /// No error
>  GE_None,
>
> +/// Missing a type
> +GE_Missing_type,
> +
>  /// Missing a type from 
>  GE_Missing_stdio,
>
>
> Modified: cfe/trunk/include/clang/Basic/Attr.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=351629=351628=351629=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/Attr.td (original)
> +++ cfe/trunk/include/clang/Basic/Attr.td Fri Jan 18 21:36:54 2019
> @@ -190,6 +190,9 @@ class VariadicIdentifierArgument  // Like VariadicUnsignedArgument except values are ParamIdx.
>  class VariadicParamIdxArgument : Argument;
>
> +// A list of identifiers matching parameters or ParamIdx indices.
> +class VariadicParamOrParamIdxArgument : Argument;
> +
>  // Like VariadicParamIdxArgument but for a single function parameter
> index.
>  class ParamIdxArgument : Argument;
>
> @@ -1210,6 +1213,13 @@ def FormatArg : InheritableAttr {
>let Documentation = [Undocumented];
>  }
>
> +def Callback : InheritableAttr {
> +  let Spellings = [Clang<"callback">];
> +  let Args = [VariadicParamOrParamIdxArgument<"Encoding">];
> +  let Subjects = SubjectList<[Function]>;
> +  let Documentation = [CallbackDocs];
> +}
> +
>  def GNUInline : InheritableAttr {
>let Spellings = [GCC<"gnu_inline">];
>let Subjects = SubjectList<[Function]>;
>
> Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=351629=351628=351629=diff
>
> 

[libunwind] r351731 - Fix typos throughout the license files that somehow I and my reviewers

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Mon Jan 21 01:52:34 2019
New Revision: 351731

URL: http://llvm.org/viewvc/llvm-project?rev=351731=rev
Log:
Fix typos throughout the license files that somehow I and my reviewers
all missed!

Thanks to Alex Bradbury for pointing this out, and the fact that I never
added the intended `legacy` anchor to the developer policy. Add that
anchor too. With hope, this will cause the links to all resolve
successfully.

Modified:
libunwind/trunk/LICENSE.TXT

Modified: libunwind/trunk/LICENSE.TXT
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/LICENSE.TXT?rev=351731=351730=351731=diff
==
--- libunwind/trunk/LICENSE.TXT (original)
+++ libunwind/trunk/LICENSE.TXT Mon Jan 21 01:52:34 2019
@@ -234,7 +234,7 @@ mechanisms:
file.
 
 ==
-Legacy LLVM License (ttps://llvm.org/docs/DeveloperPolicy.html#legacy):
+Legacy LLVM License (https://llvm.org/docs/DeveloperPolicy.html#legacy):
 ==
 
 The libunwind library is dual licensed under both the University of Illinois


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

[clang-tools-extra] r351731 - Fix typos throughout the license files that somehow I and my reviewers

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Mon Jan 21 01:52:34 2019
New Revision: 351731

URL: http://llvm.org/viewvc/llvm-project?rev=351731=rev
Log:
Fix typos throughout the license files that somehow I and my reviewers
all missed!

Thanks to Alex Bradbury for pointing this out, and the fact that I never
added the intended `legacy` anchor to the developer policy. Add that
anchor too. With hope, this will cause the links to all resolve
successfully.

Modified:
clang-tools-extra/trunk/LICENSE.TXT
clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/license.txt

Modified: clang-tools-extra/trunk/LICENSE.TXT
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/LICENSE.TXT?rev=351731=351730=351731=diff
==
--- clang-tools-extra/trunk/LICENSE.TXT (original)
+++ clang-tools-extra/trunk/LICENSE.TXT Mon Jan 21 01:52:34 2019
@@ -234,7 +234,7 @@ mechanisms:
file.
 
 ==
-Legacy LLVM License (ttps://llvm.org/docs/DeveloperPolicy.html#legacy):
+Legacy LLVM License (https://llvm.org/docs/DeveloperPolicy.html#legacy):
 ==
 University of Illinois/NCSA
 Open Source License

Modified: clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/license.txt
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/license.txt?rev=351731=351730=351731=diff
==
--- clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/license.txt (original)
+++ clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/license.txt Mon Jan 21 
01:52:34 2019
@@ -234,7 +234,7 @@ mechanisms:
file.
 
 ==
-Legacy LLVM License (ttps://llvm.org/docs/DeveloperPolicy.html#legacy):
+Legacy LLVM License (https://llvm.org/docs/DeveloperPolicy.html#legacy):
 ==
 University of Illinois/NCSA
 Open Source License


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

[libclc] r351731 - Fix typos throughout the license files that somehow I and my reviewers

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Mon Jan 21 01:52:34 2019
New Revision: 351731

URL: http://llvm.org/viewvc/llvm-project?rev=351731=rev
Log:
Fix typos throughout the license files that somehow I and my reviewers
all missed!

Thanks to Alex Bradbury for pointing this out, and the fact that I never
added the intended `legacy` anchor to the developer policy. Add that
anchor too. With hope, this will cause the links to all resolve
successfully.

Modified:
libclc/trunk/LICENSE.TXT

Modified: libclc/trunk/LICENSE.TXT
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/LICENSE.TXT?rev=351731=351730=351731=diff
==
--- libclc/trunk/LICENSE.TXT (original)
+++ libclc/trunk/LICENSE.TXT Mon Jan 21 01:52:34 2019
@@ -234,7 +234,7 @@ mechanisms:
file.
 
 ==
-Legacy LLVM License (ttps://llvm.org/docs/DeveloperPolicy.html#legacy):
+Legacy LLVM License (https://llvm.org/docs/DeveloperPolicy.html#legacy):
 ==
 
 The libclc library is dual licensed under both the University of Illinois


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

r351731 - Fix typos throughout the license files that somehow I and my reviewers

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Mon Jan 21 01:52:34 2019
New Revision: 351731

URL: http://llvm.org/viewvc/llvm-project?rev=351731=rev
Log:
Fix typos throughout the license files that somehow I and my reviewers
all missed!

Thanks to Alex Bradbury for pointing this out, and the fact that I never
added the intended `legacy` anchor to the developer policy. Add that
anchor too. With hope, this will cause the links to all resolve
successfully.

Modified:
cfe/trunk/LICENSE.TXT
cfe/trunk/tools/clang-format-vs/ClangFormat/license.txt

Modified: cfe/trunk/LICENSE.TXT
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/LICENSE.TXT?rev=351731=351730=351731=diff
==
--- cfe/trunk/LICENSE.TXT (original)
+++ cfe/trunk/LICENSE.TXT Mon Jan 21 01:52:34 2019
@@ -234,7 +234,7 @@ mechanisms:
file.
 
 ==
-Legacy LLVM License (ttps://llvm.org/docs/DeveloperPolicy.html#legacy):
+Legacy LLVM License (https://llvm.org/docs/DeveloperPolicy.html#legacy):
 ==
 University of Illinois/NCSA
 Open Source License

Modified: cfe/trunk/tools/clang-format-vs/ClangFormat/license.txt
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-format-vs/ClangFormat/license.txt?rev=351731=351730=351731=diff
==
--- cfe/trunk/tools/clang-format-vs/ClangFormat/license.txt (original)
+++ cfe/trunk/tools/clang-format-vs/ClangFormat/license.txt Mon Jan 21 01:52:34 
2019
@@ -234,7 +234,7 @@ mechanisms:
file.
 
 ==
-Legacy LLVM License (ttps://llvm.org/docs/DeveloperPolicy.html#legacy):
+Legacy LLVM License (https://llvm.org/docs/DeveloperPolicy.html#legacy):
 ==
 University of Illinois/NCSA
 Open Source License


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

r351651 - Update the license mentioned in this documentation.

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Sat Jan 19 03:48:15 2019
New Revision: 351651

URL: http://llvm.org/viewvc/llvm-project?rev=351651=rev
Log:
Update the license mentioned in this documentation.

Modified:
cfe/trunk/tools/scan-build-py/README.md

Modified: cfe/trunk/tools/scan-build-py/README.md
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/scan-build-py/README.md?rev=351651=351650=351651=diff
==
--- cfe/trunk/tools/scan-build-py/README.md (original)
+++ cfe/trunk/tools/scan-build-py/README.md Sat Jan 19 03:48:15 2019
@@ -138,7 +138,7 @@ how to fix it, include that as well. Pat
 License
 ---
 
-The project is licensed under University of Illinois/NCSA Open Source License.
+The project is licensed under Apache-2.0 with LLVM exceptions.
 See LICENSE.TXT for details.
 
   [1]: http://clang.llvm.org/docs/JSONCompilationDatabase.html


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

[libunwind] r351648 - Update more file headers across all of the LLVM projects in the monorepo

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Sat Jan 19 02:56:40 2019
New Revision: 351648

URL: http://llvm.org/viewvc/llvm-project?rev=351648=rev
Log:
Update more file headers across all of the LLVM projects in the monorepo
to reflect the new license. These used slightly different spellings that
defeated my regular expressions.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

Modified:
libunwind/trunk/include/__libunwind_config.h
libunwind/trunk/include/libunwind.h
libunwind/trunk/include/mach-o/compact_unwind_encoding.h
libunwind/trunk/include/unwind.h
libunwind/trunk/src/AddressSpace.hpp
libunwind/trunk/src/CompactUnwinder.hpp
libunwind/trunk/src/DwarfInstructions.hpp
libunwind/trunk/src/DwarfParser.hpp
libunwind/trunk/src/EHHeaderParser.hpp
libunwind/trunk/src/RWMutex.hpp
libunwind/trunk/src/Registers.hpp
libunwind/trunk/src/Unwind-EHABI.cpp
libunwind/trunk/src/Unwind-EHABI.h
libunwind/trunk/src/Unwind-seh.cpp
libunwind/trunk/src/Unwind-sjlj.c
libunwind/trunk/src/UnwindCursor.hpp
libunwind/trunk/src/UnwindLevel1-gcc-ext.c
libunwind/trunk/src/UnwindLevel1.c
libunwind/trunk/src/UnwindRegistersRestore.S
libunwind/trunk/src/UnwindRegistersSave.S
libunwind/trunk/src/Unwind_AppleExtras.cpp
libunwind/trunk/src/assembly.h
libunwind/trunk/src/config.h
libunwind/trunk/src/dwarf2.h
libunwind/trunk/src/libunwind.cpp
libunwind/trunk/src/libunwind_ext.h
libunwind/trunk/test/alignment.pass.cpp
libunwind/trunk/test/libunwind/test/config.py

Modified: libunwind/trunk/include/__libunwind_config.h
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/include/__libunwind_config.h?rev=351648=351647=351648=diff
==
--- libunwind/trunk/include/__libunwind_config.h (original)
+++ libunwind/trunk/include/__libunwind_config.h Sat Jan 19 02:56:40 2019
@@ -1,9 +1,8 @@
 //===- __libunwind_config.h 
---===//
 //
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under the MIT and the University of Illinois Open
-// Source Licenses. See LICENSE.TXT for details.
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 
//===--===//
 

Modified: libunwind/trunk/include/libunwind.h
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/include/libunwind.h?rev=351648=351647=351648=diff
==
--- libunwind/trunk/include/libunwind.h (original)
+++ libunwind/trunk/include/libunwind.h Sat Jan 19 02:56:40 2019
@@ -1,9 +1,8 @@
 //=== libunwind.h 
-===//
 //
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under the MIT and the University of Illinois Open
-// Source Licenses. See LICENSE.TXT for details.
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //
 // Compatible with libunwind API documented at:

Modified: libunwind/trunk/include/mach-o/compact_unwind_encoding.h
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/include/mach-o/compact_unwind_encoding.h?rev=351648=351647=351648=diff
==
--- libunwind/trunk/include/mach-o/compact_unwind_encoding.h (original)
+++ libunwind/trunk/include/mach-o/compact_unwind_encoding.h Sat Jan 19 
02:56:40 2019
@@ -1,9 +1,8 @@
 //===-- mach-o/compact_unwind_encoding.h 
--===//
 //
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under the MIT and the University of Illinois Open
-// Source Licenses. See LICENSE.TXT for details.
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 //
 // Darwin's alternative to DWARF based unwind encodings.

Modified: libunwind/trunk/include/unwind.h

r351640 - Update the license header in this man-page file.

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Sat Jan 19 01:24:38 2019
New Revision: 351640

URL: http://llvm.org/viewvc/llvm-project?rev=351640=rev
Log:
Update the license header in this man-page file.

It contains an `$Id$` expansion and so can only be updated from a true
Subversion client.

See the details of this update in r351636.

Modified:
cfe/trunk/tools/scan-build/man/scan-build.1

Modified: cfe/trunk/tools/scan-build/man/scan-build.1
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/scan-build/man/scan-build.1?rev=351640=351639=351640=diff
==
--- cfe/trunk/tools/scan-build/man/scan-build.1 (original)
+++ cfe/trunk/tools/scan-build/man/scan-build.1 Sat Jan 19 01:24:38 2019
@@ -1,5 +1,6 @@
-.\" This file is distributed under the University of Illinois Open Source
-.\" License. See LICENSE.TXT for details.
+.\" Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+.\" See https://llvm.org/LICENSE.txt for license information.
+.\" SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 .\" $Id$
 .Dd May 25, 2012
 .Dt SCAN-BUILD 1


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

[libclc] r351636 - Update the file headers across all of the LLVM projects in the monorepo

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Sat Jan 19 00:50:56 2019
New Revision: 351636

URL: http://llvm.org/viewvc/llvm-project?rev=351636=rev
Log:
Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

Modified:
libclc/trunk/generic/include/clc/misc/shuffle.h
libclc/trunk/generic/include/clc/misc/shuffle2.h
libclc/trunk/generic/lib/misc/shuffle.cl
libclc/trunk/generic/lib/misc/shuffle2.cl

Modified: libclc/trunk/generic/include/clc/misc/shuffle.h
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/generic/include/clc/misc/shuffle.h?rev=351636=351635=351636=diff
==
--- libclc/trunk/generic/include/clc/misc/shuffle.h (original)
+++ libclc/trunk/generic/include/clc/misc/shuffle.h Sat Jan 19 00:50:56 2019
@@ -1,9 +1,8 @@
 //===-- generic/include/clc/misc/shuffle.h --===//
 //
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under both the University of Illinois Open Source
-// License and the MIT license. See LICENSE.TXT for details.
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 
//===--===//
 

Modified: libclc/trunk/generic/include/clc/misc/shuffle2.h
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/generic/include/clc/misc/shuffle2.h?rev=351636=351635=351636=diff
==
--- libclc/trunk/generic/include/clc/misc/shuffle2.h (original)
+++ libclc/trunk/generic/include/clc/misc/shuffle2.h Sat Jan 19 00:50:56 2019
@@ -1,9 +1,8 @@
 //===-- generic/include/clc/misc/shuffle2.h --===//
 //
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under both the University of Illinois Open Source
-// License and the MIT license. See LICENSE.TXT for details.
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 
//===--===//
 

Modified: libclc/trunk/generic/lib/misc/shuffle.cl
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/generic/lib/misc/shuffle.cl?rev=351636=351635=351636=diff
==
--- libclc/trunk/generic/lib/misc/shuffle.cl (original)
+++ libclc/trunk/generic/lib/misc/shuffle.cl Sat Jan 19 00:50:56 2019
@@ -1,9 +1,8 @@
 //===-- generic/lib/misc/shuffle.cl --===//
 //
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under both the University of Illinois Open Source
-// License and the MIT license. See LICENSE.TXT for details.
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 
//===--===//
 

Modified: libclc/trunk/generic/lib/misc/shuffle2.cl
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/generic/lib/misc/shuffle2.cl?rev=351636=351635=351636=diff
==
--- libclc/trunk/generic/lib/misc/shuffle2.cl (original)
+++ libclc/trunk/generic/lib/misc/shuffle2.cl Sat Jan 19 00:50:56 2019
@@ -1,9 +1,8 @@
 //===-- generic/lib/misc/shuffle2.cl --===//
 //
-// The LLVM Compiler Infrastructure
-//
-// This file is dual licensed under both the University of Illinois Open Source
-// License and the MIT license. See LICENSE.TXT for details.
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
 //
 
//===--===//
 


___
cfe-commits 

r351634 - Convert two more files that were using Windows line endings and remove

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Fri Jan 18 22:36:08 2019
New Revision: 351634

URL: http://llvm.org/viewvc/llvm-project?rev=351634=rev
Log:
Convert two more files that were using Windows line endings and remove
a stray single '\r' from one file. These are the last line ending issues
I can find in the files containing parts of LLVM's file headers.

Modified:
cfe/trunk/lib/Basic/Targets/ARC.cpp

Modified: cfe/trunk/lib/Basic/Targets/ARC.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/ARC.cpp?rev=351634=351633=351634=diff
==
--- cfe/trunk/lib/Basic/Targets/ARC.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/ARC.cpp Fri Jan 18 22:36:08 2019
@@ -22,4 +22,4 @@ using namespace clang::targets;
 void ARCTargetInfo::getTargetDefines(const LangOptions ,
  MacroBuilder ) const {
   Builder.defineMacro("__arc__");
-}
+}


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

[clang-tools-extra] r351634 - Convert two more files that were using Windows line endings and remove

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Fri Jan 18 22:36:08 2019
New Revision: 351634

URL: http://llvm.org/viewvc/llvm-project?rev=351634=rev
Log:
Convert two more files that were using Windows line endings and remove
a stray single '\r' from one file. These are the last line ending issues
I can find in the files containing parts of LLVM's file headers.

Modified:
clang-tools-extra/trunk/clang-tidy/readability/ElseAfterReturnCheck.cpp

Modified: 
clang-tools-extra/trunk/clang-tidy/readability/ElseAfterReturnCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/ElseAfterReturnCheck.cpp?rev=351634=351633=351634=diff
==
--- clang-tools-extra/trunk/clang-tidy/readability/ElseAfterReturnCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/readability/ElseAfterReturnCheck.cpp Fri 
Jan 18 22:36:08 2019
@@ -1,58 +1,58 @@
-//===--- ElseAfterReturnCheck.cpp - 
clang-tidy-===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-
-#include "ElseAfterReturnCheck.h"
-#include "clang/AST/ASTContext.h"
-#include "clang/ASTMatchers/ASTMatchFinder.h"
-#include "clang/Tooling/FixIt.h"
-
-using namespace clang::ast_matchers;
-
-namespace clang {
-namespace tidy {
-namespace readability {
-
-void ElseAfterReturnCheck::registerMatchers(MatchFinder *Finder) {
-  const auto ControlFlowInterruptorMatcher =
-  stmt(anyOf(returnStmt().bind("return"), continueStmt().bind("continue"),
- breakStmt().bind("break"),
- expr(ignoringImplicit(cxxThrowExpr().bind("throw");
-  Finder->addMatcher(
-  compoundStmt(forEach(
-  ifStmt(unless(isConstexpr()),
- hasThen(stmt(
- anyOf(ControlFlowInterruptorMatcher,
-   compoundStmt(has(ControlFlowInterruptorMatcher),
- hasElse(stmt().bind("else")))
-  .bind("if"))),
-  this);
-}
-
-void ElseAfterReturnCheck::check(const MatchFinder::MatchResult ) {
-  const auto *If = Result.Nodes.getNodeAs("if");
-  SourceLocation ElseLoc = If->getElseLoc();
-  std::string ControlFlowInterruptor;
-  for (const auto *BindingName : {"return", "continue", "break", "throw"})
-if (Result.Nodes.getNodeAs(BindingName))
-  ControlFlowInterruptor = BindingName;
-
-  DiagnosticBuilder Diag = diag(ElseLoc, "do not use 'else' after '%0'")
-   << ControlFlowInterruptor;
-  Diag << tooling::fixit::createRemoval(ElseLoc);
-
-  // FIXME: Removing the braces isn't always safe. Do a more careful analysis.
-  // FIXME: Change clang-format to correctly un-indent the code.
-  if (const auto *CS = Result.Nodes.getNodeAs("else"))
-Diag << tooling::fixit::createRemoval(CS->getLBracLoc())
- << tooling::fixit::createRemoval(CS->getRBracLoc());
-}
-
-} // namespace readability
-} // namespace tidy
-} // namespace clang
+//===--- ElseAfterReturnCheck.cpp - 
clang-tidy-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "ElseAfterReturnCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Tooling/FixIt.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace readability {
+
+void ElseAfterReturnCheck::registerMatchers(MatchFinder *Finder) {
+  const auto ControlFlowInterruptorMatcher =
+  stmt(anyOf(returnStmt().bind("return"), continueStmt().bind("continue"),
+ breakStmt().bind("break"),
+ expr(ignoringImplicit(cxxThrowExpr().bind("throw");
+  Finder->addMatcher(
+  compoundStmt(forEach(
+  ifStmt(unless(isConstexpr()),
+ hasThen(stmt(
+ anyOf(ControlFlowInterruptorMatcher,
+   compoundStmt(has(ControlFlowInterruptorMatcher),
+ hasElse(stmt().bind("else")))
+  .bind("if"))),
+  this);
+}
+
+void ElseAfterReturnCheck::check(const MatchFinder::MatchResult ) {
+  const auto *If = Result.Nodes.getNodeAs("if");
+  SourceLocation ElseLoc = If->getElseLoc();
+  std::string ControlFlowInterruptor;
+  for (const auto *BindingName : {"return", "continue", "break", "throw"})
+if (Result.Nodes.getNodeAs(BindingName))
+  ControlFlowInterruptor = BindingName;
+
+  DiagnosticBuilder Diag = diag(ElseLoc, "do not use 'else' after '%0'")
+   << ControlFlowInterruptor;
+  Diag << 

r351633 - Remove random windows line endings that snuck into the middle of this

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Fri Jan 18 22:36:00 2019
New Revision: 351633

URL: http://llvm.org/viewvc/llvm-project?rev=351633=rev
Log:
Remove random windows line endings that snuck into the middle of this
code.

Modified:
cfe/trunk/lib/Lex/PPDirectives.cpp

Modified: cfe/trunk/lib/Lex/PPDirectives.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/PPDirectives.cpp?rev=351633=351632=351633=diff
==
--- cfe/trunk/lib/Lex/PPDirectives.cpp (original)
+++ cfe/trunk/lib/Lex/PPDirectives.cpp Fri Jan 18 22:36:00 2019
@@ -76,24 +76,24 @@ Preprocessor::AllocateVisibilityMacroDir
bool isPublic) {
   return new (BP) VisibilityMacroDirective(Loc, isPublic);
 }
-
-/// Read and discard all tokens remaining on the current line until
-/// the tok::eod token is found.
-SourceRange Preprocessor::DiscardUntilEndOfDirective() {
-  Token Tmp;
-  SourceRange Res;
-
-  LexUnexpandedToken(Tmp);
-  Res.setBegin(Tmp.getLocation());
-  while (Tmp.isNot(tok::eod)) {
-assert(Tmp.isNot(tok::eof) && "EOF seen while discarding directive 
tokens");
-LexUnexpandedToken(Tmp);
-  }
-  Res.setEnd(Tmp.getLocation());
-  return Res;
-}
-
-/// Enumerates possible cases of #define/#undef a reserved identifier.
+
+/// Read and discard all tokens remaining on the current line until
+/// the tok::eod token is found.
+SourceRange Preprocessor::DiscardUntilEndOfDirective() {
+  Token Tmp;
+  SourceRange Res;
+
+  LexUnexpandedToken(Tmp);
+  Res.setBegin(Tmp.getLocation());
+  while (Tmp.isNot(tok::eod)) {
+assert(Tmp.isNot(tok::eof) && "EOF seen while discarding directive 
tokens");
+LexUnexpandedToken(Tmp);
+  }
+  Res.setEnd(Tmp.getLocation());
+  return Res;
+}
+
+/// Enumerates possible cases of #define/#undef a reserved identifier.
 enum MacroDiag {
   MD_NoWarn,//> Not a reserved identifier
   MD_KeywordDef,//> Macro hides keyword, enabled by default
@@ -541,25 +541,25 @@ void Preprocessor::SkipExcludedCondition
 
 // If this is in a skipping block or if we're already handled this #if
 // block, don't bother parsing the condition.
-if (CondInfo.WasSkipping || CondInfo.FoundNonSkip) {
-  DiscardUntilEndOfDirective();
-} else {
-  // Restore the value of LexingRawMode so that identifiers are
-  // looked up, etc, inside the #elif expression.
-  assert(CurPPLexer->LexingRawMode && "We have to be skipping here!");
-  CurPPLexer->LexingRawMode = false;
-  IdentifierInfo *IfNDefMacro = nullptr;
-  DirectiveEvalResult DER = EvaluateDirectiveExpression(IfNDefMacro);
-  const bool CondValue = DER.Conditional;
-  CurPPLexer->LexingRawMode = true;
-  if (Callbacks) {
-Callbacks->Elif(
-Tok.getLocation(), DER.ExprRange,
-(CondValue ? PPCallbacks::CVK_True : PPCallbacks::CVK_False),
-CondInfo.IfLoc);
-  }
-  // If this condition is true, enter it!
-  if (CondValue) {
+if (CondInfo.WasSkipping || CondInfo.FoundNonSkip) {
+  DiscardUntilEndOfDirective();
+} else {
+  // Restore the value of LexingRawMode so that identifiers are
+  // looked up, etc, inside the #elif expression.
+  assert(CurPPLexer->LexingRawMode && "We have to be skipping here!");
+  CurPPLexer->LexingRawMode = false;
+  IdentifierInfo *IfNDefMacro = nullptr;
+  DirectiveEvalResult DER = EvaluateDirectiveExpression(IfNDefMacro);
+  const bool CondValue = DER.Conditional;
+  CurPPLexer->LexingRawMode = true;
+  if (Callbacks) {
+Callbacks->Elif(
+Tok.getLocation(), DER.ExprRange,
+(CondValue ? PPCallbacks::CVK_True : PPCallbacks::CVK_False),
+CondInfo.IfLoc);
+  }
+  // If this condition is true, enter it!
+  if (CondValue) {
 CondInfo.FoundNonSkip = true;
 break;
   }
@@ -1119,30 +1119,30 @@ void Preprocessor::HandleLineDirective()
   // If the StrTok is "eod", then it wasn't present.  Otherwise, it must be a
   // string followed by eod.
   if (StrTok.is(tok::eod))
-; // ok
-  else if (StrTok.isNot(tok::string_literal)) {
-Diag(StrTok, diag::err_pp_line_invalid_filename);
-DiscardUntilEndOfDirective();
-return;
-  } else if (StrTok.hasUDSuffix()) {
-Diag(StrTok, diag::err_invalid_string_udl);
-DiscardUntilEndOfDirective();
-return;
-  } else {
-// Parse and validate the string, converting it into a unique ID.
-StringLiteralParser Literal(StrTok, *this);
-assert(Literal.isAscii() && "Didn't allow wide strings in");
-if (Literal.hadError) {
-  DiscardUntilEndOfDirective();
-  return;
-}
-if (Literal.Pascal) {
-  Diag(StrTok, diag::err_pp_linemarker_invalid_filename);
- 

[clang-tools-extra] r351632 - Update some code used in our visual studio plugins to use linux file

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Fri Jan 18 22:29:07 2019
New Revision: 351632

URL: http://llvm.org/viewvc/llvm-project?rev=351632=rev
Log:
Update some code used in our visual studio plugins to use linux file
endings. We already used them in some cases, and this makes things
consistent. This will also simplify updating the licenses in these
files.

Modified:
clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/ClangTidyPackage.cs
clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/ClangTidyPropertyGrid.cs
clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/PkgCmdID.cs

Modified: clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/ClangTidyPackage.cs
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/ClangTidyPackage.cs?rev=351632=351631=351632=diff
==
--- clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/ClangTidyPackage.cs 
(original)
+++ clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/ClangTidyPackage.cs Fri Jan 
18 22:29:07 2019
@@ -1,56 +1,56 @@
-//===-- ClangTidyPackages.cs - VSPackage for clang-tidy --*- C# 
-*-===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-//
-// This class contains a VS extension package that runs clang-tidy over a
-// file in a VS text editor.
-//
-//===--===//
-
-using Microsoft.VisualStudio.Editor;
-using Microsoft.VisualStudio.Shell;
-using Microsoft.VisualStudio.Shell.Interop;
-using Microsoft.VisualStudio.TextManager.Interop;
-using System;
-using System.Collections;
-using System.ComponentModel;
-using System.ComponentModel.Design;
-using System.IO;
-using System.Runtime.InteropServices;
-using System.Windows.Forms;
-using System.Xml.Linq;
-
-namespace LLVM.ClangTidy
-{
-[PackageRegistration(UseManagedResourcesOnly = true)]
-[InstalledProductRegistration("#110", "#112", "1.0", IconResourceID = 400)]
-[ProvideMenuResource("Menus.ctmenu", 1)]
-[Guid(GuidList.guidClangTidyPkgString)]
-[ProvideOptionPage(typeof(ClangTidyConfigurationPage), "LLVM/Clang", 
"ClangTidy", 0, 0, true)]
-public sealed class ClangTidyPackage : Package
-{
-#region Package Members
-protected override void Initialize()
-{
-base.Initialize();
-
-var commandService = GetService(typeof(IMenuCommandService)) as 
OleMenuCommandService;
-if (commandService != null)
-{
-var menuCommandID = new 
CommandID(GuidList.guidClangTidyCmdSet, (int)PkgCmdIDList.cmdidClangTidy);
-var menuItem = new MenuCommand(MenuItemCallback, 
menuCommandID);
-commandService.AddCommand(menuItem);
-}
-}
-#endregion
-
-private void MenuItemCallback(object sender, EventArgs args)
-{
-}
-}
-}
+//===-- ClangTidyPackages.cs - VSPackage for clang-tidy --*- C# 
-*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// This class contains a VS extension package that runs clang-tidy over a
+// file in a VS text editor.
+//
+//===--===//
+
+using Microsoft.VisualStudio.Editor;
+using Microsoft.VisualStudio.Shell;
+using Microsoft.VisualStudio.Shell.Interop;
+using Microsoft.VisualStudio.TextManager.Interop;
+using System;
+using System.Collections;
+using System.ComponentModel;
+using System.ComponentModel.Design;
+using System.IO;
+using System.Runtime.InteropServices;
+using System.Windows.Forms;
+using System.Xml.Linq;
+
+namespace LLVM.ClangTidy
+{
+[PackageRegistration(UseManagedResourcesOnly = true)]
+[InstalledProductRegistration("#110", "#112", "1.0", IconResourceID = 400)]
+[ProvideMenuResource("Menus.ctmenu", 1)]
+[Guid(GuidList.guidClangTidyPkgString)]
+[ProvideOptionPage(typeof(ClangTidyConfigurationPage), "LLVM/Clang", 
"ClangTidy", 0, 0, true)]
+public sealed class ClangTidyPackage : Package
+{
+#region Package Members
+protected override void Initialize()
+{
+base.Initialize();
+
+var commandService = GetService(typeof(IMenuCommandService)) as 
OleMenuCommandService;
+if (commandService != null)
+{
+var menuCommandID = new 
CommandID(GuidList.guidClangTidyCmdSet, (int)PkgCmdIDList.cmdidClangTidy);
+var menuItem = new MenuCommand(MenuItemCallback, 
menuCommandID);
+

r351632 - Update some code used in our visual studio plugins to use linux file

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Fri Jan 18 22:29:07 2019
New Revision: 351632

URL: http://llvm.org/viewvc/llvm-project?rev=351632=rev
Log:
Update some code used in our visual studio plugins to use linux file
endings. We already used them in some cases, and this makes things
consistent. This will also simplify updating the licenses in these
files.

Modified:
cfe/trunk/tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs
cfe/trunk/tools/clang-format-vs/ClangFormat/Guids.cs
cfe/trunk/tools/clang-format-vs/ClangFormat/PkgCmdID.cs

Modified: cfe/trunk/tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs?rev=351632=351631=351632=diff
==
--- cfe/trunk/tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs (original)
+++ cfe/trunk/tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs Fri Jan 
18 22:29:07 2019
@@ -1,456 +1,456 @@
-//===-- ClangFormatPackages.cs - VSPackage for clang-format --*- C# 
-*-===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-//
-// This class contains a VS extension package that runs clang-format over a
-// selection in a VS text editor.
-//
-//===--===//
-
-using EnvDTE;
-using Microsoft.VisualStudio.Shell;
-using Microsoft.VisualStudio.Shell.Interop;
-using Microsoft.VisualStudio.Text;
-using Microsoft.VisualStudio.Text.Editor;
-using System;
-using System.Collections;
-using System.ComponentModel;
-using System.ComponentModel.Design;
-using System.IO;
-using System.Runtime.InteropServices;
-using System.Xml.Linq;
-using System.Linq;
-
-namespace LLVM.ClangFormat
-{
-[ClassInterface(ClassInterfaceType.AutoDual)]
-[CLSCompliant(false), ComVisible(true)]
-public class OptionPageGrid : DialogPage
-{
-private string assumeFilename = "";
-private string fallbackStyle = "LLVM";
-private bool sortIncludes = false;
-private string style = "file";
-private bool formatOnSave = false;
-private string formatOnSaveFileExtensions =
-".c;.cpp;.cxx;.cc;.tli;.tlh;.h;.hh;.hpp;.hxx;.hh;.inl;" +
-".java;.js;.ts;.m;.mm;.proto;.protodevel;.td";
-
-public OptionPageGrid Clone()
-{
-// Use MemberwiseClone to copy value types.
-var clone = (OptionPageGrid)MemberwiseClone();
-return clone;
-}
-
-public class StyleConverter : TypeConverter
-{
-protected ArrayList values;
-public StyleConverter()
-{
-// Initializes the standard values list with defaults.
-values = new ArrayList(new string[] { "file", "Chromium", 
"Google", "LLVM", "Mozilla", "WebKit" });
-}
-
-public override bool 
GetStandardValuesSupported(ITypeDescriptorContext context)
-{
-return true;
-}
-
-public override StandardValuesCollection 
GetStandardValues(ITypeDescriptorContext context)
-{
-return new StandardValuesCollection(values);
-}
-
-public override bool CanConvertFrom(ITypeDescriptorContext 
context, Type sourceType)
-{
-if (sourceType == typeof(string))
-return true;
-
-return base.CanConvertFrom(context, sourceType);
-}
-
-public override object ConvertFrom(ITypeDescriptorContext context, 
System.Globalization.CultureInfo culture, object value)
-{
-string s = value as string;
-if (s == null)
-return base.ConvertFrom(context, culture, value);
-
-return value;
-}
-}
-
-[Category("Format Options")]
-[DisplayName("Style")]
-[Description("Coding style, currently supports:\n" +
- "  - Predefined styles ('LLVM', 'Google', 'Chromium', 
'Mozilla', 'WebKit').\n" +
- "  - 'file' to search for a YAML .clang-format or 
_clang-format\n" +
- "configuration file.\n" +
- "  - A YAML configuration snippet.\n\n" +
- "'File':\n" +
- "  Searches for a .clang-format or _clang-format 
configuration file\n" +
- "  in the source file's directory and its parents.\n\n" +
- "YAML configuration snippet:\n" +
- "  The content of a .clang-format configuration file, as 
string.\n" +
- "  Example: '{BasedOnStyle: \"LLVM\", 

[libclc] r351631 - Install new LLVM license structure and new developer policy.

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Fri Jan 18 22:14:24 2019
New Revision: 351631

URL: http://llvm.org/viewvc/llvm-project?rev=351631=rev
Log:
Install new LLVM license structure and new developer policy.

This installs the new developer policy and moves all of the license
files across all LLVM projects in the monorepo to the new license
structure. The remaining projects will be moved independently.

Note that I've left odd formatting and other idiosyncracies of the
legacy license structure text alone to make the diff easier to read.
Critically, note that we do not in any case *remove* the old license
notice or terms, as that remains necessary until we finish the
relicensing process.

I've updated a few license files that refer to the LLVM license to
instead simply refer generically to whatever license the LLVM project is
under, basically trying to minimize confusion.

This is really the culmination of so many people. Chris led the
community discussions, drafted the policy update and organized the
multi-year string of meeting between lawyers across the community to
figure out the strategy. Numerous lawyers at companies in the community
spent their time figuring out initial answers, and then the Foundation's
lawyer Heather Meeker has done *so* much to help refine and get us ready
here. I could keep going on, but I just want to make sure everyone
realizes what a huge community effort this has been from the begining.

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

Modified:
libclc/trunk/LICENSE.TXT

Modified: libclc/trunk/LICENSE.TXT
URL: 
http://llvm.org/viewvc/llvm-project/libclc/trunk/LICENSE.TXT?rev=351631=351630=351631=diff
==
--- libclc/trunk/LICENSE.TXT (original)
+++ libclc/trunk/LICENSE.TXT Fri Jan 18 22:14:24 2019
@@ -1,5 +1,240 @@
 ==
-libclc License
+The LLVM Project is under the Apache License v2.0 with LLVM Exceptions:
+==
+
+ Apache License
+   Version 2.0, January 2004
+http://www.apache.org/licenses/
+
+TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+1. Definitions.
+
+  "License" shall mean the terms and conditions for use, reproduction,
+  and distribution as defined by Sections 1 through 9 of this document.
+
+  "Licensor" shall mean the copyright owner or entity authorized by
+  the copyright owner that is granting the License.
+
+  "Legal Entity" shall mean the union of the acting entity and all
+  other entities that control, are controlled by, or are under common
+  control with that entity. For the purposes of this definition,
+  "control" means (i) the power, direct or indirect, to cause the
+  direction or management of such entity, whether by contract or
+  otherwise, or (ii) ownership of fifty percent (50%) or more of the
+  outstanding shares, or (iii) beneficial ownership of such entity.
+
+  "You" (or "Your") shall mean an individual or Legal Entity
+  exercising permissions granted by this License.
+
+  "Source" form shall mean the preferred form for making modifications,
+  including but not limited to software source code, documentation
+  source, and configuration files.
+
+  "Object" form shall mean any form resulting from mechanical
+  transformation or translation of a Source form, including but
+  not limited to compiled object code, generated documentation,
+  and conversions to other media types.
+
+  "Work" shall mean the work of authorship, whether in Source or
+  Object form, made available under the License, as indicated by a
+  copyright notice that is included in or attached to the work
+  (an example is provided in the Appendix below).
+
+  "Derivative Works" shall mean any work, whether in Source or Object
+  form, that is based on (or derived from) the Work and for which the
+  editorial revisions, annotations, elaborations, or other modifications
+  represent, as a whole, an original work of authorship. For the purposes
+  of this License, Derivative Works shall not include works that remain
+  separable from, or merely link (or bind by name) to the interfaces of,
+  the Work and Derivative Works thereof.
+
+  "Contribution" shall mean any work of authorship, including
+  the original version of the Work and any modifications or additions
+  to that Work or Derivative Works thereof, that is intentionally
+  submitted to Licensor for inclusion in the Work by the copyright owner
+  or by an individual or Legal Entity authorized to submit on behalf of
+  the copyright owner. For the purposes of this definition, "submitted"
+  means any form of electronic, verbal, or written 

r351631 - Install new LLVM license structure and new developer policy.

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Fri Jan 18 22:14:24 2019
New Revision: 351631

URL: http://llvm.org/viewvc/llvm-project?rev=351631=rev
Log:
Install new LLVM license structure and new developer policy.

This installs the new developer policy and moves all of the license
files across all LLVM projects in the monorepo to the new license
structure. The remaining projects will be moved independently.

Note that I've left odd formatting and other idiosyncracies of the
legacy license structure text alone to make the diff easier to read.
Critically, note that we do not in any case *remove* the old license
notice or terms, as that remains necessary until we finish the
relicensing process.

I've updated a few license files that refer to the LLVM license to
instead simply refer generically to whatever license the LLVM project is
under, basically trying to minimize confusion.

This is really the culmination of so many people. Chris led the
community discussions, drafted the policy update and organized the
multi-year string of meeting between lawyers across the community to
figure out the strategy. Numerous lawyers at companies in the community
spent their time figuring out initial answers, and then the Foundation's
lawyer Heather Meeker has done *so* much to help refine and get us ready
here. I could keep going on, but I just want to make sure everyone
realizes what a huge community effort this has been from the begining.

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

Modified:
cfe/trunk/LICENSE.TXT
cfe/trunk/tools/clang-format-vs/ClangFormat/license.txt

Modified: cfe/trunk/LICENSE.TXT
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/LICENSE.TXT?rev=351631=351630=351631=diff
==
--- cfe/trunk/LICENSE.TXT (original)
+++ cfe/trunk/LICENSE.TXT Fri Jan 18 22:14:24 2019
@@ -1,5 +1,240 @@
 ==
-LLVM Release License
+The LLVM Project is under the Apache License v2.0 with LLVM Exceptions:
+==
+
+ Apache License
+   Version 2.0, January 2004
+http://www.apache.org/licenses/
+
+TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+1. Definitions.
+
+  "License" shall mean the terms and conditions for use, reproduction,
+  and distribution as defined by Sections 1 through 9 of this document.
+
+  "Licensor" shall mean the copyright owner or entity authorized by
+  the copyright owner that is granting the License.
+
+  "Legal Entity" shall mean the union of the acting entity and all
+  other entities that control, are controlled by, or are under common
+  control with that entity. For the purposes of this definition,
+  "control" means (i) the power, direct or indirect, to cause the
+  direction or management of such entity, whether by contract or
+  otherwise, or (ii) ownership of fifty percent (50%) or more of the
+  outstanding shares, or (iii) beneficial ownership of such entity.
+
+  "You" (or "Your") shall mean an individual or Legal Entity
+  exercising permissions granted by this License.
+
+  "Source" form shall mean the preferred form for making modifications,
+  including but not limited to software source code, documentation
+  source, and configuration files.
+
+  "Object" form shall mean any form resulting from mechanical
+  transformation or translation of a Source form, including but
+  not limited to compiled object code, generated documentation,
+  and conversions to other media types.
+
+  "Work" shall mean the work of authorship, whether in Source or
+  Object form, made available under the License, as indicated by a
+  copyright notice that is included in or attached to the work
+  (an example is provided in the Appendix below).
+
+  "Derivative Works" shall mean any work, whether in Source or Object
+  form, that is based on (or derived from) the Work and for which the
+  editorial revisions, annotations, elaborations, or other modifications
+  represent, as a whole, an original work of authorship. For the purposes
+  of this License, Derivative Works shall not include works that remain
+  separable from, or merely link (or bind by name) to the interfaces of,
+  the Work and Derivative Works thereof.
+
+  "Contribution" shall mean any work of authorship, including
+  the original version of the Work and any modifications or additions
+  to that Work or Derivative Works thereof, that is intentionally
+  submitted to Licensor for inclusion in the Work by the copyright owner
+  or by an individual or Legal Entity authorized to submit on behalf of
+  the copyright owner. For the purposes of this definition, "submitted"
+  means 

[libunwind] r351631 - Install new LLVM license structure and new developer policy.

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Fri Jan 18 22:14:24 2019
New Revision: 351631

URL: http://llvm.org/viewvc/llvm-project?rev=351631=rev
Log:
Install new LLVM license structure and new developer policy.

This installs the new developer policy and moves all of the license
files across all LLVM projects in the monorepo to the new license
structure. The remaining projects will be moved independently.

Note that I've left odd formatting and other idiosyncracies of the
legacy license structure text alone to make the diff easier to read.
Critically, note that we do not in any case *remove* the old license
notice or terms, as that remains necessary until we finish the
relicensing process.

I've updated a few license files that refer to the LLVM license to
instead simply refer generically to whatever license the LLVM project is
under, basically trying to minimize confusion.

This is really the culmination of so many people. Chris led the
community discussions, drafted the policy update and organized the
multi-year string of meeting between lawyers across the community to
figure out the strategy. Numerous lawyers at companies in the community
spent their time figuring out initial answers, and then the Foundation's
lawyer Heather Meeker has done *so* much to help refine and get us ready
here. I could keep going on, but I just want to make sure everyone
realizes what a huge community effort this has been from the begining.

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

Modified:
libunwind/trunk/LICENSE.TXT

Modified: libunwind/trunk/LICENSE.TXT
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/LICENSE.TXT?rev=351631=351630=351631=diff
==
--- libunwind/trunk/LICENSE.TXT (original)
+++ libunwind/trunk/LICENSE.TXT Fri Jan 18 22:14:24 2019
@@ -1,5 +1,240 @@
 ==
-libunwind License
+The LLVM Project is under the Apache License v2.0 with LLVM Exceptions:
+==
+
+ Apache License
+   Version 2.0, January 2004
+http://www.apache.org/licenses/
+
+TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+1. Definitions.
+
+  "License" shall mean the terms and conditions for use, reproduction,
+  and distribution as defined by Sections 1 through 9 of this document.
+
+  "Licensor" shall mean the copyright owner or entity authorized by
+  the copyright owner that is granting the License.
+
+  "Legal Entity" shall mean the union of the acting entity and all
+  other entities that control, are controlled by, or are under common
+  control with that entity. For the purposes of this definition,
+  "control" means (i) the power, direct or indirect, to cause the
+  direction or management of such entity, whether by contract or
+  otherwise, or (ii) ownership of fifty percent (50%) or more of the
+  outstanding shares, or (iii) beneficial ownership of such entity.
+
+  "You" (or "Your") shall mean an individual or Legal Entity
+  exercising permissions granted by this License.
+
+  "Source" form shall mean the preferred form for making modifications,
+  including but not limited to software source code, documentation
+  source, and configuration files.
+
+  "Object" form shall mean any form resulting from mechanical
+  transformation or translation of a Source form, including but
+  not limited to compiled object code, generated documentation,
+  and conversions to other media types.
+
+  "Work" shall mean the work of authorship, whether in Source or
+  Object form, made available under the License, as indicated by a
+  copyright notice that is included in or attached to the work
+  (an example is provided in the Appendix below).
+
+  "Derivative Works" shall mean any work, whether in Source or Object
+  form, that is based on (or derived from) the Work and for which the
+  editorial revisions, annotations, elaborations, or other modifications
+  represent, as a whole, an original work of authorship. For the purposes
+  of this License, Derivative Works shall not include works that remain
+  separable from, or merely link (or bind by name) to the interfaces of,
+  the Work and Derivative Works thereof.
+
+  "Contribution" shall mean any work of authorship, including
+  the original version of the Work and any modifications or additions
+  to that Work or Derivative Works thereof, that is intentionally
+  submitted to Licensor for inclusion in the Work by the copyright owner
+  or by an individual or Legal Entity authorized to submit on behalf of
+  the copyright owner. For the purposes of this definition, "submitted"
+  means any form of electronic, verbal, or 

[clang-tools-extra] r351631 - Install new LLVM license structure and new developer policy.

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Fri Jan 18 22:14:24 2019
New Revision: 351631

URL: http://llvm.org/viewvc/llvm-project?rev=351631=rev
Log:
Install new LLVM license structure and new developer policy.

This installs the new developer policy and moves all of the license
files across all LLVM projects in the monorepo to the new license
structure. The remaining projects will be moved independently.

Note that I've left odd formatting and other idiosyncracies of the
legacy license structure text alone to make the diff easier to read.
Critically, note that we do not in any case *remove* the old license
notice or terms, as that remains necessary until we finish the
relicensing process.

I've updated a few license files that refer to the LLVM license to
instead simply refer generically to whatever license the LLVM project is
under, basically trying to minimize confusion.

This is really the culmination of so many people. Chris led the
community discussions, drafted the policy update and organized the
multi-year string of meeting between lawyers across the community to
figure out the strategy. Numerous lawyers at companies in the community
spent their time figuring out initial answers, and then the Foundation's
lawyer Heather Meeker has done *so* much to help refine and get us ready
here. I could keep going on, but I just want to make sure everyone
realizes what a huge community effort this has been from the begining.

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

Modified:
clang-tools-extra/trunk/LICENSE.TXT
clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/license.txt
clang-tools-extra/trunk/clang-tidy/cert/LICENSE.TXT
clang-tools-extra/trunk/clang-tidy/hicpp/LICENSE.TXT

Modified: clang-tools-extra/trunk/LICENSE.TXT
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/LICENSE.TXT?rev=351631=351630=351631=diff
==
--- clang-tools-extra/trunk/LICENSE.TXT (original)
+++ clang-tools-extra/trunk/LICENSE.TXT Fri Jan 18 22:14:24 2019
@@ -1,5 +1,240 @@
 ==
-LLVM Release License
+The LLVM Project is under the Apache License v2.0 with LLVM Exceptions:
+==
+
+ Apache License
+   Version 2.0, January 2004
+http://www.apache.org/licenses/
+
+TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION
+
+1. Definitions.
+
+  "License" shall mean the terms and conditions for use, reproduction,
+  and distribution as defined by Sections 1 through 9 of this document.
+
+  "Licensor" shall mean the copyright owner or entity authorized by
+  the copyright owner that is granting the License.
+
+  "Legal Entity" shall mean the union of the acting entity and all
+  other entities that control, are controlled by, or are under common
+  control with that entity. For the purposes of this definition,
+  "control" means (i) the power, direct or indirect, to cause the
+  direction or management of such entity, whether by contract or
+  otherwise, or (ii) ownership of fifty percent (50%) or more of the
+  outstanding shares, or (iii) beneficial ownership of such entity.
+
+  "You" (or "Your") shall mean an individual or Legal Entity
+  exercising permissions granted by this License.
+
+  "Source" form shall mean the preferred form for making modifications,
+  including but not limited to software source code, documentation
+  source, and configuration files.
+
+  "Object" form shall mean any form resulting from mechanical
+  transformation or translation of a Source form, including but
+  not limited to compiled object code, generated documentation,
+  and conversions to other media types.
+
+  "Work" shall mean the work of authorship, whether in Source or
+  Object form, made available under the License, as indicated by a
+  copyright notice that is included in or attached to the work
+  (an example is provided in the Appendix below).
+
+  "Derivative Works" shall mean any work, whether in Source or Object
+  form, that is based on (or derived from) the Work and for which the
+  editorial revisions, annotations, elaborations, or other modifications
+  represent, as a whole, an original work of authorship. For the purposes
+  of this License, Derivative Works shall not include works that remain
+  separable from, or merely link (or bind by name) to the interfaces of,
+  the Work and Derivative Works thereof.
+
+  "Contribution" shall mean any work of authorship, including
+  the original version of the Work and any modifications or additions
+  to that Work or Derivative Works thereof, that is intentionally
+  submitted to Licensor for inclusion in the Work by 

r344730 - [TI removal] Test predicate rather than casting to detect a terminator

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Thu Oct 18 01:16:20 2018
New Revision: 344730

URL: http://llvm.org/viewvc/llvm-project?rev=344730=rev
Log:
[TI removal] Test predicate rather than casting to detect a terminator
and use the range based successor API.

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

Modified: cfe/trunk/lib/CodeGen/CGLoopInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGLoopInfo.cpp?rev=344730=344729=344730=diff
==
--- cfe/trunk/lib/CodeGen/CGLoopInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGLoopInfo.cpp Thu Oct 18 01:16:20 2018
@@ -12,6 +12,7 @@
 #include "clang/AST/Attr.h"
 #include "clang/Sema/LoopHint.h"
 #include "llvm/IR/BasicBlock.h"
+#include "llvm/IR/CFG.h"
 #include "llvm/IR/Constants.h"
 #include "llvm/IR/InstrTypes.h"
 #include "llvm/IR/Instructions.h"
@@ -335,10 +336,10 @@ void LoopInfoStack::InsertHelper(Instruc
   if (!L.getLoopID())
 return;
 
-  if (TerminatorInst *TI = dyn_cast(I)) {
-for (unsigned i = 0, ie = TI->getNumSuccessors(); i < ie; ++i)
-  if (TI->getSuccessor(i) == L.getHeader()) {
-TI->setMetadata(llvm::LLVMContext::MD_loop, L.getLoopID());
+  if (I->isTerminator()) {
+for (BasicBlock *Succ : successors(I))
+  if (Succ == L.getHeader()) {
+I->setMetadata(llvm::LLVMContext::MD_loop, L.getLoopID());
 break;
   }
 return;


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

r344504 - [TI removal] Make `getTerminator()` return a generic `Instruction`.

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Mon Oct 15 03:42:50 2018
New Revision: 344504

URL: http://llvm.org/viewvc/llvm-project?rev=344504=rev
Log:
[TI removal] Make `getTerminator()` return a generic `Instruction`.

This removes the primary remaining API producing `TerminatorInst` which
will reduce the rate at which code is introduced trying to use it and
generally make it much easier to remove the remaining APIs across the
codebase.

Also clean up some of the stragglers that the previous mechanical update
of variables missed.

Users of LLVM and out-of-tree code generally will need to update any
explicit variable types to handle this. Replacing `TerminatorInst` with
`Instruction` (or `auto`) almost always works. Most of these edits were
made in prior commits using the perl one-liner:
```
perl -i -ple 's/TerminatorInst(\b.* = .*getTerminator\(\))/Instruction\1/g'
```

This also my break some rare use cases where people overload for both
`Instruction` and `TerminatorInst`, but these should be easily fixed by
removing the `TerminatorInst` overload.

Modified:
cfe/trunk/lib/CodeGen/CGCleanup.cpp
cfe/trunk/lib/CodeGen/CGException.cpp

Modified: cfe/trunk/lib/CodeGen/CGCleanup.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCleanup.cpp?rev=344504=344503=344504=diff
==
--- cfe/trunk/lib/CodeGen/CGCleanup.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCleanup.cpp Mon Oct 15 03:42:50 2018
@@ -366,7 +366,7 @@ static llvm::SwitchInst *TransitionToCle
llvm::BasicBlock *Block) {
   // If it's a branch, turn it into a switch whose default
   // destination is its original target.
-  llvm::TerminatorInst *Term = Block->getTerminator();
+  llvm::Instruction *Term = Block->getTerminator();
   assert(Term && "can't transition block without terminator");
 
   if (llvm::BranchInst *Br = dyn_cast(Term)) {
@@ -589,7 +589,7 @@ static void ForwardPrebranchedFallthroug
   llvm::BasicBlock *To) {
   // Exit is the exit block of a cleanup, so it always terminates in
   // an unconditional branch or a switch.
-  llvm::TerminatorInst *Term = Exit->getTerminator();
+  llvm::Instruction *Term = Exit->getTerminator();
 
   if (llvm::BranchInst *Br = dyn_cast(Term)) {
 assert(Br->isUnconditional() && Br->getSuccessor(0) == From);

Modified: cfe/trunk/lib/CodeGen/CGException.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGException.cpp?rev=344504=344503=344504=diff
==
--- cfe/trunk/lib/CodeGen/CGException.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGException.cpp Mon Oct 15 03:42:50 2018
@@ -1248,7 +1248,7 @@ void CodeGenFunction::ExitCXXTryStmt(con
 // we follow the false destination for each of the cond branches to reach
 // the rethrow block.
 llvm::BasicBlock *RethrowBlock = WasmCatchStartBlock;
-while (llvm::TerminatorInst *TI = RethrowBlock->getTerminator()) {
+while (llvm::Instruction *TI = RethrowBlock->getTerminator()) {
   auto *BI = cast(TI);
   assert(BI->isConditional());
   RethrowBlock = BI->getSuccessor(1);


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

[clang-tools-extra] r344225 - Fix the qualification of `IntrusiveRefCntPtr` to use `llvm::`.

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Thu Oct 11 01:05:10 2018
New Revision: 344225

URL: http://llvm.org/viewvc/llvm-project?rev=344225=rev
Log:
Fix the qualification of `IntrusiveRefCntPtr` to use `llvm::`.

Without this, the code only compiled if the header was included after
something introduced the alias from `clang::` to `llvm::` for this type.
Any modules build would fail here.

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

Modified: clang-tools-extra/trunk/clangd/FSProvider.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/FSProvider.h?rev=344225=344224=344225=diff
==
--- clang-tools-extra/trunk/clangd/FSProvider.h (original)
+++ clang-tools-extra/trunk/clangd/FSProvider.h Thu Oct 11 01:05:10 2018
@@ -25,13 +25,15 @@ public:
   /// Context::current() will be the context passed to the clang entrypoint,
   /// such as addDocument(), and will also be propagated to result callbacks.
   /// Embedders may use this to isolate filesystem accesses.
-  virtual IntrusiveRefCntPtr getFileSystem() const = 0;
+  virtual llvm::IntrusiveRefCntPtr
+  getFileSystem() const = 0;
 };
 
 class RealFileSystemProvider : public FileSystemProvider {
 public:
   // FIXME: returns the single real FS instance, which is not threadsafe.
-  IntrusiveRefCntPtr getFileSystem() const override {
+  llvm::IntrusiveRefCntPtr
+  getFileSystem() const override {
 return llvm::vfs::getRealFileSystem();
   }
 };


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

r341363 - [x86/SLH] Add a real Clang flag and LLVM IR attribute for Speculative

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Tue Sep  4 05:38:00 2018
New Revision: 341363

URL: http://llvm.org/viewvc/llvm-project?rev=341363=rev
Log:
[x86/SLH] Add a real Clang flag and LLVM IR attribute for Speculative
Load Hardening.

Wires up the existing pass to work with a proper IR attribute rather
than just a hidden/internal flag. The internal flag continues to work
for now, but I'll likely remove it soon.

Most of the churn here is adding the IR attribute. I talked about this
Kristof Beyls and he seemed at least initially OK with this direction.
The idea of using a full attribute here is that we *do* expect at least
some forms of this for other architectures. There isn't anything
*inherently* x86-specific about this technique, just that we only have
an implementation for x86 at the moment.

While we could potentially expose this as a Clang-level attribute as
well, that seems like a good question to defer for the moment as it
isn't 100% clear whether that or some other programmer interface (or
both?) would be best. We'll defer the programmer interface side of this
for now, but at least get to the point where the feature can be enabled
without relying on implementation details.

This also allows us to do something that was really hard before: we can
enable *just* the indirect call retpolines when using SLH. For x86, we
don't have any other way to mitigate indirect calls. Other architectures
may take a different approach of course, and none of this is surfaced to
user-level flags.

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

Added:
cfe/trunk/test/CodeGen/attr-speculative-load-hardening.c
Modified:
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/Driver/ToolChains/Arch/X86.cpp
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Driver/x86-target-features.c

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=341363=341362=341363=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Tue Sep  4 05:38:00 2018
@@ -2009,6 +2009,10 @@ def mno_stackrealign : Flag<["-"], "mno-
 
 def mretpoline : Flag<["-"], "mretpoline">, Group, 
Flags<[CoreOption,DriverOption]>;
 def mno_retpoline : Flag<["-"], "mno-retpoline">, Group, 
Flags<[CoreOption,DriverOption]>;
+def mspeculative_load_hardening : Flag<["-"], "mspeculative-load-hardening">,
+  Group, Flags<[CoreOption,CC1Option]>;
+def mno_speculative_load_hardening : Flag<["-"], 
"mno-speculative-load-hardening">,
+  Group, Flags<[CoreOption]>;
 
 def mrelax : Flag<["-"], "mrelax">, Group,
   HelpText<"Enable linker relaxation">;

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=341363=341362=341363=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Tue Sep  4 05:38:00 2018
@@ -211,6 +211,7 @@ CODEGENOPT(SanitizeCoverageStackDepth, 1
 CODEGENOPT(SanitizeStats , 1, 0) ///< Collect statistics for sanitizers.
 CODEGENOPT(SimplifyLibCalls  , 1, 1) ///< Set when -fbuiltin is enabled.
 CODEGENOPT(SoftFloat , 1, 0) ///< -soft-float.
+CODEGENOPT(SpeculativeLoadHardening, 1, 0) ///< Enable speculative load 
hardening.
 CODEGENOPT(FineGrainedBitfieldAccesses, 1, 0) ///< Enable fine-grained 
bitfield accesses.
 CODEGENOPT(StrictEnums   , 1, 0) ///< Optimize based on strict enum 
definition.
 CODEGENOPT(StrictVTablePointers, 1, 0) ///< Optimize based on the strict 
vtable pointers

Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=341363=341362=341363=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Tue Sep  4 05:38:00 2018
@@ -1784,6 +1784,9 @@ void CodeGenModule::ConstructDefaultFnAt
   FuncAttrs.addAttribute("stackrealign");
 if (CodeGenOpts.Backchain)
   FuncAttrs.addAttribute("backchain");
+
+if (CodeGenOpts.SpeculativeLoadHardening)
+  FuncAttrs.addAttribute(llvm::Attribute::SpeculativeLoadHardening);
   }
 
   if (getLangOpts().assumeFunctionsAreConvergent()) {

Modified: cfe/trunk/lib/Driver/ToolChains/Arch/X86.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/X86.cpp?rev=341363=341362=341363=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Arch/X86.cpp (original)
+++ 

r340727 - Try to fix this clang driver test case after r340709.

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Mon Aug 27 01:49:20 2018
New Revision: 340727

URL: http://llvm.org/viewvc/llvm-project?rev=340727=rev
Log:
Try to fix this clang driver test case after r340709.

If any of the bots complain about this, I'll just revert. This test case
is essentially trying to test the exact change made, but I think this
matches the intent of the patch in question.

Modified:
cfe/trunk/test/Driver/mips-mti-linux.c

Modified: cfe/trunk/test/Driver/mips-mti-linux.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/mips-mti-linux.c?rev=340727=340726=340727=diff
==
--- cfe/trunk/test/Driver/mips-mti-linux.c (original)
+++ cfe/trunk/test/Driver/mips-mti-linux.c Mon Aug 27 01:49:20 2018
@@ -15,7 +15,7 @@
 // CHECK-BE-HF-32R2: "{{[^"]*}}clang{{[^"]*}}" {{.*}} "-triple" 
"mips-mti-linux"
 // CHECK-BE-HF-32R2-SAME: "-fuse-init-array" "-target-cpu" "mips32r2"
 // CHECK-BE-HF-32R2-SAME: "-isysroot" "{{.*}}mips_mti_linux/sysroot"
-// CHECK-BE-HF-32R2: "{{[^"]*}}lld{{[^"]*}}" "-flavor" "old-gnu" "-target" 
"mips-mti-linux"
+// CHECK-BE-HF-32R2: "{{[^"]*}}ld.lld{{[^"]*}}"
 // CHECK-BE-HF-32R2-SAME: "--sysroot=[[SYSROOT:[^"]+]]" {{.*}} 
"-dynamic-linker" "/lib/ld-musl-mips.so.1"
 // CHECK-BE-HF-32R2-SAME: 
"[[SYSROOT]]/mips-r2-hard-musl/usr/lib{{/|}}crt1.o"
 // CHECK-BE-HF-32R2-SAME: 
"[[SYSROOT]]/mips-r2-hard-musl/usr/lib{{/|}}crti.o"
@@ -33,7 +33,7 @@
 // CHECK-LE-HF-32R2: "{{[^"]*}}clang{{[^"]*}}" {{.*}} "-triple" 
"mipsel-mti-linux"
 // CHECK-LE-HF-32R2-SAME: "-fuse-init-array" "-target-cpu" "mips32r2"
 // CHECK-LE-HF-32R2-SAME: "-isysroot" "{{.*}}mips_mti_linux/sysroot"
-// CHECK-LE-HF-32R2: "{{[^"]*}}lld{{[^"]*}}" "-flavor" "old-gnu" "-target" 
"mipsel-mti-linux"
+// CHECK-LE-HF-32R2: "{{[^"]*}}ld.lld{{[^"]*}}"
 // CHECK-LE-HF-32R2-SAME: "--sysroot=[[SYSROOT:[^"]+]]" {{.*}} 
"-dynamic-linker" "/lib/ld-musl-mipsel.so.1"
 // CHECK-LE-HF-32R2-SAME: 
"[[SYSROOT]]/mipsel-r2-hard-musl/usr/lib{{/|}}crt1.o"
 // CHECK-LE-HF-32R2-SAME: 
"[[SYSROOT]]/mipsel-r2-hard-musl/usr/lib{{/|}}crti.o"


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

Re: r340709 - [Driver] Change MipsLinux default linker from "lld" to "ld.lld"

[Chandler Carruth via cfe-commits]

Build bots have been broken all day, so I'm trying a speculative fix in
r340727. If this doesn't work, i'll just revert all of this.

On Sun, Aug 26, 2018 at 3:51 PM Chandler Carruth 
wrote:

> FYI, test cases also seem to need updating:
>
> http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/19575/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Amips-mti-linux.c
>
> On Sun, Aug 26, 2018 at 12:48 PM Fangrui Song via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: maskray
>> Date: Sun Aug 26 12:47:23 2018
>> New Revision: 340709
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=340709=rev
>> Log:
>> [Driver] Change MipsLinux default linker from "lld" to "ld.lld"
>>
>> Reviewers: kzhuravl, atanasyan
>>
>> Reviewed By: atanasyan
>>
>> Subscribers: sdardis, arichardson, jrtc27, atanasyan, cfe-commits
>>
>> Differential Revision: https://reviews.llvm.org/D51234
>>
>> Modified:
>> cfe/trunk/lib/Driver/ToolChains/MipsLinux.h
>>
>> Modified: cfe/trunk/lib/Driver/ToolChains/MipsLinux.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/MipsLinux.h?rev=340709=340708=340709=diff
>>
>> ==
>> --- cfe/trunk/lib/Driver/ToolChains/MipsLinux.h (original)
>> +++ cfe/trunk/lib/Driver/ToolChains/MipsLinux.h Sun Aug 26 12:47:23 2018
>> @@ -49,7 +49,7 @@ public:
>>}
>>
>>const char *getDefaultLinker() const override {
>> -return "lld";
>> +return "ld.lld";
>>}
>>
>>  private:
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r340709 - [Driver] Change MipsLinux default linker from "lld" to "ld.lld"

[Chandler Carruth via cfe-commits]

FYI, test cases also seem to need updating:
http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/19575/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Amips-mti-linux.c

On Sun, Aug 26, 2018 at 12:48 PM Fangrui Song via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: maskray
> Date: Sun Aug 26 12:47:23 2018
> New Revision: 340709
>
> URL: http://llvm.org/viewvc/llvm-project?rev=340709=rev
> Log:
> [Driver] Change MipsLinux default linker from "lld" to "ld.lld"
>
> Reviewers: kzhuravl, atanasyan
>
> Reviewed By: atanasyan
>
> Subscribers: sdardis, arichardson, jrtc27, atanasyan, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D51234
>
> Modified:
> cfe/trunk/lib/Driver/ToolChains/MipsLinux.h
>
> Modified: cfe/trunk/lib/Driver/ToolChains/MipsLinux.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/MipsLinux.h?rev=340709=340708=340709=diff
>
> ==
> --- cfe/trunk/lib/Driver/ToolChains/MipsLinux.h (original)
> +++ cfe/trunk/lib/Driver/ToolChains/MipsLinux.h Sun Aug 26 12:47:23 2018
> @@ -49,7 +49,7 @@ public:
>}
>
>const char *getDefaultLinker() const override {
> -return "lld";
> +return "ld.lld";
>}
>
>  private:
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r294176 - [AVR] Add support for the full set of inline asm constraints

[Chandler Carruth via cfe-commits]

This was due to r340519. I've fixed it in r340596 to clean things up.

On Thu, Aug 23, 2018 at 8:20 PM Chandler Carruth 
wrote:

> Trying new address again...
>
>
> On Thu, Aug 23, 2018 at 8:17 PM Chandler Carruth 
> wrote:
>
>> Sorry for ancient thread revival, but...
>>
>> On Mon, Feb 6, 2017 at 2:10 AM Dylan McKay via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: dylanmckay
>>> Date: Mon Feb  6 03:01:59 2017
>>> New Revision: 294176
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=294176=rev
>>> Log:
>>> [AVR] Add support for the full set of inline asm constraints
>>>
>>> Summary:
>>> Previously the method would simply return false, causing every single
>>> inline assembly constraint to trigger a compile error.
>>>
>>> This adds inline assembly constraint support for the AVR target.
>>>
>>> This patch is derived from the code in
>>> AVRISelLowering::getConstraintType.
>>>
>>> More details can be found on the AVR-GCC reference wiki
>>> http://www.nongnu.org/avr-libc/user-manual/inline_asm.html
>>>
>>> Reviewers: jroelofs, asl
>>>
>>> Reviewed By: asl
>>>
>>> Subscribers: asl, ahatanak, saaadhu, cfe-commits
>>>
>>> Differential Revision: https://reviews.llvm.org/D28344
>>>
>>> Added:
>>> cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c
>>>
>>
>> This test is currently failing. Can you look at fixing it?
>>
>>
>>
>>> cfe/trunk/test/CodeGen/avr-unsupported-inline-asm-constraints.c
>>> Modified:
>>> cfe/trunk/lib/Basic/Targets.cpp
>>>
>>> Modified: cfe/trunk/lib/Basic/Targets.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=294176=294175=294176=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/Basic/Targets.cpp (original)
>>> +++ cfe/trunk/lib/Basic/Targets.cpp Mon Feb  6 03:01:59 2017
>>> @@ -8517,6 +8517,57 @@ public:
>>>
>>>bool validateAsmConstraint(const char *,
>>>   TargetInfo::ConstraintInfo ) const
>>> override {
>>> +// There aren't any multi-character AVR specific constraints.
>>> +if (StringRef(Name).size() > 1) return false;
>>> +
>>> +switch (*Name) {
>>> +  default: return false;
>>> +  case 'a': // Simple upper registers
>>> +  case 'b': // Base pointer registers pairs
>>> +  case 'd': // Upper register
>>> +  case 'l': // Lower registers
>>> +  case 'e': // Pointer register pairs
>>> +  case 'q': // Stack pointer register
>>> +  case 'r': // Any register
>>> +  case 'w': // Special upper register pairs
>>> +  case 't': // Temporary register
>>> +  case 'x': case 'X': // Pointer register pair X
>>> +  case 'y': case 'Y': // Pointer register pair Y
>>> +  case 'z': case 'Z': // Pointer register pair Z
>>> +Info.setAllowsRegister();
>>> +return true;
>>> +  case 'I': // 6-bit positive integer constant
>>> +Info.setRequiresImmediate(0, 63);
>>> +return true;
>>> +  case 'J': // 6-bit negative integer constant
>>> +Info.setRequiresImmediate(-63, 0);
>>> +return true;
>>> +  case 'K': // Integer constant (Range: 2)
>>> +Info.setRequiresImmediate(2);
>>> +return true;
>>> +  case 'L': // Integer constant (Range: 0)
>>> +Info.setRequiresImmediate(0);
>>> +return true;
>>> +  case 'M': // 8-bit integer constant
>>> +Info.setRequiresImmediate(0, 0xff);
>>> +return true;
>>> +  case 'N': // Integer constant (Range: -1)
>>> +Info.setRequiresImmediate(-1);
>>> +return true;
>>> +  case 'O': // Integer constant (Range: 8, 16, 24)
>>> +Info.setRequiresImmediate({8, 16, 24});
>>> +return true;
>>> +  case 'P': // Integer constant (Range: 1)
>>> +Info.setRequiresImmediate(1);
>>> +return true;
>>> +  case 'R': // Integer constant (Range: -6 to 5)
>>> +Info.setRequiresImmediate(-6, 5);
>>> +return true;
>>> +  case 'G': // Floating point constant
>>> +  case 'Q': // A memory address based on Y or Z pointer with
>>> displacement.
>>> +return true;
>>> +}
>>> +
>>>  return false;
>>>}
>>>
>>>
>>> Added: cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c?rev=294176=auto
>>>
>>> ==
>>> --- cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c (added)
>>> +++ cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c Mon Feb  6
>>> 03:01:59 2017
>>> @@ -0,0 +1,124 @@
>>> +// REQUIRES: avr-registered-target
>>> +// RUN: %clang_cc1 -triple avr-unknown-unknown -emit-llvm -o - %s |
>>> FileCheck %s
>>> +
>>> +int data;
>>> +
>>> +void a() {
>>> +  // CHECK: call void asm sideeffect "add r5, $0", "a"(i16 %0)
>>> +  asm("add r5, %0" :: "a"(data));
>>> +}
>>> +
>>> +void b() {
>>> +  // CHECK: call 

r340596 - [AVR] Fix inline asm calls now that the addrspace(0) there is explicit.

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Thu Aug 23 21:45:04 2018
New Revision: 340596

URL: http://llvm.org/viewvc/llvm-project?rev=340596=rev
Log:
[AVR] Fix inline asm calls now that the addrspace(0) there is explicit.

This updates the test case for r340519 so it should pass again. r340522
only got some of the AVR tests that needed an update.

Modified:
cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c

Modified: cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c?rev=340596=340595=340596=diff
==
--- cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c (original)
+++ cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c Thu Aug 23 21:45:04 2018
@@ -4,121 +4,121 @@
 int data;
 
 void a() {
-  // CHECK: call void asm sideeffect "add r5, $0", "a"(i16 %0)
+  // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "a"(i16 %0)
   asm("add r5, %0" :: "a"(data));
 }
 
 void b() {
-  // CHECK: call void asm sideeffect "add r5, $0", "b"(i16 %0)
+  // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "b"(i16 %0)
   asm("add r5, %0" :: "b"(data));
 }
 
 void d() {
-  // CHECK: call void asm sideeffect "add r5, $0", "d"(i16 %0)
+  // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "d"(i16 %0)
   asm("add r5, %0" :: "d"(data));
 }
 
 void l() {
-  // CHECK: call void asm sideeffect "add r5, $0", "l"(i16 %0)
+  // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "l"(i16 %0)
   asm("add r5, %0" :: "l"(data));
 }
 
 void e() {
-  // CHECK: call void asm sideeffect "add r5, $0", "e"(i16 %0)
+  // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "e"(i16 %0)
   asm("add r5, %0" :: "e"(data));
 }
 
 void q() {
-  // CHECK: call void asm sideeffect "add r5, $0", "q"(i16 %0)
+  // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "q"(i16 %0)
   asm("add r5, %0" :: "q"(data));
 }
 
 void r() {
-  // CHECK: call void asm sideeffect "add r5, $0", "r"(i16 %0)
+  // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "r"(i16 %0)
   asm("add r5, %0" :: "r"(data));
 }
 
 void w() {
-  // CHECK: call void asm sideeffect "add r5, $0", "w"(i16 %0)
+  // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "w"(i16 %0)
   asm("add r5, %0" :: "w"(data));
 }
 
 void t() {
-  // CHECK: call void asm sideeffect "add r5, $0", "t"(i16 %0)
+  // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "t"(i16 %0)
   asm("add r5, %0" :: "t"(data));
 }
 
 void x() {
-  // CHECK: call void asm sideeffect "add r5, $0", "x"(i16 %0)
+  // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "x"(i16 %0)
   asm("add r5, %0" :: "x"(data));
 }
 
 void y() {
-  // CHECK: call void asm sideeffect "add r5, $0", "y"(i16 %0)
+  // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "y"(i16 %0)
   asm("add r5, %0" :: "y"(data));
 }
 
 void z() {
-  // CHECK: call void asm sideeffect "add r5, $0", "z"(i16 %0)
+  // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "z"(i16 %0)
   asm("add r5, %0" :: "z"(data));
 }
 
 void I() {
-  // CHECK: call void asm sideeffect "subi r30, $0", "I"(i16 50)
+  // CHECK: call addrspace(0) void asm sideeffect "subi r30, $0", "I"(i16 50)
   asm("subi r30, %0" :: "I"(50));
 }
 
 void J() {
-  // CHECK: call void asm sideeffect "subi r30, $0", "J"(i16 -50)
+  // CHECK: call addrspace(0) void asm sideeffect "subi r30, $0", "J"(i16 -50)
   asm("subi r30, %0" :: "J"(-50));
 }
 
 void K() {
-  // CHECK: call void asm sideeffect "subi r30, $0", "K"(i16 2)
+  // CHECK: call addrspace(0) void asm sideeffect "subi r30, $0", "K"(i16 2)
   asm("subi r30, %0" :: "K"(2));
 }
 
 void L() {
-  // CHECK: call void asm sideeffect "subi r30, $0", "L"(i16 0)
+  // CHECK: call addrspace(0) void asm sideeffect "subi r30, $0", "L"(i16 0)
   asm("subi r30, %0" :: "L"(0));
 }
 
 void M() {
-  // CHECK: call void asm sideeffect "subi r30, $0", "M"(i16 255)
+  // CHECK: call addrspace(0) void asm sideeffect "subi r30, $0", "M"(i16 255)
   asm("subi r30, %0" :: "M"(255));
 }
 
 void O() {
-  // CHECK: call void asm sideeffect "subi r30, $0", "O"(i16 16)
+  // CHECK: call addrspace(0) void asm sideeffect "subi r30, $0", "O"(i16 16)
   asm("subi r30, %0" :: "O"(16));
 }
 
 void P() {
-  // CHECK: call void asm sideeffect "subi r30, $0", "P"(i16 1)
+  // CHECK: call addrspace(0) void asm sideeffect "subi r30, $0", "P"(i16 1)
   asm("subi r30, %0" :: "P"(1));
 }
 
 void R() {
-  // CHECK: call void asm sideeffect "subi r30, $0", "R"(i16 -3)
+  // CHECK: call addrspace(0) void asm sideeffect "subi r30, $0", "R"(i16 -3)
   asm("subi r30, %0" :: "R"(-3));
 }
 
 void G() {
-  // CHECK: call void asm sideeffect "subi r30, $0", "G"(i16 50)
+  // CHECK: call addrspace(0) void asm sideeffect "subi r30, $0", "G"(i16 50)
   asm("subi r30, %0" :: "G"(50));
 }
 
 void Q() {
-  // CHECK: call void asm sideeffect "subi r30, $0", 

Re: r294176 - [AVR] Add support for the full set of inline asm constraints

[Chandler Carruth via cfe-commits]

Trying new address again...

On Thu, Aug 23, 2018 at 8:17 PM Chandler Carruth 
wrote:

> Sorry for ancient thread revival, but...
>
> On Mon, Feb 6, 2017 at 2:10 AM Dylan McKay via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: dylanmckay
>> Date: Mon Feb  6 03:01:59 2017
>> New Revision: 294176
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=294176=rev
>> Log:
>> [AVR] Add support for the full set of inline asm constraints
>>
>> Summary:
>> Previously the method would simply return false, causing every single
>> inline assembly constraint to trigger a compile error.
>>
>> This adds inline assembly constraint support for the AVR target.
>>
>> This patch is derived from the code in
>> AVRISelLowering::getConstraintType.
>>
>> More details can be found on the AVR-GCC reference wiki
>> http://www.nongnu.org/avr-libc/user-manual/inline_asm.html
>>
>> Reviewers: jroelofs, asl
>>
>> Reviewed By: asl
>>
>> Subscribers: asl, ahatanak, saaadhu, cfe-commits
>>
>> Differential Revision: https://reviews.llvm.org/D28344
>>
>> Added:
>> cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c
>>
>
> This test is currently failing. Can you look at fixing it?
>
>
>
>> cfe/trunk/test/CodeGen/avr-unsupported-inline-asm-constraints.c
>> Modified:
>> cfe/trunk/lib/Basic/Targets.cpp
>>
>> Modified: cfe/trunk/lib/Basic/Targets.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=294176=294175=294176=diff
>>
>> ==
>> --- cfe/trunk/lib/Basic/Targets.cpp (original)
>> +++ cfe/trunk/lib/Basic/Targets.cpp Mon Feb  6 03:01:59 2017
>> @@ -8517,6 +8517,57 @@ public:
>>
>>bool validateAsmConstraint(const char *,
>>   TargetInfo::ConstraintInfo ) const
>> override {
>> +// There aren't any multi-character AVR specific constraints.
>> +if (StringRef(Name).size() > 1) return false;
>> +
>> +switch (*Name) {
>> +  default: return false;
>> +  case 'a': // Simple upper registers
>> +  case 'b': // Base pointer registers pairs
>> +  case 'd': // Upper register
>> +  case 'l': // Lower registers
>> +  case 'e': // Pointer register pairs
>> +  case 'q': // Stack pointer register
>> +  case 'r': // Any register
>> +  case 'w': // Special upper register pairs
>> +  case 't': // Temporary register
>> +  case 'x': case 'X': // Pointer register pair X
>> +  case 'y': case 'Y': // Pointer register pair Y
>> +  case 'z': case 'Z': // Pointer register pair Z
>> +Info.setAllowsRegister();
>> +return true;
>> +  case 'I': // 6-bit positive integer constant
>> +Info.setRequiresImmediate(0, 63);
>> +return true;
>> +  case 'J': // 6-bit negative integer constant
>> +Info.setRequiresImmediate(-63, 0);
>> +return true;
>> +  case 'K': // Integer constant (Range: 2)
>> +Info.setRequiresImmediate(2);
>> +return true;
>> +  case 'L': // Integer constant (Range: 0)
>> +Info.setRequiresImmediate(0);
>> +return true;
>> +  case 'M': // 8-bit integer constant
>> +Info.setRequiresImmediate(0, 0xff);
>> +return true;
>> +  case 'N': // Integer constant (Range: -1)
>> +Info.setRequiresImmediate(-1);
>> +return true;
>> +  case 'O': // Integer constant (Range: 8, 16, 24)
>> +Info.setRequiresImmediate({8, 16, 24});
>> +return true;
>> +  case 'P': // Integer constant (Range: 1)
>> +Info.setRequiresImmediate(1);
>> +return true;
>> +  case 'R': // Integer constant (Range: -6 to 5)
>> +Info.setRequiresImmediate(-6, 5);
>> +return true;
>> +  case 'G': // Floating point constant
>> +  case 'Q': // A memory address based on Y or Z pointer with
>> displacement.
>> +return true;
>> +}
>> +
>>  return false;
>>}
>>
>>
>> Added: cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c?rev=294176=auto
>>
>> ==
>> --- cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c (added)
>> +++ cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c Mon Feb  6
>> 03:01:59 2017
>> @@ -0,0 +1,124 @@
>> +// REQUIRES: avr-registered-target
>> +// RUN: %clang_cc1 -triple avr-unknown-unknown -emit-llvm -o - %s |
>> FileCheck %s
>> +
>> +int data;
>> +
>> +void a() {
>> +  // CHECK: call void asm sideeffect "add r5, $0", "a"(i16 %0)
>> +  asm("add r5, %0" :: "a"(data));
>> +}
>> +
>> +void b() {
>> +  // CHECK: call void asm sideeffect "add r5, $0", "b"(i16 %0)
>> +  asm("add r5, %0" :: "b"(data));
>> +}
>> +
>> +void d() {
>> +  // CHECK: call void asm sideeffect "add r5, $0", "d"(i16 %0)
>> +  asm("add r5, %0" :: "d"(data));
>> +}
>> +
>> +void l() {
>> +  // CHECK: call void asm 

Re: r294176 - [AVR] Add support for the full set of inline asm constraints

[Chandler Carruth via cfe-commits]

Sorry for ancient thread revival, but...

On Mon, Feb 6, 2017 at 2:10 AM Dylan McKay via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: dylanmckay
> Date: Mon Feb  6 03:01:59 2017
> New Revision: 294176
>
> URL: http://llvm.org/viewvc/llvm-project?rev=294176=rev
> Log:
> [AVR] Add support for the full set of inline asm constraints
>
> Summary:
> Previously the method would simply return false, causing every single
> inline assembly constraint to trigger a compile error.
>
> This adds inline assembly constraint support for the AVR target.
>
> This patch is derived from the code in
> AVRISelLowering::getConstraintType.
>
> More details can be found on the AVR-GCC reference wiki
> http://www.nongnu.org/avr-libc/user-manual/inline_asm.html
>
> Reviewers: jroelofs, asl
>
> Reviewed By: asl
>
> Subscribers: asl, ahatanak, saaadhu, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D28344
>
> Added:
> cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c
>

This test is currently failing. Can you look at fixing it?



> cfe/trunk/test/CodeGen/avr-unsupported-inline-asm-constraints.c
> Modified:
> cfe/trunk/lib/Basic/Targets.cpp
>
> Modified: cfe/trunk/lib/Basic/Targets.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=294176=294175=294176=diff
>
> ==
> --- cfe/trunk/lib/Basic/Targets.cpp (original)
> +++ cfe/trunk/lib/Basic/Targets.cpp Mon Feb  6 03:01:59 2017
> @@ -8517,6 +8517,57 @@ public:
>
>bool validateAsmConstraint(const char *,
>   TargetInfo::ConstraintInfo ) const
> override {
> +// There aren't any multi-character AVR specific constraints.
> +if (StringRef(Name).size() > 1) return false;
> +
> +switch (*Name) {
> +  default: return false;
> +  case 'a': // Simple upper registers
> +  case 'b': // Base pointer registers pairs
> +  case 'd': // Upper register
> +  case 'l': // Lower registers
> +  case 'e': // Pointer register pairs
> +  case 'q': // Stack pointer register
> +  case 'r': // Any register
> +  case 'w': // Special upper register pairs
> +  case 't': // Temporary register
> +  case 'x': case 'X': // Pointer register pair X
> +  case 'y': case 'Y': // Pointer register pair Y
> +  case 'z': case 'Z': // Pointer register pair Z
> +Info.setAllowsRegister();
> +return true;
> +  case 'I': // 6-bit positive integer constant
> +Info.setRequiresImmediate(0, 63);
> +return true;
> +  case 'J': // 6-bit negative integer constant
> +Info.setRequiresImmediate(-63, 0);
> +return true;
> +  case 'K': // Integer constant (Range: 2)
> +Info.setRequiresImmediate(2);
> +return true;
> +  case 'L': // Integer constant (Range: 0)
> +Info.setRequiresImmediate(0);
> +return true;
> +  case 'M': // 8-bit integer constant
> +Info.setRequiresImmediate(0, 0xff);
> +return true;
> +  case 'N': // Integer constant (Range: -1)
> +Info.setRequiresImmediate(-1);
> +return true;
> +  case 'O': // Integer constant (Range: 8, 16, 24)
> +Info.setRequiresImmediate({8, 16, 24});
> +return true;
> +  case 'P': // Integer constant (Range: 1)
> +Info.setRequiresImmediate(1);
> +return true;
> +  case 'R': // Integer constant (Range: -6 to 5)
> +Info.setRequiresImmediate(-6, 5);
> +return true;
> +  case 'G': // Floating point constant
> +  case 'Q': // A memory address based on Y or Z pointer with
> displacement.
> +return true;
> +}
> +
>  return false;
>}
>
>
> Added: cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c?rev=294176=auto
>
> ==
> --- cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c (added)
> +++ cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c Mon Feb  6
> 03:01:59 2017
> @@ -0,0 +1,124 @@
> +// REQUIRES: avr-registered-target
> +// RUN: %clang_cc1 -triple avr-unknown-unknown -emit-llvm -o - %s |
> FileCheck %s
> +
> +int data;
> +
> +void a() {
> +  // CHECK: call void asm sideeffect "add r5, $0", "a"(i16 %0)
> +  asm("add r5, %0" :: "a"(data));
> +}
> +
> +void b() {
> +  // CHECK: call void asm sideeffect "add r5, $0", "b"(i16 %0)
> +  asm("add r5, %0" :: "b"(data));
> +}
> +
> +void d() {
> +  // CHECK: call void asm sideeffect "add r5, $0", "d"(i16 %0)
> +  asm("add r5, %0" :: "d"(data));
> +}
> +
> +void l() {
> +  // CHECK: call void asm sideeffect "add r5, $0", "l"(i16 %0)
> +  asm("add r5, %0" :: "l"(data));
> +}
> +
> +void e() {
> +  // CHECK: call void asm sideeffect "add r5, $0", "e"(i16 %0)
> +  asm("add r5, %0" :: "e"(data));
> +}
> +
> +void q() {
> +  // CHECK: 

r340515 - [x86/retpoline] Split the LLVM concept of retpolines into separate

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Wed Aug 22 23:06:38 2018
New Revision: 340515

URL: http://llvm.org/viewvc/llvm-project?rev=340515=rev
Log:
[x86/retpoline] Split the LLVM concept of retpolines into separate
subtarget features for indirect calls and indirect branches.

This is in preparation for enabling *only* the call retpolines when
using speculative load hardening.

I've continued to use subtarget features for now as they continue to
seem the best fit given the lack of other retpoline like constructs so
far.

The LLVM side is pretty simple. I'd like to eventually get rid of the
old feature, but not sure what backwards compatibility issues that will
cause.

This does remove the "implies" from requesting an external thunk. This
always seemed somewhat questionable and is now clearly not desirable --
you specify a thunk the same way no matter which set of things are
getting retpolines.

I really want to keep this nicely isolated from end users and just an
LLVM implementation detail, so I've moved the `-mretpoline` flag in
Clang to no longer rely on a specific subtarget feature by that name and
instead to be directly handled. In some ways this is simpler, but in
order to preserve existing behavior I've had to add some fallback code
so that users who relied on merely passing -mretpoline-external-thunk
continue to get the same behavior. We should eventually remove this
I suspect (we have never tested that it works!) but I've not done that
in this patch.

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

Modified:
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/lib/Basic/Targets/X86.cpp
cfe/trunk/lib/Basic/Targets/X86.h
cfe/trunk/lib/Driver/ToolChains/Arch/X86.cpp
cfe/trunk/test/Driver/x86-target-features.c

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=340515=340514=340515=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Wed Aug 22 23:06:38 2018
@@ -1999,6 +1999,9 @@ def mno_rtd: Flag<["-"], "mno-rtd">, Gro
 def mno_soft_float : Flag<["-"], "mno-soft-float">, Group;
 def mno_stackrealign : Flag<["-"], "mno-stackrealign">, Group;
 
+def mretpoline : Flag<["-"], "mretpoline">, Group, 
Flags<[CoreOption,DriverOption]>;
+def mno_retpoline : Flag<["-"], "mno-retpoline">, Group, 
Flags<[CoreOption,DriverOption]>;
+
 def mrelax : Flag<["-"], "mrelax">, Group,
   HelpText<"Enable linker relaxation">;
 def mno_relax : Flag<["-"], "mno-relax">, Group,
@@ -2824,8 +2827,6 @@ def mxsaves : Flag<["-"], "mxsaves">, Gr
 def mno_xsaves : Flag<["-"], "mno-xsaves">, Group;
 def mshstk : Flag<["-"], "mshstk">, Group;
 def mno_shstk : Flag<["-"], "mno-shstk">, Group;
-def mretpoline : Flag<["-"], "mretpoline">, Group;
-def mno_retpoline : Flag<["-"], "mno-retpoline">, Group;
 def mretpoline_external_thunk : Flag<["-"], "mretpoline-external-thunk">, 
Group;
 def mno_retpoline_external_thunk : Flag<["-"], 
"mno-retpoline-external-thunk">, Group;
 

Modified: cfe/trunk/lib/Basic/Targets/X86.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/X86.cpp?rev=340515=340514=340515=diff
==
--- cfe/trunk/lib/Basic/Targets/X86.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/X86.cpp Wed Aug 22 23:06:38 2018
@@ -796,8 +796,6 @@ bool X86TargetInfo::handleTargetFeatures
   HasCLDEMOTE = true;
 } else if (Feature == "+rdpid") {
   HasRDPID = true;
-} else if (Feature == "+retpoline") {
-  HasRetpoline = true;
 } else if (Feature == "+retpoline-external-thunk") {
   HasRetpolineExternalThunk = true;
 } else if (Feature == "+sahf") {
@@ -1397,7 +1395,6 @@ bool X86TargetInfo::hasFeature(StringRef
   .Case("rdpid", HasRDPID)
   .Case("rdrnd", HasRDRND)
   .Case("rdseed", HasRDSEED)
-  .Case("retpoline", HasRetpoline)
   .Case("retpoline-external-thunk", HasRetpolineExternalThunk)
   .Case("rtm", HasRTM)
   .Case("sahf", HasLAHFSAHF)

Modified: cfe/trunk/lib/Basic/Targets/X86.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/X86.h?rev=340515=340514=340515=diff
==
--- cfe/trunk/lib/Basic/Targets/X86.h (original)
+++ cfe/trunk/lib/Basic/Targets/X86.h Wed Aug 22 23:06:38 2018
@@ -98,7 +98,6 @@ class LLVM_LIBRARY_VISIBILITY X86TargetI
   bool HasMOVBE = false;
   bool HasPREFETCHWT1 = false;
   bool HasRDPID = false;
-  bool HasRetpoline = false;
   bool HasRetpolineExternalThunk = false;
   bool HasLAHFSAHF = false;
   bool HasWBNOINVD = false;

Modified: cfe/trunk/lib/Driver/ToolChains/Arch/X86.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/X86.cpp?rev=340515=340514=340515=diff

r338979 - [docs] Don't use the `asm` syntax highlighting (which our docs builder

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Sun Aug  5 18:28:42 2018
New Revision: 338979

URL: http://llvm.org/viewvc/llvm-project?rev=338979=rev
Log:
[docs] Don't use the `asm` syntax highlighting (which our docs builder
errors on) and clean up the formattting.

This isn't actualy assembly anyways, so dropping the highlighting is
probably for the best.

Modified:
cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst

Modified: cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst?rev=338979=338978=338979=diff
==
--- cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst (original)
+++ cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst Sun Aug  5 
18:28:42 2018
@@ -47,21 +47,21 @@ All memory accesses are prefixed with an
 verifies the tags. Currently, the following sequence is used:
 
 
-.. code-block:: asm
+.. code-block:: none
 
   // int foo(int *a) { return *a; }
   // clang -O2 --target=aarch64-linux -fsanitize=hwaddress -c load.c
   foo:
0:  08 00 00 90 adrpx8, 0 <__hwasan_shadow>
-   4:  08 01 40 f9 ldr x8, [x8] // shadow base (to be 
resolved by the loader)
-   8:  09 dc 44 d3 ubfxx9, x0, #4, #52  // shadow offset
-   c:  28 69 68 38 ldrbw8, [x9, x8] // load shadow tag
-  10:  09 fc 78 d3 lsr x9, x0, #56  // extract address tag
-  14:  3f 01 08 6b cmp w9, w8   // compare tags
-  18:  61 00 00 54 b.ne24   // jump on mismatch
-  1c:  00 00 40 b9 ldr w0, [x0] // original load
+   4:  08 01 40 f9 ldr x8, [x8]  // shadow base (to be 
resolved by the loader)
+   8:  09 dc 44 d3 ubfxx9, x0, #4, #52 // shadow offset
+   c:  28 69 68 38 ldrbw8, [x9, x8]// load shadow tag
+  10:  09 fc 78 d3 lsr x9, x0, #56   // extract address tag
+  14:  3f 01 08 6b cmp w9, w8// compare tags
+  18:  61 00 00 54 b.ne24  // jump on mismatch
+  1c:  00 00 40 b9 ldr w0, [x0]  // original load
   20:  c0 03 5f d6 ret
-  24:  40 20 21 d4 brk #0x902   // trap
+  24:  40 20 21 d4 brk #0x902// trap
 
 Alternatively, memory accesses are prefixed with a function call.
 


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

r338209 - Revert r337456: [CodeGen] Disable aggressive structor optimizations at -O0, take 3

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Sat Jul 28 20:05:07 2018
New Revision: 338209

URL: http://llvm.org/viewvc/llvm-project?rev=338209=rev
Log:
Revert r337456: [CodeGen] Disable aggressive structor optimizations at -O0, 
take 3

This commit increases the number of sections and overall output size of
.o files by 10% and sometimes a bit more. This alone is challenging for
some users, but it also appears to trigger an as-yet unexplained
behavior in the Gold linker where the memory usage increases
considerably more than 10% (we think).

The increase is also frustrating because in many (if not all) cases we
end up with almost all of the growth coming from the ELF overhead of
-ffunction-sections and such, not from actual extra code being emitted.

Richard Smith and Eric Christopher are both going to investigate this
and try to get to the bottom of what is triggering this and whether the
kinds of increases here are sustainable or what options we might have to
minimize the impact they have. However, this is currently breaking
a pretty large number of our users' builds so reverting it while we sort
out how to make progress here. I've seen a longer and more detailed
update to the commit thread.

Modified:
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/test/CodeGenCXX/ctor-dtor-alias.cpp
cfe/trunk/test/CodeGenCXX/float16-declarations.cpp

Modified: cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp?rev=338209=338208=338209=diff
==
--- cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp (original)
+++ cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp Sat Jul 28 20:05:07 2018
@@ -3744,22 +3744,12 @@ static StructorCodegen getCodegenToUse(C
   }
   llvm::GlobalValue::LinkageTypes Linkage = CGM.getFunctionLinkage(AliasDecl);
 
-  // All discardable structors can be RAUWed, but we don't want to do that in
-  // unoptimized code, as that makes complete structor symbol disappear
-  // completely, which degrades debugging experience.
-  // Symbols with private linkage can be safely aliased, so we special case 
them
-  // here.
-  if (llvm::GlobalValue::isLocalLinkage(Linkage))
-return CGM.getCodeGenOpts().OptimizationLevel > 0 ? StructorCodegen::RAUW
-  : StructorCodegen::Alias;
+  if (llvm::GlobalValue::isDiscardableIfUnused(Linkage))
+return StructorCodegen::RAUW;
 
-  // Linkonce structors cannot be aliased nor placed in a comdat, so these need
-  // to be emitted separately.
   // FIXME: Should we allow available_externally aliases?
-  if (llvm::GlobalValue::isDiscardableIfUnused(Linkage) ||
-  !llvm::GlobalAlias::isValidLinkage(Linkage))
-return CGM.getCodeGenOpts().OptimizationLevel > 0 ? StructorCodegen::RAUW
-  : StructorCodegen::Emit;
+  if (!llvm::GlobalAlias::isValidLinkage(Linkage))
+return StructorCodegen::RAUW;
 
   if (llvm::GlobalValue::isWeakForLinker(Linkage)) {
 // Only ELF and wasm support COMDATs with arbitrary names (C5/D5).

Modified: cfe/trunk/test/CodeGenCXX/ctor-dtor-alias.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/ctor-dtor-alias.cpp?rev=338209=338208=338209=diff
==
--- cfe/trunk/test/CodeGenCXX/ctor-dtor-alias.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/ctor-dtor-alias.cpp Sat Jul 28 20:05:07 2018
@@ -1,7 +1,5 @@
-// RUN: %clang_cc1 %s -triple i686-linux -emit-llvm -o - -mconstructor-aliases 
> %t
-// RUN: FileCheck --check-prefix=NOOPT1 --input-file=%t %s
-// RUN: FileCheck --check-prefix=NOOPT2 --input-file=%t %s
-// RUN: FileCheck --check-prefix=NOOPT3 --input-file=%t %s
+// RUN: %clang_cc1 %s -triple i686-linux -emit-llvm -o - -mconstructor-aliases 
| FileCheck --check-prefix=NOOPT %s
+
 // RUN: %clang_cc1 %s -triple i686-linux -emit-llvm -o - -mconstructor-aliases 
-O1 -disable-llvm-passes > %t
 // RUN: FileCheck --check-prefix=CHECK1 --input-file=%t %s
 // RUN: FileCheck --check-prefix=CHECK2 --input-file=%t %s
@@ -23,13 +21,6 @@ namespace test1 {
 // CHECK1: define weak_odr void @_ZN5test16foobarIvED0Ev({{.*}} 
comdat($_ZN5test16foobarIvED5Ev)
 // CHECK1-NOT: comdat
 
-// This should happen regardless of the opt level.
-// NOOPT1: @_ZN5test16foobarIvEC1Ev = weak_odr unnamed_addr alias void {{.*}} 
@_ZN5test16foobarIvEC2Ev
-// NOOPT1: @_ZN5test16foobarIvED1Ev = weak_odr unnamed_addr alias void 
(%"struct.test1::foobar"*), void (%"struct.test1::foobar"*)* 
@_ZN5test16foobarIvED2Ev
-// NOOPT1: define weak_odr void @_ZN5test16foobarIvEC2Ev({{.*}} 
comdat($_ZN5test16foobarIvEC5Ev)
-// NOOPT1: define weak_odr void @_ZN5test16foobarIvED2Ev({{.*}} 
comdat($_ZN5test16foobarIvED5Ev)
-// NOOPT1: define weak_odr void @_ZN5test16foobarIvED0Ev({{.*}} 
comdat($_ZN5test16foobarIvED5Ev)
-
 // COFF doesn't support comdats with arbitrary names (C5/D5).
 

Re: r337456 - [CodeGen] Disable aggressive structor optimizations at -O0, take 3

[Chandler Carruth via cfe-commits]

On Sat, Jul 28, 2018 at 2:26 AM Chandler Carruth 
wrote:

> On Thu, Jul 19, 2018 at 7:10 AM Pavel Labath via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: labath
>> Date: Thu Jul 19 07:05:22 2018
>> New Revision: 337456
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=337456=rev
>> Log:
>> [CodeGen] Disable aggressive structor optimizations at -O0, take 3
>>
>
> I'm really sorry to do this, but I need to revert this patch Let me
> try to explain
>
> We're seeing at least two issues with it that are causing *serious* issues
> for our users, and due to numerous other things, we really need to get
> top-of-tree into usable shape sooner rather than later. As this is
> improving a long-standing deficiency in Clang, I think it is reasonable to
> revert temporarily while we sort it out. I'm CC-ing Richard Smith and Eric
> Christopher directly as I'm going to ask them to make sure we get
> satisfactory answers to why this patch causes us so many problems and how
> we can make progress here.
>
> I don't have a test case at the moment, and I want to *very clearly* call
> out that it is on us to find a test case or otherwise clearly explain what
> problem this patch causes and how it can be addressed, or else this patch
> should be re-landed.
>
> To at least give some idea of what is going wrong here..
>
> First, this patch does increase object code size. This isn't really
> unexpected based on the nature of the patch, and it does so ostensibly in
> order to gain material fidelity improvements to debug information. Despite
> the fact that the increased object size causes us problems (it made a few
> hundered of our binaries' inputs too large to fit into the quota for the
> input files to our internal distributed build system) we tried to soldier
> onward...
>
> But it also causes the Gold linker at least to use considerably more
> memory than it used to. This has resulted in over 400 failures to link
> executables due to running out of available memory on the system.
>
> There are a number of possible causes for both the input size issues and
> the linker memory issue:
> - An unexpected side-effect of this change causes lots of redundant
> sections to be output with -ffunction-sections, all of which merge away
> into nothing, but this takes huge amounts of object file and linker
> resources.
> - The object file size increease is expected and unavoidable, but there is
> some bug in the linker being triggered?
> - Something else
>

I wanted to at least do some initial investigation before reverting and
I've done that now.

What I'm seeing is a 10% or higher increase in the number of sections and
the size spent on ELF headers. This doesn't seem *too* surprising. What is
surprising is that this seems to cause an even larger increase in memory
usage by gold.

Anyways, we'll have to debug this more to truly understand what the issue
is and whether there is something we can do with this patch that would
improve things (such as maybe using fewer sections?) or whether this all
just needs to be guarded under a flag.

I'm going to revert for now, but hopefully first thing Monday, Richard and
Eric can help out with suggestions on how to make progress here.

Again, really sorry about this, especially on the third iteration
-Chandler


>
> It is going to take us some time to investigate these issues, and sadly,
> all of these issues are breaking builds actively for us.
>
> So while we will work very hard on getting to a resolution, if you also
> really need this functionality to land sooner rather than later, what I
> would request is to add it back under a flag. In fact, if you need that and
> request it, we can do the actual work of adding it back under a flag. I
> think that's the least we can do here.
>
> Anyways, again, sorry to revert with relatively little warning and with
> relatively little info.
>
> Feel free to reach out to myself or Richard Smith, or Eric Christopher who
> will all be looking at this first thing next week to understand exactly
> what is going on here and what the root causes is and whether any of these
> issues are due to bugs in some tool or another, or whether these are all
> due to some particular issue with our source code.
>
> -Chandler
>
>
>> The previous version of this patch (r332839) was reverted because it was
>> causing "definition with same mangled name as another definition" errors
>> in some module builds. This was caused by an unrelated bug in module
>> importing which it exposed. The importing problem was fixed in r336240,
>> so this recommits the original patch (r332839).
>>
>> Differential Revision: https://reviews.llvm.org/D46685
>>
>> Modified:
>> cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
>> cfe/trunk/test/CodeGenCXX/ctor-dtor-alias.cpp
>> cfe/trunk/test/CodeGenCXX/float16-declarations.cpp
>>
>> Modified: cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
>> URL:
>> 

Re: r337456 - [CodeGen] Disable aggressive structor optimizations at -O0, take 3

[Chandler Carruth via cfe-commits]

On Thu, Jul 19, 2018 at 7:10 AM Pavel Labath via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: labath
> Date: Thu Jul 19 07:05:22 2018
> New Revision: 337456
>
> URL: http://llvm.org/viewvc/llvm-project?rev=337456=rev
> Log:
> [CodeGen] Disable aggressive structor optimizations at -O0, take 3
>

I'm really sorry to do this, but I need to revert this patch Let me try
to explain

We're seeing at least two issues with it that are causing *serious* issues
for our users, and due to numerous other things, we really need to get
top-of-tree into usable shape sooner rather than later. As this is
improving a long-standing deficiency in Clang, I think it is reasonable to
revert temporarily while we sort it out. I'm CC-ing Richard Smith and Eric
Christopher directly as I'm going to ask them to make sure we get
satisfactory answers to why this patch causes us so many problems and how
we can make progress here.

I don't have a test case at the moment, and I want to *very clearly* call
out that it is on us to find a test case or otherwise clearly explain what
problem this patch causes and how it can be addressed, or else this patch
should be re-landed.

To at least give some idea of what is going wrong here..

First, this patch does increase object code size. This isn't really
unexpected based on the nature of the patch, and it does so ostensibly in
order to gain material fidelity improvements to debug information. Despite
the fact that the increased object size causes us problems (it made a few
hundered of our binaries' inputs too large to fit into the quota for the
input files to our internal distributed build system) we tried to soldier
onward...

But it also causes the Gold linker at least to use considerably more memory
than it used to. This has resulted in over 400 failures to link executables
due to running out of available memory on the system.

There are a number of possible causes for both the input size issues and
the linker memory issue:
- An unexpected side-effect of this change causes lots of redundant
sections to be output with -ffunction-sections, all of which merge away
into nothing, but this takes huge amounts of object file and linker
resources.
- The object file size increease is expected and unavoidable, but there is
some bug in the linker being triggered?
- Something else

It is going to take us some time to investigate these issues, and sadly,
all of these issues are breaking builds actively for us.

So while we will work very hard on getting to a resolution, if you also
really need this functionality to land sooner rather than later, what I
would request is to add it back under a flag. In fact, if you need that and
request it, we can do the actual work of adding it back under a flag. I
think that's the least we can do here.

Anyways, again, sorry to revert with relatively little warning and with
relatively little info.

Feel free to reach out to myself or Richard Smith, or Eric Christopher who
will all be looking at this first thing next week to understand exactly
what is going on here and what the root causes is and whether any of these
issues are due to bugs in some tool or another, or whether these are all
due to some particular issue with our source code.

-Chandler


> The previous version of this patch (r332839) was reverted because it was
> causing "definition with same mangled name as another definition" errors
> in some module builds. This was caused by an unrelated bug in module
> importing which it exposed. The importing problem was fixed in r336240,
> so this recommits the original patch (r332839).
>
> Differential Revision: https://reviews.llvm.org/D46685
>
> Modified:
> cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
> cfe/trunk/test/CodeGenCXX/ctor-dtor-alias.cpp
> cfe/trunk/test/CodeGenCXX/float16-declarations.cpp
>
> Modified: cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp?rev=337456=337455=337456=diff
>
> ==
> --- cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp (original)
> +++ cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp Thu Jul 19 07:05:22 2018
> @@ -3737,12 +3737,22 @@ static StructorCodegen getCodegenToUse(C
>}
>llvm::GlobalValue::LinkageTypes Linkage =
> CGM.getFunctionLinkage(AliasDecl);
>
> -  if (llvm::GlobalValue::isDiscardableIfUnused(Linkage))
> -return StructorCodegen::RAUW;
> +  // All discardable structors can be RAUWed, but we don't want to do
> that in
> +  // unoptimized code, as that makes complete structor symbol disappear
> +  // completely, which degrades debugging experience.
> +  // Symbols with private linkage can be safely aliased, so we special
> case them
> +  // here.
> +  if (llvm::GlobalValue::isLocalLinkage(Linkage))
> +return CGM.getCodeGenOpts().OptimizationLevel > 0 ?
> StructorCodegen::RAUW
> +  :
> 

r335310 - [x86] Fix a tiny bug in my test case in r335309 by marking that we don't

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Thu Jun 21 16:52:36 2018
New Revision: 335310

URL: http://llvm.org/viewvc/llvm-project?rev=335310=rev
Log:
[x86] Fix a tiny bug in my test case in r335309 by marking that we don't
expect any diagnostics.

Modified:
cfe/trunk/test/Sema/builtins-x86.cpp

Modified: cfe/trunk/test/Sema/builtins-x86.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/builtins-x86.cpp?rev=335310=335309=335310=diff
==
--- cfe/trunk/test/Sema/builtins-x86.cpp (original)
+++ cfe/trunk/test/Sema/builtins-x86.cpp Thu Jun 21 16:52:36 2018
@@ -2,6 +2,7 @@
 //
 // Ensure that when we use builtins in C++ code with templates that compute the
 // valid immediate, the dead code with the invalid immediate doesn't error.
+// expected-no-diagnostics
 
 typedef short __v8hi __attribute__((__vector_size__(16)));
 
@@ -20,4 +21,4 @@ template __v8hi test<3>(__v8hi);
 template __v8hi test<4>(__v8hi);
 template __v8hi test<5>(__v8hi);
 template __v8hi test<6>(__v8hi);
-template __v8hi test<7>(__v8hi);
\ No newline at end of file
+template __v8hi test<7>(__v8hi);


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

r335309 - [x86] Teach the builtin argument range check to allow invalid ranges in

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Thu Jun 21 16:46:09 2018
New Revision: 335309

URL: http://llvm.org/viewvc/llvm-project?rev=335309=rev
Log:
[x86] Teach the builtin argument range check to allow invalid ranges in
dead code.

This is important for C++ templates that essentially compute the valid
input in a way that is constant and will cause all the invalid cases to
be dead code that is deleted. Code in the wild actually does this and
GCC also accepts these kinds of patterns so it is important to support
it.

To make this work, we provide a non-error path to diagnose these issues,
and use a default-error warning instead. This keeps the relatively
strict handling but prevents nastiness like SFINAE on these errors. It
also allows us to safely use the system to diagnose this only when it
occurs at runtime (in emitted code).

Entertainingly, this required fixing the syntax in various other ways
for the x86 test because we never bothered to diagnose that the returns
were invalid.

Since debugging these compile failures was super confusing, I've also
improved the diagnostic to actually say what the value was. Most of the
checks I've made ignore this to simplify maintenance, but I've checked
it in a few places to make sure the diagnsotic is working.

Depends on D48462. Without that, we might actually crash some part of
the compiler after bypassing the error here.

Thanks to Richard, Ben Kramer, and especially Craig Topper for all the
help here.

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

Added:
cfe/trunk/test/Sema/builtins-x86.cpp
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaChecking.cpp
cfe/trunk/test/CodeGen/builtins-mips-args.c
cfe/trunk/test/CodeGen/builtins-systemz-vector-error.c
cfe/trunk/test/CodeGen/builtins-systemz-vector2-error.c
cfe/trunk/test/CodeGen/builtins-systemz-zvector-error.c
cfe/trunk/test/CodeGen/builtins-systemz-zvector2-error.c
cfe/trunk/test/CodeGen/hexagon-check-builtins.c
cfe/trunk/test/Sema/aarch64-neon-fp16-ranges.c
cfe/trunk/test/Sema/aarch64-neon-ranges.c
cfe/trunk/test/Sema/arm-neon-types.c
cfe/trunk/test/Sema/builtin-object-size.c
cfe/trunk/test/Sema/builtin-prefetch.c
cfe/trunk/test/Sema/builtins-arm.c
cfe/trunk/test/Sema/builtins-arm64.c
cfe/trunk/test/Sema/builtins-ppc.c
cfe/trunk/test/Sema/builtins-x86.c
cfe/trunk/test/SemaCXX/neon-vector-types.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=335309=335308=335309=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu Jun 21 16:46:09 
2018
@@ -8132,7 +8132,10 @@ def err_altivec_empty_initializer : Erro
 def err_invalid_neon_type_code : Error<
   "incompatible constant for this __builtin_neon function">; 
 def err_argument_invalid_range : Error<
-  "argument should be a value from %0 to %1">;
+  "argument value %0 is outside the valid range [%1, %2]">;
+def warn_argument_invalid_range : Warning<
+  "argument value %0 is outside the valid range [%1, %2]">, DefaultError,
+  InGroup>;
 def err_argument_not_multiple : Error<
   "argument should be a multiple of %0">;
 def warn_neon_vector_initializer_non_portable : Warning<

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=335309=335308=335309=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Thu Jun 21 16:46:09 2018
@@ -10431,8 +10431,8 @@ private:
 bool IsDelete);
   bool SemaBuiltinConstantArg(CallExpr *TheCall, int ArgNum,
   llvm::APSInt );
-  bool SemaBuiltinConstantArgRange(CallExpr *TheCall, int ArgNum,
-   int Low, int High);
+  bool SemaBuiltinConstantArgRange(CallExpr *TheCall, int ArgNum, int Low,
+   int High, bool RangeIsError = true);
   bool SemaBuiltinConstantArgMultiple(CallExpr *TheCall, int ArgNum,
   unsigned Multiple);
   bool SemaBuiltinARMSpecialReg(unsigned BuiltinID, CallExpr *TheCall,

Modified: cfe/trunk/lib/Sema/SemaChecking.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaChecking.cpp?rev=335309=335308=335309=diff
==
--- cfe/trunk/lib/Sema/SemaChecking.cpp (original)
+++ cfe/trunk/lib/Sema/SemaChecking.cpp Thu Jun 21 16:46:09 2018
@@ -2937,7 +2937,12 @@ bool Sema::CheckX86BuiltinFunctionCall(u
 i = 4; l = 0; u = 255;
 break;
   }
-  return 

r331411 - [gcov] Make the CLang side coverage test work with the new

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Wed May  2 15:57:20 2018
New Revision: 331411

URL: http://llvm.org/viewvc/llvm-project?rev=331411=rev
Log:
[gcov] Make the CLang side coverage test work with the new
instrumentation codegeneration strategy of using a data structure and
a loop. Required some finesse to get the critical things being tested to
surface in a nice way for FileCheck but I think this preserves the
original intent of the test.

Modified:
cfe/trunk/test/CodeGen/code-coverage.c

Modified: cfe/trunk/test/CodeGen/code-coverage.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/code-coverage.c?rev=331411=331410=331411=diff
==
--- cfe/trunk/test/CodeGen/code-coverage.c (original)
+++ cfe/trunk/test/CodeGen/code-coverage.c Wed May  2 15:57:20 2018
@@ -23,17 +23,25 @@ int test1(int a) {
   return a;
 }
 
+int test2(int b) {
+  return b * 2;
+}
+
+// Inside function emission data structure, check that
+// -coverage-no-function-names-in-data uses null as the function name.
+// CHECK: @__llvm_internal_gcov_emit_function_args.0 = internal unnamed_addr 
constant
+// CHECK-SAME: { i32 {{[0-9]+}}, i8* getelementptr inbounds ({{[^,]*}}, 
{{[^,]*}}* @
+// CHECK-SAME: { i32 {{[0-9]+}}, i8* getelementptr inbounds ({{[^,]*}}, 
{{[^,]*}}* @
+// WITHOUTNAMES: @__llvm_internal_gcov_emit_function_args.0 = internal 
unnamed_addr constant
+// WITHOUTNAMES-NOT: getelementptr inbounds ({{.*}}@
+// WITHOUTNAMES-SAME: zeroinitializer,
+// WITHOUTNAMES-NOT: getelementptr inbounds ({{.*}}@
+// WITHOUTNAMES-SAME: { i32 {{[0-9]+}}, i8* null,
+
 // Check that the noredzone flag is set on the generated functions.
 
 // CHECK: void @__llvm_gcov_indirect_counter_increment(i32* %{{.*}}, i64** 
%{{.*}}) unnamed_addr [[NRZ:#[0-9]+]]
-
-// Inside llvm_gcov_writeout, check that -coverage-no-function-names-in-data
-// passes null as the function name.
 // CHECK: void @__llvm_gcov_writeout() unnamed_addr [[NRZ]]
-// CHECK: call void @llvm_gcda_emit_function({{.*}}, i8* getelementptr {{.*}}, 
{{.*}})
-// WITHOUTNAMES: void @__llvm_gcov_writeout() unnamed_addr
-// WITHOUTNAMES: call void @llvm_gcda_emit_function({{.*}}, i8* null, {{.*}})
-
 // CHECK: void @__llvm_gcov_flush() unnamed_addr [[NRZ]]
 // CHECK: void @__llvm_gcov_init() unnamed_addr [[NRZ]]
 


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

Re: r331244 - Implement P0482R2, support for char8_t type.

[Chandler Carruth via cfe-commits]

I adjusted the test case in r331245 - it was failing for me and most of the
build bots. Please check that I didn't miss anything.

On Mon, Apr 30, 2018 at 10:06 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Mon Apr 30 22:02:45 2018
> New Revision: 331244
>
> URL: http://llvm.org/viewvc/llvm-project?rev=331244=rev
> Log:
> Implement P0482R2, support for char8_t type.
>
> This is not yet part of any C++ working draft, and so is controlled by the
> flag
> -fchar8_t rather than a -std= flag. (The GCC implementation is controlled
> by a
> flag with the same name.)
>
> This implementation is experimental, and will be removed or revised
> substantially to match the proposal as it makes its way through the C++
> committee.
>
> Added:
> cfe/trunk/test/CodeGenCXX/char8_t.cpp
> cfe/trunk/test/Lexer/char8_t.cpp
> cfe/trunk/test/SemaCXX/char8_t.cpp
> Modified:
> cfe/trunk/include/clang/AST/ASTContext.h
> cfe/trunk/include/clang/AST/BuiltinTypes.def
> cfe/trunk/include/clang/AST/Type.h
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/include/clang/Basic/LangOptions.def
> cfe/trunk/include/clang/Basic/Specifiers.h
> cfe/trunk/include/clang/Basic/TokenKinds.def
> cfe/trunk/include/clang/Driver/Options.td
> cfe/trunk/include/clang/Sema/DeclSpec.h
> cfe/trunk/include/clang/Sema/Initialization.h
> cfe/trunk/include/clang/Serialization/ASTBitCodes.h
> cfe/trunk/lib/AST/ASTContext.cpp
> cfe/trunk/lib/AST/ExprConstant.cpp
> cfe/trunk/lib/AST/ItaniumMangle.cpp
> cfe/trunk/lib/AST/MicrosoftMangle.cpp
> cfe/trunk/lib/AST/NSAPI.cpp
> cfe/trunk/lib/AST/Type.cpp
> cfe/trunk/lib/AST/TypeLoc.cpp
> cfe/trunk/lib/Analysis/PrintfFormatString.cpp
> cfe/trunk/lib/Basic/IdentifierTable.cpp
> cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
> cfe/trunk/lib/CodeGen/CodeGenTypes.cpp
> cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
> cfe/trunk/lib/Driver/ToolChains/Clang.cpp
> cfe/trunk/lib/Format/FormatToken.cpp
> cfe/trunk/lib/Frontend/CompilerInvocation.cpp
> cfe/trunk/lib/Frontend/InitPreprocessor.cpp
> cfe/trunk/lib/Index/USRGeneration.cpp
> cfe/trunk/lib/Lex/PPExpressions.cpp
> cfe/trunk/lib/Parse/ParseDecl.cpp
> cfe/trunk/lib/Parse/ParseExpr.cpp
> cfe/trunk/lib/Parse/ParseExprCXX.cpp
> cfe/trunk/lib/Parse/ParseTentative.cpp
> cfe/trunk/lib/Sema/DeclSpec.cpp
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/lib/Sema/SemaDeclCXX.cpp
> cfe/trunk/lib/Sema/SemaExpr.cpp
> cfe/trunk/lib/Sema/SemaInit.cpp
> cfe/trunk/lib/Sema/SemaOverload.cpp
> cfe/trunk/lib/Sema/SemaTemplate.cpp
> cfe/trunk/lib/Sema/SemaTemplateVariadic.cpp
> cfe/trunk/lib/Sema/SemaType.cpp
> cfe/trunk/lib/Serialization/ASTCommon.cpp
> cfe/trunk/lib/Serialization/ASTReader.cpp
> cfe/trunk/test/Lexer/cxx-features.cpp
>
> Modified: cfe/trunk/include/clang/AST/ASTContext.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=331244=331243=331244=diff
>
> ==
> --- cfe/trunk/include/clang/AST/ASTContext.h (original)
> +++ cfe/trunk/include/clang/AST/ASTContext.h Mon Apr 30 22:02:45 2018
> @@ -999,6 +999,7 @@ public:
>CanQualType WCharTy;  // [C++ 3.9.1p5].
>CanQualType WideCharTy; // Same as WCharTy in C++, integer type in C99.
>CanQualType WIntTy;   // [C99 7.24.1], integer type unchanged by
> default promotions.
> +  CanQualType Char8Ty;  // [C++20 proposal]
>CanQualType Char16Ty; // [C++0x 3.9.1p5], integer type in C99.
>CanQualType Char32Ty; // [C++0x 3.9.1p5], integer type in C99.
>CanQualType SignedCharTy, ShortTy, IntTy, LongTy, LongLongTy, Int128Ty;
>
> Modified: cfe/trunk/include/clang/AST/BuiltinTypes.def
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/BuiltinTypes.def?rev=331244=331243=331244=diff
>
> ==
> --- cfe/trunk/include/clang/AST/BuiltinTypes.def (original)
> +++ cfe/trunk/include/clang/AST/BuiltinTypes.def Mon Apr 30 22:02:45 2018
> @@ -72,6 +72,9 @@ UNSIGNED_TYPE(UChar, UnsignedCharTy)
>  // 'wchar_t' for targets where it's unsigned
>  SHARED_SINGLETON_TYPE(UNSIGNED_TYPE(WChar_U, WCharTy))
>
> +// 'char8_t' in C++20 (proposed)
> +UNSIGNED_TYPE(Char8, Char8Ty)
> +
>  // 'char16_t' in C++
>  UNSIGNED_TYPE(Char16, Char16Ty)
>
>
> Modified: cfe/trunk/include/clang/AST/Type.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Type.h?rev=331244=331243=331244=diff
>
> ==
> --- cfe/trunk/include/clang/AST/Type.h (original)
> +++ cfe/trunk/include/clang/AST/Type.h Mon Apr 30 22:02:45 2018
> @@ -1777,6 +1777,7 @@ public:
>bool isBooleanType() const;
>bool isCharType() const;
>bool isWideCharType() 

r331245 - Fix up r331244 - the emitted definition is weak_odr linkage. Should get

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Mon Apr 30 23:48:30 2018
New Revision: 331245

URL: http://llvm.org/viewvc/llvm-project?rev=331245=rev
Log:
Fix up r331244 - the emitted definition is weak_odr linkage. Should get
the build bots to healthy again without a full revert. As the
functionality added has nothing to do with linkage this seems unlikely
to represent a deep or interesting bug in the patch.

Modified:
cfe/trunk/test/CodeGenCXX/char8_t.cpp

Modified: cfe/trunk/test/CodeGenCXX/char8_t.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/char8_t.cpp?rev=331245=331244=331245=diff
==
--- cfe/trunk/test/CodeGenCXX/char8_t.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/char8_t.cpp Mon Apr 30 23:48:30 2018
@@ -3,6 +3,6 @@
 // CHECK: define void @_Z1fDu(
 void f(char8_t c) {}
 
-// CHECK: define void @_Z1gIiEvDTplplcvT__ELA4_KDuELDu114EE
+// CHECK: define weak_odr void @_Z1gIiEvDTplplcvT__ELA4_KDuELDu114EE
 template void g(decltype(T() + u8"foo" + u8'r')) {}
 template void g(const char8_t*);


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

Re: r331056 - [docs] add -ffp-cast-overflow-workaround to the release notes

[Chandler Carruth via cfe-commits]

On Fri, Apr 27, 2018 at 5:13 PM Richard Smith <rich...@metafoo.co.uk> wrote:

> On 27 April 2018 at 17:09, Chandler Carruth via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> On Fri, Apr 27, 2018 at 4:36 PM Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> On 27 April 2018 at 16:07, Sanjay Patel via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
>>>> Missing dash corrected at r331057. I can improve the doc wording, but
>>>> let's settle on the flag name first, and I'll try to get it all fixed up in
>>>> one shot.
>>>>
>>>> So far we have these candidates:
>>>> 1. -ffp-cast-overflow-workaround
>>>> 2. -fstrict-fp-trunc-semantics
>>>> 3. -fstrict-fp-cast-overflow
>>>>
>>>> I don't have a strong opinion here, but on 2nd reading, it does seem
>>>> like a 'strict' flag fits better with existing options.
>>>>
>>>
>>> The corresponding UBSan check is called -fsanitize=float-cast-overflow,
>>> so maybe -fno-strict-float-cast-overflow would be the most consistent name?
>>>
>>
>> On this topic: we were hit by this on a *lot* of code. All of that code
>> builds and passes tests with -fsanitize=float-cast-overflow. So I think
>> we've been mistaken in assuming that this sanitizer catches all of the
>> failure modes of the optimization. That at least impacts the sanitizer
>> suggestion in the release notes. And probably impacts the flag name /
>> attribuet name.
>>
>
> That's interesting, and definitely sounds like a bug (either the sanitizer
> or LLVM is presumably getting the range check wrong). Can you point me at
> an example?
>

It appears that the code that hit this has cleverly dodged *EVERY* build
configuration we have deployed this sanitizer in... despite our best
efforts. Sorry for the noise.


>
>
>> On Fri, Apr 27, 2018 at 4:41 PM, Richard Smith <rich...@metafoo.co.uk>
>>>> wrote:
>>>>
>>>>> On 27 April 2018 at 09:21, Sanjay Patel via cfe-commits <
>>>>> cfe-commits@lists.llvm.org> wrote:
>>>>>
>>>>>> Author: spatel
>>>>>> Date: Fri Apr 27 09:21:22 2018
>>>>>> New Revision: 331056
>>>>>>
>>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=331056=rev
>>>>>> Log:
>>>>>> [docs] add -ffp-cast-overflow-workaround to the release notes
>>>>>>
>>>>>> This option was added with:
>>>>>> D46135
>>>>>> rL331041
>>>>>> ...copying the text from UsersManual.rst for more exposure.
>>>>>>
>>>>>>
>>>>>> Modified:
>>>>>> cfe/trunk/docs/ReleaseNotes.rst
>>>>>>
>>>>>> Modified: cfe/trunk/docs/ReleaseNotes.rst
>>>>>> URL:
>>>>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=331056=331055=331056=diff
>>>>>>
>>>>>> ==
>>>>>> --- cfe/trunk/docs/ReleaseNotes.rst (original)
>>>>>> +++ cfe/trunk/docs/ReleaseNotes.rst Fri Apr 27 09:21:22 2018
>>>>>> @@ -83,6 +83,15 @@ Non-comprehensive list of changes in thi
>>>>>>  New Compiler Flags
>>>>>>  --
>>>>>>
>>>>>> +- :option:`-ffp-cast-overflow-workaround` and
>>>>>> +  :option:`-fnofp-cast-overflow-workaround`
>>>>>>
>>>>>
>>>>> Shouldn't this be -fno-fp-cast-overflow-workaround?
>>>>>
>>>>> Also, our convention for flags that define undefined behavior is
>>>>> `-fno-strict-*`, so perhaps this should be `-fno-strict-fp-cast-overflow`?
>>>>>
>>>>>
>>>>>> +  enable (disable) a workaround for code that casts floating-point
>>>>>> values to
>>>>>> +  integers and back to floating-point. If the floating-point value
>>>>>> is not
>>>>>> +  representable in the intermediate integer type, the code is
>>>>>> incorrect
>>>>>> +  according to the language standard.
>>>>>
>>>>>
>>>>> I find this hard to read: I initially misread "the code is incorrect
>>>>> according to the language standa

Re: r331056 - [docs] add -ffp-cast-overflow-workaround to the release notes

[Chandler Carruth via cfe-commits]

On Fri, Apr 27, 2018 at 4:36 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On 27 April 2018 at 16:07, Sanjay Patel via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Missing dash corrected at r331057. I can improve the doc wording, but
>> let's settle on the flag name first, and I'll try to get it all fixed up in
>> one shot.
>>
>> So far we have these candidates:
>> 1. -ffp-cast-overflow-workaround
>> 2. -fstrict-fp-trunc-semantics
>> 3. -fstrict-fp-cast-overflow
>>
>> I don't have a strong opinion here, but on 2nd reading, it does seem like
>> a 'strict' flag fits better with existing options.
>>
>
> The corresponding UBSan check is called -fsanitize=float-cast-overflow, so
> maybe -fno-strict-float-cast-overflow would be the most consistent name?
>

On this topic: we were hit by this on a *lot* of code. All of that code
builds and passes tests with -fsanitize=float-cast-overflow. So I think
we've been mistaken in assuming that this sanitizer catches all of the
failure modes of the optimization. That at least impacts the sanitizer
suggestion in the release notes. And probably impacts the flag name /
attribuet name.


>
>
>> On Fri, Apr 27, 2018 at 4:41 PM, Richard Smith 
>> wrote:
>>
>>> On 27 April 2018 at 09:21, Sanjay Patel via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: spatel
 Date: Fri Apr 27 09:21:22 2018
 New Revision: 331056

 URL: http://llvm.org/viewvc/llvm-project?rev=331056=rev
 Log:
 [docs] add -ffp-cast-overflow-workaround to the release notes

 This option was added with:
 D46135
 rL331041
 ...copying the text from UsersManual.rst for more exposure.


 Modified:
 cfe/trunk/docs/ReleaseNotes.rst

 Modified: cfe/trunk/docs/ReleaseNotes.rst
 URL:
 http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=331056=331055=331056=diff

 ==
 --- cfe/trunk/docs/ReleaseNotes.rst (original)
 +++ cfe/trunk/docs/ReleaseNotes.rst Fri Apr 27 09:21:22 2018
 @@ -83,6 +83,15 @@ Non-comprehensive list of changes in thi
  New Compiler Flags
  --

 +- :option:`-ffp-cast-overflow-workaround` and
 +  :option:`-fnofp-cast-overflow-workaround`

>>>
>>> Shouldn't this be -fno-fp-cast-overflow-workaround?
>>>
>>> Also, our convention for flags that define undefined behavior is
>>> `-fno-strict-*`, so perhaps this should be `-fno-strict-fp-cast-overflow`?
>>>
>>>
 +  enable (disable) a workaround for code that casts floating-point
 values to
 +  integers and back to floating-point. If the floating-point value is
 not
 +  representable in the intermediate integer type, the code is incorrect
 +  according to the language standard.
>>>
>>>
>>> I find this hard to read: I initially misread "the code is incorrect
>>> according to the language standard" as meaning "Clang will generate code
>>> that is incorrect according to the language standard". I think what you
>>> mean here is "the code has undefined behavior according to the language
>>> standard, and Clang will not guarantee any particular result. This flag
>>> causes the behavior to be defined to match the overflowing behavior of the
>>> target's native float-to-int conversion instructions."
>>>
>>>
 This flag will attempt to generate code
 +  as if the result of an overflowing conversion matches the
 overflowing behavior
 +  of a target's native float-to-int conversion instructions.
 +
  - ...

  Deprecated Compiler Flags


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

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

r330997 - [x86] Revert r330322 (& r330323): Lowering x86 adds/addus/subs/subus intrinsics

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Thu Apr 26 14:46:01 2018
New Revision: 330997

URL: http://llvm.org/viewvc/llvm-project?rev=330997=rev
Log:
[x86] Revert r330322 (& r330323): Lowering x86 adds/addus/subs/subus intrinsics

The LLVM commit introduces a crash in LLVM's instruction selection.

I filed http://llvm.org/PR37260 with the test case.

Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/test/CodeGen/avx2-builtins.c
cfe/trunk/test/CodeGen/avx512bw-builtins.c
cfe/trunk/test/CodeGen/avx512vlbw-builtins.c
cfe/trunk/test/CodeGen/sse2-builtins.c

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=330997=330996=330997=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Thu Apr 26 14:46:01 2018
@@ -8449,76 +8449,6 @@ static Value *EmitX86SExtMask(CodeGenFun
   return CGF.Builder.CreateSExt(Mask, DstTy, "vpmovm2");
 }
 
-// Emit addition or subtraction with saturation.
-// Handles both signed and unsigned intrinsics.
-static Value *EmitX86AddSubSatExpr(CodeGenFunction , const CallExpr *E,
-   SmallVectorImpl ,
-   bool IsAddition, bool Signed) {
-
-  // Collect vector elements and type data.
-  llvm::Type *ResultType = CGF.ConvertType(E->getType());
-  int NumElements = ResultType->getVectorNumElements();
-  Value *Res;
-  if (!IsAddition && !Signed) {
-Value *ICmp = CGF.Builder.CreateICmp(ICmpInst::ICMP_UGT, Ops[0], Ops[1]);
-Value *Select = CGF.Builder.CreateSelect(ICmp, Ops[0], Ops[1]);
-Res = CGF.Builder.CreateSub(Select, Ops[1]);
-  } else {
-unsigned EltSizeInBits = ResultType->getScalarSizeInBits();
-llvm::Type *ExtElementType = EltSizeInBits == 8 ?
- CGF.Builder.getInt16Ty() :
- CGF.Builder.getInt32Ty();
-
-// Extending vectors to next possible width to make space for possible
-// overflow.
-llvm::Type *ExtType = llvm::VectorType::get(ExtElementType, NumElements);
-Value *VecA = Signed ? CGF.Builder.CreateSExt(Ops[0], ExtType)
- : CGF.Builder.CreateZExt(Ops[0], ExtType);
-Value *VecB = Signed ? CGF.Builder.CreateSExt(Ops[1], ExtType)
- : CGF.Builder.CreateZExt(Ops[1], ExtType);
-
-llvm::Value *ExtProduct = IsAddition ? CGF.Builder.CreateAdd(VecA, VecB)
- : CGF.Builder.CreateSub(VecA, VecB);
-
-// Create vector of the same type as expected result with max possible
-// values and extend it to the same type as the product of the addition.
-APInt SignedMaxValue =
-llvm::APInt::getSignedMaxValue(EltSizeInBits);
-Value *Max = Signed ? llvm::ConstantInt::get(ResultType, SignedMaxValue)
-: llvm::Constant::getAllOnesValue(ResultType);
-Value *ExtMaxVec = Signed ? CGF.Builder.CreateSExt(Max, ExtType)
-  : CGF.Builder.CreateZExt(Max, ExtType);
-// In Product, replace all overflowed values with max values of 
non-extended
-// type.
-ICmpInst::Predicate Pred = Signed ? ICmpInst::ICMP_SLE : 
ICmpInst::ICMP_ULE;
-Value *Cmp = CGF.Builder.CreateICmp(Pred, ExtProduct,
-ExtMaxVec); // 1 if no overflow.
-Value *SaturatedProduct = CGF.Builder.CreateSelect(
-Cmp, ExtProduct, ExtMaxVec); // If overflowed, copy from max values.
-
-if (Signed) {
-  APInt SignedMinValue =
-  llvm::APInt::getSignedMinValue(EltSizeInBits);
-  Value *Min = llvm::ConstantInt::get(ResultType, SignedMinValue);
-  Value *ExtMinVec = CGF.Builder.CreateSExt(Min, ExtType);
-  Value *IsNegative =
-CGF.Builder.CreateICmp(ICmpInst::ICMP_SLT, SaturatedProduct, 
ExtMinVec);
-  SaturatedProduct =
-CGF.Builder.CreateSelect(IsNegative, ExtMinVec, SaturatedProduct);
-}
-
-Res = CGF.Builder.CreateTrunc(SaturatedProduct,
-  ResultType); // Trunc to ResultType.
-  }
-  if (E->getNumArgs() == 4) { // For masked intrinsics.
-Value *VecSRC = Ops[2];
-Value *Mask = Ops[3];
-return EmitX86Select(CGF, Mask, Res, VecSRC);
-  }
-
-  return Res;
-}
-
 Value *CodeGenFunction::EmitX86CpuIs(const CallExpr *E) {
   const Expr *CPUExpr = E->getArg(0)->IgnoreParenCasts();
   StringRef CPUStr = cast(CPUExpr)->getString();
@@ -9586,37 +9516,10 @@ Value *CodeGenFunction::EmitX86BuiltinEx
 Load->setVolatile(true);
 return Load;
   }
-  case X86::BI__builtin_ia32_paddusb512_mask:
-  case X86::BI__builtin_ia32_paddusw512_mask:
-  case X86::BI__builtin_ia32_paddusb256:
-  case X86::BI__builtin_ia32_paddusw256:
-  case X86::BI__builtin_ia32_paddusb128:
-  case X86::BI__builtin_ia32_paddusw128:
-return EmitX86AddSubSatExpr(*this, E, Ops, true, false); // Add, 

Re: [clang-tools-extra] r330559 - update test to use ivar in implementation instead of class extension

[Chandler Carruth via cfe-commits]

I won't be back at a computer for a while and I really don't know anything
about objective-c... But if you don't feel confident submitting fixes with
post commit review, you should probably just revert If the fix is
trivial and/or you can find ways to test it a similar suggested in my
earlier email, then I'd suggest landing it and watching the build bots to
ensure they are happy. But if you can't figure out how to restore the bots
you'll end up needing to revert the whole series and get some help from
someone with access to another platform.

On Sun, Apr 22, 2018, 18:03 Yan Zhang via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Need a accept for that revision. Can you accept it?
>
> On Sun, Apr 22, 2018 at 6:02 PM Chandler Carruth 
> wrote:
>
>> See my other email -- you can compile code targeting other platforms
>> regardless of the platform you develop on. Not exactly as good as
>> reproducing it with a bot, but about the best you have.
>>
>> On Sun, Apr 22, 2018 at 6:01 PM Chandler Carruth 
>> wrote:
>>
>>> I don't know anything about objective-c, or anything about OSX.
>>>
>>> However, I guarantee these bots aren't using 32-bit OSX. ;] Look at the
>>> bot names. They're running Linux in various flavors: ppc64be, ppc64le,
>>> armv8, etc.
>>>
>>> My suspicion is that this is a linux-specific issue.
>>>
>>> But you can reproduce this yourself. Just run clang (or clang-tidy) over
>>> this test file with --target= for various linux triples. It doesn't
>>> include any headers or anything else, so you should be able to see all
>>> these failures.
>>>
>>> Anyways, please land that revision or revert until you have a reviewer
>>> for it (many maybe not around this weekend). But please don't leave the
>>> bots broken.
>>>
>>> On Sun, Apr 22, 2018 at 5:55 PM Yan Zhang  wrote:
>>>
 I am running tests locally with "ninja check-clang-tools" and I am
 sure it is running this test because I could get error message when I debug
 it.

 The problem (according to the error message) is all caused by different
 architecture. It seems a lot of ObjC features are not supported in old
 32-bit OSX (which I believe the test bots are using). I have another
 revision sent out to see if it can help. Can you take a quick look?
 https://reviews.llvm.org/D45936

 On Sun, Apr 22, 2018 at 5:51 PM Chandler Carruth 
 wrote:

> The commit log here no longer reflects the commit. This is not just
> updating the test, this is a complete re-application of the original patch
> in r330492. =[
>
> Also, the bots are still complaining:
> http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/17830
> http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/1979
> http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/11659
>
> I'm not sure how you're running your tests that you don't see these
> issues, but they seem to reproduce on many build bots and the error 
> message
> doesn't seem to be architecture specific at all...
>
> I suspect something about how you are trying to run tests isn't
> actually running this test if you aren't able to locally reproduce.
>
> On Sun, Apr 22, 2018 at 5:19 PM Yan Zhang via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: wizard
>> Date: Sun Apr 22 17:15:15 2018
>> New Revision: 330559
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=330559=rev
>> Log:
>> update test to use ivar in implementation instead of class extension
>>
>> Summary: using ivar in class extension is not supported in 32-bit
>> architecture of MacOS.
>>
>> Reviewers: alexfh, hokein
>>
>> Reviewed By: alexfh
>>
>> Subscribers: klimek, cfe-commits
>>
>> Differential Revision: https://reviews.llvm.org/D45912
>>
>> Added:
>>
>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>> Modified:
>>
>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>
>> Modified:
>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp?rev=330559=330558=330559=diff
>>
>> ==
>> ---
>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>> (original)
>> +++
>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>> Sun Apr 22 17:15:15 2018
>> @@ -109,6 +109,7 @@ namespace readability {
>>  m(TemplateParameter) \
>>  m(TypeAlias) \
>>  m(MacroDefinition) \
>> +m(ObjcIvar) \
>>
>>  enum StyleKind {
>>  #define 

Re: [clang-tools-extra] r330559 - update test to use ivar in implementation instead of class extension

[Chandler Carruth via cfe-commits]

See my other email -- you can compile code targeting other platforms
regardless of the platform you develop on. Not exactly as good as
reproducing it with a bot, but about the best you have.

On Sun, Apr 22, 2018 at 6:01 PM Chandler Carruth 
wrote:

> I don't know anything about objective-c, or anything about OSX.
>
> However, I guarantee these bots aren't using 32-bit OSX. ;] Look at the
> bot names. They're running Linux in various flavors: ppc64be, ppc64le,
> armv8, etc.
>
> My suspicion is that this is a linux-specific issue.
>
> But you can reproduce this yourself. Just run clang (or clang-tidy) over
> this test file with --target= for various linux triples. It doesn't
> include any headers or anything else, so you should be able to see all
> these failures.
>
> Anyways, please land that revision or revert until you have a reviewer for
> it (many maybe not around this weekend). But please don't leave the bots
> broken.
>
> On Sun, Apr 22, 2018 at 5:55 PM Yan Zhang  wrote:
>
>> I am running tests locally with "ninja check-clang-tools" and I am sure
>> it is running this test because I could get error message when I debug it.
>>
>> The problem (according to the error message) is all caused by different
>> architecture. It seems a lot of ObjC features are not supported in old
>> 32-bit OSX (which I believe the test bots are using). I have another
>> revision sent out to see if it can help. Can you take a quick look?
>> https://reviews.llvm.org/D45936
>>
>> On Sun, Apr 22, 2018 at 5:51 PM Chandler Carruth 
>> wrote:
>>
>>> The commit log here no longer reflects the commit. This is not just
>>> updating the test, this is a complete re-application of the original patch
>>> in r330492. =[
>>>
>>> Also, the bots are still complaining:
>>> http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/17830
>>> http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/1979
>>> http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/11659
>>>
>>> I'm not sure how you're running your tests that you don't see these
>>> issues, but they seem to reproduce on many build bots and the error message
>>> doesn't seem to be architecture specific at all...
>>>
>>> I suspect something about how you are trying to run tests isn't actually
>>> running this test if you aren't able to locally reproduce.
>>>
>>> On Sun, Apr 22, 2018 at 5:19 PM Yan Zhang via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: wizard
 Date: Sun Apr 22 17:15:15 2018
 New Revision: 330559

 URL: http://llvm.org/viewvc/llvm-project?rev=330559=rev
 Log:
 update test to use ivar in implementation instead of class extension

 Summary: using ivar in class extension is not supported in 32-bit
 architecture of MacOS.

 Reviewers: alexfh, hokein

 Reviewed By: alexfh

 Subscribers: klimek, cfe-commits

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

 Added:

 clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
 Modified:

 clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp

 Modified:
 clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
 URL:
 http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp?rev=330559=330558=330559=diff

 ==
 ---
 clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
 (original)
 +++
 clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
 Sun Apr 22 17:15:15 2018
 @@ -109,6 +109,7 @@ namespace readability {
  m(TemplateParameter) \
  m(TypeAlias) \
  m(MacroDefinition) \
 +m(ObjcIvar) \

  enum StyleKind {
  #define ENUMERATE(v) SK_ ## v,
 @@ -384,6 +385,9 @@ static StyleKind findStyleKind(
  const NamedDecl *D,
  const
 std::vector
  ) {
 +  if (isa(D) && NamingStyles[SK_ObjcIvar])
 +return SK_ObjcIvar;
 +
if (isa(D) && NamingStyles[SK_Typedef])
  return SK_Typedef;


 Added:
 clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
 URL:
 http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m?rev=330559=auto

 ==
 ---
 clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
 (added)
 +++
 clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
 Sun Apr 22 17:15:15 2018
 @@ -0,0 +1,15 @@
 +// RUN: %check_clang_tidy %s readability-identifier-naming %t \
 +// RUN: 

Re: [clang-tools-extra] r330559 - update test to use ivar in implementation instead of class extension

[Chandler Carruth via cfe-commits]

I don't know anything about objective-c, or anything about OSX.

However, I guarantee these bots aren't using 32-bit OSX. ;] Look at the bot
names. They're running Linux in various flavors: ppc64be, ppc64le, armv8,
etc.

My suspicion is that this is a linux-specific issue.

But you can reproduce this yourself. Just run clang (or clang-tidy) over
this test file with --target= for various linux triples. It doesn't
include any headers or anything else, so you should be able to see all
these failures.

Anyways, please land that revision or revert until you have a reviewer for
it (many maybe not around this weekend). But please don't leave the bots
broken.

On Sun, Apr 22, 2018 at 5:55 PM Yan Zhang  wrote:

> I am running tests locally with "ninja check-clang-tools" and I am sure
> it is running this test because I could get error message when I debug it.
>
> The problem (according to the error message) is all caused by different
> architecture. It seems a lot of ObjC features are not supported in old
> 32-bit OSX (which I believe the test bots are using). I have another
> revision sent out to see if it can help. Can you take a quick look?
> https://reviews.llvm.org/D45936
>
> On Sun, Apr 22, 2018 at 5:51 PM Chandler Carruth 
> wrote:
>
>> The commit log here no longer reflects the commit. This is not just
>> updating the test, this is a complete re-application of the original patch
>> in r330492. =[
>>
>> Also, the bots are still complaining:
>> http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/17830
>> http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/1979
>> http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/11659
>>
>> I'm not sure how you're running your tests that you don't see these
>> issues, but they seem to reproduce on many build bots and the error message
>> doesn't seem to be architecture specific at all...
>>
>> I suspect something about how you are trying to run tests isn't actually
>> running this test if you aren't able to locally reproduce.
>>
>> On Sun, Apr 22, 2018 at 5:19 PM Yan Zhang via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: wizard
>>> Date: Sun Apr 22 17:15:15 2018
>>> New Revision: 330559
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=330559=rev
>>> Log:
>>> update test to use ivar in implementation instead of class extension
>>>
>>> Summary: using ivar in class extension is not supported in 32-bit
>>> architecture of MacOS.
>>>
>>> Reviewers: alexfh, hokein
>>>
>>> Reviewed By: alexfh
>>>
>>> Subscribers: klimek, cfe-commits
>>>
>>> Differential Revision: https://reviews.llvm.org/D45912
>>>
>>> Added:
>>>
>>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>>> Modified:
>>>
>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>>
>>> Modified:
>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp?rev=330559=330558=330559=diff
>>>
>>> ==
>>> ---
>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>> (original)
>>> +++
>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>> Sun Apr 22 17:15:15 2018
>>> @@ -109,6 +109,7 @@ namespace readability {
>>>  m(TemplateParameter) \
>>>  m(TypeAlias) \
>>>  m(MacroDefinition) \
>>> +m(ObjcIvar) \
>>>
>>>  enum StyleKind {
>>>  #define ENUMERATE(v) SK_ ## v,
>>> @@ -384,6 +385,9 @@ static StyleKind findStyleKind(
>>>  const NamedDecl *D,
>>>  const
>>> std::vector
>>>  ) {
>>> +  if (isa(D) && NamingStyles[SK_ObjcIvar])
>>> +return SK_ObjcIvar;
>>> +
>>>if (isa(D) && NamingStyles[SK_Typedef])
>>>  return SK_Typedef;
>>>
>>>
>>> Added:
>>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m?rev=330559=auto
>>>
>>> ==
>>> ---
>>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>>> (added)
>>> +++
>>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>>> Sun Apr 22 17:15:15 2018
>>> @@ -0,0 +1,15 @@
>>> +// RUN: %check_clang_tidy %s readability-identifier-naming %t \
>>> +// RUN: -config='{CheckOptions: \
>>> +// RUN:  [{key: readability-identifier-naming.ObjcIvarPrefix, value:
>>> '_'}]}' \
>>> +// RUN: --
>>> +
>>> +@interface Foo
>>> +@end
>>> +
>>> +@implementation Foo {
>>> +int _bar;
>>> +int barWithoutPrefix;
>>> +// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: invalid case style for
>>> objc ivar 'barWithoutPrefix' [readability-identifier-naming]
>>> +// 

Re: [clang-tools-extra] r330559 - update test to use ivar in implementation instead of class extension

[Chandler Carruth via cfe-commits]

The commit log here no longer reflects the commit. This is not just
updating the test, this is a complete re-application of the original patch
in r330492. =[

Also, the bots are still complaining:
http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/17830
http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/1979
http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/11659

I'm not sure how you're running your tests that you don't see these issues,
but they seem to reproduce on many build bots and the error message doesn't
seem to be architecture specific at all...

I suspect something about how you are trying to run tests isn't actually
running this test if you aren't able to locally reproduce.

On Sun, Apr 22, 2018 at 5:19 PM Yan Zhang via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: wizard
> Date: Sun Apr 22 17:15:15 2018
> New Revision: 330559
>
> URL: http://llvm.org/viewvc/llvm-project?rev=330559=rev
> Log:
> update test to use ivar in implementation instead of class extension
>
> Summary: using ivar in class extension is not supported in 32-bit
> architecture of MacOS.
>
> Reviewers: alexfh, hokein
>
> Reviewed By: alexfh
>
> Subscribers: klimek, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D45912
>
> Added:
>
> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
> Modified:
>
> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>
> Modified:
> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp?rev=330559=330558=330559=diff
>
> ==
> ---
> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
> (original)
> +++
> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
> Sun Apr 22 17:15:15 2018
> @@ -109,6 +109,7 @@ namespace readability {
>  m(TemplateParameter) \
>  m(TypeAlias) \
>  m(MacroDefinition) \
> +m(ObjcIvar) \
>
>  enum StyleKind {
>  #define ENUMERATE(v) SK_ ## v,
> @@ -384,6 +385,9 @@ static StyleKind findStyleKind(
>  const NamedDecl *D,
>  const std::vector
>  ) {
> +  if (isa(D) && NamingStyles[SK_ObjcIvar])
> +return SK_ObjcIvar;
> +
>if (isa(D) && NamingStyles[SK_Typedef])
>  return SK_Typedef;
>
>
> Added:
> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m?rev=330559=auto
>
> ==
> ---
> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
> (added)
> +++
> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
> Sun Apr 22 17:15:15 2018
> @@ -0,0 +1,15 @@
> +// RUN: %check_clang_tidy %s readability-identifier-naming %t \
> +// RUN: -config='{CheckOptions: \
> +// RUN:  [{key: readability-identifier-naming.ObjcIvarPrefix, value:
> '_'}]}' \
> +// RUN: --
> +
> +@interface Foo
> +@end
> +
> +@implementation Foo {
> +int _bar;
> +int barWithoutPrefix;
> +// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: invalid case style for
> objc ivar 'barWithoutPrefix' [readability-identifier-naming]
> +// CHECK-FIXES: int _barWithoutPrefix;
> +}
> +@end
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang-tools-extra] r330492 - [clang-tidy] add new check to find out objc ivars which do not have prefix '_'

[Chandler Carruth via cfe-commits]

Should be able to reproduce it by patching it in and running the tests
yourself? Nothing configuration specific here. Still, no hurry.

On Sat, Apr 21, 2018 at 6:02 PM Yan Zhang via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Sorry I was out today. What is the new error? Can u send it to me?
>
> Best regards
> Yan Zhang
>
> On Apr 21, 2018, at 16:32, Chandler Carruth  wrote:
>
> Ok, this still isn't fixed a day later and over half our build bots are
> red because of it. =/ I tried just applying the patch, and it doesn't seem
> to fully fix the test as it results in a different error...
>
> I've reverted in r330528 for now so that our bots are green. =] Feel free
> to re-land once you've confirmed the tests are passing, and keep an eye on
> the bots after it goes in. =D
>
> On Fri, Apr 20, 2018 at 11:33 PM Chandler Carruth 
> wrote:
>
>> I see Alex already got it, but in the future, that kind of trivial test
>> fix for a failing test is fine to just land, and it is more important to
>> get the bots healthy. =]
>>
>> On Fri, Apr 20, 2018, 22:14 Yan Zhang via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> https://reviews.llvm.org/D45912 need someone to accept
>>>
>>> Best regards
>>> Yan Zhang
>>>
>>> On Apr 20, 2018, at 19:08, Chandler Carruth  wrote:
>>>
>>> This has broken most of the build bots. Are you working on a fix or
>>> revert?
>>>
>>> Might be useful to get on the IRC channel to help coordinate this kind
>>> of thing.
>>>
>>> On Fri, Apr 20, 2018 at 4:45 PM Yan Zhang via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
 Author: wizard
 Date: Fri Apr 20 16:18:09 2018
 New Revision: 330492

 URL: http://llvm.org/viewvc/llvm-project?rev=330492=rev
 Log:
 [clang-tidy] add new check to find out objc ivars which do not have
 prefix '_'

 Summary:
 For code of ivar declaration:

int barWithoutPrefix;

 The fix will be:

int _barWithoutPrefix;

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

 Reviewed By: alexfh

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

 Tags: #clang-tools-extra

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

 Added:

 clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
 Modified:

 clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp

 Modified:
 clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
 URL:
 http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp?rev=330492=330491=330492=diff

 ==
 ---
 clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
 (original)
 +++
 clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
 Fri Apr 20 16:18:09 2018
 @@ -109,6 +109,7 @@ namespace readability {
  m(TemplateParameter) \
  m(TypeAlias) \
  m(MacroDefinition) \
 +m(ObjcIvar) \

  enum StyleKind {
  #define ENUMERATE(v) SK_ ## v,
 @@ -384,6 +385,9 @@ static StyleKind findStyleKind(
  const NamedDecl *D,
  const
 std::vector
  ) {
 +  if (isa(D) && NamingStyles[SK_ObjcIvar])
 +return SK_ObjcIvar;
 +
if (isa(D) && NamingStyles[SK_Typedef])
  return SK_Typedef;


 Added:
 clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
 URL:
 http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m?rev=330492=auto

 ==
 ---
 clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
 (added)
 +++
 clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
 Fri Apr 20 16:18:09 2018
 @@ -0,0 +1,15 @@
 +// RUN: %check_clang_tidy %s readability-identifier-naming %t \
 +// RUN: -config='{CheckOptions: \
 +// RUN:  [{key: readability-identifier-naming.ObjcIvarPrefix, value:
 '_'}]}' \
 +// RUN: --
 +
 +@interface Foo
 +@end
 +
 +@interface Foo () {
 +int _bar;
 +int barWithoutPrefix;
 +// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: invalid case style for
 objc ivar 'barWithoutPrefix' [readability-identifier-naming]
 +// CHECK-FIXES: int _barWithoutPrefix;
 +}
 +@end


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

>>> 

Re: [clang-tools-extra] r330492 - [clang-tidy] add new check to find out objc ivars which do not have prefix '_'

[Chandler Carruth via cfe-commits]

Ok, this still isn't fixed a day later and over half our build bots are red
because of it. =/ I tried just applying the patch, and it doesn't seem to
fully fix the test as it results in a different error...

I've reverted in r330528 for now so that our bots are green. =] Feel free
to re-land once you've confirmed the tests are passing, and keep an eye on
the bots after it goes in. =D

On Fri, Apr 20, 2018 at 11:33 PM Chandler Carruth 
wrote:

> I see Alex already got it, but in the future, that kind of trivial test
> fix for a failing test is fine to just land, and it is more important to
> get the bots healthy. =]
>
> On Fri, Apr 20, 2018, 22:14 Yan Zhang via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> https://reviews.llvm.org/D45912 need someone to accept
>>
>> Best regards
>> Yan Zhang
>>
>> On Apr 20, 2018, at 19:08, Chandler Carruth  wrote:
>>
>> This has broken most of the build bots. Are you working on a fix or
>> revert?
>>
>> Might be useful to get on the IRC channel to help coordinate this kind of
>> thing.
>>
>> On Fri, Apr 20, 2018 at 4:45 PM Yan Zhang via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: wizard
>>> Date: Fri Apr 20 16:18:09 2018
>>> New Revision: 330492
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=330492=rev
>>> Log:
>>> [clang-tidy] add new check to find out objc ivars which do not have
>>> prefix '_'
>>>
>>> Summary:
>>> For code of ivar declaration:
>>>
>>>int barWithoutPrefix;
>>>
>>> The fix will be:
>>>
>>>int _barWithoutPrefix;
>>>
>>> Reviewers: benhamilton, hokein, alexfh, aaron.ballman, ilya-biryukov
>>>
>>> Reviewed By: alexfh
>>>
>>> Subscribers: Eugene.Zelenko, xazax.hun, klimek, mgorny, cfe-commits
>>>
>>> Tags: #clang-tools-extra
>>>
>>> Differential Revision: https://reviews.llvm.org/D45392
>>>
>>> Added:
>>>
>>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>>> Modified:
>>>
>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>>
>>> Modified:
>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp?rev=330492=330491=330492=diff
>>>
>>> ==
>>> ---
>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>> (original)
>>> +++
>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>> Fri Apr 20 16:18:09 2018
>>> @@ -109,6 +109,7 @@ namespace readability {
>>>  m(TemplateParameter) \
>>>  m(TypeAlias) \
>>>  m(MacroDefinition) \
>>> +m(ObjcIvar) \
>>>
>>>  enum StyleKind {
>>>  #define ENUMERATE(v) SK_ ## v,
>>> @@ -384,6 +385,9 @@ static StyleKind findStyleKind(
>>>  const NamedDecl *D,
>>>  const
>>> std::vector
>>>  ) {
>>> +  if (isa(D) && NamingStyles[SK_ObjcIvar])
>>> +return SK_ObjcIvar;
>>> +
>>>if (isa(D) && NamingStyles[SK_Typedef])
>>>  return SK_Typedef;
>>>
>>>
>>> Added:
>>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m?rev=330492=auto
>>>
>>> ==
>>> ---
>>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>>> (added)
>>> +++
>>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>>> Fri Apr 20 16:18:09 2018
>>> @@ -0,0 +1,15 @@
>>> +// RUN: %check_clang_tidy %s readability-identifier-naming %t \
>>> +// RUN: -config='{CheckOptions: \
>>> +// RUN:  [{key: readability-identifier-naming.ObjcIvarPrefix, value:
>>> '_'}]}' \
>>> +// RUN: --
>>> +
>>> +@interface Foo
>>> +@end
>>> +
>>> +@interface Foo () {
>>> +int _bar;
>>> +int barWithoutPrefix;
>>> +// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: invalid case style for
>>> objc ivar 'barWithoutPrefix' [readability-identifier-naming]
>>> +// CHECK-FIXES: int _barWithoutPrefix;
>>> +}
>>> +@end
>>>
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r330528 - Revert r330492: [clang-tidy] add new check to find out objc ivars which do not have prefix '_'

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Sat Apr 21 16:27:34 2018
New Revision: 330528

URL: http://llvm.org/viewvc/llvm-project?rev=330528=rev
Log:
Revert r330492: [clang-tidy] add new check to find out objc ivars which do not 
have prefix '_'

This commit has been breaking most bots for a day now. There is a fix
proposed in https://reviews.llvm.org/D45912 but when I applied that
I just got different errors. Reverting to get our bots back to green.

Removed:
clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
Modified:
clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp

Modified: 
clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp?rev=330528=330527=330528=diff
==
--- clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp 
Sat Apr 21 16:27:34 2018
@@ -109,7 +109,6 @@ namespace readability {
 m(TemplateParameter) \
 m(TypeAlias) \
 m(MacroDefinition) \
-m(ObjcIvar) \
 
 enum StyleKind {
 #define ENUMERATE(v) SK_ ## v,
@@ -385,9 +384,6 @@ static StyleKind findStyleKind(
 const NamedDecl *D,
 const std::vector
 ) {
-  if (isa(D) && NamingStyles[SK_ObjcIvar])
-return SK_ObjcIvar;
-
   if (isa(D) && NamingStyles[SK_Typedef])
 return SK_Typedef;
 

Removed: 
clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m?rev=330527=auto
==
--- 
clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m 
(original)
+++ 
clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m 
(removed)
@@ -1,15 +0,0 @@
-// RUN: %check_clang_tidy %s readability-identifier-naming %t \
-// RUN: -config='{CheckOptions: \
-// RUN:  [{key: readability-identifier-naming.ObjcIvarPrefix, value: '_'}]}' \
-// RUN: --
-
-@interface Foo
-@end 
-
-@interface Foo () {
-int _bar;
-int barWithoutPrefix;
-// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: invalid case style for objc 
ivar 'barWithoutPrefix' [readability-identifier-naming]
-// CHECK-FIXES: int _barWithoutPrefix;
-}
-@end


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

Re: [clang-tools-extra] r330492 - [clang-tidy] add new check to find out objc ivars which do not have prefix '_'

[Chandler Carruth via cfe-commits]

I see Alex already got it, but in the future, that kind of trivial test fix
for a failing test is fine to just land, and it is more important to get
the bots healthy. =]

On Fri, Apr 20, 2018, 22:14 Yan Zhang via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> https://reviews.llvm.org/D45912 need someone to accept
>
> Best regards
> Yan Zhang
>
> On Apr 20, 2018, at 19:08, Chandler Carruth  wrote:
>
> This has broken most of the build bots. Are you working on a fix or revert?
>
> Might be useful to get on the IRC channel to help coordinate this kind of
> thing.
>
> On Fri, Apr 20, 2018 at 4:45 PM Yan Zhang via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: wizard
>> Date: Fri Apr 20 16:18:09 2018
>> New Revision: 330492
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=330492=rev
>> Log:
>> [clang-tidy] add new check to find out objc ivars which do not have
>> prefix '_'
>>
>> Summary:
>> For code of ivar declaration:
>>
>>int barWithoutPrefix;
>>
>> The fix will be:
>>
>>int _barWithoutPrefix;
>>
>> Reviewers: benhamilton, hokein, alexfh, aaron.ballman, ilya-biryukov
>>
>> Reviewed By: alexfh
>>
>> Subscribers: Eugene.Zelenko, xazax.hun, klimek, mgorny, cfe-commits
>>
>> Tags: #clang-tools-extra
>>
>> Differential Revision: https://reviews.llvm.org/D45392
>>
>> Added:
>>
>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>> Modified:
>>
>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>
>> Modified:
>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp?rev=330492=330491=330492=diff
>>
>> ==
>> ---
>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>> (original)
>> +++
>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>> Fri Apr 20 16:18:09 2018
>> @@ -109,6 +109,7 @@ namespace readability {
>>  m(TemplateParameter) \
>>  m(TypeAlias) \
>>  m(MacroDefinition) \
>> +m(ObjcIvar) \
>>
>>  enum StyleKind {
>>  #define ENUMERATE(v) SK_ ## v,
>> @@ -384,6 +385,9 @@ static StyleKind findStyleKind(
>>  const NamedDecl *D,
>>  const std::vector
>>  ) {
>> +  if (isa(D) && NamingStyles[SK_ObjcIvar])
>> +return SK_ObjcIvar;
>> +
>>if (isa(D) && NamingStyles[SK_Typedef])
>>  return SK_Typedef;
>>
>>
>> Added:
>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m?rev=330492=auto
>>
>> ==
>> ---
>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>> (added)
>> +++
>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>> Fri Apr 20 16:18:09 2018
>> @@ -0,0 +1,15 @@
>> +// RUN: %check_clang_tidy %s readability-identifier-naming %t \
>> +// RUN: -config='{CheckOptions: \
>> +// RUN:  [{key: readability-identifier-naming.ObjcIvarPrefix, value:
>> '_'}]}' \
>> +// RUN: --
>> +
>> +@interface Foo
>> +@end
>> +
>> +@interface Foo () {
>> +int _bar;
>> +int barWithoutPrefix;
>> +// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: invalid case style for
>> objc ivar 'barWithoutPrefix' [readability-identifier-naming]
>> +// CHECK-FIXES: int _barWithoutPrefix;
>> +}
>> +@end
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [clang-tools-extra] r330492 - [clang-tidy] add new check to find out objc ivars which do not have prefix '_'

[Chandler Carruth via cfe-commits]

This has broken most of the build bots. Are you working on a fix or revert?

Might be useful to get on the IRC channel to help coordinate this kind of
thing.

On Fri, Apr 20, 2018 at 4:45 PM Yan Zhang via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: wizard
> Date: Fri Apr 20 16:18:09 2018
> New Revision: 330492
>
> URL: http://llvm.org/viewvc/llvm-project?rev=330492=rev
> Log:
> [clang-tidy] add new check to find out objc ivars which do not have prefix
> '_'
>
> Summary:
> For code of ivar declaration:
>
>int barWithoutPrefix;
>
> The fix will be:
>
>int _barWithoutPrefix;
>
> Reviewers: benhamilton, hokein, alexfh, aaron.ballman, ilya-biryukov
>
> Reviewed By: alexfh
>
> Subscribers: Eugene.Zelenko, xazax.hun, klimek, mgorny, cfe-commits
>
> Tags: #clang-tools-extra
>
> Differential Revision: https://reviews.llvm.org/D45392
>
> Added:
>
> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
> Modified:
>
> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>
> Modified:
> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp?rev=330492=330491=330492=diff
>
> ==
> ---
> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
> (original)
> +++
> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
> Fri Apr 20 16:18:09 2018
> @@ -109,6 +109,7 @@ namespace readability {
>  m(TemplateParameter) \
>  m(TypeAlias) \
>  m(MacroDefinition) \
> +m(ObjcIvar) \
>
>  enum StyleKind {
>  #define ENUMERATE(v) SK_ ## v,
> @@ -384,6 +385,9 @@ static StyleKind findStyleKind(
>  const NamedDecl *D,
>  const std::vector
>  ) {
> +  if (isa(D) && NamingStyles[SK_ObjcIvar])
> +return SK_ObjcIvar;
> +
>if (isa(D) && NamingStyles[SK_Typedef])
>  return SK_Typedef;
>
>
> Added:
> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m?rev=330492=auto
>
> ==
> ---
> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
> (added)
> +++
> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
> Fri Apr 20 16:18:09 2018
> @@ -0,0 +1,15 @@
> +// RUN: %check_clang_tidy %s readability-identifier-naming %t \
> +// RUN: -config='{CheckOptions: \
> +// RUN:  [{key: readability-identifier-naming.ObjcIvarPrefix, value:
> '_'}]}' \
> +// RUN: --
> +
> +@interface Foo
> +@end
> +
> +@interface Foo () {
> +int _bar;
> +int barWithoutPrefix;
> +// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: invalid case style for
> objc ivar 'barWithoutPrefix' [readability-identifier-naming]
> +// CHECK-FIXES: int _barWithoutPrefix;
> +}
> +@end
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r330184 - Add some infuriatingly necessary comments to this test case.

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Tue Apr 17 04:08:05 2018
New Revision: 330184

URL: http://llvm.org/viewvc/llvm-project?rev=330184=rev
Log:
Add some infuriatingly necessary comments to this test case.

Without these comments, by "luck" the contents of SomeKit's SKWidget.h
are precisely the same as SomeKitCore's SomeKitCore.h. This can create
havoc if anything canonicalizes on the inode and your filesystem assigns
a common inode to files with identical file content. Alternatively, if
your build system uses symlinks into a content-addressed-storage (as
Google's does), you end up with these files being symlinks to the same
file.

The end result is that Clang deduplicates them internally, and then
believes that the SomeKit framework includes the SomeKitCore.h header,
and does not include the SKWidget.h in SomeKit. This in turn results in
warnings in this test and eventually errors as Clang becomes confused
because the umbrella header for SomeKitCore has already been included
into another framework's module (SomeKit). Yay.

If anyone has a better idea about how to avoid this, I'm all ears.
Nothing other than causing the file content to change worked for me.

Modified:

cfe/trunk/test/Modules/Inputs/exportas-link/OtherKit.framework/Headers/OtherKit.h

cfe/trunk/test/Modules/Inputs/exportas-link/SomeKit.framework/Headers/SKWidget.h

cfe/trunk/test/Modules/Inputs/exportas-link/SomeKit.framework/Headers/SomeKit.h

cfe/trunk/test/Modules/Inputs/exportas-link/SomeKitCore.framework/Headers/SomeKitCore.h

Modified: 
cfe/trunk/test/Modules/Inputs/exportas-link/OtherKit.framework/Headers/OtherKit.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/exportas-link/OtherKit.framework/Headers/OtherKit.h?rev=330184=330183=330184=diff
==
--- 
cfe/trunk/test/Modules/Inputs/exportas-link/OtherKit.framework/Headers/OtherKit.h
 (original)
+++ 
cfe/trunk/test/Modules/Inputs/exportas-link/OtherKit.framework/Headers/OtherKit.h
 Tue Apr 17 04:08:05 2018
@@ -1,3 +1,4 @@
+// Umbrella header for OtherKit.
 #import 
 
 #ifdef F

Modified: 
cfe/trunk/test/Modules/Inputs/exportas-link/SomeKit.framework/Headers/SKWidget.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/exportas-link/SomeKit.framework/Headers/SKWidget.h?rev=330184=330183=330184=diff
==
--- 
cfe/trunk/test/Modules/Inputs/exportas-link/SomeKit.framework/Headers/SKWidget.h
 (original)
+++ 
cfe/trunk/test/Modules/Inputs/exportas-link/SomeKit.framework/Headers/SKWidget.h
 Tue Apr 17 04:08:05 2018
@@ -1 +1,2 @@
+// Delegate to SomeKitCore.
 #import 

Modified: 
cfe/trunk/test/Modules/Inputs/exportas-link/SomeKit.framework/Headers/SomeKit.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/exportas-link/SomeKit.framework/Headers/SomeKit.h?rev=330184=330183=330184=diff
==
--- 
cfe/trunk/test/Modules/Inputs/exportas-link/SomeKit.framework/Headers/SomeKit.h 
(original)
+++ 
cfe/trunk/test/Modules/Inputs/exportas-link/SomeKit.framework/Headers/SomeKit.h 
Tue Apr 17 04:08:05 2018
@@ -1 +1,6 @@
+// Umbrella header for SomeKit.
+//
+// Note that this file's content must not end up to coincidentally be identical
+// to any other file in the test which can easily happen given the reduced
+// test.
 #import 

Modified: 
cfe/trunk/test/Modules/Inputs/exportas-link/SomeKitCore.framework/Headers/SomeKitCore.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/exportas-link/SomeKitCore.framework/Headers/SomeKitCore.h?rev=330184=330183=330184=diff
==
--- 
cfe/trunk/test/Modules/Inputs/exportas-link/SomeKitCore.framework/Headers/SomeKitCore.h
 (original)
+++ 
cfe/trunk/test/Modules/Inputs/exportas-link/SomeKitCore.framework/Headers/SomeKitCore.h
 Tue Apr 17 04:08:05 2018
@@ -1 +1,6 @@
+// Umbrella header for SomeKitCore.
+//
+// Note that this file's content must not end up to coincidentally be identical
+// to any other file in the test which can easily happen given the reduced
+// test.
 #import 


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

Re: [clang-tools-extra] r329550 - Fix unused variable warning.

[Chandler Carruth via cfe-commits]

I have no opinion other than removing the warning. =D This seemed to be the
idiomatic pattern in the rest of LLVM and Clang. If someone wants to adjust
this locally, by all means.

On Mon, Apr 9, 2018 at 12:47 AM Zinovy Nis via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Thanks, Chandler.
>
>assert(Result.Nodes.getNodeAs("call"));
>
> would also be fine.
>
> пн, 9 апр. 2018 г. в 10:29, Chandler Carruth via cfe-commits <
> cfe-commits@lists.llvm.org>:
>
>> Author: chandlerc
>> Date: Mon Apr  9 00:26:42 2018
>> New Revision: 329550
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=329550=rev
>> Log:
>> Fix unused variable warning.
>>
>> Modified:
>> clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp
>>
>> Modified:
>> clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp?rev=329550=329549=329550=diff
>>
>> ==
>> ---
>> clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp
>> (original)
>> +++
>> clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp Mon
>> Apr  9 00:26:42 2018
>> @@ -99,6 +99,7 @@ void ParentVirtualCallCheck::registerMat
>>
>>  void ParentVirtualCallCheck::check(const MatchFinder::MatchResult
>> ) {
>>const auto *MatchedDecl =
>> Result.Nodes.getNodeAs("call");
>> +  (void)MatchedDecl;
>>assert(MatchedDecl);
>>
>>const auto *Member = Result.Nodes.getNodeAs("member");
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] r329550 - Fix unused variable warning.

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Mon Apr  9 00:26:42 2018
New Revision: 329550

URL: http://llvm.org/viewvc/llvm-project?rev=329550=rev
Log:
Fix unused variable warning.

Modified:
clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp

Modified: clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp?rev=329550=329549=329550=diff
==
--- clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp 
(original)
+++ clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp Mon 
Apr  9 00:26:42 2018
@@ -99,6 +99,7 @@ void ParentVirtualCallCheck::registerMat
 
 void ParentVirtualCallCheck::check(const MatchFinder::MatchResult ) {
   const auto *MatchedDecl = Result.Nodes.getNodeAs("call");
+  (void)MatchedDecl;
   assert(MatchedDecl);
 
   const auto *Member = Result.Nodes.getNodeAs("member");


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

Re: r329110 - [driver][darwin] Do not infer -simulator environment for non-simulator SDKs

[Chandler Carruth via cfe-commits]

On Tue, Apr 3, 2018 at 4:01 PM Alex L via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On 3 April 2018 at 14:30, Chandler Carruth  wrote:
>
>> On Tue, Apr 3, 2018 at 1:52 PM Alex Lorenz via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: arphaman
>>> Date: Tue Apr  3 13:50:05 2018
>>> New Revision: 329110
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=329110=rev
>>> Log:
>>> [driver][darwin] Do not infer -simulator environment for non-simulator
>>> SDKs
>>>
>>
>> I know you added a REQUIRES line to these tests, but I think there is a
>> much better way:
>>
>>
>>> --- cfe/trunk/test/Driver/darwin-sdkroot.c (original)
>>> +++ cfe/trunk/test/Driver/darwin-sdkroot.c Tue Apr  3 13:50:05 2018
>>> @@ -51,12 +51,21 @@
>>>  // CHECK-IPHONE: "-triple" "arm64-apple-ios8.0.0"
>>>  // CHECK-IPHONE: ld
>>>  // CHECK-IPHONE: "-iphoneos_version_min" "8.0.0"
>>> +// RUN: env SDKROOT=%t/SDKs/iPhoneOS8.0.0.sdk %clang %s -### 2>&1 \
>>>
>>
>> Instead of just running %clang, actually pass the `-target` you want to
>> it like we do in the below invocation and the other invocations in this
>> file.
>>
>> We shouldn't lose driver testing on other systems as long as you can
>> specify the desired target.
>>
>
>
> Hi Chandler!
>
> Thanks for pointing this out! We actually can't use -target here because
> when -target is specified, Darwin's driver won't infer the triple's
> environment from the SDKROOT. So this test covers the path in the driver
> that won't be taken when -target is specified.
>

Ah, I see, that's where the inference is triggered. Sure.


>
> You've made a good point about losing testing though. I can split out this
> test into the original file (with -target use) and the new tests which
> can't use -target and are Darwin specific to ensure we won't loose the
> existing coverage. I will commit a follow-up commit that does this.
>

Sure, makes sense to factor out inference-based tests where possible and
cover as much as you can w/o inference.

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

Re: r329110 - [driver][darwin] Do not infer -simulator environment for non-simulator SDKs

[Chandler Carruth via cfe-commits]

On Tue, Apr 3, 2018 at 1:52 PM Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: arphaman
> Date: Tue Apr  3 13:50:05 2018
> New Revision: 329110
>
> URL: http://llvm.org/viewvc/llvm-project?rev=329110=rev
> Log:
> [driver][darwin] Do not infer -simulator environment for non-simulator SDKs
>

I know you added a REQUIRES line to these tests, but I think there is a
much better way:


> --- cfe/trunk/test/Driver/darwin-sdkroot.c (original)
> +++ cfe/trunk/test/Driver/darwin-sdkroot.c Tue Apr  3 13:50:05 2018
> @@ -51,12 +51,21 @@
>  // CHECK-IPHONE: "-triple" "arm64-apple-ios8.0.0"
>  // CHECK-IPHONE: ld
>  // CHECK-IPHONE: "-iphoneos_version_min" "8.0.0"
> +// RUN: env SDKROOT=%t/SDKs/iPhoneOS8.0.0.sdk %clang %s -### 2>&1 \
>

Instead of just running %clang, actually pass the `-target` you want to it
like we do in the below invocation and the other invocations in this file.

We shouldn't lose driver testing on other systems as long as you can
specify the desired target.


> +// RUN:   | FileCheck --check-prefix=CHECK-IPHONE-X86 %s
> +// CHECK-IPHONE-X86: clang
> +// CHECK-IPHONE-X86: "-cc1"
> +// CHECK-IPHONE-X86: -apple-ios8.0.0"
> +// CHECK-IPHONE-X86: ld
> +// CHECK-IPHONE-X86: "-iphoneos_version_min" "8.0.0"
>  //
>  //
>  // RUN: rm -rf %t/SDKs/iPhoneSimulator8.0.sdk
>  // RUN: mkdir -p %t/SDKs/iPhoneSimulator8.0.sdk
>  // RUN: env SDKROOT=%t/SDKs/iPhoneSimulator8.0.sdk %clang -target
> x86_64-apple-darwin %s -### 2>&1 \
>  // RUN:   | FileCheck --check-prefix=CHECK-SIMULATOR %s
> +// RUN: env SDKROOT=%t/SDKs/iPhoneSimulator8.0.sdk %clang -arch x86_64 %s
> -### 2>&1 \
> +// RUN:   | FileCheck --check-prefix=CHECK-SIMULATOR %s
>  //
>  // CHECK-SIMULATOR: clang
>  // CHECK-SIMULATOR: "-cc1"
> @@ -74,3 +83,49 @@
>  // CHECK-MACOSX: "-triple" "x86_64-apple-macosx10.10.0"
>  // CHECK-MACOSX: ld
>  // CHECK-MACOSX: "-macosx_version_min" "10.10.0"
> +
> +// RUN: rm -rf %t/SDKs/WatchOS3.0.sdk
> +// RUN: mkdir -p %t/SDKs/WatchOS3.0.sdk
> +// RUN: env SDKROOT=%t/SDKs/WatchOS3.0.sdk %clang %s -### 2>&1 \
> +// RUN:   | FileCheck --check-prefix=CHECK-WATCH %s
> +//
> +// CHECK-WATCH: clang
> +// CHECK-WATCH: "-cc1"
> +// CHECK-WATCH: -apple-watchos3.0.0"
> +// CHECK-WATCH: ld
> +// CHECK-WATCH: "-watchos_version_min" "3.0.0"
> +//
> +//
> +// RUN: rm -rf %t/SDKs/WatchSimulator3.0.sdk
> +// RUN: mkdir -p %t/SDKs/WatchSimulator3.0.sdk
> +// RUN: env SDKROOT=%t/SDKs/WatchSimulator3.0.sdk %clang %s -### 2>&1 \
> +// RUN:   | FileCheck --check-prefix=CHECK-WATCH-SIMULATOR %s
> +//
> +// CHECK-WATCH-SIMULATOR: clang
> +// CHECK-WATCH-SIMULATOR: "-cc1"
> +// CHECK-WATCH-SIMULATOR: -apple-watchos3.0.0-simulator"
> +// CHECK-WATCH-SIMULATOR: ld
> +// CHECK-WATCH-SIMULATOR: "-watchos_simulator_version_min" "3.0.0"
> +
> +// RUN: rm -rf %t/SDKs/AppleTVOS10.0.sdk
> +// RUN: mkdir -p %t/SDKs/AppleTVOS10.0.sdk
> +// RUN: env SDKROOT=%t/SDKs/AppleTVOS10.0.sdk %clang %s -### 2>&1 \
> +// RUN:   | FileCheck --check-prefix=CHECK-TV %s
> +//
> +// CHECK-TV: clang
> +// CHECK-TV: "-cc1"
> +// CHECK-TV: -apple-tvos10.0.0"
> +// CHECK-TV: ld
> +// CHECK-TV: "-tvos_version_min" "10.0.0"
> +//
> +//
> +// RUN: rm -rf %t/SDKs/AppleTVSimulator10.0.sdk
> +// RUN: mkdir -p %t/SDKs/AppleTVSimulator10.0.sdk
> +// RUN: env SDKROOT=%t/SDKs/AppleTVSimulator10.0.sdk %clang %s -### 2>&1 \
> +// RUN:   | FileCheck --check-prefix=CHECK-TV-SIMULATOR %s
> +//
> +// CHECK-TV-SIMULATOR: clang
> +// CHECK-TV-SIMULATOR: "-cc1"
> +// CHECK-TV-SIMULATOR: -apple-tvos10.0.0-simulator"
> +// CHECK-TV-SIMULATOR: ld
> +// CHECK-TV-SIMULATOR: "-tvos_simulator_version_min" "10.0.0"
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r329113 - Add REQUIRES: darwin-system to test/Driver/darwin-sdkroot.c

[Chandler Carruth via cfe-commits]

See my reply to the original commit, but I think this is the wrong fix.

On Tue, Apr 3, 2018 at 2:13 PM Alex Lorenz via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: arphaman
> Date: Tue Apr  3 14:10:26 2018
> New Revision: 329113
>
> URL: http://llvm.org/viewvc/llvm-project?rev=329113=rev
> Log:
> Add REQUIRES: darwin-system to test/Driver/darwin-sdkroot.c
>
> The test from r329110 is for Darwin only
>
> Modified:
> cfe/trunk/test/Driver/darwin-sdkroot.c
>
> Modified: cfe/trunk/test/Driver/darwin-sdkroot.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/darwin-sdkroot.c?rev=329113=329112=329113=diff
>
> ==
> --- cfe/trunk/test/Driver/darwin-sdkroot.c (original)
> +++ cfe/trunk/test/Driver/darwin-sdkroot.c Tue Apr  3 14:10:26 2018
> @@ -1,4 +1,5 @@
>  // Check that SDKROOT is used to define the default for -isysroot on
> Darwin.
> +// REQUIRES: system-darwin
>  //
>  // RUN: rm -rf %t.tmpdir
>  // RUN: mkdir -p %t.tmpdir
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r323155 - Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target

[Chandler Carruth via cfe-commits]

Yeah, I'll write stuff up for them.

On Fri, Feb 2, 2018 at 3:06 AM Hans Wennborg <h...@chromium.org> wrote:

> Thanks! I've merged them to 6.0 as below and they will be part of rc2,
> scheduled for next week.
>
> Chandler, do you want to write release notes for this?
>
> On Thu, Feb 1, 2018 at 8:09 PM, Chandler Carruth <chandl...@gmail.com>
> wrote:
> > +Hans Wennborg +tstel...@redhat.com
> >
> > So the retpoline patch series we should get back ported start with this
> > revision and have two follow ups:
> > r323155
>
> Merged in r324067 (llvm), r324068 (cfe), r324069 (lld)
>
> > r323288
>
> Merged in r324070.
>
> > r323915
>
> Merged in r324071.
>
> >
> > +Reid Kleckner was going to look at doing the (likely more involved)
> > backport to the 5 branch
> >
> > On Mon, Jan 22, 2018 at 2:06 PM Chandler Carruth via cfe-commits
> > <cfe-commits@lists.llvm.org> wrote:
> >>
> >> Author: chandlerc
> >> Date: Mon Jan 22 14:05:25 2018
> >> New Revision: 323155
> >>
> >> URL: http://llvm.org/viewvc/llvm-project?rev=323155=rev
> >> Log:
> >> Introduce the "retpoline" x86 mitigation technique for variant #2 of the
> >> speculative execution vulnerabilities disclosed today, specifically
> >> identified by CVE-2017-5715, "Branch Target Injection", and is one of
> the
> >> two halves to Spectre..
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r323155 - Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target

[Chandler Carruth via cfe-commits]

+Hans Wennborg <h...@chromium.org> +tstel...@redhat.com
<tstel...@redhat.com>

So the retpoline patch series we should get back ported start with this
revision and have two follow ups:
r323155
r323288
r323915

+Reid Kleckner <r...@google.com> was going to look at doing the (likely more
involved) backport to the 5 branch

On Mon, Jan 22, 2018 at 2:06 PM Chandler Carruth via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: chandlerc
> Date: Mon Jan 22 14:05:25 2018
> New Revision: 323155
>
> URL: http://llvm.org/viewvc/llvm-project?rev=323155=rev
> Log:
> Introduce the "retpoline" x86 mitigation technique for variant #2 of the
> speculative execution vulnerabilities disclosed today, specifically
> identified by CVE-2017-5715, "Branch Target Injection", and is one of the
> two halves to Spectre..
>
> Summary:
> First, we need to explain the core of the vulnerability. Note that this
> is a very incomplete description, please see the Project Zero blog post
> for details:
>
> https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html
>
> The basis for branch target injection is to direct speculative execution
> of the processor to some "gadget" of executable code by poisoning the
> prediction of indirect branches with the address of that gadget. The
> gadget in turn contains an operation that provides a side channel for
> reading data. Most commonly, this will look like a load of secret data
> followed by a branch on the loaded value and then a load of some
> predictable cache line. The attacker then uses timing of the processors
> cache to determine which direction the branch took *in the speculative
> execution*, and in turn what one bit of the loaded value was. Due to the
> nature of these timing side channels and the branch predictor on Intel
> processors, this allows an attacker to leak data only accessible to
> a privileged domain (like the kernel) back into an unprivileged domain.
>
> The goal is simple: avoid generating code which contains an indirect
> branch that could have its prediction poisoned by an attacker. In many
> cases, the compiler can simply use directed conditional branches and
> a small search tree. LLVM already has support for lowering switches in
> this way and the first step of this patch is to disable jump-table
> lowering of switches and introduce a pass to rewrite explicit indirectbr
> sequences into a switch over integers.
>
> However, there is no fully general alternative to indirect calls. We
> introduce a new construct we call a "retpoline" to implement indirect
> calls in a non-speculatable way. It can be thought of loosely as
> a trampoline for indirect calls which uses the RET instruction on x86.
> Further, we arrange for a specific call->ret sequence which ensures the
> processor predicts the return to go to a controlled, known location. The
> retpoline then "smashes" the return address pushed onto the stack by the
> call with the desired target of the original indirect call. The result
> is a predicted return to the next instruction after a call (which can be
> used to trap speculative execution within an infinite loop) and an
> actual indirect branch to an arbitrary address.
>
> On 64-bit x86 ABIs, this is especially easily done in the compiler by
> using a guaranteed scratch register to pass the target into this device.
> For 32-bit ABIs there isn't a guaranteed scratch register and so several
> different retpoline variants are introduced to use a scratch register if
> one is available in the calling convention and to otherwise use direct
> stack push/pop sequences to pass the target address.
>
> This "retpoline" mitigation is fully described in the following blog
> post: https://support.google.com/faqs/answer/7625886
>
> We also support a target feature that disables emission of the retpoline
> thunk by the compiler to allow for custom thunks if users want them.
> These are particularly useful in environments like kernels that
> routinely do hot-patching on boot and want to hot-patch their thunk to
> different code sequences. They can write this custom thunk and use
> `-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this
> case, on x86-64 thu thunk names must be:
> ```
>   __llvm_external_retpoline_r11
> ```
> or on 32-bit:
> ```
>   __llvm_external_retpoline_eax
>   __llvm_external_retpoline_ecx
>   __llvm_external_retpoline_edx
>   __llvm_external_retpoline_push
> ```
> And the target of the retpoline is passed in the named register, or in
> the case of the `push` suffix on the top of the stack via a `pushl`
> instruction.
>
> There is one other important source of indirect branch

r323155 - Introduce the "retpoline" x86 mitigation technique for variant #2 of the speculative execution vulnerabilities disclosed today, specifically identified by CVE-2017-5715, "Branch Target Injec

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Mon Jan 22 14:05:25 2018
New Revision: 323155

URL: http://llvm.org/viewvc/llvm-project?rev=323155=rev
Log:
Introduce the "retpoline" x86 mitigation technique for variant #2 of the 
speculative execution vulnerabilities disclosed today, specifically identified 
by CVE-2017-5715, "Branch Target Injection", and is one of the two halves to 
Spectre..

Summary:
First, we need to explain the core of the vulnerability. Note that this
is a very incomplete description, please see the Project Zero blog post
for details:
https://googleprojectzero.blogspot.com/2018/01/reading-privileged-memory-with-side.html

The basis for branch target injection is to direct speculative execution
of the processor to some "gadget" of executable code by poisoning the
prediction of indirect branches with the address of that gadget. The
gadget in turn contains an operation that provides a side channel for
reading data. Most commonly, this will look like a load of secret data
followed by a branch on the loaded value and then a load of some
predictable cache line. The attacker then uses timing of the processors
cache to determine which direction the branch took *in the speculative
execution*, and in turn what one bit of the loaded value was. Due to the
nature of these timing side channels and the branch predictor on Intel
processors, this allows an attacker to leak data only accessible to
a privileged domain (like the kernel) back into an unprivileged domain.

The goal is simple: avoid generating code which contains an indirect
branch that could have its prediction poisoned by an attacker. In many
cases, the compiler can simply use directed conditional branches and
a small search tree. LLVM already has support for lowering switches in
this way and the first step of this patch is to disable jump-table
lowering of switches and introduce a pass to rewrite explicit indirectbr
sequences into a switch over integers.

However, there is no fully general alternative to indirect calls. We
introduce a new construct we call a "retpoline" to implement indirect
calls in a non-speculatable way. It can be thought of loosely as
a trampoline for indirect calls which uses the RET instruction on x86.
Further, we arrange for a specific call->ret sequence which ensures the
processor predicts the return to go to a controlled, known location. The
retpoline then "smashes" the return address pushed onto the stack by the
call with the desired target of the original indirect call. The result
is a predicted return to the next instruction after a call (which can be
used to trap speculative execution within an infinite loop) and an
actual indirect branch to an arbitrary address.

On 64-bit x86 ABIs, this is especially easily done in the compiler by
using a guaranteed scratch register to pass the target into this device.
For 32-bit ABIs there isn't a guaranteed scratch register and so several
different retpoline variants are introduced to use a scratch register if
one is available in the calling convention and to otherwise use direct
stack push/pop sequences to pass the target address.

This "retpoline" mitigation is fully described in the following blog
post: https://support.google.com/faqs/answer/7625886

We also support a target feature that disables emission of the retpoline
thunk by the compiler to allow for custom thunks if users want them.
These are particularly useful in environments like kernels that
routinely do hot-patching on boot and want to hot-patch their thunk to
different code sequences. They can write this custom thunk and use
`-mretpoline-external-thunk` *in addition* to `-mretpoline`. In this
case, on x86-64 thu thunk names must be:
```
  __llvm_external_retpoline_r11
```
or on 32-bit:
```
  __llvm_external_retpoline_eax
  __llvm_external_retpoline_ecx
  __llvm_external_retpoline_edx
  __llvm_external_retpoline_push
```
And the target of the retpoline is passed in the named register, or in
the case of the `push` suffix on the top of the stack via a `pushl`
instruction.

There is one other important source of indirect branches in x86 ELF
binaries: the PLT. These patches also include support for LLD to
generate PLT entries that perform a retpoline-style indirection.

The only other indirect branches remaining that we are aware of are from
precompiled runtimes (such as crt0.o and similar). The ones we have
found are not really attackable, and so we have not focused on them
here, but eventually these runtimes should also be replicated for
retpoline-ed configurations for completeness.

For kernels or other freestanding or fully static executables, the
compiler switch `-mretpoline` is sufficient to fully mitigate this
particular attack. For dynamic executables, you must compile *all*
libraries with `-mretpoline` and additionally link the dynamic
executable and all shared libraries with LLD and pass `-z retpolineplt`
(or use similar functionality from some other linker). We strongly
recommend also using `-z now` as non-lazy binding 

[libunwind] r321469 - There is no portable format string for printing `uintptr_t` values.

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Tue Dec 26 21:46:53 2017
New Revision: 321469

URL: http://llvm.org/viewvc/llvm-project?rev=321469=rev
Log:
There is no portable format string for printing `uintptr_t` values.
Instead, cast them to `void *` which has a portable format string syntax
of `%p`.

This fixes a -Wformat error when building libunwind.

Modified:
libunwind/trunk/src/AddressSpace.hpp

Modified: libunwind/trunk/src/AddressSpace.hpp
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/AddressSpace.hpp?rev=321469=321468=321469=diff
==
--- libunwind/trunk/src/AddressSpace.hpp (original)
+++ libunwind/trunk/src/AddressSpace.hpp Tue Dec 26 21:46:53 2017
@@ -384,13 +384,13 @@ inline bool LocalAddressSpace::findUnwin
   // Bare metal is statically linked, so no need to ask the dynamic loader
   info.dwarf_section_length = (uintptr_t)(&__eh_frame_end - &__eh_frame_start);
   info.dwarf_section =(uintptr_t)(&__eh_frame_start);
-  _LIBUNWIND_TRACE_UNWINDING("findUnwindSections: section %X length %x",
- info.dwarf_section, info.dwarf_section_length);
+  _LIBUNWIND_TRACE_UNWINDING("findUnwindSections: section %p length %p",
+ (void *)info.dwarf_section, (void 
*)info.dwarf_section_length);
 #if defined(_LIBUNWIND_SUPPORT_DWARF_INDEX)
   info.dwarf_index_section =(uintptr_t)(&__eh_frame_hdr_start);
   info.dwarf_index_section_length = (uintptr_t)(&__eh_frame_hdr_end - 
&__eh_frame_hdr_start);
-  _LIBUNWIND_TRACE_UNWINDING("findUnwindSections: index section %X length %x",
- info.dwarf_index_section, 
info.dwarf_index_section_length);
+  _LIBUNWIND_TRACE_UNWINDING("findUnwindSections: index section %p length %p",
+ (void *)info.dwarf_index_section, (void 
*)info.dwarf_index_section_length);
 #endif
   if (info.dwarf_section_length)
 return true;
@@ -398,8 +398,8 @@ inline bool LocalAddressSpace::findUnwin
   // Bare metal is statically linked, so no need to ask the dynamic loader
   info.arm_section =(uintptr_t)(&__exidx_start);
   info.arm_section_length = (uintptr_t)(&__exidx_end - &__exidx_start);
-  _LIBUNWIND_TRACE_UNWINDING("findUnwindSections: section %X length %x",
- info.arm_section, info.arm_section_length);
+  _LIBUNWIND_TRACE_UNWINDING("findUnwindSections: section %p length %p",
+ (void *)info.arm_section, (void 
*)info.arm_section_length);
   if (info.arm_section && info.arm_section_length)
 return true;
 #elif defined(_LIBUNWIND_SUPPORT_DWARF_UNWIND) && defined(_WIN32)


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

r321392 - Add an explicit `LLVM_FALLTHROUGH` annotation to an intentional

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Fri Dec 22 15:29:49 2017
New Revision: 321392

URL: http://llvm.org/viewvc/llvm-project?rev=321392=rev
Log:
Add an explicit `LLVM_FALLTHROUGH` annotation to an intentional
fallthrough. Fixes GCC and Clang warnings about this.

Modified:
cfe/trunk/lib/Sema/SemaType.cpp

Modified: cfe/trunk/lib/Sema/SemaType.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaType.cpp?rev=321392=321391=321392=diff
==
--- cfe/trunk/lib/Sema/SemaType.cpp (original)
+++ cfe/trunk/lib/Sema/SemaType.cpp Fri Dec 22 15:29:49 2017
@@ -3143,6 +3143,7 @@ static void warnAboutRedundantParens(Sem
 case DeclaratorChunk::Paren:
   if ( == )
 continue;
+  LLVM_FALLTHROUGH;
 case DeclaratorChunk::Pointer:
   StartsWithDeclaratorId = false;
   continue;


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

r318137 - [PM] Require a registered x86 target for this test which uses the x86

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Mon Nov 13 21:20:03 2017
New Revision: 318137

URL: http://llvm.org/viewvc/llvm-project?rev=318137=rev
Log:
[PM] Require a registered x86 target for this test which uses the x86
triple.

Modified:
cfe/trunk/test/CodeGen/bounds-checking.c

Modified: cfe/trunk/test/CodeGen/bounds-checking.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/bounds-checking.c?rev=318137=318136=318137=diff
==
--- cfe/trunk/test/CodeGen/bounds-checking.c (original)
+++ cfe/trunk/test/CodeGen/bounds-checking.c Mon Nov 13 21:20:03 2017
@@ -2,6 +2,8 @@
 // RUN: %clang_cc1 -fsanitize=local-bounds -fexperimental-new-pass-manager 
-emit-llvm -triple x86_64-apple-darwin10 %s -o - | FileCheck %s
 // RUN: %clang_cc1 -fsanitize=array-bounds -O -fsanitize-trap=array-bounds 
-emit-llvm -triple x86_64-apple-darwin10 -DNO_DYNAMIC %s -o - | FileCheck %s
 // RUN: %clang_cc1 -fsanitize=array-bounds -O -fsanitize-trap=array-bounds 
-fexperimental-new-pass-manager -emit-llvm -triple x86_64-apple-darwin10 
-DNO_DYNAMIC %s -o - | FileCheck %s
+//
+// REQUIRES: x86-registered-target
 
 // CHECK-LABEL: @f
 double f(int b, int i) {


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

r318131 - [PM] Wire up support for the bounds checking sanitizer with the new PM.

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Mon Nov 13 17:59:18 2017
New Revision: 318131

URL: http://llvm.org/viewvc/llvm-project?rev=318131=rev
Log:
[PM] Wire up support for the bounds checking sanitizer with the new PM.

Not much interesting here. Mostly wiring things together.

One thing worth noting is that the approach is substantially different
from the old PM. Here, the -O0 case works fundamentally differently in
that we just directly build the pipeline without any callbacks or other
cruft. In some ways, this is nice and clean. However, I don't like that
it causes the sanitizers to be enabled with different changes at
different times. =/ Suggestions for a better way to do this are welcome.

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

Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/test/CodeGen/bounds-checking.c

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=318131=318130=318131=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Mon Nov 13 17:59:18 2017
@@ -900,6 +900,12 @@ void EmitAssemblyHelper::EmitAssemblyWit
   // Build a minimal pipeline based on the semantics required by Clang,
   // which is just that always inlining occurs.
   MPM.addPass(AlwaysInlinerPass());
+
+  // At -O0 we directly run necessary sanitizer passes.
+  if (LangOpts.Sanitize.has(SanitizerKind::LocalBounds))
+MPM.addPass(createModuleToFunctionPassAdaptor(BoundsCheckingPass()));
+
+  // Lastly, add a semantically necessary pass for ThinLTO.
   if (IsThinLTO)
 MPM.addPass(NameAnonGlobalPass());
 } else {
@@ -907,6 +913,14 @@ void EmitAssemblyHelper::EmitAssemblyWit
   // configure the pipeline.
   PassBuilder::OptimizationLevel Level = mapToLevel(CodeGenOpts);
 
+  // Register callbacks to schedule sanitizer passes at the appropriate 
part of
+  // the pipeline.
+  if (LangOpts.Sanitize.has(SanitizerKind::LocalBounds))
+PB.registerScalarOptimizerLateEPCallback(
+[](FunctionPassManager , PassBuilder::OptimizationLevel Level) 
{
+  FPM.addPass(BoundsCheckingPass());
+});
+
   if (IsThinLTO) {
 MPM = PB.buildThinLTOPreLinkDefaultPipeline(
 Level, CodeGenOpts.DebugPassManager);

Modified: cfe/trunk/test/CodeGen/bounds-checking.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/bounds-checking.c?rev=318131=318130=318131=diff
==
--- cfe/trunk/test/CodeGen/bounds-checking.c (original)
+++ cfe/trunk/test/CodeGen/bounds-checking.c Mon Nov 13 17:59:18 2017
@@ -1,5 +1,7 @@
 // RUN: %clang_cc1 -fsanitize=local-bounds -emit-llvm -triple 
x86_64-apple-darwin10 %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fsanitize=local-bounds -fexperimental-new-pass-manager 
-emit-llvm -triple x86_64-apple-darwin10 %s -o - | FileCheck %s
 // RUN: %clang_cc1 -fsanitize=array-bounds -O -fsanitize-trap=array-bounds 
-emit-llvm -triple x86_64-apple-darwin10 -DNO_DYNAMIC %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fsanitize=array-bounds -O -fsanitize-trap=array-bounds 
-fexperimental-new-pass-manager -emit-llvm -triple x86_64-apple-darwin10 
-DNO_DYNAMIC %s -o - | FileCheck %s
 
 // CHECK-LABEL: @f
 double f(int b, int i) {


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

r318130 - [PM] Add a missing header that I had in the next commit but was needed

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Mon Nov 13 17:47:24 2017
New Revision: 318130

URL: http://llvm.org/viewvc/llvm-project?rev=318130=rev
Log:
[PM] Add a missing header that I had in the next commit but was needed
in r318128. Should fix the build.

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

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=318130=318129=318130=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Mon Nov 13 17:47:24 2017
@@ -51,6 +51,7 @@
 #include "llvm/Transforms/IPO/PassManagerBuilder.h"
 #include "llvm/Transforms/IPO/ThinLTOBitcodeWriter.h"
 #include "llvm/Transforms/Instrumentation.h"
+#include "llvm/Transforms/Instrumentation/BoundsChecking.h"
 #include "llvm/Transforms/ObjCARC.h"
 #include "llvm/Transforms/Scalar.h"
 #include "llvm/Transforms/Scalar/GVN.h"


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

r318128 - [PM] Port BoundsChecking to the new PM.

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Mon Nov 13 17:30:04 2017
New Revision: 318128

URL: http://llvm.org/viewvc/llvm-project?rev=318128=rev
Log:
[PM] Port BoundsChecking to the new PM.

Registers it and everything, updates all the references, etc.

Next patch will add support to Clang's `-fexperimental-new-pass-manager`
path to actually enable BoundsChecking correctly.

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

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

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=318128=318127=318128=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Mon Nov 13 17:30:04 2017
@@ -168,7 +168,7 @@ static void addAddDiscriminatorsPass(con
 
 static void addBoundsCheckingPass(const PassManagerBuilder ,
   legacy::PassManagerBase ) {
-  PM.add(createBoundsCheckingPass());
+  PM.add(createBoundsCheckingLegacyPass());
 }
 
 static void addSanitizerCoveragePass(const PassManagerBuilder ,


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

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

[Chandler Carruth via cfe-commits]

On Sun, Sep 3, 2017 at 10:41 PM Hal Finkel via llvm-commits <
llvm-comm...@lists.llvm.org> wrote:

> Nevertheless, I think that you've convinced me that this is a least-bad
> solution. I'll want a flag preserving the old behavior. Something like
> -fwiden-bitfield-accesses (modulo bikeshedding).
>
Several different approaches have been discussed in this thread, I'm not
sure what you mean about "least-bad solution"...

I remain completely unconvinced that we should change the default behavior.
At most, I'm not strongly opposed to adding an attribute that indicates
"please try to use narrow loads for this bitfield member" and is an error
if applied to a misaligned or non-byte-sized bitfield member. But I remain
strongly opposed to changing the default behavior. We have one or two cases
that regress and are easily addressed by source changes (either to not use
bitfields or to use an attribute). I don't think that is cause to change
the lowering Clang has used for years and potentially regress many other
use cases.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

[Chandler Carruth via cfe-commits]

On Tue, Aug 22, 2017 at 7:18 PM Xinliang David Li via llvm-commits <
llvm-comm...@lists.llvm.org> wrote:

> On Tue, Aug 22, 2017 at 7:10 PM, Chandler Carruth via llvm-commits <
> llvm-comm...@lists.llvm.org> wrote:
>
>> On Tue, Aug 22, 2017 at 7:03 PM Xinliang David Li via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> On Tue, Aug 22, 2017 at 6:37 PM, Chandler Carruth via Phabricator <
>>> revi...@reviews.llvm.org> wrote:
>>>
 chandlerc added a comment.

 I'm really not a fan of the degree of complexity and subtlety that this
 introduces into the frontend, all to allow particular backend 
 optimizations.

 I feel like this is Clang working around a fundamental deficiency in
 LLVM and we should instead find a way to fix this in LLVM itself.

 As has been pointed out before, user code can synthesize large integers
 that small bit sequences are extracted from, and Clang and LLVM should
 handle those just as well as actual bitfields.

 Can we see how far we can push the LLVM side before we add complexity
 to Clang here? I understand that there remain challenges to LLVM's stuff,
 but I don't think those challenges make *all* of the LLVM improvements off
 the table, I don't think we've exhausted all ways of improving the LLVM
 changes being proposed, and I think we should still land all of those and
 re-evaluate how important these issues are when all of that is in place.

>>>
>>> The main challenge of doing  this in LLVM is that inter-procedural
>>> analysis (and possibly cross module) is needed (for store forwarding
>>> issues).
>>>
>>> Wei, perhaps you can provide concrete test case to illustrate the issue
>>> so that reviewers have a good understanding.
>>>
>>
>> It doesn't seem like all options for addressing that have been exhausted.
>> And even then, I feel like trying to fix this with non-obvious (to the
>> programmer) frontend heuristics isn't a good solution. I actually *prefer*
>> the source work around of "don't use a bitfield if you *must* have narrow
>> width access across modules where the optimizer cannot see enough to narrow
>> them and you happen to know that there is a legal narrow access that
>> works". Because that way the programmer has *control* over this rather than
>> being at the whim of whichever side of the heuristic they end up on.
>>
>
>
> The source workaround solution *does not* scale. Most importantly, user
> may not even be aware of the problem (and performance loss) unless
>  compiling the code with another compiler and notice the performance
> difference.
>

I don't really understand this argument...

I don't think we can realistically chase all performance problems that
users aren't aware of or can't measure. And our users *do* care and seem
very good at benchmarking and noticing problems. =]

I also think it is OK if in rare cases programmers have to adapt their
source code to optimize well. We can and should make this as rare as
reasonable from an engineering tradeoff perspective, but at a certain point
we need to work with programmers to find a way to solve the problem. There
exist coding patterns that Clang and LLVM will never be particularly
effective at optimizing, and that seems OK. We just need to have reasonable
engineering requirements for those cases:

1) They need to be quite rare. So far, this issue has come up fairly
infrequently. Not never, but there are many issues that seem to come up
much more often such as inlining issues.

2) We need an effective way to explain how programmers should write code to
optimize well, and this explanation needs to be as simple as possible.

3) We likely need to give programmers *choices* about which direction their
code gets optimized for. And this is (IMO) the biggest practical issue with
the approach in this change (beyond race detection and other semantic
issues).


I'm suggesting that we teach programmers to choose between a bitfield to
get combining-friendly access to tightly packed data, and integer types of
an appropriate size to get inexpensive and predictable loads and stores.
For sub-byte-width and non-byte-aligned bitfields this is already a
necessary property and so it seems like a consistent and easily explained
and taught model.

While there are times where there is a single "right" answer and we only
have to provide that, I don't think this is one of them. I've seen rare but
serious complaints about *both* failing to combine adjacent bit fields and
failing to narrow to small legal integer types. These seem in fundamental
tension, and I would prefer to establish idiomatic patterns for programmers
to request the behavior then need in their application.


>
> David
>
>>
>>
>>>
>>> David
>>>


 Repository:
   rL LLVM

 https://reviews.llvm.org/D36562



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

Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type

[Chandler Carruth via cfe-commits]

On Tue, Aug 22, 2017 at 7:03 PM Xinliang David Li via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> On Tue, Aug 22, 2017 at 6:37 PM, Chandler Carruth via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> chandlerc added a comment.
>>
>> I'm really not a fan of the degree of complexity and subtlety that this
>> introduces into the frontend, all to allow particular backend optimizations.
>>
>> I feel like this is Clang working around a fundamental deficiency in LLVM
>> and we should instead find a way to fix this in LLVM itself.
>>
>> As has been pointed out before, user code can synthesize large integers
>> that small bit sequences are extracted from, and Clang and LLVM should
>> handle those just as well as actual bitfields.
>>
>> Can we see how far we can push the LLVM side before we add complexity to
>> Clang here? I understand that there remain challenges to LLVM's stuff, but
>> I don't think those challenges make *all* of the LLVM improvements off the
>> table, I don't think we've exhausted all ways of improving the LLVM changes
>> being proposed, and I think we should still land all of those and
>> re-evaluate how important these issues are when all of that is in place.
>>
>
> The main challenge of doing  this in LLVM is that inter-procedural
> analysis (and possibly cross module) is needed (for store forwarding
> issues).
>
> Wei, perhaps you can provide concrete test case to illustrate the issue so
> that reviewers have a good understanding.
>

It doesn't seem like all options for addressing that have been exhausted.
And even then, I feel like trying to fix this with non-obvious (to the
programmer) frontend heuristics isn't a good solution. I actually *prefer*
the source work around of "don't use a bitfield if you *must* have narrow
width access across modules where the optimizer cannot see enough to narrow
them and you happen to know that there is a legal narrow access that
works". Because that way the programmer has *control* over this rather than
being at the whim of whichever side of the heuristic they end up on.


>
> David
>
>>
>>
>> Repository:
>>   rL LLVM
>>
>> https://reviews.llvm.org/D36562
>>
>>
>>
>> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r310994 - Fix a UBSan failure where this boolean was copied when uninitialized.

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Wed Aug 16 00:22:49 2017
New Revision: 310994

URL: http://llvm.org/viewvc/llvm-project?rev=310994=rev
Log:
Fix a UBSan failure where this boolean was copied when uninitialized.

When r310905 moved the pointer and bool out of a PointerIntPair, it made
them end up uninitialized and caused UBSan failures when copying the
uninitialized boolean. However, making the pointer be null should avoid
the reference to the boolean entirely.

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

Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=310994=310993=310994=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Wed Aug 16 00:22:49 2017
@@ -977,7 +977,7 @@ namespace {
   /// RAII object used to optionally suppress diagnostics and side-effects from
   /// a speculative evaluation.
   class SpeculativeEvaluationRAII {
-EvalInfo *Info;
+EvalInfo *Info = nullptr;
 Expr::EvalStatus OldStatus;
 bool OldIsSpeculativelyEvaluating;
 


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

r308967 - [PM] Setup TargetLibraryInfo correctly for the new pass manager.

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Tue Jul 25 03:46:07 2017
New Revision: 308967

URL: http://llvm.org/viewvc/llvm-project?rev=308967=rev
Log:
[PM] Setup TargetLibraryInfo correctly for the new pass manager.

Without this, -fno-builtin and friends doesn't work. Added the obvious
RUN lines to the test for -fno-builtin and they pass now.

Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/test/CodeGen/nobuiltin.c

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=308967=308966=308967=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Tue Jul 25 03:46:07 2017
@@ -871,6 +871,14 @@ void EmitAssemblyHelper::EmitAssemblyWit
   // Register the AA manager first so that our version is the one used.
   FAM.registerPass([&] { return PB.buildDefaultAAPipeline(); });
 
+  // Register the target library analysis directly and give it a customized
+  // preset TLI.
+  Triple TargetTriple(TheModule->getTargetTriple());
+  std::unique_ptr TLII(
+  createTLII(TargetTriple, CodeGenOpts));
+  FAM.registerPass([&] { return TargetLibraryAnalysis(*TLII); });
+  MAM.registerPass([&] { return TargetLibraryAnalysis(*TLII); });
+
   // Register all the basic analyses with the managers.
   PB.registerModuleAnalyses(MAM);
   PB.registerCGSCCAnalyses(CGAM);

Modified: cfe/trunk/test/CodeGen/nobuiltin.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/nobuiltin.c?rev=308967=308966=308967=diff
==
--- cfe/trunk/test/CodeGen/nobuiltin.c (original)
+++ cfe/trunk/test/CodeGen/nobuiltin.c Tue Jul 25 03:46:07 2017
@@ -4,6 +4,10 @@
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -fno-builtin -O1 -S -o - %s | 
FileCheck -check-prefix=NOSTRCPY -check-prefix=NOMEMSET %s
 // RUN: %clang_cc1 -triple x86_64-linux-gnu -fno-builtin-memset -O1 -S -o - %s 
| FileCheck -check-prefix=STRCPY -check-prefix=NOMEMSET %s
 
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -O1 
-fexperimental-new-pass-manager -S -o - %s | FileCheck -check-prefix=STRCPY 
-check-prefix=MEMSET %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fno-builtin -O1 
-fexperimental-new-pass-manager -S -o - %s | FileCheck -check-prefix=NOSTRCPY 
-check-prefix=NOMEMSET %s
+// RUN: %clang_cc1 -triple x86_64-linux-gnu -fno-builtin-memset -O1 
-fexperimental-new-pass-manager -S -o - %s | FileCheck -check-prefix=STRCPY 
-check-prefix=NOMEMSET %s
+
 void PR13497() {
   char content[2];
   // make sure we don't optimize this call to strcpy()


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

r306786 - Remove Clang support for '-fvectorize-slp-aggressive' which used LLVM's

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Thu Jun 29 22:13:31 2017
New Revision: 306786

URL: http://llvm.org/viewvc/llvm-project?rev=306786=rev
Log:
Remove Clang support for '-fvectorize-slp-aggressive' which used LLVM's
basic block vectorizer. This vectorizer has had no known users for many,
many years and is completely surpassed by the normal
'-fvectorize-slp'-controlled SLP vectorizer in LLVM.

Hal proposed this back in 2014 to no objections:
http://lists.llvm.org/pipermail/llvm-dev/2014-November/079091.html

While this patch completely removes the flag, Joerg is working on
a patch that will add it back in a way that warns users and ignores the
flag in a clear and well factored way (so that we can keep doing this
going forward).

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

Modified:
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Driver/clang_f_opts.c

Modified: cfe/trunk/include/clang/Driver/CC1Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=306786=306785=306786=diff
==
--- cfe/trunk/include/clang/Driver/CC1Options.td (original)
+++ cfe/trunk/include/clang/Driver/CC1Options.td Thu Jun 29 22:13:31 2017
@@ -268,8 +268,6 @@ def vectorize_loops : Flag<["-"], "vecto
   HelpText<"Run the Loop vectorization passes">;
 def vectorize_slp : Flag<["-"], "vectorize-slp">,
   HelpText<"Run the SLP vectorization passes">;
-def vectorize_slp_aggressive : Flag<["-"], "vectorize-slp-aggressive">,
-  HelpText<"Run the BB vectorization passes">;
 def dependent_lib : Joined<["--"], "dependent-lib=">,
   HelpText<"Add dependent library">;
 def linker_option : Joined<["--"], "linker-option=">,

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=306786=306785=306786=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Thu Jun 29 22:13:31 2017
@@ -1405,9 +1405,6 @@ def : Flag<["-"], "fno-tree-vectorize">,
 def fslp_vectorize : Flag<["-"], "fslp-vectorize">, Group,
   HelpText<"Enable the superword-level parallelism vectorization passes">;
 def fno_slp_vectorize : Flag<["-"], "fno-slp-vectorize">, Group;
-def fslp_vectorize_aggressive : Flag<["-"], "fslp-vectorize-aggressive">, 
Group,
-  HelpText<"Enable the BB vectorization passes">;
-def fno_slp_vectorize_aggressive : Flag<["-"], 
"fno-slp-vectorize-aggressive">, Group;
 def : Flag<["-"], "ftree-slp-vectorize">, Alias;
 def : Flag<["-"], "fno-tree-slp-vectorize">, Alias;
 def Wlarge_by_value_copy_def : Flag<["-"], "Wlarge-by-value-copy">,

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=306786=306785=306786=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Thu Jun 29 22:13:31 2017
@@ -179,7 +179,6 @@ CODEGENOPT(RerollLoops   , 1, 0) ///
 CODEGENOPT(NoUseJumpTables   , 1, 0) ///< Set when -fno-jump-tables is enabled.
 CODEGENOPT(UnsafeFPMath  , 1, 0) ///< Allow unsafe floating point optzns.
 CODEGENOPT(UnwindTables  , 1, 0) ///< Emit unwind tables.
-CODEGENOPT(VectorizeBB   , 1, 0) ///< Run basic block vectorizer.
 CODEGENOPT(VectorizeLoop , 1, 0) ///< Run loop vectorizer.
 CODEGENOPT(VectorizeSLP  , 1, 0) ///< Run SLP vectorizer.
 

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=306786=306785=306786=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Thu Jun 29 22:13:31 2017
@@ -492,7 +492,6 @@ void EmitAssemblyHelper::CreatePasses(le
 
   PMBuilder.OptLevel = CodeGenOpts.OptimizationLevel;
   PMBuilder.SizeLevel = CodeGenOpts.OptimizeSize;
-  PMBuilder.BBVectorize = CodeGenOpts.VectorizeBB;
   PMBuilder.SLPVectorize = CodeGenOpts.VectorizeSLP;
   PMBuilder.LoopVectorize = CodeGenOpts.VectorizeLoop;
 

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=306786=306785=306786=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Thu Jun 29 22:13:31 2017
@@ -4127,11 

r306759 - [clang-format] Switch to case-insensitive header matching and use it to

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Thu Jun 29 16:20:54 2017
New Revision: 306759

URL: http://llvm.org/viewvc/llvm-project?rev=306759=rev
Log:
[clang-format] Switch to case-insensitive header matching and use it to
improve support for LLVM-style include sorting.

This really is a collection of improvements to the rules for LLVM
include sorting:
- We have gmock headers now, so it adds support for those to one of the
  categories.
- LLVM does use 'FooTest.cpp' files to test 'Foo.h' so it adds that
  suffix for finding a main header.
- At times the test file's case may not match the header file's case, so
  switch to case-insensitive regex matching of header names.

With this set of changes, I can't spot any misbehaviors when re-sorting
all of LLVM's unittest '#include' lines.

Thanks to Eric and Daniel for help testing and refining the patch during
review!

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

Modified:
cfe/trunk/include/clang/Format/Format.h
cfe/trunk/lib/Format/Format.cpp
cfe/trunk/unittests/Format/SortIncludesTest.cpp

Modified: cfe/trunk/include/clang/Format/Format.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Format/Format.h?rev=306759=306758=306759=diff
==
--- cfe/trunk/include/clang/Format/Format.h (original)
+++ cfe/trunk/include/clang/Format/Format.h Thu Jun 29 16:20:54 2017
@@ -966,7 +966,7 @@ struct FormatStyle {
   ///   IncludeCategories:
   /// - Regex:   '^"(llvm|llvm-c|clang|clang-c)/'
   ///   Priority:2
-  /// - Regex:   '^(<|"(gtest|isl|json)/)'
+  /// - Regex:   '^(<|"(gtest|gmock|isl|json)/)'
   ///   Priority:3
   /// - Regex:   '.*'
   ///   Priority:1

Modified: cfe/trunk/lib/Format/Format.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Format/Format.cpp?rev=306759=306758=306759=diff
==
--- cfe/trunk/lib/Format/Format.cpp (original)
+++ cfe/trunk/lib/Format/Format.cpp Thu Jun 29 16:20:54 2017
@@ -579,9 +579,9 @@ FormatStyle getLLVMStyle() {
   LLVMStyle.ForEachMacros.push_back("Q_FOREACH");
   LLVMStyle.ForEachMacros.push_back("BOOST_FOREACH");
   LLVMStyle.IncludeCategories = {{"^\"(llvm|llvm-c|clang|clang-c)/", 2},
- {"^(<|\"(gtest|isl|json)/)", 3},
+ {"^(<|\"(gtest|gmock|isl|json)/)", 3},
  {".*", 1}};
-  LLVMStyle.IncludeIsMainRegex = "$";
+  LLVMStyle.IncludeIsMainRegex = "(Test)?$";
   LLVMStyle.IndentCaseLabels = false;
   LLVMStyle.IndentWrappedFunctionNames = false;
   LLVMStyle.IndentWidth = 2;
@@ -1409,7 +1409,7 @@ public:
   : Style(Style), FileName(FileName) {
 FileStem = llvm::sys::path::stem(FileName);
 for (const auto  : Style.IncludeCategories)
-  CategoryRegexs.emplace_back(Category.Regex);
+  CategoryRegexs.emplace_back(Category.Regex, llvm::Regex::IgnoreCase);
 IsMainFile = FileName.endswith(".c") || FileName.endswith(".cc") ||
  FileName.endswith(".cpp") || FileName.endswith(".c++") ||
  FileName.endswith(".cxx") || FileName.endswith(".m") ||
@@ -1437,9 +1437,11 @@ private:
   return false;
 StringRef HeaderStem =
 llvm::sys::path::stem(IncludeName.drop_front(1).drop_back(1));
-if (FileStem.startswith(HeaderStem)) {
+if (FileStem.startswith(HeaderStem) ||
+FileStem.startswith_lower(HeaderStem)) {
   llvm::Regex MainIncludeRegex(
-  (HeaderStem + Style.IncludeIsMainRegex).str());
+  (HeaderStem + Style.IncludeIsMainRegex).str(),
+  llvm::Regex::IgnoreCase);
   if (MainIncludeRegex.match(FileStem))
 return true;
 }

Modified: cfe/trunk/unittests/Format/SortIncludesTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/Format/SortIncludesTest.cpp?rev=306759=306758=306759=diff
==
--- cfe/trunk/unittests/Format/SortIncludesTest.cpp (original)
+++ cfe/trunk/unittests/Format/SortIncludesTest.cpp Thu Jun 29 16:20:54 2017
@@ -266,6 +266,29 @@ TEST_F(SortIncludesTest, LeavesMainHeade
  "a.cc"));
 }
 
+TEST_F(SortIncludesTest, SupportCaseInsensitiveMatching) {
+  // Setup an regex for main includes so we can cover those as well.
+  Style.IncludeIsMainRegex = "([-_](test|unittest))?$";
+
+  // Ensure both main header detection and grouping work in a case insensitive
+  // manner.
+  EXPECT_EQ("#include \"llvm/A.h\"\n"
+"#include \"b.h\"\n"
+"#include \"c.h\"\n"
+"#include \"LLVM/z.h\"\n"
+"#include \"llvm/X.h\"\n"
+"#include \"GTest/GTest.h\"\n"
+"#include \"gmock/gmock.h\"\n",
+sort("#include \"c.h\"\n"
+ "#include \"b.h\"\n"
+ "#include 

Re: [PATCH] D34728: [ThinkLTO] Invoke build(Thin)?LTOPreLinkDefaultPipeline.

[Chandler Carruth via cfe-commits]

Sorry, email misfire...

On Thu, Jun 29, 2017 at 4:15 PM Chandler Carruth via Phabricator via
llvm-commits  wrote:

> chandlerc added a comment.
>
> Already said LGTM, please go ahead and submit. If tehre are further
> requsets, we can always amke follow-up changes.
>
>
> Repository:
>   rL LLVM
>
> https://reviews.llvm.org/D34728
>
>
>
> ___
> llvm-commits mailing list
> llvm-comm...@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D33467: Fix LLVM build errors if necent build of GCC 7 is used

[Chandler Carruth via cfe-commits]

Maybe Richard would be a better one to explain what on earth is going on
here then...

On Fri, May 26, 2017 at 1:51 AM David Abdurachmanov <
david.abdurachma...@gmail.com> wrote:

> Just reminder that this is in C++1z (C++17) mode, which I doubt is being
> widely used at this point.
>
> I was a change a few months ago that caused it, but cannot recall exact
> commit in GCC.
>
> david
>
> On 26 May 2017, at 10:43, Chandler Carruth  wrote:
>
> I kind of think this may be a GCC bug. It is quite strange that no one
> else has reported it, and that you're only seeing it in this context. We
> have many std::string flags and they are used in this way pretty commonly.
>
> I'm not seeing this with any other GCC-hosted build bot either, including
> a PPC one here: http://lab.llvm.org:8011/builders/clang-ppc64le-linux
>
> On Fri, May 26, 2017 at 1:34 AM David Abdurachmanov via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> davidlt added a comment.
>>
>> This happens with recent GCC 7.1.1 (updated yesterday) and if compiled in
>> C++1z mode.
>>
>>   FAILED:
>> /home/davidlt/root_patch_check/a/slc7_ppc64le_gcc700/external/gcc/7.0.0-njopjo2/bin/g++
>>  -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
>> -Iinterpreter/llvm/src/lib/Transforms/Instrumentation
>> -I/home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/lib/Transforms/Instrumentation
>> -Iinterpreter/llvm/src/include
>> -I/home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include
>> -D__ROOFIT_NOBANNER -Wno-implicit-fallthrough -Wno-noexcept-type -pipe
>>  -Wshadow -Wall -W -Woverloaded-virtual -fsigned-char -fPIC -pthread
>> -std=c++1z -fvisibility=hidden -fPIC -fvisibility-inlines-hidden -w
>> -Werror=date-time -std=c++1z -ffunction-sections -fdata-sections -O2
>> -DNDEBUG-fno-exceptions -fno-rtti -MD -MT
>> interpreter/llvm/src/lib/Transforms/Instrumentation/CMakeFiles/LLVMInstrumentation.dir/PGOInstrumentation.cpp.o
>> -MF
>> interpreter/llvm/src/lib/Transforms/Instrumentation/CMakeFiles/LLVMInstrumentation.dir/PGOInstrumentation.cpp.o.d
>> -o
>> interpreter/llvm/src/lib/Transforms/Instrumentation/CMakeFiles/LLVMInstrumentation.dir/PGOInstrumentation.cpp.o
>> -c
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
>>
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/lib/Transforms/Instrumentation/PGOInstrumentation.cpp:
>> In constructor
>> '{anonymous}::PGOInstrumentationUseLegacyPass::PGOInstrumentationUseLegacyPass(std::string)':
>>
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/lib/Transforms/Instrumentation/PGOInstrumentation.cpp:155:25:
>> error: 'llvm::cl::opt::opt(const
>> llvm::cl::opt&) [with DataType =
>> std::basic_string; bool ExternalStorage = false; ParserClass =
>> llvm::cl::parser]' is private within this context
>>  ProfileFileName = PGOTestProfileFile;
>>^~
>>   In file included from
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/Support/Options.h:41:0,
>>from
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/LLVMContext.h:19,
>>from
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/Metadata.h:26,
>>from
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/TrackingMDRef.h:17,
>>from
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/DebugLoc.h:18,
>>from
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/Instruction.h:20,
>>from
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/BasicBlock.h:19,
>>from
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/Function.h:24,
>>from
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/PassManager.h:44,
>>from
>> 

Re: [PATCH] D33467: Fix LLVM build errors if necent build of GCC 7 is used

[Chandler Carruth via cfe-commits]

I kind of think this may be a GCC bug. It is quite strange that no one else
has reported it, and that you're only seeing it in this context. We have
many std::string flags and they are used in this way pretty commonly.

I'm not seeing this with any other GCC-hosted build bot either, including a
PPC one here: http://lab.llvm.org:8011/builders/clang-ppc64le-linux

On Fri, May 26, 2017 at 1:34 AM David Abdurachmanov via Phabricator <
revi...@reviews.llvm.org> wrote:

> davidlt added a comment.
>
> This happens with recent GCC 7.1.1 (updated yesterday) and if compiled in
> C++1z mode.
>
>   FAILED:
> /home/davidlt/root_patch_check/a/slc7_ppc64le_gcc700/external/gcc/7.0.0-njopjo2/bin/g++
>  -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> -Iinterpreter/llvm/src/lib/Transforms/Instrumentation
> -I/home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/lib/Transforms/Instrumentation
> -Iinterpreter/llvm/src/include
> -I/home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include
> -D__ROOFIT_NOBANNER -Wno-implicit-fallthrough -Wno-noexcept-type -pipe
>  -Wshadow -Wall -W -Woverloaded-virtual -fsigned-char -fPIC -pthread
> -std=c++1z -fvisibility=hidden -fPIC -fvisibility-inlines-hidden -w
> -Werror=date-time -std=c++1z -ffunction-sections -fdata-sections -O2
> -DNDEBUG-fno-exceptions -fno-rtti -MD -MT
> interpreter/llvm/src/lib/Transforms/Instrumentation/CMakeFiles/LLVMInstrumentation.dir/PGOInstrumentation.cpp.o
> -MF
> interpreter/llvm/src/lib/Transforms/Instrumentation/CMakeFiles/LLVMInstrumentation.dir/PGOInstrumentation.cpp.o.d
> -o
> interpreter/llvm/src/lib/Transforms/Instrumentation/CMakeFiles/LLVMInstrumentation.dir/PGOInstrumentation.cpp.o
> -c
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
>
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/lib/Transforms/Instrumentation/PGOInstrumentation.cpp:
> In constructor
> '{anonymous}::PGOInstrumentationUseLegacyPass::PGOInstrumentationUseLegacyPass(std::string)':
>
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/lib/Transforms/Instrumentation/PGOInstrumentation.cpp:155:25:
> error: 'llvm::cl::opt::opt(const
> llvm::cl::opt&) [with DataType =
> std::basic_string; bool ExternalStorage = false; ParserClass =
> llvm::cl::parser]' is private within this context
>  ProfileFileName = PGOTestProfileFile;
>^~
>   In file included from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/Support/Options.h:41:0,
>from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/LLVMContext.h:19,
>from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/Metadata.h:26,
>from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/TrackingMDRef.h:17,
>from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/DebugLoc.h:18,
>from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/Instruction.h:20,
>from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/BasicBlock.h:19,
>from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/Function.h:24,
>from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/PassManager.h:44,
>from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/Transforms/PGOInstrumentation.h:17,
>from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/lib/Transforms/Instrumentation/PGOInstrumentation.cpp:51:
>
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/Support/CommandLine.h:1296:3:
> note: declared private here
>  opt(const opt &) = 

Re: r300650 - [modules] Properly look up the owning module for an instantiation of a merged template.

[Chandler Carruth via cfe-commits]

Reverted in r300658.

On Tue, Apr 18, 2017 at 8:30 PM Chandler Carruth 
wrote:

> Consider code like the following:
>
> ```
> #include 
>
> template 
> class MyAllocator : public std::allocator {
>  public:
>   typedef std::allocator Alloc;
>   typedef typename Alloc::pointer pointer;
>   typedef typename Alloc::size_type size_type;
>
>   MyAllocator() {}
>
>   template 
>   MyAllocator(const MyAllocator& x) : Alloc(x) {}
>
>   pointer allocate(size_type n,
>std::allocator::const_pointer /*hint*/ = nullptr)
> {
> void* p = malloc(n * sizeof(T));
> return static_cast(p);
>   }
>
>   void deallocate(pointer p, size_type) { free(p); }
>
>   template 
>   struct rebind {
> typedef MyAllocator other;
>   };
>
>  private:
>   template 
>   friend class MyAllocator;
> };
>
> std::shared_ptr x = std::allocate_shared(MyAllocator(), 0);
> ```
>
> This will fail to compile against libstdc++ 4.9's alloc_traits.h, when
> that header comes from a module, with an error message along the lines of:
> .../bits/alloc_traits.h:197:2: error: too few template arguments for class
> template '__alloctr_rebind'
> using rebind_alloc = typename __alloctr_rebind<_Alloc,
> _Tp>::__type;
>
> I think this is enough for you to debug, but let me know if not. I'm going
> to revert this temporarily to unbreak our modules builds using this version
> of libstdc++.
>
> On Tue, Apr 18, 2017 at 8:14 PM Chandler Carruth 
> wrote:
>
>> This appears to break a pretty straightforward use of things like
>> libstdc++'s __alloctr_rebind (undefined template with a default argument,
>> specializations, etc):
>>
>> https://github.com/gcc-mirror/gcc/blob/gcc-4_9-branch/libstdc++-v3/include/bits/alloc_traits.h#L58-L73
>>
>> At least, I'm getting errors from this. I'm working on a test case, but
>> as usual, the test case may be... large.
>>
>> On Tue, Apr 18, 2017 at 6:49 PM Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: rsmith
>>> Date: Tue Apr 18 20:36:43 2017
>>> New Revision: 300650
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=300650=rev
>>> Log:
>>> [modules] Properly look up the owning module for an instantiation of a
>>> merged template.
>>>
>>> When looking for the template instantiation pattern of a templated
>>> entity,
>>> consistently select the definition of the pattern if there is one. This
>>> means
>>> we'll pick the same owning module when we start instantiating a template
>>> that
>>> we'll later pick when determining which modules are visible during that
>>> instantiation.
>>>
>>> Modified:
>>> cfe/trunk/lib/AST/Decl.cpp
>>> cfe/trunk/lib/AST/DeclCXX.cpp
>>> cfe/trunk/lib/Sema/SemaLookup.cpp
>>> cfe/trunk/test/Modules/Inputs/template-default-args/a.h
>>> cfe/trunk/test/Modules/template-default-args.cpp
>>>
>>> Modified: cfe/trunk/lib/AST/Decl.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Decl.cpp?rev=300650=300649=300650=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/AST/Decl.cpp (original)
>>> +++ cfe/trunk/lib/AST/Decl.cpp Tue Apr 18 20:36:43 2017
>>> @@ -2251,6 +2251,13 @@ bool VarDecl::checkInitIsICE() const {
>>>return Eval->IsICE;
>>>  }
>>>
>>> +template
>>> +static DeclT *getDefinitionOrSelf(DeclT *D) {
>>> +  if (auto *Def = D->getDefinition())
>>> +return Def;
>>> +  return D;
>>> +}
>>> +
>>>  VarDecl *VarDecl::getTemplateInstantiationPattern() const {
>>>// If it's a variable template specialization, find the template or
>>> partial
>>>// specialization from which it was instantiated.
>>> @@ -2262,7 +2269,7 @@ VarDecl *VarDecl::getTemplateInstantiati
>>>break;
>>>  VTD = NewVTD;
>>>}
>>> -  return VTD->getTemplatedDecl()->getDefinition();
>>> +  return getDefinitionOrSelf(VTD->getTemplatedDecl());
>>>  }
>>>  if (auto *VTPSD =
>>>  From.dyn_cast()) {
>>> @@ -2271,7 +2278,7 @@ VarDecl *VarDecl::getTemplateInstantiati
>>>break;
>>>  VTPSD = NewVTPSD;
>>>}
>>> -  return VTPSD->getDefinition();
>>> +  return getDefinitionOrSelf(VTPSD);
>>>  }
>>>}
>>>
>>> @@ -2280,23 +2287,18 @@ VarDecl *VarDecl::getTemplateInstantiati
>>>VarDecl *VD = getInstantiatedFromStaticDataMember();
>>>while (auto *NewVD = VD->getInstantiatedFromStaticDataMember())
>>>  VD = NewVD;
>>> -  return VD->getDefinition();
>>> +  return getDefinitionOrSelf(VD);
>>>  }
>>>}
>>>
>>>if (VarTemplateDecl *VarTemplate = getDescribedVarTemplate()) {
>>> -
>>>  while (VarTemplate->getInstantiatedFromMemberTemplate()) {
>>>if (VarTemplate->isMemberSpecialization())
>>>  break;
>>>VarTemplate = VarTemplate->getInstantiatedFromMemberTemplate();
>>>  }
>>>
>>> -assert((!VarTemplate->getTemplatedDecl() ||
>>> -

r300659 - Revert r300653 and r300650. The underlying commit fixes one issue with

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Wed Apr 19 00:25:13 2017
New Revision: 300659

URL: http://llvm.org/viewvc/llvm-project?rev=300659=rev
Log:
Revert r300653 and r300650. The underlying commit fixes one issue with
modules but exposes much more widespread issues. Example and more
information is on the review thread for r300650.

Original commit summary:
[modules] Properly look up the owning module for an instantiation of a merged 
template.

Modified:
cfe/trunk/lib/AST/Decl.cpp
cfe/trunk/lib/AST/DeclCXX.cpp
cfe/trunk/lib/Sema/SemaLookup.cpp
cfe/trunk/test/Modules/Inputs/template-default-args/a.h
cfe/trunk/test/Modules/template-default-args.cpp

Modified: cfe/trunk/lib/AST/Decl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Decl.cpp?rev=300659=300658=300659=diff
==
--- cfe/trunk/lib/AST/Decl.cpp (original)
+++ cfe/trunk/lib/AST/Decl.cpp Wed Apr 19 00:25:13 2017
@@ -2251,14 +2251,6 @@ bool VarDecl::checkInitIsICE() const {
   return Eval->IsICE;
 }
 
-template
-static DeclT *getDefinitionOrSelf(DeclT *D) {
-  assert(D);
-  if (auto *Def = D->getDefinition())
-return Def;
-  return D;
-}
-
 VarDecl *VarDecl::getTemplateInstantiationPattern() const {
   // If it's a variable template specialization, find the template or partial
   // specialization from which it was instantiated.
@@ -2270,7 +2262,7 @@ VarDecl *VarDecl::getTemplateInstantiati
   break;
 VTD = NewVTD;
   }
-  return getDefinitionOrSelf(VTD->getTemplatedDecl());
+  return VTD->getTemplatedDecl()->getDefinition();
 }
 if (auto *VTPSD =
 From.dyn_cast()) {
@@ -2279,7 +2271,7 @@ VarDecl *VarDecl::getTemplateInstantiati
   break;
 VTPSD = NewVTPSD;
   }
-  return getDefinitionOrSelf(VTPSD);
+  return VTPSD->getDefinition();
 }
   }
 
@@ -2288,18 +2280,23 @@ VarDecl *VarDecl::getTemplateInstantiati
   VarDecl *VD = getInstantiatedFromStaticDataMember();
   while (auto *NewVD = VD->getInstantiatedFromStaticDataMember())
 VD = NewVD;
-  return getDefinitionOrSelf(VD);
+  return VD->getDefinition();
 }
   }
 
   if (VarTemplateDecl *VarTemplate = getDescribedVarTemplate()) {
+
 while (VarTemplate->getInstantiatedFromMemberTemplate()) {
   if (VarTemplate->isMemberSpecialization())
 break;
   VarTemplate = VarTemplate->getInstantiatedFromMemberTemplate();
 }
 
-return getDefinitionOrSelf(VarTemplate->getTemplatedDecl());
+assert((!VarTemplate->getTemplatedDecl() ||
+!isTemplateInstantiation(getTemplateSpecializationKind())) &&
+   "couldn't find pattern for variable instantiation");
+
+return VarTemplate->getTemplatedDecl();
   }
   return nullptr;
 }
@@ -3203,12 +3200,9 @@ bool FunctionDecl::isTemplateInstantiati

 FunctionDecl *FunctionDecl::getTemplateInstantiationPattern() const {
   // Handle class scope explicit specialization special case.
-  if (getTemplateSpecializationKind() == TSK_ExplicitSpecialization) {
-if (auto *Spec = getClassScopeSpecializationPattern())
-  return getDefinitionOrSelf(Spec);
-return nullptr;
-  }
-
+  if (getTemplateSpecializationKind() == TSK_ExplicitSpecialization)
+return getClassScopeSpecializationPattern();
+  
   // If this is a generic lambda call operator specialization, its 
   // instantiation pattern is always its primary template's pattern
   // even if its primary template was instantiated from another 
@@ -3220,10 +3214,16 @@ FunctionDecl *FunctionDecl::getTemplateI
 
   if (isGenericLambdaCallOperatorSpecialization(
   dyn_cast(this))) {
-assert(getPrimaryTemplate() && "not a generic lambda call operator?");
-return getDefinitionOrSelf(getPrimaryTemplate()->getTemplatedDecl());
+assert(getPrimaryTemplate() && "A generic lambda specialization must be "
+   "generated from a primary call operator "
+   "template");
+assert(getPrimaryTemplate()->getTemplatedDecl()->getBody() &&
+   "A generic lambda call operator template must always have a body - "
+   "even if instantiated from a prototype (i.e. as written) member "
+   "template");
+return getPrimaryTemplate()->getTemplatedDecl();
   }
-
+  
   if (FunctionTemplateDecl *Primary = getPrimaryTemplate()) {
 while (Primary->getInstantiatedFromMemberTemplate()) {
   // If we have hit a point where the user provided a specialization of
@@ -3232,14 +3232,11 @@ FunctionDecl *FunctionDecl::getTemplateI
 break;
   Primary = Primary->getInstantiatedFromMemberTemplate();
 }
-
-return getDefinitionOrSelf(Primary->getTemplatedDecl());
+
+return Primary->getTemplatedDecl();
   } 
-
-  if (auto *MFD = getInstantiatedFromMemberFunction())
-return getDefinitionOrSelf(MFD);
-
-  return nullptr;
+
+  return 

Re: r300650 - [modules] Properly look up the owning module for an instantiation of a merged template.

[Chandler Carruth via cfe-commits]

Consider code like the following:

```
#include 

template 
class MyAllocator : public std::allocator {
 public:
  typedef std::allocator Alloc;
  typedef typename Alloc::pointer pointer;
  typedef typename Alloc::size_type size_type;

  MyAllocator() {}

  template 
  MyAllocator(const MyAllocator& x) : Alloc(x) {}

  pointer allocate(size_type n,
   std::allocator::const_pointer /*hint*/ = nullptr) {
void* p = malloc(n * sizeof(T));
return static_cast(p);
  }

  void deallocate(pointer p, size_type) { free(p); }

  template 
  struct rebind {
typedef MyAllocator other;
  };

 private:
  template 
  friend class MyAllocator;
};

std::shared_ptr x = std::allocate_shared(MyAllocator(), 0);
```

This will fail to compile against libstdc++ 4.9's alloc_traits.h, when that
header comes from a module, with an error message along the lines of:
.../bits/alloc_traits.h:197:2: error: too few template arguments for class
template '__alloctr_rebind'
using rebind_alloc = typename __alloctr_rebind<_Alloc, _Tp>::__type;

I think this is enough for you to debug, but let me know if not. I'm going
to revert this temporarily to unbreak our modules builds using this version
of libstdc++.

On Tue, Apr 18, 2017 at 8:14 PM Chandler Carruth 
wrote:

> This appears to break a pretty straightforward use of things like
> libstdc++'s __alloctr_rebind (undefined template with a default argument,
> specializations, etc):
>
> https://github.com/gcc-mirror/gcc/blob/gcc-4_9-branch/libstdc++-v3/include/bits/alloc_traits.h#L58-L73
>
> At least, I'm getting errors from this. I'm working on a test case, but as
> usual, the test case may be... large.
>
> On Tue, Apr 18, 2017 at 6:49 PM Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: rsmith
>> Date: Tue Apr 18 20:36:43 2017
>> New Revision: 300650
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=300650=rev
>> Log:
>> [modules] Properly look up the owning module for an instantiation of a
>> merged template.
>>
>> When looking for the template instantiation pattern of a templated entity,
>> consistently select the definition of the pattern if there is one. This
>> means
>> we'll pick the same owning module when we start instantiating a template
>> that
>> we'll later pick when determining which modules are visible during that
>> instantiation.
>>
>> Modified:
>> cfe/trunk/lib/AST/Decl.cpp
>> cfe/trunk/lib/AST/DeclCXX.cpp
>> cfe/trunk/lib/Sema/SemaLookup.cpp
>> cfe/trunk/test/Modules/Inputs/template-default-args/a.h
>> cfe/trunk/test/Modules/template-default-args.cpp
>>
>> Modified: cfe/trunk/lib/AST/Decl.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Decl.cpp?rev=300650=300649=300650=diff
>>
>> ==
>> --- cfe/trunk/lib/AST/Decl.cpp (original)
>> +++ cfe/trunk/lib/AST/Decl.cpp Tue Apr 18 20:36:43 2017
>> @@ -2251,6 +2251,13 @@ bool VarDecl::checkInitIsICE() const {
>>return Eval->IsICE;
>>  }
>>
>> +template
>> +static DeclT *getDefinitionOrSelf(DeclT *D) {
>> +  if (auto *Def = D->getDefinition())
>> +return Def;
>> +  return D;
>> +}
>> +
>>  VarDecl *VarDecl::getTemplateInstantiationPattern() const {
>>// If it's a variable template specialization, find the template or
>> partial
>>// specialization from which it was instantiated.
>> @@ -2262,7 +2269,7 @@ VarDecl *VarDecl::getTemplateInstantiati
>>break;
>>  VTD = NewVTD;
>>}
>> -  return VTD->getTemplatedDecl()->getDefinition();
>> +  return getDefinitionOrSelf(VTD->getTemplatedDecl());
>>  }
>>  if (auto *VTPSD =
>>  From.dyn_cast()) {
>> @@ -2271,7 +2278,7 @@ VarDecl *VarDecl::getTemplateInstantiati
>>break;
>>  VTPSD = NewVTPSD;
>>}
>> -  return VTPSD->getDefinition();
>> +  return getDefinitionOrSelf(VTPSD);
>>  }
>>}
>>
>> @@ -2280,23 +2287,18 @@ VarDecl *VarDecl::getTemplateInstantiati
>>VarDecl *VD = getInstantiatedFromStaticDataMember();
>>while (auto *NewVD = VD->getInstantiatedFromStaticDataMember())
>>  VD = NewVD;
>> -  return VD->getDefinition();
>> +  return getDefinitionOrSelf(VD);
>>  }
>>}
>>
>>if (VarTemplateDecl *VarTemplate = getDescribedVarTemplate()) {
>> -
>>  while (VarTemplate->getInstantiatedFromMemberTemplate()) {
>>if (VarTemplate->isMemberSpecialization())
>>  break;
>>VarTemplate = VarTemplate->getInstantiatedFromMemberTemplate();
>>  }
>>
>> -assert((!VarTemplate->getTemplatedDecl() ||
>> -!isTemplateInstantiation(getTemplateSpecializationKind())) &&
>> -   "couldn't find pattern for variable instantiation");
>> -
>> -return VarTemplate->getTemplatedDecl();
>> +return getDefinitionOrSelf(VarTemplate->getTemplatedDecl());
>>}
>>return nullptr;
>>  }
>> @@ -3201,7 +3203,7 @@ bool 

Re: r300650 - [modules] Properly look up the owning module for an instantiation of a merged template.

[Chandler Carruth via cfe-commits]

This appears to break a pretty straightforward use of things like
libstdc++'s __alloctr_rebind (undefined template with a default argument,
specializations, etc):
https://github.com/gcc-mirror/gcc/blob/gcc-4_9-branch/libstdc++-v3/include/bits/alloc_traits.h#L58-L73

At least, I'm getting errors from this. I'm working on a test case, but as
usual, the test case may be... large.

On Tue, Apr 18, 2017 at 6:49 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Tue Apr 18 20:36:43 2017
> New Revision: 300650
>
> URL: http://llvm.org/viewvc/llvm-project?rev=300650=rev
> Log:
> [modules] Properly look up the owning module for an instantiation of a
> merged template.
>
> When looking for the template instantiation pattern of a templated entity,
> consistently select the definition of the pattern if there is one. This
> means
> we'll pick the same owning module when we start instantiating a template
> that
> we'll later pick when determining which modules are visible during that
> instantiation.
>
> Modified:
> cfe/trunk/lib/AST/Decl.cpp
> cfe/trunk/lib/AST/DeclCXX.cpp
> cfe/trunk/lib/Sema/SemaLookup.cpp
> cfe/trunk/test/Modules/Inputs/template-default-args/a.h
> cfe/trunk/test/Modules/template-default-args.cpp
>
> Modified: cfe/trunk/lib/AST/Decl.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Decl.cpp?rev=300650=300649=300650=diff
>
> ==
> --- cfe/trunk/lib/AST/Decl.cpp (original)
> +++ cfe/trunk/lib/AST/Decl.cpp Tue Apr 18 20:36:43 2017
> @@ -2251,6 +2251,13 @@ bool VarDecl::checkInitIsICE() const {
>return Eval->IsICE;
>  }
>
> +template
> +static DeclT *getDefinitionOrSelf(DeclT *D) {
> +  if (auto *Def = D->getDefinition())
> +return Def;
> +  return D;
> +}
> +
>  VarDecl *VarDecl::getTemplateInstantiationPattern() const {
>// If it's a variable template specialization, find the template or
> partial
>// specialization from which it was instantiated.
> @@ -2262,7 +2269,7 @@ VarDecl *VarDecl::getTemplateInstantiati
>break;
>  VTD = NewVTD;
>}
> -  return VTD->getTemplatedDecl()->getDefinition();
> +  return getDefinitionOrSelf(VTD->getTemplatedDecl());
>  }
>  if (auto *VTPSD =
>  From.dyn_cast()) {
> @@ -2271,7 +2278,7 @@ VarDecl *VarDecl::getTemplateInstantiati
>break;
>  VTPSD = NewVTPSD;
>}
> -  return VTPSD->getDefinition();
> +  return getDefinitionOrSelf(VTPSD);
>  }
>}
>
> @@ -2280,23 +2287,18 @@ VarDecl *VarDecl::getTemplateInstantiati
>VarDecl *VD = getInstantiatedFromStaticDataMember();
>while (auto *NewVD = VD->getInstantiatedFromStaticDataMember())
>  VD = NewVD;
> -  return VD->getDefinition();
> +  return getDefinitionOrSelf(VD);
>  }
>}
>
>if (VarTemplateDecl *VarTemplate = getDescribedVarTemplate()) {
> -
>  while (VarTemplate->getInstantiatedFromMemberTemplate()) {
>if (VarTemplate->isMemberSpecialization())
>  break;
>VarTemplate = VarTemplate->getInstantiatedFromMemberTemplate();
>  }
>
> -assert((!VarTemplate->getTemplatedDecl() ||
> -!isTemplateInstantiation(getTemplateSpecializationKind())) &&
> -   "couldn't find pattern for variable instantiation");
> -
> -return VarTemplate->getTemplatedDecl();
> +return getDefinitionOrSelf(VarTemplate->getTemplatedDecl());
>}
>return nullptr;
>  }
> @@ -3201,7 +3203,7 @@ bool FunctionDecl::isTemplateInstantiati
>  FunctionDecl *FunctionDecl::getTemplateInstantiationPattern() const {
>// Handle class scope explicit specialization special case.
>if (getTemplateSpecializationKind() == TSK_ExplicitSpecialization)
> -return getClassScopeSpecializationPattern();
> +return getDefinitionOrSelf(getClassScopeSpecializationPattern());
>
>// If this is a generic lambda call operator specialization, its
>// instantiation pattern is always its primary template's pattern
> @@ -3214,16 +3216,10 @@ FunctionDecl *FunctionDecl::getTemplateI
>
>if (isGenericLambdaCallOperatorSpecialization(
>dyn_cast(this))) {
> -assert(getPrimaryTemplate() && "A generic lambda specialization must
> be "
> -   "generated from a primary call
> operator "
> -   "template");
> -assert(getPrimaryTemplate()->getTemplatedDecl()->getBody() &&
> -   "A generic lambda call operator template must always have a
> body - "
> -   "even if instantiated from a prototype (i.e. as written)
> member "
> -   "template");
> -return getPrimaryTemplate()->getTemplatedDecl();
> +assert(getPrimaryTemplate() && "not a generic lambda call operator?");
> +return getDefinitionOrSelf(getPrimaryTemplate()->getTemplatedDecl());
>}
> -
> +
>if (FunctionTemplateDecl *Primary = 

r300035 - Update Clang for an API change to LLVM's switch case iterator (it is now

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Wed Apr 12 03:12:30 2017
New Revision: 300035

URL: http://llvm.org/viewvc/llvm-project?rev=300035=rev
Log:
Update Clang for an API change to LLVM's switch case iterator (it is now
an actual iterator and so we need to look through it to the case
handle).

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

Modified: cfe/trunk/lib/CodeGen/CGCleanup.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCleanup.cpp?rev=300035=300034=300035=diff
==
--- cfe/trunk/lib/CodeGen/CGCleanup.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCleanup.cpp Wed Apr 12 03:12:30 2017
@@ -609,7 +609,7 @@ static void destroyOptimisticNormalEntry
 llvm::SwitchInst *si = cast(use.getUser());
 if (si->getNumCases() == 1 && si->getDefaultDest() == unreachableBB) {
   // Replace the switch with a branch.
-  llvm::BranchInst::Create(si->case_begin().getCaseSuccessor(), si);
+  llvm::BranchInst::Create(si->case_begin()->getCaseSuccessor(), si);
 
   // The switch operand is a load from the cleanup-dest alloca.
   llvm::LoadInst *condition = cast(si->getCondition());


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

r298695 - Revert r298491 and r298494 which changed Clang's handling of 'nonnull'

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Fri Mar 24 04:11:57 2017
New Revision: 298695

URL: http://llvm.org/viewvc/llvm-project?rev=298695=rev
Log:
Revert r298491 and r298494 which changed Clang's handling of 'nonnull'
attributes.

These patches don't work because we can't currently access the parameter
information in a reliable way when building attributes. I thought this
would be relatively straightforward to fix, but it seems not to be the
case. Fixing this will requrie a substantial re-plumbing of machinery to
allow attributes to be handled in this location, and several other fixes
to the attribute machinery should probably be made at the same time. All
of this will make the patch  substantially more complicated.

Reverting for now as there are active miscompiles caused by the current
version.

Modified:
cfe/trunk/include/clang/AST/ASTContext.h
cfe/trunk/include/clang/Basic/Builtins.def
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/test/CodeGen/function-attributes.c
cfe/trunk/test/CodeGen/nonnull.c

Modified: cfe/trunk/include/clang/AST/ASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=298695=298694=298695=diff
==
--- cfe/trunk/include/clang/AST/ASTContext.h (original)
+++ cfe/trunk/include/clang/AST/ASTContext.h Fri Mar 24 04:11:57 2017
@@ -1864,9 +1864,7 @@ public:
   /// arguments to the builtin that are required to be integer constant
   /// expressions.
   QualType GetBuiltinType(unsigned ID, GetBuiltinTypeError ,
-  unsigned *IntegerConstantArgs = nullptr,
-  bool *OverrideNonnullReturn = nullptr,
-  unsigned *OverrideNonnullArgs = nullptr) const;
+  unsigned *IntegerConstantArgs = nullptr) const;
 
 private:
   CanQualType getFromTargetType(unsigned Type) const;

Modified: cfe/trunk/include/clang/Basic/Builtins.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Builtins.def?rev=298695=298694=298695=diff
==
--- cfe/trunk/include/clang/Basic/Builtins.def (original)
+++ cfe/trunk/include/clang/Basic/Builtins.def Fri Mar 24 04:11:57 2017
@@ -55,12 +55,6 @@
 //  S   -> signed
 //  U   -> unsigned
 //  I   -> Required to constant fold to an integer constant expression.
-//  N   -> Do not assume non-null for optimizations even if attributed nonnull.
-// This can be used when a relevant standard requires arguments or
-// returns to be non-null and they are attributed accordingly but in
-// practice are not used in this way. This typically used when a size
-// parameter is also provided and when zero it would be reasonable to
-// give an invalid pointer.
 //
 // Types may be postfixed with the following modifiers:
 // * -> pointer (optionally followed by an address space number, if no address
@@ -792,27 +786,27 @@ LIBBUILTIN(_Exit, "vi",   "fr",
 LIBBUILTIN(malloc, "v*z", "f", "stdlib.h", ALL_LANGUAGES)
 LIBBUILTIN(realloc, "v*v*z",  "f", "stdlib.h", ALL_LANGUAGES)
 // C99 string.h
-LIBBUILTIN(memcpy, "Nv*Nv*NvC*z",  "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(memcmp, "iNvC*NvC*z",   "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(memmove, "Nv*Nv*NvC*z", "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strcpy, "c*c*cC*",  "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strncpy, "Nc*Nc*NcC*z", "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strcmp, "icC*cC*",  "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strncmp, "iNcC*NcC*z",  "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strcat, "c*c*cC*",  "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strncat, "c*c*NcC*z",   "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strxfrm, "zc*cC*z", "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(memchr, "Nv*NvC*iz","f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strchr, "c*cC*i",   "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strcspn, "zcC*cC*", "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strpbrk, "c*cC*cC*","f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strrchr, "c*cC*i",  "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strspn, "zcC*cC*",  "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strstr, "c*cC*cC*", "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strtok, "c*c*cC*",  "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(memset, "Nv*Nv*iz", "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strerror, "c*i","f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strlen, "zcC*", "f", "string.h", ALL_LANGUAGES)
+LIBBUILTIN(memcpy, "v*v*vC*z","f", "string.h", ALL_LANGUAGES)
+LIBBUILTIN(memcmp, "ivC*vC*z","f", "string.h", ALL_LANGUAGES)
+LIBBUILTIN(memmove, "v*v*vC*z",   "f", "string.h", ALL_LANGUAGES)

r298494 - Remove an overly aggressive assert in r298491 and leave a comment

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Wed Mar 22 05:38:07 2017
New Revision: 298494

URL: http://llvm.org/viewvc/llvm-project?rev=298494=rev
Log:
Remove an overly aggressive assert in r298491 and leave a comment
explaining why we have to ignore errors here even though in other parts
of codegen we can be more strict with builtins.

Also add a test case based on the code in a TSan test that found this
issue.

Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/test/CodeGen/function-attributes.c

Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=298494=298493=298494=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Wed Mar 22 05:38:07 2017
@@ -1813,7 +1813,11 @@ void CodeGenModule::ConstructAttributeLi
 ASTContext::GetBuiltinTypeError Error;
 getContext().GetBuiltinType(BuiltinID, Error, nullptr,
 , );
-assert(Error == ASTContext::GE_None && "Should not codegen an error");
+// Note that we can't check the 'Error' here as there may be errors that
+// have been diagnosed and reported to the programmer as warnings but
+// repaired in the AST such as for implicit declarations of builtin
+// functions. None of those impact our usage of this to analyze attributes
+// for the builtins.
   }
 
   bool HasOptnone = false;

Modified: cfe/trunk/test/CodeGen/function-attributes.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/function-attributes.c?rev=298494=298493=298494=diff
==
--- cfe/trunk/test/CodeGen/function-attributes.c (original)
+++ cfe/trunk/test/CodeGen/function-attributes.c Wed Mar 22 05:38:07 2017
@@ -108,6 +108,20 @@ void f20(void) {
   _setjmp(0);
 }
 
+// Bogus declarations that will end up with bad types when detecting builtins,
+// but that we will still process when considering whether to add attributes.
+struct __jmp_buf_tag;
+extern int __sigsetjmp(struct __jmp_buf_tag *__env, int __savemask);
+
+// CHECK-LABEL: define void @f21()
+// CHECK: {
+// CHECK: call i32 @__sigsetjmp(%{{.*}}* null, i32 0)
+// CHECK: [[RT_CALL]]
+// CHECK: ret void
+void f21(void) {
+  __sigsetjmp(0, 0);
+}
+
 // CHECK: attributes [[NUW]] = { nounwind optsize{{.*}} }
 // CHECK: attributes [[AI]] = { alwaysinline nounwind optsize{{.*}} }
 // CHECK: attributes [[NUW_OS_RN]] = { nounwind optsize readnone{{.*}} }


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

r298491 - [nonnull] Teach Clang to attach the nonnull LLVM attribute to

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Wed Mar 22 04:09:13 2017
New Revision: 298491

URL: http://llvm.org/viewvc/llvm-project?rev=298491=rev
Log:
[nonnull] Teach Clang to attach the nonnull LLVM attribute to
declarations and calls instead of just definitions, and then teach it to
*not* attach such attributes even if the source code contains them.

This follows the design direction discussed on cfe-dev here:
http://lists.llvm.org/pipermail/cfe-dev/2017-January/052066.html

The idea is that for C standard library builtins, even if the library
vendor chooses to annotate their routines with __attribute__((nonnull)),
we will ignore those attributes which pertain to pointer arguments that
have an associated size. This allows the widespread (and seemingly
reasonable) pattern of calling these routines with a null pointer and
a zero size. I have only done this for the library builtins currently
recognized by Clang, but we can now trivially add to this set. This will
be controllable with -fno-builtin if anyone should care to do so.

Note that this does *not* change the AST. As a consequence, warnings,
static analysis, and source code rewriting are not impacted.

This isn't even a regression on any platform as neither Clang nor LLVM
have ever put 'nonnull' onto these arguments for declarations. All this
patch does is enable it on other declarations while preventing us from
ever accidentally enabling it on these libc functions due to a library
vendor.

It will also allow any other libraries using this annotation to gain
optimizations based on the annotation even when only a declaration is
visible.

Modified:
cfe/trunk/include/clang/AST/ASTContext.h
cfe/trunk/include/clang/Basic/Builtins.def
cfe/trunk/lib/AST/ASTContext.cpp
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/test/CodeGen/nonnull.c

Modified: cfe/trunk/include/clang/AST/ASTContext.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=298491=298490=298491=diff
==
--- cfe/trunk/include/clang/AST/ASTContext.h (original)
+++ cfe/trunk/include/clang/AST/ASTContext.h Wed Mar 22 04:09:13 2017
@@ -1864,7 +1864,9 @@ public:
   /// arguments to the builtin that are required to be integer constant
   /// expressions.
   QualType GetBuiltinType(unsigned ID, GetBuiltinTypeError ,
-  unsigned *IntegerConstantArgs = nullptr) const;
+  unsigned *IntegerConstantArgs = nullptr,
+  bool *OverrideNonnullReturn = nullptr,
+  unsigned *OverrideNonnullArgs = nullptr) const;
 
 private:
   CanQualType getFromTargetType(unsigned Type) const;

Modified: cfe/trunk/include/clang/Basic/Builtins.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Builtins.def?rev=298491=298490=298491=diff
==
--- cfe/trunk/include/clang/Basic/Builtins.def (original)
+++ cfe/trunk/include/clang/Basic/Builtins.def Wed Mar 22 04:09:13 2017
@@ -55,6 +55,12 @@
 //  S   -> signed
 //  U   -> unsigned
 //  I   -> Required to constant fold to an integer constant expression.
+//  N   -> Do not assume non-null for optimizations even if attributed nonnull.
+// This can be used when a relevant standard requires arguments or
+// returns to be non-null and they are attributed accordingly but in
+// practice are not used in this way. This typically used when a size
+// parameter is also provided and when zero it would be reasonable to
+// give an invalid pointer.
 //
 // Types may be postfixed with the following modifiers:
 // * -> pointer (optionally followed by an address space number, if no address
@@ -787,27 +793,27 @@ LIBBUILTIN(_Exit, "vi",   "fr",
 LIBBUILTIN(malloc, "v*z", "f", "stdlib.h", ALL_LANGUAGES)
 LIBBUILTIN(realloc, "v*v*z",  "f", "stdlib.h", ALL_LANGUAGES)
 // C99 string.h
-LIBBUILTIN(memcpy, "v*v*vC*z","f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(memcmp, "ivC*vC*z","f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(memmove, "v*v*vC*z",   "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strcpy, "c*c*cC*", "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strncpy, "c*c*cC*z",   "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strcmp, "icC*cC*", "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strncmp, "icC*cC*z",   "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strcat, "c*c*cC*", "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strncat, "c*c*cC*z",   "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strxfrm, "zc*cC*z","f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(memchr, "v*vC*iz", "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strchr, "c*cC*i",  "f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strcspn, "zcC*cC*","f", "string.h", ALL_LANGUAGES)
-LIBBUILTIN(strpbrk, "c*cC*cC*",   "f", 

[clang-tools-extra] r298434 - Don't make unqualified calls to functions that could well be found via

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Tue Mar 21 15:15:42 2017
New Revision: 298434

URL: http://llvm.org/viewvc/llvm-project?rev=298434=rev
Log:
Don't make unqualified calls to functions that could well be found via
ADL as reasonable extension points.

All of this would be cleaner if this code followed the more usual LLVM
convention of not having deeply nested namespaces inside of .cpp files
and instead having a `using namespace ...;` at the top. Then the static
function would be in the global namespace and easily referred to as
`::join`. Instead we have to write a fairly contrived qualified name.
I figure the authors can clean this up with a less ambiguous name, using
the newly provided LLVM `join` function, or any other solution, but this
at least fixes the build.

Modified:

clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/SpecialMemberFunctionsCheck.cpp

Modified: 
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/SpecialMemberFunctionsCheck.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/SpecialMemberFunctionsCheck.cpp?rev=298434=298433=298434=diff
==
--- 
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/SpecialMemberFunctionsCheck.cpp
 (original)
+++ 
clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/SpecialMemberFunctionsCheck.cpp
 Tue Mar 21 15:15:42 2017
@@ -182,8 +182,8 @@ void SpecialMemberFunctionsCheck::checkF
 
   if (!MissingMembers.empty())
 diag(ID.first, "class '%0' defines %1 but does not define %2")
-<< ID.second << join(DefinedMembers, " and ")
-<< join(MissingMembers, " or ");
+<< ID.second << cppcoreguidelines::join(DefinedMembers, " and ")
+<< cppcoreguidelines::join(MissingMembers, " or ");
 }
 
 } // namespace cppcoreguidelines


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

Re: [cfe-commits] r164177 - in /cfe/trunk: lib/Driver/ test/Driver/ test/Driver/Inputs/freescale_ppc_tree/ test/Driver/Inputs/freescale_ppc_tree/lib/ test/Driver/Inputs/freescale_ppc_tree/usr/ test/Dr

[Chandler Carruth via cfe-commits]

On Thu, Feb 9, 2017 at 2:46 PM Tobias von Koch 
wrote:

> On Wed, Feb 8, 2017 at 7:21 PM, Chandler Carruth 
> wrote:
>
>
> +// The Freescale PPC SDK has the gcc libraries in
> +// /usr/lib//x.y.z so have a look there as well.
> +"/" + CandidateTriple.str(),
>
>
> So, this is really bad it turns out.
>
> We use this directory to walk every installed GCC version. But because
> this is just a normal lib directory on many systems (ever Debian and Ubuntu
> system for example) this goes very badly. It goes even more badly because
> of the (questionable) design of LLVM's directory iterator:
>
>
> Wow, this is pretty bad, but it really sounds like the iterator should be
> fixed rather than trying to hack around it.
>

I mean, we should.

But even then, walking the entire directory seems bad too... See below.


> Doesn't this happen for the other directories as well (which, admittedly,
> will have less entries)?
>

The *only* entries in the other directories are the actual installed GCC
toolchains though, so walking them makes a lot of sense. The tricky thing
is that this isn't a gcc-specific directory.

I suspect the fix should be to not use this base path as part of the walk
to discover GCC toolchains, and instead to hard code the specific toolchain
patterns on this specific platform.

Or we could do the walk, but only when actually on the NXP/Freescale Power
platform where this is necessary to find GCC installations.

Both of those would seem reasonable. Fixing the directory iterator would be
icing on the cake IMO. =D
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [cfe-commits] r164177 - in /cfe/trunk: lib/Driver/ test/Driver/ test/Driver/Inputs/freescale_ppc_tree/ test/Driver/Inputs/freescale_ppc_tree/lib/ test/Driver/Inputs/freescale_ppc_tree/usr/ test/Dr

[Chandler Carruth via cfe-commits]

It's blast from the past time!

On Tue, Sep 18, 2012 at 3:28 PM Hal Finkel  wrote:

> Author: hfinkel
> Date: Tue Sep 18 17:25:07 2012
> New Revision: 164177
>
> URL: http://llvm.org/viewvc/llvm-project?rev=164177=rev
> Log:
> Add C/C++ header locations for the Freescale SDK.
>
> The Freescale SDK is based on OpenEmbedded, and this might be useful
> for other OpenEmbedded-based configurations as well.
>
> With minor modifications, patch by Tobias von Koch!
>
> Added:
> cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/
> cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/lib/
> cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/lib/.keep
> cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/usr/
> cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/usr/lib/
> cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/usr/lib/crt1.o
> cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/usr/lib/crti.o
> cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/usr/lib/crtn.o
>
> cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/usr/lib/powerpc-fsl-linux/
>
> cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/usr/lib/powerpc-fsl-linux/4.6.2/
>
> cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/usr/lib/powerpc-fsl-linux/4.6.2/crtbegin.o
>
> cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/usr/lib/powerpc-fsl-linux/4.6.2/crtend.o
> Modified:
> cfe/trunk/lib/Driver/ToolChains.cpp
> cfe/trunk/test/Driver/linux-ld.c
>
> Modified: cfe/trunk/lib/Driver/ToolChains.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains.cpp?rev=164177=164176=164177=diff
>
> ==
> --- cfe/trunk/lib/Driver/ToolChains.cpp (original)
> +++ cfe/trunk/lib/Driver/ToolChains.cpp Tue Sep 18 17:25:07 2012
> @@ -1291,6 +1291,10 @@
>  "/gcc/" + CandidateTriple.str(),
>  "/" + CandidateTriple.str() + "/gcc/" + CandidateTriple.str(),
>
> +// The Freescale PPC SDK has the gcc libraries in
> +// /usr/lib//x.y.z so have a look there as well.
> +"/" + CandidateTriple.str(),
>

So, this is really bad it turns out.

We use this directory to walk every installed GCC version. But because this
is just a normal lib directory on many systems (ever Debian and Ubuntu
system for example) this goes very badly. It goes even more badly because
of the (questionable) design of LLVM's directory iterator:

It ends up stat'ing *every single file* in /usr/lib/  =[ For
the current Ubuntu LTS for example, this causes roughly 3900 spurrious stat
syscalls for every invocation of the Clang driver.

Can we do something different here?


> +
>  // Ubuntu has a strange mis-matched pair of triples that this happens
> to
>  // match.
>  // FIXME: It may be worthwhile to generalize this and look for a
> second
> @@ -1300,6 +1304,7 @@
>const std::string InstallSuffixes[] = {
>  "/../../..",
>  "/../../../..",
> +"/../..",
>  "/../../../.."
>};
>// Only look at the final, weird Ubuntu suffix for i386-linux-gnu.
> @@ -2374,6 +2379,9 @@
>  InstallDir.str() + "/include/g++-v4",
>  // Android standalone toolchain has C++ headers in yet another place.
>  LibDir.str() + "/../" + TripleStr.str() + "/include/c++/" +
> Version.str(),
> +// Freescale SDK C++ headers are directly in
> /usr/include/c++,
> +// without a subdirectory corresponding to the gcc version.
> +LibDir.str() + "/../include/c++",
>};
>
>for (unsigned i = 0; i < llvm::array_lengthof(IncludePathCandidates);
> ++i) {
>
> Added: cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/lib/.keep
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/lib/.keep?rev=164177=auto
>
> ==
> (empty)
>
> Added: cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/usr/lib/crt1.o
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/usr/lib/crt1.o?rev=164177=auto
>
> ==
> (empty)
>
> Added: cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/usr/lib/crti.o
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/usr/lib/crti.o?rev=164177=auto
>
> ==
> (empty)
>
> Added: cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/usr/lib/crtn.o
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/usr/lib/crtn.o?rev=164177=auto
>
> ==
> (empty)
>
> Added:
> cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/usr/lib/powerpc-fsl-linux/4.6.2/crtbegin.o
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/Inputs/freescale_ppc_tree/usr/lib/powerpc-fsl-linux/4.6.2/crtbegin.o?rev=164177=auto
>
> 

Re: r290392 - Make '-disable-llvm-optzns' an alias for '-disable-llvm-passes'.

[Chandler Carruth via cfe-commits]

Also need to pull in r291881. Sorry about that.

On Thu, Jan 12, 2017 at 3:42 PM Hans Wennborg  wrote:

> On Thu, Jan 12, 2017 at 3:01 PM, Chandler Carruth 
> wrote:
> >> This isn't quite right, it should either be left as-is or dropped
> >> completely. This path was allowing people to spell "-mllvm
> >> -disable-llvm-optzns" for legacy reasons, even though the correct
> >> spelling is "-Xclang -disable-llvm-optzns". There's no need to add
> >> legacy support for "-mllvm -disable-llvm-passes", since that never
> >> worked.
> >
> >
> > Yeah, I don't think this was even really intended.
> >
> > r291850+r291853 fix this to preserve -disable-llvm-optzns exactly as it
> was.
> >
> > I've alse followed up with Hans to make sure LLVM 4 gets this.
>
> Merged in r291860.
>
> Cheers,
> Hans
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r291881 - Another fix for r291850 because there are apparently targets which add

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Thu Jan 12 20:47:34 2017
New Revision: 291881

URL: http://llvm.org/viewvc/llvm-project?rev=291881=rev
Log:
Another fix for r291850 because there are apparently targets which add
"-mllvm" flags to the CC1 invocation (notably, Hexagon seems to hit
this).

Modified:
cfe/trunk/test/Driver/disable-llvm.c

Modified: cfe/trunk/test/Driver/disable-llvm.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/disable-llvm.c?rev=291881=291880=291881=diff
==
--- cfe/trunk/test/Driver/disable-llvm.c (original)
+++ cfe/trunk/test/Driver/disable-llvm.c Thu Jan 12 20:47:34 2017
@@ -2,8 +2,8 @@
 // RUN: %clang -O2 -Xclang -disable-llvm-passes -### %s 2>&1 \
 // RUN: | FileCheck --check-prefix=DISABLED %s
 // DISABLED: -cc1
-// DISABLED-NOT: -mllvm
-// DISABLED: -disable-llvm-passes
+// DISABLED-NOT: "-mllvm" "-disable-llvm-passes"
+// DISABLED: "-disable-llvm-passes"
 //
 // We also support two alternative spellings for historical reasons.
 // RUN: %clang -O2 -Xclang -disable-llvm-optzns -### %s 2>&1 \
@@ -11,8 +11,8 @@
 // RUN: %clang -O2 -mllvm -disable-llvm-optzns -### %s 2>&1 \
 // RUN: | FileCheck --check-prefix=DISABLED-LEGACY %s
 // DISABLED-LEGACY: -cc1
-// DISABLED-LEGACY-NOT: -mllvm
-// DISABLED-LEGACY: -disable-llvm-optzns
+// DISABLED-LEGACY-NOT: "-mllvm" "-disable-llvm-optzns"
+// DISABLED-LEGACY: "-disable-llvm-optzns"
 //
 // The main flag shouldn't be specially handled when used with '-mllvm'.
 // RUN: %clang -O2 -mllvm -disable-llvm-passes -### %s 2>&1 | FileCheck 
--check-prefix=MLLVM %s


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

r291853 - Fix two test cases I missed updating in r291850. Sorry for the noise.

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Thu Jan 12 16:48:28 2017
New Revision: 291853

URL: http://llvm.org/viewvc/llvm-project?rev=291853=rev
Log:
Fix two test cases I missed updating in r291850. Sorry for the noise.

Modified:
cfe/trunk/test/CodeGen/always_inline.c
cfe/trunk/test/Profile/gcc-flag-compatibility.c

Modified: cfe/trunk/test/CodeGen/always_inline.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/always_inline.c?rev=291853=291852=291853=diff
==
--- cfe/trunk/test/CodeGen/always_inline.c (original)
+++ cfe/trunk/test/CodeGen/always_inline.c Thu Jan 12 16:48:28 2017
@@ -1,7 +1,7 @@
 // RUN: %clang -emit-llvm -S -o %t %s
 // RUN: not grep '@f0' %t
 // RUN: not grep 'call ' %t
-// RUN: %clang -mllvm -disable-llvm-passes -emit-llvm -S -o %t %s
+// RUN: %clang -Xclang -disable-llvm-passes -emit-llvm -S -o %t %s
 // RUN: grep '@f0' %t | count 2
 
 //static int f0() { 

Modified: cfe/trunk/test/Profile/gcc-flag-compatibility.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Profile/gcc-flag-compatibility.c?rev=291853=291852=291853=diff
==
--- cfe/trunk/test/Profile/gcc-flag-compatibility.c (original)
+++ cfe/trunk/test/Profile/gcc-flag-compatibility.c Thu Jan 12 16:48:28 2017
@@ -18,14 +18,14 @@
 // RUN: rm -rf %t.dir
 // RUN: mkdir -p %t.dir/some/path
 // RUN: llvm-profdata merge %S/Inputs/gcc-flag-compatibility.proftext -o 
%t.dir/some/path/default.profdata
-// RUN: %clang %s -o - -mllvm -disable-llvm-passes -emit-llvm -S 
-fprofile-use=%t.dir/some/path | FileCheck -check-prefix=PROFILE-USE-2 %s
+// RUN: %clang %s -o - -Xclang -disable-llvm-passes -emit-llvm -S 
-fprofile-use=%t.dir/some/path | FileCheck -check-prefix=PROFILE-USE-2 %s
 // PROFILE-USE-2: = !{!"branch_weights", i32 101, i32 2}
 
 // Check that -fprofile-use=some/path/file.prof reads some/path/file.prof
 // RUN: rm -rf %t.dir
 // RUN: mkdir -p %t.dir/some/path
 // RUN: llvm-profdata merge %S/Inputs/gcc-flag-compatibility.proftext -o 
%t.dir/some/path/file.prof
-// RUN: %clang %s -o - -mllvm -disable-llvm-passes -emit-llvm -S 
-fprofile-use=%t.dir/some/path/file.prof | FileCheck 
-check-prefix=PROFILE-USE-3 %s
+// RUN: %clang %s -o - -Xclang -disable-llvm-passes -emit-llvm -S 
-fprofile-use=%t.dir/some/path/file.prof | FileCheck 
-check-prefix=PROFILE-USE-3 %s
 // PROFILE-USE-3: = !{!"branch_weights", i32 101, i32 2}
 
 int X = 0;


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

r291851 - Replace some stray uses of the old spelling of the flag with the new

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Thu Jan 12 16:43:37 2017
New Revision: 291851

URL: http://llvm.org/viewvc/llvm-project?rev=291851=rev
Log:
Replace some stray uses of the old spelling of the flag with the new
spelling. NFC.

Modified:
cfe/trunk/test/CodeGen/ms-declspecs.c
cfe/trunk/test/CodeGenCXX/optnone-class-members.cpp
cfe/trunk/test/CodeGenCXX/optnone-def-decl.cpp

Modified: cfe/trunk/test/CodeGen/ms-declspecs.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/ms-declspecs.c?rev=291851=291850=291851=diff
==
--- cfe/trunk/test/CodeGen/ms-declspecs.c (original)
+++ cfe/trunk/test/CodeGen/ms-declspecs.c Thu Jan 12 16:43:37 2017
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -triple i386-pc-win32 %s -emit-llvm -fms-compatibility -O2 
-disable-llvm-optzns -o - | FileCheck %s
+// RUN: %clang_cc1 -triple i386-pc-win32 %s -emit-llvm -fms-compatibility -O2 
-disable-llvm-passes -o - | FileCheck %s
 
 __declspec(selectany) int x1 = 1;
 const __declspec(selectany) int x2 = 2;

Modified: cfe/trunk/test/CodeGenCXX/optnone-class-members.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/optnone-class-members.cpp?rev=291851=291850=291851=diff
==
--- cfe/trunk/test/CodeGenCXX/optnone-class-members.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/optnone-class-members.cpp Thu Jan 12 16:43:37 2017
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 < %s -triple %itanium_abi_triple -fms-extensions -O2 
-disable-llvm-optzns -emit-llvm -x c++ | FileCheck %s
+// RUN: %clang_cc1 < %s -triple %itanium_abi_triple -fms-extensions -O2 
-disable-llvm-passes -emit-llvm -x c++ | FileCheck %s
 
 // Test attribute 'optnone' on methods:
 //  -- member functions;

Modified: cfe/trunk/test/CodeGenCXX/optnone-def-decl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/optnone-def-decl.cpp?rev=291851=291850=291851=diff
==
--- cfe/trunk/test/CodeGenCXX/optnone-def-decl.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/optnone-def-decl.cpp Thu Jan 12 16:43:37 2017
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 %s -triple %itanium_abi_triple -fms-extensions -O2 
-disable-llvm-optzns -emit-llvm -o - | FileCheck %s
+// RUN: %clang_cc1 %s -triple %itanium_abi_triple -fms-extensions -O2 
-disable-llvm-passes -emit-llvm -o - | FileCheck %s
 
 // Test optnone on both function declarations and function definitions.
 // Verify also that we don't generate invalid IR functions with


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

r291850 - Address review comments on r290392:

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Thu Jan 12 16:40:13 2017
New Revision: 291850

URL: http://llvm.org/viewvc/llvm-project?rev=291850=rev
Log:
Address review comments on r290392:
- Don't break using '-mllvm -disable-llvm-optzns' (yet).
- Don't add support for '-mllvm -disable-llvm-passes'.

This is important for LLVM 4 as we haven't yet really told folks this is
coming. I'll add release notes about this.

I've also added some explicit testing of this so its more obvious what
is happening here.

Added:
cfe/trunk/test/Driver/disable-llvm.c
Modified:
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/cl-options.c

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=291850=291849=291850=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Thu Jan 12 16:40:13 2017
@@ -6431,11 +6431,13 @@ void Clang::ConstructJob(Compilation ,
 A->claim();
 
 // We translate this by hand to the -cc1 argument, since nightly test uses
-// it and developers have been trained to spell it with -mllvm.
-if (StringRef(A->getValue(0)) == "-disable-llvm-passes") {
-  CmdArgs.push_back("-disable-llvm-passes");
-} else
+// it and developers have been trained to spell it with -mllvm. Both
+// spellings are now deprecated and should be removed.
+if (StringRef(A->getValue(0)) == "-disable-llvm-optzns") {
+  CmdArgs.push_back("-disable-llvm-optzns");
+} else {
   A->render(Args, CmdArgs);
+}
   }
 
   // With -save-temps, we want to save the unoptimized bitcode output from the

Modified: cfe/trunk/test/Driver/cl-options.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cl-options.c?rev=291850=291849=291850=diff
==
--- cfe/trunk/test/Driver/cl-options.c (original)
+++ cfe/trunk/test/Driver/cl-options.c Thu Jan 12 16:40:13 2017
@@ -535,7 +535,7 @@
 // RUN: -fno-ms-compatibility \
 // RUN: -fms-extensions \
 // RUN: -fno-ms-extensions \
-// RUN: -mllvm -disable-llvm-passes \
+// RUN: -Xclang -disable-llvm-passes \
 // RUN: -resource-dir asdf \
 // RUN: -resource-dir=asdf \
 // RUN: -Wunused-variable \

Added: cfe/trunk/test/Driver/disable-llvm.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/disable-llvm.c?rev=291850=auto
==
--- cfe/trunk/test/Driver/disable-llvm.c (added)
+++ cfe/trunk/test/Driver/disable-llvm.c Thu Jan 12 16:40:13 2017
@@ -0,0 +1,22 @@
+// We support a CC1 option for disabling LLVM's passes.
+// RUN: %clang -O2 -Xclang -disable-llvm-passes -### %s 2>&1 \
+// RUN: | FileCheck --check-prefix=DISABLED %s
+// DISABLED: -cc1
+// DISABLED-NOT: -mllvm
+// DISABLED: -disable-llvm-passes
+//
+// We also support two alternative spellings for historical reasons.
+// RUN: %clang -O2 -Xclang -disable-llvm-optzns -### %s 2>&1 \
+// RUN: | FileCheck --check-prefix=DISABLED-LEGACY %s
+// RUN: %clang -O2 -mllvm -disable-llvm-optzns -### %s 2>&1 \
+// RUN: | FileCheck --check-prefix=DISABLED-LEGACY %s
+// DISABLED-LEGACY: -cc1
+// DISABLED-LEGACY-NOT: -mllvm
+// DISABLED-LEGACY: -disable-llvm-optzns
+//
+// The main flag shouldn't be specially handled when used with '-mllvm'.
+// RUN: %clang -O2 -mllvm -disable-llvm-passes -### %s 2>&1 | FileCheck 
--check-prefix=MLLVM %s
+// MLLVM: -cc1
+// MLLVM-NOT: -disable-llvm-passes
+// MLLVM: "-mllvm" "-disable-llvm-passes"
+// MLLVM-NOT: -disable-llvm-passes


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

Re: r290450 - [PM] Introduce options to enable the (still experimental) new pass

[Chandler Carruth via cfe-commits]

(explicitly adding Richard so he sees this discussion as some of this
involves a discussion between myself and him)

On Tue, Jan 10, 2017 at 4:36 PM Justin Bogner via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Chandler Carruth via cfe-commits <cfe-commits@lists.llvm.org> writes:
> > Author: chandlerc
> > Date: Fri Dec 23 14:44:01 2016
> > New Revision: 290450
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=290450=rev
> > Log:
> > [PM] Introduce options to enable the (still experimental) new pass
> > manager, and a code path to use it.
> >
> > The option is actually a top-level option but does contain
> > 'experimental' in the name. This is the compromise suggested by Richard
> > in discussions. We expect this option will be around long enough and
> > have enough users towards the end that it merits not being relegated to
> > CC1, but it still needs to be clear that this option will go away at
> > some point.
>
> I don't really understand why this is a driver option and not just a CC1
> option. Using a driver flag makes me think we expect people to be using
> this in production before we make the new PM the default, which seems
> kind of questionable to me,


I tried to explain the thinking here, but sorry if it wasn't clear. And
maybe its just the wrong tradeoff.

My thought process is this: until we get users of Clang and LLVM using the
new PM in production, I think it's going to be between hard and impossible
to make it the default. So I've been trying to make sure we have a healthy
state for asking users to enable this including in production. Speaking
just for myself as a user, I will need to enable this in production prior
to it being the default.


> and I don't see how adding a new
> "-fexperimental" is any better than just using the "-Xclang" that people
> are already familiar with the implications of.
>

The "experimental" thing was not really intended to be anything like the
CC1 interface.

It communicates two things IMO: that the functionality is less mature at
this point, and that there will (eventually) be changes.

I would still expect us to go through a very slow process to remove this
flag, the same as I would expect for any other driver-level flag.

To give an idea of the kind of timeframe I'm trying to prepare for
(although it being faster would of course be a pleasant surprise): I
suspect we will need there to be an open source release with the
functionality finished and reasonably well tested but still not the
default. And in that release we'll want to in the release notes advertise
that this is coming and that the next release will flip the default. And
then I think we'll need to do *another* release where the old pass manager
is still around, but is not the default.

Maybe things will go substantially better/faster than I've described, but
I'm trying to have a plan that is viable even if things move that slowly.


Anyways, if the decision is to go back to a CC1 flag, we can do that. I
just really want to avoid that if possible as I'd like to avoid deploying a
CC1 flag to my users (we work actively to avoid doing this where possible).

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

r291036 - [gtest] The way EXPECT_TEST now works after upgrading gtest triggers an

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Wed Jan  4 17:57:25 2017
New Revision: 291036

URL: http://llvm.org/viewvc/llvm-project?rev=291036=rev
Log:
[gtest] The way EXPECT_TEST now works after upgrading gtest triggers an
ODR use. These traits don't have a definition as they're intended to be
used strictly at compile time. Change the tests to use static_assert to
move the entire thing into compile-time.

Modified:
cfe/trunk/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp

Modified: cfe/trunk/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp?rev=291036=291035=291036=diff
==
--- cfe/trunk/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp (original)
+++ cfe/trunk/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp Wed Jan  4 
17:57:25 2017
@@ -222,9 +222,12 @@ TEST(HasDeclaration, HasDeclarationOfEnu
 }
 
 TEST(HasDeclaration, HasGetDeclTraitTest) {
-  EXPECT_TRUE(internal::has_getDecl::value);
-  EXPECT_TRUE(internal::has_getDecl::value);
-  EXPECT_FALSE(internal::has_getDecl::value);
+  static_assert(internal::has_getDecl::value,
+"Expected TypedefType to have a getDecl.");
+  static_assert(internal::has_getDecl::value,
+"Expected RecordType to have a getDecl.");
+  static_assert(!internal::has_getDecl::value,
+"Expected TemplateSpecializationType to *not* have a 
getDecl.");
 }
 
 TEST(HasDeclaration, HasDeclarationOfTypeWithDecl) {


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

Re: r290539 - [inline-asm]No error for conflict between inputs\outputs and clobber list

[Chandler Carruth via cfe-commits]

On Mon, Dec 26, 2016 at 4:34 AM Marina Yatsina via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: myatsina
> Date: Mon Dec 26 06:23:42 2016
> New Revision: 290539
>
> URL: http://llvm.org/viewvc/llvm-project?rev=290539=rev
> Log:
> [inline-asm]No error for conflict between inputs\outputs and clobber list
>
> According to extended asm syntax, a case where the clobber list includes a
> variable from the inputs or outputs should be an error - conflict.
> for example:
>
> const long double a = 0.0;
> int main()
> {
>
> char b;
> double t1 = a;
> __asm__ ("fucompp": "=a" (b) : "u" (t1), "t" (t1) : "cc", "st", "st(1)");
>
> return 0;
> }
>
> This should conflict with the output - t1 which is st, and st which is st
> aswell.
> The patch fixes it.


> Commit on behald of Ziv Izhar.
>
> Differential Revision: https://reviews.llvm.org/D15075
>
>
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/include/clang/Basic/TargetInfo.h
> cfe/trunk/lib/Basic/TargetInfo.cpp
> cfe/trunk/lib/Basic/Targets.cpp
> cfe/trunk/lib/Headers/intrin.h
> cfe/trunk/lib/Sema/SemaStmtAsm.cpp
> cfe/trunk/test/Sema/asm.c
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=290539=290538=290539=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Mon Dec 26
> 06:23:42 2016
> @@ -7069,6 +7069,10 @@ let CategoryName = "Inline Assembly Issu
>  "constraint '%0' is already present here">;
>  }
>
> +  def error_inoutput_conflict_with_clobber : Error<
> +"asm-specifier for input or output variable conflicts with asm"
> +" clobber list">;
>

Clang generally works to avoid this kind of error message. All this does is
say "there was a problem of this kind" without identifying any of the
specifics. And for this error in particular I think this is of the utmost
importance. Developers are not going to understand what went wrong here.

I would suggest at a minimum to enhance this to explain:

1) What operands and clobbers conflict, preferably with source ranges
underlining them.

2) Why they conflict (for example the fact that "D" means the di register
group, of which "%rdi" is a member)

Beyond that, I wonder if you could add a note suggesting to remove the
clobber if the input (or output) operand is sufficient.

You can make this note explain carefully the case where something would
need to be added to the inputs or outputs instead, but I think it at least
makes sense to clarify that this will be a common fix and what to look out
for that might make it an incorrect fix.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r290593 - DR1495: A partial specialization is ill-formed if it is not (strictly) more

[Chandler Carruth via cfe-commits]

I suspect that this commit is responsible for a regression parsing widely
used open source packages like Eigen.

See the code in Eigen here:
https://bitbucket.org/eigen/eigen/src/e46c8246b284dea1690ac260dfe50851906138f0/unsupported/Eigen/CXX11/src/Tensor/TensorStorage.h?at=default=file-view-default#TensorStorage.h-38

I'm not claiming this code is correct, but I'm worried about how much code
out there looks like this... Thoughts? Could we at least temporarily put
this DR fix behind a flag or make it a warning?

On Tue, Dec 27, 2016 at 12:07 AM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Tue Dec 27 01:56:27 2016
> New Revision: 290593
>
> URL: http://llvm.org/viewvc/llvm-project?rev=290593=rev
> Log:
> DR1495: A partial specialization is ill-formed if it is not (strictly) more
> specialized than the primary template. (Put another way, if we imagine
> there
> were a partial specialization matching the primary template, we should
> never
> select it if some other partial specialization also matches.)
>
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/include/clang/Sema/Sema.h
> cfe/trunk/include/clang/Sema/TemplateDeduction.h
> cfe/trunk/lib/Sema/SemaTemplate.cpp
> cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp
> cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
> cfe/trunk/test/CXX/drs/dr14xx.cpp
> cfe/trunk/test/CXX/temp/temp.decls/temp.variadic/fixed-expansion.cpp
> cfe/trunk/test/SemaTemplate/class-template-spec.cpp
> cfe/trunk/test/SemaTemplate/temp_arg_nontype.cpp
> cfe/trunk/www/cxx_dr_status.html
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=290593=290592=290593=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Tue Dec 27
> 01:56:27 2016
> @@ -4043,6 +4043,10 @@ def err_partial_spec_args_match_primary_
>  "%select{class|variable}0 template partial specialization does not "
>  "specialize any template argument; to %select{declare|define}1 the "
>  "primary template, remove the template argument list">;
> +def err_partial_spec_not_more_specialized_than_primary : Error<
> +"%select{class|variable}0 template partial specialization is not "
> +"more specialized than the primary template">;
> +def note_partial_spec_not_more_specialized_than_primary : Note<"%0">;
>  def warn_partial_specs_not_deducible : Warning<
>  "%select{class|variable}0 template partial specialization contains "
>  "%select{a template parameter|template parameters}1 that cannot be "
> @@ -4147,7 +4151,7 @@ def note_function_template_deduction_ins
>"%1">;
>  def note_deduced_template_arg_substitution_here : Note<
>"during template argument deduction for %select{class|variable}0
> template "
> -  "partial specialization %1 %2">;
> +  "%select{partial specialization |}1%2 %3">;
>  def note_prior_template_arg_substitution : Note<
>"while substituting prior template arguments into
> %select{non-type|template}0"
>" template parameter%1 %2">;
>
> Modified: cfe/trunk/include/clang/Sema/Sema.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=290593=290592=290593=diff
>
> ==
> --- cfe/trunk/include/clang/Sema/Sema.h (original)
> +++ cfe/trunk/include/clang/Sema/Sema.h Tue Dec 27 01:56:27 2016
> @@ -6697,10 +6697,16 @@ public:
>ClassTemplatePartialSpecializationDecl
> *PS2,
>SourceLocation Loc);
>
> +  bool
> isMoreSpecializedThanPrimary(ClassTemplatePartialSpecializationDecl *T,
> +sema::TemplateDeductionInfo );
> +
>VarTemplatePartialSpecializationDecl
> *getMoreSpecializedPartialSpecialization(
>VarTemplatePartialSpecializationDecl *PS1,
>VarTemplatePartialSpecializationDecl *PS2, SourceLocation Loc);
>
> +  bool isMoreSpecializedThanPrimary(VarTemplatePartialSpecializationDecl
> *T,
> +sema::TemplateDeductionInfo );
> +
>void MarkUsedTemplateParameters(const TemplateArgumentList
> ,
>bool OnlyDeduced,
>unsigned Depth,
> @@ -6752,7 +6758,7 @@ public:
>/// template argument deduction for either a class template
>/// partial specialization or a function template. The
>/// Entity is either a {Class|Var}TemplatePartialSpecializationDecl
> or
> -  /// a FunctionTemplateDecl.
> +  /// a TemplateDecl.
>DeducedTemplateArgumentSubstitution,
>
>/// We are substituting prior template arguments into a new
> @@ -6973,6 

r290560 - [PM] The new pass manager requires a registered target for these, and

[Chandler Carruth via cfe-commits]

Author: chandlerc
Date: Mon Dec 26 18:31:34 2016
New Revision: 290560

URL: http://llvm.org/viewvc/llvm-project?rev=290560=rev
Log:
[PM] The new pass manager requires a registered target for these, and
given that they hard code specific triples that seems reasonable so add
the REQUIRES.

Modified:
cfe/trunk/test/CodeGen/inline.c

Modified: cfe/trunk/test/CodeGen/inline.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/inline.c?rev=290560=290559=290560=diff
==
--- cfe/trunk/test/CodeGen/inline.c (original)
+++ cfe/trunk/test/CodeGen/inline.c Mon Dec 26 18:31:34 2016
@@ -1,3 +1,5 @@
+// REQUIRES: x86-registered-target
+//
 // RUN: echo "GNU89 tests:"
 // RUN: %clang_cc1 %s -triple i386-unknown-unknown -O1 -disable-llvm-passes 
-emit-llvm -o - -std=gnu89 | FileCheck %s --check-prefix=CHECK1
 // RUN: %clang_cc1 %s -triple i386-unknown-unknown 
-fexperimental-new-pass-manager -O1 -disable-llvm-passes -emit-llvm -o - 
-std=gnu89 | FileCheck %s --check-prefix=CHECK1


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