[PATCH] D99517: Implemented [[clang::musttail]] attribute for guaranteed tail calls.

2021-04-07 Thread Josh Haberman via Phabricator via cfe-commits
haberman added inline comments.



Comment at: clang/include/clang/Basic/AttrDocs.td:458
+same number of arguments as the caller. The types of the return value and all
+arguments must be similar, including the implicit "this" argument, if any.
+Any variables in scope, including all arguments to the function and the

aaron.ballman wrote:
> It'd be nice if we could nail down "similar" somewhat. I don't know if `int` 
> and `short` are similar (due to promotions) or `const int` and `int` are 
> similar, etc.
Done. I tried to summarize the C++ concept of "similar" types as defined in 
https://eel.is/c++draft/conv.qual#2 and implemented in 
https://clang.llvm.org/doxygen/classclang_1_1ASTContext.html#a1b1b3b7a67a30fd817ba85454780d8ad



Comment at: clang/lib/Sema/SemaStmt.cpp:596
+  if (!CE->getCalleeDecl()) {
+assert(hasUncompilableErrorOccurred() && "expected previous error");
+return false;

rsmith wrote:
> A call expression doesn't necessarily have a known callee declaration. I 
> would expect this assert to fire on a case like:
> ```
> void f() {
>   void (*p)() = f;
>   [[clang::musttail]] return p();
> }
> ```
> We should reject this with a diagnostic.
I think this case will work actually, the callee decl in this case is just the 
function pointer, which seems appropriate and type checks correctly.

I added a test for this.



Comment at: clang/lib/Sema/SemaStmt.cpp:631
+// Caller is an Obj-C block decl: ^(void) { /* ... */ }
+assert(dyn_cast(CurContext) && "unexpected decl context");
+Diag(St->getBeginLoc(), diag::err_musttail_from_block_forbidden) << 

rjmccall wrote:
> rsmith wrote:
> > There are a couple of other contexts that can include a return statement: 
> > the caller could also be an `ObjCMethodDecl` (an Objective-C method) or a 
> > `CapturedDecl` (the body of a `#pragma omp` parallel region). I'd probably 
> > use a specific diagnostic ("cannot be used from a block" / "cannot be used 
> > from an Objective-C function") for the block and ObjCMethod case, and a 
> > nonsepcific-but-correct "cannot be used from this context" for anything 
> > else.
> Blocks ought to be extremely straightforward to support.  Just validate that 
> the tail call is to a block pointer and then compare the underlying function 
> types line up in the same way.  You will need to be able to verify that there 
> isn't a non-trivial conversion on the return types, even if the return type 
> isn't known at this point in the function, but that's a problem in C++ as 
> well due to lambdas and `auto` deduced return types.
> 
> Also, you can use `isa<...>` for checks like this instead of `dyn_cast<...>`.
Tail calls to a block are indeed straightforward and are handled below. This 
check is for tail calls from a block, which I tried to add support for but 
didn't have much luck (in particular, during parsing of a block I wasn't able 
to get good type information for the block).

> I'd probably use a specific diagnostic ("cannot be used from a block" / 
> "cannot be used from an Objective-C function") for the block and ObjCMethod 
> case, and a nonsepcific-but-correct "cannot be used from this context" for 
> anything else.

I implemented this as requested. I wasn't able to test OpenMP as you apparently 
can't return from an OpenMP block.



