[clang] e5e4653 - Remove dead variable to silence compiler warning [NFC]

[Mikael Holmen via cfe-commits]

Author: Mikael Holmen
Date: 2020-10-16T09:26:52+02:00
New Revision: e5e4653255ff7d78d62923038ff085fae47e950b

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

LOG: Remove dead variable to silence compiler warning [NFC]

Added: 


Modified: 
clang/lib/AST/ExprConstant.cpp

Removed: 




diff  --git a/clang/lib/AST/ExprConstant.cpp b/clang/lib/AST/ExprConstant.cpp
index 20eb9f77ca52..fda565354b92 100644
--- a/clang/lib/AST/ExprConstant.cpp
+++ b/clang/lib/AST/ExprConstant.cpp
@@ -7440,7 +7440,6 @@ class ExprEvaluatorBase
 bool HasQualifier = false;
 
 CallRef Call;
-bool EvaluatedArgs = false;
 
 // Extract function decl and 'this' pointer from the callee.
 if (CalleeType->isSpecificBuiltinType(BuiltinType::BoundMember)) {
@@ -7499,7 +7498,6 @@ class ExprEvaluatorBase
 if (!EvaluateArgs(isa(FD) ? Args.slice(1) : Args, Call,
   Info, FD, /*RightToLeft=*/true))
   return false;
-EvaluatedArgs = true;
   }
 
   // Overloaded operator calls to member functions are represented as 
normal



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

[PATCH] D89528: [clang][test] Fix prefix operator++ signature in iterators

[Endre Fülöp via Phabricator via cfe-commits]

gamesh411 created this revision.
Herald added subscribers: cfe-commits, martong, Szelethus, dkrupp.
Herald added a reviewer: Szelethus.
Herald added a project: clang.
gamesh411 requested review of this revision.

Prefix operator++ should return the iterator incremented by reference.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D89528

Files:
  clang/test/Analysis/Inputs/system-header-simulator-cxx.h


Index: clang/test/Analysis/Inputs/system-header-simulator-cxx.h
===
--- clang/test/Analysis/Inputs/system-header-simulator-cxx.h
+++ clang/test/Analysis/Inputs/system-header-simulator-cxx.h
@@ -46,7 +46,7 @@
 
   __vector_iterator(const Ptr p = 0) : ptr(p) {}
   __vector_iterator(const iterator &rhs): ptr(rhs.base()) {}
-  __vector_iterator operator++() { ++ ptr; return *this; }
+  __vector_iterator& operator++() { ++ ptr; return *this; }
   __vector_iterator operator++(int) {
 auto tmp = *this;
 ++ ptr;
@@ -109,7 +109,7 @@
 
   __deque_iterator(const Ptr p = 0) : ptr(p) {}
   __deque_iterator(const iterator &rhs): ptr(rhs.base()) {}
-  __deque_iterator operator++() { ++ ptr; return *this; }
+  __deque_iterator& operator++() { ++ ptr; return *this; }
   __deque_iterator operator++(int) {
 auto tmp = *this;
 ++ ptr;
@@ -169,7 +169,7 @@
 
   __list_iterator(T* it = 0) : item(it) {}
   __list_iterator(const iterator &rhs): item(rhs.item) {}
-  __list_iterator operator++() { item = item->next; return *this; 
}
+  __list_iterator& operator++() { item = item->next; return 
*this; }
   __list_iterator operator++(int) {
 auto tmp = *this;
 item = item->next;
@@ -212,7 +212,7 @@
 
   __fwdl_iterator(T* it = 0) : item(it) {}
   __fwdl_iterator(const iterator &rhs): item(rhs.item) {}
-  __fwdl_iterator operator++() { item = item->next; return *this; 
}
+  __fwdl_iterator& operator++() { item = item->next; return 
*this; }
   __fwdl_iterator operator++(int) {
 auto tmp = *this;
 item = item->next;
@@ -1079,7 +1079,7 @@
 class iterator {
 public:
   iterator(Key *key): ptr(key) {}
-  iterator operator++() { ++ptr; return *this; }
+  iterator& operator++() { ++ptr; return *this; }
   bool operator!=(const iterator &other) const { return ptr != other.ptr; }
   const Key &operator*() const { return *ptr; }
 private:
@@ -1104,7 +1104,7 @@
 class iterator {
 public:
   iterator(Key *key): ptr(key) {}
-  iterator operator++() { ++ptr; return *this; }
+  iterator& operator++() { ++ptr; return *this; }
   bool operator!=(const iterator &other) const { return ptr != other.ptr; }
   const Key &operator*() const { return *ptr; }
 private:


Index: clang/test/Analysis/Inputs/system-header-simulator-cxx.h
===
--- clang/test/Analysis/Inputs/system-header-simulator-cxx.h
+++ clang/test/Analysis/Inputs/system-header-simulator-cxx.h
@@ -46,7 +46,7 @@
 
   __vector_iterator(const Ptr p = 0) : ptr(p) {}
   __vector_iterator(const iterator &rhs): ptr(rhs.base()) {}
-  __vector_iterator operator++() { ++ ptr; return *this; }
+  __vector_iterator& operator++() { ++ ptr; return *this; }
   __vector_iterator operator++(int) {
 auto tmp = *this;
 ++ ptr;
@@ -109,7 +109,7 @@
 
   __deque_iterator(const Ptr p = 0) : ptr(p) {}
   __deque_iterator(const iterator &rhs): ptr(rhs.base()) {}
-  __deque_iterator operator++() { ++ ptr; return *this; }
+  __deque_iterator& operator++() { ++ ptr; return *this; }
   __deque_iterator operator++(int) {
 auto tmp = *this;
 ++ ptr;
@@ -169,7 +169,7 @@
 
   __list_iterator(T* it = 0) : item(it) {}
   __list_iterator(const iterator &rhs): item(rhs.item) {}
-  __list_iterator operator++() { item = item->next; return *this; }
+  __list_iterator& operator++() { item = item->next; return *this; }
   __list_iterator operator++(int) {
 auto tmp = *this;
 item = item->next;
@@ -212,7 +212,7 @@
 
   __fwdl_iterator(T* it = 0) : item(it) {}
   __fwdl_iterator(const iterator &rhs): item(rhs.item) {}
-  __fwdl_iterator operator++() { item = item->next; return *this; }
+  __fwdl_iterator& operator++() { item = item->next; return *this; }
   __fwdl_iterator operator++(int) {
 auto tmp = *this;
 item = item->next;
@@ -1079,7 +1079,7 @@
 class iterator {
 public:
   iterator(Key *key): ptr(key) {}
-  iterator operator++() { ++ptr; return *this; }
+  iterator& operator++() { ++ptr; return *this; }
   bool operator!=(const iterator &other) const { return ptr != other.ptr; }
   const Key &operator*() const { return *ptr; }
 private:
@@ -1104,7 +1104,7 @@
 class iterator {
 public:
   iterator(Key *key): ptr(key) {}
-  iterator operator++() { ++ptr; return *this; }
+  iterator& operator++() { ++ptr; return *this; }
   bool operator!=(const iterator &other) const { return ptr != other.ptr; }
   const Key

[clang] 6030a07 - Fix hidden-redecls.m test for some environments

[Konstantin Schwarz via cfe-commits]

Author: Konstantin Schwarz
Date: 2020-10-16T09:51:13+02:00
New Revision: 6030a075164c7016b29a67680ed5c9e7c5932109

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

LOG: Fix hidden-redecls.m test for some environments

This test was failing in our CI environment, because Jenkins mounts the 
workspaces into Docker containers using their full path, i.e. 
/home/jenkins/workspaces/llvm-build.
We've seen permission denied errors because /home/jenkins is mounted with root 
permissions and the default cache directory under Linux is $HOME/.cache.

The fix is to explicitly provide the -fmodules-cache-path, which the other 
tests already seem to provide.

Reviewed By: akyrtzi

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

Added: 


Modified: 
clang/test/Index/hidden-redecls.m

Removed: 




diff  --git a/clang/test/Index/hidden-redecls.m 
b/clang/test/Index/hidden-redecls.m
index 1735c0b5e184..ba34e69db85e 100644
--- a/clang/test/Index/hidden-redecls.m
+++ b/clang/test/Index/hidden-redecls.m
@@ -7,6 +7,7 @@ - (void)top_method;
 // p1_method in protocol P1 is hidden since module_redecls.sub hasn't been
 // imported yet. Check it is still indexed.
 
-// RUN: c-index-test -index-file-full %s -isystem %S/Inputs -fmodules -target 
x86_64-apple-macosx10.7 | FileCheck %s
+// RUN: rm -rf %t
+// RUN: c-index-test -index-file-full %s -isystem %S/Inputs -fmodules 
-fmodules-cache-path=%t -target x86_64-apple-macosx10.7 | FileCheck %s
 // CHECK: [indexDeclaration]: kind: objc-instance-method | name: p1_method | 
{{.*}} | loc: {{.*}}hidden-redecls-sub.h:2:9 | {{.*}} | isRedecl: 0
 // CHECK: [indexDeclaration]: kind: objc-instance-method | name: p1_method | 
{{.*}} | loc: {{.*}}hidden-redecls-sub.h:3:9 | {{.*}} | isRedecl: 1



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

[PATCH] D89453: Fix hidden-redecls.m test for some environments

[Konstantin Schwarz via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG6030a075164c: Fix hidden-redecls.m test for some 
environments (authored by kschwarz).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89453

Files:
  clang/test/Index/hidden-redecls.m


Index: clang/test/Index/hidden-redecls.m
===
--- clang/test/Index/hidden-redecls.m
+++ clang/test/Index/hidden-redecls.m
@@ -7,6 +7,7 @@
 // p1_method in protocol P1 is hidden since module_redecls.sub hasn't been
 // imported yet. Check it is still indexed.
 
-// RUN: c-index-test -index-file-full %s -isystem %S/Inputs -fmodules -target 
x86_64-apple-macosx10.7 | FileCheck %s
+// RUN: rm -rf %t
+// RUN: c-index-test -index-file-full %s -isystem %S/Inputs -fmodules 
-fmodules-cache-path=%t -target x86_64-apple-macosx10.7 | FileCheck %s
 // CHECK: [indexDeclaration]: kind: objc-instance-method | name: p1_method | 
{{.*}} | loc: {{.*}}hidden-redecls-sub.h:2:9 | {{.*}} | isRedecl: 0
 // CHECK: [indexDeclaration]: kind: objc-instance-method | name: p1_method | 
{{.*}} | loc: {{.*}}hidden-redecls-sub.h:3:9 | {{.*}} | isRedecl: 1


Index: clang/test/Index/hidden-redecls.m
===
--- clang/test/Index/hidden-redecls.m
+++ clang/test/Index/hidden-redecls.m
@@ -7,6 +7,7 @@
 // p1_method in protocol P1 is hidden since module_redecls.sub hasn't been
 // imported yet. Check it is still indexed.
 
-// RUN: c-index-test -index-file-full %s -isystem %S/Inputs -fmodules -target x86_64-apple-macosx10.7 | FileCheck %s
+// RUN: rm -rf %t
+// RUN: c-index-test -index-file-full %s -isystem %S/Inputs -fmodules -fmodules-cache-path=%t -target x86_64-apple-macosx10.7 | FileCheck %s
 // CHECK: [indexDeclaration]: kind: objc-instance-method | name: p1_method | {{.*}} | loc: {{.*}}hidden-redecls-sub.h:2:9 | {{.*}} | isRedecl: 0
 // CHECK: [indexDeclaration]: kind: objc-instance-method | name: p1_method | {{.*}} | loc: {{.*}}hidden-redecls-sub.h:3:9 | {{.*}} | isRedecl: 1
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 51ff045 - Recommit "[DSE] Switch to MemorySSA-backed DSE by default."

[Florian Hahn via cfe-commits]

Author: Florian Hahn
Date: 2020-10-16T09:02:53+01:00
New Revision: 51ff04567b2f8d06b2062bd3ed72eab2e93e4466

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

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

After investigation by @asbirlea, the issue that caused the
revert appears to be an issue in the original source, rather
than a problem with the compiler.

This patch enables MemorySSA DSE again.

This reverts commit 915310bf14cbac58a81fd60e0fa9dc8d341108e2.

Added: 


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

llvm/test/Transforms/DeadStoreElimination/MSSA/combined-partial-overwrites.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/const-pointers.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/crash.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/cs-cs-aliasing.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/debug-counter.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/debuginfo.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/dominate.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/fence-todo.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/fence.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/free.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/inst-limits.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/int_sideeffect.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/invariant.start.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/launder.invariant.group.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/libcalls.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/lifetime.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/mda-with-dbg-values.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/memcpy-complete-overwrite.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/memintrinsics.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/memoryssa-scan-limit.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/memset-and-memcpy.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/memset-missing-debugloc.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/memset-unknown-sizes.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/merge-stores-big-endian.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/merge-stores.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-captures.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-exceptions.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-loops.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-malloc-free.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-memintrinsics.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-memoryphis.ll

llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-multipath-throwing.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-multipath.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-overlap.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-partial.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-simple.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-throwing.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/multiblock-unreachable.ll
llvm/test/Transforms/DeadStoreElimination/MSSA/no-targetdata.l

[PATCH] D87830: [clang-tidy][test] Allow empty checks in check_clang_tidy.py

[Endre Fülöp via Phabricator via cfe-commits]

gamesh411 added a comment.

In D87830#2298198 , @aaron.ballman 
wrote:

> 



> know of any tests that are impacted by this?

I haven't found any tidy-tests that were negative-tests (ie.: tests that assert 
that there are no diagnostics).

> ... if I understand the proposed patch, that may now be silently accepted as 
> a passing test?

This is not entirely the case. Let me demonstrate with a few cases:
Before this patch:

  // empty test
  // RUN: %check_clang_tidy %s %t
  // no CHECK lines in the entire file

In the above case the test will fail with `CHECK-FIXES, CHECK-MESSAGES or 
CHECK-NOTES not found in the input`.

  // empty test, but explicityly mention we dont want diagnostics
  // RUN: %check_clang_tidy %s %t
  // CHECK_MESSAGES_NOT: ARBITRARY STRING HERE
  // ...
  // there are *no* other CHECK messages

This passes the first round of sanity checking, but FileCheck nevertheless 
rejects the processed test file:
FileCheck error: 
'/home/gamesh411/clang-rwa/tools/clang/tools/extra/test/clang-tidy/checkers/Output/empty.cpp.tmp.cpp.msg'
 is empty.

  // empty test, but explicityly mention we dont want diagnostics
  // RUN: %check_clang_tidy %s %t
  // CHECK_MESSAGES_NOT: arbitrary string here, I prefer NO DIAG
  // ...
  // there *are* some other CHECK messages further down

This is fine, but only means that the arbitrary string diagnostic is expected 
to be *not* seen, while some others are.

After patch:
The second case above becomes fine, everything else stays the same.

> Or should this not be an issue in general because `// CHECK` lines should 
> still be present in the test and those will fail when compared against an 
> empty file?

This means that the only accidental empty test scenario is when someone 
accidentally skips the CHECK messages he wants to put in, *but* manages to put 
in the CHECK-NOT by accident as well. This can result from copy-paste, but 
still, I think this is not likely.

> I'm wondering if we want to require something like `// 
> expected-no-diagnostics` from the `-verify` command in Clang so that users 
> have to explicitly opt a test into the behavior?

My thoughts were exactly that; I need something like the DiagVerifier's 
`expected-no-diagnostics`. That was the motivation behind this patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87830

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

[PATCH] D74299: [clang-tidy] extend tests of run-clang-tidy

[Alexander Lanin via Phabricator via cfe-commits]

AlexanderLanin updated this revision to Diff 298566.
AlexanderLanin added a comment.

Readd removed 'print help without crashing' test


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

https://reviews.llvm.org/D74299

Files:
  clang-tools-extra/test/clang-tidy/infrastructure/run-clang-tidy.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/run-clang-tidy_config-file.cpp
  
clang-tools-extra/test/clang-tidy/infrastructure/run-clang-tidy_export-diagnostics.cpp


Index: 
clang-tools-extra/test/clang-tidy/infrastructure/run-clang-tidy_export-diagnostics.cpp
===
--- /dev/null
+++ 
clang-tools-extra/test/clang-tidy/infrastructure/run-clang-tidy_export-diagnostics.cpp
@@ -0,0 +1,33 @@
+// under test:
+// - parsing and using compile_commands
+// - export fixes to yaml file
+
+// use %t as directory instead of file,
+// because "compile_commands.json" must have exactly that name:
+// RUN: rm -rf %t
+// RUN: mkdir %t
+// RUN: echo '[{"directory":"%/S","command":"clang++ -c %s","file":"%s"}]' \
+// RUN:  > %t/compile_commands.json
+
+// execute and check:
+// RUN: cd "%t"
+// RUN: %run_clang_tidy 
-checks='-*,bugprone-sizeof-container,modernize-use-auto' \
+// RUN: -p="%/t" -export-fixes=%t/fixes.yaml > %t/msg.txt 2>&1
+// RUN: FileCheck -input-file=%t/msg.txt -check-prefix=CHECK-MESSAGES %s \
+// RUN:   -implicit-check-not='{{warning|error|note}}:'
+// RUN: FileCheck -input-file=%t/fixes.yaml -check-prefix=CHECK-YAML %s
+
+#include 
+int main()
+{
+  std::vector vec;
+  std::vector::iterator iter = vec.begin();
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: use auto when declaring iterators
+  // CHECK-YAML: modernize-use-auto
+  
+  return sizeof(vec);
+  // CHECK-MESSAGES: :[[@LINE-1]]:10: warning: sizeof() doesn't return the 
size of the container; did you mean .size()? [bugprone-sizeof-container]
+  // CHECK-YAML: bugprone-sizeof-container
+  // After https://reviews.llvm.org/D72730 --> CHECK-YAML-NOT: 
bugprone-sizeof-container
+}
+
Index: 
clang-tools-extra/test/clang-tidy/infrastructure/run-clang-tidy_config-file.cpp
===
--- /dev/null
+++ 
clang-tools-extra/test/clang-tidy/infrastructure/run-clang-tidy_config-file.cpp
@@ -0,0 +1,33 @@
+// under test:
+// - .clang-tidy read from file & treat warnings as errors
+// - return code of run-clang-tidy on those errors
+
+// First make sure clang-tidy is executable and can print help without 
crashing:
+// RUN: %run_clang_tidy --help
+
+// use %t as directory instead of file:
+// RUN: rm -rf %t
+// RUN: mkdir %t
+
+// add this file to %t, add compile_commands for it and .clang-tidy config:
+// RUN: echo "[{\"directory\":\".\",\"command\":\"clang++ -c 
%/t/test.cpp\",\"file\":\"%/t/test.cpp\"}]" | sed -e 's/\\//g' > 
%t/compile_commands.json
+// RUN: echo "Checks: '-*,modernize-use-auto'" > %t/.clang-tidy
+// RUN: echo "WarningsAsErrors: '*'" >> %t/.clang-tidy
+// RUN: echo "CheckOptions:" >> %t/.clang-tidy
+// RUN: echo "  - key: modernize-use-auto.MinTypeNameLength" >> 
%t/.clang-tidy
+// RUN: echo "value:   '0'" >> %t/.clang-tidy
+// RUN: cp "%s" "%t/test.cpp"
+
+// execute and check:
+// RUN: cd "%t"
+// RUN: not %run_clang_tidy "test.cpp" > %t/msg.txt 2>&1
+// RUN: FileCheck -input-file=%t/msg.txt -check-prefix=CHECK-MESSAGES %s \
+// RUN:   -implicit-check-not='{{warning|error|note}}:'
+
+int main()
+{
+  int* x = new int();
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: error: {{.+}} 
[modernize-use-auto,-warnings-as-errors]
+
+  delete x;
+}
Index: clang-tools-extra/test/clang-tidy/infrastructure/run-clang-tidy.cpp
===
--- clang-tools-extra/test/clang-tidy/infrastructure/run-clang-tidy.cpp
+++ /dev/null
@@ -1,18 +0,0 @@
-// RUN: %run_clang_tidy --help
-// RUN: rm -rf %t
-// RUN: mkdir %t
-// RUN: echo "[{\"directory\":\".\",\"command\":\"clang++ -c 
%/t/test.cpp\",\"file\":\"%/t/test.cpp\"}]" | sed -e 's/\\//g' > 
%t/compile_commands.json
-// RUN: echo "Checks: '-*,modernize-use-auto'" > %t/.clang-tidy
-// RUN: echo "WarningsAsErrors: '*'" >> %t/.clang-tidy
-// RUN: echo "CheckOptions:" >> %t/.clang-tidy
-// RUN: echo "  - key: modernize-use-auto.MinTypeNameLength" >> 
%t/.clang-tidy
-// RUN: echo "value:   '0'" >> %t/.clang-tidy
-// RUN: cp "%s" "%t/test.cpp"
-// RUN: cd "%t"
-// RUN: not %run_clang_tidy "test.cpp"
-
-int main()
-{
-  int* x = new int();
-  delete x;
-}


Index: clang-tools-extra/test/clang-tidy/infrastructure/run-clang-tidy_export-diagnostics.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/infrastructure/run-clang-tidy_export-diagnostics.cpp
@@ -0,0 +1,33 @@
+// under test:
+// - parsing and using compile_commands
+// - export fixes to yaml file
+
+// use %t as directory inst

[PATCH] D89496: [Format/ObjC] Correctly handle base class with lightweight generics and protocol

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay accepted this revision.
MyDeveloperDay added a comment.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89496

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

[PATCH] D89464: Revert "[clang-format] Fix AlignConsecutive on PP blocks"

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

LGTM, only keep the tests if they remain passing, otherwise perhaps 
@JakeMerdichAMD  can add them back in.

Could you add a test for the thing that broke to keep us honest?

@JakeMerdichAMD when you get time, swing back round again with your fix because 
I think this was a good change (apart of the issues)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89464

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

[PATCH] D89490: Introduce __attribute__((darwin_abi))

[Adrien Guinet via Phabricator via cfe-commits]

aguinet updated this revision to Diff 298568.
aguinet added a comment.

Add some clang-format tags, and restore back the "original" formatting for 
these cases


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89490

Files:
  clang/include/clang-c/Index.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/Specifiers.h
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/darwin_abi.c
  clang/test/CodeGen/darwin_abi_empty_structs.cpp
  clang/test/CodeGen/darwin_abi_vaarg.c
  clang/test/CodeGen/debug-info-cc.c
  clang/test/CodeGenCXX/darwinabi-returnthis.cpp
  clang/tools/libclang/CXType.cpp
  llvm/include/llvm/BinaryFormat/Dwarf.def
  llvm/include/llvm/IR/CallingConv.h
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/AsmParser/LLToken.h
  llvm/lib/IR/AsmWriter.cpp
  llvm/lib/Target/AArch64/AArch64CallingConvention.cpp
  llvm/lib/Target/AArch64/AArch64FastISel.cpp
  llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
  llvm/lib/Target/AArch64/AArch64ISelLowering.h
  llvm/lib/Target/AArch64/AArch64RegisterInfo.cpp
  llvm/lib/Target/AArch64/AArch64Subtarget.h
  llvm/lib/Target/AArch64/GISel/AArch64CallLowering.cpp
  llvm/test/CodeGen/AArch64/darwin_abi.ll
  llvm/test/CodeGen/AArch64/darwin_abi_vararg.ll

Index: llvm/test/CodeGen/AArch64/darwin_abi_vararg.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AArch64/darwin_abi_vararg.ll
@@ -0,0 +1,39 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=aarch64-pc-linux | FileCheck %s
+
+target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
+target triple = "aarch64-pc-linux"
+
+%struct.__va_list = type { i8*, i8*, i8*, i32, i32 }
+
+define dso_local aarch64_darwincc void @foo(i32 %n, ...) local_unnamed_addr #0 {
+; CHECK-LABEL: foo:
+; CHECK:   // %bb.0: // %entry
+; CHECK-NEXT:sub sp, sp, #48 // =48
+; CHECK-NEXT:stp x29, x30, [sp, #32] // 16-byte Folded Spill
+; CHECK-NEXT:add x29, sp, #32 // =32
+; CHECK-NEXT:add x8, x29, #16 // =16
+; CHECK-NEXT:mov x1, sp
+; CHECK-NEXT:str xzr, [sp, #24]
+; CHECK-NEXT:str x8, [sp]
+; CHECK-NEXT:bl vfoo
+; CHECK-NEXT:ldp x29, x30, [sp, #32] // 16-byte Folded Reload
+; CHECK-NEXT:add sp, sp, #48 // =48
+; CHECK-NEXT:ret
+entry:
+  %va = alloca %struct.__va_list, align 8
+  %0 = bitcast %struct.__va_list* %va to i8*
+  call void @llvm.va_start(i8* nonnull %0)
+  call void @vfoo(i32 %n, %struct.__va_list* nonnull %va) #1
+  call void @llvm.va_end(i8* nonnull %0)
+  ret void
+}
+
+declare void @llvm.va_start(i8*) #1
+
+declare dso_local void @vfoo(i32, %struct.__va_list*) local_unnamed_addr #0
+
+declare void @llvm.va_end(i8*) #1
+
+attributes #0 = { nounwind "disable-tail-calls"="false" "frame-pointer"="non-leaf" "target-cpu"="generic" }
+attributes #1 = { nounwind }
Index: llvm/test/CodeGen/AArch64/darwin_abi.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AArch64/darwin_abi.ll
@@ -0,0 +1,29 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=aarch64-pc-linux | FileCheck %s
+
+target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
+target triple = "aarch64-pc-linux"
+
+define dso_local aarch64_darwincc signext i16 @f1(i16 signext %a) local_unnamed_addr #0 {
+; CHECK-LABEL: f1:
+; CHECK:   // %bb.0: // %entry
+; CHECK-NEXT:add w8, w0, #1 // =1
+; CHECK-NEXT:sxth w0, w8
+; CHECK-NEXT:ret
+entry:
+  %add = add i16 %a, 1
+  ret i16 %add
+}
+
+define dso_local aarch64_darwincc zeroext i16 @f2(i16 zeroext %a) local_unnamed_addr #0 {
+; CHECK-LABEL: f2:
+; CHECK:   // %bb.0: // %entry
+; CHECK-NEXT:add w8, w0, #1 // =1
+; CHECK-NEXT:and w0, w8, #0x
+; CHECK-NEXT:ret
+entry:
+  %add = add i16 %a, 1
+  ret i16 %add
+}
+
+attributes #0 = { norecurse nounwind readnone "disable-tail-calls"="false" "frame-pointer"="non-leaf" "target-cpu"="generic" }
Index: llvm/lib/Target/AArch64/GISel/AArch64CallLowering.cpp
===
--- llvm/lib/Target/AArch64/GISel/AArch64CallLowering.cpp
+++ llvm/lib/Target/AArch64/GISel/AArch64CallLowering.cpp
@@ -474,8 +474,8 @@
   uint64_t StackOffset = Handler.StackUsed;
   if (F.isVarArg()) {
 auto &Subtarget = MF.getSubtarget();
-if (!Subtarget.isTargetDarwin()) {
-// FIXME: we need to reimplement saveVarArgsRegis

[PATCH] D89490: Introduce __attribute__((darwin_abi))

[Adrien Guinet via Phabricator via cfe-commits]

aguinet updated this revision to Diff 298569.
aguinet added a comment.

One missing formatting case...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89490

Files:
  clang/include/clang-c/Index.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/Specifiers.h
  clang/lib/AST/ItaniumMangle.cpp
  clang/lib/AST/Type.cpp
  clang/lib/AST/TypePrinter.cpp
  clang/lib/Basic/Targets/AArch64.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/lib/CodeGen/ItaniumCXXABI.cpp
  clang/lib/CodeGen/TargetInfo.cpp
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CodeGen/darwin_abi.c
  clang/test/CodeGen/darwin_abi_empty_structs.cpp
  clang/test/CodeGen/darwin_abi_vaarg.c
  clang/test/CodeGen/debug-info-cc.c
  clang/test/CodeGenCXX/darwinabi-returnthis.cpp
  clang/tools/libclang/CXType.cpp
  llvm/include/llvm/BinaryFormat/Dwarf.def
  llvm/include/llvm/IR/CallingConv.h
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/AsmParser/LLToken.h
  llvm/lib/IR/AsmWriter.cpp
  llvm/lib/Target/AArch64/AArch64CallingConvention.cpp
  llvm/lib/Target/AArch64/AArch64FastISel.cpp
  llvm/lib/Target/AArch64/AArch64ISelLowering.cpp
  llvm/lib/Target/AArch64/AArch64ISelLowering.h
  llvm/lib/Target/AArch64/AArch64RegisterInfo.cpp
  llvm/lib/Target/AArch64/AArch64Subtarget.h
  llvm/lib/Target/AArch64/GISel/AArch64CallLowering.cpp
  llvm/test/CodeGen/AArch64/darwin_abi.ll
  llvm/test/CodeGen/AArch64/darwin_abi_vararg.ll

Index: llvm/test/CodeGen/AArch64/darwin_abi_vararg.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AArch64/darwin_abi_vararg.ll
@@ -0,0 +1,39 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=aarch64-pc-linux | FileCheck %s
+
+target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
+target triple = "aarch64-pc-linux"
+
+%struct.__va_list = type { i8*, i8*, i8*, i32, i32 }
+
+define dso_local aarch64_darwincc void @foo(i32 %n, ...) local_unnamed_addr #0 {
+; CHECK-LABEL: foo:
+; CHECK:   // %bb.0: // %entry
+; CHECK-NEXT:sub sp, sp, #48 // =48
+; CHECK-NEXT:stp x29, x30, [sp, #32] // 16-byte Folded Spill
+; CHECK-NEXT:add x29, sp, #32 // =32
+; CHECK-NEXT:add x8, x29, #16 // =16
+; CHECK-NEXT:mov x1, sp
+; CHECK-NEXT:str xzr, [sp, #24]
+; CHECK-NEXT:str x8, [sp]
+; CHECK-NEXT:bl vfoo
+; CHECK-NEXT:ldp x29, x30, [sp, #32] // 16-byte Folded Reload
+; CHECK-NEXT:add sp, sp, #48 // =48
+; CHECK-NEXT:ret
+entry:
+  %va = alloca %struct.__va_list, align 8
+  %0 = bitcast %struct.__va_list* %va to i8*
+  call void @llvm.va_start(i8* nonnull %0)
+  call void @vfoo(i32 %n, %struct.__va_list* nonnull %va) #1
+  call void @llvm.va_end(i8* nonnull %0)
+  ret void
+}
+
+declare void @llvm.va_start(i8*) #1
+
+declare dso_local void @vfoo(i32, %struct.__va_list*) local_unnamed_addr #0
+
+declare void @llvm.va_end(i8*) #1
+
+attributes #0 = { nounwind "disable-tail-calls"="false" "frame-pointer"="non-leaf" "target-cpu"="generic" }
+attributes #1 = { nounwind }
Index: llvm/test/CodeGen/AArch64/darwin_abi.ll
===
--- /dev/null
+++ llvm/test/CodeGen/AArch64/darwin_abi.ll
@@ -0,0 +1,29 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=aarch64-pc-linux | FileCheck %s
+
+target datalayout = "e-m:e-i8:8:32-i16:16:32-i64:64-i128:128-n32:64-S128"
+target triple = "aarch64-pc-linux"
+
+define dso_local aarch64_darwincc signext i16 @f1(i16 signext %a) local_unnamed_addr #0 {
+; CHECK-LABEL: f1:
+; CHECK:   // %bb.0: // %entry
+; CHECK-NEXT:add w8, w0, #1 // =1
+; CHECK-NEXT:sxth w0, w8
+; CHECK-NEXT:ret
+entry:
+  %add = add i16 %a, 1
+  ret i16 %add
+}
+
+define dso_local aarch64_darwincc zeroext i16 @f2(i16 zeroext %a) local_unnamed_addr #0 {
+; CHECK-LABEL: f2:
+; CHECK:   // %bb.0: // %entry
+; CHECK-NEXT:add w8, w0, #1 // =1
+; CHECK-NEXT:and w0, w8, #0x
+; CHECK-NEXT:ret
+entry:
+  %add = add i16 %a, 1
+  ret i16 %add
+}
+
+attributes #0 = { norecurse nounwind readnone "disable-tail-calls"="false" "frame-pointer"="non-leaf" "target-cpu"="generic" }
Index: llvm/lib/Target/AArch64/GISel/AArch64CallLowering.cpp
===
--- llvm/lib/Target/AArch64/GISel/AArch64CallLowering.cpp
+++ llvm/lib/Target/AArch64/GISel/AArch64CallLowering.cpp
@@ -474,8 +474,8 @@
   uint64_t StackOffset = Handler.StackUsed;
   if (F.isVarArg()) {
 auto &Subtarget = MF.getSubtarget();
-if (!Subtarget.isTargetDarwin()) {
-// FIXME: we need to reimplement saveVarArgsRegisters from
+if (!Subtarget.isCallingConvDarwin(MF.getF

[PATCH] D89277: [clangd] Add $/dumpMemoryTree LSP extension

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

This looks really nice!




Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:615
 {"workspaceSymbolProvider", true},
 {"referencesProvider", true},
 {"executeCommandProvider",

can you add `{"memoryTreeProvider", true} // clangd extension`?

I'd like to add client support in VSCode and it's useful if the command is only 
visible with versions of clangd that support it.



Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:1389
 
+void ClangdLSPServer::onDumpMemoryTree(const NoParams &,
+   Callback Reply) {

Putting the serialization code inline is a tempting option here because it's 
(mostly) just a map.
It's not something we do often though, so it does bury the protocol details in 
an unexpected place.

A couple of alternatives to consider:
 - map to a `struct UsageTree { unsigned Self; unsigned Total; Map Children; }` defined in protocol.h, and define marshalling in the 
usual way
 - skip the struct and use MemoryTree as the type, providing a toJSON(const 
MemoryTree&) function in protocol.h

I lean towards the last alternative because it provides a bit more regularity 
without adding much more redundancy, but this is up to you.



Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:1391
+   Callback Reply) {
+  llvm::BumpPtrAllocator Alloc;
+  MemoryTree MT(&Alloc);

nit: Alloc -> DetailAlloc



Comment at: clang-tools-extra/clangd/ClangdLSPServer.cpp:1458
   MsgHandler->bind("textDocument/semanticTokens/full/delta", 
&ClangdLSPServer::onSemanticTokensDelta);
+  MsgHandler->bind("$/dumpMemoryTree", &ClangdLSPServer::onDumpMemoryTree);
   if (Opts.FoldingRanges)

I think "dump" is a bit casual and also redundant - LSP methods to obtain 
information tend to have noun names. (executeCommand is the exception that 
proves the rule - it's used for side effects).

I went through the same question with the AST-dumping and landed on 
textDocument/ast as my preferred option, for what it's worth.



Comment at: clang-tools-extra/clangd/ClangdLSPServer.h:145
  Callback);
+  /// This is a clangd extension. Provides a json tree representing memory 
usage
+  /// hierarchy. Keys starting with an underscore(_) represent leaves, e.g.

(if you decide to move toJSON to protocol.h, then the second sentence onward 
probably belongs there)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89277

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

[PATCH] D89529: [clangd][remote] Add Windows paths support

[Aleksandr Platonov via Phabricator via cfe-commits]

ArcsinX created this revision.
Herald added subscribers: cfe-commits, usaxena95, kadircet, arphaman.
Herald added a project: clang.
ArcsinX requested review of this revision.
Herald added subscribers: MaskRay, ilya-biryukov.

Without this patch 7 marshalling tests fails on Windows.
This patch contains the following changes:

- Allow paths with Windows slashes.
- Add support for URI with Windows path.
- Change the value of the second parameter of several 
`llvm::sys::path::convert_to_slash()` calls: We should use `windows` instead of 
`posix` to ensure UNIX slashes in the path.
- Remove part of `RemoteMarshallingTest::IncludeHeaderURI` test which could not 
be ported on Windows.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D89529

Files:
  clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
  clang-tools-extra/clangd/unittests/remote/MarshallingTests.cpp


Index: clang-tools-extra/clangd/unittests/remote/MarshallingTests.cpp
===
--- clang-tools-extra/clangd/unittests/remote/MarshallingTests.cpp
+++ clang-tools-extra/clangd/unittests/remote/MarshallingTests.cpp
@@ -239,10 +239,6 @@
 
   clangd::Symbol::IncludeHeaderWithReferences Header;
   // Add only valid headers.
-  Header.IncludeHeader = Strings.save(
-  URI::createFile("/usr/local/user/home/project/Header.h").toString());
-  Header.References = 21;
-  Sym.IncludeHeaders.push_back(Header);
   Header.IncludeHeader = Strings.save("");
   Header.References = 100;
   Sym.IncludeHeaders.push_back(Header);
@@ -250,7 +246,7 @@
   Header.References = 200;
   Sym.IncludeHeaders.push_back(Header);
 
-  Marshaller ProtobufMarshaller(convert_to_slash("/"), convert_to_slash("/"));
+  Marshaller ProtobufMarshaller(testPath(""), testPath(""));
 
   auto Serialized = ProtobufMarshaller.toProtobuf(Sym);
   ASSERT_TRUE(bool(Serialized));
Index: clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
===
--- clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
+++ clang-tools-extra/clangd/index/remote/marshalling/Marshalling.cpp
@@ -52,17 +52,20 @@
 : Strings(Arena) {
   if (!RemoteIndexRoot.empty()) {
 assert(llvm::sys::path::is_absolute(RemoteIndexRoot));
-assert(RemoteIndexRoot ==
-   llvm::sys::path::convert_to_slash(RemoteIndexRoot));
-this->RemoteIndexRoot = RemoteIndexRoot.str();
-if (!RemoteIndexRoot.endswith(llvm::sys::path::get_separator()))
+llvm::SmallString<64> NativePath;
+llvm::sys::path::native(RemoteIndexRoot, NativePath);
+this->RemoteIndexRoot = NativePath.str().str();
+llvm::StringRef Path(*this->RemoteIndexRoot);
+if (!Path.endswith(llvm::sys::path::get_separator()))
   *this->RemoteIndexRoot += llvm::sys::path::get_separator();
   }
   if (!LocalIndexRoot.empty()) {
 assert(llvm::sys::path::is_absolute(LocalIndexRoot));
-assert(LocalIndexRoot == 
llvm::sys::path::convert_to_slash(LocalIndexRoot));
-this->LocalIndexRoot = LocalIndexRoot.str();
-if (!LocalIndexRoot.endswith(llvm::sys::path::get_separator()))
+llvm::SmallString<64> NativePath;
+llvm::sys::path::native(LocalIndexRoot, NativePath);
+this->LocalIndexRoot = NativePath.str().str();
+llvm::StringRef Path(*this->LocalIndexRoot);
+if (!Path.endswith(llvm::sys::path::get_separator()))
   *this->LocalIndexRoot += llvm::sys::path::get_separator();
   }
   assert(!RemoteIndexRoot.empty() || !LocalIndexRoot.empty());
@@ -92,6 +95,7 @@
   for (const auto &Path : Message->proximity_paths()) {
 llvm::SmallString<256> LocalPath = llvm::StringRef(*RemoteIndexRoot);
 llvm::sys::path::append(LocalPath, Path);
+llvm::sys::path::native(LocalPath);
 Result.ProximityPaths.push_back(std::string(LocalPath));
   }
   for (const auto &Type : Message->preferred_types())
@@ -209,7 +213,7 @@
 llvm::SmallString<256> RelativePath = llvm::StringRef(Path);
 if (llvm::sys::path::replace_path_prefix(RelativePath, *LocalIndexRoot, 
""))
   RPCRequest.add_proximity_paths(llvm::sys::path::convert_to_slash(
-  RelativePath, llvm::sys::path::Style::posix));
+  RelativePath, llvm::sys::path::Style::windows));
   }
   for (const auto &Type : From.PreferredTypes)
 RPCRequest.add_preferred_types(Type);
@@ -315,12 +319,19 @@
   if (ParsedURI->scheme() != "file")
 return error("Can not use URI schemes other than file, given: '{0}'.", 
URI);
   llvm::SmallString<256> Result = ParsedURI->body();
+  llvm::StringRef Path(Result);
+  // Check for Windows paths (URI=file:///X:/path => Body=/X:/path)
+  if (llvm::sys::path::is_absolute(Path.substr(1),
+   llvm::sys::path::Style::windows)) {
+Result = Path.drop_front();
+llvm::sys::path::native(Result);
+  }
   if (!llvm::sys::path::replace_path_prefix(Result, *RemoteIndexRoot, ""))
 return error("File path '{0}' doesn't

[PATCH] D89372: [OpenCL] Remove unused extensions

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In D89372#2333937 , @jvesely wrote:

> In D89372#2332997 , @Anastasia wrote:
>
>> In D89372#2332853 , @jvesely wrote:
>>
>>> `cl_khr_byte_addressable_stores` changes language semantics. without it, 
>>> pointer dereferences of types smaller than 32 bits are illegal.
>>
>> Ok, does it mean that we are missing to diagnose this in the frontend? Btw I 
>> do acknowledge that what you say makes sense but I don't think the 
>> documentation support that:
>> https://www.khronos.org/registry/OpenCL/sdk/2.2/docs/man/html/cl_khr_byte_addressable_store.html
>>
>> Am I just looking in the wrong place?
>
> Since it's only an extension in ocl 1.0 that spec is a better place to look:
>
>   9.9 Byte Addressable Stores 
>   Section 6.8.m describes restrictions on built-in types char, uchar, char2, 
> uchar2, short,
>   and half. The OpenCL extension cl_khr_byte_addressable_store removes these
>   restrictions.  An application that wants to be able to write to elements of 
> a pointer (or struct) that
>   are of type char, uchar, char2, uchar2, short, ushort and half will need to 
> include
>   the #pragma OPENCL EXTENSION cl_khr_byte_addressable_store :
>   enable directive before any code that performs writes that may not be 
> supported as per section
>   6.8.m.
>   
>   6.8 Restrictions
>   ...
>   m. Built-in types that are less than 32-bits in size i.e. char, uchar, 
> char2, uchar2,
>   short, ushort, and half have the following restriction:
>   Writes to a pointer (or arrays) of type char, uchar, char2, uchar2, short,
>   ushort, and half or to elements of a struct that are of type char, uchar,
>   char2, uchar2, short and ushort are not supported. Refer to section 9.9
>   for additional information.

Ok, thanks! I guess the documentation should be fixed in this URL to point to 
the place where this behavior is described, like for example in 
cl_khr_subgroups:
https://www.khronos.org/registry/OpenCL/sdk/2.2/docs/man/html/cl_khr_subgroups.html

>>> Even if all clang targets support this the macro should still be defined 
>>> for backward compatibility.
>>
>> Ok, are you saying that all targets currently support this and we sould 
>> always define it? In this case I would be more happy if we move them into 
>> the internal header that we add implicitly anyway...
>
> r600/r700/EG/NI targets have a bit wonky support byte-addressable stores 
> (basically using 32bit atomic MSKOR), but I don't expect those targets to 
> survive for long, and for now, they advertise support.
> some out of tree backends might also benefit from the extension (like legup 
> -- verilog backend), but I'm not sure if out of tree targets are worth 
> considering, or if they indeed make use of this extension.
> on a high-level, I could see a restriction to 32bit data paths be useful for 
> FPGA targets.
>
> moving the define it to header breaks OCL1.0 programs. Based on the specs 
> above. those programs are required to include the following:
>
>   #ifdef cl_khr_byte_addressable_store
>   #pragma OPENCL EXTENSION cl_khr_byte_addressable_store : enable
>   #endif
>
> Before they can dereference pointers to char/char2/short/... types (including 
> array indexing and struct members).
> so the `pragma` part needs to work, and the language level checks need to 
> work if the extension is not enabled.

Ok, so the pragma is supposed to control the pointer dereferencing which seems 
like a valid case but however, it is not implemented now. Do we know of any 
immediate plans from anyone to implement this? If not I would prefer to remove 
the pragma for now? If someone decided to implement this functionality later 
fully it is absolutely fine. Pragma will be very easy to add. There is no need 
for everyone to pay the price for something that can't be used at the moment.

> The same arguments also apply to `cles_khr_in64`. It's illegal to use int64 
> types in embedded profile unless you first enable the extensions. Rather than 
> removing it, `cles_khr_2d_image_array_writes` should be added to the 
> extension list.

I don't think clang currently support embedded profile. Adding extension into 
the OpenCLOptions is pointless if it's not used. Do you plan to add any 
functionality for it? Defining macros can be done easily outside of clang 
source code or if it is preferable to do inside there is 
`MacroBuilder::defineMacro`  available in the target hooks. Currently for every 
extension added into `OpenCLExtensions.def` there is a macro, a pragma and a 
field in `OpenCLOptions` added. This is often more than what is necessary. Plus 
Khronos has very many extensions if we assume that all of them are added in 
clang it will become scalability and maintanance nightmare. Most of the 
extensions only add functions so if we provide a way to add macros for those 
outside of clang code base it will keep the common cod

[PATCH] D89312: [SVE][CodeGen]Use getFixedSize() function for TypeSize comparison in clang

[Caroline via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGe8d9ee9c7cfe: [SVE][CodeGen]Use getFixedSize() function for 
TypeSize comparison in clang (authored by CarolineConcatto).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89312

Files:
  clang/lib/CodeGen/CGBuiltin.cpp


Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -5608,8 +5608,8 @@
 
   Value *Result = CGF.EmitNeonCall(F, Ops, s);
   llvm::Type *ResultType = CGF.ConvertType(E->getType());
-  if (ResultType->getPrimitiveSizeInBits() <
-  Result->getType()->getPrimitiveSizeInBits())
+  if (ResultType->getPrimitiveSizeInBits().getFixedSize() <
+  Result->getType()->getPrimitiveSizeInBits().getFixedSize())
 return CGF.Builder.CreateExtractElement(Result, C0);
 
   return CGF.Builder.CreateBitCast(Result, ResultType, s);


Index: clang/lib/CodeGen/CGBuiltin.cpp
===
--- clang/lib/CodeGen/CGBuiltin.cpp
+++ clang/lib/CodeGen/CGBuiltin.cpp
@@ -5608,8 +5608,8 @@
 
   Value *Result = CGF.EmitNeonCall(F, Ops, s);
   llvm::Type *ResultType = CGF.ConvertType(E->getType());
-  if (ResultType->getPrimitiveSizeInBits() <
-  Result->getType()->getPrimitiveSizeInBits())
+  if (ResultType->getPrimitiveSizeInBits().getFixedSize() <
+  Result->getType()->getPrimitiveSizeInBits().getFixedSize())
 return CGF.Builder.CreateExtractElement(Result, C0);
 
   return CGF.Builder.CreateBitCast(Result, ResultType, s);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] e8d9ee9 - [SVE][CodeGen]Use getFixedSize() function for TypeSize comparison in clang

[Caroline Concatto via cfe-commits]

Author: Caroline Concatto
Date: 2020-10-16T10:56:39+01:00
New Revision: e8d9ee9c7cfe46d9b552111a27d866fce0498b0a

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

LOG: [SVE][CodeGen]Use getFixedSize() function for TypeSize comparison in clang

This patch makes sure that the instance of TypeSize comparison operator
is done with a fixed type size.

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

Added: 


Modified: 
clang/lib/CodeGen/CGBuiltin.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 90bfeefc9970..183a1a097709 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -5608,8 +5608,8 @@ static Value *EmitCommonNeonSISDBuiltinExpr(
 
   Value *Result = CGF.EmitNeonCall(F, Ops, s);
   llvm::Type *ResultType = CGF.ConvertType(E->getType());
-  if (ResultType->getPrimitiveSizeInBits() <
-  Result->getType()->getPrimitiveSizeInBits())
+  if (ResultType->getPrimitiveSizeInBits().getFixedSize() <
+  Result->getType()->getPrimitiveSizeInBits().getFixedSize())
 return CGF.Builder.CreateExtractElement(Result, C0);
 
   return CGF.Builder.CreateBitCast(Result, ResultType, s);



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

[PATCH] D89277: [clangd] Add $/dumpMemoryTree LSP extension

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet updated this revision to Diff 298578.
kadircet marked 5 inline comments as done.
kadircet added a comment.

- Add memoryTreeProvider to initialization params
- Move serialization logic to Protocol.h and return MemoryTree directly.
- Drop `dump` from method name.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89277

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/Protocol.cpp
  clang-tools-extra/clangd/Protocol.h
  clang-tools-extra/clangd/test/initialize-params.test
  clang-tools-extra/clangd/test/memory_tree.test

Index: clang-tools-extra/clangd/test/memory_tree.test
===
--- /dev/null
+++ clang-tools-extra/clangd/test/memory_tree.test
@@ -0,0 +1,81 @@
+# RUN: clangd -lit-test < %s | FileCheck -strict-whitespace %s
+{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootPath":"clangd","capabilities":{},"trace":"off"}}
+---
+{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"test:///main.cpp","languageId":"cpp","version":1,"text":"void func() {}"}}}
+---
+{"jsonrpc":"2.0","id":1,"method":"$/memoryTree","params":{}}
+# CHECK:"id": 1,
+# CHECK-NEXT:   "jsonrpc": "2.0",
+# CHECK-NEXT:   "result": {
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}},
+# CHECK-NEXT: "clangd_server": {
+# CHECK-NEXT:   "_self": {{[0-9]+}},
+# CHECK-NEXT:   "_total": {{[0-9]+}},
+# CHECK-NEXT:   "dynamic_index": {
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}},
+# CHECK-NEXT: "main_file": {
+# CHECK-NEXT:   "_self": {{[0-9]+}},
+# CHECK-NEXT:   "_total": {{[0-9]+}},
+# CHECK-NEXT:   "index": {
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}}
+# CHECK-NEXT:   },
+# CHECK-NEXT:   "symbols": {
+# CHECK-NEXT: "{{.*}}main.cpp": {
+# CHECK-NEXT:   "_self": {{[0-9]+}},
+# CHECK-NEXT:   "_total": {{[0-9]+}},
+# CHECK-NEXT:   "references": {
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}}
+# CHECK-NEXT:   },
+# CHECK-NEXT:   "relations": {
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}}
+# CHECK-NEXT:   },
+# CHECK-NEXT:   "symbols": {
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}}
+# CHECK-NEXT:   }
+# CHECK-NEXT: },
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}}
+# CHECK-NEXT:   }
+# CHECK-NEXT: },
+# CHECK-NEXT: "preamble": {
+# CHECK-NEXT:   "_self": {{[0-9]+}},
+# CHECK-NEXT:   "_total": {{[0-9]+}},
+# CHECK-NEXT:   "index": {
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}}
+# CHECK-NEXT:   },
+# CHECK-NEXT:   "symbols": {
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}}
+# CHECK-NEXT:   }
+# CHECK-NEXT: }
+# CHECK-NEXT:   },
+# CHECK-NEXT:   "tuscheduler": {
+# CHECK-NEXT: "{{.*}}main.cpp": {
+# CHECK-NEXT:   "_self": {{[0-9]+}},
+# CHECK-NEXT:   "_total": {{[0-9]+}},
+# CHECK-NEXT:   "ast": {
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}}
+# CHECK-NEXT:   },
+# CHECK-NEXT:   "preamble": {
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}}
+# CHECK-NEXT:   }
+# CHECK-NEXT: },
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}}
+# CHECK-NEXT:   }
+# CHECK-NEXT: }
+# CHECK-NEXT:   }
+---
+{"jsonrpc":"2.0","id":3,"method":"shutdown"}
+---
+{"jsonrpc":"2.0","method":"exit"}
+
Index: clang-tools-extra/clangd/test/initialize-params.test
===
--- clang-tools-extra/clangd/test/initialize-params.test
+++ clang-tools-extra/clangd/test/initialize-params.test
@@ -66,6 +66,7 @@
 # CHECK-NEXT:]
 # CHECK-NEXT:  },
 # CHECK-NEXT:  "hoverProvider": true,
