[PATCH] D78655: [HIP] Let lambda be host device by default

[Michael Liao via Phabricator via cfe-commits]

hliao added a comment.

In D78655#2003837 , @yaxunl wrote:

> In D78655#2003681 , @hliao wrote:
>
> > I though the goal of adding HD/D attributes for lambda is to make the 
> > static check easier as lambda used in device code or device lambda is 
> > sensitive to captures. Invalid capture may render error accidentally 
> > without static check, says we capture host variable reference in a device 
> > lambda. That makes the final code invalid. Allowing regular lambda to be 
> > used in global or device function is considering harmful.
>
>
> Inferring a lambda function by default as `__host__ __device__` does not mean 
> skipping the check for harmful captures.
>
> If we add such checks, it does not matter whether the `__host__ __device__` 
> attribute is explicit or implicit, they go through the same check.
>
> How to infer the device/host-ness of a lambda function is a usability issue. 
> It is orthogonal to the issue of missing diagnostics about captures.
>
> Forcing users to explicitly mark a lambda function as `__device__ __host__` 
> itself does not help diagnose the harmful captures if such diags do not exist.
>
> Let's think about a lambda function which captures references to host 
> variables. If it is only used in host code, as in ordinary C++ host code. 
> Marking it `host device` implicitly does not change anything, since it is not 
> emitted in device code. If it is used in device code, it will likely cause 
> mem fault at run time since currently we do not diagnose it. Does it help if 
> we force users to mark it `__device__ __host__`? I don't think so. Users will 
> just reluctantly add `__device__ __host__` to it and they still end up as mem 
> fault. If we add the diagnostic about the harmful captures, it does not 
> matter whether the `__device__ __host__` attribute is explicit or implicit, 
> users get the same diagnostic about harmful captures. So the effect is the 
> same. However, usability is improved if users do not need to add `__device__ 
> __host__` by themselves.
>
> Does inferring lambda function as `__device__ __host__` by default making the 
> diagnostic about harmful captures more difficult? No. It should be the same 
> for lambdas with explicit `__device__ __host__`. This needs to be a deferred 
> diagnostic like those we already did, which are only emitted if the function 
> is really emitted. It does not matter whether the device/host attrs are 
> implicit or explicit.


Not only the capture is an issue, like a regular function, lambda could also 
access non-local variables/functions. Without marking proper HD attributes 
explicitly, it's difficult or expensive to statically check the use of them. If 
we have to guess that attributes based on how they are called, we may find 
cases where conflicting results may be derived depending on call sites. It 
would be quite confusing if developers struggle to solve one but trigger 
another one or more. From the other perspective, a lambda is just another 
function and should have consistent rule for its usage, resolution, and etc.


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

https://reviews.llvm.org/D78655



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

[PATCH] D78655: [HIP] Let lambda be host device by default

[Michael Liao via Phabricator via cfe-commits]

hliao added a comment.

In D78655#2011823 , @pfultz2 wrote:

> > says we capture host variable reference in a device lambda.
>
> Is that required to be an error? I know @AlexVlx added support to hcc at one 
> point to capture host variables by reference. So it seems to be possible for 
> it to work correctly. So it doesn't seem to be like reason enough to disallow 
> implicit HD.


Do we have a mechanism to allow device code to access the local auto variable 
on the host side?


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

https://reviews.llvm.org/D78655



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

[PATCH] D78655: [HIP] Let lambda be host device by default

[Paul Fultz II via Phabricator via cfe-commits]

pfultz2 added a subscriber: AlexVlx.
pfultz2 added a comment.

> says we capture host variable reference in a device lambda.

Is that required to be an error? I know @AlexVlx added support to hcc at one 
point to capture host variables by reference. So it seems to be possible for it 
to work correctly. So it doesn't seem to be like reason enough to disallow 
implicit HD.


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

https://reviews.llvm.org/D78655



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

[PATCH] D78694: [clang-format] Fix lambda with ellipsis in return type

[Pochang Chen via Phabricator via cfe-commits]

johnchen902 added a comment.

Well... I don't know how to land this. I guess I don't have commit access 
anyway.


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

https://reviews.llvm.org/D78694



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

[PATCH] D77168: Add a flag to debug automatic variable initialization

[JF Bastien via Phabricator via cfe-commits]

jfb added a comment.

I think you want to emit a diagnostic any time auto-init doesn't happen because 
of this new flag. With the code simplification I propose, it would be pretty 
hard to introduce a regression... and it someone does it wouldn't be a silent 
one :)




Comment at: clang/lib/CodeGen/CGBuiltin.cpp:84
+CGF.CGM.countAutoVarInit();
+  }
   CGF.Builder.CreateMemSet(AI, Byte, Size, AlignmentInBytes);

I think this logic is about right, but it seems like something you'd want to 
use as a two-liner instead. Maybe something like:

```
if (autoInitStopCounter())
  return;
```

This would check the value is set, check its value against the counter, and 
increment the counter.



Comment at: clang/lib/CodeGen/CGDecl.cpp:1817
+  CGM.countAutoVarInit();
+}
+

This isn't the right place to stop auto-init: we can get past this point even 
without auto-init. As-is you're introducing a change in the regular language.

I hope that some tests for whatever happens below would break if you hack your 
flag to always stop auto-init for any value. i.e. just on your machine, run the 
entire test suite with this forcibly on. Only auto-init tests should fail, the 
others should all still pass.



Comment at: clang/lib/CodeGen/CodeGenModule.h:305
   const CodeGenOptions 
+  mutable unsigned NumAutoVarInit = 0;
   llvm::Module 

This is reachable from a context where `CodeGenModule` is `const` ? :( 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77168



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

Buildbot numbers for the last week of 04/19/2020 - 04/25/2020

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the last week of 04/19/2020 -
04/25/2020.

Please see the same data in attached csv files:

The longest time each builder was red during the week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the week:
  buildername  | was_red
---+-
 clang-cmake-armv7-full| 99:37:22
 clang-cmake-aarch64-lld   | 57:26:11
 sanitizer-x86_64-linux-autoconf   | 50:17:09
 clang-cmake-thumbv7-full-sh   | 49:27:32
 llvm-clang-x86_64-expensive-checks-win| 45:14:00
 clang-cmake-aarch64-full  | 41:45:55
 clang-cmake-armv7-global-isel | 37:27:21
 clang-cmake-armv8-lld | 35:49:15
 clang-ppc64le-linux-lnt   | 34:55:01
 clang-cmake-aarch64-global-isel   | 34:44:17
 clang-cmake-aarch64-quick | 34:34:40
 clang-cmake-x86_64-avx2-linux | 34:33:18
 clang-cmake-armv7-lnt | 34:28:12
 clang-cmake-x86_64-sde-avx512-linux   | 33:52:55
 llvm-clang-win-x-armv7l   | 25:32:19
 ppc64le-lld-multistage-test   | 23:41:31
 clang-ppc64le-linux   | 22:06:08
 lldb-aarch64-ubuntu   | 21:58:46
 clang-s390x-linux-lnt | 20:54:54
 clang-s390x-linux | 18:56:21
 clang-ppc64le-rhel| 17:51:10
 clang-ppc64be-linux-multistage| 17:46:29
 clang-ppc64be-linux-lnt   | 17:40:02
 clang-ppc64be-linux   | 17:14:40
 clang-with-lto-ubuntu | 15:35:36
 clang-with-thin-lto-ubuntu| 15:34:36
 fuchsia-x86_64-linux  | 13:48:34
 llvm-avr-linux| 13:16:04
 clang-x86_64-linux-abi-test   | 11:40:19
 clang-ppc64le-linux-multistage| 11:28:22
 libc-x86_64-debian| 08:16:35
 sanitizer-x86_64-linux-bootstrap-msan | 07:12:57
 llvm-clang-x86_64-win-fast| 06:49:28
 clang-x64-windows-msvc| 06:32:59
 mlir-nvidia   | 06:14:06
 clang-cmake-armv7-selfhost-neon   | 05:40:42
 llvm-clang-win-x-aarch64  | 05:22:19
 sanitizer-ppc64le-linux   | 05:16:59
 lld-x86_64-win| 04:11:31
 sanitizer-ppc64be-linux   | 04:09:20
 clang-s390x-linux-multistage  | 04:05:31
 aosp-O3-polly-before-vectorizer-unprofitable  | 03:56:37
 sanitizer-x86_64-linux| 03:54:33
 lld-x86_64-ubuntu-fast| 03:47:07
 sanitizer-x86_64-linux-bootstrap  | 03:35:21
 lldb-x64-windows-ninja| 03:35:12
 sanitizer-x86_64-linux-fast   | 03:33:47
 libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions | 03:29:41
 libcxx-libcxxabi-libunwind-armv8-linux| 03:25:02
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast  | 03:21:33
 lld-x86_64-freebsd| 03:12:00
 clang-cmake-armv7-quick   | 03:06:57
 polly-x86_64-linux| 02:55:21
 sanitizer-x86_64-linux-bootstrap-ubsan| 02:54:31
 sanitizer-windows | 02:51:19
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast| 02:42:51
 llvm-clang-x86_64-expensive-checks-debian | 02:39:07
 clang-x86_64-debian-new-pass-manager-fast | 02:36:34
 clang-x86_64-debian-fast  | 02:35:32
 llvm-clang-x86_64-expensive-checks-ubuntu | 02:30:04
 lldb-x86_64-debian| 01:50:36
 polly-arm-linux   | 01:48:19
 clang-hexagon-elf | 01:47:04
 clang-cmake-armv7-selfhost| 01:31:06
 

Buildbot numbers for the last week of 04/12/2020 - 04/18/2020

[Galina Kistanova via cfe-commits]

Hello everyone,

Below are some buildbot numbers for the last week of 04/12/2020 -
04/18/2020.

Please see the same data in attached csv files:

The longest time each builder was red during the week;
"Status change ratio" by active builder (percent of builds that changed the
builder status from greed to red or from red to green);
Count of commits by project;
Number of completed builds, failed builds and average build time for
successful builds per active builder;
Average waiting time for a revision to get build result per active builder
(response time).

Thanks

Galina


The longest time each builder was red during the week:
   buildername   | was_red
-+-
 llvm-sphinx-docs| 51:47:32
 lldb-aarch64-ubuntu | 48:54:21
 lldb-x64-windows-ninja  | 15:02:13
 lldb-x86_64-debian  | 14:59:53
 clang-cmake-thumbv7-full-sh | 11:44:43
 sanitizer-ppc64be-linux | 10:44:44
 clang-ppc64le-linux-multistage  | 09:32:56
 mlir-nvidia | 08:37:40
 clang-cmake-armv7-selfhost-neon | 07:52:16
 sanitizer-x86_64-linux-fast | 06:58:48
 clang-s390x-linux-multistage| 06:53:21
 clang-ppc64le-rhel  | 06:50:53
 libc-x86_64-debian  | 06:40:56
 sanitizer-x86_64-linux-bootstrap| 06:19:30
 mlir-windows| 06:05:51
 clang-with-lto-ubuntu   | 05:44:11
 clang-ppc64be-linux-lnt | 05:39:00
 clang-ppc64be-linux | 05:38:21
 clang-s390x-linux-lnt   | 05:29:18
 clang-ppc64le-linux | 05:22:16
 clang-s390x-linux   | 05:20:34
 sanitizer-ppc64le-linux | 05:09:12
 clang-ppc64be-linux-multistage  | 05:08:24
 clang-x64-windows-msvc  | 05:08:20
 clang-cmake-aarch64-lld | 04:46:31
 clang-ppc64le-linux-lnt | 04:42:52
 llvm-clang-lld-x86_64-scei-ps4-windows10pro-fast| 03:34:04
 ppc64le-lld-multistage-test | 03:20:31
 clang-with-thin-lto-ubuntu  | 03:16:56
 sanitizer-x86_64-linux-autoconf | 03:15:15
 aosp-O3-polly-before-vectorizer-unprofitable| 03:11:16
 sanitizer-x86_64-linux-bootstrap-msan   | 03:05:03
 clang-cmake-aarch64-full| 03:00:21
 llvm-avr-linux  | 02:52:05
 sanitizer-x86_64-linux  | 02:42:17
 clang-cmake-aarch64-global-isel | 02:38:20
 sanitizer-x86_64-linux-bootstrap-ubsan  | 02:21:30
 clang-cmake-armv7-lnt   | 02:21:10
 clang-hexagon-elf   | 02:19:26
 openmp-clang-x86_64-linux-debian| 02:17:21
 clang-cmake-x86_64-avx2-linux   | 01:51:04
 libcxx-libcxxabi-singlethreaded-x86_64-linux-debian | 01:32:11
 sanitizer-x86_64-linux-fuzzer   | 01:29:37
 lld-x86_64-win  | 01:25:01
 clang-cmake-armv8-lld   | 01:22:55
 sanitizer-windows   | 01:19:13
 llvm-clang-win-x-aarch64| 01:16:28
 fuchsia-x86_64-linux| 01:15:06
 polly-arm-linux | 01:14:31
 llvm-clang-lld-x86_64-scei-ps4-ubuntu-fast  | 01:12:07
 lld-x86_64-ubuntu-fast  | 01:11:41
 clang-x86_64-debian-fast| 01:10:03
 llvm-clang-x86_64-expensive-checks-debian   | 01:09:53
 clang-x86_64-debian-new-pass-manager-fast   | 01:09:52
 libcxx-libcxxabi-x86_64-linux-ubuntu-cxx03  | 01:06:46
 llvm-clang-x86_64-expensive-checks-ubuntu   | 01:06:12
 libcxx-libcxxabi-x86_64-linux-ubuntu-msan   | 01:05:56
 clang-x86_64-linux-abi-test | 01:04:42
 clang-cmake-armv7-quick | 01:04:10
 libcxx-libcxxabi-x86_64-linux-ubuntu-ubsan  | 01:01:49
 clang-cmake-x86_64-sde-avx512-linux | 01:00:04
 llvm-clang-win-x-armv7l | 00:59:48
 

[PATCH] D79094: [SemaObjC] Warn on visibility attributes on an @implementation

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak added a comment.

This seems fine to me unless there are cases where the user wants to use it on 
the implementation. I can't think of a case where that is needed.


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

https://reviews.llvm.org/D79094



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

[PATCH] D79094: [SemaObjC] Warn on visibility attributes on an @implementation

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak added a comment.

What if someone wants to use the attribute on either the interface or the 
implementation but can't modify the header?


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

https://reviews.llvm.org/D79094



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

[PATCH] D77221: [AVR] Rework MCU family detection to support more AVR MCUs

[Ayke via Phabricator via cfe-commits]

aykevl added a comment.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

A thought: should the AVR family be included in the target triple? Like 
`avr5-unknown-unknown` (similar to `armv6m-none-eabi`, `armv7m-none-eabi`, etc).
The different variations do sometimes change the architecture in incompatible 
ways, such as with the call instruction 

 which pushes a return address of two or three bytes depending on the 
architecture variant (and thus makes it impossible to pass parameters on the 
stack reliably).

I don't think this should block this patch (which I hope will get updated so it 
can land soon), but it may be something to consider.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77221



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

[PATCH] D79014: [clangd] Move non-clang base pieces into separate support/ lib.

[Kirill Bobyrev via Phabricator via cfe-commits]

kbobyrev added a comment.

In D79014#2011034 , @sammccall wrote:

> I think there's more, just running a local shared build so I can catch them 
> (I should really have done this ahead of time).


Ah, I've done that (since I primarily build in the shared mode, though I 
temporarily switched to static to resolve recent shared index issues) but 
didn't only built some of the targets, should've done all of them; my bad too, 
sorry.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79014



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

[PATCH] D78979: OpenCL: Include builtin header by default

[Jan Vesely via Phabricator via cfe-commits]

jvesely added a comment.

In D78979#2006901 , @yaxunl wrote:

> In D78979#2006847 , @arsenm wrote:
>
> > I'm also wondering if using -nogpulib for the corresponding linker purpose 
> > was correct, since in the OpenCL case it's not really an offload target. 
> > Maybe this should switch to -nostdlib?
>
>
> -nogpulib is fine since opencl compiler is in parallel with the device 
> compiler of CUDA/HIP. The library it uses is the device library.


OpenCL can target other devices than GPUs, including CPUs and FPGAs, referring 
to gpulibs wrt opencl is a misnomer.

It would be nice to have some clarity as to how OpenCL is handled wrt clang 
frontend vs. clang driver.
OpenCL options are currently split between the two (e.g. cl-denorms-are-zero is 
only available in the driver and not the frontend)
There are 3 implementations of CL headers, two in clang which might or might 
not be included by default, and the 3rd one in libclc.


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

https://reviews.llvm.org/D78979



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

[PATCH] D79147: [WIP] Merge -debug-info-kind=constructor into -debug-info-kind=limited

[Amy Huang via Phabricator via cfe-commits]

akhuang created this revision.
Herald added subscribers: lldb-commits, cfe-commits, aprantl.
Herald added projects: clang, LLDB.

There will be an RFC for this in cfe-dev.
This reduces the amount of class debug info emitted in Limited debug info mode.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79147

Files:
  clang/include/clang/Basic/CodeGenOptions.h
  clang/include/clang/Basic/DebugInfoOptions.h
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
  clang/test/CodeGenCXX/debug-lambda-this.cpp
  lldb/test/Shell/SymbolFile/PDB/Inputs/ClassLayoutTest.cpp

Index: lldb/test/Shell/SymbolFile/PDB/Inputs/ClassLayoutTest.cpp
===
--- lldb/test/Shell/SymbolFile/PDB/Inputs/ClassLayoutTest.cpp
+++ lldb/test/Shell/SymbolFile/PDB/Inputs/ClassLayoutTest.cpp
@@ -106,6 +106,7 @@
 int main() {
   MemberTest::Base B1;
   B1.Get();
+  MemberTest::Class C1;
   MemberTest::Class::StaticMemberFunc(1, 10, 2);
   return 0;
 }
Index: clang/test/CodeGenCXX/debug-lambda-this.cpp
===
--- clang/test/CodeGenCXX/debug-lambda-this.cpp
+++ clang/test/CodeGenCXX/debug-lambda-this.cpp
@@ -1,8 +1,6 @@
 // RUN: %clang_cc1 -triple x86_64-apple-darwin10.0.0 -emit-llvm -o - %s -fexceptions -std=c++11 -debug-info-kind=limited | FileCheck %s
 
 struct D {
-  D();
-  D(const D&);
   int x;
   int d(int x);
 };
@@ -15,7 +13,7 @@
 // CHECK: ![[D:[0-9]+]] = distinct !DICompositeType(tag: DW_TAG_structure_type, name: "D",
 // CHECK: ![[POINTER:.*]] = !DIDerivedType(tag: DW_TAG_pointer_type, baseType: ![[D]], size: 64)
 // CHECK: !DIDerivedType(tag: DW_TAG_member, name: "this",
-// CHECK-SAME:   line: 11
+// CHECK-SAME:   line: 9
 // CHECK-SAME:   baseType: ![[POINTER]]
 // CHECK-SAME:   size: 64
 // CHECK-NOT:offset: 0
Index: clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
===
--- clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
+++ clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang -cc1 -debug-info-kind=constructor -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang -cc1 -debug-info-kind=limited -emit-llvm %s -o - | FileCheck %s
 
 // CHECK-DAG: !DICompositeType(tag: DW_TAG_structure_type, name: "A"{{.*}}DIFlagTypePassByValue
 struct A {
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -727,7 +727,6 @@
 llvm::StringSwitch(A->getValue())
 .Case("line-tables-only", codegenoptions::DebugLineTablesOnly)
 .Case("line-directives-only", codegenoptions::DebugDirectivesOnly)
-.Case("constructor", codegenoptions::DebugInfoConstructor)
 .Case("limited", codegenoptions::LimitedDebugInfo)
 .Case("standalone", codegenoptions::FullDebugInfo)
 .Default(~0U);
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -1004,9 +1004,6 @@
   case codegenoptions::DebugLineTablesOnly:
 CmdArgs.push_back("-debug-info-kind=line-tables-only");
 break;
-  case codegenoptions::DebugInfoConstructor:
-CmdArgs.push_back("-debug-info-kind=constructor");
-break;
   case codegenoptions::LimitedDebugInfo:
 CmdArgs.push_back("-debug-info-kind=limited");
 break;
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -592,7 +592,6 @@
   case codegenoptions::DebugDirectivesOnly:
 EmissionKind = llvm::DICompileUnit::DebugDirectivesOnly;
 break;
-  case codegenoptions::DebugInfoConstructor:
   case codegenoptions::LimitedDebugInfo:
   case codegenoptions::FullDebugInfo:
 EmissionKind = llvm::DICompileUnit::FullDebug;
@@ -1689,9 +1688,8 @@
   if (CGM.getLangOpts().Optimize)
 SPFlags |= llvm::DISubprogram::SPFlagOptimized;
 
-  // In this debug mode, emit type info for a class when its constructor type
-  // info is emitted.
-  if (DebugKind == codegenoptions::DebugInfoConstructor)
+  // Emit class type info when its constructor is emitted.
+  if (DebugKind == codegenoptions::LimitedDebugInfo)
 if (const CXXConstructorDecl *CD = dyn_cast(Method))
   completeClass(CD->getParent());
 
@@ -2280,10 +2278,10 @@
   !isClassOrMethodDLLImport(CXXDecl))
 return true;
 
-  // In constructor debug mode, only emit debug info for a class when its
-  // constructor is emitted. Skip this optimization if the class or any of
-  // its methods 

[PATCH] D79142: [clangd] Render doc-comment code spans with `backticks` in plaintext mode

[Sam McCall via Phabricator via cfe-commits]

sammccall created this revision.
sammccall added a reviewer: kadircet.
Herald added subscribers: cfe-commits, usaxena95, arphaman, jkorous, MaskRay, 
ilya-biryukov.
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79142