Comment at: clang/lib/Sema/SemaStmt.cpp:561-568
+  for (const auto *A : Attrs) {
+if (A->getKind() == attr::MustTail) {
+  if (!checkMustTailAttr(SubStmt, *A)) {
+return SubStmt;
+  }
+  setFunctionHasMustTail();
+}

aaron.ballman wrote:
> haberman wrote:
> > aaron.ballman wrote:
> > > rsmith wrote:
> > > > aaron.ballman wrote:
> > > > > aaron.ballman wrote:
> > > > > > haberman wrote:
> > > > > > > aaron.ballman wrote:
> > > > > > > > haberman wrote:
> > > > > > > > > haberman wrote:
> > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > haberman wrote:
> > > > > > > > > > > > aaron.ballman wrote:
> > > > > > > > > > > > > This functionality belongs in SemaStmtAttr.cpp, I 
> > > > > > > > > > > > > think.
> > > > > > > > > > > > That is where I had originally put it, but that didn't 
> > > > > > > > > > > > work for templates. The semantic checks can only be 
> > > > > > > > > > > > performed at instantiation time. `ActOnAttributedStmt` 
> > > > > > > > > > > > seems to be the right hook point where I can evaluate 
> > > > > > > > > > > > the semantic checks for both template and non-template 
> > > > > > > > > > > > functions (with template functions getting checked at 
> > > > > > > > > > > > instantiation time).
> > > > > > > > > > > I disagree that `ActOnAttributedStmt()` is the correct 
> > > > > > > > > > > place for this checking -- template checking should occur 
> > > > > > > > > > > when the template is instantiated, same as happens for 
> > > > > > > > > > > declaration attributes. I'd like to see 

[PATCH] D99517: Implemented [[clang::musttail]] attribute for guaranteed tail calls.

2021-04-07 Thread Josh Haberman via Phabricator via cfe-commits
haberman updated this revision to Diff 336004.
haberman marked 19 inline comments as done.
haberman added a comment.
Herald added a reviewer: jdoerfert.
Herald added a subscriber: sstefan1.

- Returned validation to ActOnAttributedStmt() so it works with templates.
- Merge branch 'main' into musttail
- Address more review comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99517

Files:
  clang/include/clang/AST/Expr.h
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/ScopeInfo.h
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Expr.cpp
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGClass.cpp
  clang/lib/CodeGen/CGDecl.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGExprCXX.cpp
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/CodeGen/EHScopeStack.h
  clang/lib/Sema/JumpDiagnostics.cpp
  clang/lib/Sema/Sema.cpp
  clang/lib/Sema/SemaStmt.cpp
  clang/lib/Sema/SemaStmtAttr.cpp
  clang/test/CodeGen/attr-musttail.cpp
  clang/test/Sema/attr-musttail.c
  clang/test/Sema/attr-musttail.cpp
  clang/test/Sema/attr-musttail.m

Index: clang/test/Sema/attr-musttail.m
===
--- /dev/null
+++ clang/test/Sema/attr-musttail.m
@@ -0,0 +1,28 @@
+// RUN: %clang_cc1 -fsyntax-only -fblocks -Wno-objc-root-class -verify %s
+
+void TestObjcBlock(void) {
+  void (^x)(void) = ^(void) {
+__attribute__((musttail)) return TestObjcBlock(); // expected-error{{'musttail' attribute cannot be used from a block}}
+  };
+  __attribute__((musttail)) return x();
+}
+
+void ReturnsVoid(void);
+void TestObjcBlockVar(void) {
+  __block int i = 0;  // expected-note{{jump exits scope of __block variable}}
+  __attribute__((musttail)) return ReturnsVoid();  // expected-error{{cannot perform a tail call from this return statement}}
+}
+
+//#import 
+
+__attribute__((objc_root_class))
+@interface TestObjcClass
+@end
+
+@implementation TestObjcClass
+
+- (void)testObjCMethod {
+  __attribute__((musttail)) return ReturnsVoid(); // expected-error{{'musttail' attribute cannot be used from an Objective-C function}}
+}
+
+@end
Index: clang/test/Sema/attr-musttail.cpp
===
--- /dev/null
+++ clang/test/Sema/attr-musttail.cpp
@@ -0,0 +1,191 @@
+// RUN: %clang_cc1 -verify -fsyntax-only -fms-extensions -fcxx-exceptions -fopenmp %s
+
+int ReturnsInt1();
+int Func1() {
+  [[clang::musttail]] ReturnsInt1();   // expected-error {{'musttail' attribute only applies to return statements}}
+  [[clang::musttail(1, 2)]] return ReturnsInt1(); // expected-error {{'musttail' attribute takes no arguments}}
+  [[clang::musttail]] return 5;// expected-error {{'musttail' attribute requires that the return value is the result of a function call}}
+  [[clang::musttail]] return ReturnsInt1();
+}
+
+void NoFunctionCall() {
+  [[clang::musttail]] return;  // expected-error {{'musttail' attribute requires that the return value is the result of a function call}}
+}
+
+[[clang::musttail]] static int int_val = ReturnsInt1(); // expected-error {{'musttail' attribute cannot be applied to a declaration}}
+
+void NoParams(); // expected-note {{target function has different number of parameters (expected 1 but has 0)}}
+void TestParamArityMismatch(int x) {
+  [[clang::musttail]] return NoParams(); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}}
+}
+
+void LongParam(long x); // expected-note {{target function has type mismatch at 1st parameter (expected 'long' but has 'int')}}
+void TestParamTypeMismatch(int x) {
+  [[clang::musttail]] return LongParam(x); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}}
+}
+
+long ReturnsLong(); // expected-note {{target function has different return type ('int' expected but has 'long')}}
+int TestReturnTypeMismatch() {
+  [[clang::musttail]] return ReturnsLong(); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}}
+}
+
+struct Struct1 {
+  void MemberFunction(); // expected-note {{target function is a member of different class (expected 'void' but has 'Struct1')}}
+};
+void TestNonMemberToMember() {
+  Struct1 st;
+  [[clang::musttail]] return st.MemberFunction(); // expected-error {{'musttail' attribute requires that caller and callee have compatible function signatures}}
+}
+
+void ReturnsVoid(); // expected-note {{target function is a member of different class (expected 'Struct2' but has 'void')}}
+struct Struct2 {
+  void TestMemberToNonMember() {
+[[clang::musttail]] return ReturnsVoid(); // expected-error{{'musttail' attribute requires that caller and callee have compatible function signatures}}
+ 

[PATCH] D100085: [X86] Support -march=rocketlake

2021-04-07 Thread Freddy, Ye via Phabricator via cfe-commits
FreddyYe added a comment.

THX for review!




Comment at: clang/test/Preprocessor/predefined-arch-macros.c:1396
 
+// RUN: %clang -march=rocketlake -m32 -E -dM %s -o - 2>&1 \
+// RUN: -target i386-unknown-linux \

MaskRay wrote:
> The file may need some refactoring first. You can let RUN lines share some 
> common check prefixes, instead of adding a bunch of defines for every new 
> processor.
> 
> ```
> // CHECK_X86_64_V2: ...
> // CHECK_X86_64_V2: ...
> // CHECK_X86_64_V3: ...
> // CHECK_PROCESSOR1_M32:
> // CHECK_PROCESSOR1_M64:
> // CHECK_PROCESSOR2_M32:
> // CHECK_PROCESSOR2_M64:
> ```
I agree. I'll do it



Comment at: compiler-rt/lib/builtins/cpu_model.c:101
   INTEL_COREI7_ALDERLAKE,
+  INTEL_COREI7_ROCKETLAKE,
   AMDFAM19H_ZNVER3,

craig.topper wrote:
> This order is defined by libgcc. We can't insert in the middle unless ZNVER3 
> was in the wrong place
> 
> Why this not referenced in the switch the select subtype?
This is a mistake. I'll modify. And reference is missing in two switch. I'll 
add.



Comment at: llvm/lib/Target/X86/X86.td:767
+  // Rocketlake
+  list RKLAdditionalFeatures = [FeatureAES,
+  FeatureXSAVEC,

craig.topper wrote:
> Is this list this long because SKL includes SGX but RKL doesn't?
Yes. And I don't know any simple ways to exclude SGX here, any suggestions?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100085

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


[PATCH] D100085: [X86] Support -march=rocketlake

2021-04-07 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: compiler-rt/lib/builtins/cpu_model.c:101
   INTEL_COREI7_ALDERLAKE,
+  INTEL_COREI7_ROCKETLAKE,
   AMDFAM19H_ZNVER3,

This order is defined by libgcc. We can't insert in the middle unless ZNVER3 
was in the wrong place

Why this not referenced in the switch the select subtype?



Comment at: llvm/lib/Target/X86/X86.td:767
+  // Rocketlake
+  list RKLAdditionalFeatures = [FeatureAES,
+  FeatureXSAVEC,

Is this list this long because SKL includes SGX but RKL doesn't?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100085

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


[PATCH] D100087: Include `count` in AppleClang toolchains.

2021-04-07 Thread Dan Liew via Phabricator via cfe-commits
delcypher created this revision.
delcypher added reviewers: arphaman, JDevlieghere.
Herald added a subscriber: mgorny.
delcypher requested review of this revision.
Herald added a project: clang.

The motivation here is so we can run the compiler-rt tests
from a standalone build against AppleClang.

In particular the `Posix/halt_on_error-torture.cpp` and
`Posix/halt_on_error_suppress_equal_pcs.cpp` ASan test cases currently
require this binary for the tests to pass.

rdar://76366784


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100087

Files:
  clang/cmake/caches/Apple-stage2.cmake


Index: clang/cmake/caches/Apple-stage2.cmake
===
--- clang/cmake/caches/Apple-stage2.cmake
+++ clang/cmake/caches/Apple-stage2.cmake
@@ -65,6 +65,7 @@
   FileCheck
   yaml2obj
   not
+  count
   CACHE STRING "")
 
 set(LLVM_DISTRIBUTION_COMPONENTS


Index: clang/cmake/caches/Apple-stage2.cmake
===
--- clang/cmake/caches/Apple-stage2.cmake
+++ clang/cmake/caches/Apple-stage2.cmake
@@ -65,6 +65,7 @@
   FileCheck
   yaml2obj
   not
+  count
   CACHE STRING "")
 
 set(LLVM_DISTRIBUTION_COMPONENTS
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D100086: Include `llvm-config` and `not` in AppleClang toolchains.

2021-04-07 Thread Dan Liew 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 rG73cbc7f60ed9: Include `llvm-config` and `not` in AppleClang 
toolchains. (authored by delcypher).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100086

Files:
  clang/cmake/caches/Apple-stage2.cmake


Index: clang/cmake/caches/Apple-stage2.cmake
===
--- clang/cmake/caches/Apple-stage2.cmake
+++ clang/cmake/caches/Apple-stage2.cmake
@@ -56,6 +56,7 @@
   llvm-objdump
   llvm-nm
   llvm-size
+  llvm-config
   CACHE STRING "")
 
 set(LLVM_BUILD_UTILS ON CACHE BOOL "")
@@ -63,6 +64,7 @@
 set(LLVM_TOOLCHAIN_UTILITIES
   FileCheck
   yaml2obj
+  not
   CACHE STRING "")
 
 set(LLVM_DISTRIBUTION_COMPONENTS


Index: clang/cmake/caches/Apple-stage2.cmake
===
--- clang/cmake/caches/Apple-stage2.cmake
+++ clang/cmake/caches/Apple-stage2.cmake
@@ -56,6 +56,7 @@
   llvm-objdump
   llvm-nm
   llvm-size
+  llvm-config
   CACHE STRING "")
 
 set(LLVM_BUILD_UTILS ON CACHE BOOL "")
@@ -63,6 +64,7 @@
 set(LLVM_TOOLCHAIN_UTILITIES
   FileCheck
   yaml2obj
+  not
   CACHE STRING "")
 
 set(LLVM_DISTRIBUTION_COMPONENTS
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 73cbc7f - Include `llvm-config` and `not` in AppleClang toolchains.

2021-04-07 Thread Dan Liew via cfe-commits

Author: Dan Liew
Date: 2021-04-07T21:29:52-07:00
New Revision: 73cbc7f60ed90ad207b54b55aaf0efa0e5c38c47

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

LOG: Include `llvm-config` and `not` in AppleClang toolchains.

The motivation here is so that we can configure and run compiler-rt
tests from a standalone build against AppleClang.

rdar://75975846

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

Added: 


Modified: 
clang/cmake/caches/Apple-stage2.cmake

Removed: 




diff  --git a/clang/cmake/caches/Apple-stage2.cmake 
b/clang/cmake/caches/Apple-stage2.cmake
index ff9c612b9808..3a8bae087d32 100644
--- a/clang/cmake/caches/Apple-stage2.cmake
+++ b/clang/cmake/caches/Apple-stage2.cmake
@@ -56,6 +56,7 @@ set(LLVM_TOOLCHAIN_TOOLS
   llvm-objdump
   llvm-nm
   llvm-size
+  llvm-config
   CACHE STRING "")
 
 set(LLVM_BUILD_UTILS ON CACHE BOOL "")
@@ -63,6 +64,7 @@ set(LLVM_INSTALL_UTILS ON CACHE BOOL "")
 set(LLVM_TOOLCHAIN_UTILITIES
   FileCheck
   yaml2obj
+  not
   CACHE STRING "")
 
 set(LLVM_DISTRIBUTION_COMPONENTS



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


[PATCH] D100086: Include `llvm-config` and `not` in AppleClang toolchains.

2021-04-07 Thread Jonas Devlieghere via Phabricator via cfe-commits
JDevlieghere accepted this revision.
JDevlieghere 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/D100086/new/

https://reviews.llvm.org/D100086

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


[PATCH] D100086: Include `llvm-config` and `not` in AppleClang toolchains.

2021-04-07 Thread Dan Liew via Phabricator via cfe-commits
delcypher created this revision.
delcypher added reviewers: JDevlieghere, arphaman.
Herald added a subscriber: mgorny.
delcypher requested review of this revision.
Herald added a project: clang.

The motivation here is so that we can configure and run compiler-rt
tests from a standalone build against AppleClang.

rdar://75975846


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100086

Files:
  clang/cmake/caches/Apple-stage2.cmake


Index: clang/cmake/caches/Apple-stage2.cmake
===
--- clang/cmake/caches/Apple-stage2.cmake
+++ clang/cmake/caches/Apple-stage2.cmake
@@ -56,6 +56,7 @@
   llvm-objdump
   llvm-nm
   llvm-size
+  llvm-config
   CACHE STRING "")
 
 set(LLVM_BUILD_UTILS ON CACHE BOOL "")
@@ -63,6 +64,7 @@
 set(LLVM_TOOLCHAIN_UTILITIES
   FileCheck
   yaml2obj
+  not
   CACHE STRING "")
 
 set(LLVM_DISTRIBUTION_COMPONENTS


Index: clang/cmake/caches/Apple-stage2.cmake
===
--- clang/cmake/caches/Apple-stage2.cmake
+++ clang/cmake/caches/Apple-stage2.cmake
@@ -56,6 +56,7 @@
   llvm-objdump
   llvm-nm
   llvm-size
+  llvm-config
   CACHE STRING "")
 
 set(LLVM_BUILD_UTILS ON CACHE BOOL "")
@@ -63,6 +64,7 @@
 set(LLVM_TOOLCHAIN_UTILITIES
   FileCheck
   yaml2obj
+  not
   CACHE STRING "")
 
 set(LLVM_DISTRIBUTION_COMPONENTS
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D99996: [Driver] Drop $DEFAULT_TRIPLE-$name as a fallback program name

2021-04-07 Thread Fangrui Song via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG8ac5e440615d: [Driver] Drop $DEFAULT_TRIPLE-$name as a 
fallback program name (authored by MaskRay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D6

Files:
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/program-path-priority.c


Index: clang/test/Driver/program-path-priority.c
===
--- clang/test/Driver/program-path-priority.c
+++ clang/test/Driver/program-path-priority.c
@@ -3,8 +3,7 @@
 
 /// Check the priority used when searching for tools
 /// Names and locations are usually in this order:
-/// -tool, tool, -tool
-/// program path, PATH
+/// -tool, tool, program path, PATH
 /// (from highest to lowest priority)
 /// A higher priority name found in a lower priority
 /// location will win over a lower priority name in a
@@ -102,13 +101,11 @@
 // DEFAULT_TRIPLE_NO_NOTREAL: env/gcc"
 // DEFAULT_TRIPLE_NO_NOTREAL-NOT: -gcc"
 
-/// default triple only chosen when no others are present
+/// Pick "gcc" as a fallback. Don't pick $DEFAULT_TRIPLE-gcc.
 // RUN: rm %t/env/gcc
 // RUN: env "PATH=%t/env/" %t/clang -### -target notreal-none-elf %s 2>&1 | \
 // RUN:   FileCheck --check-prefix=DEFAULT_TRIPLE_NO_OTHERS %s
-// DEFAULT_TRIPLE_NO_OTHERS: -gcc"
-// DEFAULT_TRIPLE_NO_OTHERS-NOT: notreal-none-elf-gcc"
-// DEFAULT_TRIPLE_NO_OTHERS-NOT: /gcc"
+// DEFAULT_TRIPLE_NO_OTHERS: "gcc"
 
 /// -B paths are searched separately so default triple will win
 /// if put in one of those even if other paths have higher priority names
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -5070,11 +5070,6 @@
   // FIXME: Needs a better variable than TargetTriple
   Names.emplace_back((TargetTriple + "-" + Tool).str());
   Names.emplace_back(Tool);
-
-  // Allow the discovery of tools prefixed with LLVM's default target triple.
-  std::string DefaultTargetTriple = llvm::sys::getDefaultTargetTriple();
-  if (DefaultTargetTriple != TargetTriple)
-Names.emplace_back((DefaultTargetTriple + "-" + Tool).str());
 }
 
 static bool ScanDirForExecutable(SmallString<128> , StringRef Name) {


Index: clang/test/Driver/program-path-priority.c
===
--- clang/test/Driver/program-path-priority.c
+++ clang/test/Driver/program-path-priority.c
@@ -3,8 +3,7 @@
 
 /// Check the priority used when searching for tools
 /// Names and locations are usually in this order:
-/// -tool, tool, -tool
-/// program path, PATH
+/// -tool, tool, program path, PATH
 /// (from highest to lowest priority)
 /// A higher priority name found in a lower priority
 /// location will win over a lower priority name in a
@@ -102,13 +101,11 @@
 // DEFAULT_TRIPLE_NO_NOTREAL: env/gcc"
 // DEFAULT_TRIPLE_NO_NOTREAL-NOT: -gcc"
 
-/// default triple only chosen when no others are present
+/// Pick "gcc" as a fallback. Don't pick $DEFAULT_TRIPLE-gcc.
 // RUN: rm %t/env/gcc
 // RUN: env "PATH=%t/env/" %t/clang -### -target notreal-none-elf %s 2>&1 | \
 // RUN:   FileCheck --check-prefix=DEFAULT_TRIPLE_NO_OTHERS %s
-// DEFAULT_TRIPLE_NO_OTHERS: -gcc"
-// DEFAULT_TRIPLE_NO_OTHERS-NOT: notreal-none-elf-gcc"
-// DEFAULT_TRIPLE_NO_OTHERS-NOT: /gcc"
+// DEFAULT_TRIPLE_NO_OTHERS: "gcc"
 
 /// -B paths are searched separately so default triple will win
 /// if put in one of those even if other paths have higher priority names
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -5070,11 +5070,6 @@
   // FIXME: Needs a better variable than TargetTriple
   Names.emplace_back((TargetTriple + "-" + Tool).str());
   Names.emplace_back(Tool);
-
-  // Allow the discovery of tools prefixed with LLVM's default target triple.
-  std::string DefaultTargetTriple = llvm::sys::getDefaultTargetTriple();
-  if (DefaultTargetTriple != TargetTriple)
-Names.emplace_back((DefaultTargetTriple + "-" + Tool).str());
 }
 
 static bool ScanDirForExecutable(SmallString<128> , StringRef Name) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 8ac5e44 - [Driver] Drop $DEFAULT_TRIPLE-$name as a fallback program name

2021-04-07 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2021-04-07T21:01:10-07:00
New Revision: 8ac5e440615dd3dc9fd2eb88c0bad32fdc5f678c

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

LOG: [Driver] Drop $DEFAULT_TRIPLE-$name as a fallback program name

D13340 introduced this behavior which is not needed even for mips.
This was raised on https://lists.llvm.org/pipermail/cfe-dev/2020-May/065437.html
but no action was taken.

This was raised again in 
https://lists.llvm.org/pipermail/cfe-dev/2021-April/067974.html
"The LLVM host/target TRIPLE padding drama on Debian"
as it caused confusion. This patch drops the behavior.

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

Added: 


Modified: 
clang/lib/Driver/Driver.cpp
clang/test/Driver/program-path-priority.c

Removed: 




diff  --git a/clang/lib/Driver/Driver.cpp b/clang/lib/Driver/Driver.cpp
index 171d3d5b5b88..39a630a7b4e8 100644
--- a/clang/lib/Driver/Driver.cpp
+++ b/clang/lib/Driver/Driver.cpp
@@ -5070,11 +5070,6 @@ void Driver::generatePrefixedToolNames(
   // FIXME: Needs a better variable than TargetTriple
   Names.emplace_back((TargetTriple + "-" + Tool).str());
   Names.emplace_back(Tool);
-
-  // Allow the discovery of tools prefixed with LLVM's default target triple.
-  std::string DefaultTargetTriple = llvm::sys::getDefaultTargetTriple();
-  if (DefaultTargetTriple != TargetTriple)
-Names.emplace_back((DefaultTargetTriple + "-" + Tool).str());
 }
 
 static bool ScanDirForExecutable(SmallString<128> , StringRef Name) {

diff  --git a/clang/test/Driver/program-path-priority.c 
b/clang/test/Driver/program-path-priority.c
index cba5f9f4d743..ee931dd7a9a3 100644
--- a/clang/test/Driver/program-path-priority.c
+++ b/clang/test/Driver/program-path-priority.c
@@ -3,8 +3,7 @@
 
 /// Check the priority used when searching for tools
 /// Names and locations are usually in this order:
-/// -tool, tool, -tool
-/// program path, PATH
+/// -tool, tool, program path, PATH
 /// (from highest to lowest priority)
 /// A higher priority name found in a lower priority
 /// location will win over a lower priority name in a
@@ -102,13 +101,11 @@
 // DEFAULT_TRIPLE_NO_NOTREAL: env/gcc"
 // DEFAULT_TRIPLE_NO_NOTREAL-NOT: -gcc"
 
-/// default triple only chosen when no others are present
+/// Pick "gcc" as a fallback. Don't pick $DEFAULT_TRIPLE-gcc.
 // RUN: rm %t/env/gcc
 // RUN: env "PATH=%t/env/" %t/clang -### -target notreal-none-elf %s 2>&1 | \
 // RUN:   FileCheck --check-prefix=DEFAULT_TRIPLE_NO_OTHERS %s
-// DEFAULT_TRIPLE_NO_OTHERS: -gcc"
-// DEFAULT_TRIPLE_NO_OTHERS-NOT: notreal-none-elf-gcc"
-// DEFAULT_TRIPLE_NO_OTHERS-NOT: /gcc"
+// DEFAULT_TRIPLE_NO_OTHERS: "gcc"
 
 /// -B paths are searched separately so default triple will win
 /// if put in one of those even if other paths have higher priority names



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


[PATCH] D100085: [X86] Support -march=rocketlake

2021-04-07 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added inline comments.



Comment at: clang/test/Preprocessor/predefined-arch-macros.c:1396
 
+// RUN: %clang -march=rocketlake -m32 -E -dM %s -o - 2>&1 \
+// RUN: -target i386-unknown-linux \

The file may need some refactoring first. You can let RUN lines share some 
common check prefixes, instead of adding a bunch of defines for every new 
processor.

```
// CHECK_X86_64_V2: ...
// CHECK_X86_64_V2: ...
// CHECK_X86_64_V3: ...
// CHECK_PROCESSOR1_M32:
// CHECK_PROCESSOR1_M64:
// CHECK_PROCESSOR2_M32:
// CHECK_PROCESSOR2_M64:
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100085

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


[PATCH] D100085: [X86] Support -march=rocketlake

2021-04-07 Thread Freddy, Ye via Phabricator via cfe-commits
FreddyYe created this revision.
Herald added subscribers: dexonsmith, pengfei, hiraditya.
FreddyYe requested review of this revision.
Herald added projects: clang, Sanitizers, LLVM.
Herald added subscribers: llvm-commits, Sanitizers, cfe-commits.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100085

Files:
  clang/lib/Basic/Targets/X86.cpp
  clang/test/CodeGen/attr-target-mv.c
  clang/test/CodeGen/target-builtin-noerror.c
  clang/test/Driver/x86-march.c
  clang/test/Misc/target-invalid-cpu-note.c
  clang/test/Preprocessor/predefined-arch-macros.c
  compiler-rt/lib/builtins/cpu_model.c
  llvm/include/llvm/Support/X86TargetParser.def
  llvm/include/llvm/Support/X86TargetParser.h
  llvm/lib/Support/Host.cpp
  llvm/lib/Support/X86TargetParser.cpp
  llvm/lib/Target/X86/X86.td
  llvm/test/CodeGen/X86/cpus-intel.ll

Index: llvm/test/CodeGen/X86/cpus-intel.ll
===
--- llvm/test/CodeGen/X86/cpus-intel.ll
+++ llvm/test/CodeGen/X86/cpus-intel.ll
@@ -38,6 +38,7 @@
 ; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=cooperlake 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
 ; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=cannonlake 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
 ; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=icelake-client 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
+; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=rocketlake 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
 ; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=icelake-server 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
 ; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=tigerlake 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
 ; RUN: llc < %s -o /dev/null -mtriple=x86_64-unknown-unknown -mcpu=sapphirerapids 2>&1 | FileCheck %s --check-prefix=CHECK-NO-ERROR --allow-empty
Index: llvm/lib/Target/X86/X86.td
===
--- llvm/lib/Target/X86/X86.td
+++ llvm/lib/Target/X86/X86.td
@@ -754,7 +754,7 @@
   list ICXFeatures =
 !listconcat(ICLFeatures, ICXAdditionalFeatures);
 
-  //Tigerlake
+  // Tigerlake
   list TGLAdditionalFeatures = [FeatureVP2INTERSECT,
   FeatureMOVDIRI,
   FeatureMOVDIR64B,
@@ -763,7 +763,35 @@
   list TGLFeatures =
 !listconcat(ICLFeatures, TGLAdditionalFeatures );
 
-  //Sapphirerapids
+  // Rocketlake
+  list RKLAdditionalFeatures = [FeatureAES,
+  FeatureXSAVEC,
+  FeatureXSAVES,
+  FeatureCLFLUSHOPT,
+  FeatureAVX512,
+  FeatureCDI,
+  FeatureDQI,
+  FeatureBWI,
+  FeatureVLX,
+  FeaturePKU,
+  FeatureVBMI,
+  FeatureIFMA,
+  FeatureSHA,
+  FeatureBITALG,
+  FeatureVAES,
+  FeatureVBMI2,
+  FeatureVNNI,
+  FeatureVPCLMULQDQ,
+  FeatureVPOPCNTDQ,
+  FeatureGFNI,
+  FeatureCLWB,
+  FeatureRDPID,
+  FeatureFSRM];
+  list RKLTuning = ICLTuning;
+  list RKLFeatures =
+!listconcat(BDWFeatures, RKLAdditionalFeatures);
+
+  // Sapphirerapids
   list SPRAdditionalFeatures = [FeatureAMXTILE,
   FeatureAMXINT8,
   FeatureAMXBF16,
@@ -1307,6 +1335,8 @@
 ProcessorFeatures.CNLFeatures, ProcessorFeatures.CNLTuning>;
 def : ProcModel<"icelake-client", SkylakeServerModel,
 ProcessorFeatures.ICLFeatures, ProcessorFeatures.ICLTuning>;
+def : ProcModel<"rocketlake", SkylakeServerModel,
+ProcessorFeatures.RKLFeatures, ProcessorFeatures.RKLTuning>;
 def : ProcModel<"icelake-server", SkylakeServerModel,
 ProcessorFeatures.ICXFeatures, ProcessorFeatures.ICXTuning>;
 def : ProcModel<"tigerlake", 

[PATCH] D99708: [X86] Enable compilation of user interrupt handlers.

2021-04-07 Thread Wang Tianqing via Phabricator via cfe-commits
tianqing updated this revision to Diff 335980.

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

https://reviews.llvm.org/D99708

Files:
  clang/lib/Headers/uintrintrin.h
  llvm/lib/Target/X86/X86ExpandPseudo.cpp
  llvm/test/CodeGen/X86/x86-64-intrcc-uintr.ll

Index: llvm/test/CodeGen/X86/x86-64-intrcc-uintr.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/x86-64-intrcc-uintr.ll
@@ -0,0 +1,171 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py UTC_ARGS: --no_x86_scrub_sp --no_x86_scrub_rip
+; RUN: llc < %s | FileCheck %s -check-prefixes=CHECK-USER
+; RUN: llc -O0 < %s | FileCheck %s -check-prefixes=CHECK0-USER
+; RUN: llc -code-model=kernel < %s | FileCheck %s -check-prefixes=CHECK-KERNEL
+; RUN: llc -O0 -code-model=kernel < %s | FileCheck %s -check-prefixes=CHECK0-KERNEL
+
+target datalayout = "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
+target triple = "x86_64-unknown-linux-gnu"
+
+%struct.__uintr_frame = type { i64, i64, i64 }
+
+; #include 
+;
+; void
+; __attribute__ ((interrupt))
+; test_uintr_isr_cc_empty(struct __uintr_frame *frame, unsigned long long uirrv)
+; {
+; }
+
+define dso_local x86_intrcc void @test_uintr_isr_cc_empty(%struct.__uintr_frame* nocapture byval(%struct.__uintr_frame) %frame, i64 %uirrv) #0 {
+; CHECK-USER-LABEL: test_uintr_isr_cc_empty:
+; CHECK-USER:   # %bb.0: # %entry
+; CHECK-USER-NEXT:pushq %rax
+; CHECK-USER-NEXT:cld
+; CHECK-USER-NEXT:addq $16, %rsp
+; CHECK-USER-NEXT:uiret
+;
+; CHECK0-USER-LABEL: test_uintr_isr_cc_empty:
+; CHECK0-USER:   # %bb.0: # %entry
+; CHECK0-USER-NEXT:pushq %rax
+; CHECK0-USER-NEXT:cld
+; CHECK0-USER-NEXT:addq $16, %rsp
+; CHECK0-USER-NEXT:uiret
+;
+; CHECK-KERNEL-LABEL: test_uintr_isr_cc_empty:
+; CHECK-KERNEL:   # %bb.0: # %entry
+; CHECK-KERNEL-NEXT:pushq %rax
+; CHECK-KERNEL-NEXT:cld
+; CHECK-KERNEL-NEXT:addq $16, %rsp
+; CHECK-KERNEL-NEXT:iretq
+;
+; CHECK0-KERNEL-LABEL: test_uintr_isr_cc_empty:
+; CHECK0-KERNEL:   # %bb.0: # %entry
+; CHECK0-KERNEL-NEXT:pushq %rax
+; CHECK0-KERNEL-NEXT:cld
+; CHECK0-KERNEL-NEXT:addq $16, %rsp
+; CHECK0-KERNEL-NEXT:iretq
+entry:
+  ret void
+}
+
+; unsigned long long g_rip;
+; unsigned long long g_rflags;
+; unsigned long long g_rsp;
+; unsigned long long g_uirrv;
+;
+; void
+; __attribute__((interrupt))
+; test_uintr_isr_cc_args(struct __uintr_frame *frame, unsigned long long uirrv)
+; {
+;   g_rip = frame->rip;
+;   g_rflags = frame->rflags;
+;   g_rsp = frame->rsp;
+;   g_uirrv = uirrv;
+; }
+@g_rip = dso_local local_unnamed_addr global i64 0, align 8
+@g_rflags = dso_local local_unnamed_addr global i64 0, align 8
+@g_rsp = dso_local local_unnamed_addr global i64 0, align 8
+@g_uirrv = dso_local local_unnamed_addr global i64 0, align 8
+
+define dso_local x86_intrcc void @test_uintr_isr_cc_args(%struct.__uintr_frame* nocapture readonly byval(%struct.__uintr_frame) %frame, i64 %uirrv) #0 {
+; CHECK-USER-LABEL: test_uintr_isr_cc_args:
+; CHECK-USER:   # %bb.0: # %entry
+; CHECK-USER-NEXT:pushq %rax
+; CHECK-USER-NEXT:pushq %rax
+; CHECK-USER-NEXT:pushq %rdx
+; CHECK-USER-NEXT:pushq %rcx
+; CHECK-USER-NEXT:cld
+; CHECK-USER-NEXT:movq 32(%rsp), %rax
+; CHECK-USER-NEXT:movq 40(%rsp), %rcx
+; CHECK-USER-NEXT:movq 48(%rsp), %rdx
+; CHECK-USER-NEXT:movq %rcx, g_rip(%rip)
+; CHECK-USER-NEXT:movq %rdx, g_rflags(%rip)
+; CHECK-USER-NEXT:movq 56(%rsp), %rcx
+; CHECK-USER-NEXT:movq %rcx, g_rsp(%rip)
+; CHECK-USER-NEXT:movq %rax, g_uirrv(%rip)
+; CHECK-USER-NEXT:popq %rcx
+; CHECK-USER-NEXT:popq %rdx
+; CHECK-USER-NEXT:popq %rax
+; CHECK-USER-NEXT:addq $16, %rsp
+; CHECK-USER-NEXT:uiret
+;
+; CHECK0-USER-LABEL: test_uintr_isr_cc_args:
+; CHECK0-USER:   # %bb.0: # %entry
+; CHECK0-USER-NEXT:pushq %rax
+; CHECK0-USER-NEXT:pushq %rax
+; CHECK0-USER-NEXT:pushq %rdx
+; CHECK0-USER-NEXT:pushq %rcx
+; CHECK0-USER-NEXT:cld
+; CHECK0-USER-NEXT:movq 32(%rsp), %rax
+; CHECK0-USER-NEXT:leaq 40(%rsp), %rcx
+; CHECK0-USER-NEXT:movq (%rcx), %rdx
+; CHECK0-USER-NEXT:movq %rdx, g_rip(%rip)
+; CHECK0-USER-NEXT:movq 8(%rcx), %rdx
+; CHECK0-USER-NEXT:movq %rdx, g_rflags(%rip)
+; CHECK0-USER-NEXT:movq 16(%rcx), %rcx
+; CHECK0-USER-NEXT:movq %rcx, g_rsp(%rip)
+; CHECK0-USER-NEXT:movq %rax, g_uirrv(%rip)
+; CHECK0-USER-NEXT:popq %rcx
+; CHECK0-USER-NEXT:popq %rdx
+; CHECK0-USER-NEXT:popq %rax
+; CHECK0-USER-NEXT:addq $16, %rsp
+; CHECK0-USER-NEXT:uiret
+;
+; CHECK-KERNEL-LABEL: test_uintr_isr_cc_args:
+; CHECK-KERNEL:   # %bb.0: # %entry
+; CHECK-KERNEL-NEXT:pushq %rax
+; CHECK-KERNEL-NEXT:pushq %rax
+; CHECK-KERNEL-NEXT:pushq %rdx
+; CHECK-KERNEL-NEXT:pushq %rcx
+; CHECK-KERNEL-NEXT:cld
+; CHECK-KERNEL-NEXT:movq 32(%rsp), %rax
+; 

[PATCH] D100074: [RISCV] Use multiclass inheritance to simplify some of riscv_vector.td. NFCI

2021-04-07 Thread Craig Topper via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG5f6b3d1833fd: [RISCV] Use multiclass inheritance to simplify 
some of riscv_vector.td. NFCI (authored by craig.topper).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100074

Files:
  clang/include/clang/Basic/riscv_vector.td

Index: clang/include/clang/Basic/riscv_vector.td
===
--- clang/include/clang/Basic/riscv_vector.td
+++ clang/include/clang/Basic/riscv_vector.td
@@ -217,127 +217,109 @@
 
 // IntrinsicTypes is output, op0, op1 [-1, 0, 1]
 multiclass RVVOutOp0Op1BuiltinSet> suffixes_prototypes> {
-  defm NAME : RVVBuiltinSet> suffixes_prototypes>
+: RVVBuiltinSet;
-}
 
 // IntrinsicTypes is output, op1 [-1, 1]
 multiclass RVVOutOp1BuiltinSet> suffixes_prototypes> {
-  defm "" : RVVBuiltinSet;
-}
+   list> suffixes_prototypes>
+: RVVBuiltinSet;
 
 multiclass RVVOp0Op1BuiltinSet> suffixes_prototypes> {
-  defm "" : RVVBuiltinSet;
-}
+   list> suffixes_prototypes>
+: RVVBuiltinSet;
 
 multiclass RVVOutOp1Op2BuiltinSet> suffixes_prototypes> {
-  defm "" : RVVBuiltinSet;
-}
+  list> suffixes_prototypes>
+: RVVBuiltinSet;
 
-multiclass RVVSignedBinBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
-}
+multiclass RVVSignedBinBuiltinSet
+: RVVOutOp1BuiltinSet;
 
-multiclass RVVUnsignedBinBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
-}
+multiclass RVVUnsignedBinBuiltinSet
+: RVVOutOp1BuiltinSet;
 
-multiclass RVVIntBinBuiltinSet {
-  defm "" : RVVSignedBinBuiltinSet;
-  defm "" : RVVUnsignedBinBuiltinSet;
-}
+multiclass RVVIntBinBuiltinSet
+: RVVSignedBinBuiltinSet,
+  RVVUnsignedBinBuiltinSet;
 
-multiclass RVVSignedShiftBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
-}
+multiclass RVVSignedShiftBuiltinSet
+: RVVOutOp1BuiltinSet;
 
-multiclass RVVUnsignedShiftBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
-}
+multiclass RVVUnsignedShiftBuiltinSet
+: RVVOutOp1BuiltinSet;
 
-multiclass RVVShiftBuiltinSet {
-  defm "" : RVVSignedShiftBuiltinSet;
-  defm "" : RVVUnsignedShiftBuiltinSet;
-}
+multiclass RVVShiftBuiltinSet
+: RVVSignedShiftBuiltinSet,
+  RVVUnsignedShiftBuiltinSet;
 
 let Log2LMUL = [-3, -2, -1, 0, 1, 2] in {
-  multiclass RVVSignedNShiftBuiltinSet {
-defm "" : RVVOutOp0Op1BuiltinSet;
-  }
-  multiclass RVVUnsignedNShiftBuiltinSet {
-defm "" : RVVOutOp0Op1BuiltinSet;
-  }
-}
-
-multiclass RVVIntTerBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
 }
 
-multiclass RVVCarryinBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
-}
-
-multiclass RVVCarryOutInBuiltinSet {
-  defm "" : RVVOp0Op1BuiltinSet;
-}
-
-multiclass RVVSignedMaskOutBuiltinSet {
-  defm "" : RVVOp0Op1BuiltinSet;
-}
-
-multiclass RVVUnsignedMaskOutBuiltinSet {
-  defm "" : RVVOp0Op1BuiltinSet;
-}
-
-multiclass RVVIntMaskOutBuiltinSet {
-  defm "" : RVVSignedMaskOutBuiltinSet;
-  defm "" : RVVUnsignedMaskOutBuiltinSet;
-}
-
-multiclass RVVFloatingBinBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
-}
-
-multiclass RVVIntExt {
-  let IRName = intrinsic_name, IRNameMask = intrinsic_name # "_mask",
-  MangledName = NAME, IntrinsicTypes = [-1, 0] in {
-def "" : RVVBuiltin;
-  }
+multiclass RVVIntTerBuiltinSet
+: RVVOutOp1BuiltinSet;
+
+multiclass RVVCarryinBuiltinSet
+: RVVOutOp1BuiltinSet;
+
+multiclass RVVCarryOutInBuiltinSet
+: RVVOp0Op1BuiltinSet;
+
+multiclass RVVSignedMaskOutBuiltinSet
+: RVVOp0Op1BuiltinSet;
+
+multiclass RVVUnsignedMaskOutBuiltinSet
+: RVVOp0Op1BuiltinSet;
+
+multiclass RVVIntMaskOutBuiltinSet
+: RVVSignedMaskOutBuiltinSet,
+  RVVUnsignedMaskOutBuiltinSet;
+
+multiclass RVVFloatingBinBuiltinSet
+: RVVOutOp1BuiltinSet;
+
+class RVVIntExt
+: RVVBuiltin {
+  let IRName = intrinsic_name;
+  let IRNameMask = intrinsic_name # "_mask";
+  let MangledName = NAME;
+  let IntrinsicTypes = [-1, 0];
 }
 
 defvar TypeList = ["c","s","i","l","f","d"];
@@ -520,16 +502,16 @@
 
 // 12.3. Vector Integer Extension
 let Log2LMUL = [-3, -2, -1, 0, 1, 2] in {
-defm vsext_vf2 : RVVIntExt<"vsext", "w", "wv", "csi">;
-defm vzext_vf2 : RVVIntExt<"vzext", "Uw", "UwUv", "csi">;
+  def vsext_vf2 : RVVIntExt<"vsext", "w", "wv", "csi">;
+  def vzext_vf2 : RVVIntExt<"vzext", "Uw", "UwUv", "csi">;
 }
 let Log2LMUL = [-3, -2, -1, 0, 1] in {
-defm vsext_vf4 : RVVIntExt<"vsext", "q", "qv", "cs">;
-defm vzext_vf4 : RVVIntExt<"vzext", "Uq", "UqUv", "cs">;
+  def vsext_vf4 : RVVIntExt<"vsext", "q", "qv", "cs">;
+  def vzext_vf4 : RVVIntExt<"vzext", "Uq", "UqUv", "cs">;
 }
 let Log2LMUL = [-3, -2, -1, 0] in {
-defm vsext_vf8 : RVVIntExt<"vsext", "o", "ov", "c">;
-defm vzext_vf8 : RVVIntExt<"vzext", "Uo", "UoUv", "c">;
+  def vsext_vf8 : RVVIntExt<"vsext", "o", "ov", "c">;
+  def vzext_vf8 : RVVIntExt<"vzext", "Uo", 

[clang] 5f6b3d1 - [RISCV] Use multiclass inheritance to simplify some of riscv_vector.td. NFCI

2021-04-07 Thread Craig Topper via cfe-commits

Author: Craig Topper
Date: 2021-04-07T17:33:21-07:00
New Revision: 5f6b3d1833fdf20e18a3c8bf3ede7b5060130f73

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

LOG: [RISCV] Use multiclass inheritance to simplify some of riscv_vector.td. 
NFCI

We don't need to instantiate single multiclasses inside of
other multiclasses. We can use inheritance and save writing 'defm ""'.

Reviewed By: khchen

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

Added: 


Modified: 
clang/include/clang/Basic/riscv_vector.td

Removed: 




diff  --git a/clang/include/clang/Basic/riscv_vector.td 
b/clang/include/clang/Basic/riscv_vector.td
index 98beebf25da8c..9b8a0d87de5cc 100644
--- a/clang/include/clang/Basic/riscv_vector.td
+++ b/clang/include/clang/Basic/riscv_vector.td
@@ -217,127 +217,109 @@ multiclass RVVBuiltinSet> suffixes_prototypes> {
-  defm NAME : RVVBuiltinSet> suffixes_prototypes>
+: RVVBuiltinSet;
-}
 
 // IntrinsicTypes is output, op1 [-1, 1]
 multiclass RVVOutOp1BuiltinSet> suffixes_prototypes> {
-  defm "" : RVVBuiltinSet;
-}
+   list> suffixes_prototypes>
+: RVVBuiltinSet;
 
 multiclass RVVOp0Op1BuiltinSet> suffixes_prototypes> {
-  defm "" : RVVBuiltinSet;
-}
+   list> suffixes_prototypes>
+: RVVBuiltinSet;
 
 multiclass RVVOutOp1Op2BuiltinSet> suffixes_prototypes> {
-  defm "" : RVVBuiltinSet;
-}
+  list> suffixes_prototypes>
+: RVVBuiltinSet;
 
-multiclass RVVSignedBinBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
-}
+multiclass RVVSignedBinBuiltinSet
+: RVVOutOp1BuiltinSet;
 
-multiclass RVVUnsignedBinBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
-}
+multiclass RVVUnsignedBinBuiltinSet
+: RVVOutOp1BuiltinSet;
 
-multiclass RVVIntBinBuiltinSet {
-  defm "" : RVVSignedBinBuiltinSet;
-  defm "" : RVVUnsignedBinBuiltinSet;
-}
+multiclass RVVIntBinBuiltinSet
+: RVVSignedBinBuiltinSet,
+  RVVUnsignedBinBuiltinSet;
 
-multiclass RVVSignedShiftBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
-}
+multiclass RVVSignedShiftBuiltinSet
+: RVVOutOp1BuiltinSet;
 
-multiclass RVVUnsignedShiftBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
-}
+multiclass RVVUnsignedShiftBuiltinSet
+: RVVOutOp1BuiltinSet;
 
-multiclass RVVShiftBuiltinSet {
-  defm "" : RVVSignedShiftBuiltinSet;
-  defm "" : RVVUnsignedShiftBuiltinSet;
-}
+multiclass RVVShiftBuiltinSet
+: RVVSignedShiftBuiltinSet,
+  RVVUnsignedShiftBuiltinSet;
 
 let Log2LMUL = [-3, -2, -1, 0, 1, 2] in {
-  multiclass RVVSignedNShiftBuiltinSet {
-defm "" : RVVOutOp0Op1BuiltinSet;
-  }
-  multiclass RVVUnsignedNShiftBuiltinSet {
-defm "" : RVVOutOp0Op1BuiltinSet;
-  }
-}
-
-multiclass RVVIntTerBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
 }
 
-multiclass RVVCarryinBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
-}
-
-multiclass RVVCarryOutInBuiltinSet {
-  defm "" : RVVOp0Op1BuiltinSet;
-}
-
-multiclass RVVSignedMaskOutBuiltinSet {
-  defm "" : RVVOp0Op1BuiltinSet;
-}
-
-multiclass RVVUnsignedMaskOutBuiltinSet {
-  defm "" : RVVOp0Op1BuiltinSet;
-}
-
-multiclass RVVIntMaskOutBuiltinSet {
-  defm "" : RVVSignedMaskOutBuiltinSet;
-  defm "" : RVVUnsignedMaskOutBuiltinSet;
-}
-
-multiclass RVVFloatingBinBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
-}
-
-multiclass RVVIntExt {
-  let IRName = intrinsic_name, IRNameMask = intrinsic_name # "_mask",
-  MangledName = NAME, IntrinsicTypes = [-1, 0] in {
-def "" : RVVBuiltin;
-  }
+multiclass RVVIntTerBuiltinSet
+: RVVOutOp1BuiltinSet;
+
+multiclass RVVCarryinBuiltinSet
+: RVVOutOp1BuiltinSet;
+
+multiclass RVVCarryOutInBuiltinSet
+: RVVOp0Op1BuiltinSet;
+
+multiclass RVVSignedMaskOutBuiltinSet
+: RVVOp0Op1BuiltinSet;
+
+multiclass RVVUnsignedMaskOutBuiltinSet
+: RVVOp0Op1BuiltinSet;
+
+multiclass RVVIntMaskOutBuiltinSet
+: RVVSignedMaskOutBuiltinSet,
+  RVVUnsignedMaskOutBuiltinSet;
+
+multiclass RVVFloatingBinBuiltinSet
+: RVVOutOp1BuiltinSet;
+
+class RVVIntExt
+: RVVBuiltin {
+  let IRName = intrinsic_name;
+  let IRNameMask = intrinsic_name # "_mask";
+  let MangledName = NAME;
+  let IntrinsicTypes = [-1, 0];
 }
 
 defvar TypeList = ["c","s","i","l","f","d"];
@@ -520,16 +502,16 @@ defm vrsub : RVVOutOp1BuiltinSet<"vrsub", "csil",
 
 // 12.3. Vector Integer Extension
 let Log2LMUL = [-3, -2, -1, 0, 1, 2] in {
-defm vsext_vf2 : RVVIntExt<"vsext", "w", "wv", "csi">;
-defm vzext_vf2 : RVVIntExt<"vzext", "Uw", "UwUv", "csi">;
+  def vsext_vf2 : RVVIntExt<"vsext", "w", "wv", "csi">;
+  def vzext_vf2 : RVVIntExt<"vzext", "Uw", "UwUv", "csi">;
 }
 let Log2LMUL = [-3, -2, -1, 0, 1] in {
-defm vsext_vf4 : RVVIntExt<"vsext", "q", "qv", "cs">;
-defm vzext_vf4 : RVVIntExt<"vzext", "Uq", "UqUv", "cs">;
+  

[PATCH] D100074: [RISCV] Use multiclass inheritance to simplify some of riscv_vector.td. NFCI

2021-04-07 Thread Zakk Chen via Phabricator via cfe-commits
khchen accepted this revision.
khchen added a comment.
This revision is now accepted and ready to land.

LGTM, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100074

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


[PATCH] D94640: adds more checks to -Wfree-nonheap-object

2021-04-07 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

Sorry for the late review.




Comment at: clang/lib/Sema/SemaChecking.cpp:10294-10303
+void CheckFreeArgumentsPlus(Sema , const std::string ,
+const UnaryOperator *UnaryExpr) {
+  const auto *Lambda = dyn_cast(
+  UnaryExpr->getSubExpr()->IgnoreImplicitAsWritten()->IgnoreParens());
+  if (!Lambda)
 return;
 

This special case is rather too special, and I don't think it's worth the lines 
of code we're spending on it.

There's a fair amount of work being done here to figure out what's being passed 
to `free`, and some of it, like this, seems pretty hard to justify in 
isolation. I wonder if we can reuse some of our existing mechanisms -- for 
example, can we run the constant evaluator on the operand to `free` instead, 
and see if it evaluates to a known non-heap object?



Comment at: clang/lib/Sema/SemaChecking.cpp:10326-10328
+OS << '\'';
+Cast->printPretty(OS, nullptr, S.getPrintingPolicy());
+OS << '\'';

Please don't pretty-print source expressions and include them in the diagnostic 
text. Instead, include a source range to highlight them in the caret 
diagnostic. See 
https://clang.llvm.org/docs/InternalsManual.html#the-format-string for our 
diagnostic best practices.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94640

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


[PATCH] D91466: [WIP][clang][Fuchsia] Support HWASan for Fuchsia

2021-04-07 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan updated this revision to Diff 335951.
leonardchan added a comment.

Rebase against submitted changes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D91466

Files:
  clang/cmake/caches/Fuchsia-stage2.cmake
  compiler-rt/cmake/config-ix.cmake
  compiler-rt/lib/hwasan/CMakeLists.txt
  compiler-rt/lib/hwasan/hwasan_dynamic_shadow.cpp
  compiler-rt/lib/hwasan/hwasan_fuchsia.cpp
  compiler-rt/lib/hwasan/hwasan_interceptors.cpp
  compiler-rt/lib/hwasan/hwasan_interface_internal.h
  compiler-rt/lib/hwasan/hwasan_new_delete.cpp
  compiler-rt/lib/hwasan/hwasan_poisoning.cpp
  compiler-rt/lib/hwasan/hwasan_thread.cpp
  compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_fuchsia.h
  compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_markup.cpp

Index: compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_markup.cpp
===
--- compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_markup.cpp
+++ compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_markup.cpp
@@ -54,6 +54,11 @@
   return false;
 }
 
+// TODO: We should also have an offline implementation. This function was
+// initially undefined when building hwasan. It's probably just because no one
+// used this until now that we didn't see this before.
+bool Symbolizer::SymbolizeFrame(uptr addr, FrameInfo *info) { return false; }
+
 // This is used in some places for suppression checking, which we
 // don't really support for Fuchsia.  It's also used in UBSan to
 // identify a PC location to a function name, so we always fill in
Index: compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_fuchsia.h
===
--- /dev/null
+++ compiler-rt/lib/sanitizer_common/sanitizer_platform_limits_fuchsia.h
@@ -0,0 +1,25 @@
+//===-- sanitizer_platform_limits_fuchsia.h ---===//
+//
+// 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
+//
+//===--===//
+//
+// This file is a part of Sanitizer common code.
+//
+// Sizes and layouts of platform-specific Fuchsia data structures.
+//===--===//
+
+#ifndef SANITIZER_PLATFORM_LIMITS_FUCHSIA_H
+#define SANITIZER_PLATFORM_LIMITS_FUCHSIA_H
+
+#if SANITIZER_FUCHSIA
+
+namespace __sanitizer {
+struct __sanitizer_struct_mallinfo {};
+}  // namespace __sanitizer
+
+#endif  // SANITIZER_FUCHSIA
+
+#endif
Index: compiler-rt/lib/hwasan/hwasan_thread.cpp
===
--- compiler-rt/lib/hwasan/hwasan_thread.cpp
+++ compiler-rt/lib/hwasan/hwasan_thread.cpp
@@ -51,12 +51,18 @@
   // ScopedTaggingDisable needs GetCurrentThread to be set up.
   ScopedTaggingDisabler disabler;
 
+#if !SANITIZER_FUCHSIA
   uptr tls_size;
   uptr stack_size;
   GetThreadStackAndTls(IsMainThread(), _bottom_, _size, _begin_,
_size);
   stack_top_ = stack_bottom_ + stack_size;
   tls_end_ = tls_begin_ + tls_size;
+#else
+  __sanitizer::GetThreadStackTopAndBottom(true, _top_,
+  _bottom_);
+  tls_end_ = tls_begin_ = 0;
+#endif
 
   if (stack_bottom_) {
 int local;
Index: compiler-rt/lib/hwasan/hwasan_poisoning.cpp
===
--- compiler-rt/lib/hwasan/hwasan_poisoning.cpp
+++ compiler-rt/lib/hwasan/hwasan_poisoning.cpp
@@ -22,6 +22,10 @@
 uptr TagMemoryAligned(uptr p, uptr size, tag_t tag) {
   CHECK(IsAligned(p, kShadowAlignment));
   CHECK(IsAligned(size, kShadowAlignment));
+#if SANITIZER_FUCHSIA
+  __sanitizer_fill_shadow(p, size, tag,
+  common_flags()->clear_shadow_mmap_threshold);
+#else
   uptr shadow_start = MemToShadow(p);
   uptr shadow_size = MemToShadowSize(size);
 
@@ -40,6 +44,7 @@
   } else {
 internal_memset((void *)shadow_start, tag, shadow_size);
   }
+#endif
   return AddTagToPointer(p, tag);
 }
 
Index: compiler-rt/lib/hwasan/hwasan_new_delete.cpp
===
--- compiler-rt/lib/hwasan/hwasan_new_delete.cpp
+++ compiler-rt/lib/hwasan/hwasan_new_delete.cpp
@@ -50,6 +50,7 @@
 // Fake std::nothrow_t to avoid including .
 namespace std {
   struct nothrow_t {};
+  enum class align_val_t: size_t {};
 }  // namespace std
 
 
@@ -66,6 +67,14 @@
 void *operator new[](size_t size, std::nothrow_t const&) {
   OPERATOR_NEW_BODY(true /*nothrow*/);
 }
+INTERCEPTOR_ATTRIBUTE SANITIZER_WEAK_ATTRIBUTE
+void *operator new(size_t size, std::align_val_t align) { OPERATOR_NEW_BODY(false /*nothrow*/); }
+INTERCEPTOR_ATTRIBUTE SANITIZER_WEAK_ATTRIBUTE
+void *operator new[](size_t 

[PATCH] D100074: [RISCV] Use multiclass inheritance to simplify some of riscv_vector.td. NFCI

2021-04-07 Thread Craig Topper via Phabricator via cfe-commits
craig.topper created this revision.
craig.topper added reviewers: khchen, HsiangKai, evandro, arcbbb.
Herald added subscribers: StephenFan, vkmr, frasercrmck, dexonsmith, 
luismarques, apazos, sameer.abuasal, s.egerton, Jim, benna, psnobl, jocewei, 
PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, zzheng, jrtc27, 
shiva0217, kito-cheng, niosHD, sabuasal, simoncook, johnrusso, rbar, asb.
craig.topper requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

We don't need to instantiate single multiclasses inside of
other multiclasses. We can use inheritance and save writing 'defm ""'.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100074

Files:
  clang/include/clang/Basic/riscv_vector.td

Index: clang/include/clang/Basic/riscv_vector.td
===
--- clang/include/clang/Basic/riscv_vector.td
+++ clang/include/clang/Basic/riscv_vector.td
@@ -217,127 +217,109 @@
 
 // IntrinsicTypes is output, op0, op1 [-1, 0, 1]
 multiclass RVVOutOp0Op1BuiltinSet> suffixes_prototypes> {
-  defm NAME : RVVBuiltinSet> suffixes_prototypes>
+: RVVBuiltinSet;
-}
 
 // IntrinsicTypes is output, op1 [-1, 1]
 multiclass RVVOutOp1BuiltinSet> suffixes_prototypes> {
-  defm "" : RVVBuiltinSet;
-}
+   list> suffixes_prototypes>
+: RVVBuiltinSet;
 
 multiclass RVVOp0Op1BuiltinSet> suffixes_prototypes> {
-  defm "" : RVVBuiltinSet;
-}
+   list> suffixes_prototypes>
+: RVVBuiltinSet;
 
 multiclass RVVOutOp1Op2BuiltinSet> suffixes_prototypes> {
-  defm "" : RVVBuiltinSet;
-}
+  list> suffixes_prototypes>
+: RVVBuiltinSet;
 
-multiclass RVVSignedBinBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
-}
+multiclass RVVSignedBinBuiltinSet
+: RVVOutOp1BuiltinSet;
 
-multiclass RVVUnsignedBinBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
-}
+multiclass RVVUnsignedBinBuiltinSet
+: RVVOutOp1BuiltinSet;
 
-multiclass RVVIntBinBuiltinSet {
-  defm "" : RVVSignedBinBuiltinSet;
-  defm "" : RVVUnsignedBinBuiltinSet;
-}
+multiclass RVVIntBinBuiltinSet
+: RVVSignedBinBuiltinSet,
+  RVVUnsignedBinBuiltinSet;
 
-multiclass RVVSignedShiftBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
-}
+multiclass RVVSignedShiftBuiltinSet
+: RVVOutOp1BuiltinSet;
 
-multiclass RVVUnsignedShiftBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
-}
+multiclass RVVUnsignedShiftBuiltinSet
+: RVVOutOp1BuiltinSet;
 
-multiclass RVVShiftBuiltinSet {
-  defm "" : RVVSignedShiftBuiltinSet;
-  defm "" : RVVUnsignedShiftBuiltinSet;
-}
+multiclass RVVShiftBuiltinSet
+: RVVSignedShiftBuiltinSet,
+  RVVUnsignedShiftBuiltinSet;
 
 let Log2LMUL = [-3, -2, -1, 0, 1, 2] in {
-  multiclass RVVSignedNShiftBuiltinSet {
-defm "" : RVVOutOp0Op1BuiltinSet;
-  }
-  multiclass RVVUnsignedNShiftBuiltinSet {
-defm "" : RVVOutOp0Op1BuiltinSet;
-  }
-}
-
-multiclass RVVIntTerBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
 }
 
-multiclass RVVCarryinBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
-}
-
-multiclass RVVCarryOutInBuiltinSet {
-  defm "" : RVVOp0Op1BuiltinSet;
-}
-
-multiclass RVVSignedMaskOutBuiltinSet {
-  defm "" : RVVOp0Op1BuiltinSet;
-}
-
-multiclass RVVUnsignedMaskOutBuiltinSet {
-  defm "" : RVVOp0Op1BuiltinSet;
-}
-
-multiclass RVVIntMaskOutBuiltinSet {
-  defm "" : RVVSignedMaskOutBuiltinSet;
-  defm "" : RVVUnsignedMaskOutBuiltinSet;
-}
-
-multiclass RVVFloatingBinBuiltinSet {
-  defm "" : RVVOutOp1BuiltinSet;
-}
-
-multiclass RVVIntExt {
-  let IRName = intrinsic_name, IRNameMask = intrinsic_name # "_mask",
-  MangledName = NAME, IntrinsicTypes = [-1, 0] in {
-def "" : RVVBuiltin;
-  }
+multiclass RVVIntTerBuiltinSet
+: RVVOutOp1BuiltinSet;
+
+multiclass RVVCarryinBuiltinSet
+: RVVOutOp1BuiltinSet;
+
+multiclass RVVCarryOutInBuiltinSet
+: RVVOp0Op1BuiltinSet;
+
+multiclass RVVSignedMaskOutBuiltinSet
+: RVVOp0Op1BuiltinSet;
+
+multiclass RVVUnsignedMaskOutBuiltinSet
+: RVVOp0Op1BuiltinSet;
+
+multiclass RVVIntMaskOutBuiltinSet
+: RVVSignedMaskOutBuiltinSet,
+  RVVUnsignedMaskOutBuiltinSet;
+
+multiclass RVVFloatingBinBuiltinSet
+: RVVOutOp1BuiltinSet;
+
+class RVVIntExt
+: RVVBuiltin {
+  let IRName = intrinsic_name;
+  let IRNameMask = intrinsic_name # "_mask";
+  let MangledName = NAME;
+  let IntrinsicTypes = [-1, 0];
 }
 
 defvar TypeList = ["c","s","i","l","f","d"];
@@ -520,16 +502,16 @@
 
 // 12.3. Vector Integer Extension
 let Log2LMUL = [-3, -2, -1, 0, 1, 2] in {
-defm vsext_vf2 : RVVIntExt<"vsext", "w", "wv", "csi">;
-defm vzext_vf2 : RVVIntExt<"vzext", "Uw", "UwUv", "csi">;
+  def vsext_vf2 : RVVIntExt<"vsext", "w", "wv", "csi">;
+  def vzext_vf2 : RVVIntExt<"vzext", "Uw", "UwUv", "csi">;
 }
 let Log2LMUL = [-3, -2, -1, 0, 1] in {
-defm vsext_vf4 : RVVIntExt<"vsext", "q", "qv", "cs">;
-defm vzext_vf4 : RVVIntExt<"vzext", "Uq", "UqUv", "cs">;

[PATCH] D99231: [AST] Add introspection support for more base nodes

2021-04-07 Thread Stephen Kelly via Phabricator via cfe-commits
steveire added a comment.

@njames93 ping?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99231

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


[PATCH] D99291: [AIX] Support init priority attribute

2021-04-07 Thread Jason Liu via Phabricator via cfe-commits
jasonliu accepted this revision.
jasonliu added a comment.
This revision is now accepted and ready to land.

LGTM.




Comment at: clang/lib/CodeGen/CGDeclCXX.cpp:663
 
+  // Create our global prioritized cleanup function.
+  if (!PrioritizedCXXStermFinalizers.empty()) {

Just noting that this trunk of code have very similar logic counter part in 
`EmitCXXGlobalInitFunc`. It seems there is no easy way to common them up given 
the current way of implementing it. It may require a non-trivial amount of 
refactoring for us to common up the similar logic between init and cleanup. 


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

https://reviews.llvm.org/D99291

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


[PATCH] D99037: [Matrix] Implement C-style explicit type conversions for matrix types

2021-04-07 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added inline comments.



Comment at: clang/lib/CodeGen/CGExprScalar.cpp:1219
+  } else {
+SrcElementTy = SrcTy;
+DstElementTy = DstTy;

We should be able to assert here that both types are not matrix types, I think?



Comment at: clang/lib/CodeGen/CGExprScalar.cpp:1377
 
+  if (SrcType->isMatrixType() && DstType->isMatrixType()) {
+return EmitScalarCast(Src, SrcType, DstType, SrcTy, DstTy, Opts);

nit: no braces required here



Comment at: clang/lib/CodeGen/CGExprScalar.cpp:1453
+  CGF.CGM.getIntrinsic(llvm::Intrinsic::convert_to_fp16,
+   CGF.CGM.FloatTy),
+  Res);

SaurabhJha wrote:
> Not sure why this was changed. Perhaps clang-clean.
Not sure, but please remove the change from the diff.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99037

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


[PATCH] D100054: Handle flags such as -m32 when computing the triple prefix for programs

2021-04-07 Thread Alexander Richardson via Phabricator via cfe-commits
arichardson planned changes to this revision.
arichardson added a comment.

In D100054#2675152 , @joerg wrote:

> This sounds wrong. If you are using 'x86_64-freebsd' as triple and -m32, it 
> should still call 'x86_64-freebsd-ld', but it is the responsibility of the 
> driver to ensure that also the right set of linker flags are passed as well. 
> Compare `netbsd::Linker::ConstructJob` for one way to handle this.

Good point. The real problem was that clang was passing the 64-bit asan runtime 
library to the linker, not so much that it tried to invoke the x86_64-prefixed 
linker. I'll see if I can limit this to the library paths.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100054

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


[PATCH] D100054: Handle flags such as -m32 when computing the triple prefix for programs

2021-04-07 Thread Joerg Sonnenberger via Phabricator via cfe-commits
joerg added a comment.

This sounds wrong. If you are using 'x86_64-freebsd' as triple and -m32, it 
should still call 'x86_64-freebsd-ld', but it is the responsibility of the 
driver to ensure that also the right set of linker flags are passed as well. 
Compare `netbsd::Linker::ConstructJob` for one way to handle this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100054

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


[PATCH] D100057: Remove warning "suggest braces" for aggregate initialization of an empty class with an aggregate base class.

2021-04-07 Thread Hana Dusíková via Phabricator via cfe-commits
hankadusikova marked 3 inline comments as done.
hankadusikova added a comment.

In D100057#2675085 , @jfb wrote:

> A few nits, but this is good otherwise!

Having an aggregate with multiple (empty) bases initialised with nonempty {} is 
a hard error, hence the 1.

https://compiler-explorer.com/z/hKqxWjo3G




Comment at: clang/lib/Sema/SemaInit.cpp:1018
+if (CXXRecordDecl *CXXRD = dyn_cast(ParentRD)) {
+  if (CXXRD->getNumBases() == 1) {
+return ParentRD->field_begin() == ParentRD->field_end();

jfb wrote:
> Multiple empty bases isn't a common thing, right? I don't think so, but would 
> rather check.
Having an aggregate with multiple (empty) bases initialised with {} is a hard 
error, hence the 1.

https://compiler-explorer.com/z/hKqxWjo3G


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

https://reviews.llvm.org/D100057

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


[PATCH] D100057: Remove warning "suggest braces" for aggregate initialization of an empty class with an aggregate base class.

2021-04-07 Thread Hana Dusíková via Phabricator via cfe-commits
hankadusikova updated this revision to Diff 335922.

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

https://reviews.llvm.org/D100057

Files:
  clang/lib/Sema/SemaInit.cpp
  clang/test/SemaCXX/aggregate-initialization.cpp


Index: clang/test/SemaCXX/aggregate-initialization.cpp
===
--- clang/test/SemaCXX/aggregate-initialization.cpp
+++ clang/test/SemaCXX/aggregate-initialization.cpp
@@ -172,11 +172,20 @@
   };
   ArrayAndBaseClass z = {1, 2, 3}; // expected-warning {{suggest 
braces}}
 
-  // It's not clear whether we should be warning in this case. If this
-  // pattern becomes idiomatic, it would be reasonable to suppress the
-  // warning here too.
+  // This pattern is used for tagged aggregates and must not warn
   template struct JustABaseClass : StdArray {};
-  JustABaseClass w = {1, 2, 3}; // expected-warning {{suggest braces}}
+  JustABaseClass w = {1, 2, 3};
+  // but this should be also ok
+  JustABaseClass v = {{1, 2, 3}};
+
+  template  struct OnionBaseClass : JustABaseClass {};
+  OnionBaseClass u = {1, 2, 3};
+  OnionBaseClass t = {{{1, 2, 3}}};
+
+  struct EmptyBase {};
+
+  template  struct AggregateAndEmpty : StdArray, 
EmptyBase {};
+  AggregateAndEmpty p = {1, 2, 3}; // expected-warning {{suggest 
braces}}
 #endif
 
 #pragma clang diagnostic pop
Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -1007,21 +1007,37 @@
   //
   // (where std::array is an aggregate struct containing a single array field.
 
-  // FIXME: Should aggregate initialization of a struct with a single
-  // base class and no members also suppress the warning?
-  if (Entity.getKind() != InitializedEntity::EK_Member || !Entity.getParent())
+  if (!Entity.getParent())
 return false;
 
-  auto *ParentRD =
-  Entity.getParent()->getType()->castAs()->getDecl();
-  if (CXXRecordDecl *CXXRD = dyn_cast(ParentRD))
-if (CXXRD->getNumBases())
-  return false;
+  // Allows elide brace initialization for aggregates with empty base.
+  if (Entity.getKind() == InitializedEntity::EK_Base) {
+auto *ParentRD =
+Entity.getParent()->getType()->castAs()->getDecl();
+if (CXXRecordDecl *CXXRD = dyn_cast(ParentRD)) {
+  if (CXXRD->getNumBases() == 1) {
+return ParentRD->field_begin() == ParentRD->field_end();
+  }
+}
+return false;
+  }
 
-  auto FieldIt = ParentRD->field_begin();
-  assert(FieldIt != ParentRD->field_end() &&
- "no fields but have initializer for member?");
-  return ++FieldIt == ParentRD->field_end();
+  // Allows elide brace initialization for aggregates with one member.
+  if (Entity.getKind() == InitializedEntity::EK_Member) {
+auto *ParentRD =
+Entity.getParent()->getType()->castAs()->getDecl();
+if (CXXRecordDecl *CXXRD = dyn_cast(ParentRD)) {
+  if (CXXRD->getNumBases()) {
+return false;
+  }
+}
+auto FieldIt = ParentRD->field_begin();
+assert(FieldIt != ParentRD->field_end() &&
+   "no fields but have initializer for member?");
+return ++FieldIt == ParentRD->field_end();
+  }
+
+  return false;
 }
 
 /// Check whether the range of the initializer \p ParentIList from element


Index: clang/test/SemaCXX/aggregate-initialization.cpp
===
--- clang/test/SemaCXX/aggregate-initialization.cpp
+++ clang/test/SemaCXX/aggregate-initialization.cpp
@@ -172,11 +172,20 @@
   };
   ArrayAndBaseClass z = {1, 2, 3}; // expected-warning {{suggest braces}}
 
-  // It's not clear whether we should be warning in this case. If this
-  // pattern becomes idiomatic, it would be reasonable to suppress the
-  // warning here too.
+  // This pattern is used for tagged aggregates and must not warn
   template struct JustABaseClass : StdArray {};
-  JustABaseClass w = {1, 2, 3}; // expected-warning {{suggest braces}}
+  JustABaseClass w = {1, 2, 3};
+  // but this should be also ok
+  JustABaseClass v = {{1, 2, 3}};
+
+  template  struct OnionBaseClass : JustABaseClass {};
+  OnionBaseClass u = {1, 2, 3};
+  OnionBaseClass t = {{{1, 2, 3}}};
+
+  struct EmptyBase {};
+
+  template  struct AggregateAndEmpty : StdArray, EmptyBase {};
+  AggregateAndEmpty p = {1, 2, 3}; // expected-warning {{suggest braces}}
 #endif
 
 #pragma clang diagnostic pop
Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -1007,21 +1007,37 @@
   //
   // (where std::array is an aggregate struct containing a single array field.
 
-  // FIXME: Should aggregate initialization of a struct with a single
-  // base class and no members also suppress the warning?
-  if (Entity.getKind() != InitializedEntity::EK_Member || !Entity.getParent())
+  if (!Entity.getParent())
 return 

[PATCH] D99965: [RISCV][Clang] Add more RVV load/store intrinsic functions.

2021-04-07 Thread Craig Topper via Phabricator via cfe-commits
craig.topper accepted this revision.
craig.topper added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99965

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


[PATCH] D100057: Remove warning "suggest braces" for aggregate initialization of an empty class with an aggregate base class.

2021-04-07 Thread JF Bastien via Phabricator via cfe-commits
jfb accepted this revision.
jfb added a comment.
This revision is now accepted and ready to land.

A few nits, but this is good otherwise!




Comment at: clang/lib/Sema/SemaInit.cpp:1013
 
-  auto *ParentRD =
-  Entity.getParent()->getType()->castAs()->getDecl();
-  if (CXXRecordDecl *CXXRD = dyn_cast(ParentRD))
-if (CXXRD->getNumBases())
-  return false;
+  // Allows elide brace initialization for aggregates with empty base
+  if (Entity.getKind() == InitializedEntity::EK_Base) {

"Allow eliding brace initialization".

Also, period at the end of the sentence.




Comment at: clang/lib/Sema/SemaInit.cpp:1018
+if (CXXRecordDecl *CXXRD = dyn_cast(ParentRD)) {
+  if (CXXRD->getNumBases() == 1) {
+return ParentRD->field_begin() == ParentRD->field_end();

Multiple empty bases isn't a common thing, right? I don't think so, but would 
rather check.



Comment at: clang/lib/Sema/SemaInit.cpp:1025
 
-  auto FieldIt = ParentRD->field_begin();
-  assert(FieldIt != ParentRD->field_end() &&
- "no fields but have initializer for member?");
-  return ++FieldIt == ParentRD->field_end();
+  // Allows elide brace initilization for aggregates with one member
+  if (Entity.getKind() == InitializedEntity::EK_Member) {

Same here.



Comment at: clang/test/SemaCXX/aggregate-initialization.cpp:183
+  OnionBaseClass u = {1, 2, 3};
+  OnionBaseClass t = {{{1, 2, 3}}};
+

Haha I like the name! 暈


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100057

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


[PATCH] D83660: [analyzer] Fix a crash for dereferencing an empty llvm::Optional variable in SMTConstraintManager.h.

2021-04-07 Thread Mikhail Ramalho via Phabricator via cfe-commits
mikhail.ramalho added a comment.

Indeed it looks like a copy & paste error, I'm surprised no one found it 
earlier.

Regarding the tests, we used to have `make check-clang-analysis-z3` (or 
something similar) that would run only the analyzer's tests, but using Z3 as 
the constraint solver. It looks like this change broke it: 
https://reviews.llvm.org/D62445


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

https://reviews.llvm.org/D83660

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


[PATCH] D100055: Fix missing generate capture expression for novariants's condition

2021-04-07 Thread Jennifer Yu via Phabricator via cfe-commits
jyu2 closed this revision.
jyu2 added a comment.

committed rGebf2dc33287e 
: Fix 
missing generate capture expression for novariants condition. (authored by 
jyu2).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100055

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


[PATCH] D97653: [clang-tidy] Fix RenamerClangTidy checks breaking lambda captures.

2021-04-07 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D97653#2593287 , @njames93 wrote:

> Where would be a good place for testing refersToDefaultCapture support?

Thank you for your patience while I thought about this a bit more, sorry for 
the delay in reviewing it!

I think it probably makes sense to add testing for it in `clang\test\AST` with 
an AST dumping test (so the text node dumper would probably need to be updated 
to mention that the `DeclRefExpr` is an implicit capture).




Comment at: clang/lib/Sema/SemaLambda.cpp:1619
+  if (Cap.isVariableCapture() && ImplicitCaptureLoc.isValid())
+cast(InitExpr)->setRefersToDefaultCapture(true);
   InitializedEntity Entity = InitializedEntity::InitializeLambdaCapture(

njames93 wrote:
> Correct me if I'm wrong, but there shouldn't be a case where the assert in 
> cast fails.
Hmmm, could it be an unresolved lookup expr in the case of a dependent capture? 
Or a `MemberExpr` in the case of capturing an anonymous structure or union 
member capture?

Because we're trying to determine if a `DeclRefExpr` was implicitly captured, 
would it be better to use "implicit capture" in the identifier rather than 
"default capture"?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97653

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


[PATCH] D99381: [compiler-rt][hwasan] Add Fuchsia-specific sanitizer platform limits

2021-04-07 Thread Leonard Chan via Phabricator via cfe-commits
leonardchan added a comment.

In D99381#2651896 , @mcgrathr wrote:

> I don't think this is warranted.  There should not be any references to such 
> things when building for Fuchsia.
> This looks like it's intended to satisfy one reference in dead code in 
> hwasan_interceptors.cpp.
> I think the right solution is just to refactor the hwasan code so that the 
> dead code is not compiled for Fuchsia at all.

To add more context, this patch was meant to resolve this missing type error:

  [27/32] Building CXX object 
compiler-rt/lib/hwasan/CMakeFiles/RTHwasan_dynamic.aarch64.dir/hwasan.cpp.obj
  FAILED: 
compiler-rt/lib/hwasan/CMakeFiles/RTHwasan_dynamic.aarch64.dir/hwasan.cpp.obj 
  
/usr/local/google/home/leonardchan/llvm-monorepo/llvm-build-4-master-fuchsia-toolchain/./bin/clang++
 --target=aarch64-unknown-fuchsia 
--sysroot=/usr/local/google/home/leonardchan/sdk/garnet/arch/arm64/sysroot 
-DHWASAN_REPLACE_OPERATORS_NEW_AND_DELETE=1 -D__STDC_CONSTANT_MACROS 
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS 
-I/usr/local/google/home/leonardchan/llvm-monorepo/llvm-project-4/compiler-rt/lib/hwasan/..
 --target=aarch64-unknown-fuchsia 
-I/usr/local/google/home/leonardchan/sdk/garnet/pkg/fdio/include -fPIC 
-fvisibility-inlines-hidden -Werror=date-time 
-Werror=unguarded-availability-new -Wall -Wextra -Wno-unused-parameter 
-Wwrite-strings -Wcast-qual -Wmissing-field-initializers -Wimplicit-fallthrough 
-Wcovered-switch-default -Wno-noexcept-type -Wnon-virtual-dtor 
-Wdelete-non-virtual-dtor -Wsuggest-override -Wno-comment -Wstring-conversion 
-ffunction-sections -fdata-sections 
-ffile-prefix-map=/usr/local/google/home/leonardchan/llvm-monorepo/llvm-build-4-master-fuchsia-toolchain/runtimes/runtimes-aarch64-unknown-fuchsia-bins=../llvm-build-4-master-fuchsia-toolchain/runtimes/runtimes-aarch64-unknown-fuchsia-bins
 
-ffile-prefix-map=/usr/local/google/home/leonardchan/llvm-monorepo/llvm-project-4/=
 -no-canonical-prefixes -Wall -std=c++14 -Wno-unused-parameter -O2 -g -DNDEBUG  
-fPIC -fno-builtin -fno-exceptions -fomit-frame-pointer -funwind-tables 
-fno-stack-protector -fno-sanitize=safe-stack -fvisibility=hidden -fno-lto -O3 
-gline-tables-only -Wno-gnu -Wno-variadic-macros -Wno-c99-extensions 
-nostdinc++ -fno-rtti -fPIC -ffreestanding -ftls-model=initial-exec -MD -MT 
compiler-rt/lib/hwasan/CMakeFiles/RTHwasan_dynamic.aarch64.dir/hwasan.cpp.obj 
-MF 
compiler-rt/lib/hwasan/CMakeFiles/RTHwasan_dynamic.aarch64.dir/hwasan.cpp.obj.d 
-o 
compiler-rt/lib/hwasan/CMakeFiles/RTHwasan_dynamic.aarch64.dir/hwasan.cpp.obj 
-c 
/usr/local/google/home/leonardchan/llvm-monorepo/llvm-project-4/compiler-rt/lib/hwasan/hwasan.cpp
  In file included from 
/usr/local/google/home/leonardchan/llvm-monorepo/llvm-project-4/compiler-rt/lib/hwasan/hwasan.cpp:14:
  In file included from 
/usr/local/google/home/leonardchan/llvm-monorepo/llvm-project-4/compiler-rt/lib/hwasan/hwasan.h:20:
  
/usr/local/google/home/leonardchan/llvm-monorepo/llvm-project-4/compiler-rt/lib/hwasan/hwasan_interface_internal.h:204:11:
 error: no type named '__sanitizer_struct_mallinfo' in namespace '__hwasan'
  __hwasan::__sanitizer_struct_mallinfo __sanitizer_mallinfo();
  ~~^

`__sanitizer_struct_mallinfo` is used as part of the hwasan interface:

  SANITIZER_INTERFACE_ATTRIBUTE
  __hwasan::__sanitizer_struct_mallinfo __sanitizer_mallinfo();

So I'm thinking unless we want to change the API, we may not want to change or 
remove this function. The error comes up because `__sanitizer_struct_mallinfo` 
is currently only defined if `SANITIZER_LINUX || SANITIZER_MAC` is true, so it 
felt appropriate to add a fuchsia-specific definition in 
`sanitizer_platform_limits_fuchsia.h` which can just be empty if we don't use 
it anyway. Would refactoring still be applicable in this case?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99381

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


[PATCH] D99037: [Matrix] Implement C-style explicit type conversions for matrix types

2021-04-07 Thread Saurabh Jha via Phabricator via cfe-commits
SaurabhJha added a comment.

Hopefully this will work. My IDE is a bit wonky and it will take hours to 
rebuild for me after rebase. So pushed here with the hope that this could be 
validated using web build.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99037

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


[PATCH] D99901: [Driver][test] Test intended target only

2021-04-07 Thread Jinsong Ji via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGa723310b419b: [Driver][test] Test intended target only 
(authored by jsji).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99901

Files:
  clang/test/Driver/nostdincxx.cpp


Index: clang/test/Driver/nostdincxx.cpp
===
--- clang/test/Driver/nostdincxx.cpp
+++ clang/test/Driver/nostdincxx.cpp
@@ -1,7 +1,7 @@
 // RUN: not %clangxx -nostdinc %s 2>&1 | FileCheck %s
 // RUN: not %clangxx -nostdinc++ %s 2>&1 | FileCheck %s
 // RUN: not %clangxx -nostdlibinc %s 2>&1 | FileCheck %s
-// RUN: not %clangxx -fsyntax-only -nostdinc -nostdinc++ %s 2>&1 | FileCheck 
/dev/null --implicit-check-not=-Wunused-command-line-argument
+// RUN: not %clangxx -triple x86_64-unknown-unknown-gnu -fsyntax-only 
-nostdinc -nostdinc++ %s 2>&1 | FileCheck /dev/null 
--implicit-check-not=-Wunused-command-line-argument
 // CHECK: file not found
 #include  
 


Index: clang/test/Driver/nostdincxx.cpp
===
--- clang/test/Driver/nostdincxx.cpp
+++ clang/test/Driver/nostdincxx.cpp
@@ -1,7 +1,7 @@
 // RUN: not %clangxx -nostdinc %s 2>&1 | FileCheck %s
 // RUN: not %clangxx -nostdinc++ %s 2>&1 | FileCheck %s
 // RUN: not %clangxx -nostdlibinc %s 2>&1 | FileCheck %s
-// RUN: not %clangxx -fsyntax-only -nostdinc -nostdinc++ %s 2>&1 | FileCheck /dev/null --implicit-check-not=-Wunused-command-line-argument
+// RUN: not %clangxx -triple x86_64-unknown-unknown-gnu -fsyntax-only -nostdinc -nostdinc++ %s 2>&1 | FileCheck /dev/null --implicit-check-not=-Wunused-command-line-argument
 // CHECK: file not found
 #include  
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] a723310 - [Driver][test] Test intended target only

2021-04-07 Thread Jinsong Ji via cfe-commits

Author: Jinsong Ji
Date: 2021-04-07T20:08:26Z
New Revision: a723310b419be870acf72aafd3bfabacbaace642

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

LOG: [Driver][test] Test intended target only

6fe7de90b9e4e466a5c2baadafd5f72d3203651d changed GNU toolchain,
and added new RUN line to test expected behavior.

The change is for GNU toolchain only, so this will fail other toolchain,
eg: AIX.

Update the test with `-target` to test GNU tool chain only.

Reviewed By: MaskRay

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

Added: 


Modified: 
clang/test/Driver/nostdincxx.cpp

Removed: 




diff  --git a/clang/test/Driver/nostdincxx.cpp 
b/clang/test/Driver/nostdincxx.cpp
index c919c73fa126..774874d80d82 100644
--- a/clang/test/Driver/nostdincxx.cpp
+++ b/clang/test/Driver/nostdincxx.cpp
@@ -1,7 +1,7 @@
 // RUN: not %clangxx -nostdinc %s 2>&1 | FileCheck %s
 // RUN: not %clangxx -nostdinc++ %s 2>&1 | FileCheck %s
 // RUN: not %clangxx -nostdlibinc %s 2>&1 | FileCheck %s
-// RUN: not %clangxx -fsyntax-only -nostdinc -nostdinc++ %s 2>&1 | FileCheck 
/dev/null --implicit-check-not=-Wunused-command-line-argument
+// RUN: not %clangxx -triple x86_64-unknown-unknown-gnu -fsyntax-only 
-nostdinc -nostdinc++ %s 2>&1 | FileCheck /dev/null 
--implicit-check-not=-Wunused-command-line-argument
 // CHECK: file not found
 #include  
 



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


[PATCH] D99037: [Matrix] Implement C-style explicit type conversions for matrix types

2021-04-07 Thread Saurabh Jha via Phabricator via cfe-commits
SaurabhJha added inline comments.



Comment at: clang/lib/CodeGen/CGExprScalar.cpp:1453
+  CGF.CGM.getIntrinsic(llvm::Intrinsic::convert_to_fp16,
+   CGF.CGM.FloatTy),
+  Res);

Not sure why this was changed. Perhaps clang-clean.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99037

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


[PATCH] D99037: [Matrix] Implement C-style explicit type conversions for matrix types

2021-04-07 Thread Saurabh Jha via Phabricator via cfe-commits
SaurabhJha updated this revision to Diff 335913.
SaurabhJha added a comment.

Rebased with latest main


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99037

Files:
  clang/include/clang/AST/OperationKinds.def
  clang/include/clang/AST/Stmt.h
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/Sema.h
  clang/lib/AST/Expr.cpp
  clang/lib/AST/ExprConstant.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CGExprAgg.cpp
  clang/lib/CodeGen/CGExprComplex.cpp
  clang/lib/CodeGen/CGExprConstant.cpp
  clang/lib/CodeGen/CGExprScalar.cpp
  clang/lib/Edit/RewriteObjCFoundationAPI.cpp
  clang/lib/Sema/SemaCast.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
  clang/test/CodeGen/matrix-cast.c
  clang/test/Sema/matrix-cast.c
  clang/test/SemaCXX/matrix-casts.cpp

Index: clang/test/SemaCXX/matrix-casts.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/matrix-casts.cpp
@@ -0,0 +1,67 @@
+// RUN: %clang_cc1 -std=c++11 -fenable-matrix -fsyntax-only -verify %s
+
+template 
+
+using matrix_4_4 = X __attribute__((matrix_type(4, 4)));
+
+template 
+
+using matrix_5_5 = Y __attribute__((matrix_type(5, 5)));
+
+typedef struct test_struct {
+} test_struct;
+
+typedef int vec __attribute__((vector_size(4)));
+
+void f1() {
+  // TODO: Update this test once the support of C-style casts for C++ is implemented.
+  matrix_4_4 m1;
+  matrix_4_4 m2;
+  matrix_4_4 m3;
+  matrix_5_5 m4;
+  int i;
+  vec v;
+  test_struct *s;
+
+  (matrix_4_4)m1;   // expected-error {{C-style cast from 'matrix_4_4' (aka 'char __attribute__((matrix_type(4, \
+4)))') to 'matrix_4_4' (aka 'int __attribute__((matrix_type(4, 4)))') is not allowed}}
+  (matrix_4_4)m2; // expected-error {{C-style cast from 'matrix_4_4' (aka 'int __attribute__((matrix_type(4, \
+4)))') to 'matrix_4_4' (aka 'short __attribute__((matrix_type(4, 4)))') is not allowed}}
+  (matrix_5_5)m3;   // expected-error {{C-style cast from 'matrix_4_4' (aka 'short __attribute__((matrix_type(4, \
+4)))') to 'matrix_5_5' (aka 'int __attribute__((matrix_type(5, 5)))') is not allowed}}
+
+  (int)m3;// expected-error {{C-style cast from 'matrix_4_4' (aka 'short __attribute__((matrix_type(4, \
+4)))') to 'int'}}
+  (matrix_4_4)i; // expected-error {{C-style cast from 'int' to 'matrix_4_4' (aka 'int __attribute__((\
+matrix_type(4, 4)))') is not allowed}}
+
+  (vec) m2;// expected-error {{C-style cast from 'matrix_4_4' (aka 'int __attribute__((matrix_type(4, 4)))') \
+to 'vec' (vector of 1 'int' value) is not allowed}}
+  (matrix_4_4)v; // expected-error {{C-style cast from 'vec' (vector of 1 'int' value) to 'matrix_4_4' \
+(aka 'char __attribute__((matrix_type(4, 4)))') is not allowed}}
+
+  (test_struct *)m1;// expected-error {{cannot cast from type 'matrix_4_4' (aka 'char __attribute__\
+((matrix_type(4, 4)))') to pointer type 'test_struct *}}'
+  (matrix_5_5)s; // expected-error {{C-style cast from 'test_struct *' to 'matrix_5_5' (aka 'float __attribute__\
+((matrix_type(5, 5)))') is not allowed}}'
+}
+
+void f2() {
+  // TODO: Update this test once the support of C-style casts for C++ is implemented.
+  matrix_4_4 m1;
+  matrix_5_5 m2;
+  matrix_5_5 m3;
+  matrix_4_4 m4;
+  float f;
+
+  (matrix_4_4)m1;   // expected-error {{C-style cast from 'matrix_4_4' (aka 'float __attribute__\
+((matrix_type(4, 4)))') to 'matrix_4_4' (aka 'double __attribute__((matrix_type(4, 4)))') is not allowed}}
+  (matrix_5_5)m2;// expected-error {{C-style cast from 'matrix_5_5' (aka 'double __attribute__\
+((matrix_type(5, 5)))') to 'matrix_5_5' (aka 'float __attribute__((matrix_type(5, 5)))') is not allowed}}
+  (matrix_5_5)m3; // expected-error {{C-style cast from 'matrix_5_5' (aka 'int __attribute__\
+((matrix_type(5, 5)))') to 'matrix_5_5' (aka 'unsigned int __attribute__((matrix_type(5, 5)))') \
+is not allowed}}
+  (matrix_4_4)m4;  // expected-error {{C-style cast from 'matrix_4_4' (aka 'unsigned int \
+__attribute__((matrix_type(4, 4)))') to 'matrix_4_4' (aka 'int __attribute__((matrix_type(4, 4)))') is not \
+allowed}}
+}
Index: clang/test/Sema/matrix-cast.c
===
--- /dev/null
+++ clang/test/Sema/matrix-cast.c
@@ -0,0 +1,75 @@
+// RUN: %clang_cc1 -fenable-matrix -fsyntax-only %s -verify
+
+typedef char cx4x4 __attribute__((matrix_type(4, 4)));
+typedef int ix4x4 __attribute__((matrix_type(4, 4)));
+typedef short sx4x4 __attribute__((matrix_type(4, 4)));
+typedef int ix5x5 __attribute__((matrix_type(5, 5)));
+typedef float fx5x5 __attribute__((matrix_type(5, 5)));
+typedef int vec __attribute__((vector_size(4)));
+typedef struct test_struct {
+} test_struct;
+
+void f1() {
+  cx4x4 m1;
+  ix4x4 m2;
+  sx4x4 m3;
+  ix5x5 m4;
+  fx5x5 m5;
+  int i;
+  vec v;
+  test_struct *s;
+
+  m2 = (ix4x4)m1;
+  m3 

[clang] ebf2dc3 - Fix missing generate capture expression for novariants condition.

2021-04-07 Thread Jennifer Yu via cfe-commits

Author: Jennifer Yu
Date: 2021-04-07T12:35:49-07:00
New Revision: ebf2dc33287ea414059d3b2f3568f6653ddd4b51

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

LOG: Fix missing generate capture expression for novariants condition.

Added: 


Modified: 
clang/lib/Sema/SemaOpenMP.cpp
clang/test/OpenMP/dispatch_ast_print.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaOpenMP.cpp b/clang/lib/Sema/SemaOpenMP.cpp
index c285ce32aea7..2d2f02c7ed90 100644
--- a/clang/lib/Sema/SemaOpenMP.cpp
+++ b/clang/lib/Sema/SemaOpenMP.cpp
@@ -14905,6 +14905,7 @@ OMPClause *Sema::ActOnOpenMPNovariantsClause(Expr 
*Condition,
 if (CaptureRegion != OMPD_unknown && !CurContext->isDependentContext()) {
   ValExpr = MakeFullExpr(ValExpr).get();
   llvm::MapVector Captures;
+  ValExpr = tryBuildCapture(*this, ValExpr, Captures).get();
   HelperValStmt = buildPreInits(Context, Captures);
 }
   }

diff  --git a/clang/test/OpenMP/dispatch_ast_print.cpp 
b/clang/test/OpenMP/dispatch_ast_print.cpp
index e44c48946bb7..11c0ed82fa90 100644
--- a/clang/test/OpenMP/dispatch_ast_print.cpp
+++ b/clang/test/OpenMP/dispatch_ast_print.cpp
@@ -56,6 +56,9 @@ void test_one()
   //DUMP: OMPDependClause
   //DUMP: OMPNowaitClause
   //DUMP: OMPNovariantsClause
+  //DUMP: DeclRefExpr {{.*}} 'bool' lvalue OMPCapturedExpr
+  //DUMP: OMPNocontextClause
+  //DUMP: DeclRefExpr {{.*}} 'bool' lvalue OMPCapturedExpr
   #pragma omp dispatch depend(in:var) nowait novariants(aaa > 5) nocontext(bbb 
> 5)
   foo(aaa, );
 
@@ -66,6 +69,9 @@ void test_one()
   //DUMP: OMPDeviceClause
   //DUMP: OMPIs_device_ptrClause
   //DUMP: OMPNovariantsClause
+  //DUMP: DeclRefExpr {{.*}} 'bool' lvalue OMPCapturedExpr
+  //DUMP: OMPNocontextClause
+  //DUMP: DeclRefExpr {{.*}} 'bool' lvalue OMPCapturedExpr
   #pragma omp dispatch device(dev) is_device_ptr(dp) novariants(dev > 10) 
nocontext(dev > 5)
   foo(aaa, dp);
 



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


[PATCH] D100051: [clang] Move int <-> float scalar conversion to a separate function

2021-04-07 Thread Erich Keane via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG7d8513b7f2e9: [clang] Move int - float scalar 
conversion to a separate function (authored by SaurabhJha, committed by 
erichkeane).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100051

Files:
  clang/lib/CodeGen/CGExprScalar.cpp


Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -348,6 +348,9 @@
   EmitImplicitIntegerSignChangeChecks(
   SanOpts.has(SanitizerKind::ImplicitIntegerSignChange)) {}
   };
+  Value *EmitScalarCast(Value *Src, QualType SrcType, QualType DstType,
+llvm::Type *SrcTy, llvm::Type *DstTy,
+ScalarConversionOpts Opts);
   Value *
   EmitScalarConversion(Value *Src, QualType SrcTy, QualType DstTy,
SourceLocation Loc,
@@ -1191,6 +1194,35 @@
 {Src, Dst});
 }
 
+Value *ScalarExprEmitter::EmitScalarCast(Value *Src, QualType SrcType,
+ QualType DstType, llvm::Type *SrcTy,
+ llvm::Type *DstTy,
+ ScalarConversionOpts Opts) {
+  if (isa(SrcTy)) {
+bool InputSigned = SrcType->isSignedIntegerOrEnumerationType();
+if (SrcType->isBooleanType() && Opts.TreatBooleanAsSigned) {
+  InputSigned = true;
+}
+
+if (isa(DstTy))
+  return Builder.CreateIntCast(Src, DstTy, InputSigned, "conv");
+if (InputSigned)
+  return Builder.CreateSIToFP(Src, DstTy, "conv");
+return Builder.CreateUIToFP(Src, DstTy, "conv");
+  }
+
+  if (isa(DstTy)) {
+assert(SrcTy->isFloatingPointTy() && "Unknown real conversion");
+if (DstType->isSignedIntegerOrEnumerationType())
+  return Builder.CreateFPToSI(Src, DstTy, "conv");
+return Builder.CreateFPToUI(Src, DstTy, "conv");
+  }
+
+  if (DstTy->getTypeID() < SrcTy->getTypeID())
+return Builder.CreateFPTrunc(Src, DstTy, "conv");
+  return Builder.CreateFPExt(Src, DstTy, "conv");
+}
+
 /// Emit a conversion from the specified type to the specified destination 
type,
 /// both of which are LLVM scalar types.
 Value *ScalarExprEmitter::EmitScalarConversion(Value *Src, QualType SrcType,
@@ -1384,31 +1416,7 @@
 DstTy = CGF.FloatTy;
   }
 
-  if (isa(SrcTy)) {
-bool InputSigned = SrcType->isSignedIntegerOrEnumerationType();
-if (SrcType->isBooleanType() && Opts.TreatBooleanAsSigned) {
-  InputSigned = true;
-}
-if (isa(DstTy))
-  Res = Builder.CreateIntCast(Src, DstTy, InputSigned, "conv");
-else if (InputSigned)
-  Res = Builder.CreateSIToFP(Src, DstTy, "conv");
-else
-  Res = Builder.CreateUIToFP(Src, DstTy, "conv");
-  } else if (isa(DstTy)) {
-assert(SrcTy->isFloatingPointTy() && "Unknown real conversion");
-if (DstType->isSignedIntegerOrEnumerationType())
-  Res = Builder.CreateFPToSI(Src, DstTy, "conv");
-else
-  Res = Builder.CreateFPToUI(Src, DstTy, "conv");
-  } else {
-assert(SrcTy->isFloatingPointTy() && DstTy->isFloatingPointTy() &&
-   "Unknown real conversion");
-if (DstTy->getTypeID() < SrcTy->getTypeID())
-  Res = Builder.CreateFPTrunc(Src, DstTy, "conv");
-else
-  Res = Builder.CreateFPExt(Src, DstTy, "conv");
-  }
+  Res = EmitScalarCast(Src, SrcType, DstType, SrcTy, DstTy, Opts);
 
   if (DstTy != ResTy) {
 if (CGF.getContext().getTargetInfo().useFP16ConversionIntrinsics()) {


Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -348,6 +348,9 @@
   EmitImplicitIntegerSignChangeChecks(
   SanOpts.has(SanitizerKind::ImplicitIntegerSignChange)) {}
   };
+  Value *EmitScalarCast(Value *Src, QualType SrcType, QualType DstType,
+llvm::Type *SrcTy, llvm::Type *DstTy,
+ScalarConversionOpts Opts);
   Value *
   EmitScalarConversion(Value *Src, QualType SrcTy, QualType DstTy,
SourceLocation Loc,
@@ -1191,6 +1194,35 @@
 {Src, Dst});
 }
 
+Value *ScalarExprEmitter::EmitScalarCast(Value *Src, QualType SrcType,
+ QualType DstType, llvm::Type *SrcTy,
+ llvm::Type *DstTy,
+ ScalarConversionOpts Opts) {
+  if (isa(SrcTy)) {
+bool InputSigned = SrcType->isSignedIntegerOrEnumerationType();
+if (SrcType->isBooleanType() && Opts.TreatBooleanAsSigned) {
+  InputSigned = true;
+}
+
+if (isa(DstTy))
+  return Builder.CreateIntCast(Src, DstTy, InputSigned, "conv");
+if (InputSigned)
+  return 

[clang] 7d8513b - [clang] Move int <-> float scalar conversion to a separate function

2021-04-07 Thread Erich Keane via cfe-commits

Author: Saurabh Jha
Date: 2021-04-07T12:34:16-07:00
New Revision: 7d8513b7f2e996fbbb35e0ffce4fe1d4f695928b

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

LOG: [clang] Move int <-> float scalar conversion to a separate function

As prelude to this patch https://reviews.llvm.org/D99037, we want to
move the int-float conversion
into a separate function that can be reused by matrix cast

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

Added: 


Modified: 
clang/lib/CodeGen/CGExprScalar.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGExprScalar.cpp 
b/clang/lib/CodeGen/CGExprScalar.cpp
index c4d49d3ac695..7385440b4d73 100644
--- a/clang/lib/CodeGen/CGExprScalar.cpp
+++ b/clang/lib/CodeGen/CGExprScalar.cpp
@@ -348,6 +348,9 @@ class ScalarExprEmitter
   EmitImplicitIntegerSignChangeChecks(
   SanOpts.has(SanitizerKind::ImplicitIntegerSignChange)) {}
   };
+  Value *EmitScalarCast(Value *Src, QualType SrcType, QualType DstType,
+llvm::Type *SrcTy, llvm::Type *DstTy,
+ScalarConversionOpts Opts);
   Value *
   EmitScalarConversion(Value *Src, QualType SrcTy, QualType DstTy,
SourceLocation Loc,
@@ -1191,6 +1194,35 @@ void ScalarExprEmitter::EmitIntegerSignChangeCheck(Value 
*Src, QualType SrcType,
 {Src, Dst});
 }
 
+Value *ScalarExprEmitter::EmitScalarCast(Value *Src, QualType SrcType,
+ QualType DstType, llvm::Type *SrcTy,
+ llvm::Type *DstTy,
+ ScalarConversionOpts Opts) {
+  if (isa(SrcTy)) {
+bool InputSigned = SrcType->isSignedIntegerOrEnumerationType();
+if (SrcType->isBooleanType() && Opts.TreatBooleanAsSigned) {
+  InputSigned = true;
+}
+
+if (isa(DstTy))
+  return Builder.CreateIntCast(Src, DstTy, InputSigned, "conv");
+if (InputSigned)
+  return Builder.CreateSIToFP(Src, DstTy, "conv");
+return Builder.CreateUIToFP(Src, DstTy, "conv");
+  }
+
+  if (isa(DstTy)) {
+assert(SrcTy->isFloatingPointTy() && "Unknown real conversion");
+if (DstType->isSignedIntegerOrEnumerationType())
+  return Builder.CreateFPToSI(Src, DstTy, "conv");
+return Builder.CreateFPToUI(Src, DstTy, "conv");
+  }
+
+  if (DstTy->getTypeID() < SrcTy->getTypeID())
+return Builder.CreateFPTrunc(Src, DstTy, "conv");
+  return Builder.CreateFPExt(Src, DstTy, "conv");
+}
+
 /// Emit a conversion from the specified type to the specified destination 
type,
 /// both of which are LLVM scalar types.
 Value *ScalarExprEmitter::EmitScalarConversion(Value *Src, QualType SrcType,
@@ -1384,31 +1416,7 @@ Value *ScalarExprEmitter::EmitScalarConversion(Value 
*Src, QualType SrcType,
 DstTy = CGF.FloatTy;
   }
 
-  if (isa(SrcTy)) {
-bool InputSigned = SrcType->isSignedIntegerOrEnumerationType();
-if (SrcType->isBooleanType() && Opts.TreatBooleanAsSigned) {
-  InputSigned = true;
-}
-if (isa(DstTy))
-  Res = Builder.CreateIntCast(Src, DstTy, InputSigned, "conv");
-else if (InputSigned)
-  Res = Builder.CreateSIToFP(Src, DstTy, "conv");
-else
-  Res = Builder.CreateUIToFP(Src, DstTy, "conv");
-  } else if (isa(DstTy)) {
-assert(SrcTy->isFloatingPointTy() && "Unknown real conversion");
-if (DstType->isSignedIntegerOrEnumerationType())
-  Res = Builder.CreateFPToSI(Src, DstTy, "conv");
-else
-  Res = Builder.CreateFPToUI(Src, DstTy, "conv");
-  } else {
-assert(SrcTy->isFloatingPointTy() && DstTy->isFloatingPointTy() &&
-   "Unknown real conversion");
-if (DstTy->getTypeID() < SrcTy->getTypeID())
-  Res = Builder.CreateFPTrunc(Src, DstTy, "conv");
-else
-  Res = Builder.CreateFPExt(Src, DstTy, "conv");
-  }
+  Res = EmitScalarCast(Src, SrcType, DstType, SrcTy, DstTy, Opts);
 
   if (DstTy != ResTy) {
 if (CGF.getContext().getTargetInfo().useFP16ConversionIntrinsics()) {



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


[PATCH] D98193: [CUDA][HIP] Allow non-ODR use of host var in device

2021-04-07 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl updated this revision to Diff 335904.
yaxunl added a comment.

fix test failure on windows. need to specify triple since it affects name 
mangling.


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

https://reviews.llvm.org/D98193

Files:
  clang/lib/Sema/SemaExpr.cpp
  clang/test/CodeGenCUDA/device-use-host-var.cu
  clang/test/SemaCUDA/device-use-host-var.cu

Index: clang/test/SemaCUDA/device-use-host-var.cu
===
--- clang/test/SemaCUDA/device-use-host-var.cu
+++ clang/test/SemaCUDA/device-use-host-var.cu
@@ -5,37 +5,96 @@
 
 #include "Inputs/cuda.h"
 
-int global_host_var;
+struct A {
+  int x;
+  static int host_var;
+};
+
+int A::host_var;
+
+namespace X {
+  int host_var;
+}
+
+static int static_host_var;
+
 __device__ int global_dev_var;
 __constant__ int global_constant_var;
 __shared__ int global_shared_var;
-constexpr int global_constexpr_var = 1;
+
+int global_host_var;
 const int global_const_var = 1;
+constexpr int global_constexpr_var = 1;
+
+int global_host_array[2] = {1, 2};
+const int global_const_array[2] = {1, 2};
+constexpr int global_constexpr_array[2] = {1, 2};
+
+A global_host_struct_var{1};
+const A global_const_struct_var{1};
+constexpr A global_constexpr_struct_var{1};
 
 template
 __global__ void kernel(F f) { f(); } // dev-note2 {{called by 'kernel<(lambda}}
 
 __device__ void dev_fun(int *out) {
-  int _host_var = global_host_var; // dev-error {{reference to __host__ variable 'global_host_var' in __device__ function}}
+  // Check access device variables are allowed.
   int _dev_var = global_dev_var;
   int _constant_var = global_constant_var;
   int _shared_var = global_shared_var;
-  const int _constexpr_var = global_constexpr_var;
-  const int _const_var = global_const_var;
-
-  *out = global_host_var; // dev-error {{reference to __host__ variable 'global_host_var' in __device__ function}}
+  *out = ref_dev_var;
+  *out = ref_constant_var;
+  *out = ref_shared_var;
   *out = global_dev_var;
   *out = global_constant_var;
   *out = global_shared_var;
-  *out = global_constexpr_var;
+
+  // Check access of non-const host variables are not allowed.
+  *out = global_host_var; // dev-error {{reference to __host__ variable 'global_host_var' in __device__ function}}
   *out = global_const_var;
+  *out = global_constexpr_var;
+  global_host_var = 1; // dev-error {{reference to __host__ variable 'global_host_var' in __device__ function}}
 
+  // Check reference of non-constexpr host variables are not allowed.
+  int _host_var = global_host_var; // dev-error {{reference to __host__ variable 'global_host_var' in __device__ function}}
+  const int _const_var = global_const_var; // dev-error {{reference to __host__ variable 'global_const_var' in __device__ function}}
+  const int _constexpr_var = global_constexpr_var;
   *out = ref_host_var;
-  *out = ref_dev_var;
-  *out = ref_constant_var;
-  *out = ref_shared_var;
   *out = ref_constexpr_var;
   *out = ref_const_var;
+
+  // Check access member of non-constexpr struct type host variable is not allowed.
+  *out = global_host_struct_var.x; // dev-error {{reference to __host__ variable 'global_host_struct_var' in __device__ function}}
+  *out = global_const_struct_var.x; // dev-error {{reference to __host__ variable 'global_const_struct_var' in __device__ function}}
+  *out = global_constexpr_struct_var.x;
+  global_host_struct_var.x = 1; // dev-error {{reference to __host__ variable 'global_host_struct_var' in __device__ function}}
+
+  // Check address taking of non-constexpr host variables is not allowed.
+  int *p = _host_var; // dev-error {{reference to __host__ variable 'global_host_var' in __device__ function}}
+  const int *cp = _const_var; // dev-error {{reference to __host__ variable 'global_const_var' in __device__ function}}
+  const int *cp2 = _constexpr_var;
+
+  // Check access elements of non-constexpr host array is not allowed.
+  *out = global_host_array[1]; // dev-error {{reference to __host__ variable 'global_host_array' in __device__ function}}
+  *out = global_const_array[1]; // dev-error {{reference to __host__ variable 'global_const_array' in __device__ function}}
+  *out = global_constexpr_array[1];
+
+  // Check ODR-use of host variables in namespace is not allowed.
+  *out = X::host_var; // dev-error {{reference to __host__ variable 'host_var' in __device__ function}}
+
+  // Check ODR-use of static host varables in class or file scope is not allowed.
+  *out = A::host_var; // dev-error {{reference to __host__ variable 'host_var' in __device__ function}}
+  *out = static_host_var; // dev-error {{reference to __host__ variable 'static_host_var' in __device__ function}}
+
+  // Check function-scope static variable is allowed.
+  static int static_var;
+  *out = static_var;
+
+  // Check non-ODR use of host varirables are allowed.
+  *out = sizeof(global_host_var);
+  *out = sizeof(global_host_struct_var.x);
+  

[PATCH] D100051: [clang] Move int <-> float scalar conversion to a separate function

2021-04-07 Thread Saurabh Jha via Phabricator via cfe-commits
SaurabhJha added a comment.

In D100051#2674849 , @erichkeane 
wrote:

> Alright, validating it now, then I'll push.

Thanks very much.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100051

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


[PATCH] D100049: Remove .gitignore entries not relevant in the monorepo.

2021-04-07 Thread Paul Robinson via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG676a9ab5e406: Remove .gitignore entries not relevant in the 
monorepo. (authored by probinson).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100049

Files:
  clang/.gitignore
  llvm/.gitignore


Index: llvm/.gitignore
===
--- llvm/.gitignore
+++ llvm/.gitignore
@@ -44,16 +44,6 @@
 !projects/Makefile
 runtimes/*
 !runtimes/*.*
-# Clang, which is tracked independently.
-tools/clang
-# LLDB, which is tracked independently.
-tools/lldb
-# lld, which is tracked independently.
-tools/lld
-# Polly, which is tracked independently.
-tools/polly
-# avrlit, which is tracked independently.
-tools/avrlit
 # Sphinx build tree, if building in-source dir.
 docs/_build
 # VS2017 and VSCode config files.
Index: clang/.gitignore
===
--- clang/.gitignore
+++ clang/.gitignore
@@ -26,13 +26,9 @@
 
#==#
 # Directories to ignore (do not add trailing '/'s, they skip symlinks).
 
#==#
-# Clang extra user tools, which is tracked independently (clang-tools-extra).
-tools/extra
 # Sphinx build products
 docs/_build
 docs/analyzer/_build
-# debug info testsuite
-test/debuginfo-tests
 
 # VS2017 and VSCode config files.
 .vscode


Index: llvm/.gitignore
===
--- llvm/.gitignore
+++ llvm/.gitignore
@@ -44,16 +44,6 @@
 !projects/Makefile
 runtimes/*
 !runtimes/*.*
-# Clang, which is tracked independently.
-tools/clang
-# LLDB, which is tracked independently.
-tools/lldb
-# lld, which is tracked independently.
-tools/lld
-# Polly, which is tracked independently.
-tools/polly
-# avrlit, which is tracked independently.
-tools/avrlit
 # Sphinx build tree, if building in-source dir.
 docs/_build
 # VS2017 and VSCode config files.
Index: clang/.gitignore
===
--- clang/.gitignore
+++ clang/.gitignore
@@ -26,13 +26,9 @@
 #==#
 # Directories to ignore (do not add trailing '/'s, they skip symlinks).
 #==#
-# Clang extra user tools, which is tracked independently (clang-tools-extra).
-tools/extra
 # Sphinx build products
 docs/_build
 docs/analyzer/_build
-# debug info testsuite
-test/debuginfo-tests
 
 # VS2017 and VSCode config files.
 .vscode
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D100051: [clang] Move int <-> float scalar conversion to a separate function

2021-04-07 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added a comment.

In D100051#2674849 , @erichkeane 
wrote:

> Alright, validating it now, then I'll push.

Thanks Erich!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100051

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


[clang] 676a9ab - Remove .gitignore entries not relevant in the monorepo.

2021-04-07 Thread Paul Robinson via cfe-commits

Author: Paul Robinson
Date: 2021-04-07T12:25:02-07:00
New Revision: 676a9ab5e406f3a54179b3dd7be1ccd141841d19

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

LOG: Remove .gitignore entries not relevant in the monorepo.

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

Added: 


Modified: 
clang/.gitignore
llvm/.gitignore

Removed: 




diff  --git a/clang/.gitignore b/clang/.gitignore
index 9ee83231d375..3004923c22af 100644
--- a/clang/.gitignore
+++ b/clang/.gitignore
@@ -26,13 +26,9 @@ cscope.out
 
#==#
 # Directories to ignore (do not add trailing '/'s, they skip symlinks).
 
#==#
-# Clang extra user tools, which is tracked independently (clang-tools-extra).
-tools/extra
 # Sphinx build products
 docs/_build
 docs/analyzer/_build
-# debug info testsuite
-test/debuginfo-tests
 
 # VS2017 and VSCode config files.
 .vscode

diff  --git a/llvm/.gitignore b/llvm/.gitignore
index d6021ff18e1f..f2ed54a4f4bd 100644
--- a/llvm/.gitignore
+++ b/llvm/.gitignore
@@ -44,16 +44,6 @@ projects/*
 !projects/Makefile
 runtimes/*
 !runtimes/*.*
-# Clang, which is tracked independently.
-tools/clang
-# LLDB, which is tracked independently.
-tools/lldb
-# lld, which is tracked independently.
-tools/lld
-# Polly, which is tracked independently.
-tools/polly
-# avrlit, which is tracked independently.
-tools/avrlit
 # Sphinx build tree, if building in-source dir.
 docs/_build
 # VS2017 and VSCode config files.



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


[PATCH] D100051: [clang] Move int <-> float scalar conversion to a separate function

2021-04-07 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

Alright, validating it now, then I'll push.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100051

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


[PATCH] D100037: [clang][UBSan] Passing underaligned pointer as a function argument is undefined behaviour

2021-04-07 Thread John McCall via Phabricator via cfe-commits
rjmccall added a comment.

> Yes. We now have a motivational reason to do so, it wouldn't be "just expose 
> the UB for the sake of miscompiling the program".

Nobody thinks you're proposing this just for the sake of miscompiling.  We 
understand that there are optimization benefits to having this information.  We 
just don't think you get to have this information in general, because of the de 
facto rules of the language.  Knowing that argument pointers don't alias would 
also be valuable for optimization, but C doesn't guarantee that; this is not 
that different, it's just that the language rule is a self-imposed rule of our 
implementation instead of being written up in a standard.

Are you certain that knowing argument pointer alignment is the only way of 
achieving this optimization?  That's surprising to me because I would expect 
that most optimizations would also need dereferenceability, which of course you 
can't get.  And if you can see (and hoist) a load to infer dereferenceability 
then you can also infer alignment from that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100037

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


[PATCH] D100057: Remove warning "suggest braces" for aggregate initialization of an empty class with an aggregate base class.

2021-04-07 Thread Hana Dusíková via Phabricator via cfe-commits
hankadusikova marked an inline comment as done.
hankadusikova added a comment.

In D100057#2674820 , @lebedev.ri 
wrote:

> This patch says what it does, but not why it does what it does.
> Did the pattern become idiomatic so that we now want to not warn?

Yes, using inheritance for strong typing with aggregates is quite common 
pattern. I checked GCC / EDG / MSVC and neither of them is emitting warning in 
this case.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100057

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


[PATCH] D98902: [Clang][OpenMP][NVPTX] Fixed failure in openmp-offload-gpu.c if the system has CUDA

2021-04-07 Thread Jonas Hahnfeld via Phabricator via cfe-commits
Hahnfeld added a comment.

Can we get this fixed somehow? It's annoying that there is a test failure in 
Clang without building the OpenMP runtime, just because I have CUDA installed 
on my machine...


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98902

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


[PATCH] D100057: Remove warning "suggest braces" for aggregate initialization of an empty class with an aggregate base class.

2021-04-07 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

This patch says what it does, but not why it does what it does.
Did the pattern become idiomatic so that we now want to not warn?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100057

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


[PATCH] D99791: [CGCall] Annotate pointer argument with alignment

2021-04-07 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri updated this revision to Diff 335894.
lebedev.ri added a comment.
Herald added subscribers: jansvoboda11, dexonsmith, dang.

Add an option to toggle this optimization.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99791

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/docs/ReleaseNotes.rst
  clang/docs/UsersManual.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/Driver/ToolChains/Clang.cpp

Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -4872,6 +4872,10 @@
options::OPT_fno_force_emit_vtables,
false))
 CmdArgs.push_back("-fforce-emit-vtables");
+  if (Args.hasFlag(options::OPT_fstrict_pointer_alignment,
+   options::OPT_fno_strict_pointer_alignment,
+   !RawTriple.isOSDarwin()))
+CmdArgs.push_back("-fstrict-pointer-alignment");
   if (!Args.hasFlag(options::OPT_foptimize_sibling_calls,
 options::OPT_fno_optimize_sibling_calls))
 CmdArgs.push_back("-mdisable-tail-calls");
Index: clang/lib/CodeGen/CGCall.cpp
===
--- clang/lib/CodeGen/CGCall.cpp
+++ clang/lib/CodeGen/CGCall.cpp
@@ -2446,6 +2446,17 @@
   }
 }
 
+if (getCodeGenOpts().StrictPointerAlignment) {
+  if (const auto *PtrTy = ParamType->getAs()) {
+QualType PTy = PtrTy->getPointeeType();
+if (PTy->isObjectType()) {
+  llvm::Align Alignment =
+  getNaturalPointeeTypeAlignment(ParamType).getAsAlign();
+  Attrs.addAlignmentAttr(Alignment);
+}
+  }
+}
+
 switch (FI.getExtParameterInfo(ArgNo).getABI()) {
 case ParameterABI::Ordinary:
   break;
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -2446,6 +2446,11 @@
   PosFlag,
   NegFlag>;
+defm strict_pointer_alignment : BoolFOption<"strict-pointer-alignment",
+  CodeGenOpts<"StrictPointerAlignment">, DefaultFalse,
+  NegFlag,
+  PosFlag,
+  BothFlags<[], " optimizations based on the strict rules for pointer alignmen">>;
 def fstrict_overflow : Flag<["-"], "fstrict-overflow">, Group;
 def fsyntax_only : Flag<["-"], "fsyntax-only">,
   Flags<[NoXarchOption,CoreOption,CC1Option,FC1Option]>, Group;
Index: clang/include/clang/Basic/CodeGenOptions.def
===
--- clang/include/clang/Basic/CodeGenOptions.def
+++ clang/include/clang/Basic/CodeGenOptions.def
@@ -261,6 +261,7 @@
 CODEGENOPT(FineGrainedBitfieldAccesses, 1, 0) ///< Enable fine-grained bitfield accesses.
 CODEGENOPT(StrictEnums   , 1, 0) ///< Optimize based on strict enum definition.
 CODEGENOPT(StrictVTablePointers, 1, 0) ///< Optimize based on the strict vtable pointers
+CODEGENOPT(StrictPointerAlignment, 1, 1) ///< Optimize based on the strict pointer alignment rules
 CODEGENOPT(TimePasses, 1, 0) ///< Set when -ftime-report or -ftime-report= is enabled.
 CODEGENOPT(TimePassesPerRun  , 1, 0) ///< Set when -ftime-report=per-pass-run is enabled.
 CODEGENOPT(TimeTrace , 1, 0) ///< Set when -ftime-trace is enabled.
Index: clang/docs/UsersManual.rst
===
--- clang/docs/UsersManual.rst
+++ clang/docs/UsersManual.rst
@@ -1669,6 +1669,12 @@
modules where it isn't necessary. It causes more inline virtual functions
to be emitted.
 
+.. option:: -fstrict-pointer-alignment
+
+   Enable optimizations based on the strict rules for pointer alignment.
+   This currently only affects function pointer arguments, and only controls
+   UBSan behaviour, no optimizations are currently performed based on it.
+
 .. option:: -fno-assume-sane-operator-new
 
Don't assume that the C++'s new operator is sane.
Index: clang/docs/ReleaseNotes.rst
===
--- clang/docs/ReleaseNotes.rst
+++ clang/docs/ReleaseNotes.rst
@@ -54,6 +54,10 @@
   to allow codebases to be cleaned up in preparation for this optimization,
   to avoid miscompiles.
 
+- Clang now assumes that all function pointer arguments are properly aligned,
+  and optimizes on that. A new ``-fstrict-pointer-alignment`` flag was
+  introduces (default on), which guards these new optimizations.
+
 
 Improvements to Clang's diagnostics
 ^^^
Index: clang/docs/ClangCommandLineReference.rst
===
--- clang/docs/ClangCommandLineReference.rst
+++ clang/docs/ClangCommandLineReference.rst
@@ 

[PATCH] D100037: [clang][UBSan] Passing underaligned pointer as a function argument is undefined behaviour

2021-04-07 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri updated this revision to Diff 335893.
lebedev.ri marked an inline comment as done.
lebedev.ri added a comment.

Unguard the UBSan check under `-fstrict*`.

In D100037#2674610 , @rsmith wrote:

> I assume your intent here is to eventually add LLVM parameter attributes 
> indicating the function argument is correctly-aligned, which is why you're 
> checking on call boundaries?

Yep, D99791 .


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100037

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/catch-function-pointer-argument-alignment.cpp
  compiler-rt/lib/ubsan/ubsan_handlers.cpp
  compiler-rt/test/ubsan/TestCases/Pointer/function-pointer-argument.cpp

Index: compiler-rt/test/ubsan/TestCases/Pointer/function-pointer-argument.cpp
===
--- /dev/null
+++ compiler-rt/test/ubsan/TestCases/Pointer/function-pointer-argument.cpp
@@ -0,0 +1,30 @@
+// RUN: %clang   -x c   -fsanitize=alignment -O0 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+// RUN: %clang   -x c   -fsanitize=alignment -O1 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+// RUN: %clang   -x c   -fsanitize=alignment -O2 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+// RUN: %clang   -x c   -fsanitize=alignment -O3 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+
+// RUN: %clang   -x c++ -fsanitize=alignment -O0 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+// RUN: %clang   -x c++ -fsanitize=alignment -O1 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+// RUN: %clang   -x c++ -fsanitize=alignment -O2 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+// RUN: %clang   -x c++ -fsanitize=alignment -O3 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+
+#include 
+
+struct S {
+  int k;
+} __attribute__((aligned(8192)));
+
+void take_pointer_to_overaligned_struct(struct S *x) {
+}
+
+int main(int argc, char *argv[]) {
+  char *ptr = (char *)malloc(2 * sizeof(struct S));
+
+  take_pointer_to_overaligned_struct((struct S *)(ptr + 1));
+  // CHECK: {{.*}}function-pointer-argument.cpp:[[@LINE-7]]:51: runtime error: function pointer argument has misaligned address {{.*}} for type 'struct S', which requires 8192 byte alignment
+  // CHECK: 0x{{.*}}: note: pointer points here
+
+  free(ptr);
+
+  return 0;
+}
Index: compiler-rt/lib/ubsan/ubsan_handlers.cpp
===
--- compiler-rt/lib/ubsan/ubsan_handlers.cpp
+++ compiler-rt/lib/ubsan/ubsan_handlers.cpp
@@ -73,15 +73,25 @@
   TCK_NonnullAssign,
   /// Checking the operand of a dynamic_cast or a typeid expression.  Must be
   /// null or an object within its lifetime.
-  TCK_DynamicOperation
+  TCK_DynamicOperation,
+  /// Checking the alignment of the function's pointer argument.
+  TCK_FunctionPointerArgument
 };
 
-const char *TypeCheckKinds[] = {
-"load of", "store to", "reference binding to", "member access within",
-"member call on", "constructor call on", "downcast of", "downcast of",
-"upcast of", "cast to virtual base of", "_Nonnull binding to",
-"dynamic operation on"};
-}
+const char *TypeCheckKinds[] = {"load of",
+"store to",
+"reference binding to",
+"member access within",
+"member call on",
+"constructor call on",
+"downcast of",
+"downcast of",
+"upcast of",
+"cast to virtual base of",
+"_Nonnull binding to",
+"dynamic operation on",
+"function pointer argument has"};
+} // namespace __ubsan
 
 static void handleTypeMismatchImpl(TypeMismatchData *Data, ValueHandle Pointer,
ReportOptions Opts) {
Index: clang/test/CodeGen/catch-function-pointer-argument-alignment.cpp

[PATCH] D100057: Remove warning "suggest braces" for aggregate initialization of an empty class with an aggregate base class.

2021-04-07 Thread Hana Dusíková via Phabricator via cfe-commits
hankadusikova updated this revision to Diff 335892.
hankadusikova added a comment.

Fix typo.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100057

Files:
  clang/lib/Sema/SemaInit.cpp
  clang/test/SemaCXX/aggregate-initialization.cpp


Index: clang/test/SemaCXX/aggregate-initialization.cpp
===
--- clang/test/SemaCXX/aggregate-initialization.cpp
+++ clang/test/SemaCXX/aggregate-initialization.cpp
@@ -172,11 +172,20 @@
   };
   ArrayAndBaseClass z = {1, 2, 3}; // expected-warning {{suggest 
braces}}
 
-  // It's not clear whether we should be warning in this case. If this
-  // pattern becomes idiomatic, it would be reasonable to suppress the
-  // warning here too.
+  // This pattern is used for tagged aggregates and must not warn
   template struct JustABaseClass : StdArray {};
-  JustABaseClass w = {1, 2, 3}; // expected-warning {{suggest braces}}
+  JustABaseClass w = {1, 2, 3};
+  // but this should be also ok
+  JustABaseClass v = {{1, 2, 3}};
+
+  template  struct OnionBaseClass : JustABaseClass {};
+  OnionBaseClass u = {1, 2, 3};
+  OnionBaseClass t = {{{1, 2, 3}}};
+
+  struct EmptyBase {};
+
+  template  struct AggregateAndEmpty : StdArray, 
EmptyBase {};
+  AggregateAndEmpty p = {1, 2, 3}; // expected-warning {{suggest 
braces}}
 #endif
 
 #pragma clang diagnostic pop
Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -1007,21 +1007,37 @@
   //
   // (where std::array is an aggregate struct containing a single array field.
 
-  // FIXME: Should aggregate initialization of a struct with a single
-  // base class and no members also suppress the warning?
-  if (Entity.getKind() != InitializedEntity::EK_Member || !Entity.getParent())
+  if (!Entity.getParent())
 return false;
 
-  auto *ParentRD =
-  Entity.getParent()->getType()->castAs()->getDecl();
-  if (CXXRecordDecl *CXXRD = dyn_cast(ParentRD))
-if (CXXRD->getNumBases())
-  return false;
+  // Allows elide brace initialization for aggregates with empty base
+  if (Entity.getKind() == InitializedEntity::EK_Base) {
+auto *ParentRD =
+Entity.getParent()->getType()->castAs()->getDecl();
+if (CXXRecordDecl *CXXRD = dyn_cast(ParentRD)) {
+  if (CXXRD->getNumBases() == 1) {
+return ParentRD->field_begin() == ParentRD->field_end();
+  }
+}
+return false;
+  }
 
-  auto FieldIt = ParentRD->field_begin();
-  assert(FieldIt != ParentRD->field_end() &&
- "no fields but have initializer for member?");
-  return ++FieldIt == ParentRD->field_end();
+  // Allows elide brace initilization for aggregates with one member
+  if (Entity.getKind() == InitializedEntity::EK_Member) {
+auto *ParentRD =
+Entity.getParent()->getType()->castAs()->getDecl();
+if (CXXRecordDecl *CXXRD = dyn_cast(ParentRD)) {
+  if (CXXRD->getNumBases()) {
+return false;
+  }
+}
+auto FieldIt = ParentRD->field_begin();
+assert(FieldIt != ParentRD->field_end() &&
+   "no fields but have initializer for member?");
+return ++FieldIt == ParentRD->field_end();
+  }
+
+  return false;
 }
 
 /// Check whether the range of the initializer \p ParentIList from element


Index: clang/test/SemaCXX/aggregate-initialization.cpp
===
--- clang/test/SemaCXX/aggregate-initialization.cpp
+++ clang/test/SemaCXX/aggregate-initialization.cpp
@@ -172,11 +172,20 @@
   };
   ArrayAndBaseClass z = {1, 2, 3}; // expected-warning {{suggest braces}}
 
-  // It's not clear whether we should be warning in this case. If this
-  // pattern becomes idiomatic, it would be reasonable to suppress the
-  // warning here too.
+  // This pattern is used for tagged aggregates and must not warn
   template struct JustABaseClass : StdArray {};
-  JustABaseClass w = {1, 2, 3}; // expected-warning {{suggest braces}}
+  JustABaseClass w = {1, 2, 3};
+  // but this should be also ok
+  JustABaseClass v = {{1, 2, 3}};
+
+  template  struct OnionBaseClass : JustABaseClass {};
+  OnionBaseClass u = {1, 2, 3};
+  OnionBaseClass t = {{{1, 2, 3}}};
+
+  struct EmptyBase {};
+
+  template  struct AggregateAndEmpty : StdArray, EmptyBase {};
+  AggregateAndEmpty p = {1, 2, 3}; // expected-warning {{suggest braces}}
 #endif
 
 #pragma clang diagnostic pop
Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -1007,21 +1007,37 @@
   //
   // (where std::array is an aggregate struct containing a single array field.
 
-  // FIXME: Should aggregate initialization of a struct with a single
-  // base class and no members also suppress the warning?
-  if (Entity.getKind() != 

[PATCH] D99964: [RISCV][Clang] Add all RVV Reduction intrinsic functions.

2021-04-07 Thread Craig Topper via Phabricator via cfe-commits
craig.topper accepted this revision.
craig.topper added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99964

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


[PATCH] D100051: [clang] Move int <-> float scalar conversion to a separate function

2021-04-07 Thread Saurabh Jha via Phabricator via cfe-commits
SaurabhJha added a comment.

I don't have commit rights so if it looks good to you, please commit on my 
behalf.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100051

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


[PATCH] D100057: Remove warning "suggest braces" for aggregate initialization of an empty class with an aggregate base class.

2021-04-07 Thread Michael Schellenberger Costa via Phabricator via cfe-commits
miscco added inline comments.



Comment at: clang/lib/Sema/SemaInit.cpp:1013
 
-  auto *ParentRD =
-  Entity.getParent()->getType()->castAs()->getDecl();
-  if (CXXRecordDecl *CXXRD = dyn_cast(ParentRD))
-if (CXXRD->getNumBases())
-  return false;
+  // Allows elide brace initialization for aggreagates with empty base
+  if (Entity.getKind() == InitializedEntity::EK_Base) {

There is a typo here `aggreagates` -> `aggregates`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100057

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


[PATCH] D100057: Remove warning "suggest braces" for aggregate initialization of an empty class with an aggregate base class.

2021-04-07 Thread Hana Dusíková via Phabricator via cfe-commits
hankadusikova created this revision.
hankadusikova added a reviewer: clang.
hankadusikova requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Removes this warning:

  template struct StdArray {
  T contents[N];
};
  
  template struct AggregateAndEmpty : StdArray { };
  
  AggregateAndEmpty p = {1, 2, 3}; // <-- warning here about omitted 
braces

This warning starts to be prominent when you have multiple levels of 
inheritance for strong typing with aggregates:

  template struct StdArray {
  T contents[N];
  };
  
  template  struct JustABaseClass : StdArray {};
  template  struct OnionBaseClass : JustABaseClass {};
  
  OnionBaseClass i = {1,2,3}; // instead {{{1,2,3}}}

This is my first patch for clang, so I hopefully didn't overlook something, but 
all tests are green.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100057

Files:
  clang/lib/Sema/SemaInit.cpp
  clang/test/SemaCXX/aggregate-initialization.cpp


Index: clang/test/SemaCXX/aggregate-initialization.cpp
===
--- clang/test/SemaCXX/aggregate-initialization.cpp
+++ clang/test/SemaCXX/aggregate-initialization.cpp
@@ -172,11 +172,20 @@
   };
   ArrayAndBaseClass z = {1, 2, 3}; // expected-warning {{suggest 
braces}}
 
-  // It's not clear whether we should be warning in this case. If this
-  // pattern becomes idiomatic, it would be reasonable to suppress the
-  // warning here too.
+  // This pattern is used for tagged aggregates and must not warn
   template struct JustABaseClass : StdArray {};
-  JustABaseClass w = {1, 2, 3}; // expected-warning {{suggest braces}}
+  JustABaseClass w = {1, 2, 3};
+  // but this should be also ok
+  JustABaseClass v = {{1, 2, 3}};
+
+  template  struct OnionBaseClass : JustABaseClass {};
+  OnionBaseClass u = {1, 2, 3};
+  OnionBaseClass t = {{{1, 2, 3}}};
+
+  struct EmptyBase {};
+
+  template  struct AggregateAndEmpty : StdArray, 
EmptyBase {};
+  AggregateAndEmpty p = {1, 2, 3}; // expected-warning {{suggest 
braces}}
 #endif
 
 #pragma clang diagnostic pop
Index: clang/lib/Sema/SemaInit.cpp
===
--- clang/lib/Sema/SemaInit.cpp
+++ clang/lib/Sema/SemaInit.cpp
@@ -1007,21 +1007,37 @@
   //
   // (where std::array is an aggregate struct containing a single array field.
 
-  // FIXME: Should aggregate initialization of a struct with a single
-  // base class and no members also suppress the warning?
-  if (Entity.getKind() != InitializedEntity::EK_Member || !Entity.getParent())
+  if (!Entity.getParent())
 return false;
 
-  auto *ParentRD =
-  Entity.getParent()->getType()->castAs()->getDecl();
-  if (CXXRecordDecl *CXXRD = dyn_cast(ParentRD))
-if (CXXRD->getNumBases())
-  return false;
+  // Allows elide brace initialization for aggreagates with empty base
+  if (Entity.getKind() == InitializedEntity::EK_Base) {
+auto *ParentRD =
+Entity.getParent()->getType()->castAs()->getDecl();
+if (CXXRecordDecl *CXXRD = dyn_cast(ParentRD)) {
+  if (CXXRD->getNumBases() == 1) {
+return ParentRD->field_begin() == ParentRD->field_end();
+  }
+}
+return false;
+  }
 
-  auto FieldIt = ParentRD->field_begin();
-  assert(FieldIt != ParentRD->field_end() &&
- "no fields but have initializer for member?");
-  return ++FieldIt == ParentRD->field_end();
+  // Allows elide brace initilization for aggregates with one member
+  if (Entity.getKind() == InitializedEntity::EK_Member) {
+auto *ParentRD =
+Entity.getParent()->getType()->castAs()->getDecl();
+if (CXXRecordDecl *CXXRD = dyn_cast(ParentRD)) {
+  if (CXXRD->getNumBases()) {
+return false;
+  }
+}
+auto FieldIt = ParentRD->field_begin();
+assert(FieldIt != ParentRD->field_end() &&
+   "no fields but have initializer for member?");
+return ++FieldIt == ParentRD->field_end();
+  }
+
+  return false;
 }
 
 /// Check whether the range of the initializer \p ParentIList from element


Index: clang/test/SemaCXX/aggregate-initialization.cpp
===
--- clang/test/SemaCXX/aggregate-initialization.cpp
+++ clang/test/SemaCXX/aggregate-initialization.cpp
@@ -172,11 +172,20 @@
   };
   ArrayAndBaseClass z = {1, 2, 3}; // expected-warning {{suggest braces}}
 
-  // It's not clear whether we should be warning in this case. If this
-  // pattern becomes idiomatic, it would be reasonable to suppress the
-  // warning here too.
+  // This pattern is used for tagged aggregates and must not warn
   template struct JustABaseClass : StdArray {};
-  JustABaseClass w = {1, 2, 3}; // expected-warning {{suggest braces}}
+  JustABaseClass w = {1, 2, 3};
+  // but this should be also ok
+  JustABaseClass v = {{1, 2, 3}};
+
+  template  struct OnionBaseClass : JustABaseClass {};
+  OnionBaseClass u = {1, 2, 3};
+  

[PATCH] D100051: [clang] Move int <-> float scalar conversion to a separate function

2021-04-07 Thread Saurabh Jha via Phabricator via cfe-commits
SaurabhJha updated this revision to Diff 335884.
SaurabhJha added a comment.

Rename the function to `EmitScalarCast` and directly returning from `if` 
branches now


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100051

Files:
  clang/lib/CodeGen/CGExprScalar.cpp


Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -348,6 +348,9 @@
   EmitImplicitIntegerSignChangeChecks(
   SanOpts.has(SanitizerKind::ImplicitIntegerSignChange)) {}
   };
+  Value *EmitScalarCast(Value *Src, QualType SrcType, QualType DstType,
+llvm::Type *SrcTy, llvm::Type *DstTy,
+ScalarConversionOpts Opts);
   Value *
   EmitScalarConversion(Value *Src, QualType SrcTy, QualType DstTy,
SourceLocation Loc,
@@ -1191,6 +1194,35 @@
 {Src, Dst});
 }
 
+Value *ScalarExprEmitter::EmitScalarCast(Value *Src, QualType SrcType,
+ QualType DstType, llvm::Type *SrcTy,
+ llvm::Type *DstTy,
+ ScalarConversionOpts Opts) {
+  if (isa(SrcTy)) {
+bool InputSigned = SrcType->isSignedIntegerOrEnumerationType();
+if (SrcType->isBooleanType() && Opts.TreatBooleanAsSigned) {
+  InputSigned = true;
+}
+
+if (isa(DstTy))
+  return Builder.CreateIntCast(Src, DstTy, InputSigned, "conv");
+if (InputSigned)
+  return Builder.CreateSIToFP(Src, DstTy, "conv");
+return Builder.CreateUIToFP(Src, DstTy, "conv");
+  }
+
+  if (isa(DstTy)) {
+assert(SrcTy->isFloatingPointTy() && "Unknown real conversion");
+if (DstType->isSignedIntegerOrEnumerationType())
+  return Builder.CreateFPToSI(Src, DstTy, "conv");
+return Builder.CreateFPToUI(Src, DstTy, "conv");
+  }
+
+  if (DstTy->getTypeID() < SrcTy->getTypeID())
+return Builder.CreateFPTrunc(Src, DstTy, "conv");
+  return Builder.CreateFPExt(Src, DstTy, "conv");
+}
+
 /// Emit a conversion from the specified type to the specified destination 
type,
 /// both of which are LLVM scalar types.
 Value *ScalarExprEmitter::EmitScalarConversion(Value *Src, QualType SrcType,
@@ -1384,31 +1416,7 @@
 DstTy = CGF.FloatTy;
   }
 
-  if (isa(SrcTy)) {
-bool InputSigned = SrcType->isSignedIntegerOrEnumerationType();
-if (SrcType->isBooleanType() && Opts.TreatBooleanAsSigned) {
-  InputSigned = true;
-}
-if (isa(DstTy))
-  Res = Builder.CreateIntCast(Src, DstTy, InputSigned, "conv");
-else if (InputSigned)
-  Res = Builder.CreateSIToFP(Src, DstTy, "conv");
-else
-  Res = Builder.CreateUIToFP(Src, DstTy, "conv");
-  } else if (isa(DstTy)) {
-assert(SrcTy->isFloatingPointTy() && "Unknown real conversion");
-if (DstType->isSignedIntegerOrEnumerationType())
-  Res = Builder.CreateFPToSI(Src, DstTy, "conv");
-else
-  Res = Builder.CreateFPToUI(Src, DstTy, "conv");
-  } else {
-assert(SrcTy->isFloatingPointTy() && DstTy->isFloatingPointTy() &&
-   "Unknown real conversion");
-if (DstTy->getTypeID() < SrcTy->getTypeID())
-  Res = Builder.CreateFPTrunc(Src, DstTy, "conv");
-else
-  Res = Builder.CreateFPExt(Src, DstTy, "conv");
-  }
+  Res = EmitScalarCast(Src, SrcType, DstType, SrcTy, DstTy, Opts);
 
   if (DstTy != ResTy) {
 if (CGF.getContext().getTargetInfo().useFP16ConversionIntrinsics()) {


Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -348,6 +348,9 @@
   EmitImplicitIntegerSignChangeChecks(
   SanOpts.has(SanitizerKind::ImplicitIntegerSignChange)) {}
   };
+  Value *EmitScalarCast(Value *Src, QualType SrcType, QualType DstType,
+llvm::Type *SrcTy, llvm::Type *DstTy,
+ScalarConversionOpts Opts);
   Value *
   EmitScalarConversion(Value *Src, QualType SrcTy, QualType DstTy,
SourceLocation Loc,
@@ -1191,6 +1194,35 @@
 {Src, Dst});
 }
 
+Value *ScalarExprEmitter::EmitScalarCast(Value *Src, QualType SrcType,
+ QualType DstType, llvm::Type *SrcTy,
+ llvm::Type *DstTy,
+ ScalarConversionOpts Opts) {
+  if (isa(SrcTy)) {
+bool InputSigned = SrcType->isSignedIntegerOrEnumerationType();
+if (SrcType->isBooleanType() && Opts.TreatBooleanAsSigned) {
+  InputSigned = true;
+}
+
+if (isa(DstTy))
+  return Builder.CreateIntCast(Src, DstTy, InputSigned, "conv");
+if (InputSigned)
+  return Builder.CreateSIToFP(Src, DstTy, "conv");
+return 

[PATCH] D100056: [SystemZ][z/OS] Set files in FileRemapper.cpp are text

2021-04-07 Thread Abhina Sree via Phabricator via cfe-commits
abhina.sreeskantharajan created this revision.
abhina.sreeskantharajan requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch sets files in FileRemapper to open as text.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100056

Files:
  clang/lib/ARCMigrate/FileRemapper.cpp


Index: clang/lib/ARCMigrate/FileRemapper.cpp
===
--- clang/lib/ARCMigrate/FileRemapper.cpp
+++ clang/lib/ARCMigrate/FileRemapper.cpp
@@ -63,7 +63,7 @@
   std::vector > pairs;
 
   llvm::ErrorOr> fileBuf =
-  llvm::MemoryBuffer::getFile(infoFile);
+  llvm::MemoryBuffer::getFile(infoFile, /*IsText=*/true);
   if (!fileBuf)
 return report("Error opening file: " + infoFile, Diag);
 
@@ -121,7 +121,7 @@
 
   std::error_code EC;
   std::string infoFile = std::string(outputPath);
-  llvm::raw_fd_ostream infoOut(infoFile, EC, llvm::sys::fs::OF_None);
+  llvm::raw_fd_ostream infoOut(infoFile, EC, llvm::sys::fs::OF_Text);
   if (EC)
 return report(EC.message(), Diag);
 
@@ -144,7 +144,7 @@
   int fd;
   if (fs::createTemporaryFile(path::filename(origFE->getName()),
   
path::extension(origFE->getName()).drop_front(), fd,
-  tempPath))
+  tempPath, llvm::sys::fs::OF_Text))
 return report("Could not create file: " + tempPath.str(), Diag);
 
   llvm::raw_fd_ostream newOut(fd, /*shouldClose=*/true);


Index: clang/lib/ARCMigrate/FileRemapper.cpp
===
--- clang/lib/ARCMigrate/FileRemapper.cpp
+++ clang/lib/ARCMigrate/FileRemapper.cpp
@@ -63,7 +63,7 @@
   std::vector > pairs;
 
   llvm::ErrorOr> fileBuf =
-  llvm::MemoryBuffer::getFile(infoFile);
+  llvm::MemoryBuffer::getFile(infoFile, /*IsText=*/true);
   if (!fileBuf)
 return report("Error opening file: " + infoFile, Diag);
 
@@ -121,7 +121,7 @@
 
   std::error_code EC;
   std::string infoFile = std::string(outputPath);
-  llvm::raw_fd_ostream infoOut(infoFile, EC, llvm::sys::fs::OF_None);
+  llvm::raw_fd_ostream infoOut(infoFile, EC, llvm::sys::fs::OF_Text);
   if (EC)
 return report(EC.message(), Diag);
 
@@ -144,7 +144,7 @@
   int fd;
   if (fs::createTemporaryFile(path::filename(origFE->getName()),
   path::extension(origFE->getName()).drop_front(), fd,
-  tempPath))
+  tempPath, llvm::sys::fs::OF_Text))
 return report("Could not create file: " + tempPath.str(), Diag);
 
   llvm::raw_fd_ostream newOut(fd, /*shouldClose=*/true);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D100055: Fix missing generate capture expression for novariants's condition

2021-04-07 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev accepted this revision.
ABataev added a comment.
This revision is now accepted and ready to land.

LG


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100055

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


[PATCH] D100055: Fix missing generate capture expression for novariants's condition

2021-04-07 Thread Jennifer Yu via Phabricator via cfe-commits
jyu2 created this revision.
jyu2 added reviewers: ABataev, mikerice.
jyu2 requested review of this revision.
Herald added a project: clang.

This is fix missing capture expression for novariants's condition


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100055

Files:
  clang/lib/Sema/SemaOpenMP.cpp
  clang/test/OpenMP/dispatch_ast_print.cpp


Index: clang/test/OpenMP/dispatch_ast_print.cpp
===
--- clang/test/OpenMP/dispatch_ast_print.cpp
+++ clang/test/OpenMP/dispatch_ast_print.cpp
@@ -56,6 +56,9 @@
   //DUMP: OMPDependClause
   //DUMP: OMPNowaitClause
   //DUMP: OMPNovariantsClause
+  //DUMP: DeclRefExpr {{.*}} 'bool' lvalue OMPCapturedExpr
+  //DUMP: OMPNocontextClause
+  //DUMP: DeclRefExpr {{.*}} 'bool' lvalue OMPCapturedExpr
   #pragma omp dispatch depend(in:var) nowait novariants(aaa > 5) nocontext(bbb 
> 5)
   foo(aaa, );
 
@@ -66,6 +69,9 @@
   //DUMP: OMPDeviceClause
   //DUMP: OMPIs_device_ptrClause
   //DUMP: OMPNovariantsClause
+  //DUMP: DeclRefExpr {{.*}} 'bool' lvalue OMPCapturedExpr
+  //DUMP: OMPNocontextClause
+  //DUMP: DeclRefExpr {{.*}} 'bool' lvalue OMPCapturedExpr
   #pragma omp dispatch device(dev) is_device_ptr(dp) novariants(dev > 10) 
nocontext(dev > 5)
   foo(aaa, dp);
 
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clang/lib/Sema/SemaOpenMP.cpp
@@ -14905,6 +14905,7 @@
 if (CaptureRegion != OMPD_unknown && !CurContext->isDependentContext()) {
   ValExpr = MakeFullExpr(ValExpr).get();
   llvm::MapVector Captures;
+  ValExpr = tryBuildCapture(*this, ValExpr, Captures).get();
   HelperValStmt = buildPreInits(Context, Captures);
 }
   }


Index: clang/test/OpenMP/dispatch_ast_print.cpp
===
--- clang/test/OpenMP/dispatch_ast_print.cpp
+++ clang/test/OpenMP/dispatch_ast_print.cpp
@@ -56,6 +56,9 @@
   //DUMP: OMPDependClause
   //DUMP: OMPNowaitClause
   //DUMP: OMPNovariantsClause
+  //DUMP: DeclRefExpr {{.*}} 'bool' lvalue OMPCapturedExpr
+  //DUMP: OMPNocontextClause
+  //DUMP: DeclRefExpr {{.*}} 'bool' lvalue OMPCapturedExpr
   #pragma omp dispatch depend(in:var) nowait novariants(aaa > 5) nocontext(bbb > 5)
   foo(aaa, );
 
@@ -66,6 +69,9 @@
   //DUMP: OMPDeviceClause
   //DUMP: OMPIs_device_ptrClause
   //DUMP: OMPNovariantsClause
+  //DUMP: DeclRefExpr {{.*}} 'bool' lvalue OMPCapturedExpr
+  //DUMP: OMPNocontextClause
+  //DUMP: DeclRefExpr {{.*}} 'bool' lvalue OMPCapturedExpr
   #pragma omp dispatch device(dev) is_device_ptr(dp) novariants(dev > 10) nocontext(dev > 5)
   foo(aaa, dp);
 
Index: clang/lib/Sema/SemaOpenMP.cpp
===
--- clang/lib/Sema/SemaOpenMP.cpp
+++ clang/lib/Sema/SemaOpenMP.cpp
@@ -14905,6 +14905,7 @@
 if (CaptureRegion != OMPD_unknown && !CurContext->isDependentContext()) {
   ValExpr = MakeFullExpr(ValExpr).get();
   llvm::MapVector Captures;
+  ValExpr = tryBuildCapture(*this, ValExpr, Captures).get();
   HelperValStmt = buildPreInits(Context, Captures);
 }
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D100051: [clang] Move int <-> float scalar conversion to a separate function

2021-04-07 Thread Saurabh Jha via Phabricator via cfe-commits
SaurabhJha added a comment.

In D100051#2674674 , @erichkeane 
wrote:

> Hrmph... Phab ate my other comment, which was that the name 
> `EmitCastBetweenScalarTypes` feels clunky.  Does `EmitScalarCast` or 
> `EmitScalarScalarCast` sound better and capture the meaning correctly?

Yeah, good idea. I'll rename it to `EmitScalarCast`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100051

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


[PATCH] D100037: [clang][UBSan] Passing underaligned pointer as a function argument is undefined behaviour

2021-04-07 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri added a comment.

In D100037#2674610 , @rsmith wrote:

>> This is somewhat related to the following RFC by @rjmccall:
>> https://lists.llvm.org/pipermail/llvm-dev/2016-January/094012.html
>
> It looks to me like this direction is in conflict with that RFC. In 
> particular, it says:
>
>> It is not undefined behavior to create a pointer that is less aligned
>>  than its pointee type.  Instead, it is only undefined behavior to
>>  access memory through a pointer that is less aligned than its pointee
>>  type.
>
> ... and gives as an example that passing an underaligned pointer to a 
> function that doesn't perform an underaligned access is OK under the proposed 
> rule.

Yes. We now have a motivational reason to do so, it wouldn't be "just expose 
the UB for the sake of miscompiling the program".

> Putting this behind a `-fstrict-*` flag (as this patch does) seems OK to me, 
> but I think enabling it by default on any target would be inconsistent with 
> the RFC and would need broader discussion and a change in policy.

I suppose so.

> I think it is reasonable to add stricter UBSan checks for underaligned 
> pointers, but that should be available regardless of what properties our 
> implementation happens to treat as defined; part of the point of UBSan is to 
> check for portability issues and to check whether problems would arise as a 
> prerequisite for enabling the corresponding `-fstrict` flag. So I do not 
> think the checks should be gated behind the `-fstrict` flag. I don't think 
> this is analogous to `-fwrapv`, which actually opts into a different set of 
> language rules where integer overflow is defined; this is more like 
> `-fstrict-enums`, for which we will still sanitize even in cases where we 
> happen to choose to not optimize, or the sanitizer for floating-point 
> division by zero, for which we still sanitize (because it's formally UB) but 
> don't include in `-fsanitize=undefined` (because our implementation defines 
> it). Generally-speaking, things controlled by `-fstrict-*` flags are checked 
> by UBSan and in particular by `-fsanitize=undefined` regardless of whether 
> the `-fstrict-*` flag is specified, and I think there are some cases where 
> `-fsanitize=undefined` already diagnoses misalignment that is valid under 
> John's RFC, so adding the new checks to the `-fsanitize=undefined` sanitizer 
> group (regardless of `-fstrict`) seems consistent to me.

Aha. I was also very uneasy about doing the check behind the `-fstrict`.
Will change it to be unconditional!

> If we want to add a sanitizer that checks for misaligned pointers existing, 
> instead of checking (as our current alignment sanitizer does) for misaligned 
> accesses, then I think it would be more precise (and add a lot fewer checks) 
> to enforce the language rule as written, that is, check for pointer and 
> reference casts to a more-aligned type, rather than checking function 
> arguments. I assume your intent here is to eventually add LLVM parameter 
> attributes indicating the function argument is correctly-aligned, which is 
> why you're checking on call boundaries?

It's complicated. I would like this to be more strict, and catch any misaligned 
pointers, yes.
But, two things:

1. it's going to be much more noisy than only dealing with function arguments :)
2. even if we are okay with that, handling this *just* on the callers side 
(when the pointer is created) is a wrong solution here. we still need to do 
this on the callee side. because we can't be sure that the caller will be 
compiled with sanitizer, but we *know* that the callee will be micompiled by us.

So at most i could handle it in more cases, but this one should stay..
Does this make sense?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100037

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


[PATCH] D100037: [clang][UBSan] Passing underaligned pointer as a function argument is undefined behaviour

2021-04-07 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added a comment.

> Let's first give users tools to weed out the cases where the pointer
> passed into function's argument is underaligned.

Isn't there already `-Walign-mismatch` in clang?  We definitely have 1 
unresolved case of that affecting the Linux kernel ATM: 
https://github.com/ClangBuiltLinux/linux/issues/1328




Comment at: clang/docs/ReleaseNotes.rst:52
+  however, there's interest in doing so now.
+  A new ``-fstrict-pointer-alignment`` flag was introduces (default on), which
+  will guard these new optimizations in the future, and allow disabling them.

s/was//


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100037

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


[PATCH] D100051: [clang] Move int <-> float scalar conversion to a separate function

2021-04-07 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added a comment.

Hrmph... Phab ate my other comment, which was that the name 
`EmitCastBetweenScalarTypes` feels clunky.  Does `EmitScalarCast` or 
`EmitScalarScalarCast` sound better and capture the meaning correctly?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100051

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


[PATCH] D100051: [clang] Move int <-> float scalar conversion to a separate function

2021-04-07 Thread Erich Keane via Phabricator via cfe-commits
erichkeane added inline comments.



Comment at: clang/lib/CodeGen/CGExprScalar.cpp:1209
+if (isa(DstTy))
+  Res = Builder.CreateIntCast(Src, DstTy, InputSigned, "conv");
+else if (InputSigned)

fhahn wrote:
> now that' this is a separate function, we should be able to just return the 
> created value directly, right? There should be no need for `Res`
Yep, I'd also prefer multiple returns. That also cleans up a bunch of hte 
'else's in this function.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100051

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


[PATCH] D99996: [Driver] Drop $DEFAULT_TRIPLE-$name as a fallback program name

2021-04-07 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.

In D6#2673276 , @sylvestre.ledru 
wrote:

> To understand better, we will be fixing a bug from 2015, correct?

Yes.

In D6#2674407 , @arichardson wrote:

> I believe adding the default triple is causing the wrong linker to be 
> selected for me when compiling with -m32, so I'd be happy for this code to be 
> removed.

Yes...

In D6#2674495 , @srhines wrote:

> Adding Dan as an FYI. While this doesn't impact Android platform or regular 
> NDK users, I suppose that someone could have some esoteric build rules that 
> are relying on this, but they should probably be more explicit about what 
> they're running in those cases anyways.

The 2015 behavior is that a `--target=aarch64-linux-gnu` cross compile may pick 
up `x86_64-unknown-linux-gnu-{as,ld,gcc}`. First most Linux programs should be 
named `x86_64-linux-gnu-*`.
Second `x86_64-unknown-linux-gnu-{as,ld,gcc}`, even if exists, is unlikely to 
handle aarch64-linux-gnu builds... So the case should be very rare.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D6

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


[PATCH] D100051: [clang] Move int <-> float scalar conversion to a separate function

2021-04-07 Thread Florian Hahn via Phabricator via cfe-commits
fhahn added reviewers: rsmith, erichkeane.
fhahn added inline comments.



Comment at: clang/lib/CodeGen/CGExprScalar.cpp:1209
+if (isa(DstTy))
+  Res = Builder.CreateIntCast(Src, DstTy, InputSigned, "conv");
+else if (InputSigned)

now that' this is a separate function, we should be able to just return the 
created value directly, right? There should be no need for `Res`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100051

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


[PATCH] D99994: [CodeView] Add CodeView support for PGO debug information

2021-04-07 Thread Amy Huang via Phabricator via cfe-commits
akhuang added a comment.

think this looks good overall; maybe it should also have an IR to codeview test?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D4

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


[PATCH] D100054: Handle flags such as -m32 when computing the triple prefix for programs

2021-04-07 Thread Alexander Richardson via Phabricator via cfe-commits
arichardson created this revision.
arichardson added reviewers: MaskRay, phosek.
Herald added subscribers: frasercrmck, luismarques, apazos, sameer.abuasal, 
pengfei, s.egerton, Jim, jocewei, PkmX, the_o, brucehoult, MartinMosbeck, 
rogfer01, edward-jones, zzheng, jrtc27, niosHD, sabuasal, simoncook, johnrusso, 
rbar, asb, krytarowski, emaste.
arichardson requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

I was trying to use -DLLVM_ENABLE_RUNTIMES=compiler-rt on FreeBSD and this
failed since the 32-bit build ended up linking against the 64-bit ASAN
runtime and linking with "/usr/local/bin/x86_64-unknown-freebsd12.2-ld".
Looking at the driver code shows that the triple used as a prefix for tools
and libaries is always the raw value passed to -target and is not affected
by flags such as -m32/-march/etc.

This commit uses computeTargetTriple() to update the triple used as a
prefix for tools such as the linker. If computeTargetTriple() results in
a different triple, we update the RawTargetTriple and now search for
i386-unknown-freebsd12.2-ld when -m32 is passed. It is important to note
that we do not normalize the triple passed to -target since adding
additional could result in an unexpected behaviour change. For example,
`clang -target x86_64-freebsd13` should search for x86_64-freebsd13-ld
and not the normalized x86_64-unknown-freebsd13-ld and
`clang -target x86_64-freebsd13 -m32` tries to find i386-unknown-freebsd13-ld.

Depends on D6  (not functionally, but 
required to compile correctly)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100054

Files:
  clang/include/clang/Driver/Driver.h
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/BareMetal.cpp
  clang/lib/Driver/ToolChains/RISCVToolchain.cpp
  
clang/test/Driver/Inputs/basic_freebsd64_tree/usr/bin/i386-unknown-freebsd12.2-ld
  
clang/test/Driver/Inputs/basic_freebsd64_tree/usr/bin/x86_64-unknown-freebsd12.2-ld
  clang/test/Driver/freebsd-m32.c

Index: clang/test/Driver/freebsd-m32.c
===
--- /dev/null
+++ clang/test/Driver/freebsd-m32.c
@@ -0,0 +1,52 @@
+// Check that building with -m32 links with x86_64-unknown-freebsd12.2-ld
+// instead of x86_64-unknown-freebsd12.2-ld.
+
+/// We should select x86_64-unknown-freebsd12.2-ld since it matches the triple argument
+/// Note: The paths specified by -B are not searched for triple-prefixed tools, so
+/// we also have to set $PATH.
+// RUN: env PATH=%S/Inputs/basic_freebsd64_tree/usr/bin %clang -no-canonical-prefixes \
+// RUN:   -target x86_64-unknown-freebsd12.2 %s \
+// RUN:   -B%S/Inputs/basic_freebsd64_tree/usr/bin -### 2>&1 | FileCheck %s --check-prefix=PREFIXED-64
+// PREFIXED-64: "-cc1" "-triple" "x86_64-unknown-freebsd12.2"
+// PREFIXED-64-NEXT: "{{.+}}/Inputs/basic_freebsd64_tree/usr/bin/x86_64-unknown-freebsd12.2-ld" "--eh-frame-hdr"
+// RUN: env PATH=/this/path/does/not/exist %clang -no-canonical-prefixes \
+// RUN:   -target x86_64-unknown-freebsd12.2 %s \
+// RUN:   -B%S/Inputs/basic_freebsd64_tree/usr/bin -### 2>&1 | FileCheck %s --check-prefix=MINUS-B-NO-TRIPLE-PREFIX
+// MINUS-B-NO-TRIPLE-PREFIX: "-cc1" "-triple" "x86_64-unknown-freebsd12.2"
+// MINUS-B-NO-TRIPLE-PREFIX-NEXT: "ld" "--eh-frame-hdr"
+
+/// The triple passed to clang -cc1 should be normalized, but the prefix when searching
+/// for ld should not be normalized. Since there is no x86_64-freebsd12.2-ld, passing
+/// -target x86_64-freebsd12.2 should not find a a valid linker:
+// RUN: env PATH=%S/Inputs/basic_freebsd64_tree/usr/bin %clang -no-canonical-prefixes \
+// RUN:   -target x86_64-freebsd12.2 %s \
+// RUN:   -B%S/Inputs/basic_freebsd64_tree/usr/bin -### 2>&1 | FileCheck %s --check-prefix=NO-NORMALIZE-LD-PREFIX-64
+// NO-NORMALIZE-LD-PREFIX-64: "-cc1" "-triple" "x86_64-unknown-freebsd12.2"
+// NO-NORMALIZE-LD-PREFIX-64: "ld" "--eh-frame-hdr"
+
+/// We should search for i386-unknown-freebsd12.2-ld when -m32 is passed:
+// RUN: env PATH=%S/Inputs/basic_freebsd64_tree/usr/bin %clang -no-canonical-prefixes \
+// RUN:   -target x86_64-unknown-freebsd12.2 %s -m32 \
+// RUN:   -B%S/Inputs/basic_freebsd64_tree/usr/bin -### 2>&1  | FileCheck %s --check-prefix=PREFIXED-M32
+// PREFIXED-M32: "-cc1" "-triple" "i386-unknown-freebsd12.2"
+// PREFIXED-M32-NEXT: "{{.+}}/Inputs/basic_freebsd64_tree/usr/bin/i386-unknown-freebsd12.2-ld" "--eh-frame-hdr"
+/// Only the -cc1 triple should be normalized even when adjusted by -m32:
+// RUN: env PATH=%S/Inputs/basic_freebsd64_tree/usr/bin %clang -no-canonical-prefixes \
+// RUN:   -target x86_64-freebsd12.2 %s -m32 \
+// RUN:   -B%S/Inputs/basic_freebsd64_tree/usr/bin -### 2>&1 | FileCheck %s --check-prefix=NO-NORMALIZE-LD-PREFIX-M32
+// NO-NORMALIZE-LD-PREFIX-M32: "-cc1" "-triple" "i386-unknown-freebsd12.2"
+// NO-NORMALIZE-LD-PREFIX-M32-NEXT: "ld" "--eh-frame-hdr"
+
+/// Check 

[PATCH] D100037: [clang][UBSan] Passing underaligned pointer as a function argument is undefined behaviour

2021-04-07 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

> This is somewhat related to the following RFC by @rjmccall:
> https://lists.llvm.org/pipermail/llvm-dev/2016-January/094012.html

It looks to me like this direction is in conflict with that RFC. In particular, 
it says:

> It is not undefined behavior to create a pointer that is less aligned
>  than its pointee type.  Instead, it is only undefined behavior to
>  access memory through a pointer that is less aligned than its pointee
>  type.

... and gives as an example that passing an underaligned pointer to a function 
that doesn't perform an underaligned access is OK under the proposed rule. 
Putting this behind a `-fstrict-*` flag (as this patch does) seems OK to me, 
but I think enabling it by default on any target would be inconsistent with the 
RFC and would need broader discussion and a change in policy.

I think it is reasonable to add stricter UBSan checks for underaligned 
pointers, but that should be available regardless of what properties our 
implementation happens to treat as defined; part of the point of UBSan is to 
check for portability issues and to check whether problems would arise as a 
prerequisite for enabling the corresponding `-fstrict` flag. So I do not think 
the checks should be gated behind the `-fstrict` flag. I don't think this is 
analogous to `-fwrapv`, which actually opts into a different set of language 
rules where integer overflow is defined; this is more like `-fstrict-enums`, 
for which we will still sanitize even in cases where we happen to choose to not 
optimize, or the sanitizer for floating-point division by zero, for which we 
still sanitize (because it's formally UB) but don't include in 
`-fsanitize=undefined` (because our implementation defines it). 
Generally-speaking, things controlled by `-fstrict-*` flags are checked by 
UBSan and in particular by `-fsanitize=undefined` regardless of whether the 
`-fstrict-*` flag is specified, and I think there are some cases where 
`-fsanitize=undefined` already diagnoses misalignment that is valid under 
John's RFC, so adding the new checks to the `-fsanitize=undefined` sanitizer 
group (regardless of `-fstrict`) seems consistent to me.

If we want to add a sanitizer that checks for misaligned pointers existing, 
instead of checking (as our current alignment sanitizer does) for misaligned 
accesses, then I think it would be more precise (and add a lot fewer checks) to 
enforce the language rule as written, that is, check for pointer and reference 
casts to a more-aligned type, rather than checking function arguments. I assume 
your intent here is to eventually add LLVM parameter attributes indicating the 
function argument is correctly-aligned, which is why you're checking on call 
boundaries?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100037

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


[clang] 028092e - Correct the tablegen logic for MutualExclusions attribute checking.

2021-04-07 Thread Aaron Ballman via cfe-commits

Author: Aaron Ballman
Date: 2021-04-07T14:04:08-04:00
New Revision: 028092eb613e5553ce0833878e7d36fcaf11fcb2

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

LOG: Correct the tablegen logic for MutualExclusions attribute checking.

Just because an attribute is a statement attribute doesn't mean it's
not also a declaration attribute. In Clang, there are not currently any
DeclOrStmtAttr attributes that require mutual exclusion checking, but
downstream clients discovered this issue.

Added: 


Modified: 
clang/utils/TableGen/ClangAttrEmitter.cpp

Removed: 




diff  --git a/clang/utils/TableGen/ClangAttrEmitter.cpp 
b/clang/utils/TableGen/ClangAttrEmitter.cpp
index 6b76ad8ccc0d1..ececceb5d3fd4 100644
--- a/clang/utils/TableGen/ClangAttrEmitter.cpp
+++ b/clang/utils/TableGen/ClangAttrEmitter.cpp
@@ -3644,10 +3644,12 @@ static void GenerateMutualExclusionsChecks(const Record 
,
   if (Attr.isSubClassOf("TypeAttr"))
 return;
 
-  // This means the attribute is either a statement attribute or a decl
-  // attribute, find out which.
+  // This means the attribute is either a statement attribute, a decl
+  // attribute, or both; find out which.
   bool CurAttrIsStmtAttr =
   Attr.isSubClassOf("StmtAttr") || Attr.isSubClassOf("DeclOrStmtAttr");
+  bool CurAttrIsDeclAttr =
+  !CurAttrIsStmtAttr || Attr.isSubClassOf("DeclOrStmtAttr");
 
   std::vector DeclAttrs, StmtAttrs;
 
@@ -3666,7 +3668,7 @@ static void GenerateMutualExclusionsChecks(const Record 
,
 
 if (CurAttrIsStmtAttr)
   StmtAttrs.push_back((AttrToExclude->getName() + "Attr").str());
-else
+if (CurAttrIsDeclAttr)
   DeclAttrs.push_back((AttrToExclude->getName() + "Attr").str());
   }
 }



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


[PATCH] D100037: [clang][UBSan] Passing underaligned pointer as a function argument is undefined behaviour

2021-04-07 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri updated this revision to Diff 335872.
lebedev.ri added a comment.

Fix usage of clang function argument -> llvm function argument mapping reading.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100037

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/docs/ReleaseNotes.rst
  clang/docs/UsersManual.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/catch-function-pointer-argument-alignment.cpp
  compiler-rt/lib/ubsan/ubsan_handlers.cpp
  compiler-rt/test/ubsan/TestCases/Pointer/function-pointer-argument.cpp

Index: compiler-rt/test/ubsan/TestCases/Pointer/function-pointer-argument.cpp
===
--- /dev/null
+++ compiler-rt/test/ubsan/TestCases/Pointer/function-pointer-argument.cpp
@@ -0,0 +1,30 @@
+// RUN: %clang   -x c   -fsanitize=alignment -O0 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+// RUN: %clang   -x c   -fsanitize=alignment -O1 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+// RUN: %clang   -x c   -fsanitize=alignment -O2 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+// RUN: %clang   -x c   -fsanitize=alignment -O3 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+
+// RUN: %clang   -x c++ -fsanitize=alignment -O0 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+// RUN: %clang   -x c++ -fsanitize=alignment -O1 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+// RUN: %clang   -x c++ -fsanitize=alignment -O2 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+// RUN: %clang   -x c++ -fsanitize=alignment -O3 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+
+#include 
+
+struct S {
+  int k;
+} __attribute__((aligned(8192)));
+
+void take_pointer_to_overaligned_struct(struct S *x) {
+}
+
+int main(int argc, char *argv[]) {
+  char *ptr = (char *)malloc(2 * sizeof(struct S));
+
+  take_pointer_to_overaligned_struct((struct S *)(ptr + 1));
+  // CHECK: {{.*}}function-pointer-argument.cpp:[[@LINE-7]]:51: runtime error: function pointer argument has misaligned address {{.*}} for type 'struct S', which requires 8192 byte alignment
+  // CHECK: 0x{{.*}}: note: pointer points here
+
+  free(ptr);
+
+  return 0;
+}
Index: compiler-rt/lib/ubsan/ubsan_handlers.cpp
===
--- compiler-rt/lib/ubsan/ubsan_handlers.cpp
+++ compiler-rt/lib/ubsan/ubsan_handlers.cpp
@@ -73,15 +73,25 @@
   TCK_NonnullAssign,
   /// Checking the operand of a dynamic_cast or a typeid expression.  Must be
   /// null or an object within its lifetime.
-  TCK_DynamicOperation
+  TCK_DynamicOperation,
+  /// Checking the alignment of the function's pointer argument.
+  TCK_FunctionPointerArgument
 };
 
-const char *TypeCheckKinds[] = {
-"load of", "store to", "reference binding to", "member access within",
-"member call on", "constructor call on", "downcast of", "downcast of",
-"upcast of", "cast to virtual base of", "_Nonnull binding to",
-"dynamic operation on"};
-}
+const char *TypeCheckKinds[] = {"load of",
+"store to",
+"reference binding to",
+"member access within",
+"member call on",
+"constructor call on",
+"downcast of",
+"downcast of",
+"upcast of",
+"cast to virtual base of",
+"_Nonnull binding to",
+"dynamic operation on",
+"function pointer argument has"};
+} // namespace __ubsan
 
 static void handleTypeMismatchImpl(TypeMismatchData *Data, ValueHandle Pointer,
ReportOptions Opts) {
Index: clang/test/CodeGen/catch-function-pointer-argument-alignment.cpp
===
--- /dev/null
+++ 

[PATCH] D89909: [SYCL] Implement SYCL address space attributes handling

2021-04-07 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia added inline comments.



Comment at: clang/include/clang/AST/Type.h:493
+   // Default is a superset of SYCL address spaces.
+   (A == LangAS::Default &&
+(B == LangAS::sycl_private || B == LangAS::sycl_local ||

Ok if you allow implicit conversions both ways then this condition should be 
extended to also contain all named address spaces in `A` and `Default` in `B`. 
But actually, could you simplify by checking that you have `Default` on either 
side, so something like 


```
(A == LangAS::Default || B == LangAS::Default)
```
?



Comment at: clang/lib/AST/ItaniumMangle.cpp:2379
   unsigned TargetAS = Context.getASTContext().getTargetAddressSpace(AS);
-  if (TargetAS != 0)
+  if (TargetAS != 0 || Context.getASTContext().getLangOpts().SYCLIsDevice)
 ASString = "AS" + llvm::utostr(TargetAS);

Any reason not to use OpenCL mangling? If you do then you might be able to link 
against libraries compiled for OpenCL. Also you will get more stable naming 
i.e. it would not differ from target to target. 



Comment at: clang/lib/Basic/Targets/AMDGPU.cpp:74
 Local,// cuda_shared
+Global,   // sycl_global
+Local,// sycl_local

Would this map ever be used for SYCL? If not it would be better to add a 
comment about it and/or perhaps even just use dummy values.



Comment at: clang/lib/Basic/Targets/SPIR.h:36
 0, // cuda_shared
+1, // sycl_global
+3, // sycl_local

The same here. This map will never work for SYCL so let's just use dummy values 
like for CUDA and add a comment explaining this.



Comment at: clang/lib/Basic/Targets/SPIR.h:71
 LongWidth = LongAlign = 64;
-AddrSpaceMap = 
+AddrSpaceMap = Triple.getEnvironment() == llvm::Triple::SYCLDevice
+   ? 

Ok so what I understand is that the only reason you need a separate map is that 
the semantics of `Default` is different for SYCL than for C/C++.

//i.e. in SYCL (i.e. inherited from CUDA) it is a virtual/placeholder address 
space that can point to any of the named address spaces while in embedded C it 
is a physical address space which is the same as automatic storage / flat 
address space.//

Since originally CUDA was not intended to compile for the same targets as C or 
C++ it hasn't been an issue as there was some sort of separation of concerns. 
But with wider adoption, it seems that this separation no longer exists and any 
target supporting CUDA style address space semantic together with C style would 
need to duplicate the address space map. This is not ideal especially 
considering the number of entities it contains and their constant growth. In 
reality, at least there won't be many such targets but if SYCL intends to 
support targets that OpenCL does then it is not uncommon. For example CPU 
targets can compile both OpenCL and C/C++...

If we adhere to the current architecture we should have C's `Default` and 
CUDA's `Default` as separate entries in the map. However, this might be quite 
an involved refactoring. Have you looked in this before? A less involved 
refactoring could be to add a special hook that would allow to alter the 
address space mapping only for Default address space. I am not sure whether 
this is something we could add to Targets, although it seems to be driven by 
the language semantic. Anyway we can't decide this in this review as it 
requires other community member involvement.

Considering that the workaround is relatively simple I think it would be 
reasonable to accept it as an initial step. However, I would prefer to simplify 
this patch further by removing the environment component for the time being and 
just conditionalizing the map on the language mode instead. You will probably 
need to reset the map in `TargetInfo:adjust` because this is where we have 
access to `LangOpts`.

https://clang.llvm.org/doxygen/Basic_2TargetInfo_8cpp_source.html#l00347

We already override lots of settings there and hopefully, this will only be 
needed temporarily. I would add a FIXME comment there explaining the design 
issue.

Then you won’t need to extend the triple component at least for now, until we 
find the right architectural solution for this. As I am not convinced this is a 
good approach. I would suggest to follow up on cfe-dev regarding this issue and 
how we should address this in the long term. Ideally, we should have started 
from this but I understand that you have some timing constraints.




Comment at: clang/lib/Basic/Targets/SPIR.h:123
+// If we assign "opencl_constant" address space the following code becomes
+// illegal, because it can't be cast to any other address space:
+//

Should the following code be legal? Perhaps you can replace this with a spec 
reference instead?



Comment 

[PATCH] D99645: [flang][driver] Add debug options not requiring semantic checks

2021-04-07 Thread Kiran Chandramohan via Phabricator via cfe-commits
kiranchandramohan accepted this revision.
kiranchandramohan added a comment.

LGTM.

Might be good to have a test for fdebug-dump-parse-tree-no-sema.




Comment at: flang/include/flang/Frontend/FrontendOptions.h:54
 
+  /// Parse, run semantics and then output the parse tree, skip the semantic
+  /// checks

Nit: semantics are not run here, i guess.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99645

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


[PATCH] D99996: [Driver] Drop $DEFAULT_TRIPLE-$name as a fallback program name

2021-04-07 Thread Stephen Hines via Phabricator via cfe-commits
srhines added a comment.

Adding Dan as an FYI. While this doesn't impact Android platform or regular NDK 
users, I suppose that someone could have some esoteric build rules that are 
relying on this, but they should probably be more explicit about what they're 
running in those cases anyways.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D6

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


[PATCH] D99996: [Driver] Drop $DEFAULT_TRIPLE-$name as a fallback program name

2021-04-07 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers accepted this revision.
nickdesaulniers added a comment.

I don't foresee this affecting Linux kernel builds.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D6

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


[PATCH] D98856: Always emit error for wrong interfaces to scalable vectors, unless cmdline flag is passed.

2021-04-07 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:5066
+CmdArgs.push_back("-mllvm");
+CmdArgs.push_back("-treat-scalable-fixed-error-as-warning");
+  }

sdesmalen wrote:
> MaskRay wrote:
> > Does this introduce an option in the CC1 command line for most cases? We 
> > should shorten the CC1 command line for common cases...
> The option is purely temporary and will be removed in the future. I guess it 
> depends on the meaning of the word 'common' in this context, but it enables 
> experimental use of Clang for scalable vectors, which is common if the 
> targets support them. We'd like to remove this flag sooner rather than later, 
> although there is work involved in LLVM before we can remove it.
> 
> Are you specifically concerned with the length (as in: number of characters) 
> of the cc1 command?
> Are you specifically concerned with the length (as in: number of characters) 
> of the cc1 command?

Yes.

I looked at a random SVE unrelated `clang -###` and found this option... Now I 
tried again and can't find the option now. Reducing CC1 length without making 
internal implementation difficult is generally good.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D98856

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


[PATCH] D99037: [Matrix] Implement C-style explicit type conversions for matrix types

2021-04-07 Thread Saurabh Jha via Phabricator via cfe-commits
SaurabhJha added a comment.

> I think the issue might be that adding this additional cast-kind caused the 
> value to exceed the maximum supported by the `CastExprBitfields`; the 
> bitfield can only store 64 values, but after adding `MatrixCast`, 
> `CK_IntToOCLSampler` will have value `64`, so assigning to the bitfield 
> results in `0` being assigned. I *think* you have to bump the bitfield size 
> to 7 or perhaps 8 (which may result in slightly better codegen). 
> https://github.com/llvm/llvm-project/blob/main/clang/include/clang/AST/Stmt.h#L521

This worked. Setting it to 7 made the tests pass.

I have created a separate patch for codegen refactoring here 
https://reviews.llvm.org/D100051. Once that's merged, I can rebase this 
patch/branch against that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99037

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


[PATCH] D100051: [clang] Move int <-> float scalar conversion to a separate function

2021-04-07 Thread Saurabh Jha via Phabricator via cfe-commits
SaurabhJha created this revision.
SaurabhJha requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

As prelude to this patch https://reviews.llvm.org/D99037, we want to move the 
int-float conversion
into a separate function that can be reused by matrix cast


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100051

Files:
  clang/lib/CodeGen/CGExprScalar.cpp


Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -348,6 +348,10 @@
   EmitImplicitIntegerSignChangeChecks(
   SanOpts.has(SanitizerKind::ImplicitIntegerSignChange)) {}
   };
+  Value *EmitCastBetweenScalarTypes(Value *Src, QualType SrcType,
+QualType DstType, llvm::Type *SrcTy,
+llvm::Type *DstTy,
+ScalarConversionOpts Opts);
   Value *
   EmitScalarConversion(Value *Src, QualType SrcTy, QualType DstTy,
SourceLocation Loc,
@@ -1191,6 +1195,38 @@
 {Src, Dst});
 }
 
+Value *ScalarExprEmitter::EmitCastBetweenScalarTypes(
+Value *Src, QualType SrcType, QualType DstType, llvm::Type *SrcTy,
+llvm::Type *DstTy, ScalarConversionOpts Opts) {
+  Value *Res = nullptr;
+
+  if (isa(SrcTy)) {
+bool InputSigned = SrcType->isSignedIntegerOrEnumerationType();
+if (SrcType->isBooleanType() && Opts.TreatBooleanAsSigned) {
+  InputSigned = true;
+}
+if (isa(DstTy))
+  Res = Builder.CreateIntCast(Src, DstTy, InputSigned, "conv");
+else if (InputSigned)
+  Res = Builder.CreateSIToFP(Src, DstTy, "conv");
+else
+  Res = Builder.CreateUIToFP(Src, DstTy, "conv");
+  } else if (isa(DstTy)) {
+assert(SrcTy->isFloatingPointTy() && "Unknown real conversion");
+if (DstType->isSignedIntegerOrEnumerationType())
+  Res = Builder.CreateFPToSI(Src, DstTy, "conv");
+else
+  Res = Builder.CreateFPToUI(Src, DstTy, "conv");
+  } else {
+if (DstTy->getTypeID() < SrcTy->getTypeID())
+  Res = Builder.CreateFPTrunc(Src, DstTy, "conv");
+else
+  Res = Builder.CreateFPExt(Src, DstTy, "conv");
+  }
+
+  return Res;
+}
+
 /// Emit a conversion from the specified type to the specified destination 
type,
 /// both of which are LLVM scalar types.
 Value *ScalarExprEmitter::EmitScalarConversion(Value *Src, QualType SrcType,
@@ -1384,31 +1420,7 @@
 DstTy = CGF.FloatTy;
   }
 
-  if (isa(SrcTy)) {
-bool InputSigned = SrcType->isSignedIntegerOrEnumerationType();
-if (SrcType->isBooleanType() && Opts.TreatBooleanAsSigned) {
-  InputSigned = true;
-}
-if (isa(DstTy))
-  Res = Builder.CreateIntCast(Src, DstTy, InputSigned, "conv");
-else if (InputSigned)
-  Res = Builder.CreateSIToFP(Src, DstTy, "conv");
-else
-  Res = Builder.CreateUIToFP(Src, DstTy, "conv");
-  } else if (isa(DstTy)) {
-assert(SrcTy->isFloatingPointTy() && "Unknown real conversion");
-if (DstType->isSignedIntegerOrEnumerationType())
-  Res = Builder.CreateFPToSI(Src, DstTy, "conv");
-else
-  Res = Builder.CreateFPToUI(Src, DstTy, "conv");
-  } else {
-assert(SrcTy->isFloatingPointTy() && DstTy->isFloatingPointTy() &&
-   "Unknown real conversion");
-if (DstTy->getTypeID() < SrcTy->getTypeID())
-  Res = Builder.CreateFPTrunc(Src, DstTy, "conv");
-else
-  Res = Builder.CreateFPExt(Src, DstTy, "conv");
-  }
+  Res = EmitCastBetweenScalarTypes(Src, SrcType, DstType, SrcTy, DstTy, Opts);
 
   if (DstTy != ResTy) {
 if (CGF.getContext().getTargetInfo().useFP16ConversionIntrinsics()) {


Index: clang/lib/CodeGen/CGExprScalar.cpp
===
--- clang/lib/CodeGen/CGExprScalar.cpp
+++ clang/lib/CodeGen/CGExprScalar.cpp
@@ -348,6 +348,10 @@
   EmitImplicitIntegerSignChangeChecks(
   SanOpts.has(SanitizerKind::ImplicitIntegerSignChange)) {}
   };
+  Value *EmitCastBetweenScalarTypes(Value *Src, QualType SrcType,
+QualType DstType, llvm::Type *SrcTy,
+llvm::Type *DstTy,
+ScalarConversionOpts Opts);
   Value *
   EmitScalarConversion(Value *Src, QualType SrcTy, QualType DstTy,
SourceLocation Loc,
@@ -1191,6 +1195,38 @@
 {Src, Dst});
 }
 
+Value *ScalarExprEmitter::EmitCastBetweenScalarTypes(
+Value *Src, QualType SrcType, QualType DstType, llvm::Type *SrcTy,
+llvm::Type *DstTy, ScalarConversionOpts Opts) {
+  Value *Res = nullptr;
+
+  if (isa(SrcTy)) {
+bool InputSigned = SrcType->isSignedIntegerOrEnumerationType();
+if (SrcType->isBooleanType() && Opts.TreatBooleanAsSigned) {
+  InputSigned = true;
+}
+if (isa(DstTy))
+  Res = 

[PATCH] D99580: [CLANG] [DebugInfo] Convert File name to native format

2021-04-07 Thread kamlesh kumar via Phabricator via cfe-commits
kamleshbhalui added a reviewer: rnk.
kamleshbhalui added a comment.

ping?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99580

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


[PATCH] D100045: [HIP] Fix rocm-detect.hip test path

2021-04-07 Thread Aaron Enye Shi via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGdf59850038d8: [HIP] Fix rocm-detect.hip test path (authored 
by ashi1).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Changed prior to commit:
  https://reviews.llvm.org/D100045?vs=335838=335860#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100045

Files:
  clang/test/Driver/rocm-detect.hip


Index: clang/test/Driver/rocm-detect.hip
===
--- clang/test/Driver/rocm-detect.hip
+++ clang/test/Driver/rocm-detect.hip
@@ -81,7 +81,7 @@
 
 // SPACK: ROCm installation search path (Spack 4.0.0): [[DIR:.*]]
 // SPACK: ROCm installation search path: [[CLANG:.*]]
-// SPACK: ROCm installation search path: [[CLANG]]/lib/clang/{{[0-9.]+}}
+// SPACK: ROCm installation search path: 
[[CLANG]]/{{(llvm/)?}}lib/clang/{{[0-9.]+}}
 // SPACK: ROCm installation search path: /opt/rocm
 // SPACK: InstalledDir: 
[[DIR]]/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/bin
 // SPACK: Found HIP installation: 
[[DIR]]/hip-4.0.0-5f63slrursbrvfe2txrrjkynbsywsob5, version 4.0.20214-a2917cd


Index: clang/test/Driver/rocm-detect.hip
===
--- clang/test/Driver/rocm-detect.hip
+++ clang/test/Driver/rocm-detect.hip
@@ -81,7 +81,7 @@
 
 // SPACK: ROCm installation search path (Spack 4.0.0): [[DIR:.*]]
 // SPACK: ROCm installation search path: [[CLANG:.*]]
-// SPACK: ROCm installation search path: [[CLANG]]/lib/clang/{{[0-9.]+}}
+// SPACK: ROCm installation search path: [[CLANG]]/{{(llvm/)?}}lib/clang/{{[0-9.]+}}
 // SPACK: ROCm installation search path: /opt/rocm
 // SPACK: InstalledDir: [[DIR]]/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/bin
 // SPACK: Found HIP installation: [[DIR]]/hip-4.0.0-5f63slrursbrvfe2txrrjkynbsywsob5, version 4.0.20214-a2917cd
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] df59850 - [HIP] Fix rocm-detect.hip test path

2021-04-07 Thread Aaron En Ye Shi via cfe-commits

Author: Aaron En Ye Shi
Date: 2021-04-07T17:20:59Z
New Revision: df59850038d800e8e8b062a5fc2e3d4ed624b526

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

LOG: [HIP] Fix rocm-detect.hip test path

The ROCm installation directory may be another
directory, llvm/ inside the build directory.

Reviewed By: yaxunl

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

Added: 


Modified: 
clang/test/Driver/rocm-detect.hip

Removed: 




diff  --git a/clang/test/Driver/rocm-detect.hip 
b/clang/test/Driver/rocm-detect.hip
index 1e21323ba218..5df5d2a9be06 100644
--- a/clang/test/Driver/rocm-detect.hip
+++ b/clang/test/Driver/rocm-detect.hip
@@ -81,7 +81,7 @@
 
 // SPACK: ROCm installation search path (Spack 4.0.0): [[DIR:.*]]
 // SPACK: ROCm installation search path: [[CLANG:.*]]
-// SPACK: ROCm installation search path: [[CLANG]]/lib/clang/{{[0-9.]+}}
+// SPACK: ROCm installation search path: 
[[CLANG]]/{{(llvm/)?}}lib/clang/{{[0-9.]+}}
 // SPACK: ROCm installation search path: /opt/rocm
 // SPACK: InstalledDir: 
[[DIR]]/llvm-amdgpu-4.0.0-ieagcs7inf7runpyfvepqkurasoglq4z/bin
 // SPACK: Found HIP installation: 
[[DIR]]/hip-4.0.0-5f63slrursbrvfe2txrrjkynbsywsob5, version 4.0.20214-a2917cd



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


[PATCH] D99996: [Driver] Drop $DEFAULT_TRIPLE-$name as a fallback program name

2021-04-07 Thread Alexander Richardson via Phabricator via cfe-commits
arichardson added a comment.

I believe adding the default triple is causing the wrong linker to be selected 
for me when compiling with -m32, so I'd be happy for this code to be removed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D6

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


[PATCH] D99526: [RISCV][Clang] Add RVV Widening Integer Add/Subtract intrinsic functions.

2021-04-07 Thread Craig Topper via Phabricator via cfe-commits
craig.topper accepted this revision.
craig.topper added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99526

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


[PATCH] D99669: [RISCV][Clang] Add more RVV Floating-Point intrinsic functions.

2021-04-07 Thread Craig Topper via Phabricator via cfe-commits
craig.topper accepted this revision.
craig.topper added a comment.
This revision is now accepted and ready to land.

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99669

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


[PATCH] D99409: [clang] Speedup line offset mapping computation

2021-04-07 Thread serge via Phabricator via cfe-commits
serge-sans-paille added inline comments.



Comment at: clang/lib/Basic/SourceManager.cpp:1262
+   unsigned char n) {
+  return ((x - ~0UL / 255 * (n + 1)) & ~x &
+  (x & ~0UL / 255 * 127) + ~0UL / 255 * (127 - (m - 1))) &

thakis wrote:
> UL is 32-bit on windows but 64-bit on linux/mac in 64-bit builds (LP64 vs 
> LLP64). Maybe you want 0ULL here?
> 
> If so, then you should be able to repro this on linux by building a 32-bit 
> clang binary there.
That + some endianess issue on ppc64be, resubmit coming soon once I validate 
locally :-)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99409

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


[PATCH] D100046: [AArch64] ACLE: Fix issue for mismatching enum types with builtins.

2021-04-07 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen added a comment.

The fact that Clang chooses to (explicitly) forget about a builtin in 
SemaDecl.cpp was quite puzzling to me. Maybe that just shows that I don't fully 
understand how the builtin mechanism is supposed to work.
@rsmith and @tambre, git history showed me you have more experience in this 
area and touched some of that code before, so hopefully you can give me some 
good feedback!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100046

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


[PATCH] D99669: [RISCV][Clang] Add more RVV Floating-Point intrinsic functions.

2021-04-07 Thread Zakk Chen via Phabricator via cfe-commits
khchen updated this revision to Diff 335846.
khchen marked 4 inline comments as done.
khchen added a comment.

address Craig's comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99669

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfnmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwnmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vfwsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmfeq.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmfge.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmfgt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmfle.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmflt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vmfne.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfnmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfnmadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfnmsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwmul.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwnmacc.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwnmsac.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vfwsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmfeq.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmfge.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmfgt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmfle.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmflt.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vmfne.c

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


[PATCH] D100046: [AArch64] ACLE: Fix issue for mismatching enum types with builtins.

2021-04-07 Thread Sander de Smalen via Phabricator via cfe-commits
sdesmalen created this revision.
Herald added subscribers: danielkiss, kristof.beyls.
sdesmalen requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This patch fixes an issue with the SVE prefetch and qinc/qdec intrinsics
that take an `enum` argument, but where the builtin prototype encodes
these as `int`. Some code in SemaDecl finds the mismatch, and chooses
to forget about the builtin altogether, which means that any future
code using that builtin will fail.

This patch fixes the issue by marking the builtin as 'T', which allows
for a type-mismatch, and then only discarding the builtin when
`allowTypeMismatch()` returns false.

This patch also fixes another issue with the SVE prefetch intrinsic
when built with C++, where the builtin didn't accept the correct
pointer type, which should be `const void *`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100046

Files:
  clang/include/clang/Basic/arm_sve.td
  clang/lib/Sema/SemaDecl.cpp
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfh.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_prfw.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qdecb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qdecd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qdech.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qdecp.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qdecw.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qincb.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qincd.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qinch.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qincp.c
  clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qincw.c
  clang/utils/TableGen/SveEmitter.cpp

Index: clang/utils/TableGen/SveEmitter.cpp
===
--- clang/utils/TableGen/SveEmitter.cpp
+++ clang/utils/TableGen/SveEmitter.cpp
@@ -1299,11 +1299,21 @@
 
   OS << "#ifdef GET_SVE_BUILTINS\n";
   for (auto  : Defs) {
+// If one of the arguments is an enum (e.g. svprfop) then avoid Clang
+// from doing the type-checking of the builtin-type with the C/C++
+// declaration, because we have to use 'int' for the builtin prototype,
+// which otherwise won't match.
+bool HasEnumPatternOperand =
+llvm::any_of(Def->getTypes(), [](const SVEType ) {
+  return T.isPredicatePattern() || T.isPrefetchOp();
+});
+
 // Only create BUILTINs for non-overloaded intrinsics, as overloaded
 // declarations only live in the header file.
 if (Def->getClassKind() != ClassG)
   OS << "BUILTIN(__builtin_sve_" << Def->getMangledName() << ", \""
- << Def->getBuiltinTypeStr() << "\", \"n\")\n";
+ << Def->getBuiltinTypeStr() << "\", \""
+ << (HasEnumPatternOperand ? "nT" : "n") << "\")\n";
   }
 
   // Add reinterpret builtins
Index: clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qincw.c
===
--- clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qincw.c
+++ clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qincw.c
@@ -1,6 +1,8 @@
 // REQUIRES: aarch64-registered-target
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - -x c++ %s | FileCheck %s
 // RUN: %clang_cc1 -DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - -x c++ %s | FileCheck %s
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -o - %s >/dev/null
 #include 
 
Index: clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qincp.c
===
--- clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qincp.c
+++ clang/test/CodeGen/aarch64-sve-intrinsics/acle_sve_qincp.c
@@ -1,6 +1,8 @@
 // REQUIRES: aarch64-registered-target
 // RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -triple aarch64-none-linux-gnu -target-feature +sve -fallow-half-arguments-and-returns -S -O1 -Werror -Wall -emit-llvm -o - -x c++ %s | FileCheck %s
 // RUN: %clang_cc1 -DSVE_OVERLOADED_FORMS -triple aarch64-none-linux-gnu -target-feature +sve 

[PATCH] D99526: [RISCV][Clang] Add RVV Widening Integer Add/Subtract intrinsic functions.

2021-04-07 Thread Zakk Chen via Phabricator via cfe-commits
khchen updated this revision to Diff 335840.
khchen added a comment.

align implementation to https://github.com/riscv/rvv-intrinsic-doc/pull/77.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99526

Files:
  clang/include/clang/Basic/riscv_vector.td
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vwadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics-overloaded/vwsub.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vwadd.c
  clang/test/CodeGen/RISCV/rvv-intrinsics/vwsub.c

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


[PATCH] D99646: [clang-tidy] misc-avoid-std-io-outside-main: a new check

2021-04-07 Thread Marco Gartmann via Phabricator via cfe-commits
mgartmann updated this revision to Diff 335839.
mgartmann added a comment.

Corrected check's entry in `list.rst` after renaming the check.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99646

Files:
  clang-tools-extra/clang-tidy/misc/AvoidStdIoOutsideMainCheck.cpp
  clang-tools-extra/clang-tidy/misc/AvoidStdIoOutsideMainCheck.h
  clang-tools-extra/clang-tidy/misc/CMakeLists.txt
  clang-tools-extra/clang-tidy/misc/MiscTidyModule.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  clang-tools-extra/docs/clang-tidy/checks/list.rst
  clang-tools-extra/docs/clang-tidy/checks/misc-avoid-std-io-outside-main.rst
  clang-tools-extra/test/clang-tidy/checkers/misc-avoid-std-io-outside-main.cpp

Index: clang-tools-extra/test/clang-tidy/checkers/misc-avoid-std-io-outside-main.cpp
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/misc-avoid-std-io-outside-main.cpp
@@ -0,0 +1,138 @@
+// RUN: %check_clang_tidy %s misc-avoid-std-io-outside-main %t
+
+namespace std {
+struct string {
+  string(const char *);
+  ~string();
+};
+
+struct Ostream {
+  Ostream <<(string Message);
+};
+
+struct Istream {
+  Istream >>(string Message);
+};
+
+Ostream cout{}, wcout{}, cerr{}, wcerr{};
+Istream cin{}, wcin{};
+
+int printf(const char *Format, ...);
+int vprintf(const char *const, ...);
+int puts(const char *Str);
+int putchar(int Character);
+int scanf(const char *Format, ...);
+int getchar(void);
+char *gets(char *Str);
+} // namespace std
+
+int printf(const char *Format, ...);
+int vprintf(const char *const, ...);
+int puts(const char *Str);
+int putchar(int Character);
+int scanf(const char *Format, ...);
+int getchar(void);
+char *gets(char *Str);
+
+namespace arbitrary_namespace {
+std::Ostream cout{};
+std::Istream cin{};
+} // namespace arbitrary_namespace
+
+void anyNonMainFunction() {
+  // CHECK-MESSAGES: :[[@LINE+1]]:8: warning: predefined standard stream objects should not be used outside the main function [misc-avoid-std-io-outside-main]
+  std::cout << "This should trigger the check";
+
+  // CHECK-MESSAGES: :[[@LINE+1]]:8: warning: predefined standard stream objects should not be used outside the main function [misc-avoid-std-io-outside-main]
+  std::wcout << "This should trigger the check";
+
+  // CHECK-MESSAGES: :[[@LINE+1]]:8: warning: predefined standard stream objects should not be used outside the main function [misc-avoid-std-io-outside-main]
+  std::cerr << "This should trigger the check";
+
+  // CHECK-MESSAGES: :[[@LINE+1]]:8: warning: predefined standard stream objects should not be used outside the main function [misc-avoid-std-io-outside-main]
+  std::wcerr << "This should trigger the check";
+
+  arbitrary_namespace::cout << "This should not trigger the check"; // OK
+
+  std::string Foo{"bar"};
+
+  // CHECK-MESSAGES: :[[@LINE+1]]:8: warning: predefined standard stream objects should not be used outside the main function [misc-avoid-std-io-outside-main]
+  std::cin >> Foo;
+
+  // CHECK-MESSAGES: :[[@LINE+1]]:8: warning: predefined standard stream objects should not be used outside the main function [misc-avoid-std-io-outside-main]
+  std::wcin >> Foo;
+
+  arbitrary_namespace::cin >> Foo; // OK
+
+  // CHECK-MESSAGES: :[[@LINE+1]]:8: warning: cstdio functions should not be used outside the main function [misc-avoid-std-io-outside-main]
+  std::printf("This should trigger the check");
+  // CHECK-MESSAGES: :[[@LINE+1]]:3: warning: cstdio functions should not be used outside the main function [misc-avoid-std-io-outside-main]
+  printf("This should trigger the check");
+
+  // CHECK-MESSAGES: :[[@LINE+1]]:8: warning: cstdio functions should not be used outside the main function [misc-avoid-std-io-outside-main]
+  std::puts("This should trigger the check");
+  // CHECK-MESSAGES: :[[@LINE+1]]:3: warning: cstdio functions should not be used outside the main function [misc-avoid-std-io-outside-main]
+  puts("This should trigger the check");
+
+  // CHECK-MESSAGES: :[[@LINE+1]]:8: warning: cstdio functions should not be used outside the main function [misc-avoid-std-io-outside-main]
+  std::putchar('m');
+  // CHECK-MESSAGES: :[[@LINE+1]]:3: warning: cstdio functions should not be used outside the main function [misc-avoid-std-io-outside-main]
+  putchar('m');
+
+  char Input[5];
+  // CHECK-MESSAGES: :[[@LINE+1]]:8: warning: cstdio functions should not be used outside the main function [misc-avoid-std-io-outside-main]
+  std::scanf("%s", Input);
+  // CHECK-MESSAGES: :[[@LINE+1]]:3: warning: cstdio functions should not be used outside the main function [misc-avoid-std-io-outside-main]
+  scanf("%s", Input);
+
+  // CHECK-MESSAGES: :[[@LINE+1]]:8: warning: cstdio functions should not be used outside the main function [misc-avoid-std-io-outside-main]
+  std::getchar();
+  // CHECK-MESSAGES: :[[@LINE+1]]:3: warning: cstdio functions should not be 

[PATCH] D99554: [ThinLTO] During module importing, close one source module before open another one for distributed mode.

2021-04-07 Thread Wenlei He via Phabricator via cfe-commits
wenlei added subscribers: weiwang, wenlei.
wenlei added a comment.

Does this help non-distributed ThinLTO as well? cc: @weiwang


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99554

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


[PATCH] D99353: [driver] Make `clang` warn rather then error on `flang` options

2021-04-07 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski added a comment.

In D99353#2672503 , @protze.joachim 
wrote:

> In D99353#2669046 , @awarzynski 
> wrote:
>
>> Btw, how important are these aliases for you?
>
> It's just not obvious from `flang --help` that this is an alias for 
> `-ffixed-line-length-132` (or the other way around). I only learned that by 
> looking at LLVM source.

It's the other way round :) `-ffixed-line-length-132` is an alias for 
`-ffixed-line-length=132`. If you run `flang-new --help`, then you will only 
see non-aliases. Hopefully that will help navigating this.

I don't have a solution for aliases, I'd need more time for this. Long term we 
should definitely aim for something more general, but for now I'd like to focus 
on making sure that:

- you are no longer blocked, and
- we are not introducing anything that could block/disable other important use 
cases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99353

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


[PATCH] D99645: [flang][driver] Add debug options not requiring semantic checks

2021-04-07 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski added inline comments.



Comment at: clang/include/clang/Driver/Options.td:4378
   HelpText<"Run the InputOuputTest action. Use for development and testing 
only.">;
+def fdebug_unparse_no_sema : Flag<["-"], "fdebug-unparse-no-sema">, 
Group,
+  HelpText<"Unparse and stop (skips the semantic checks)">;

awarzynski wrote:
> kiranchandramohan wrote:
> > Does this flag actually mean, parse and construct the parse-tree and 
> > unparse and stop?
> > 
> > While the current name is OK now, when the rest of the pipeline (codegen, 
> > linking etc) is there will it be an issue?
> > Does this flag actually mean, parse and construct the parse-tree and 
> > unparse and stop?
> 
> Yes
> 
> > While the current name is OK now, when the rest of the pipeline (codegen, 
> > linking etc) is there will it be an issue?
> IIUC, there shouldn't be any. Currently, the `-fdebug-unparse` options have 
> dedicated frontend actions 
> * `-fdebug-unparse` runs [[ 
> https://github.com/llvm/llvm-project/blob/main/flang/lib/Frontend/FrontendActions.cpp#L194-L208
>  | DebugUnparseAction ]]
> * `-fdebug-unparse-no-sema` will run `DebugUnparseNoSemaAction` (introduced 
> here)
> I don't see why we'd change these actions once codegen or linking are 
> available. That's something that will be implemented separately.
> 
> Does this help?
> 
> 
I added `DocBrief` descriptions to clarify the purpose of these options. Please 
note that currently these are not used anywhere. In Clang `DocBrief` 
descriptions are used to generate 
https://clang.llvm.org/docs/ClangCommandLineReference.html. We could set-up 
something similar for Flang.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99645

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


[PATCH] D99645: [flang][driver] Add debug options not requiring semantic checks

2021-04-07 Thread Andrzej Warzynski via Phabricator via cfe-commits
awarzynski updated this revision to Diff 335820.
awarzynski added a comment.

Add DocBrief descriptions in Options.td

I added the descriptions so that it's documented what the options are intended 
for and to avoid confusion in the future.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99645

Files:
  clang/include/clang/Driver/Options.td
  flang/include/flang/Frontend/FrontendActions.h
  flang/include/flang/Frontend/FrontendOptions.h
  flang/lib/Frontend/CompilerInvocation.cpp
  flang/lib/Frontend/FrontendActions.cpp
  flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
  flang/test/Driver/driver-help.f90
  flang/test/Parser/omp-allocate-unparse.f90
  flang/test/Parser/omp-atomic-unparse.f90
  flang/tools/f18/f18.cpp

Index: flang/tools/f18/f18.cpp
===
--- flang/tools/f18/f18.cpp
+++ flang/tools/f18/f18.cpp
@@ -564,6 +564,13 @@
   options.instrumentedParse = true;
 } else if (arg == "-fdebug-no-semantics") {
   driver.debugNoSemantics = true;
+} else if (arg == "-fdebug-unparse-no-sema") {
+  driver.debugNoSemantics = true;
+  driver.dumpUnparse = true;
+} else if (arg == "-fdebug-dump-parse-tree-no-sema") {
+  driver.debugNoSemantics = true;
+  driver.dumpParseTree = true;
+  driver.syntaxOnly = true;
 } else if (arg == "-funparse" || arg == "-fdebug-unparse") {
   driver.dumpUnparse = true;
 } else if (arg == "-funparse-with-symbols" ||
Index: flang/test/Parser/omp-atomic-unparse.f90
===
--- flang/test/Parser/omp-atomic-unparse.f90
+++ flang/test/Parser/omp-atomic-unparse.f90
@@ -1,4 +1,4 @@
-! RUN: %f18 -fdebug-no-semantics -funparse -fopenmp %s | FileCheck %s
+! RUN: %flang_fc1 -fdebug-unparse-no-sema -fopenmp %s | FileCheck %s
 
 program main
implicit none
Index: flang/test/Parser/omp-allocate-unparse.f90
===
--- flang/test/Parser/omp-allocate-unparse.f90
+++ flang/test/Parser/omp-allocate-unparse.f90
@@ -1,4 +1,4 @@
-! RUN: %f18 -fdebug-no-semantics -funparse -fopenmp %s | FileCheck %s
+! RUN: %flang_fc1 -fdebug-unparse-no-sema -fopenmp %s | FileCheck %s
 ! Check Unparsing of OpenMP Allocate directive
 
 program allocate_unparse
Index: flang/test/Driver/driver-help.f90
===
--- flang/test/Driver/driver-help.f90
+++ flang/test/Driver/driver-help.f90
@@ -66,6 +66,8 @@
 ! HELP-FC1-NEXT: -falternative-parameter-statement
 ! HELP-FC1-NEXT: Enable the old style PARAMETER statement
 ! HELP-FC1-NEXT: -fbackslashSpecify that backslash in string introduces an escape character
+! HELP-FC1-NEXT: -fdebug-dump-parse-tree-no-sema
+! HELP-FC1-NEXT:Dump the parse tree (skips the semantic checks)
 ! HELP-FC1-NEXT: -fdebug-dump-parse-tree Dump the parse tree
 ! HELP-FC1-NEXT: -fdebug-dump-parsing-log
 ! HELP-FC1-NEXT:   Run instrumented parse and dump the parsing log
@@ -75,6 +77,7 @@
 ! HELP-FC1-NEXT: Measure the parse tree
 ! HELP-FC1-NEXT: -fdebug-module-writer   Enable debug messages while writing module files
 ! HELP-FC1-NEXT: -fdebug-pre-fir-treeDump the pre-FIR tree
+! HELP-FC1-NEXT: -fdebug-unparse-no-sema Unparse and stop (skips the semantic checks)
 ! HELP-FC1-NEXT: -fdebug-unparse-with-symbols
 ! HELP-FC1-NEXT:Unparse and stop.
 ! HELP-FC1-NEXT: -fdebug-unparseUnparse and stop.
Index: flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
===
--- flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
+++ flang/lib/FrontendTool/ExecuteCompilerInvocation.cpp
@@ -40,6 +40,9 @@
   case DebugUnparse:
 return std::make_unique();
 break;
+  case DebugUnparseNoSema:
+return std::make_unique();
+break;
   case DebugUnparseWithSymbols:
 return std::make_unique();
 break;
@@ -49,6 +52,9 @@
   case DebugDumpParseTree:
 return std::make_unique();
 break;
+  case DebugDumpParseTreeNoSema:
+return std::make_unique();
+break;
   case DebugDumpProvenance:
 return std::make_unique();
 break;
Index: flang/lib/Frontend/FrontendActions.cpp
===
--- flang/lib/Frontend/FrontendActions.cpp
+++ flang/lib/Frontend/FrontendActions.cpp
@@ -78,6 +78,55 @@
   return true;
 }
 
+bool PrescanAndParseAction::BeginSourceFileAction(CompilerInstance ) {
+  CompilerInstance  = this->instance();
+
+  std::string currentInputPath{GetCurrentFileOrBufferName()};
+
+  Fortran::parser::Options parserOptions = ci.invocation().fortranOpts();
+
+  if (ci.invocation().frontendOpts().fortranForm_ == FortranForm::Unknown) {
+// Switch between fixed and free form format based on the 

[PATCH] D100037: [clang][UBSan] Passing underaligned pointer as a function argument is undefined behaviour

2021-04-07 Thread Roman Lebedev via Phabricator via cfe-commits
lebedev.ri created this revision.
lebedev.ri added reviewers: aaron.ballman, rsmith, efriedma, vsk, filcab, 
vitalybuka.
lebedev.ri added projects: LLVM, clang, Sanitizers.
Herald added subscribers: jansvoboda11, dexonsmith, dang.
lebedev.ri requested review of this revision.
Herald added subscribers: Sanitizers, cfe-commits.

This is somewhat related to the following RFC by @rjmccall:
https://lists.llvm.org/pipermail/llvm-dev/2016-January/094012.html

> C 6.3.2.3p7 (N1548) says:
>
>   A pointer to an object type may be converted to a pointer to a
>   different object type. If the resulting pointer is not correctly
>   aligned) for the referenced type, the behavior is undefined.
>
> C++ [expr.reinterpret.cast]p7 (N4527) defines pointer conversions in terms
> of conversions from void*:
>
>   An object pointer can be explicitly converted to an object pointer
>   of a different type. When a prvalue v of object pointer type is
>   converted to the object pointer type “pointer to cv T”, the result
>   is static_cast(static_cast(v)).
>
> C++ [expr.static.cast]p13 says of conversions from void*:
>
>   A prvalue of type “pointer to cv1 void” can be converted to a
>   prvalue of type “pointer to cv2 T”  If the original pointer value
>   represents the address A of a byte in memory and A satisfies the alignment
>   requirement of T, then the resulting pointer value represents the same
>   address as the original pointer value, that is, A. The result of any
>   other such pointer conversion is unspecified.

Currently clang does not optimize based on the fact that the pointers
passed into the function must be appropriately aligned for their pointee type.
We now have a motivation to change that. Namely, it was estabilished that
not doing so prevents LICM, and it is likely not the only penalized transform.
See D99249 .

Now, somehow i don't think we can just start optimizing on that.
Let's first give users tools to weed out the cases where the pointer
passed into function's argument is underaligned.

I've yet to actually see just how much mayhem this causes,
at least on the LLVM stage-2 build.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D100037

Files:
  clang/docs/ClangCommandLineReference.rst
  clang/docs/ReleaseNotes.rst
  clang/docs/UsersManual.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CodeGenFunction.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/test/CodeGen/catch-function-pointer-argument-alignment.cpp
  compiler-rt/lib/ubsan/ubsan_handlers.cpp
  compiler-rt/test/ubsan/TestCases/Pointer/function-pointer-argument.cpp

Index: compiler-rt/test/ubsan/TestCases/Pointer/function-pointer-argument.cpp
===
--- /dev/null
+++ compiler-rt/test/ubsan/TestCases/Pointer/function-pointer-argument.cpp
@@ -0,0 +1,30 @@
+// RUN: %clang   -x c   -fsanitize=alignment -O0 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+// RUN: %clang   -x c   -fsanitize=alignment -O1 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+// RUN: %clang   -x c   -fsanitize=alignment -O2 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+// RUN: %clang   -x c   -fsanitize=alignment -O3 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+
+// RUN: %clang   -x c++ -fsanitize=alignment -O0 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+// RUN: %clang   -x c++ -fsanitize=alignment -O1 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+// RUN: %clang   -x c++ -fsanitize=alignment -O2 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+// RUN: %clang   -x c++ -fsanitize=alignment -O3 %s -o %t && %run %t 2>&1 | FileCheck %s --implicit-check-not=" assumption " --implicit-check-not="note:" --implicit-check-not="error:"
+
+#include 
+
+struct S {
+  int k;
+} __attribute__((aligned(8192)));
+
+void take_pointer_to_overaligned_struct(struct S *x) {
+}
+
+int main(int argc, char *argv[]) {
+  char *ptr = (char *)malloc(2 * sizeof(struct S));
+
+  take_pointer_to_overaligned_struct((struct S *)(ptr + 1));
+  // CHECK: {{.*}}function-pointer-argument.cpp:[[@LINE-7]]:51: runtime error: function pointer argument has misaligned address {{.*}} for type 'struct S', which requires 8192 byte alignment
+  // CHECK: 0x{{.*}}: 

[PATCH] D99949: [AMDGPU][OpenMP] Add amdgpu-arch tool to list AMD GPUs installed

2021-04-07 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

We'll have slightly indirect testing once this is used to enable D99656 
. There are two pieces that can be tested:

1/ The clang handling. That we can test with a minor change. Add a command line 
argument to clang that specifies the name of the tool to call to get the 
architecture (and defaults to amdgpu-arch). Then write N tests that call N 
different shell scripts that return the various cases. The plumbing for that 
argument may prove useful when adding a corresponding nvptx toool.

2/ The call into hsa. That probably means stubbing out hsa. Kind of interested 
in that - a hsa library that can be jury rigged to fail various calls is a path 
to a robust amdgpu plugin. Way more complexity in that fake stub than in this 
code though. I don't think that's worthwhile here.




Comment at: clang/tools/amdgpu-arch/AMDGPUArch.cpp:42
+  if (Status != HSA_STATUS_SUCCESS) {
+fprintf(stderr, "Unable to initialize HSA\n");
+  }

missed one, return 1 on failure to initialize


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99949

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


[PATCH] D99409: [clang] Speedup line offset mapping computation

2021-04-07 Thread Nico Weber via Phabricator via cfe-commits
thakis added inline comments.



Comment at: clang/lib/Basic/SourceManager.cpp:1262
+   unsigned char n) {
+  return ((x - ~0UL / 255 * (n + 1)) & ~x &
+  (x & ~0UL / 255 * 127) + ~0UL / 255 * (127 - (m - 1))) &

UL is 32-bit on windows but 64-bit on linux/mac in 64-bit builds (LP64 vs 
LLP64). Maybe you want 0ULL here?

If so, then you should be able to repro this on linux by building a 32-bit 
clang binary there.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D99409

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


  1   2   >