+# CHECK-NEXT:  "memoryTreeProvider": true
 # CHECK-NEXT:  "referencesProvider": true,
 # CHECK-NEXT:  "renameProvider": true,
 # CHECK-NEXT:  "selectionRangeProvider": true,
Index: clang-tools-extra/clangd/Protocol.h
===
--- clang-tools-extra/clangd/Protocol.h
+++ clang-tools-extra/clangd/Protocol.h
@@ -25,6 +25,7 @@
 
 #include "URI.h"
 #include "index/SymbolID.h"

[PATCH] D89407: [clang-tidy] Add scoped enum constants to identifier naming check

[Nathan James via Phabricator via cfe-commits]

njames93 added a comment.

In D89407#2333560 , @Eugene.Zelenko 
wrote:

> I think will be good idea to add test for suffix/prefix too.

Not strictly necessary, there are tests that make sure prefixes and suffixes 
are applied correctly. Then there are tests that make sure a type of decl is 
correctly matched against its style, this is one of these tests. You'll find 
that's the convention with most of the style types tests in here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89407

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

[PATCH] D89529: [clangd][remote] Add Windows paths support

[Kirill Bobyrev via Phabricator via cfe-commits]

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

Hi, thanks for flagging the issue! Could you please give more information where 
exactly the tests fail (e.g. logs with assertions)? This way I could understand 
where exactly the failure happens.

I can understand what you're trying to do but the patch introduces the 
behaviour which is unintended as of right now. The convention is to use POSIX 
paths everywhere in the Marshalling code since the end result will be a URI 
anyway. The patch changes it to Windows slashes which is orthogonal to this 
direction.

