[PATCH] D86632: [Fixed Point] Add codegen for conversion between fixed-point and floating point.

2020-09-10 Thread John McCall via Phabricator via cfe-commits
rjmccall added inline comments.



Comment at: llvm/include/llvm/IR/FixedPointBuilder.h:126
+  /// \p Ty, or a floating point type with a larger exponent than Ty.
+  Type *getAccommodatingFloatType(Type *Ty, const FixedPointSemantics ) {
+const fltSemantics *FloatSema = >getFltSemantics();

I like this method name.  Does this have the same problem as I asked about in 
the other patch about really needing to be about whether the *unscaled* 
fixed-point type fits in the given type?



Comment at: llvm/include/llvm/IR/FixedPointBuilder.h:131
+// There's seemingly no way to convert fltSemantics to Type.
+return ConstantFP::get(Ty->getContext(), APFloat(*FloatSema))->getType();
+  }

Could you just extract that code out of `llvm::ConstantFP::get` and put it on 
`llvm::Type`?  Might be better as a separate patch.

While you're at it, there's also a `TypeToFloatSemantics` function in 
Constants.cpp that's completely redundant with `llvm::Type::getFltSemantics`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86632

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


[PATCH] D87047: [clang] Add command line options for the Machine Function Splitter.

2020-09-10 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added inline comments.



Comment at: clang/docs/ClangCommandLineReference.rst:2131
 
+.. option:: -fsplit-machine-functions, -fno-split-machine-functions
+

You don't need to edit this file. It is auto-generated from Options.td



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:4917
+if (Triple.isX86() && Triple.isOSBinFormatELF())
+  A->render(Args, CmdArgs);
+else

OPT_fno_split_machine_functions is a driver option but not a CC1 option. 
Rendering OPT_fno_split_machine_functions will error when processing CC1 
options.



Comment at: clang/test/CodeGen/split-machine-functions.c:1
+// clang-format off
+// REQUIRES: x86-registered-target

You can ignore clang-format/clang-tidy issues in test/ and there is no need to 
annotate the tests (otherwise we will annotate essentially every file)



Comment at: clang/test/CodeGen/split-machine-functions.c:5
+// RUN: llvm-profdata merge -o %t/default.profdata %t/proftext
+// RUN: %clang_cc1 -triple x86_64 -O3 -S 
-fprofile-instrument-use-path=%t/default.profdata -fsplit-machine-functions -o 
- < %t/code | FileCheck %s
+

See https://reviews.llvm.org/D85408#2266559

It feels wrong that the assembly+llvm-profdata test is in clang/test



Comment at: clang/test/Driver/fsplit-machine-functions.c:1
+// RUN: %clang -### -target x86_64 -fsplit-machine-functions %s -c 2>&1 | 
FileCheck -check-prefix=CHECK-OPT %s
+// RUN: %clang -### -target x86_64 -fsplit-machine-functions 
-fno-split-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-NOOPT %s

Add `-fprofile-use` to the canonical usage line



Comment at: clang/test/Driver/fsplit-machine-functions.c:3
+// RUN: %clang -### -target x86_64 -fsplit-machine-functions 
-fno-split-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-NOOPT %s
+// RUN: %clang -c -target x86_64 -fsplit-machine-functions %s -c 2>&1 | 
FileCheck -check-prefix=CHECK-WARN %s
+// RUN: not %clang -c -target arm-unknown-linux -fsplit-machine-functions %s 
-c 2>&1 | FileCheck -check-prefix=CHECK-TRIPLE %s

Two -c?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87047

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


[PATCH] D85473: [Clang] Add option to allow marking pass-by-value args as noalias.

2020-09-10 Thread John McCall via Phabricator via cfe-commits
rjmccall added a reviewer: ahatanak.
rjmccall added inline comments.



Comment at: clang/lib/CodeGen/CGCall.cpp:2198
+// reference to the underlying object. Mark it accordingly.
+Attrs.addAttribute(llvm::Attribute::NoAlias);
+

fhahn wrote:
> rjmccall wrote:
> > This definitely can't be added unconditionally to all types; you need to 
> > rule out non-trivial C++ class types, as well as types with ObjC weak 
> > references.
> Updated to rule out non trivially-copyable types.
> 
> I am not sure how to best handle types with weak references. I did not manage 
> to find any helpers that traverse a whole type to check if it contains weak 
> references. 
> 
> I added `clang/test/CodeGenObjC/pass-by-value-noalias.m` and IIUC `noalias` 
> should not be added for that case.
The restriction should not be by triviality but by whether indirectness is 
forced semantically.  That may currently only be available on RecordDecl (as 
`RecordDecl::getArgPassingRestrictions`), but you could definitely add an 
accessor to `Type` which checked for a RecordType and otherwise returned that 
there are no passing constraints.  Tagging Akira, who worked on this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85473

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


[PATCH] D85960: [AST][FPEnv] Keep FP options in trailing storage of CastExpr

2020-09-10 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

Follow-up on my previous request.  It's fine by me if you commit with that fix.




Comment at: clang/lib/Analysis/BodyFarm.cpp:188
+  const_cast(Arg), nullptr, VK_RValue,
+  FPOptionsOverride());
 }

rjmccall wrote:
> Can these call sites just be changed to use `makeImplicitCast`?
Can you do the one in makeIntegralCast, too?  Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85960

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


[PATCH] D87470: [Coroutine][Sema] Tighten the lifetime of symmetric transfer returned handle

2020-09-10 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

Also LGTM with a testcase.  It's fine to test the result of IRGen.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87470

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


[PATCH] D75574: RFC: Implement objc_direct_protocol attribute to remove protocol metadata

2020-09-10 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

In D75574#2262622 , @lanza wrote:

>> I don't think it'll actually error out at link time: protocol objects get 
>> emitted eagerly on use, cross-module linking is just a code-size 
>> optimization. This actually has caused longstanding problems.
>
> But if it's just a forward declaration there's nothing to emit. The above 
> code compiles just fine as is with just a warning. Here's the result of 
> `clang protocol.m -lobjc`
>
>   proto.m:10:31: warning: cannot find protocol definition for 
> 'NonRuntimeProto'
>   @interface Implementer : Root
> ^
>   proto.m:8:11: note: protocol 'NonRuntimeProto' has no definition
>   @protocol NonRuntimeProto;
> ^
>   1 warning generated.
>   Undefined symbols for architecture x86_64:
> "__OBJC_PROTOCOL_$_NonRuntimeProto", referenced from:
> __OBJC_CLASS_PROTOCOLS_$_Implementer in proto-bd4a43.o
>   ld: symbol(s) not found for architecture x86_64
>   clang-12: error: linker command failed with exit code 1 (use -v to see 
> invocation)
>
> The protocol definition isn't actually required to compile an implementation. 
> And if that protocol is declared as `objc_non_runtime_protocol` it won't ever 
> see one.
>
> Simply requiring that it is annotated accordingly also isn't satisfactory for 
> the same inheritance problem you mentioned above. Annotating a forward decl 
> can tell clang not to emit it but won't let clang know if there's a base 
> protocol that still needs to be emitted. e.g. if we have
>
>   // SomeHeader.h
>   @protocol Base
>   @end
>   __attribute__((objc_non_runtime_protocol))
>   @protocol NonRuntime 
>   @end
>   
>   
>   // and in main.m
>   __attribute__((objc_non_runtime_protocol))
>   @protocol NonRuntime
>   @interface AClass : Root
>   @end
>   @implementation AClass
>   @end
>
> we'll get a compile warning but no link error. But it will be wrong as the 
> protocol `Base` should still be in the protocollist for `AClass`.
>
> I'm not sure how big of an issue it would be introducing a new error here for 
> code that used to compile, but that's really the only way I see this working.

Hmm, I thought we actually just generated a bogus definition for the protocol 
when it was forward-declared; really, this is better behavior that I expected.  
Regardless, I don't think it's worthwhile to diagnose this more strongly than a 
warning because of the history of not doing so.

Not really important for this PR anyway.  Was your question answered well 
enough to move forward?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D75574

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


[PATCH] D87470: [Coroutine][Sema] Tighten the lifetime of symmetric transfer returned handle

2020-09-10 Thread Xun Li via Phabricator via cfe-commits
lxfind added a comment.

In D87470#2267060 , @junparser wrote:

> Thanks for the change. LGTM, and testcase?

Not sure how to add a test case for this though. We don't seem to explicitly 
test AST output.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87470

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


Upcoming upgrade of LLVM buildbot

2020-09-10 Thread Galina Kistanova via cfe-commits
Hello everyone,

The buildbot upgrade is entering the phase when the results to become
visible.

No change is required at this time on any of the builders. The bot owners
could upgrade the buildbot on build computers later, at their convenience,
as this is not on the critical path.

We are going to upgrade the staging bot first. Then, once that is stable
and all detected issues are resolved, we will upgrade the production bot.

I will need some help with testing, and will be asking to move some of the
builders temporarily to the staging. LLVM buildbot is a piece of critical
infrastructure, so more eyes and hands in making sure it works properly the
better.

I'll be posting updates and ETA of particular changes in this thread.

Please feel free to ask if you have any questions or concerns.

Thanks

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


[libclc] 16ba78e - libclc/spirv: Add missing files from D85911

2020-09-10 Thread Jan Vesely via cfe-commits

Author: Jan Vesely
Date: 2020-09-10T23:41:38-04:00
New Revision: 16ba78ee627c3fe66906349e8c90ee8cc1224298

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

LOG: libclc/spirv: Add missing files from D85911

Fixes: 060c8e083dd637866854acb6a0823c45b2ef68ef
Signed-off-by: Jan Vesely 

Added: 
libclc/spirv/lib/math/fma.cl
libclc/spirv/lib/math/fma.inc
libclc/spirv64/lib/math/fma.cl
libclc/spirv64/lib/math/fma.inc

Modified: 


Removed: 




diff  --git a/libclc/spirv/lib/math/fma.cl b/libclc/spirv/lib/math/fma.cl
new file mode 100644
index ..982ddc4374f3
--- /dev/null
+++ b/libclc/spirv/lib/math/fma.cl
@@ -0,0 +1,6 @@
+#include 
+#include 
+
+#define __CLC_BODY 
+#define __FLOAT_ONLY
+#include 

diff  --git a/libclc/spirv/lib/math/fma.inc b/libclc/spirv/lib/math/fma.inc
new file mode 100644
index ..0f12c565758f
--- /dev/null
+++ b/libclc/spirv/lib/math/fma.inc
@@ -0,0 +1,3 @@
+_CLC_DEF _CLC_OVERLOAD __CLC_GENTYPE fma(__CLC_GENTYPE a, __CLC_GENTYPE b, 
__CLC_GENTYPE c) {
+   return __clc_sw_fma(a, b, c);
+}

diff  --git a/libclc/spirv64/lib/math/fma.cl b/libclc/spirv64/lib/math/fma.cl
new file mode 100644
index ..982ddc4374f3
--- /dev/null
+++ b/libclc/spirv64/lib/math/fma.cl
@@ -0,0 +1,6 @@
+#include 
+#include 
+
+#define __CLC_BODY 
+#define __FLOAT_ONLY
+#include 

diff  --git a/libclc/spirv64/lib/math/fma.inc b/libclc/spirv64/lib/math/fma.inc
new file mode 100644
index ..0f12c565758f
--- /dev/null
+++ b/libclc/spirv64/lib/math/fma.inc
@@ -0,0 +1,3 @@
+_CLC_DEF _CLC_OVERLOAD __CLC_GENTYPE fma(__CLC_GENTYPE a, __CLC_GENTYPE b, 
__CLC_GENTYPE c) {
+   return __clc_sw_fma(a, b, c);
+}



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


[PATCH] D87047: [clang] Add command line options for the Machine Function Splitter.

2020-09-10 Thread Snehasish Kumar via Phabricator via cfe-commits
snehasish marked an inline comment as done.
snehasish added inline comments.



Comment at: clang/test/CodeGen/split-machine-functions.c:3
+
+// RUN: echo "foo"> %t.proftext
+// RUN: echo "# Func Hash:"   >> %t.proftext

snehasish wrote:
> MaskRay wrote:
> > Consider `RUN: split-file`
> > 
> > Search for this string for some examples.
> Looks much cleaner with split-file overall, though it doesn't play well with 
> clang-format since this is a .c file. Should we just ignore clang-format 
> complaints for this file?
Fixed the formatting by adding a `clang-format off` directive at the top of 
this file.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87047

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


[PATCH] D87047: [clang] Add command line options for the Machine Function Splitter.

2020-09-10 Thread Snehasish Kumar via Phabricator via cfe-commits
snehasish updated this revision to Diff 291122.
snehasish marked an inline comment as done.
snehasish added a comment.

Fix test formatting.

Added clang-format off to disable clang format for the test which contains both 
profile data (as text) and c code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87047

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/split-machine-functions.c
  clang/test/Driver/fsplit-machine-functions.c

Index: clang/test/Driver/fsplit-machine-functions.c
===
--- /dev/null
+++ clang/test/Driver/fsplit-machine-functions.c
@@ -0,0 +1,9 @@
+// RUN: %clang -### -target x86_64 -fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
+// RUN: %clang -### -target x86_64 -fsplit-machine-functions -fno-split-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-NOOPT %s
+// RUN: %clang -c -target x86_64 -fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-WARN %s
+// RUN: not %clang -c -target arm-unknown-linux -fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-TRIPLE %s
+
+// CHECK-OPT:   "-fsplit-machine-functions"
+// CHECK-NOOPT-NOT: "-fsplit-machine-functions"
+// CHECK-WARN:  ignored -fsplit-machine-functions, no profile provided via -fprofile-use
+// CHECK-TRIPLE:error: unsupported option '-fsplit-machine-functions' for target
Index: clang/test/CodeGen/split-machine-functions.c
===
--- /dev/null
+++ clang/test/CodeGen/split-machine-functions.c
@@ -0,0 +1,38 @@
+// clang-format off
+// REQUIRES: x86-registered-target
+// RUN: split-file %s %t
+// RUN: llvm-profdata merge -o %t/default.profdata %t/proftext
+// RUN: %clang_cc1 -triple x86_64 -O3 -S -fprofile-instrument-use-path=%t/default.profdata -fsplit-machine-functions -o - < %t/code | FileCheck %s
+
+// CHECK: .section .text.hot.,"ax",@progbits
+// CHECK: foo:
+// CHECK: section .text.unlikely.foo,"ax",@progbits
+// CHECK: foo.cold:
+// CHECK: callq exit@PLT
+
+//--- proftext
+foo
+# Func Hash:
+11262309905
+# Num Counters:
+2
+# Counter Values:
+100
+0
+
+//--- code
+__attribute__((noinline)) int foo(int argc) {
+  if (argc % 2 == 0) {
+exit(argc);
+  } else {
+return argc + 1;
+  }
+}
+
+int main(int argc, char *argv[]) {
+  int total = 0;
+  for (int i = 0; i < 100; ++i) {
+total += foo(argc);
+  }
+  printf("%d\n", total);
+}
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -998,6 +998,8 @@
   Opts.UniqueInternalLinkageNames =
   Args.hasArg(OPT_funique_internal_linkage_names);
 
+  Opts.SplitMachineFunctions = Args.hasArg(OPT_fsplit_machine_functions);
+
   Opts.MergeFunctions = Args.hasArg(OPT_fmerge_functions);
 
   Opts.NoUseJumpTables = Args.hasArg(OPT_fno_jump_tables);
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4911,6 +4911,15 @@
options::OPT_fno_unique_basic_block_section_names, false))
 CmdArgs.push_back("-funique-basic-block-section-names");
 
+  if (Arg *A = Args.getLastArg(options::OPT_fsplit_machine_functions,
+   options::OPT_fno_split_machine_functions)) {
+if (Triple.isX86() && Triple.isOSBinFormatELF())
+  A->render(Args, CmdArgs);
+else
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << A->getAsString(Args) << TripleStr;
+  }
+
   Args.AddLastArg(CmdArgs, options::OPT_finstrument_functions,
   options::OPT_finstrument_functions_after_inlining,
   options::OPT_finstrument_function_entry_bare);
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -9,6 +9,7 @@
 #include "clang/CodeGen/BackendUtil.h"
 #include "clang/Basic/CodeGenOptions.h"
 #include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticFrontend.h"
 #include "clang/Basic/LangOptions.h"
 #include "clang/Basic/TargetOptions.h"
 #include "clang/Frontend/FrontendDiagnostic.h"
@@ -514,6 +515,15 @@
   Options.BBSectionsFuncListBuf = std::move(*MBOrErr);
   }
 