Files:
  clang-tools-extra/clangd/FormattedString.cpp
  clang-tools-extra/clangd/FormattedString.h
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/unittests/HoverTests.cpp


Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -2022,12 +2022,12 @@
// FIXME: we insert spaces between code and text chunk.
"Tests primality of `p`.",
"Tests primality of `p` .",
-   "Tests primality of p .",
+   "Tests primality of `p` .",
},
{
"'`' should not occur in `Code`",
"'\\`' should not occur in `Code`",
-   "'`' should not occur in Code",
+   "'`' should not occur in `Code`",
},
{
"`not\nparsed`",
Index: clang-tools-extra/clangd/Hover.cpp
===
--- clang-tools-extra/clangd/Hover.cpp
+++ clang-tools-extra/clangd/Hover.cpp
@@ -876,7 +876,7 @@
   case '`':
 if (auto Range = getBacktickQuoteRange(Line, I)) {
   Out.appendText(Line.substr(0, I));
-  Out.appendCode(Range->trim("`"));
+  Out.appendCode(Range->trim("`"), /*Preserve=*/true);
   return parseDocumentationLine(Line.substr(I+Range->size()), Out);
 }
 break;
Index: clang-tools-extra/clangd/FormattedString.h
===
--- clang-tools-extra/clangd/FormattedString.h
+++ clang-tools-extra/clangd/FormattedString.h
@@ -49,7 +49,8 @@
   Paragraph (llvm::StringRef Text);
 
   /// Append inline code, this translates to the ` block in markdown.
-  Paragraph (llvm::StringRef Code);
+  /// \p Preserve indicates the code span must be apparent even in plaintext.
+  Paragraph (llvm::StringRef Code, bool Preserve = false);
 
 private:
   struct Chunk {
@@ -57,6 +58,8 @@
   PlainText,
   InlineCode,
 } Kind = PlainText;
+// Preserve chunk markers in plaintext.
+bool Preserve = false;
 std::string Contents;
 /// Language for code block chunks. Ignored for other chunks.
 std::string Language;
Index: clang-tools-extra/clangd/FormattedString.cpp
===
--- clang-tools-extra/clangd/FormattedString.cpp
+++ clang-tools-extra/clangd/FormattedString.cpp
@@ -361,7 +361,10 @@
 void Paragraph::renderPlainText(llvm::raw_ostream ) const {
   llvm::StringRef Sep = "";
   for (auto  : Chunks) {
-OS << Sep << C.Contents;
+llvm::StringRef Marker = "";
+if (C.Preserve && C.Kind == Chunk::InlineCode)
+  Marker = "`";
+OS << Sep << Marker << C.Contents << Marker;
 Sep = " ";
   }
   OS << '\n';
@@ -396,7 +399,7 @@
   return *this;
 }
 
-Paragraph ::appendCode(llvm::StringRef Code) {
+Paragraph ::appendCode(llvm::StringRef Code, bool Preserve) {
   std::string Norm = canonicalizeSpaces(std::move(Code));
   if (Norm.empty())
 return *this;
@@ -404,6 +407,7 @@
   Chunk  = Chunks.back();
   C.Contents = std::move(Norm);
   C.Kind = Chunk::InlineCode;
+  C.Preserve = Preserve;
   return *this;
 }
 


Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -2022,12 +2022,12 @@
// FIXME: we insert spaces between code and text chunk.
"Tests primality of `p`.",
"Tests primality of `p` .",
-   "Tests primality of p .",
+   "Tests primality of `p` .",
},
{
"'`' should not occur in `Code`",
"'\\`' should not occur in `Code`",
-   "'`' should not occur in Code",
+   "'`' should not occur in `Code`",
},
{
"`not\nparsed`",
Index: clang-tools-extra/clangd/Hover.cpp
===
--- clang-tools-extra/clangd/Hover.cpp
+++ clang-tools-extra/clangd/Hover.cpp
@@ -876,7 +876,7 @@
   case '`':
 if (auto Range = getBacktickQuoteRange(Line, I)) {
   Out.appendText(Line.substr(0, I));
-  Out.appendCode(Range->trim("`"));
+  Out.appendCode(Range->trim("`"), /*Preserve=*/true);
   return 

[PATCH] D74813: [RFC] Add hash of block contents to function block names

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added a comment.

In D74813#2011083 , @alexbdv wrote:

> @dexonsmith what regression are you referring to ? 
>  What this change is effectively doing now is changing the numbering of the 
> blocks from incremental to hash-based.
>  So the demangler functionality remains the same (i think) - I saw that it is 
> ignoring the (currently incrememntal) number, so changing it shouldn't make a 
> difference.
>  Did I miss anything ?


I think you missed @erik.pilkington's comment, which I was replying to.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74813



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

[PATCH] D79139: [clangd] Fix whitespace between chunks in markdown paragraphs.

[Sam McCall via Phabricator via cfe-commits]

sammccall created this revision.
sammccall added a reviewer: kadircet.
Herald added subscribers: cfe-commits, usaxena95, arphaman, jkorous, MaskRay, 
ilya-biryukov.
Herald added a project: clang.

Old model: chunks are always separated by one space.

  This makes it impossible to render "Foo `bar`." correctly.

New model: chunks are separated by space if the left had trailing space, or

  the right had leading space, or space was explicitly requested.
  (Only leading/trailing space in plaintext chunks count, not code)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79139

Files:
  clang-tools-extra/clangd/FormattedString.cpp
  clang-tools-extra/clangd/FormattedString.h
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/unittests/FormattedStringTests.cpp
  clang-tools-extra/clangd/unittests/HoverTests.cpp

Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -2021,8 +2021,8 @@
{
// FIXME: we insert spaces between code and text chunk.
"Tests primality of `p`.",
-   "Tests primality of `p` .",
-   "Tests primality of p .",
+   "Tests primality of `p`.",
+   "Tests primality of p.",
},
{
"'`' should not occur in `Code`",
Index: clang-tools-extra/clangd/unittests/FormattedStringTests.cpp
===
--- clang-tools-extra/clangd/unittests/FormattedStringTests.cpp
+++ clang-tools-extra/clangd/unittests/FormattedStringTests.cpp
@@ -155,11 +155,11 @@
   // Purpose is to check for separation between different chunks.
   Paragraph P;
 
-  P.appendText("after");
+  P.appendText("after ");
   EXPECT_EQ(P.asMarkdown(), "after");
   EXPECT_EQ(P.asPlainText(), "after");
 
-  P.appendCode("foobar");
+  P.appendCode("foobar").appendSpace();
   EXPECT_EQ(P.asMarkdown(), "after `foobar`");
   EXPECT_EQ(P.asPlainText(), "after foobar");
 
@@ -173,8 +173,16 @@
   Paragraph P;
   P.appendText("foo\n   \t   baz");
   P.appendCode(" bar\n");
-  EXPECT_EQ(P.asMarkdown(), "foo baz `bar`");
-  EXPECT_EQ(P.asPlainText(), "foo baz bar");
+  EXPECT_EQ(P.asMarkdown(), "foo baz`bar`");
+  EXPECT_EQ(P.asPlainText(), "foo bazbar");
+}
+
+TEST(Paragraph, SpacesCollapsed) {
+  Paragraph P;
+  P.appendText(" foo bar ");
+  P.appendText(" baz ");
+  EXPECT_EQ(P.asMarkdown(), "foo bar baz");
+  EXPECT_EQ(P.asPlainText(), "foo bar baz");
 }
 
 TEST(Paragraph, NewLines) {
Index: clang-tools-extra/clangd/Hover.cpp
===
--- clang-tools-extra/clangd/Hover.cpp
+++ clang-tools-extra/clangd/Hover.cpp
@@ -772,7 +772,7 @@
   // https://github.com/microsoft/vscode/issues/88417 for details.
   markup::Paragraph  = Output.addHeading(3);
   if (Kind != index::SymbolKind::Unknown)
-Header.appendText(index::getSymbolKindString(Kind));
+Header.appendText(index::getSymbolKindString(Kind)).appendSpace();
   assert(!Name.empty() && "hover triggered on a nameless symbol");
   Header.appendCode(Name);
 
@@ -786,9 +786,9 @@
 // Parameters:
 // - `bool param1`
 // - `int param2 = 5`
-Output.addParagraph().appendText("→").appendCode(*ReturnType);
+Output.addParagraph().appendText("→ ").appendCode(*ReturnType);
 if (Parameters && !Parameters->empty()) {
-  Output.addParagraph().appendText("Parameters:");
+  Output.addParagraph().appendText("Parameters: ");
   markup::BulletList  = Output.addBulletList();
   for (const auto  : *Parameters) {
 std::string Buffer;
@@ -803,7 +803,7 @@
 
   if (Value) {
 markup::Paragraph  = Output.addParagraph();
-P.appendText("Value =");
+P.appendText("Value = ");
 P.appendCode(*Value);
   }
 
@@ -883,6 +883,7 @@
 }
   }
   Out.appendText(Line);
+  Out.appendSpace();
 }
 
 void parseDocumentation(llvm::StringRef Input, markup::Document ) {
Index: clang-tools-extra/clangd/FormattedString.h
===
--- clang-tools-extra/clangd/FormattedString.h
+++ clang-tools-extra/clangd/FormattedString.h
@@ -51,6 +51,10 @@
   /// Append inline code, this translates to the ` block in markdown.
   Paragraph (llvm::StringRef Code);
 
+  /// Ensure there is space between the surrounding chunks.
+  /// Has no effect at the beginning or end of a paragraph.
+  Paragraph ();
+
 private:
   struct Chunk {
 enum {
@@ -60,6 +64,10 @@
 std::string Contents;
 /// Language for code block chunks. Ignored for other chunks.
 std::string Language;
+// Whether this chunk should be surrounded by whitespace.
+// Consecutive SpaceAfter and SpaceBefore will be collapsed into one space.
+// Code spans don't set this: 

[PATCH] D79079: [clangd] Make use of URIs in FileShardedIndex

[Sam McCall via Phabricator via cfe-commits]

sammccall accepted this revision.
sammccall added inline comments.
This revision is now accepted and ready to land.



Comment at: clang-tools-extra/clangd/index/FileIndex.h:59
+/// A container of slabs associated with a key. It can be updated at key
+/// granularity, replacing all slabs belonging to a key with a new set.
 ///

may want to mention that keys are typically files, up to you


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79079



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

[PATCH] D78659: Add nomerge function attribute to supress tail merge optimization in simplifyCFG

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

I think this looks good, but I would like to get a second opinion from Alina 
(@asbirlea).


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

https://reviews.llvm.org/D78659



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

[PATCH] D77456: [clangd] Parse `foo` in documentation comments and render as code.

[Sam McCall via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG30d17d885283: [clangd] Parse `foo` in documentation comments 
and render as code. (authored by sammccall).

Changed prior to commit:
  https://reviews.llvm.org/D77456?vs=255010=261063#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77456

Files:
  clang-tools-extra/clangd/FormattedString.cpp
  clang-tools-extra/clangd/FormattedString.h
  clang-tools-extra/clangd/Hover.cpp
  clang-tools-extra/clangd/unittests/HoverTests.cpp

Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -1958,7 +1958,7 @@
   }
 }
 
-TEST(Hover, DocCommentLineBreakConversion) {
+TEST(Hover, ParseDocumentation) {
   struct Case {
 llvm::StringRef Documentation;
 llvm::StringRef ExpectedRenderMarkdown;
@@ -2017,6 +2017,22 @@
"foo\nbar",
"foo bar",
"foo bar",
+   },
+   {
+   // FIXME: we insert spaces between code and text chunk.
+   "Tests primality of `p`.",
+   "Tests primality of `p` .",
+   "Tests primality of p .",
+   },
+   {
+   "'`' should not occur in `Code`",
+   "'\\`' should not occur in `Code`",
+   "'`' should not occur in Code",
+   },
+   {
+   "`not\nparsed`",
+   "\\`not parsed\\`",
+   "`not parsed`",
}};
 
   for (const auto  : Cases) {
Index: clang-tools-extra/clangd/Hover.cpp
===
--- clang-tools-extra/clangd/Hover.cpp
+++ clang-tools-extra/clangd/Hover.cpp
@@ -772,7 +772,7 @@
   // https://github.com/microsoft/vscode/issues/88417 for details.
   markup::Paragraph  = Output.addHeading(3);
   if (Kind != index::SymbolKind::Unknown)
-Header.appendText(std::string(index::getSymbolKindString(Kind)));
+Header.appendText(index::getSymbolKindString(Kind));
   assert(!Name.empty() && "hover triggered on a nameless symbol");
   Header.appendCode(Name);
 
@@ -809,10 +809,11 @@
 
   if (Offset)
 Output.addParagraph().appendText(
-llvm::formatv("Offset: {0} byte{1}", *Offset, *Offset == 1 ? "" : "s"));
+llvm::formatv("Offset: {0} byte{1}", *Offset, *Offset == 1 ? "" : "s")
+.str());
   if (Size)
 Output.addParagraph().appendText(
-llvm::formatv("Size: {0} byte{1}", *Size, *Size == 1 ? "" : "s"));
+llvm::formatv("Size: {0} byte{1}", *Size, *Size == 1 ? "" : "s").str());
 
   if (!Documentation.empty())
 parseDocumentation(Documentation, Output);
@@ -838,6 +839,52 @@
   return Output;
 }
 
+// If the backtick at `Offset` starts a probable quoted range, return the range
+// (including the quotes).
+llvm::Optional getBacktickQuoteRange(llvm::StringRef Line,
+  unsigned Offset) {
+  assert(Line[Offset] == '`');
+
+  // The open-quote is usually preceded by whitespace.
+  llvm::StringRef Prefix = Line.substr(0, Offset);
+  constexpr llvm::StringLiteral BeforeStartChars = " \t(=";
+  if (!Prefix.empty() && !BeforeStartChars.contains(Prefix.back()))
+return llvm::None;
+
+  // The quoted string must be nonempty and usually has no leading/trailing ws.
+  auto Next = Line.find('`', Offset + 1);
+  if (Next == llvm::StringRef::npos)
+return llvm::None;
+  llvm::StringRef Contents = Line.slice(Offset + 1, Next);
+  if (Contents.empty() || isWhitespace(Contents.front()) ||
+  isWhitespace(Contents.back()))
+return llvm::None;
+
+  // The close-quote is usually followed by whitespace or punctuation.
+  llvm::StringRef Suffix = Line.substr(Next + 1);
+  constexpr llvm::StringLiteral AfterEndChars = " \t)=.,;:";
+  if (!Suffix.empty() && !AfterEndChars.contains(Suffix.front()))
+return llvm::None;
+
+  return Line.slice(Offset, Next+1);
+}
+
+void parseDocumentationLine(llvm::StringRef Line, markup::Paragraph ) {
+  // Probably this is appendText(Line), but scan for something interesting.
+  for (unsigned I = 0; I < Line.size(); ++I) {
+switch (Line[I]) {
+  case '`':
+if (auto Range = getBacktickQuoteRange(Line, I)) {
+  Out.appendText(Line.substr(0, I));
+  Out.appendCode(Range->trim("`"));
+  return parseDocumentationLine(Line.substr(I+Range->size()), Out);
+}
+break;
+}
+  }
+  Out.appendText(Line);
+}
+
 void parseDocumentation(llvm::StringRef Input, markup::Document ) {
   std::vector ParagraphLines;
   auto FlushParagraph = [&] {
@@ -845,7 +892,7 @@
   return;
 auto  = Output.addParagraph();
 for 

[PATCH] D79079: [clangd] Make use of URIs in FileShardedIndex

[Kadir Cetinkaya via Phabricator via cfe-commits]

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



Comment at: clang-tools-extra/clangd/index/Background.cpp:183
 const auto  = IndexIt.getValue();
 // Note that sources do not contain any information regarding missing
 // headers, since we don't even know what absolute path they should fall 
in.

sammccall wrote:
> is this really important enough to be worth saying twice :-)
copy pasta is the worst kind of pasta :D


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79079



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

[PATCH] D78659: Add nomerge function attribute to supress tail merge optimization in simplifyCFG

[Zequan Wu via Phabricator via cfe-commits]

zequanwu updated this revision to Diff 261059.
zequanwu marked 4 inline comments as done.

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

https://reviews.llvm.org/D78659

Files:
  llvm/docs/LangRef.rst
  llvm/include/llvm/Bitcode/LLVMBitCodes.h
  llvm/include/llvm/IR/Attributes.td
  llvm/include/llvm/IR/InstrTypes.h
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/AsmParser/LLToken.h
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/Attributes.cpp
  llvm/lib/IR/Verifier.cpp
  llvm/lib/Transforms/Utils/SimplifyCFG.cpp
  llvm/test/Transforms/SimplifyCFG/nomerge.ll

Index: llvm/test/Transforms/SimplifyCFG/nomerge.ll
===
--- /dev/null
+++ llvm/test/Transforms/SimplifyCFG/nomerge.ll
@@ -0,0 +1,71 @@
+; RUN: opt < %s -O1 -S | FileCheck %s
+
+; The attribute nomerge prevents the 3 bar() calls from being sunk/hoisted into 
+; one inside a function. Check that there are still 3 tail calls.
+
+; Test case for preventing sinking
+; CHECK-LABEL: define void @sink
+; CHECK: if.then:
+; CHECK-NEXT: tail call void @bar()
+; CHECK: if.then2:
+; CHECK-NEXT: tail call void @bar()
+; CHECK: if.end3:
+; CHECK-NEXT: tail call void @bar()
+define void @sink(i32 %i) {
+entry:
+  switch i32 %i, label %if.end3 [
+i32 5, label %if.then
+i32 7, label %if.then2
+  ]
+
+if.then:
+  tail call void @bar() #0
+  br label %if.end3
+
+if.then2:
+  tail call void @bar() #0
+  br label %if.end3
+
+if.end3:
+  tail call void @bar() #0
+  ret void
+}
+
+; Test case for preventing hoisting
+; CHECK-LABEL: define void @hoist
+; CHECK: if.then:
+; CHECK-NEXT: tail call void @bar()
+; CHECK: if.then2:
+; CHECK-NEXT: tail call void @bar()
+; CHECK: if.end:
+; CHECK-NEXT: tail call void @bar()
+define void @hoist(i32 %i) {
+entry:
+  %i.addr = alloca i32, align 4
+  store i32 %i, i32* %i.addr, align 4
+  %0 = load i32, i32* %i.addr, align 4
+  %cmp = icmp eq i32 %0, 5
+  br i1 %cmp, label %if.then, label %if.else
+
+if.then:
+  tail call void @bar() #1
+  unreachable
+
+if.else:
+  %1 = load i32, i32* %i.addr, align 4
+  %cmp1 = icmp eq i32 %i, 7
+  br i1 %cmp1, label %if.then2, label %if.end
+
+if.then2:
+  tail call void @bar() #1
+  unreachable
+
+if.end:
+  tail call void @bar() #1
+  unreachable
+}
+
+declare void @bar()
+
+attributes #0 = { nomerge }
+attributes #1 = { noreturn nomerge }
Index: llvm/lib/Transforms/Utils/SimplifyCFG.cpp
===
--- llvm/lib/Transforms/Utils/SimplifyCFG.cpp
+++ llvm/lib/Transforms/Utils/SimplifyCFG.cpp
@@ -1300,6 +1300,14 @@
 if (!TTI.isProfitableToHoist(I1) || !TTI.isProfitableToHoist(I2))
   return Changed;
 
+// If any of the two call sites has nomerge attribute, stop hoisting.
+if (const auto *CB1 = dyn_cast(I1))
+  if (CB1->cannotMerge())
+return Changed;
+if (const auto *CB2 = dyn_cast(I2))
+  if (CB2->cannotMerge())
+return Changed;
+
 if (isa(I1) || isa(I2)) {
   assert (isa(I1) && isa(I2));
   // The debug location is an integral part of a debug info intrinsic
@@ -1485,8 +1493,9 @@
 // Conservatively return false if I is an inline-asm instruction. Sinking
 // and merging inline-asm instructions can potentially create arguments
 // that cannot satisfy the inline-asm constraints.
+// If the instruction has nomerge attribute, return false.
 if (const auto *C = dyn_cast(I))
-  if (C->isInlineAsm())
+  if (C->cannotMerge())
 return false;
 
 // Each instruction must have zero or one use.
Index: llvm/lib/IR/Verifier.cpp
===
--- llvm/lib/IR/Verifier.cpp
+++ llvm/lib/IR/Verifier.cpp
@@ -1509,6 +1509,7 @@
 /// Return true if this attribute kind only applies to functions.
 static bool isFuncOnlyAttr(Attribute::AttrKind Kind) {
   switch (Kind) {
+  case Attribute::NoMerge:
   case Attribute::NoReturn:
   case Attribute::NoSync:
   case Attribute::WillReturn:
Index: llvm/lib/IR/Attributes.cpp
===
--- llvm/lib/IR/Attributes.cpp
+++ llvm/lib/IR/Attributes.cpp
@@ -372,6 +372,8 @@
 return "noinline";
   if (hasAttribute(Attribute::NonLazyBind))
 return "nonlazybind";
+  if (hasAttribute(Attribute::NoMerge))
+return "nomerge";
   if (hasAttribute(Attribute::NonNull))
 return "nonnull";
   if (hasAttribute(Attribute::NoRedZone))
Index: llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
===
--- llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
+++ llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
@@ -647,6 +647,8 @@
 return bitc::ATTR_KIND_NO_INLINE;
   case Attribute::NoRecurse:
 return bitc::ATTR_KIND_NO_RECURSE;
+  case Attribute::NoMerge:
+return bitc::ATTR_KIND_NO_MERGE;
   case Attribute::NonLazyBind:

[PATCH] D79079: [clangd] Make use of URIs in FileShardedIndex

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet updated this revision to Diff 261061.
kadircet marked 2 inline comments as done.
kadircet added a comment.

- Update FileSymbols to express keys are not necessarily file paths.
- Use Uri for keys of PreambleSymbols


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79079

Files:
  clang-tools-extra/clangd/index/Background.cpp
  clang-tools-extra/clangd/index/FileIndex.cpp
  clang-tools-extra/clangd/index/FileIndex.h
  clang-tools-extra/clangd/unittests/FileIndexTests.cpp

Index: clang-tools-extra/clangd/unittests/FileIndexTests.cpp
===
--- clang-tools-extra/clangd/unittests/FileIndexTests.cpp
+++ clang-tools-extra/clangd/unittests/FileIndexTests.cpp
@@ -568,13 +568,12 @@
 
   IF.Cmd = tooling::CompileCommand(testRoot(), "b.cc", {"clang"}, "out");
 
-  FileShardedIndex ShardedIndex(std::move(IF), testPath("b.cc"));
-  ASSERT_THAT(
-  ShardedIndex.getAllFiles(),
-  UnorderedElementsAre(testPath("a.h"), testPath("b.h"), testPath("b.cc")));
+  FileShardedIndex ShardedIndex(std::move(IF));
+  ASSERT_THAT(ShardedIndex.getAllSources(),
+  UnorderedElementsAre(AHeaderUri, BHeaderUri, BSourceUri));
 
   {
-auto Shard = ShardedIndex.getShard(testPath("a.h"));
+auto Shard = ShardedIndex.getShard(AHeaderUri).getValue();
 EXPECT_THAT(Shard.Symbols.getValue(), UnorderedElementsAre(QName("1")));
 EXPECT_THAT(Shard.Refs.getValue(), IsEmpty());
 EXPECT_THAT(
@@ -586,7 +585,7 @@
 EXPECT_TRUE(Shard.Cmd.hasValue());
   }
   {
-auto Shard = ShardedIndex.getShard(testPath("b.h"));
+auto Shard = ShardedIndex.getShard(BHeaderUri).getValue();
 EXPECT_THAT(Shard.Symbols.getValue(), UnorderedElementsAre(QName("2")));
 EXPECT_THAT(Shard.Refs.getValue(), IsEmpty());
 EXPECT_THAT(
@@ -599,7 +598,7 @@
 EXPECT_TRUE(Shard.Cmd.hasValue());
   }
   {
-auto Shard = ShardedIndex.getShard(testPath("b.cc"));
+auto Shard = ShardedIndex.getShard(BSourceUri).getValue();
 EXPECT_THAT(Shard.Symbols.getValue(), UnorderedElementsAre(QName("2")));
 EXPECT_THAT(Shard.Refs.getValue(), UnorderedElementsAre(Pair(Sym1.ID, _)));
 EXPECT_THAT(Shard.Relations.getValue(), IsEmpty());
Index: clang-tools-extra/clangd/index/FileIndex.h
===
--- clang-tools-extra/clangd/index/FileIndex.h
+++ clang-tools-extra/clangd/index/FileIndex.h
@@ -55,30 +55,29 @@
   Merge,
 };
 
-/// A container of Symbols from several source files. It can be updated
-/// at source-file granularity, replacing all symbols from one file with a new
-/// set.
+/// A container of slabs associated with a key. It can be updated at key
+/// granularity, replacing all slabs belonging to a key with a new set.
 ///
-/// This implements a snapshot semantics for symbols in a file. Each update to a
-/// file will create a new snapshot for all symbols in the file. Snapshots are
-/// managed with shared pointers that are shared between this class and the
-/// users. For each file, this class only stores a pointer pointing to the
-/// newest snapshot, and an outdated snapshot is deleted by the last owner of
-/// the snapshot, either this class or the symbol index.
+/// This implements snapshot semantics. Each update will create a new snapshot
+/// for all slabs of the Key. Snapshots are managed with shared pointers that
+/// are shared between this class and the users. For each key, this class only
+/// stores a pointer pointing to the newest snapshot, and an outdated snapshot
+/// is deleted by the last owner of the snapshot, either this class or the
+/// symbol index.
 ///
 /// The snapshot semantics keeps critical sections minimal since we only need
 /// locking when we swap or obtain references to snapshots.
 class FileSymbols {
 public:
-  /// Updates all symbols and refs in a file.
-  /// If either is nullptr, corresponding data for \p Path will be removed.
-  /// If CountReferences is true, \p Refs will be used for counting References
+  /// Updates all slabs associated with the \p Key.
+  /// If either is nullptr, corresponding data for \p Key will be removed.
+  /// If CountReferences is true, \p Refs will be used for counting references
   /// during merging.
-  void update(PathRef Path, std::unique_ptr Slab,
+  void update(llvm::StringRef Key, std::unique_ptr Symbols,
   std::unique_ptr Refs,
   std::unique_ptr Relations, bool CountReferences);
 
-  /// The index keeps the symbols alive.
+  /// The index keeps the slabs alive.
   /// Will count Symbol::References based on number of references in the main
   /// files, while building the index with DuplicateHandling::Merge option.
   std::unique_ptr
@@ -92,12 +91,9 @@
   };
   mutable std::mutex Mutex;
 
-  /// Stores the latest symbol snapshots for all active files.
-  llvm::StringMap> FileToSymbols;
-  /// Stores the 

[PATCH] D77456: [clangd] Parse `foo` in documentation comments and render as code.

[Sam McCall via Phabricator via cfe-commits]

sammccall marked an inline comment as done.
sammccall added a comment.

Discussed offline, will follow up with fix for spaces and preserving backticks 
in text.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D77456



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

[PATCH] D79014: [clangd] Move non-clang base pieces into separate support/ lib.

[Jinsong Ji via Phabricator via cfe-commits]

jsji added a comment.

Thanks all, yes, it is passing now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79014



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

[libclc] 174c41d - libclc: Pass system libraries to the linker after llvm libraries

[Tom Stellard via cfe-commits]

Author: Tom Stellard
Date: 2020-04-29T15:34:54-07:00
New Revision: 174c41defc63db4ac7594e00a5044672ff624a31

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

LOG: libclc: Pass system libraries to the linker after llvm libraries

Summary:
The llvm libraries depend on the symbols in the system libaries, so
the system libraries need to be added after.

Reviewers: jvesely

Reviewed By: jvesely

Subscribers: mgorny, llvm-commits

Tags: #llvm

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

Added: 


Modified: 
libclc/CMakeLists.txt

Removed: 




diff  --git a/libclc/CMakeLists.txt b/libclc/CMakeLists.txt
index 7274f02f666b..7b981110f6fd 100644
--- a/libclc/CMakeLists.txt
+++ b/libclc/CMakeLists.txt
@@ -125,8 +125,8 @@ link_directories( ${LLVM_LIBDIR} )
 add_executable( prepare_builtins utils/prepare-builtins.cpp )
 target_compile_options( prepare_builtins PRIVATE ${LLVM_CXX_FLAGS} )
 target_compile_definitions( prepare_builtins PRIVATE ${LLVM_VERSION_DEFINE} )
-target_link_libraries( prepare_builtins PRIVATE ${LLVM_SYSTEM_LIBS} )
 target_link_libraries( prepare_builtins PRIVATE ${LLVM_LIBS} )
+target_link_libraries( prepare_builtins PRIVATE ${LLVM_SYSTEM_LIBS} )
 
 # Setup arch devices
 set( r600--_devices cedar cypress barts cayman )



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

[clang-tools-extra] 30d17d8 - [clangd] Parse `foo` in documentation comments and render as code.

[Sam McCall via cfe-commits]

Author: Sam McCall
Date: 2020-04-30T00:22:15+02:00
New Revision: 30d17d88528329558b6df22cc9595eae95a9f77c

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

LOG: [clangd] Parse `foo` in documentation comments and render as code.

Reviewers: kadircet

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

Tags: #clang

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

Added: 


Modified: 
clang-tools-extra/clangd/FormattedString.cpp
clang-tools-extra/clangd/FormattedString.h
clang-tools-extra/clangd/Hover.cpp
clang-tools-extra/clangd/unittests/HoverTests.cpp

Removed: 




diff  --git a/clang-tools-extra/clangd/FormattedString.cpp 
b/clang-tools-extra/clangd/FormattedString.cpp
index d3dbdbba17bc..81de6a8be93c 100644
--- a/clang-tools-extra/clangd/FormattedString.cpp
+++ b/clang-tools-extra/clangd/FormattedString.cpp
@@ -216,23 +216,10 @@ std::string getMarkerForCodeBlock(llvm::StringRef Input) {
 }
 
 // Trims the input and concatenates whitespace blocks into a single ` `.
-std::string canonicalizeSpaces(std::string Input) {
-  // Goes over the string and preserves only a single ` ` for any whitespace
-  // chunks, the rest is moved to the end of the string and dropped in the end.
-  auto WritePtr = Input.begin();
+std::string canonicalizeSpaces(llvm::StringRef Input) {
   llvm::SmallVector Words;
   llvm::SplitString(Input, Words);
-  if (Words.empty())
-return "";
-  // Go over each word and add it to the string.
-  for (llvm::StringRef Word : Words) {
-if (WritePtr > Input.begin())
-  *WritePtr++ = ' '; // Separate from previous block.
-llvm::for_each(Word, [](const char C) { *WritePtr++ = C; });
-  }
-  // Get rid of extra spaces.
-  Input.resize(WritePtr - Input.begin());
-  return Input;
+  return llvm::join(Words, " ");
 }
 
 std::string renderBlocks(llvm::ArrayRef> Children,
@@ -398,24 +385,24 @@ void BulletList::renderPlainText(llvm::raw_ostream ) 
const {
   }
 }
 
-Paragraph ::appendText(std::string Text) {
-  Text = canonicalizeSpaces(std::move(Text));
-  if (Text.empty())
+Paragraph ::appendText(llvm::StringRef Text) {
+  std::string Norm = canonicalizeSpaces(Text);
+  if (Norm.empty())
 return *this;
   Chunks.emplace_back();
   Chunk  = Chunks.back();
-  C.Contents = std::move(Text);
+  C.Contents = std::move(Norm);
   C.Kind = Chunk::PlainText;
   return *this;
 }
 
-Paragraph ::appendCode(std::string Code) {
-  Code = canonicalizeSpaces(std::move(Code));
-  if (Code.empty())
+Paragraph ::appendCode(llvm::StringRef Code) {
+  std::string Norm = canonicalizeSpaces(std::move(Code));
+  if (Norm.empty())
 return *this;
   Chunks.emplace_back();
   Chunk  = Chunks.back();
-  C.Contents = std::move(Code);
+  C.Contents = std::move(Norm);
   C.Kind = Chunk::InlineCode;
   return *this;
 }

diff  --git a/clang-tools-extra/clangd/FormattedString.h 
b/clang-tools-extra/clangd/FormattedString.h
index fe864ba57568..8c522d060c4f 100644
--- a/clang-tools-extra/clangd/FormattedString.h
+++ b/clang-tools-extra/clangd/FormattedString.h
@@ -46,10 +46,10 @@ class Paragraph : public Block {
   void renderPlainText(llvm::raw_ostream ) const override;
 
   /// Append plain text to the end of the string.
-  Paragraph (std::string Text);
+  Paragraph (llvm::StringRef Text);
 
   /// Append inline code, this translates to the ` block in markdown.
-  Paragraph (std::string Code);
+  Paragraph (llvm::StringRef Code);
 
 private:
   struct Chunk {

diff  --git a/clang-tools-extra/clangd/Hover.cpp 
b/clang-tools-extra/clangd/Hover.cpp
index b0ac041abe5f..3a66130ea153 100644
--- a/clang-tools-extra/clangd/Hover.cpp
+++ b/clang-tools-extra/clangd/Hover.cpp
@@ -772,7 +772,7 @@ markup::Document HoverInfo::present() const {
   // https://github.com/microsoft/vscode/issues/88417 for details.
   markup::Paragraph  = Output.addHeading(3);
   if (Kind != index::SymbolKind::Unknown)
-Header.appendText(std::string(index::getSymbolKindString(Kind)));
+Header.appendText(index::getSymbolKindString(Kind));
   assert(!Name.empty() && "hover triggered on a nameless symbol");
   Header.appendCode(Name);
 
@@ -809,10 +809,11 @@ markup::Document HoverInfo::present() const {
 
   if (Offset)
 Output.addParagraph().appendText(
-llvm::formatv("Offset: {0} byte{1}", *Offset, *Offset == 1 ? "" : 
"s"));
+llvm::formatv("Offset: {0} byte{1}", *Offset, *Offset == 1 ? "" : "s")
+.str());
   if (Size)
 Output.addParagraph().appendText(
-llvm::formatv("Size: {0} byte{1}", *Size, *Size == 1 ? "" : "s"));
+llvm::formatv("Size: {0} byte{1}", *Size, *Size == 1 ? "" : 
"s").str());
 
   if (!Documentation.empty())
 parseDocumentation(Documentation, Output);
@@ -838,6 +839,52 @@ markup::Document 

Re: [PATCH] D78853: [Analysis] Fix null pointer dereference warnings [1/n]

[Aaron Puchert via cfe-commits]

Am 29.04.20 um 23:11 schrieb Mandeep Singh Grang:
> My previous email details why we are doing
> this: http://lists.llvm.org/pipermail/llvm-dev/2020-April/141167.html
> Basically, we ran the PREfast static analysis tool on LLVM/Clang and
> it reported a lot of warnings. I guess some of them are false
> positives after all.
Thanks for the link. There is nothing wrong with running additional
tools on LLVM.
> As David suggests that maybe I should validate these warnings by also
> running the clang static analyzer.
You could have a look at http://llvm.org/reports/scan-build/. It's not
terribly up-to-date though, so you might also run it yourself.
> There are a lot of other warnings reported by the tool. Here is the
> full
> list: 
> https://docs.google.com/spreadsheets/d/1h_3tHxsgBampxb7PXoB5lgwiBSpTty9RLe5maIQxnTk/edit?usp=sharing.

In my opinion you're probably not losing a lot by filtering out the
types of issues that the Clang static analyzer can find as well. So for
example, ignore the null dereferences since Clang has essentially the
same check. Of course it could be that the tool finds additional issues,
I can't really say that. But you can see in the report that there quite
a few issues of a similar kind. (This one isn't among them, however.)

For analyzing the issues in the list, it would be good to note the git
commit of your analysis run, otherwise it might be hard to follow the
reports.

> If the community is interested in getting those fixed I can upstream
> patches.

Improvements are always welcome, but unfortunately no static analysis
tool only reports actual issues. Otherwise one could hope that the Clang
findings would have been all fixed by now.

So I think you need to carefully inspect the reports. It's not a bad
idea to start with a random sample of the issues reported by every
check. Avoid stylistic issues like shadowing: people have different
opinions on that. Then try to find out if there is a real issue, or if
you can think of a way to improve the code. (That's often subjective, of
course. But if you can rewrite code a bit to make it more obvious that a
certain bad thing can't happen, you'll find open ears.)

The best thing is of course if you can use the report to construct
failing test cases, but I wouldn't put the bar that high.

Best regards,
Aaron

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

[PATCH] D79121: Add nomerge function attribute to clang

[Reid Kleckner via Phabricator via cfe-commits]

rnk added inline comments.



Comment at: clang/include/clang/Basic/Attr.td:1799
+  let Spellings = [Clang<"nomerge">];
+  let Subjects = SubjectList<[Function]>;
+  let Documentation = [NoMergeDocs];

Clang supports many function-like things that are not functions, for example, 
Objective C method declarations are not considered FunctionDecls in the AST. 
Blocks are another function-like thing. I see below there is a `FunctionLike` 
subject type. Lets use that here.

I would like to make it possible to apply this attribute directly to call 
expressions as well, but I don't see a good example of how to do that in the 
existing attribute. I'd like to be able to do this, for example:

```
void __attribute__((noreturn)) bar();
void foo(bool cond) {
  if (cond)
[[clang::nomerge]] bar();
  else
[[clang::nomerge]] bar();
}
```

This gives the user fine-grained control. It allows them to call some existing 
API, like perhaps RaiseException, of which they do not control the declaration, 
and mark the calls as unmergeable.



Comment at: clang/test/CodeGen/attr-nomerge.c:15
+// CHECK: attributes #1 = { nomerge {{.*}} }
+// CHECK: attributes #2 = { nomerge }

These numbers can be unstable. Generally the best practice is to do something 
like this:
  // CHECK: declare void @bar() #[[NOMERGEATTR:\d+]]
  // CHECK: attributes #[[NOMERGEATTR]] = { nomerge {{.*}} }

This makes the test more readable and more resilient in the case that the 
attribute set numbers change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79121



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

[PATCH] D49890: Clang-Tidy Export Problem

[Ng Zhi An via Phabricator via cfe-commits]

ngzhian added a comment.

I found this patch while searching for a similar problem I faced while tryin to 
use clang-tidy to fix some warnings in V8 (Chrome's JavaScript engine).
The setup for our compilation is as such:

- basedir
  - src/
  - out/ -arch1/
  - .o files, generated files
  - compile_commands.json
- arch2/

We use ninja to build, so usually with a command like `ninja -C out/arch1`, 
this means (roughly) cd into out/arch1 and build.

Given this, I have an alternative suggestion for a fix. In run-clang-tidy.py 
apply_fixes, we call the clang-apply-replacement with cwd set to build_path, 
like so:

  diff --git a/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py 
b/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
  index 1eb13529575..cde9e3671af 100755
  --- a/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
  +++ b/clang-tools-extra/clang-tidy/tool/run-clang-tidy.py
  @@ -150,7 +150,7 @@ def apply_fixes(args, tmpdir):
 if args.style:
   invocation.append('-style=' + args.style)
 invocation.append(tmpdir)
  -  subprocess.call(invocation)
  +  subprocess.call(invocation, cwd=args.build_path)

def run_tidy(args, tmpdir, build_path, queue, lock, failed_files):

I don't know the internals of clang-tidy enough to do this, but it works for 
me. And it seems reasonable, since the Replacement FilePath in the yaml file 
consumed by clang-apply-replacement was generated as a path relative to the 
build_path anyway. For now this is a sufficient hack for my use case (tried 
with with just 1 data point as a test), and it will be good to get feedback if 
this fix is correct. Thanks!


Repository:
  rCTE Clang Tools Extra

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

https://reviews.llvm.org/D49890



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

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78785



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

[clang] 5b862b6 - Fix ext-int Sema test that didn't specify a triple.

[Erich Keane via cfe-commits]

Author: Erich Keane
Date: 2020-04-29T14:34:53-07:00
New Revision: 5b862b6aa7705fdbd893dc5946289631e7b6d662

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

LOG: Fix ext-int Sema test that didn't specify a triple.

I added a limit to make sure that _ExtInt isn't exposed on systems that
haven't considered it in their ABI.  The ext-int.cpp Sema test didn't
have a triple, so on non x86/x86_64 it would fail with this new error.

This patch adds said triple to make sure this passes.

Added: 


Modified: 
clang/test/SemaCXX/ext-int.cpp

Removed: 




diff  --git a/clang/test/SemaCXX/ext-int.cpp b/clang/test/SemaCXX/ext-int.cpp
index 6a06280dceec..cf94fd17162a 100644
--- a/clang/test/SemaCXX/ext-int.cpp
+++ b/clang/test/SemaCXX/ext-int.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -fsyntax-only -verify %s -Wimplicit-int-conversion
+// RUN: %clang_cc1 -fsyntax-only -verify %s -Wimplicit-int-conversion -triple 
x86_64-gnu-linux
 
 template
 struct HasExtInt {



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

[PATCH] D78659: Add nomerge function attribute to supress tail merge optimization in simplifyCFG

[Reid Kleckner via Phabricator via cfe-commits]

rnk added a comment.

This looks pretty close, let's do one more iteration.




Comment at: llvm/include/llvm/IR/InstrTypes.h:1720
 
+  /// Determine if the invoke cannot be tail merged.
+  bool cannotMerge() const { return hasFnAttr(Attribute::NoMerge); }

Let's say "call" instead of "invoke". This method appears in the CallBase 
class. "Invoke" specifically refers to a call in LLVM IR which has an 
exceptional edge attached to it.



Comment at: llvm/lib/Transforms/Utils/SimplifyCFG.cpp:1305
+if (const auto *CB1 = dyn_cast(I1))
+  if (CB1->cannotMerge())
+return Changed;

It seems inconsistent that we don't apply the same logic to inline asm here. I 
think you should modify `cannotMerge` to return `isInlineAsm() || 
hasFnAttr(...NoMerge)`, and then remove the isInlineAsm case below.



Comment at: llvm/test/Transforms/SimplifyCFG/nomerge.ll:8
+; CHECK-LABEL: define void @sink
+; CHECK: tail call void @bar()
+; CHECK: tail call void @bar()

I would prefer retaining CHECK lines for the basic block labels to make it 
clear that these calls are all in separate blocks.



Comment at: llvm/test/Transforms/SimplifyCFG/nomerge.ll:34
+; CHECK: tail call void @bar()
+; CHECK: tail call void @bar()
+; CHECK: tail call void @bar()

ditto regarding labels


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

https://reviews.llvm.org/D78659



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

[PATCH] D68049: Propeller: Clang options for basic block sections

[Sriraman Tallam via Phabricator via cfe-commits]

tmsriram added a comment.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

Ping.


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

https://reviews.llvm.org/D68049



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

[PATCH] D78756: [SveEmitter] Add builtins for svreinterpret

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:7880
+return Builder.CreateBitCast(Val, Ty);
+  }
+

sdesmalen wrote:
> efriedma wrote:
> > sdesmalen wrote:
> > > efriedma wrote:
> > > > I'm vaguely suspicious this might be wrong for big-endian targets.  I 
> > > > mean, this isn't unreasonable, but users might be surprised if 
> > > > svreinterpret isn't a no-op.
> > > For SVE the loads and stores (svld1 and svst1) are all endian safe, so no 
> > > special consideration needs to be taken for big endian targets.
> > > 
> > > The ACLE specifies that:
> > > > The svreinterpret functions simply reinterpret a vector of one type as 
> > > > a vector of another type, without changing any of the bits.
> > "bitcast" is specified to mean "reinterpret the bits like a store+load".  
> > On big-endian NEON (and, I assume, SVE), that isn't a no-op.  See 
> > http://llvm.org/docs/BigEndianNEON.html .
> > 
> > I mean, if the answer here is "yes, svreinterpret is supposed to lower to a 
> > REV", then that's fine.  But I'd like to see some explciit acknowledgement 
> > that that's intentional.
> Thanks for pointing out that page, but for SVE I don't think the 
> svreinterpret should lower to a REV.
> 
> This is probably where things are different from Neon. The ACLE SVE vectors 
> such as `svint32_t` are opaque vector types and the only way to load/store 
> them from/to memory is through the use of the svld1 and svst1 intrinsics 
> which are endian safe (in that they use the ld1/st1 instructions that do 
> endianess conversion on big endian targets). The ACLE does not expose any 
> full-vector load/store (ldr/str) operations.
Like that page describes, we use ld1/st1 for big-endian NEON, to match the LLVM 
IR rules for laying out a vector.  If you use ld1/st1 to load/store vectors on 
big-endian NEON, a bitcast is not a no-op.  As far as I know, SVE ld1/st1 is 
equivalent to NEON ld1/st1 in the case where vscale=1.  Therefore, on 
big-endian SVE, a bitcast is not a no-op.

That leaves the following options:

1. svreinterpret is not a no-op.
2. svreinterpret is not equivalent to an LLVM IR bitcast, so this patch needs 
to be changed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78756



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

[PATCH] D78827: Add support for #pragma clang fp reassoc(on|off) -- floating point control of associative math transformations

[Melanie Blower via Phabricator via cfe-commits]

mibintc updated this revision to Diff 261036.
mibintc added a comment.

Thanks for your review @sepavloff and @erichkeane, I have responded to your 
feedback and reverted the name back to reassoc which is what Serge prefers


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78827

Files:
  clang/docs/LanguageExtensions.rst
  clang/include/clang/Basic/DiagnosticParseKinds.td
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Basic/LangOptions.h
  clang/include/clang/Sema/Sema.h
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/lib/Parse/ParsePragma.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/test/CodeGen/fp-reassoc-pragma.cpp
  clang/test/Parser/pragma-fp-contract.c

Index: clang/test/Parser/pragma-fp-contract.c
===
--- clang/test/Parser/pragma-fp-contract.c
+++ clang/test/Parser/pragma-fp-contract.c
@@ -23,3 +23,18 @@
 // expected-error@+1 {{this pragma cannot appear in union declaration}}
 #pragma STDC FP_CONTRACT ON
 };
+
+float fp_reassoc_fail(float a, float b) {
+  // CHECK-LABEL: fp_reassoc_fail
+  // expected-error@+2{{'#pragma clang fp' can only appear at file scope or at the start of a compound statement}}
+  float c = a + b;
+#pragma clang fp reassoc(on)
+  return c - b;
+}
+
+float fp_reassoc_no_fast(float a, float b) {
+// CHECK-LABEL: fp_reassoc_no_fast
+// expected-error@+1{{unexpected argument 'fast' to '#pragma clang fp reassoc'; expected 'on' or 'off'}}
+#pragma clang fp reassoc(fast)
+  return a - b;
+}
Index: clang/test/CodeGen/fp-reassoc-pragma.cpp
===
--- /dev/null
+++ clang/test/CodeGen/fp-reassoc-pragma.cpp
@@ -0,0 +1,90 @@
+// RUN: %clang_cc1 -O3 -triple %itanium_abi_triple -emit-llvm -o - %s | FileCheck %s
+// Simple case
+float fp_reassoc_simple(float a, float b, float c) {
+// CHECK: _Z17fp_reassoc_simplefff
+// CHECK: %[[M:.+]] = fmul reassoc float %a, %b
+// CHECK-NEXT: fadd reassoc float %[[M]], %c
+#pragma clang fp reassoc(on)
+  return a * b + c;
+}
+
+// Reassoc pragma should only apply to its scope
+float fp_reassoc_scoped(float a, float b, float c) {
+  // CHECK: _Z17fp_reassoc_scopedfff
+  // CHECK: %[[M:.+]] = fmul float %a, %b
+  // CHECK-NEXT: fadd float %[[M]], %c
+  {
+#pragma clang fp reassoc(on)
+  }
+  return a * b + c;
+}
+
+// Reassoc pragma should apply to templates as well
+class Foo {};
+Foo operator+(Foo, Foo);
+template 
+T template_reassoc(T a, T b, T c) {
+#pragma clang fp reassoc(on)
+  return ((a + b) - c) + c;
+}
+
+float fp_reassoc_template(float a, float b, float c) {
+  // CHECK: _Z19fp_reassoc_templatefff
+  // CHECK: %[[A1:.+]] = fadd reassoc float %a, %b
+  // CHECK-NEXT: %[[A2:.+]] = fsub reassoc float %[[A1]], %c
+  // CHECK-NEXT: fadd reassoc float %[[A2]], %c
+  return template_reassoc(a, b, c);
+}
+
+// File Scoping should work across functions
+#pragma clang fp reassoc(on)
+float fp_file_scope_on(float a, float b, float c) {
+  // CHECK: _Z16fp_file_scope_onfff
+  // CHECK: %[[M1:.+]] = fmul reassoc float %a, %c
+  // CHECK-NEXT: %[[M2:.+]] = fmul reassoc float %b, %c
+  // CHECK-NEXT: fadd reassoc float %[[M1]], %[[M2]]
+  return (a * c) + (b * c);
+}
+
+// Inner pragma has precedence
+float fp_file_scope_stop(float a, float b, float c) {
+  // CHECK: _Z18fp_file_scope_stopfff
+  // CHECK: %[[A:.+]] = fadd reassoc float %a, %a
+  // CHECK: %[[M1:.+]] = fmul float %[[A]], %c
+  // CHECK-NEXT: %[[M2:.+]] = fmul float %b, %c
+  // CHECK-NEXT: fsub float %[[M1]], %[[M2]]
+  a = a + a;
+  {
+#pragma clang fp reassoc(off)
+return (a * c) - (b * c);
+  }
+}
+
+#pragma clang fp reassoc(off)
+float fp_reassoc_off(float a, float b, float c) {
+  // CHECK: _Z14fp_reassoc_of
+  // CHECK: %[[D1:.+]] = fdiv float %a, %c
+  // CHECK-NEXT: %[[D2:.+]] = fdiv float %b, %c
+  // CHECK-NEXT: fadd float %[[D1]], %[[D2]]
+  return (a / c) + (b / c);
+}
+
+// Takes latest flag
+float fp_reassoc_many(float a, float b, float c) {
+// CHECK: _Z15fp_reassoc_manyfff
+// CHECK: %[[D1:.+]] = fdiv reassoc float %a, %c
+// CHECK-NEXT: %[[D2:.+]] = fdiv reassoc float %b, %c
+// CHECK-NEXT: fadd reassoc float %[[D1]], %[[D2]]
+#pragma clang fp reassoc(off) reassoc(on)
+  return (a / c) + (b / c);
+}
+
+// Pragma does not propagate through called functions
+float helper_func(float a, float b, float c) { return a + b + c; }
+float fp_reassoc_call_helper(float a, float b, float c) {
+// CHECK: _Z22fp_reassoc_call_helperfff
+// CHECK: %[[S1:.+]] = fadd float %a, %b
+// CHECK-NEXT: fadd float %[[S1]], %c
+#pragma clang fp reassoc(on)
+  return helper_func(a, b, c);
+}
Index: clang/lib/Sema/SemaAttr.cpp
===
--- clang/lib/Sema/SemaAttr.cpp
+++ clang/lib/Sema/SemaAttr.cpp
@@ -985,20 +985,33 @@
   }
 }
 
-void 

[PATCH] D78982: [clang-format] Fix Microsoft style for enums

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay requested changes to this revision.
MyDeveloperDay added a comment.
This revision now requires changes to proceed.

Sorry please adjust the patch to remove the un-related changes


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

https://reviews.llvm.org/D78982



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

[PATCH] D76932: [AIX] emit .extern and .weak directive linkage

[Hubert Tong via Phabricator via cfe-commits]

hubert.reinterpretcast accepted this revision.
hubert.reinterpretcast added a comment.

LGTM with minor comment.




Comment at: llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp:2143
+  case GlobalValue::AvailableExternallyLinkage:
+report_fatal_error("Unhandled AvailableExternallyLinkage when mapping "
+   "linkage to StorageClass");

The beginning of `report_fatal_error` messages should not be capitalized in the 
style of a sentence.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76932



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

[PATCH] D78982: [clang-format] Fix Microsoft style for enums

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added inline comments.



Comment at: clang/lib/Format/Format.cpp:1143
   Style.PenaltyReturnTypeOnItsOwnLine = 1000;
+  Style.AllowShortEnumsOnASingleLine = (Language != FormatStyle::LK_Cpp);
   Style.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_None;

asmith wrote:
> MyDeveloperDay wrote:
> > asmith wrote:
> > > MyDeveloperDay wrote:
> > > > I think its ok to leave it was, just if up the unit tests
> > > > 
> > > > (the fact you didn't see this suggests you are not running the unit 
> > > > tests please ensure you are)
> > > You need to use the latest changes. The is only applied when the style is 
> > > Msft and C++. See the GetMicrosoftStyle() method.
> > I don't think you should change the style based on the language here, 
> > either on or off, but not changing based on language because what about 
> > "ObjectiveC"?
> > 
> > As I added the Microsoft style to allow C# development I think its ok to 
> > set this to what you originally had, but fix up the tests
> Ive enabled this for C#. I don't see the connection between ObjectiveC and 
> Microsoft Style.
The Microsoft style was a style we added to try and give us a unique style to 
setup for C#, but that wouldn't stop a user for using it for other languages

Saying that you want a style for C++ but not other C based languges feels a 
little odd

Its perfectly acceptable for someone using Objective-C to use the BasedOnStyle 
of Microsoft

as such I think its better for a style to have a set default, then let users 
modify from the default.




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

https://reviews.llvm.org/D78982



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

Re: [PATCH] D78853: [Analysis] Fix null pointer dereference warnings [1/n]

[Mandeep Singh Grang via cfe-commits]

My previous email details why we are doing this:
http://lists.llvm.org/pipermail/llvm-dev/2020-April/141167.html
Basically, we ran the PREfast static analysis tool on LLVM/Clang and it
reported a lot of warnings. I guess some of them are false positives after
all.

As David suggests that maybe I should validate these warnings by also
running the clang static analyzer. There are a lot of other warnings
reported by the tool. Here is the full list:
https://docs.google.com/spreadsheets/d/1h_3tHxsgBampxb7PXoB5lgwiBSpTty9RLe5maIQxnTk/edit?usp=sharing.
If the community is interested in getting those fixed I can upstream
patches.

--Mandeep

On Tue, Apr 28, 2020 at 10:44 AM Aaron Puchert via Phabricator <
revi...@reviews.llvm.org> wrote:

> aaronpuchert added a comment.
>
> Could you explain why we are doing this? Clang has its own static analyzer
> , which can find null dereferences <
> https://clang.llvm.org/docs/analyzer/checkers.html#core-nulldereference-c-c-objc>
> as well but also tracks constraints to prevent false positives like this.
>
> There is a page somewhere with current analysis runs on LLVM, although I
> can't find it right now.
>
>
>
> 
> Comment at: clang/lib/Analysis/ThreadSafety.cpp:1938-1940
> +// The default value for the argument VD to the current function is
> +// nullptr. So we assert that VD is non null because we deref VD here.
> +assert(VD && "!VD");
> 
> dblaikie wrote:
> > Doesn't seem like the most informative comment or assertion string - the
> invariant  "isScopedVar implies VD is non-null" is established earlier in
> the function, where isScopedVar only becomes true under the "VD is
> non-null" condition at 1809.
> >
> > Would it be better to improve whatever static analysis you're using to
> be able to track that correlation, rather than adding lots of extra
> assertions to LLVM? (can the Clang Static Analyzer understand this code and
> avoid warning on it, for instance - that'd be a good existence proof for
> such "smarts" being reasonably possible for static analysis)
> I haven't tested it, but the Clang static analyzer shouldn't complain
> here. It explores different code paths and collects constraints along them.
> All code paths including the assignment `isScopedVar = true` should have
> `VD` being non-null as constraint, because that's the condition to get
> there.
>
> I know that solving constraints can be hard in general, but here the
> constraint is exactly what we need to disprove null references from
> happening.
>
>
> CHANGES SINCE LAST ACTION
>   https://reviews.llvm.org/D78853/new/
>
> https://reviews.llvm.org/D78853
>
>
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D74813: [RFC] Add hash of block contents to function block names

[Alex Borcan via Phabricator via cfe-commits]

alexbdv added a comment.

@dexonsmith what regression are you referring to ? 
What this change is effectively doing now is changing the numbering of the 
blocks from incremental to hash-based.
So the demangler functionality remains the same (i think) - I saw that it is 
ignoring the (currently incrememntal) number, so changing it shouldn't make a 
difference.
Did I miss anything ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74813



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

[PATCH] D78756: [SveEmitter] Add builtins for svreinterpret

[Sander de Smalen via Phabricator via cfe-commits]

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



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:7880
+return Builder.CreateBitCast(Val, Ty);
+  }
+

efriedma wrote:
> sdesmalen wrote:
> > efriedma wrote:
> > > I'm vaguely suspicious this might be wrong for big-endian targets.  I 
> > > mean, this isn't unreasonable, but users might be surprised if 
> > > svreinterpret isn't a no-op.
> > For SVE the loads and stores (svld1 and svst1) are all endian safe, so no 
> > special consideration needs to be taken for big endian targets.
> > 
> > The ACLE specifies that:
> > > The svreinterpret functions simply reinterpret a vector of one type as a 
> > > vector of another type, without changing any of the bits.
> "bitcast" is specified to mean "reinterpret the bits like a store+load".  On 
> big-endian NEON (and, I assume, SVE), that isn't a no-op.  See 
> http://llvm.org/docs/BigEndianNEON.html .
> 
> I mean, if the answer here is "yes, svreinterpret is supposed to lower to a 
> REV", then that's fine.  But I'd like to see some explciit acknowledgement 
> that that's intentional.
Thanks for pointing out that page, but for SVE I don't think the svreinterpret 
should lower to a REV.

This is probably where things are different from Neon. The ACLE SVE vectors 
such as `svint32_t` are opaque vector types and the only way to load/store them 
from/to memory is through the use of the svld1 and svst1 intrinsics which are 
endian safe (in that they use the ld1/st1 instructions that do endianess 
conversion on big endian targets). The ACLE does not expose any full-vector 
load/store (ldr/str) operations.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78756



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

[PATCH] D79014: [clangd] Move non-clang base pieces into separate support/ lib.

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

In D79014#2011034 , @sammccall wrote:

> I think there's more, just running a local shared build so I can catch them 
> (I should really have done this ahead of time).


OK, this now builds for me in shared mode after 
e7a7deb60ab0ee4ccd9e1f0de8e164b615344ae2 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79014



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

[PATCH] D78762: build: use `find_package(Python3)` if available

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

I attempted a fix in e071ea48e923651ae21b9b684b0473248630322c 



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78762



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

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

Alright then, I've disabled by default(911add149af563a5a61458de0dd730e3f5348623 
). I'll 
enable 1 at a time as I fix the calling conventions in D79118 
.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78785



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

[PATCH] D79014: [clangd] Move non-clang base pieces into separate support/ lib.

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

I think there's more, just running a local shared build so I can catch them (I 
should really have done this ahead of time).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79014



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

[clang] 911add1 - Disable _ExtInt by default

[Erich Keane via cfe-commits]

Author: Erich Keane
Date: 2020-04-29T13:48:12-07:00
New Revision: 911add149af563a5a61458de0dd730e3f5348623

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

LOG: Disable _ExtInt by default

Since the _ExtInt type got into the repo, we've discovered that the ABI
implications weren't completely understood. The other architectures are
going to be audited (see D79118), however downstream targets aren't
going to benefit from this audit.

This patch disables the _ExtInt type by default and makes the
target-info an opt-in.  As it is audited, I'll re-enable these for all
of our default targets.

Added: 
clang/test/Sema/ext-int-not-supported.c

Modified: 
clang/include/clang/Basic/TargetInfo.h
clang/lib/Basic/Targets/X86.h
clang/lib/Sema/SemaType.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/TargetInfo.h 
b/clang/include/clang/Basic/TargetInfo.h
index ab4795404071..910a4d6846aa 100644
--- a/clang/include/clang/Basic/TargetInfo.h
+++ b/clang/include/clang/Basic/TargetInfo.h
@@ -547,6 +547,12 @@ class TargetInfo : public virtual TransferrableTargetInfo,
 return (getPointerWidth(0) >= 64) || getTargetOpts().ForceEnableInt128;
   } // FIXME
 
+  /// Determine whether the _ExtInt type is supported on this target. This
+  /// limitation is put into place for ABI reasons.
+  virtual bool hasExtIntType() const {
+return false;
+  }
+
   /// Determine whether _Float16 is supported on this target.
   virtual bool hasLegalHalfType() const { return HasLegalHalfType; }
 

diff  --git a/clang/lib/Basic/Targets/X86.h b/clang/lib/Basic/Targets/X86.h
index a68109a604d5..39ccac96a49d 100644
--- a/clang/lib/Basic/Targets/X86.h
+++ b/clang/lib/Basic/Targets/X86.h
@@ -435,6 +435,8 @@ class LLVM_LIBRARY_VISIBILITY X86_32TargetInfo : public 
X86TargetInfo {
   }
 
   ArrayRef getTargetBuiltins() const override;
+
+  bool hasExtIntType() const override { return true; }
 };
 
 class LLVM_LIBRARY_VISIBILITY NetBSDI386TargetInfo
@@ -737,6 +739,8 @@ class LLVM_LIBRARY_VISIBILITY X86_64TargetInfo : public 
X86TargetInfo {
   }
 
   ArrayRef getTargetBuiltins() const override;
+
+  bool hasExtIntType() const override { return true; }
 };
 
 // x86-64 Windows target

diff  --git a/clang/lib/Sema/SemaType.cpp b/clang/lib/Sema/SemaType.cpp
index a96e1c1e6572..338e33589b1d 100644
--- a/clang/lib/Sema/SemaType.cpp
+++ b/clang/lib/Sema/SemaType.cpp
@@ -1443,6 +1443,9 @@ static QualType ConvertDeclSpecToType(TypeProcessingState 
) {
 break;
   }
   case DeclSpec::TST_extint: {
+if (!S.Context.getTargetInfo().hasExtIntType())
+  S.Diag(DS.getTypeSpecTypeLoc(), diag::err_type_unsupported)
+<< "_ExtInt";
 Result = S.BuildExtIntType(DS.getTypeSpecSign() == TSS_unsigned,
DS.getRepAsExpr(), DS.getBeginLoc());
 if (Result.isNull()) {

diff  --git a/clang/test/Sema/ext-int-not-supported.c 
b/clang/test/Sema/ext-int-not-supported.c
new file mode 100644
index ..23610b9941e4
--- /dev/null
+++ b/clang/test/Sema/ext-int-not-supported.c
@@ -0,0 +1,5 @@
+// RUN: %clang_cc1 -triple armv7 -fsyntax-only -verify %s
+
+void foo() {
+  _ExtInt(33) a; // expected-error{{_ExtInt is not supported on this target}}
+}



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

[clang-tools-extra] e7a7deb - [clangd] Fix BUILD_SHARED_LIBS build more.

[Sam McCall via cfe-commits]

Author: Sam McCall
Date: 2020-04-29T22:46:41+02:00
New Revision: e7a7deb60ab0ee4ccd9e1f0de8e164b615344ae2

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

LOG: [clangd] Fix BUILD_SHARED_LIBS build more.

Added: 


Modified: 
clang-tools-extra/clangd/fuzzer/CMakeLists.txt
clang-tools-extra/clangd/tool/CMakeLists.txt

Removed: 




diff  --git a/clang-tools-extra/clangd/fuzzer/CMakeLists.txt 
b/clang-tools-extra/clangd/fuzzer/CMakeLists.txt
index 90379822ac66..778b61158304 100644
--- a/clang-tools-extra/clangd/fuzzer/CMakeLists.txt
+++ b/clang-tools-extra/clangd/fuzzer/CMakeLists.txt
@@ -24,4 +24,5 @@ clang_target_link_libraries(clangd-fuzzer
 target_link_libraries(clangd-fuzzer
   PRIVATE
   clangDaemon
+  clangdSupport
   )

diff  --git a/clang-tools-extra/clangd/tool/CMakeLists.txt 
b/clang-tools-extra/clangd/tool/CMakeLists.txt
index b81f90a23b78..3368013f5079 100644
--- a/clang-tools-extra/clangd/tool/CMakeLists.txt
+++ b/clang-tools-extra/clangd/tool/CMakeLists.txt
@@ -32,5 +32,6 @@ target_link_libraries(clangd
   PRIVATE
   clangTidy
   clangDaemon
+  clangdSupport
   ${CLANGD_XPC_LIBS}
   )



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

[PATCH] D74813: [RFC] Add hash of block contents to function block names

[Duncan P. N. Exon Smith via Phabricator via cfe-commits]

dexonsmith added a comment.

In D74813#2010859 , @erik.pilkington 
wrote:

> In D74813#2010767 , @alexbdv wrote:
>
> > @erik.pilkington would the hash-based numbering be OK for now ?
>
>
> Feel free to drop the demangler changes for now, but I would prefer including 
> the output of the mangled type in the symbol rather than it's hash.


Dropping the demangler changes will introduce a regression for demangling 
blocks... I don't think we should do that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74813



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

[PATCH] D76932: [AIX] emit .extern and .weak directive linkage

[Digger via Phabricator via cfe-commits]

DiggerLin updated this revision to Diff 261004.
DiggerLin marked an inline comment as done.
DiggerLin added a comment.

take out the functionality  of "remove -u from clang"


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76932

Files:
  llvm/include/llvm/MC/MCAsmInfo.h
  llvm/include/llvm/MC/MCDirectives.h
  llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
  llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
  llvm/lib/MC/MCAsmInfoXCOFF.cpp
  llvm/lib/MC/MCAsmStreamer.cpp
  llvm/lib/MC/MCXCOFFStreamer.cpp
  llvm/lib/MC/XCOFFObjectWriter.cpp
  llvm/lib/Target/PowerPC/PPCAsmPrinter.cpp
  llvm/test/CodeGen/PowerPC/aix-LinkOnceAnyLinkage.ll
  llvm/test/CodeGen/PowerPC/aix-LinkOnceODRLinkage.ll
  llvm/test/CodeGen/PowerPC/aix-WeakODRLinkage.ll
  llvm/test/CodeGen/PowerPC/aix-extern-weak.ll
  llvm/test/CodeGen/PowerPC/aix-extern.ll
  llvm/test/CodeGen/PowerPC/aix-reference-func-addr-const.ll
  llvm/test/CodeGen/PowerPC/aix-weak.ll
  llvm/test/CodeGen/PowerPC/aix-xcoff-reloc.ll

Index: llvm/test/CodeGen/PowerPC/aix-xcoff-reloc.ll
===
--- llvm/test/CodeGen/PowerPC/aix-xcoff-reloc.ll
+++ llvm/test/CodeGen/PowerPC/aix-xcoff-reloc.ll
@@ -36,7 +36,7 @@
 ; OBJ-NEXT:   NumberOfSections: 2
 ; OBJ-NEXT:   TimeStamp: None (0x0)
 ; OBJ-NEXT:   SymbolTableOffset: 0x13C
-; OBJ-NEXT:   SymbolTableEntries: 24
+; OBJ-NEXT:   SymbolTableEntries: 26
 ; OBJ-NEXT:   OptionalHeaderSize: 0x0
 ; OBJ-NEXT:   Flags: 0x0
 ; OBJ-NEXT: }
@@ -86,7 +86,7 @@
 ; RELOC-NEXT:   }
 ; RELOC-NEXT:   Relocation {
 ; RELOC-NEXT: Virtual Address: 0x1A
-; RELOC-NEXT: Symbol: globalA (20)
+; RELOC-NEXT: Symbol: globalA (22)
 ; RELOC-NEXT: IsSigned: No
 ; RELOC-NEXT: FixupBitValue: 0
 ; RELOC-NEXT: Length: 16
@@ -94,7 +94,7 @@
 ; RELOC-NEXT:   }
 ; RELOC-NEXT:   Relocation {
 ; RELOC-NEXT: Virtual Address: 0x1E
-; RELOC-NEXT: Symbol: globalB (22)
+; RELOC-NEXT: Symbol: globalB (24)
 ; RELOC-NEXT: IsSigned: No
 ; RELOC-NEXT: FixupBitValue: 0
 ; RELOC-NEXT: Length: 16
@@ -104,7 +104,7 @@
 ; RELOC-NEXT: Section (index: 2) .data {
 ; RELOC-NEXT: Relocation {
 ; RELOC-NEXT:   Virtual Address: 0x70
-; RELOC-NEXT:   Symbol: arr (12)
+; RELOC-NEXT:   Symbol: arr (14)
 ; RELOC-NEXT:   IsSigned: No
 ; RELOC-NEXT:   FixupBitValue: 0
 ; RELOC-NEXT:   Length: 32
@@ -112,7 +112,7 @@
 ; RELOC-NEXT: }
 ; RELOC-NEXT: Relocation {
 ; RELOC-NEXT:   Virtual Address: 0x74
-; RELOC-NEXT:   Symbol: .foo (4)
+; RELOC-NEXT:   Symbol: .foo (6)
 ; RELOC-NEXT:   IsSigned: No
 ; RELOC-NEXT:   FixupBitValue: 0
 ; RELOC-NEXT:   Length: 32
@@ -120,7 +120,7 @@
 ; RELOC-NEXT: }
 ; RELOC-NEXT: Relocation {
 ; RELOC-NEXT:   Virtual Address: 0x78
-; RELOC-NEXT:   Symbol: TOC (18)
+; RELOC-NEXT:   Symbol: TOC (20)
 ; RELOC-NEXT:   IsSigned: No
 ; RELOC-NEXT:   FixupBitValue: 0
 ; RELOC-NEXT:   Length: 32
@@ -128,7 +128,7 @@
 ; RELOC-NEXT: }
 ; RELOC-NEXT: Relocation {
 ; RELOC-NEXT:   Virtual Address: 0x80
-; RELOC-NEXT:   Symbol: globalA (8)
+; RELOC-NEXT:   Symbol: globalA (10)
 ; RELOC-NEXT:   IsSigned: No
 ; RELOC-NEXT:   FixupBitValue: 0
 ; RELOC-NEXT:   Length: 32
@@ -136,7 +136,7 @@
 ; RELOC-NEXT: }
 ; RELOC-NEXT: Relocation {
 ; RELOC-NEXT:   Virtual Address: 0x84
-; RELOC-NEXT:   Symbol: globalB (10)
+; RELOC-NEXT:   Symbol: globalB (12)
 ; RELOC-NEXT:   IsSigned: No
 ; RELOC-NEXT:   FixupBitValue: 0
 ; RELOC-NEXT:   Length: 32
@@ -168,6 +168,26 @@
 ; SYM-NEXT:   }
 ; SYM-NEXT:   Symbol {
 ; SYM-NEXT: Index: 2
+; SYM-NEXT: Name: bar
+; SYM-NEXT: Value (RelocatableAddress): 0x0
+; SYM-NEXT: Section: N_UNDEF
+; SYM-NEXT: Type: 0x0
+; SYM-NEXT: StorageClass: C_EXT (0x2)
+; SYM-NEXT: NumberOfAuxEntries: 1
+; SYM-NEXT: CSECT Auxiliary Entry {
+; SYM-NEXT:   Index: 3
+; SYM-NEXT:   SectionLen: 0
+; SYM-NEXT:   ParameterHashIndex: 0x0
+; SYM-NEXT:   TypeChkSectNum: 0x0
+; SYM-NEXT:   SymbolAlignmentLog2: 0
+; SYM-NEXT:   SymbolType: XTY_ER (0x0)
+; SYM-NEXT:   StorageMappingClass: XMC_DS (0xA)
+; SYM-NEXT:   StabInfoIndex: 0x0
+; SYM-NEXT:   StabSectNum: 0x0
+; SYM-NEXT: }
+; SYM-NEXT:   }
+; SYM-NEXT:   Symbol {
+; SYM-NEXT: Index: 4
 ; SYM-NEXT: Name: .text
 ; SYM-NEXT: Value (RelocatableAddress): 0x0
 ; SYM-NEXT: Section: .text
@@ -175,7 +195,7 @@
 ; SYM-NEXT: StorageClass: C_HIDEXT (0x6B)
 ; SYM-NEXT: NumberOfAuxEntries: 1
 ; SYM-NEXT: CSECT Auxiliary Entry {
-; SYM-NEXT:   Index: 3
+; SYM-NEXT:   Index: 5
 ; SYM-NEXT:   SectionLen: 64
 ; SYM-NEXT:   ParameterHashIndex: 0x0
 ; SYM-NEXT:   TypeChkSectNum: 0x0
@@ -187,7 +207,7 @@
 ; SYM-NEXT: }
 ; SYM-NEXT:   }
 ; SYM-NEXT:   Symbol {
-; SYM-NEXT: Index: 4
+; SYM-NEXT: Index: 6
 ; SYM-NEXT: Name: .foo
 ; SYM-NEXT: Value (RelocatableAddress): 0x0
 ; SYM-NEXT: Section: .text
@@ -195,8 +215,8 @@
 ; SYM-NEXT: 

[PATCH] D78762: build: use `find_package(Python3)` if available

[Nico Weber via Phabricator via cfe-commits]

thakis added a comment.

I believe this breaks check-builtins on macOS. See 
https://bugs.chromium.org/p/chromium/issues/detail?id=1076480 for details.

The `split()` on the subprocess output throws since it wants a b'.' on py3, but 
that code has an unqualified except block. That means (I think) we always 
believe we run on macOS 10.0.0 under py3. I don't understand how we then fail 
to convert that back to an int (see linked bug).

Anyhoo, please take a look, and if it takes a while to fix we might have to go 
through yet another reland cycled :/

In D78762#2006872 , @compnerd wrote:

> I was trying to do the minimal change to cover llvm.  I definitely care about 
> LLD and will do that in a subsequent change.
>
> As to the benefit of this, it is primarily that the detection here explicitly 
> ensures that python3 is used rather than python2.  The fallback of aliasing 
> is the easiest way to achieve this without having a lot of complicated logic 
> at each site:
>
>   if(NOT Python3_Interpreter_FOUND)
> add_custom_command(...)
>   else()
> add_custom_command(...)
>   endif()


I would've expected we'd just set some new variable, eg LLVM_PYTHON_INTERPRETER 
to either the py2 or py3 interpreter and use that everywhere. Seems a bit less 
confusing, and shouldn't make anything else more complicated. But it's all 
going away in a few months anyways, so I don't have a strong opinion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78762



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

[PATCH] D79121: Add nomerge function attribute to clang

[Zequan Wu via Phabricator via cfe-commits]

zequanwu created this revision.
zequanwu added a reviewer: rnk.
zequanwu added a project: clang.
Herald added a subscriber: cfe-commits.

Related to D78659 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79121

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/lib/CodeGen/CGCall.cpp
  clang/test/CodeGen/attr-nomerge.c
  clang/test/Misc/pragma-attribute-supported-attributes-list.test


Index: clang/test/Misc/pragma-attribute-supported-attributes-list.test
===
--- clang/test/Misc/pragma-attribute-supported-attributes-list.test
+++ clang/test/Misc/pragma-attribute-supported-attributes-list.test
@@ -89,6 +89,7 @@
 // CHECK-NEXT: NoEscape (SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: NoInline (SubjectMatchRule_function)
 // CHECK-NEXT: NoInstrumentFunction (SubjectMatchRule_function)
+// CHECK-NEXT: NoMerge (SubjectMatchRule_function)
 // CHECK-NEXT: NoMicroMips (SubjectMatchRule_function)
 // CHECK-NEXT: NoMips16 (SubjectMatchRule_function)
 // CHECK-NEXT: NoSanitize (SubjectMatchRule_function, 
SubjectMatchRule_objc_method, SubjectMatchRule_variable_is_global)
Index: clang/test/CodeGen/attr-nomerge.c
===
--- /dev/null
+++ clang/test/CodeGen/attr-nomerge.c
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -S -emit-llvm %s -o - | FileCheck %s
+
+void bar() __attribute__((nomerge));
+
+void foo(int i) {
+if (i == 5) {
+bar();
+}
+else if (i == 7) {
+bar();
+}
+bar();
+}
+// CHECK: attributes #1 = { nomerge {{.*}} }
+// CHECK: attributes #2 = { nomerge }
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -1905,6 +1905,8 @@
   FuncAttrs.addAttribute(llvm::Attribute::NoDuplicate);
 if (TargetDecl->hasAttr())
   FuncAttrs.addAttribute(llvm::Attribute::Convergent);
+if (TargetDecl->hasAttr())
+  FuncAttrs.addAttribute(llvm::Attribute::NoMerge);
 
 if (const FunctionDecl *Fn = dyn_cast(TargetDecl)) {
   AddAttributesFromFunctionProtoType(
Index: clang/include/clang/Basic/AttrDocs.td
===
--- clang/include/clang/Basic/AttrDocs.td
+++ clang/include/clang/Basic/AttrDocs.td
@@ -350,6 +350,19 @@
   }];
 }
 
+def NoMergeDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+Calls to functions marked `nomerge` will not be merged during optimization.
+This attribute can be used to prevent the optimizer from obscuring the source
+location of certain calls. For example, it will prevent tail merging otherwise
+identical code sequences that raise an exception or terminate the program. Tail
+merging normally reduces the precision of source location information, making
+stack traces less useful for debugging. This attribute gives the user control
+over the tradeoff between code size and debug information precision.
+  }];
+}
+
 def AssertCapabilityDocs : Documentation {
   let Category = DocCatFunction;
   let Heading = "assert_capability, assert_shared_capability";
Index: clang/include/clang/Basic/Attr.td
===
--- clang/include/clang/Basic/Attr.td
+++ clang/include/clang/Basic/Attr.td
@@ -1794,6 +1794,13 @@
   let Documentation = [Undocumented];
 }
 
+def NoMerge : InheritableAttr {
+  let Spellings = [Clang<"nomerge">];
+  let Subjects = SubjectList<[Function]>;
+  let Documentation = [NoMergeDocs];
+  let SimpleHandler = 1;
+}
+
 def NoInstrumentFunction : InheritableAttr {
   let Spellings = [GCC<"no_instrument_function">];
   let Subjects = SubjectList<[Function]>;


Index: clang/test/Misc/pragma-attribute-supported-attributes-list.test
===
--- clang/test/Misc/pragma-attribute-supported-attributes-list.test
+++ clang/test/Misc/pragma-attribute-supported-attributes-list.test
@@ -89,6 +89,7 @@
 // CHECK-NEXT: NoEscape (SubjectMatchRule_variable_is_parameter)
 // CHECK-NEXT: NoInline (SubjectMatchRule_function)
 // CHECK-NEXT: NoInstrumentFunction (SubjectMatchRule_function)
+// CHECK-NEXT: NoMerge (SubjectMatchRule_function)
 // CHECK-NEXT: NoMicroMips (SubjectMatchRule_function)
 // CHECK-NEXT: NoMips16 (SubjectMatchRule_function)
 // CHECK-NEXT: NoSanitize (SubjectMatchRule_function, SubjectMatchRule_objc_method, SubjectMatchRule_variable_is_global)
Index: clang/test/CodeGen/attr-nomerge.c
===
--- /dev/null
+++ clang/test/CodeGen/attr-nomerge.c
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -S -emit-llvm %s -o - | FileCheck %s
+
+void bar() __attribute__((nomerge));
+
+void foo(int i) {
+if (i == 5) {
+bar();
+}
+else if (i == 7) {
+

[PATCH] D71227: [cuda][hip] Fix function overload resolution in the global initiailizer.

[Michael Liao via Phabricator via cfe-commits]

hliao updated this revision to Diff 261003.
hliao added a comment.

Rebase to trunk and resolve the conflict.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D71227

Files:
  clang/include/clang/Sema/Sema.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Sema/SemaCUDA.cpp
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExprCXX.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/SemaCUDA/function-overload.cu
  clang/test/SemaCUDA/global-initializers-host.cu

Index: clang/test/SemaCUDA/global-initializers-host.cu
===
--- clang/test/SemaCUDA/global-initializers-host.cu
+++ clang/test/SemaCUDA/global-initializers-host.cu
@@ -6,12 +6,14 @@
 // module initializer.
 
 struct S {
+  // expected-note@-1 {{candidate constructor (the implicit copy constructor) not viable: requires 1 argument, but 0 were provided}}
+  // expected-note@-2 {{candidate constructor (the implicit move constructor) not viable: requires 1 argument, but 0 were provided}}
   __device__ S() {}
-  // expected-note@-1 {{'S' declared here}}
+  // expected-note@-1 {{candidate constructor not viable: call to __device__ function from __host__ function}}
 };
 
 S s;
-// expected-error@-1 {{reference to __device__ function 'S' in global initializer}}
+// expected-error@-1 {{no matching constructor for initialization of 'S'}}
 
 struct T {
   __host__ __device__ T() {}
@@ -19,14 +21,17 @@
 T t;  // No error, this is OK.
 
 struct U {
+  // expected-note@-1 {{candidate constructor (the implicit copy constructor) not viable: no known conversion from 'int' to 'const U' for 1st argument}}
+  // expected-note@-2 {{candidate constructor (the implicit move constructor) not viable: no known conversion from 'int' to 'U' for 1st argument}}
   __host__ U() {}
+  // expected-note@-1 {{candidate constructor not viable: requires 0 arguments, but 1 was provided}}
   __device__ U(int) {}
-  // expected-note@-1 {{'U' declared here}}
+  // expected-note@-1 {{candidate constructor not viable: call to __device__ function from __host__ function}}
 };
 U u(42);
-// expected-error@-1 {{reference to __device__ function 'U' in global initializer}}
+// expected-error@-1 {{no matching constructor for initialization of 'U'}}
 
 __device__ int device_fn() { return 42; }
-// expected-note@-1 {{'device_fn' declared here}}
+// expected-note@-1 {{candidate function not viable: call to __device__ function from __host__ function}}
 int n = device_fn();
-// expected-error@-1 {{reference to __device__ function 'device_fn' in global initializer}}
+// expected-error@-1 {{no matching function for call to 'device_fn'}}
Index: clang/test/SemaCUDA/function-overload.cu
===
--- clang/test/SemaCUDA/function-overload.cu
+++ clang/test/SemaCUDA/function-overload.cu
@@ -214,8 +214,10 @@
 // Test for address of overloaded function resolution in the global context.
 HostFnPtr fp_h = h;
 HostFnPtr fp_ch = ch;
+#if !defined(__CUDA_ARCH__)
 CurrentFnPtr fp_dh = dh;
 CurrentFnPtr fp_cdh = cdh;
+#endif
 GlobalFnPtr fp_g = g;
 
 
@@ -463,3 +465,29 @@
 void foo() {
   __test();
 }
+
+// Overload resolution in the global initialization should follow the same rule
+// as the one in other places. That is, we prefer a callable function over a
+// non-callable function with a better signature match. In this test case, even
+// though the device function has exactly matching with the integer argument,
+// it can't be executed.
+
+__device__ float fn(int);
+__host__ float fn(float);
+
+float gvar1 = fn(1);
+
+__device__ float dev_only_fn(int);
+// expected-note@-1 {{candidate function not viable: call to __device__ function from __host__ function}}
+
+float gvar2 = dev_only_fn(1); // expected-error {{no matching function for call to 'dev_only_fn'}}
+
+#ifdef __CUDA_ARCH__
+__device__ DeviceReturnTy gvar3 = template_vs_function(1.f);
+// expected-error@-1 {{dynamic initialization is not supported for __device__, __constant__, and __shared__ variables.}}
+__device__ int gvar4 = template_overload(1);
+// expected-error@-1 {{dynamic initialization is not supported for __device__, __constant__, and __shared__ variables.}}
+#else
+TemplateReturnTy gvar3 = template_vs_function(2.f);
+int gvar4 = template_overload(1);
+#endif
Index: clang/lib/Sema/SemaOverload.cpp
===
--- clang/lib/Sema/SemaOverload.cpp
+++ clang/lib/Sema/SemaOverload.cpp
@@ -6302,17 +6302,12 @@
   }
 
   // (CUDA B.1): Check for invalid calls between targets.
-  if (getLangOpts().CUDA)
-if (const FunctionDecl *Caller = dyn_cast(CurContext))
-  // Skip the check for callers that are implicit members, because in this
-  // case we may not yet know what the member's target is; the target is
-  // inferred for the member automatically, based on the bases and fields of
-

[PATCH] D79014: [clangd] Move non-clang base pieces into separate support/ lib.

[Kirill Bobyrev via Phabricator via cfe-commits]

kbobyrev added a comment.

Ah, sorry, stale tab :(


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79014



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

[PATCH] D79014: [clangd] Move non-clang base pieces into separate support/ lib.

[Kirill Bobyrev via Phabricator via cfe-commits]

kbobyrev added a comment.

In D79014#2010746 , @jsji wrote:

> Looks like this is causing buildbot failure when built with 
> `-DBUILD_SHARED_LIBS=ON`.
>  
> http://lab.llvm.org:8011/builders/clang-ppc64le-rhel/builds/3077/steps/build%20stage%201/logs/stdio
>
>   FAILED: lib/libclangDaemon.so.11git 
>   : && /home/buildbots/clang.9.0.0/bin/clang++ -... && :
>   
> tools/clang/tools/extra/clangd/CMakeFiles/obj.clangDaemon.dir/CodeComplete.cpp.o:(.toc+0x120):
>  undefined reference to `pthread_create'
>   clang++: error: linker command failed with exit code 1 (use -v to see 
> invocation)
>


Thanks! Fixed in 
https://github.com/llvm/llvm-project/commit/bc029fa6c5cdc28fa2087f721e5ffe27d9b24ecd


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79014



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

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

See my audit/WIP on calling conventions here: https://reviews.llvm.org/D79118


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78785



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

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

In D78785#2010738 , @erichkeane wrote:

> In D78785#2010654 , @rjmccall wrote:
>
> > Every target does something similar, they just all do it in different ways 
> > because they're mostly written by different people.
> >
> > We should restrict this feature to targets where we've adequately audited 
> > the ABI.  It's not a feature until the ABI work is done.
>
>
> I'm discovering that now :)  I'm currently trying to do said audit by going 
> down the ABIInfo inheritance tree.  I believe we have at least a month until 
> the next release branch date.  If you can help keep me honest here, I'll 
> disable _ExtInt for any platforms I haven't done by then at the branch.
>
> Does that seem acceptable?


Yes, although, I think you ought to flip the default anyway just so we're doing 
the right thing for out-of-tree targets.  It should then be very 
straightforward to flip it back target-by-target as you do your audit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78785



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

[PATCH] D74813: [RFC] Add hash of block contents to function block names

[Erik Pilkington via Phabricator via cfe-commits]

erik.pilkington edited reviewers, added: rjmccall; removed: libc++abi.
erik.pilkington added a comment.

In D74813#2010767 , @alexbdv wrote:

> @erik.pilkington would the hash-based numbering be OK for now ?


Feel free to drop the demangler changes for now, but I would prefer including 
the output of the mangled type in the symbol rather than it's hash.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74813



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

[PATCH] D79014: [clangd] Move non-clang base pieces into separate support/ lib.

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

In D79014#2010746 , @jsji wrote:

> Looks like this is causing buildbot failure when built with 
> `-DBUILD_SHARED_LIBS=ON`.
>  
> http://lab.llvm.org:8011/builders/clang-ppc64le-rhel/builds/3077/steps/build%20stage%201/logs/stdio
>
>   FAILED: lib/libclangDaemon.so.11git 
>   : && /home/buildbots/clang.9.0.0/bin/clang++ -... && :
>   
> tools/clang/tools/extra/clangd/CMakeFiles/obj.clangDaemon.dir/CodeComplete.cpp.o:(.toc+0x120):
>  undefined reference to `pthread_create'
>   clang++: error: linker command failed with exit code 1 (use -v to see 
> invocation)
>


Thanks, bc029fa6c5cdc28fa2087f721e5ffe27d9b24ecd 
 should 
fix this.
Will keep an eye on it (didn't get mail last time, maybe it was already broken).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79014



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

[PATCH] D79117: [clang] [Darwin] Add reverse mappings for aarch64/aarch64_32 to darwin arch names

[Martin Storsjö via Phabricator via cfe-commits]

mstorsjo created this revision.
mstorsjo added a reviewer: t.p.northover.
Herald added subscribers: danielkiss, kristof.beyls.
Herald added a project: clang.

These are mapped in MachO::getMachOArchName already, but were missing in 
ToolChain::getDefaultUniversalArchName.

Having these reverse mapped here fixes weird inconsistencies like -dumpmachine 
showing a target triple like "aarch64-apple-darwin", while "clang -target 
aarch64-apple-darwin" didn't use to work (ended up mapped as unknown-apple-ios).


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79117

Files:
  clang/lib/Driver/ToolChain.cpp
  clang/test/Driver/darwin-arm64-target.c


Index: clang/test/Driver/darwin-arm64-target.c
===
--- /dev/null
+++ clang/test/Driver/darwin-arm64-target.c
@@ -0,0 +1,3 @@
+// RUN: %clang -target aarch64-apple-darwin %s -miphoneos-version-min=8.0 -### 
2>&1 | FileCheck %s
+
+// CHECK: "-cc1"{{.*}} "-triple" "arm64-apple-ios8.0.0"
Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -230,9 +230,12 @@
 StringRef ToolChain::getDefaultUniversalArchName() const {
   // In universal driver terms, the arch name accepted by -arch isn't exactly
   // the same as the ones that appear in the triple. Roughly speaking, this is
-  // an inverse of the darwin::getArchTypeForDarwinArchName() function, but the
-  // only interesting special case is powerpc.
+  // an inverse of the darwin::getArchTypeForDarwinArchName() function.
   switch (Triple.getArch()) {
+  case llvm::Triple::aarch64:
+return "arm64";
+  case llvm::Triple::aarch64_32:
+return "arm64_32";
   case llvm::Triple::ppc:
 return "ppc";
   case llvm::Triple::ppc64:


Index: clang/test/Driver/darwin-arm64-target.c
===
--- /dev/null
+++ clang/test/Driver/darwin-arm64-target.c
@@ -0,0 +1,3 @@
+// RUN: %clang -target aarch64-apple-darwin %s -miphoneos-version-min=8.0 -### 2>&1 | FileCheck %s
+
+// CHECK: "-cc1"{{.*}} "-triple" "arm64-apple-ios8.0.0"
Index: clang/lib/Driver/ToolChain.cpp
===
--- clang/lib/Driver/ToolChain.cpp
+++ clang/lib/Driver/ToolChain.cpp
@@ -230,9 +230,12 @@
 StringRef ToolChain::getDefaultUniversalArchName() const {
   // In universal driver terms, the arch name accepted by -arch isn't exactly
   // the same as the ones that appear in the triple. Roughly speaking, this is
-  // an inverse of the darwin::getArchTypeForDarwinArchName() function, but the
-  // only interesting special case is powerpc.
+  // an inverse of the darwin::getArchTypeForDarwinArchName() function.
   switch (Triple.getArch()) {
+  case llvm::Triple::aarch64:
+return "arm64";
+  case llvm::Triple::aarch64_32:
+return "arm64_32";
   case llvm::Triple::ppc:
 return "ppc";
   case llvm::Triple::ppc64:
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang-tools-extra] bc029fa - [clangd] Still need pthreads in clangDaemon.

[Sam McCall via cfe-commits]

Author: Sam McCall
Date: 2020-04-29T21:41:12+02:00
New Revision: bc029fa6c5cdc28fa2087f721e5ffe27d9b24ecd

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

LOG: [clangd] Still need pthreads in clangDaemon.

Added: 


Modified: 
clang-tools-extra/clangd/CMakeLists.txt

Removed: 




diff  --git a/clang-tools-extra/clangd/CMakeLists.txt 
b/clang-tools-extra/clangd/CMakeLists.txt
index 146f1b33599f..b8e179855b9d 100644
--- a/clang-tools-extra/clangd/CMakeLists.txt
+++ b/clang-tools-extra/clangd/CMakeLists.txt
@@ -114,6 +114,7 @@ add_clang_library(clangDaemon
   clangToolingRefactoring
   clangToolingSyntax
   clangdSupport
+  ${LLVM_PTHREAD_LIB}
   ${ALL_CLANG_TIDY_CHECKS}
   )
 



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

[PATCH] D79113: Revert "Remove false positive in AvoidNonConstGlobalVariables."

[Kim Viggedal via Phabricator via cfe-commits]

vingeldal created this revision.
Herald added subscribers: cfe-commits, kbarton, nemanjai.
Herald added a project: clang.
vingeldal added reviewers: aaron.ballman, lebedev.ri, JonasToth, gribozavr2.
Herald added a subscriber: wuzish.

There was concernes about a false positive in clang-tidy check
AvoidNonConstGlobalVariables after it was merged and a fix for
assumed false positive was submitted in:
https://reviews.llvm.org/D77461

There was also some discussion regarding if this was actually a
false positive or a true positive. An issue was submitted to the
C++ Core Guidelines asking for a clarification in the matter:
https://github.com/isocpp/CppCoreGuidelines/issues/1599

The answer from the C++ Core Guidelines project seems to go
against the previous assumption that this was a matter of a
false positive, so this patch is suggestion to revert the
previous fix of the assumed false positive.

This reverts commit b2d8c89ea48beb83e0392b1f00c9eafa33c09ca8 
.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79113

Files:
  
clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidNonConstGlobalVariablesCheck.cpp
  
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-avoid-non-const-global-variables.cpp


Index: 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-avoid-non-const-global-variables.cpp
===
--- 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-avoid-non-const-global-variables.cpp
+++ 
clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-avoid-non-const-global-variables.cpp
@@ -231,8 +231,7 @@
 // CHECKING AGAINST FALSE POSITIVES INSIDE FUNCTION SCOPE /
 int main() {
   for (int i = 0; i < 3; ++i) {
-static int staticNonConstLoopVariable = 42;
 int nonConstLoopVariable = 42;
-nonConstInt = nonConstLoopVariable + i + staticNonConstLoopVariable;
+nonConstInt = nonConstLoopVariable + i;
   }
 }
Index: 
clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidNonConstGlobalVariablesCheck.cpp
===
--- 
clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidNonConstGlobalVariablesCheck.cpp
+++ 
clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidNonConstGlobalVariablesCheck.cpp
@@ -17,15 +17,11 @@
 namespace tidy {
 namespace cppcoreguidelines {
 
-namespace {
-AST_MATCHER(VarDecl, isLocalVarDecl) { return Node.isLocalVarDecl(); }
-} // namespace
-
 void AvoidNonConstGlobalVariablesCheck::registerMatchers(MatchFinder *Finder) {
   auto GlobalVariable = varDecl(
   hasGlobalStorage(),
   unless(anyOf(
-  isLocalVarDecl(), isConstexpr(), hasType(isConstQualified()),
+  isConstexpr(), hasType(isConstQualified()),
   hasType(referenceType(); // References can't be changed, only the
// data they reference can be changed.
 


Index: clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-avoid-non-const-global-variables.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-avoid-non-const-global-variables.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/cppcoreguidelines-avoid-non-const-global-variables.cpp
@@ -231,8 +231,7 @@
 // CHECKING AGAINST FALSE POSITIVES INSIDE FUNCTION SCOPE /
 int main() {
   for (int i = 0; i < 3; ++i) {
-static int staticNonConstLoopVariable = 42;
 int nonConstLoopVariable = 42;
-nonConstInt = nonConstLoopVariable + i + staticNonConstLoopVariable;
+nonConstInt = nonConstLoopVariable + i;
   }
 }
Index: clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidNonConstGlobalVariablesCheck.cpp
===
--- clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidNonConstGlobalVariablesCheck.cpp
+++ clang-tools-extra/clang-tidy/cppcoreguidelines/AvoidNonConstGlobalVariablesCheck.cpp
@@ -17,15 +17,11 @@
 namespace tidy {
 namespace cppcoreguidelines {
 
-namespace {
-AST_MATCHER(VarDecl, isLocalVarDecl) { return Node.isLocalVarDecl(); }
-} // namespace
-
 void AvoidNonConstGlobalVariablesCheck::registerMatchers(MatchFinder *Finder) {
   auto GlobalVariable = varDecl(
   hasGlobalStorage(),
   unless(anyOf(
-  isLocalVarDecl(), isConstexpr(), hasType(isConstQualified()),
+  isConstexpr(), hasType(isConstQualified()),
   hasType(referenceType(); // References can't be changed, only the
// data they reference can be changed.
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D71124: [RISCV] support clang driver to select cpu

[Sam Elliott via Phabricator via cfe-commits]

lenary added a comment.
Herald added a project: LLVM.
Herald added a subscriber: llvm-commits.

This is looking good.

I remember we discussed this on the LLVM call a few weeks ago - there was a 
discussion as to whether we should be prioritising `-march` or `-mcpu` - do you 
recall the outcome of that discussion?




Comment at: clang/lib/Basic/Targets/RISCV.cpp:166
+bool RISCV32TargetInfo::isValidCPUName(StringRef Name) const {
+  return llvm::RISCV::checkCPUKind(llvm::RISCV::parseCPUKind(Name), false);
+}

It would be good to have `/*Is64Bit=*/` before the boolean arguments to these 
functions.



Comment at: clang/lib/Driver/ToolChains/Arch/RISCV.cpp:501-516
-  // 3. Choose a default based on the triple
-  //
-  // We deviate from GCC's defaults here:
-  // - On `riscv{XLEN}-unknown-elf` we use the integer calling convention only.
-  // - On all other OSs we use the double floating point calling convention.
-  if (Triple.getArch() == llvm::Triple::riscv32) {
-if (Triple.getOS() == llvm::Triple::UnknownOS)

What's the justification for removing this code?



Comment at: clang/lib/Driver/ToolChains/CommonArgs.cpp:310
+  case llvm::Triple::riscv64:
+if (const Arg *A = Args.getLastArg(options::OPT_mcpu_EQ))
+  return A->getValue();

Should we be doing more validation here?



Comment at: llvm/lib/Support/TargetParser.cpp:122
 
+struct CPUInfo {
+  StringLiteral Name;

I think this should be prefixed `RISCV`, or moved into the RISCV namespace if 
you can?



Comment at: llvm/lib/Support/TargetParser.cpp:259-260
+
+  if (features & FK_64BIT)
+Features.push_back("+64bit");
+

It might be worth explicitly adding `-64bit` where FK_64BIT is not set.


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

https://reviews.llvm.org/D71124



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

[PATCH] D79014: [clangd] Move non-clang base pieces into separate support/ lib.

[Jinsong Ji via Phabricator via cfe-commits]

jsji added a comment.
Herald added a subscriber: wuzish.

Looks like this is causing buildbot failure when built with 
`-DBUILD_SHARED_LIBS=ON`.
http://lab.llvm.org:8011/builders/clang-ppc64le-rhel/builds/3077/steps/build%20stage%201/logs/stdio

  FAILED: lib/libclangDaemon.so.11git 
  : && /home/buildbots/clang.9.0.0/bin/clang++ -... && :
  
tools/clang/tools/extra/clangd/CMakeFiles/obj.clangDaemon.dir/CodeComplete.cpp.o:(.toc+0x120):
 undefined reference to `pthread_create'
  clang++: error: linker command failed with exit code 1 (use -v to see 
invocation)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79014



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

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D78785#2010654 , @rjmccall wrote:

> Every target does something similar, they just all do it in different ways 
> because they're mostly written by different people.
>
> We should restrict this feature to targets where we've adequately audited the 
> ABI.  It's not a feature until the ABI work is done.


I'm discovering that now :)  I'm currently trying to do said audit by going 
down the ABIInfo inheritance tree.  I believe we have at least a month until 
the next release branch date.  If you can help keep me honest here, I'll 
disable _ExtInt for any platforms I haven't done by then at the branch.

Does that seem acceptable?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78785



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

[PATCH] D74813: [RFC] Add hash of block contents to function block names

[Alex Borcan via Phabricator via cfe-commits]

alexbdv added a comment.

@erik.pilkington would the hash-based numbering be OK for now ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D74813



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

[PATCH] D78979: OpenCL: Include builtin header by default

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In D78979#2010527 , @svenvh wrote:

> In D78979#2007643 , @Anastasia wrote:
>
> > > Would it not become confusing since the builtins are going to be included 
> > > by default? Should we rename the flag at least? Also ideally it should be 
> > > documented in https://clang.llvm.org/docs/UsersManual.html#opencl-header
> >
> > ah I guess if we leave it under `-cc1 ` we will have the command line 
> > interface as follows:
> >
> > - Driver (without `-cc1`) adds OpenCL header by default that can be 
> > overridden by the flag added in this patch.
> > - Frontend (with `-cc1`) doesn't add the header by default but there are 
> > two flags `-fdeclare-opencl-builtins` or `-finclude-default-header` that 
> > allow to include the header.
>
>
> The name of `-fdeclare-opencl-builtins` becomes a bit non-intuitive, a more 
> intuitive name would be something like `-fopencl-tablegen-builtins` perhaps 
> or `-fopencl-fast-builtins` if we don't want to mention TableGen.  But since 
> it is still an experimental option, I have no objections against postponing 
> the renaming until the option has reached maturity.


I vote for `-fopencl-fast-builtins`.


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

https://reviews.llvm.org/D78979



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

[PATCH] D78979: OpenCL: Include builtin header by default

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In D78979#2007760 , @yaxunl wrote:

> In D78979#2007643 , @Anastasia wrote:
>
> > ah I guess if we leave it under `-cc1 ` we will have the command line 
> > interface as follows:
> >
> > - Driver (without `-cc1`) adds OpenCL header by default that can be 
> > overridden by the flag added in this patch.
> > - Frontend (with `-cc1`) doesn't add the header by default but there are 
> > two flags `-fdeclare-opencl-builtins` or `-finclude-default-header` that 
> > allow to include the header.
> >
> >   Is my understanding correct? We should reflect this is the User Manual.
>
>
> I think -finclude-default-header -fno-include-default-header better becomes 
> both driver and -cc1 option since users are likely to use it with driver. It 
> may also be used with other languages e.g. HIP.


If we change `-finclude-default-header` to driver option, what would it do 
since the header is added by default?

Unless as @arsenm pointed out we want to get rid of custom OpenCL options and 
just use standard ones for C/C++...


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

https://reviews.llvm.org/D78979



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

[clang] b5a4dee - [NFC] Split ext-int calling convention tests into their own file.

[Erich Keane via cfe-commits]

Author: Erich Keane
Date: 2020-04-29T12:20:21-07:00
New Revision: b5a4deec6a70da8a1024a2227be66f88e9276b08

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

LOG: [NFC] Split ext-int calling convention tests into their own file.

I'm currently auditing all of the calling convention implications of
_ExtInt for all platforms, so splitting them up into their own test will
make this a much easier task to organize.

Added: 
clang/test/CodeGen/ext-int-cc.c

Modified: 
clang/test/CodeGen/ext-int.c

Removed: 




diff  --git a/clang/test/CodeGen/ext-int-cc.c b/clang/test/CodeGen/ext-int-cc.c
new file mode 100644
index ..41410be65497
--- /dev/null
+++ b/clang/test/CodeGen/ext-int-cc.c
@@ -0,0 +1,42 @@
+// RUN: %clang_cc1 -triple x86_64-gnu-linux -O3 -disable-llvm-passes 
-emit-llvm -o - %s | FileCheck %s --check-prefixes=LIN64
+// RUN: %clang_cc1 -triple x86_64-windows-pc -O3 -disable-llvm-passes 
-emit-llvm -o - %s | FileCheck %s --check-prefixes=WIN64
+// RUN: %clang_cc1 -triple i386-gnu-linux -O3 -disable-llvm-passes -emit-llvm 
-o - %s | FileCheck %s --check-prefixes=LIN32
+// RUN: %clang_cc1 -triple i386-windows-pc -O3 -disable-llvm-passes -emit-llvm 
-o - %s | FileCheck %s --check-prefixes=WIN32
+
+// Make sure 128 and 64 bit versions are passed like integers, and that >128
+// is passed indirectly.
+void ParamPassing(_ExtInt(129) a, _ExtInt(128) b, _ExtInt(64) c) {}
+// LIN64: define void @ParamPassing(i129* byval(i129) align 8 %{{.+}}, i64 
%{{.+}}, i64 %{{.+}}, i64 %{{.+}})
+// WIN64: define dso_local void @ParamPassing(i129* %{{.+}}, i128* %{{.+}}, 
i64 %{{.+}})
+// LIN32: define void @ParamPassing(i129* %{{.+}}, i128* %{{.+}}, i64 %{{.+}})
+// WIN32: define dso_local void @ParamPassing(i129* %{{.+}}, i128* %{{.+}}, 
i64 %{{.+}})
+void ParamPassing2(_ExtInt(129) a, _ExtInt(127) b, _ExtInt(63) c) {}
+// LIN64: define void @ParamPassing2(i129* byval(i129) align 8 %{{.+}}, i64 
%{{.+}}, i64 %{{.+}}, i64 %{{.+}})
+// WIN64: define dso_local void @ParamPassing2(i129* %{{.+}}, i127* %{{.+}}, 
i63 %{{.+}})
+// LIN32: define void @ParamPassing2(i129* %{{.+}}, i127* %{{.+}}, i63 %{{.+}})
+// WIN32: define dso_local void @ParamPassing2(i129* %{{.+}}, i127* %{{.+}}, 
i63 %{{.+}})
+_ExtInt(63) ReturnPassing(){}
+// LIN64: define i64 @ReturnPassing(
+// WIN64: define dso_local i63 @ReturnPassing(
+// LIN32: define i63 @ReturnPassing(
+// WIN32: define dso_local i63 @ReturnPassing(
+_ExtInt(64) ReturnPassing2(){}
+// LIN64: define i64 @ReturnPassing2(
+// WIN64: define dso_local i64 @ReturnPassing2(
+// LIN32: define i64 @ReturnPassing2(
+// WIN32: define dso_local i64 @ReturnPassing2(
+_ExtInt(127) ReturnPassing3(){}
+// LIN64: define { i64, i64 } @ReturnPassing3(
+// WIN64: define dso_local void @ReturnPassing3(i127* noalias sret
+// LIN32: define i127 @ReturnPassing3(
+// WIN32: define dso_local i127 @ReturnPassing3(
+_ExtInt(128) ReturnPassing4(){}
+// LIN64: define { i64, i64 } @ReturnPassing4(
+// WIN64: define dso_local void @ReturnPassing4(i128* noalias sret
+// LIN32: define i128 @ReturnPassing4(
+// WIN32: define dso_local i128 @ReturnPassing4(
+_ExtInt(129) ReturnPassing5(){}
+// LIN64: define void @ReturnPassing5(i129* noalias sret
+// WIN64: define dso_local void @ReturnPassing5(i129* noalias sret
+// LIN32: define i129 @ReturnPassing5(
+// WIN32: define dso_local i129 @ReturnPassing5(

diff  --git a/clang/test/CodeGen/ext-int.c b/clang/test/CodeGen/ext-int.c
index 8f90c0db27c7..196bb810b61a 100644
--- a/clang/test/CodeGen/ext-int.c
+++ b/clang/test/CodeGen/ext-int.c
@@ -1,8 +1,7 @@
-// RUN: %clang_cc1 -triple x86_64-gnu-linux -O3 -disable-llvm-passes 
-emit-llvm -o - %s | FileCheck %s --check-prefixes=CHECK,LIN64,CHECK64
-// RUN: %clang_cc1 -triple x86_64-windows-pc -O3 -disable-llvm-passes 
-emit-llvm -o - %s | FileCheck %s --check-prefixes=CHECK,WIN64,CHECK64
-// RUN: %clang_cc1 -triple i386-gnu-linux -O3 -disable-llvm-passes -emit-llvm 
-o - %s | FileCheck %s --check-prefixes=CHECK,LIN32,CHECK32
-// RUNX: %clang_cc1 -triple i386-windows-pc -O3 -disable-llvm-passes 
-emit-llvm -o - %s | FileCheck %s --check-prefixes=CHECK,WIN32,CHECK32
-
+// RUN: %clang_cc1 -triple x86_64-gnu-linux -O3 -disable-llvm-passes 
-emit-llvm -o - %s | FileCheck %s --check-prefixes=CHECK,CHECK64
+// RUN: %clang_cc1 -triple x86_64-windows-pc -O3 -disable-llvm-passes 
-emit-llvm -o - %s | FileCheck %s --check-prefixes=CHECK,CHECK64
+// RUN: %clang_cc1 -triple i386-gnu-linux -O3 -disable-llvm-passes -emit-llvm 
-o - %s | FileCheck %s --check-prefixes=CHECK,LIN32
+// RUN: %clang_cc1 -triple i386-windows-pc -O3 -disable-llvm-passes -emit-llvm 
-o - %s | FileCheck %s --check-prefixes=CHECK,WIN32
 
 void GenericTest(_ExtInt(3) a, unsigned _ExtInt(3) b, _ExtInt(4) c) {
   // CHECK: define 

[PATCH] D72841: Add support for pragma float_control, to control precision and exception behavior at the source level

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

2 small things, @rjmccall  and @sepavloff , anything else?




Comment at: clang/include/clang/Basic/DiagnosticSemaKinds.td:870
+def err_pragma_fenv_requires_precise : Error<
+  "'#pragma STDC FENV_ACCESS ON' is illegal when precise is disabled">;
 def warn_cxx_ms_struct :

The last 4 can be done via selects as well!  Save a couple more spaces before 
we have to up the diagnostic id size :) 




Comment at: clang/include/clang/Sema/Sema.h:558
 
+  // This stacks the current state of Sema.CurFPFeatures
+  PragmaStack FpPragmaStack;

erichkeane wrote:
> This comment is really oddly phrased and uses the 'stack'-noun as a verb?  
> Something like: (please feel free to wordsmith): "This stack tracks the 
> current state of Sema.CurFPFeatures."?
Just needs a period at the end.



Comment at: clang/lib/Parse/ParsePragma.cpp:2534
+  PP.Lex(Tok);
+  if (Tok.isNot(tok::l_paren)) {
+PP.Diag(FloatControlLoc, diag::err_expected) << tok::l_paren;

mibintc wrote:
> erichkeane wrote:
> > Replace this with BalancedDelimiterTracker instead, it gives consistent 
> > errors and are a bit easier to use.  Additionally, I think it does some 
> > fixups that allow us to recover better.
> > 
> > I'd also suggest some refactoring with the PragmaFloatControlKind if/elses 
> > below.  Perhaps handle the closing paren at the end, and do a switch-case 
> > for that handling.
> BalancedDelimiterTracker doesn't work here because there's no access to the 
> Parser object. Rewriting it would be an extensive change and I'm doubtful 
> about making this change. PragmaHandler is defined in Lex. I think there are 
> 60 pragma's that use the PragmaHandler. 
Thats unfortunate :/  That type does some nice fixup work.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72841



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

[PATCH] D79087: [SVE][Codegen] Lower legal min & max operations

[Eli Friedman via Phabricator via cfe-commits]

efriedma added a subscriber: huihuiz.
efriedma added inline comments.



Comment at: llvm/lib/Target/AArch64/SVEInstrFormats.td:3851
+  def : SVE_1_Op_Imm_Arith_Pred_Pat(NAME # _S)>;
+  def : SVE_1_Op_Imm_Arith_Pred_Pat(NAME # _D)>;
 }

I don't see any test for this part of the patch?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79087



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

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Every target does something similar, they just all do it in different ways 
because they're mostly written by different people.

We should restrict this feature to targets where we've adequately audited the 
ABI.  It's not a feature until the ABI work is done.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78785



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

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

[Erich Keane via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG5a1d9c0f5ac8: Fix x86/x86_64 calling convention for _ExtInt 
(authored by erichkeane).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78785

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGen/ext-int-sanitizer.cpp
  clang/test/CodeGen/ext-int.c
  clang/test/CodeGenCXX/ext-int.cpp

Index: clang/test/CodeGenCXX/ext-int.cpp
===
--- clang/test/CodeGenCXX/ext-int.cpp
+++ clang/test/CodeGenCXX/ext-int.cpp
@@ -98,7 +98,7 @@
 };
 
 void UnderlyingTypeUsage(AsEnumUnderlyingType Param) {
-  // LIN: define void @_Z19UnderlyingTypeUsage20AsEnumUnderlyingType(i9 %
+  // LIN: define void @_Z19UnderlyingTypeUsage20AsEnumUnderlyingType(i16 %
   // WIN: define dso_local void @"?UnderlyingTypeUsage@@YAXW4AsEnumUnderlyingType@@@Z"(i9 %
   AsEnumUnderlyingType Var;
   // CHECK: alloca i9, align 2
@@ -106,13 +106,13 @@
 }
 
 unsigned _ExtInt(33) ManglingTestRetParam(unsigned _ExtInt(33) Param) {
-// LIN: define i33 @_Z20ManglingTestRetParamU7_ExtIntILi33EEj(i33 %
+// LIN: define i64 @_Z20ManglingTestRetParamU7_ExtIntILi33EEj(i64 %
 // WIN: define dso_local i33 @"?ManglingTestRetParam@@YAU?$_UExtInt@$0CB@@__clang@@U12@@Z"(i33
   return 0;
 }
 
 _ExtInt(33) ManglingTestRetParam(_ExtInt(33) Param) {
-// LIN: define i33 @_Z20ManglingTestRetParamU7_ExtIntILi33EEi(i33 %
+// LIN: define i64 @_Z20ManglingTestRetParamU7_ExtIntILi33EEi(i64 %
 // WIN: define dso_local i33 @"?ManglingTestRetParam@@YAU?$_ExtInt@$0CB@@__clang@@U12@@Z"(i33
   return 0;
 }
@@ -155,13 +155,14 @@
 
   _ExtInt(92) A = __builtin_va_arg(args, _ExtInt(92));
   // LIN: %[[AD1:.+]] = getelementptr inbounds [1 x %struct.__va_list_tag], [1 x %struct.__va_list_tag]* %[[ARGS]]
-  // LIN: %[[OFA_P1:.+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %[[AD1]], i32 0, i32 2
-  // LIN: %[[OFA1:.+]] = load i8*, i8** %[[OFA_P1]]
-  // LIN: %[[BC1:.+]] = bitcast i8* %[[OFA1]] to i92*
-  // LIN: %[[OFANEXT1:.+]] = getelementptr i8, i8* %[[OFA1]], i32 16
-  // LIN: store i8* %[[OFANEXT1]], i8** %[[OFA_P1]]
+  // LIN: %[[OFA_P1:.+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %[[AD1]], i32 0, i32 0
+  // LIN: %[[GPOFFSET:.+]] = load i32, i32* %[[OFA_P1]]
+  // LIN: %[[FITSINGP:.+]] = icmp ule i32 %[[GPOFFSET]], 32
+  // LIN: br i1 %[[FITSINGP]]
+  // LIN: %[[BC1:.+]] = phi i92*
   // LIN: %[[LOAD1:.+]] = load i92, i92* %[[BC1]]
   // LIN: store i92 %[[LOAD1]], i92*
+
   // WIN: %[[CUR1:.+]] = load i8*, i8** %[[ARGS]]
   // WIN: %[[NEXT1:.+]] = getelementptr inbounds i8, i8* %[[CUR1]], i64 16
   // WIN: store i8* %[[NEXT1]], i8** %[[ARGS]]
@@ -171,15 +172,16 @@
 
   _ExtInt(31) B = __builtin_va_arg(args, _ExtInt(31));
   // LIN: %[[AD2:.+]] = getelementptr inbounds [1 x %struct.__va_list_tag], [1 x %struct.__va_list_tag]* %[[ARGS]]
-  // LIN: %[[OFA_P2:.+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %[[AD2]], i32 0, i32 2
-  // LIN: %[[OFA2:.+]] = load i8*, i8** %[[OFA_P2]]
-  // LIN: %[[BC2:.+]] = bitcast i8* %[[OFA2]] to i31*
-  // LIN: %[[OFANEXT2:.+]] = getelementptr i8, i8* %[[OFA2]], i32 8
-  // LIN: store i8* %[[OFANEXT2]], i8** %[[OFA_P2]]
-  // LIN: %[[LOAD2:.+]] = load i31, i31* %[[BC2]]
-  // LIN: store i31 %[[LOAD2]], i31*
+  // LIN: %[[OFA_P2:.+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %[[AD2]], i32 0, i32 0
+  // LIN: %[[GPOFFSET:.+]] = load i32, i32* %[[OFA_P2]]
+  // LIN: %[[FITSINGP:.+]] = icmp ule i32 %[[GPOFFSET]], 40
+  // LIN: br i1 %[[FITSINGP]]
+  // LIN: %[[BC1:.+]] = phi i31*
+  // LIN: %[[LOAD1:.+]] = load i31, i31* %[[BC1]]
+  // LIN: store i31 %[[LOAD1]], i31*
+
   // WIN: %[[CUR2:.+]] = load i8*, i8** %[[ARGS]]
-  // WIN: %[[NEXT2:.+]] = getelementptr inbounds i8, i8* %[[CUR2]], i64 8 
+  // WIN: %[[NEXT2:.+]] = getelementptr inbounds i8, i8* %[[CUR2]], i64 8
   // WIN: store i8* %[[NEXT2]], i8** %[[ARGS]]
   // WIN: %[[BC2:.+]] = bitcast i8* %[[CUR2]] to i31*
   // WIN: %[[LOADV2:.+]] = load i31, i31* %[[BC2]]
@@ -187,13 +189,14 @@
 
   _ExtInt(16) C = __builtin_va_arg(args, _ExtInt(16));
   // LIN: %[[AD3:.+]] = getelementptr inbounds [1 x %struct.__va_list_tag], [1 x %struct.__va_list_tag]* %[[ARGS]]
-  // LIN: %[[OFA_P3:.+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %[[AD3]], i32 0, i32 2
-  // LIN: %[[OFA3:.+]] = load i8*, i8** %[[OFA_P3]]
-  // LIN: %[[BC3:.+]] = bitcast i8* %[[OFA3]] to i16*
-  // LIN: %[[OFANEXT3:.+]] = getelementptr i8, i8* %[[OFA3]], i32 8
-  // LIN: store i8* %[[OFANEXT3]], i8** %[[OFA_P3]]
-  // LIN: %[[LOAD3:.+]] = load i16, i16* %[[BC3]]
-  // LIN: store i16 %[[LOAD3]], i16*
+  // LIN: %[[OFA_P3:.+]] = getelementptr inbounds %struct.__va_list_tag, %struct.__va_list_tag* %[[AD3]], i32 0, i32 0
+  // LIN: 

[PATCH] D79076: [clang] [MinGW] Add the compiler rt libdirs to the search path

[Martin Storsjö via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGa0e53de472c5: [clang] [MinGW] Add the compiler rt libdirs to 
the search path (authored by mstorsjo).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79076

Files:
  clang/lib/Driver/ToolChains/MinGW.cpp


Index: clang/lib/Driver/ToolChains/MinGW.cpp
===
--- clang/lib/Driver/ToolChains/MinGW.cpp
+++ clang/lib/Driver/ToolChains/MinGW.cpp
@@ -18,6 +18,7 @@
 #include "llvm/Option/ArgList.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/VirtualFileSystem.h"
 #include 
 
 using namespace clang::diag;
@@ -198,6 +199,17 @@
 
   Args.AddAllArgs(CmdArgs, options::OPT_L);
   TC.AddFilePathLibArgs(Args, CmdArgs);
+
+  // Add the compiler-rt library directories if they exist to help
+  // the linker find the various sanitizer, builtin, and profiling runtimes.
+  for (const auto  : TC.getLibraryPaths()) {
+if (TC.getVFS().exists(LibPath))
+  CmdArgs.push_back(Args.MakeArgString("-L" + LibPath));
+  }
+  auto CRTPath = TC.getCompilerRTPath();
+  if (TC.getVFS().exists(CRTPath))
+CmdArgs.push_back(Args.MakeArgString("-L" + CRTPath));
+
   AddLinkerInputs(TC, Inputs, Args, CmdArgs, JA);
 
   // TODO: Add profile stuff here


Index: clang/lib/Driver/ToolChains/MinGW.cpp
===
--- clang/lib/Driver/ToolChains/MinGW.cpp
+++ clang/lib/Driver/ToolChains/MinGW.cpp
@@ -18,6 +18,7 @@
 #include "llvm/Option/ArgList.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/VirtualFileSystem.h"
 #include 
 
 using namespace clang::diag;
@@ -198,6 +199,17 @@
 
   Args.AddAllArgs(CmdArgs, options::OPT_L);
   TC.AddFilePathLibArgs(Args, CmdArgs);
+
+  // Add the compiler-rt library directories if they exist to help
+  // the linker find the various sanitizer, builtin, and profiling runtimes.
+  for (const auto  : TC.getLibraryPaths()) {
+if (TC.getVFS().exists(LibPath))
+  CmdArgs.push_back(Args.MakeArgString("-L" + LibPath));
+  }
+  auto CRTPath = TC.getCompilerRTPath();
+  if (TC.getVFS().exists(CRTPath))
+CmdArgs.push_back(Args.MakeArgString("-L" + CRTPath));
+
   AddLinkerInputs(TC, Inputs, Args, CmdArgs, JA);
 
   // TODO: Add profile stuff here
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D78756: [SveEmitter] Add builtins for svreinterpret

[Eli Friedman via Phabricator via cfe-commits]

efriedma added inline comments.



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:7880
+return Builder.CreateBitCast(Val, Ty);
+  }
+

sdesmalen wrote:
> efriedma wrote:
> > I'm vaguely suspicious this might be wrong for big-endian targets.  I mean, 
> > this isn't unreasonable, but users might be surprised if svreinterpret 
> > isn't a no-op.
> For SVE the loads and stores (svld1 and svst1) are all endian safe, so no 
> special consideration needs to be taken for big endian targets.
> 
> The ACLE specifies that:
> > The svreinterpret functions simply reinterpret a vector of one type as a 
> > vector of another type, without changing any of the bits.
"bitcast" is specified to mean "reinterpret the bits like a store+load".  On 
big-endian NEON (and, I assume, SVE), that isn't a no-op.  See 
http://llvm.org/docs/BigEndianNEON.html .

I mean, if the answer here is "yes, svreinterpret is supposed to lower to a 
REV", then that's fine.  But I'd like to see some explciit acknowledgement that 
that's intentional.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78756



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

[PATCH] D79106: [clangd] Move inserted include from detail -> documentation.

[Sam McCall via Phabricator via cfe-commits]

sammccall created this revision.
sammccall added a reviewer: hokein.
Herald added subscribers: cfe-commits, usaxena95, kadircet, arphaman, jkorous, 
MaskRay, ilya-biryukov.
Herald added a project: clang.

Many clients try to display all the detail inline, with poor results.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79106

Files:
  clang-tools-extra/clangd/CodeComplete.cpp
  clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -1660,8 +1660,8 @@
   EXPECT_EQ(R.insertText, "Foo::x");
   EXPECT_EQ(R.insertTextFormat, InsertTextFormat::PlainText);
   EXPECT_EQ(R.filterText, "x");
-  EXPECT_EQ(R.detail, "int\n\"foo.h\"");
-  EXPECT_EQ(R.documentation, "This is x().");
+  EXPECT_EQ(R.detail, "int");
+  EXPECT_EQ(R.documentation, "#include \"foo.h\"\nThis is x().");
   EXPECT_THAT(R.additionalTextEdits, IsEmpty());
   EXPECT_EQ(R.sortText, sortText(1.0, "x"));
   EXPECT_FALSE(R.deprecated);
@@ -1683,7 +1683,8 @@
 
   C.BundleSize = 2;
   R = C.render(Opts);
-  EXPECT_EQ(R.detail, "[2 overloads]\n\"foo.h\"");
+  EXPECT_EQ(R.detail, "[2 overloads]");
+  EXPECT_EQ(R.documentation, "#include \"foo.h\"\nThis is x().");
 
   C.Deprecated = true;
   R = C.render(Opts);
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -1831,8 +1831,12 @@
: ReturnType;
   LSP.deprecated = Deprecated;
   if (InsertInclude)
-LSP.detail += "\n" + InsertInclude->Header;
-  LSP.documentation = Documentation;
+LSP.documentation = llvm::formatv("#include {0}", InsertInclude->Header);
+  if (!Documentation.empty()) {
+if (!LSP.documentation.empty())
+  LSP.documentation += "\n";
+LSP.documentation += Documentation;
+  }
   LSP.sortText = sortText(Score.Total, Name);
   LSP.filterText = Name;
   LSP.textEdit = {CompletionTokenRange, RequiredQualifier + Name};


Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -1660,8 +1660,8 @@
   EXPECT_EQ(R.insertText, "Foo::x");
   EXPECT_EQ(R.insertTextFormat, InsertTextFormat::PlainText);
   EXPECT_EQ(R.filterText, "x");
-  EXPECT_EQ(R.detail, "int\n\"foo.h\"");
-  EXPECT_EQ(R.documentation, "This is x().");
+  EXPECT_EQ(R.detail, "int");
+  EXPECT_EQ(R.documentation, "#include \"foo.h\"\nThis is x().");
   EXPECT_THAT(R.additionalTextEdits, IsEmpty());
   EXPECT_EQ(R.sortText, sortText(1.0, "x"));
   EXPECT_FALSE(R.deprecated);
@@ -1683,7 +1683,8 @@
 
   C.BundleSize = 2;
   R = C.render(Opts);
-  EXPECT_EQ(R.detail, "[2 overloads]\n\"foo.h\"");
+  EXPECT_EQ(R.detail, "[2 overloads]");
+  EXPECT_EQ(R.documentation, "#include \"foo.h\"\nThis is x().");
 
   C.Deprecated = true;
   R = C.render(Opts);
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -1831,8 +1831,12 @@
: ReturnType;
   LSP.deprecated = Deprecated;
   if (InsertInclude)
-LSP.detail += "\n" + InsertInclude->Header;
-  LSP.documentation = Documentation;
+LSP.documentation = llvm::formatv("#include {0}", InsertInclude->Header);
+  if (!Documentation.empty()) {
+if (!LSP.documentation.empty())
+  LSP.documentation += "\n";
+LSP.documentation += Documentation;
+  }
   LSP.sortText = sortText(Score.Total, Name);
   LSP.filterText = Name;
   LSP.textEdit = {CompletionTokenRange, RequiredQualifier + Name};
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D72841: Add support for pragma float_control, to control precision and exception behavior at the source level

[Melanie Blower via Phabricator via cfe-commits]

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



Comment at: clang/include/clang/AST/Expr.h:2701
 
+  FPOptions FPFeatures;
+

mibintc wrote:
> erichkeane wrote:
> > This type already has trailing-storage type stuff.  I think in the past 
> > review @rjmccall encouraged you to put this in the fake-trailing-storage  
> > like above.
> whoops i meant that to go to the CallExprBits
Adding FPOptions to CallExprBits makes the field too large, I'm going to drop 
adding FPOptions to CallExpr, i'll add it via trailingstorage in a separate 
patch if it's needed.



Comment at: clang/lib/Parse/ParsePragma.cpp:2534
+  PP.Lex(Tok);
+  if (Tok.isNot(tok::l_paren)) {
+PP.Diag(FloatControlLoc, diag::err_expected) << tok::l_paren;

erichkeane wrote:
> Replace this with BalancedDelimiterTracker instead, it gives consistent 
> errors and are a bit easier to use.  Additionally, I think it does some 
> fixups that allow us to recover better.
> 
> I'd also suggest some refactoring with the PragmaFloatControlKind if/elses 
> below.  Perhaps handle the closing paren at the end, and do a switch-case for 
> that handling.
BalancedDelimiterTracker doesn't work here because there's no access to the 
Parser object. Rewriting it would be an extensive change and I'm doubtful about 
making this change. PragmaHandler is defined in Lex. I think there are 60 
pragma's that use the PragmaHandler. 



Comment at: clang/lib/Sema/SemaAttr.cpp:1023
+  Diag(Loc, diag::err_pragma_fenv_requires_precise);
 CurFPFeatures.setAllowFEnvAccess();
 break;

erichkeane wrote:
> Should we still be setting this even if there was an error?
> Should we still be setting this even if there was an error?
It's not harmful to set it, if there's an error diagnostic then there is no 
codegen right?





Comment at: clang/lib/Serialization/ASTReaderStmt.cpp:684
 void ASTStmtReader::VisitUnaryOperator(UnaryOperator *E) {
+  bool hasFP_Features;
   VisitExpr(E);

mibintc wrote:
> erichkeane wrote:
> > Rather than this variable, why not just ask 'E' below?
> yes i could do that. it would be a function call
i made some changes in this area, eliminating setHasStoredFPFeatures


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72841



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

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D78785#2010546 , @rjmccall wrote:

> Could you answer my question up-thread about whether ExtInt is currently 
> target-limited?  If it isn't, we need to more broadly audit targets.


Yikes!  I missed that question, I'm sorry :/

We aren't limiting it, as it is supposed to be a C language feature (and in 
fact, is more useful certain on non-x86 chips!).  We likely need an audit, 
though in TargetInfo I didn't see any other 'classify' functions other than 
these 3 (X86, x86-64Win, x86-64-Linux).


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

https://reviews.llvm.org/D78785



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

[clang] 5a1d9c0 - Fix x86/x86_64 calling convention for _ExtInt

[Erich Keane via cfe-commits]

Author: Erich Keane
Date: 2020-04-29T11:04:25-07:00
New Revision: 5a1d9c0f5ac85b486a539b1d9558205821f17b33

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

LOG: Fix x86/x86_64 calling convention for _ExtInt

After speaking with Craig Topper about some recent defects, he pointed
out that _ExtInts should be passed indirectly if larger than the largest
int register, and like ints when smaller than that.  This patch
implements that.

Note that this changed the way vaargs worked quite a bit, but they still
work.

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

Added: 


Modified: 
clang/lib/CodeGen/TargetInfo.cpp
clang/test/CodeGen/ext-int-sanitizer.cpp
clang/test/CodeGen/ext-int.c
clang/test/CodeGenCXX/ext-int.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/TargetInfo.cpp 
b/clang/lib/CodeGen/TargetInfo.cpp
index 0a5fb27ba015..e77daad9668b 100644
--- a/clang/lib/CodeGen/TargetInfo.cpp
+++ b/clang/lib/CodeGen/TargetInfo.cpp
@@ -1822,6 +1822,15 @@ ABIArgInfo X86_32ABIInfo::classifyArgumentType(QualType 
Ty,
 return ABIArgInfo::getExtend(Ty);
   }
 
+  if (const auto * EIT = Ty->getAs()) {
+if (EIT->getNumBits() <= 64) {
+  if (InReg)
+return ABIArgInfo::getDirectInReg();
+  return ABIArgInfo::getDirect();
+}
+return getIndirectResult(Ty, /*ByVal=*/false, State);
+  }
+
   if (InReg)
 return ABIArgInfo::getDirectInReg();
   return ABIArgInfo::getDirect();
@@ -2785,6 +2794,15 @@ void X86_64ABIInfo::classify(QualType Ty, uint64_t 
OffsetBase,
 return;
   }
 
+  if (const auto *EITy = Ty->getAs()) {
+if (EITy->getNumBits() <= 64)
+  Current = Integer;
+else if (EITy->getNumBits() <= 128)
+  Lo = Hi = Integer;
+// Larger values need to get passed in memory.
+return;
+  }
+
   if (const ConstantArrayType *AT = getContext().getAsConstantArrayType(Ty)) {
 // Arrays are treated like structures.
 
@@ -2959,8 +2977,9 @@ ABIArgInfo 
X86_64ABIInfo::getIndirectReturnResult(QualType Ty) const {
 if (const EnumType *EnumTy = Ty->getAs())
   Ty = EnumTy->getDecl()->getIntegerType();
 
-return (Ty->isPromotableIntegerType() ? ABIArgInfo::getExtend(Ty)
-  : ABIArgInfo::getDirect());
+if (!Ty->isExtIntType())
+  return (Ty->isPromotableIntegerType() ? ABIArgInfo::getExtend(Ty)
+: ABIArgInfo::getDirect());
   }
 
   return getNaturalAlignIndirect(Ty);
@@ -2992,7 +3011,8 @@ ABIArgInfo X86_64ABIInfo::getIndirectResult(QualType Ty,
   // the argument in the free register. This does not seem to happen currently,
   // but this code would be much safer if we could mark the argument with
   // 'onstack'. See PR12193.
-  if (!isAggregateTypeForABI(Ty) && !IsIllegalVectorType(Ty)) {
+  if (!isAggregateTypeForABI(Ty) && !IsIllegalVectorType(Ty) &&
+  !Ty->isExtIntType()) {
 // Treat an enum type as its underlying type.
 if (const EnumType *EnumTy = Ty->getAs())
   Ty = EnumTy->getDecl()->getIntegerType();
@@ -4083,6 +4103,17 @@ ABIArgInfo WinX86_64ABIInfo::classify(QualType Ty, 
unsigned ,
 }
   }
 
+  if (Ty->isExtIntType()) {
+// MS x64 ABI requirement: "Any argument that doesn't fit in 8 bytes, or is
+// not 1, 2, 4, or 8 bytes, must be passed by reference."
+// However, non-power-of-two _ExtInts will be passed as 1,2,4 or 8 bytes
+// anyway as long is it fits in them, so we don't have to check the power 
of
+// 2.
+if (Width <= 64)
+  return ABIArgInfo::getDirect();
+return ABIArgInfo::getIndirect(Align, /*ByVal=*/false);
+  }
+
   return ABIArgInfo::getDirect();
 }
 

diff  --git a/clang/test/CodeGen/ext-int-sanitizer.cpp 
b/clang/test/CodeGen/ext-int-sanitizer.cpp
index ddf3180e1a1b..eaaab1b56c34 100644
--- a/clang/test/CodeGen/ext-int-sanitizer.cpp
+++ b/clang/test/CodeGen/ext-int-sanitizer.cpp
@@ -1,4 +1,4 @@
-// RUN: %clang_cc1 -triple x86_64-gnu-linux 
-fsanitize=array-bounds,enum,float-cast-overflow,integer-divide-by-zero,implicit-unsigned-integer-truncation,implicit-signed-integer-truncation,implicit-integer-sign-change,unsigned-integer-overflow,signed-integer-overflow,shift-base,shift-exponent
 -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s 
+// RUN: %clang_cc1 -triple x86_64-gnu-linux 
-fsanitize=array-bounds,enum,float-cast-overflow,integer-divide-by-zero,implicit-unsigned-integer-truncation,implicit-signed-integer-truncation,implicit-integer-sign-change,unsigned-integer-overflow,signed-integer-overflow,shift-base,shift-exponent
 -O3 -disable-llvm-passes -emit-llvm -o - %s | FileCheck %s
 
 
 // CHECK: define void @_Z6BoundsRA10_KiU7_ExtIntILi15EEi
@@ -56,9 +56,11 @@ void UIntTruncation(unsigned _ExtInt(35) E, unsigned int i, 
unsigned long 

[clang] a0e53de - [clang] [MinGW] Add the compiler rt libdirs to the search path

[Martin Storsjö via cfe-commits]

Author: Martin Storsjö
Date: 2020-04-29T20:35:50+03:00
New Revision: a0e53de472c5b9538884f23eb8f47c3bc734b345

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

LOG: [clang] [MinGW] Add the compiler rt libdirs to the search path

This matches what is done for MSVC in
b8000c0ce84541c5b5535419234fb65ce77d6756. Since that commit, compiler
rt sanitizer libraries aren't linked to with absolute path on windows,
but using their basenames, requiring the libdirs to be passed to
the linker.

This fixes undefined behaviour sanitizer on MinGW after
b8000c0ce84541c5b5535419234fb65ce77d6756.

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/MinGW.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/MinGW.cpp 
b/clang/lib/Driver/ToolChains/MinGW.cpp
index 6139764e4601..ce01c8816263 100644
--- a/clang/lib/Driver/ToolChains/MinGW.cpp
+++ b/clang/lib/Driver/ToolChains/MinGW.cpp
@@ -18,6 +18,7 @@
 #include "llvm/Option/ArgList.h"
 #include "llvm/Support/FileSystem.h"
 #include "llvm/Support/Path.h"
+#include "llvm/Support/VirtualFileSystem.h"
 #include 
 
 using namespace clang::diag;
@@ -198,6 +199,17 @@ void tools::MinGW::Linker::ConstructJob(Compilation , 
const JobAction ,
 
   Args.AddAllArgs(CmdArgs, options::OPT_L);
   TC.AddFilePathLibArgs(Args, CmdArgs);
+
+  // Add the compiler-rt library directories if they exist to help
+  // the linker find the various sanitizer, builtin, and profiling runtimes.
+  for (const auto  : TC.getLibraryPaths()) {
+if (TC.getVFS().exists(LibPath))
+  CmdArgs.push_back(Args.MakeArgString("-L" + LibPath));
+  }
+  auto CRTPath = TC.getCompilerRTPath();
+  if (TC.getVFS().exists(CRTPath))
+CmdArgs.push_back(Args.MakeArgString("-L" + CRTPath));
+
   AddLinkerInputs(TC, Inputs, Args, CmdArgs, JA);
 
   // TODO: Add profile stuff here



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

[PATCH] D78903: [Driver] Add option -fproc-stat-report

[Alexandre Ganea via Phabricator via cfe-commits]

aganea added inline comments.



Comment at: clang/docs/UsersManual.rst:770
+   $ cat abc
+   clang-11,"/tmp/foo-123456.o",92000,84000,87536
+   ld,"a.out",900,8000,53568

sepavloff wrote:
> aganea wrote:
> > Please add a header to the output .CSV, specifying the units of measure 
> > where relevant.
> CSV was chosen because such file is a simple union of records. It is 
> convenient if multiple processes write to it. A process locks the file, 
> writes to it and unlock it.
> 
> If header is required, thing get more complicated. A process locks file, then 
> moves to the end and get current position. If it is the beginning of the 
> file, this process if the first writer, so it writes header. Then it writes 
> line of data and unlock file.
> 
> On the other hand, CSV file is proposed for parsing by scripts. Does such 
> complication really makes sense?
Thanks for the explanation! Yes, it would be more complicated indeed if locking 
is required. Let's forget the header if it's not practical.

However that raises a question: is it up to the user/build system to delete the 
log file on startup? Otherwise each build would indefintely append, you 
wouldn't know where your last build started in the log? How do you address that 
currently?



Comment at: clang/docs/UsersManual.rst:787
+  $ clang -fproc-stat-report=- foo.c  
+  clang-11: output=/tmp/foo-123456.o, total=84000, user=76000, mem=87496
+  ld: output=a.out, total=8000, user=8000, mem=53548

sepavloff wrote:
> aganea wrote:
> > MaskRay wrote:
> > > aganea wrote:
> > > > I think it is better if the units are specified along (and 
> > > > locale-formatted, if possible):
> > > > ```
> > > > clang-11: output=/tmp/foo-123456.o  total=84,000 ms  user=76,000 ms  
> > > > mem=87,496 kb
> > > > ```
> > > Sorry, I tend to disagree with the argument for decimal separators and 
> > > locale differences. They make behaviors divergent and make the output 
> > > difficult to parse by a script. (Scripts may have to use `LANG=C clang 
> > > -fproc-stat-report=-` to cancel the locale effect)
> > In my sense, CSV or YAML are for machine parsing, TXT is for human 
> > consumption. A script should not parse a human-targetted output.
> > Maybe an option is missing here to set the format? Again xray has `-f=text` 
> > or `-f=csv`.
> I don't think an option for output format is needed here (but it could be 
> useful if we supported JSON in addition to CSV). However the proposed format 
> indeed is more readable. I am going to change printing accordingly, but 
> without locale specifics. For users of this feature C locale is convenient.
Sounds good!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78903



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

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

Could you answer my question up-thread about whether ExtInt is currently 
target-limited?  If it isn't, we need to more broadly audit targets.


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

https://reviews.llvm.org/D78785



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

[PATCH] D78979: OpenCL: Include builtin header by default

[Sven van Haastregt via Phabricator via cfe-commits]

svenvh added a comment.

In D78979#2007643 , @Anastasia wrote:

> > Would it not become confusing since the builtins are going to be included 
> > by default? Should we rename the flag at least? Also ideally it should be 
> > documented in https://clang.llvm.org/docs/UsersManual.html#opencl-header
>
> ah I guess if we leave it under `-cc1 ` we will have the command line 
> interface as follows:
>
> - Driver (without `-cc1`) adds OpenCL header by default that can be 
> overridden by the flag added in this patch.
> - Frontend (with `-cc1`) doesn't add the header by default but there are two 
> flags `-fdeclare-opencl-builtins` or `-finclude-default-header` that allow to 
> include the header.


The name of `-fdeclare-opencl-builtins` becomes a bit non-intuitive, a more 
intuitive name would be something like `-fopencl-tablegen-builtins` perhaps or 
`-fopencl-fast-builtins` if we don't want to mention TableGen.  But since it is 
still an experimental option, I have no objections against postponing the 
renaming until the option has reached maturity.


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

https://reviews.llvm.org/D78979



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

[PATCH] D77229: [Analyzer][WIP] Avoid handling of LazyCompundVals in IteratorModeling

[Balogh , Ádám via Phabricator via cfe-commits]

baloghadamsoftware updated this revision to Diff 260944.
baloghadamsoftware added a comment.

Now I made some good progress, thank you @NoQ for your suggestions. Not all of 
them are implemented yet (currently the +-1 with the indices seem to be 
working, thus I will fix that part later), but now I managed to reduce failing 
tests from 340 to 19. Most of these tests are about missing notes, so the next 
task is handling the new `ParamRegion` in the bug reporter visitors. I already 
made some progress there too.


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

https://reviews.llvm.org/D77229

Files:
  clang/include/clang/StaticAnalyzer/Checkers/SValExplainer.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/CallEvent.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/MemRegion.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/Regions.def
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/Store.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/SymbolManager.h
  clang/lib/StaticAnalyzer/Checkers/ContainerModeling.cpp
  clang/lib/StaticAnalyzer/Checkers/InvalidatedIteratorChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/Iterator.cpp
  clang/lib/StaticAnalyzer/Checkers/IteratorModeling.cpp
  clang/lib/StaticAnalyzer/Checkers/IteratorRangeChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/MismatchedIteratorChecker.cpp
  clang/lib/StaticAnalyzer/Checkers/STLAlgorithmModeling.cpp
  clang/lib/StaticAnalyzer/Core/BugReporterVisitors.cpp
  clang/lib/StaticAnalyzer/Core/CallEvent.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngine.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineCXX.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineCallAndReturn.cpp
  clang/lib/StaticAnalyzer/Core/MemRegion.cpp
  clang/lib/StaticAnalyzer/Core/RegionStore.cpp
  clang/lib/StaticAnalyzer/Core/Store.cpp
  clang/lib/StaticAnalyzer/Core/SymbolManager.cpp
  clang/test/Analysis/container-modeling.cpp
  clang/test/Analysis/explain-svals.cpp
  clang/test/Analysis/iterator-modeling.cpp
  clang/test/Analysis/temporaries.cpp

Index: clang/test/Analysis/temporaries.cpp
===
--- clang/test/Analysis/temporaries.cpp
+++ clang/test/Analysis/temporaries.cpp
@@ -890,12 +890,9 @@
 public:
   ~C() {
 glob = 1;
-// FIXME: Why is destructor not inlined in C++17
 clang_analyzer_checkInlined(true);
 #ifdef TEMPORARY_DTORS
-#if __cplusplus < 201703L
-// expected-warning@-3{{TRUE}}
-#endif
+// expected-warning@-2{{TRUE}}
 #endif
   }
 };
@@ -914,16 +911,11 @@
   // temporaries returned from functions, so we took the wrong branch.
   coin && is(get()); // no-crash
   if (coin) {
-// FIXME: Why is destructor not inlined in C++17
 clang_analyzer_eval(glob);
 #ifdef TEMPORARY_DTORS
-#if __cplusplus < 201703L
-// expected-warning@-3{{TRUE}}
-#else
-// expected-warning@-5{{UNKNOWN}}
-#endif
+// expected-warning@-2{{TRUE}}
 #else
-// expected-warning@-8{{UNKNOWN}}
+// expected-warning@-4{{UNKNOWN}}
 #endif
   } else {
 // The destructor is not called on this branch.
Index: clang/test/Analysis/iterator-modeling.cpp
===
--- clang/test/Analysis/iterator-modeling.cpp
+++ clang/test/Analysis/iterator-modeling.cpp
@@ -1862,7 +1862,7 @@
 void clang_analyzer_printState();
 
 void print_state(std::vector ) {
-  const auto i0 = V.cbegin();
+  auto i0 = V.cbegin();
   clang_analyzer_printState();
 
 // CHECK:  "checker_messages": [
@@ -1871,7 +1871,8 @@
 // CHECK-NEXT: "i0 : Valid ; Container == SymRegion{reg_$[[#]] & V>} ; Offset == conj_$[[#]]{long, LC[[#]], S[[#]], #[[#]]}"
 // CHECK-NEXT:   ]}
 
-  const auto i1 = V.cend();
+  ++i0;
+  auto i1 = V.cend();
   clang_analyzer_printState();
   
 // CHECK:  "checker_messages": [
@@ -1879,4 +1880,6 @@
 // CHECK-NEXT: "Iterator Positions :",
 // CHECK-NEXT: "i1 : Valid ; Container == SymRegion{reg_$[[#]] & V>} ; Offset == conj_$[[#]]{long, LC[[#]], S[[#]], #[[#]]}"
 // CHECK-NEXT:   ]}
+
+  --i1;
 }
Index: clang/test/Analysis/explain-svals.cpp
===
--- clang/test/Analysis/explain-svals.cpp
+++ clang/test/Analysis/explain-svals.cpp
@@ -93,6 +93,6 @@
 } // end of anonymous namespace
 
 void test_6() {
-  clang_analyzer_explain(conjure_S()); // expected-warning-re^lazily frozen compound value of temporary object constructed at statement 'conjure_S\(\)'$
+  clang_analyzer_explain(conjure_S()); // expected-warning-re^lazily frozen compound value of parameter 0 of function 'clang_analyzer_explain\(\)'$
   clang_analyzer_explain(conjure_S().z); // expected-warning-re^value derived from \(symbol of type 'int' conjured at statement 'conjure_S\(\)'\) for field 'z' of temporary object 

[PATCH] D78785: Fix x86/x86_64 calling convention for _ExtInt

[Craig Topper via Phabricator via cfe-commits]

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

LGTM


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

https://reviews.llvm.org/D78785



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

[PATCH] D78903: [Driver] Add option -fproc-stat-report

[Serge Pavlov via Phabricator via cfe-commits]

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



Comment at: clang/docs/UsersManual.rst:770
+   $ cat abc
+   clang-11,"/tmp/foo-123456.o",92000,84000,87536
+   ld,"a.out",900,8000,53568

aganea wrote:
> Please add a header to the output .CSV, specifying the units of measure where 
> relevant.
CSV was chosen because such file is a simple union of records. It is convenient 
if multiple processes write to it. A process locks the file, writes to it and 
unlock it.

If header is required, thing get more complicated. A process locks file, then 
moves to the end and get current position. If it is the beginning of the file, 
this process if the first writer, so it writes header. Then it writes line of 
data and unlock file.

On the other hand, CSV file is proposed for parsing by scripts. Does such 
complication really makes sense?



Comment at: clang/docs/UsersManual.rst:786
+
+  $ clang -fproc-stat-report=- foo.c  
+  clang-11: output=/tmp/foo-123456.o, total=84000, user=76000, mem=87496

aganea wrote:
> MaskRay wrote:
> > aganea wrote:
> > > Why not just `-fproc-stat-report` in this case?
> > It can save an `Option`..
> I was thinking in terms of user experience, I find it a bit awkward. If you 
> want stdin, you say `mytool < file`, if you want stdout you say `mytool` and 
> pipe the output down the line. Is there a need to state the output when we're 
> not writing to a file?
> 
> There is a precedent for this, other tools like xray have `llvm-xray account 
> %s -o -`, but it's there for completness, you could just say `llvm-xray 
> account %s`.
Agree, it looks awkward. I will add variant without value.



Comment at: clang/docs/UsersManual.rst:787
+  $ clang -fproc-stat-report=- foo.c  
+  clang-11: output=/tmp/foo-123456.o, total=84000, user=76000, mem=87496
+  ld: output=a.out, total=8000, user=8000, mem=53548

aganea wrote:
> MaskRay wrote:
> > aganea wrote:
> > > I think it is better if the units are specified along (and 
> > > locale-formatted, if possible):
> > > ```
> > > clang-11: output=/tmp/foo-123456.o  total=84,000 ms  user=76,000 ms  
> > > mem=87,496 kb
> > > ```
> > Sorry, I tend to disagree with the argument for decimal separators and 
> > locale differences. They make behaviors divergent and make the output 
> > difficult to parse by a script. (Scripts may have to use `LANG=C clang 
> > -fproc-stat-report=-` to cancel the locale effect)
> In my sense, CSV or YAML are for machine parsing, TXT is for human 
> consumption. A script should not parse a human-targetted output.
> Maybe an option is missing here to set the format? Again xray has `-f=text` 
> or `-f=csv`.
I don't think an option for output format is needed here (but it could be 
useful if we supported JSON in addition to CSV). However the proposed format 
indeed is more readable. I am going to change printing accordingly, but without 
locale specifics. For users of this feature C locale is convenient.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78903



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

[PATCH] D78982: [clang-format] Fix Microsoft style for enums

[Aaron Smith via Phabricator via cfe-commits]

asmith marked 2 inline comments as done.
asmith added inline comments.



Comment at: clang/lib/Format/Format.cpp:1143
   Style.PenaltyReturnTypeOnItsOwnLine = 1000;
+  Style.AllowShortEnumsOnASingleLine = (Language != FormatStyle::LK_Cpp);
   Style.AllowShortFunctionsOnASingleLine = FormatStyle::SFS_None;

MyDeveloperDay wrote:
> asmith wrote:
> > MyDeveloperDay wrote:
> > > I think its ok to leave it was, just if up the unit tests
> > > 
> > > (the fact you didn't see this suggests you are not running the unit tests 
> > > please ensure you are)
> > You need to use the latest changes. The is only applied when the style is 
> > Msft and C++. See the GetMicrosoftStyle() method.
> I don't think you should change the style based on the language here, either 
> on or off, but not changing based on language because what about "ObjectiveC"?
> 
> As I added the Microsoft style to allow C# development I think its ok to set 
> this to what you originally had, but fix up the tests
Ive enabled this for C#. I don't see the connection between ObjectiveC and 
Microsoft Style.


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

https://reviews.llvm.org/D78982



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

[PATCH] D78982: [clang-format] Fix Microsoft style for enums

[Aaron Smith via Phabricator via cfe-commits]

asmith updated this revision to Diff 260932.
asmith retitled this revision from "[clang-format] Fix Microsoft style for C++ 
enums" to "[clang-format] Fix Microsoft style for enums".
asmith edited the summary of this revision.
asmith added a comment.

Enable for C#


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

https://reviews.llvm.org/D78982

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

Index: clang/unittests/Format/FormatTestCSharp.cpp
===
--- clang/unittests/Format/FormatTestCSharp.cpp
+++ clang/unittests/Format/FormatTestCSharp.cpp
@@ -343,7 +343,13 @@
 }
 
 TEST_F(FormatTestCSharp, CSharpKeyWordEscaping) {
-  verifyFormat("public enum var { none, @string, bool, @enum }");
+  verifyFormat("public enum var\n"
+   "{\n"
+   "none,\n"
+   "@string,\n"
+   "bool,\n"
+   "@enum\n"
+   "}");
 }
 
 TEST_F(FormatTestCSharp, CSharpNullCoalescing) {
Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -1298,6 +1298,20 @@
"}");
 }
 
+TEST_F(FormatTest, ShortEnums) {
+  FormatStyle Style = getLLVMStyle();
+  Style.AllowShortEnumsOnASingleLine = true;
+  verifyFormat("enum { A, B, C } ShortEnum1, ShortEnum2;", Style);
+  Style.AllowShortEnumsOnASingleLine = false;
+  verifyFormat("enum\n"
+   "{\n"
+   "  A,\n"
+   "  B,\n"
+   "  C\n"
+   "} ShortEnum1, ShortEnum2;",
+   Style);
+}
+  
 TEST_F(FormatTest, ShortCaseLabels) {
   FormatStyle Style = getLLVMStyle();
   Style.AllowShortCaseLabelsOnASingleLine = true;
@@ -12934,6 +12948,7 @@
   CHECK_PARSE_BOOL(AllowAllConstructorInitializersOnNextLine);
   CHECK_PARSE_BOOL(AllowAllParametersOfDeclarationOnNextLine);
   CHECK_PARSE_BOOL(AllowShortCaseLabelsOnASingleLine);
+  CHECK_PARSE_BOOL(AllowShortEnumsOnASingleLine);
   CHECK_PARSE_BOOL(AllowShortLoopsOnASingleLine);
   CHECK_PARSE_BOOL(BinPackArguments);
   CHECK_PARSE_BOOL(BinPackParameters);
Index: clang/lib/Format/UnwrappedLineParser.h
===
--- clang/lib/Format/UnwrappedLineParser.h
+++ clang/lib/Format/UnwrappedLineParser.h
@@ -98,7 +98,7 @@
   void readTokenWithJavaScriptASI();
   void parseStructuralElement();
   bool tryToParseBracedList();
-  bool parseBracedList(bool ContinueOnSemicolons = false,
+  bool parseBracedList(bool ContinueOnSemicolons = false, bool IsEnum = false,
tok::TokenKind ClosingBraceKind = tok::r_brace);
   void parseParens();
   void parseSquare(bool LambdaIntroducer = false);
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -1724,6 +1724,7 @@
 }
 
 bool UnwrappedLineParser::parseBracedList(bool ContinueOnSemicolons,
+  bool IsEnum,
   tok::TokenKind ClosingBraceKind) {
   bool HasError = false;
   
@@ -1764,6 +1765,8 @@
   }
 }
 if (FormatTok->Tok.getKind() == ClosingBraceKind) {
+  if (IsEnum && !Style.AllowShortEnumsOnASingleLine)
+addUnwrappedLine();
   nextToken();
   return !HasError;
 }
@@ -1822,6 +1825,8 @@
   break;
 case tok::comma:
   nextToken();
+  if (IsEnum && !Style.AllowShortEnumsOnASingleLine)
+addUnwrappedLine();
   break;
 default:
   nextToken();
@@ -2280,9 +2285,18 @@
 return true;
   }
 
+  if (!Style.AllowShortEnumsOnASingleLine)
+addUnwrappedLine();
   // Parse enum body.
   nextToken();
-  bool HasError = !parseBracedList(/*ContinueOnSemicolons=*/true);
+  if (!Style.AllowShortEnumsOnASingleLine) {
+addUnwrappedLine();
+Line->Level += 1;
+  }
+  bool HasError = !parseBracedList(/*ContinueOnSemicolons=*/true,
+   /*IsEnum=*/true);
+  if (!Style.AllowShortEnumsOnASingleLine)
+Line->Level -= 1;
   if (HasError) {
 if (FormatTok->is(tok::semi))
   nextToken();
Index: clang/lib/Format/Format.cpp
===
--- clang/lib/Format/Format.cpp
+++ clang/lib/Format/Format.cpp
@@ -397,6 +397,8 @@
Style.AllowAllConstructorInitializersOnNextLine);
 IO.mapOptional("AllowAllParametersOfDeclarationOnNextLine",
Style.AllowAllParametersOfDeclarationOnNextLine);
+

[PATCH] D79095: [clang-format] NFC Correct clang-format headers file so documentation can be once again autogenerated

[Krasimir Georgiev via Phabricator via cfe-commits]

krasimir added a comment.

Awesome! Thank you!
Now that we've got "clang/phabricator/lint/git" robots that leave comments on 
patches, we may want to think about a way to have this automatically enforced 
in the future.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79095



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

[PATCH] D78118: [analyzer] StdLibraryFunctionsChecker: Add option to display loaded summaries

[Gabor Marton via Phabricator via cfe-commits]

martong updated this revision to Diff 260930.
martong marked 2 inline comments as done.
martong added a comment.

- Use Decl::print and 'for: '


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78118

Files:
  clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
  clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
  clang/test/Analysis/analyzer-config.c
  clang/test/Analysis/std-c-library-functions.c

Index: clang/test/Analysis/std-c-library-functions.c
===
--- clang/test/Analysis/std-c-library-functions.c
+++ clang/test/Analysis/std-c-library-functions.c
@@ -30,6 +30,35 @@
 // RUN:   -triple thumbv7-a15-linux \
 // RUN:   -verify
 
+// RUN: %clang_analyze_cc1 %s \
+// RUN:   -analyzer-checker=core \
+// RUN:   -analyzer-checker=apiModeling.StdCLibraryFunctions \
+// RUN:   -analyzer-config apiModeling.StdCLibraryFunctions:DisplayLoadedSummaries=true \
+// RUN:   -analyzer-checker=debug.ExprInspection \
+// RUN:   -analyzer-config eagerly-assume=false \
+// RUN:   -triple i686-unknown-linux 2>&1 | FileCheck %s
+
+//  CHECK: Loaded summary for: int isalnum(int)
+// CHECK-NEXT: Loaded summary for: int isalpha(int)
+// CHECK-NEXT: Loaded summary for: int isascii(int)
+// CHECK-NEXT: Loaded summary for: int isblank(int)
+// CHECK-NEXT: Loaded summary for: int isdigit(int)
+// CHECK-NEXT: Loaded summary for: int isgraph(int)
+// CHECK-NEXT: Loaded summary for: int islower(int)
+// CHECK-NEXT: Loaded summary for: int isprint(int)
+// CHECK-NEXT: Loaded summary for: int ispunct(int)
+// CHECK-NEXT: Loaded summary for: int isspace(int)
+// CHECK-NEXT: Loaded summary for: int isupper(int)
+// CHECK-NEXT: Loaded summary for: int isxdigit(int)
+// CHECK-NEXT: Loaded summary for: int getc(FILE *)
+// CHECK-NEXT: Loaded summary for: int fgetc(FILE *)
+// CHECK-NEXT: Loaded summary for: int getchar()
+// CHECK-NEXT: Loaded summary for: ssize_t read(int, void *, size_t)
+// CHECK-NEXT: Loaded summary for: ssize_t write(int, const void *, size_t)
+// CHECK-NEXT: Loaded summary for: unsigned int fread(void *restrict, size_t, size_t, FILE *)
+// CHECK-NEXT: Loaded summary for: unsigned int fwrite(const void *restrict, size_t, size_t, FILE *restrict)
+// CHECK-NEXT: Loaded summary for: ssize_t getline(char **, size_t *, FILE *)
+
 void clang_analyzer_eval(int);
 
 int glob;
Index: clang/test/Analysis/analyzer-config.c
===
--- clang/test/Analysis/analyzer-config.c
+++ clang/test/Analysis/analyzer-config.c
@@ -11,6 +11,7 @@
 // CHECK-NEXT: alpha.security.MmapWriteExec:MmapProtExec = 0x04
 // CHECK-NEXT: alpha.security.MmapWriteExec:MmapProtRead = 0x01
 // CHECK-NEXT: alpha.security.taint.TaintPropagation:Config = ""
+// CHECK-NEXT: apiModeling.StdCLibraryFunctions:DisplayLoadedSummaries = false
 // CHECK-NEXT: apply-fixits = false
 // CHECK-NEXT: avoid-suppressing-null-argument-paths = false
 // CHECK-NEXT: c++-allocator-inlining = true
@@ -106,4 +107,4 @@
 // CHECK-NEXT: unroll-loops = false
 // CHECK-NEXT: widen-loops = false
 // CHECK-NEXT: [stats]
-// CHECK-NEXT: num-entries = 103
+// CHECK-NEXT: num-entries = 104
Index: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -300,6 +300,8 @@
   DefaultBool ChecksEnabled[CK_NumCheckKinds];
   CheckerNameRef CheckNames[CK_NumCheckKinds];
 
+  bool DisplayLoadedSummaries = false;
+
 private:
   Optional findFunctionSummary(const FunctionDecl *FD,
 CheckerContext ) const;
@@ -639,8 +641,12 @@
   struct AddToFunctionSummaryMap {
 const ASTContext 
 FunctionSummaryMapType 
-AddToFunctionSummaryMap(const ASTContext , FunctionSummaryMapType )
-: ACtx(ACtx), Map(FSM) {}
+bool DisplayLoadedSummaries;
+AddToFunctionSummaryMap(const ASTContext , FunctionSummaryMapType ,
+bool DisplayLoadedSummaries)
+: ACtx(ACtx), Map(FSM), DisplayLoadedSummaries(DisplayLoadedSummaries) {
+}
+
 // Add a summary to a FunctionDecl found by lookup. The lookup is performed
 // by the given Name, and in the global scope. The summary will be attached
 // to the found FunctionDecl only if the signatures match.
@@ -655,6 +661,11 @@
 auto Res = Map.insert({FD->getCanonicalDecl(), S});
 assert(Res.second && "Function already has a summary set!");
 (void)Res;
+if (DisplayLoadedSummaries) {
+  llvm::errs() << "Loaded summary for: ";
+  FD->print(llvm::errs());
+  llvm::errs() << "\n";
+}
 return;
   }
 }
@@ -665,7 +676,7 @@
   

[PATCH] D79095: [clang-format] NFC Correct clang-format headers file so documentation can be once again autogenerated

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

In D79095#2010250 , @krasimir wrote:

> Awesome! Thank you!
>  Now that we've got "clang/phabricator/lint/git" robots that leave comments 
> on patches, we may want to think about a way to have this automatically 
> enforced in the future.


Thats a great idea.. do you know who looks after those scripts?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79095



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

[PATCH] D78118: [analyzer] StdLibraryFunctionsChecker: Add option to display loaded summaries

[Gabor Marton via Phabricator via cfe-commits]

martong marked 4 inline comments as done.
martong added inline comments.



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:651
+// Get the declaration of a function proto as written in the source file.
+StringRef ToString(const FunctionDecl *FD) {
+  const auto  = ACtx.getSourceManager();

balazske wrote:
> Maybe the `Decl::print` method can be used? I pretty-prints the declaration 
> (hopefully there is an option to print only the prototype), otherwise we can 
> get the code as written in the source-file(?) that makes comparing the output 
> more difficult. 
Yeah, thanks! I switched to use that!



Comment at: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp:681
+if (DisplayLoadedSummaries)
+  llvm::errs() << "Loaded summary for " << ToString(FD) << "\n";
 return;

balazske wrote:
> I would prefer to display the function prototype in a separate line (if not 
> only the name is included in the string). Or at least enclose the prototype 
> with `'` characters. Or the `Loaded summary for: ` form.
Ok I use the `Loaded summary for: ` form from now on.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D78118



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

[PATCH] D76066: [ARM][MachineOutliner] Add Machine Outliner support for ARM

[Yvan Roux via Phabricator via cfe-commits]

yroux added inline comments.



Comment at: llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp:5606
+  // candidates.
+  auto CantGuaranteeValueAcrossCall = [](outliner::Candidate ) {
+// If the unsafe registers in this block are all dead, then we don't need

yroux wrote:
> samparker wrote:
> > Does this code work with the DSP instructions that read/write the Q and GE 
> > flags? I have a nasty feeling that we don't model their register usage.
> Good question, I'll test that
From what I saw in my testing of DSP instructions, these flags are handled by 
CPSR usage, so this code seems good to me, do you have something else in mind ?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76066



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

[PATCH] D79095: [clang-format] NFC Correct clang-format headers file so documentation can be once again autogenerated

[MyDeveloperDay via Phabricator via cfe-commits]

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



Comment at: clang/docs/ClangFormatStyleOptions.rst:1752
  LngFunctionDeclaration();
 
+**InsertTrailingCommas** (``TrailingCommaStyle``)

NOTE: options are alphabetic in Format.h and so the position within the rst 
file will change.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79095



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

[PATCH] D79095: [clang-format] NFC Correct clang-format headers file so documentation can be once again autogenerated

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay created this revision.
MyDeveloperDay added reviewers: mprobst, krasimir, mitchell-stellar, asmith.
MyDeveloperDay added projects: clang, clang-format.
MyDeveloperDay edited the summary of this revision.
MyDeveloperDay marked an inline comment as done.
MyDeveloperDay added inline comments.
MyDeveloperDay retitled this revision from "[clang-format] NFC Correct 
clang-format headers file so documentation can be one again autogenerated" to 
"[clang-format] NFC Correct clang-format headers file so documentation can be 
once again autogenerated".



Comment at: clang/docs/ClangFormatStyleOptions.rst:1752
  LngFunctionDeclaration();
 
+**InsertTrailingCommas** (``TrailingCommaStyle``)

NOTE: options are alphabetic in Format.h and so the position within the rst 
file will change.


`ClangFormatStyleOptions.rst` should ALWAYS be autogenerated from Format.h 
using `clang/docs/tools/dump_format_style.py` if not its liable to get removed 
leaving options undocumented.

This revision reworks the documentation for D73354: clang-format: insert 
trailing commas into containers.  D73768: 
clang-format: [JS] document InsertTrailingCommas. 
 to ensure we can continue to regenerated

Fix other minor changes that ensure the documentation remains consistent 
(Format.h obviously got re clang-formatted after the rst had been regenerated 
previously)

Generated documentation will look like

F11824218: image.png 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D79095

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/include/clang/Format/Format.h

Index: clang/include/clang/Format/Format.h
===
--- clang/include/clang/Format/Format.h
+++ clang/include/clang/Format/Format.h
@@ -561,6 +561,21 @@
 TCS_Wrapped,
   };
 
+  /// If set to ``TCS_Wrapped`` will insert trailing commas in container
+  /// literals (arrays and objects) that wrap across multiple lines.
+  /// It is currently only available for JavaScript
+  /// and disabled by default ``TCS_None``.
+  /// ``InsertTrailingCommas`` cannot be used together with ``BinPackArguments``
+  /// as inserting the comma disables bin-packing.
+  /// \code
+  ///   TSC_Wrapped:
+  ///   const someArray = [
+  ///   aa,
+  ///   aa,
+  ///   aa,
+  ///   //^ inserted
+  ///   ]
+  /// \endcode
   TrailingCommaStyle InsertTrailingCommas;
 
   /// If ``false``, a function declaration's or function definition's
@@ -2133,7 +2148,7 @@
 /// appears within a line (e.g. consecutive assignments and declarations).
 UT_ForContinuationAndIndentation,
 /// Use tabs for line continuation and indentation, and spaces for
-/// alignemnt.
+/// alignment.
 UT_AlignWithSpaces,
 /// Use tabs whenever we need to fill whitespace that spans at least from
 /// one tab stop to the next one.
Index: clang/docs/ClangFormatStyleOptions.rst
===
--- clang/docs/ClangFormatStyleOptions.rst
+++ clang/docs/ClangFormatStyleOptions.rst
@@ -717,26 +717,6 @@
 aaa);
 }
 
-
-**InsertTrailingCommas** (``TrailingCommaStyle``) can be set to ``TCS_Wrapped``
-  to insert trailing commas in container literals (arrays and objects) that wrap
-  across multiple lines. It is currently only available for JavaScript and
-  disabled by default (``TCS_None``).
-
-  ``InsertTrailingCommas`` cannot be used together with ``BinPackArguments`` as
-  inserting the comma disables bin-packing.
-
-  .. code-block:: c++
-
-TSC_Wrapped:
-const someArray = [
-  aa,
-  aa,
-  aa,
-  //^ inserted
-]
-
-
 **BinPackParameters** (``bool``)
   If ``false``, a function declaration's or function definition's
   parameters will either all be on the same line or will have one line each.
@@ -1770,6 +1750,38 @@
  LngReturnType
  LngFunctionDeclaration();
 
+**InsertTrailingCommas** (``TrailingCommaStyle``)
+  If set to ``TCS_Wrapped`` will insert trailing commas in container
+  literals (arrays and objects) that wrap across multiple lines.
+  It is currently only available for JavaScript
+  and disabled by default ``TCS_None``.
+  ``InsertTrailingCommas`` cannot be used together with ``BinPackArguments``
+  as inserting the comma disables bin-packing.
+
+  .. code-block:: c++
+
+TSC_Wrapped:
+const someArray = [
+aa,
+aa,
+aa,
+//^ inserted

[PATCH] D78982: [clang-format] Fix Microsoft style for C++ enums

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

see D79095: [clang-format] NFC Correct clang-format headers file so 
documentation can be once again autogenerated  
this should be handled separately.




Comment at: clang/docs/ClangFormatStyleOptions.rst:721
-
-**InsertTrailingCommas** (``TrailingCommaStyle``) can be set to ``TCS_Wrapped``
-  to insert trailing commas in container literals (arrays and objects) that 
wrap

MyDeveloperDay wrote:
> asmith wrote:
> > MyDeveloperDay wrote:
> > > ? are you removing something?
> > These are changes from running the python script to regenerate the docs. 
> > Someone forgot to run the script. This info is no longer in the header.
> If a change isn't related to your feature, simply ignore it, but don't 
> include other changes in yours. If this has truly gone then we need to handle 
> that separately
This is from {D73768} we may need to determine why the code was not put into 
Format.h but that can be handled by a separate revision


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

https://reviews.llvm.org/D78982



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

[PATCH] D78982: [clang-format] Fix Microsoft style for C++ enums

[Aaron Smith via Phabricator via cfe-commits]

asmith added inline comments.



Comment at: clang/docs/ClangFormatStyleOptions.rst:721
-
-**InsertTrailingCommas** (``TrailingCommaStyle``) can be set to ``TCS_Wrapped``
-  to insert trailing commas in container literals (arrays and objects) that 
wrap

MyDeveloperDay wrote:
> MyDeveloperDay wrote:
> > asmith wrote:
> > > MyDeveloperDay wrote:
> > > > ? are you removing something?
> > > These are changes from running the python script to regenerate the docs. 
> > > Someone forgot to run the script. This info is no longer in the header.
> > If a change isn't related to your feature, simply ignore it, but don't 
> > include other changes in yours. If this has truly gone then we need to 
> > handle that separately
> This is from {D73768} we may need to determine why the code was not put into 
> Format.h but that can be handled by a separate revision
This is generated by a script. I don't think it's a good idea to edit an 
automatically generated file. I can exclude the change to the RST completely 
and someone can regenerate the RST in a follow on patch.


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

https://reviews.llvm.org/D78982



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

[PATCH] D79094: [SemaObjC] Warn on visibility attributes on an @implementation

[Erik Pilkington via Phabricator via cfe-commits]

erik.pilkington created this revision.
erik.pilkington added reviewers: rjmccall, aaron.ballman.
Herald added subscribers: ributzka, dexonsmith, jkorous.

D60542  added support for attributes on 
`@implementation`s, but CodeGen always looks for visibility attributes on the 
`@interface`, so these attributes just end up getting ignored. I think we could 
support them on implementations, but it seems like information that should 
really belong in the header. This patch explicitly ignores them with a warning.

rdar://60045616


https://reviews.llvm.org/D79094

Files:
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Parser/attributes.mm


Index: clang/test/Parser/attributes.mm
===
--- clang/test/Parser/attributes.mm
+++ clang/test/Parser/attributes.mm
@@ -15,9 +15,11 @@
 
 @interface EXP I @end // expected-error {{postfix attributes are not allowed 
on Objective-C directives, place them in front of '@interface'}}
 EXP @interface I2 @end
+EXP @interface I2 (Cat) @end
 
 @implementation EXP I @end // expected-error-re {{postfix attributes are not 
allowed on Objective-C directives{{$
-EXP @implementation I2 @end
+EXP @implementation I2 @end // expected-warning{{attribute ignored}}
+EXP @implementation I2 (Cat) @end // expected-warning{{attribute ignored}}
 
 @class EXP OC; // expected-error-re {{postfix attributes are not allowed on 
Objective-C directives{{$
 EXP @class OC2; // expected-error {{prefix attribute must be followed by an 
interface, protocol, or implementation}}
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -2570,8 +2570,9 @@
 
 static void handleVisibilityAttr(Sema , Decl *D, const ParsedAttr ,
  bool isTypeVisibility) {
-  // Visibility attributes don't mean anything on a typedef.
-  if (isa(D)) {
+  // Visibility attributes don't mean anything on a typedef, and aren't
+  // permitted on an @implementation.
+  if (isa(D) || isa(D)) {
 S.Diag(AL.getRange().getBegin(), diag::warn_attribute_ignored) << AL;
 return;
   }


Index: clang/test/Parser/attributes.mm
===
--- clang/test/Parser/attributes.mm
+++ clang/test/Parser/attributes.mm
@@ -15,9 +15,11 @@
 
 @interface EXP I @end // expected-error {{postfix attributes are not allowed on Objective-C directives, place them in front of '@interface'}}
 EXP @interface I2 @end
+EXP @interface I2 (Cat) @end
 
 @implementation EXP I @end // expected-error-re {{postfix attributes are not allowed on Objective-C directives{{$
-EXP @implementation I2 @end
+EXP @implementation I2 @end // expected-warning{{attribute ignored}}
+EXP @implementation I2 (Cat) @end // expected-warning{{attribute ignored}}
 
 @class EXP OC; // expected-error-re {{postfix attributes are not allowed on Objective-C directives{{$
 EXP @class OC2; // expected-error {{prefix attribute must be followed by an interface, protocol, or implementation}}
Index: clang/lib/Sema/SemaDeclAttr.cpp
===
--- clang/lib/Sema/SemaDeclAttr.cpp
+++ clang/lib/Sema/SemaDeclAttr.cpp
@@ -2570,8 +2570,9 @@
 
 static void handleVisibilityAttr(Sema , Decl *D, const ParsedAttr ,
  bool isTypeVisibility) {
-  // Visibility attributes don't mean anything on a typedef.
-  if (isa(D)) {
+  // Visibility attributes don't mean anything on a typedef, and aren't
+  // permitted on an @implementation.
+  if (isa(D) || isa(D)) {
 S.Diag(AL.getRange().getBegin(), diag::warn_attribute_ignored) << AL;
 return;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] e717e87 - [libclang] Shared libraries require PIC unless WIN32

[David Zarzycki via cfe-commits]

Author: David Zarzycki
Date: 2020-04-29T11:25:45-04:00
New Revision: e717e8744d374e16603157e5135005727bf17901

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

LOG: [libclang] Shared libraries require PIC unless WIN32

Added: 


Modified: 
clang/tools/libclang/CMakeLists.txt

Removed: 




diff  --git a/clang/tools/libclang/CMakeLists.txt 
b/clang/tools/libclang/CMakeLists.txt
index bb2b14cc8e27..f56771b8a594 100644
--- a/clang/tools/libclang/CMakeLists.txt
+++ b/clang/tools/libclang/CMakeLists.txt
@@ -77,7 +77,7 @@ if(MSVC)
   set(LLVM_EXPORTED_SYMBOL_FILE)
 endif()
 
-if(LLVM_ENABLE_PIC OR NOT LIBCLANG_BUILD_STATIC)
+if(LLVM_ENABLE_PIC OR (WIN32 AND NOT LIBCLANG_BUILD_STATIC))
   set(ENABLE_SHARED SHARED)
 endif()
 



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

Re: [clang] 6654719 - [CMake] Fix logic error: NOT LIBCLANG_BUILD_STATIC does not imply PIC

[David Zarzycki via cfe-commits]

Hi Cristian,

That's alright. No worries. Good luck with the move (especially during the 
pandemic). My three stage test of LLVM+clang+lld+libcxx+libcxxabi is almost 
done, and I'll commit your suggested fix soon.

Dave

On Wed, Apr 29, 2020, at 10:53 AM, Cristian Adam wrote:
> Hi, 
> 
> Thank you David for not reverting my 3rd attempt to get libclang to 
> build statically on Windows.
> 
> In my defense the commit landed on a Saturday, and while I usually hack 
> on weekends, but now I'm involved in moving to a new home and I wasn't 
> able to reply to your message.
> 
> I'm sorry for the trouble of getting the revert and failed build. I 
> thought I had everything covered this time...
> 
> Cheers
> Cristian.
> 
> > -Original Message-
> > From: David Zarzycki 
> > Sent: Wednesday, 29 April 2020 16:37
> > To: Hans Wennborg 
> > Cc: Cristian Adam ; David Zarzycki via cfe-commits 
> >  > comm...@lists.llvm.org>; Nico Weber 
> > Subject: Re: [clang] 6654719 - [CMake] Fix logic error: NOT
> > LIBCLANG_BUILD_STATIC does not imply PIC
> > 
> > Okay, sounds good. For whatever it may be worth, I pasted the build failure 
> > to
> > D75068 shortly after it landed with the hope that the original author(s) 
> > would
> > commit a quick fix, but that didn't happen.
> > 
> > 
> > On Wed, Apr 29, 2020, at 10:23 AM, Hans Wennborg wrote:
> > > Your suggestion of
> > >
> > > > if(LLVM_ENABLE_PIC OR (WIN32 AND NOT LIBCLANG_BUILD_STATIC))
> > >
> > > sounds good to me. I don't know what the non-Windows non-PIC problem
> > > was exactly (your commit didn't mention it), so maybe it's best if you
> > > land that to verify it fixes the issue?
> > >
> > > Thanks,
> > > Hans
> > >
> > > On Wed, Apr 29, 2020 at 3:59 PM David Zarzycki  wrote:
> > > >
> > > > Hans,
> > > >
> > > > Non-Windows non-PIC setups were working just fine until four days ago
> > when D75068 landed. I tried to narrowly unbreak non-Windows non-PIC systems
> > but apparently that broke Windows. For that, I'm sorry. That being said, 
> > non-
> > Windows systems are broken again and this breakable was foreseeable given my
> > revert. What is your plan for non-Windows systems?
> > > >
> > > > As a part of the post-revert discussion in D75068, cristian.adam 
> > > > suggested
> > that the check for WIN32 should be added back, but nobody followed through
> > on that. What is stopping us from adding Christian's proposed change?
> > Specifically:
> > > >
> > > > if(LLVM_ENABLE_PIC OR (WIN32 AND NOT LIBCLANG_BUILD_STATIC))
> > > >
> > > > Dave
> > > >
> > > > On Wed, Apr 29, 2020, at 9:19 AM, Hans Wennborg wrote:
> > > > > On Sun, Apr 26, 2020 at 1:17 PM David Zarzycki via cfe-commits
> > > > >  wrote:
> > > > > >
> > > > > >
> > > > > > Author: David Zarzycki
> > > > > > Date: 2020-04-26T07:16:42-04:00
> > > > > > New Revision: 665471907a5c072c6653a38c35f35e5d54cef220
> > > > > >
> > > > > > URL:
> > > > > > https://github.com/llvm/llvm-project/commit/665471907a5c072c6653
> > > > > > a38c35f35e5d54cef220
> > > > > > DIFF:
> > > > > > https://github.com/llvm/llvm-project/commit/665471907a5c072c6653
> > > > > > a38c35f35e5d54cef220.diff
> > > > > >
> > > > > > LOG: [CMake] Fix logic error: NOT LIBCLANG_BUILD_STATIC does not
> > > > > > imply PIC
> > > > >
> > > > > But it does imply building libclang.dll.
> > > > >
> > > > > Your change broke building libclang.dll when configured with
> > > > > "cmake -GNinja -DCMAKE_BUILD_TYPE=Release
> > > > > -DLLVM_ENABLE_PROJECTS=clang
> > > > > -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ENABLE_PIC=OFF" on
> > Windows, see
> > > > > the discussion here: https://reviews.llvm.org/D74564#1884556
> > > > >
> > > > > I've reverted in 209ab6d8835cd88320ceb814893759cfbda91d15.
> > > > >
> > > > > >
> > > > > > Added:
> > > > > >
> > > > > >
> > > > > > Modified:
> > > > > > clang/tools/libclang/CMakeLists.txt
> > > > > >
> > > > > > Removed:
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > 
> > > > > >  diff  --git
> > > > > > a/clang/tools/libclang/CMakeLists.txt
> > > > > > b/clang/tools/libclang/CMakeLists.txt
> > > > > > index bb2b14cc8e27..9368501592a9 100644
> > > > > > --- a/clang/tools/libclang/CMakeLists.txt
> > > > > > +++ b/clang/tools/libclang/CMakeLists.txt
> > > > > > @@ -77,7 +77,7 @@ if(MSVC)
> > > > > >set(LLVM_EXPORTED_SYMBOL_FILE)
> > > > > >  endif()
> > > > > >
> > > > > > -if(LLVM_ENABLE_PIC OR NOT LIBCLANG_BUILD_STATIC)
> > > > > > +if(LLVM_ENABLE_PIC)
> > > > > >set(ENABLE_SHARED SHARED)
> > > > > >  endif()
> > > > > >
> > > > > >
> > > > > >
> > > > > >
> > > > > > ___
> > > > > > 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

[PATCH] D76066: [ARM][MachineOutliner] Add Machine Outliner support for ARM

[Yvan Roux via Phabricator via cfe-commits]

yroux updated this revision to Diff 260921.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D76066

Files:
  clang/lib/Driver/ToolChains/Clang.cpp
  llvm/lib/Target/ARM/ARMBaseInstrInfo.cpp
  llvm/lib/Target/ARM/ARMBaseInstrInfo.h
  llvm/lib/Target/ARM/ARMTargetMachine.cpp
  llvm/test/CodeGen/ARM/machine-outliner-tail.ll
  llvm/test/CodeGen/ARM/machine-outliner-thunk.ll
  llvm/test/CodeGen/ARM/machine-outliner-unoutlinable.mir
  llvm/test/CodeGen/ARM/machine-outliner-unsafe-registers.mir

Index: llvm/test/CodeGen/ARM/machine-outliner-unsafe-registers.mir
===
--- /dev/null
+++ llvm/test/CodeGen/ARM/machine-outliner-unsafe-registers.mir
@@ -0,0 +1,76 @@
+# NOTE: Assertions have been autogenerated by utils/update_mir_test_checks.py
+# RUN: llc -mtriple=arm-- -run-pass=machine-outliner -verify-machineinstrs \
+# RUN: %s -o - | FileCheck %s
+
+--- |
+  define void @outline_cpsr_r12_ok() #0 { ret void }
+  define void @dont_outline_cpsr() #0 { ret void }
+  define void @dont_outline_r12() #0 { ret void }
+  declare void @z(i32, i32, i32, i32)
+
+  attributes #0 = { minsize optsize }
+...
+---
+
+name:   outline_cpsr_r12_ok
+tracksRegLiveness: true
+body: |
+  ; CHECK-LABEL: name: outline_cpsr_r12_ok
+  ; CHECK: bb.0:
+  ; CHECK:   BL @OUTLINED_FUNCTION_0
+  ; CHECK: bb.1:
+  ; CHECK:   $r12 = MOVi 1, 14 /* CC::al */, $noreg, $noreg
+  ; CHECK:   CMPri $r12, 42, 14 /* CC::al */, $noreg, implicit-def $cpsr
+  ; CHECK:   BL @OUTLINED_FUNCTION_0
+  bb.0:
+liveins: $cpsr, $r12
+$r0 = MOVi 1, 14, $noreg, $noreg
+$r1 = MOVi 1, 14, $noreg, $noreg
+$r2 = MOVi 1, 14, $noreg, $noreg
+$r3 = MOVi 1, 14, $noreg, $noreg
+BL @z
+  bb.1:
+$r12 = MOVi 1, 14, $noreg, $noreg
+CMPri $r12, 42, 14, $noreg, implicit-def $cpsr
+$r0 = MOVi 1, 14, $noreg, $noreg
+$r1 = MOVi 1, 14, $noreg, $noreg
+$r2 = MOVi 1, 14, $noreg, $noreg
+$r3 = MOVi 1, 14, $noreg, $noreg
+BL @z
+  bb.2:
+BX_RET 14, $noreg
+...
+---
+
+name:   dont_outline_cpsr
+tracksRegLiveness: true
+body: |
+  ; CHECK-LABEL: name: dont_outline_cpsr
+  ; CHECK-NOT: BL @OUTLINED_FUNCTION_0
+  bb.0:
+liveins: $cpsr
+$r0 = MOVi 1, 14, $noreg, $noreg
+$r1 = MOVi 1, 14, $noreg, $noreg
+$r2 = MOVi 1, 14, $noreg, $noreg
+$r3 = MOVi 1, 14, $noreg, $noreg
+BL @z
+  bb.1:
+liveins: $cpsr
+BX_RET 14, $noreg
+...
+---
+
+name:   dont_outline_r12
+tracksRegLiveness: true
+body: |
+  bb.0:
+liveins: $r12
+; CHECK-LABEL: name: dont_outline_r12
+; CHECK-NOT: BL @OUTLINED_FUNCTION_0
+$r0 = MOVi 1, 14, $noreg, $noreg
+$r1 = MOVi 1, 14, $noreg, $noreg
+$r2 = MOVi 1, 14, $noreg, $noreg
+$r3 = MOVi 1, 14, $noreg, $noreg
+BL @z
+$r2 = MOVr $r12, 14, $noreg, $noreg
+BX_RET 14, $noreg
Index: llvm/test/CodeGen/ARM/machine-outliner-unoutlinable.mir
===
--- /dev/null
+++ llvm/test/CodeGen/ARM/machine-outliner-unoutlinable.mir
@@ -0,0 +1,113 @@
+# NOTE: Assertions have been autogenerated by utils/update_mir_test_checks.py
+# RUN: llc -mtriple=thumbv7-- -run-pass=machine-outliner -verify-machineinstrs \
+# RUN: %s -o - | FileCheck %s
+
+--- |
+  define void @dont_outline_asm() #0 { ret void }
+  define void @dont_outline_lr() #0 { ret void }
+  define void @dont_outline_it() #0 { ret void }
+  define void @dont_outline_pic() #0 { ret void }
+  declare void @z(i32, i32, i32, i32)
+
+  attributes #0 = { minsize optsize }
+...
+---
+
+name:   dont_outline_asm
+tracksRegLiveness: true
+body: |
+  ; CHECK-LABEL: name: dont_outline_asm
+  ; CHECK: bb.0:
+  ; CHECK:   INLINEASM &"movs  r0, #42", 1
+  ; CHECK:   tBL 14 /* CC::al */, $noreg, @OUTLINED_FUNCTION_0
+  ; CHECK: bb.1:
+  ; CHECK:   INLINEASM &"movs  r0, #42", 1
+  ; CHECK:   tBL 14 /* CC::al */, $noreg, @OUTLINED_FUNCTION_0
+  bb.0:
+INLINEASM &"movs  r0, #42", 1
+$r0, dead $cpsr = tMOVi8 1, 14, $noreg
+$r1, dead $cpsr = tMOVi8 1, 14, $noreg
+$r2, dead $cpsr = tMOVi8 1, 14, $noreg
+$r3, dead $cpsr = tMOVi8 1, 14, $noreg
+tBL 14, $noreg, @z
+  bb.1:
+INLINEASM &"movs  r0, #42", 1
+$r0, dead $cpsr = tMOVi8 1, 14, $noreg
+$r1, dead $cpsr = tMOVi8 1, 14, $noreg
+$r2, dead $cpsr = tMOVi8 1, 14, $noreg
+$r3, dead $cpsr = tMOVi8 1, 14, $noreg
+tBL 14, $noreg, @z
+  bb.2:
+tBX_RET 14, $noreg
+...
+---
+
+name:   dont_outline_lr
+tracksRegLiveness: true
+body: |
+  ; CHECK-LABEL: name: dont_outline_lr
+  ; CHECK-NOT: tBL 14 /* CC::al */, $noreg, @OUTLINED_FUNCTION
+  bb.0:
+liveins: $lr
+$r0 = tMOVr $lr, 14, $noreg
+$r1 = tMOVr $lr, 14, $noreg
+$r2 = tMOVr $lr, 14, $noreg
+$r3 = tMOVr $lr, 14, $noreg
+tBL 14, $noreg, @z
+  bb.1:
+liveins: $lr
+$r0 =