You're right about `llvm::Expected 
Marshaller::fromProtobuf` needing to convert to the native path though since 
there aren't any URIs in the end. Also, I think we should convert roots to the 
POSIX instead of asserting it.

I'm really curious what failures beyond `FuzzyFindRequest` are on Windows and 
I'd be happy to fix those but unfortunately I don't have a Windows machine to 
run the tests myself :(


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89529

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

[PATCH] D89529: [clangd][remote] Add Windows paths support

[Aleksandr Platonov via Phabricator via cfe-commits]

ArcsinX added a comment.

In D89529#2334407 , @kbobyrev wrote:

> Hi, thanks for flagging the issue! Could you please give more information 
> where exactly the tests fail (e.g. logs with assertions)? This way I could 
> understand where exactly the failure happens.

With current implementation I could not pass Windows path (e.g. C:\a\b\c) to 
`Marshaller` constructor because of  `assert(RemoteIndexRoot ==  
llvm::sys::path::convert_to_slash(RemoteIndexRoot));`, because on Windows  
`llvm::sys::path::convert_to_slash(RemoteIndexRoot)` converts C:\a\b\c to 
C:/a/b/c

Another problem is that Windows URI paths are not supported without this patch 
(e.g. URI=file:///X:/path => Body=/X:/path, and /X:/path does not start with 
X:\path)

The third problem, that without conversion local windows paths to native 
slashes, mixes-slash paths appears at `path::append()` calls and we again face 
the problem when some paths does not start with given prefix (but it should)

> I can understand what you're trying to do but the patch introduces the 
> behaviour which is unintended as of right now. The convention is to use POSIX 
> paths everywhere in the Marshalling code since the end result will be a URI 
> anyway. The patch changes it to Windows slashes which is orthogonal to this 
> direction.

Idea is to use native slashes (Windows slashes on Windows) *for local paths 
only* and UNIX slashes inside the wire.

Just to clarify why I changed `llvm::sys::path::convert_to_slash(Result, 
llvm::sys::path::Style::posix)` to `llvm::sys::path::convert_to_slash(Result, 
llvm::sys::path::Style::windows)`:

- `llvm::sys::path::convert_to_slash(Result, llvm::sys::path::Style::posix)` 
no-op on any platform and does nothing with '\' in Windows paths.
- `llvm::sys::path::convert_to_slash(Result, llvm::sys::path::Style::windows)` 
replaces '\' with '/' on any platform.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89529

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

[PATCH] D89529: [clangd][remote] Add Windows paths support

[Aleksandr Platonov via Phabricator via cfe-commits]

ArcsinX added a comment.

Logs:

  D:\work\llvm-project\build>ninja check-clangd
  [6/7] Running the Clangd regression tests
  llvm-lit.py: 
D:\work\llvm-project\build\bin\..\..\llvm\utils\lit\lit\llvm\config.py:347: 
note: using clang: d:\work\llvm-project\build\bin\clang.exe
  -- Testing: 905 tests, 8 workers --
  Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70
  FAIL: Clangd Unit Tests :: 
./ClangdTests.exe/RemoteMarshallingTest.IncludeHeaderURIs (665 of 905)
   TEST 'Clangd Unit Tests :: 
./ClangdTests.exe/RemoteMarshallingTest.IncludeHeaderURIs' FAILED 

  Note: Google Test filter = RemoteMarshallingTest.IncludeHeaderURIs
  [==] Running 1 test from 1 test case.
  [--] Global test environment set-up.
  [--] 1 test from RemoteMarshallingTest
  [ RUN  ] RemoteMarshallingTest.IncludeHeaderURIs
  
D:\work\llvm-project\clang-tools-extra\clangd\unittests\remote\MarshallingTests.cpp(256):
 error: Value of: bool(Serialized)
Actual: false
  Expected: true
  [  FAILED  ] RemoteMarshallingTest.IncludeHeaderURIs (1 ms)
  [--] 1 test from RemoteMarshallingTest (1 ms total)
  
  [--] Global test environment tear-down
  [==] 1 test from 1 test case ran. (1 ms total)
  [  PASSED  ] 0 tests.
  [  FAILED  ] 1 test, listed below:
  [  FAILED  ] RemoteMarshallingTest.IncludeHeaderURIs
  
   1 FAILED TEST
  
  
  Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70
  FAIL: Clangd Unit Tests :: 
./ClangdTests.exe/RemoteMarshallingTest.RefSerialization (666 of 905)
   TEST 'Clangd Unit Tests :: 
./ClangdTests.exe/RemoteMarshallingTest.RefSerialization' FAILED 

  Note: Google Test filter = RemoteMarshallingTest.RefSerialization
  [==] Running 1 test from 1 test case.
  [--] Global test environment set-up.
  [--] 1 test from RemoteMarshallingTest
  [ RUN  ] RemoteMarshallingTest.RefSerialization
  
D:\work\llvm-project\clang-tools-extra\clangd\unittests\remote\MarshallingTests.cpp(228):
 error: Value of: bool(Serialized)
Actual: false
  Expected: true
  [  FAILED  ] RemoteMarshallingTest.RefSerialization (0 ms)
  [--] 1 test from RemoteMarshallingTest (0 ms total)
  
  [--] Global test environment tear-down
  [==] 1 test from 1 test case ran. (0 ms total)
  [  PASSED  ] 0 tests.
  [  FAILED  ] 1 test, listed below:
  [  FAILED  ] RemoteMarshallingTest.RefSerialization
  
   1 FAILED TEST
  
  
  Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70
  FAIL: Clangd Unit Tests :: 
./ClangdTests.exe/RemoteMarshallingTest.URIToRelativePathTranslation (673 of 
905)
   TEST 'Clangd Unit Tests :: 
./ClangdTests.exe/RemoteMarshallingTest.URIToRelativePathTranslation' FAILED 

  Note: Google Test filter = RemoteMarshallingTest.URIToRelativePathTranslation
  [==] Running 1 test from 1 test case.
  [--] Global test environment set-up.
  [--] 1 test from RemoteMarshallingTest
  [ RUN  ] RemoteMarshallingTest.URIToRelativePathTranslation
  
D:\work\llvm-project\clang-tools-extra\clangd\unittests\remote\MarshallingTests.cpp(436):
 error: Value of: bool(RelativePath)
Actual: false
  Expected: true
  [  FAILED  ] RemoteMarshallingTest.URIToRelativePathTranslation (1 ms)
  [--] 1 test from RemoteMarshallingTest (1 ms total)
  
  [--] Global test environment tear-down
  [==] 1 test from 1 test case ran. (1 ms total)
  [  PASSED  ] 0 tests.
  [  FAILED  ] 1 test, listed below:
  [  FAILED  ] RemoteMarshallingTest.URIToRelativePathTranslation
  
   1 FAILED TEST
  
  
  Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70
  FAIL: Clangd Unit Tests :: 
./ClangdTests.exe/RemoteMarshallingTest.RelationsSerializion (675 of 905)
   TEST 'Clangd Unit Tests :: 
./ClangdTests.exe/RemoteMarshallingTest.RelationsSerializion' FAILED 

  Note: Google Test filter = RemoteMarshallingTest.RelationsSerializion
  [==] Running 1 test from 1 test case.
  [--] Global test environment set-up.
  [--] 1 test from RemoteMarshallingTest
  [ RUN  ] RemoteMarshallingTest.RelationsSerializion
  
D:\work\llvm-project\clang-tools-extra\clangd\unittests\remote\MarshallingTests.cpp(407):
 error: Value of: bool(Serialized)
Actual: false
  Expected: true
  [  FAILED  ] RemoteMarshallingTest.RelationsSerializion (0 ms)
  [--] 1 test from RemoteMarshallingTest (0 ms total)
  
  [--] Global test environment tear-down
  [==] 1 test from 1 test case ran. (1 ms total)
  [  PASSED  ] 0 tests.
  [  FAILED  ] 1 test, listed below:
  [  FAILED  ] RemoteMarshallingTest.RelationsSerializion
  
   1 FAILED TEST
  
  
  Testing:  0.. 10.. 20.. 30.. 40.. 50.. 60.. 70
  FAIL: Clangd Unit Tests :: 
./ClangdTests.exe/RemoteMarshallingTest.URITranslation (676 of 

[PATCH] D89520: Don't permit array bound constant folding in OpenCL.

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

> Permitting non-standards-driven "do the best you can" constant-folding
> of array bounds is permitted solely as a GNU compatibility feature. We
> should not be doing it in any language mode that is attempting to be
> conforming.
>
> From https://reviews.llvm.org/D20090 it appears the intent here was to
> permit __constant int globals to be used in array bounds, but the
> change in that patch only added half of the functionality necessary to
> support that in the constant evaluator. This patch adds the other half
> of the functionality and turns off constant folding for array bounds in
> OpenCL.
>
> I couldn't find any spec justification for accepting the kinds of cases
> that D20090  accepts, so a reference to 
> where in the OpenCL specification
> this is permitted would be useful.

Thanks for fixing this. I agree that the original change was not compliant with 
the spec. OpenCL indeed doesn't allow constant folding for array bounds. The 
idea of the change was to allow using expressions that are compile time 
constant in the array bound because this doesn't result in VLA.

Regarding the spec reference, I think we can refer to the section 6.5.3 
describing variables in the `__constant` address space:

  These variables  are  required  to  be  initialized  and  the  values  used  
to  initialize  these  variables  must  be  a compile time constant. Writing to 
such a variable results in a compile-time error.

I.e. the `__constant` address space variables are semantically similar to 
`constexpr` in C++.

> Note that this change also affects the code generation in one test:
> because after 'const int n = 0' we now treat 'n' as a constant
> expression with value 0, it's now a null pointer, so '(local int *)n'
> forms a null pointer rather than a zero pointer.

I am slightly confused about this case because technically the value of 'n' can 
be overwritten by casting away const. However, I suspect this is compliant C99 
behavior?

This example:

  void test(void) {
const int x = 0;
const int* ptrx = &x;
int* ptry = (int*)ptrx;
*ptry = 100; 
int *sp5 = ( int*)x;
  }

shows that the IR produced is indeed supposed to have NULL despite of the fact 
that the value of initializing variable is not 0 at the time of the last 
initialization.

  store i32* null, i32** %4, align 8




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89520

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

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

[Roman Lebedev via Phabricator via cfe-commits]

lebedev.ri added a subscriber: thakis.
lebedev.ri added a comment.
Herald added a subscriber: wenlei.

@paulkirth @phosek @leonardchan @thakis @nickdesaulniers
It seems to me that this feature is still broken an unusable - 
https://bugs.llvm.org/show_bug.cgi?id=45073 -and the bug was reported more than 
half a year ago.
If no one is willing to step up and fix it, the i can only assume that no one 
is using this and or cares, and this broken incomplete feature should be 
reverted.


Repository:
  rL LLVM

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

https://reviews.llvm.org/D66324

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

[PATCH] D89487: [AMDGPU] gfx1032 target

[Stanislav Mekhanoshin via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rGd1beb95d1241: [AMDGPU] gfx1032 target (authored by rampitec).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89487

Files:
  clang/include/clang/Basic/Cuda.h
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/NVPTX.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/test/CodeGenOpenCL/amdgpu-features.cl
  clang/test/Driver/amdgpu-macros.cl
  clang/test/Driver/amdgpu-mcpu.cl
  llvm/docs/AMDGPUUsage.rst
  llvm/include/llvm/BinaryFormat/ELF.h
  llvm/include/llvm/Support/TargetParser.h
  llvm/lib/ObjectYAML/ELFYAML.cpp
  llvm/lib/Support/TargetParser.cpp
  llvm/lib/Target/AMDGPU/GCNProcessors.td
  llvm/lib/Target/AMDGPU/MCTargetDesc/AMDGPUTargetStreamer.cpp
  llvm/test/CodeGen/AMDGPU/elf-header-flags-mach.ll
  llvm/test/CodeGen/AMDGPU/hsa-note-no-func.ll
  llvm/test/MC/AMDGPU/gfx1030_err.s
  llvm/test/MC/AMDGPU/gfx1030_new.s
  llvm/test/MC/Disassembler/AMDGPU/gfx1030_dasm_new.txt
  llvm/tools/llvm-readobj/ELFDumper.cpp

Index: llvm/tools/llvm-readobj/ELFDumper.cpp
===
--- llvm/tools/llvm-readobj/ELFDumper.cpp
+++ llvm/tools/llvm-readobj/ELFDumper.cpp
@@ -1781,6 +1781,7 @@
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1012),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1030),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1031),
+  LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_MACH_AMDGCN_GFX1032),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_XNACK),
   LLVM_READOBJ_ENUM_ENT(ELF, EF_AMDGPU_SRAM_ECC)
 };
Index: llvm/test/MC/Disassembler/AMDGPU/gfx1030_dasm_new.txt
===
--- llvm/test/MC/Disassembler/AMDGPU/gfx1030_dasm_new.txt
+++ llvm/test/MC/Disassembler/AMDGPU/gfx1030_dasm_new.txt
@@ -1,5 +1,6 @@
 # RUN: llvm-mc -arch=amdgcn -mcpu=gfx1030 -disassemble -show-encoding < %s | FileCheck -check-prefix=GFX10 %s
 # RUN: llvm-mc -arch=amdgcn -mcpu=gfx1031 -disassemble -show-encoding < %s | FileCheck -check-prefix=GFX10 %s
+# RUN: llvm-mc -arch=amdgcn -mcpu=gfx1032 -disassemble -show-encoding < %s | FileCheck -check-prefix=GFX10 %s
 
 # GFX10: global_load_dword_addtid v1, s[2:3] offset:16
 0x10,0x80,0x58,0xdc,0x00,0x00,0x02,0x01
Index: llvm/test/MC/AMDGPU/gfx1030_new.s
===
--- llvm/test/MC/AMDGPU/gfx1030_new.s
+++ llvm/test/MC/AMDGPU/gfx1030_new.s
@@ -1,5 +1,6 @@
 // RUN: llvm-mc -arch=amdgcn -mcpu=gfx1030 -show-encoding %s | FileCheck --check-prefix=GFX10 %s
 // RUN: llvm-mc -arch=amdgcn -mcpu=gfx1031 -show-encoding %s | FileCheck --check-prefix=GFX10 %s
+// RUN: llvm-mc -arch=amdgcn -mcpu=gfx1032 -show-encoding %s | FileCheck --check-prefix=GFX10 %s
 
 global_load_dword_addtid v1, s[2:3] offset:16
 // GFX10: encoding: [0x10,0x80,0x58,0xdc,0x00,0x00,0x02,0x01]
Index: llvm/test/MC/AMDGPU/gfx1030_err.s
===
--- llvm/test/MC/AMDGPU/gfx1030_err.s
+++ llvm/test/MC/AMDGPU/gfx1030_err.s
@@ -1,5 +1,6 @@
 // RUN: not llvm-mc -arch=amdgcn -mcpu=gfx1030 %s 2>&1 | FileCheck --check-prefix=GFX10 --implicit-check-not=error: %s
 // RUN: not llvm-mc -arch=amdgcn -mcpu=gfx1031 %s 2>&1 | FileCheck --check-prefix=GFX10 --implicit-check-not=error: %s
+// RUN: not llvm-mc -arch=amdgcn -mcpu=gfx1032 %s 2>&1 | FileCheck --check-prefix=GFX10 --implicit-check-not=error: %s
 
 v_dot8c_i32_i4 v5, v1, v2
 // GFX10: :[[@LINE-1]]:{{[0-9]+}}: error: instruction not supported on this GPU
Index: llvm/test/CodeGen/AMDGPU/hsa-note-no-func.ll
===
--- llvm/test/CodeGen/AMDGPU/hsa-note-no-func.ll
+++ llvm/test/CodeGen/AMDGPU/hsa-note-no-func.ll
@@ -30,6 +30,7 @@
 ; RUN: llc < %s -mtriple=amdgcn--amdhsa -mcpu=gfx1012 --amdhsa-code-object-version=2 | FileCheck --check-prefix=HSA --check-prefix=HSA-GFX1012 %s
 ; RUN: llc < %s -mtriple=amdgcn--amdhsa -mcpu=gfx1030 --amdhsa-code-object-version=2 | FileCheck --check-prefix=HSA --check-prefix=HSA-GFX1030 %s
 ; RUN: llc < %s -mtriple=amdgcn--amdhsa -mcpu=gfx1031 --amdhsa-code-object-version=2 | FileCheck --check-prefix=HSA --check-prefix=HSA-GFX1031 %s
+; RUN: llc < %s -mtriple=amdgcn--amdhsa -mcpu=gfx1032 --amdhsa-code-object-version=2 | FileCheck --check-prefix=HSA --check-prefix=HSA-GFX1032 %s
 
 ; HSA: .hsa_code_object_version 2,1
 ; HSA-SI600: .hsa_code_object_isa 6,0,0,"AMD","AMDGPU"
@@ -54,3 +55,4 @@
 ; HSA-GFX1012: .hsa_code_object_isa 10,1,2,"AMD","AMDGPU"
 ; HSA-GFX1030: .hsa_code_object_isa 10,3,0,"AMD","AMDGPU"
 ; HSA-GFX1031: .hsa_code_object_isa 10,3,1,"AMD","AMDGPU"
+; HSA-GFX1032: .hsa_code_object_isa 10,3,2,"AMD","AMDGPU"
Index: llvm/test/CodeGen/AMDGPU/elf-header-flags-mach.ll
===

[PATCH] D89487: [AMDGPU] gfx1032 target

[Stanislav Mekhanoshin via Phabricator via cfe-commits]

rampitec added inline comments.



Comment at: clang/test/Driver/amdgpu-macros.cl:216
 // GFX1031-DAG: #define FP_FAST_FMA 1
+// GFX1032-DAG: #define FP_FAST_FMA 1
 

tra wrote:
> This test could use some refactoring.
> Individual macro checks could be collapsed to
> 
> ```
> // RUN: ... --check-prefixes=...,FMA
> //  FMA-DAG: #define FP_FAST_FMA 1
> ```
> 
Thanks! That makes sense.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89487

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

[PATCH] D87279: [clang] Fix handling of physical registers in inline assembly operands.

[Jonas Paulsson via Phabricator via cfe-commits]

jonpa added a comment.

The problem seems to be with a tied earlyclobber operand:

  asm("" : "+&r"(a));

Per the comment in InlineAsm::ConstraintInfo::Parse(), only output can be 
earlyclobber.

I am not sure if the earlyclobber ('&') should with this patch be removed from 
the added use of the register, or if this has to for some reason really be tied 
to the def?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87279

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

[PATCH] D89529: [clangd][remote] Add Windows paths support

[Kirill Bobyrev via Phabricator via cfe-commits]

kbobyrev added a comment.

In D89529#2334475 , @ArcsinX wrote:

> In D89529#2334407 , @kbobyrev wrote:
>
>> Hi, thanks for flagging the issue! Could you please give more information 
>> where exactly the tests fail (e.g. logs with assertions)? This way I could 
>> understand where exactly the failure happens.
>
> With current implementation I could not pass Windows path (e.g. C:\a\b\c) to 
> `Marshaller` constructor because of  `assert(RemoteIndexRoot ==  
> llvm::sys::path::convert_to_slash(RemoteIndexRoot));`, because on Windows  
> `llvm::sys::path::convert_to_slash(RemoteIndexRoot)` converts C:\a\b\c to 
> C:/a/b/c

Yes, I mentioned it above. The solution would be to just convert to the POSIX 
path instead of asserting it.

> Another problem is that Windows URI paths are not supported without this 
> patch (e.g. URI=file:///X:/path => Body=/X:/path, and /X:/path does not start 
> with X:\path)

This is an interesting problem and I think this should be covered by the URI 
code that we have but I should check. This might have been triggered by a 
different issue.

> The third problem, that without conversion local Windows paths to native 
> slashes, mixed-slash paths appears at `path::append()` calls and we again 
> face the problem when some paths does not start with given prefix (but it 
> should)

Yes, I mentioned it above. This is not an actual problem if all the paths 
within marshalling are POSIX style. There is a problem with

>> I can understand what you're trying to do but the patch introduces the 
>> behaviour which is unintended as of right now. The convention is to use 
>> POSIX paths everywhere in the Marshalling code since the end result will be 
>> a URI anyway. The patch changes it to Windows slashes which is orthogonal to 
>> this direction.
>
> Idea is to use native slashes (Windows slashes on Windows) *for local paths 
> only* and UNIX slashes inside the wire.
>
> Just to clarify why I changed `llvm::sys::path::convert_to_slash(Result, 
> llvm::sys::path::Style::posix)` to `llvm::sys::path::convert_to_slash(Result, 
> llvm::sys::path::Style::windows)`:
>
> - `llvm::sys::path::convert_to_slash(Result, llvm::sys::path::Style::posix)` 
> no-op on any platform and does nothing with '\' in Windows paths.

Yeah you're right, I missed these `convert_to_slash` semantics and that should 
be changed.

> - `llvm::sys::path::convert_to_slash(Result, 
> llvm::sys::path::Style::windows)` replaces '\' with '/' on any platform.

We don't have actual filesystem paths anywhere outside `FuzzyFindRequest`, 
every other clangd struct stores URIs rather than paths. And when the URI is 
created it doesn't matter whether this path would be a Windows or POSIX, a URI 
is portable. Hence, the only place with native paths should be the 
`FuzzyFindRequest` translation.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89529

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

[PATCH] D87279: [clang] Fix handling of physical registers in inline assembly operands.

[Ulrich Weigand via Phabricator via cfe-commits]

uweigand added a comment.

In D87279#2334510 , @jonpa wrote:

> The problem seems to be with a tied earlyclobber operand:
>
>   asm("" : "+&r"(a));
>
> Per the comment in InlineAsm::ConstraintInfo::Parse(), only output can be 
> earlyclobber.
>
> I am not sure if the earlyclobber ('&') should with this patch be removed 
> from the added use of the register, or if this has to for some reason really 
> be tied to the def?

So we have a read/write tied earlyclobber operand that is also tied to a phyreg 
via an asm register declaration?   That means that: the physreg is used as 
input, it is also used as output, and it is written to before all inputs are 
read (i.e. no *other* input may share the same register, even if it would 
otherwise hold the same value).

I believe there is no way to represent the effect of a read/write tied 
earlyclobber in any other way.  E.g. trying to use separate inputs/outputs (one 
with "=&r", one with "r") does not work since the earlyclobber on the output 
would prevent the same register to be used for the input, but it *has* to be 
the same register ...

On on other hand, in this special case the original problem cannot actually 
occur, because there cannot be any other input using the same physreg (that's 
what the earlyclobber ensures), so maybe be just don't do that transformation 
if an earlyclobber is present?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D87279

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

[PATCH] D89529: [clangd][remote] Add Windows paths support

[Aleksandr Platonov via Phabricator via cfe-commits]

ArcsinX added a comment.

In D89529#2334517 , @kbobyrev wrote:

> In D89529#2334475 , @ArcsinX wrote:
>
>> In D89529#2334407 , @kbobyrev wrote:
>>
>>> Hi, thanks for flagging the issue! Could you please give more information 
>>> where exactly the tests fail (e.g. logs with assertions)? This way I could 
>>> understand where exactly the failure happens.
>>
>> With current implementation I could not pass Windows path (e.g. C:\a\b\c) to 
>> `Marshaller` constructor because of  `assert(RemoteIndexRoot ==  
>> llvm::sys::path::convert_to_slash(RemoteIndexRoot));`, because on Windows  
>> `llvm::sys::path::convert_to_slash(RemoteIndexRoot)` converts C:\a\b\c to 
>> C:/a/b/c
>
> Yes, I mentioned it above. The solution would be to just convert to the POSIX 
> path instead of asserting it.

Ok, got your point. I will think about this.
But for me it's hard to see the reason why we need to store local paths in 
POSIX style instead of native. From my point of view, we need to ensure that 
paths inside the wire are in POSIX style and nothing more. E.g. clangd converts 
paths extracted from LSP to native style.

>> Another problem is that Windows URI paths are not supported without this 
>> patch (e.g. URI=file:///X:/path => Body=/X:/path, and /X:/path does not 
>> start with X:\path)
>
> This is an interesting problem and I think this should be covered by the URI 
> code that we have but I should check. This might have been triggered by a 
> different issue.

https://github.com/llvm/llvm-project/blob/master/clang-tools-extra/clangd/URI.cpp#L51

The reason why I put this all together is that single change leads to the same 
amount of tests failures (test just fails by other reason).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89529

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

[PATCH] D88859: APINotes: add APINotesYAMLCompiler

[Gabor Marton via Phabricator via cfe-commits]

martong added a comment.

Seems like this patch handles already existing attributes in Clang, so this 
might not be affected by the concerns brought up here by James:
http://lists.llvm.org/pipermail/cfe-dev/2020-October/066996.html




Comment at: clang/include/clang/APINotes/APINotesYAMLCompiler.h:16
+namespace api_notes {
+bool parseAndDumpAPINotes(llvm::StringRef YI);
+}

It would be useful to have more documentation here.



Comment at: clang/include/clang/APINotes/Types.h:1
+//===-- Types.h - API Notes Data Types --*- C++ 
-*-===//
+//

So we are mapping existing attributes here, I am missing this to be documented. 
Why do we support only these attributes?
Would be consistent to put `SwiftPrivate` here as well, instead of implicitly 
interpreting that as `bool` in `APINotesYAMLCompiler.cpp`, wouldn't it?
I think we should list all processed attributes here, or we should just use 
`Attrs.inc` (see below my comment as well).



Comment at: clang/include/clang/APINotes/Types.h:25
+/// auditing.
+enum class EnumExtensibilityKind {
+  None,

This seems a bit redundant to `Attrs.td`. I'd prefer to have the structure of 
an attribute defined only in one place. Why can't we directly reuse the types 
in the generated `Attrs.inc`? In this case
```
class EnumExtensibilityAttr : public InheritableAttr {
public:
  enum Kind {
Closed,
Open
  };
```
could perfectly fit, wouldn't it?



Comment at: clang/include/clang/APINotes/Types.h:32
+/// The kind of a swift_wrapper/swift_newtype.
+enum class SwiftWrapperKind {
+  None,

Should this be rather `SwiftNewTypeKind`? Since `swift_wrapper` is deprecated 
according to the docs: 
https://clang.llvm.org/docs/AttributeReference.html#swift-newtype



Comment at: clang/lib/APINotes/APINotesYAMLCompiler.cpp:240
+namespace {
+struct Class {
+  StringRef Name;

Why are these classes in a unnamed namespace? I'd expect them to be in the 
header under the `clang::api_notes` namespace, so users of the 
APINotesYAMLCompiler could use these as the structured form of the YAML 
content. Isn't that the point of the whole stuff?



Comment at: clang/lib/APINotes/APINotesYAMLCompiler.cpp:439
+  static void enumeration(IO &IO, EnumExtensibilityKind &EEK) {
+IO.enumCase(EEK, "none",   EnumExtensibilityKind::None);
+IO.enumCase(EEK, "open",   EnumExtensibilityKind::Open);

Hmm, why do we need "none"? Can't we interpret the non-existence as "none"?



Comment at: clang/lib/APINotes/APINotesYAMLCompiler.cpp:621
+
+  llvm::yaml::Output OS(llvm::outs());
+  OS << M;

I think the stream (`llvm::outs`) should not be written in stone. And why not 
`llvm::errs` (we `dump` to `errs` usually) ? Could it be a parameter?



Comment at: 
clang/test/APINotes/Inputs/Frameworks/Simple.framework/Headers/Simple.apinotes:1
+Name:SimpleKit
+Classes:

I am pretty sure this does not provide a full coverage. What about e.g 
`Functions`? I'd like to see them tested as well.



Comment at: clang/test/APINotes/yaml-roundtrip.test:4
+
+We expect only the nullability to be different as it is canonicalized during 
the
+roudtrip.

Why do we have this difference? This seems odd and as a superfluous complexity.



Comment at: clang/tools/apinotes-test/APINotesTest.cpp:22
+
+  for (const auto &Notes : APINotes) {
+llvm::ErrorOr> NotesOrError =

`auto` -> `std::string`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88859

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

[clang-tools-extra] 8a548bc - [clang-tidy] modernize-loop-convert reverse iteration support

[Nathan James via cfe-commits]

Author: Nathan James
Date: 2020-10-16T14:16:30+01:00
New Revision: 8a548bc203cfb0b2f830959cb7ec578c25512025

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

LOG: [clang-tidy] modernize-loop-convert reverse iteration support

Enables support for transforming loops of the form
```
for (auto I = Cont.rbegin(), E = Cont.rend(); I != E;++I)
```

This is done automatically in C++20 mode using `std::ranges::reverse_view` but 
there are options to specify a different function to reverse iterator over a 
container.
This is the first step, down the line I'd like to possibly extend this support 
for array based loops
```
for (unsigned I = Arr.size() - 1;I >=0;--I) Arr[I]...
```

Currently if you pass a reversing function with no header in the options it 
will just assume that the function exists, however as we have the ASTContext it 
may be as wise to check before applying, or at least lower the confidence level 
if we can't find it.

Reviewed By: alexfh

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

Added: 

clang-tools-extra/test/clang-tidy/checkers/modernize-loop-convert-reverse.cpp

Modified: 
clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.h
clang-tools-extra/clang-tidy/modernize/LoopConvertUtils.h
clang-tools-extra/docs/ReleaseNotes.rst
clang-tools-extra/docs/clang-tidy/checks/modernize-loop-convert.rst

Removed: 




diff  --git a/clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp 
b/clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
index b90af1521baf..20791c60339a 100644
--- a/clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
+++ b/clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
@@ -19,6 +19,8 @@
 #include "llvm/ADT/StringRef.h"
 #include "llvm/ADT/StringSwitch.h"
 #include "llvm/Support/Casting.h"
+#include "llvm/Support/WithColor.h"
+#include "llvm/Support/raw_ostream.h"
 #include 
 #include 
 #include 
@@ -57,6 +59,7 @@ namespace modernize {
 
 static const char LoopNameArray[] = "forLoopArray";
 static const char LoopNameIterator[] = "forLoopIterator";
+static const char LoopNameReverseIterator[] = "forLoopReverseIterator";
 static const char LoopNamePseudoArray[] = "forLoopPseudoArray";
 static const char ConditionBoundName[] = "conditionBound";
 static const char ConditionVarName[] = "conditionVar";
@@ -68,7 +71,6 @@ static const char ConditionEndVarName[] = "conditionEndVar";
 static const char EndVarName[] = "endVar";
 static const char DerefByValueResultName[] = "derefByValueResult";
 static const char DerefByRefResultName[] = "derefByRefResult";
-
 // shared matchers
 static const TypeMatcher AnyType() { return anything(); }
 
@@ -150,10 +152,17 @@ StatementMatcher makeArrayLoopMatcher() {
 ///   - The iterator variables 'it', 'f', and 'h' are the same.
 ///   - The two containers on which 'begin' and 'end' are called are the same.
 ///   - If the end iterator variable 'g' is defined, it is the same as 'f'.
-StatementMatcher makeIteratorLoopMatcher() {
+StatementMatcher makeIteratorLoopMatcher(bool IsReverse) {
+
+  auto BeginNameMatcher = IsReverse ? hasAnyName("rbegin", "crbegin")
+: hasAnyName("begin", "cbegin");
+
+  auto EndNameMatcher =
+  IsReverse ? hasAnyName("rend", "crend") : hasAnyName("end", "cend");
+
   StatementMatcher BeginCallMatcher =
   cxxMemberCallExpr(argumentCountIs(0),
-callee(cxxMethodDecl(hasAnyName("begin", "cbegin"
+callee(cxxMethodDecl(BeginNameMatcher)))
   .bind(BeginCallName);
 
   DeclarationMatcher InitDeclMatcher =
@@ -167,7 +176,7 @@ StatementMatcher makeIteratorLoopMatcher() {
   varDecl(hasInitializer(anything())).bind(EndVarName);
 
   StatementMatcher EndCallMatcher = cxxMemberCallExpr(
-  argumentCountIs(0), callee(cxxMethodDecl(hasAnyName("end", "cend";
+  argumentCountIs(0), callee(cxxMethodDecl(EndNameMatcher)));
 
   StatementMatcher IteratorBoundMatcher =
   expr(anyOf(ignoringParenImpCasts(
@@ -225,7 +234,7 @@ StatementMatcher makeIteratorLoopMatcher() {
  hasArgument(
  0, declRefExpr(to(varDecl(TestDerefReturnsByValue)
.bind(IncrementVarName
-  .bind(LoopNameIterator);
+  .bind(IsReverse ? LoopNameReverseIterator : LoopNameIterator);
 }
 
 /// The matcher used for array-like containers (pseudoarrays).
@@ -325,7 +334,7 @@ StatementMatcher makePseudoArrayLoopMatcher() {
 /// the output parameter isArrow is set to indicate whether the initialization
 /// is called via . or ->.
 static const Expr *getContainerFromBeginEndCall(const Expr *Init, bool IsBegin,
-  

[PATCH] D82089: [clang-tidy] modernize-loop-convert reverse iteration support

[Nathan James via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG8a548bc203cf: [clang-tidy] modernize-loop-convert reverse 
iteration support (authored by njames93).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D82089

Files:
  clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp
  clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.h
  clang-tools-extra/clang-tidy/modernize/LoopConvertUtils.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/modernize-loop-convert.rst
  clang-tools-extra/test/clang-tidy/checkers/modernize-loop-convert-reverse.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/modernize-loop-convert-reverse.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/modernize-loop-convert-reverse.cpp
@@ -0,0 +1,115 @@
+// RUN: %check_clang_tidy -std=c++20 -check-suffixes=,RANGES %s modernize-loop-convert %t
+
+// RUN: %check_clang_tidy -check-suffixes=,CUSTOM,CUSTOM-NO-SYS %s modernize-loop-convert %t -- \
+// RUN:   -config="{CheckOptions: [ \
+// RUN:   {key: modernize-loop-convert.MakeReverseRangeFunction, value: 'llvm::reverse'}, \
+// RUN:   {key: modernize-loop-convert.MakeReverseRangeHeader, value: 'llvm/ADT/STLExtras.h'}]}"
+
+// RUN: %check_clang_tidy -check-suffixes=,CUSTOM,CUSTOM-SYS %s modernize-loop-convert %t -- \
+// RUN:   -config="{CheckOptions: [ \
+// RUN:   {key: modernize-loop-convert.MakeReverseRangeFunction, value: 'llvm::reverse'}, \
+// RUN:   {key: modernize-loop-convert.MakeReverseRangeHeader, value: ''}]}"
+
+// RUN: %check_clang_tidy -check-suffixes=,CUSTOM,CUSTOM-NO-HEADER %s modernize-loop-convert %t -- \
+// RUN:   -config="{CheckOptions: [ \
+// RUN:   {key: modernize-loop-convert.MakeReverseRangeFunction, value: 'llvm::reverse'}]}"
+
+// Ensure the check doesn't transform reverse loops when not in c++20 mode or
+// when UseCxx20ReverseRanges has been disabled
+// RUN: clang-tidy %s -checks=-*,modernize-loop-convert -- -std=c++17 | count 0
+
+// RUN: clang-tidy %s -checks=-*,modernize-loop-convert -config="{CheckOptions: \
+// RUN: [{key: modernize-loop-convert.UseCxx20ReverseRanges, value: 'false'}] \
+// RUN: }" -- -std=c++20 | count 0
+
+// Ensure we get a warning if we supply the header argument without the
+// function argument.
+// RUN: clang-tidy %s -checks=-*,modernize-loop-convert -config="{CheckOptions: [ \
+// RUN:   {key: modernize-loop-convert.MakeReverseRangeHeader, value: 'llvm/ADT/STLExtras.h'}]}" \
+// RUN: -- -std=c++17 2>&1 \
+// RUN:   | FileCheck %s -check-prefix=CHECK-HEADER-NO-FUNC \
+// RUN:   -implicit-check-not="{{warning|error}}:"
+
+// CHECK-HEADER-NO-FUNC: warning: modernize-loop-convert: 'MakeReverseRangeHeader' is set but 'MakeReverseRangeFunction' is not, disabling reverse loop transformation
+
+// Make sure appropiate headers are included
+// CHECK-FIXES-RANGES: #include 
+// CHECK-FIXES-CUSTOM-NO-SYS: #include "llvm/ADT/STLExtras.h"
+// CHECK-FIXES-CUSTOM-SYS: #include 
+
+// Make sure no header is included in this example
+// CHECK-FIXES-CUSTOM-NO-HEADER-NOT: #include
+
+template 
+struct Reversable {
+  using iterator = T *;
+  using const_iterator = const T *;
+
+  iterator begin();
+  iterator end();
+  iterator rbegin();
+  iterator rend();
+
+  const_iterator begin() const;
+  const_iterator end() const;
+  const_iterator rbegin() const;
+  const_iterator rend() const;
+
+  const_iterator cbegin() const;
+  const_iterator cend() const;
+  const_iterator crbegin() const;
+  const_iterator crend() const;
+};
+
+template 
+void observe(const T &);
+template 
+void mutate(T &);
+
+void constContainer(const Reversable &Numbers) {
+  for (auto I = Numbers.rbegin(), E = Numbers.rend(); I != E; ++I) {
+observe(*I);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES-RANGES: for (int Number : std::ranges::reverse_view(Numbers)) {
+  // CHECK-FIXES-CUSTOM: for (int Number : llvm::reverse(Numbers)) {
+  //   CHECK-FIXES-NEXT:   observe(Number);
+  //   CHECK-FIXES-NEXT: }
+
+  for (auto I = Numbers.crbegin(), E = Numbers.crend(); I != E; ++I) {
+observe(*I);
+  }
+  // CHECK-MESSAGES: :[[@LINE-3]]:3: warning: use range-based for loop instead
+  // CHECK-FIXES-RANGES: for (int Number : std::ranges::reverse_view(Numbers)) {
+  // CHECK-FIXES-CUSTOM: for (int Number : llvm::reverse(Numbers)) {
+  //   CHECK-FIXES-NEXT:   observe(Number);
+  //   CHECK-FIXES-NEXT: }
+
+  // Ensure these bad loops aren't transformed.
+  for (auto I = Numbers.rbegin(), E = Numbers.end(); I != E; ++I) {
+observe(*I);
+  }
+  for (auto I = Numbers.begin(), E = Numbers.rend(); I != E; ++I) {
+observe(*I);
+  }
+}
+
+void nonConstContainer(Reversable &Numbers) {
+  for (auto I = Numbers.rbe

[PATCH] D88154: Initial support for vectorization using Libmvec (GLIBC vector math library).

[Francesco Petrogalli via Phabricator via cfe-commits]

fpetrogalli added a comment.

LGTM from the perspective of making sure that this solution can be extended to 
any of the architectures that `libmvec` supports.

Thank you.


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

https://reviews.llvm.org/D88154

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

[PATCH] D79674: [clang-tidy] Better support for Override function in RenamerClangTidy based checks

[Nathan James via Phabricator via cfe-commits]

njames93 updated this revision to Diff 298616.
njames93 added a comment.

Updated release notes to reflect change


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D79674

Files:
  clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming.cpp
===
--- clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming.cpp
+++ clang-tools-extra/test/clang-tidy/checkers/readability-identifier-naming.cpp
@@ -266,14 +266,32 @@
   virtual ~AOverridden() = default;
   virtual void BadBaseMethod() = 0;
   // CHECK-MESSAGES: :[[@LINE-1]]:16: warning: invalid case style for virtual method 'BadBaseMethod'
+  // CHECK-FIXES: {{^}}  virtual void v_Bad_Base_Method() = 0;
 };
 
 class COverriding : public AOverridden {
 public:
   // Overriding a badly-named base isn't a new violation.
   void BadBaseMethod() override {}
+  // CHECK-FIXES: {{^}}  void v_Bad_Base_Method() override {}
+  
+  void foo() {
+BadBaseMethod();
+// CHECK-FIXES: {{^}}v_Bad_Base_Method();
+this->BadBaseMethod();
+// CHECK-FIXES: {{^}}this->v_Bad_Base_Method();
+AOverridden::BadBaseMethod();
+// CHECK-FIXES: {{^}}AOverridden::v_Bad_Base_Method();
+COverriding::BadBaseMethod();
+// CHECK-FIXES: {{^}}COverriding::v_Bad_Base_Method();
+  }
 };
 
+void VirtualCall(AOverridden &a_vItem) {
+  a_vItem.BadBaseMethod();
+  // CHECK-FIXES: {{^}}  a_vItem.v_Bad_Base_Method();
+}
+
 template 
 class CRTPBase {
 public:
Index: clang-tools-extra/docs/ReleaseNotes.rst
===
--- clang-tools-extra/docs/ReleaseNotes.rst
+++ clang-tools-extra/docs/ReleaseNotes.rst
@@ -125,6 +125,9 @@
   Added an option `GetConfigPerFile` to support including files which use
   different naming styles.
 
+  Now renames overridden virtual methods if the method they override has a
+  style violation.
+
 - Removed `google-runtime-references` check because the rule it checks does
   not exist in the Google Style Guide anymore.
 
Index: clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
===
--- clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
+++ clang-tools-extra/clang-tidy/utils/RenamerClangTidyCheck.cpp
@@ -135,6 +135,26 @@
  this));
 }
 
+/// Returns the function that \p Method is overridding. If There are none or
+/// multiple overrides it returns nullptr. If the overridden function itself is
+/// overridding then it will recurse up to find the first decl of the function.
+static const CXXMethodDecl *getOverrideMethod(const CXXMethodDecl *Method) {
+  if (Method->size_overridden_methods() != 1)
+return nullptr; // no overrides
+  while (true) {
+const CXXMethodDecl *Next = *Method->begin_overridden_methods();
+assert(Next && "Overridden method shouldn't be null");
+if (Next->size_overridden_methods() == 0) {
+  return Next;
+}
+if (Next->size_overridden_methods() == 1) {
+  Method = Next;
+  continue;
+}
+return nullptr; // Multiple overrides
+  }
+}
+
 void RenamerClangTidyCheck::addUsage(
 const RenamerClangTidyCheck::NamingCheckId &Decl, SourceRange Range,
 SourceManager *SourceMgr) {
@@ -173,6 +193,10 @@
 void RenamerClangTidyCheck::addUsage(const NamedDecl *Decl, SourceRange Range,
  SourceManager *SourceMgr) {
   Decl = cast(Decl->getCanonicalDecl());
+  if (const auto *Method = dyn_cast(Decl)) {
+if (const CXXMethodDecl *Overridden = getOverrideMethod(Method))
+  Decl = Overridden;
+  }
   return addUsage(RenamerClangTidyCheck::NamingCheckId(Decl->getLocation(),
Decl->getNameAsString()),
   Range, SourceMgr);
@@ -412,6 +436,14 @@
   }
 }
 
+// Fix overridden methods
+if (const auto *Method = Result.Nodes.getNodeAs("decl")) {
+  if (const CXXMethodDecl *Overridden = getOverrideMethod(Method)) {
+addUsage(Overridden, Method->getLocation());
+return; // Don't try to add the actual decl as a Failure.
+  }
+}
+
 // Ignore ClassTemplateSpecializationDecl which are creating duplicate
 // replacements with CXXRecordDecl.
 if (isa(Decl))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D89372: [OpenCL] Remove unused extensions

[Jan Vesely via Phabricator via cfe-commits]

jvesely added a comment.

In D89372#2334225 , @Anastasia wrote:

>> 
>
> Ok, so the pragma is supposed to control the pointer dereferencing which 
> seems like a valid case but however, it is not implemented now. Do we know of 
> any immediate plans from anyone to implement this? If not I would prefer to 
> remove the pragma for now? If someone decided to implement this functionality 
> later fully it is absolutely fine. Pragma will be very easy to add. There is 
> no need for everyone to pay the price for something that can't be used at the 
> moment.

I though the current behaviour of 'you can use #pragma, but the dereferences 
are always legal' was intentional for backward compatibility.
I don't think there are programs that would set it to 'disabled' and expect 
compilation failure. My concern is that legacy apps would set '#pragma enabled' 
before using char/short. such behavior would produce warning/error if with this 
change applied.

>> The same arguments also apply to `cles_khr_in64`. It's illegal to use int64 
>> types in embedded profile unless you first enable the extensions. Rather 
>> than removing it, `cles_khr_2d_image_array_writes` should be added to the 
>> extension list.
>
> I don't think clang currently support embedded profile. Adding extension into 
> the OpenCLOptions is pointless if it's not used. Do you plan to add any 
> functionality for it? Defining macros can be done easily outside of clang 
> source code or if it is preferable to do inside there is 
> `MacroBuilder::defineMacro`  available in the target hooks. Currently for 
> every extension added into `OpenCLExtensions.def` there is a macro, a pragma 
> and a field in `OpenCLOptions` added. This is often more than what is 
> necessary. Plus Khronos has very many extensions if we assume that all of 
> them are added in clang it will become scalability and maintanance nightmare. 
> Most of the extensions only add functions so if we provide a way to add 
> macros for those outside of clang code base it will keep the common code 
> clean and vendors can be more flexible in adding the extensions without the 
> need to modify upstream code if they need to. I see it as an opportunity to 
> improve common code and out of tree implementations too. It just need a 
> little bit of restructuring.

My understanding is that both the macro and working #pragma directive is 
necessary. The configuration bit is only needed if clang changes behaviour, 
which is a separate question.
I'd also argue that new third party extensions need an API call to register new 
extensions in order to get a working pragma mechanism.

Even if an extension only adds access new functions, pragma should control if 
user functions with conflicting names are legal or not.

for example, a program can implement function `new_func`, which gets later 
added to an extension. since the program doesn't know about the new extension 
it doesn't use `#pragma new_extension:enable` and continues to work correctly.
If the new extension exposes `new_func` unconditionally, the program breaks, 
because it doesn't check for a macro that didn't exist at the time it was 
written.
more recent programs can use ifdef to either use `new_func` provided by the 
extension, or implement a custom version.

I didn't find much about embedded program behavior in full profile 
implementation in the specs.
It only says that "embedded profile is a subset" which imo implies that legal 
embedded profile programs should work correctly in a full profile 
implementation.
This implies that cles_* pragmas should continue to work even if the behavior 
is always supported.

>>> Are you suggesting to leave this out? However I don't see any evidence that 
>>> this require either macro or pragma. I feel this is in rather incomplete 
>>> state. So I don't feel we can accomodate for all of these.
>>
>> "incomplete specification" is imo a good reason to drop support for an 
>> extension. My argument is that explanation of legacy extensions should rely 
>> on the spec that introduced them, rather than the current 2.x/3.x which does 
>> an arguably poor job on backward compatibility.
>
> Ok, the idea is not to break backwards compatibility of course. For the 
> extensions that intended to modify language (but never did) if we look from 
> upstream clang user's perspective those extensions couldn't possibly be used 
> to do anything useful. It is of course possible that in some forks the 
> functionality has been completed but then they can easily update the 
> implementation to include the extension definition back. This is very small 
> change compared to the actual extension functionality.
>
> I am ok to leave the extensions that could hypotetically modify the language 
> out of this patch for now. Perhaps we could add a comment explaining that 
> they are unused and only left for backwards compatibility. In a long term we 
> need to find some ways to remove the legacy that

[PATCH] D87279: [clang] Fix handling of physical registers in inline assembly operands.

[Jonas Paulsson via Phabricator via cfe-commits]

jonpa updated this revision to Diff 298624.
jonpa added a comment.

That makes sense... Patch updated to keep the tying of operands for this case 
of earlyclobber.

@nickdesaulniers : Can you see if this patch now passes your builds?


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

https://reviews.llvm.org/D87279

Files:
  clang/lib/CodeGen/CGStmt.cpp
  clang/test/CodeGen/systemz-inline-asm-02.c
  clang/test/CodeGen/systemz-inline-asm.c

Index: clang/test/CodeGen/systemz-inline-asm.c
===
--- clang/test/CodeGen/systemz-inline-asm.c
+++ clang/test/CodeGen/systemz-inline-asm.c
@@ -129,3 +129,17 @@
 // CHECK: [[RESULT:%.*]] = tail call fp128 asm "axbr $0, $2", "=f,0,f"(fp128 %f, fp128 %g)
 // CHECK: store fp128 [[RESULT]], fp128* [[DEST]]
 }
+
+// Test that there are no tied physreg uses. TwoAddress pass cannot deal with them.
+int test_physregs(void) {
+  // CHECK-LABEL: define signext i32 @test_physregs()
+  register int l __asm__("r7") = 0;
+
+  // CHECK: call i32 asm "lr $0, $1", "={r7},{r7}"
+  __asm__("lr %0, %1" : "+r"(l));
+
+  // CHECK: call i32 asm "$0 $1 $2", "={r7},{r7},{r7}"
+  __asm__("%0 %1 %2" : "+r"(l) : "r"(l));
+
+  return l;
+}
Index: clang/test/CodeGen/systemz-inline-asm-02.c
===
--- /dev/null
+++ clang/test/CodeGen/systemz-inline-asm-02.c
@@ -0,0 +1,13 @@
+// RUN: not %clang_cc1 -triple s390x-linux-gnu -O2 -emit-llvm -o - %s 2>&1 \
+// RUN:  | FileCheck %s
+// REQUIRES: systemz-registered-target
+
+// Test that an error is given if a physreg is defined by multiple operands.
+int test_physreg_defs(void) {
+  register int l __asm__("r7") = 0;
+
+  // CHECK: error: multiple outputs to hard register: r7
+  __asm__("" : "+r"(l), "=r"(l));
+
+  return l;
+}
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -21,6 +21,7 @@
 #include "clang/Basic/PrettyStackTrace.h"
 #include "clang/Basic/SourceManager.h"
 #include "clang/Basic/TargetInfo.h"
+#include "llvm/ADT/SmallSet.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/IR/DataLayout.h"
 #include "llvm/IR/InlineAsm.h"
@@ -1836,7 +1837,8 @@
 static std::string
 AddVariableConstraints(const std::string &Constraint, const Expr &AsmExpr,
const TargetInfo &Target, CodeGenModule &CGM,
-   const AsmStmt &Stmt, const bool EarlyClobber) {
+   const AsmStmt &Stmt, const bool EarlyClobber,
+   std::string *GCCReg = nullptr) {
   const DeclRefExpr *AsmDeclRef = dyn_cast(&AsmExpr);
   if (!AsmDeclRef)
 return Constraint;
@@ -1861,6 +1863,8 @@
   }
   // Canonicalize the register here before returning it.
   Register = Target.getNormalizedGCCRegisterName(Register);
+  if (GCCReg != nullptr)
+*GCCReg = Register.str();
   return (EarlyClobber ? "&{" : "{") + Register.str() + "}";
 }
 
@@ -2059,6 +2063,9 @@
   // Keep track of out constraints for tied input operand.
   std::vector OutputConstraints;
 
+  // Keep track of defined physregs.
+  llvm::SmallSet PhysRegOutputs;
+
   // An inline asm can be marked readonly if it meets the following conditions:
   //  - it doesn't have any sideeffects
   //  - it doesn't clobber memory
@@ -2078,9 +2085,15 @@
 const Expr *OutExpr = S.getOutputExpr(i);
 OutExpr = OutExpr->IgnoreParenNoopCasts(getContext());
 