+  if (CodeGenOpts.SplitMachineFunctions) {
+if (CodeGenOpts.getProfileUse() != CodeGenOptions::ProfileNone)
+  Options.EnableMachineFunctionSplitter = true;
+else
+  

LLVM buildmaster will be updated and restarted soon

2020-09-10 Thread Galina Kistanova via cfe-commits
 Hello everyone,

LLVM buildmaster will be updated and restarted in an hour.

Thanks

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


[PATCH] D84988: [Coverage] Add empty line regions to SkippedRegions

2020-09-10 Thread Zequan Wu via Phabricator via cfe-commits
zequanwu updated this revision to Diff 291118.
zequanwu added a comment.
Herald added a reviewer: jdoerfert.
Herald added a subscriber: sstefan1.

- Address comment.
- Add cl::opt to disable emitting skipped regions for empty lines and comments 
(used on test case only), and update test cases under CoverageMapping with 
`-mllvm -emptyline-comment-coverage=false`.
- Remove the logic which only emits skipped regions for comments and empty 
lines parsing function body, because can't tell if it's inside class member 
function.
- Always set `SR.ColumnStart` to 1 in `adjustSkippedRange`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D84988

Files:
  clang/include/clang/Lex/Lexer.h
  clang/include/clang/Lex/Preprocessor.h
  clang/lib/CodeGen/CoverageMappingGen.cpp
  clang/lib/CodeGen/CoverageMappingGen.h
  clang/lib/Lex/Lexer.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/test/CoverageMapping/abspath.cpp
  clang/test/CoverageMapping/block-storage-starts-region.m
  clang/test/CoverageMapping/break.c
  clang/test/CoverageMapping/builtinmacro.c
  clang/test/CoverageMapping/casts.c
  clang/test/CoverageMapping/classtemplate.cpp
  clang/test/CoverageMapping/comment-in-macro.c
  clang/test/CoverageMapping/continue.c
  clang/test/CoverageMapping/control-flow-macro.c
  clang/test/CoverageMapping/coroutine.cpp
  clang/test/CoverageMapping/decl.c
  clang/test/CoverageMapping/default-method.cpp
  clang/test/CoverageMapping/deferred-region.cpp
  clang/test/CoverageMapping/empty-destructor.cpp
  clang/test/CoverageMapping/header.cpp
  clang/test/CoverageMapping/if.cpp
  clang/test/CoverageMapping/implicit-def-in-macro.m
  clang/test/CoverageMapping/include-macros.c
  clang/test/CoverageMapping/includehell.cpp
  clang/test/CoverageMapping/ir.c
  clang/test/CoverageMapping/label.cpp
  clang/test/CoverageMapping/lambda.cpp
  clang/test/CoverageMapping/logical.cpp
  clang/test/CoverageMapping/loopmacro.c
  clang/test/CoverageMapping/loops.cpp
  clang/test/CoverageMapping/macro-expansion.c
  clang/test/CoverageMapping/macro-expressions.cpp
  clang/test/CoverageMapping/macro-stringize-twice.cpp
  clang/test/CoverageMapping/macroception.c
  clang/test/CoverageMapping/macroparams.c
  clang/test/CoverageMapping/macroparams2.c
  clang/test/CoverageMapping/macros.c
  clang/test/CoverageMapping/macroscopes.cpp
  clang/test/CoverageMapping/md.cpp
  clang/test/CoverageMapping/moremacros.c
  clang/test/CoverageMapping/nestedclass.cpp
  clang/test/CoverageMapping/objc.m
  clang/test/CoverageMapping/openmp.c
  clang/test/CoverageMapping/pr32679.cpp
  clang/test/CoverageMapping/preprocessor.c
  clang/test/CoverageMapping/return.c
  clang/test/CoverageMapping/switch.cpp
  clang/test/CoverageMapping/switchmacro.c
  clang/test/CoverageMapping/system_macro.cpp
  clang/test/CoverageMapping/templates.cpp
  clang/test/CoverageMapping/test.c
  clang/test/CoverageMapping/trycatch.cpp
  clang/test/CoverageMapping/trymacro.cpp
  clang/test/CoverageMapping/unreachable-macro.c
  clang/test/CoverageMapping/unused_function.cpp
  clang/test/CoverageMapping/unused_names.c
  clang/test/CoverageMapping/while.c
  clang/test/lit.cfg.py
  compiler-rt/test/profile/coverage_emptylines.cpp
  compiler-rt/test/profile/instrprof-set-file-object-merging.c
  compiler-rt/test/profile/instrprof-set-file-object.c
  llvm/lib/ProfileData/Coverage/CoverageMapping.cpp

Index: llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
===
--- llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
+++ llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
@@ -485,9 +485,15 @@
   if (CurStartLoc == CR.value().endLoc()) {
 // Avoid making zero-length regions active. If it's the last region,
 // emit a skipped segment. Otherwise use its predecessor's count.
-const bool Skipped = (CR.index() + 1) == Regions.size();
+const bool Skipped =
+(CR.index() + 1) == Regions.size() ||
+CR.value().Kind == CounterMappingRegion::SkippedRegion;
 startSegment(ActiveRegions.empty() ? CR.value() : *ActiveRegions.back(),
  CurStartLoc, !GapRegion, Skipped);
+// If it is skipped segment, create a segment with last pushed
+// regions's count at CurStartLoc.
+if (Skipped && !ActiveRegions.empty())
+  startSegment(*ActiveRegions.back(), CurStartLoc, false);
 continue;
   }
   if (CR.index() + 1 == Regions.size() ||
@@ -587,6 +593,8 @@
   const auto  = Segments[I - 1];
   const auto  = Segments[I];
   if (!(L.Line < R.Line) && !(L.Line == R.Line && L.Col < R.Col)) {
+if (L.Line == R.Line && L.Col == R.Col && !L.HasCount)
+  continue;
 LLVM_DEBUG(dbgs() << " ! Segment " << L.Line << ":" << L.Col
   << " followed by " << R.Line << ":" << R.Col << "\n");
 assert(false && "Coverage 

[clang] b22d450 - Remove dependency on clangASTMatchers.

2020-09-10 Thread Michael Liao via cfe-commits

Author: Michael Liao
Date: 2020-09-10T22:17:48-04:00
New Revision: b22d45049682d1461b6b786f159681e2e5c2ce24

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

LOG: Remove dependency on clangASTMatchers.

- It seems no long required for shared library builds.

Added: 


Modified: 
clang/lib/CodeGen/CMakeLists.txt

Removed: 




diff  --git a/clang/lib/CodeGen/CMakeLists.txt 
b/clang/lib/CodeGen/CMakeLists.txt
index f47ecd9bf846..4039277707c5 100644
--- a/clang/lib/CodeGen/CMakeLists.txt
+++ b/clang/lib/CodeGen/CMakeLists.txt
@@ -92,7 +92,6 @@ add_clang_library(clangCodeGen
   LINK_LIBS
   clangAnalysis
   clangAST
-  clangASTMatchers
   clangBasic
   clangFrontend
   clangLex



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


Re: r364428 - Make CodeGen depend on ASTMatchers

2020-09-10 Thread Michael LIAO via cfe-commits
That change was added long ago to fix the shared library build.
Possibly, there are changes removing that dependency then. Just
verified that removing that dependency is just fine.

On Thu, Sep 10, 2020 at 6:48 AM Vassil Vassilev  wrote:
>
> Hello,
>
>IIUC, clang's CodeGen does not immediately depend on ASTMatchers. I
> was wondering what is the reason for inserting such a dependency to fix
> the shared library builds?
>
>Can you give more details about the failure you are fixing?
>
>Sorry for the late question.
>
> Best, Vassil
> On 6/26/19 5:13 PM, Michael Liao via cfe-commits wrote:
> > Author: hliao
> > Date: Wed Jun 26 07:13:43 2019
> > New Revision: 364428
> >
> > URL: http://llvm.org/viewvc/llvm-project?rev=364428=rev
> > Log:
> > Make CodeGen depend on ASTMatchers
> >
> > - Shared library builds are broken due to the missing dependency.
> >
> > Modified:
> >  cfe/trunk/lib/CodeGen/CMakeLists.txt
> >
> > Modified: cfe/trunk/lib/CodeGen/CMakeLists.txt
> > URL: 
> > http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CMakeLists.txt?rev=364428=364427=364428=diff
> > ==
> > --- cfe/trunk/lib/CodeGen/CMakeLists.txt (original)
> > +++ cfe/trunk/lib/CodeGen/CMakeLists.txt Wed Jun 26 07:13:43 2019
> > @@ -101,6 +101,7 @@ add_clang_library(clangCodeGen
> > LINK_LIBS
> > clangAnalysis
> > clangAST
> > +  clangASTMatchers
> > clangBasic
> > clangFrontend
> > clangLex
> >
> >
> > ___
> > cfe-commits mailing list
> > cfe-commits@lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D80409: [MS ABI] Add mangled type for auto template parameter whose argument kind is Integeral

2020-09-10 Thread Zequan Wu via Phabricator via cfe-commits
zequanwu updated this revision to Diff 29.
zequanwu marked 2 inline comments as done.
zequanwu retitled this revision from "[MS ABI] Add mangled type for auto 
template parameter whose argument kind is Integeral " to "[MS ABI] Add mangled 
type for auto template parameter whose argument kind is Integeral".
zequanwu added a comment.

rebase and address comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D80409

Files:
  clang/include/clang/Basic/LangOptions.h
  clang/lib/AST/MicrosoftMangle.cpp
  clang/test/CodeGenCXX/mangle-ms-auto-templates.cpp

Index: clang/test/CodeGenCXX/mangle-ms-auto-templates.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/mangle-ms-auto-templates.cpp
@@ -0,0 +1,33 @@
+// RUN: %clang_cc1 -std=c++17 -fms-compatibility-version=19.20 -emit-llvm %s -o - -fms-extensions -fdelayed-template-parsing -triple=x86_64-pc-windows-msvc | FileCheck %s
+
+template 
+class AutoParmTemplate {
+public:
+  AutoParmTemplate() {}
+};
+
+template 
+class AutoParmsTemplate {
+public:
+  AutoParmsTemplate() {}
+};
+
+void template_mangling() {
+  AutoParmTemplate<0> auto_int;
+  // CHECK: call {{.*}} @"??0?$AutoParmTemplate@$MH0A@@@QEAA@XZ"
+  AutoParmTemplate auto_bool;
+  // CHECK: call {{.*}} @"??0?$AutoParmTemplate@$M_N0A@@@QEAA@XZ"
+  AutoParmTemplate<'a'> auto_char;
+  // CHECK: call {{.*}} @"??0?$AutoParmTemplate@$MD0GB@@@QEAA@XZ"
+  AutoParmTemplate<9223372036854775807LL> int64_max;
+  // CHECK: call {{.*}} @"??0?$AutoParmTemplate@$M_J0HPPP@@@QEAA@XZ"
+  AutoParmTemplate<-9223372036854775807LL - 1LL> int64_min;
+  // CHECK: call {{.*}} @"??0?$AutoParmTemplate@$M_J0?IAAA@@@QEAA@XZ"
+  AutoParmTemplate<(unsigned long long)-1> uint64_neg_1;
+  // CHECK: call {{.*}} @"??0?$AutoParmTemplate@$M_K0?0@@QEAA@XZ"
+
+  AutoParmsTemplate<0, false, 'a'> c1;
+  // CHECK: call {{.*}} @"??0?$AutoParmsTemplate@$MH0A@$M_N0A@$MD0GB@@@QEAA@XZ"
+  AutoParmsTemplate<(unsigned long)1, 9223372036854775807LL> c2;
+  // CHECK: call {{.*}} @"??0?$AutoParmsTemplate@$MK00$M_J0HPPP@@@QEAA@XZ"
+}
Index: clang/lib/AST/MicrosoftMangle.cpp
===
--- clang/lib/AST/MicrosoftMangle.cpp
+++ clang/lib/AST/MicrosoftMangle.cpp
@@ -378,8 +378,10 @@
   void mangleFunctionClass(const FunctionDecl *FD);
   void mangleCallingConvention(CallingConv CC);
   void mangleCallingConvention(const FunctionType *T);
-  void mangleIntegerLiteral(const llvm::APSInt , bool IsBoolean);
-  void mangleExpression(const Expr *E);
+  void mangleIntegerLiteral(const llvm::APSInt ,
+const NonTypeTemplateParmDecl *PD = nullptr,
+QualType TemplateArgType = QualType());
+  void mangleExpression(const Expr *E, const NonTypeTemplateParmDecl *PD);
   void mangleThrowSpecification(const FunctionProtoType *T);
 
   void mangleTemplateArgs(const TemplateDecl *TD,
@@ -1357,24 +1359,35 @@
   mangleUnqualifiedName(TD);
 }
 
-void MicrosoftCXXNameMangler::mangleIntegerLiteral(const llvm::APSInt ,
-   bool IsBoolean) {
-  //  ::= $0 
-  Out << "$0";
-  // Make sure booleans are encoded as 0/1.
-  if (IsBoolean && Value.getBoolValue())
-mangleNumber(1);
-  else if (Value.isSigned())
+void MicrosoftCXXNameMangler::mangleIntegerLiteral(
+const llvm::APSInt , const NonTypeTemplateParmDecl *PD,
+QualType TemplateArgType) {
+  //  ::= $ [] 0 
+  Out << "$";
+
+  // mangle argument type if parmeter is auto
+  if (getASTContext().getLangOpts().isCompatibleWithMSVC(
+  LangOptions::MSVC2019) &&
+  PD && PD->getType()->getTypeClass() == Type::Auto &&
+  !TemplateArgType.isNull()) {
+Out << "M";
+mangleType(TemplateArgType, SourceRange(), QMM_Drop);
+  }
+
+  Out << "0";
+
+  if (Value.isSigned())
 mangleNumber(Value.getSExtValue());
   else
 mangleNumber(Value.getZExtValue());
 }
 
-void MicrosoftCXXNameMangler::mangleExpression(const Expr *E) {
+void MicrosoftCXXNameMangler::mangleExpression(
+const Expr *E, const NonTypeTemplateParmDecl *PD) {
   // See if this is a constant expression.
   if (Optional Value =
   E->getIntegerConstantExpr(Context.getASTContext())) {
-mangleIntegerLiteral(*Value, E->getType()->isBooleanType());
+mangleIntegerLiteral(*Value, PD, E->getType());
 return;
   }
 
@@ -1448,10 +1461,12 @@
 }
 break;
   }
-  case TemplateArgument::Integral:
+  case TemplateArgument::Integral: {
+QualType T = TA.getIntegralType();
 mangleIntegerLiteral(TA.getAsIntegral(),
- TA.getIntegralType()->isBooleanType());
+ cast(Parm), T);
 break;
+  }
   case TemplateArgument::NullPtr: {
 QualType T = TA.getNullPtrType();
 if (const MemberPointerType *MPT = T->getAs()) {
@@ -1473,16 +1488,18 

[PATCH] D87470: [Coroutine][Sema] Tighten the lifetime of symmetric transfer returned handle

2020-09-10 Thread JunMa via Phabricator via cfe-commits
junparser added a comment.

Thanks for the change. LGTM, and testcase?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87470

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


[PATCH] D87047: [clang] Add command line options for the Machine Function Splitter.

2020-09-10 Thread Snehasish Kumar via Phabricator via cfe-commits
snehasish marked 3 inline comments as done.
snehasish added a comment.

PTAL, thanks!




Comment at: clang/lib/Driver/ToolChains/Clang.cpp:4259
 options::OPT_fno_unique_basic_block_section_names,
+options::OPT_fsplit_machine_functions,
+options::OPT_fno_split_machine_functions,

MaskRay wrote:
> This is not needed.
> 
> This is for fembed-bitcode and people seem to randomly add options here. Many 
> options are probably not needed.
Thanks for catching this. I read this list as "options which should be ignored 
for embedding bitcode". In this case we do want to save this flag to pass back 
to clang if necessary (as mtrofin@ pointed out offline). Perhaps the 
documentation around this could be enhanced.



Comment at: clang/test/CodeGen/split-machine-functions.c:3
+
+// RUN: echo "foo"> %t.proftext
+// RUN: echo "# Func Hash:"   >> %t.proftext

MaskRay wrote:
> Consider `RUN: split-file`
> 
> Search for this string for some examples.
Looks much cleaner with split-file overall, though it doesn't play well with 
clang-format since this is a .c file. Should we just ignore clang-format 
complaints for this file?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87047

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


[PATCH] D87047: [clang] Add command line options for the Machine Function Splitter.

2020-09-10 Thread Snehasish Kumar via Phabricator via cfe-commits
snehasish updated this revision to Diff 291108.
snehasish added a comment.

Use OptInFFlag, split-file and update tests.

- Change the flag type to OptInFFlag.
- Use split-file in the test to avoid "RUN: echo" lines.
- Use an existing warn message (if no profile is available) and add a check for 
it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87047

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/split-machine-functions.c
  clang/test/Driver/fsplit-machine-functions.c

Index: clang/test/Driver/fsplit-machine-functions.c
===
--- /dev/null
+++ clang/test/Driver/fsplit-machine-functions.c
@@ -0,0 +1,9 @@
+// RUN: %clang -### -target x86_64 -fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
+// RUN: %clang -### -target x86_64 -fsplit-machine-functions -fno-split-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-NOOPT %s
+// RUN: %clang -c -target x86_64 -fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-WARN %s
+// RUN: not %clang -c -target arm-unknown-linux -fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-TRIPLE %s
+
+// CHECK-OPT:   "-fsplit-machine-functions"
+// CHECK-NOOPT-NOT: "-fsplit-machine-functions"
+// CHECK-WARN:  ignored -fsplit-machine-functions, no profile provided via -fprofile-use
+// CHECK-TRIPLE:error: unsupported option '-fsplit-machine-functions' for target
Index: clang/test/CodeGen/split-machine-functions.c
===
--- /dev/null
+++ clang/test/CodeGen/split-machine-functions.c
@@ -0,0 +1,37 @@
+// REQUIRES: x86-registered-target
+// RUN: split-file %s %t
+// RUN: llvm-profdata merge -o %t/default.profdata %t/proftext
+// RUN: %clang_cc1 -triple x86_64 -O3 -S -fprofile-instrument-use-path=%t/default.profdata -fsplit-machine-functions -o - < %t/code | FileCheck %s
+
+// CHECK: .section .text.hot.,"ax",@progbits
+// CHECK: foo:
+// CHECK: section .text.unlikely.foo,"ax",@progbits
+// CHECK: foo.cold:
+// CHECK: callq exit@PLT
+
+//--- proftext
+foo
+#Func Hash:
+11262309905
+#Num Counters:
+2
+#Counter Values:
+100 0
+
+//--- code
+__attribute__((noinline)) int
+foo(int argc) {
+  if (argc % 2 == 0) {
+exit(argc);
+  } else {
+return argc + 1;
+  }
+}
+
+int main(int argc, char *argv[]) {
+  int total = 0;
+  for (int i = 0; i < 100; ++i) {
+total += foo(argc);
+  }
+  printf("%d\n", total);
+}
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -998,6 +998,8 @@
   Opts.UniqueInternalLinkageNames =
   Args.hasArg(OPT_funique_internal_linkage_names);
 
+  Opts.SplitMachineFunctions = Args.hasArg(OPT_fsplit_machine_functions);
+
   Opts.MergeFunctions = Args.hasArg(OPT_fmerge_functions);
 
   Opts.NoUseJumpTables = Args.hasArg(OPT_fno_jump_tables);
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4911,6 +4911,15 @@
options::OPT_fno_unique_basic_block_section_names, false))
 CmdArgs.push_back("-funique-basic-block-section-names");
 
+  if (Arg *A = Args.getLastArg(options::OPT_fsplit_machine_functions,
+   options::OPT_fno_split_machine_functions)) {
+if (Triple.isX86() && Triple.isOSBinFormatELF())
+  A->render(Args, CmdArgs);
+else
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << A->getAsString(Args) << TripleStr;
+  }
+
   Args.AddLastArg(CmdArgs, options::OPT_finstrument_functions,
   options::OPT_finstrument_functions_after_inlining,
   options::OPT_finstrument_function_entry_bare);
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -9,6 +9,7 @@
 #include "clang/CodeGen/BackendUtil.h"
 #include "clang/Basic/CodeGenOptions.h"
 #include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticFrontend.h"
 #include "clang/Basic/LangOptions.h"
 #include "clang/Basic/TargetOptions.h"
 #include "clang/Frontend/FrontendDiagnostic.h"
@@ -514,6 +515,15 @@
   Options.BBSectionsFuncListBuf = std::move(*MBOrErr);
   }
 
+  if (CodeGenOpts.SplitMachineFunctions) {
+if (CodeGenOpts.getProfileUse() != CodeGenOptions::ProfileNone)
+  

[PATCH] D87395: Sema: add support for `__attribute__((__swift_objc_members__))`

2020-09-10 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr2 added inline comments.



Comment at: clang/test/SemaObjC/attr-swift_objc_members.m:4
+#if !__has_attribute(swift_objc_members)
+#error cannot verify precense of swift_objc_members attribute
+#endif

compnerd wrote:
> aaron.ballman wrote:
> > gribozavr2 wrote:
> > > aaron.ballman wrote:
> > > > gribozavr2 wrote:
> > > > > 
> > > > The typo fix makes sense to me, but for my own understanding, why 
> > > > switch to a string literal?
> > > IIUC, as it is now, the message is tokenized by the lexer -- and I think 
> > > that's not the intent, none of these words are program code.
> > Interesting and somewhat different from my understanding. My mental model 
> > for `#error` is that it "replays" the tokens into the diagnostic message up 
> > to the end of the line. Given that I prefer my diagnostics to be `warning: 
> > you did the wrong thing` and not `warning: "you did the wrong thing"` (with 
> > quotes), I usually leave the quotes off so that the error looks more 
> > consistent with other errors.
> > 
> > Neither form is more right than the other in this case, so I don't really 
> > care for this review (I was interested in it as a standards committee 
> > member who recently had to look at the specification for `#error` though).
> FWIW, the reason for the warning not being quoted currently is exactly what 
> @aaron.ballman stated ... that is how I process the `#error` directive as 
> well, and I tend to leave the quotes off to make the error match the other 
> diagnostics.  Is the quoting really that important?
No, not at all important.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87395

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


[PATCH] D87463: [clang][aarch64] Fix mangling of bfloat16 neon vectors

2020-09-10 Thread Ties Stuij via Phabricator via cfe-commits
stuij accepted this revision.
stuij added a comment.
This revision is now accepted and ready to land.

Thanks, this one crept in during mass-renaming.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87463

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


[PATCH] D86796: [Sema] Address-space sensitive index check for unbounded arrays

2020-09-10 Thread Chris Hamilton via Phabricator via cfe-commits
chrish_ericsson_atx added a comment.

Thank you for the comments, @aaron.ballman .   I'll update with the changes you 
requested shortly.  I did have some requests for clarification of you, though.  
Thanks!




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:8841-8844
+def warn_array_index_exceeds_max_addressable_bounds : Warning<
+  "array index %0 refers past the last possible element for an array in %1-bit 
"
+  "address space containing %2-bit (%3-byte) elements (max possible %4 
element%s5)">,
+  InGroup;

aaron.ballman wrote:
> I'd combine this with the above diagnostic given how similar they are:
> ```
> def warn_exceeds_max_addressable_bounds : Warning<
>   "%select{array index %1|the pointer incremented by %1}0 refers past the 
> last possible element for an array in %2-bit "
>   "address space containing %3-bit (%4-byte) elements (max possible %5 
> element%s6)">,
>   InGroup;
> ```
I was attempting to follow the pattern set by the preceding four definitions, 
which keep pointer math warnings and array index warnings separated, but are 
otherwise nearly identical.  If there's value in that pattern for those other 
warnings, I would assume the same value applies to keeping these separated.  
Please re-ping if you disagree, otherwise, I'll leave these as two separate 
warnings.



Comment at: clang/lib/Sema/SemaChecking.cpp:14063
+  if (isUnboundedArray) {
+if (index.isUnsigned() || !index.isNegative()) {
+  const auto  = getASTContext();

aaron.ballman wrote:
> ebevhan wrote:
> > This could be early return to avoid the indentation.
> +1 to using early return here. I might even get rid of `isUnboundedArray` and 
> just use `!BaseType`
@ebevhan's comment about early return was actually addressed in a previous 
diff... I should have marked it as such.  My apologies.

I'd prefer to keep `isUnboundedArray` (with the case corrected, of course), as 
it seems much clearer than `!BaseType` in terms of expressing what we are 
actually checking here, and why.



Comment at: clang/lib/Sema/SemaChecking.cpp:14100
+  // dependent CharUnits)
+  DiagRuntimeBehavior(BaseExpr->getBeginLoc(), BaseExpr,
+  PDiag(DiagID)

aaron.ballman wrote:
> It's not clear to me whether we need to pay the extra expense of doing 
> reachability checks for the diagnostic -- do you have evidence that there 
> would be a high false positive rate if we always emit the diagnostic?
Sorry-- I'm not following you here, @aaron.ballman. What reachability check are 
you referring to?  The diagnostic isn't conditioned on anything (at least not 
here, where your comment appears...), so I'm not sure what change you are 
suggesting that would "always emit the diagnostic"...  Sorry to be slow on the 
uptake here... Could you clarify that for me?



Comment at: clang/lib/Sema/SemaChecking.cpp:14111
+// Try harder to find a NamedDecl to point at in the note.
+while (const ArraySubscriptExpr *ASE =
+   dyn_cast(BaseExpr))

aaron.ballman wrote:
> You can use `const auto *` here since the type is spelled out in the 
> initialization. Same below.
Fair point -- this was just cut-and-paste from the code I had to duplicate in 
order to address the early return comment from @ebevhan.  :)  I'll change it in 
both places.



Comment at: clang/lib/Sema/SemaChecking.cpp:14121
+  if (ND)
+DiagRuntimeBehavior(ND->getBeginLoc(), BaseExpr,
+PDiag(diag::note_array_declared_here) << ND);

aaron.ballman wrote:
> Similar comment here about reachability.
Similar request for clarification.  ;)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86796

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


[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

2020-09-10 Thread Eli Friedman via Phabricator via cfe-commits
efriedma accepted this revision.
efriedma added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

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


[PATCH] D86621: [clang][Sparc] Default to -mcpu=v9 for SparcV8 on Solaris

2020-09-10 Thread Rainer Orth via Phabricator via cfe-commits
ro added a comment.

Ping?  It's been a week and AFAICT there's nothing left for me to do.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86621

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


[PATCH] D87395: Sema: add support for `__attribute__((__swift_objc_members__))`

2020-09-10 Thread Saleem Abdulrasool via Phabricator via cfe-commits
compnerd marked an inline comment as done.
compnerd added inline comments.



Comment at: clang/include/clang/Basic/Attr.td:2121
 
+def SwiftObjCMembers : Attr {
+  let Spellings = [GNU<"swift_objc_members">];

aaron.ballman wrote:
> Should this be inherited by redeclarations, or is that not a thing with 
> `ObjCInterfaceDecl`s?
Objective-C interfaces cannot be redeclared, so this actually is correct I 
believe.



Comment at: clang/lib/Sema/SemaDeclAttr.cpp:7546
+  case ParsedAttr::AT_SwiftObjCMembers:
+handleSimpleAttribute(S, D, AL);
+break;

aaron.ballman wrote:
> Does it matter if the user writes this attribute on an interface that exposes 
> no members? e.g., are there warnings we may want to give the user about using 
> the attribute in a weird way? (Sorry if this should be obvious, but I don't 
> have experience with Swift.)
I think that the name is not exactly helpful in this case, but that ship has 
sailed since this is in production already.  AIUI the attribute should apply to 
empty interfaces as it results in the Swift interface being exposed back to 
Objective-C.



Comment at: clang/test/SemaObjC/attr-swift_objc_members.m:4
+#if !__has_attribute(swift_objc_members)
+#error cannot verify precense of swift_objc_members attribute
+#endif

aaron.ballman wrote:
> gribozavr2 wrote:
> > aaron.ballman wrote:
> > > gribozavr2 wrote:
> > > > 
> > > The typo fix makes sense to me, but for my own understanding, why switch 
> > > to a string literal?
> > IIUC, as it is now, the message is tokenized by the lexer -- and I think 
> > that's not the intent, none of these words are program code.
> Interesting and somewhat different from my understanding. My mental model for 
> `#error` is that it "replays" the tokens into the diagnostic message up to 
> the end of the line. Given that I prefer my diagnostics to be `warning: you 
> did the wrong thing` and not `warning: "you did the wrong thing"` (with 
> quotes), I usually leave the quotes off so that the error looks more 
> consistent with other errors.
> 
> Neither form is more right than the other in this case, so I don't really 
> care for this review (I was interested in it as a standards committee member 
> who recently had to look at the specification for `#error` though).
FWIW, the reason for the warning not being quoted currently is exactly what 
@aaron.ballman stated ... that is how I process the `#error` directive as well, 
and I tend to leave the quotes off to make the error match the other 
diagnostics.  Is the quoting really that important?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87395

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


[PATCH] D87047: [clang] Add command line options for the Machine Function Splitter.

2020-09-10 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay requested changes to this revision.
MaskRay added inline comments.
This revision now requires changes to proceed.



Comment at: clang/include/clang/Driver/Options.td:1992
 
+def fsplit_machine_functions : Flag <["-"], "fsplit-machine-functions">,
+  Group, Flags<[CC1Option]>,

Please use `OptInFFlag` and see its comment.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:4259
 options::OPT_fno_unique_basic_block_section_names,
+options::OPT_fsplit_machine_functions,
+options::OPT_fno_split_machine_functions,

This is not needed.

This is for fembed-bitcode and people seem to randomly add options here. Many 
options are probably not needed.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:4922
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << "-fsplit-machine-functions" << TripleStr;
+  }

If you use getLastArg

A->getAsString(Args)



Comment at: clang/test/CodeGen/split-machine-functions.c:3
+
+// RUN: echo "foo"> %t.proftext
+// RUN: echo "# Func Hash:"   >> %t.proftext

Consider `RUN: split-file`

Search for this string for some examples.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87047

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


[PATCH] D80409: [MS ABI] Add mangled type for auto template parameter whose argument kind is Integeral

2020-09-10 Thread Reid "Away June-Sep" Kleckner via Phabricator via cfe-commits
rnk added inline comments.



Comment at: clang/lib/AST/MicrosoftMangle.cpp:383
+const NonTypeTemplateParmDecl *PD = nullptr,
+QualType *TemplateArgType = nullptr);
+  void mangleExpression(const Expr *E, const NonTypeTemplateParmDecl *PD);

I see you need an optional QualType here. Can you do this: `QualType 
TemplateArgType = QualType()`? I believe it will create a null QualType, which 
you can then check for with `.isNull()`.

QualType is pointer-sized and is generally passed by value. I think it will 
help make the other call sites shorter, so they don't need to take the address 
of a local variable.



Comment at: clang/lib/AST/MicrosoftMangle.cpp:1390
+QualType T = E->getType();
+mangleIntegerLiteral(Value, PD, );
 return;

For example, if you can avoid the pointer indirection, you can avoid the local 
variable here.


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

https://reviews.llvm.org/D80409

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


[PATCH] D87163: [DSE] Switch to MemorySSA-backed DSE by default.

2020-09-10 Thread Florian Hahn via Phabricator via cfe-commits
This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGfb109c42d91c: [DSE] Switch to MemorySSA-backed DSE by 
default. (authored by fhahn).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87163

Files:
  clang/test/CodeGen/thinlto-distributed-newpm.ll
  clang/test/CodeGenObjC/exceptions.m
  llvm/lib/Transforms/Scalar/DeadStoreElimination.cpp
  llvm/test/Analysis/BasicAA/modref.ll
  llvm/test/CodeGen/AMDGPU/opt-pipeline.ll
  llvm/test/Other/new-pm-defaults.ll
  llvm/test/Other/new-pm-lto-defaults.ll
  llvm/test/Other/new-pm-thinlto-defaults.ll
  llvm/test/Other/opt-O2-pipeline.ll
  llvm/test/Other/opt-O3-pipeline-enable-matrix.ll
  llvm/test/Other/opt-O3-pipeline.ll
  llvm/test/Other/opt-Os-pipeline.ll
  llvm/test/Transforms/Coroutines/ArgAddr.ll
  llvm/test/Transforms/Coroutines/coro-retcon.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/2011-03-25-DSEMiscompile.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/2011-09-06-EndOfFunction.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/2011-09-06-MemCpy.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/2016-07-17-UseAfterFree.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/OverwriteStoreBegin.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/OverwriteStoreEnd.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/PartialStore.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/PartialStore2.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/X86/gather-null-pointer.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/atomic-overlapping.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/atomic-todo.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/atomic.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/calloc-store.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/combined-partial-overwrites.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/const-pointers.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/crash.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/cs-cs-aliasing.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/debug-counter.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/debuginfo.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/dominate.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/fence-todo.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/fence.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/free.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/inst-limits.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/int_sideeffect.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/invariant.start.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/launder.invariant.group.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/libcalls.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/lifetime.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/mda-with-dbg-values.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/memcpy-complete-overwrite.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/memintrinsics.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/memoryssa-scan-limit.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/memset-and-memcpy.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/memset-missing-debugloc.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/memset-unknown-sizes.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/merge-stores-big-endian.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/merge-stores.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-captures.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-exceptions.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-loops.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-malloc-free.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-memintrinsics.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-memoryphis.ll
  
llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-multipath-throwing.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-multipath.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-overlap.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-partial.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-simple.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-throwing.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-unreachable.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/no-targetdata.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/noop-stores.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/operand-bundles.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/overlap.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/pr11390.ll
  
llvm/test/Transforms/DeadStoreElimination/MSSA/pr47285-not-overwritten-on-all-exit-paths.ll
  

[clang] fb109c4 - [DSE] Switch to MemorySSA-backed DSE by default.

2020-09-10 Thread Florian Hahn via cfe-commits

Author: Florian Hahn
Date: 2020-09-10T22:24:32+01:00
New Revision: fb109c42d91c30c8c7497ef1fd7aff6f2969c6e7

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

LOG: [DSE] Switch to MemorySSA-backed DSE by default.

The tests have been updated and I plan to move them from the MSSA
directory up.

Some end-to-end tests needed small adjustments. One difference to the
legacy DSE is that legacy DSE also deletes trivially dead instructions
that are unrelated to memory operations. Because MemorySSA-backed DSE
just walks the MemorySSA, we only visit/check memory instructions. But
removing unrelated dead instructions is not really DSE's job and other
passes will clean up.

One noteworthy change is in llvm/test/Transforms/Coroutines/ArgAddr.ll,
but I think this comes down to legacy DSE not handling instructions that
may throw correctly in that case. To cover this with MemorySSA-backed
DSE, we need an update to llvm.coro.begin to treat it's return value to
belong to the same underlying object as the passed pointer.

There are some minor cases MemorySSA-backed DSE currently misses, e.g. related
to atomic operations, but I think those can be implemented after the switch.

This has been discussed on llvm-dev:
http://lists.llvm.org/pipermail/llvm-dev/2020-August/144417.html

For the MultiSource/SPEC2000/SPEC2006 the number of eliminated stores
goes from ~17500 (legayc DSE) to ~26300 (MemorySSA-backed). More numbers
and details in the thread on llvm-dev.

Impact on CTMark:
```
 Legacy Pass Manager
exec instrssize-text
O3   + 0.60%- 0.27%
ReleaseThinLTO   + 1.00%- 0.42%
ReleaseLTO-g.+ 0.77%- 0.33%
RelThinLTO (link only)   + 0.87%- 0.42%
RelLO-g (link only)  + 0.78%- 0.33%
```
http://llvm-compile-time-tracker.com/compare.php?from=3f22e96d95c71ded906c67067d75278efb0a2525=ae8be4642533ff03803967ee9d7017c0d73b0ee0=instructions
```
 New Pass Manager
   exec instrs.   size-text
O3   + 0.95%   - 0.25%
ReleaseThinLTO   + 1.34%   - 0.41%
ReleaseLTO-g.+ 1.71%   - 0.35%
RelThinLTO (link only)   + 0.96%   - 0.41%
RelLO-g (link only)  + 2.21%   - 0.35%
```
http://195.201.131.214:8000/compare.php?from=3f22e96d95c71ded906c67067d75278efb0a2525=ae8be4642533ff03803967ee9d7017c0d73b0ee0=instructions

Reviewed By: asbirlea, xbolva00, nikic

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

Added: 


Modified: 
clang/test/CodeGen/thinlto-distributed-newpm.ll
clang/test/CodeGenObjC/exceptions.m
llvm/lib/Transforms/Scalar/DeadStoreElimination.cpp
llvm/test/Analysis/BasicAA/modref.ll
llvm/test/CodeGen/AMDGPU/opt-pipeline.ll
llvm/test/Other/new-pm-defaults.ll
llvm/test/Other/new-pm-lto-defaults.ll
llvm/test/Other/new-pm-thinlto-defaults.ll
llvm/test/Other/opt-O2-pipeline.ll
llvm/test/Other/opt-O3-pipeline-enable-matrix.ll
llvm/test/Other/opt-O3-pipeline.ll
llvm/test/Other/opt-Os-pipeline.ll
llvm/test/Transforms/Coroutines/ArgAddr.ll
llvm/test/Transforms/Coroutines/coro-retcon.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/2011-03-25-DSEMiscompile.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/2011-09-06-EndOfFunction.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/2011-09-06-MemCpy.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/2016-07-17-UseAfterFree.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/OverwriteStoreBegin.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/OverwriteStoreEnd.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/PartialStore.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/PartialStore2.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/X86/gather-null-pointer.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/atomic-overlapping.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/atomic-todo.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/atomic.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/calloc-store.ll

llvm/test/Transforms/DeadStoreElimination/MSSA/combined-partial-overwrites.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/const-pointers.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/crash.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/cs-cs-aliasing.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/debug-counter.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/debuginfo.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/dominate.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/fence-todo.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/fence.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/free.ll

[PATCH] D85473: [Clang] Add option to allow marking pass-by-value args as noalias.

2020-09-10 Thread Florian Hahn via Phabricator via cfe-commits
fhahn updated this revision to Diff 291083.
fhahn added a comment.

Also restrict to types that are `isNonTrivialToPrimitiveCopy`, so we do not add 
noalias for problematic types, like ObjC structs with weak references.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85473

Files:
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/pass-by-value-noalias.c
  clang/test/CodeGenCXX/pass-by-value-noalias.cpp
  clang/test/CodeGenObjC/pass-by-value-noalias.m

Index: clang/test/CodeGenObjC/pass-by-value-noalias.m
===
--- /dev/null
+++ clang/test/CodeGenObjC/pass-by-value-noalias.m
@@ -0,0 +1,22 @@
+// RUN: %clang_cc1 -fpass-by-value-is-noalias -triple arm64-apple-iphoneos -emit-llvm -disable-llvm-optzns -fobjc-runtime-has-weak -fobjc-arc -fobjc-dispatch-method=mixed %s -o - 2>&1 | FileCheck --check-prefix=WITH_NOALIAS %s
+// RUN: %clang_cc1 -triple arm64-apple-iphoneos -emit-llvm -disable-llvm-optzns -fobjc-runtime-has-weak -fobjc-arc -fobjc-dispatch-method=mixed %s -o - 2>&1 | FileCheck --check-prefix=NO_NOALIAS %s
+
+@interface Bar
+@property char value;
+@end
+
+// A struct large enough so it is not passed in registers on ARM64, but with a
+// weak reference, so noalias should not be added even with
+// -fpass-by-value-is-noalias.
+struct Foo {
+  int a;
+  int b;
+  int c;
+  int d;
+  int e;
+  Bar *__weak f;
+};
+
+// WITH_NOALIAS: define void @take(%struct.Foo* %arg)
+// NO_NOALIAS: define void @take(%struct.Foo* %arg)
+void take(struct Foo arg) {}
Index: clang/test/CodeGenCXX/pass-by-value-noalias.cpp
===
--- /dev/null
+++ clang/test/CodeGenCXX/pass-by-value-noalias.cpp
@@ -0,0 +1,43 @@
+// RUN: %clang_cc1 -fpass-by-value-is-noalias -triple arm64-apple-iphoneos -emit-llvm -disable-llvm-optzns %s -o - 2>&1 | FileCheck --check-prefix=WITH_NOALIAS %s
+// RUN: %clang_cc1 -triple arm64-apple-iphoneos -emit-llvm -disable-llvm-optzns %s -o - 2>&1 | FileCheck --check-prefix=NO_NOALIAS %s
+
+// A trivial struct large enough so it is not passed in registers on ARM64.
+struct Foo {
+  int a;
+  int b;
+  int c;
+  int d;
+  int e;
+  int f;
+};
+
+// Make sure noalias is added to indirect arguments with trivially copyable types
+// if -fpass-by-value-is-noalias is provided.
+
+// WITH_NOALIAS: define void @_Z4take3Foo(%struct.Foo* noalias %arg)
+// NO_NOALIAS: define void @_Z4take3Foo(%struct.Foo* %arg)
+void take(Foo arg) {}
+
+int G;
+
+// NonTrivial is not trivially-copyable, because it has a non-trivial copy
+// constructor.
+struct NonTrivial {
+  int a;
+  int b;
+  int c;
+  int d;
+  int e;
+  int f;
+
+  NonTrivial(const NonTrivial ) {
+a = G + 10 + Other.a;
+  }
+};
+
+// Make sure noalias is not added to indirect arguments that are not trivially
+// copyable even if -fpass-by-value-is-noalias is provided.
+
+// WITH_NOALIAS: define void @_Z4take10NonTrivial(%struct.NonTrivial* %arg)
+// NO_NOALIAS:   define void @_Z4take10NonTrivial(%struct.NonTrivial* %arg)
+void take(NonTrivial arg) {}
Index: clang/test/CodeGen/pass-by-value-noalias.c
===
--- /dev/null
+++ clang/test/CodeGen/pass-by-value-noalias.c
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -fpass-by-value-is-noalias -triple arm64-apple-iphoneos -emit-llvm -disable-llvm-optzns %s -o - 2>&1 | FileCheck --check-prefix=WITH_NOALIAS %s
+// RUN: %clang_cc1 -triple arm64-apple-iphoneos -emit-llvm -disable-llvm-optzns %s -o - 2>&1 | FileCheck --check-prefix=NO_NOALIAS %s
+
+// A struct large enough so it is not passed in registers on ARM64.
+struct Foo {
+  int a;
+  int b;
+  int c;
+  int d;
+  int e;
+  int f;
+};
+
+// WITH_NOALIAS: define void @take(%struct.Foo* noalias %arg)
+// NO_NOALIAS: define void @take(%struct.Foo* %arg)
+void take(struct Foo arg) {}
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1453,6 +1453,8 @@
   std::string(Args.getLastArgValue(OPT_fsymbol_partition_EQ));
 
   Opts.ForceAAPCSBitfieldLoad = Args.hasArg(OPT_ForceAAPCSBitfieldLoad);
+
+  Opts.PassByValueIsNoAlias = Args.hasArg(OPT_fpass_by_value_is_noalias);
   return Success;
 }
 
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -2201,6 +2201,13 @@
   if (AI.getIndirectByVal())
 Attrs.addByValAttr(getTypes().ConvertTypeForMem(ParamType));
 
+  if (CodeGenOpts.PassByValueIsNoAlias &&
+  ParamType.isTriviallyCopyableType(getContext()) &&
+  

[PATCH] D87482: Fix clang Wrange-loop-analysis in BuildTree.cpp

2020-09-10 Thread Jeff Hemphill via Phabricator via cfe-commits
jthemphill created this revision.
jthemphill added a reviewer: eduucaldas.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
jthemphill requested review of this revision.

Building on Mac OS with clang 12:

  jhemphill@jhemphill-mbp build % clang --version
  Apple clang version 12.0.0 (clang-1200.0.26.2)
  Target: x86_64-apple-darwin19.6.0
  Thread model: posix
  InstalledDir: /Library/Developer/CommandLineTools/usr/bin

yields one warning:

  
/Users/jhemphill/oss/llvm-project/clang/lib/Tooling/Syntax/BuildTree.cpp:1126:22:
 warning: loop variable 'Arg' is always a copy because the range of type 
'llvm::iterator_range >' does not return a reference [-Wrange-loop-analysis]
  for (const auto  : Args) {
   ^
  
/Users/jhemphill/oss/llvm-project/clang/lib/Tooling/Syntax/BuildTree.cpp:1126:10:
 note: use non-reference type 'clang::Expr *'
  for (const auto  : Args) {

It appears that `Arg` is an `Expr*`, passed by value rather than by const 
reference.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87482

Files:
  clang/lib/Tooling/Syntax/BuildTree.cpp


Index: clang/lib/Tooling/Syntax/BuildTree.cpp
===
--- clang/lib/Tooling/Syntax/BuildTree.cpp
+++ clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -1123,7 +1123,7 @@
   syntax::CallArguments *
   buildCallArguments(CallExpr::arg_range ArgsAndDefaultArgs) {
 auto Args = dropDefaultArgs(ArgsAndDefaultArgs);
-for (const auto  : Args) {
+for (auto *Arg : Args) {
   Builder.markExprChild(Arg, syntax::NodeRole::ListElement);
   const auto *DelimiterToken =
   std::next(Builder.findToken(Arg->getEndLoc()));


Index: clang/lib/Tooling/Syntax/BuildTree.cpp
===
--- clang/lib/Tooling/Syntax/BuildTree.cpp
+++ clang/lib/Tooling/Syntax/BuildTree.cpp
@@ -1123,7 +1123,7 @@
   syntax::CallArguments *
   buildCallArguments(CallExpr::arg_range ArgsAndDefaultArgs) {
 auto Args = dropDefaultArgs(ArgsAndDefaultArgs);
-for (const auto  : Args) {
+for (auto *Arg : Args) {
   Builder.markExprChild(Arg, syntax::NodeRole::ListElement);
   const auto *DelimiterToken =
   std::next(Builder.findToken(Arg->getEndLoc()));
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D87163: [DSE] Switch to MemorySSA-backed DSE by default.

2020-09-10 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added a comment.

In D87163#2266725 , @asbirlea wrote:

> I'm running additional testing in the background. I don't have anything 
> holding this back at this point.
> Either check in and if something shows up, I'll let you know to resolve or 
> revert, or wait another 1-2 days for the testing I'm running to complete.
> I'm ok with either option, and may even be inclined for the former, because 
> there may be additional parties coming forward if issues arise, and I'd like 
> these to come up earlier rather than later.

SGTM, I expect a few hiccups and it's probably best to get started early. I'll 
commit shortly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87163

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


[PATCH] D87163: [DSE] Switch to MemorySSA-backed DSE by default.

2020-09-10 Thread Alina Sbirlea via Phabricator via cfe-commits
asbirlea accepted this revision.
asbirlea added a comment.
This revision is now accepted and ready to land.

I'm running additional testing in the background. I don't have anything holding 
this back at this point.
Either check in and if something shows up, I'll let you know to resolve or 
revert, or wait another 1-2 days for the testing I'm running to complete.
I'm ok with either option, and may even be inclined for the former, because 
there may be additional parties coming forward if issues arise, and I'd like 
these to come up earlier rather than later.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87163

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


[PATCH] D87163: [DSE] Switch to MemorySSA-backed DSE by default.

2020-09-10 Thread Florian Hahn via Phabricator via cfe-commits
fhahn updated this revision to Diff 291078.
fhahn added a comment.

Final rebase after new memcpy test.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87163

Files:
  clang/test/CodeGen/thinlto-distributed-newpm.ll
  clang/test/CodeGenObjC/exceptions.m
  llvm/lib/Transforms/Scalar/DeadStoreElimination.cpp
  llvm/test/Analysis/BasicAA/modref.ll
  llvm/test/CodeGen/AMDGPU/opt-pipeline.ll
  llvm/test/Other/new-pm-defaults.ll
  llvm/test/Other/new-pm-lto-defaults.ll
  llvm/test/Other/new-pm-thinlto-defaults.ll
  llvm/test/Other/opt-O2-pipeline.ll
  llvm/test/Other/opt-O3-pipeline-enable-matrix.ll
  llvm/test/Other/opt-O3-pipeline.ll
  llvm/test/Other/opt-Os-pipeline.ll
  llvm/test/Transforms/Coroutines/ArgAddr.ll
  llvm/test/Transforms/Coroutines/coro-retcon.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/2011-03-25-DSEMiscompile.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/2011-09-06-EndOfFunction.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/2011-09-06-MemCpy.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/2016-07-17-UseAfterFree.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/OverwriteStoreBegin.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/OverwriteStoreEnd.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/PartialStore.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/PartialStore2.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/X86/gather-null-pointer.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/atomic-overlapping.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/atomic-todo.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/atomic.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/calloc-store.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/combined-partial-overwrites.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/const-pointers.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/crash.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/cs-cs-aliasing.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/debug-counter.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/debuginfo.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/dominate.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/fence-todo.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/fence.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/free.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/inst-limits.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/int_sideeffect.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/invariant.start.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/launder.invariant.group.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/libcalls.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/lifetime.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/mda-with-dbg-values.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/memcpy-complete-overwrite.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/memintrinsics.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/memoryssa-scan-limit.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/memset-and-memcpy.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/memset-missing-debugloc.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/memset-unknown-sizes.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/merge-stores-big-endian.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/merge-stores.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-captures.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-exceptions.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-loops.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-malloc-free.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-memintrinsics.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-memoryphis.ll
  
llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-multipath-throwing.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-multipath.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-overlap.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-partial.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-simple.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-throwing.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-unreachable.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/no-targetdata.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/noop-stores.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/operand-bundles.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/overlap.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/pr11390.ll
  
llvm/test/Transforms/DeadStoreElimination/MSSA/pr47285-not-overwritten-on-all-exit-paths.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/simple-preservation.ll
  llvm/test/Transforms/DeadStoreElimination/MSSA/simple-todo.ll
  

[PATCH] D83144: Allow to specify macro names for android-comparison-in-temp-failure-retry.

2020-09-10 Thread Stephen Hines via Phabricator via cfe-commits
srhines added inline comments.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/android-comparison-in-temp-failure-retry.c:1
-// RUN: %check_clang_tidy %s android-comparison-in-temp-failure-retry %t
+// RUN: %check_clang_tidy %s android-comparison-in-temp-failure-retry %t -- 
-config="{CheckOptions: [{key: 
android-comparison-in-temp-failure-retry.RetryMacros, value: 
'TEMP_FAILURE_RETRY,MY_TEMP_FAILURE_RETRY'}]}"
 

Ideally there should either be another RUN macro here without your new options, 
or there should be a separate test/file for checking here, since we'd like to 
make sure that the default behavior still works.



Comment at: 
clang-tools-extra/test/clang-tidy/checkers/android-comparison-in-temp-failure-retry.c:28
   TEMP_FAILURE_RETRY(foo());
   TEMP_FAILURE_RETRY((foo()));
 

Don't you want a check for `MY_TEMP_FAILURE_RETRY` for cases like this too (to 
make sure that it is detecting them)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83144

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


[PATCH] D87331: Sema: add support for `__attribute__((__swift_error__))`

2020-09-10 Thread Saleem Abdulrasool via Phabricator via cfe-commits
compnerd added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:3394
+parameter. Currently, the error parameter is always the last parameter of type
+``NSError**`` or ``CFErrorRef*``.  Swift will remove the error parameter from
+the imported API. When calling the API, Swift will always pass a valid address

aaron.ballman wrote:
> compnerd wrote:
> > rjmccall wrote:
> > > compnerd wrote:
> > > > aaron.ballman wrote:
> > > > > Canonical type or are typedefs to these types also fine? May want to 
> > > > > mention that the type has to be cv-unqualified, but I do wonder 
> > > > > whether something like `NSError * const *` is fine.
> > > > I am definitely not the authority on this, but I believe that the 
> > > > common thing is to take `NSError **` or `CFErrorRef **` by canonical 
> > > > name.  The cv-qualified versions, except on the outermost pointer, is 
> > > > something that can be treated as valid, though it is certainly 
> > > > extremely unusual.  I've added test cases for them as well.
> > > `NSError * const *` actually does not really work; the whole point is 
> > > that this is an out-parameter.
> > Oh right, its the `const NSError ** const` that can work, because the outer 
> > pointer can be non-mutable as it is a pointer by-reference scenario.  
> > Should we diagnose the `NSError * const *` case then?  Any `const` 
> > qualified value is really unidiomatic to say the least.
> I think we should diagnose (as an error) any case that can't work.
> 
> I think it may make sense to diagnose (as a warning) any case where we want 
> to ignore the qualifiers, in case we want to give semantics to those 
> qualifiers in this situation later. So this means we'd error on `NSError * 
> const *` but warn and ignore the qualifiers on `volatile NSError **`. 
> However, I don't insist on warning in this case unless there's a situation 
> that the user might actually appreciate the warning because it matters (it's 
> not clear to me if such a situation exists). Also, it's not clear to me 
> whether we should or should not warn on a `restrict`-qualified pointer.
I think that the newer diagnostics would make sense as a follow up improvement 
in the case that @rjmccall believe that they would be useful to users.  As John 
mentioned, `const` is rarely used with ObjectiveC, so the use of that is pretty 
unidiomatic.  In fact, trying to return the error would cause a warning in the 
first place (due to the assignment of a value to a `const` parameter).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87331

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


[PATCH] D87395: Sema: add support for `__attribute__((__swift_objc_members__))`

2020-09-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:3387
+The ``swift_objc_members`` attribute maps to the ``@objcMembers`` Swift
+attribute, which indicates that Swift members of this class, its subclasses, 
and
+all extensions thereof, will implicitly be exposed back to Objective-C.

gribozavr2 wrote:
> aaron.ballman wrote:
> > gribozavr2 wrote:
> > > aaron.ballman wrote:
> > > > The documentation is a bit hard to follow -- the user is going to be 
> > > > adding this attribute to an ObjC interface, so the docs should be 
> > > > talking about what that means from the ObjC side of things more so than 
> > > > the Swift side, no?
> > > IIUC, this attribute has no effect on the Objective-C users of this type.
> > It may not have semantic impact on the ObjC side of things, but I'd still 
> > expect that since the user is writing it on an ObjC entity, the docs talk 
> > about it from that perspective. 
> > 
> > e.g., I'd expect the documentation to be more along the lines of "The 
> > attribute indicates that the members of this Objective-C 
> > class/protocol/whatever, its subclasses and so on, will be exposed as Swift 
> > class members that do the awesome thing." instead of "In Swift, this other 
> > attribute does things similar to what this one does in Objective-C."
> Sure, how about this: "This attribute indicates that Swift subclasses and 
> members of Swift extensions of this class will be implicitly marked with the 
> ``@objcMembers`` Swift attribute."
> 
> (This attribute has no effect on this class itself or its members, even when 
> imported in Swift -- only on Swift extensions & subclasses.)
That sounds better to me, thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87395

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


[PATCH] D73425: [PPC] Fix platform definitions when compiling FreeBSD powerpc64 as LE

2020-09-10 Thread Dimitry Andric via Phabricator via cfe-commits
dim added a comment.

In D73425#2266446 , @Bdragon28 wrote:

> Any chance of a backport to 11?

I submitted https://bugs.llvm.org/show_bug.cgi?id=47485 for this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73425

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


[PATCH] D87395: Sema: add support for `__attribute__((__swift_objc_members__))`

2020-09-10 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr2 added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:3387
+The ``swift_objc_members`` attribute maps to the ``@objcMembers`` Swift
+attribute, which indicates that Swift members of this class, its subclasses, 
and
+all extensions thereof, will implicitly be exposed back to Objective-C.

aaron.ballman wrote:
> gribozavr2 wrote:
> > aaron.ballman wrote:
> > > The documentation is a bit hard to follow -- the user is going to be 
> > > adding this attribute to an ObjC interface, so the docs should be talking 
> > > about what that means from the ObjC side of things more so than the Swift 
> > > side, no?
> > IIUC, this attribute has no effect on the Objective-C users of this type.
> It may not have semantic impact on the ObjC side of things, but I'd still 
> expect that since the user is writing it on an ObjC entity, the docs talk 
> about it from that perspective. 
> 
> e.g., I'd expect the documentation to be more along the lines of "The 
> attribute indicates that the members of this Objective-C 
> class/protocol/whatever, its subclasses and so on, will be exposed as Swift 
> class members that do the awesome thing." instead of "In Swift, this other 
> attribute does things similar to what this one does in Objective-C."
Sure, how about this: "This attribute indicates that Swift subclasses and 
members of Swift extensions of this class will be implicitly marked with the 
``@objcMembers`` Swift attribute."

(This attribute has no effect on this class itself or its members, even when 
imported in Swift -- only on Swift extensions & subclasses.)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87395

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


[PATCH] D73425: [PPC] Fix platform definitions when compiling FreeBSD powerpc64 as LE

2020-09-10 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a subscriber: hans.
MaskRay added a comment.

In D73425#2266446 , @Bdragon28 wrote:

> Any chance of a backport to 11?

CC the release manager @hans

Perhaps there is still time 
http://lists.llvm.org/pipermail/llvm-dev/2020-September/144961.html


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73425

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


[PATCH] D87395: Sema: add support for `__attribute__((__swift_objc_members__))`

2020-09-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:3387
+The ``swift_objc_members`` attribute maps to the ``@objcMembers`` Swift
+attribute, which indicates that Swift members of this class, its subclasses, 
and
+all extensions thereof, will implicitly be exposed back to Objective-C.

gribozavr2 wrote:
> aaron.ballman wrote:
> > The documentation is a bit hard to follow -- the user is going to be adding 
> > this attribute to an ObjC interface, so the docs should be talking about 
> > what that means from the ObjC side of things more so than the Swift side, 
> > no?
> IIUC, this attribute has no effect on the Objective-C users of this type.
It may not have semantic impact on the ObjC side of things, but I'd still 
expect that since the user is writing it on an ObjC entity, the docs talk about 
it from that perspective. 

e.g., I'd expect the documentation to be more along the lines of "The attribute 
indicates that the members of this Objective-C class/protocol/whatever, its 
subclasses and so on, will be exposed as Swift class members that do the 
awesome thing." instead of "In Swift, this other attribute does things similar 
to what this one does in Objective-C."



Comment at: clang/test/SemaObjC/attr-swift_objc_members.m:4
+#if !__has_attribute(swift_objc_members)
+#error cannot verify precense of swift_objc_members attribute
+#endif

gribozavr2 wrote:
> aaron.ballman wrote:
> > gribozavr2 wrote:
> > > 
> > The typo fix makes sense to me, but for my own understanding, why switch to 
> > a string literal?
> IIUC, as it is now, the message is tokenized by the lexer -- and I think 
> that's not the intent, none of these words are program code.
Interesting and somewhat different from my understanding. My mental model for 
`#error` is that it "replays" the tokens into the diagnostic message up to the 
end of the line. Given that I prefer my diagnostics to be `warning: you did the 
wrong thing` and not `warning: "you did the wrong thing"` (with quotes), I 
usually leave the quotes off so that the error looks more consistent with other 
errors.

Neither form is more right than the other in this case, so I don't really care 
for this review (I was interested in it as a standards committee member who 
recently had to look at the specification for `#error` though).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87395

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


[PATCH] D87395: Sema: add support for `__attribute__((__swift_objc_members__))`

2020-09-10 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr2 added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:3387
+The ``swift_objc_members`` attribute maps to the ``@objcMembers`` Swift
+attribute, which indicates that Swift members of this class, its subclasses, 
and
+all extensions thereof, will implicitly be exposed back to Objective-C.

aaron.ballman wrote:
> The documentation is a bit hard to follow -- the user is going to be adding 
> this attribute to an ObjC interface, so the docs should be talking about what 
> that means from the ObjC side of things more so than the Swift side, no?
IIUC, this attribute has no effect on the Objective-C users of this type.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87395

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


[PATCH] D87395: Sema: add support for `__attribute__((__swift_objc_members__))`

2020-09-10 Thread Dmitri Gribenko via Phabricator via cfe-commits
gribozavr2 added inline comments.



Comment at: clang/test/SemaObjC/attr-swift_objc_members.m:4
+#if !__has_attribute(swift_objc_members)
+#error cannot verify precense of swift_objc_members attribute
+#endif

aaron.ballman wrote:
> gribozavr2 wrote:
> > 
> The typo fix makes sense to me, but for my own understanding, why switch to a 
> string literal?
IIUC, as it is now, the message is tokenized by the lexer -- and I think that's 
not the intent, none of these words are program code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87395

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


[PATCH] D85408: Let -basic-block-sections=labels emit basicblock metadata in a new .bb_addr_map section, instead of emitting special unary-encoded symbols.

2020-09-10 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

In D85408#2262134 , @rahmanl wrote:

> @efriedma Would you please chime in specially with respect to @MaskRay 's 
> comment about the clang test involving assembly?

I'll chime in, perhaps @efriedma will/can too: This patch has no changes to 
Clang's code, so it should have no changes to Clang's tests, generally speaking.

Whatever codepath/behavior is being tested by that Clang test change should be 
testable (& generally only tested) via LLVM's tools/tests, like llc, I would 
expect? (I guess that's what the basic-block-sections-labels.ll test is doing? 
Making the Clang test update redundant)

The only reason I'd expect to see the assembly tested in Clang is if the flag 
that enables this feature is an MCOptions (or other similar API level feature) 
member, rather than part of LLVM IR proper. In that case the only way to test 
that the flag has any effect (since we can't observe the MCOptions struct state 
directly in a test) is to test for the MCOptions effect on LLVM's output. 
Depending on the complexity, sometimes such tests are just skipped entirely 
(leaving the setting of the MCOption untested) - I think I did that for, for 
example, DWARF type units. Other times, an end-to-end test is used to ensure 
the flag is working. But that's all the test should do: test the flag is 
working, with some very basic/rudimentary property of the feature being enabled 
(so pretty much /any/ change to the way the feature works will still pass the 
test, but if the feature were turned off entirely (the MCOptions flag stopped 
being set correctly), the test would fail). Not test all the functionality of 
the feature that the flag enables - all that testing should be down in LLVM.




Comment at: llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:1058
+  // Emit BB Information for each basic block in the funciton.
+  for (const auto  : MF) {
+const MCSymbol *MBBSymbol =

MaskRay wrote:
> auto -> MachineBasicBlock
FWIW, auto seems pretty fine to me here - looking only at for loops over MBB, a 
rough grep/count seems like there's certainly a lot of both (194 (non-auto) to 
168 (auto)) and I think it qualifies as "obvious" for LLVM backend code that an 
MBB variable would be of the type MachineBasicBlock. (bonus points for 
obviousness that MF is a MachineFunction)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85408

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


[PATCH] D86089: [flang][driver]Add experimental flang driver and frontend with help screen

2020-09-10 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski updated this revision to Diff 291068.
awarzynski marked 2 inline comments as done.
awarzynski added a comment.

Address final comments

I also took the liberty and made the following changes in CMake scripts:

- replaced add_library wiht add_flang_library
- replaced add_executable with add_flang_tool

These are all NFCs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86089

Files:
  clang/include/clang/Driver/Driver.h
  clang/include/clang/Driver/Options.h
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChains/Flang.cpp
  clang/lib/Frontend/CreateInvocationFromCommandLine.cpp
  clang/lib/Tooling/Tooling.cpp
  clang/test/Driver/flang/flang.f90
  clang/test/Driver/flang/flang_ucase.F90
  clang/test/Driver/flang/multiple-inputs-mixed.f90
  clang/test/Driver/flang/multiple-inputs.f90
  clang/unittests/Driver/SanitizerArgsTest.cpp
  clang/unittests/Driver/ToolChainTest.cpp
  flang/CMakeLists.txt
  flang/README.md
  flang/include/flang/Frontend/CompilerInstance.h
  flang/include/flang/Frontend/CompilerInvocation.h
  flang/include/flang/Frontend/FrontendOptions.h
  flang/include/flang/FrontendTool/Utils.h
  flang/lib/CMakeLists.txt
  flang/lib/Frontend/CMakeLists.txt
  flang/lib/Frontend/CompilerInstance.cpp
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendOptions.cpp
  flang/lib/FrontendTool/CMakeLists.txt
  flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  flang/test/CMakeLists.txt
  flang/test/Flang-Driver/driver-error-cc1.c
  flang/test/Flang-Driver/driver-error-cc1.cpp
  flang/test/Flang-Driver/driver-help.f90
  flang/test/Flang-Driver/driver-version.f90
  flang/test/Flang-Driver/emit-obj.f90
  flang/test/Flang-Driver/missing-input.f90
  flang/test/lit.cfg.py
  flang/test/lit.site.cfg.py.in
  flang/tools/CMakeLists.txt
  flang/tools/flang-driver/CMakeLists.txt
  flang/tools/flang-driver/driver.cpp
  flang/tools/flang-driver/fc1_main.cpp
  flang/unittests/CMakeLists.txt
  flang/unittests/Frontend/CMakeLists.txt
  flang/unittests/Frontend/CompilerInstanceTest.cpp
  llvm/include/llvm/Option/OptTable.h

Index: llvm/include/llvm/Option/OptTable.h
===
--- llvm/include/llvm/Option/OptTable.h
+++ llvm/include/llvm/Option/OptTable.h
@@ -50,7 +50,7 @@
 unsigned ID;
 unsigned char Kind;
 unsigned char Param;
-unsigned short Flags;
+unsigned int Flags;
 unsigned short GroupID;
 unsigned short AliasID;
 const char *AliasArgs;
Index: flang/unittests/Frontend/CompilerInstanceTest.cpp
===
--- /dev/null
+++ flang/unittests/Frontend/CompilerInstanceTest.cpp
@@ -0,0 +1,52 @@
+//===- unittests/Frontend/CompilerInstanceTest.cpp - CI tests -===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "flang/Frontend/CompilerInstance.h"
+#include "gtest/gtest.h"
+#include "flang/Frontend/CompilerInvocation.h"
+#include "clang/Basic/DiagnosticOptions.h"
+#include "clang/Driver/Options.h"
+#include "clang/Frontend/TextDiagnosticPrinter.h"
+#include "llvm/Support/raw_ostream.h"
+
+#include 
+using namespace llvm;
+using namespace Fortran::frontend;
+
+namespace {
+
+TEST(CompilerInstance, AllowDiagnosticLogWithUnownedDiagnosticConsumer) {
+  // 1. Set-up a basic DiagnosticConsumer
+  std::string diagnosticOutput;
+  llvm::raw_string_ostream diagnosticsOS(diagnosticOutput);
+  auto diagPrinter = std::make_unique(
+  diagnosticsOS, new clang::DiagnosticOptions());
+
+  // 2. Create a CompilerInstance (to manage a DiagnosticEngine)
+  CompilerInstance compInst;
+
+  // 3. Set-up DiagnosticOptions
+  auto diagOpts = new clang::DiagnosticOptions();
+  // Tell the diagnostics engine to emit the diagnostic log to STDERR. This
+  // ensures that a chained diagnostic consumer is created so that the test can
+  // exercise the unowned diagnostic consumer in a chained consumer.
+  diagOpts->DiagnosticLogFile = "-";
+
+  // 4. Create a DiagnosticEngine with an unowned consumer
+  IntrusiveRefCntPtr diags =
+  compInst.CreateDiagnostics(diagOpts, diagPrinter.get(),
+  /*ShouldOwnClient=*/false);
+
+  // 5. Report a diagnostic
+  diags->Report(clang::diag::err_expected) << "no crash";
+
+  // 6. Verify that the reported diagnostic wasn't lost and did end up in the
+  // output stream
+  ASSERT_EQ(diagnosticsOS.str(), "error: expected no crash\n");
+}
+} // namespace
Index: flang/unittests/Frontend/CMakeLists.txt
===
--- /dev/null
+++ flang/unittests/Frontend/CMakeLists.txt
@@ -0,0 

[PATCH] D83144: Allow to specify macro names for android-comparison-in-temp-failure-retry.

2020-09-10 Thread Florian Mayer via Phabricator via cfe-commits
fmayer added a comment.

Hey, any updates on this? :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83144

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


[clang] 4934127 - Diable sanitizer options for amdgpu

2020-09-10 Thread Yaxun Liu via cfe-commits

Author: Yaxun (Sam) Liu
Date: 2020-09-10T15:41:07-04:00
New Revision: 4934127e627d7c58342be15bc9230a7cbdf5273f

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

LOG: Diable sanitizer options for amdgpu

Currently AMDGPU does not support sanitizer. Disable
sanitizer options for now until they are supported.

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

Added: 
clang/test/Driver/hip-sanitize-options.hip

Modified: 
clang/lib/Driver/SanitizerArgs.cpp

Removed: 




diff  --git a/clang/lib/Driver/SanitizerArgs.cpp 
b/clang/lib/Driver/SanitizerArgs.cpp
index 0f51443010ca..0cb1e7b5282b 100644
--- a/clang/lib/Driver/SanitizerArgs.cpp
+++ b/clang/lib/Driver/SanitizerArgs.cpp
@@ -929,10 +929,10 @@ static bool hasTargetFeatureMTE(const 
llvm::opt::ArgStringList ) {
 void SanitizerArgs::addArgs(const ToolChain , const llvm::opt::ArgList 
,
 llvm::opt::ArgStringList ,
 types::ID InputType) const {
-  // NVPTX doesn't currently support sanitizers.  Bailing out here means that
-  // e.g. -fsanitize=address applies only to host code, which is what we want
-  // for now.
-  if (TC.getTriple().isNVPTX())
+  // NVPTX/AMDGPU doesn't currently support sanitizers.  Bailing out here means
+  // that e.g. -fsanitize=address applies only to host code, which is what we
+  // want for now.
+  if (TC.getTriple().isNVPTX() || TC.getTriple().isAMDGPU())
 return;
 
   // Translate available CoverageFeatures to corresponding clang-cc1 flags.

diff  --git a/clang/test/Driver/hip-sanitize-options.hip 
b/clang/test/Driver/hip-sanitize-options.hip
new file mode 100644
index ..908e02136cad
--- /dev/null
+++ b/clang/test/Driver/hip-sanitize-options.hip
@@ -0,0 +1,9 @@
+// REQUIRES: clang-driver, x86-registered-target, amdgpu-registered-target
+
+// RUN: %clang -### -target x86_64-unknown-linux-gnu --offload-arch=gfx906 \
+// RUN:   -fsanitize=address \
+// RUN:   -nogpuinc -nogpulib \
+// RUN:   %s 2>&1 | FileCheck %s
+
+// CHECK-NOT: {{"[^"]*clang[^"]*".* "-fcuda-is-device".* "-fsanitize=address"}}
+// CHECK: {{"[^"]*clang[^"]*".* "-triple" "x86_64-unknown-linux-gnu".* 
"-fsanitize=address"}}



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


[PATCH] D87461: Disable sanitizer options for AMDGPU

2020-09-10 Thread Yaxun Liu via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4934127e627d: Diable sanitizer options for amdgpu (authored 
by yaxunl).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87461

Files:
  clang/lib/Driver/SanitizerArgs.cpp
  clang/test/Driver/hip-sanitize-options.hip


Index: clang/test/Driver/hip-sanitize-options.hip
===
--- /dev/null
+++ clang/test/Driver/hip-sanitize-options.hip
@@ -0,0 +1,9 @@
+// REQUIRES: clang-driver, x86-registered-target, amdgpu-registered-target
+
+// RUN: %clang -### -target x86_64-unknown-linux-gnu --offload-arch=gfx906 \
+// RUN:   -fsanitize=address \
+// RUN:   -nogpuinc -nogpulib \
+// RUN:   %s 2>&1 | FileCheck %s
+
+// CHECK-NOT: {{"[^"]*clang[^"]*".* "-fcuda-is-device".* "-fsanitize=address"}}
+// CHECK: {{"[^"]*clang[^"]*".* "-triple" "x86_64-unknown-linux-gnu".* 
"-fsanitize=address"}}
Index: clang/lib/Driver/SanitizerArgs.cpp
===
--- clang/lib/Driver/SanitizerArgs.cpp
+++ clang/lib/Driver/SanitizerArgs.cpp
@@ -929,10 +929,10 @@
 void SanitizerArgs::addArgs(const ToolChain , const llvm::opt::ArgList 
,
 llvm::opt::ArgStringList ,
 types::ID InputType) const {
-  // NVPTX doesn't currently support sanitizers.  Bailing out here means that
-  // e.g. -fsanitize=address applies only to host code, which is what we want
-  // for now.
-  if (TC.getTriple().isNVPTX())
+  // NVPTX/AMDGPU doesn't currently support sanitizers.  Bailing out here means
+  // that e.g. -fsanitize=address applies only to host code, which is what we
+  // want for now.
+  if (TC.getTriple().isNVPTX() || TC.getTriple().isAMDGPU())
 return;
 
   // Translate available CoverageFeatures to corresponding clang-cc1 flags.


Index: clang/test/Driver/hip-sanitize-options.hip
===
--- /dev/null
+++ clang/test/Driver/hip-sanitize-options.hip
@@ -0,0 +1,9 @@
+// REQUIRES: clang-driver, x86-registered-target, amdgpu-registered-target
+
+// RUN: %clang -### -target x86_64-unknown-linux-gnu --offload-arch=gfx906 \
+// RUN:   -fsanitize=address \
+// RUN:   -nogpuinc -nogpulib \
+// RUN:   %s 2>&1 | FileCheck %s
+
+// CHECK-NOT: {{"[^"]*clang[^"]*".* "-fcuda-is-device".* "-fsanitize=address"}}
+// CHECK: {{"[^"]*clang[^"]*".* "-triple" "x86_64-unknown-linux-gnu".* "-fsanitize=address"}}
Index: clang/lib/Driver/SanitizerArgs.cpp
===
--- clang/lib/Driver/SanitizerArgs.cpp
+++ clang/lib/Driver/SanitizerArgs.cpp
@@ -929,10 +929,10 @@
 void SanitizerArgs::addArgs(const ToolChain , const llvm::opt::ArgList ,
 llvm::opt::ArgStringList ,
 types::ID InputType) const {
-  // NVPTX doesn't currently support sanitizers.  Bailing out here means that
-  // e.g. -fsanitize=address applies only to host code, which is what we want
-  // for now.
-  if (TC.getTriple().isNVPTX())
+  // NVPTX/AMDGPU doesn't currently support sanitizers.  Bailing out here means
+  // that e.g. -fsanitize=address applies only to host code, which is what we
+  // want for now.
+  if (TC.getTriple().isNVPTX() || TC.getTriple().isAMDGPU())
 return;
 
   // Translate available CoverageFeatures to corresponding clang-cc1 flags.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D87047: [clang] Add command line options for the Machine Function Splitter.

2020-09-10 Thread Snehasish Kumar via Phabricator via cfe-commits
snehasish updated this revision to Diff 291063.
snehasish added a comment.

Check warning, specify target to avoid failures on windows.

- Added a check for warning emitted if no profile is provided.
- Added a triple for the remaining checks since we now emit an error for 
incompatible targets.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87047

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/split-machine-functions.c
  clang/test/Driver/fsplit-machine-functions.c

Index: clang/test/Driver/fsplit-machine-functions.c
===
--- /dev/null
+++ clang/test/Driver/fsplit-machine-functions.c
@@ -0,0 +1,9 @@
+// RUN: %clang -### -target x86_64 -fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
+// RUN: %clang -### -target x86_64 -fsplit-machine-functions -fno-split-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-NOOPT %s
+// RUN: %clang -c -target x86_64 -fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-WARN %s
+// RUN: not %clang -c -target arm-unknown-linux -fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-TRIPLE %s
+
+// CHECK-OPT:   "-fsplit-machine-functions"
+// CHECK-NOOPT-NOT: "-fsplit-machine-functions"
+// CHECK-WARN:  ignored -fsplit-machine-functions, no profile provided via -fprofile-use
+// CHECK-TRIPLE:error: unsupported option '-fsplit-machine-functions' for target
Index: clang/test/CodeGen/split-machine-functions.c
===
--- /dev/null
+++ clang/test/CodeGen/split-machine-functions.c
@@ -0,0 +1,34 @@
+// REQUIRES: x86-registered-target
+
+// RUN: echo "foo"> %t.proftext
+// RUN: echo "# Func Hash:"   >> %t.proftext
+// RUN: echo "11262309905">> %t.proftext
+// RUN: echo "# Num Counters:">> %t.proftext
+// RUN: echo "2"  >> %t.proftext
+// RUN: echo "# Counter Values:"  >> %t.proftext
+// RUN: echo "100">> %t.proftext
+// RUN: echo "0"  >> %t.proftext
+// RUN: llvm-profdata merge -o %t.profdata %t.proftext
+// RUN: %clang_cc1 -triple x86_64 -O3 -S -fprofile-instrument-use-path=%t.profdata -fsplit-machine-functions -o - < %s | FileCheck %s
+
+__attribute__((noinline)) int foo(int argc) {
+  if (argc % 2 == 0) {
+exit(argc);
+  } else {
+return argc + 1;
+  }
+}
+
+int main(int argc, char *argv[]) {
+  int total = 0;
+  for (int i = 0; i < 100; ++i) {
+total += foo(argc);
+  }
+  printf("%d\n", total);
+}
+
+// CHECK: .section .text.hot.,"ax",@progbits
+// CHECK: foo:
+// CHECK: section .text.unlikely.foo,"ax",@progbits
+// CHECK: foo.cold:
+// CHECK: callq exit@PLT
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -998,6 +998,8 @@
   Opts.UniqueInternalLinkageNames =
   Args.hasArg(OPT_funique_internal_linkage_names);
 
+  Opts.SplitMachineFunctions = Args.hasArg(OPT_fsplit_machine_functions);
+
   Opts.MergeFunctions = Args.hasArg(OPT_fmerge_functions);
 
   Opts.NoUseJumpTables = Args.hasArg(OPT_fno_jump_tables);
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4256,6 +4256,8 @@
 options::OPT_fno_unique_section_names,
 options::OPT_funique_basic_block_section_names,
 options::OPT_fno_unique_basic_block_section_names,
+options::OPT_fsplit_machine_functions,
+options::OPT_fno_split_machine_functions,
 options::OPT_mrestrict_it,
 options::OPT_mno_restrict_it,
 options::OPT_mstackrealign,
@@ -4911,6 +4913,15 @@
options::OPT_fno_unique_basic_block_section_names, false))
 CmdArgs.push_back("-funique-basic-block-section-names");
 
+  if (Args.hasFlag(options::OPT_fsplit_machine_functions,
+   options::OPT_fno_split_machine_functions, false)) {
+if (Triple.isX86() && Triple.isOSBinFormatELF())
+  CmdArgs.push_back("-fsplit-machine-functions");
+else
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << "-fsplit-machine-functions" << TripleStr;
+  }
+
   Args.AddLastArg(CmdArgs, options::OPT_finstrument_functions,
   options::OPT_finstrument_functions_after_inlining,
   options::OPT_finstrument_function_entry_bare);
Index: clang/lib/CodeGen/BackendUtil.cpp

[PATCH] D73425: [PPC] Fix platform definitions when compiling FreeBSD powerpc64 as LE

2020-09-10 Thread Brandon Bergren via Phabricator via cfe-commits
Bdragon28 added a comment.

Any chance of a backport to 11?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D73425

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


[PATCH] D87047: [clang] Add command line options for the Machine Function Splitter.

2020-09-10 Thread Snehasish Kumar via Phabricator via cfe-commits
snehasish updated this revision to Diff 291051.
snehasish added a comment.

Updated test and warning type.

- Updated test to check for the diagnostic message.
- Updated BackendUtil.cpp to use backend optimization failure warning.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87047

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/split-machine-functions.c
  clang/test/Driver/fsplit-machine-functions.c

Index: clang/test/Driver/fsplit-machine-functions.c
===
--- /dev/null
+++ clang/test/Driver/fsplit-machine-functions.c
@@ -0,0 +1,7 @@
+// RUN: %clang -### -fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-OPT %s
+// RUN: %clang -### -fsplit-machine-functions -fno-split-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-NOOPT %s
+// RUN: not %clang -c -target arm-unknown-linux -fsplit-machine-functions %s -c 2>&1 | FileCheck -check-prefix=CHECK-TRIPLE %s
+
+// CHECK-OPT:   "-fsplit-machine-functions"
+// CHECK-NOOPT-NOT: "-fsplit-machine-functions"
+// CHECK-TRIPLE:error: unsupported option '-fsplit-machine-functions' for target
Index: clang/test/CodeGen/split-machine-functions.c
===
--- /dev/null
+++ clang/test/CodeGen/split-machine-functions.c
@@ -0,0 +1,34 @@
+// REQUIRES: x86-registered-target
+
+// RUN: echo "foo"> %t.proftext
+// RUN: echo "# Func Hash:"   >> %t.proftext
+// RUN: echo "11262309905">> %t.proftext
+// RUN: echo "# Num Counters:">> %t.proftext
+// RUN: echo "2"  >> %t.proftext
+// RUN: echo "# Counter Values:"  >> %t.proftext
+// RUN: echo "100">> %t.proftext
+// RUN: echo "0"  >> %t.proftext
+// RUN: llvm-profdata merge -o %t.profdata %t.proftext
+// RUN: %clang_cc1 -triple x86_64 -O3 -S -fprofile-instrument-use-path=%t.profdata -fsplit-machine-functions -o - < %s | FileCheck %s
+
+__attribute__((noinline)) int foo(int argc) {
+  if (argc % 2 == 0) {
+exit(argc);
+  } else {
+return argc + 1;
+  }
+}
+
+int main(int argc, char *argv[]) {
+  int total = 0;
+  for (int i = 0; i < 100; ++i) {
+total += foo(argc);
+  }
+  printf("%d\n", total);
+}
+
+// CHECK: .section .text.hot.,"ax",@progbits
+// CHECK: foo:
+// CHECK: section .text.unlikely.foo,"ax",@progbits
+// CHECK: foo.cold:
+// CHECK: callq exit@PLT
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -998,6 +998,8 @@
   Opts.UniqueInternalLinkageNames =
   Args.hasArg(OPT_funique_internal_linkage_names);
 
+  Opts.SplitMachineFunctions = Args.hasArg(OPT_fsplit_machine_functions);
+
   Opts.MergeFunctions = Args.hasArg(OPT_fmerge_functions);
 
   Opts.NoUseJumpTables = Args.hasArg(OPT_fno_jump_tables);
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4256,6 +4256,8 @@
 options::OPT_fno_unique_section_names,
 options::OPT_funique_basic_block_section_names,
 options::OPT_fno_unique_basic_block_section_names,
+options::OPT_fsplit_machine_functions,
+options::OPT_fno_split_machine_functions,
 options::OPT_mrestrict_it,
 options::OPT_mno_restrict_it,
 options::OPT_mstackrealign,
@@ -4911,6 +4913,15 @@
options::OPT_fno_unique_basic_block_section_names, false))
 CmdArgs.push_back("-funique-basic-block-section-names");
 
+  if (Args.hasFlag(options::OPT_fsplit_machine_functions,
+   options::OPT_fno_split_machine_functions, false)) {
+if (Triple.isX86() && Triple.isOSBinFormatELF())
+  CmdArgs.push_back("-fsplit-machine-functions");
+else
+  D.Diag(diag::err_drv_unsupported_opt_for_target)
+  << "-fsplit-machine-functions" << TripleStr;
+  }
+
   Args.AddLastArg(CmdArgs, options::OPT_finstrument_functions,
   options::OPT_finstrument_functions_after_inlining,
   options::OPT_finstrument_function_entry_bare);
Index: clang/lib/CodeGen/BackendUtil.cpp
===
--- clang/lib/CodeGen/BackendUtil.cpp
+++ clang/lib/CodeGen/BackendUtil.cpp
@@ -9,6 +9,7 @@
 #include "clang/CodeGen/BackendUtil.h"
 #include "clang/Basic/CodeGenOptions.h"
 #include "clang/Basic/Diagnostic.h"
+#include "clang/Basic/DiagnosticFrontend.h"
 #include "clang/Basic/LangOptions.h"
 

[PATCH] D87358: [clang][aarch64] Fix ILP32 ABI for arm_sve_vector_bits

2020-09-10 Thread Eli Friedman via Phabricator via cfe-commits
efriedma accepted this revision.
efriedma added a comment.
This revision is now accepted and ready to land.

LGTM




Comment at: clang/lib/AST/Type.cpp:2324
 // scalable and fixed-length vectors.
-return Ctx.UnsignedCharTy;
-  case BuiltinType::SveInt16:
-return Ctx.ShortTy;
-  case BuiltinType::SveUint16:
-return Ctx.UnsignedShortTy;
-  case BuiltinType::SveInt32:
-return Ctx.IntTy;
-  case BuiltinType::SveUint32:
-return Ctx.UnsignedIntTy;
-  case BuiltinType::SveInt64:
-return Ctx.LongTy;
-  case BuiltinType::SveUint64:
-return Ctx.UnsignedLongTy;
-  case BuiltinType::SveFloat16:
-return Ctx.Float16Ty;
-  case BuiltinType::SveBFloat16:
-return Ctx.BFloat16Ty;
-  case BuiltinType::SveFloat32:
-return Ctx.FloatTy;
-  case BuiltinType::SveFloat64:
-return Ctx.DoubleTy;
-  }
+return Ctx.getIntTypeForBitwidth(8, /*Signed=*/0);
+  else

For 8-bit types, not sure you're getting anything by using 
getIntTypeForBitwidth instead of Ctx.UnsignedCharTy; there isn't actually any 
possible variation. I don't care much either way, though.


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

https://reviews.llvm.org/D87358

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


[PATCH] D78938: Make LLVM build in C++20 mode

2020-09-10 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

In D78938#2262713 , @jhenderson wrote:

> In D78938#2261411 , @jfb wrote:
>
>> On C++20 mode rotting: it won't if someone sets up a bot. If it rots, then 
>> it's easier to un-rot with Barry's patch.
>
> I assume this would be a private bot? It can't be a public bot, since LLVM 
> isn't even on C++17, let alone C++20, and so it shouldn't be part of minimum 
> requirements that somebody has a compiler that can build C++20. Whilst I 
> personally am quite happy with moving LLVM forward, I develop on Windows 
> primarily, so don't have the same need to support a long tail of old *nix 
> versions etc.

I'd be fine with it being a public bot - it's not saying LLVM can only be 
compiled with C++20-supporting compilers, that'd be very different & that's the 
discussion we'll have when we want to start using C++20 in LLVM. But saying 
"LLVM is intended to be C++20 compatible" is something we can/shuold be saying 
much sooner than that. Like we say that LLVM's compatible with a certain 
variety of compilers in C++14 mode too - not everyone has or is testing on all 
those compilers every time they commit, but buildbots test a range of them (and 
test a range of hardware - again, hardware I don't have/don't intend to test 
with) & we clean things up that they report, ideally.

I'd think a C++20 buildbot could at least be relatively fast/easy (doesn't have 
to do multi-stage bootstraps (though it could - making sure the evolving C++20 
support in Clang remains compatible with the LLVM project codebase itself)) - 
doesn't even need to run any tests, really, just compile.




Comment at: llvm/include/llvm/DebugInfo/DWARF/DWARFExpression.h:167-171
-
-inline bool operator!=(const DWARFExpression::iterator ,
-   const DWARFExpression::iterator ) {
-  return !(LHS == RHS);
-}

Why are some being removed? That seems harder to justify. Even if they're not 
called, it may be more valuable to have the symmetry to reduce friction if/when 
they are needed. (iterators seem pretty common to compare for inequality - such 
as in a loop condition testing I != E)



Comment at: llvm/include/llvm/IR/BasicBlock.h:324-325
+template ::value>>
 phi_iterator_impl(const phi_iterator_impl )

What tripped over/required this SFINAE?



Comment at: llvm/include/llvm/Support/BinaryStreamRef.h:124
 
-  bool operator==(const RefType ) const {
-if (BorrowedImpl != Other.BorrowedImpl)
+  friend bool operator==(const RefType , const RefType ) {
+if (Self.BorrowedImpl != Other.BorrowedImpl)

Quuxplusone wrote:
> Is there a neat rule of thumb for when you were able to preserve the member 
> `bool Me::operator==(const Me& rhs) const` versus when you were forced to 
> change it to a hidden friend? It seems like maybe you changed it to a hidden 
> friend only in cases where `Me` was a base class, is that right?
Be curious of the answer here - and, honestly, I'd be fine with changing them 
all to friends. It makes them more consistent - equal rank for implicit 
conversions on LHS and RHS, etc. (generally considered best practice basically 
to not define op overloads as members if they can be defined as non-members)



Comment at: llvm/unittests/ADT/STLExtrasTest.cpp:465
   // Check fancy pointer overload for unique_ptr
+  // Parenthesizing to_address to avoid ADL finding std::to_address
   std::unique_ptr V2 = std::make_unique(0);

jhenderson wrote:
> Nit: trailing full stop.
Probably more suitable to use qualify the name rather than use parens (teh 
comment's still helpful to explain why either strategy is used) - that's what's 
done with llvm::make_unique, for instance.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78938

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


[PATCH] D83814: [clangd] Add Random Forest runtime for code completion.

2020-09-10 Thread UTKARSH SAXENA via Phabricator via cfe-commits
usaxena95 added a comment.

Hi @jkorous

> Do you guys intend to open-source also the training part of the model 
> pipeline ?

Open sourcing the training part (both dataset generation and using an open 
sourced DecisionForest based framework for training) has been on our radar. 
Although gathering capacity for this task has been difficult lately.

> Publish a model trained on generic-enough training set so it could be 
> reasonably used on "any" codebase?

Although the current model has not been trained on a generic codebase, but 
since the features involved doesn't capture code style/conventions/variable 
names, it is likely that it performs well on generic code bases as well. This 
remains to be tested.

> Do you still intend to support the heuristic that is currently powering 
> clangd in the future?

Currently we are planning to use this model behind a flag. Initially we would 
be focusing on comparing the two. Since maintaining and developing signals is 
easier for an ML model, we might end up deprecating the heuristics.

Thanks,
Utkarsh.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83814

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


[PATCH] D87396: Sema: add support for `__attribute__((__swift_typedef_bridged__))`

2020-09-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/Attr.td:2121
 
+def SwiftBridgedTypedef : Attr {
+  let Spellings = [GNU<"swift_bridged_typedef">];

Should this be inherited on redeclarations?



Comment at: clang/include/clang/Basic/Attr.td:2123
+  let Spellings = [GNU<"swift_bridged_typedef">];
+  let Subjects = SubjectList<[TypedefName], ErrorDiag, "typedefs">;
+  let Documentation = [SwiftBridgedTypedefDocs];

Does the default diagnostic text generate something bad that caused you to add 
`typedefs` here?



Comment at: clang/include/clang/Basic/AttrDocs.td:3389
+Swift type (e.g. Swift's ``String``) rather than the Objective-C type as 
written
+(e.g. ``NSString``).
+  }];

I think it would be helpful to show the `String` vs `NSString` behavior in a 
short code example of how to use the attribute.



Comment at: clang/lib/Sema/SemaDeclAttr.cpp:7543
+  case ParsedAttr::AT_SwiftBridgedTypedef:
+handleSimpleAttribute(S, D, AL);
+break;

Should there be any type checking that the underlying type of the typedef is a 
sensible one to bridge?



Comment at: clang/test/SemaObjC/attr-swift_bridged_typedef.m:8
+
+struct __attribute__((swift_bridged_typedef)) S {};
+// expected-error@-1 {{'swift_bridged_typedef' attribute only applies to 
typedefs}}

Please also add some examples where the attribute has arguments. Also, should 
this work in Objective-C++ when using a `using` type alias? If so, an example 
showing that working would also be helpful.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87396

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


[PATCH] D87395: Sema: add support for `__attribute__((__swift_objc_members__))`

2020-09-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/Attr.td:2121
 
+def SwiftObjCMembers : Attr {
+  let Spellings = [GNU<"swift_objc_members">];

Should this be inherited by redeclarations, or is that not a thing with 
`ObjCInterfaceDecl`s?



Comment at: clang/include/clang/Basic/AttrDocs.td:3387
+The ``swift_objc_members`` attribute maps to the ``@objcMembers`` Swift
+attribute, which indicates that Swift members of this class, its subclasses, 
and
+all extensions thereof, will implicitly be exposed back to Objective-C.

The documentation is a bit hard to follow -- the user is going to be adding 
this attribute to an ObjC interface, so the docs should be talking about what 
that means from the ObjC side of things more so than the Swift side, no?



Comment at: clang/lib/Sema/SemaDeclAttr.cpp:7546
+  case ParsedAttr::AT_SwiftObjCMembers:
+handleSimpleAttribute(S, D, AL);
+break;

Does it matter if the user writes this attribute on an interface that exposes 
no members? e.g., are there warnings we may want to give the user about using 
the attribute in a weird way? (Sorry if this should be obvious, but I don't 
have experience with Swift.)



Comment at: clang/test/SemaObjC/attr-swift_objc_members.m:4
+#if !__has_attribute(swift_objc_members)
+#error cannot verify precense of swift_objc_members attribute
+#endif

gribozavr2 wrote:
> 
The typo fix makes sense to me, but for my own understanding, why switch to a 
string literal?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87395

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


[PATCH] D87455: [clang-tidy] performance-unnecessary-copy-initialization: Restrict UnnecessaryCopyInitialization check to variables initialized from free functions without arguments

2020-09-10 Thread Felix Berger via Phabricator via cfe-commits
flx updated this revision to Diff 291030.
flx retitled this revision from "[clang-tidy] 
performance-unnecessary-copy-initialization: Restrict 
UnnecessaryCopyInitialization check to variables initialized from 
methods/functions without arguments " to "[clang-tidy] 
performance-unnecessary-copy-initialization: Restrict 
UnnecessaryCopyInitialization check to variables initialized from free 
functions without arguments ".
flx edited the summary of this revision.

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

https://reviews.llvm.org/D87455

Files:
  clang-tools-extra/clang-tidy/performance/UnnecessaryCopyInitialization.cpp
  
clang-tools-extra/test/clang-tidy/checkers/performance-unnecessary-copy-initialization.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/performance-unnecessary-copy-initialization.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/performance-unnecessary-copy-initialization.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/performance-unnecessary-copy-initialization.cpp
@@ -23,6 +23,9 @@
 ExpensiveToCopyType global_expensive_to_copy_type;
 
 const ExpensiveToCopyType ();
+const ExpensiveToCopyType (const ExpensiveToCopyType &);
+const ExpensiveToCopyType (
+const ExpensiveToCopyType *arg = nullptr);
 const TrivialToCopyType ();
 
 void mutate(ExpensiveToCopyType &);
@@ -387,3 +390,20 @@
   for (const Element  : Container()) {
   }
 }
+
+// This should not trigger the check as the argument could introduce an alias.
+void negativeInitializedFromFreeFunctionWithArg() {
+  ExpensiveToCopyType Orig;
+  const ExpensiveToCopyType Copy = freeFunctionWithArg(Orig);
+}
+
+void positiveInitializedFromFreeFunctionWithDefaultArg() {
+  const ExpensiveToCopyType Copy = freeFunctionWithDefaultArg();
+  // CHECK-MESSAGES: [[@LINE-1]]:29: warning: the const qualified variable 'Copy'
+  // CHECK-FIXES: const ExpensiveToCopyType& Copy = freeFunctionWithDefaultArg();
+}
+
+void negativeInitialzedFromFreeFunctionWithNonDefaultArg() {
+  ExpensiveToCopyType Orig;
+  const ExpensiveToCopyType Copy = freeFunctionWithDefaultArg();
+}
Index: clang-tools-extra/clang-tidy/performance/UnnecessaryCopyInitialization.cpp
===
--- clang-tools-extra/clang-tidy/performance/UnnecessaryCopyInitialization.cpp
+++ clang-tools-extra/clang-tidy/performance/UnnecessaryCopyInitialization.cpp
@@ -29,6 +29,14 @@
   }
 }
 
+template 
+bool hasNonDefaultArgs(const Call , unsigned int StartIndex = 0) {
+  for (unsigned int I = StartIndex; I < CallExpr.getNumArgs(); ++I)
+if (!CallExpr.getArg(I)->isDefaultArgument())
+  return true;
+  return false;
+}
+
 } // namespace
 
 using namespace ::clang::ast_matchers;
@@ -54,7 +62,8 @@
 on(declRefExpr(to(varDecl().bind("objectArg");
   auto ConstRefReturningFunctionCall =
   callExpr(callee(functionDecl(returns(ConstReference))),
-   unless(callee(cxxMethodDecl(;
+   unless(callee(cxxMethodDecl(
+  .bind("initFunctionCall");
 
   auto localVarCopiedFrom = [this](const internal::Matcher ) {
 return compoundStmt(
@@ -96,6 +105,8 @@
   const auto *ObjectArg = Result.Nodes.getNodeAs("objectArg");
   const auto *BlockStmt = Result.Nodes.getNodeAs("blockStmt");
   const auto *CtorCall = Result.Nodes.getNodeAs("ctorCall");
+  const auto *InitFunctionCall =
+  Result.Nodes.getNodeAs("initFunctionCall");
 
   TraversalKindScope RAII(*Result.Context, ast_type_traits::TK_AsIs);
 
@@ -108,11 +119,16 @@
   // A constructor that looks like T(const T& t, bool arg = false) counts as a
   // copy only when it is called with default arguments for the arguments after
   // the first.
-  for (unsigned int i = 1; i < CtorCall->getNumArgs(); ++i)
-if (!CtorCall->getArg(i)->isDefaultArgument())
-  return;
+  if (hasNonDefaultArgs(*CtorCall, 1))
+return;
 
   if (OldVar == nullptr) {
+// Only allow initialization of a const reference from a free function if it
+// has no arguments or only default arguments. Otherwise it could return
+// an alias to one of its arguments and the arguments need to be checked for
+// const use as well.
+if (InitFunctionCall != nullptr && hasNonDefaultArgs(*InitFunctionCall))
+  return;
 handleCopyFromMethodReturn(*NewVar, *BlockStmt, IssueFix, ObjectArg,
*Result.Context);
   } else {
@@ -127,10 +143,10 @@
   bool IsConstQualified = Var.getType().isConstQualified();
   if (!IsConstQualified && !isOnlyUsedAsConst(Var, BlockStmt, Context))
 return;
+
   if (ObjectArg != nullptr &&
   !isOnlyUsedAsConst(*ObjectArg, BlockStmt, Context))
 return;
-
   auto Diagnostic =
   diag(Var.getLocation(),
IsConstQualified ? "the const qualified variable %0 is "
___
cfe-commits mailing list

[PATCH] D87331: Sema: add support for `__attribute__((__swift_error__))`

2020-09-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang/Basic/Attr.td:2128
+  ];
+  let Subjects = SubjectList<[Function, ObjCMethod], ErrorDiag>;
+  let Documentation = [SwiftErrorDocs];

rjmccall wrote:
> compnerd wrote:
> > aaron.ballman wrote:
> > > Should this apply to function-like things such as blocks or function 
> > > pointers? If so, you should use `HasFunctionProto`.
> > I believe not.
> Correct, it's just declared functions for now.
SGTM, thank you for verifying.



Comment at: clang/include/clang/Basic/AttrDocs.td:3394
+parameter. Currently, the error parameter is always the last parameter of type
+``NSError**`` or ``CFErrorRef*``.  Swift will remove the error parameter from
+the imported API. When calling the API, Swift will always pass a valid address

compnerd wrote:
> rjmccall wrote:
> > compnerd wrote:
> > > aaron.ballman wrote:
> > > > Canonical type or are typedefs to these types also fine? May want to 
> > > > mention that the type has to be cv-unqualified, but I do wonder whether 
> > > > something like `NSError * const *` is fine.
> > > I am definitely not the authority on this, but I believe that the common 
> > > thing is to take `NSError **` or `CFErrorRef **` by canonical name.  The 
> > > cv-qualified versions, except on the outermost pointer, is something that 
> > > can be treated as valid, though it is certainly extremely unusual.  I've 
> > > added test cases for them as well.
> > `NSError * const *` actually does not really work; the whole point is that 
> > this is an out-parameter.
> Oh right, its the `const NSError ** const` that can work, because the outer 
> pointer can be non-mutable as it is a pointer by-reference scenario.  Should 
> we diagnose the `NSError * const *` case then?  Any `const` qualified value 
> is really unidiomatic to say the least.
I think we should diagnose (as an error) any case that can't work.

I think it may make sense to diagnose (as a warning) any case where we want to 
ignore the qualifiers, in case we want to give semantics to those qualifiers in 
this situation later. So this means we'd error on `NSError * const *` but warn 
and ignore the qualifiers on `volatile NSError **`. However, I don't insist on 
warning in this case unless there's a situation that the user might actually 
appreciate the warning because it matters (it's not clear to me if such a 
situation exists). Also, it's not clear to me whether we should or should not 
warn on a `restrict`-qualified pointer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87331

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


[PATCH] D87455: [clang-tidy] performance-unnecessary-copy-initialization: Restrict UnnecessaryCopyInitialization check to variables initialized from methods/functions without arguments

2020-09-10 Thread Felix Berger via Phabricator via cfe-commits
flx added a comment.

The motivating false positive was the free functions `std::min`. To not limit 
the usefulness of the check I'll only disable arguments for free functions for 
now. Updated change coming.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87455

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


[PATCH] D83814: [clangd] Add Random Forest runtime for code completion.

2020-09-10 Thread UTKARSH SAXENA via Phabricator via cfe-commits
usaxena95 added inline comments.



Comment at: clang-tools-extra/clangd/CMakeLists.txt:30
+  
+set(DF_COMPILER ${CMAKE_CURRENT_SOURCE_DIR}/CompletionModelCodegen.py)
+include(${CMAKE_CURRENT_SOURCE_DIR}/CompletionModel.cmake)

sammccall wrote:
> if you want the compiler script to be a parameter, make it an argument to the 
> function rather than a magic variable. 
> 
> But really, I think the CompletionModel.cmake is tightly coupled to the 
> python script, I think it can be hardcoded there.
Hardcoded it in .cmake file.



Comment at: clang-tools-extra/clangd/CompletionModel.cmake:1
+# Run the Completion Model Codegenerator on the model in the 
+# ${model} directory.

sammccall wrote:
> I think there's some confusion in the naming.
> 
> You've got the code split into two locations: the generic generator and the 
> specific code completion model.
> 
> However the directory named just "model" contains the specific stuff, and the 
> generic parts are named "completionmodel!".
> 
> I'd suggest either:
>  - don't generalize, and put everything in clangd/quality or so
>  - split into clangd/quality/ and clangd/forest/ for the specific/generic 
> parts
Moved .cmake, codegen and model in quality dir.



Comment at: clang-tools-extra/clangd/CompletionModel.cmake:5
+# ${CMAKE_BINARY_DIR}/generated/decision_forest. The generated header
+# will define a C++ class called ${cpp_class} - which may be a
+# namespace-qualified class name.

sammccall wrote:
> what does the class do?
The class specifies the name and scope of the Feature class. 
`clang::clangd::Example` in this case.



Comment at: clang-tools-extra/clangd/CompletionModel.cmake:17
+COMMAND "${Python3_EXECUTABLE}" ${DF_COMPILER} 
+  --model ${model}
+  --output_dir ${output_dir}

sammccall wrote:
> I'd suggest passing the component filenames explicitly here since you're 
> computing them anyway
This allows the generated cc file to include the header using "filename.h".
If we give the filepath as input, we would have to strip out the filename from 
it. 

Although I like the current notion of being explicit that the output_dir 
contains the two files. We need to add output_dir to include path to use this 
library.



Comment at: clang-tools-extra/clangd/CompletionModel.cmake:29
+GENERATED 1
+COMPILE_FLAGS -Wno-unused-label)
+

sammccall wrote:
> this needs to be guarded based on the compiler - other compilers use 
> different flags
> 
> I'd suggest just -Wno-usuned
only MSVC needed a different flag. `-Wno-unused` works with Clang and GCC.
https://godbolt.org/z/Gvdne7




Comment at: clang-tools-extra/clangd/CompletionModel.cmake:31
+
+  set(GENERATED_CC ${df_cpp} PARENT_SCOPE)
+  set(DF_INCLUDE ${output_dir} PARENT_SCOPE)  

sammccall wrote:
> It'd be nice to avoid passing data out by setting magic variables with 
> generic names.
> 
> The caller is already passing in the filename they want, so they know what it 
> is.
We can avoid `GENERATED_CC`. But I still wanted to keep the output directory as 
a detail in this function itself and not as an input parameter.
Changed the name to more specific name `DECISION_FOREST_OUTPUT_DIR`. 




Comment at: clang-tools-extra/clangd/CompletionModelCodegen.py:9
+
+class Feature:
+class Type(Enum):

sammccall wrote:
> Hmm, do these classes really pay for themselves compared to just using the 
> JSON-decoded data structures directly and writing functions?
> 
> e.g.
> 
> ```
> def setter(feature):
>   if (feature['kind'] == KIND_CATEGORICAL)
> return "void Set{feature}(float V) {{ {feature} = OrderEncode(V); 
> }}".format(feature['name'])
>   ...
> ```
Removed the Feature class and Tree.
CppClass calculates and holds the namespaces which I felt convenient. 



Comment at: clang-tools-extra/clangd/CompletionModelCodegen.py:52
+self.fname = fname
+assert not cpp_class.startswith(
+"::"), "Do not fully qualify class name."

sammccall wrote:
> why not assert this on self.ns so that "::Foo" will work fine?
Allowed fully qualified names of classes.



Comment at: clang-tools-extra/clangd/CompletionModelCodegen.py:70
+return "GENERATED_CODE_COMPLETION_MODEL_{}_H".format(
+reduce(lambda x, y: x + ('_' if y.isupper() else '') + y,
+   self.fname).upper())

sammccall wrote:
> `''.join('_' if x in '-' else x.upper() for x in self.fname)` ?
Sorry for making this complicated. filename was assumed to be in PascalCase 
(and not contain '-' at all).
I wanted to convert it to UPPER_SNAKE_CASE. To avoid unnecessary complexity, 
lets simply convert it to upper case.


Repository:
  rG LLVM Github Monorepo

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


[PATCH] D83814: [clangd] Add Random Forest runtime for code completion.

2020-09-10 Thread UTKARSH SAXENA via Phabricator via cfe-commits
usaxena95 updated this revision to Diff 291024.
usaxena95 marked 23 inline comments as done.
usaxena95 added a comment.

Addressed comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83814

Files:
  clang-tools-extra/clangd/CMakeLists.txt
  clang-tools-extra/clangd/for-review-only/CompletionModel.cpp
  clang-tools-extra/clangd/for-review-only/CompletionModel.h
  clang-tools-extra/clangd/for-review-only/DecisionForestRuntimeTest.cpp
  clang-tools-extra/clangd/for-review-only/DecisionForestRuntimeTest.h
  clang-tools-extra/clangd/quality/CompletionModel.cmake
  clang-tools-extra/clangd/quality/CompletionModelCodegen.py
  clang-tools-extra/clangd/quality/README.md
  clang-tools-extra/clangd/quality/model/features.json
  clang-tools-extra/clangd/quality/model/forest.json
  clang-tools-extra/clangd/unittests/CMakeLists.txt
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
  clang-tools-extra/clangd/unittests/DecisionForestTests.cpp
  clang-tools-extra/clangd/unittests/model/CategoricalFeature.h
  clang-tools-extra/clangd/unittests/model/features.json
  clang-tools-extra/clangd/unittests/model/forest.json

Index: clang-tools-extra/clangd/unittests/model/forest.json
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/model/forest.json
@@ -0,0 +1,52 @@
+[
+{
+"operation": "if_greater",
+"feature": "ANumber",
+"threshold": 200.0,
+"then": {
+"operation": "if_greater",
+"feature": "AFloat",
+"threshold": -1,
+"then": {
+"operation": "boost",
+"score": 10.0
+},
+"else": {
+"operation": "boost",
+"score": -20.0
+}
+},
+"else": {
+"operation": "if_member",
+"feature": "ACategorical",
+"set": [
+"A",
+"C"
+],
+"then": {
+"operation": "boost",
+"score": 3.0
+},
+"else": {
+"operation": "boost",
+"score": -4.0
+}
+}
+},
+{
+"operation": "if_member",
+"feature": "ACategorical",
+"set": [
+"A",
+"B"
+],
+"then": {
+"operation": "boost",
+"score": 5.0
+},
+"else": {
+"operation": "boost",
+"score": -6.0
+}
+}
+]
\ No newline at end of file
Index: clang-tools-extra/clangd/unittests/model/features.json
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/model/features.json
@@ -0,0 +1,16 @@
+[
+{
+"name": "ANumber",
+"type": "NUMBER"
+},
+{
+"name": "AFloat",
+"type": "NUMBER"
+},
+{
+"name": "ACategorical",
+"type": "ENUM",
+"enum": "ns1::ns2::TestEnum",
+"header": "model/CategoricalFeature.h"
+}
+]
\ No newline at end of file
Index: clang-tools-extra/clangd/unittests/model/CategoricalFeature.h
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/model/CategoricalFeature.h
@@ -0,0 +1,5 @@
+namespace ns1 {
+namespace ns2 {
+enum TestEnum { A, B, C, D };
+} // namespace ns2
+} // namespace ns1
Index: clang-tools-extra/clangd/unittests/DecisionForestTests.cpp
===
--- /dev/null
+++ clang-tools-extra/clangd/unittests/DecisionForestTests.cpp
@@ -0,0 +1,29 @@
+#include "DecisionForestRuntimeTest.h"
+#include "model/CategoricalFeature.h"
+#include "gtest/gtest.h"
+
+namespace clangd {
+namespace clangd {
+
+TEST(DecisionForestRuntime, Evaluate) {
+  using Example = ::ns1::ns2::test::Example;
+  using Cat = ::ns1::ns2::TestEnum;
+  using ::ns1::ns2::test::Evaluate;
+
+  Example E;
+  E.setANumber(200); // True
+  E.setAFloat(0);// True: +10.0
+  E.setACategorical(Cat::A); // True: +5.0
+  EXPECT_EQ(Evaluate(E), 15.0);
+
+  E.setANumber(200); // True
+  E.setAFloat(-2.5); // False: -20.0
+  E.setACategorical(Cat::B); // True: +5.0
+  EXPECT_EQ(Evaluate(E), -15.0);
+
+  E.setANumber(100); // False
+  E.setACategorical(Cat::C); // True: +3.0, False: -6.0
+  EXPECT_EQ(Evaluate(E), -3.0);
+}
+} // namespace clangd
+} // namespace clangd
Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -10,6 +10,7 @@
 #include "ClangdServer.h"
 #include "CodeComplete.h"
 #include "Compiler.h"
+#include "CompletionModel.h"
 

[PATCH] D87470: [Coroutine][Sema] Tighten the lifetime of symmetric transfer returned handle

2020-09-10 Thread Xun Li via Phabricator via cfe-commits
lxfind created this revision.
lxfind added reviewers: lewissbaker, wenlei, hoy, bruno, junparser, rjmccall.
Herald added subscribers: cfe-commits, dexonsmith, modocache.
Herald added a project: clang.
lxfind requested review of this revision.

In generating the code for symmetric transfer, a temporary object is created to 
store the returned handle from await_suspend() call of the awaiter. Previously 
this temp won't be cleaned up until very later, which ends up causing this temp 
to be spilled to the heap. However, we know that this temp will no longer be 
needed after the coro_resume call. We can clean it up right after.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87470

Files:
  clang/lib/Sema/SemaCoroutine.cpp


Index: clang/lib/Sema/SemaCoroutine.cpp
===
--- clang/lib/Sema/SemaCoroutine.cpp
+++ clang/lib/Sema/SemaCoroutine.cpp
@@ -398,8 +398,8 @@
diag::warn_coroutine_handle_address_invalid_return_type)
 << JustAddress->getType();
 
-  return buildBuiltinCall(S, Loc, Builtin::BI__builtin_coro_resume,
-  JustAddress);
+  return S.MaybeCreateExprWithCleanups(
+  buildBuiltinCall(S, Loc, Builtin::BI__builtin_coro_resume, JustAddress));
 }
 
 /// Build calls to await_ready, await_suspend, and await_resume for a co_await


Index: clang/lib/Sema/SemaCoroutine.cpp
===
--- clang/lib/Sema/SemaCoroutine.cpp
+++ clang/lib/Sema/SemaCoroutine.cpp
@@ -398,8 +398,8 @@
diag::warn_coroutine_handle_address_invalid_return_type)
 << JustAddress->getType();
 
-  return buildBuiltinCall(S, Loc, Builtin::BI__builtin_coro_resume,
-  JustAddress);
+  return S.MaybeCreateExprWithCleanups(
+  buildBuiltinCall(S, Loc, Builtin::BI__builtin_coro_resume, JustAddress));
 }
 
 /// Build calls to await_ready, await_suspend, and await_resume for a co_await
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] ab1de1f - [gcov] Delete flush_fn_list (unused since D83149)

2020-09-10 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2020-09-10T10:15:27-07:00
New Revision: ab1de1fcfb0c53bc768deb8f8bacefad7d378b7b

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

LOG: [gcov] Delete flush_fn_list (unused since D83149)

Added: 


Modified: 
clang/lib/Driver/ToolChains/Darwin.cpp
compiler-rt/lib/profile/GCDAProfiling.c

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Darwin.cpp 
b/clang/lib/Driver/ToolChains/Darwin.cpp
index 9d22cda21711..8f2be2a343cc 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -1197,7 +1197,6 @@ void Darwin::addProfileRTLibs(const ArgList ,
 if (ForGCOV) {
   addExportedSymbol(CmdArgs, "___gcov_dump");
   addExportedSymbol(CmdArgs, "___gcov_reset");
-  addExportedSymbol(CmdArgs, "_flush_fn_list");
   addExportedSymbol(CmdArgs, "_writeout_fn_list");
   addExportedSymbol(CmdArgs, "_reset_fn_list");
 } else {

diff  --git a/compiler-rt/lib/profile/GCDAProfiling.c 
b/compiler-rt/lib/profile/GCDAProfiling.c
index cf6c44bae641..405568187241 100644
--- a/compiler-rt/lib/profile/GCDAProfiling.c
+++ b/compiler-rt/lib/profile/GCDAProfiling.c
@@ -127,11 +127,6 @@ struct fn_list {
  */
 struct fn_list writeout_fn_list;
 
-/*
- *  A list of flush functions that our __gcov_flush() function should call, 
shared between all dynamic objects.
- */
-struct fn_list flush_fn_list;
-
 /*
  *  A list of reset functions, shared between all dynamic objects.
  */



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


[PATCH] D87243: [cmake] Centralize LLVM_ENABLE_WARNINGS option

2020-09-10 Thread Dave Lee via Phabricator via cfe-commits
kastiglione added a comment.

for context this caused standalone swift-lldb builds to have warnings disabled 
via `-w`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87243

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


[PATCH] D87243: [cmake] Centralize LLVM_ENABLE_WARNINGS option

2020-09-10 Thread Dave Lee via Phabricator via cfe-commits
kastiglione added a comment.

@compnerd Saleem, what do you think? (see also my reply to you)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87243

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


[PATCH] D87163: [DSE] Switch to MemorySSA-backed DSE by default.

2020-09-10 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added a comment.

In D87163#2264785 , @asbirlea wrote:

> I'm running into a crash with this, could you please hold off until tomorrow? 
> I'm working on getting a reproducer.

@asbirlea Thanks for the reproducer, the issue should be sorted out. The GVN 
issue has also been fixed and I am planning to submit this today, unless you 
think we should wait a bit longer.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87163

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


[PATCH] D83154: clang: Add -fcoverage-prefix-map

2020-09-10 Thread Reid "Away June-Sep" Kleckner via Phabricator via cfe-commits
rnk added inline comments.



Comment at: clang/lib/CodeGen/CoverageMappingGen.cpp:1334
+  llvm::SmallString<256> Path(Filename);
+  llvm::sys::fs::make_absolute(Path);
+  llvm::sys::path::remove_dots(Path, /*remove_dot_dot=*/true);

keith wrote:
> rnk wrote:
> > Please only make the path absolute if nothing in the prefix map matches. 
> > Otherwise, the user must embed the CWD into the prefix map, which is 
> > needlessly difficult for the build system. I believe it is also consistent 
> > with the way that the debug info prefix map works. It appears to operate on 
> > the possibly relative source paths received on the command line (-I...).
> Are you suggesting that I try to remap them relatively, and if that fails, 
> absolutize it and attempt the remapping again? Or don't absolutize them at 
> all anymore?
I'd prefer to do the remapping once without any absolutization, and if that 
fails, preserve the behavior of absolutizing.

It would be my preference to not absolutize paths at all, since that is what is 
done for debug info. However, @vsk implemented things this way, and I do 
understand that this is convenient default behavior for most users: the paths 
in the coverage are valid anywhere on their system. So, changing this behavior 
is out of scope for this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83154

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


[PATCH] D87374: [SyntaxTree] Specialize `TreeTestBase` for `BuildTreeTest` and `MutationsTest`

2020-09-10 Thread Eduardo Caldas via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGc01d28dc51bd: [SyntaxTree] Specialize `TreeTestBase` for 
`BuildTreeTest`, `MutationsTest` and… (authored by eduucaldas).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87374

Files:
  clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
  clang/unittests/Tooling/Syntax/CMakeLists.txt
  clang/unittests/Tooling/Syntax/MutationsTest.cpp
  clang/unittests/Tooling/Syntax/SynthesisTest.cpp
  clang/unittests/Tooling/Syntax/TreeTestBase.cpp
  clang/unittests/Tooling/Syntax/TreeTestBase.h

Index: clang/unittests/Tooling/Syntax/TreeTestBase.h
===
--- clang/unittests/Tooling/Syntax/TreeTestBase.h
+++ clang/unittests/Tooling/Syntax/TreeTestBase.h
@@ -32,11 +32,6 @@
   TranslationUnit *buildTree(StringRef Code,
  const TestClangConfig );
 
-  ::testing::AssertionResult treeDumpEqual(StringRef Code, StringRef Tree);
-
-  ::testing::AssertionResult
-  treeDumpEqualOnAnnotations(StringRef CodeWithAnnotations,
- ArrayRef TreeDumps);
   /// Finds the deepest node in the tree that covers exactly \p R.
   /// FIXME: implement this efficiently and move to public syntax tree API.
   syntax::Node *nodeByRange(llvm::Annotations::Range R, syntax::Node *Root);
@@ -56,6 +51,8 @@
   std::unique_ptr TB;
   std::unique_ptr Arena;
 };
+
+std::vector allTestClangConfigs();
 } // namespace syntax
 } // namespace clang
 #endif // LLVM_CLANG_UNITTESTS_TOOLING_SYNTAX_TREETESTBASE_H
Index: clang/unittests/Tooling/Syntax/TreeTestBase.cpp
===
--- clang/unittests/Tooling/Syntax/TreeTestBase.cpp
+++ clang/unittests/Tooling/Syntax/TreeTestBase.cpp
@@ -43,8 +43,9 @@
   return llvm::makeArrayRef(T->firstLeaf()->token(),
 T->lastLeaf()->token() + 1);
 }
+} // namespace
 
-std::vector allTestClangConfigs() {
+std::vector clang::syntax::allTestClangConfigs() {
   std::vector all_configs;
   for (TestLanguage lang : {Lang_C89, Lang_C99, Lang_CXX03, Lang_CXX11,
 Lang_CXX14, Lang_CXX17, Lang_CXX20}) {
@@ -61,10 +62,6 @@
   return all_configs;
 }
 
-INSTANTIATE_TEST_CASE_P(SyntaxTreeTests, SyntaxTreeTest,
-testing::ValuesIn(allTestClangConfigs()), );
-} // namespace
-
 syntax::TranslationUnit *
 SyntaxTreeTest::buildTree(StringRef Code, const TestClangConfig ) {
   // FIXME: this code is almost the identical to the one in TokensTest. Share
@@ -161,62 +158,6 @@
   return Root;
 }
 
-::testing::AssertionResult SyntaxTreeTest::treeDumpEqual(StringRef Code,
- StringRef Tree) {
-  SCOPED_TRACE(llvm::join(GetParam().getCommandLineArgs(), " "));
-
-  auto *Root = buildTree(Code, GetParam());
-  if (Diags->getClient()->getNumErrors() != 0) {
-return ::testing::AssertionFailure()
-   << "Source file has syntax errors, they were printed to the test "
-  "log";
-  }
-  auto Actual = StringRef(Root->dump(Arena->sourceManager())).trim().str();
-  // EXPECT_EQ shows the diff between the two strings if they are different.
-  EXPECT_EQ(Tree.trim().str(), Actual);
-  if (Actual != Tree.trim().str()) {
-return ::testing::AssertionFailure();
-  }
-  return ::testing::AssertionSuccess();
-}
-
-::testing::AssertionResult
-SyntaxTreeTest::treeDumpEqualOnAnnotations(StringRef CodeWithAnnotations,
-   ArrayRef TreeDumps) {
-  SCOPED_TRACE(llvm::join(GetParam().getCommandLineArgs(), " "));
-
-  auto AnnotatedCode = llvm::Annotations(CodeWithAnnotations);
-  auto *Root = buildTree(AnnotatedCode.code(), GetParam());
-
-  if (Diags->getClient()->getNumErrors() != 0) {
-return ::testing::AssertionFailure()
-   << "Source file has syntax errors, they were printed to the test "
-  "log";
-  }
-
-  auto AnnotatedRanges = AnnotatedCode.ranges();
-  if (AnnotatedRanges.size() != TreeDumps.size()) {
-return ::testing::AssertionFailure()
-   << "The number of annotated ranges in the source code is different "
-  "to the number of their corresponding tree dumps.";
-  }
-  bool Failed = false;
-  for (unsigned i = 0; i < AnnotatedRanges.size(); i++) {
-auto *AnnotatedNode = nodeByRange(AnnotatedRanges[i], Root);
-assert(AnnotatedNode);
-auto AnnotatedNodeDump =
-StringRef(AnnotatedNode->dump(Arena->sourceManager())).trim().str();
-// EXPECT_EQ shows the diff between the two strings if they are different.
-EXPECT_EQ(TreeDumps[i].trim().str(), AnnotatedNodeDump)
-<< "Dumps diverged for the code:\n"
-<< AnnotatedCode.code().slice(AnnotatedRanges[i].Begin,
-  AnnotatedRanges[i].End);
-if (AnnotatedNodeDump != 

[PATCH] D87461: Disable sanitizer options for AMDGPU

2020-09-10 Thread Aaron Enye Shi via Phabricator via cfe-commits
ashi1 accepted this revision.
ashi1 added a comment.
This revision is now accepted and ready to land.

LGTM


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

https://reviews.llvm.org/D87461

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


[clang] c01d28d - [SyntaxTree] Specialize `TreeTestBase` for `BuildTreeTest`, `MutationsTest` and `SynthesisTest`

2020-09-10 Thread Eduardo Caldas via cfe-commits

Author: Eduardo Caldas
Date: 2020-09-10T16:44:14Z
New Revision: c01d28dc51bdd33404828a327320e3307a51bb22

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

LOG: [SyntaxTree] Specialize `TreeTestBase` for `BuildTreeTest`, 
`MutationsTest` and `SynthesisTest`

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

Added: 
clang/unittests/Tooling/Syntax/SynthesisTest.cpp

Modified: 
clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
clang/unittests/Tooling/Syntax/CMakeLists.txt
clang/unittests/Tooling/Syntax/MutationsTest.cpp
clang/unittests/Tooling/Syntax/TreeTestBase.cpp
clang/unittests/Tooling/Syntax/TreeTestBase.h

Removed: 




diff  --git a/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp 
b/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
index 225885437267..6fcc74ba55d0 100644
--- a/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
+++ b/clang/unittests/Tooling/Syntax/BuildTreeTest.cpp
@@ -17,7 +17,70 @@ using namespace clang::syntax;
 
 namespace {
 
-TEST_P(SyntaxTreeTest, Simple) {
+class BuildSyntaxTreeTest : public SyntaxTreeTest {
+protected:
+  ::testing::AssertionResult treeDumpEqual(StringRef Code, StringRef Tree) {
+SCOPED_TRACE(llvm::join(GetParam().getCommandLineArgs(), " "));
+
+auto *Root = buildTree(Code, GetParam());
+if (Diags->getClient()->getNumErrors() != 0) {
+  return ::testing::AssertionFailure()
+ << "Source file has syntax errors, they were printed to the test "
+"log";
+}
+auto Actual = StringRef(Root->dump(Arena->sourceManager())).trim().str();
+// EXPECT_EQ shows the 
diff  between the two strings if they are 
diff erent.
+EXPECT_EQ(Tree.trim().str(), Actual);
+if (Actual != Tree.trim().str()) {
+  return ::testing::AssertionFailure();
+}
+return ::testing::AssertionSuccess();
+  }
+
+  ::testing::AssertionResult
+  treeDumpEqualOnAnnotations(StringRef CodeWithAnnotations,
+ ArrayRef TreeDumps) {
+SCOPED_TRACE(llvm::join(GetParam().getCommandLineArgs(), " "));
+
+auto AnnotatedCode = llvm::Annotations(CodeWithAnnotations);
+auto *Root = buildTree(AnnotatedCode.code(), GetParam());
+
+if (Diags->getClient()->getNumErrors() != 0) {
+  return ::testing::AssertionFailure()
+ << "Source file has syntax errors, they were printed to the test "
+"log";
+}
+
+auto AnnotatedRanges = AnnotatedCode.ranges();
+if (AnnotatedRanges.size() != TreeDumps.size()) {
+  return ::testing::AssertionFailure()
+ << "The number of annotated ranges in the source code is "
+"
diff erent "
+"to the number of their corresponding tree dumps.";
+}
+bool Failed = false;
+for (unsigned i = 0; i < AnnotatedRanges.size(); i++) {
+  auto *AnnotatedNode = nodeByRange(AnnotatedRanges[i], Root);
+  assert(AnnotatedNode);
+  auto AnnotatedNodeDump =
+  StringRef(AnnotatedNode->dump(Arena->sourceManager())).trim().str();
+  // EXPECT_EQ shows the 
diff  between the two strings if they are 
diff erent.
+  EXPECT_EQ(TreeDumps[i].trim().str(), AnnotatedNodeDump)
+  << "Dumps diverged for the code:\n"
+  << AnnotatedCode.code().slice(AnnotatedRanges[i].Begin,
+AnnotatedRanges[i].End);
+  if (AnnotatedNodeDump != TreeDumps[i].trim().str())
+Failed = true;
+}
+return Failed ? ::testing::AssertionFailure()
+  : ::testing::AssertionSuccess();
+  }
+};
+
+INSTANTIATE_TEST_CASE_P(SyntaxTreeTests, BuildSyntaxTreeTest,
+testing::ValuesIn(allTestClangConfigs()), );
+
+TEST_P(BuildSyntaxTreeTest, Simple) {
   EXPECT_TRUE(treeDumpEqual(
   R"cpp(
 int main() {}
@@ -48,7 +111,7 @@ TranslationUnit Detached
 )txt"));
 }
 
-TEST_P(SyntaxTreeTest, SimpleVariable) {
+TEST_P(BuildSyntaxTreeTest, SimpleVariable) {
   EXPECT_TRUE(treeDumpEqual(
   R"cpp(
 int a;
@@ -72,7 +135,7 @@ TranslationUnit Detached
 )txt"));
 }
 
-TEST_P(SyntaxTreeTest, SimpleFunction) {
+TEST_P(BuildSyntaxTreeTest, SimpleFunction) {
   EXPECT_TRUE(treeDumpEqual(
   R"cpp(
 void foo(int a, int b) {}
@@ -102,7 +165,7 @@ TranslationUnit Detached
 )txt"));
 }
 
-TEST_P(SyntaxTreeTest, If) {
+TEST_P(BuildSyntaxTreeTest, If) {
   EXPECT_TRUE(treeDumpEqualOnAnnotations(
   R"cpp(
 void test() {
@@ -144,7 +207,7 @@ IfStatement Statement
 )txt"}));
 }
 
-TEST_P(SyntaxTreeTest, For) {
+TEST_P(BuildSyntaxTreeTest, For) {
   EXPECT_TRUE(treeDumpEqualOnAnnotations(
   R"cpp(
 void test() {
@@ -164,7 +227,7 @@ ForStatement Statement
 )txt"}));
 }
 
-TEST_P(SyntaxTreeTest, RangeBasedFor) {
+TEST_P(BuildSyntaxTreeTest, RangeBasedFor) {
   if 

[PATCH] D87459: [libcxx][test] ostream{,buf}_iterator::difference_type changes in C++20

2020-09-10 Thread Louis Dionne via Phabricator via cfe-commits
ldionne commandeered this revision.
ldionne edited reviewers, added: CaseyCarter; removed: ldionne.
ldionne added a comment.
Herald added a subscriber: jkorous.

In D87459#2265875 , @CaseyCarter wrote:

>> Ah, I see it. I'll add that bit to libc++ so we don't need special casing in 
>> the tests.
>
> Feel free to steal this for your test changes. Shall I close this 
> differential then?

No need, I'll steal it by commandeering.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87459

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


[PATCH] D71199: [clang-tidy] New check cppcoreguidelines-prefer-member-initializer

2020-09-10 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware added a comment.

OK, I reversed the matcher expression now, it seems to work, but I will check 
it on the //LLVM/Clang// codebase first.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71199

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


[PATCH] D71199: [clang-tidy] New check cppcoreguidelines-prefer-member-initializer

2020-09-10 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware added a comment.

I found the problem: `hasBody()` always returns true if the function has 
//somewhere// a body. This means that also the `hasBody` matcher matches 
forward declarations. However, I only need the definition. This far I could not 
find any method to achieve that: `isDefinition()` also returns true for forward 
declarations, as well as comparing with the `CanonicalDecl`. I am looking 
further...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71199

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


[PATCH] D87463: [clang][aarch64] Fix mangling of bfloat16 neon vectors

2020-09-10 Thread Cullen Rhodes via Phabricator via cfe-commits
c-rhodes created this revision.
c-rhodes added reviewers: sdesmalen, SjoerdMeijer, stuij.
Herald added subscribers: danielkiss, kristof.beyls.
Herald added a project: clang.
c-rhodes requested review of this revision.

The AAPCS64 specifies the internal type is used for c++ mangling. For
bfloat16 it was defined as `BFloat16` when it should be `Bfloat16`, i.e.
lowercase 'f'.

For more information, see:

https://github.com/ARM-software/abi-aa/blob/master/aapcs64/aapcs64.rst#appendix-support-for-advanced-simd-extensions


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87463

Files:
  clang/lib/AST/ItaniumMangle.cpp
  clang/test/CodeGenCXX/mangle-neon-vectors.cpp


Index: clang/test/CodeGenCXX/mangle-neon-vectors.cpp
===
--- clang/test/CodeGenCXX/mangle-neon-vectors.cpp
+++ clang/test/CodeGenCXX/mangle-neon-vectors.cpp
@@ -1,6 +1,7 @@
 // RUN: %clang_cc1 -triple armv7-apple-ios -target-feature +neon  %s 
-emit-llvm -o - | FileCheck %s
 // RUN: %clang_cc1 -triple arm64-apple-ios -target-feature +neon %s -emit-llvm 
-o - | FileCheck %s
 // RUN: %clang_cc1 -triple arm64-linux-gnu -target-feature +neon %s -emit-llvm 
-o - | FileCheck %s --check-prefix=CHECK-AARCH64
+// RUN: %clang_cc1 -triple arm64-linux-gnu -target-feature +neon 
-target-feature +bf16 %s -emit-llvm -o - | FileCheck %s 
--check-prefix=CHECK-AARCH64-BF16
 
 typedef float float32_t;
 typedef double float64_t;
@@ -14,6 +15,10 @@
 #endif
 typedef unsigned __INT64_TYPE__ uint64_t;
 
+#if defined(__ARM_FEATURE_BF16)
+typedef __bf16 bfloat16_t;
+#endif
+
 typedef __attribute__((neon_vector_type(2))) int int32x2_t;
 typedef __attribute__((neon_vector_type(4))) int int32x4_t;
 typedef __attribute__((neon_vector_type(1))) uint64_t uint64x1_t;
@@ -28,6 +33,10 @@
 typedef __attribute__((neon_polyvector_type(16))) poly8_t  poly8x16_t;
 typedef __attribute__((neon_polyvector_type(8)))  poly16_t poly16x8_t;
 
+#if defined(__ARM_FEATURE_BF16)
+typedef __attribute__((neon_vector_type(4))) __bf16 bfloat16x4_t;
+#endif
+
 // CHECK: 16__simd64_int32_t
 // CHECK-AARCH64: 11__Int32x2_t
 void f1(int32x2_t v) { }
@@ -72,3 +81,8 @@
 // CHECK-AARCH64: 13__Float64x2_t
 void f11(float64x2_t v) { }
 #endif
+
+#if defined(__ARM_FEATURE_BF16)
+// CHECK-AARCH64-BF16: 14__Bfloat16x4_t
+void f12(bfloat16x4_t v) {}
+#endif
Index: clang/lib/AST/ItaniumMangle.cpp
===
--- clang/lib/AST/ItaniumMangle.cpp
+++ clang/lib/AST/ItaniumMangle.cpp
@@ -3275,7 +3275,7 @@
   case BuiltinType::Double:
 return "Float64";
   case BuiltinType::BFloat16:
-return "BFloat16";
+return "Bfloat16";
   default:
 llvm_unreachable("Unexpected vector element base type");
   }


Index: clang/test/CodeGenCXX/mangle-neon-vectors.cpp
===
--- clang/test/CodeGenCXX/mangle-neon-vectors.cpp
+++ clang/test/CodeGenCXX/mangle-neon-vectors.cpp
@@ -1,6 +1,7 @@
 // RUN: %clang_cc1 -triple armv7-apple-ios -target-feature +neon  %s -emit-llvm -o - | FileCheck %s
 // RUN: %clang_cc1 -triple arm64-apple-ios -target-feature +neon %s -emit-llvm -o - | FileCheck %s
 // RUN: %clang_cc1 -triple arm64-linux-gnu -target-feature +neon %s -emit-llvm -o - | FileCheck %s --check-prefix=CHECK-AARCH64
+// RUN: %clang_cc1 -triple arm64-linux-gnu -target-feature +neon -target-feature +bf16 %s -emit-llvm -o - | FileCheck %s --check-prefix=CHECK-AARCH64-BF16
 
 typedef float float32_t;
 typedef double float64_t;
@@ -14,6 +15,10 @@
 #endif
 typedef unsigned __INT64_TYPE__ uint64_t;
 
+#if defined(__ARM_FEATURE_BF16)
+typedef __bf16 bfloat16_t;
+#endif
+
 typedef __attribute__((neon_vector_type(2))) int int32x2_t;
 typedef __attribute__((neon_vector_type(4))) int int32x4_t;
 typedef __attribute__((neon_vector_type(1))) uint64_t uint64x1_t;
@@ -28,6 +33,10 @@
 typedef __attribute__((neon_polyvector_type(16))) poly8_t  poly8x16_t;
 typedef __attribute__((neon_polyvector_type(8)))  poly16_t poly16x8_t;
 
+#if defined(__ARM_FEATURE_BF16)
+typedef __attribute__((neon_vector_type(4))) __bf16 bfloat16x4_t;
+#endif
+
 // CHECK: 16__simd64_int32_t
 // CHECK-AARCH64: 11__Int32x2_t
 void f1(int32x2_t v) { }
@@ -72,3 +81,8 @@
 // CHECK-AARCH64: 13__Float64x2_t
 void f11(float64x2_t v) { }
 #endif
+
+#if defined(__ARM_FEATURE_BF16)
+// CHECK-AARCH64-BF16: 14__Bfloat16x4_t
+void f12(bfloat16x4_t v) {}
+#endif
Index: clang/lib/AST/ItaniumMangle.cpp
===
--- clang/lib/AST/ItaniumMangle.cpp
+++ clang/lib/AST/ItaniumMangle.cpp
@@ -3275,7 +3275,7 @@
   case BuiltinType::Double:
 return "Float64";
   case BuiltinType::BFloat16:
-return "BFloat16";
+return "Bfloat16";
   default:
 llvm_unreachable("Unexpected vector element base type");
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[PATCH] D87461: Disable sanitizer options for AMDGPU

2020-09-10 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl created this revision.
yaxunl added reviewers: tra, ashi1.
Herald added subscribers: t-tye, tpr, dstuttard, kzhuravl.
yaxunl requested review of this revision.
Herald added a subscriber: wdng.

Currently AMDGPU does not support sanitizer. Disable sanitizer options for now 
until they are supported.


https://reviews.llvm.org/D87461

Files:
  clang/lib/Driver/SanitizerArgs.cpp
  clang/test/Driver/hip-sanitize-options.hip


Index: clang/test/Driver/hip-sanitize-options.hip
===
--- /dev/null
+++ clang/test/Driver/hip-sanitize-options.hip
@@ -0,0 +1,9 @@
+// REQUIRES: clang-driver, x86-registered-target, amdgpu-registered-target
+
+// RUN: %clang -### -target x86_64-unknown-linux-gnu --offload-arch=gfx906 \
+// RUN:   -fsanitize=address \
+// RUN:   -nogpuinc -nogpulib \
+// RUN:   %s 2>&1 | FileCheck %s
+
+// CHECK-NOT: {{"[^"]*clang[^"]*".* "-fcuda-is-device".* "-fsanitize=address"}}
+// CHECK: {{"[^"]*clang[^"]*".* "-triple" "x86_64-unknown-linux-gnu".* 
"-fsanitize=address"}}
Index: clang/lib/Driver/SanitizerArgs.cpp
===
--- clang/lib/Driver/SanitizerArgs.cpp
+++ clang/lib/Driver/SanitizerArgs.cpp
@@ -929,10 +929,10 @@
 void SanitizerArgs::addArgs(const ToolChain , const llvm::opt::ArgList 
,
 llvm::opt::ArgStringList ,
 types::ID InputType) const {
-  // NVPTX doesn't currently support sanitizers.  Bailing out here means that
-  // e.g. -fsanitize=address applies only to host code, which is what we want
-  // for now.
-  if (TC.getTriple().isNVPTX())
+  // NVPTX/AMDGPU doesn't currently support sanitizers.  Bailing out here means
+  // that e.g. -fsanitize=address applies only to host code, which is what we
+  // want for now.
+  if (TC.getTriple().isNVPTX() || TC.getTriple().isAMDGPU())
 return;
 
   // Translate available CoverageFeatures to corresponding clang-cc1 flags.


Index: clang/test/Driver/hip-sanitize-options.hip
===
--- /dev/null
+++ clang/test/Driver/hip-sanitize-options.hip
@@ -0,0 +1,9 @@
+// REQUIRES: clang-driver, x86-registered-target, amdgpu-registered-target
+
+// RUN: %clang -### -target x86_64-unknown-linux-gnu --offload-arch=gfx906 \
+// RUN:   -fsanitize=address \
+// RUN:   -nogpuinc -nogpulib \
+// RUN:   %s 2>&1 | FileCheck %s
+
+// CHECK-NOT: {{"[^"]*clang[^"]*".* "-fcuda-is-device".* "-fsanitize=address"}}
+// CHECK: {{"[^"]*clang[^"]*".* "-triple" "x86_64-unknown-linux-gnu".* "-fsanitize=address"}}
Index: clang/lib/Driver/SanitizerArgs.cpp
===
--- clang/lib/Driver/SanitizerArgs.cpp
+++ clang/lib/Driver/SanitizerArgs.cpp
@@ -929,10 +929,10 @@
 void SanitizerArgs::addArgs(const ToolChain , const llvm::opt::ArgList ,
 llvm::opt::ArgStringList ,
 types::ID InputType) const {
-  // NVPTX doesn't currently support sanitizers.  Bailing out here means that
-  // e.g. -fsanitize=address applies only to host code, which is what we want
-  // for now.
-  if (TC.getTriple().isNVPTX())
+  // NVPTX/AMDGPU doesn't currently support sanitizers.  Bailing out here means
+  // that e.g. -fsanitize=address applies only to host code, which is what we
+  // want for now.
+  if (TC.getTriple().isNVPTX() || TC.getTriple().isAMDGPU())
 return;
 
   // Translate available CoverageFeatures to corresponding clang-cc1 flags.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D87459: [libcxx][test] ostream{,buf}_iterator::difference_type changes in C++20

2020-09-10 Thread Casey Carter via Phabricator via cfe-commits
CaseyCarter added a comment.

> Ah, I see it. I'll add that bit to libc++ so we don't need special casing in 
> the tests.

Feel free to steal this for your test changes. Shall I close this differential 
then?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87459

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


[PATCH] D87459: [libcxx][test] ostream{,buf}_iterator::difference_type changes in C++20

2020-09-10 Thread Louis Dionne via Phabricator via cfe-commits
ldionne added a comment.

In D87459#2265871 , @CaseyCarter wrote:

> In D87459#2265864 , @ldionne wrote:
>
>> What paper is this? I searched but failed to find a paper this falls off 
>> from.
>
> P0896R4 "The One Ranges Proposal" - Ranges demands that all iterators have 
> useful difference types.

Ah, I see it. I'll add that bit to libc++ so we don't need special casing in 
the tests.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87459

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


[PATCH] D87331: Sema: add support for `__attribute__((__swift_error__))`

2020-09-10 Thread Saleem Abdulrasool via Phabricator via cfe-commits
compnerd updated this revision to Diff 290990.
compnerd added a comment.

Address @gribozavr2's comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87331

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/SemaObjC/attr-swift-error.m

Index: clang/test/SemaObjC/attr-swift-error.m
===
--- /dev/null
+++ clang/test/SemaObjC/attr-swift-error.m
@@ -0,0 +1,93 @@
+// RUN: %clang_cc1 -verify -fsyntax-only -fobjc-arc -fblocks %s
+
+@class NSError;
+
+#if __SIZEOF_POINTER__ == 4
+typedef unsigned char BOOL;
+#else
+typedef _Bool BOOL;
+#endif
+
+typedef struct __attribute__((__objc_bridge__(NSError))) __CFError *CFErrorRef;
+
+extern int f0(void) __attribute__((__swift_error__));
+// expected-error@-1 {{'__swift_error__' attribute takes one argument}}
+extern int f1(void) __attribute__((__swift_error__(invalid)));
+// expected-warning@-1 {{'__swift_error__' attribute argument not supported: 'invalid'}}
+extern int f2(void) __attribute__((__swift_error__(none,zero_result)));
+// expected-error@-1 {{use of undeclared identifier 'zero_result'}}
+
+@interface Erroneous
+- (BOOL)m0:(NSError **)error __attribute__((__swift_error__(none)));
+- (BOOL)m1:(NSError **)error __attribute__((__swift_error__(nonnull_error)));
+- (BOOL)m2:(NSError **)error __attribute__((__swift_error__(null_result)));
+// expected-error@-1 {{'__swift_error__' attribute with 'null_result' convention can only be applied to a method returning a pointer}}
+- (BOOL)m3:(NSError **)error __attribute__((__swift_error__(nonzero_result)));
+- (BOOL)m4:(NSError **)error __attribute__((__swift_error__(zero_result)));
+
+- (Undeclared)n0:(NSError **)error __attribute__((__swift_error__(none)));
+// expected-error@-1 {{expected a type}}
+- (Undeclared)n1:(NSError **)error __attribute__((__swift_error__(nonnull_error)));
+// expected-error@-1 {{expected a type}}
+- (Undeclared)n2:(NSError **)error __attribute__((__swift_error__(null_result)));
+// expected-error@-1 {{expected a type}}
+- (Undeclared)n3:(NSError **)error __attribute__((__swift_error__(nonzero_result)));
+// expected-error@-1 {{expected a type}}
+// FIXME: the follow-on warning should really be suppressed, but apparently
+// having an ill-formed return type doesn't mark anything as invalid.
+// expected-error@-4 {{can only be applied}}
+- (Undeclared)n4:(NSError **)error __attribute__((__swift_error__(zero_result)));
+// expected-error@-1 {{expected a type}}
+// FIXME: the follow-on warning should really be suppressed, but apparently
+// having an ill-formed return type doesn't mark anything as invalid.
+// expected-error@-4 {{can only be applied}}
+
+- (instancetype)o0 __attribute__((__swift_error__(none)));
+- (instancetype)o1 __attribute__((__swift_error__(nonnull_error)));
+// expected-error@-1 {{'__swift_error__' attribute can only be applied to a method with an error parameter}}
+- (instancetype)o2 __attribute__((__swift_error__(null_result)));
+// expected-error@-1 {{'__swift_error__' attribute can only be applied to a method with an error parameter}}
+- (instancetype)o3 __attribute__((__swift_error__(nonzero_result)));
+// expected-error@-1 {{'__swift_error__' attribute can only be applied to a method with an error parameter}}
+- (instancetype)o4 __attribute__((__swift_error__(zero_result)));
+// expected-error@-1 {{'__swift_error__' attribute can only be applied to a method with an error parameter}}
+@end
+
+extern BOOL m0(CFErrorRef *) __attribute__((__swift_error__(none)));
+extern BOOL m1(CFErrorRef *) __attribute__((__swift_error__(nonnull_error)));
+extern BOOL m2(CFErrorRef *) __attribute__((__swift_error__(null_result)));
+// expected-error@-1 {{'__swift_error__' attribute with 'null_result' convention can only be applied to a function returning a pointer}}
+extern BOOL m3(CFErrorRef *) __attribute__((__swift_error__(nonzero_result)));
+extern BOOL m4(CFErrorRef *) __attribute__((__swift_error__(zero_result)));
+
+extern Undeclared n0(CFErrorRef *) __attribute__((__swift_error__(none)));
+// expected-error@-1 {{unknown type name 'Undeclared'}}
+extern Undeclared n1(CFErrorRef *) __attribute__((__swift_error__(nonnull_error)));
+// expected-error@-1 {{unknown type name 'Undeclared'}}
+extern Undeclared n2(CFErrorRef *) __attribute__((__swift_error__(null_result)));
+// expected-error@-1 {{unknown type name 'Undeclared'}}
+extern Undeclared n3(CFErrorRef *) __attribute__((__swift_error__(nonzero_result)));
+// expected-error@-1 {{unknown type name 'Undeclared'}}
+extern Undeclared n4(CFErrorRef *) __attribute__((__swift_error__(zero_result)));
+// expected-error@-1 {{unknown type name 'Undeclared'}}
+
+extern void *o0(CFErrorRef *) 

[PATCH] D87459: [libcxx][test] ostream{,buf}_iterator::difference_type changes in C++20

2020-09-10 Thread Casey Carter via Phabricator via cfe-commits
CaseyCarter added a comment.

In D87459#2265864 , @ldionne wrote:

> What paper is this? I searched but failed to find a paper this falls off from.

P0896R4 "The One Ranges Proposal" - Ranges demands that all iterators have 
useful difference types.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87459

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


[PATCH] D87331: Sema: add support for `__attribute__((__swift_error__))`

2020-09-10 Thread Saleem Abdulrasool via Phabricator via cfe-commits
compnerd marked 2 inline comments as done.
compnerd added inline comments.



Comment at: clang/test/SemaObjC/attr-swift-error.m:55
+
+// This is unconventional and very odd but we do process it.
+- (int)q0:(const NSError **)error 
__attribute__((__swift_error__(nonzero_result)));

gribozavr2 wrote:
> 
Removed the test case in light of John's comment.



Comment at: clang/test/SemaObjC/attr-swift-error.m:97
+
+// This is unconventional and very odd but we do process it.
+extern void *q0(const CFErrorRef *) 
__attribute__((__swift_error__(null_result)));

gribozavr2 wrote:
> 
Similar


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87331

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


[PATCH] D87459: [libcxx][test] ostream{,buf}_iterator::difference_type changes in C++20

2020-09-10 Thread Louis Dionne via Phabricator via cfe-commits
ldionne added a comment.

What paper is this? I searched but failed to find a paper this falls off from.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87459

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


RE: Clang-Format, Clang-Tidy - Absolute Path to config files

2020-09-10 Thread via cfe-commits
Hi Francois,

I read your usecase. Our usecase is similar, but the difference is that we use 
Artifactory to store our tools and Conan to manage and install them. This way, 
having a Conan package with everything in it, including the config file is very 
scalable and maintainable.

I did not quite understand the last statement: “But as long as you are ready to 
recompile clang-format, it should work fine.” . I am a noob to contributing to 
open source software and I really do not know how to contribute, how to 
integrate the code. The idea would be to integrate this feature, so if we want 
to use future releases of Clang, they will also contain this feature and we 
will not need to integrate it again at every release.

Best regards,
Cezar

From: Typz 
Sent: joi, 10 septembrie 2020 17:58
To: Diplasu Cezar (IFRO DCBUC ATV SC D DD) 
Cc: cfe-commits@lists.llvm.org
Subject: Re: Clang-Format, Clang-Tidy - Absolute Path to config files

Caution: This e-mail originated outside Infineon Technologies. Do not click on 
links or open attachments unless you validate it is 
safe.


Hello,

I worked on adding a similar feature some time back : 
https://reviews.llvm.org/D50147
It supports specifying styles by absolute file name as well as lookup of a 
style by name in various locations (like ~/.local/share/clang-format or 
/usr/share/clang-format), allowing to install styles on the machine and use 
them similarly to "integrated" styles : e.g. reference them in BasedOnStyle tag 
or specify them via the --style parameter...

Unfortunately there was no consensus on this approach, and I did not get the 
time yet to finalize something that could be integrated. But as long as you are 
ready to recompile clang-format, it should work fine.
Best regards,

--
Francois

On Thu, Sep 10, 2020 at 2:28 PM via cfe-commits 
mailto:cfe-commits@lists.llvm.org>> wrote:
Hi all,


I have recently started to work with Clang-Format and Clang-Tidy tools as part 
of a methodology project in my company.
We want to have a uniform style and format in the entire department and for 
that we want to use the two tools to automatically keep this in order. For this 
we need to be able to store the config files somewhere available for everybody 
and for any project.

In my research, I did not find the possibility to give an Absolute Path to the 
config files of the tools.

This is why I added the feature myself and recompiled the tools. Could some 
body help me with the integration of the feature in the community?


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


Re: [clang-tools-extra] 156b127 - Add a new altera check for structure packing and alignment.

2020-09-10 Thread Aaron Ballman via cfe-commits
On Thu, Sep 10, 2020 at 11:27 AM Nico Weber  wrote:
>
> Looks like this broke the sphinx bot: 
> http://lab.llvm.org:8011/builders/clang-tools-sphinx-docs/builds/65757/steps/docs-clang-tools-html/logs/stdio
>
> Can you take a look?

Hopefully 66ac212ea97a529e171a7b8aea10638d7b9b9907 will resolve the
issue while I get sphinx up and running on this box in case it
doesn't.

~Aaron

>
> On Tue, Sep 8, 2020 at 9:36 AM Aaron Ballman via cfe-commits 
>  wrote:
>>
>>
>> Author: Frank Derry Wanye
>> Date: 2020-09-08T09:35:14-04:00
>> New Revision: 156b127945a8c923d141e608b7380427da024376
>>
>> URL: 
>> https://github.com/llvm/llvm-project/commit/156b127945a8c923d141e608b7380427da024376
>> DIFF: 
>> https://github.com/llvm/llvm-project/commit/156b127945a8c923d141e608b7380427da024376.diff
>>
>> LOG: Add a new altera check for structure packing and alignment.
>>
>> The altera struct pack align lint check finds structs that are inefficiently
>> packed or aligned and recommends packing/aligning of the structs using the
>> packed and aligned attributes as needed in a warning.
>>
>> Added:
>> clang-tools-extra/clang-tidy/altera/AlteraTidyModule.cpp
>> clang-tools-extra/clang-tidy/altera/CMakeLists.txt
>> clang-tools-extra/clang-tidy/altera/StructPackAlignCheck.cpp
>> clang-tools-extra/clang-tidy/altera/StructPackAlignCheck.h
>> clang-tools-extra/docs/clang-tidy/checks/altera-struct-pack-align.rst
>> clang-tools-extra/test/clang-tidy/checkers/altera-struct-pack-align.cpp
>>
>> Modified:
>> clang-tools-extra/clang-tidy/CMakeLists.txt
>> clang-tools-extra/clang-tidy/ClangTidyForceLinker.h
>> clang-tools-extra/docs/ReleaseNotes.rst
>> clang-tools-extra/docs/clang-tidy/checks/list.rst
>> clang-tools-extra/docs/clang-tidy/index.rst
>>
>> Removed:
>>
>>
>>
>> 
>> diff  --git a/clang-tools-extra/clang-tidy/CMakeLists.txt 
>> b/clang-tools-extra/clang-tidy/CMakeLists.txt
>> index 02573534ccae..923976197ebe 100644
>> --- a/clang-tools-extra/clang-tidy/CMakeLists.txt
>> +++ b/clang-tools-extra/clang-tidy/CMakeLists.txt
>> @@ -46,6 +46,7 @@ endif()
>>  # If you add a check, also add it to ClangTidyForceLinker.h in this 
>> directory.
>>  add_subdirectory(android)
>>  add_subdirectory(abseil)
>> +add_subdirectory(altera)
>>  add_subdirectory(boost)
>>  add_subdirectory(bugprone)
>>  add_subdirectory(cert)
>> @@ -71,6 +72,7 @@ add_subdirectory(zircon)
>>  set(ALL_CLANG_TIDY_CHECKS
>>clangTidyAndroidModule
>>clangTidyAbseilModule
>> +  clangTidyAlteraModule
>>clangTidyBoostModule
>>clangTidyBugproneModule
>>clangTidyCERTModule
>>
>> diff  --git a/clang-tools-extra/clang-tidy/ClangTidyForceLinker.h 
>> b/clang-tools-extra/clang-tidy/ClangTidyForceLinker.h
>> index 1d6bd2a4fd62..63e681f878db 100644
>> --- a/clang-tools-extra/clang-tidy/ClangTidyForceLinker.h
>> +++ b/clang-tools-extra/clang-tidy/ClangTidyForceLinker.h
>> @@ -20,6 +20,11 @@ extern volatile int AbseilModuleAnchorSource;
>>  static int LLVM_ATTRIBUTE_UNUSED AbseilModuleAnchorDestination =
>>  AbseilModuleAnchorSource;
>>
>> +// This anchor is used to force the linker to link the AlteraModule.
>> +extern volatile int AlteraModuleAnchorSource;
>> +static int LLVM_ATTRIBUTE_UNUSED AlteraModuleAnchorDestination =
>> +AlteraModuleAnchorSource;
>> +
>>  // This anchor is used to force the linker to link the AndroidModule.
>>  extern volatile int AndroidModuleAnchorSource;
>>  static int LLVM_ATTRIBUTE_UNUSED AndroidModuleAnchorDestination =
>>
>> diff  --git a/clang-tools-extra/clang-tidy/altera/AlteraTidyModule.cpp 
>> b/clang-tools-extra/clang-tidy/altera/AlteraTidyModule.cpp
>> new file mode 100644
>> index ..d91f67ac1485
>> --- /dev/null
>> +++ b/clang-tools-extra/clang-tidy/altera/AlteraTidyModule.cpp
>> @@ -0,0 +1,39 @@
>> +//===--- AlteraTidyModule.cpp - clang-tidy 
>> ===//
>> +//
>> +// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
>> Exceptions.
>> +// See https://llvm.org/LICENSE.txt for license information.
>> +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
>> +//
>> +//===--===//
>> +
>> +#include "../ClangTidy.h"
>> +#include "../ClangTidyModule.h"
>> +#include "../ClangTidyModuleRegistry.h"
>> +#include "StructPackAlignCheck.h"
>> +
>> +using namespace clang::ast_matchers;
>> +
>> +namespace clang {
>> +namespace tidy {
>> +namespace altera {
>> +
>> +class AlteraModule : public ClangTidyModule {
>> +public:
>> +  void addCheckFactories(ClangTidyCheckFactories ) override {
>> +CheckFactories.registerCheck(
>> +"altera-struct-pack-align");
>> +  }
>> +};
>> +
>> +} // namespace altera
>> +
>> +// Register the AlteraTidyModule using this statically initialized variable.
>> +static ClangTidyModuleRegistry::Add
>> +X("altera-module", "Adds Altera FPGA OpenCL 

[PATCH] D87451: add new clang option -fnovisibility.

2020-09-10 Thread Digger via Phabricator via cfe-commits
DiggerLin updated this revision to Diff 290987.
DiggerLin added a comment.

address comment


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87451

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/AST/Decl.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Driver/fnovisibility.cpp

Index: clang/test/Driver/fnovisibility.cpp
===
--- /dev/null
+++ clang/test/Driver/fnovisibility.cpp
@@ -0,0 +1,81 @@
+// RUN: %clang-target powerpc-unknown-aix  -emit-llvm  -o - -S  %s  |\
+// RUN:   FileCheck --check-prefixes=NOVISIBILITY,AIX-NOVISIBILITY %s
+
+// RUN: %clang -fnovisibility -target powerpc-unknown-aix  -emit-llvm -o -  -S %s  | \
+// RUN: FileCheck -check-prefixes=NOVISIBILITY,AIX-NOVISIBILITY %s
+
+// RUN: %clang -fnovisibility -target powerpc-unknown-linux  -emit-llvm -o - -S %s  | \
+// RUN: FileCheck -check-prefixes=NOVISIBILITY,LINUX-NOVISIBILITY %s
+
+// RUN: %clang -fnovisibility -fvisibility=default -target powerpc-unknown-aix  -emit-llvm  -o - -S %s  | \
+// RUN: FileCheck -check-prefix=VISIBILITY %s
+
+// RUN: %clang -target powerpc-unknown-linux  -emit-llvm  -o - -S %s  | \
+// RUN: FileCheck -check-prefix=VISIBILITY %s
+
+// RUN: %clang -fnovisibility -fvisibility=default -target powerpc-unknown-linux  -emit-llvm -o - -S %s  | \
+// RUN: FileCheck -check-prefix=VISIBILITY %s
+
+__attribute__((visibility("hidden"))) void foo_h(int *p) {
+  (*p)++;
+}
+
+__attribute__((visibility("protected"))) int b;
+
+extern __attribute__((visibility("hidden"))) void zoo_extern_h(void);
+
+void (*foo_p)(void) = zoo_extern_h;
+
+__attribute__((visibility("protected"))) void bar() {
+  foo_h();
+  foo_p();
+}
+
+class TestClass {
+public:
+  __attribute__((__visibility__("hidden"))) int value() const noexcept { return 0; }
+};
+
+int main() {
+  TestClass TC;
+  return TC.value();
+}
+
+template 
+class basic {
+public:
+  __attribute__((__visibility__("protected"))) int getdata() { return 1; }
+};
+
+template class basic;
+
+#pragma GCC visibility push(hidden)
+ int pramb;
+ void prambar() {}
+#pragma GCC visibility pop
+
+
+// AIX-NOVISIBILITY:@b = global i32 0
+// LINUX-NOVISIBILITY:  @b = dso_local global i32 0
+// AIX-NOVISIBILITY:@pramb = global i32 0
+// LINUX-NOVISIBILITY:  @pramb = dso_local global i32 0
+// AIX-NOVISIBILITY:define void @_Z5foo_hPi(i32* %p)
+// LINUX-NOVISIBILITY:  define dso_local void @_Z5foo_hPi(i32* %p)
+// NOVISIBILITY:declare void @_Z12zoo_extern_hv()
+// AIX-NOVISIBILITY:define void @_Z3barv()
+// LINUX-NOVISIBILITY:  define dso_local void @_Z3barv()
+// AIX-NOVISIBILITY:define linkonce_odr i32 @_ZNK9TestClass5valueEv(%class.TestClass* %this)
+// LINUX-NOVISIBILITY:  define linkonce_odr dso_local i32 @_ZNK9TestClass5valueEv(%class.TestClass* %this)
+// AIX-NOVISIBILITY:define weak_odr i32 @_ZN5basicIiE7getdataEv(%class.basic* %this)
+// LINUX-NOVISIBILITY:  define weak_odr dso_local i32 @_ZN5basicIiE7getdataEv(%class.basic* %this)
+// AIX-NOVISIBILITY:define void @_Z7prambarv()
+// LINUX-NOVISIBILITY:  define dso_local void @_Z7prambarv()
+
+// VISIBILITY:@b = protected global i32 0
+// VISIBILITY:@pramb = hidden global i32 0
+// VISIBILITY:define hidden void @_Z5foo_hPi(i32* %p)
+// VISIBILITY:declare hidden void @_Z12zoo_extern_hv()
+// VISIBILITY:define protected void @_Z3barv()
+// VISIBILITY:define linkonce_odr hidden i32 @_ZNK9TestClass5valueEv(%class.TestClass* %this)
+// VISIBILITY:define weak_odr protected i32 @_ZN5basicIiE7getdataEv(%class.basic* %this)
+// VISIBILITY:define hidden void @_Z7prambarv()
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -2752,6 +2752,9 @@
 Opts.setValueVisibilityMode(parseVisibility(visOpt, Args, Diags));
   } else {
 Opts.setValueVisibilityMode(DefaultVisibility);
+// In AIX oS, the -fnovisibility is enable by default.
+if (T.isOSAIX() || Args.hasArg(OPT_fnovisibility))
+  Opts.NoVisibility = 1;
   }
 
   // The type-visibility mode defaults to the value-visibility mode.
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5198,6 +5198,9 @@
 }
   }
 
+  if (Args.getLastArg(options::OPT_fnovisibility))
+CmdArgs.push_back("-fnovisibility");
+
   Args.AddLastArg(CmdArgs, options::OPT_fvisibility_inlines_hidden);
   Args.AddLastArg(CmdArgs, options::OPT_fvisibility_global_new_delete_hidden);
 
Index: clang/lib/AST/Decl.cpp

[clang-tools-extra] 66ac212 - Speculatively fix the Sphinx builder.

2020-09-10 Thread Aaron Ballman via cfe-commits

Author: Aaron Ballman
Date: 2020-09-10T11:35:10-04:00
New Revision: 66ac212ea97a529e171a7b8aea10638d7b9b9907

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

LOG: Speculatively fix the Sphinx builder.

Added: 


Modified: 
clang-tools-extra/docs/ReleaseNotes.rst

Removed: 




diff  --git a/clang-tools-extra/docs/ReleaseNotes.rst 
b/clang-tools-extra/docs/ReleaseNotes.rst
index 192f200f34ac..563c0eced92e 100644
--- a/clang-tools-extra/docs/ReleaseNotes.rst
+++ b/clang-tools-extra/docs/ReleaseNotes.rst
@@ -70,7 +70,7 @@ Improvements to clang-tidy
 New modules
 ^^^
 
-- New :doc:`altera ` module.
+- New ``altera`` module.
 
   Includes checks related to OpenCL for FPGA coding guidelines, based on the
   `Altera SDK for OpenCL: Best Practices Guide



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


[PATCH] D87459: [libcxx][test] ostream{,buf}_iterator::difference_type changes in C++20

2020-09-10 Thread Casey Carter via Phabricator via cfe-commits
CaseyCarter created this revision.
CaseyCarter added reviewers: ldionne, mclow.lists, EricWF.
Herald added subscribers: libcxx-commits, dexonsmith.
Herald added a project: libc++.
Herald added a reviewer: libc++.
CaseyCarter requested review of this revision.

Although libc++ doesn't yet implement this change, these tests should expect 
the difference type of `std::ostream_iterator` and `std::ostreambuf_iterator` 
specializations to be `std::ptrdiff_t` instead of `void` when testing C++ 
versions greater than 17 if the library under test is not libc++.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87459

Files:
  libcxx/test/std/iterators/stream.iterators/ostream.iterator/types.pass.cpp
  libcxx/test/std/iterators/stream.iterators/ostreambuf.iterator/types.pass.cpp


Index: 
libcxx/test/std/iterators/stream.iterators/ostreambuf.iterator/types.pass.cpp
===
--- 
libcxx/test/std/iterators/stream.iterators/ostreambuf.iterator/types.pass.cpp
+++ 
libcxx/test/std/iterators/stream.iterators/ostreambuf.iterator/types.pass.cpp
@@ -19,6 +19,7 @@
 //   typedef basic_ostream   ostream_type;
 //   ...
 
+#include 
 #include 
 #include 
 #include 
@@ -34,7 +35,11 @@
 #else
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
+#if TEST_STD_VER <= 17 || defined(_LIBCPP_VERSION)
 static_assert((std::is_same::value), "");
+#else
+static_assert((std::is_same::value), 
"");
+#endif
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 #endif
@@ -50,7 +55,11 @@
 #else
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
+#if TEST_STD_VER <= 17 || defined(_LIBCPP_VERSION)
 static_assert((std::is_same::value), "");
+#else
+static_assert((std::is_same::value), 
"");
+#endif
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 #endif
Index: 
libcxx/test/std/iterators/stream.iterators/ostream.iterator/types.pass.cpp
===
--- libcxx/test/std/iterators/stream.iterators/ostream.iterator/types.pass.cpp
+++ libcxx/test/std/iterators/stream.iterators/ostream.iterator/types.pass.cpp
@@ -19,6 +19,7 @@
 // typedef basic_istream istream_type;
 // ...
 
+#include 
 #include 
 #include 
 
@@ -33,7 +34,11 @@
 #else
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
+#if TEST_STD_VER <= 17 || defined(_LIBCPP_VERSION)
 static_assert((std::is_same::value), "");
+#else
+static_assert((std::is_same::value), 
"");
+#endif
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 #endif
@@ -47,7 +52,11 @@
 #else
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
+#if TEST_STD_VER <= 17 || defined(_LIBCPP_VERSION)
 static_assert((std::is_same::value), "");
+#else
+static_assert((std::is_same::value), 
"");
+#endif
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 #endif


Index: libcxx/test/std/iterators/stream.iterators/ostreambuf.iterator/types.pass.cpp
===
--- libcxx/test/std/iterators/stream.iterators/ostreambuf.iterator/types.pass.cpp
+++ libcxx/test/std/iterators/stream.iterators/ostreambuf.iterator/types.pass.cpp
@@ -19,6 +19,7 @@
 //   typedef basic_ostream   ostream_type;
 //   ...
 
+#include 
 #include 
 #include 
 #include 
@@ -34,7 +35,11 @@
 #else
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
+#if TEST_STD_VER <= 17 || defined(_LIBCPP_VERSION)
 static_assert((std::is_same::value), "");
+#else
+static_assert((std::is_same::value), "");
+#endif
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 #endif
@@ -50,7 +55,11 @@
 #else
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
+#if TEST_STD_VER <= 17 || defined(_LIBCPP_VERSION)
 static_assert((std::is_same::value), "");
+#else
+static_assert((std::is_same::value), "");
+#endif
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 #endif
Index: libcxx/test/std/iterators/stream.iterators/ostream.iterator/types.pass.cpp
===
--- libcxx/test/std/iterators/stream.iterators/ostream.iterator/types.pass.cpp
+++ libcxx/test/std/iterators/stream.iterators/ostream.iterator/types.pass.cpp
@@ -19,6 +19,7 @@
 // typedef basic_istream istream_type;
 // ...
 
+#include 
 #include 
 #include 
 
@@ -33,7 +34,11 @@
 #else
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
+#if TEST_STD_VER <= 17 || defined(_LIBCPP_VERSION)
 

[PATCH] D87458: [Clang] Clarify __builtin_memcpy_inline documentation

2020-09-10 Thread Guillaume Chatelet via Phabricator via cfe-commits
gchatelet created this revision.
gchatelet added a reviewer: courbet.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
gchatelet requested review of this revision.

This patch updates the documentation about `__builtin_memcpy_inline` and 
reorders the sections so it is more consitent and understandable.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87458

Files:
  clang/docs/LanguageExtensions.rst


Index: clang/docs/LanguageExtensions.rst
===
--- clang/docs/LanguageExtensions.rst
+++ clang/docs/LanguageExtensions.rst
@@ -2408,20 +2408,6 @@
 Memory builtins
 ---
 
- * ``__builtin_memcpy_inline``
-
-.. code-block:: c
-
-  void __builtin_memcpy_inline(void *dst, const void *src, size_t size);
-
-``__builtin_memcpy_inline(dst, src, size)`` is identical to
-``__builtin_memcpy(dst, src, size)`` except that the generated code is
-guaranteed not to call any external functions. See LLVM IR `llvm.memcpy.inline
-`_ Intrinsic 
-for more information.
-
-Note that the `size` argument must be a compile time constant.
-
 Clang provides constant expression evaluation support for builtin forms of the
 following functions from the C standard library headers
  and :
@@ -2439,7 +2425,27 @@
 given size is an exact multiple of the element size that is no greater than
 the number of elements accessible through the source and destination operands.
 
-Constant evaluation support is not yet provided for 
``__builtin_memcpy_inline``.
+Guaranteed inlined copy
+^^^
+
+.. code-block:: c
+
+  void __builtin_memcpy_inline(void *dst, const void *src, size_t size);
+
+
+``__builtin_memcpy_inline`` has been designed as a building block for efficient
+``memcpy`` implementations. It is identical to ``__builtin_memcpy`` but also
+guarantees not to call any external functions. See LLVM IR `llvm.memcpy.inline
+`_ Intrinsic 
+for more information.
+
+This is useful to implement a custom version of ``memcpy``, implemement a
+``libc`` memcpy or work around the absence of a ``libc``.
+
+Note that the `size` argument must be a compile time constant.
+
+Note that this intrinsic cannot yet be called in a ``constexpr`` context.
+
 
 Atomic Min/Max builtins with memory ordering
 


Index: clang/docs/LanguageExtensions.rst
===
--- clang/docs/LanguageExtensions.rst
+++ clang/docs/LanguageExtensions.rst
@@ -2408,20 +2408,6 @@
 Memory builtins
 ---
 
- * ``__builtin_memcpy_inline``
-
-.. code-block:: c
-
-  void __builtin_memcpy_inline(void *dst, const void *src, size_t size);
-
-``__builtin_memcpy_inline(dst, src, size)`` is identical to
-``__builtin_memcpy(dst, src, size)`` except that the generated code is
-guaranteed not to call any external functions. See LLVM IR `llvm.memcpy.inline
-`_ Intrinsic 
-for more information.
-
-Note that the `size` argument must be a compile time constant.
-
 Clang provides constant expression evaluation support for builtin forms of the
 following functions from the C standard library headers
  and :
@@ -2439,7 +2425,27 @@
 given size is an exact multiple of the element size that is no greater than
 the number of elements accessible through the source and destination operands.
 
-Constant evaluation support is not yet provided for ``__builtin_memcpy_inline``.
+Guaranteed inlined copy
+^^^
+
+.. code-block:: c
+
+  void __builtin_memcpy_inline(void *dst, const void *src, size_t size);
+
+
+``__builtin_memcpy_inline`` has been designed as a building block for efficient
+``memcpy`` implementations. It is identical to ``__builtin_memcpy`` but also
+guarantees not to call any external functions. See LLVM IR `llvm.memcpy.inline
+`_ Intrinsic 
+for more information.
+
+This is useful to implement a custom version of ``memcpy``, implemement a
+``libc`` memcpy or work around the absence of a ``libc``.
+
+Note that the `size` argument must be a compile time constant.
+
+Note that this intrinsic cannot yet be called in a ``constexpr`` context.
+
 
 Atomic Min/Max builtins with memory ordering
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [clang-tools-extra] 156b127 - Add a new altera check for structure packing and alignment.

2020-09-10 Thread Nico Weber via cfe-commits
Looks like this broke the sphinx bot:
http://lab.llvm.org:8011/builders/clang-tools-sphinx-docs/builds/65757/steps/docs-clang-tools-html/logs/stdio

Can you take a look?

On Tue, Sep 8, 2020 at 9:36 AM Aaron Ballman via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

>
> Author: Frank Derry Wanye
> Date: 2020-09-08T09:35:14-04:00
> New Revision: 156b127945a8c923d141e608b7380427da024376
>
> URL:
> https://github.com/llvm/llvm-project/commit/156b127945a8c923d141e608b7380427da024376
> DIFF:
> https://github.com/llvm/llvm-project/commit/156b127945a8c923d141e608b7380427da024376.diff
>
> LOG: Add a new altera check for structure packing and alignment.
>
> The altera struct pack align lint check finds structs that are
> inefficiently
> packed or aligned and recommends packing/aligning of the structs using the
> packed and aligned attributes as needed in a warning.
>
> Added:
> clang-tools-extra/clang-tidy/altera/AlteraTidyModule.cpp
> clang-tools-extra/clang-tidy/altera/CMakeLists.txt
> clang-tools-extra/clang-tidy/altera/StructPackAlignCheck.cpp
> clang-tools-extra/clang-tidy/altera/StructPackAlignCheck.h
> clang-tools-extra/docs/clang-tidy/checks/altera-struct-pack-align.rst
> clang-tools-extra/test/clang-tidy/checkers/altera-struct-pack-align.cpp
>
> Modified:
> clang-tools-extra/clang-tidy/CMakeLists.txt
> clang-tools-extra/clang-tidy/ClangTidyForceLinker.h
> clang-tools-extra/docs/ReleaseNotes.rst
> clang-tools-extra/docs/clang-tidy/checks/list.rst
> clang-tools-extra/docs/clang-tidy/index.rst
>
> Removed:
>
>
>
>
> 
> diff  --git a/clang-tools-extra/clang-tidy/CMakeLists.txt
> b/clang-tools-extra/clang-tidy/CMakeLists.txt
> index 02573534ccae..923976197ebe 100644
> --- a/clang-tools-extra/clang-tidy/CMakeLists.txt
> +++ b/clang-tools-extra/clang-tidy/CMakeLists.txt
> @@ -46,6 +46,7 @@ endif()
>  # If you add a check, also add it to ClangTidyForceLinker.h in this
> directory.
>  add_subdirectory(android)
>  add_subdirectory(abseil)
> +add_subdirectory(altera)
>  add_subdirectory(boost)
>  add_subdirectory(bugprone)
>  add_subdirectory(cert)
> @@ -71,6 +72,7 @@ add_subdirectory(zircon)
>  set(ALL_CLANG_TIDY_CHECKS
>clangTidyAndroidModule
>clangTidyAbseilModule
> +  clangTidyAlteraModule
>clangTidyBoostModule
>clangTidyBugproneModule
>clangTidyCERTModule
>
> diff  --git a/clang-tools-extra/clang-tidy/ClangTidyForceLinker.h
> b/clang-tools-extra/clang-tidy/ClangTidyForceLinker.h
> index 1d6bd2a4fd62..63e681f878db 100644
> --- a/clang-tools-extra/clang-tidy/ClangTidyForceLinker.h
> +++ b/clang-tools-extra/clang-tidy/ClangTidyForceLinker.h
> @@ -20,6 +20,11 @@ extern volatile int AbseilModuleAnchorSource;
>  static int LLVM_ATTRIBUTE_UNUSED AbseilModuleAnchorDestination =
>  AbseilModuleAnchorSource;
>
> +// This anchor is used to force the linker to link the AlteraModule.
> +extern volatile int AlteraModuleAnchorSource;
> +static int LLVM_ATTRIBUTE_UNUSED AlteraModuleAnchorDestination =
> +AlteraModuleAnchorSource;
> +
>  // This anchor is used to force the linker to link the AndroidModule.
>  extern volatile int AndroidModuleAnchorSource;
>  static int LLVM_ATTRIBUTE_UNUSED AndroidModuleAnchorDestination =
>
> diff  --git a/clang-tools-extra/clang-tidy/altera/AlteraTidyModule.cpp
> b/clang-tools-extra/clang-tidy/altera/AlteraTidyModule.cpp
> new file mode 100644
> index ..d91f67ac1485
> --- /dev/null
> +++ b/clang-tools-extra/clang-tidy/altera/AlteraTidyModule.cpp
> @@ -0,0 +1,39 @@
> +//===--- AlteraTidyModule.cpp - clang-tidy
> ===//
> +//
> +// Part of the LLVM Project, under the Apache License v2.0 with LLVM
> Exceptions.
> +// See https://llvm.org/LICENSE.txt for license information.
> +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
> +//
>
> +//===--===//
> +
> +#include "../ClangTidy.h"
> +#include "../ClangTidyModule.h"
> +#include "../ClangTidyModuleRegistry.h"
> +#include "StructPackAlignCheck.h"
> +
> +using namespace clang::ast_matchers;
> +
> +namespace clang {
> +namespace tidy {
> +namespace altera {
> +
> +class AlteraModule : public ClangTidyModule {
> +public:
> +  void addCheckFactories(ClangTidyCheckFactories )
> override {
> +CheckFactories.registerCheck(
> +"altera-struct-pack-align");
> +  }
> +};
> +
> +} // namespace altera
> +
> +// Register the AlteraTidyModule using this statically initialized
> variable.
> +static ClangTidyModuleRegistry::Add
> +X("altera-module", "Adds Altera FPGA OpenCL lint checks.");
> +
> +// This anchor is used to force the linker to link in the generated
> object file
> +// and thus register the AlteraModule.
> +volatile int AlteraModuleAnchorSource = 0;
> +
> +} // namespace tidy
> +} // namespace clang
>
> diff  --git 

[PATCH] D87451: add new clang option -fnovisibility.

2020-09-10 Thread Digger via Phabricator via cfe-commits
DiggerLin updated this revision to Diff 290978.
DiggerLin added a comment.

add a pragmas test case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87451

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/AST/Decl.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/Driver/fnovisibility.cpp

Index: clang/test/Driver/fnovisibility.cpp
===
--- /dev/null
+++ clang/test/Driver/fnovisibility.cpp
@@ -0,0 +1,81 @@
+// RUN: %clang-target powerpc-unknown-aix  -emit-llvm  -o - -S  %s  |\
+// RUN:   FileCheck --check-prefixes=NOVISIBILITY,AIX-NOVISIBILITY %s
+
+// RUN: %clang -fnovisibility -target powerpc-unknown-aix  -emit-llvm -o -  -S %s  | \
+// RUN: FileCheck -check-prefixes=NOVISIBILITY,AIX-NOVISIBILITY %s
+
+// RUN: %clang -fnovisibility -target powerpc-unknown-linux  -emit-llvm -o - -S %s  | \
+// RUN: FileCheck -check-prefixes=NOVISIBILITY,LINUX-NOVISIBILITY %s
+
+// RUN: %clang -fnovisibility -fvisibility=default -target powerpc-unknown-aix  -emit-llvm  -o - -S %s  | \
+// RUN: FileCheck -check-prefix=VISIBILITY %s
+
+// RUN: %clang -target powerpc-unknown-linux  -emit-llvm  -o - -S %s  | \
+// RUN: FileCheck -check-prefix=VISIBILITY %s
+
+// RUN: %clang -fnovisibility -fvisibility=default -target powerpc-unknown-linux  -emit-llvm -o - -S %s  | \
+// RUN: FileCheck -check-prefix=VISIBILITY %s
+
+__attribute__((visibility("hidden"))) void foo_h(int *p) {
+  (*p)++;
+}
+
+__attribute__((visibility("protected"))) int b;
+
+extern __attribute__((visibility("hidden"))) void zoo_extern_h(void);
+
+void (*foo_p)(void) = zoo_extern_h;
+
+__attribute__((visibility("protected"))) void bar() {
+  foo_h();
+  foo_p();
+}
+
+class TestClass {
+public:
+  __attribute__((__visibility__("hidden"))) int value() const noexcept { return 0; }
+};
+
+int main() {
+  TestClass TC;
+  return TC.value();
+}
+
+template 
+class basic {
+public:
+  __attribute__((__visibility__("protected"))) int getdata() { return 1; }
+};
+
+template class basic;
+
+#pragma GCC visibility push(hidden)
+ int pramb;
+ void prambar() {}
+#pragma GCC visibility pop
+
+
+// AIX-NOVISIBILITY:@b = global i32 0
+// LINUX-NOVISIBILITY:  @b = dso_local global i32 0
+// AIX-NOVISIBILITY:@pramb = global i32 0
+// LINUX-NOVISIBILITY:  @pramb = dso_local global i32 0
+// AIX-NOVISIBILITY:define void @_Z5foo_hPi(i32* %p)
+// LINUX-NOVISIBILITY:  define dso_local void @_Z5foo_hPi(i32* %p)
+// NOVISIBILITY:declare void @_Z12zoo_extern_hv()
+// AIX-NOVISIBILITY:define void @_Z3barv()
+// LINUX-NOVISIBILITY:  define dso_local void @_Z3barv()
+// AIX-NOVISIBILITY:define linkonce_odr i32 @_ZNK9TestClass5valueEv(%class.TestClass* %this)
+// LINUX-NOVISIBILITY:  define linkonce_odr dso_local i32 @_ZNK9TestClass5valueEv(%class.TestClass* %this)
+// AIX-NOVISIBILITY:define weak_odr i32 @_ZN5basicIiE7getdataEv(%class.basic* %this)
+// LINUX-NOVISIBILITY:  define weak_odr dso_local i32 @_ZN5basicIiE7getdataEv(%class.basic* %this)
+// AIX-NOVISIBILITY:define void @_Z7prambarv()
+// LINUX-NOVISIBILITY:  define dso_local void @_Z7prambarv()
+
+// VISIBILITY:@b = protected global i32 0
+// VISIBILITY:@pramb = hidden global i32 0
+// VISIBILITY:define hidden void @_Z5foo_hPi(i32* %p)
+// VISIBILITY:declare hidden void @_Z12zoo_extern_hv()
+// VISIBILITY:define protected void @_Z3barv()
+// VISIBILITY:define linkonce_odr hidden i32 @_ZNK9TestClass5valueEv(%class.TestClass* %this)
+// VISIBILITY:define weak_odr protected i32 @_ZN5basicIiE7getdataEv(%class.basic* %this)
+// VISIBILITY:define hidden void @_Z7prambarv()
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -2752,6 +2752,9 @@
 Opts.setValueVisibilityMode(parseVisibility(visOpt, Args, Diags));
   } else {
 Opts.setValueVisibilityMode(DefaultVisibility);
+// In AIX oS, the -fnovisibility is enable by default.
+if (T.isOSAIX() || Args.hasArg(OPT_fnovisibility))
+  Opts.NoVisibility = 1;
   }
 
   // The type-visibility mode defaults to the value-visibility mode.
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5198,6 +5198,9 @@
 }
   }
 
+  if (Args.getLastArg(options::OPT_fnovisibility))
+CmdArgs.push_back("-fnovisibility");
+
   Args.AddLastArg(CmdArgs, options::OPT_fvisibility_inlines_hidden);
   Args.AddLastArg(CmdArgs, options::OPT_fvisibility_global_new_delete_hidden);
 
Index: clang/lib/AST/Decl.cpp

[clang-tools-extra] 29cecbc - Fix clangd build after 33c9dbbd380

2020-09-10 Thread Nico Weber via cfe-commits

Author: Nico Weber
Date: 2020-09-10T11:05:53-04:00
New Revision: 29cecbc5d6fe2ee36635d593171d59eab631639f

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

LOG: Fix clangd build after 33c9dbbd380

Added: 


Modified: 
clang-tools-extra/clangd/CMakeLists.txt
llvm/utils/gn/secondary/clang-tools-extra/clangd/BUILD.gn

Removed: 




diff  --git a/clang-tools-extra/clangd/CMakeLists.txt 
b/clang-tools-extra/clangd/CMakeLists.txt
index 639441e8130a..3a1a034ed17b 100644
--- a/clang-tools-extra/clangd/CMakeLists.txt
+++ b/clang-tools-extra/clangd/CMakeLists.txt
@@ -33,6 +33,8 @@ if(MSVC AND NOT CLANG_CL)
  set_source_files_properties(CompileCommands.cpp PROPERTIES COMPILE_FLAGS 
-wd4130) # disables C4130: logical operation on address of string constant
 endif()
 
+include_directories(BEFORE "${CMAKE_CURRENT_BINARY_DIR}/../clang-tidy")
+
 add_clang_library(clangDaemon
   AST.cpp
   ClangdLSPServer.cpp

diff  --git a/llvm/utils/gn/secondary/clang-tools-extra/clangd/BUILD.gn 
b/llvm/utils/gn/secondary/clang-tools-extra/clangd/BUILD.gn
index 84d3f14bb2f2..7fa4cc8fd32c 100644
--- a/llvm/utils/gn/secondary/clang-tools-extra/clangd/BUILD.gn
+++ b/llvm/utils/gn/secondary/clang-tools-extra/clangd/BUILD.gn
@@ -27,6 +27,7 @@ static_library("clangd") {
 ":features",
 "//clang-tools-extra/clang-tidy",
 "//clang-tools-extra/clang-tidy:all-checks",
+"//clang-tools-extra/clang-tidy:clang-tidy-config",
 "//clang-tools-extra/clangd/support",
 "//clang/lib/AST",
 "//clang/lib/ASTMatchers",



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


[PATCH] D86465: [analyzer][solver] Redesign constraint ranges data structure

2020-09-10 Thread Denys Petrov via Phabricator via cfe-commits
ASDenysPetrov added a comment.

Here is my five cents. I haven't done with the review yet. I'm gonna return to 
it a bit later.




Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h:56
+  bool operator==(const Range ) const { return Impl == RHS.Impl; }
+  bool operator!=(const Range ) const { return !(*this == RHS); }
+

I'm not sure about optimizations but it seems like it could have less commands 
by omiting `this`.



Comment at: 
clang/include/clang/StaticAnalyzer/Core/PathSensitive/RangedConstraintManager.h:139
+/// @{
+RangeSet getSet(Range Origin);
+RangeSet getSet(const llvm::APSInt , const llvm::APSInt ) {

IMO function's name should match to what it does. If it creates smth, so its 
name should starts with `create`. Even if all other functions have misleading 
names it doesn't mean we are delegated to ignore this fact.
My another suggestion is that `Set` is a common term to `RangeSet`. So I'd 
prefer to use `getRangeSet` instead.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86465

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


Re: Clang-Format, Clang-Tidy - Absolute Path to config files

2020-09-10 Thread Typz via cfe-commits
Hello,

I worked on adding a similar feature some time back :
https://reviews.llvm.org/D50147
It supports specifying styles by absolute file name as well as lookup of a
style by name in various locations (like ~/.local/share/clang-format or
/usr/share/clang-format), allowing to install styles on the machine and use
them similarly to "integrated" styles : e.g. reference them in BasedOnStyle
tag or specify them via the --style parameter...

Unfortunately there was no consensus on this approach, and I did not get
the time yet to finalize something that could be integrated. But as long as
you are ready to recompile clang-format, it should work fine.
Best regards,

-- 
Francois

On Thu, Sep 10, 2020 at 2:28 PM via cfe-commits 
wrote:

> Hi all,
>
>
>
>
>
> I have recently started to work with Clang-Format and Clang-Tidy tools as
> part of a methodology project in my company.
>
> We want to have a uniform style and format in the entire department and
> for that we want to use the two tools to automatically keep this in order.
> For this we need to be able to store the config files somewhere available
> for everybody and for any project.
>
>
>
> In my research, I did not find the possibility to give an Absolute Path to
> the config files of the tools.
>
>
>
> This is why I added the feature myself and recompiled the tools. Could
> some body help me with the integration of the feature in the community?
>
>
>
>
>
> Best regards,
>
> Cezar
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D87455: Restrict UnnecessaryCopyInitialization check to variables initialized from methods/functions without arguments

2020-09-10 Thread Felix Berger via Phabricator via cfe-commits
flx created this revision.
flx added reviewers: alexfh, sbenza.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.
flx requested review of this revision.

This restriction avoids cases where an alias is returned to an argument and 
which could lead to to a false positive change. Example:

  struct S {
S(const S&);
void modify();
  };
  
  const S& alias(const S& a) {
return a;
  }
  
  void f(S a) {
const S c = alias(a);
a.modify();
  }

Taking a const reference of the return value of alias would not be safe since a 
is modified.

Still allow methods and functions with default arguments if they are called 
with their default arguments.

A more involved alternative approach would be to inspect each argument passed 
to these functions for its constness, but this can get complex quickly.

As I'm writing this I'm realizing though that this precludes catching repeated 
protobuff messages:

  Message m;
  const auto field = m.repeated_field(0);

Maybe this approach should be refined to allowing functions and methods that 
take all parameters by value?


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D87455

Files:
  clang-tools-extra/clang-tidy/performance/UnnecessaryCopyInitialization.cpp
  clang-tools-extra/clang-tidy/performance/UnnecessaryCopyInitialization.h
  
clang-tools-extra/test/clang-tidy/checkers/performance-unnecessary-copy-initialization.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/performance-unnecessary-copy-initialization.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/performance-unnecessary-copy-initialization.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/performance-unnecessary-copy-initialization.cpp
@@ -6,6 +6,8 @@
   const ExpensiveToCopyType () const;
   void nonConstMethod();
   bool constMethod() const;
+  const ExpensiveToCopyType (const ExpensiveToCopyType &) const;
+  const ExpensiveToCopyType (int arg = 0) const;
 };
 
 struct TrivialToCopyType {
@@ -23,6 +25,9 @@
 ExpensiveToCopyType global_expensive_to_copy_type;
 
 const ExpensiveToCopyType ();
+const ExpensiveToCopyType (const ExpensiveToCopyType &);
+const ExpensiveToCopyType (
+const ExpensiveToCopyType *arg = nullptr);
 const TrivialToCopyType ();
 
 void mutate(ExpensiveToCopyType &);
@@ -387,3 +392,38 @@
   for (const Element  : Container()) {
   }
 }
+
+// This should not trigger the check as the argument could introduce an alias.
+void negativeInitializedFromMethodWithArg() {
+  ExpensiveToCopyType Orig;
+  const ExpensiveToCopyType Copy = Orig.methodWithArg(Orig);
+}
+
+// This should not trigger the check as the argument could introduce an alias.
+void negativeInitializedFromFreeFunctionWithArg() {
+  ExpensiveToCopyType Orig;
+  const ExpensiveToCopyType Copy = freeFunctionWithArg(Orig);
+}
+
+void positiveInitializedFromMethodWithDefaultArg() {
+  ExpensiveToCopyType Orig;
+  const ExpensiveToCopyType Copy = Orig.methodWithDefaultArg();
+  // CHECK-MESSAGES: [[@LINE-1]]:29: warning: the const qualified variable 'Copy'
+  // CHECK-FIXES: const ExpensiveToCopyType& Copy = Orig.methodWithDefaultArg();
+}
+
+void negativeInitializedFromMethodWithNonDefaultArg() {
+  ExpensiveToCopyType Orig;
+  const ExpensiveToCopyType Copy = Orig.methodWithDefaultArg(5);
+}
+
+void positiveInitializedFromFreeFunctionWithDefaultArg() {
+  const ExpensiveToCopyType Copy = freeFunctionWithDefaultArg();
+  // CHECK-MESSAGES: [[@LINE-1]]:29: warning: the const qualified variable 'Copy'
+  // CHECK-FIXES: const ExpensiveToCopyType& Copy = freeFunctionWithDefaultArg();
+}
+
+void negativeInitialzedFromFreeFunctionWithNonDefaultArg() {
+  ExpensiveToCopyType Orig;
+  const ExpensiveToCopyType Copy = freeFunctionWithDefaultArg();
+}
Index: clang-tools-extra/clang-tidy/performance/UnnecessaryCopyInitialization.h
===
--- clang-tools-extra/clang-tidy/performance/UnnecessaryCopyInitialization.h
+++ clang-tools-extra/clang-tidy/performance/UnnecessaryCopyInitialization.h
@@ -36,6 +36,7 @@
 private:
   void handleCopyFromMethodReturn(const VarDecl , const Stmt ,
   bool IssueFix, const VarDecl *ObjectArg,
+  const CallExpr *InitCallExpr,
   ASTContext );
   void handleCopyFromLocalVar(const VarDecl , const VarDecl ,
   const Stmt , bool IssueFix,
Index: clang-tools-extra/clang-tidy/performance/UnnecessaryCopyInitialization.cpp
===
--- clang-tools-extra/clang-tidy/performance/UnnecessaryCopyInitialization.cpp
+++ clang-tools-extra/clang-tidy/performance/UnnecessaryCopyInitialization.cpp
@@ -29,6 +29,14 @@
   }
 }
 
+template 
+bool hasNonDefaultArgs(const Call , unsigned int StartIndex = 0) {
+  for (unsigned int I = StartIndex; I < CallExpr.getNumArgs(); ++I)

[PATCH] D87358: [clang][aarch64] Fix ILP32 ABI for arm_sve_vector_bits

2020-09-10 Thread Cullen Rhodes via Phabricator via cfe-commits
c-rhodes added inline comments.



Comment at: clang/lib/AST/Type.cpp:2339
   case BuiltinType::SveInt32:
-return Ctx.IntTy;
+return IsILP32 ? Ctx.LongTy : Ctx.IntTy;
   case BuiltinType::SveUint32:

efriedma wrote:
> sdesmalen wrote:
> > Rather than comparing with a specific triple, how about getting the 
> > information from `TargetInfo`, i.e.
> > 
> >   case BuiltinType::SveInt32:
> > Ctx.getTargetInfo().getLongWidth() == 32 ? Ctx.LongTy : Ctx.IntTy
> The type that actually corresponds to int64_t is TargetInfo::getInt64Type().  
> Not sure if you need that here.
I realised `ASTContext::getIntTypeForBitwidth` handles this and noticed 
`getBuiltinVectorTypeInfo` which Sander recently added makes use of it so I've 
updated it to use that instead for all types except predicates since we still 
need to represent them as i8.


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

https://reviews.llvm.org/D87358

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


[PATCH] D87358: [clang][aarch64] Fix ILP32 ABI for arm_sve_vector_bits

2020-09-10 Thread Cullen Rhodes via Phabricator via cfe-commits
c-rhodes updated this revision to Diff 290974.
c-rhodes edited the summary of this revision.
c-rhodes added a comment.

- Get the element type of scalable vectors from `getBuiltinVectorTypeInfo` when 
creating VLS types. This fixes the ABI issue since it calls 
`ASTContext::getIntTypeForBitwidth` which gets the correct type for a given 
target.
- Element type for `svfloat16_t` is changed from `Float16Ty` to `HalfTy` for 
VLS types since this is what’s used elsewhere.


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

https://reviews.llvm.org/D87358

Files:
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/Type.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/attr-arm-sve-vector-bits-types.c


Index: clang/test/CodeGen/attr-arm-sve-vector-bits-types.c
===
--- clang/test/CodeGen/attr-arm-sve-vector-bits-types.c
+++ clang/test/CodeGen/attr-arm-sve-vector-bits-types.c
@@ -4,6 +4,7 @@
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve 
-target-feature +bf16 -msve-vector-bits=512 -fallow-half-arguments-and-returns 
-S -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-512
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve 
-target-feature +bf16 -msve-vector-bits=1024 -fallow-half-arguments-and-returns 
-S -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-1024
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve 
-target-feature +bf16 -msve-vector-bits=2048 -fallow-half-arguments-and-returns 
-S -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-2048
+// RUN: %clang_cc1 -triple aarch64_32-unknown-darwin -target-feature +sve 
-target-feature +bf16 -msve-vector-bits=512 -fallow-half-arguments-and-returns 
-S -emit-llvm -o - %s | FileCheck %s --check-prefix=CHECK-ILP32
 
 #include 
 
@@ -579,3 +580,11 @@
 // CHECK-2048-NEXT:  %local_arr_f64 = alloca [3 x <32 x double>], align 16
 // CHECK-2048-NEXT:  %local_arr_bf16 = alloca [3 x <128 x bfloat>], align 16
 // CHECK-2048-NEXT:  %local_arr_bool = alloca [3 x <32 x i8>], align 2
+
+//===--===//
+// ILP32 ABI
+//===--===//
+// CHECK-ILP32: @global_i32 = global <16 x i32> zeroinitializer, align 16
+// CHECK-ILP32: @global_i64 = global <8 x i64> zeroinitializer, align 16
+// CHECK-ILP32: @global_u32 = global <16 x i32> zeroinitializer, align 16
+// CHECK-ILP32: @global_u64 = global <8 x i64> zeroinitializer, align 16
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -5627,7 +5627,7 @@
   ResType = llvm::ScalableVectorType::get(
   llvm::Type::getInt64Ty(getVMContext()), 2);
   break;
-case BuiltinType::Float16:
+case BuiltinType::Half:
   ResType = llvm::ScalableVectorType::get(
   llvm::Type::getHalfTy(getVMContext()), 8);
   break;
Index: clang/lib/AST/Type.cpp
===
--- clang/lib/AST/Type.cpp
+++ clang/lib/AST/Type.cpp
@@ -2317,38 +2317,13 @@
   assert(isVLSTBuiltinType() && "unsupported type!");
 
   const BuiltinType *BTy = getAs();
-  switch (BTy->getKind()) {
-  default:
-llvm_unreachable("Unknown builtin SVE type!");
-  case BuiltinType::SveInt8:
-return Ctx.SignedCharTy;
-  case BuiltinType::SveUint8:
-  case BuiltinType::SveBool:
+  if (BTy->getKind() == BuiltinType::SveBool)
 // Represent predicates as i8 rather than i1 to avoid any layout issues.
 // The type is bitcasted to a scalable predicate type when casting between
 // scalable and fixed-length vectors.
-return Ctx.UnsignedCharTy;
-  case BuiltinType::SveInt16:
-return Ctx.ShortTy;
-  case BuiltinType::SveUint16:
-return Ctx.UnsignedShortTy;
-  case BuiltinType::SveInt32:
-return Ctx.IntTy;
-  case BuiltinType::SveUint32:
-return Ctx.UnsignedIntTy;
-  case BuiltinType::SveInt64:
-return Ctx.LongTy;
-  case BuiltinType::SveUint64:
-return Ctx.UnsignedLongTy;
-  case BuiltinType::SveFloat16:
-return Ctx.Float16Ty;
-  case BuiltinType::SveBFloat16:
-return Ctx.BFloat16Ty;
-  case BuiltinType::SveFloat32:
-return Ctx.FloatTy;
-  case BuiltinType::SveFloat64:
-return Ctx.DoubleTy;
-  }
+return Ctx.getIntTypeForBitwidth(8, /*Signed=*/0);
+  else
+return Ctx.getBuiltinVectorTypeInfo(BTy).ElementType;
 }
 
 bool QualType::isPODType(const ASTContext ) const {
Index: clang/lib/AST/ItaniumMangle.cpp
===
--- clang/lib/AST/ItaniumMangle.cpp
+++ clang/lib/AST/ItaniumMangle.cpp
@@ -3388,7 +3388,7 @@
   case BuiltinType::ULong:
 TypeName = "__SVUint64_t";
 break;
-  case BuiltinType::Float16:
+  case BuiltinType::Half:
 TypeName = 

[clang-tools-extra] 33c9dbb - Add an explicit toggle for the static analyzer in clang-tidy

2020-09-10 Thread Nico Weber via cfe-commits

Author: Nico Weber
Date: 2020-09-10T10:48:17-04:00
New Revision: 33c9dbbd380913e8ab7e5a8e82468f9f7d092187

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

LOG: Add an explicit toggle for the static analyzer in clang-tidy

Instead of using CLANG_ENABLE_STATIC_ANALYZER for use of the
static analyzer in both clang and clang-tidy, add a second
toggle CLANG_TIDY_ENABLE_STATIC_ANALYZER.

This allows enabling the static analyzer in clang-tidy while
disabling it in clang.

Differential Revison: https://reviews.llvm.org/D87118

Added: 
clang-tools-extra/clang-tidy/clang-tidy-config.h.cmake
llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/enable.gni

Modified: 
clang-tools-extra/CMakeLists.txt
clang-tools-extra/clang-tidy/CMakeLists.txt
clang-tools-extra/clang-tidy/ClangTidy.cpp
clang-tools-extra/clang-tidy/ClangTidyForceLinker.h
clang-tools-extra/docs/clang-tidy/Contributing.rst
clang-tools-extra/test/CMakeLists.txt
clang-tools-extra/test/lit.cfg.py
clang-tools-extra/test/lit.site.cfg.py.in
clang/CMakeLists.txt
clang/cmake/caches/Android.cmake
clang/lib/CMakeLists.txt
llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/BUILD.gn
llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/tool/BUILD.gn
llvm/utils/gn/secondary/clang-tools-extra/test/BUILD.gn

Removed: 




diff  --git a/clang-tools-extra/CMakeLists.txt 
b/clang-tools-extra/CMakeLists.txt
index 57bb97057560..2e73b6ba81d2 100644
--- a/clang-tools-extra/CMakeLists.txt
+++ b/clang-tools-extra/CMakeLists.txt
@@ -1,5 +1,8 @@
 include(CMakeDependentOption)
 
+option(CLANG_TIDY_ENABLE_STATIC_ANALYZER
+  "Include static analyzer checks in clang-tidy" ON)
+
 add_subdirectory(clang-apply-replacements)
 add_subdirectory(clang-reorder-fields)
 add_subdirectory(modularize)

diff  --git a/clang-tools-extra/clang-tidy/CMakeLists.txt 
b/clang-tools-extra/clang-tidy/CMakeLists.txt
index 923976197ebe..ca7a5afed6b0 100644
--- a/clang-tools-extra/clang-tidy/CMakeLists.txt
+++ b/clang-tools-extra/clang-tidy/CMakeLists.txt
@@ -3,6 +3,11 @@ set(LLVM_LINK_COMPONENTS
   Support
   )
 
+configure_file(
+  ${CMAKE_CURRENT_SOURCE_DIR}/clang-tidy-config.h.cmake
+  ${CMAKE_CURRENT_BINARY_DIR}/clang-tidy-config.h)
+include_directories(BEFORE ${CMAKE_CURRENT_BINARY_DIR})
+
 add_clang_library(clangTidy
   ClangTidy.cpp
   ClangTidyCheck.cpp
@@ -34,7 +39,7 @@ clang_target_link_libraries(clangTidy
   clangToolingCore
   )
 
-if(CLANG_ENABLE_STATIC_ANALYZER)
+if(CLANG_TIDY_ENABLE_STATIC_ANALYZER)
   clang_target_link_libraries(clangTidy
 PRIVATE
 clangStaticAnalyzerCore
@@ -60,7 +65,7 @@ add_subdirectory(llvm)
 add_subdirectory(llvmlibc)
 add_subdirectory(misc)
 add_subdirectory(modernize)
-if(CLANG_ENABLE_STATIC_ANALYZER)
+if(CLANG_TIDY_ENABLE_STATIC_ANALYZER)
   add_subdirectory(mpi)
 endif()
 add_subdirectory(objc)
@@ -93,7 +98,7 @@ set(ALL_CLANG_TIDY_CHECKS
   clangTidyReadabilityModule
   clangTidyZirconModule
   )
-if(CLANG_ENABLE_STATIC_ANALYZER)
+if(CLANG_TIDY_ENABLE_STATIC_ANALYZER)
   list(APPEND ALL_CLANG_TIDY_CHECKS clangTidyMPIModule)
 endif()
 set(ALL_CLANG_TIDY_CHECKS ${ALL_CLANG_TIDY_CHECKS} PARENT_SCOPE)

diff  --git a/clang-tools-extra/clang-tidy/ClangTidy.cpp 
b/clang-tools-extra/clang-tidy/ClangTidy.cpp
index 90b39347bc9a..1f94ab4977c2 100644
--- a/clang-tools-extra/clang-tidy/ClangTidy.cpp
+++ b/clang-tools-extra/clang-tidy/ClangTidy.cpp
@@ -20,11 +20,11 @@
 #include "ClangTidyModuleRegistry.h"
 #include "ClangTidyProfiling.h"
 #include "ExpandModularHeadersPPCallbacks.h"
+#include "clang-tidy-config.h"
 #include "clang/AST/ASTConsumer.h"
 #include "clang/AST/ASTContext.h"
 #include "clang/AST/Decl.h"
 #include "clang/ASTMatchers/ASTMatchFinder.h"
-#include "clang/Config/config.h"
 #include "clang/Format/Format.h"
 #include "clang/Frontend/ASTConsumers.h"
 #include "clang/Frontend/CompilerInstance.h"
@@ -47,10 +47,10 @@
 #include 
 #include 
 
-#if CLANG_ENABLE_STATIC_ANALYZER
+#if CLANG_TIDY_ENABLE_STATIC_ANALYZER
 #include "clang/Analysis/PathDiagnostic.h"
 #include "clang/StaticAnalyzer/Frontend/AnalysisConsumer.h"
-#endif // CLANG_ENABLE_STATIC_ANALYZER
+#endif // CLANG_TIDY_ENABLE_STATIC_ANALYZER
 
 using namespace clang::ast_matchers;
 using namespace clang::driver;
@@ -63,7 +63,7 @@ namespace clang {
 namespace tidy {
 
 namespace {
-#if CLANG_ENABLE_STATIC_ANALYZER
+#if CLANG_TIDY_ENABLE_STATIC_ANALYZER
 static const char *AnalyzerCheckNamePrefix = "clang-analyzer-";
 
 class AnalyzerDiagnosticConsumer : public ento::PathDiagnosticConsumer {
@@ -95,7 +95,7 @@ class AnalyzerDiagnosticConsumer : public 
ento::PathDiagnosticConsumer {
 private:
   ClangTidyContext 
 };
-#endif // CLANG_ENABLE_STATIC_ANALYZER
+#endif // CLANG_TIDY_ENABLE_STATIC_ANALYZER
 
 class 

[PATCH] D86819: [PowerPC][Power10] Implementation of 128-bit Binary Vector Rotate builtins

2020-09-10 Thread Nemanja Ivanovic via Phabricator via cfe-commits
nemanjai added inline comments.



Comment at: clang/lib/Headers/altivec.h:7743
+  return __builtin_altivec_vrlqnm(__a, ((__c << ShiftMask) |
+(__b << ShiftRotation)));
+}

While correct, this implementation will require two constant pool loads (for 
the two shift amounts), then two `vrlq`'s to shift the two vectors and finally 
an `xxlor` to OR them together. We should be able to do this with a single 
constant pool load and `vperm`.
Presumably the implementation would be something like:
```
  // Merge __b and __c using an appropriate shuffle.
  vector unsigned char TmpB = (vector unsigned char)__b;
  vector unsigned char TmpC = (vector unsigned char)__c;
  vector unsigned char MaskAndShift =
#ifdef __LITTLE_ENDIAN__
  __builtin_shufflevector(TmpB, TmpC, -1, -1, -1, -1, -1, -1, -1, -1, 16, 1,
  0, -1, -1, -1, -1, -1);
#else
  __builtin_shufflevector(TmpB, TmpC, -1, -1, -1, -1, -1, 30, 31, 15, -1,
  -1, -1, -1, -1, -1, -1, -1);
#endif
  return __builtin_altivec_vrlqnm(__a, MaskAndShift);
```
(but of course, double-check that the numbers are correct).



Comment at: clang/test/CodeGen/builtins-ppc-p10vector.c:996
+  // CHECK-COMMON-LABEL: @test_vec_rlnm_s128(
+  // CHECK-COMMON: call <1 x i128> @llvm.ppc.altivec.vrlqnm(<1 x i128>
+  // CHECK-COMMON-NEXT: ret <1 x i128>

Please show the shift in the test case as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86819

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


[PATCH] D71199: [clang-tidy] New check cppcoreguidelines-prefer-member-initializer

2020-09-10 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D71199#2265693 , @lebedev.ri wrote:

> In D71199#2265692 , 
> @baloghadamsoftware wrote:
>
>> In D71199#2265594 , @lebedev.ri 
>> wrote:
>>
>>> So i've just reverted this in rGebf496d805521b53022a351f35854de977fee844 
>>> .
>>>
>>> @aaron.ballman @baloghadamsoftware how's QC going on nowadays here?
>>> Was this evaluated on anything other than it's tests?
>>
>> Surely. After I commit a patch, lots of buildbots verify it. They passed so 
>> far.
>
> @baloghadamsoftware, i think you understand that wasn't the question.

This feedback is a bit terse and not very constructive. FWIW, we don't 
typically ask patch authors to run their patch over a large corpus of code 
unless a reviewer expects there to be a performance concern and asks 
explicitly. Given that this checks constructor bodies, there was no obvious 
reason to ask for that here. Also, I can't recall a time when we expected a 
patch reviewer to do that work. I appreciate that you noticed an issue and 
reverted so we could investigate, but when reporting an issue like this, please 
try to keep in mind that we're all in the same community trying to make a great 
product.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71199

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


[PATCH] D85424: [Analyzer] Crash fix for alpha.cplusplus.IteratorRange

2020-09-10 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware added a comment.

In D85424#2258886 , @steakhal wrote:

> void foo(int x) {
>
>   int uninit;
>   x - uninit; // will-crash
>
> }

This is not even related to the iterators. We could check first whether `LHS` 
is an iterator and early exit if not. However, that does not help, the checker 
crashes if we try to add or subtract an unitialized value to/from an iterator.


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

https://reviews.llvm.org/D85424

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


[PATCH] D85424: [Analyzer] Crash fix for alpha.cplusplus.IteratorRange

2020-09-10 Thread Balogh , Ádám via Phabricator via cfe-commits
baloghadamsoftware updated this revision to Diff 290967.
baloghadamsoftware added a comment.

Test added. Thank you for the test @steakhal!


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

https://reviews.llvm.org/D85424

Files:
  clang/lib/StaticAnalyzer/Checkers/IteratorRangeChecker.cpp
  clang/test/Analysis/iterator-range.cpp


Index: clang/test/Analysis/iterator-range.cpp
===
--- clang/test/Analysis/iterator-range.cpp
+++ clang/test/Analysis/iterator-range.cpp
@@ -939,3 +939,9 @@
   auto i0 = c.begin(), i1 = c.end();
   ptrdiff_t len = i1 - i0; // no-crash
 }
+
+int uninit_var(int n) {
+  int uninit; // expected-note{{'uninit' declared without an initial value}}
+  return n - uninit; // expected-warning{{The right operand of '-' is a 
garbage value}}
+ // expected-note@-1{{The right operand of '-' is a 
garbage value}}
+}
Index: clang/lib/StaticAnalyzer/Checkers/IteratorRangeChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/IteratorRangeChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/IteratorRangeChecker.cpp
@@ -228,7 +228,8 @@
 Value = State->getRawSVal(*ValAsLoc);
   }
 
-  if (Value.isUnknown())
+  if (Value.isUnknownOrUndef())
+//  if (Value.isUnknownOrUndef())
 return;
 
   // Incremention or decremention by 0 is never a bug.


Index: clang/test/Analysis/iterator-range.cpp
===
--- clang/test/Analysis/iterator-range.cpp
+++ clang/test/Analysis/iterator-range.cpp
@@ -939,3 +939,9 @@
   auto i0 = c.begin(), i1 = c.end();
   ptrdiff_t len = i1 - i0; // no-crash
 }
+
+int uninit_var(int n) {
+  int uninit; // expected-note{{'uninit' declared without an initial value}}
+  return n - uninit; // expected-warning{{The right operand of '-' is a garbage value}}
+ // expected-note@-1{{The right operand of '-' is a garbage value}}
+}
Index: clang/lib/StaticAnalyzer/Checkers/IteratorRangeChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/IteratorRangeChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/IteratorRangeChecker.cpp
@@ -228,7 +228,8 @@
 Value = State->getRawSVal(*ValAsLoc);
   }
 
-  if (Value.isUnknown())
+  if (Value.isUnknownOrUndef())
+//  if (Value.isUnknownOrUndef())
 return;
 
   // Incremention or decremention by 0 is never a bug.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


  1   2   >