+std::string GCCReg;
 OutputConstraint = AddVariableConstraints(OutputConstraint, *OutExpr,
   getTarget(), CGM, S,
-  Info.earlyClobber());
+  Info.earlyClobber(),
+  &GCCReg);
+// Give an error on multiple outputs to same physreg.
+if (!GCCReg.empty() && !PhysRegOutputs.insert(GCCReg).second)
+  CGM.Error(S.getAsmLoc(), "multiple outputs to hard register: " + GCCReg);
+
 OutputConstraints.push_back(OutputConstraint);
 LValue Dest = EmitLValue(OutExpr);
 if (!Constraints.empty())
@@ -2167,7 +2180,8 @@
 LargestVectorWidth =
 std::max((uint64_t)LargestVectorWidth,
  VT->getPrimitiveSizeInBits().getKnownMinSize());
-  if (Info.allowsRegister())
+  // Only tie earlyclobber physregs.
+  if (Info.allowsRegister() && (GCCReg.empty() || Info.earlyClobber()))
 InOutConstraints += llvm::utostr(i);
   else
 InOutConstraints += OutputConstraint;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D89443: [PowerPC][AIX] Make `__vector [un]signed long` an error

[Zarko Todorovski via Phabricator via cfe-commits]

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

LGTM




Comment at: clang/lib/Sema/DeclSpec.cpp:1200
+  // It has also been historically deprecated on AIX (as an alias for
+  // "vector int" in both 32-bit and 64-bit modes) and was made unsupported
+  // in the Clang-based XL compiler since the deprecated type has a number

minor nit, prefer to divide the comment in 2 sentences.  


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89443

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

[PATCH] D72218: [clang-tidy] new altera kernel name restriction check

[Frank Derry Wanye via Phabricator via cfe-commits]

ffrankies updated this revision to Diff 298601.
ffrankies marked 7 inline comments as done.
ffrankies added a comment.

Addressed comments by @aaron.ballman regarding the diagnostic warning.

I tried to add a test case for when the filename is `kernel.cl`, `verilog.cl`, 
or `vhdl.cl`, but that did not work because the test suite appends `.tmp.cpp` 
to the end of the test files, and `kernel.cl.tmp.cpp` is not a restricted 
filename. If you know of a way to include this test case in the test suite, 
please let me know. In the meantime, I tested this functionality manually, and 
found a minor bug that has since been fixed.

The bug was: if `kernel.cl` does not have any include directives, then the 
warning would not show up. Fixed this by rearranging the code to check the main 
file name before checking the include directives.


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

https://reviews.llvm.org/D72218

Files:
  clang-tools-extra/clang-tidy/altera/AlteraTidyModule.cpp
  clang-tools-extra/clang-tidy/altera/CMakeLists.txt
  clang-tools-extra/clang-tidy/altera/KernelNameRestrictionCheck.cpp
  clang-tools-extra/clang-tidy/altera/KernelNameRestrictionCheck.h
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/altera-kernel-name-restriction.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/altera-kernel-name-restriction/KERNEL.cl
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/altera-kernel-name-restriction/VHDL.cl
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/altera-kernel-name-restriction/Verilog.cl
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/altera-kernel-name-restriction/kernel.cl
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/altera-kernel-name-restriction/kernel.h
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/altera-kernel-name-restriction/other_Verilog.cl
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/altera-kernel-name-restriction/otherdir/vhdl.cl
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/altera-kernel-name-restriction/otherthing.cl
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/altera-kernel-name-restriction/some/dir/kernel.cl
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/altera-kernel-name-restriction/some/kernel.cl/foo.h
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/altera-kernel-name-restriction/some/verilog.cl/foo.h
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/altera-kernel-name-restriction/some/vhdl.cl/foo.h
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/altera-kernel-name-restriction/some_kernel.cl
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/altera-kernel-name-restriction/somedir/verilog.cl
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/altera-kernel-name-restriction/thing.h
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/altera-kernel-name-restriction/vERILOG.cl
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/altera-kernel-name-restriction/verilog.h
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/altera-kernel-name-restriction/vhdl.CL
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/altera-kernel-name-restriction/vhdl.h
  
clang-tools-extra/test/clang-tidy/checkers/Inputs/altera-kernel-name-restriction/vhdl_number_two.cl
  clang-tools-extra/test/clang-tidy/checkers/altera-kernel-name-restriction.cpp
  llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/altera/BUILD.gn

Index: llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/altera/BUILD.gn
===
--- llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/altera/BUILD.gn
+++ llvm/utils/gn/secondary/clang-tools-extra/clang-tidy/altera/BUILD.gn
@@ -13,6 +13,7 @@
   ]
   sources = [
 "AlteraTidyModule.cpp",
+"KernelNameRestrictionCheck.cpp",
 "StructPackAlignCheck.cpp",
   ]
 }
Index: clang-tools-extra/test/clang-tidy/checkers/altera-kernel-name-restriction.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/altera-kernel-name-restriction.cpp
@@ -0,0 +1,50 @@
+// RUN: %check_clang_tidy %s altera-kernel-name-restriction %t -- -- -I%S/Inputs/altera-kernel-name-restriction
+
+// These are the banned kernel filenames, and should trigger warnings
+#include "kernel.cl"
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: including 'kernel.cl' may cause additional compilation errors due to the name of the kernel source file; consider renaming the included kernel source file [altera-kernel-name-restriction]
+#include "Verilog.cl"
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: including 'Verilog.cl' may cause additional compilation errors due to the name of the kernel source file; consider renaming the included kernel source file [altera-kernel-name-restriction]
+#include "VHDL.cl"
+// CHECK-MESSAGES: :[[@LINE-1]]:1: warning: including 'VHDL.cl' may cause additional compilation errors due

[PATCH] D89528: [clang][test] Fix prefix operator++ signature in iterators

[Gabor Marton via Phabricator via cfe-commits]

martong added a comment.

What is the context here? Did it cause any crash/bug or were you just reading 
through the code for a good night sleep? :D


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89528

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

[clang] 59a3b1a - clang-format: Assert in-memory file created in createInMemoryFile, NFC

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

Author: Duncan P. N. Exon Smith
Date: 2020-10-16T10:20:32-04:00
New Revision: 59a3b1afb28541d5bf37445b028bfd711e3c556a

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

LOG: clang-format: Assert in-memory file created in createInMemoryFile, NFC

`SourceManager::createFileID` asserts that the given `FileEntry` is not
null, so remove the logic that passed in `nullptr`. Since we just added
the file to an in-memory FS via an API that cannot fail, use
`llvm_unreachable` on the error path. Didn't use an `assert` since it
seems cleaner semantically to check the error (and better,
hypothetically, for updating the API to use `Expected` instead of
`ErrorOr`).

I noticed this incidentally while auditing calls to `createFileID`.

Added: 


Modified: 
clang/tools/clang-format/ClangFormat.cpp

Removed: 




diff  --git a/clang/tools/clang-format/ClangFormat.cpp 
b/clang/tools/clang-format/ClangFormat.cpp
index 8dd55d99e2a0..3a7247deab46 100644
--- a/clang/tools/clang-format/ClangFormat.cpp
+++ b/clang/tools/clang-format/ClangFormat.cpp
@@ -179,8 +179,8 @@ static FileID createInMemoryFile(StringRef FileName, 
MemoryBuffer *Source,
  llvm::vfs::InMemoryFileSystem *MemFS) {
   MemFS->addFileNoOwn(FileName, 0, Source);
   auto File = Files.getFile(FileName);
-  return Sources.createFileID(File ? *File : nullptr, SourceLocation(),
-  SrcMgr::C_User);
+  assert(File && "File not added to MemFS?");
+  return Sources.createFileID(*File, SourceLocation(), SrcMgr::C_User);
 }
 
 // Parses : input to a pair of line numbers.



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

[PATCH] D88154: Initial support for vectorization using Libmvec (GLIBC vector math library).

[Sanjay Patel via Phabricator via cfe-commits]

spatel added a subscriber: aeubanks.
spatel added a comment.

In D88154#2328312 , 
@venkataramanan.kumar.llvm wrote:

> I can add few more float type tests with meta data for VF=8.   please let me 
> know your suggestions.

I may be missing some subtlety of the vectorizer behavior. Can we vary the test 
types + metadata in 1 file,s o that there is coverage for something like this 
v2f64 call : `TLI_DEFINE_VECFUNC("llvm.sin.f64", "_ZGVbN2v_sin", 2)`?
I'm just trying to make sure we don't fall into some blind-spot by only testing 
VF=4.




Comment at: llvm/test/Transforms/LoopVectorize/X86/libm-vector-calls-finite.ll:2
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py
+; RUN: opt -vector-library=LIBMVEC-X86 -inject-tli-mappings -loop-vectorize -S 
< %s | FileCheck %s
+target datalayout = "e-m:e-i64:64-f80:128-n8:16:32:64-S128"

fhahn wrote:
> fpetrogalli wrote:
> > `-inject-tli-mappings` is not required here, as a pass itself is required 
> > by the loop vectorizer.
> I guess it still doesn't hurt to be explicit. Also, can you add a line for 
> the new pass manager?
We need to be explicit about that pass with new-pass-manager as shown here:
df5576a

cc @aeubanks as I'm not sure if we want to update tests with NPM RUN lines or 
if we want to silently transition whenever the default gets changed.


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

https://reviews.llvm.org/D88154

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

[PATCH] D89554: SourceManager: Clarify that FileInfo always has a ContentCache, NFC

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

dexonsmith created this revision.
dexonsmith added a reviewer: arphaman.
Herald added subscribers: ributzka, martong.
Herald added a reviewer: shafik.
dexonsmith requested review of this revision.

It turns out that `FileInfo` *always* has a ContentCache. Clarify that
in the code:

- Update the private version of `SourceManager::createFileID` to take a 
`ContentCache&` instead of `ContentCache*`, and rename it to `createFileIDImpl` 
for clarity.
- Change `FileInfo::getContentCache` to return a reference.


https://reviews.llvm.org/D89554

Files:
  clang/include/clang/Basic/SourceManager.h
  clang/lib/AST/ASTImporter.cpp
  clang/lib/Basic/SourceManager.cpp
  clang/lib/Lex/ScratchBuffer.cpp
  clang/lib/Rewrite/Rewriter.cpp
  clang/lib/Serialization/ASTWriter.cpp
  clang/tools/libclang/CIndexInclusionStack.cpp

Index: clang/tools/libclang/CIndexInclusionStack.cpp
===
--- clang/tools/libclang/CIndexInclusionStack.cpp
+++ clang/tools/libclang/CIndexInclusionStack.cpp
@@ -35,7 +35,7 @@
   continue;
 
 const SrcMgr::FileInfo &FI = SL.getFile();
-if (!FI.getContentCache()->OrigEntry)
+if (!FI.getContentCache().OrigEntry)
   continue;
 
 // If this is the main file, and there is a preamble, skip this SLoc. The
@@ -60,7 +60,7 @@
 // Callback to the client.
 // FIXME: We should have a function to construct CXFiles.
 CB(static_cast(
-   const_cast(FI.getContentCache()->OrigEntry)),
+   const_cast(FI.getContentCache().OrigEntry)),
InclusionStack.data(), InclusionStack.size(), clientData);
   }
 }
Index: clang/lib/Serialization/ASTWriter.cpp
===
--- clang/lib/Serialization/ASTWriter.cpp
+++ clang/lib/Serialization/ASTWriter.cpp
@@ -1452,7 +1452,7 @@
 if (!SLoc->isFile())
   continue;
 const SrcMgr::FileInfo &File = SLoc->getFile();
-const SrcMgr::ContentCache *Cache = File.getContentCache();
+const SrcMgr::ContentCache *Cache = &File.getContentCache();
 if (!Cache->OrigEntry)
   continue;
 
@@ -1952,7 +1952,7 @@
 // Figure out which record code to use.
 unsigned Code;
 if (SLoc->isFile()) {
-  const SrcMgr::ContentCache *Cache = SLoc->getFile().getContentCache();
+  const SrcMgr::ContentCache *Cache = &SLoc->getFile().getContentCache();
   if (Cache->OrigEntry) {
 Code = SM_SLOC_FILE_ENTRY;
   } else
@@ -1970,7 +1970,7 @@
   Record.push_back(File.getFileCharacteristic()); // FIXME: stable encoding
   Record.push_back(File.hasLineDirectives());
 
-  const SrcMgr::ContentCache *Content = File.getContentCache();
+  const SrcMgr::ContentCache *Content = &File.getContentCache();
   bool EmitBlob = false;
   if (Content->OrigEntry) {
 assert(Content->OrigEntry == Content->ContentsEntry &&
Index: clang/lib/Rewrite/Rewriter.cpp
===
--- clang/lib/Rewrite/Rewriter.cpp
+++ clang/lib/Rewrite/Rewriter.cpp
@@ -263,8 +263,8 @@
 StringRef MB = SourceMgr->getBufferData(FID);
 
 unsigned lineNo = SourceMgr->getLineNumber(FID, StartOffs) - 1;
-const SrcMgr::ContentCache *
-Content = SourceMgr->getSLocEntry(FID).getFile().getContentCache();
+const SrcMgr::ContentCache *Content =
+&SourceMgr->getSLocEntry(FID).getFile().getContentCache();
 unsigned lineOffs = Content->SourceLineCache[lineNo];
 
 // Find the whitespace at the start of the line.
@@ -367,8 +367,8 @@
   unsigned startLineNo = SourceMgr->getLineNumber(FID, StartOff) - 1;
   unsigned endLineNo = SourceMgr->getLineNumber(FID, EndOff) - 1;
 
-  const SrcMgr::ContentCache *
-  Content = SourceMgr->getSLocEntry(FID).getFile().getContentCache();
+  const SrcMgr::ContentCache *Content =
+  &SourceMgr->getSLocEntry(FID).getFile().getContentCache();
 
   // Find where the lines start.
   unsigned parentLineOffs = Content->SourceLineCache[parentLineNo];
Index: clang/lib/Lex/ScratchBuffer.cpp
===
--- clang/lib/Lex/ScratchBuffer.cpp
+++ clang/lib/Lex/ScratchBuffer.cpp
@@ -38,8 +38,9 @@
 // Clear out the source line cache if it's already been computed.
 // FIXME: Allow this to be incrementally extended.
 auto *ContentCache = const_cast(
-SourceMgr.getSLocEntry(SourceMgr.getFileID(BufferStartLoc))
- .getFile().getContentCache());
+&SourceMgr.getSLocEntry(SourceMgr.getFileID(BufferStartLoc))
+ .getFile()
+ .getContentCache());
 ContentCache->SourceLineCache = nullptr;
   }
 
Index: clang/lib/Basic/SourceManager.cpp
===
--- clang/lib/Basic/SourceManager.cpp
+++ clang/lib/Basic/SourceManager.cpp
@@ -435,7 +435,7 @@
 if (!SLocEntryLoaded[Index]) {
   // Try to recover; create a SLocEntry so the rest of c

[PATCH] D88381: [Flang][Driver]Add PrintPreprocessedInput action `-E`

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski updated this revision to Diff 298635.
awarzynski added a comment.

Rebase + refector the unit test

This is re-based on top of the latest version of D87989 
. The unit test is
update for consistency with D87989 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88381

Files:
  clang/include/clang/Driver/Options.td
  flang/include/flang/Frontend/CompilerInstance.h
  flang/include/flang/Frontend/CompilerInvocation.h
  flang/include/flang/Frontend/FrontendActions.h
  flang/include/flang/Frontend/FrontendOptions.h
  flang/lib/Frontend/CMakeLists.txt
  flang/lib/Frontend/CompilerInstance.cpp
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendAction.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  flang/test/Flang-Driver/driver-help-hidden.f90
  flang/test/Flang-Driver/driver-help.f90
  flang/test/Frontend/Inputs/hello-world.c
  flang/test/Frontend/print-preprocess-C-file.f90
  flang/test/Frontend/print-preprocessed-file.f90
  flang/unittests/Frontend/CMakeLists.txt
  flang/unittests/Frontend/PrintPreprocessedTest.cpp

Index: flang/unittests/Frontend/PrintPreprocessedTest.cpp
===
--- /dev/null
+++ flang/unittests/Frontend/PrintPreprocessedTest.cpp
@@ -0,0 +1,79 @@
+//===- unittests/Frontend/PrintPreprocessedTest.cpp  FrontendAction tests --===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "flang/unittests/Frontend/PrintPreprocessedTest.cpp"
+#include "gtest/gtest.h"
+#include "flang/Frontend/CompilerInstance.h"
+#include "flang/Frontend/FrontendOptions.h"
+#include "flang/FrontendTool/Utils.h"
+#include "llvm/Support/FileSystem.h"
+#include "llvm/Support/raw_ostream.h"
+
+using namespace Fortran::frontend;
+
+namespace {
+
+TEST(FrontendAction, PrintPreprocessedInput) {
+  std::string inputFile = "test-file.f";
+  std::error_code ec;
+
+  // 1. Create the input file for the file manager
+  // AllSources (which is used to manage files inside every compiler instance),
+  // works with paths. This means that it requires a physical file. Create one.
+  std::unique_ptr os{
+  new llvm::raw_fd_ostream(inputFile, ec, llvm::sys::fs::OF_None)};
+  if (ec)
+FAIL() << "Fail to create the file need by the test";
+
+  // Populate the input file with the pre-defined input and flush it.
+  *(os) << "! test-file.F:\n"
+<< "#ifdef NEW\n"
+<< "  Program A \n"
+<< "#else\n"
+<< "  Program B\n"
+<< "#endif";
+  os.reset();
+
+  // Get the path of the input file
+  llvm::SmallString<64> cwd;
+  if (std::error_code ec = llvm::sys::fs::current_path(cwd))
+FAIL() << "Failed to obtain the current working directory";
+  std::string testFilePath(cwd.c_str());
+  testFilePath += "/" + inputFile;
+
+  // 2. Prepare the compiler (CompilerInvocation + CompilerInstance)
+  CompilerInstance compInst;
+  compInst.CreateDiagnostics();
+  auto invocation = std::make_shared();
+  invocation->GetFrontendOpts().programAction_ = PrintPreprocessedInput;
+
+  compInst.SetInvocation(std::move(invocation));
+  compInst.GetFrontendOpts().inputs_.push_back(
+  FrontendInputFile(testFilePath, Language::Fortran));
+
+  // 3. Set-up the output stream. Using output buffer wrapped as an output
+  // stream, as opposed to an actual file (or a file descriptor).
+  llvm::SmallVector outputFileBuffer;
+  std::unique_ptr outputFileStream(
+  new llvm::raw_svector_ostream(outputFileBuffer));
+  compInst.SetOutputStream(std::move(outputFileStream));
+
+  // 4. Run the earlier defined FrontendAction
+  bool success = ExecuteCompilerInvocation(&compInst);
+
+  // 5. Validate the expected output
+  EXPECT_TRUE(success);
+  EXPECT_TRUE(!outputFileBuffer.empty());
+  EXPECT_TRUE(llvm::StringRef(outputFileBuffer.data()).equals("program b"));
+
+  // 6. Clear the input and the output files. Since we used an output buffer,
+  // there are no physical output files to delete.
+  llvm::sys::fs::remove(inputFile);
+  compInst.ClearOutputFiles(/*EraseFiles=*/true);
+}
+} // namespace
Index: flang/unittests/Frontend/CMakeLists.txt
===
--- flang/unittests/Frontend/CMakeLists.txt
+++ flang/unittests/Frontend/CMakeLists.txt
@@ -1,11 +1,13 @@
 add_flang_unittest(FlangFrontendTests
   CompilerInstanceTest.cpp
   InputOutputTest.cpp
+  PrintPreprocessedTest.cpp
 )
 
 target_link_libraries(FlangFrontendTests
   PRIVATE
   clangBasic
   clangFrontend
+  FortranParser
   flangFrontend
   flangFrontendTool)
Index: flang

[PATCH] D88381: [Flang][Driver]Add PrintPreprocessedInput action `-E`

[Andrzej Warzynski via Phabricator via cfe-commits]

awarzynski commandeered this revision.
awarzynski edited reviewers, added: CarolineConcatto; removed: awarzynski.
awarzynski added a comment.

Since @CarolineConcatto has recently moved to a different project, I am 
assigning this to myself and will be responding to the future review comments. 
Thank you for all the effort @CarolineConcatto !


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88381

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

[PATCH] D89277: [clangd] Add $/dumpMemoryTree LSP extension

[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/ClangdLSPServer.cpp:623
 {"typeHierarchyProvider", true},
+{"memoryTreeProvider", true}, // clangd extension.
 ;

one last naming nit: I think `memoryUsage` would put appropriately more weight 
on the semantics rather than the data structure


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89277

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

[PATCH] D88859: APINotes: add APINotesYAMLCompiler

[Saleem Abdulrasool via Phabricator via cfe-commits]

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

Thanks for the feedback!




Comment at: clang/include/clang/APINotes/Types.h:1
+//===-- Types.h - API Notes Data Types --*- C++ 
-*-===//
+//

martong wrote:
> So we are mapping existing attributes here, I am missing this to be 
> documented. Why do we support only these attributes?
> Would be consistent to put `SwiftPrivate` here as well, instead of implicitly 
> interpreting that as `bool` in `APINotesYAMLCompiler.cpp`, wouldn't it?
> I think we should list all processed attributes here, or we should just use 
> `Attrs.inc` (see below my comment as well).
These are the ones that are currently needed and can be safely merged.  I 
really wouldn't want to extend the support to all the attributes in the initial 
attempt to merge the functionality as it is something which is actually in 
production already.  However, once the functionality is in a shared state, it 
is much easier to revise and co-evolve other consumers.



Comment at: clang/lib/APINotes/APINotesYAMLCompiler.cpp:240
+namespace {
+struct Class {
+  StringRef Name;

martong wrote:
> Why are these classes in a unnamed namespace? I'd expect them to be in the 
> header under the `clang::api_notes` namespace, so users of the 
> APINotesYAMLCompiler could use these as the structured form of the YAML 
> content. Isn't that the point of the whole stuff?
There will be follow up types that provide structured access to the data.  
These types are strictly for the serialization to and from YAML via `YAML::IO`.



Comment at: clang/lib/APINotes/APINotesYAMLCompiler.cpp:439
+  static void enumeration(IO &IO, EnumExtensibilityKind &EEK) {
+IO.enumCase(EEK, "none",   EnumExtensibilityKind::None);
+IO.enumCase(EEK, "open",   EnumExtensibilityKind::Open);

martong wrote:
> Hmm, why do we need "none"? Can't we interpret the non-existence as "none"?
At the very least we need it for compatibility - this is already a shipping 
feature.  However, nullability is also not completely annotated.  So, there is 
some benefit in tracking the explicit none vs missing.



Comment at: clang/lib/APINotes/APINotesYAMLCompiler.cpp:621
+
+  llvm::yaml::Output OS(llvm::outs());
+  OS << M;

martong wrote:
> I think the stream (`llvm::outs`) should not be written in stone. And why not 
> `llvm::errs` (we `dump` to `errs` usually) ? Could it be a parameter?
Sure, that is reasonable, I should be able to add a `llvm::raw_ostream &` 
parameter.



Comment at: 
clang/test/APINotes/Inputs/Frameworks/Simple.framework/Headers/Simple.apinotes:1
+Name:SimpleKit
+Classes:

martong wrote:
> I am pretty sure this does not provide a full coverage. What about e.g 
> `Functions`? I'd like to see them tested as well.
Correct, it isn't meant to provide full coverage at all.  It is merely meant to 
be enough to ensure that we can load the YAML and process it.  The full 
coverage will come with the follow up patches as they will require filling out 
more of the infrastructure.  I am trying to keep the patch at a reasonable 
size.  I can add additional test cases if you feel strongly that they should be 
added now, but, I do worry about the size of the patch ballooning.



Comment at: clang/test/APINotes/yaml-roundtrip.test:4
+
+We expect only the nullability to be different as it is canonicalized during 
the
+roudtrip.

martong wrote:
> Why do we have this difference? This seems odd and as a superfluous 
> complexity.
The difference is needed for compatibility.  Richard wanted the fully spelt out 
names, but that requires backwards compatibility, so we need the difference 
here.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88859

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

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

[Dávid Bolvanský via Phabricator via cfe-commits]

xbolva00 added a comment.

+1 for revert


Repository:
  rL LLVM

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

https://reviews.llvm.org/D66324

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

[PATCH] D89464: Revert "[clang-format] Fix AlignConsecutive on PP blocks"

[Sylvestre Ledru via Phabricator via cfe-commits]

sylvestre.ledru updated this revision to Diff 298639.
sylvestre.ledru added a comment.

Add the test which was failing + add the previous tests (but disabled)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89464

Files:
  clang/lib/Format/FormatToken.h
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/lib/Format/WhitespaceManager.cpp
  clang/unittests/Format/FormatTest.cpp
  clang/unittests/Format/FormatTestComments.cpp

Index: clang/unittests/Format/FormatTestComments.cpp
===
--- clang/unittests/Format/FormatTestComments.cpp
+++ clang/unittests/Format/FormatTestComments.cpp
@@ -2783,7 +2783,7 @@
 
   // Checks an edge case in preprocessor handling.
   // These comments should *not* be aligned
-  EXPECT_EQ(
+  EXPECT_NE( // change for EQ when fixed
   "#if FOO\n"
   "#else\n"
   "long a; // Line about a\n"
@@ -2801,6 +2801,24 @@
  "long b_long_name; // Line about b\n"
  "#endif\n",
  getLLVMStyleWithColumns(80)));
+
+  // bug 47589
+  EXPECT_EQ(
+  "namespace m {\n\n"
+  "#define FOO_GLOBAL 0  // Global scope.\n"
+  "#define FOO_LINKLOCAL 1   // Link-local scope.\n"
+  "#define FOO_SITELOCAL 2   // Site-local scope (deprecated).\n"
+  "#define FOO_UNIQUELOCAL 3 // Unique local\n"
+  "#define FOO_NODELOCAL 4   // Loopback\n\n"
+  "} // namespace m\n",
+  format("namespace m {\n\n"
+ "#define FOO_GLOBAL 0   // Global scope.\n"
+ "#define FOO_LINKLOCAL 1  // Link-local scope.\n"
+ "#define FOO_SITELOCAL 2  // Site-local scope (deprecated).\n"
+ "#define FOO_UNIQUELOCAL 3 // Unique local\n"
+ "#define FOO_NODELOCAL 4  // Loopback\n\n"
+ "} // namespace m\n",
+ getLLVMStyleWithColumns(80)));
 }
 
 TEST_F(FormatTestComments, AlignsBlockCommentDecorations) {
Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -12254,26 +12254,28 @@
Alignment);
 
   // Bug 25167
-  verifyFormat("#if A\n"
-   "#else\n"
-   "int  = 12;\n"
-   "#endif\n"
-   "#if B\n"
-   "#else\n"
-   "int a = 12;\n"
-   "#endif\n",
-   Alignment);
-  verifyFormat("enum foo {\n"
-   "#if A\n"
-   "#else\n"
-   "   = 12;\n"
-   "#endif\n"
-   "#if B\n"
-   "#else\n"
-   "  a = 12;\n"
-   "#endif\n"
-   "};\n",
-   Alignment);
+  /* Uncomment when fixed
+verifyFormat("#if A\n"
+ "#else\n"
+ "int  = 12;\n"
+ "#endif\n"
+ "#if B\n"
+ "#else\n"
+ "int a = 12;\n"
+ "#endif\n",
+ Alignment);
+verifyFormat("enum foo {\n"
+ "#if A\n"
+ "#else\n"
+ "   = 12;\n"
+ "#endif\n"
+ "#if B\n"
+ "#else\n"
+ "  a = 12;\n"
+ "#endif\n"
+ "};\n",
+ Alignment);
+  */
 
   EXPECT_EQ("int a = 5;\n"
 "\n"
Index: clang/lib/Format/WhitespaceManager.cpp
===
--- clang/lib/Format/WhitespaceManager.cpp
+++ clang/lib/Format/WhitespaceManager.cpp
@@ -411,11 +411,9 @@
 if (Changes[i].NewlinesBefore != 0) {
   CommasBeforeMatch = 0;
   EndOfSequence = i;
-  // If there is a blank line, there is a forced-align-break (eg,
-  // preprocessor), or if the last line didn't contain any matching token,
-  // the sequence ends here.
-  if (Changes[i].NewlinesBefore > 1 ||
-  Changes[i].Tok->MustBreakAlignBefore || !FoundMatchOnLine)
+  // If there is a blank line, or if the last line didn't contain any
+  // matching token, the sequence ends here.
+  if (Changes[i].NewlinesBefore > 1 || !FoundMatchOnLine)
 AlignCurrentSequence();
 
   FoundMatchOnLine = false;
@@ -726,8 +724,6 @@
 if (Changes[i].StartOfBlockComment)
   continue;
 Newlines += Changes[i].NewlinesBefore;
-if (Changes[i].Tok->MustBreakAlignBefore)
-  BreakBeforeNext = true;
 if (!Changes[i].IsTrailingComment)
   continue;
 
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -3037,7 +3037,6 @@
   }
   FormatTok = Tokens->getNextToken();
   FormatTok->MustBreakBefore = true;
-  FormatTok->Must

[PATCH] D89277: [clangd] Add $/dumpMemoryTree LSP extension

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet updated this revision to Diff 298644.
kadircet added a comment.

s/memoryTree/memoryUsage/g


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89277

Files:
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/Protocol.cpp
  clang-tools-extra/clangd/Protocol.h
  clang-tools-extra/clangd/test/initialize-params.test
  clang-tools-extra/clangd/test/memory_tree.test

Index: clang-tools-extra/clangd/test/memory_tree.test
===
--- /dev/null
+++ clang-tools-extra/clangd/test/memory_tree.test
@@ -0,0 +1,81 @@
+# RUN: clangd -lit-test < %s | FileCheck -strict-whitespace %s
+{"jsonrpc":"2.0","id":0,"method":"initialize","params":{"processId":123,"rootPath":"clangd","capabilities":{},"trace":"off"}}
+---
+{"jsonrpc":"2.0","method":"textDocument/didOpen","params":{"textDocument":{"uri":"test:///main.cpp","languageId":"cpp","version":1,"text":"void func() {}"}}}
+---
+{"jsonrpc":"2.0","id":1,"method":"$/memoryTree","params":{}}
+# CHECK:"id": 1,
+# CHECK-NEXT:   "jsonrpc": "2.0",
+# CHECK-NEXT:   "result": {
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}},
+# CHECK-NEXT: "clangd_server": {
+# CHECK-NEXT:   "_self": {{[0-9]+}},
+# CHECK-NEXT:   "_total": {{[0-9]+}},
+# CHECK-NEXT:   "dynamic_index": {
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}},
+# CHECK-NEXT: "main_file": {
+# CHECK-NEXT:   "_self": {{[0-9]+}},
+# CHECK-NEXT:   "_total": {{[0-9]+}},
+# CHECK-NEXT:   "index": {
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}}
+# CHECK-NEXT:   },
+# CHECK-NEXT:   "symbols": {
+# CHECK-NEXT: "{{.*}}main.cpp": {
+# CHECK-NEXT:   "_self": {{[0-9]+}},
+# CHECK-NEXT:   "_total": {{[0-9]+}},
+# CHECK-NEXT:   "references": {
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}}
+# CHECK-NEXT:   },
+# CHECK-NEXT:   "relations": {
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}}
+# CHECK-NEXT:   },
+# CHECK-NEXT:   "symbols": {
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}}
+# CHECK-NEXT:   }
+# CHECK-NEXT: },
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}}
+# CHECK-NEXT:   }
+# CHECK-NEXT: },
+# CHECK-NEXT: "preamble": {
+# CHECK-NEXT:   "_self": {{[0-9]+}},
+# CHECK-NEXT:   "_total": {{[0-9]+}},
+# CHECK-NEXT:   "index": {
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}}
+# CHECK-NEXT:   },
+# CHECK-NEXT:   "symbols": {
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}}
+# CHECK-NEXT:   }
+# CHECK-NEXT: }
+# CHECK-NEXT:   },
+# CHECK-NEXT:   "tuscheduler": {
+# CHECK-NEXT: "{{.*}}main.cpp": {
+# CHECK-NEXT:   "_self": {{[0-9]+}},
+# CHECK-NEXT:   "_total": {{[0-9]+}},
+# CHECK-NEXT:   "ast": {
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}}
+# CHECK-NEXT:   },
+# CHECK-NEXT:   "preamble": {
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}}
+# CHECK-NEXT:   }
+# CHECK-NEXT: },
+# CHECK-NEXT: "_self": {{[0-9]+}},
+# CHECK-NEXT: "_total": {{[0-9]+}}
+# CHECK-NEXT:   }
+# CHECK-NEXT: }
+# CHECK-NEXT:   }
+---
+{"jsonrpc":"2.0","id":3,"method":"shutdown"}
+---
+{"jsonrpc":"2.0","method":"exit"}
+
Index: clang-tools-extra/clangd/test/initialize-params.test
===
--- clang-tools-extra/clangd/test/initialize-params.test
+++ clang-tools-extra/clangd/test/initialize-params.test
@@ -66,6 +66,7 @@
 # CHECK-NEXT:]
 # CHECK-NEXT:  },
 # CHECK-NEXT:  "hoverProvider": true,
+# CHECK-NEXT:  "memoryTreeProvider": true
 # CHECK-NEXT:  "referencesProvider": true,
 # CHECK-NEXT:  "renameProvider": true,
 # CHECK-NEXT:  "selectionRangeProvider": true,
Index: clang-tools-extra/clangd/Protocol.h
===
--- clang-tools-extra/clangd/Protocol.h
+++ clang-tools-extra/clangd/Protocol.h
@@ -25,6 +25,7 @@
 
 #include "URI.h"
 #include "index/SymbolID.h"
+#include "support/MemoryTree.h"
 #include "clang/Index/IndexSymbol.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/Support/JSON.h"
@@ -1576,6 +1577,27 @@
 };
 llvm::j

[PATCH] D89559: PR47372: Fix Lambda invoker calling conventions

[Erich Keane via Phabricator via cfe-commits]

erichkeane created this revision.
erichkeane added reviewers: rsmith, rjmccall.
erichkeane requested review of this revision.

As mentioned in the defect, the lambda static invoker does not follow
the calling convention of the lambda itself, which seems wrong. This
patch ensures that the calling convention of operator() is passed onto
the invoker and conversion-operator type.

This is accomplished by extracting the calling-convention determination
code out into a separate function in order to better reflect the 'thiscall'
work, as well as somewhat better support the future implementation of 
https://devblogs.microsoft.com/oldnewthing/20150220-00/?p=44623


Repository:
  rC Clang

https://reviews.llvm.org/D89559

Files:
  clang/lib/Sema/SemaLambda.cpp
  clang/test/SemaCXX/lambda-conversion-op-cc.cpp

Index: clang/test/SemaCXX/lambda-conversion-op-cc.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/lambda-conversion-op-cc.cpp
@@ -0,0 +1,79 @@
+// RUN: %clang_cc1 -fsyntax-only -triple x86_64-linux-pc %s -verify -DBAD_CONVERSION
+// RUN: %clang_cc1 -fsyntax-only -triple i386-windows-pc %s -verify -DBAD_CONVERSION -DWIN32
+// RUN: %clang_cc1 -fsyntax-only -triple x86_64-linux-pc %s -ast-dump | FileCheck %s --check-prefixes=CHECK,LIN64,NODEF
+// RUN: %clang_cc1 -fsyntax-only -triple i386-windows-pc %s -ast-dump -DWIN32 | FileCheck %s --check-prefixes=CHECK,WIN32,NODEF
+
+// RUN: %clang_cc1 -fsyntax-only -triple x86_64-linux-pc -fdefault-calling-conv=vectorcall %s -verify -DBAD_VEC_CONVERS
+// RUN: %clang_cc1 -fsyntax-only -triple x86_64-linux-pc -fdefault-calling-conv=vectorcall %s -ast-dump | FileCheck %s --check-prefixes=CHECK,VECTDEF
+
+void useage() {
+  auto normal = [](int, float, double){}; // #1
+  auto vectorcall = [](int, float, double) __attribute__((vectorcall)) {}; // #2
+#ifdef WIN32
+  auto thiscall = [](int, float, double) __attribute__((thiscall)) {}; // #3
+#endif // WIN32
+  auto cdecl = [](int, float, double) __attribute__((cdecl)) {};
+
+// CHECK: VarDecl {{.*}} normal '
+// CHECK: LambdaExpr
+// WIN32: CXXMethodDecl {{.*}} operator() 'void (int, float, double) __attribute__((thiscall)) const'
+// LIN64: CXXMethodDecl {{.*}} operator() 'void (int, float, double) const'
+// VECTDEF: CXXMethodDecl {{.*}} operator() 'void (int, float, double) const'
+// NODEF: CXXConversionDecl {{.*}} operator void (*)(int, float, double) 'void
+// NODEF: CXXMethodDecl {{.*}} __invoke 'void (int, float, double)' static inline
+// VECTDEF: CXXConversionDecl {{.*}} operator void (*)(int, float, double) __attribute__((vectorcall)) 'void
+// VECTDEF: CXXMethodDecl {{.*}} __invoke 'void (int, float, double) __attribute__((vectorcall))' static inline
+
+// CHECK: VarDecl {{.*}} vectorcall '
+// CHECK: LambdaExpr
+// CHECK: CXXMethodDecl {{.*}} operator() 'void (int, float, double) __attribute__((vectorcall)) const'
+// CHECK: CXXConversionDecl {{.*}} operator void (*)(int, float, double) __attribute__((vectorcall)) 'void
+// CHECK: CXXMethodDecl {{.*}} __invoke 'void (int, float, double) __attribute__((vectorcall))' static inline
+
+// WIN32: VarDecl {{.*}} thiscall '
+// WIN32: LambdaExpr
+// WIN32: CXXMethodDecl {{.*}} operator() 'void (int, float, double) __attribute__((thiscall)) const'
+// WIN32: CXXConversionDecl {{.*}} operator void (*)(int, float, double) 'void
+// WIN32: CXXMethodDecl {{.*}} __invoke 'void (int, float, double)' static inline
+
+// CHECK: VarDecl {{.*}} cdecl '
+// CHECK: LambdaExpr
+// CHECK: CXXMethodDecl {{.*}} operator() 'void (int, float, double) const'
+// NODEF: CXXConversionDecl {{.*}} operator void (*)(int, float, double) 'void
+// NODEF: CXXMethodDecl {{.*}} __invoke 'void (int, float, double)' static inline
+// VECTDEF: CXXConversionDecl {{.*}} operator void (*)(int, float, double) __attribute__((vectorcall)) 'void
+// VECTDEF: CXXMethodDecl {{.*}} __invoke 'void (int, float, double) __attribute__((vectorcall))' static inline
+
+#ifdef BAD_CONVERSION
+  // expected-error-re@+2 {{no viable conversion from {{.*}} to 'void (*)(int, float, double) __attribute__((vectorcall))}}
+  // expected-note@#1 {{candidate function}}
+  void (*__attribute__((vectorcall)) normal_ptr2)(int, float, double) = normal;
+  // expected-error-re@+2 {{no viable conversion from {{.*}} to 'void (*)(int, float, double)}}
+  // expected-note@#2 {{candidate function}}
+  void (*vectorcall_ptr2)(int, float, double) = vectorcall;
+#ifdef WIN32
+  // expected-error-re@+2 {{no viable conversion from {{.*}} to 'void (*)(int, float, double) __attribute__((thiscall))}}
+  // expected-note@#3 {{candidate function}}
+  void (*__attribute__((thiscall)) thiscall_ptr2)(int, float, double) = thiscall;
+#endif // WIN32
+#endif // BAD_CONVERSION
+
+#ifdef BAD_VEC_CONVERS
+  void (*__attribute__((vectorcall)) normal_ptr2)(int, float, double) = normal;
+  void (* normal_ptr3)(int, float, double) = normal;
+  // expected-error-re@+2 {{no viable conversion from {{.*}} to 

[PATCH] D89487: [AMDGPU] gfx1032 target

[Jay Foad via Phabricator via cfe-commits]

foad added inline comments.



Comment at: llvm/docs/AMDGPUUsage.rst:280

  names.
+ ``gfx1032`` ``amdgcn``   dGPU  - xnack   
*TBA*
+  [off]

xnack looks like a mistake here?



Comment at: llvm/lib/Support/TargetParser.cpp:66
 // Don't bother listing the implicitly true features
-constexpr GPUInfo AMDGCNGPUs[43] = {
+constexpr GPUInfo AMDGCNGPUs[44] = {
   // Name CanonicalKindFeatures

Use `[]` so we don't have to keep updating the number?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89487

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

[PATCH] D89372: [OpenCL] Remove unused extensions

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia added a comment.

In D89372#2334728 , @jvesely wrote:

> In D89372#2334225 , @Anastasia wrote:
>
>>> 
>>
>> Ok, so the pragma is supposed to control the pointer dereferencing which 
>> seems like a valid case but however, it is not implemented now. Do we know 
>> of any immediate plans from anyone to implement this? If not I would prefer 
>> to remove the pragma for now? If someone decided to implement this 
>> functionality later fully it is absolutely fine. Pragma will be very easy to 
>> add. There is no need for everyone to pay the price for something that can't 
>> be used at the moment.
>
> I though the current behaviour of 'you can use #pragma, but the dereferences 
> are always legal' was intentional for backward compatibility.
> I don't think there are programs that would set it to 'disabled' and expect 
> compilation failure.

The initial state of the pragma is disabled, so if disabling the extension 
isn't supposed to do anything then I don't know why would anyone ever enable it?

> My concern is that legacy apps would set '#pragma enabled' before using 
> char/short. such behavior would produce warning/error if with this change 
> applied.

Correct, it will compile with a warning but not fail to compile. I am willing 
to introduce a -W option (if not present already ) to suppress that warning if 
it helps with the clean up and backward compatibility. It might also open up 
opportunities for a wider clean up  - removing pragma in extensions that 
currently require pragma for no good reason.  I have written more details on 
this in 
https://github.com/KhronosGroup/OpenCL-Docs/pull/355#issuecomment-662679499

>>> The same arguments also apply to `cles_khr_in64`. It's illegal to use int64 
>>> types in embedded profile unless you first enable the extensions. Rather 
>>> than removing it, `cles_khr_2d_image_array_writes` should be added to the 
>>> extension list.
>>
>> I don't think clang currently support embedded profile. Adding extension 
>> into the OpenCLOptions is pointless if it's not used. Do you plan to add any 
>> functionality for it? Defining macros can be done easily outside of clang 
>> source code or if it is preferable to do inside there is 
>> `MacroBuilder::defineMacro`  available in the target hooks. Currently for 
>> every extension added into `OpenCLExtensions.def` there is a macro, a pragma 
>> and a field in `OpenCLOptions` added. This is often more than what is 
>> necessary. Plus Khronos has very many extensions if we assume that all of 
>> them are added in clang it will become scalability and maintanance 
>> nightmare. Most of the extensions only add functions so if we provide a way 
>> to add macros for those outside of clang code base it will keep the common 
>> code clean and vendors can be more flexible in adding the extensions without 
>> the need to modify upstream code if they need to. I see it as an opportunity 
>> to improve common code and out of tree implementations too. It just need a 
>> little bit of restructuring.
>
> My understanding is that both the macro and working #pragma directive is 
> necessary.

I don't believe this is the correct interpretation. If you look at the 
extension spec s9.1 it says:

`Every extension which affects the OpenCL language semantics, syntax or adds 
built-in functions to the language must create a preprocessor #define that 
matches the extension name string.  This #define would be available in the 
language if and only if the extension is supported on a given implementation.`

It does not say that the pragma is needed, it only says that macro is needed. 
That perfectly makes sense because the macro allows to check that the extension 
is present to implement certain functionality conditionally.

OpenCL spec however never clarified the use of pragma that technically makes 
sense because the pragmas in C languages are used for altering the standard 
behavior that can't be otherwise achieved using standard parsing i.e. C99 
section 6.10.1 says about non-STDC pragmas:

`The behavior might cause translation to fail or cause the translator  or  the  
resulting  program  to  behave  in  a  non-conforming  manner.   Any  such 
pragma that is not recognized by the implementation is ignored.`

So C99 only regulates behavior of STDC pragmas and for those it explicitly says 
how the behavior of the parsed program is altered.

Technically OpenCL pragmas are not covered neither in OpenCL C and not C99 and 
therefore it is unclear what the implementation should do. However, with time 
due to the absence of the clarification mutiple interpretations appeared. Sadly 
some of them ended up in a very suboptimal state both for the tooling and the 
application developers because the pragma started to be added for no reason or 
for controlling redundant diagnostics of use of types or functions that 
extensions were introducing. If you are interested in more d

[PATCH] D89372: [OpenCL] Remove unused extensions

[Marco Antognini via Phabricator via cfe-commits]

mantognini updated this revision to Diff 298660.
mantognini added a comment.

Keep cl_khr_byte_addressable_store and cles_khr_int64 out of this PR. Add more 
details on the extensions being removed in the commit message.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89372

Files:
  clang/include/clang/Basic/OpenCLExtensions.def
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/NVPTX.h
  clang/test/Misc/amdgcn.languageOptsOpenCL.cl
  clang/test/Misc/nvptx.languageOptsOpenCL.cl
  clang/test/Misc/r600.languageOptsOpenCL.cl
  clang/test/SemaOpenCL/extension-version.cl

Index: clang/test/SemaOpenCL/extension-version.cl
===
--- clang/test/SemaOpenCL/extension-version.cl
+++ clang/test/SemaOpenCL/extension-version.cl
@@ -34,16 +34,6 @@
 #endif
 #pragma OPENCL EXTENSION cl_khr_int64_extended_atomics: enable
 
-#ifndef cl_khr_gl_sharing
-#error "Missing cl_khr_gl_sharing define"
-#endif
-#pragma OPENCL EXTENSION cl_khr_gl_sharing: enable
-
-#ifndef cl_khr_icd
-#error "Missing cl_khr_icd define"
-#endif
-#pragma OPENCL EXTENSION cl_khr_icd: enable
-
 // Core features in CL 1.1
 
 #ifndef cl_khr_byte_addressable_store
@@ -86,15 +76,6 @@
 // expected-warning@-2{{OpenCL extension 'cl_khr_local_int32_extended_atomics' is core feature or supported optional core feature - ignoring}}
 #endif
 
-#if (defined(__OPENCL_C_VERSION__) && __OPENCL_C_VERSION__ < 110)
-// Deprecated abvoe 1.0
-#ifndef cl_khr_select_fprounding_mode
-#error "Missing cl_khr_select_fp_rounding_mode define"
-#endif
-#pragma OPENCL EXTENSION cl_khr_select_fprounding_mode: enable
-#endif
-
-
 // Core feature in CL 1.2
 #ifndef cl_khr_fp64
 #error "Missing cl_khr_fp64 define"
@@ -113,24 +94,6 @@
 // expected-warning@-2{{OpenCL extension 'cl_khr_3d_image_writes' is core feature or supported optional core feature - ignoring}}
 #endif
 
-#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 110)
-#ifndef cl_khr_gl_event
-#error "Missing cl_khr_gl_event define"
-#endif
-#else
-// expected-warning@+2{{unsupported OpenCL extension 'cl_khr_gl_event' - ignoring}}
-#endif
-#pragma OPENCL EXTENSION cl_khr_gl_event : enable
-
-#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 110)
-#ifndef cl_khr_d3d10_sharing
-#error "Missing cl_khr_d3d10_sharing define"
-#endif
-#else
-// expected-warning@+2{{unsupported OpenCL extension 'cl_khr_d3d10_sharing' - ignoring}}
-#endif
-#pragma OPENCL EXTENSION cl_khr_d3d10_sharing : enable
-
 #if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 110)
 #ifndef cles_khr_int64
 #error "Missing cles_khr_int64 define"
@@ -140,60 +103,6 @@
 #endif
 #pragma OPENCL EXTENSION cles_khr_int64 : enable
 
-#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 120)
-#ifndef cl_khr_context_abort
-#error "Missing cl_context_abort define"
-#endif
-#else
-// expected-warning@+2{{unsupported OpenCL extension 'cl_khr_context_abort' - ignoring}}
-#endif
-#pragma OPENCL EXTENSION cl_khr_context_abort : enable
-
-#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 120)
-#ifndef cl_khr_d3d11_sharing
-#error "Missing cl_khr_d3d11_sharing define"
-#endif
-#else
-// expected-warning@+2{{unsupported OpenCL extension 'cl_khr_d3d11_sharing' - ignoring}}
-#endif
-#pragma OPENCL EXTENSION cl_khr_d3d11_sharing : enable
-
-#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 120)
-#ifndef cl_khr_dx9_media_sharing
-#error "Missing cl_khr_dx9_media_sharing define"
-#endif
-#else
-// expected-warning@+2{{unsupported OpenCL extension 'cl_khr_dx9_media_sharing' - ignoring}}
-#endif
-#pragma OPENCL EXTENSION cl_khr_dx9_media_sharing : enable
-
-#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 120)
-#ifndef cl_khr_image2d_from_buffer
-#error "Missing cl_khr_image2d_from_buffer define"
-#endif
-#else
-// expected-warning@+2{{unsupported OpenCL extension 'cl_khr_image2d_from_buffer' - ignoring}}
-#endif
-#pragma OPENCL EXTENSION cl_khr_image2d_from_buffer : enable
-
-#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 120)
-#ifndef cl_khr_initialize_memory
-#error "Missing cl_khr_initialize_memory define"
-#endif
-#else
-// expected-warning@+2{{unsupported OpenCL extension 'cl_khr_initialize_memory' - ignoring}}
-#endif
-#pragma OPENCL EXTENSION cl_khr_initialize_memory : enable
-
-#if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 120)
-#ifndef cl_khr_gl_depth_images
-#error "Missing cl_khr_gl_depth_images define"
-#endif
-#else
-// expected-warning@+2{{unsupported OpenCL extension 'cl_khr_gl_depth_images' - ignoring}}
-#endif
-#pragma OPENCL EXTENSION cl_khr_gl_depth_images : enable
-
 #if (defined(__OPENCL_CPP_VERSION__) || __OPENCL_C_VERSION__ >= 120)
 #ifndef cl_khr_gl_msaa_sharing
 #error "Missing cl_khr_gl_msaa_sharing define"
@@ -203,33 +112,6 @@
 #endif
 #pragma OPENCL EXTENSION cl_khr_gl_msaa_sharing : e

[PATCH] D89559: PR47372: Fix Lambda invoker calling conventions

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

I agree that it seems reasonable to preserve an explicit CC from the lambda on 
the converted function pointer.




Comment at: clang/lib/Sema/SemaLambda.cpp:1268
+calcLambdaConversionFunctionCallConv(Sema &S,
+ const FunctionProtoType *CallOpProto) {
+  CallingConv DefaultFree = S.Context.getDefaultCallingConvention(

I don't think we use `calc` as a prefix anywhere else in the compiler.  Maybe 
`get`?


Repository:
  rC Clang

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

https://reviews.llvm.org/D89559

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

[PATCH] D89559: PR47372: Fix Lambda invoker calling conventions

[John McCall via Phabricator via cfe-commits]

rjmccall added inline comments.



Comment at: clang/lib/Sema/SemaLambda.cpp:1278
+  if (CallOpCC == DefaultMember)
+return DefaultFree;
+  return CallOpCC;

...I made this comment in my first review, but Phabricator threw it away.

The attributes let you explicitly request the default method CC, right?  I 
think you need to check for an explicit attribute rather than just checking CC 
identity.  There should be an AttributedType in the sugar.


Repository:
  rC Clang

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

https://reviews.llvm.org/D89559

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

[PATCH] D89559: PR47372: Fix Lambda invoker calling conventions

[Erich Keane via Phabricator via cfe-commits]

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



Comment at: clang/lib/Sema/SemaLambda.cpp:1268
+calcLambdaConversionFunctionCallConv(Sema &S,
+ const FunctionProtoType *CallOpProto) {
+  CallingConv DefaultFree = S.Context.getDefaultCallingConvention(

rjmccall wrote:
> I don't think we use `calc` as a prefix anywhere else in the compiler.  Maybe 
> `get`?
WFM!


Repository:
  rC Clang

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

https://reviews.llvm.org/D89559

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

[PATCH] D89464: Revert "[clang-format] Fix AlignConsecutive on PP blocks"

[MyDeveloperDay via Phabricator via cfe-commits]

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89464

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

[PATCH] D89487: [AMDGPU] gfx1032 target

[Tony Tye via Phabricator via cfe-commits]

t-tye added inline comments.



Comment at: llvm/docs/AMDGPUUsage.rst:280

  names.
+ ``gfx1032`` ``amdgcn``   dGPU  - xnack   
*TBA*
+  [off]

foad wrote:
> xnack looks like a mistake here?
gfx1032 does not support XNACK. It should have the same target features as 
gfx1032.



Comment at: llvm/docs/AMDGPUUsage.rst:835
+ ``EF_AMDGPU_MACH_AMDGCN_GFX1032`` 0x038  ``gfx1032``
  *reserved*0x038  Reserved.
  *reserved*0x039  Reserved.

Delete as the line above is using this reserved number.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89487

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

[PATCH] D89487: [AMDGPU] gfx1032 target

[Stanislav Mekhanoshin via Phabricator via cfe-commits]

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



Comment at: llvm/docs/AMDGPUUsage.rst:280

  names.
+ ``gfx1032`` ``amdgcn``   dGPU  - xnack   
*TBA*
+  [off]

t-tye wrote:
> foad wrote:
> > xnack looks like a mistake here?
> gfx1032 does not support XNACK. It should have the same target features as 
> gfx1032.
D89565



Comment at: llvm/docs/AMDGPUUsage.rst:835
+ ``EF_AMDGPU_MACH_AMDGCN_GFX1032`` 0x038  ``gfx1032``
  *reserved*0x038  Reserved.
  *reserved*0x039  Reserved.

t-tye wrote:
> Delete as the line above is using this reserved number.
D89565


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89487

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

[PATCH] D89559: PR47372: Fix Lambda invoker calling conventions

[Erich Keane via Phabricator via cfe-commits]

erichkeane added inline comments.



Comment at: clang/lib/Sema/SemaLambda.cpp:1278
+  if (CallOpCC == DefaultMember)
+return DefaultFree;
+  return CallOpCC;

rjmccall wrote:
> ...I made this comment in my first review, but Phabricator threw it away.
> 
> The attributes let you explicitly request the default method CC, right?  I 
> think you need to check for an explicit attribute rather than just checking 
> CC identity.  There should be an AttributedType in the sugar.
They do, but I can't seem to find a way to find them.  The calling convention 
is already merged into the functiontype by the time we get here, the 
AttributedType isn't accessible.

So it seems we don't distinguish between "modified by attribute", 
"modified-default by command line", and "modified-default by TargetInfo."

That said, I somewhat think this is the right thing to do anyway.  If you're on 
a platform where the default call convention is different between a 
free-function and member-function, I'd think that this is what you MEAN...


Repository:
  rC Clang

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

https://reviews.llvm.org/D89559

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

[PATCH] D89559: PR47372: Fix Lambda invoker calling conventions

[Erich Keane via Phabricator via cfe-commits]

erichkeane updated this revision to Diff 298666.
erichkeane marked an inline comment as done.
erichkeane added a comment.

Calc->get.


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

https://reviews.llvm.org/D89559

Files:
  clang/lib/Sema/SemaLambda.cpp
  clang/test/SemaCXX/lambda-conversion-op-cc.cpp

Index: clang/test/SemaCXX/lambda-conversion-op-cc.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/lambda-conversion-op-cc.cpp
@@ -0,0 +1,79 @@
+// RUN: %clang_cc1 -fsyntax-only -triple x86_64-linux-pc %s -verify -DBAD_CONVERSION
+// RUN: %clang_cc1 -fsyntax-only -triple i386-windows-pc %s -verify -DBAD_CONVERSION -DWIN32
+// RUN: %clang_cc1 -fsyntax-only -triple x86_64-linux-pc %s -ast-dump | FileCheck %s --check-prefixes=CHECK,LIN64,NODEF
+// RUN: %clang_cc1 -fsyntax-only -triple i386-windows-pc %s -ast-dump -DWIN32 | FileCheck %s --check-prefixes=CHECK,WIN32,NODEF
+
+// RUN: %clang_cc1 -fsyntax-only -triple x86_64-linux-pc -fdefault-calling-conv=vectorcall %s -verify -DBAD_VEC_CONVERS
+// RUN: %clang_cc1 -fsyntax-only -triple x86_64-linux-pc -fdefault-calling-conv=vectorcall %s -ast-dump | FileCheck %s --check-prefixes=CHECK,VECTDEF
+
+void useage() {
+  auto normal = [](int, float, double){}; // #1
+  auto vectorcall = [](int, float, double) __attribute__((vectorcall)) {}; // #2
+#ifdef WIN32
+  auto thiscall = [](int, float, double) __attribute__((thiscall)) {}; // #3
+#endif // WIN32
+  auto cdecl = [](int, float, double) __attribute__((cdecl)) {};
+
+// CHECK: VarDecl {{.*}} normal '
+// CHECK: LambdaExpr
+// WIN32: CXXMethodDecl {{.*}} operator() 'void (int, float, double) __attribute__((thiscall)) const'
+// LIN64: CXXMethodDecl {{.*}} operator() 'void (int, float, double) const'
+// VECTDEF: CXXMethodDecl {{.*}} operator() 'void (int, float, double) const'
+// NODEF: CXXConversionDecl {{.*}} operator void (*)(int, float, double) 'void
+// NODEF: CXXMethodDecl {{.*}} __invoke 'void (int, float, double)' static inline
+// VECTDEF: CXXConversionDecl {{.*}} operator void (*)(int, float, double) __attribute__((vectorcall)) 'void
+// VECTDEF: CXXMethodDecl {{.*}} __invoke 'void (int, float, double) __attribute__((vectorcall))' static inline
+
+// CHECK: VarDecl {{.*}} vectorcall '
+// CHECK: LambdaExpr
+// CHECK: CXXMethodDecl {{.*}} operator() 'void (int, float, double) __attribute__((vectorcall)) const'
+// CHECK: CXXConversionDecl {{.*}} operator void (*)(int, float, double) __attribute__((vectorcall)) 'void
+// CHECK: CXXMethodDecl {{.*}} __invoke 'void (int, float, double) __attribute__((vectorcall))' static inline
+
+// WIN32: VarDecl {{.*}} thiscall '
+// WIN32: LambdaExpr
+// WIN32: CXXMethodDecl {{.*}} operator() 'void (int, float, double) __attribute__((thiscall)) const'
+// WIN32: CXXConversionDecl {{.*}} operator void (*)(int, float, double) 'void
+// WIN32: CXXMethodDecl {{.*}} __invoke 'void (int, float, double)' static inline
+
+// CHECK: VarDecl {{.*}} cdecl '
+// CHECK: LambdaExpr
+// CHECK: CXXMethodDecl {{.*}} operator() 'void (int, float, double) const'
+// NODEF: CXXConversionDecl {{.*}} operator void (*)(int, float, double) 'void
+// NODEF: CXXMethodDecl {{.*}} __invoke 'void (int, float, double)' static inline
+// VECTDEF: CXXConversionDecl {{.*}} operator void (*)(int, float, double) __attribute__((vectorcall)) 'void
+// VECTDEF: CXXMethodDecl {{.*}} __invoke 'void (int, float, double) __attribute__((vectorcall))' static inline
+
+#ifdef BAD_CONVERSION
+  // expected-error-re@+2 {{no viable conversion from {{.*}} to 'void (*)(int, float, double) __attribute__((vectorcall))}}
+  // expected-note@#1 {{candidate function}}
+  void (*__attribute__((vectorcall)) normal_ptr2)(int, float, double) = normal;
+  // expected-error-re@+2 {{no viable conversion from {{.*}} to 'void (*)(int, float, double)}}
+  // expected-note@#2 {{candidate function}}
+  void (*vectorcall_ptr2)(int, float, double) = vectorcall;
+#ifdef WIN32
+  // expected-error-re@+2 {{no viable conversion from {{.*}} to 'void (*)(int, float, double) __attribute__((thiscall))}}
+  // expected-note@#3 {{candidate function}}
+  void (*__attribute__((thiscall)) thiscall_ptr2)(int, float, double) = thiscall;
+#endif // WIN32
+#endif // BAD_CONVERSION
+
+#ifdef BAD_VEC_CONVERS
+  void (*__attribute__((vectorcall)) normal_ptr2)(int, float, double) = normal;
+  void (* normal_ptr3)(int, float, double) = normal;
+  // expected-error-re@+2 {{no viable conversion from {{.*}} to 'void (*)(int, float, double) __attribute__((regcall))}}
+  // expected-note@#1 {{candidate function}}
+  void (*__attribute__((regcall)) normalptr4)(int, float, double) = normal;
+  void (*__attribute__((vectorcall)) vectorcall_ptr2)(int, float, double) = vectorcall;
+  void (* vectorcall_ptr3)(int, float, double) = vectorcall;
+#endif // BAD_VEC_CONVERS
+
+  // Required to force emission of the invoker.
+  void (*normal_ptr)(int, float, double) = normal;
+  void (*__attribute__((v

[PATCH] D89487: [AMDGPU] gfx1032 target

[Stanislav Mekhanoshin via Phabricator via cfe-commits]

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



Comment at: llvm/lib/Support/TargetParser.cpp:66
 // Don't bother listing the implicitly true features
-constexpr GPUInfo AMDGCNGPUs[43] = {
+constexpr GPUInfo AMDGCNGPUs[44] = {
   // Name CanonicalKindFeatures

foad wrote:
> Use `[]` so we don't have to keep updating the number?
D89568


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89487

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

[PATCH] D89484: [AMDGPU][HIP] Switch default DWARF version to 5

[Scott Linder via Phabricator via cfe-commits]

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rGc4d10e7e9bb4: [AMDGPU][HIP] Switch default DWARF version to 
5 (authored by scott.linder).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89484

Files:
  clang/lib/Driver/ToolChains/AMDGPU.h
  clang/lib/Driver/ToolChains/HIP.h
  clang/test/Driver/amdgpu-toolchain.c
  clang/test/Driver/hip-toolchain-dwarf.hip


Index: clang/test/Driver/hip-toolchain-dwarf.hip
===
--- clang/test/Driver/hip-toolchain-dwarf.hip
+++ clang/test/Driver/hip-toolchain-dwarf.hip
@@ -6,4 +6,4 @@
 // RUN:   -x hip --cuda-gpu-arch=gfx803 %s \
 // RUN:   -Xarch_gfx803 -g 2>&1 | FileCheck %s -check-prefix=DWARF_VER
 
-// DWARF_VER: "-dwarf-version=4"
+// DWARF_VER: "-dwarf-version=5"
Index: clang/test/Driver/amdgpu-toolchain.c
===
--- clang/test/Driver/amdgpu-toolchain.c
+++ clang/test/Driver/amdgpu-toolchain.c
@@ -8,7 +8,7 @@
 // AS_LINK: clang{{.*}} "-cc1as"
 // AS_LINK: ld.lld{{.*}} "-shared"
 
-// DWARF_VER: "-dwarf-version=4"
+// DWARF_VER: "-dwarf-version=5"
 
 // RUN: %clang -### -target amdgcn-amd-amdhsa -mcpu=gfx906 -nogpulib \
 // RUN:   -flto %s 2>&1 | FileCheck -check-prefix=LTO %s
Index: clang/lib/Driver/ToolChains/HIP.h
===
--- clang/lib/Driver/ToolChains/HIP.h
+++ clang/lib/Driver/ToolChains/HIP.h
@@ -99,7 +99,7 @@
   computeMSVCVersion(const Driver *D,
  const llvm::opt::ArgList &Args) const override;
 
-  unsigned GetDefaultDwarfVersion() const override { return 4; }
+  unsigned GetDefaultDwarfVersion() const override { return 5; }
 
   const ToolChain &HostTC;
 
Index: clang/lib/Driver/ToolChains/AMDGPU.h
===
--- clang/lib/Driver/ToolChains/AMDGPU.h
+++ clang/lib/Driver/ToolChains/AMDGPU.h
@@ -60,7 +60,7 @@
 public:
   AMDGPUToolChain(const Driver &D, const llvm::Triple &Triple,
   const llvm::opt::ArgList &Args);
-  unsigned GetDefaultDwarfVersion() const override { return 4; }
+  unsigned GetDefaultDwarfVersion() const override { return 5; }
   bool IsIntegratedAssemblerDefault() const override { return true; }
   bool IsMathErrnoDefault() const override { return false; }
 


Index: clang/test/Driver/hip-toolchain-dwarf.hip
===
--- clang/test/Driver/hip-toolchain-dwarf.hip
+++ clang/test/Driver/hip-toolchain-dwarf.hip
@@ -6,4 +6,4 @@
 // RUN:   -x hip --cuda-gpu-arch=gfx803 %s \
 // RUN:   -Xarch_gfx803 -g 2>&1 | FileCheck %s -check-prefix=DWARF_VER
 
-// DWARF_VER: "-dwarf-version=4"
+// DWARF_VER: "-dwarf-version=5"
Index: clang/test/Driver/amdgpu-toolchain.c
===
--- clang/test/Driver/amdgpu-toolchain.c
+++ clang/test/Driver/amdgpu-toolchain.c
@@ -8,7 +8,7 @@
 // AS_LINK: clang{{.*}} "-cc1as"
 // AS_LINK: ld.lld{{.*}} "-shared"
 
-// DWARF_VER: "-dwarf-version=4"
+// DWARF_VER: "-dwarf-version=5"
 
 // RUN: %clang -### -target amdgcn-amd-amdhsa -mcpu=gfx906 -nogpulib \
 // RUN:   -flto %s 2>&1 | FileCheck -check-prefix=LTO %s
Index: clang/lib/Driver/ToolChains/HIP.h
===
--- clang/lib/Driver/ToolChains/HIP.h
+++ clang/lib/Driver/ToolChains/HIP.h
@@ -99,7 +99,7 @@
   computeMSVCVersion(const Driver *D,
  const llvm::opt::ArgList &Args) const override;
 
-  unsigned GetDefaultDwarfVersion() const override { return 4; }
+  unsigned GetDefaultDwarfVersion() const override { return 5; }
 
   const ToolChain &HostTC;
 
Index: clang/lib/Driver/ToolChains/AMDGPU.h
===
--- clang/lib/Driver/ToolChains/AMDGPU.h
+++ clang/lib/Driver/ToolChains/AMDGPU.h
@@ -60,7 +60,7 @@
 public:
   AMDGPUToolChain(const Driver &D, const llvm::Triple &Triple,
   const llvm::opt::ArgList &Args);
-  unsigned GetDefaultDwarfVersion() const override { return 4; }
+  unsigned GetDefaultDwarfVersion() const override { return 5; }
   bool IsIntegratedAssemblerDefault() const override { return true; }
   bool IsMathErrnoDefault() const override { return false; }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] c4d10e7 - [AMDGPU][HIP] Switch default DWARF version to 5

[Scott Linder via cfe-commits]

Author: Scott Linder
Date: 2020-10-16T17:53:27Z
New Revision: c4d10e7e9bb47b77fad43d8ddcfa328298f36c88

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

LOG: [AMDGPU][HIP] Switch default DWARF version to 5

Another attempt at this, see D59008 for previous attempt.

Reviewed By: kzhuravl, t-tye

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/AMDGPU.h
clang/lib/Driver/ToolChains/HIP.h
clang/test/Driver/amdgpu-toolchain.c
clang/test/Driver/hip-toolchain-dwarf.hip

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/AMDGPU.h 
b/clang/lib/Driver/ToolChains/AMDGPU.h
index 55ef6e01967e..f5448b76aee5 100644
--- a/clang/lib/Driver/ToolChains/AMDGPU.h
+++ b/clang/lib/Driver/ToolChains/AMDGPU.h
@@ -60,7 +60,7 @@ class LLVM_LIBRARY_VISIBILITY AMDGPUToolChain : public 
Generic_ELF {
 public:
   AMDGPUToolChain(const Driver &D, const llvm::Triple &Triple,
   const llvm::opt::ArgList &Args);
-  unsigned GetDefaultDwarfVersion() const override { return 4; }
+  unsigned GetDefaultDwarfVersion() const override { return 5; }
   bool IsIntegratedAssemblerDefault() const override { return true; }
   bool IsMathErrnoDefault() const override { return false; }
 

diff  --git a/clang/lib/Driver/ToolChains/HIP.h 
b/clang/lib/Driver/ToolChains/HIP.h
index 5e2be7138579..ff58c5451b0b 100644
--- a/clang/lib/Driver/ToolChains/HIP.h
+++ b/clang/lib/Driver/ToolChains/HIP.h
@@ -99,7 +99,7 @@ class LLVM_LIBRARY_VISIBILITY HIPToolChain final : public 
ROCMToolChain {
   computeMSVCVersion(const Driver *D,
  const llvm::opt::ArgList &Args) const override;
 
-  unsigned GetDefaultDwarfVersion() const override { return 4; }
+  unsigned GetDefaultDwarfVersion() const override { return 5; }
 
   const ToolChain &HostTC;
 

diff  --git a/clang/test/Driver/amdgpu-toolchain.c 
b/clang/test/Driver/amdgpu-toolchain.c
index ac558e0e26eb..cb92744eee6a 100644
--- a/clang/test/Driver/amdgpu-toolchain.c
+++ b/clang/test/Driver/amdgpu-toolchain.c
@@ -8,7 +8,7 @@
 // AS_LINK: clang{{.*}} "-cc1as"
 // AS_LINK: ld.lld{{.*}} "-shared"
 
-// DWARF_VER: "-dwarf-version=4"
+// DWARF_VER: "-dwarf-version=5"
 
 // RUN: %clang -### -target amdgcn-amd-amdhsa -mcpu=gfx906 -nogpulib \
 // RUN:   -flto %s 2>&1 | FileCheck -check-prefix=LTO %s

diff  --git a/clang/test/Driver/hip-toolchain-dwarf.hip 
b/clang/test/Driver/hip-toolchain-dwarf.hip
index 44d66fe52e04..c853d5cf07cf 100644
--- a/clang/test/Driver/hip-toolchain-dwarf.hip
+++ b/clang/test/Driver/hip-toolchain-dwarf.hip
@@ -6,4 +6,4 @@
 // RUN:   -x hip --cuda-gpu-arch=gfx803 %s \
 // RUN:   -Xarch_gfx803 -g 2>&1 | FileCheck %s -check-prefix=DWARF_VER
 
-// DWARF_VER: "-dwarf-version=4"
+// DWARF_VER: "-dwarf-version=5"



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

[PATCH] D89571: [clangd] Add textDocument/ast extension method to dump the AST

[Sam McCall via Phabricator via cfe-commits]

sammccall created this revision.
sammccall added a reviewer: adamcz.
Herald added subscribers: cfe-commits, usaxena95, kadircet, arphaman, mgorny.
Herald added a project: clang.
sammccall requested review of this revision.
Herald added subscribers: MaskRay, ilya-biryukov.

This is a mass-market version of the "dump AST" tweak we have behind
-hidden-features.
I think in this friendlier form it'll be useful for people outside clang
developers, which would justify making it a real feature.
It could be useful as a step towards lightweight clang-AST tooling in clangd
itself (like matcher-based search).

Advantages over the tweak:

- simplified information makes it more accessible, likely somewhat useful 
without learning too much clang internals
- can be shown in a tree view
- structured information gives some options for presentation (e.g. icon + two 
text colors + tooltip in vscode)
- clickable nodes jump to the corresponding code

Disadvantages:

- a bunch of code to handle different node types
- likely missing some important info vs dump-ast due to brevity/oversight
- may end up chasing/maintaining support for the long tail of nodes

Demo with VSCode support: https://imgur.com/a/6gKfyIV


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D89571

Files:
  clang-tools-extra/clangd/CMakeLists.txt
  clang-tools-extra/clangd/ClangdLSPServer.cpp
  clang-tools-extra/clangd/ClangdLSPServer.h
  clang-tools-extra/clangd/ClangdServer.cpp
  clang-tools-extra/clangd/ClangdServer.h
  clang-tools-extra/clangd/Protocol.cpp
  clang-tools-extra/clangd/Protocol.h
  clang-tools-extra/clangd/test/initialize-params.test
  clang-tools-extra/clangd/unittests/CMakeLists.txt

Index: clang-tools-extra/clangd/unittests/CMakeLists.txt
===
--- clang-tools-extra/clangd/unittests/CMakeLists.txt
+++ clang-tools-extra/clangd/unittests/CMakeLists.txt
@@ -51,6 +51,7 @@
   DexTests.cpp
   DiagnosticsTests.cpp
   DraftStoreTests.cpp
+  DumpASTTests.cpp
   ExpectedTypeTest.cpp
   FileDistanceTests.cpp
   FileIndexTests.cpp
Index: clang-tools-extra/clangd/test/initialize-params.test
===
--- clang-tools-extra/clangd/test/initialize-params.test
+++ clang-tools-extra/clangd/test/initialize-params.test
@@ -5,6 +5,7 @@
 # CHECK-NEXT:  "jsonrpc": "2.0",
 # CHECK-NEXT:  "result": {
 # CHECK-NEXT:"capabilities": {
+# CHECK-NEXT:  "astProvider": true,
 # CHECK-NEXT:  "codeActionProvider": true,
 # CHECK-NEXT:  "completionProvider": {
 # CHECK-NEXT:"allCommitCharacters": [
Index: clang-tools-extra/clangd/Protocol.h
===
--- clang-tools-extra/clangd/Protocol.h
+++ clang-tools-extra/clangd/Protocol.h
@@ -1576,6 +1576,45 @@
 };
 llvm::json::Value toJSON(const FoldingRange &Range);
 
+/// Payload for textDocument/ast request.
+/// This request is a clangd extension.
+struct ASTParams {
+  /// The text document.
+  TextDocumentIdentifier textDocument;
+
+  /// The position of the node to be dumped.
+  /// The highest-level node that entirely contains the range will be returned.
+  Range range;
+};
+bool fromJSON(const llvm::json::Value &, ASTParams &, llvm::json::Path);
+
+/// Simplified description of a clang AST node.
+/// This is clangd's internal representation of C++ code.
+struct ASTNode {
+  /// The general kind of node, such as "expression"
+  /// Corresponds to the base AST node type such as Expr.
+  std::string role;
+  /// The specific kind of node this is, such as "BinaryOperator".
+  /// This is usually a concrete node class (with Expr etc suffix dropped).
+  /// When there's no hierarchy (e.g. TemplateName), the variant (NameKind).
+  std::string kind;
+  /// Brief additional information, such as "||" for the particular operator.
+  /// The information included depends on the node kind, and may be empty.
+  std::string detail;
+  /// A one-line dump of detailed information about the node.
+  /// This includes role/kind/description information, but is rather cryptic.
+  /// It is similar to the output from `clang -Xclang -ast-dump`.
+  /// May be empty for certain types of nodes.
+  std::string arcana;
+  /// The range of the original source file covered by this node.
+  /// May be missing for implicit nodes, or those created by macro expansion.
+  llvm::Optional range;
+  /// Nodes nested within this one, such as the operands of a BinaryOperator.
+  std::vector children;
+};
+llvm::json::Value toJSON(const ASTNode &);
+llvm::raw_ostream &operator<<(llvm::raw_ostream &, const ASTNode &);
+
 } // namespace clangd
 } // namespace clang
 
Index: clang-tools-extra/clangd/Protocol.cpp
===
--- clang-tools-extra/clangd/Protocol.cpp
+++ clang-tools-extra/clangd/Protocol.cpp
@@ -1300,5 +1300,41 @@
   return Result;
 }
 
+bool fromJSON(const llvm::json::Value &Params, AS

[PATCH] D89573: [Driver] Incorporate -mfloat-abi in the computed triple on ARM

[John Brawn via Phabricator via cfe-commits]

john.brawn created this revision.
john.brawn added reviewers: efriedma, vhscampos, chill.
Herald added subscribers: dexonsmith, steven_wu, hiraditya, kristof.beyls.
Herald added a project: clang.
john.brawn requested review of this revision.

LLVM assumes that when it creates a call to a C library function it can use the 
C calling convention. On ARM the effective calling convention is determined 
from the target triple, however using -mfloat-abi=hard on ARM means that calls 
to (and definitions of) C library functions use the arm_aapcs_vfpcc calling 
convention which can result in a mismatch.

Fix this by incorporating -mfloat-abi into the target triple, similar to how 
-mbig-endian and -march/-mcpu are. This only works for EABI targets and not 
Android or iOS, but there the float abi is fixed.

Fixes PR45524.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D89573

Files:
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Arch/ARM.cpp
  clang/test/Driver/arm-float-abi-lto.c
  clang/test/Driver/arm-triple.c
  clang/test/Driver/windows-thumbv7em.cpp

Index: clang/test/Driver/windows-thumbv7em.cpp
===
--- clang/test/Driver/windows-thumbv7em.cpp
+++ clang/test/Driver/windows-thumbv7em.cpp
@@ -1,8 +1,8 @@
 // RUN: %clang -target thumb-none-windows-eabi-coff -mcpu=cortex-m7 -### -c %s 2>&1 \
 // RUN: | FileCheck %s --check-prefix CHECK-V7
-// CHECK-V7-NOT: error: the target architecture 'thumbv7em' is not supported by the target 'thumbv7em-none-windows-eabi'
+// CHECK-V7-NOT: error: the target architecture 'thumbv7em' is not supported by the target 'thumbv7em-none-windows-eabihf'
 
 // RUN: %clang -target thumb-none-windows-eabi-coff -mcpu=cortex-m1 -### -c %s 2>&1 \
 // RUN: | FileCheck %s --check-prefix CHECK-V6
-// CHECK-V6: error: the target architecture 'thumbv6m' is not supported by the target 'thumbv6m-none-windows-eabi'
+// CHECK-V6: error: the target architecture 'thumbv6m' is not supported by the target 'thumbv6m-none-windows-eabihf'
 
Index: clang/test/Driver/arm-triple.c
===
--- /dev/null
+++ clang/test/Driver/arm-triple.c
@@ -0,0 +1,48 @@
+// RUN: %clang -print-effective-triple \
+// RUN:   --target=arm-none-eabi \
+// RUN:   | FileCheck %s --check-prefix=CHECK-DEFAULT
+// RUN: %clang -print-effective-triple \
+// RUN:   --target=armeb-none-eabi -mlittle-endian \
+// RUN:   | FileCheck %s --check-prefix=CHECK-DEFAULT
+// RUN: %clang -print-effective-triple \
+// RUN:   --target=arm-none-eabihf -march=armv4t -mfloat-abi=softfp \
+// RUN:   | FileCheck %s --check-prefix=CHECK-DEFAULT
+// CHECK-DEFAULT: armv4t-none-unknown-eabi
+
+// RUN: %clang -print-effective-triple \
+// RUN:   --target=armeb-none-eabi \
+// RUN:   | FileCheck %s --check-prefix=CHECK-EB
+// RUN: %clang -print-effective-triple \
+// RUN:   --target=arm-none-eabi -mbig-endian \
+// RUN:   | FileCheck %s --check-prefix=CHECK-EB
+// CHECK-EB: armebv4t-none-unknown-eabi
+
+// RUN: %clang -print-effective-triple \
+// RUN:   --target=arm-none-eabihf -march=armv4t \
+// RUN:   | FileCheck %s --check-prefix=CHECK-HF
+// RUN: %clang -print-effective-triple \
+// RUN:   --target=arm-none-eabi -mfloat-abi=hard \
+// RUN:   | FileCheck %s --check-prefix=CHECK-HF
+// CHECK-HF: armv4t-none-unknown-eabihf
+
+// RUN: %clang -print-effective-triple \
+// RUN:   --target=armeb-none-eabihf -march=armv4t \
+// RUN:   | FileCheck %s --check-prefix=CHECK-EB-HF
+// RUN: %clang -print-effective-triple \
+// RUN:   --target=armeb-none-eabi -mfloat-abi=hard \
+// RUN:   | FileCheck %s --check-prefix=CHECK-EB-HF
+// RUN: %clang -print-effective-triple -march=armv4t \
+// RUN:   --target=arm-none-eabihf -mbig-endian \
+// RUN:   | FileCheck %s --check-prefix=CHECK-EB-HF
+// RUN: %clang -print-effective-triple \
+// RUN:   --target=arm-none-eabi -mbig-endian -mfloat-abi=hard \
+// RUN:   | FileCheck %s --check-prefix=CHECK-EB-HF
+// CHECK-EB-HF: armebv4t-none-unknown-eabihf
+
+// RUN: %clang -print-effective-triple \
+// RUN:   --target=arm-none-eabi -march=armv8m.main -mbig-endian -mfloat-abi=hard \
+// RUN:   | FileCheck %s --check-prefix=CHECK-V8M-EB-HF
+// RUN: %clang -print-effective-triple \
+// RUN:   --target=arm-none-eabi -mcpu=cortex-m33 -mbig-endian -mfloat-abi=hard \
+// RUN:   | FileCheck %s --check-prefix=CHECK-V8M-EB-HF
+// CHECK-V8M-EB-HF: thumbebv8m.main-none-unknown-eabihf
Index: clang/test/Driver/arm-float-abi-lto.c
===
--- /dev/null
+++ clang/test/Driver/arm-float-abi-lto.c
@@ -0,0 +1,63 @@
+// REQUIRES: arm-registered-target
+
+// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s -S -o - -emit-llvm -DCALL_LIB -DDEFINE_LIB | FileCheck %s
+
+// RUN: %clang --target=arm-none-eabi -mcpu=cortex-m33 -mfloat-abi=hard -O1 %s -flto=full -c -o %t.call_full.bc -DCALL_LIB
+// RUN: %clang --target=arm-none-e

[PATCH] D87279: [clang] Fix handling of physical registers in inline assembly operands.

[Nick Desaulniers via Phabricator via cfe-commits]

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

Thanks for updating the patch.

Please add a test case for the earlyclobber case. In particular, if none of the 
in-tree tests failed for the initial version of this patch that landed, you 
should add one that would have.

I should be able to `git checkout c78da037783bda0f27f4d82060149166e6f0c796`, 
observe the test case fail, then `arc patch D87279` and observe the test case 
pass.

The current version of this patch,  Diff 298624, passes the previously failing 
Linux kernel builds.


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

https://reviews.llvm.org/D87279

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

[PATCH] D63473: Support -fclang-abi-compat=8.0 to keep old ABI behavior

[Nico Weber via Phabricator via cfe-commits]

thakis resigned from this revision.
thakis added a comment.

hans and compnerd got this, no need for so many reviewers :)


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

https://reviews.llvm.org/D63473

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

[PATCH] D85788: [Clang test] Update to allow passing extra default clang arguments in use_clang

[Evgenii Stepanov via Phabricator via cfe-commits]

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85788

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

[PATCH] D89579: [clangd][ObjC] Support nullability annotations

[David Goldman via Phabricator via cfe-commits]

dgoldman created this revision.
Herald added subscribers: cfe-commits, usaxena95, kadircet, arphaman.
Herald added a project: clang.
dgoldman requested review of this revision.
Herald added subscribers: MaskRay, ilya-biryukov.

Nullability annotations are implmented using attributes; previusly
clangd would skip over AttributedTypeLoc since their location
points to the attribute instead of the modified type.

Also add quite a few test cases for this.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D89579

Files:
  clang-tools-extra/clangd/Selection.cpp
  clang-tools-extra/clangd/unittests/FindTargetTests.cpp
  clang-tools-extra/clangd/unittests/HoverTests.cpp
  clang-tools-extra/clangd/unittests/SelectionTests.cpp

Index: clang-tools-extra/clangd/unittests/SelectionTests.cpp
===
--- clang-tools-extra/clangd/unittests/SelectionTests.cpp
+++ clang-tools-extra/clangd/unittests/SelectionTests.cpp
@@ -356,6 +356,22 @@
 )cpp",
   "DeclRefExpr"},
 
+  // Objective-C nullability attributes.
+  {
+  R"cpp(
+@interface I{}
+@property(nullable) [[^I]] *x;
+@end
+  )cpp",
+  "ObjCInterfaceTypeLoc"},
+  {
+  R"cpp(
+@interface I{}
+- (void)doSomething:(nonnull [[i^d]])argument;
+@end
+  )cpp",
+  "TypedefTypeLoc"},
+
   // Objective-C OpaqueValueExpr/PseudoObjectExpr has weird ASTs.
   // Need to traverse the contents of the OpaqueValueExpr to the POE,
   // and ensure we traverse only the syntactic form of the PseudoObjectExpr.
Index: clang-tools-extra/clangd/unittests/HoverTests.cpp
===
--- clang-tools-extra/clangd/unittests/HoverTests.cpp
+++ clang-tools-extra/clangd/unittests/HoverTests.cpp
@@ -1991,6 +1991,91 @@
 HI.NamespaceScope = "ObjC::"; // FIXME: fix it
 HI.Definition = "char data";
   }},
+  {
+  R"cpp(
+  @interface MYObject
+  @end
+  @interface Interface
+  @property(retain) [[MYOb^ject]] *x;
+  @end
+  )cpp",
+  [](HoverInfo &HI) {
+HI.Name = "MYObject";
+HI.Kind = index::SymbolKind::Class;
+HI.NamespaceScope = "";
+HI.Definition = "@interface MYObject\n@end";
+  }},
+  {
+  // Should work even with nullability attribute.
+  R"cpp(
+  @interface MYObject
+  @end
+  @interface Interface
+  @property(nonnull) [[MYOb^ject]] *x;
+  @end
+  )cpp",
+  [](HoverInfo &HI) {
+HI.Name = "MYObject";
+HI.Kind = index::SymbolKind::Class;
+HI.NamespaceScope = "";
+HI.Definition = "@interface MYObject\n@end";
+  }},
+  {
+  R"cpp(
+  @interface MYObject
+  @end
+  @interface Interface
+  - (void)doWith:([[MYOb^ject]] *)object;
+  @end
+  )cpp",
+  [](HoverInfo &HI) {
+HI.Name = "MYObject";
+HI.Kind = index::SymbolKind::Class;
+HI.NamespaceScope = "";
+HI.Definition = "@interface MYObject\n@end";
+  }},
+  {
+  R"cpp(
+  @interface MYObject
+  @end
+  @interface Interface
+  - (void)doWith:(nullable [[MYOb^ject]] *)object;
+  @end
+  )cpp",
+  [](HoverInfo &HI) {
+HI.Name = "MYObject";
+HI.Kind = index::SymbolKind::Class;
+HI.NamespaceScope = "";
+HI.Definition = "@interface MYObject\n@end";
+  }},
+  {
+  R"cpp(
+  @class ForwardDeclared;
+  @interface Interface
+  @property(retain) [[Forward^Declared]] *x;
+  @end
+  )cpp",
+  [](HoverInfo &HI) {
+HI.Name = "ForwardDeclared";
+HI.Kind = index::SymbolKind::Class;
+HI.NamespaceScope = "";
+HI.Definition = "@class ForwardDeclared;";
+  }},
+  {
+  R"cpp(
+  @protocol Fooey
+  - (void)foo;
+  @end
+  @interface Interface
+  @property(retain) id<[[Fo^oey]]> fooey;
+  @end
+  )cpp",
+  [](HoverInfo &HI) {
+HI.Name = "Fooey";
+HI.Kind = index::SymbolKind::Protocol;
+HI.NamespaceScope = "";
+HI.Definition = "@protocol Fooey\n@end";
+  }},
   };
 
   // Create a tiny index, so tests above can verify documentation is fetched.
Index: clang-tools-extra/clangd/unittests/FindTargetTests.cpp
===
--- clang-tools-extra/clangd/unittests/FindTargetTests.cpp
+++ clang-tools-extra/clangd/unittests/FindTargetTests.cpp
@@ -820,6 +820,26 @@
   EXPECT_DECLS("Obj

[PATCH] D89579: [clangd][ObjC] Support nullability annotations

[David Goldman via Phabricator via cfe-commits]

dgoldman added inline comments.



Comment at: clang-tools-extra/clangd/Selection.cpp:621-623
+  if (auto AT = TL->getAs())
+S = AT.getModifiedLoc()
+.getSourceRange(); // should we just return false?

Let me know if you think it would be better to return false here


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89579

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

[PATCH] D89580: SourceManager: Fix an SLocEntry memory regression introduced with FileEntryRef

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

dexonsmith created this revision.
dexonsmith added reviewers: arphaman, Bigcheese.
Herald added a subscriber: ributzka.
dexonsmith requested review of this revision.

4dc5573acc0d2e7c59d8bac2543eb25cb4b32984 added `FileEntryRef` in order to
help enable sharing of a `FileManager` between `CompilerInstance`s.

It also added a `StringRef` with the filename on `FileInfo`. This
doubled `sizeof(FileInfo)`, bloating `sizeof(SLocEntry)`, of which we
have one for each (loaded and unloaded) file and macro expansion. This
causes a memory regression in modules builds.

Move the filename down into the `ContentCache`, which is a side data
structure for `FileInfo` that does not impact `sizeof(SLocEntry)`. Once
`FileEntryRef` is used for `ContentCache::OrigEntry` this can go away.


https://reviews.llvm.org/D89580

Files:
  clang/include/clang/Basic/SourceManager.h
  clang/lib/Basic/SourceManager.cpp


Index: clang/lib/Basic/SourceManager.cpp
===
--- clang/lib/Basic/SourceManager.cpp
+++ clang/lib/Basic/SourceManager.cpp
@@ -1748,7 +1748,7 @@
   // Predefined header doesn't have a valid include location in main
   // file, but any files created by it should still be skipped when
   // computing macro args expanded in the main file.
-  (FID == MainFileID && Entry.getFile().Filename == "");
+  (FID == MainFileID && Entry.getFile().getName() == "");
   if (IncludedInFID) {
 // Skip the files/macros of the #include'd file, we only care about
 // macros that lexed macro arguments from our file.
Index: clang/include/clang/Basic/SourceManager.h
===
--- clang/include/clang/Basic/SourceManager.h
+++ clang/include/clang/Basic/SourceManager.h
@@ -105,6 +105,8 @@
 ///
 /// It is possible for this to be NULL if the ContentCache encapsulates
 /// an imaginary text buffer.
+///
+/// FIXME: Turn this into a FileEntryRef and remove Filename.
 const FileEntry *OrigEntry;
 
 /// References the file which the contents were actually loaded from.
@@ -113,6 +115,11 @@
 /// with the contents of another file.
 const FileEntry *ContentsEntry;
 
+/// The filename that is used to access OrigEntry.
+///
+/// FIXME: Remove this once OrigEntry is a FileEntryRef with a stable name.
+StringRef Filename;
+
 /// A bump pointer allocated array of offsets for each source line.
 ///
 /// This is lazily computed.  This is owned by the SourceManager
@@ -244,7 +251,11 @@
   /// from. This information encodes the \#include chain that a token was
   /// expanded from. The main include file has an invalid IncludeLoc.
   ///
-  /// FileInfos contain a "ContentCache *", with the contents of the file.
+  /// FileInfo should not grow larger than ExpansionInfo. Doing so will
+  /// cause memory to bloat in compilations with many unloaded macro
+  /// expansions, since the two data structurs are stored in a union in
+  /// SLocEntry. Extra fields should instead go in "ContentCache *", which
+  /// stores file contents and other bits on the side.
   ///
   class FileInfo {
 friend class clang::SourceManager;
@@ -269,10 +280,6 @@
 llvm::PointerIntPair
 ContentAndKind;
 
-/// The filename that is used to access the file entry represented by the
-/// content cache.
-StringRef Filename;
-
   public:
 /// Return a FileInfo object.
 static FileInfo get(SourceLocation IL, const ContentCache &Con,
@@ -283,7 +290,7 @@
   X.HasLineDirectives = false;
   X.ContentAndKind.setPointer(&Con);
   X.ContentAndKind.setInt(FileCharacter);
-  X.Filename = Filename;
+  const_cast(Con).Filename = Filename;
   return X;
 }
 
@@ -311,7 +318,7 @@
 
 /// Returns the name of the file that was used when the file was loaded 
from
 /// the underlying file system.
-StringRef getName() const { return Filename; }
+StringRef getName() const { return getContentCache().Filename; }
   };
 
   /// Each ExpansionInfo encodes the expansion location - where
@@ -432,6 +439,13 @@
 }
   };
 
+  // Assert that the \c FileInfo objects are no bigger than \c ExpansionInfo
+  // objects. This controls the size of \c SLocEntry, of which we have one for
+  // each macro expansion. The number of (unloaded) macro expansions can be
+  // very large. Any other fields needed in FileInfo should go in ContentCache.
+  static_assert(sizeof(FileInfo) <= sizeof(ExpansionInfo),
+"FileInfo must be no larger than ExpansionInfo.");
+
   /// This is a discriminated union of FileInfo and ExpansionInfo.
   ///
   /// SourceManager keeps an array of these objects, and they are uniquely


Index: clang/lib/Basic/SourceManager.cpp
===
--- clang/lib/Basic/SourceManager.cpp
+++ clang/lib/Basic/SourceManager.cpp
@@ -1748,7 +1748,7 @@
   

[PATCH] D89523: PR44406: Follow behavior of array bound constant folding in more recent versions of GCC.

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

rsmith updated this revision to Diff 298702.
rsmith marked 2 inline comments as done.
rsmith added a comment.

- Update User's Manual to more accurately describe GNU mode and


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89523

Files:
  clang/docs/UsersManual.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CXX/basic/basic.types/p10.cpp
  clang/test/CXX/drs/dr3xx.cpp
  clang/test/CodeGen/vla.c
  clang/test/Misc/warning-flags.c
  clang/test/PCH/cxx-constexpr.cpp
  clang/test/Profile/misexpect-switch-default.c
  clang/test/Profile/misexpect-switch-nonconst.c
  clang/test/Profile/misexpect-switch-only-default-case.c
  clang/test/Profile/misexpect-switch.c
  clang/test/Sema/builtin-assume.c
  clang/test/Sema/builtins.c
  clang/test/Sema/complex-int.c
  clang/test/Sema/const-eval-64.c
  clang/test/Sema/const-eval.c
  clang/test/Sema/darwin-align-cast.c
  clang/test/Sema/decl-in-prototype.c
  clang/test/Sema/gnu-flags.c
  clang/test/Sema/i-c-e.c
  clang/test/Sema/offsetof-64.c
  clang/test/Sema/struct-decl.c
  clang/test/Sema/typedef-variable-type.c
  clang/test/Sema/vla.c
  clang/test/SemaCXX/anonymous-struct.cpp
  clang/test/SemaCXX/constant-expression.cpp
  clang/test/SemaCXX/cxx1z-noexcept-function-type.cpp
  clang/test/SemaCXX/i-c-e-cxx.cpp
  clang/test/SemaObjC/gcc-cast-ext.m

Index: clang/test/SemaObjC/gcc-cast-ext.m
===
--- clang/test/SemaObjC/gcc-cast-ext.m
+++ clang/test/SemaObjC/gcc-cast-ext.m
@@ -11,7 +11,7 @@
 
 // GCC allows pointer expressions in integer constant expressions.
 struct {
-  char control[((int)(char *)2)];
+  char control[((int)(char *)2)]; // expected-warning {{extension}}
 } xx;
 
 @implementation PBXDocBookmark // expected-warning {{method definition for 'autorelease' not found}}\
Index: clang/test/SemaCXX/i-c-e-cxx.cpp
===
--- clang/test/SemaCXX/i-c-e-cxx.cpp
+++ clang/test/SemaCXX/i-c-e-cxx.cpp
@@ -80,7 +80,7 @@
 #endif
 
 int PR8836test[(__typeof(sizeof(int)))&reinterpret_castPR8836*)0)->a))];
-// expected-warning@-1 {{folded to constant array as an extension}}
+// expected-warning@-1 0-1{{C99 feature}} expected-warning@-1 {{folded to constant array as an extension}}
 // expected-note@-2 {{cast that performs the conversions of a reinterpret_cast is not allowed in a constant expression}}
 
 const int nonconst = 1.0;
@@ -89,7 +89,7 @@
 #endif
 int arr[nonconst];
 #if __cplusplus <= 199711L
-// expected-warning@-2 {{folded to constant array as an extension}}
+// expected-warning@-2 0-1{{C99 feature}} expected-warning@-2 {{folded to constant array as an extension}}
 // expected-note@-3 {{initializer of 'nonconst' is not a constant expression}}
 #endif
 
Index: clang/test/SemaCXX/cxx1z-noexcept-function-type.cpp
===
--- clang/test/SemaCXX/cxx1z-noexcept-function-type.cpp
+++ clang/test/SemaCXX/cxx1z-noexcept-function-type.cpp
@@ -120,7 +120,7 @@
   extern "C" int strncmp(const char *, const char *, decltype(sizeof(0))) noexcept;
 
   // Check we recognized both as builtins.
-  typedef int arr[strcmp("bar", "foo") + 4 * strncmp("foo", "bar", 4)];
+  typedef int arr[strcmp("bar", "foo") + 4 * strncmp("foo", "bar", 4)]; // expected-warning {{variable length array}}
   typedef int arr[3];
 }
 
Index: clang/test/SemaCXX/constant-expression.cpp
===
--- clang/test/SemaCXX/constant-expression.cpp
+++ clang/test/SemaCXX/constant-expression.cpp
@@ -110,7 +110,7 @@
 const int recurse2 = recurse1; // expected-note {{here}}
 const int recurse1 = 1;
 int array1[recurse1]; // ok
-int array2[recurse2]; // expected-warning {{variable length array}} expected-warning {{integer constant expression}} expected-note {{initializer of 'recurse2' is not a constant expression}}
+int array2[recurse2]; // expected-warning 2{{variable length array}} expected-note {{initializer of 'recurse2' is not a constant expression}}
 
 namespace FloatConvert {
   typedef int a[(int)42.3];
Index: clang/test/SemaCXX/anonymous-struct.cpp
===
--- clang/test/SemaCXX/anonymous-struct.cpp
+++ clang/test/SemaCXX/anonymous-struct.cpp
@@ -131,6 +131,9 @@
   typedef struct { // expected-error {{unsupported}}
 enum X {};
 int arr[&f ? 1 : 2];
+#if __cplusplus < 201103L
+// expected-warning@-2 {{folded to constant}}
+#endif
   } C; // expected-note {{by this typedef}}
 }
 
Index: clang/test/Sema/vla.c
===
--- clang/test/Sema/vla.c
+++ clang/test/Sema/vla.c
@@ -53,7 +53,7 @@
 int (*pr2044c(void))[pr2044b]; // expected-error {{variably modified type}}
 
 const int f5_ci = 1;
-void f5

[PATCH] D89582: clang/AMDGPU: Apply workgroup related attributes to all functions

[Matt Arsenault via Phabricator via cfe-commits]

arsenm created this revision.
arsenm added reviewers: yaxunl, rampitec.
Herald added subscribers: kerbowa, t-tye, tpr, dstuttard, nhaehnle, jvesely, 
kzhuravl.
arsenm requested review of this revision.
Herald added a subscriber: wdng.

When the default flat work group size is 256, it should also apply to
callable functions.


https://reviews.llvm.org/D89582

Files:
  clang/lib/CodeGen/TargetInfo.cpp
  clang/test/CodeGenCUDA/amdgpu-kernel-attrs.cu
  clang/test/CodeGenOpenCL/amdgpu-attrs.cl


Index: clang/test/CodeGenOpenCL/amdgpu-attrs.cl
===
--- clang/test/CodeGenOpenCL/amdgpu-attrs.cl
+++ clang/test/CodeGenOpenCL/amdgpu-attrs.cl
@@ -190,5 +190,5 @@
 // CHECK-DAG: attributes 
[[FLAT_WORK_GROUP_SIZE_32_64_WAVES_PER_EU_2_NUM_SGPR_32_NUM_VGPR_64]] = {{.*}} 
"amdgpu-flat-work-group-size"="32,64" "amdgpu-implicitarg-num-bytes"="56" 
"amdgpu-num-sgpr"="32" "amdgpu-num-vgpr"="64" "amdgpu-waves-per-eu"="2"
 // CHECK-DAG: attributes 
[[FLAT_WORK_GROUP_SIZE_32_64_WAVES_PER_EU_2_4_NUM_SGPR_32_NUM_VGPR_64]] = 
{{.*}} "amdgpu-flat-work-group-size"="32,64" 
"amdgpu-implicitarg-num-bytes"="56" "amdgpu-num-sgpr"="32" 
"amdgpu-num-vgpr"="64" "amdgpu-waves-per-eu"="2,4"
 
-// CHECK-DAG: attributes [[A_FUNCTION]] = {{.*}}
+// CHECK-DAG: attributes [[A_FUNCTION]] = {{.*}} 
"amdgpu-flat-work-group-size"="1,256"
 // CHECK-DAG: attributes [[DEFAULT_KERNEL_ATTRS]] = {{.*}} 
"amdgpu-flat-work-group-size"="1,256" "amdgpu-implicitarg-num-bytes"="56"
Index: clang/test/CodeGenCUDA/amdgpu-kernel-attrs.cu
===
--- clang/test/CodeGenCUDA/amdgpu-kernel-attrs.cu
+++ clang/test/CodeGenCUDA/amdgpu-kernel-attrs.cu
@@ -16,6 +16,10 @@
 // CHECK: define amdgpu_kernel void @_Z28flat_work_group_size_defaultv() 
[[FLAT_WORK_GROUP_SIZE_DEFAULT:#[0-9]+]]
 }
 
+__device__ void func_flat_work_group_size_default() {
+// CHECK: define void @_Z33func_flat_work_group_size_defaultv() 
[[FLAT_WORK_GROUP_SIZE_DEFAULT_FUNC:#[0-9]+]]
+}
+
 __attribute__((amdgpu_flat_work_group_size(32, 64))) // expected-no-diagnostics
 __global__ void flat_work_group_size_32_64() {
 // CHECK: define amdgpu_kernel void @_Z26flat_work_group_size_32_64v() 
[[FLAT_WORK_GROUP_SIZE_32_64:#[0-9]+]]
@@ -40,7 +44,11 @@
 // NAMD-NOT: "amdgpu-num-sgpr"
 
 // DEFAULT-DAG: attributes [[FLAT_WORK_GROUP_SIZE_DEFAULT]] = 
{{.*}}"amdgpu-flat-work-group-size"="1,256"{{.*}}"uniform-work-group-size"="true"
+// DEFAULT-DAG: attributes [[FLAT_WORK_GROUP_SIZE_DEFAULT_FUNC]] = 
{{.*}}"amdgpu-flat-work-group-size"="1,256"{{.*}}"uniform-work-group-size"="true"
+
 // MAX1024-DAG: attributes [[FLAT_WORK_GROUP_SIZE_DEFAULT]] = 
{{.*}}"amdgpu-flat-work-group-size"="1,1024"
+// MAX1024-DAG: attributes [[FLAT_WORK_GROUP_SIZE_DEFAULT_FUNC]] = 
{{.*}}"amdgpu-flat-work-group-size"="1,1024"
+
 // CHECK-DAG: attributes [[FLAT_WORK_GROUP_SIZE_32_64]] = 
{{.*}}"amdgpu-flat-work-group-size"="32,64"
 // CHECK-DAG: attributes [[WAVES_PER_EU_2]] = {{.*}}"amdgpu-waves-per-eu"="2"
 // CHECK-DAG: attributes [[NUM_SGPR_32]] = {{.*}}"amdgpu-num-sgpr"="32"
Index: clang/lib/CodeGen/TargetInfo.cpp
===
--- clang/lib/CodeGen/TargetInfo.cpp
+++ clang/lib/CodeGen/TargetInfo.cpp
@@ -9031,7 +9031,7 @@
   (M.getTriple().getOS() == llvm::Triple::AMDHSA))
 F->addFnAttr("amdgpu-implicitarg-num-bytes", "56");
 
-  if (IsHIPKernel)
+  if (M.getLangOpts().HIP)
 F->addFnAttr("uniform-work-group-size", "true");
 
 
@@ -9057,7 +9057,7 @@
   F->addFnAttr("amdgpu-flat-work-group-size", AttrVal);
 } else
   assert(Max == 0 && "Max must be zero");
-  } else if (IsOpenCLKernel || IsHIPKernel) {
+  } else {
 // By default, restrict the maximum size to a value specified by
 // --gpu-max-threads-per-block=n or its default value.
 std::string AttrVal =


Index: clang/test/CodeGenOpenCL/amdgpu-attrs.cl
===
--- clang/test/CodeGenOpenCL/amdgpu-attrs.cl
+++ clang/test/CodeGenOpenCL/amdgpu-attrs.cl
@@ -190,5 +190,5 @@
 // CHECK-DAG: attributes [[FLAT_WORK_GROUP_SIZE_32_64_WAVES_PER_EU_2_NUM_SGPR_32_NUM_VGPR_64]] = {{.*}} "amdgpu-flat-work-group-size"="32,64" "amdgpu-implicitarg-num-bytes"="56" "amdgpu-num-sgpr"="32" "amdgpu-num-vgpr"="64" "amdgpu-waves-per-eu"="2"
 // CHECK-DAG: attributes [[FLAT_WORK_GROUP_SIZE_32_64_WAVES_PER_EU_2_4_NUM_SGPR_32_NUM_VGPR_64]] = {{.*}} "amdgpu-flat-work-group-size"="32,64" "amdgpu-implicitarg-num-bytes"="56" "amdgpu-num-sgpr"="32" "amdgpu-num-vgpr"="64" "amdgpu-waves-per-eu"="2,4"
 
-// CHECK-DAG: attributes [[A_FUNCTION]] = {{.*}}
+// CHECK-DAG: attributes [[A_FUNCTION]] = {{.*}} "amdgpu-flat-work-group-size"="1,256"
 // CHECK-DAG: attributes [[DEFAULT_KERNEL_ATTRS]] = {{.*}} "amdgpu-flat-work-group-size"="1,256" "amdgpu-implicitarg-num-bytes"="56"
Index: clang/test/CodeGenCUDA/amdgpu-kernel-attrs.cu
=

[PATCH] D89559: PR47372: Fix Lambda invoker calling conventions

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

No, if you put a calling convention on a lambda and then convert it to a 
function pointer, you almost certainly want that CC to be honored.

Is the `AttributedType` still present in `CallOperator->getType()`?


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

https://reviews.llvm.org/D89559

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

[PATCH] D89559: PR47372: Fix Lambda invoker calling conventions

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

In D89559#2335557 , @rjmccall wrote:

> No, if you put a calling convention on a lambda and then convert it to a 
> function pointer, you almost certainly want that CC to be honored.
>
> Is the `AttributedType` still present in `CallOperator->getType()`?

No, it is not at that point:

(gdb) p CallOperator->getType()->dump()
FunctionProtoType 0x1177a160 'void (void) __attribute__((thiscall)) const' 
const thiscall
`-AutoType 0x1177a0d0 'void' sugar

  `-BuiltinType 0x11716dc0 'void'


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

https://reviews.llvm.org/D89559

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

[PATCH] D89559: PR47372: Fix Lambda invoker calling conventions

[Erich Keane via Phabricator via cfe-commits]

erichkeane added a comment.

Perhaps a better example:

(gdb) p CallOperator->getType()->dump()
FunctionProtoType 0x1177edf0 'void (void) __attribute__((vectorcall)) const' 
const vectorcall
`-AutoType 0x1177a0d0 'void' sugar

  `-BuiltinType 0x11716dc0 'void'


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

https://reviews.llvm.org/D89559

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

[PATCH] D89523: PR44406: Follow behavior of array bound constant folding in more recent versions of GCC.

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

rsmith updated this revision to Diff 298705.
rsmith added a comment.

- Update User's Manual to more accurately describe GNU mode and


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89523

Files:
  clang/docs/UsersManual.rst
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDecl.cpp
  clang/lib/Sema/SemaType.cpp
  clang/test/CXX/basic/basic.types/p10.cpp
  clang/test/CXX/drs/dr3xx.cpp
  clang/test/CodeGen/vla.c
  clang/test/Misc/warning-flags.c
  clang/test/PCH/cxx-constexpr.cpp
  clang/test/Profile/misexpect-switch-default.c
  clang/test/Profile/misexpect-switch-nonconst.c
  clang/test/Profile/misexpect-switch-only-default-case.c
  clang/test/Profile/misexpect-switch.c
  clang/test/Sema/builtin-assume.c
  clang/test/Sema/builtins.c
  clang/test/Sema/complex-int.c
  clang/test/Sema/const-eval-64.c
  clang/test/Sema/const-eval.c
  clang/test/Sema/darwin-align-cast.c
  clang/test/Sema/decl-in-prototype.c
  clang/test/Sema/gnu-flags.c
  clang/test/Sema/i-c-e.c
  clang/test/Sema/offsetof-64.c
  clang/test/Sema/struct-decl.c
  clang/test/Sema/typedef-variable-type.c
  clang/test/Sema/vla.c
  clang/test/SemaCXX/anonymous-struct.cpp
  clang/test/SemaCXX/constant-expression.cpp
  clang/test/SemaCXX/cxx1z-noexcept-function-type.cpp
  clang/test/SemaCXX/i-c-e-cxx.cpp
  clang/test/SemaObjC/gcc-cast-ext.m

Index: clang/test/SemaObjC/gcc-cast-ext.m
===
--- clang/test/SemaObjC/gcc-cast-ext.m
+++ clang/test/SemaObjC/gcc-cast-ext.m
@@ -11,7 +11,7 @@
 
 // GCC allows pointer expressions in integer constant expressions.
 struct {
-  char control[((int)(char *)2)];
+  char control[((int)(char *)2)]; // expected-warning {{extension}}
 } xx;
 
 @implementation PBXDocBookmark // expected-warning {{method definition for 'autorelease' not found}}\
Index: clang/test/SemaCXX/i-c-e-cxx.cpp
===
--- clang/test/SemaCXX/i-c-e-cxx.cpp
+++ clang/test/SemaCXX/i-c-e-cxx.cpp
@@ -80,7 +80,7 @@
 #endif
 
 int PR8836test[(__typeof(sizeof(int)))&reinterpret_castPR8836*)0)->a))];
-// expected-warning@-1 {{folded to constant array as an extension}}
+// expected-warning@-1 0-1{{C99 feature}} expected-warning@-1 {{folded to constant array as an extension}}
 // expected-note@-2 {{cast that performs the conversions of a reinterpret_cast is not allowed in a constant expression}}
 
 const int nonconst = 1.0;
@@ -89,7 +89,7 @@
 #endif
 int arr[nonconst];
 #if __cplusplus <= 199711L
-// expected-warning@-2 {{folded to constant array as an extension}}
+// expected-warning@-2 0-1{{C99 feature}} expected-warning@-2 {{folded to constant array as an extension}}
 // expected-note@-3 {{initializer of 'nonconst' is not a constant expression}}
 #endif
 
Index: clang/test/SemaCXX/cxx1z-noexcept-function-type.cpp
===
--- clang/test/SemaCXX/cxx1z-noexcept-function-type.cpp
+++ clang/test/SemaCXX/cxx1z-noexcept-function-type.cpp
@@ -120,7 +120,7 @@
   extern "C" int strncmp(const char *, const char *, decltype(sizeof(0))) noexcept;
 
   // Check we recognized both as builtins.
-  typedef int arr[strcmp("bar", "foo") + 4 * strncmp("foo", "bar", 4)];
+  typedef int arr[strcmp("bar", "foo") + 4 * strncmp("foo", "bar", 4)]; // expected-warning {{variable length array}}
   typedef int arr[3];
 }
 
Index: clang/test/SemaCXX/constant-expression.cpp
===
--- clang/test/SemaCXX/constant-expression.cpp
+++ clang/test/SemaCXX/constant-expression.cpp
@@ -110,7 +110,7 @@
 const int recurse2 = recurse1; // expected-note {{here}}
 const int recurse1 = 1;
 int array1[recurse1]; // ok
-int array2[recurse2]; // expected-warning {{variable length array}} expected-warning {{integer constant expression}} expected-note {{initializer of 'recurse2' is not a constant expression}}
+int array2[recurse2]; // expected-warning 2{{variable length array}} expected-note {{initializer of 'recurse2' is not a constant expression}}
 
 namespace FloatConvert {
   typedef int a[(int)42.3];
Index: clang/test/SemaCXX/anonymous-struct.cpp
===
--- clang/test/SemaCXX/anonymous-struct.cpp
+++ clang/test/SemaCXX/anonymous-struct.cpp
@@ -131,6 +131,9 @@
   typedef struct { // expected-error {{unsupported}}
 enum X {};
 int arr[&f ? 1 : 2];
+#if __cplusplus < 201103L
+// expected-warning@-2 {{folded to constant}}
+#endif
   } C; // expected-note {{by this typedef}}
 }
 
Index: clang/test/Sema/vla.c
===
--- clang/test/Sema/vla.c
+++ clang/test/Sema/vla.c
@@ -53,7 +53,7 @@
 int (*pr2044c(void))[pr2044b]; // expected-error {{variably modified type}}
 
 const int f5_ci = 1;
-void f5() { char a[][f5_ci] = {""}; } // expecte

[PATCH] D89523: PR44406: Follow behavior of array bound constant folding in more recent versions of GCC.

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

rsmith added a comment.

In D89523#2333939 , @efriedma wrote:

> Also update the documentation?  See 
> https://clang.llvm.org/docs/UsersManual.html#differences-between-various-standard-modes
>  .

Done.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89523

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

[clang] dd4e8a5 - [docs] Fix some out-of-date / inaccurate text and missing formatting in the User's Manual.

[Richard Smith via cfe-commits]

Author: Richard Smith
Date: 2020-10-16T12:00:13-07:00
New Revision: dd4e8a54b2ba9cec78441ba537b94f4eaa5acd84

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

LOG: [docs] Fix some out-of-date / inaccurate text and missing formatting in 
the User's Manual.

Added: 


Modified: 
clang/docs/UsersManual.rst

Removed: 




diff  --git a/clang/docs/UsersManual.rst b/clang/docs/UsersManual.rst
index f313ce72d8ed..473fbb6d8d04 100644
--- a/clang/docs/UsersManual.rst
+++ b/clang/docs/UsersManual.rst
@@ -2479,8 +2479,8 @@ Differences between various standard modes
 --
 
 clang supports the -std option, which changes what language mode clang uses.
-The supported modes for C are c89, gnu89, c99, gnu99, c11, gnu11, c17, gnu17,
-c2x, gnu2x, and various aliases for those modes. If no -std option is
+The supported modes for C are c89, gnu89, c94, c99, gnu99, c11, gnu11, c17,
+gnu17, c2x, gnu2x, and various aliases for those modes. If no -std option is
 specified, clang defaults to gnu17 mode. Many C99 and C11 features are
 supported in earlier modes as a conforming extension, with a warning. Use
 ``-pedantic-errors`` to request an error if a feature from a later standard
@@ -2489,34 +2489,40 @@ revision is used in an earlier mode.
 Differences between all ``c*`` and ``gnu*`` modes:
 
 -  ``c*`` modes define "``__STRICT_ANSI__``".
--  Target-specific defines not prefixed by underscores, like "linux",
+-  Target-specific defines not prefixed by underscores, like ``linux``,
are defined in ``gnu*`` modes.
--  Trigraphs default to being off in ``gnu*`` modes; they can be enabled by
-   the -trigraphs option.
--  The parser recognizes "asm" and "typeof" as keywords in ``gnu*`` modes;
-   the variants "``__asm__``" and "``__typeof__``" are recognized in all
+-  Trigraphs default to being off in ``gnu*`` modes; they can be enabled
+   by the ``-trigraphs`` option.
+-  The parser recognizes ``asm`` and ``typeof`` as keywords in ``gnu*`` modes;
+   the variants ``__asm__`` and ``__typeof__`` are recognized in all modes.
+-  The parser recognizes ``inline`` as a keyword in ``gnu*`` mode, in
+   addition to recognizing it in the ``*99`` and later modes for which it is
+   part of the ISO C standard. The variant ``__inline__`` is recognized in all
modes.
 -  The Apple "blocks" extension is recognized by default in ``gnu*`` modes
-   on some platforms; it can be enabled in any mode with the "-fblocks"
+   on some platforms; it can be enabled in any mode with the ``-fblocks``
option.
 -  Arrays that are VLA's according to the standard, but which can be
constant folded by the frontend are treated as fixed size arrays.
This occurs for things like "int X[(1, 2)];", which is technically a
VLA. ``c*`` modes are strictly compliant and treat these as VLAs.
 
-Differences between ``*89`` and ``*99`` modes:
+Differences between ``*89`` and ``*94`` modes:
 
--  The ``*99`` modes default to implementing "inline" as specified in C99,
-   while the ``*89`` modes implement the GNU version. This can be
-   overridden for individual functions with the ``__gnu_inline__``
-   attribute.
 -  Digraphs are not recognized in c89 mode.
--  The scope of names defined inside a "for", "if", "switch", "while",
-   or "do" statement is 
diff erent. (example: "``if ((struct x {int
-   x;}*)0) {}``".)
+
+Differences between ``*94`` and ``*99`` modes:
+
+-  The ``*99`` modes default to implementing ``inline`` / ``__inline__``
+   as specified in C99, while the ``*89`` modes implement the GNU version.
+   This can be overridden for individual functions with the ``__gnu_inline__``
+   attribute.
+-  The scope of names defined inside a ``for``, ``if``, ``switch``, ``while``,
+  or ``do`` statement is 
diff erent. (example: ``if ((struct x {int x;}*)0)
+  {}``.)
 -  ``__STDC_VERSION__`` is not defined in ``*89`` modes.
--  "inline" is not recognized as a keyword in c89 mode.
--  "restrict" is not recognized as a keyword in ``*89`` modes.
+-  ``inline`` is not recognized as a keyword in ``c89`` mode.
+-  ``restrict`` is not recognized as a keyword in ``*89`` modes.
 -  Commas are allowed in integer constant expressions in ``*99`` modes.
 -  Arrays which are not lvalues are not implicitly promoted to pointers
in ``*89`` modes.
@@ -2538,9 +2544,7 @@ clang tries to be compatible with gcc as much as 
possible, but some gcc
 extensions are not implemented yet:
 
 -  clang does not support decimal floating point types (``_Decimal32`` and
-   friends) or fixed-point types (``_Fract`` and friends); nobody has
-   expressed interest in these features yet, so it's hard to say when
-   they will be implemented.
+   friends) yet.
 -  clang does not support nested functions; this is a comp

[PATCH] D89582: clang/AMDGPU: Apply workgroup related attributes to all functions

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

What if a device function is called by kernels with different work group sizes, 
will caller's work group size override callee's work group size?


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

https://reviews.llvm.org/D89582

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

[PATCH] D89582: clang/AMDGPU: Apply workgroup related attributes to all functions

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

In D89582#2335574 , @yaxunl wrote:

> What if a device function is called by kernels with different work group 
> sizes, will caller's work group size override callee's work group size?

It's user error to call a function with a larger range than the caller


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

https://reviews.llvm.org/D89582

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

[PATCH] D89520: Don't permit array bound constant folding in OpenCL.

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

rsmith added a comment.

In D89520#2334477 , @Anastasia wrote:

>> I couldn't find any spec justification for accepting the kinds of cases
>> that D20090  accepts, so a reference to 
>> where in the OpenCL specification
>> this is permitted would be useful.
>
> Thanks for fixing this. I agree that the original change was not compliant 
> with the spec. OpenCL indeed doesn't allow constant folding for array bounds. 
> The idea of the change was to allow using expressions that are compile time 
> constant in the array bound because this doesn't result in VLA.
>
> Regarding the spec reference, I think we can refer to the section 6.5.3 
> describing variables in the `__constant` address space:
>
>   These variables  are  required  to  be  initialized  and  the  values  used 
>  to  initialize  these  variables  must  be  a compile time constant. Writing 
> to such a variable results in a compile-time error.
>
> I.e. the `__constant` address space variables are semantically similar to 
> `constexpr` in C++.

I don't see any way to read this wording that way. That talks about how the 
variables are initialized and says they're immutable, but I can't find anything 
in the OpenCL specification that says they can be used in integer constant 
expressions. The C definition of "integral constant expression" does not allow 
the use of variables:

C11 6.6/6: "An integer constant expression shall have integer type and shall 
only have operands that are integer constants, enumeration constants, character 
constants, sizeof expressions whose results are integer constants, _Alignof 
expressions, and floating constants that are the immediate operands of casts."

... and absent a modification to that, nor would OpenCL. That said, I'm happy 
to take your word for it that the OpenCL specification //intends// for such 
variable uses to be permitted in constant expressions.

>> Note that this change also affects the code generation in one test:
>> because after 'const int n = 0' we now treat 'n' as a constant
>> expression with value 0, it's now a null pointer, so '(local int *)n'
>> forms a null pointer rather than a zero pointer.
>
> I am slightly confused about this case because technically the value of 'n' 
> can be overwritten by casting away const.

That would result in undefined behavior. And if not, the same consideration 
would apply to array bounds :)

> However, I suspect this is compliant C99 behavior?

Not exactly, because C99 doesn't permit usage of variables in integer constant 
expressions; this is a consequence of the presumptive OpenCL rule that does 
permit such things. In C, the closest analogue would be something like:

  enum { e = 0 };
  int *p = (int*)0; // null pointer constant, not a bit-cast of zero to a 
pointer



> This example:
>
>   void test(void) {
> const int x = 0;
> const int* ptrx = &x;
> int* ptry = (int*)ptrx;
> *ptry = 100; 
> int *sp5 = ( int*)x;
>   }
>
> shows that the IR produced is indeed supposed to have NULL despite of the 
> fact that the value of initializing variable is not 0 at the time of the last 
> initialization.

This example has undefined behavior due to writing to a const variable. Also, 
in C it initializes `sp5` to a zero pointer, not necessarily a null pointer, 
because `x` is not an integer constant expression -- though you can't see the 
difference here because we're in an address space where they're the same. Under 
the presumptive OpenCL rule, `x` would be an integer constant expression, so 
the above example would initialize `sp5` to a null pointer instead of a zero 
pointer, just like in C++98.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89520

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

[PATCH] D89372: [OpenCL] Remove unused extensions

[Jan Vesely via Phabricator via cfe-commits]

jvesely added a comment.

In D89372#2335027 , @Anastasia wrote:

> In D89372#2334728 , @jvesely wrote:
>
>> In D89372#2334225 , @Anastasia 
>> wrote:
>>
 
>>>
>>> Ok, so the pragma is supposed to control the pointer dereferencing which 
>>> seems like a valid case but however, it is not implemented now. Do we know 
>>> of any immediate plans from anyone to implement this? If not I would prefer 
>>> to remove the pragma for now? If someone decided to implement this 
>>> functionality later fully it is absolutely fine. Pragma will be very easy 
>>> to add. There is no need for everyone to pay the price for something that 
>>> can't be used at the moment.
>>
>> I though the current behaviour of 'you can use #pragma, but the dereferences 
>> are always legal' was intentional for backward compatibility.
>> I don't think there are programs that would set it to 'disabled' and expect 
>> compilation failure.
>
> The initial state of the pragma is disabled, so if disabling the extension 
> isn't supposed to do anything then I don't know why would anyone ever enable 
> it?
>
>> My concern is that legacy apps would set '#pragma enabled' before using 
>> char/short. such behavior would produce warning/error if with this change 
>> applied.
>
> Correct, it will compile with a warning but not fail to compile. I am willing 
> to introduce a -W option (if not present already ) to suppress that warning 
> if it helps with the clean up and backward compatibility. It might also open 
> up opportunities for a wider clean up  - removing pragma in extensions that 
> currently require pragma for no good reason.  I have written more details on 
> this in 
> https://github.com/KhronosGroup/OpenCL-Docs/pull/355#issuecomment-662679499

Adding a new option cannot be a solution as legacy applications were written 
before its introduction.
CL1.x applications need to continue to work without changes, anything else 
breaks backward compatibility.

 The same arguments also apply to `cles_khr_in64`. It's illegal to use 
 int64 types in embedded profile unless you first enable the extensions. 
 Rather than removing it, `cles_khr_2d_image_array_writes` should be added 
 to the extension list.
>>>
>>> I don't think clang currently support embedded profile. Adding extension 
>>> into the OpenCLOptions is pointless if it's not used. Do you plan to add 
>>> any functionality for it? Defining macros can be done easily outside of 
>>> clang source code or if it is preferable to do inside there is 
>>> `MacroBuilder::defineMacro`  available in the target hooks. Currently for 
>>> every extension added into `OpenCLExtensions.def` there is a macro, a 
>>> pragma and a field in `OpenCLOptions` added. This is often more than what 
>>> is necessary. Plus Khronos has very many extensions if we assume that all 
>>> of them are added in clang it will become scalability and maintanance 
>>> nightmare. Most of the extensions only add functions so if we provide a way 
>>> to add macros for those outside of clang code base it will keep the common 
>>> code clean and vendors can be more flexible in adding the extensions 
>>> without the need to modify upstream code if they need to. I see it as an 
>>> opportunity to improve common code and out of tree implementations too. It 
>>> just need a little bit of restructuring.
>>
>> My understanding is that both the macro and working #pragma directive is 
>> necessary.
>
> I don't believe this is the correct interpretation. If you look at the 
> extension spec s9.1 it says:
>
> `Every extension which affects the OpenCL language semantics, syntax or adds 
> built-in functions to the language must create a preprocessor #define that 
> matches the extension name string.  This #define would be available in the 
> language if and only if the extension is supported on a given implementation.`

This is only one part indicating the availability of extension. It's not 
describing what's necessary to observe extended behaviour. The specs state that 
the initial state of the compiler is as if `#pragma OPENCL EXTENSION all : 
disable` was issued.
This means that functions introduced by extensions cannot be present, and the 
symbol names are available for application use unless such symbols were 
previously reserved.

> It does not say that the pragma is needed, it only says that macro is needed. 
> That perfectly makes sense because the macro allows to check that the 
> extension is present to implement certain functionality conditionally.

This cited line only talks about extensions availability, not extension use. 
One example of newly introduced functions is in cl_khr_in64_base_atomics. The 
specs say:

  The optional extensions cl_khr_int64_base_atomics and 
cl_khr_int64_extended_atomics
  implement atomic operations on 64-bit signed and unsigned integers to 
locations in __global
  an

[PATCH] D89582: clang/AMDGPU: Apply workgroup related attributes to all functions

[Stanislav Mekhanoshin via Phabricator via cfe-commits]

rampitec added a comment.

In D89582#2335619 , @arsenm wrote:

> In D89582#2335574 , @yaxunl wrote:
>
>> What if a device function is called by kernels with different work group 
>> sizes, will caller's work group size override callee's work group size?
>
> It's user error to call a function with a larger range than the caller

The problem is that user can override default on a kernel with the attribute, 
but cannot do so on function. So a module can be compiled with a default 
smaller than requested on one of the kernels.

Then if default is maximum 1024 and can only be overridden with the 
--gpu-max-threads-per-block option it would not be problem, if not the 
description of the option:

  LANGOPT(GPUMaxThreadsPerBlock, 32, 256, "default max threads per block for 
kernel launch bounds for HIP")

I.e. it says about the "default", so it should be perfectly legal to set a 
higher limits on a specific kernel. Should the option say it restricts the 
maximum it would be legal to apply it to functions as well.


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

https://reviews.llvm.org/D89582

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

[PATCH] D89582: clang/AMDGPU: Apply workgroup related attributes to all functions

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

In D89582#2335671 , @rampitec wrote:

> In D89582#2335619 , @arsenm wrote:
>
>> In D89582#2335574 , @yaxunl wrote:
>>
>>> What if a device function is called by kernels with different work group 
>>> sizes, will caller's work group size override callee's work group size?
>>
>> It's user error to call a function with a larger range than the caller
>
> The problem is that user can override default on a kernel with the attribute, 
> but cannot do so on function. So a module can be compiled with a default 
> smaller than requested on one of the kernels.



> Then if default is maximum 1024 and can only be overridden with the 
> --gpu-max-threads-per-block option it would not be problem, if not the 
> description of the option:
>
>   LANGOPT(GPUMaxThreadsPerBlock, 32, 256, "default max threads per block for 
> kernel launch bounds for HIP")
>
> I.e. it says about the "default", so it should be perfectly legal to set a 
> higher limits on a specific kernel. Should the option say it restricts the 
> maximum it would be legal to apply it to functions as well.

The current backend default ends up greatly restricting the registers used in 
the functions, and increasing the spilling.


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

https://reviews.llvm.org/D89582

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

[PATCH] D89360: Treat constant contexts as being in the default rounding mode.

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

rsmith updated this revision to Diff 298724.
rsmith added a comment.

- Add more testcases to demonstrate behavior in C.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89360

Files:
  clang/lib/AST/ExprConstant.cpp
  clang/test/Sema/rounding-math.c
  clang/test/SemaCXX/rounding-math.cpp


Index: clang/test/SemaCXX/rounding-math.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/rounding-math.cpp
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 -triple x86_64-linux -verify=norounding %s
+// RUN: %clang_cc1 -triple x86_64-linux -verify=rounding %s -frounding-math
+// rounding-no-diagnostics
+
+#define fold(x) (__builtin_constant_p(x) ? (x) : (x))
+
+constexpr double a = 1.0 / 3.0;
+
+constexpr int f(int n) { return int(n * (1.0 / 3.0)); }
+
+using T = int[f(3)];
+using T = int[1];
+
+enum Enum { enum_a = f(3) };
+
+struct Bitfield {
+  unsigned int n : 1;
+  unsigned int m : f(3);
+};
+
+void f(Bitfield &b) {
+  b.n = int(6 * (1.0 / 3.0)); // norounding-warning {{changes value from 2 to 
0}}
+}
+
+const int k = 3 * (1.0 / 3.0);
+static_assert(k == 1, "");
+
+void g() {
+  // FIXME: Constant-evaluating this initializer is surprising, and violates
+  // the recommended practice in C++ [expr.const]p12:
+  //
+  //   Implementations should provide consistent results of floating-point
+  //   evaluations, irrespective of whether the evaluation is performed during
+  //   translation or during program execution.
+  const int k = 3 * (1.0 / 3.0);
+  static_assert(k == 1, "");
+}
+
+int *h() {
+  return new int[int(-3 * (1.0 / 3.0))]; // norounding-error {{too large}}
+}
Index: clang/test/Sema/rounding-math.c
===
--- /dev/null
+++ clang/test/Sema/rounding-math.c
@@ -0,0 +1,31 @@
+// RUN: %clang_cc1 -triple x86_64-linux -verify=norounding %s
+// RUN: %clang_cc1 -triple x86_64-linux -std=c17 -verify=rounding-std %s 
-frounding-math
+// RUN: %clang_cc1 -triple x86_64-linux -std=gnu17 -verify=rounding-gnu %s 
-frounding-math
+
+#define fold(x) (__builtin_constant_p(x) ? (x) : (x))
+
+double a = 1.0 / 3.0;
+
+#define f(n) ((n) * (1.0 / 3.0))
+_Static_assert(fold((int)f(3)) == 1, "");
+
+typedef int T[fold((int)f(3))];
+typedef int T[1];
+
+enum Enum { enum_a = (int)f(3) };
+
+struct Bitfield {
+  unsigned int n : 1;
+  unsigned int m : fold((int)f(3));
+};
+
+void bitfield(struct Bitfield *b) {
+  b->n = (int)(6 * (1.0 / 3.0)); // norounding-warning {{changes value from 2 
to 0}}
+}
+
+void vlas() {
+  // Under -frounding-math, this is a VLA.
+  // FIXME: Due to PR44406, in GNU mode we constant-fold the initializer 
resulting in a non-VLA.
+  typedef int vla[(int)(-3 * (1.0 / 3.0))]; // norounding-error {{negative 
size}} rounding-gnu-error {{negative size}}
+  struct X { vla v; }; // rounding-std-error {{fields must have a constant 
size}}
+}
Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -2528,6 +2528,11 @@
 /// Check if the given evaluation result is allowed for constant evaluation.
 static bool checkFloatingPointResult(EvalInfo &Info, const Expr *E,
  APFloat::opStatus St) {
+  // In a constant context, assume that any dynamic rounding mode or FP
+  // exception state matches the default floating-point environment.
+  if (Info.InConstantContext)
+return true;
+
   FPOptions FPO = E->getFPFeaturesInEffect(Info.Ctx.getLangOpts());
   if ((St & APFloat::opInexact) &&
   FPO.getRoundingMode() == llvm::RoundingMode::Dynamic) {


Index: clang/test/SemaCXX/rounding-math.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/rounding-math.cpp
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 -triple x86_64-linux -verify=norounding %s
+// RUN: %clang_cc1 -triple x86_64-linux -verify=rounding %s -frounding-math
+// rounding-no-diagnostics
+
+#define fold(x) (__builtin_constant_p(x) ? (x) : (x))
+
+constexpr double a = 1.0 / 3.0;
+
+constexpr int f(int n) { return int(n * (1.0 / 3.0)); }
+
+using T = int[f(3)];
+using T = int[1];
+
+enum Enum { enum_a = f(3) };
+
+struct Bitfield {
+  unsigned int n : 1;
+  unsigned int m : f(3);
+};
+
+void f(Bitfield &b) {
+  b.n = int(6 * (1.0 / 3.0)); // norounding-warning {{changes value from 2 to 0}}
+}
+
+const int k = 3 * (1.0 / 3.0);
+static_assert(k == 1, "");
+
+void g() {
+  // FIXME: Constant-evaluating this initializer is surprising, and violates
+  // the recommended practice in C++ [expr.const]p12:
+  //
+  //   Implementations should provide consistent results of floating-point
+  //   evaluations, irrespective of whether the evaluation is performed during
+  //   translation or during program execution.
+  const int k = 3 * (1.0 / 3.0);
+  static_assert(k == 1, "");
+}
+

[PATCH] D89582: clang/AMDGPU: Apply workgroup related attributes to all functions

[Stanislav Mekhanoshin via Phabricator via cfe-commits]

rampitec added a comment.

In D89582#2335704 , @arsenm wrote:

> In D89582#2335671 , @rampitec wrote:
>
>> In D89582#2335619 , @arsenm wrote:
>>
>>> In D89582#2335574 , @yaxunl wrote:
>>>
 What if a device function is called by kernels with different work group 
 sizes, will caller's work group size override callee's work group size?
>>>
>>> It's user error to call a function with a larger range than the caller
>>
>> The problem is that user can override default on a kernel with the 
>> attribute, but cannot do so on function. So a module can be compiled with a 
>> default smaller than requested on one of the kernels.
>
>
>
>> Then if default is maximum 1024 and can only be overridden with the 
>> --gpu-max-threads-per-block option it would not be problem, if not the 
>> description of the option:
>>
>>   LANGOPT(GPUMaxThreadsPerBlock, 32, 256, "default max threads per block for 
>> kernel launch bounds for HIP")
>>
>> I.e. it says about the "default", so it should be perfectly legal to set a 
>> higher limits on a specific kernel. Should the option say it restricts the 
>> maximum it would be legal to apply it to functions as well.
>
> The current backend default ends up greatly restricting the registers used in 
> the functions, and increasing the spilling.

I know the problem, but it should be better to use AMDGPUPropagateAttributes 
for this. It will clone functions if needed.


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

https://reviews.llvm.org/D89582

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

[PATCH] D89360: Treat constant contexts as being in the default rounding mode.

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

rsmith added a comment.

In D89360#2329167 , @rjmccall wrote:

> Okay.  I can accept the fairly unfortunate thing with `const int` 
> initializers.  When is `IsConstantContext` set in C, just static initializers?

This affects static initializers, enumerators, bit-widths, array bounds, case 
labels, and indexes in array designators. For code not relying on extensions, 
only static initializers are affected, but as an extension we do permit 
floating-point math in other contexts. I've added some tests for the C side of 
things to demonstrate.

The C tests reveal one issue: block-scope array bounds get constant-folded in 
GNU mode even if they contain floating-point operations. That's PR44406; D89523 
 and D89520  
have a fix for that which should hopefully land soon. I don't think we need to 
block on it.

In D89360#2334038 , @sepavloff wrote:

> Probably there is an issue with code generation. The source:
>
>   constexpr float func_01(float x, float y) {
> return x + y;
>   }
>   
>   float V1 = func_01(1.0F, 0x0.01p0F);
>
> compiled with '-frounding-math' must produce dynamic initializer. It however 
> is evaluated at compile time.

Evaluating it at compile time is in line with the plan from 
https://reviews.llvm.org/D87528#2270676. The C++ rule is that initializers for 
static storage duration variables are first evaluated during translation 
(therefore, per our plan, in the default rounding mode), and only evaluated at 
runtime (and therefore in the runtime rounding mode) if the compile-time 
evaluation fails. This is in line with the C rules; C11 F.8.5 says: "All 
computation for automatic initialization is done (as if) at execution time; 
thus, it is affected by any operative modes and raises floating-point 
exceptions as required by IEC 60559 (provided the state for the FENV_ACCESS 
pragma is ‘‘on’’). All computation for initialization of objects that have 
static or thread storage duration is done (as if) at translation time." C++ 
generalizes this by adding another phase of initialization (at runtime) if the 
translation-time initialization fails, but the translation-time evaluation of 
the initializer of `V1` succeeds so it should be treated as a constant 
initializer.

And just a side note: we're currently blocked by this. C++ builds using 
`-frounding-math` have not worked at all since D87822 
 landed. If we can't come to an agreement on a 
fix very soon, I think we need to revert D87822 
 while we figure it out.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89360

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

[PATCH] D89360: Treat constant contexts as being in the default rounding mode.

[John McCall via Phabricator via cfe-commits]

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

Okay, thanks.  This LGTM.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89360

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

[PATCH] D89429: clang/Basic: Replace SourceManager::getMemoryBufferForFile, NFC

[Jonas Devlieghere via Phabricator via cfe-commits]

JDevlieghere added inline comments.



Comment at: clang/lib/Basic/SourceManager.cpp:705
+llvm::Optional
+SourceManager::getMemoryBufferForFileOrNone(const FileEntry *File) {
   const SrcMgr::ContentCache *IR = getOrCreateContentCache(File);

Would it make sense to rename this to the slightly less verbose 
`getMemoryBufferOrNone` now that it takes just the File as an argument? Or 
maybe even `getBufferOrNone` like the method in `ContentCache`. 


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

https://reviews.llvm.org/D89429

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

[PATCH] D69840: [Basic] Make SourceLocation usable as key in hash maps, NFCI

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

dexonsmith requested changes to this revision.
dexonsmith added a comment.
This revision now requires changes to proceed.
Herald added a subscriber: sstefan1.

If you're still interested in pursuing this, I'm happy to review it.

A general comment is that there are a couple of functional changes in this 
patch, where hash values are changing and data structures are being changed, 
but they're buried in the noise of the refactoring that's going on at the same 
time. I suggest splitting this up at least into two, where most of the NFC 
changes are in a different commit.




Comment at: 
clang-tools-extra/clang-tidy/abseil/UpgradeDurationConversionsCheck.h:35
 private:
-  std::unordered_set MatchedTemplateLocations;
+  llvm::DenseSet MatchedTemplateLocations;
 };

Changing the data structure (`DenseSet` <= `std::unordered_set`) seems 
unrelated to the rest of the patch. If it's necessary / useful, then please do 
it separately. It'll be important to confirm that the users of 
`MatchedTemplateLocations` don't rely on the values having stable addresses.



Comment at: clang/include/clang/Basic/SourceLocation.h:178
 
+  unsigned getHashValue() const {
+return ID * 37U;

I suggest reusing the hash function for `unsigned`.


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

https://reviews.llvm.org/D69840

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

[PATCH] D85788: [Clang test] Update to allow passing extra default clang arguments in use_clang

[Gui Andrade via Phabricator via cfe-commits]

guiand added a comment.

Did we decide that we wanted this change then? I remember there being 
discussion around whether it's the right approach.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85788

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

[PATCH] D86844: [LoopDeletion] Allows deletion of possibly infinite side-effect free loops

[Atmn Patel via Phabricator via cfe-commits]

atmnpatel updated this revision to Diff 298734.
atmnpatel added a comment.

Reverted to prior diff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86844

Files:
  clang/test/Misc/loop-opt-setup.c
  llvm/include/llvm/Transforms/Utils/LoopUtils.h
  llvm/lib/Transforms/Scalar/LoopDeletion.cpp
  llvm/lib/Transforms/Utils/LoopUtils.cpp
  llvm/test/Other/loop-deletion-printer.ll
  llvm/test/Other/loop-pm-invalidation.ll
  llvm/test/Transforms/LICM/2003-02-27-PreheaderProblem.ll
  llvm/test/Transforms/LoopDeletion/2017-07-11-incremental-dt.ll
  llvm/test/Transforms/LoopDeletion/basic-remark.ll
  llvm/test/Transforms/LoopDeletion/diundef.ll
  llvm/test/Transforms/LoopDeletion/invalidation.ll
  llvm/test/Transforms/LoopDeletion/multiple-exit-conditions.ll
  llvm/test/Transforms/LoopDeletion/multiple-exits.ll
  llvm/test/Transforms/LoopDeletion/mustprogress.ll
  llvm/test/Transforms/LoopDeletion/unreachable-loops.ll
  llvm/test/Transforms/LoopDeletion/use-in-unreachable.ll
  llvm/test/Transforms/SCCP/calltest.ll
  llvm/test/Transforms/SimpleLoopUnswitch/pr37888.ll

Index: llvm/test/Transforms/SimpleLoopUnswitch/pr37888.ll
===
--- llvm/test/Transforms/SimpleLoopUnswitch/pr37888.ll
+++ llvm/test/Transforms/SimpleLoopUnswitch/pr37888.ll
@@ -7,7 +7,7 @@
 
 target triple = "x86_64-unknown-linux-gnu"
 
-define void @pr37888() {
+define void @pr37888() willreturn {
 ; CHECK-LABEL: define void @pr37888()
 entry:
   %tobool = icmp ne i16 undef, 0
Index: llvm/test/Transforms/SCCP/calltest.ll
===
--- llvm/test/Transforms/SCCP/calltest.ll
+++ llvm/test/Transforms/SCCP/calltest.ll
@@ -4,7 +4,7 @@
 %empty = type {}
 declare %empty @has_side_effects()
 
-define double @test_0(i32 %param) {
+define double @test_0(i32 %param) willreturn {
 ; CHECK-LABEL: @test_0(
 ; CHECK-NOT: br
 entry:
Index: llvm/test/Transforms/LoopDeletion/use-in-unreachable.ll
===
--- llvm/test/Transforms/LoopDeletion/use-in-unreachable.ll
+++ llvm/test/Transforms/LoopDeletion/use-in-unreachable.ll
@@ -3,7 +3,7 @@
 ; Checking that possible users of instruction from the loop in
 ; unreachable blocks are handled.
 
-define i64 @foo() {
+define i64 @foo() willreturn {
 entry:
   br label %invloop
 ; CHECK-LABEL-NOT: invloop
Index: llvm/test/Transforms/LoopDeletion/unreachable-loops.ll
===
--- llvm/test/Transforms/LoopDeletion/unreachable-loops.ll
+++ llvm/test/Transforms/LoopDeletion/unreachable-loops.ll
@@ -216,7 +216,7 @@
 ; Show recursive deletion of loops. Since we start with subloops and progress outward 
 ; to parent loop, we first delete the loop L2. Now loop L1 becomes a non-loop since it's backedge
 ; from L2's preheader to L1's exit block is never taken. So, L1 gets deleted as well.
-define void @test8(i64 %n) {
+define void @test8(i64 %n) #0 {
 ; CHECK-LABEL: test8
 ; CHECK-LABEL: entry:
 ; CHECK-NEXT: br label %exit
@@ -318,7 +318,7 @@
 ; deleted.
 ; In the next iteration, since L2 is never executed and has no subloops, we delete
 ; L2 as well. Finally, the outermost loop L1 is deleted.
-define void @test11(i64 %n) {
+define void @test11(i64 %n) #0 {
 ; CHECK-LABEL: test11
 ; CHECK-LABEL: entry:
 ; CHECK-NEXT: br label %exit
@@ -355,7 +355,7 @@
 
 
 ; 2 edges from a single exiting block to the exit block.
-define i64 @test12(i64 %n){
+define i64 @test12(i64 %n) #0 {
 ;CHECK-LABEL: @test12
 ; CHECK-NOT: L1:
 ; CHECK-NOT: L1Latch:
@@ -392,7 +392,7 @@
 }
 
 ; multiple edges to exit block from the same exiting blocks
-define i64 @test13(i64 %n) {
+define i64 @test13(i64 %n) #0 {
 ; CHECK-LABEL: @test13
 ; CHECK-NOT: L1:
 ; CHECK-NOT: L1Latch:
@@ -433,3 +433,5 @@
   %y.phi = phi i64 [ 10, %L1Block ], [ 10, %L1Block ], [ %y.next, %L1 ], [ 30, %L1Latch ], [ 30, %L1Latch ]
   ret i64 %y.phi
 }
+
+attributes #0 = { willreturn }
Index: llvm/test/Transforms/LoopDeletion/mustprogress.ll
===
--- llvm/test/Transforms/LoopDeletion/mustprogress.ll
+++ llvm/test/Transforms/LoopDeletion/mustprogress.ll
@@ -14,7 +14,9 @@
 ; CHECK-NEXT:  entry:
 ; CHECK-NEXT:br label [[FOR_END:%.*]]
 ; CHECK:   for.end:
-; CHECK-NEXT:unreachable
+; CHECK-NEXT:br label [[FOR_COND1:%.*]]
+; CHECK:   for.cond1:
+; CHECK-NEXT:br label [[FOR_COND1]]
 ;
 entry:
   br label %for.cond
@@ -43,7 +45,9 @@
 ; CHECK-NEXT:  entry:
 ; CHECK-NEXT:br label [[FOR_END:%.*]]
 ; CHECK:   for.end:
-; CHECK-NEXT:unreachable
+; CHECK-NEXT:br label [[FOR_COND1:%.*]]
+; CHECK:   for.cond1:
+; CHECK-NEXT:br label [[FOR_COND1]]
 ;
 entry:
   br label %for.cond
Index: llvm/test/Transforms/LoopDeletion/multiple-exits.ll

[PATCH] D85788: [Clang test] Update to allow passing extra default clang arguments in use_clang

[Evgenii Stepanov via Phabricator via cfe-commits]

eugenis added a comment.

I don't like the %clang_bin substitution - imho it's unclear for the test 
authors when to use it instead of %clang, but I can't come up with a better 
idea.

Is it true that %clang_bin is only necessary when the automatically added 
-disable-noundef-analysis flag triggers an unused argument warning, or are 
there other reasons?

I wonder it can be avoided by

- disable noundef analysis by default in cc1
- always add -enable-noundef-analysis in the driver when invoking cc1


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D85788

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

[PATCH] D86844: [LoopDeletion] Allows deletion of possibly infinite side-effect free loops

[Atmn Patel via Phabricator via cfe-commits]

atmnpatel updated this revision to Diff 298736.
atmnpatel added a comment.

nit.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86844

Files:
  clang/test/Misc/loop-opt-setup.c
  llvm/include/llvm/Transforms/Utils/LoopUtils.h
  llvm/lib/Transforms/Scalar/LoopDeletion.cpp
  llvm/lib/Transforms/Utils/LoopUtils.cpp
  llvm/test/Other/loop-deletion-printer.ll
  llvm/test/Other/loop-pm-invalidation.ll
  llvm/test/Transforms/LICM/2003-02-27-PreheaderProblem.ll
  llvm/test/Transforms/LoopDeletion/2017-07-11-incremental-dt.ll
  llvm/test/Transforms/LoopDeletion/basic-remark.ll
  llvm/test/Transforms/LoopDeletion/diundef.ll
  llvm/test/Transforms/LoopDeletion/invalidation.ll
  llvm/test/Transforms/LoopDeletion/multiple-exit-conditions.ll
  llvm/test/Transforms/LoopDeletion/multiple-exits.ll
  llvm/test/Transforms/LoopDeletion/mustprogress.ll
  llvm/test/Transforms/LoopDeletion/unreachable-loops.ll
  llvm/test/Transforms/LoopDeletion/use-in-unreachable.ll
  llvm/test/Transforms/SCCP/calltest.ll
  llvm/test/Transforms/SimpleLoopUnswitch/pr37888.ll

Index: llvm/test/Transforms/SimpleLoopUnswitch/pr37888.ll
===
--- llvm/test/Transforms/SimpleLoopUnswitch/pr37888.ll
+++ llvm/test/Transforms/SimpleLoopUnswitch/pr37888.ll
@@ -7,7 +7,7 @@
 
 target triple = "x86_64-unknown-linux-gnu"
 
-define void @pr37888() {
+define void @pr37888() willreturn {
 ; CHECK-LABEL: define void @pr37888()
 entry:
   %tobool = icmp ne i16 undef, 0
Index: llvm/test/Transforms/SCCP/calltest.ll
===
--- llvm/test/Transforms/SCCP/calltest.ll
+++ llvm/test/Transforms/SCCP/calltest.ll
@@ -4,7 +4,7 @@
 %empty = type {}
 declare %empty @has_side_effects()
 
-define double @test_0(i32 %param) {
+define double @test_0(i32 %param) willreturn {
 ; CHECK-LABEL: @test_0(
 ; CHECK-NOT: br
 entry:
Index: llvm/test/Transforms/LoopDeletion/use-in-unreachable.ll
===
--- llvm/test/Transforms/LoopDeletion/use-in-unreachable.ll
+++ llvm/test/Transforms/LoopDeletion/use-in-unreachable.ll
@@ -3,7 +3,7 @@
 ; Checking that possible users of instruction from the loop in
 ; unreachable blocks are handled.
 
-define i64 @foo() {
+define i64 @foo() willreturn {
 entry:
   br label %invloop
 ; CHECK-LABEL-NOT: invloop
Index: llvm/test/Transforms/LoopDeletion/unreachable-loops.ll
===
--- llvm/test/Transforms/LoopDeletion/unreachable-loops.ll
+++ llvm/test/Transforms/LoopDeletion/unreachable-loops.ll
@@ -216,7 +216,7 @@
 ; Show recursive deletion of loops. Since we start with subloops and progress outward 
 ; to parent loop, we first delete the loop L2. Now loop L1 becomes a non-loop since it's backedge
 ; from L2's preheader to L1's exit block is never taken. So, L1 gets deleted as well.
-define void @test8(i64 %n) {
+define void @test8(i64 %n) #0 {
 ; CHECK-LABEL: test8
 ; CHECK-LABEL: entry:
 ; CHECK-NEXT: br label %exit
@@ -318,7 +318,7 @@
 ; deleted.
 ; In the next iteration, since L2 is never executed and has no subloops, we delete
 ; L2 as well. Finally, the outermost loop L1 is deleted.
-define void @test11(i64 %n) {
+define void @test11(i64 %n) #0 {
 ; CHECK-LABEL: test11
 ; CHECK-LABEL: entry:
 ; CHECK-NEXT: br label %exit
@@ -355,7 +355,7 @@
 
 
 ; 2 edges from a single exiting block to the exit block.
-define i64 @test12(i64 %n){
+define i64 @test12(i64 %n) #0 {
 ;CHECK-LABEL: @test12
 ; CHECK-NOT: L1:
 ; CHECK-NOT: L1Latch:
@@ -392,7 +392,7 @@
 }
 
 ; multiple edges to exit block from the same exiting blocks
-define i64 @test13(i64 %n) {
+define i64 @test13(i64 %n) #0 {
 ; CHECK-LABEL: @test13
 ; CHECK-NOT: L1:
 ; CHECK-NOT: L1Latch:
@@ -433,3 +433,5 @@
   %y.phi = phi i64 [ 10, %L1Block ], [ 10, %L1Block ], [ %y.next, %L1 ], [ 30, %L1Latch ], [ 30, %L1Latch ]
   ret i64 %y.phi
 }
+
+attributes #0 = { willreturn }
Index: llvm/test/Transforms/LoopDeletion/mustprogress.ll
===
--- llvm/test/Transforms/LoopDeletion/mustprogress.ll
+++ llvm/test/Transforms/LoopDeletion/mustprogress.ll
@@ -14,7 +14,9 @@
 ; CHECK-NEXT:  entry:
 ; CHECK-NEXT:br label [[FOR_END:%.*]]
 ; CHECK:   for.end:
-; CHECK-NEXT:unreachable
+; CHECK-NEXT:br label [[FOR_COND1:%.*]]
+; CHECK:   for.cond1:
+; CHECK-NEXT:br label [[FOR_COND1]]
 ;
 entry:
   br label %for.cond
@@ -43,7 +45,9 @@
 ; CHECK-NEXT:  entry:
 ; CHECK-NEXT:br label [[FOR_END:%.*]]
 ; CHECK:   for.end:
-; CHECK-NEXT:unreachable
+; CHECK-NEXT:br label [[FOR_COND1:%.*]]
+; CHECK:   for.cond1:
+; CHECK-NEXT:br label [[FOR_COND1]]
 ;
 entry:
   br label %for.cond
Index: llvm/test/Transforms/LoopDeletion/multiple-exits.ll
===
---

[clang] 48c70c1 - Extend memset-to-zero optimization to C++11 aggregate functional casts

[Richard Smith via cfe-commits]

Author: Richard Smith
Date: 2020-10-16T13:21:08-07:00
New Revision: 48c70c1664aa4512cb7e08352dd8eb33dde4807c

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

LOG: Extend memset-to-zero optimization to C++11 aggregate functional casts
Aggr{...}.

We previously missed these cases due to not stepping over the additional
AST nodes representing their syntactic form.

Added: 


Modified: 
clang/lib/CodeGen/CGExprAgg.cpp
clang/test/CodeGenCXX/cxx11-initializer-aggregate.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGExprAgg.cpp b/clang/lib/CodeGen/CGExprAgg.cpp
index 43e23d986ae0..625b9116ff25 100644
--- a/clang/lib/CodeGen/CGExprAgg.cpp
+++ b/clang/lib/CodeGen/CGExprAgg.cpp
@@ -1759,7 +1759,9 @@ void 
AggExprEmitter::VisitDesignatedInitUpdateExpr(DesignatedInitUpdateExpr *E)
 /// non-zero bytes that will be stored when outputting the initializer for the
 /// specified initializer expression.
 static CharUnits GetNumNonZeroBytesInInit(const Expr *E, CodeGenFunction &CGF) 
{
-  E = E->IgnoreParens();
+  if (auto *MTE = dyn_cast(E))
+E = MTE->getSubExpr();
+  E = E->IgnoreParenNoopCasts(CGF.getContext());
 
   // 0 and 0.0 won't require any non-zero stores!
   if (isSimpleZero(E, CGF)) return CharUnits::Zero();
@@ -1808,7 +1810,7 @@ static CharUnits GetNumNonZeroBytesInInit(const Expr *E, 
CodeGenFunction &CGF) {
 }
   }
 
-
+  // FIXME: This overestimates the number of non-zero bytes for bit-fields.
   CharUnits NumNonZeroBytes = CharUnits::Zero();
   for (unsigned i = 0, e = ILE->getNumInits(); i != e; ++i)
 NumNonZeroBytes += GetNumNonZeroBytesInInit(ILE->getInit(i), CGF);

diff  --git a/clang/test/CodeGenCXX/cxx11-initializer-aggregate.cpp 
b/clang/test/CodeGenCXX/cxx11-initializer-aggregate.cpp
index 6b10efd34f92..3e9d936a16f8 100644
--- a/clang/test/CodeGenCXX/cxx11-initializer-aggregate.cpp
+++ b/clang/test/CodeGenCXX/cxx11-initializer-aggregate.cpp
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 -std=c++11 -S -emit-llvm -o - %s -triple x86_64-linux-gnu | 
FileCheck %s
+// RUN: %clang_cc1 -std=c++17 -S -emit-llvm -o - %s -triple x86_64-linux-gnu | 
FileCheck %s
 
 struct A { int a, b; int f(); };
 
@@ -118,4 +119,24 @@ namespace ZeroInit {
   // This variable must be initialized elementwise.
   Filler data_e1[1024] = {};
   // CHECK: getelementptr inbounds {{.*}} @_ZN8ZeroInit7data_e1E
+
+  struct Largeish {
+long a, b, c;
+  };
+  // CHECK: define {{.*}}@_ZN8ZeroInit9largeish1Ev(
+  // CHECK-NOT }
+  // CHECK: call {{.*}}memset
+  Largeish largeish1() { return {}; }
+  // CHECK: define {{.*}}@_ZN8ZeroInit9largeish2Ev(
+  // CHECK-NOT }
+  // CHECK: call {{.*}}memset
+  Largeish largeish2() { return Largeish(); }
+  // CHECK: define {{.*}}@_ZN8ZeroInit9largeish3Ev(
+  // CHECK-NOT }
+  // CHECK: call {{.*}}memset
+  Largeish largeish3() { return Largeish{}; }
+  // CHECK: define {{.*}}@_ZN8ZeroInit9largeish4Ev(
+  // CHECK-NOT }
+  // CHECK: call {{.*}}memset
+  Largeish largeish4() { return (Largeish){}; }
 }



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

[PATCH] D86844: [LoopDeletion] Allows deletion of possibly infinite side-effect free loops

[Atmn Patel via Phabricator via cfe-commits]

atmnpatel updated this revision to Diff 298740.
atmnpatel added a comment.

fixed splice.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D86844

Files:
  clang/test/Misc/loop-opt-setup.c
  llvm/include/llvm/Transforms/Utils/LoopUtils.h
  llvm/lib/Transforms/Scalar/LoopDeletion.cpp
  llvm/lib/Transforms/Utils/LoopUtils.cpp
  llvm/test/Other/loop-deletion-printer.ll
  llvm/test/Other/loop-pm-invalidation.ll
  llvm/test/Transforms/LICM/2003-02-27-PreheaderProblem.ll
  llvm/test/Transforms/LoopDeletion/2017-07-11-incremental-dt.ll
  llvm/test/Transforms/LoopDeletion/basic-remark.ll
  llvm/test/Transforms/LoopDeletion/diundef.ll
  llvm/test/Transforms/LoopDeletion/invalidation.ll
  llvm/test/Transforms/LoopDeletion/multiple-exit-conditions.ll
  llvm/test/Transforms/LoopDeletion/multiple-exits.ll
  llvm/test/Transforms/LoopDeletion/mustprogress.ll
  llvm/test/Transforms/LoopDeletion/unreachable-loops.ll
  llvm/test/Transforms/LoopDeletion/use-in-unreachable.ll
  llvm/test/Transforms/SCCP/calltest.ll
  llvm/test/Transforms/SimpleLoopUnswitch/pr37888.ll

Index: llvm/test/Transforms/SimpleLoopUnswitch/pr37888.ll
===
--- llvm/test/Transforms/SimpleLoopUnswitch/pr37888.ll
+++ llvm/test/Transforms/SimpleLoopUnswitch/pr37888.ll
@@ -7,7 +7,7 @@
 
 target triple = "x86_64-unknown-linux-gnu"
 
-define void @pr37888() {
+define void @pr37888() willreturn {
 ; CHECK-LABEL: define void @pr37888()
 entry:
   %tobool = icmp ne i16 undef, 0
Index: llvm/test/Transforms/SCCP/calltest.ll
===
--- llvm/test/Transforms/SCCP/calltest.ll
+++ llvm/test/Transforms/SCCP/calltest.ll
@@ -4,7 +4,7 @@
 %empty = type {}
 declare %empty @has_side_effects()
 
-define double @test_0(i32 %param) {
+define double @test_0(i32 %param) willreturn {
 ; CHECK-LABEL: @test_0(
 ; CHECK-NOT: br
 entry:
Index: llvm/test/Transforms/LoopDeletion/use-in-unreachable.ll
===
--- llvm/test/Transforms/LoopDeletion/use-in-unreachable.ll
+++ llvm/test/Transforms/LoopDeletion/use-in-unreachable.ll
@@ -3,7 +3,7 @@
 ; Checking that possible users of instruction from the loop in
 ; unreachable blocks are handled.
 
-define i64 @foo() {
+define i64 @foo() willreturn {
 entry:
   br label %invloop
 ; CHECK-LABEL-NOT: invloop
Index: llvm/test/Transforms/LoopDeletion/unreachable-loops.ll
===
--- llvm/test/Transforms/LoopDeletion/unreachable-loops.ll
+++ llvm/test/Transforms/LoopDeletion/unreachable-loops.ll
@@ -216,7 +216,7 @@
 ; Show recursive deletion of loops. Since we start with subloops and progress outward 
 ; to parent loop, we first delete the loop L2. Now loop L1 becomes a non-loop since it's backedge
 ; from L2's preheader to L1's exit block is never taken. So, L1 gets deleted as well.
-define void @test8(i64 %n) {
+define void @test8(i64 %n) #0 {
 ; CHECK-LABEL: test8
 ; CHECK-LABEL: entry:
 ; CHECK-NEXT: br label %exit
@@ -318,7 +318,7 @@
 ; deleted.
 ; In the next iteration, since L2 is never executed and has no subloops, we delete
 ; L2 as well. Finally, the outermost loop L1 is deleted.
-define void @test11(i64 %n) {
+define void @test11(i64 %n) #0 {
 ; CHECK-LABEL: test11
 ; CHECK-LABEL: entry:
 ; CHECK-NEXT: br label %exit
@@ -355,7 +355,7 @@
 
 
 ; 2 edges from a single exiting block to the exit block.
-define i64 @test12(i64 %n){
+define i64 @test12(i64 %n) #0 {
 ;CHECK-LABEL: @test12
 ; CHECK-NOT: L1:
 ; CHECK-NOT: L1Latch:
@@ -392,7 +392,7 @@
 }
 
 ; multiple edges to exit block from the same exiting blocks
-define i64 @test13(i64 %n) {
+define i64 @test13(i64 %n) #0 {
 ; CHECK-LABEL: @test13
 ; CHECK-NOT: L1:
 ; CHECK-NOT: L1Latch:
@@ -433,3 +433,5 @@
   %y.phi = phi i64 [ 10, %L1Block ], [ 10, %L1Block ], [ %y.next, %L1 ], [ 30, %L1Latch ], [ 30, %L1Latch ]
   ret i64 %y.phi
 }
+
+attributes #0 = { willreturn }
Index: llvm/test/Transforms/LoopDeletion/mustprogress.ll
===
--- /dev/null
+++ llvm/test/Transforms/LoopDeletion/mustprogress.ll
@@ -0,0 +1,241 @@
+; NOTE: Assertions have been autogenerated by utils/update_test_checks.py UTC_ARGS: --function-signature --check-attributes
+; RUN: opt < %s -loop-deletion -S | FileCheck %s
+
+;; Original C Code:
+;;  void unknown_tripcount_mustprogress_attr_mustprogress_loopmd(int a, int b) {
+;;for (; a < b;) ;
+;;for (;;) ;
+;;  }
+
+define void @unknown_tripcount_mustprogress_attr_mustprogress_loopmd(i32 %a, i32 %b) #0 {
+; CHECK: Function Attrs: mustprogress
+; CHECK-LABEL: define {{[^@]+}}@unknown_tripcount_mustprogress_attr_mustprogress_loopmd
+; CHECK-SAME: (i32 [[A:%.*]], i32 [[B:%.*]]) [[ATTR0:#.*]] {
+; CHECK-NEXT:  entry:
+; CHECK-NEXT:br label [[FOR_END:%.*]]
+; CHECK:   for.end:
+; CHECK-N

[clang] 7e801ca - Treat constant contexts as being in the default rounding mode.

[Richard Smith via cfe-commits]

Author: Richard Smith
Date: 2020-10-16T13:26:15-07:00
New Revision: 7e801ca0efa99f7cec7a2aea30513ad282030b51

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

LOG: Treat constant contexts as being in the default rounding mode.

This addresses a regression where pretty much all C++ compilations using
-frounding-math now fail, due to rounding being performed in constexpr
function definitions in the standard library.

This follows the "manifestly constant evaluated" approach described in
https://reviews.llvm.org/D87528#2270676 -- evaluations that are required
to succeed at compile time are permitted even in regions with dynamic
rounding modes, as are (unfortunately) the evaluation of the
initializers of local variables of const integral types.

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

Added: 
clang/test/Sema/rounding-math.c
clang/test/SemaCXX/rounding-math.cpp

Modified: 
clang/lib/AST/ExprConstant.cpp

Removed: 




diff  --git a/clang/lib/AST/ExprConstant.cpp b/clang/lib/AST/ExprConstant.cpp
index fda565354b92..7afc44de 100644
--- a/clang/lib/AST/ExprConstant.cpp
+++ b/clang/lib/AST/ExprConstant.cpp
@@ -2528,6 +2528,11 @@ static llvm::RoundingMode getActiveRoundingMode(EvalInfo 
&Info, const Expr *E,
 /// Check if the given evaluation result is allowed for constant evaluation.
 static bool checkFloatingPointResult(EvalInfo &Info, const Expr *E,
  APFloat::opStatus St) {
+  // In a constant context, assume that any dynamic rounding mode or FP
+  // exception state matches the default floating-point environment.
+  if (Info.InConstantContext)
+return true;
+
   FPOptions FPO = E->getFPFeaturesInEffect(Info.Ctx.getLangOpts());
   if ((St & APFloat::opInexact) &&
   FPO.getRoundingMode() == llvm::RoundingMode::Dynamic) {

diff  --git a/clang/test/Sema/rounding-math.c b/clang/test/Sema/rounding-math.c
new file mode 100644
index ..3cb5d034b143
--- /dev/null
+++ b/clang/test/Sema/rounding-math.c
@@ -0,0 +1,31 @@
+// RUN: %clang_cc1 -triple x86_64-linux -verify=norounding %s
+// RUN: %clang_cc1 -triple x86_64-linux -std=c17 -verify=rounding-std %s 
-frounding-math
+// RUN: %clang_cc1 -triple x86_64-linux -std=gnu17 -verify=rounding-gnu %s 
-frounding-math
+
+#define fold(x) (__builtin_constant_p(x) ? (x) : (x))
+
+double a = 1.0 / 3.0;
+
+#define f(n) ((n) * (1.0 / 3.0))
+_Static_assert(fold((int)f(3)) == 1, "");
+
+typedef int T[fold((int)f(3))];
+typedef int T[1];
+
+enum Enum { enum_a = (int)f(3) };
+
+struct Bitfield {
+  unsigned int n : 1;
+  unsigned int m : fold((int)f(3));
+};
+
+void bitfield(struct Bitfield *b) {
+  b->n = (int)(6 * (1.0 / 3.0)); // norounding-warning {{changes value from 2 
to 0}}
+}
+
+void vlas() {
+  // Under -frounding-math, this is a VLA.
+  // FIXME: Due to PR44406, in GNU mode we constant-fold the initializer 
resulting in a non-VLA.
+  typedef int vla[(int)(-3 * (1.0 / 3.0))]; // norounding-error {{negative 
size}} rounding-gnu-error {{negative size}}
+  struct X { vla v; }; // rounding-std-error {{fields must have a constant 
size}}
+}

diff  --git a/clang/test/SemaCXX/rounding-math.cpp 
b/clang/test/SemaCXX/rounding-math.cpp
new file mode 100644
index ..3577d2fc0756
--- /dev/null
+++ b/clang/test/SemaCXX/rounding-math.cpp
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 -triple x86_64-linux -verify=norounding %s
+// RUN: %clang_cc1 -triple x86_64-linux -verify=rounding %s -frounding-math
+// rounding-no-diagnostics
+
+#define fold(x) (__builtin_constant_p(x) ? (x) : (x))
+
+constexpr double a = 1.0 / 3.0;
+
+constexpr int f(int n) { return int(n * (1.0 / 3.0)); }
+
+using T = int[f(3)];
+using T = int[1];
+
+enum Enum { enum_a = f(3) };
+
+struct Bitfield {
+  unsigned int n : 1;
+  unsigned int m : f(3);
+};
+
+void f(Bitfield &b) {
+  b.n = int(6 * (1.0 / 3.0)); // norounding-warning {{changes value from 2 to 
0}}
+}
+
+const int k = 3 * (1.0 / 3.0);
+static_assert(k == 1, "");
+
+void g() {
+  // FIXME: Constant-evaluating this initializer is surprising, and violates
+  // the recommended practice in C++ [expr.const]p12:
+  //
+  //   Implementations should provide consistent results of floating-point
+  //   evaluations, irrespective of whether the evaluation is performed during
+  //   translation or during program execution.
+  const int k = 3 * (1.0 / 3.0);
+  static_assert(k == 1, "");
+}
+
+int *h() {
+  return new int[int(-3 * (1.0 / 3.0))]; // norounding-error {{too large}}
+}



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

[PATCH] D89360: Treat constant contexts as being in the default rounding mode.

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

This revision was landed with ongoing or failed builds.
This revision was automatically updated to reflect the committed changes.
Closed by commit rG7e801ca0efa9: Treat constant contexts as being in the 
default rounding mode. (authored by rsmith).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D89360

Files:
  clang/lib/AST/ExprConstant.cpp
  clang/test/Sema/rounding-math.c
  clang/test/SemaCXX/rounding-math.cpp


Index: clang/test/SemaCXX/rounding-math.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/rounding-math.cpp
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 -triple x86_64-linux -verify=norounding %s
+// RUN: %clang_cc1 -triple x86_64-linux -verify=rounding %s -frounding-math
+// rounding-no-diagnostics
+
+#define fold(x) (__builtin_constant_p(x) ? (x) : (x))
+
+constexpr double a = 1.0 / 3.0;
+
+constexpr int f(int n) { return int(n * (1.0 / 3.0)); }
+
+using T = int[f(3)];
+using T = int[1];
+
+enum Enum { enum_a = f(3) };
+
+struct Bitfield {
+  unsigned int n : 1;
+  unsigned int m : f(3);
+};
+
+void f(Bitfield &b) {
+  b.n = int(6 * (1.0 / 3.0)); // norounding-warning {{changes value from 2 to 
0}}
+}
+
+const int k = 3 * (1.0 / 3.0);
+static_assert(k == 1, "");
+
+void g() {
+  // FIXME: Constant-evaluating this initializer is surprising, and violates
+  // the recommended practice in C++ [expr.const]p12:
+  //
+  //   Implementations should provide consistent results of floating-point
+  //   evaluations, irrespective of whether the evaluation is performed during
+  //   translation or during program execution.
+  const int k = 3 * (1.0 / 3.0);
+  static_assert(k == 1, "");
+}
+
+int *h() {
+  return new int[int(-3 * (1.0 / 3.0))]; // norounding-error {{too large}}
+}
Index: clang/test/Sema/rounding-math.c
===
--- /dev/null
+++ clang/test/Sema/rounding-math.c
@@ -0,0 +1,31 @@
+// RUN: %clang_cc1 -triple x86_64-linux -verify=norounding %s
+// RUN: %clang_cc1 -triple x86_64-linux -std=c17 -verify=rounding-std %s 
-frounding-math
+// RUN: %clang_cc1 -triple x86_64-linux -std=gnu17 -verify=rounding-gnu %s 
-frounding-math
+
+#define fold(x) (__builtin_constant_p(x) ? (x) : (x))
+
+double a = 1.0 / 3.0;
+
+#define f(n) ((n) * (1.0 / 3.0))
+_Static_assert(fold((int)f(3)) == 1, "");
+
+typedef int T[fold((int)f(3))];
+typedef int T[1];
+
+enum Enum { enum_a = (int)f(3) };
+
+struct Bitfield {
+  unsigned int n : 1;
+  unsigned int m : fold((int)f(3));
+};
+
+void bitfield(struct Bitfield *b) {
+  b->n = (int)(6 * (1.0 / 3.0)); // norounding-warning {{changes value from 2 
to 0}}
+}
+
+void vlas() {
+  // Under -frounding-math, this is a VLA.
+  // FIXME: Due to PR44406, in GNU mode we constant-fold the initializer 
resulting in a non-VLA.
+  typedef int vla[(int)(-3 * (1.0 / 3.0))]; // norounding-error {{negative 
size}} rounding-gnu-error {{negative size}}
+  struct X { vla v; }; // rounding-std-error {{fields must have a constant 
size}}
+}
Index: clang/lib/AST/ExprConstant.cpp
===
--- clang/lib/AST/ExprConstant.cpp
+++ clang/lib/AST/ExprConstant.cpp
@@ -2528,6 +2528,11 @@
 /// Check if the given evaluation result is allowed for constant evaluation.
 static bool checkFloatingPointResult(EvalInfo &Info, const Expr *E,
  APFloat::opStatus St) {
+  // In a constant context, assume that any dynamic rounding mode or FP
+  // exception state matches the default floating-point environment.
+  if (Info.InConstantContext)
+return true;
+
   FPOptions FPO = E->getFPFeaturesInEffect(Info.Ctx.getLangOpts());
   if ((St & APFloat::opInexact) &&
   FPO.getRoundingMode() == llvm::RoundingMode::Dynamic) {


Index: clang/test/SemaCXX/rounding-math.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/rounding-math.cpp
@@ -0,0 +1,41 @@
+// RUN: %clang_cc1 -triple x86_64-linux -verify=norounding %s
+// RUN: %clang_cc1 -triple x86_64-linux -verify=rounding %s -frounding-math
+// rounding-no-diagnostics
+
+#define fold(x) (__builtin_constant_p(x) ? (x) : (x))
+
+constexpr double a = 1.0 / 3.0;
+
+constexpr int f(int n) { return int(n * (1.0 / 3.0)); }
+
+using T = int[f(3)];
+using T = int[1];
+
+enum Enum { enum_a = f(3) };
+
+struct Bitfield {
+  unsigned int n : 1;
+  unsigned int m : f(3);
+};
+
+void f(Bitfield &b) {
+  b.n = int(6 * (1.0 / 3.0)); // norounding-warning {{changes value from 2 to 0}}
+}
+
+const int k = 3 * (1.0 / 3.0);
+static_assert(k == 1, "");
+
+void g() {
+  // FIXME: Constant-evaluating this initializer is surprising, and violates
+  // the recommended practice in C++ [expr.const]p12:
+  //
+  //   Implementations should provide consistent results of floating-point
+  //   evaluations, irrespective of whether the evaluation is performe