[PATCH] D97915: [Coroutines] Handle overaligned frame allocation

2021-06-22 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen marked 5 inline comments as done.
ychen added a comment.

In D97915#2829581 , @ChuanqiXu wrote:

> A remained question.
>
> - what's the semantics if user specified their allocation/deallocation 
> functions?
>
> Previously, we discussed for the ::operator new and ::operator delete. But 
> what would we do for user specified allocation/deallocation functions?
> It looks like we would treat them just like `::operator new`. And it makes 
> sense at the first glance. But the problem comes from that we judge whether
> or not to over allocate a frame by this condition:
>
>   coro.align > align of new
>
> But if the user uses their new, it makes no sense to use the `align of new` 
> as the condition. On the other hand, if user specified their new function and 
> the 
> alignment requirement for their promise type, would it be better really that 
> the compiler do the extra transformation?
>
> May be we need to discuss with other guys who are more familiar with the C++ 
> standard to answer this.

I think @rjmccall could answer these. My understanding is that user-specified 
allocation/deallocation has the same semantics as their standard library's 
counterparts. `align of new` (aka __STDCPP_DEFAULT_NEW_ALIGNMENT__) should 
apply to both.




Comment at: clang/lib/CodeGen/CGCoroutine.cpp:743-744
+CGM.getIntrinsic(llvm::Intrinsic::coro_align, SizeTy));
+auto *AlignedUpAddr = EmitBuiltinAlignTo(AlignedAllocateCall, CoroAlign,
+ S.getAlignedAllocate(), true);
+// rawFrame = frame;

ChuanqiXu wrote:
> ychen wrote:
> > ChuanqiXu wrote:
> > > ychen wrote:
> > > > ChuanqiXu wrote:
> > > > > Maybe we could calculate it in place instead of trying to call a 
> > > > > function which is not designed for llvm::value*. It looks like the 
> > > > > calculation isn't too complex.
> > > > I'm open to not calling `EmitBuiltinAlignTo`, which basically inline 
> > > > the useful parts of `EmitBuiltinAlignTo`.  The initial intention is 
> > > > code sharing and easy readability. What's the benefit of not calling it?
> > > Reusing code is good. But my main concern is that the design for the 
> > > interfaces. The current design smells bad to me. Another reason for 
> > > implement it in place is I think it is not very complex and easy to 
> > > understand.
> > > 
> > > Another option I got is to implement `EmitBuitinAlign` in LLVM (someplace 
> > > like `Local`), then the CodeGenFunction:: EmitBuitinAlign and this 
> > > function could use it.
> > > Reusing code is good. But my main concern is that the design for the 
> > > interfaces. The current design smells bad to me. Another reason for 
> > > implement it in place is I think it is not very complex and easy to 
> > > understand.
> > > 
> > > Another option I got is to implement `EmitBuitinAlign` in LLVM (someplace 
> > > like `Local`), then the CodeGenFunction:: EmitBuitinAlign and this 
> > > function could use it.
> > 
> > 
> I guess you forgot to reply what you want to say.
Yep, I meant to say the use of "void *" is removed.



Comment at: clang/lib/CodeGen/CGCoroutine.cpp:431-433
+  auto *Diff = Builder.CreateNSWSub(AlignCall, AlignOfNewInt);
+  auto *NewCoroSize = Builder.CreateAdd(CI->getArgOperand(CoroSizeIdx), Diff);
+  CI->setArgOperand(CoroSizeIdx, NewCoroSize);

ChuanqiXu wrote:
> In other comments, I find 'size += align - NEW_ALIGN + sizeof(void*);'. But I 
> don't find sizeof(void*) in this function.
Sorry, that's a stale comment. It should be `size += align - NEW_ALIGN`. The 
`sizeof(void*)` was supposed for the newly added raw memory pointer stored in 
the frame. In the current implementation, `sizeof(void*)` is factored into the 
`llvm.coro.size()` calculation because CoroFrame is responsible for allocating 
the extra raw memory pointer if it is needed at all.



Comment at: clang/lib/CodeGen/CGCoroutine.cpp:452-461
+  llvm::Function *RawFramePtrOffsetIntrin = CGF.CGM.getIntrinsic(
+  llvm::Intrinsic::coro_raw_frame_ptr_offset, CGF.Int32Ty);
+  auto *RawFramePtrOffset = CGF.Builder.CreateCall(RawFramePtrOffsetIntrin);
+  auto *FramePtrAddrStart =
+  CGF.Builder.CreateInBoundsGEP(CoroFree, {RawFramePtrOffset});
+  auto *FramePtrAddr = CGF.Builder.CreatePointerCast(
+  FramePtrAddrStart, CGF.Int8PtrTy->getPointerTo());

ChuanqiXu wrote:
> We allocate overaligned-frame like:
> ```
> | --- for align --- | --- true frame --- |
> ```
> And here we set the argument to the address of true frame. Then I wonder how 
> about the memory for the `for align` part. Would we still free them 
> correctly? Maybe I missed something.
> Would we still free them correctly? 
Yes, that's the tricky part. Using `f0` of `coro-alloc.cpp` as an example, 
`llvm.coro.raw.frame.ptr.addr` is called at alloc time to save the raw memory 
pointer to the coroutine frame.  Later at dealloc

[PATCH] D97915: [Coroutines] Handle overaligned frame allocation

2021-06-22 Thread Yuanfang Chen via Phabricator via cfe-commits
ychen updated this revision to Diff 353567.
ychen marked an inline comment as done.
ychen added a comment.

- Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97915

Files:
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/lib/CodeGen/CGCoroutine.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGenCoroutines/coro-alloc.cpp
  clang/test/CodeGenCoroutines/coro-cleanup.cpp
  clang/test/CodeGenCoroutines/coro-gro.cpp
  llvm/docs/Coroutines.rst
  llvm/include/llvm/IR/Intrinsics.td
  llvm/lib/Transforms/Coroutines/CoroFrame.cpp
  llvm/lib/Transforms/Coroutines/CoroInstr.h
  llvm/lib/Transforms/Coroutines/CoroInternal.h
  llvm/lib/Transforms/Coroutines/CoroSplit.cpp
  llvm/lib/Transforms/Coroutines/Coroutines.cpp
  llvm/test/Transforms/Coroutines/coro-frame-overalign.ll

Index: llvm/test/Transforms/Coroutines/coro-frame-overalign.ll
===
--- /dev/null
+++ llvm/test/Transforms/Coroutines/coro-frame-overalign.ll
@@ -0,0 +1,78 @@
+; Check that `llvm.coro.align`, `llvm.coro.raw.frame.ptr.offset` and
+; `@llvm.coro.raw.frame.ptr.alloca` are lowered correctly.
+; RUN: opt < %s -passes=coro-split -S | FileCheck %s
+
+%PackedStruct = type <{ i64 }>
+
+declare void @consume(%PackedStruct*, i32, i32, i8**)
+declare void @consume2(i32, i32)
+
+define i8* @f() "coroutine.presplit"="1" {
+entry:
+  %data = alloca %PackedStruct, align 32
+  %id = call token @llvm.coro.id(i32 16, i8* null, i8* null, i8* null)
+  %size = call i32 @llvm.coro.size.i32()
+  %alloc = call i8* @malloc(i32 %size)
+  %hdl = call i8* @llvm.coro.begin(token %id, i8* %alloc)
+  %align = call i32 @llvm.coro.align.i32()
+  %offset = call i32 @llvm.coro.raw.frame.ptr.offset.i32()
+  %addr = call i8** @llvm.coro.raw.frame.ptr.addr()
+  call void @consume(%PackedStruct* %data, i32 %align, i32 %offset, i8** %addr)
+  %0 = call i8 @llvm.coro.suspend(token none, i1 false)
+  switch i8 %0, label %suspend [i8 0, label %resume
+i8 1, label %cleanup]
+resume:
+  br label %cleanup
+
+cleanup:
+  %align2 = call i32 @llvm.coro.align.i32()
+  %offset2 = call i32 @llvm.coro.raw.frame.ptr.offset.i32()
+  call void @consume2(i32 %align2, i32 %offset2)
+  %mem = call i8* @llvm.coro.free(token %id, i8* %hdl)
+  call void @free(i8* %mem)
+  br label %suspend
+suspend:
+  call i1 @llvm.coro.end(i8* %hdl, i1 0)
+  ret i8* %hdl
+}
+
+; See if the raw frame address was inserted into the frame.
+; CHECK-LABEL: %f.Frame = type { void (%f.Frame*)*, void (%f.Frame*)*, i8*, i1, [7 x i8], %PackedStruct }
+
+; See if we used correct index to access frame addr field (field 2).
+; CHECK-LABEL: @f(
+; CHECK: %alloc.frame.ptr = alloca i8*, align 8
+; CHECK: %[[FIELD:.+]] = getelementptr inbounds %f.Frame, %f.Frame* %FramePtr, i32 0, i32 2
+; CHECK: %[[ADDR:.+]] = load i8*, i8** %alloc.frame.ptr, align 8
+; CHECK: store i8* %[[ADDR]], i8** %[[FIELD]], align 8
+; CHECK: %[[DATA:.+]] = getelementptr inbounds %f.Frame, %f.Frame* %FramePtr, i32 0, i32 5
+; CHECK: call void @consume(%PackedStruct* %[[DATA]], i32 32, i32 16, i8** %[[FIELD]])
+; CHECK: ret i8*
+
+; See if `llvm.coro.align` and `llvm.coro.raw.frame.ptr.offset` are lowered
+; correctly during deallocation.
+; CHECK-LABEL: @f.destroy(
+; CHECK: call void @consume2(i32 32, i32 16)
+; CHECK: call void @free(i8* %{{.*}})
+
+; CHECK-LABEL: @f.cleanup(
+; CHECK: call void @consume2(i32 32, i32 16)
+; CHECK: call void @free(i8*
+
+declare i8* @llvm.coro.free(token, i8*)
+declare i32 @llvm.coro.size.i32()
+declare i32 @llvm.coro.align.i32()
+declare i32 @llvm.coro.raw.frame.ptr.offset.i32()
+declare i8** @llvm.coro.raw.frame.ptr.addr()
+declare i8  @llvm.coro.suspend(token, i1)
+declare void @llvm.coro.resume(i8*)
+declare void @llvm.coro.destroy(i8*)
+
+declare token @llvm.coro.id(i32, i8*, i8*, i8*)
+declare i1 @llvm.coro.alloc(token)
+declare i8* @llvm.coro.begin(token, i8*)
+declare i1 @llvm.coro.end(i8*, i1)
+
+declare noalias i8* @malloc(i32)
+declare double @print(double)
+declare void @free(i8*)
Index: llvm/lib/Transforms/Coroutines/Coroutines.cpp
===
--- llvm/lib/Transforms/Coroutines/Coroutines.cpp
+++ llvm/lib/Transforms/Coroutines/Coroutines.cpp
@@ -234,6 +234,9 @@
   Shape.CoroBegin = nullptr;
   Shape.CoroEnds.clear();
   Shape.CoroSizes.clear();
+  Shape.CoroAligns.clear();
+  Shape.CoroRawFramePtrOffsets.clear();
+  Shape.CoroRawFramePtrAddrs.clear();
   Shape.CoroSuspends.clear();
 
   Shape.FrameTy = nullptr;
@@ -268,6 +271,15 @@
   case Intrinsic::coro_size:
 CoroSizes.push_back(cast(II));
 break;
+  case Intrinsic::coro_align:
+CoroAligns.push_back(cast(II));
+break;
+  case Intrinsic::coro_raw_frame_ptr_offset:
+CoroRawFramePtrOffsets.push_back(cast(II));
+break;
+  case Intrinsic::coro_raw_frame_ptr_a

[PATCH] D93528: [clang-format] Add basic support for formatting JSON

2021-06-22 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay updated this revision to Diff 353570.
MyDeveloperDay added a comment.

- Add release note
- Add default Column Limit of 0 for default Json Style (add unit test to ensure 
column limits can still be used)
  - this minimises the differences between what Notepad++'s JSON Format plugin 
(https://github.com/kapilratnani/JSON-Viewer)  and clang-format produces




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

https://reviews.llvm.org/D93528

Files:
  clang/docs/ClangFormat.rst
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/ContinuationIndenter.cpp
  clang/lib/Format/Format.cpp
  clang/lib/Format/TokenAnnotator.cpp
  clang/tools/clang-format/ClangFormat.cpp
  clang/tools/clang-format/clang-format-diff.py
  clang/tools/clang-format/git-clang-format
  clang/unittests/Format/CMakeLists.txt
  clang/unittests/Format/FormatTestJson.cpp

Index: clang/unittests/Format/FormatTestJson.cpp
===
--- /dev/null
+++ clang/unittests/Format/FormatTestJson.cpp
@@ -0,0 +1,197 @@
+//===- unittest/Format/FormatTestJson.cpp - Formatting tests for Json -===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#include "FormatTestUtils.h"
+#include "clang/Format/Format.h"
+#include "llvm/Support/Debug.h"
+#include "gtest/gtest.h"
+
+#define DEBUG_TYPE "format-test-json"
+
+namespace clang {
+namespace format {
+
+class FormatTestJson : public ::testing::Test {
+protected:
+  static std::string format(llvm::StringRef Code, unsigned Offset,
+unsigned Length, const FormatStyle &Style) {
+LLVM_DEBUG(llvm::errs() << "---\n");
+LLVM_DEBUG(llvm::errs() << Code << "\n\n");
+
+tooling::Replacements Replaces;
+
+// Mock up what ClangFormat.cpp will do for JSON by adding a variable
+// to trick JSON into being JavaScript
+if (Style.isJson()) {
+  auto Err = Replaces.add(
+  tooling::Replacement(tooling::Replacement("", 0, 0, "x = ")));
+  if (Err) {
+llvm::errs() << "Bad Json variable insertion\n";
+  }
+}
+auto ChangedCode = applyAllReplacements(Code, Replaces);
+if (!ChangedCode) {
+  llvm::errs() << "Bad Json varibale replacement\n";
+}
+StringRef NewCode = *ChangedCode;
+
+std::vector Ranges(1, tooling::Range(0, NewCode.size()));
+Replaces = reformat(Style, NewCode, Ranges);
+auto Result = applyAllReplacements(NewCode, Replaces);
+EXPECT_TRUE(static_cast(Result));
+LLVM_DEBUG(llvm::errs() << "\n" << *Result << "\n\n");
+return *Result;
+  }
+
+  static std::string
+  format(llvm::StringRef Code,
+ const FormatStyle &Style = getLLVMStyle(FormatStyle::LK_Json)) {
+return format(Code, 0, Code.size(), Style);
+  }
+
+  static FormatStyle getStyleWithColumns(unsigned ColumnLimit) {
+FormatStyle Style = getLLVMStyle(FormatStyle::LK_Json);
+Style.ColumnLimit = ColumnLimit;
+return Style;
+  }
+
+  static void
+  verifyFormat(llvm::StringRef Code,
+   const FormatStyle &Style = getLLVMStyle(FormatStyle::LK_Json)) {
+EXPECT_EQ(Code.str(), format(Code, Style)) << "Expected code is not stable";
+EXPECT_EQ(Code.str(), format(test::messUp(Code), Style));
+  }
+};
+
+TEST_F(FormatTestJson, JsonRecord) {
+  verifyFormat("{}");
+  verifyFormat("{\n"
+   "  \"name\": 1\n"
+   "}");
+  verifyFormat("{\n"
+   "  \"name\": \"Foo\"\n"
+   "}");
+  verifyFormat("{\n"
+   "  \"name\": {\n"
+   "\"value\": 1\n"
+   "  }\n"
+   "}");
+  verifyFormat("{\n"
+   "  \"name\": {\n"
+   "\"value\": 1\n"
+   "  },\n"
+   "  \"name\": {\n"
+   "\"value\": 2\n"
+   "  }\n"
+   "}");
+  verifyFormat("{\n"
+   "  \"name\": {\n"
+   "\"value\": [\n"
+   "  1,\n"
+   "  2,\n"
+   "]\n"
+   "  }\n"
+   "}");
+  verifyFormat("{\n"
+   "  \"name\": {\n"
+   "\"value\": [\n"
+   "  \"name\": {\n"
+   "\"value\": 1\n"
+   "  },\n"
+   "  \"name\": {\n"
+   "\"value\": 2\n"
+   "  }\n"
+   "]\n"
+   "  }\n"
+   "}");
+  verifyFormat(R"({
+  "firstName": "John",
+  "lastName": "Smith",
+  "isAlive": true,
+  "age": 27,
+  "address": {
+"streetAddress": "21 2nd Street",
+"city": "New York",
+"state": "NY",
+"postalCode": "10021-

[PATCH] D93528: [clang-format] Add basic support for formatting JSON

2021-06-22 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay marked an inline comment as done.
MyDeveloperDay added inline comments.



Comment at: clang/docs/ReleaseNotes.rst:284
 
+- Basic Support has been adding for Formatting .json files (with very limited 
options)
+

curdeius wrote:
> Maybe instead of putting "with very limited options", you may add a link to 
> the doc describing limitations?
This new strategy actually gives us lots of pre-existing options, for example:

using `TabWidth` and `UseTab`  we can tabify/de-tabify the json

using `SpacesInContainerLiterals` we can control if the json is `["foo"]` or `[ 
"foo" ]`

Any option that can be used to format the javascript:

`x =  { ... } `

can be used to format the JSON, I believe this gives us the best of both 
worlds, and some flexibility for the future if people want to format JSON in a 
specific BraceWrapping style.





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

https://reviews.llvm.org/D93528

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


[PATCH] D93373: [Flang][Openmp] Upgrade TASKGROUP construct to 5.0.

2021-06-22 Thread Chirag Khandelwal via Phabricator via cfe-commits
AMDChirag added a comment.

Hi @kiranchandramohan How do I restart the build? It says I don't have 
permission.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93373

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


[PATCH] D93373: [Flang][Openmp] Upgrade TASKGROUP construct to 5.0.

2021-06-22 Thread Kiran Chandramohan via Phabricator via cfe-commits
kiranchandramohan added a comment.

It could be because you are not the author. Can you commandeer the patch 
(option available in the Add Action menu below)?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93373

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


[PATCH] D93373: [Flang][Openmp] Upgrade TASKGROUP construct to 5.0.

2021-06-22 Thread Chirag Khandelwal via Phabricator via cfe-commits
AMDChirag added a comment.

In D93373#2832533 , @kiranchandramohan 
wrote:

> It could be because you are not the author. Can you commandeer the patch 
> (option available in the Add Action menu below)?

Just did that. Still the same error:

  You do not have permission to edit this object.
  Users with the "Can Edit" capability:
  Administrators can take this action.
  You must have edit permission on this build plan to pause, abort, resume, or 
restart it.You must have edit permission on this build plan to run it manually.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93373

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


[PATCH] D103131: support debug info for alias variable

2021-06-22 Thread kamlesh kumar via Phabricator via cfe-commits
kamleshbhalui added a comment.

In D103131#2815386 , @probinson wrote:

>>>   0x002a:   DW_TAG_variable
>>>   DW_AT_name  ("oldname")
>>>   DW_AT_type  (0x003f "int")
>>>   DW_AT_external  (true)
>>>   DW_AT_decl_file 
>>> ("/folk/kkumar/tcllvm/llvm-build-lldb-rel/bin/test.c")
>>>   DW_AT_decl_line (1)
>>>   DW_AT_location  (DW_OP_addr 0x0)
>>>   
>>>   0x003f:   DW_TAG_base_type
>>>   DW_AT_name  ("int")
>>>   DW_AT_encoding  (DW_ATE_signed)
>>>   DW_AT_byte_size (0x04)
>>>   
>>>   0x0046:   DW_TAG_variable
>>>   DW_AT_name  ("newname")
>>>   DW_AT_type  (0x003f "int")
>>>   DW_AT_decl_file 
>>> ("/folk/kkumar/tcllvm/llvm-build-lldb-rel/bin/test.c")
>>>   DW_AT_decl_line (2)
>>>   DW_AT_declaration   (true)
>>>   
>>>   0x0051:   DW_TAG_imported_declaration
>>>   DW_AT_decl_file 
>>> ("/folk/kkumar/tcllvm/llvm-build-lldb-rel/bin/test.c")
>>>   DW_AT_decl_line (2)
>>>   DW_AT_import(0x0046)
>>>   DW_AT_name  ("newname")
>
> I agree with David, this sequence doesn't seem to do what's desired.
> There's nothing that ties "newname" to "oldname" here.  What you 
> want is something more like this:
>
>   0x002a: DW_TAG_variable
>  DW_AT_name ("oldname")
>  ...
>   0x003a: DW_TAG_imported_declaration
>  DW_AT_import (0x002a)
>  DW_AT_name ("newname")
>
> That is, there would not be a separate DW_TAG_variable for "newname";
> instead, the imported_declaration would import the DIE for "oldname"
> giving it the name "newname".
>
> --paulr

Even this does not work with gdb.
Here is what gdb says,

   (gdb) ptype newname
  type = 
   (gdb) p newname
  'newname' has unknown type; cast it to its declared type
   (gdb) p oldname
   $1 = 1
   (gdb) ptype oldname
   type = int
   (gdb)  
   --
   dumped debug info (using llvm-dwarfdump)
   test.o: file format elf64-x86-64
   
   .debug_info contents:
   0x: Compile Unit: length = 0x0067, format = DWARF32, version = 
0x0004, abbr_offset = 0x, addr_size = 0x08 (next unit at 0x006b)
   
   0x000b: DW_TAG_compile_unit
 DW_AT_producer("clang version 13.0.0 
(g...@github.com:llvm/llvm-project.git 
4cd7169f5517167ef456e82c6dcae669bde6c725)")
 DW_AT_language(DW_LANG_C99)
 DW_AT_name("test.c")
 DW_AT_stmt_list   (0x)
 DW_AT_comp_dir
("/folk/kkumar/tcllvm/llvm-build-lldb-rel/bin")
 DW_AT_low_pc  (0x)
 DW_AT_high_pc (0x0008)
   
   0x002a:   DW_TAG_variable
   DW_AT_name  ("oldname")
   DW_AT_type  (0x003f "int")
   DW_AT_external  (true)
   DW_AT_decl_file 
("/folk/kkumar/tcllvm/llvm-build-lldb-rel/bin/test.c")
   DW_AT_decl_line (1)
   DW_AT_location  (DW_OP_addr 0x0)
   
   0x003f:   DW_TAG_base_type
   DW_AT_name  ("int")
   DW_AT_encoding  (DW_ATE_signed)
   DW_AT_byte_size (0x04)
   
   0x0046:   DW_TAG_imported_declaration
   DW_AT_decl_file 
("/folk/kkumar/tcllvm/llvm-build-lldb-rel/bin/test.c")
   DW_AT_decl_line (2)
   DW_AT_import(0x002a)
   DW_AT_name  ("newname")
   
   0x0051:   DW_TAG_subprogram
   DW_AT_low_pc(0x)
   DW_AT_high_pc   (0x0008)
   DW_AT_frame_base(DW_OP_reg6 RBP)
   DW_AT_name  ("main")
   DW_AT_decl_file 
("/folk/kkumar/tcllvm/llvm-build-lldb-rel/bin/test.c")
   DW_AT_decl_line (3)
   DW_AT_type  (0x003f "int")
   DW_AT_external  (true)
   
   0x006a:   NULL
   
   




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103131

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


[PATCH] D93373: [Flang][Openmp] Upgrade TASKGROUP construct to 5.0.

2021-06-22 Thread Kiran Chandramohan via Phabricator via cfe-commits
kiranchandramohan added a comment.

Can you rebase and update the patch? It seems to have built for the latest 
revision (Harbormaster completed remote builds in B110336 
: Diff 353548).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93373

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


[PATCH] D93373: [Flang][Openmp] Upgrade TASKGROUP construct to 5.0.

2021-06-22 Thread Chirag Khandelwal via Phabricator via cfe-commits
AMDChirag updated this revision to Diff 353579.
AMDChirag added a comment.

Rebased


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93373

Files:
  clang/test/OpenMP/master_taskloop_simd_ast_print.cpp
  clang/test/OpenMP/parallel_master_taskloop_simd_ast_print.cpp
  clang/test/OpenMP/taskloop_simd_ast_print.cpp
  flang/lib/Semantics/resolve-directives.cpp
  flang/lib/Semantics/resolve-names.cpp
  flang/test/Semantics/omp-taskgroup01.f90
  llvm/include/llvm/Frontend/OpenMP/OMP.td

Index: llvm/include/llvm/Frontend/OpenMP/OMP.td
===
--- llvm/include/llvm/Frontend/OpenMP/OMP.td
+++ llvm/include/llvm/Frontend/OpenMP/OMP.td
@@ -473,8 +473,8 @@
 }
 def OMP_TaskGroup : Directive<"taskgroup"> {
   let allowedClauses = [
-VersionedClause,
-VersionedClause
+VersionedClause,
+VersionedClause
   ];
 }
 def OMP_Flush : Directive<"flush"> {
Index: flang/test/Semantics/omp-taskgroup01.f90
===
--- /dev/null
+++ flang/test/Semantics/omp-taskgroup01.f90
@@ -0,0 +1,47 @@
+! RUN: %S/test_errors.sh %s %t %flang -fopenmp
+use omp_lib
+  implicit none
+  integer :: xyz, abc
+  real :: reduction_var
+  !$omp parallel num_threads(4)
+!$omp single
+  print *, "The"
+!$omp taskgroup
+  !$omp task
+  print *, "almighty"
+  !$omp end task
+  !$omp task
+  print *, "sun"
+  !$omp end task
+!$omp end taskgroup
+!$omp end single
+  !$omp end parallel
+
+  !$omp parallel private(xyz)
+!$omp taskgroup allocate(xyz)
+  !$omp task
+print *, "The "
+!$omp taskgroup allocate(omp_large_cap_mem_space: abc)
+  !$omp task
+  print *, "almighty sun"
+  !$omp end task
+!$omp end taskgroup
+  !$omp end task
+!$omp end taskgroup
+  !$omp end parallel
+
+  !ERROR: PRIVATE clause is not allowed on the TASKGROUP directive
+  !$omp taskgroup private(abc)
+  !$omp end taskgroup
+
+  !$omp parallel
+!$omp task
+  !$omp taskgroup task_reduction(+ : reduction_var)
+print *, "The "
+!$omp taskgroup task_reduction(.or. : reduction_var) task_reduction(.and. : reduction_var)
+  print *, "almighty sun"
+!$omp end taskgroup
+  !$omp end taskgroup
+!$omp end task
+  !$omp end parallel
+end program
Index: flang/lib/Semantics/resolve-names.cpp
===
--- flang/lib/Semantics/resolve-names.cpp
+++ flang/lib/Semantics/resolve-names.cpp
@@ -1288,6 +1288,7 @@
   case llvm::omp::Directive::OMPD_target_data:
   case llvm::omp::Directive::OMPD_master:
   case llvm::omp::Directive::OMPD_ordered:
+  case llvm::omp::Directive::OMPD_taskgroup:
 return false;
   default:
 return true;
Index: flang/lib/Semantics/resolve-directives.cpp
===
--- flang/lib/Semantics/resolve-directives.cpp
+++ flang/lib/Semantics/resolve-directives.cpp
@@ -1069,12 +1069,12 @@
   case llvm::omp::Directive::OMPD_target:
   case llvm::omp::Directive::OMPD_target_data:
   case llvm::omp::Directive::OMPD_task:
+  case llvm::omp::Directive::OMPD_taskgroup:
   case llvm::omp::Directive::OMPD_teams:
   case llvm::omp::Directive::OMPD_workshare:
   case llvm::omp::Directive::OMPD_parallel_workshare:
   case llvm::omp::Directive::OMPD_target_teams:
   case llvm::omp::Directive::OMPD_target_parallel:
-  case llvm::omp::Directive::OMPD_taskgroup:
 PushContext(beginDir.source, beginDir.v);
 break;
   default:
@@ -1095,6 +1095,7 @@
   case llvm::omp::Directive::OMPD_single:
   case llvm::omp::Directive::OMPD_target:
   case llvm::omp::Directive::OMPD_task:
+  case llvm::omp::Directive::OMPD_taskgroup:
   case llvm::omp::Directive::OMPD_teams:
   case llvm::omp::Directive::OMPD_parallel_workshare:
   case llvm::omp::Directive::OMPD_target_teams:
Index: clang/test/OpenMP/taskloop_simd_ast_print.cpp
===
--- clang/test/OpenMP/taskloop_simd_ast_print.cpp
+++ clang/test/OpenMP/taskloop_simd_ast_print.cpp
@@ -1,13 +1,13 @@
-// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=45 -ast-print %s | FileCheck %s --check-prefix CHECK --check-prefix OMP45
-// RUN: %clang_cc1 -fopenmp -fopenmp-version=45 -x c++ -std=c++11 -emit-pch -o %t %s
-// RUN: %clang_cc1 -fopenmp -fopenmp-version=45 -std=c++11 -include-pch %t -fsyntax-only -verify %s -ast-print | FileCheck %s --check-prefix CHECK --check-prefix OMP45
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-version=50 -DOMP5 -ast-print %s | FileCheck %s --check-prefix CHECK --check-prefix OMP50
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -DOMP5 -x c++ -std=c++11 -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-version=50 -DOMP5 -std=c++11 -include-pch %t -fsyntax-only -verify %s -ast-print | File

[PATCH] D93373: [Flang][Openmp] Upgrade TASKGROUP construct to 5.0.

2021-06-22 Thread Chirag Khandelwal via Phabricator via cfe-commits
AMDChirag added a comment.

Oh great! That triggered it!
Thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93373

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


[PATCH] D104550: [analyzer] Implement getType for SVal

2021-06-22 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko marked an inline comment as done.
vsavchenko added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/SVals.cpp:151
+  Optional VisitNonLocLazyCompoundVal(nonloc::LazyCompoundVal LCV) {
+return Visit(LCV.getRegion());
+  }

NoQ wrote:
> vsavchenko wrote:
> > NoQ wrote:
> > > This is correct except you need to get the value type, not the pointer 
> > > type.
> > > 
> > > `LazyCompoundVal` is a `prvalue` and its parent region is the location in 
> > > which this `prvalue` resided some time in the past. So the parent region 
> > > is of the right type and it's always typed but you need the pointee type.
> > OK then, can you maybe hint how can I write a test where this is going to 
> > be a pointer type (or maybe then `getType` for regions works incorrectly).
> Regions have `getLocationType()` (the pointer type) and `getValueType()` (the 
> pointee type). I think you need to call the latter directly in this case, 
> bypassing recursion.
> 
> In order to obtain a live `LazyCompoundVal` specimen for testing purposes, 
> you need to load an entire compound object (not necessarily represented by a 
> `CompoundVal`) from Region Store.
> 
> Eg.,
> ```lang=c
>   struct MyStruct a;
>   // ...
>   struct MyStruct b = a; // Avoid C++ though, constructors are a different 
> beast.
> ```
> 
> Or you could construct one directly. But that, of course, wouldn't give you 
> any hints about the appropriate type.
> 
> > maybe then `getType` for regions works incorrectly
> 
> Hmm that's actually a good separate question. How do you know if a region 
> represents a prvalue of pointer type or a glvalue of pointee type (including, 
> but not limited to, references)? This can't be figured out without more 
> context just by looking at the `SVal`.
> In order to obtain a live LazyCompoundVal specimen for testing purposes.
That's not a problem:
```
TestUnion d = {.c=b};
```
does produce LazyCompundVal and we don't get a pointer, but the value type.  
That's why I was asking how I can construct an example when this current 
implementation fails.

> Hmm that's actually a good separate question. How do you know if a region 
> represents a prvalue of pointer type or a glvalue of pointee type (including, 
> but not limited to, references)? This can't be figured out without more 
> context just by looking at the SVal.
Value categories are orthogonal to types, so I don't see why we should care for 
those in `getType`.  How do you think it should affect this particular 
functionality?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104550

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


[clang] d7227a5 - [clang][Analyzer] Track null stream argument in alpha.unix.Stream .

2021-06-22 Thread Balázs Kéri via cfe-commits

Author: Balázs Kéri
Date: 2021-06-22T11:16:56+02:00
New Revision: d7227a5bc718940fa9bf90ba443e1dff6ded68cc

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

LOG: [clang][Analyzer] Track null stream argument in alpha.unix.Stream .

The checker contains check for passing a NULL stream argument.
This change should make more easy to identify where the passed pointer
becomes NULL.

Reviewed By: NoQ

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

Added: 


Modified: 
clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
clang/test/Analysis/stream-note.c

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
index 6b176b3c4e2b2..75db1e195a432 100644
--- a/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
@@ -306,7 +306,8 @@ class StreamChecker : public CheckerStreamArgNo), C, State);
   if (!State)
 return;
 
@@ -549,7 +551,8 @@ void StreamChecker::preFread(const FnDescription *Desc, 
const CallEvent &Call,
  CheckerContext &C) const {
   ProgramStateRef State = C.getState();
   SVal StreamVal = getStreamArg(Desc, Call);
-  State = ensureStreamNonNull(StreamVal, C, State);
+  State = ensureStreamNonNull(StreamVal, Call.getArgExpr(Desc->StreamArgNo), C,
+  State);
   if (!State)
 return;
   State = ensureStreamOpened(StreamVal, C, State);
@@ -573,7 +576,8 @@ void StreamChecker::preFwrite(const FnDescription *Desc, 
const CallEvent &Call,
   CheckerContext &C) const {
   ProgramStateRef State = C.getState();
   SVal StreamVal = getStreamArg(Desc, Call);
-  State = ensureStreamNonNull(StreamVal, C, State);
+  State = ensureStreamNonNull(StreamVal, Call.getArgExpr(Desc->StreamArgNo), C,
+  State);
   if (!State)
 return;
   State = ensureStreamOpened(StreamVal, C, State);
@@ -671,7 +675,8 @@ void StreamChecker::preFseek(const FnDescription *Desc, 
const CallEvent &Call,
  CheckerContext &C) const {
   ProgramStateRef State = C.getState();
   SVal StreamVal = getStreamArg(Desc, Call);
-  State = ensureStreamNonNull(StreamVal, C, State);
+  State = ensureStreamNonNull(StreamVal, Call.getArgExpr(Desc->StreamArgNo), C,
+  State);
   if (!State)
 return;
   State = ensureStreamOpened(StreamVal, C, State);
@@ -790,7 +795,8 @@ void StreamChecker::preDefault(const FnDescription *Desc, 
const CallEvent &Call,
CheckerContext &C) const {
   ProgramStateRef State = C.getState();
   SVal StreamVal = getStreamArg(Desc, Call);
-  State = ensureStreamNonNull(StreamVal, C, State);
+  State = ensureStreamNonNull(StreamVal, Call.getArgExpr(Desc->StreamArgNo), C,
+  State);
   if (!State)
 return;
   State = ensureStreamOpened(StreamVal, C, State);
@@ -814,7 +820,8 @@ void StreamChecker::evalSetFeofFerror(const FnDescription 
*Desc,
 }
 
 ProgramStateRef
-StreamChecker::ensureStreamNonNull(SVal StreamVal, CheckerContext &C,
+StreamChecker::ensureStreamNonNull(SVal StreamVal, const Expr *StreamE,
+   CheckerContext &C,
ProgramStateRef State) const {
   auto Stream = StreamVal.getAs();
   if (!Stream)
@@ -827,8 +834,11 @@ StreamChecker::ensureStreamNonNull(SVal StreamVal, 
CheckerContext &C,
 
   if (!StateNotNull && StateNull) {
 if (ExplodedNode *N = C.generateErrorNode(StateNull)) {
-  C.emitReport(std::make_unique(
-  BT_FileNull, "Stream pointer might be NULL.", N));
+  auto R = std::make_unique(
+  BT_FileNull, "Stream pointer might be NULL.", N);
+  if (StreamE)
+bugreporter::trackExpressionValue(N, StreamE, *R);
+  C.emitReport(std::move(R));
 }
 return nullptr;
   }

diff  --git a/clang/test/Analysis/stream-note.c 
b/clang/test/Analysis/stream-note.c
index 71a5ba2315d9c..a509bb1b58315 100644
--- a/clang/test/Analysis/stream-note.c
+++ b/clang/test/Analysis/stream-note.c
@@ -77,3 +77,14 @@ void check_note_leak_2(int c) {
   fclose(F1);
   fclose(F2);
 }
+
+void check_track_null() {
+  FILE *F;
+  F = fopen("foo1.c", "r"); // expected-note {{Value assigned to 'F'}} 
expected-note {{Assuming pointer value is null}}
+  if (F != NULL) {  // expected-note {{Taking false branch}} 
expected-note {{'F' is equal to NULL}}
+fclose(F);
+return;
+  }
+  fclose(F); // expected-warning {{Stream pointer might be NULL}}
+  // expected-note@-1 {{Stream pointer might be NULL}}
+}



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

[PATCH] D104640: [clang][Analyzer] Track null stream argument in alpha.unix.Stream .

2021-06-22 Thread Balázs Kéri via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGd7227a5bc718: [clang][Analyzer] Track null stream argument 
in alpha.unix.Stream . (authored by balazske).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104640

Files:
  clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
  clang/test/Analysis/stream-note.c

Index: clang/test/Analysis/stream-note.c
===
--- clang/test/Analysis/stream-note.c
+++ clang/test/Analysis/stream-note.c
@@ -77,3 +77,14 @@
   fclose(F1);
   fclose(F2);
 }
+
+void check_track_null() {
+  FILE *F;
+  F = fopen("foo1.c", "r"); // expected-note {{Value assigned to 'F'}} expected-note {{Assuming pointer value is null}}
+  if (F != NULL) {  // expected-note {{Taking false branch}} expected-note {{'F' is equal to NULL}}
+fclose(F);
+return;
+  }
+  fclose(F); // expected-warning {{Stream pointer might be NULL}}
+  // expected-note@-1 {{Stream pointer might be NULL}}
+}
Index: clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/StreamChecker.cpp
@@ -306,7 +306,8 @@
   /// If it can only be NULL a fatal error is emitted and nullptr returned.
   /// Otherwise the return value is a new state where the stream is constrained
   /// to be non-null.
-  ProgramStateRef ensureStreamNonNull(SVal StreamVal, CheckerContext &C,
+  ProgramStateRef ensureStreamNonNull(SVal StreamVal, const Expr *StreamE,
+  CheckerContext &C,
   ProgramStateRef State) const;
 
   /// Check that the stream is the opened state.
@@ -472,7 +473,8 @@
CheckerContext &C) const {
   // Do not allow NULL as passed stream pointer but allow a closed stream.
   ProgramStateRef State = C.getState();
-  State = ensureStreamNonNull(getStreamArg(Desc, Call), C, State);
+  State = ensureStreamNonNull(getStreamArg(Desc, Call),
+  Call.getArgExpr(Desc->StreamArgNo), C, State);
   if (!State)
 return;
 
@@ -549,7 +551,8 @@
  CheckerContext &C) const {
   ProgramStateRef State = C.getState();
   SVal StreamVal = getStreamArg(Desc, Call);
-  State = ensureStreamNonNull(StreamVal, C, State);
+  State = ensureStreamNonNull(StreamVal, Call.getArgExpr(Desc->StreamArgNo), C,
+  State);
   if (!State)
 return;
   State = ensureStreamOpened(StreamVal, C, State);
@@ -573,7 +576,8 @@
   CheckerContext &C) const {
   ProgramStateRef State = C.getState();
   SVal StreamVal = getStreamArg(Desc, Call);
-  State = ensureStreamNonNull(StreamVal, C, State);
+  State = ensureStreamNonNull(StreamVal, Call.getArgExpr(Desc->StreamArgNo), C,
+  State);
   if (!State)
 return;
   State = ensureStreamOpened(StreamVal, C, State);
@@ -671,7 +675,8 @@
  CheckerContext &C) const {
   ProgramStateRef State = C.getState();
   SVal StreamVal = getStreamArg(Desc, Call);
-  State = ensureStreamNonNull(StreamVal, C, State);
+  State = ensureStreamNonNull(StreamVal, Call.getArgExpr(Desc->StreamArgNo), C,
+  State);
   if (!State)
 return;
   State = ensureStreamOpened(StreamVal, C, State);
@@ -790,7 +795,8 @@
CheckerContext &C) const {
   ProgramStateRef State = C.getState();
   SVal StreamVal = getStreamArg(Desc, Call);
-  State = ensureStreamNonNull(StreamVal, C, State);
+  State = ensureStreamNonNull(StreamVal, Call.getArgExpr(Desc->StreamArgNo), C,
+  State);
   if (!State)
 return;
   State = ensureStreamOpened(StreamVal, C, State);
@@ -814,7 +820,8 @@
 }
 
 ProgramStateRef
-StreamChecker::ensureStreamNonNull(SVal StreamVal, CheckerContext &C,
+StreamChecker::ensureStreamNonNull(SVal StreamVal, const Expr *StreamE,
+   CheckerContext &C,
ProgramStateRef State) const {
   auto Stream = StreamVal.getAs();
   if (!Stream)
@@ -827,8 +834,11 @@
 
   if (!StateNotNull && StateNull) {
 if (ExplodedNode *N = C.generateErrorNode(StateNull)) {
-  C.emitReport(std::make_unique(
-  BT_FileNull, "Stream pointer might be NULL.", N));
+  auto R = std::make_unique(
+  BT_FileNull, "Stream pointer might be NULL.", N);
+  if (StreamE)
+bugreporter::trackExpressionValue(N, StreamE, *R);
+  C.emitReport(std::move(R));
 }
 return nullptr;
   }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D103793: [Clang][OpenMP] Monotonic does not apply to SIMD

2021-06-22 Thread Graham Hunter via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGc6a91ee6: [Clang][OpenMP] Monotonic does not apply to 
SIMD (authored by huntergr).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103793

Files:
  clang/lib/CodeGen/CGStmtOpenMP.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/OpenMP/distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/distribute_simd_codegen.cpp
  clang/test/OpenMP/for_simd_codegen.cpp
  clang/test/OpenMP/parallel_for_simd_codegen.cpp
  clang/test/OpenMP/schedule_codegen.cpp
  clang/test/OpenMP/target_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_parallel_for_simd_if_codegen.cpp
  
clang/test/OpenMP/target_teams_distribute_parallel_for_simd_schedule_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_simd_codegen.cpp
  clang/test/OpenMP/target_teams_distribute_simd_dist_schedule_codegen.cpp
  clang/test/OpenMP/teams_distribute_parallel_for_simd_schedule_codegen.cpp
  clang/test/OpenMP/teams_distribute_simd_codegen.cpp
  clang/test/OpenMP/teams_distribute_simd_dist_schedule_codegen.cpp

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


[PATCH] D93373: [Flang][Openmp] Upgrade TASKGROUP construct to 5.0.

2021-06-22 Thread Chirag Khandelwal via Phabricator via cfe-commits
AMDChirag added a comment.

@kiranchandramohan It failed again. Apparently, it automatically attempted to 
add a patch D93105  which is already merged. I 
removed that patch as dependency before (edit related revisions), but it seems 
to have been added again.
Am I missing something?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93373

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


[PATCH] D103440: [WIP][analyzer] Introduce range-based reasoning for addition operator

2021-06-22 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko added inline comments.



Comment at: clang/test/Analysis/constant-folding.c:280-281
+  if (c < 0 && c != INT_MIN && d < 0) {
+clang_analyzer_eval((c + d) == -1); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}}
+clang_analyzer_eval((c + d) <= -2); // expected-warning{{UNKNOWN}}

manas wrote:
> manas wrote:
> > vsavchenko wrote:
> > > manas wrote:
> > > > vsavchenko wrote:
> > > > > manas wrote:
> > > > > > When I pull these cases out to a separate function (say 
> > > > > > testAdditionRules2) in constant-folding.c then algorithm is able to 
> > > > > > reason about the range correctly, but inside testAdditionRules, it 
> > > > > > is unable to figure stuff out. Does it have something to do with 
> > > > > > constraints being propagated which we discussed below?
> > > > > > 
> > > > > > @vsavchenko wrote: 
> > > > > > > I have one note here.  The fact that we don't have a testing 
> > > > > > > framework and use this approach of inspecting the actual analysis 
> > > > > > > has an interesting implication.
> > > > > > > 
> > > > > > > ```
> > > > > > > if (a == 10) { // here we split path into 2 paths: one where a == 
> > > > > > > 10, and one where a != 10;
> > > > > > >// one goes inside of if, one doesn't
> > > > > > >   . . .
> > > > > > > }
> > > > > > > if (a >= 5) { // here we split into 3 paths: a == 10, a < 5, and 
> > > > > > > a in [5, 9] and [11, INT_MAX] (aka a >= 5 and a != 10).
> > > > > > >   // 1 path was infeasible: a == 10 and a < 5
> > > > > > >   // Two of these paths go inside of the if, one 
> > > > > > > doesn't
> > > > > > >   . . .
> > > > > > >   clang_analyzer_eval(a == 10); // it will produce two results: 
> > > > > > > TRUE and FALSE
> > > > > > > }
> > > > > > > clang_analyzer_eval(a == 10); // it will produce three results: 
> > > > > > > TRUE, FALSE, and FALSE
> > > > > > > ```
> > > > > > > 
> > > > > > > We don't want to test how path splitting works in these 
> > > > > > > particular tests (they are about solver and constant folding 
> > > > > > > after all), that's why we try to have only one path going through 
> > > > > > > each `clang_analyzer_eval(...)`
> > > > > > > 
> > > > > > 
> > > > > > 
> > > > > It might be that or it might be something different.  Just by looking 
> > > > > at this example, the previous `if` statement shouldn't add more paths 
> > > > > that go inside of this `if`, so it shouldn't be the root cause.
> > > > > Whenever you encounter problems and you want to tell other people, 
> > > > > **please, provide more detail**.  Did you notice it when running the 
> > > > > test case?  What was the output?  What did you try?  How did you 
> > > > > extract it into a separate function?
> > > > I put a new test function in `constant-folding.c` as:
> > > > 
> > > > ```
> > > > void testAdditionRulesNew(int c, int d) {
> > > >   if (c < 0 && c != INT_MIN && d < 0) {
> > > > clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}}
> > > >   }
> > > > }
> > > > ```
> > > > I tested this specific function as:
> > > > 
> > > >   ./build/bin/clang -cc1 -analyze 
> > > > -analyzer-checker=core,debug.ExprInspection 
> > > > -analyze-function=testAdditionRulesNew constant-folding.c
> > > > 
> > > > And I got the following output:
> > > > 
> > > >   ../clang/test/Analysis/constant-folding.c:338:5: warning: FALSE 
> > > > [debug.ExprInspection]
> > > > clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}}
> > > > 
> > > > which is correct.
> > > > 
> > > > But when I ran the same test inside `testAdditionRules`, using:
> > > > ./build/bin/clang -cc1 -analyze 
> > > > -analyzer-checker=core,debug.ExprInspection 
> > > > -analyze-function=testAdditionRules constant-folding.c
> > > > then I got:
> > > > 
> > > >   ../clang/test/Analysis/constant-folding.c:281:5: warning: FALSE 
> > > > [debug.ExprInspection]
> > > > clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}} 
> > > > 
> > > >
> > > > ^   
> > > >
> > > >   ../clang/test/Analysis/constant-folding.c:281:5: warning: TRUE 
> > > > [debug.ExprInspection]
> > > > clang_analyzer_eval((c + d) == 0); // expected-warning{{FALSE}} 
> > > > 
> > > >
> > > > ^  
> > > > 
> > > > Here, `c = [INT_MIN + 1, -1]` and `d = [INT_MIN, 0]`, so `c + d = 
> > > > [INT_MIN, -2] U [1, INT_MAX]`. So `c + d == 0` should be false. But in 
> > > > latter case, it is reasoning `c + d == 0` to be `UNKNOWN`.
> > > > 
> > > > Also, the error arises in `c + d == 0` case only and not in `c + d == 
> > > > -1` case. I mistakenly highlighted that cas

[PATCH] D97915: [Coroutines] Handle overaligned frame allocation

2021-06-22 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added a comment.

In D97915#2832446 , @ychen wrote:

> In D97915#2829581 , @ChuanqiXu wrote:
>
>> A remained question.
>>
>> - what's the semantics if user specified their allocation/deallocation 
>> functions?
>>
>> Previously, we discussed for the ::operator new and ::operator delete. But 
>> what would we do for user specified allocation/deallocation functions?
>> It looks like we would treat them just like `::operator new`. And it makes 
>> sense at the first glance. But the problem comes from that we judge whether
>> or not to over allocate a frame by this condition:
>>
>>   coro.align > align of new
>>
>> But if the user uses their new, it makes no sense to use the `align of new` 
>> as the condition. On the other hand, if user specified their new function 
>> and the 
>> alignment requirement for their promise type, would it be better really that 
>> the compiler do the extra transformation?
>>
>> May be we need to discuss with other guys who are more familiar with the C++ 
>> standard to answer this.
>
> I think @rjmccall could answer these. My understanding is that user-specified 
> allocation/deallocation has the same semantics as their standard library's 
> counterparts. `align of new` (aka __STDCPP_DEFAULT_NEW_ALIGNMENT__) should 
> apply to both.

Yeah, I just curious about the question and not sure about the answer yet. I 
agree with that it should be safe if we treat user-specified 
allocation/deallocation as ::operator new. Maybe I am a little bit of pedantry. 
I just not sure if the developer would be satisfied when they find we allocate 
padding space they didn't want when they offered a new/delete method. (Maybe I 
am too anxious).

---

Another problem I find in this patch is that the introduction for `raw frame` 
makes the frame confusing. For example, the following codes is aim to calculate 
the size for the over allocated  frame:

  %[[SIZE:.+]] = call i64 @llvm.coro.size.i64()
  %[[NEWSIZE:.+]] = add i64 %[[SIZE]], %[[PAD]]
  %[[MEM2:.+]] = call noalias nonnull i8* @_Znwm(i64 %[[NEWSIZE]])

It makes sense only if `llvm.coro.size` stands for the size of 'true frame' (I 
am not sure what's the meaning for raw frame now. Let me use 'true frame' 
temporarily). But the document now says that '@llvm.coro.size' returns the size 
of the frame. It's confusing
I am not require to fix it by rename 'llvm.coro.size' or rephrase the document 
simply. I am thinking about the the semantics of coroutine intrinsics after we 
introduce the concept of 'raw frame'.




Comment at: clang/lib/CodeGen/CGCoroutine.cpp:424
+// dynamically adjust the frame start address at runtime.
+void OverAllocateFrame(CodeGenFunction &CGF, llvm::CallInst *CI, bool IsAlloc) 
{
+  unsigned CoroSizeIdx = IsAlloc ? 0 : 1;

So if this would be called for deallocate. the function name is confusing. I 
think it may be better to rename it as something like 
'GeSizeOFtOverAlignedFrame' (The name suggested looks not good too).
By the way, now I am wondering why wouldn't we use llvm.coro.size directly? And 
make the middle end to handle it. How do you think about it?



Comment at: clang/lib/CodeGen/CGCoroutine.cpp:719
+  auto *AlignedUpAddr =
+  EmitBuiltinAlignTo(AlignedAllocateCall, CoroAlign, S.getAllocate(), 
true);
+  // rawFrame = frame

How do your think about to replace EmitBuiltinAlignTo inplace?



Comment at: clang/lib/CodeGen/CGCoroutine.cpp:452-461
+  llvm::Function *RawFramePtrOffsetIntrin = CGF.CGM.getIntrinsic(
+  llvm::Intrinsic::coro_raw_frame_ptr_offset, CGF.Int32Ty);
+  auto *RawFramePtrOffset = CGF.Builder.CreateCall(RawFramePtrOffsetIntrin);
+  auto *FramePtrAddrStart =
+  CGF.Builder.CreateInBoundsGEP(CoroFree, {RawFramePtrOffset});
+  auto *FramePtrAddr = CGF.Builder.CreatePointerCast(
+  FramePtrAddrStart, CGF.Int8PtrTy->getPointerTo());

ychen wrote:
> ChuanqiXu wrote:
> > We allocate overaligned-frame like:
> > ```
> > | --- for align --- | --- true frame --- |
> > ```
> > And here we set the argument to the address of true frame. Then I wonder 
> > how about the memory for the `for align` part. Would we still free them 
> > correctly? Maybe I missed something.
> > Would we still free them correctly? 
> Yes, that's the tricky part. Using `f0` of `coro-alloc.cpp` as an example, 
> `llvm.coro.raw.frame.ptr.addr` is called at alloc time to save the raw memory 
> pointer to the coroutine frame.  Later at dealloc time, 
> `llvm.coro.raw.frame.ptr.addr` is called again to load the raw memory pointer 
> back and free it.
To make it clear, what's the definition for 'raw ptr'? From the context, I 
think it means the true frame in above diagram from the context.

So this confuses me:
> llvm.coro.raw.frame.ptr.addr is called again to load the raw memory pointer 
> back and free it.

If the raw memory means the true 

[PATCH] D102107: [OpenMP] Codegen aggregate for outlined function captures

2021-06-22 Thread Alexey Bataev via Phabricator via cfe-commits
ABataev added a comment.

In D102107#2832286 , @jdoerfert wrote:

> In D102107#2824581 , @ABataev wrote:
>
>> In D102107#2823706 , @jdoerfert 
>> wrote:
>>
>>> In D102107#2821976 , @ABataev 
>>> wrote:
>>>
 We used this kind of codegen initially but later found out that it causes 
 a large overhead when gathering pointers into a record. What about hybrid 
 scheme where the first args are passed as arguments and others (if any) 
 are gathered into a record?
>>>
>>> I'm confused, maybe I misunderstand the problem. The parallel function 
>>> arguments need to go from the main thread to the workers somehow, I don't 
>>> see how this is done w/o a record. This patch makes it explicit though.
>>
>> Pass it in a record for workers only? And use a hybrid scheme for all other 
>> parallel regions.
>
> I still do not follow. What does it mean for workers only? What is a hybrid 
> scheme? And, probably most importantly, how would we not eventually put 
> everything into a record anyway?

On the host you don’t need to put everything into a record, especially for 
small parallel regions. Pass some first args in registers and only the 
remaining args gather into the record. For workers just pass all args in the 
record.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102107

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


[PATCH] D104680: [clang] Eliminate relational function pointer comparisons in all C++ modes

2021-06-22 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov updated this revision to Diff 353596.
mizvekov added a comment.
Herald added a project: Sanitizers.
Herald added a subscriber: Sanitizers.

- Update more tests.
- Slightly improved error recovery: deduce type for non-three-way relational 
comparisons.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104680

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CXX/class/class.compare/class.spaceship/p2.cpp
  clang/test/CXX/drs/dr15xx.cpp
  clang/test/CXX/drs/dr3xx.cpp
  clang/test/CXX/expr/expr.const/p2-0x.cpp
  clang/test/FixIt/fixit.cpp
  clang/test/Parser/cxx-template-argument.cpp
  clang/test/Sema/compare.c
  clang/test/SemaCXX/compare-cxx2a.cpp
  clang/test/SemaCXX/compare-function-pointer.cpp
  clang/test/SemaTemplate/resolve-single-template-id.cpp
  compiler-rt/test/asan/TestCases/Posix/coverage-module-unloaded.cpp

Index: compiler-rt/test/asan/TestCases/Posix/coverage-module-unloaded.cpp
===
--- compiler-rt/test/asan/TestCases/Posix/coverage-module-unloaded.cpp
+++ compiler-rt/test/asan/TestCases/Posix/coverage-module-unloaded.cpp
@@ -13,6 +13,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -38,10 +39,11 @@
 
   // It matters whether the unloaded module has a higher or lower address range
   // than the remaining one. Make sure to test both cases.
+  bool lt = reinterpret_cast(bar1) < reinterpret_cast(bar2);
   if (argc < 2)
-dlclose(bar1 < bar2 ? handle1 : handle2);
+dlclose(lt ? handle1 : handle2);
   else
-dlclose(bar1 < bar2 ? handle2 : handle1);
+dlclose(lt ? handle2 : handle1);
   return 0;
 }
 #endif
Index: clang/test/SemaTemplate/resolve-single-template-id.cpp
===
--- clang/test/SemaTemplate/resolve-single-template-id.cpp
+++ clang/test/SemaTemplate/resolve-single-template-id.cpp
@@ -66,11 +66,13 @@
 
   b = (void (*)()) twoT;
   
-  one < one; //expected-warning {{self-comparison always evaluates to false}} \
- //expected-warning {{relational comparison result unused}} 
+  one < one; // expected-warning {{self-comparison always evaluates to false}} \
+ // expected-warning {{relational comparison result unused}}   \
+ // expected-error   {{ordered comparison of function pointers}}
 
-  oneT < oneT;  //expected-warning {{self-comparison always evaluates to false}} \
-  //expected-warning {{relational comparison result unused}}
+  oneT < oneT;  // expected-warning {{self-comparison always evaluates to false}} \
+  // expected-warning {{relational comparison result unused}}   \
+  // expected-error   {{ordered comparison of function pointers}}
 
   two < two; //expected-error 2 {{reference to overloaded function could not be resolved; did you mean to call it with no arguments?}} expected-error {{invalid operands to binary expression ('void' and 'void')}}
   twoT < twoT; //expected-error {{reference to overloaded function could not be resolved; did you mean to call it?}} {{cannot resolve overloaded function 'twoT' from context}}
Index: clang/test/SemaCXX/compare-function-pointer.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/compare-function-pointer.cpp
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify %s
+
+using fp_t = void (*)();
+extern fp_t a, b;
+
+bool eq = a == b;
+bool ne = a != b;
+bool lt = a < b;   // expected-error {{ordered comparison of function pointers ('fp_t' (aka 'void (*)()') and 'fp_t')}}
+bool le = a <= b;  // expected-error {{ordered comparison of function pointers}}
+bool gt = a > b;   // expected-error {{ordered comparison of function pointers}}
+bool ge = a >= b;  // expected-error {{ordered comparison of function pointers}}
+bool tw = a <=> b; // expected-error {{ordered comparison of function pointers}}
Index: clang/test/SemaCXX/compare-cxx2a.cpp
===
--- clang/test/SemaCXX/compare-cxx2a.cpp
+++ clang/test/SemaCXX/compare-cxx2a.cpp
@@ -212,8 +212,6 @@
 struct ClassB : Class {};
 struct Class2 {};
 using FnTy = void(int);
-using FnTy2 = long(int);
-using FnTy3 = void(int) noexcept;
 using MemFnTy = void (Class::*)() const;
 using MemDataTy = long(Class::*);
 
@@ -232,11 +230,6 @@
   (void)(md <=> md); // expected-error {{invalid operands}} expected-warning {{self-comparison}}
 }
 
-void test_compatible_pointer(FnTy *f1, FnTy2 *f2, FnTy3 *f3) {
-  (void)(f1 <=> f2); // expected-error {{distinct pointer types}}
-  (void)(f1 <=> f3); // expected-error {{invalid operands}}
-}
-
 // Test that variable narrowing is deferred for value dependent ex

[PATCH] D96568: [CFE, SystemZ] Emit s390.tdc instrincic for __builtin_isnan in Constrained FP mode.

2021-06-22 Thread Thomas Preud'homme via Phabricator via cfe-commits
thopre added a comment.

In D96568#2569296 , @jonpa wrote:

>> Sounds good to me. Hopefully I'll get round to __builtin_isinf soon and a 
>> single hook will make the patch slightly smaller.
>
> Patch updated to call the new hook testFPKind() and make it take a BuiltinID 
> as argument (that seems to work at least for the moment - maybe an enum type 
> will become necessary at some point per your suggestion..?)
>
> I am not sure if this is "only" or "typically" used in constrained FP mode, 
> or if the mode should be independent of calling this hook. The patch as it is 
> asserts that it is called for an FP type but leaves it to the target to 
> decide based on the FP mode, where SystemZ opts out unless it is constrained 
> (which I think is what is wanted...).

I forgot to ask at the time, why do you restrict this code to the constrained 
case? Presumably it's a lot faster than fabs+cmp and should be faster in all 
cases?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D96568

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


[PATCH] D44609: [clang-format] New option BeforeLambdaBody to manage lambda line break inside function parameter call (in Allman style)

2021-06-22 Thread Mike Weller via Phabricator via cfe-commits
Userbla added a comment.

I applied this fix locally to a branch based off llvm 11.x and the 
`FormatTest.FormatsTypedefEnum` test now fails.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D44609

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


[PATCH] D93938: [clang-format] Fixed AfterEnum handling

2021-06-22 Thread Mike Weller via Phabricator via cfe-commits
Userbla added a comment.

I applied this fix locally to a branch based off llvm 11.x and the 
`FormatTest.FormatsTypedefEnum` test now fails.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93938

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


[PATCH] D104649: Thread safety analysis: Rename parameters of ThreadSafetyAnalyzer::intersectAndWarn (NFC)

2021-06-22 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman accepted this revision.
aaron.ballman added a comment.
This revision is now accepted and ready to land.

LGTM! Thank you for the terminology cleanup.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104649

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


[PATCH] D104677: [OpenMP][AMDGCN] Apply fix for isnan, isinf and isfinite for amdgcn.

2021-06-22 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

Looks very similar to the cuda workaround. Any chance we can #include to use 
the same code in both?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104677

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


[PATCH] D104261: Thread safety analysis: Always warn when dropping locks on back edges

2021-06-22 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

I think the CI failure (libarcher.races::lock-unrelated.c) is not related to 
this patch but is a tsan thing, but you may want to double-check that just in 
case.

I think this looks reasonable, but I'd like to hear from @delesley before 
landing.




Comment at: clang/test/SemaCXX/warn-thread-safety-analysis.cpp:643
 sls_mu.Lock();  // \
-  // expected-note {{the other acquisition of mutex 'sls_mu' is here}}
+  // expected-warning {{mutex 'sls_mu' is acquired exclusively and shared 
in the same scope}}
   } while (getBool());

aaronpuchert wrote:
> These are just swapped because I'm merging the branches in a different order 
> now. I think that's Ok.
I think the new order is actually an improvement because it diagnoses the 
second acquisition (diagnosing the first is a bit weirdly predictive for my 
tastes).



Comment at: clang/test/SemaCXX/warn-thread-safety-analysis.cpp:2806-2816
+void loopReleaseContinue() {
+  RelockableMutexLock scope(&mu, ExclusiveTraits{}); // expected-note {{mutex 
acquired here}}
+  // We have to warn on this join point despite the lock being managed ...
+  for (unsigned i = 1; i < 10; ++i) {
+x = 1; // ... because we might miss that this doesn't always happen under 
lock.
+if (i == 5) {
+  scope.Unlock();

How about a test like:
```
void foo() {
  RelockableMutexLock scope(&mu, ExclusiveTraits{});
  for (unsigned i = 1; i < 10; ++i) {
if (i > 0) // Always true
  scope.Lock(); // So we always lock
x = 1; // So I'd assume we don't warn
  }
}


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104261

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


[PATCH] D102186: [clang][c++20] Fix false warning for unused private fields when a class has only defaulted comparison operators.

2021-06-22 Thread Alexandru Octavian Buțiu via Phabricator via cfe-commits
predator5047 marked an inline comment as done.
predator5047 added a comment.

@hans Can you commit on my behalf? 
Email: Alexandru Octavian Butiu alexandru.octavian.butiu at gmail.com


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102186

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


[PATCH] D104550: [analyzer] Implement getType for SVal

2021-06-22 Thread Artem Dergachev via Phabricator via cfe-commits
NoQ added inline comments.



Comment at: clang/lib/StaticAnalyzer/Core/SVals.cpp:151
+  Optional VisitNonLocLazyCompoundVal(nonloc::LazyCompoundVal LCV) {
+return Visit(LCV.getRegion());
+  }

vsavchenko wrote:
> NoQ wrote:
> > vsavchenko wrote:
> > > NoQ wrote:
> > > > This is correct except you need to get the value type, not the pointer 
> > > > type.
> > > > 
> > > > `LazyCompoundVal` is a `prvalue` and its parent region is the location 
> > > > in which this `prvalue` resided some time in the past. So the parent 
> > > > region is of the right type and it's always typed but you need the 
> > > > pointee type.
> > > OK then, can you maybe hint how can I write a test where this is going to 
> > > be a pointer type (or maybe then `getType` for regions works incorrectly).
> > Regions have `getLocationType()` (the pointer type) and `getValueType()` 
> > (the pointee type). I think you need to call the latter directly in this 
> > case, bypassing recursion.
> > 
> > In order to obtain a live `LazyCompoundVal` specimen for testing purposes, 
> > you need to load an entire compound object (not necessarily represented by 
> > a `CompoundVal`) from Region Store.
> > 
> > Eg.,
> > ```lang=c
> >   struct MyStruct a;
> >   // ...
> >   struct MyStruct b = a; // Avoid C++ though, constructors are a different 
> > beast.
> > ```
> > 
> > Or you could construct one directly. But that, of course, wouldn't give you 
> > any hints about the appropriate type.
> > 
> > > maybe then `getType` for regions works incorrectly
> > 
> > Hmm that's actually a good separate question. How do you know if a region 
> > represents a prvalue of pointer type or a glvalue of pointee type 
> > (including, but not limited to, references)? This can't be figured out 
> > without more context just by looking at the `SVal`.
> > In order to obtain a live LazyCompoundVal specimen for testing purposes.
> That's not a problem:
> ```
> TestUnion d = {.c=b};
> ```
> does produce LazyCompundVal and we don't get a pointer, but the value type.  
> That's why I was asking how I can construct an example when this current 
> implementation fails.
> 
> > Hmm that's actually a good separate question. How do you know if a region 
> > represents a prvalue of pointer type or a glvalue of pointee type 
> > (including, but not limited to, references)? This can't be figured out 
> > without more context just by looking at the SVal.
> Value categories are orthogonal to types, so I don't see why we should care 
> for those in `getType`.  How do you think it should affect this particular 
> functionality?
> `TestUnion d = {.c=b};`

```
(lldb) p D.dump()
compoundVal{ lazyCompoundVal{0x1110b3950,temp_object{struct TestStruct, S1276}}}
```

It's an eager compound value that contains a lazy compound value as the 
initializer for field `.c`.

You're still testing an eager compound value. You never visit the lazy compound 
value recursively.

`MemRegion::getLocationType()` is always a pointer type.

> Value categories are orthogonal to types, so I don't see why we should care 
> for those in `getType`. How do you think it should affect this particular 
> functionality?

The static analyzer basically models operators `*` and `&` as no-op but from 
the perspective of the standard's formalism they jump across objects.

For example, a load from parameter `int *p` would produce a value 
`&SymRegion{reg_$0}` that represents both the rvalue of `p` (which has the 
type `int *`) and the lvalue of `*p` (which is an entirely different object of 
type `int`).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104550

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


[PATCH] D104550: [analyzer] Implement getType for SVal

2021-06-22 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added a comment.

This is not an urgent, but still a very important issue: `SVal` is likely among 
the first things a new developer in the analyzer sees. Its common around the 
university here that some students barely halfway through their BSc are given 
smaller tasks, like the implementation of a checker in the static analyzer. 
Instead of

  // Try to get a reasonable type for the given value.

Maybe we should tell why this might fail, why its not just a type but a best 
effort, etc.

Despite being in the analyzer for so long, I don't have anything anything 
meaningful to add just yet :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104550

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


[PATCH] D104439: [analyzer][NFC] Demonstrate a move from the analyzer-configs `.def` file to a TableGen file

2021-06-22 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added a comment.

Ping.

The main question with this patch really is whether we want TableGen at all or 
not, as for what we generate precisely and how we'd utilize it is a discussion 
for later.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104439

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


[PATCH] D104550: [analyzer] Implement getType for SVal

2021-06-22 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko added a comment.

In D104550#2832983 , @Szelethus wrote:

> This is not an urgent, but still a very important issue: `SVal` is likely 
> among the first things a new developer in the analyzer sees. Its common 
> around the university here that some students barely halfway through their 
> BSc are given smaller tasks, like the implementation of a checker in the 
> static analyzer. Instead of
>
>   // Try to get a reasonable type for the given value.
>
> Maybe we should tell why this might fail, why its not just a type but a best 
> effort, etc.
>
> Despite being in the analyzer for so long, I don't have anything anything 
> meaningful to add just yet :)

That's a good point!  I guess the main obstacle for a meaningful description of 
"why this might fail" is what @NoQ mentioned: "all values are supposed to be 
typed".  But if we go that deep in one commit (even doing it for a rather 
simple pointer-to-member case is not so small of a change), we won't get this 
feature at all.  Do you think that "for the sake of incremental approach"-like 
comment can help?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104550

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


[PATCH] D93938: [clang-format] Fixed AfterEnum handling

2021-06-22 Thread Mike Weller via Phabricator via cfe-commits
Userbla added a comment.

In D93938#2832825 , @Userbla wrote:

> I applied this fix locally to a branch based off llvm 11.x and the 
> `FormatTest.FormatsTypedefEnum` test now fails.

So this test is failing:

  TEST_F(FormatTest, LongEnum) {
FormatStyle Style = getLLVMStyle();
Style.AllowShortEnumsOnASingleLine = true;
Style.ColumnLimit = 40;
  
Style.BreakBeforeBraces = FormatStyle::BS_Custom;
Style.BraceWrapping.AfterEnum = false;
  
verifyFormat("enum {\n"
 "  ZERO = 0,\n"
 "  ONE = 1,\n"
 "  TWO = 2,\n"
 "  THREE = 3\n"
 "} LongEnum;",
 Style);
Style.BreakBeforeBraces = FormatStyle::BS_Custom;
Style.BraceWrapping.AfterEnum = true;
verifyFormat("enum\n"
 "{\n"
 "  ZERO = 0,\n"
 "  ONE = 1,\n"
 "  TWO = 2,\n"
 "  THREE = 3\n"
 "} LongEnum;",
 Style);
  }

It fails in the second case because we don't respect the 'AfterEnum = true' and 
collapse the brace. It appears there is buggy logic in the 
`remainingLineCharCount` stuff which others have already been commenting on


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93938

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


[PATCH] D104439: [analyzer][NFC] Demonstrate a move from the analyzer-configs `.def` file to a TableGen file

2021-06-22 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko added a comment.

In D104439#2832984 , @Szelethus wrote:

> Ping.
>
> The main question with this patch really is whether we want TableGen at all 
> or not, as for what we generate precisely and how we'd utilize it is a 
> discussion for later.

I don't really have strong opinions here.  On one hand, I'd prefer TableGen to 
a purely macro-based solution.  On the other hand, something, let's say, 
C++-native (like `cl::opt`) seems better than TableGen.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104439

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


[PATCH] D93938: [clang-format] Fixed AfterEnum handling

2021-06-22 Thread Mike Weller via Phabricator via cfe-commits
Userbla added a comment.

In D93938#2833045 , @Userbla wrote:

> It fails in the second case because we don't respect the 'AfterEnum = true' 
> and collapse the brace. It appears there is buggy logic in the 
> `remainingLineCharCount` stuff which others have already been commenting on

Apologies, late to the party here... this fix suggested by curdeius does indeed 
fix the issue:

> Since you use `== ' '` twice, `remainingLineCharCount` will count only 
> consecutive spaces, right?
> But you want to count other characters, no?
> So, IIUC, the condition you want is `rF[wI] != '\n' && !(rF[wI] == ' ' && 
> rF[wI - 1] == ' ')` (mind the negation). It will count characters other than 
> a newline and it will only count a series of consecutive spaces as one char. 
> WDYT?




Comment at: clang/lib/Format/TokenAnnotator.cpp:3679-3680
+if (remainingFile[whileIndex] != '\n' &&
+(remainingFile[whileIndex] == ' ' &&
+ remainingFile[whileIndex - 1] == ' ')) {
+  remainingLineCharCount++;

atirit wrote:
> curdeius wrote:
> > atirit wrote:
> > > curdeius wrote:
> > > > I don't really understand these conditions on spaces. Could you explain 
> > > > your intent, please?
> > > > You really need to add specific tests for that, playing with the value 
> > > > of ColumnLimit, adding spacing etc.
> > > Repeated spaces, e.g. `enum {   A,  B, C } SomeEnum;` are removed during 
> > > formatting. Since they wouldn't be part of the formatted line, they 
> > > shouldn't be counted towards the column limit. Only one space need be 
> > > considered. Removed spaces, e.g. `enum{A,B,C}SomeEnum;` are handled by 
> > > the fact that `clang-format` runs multiple passes. On the first pass, 
> > > spaces would be added. On the second pass, assuming the line is then too 
> > > long, the above code would catch it and break up the enum.
> > > 
> > > I'll add unit tests to check if spaces are being handled correctly.
> > Since you use `== ' '` twice, `remainingLineCharCount` will count only 
> > consecutive spaces, right?
> > But you want to count other characters, no?
> > So, IIUC, the condition you want is `rF[wI] != '\n' && !(rF[wI] == ' ' && 
> > rF[wI - 1] == ' ')` (mind the negation). It will count characters other 
> > than a newline and it will only count a series of consecutive spaces as one 
> > char. WDYT?
> Ah yes, that's my bad. Must have made a typo. Fixed in the next commit.
> Since you use `== ' '` twice, `remainingLineCharCount` will count only 
> consecutive spaces, right?
> But you want to count other characters, no?
> So, IIUC, the condition you want is `rF[wI] != '\n' && !(rF[wI] == ' ' && 
> rF[wI - 1] == ' ')` (mind the negation). It will count characters other than 
> a newline and it will only count a series of consecutive spaces as one char. 
> WDYT?




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93938

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


[PATCH] D104550: [analyzer] Implement getType for SVal

2021-06-22 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added a comment.

In D104550#2833020 , @vsavchenko 
wrote:

> Do you think that "for the sake of incremental approach"-like comment can 
> help?

A `TODO:` should be good enough for now. I see this is still a moving target.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104550

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


[PATCH] D104136: [analyzer] Add better tracking for RetainCountChecker leak warnings

2021-06-22 Thread Kristóf Umann via Phabricator via cfe-commits
Szelethus added inline comments.



Comment at: 
clang/lib/StaticAnalyzer/Checkers/RetainCountChecker/RetainCountDiagnostics.cpp:953-957
+  // Let's traverse...
+  for (const ExplodedNode *N = ExprNode;
+   // ...all the nodes corresponding to the given expression...
+   N != nullptr && N->getStmtForDiagnostics() == E;
+   N = N->getFirstPred()) {

vsavchenko wrote:
> Szelethus wrote:
> > vsavchenko wrote:
> > > NoQ wrote:
> > > > I guess this part should ultimately be written in one place, eg. 
> > > > `ExplodedNode::findTag()` or something like that.
> > > > 
> > > > I'd also really like to explore the possibility to further limit the 
> > > > variety of nodes traversed here. What nodes are typically traversed 
> > > > here? Is it checker-tagged nodes or is it purge dead symbol nodes or 
> > > > something else?
> > > Yes, `ExplodedNode::findTag()` sounds like a great idea!
> > > 
> > > I mean it is hard to tell without calculating statistics right here and 
> > > running it on a bunch of projects.  However, it is always possible to 
> > > write the code that will have it the other way.  My take on it is that it 
> > > is probably a mix of things.
> > > 
> > > I'd also prefer to traverse less, do you have any specific ideas here?
> > > I'd also really like to explore the possibility to further limit the 
> > > variety of nodes traversed here. What nodes are typically traversed here? 
> > > Is it checker-tagged nodes or is it purge dead symbol nodes or something 
> > > else?
> > 
> > Is there something I'm not seeing here? Trackers basically ascend //a// 
> > path from the error node to at most the root of the ExplodedGraph (not the 
> > trimmed version, as `Tracker::track()` is called before any of that process 
> > happens), so its not much slower than `trackExpressionValue`, right?
> > 
> > Or does this, and likely many other future handlers run such a loop more 
> > often then what I imagine?
> > 
> > 
> Essentially, yes.  `trackExpressionValue` (and `Tracker::track`) ascend the 
> graph searching for a node where the give expression is evaluated.  The 
> problem here is that whenever we ask to track some expression, not only 
> `trackExpressionValue` will do its traversal (much longer), but also this 
> handler will do its (shorter).  It would be better not to do this altogether, 
> but I personally don't see any solutions how we can cut on this part.
> At the same time, I don't think that it is performance critical, considering 
> that the part of the graph where `N->getStmtForDiagnostics() == E` is small.
Ah, so, this is your patch:

```
E: Error Node
C: Identity function call
V: Argument evaluation
A: Origin of the argument value
>: Nodes traversed by the tracker
>: Nodes traversed by the handler

*  *   *   *
E->O->O->O->O->C->O->O->O->V->O->O->O->A->X->X->X

--->  
   >--->
```
This is fine, because its just a single ascend, made a little worse by the fact 
that we do it for each tracked variable. But later, with more handlers, it 
might get worse (per variable):
```
*  *   *   *
E->O->O->O->O->C->O->O->O->V->O->O->O->A->X->X->X

--->   
   >--->
   ===>->
   ==>-->
   =>
   ==>
```
Now, I can't immediately imagine a case where someone would add THAT many 
handlers, or track that many variables, even in extreme circumstances, but I 
don't posses a crystal ball either :^)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104136

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


[PATCH] D104484: [clang] Add cc1 option for dumping layout for all complete types

2021-06-22 Thread David Tenty via Phabricator via cfe-commits
daltenty updated this revision to Diff 353636.
daltenty added a comment.

- clang-format
- Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104484

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/AST/Decl.cpp
  clang/test/Layout/dump-complete.cpp


Index: clang/test/Layout/dump-complete.cpp
===
--- /dev/null
+++ clang/test/Layout/dump-complete.cpp
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -emit-llvm-only -fdump-record-layouts-complete %s | 
FileCheck %s
+
+struct a {
+  int x;
+};
+
+struct b {
+  char y;
+} foo;
+
+class c {};
+
+class d;
+
+// CHECK:  0 | struct a
+// CHECK:  0 | struct b
+// CHECK:  0 | class c
+// CHECK-NOT:  0 | class d
Index: clang/lib/AST/Decl.cpp
===
--- clang/lib/AST/Decl.cpp
+++ clang/lib/AST/Decl.cpp
@@ -4581,6 +4581,13 @@
 void RecordDecl::completeDefinition() {
   assert(!isCompleteDefinition() && "Cannot redefine record!");
   TagDecl::completeDefinition();
+
+  ASTContext &Ctx = getASTContext();
+
+  // Layouts are dumped when computed, so if we are dumping for all complete
+  // types, we need to force usage to get types that wouldn't be used 
elsewhere.
+  if (Ctx.getLangOpts().DumpRecordLayoutsComplete)
+(void)Ctx.getASTRecordLayout(this);
 }
 
 /// isMsStruct - Get whether or not this record uses ms_struct layout.
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -5371,10 +5371,13 @@
 def fdump_record_layouts_simple : Flag<["-"], "fdump-record-layouts-simple">,
   HelpText<"Dump record layout information in a simple form used for testing">,
   MarshallingInfoFlag>;
+def fdump_record_layouts_complete : Flag<["-"], 
"fdump-record-layouts-complete">,
+  HelpText<"Dump record layout information for all complete types">,
+  MarshallingInfoFlag>;
 def fdump_record_layouts : Flag<["-"], "fdump-record-layouts">,
   HelpText<"Dump record layout information">,
   MarshallingInfoFlag>,
-  ImpliedByAnyOf<[fdump_record_layouts_simple.KeyPath]>;
+  ImpliedByAnyOf<[fdump_record_layouts_simple.KeyPath, 
fdump_record_layouts_complete.KeyPath]>;
 def fix_what_you_can : Flag<["-"], "fix-what-you-can">,
   HelpText<"Apply fix-it advice even in the presence of unfixable errors">,
   MarshallingInfoFlag>;
Index: clang/include/clang/Basic/LangOptions.def
===
--- clang/include/clang/Basic/LangOptions.def
+++ clang/include/clang/Basic/LangOptions.def
@@ -266,6 +266,7 @@
 BENIGN_LANGOPT(ElideConstructors , 1, 1, "C++ copy constructor elision")
 BENIGN_LANGOPT(DumpRecordLayouts , 1, 0, "dumping the layout of IRgen'd 
records")
 BENIGN_LANGOPT(DumpRecordLayoutsSimple , 1, 0, "dumping the layout of IRgen'd 
records in a simple form")
+BENIGN_LANGOPT(DumpRecordLayoutsComplete , 1, 0, "dumping the AST layout of 
all complete records")
 BENIGN_LANGOPT(DumpVTableLayouts , 1, 0, "dumping the layouts of emitted 
vtables")
 LANGOPT(NoConstantCFStrings , 1, 0, "no constant CoreFoundation strings")
 BENIGN_LANGOPT(InlineVisibilityHidden , 1, 0, "hidden visibility for inline 
C++ methods")


Index: clang/test/Layout/dump-complete.cpp
===
--- /dev/null
+++ clang/test/Layout/dump-complete.cpp
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -emit-llvm-only -fdump-record-layouts-complete %s | FileCheck %s
+
+struct a {
+  int x;
+};
+
+struct b {
+  char y;
+} foo;
+
+class c {};
+
+class d;
+
+// CHECK:  0 | struct a
+// CHECK:  0 | struct b
+// CHECK:  0 | class c
+// CHECK-NOT:  0 | class d
Index: clang/lib/AST/Decl.cpp
===
--- clang/lib/AST/Decl.cpp
+++ clang/lib/AST/Decl.cpp
@@ -4581,6 +4581,13 @@
 void RecordDecl::completeDefinition() {
   assert(!isCompleteDefinition() && "Cannot redefine record!");
   TagDecl::completeDefinition();
+
+  ASTContext &Ctx = getASTContext();
+
+  // Layouts are dumped when computed, so if we are dumping for all complete
+  // types, we need to force usage to get types that wouldn't be used elsewhere.
+  if (Ctx.getLangOpts().DumpRecordLayoutsComplete)
+(void)Ctx.getASTRecordLayout(this);
 }
 
 /// isMsStruct - Get whether or not this record uses ms_struct layout.
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -5371,10 +5371,13 @@
 def fdump_record_layouts_simple : Flag<["-"], "fdump-record-layouts-simple">,
   HelpText<"Dump record layout information in a simple f

[clang] a83ce95 - [clang] Remove unused capture in closure

2021-06-22 Thread Graham Hunter via cfe-commits

Author: Graham Hunter
Date: 2021-06-22T15:09:39+01:00
New Revision: a83ce95b097689f4ebd2c3b45c0778d0b6946d00

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

LOG: [clang] Remove unused capture in closure

c6a91ee6 removed uses of IsMonotonic from OpenMP SIMD codegen,
but that left a capture of the variable unused which upset buildbots
using -Werror.

Added: 


Modified: 
clang/lib/CodeGen/CGStmtOpenMP.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGStmtOpenMP.cpp 
b/clang/lib/CodeGen/CGStmtOpenMP.cpp
index 3b2b70f388cc..ba497a5b9d3a 100644
--- a/clang/lib/CodeGen/CGStmtOpenMP.cpp
+++ b/clang/lib/CodeGen/CGStmtOpenMP.cpp
@@ -3197,7 +3197,7 @@ bool CodeGenFunction::EmitOMPWorksharingLoop(
 getJumpDestInCurrentScope(createBasicBlock("omp.loop.exit"));
 emitCommonSimdLoop(
 *this, S,
-[&S, IsMonotonic](CodeGenFunction &CGF, PrePostActionTy &) {
+[&S](CodeGenFunction &CGF, PrePostActionTy &) {
   if (isOpenMPSimdDirective(S.getDirectiveKind())) {
 CGF.EmitOMPSimdInit(S);
   } else if (const auto *C = S.getSingleClause()) {



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


[PATCH] D104677: [OpenMP][AMDGCN] Apply fix for isnan, isinf and isfinite for amdgcn.

2021-06-22 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl requested changes to this revision.
yaxunl added a comment.
This revision now requires changes to proceed.

can we add a test to 
https://github.com/llvm/llvm-project/blob/main/clang/test/Headers/hip-header.hip
 just to make sure these functions are still available for HIP? Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104677

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


[PATCH] D104714: [UpdateCCTestChecks] Support --check-globals

2021-06-22 Thread Joel E. Denny via Phabricator via cfe-commits
jdenny created this revision.
jdenny added reviewers: arichardson, ggeorgakoudis, jdoerfert, MaskRay, 
mtrofin, greened.
jdenny requested review of this revision.
Herald added a subscriber: sstefan1.
Herald added projects: clang, LLVM.

This option is already supported by update_test_checks.py, but it can
also be useful in update_cc_test_checks.py.  For example, I'd like to
use it in OpenMP offload codegen tests to check global variables like
`.offload_maptypes*`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104714

Files:
  clang/test/utils/update_cc_test_checks/Inputs/check-globals.c
  clang/test/utils/update_cc_test_checks/Inputs/lit.cfg.example
  clang/test/utils/update_cc_test_checks/check-globals.test
  clang/test/utils/update_cc_test_checks/lit.local.cfg
  llvm/utils/update_cc_test_checks.py

Index: llvm/utils/update_cc_test_checks.py
===
--- llvm/utils/update_cc_test_checks.py
+++ llvm/utils/update_cc_test_checks.py
@@ -147,6 +147,8 @@
   help='Keep function signature information around for the check line')
   parser.add_argument('--check-attributes', action='store_true',
   help='Check "Function Attributes" for functions')
+  parser.add_argument('--check-globals', action='store_true',
+  help='Check global entries (global variables, metadata, attribute sets, ...) for functions')
   parser.add_argument('tests', nargs='+')
   args = common.parse_commandline_args(parser)
   infer_dependent_args(args)
@@ -300,6 +302,7 @@
 global_vars_seen_dict = {}
 prefix_set = set([prefix for p in filecheck_run_list for prefix in p[0]])
 output_lines = []
+has_checked_pre_function_globals = False
 
 include_generated_funcs = common.find_arg_in_test(ti,
   lambda args: ti.args.include_generated_funcs,
@@ -332,6 +335,10 @@
  prefixes,
  func_dict, func)
 
+  if ti.args.check_globals:
+common.add_global_checks(builder.global_var_dict(), '//', run_list,
+ output_lines, global_vars_seen_dict, True,
+ True)
   common.add_checks_at_end(output_lines, filecheck_run_list, builder.func_order(),
'//', lambda my_output_lines, prefixes, func:
check_generator(my_output_lines,
@@ -346,6 +353,8 @@
 m = common.CHECK_RE.match(line)
 if m and m.group(1) in prefix_set:
   continue  # Don't append the existing CHECK lines
+if line.strip() == '//' + common.SEPARATOR:
+  continue
 if idx in line2spell_and_mangled_list:
   added = set()
   for spell, mangled in line2spell_and_mangled_list[idx]:
@@ -363,6 +372,11 @@
 # line as part of common.add_ir_checks()
 output_lines.pop()
 last_line = output_lines[-1].strip()
+  if ti.args.check_globals and not has_checked_pre_function_globals:
+common.add_global_checks(builder.global_var_dict(), '//',
+ run_list, output_lines,
+ global_vars_seen_dict, True, True)
+has_checked_pre_function_globals = True
   if added:
 output_lines.append('//')
   added.add(mangled)
@@ -374,6 +388,9 @@
 if include_line:
   output_lines.append(line.rstrip('\n'))
 
+if ti.args.check_globals:
+  common.add_global_checks(builder.global_var_dict(), '//', run_list,
+   output_lines, global_vars_seen_dict, True, False)
 common.debug('Writing %d lines to %s...' % (len(output_lines), ti.path))
 with open(ti.path, 'wb') as f:
   f.writelines(['{}\n'.format(l).encode('utf-8') for l in output_lines])
Index: clang/test/utils/update_cc_test_checks/lit.local.cfg
===
--- clang/test/utils/update_cc_test_checks/lit.local.cfg
+++ clang/test/utils/update_cc_test_checks/lit.local.cfg
@@ -19,9 +19,13 @@
 script_path = os.path.join(config.llvm_src_root, 'utils',
'update_cc_test_checks.py')
 assert os.path.isfile(script_path)
+lit = shell_quote(os.path.join(config.llvm_src_root, 'utils', 'lit', 'lit.py'))
+python = shell_quote(config.python_executable)
 config.substitutions.append(
 ('%update_cc_test_checks', "%s %s %s" % (
-shell_quote(config.python_executable), shell_quote(script_path),
-extra_args)))
+python, shell_quote(script_path), extra_args)))
 config.substitutions.append(
 ('%clang_tools_dir', shell_quote(config.clang_tools_dir)))
+config.substitutions.append(
+('%lit', "%s %s -Dclang_obj_root=%s -j1 -vv" % (
+python, lit, shell_quote(config.clang_obj_root)))

[PATCH] D104677: [OpenMP][AMDGCN] Apply fix for isnan, isinf and isfinite for amdgcn.

2021-06-22 Thread Aaron Enye Shi via Phabricator via cfe-commits
ashi1 added a comment.

Looks OK to me, please address other review comments. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104677

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


[PATCH] D104714: [UpdateCCTestChecks] Support --check-globals

2021-06-22 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert accepted this revision.
jdoerfert added a comment.
This revision is now accepted and ready to land.

LG, cool :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104714

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


[PATCH] D97680: [OpenMP] Simplify GPU memory globalization

2021-06-22 Thread Joseph Huber via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG68d133a3e8c9: [OpenMP] Simplify GPU memory globalization 
(authored by jhuber6).

Changed prior to commit:
  https://reviews.llvm.org/D97680?vs=347097&id=353650#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D97680

Files:
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.cpp
  clang/lib/CodeGen/CGOpenMPRuntimeGPU.h
  clang/test/OpenMP/assumes_include_nvptx.cpp
  clang/test/OpenMP/declare_target_codegen_globalization.cpp
  clang/test/OpenMP/nvptx_data_sharing.cpp
  clang/test/OpenMP/nvptx_distribute_parallel_generic_mode_codegen.cpp
  clang/test/OpenMP/nvptx_lambda_capturing.cpp
  clang/test/OpenMP/nvptx_multi_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_nested_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_parallel_for_codegen.cpp
  clang/test/OpenMP/nvptx_target_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_num_threads_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_proc_bind_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_reduction_codegen.cpp
  clang/test/OpenMP/nvptx_target_parallel_reduction_codegen_tbaa_PR46146.cpp
  clang/test/OpenMP/nvptx_target_teams_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_codegen.cpp
  clang/test/OpenMP/nvptx_target_teams_distribute_parallel_for_simd_codegen.cpp
  clang/test/OpenMP/nvptx_teams_codegen.cpp
  clang/test/OpenMP/nvptx_teams_reduction_codegen.cpp
  clang/test/OpenMP/target_parallel_debug_codegen.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPKinds.def
  llvm/lib/Transforms/IPO/OpenMPOpt.cpp
  llvm/test/Transforms/OpenMP/globalization_remarks.ll
  llvm/test/Transforms/PhaseOrdering/openmp-opt-module.ll

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


[PATCH] D104647: [analyzer] Support SVal::getType for pointer-to-member values

2021-06-22 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko updated this revision to Diff 353649.
vsavchenko added a comment.

Restore behavior for nullptr declarations


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104647

Files:
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/BasicValueFactory.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/SValBuilder.h
  clang/include/clang/StaticAnalyzer/Core/PathSensitive/SVals.h
  clang/lib/StaticAnalyzer/Core/BasicValueFactory.cpp
  clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
  clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
  clang/lib/StaticAnalyzer/Core/SVals.cpp
  clang/unittests/StaticAnalyzer/SValTest.cpp

Index: clang/unittests/StaticAnalyzer/SValTest.cpp
===
--- clang/unittests/StaticAnalyzer/SValTest.cpp
+++ clang/unittests/StaticAnalyzer/SValTest.cpp
@@ -346,6 +346,41 @@
   EXPECT_EQ(Context.VoidPtrTy, *B.getType(Context));
 }
 
+SVAL_TEST(GetMemberPtrType, R"(
+struct A {
+  int a;
+  struct {
+int b;
+  };
+};
+void foo(int A::*x) {
+  int A::*a = &A::a;
+  int A::*b = &A::b;
+  int A::*c = x;
+}
+)") {
+  SVal A = getByName("a");
+  ASSERT_TRUE(A.getType(Context).hasValue());
+  const auto *AMemberPtrTy = dyn_cast(*A.getType(Context));
+  ASSERT_NE(AMemberPtrTy, nullptr);
+  EXPECT_EQ(Context.IntTy, AMemberPtrTy->getPointeeType());
+  const auto *ARecordType = dyn_cast(AMemberPtrTy->getClass());
+  ASSERT_NE(ARecordType, nullptr);
+  EXPECT_EQ("A", ARecordType->getDecl()->getName());
+
+  SVal B = getByName("b");
+  ASSERT_TRUE(B.getType(Context).hasValue());
+  const auto *BMemberPtrTy = dyn_cast(*B.getType(Context));
+  ASSERT_NE(BMemberPtrTy, nullptr);
+  EXPECT_EQ(Context.IntTy, BMemberPtrTy->getPointeeType());
+  const auto *BRecordType = dyn_cast(BMemberPtrTy->getClass());
+  ASSERT_NE(BRecordType, nullptr);
+  EXPECT_EQ("A", BRecordType->getDecl()->getName());
+
+  SVal C = getByName("c");
+  EXPECT_TRUE(C.isUnknown());
+}
+
 } // namespace
 } // namespace ento
 } // namespace clang
Index: clang/lib/StaticAnalyzer/Core/SVals.cpp
===
--- clang/lib/StaticAnalyzer/Core/SVals.cpp
+++ clang/lib/StaticAnalyzer/Core/SVals.cpp
@@ -180,6 +180,14 @@
   Optional VisitNonLocSymbolVal(nonloc::SymbolVal SV) {
 return Visit(SV.getSymbol());
   }
+  Optional VisitNonLocPointerToMember(nonloc::PointerToMember PTM) {
+QualType T = PTM.getType();
+
+if (T.isNull())
+  return None;
+
+return T;
+  }
   Optional VisitSymbolicRegion(const SymbolicRegion *SR) {
 return Visit(SR->getSymbol());
   }
@@ -209,21 +217,21 @@
 }
 
 bool nonloc::PointerToMember::isNullMemberPointer() const {
-  return getPTMData().isNull();
+  return getPTMData() == nullptr;
 }
 
 const NamedDecl *nonloc::PointerToMember::getDecl() const {
-  const auto PTMD = this->getPTMData();
-  if (PTMD.isNull())
+  if (!getPTMData())
 return nullptr;
 
-  const NamedDecl *ND = nullptr;
-  if (PTMD.is())
-ND = PTMD.get();
-  else
-ND = PTMD.get()->getDeclaratorDecl();
+  return getPTMData()->getDeclaratorDecl();
+}
+
+QualType nonloc::PointerToMember::getType() const {
+  if (!getPTMData())
+return {};
 
-  return ND;
+  return getPTMData()->getType();
 }
 
 //===--===//
@@ -239,17 +247,11 @@
 }
 
 nonloc::PointerToMember::iterator nonloc::PointerToMember::begin() const {
-  const PTMDataType PTMD = getPTMData();
-  if (PTMD.is())
-return {};
-  return PTMD.get()->begin();
+  return getPTMData()->begin();
 }
 
 nonloc::PointerToMember::iterator nonloc::PointerToMember::end() const {
-  const PTMDataType PTMD = getPTMData();
-  if (PTMD.is())
-return {};
-  return PTMD.get()->end();
+  return getPTMData()->end();
 }
 
 //===--===//
Index: clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
===
--- clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
+++ clang/lib/StaticAnalyzer/Core/SValBuilder.cpp
@@ -236,7 +236,7 @@
   return nonloc::SymbolVal(sym);
 }
 
-DefinedSVal SValBuilder::getMemberPointer(const NamedDecl *ND) {
+DefinedSVal SValBuilder::getMemberPointer(const NamedDecl *ND, QualType T) {
   assert(!ND || isa(ND) || isa(ND) ||
  isa(ND));
 
@@ -250,7 +250,8 @@
   return getFunctionPointer(MD);
   }
 
-  return nonloc::PointerToMember(ND);
+  return nonloc::PointerToMember(
+  ND ? getBasicValueFactory().getPointerToMemberData(ND, T) : nullptr);
 }
 
 DefinedSVal SValBuilder::getFunctionPointer(const FunctionDecl *func) {
Index: clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
===
--- clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
+++ clang/lib/StaticAnalyzer/Core/ExprEngineC.cpp
@@ -516,7 +516,7 @@

[PATCH] D104505: [HIP] Defer operator overloading errors

2021-06-22 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D104505#2831811 , @tra wrote:

> In D104505#2831644 , @yaxunl wrote:
>
>> However, this does cause source level incompatibilities, i.e. CUDA code that 
>> passes nvcc does not pass clang. This patch somehow addresses that without 
>> compromising clang's more sophisticated `__host__/__device__` overloading 
>> resolution capabilities.
>
> Yes. This will not be the first time where clang does diagnose invalid code 
> while NVCC does not.
> In general, some amount of source code porting between nvcc and clang is 
> expected. In practice the amount of work required to make CUDA code portable 
> has been relatively minor.
>
> My general rule of thumb is that if both host and device compilation have 
> enough information to diagnose a problem, both should do it.
> In this case, there's no ambiguity that the code is invalid. The sooner we 
> diagnose it, the better.
>
> Is there particular use case where this patch would be necessary?

Such host/device overloading resolution induced issue is not limited to device 
functions calling host functions. It could also happen to host device functions 
calling host functions, which is less controversial for deferring.


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

https://reviews.llvm.org/D104505

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


[PATCH] D104680: [clang] Eliminate relational function pointer comparisons in all C++ modes

2021-06-22 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov updated this revision to Diff 353651.
mizvekov added a comment.

- Add one more test case.
- Formating


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104680

Files:
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/lib/Sema/SemaOverload.cpp
  clang/test/CXX/class/class.compare/class.spaceship/p2.cpp
  clang/test/CXX/drs/dr15xx.cpp
  clang/test/CXX/drs/dr3xx.cpp
  clang/test/CXX/expr/expr.const/p2-0x.cpp
  clang/test/FixIt/fixit.cpp
  clang/test/Parser/cxx-template-argument.cpp
  clang/test/Sema/compare.c
  clang/test/SemaCXX/compare-cxx2a.cpp
  clang/test/SemaCXX/compare-function-pointer.cpp
  clang/test/SemaTemplate/resolve-single-template-id.cpp
  compiler-rt/test/asan/TestCases/Posix/coverage-module-unloaded.cpp

Index: compiler-rt/test/asan/TestCases/Posix/coverage-module-unloaded.cpp
===
--- compiler-rt/test/asan/TestCases/Posix/coverage-module-unloaded.cpp
+++ compiler-rt/test/asan/TestCases/Posix/coverage-module-unloaded.cpp
@@ -13,6 +13,7 @@
 
 #include 
 #include 
+#include 
 #include 
 #include 
 
@@ -38,10 +39,11 @@
 
   // It matters whether the unloaded module has a higher or lower address range
   // than the remaining one. Make sure to test both cases.
+  bool lt = reinterpret_cast(bar1) < reinterpret_cast(bar2);
   if (argc < 2)
-dlclose(bar1 < bar2 ? handle1 : handle2);
+dlclose(lt ? handle1 : handle2);
   else
-dlclose(bar1 < bar2 ? handle2 : handle1);
+dlclose(lt ? handle2 : handle1);
   return 0;
 }
 #endif
Index: clang/test/SemaTemplate/resolve-single-template-id.cpp
===
--- clang/test/SemaTemplate/resolve-single-template-id.cpp
+++ clang/test/SemaTemplate/resolve-single-template-id.cpp
@@ -65,12 +65,14 @@
   void (*u)(int) = oneT;
 
   b = (void (*)()) twoT;
-  
-  one < one; //expected-warning {{self-comparison always evaluates to false}} \
- //expected-warning {{relational comparison result unused}} 
 
-  oneT < oneT;  //expected-warning {{self-comparison always evaluates to false}} \
-  //expected-warning {{relational comparison result unused}}
+  one < one; // expected-warning {{self-comparison always evaluates to false}} \
+ // expected-warning {{relational comparison result unused}}   \
+ // expected-error   {{ordered comparison of function pointers}}
+
+  oneT < oneT; // expected-warning {{self-comparison always evaluates to false}} \
+ // expected-warning {{relational comparison result unused}}   \
+ // expected-error   {{ordered comparison of function pointers}}
 
   two < two; //expected-error 2 {{reference to overloaded function could not be resolved; did you mean to call it with no arguments?}} expected-error {{invalid operands to binary expression ('void' and 'void')}}
   twoT < twoT; //expected-error {{reference to overloaded function could not be resolved; did you mean to call it?}} {{cannot resolve overloaded function 'twoT' from context}}
Index: clang/test/SemaCXX/compare-function-pointer.cpp
===
--- /dev/null
+++ clang/test/SemaCXX/compare-function-pointer.cpp
@@ -0,0 +1,12 @@
+// RUN: %clang_cc1 -fsyntax-only -std=c++20 -verify %s
+
+using fp_t = void (*)();
+extern fp_t a, b;
+
+bool eq = a == b;
+bool ne = a != b;
+bool lt = a < b;   // expected-error {{ordered comparison of function pointers ('fp_t' (aka 'void (*)()') and 'fp_t')}}
+bool le = a <= b;  // expected-error {{ordered comparison of function pointers}}
+bool gt = a > b;   // expected-error {{ordered comparison of function pointers}}
+bool ge = a >= b;  // expected-error {{ordered comparison of function pointers}}
+bool tw = a <=> b; // expected-error {{ordered comparison of function pointers}}
Index: clang/test/SemaCXX/compare-cxx2a.cpp
===
--- clang/test/SemaCXX/compare-cxx2a.cpp
+++ clang/test/SemaCXX/compare-cxx2a.cpp
@@ -212,8 +212,6 @@
 struct ClassB : Class {};
 struct Class2 {};
 using FnTy = void(int);
-using FnTy2 = long(int);
-using FnTy3 = void(int) noexcept;
 using MemFnTy = void (Class::*)() const;
 using MemDataTy = long(Class::*);
 
@@ -232,11 +230,6 @@
   (void)(md <=> md); // expected-error {{invalid operands}} expected-warning {{self-comparison}}
 }
 
-void test_compatible_pointer(FnTy *f1, FnTy2 *f2, FnTy3 *f3) {
-  (void)(f1 <=> f2); // expected-error {{distinct pointer types}}
-  (void)(f1 <=> f3); // expected-error {{invalid operands}}
-}
-
 // Test that variable narrowing is deferred for value dependent expressions
 template 
 auto test_template_overflow() {
Index: clang/test/Sema/compare.c
=

[PATCH] D103191: [OpenCL] Add support of __opencl_c_program_scope_global_variables feature macro

2021-06-22 Thread Anastasia Stulova via Phabricator via cfe-commits
Anastasia accepted this revision.
Anastasia added a comment.
This revision is now accepted and ready to land.

LGTM! Thanks!




Comment at: clang/include/clang/Basic/OpenCLOptions.h:80
+return Opts.OpenCLCPlusPlus || Opts.OpenCLVersion == 200 ||
+   (Opts.OpenCLVersion >= 300 &&
+isSupported("__opencl_c_program_scope_global_variables", Opts));

While it is not critical, I would slightly prefer that we are checking for `== 
300`. Checking `>= 300` assumes that the next versions are going to be backward 
compatible. But it is not always the case if we look at the OpenCL evolution.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103191

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


[PATCH] D104716: [analyzer] Fix assertion failure on code with transparent unions

2021-06-22 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko created this revision.
vsavchenko added reviewers: NoQ, xazax.hun, martong, steakhal, Szelethus, 
ASDenysPetrov, manas, RedDocMD.
Herald added subscribers: dkrupp, donat.nagy, mikhail.ramalho, a.sidorin, 
rnkovacs, szepet, baloghadamsoftware.
vsavchenko requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

rdar://76948312


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104716

Files:
  clang/lib/StaticAnalyzer/Core/CallEvent.cpp
  clang/test/Analysis/transparent_union_bug.c

Index: clang/test/Analysis/transparent_union_bug.c
===
--- /dev/null
+++ clang/test/Analysis/transparent_union_bug.c
@@ -0,0 +1,42 @@
+// RUN: %clang_analyze_cc1 -analyze -triple x86_64-apple-darwin10 \
+// RUN:  -analyzer-checker=core,debug.ExprInspection -verify %s
+
+void clang_analyzer_warnIfReached();
+void clang_analyzer_printState();
+
+typedef struct {
+  int value;
+} Struct;
+
+typedef union {
+  Struct *ptr;
+  long num;
+} __attribute__((transparent_union)) Alias;
+
+void foo(Struct *x);
+void foo(Alias y) {
+  if (y.ptr == 0) {
+// no-crash
+  }
+  clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+}
+void foobar(long z);
+void foobar(Alias z) {
+  clang_analyzer_printState();
+  if (z.num != 42) {
+// no-crash
+  }
+  clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+}
+
+void foobaz(Alias x) {
+  if (x.ptr == 0) {
+// no-crash
+  }
+  clang_analyzer_warnIfReached(); // expected-warning{{REACHABLE}}
+}
+void bar(Struct arg) {
+  foo(&arg);
+  foobar(42);
+  foobaz(&arg);
+}
Index: clang/lib/StaticAnalyzer/Core/CallEvent.cpp
===
--- clang/lib/StaticAnalyzer/Core/CallEvent.cpp
+++ clang/lib/StaticAnalyzer/Core/CallEvent.cpp
@@ -47,6 +47,7 @@
 #include "clang/StaticAnalyzer/Core/PathSensitive/Store.h"
 #include "llvm/ADT/ArrayRef.h"
 #include "llvm/ADT/DenseMap.h"
+#include "llvm/ADT/ImmutableList.h"
 #include "llvm/ADT/None.h"
 #include "llvm/ADT/Optional.h"
 #include "llvm/ADT/PointerIntPair.h"
@@ -466,6 +467,46 @@
   llvm_unreachable("unknown callable kind");
 }
 
+static bool isTransparentUnion(QualType T) {
+  const RecordType *UT = T->getAsUnionType();
+  return UT && UT->getDecl()->hasAttr();
+}
+
+static bool isTransparentUnion(SVal Value, const ASTContext &Context) {
+  Optional T = Value.getType(Context);
+  return T && isTransparentUnion(*T);
+}
+
+// In some cases, symbolic cases should be transformed before we associate
+// them with parameters.  This function incapsulates such cases.
+static SVal process(SVal Value, const ParmVarDecl *Parameter,
+SValBuilder &SVB) {
+  QualType ParamType = Parameter->getType();
+
+  // Transparent unions allow users to easily convert values of union field
+  // types into union-typed objects.
+  //
+  // Also, more importantly, they allow users to define functions with different
+  // different parameter types, substituting types matching transparent union
+  // field types with the union type itself.
+  //
+  // Here, we check specifically for latter cases and prevent binding
+  // field-typed values to union-typed regions.
+  if (isTransparentUnion(ParamType) &&
+  // Let's check that we indeed trying to bind different types.
+  !isTransparentUnion(Value, SVB.getContext())) {
+BasicValueFactory &BVF = SVB.getBasicValueFactory();
+
+llvm::ImmutableList CompoundSVals = BVF.getEmptySValList();
+CompoundSVals = BVF.prependSVal(Value, CompoundSVals);
+
+// Wrap it with compound value.
+return SVB.makeCompoundVal(ParamType, CompoundSVals);
+  }
+
+  return Value;
+}
+
 static void addParameterValuesToBindings(const StackFrameContext *CalleeCtx,
  CallEvent::BindingsTy &Bindings,
  SValBuilder &SVB,
@@ -493,7 +534,7 @@
 if (!ArgVal.isUnknown()) {
   Loc ParamLoc = SVB.makeLoc(
   MRMgr.getParamVarRegion(Call.getOriginExpr(), Idx, CalleeCtx));
-  Bindings.push_back(std::make_pair(ParamLoc, ArgVal));
+  Bindings.push_back(std::make_pair(ParamLoc, process(ArgVal, *I, SVB)));
 }
   }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D104680: [clang] Eliminate relational function pointer comparisons in all C++ modes

2021-06-22 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov added inline comments.



Comment at: clang/test/Parser/cxx-template-argument.cpp:28
+(void)(&t==p);// expected-error {{use '> ='}}
+(void)(&t>=p);// expected-error {{use '> >'}} expected-error 
{{ordered comparison of function pointers}}
+(void)(&t>>=p); // expected-error {{ordered comparison of function 
pointers}}

So here we are recovering from the parser error into this type check error.
Maybe there is something that could be improved as a follow up task so we don't 
get a double error.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104680

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


[PATCH] D104540: [clangd] Dont index ObjCCategoryDecls for completion

2021-06-22 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet updated this revision to Diff 353658.
kadircet marked an inline comment as done.
kadircet added a comment.

- Also handle ObjcCategoryImplDecl


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104540

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


Index: clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
===
--- clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
+++ clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
@@ -552,8 +552,9 @@
   EXPECT_THAT(Symbols,
   UnorderedElementsAre(
   QName("Person"), QName("Person::someMethodName:lastName:"),
-  QName("MyCategory"), QName("Person::someMethodName2:"),
-  QName("MyProtocol"), QName("MyProtocol::someMethodName3:")));
+  AllOf(QName("MyCategory"), ForCodeCompletion(false)),
+  QName("Person::someMethodName2:"), QName("MyProtocol"),
+  QName("MyProtocol::someMethodName3:")));
 }
 
 TEST_F(SymbolCollectorTest, ObjCPropertyImpl) {
Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -3221,6 +3221,45 @@
   UnorderedElementsAre(Labeled("ECHO(X)"), Labeled("ECHO2(X)")));
 }
 
+TEST(CompletionTest, ObjCCategoryDecls) {
+  TestTU TU;
+  TU.ExtraArgs.push_back("-xobjective-c");
+  TU.HeaderCode = R"objc(
+  @interface Foo
+  @end
+
+  @interface Foo (FooExt1)
+  @end
+
+  @interface Foo (FooExt2)
+  @end
+
+  @interface Bar
+  @end
+
+  @interface Bar (BarExt)
+  @end)objc";
+
+  {
+Annotations Test(R"objc(
+  @implementation Foo (^)
+  @end
+  )objc");
+TU.Code = Test.code().str();
+auto Results = completions(TU, Test.point());
+EXPECT_THAT(Results.Completions,
+UnorderedElementsAre(Labeled("FooExt1"), Labeled("FooExt2")));
+  }
+  {
+Annotations Test(R"objc(
+  @interface Foo (^)
+  @end
+  )objc");
+TU.Code = Test.code().str();
+auto Results = completions(TU, Test.point());
+EXPECT_THAT(Results.Completions, UnorderedElementsAre(Labeled("BarExt")));
+  }
+}
 } // namespace
 } // namespace clangd
 } // namespace clang
Index: clang-tools-extra/clangd/CodeComplete.cpp
===
--- clang-tools-extra/clangd/CodeComplete.cpp
+++ clang-tools-extra/clangd/CodeComplete.cpp
@@ -62,6 +62,7 @@
 #include "llvm/ADT/SmallVector.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringRef.h"
+#include "llvm/Support/Casting.h"
 #include "llvm/Support/Compiler.h"
 #include "llvm/Support/Debug.h"
 #include "llvm/Support/Error.h"
@@ -1910,6 +1911,13 @@
   if (isExplicitTemplateSpecialization(&ND))
 return false;
 
+  // Category decls are not useful on their own outside the interface or
+  // implementation blocks. Moreover, sema already provides completion for
+  // these, even if it requires preamble deserialization. So by excluding them
+  // from the index, we reduce the noise in all the other completion scopes.
+  if (llvm::isa(&ND) || llvm::isa(&ND))
+return false;
+
   if (InTopLevelScope(ND))
 return true;
 


Index: clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
===
--- clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
+++ clang-tools-extra/clangd/unittests/SymbolCollectorTests.cpp
@@ -552,8 +552,9 @@
   EXPECT_THAT(Symbols,
   UnorderedElementsAre(
   QName("Person"), QName("Person::someMethodName:lastName:"),
-  QName("MyCategory"), QName("Person::someMethodName2:"),
-  QName("MyProtocol"), QName("MyProtocol::someMethodName3:")));
+  AllOf(QName("MyCategory"), ForCodeCompletion(false)),
+  QName("Person::someMethodName2:"), QName("MyProtocol"),
+  QName("MyProtocol::someMethodName3:")));
 }
 
 TEST_F(SymbolCollectorTest, ObjCPropertyImpl) {
Index: clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
===
--- clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
+++ clang-tools-extra/clangd/unittests/CodeCompleteTests.cpp
@@ -3221,6 +3221,45 @@
   UnorderedElementsAre(Labeled("ECHO(X)"), Labeled("ECHO2(X)")));
 }
 
+TEST(CompletionTest, ObjCCategoryDecls) {
+  TestTU TU;
+  TU.ExtraArgs.push_back("-xobjective-c");
+  TU.HeaderCode = R"objc(
+  @interface Foo
+  @end
+
+  @interface Foo (FooExt1)
+  @end
+
+  @interface Foo (FooExt2)
+  @end
+
+  @interfac

[PATCH] D104540: [clangd] Dont index ObjCCategoryDecls for completion

2021-06-22 Thread Kadir Cetinkaya via Phabricator via cfe-commits
kadircet added inline comments.



Comment at: clang-tools-extra/clangd/CodeComplete.cpp:1918
+  // from the index, we reduce the noise in all the other completion scopes.
+  if (llvm::isa(&ND))
+return false;

dgoldman wrote:
> Seems like we should also ignore ObjCCategoryImplDecl, I think those would 
> have the same issue (although only from other .m files in the project, not 
> from SDK headers)?
we actually never index those, as symbolcollector canonicalizes 
ObjcCategoryImplDecls to ObjcCategoryDecl, so we can't really test it. but 
adding here for completeness.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104540

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


[PATCH] D93938: [clang-format] Fixed AfterEnum handling

2021-06-22 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay added a comment.



>> Since you use `== ' '` twice, `remainingLineCharCount` will count only 
>> consecutive spaces, right?
>> But you want to count other characters, no?
>> So, IIUC, the condition you want is `rF[wI] != '\n' && !(rF[wI] == ' ' && 
>> rF[wI - 1] == ' ')` (mind the negation). It will count characters other than 
>> a newline and it will only count a series of consecutive spaces as one char. 
>> WDYT?

That whole while loop leaves me feeling cold, it feels like a bug waiting to 
happen, frankly I don't understand why its necessary.  It would be better to 
move the loop into a function and properly unit test it if there is really no 
other way


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D93938

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


[PATCH] D104680: [clang] Eliminate relational function pointer comparisons in all C++ modes

2021-06-22 Thread Arthur O'Dwyer via Phabricator via cfe-commits
Quuxplusone added a comment.

> There isn't any wording on it or anything, yet, but we must jump the gun here 
> and just do away with it pronto.

I think "must" is the wrong word here. "Might as well"? Anyway, I agree with 
this general idea, FWLIW.




Comment at: clang/lib/Sema/SemaExpr.cpp:11815
+if (IsError)
+  return Opc != BO_Cmp ? Context.getLogicalOperationType() : QualType();
+  }

Peanut gallery says: Is `QualType()` the right "placeholder" to return here? 
IIUC, this is the situation where we've diagnosed an ill-formed expression and 
are just trying to do error-recovery: if the expression looks like `x < y` then 
we assume the programmer wants it to return `bool`, and if the expression looks 
like `x <=> y` then we assume the programmer wants it to return... 
`QualType()`? Is that the same thing we'd do for e.g. `x + y` or 
`undeclaredfunction(x)`? (If so, good, I think.)



Comment at: clang/test/Parser/cxx-template-argument.cpp:28
+(void)(&t==p);// expected-error {{use '> ='}}
+(void)(&t>=p);// expected-error {{use '> >'}} expected-error 
{{ordered comparison of function pointers}}
+(void)(&t>>=p); // expected-error {{ordered comparison of function 
pointers}}

mizvekov wrote:
> So here we are recovering from the parser error into this type check error.
> Maybe there is something that could be improved as a follow up task so we 
> don't get a double error.
Since this is a parsing test, not a semantics test, I think it should avoid 
doing anything sketchy semantic-wise. It should just be rewritten as something 
like
```
struct RHS {
friend void operator==(void(*)(), RHS) {}
friend void operator>=(void(*)(), RHS) {}
};
(void)(&t==RHS());
(void)(&t>=RHS());
(void)(&t>==RHS());
(void)(&t>>=RHS());
```



Comment at: clang/test/SemaCXX/compare-function-pointer.cpp:12
+bool ge = a >= b;  // expected-error {{ordered comparison of function 
pointers}}
+bool tw = a <=> b; // expected-error {{ordered comparison of function 
pointers}}

I believe you should also test these same cases for `a OP c` where `c` is a 
different function pointer type, e.g. `int (*c)();`



Comment at: clang/test/SemaTemplate/resolve-single-template-id.cpp:73-75
+  oneT < oneT; // expected-warning {{self-comparison always 
evaluates to false}} \
+ // expected-warning {{relational comparison result 
unused}}   \
+ // expected-error   {{ordered comparison of function 
pointers}}

Cast `(void)(x < y)` here to suppress one of these irrelevant warnings.
The combination of warning "expr always evaluates to false" and erroring "expr 
is ill-formed" is also silly, but I suppose we can't do much about it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104680

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


[PATCH] D104680: [clang] Eliminate relational function pointer comparisons in all C++ modes

2021-06-22 Thread Matheus Izvekov via Phabricator via cfe-commits
mizvekov added inline comments.



Comment at: clang/lib/Sema/SemaExpr.cpp:11815
+if (IsError)
+  return Opc != BO_Cmp ? Context.getLogicalOperationType() : QualType();
+  }

Quuxplusone wrote:
> Peanut gallery says: Is `QualType()` the right "placeholder" to return here? 
> IIUC, this is the situation where we've diagnosed an ill-formed expression 
> and are just trying to do error-recovery: if the expression looks like `x < 
> y` then we assume the programmer wants it to return `bool`, and if the 
> expression looks like `x <=> y` then we assume the programmer wants it to 
> return... `QualType()`? Is that the same thing we'd do for e.g. `x + y` or 
> `undeclaredfunction(x)`? (If so, good, I think.)
So right now, this is the same we are doing for three-way comparison between 
builtin types we do not support / recognize. Check just below in this same 
function. Just look for the call to `getComparisonCategoryForBuiltinCmp`.

I agree completely with you and I was going to raise the same point, but I 
would prefer we changed both places at once instead of fixing it just here, so 
I think this should be a follow up task: Find something more appropriate to 
return here.



Comment at: clang/test/Parser/cxx-template-argument.cpp:28
+(void)(&t==p);// expected-error {{use '> ='}}
+(void)(&t>=p);// expected-error {{use '> >'}} expected-error 
{{ordered comparison of function pointers}}
+(void)(&t>>=p); // expected-error {{ordered comparison of function 
pointers}}

Quuxplusone wrote:
> mizvekov wrote:
> > So here we are recovering from the parser error into this type check error.
> > Maybe there is something that could be improved as a follow up task so we 
> > don't get a double error.
> Since this is a parsing test, not a semantics test, I think it should avoid 
> doing anything sketchy semantic-wise. It should just be rewritten as 
> something like
> ```
> struct RHS {
> friend void operator==(void(*)(), RHS) {}
> friend void operator>=(void(*)(), RHS) {}
> };
> (void)(&t==RHS());
> (void)(&t>=RHS());
> (void)(&t>==RHS());
> (void)(&t>>=RHS());
> ```
I like that idea.



Comment at: clang/test/SemaCXX/compare-function-pointer.cpp:12
+bool ge = a >= b;  // expected-error {{ordered comparison of function 
pointers}}
+bool tw = a <=> b; // expected-error {{ordered comparison of function 
pointers}}

Quuxplusone wrote:
> I believe you should also test these same cases for `a OP c` where `c` is a 
> different function pointer type, e.g. `int (*c)();`
Sounds good.



Comment at: clang/test/SemaTemplate/resolve-single-template-id.cpp:73-75
+  oneT < oneT; // expected-warning {{self-comparison always 
evaluates to false}} \
+ // expected-warning {{relational comparison result 
unused}}   \
+ // expected-error   {{ordered comparison of function 
pointers}}

Quuxplusone wrote:
> Cast `(void)(x < y)` here to suppress one of these irrelevant warnings.
> The combination of warning "expr always evaluates to false" and erroring 
> "expr is ill-formed" is also silly, but I suppose we can't do much about it.
I tried avoid changing the original test because I am not sure what the 
original intention was, but I agree in principle the two errors already give 
enough indication that the compiler is figuring out what is happening here 
correctly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104680

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


[PATCH] D104082: [CodeGen] Don't create a fake FunctionDecl when generating block/block_byref copy/dispose helper functions

2021-06-22 Thread Adrian Prantl via Phabricator via cfe-commits
aprantl accepted this revision.
aprantl added a comment.

Block copy helpers don't have any source code associated with them, so as long 
as they are described by a DISubprogram, the exact format of it most likely 
does not matter.




Comment at: clang/lib/CodeGen/CGBlocks.cpp:1957
  CGM);
   // This is necessary to avoid inheriting the previous line number.
+  StartFunction(GlobalDecl(), ReturnTy, Fn, FI, args);

This comment refers to the `FD->setImplicit();` that was removed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104082

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


[PATCH] D104082: [CodeGen] Don't create a fake FunctionDecl when generating block/block_byref copy/dispose helper functions

2021-06-22 Thread Adrian Prantl via Phabricator via cfe-commits
aprantl added inline comments.



Comment at: clang/lib/CodeGen/CGBlocks.cpp:2144
  CGM);
   // This is necessary to avoid inheriting the previous line number.
+  StartFunction(GlobalDecl(), ReturnTy, Fn, FI, args);

Same here — the comment should be removed.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104082

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


[PATCH] D88984: Prefer libc++ headers in the -isysroot over the toolchain

2021-06-22 Thread Louis Dionne via Phabricator via cfe-commits
ldionne abandoned this revision.
ldionne added a comment.
Herald added a project: clang-tools-extra.

Revisiting this, I don't think we need to move forward with this. Let's just 
carry our downstream patch until we don't need it anymore (which should be soon 
ish), and leave upstream Clang as it is (I think the current behavior makes the 
most sense). I'm abandoning this - I'll reopen if someone thinks that having 
Clang and AppleClang behave differently for a little while is harmful, but I 
don't think it is.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D88984

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


[PATCH] D101899: std::forward_list::swap to use propagate_on_container_swap for noexcept specification

2021-06-22 Thread Louis Dionne via Phabricator via cfe-commits
ldionne accepted this revision.
ldionne added a comment.
This revision is now accepted and ready to land.

Thanks a lot for fixing this and sorry


Repository:
  rCXX libc++

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

https://reviews.llvm.org/D101899

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


[clang] 03d7e61 - [OpenMP] Internalize functions in OpenMPOpt to improve IPO passes

2021-06-22 Thread via cfe-commits

Author: Joseph Huber
Date: 2021-06-22T12:38:10-04:00
New Revision: 03d7e61c87eb94083d22ff55cf30c0a378ab6824

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

LOG: [OpenMP] Internalize functions in OpenMPOpt to improve IPO passes

Summary:
Currently the attributor needs to give up if a function has external linkage.
This means that the optimization introduced in D97818 will only apply to static
functions. This change uses the Attributor to internalize OpenMP device
routines by making a copy of each function with private linkage and replacing
the uses in the module with it. This allows for the optimization to be applied
to any regular function.

Reviewed By: jdoerfert

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

Added: 


Modified: 
clang/test/OpenMP/remarks_parallel_in_multiple_target_state_machines.c
clang/test/OpenMP/remarks_parallel_in_target_state_machine.c
llvm/include/llvm/Transforms/IPO/Attributor.h
llvm/lib/Transforms/IPO/Attributor.cpp
llvm/lib/Transforms/IPO/OpenMPOpt.cpp
llvm/test/Transforms/OpenMP/replace_globalization.ll
llvm/test/Transforms/OpenMP/single_threaded_execution.ll

Removed: 




diff  --git 
a/clang/test/OpenMP/remarks_parallel_in_multiple_target_state_machines.c 
b/clang/test/OpenMP/remarks_parallel_in_multiple_target_state_machines.c
index 72593b96bd1ba..8b45d4dc789e5 100644
--- a/clang/test/OpenMP/remarks_parallel_in_multiple_target_state_machines.c
+++ b/clang/test/OpenMP/remarks_parallel_in_multiple_target_state_machines.c
@@ -1,13 +1,13 @@
-// RUN: %clang_cc1 -verify=host  
-Rpass=openmp-opt -Rpass-analysis=openmp -fopenmp -x c++ -triple 
powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc 
%s -o %t-ppc-host.bc
-// RUN: %clang_cc1 -verify=all,safe  
-Rpass=openmp-opt -Rpass-analysis=openmp -fopenmp -O2 -x c++ -triple 
nvptx64-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s 
-fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o %t.out
-// RUN: %clang_cc1 -fexperimental-new-pass-manager -verify=all,safe  
-Rpass=openmp-opt -Rpass-analysis=openmp -fopenmp -O2 -x c++ -triple 
nvptx64-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s 
-fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o %t.out
+// RUN: %clang_cc1 -verify=host  
-Rpass=openmp-opt -Rpass-analysis=openmp-opt -fopenmp -x c++ -triple 
powerpc64le-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm-bc 
%s -o %t-ppc-host.bc
+// RUN: %clang_cc1 -verify=all,safe  
-Rpass=openmp-opt -Rpass-analysis=openmp-opt -fopenmp -O2 -x c++ -triple 
nvptx64-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s 
-fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o %t.out
+// RUN: %clang_cc1 -fexperimental-new-pass-manager -verify=all,safe  
-Rpass=openmp-opt -Rpass-analysis=openmp-opt -fopenmp -O2 -x c++ -triple 
nvptx64-unknown-unknown -fopenmp-targets=nvptx64-nvidia-cuda -emit-llvm %s 
-fopenmp-is-device -fopenmp-host-ir-file-path %t-ppc-host.bc -o %t.out
 
 // host-no-diagnostics
 
 void bar1(void) {
 #pragma omp parallel // #0
  // all-remark@#0 {{Found a parallel region that is called 
in a target region but not part of a combined target construct nor nested 
inside a target construct without intermediate code. This can lead to excessive 
register usage for unrelated target regions in the same translation unit due to 
spurious call edges assumed by ptxas.}}
- // safe-remark@#0 {{Parallel region is used in unexpected 
ways; will not attempt to rewrite the state machine.}}
+ // safe-remark@#0 {{Parallel region is used in unknown 
ways; will not attempt to rewrite the state machine.}}
  // force-remark@#0 {{Specialize parallel region that is 
only reached from a single target region to avoid spurious call edges and 
excessive register usage in other target regions. (parallel region ID: 
__omp_outlined__2_wrapper, kernel ID: }}
   {
   }
@@ -15,7 +15,7 @@ void bar1(void) {
 void bar2(void) {
 #pragma omp parallel // #1
  // all-remark@#1 {{Found a parallel region that is called 
in a target region but not part of a combined target construct nor nested 
inside a target construct without intermediate code. This can lead to excessive 
register usage for unrelated target regions in the same translation unit due to 
spurious call edges assumed by ptxas.}}
- // safe-remark@#1 {{Parallel region is used in unexpected 
ways; will not attempt to rewrite the state machine.}}
+ // safe-remark@#

[PATCH] D102824: [OpenMP] Internalize functions in OpenMPOpt to improve IPO passes

2021-06-22 Thread Joseph Huber 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 rG03d7e61c87eb: [OpenMP] Internalize functions in OpenMPOpt to 
improve IPO passes (authored by jhuber6).
Herald added subscribers: cfe-commits, ormris.
Herald added a project: clang.

Changed prior to commit:
  https://reviews.llvm.org/D102824?vs=347099&id=353679#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102824

Files:
  clang/test/OpenMP/remarks_parallel_in_multiple_target_state_machines.c
  clang/test/OpenMP/remarks_parallel_in_target_state_machine.c
  llvm/include/llvm/Transforms/IPO/Attributor.h
  llvm/lib/Transforms/IPO/Attributor.cpp
  llvm/lib/Transforms/IPO/OpenMPOpt.cpp
  llvm/test/Transforms/OpenMP/replace_globalization.ll
  llvm/test/Transforms/OpenMP/single_threaded_execution.ll

Index: llvm/test/Transforms/OpenMP/single_threaded_execution.ll
===
--- llvm/test/Transforms/OpenMP/single_threaded_execution.ll
+++ llvm/test/Transforms/OpenMP/single_threaded_execution.ll
@@ -1,8 +1,8 @@
-; RUN: opt -passes=openmp-opt-cgscc -debug-only=openmp-opt -disable-output < %s 2>&1 | FileCheck %s
+; RUN: opt -passes=openmp-opt -debug-only=openmp-opt -disable-output < %s 2>&1 | FileCheck %s
 ; REQUIRES: asserts
 ; ModuleID = 'single_threaded_exeuction.c'
 
-define void @kernel() {
+define weak void @kernel() {
   call void @__kmpc_kernel_init(i32 512, i16 1)
   call void @nvptx()
   call void @amdgcn()
@@ -12,14 +12,15 @@
 ; CHECK-NOT: [openmp-opt] Basic block @nvptx entry is executed by a single thread.
 ; CHECK: [openmp-opt] Basic block @nvptx if.then is executed by a single thread.
 ; CHECK-NOT: [openmp-opt] Basic block @nvptx if.end is executed by a single thread.
-; Function Attrs: noinline nounwind uwtable
-define dso_local void @nvptx() {
+; Function Attrs: noinline
+define internal void @nvptx() {
 entry:
   %call = call i32 @llvm.nvvm.read.ptx.sreg.tid.x()
   %cmp = icmp eq i32 %call, 0
   br i1 %cmp, label %if.then, label %if.end
 
 if.then:
+  call void @foo()
   call void @bar()
   br label %if.end
 
@@ -30,14 +31,15 @@
 ; CHECK-NOT: [openmp-opt] Basic block @amdgcn entry is executed by a single thread.
 ; CHECK: [openmp-opt] Basic block @amdgcn if.then is executed by a single thread.
 ; CHECK-NOT: [openmp-opt] Basic block @amdgcn if.end is executed by a single thread.
-; Function Attrs: noinline nounwind uwtable
-define dso_local void @amdgcn() {
+; Function Attrs: noinline
+define internal void @amdgcn() {
 entry:
   %call = call i32 @llvm.amdgcn.workitem.id.x()
   %cmp = icmp eq i32 %call, 0
   br i1 %cmp, label %if.then, label %if.end
 
 if.then:
+  call void @foo()
   call void @bar()
   br label %if.end
 
@@ -45,9 +47,16 @@
   ret void
 }
 
-; CHECK: [openmp-opt] Basic block @bar entry is executed by a single thread.
-; Function Attrs: noinline nounwind uwtable
-define internal void @bar() {
+; CHECK: [openmp-opt] Basic block @foo entry is executed by a single thread.
+; Function Attrs: noinline
+define internal void @foo() {
+entry:
+  ret void
+}
+
+; CHECK: [openmp-opt] Basic block @bar.internalized entry is executed by a single thread.
+; Function Attrs: noinline
+define void @bar() {
 entry:
   ret void
 }
Index: llvm/test/Transforms/OpenMP/replace_globalization.ll
===
--- llvm/test/Transforms/OpenMP/replace_globalization.ll
+++ llvm/test/Transforms/OpenMP/replace_globalization.ll
@@ -2,6 +2,8 @@
 target datalayout = "e-i64:64-i128:128-v16:16-v32:32-n16:32:64"
 target triple = "nvptx64"
 
+@S = external local_unnamed_addr global i8*
+
 ; CHECK: [[SHARED_X:@.+]] = internal addrspace(3) global [16 x i8] undef
 ; CHECK: [[SHARED_Y:@.+]] = internal addrspace(3) global [4 x i8] undef
 
@@ -67,7 +69,7 @@
 define void @use(i8* %x) {
 entry:
   %addr = alloca i8*
-  store i8* %x, i8** %addr
+  store i8* %x, i8** @S
   ret void
 }
 
Index: llvm/lib/Transforms/IPO/OpenMPOpt.cpp
===
--- llvm/lib/Transforms/IPO/OpenMPOpt.cpp
+++ llvm/lib/Transforms/IPO/OpenMPOpt.cpp
@@ -1623,9 +1623,9 @@
 };
 GlobalizationRFI.foreachUse(SCC, CreateAA);
 
-for (auto &F : M) {
-  if (!F.isDeclaration())
-A.getOrCreateAAFor(IRPosition::function(F));
+for (auto *F : SCC) {
+  if (!F->isDeclaration())
+A.getOrCreateAAFor(IRPosition::function(*F));
 }
   }
 };
@@ -2620,11 +2620,19 @@
   if (DisableOpenMPOptimizations)
 return PreservedAnalyses::all();
 
-  // Look at every function definition in the Module.
+  // Create internal copies of each function if this is a kernel Module.
+  DenseSet InternalizedFuncs;
+  if (!OMPInModule.getKernels().empty())
+for (Function &F : M)
+  if (!F.isDeclaration() && !OMPInModule.getKernels().contains(&F))

[clang] 78d404a - [clang][c++20] Fix false warning for unused private fields when a class has only defaulted comparison operators.

2021-06-22 Thread Hans Wennborg via cfe-commits

Author: Alexandru Octavian Butiu
Date: 2021-06-22T18:40:16+02:00
New Revision: 78d404a11dd33c8349fd9b6ef5876d523c457f0e

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

LOG: [clang][c++20] Fix false warning for unused private fields when a class 
has only defaulted comparison operators.

Fixes bug 50263

When "unused-private-field" flag is on if you have a struct with private
members and only defaulted comparison operators clang will warn about
unused private fields.

If you where to write the comparison operators by hand no warning is
produced.

This is a bug since defaulting a comparison operator uses all private
members .

The fix is simple, in CheckExplicitlyDefaultedFunction just clear the
list of unused private fields if the defaulted function is a comparison
function.

Differential revision: https://reviews.llvm.org/D102186

Added: 


Modified: 
clang/lib/Sema/SemaDeclCXX.cpp
clang/test/SemaCXX/warn-unused-private-field.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaDeclCXX.cpp b/clang/lib/Sema/SemaDeclCXX.cpp
index 5109f1e877a26..6d2710f1774ce 100644
--- a/clang/lib/Sema/SemaDeclCXX.cpp
+++ b/clang/lib/Sema/SemaDeclCXX.cpp
@@ -7292,6 +7292,9 @@ void Sema::CheckExplicitlyDefaultedFunction(Scope *S, 
FunctionDecl *FD) {
 return;
   }
 
+  if (DefKind.isComparison())
+UnusedPrivateFields.clear();
+
   if (DefKind.isSpecialMember()
   ? CheckExplicitlyDefaultedSpecialMember(cast(FD),
   DefKind.asSpecialMember())

diff  --git a/clang/test/SemaCXX/warn-unused-private-field.cpp 
b/clang/test/SemaCXX/warn-unused-private-field.cpp
index fe44122a1d051..e67603eaceae6 100644
--- a/clang/test/SemaCXX/warn-unused-private-field.cpp
+++ b/clang/test/SemaCXX/warn-unused-private-field.cpp
@@ -1,5 +1,26 @@
 // RUN: %clang_cc1 -fsyntax-only -Wunused-private-field 
-Wused-but-marked-unused -Wno-uninitialized -verify -std=c++11 %s
 // RUN: %clang_cc1 -fsyntax-only -Wunused-private-field 
-Wused-but-marked-unused -Wno-uninitialized -verify -std=c++17 %s
+// RUN: %clang_cc1 -fsyntax-only -Wunused-private-field 
-Wused-but-marked-unused -Wno-uninitialized -verify -std=c++20 %s
+
+#if __cplusplus >= 202002L
+
+class EqDefaultCompare {
+  int used;
+
+public:
+  EqDefaultCompare(int x) : used(x) {}
+  bool operator==(const EqDefaultCompare &) const = default;
+};
+
+class SpaceShipDefaultCompare {
+  int used;
+
+public:
+  SpaceShipDefaultCompare(int x) : used(x) {}
+  int operator<=>(const SpaceShipDefaultCompare &) const = default;
+};
+
+#endif
 
 class NotFullyDefined {
  public:



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


[PATCH] D102186: [clang][c++20] Fix false warning for unused private fields when a class has only defaulted comparison operators.

2021-06-22 Thread Hans Wennborg 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 rG78d404a11dd3: [clang][c++20] Fix false warning for unused 
private fields when a class has… (authored by Alexandru Octavian Butiu 
, committed by hans).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102186

Files:
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/SemaCXX/warn-unused-private-field.cpp


Index: clang/test/SemaCXX/warn-unused-private-field.cpp
===
--- clang/test/SemaCXX/warn-unused-private-field.cpp
+++ clang/test/SemaCXX/warn-unused-private-field.cpp
@@ -1,5 +1,26 @@
 // RUN: %clang_cc1 -fsyntax-only -Wunused-private-field 
-Wused-but-marked-unused -Wno-uninitialized -verify -std=c++11 %s
 // RUN: %clang_cc1 -fsyntax-only -Wunused-private-field 
-Wused-but-marked-unused -Wno-uninitialized -verify -std=c++17 %s
+// RUN: %clang_cc1 -fsyntax-only -Wunused-private-field 
-Wused-but-marked-unused -Wno-uninitialized -verify -std=c++20 %s
+
+#if __cplusplus >= 202002L
+
+class EqDefaultCompare {
+  int used;
+
+public:
+  EqDefaultCompare(int x) : used(x) {}
+  bool operator==(const EqDefaultCompare &) const = default;
+};
+
+class SpaceShipDefaultCompare {
+  int used;
+
+public:
+  SpaceShipDefaultCompare(int x) : used(x) {}
+  int operator<=>(const SpaceShipDefaultCompare &) const = default;
+};
+
+#endif
 
 class NotFullyDefined {
  public:
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -7292,6 +7292,9 @@
 return;
   }
 
+  if (DefKind.isComparison())
+UnusedPrivateFields.clear();
+
   if (DefKind.isSpecialMember()
   ? CheckExplicitlyDefaultedSpecialMember(cast(FD),
   DefKind.asSpecialMember())


Index: clang/test/SemaCXX/warn-unused-private-field.cpp
===
--- clang/test/SemaCXX/warn-unused-private-field.cpp
+++ clang/test/SemaCXX/warn-unused-private-field.cpp
@@ -1,5 +1,26 @@
 // RUN: %clang_cc1 -fsyntax-only -Wunused-private-field -Wused-but-marked-unused -Wno-uninitialized -verify -std=c++11 %s
 // RUN: %clang_cc1 -fsyntax-only -Wunused-private-field -Wused-but-marked-unused -Wno-uninitialized -verify -std=c++17 %s
+// RUN: %clang_cc1 -fsyntax-only -Wunused-private-field -Wused-but-marked-unused -Wno-uninitialized -verify -std=c++20 %s
+
+#if __cplusplus >= 202002L
+
+class EqDefaultCompare {
+  int used;
+
+public:
+  EqDefaultCompare(int x) : used(x) {}
+  bool operator==(const EqDefaultCompare &) const = default;
+};
+
+class SpaceShipDefaultCompare {
+  int used;
+
+public:
+  SpaceShipDefaultCompare(int x) : used(x) {}
+  int operator<=>(const SpaceShipDefaultCompare &) const = default;
+};
+
+#endif
 
 class NotFullyDefined {
  public:
Index: clang/lib/Sema/SemaDeclCXX.cpp
===
--- clang/lib/Sema/SemaDeclCXX.cpp
+++ clang/lib/Sema/SemaDeclCXX.cpp
@@ -7292,6 +7292,9 @@
 return;
   }
 
+  if (DefKind.isComparison())
+UnusedPrivateFields.clear();
+
   if (DefKind.isSpecialMember()
   ? CheckExplicitlyDefaultedSpecialMember(cast(FD),
   DefKind.asSpecialMember())
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D102186: [clang][c++20] Fix false warning for unused private fields when a class has only defaulted comparison operators.

2021-06-22 Thread Hans Wennborg via Phabricator via cfe-commits
hans added a comment.

In D102186#2832900 , @predator5047 
wrote:

> @hans Can you commit on my behalf? 
> Email: Alexandru Octavian Butiu alexandru.octavian.butiu at gmail.com

Sure! Pushed as 
https://github.com/llvm/llvm-project/commit/78d404a11dd33c8349fd9b6ef5876d523c457f0e


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102186

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


[PATCH] D101899: std::forward_list::swap to use propagate_on_container_swap for noexcept specification

2021-06-22 Thread Louis Dionne via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG7adf713a5e22: [libc++] Change forward_list::swap to use 
propagate_on_container_swap for… (authored by airglow923, committed by ldionne).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D101899

Files:
  libcxx/include/forward_list


Index: libcxx/include/forward_list
===
--- libcxx/include/forward_list
+++ libcxx/include/forward_list
@@ -534,7 +534,7 @@
 #if _LIBCPP_STD_VER >= 14
 _NOEXCEPT;
 #else
-
_NOEXCEPT_(!__node_traits::propagate_on_container_move_assignment::value ||
+_NOEXCEPT_(!__node_traits::propagate_on_container_swap::value ||
 __is_nothrow_swappable<__node_allocator>::value);
 #endif
 protected:
@@ -599,7 +599,7 @@
 #if _LIBCPP_STD_VER >= 14
 _NOEXCEPT
 #else
-
_NOEXCEPT_(!__node_traits::propagate_on_container_move_assignment::value ||
+_NOEXCEPT_(!__node_traits::propagate_on_container_swap::value ||
 __is_nothrow_swappable<__node_allocator>::value)
 #endif
 {


Index: libcxx/include/forward_list
===
--- libcxx/include/forward_list
+++ libcxx/include/forward_list
@@ -534,7 +534,7 @@
 #if _LIBCPP_STD_VER >= 14
 _NOEXCEPT;
 #else
-_NOEXCEPT_(!__node_traits::propagate_on_container_move_assignment::value ||
+_NOEXCEPT_(!__node_traits::propagate_on_container_swap::value ||
 __is_nothrow_swappable<__node_allocator>::value);
 #endif
 protected:
@@ -599,7 +599,7 @@
 #if _LIBCPP_STD_VER >= 14
 _NOEXCEPT
 #else
-_NOEXCEPT_(!__node_traits::propagate_on_container_move_assignment::value ||
+_NOEXCEPT_(!__node_traits::propagate_on_container_swap::value ||
 __is_nothrow_swappable<__node_allocator>::value)
 #endif
 {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] f53d791 - Improve the diagnostic of DiagnosticInfoResourceLimit (and warn-stack-size in particular)

2021-06-22 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2021-06-22T09:55:20-07:00
New Revision: f53d791520d85c5404381ff3ad92cb918256029d

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

LOG: Improve the diagnostic of DiagnosticInfoResourceLimit (and warn-stack-size 
in particular)

Before: `warning: stack size limit exceeded (888) in main`
After: `warning: stack frame size (888) exceeds limit (100) in function 'main'` 
(the -Wframe-larger-than limit will be mentioned)

Reviewed By: nickdesaulniers

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

Added: 


Modified: 
clang/test/Misc/backend-resource-limit-diagnostics.cl
clang/test/Misc/backend-stack-frame-diagnostics-fallback.cpp
llvm/include/llvm/IR/DiagnosticInfo.h
llvm/lib/CodeGen/PrologEpilogInserter.cpp
llvm/lib/IR/DiagnosticInfo.cpp
llvm/test/CodeGen/AMDGPU/exceed-max-sgprs.ll
llvm/test/CodeGen/AMDGPU/stack-size-overflow.ll
llvm/test/CodeGen/ARM/warn-stack.ll
llvm/test/CodeGen/X86/warn-stack.ll

Removed: 




diff  --git a/clang/test/Misc/backend-resource-limit-diagnostics.cl 
b/clang/test/Misc/backend-resource-limit-diagnostics.cl
index 6e7619babe83b..d80f44f691867 100644
--- a/clang/test/Misc/backend-resource-limit-diagnostics.cl
+++ b/clang/test/Misc/backend-resource-limit-diagnostics.cl
@@ -1,7 +1,7 @@
 // REQUIRES: amdgpu-registered-target
 // RUN: not %clang_cc1 -emit-codegen-only -triple=amdgcn-- %s 2>&1 | FileCheck 
%s
 
-// CHECK: error: local memory limit exceeded (48) in use_huge_lds
+// CHECK: error: local memory (48) exceeds limit in function 'use_huge_lds'
 kernel void use_huge_lds()
 {
 volatile local int huge[12];

diff  --git a/clang/test/Misc/backend-stack-frame-diagnostics-fallback.cpp 
b/clang/test/Misc/backend-stack-frame-diagnostics-fallback.cpp
index 01b9ff598d86a..d28d54b0e8a2d 100644
--- a/clang/test/Misc/backend-stack-frame-diagnostics-fallback.cpp
+++ b/clang/test/Misc/backend-stack-frame-diagnostics-fallback.cpp
@@ -13,7 +13,7 @@ namespace frameSizeThunkWarning {
   };
 
   // CHECK: warning: stack frame size of {{[0-9]+}} bytes in function 
'frameSizeThunkWarning::B::f'
-  // CHECK: warning: stack size limit exceeded ({{[0-9]+}}) in {{[^ ]+}}
+  // CHECK: warning: stack frame size ([[#]]) exceeds limit in function 
'_ZTv0_n12_N21frameSizeThunkWarning1B1fEv'
   void B::f() {
 volatile int x = 0; // Ensure there is stack usage.
   }

diff  --git a/llvm/include/llvm/IR/DiagnosticInfo.h 
b/llvm/include/llvm/IR/DiagnosticInfo.h
index 89c3f1ba9761e..9134ca12600b2 100644
--- a/llvm/include/llvm/IR/DiagnosticInfo.h
+++ b/llvm/include/llvm/IR/DiagnosticInfo.h
@@ -220,7 +220,7 @@ class DiagnosticInfoStackSize : public 
DiagnosticInfoResourceLimit {
   DiagnosticInfoStackSize(const Function &Fn, uint64_t StackSize,
   DiagnosticSeverity Severity = DS_Warning,
   uint64_t StackLimit = 0)
-  : DiagnosticInfoResourceLimit(Fn, "stack size", StackSize, Severity,
+  : DiagnosticInfoResourceLimit(Fn, "stack frame size", StackSize, 
Severity,
 DK_StackSize, StackLimit) {}
 
   uint64_t getStackSize() const { return getResourceSize(); }

diff  --git a/llvm/lib/CodeGen/PrologEpilogInserter.cpp 
b/llvm/lib/CodeGen/PrologEpilogInserter.cpp
index e745f561a8961..2f65a450fb02a 100644
--- a/llvm/lib/CodeGen/PrologEpilogInserter.cpp
+++ b/llvm/lib/CodeGen/PrologEpilogInserter.cpp
@@ -285,7 +285,7 @@ bool PEI::runOnMachineFunction(MachineFunction &MF) {
 (void)Failed;
   }
   if (StackSize > Threshold) {
-DiagnosticInfoStackSize DiagStackSize(F, StackSize);
+DiagnosticInfoStackSize DiagStackSize(F, StackSize, DS_Warning, Threshold);
 F.getContext().diagnose(DiagStackSize);
   }
   ORE->emit([&]() {

diff  --git a/llvm/lib/IR/DiagnosticInfo.cpp b/llvm/lib/IR/DiagnosticInfo.cpp
index 59541704ef52c..f921382748018 100644
--- a/llvm/lib/IR/DiagnosticInfo.cpp
+++ b/llvm/lib/IR/DiagnosticInfo.cpp
@@ -70,12 +70,10 @@ void DiagnosticInfoInlineAsm::print(DiagnosticPrinter &DP) 
const {
 }
 
 void DiagnosticInfoResourceLimit::print(DiagnosticPrinter &DP) const {
-  DP << getResourceName() << " limit";
-
+  DP << getResourceName() << " (" << getResourceSize() << ") exceeds limit";
   if (getResourceLimit() != 0)
-DP << " of " << getResourceLimit();
-
-  DP << " exceeded (" <<  getResourceSize() << ") in " << getFunction();
+DP << " (" << getResourceLimit() << ')';
+  DP << " in function '" << getFunction() << '\'';
 }
 
 void DiagnosticInfoDebugMetadataVersion::print(DiagnosticPrinter &DP) const {

diff  --git a/llvm/test/CodeGen/AMDGPU/exceed-max-sgprs.ll 
b/llvm/test/CodeGen/AMDGPU/exceed-max-sgprs.ll
index 13aafc24895df..ad2c6debda7e9 100644
--- a/llvm/test/CodeGen/AMDGPU/exceed-max-sg

[PATCH] D104667: Improve the diagnostic of DiagnosticInfoResourceLimit (and warn-stack-size in particular)

2021-06-22 Thread Fangrui Song 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 rGf53d791520d8: Improve the diagnostic of 
DiagnosticInfoResourceLimit (and warn-stack-size in… (authored by MaskRay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104667

Files:
  clang/test/Misc/backend-resource-limit-diagnostics.cl
  clang/test/Misc/backend-stack-frame-diagnostics-fallback.cpp
  llvm/include/llvm/IR/DiagnosticInfo.h
  llvm/lib/CodeGen/PrologEpilogInserter.cpp
  llvm/lib/IR/DiagnosticInfo.cpp
  llvm/test/CodeGen/AMDGPU/exceed-max-sgprs.ll
  llvm/test/CodeGen/AMDGPU/stack-size-overflow.ll
  llvm/test/CodeGen/ARM/warn-stack.ll
  llvm/test/CodeGen/X86/warn-stack.ll

Index: llvm/test/CodeGen/X86/warn-stack.ll
===
--- llvm/test/CodeGen/X86/warn-stack.ll
+++ llvm/test/CodeGen/X86/warn-stack.ll
@@ -1,5 +1,5 @@
 ; RUN: llc -mtriple x86_64-apple-macosx10.8.0 < %s 2>&1 >/dev/null | FileCheck %s
-; Check the internal option that warns when the stack size exceeds the
+; Check the internal option that warns when the stack frame size exceeds the
 ; given amount.
 ; 
 
@@ -12,7 +12,7 @@
   ret void
 }
 
-; CHECK: warning: stack size limit exceeded (88) in warn
+; CHECK: warning: stack frame size (88) exceeds limit (80) in function 'warn'
 define void @warn() nounwind ssp "warn-stack-size"="80" {
 entry:
   %buffer = alloca [80 x i8], align 1
Index: llvm/test/CodeGen/ARM/warn-stack.ll
===
--- llvm/test/CodeGen/ARM/warn-stack.ll
+++ llvm/test/CodeGen/ARM/warn-stack.ll
@@ -1,5 +1,5 @@
 ; RUN: llc -mtriple thumbv7-apple-ios3.0.0 < %s 2>&1 >/dev/null | FileCheck %s
-; Check the internal option that warns when the stack size exceeds the
+; Check the internal option that warns when the stack frame size exceeds the
 ; given amount.
 ; 
 
@@ -12,7 +12,7 @@
   ret void
 }
 
-; CHECK: warning: stack size limit exceeded (92) in warn
+; CHECK: warning: stack frame size (92) exceeds limit (80) in function 'warn'
 define void @warn() nounwind ssp "frame-pointer"="all" "warn-stack-size"="80" {
 entry:
   %buffer = alloca [80 x i8], align 1
Index: llvm/test/CodeGen/AMDGPU/stack-size-overflow.ll
===
--- llvm/test/CodeGen/AMDGPU/stack-size-overflow.ll
+++ llvm/test/CodeGen/AMDGPU/stack-size-overflow.ll
@@ -3,7 +3,7 @@
 
 declare void @llvm.memset.p5i8.i32(i8 addrspace(5)* nocapture, i8, i32, i32, i1) #1
 
-; ERROR: error: stack size limit exceeded (131061) in stack_size_limit_wave64
+; ERROR: error: stack frame size (131061) exceeds limit in function 'stack_size_limit_wave64'
 ; GCN: ; ScratchSize: 131061
 define amdgpu_kernel void @stack_size_limit_wave64() #0 {
 entry:
@@ -13,7 +13,7 @@
   ret void
 }
 
-; ERROR: error: stack size limit exceeded (262117) in stack_size_limit_wave32
+; ERROR: error: stack frame size (262117) exceeds limit in function 'stack_size_limit_wave32'
 ; GCN: ; ScratchSize: 262117
 define amdgpu_kernel void @stack_size_limit_wave32() #1 {
 entry:
Index: llvm/test/CodeGen/AMDGPU/exceed-max-sgprs.ll
===
--- llvm/test/CodeGen/AMDGPU/exceed-max-sgprs.ll
+++ llvm/test/CodeGen/AMDGPU/exceed-max-sgprs.ll
@@ -1,6 +1,6 @@
 ; RUN: not llc -march=amdgcn -verify-machineinstrs < %s 2>&1 | FileCheck -check-prefix=ERROR %s
 
-; ERROR: error: scalar registers limit of 104 exceeded (106) in use_too_many_sgprs_tahiti
+; ERROR: error: scalar registers (106) exceeds limit (104) in function 'use_too_many_sgprs_tahiti'
 define amdgpu_kernel void @use_too_many_sgprs_tahiti() #0 {
   call void asm sideeffect "", "~{s[0:7]}" ()
   call void asm sideeffect "", "~{s[8:15]}" ()
@@ -19,7 +19,7 @@
   ret void
 }
 
-; ERROR: error: scalar registers limit of 104 exceeded (106) in use_too_many_sgprs_bonaire
+; ERROR: error: scalar registers (106) exceeds limit (104) in function 'use_too_many_sgprs_bonaire'
 define amdgpu_kernel void @use_too_many_sgprs_bonaire() #1 {
   call void asm sideeffect "", "~{s[0:7]}" ()
   call void asm sideeffect "", "~{s[8:15]}" ()
@@ -38,7 +38,7 @@
   ret void
 }
 
-; ERROR: error: scalar registers limit of 104 exceeded (108) in use_too_many_sgprs_bonaire_flat_scr
+; ERROR: error: scalar registers (108) exceeds limit (104) in function 'use_too_many_sgprs_bonaire_flat_scr'
 define amdgpu_kernel void @use_too_many_sgprs_bonaire_flat_scr() #1 {
   call void asm sideeffect "", "~{s[0:7]}" ()
   call void asm sideeffect "", "~{s[8:15]}" ()
@@ -58,7 +58,7 @@
   ret void
 }
 
-; ERROR: error: scalar registers limit of 96 exceeded (98) in use_too_many_sgprs_iceland
+; ERROR: error: scalar registers (98) exceeds limit (96) in function 'use_too_many_sgprs_iceland'
 define amdgpu_kernel void @use_too_many_sgprs_iceland() #2 {
  

[PATCH] D102507: [HIP] Support in device code

2021-06-22 Thread Louis Dionne via Phabricator via cfe-commits
ldionne added a comment.

In D102507#2830688 , @yaxunl wrote:

> In D102507#2792087 , @rsmith wrote:
>
>> @ldionne How should we go about establishing whether libc++ would be 
>> prepared to officially support CUDA? Right now, Clang's CUDA support is 
>> patching in attributes onto libc++ functions from the outside, which doesn't 
>> seem like a sustainable model.
>
> ping

If the current approach is to patch libc++ from the outside, then yeah, that's 
most definitely not a great design IMO. It's going to be very brittle. I think 
it *may* be reasonable to support this in libc++, but I'd like to see some sort 
of basic explanation of what the changes would be so we can have a discussion 
and make our mind up about whether we can support this, and what's the best way 
of doing it.


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

https://reviews.llvm.org/D102507

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


[PATCH] D104058: ThinLTO: Fix inline assembly references to static functions with CFI

2021-06-22 Thread Sami Tolvanen via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG4474958d3a97: ThinLTO: Fix inline assembly references to 
static functions with CFI (authored by samitolvanen).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104058

Files:
  llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
  llvm/test/Transforms/ThinLTOBitcodeWriter/cfi-icall-static-inline-asm.ll


Index: llvm/test/Transforms/ThinLTOBitcodeWriter/cfi-icall-static-inline-asm.ll
===
--- /dev/null
+++ llvm/test/Transforms/ThinLTOBitcodeWriter/cfi-icall-static-inline-asm.ll
@@ -0,0 +1,19 @@
+; RUN: opt -thinlto-bc -thinlto-split-lto-unit -o - %s | llvm-modextract -b -n 
0 -o - | llvm-dis | FileCheck %s
+
+; CHECK: @a = internal alias {{.*}}@a.[[HASH:[0-9a-f]+]]
+
+define void @b() {
+  %f = alloca void ()*, align 8
+  ; CHECK: store{{.*}} @a.[[HASH]],{{.*}} %f
+  store void ()* @a, void ()** %f, align 8
+  ; CHECK: %1 = call void ()* asm sideeffect "leaq a(%rip)
+  %1 = call void ()* asm sideeffect "leaq a(%rip), $0\0A\09", 
"=r,~{dirflag},~{fpsr},~{flags}"()
+  ret void
+}
+
+; CHECK: define{{.*}} @a.[[HASH]](){{.*}} !type
+define internal void @a() !type !0 {
+  ret void
+}
+
+!0 = !{i64 0, !"typeid1"}
Index: llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
===
--- llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
+++ llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
@@ -69,6 +69,15 @@
   ImportGV->setName(NewName);
   ImportGV->setVisibility(GlobalValue::HiddenVisibility);
 }
+
+if (Function *F = dyn_cast(&ExportGV)) {
+  // Create a local alias with the original name to avoid breaking
+  // references from inline assembly.
+  GlobalAlias *A =
+  GlobalAlias::create(F->getValueType(), F->getAddressSpace(),
+  GlobalValue::InternalLinkage, Name, F, &ExportM);
+  appendToCompilerUsed(ExportM, A);
+}
   }
 
   if (!RenamedComdats.empty())


Index: llvm/test/Transforms/ThinLTOBitcodeWriter/cfi-icall-static-inline-asm.ll
===
--- /dev/null
+++ llvm/test/Transforms/ThinLTOBitcodeWriter/cfi-icall-static-inline-asm.ll
@@ -0,0 +1,19 @@
+; RUN: opt -thinlto-bc -thinlto-split-lto-unit -o - %s | llvm-modextract -b -n 0 -o - | llvm-dis | FileCheck %s
+
+; CHECK: @a = internal alias {{.*}}@a.[[HASH:[0-9a-f]+]]
+
+define void @b() {
+  %f = alloca void ()*, align 8
+  ; CHECK: store{{.*}} @a.[[HASH]],{{.*}} %f
+  store void ()* @a, void ()** %f, align 8
+  ; CHECK: %1 = call void ()* asm sideeffect "leaq a(%rip)
+  %1 = call void ()* asm sideeffect "leaq a(%rip), $0\0A\09", "=r,~{dirflag},~{fpsr},~{flags}"()
+  ret void
+}
+
+; CHECK: define{{.*}} @a.[[HASH]](){{.*}} !type
+define internal void @a() !type !0 {
+  ret void
+}
+
+!0 = !{i64 0, !"typeid1"}
Index: llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
===
--- llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
+++ llvm/lib/Transforms/IPO/ThinLTOBitcodeWriter.cpp
@@ -69,6 +69,15 @@
   ImportGV->setName(NewName);
   ImportGV->setVisibility(GlobalValue::HiddenVisibility);
 }
+
+if (Function *F = dyn_cast(&ExportGV)) {
+  // Create a local alias with the original name to avoid breaking
+  // references from inline assembly.
+  GlobalAlias *A =
+  GlobalAlias::create(F->getValueType(), F->getAddressSpace(),
+  GlobalValue::InternalLinkage, Name, F, &ExportM);
+  appendToCompilerUsed(ExportM, A);
+}
   }
 
   if (!RenamedComdats.empty())
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D104088: Add clang frontend flags for MIP

2021-06-22 Thread Ellis Hoag via Phabricator via cfe-commits
ellis updated this revision to Diff 353705.
ellis added a comment.

Correctly link the runtime symbol for Mach-O.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104088

Files:
  clang/include/clang/Driver/Options.td
  clang/include/clang/Driver/ToolChain.h
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/AIX.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/lib/Driver/ToolChains/Darwin.h
  clang/lib/Driver/ToolChains/DragonFly.cpp
  clang/lib/Driver/ToolChains/FreeBSD.cpp
  clang/lib/Driver/ToolChains/Fuchsia.cpp
  clang/lib/Driver/ToolChains/Fuchsia.h
  clang/lib/Driver/ToolChains/Gnu.cpp
  clang/lib/Driver/ToolChains/Linux.cpp
  clang/lib/Driver/ToolChains/Linux.h
  clang/lib/Driver/ToolChains/NetBSD.cpp
  clang/lib/Driver/ToolChains/Solaris.cpp
  clang/test/CMakeLists.txt
  clang/test/Driver/clang-mip-flags.c

Index: clang/test/Driver/clang-mip-flags.c
===
--- /dev/null
+++ clang/test/Driver/clang-mip-flags.c
@@ -0,0 +1,45 @@
+// REQUIRES: clang-driver
+// UNSUPPORTED: windows-msvc
+
+// RUN: %clang -### -fmachine-profile-use=/path/to/profile.mip %s 2>&1 | FileCheck %s --check-prefix USE
+// USE: "-cc1"
+// USE-SAME: "-mllvm" "-machine-profile-use=/path/to/profile.mip"
+// USE-SAME: "-mllvm" "-link-unit-name=a.out"
+
+// RUN: %clang -### -fmachine-profile-use=/path/to/profile.mip -o my-executable %s 2>&1 | FileCheck %s --check-prefix USE-OUTPUT
+// RUN: %clang -### -fmachine-profile-use=/path/to/profile.mip -fmachine-profile-link-unit-name=my-executable %s 2>&1 | FileCheck %s --check-prefix USE-OUTPUT
+// USE-OUTPUT: "-cc1"
+// USE-OUTPUT-SAME: "-mllvm" "-link-unit-name=my-executable"
+
+// RUN: %clang -### -fmachine-profile-generate %s 2>&1 | FileCheck %s --check-prefix GEN
+// RUN: %clang -### -fno-machine-profile-generate -fmachine-profile-generate %s 2>&1 | FileCheck %s --check-prefix GEN
+// GEN: "-cc1"
+// GEN-SAME: "-mllvm" "-enable-machine-instrumentation"
+// GEN-SAME: "-mllvm" "-link-unit-name=a.out"
+
+// RUN: %clang -### %s 2>&1 | FileCheck %s --check-prefix NOGEN
+// RUN: %clang -### -fno-machine-profile-generate %s 2>&1 | FileCheck %s --check-prefix NOGEN
+// RUN: %clang -### -fmachine-profile-generate -fno-machine-profile-generate %s 2>&1 | FileCheck %s --check-prefix NOGEN
+// NOGEN-NOT: "-enable-machine-instrumentation"
+
+// RUN: %clang -### -fmachine-profile-generate -fmachine-profile-function-coverage %s 2>&1 | FileCheck %s --check-prefix FUNCCOV
+// FUNCCOV: "-cc1"
+// FUNCCOV-SAME: "-mllvm" "-enable-machine-function-coverage"
+
+// RUN: %clang -### -fmachine-profile-generate -fmachine-profile-block-coverage %s 2>&1 | FileCheck %s --check-prefix BLOCKCOV
+// BLOCKCOV: "-cc1"
+// BLOCKCOV-SAME: "-mllvm" "-enable-machine-block-coverage"
+
+// RUN: %clang -### -fmachine-profile-generate %s 2>&1 | FileCheck %s --check-prefix FULL
+// RUN: %clang -### -fmachine-profile-generate -fmachine-profile-call-graph %s 2>&1 | FileCheck %s --check-prefix FULL
+// FULL: "-cc1"
+// FULL-SAME: "-mllvm" "-enable-machine-call-graph"
+
+// RUN: %clang -### -fmachine-profile-generate -fmachine-profile-runtime-buffer=1024 %s 2>&1 | FileCheck %s --check-prefix RUNTIMEBUF
+// RUNTIMEBUF: "-cc1"
+// RUNTIMEBUF-SAME: "-mllvm" "-machine-profile-runtime-buffer=1024"
+
+// RUN: %clang -### -fmachine-profile-generate -fmachine-profile-function-group-count=22 -fmachine-profile-selected-function-group=11 %s 2>&1 | FileCheck %s --check-prefix GEN-GROUPS
+// GEN-GROUPS: "-cc1"
+// GEN-GROUPS-SAME: "-mllvm" "-machine-profile-function-group-count=22"
+// GEN-GROUPS-SAME: "-mllvm" "-machine-profile-selected-function-group=11"
Index: clang/test/CMakeLists.txt
===
--- clang/test/CMakeLists.txt
+++ clang/test/CMakeLists.txt
@@ -118,6 +118,7 @@
 llvm-lto2
 llvm-modextract
 llvm-nm
+llvm-mipdata
 llvm-objcopy
 llvm-objdump
 llvm-profdata
Index: clang/lib/Driver/ToolChains/Solaris.cpp
===
--- clang/lib/Driver/ToolChains/Solaris.cpp
+++ clang/lib/Driver/ToolChains/Solaris.cpp
@@ -149,6 +149,7 @@
   CmdArgs.push_back(Args.MakeArgString(getToolChain().GetFilePath("crtn.o")));
 
   getToolChain().addProfileRTLibs(Args, CmdArgs);
+  getToolChain().addMachineProfileRTLibs(Args, CmdArgs);
 
   const char *Exec = Args.MakeArgString(getToolChain().GetLinkerPath());
   C.addCommand(std::make_unique(JA, *this, ResponseFileSupport::None(),
Index: clang/lib/Driver/ToolChains/NetBSD.cpp
===
--- clang/lib/Driver/ToolChains/NetBSD.cpp
+++ clang/lib/Driver/ToolChains/NetBSD.cpp
@@ -337,6 +337,7 @@
   }
 
   ToolChain.addProfileRTLibs(Args, CmdArgs);
+  ToolChain.addMachineProfileRTLibs(Args, CmdArgs);
 
   const char *Exec 

[PATCH] D104505: [HIP] Defer operator overloading errors

2021-06-22 Thread Artem Belevich via Phabricator via cfe-commits
tra added a comment.

In D104505#2833271 , @yaxunl wrote:

> Such host/device overloading resolution induced issue is not limited to 
> device functions calling host functions.

It does not change the fact that the code in the test above is invalid, 
regardless of whether we compile it on the host or on the device.

> It could also happen to host device functions calling host functions, which 
> is less controversial for deferring.

H/D functions are special, because their overloading is affected whether 
compilation is done on the host or on the device side and we often can not tell 
whether the diagnostic is appropriate until codegen.

I still think that deferring diags for unambiguously invalid code is not a good 
idea. The fact that NVCC can only diagnose such errors during device-side 
compilation is not a good enough reason, IMO, to make clang ignore real errors, 
even if we'd still end up eventually failing later, during device-side 
compilation.

@rsmith, @rjmccall  -- any thoughts?


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

https://reviews.llvm.org/D104505

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


[PATCH] D104616: [analyzer][WIP] Model comparision methods of std::unique_ptr

2021-06-22 Thread Deep Majumder via Phabricator via cfe-commits
RedDocMD updated this revision to Diff 353709.
RedDocMD added a comment.

Logic for handling special cases, when both are unique_ptr


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104616

Files:
  clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp

Index: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
+++ clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp
@@ -68,6 +68,7 @@
   bool updateMovedSmartPointers(CheckerContext &C, const MemRegion *ThisRegion,
 const MemRegion *OtherSmartPtrRegion) const;
   void handleBoolConversion(const CallEvent &Call, CheckerContext &C) const;
+  bool handleComparisionOp(const CallEvent &Call, CheckerContext &C) const;
 
   using SmartPtrMethodHandlerFn =
   void (SmartPtrModeling::*)(const CallEvent &Call, CheckerContext &) const;
@@ -264,6 +265,11 @@
   if (handleAssignOp(Call, C))
 return true;
 
+  // FIXME: This won't work
+  // Check for one arg or the other being a smart-ptr.
+  if (handleComparisionOp(Call, C))
+return true;
+
   const SmartPtrMethodHandlerFn *Handler = SmartPtrMethodHandlers.lookup(Call);
   if (!Handler)
 return false;
@@ -272,6 +278,177 @@
   return C.isDifferent();
 }
 
+bool SmartPtrModeling::handleComparisionOp(const CallEvent &Call,
+   CheckerContext &C) const {
+  const auto *MC = llvm::dyn_cast(&Call);
+  if (!MC)
+return false;
+  const OverloadedOperatorKind OOK = MC->getOperator();
+  if (!(OOK == OO_Equal || OOK == OO_ExclaimEqual || OOK == OO_Less ||
+OOK == OO_LessEqual || OOK == OO_Greater || OOK == OO_GreaterEqual ||
+OOK == OO_Spaceship))
+return false;
+
+  SVal First = Call.getArgSVal(0);
+  SVal Second = Call.getArgSVal(1);
+
+  // There are some special cases about which we can infer about
+  // the resulting answer.
+  // For reference, there is a discussion at https://reviews.llvm.org/D104616.
+  // Also, the cppreference page is good to look at
+  // https://en.cppreference.com/w/cpp/memory/unique_ptr/operator_cmp.
+
+  bool addTransition = false;
+  ProgramStateRef State = C.getState();
+  SVal RetVal = C.getSValBuilder().conjureSymbolVal(
+  Call.getOriginExpr(), C.getLocationContext(), Call.getResultType(),
+  C.blockCount());
+
+  if (!First.isZeroConstant() && !Second.isZeroConstant()) {
+// Neither are nullptr, so they are both std::unique_ptr. (whether the smart
+// pointers are null or not is an entire different question.)
+const MemRegion *FirstReg = First.getAsRegion();
+const MemRegion *SecondReg = Second.getAsRegion();
+if (!FirstReg || !SecondReg)
+  return false;
+
+// First and Second may refer to the same object
+if (FirstReg == SecondReg) {
+  switch (OOK) {
+  case OO_Equal:
+  case OO_GreaterEqual:
+  case OO_LessEqual:
+State =
+State->assume(llvm::dyn_cast(RetVal), true);
+addTransition = true;
+break;
+  case OO_Greater:
+  case OO_Less:
+State =
+State->assume(llvm::dyn_cast(RetVal), false);
+addTransition = true;
+break;
+  case OO_Spaceship:
+// TODO: What would be a good thing to do here?
+  default:
+assert(false && "shouldn't reach here");
+  }
+} else {
+  const auto *FirstPtr = State->get(FirstReg);
+  const auto *SecondPtr = State->get(SecondReg);
+
+  if (!FirstPtr && !SecondPtr)
+return false;
+
+  // Now, we know the inner pointer of at least one
+
+  if (FirstPtr && !SecondPtr &&
+  State->assume(llvm::dyn_cast(*FirstPtr),
+false)) {
+// FirstPtr is null, SecondPtr is unknown
+if (OOK == OO_LessEqual) {
+  State =
+  State->assume(llvm::dyn_cast(RetVal), true);
+  addTransition = true;
+}
+  }
+  if (SecondPtr && !FirstPtr &&
+  State->assume(llvm::dyn_cast(*SecondPtr),
+false)) {
+// SecondPtr is null, FirstPtr is unknown
+if (OOK == OO_GreaterEqual) {
+  State =
+  State->assume(llvm::dyn_cast(RetVal), true);
+  addTransition = true;
+}
+  }
+
+  if (FirstPtr && SecondPtr) {
+bool FirstNull{!State->assume(
+llvm::dyn_cast(*FirstPtr), true)};
+bool SecondNull{!State->assume(
+llvm::dyn_cast(*SecondPtr), true)};
+
+if (FirstNull && SecondNull) {
+  switch (OOK) {
+  case OO_Equal:
+  case OO_GreaterEqual:
+  case OO_LessEqual:
+State = State->assume(llvm::dyn_cast(RetVal),
+  true);
+addTransition = true;
+break;
+  case OO_Greate

[PATCH] D103986: [PowerPC] Floating Point Builtins for XL Compat.

2021-06-22 Thread Quinn Pham via Phabricator via cfe-commits
quinnp updated this revision to Diff 353716.
quinnp marked 2 inline comments as done.
quinnp added a comment.

Fixing the 32bit AIX run line in the testcases.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D103986

Files:
  clang/include/clang/Basic/BuiltinsPPC.def
  clang/lib/Basic/Targets/PPC.h
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-ppc-xlcompat-fp.c
  llvm/include/llvm/IR/IntrinsicsPowerPC.td
  llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp
  llvm/lib/Target/PowerPC/PPCInstrInfo.td
  llvm/lib/Target/PowerPC/PPCInstrVSX.td
  llvm/test/CodeGen/builtins-ppc-xlcompat-fp.ll

Index: llvm/test/CodeGen/builtins-ppc-xlcompat-fp.ll
===
--- /dev/null
+++ llvm/test/CodeGen/builtins-ppc-xlcompat-fp.ll
@@ -0,0 +1,60 @@
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-unknown \
+; RUN: -mcpu=pwr7 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64le-unknown-unknown \
+; RUN: -mcpu=pwr8 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc64-unknown-aix \
+; RUN: -mcpu=pwr7 < %s | FileCheck %s
+; RUN: llc -verify-machineinstrs -mtriple=powerpc-unknown-aix \
+; RUN: -mcpu=pwr7 < %s | FileCheck %s
+
+define dso_local double @test_fsel(double %a, double %b, double %c) local_unnamed_addr #0 {
+; CHECK-LABEL: test_fsel 
+
+entry:
+  %0 = tail call double @llvm.ppc.fsel(double %a, double %b, double %c)
+; CHECK: fsel 1, 1, 2, 3
+
+  ret double %0
+; CHECK: blr
+}
+
+declare double @llvm.ppc.fsel(double, double, double) #2
+
+define dso_local float @test_fsels(float %a, float %b, float %c) local_unnamed_addr #0 {
+; CHECK-LABEL: test_fsels
+
+entry:
+  %0 = tail call float @llvm.ppc.fsels(float %a, float %b, float %c)
+; CHECK: fsel 1, 1, 2, 3
+
+  ret float %0
+; CHECK: blr
+}
+
+declare float @llvm.ppc.fsels(float, float, float) #2
+
+define dso_local double @test_frsqrte(double %a) local_unnamed_addr #0 {
+; CHECK-LABEL: test_frsqrte
+
+entry:
+  %0 = tail call double @llvm.ppc.frsqrte(double %a)
+; CHECK: xsrsqrtedp 1, 1
+
+  ret double %0
+; CHECK: blr
+}
+
+declare double @llvm.ppc.frsqrte(double) #2
+
+define dso_local float @test_frsqrtes(float %a) local_unnamed_addr #0 {
+; CHECK-LABEL: test_frsqrtes
+
+entry:
+  %0 = tail call float @llvm.ppc.frsqrtes(float %a)
+; CHECK: xsrsqrtesp 1, 1
+ 
+  ret float %0
+; CHECK: blr
+}
+
+declare float @llvm.ppc.frsqrtes(float) #2
Index: llvm/lib/Target/PowerPC/PPCInstrVSX.td
===
--- llvm/lib/Target/PowerPC/PPCInstrVSX.td
+++ llvm/lib/Target/PowerPC/PPCInstrVSX.td
@@ -4954,6 +4954,9 @@
 } // HasVSX, IsISA3_0, HasDirectMove, IsLittleEndian
 } // AddedComplexity = 400
 
+def : Pat<(int_ppc_frsqrte vsfrc:$XB), (XSRSQRTEDP $XB)>;
+def : Pat<(int_ppc_frsqrtes vssrc:$XB), (XSRSQRTESP $XB)>;
+
 // Instruction aliases ---//
 def : InstAlias<"xvmovdp $XT, $XB",
 (XVCPSGNDP vsrc:$XT, vsrc:$XB, vsrc:$XB)>;
Index: llvm/lib/Target/PowerPC/PPCInstrInfo.td
===
--- llvm/lib/Target/PowerPC/PPCInstrInfo.td
+++ llvm/lib/Target/PowerPC/PPCInstrInfo.td
@@ -3318,6 +3318,8 @@
   }
 }
 
+def : Pat<(int_ppc_fsel f8rc:$FRA, f8rc:$FRC, f8rc:$FRB), (FSELD $FRA, $FRC, $FRB)>;
+
 let hasSideEffects = 0 in {
 let PPC970_Unit = 1 in {  // FXU Operations.
   let isSelect = 1 in
Index: llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp
===
--- llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp
+++ llvm/lib/Target/PowerPC/PPCISelDAGToDAG.cpp
@@ -4987,6 +4987,13 @@
 break;
 
   case ISD::INTRINSIC_WO_CHAIN: {
+
+if (N->getConstantOperandVal(0) == Intrinsic::ppc_fsels) {
+  SDValue ops[] = {N->getOperand(1), N->getOperand(2), N->getOperand(3)};
+  CurDAG->SelectNodeTo(N, PPC::FSELS, MVT::f32, ops);
+  return;
+}
+
 if (!Subtarget->isISA3_1())
   break;
 unsigned Opcode = 0;
Index: llvm/include/llvm/IR/IntrinsicsPowerPC.td
===
--- llvm/include/llvm/IR/IntrinsicsPowerPC.td
+++ llvm/include/llvm/IR/IntrinsicsPowerPC.td
@@ -1523,5 +1523,16 @@
   Intrinsic<[],[],[]>;
   def int_ppc_iospace_eieio : GCCBuiltin<"__builtin_ppc_iospace_eieio">,
   Intrinsic<[],[],[]>;
+
+  def int_ppc_fsel : GCCBuiltin<"__builtin_ppc_fsel">,
+ Intrinsic<[llvm_double_ty], [llvm_double_ty, 
+ llvm_double_ty, llvm_double_ty], [IntrNoMem]>;
+  def int_ppc_fsels : GCCBuiltin<"__builtin_ppc_fsels">,
+  Intrinsic<[llvm_float_ty], [llvm_float_ty, llvm_float_ty,
+  llvm_float_ty], [IntrNoMem]>;
+  def int_ppc_frsqrte : GCCBuiltin<"__builtin_ppc_frsqrte">,
+

[PATCH] D100118: [clang] Add support for new builtin __arithmetic_fence to control floating point optimization, and new clang option fprotect-parens

2021-06-22 Thread Melanie Blower via Phabricator via cfe-commits
mibintc updated this revision to Diff 353719.
mibintc added a comment.
Herald added subscribers: jdoerfert, hiraditya.

This patch addresses almost all the review comments, not yet sure about 
@aaron.ballman 's question about CoreOptions


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D100118

Files:
  llvm/docs/LangRef.rst
  llvm/include/llvm/Analysis/TargetTransformInfoImpl.h
  llvm/include/llvm/CodeGen/BasicTTIImpl.h
  llvm/include/llvm/CodeGen/ISDOpcodes.h
  llvm/include/llvm/CodeGen/SelectionDAGISel.h
  llvm/include/llvm/IR/IRBuilder.h
  llvm/include/llvm/IR/Intrinsics.td
  llvm/include/llvm/Support/TargetOpcodes.def
  llvm/include/llvm/Target/Target.td
  llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp
  llvm/lib/CodeGen/SelectionDAG/LegalizeVectorTypes.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp
  llvm/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp
  llvm/test/CodeGen/X86/arithmetic_fence.ll
  llvm/test/CodeGen/X86/arithmetic_fence2.ll

Index: llvm/test/CodeGen/X86/arithmetic_fence2.ll
===
--- /dev/null
+++ llvm/test/CodeGen/X86/arithmetic_fence2.ll
@@ -0,0 +1,170 @@
+; NOTE: Assertions have been autogenerated by utils/update_llc_test_checks.py
+; RUN: llc < %s -mtriple=i686-unknown-unknown -mattr=+sse2 | FileCheck %s --check-prefix=X86
+; RUN: llc < %s -mtriple=x86_64-unknown-unknown -mattr=+sse2 | FileCheck %s --check-prefix=X64
+
+define double @f1(double %a) {
+; X86-LABEL: f1:
+; X86:   # %bb.0:
+; X86-NEXT:pushl %ebp
+; X86-NEXT:.cfi_def_cfa_offset 8
+; X86-NEXT:.cfi_offset %ebp, -8
+; X86-NEXT:movl %esp, %ebp
+; X86-NEXT:.cfi_def_cfa_register %ebp
+; X86-NEXT:andl $-8, %esp
+; X86-NEXT:subl $8, %esp
+; X86-NEXT:movsd {{.*#+}} xmm0 = mem[0],zero
+; X86-NEXT:mulsd {{\.?LCPI[0-9]+_[0-9]+}}, %xmm0
+; X86-NEXT:movsd %xmm0, (%esp)
+; X86-NEXT:fldl (%esp)
+; X86-NEXT:movl %ebp, %esp
+; X86-NEXT:popl %ebp
+; X86-NEXT:.cfi_def_cfa %esp, 4
+; X86-NEXT:retl
+;
+; X64-LABEL: f1:
+; X64:   # %bb.0:
+; X64-NEXT:mulsd {{\.?LCPI[0-9]+_[0-9]+}}(%rip), %xmm0
+; X64-NEXT:retq
+  %1 = fadd fast double %a, %a
+  %2 = fadd fast double %a, %a
+  %3 = fadd fast double %1, %2
+  ret double %3
+}
+
+define double @f2(double %a) {
+; X86-LABEL: f2:
+; X86:   # %bb.0:
+; X86-NEXT:pushl %ebp
+; X86-NEXT:.cfi_def_cfa_offset 8
+; X86-NEXT:.cfi_offset %ebp, -8
+; X86-NEXT:movl %esp, %ebp
+; X86-NEXT:.cfi_def_cfa_register %ebp
+; X86-NEXT:andl $-8, %esp
+; X86-NEXT:subl $8, %esp
+; X86-NEXT:movsd {{.*#+}} xmm0 = mem[0],zero
+; X86-NEXT:addsd %xmm0, %xmm0
+; X86-NEXT:movapd %xmm0, %xmm1
+; X86-NEXT:#ARITH_FENCE
+; X86-NEXT:addsd %xmm0, %xmm1
+; X86-NEXT:movsd %xmm1, (%esp)
+; X86-NEXT:fldl (%esp)
+; X86-NEXT:movl %ebp, %esp
+; X86-NEXT:popl %ebp
+; X86-NEXT:.cfi_def_cfa %esp, 4
+; X86-NEXT:retl
+;
+; X64-LABEL: f2:
+; X64:   # %bb.0:
+; X64-NEXT:addsd %xmm0, %xmm0
+; X64-NEXT:movapd %xmm0, %xmm1
+; X64-NEXT:#ARITH_FENCE
+; X64-NEXT:addsd %xmm0, %xmm1
+; X64-NEXT:movapd %xmm1, %xmm0
+; X64-NEXT:retq
+  %1 = fadd fast double %a, %a
+  %t = call double @llvm.arithmetic.fence.f64(double %1)
+  %2 = fadd fast double %a, %a
+  %3 = fadd fast double %t, %2
+  ret double %3
+}
+
+define <2 x float> @f3(<2 x float> %a) {
+; X86-LABEL: f3:
+; X86:   # %bb.0:
+; X86-NEXT:mulps {{\.?LCPI[0-9]+_[0-9]+}}, %xmm0
+; X86-NEXT:retl
+;
+; X64-LABEL: f3:
+; X64:   # %bb.0:
+; X64-NEXT:mulps {{\.?LCPI[0-9]+_[0-9]+}}(%rip), %xmm0
+; X64-NEXT:retq
+  %1 = fadd fast <2 x float> %a, %a
+  %2 = fadd fast <2 x float> %a, %a
+  %3 = fadd fast <2 x float> %1, %2
+  ret <2 x float> %3
+}
+
+define <2 x float> @f4(<2 x float> %a) {
+; X86-LABEL: f4:
+; X86:   # %bb.0:
+; X86-NEXT:addps %xmm0, %xmm0
+; X86-NEXT:movaps %xmm0, %xmm1
+; X86-NEXT:#ARITH_FENCE
+; X86-NEXT:addps %xmm0, %xmm1
+; X86-NEXT:movaps %xmm1, %xmm0
+; X86-NEXT:retl
+;
+; X64-LABEL: f4:
+; X64:   # %bb.0:
+; X64-NEXT:addps %xmm0, %xmm0
+; X64-NEXT:movaps %xmm0, %xmm1
+; X64-NEXT:#ARITH_FENCE
+; X64-NEXT:addps %xmm0, %xmm1
+; X64-NEXT:movaps %xmm1, %xmm0
+; X64-NEXT:retq
+  %1 = fadd fast <2 x float> %a, %a
+  %t = call <2 x float> @llvm.arithmetic.fence.v2f32(<2 x float> %1)
+  %2 = fadd fast <2 x float> %a, %a
+  %3 = fadd fast <2 x float> %t, %2
+  ret <2 x float> %3
+}
+
+define <8 x float> @f5(<8 x float> %a) {
+; X86-LABEL: f5:
+; X86:   # %bb.0:
+; X86-NEXT:movaps {{.*#+}} xmm2 = [4.0E+0,4.0E+0,4.0E+0,4.0E+0]
+; X86-NEXT:mulps %xmm2, %xmm0
+; X86-NEXT:mulps %xmm2, %xmm1
+; X86-NEXT:retl
+;
+; X64-LABEL: f5:
+; X64:   # %bb.0:
+; X64-NEXT:movaps {{.*#+}} xmm2 = [4.0E+0,4.0E+0,4.0E+0,4.0E+0]
+; X64-NEXT:mulps %xmm2, %xmm0
+; X64-NEXT:mulps 

[PATCH] D102094: [AIX][PowerPC] Remove error when specifying mabi=vec-default on AIX

2021-06-22 Thread Zarko Todorovski via Phabricator via cfe-commits
ZarkoCA updated this revision to Diff 353721.
ZarkoCA marked an inline comment as done.
ZarkoCA added a comment.

Addressed comments:

- Removed redundant `elseif` and CHECK


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102094

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/altivec.c
  clang/test/Driver/aix-vec-extabi.c
  clang/test/Preprocessor/aix-vec_extabi.c

Index: clang/test/Preprocessor/aix-vec_extabi.c
===
--- clang/test/Preprocessor/aix-vec_extabi.c
+++ clang/test/Preprocessor/aix-vec_extabi.c
@@ -2,11 +2,11 @@
 // RUN:   | FileCheck %s -check-prefix=EXTABI
 // RUN: %clang  -target powerpc64-ibm-aix-xcoff -mcpu=pwr8 -E -dM -maltivec -mabi=vec-extabi %s -o - 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=EXTABI
-// RUN: not %clang  -target powerpc-ibm-aix-xcoff -mcpu=pwr8 -E -dM -maltivec -mabi=vec-default %s 2>&1 \
+// RUN: %clang  -target powerpc-ibm-aix-xcoff -mcpu=pwr8 -E -dM -maltivec -mabi=vec-default %s 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=DFLTABI
-// RUN: not %clang -target powerpc64-ibm-aix-xcoff -mcpu=pwr8 -E -dM -maltivec -mabi=vec-default %s 2>&1 \
+// RUN: %clang -target powerpc64-ibm-aix-xcoff -mcpu=pwr8 -E -dM -maltivec -mabi=vec-default %s 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=DFLTABI
 
 
-// EXTABI:  #define __EXTABI__
-// DFLTABI: The default Altivec ABI on AIX is not yet supported, use '-mabi=vec-extabi' for the extended Altivec ABI
+// EXTABI:  #define __EXTABI__
+// DFLTABI-NOT: #define __EXTABI__
Index: clang/test/Driver/aix-vec-extabi.c
===
--- clang/test/Driver/aix-vec-extabi.c
+++ clang/test/Driver/aix-vec-extabi.c
@@ -1,10 +1,10 @@
 // RUN:  %clang -### -target powerpc-unknown-aix -S -maltivec -mabi=vec-extabi %s 2>&1 | \
-// RUN:  FileCheck %s
-
-// CHECK: "-cc1"
-// CHECK-SAME: "-mabi=vec-extabi"
-
+// RUN:  FileCheck %s --check-prefix=EXTABI
 // RUN:  %clang -### -target powerpc-unknown-aix -S -maltivec -mabi=vec-default %s 2>&1 | \
-// RUN:  FileCheck %s --check-prefix=ERROR
+// RUN:  FileCheck %s --check-prefix=DFLTABI
+
+// EXTABI:   "-cc1"
+// EXTABI-SAME:  "-mabi=vec-extabi"
 
-// ERROR: The default Altivec ABI on AIX is not yet supported, use '-mabi=vec-extabi' for the extended Altivec ABI
+// DFLTABI:  "-cc1"
+// DFLTABI-SAME: "-mabi=vec-default"
Index: clang/test/CodeGen/altivec.c
===
--- clang/test/CodeGen/altivec.c
+++ clang/test/CodeGen/altivec.c
@@ -4,12 +4,12 @@
 // RUN: %clang_cc1 -target-feature +altivec -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-LE
 // RUN: %clang_cc1 -target-feature +altivec -mabi=vec-extabi -target-cpu pwr8 -triple powerpc-unknown-aix -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-BE
 // RUN: %clang_cc1 -target-feature +altivec -mabi=vec-extabi -target-cpu pwr8 -triple powerpc64-unknown-aix -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-BE
-// RUN: not %clang_cc1 -target-feature +altivec -mabi=vec-default -target-cpu pwr8 -triple powerpc-unknown-aix -emit-llvm %s 2>&1 | FileCheck %s --check-prefix=AIX-ERROR
-// RUN: not %clang_cc1 -target-feature +altivec -mabi=vec-default -target-cpu pwr8 -triple powerpc64-unknown-aix -emit-llvm %s 2>&1 | FileCheck %s --check-prefix=AIX-ERROR
-// RUN: %clang -S -emit-llvm -maltivec -mabi=vec-extabi -mcpu=pwr8 -target powerpc-unknown-aix %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-BE
-// RUN: %clang -S -emit-llvm -maltivec -mabi=vec-extabi -mcpu=pwr8 -target powerpc64-unknown-aix %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-BE
-// RUN: not %clang -S -emit-llvm -maltivec -mabi=vec-default -mcpu=pwr8 -triple powerpc-unknown-aix -emit-llvm %s 2>&1 | FileCheck %s --check-prefix=AIX-ERROR
-// RUN: not %clang -S -emit-llvm -maltivec -mabi=vec-default -mcpu=pwr8 -triple powerpc64-unknown-aix -emit-llvm %s 2>&1 | FileCheck %s --check-prefix=AIX-ERROR
+// RUN: %clang_cc1 -target-feature +altivec -mabi=vec-default -target-cpu pwr8 -triple powerpc-unknown-aix -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-BE
+// RUN: %clang_cc1 -target-feature +altivec -mabi=vec-default -target-cpu pwr8 -triple powerpc64-unknown-aix -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-BE
+// RUN: %clang -S -emit-llvm -maltivec -mabi=vec-extabi -mcpu=pwr8 --target=powerpc-unknown-aix %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-BE
+// RUN: %clang -S -emit-llvm -maltivec -mabi=vec-extabi -mcpu=pwr8 --target=powerpc64-unknown-aix %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-BE
+// RUN: %clang -S -emit-llvm -maltivec -mabi=vec-default -mcpu=pwr8 --target=powerpc-unknown-ai

[PATCH] D104729: [clang][PATCH][nfc] Refactor TargetInfo::adjust to pass DiagnosticsEngine to allow diagnostics on target-unsupported options

2021-06-22 Thread Melanie Blower via Phabricator via cfe-commits
mibintc created this revision.
mibintc added a reviewer: aaron.ballman.
mibintc added a project: clang.
Herald added subscribers: kerbowa, kbarton, jgravelle-google, sbc100, nhaehnle, 
jvesely, nemanjai, dschuff.
mibintc requested review of this revision.
Herald added a subscriber: aheejin.

In the clang patch https://reviews.llvm.org/D100118 @aaron.ballman suggested 
that I pull out these changes into a precursor patch


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D104729

Files:
  clang/include/clang/Basic/TargetInfo.h
  clang/lib/Basic/TargetInfo.cpp
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Basic/Targets/AMDGPU.h
  clang/lib/Basic/Targets/PPC.cpp
  clang/lib/Basic/Targets/PPC.h
  clang/lib/Basic/Targets/SPIR.h
  clang/lib/Basic/Targets/WebAssembly.cpp
  clang/lib/Basic/Targets/WebAssembly.h
  clang/lib/Frontend/ASTUnit.cpp
  clang/lib/Frontend/CompilerInstance.cpp
  clang/lib/Interpreter/Interpreter.cpp
  clang/tools/clang-import-test/clang-import-test.cpp

Index: clang/tools/clang-import-test/clang-import-test.cpp
===
--- clang/tools/clang-import-test/clang-import-test.cpp
+++ clang/tools/clang-import-test/clang-import-test.cpp
@@ -208,7 +208,7 @@
   TargetInfo *TI = TargetInfo::CreateTargetInfo(
   Ins->getDiagnostics(), Ins->getInvocation().TargetOpts);
   Ins->setTarget(TI);
-  Ins->getTarget().adjust(Ins->getLangOpts());
+  Ins->getTarget().adjust(Ins->getDiagnostics(), Ins->getLangOpts());
   Ins->createFileManager();
   Ins->createSourceManager(Ins->getFileManager());
   Ins->createPreprocessor(TU_Complete);
Index: clang/lib/Interpreter/Interpreter.cpp
===
--- clang/lib/Interpreter/Interpreter.cpp
+++ clang/lib/Interpreter/Interpreter.cpp
@@ -110,7 +110,7 @@
"Initialization failed. "
"Target is missing");
 
-  Clang->getTarget().adjust(Clang->getLangOpts());
+  Clang->getTarget().adjust(Clang->getDiagnostics(), Clang->getLangOpts());
 
   return std::move(Clang);
 }
Index: clang/lib/Frontend/CompilerInstance.cpp
===
--- clang/lib/Frontend/CompilerInstance.cpp
+++ clang/lib/Frontend/CompilerInstance.cpp
@@ -142,7 +142,7 @@
   // Inform the target of the language options.
   // FIXME: We shouldn't need to do this, the target should be immutable once
   // created. This complexity should be lifted elsewhere.
-  getTarget().adjust(getLangOpts());
+  getTarget().adjust(getDiagnostics(), getLangOpts());
 
   // Adjust target options based on codegen options.
   getTarget().adjustTargetOptions(getCodeGenOpts(), getTargetOpts());
@@ -457,7 +457,7 @@
   getSourceManager(), *HeaderInfo, *this,
   /*IdentifierInfoLookup=*/nullptr,
   /*OwnsHeaderSearch=*/true, TUKind);
-  getTarget().adjust(getLangOpts());
+  getTarget().adjust(getDiagnostics(), getLangOpts());
   PP->Initialize(getTarget(), getAuxTarget());
 
   if (PPOpts.DetailedRecord)
Index: clang/lib/Frontend/ASTUnit.cpp
===
--- clang/lib/Frontend/ASTUnit.cpp
+++ clang/lib/Frontend/ASTUnit.cpp
@@ -588,7 +588,7 @@
 //
 // FIXME: We shouldn't need to do this, the target should be immutable once
 // created. This complexity should be lifted elsewhere.
-Target->adjust(LangOpt);
+Target->adjust(PP.getDiagnostics(), LangOpt);
 
 // Initialize the preprocessor.
 PP.Initialize(*Target);
Index: clang/lib/Basic/Targets/WebAssembly.h
===
--- clang/lib/Basic/Targets/WebAssembly.h
+++ clang/lib/Basic/Targets/WebAssembly.h
@@ -138,7 +138,7 @@
 
   bool hasProtectedVisibility() const override { return false; }
 
-  void adjust(LangOptions &Opts) override;
+  void adjust(DiagnosticsEngine &Diags, LangOptions &Opts) override;
 };
 
 class LLVM_LIBRARY_VISIBILITY WebAssembly32TargetInfo
Index: clang/lib/Basic/Targets/WebAssembly.cpp
===
--- clang/lib/Basic/Targets/WebAssembly.cpp
+++ clang/lib/Basic/Targets/WebAssembly.cpp
@@ -234,7 +234,8 @@
  Builtin::FirstTSBuiltin);
 }
 
-void WebAssemblyTargetInfo::adjust(LangOptions &Opts) {
+void WebAssemblyTargetInfo::adjust(DiagnosticsEngine &Diags,
+   LangOptions &Opts) {
   // If the Atomics feature isn't available, turn off POSIXThreads and
   // ThreadModel, so that we don't predefine _REENTRANT or __STDCPP_THREADS__.
   if (!HasAtomics) {
Index: clang/lib/Basic/Targets/SPIR.h
===
--- clang/lib/Basic/Targets/SPIR.h
+++ clang/lib/Basic/Targets/SPIR.h
@@ -135,8 +135,8 @@
   

[PATCH] D102094: [AIX][PowerPC] Remove error when specifying mabi=vec-default on AIX

2021-06-22 Thread Zarko Todorovski via Phabricator via cfe-commits
ZarkoCA marked 2 inline comments as done.
ZarkoCA added inline comments.



Comment at: clang/lib/Driver/ToolChains/Clang.cpp:4779
   CmdArgs.push_back("-mabi=vec-extabi");
+else if (A->getOption().getID() == options::OPT_mabi_EQ_vec_default)
+  CmdArgs.push_back("-mabi=vec-default");

jsji wrote:
> Why we need to check this if the default is to set it to `-mabi=vec-default` 
> in below else?
I think my reasoning was to map `-mabi=vec-default` to something specific but 
we don't need it. 



Comment at: clang/test/Driver/aix-vec-extabi.c:11
+// DFLTABI-SAME: "-mabi=vec-default"
+// DFLTABI-NOT:  "-mabi=vec-default"

jsji wrote:
> Why we need to explicitly `DFLTABI-NOT:  "-mabi=vec-default"`
It's not required, removed. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102094

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


[PATCH] D104616: [analyzer][WIP] Model comparision methods of std::unique_ptr

2021-06-22 Thread Valeriy Savchenko via Phabricator via cfe-commits
vsavchenko added a comment.

Looks like a solid start!




Comment at: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp:301
+
+  bool addTransition = false;
+  ProgramStateRef State = C.getState();

nit: variable names should be capitalized



Comment at: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp:321-323
+State =
+State->assume(llvm::dyn_cast(RetVal), true);
+addTransition = true;

Another idea here.
Instead of repeating:
```
State = State->assume(llvm::dyn_cast(RetVal), VALUE);
addTransition = true;
```
and having boolean `addTransition`, you can have `Optional CompResult` 
and do:
```
CompResult = VALUE;
```
And do the actual assumption at the bottom section when `CompResult.hasValue()`



Comment at: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp:334
+  default:
+assert(false && "shouldn't reach here");
+  }

nit: `llvm_unreachable` instead of `assert(false)`



Comment at: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp:345-364
+  if (FirstPtr && !SecondPtr &&
+  State->assume(llvm::dyn_cast(*FirstPtr),
+false)) {
+// FirstPtr is null, SecondPtr is unknown
+if (OOK == OO_LessEqual) {
+  State =
+  State->assume(llvm::dyn_cast(RetVal), 
true);

These are also symmetrical.



Comment at: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp:373-391
+  switch (OOK) {
+  case OO_Equal:
+  case OO_GreaterEqual:
+  case OO_LessEqual:
+State = State->assume(llvm::dyn_cast(RetVal),
+  true);
+addTransition = true;

This switch exactly repeats the previous switch.



Comment at: clang/lib/StaticAnalyzer/Checkers/SmartPtrModeling.cpp:394-436
+if (FirstNull && !SecondNull) {
+  switch (OOK) {
+  case OO_Less:
+  case OO_LessEqual:
+State = State->assume(llvm::dyn_cast(RetVal),
+  true);
+addTransition = true;

These are symmetrical, is there a way to implement it without this boilerplate?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104616

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


[clang] 9480162 - Improve clang -Wframe-larger-than= diagnostic

2021-06-22 Thread Fangrui Song via cfe-commits

Author: Fangrui Song
Date: 2021-06-22T11:20:49-07:00
New Revision: 948016228fdfb647ad7bcc978fde173504e3df82

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

LOG: Improve clang -Wframe-larger-than= diagnostic

Match the style in D104667.

This commit is for non-LTO diagnostics, while D104667 is for LTO and llc 
diagnostics.

Added: 


Modified: 
clang/include/clang/Basic/DiagnosticFrontendKinds.td
clang/lib/CodeGen/CodeGenAction.cpp
clang/test/Frontend/backend-diagnostic.c
clang/test/Misc/backend-stack-frame-diagnostics-fallback.cpp
clang/test/Misc/backend-stack-frame-diagnostics.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticFrontendKinds.td 
b/clang/include/clang/Basic/DiagnosticFrontendKinds.td
index e68058dd19b5b..0f4ccec385506 100644
--- a/clang/include/clang/Basic/DiagnosticFrontendKinds.td
+++ b/clang/include/clang/Basic/DiagnosticFrontendKinds.td
@@ -25,7 +25,7 @@ def note_fe_source_mgr : Note<"%0">, CatSourceMgr;
 def err_fe_cannot_link_module : Error<"cannot link module '%0': %1">,
   DefaultFatal;
 
-def warn_fe_frame_larger_than : Warning<"stack frame size of %0 bytes in %q1">,
+def warn_fe_frame_larger_than : Warning<"stack frame size (%0) exceeds limit 
(%1) in %q2">,
 BackendInfo, InGroup;
 def warn_fe_backend_frame_larger_than: Warning<"%0">,
 BackendInfo, InGroup;

diff  --git a/clang/lib/CodeGen/CodeGenAction.cpp 
b/clang/lib/CodeGen/CodeGenAction.cpp
index 02dcea2865058..b30bd11edbadb 100644
--- a/clang/lib/CodeGen/CodeGenAction.cpp
+++ b/clang/lib/CodeGen/CodeGenAction.cpp
@@ -571,7 +571,9 @@ BackendConsumer::StackSizeDiagHandler(const 
llvm::DiagnosticInfoStackSize &D) {
 // FIXME: Shouldn't need to truncate to uint32_t
 Diags.Report(ND->getASTContext().getFullLoc(ND->getLocation()),
  diag::warn_fe_frame_larger_than)
-  << static_cast(D.getStackSize()) << 
Decl::castToDeclContext(ND);
+<< static_cast(D.getStackSize())
+<< static_cast(D.getStackLimit())
+<< Decl::castToDeclContext(ND);
 return true;
   }
 

diff  --git a/clang/test/Frontend/backend-diagnostic.c 
b/clang/test/Frontend/backend-diagnostic.c
index 01029d7f83d66..695158cdd186e 100644
--- a/clang/test/Frontend/backend-diagnostic.c
+++ b/clang/test/Frontend/backend-diagnostic.c
@@ -15,9 +15,9 @@
 
 extern void doIt(char *);
 
-// REGULAR: warning: stack frame size of {{[0-9]+}} bytes in function 
'stackSizeWarning'
-// PROMOTE: error: stack frame size of {{[0-9]+}} bytes in function 
'stackSizeWarning'
-// IGNORE-NOT: stack frame size of {{[0-9]+}} bytes in function 
'stackSizeWarning'
+// REGULAR: warning: stack frame size ([[#]]) exceeds limit ([[#]]) in 
function 'stackSizeWarning'
+// PROMOTE: error: stack frame size ([[#]]) exceeds limit ([[#]]) in function 
'stackSizeWarning'
+// IGNORE-NOT: stack frame size ([[#]]) exceeds limit ([[#]]) in function 
'stackSizeWarning'
 void stackSizeWarning() {
   char buffer[80];
   doIt(buffer);

diff  --git a/clang/test/Misc/backend-stack-frame-diagnostics-fallback.cpp 
b/clang/test/Misc/backend-stack-frame-diagnostics-fallback.cpp
index d28d54b0e8a2d..79c6ba9b23f6d 100644
--- a/clang/test/Misc/backend-stack-frame-diagnostics-fallback.cpp
+++ b/clang/test/Misc/backend-stack-frame-diagnostics-fallback.cpp
@@ -12,7 +12,7 @@ namespace frameSizeThunkWarning {
 virtual void f();
   };
 
-  // CHECK: warning: stack frame size of {{[0-9]+}} bytes in function 
'frameSizeThunkWarning::B::f'
+  // CHECK: warning: stack frame size ([[#]]) exceeds limit ([[#]]) in 
function 'frameSizeThunkWarning::B::f'
   // CHECK: warning: stack frame size ([[#]]) exceeds limit in function 
'_ZTv0_n12_N21frameSizeThunkWarning1B1fEv'
   void B::f() {
 volatile int x = 0; // Ensure there is stack usage.

diff  --git a/clang/test/Misc/backend-stack-frame-diagnostics.cpp 
b/clang/test/Misc/backend-stack-frame-diagnostics.cpp
index b02e7f4c471d5..f0ceac00ea357 100644
--- a/clang/test/Misc/backend-stack-frame-diagnostics.cpp
+++ b/clang/test/Misc/backend-stack-frame-diagnostics.cpp
@@ -26,7 +26,7 @@ void frameSizeWarning(int, int) {}
 
 void frameSizeWarning();
 
-void frameSizeWarning() { // expected-warning-re {{stack frame size of 
{{[0-9]+}} bytes in function 'frameSizeWarning'}}
+void frameSizeWarning() { // expected-warning-re {{stack frame size 
({{[0-9]+}}) exceeds limit ({{[0-9]+}}) in function 'frameSizeWarning'}}
   char buffer[80];
   doIt(buffer);
 }
@@ -45,7 +45,7 @@ void frameSizeWarningIgnored() {
 
 void frameSizeLocalClassWarning() {
   struct S {
-S() { // expected-warning-re {{stack frame size of {{[0-9]+}} bytes in 
function 'frameSizeLocalClassWarning()::S::S'}}
+S() { // expected-warning-re {{stack frame size ({{[0-9]+}}) exceeds limit 
({{[0-9]+}}

[PATCH] D104505: [HIP] Defer operator overloading errors

2021-06-22 Thread Yaxun Liu via Phabricator via cfe-commits
yaxunl added a comment.

In D104505#2833746 , @tra wrote:

> In D104505#2833271 , @yaxunl wrote:
>
>> Such host/device overloading resolution induced issue is not limited to 
>> device functions calling host functions.
>
> It does not change the fact that the code in the test above is invalid, 
> regardless of whether we compile it on the host or on the device.
>
>> It could also happen to host device functions calling host functions, which 
>> is less controversial for deferring.
>
> H/D functions are special, because their overloading is affected whether 
> compilation is done on the host or on the device side and we often can not 
> tell whether the diagnostic is appropriate until codegen.
>
> I still think that deferring diags for unambiguously invalid code is not a 
> good idea. The fact that NVCC can only diagnose such errors during 
> device-side compilation is not a good enough reason, IMO, to make clang 
> ignore real errors, even if we'd still end up eventually failing later, 
> during device-side compilation.
>
> @rsmith, @rjmccall  -- any thoughts?

We don't defer such diags by default. We only defer them under option 
-fgpu-defer-diags, which users have to specify explicitly.


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

https://reviews.llvm.org/D104505

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


[PATCH] D102094: [AIX][PowerPC] Remove error when specifying mabi=vec-default on AIX

2021-06-22 Thread Jinsong Ji via Phabricator via cfe-commits
jsji added inline comments.



Comment at: clang/test/Driver/aix-vec-extabi.c:3
+// RUN:  FileCheck %s --check-prefix=EXTABI
 // RUN:  %clang -### -target powerpc-unknown-aix -S -maltivec 
-mabi=vec-default %s 2>&1 | \
+// RUN:  FileCheck %s --check-prefix=DFLTABI

How about RUN line without `-mabi`? 
and without `-maltivec`?
and `-mabi=vec-extabi` without `-maltivec`?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102094

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


[PATCH] D104484: [clang] Add cc1 option for dumping layout for all complete types

2021-06-22 Thread Duncan P. N. Exon Smith via Phabricator via cfe-commits
dexonsmith accepted this revision.
dexonsmith 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/D104484/new/

https://reviews.llvm.org/D104484

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


[PATCH] D104082: [CodeGen] Don't create a fake FunctionDecl when generating block/block_byref copy/dispose helper functions

2021-06-22 Thread Akira Hatanaka via Phabricator via cfe-commits
ahatanak updated this revision to Diff 353729.
ahatanak marked 2 inline comments as done.
ahatanak added a comment.

Delete comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104082

Files:
  clang/lib/CodeGen/CGBlocks.cpp
  clang/test/CodeGenCXX/debug-info-blocks.cpp
  clang/test/CodeGenObjC/debug-info-block-helper.m
  clang/test/CodeGenObjC/debug-info-blocks.m

Index: clang/test/CodeGenObjC/debug-info-blocks.m
===
--- clang/test/CodeGenObjC/debug-info-blocks.m
+++ clang/test/CodeGenObjC/debug-info-blocks.m
@@ -25,9 +25,9 @@
 // CHECK: ret {{.*}}, !dbg ![[DESTROY_LINE]]
 
 // CHECK-DAG: [[DBG_LINE]] = !DILocation(line: 0, scope: ![[COPY_SP:[0-9]+]])
-// CHECK-DAG: [[COPY_SP]] = distinct !DISubprogram(name: "__copy_helper_block_
+// CHECK-DAG: [[COPY_SP]] = distinct !DISubprogram(linkageName: "__copy_helper_block_
 // CHECK-DAG: [[DESTROY_LINE]] = !DILocation(line: 0, scope: ![[DESTROY_SP:[0-9]+]])
-// CHECK-DAG: [[DESTROY_SP]] = distinct !DISubprogram(name: "__destroy_helper_block_
+// CHECK-DAG: [[DESTROY_SP]] = distinct !DISubprogram(linkageName: "__destroy_helper_block_
 typedef unsigned int NSUInteger;
 
 @protocol NSObject
Index: clang/test/CodeGenObjC/debug-info-block-helper.m
===
--- clang/test/CodeGenObjC/debug-info-block-helper.m
+++ clang/test/CodeGenObjC/debug-info-block-helper.m
@@ -2,7 +2,7 @@
 // RUN: %clang_cc1 -emit-llvm -fblocks -debug-info-kind=limited -triple x86_64-apple-darwin10 -fobjc-runtime=macosx-fragile-10.5 %s -o - | FileCheck %s
 extern void foo(void(^)(void));
 
-// CHECK: !DISubprogram(name: "__destroy_helper_block_8_32o40r48r"
+// CHECK: !DISubprogram(linkageName: "__destroy_helper_block_8_32o40r48r"
 
 @interface NSObject {
   struct objc_object *isa;
Index: clang/test/CodeGenCXX/debug-info-blocks.cpp
===
--- clang/test/CodeGenCXX/debug-info-blocks.cpp
+++ clang/test/CodeGenCXX/debug-info-blocks.cpp
@@ -12,9 +12,7 @@
   ^{ (void)a; };
 }
 
-// CHECK: !DISubprogram(name: "__Block_byref_object_copy_",
-// CHECK-SAME:  line: 11,
+// CHECK: !DISubprogram(linkageName: "__Block_byref_object_copy_",
 // CHECK-SAME:  DISPFlagLocalToUnit | DISPFlagDefinition
-// CHECK: !DISubprogram(name: "__Block_byref_object_dispose_",
-// CHECK-SAME:  line: 11,
+// CHECK: !DISubprogram(linkageName: "__Block_byref_object_dispose_",
 // CHECK-SAME:  DISPFlagLocalToUnit | DISPFlagDefinition
Index: clang/lib/CodeGen/CGBlocks.cpp
===
--- clang/lib/CodeGen/CGBlocks.cpp
+++ clang/lib/CodeGen/CGBlocks.cpp
@@ -1948,21 +1948,13 @@
   if (CGM.supportsCOMDAT())
 Fn->setComdat(CGM.getModule().getOrInsertComdat(FuncName));
 
-  IdentifierInfo *II = &C.Idents.get(FuncName);
-
   SmallVector ArgTys;
   ArgTys.push_back(C.VoidPtrTy);
   ArgTys.push_back(C.VoidPtrTy);
-  QualType FunctionTy = C.getFunctionType(ReturnTy, ArgTys, {});
 
-  FunctionDecl *FD = FunctionDecl::Create(
-  C, C.getTranslationUnitDecl(), SourceLocation(), SourceLocation(), II,
-  FunctionTy, nullptr, SC_Static, false, false);
   setBlockHelperAttributesVisibility(blockInfo.CapturesNonExternalType, Fn, FI,
  CGM);
-  // This is necessary to avoid inheriting the previous line number.
-  FD->setImplicit();
-  StartFunction(FD, ReturnTy, Fn, FI, args);
+  StartFunction(GlobalDecl(), ReturnTy, Fn, FI, args);
   auto AL = ApplyDebugLocation::CreateArtificial(*this);
 
   llvm::Type *structPtrTy = blockInfo.StructureType->getPointerTo();
@@ -2143,21 +2135,12 @@
   if (CGM.supportsCOMDAT())
 Fn->setComdat(CGM.getModule().getOrInsertComdat(FuncName));
 
-  IdentifierInfo *II = &C.Idents.get(FuncName);
-
   SmallVector ArgTys;
   ArgTys.push_back(C.VoidPtrTy);
-  QualType FunctionTy = C.getFunctionType(ReturnTy, ArgTys, {});
-
-  FunctionDecl *FD = FunctionDecl::Create(
-  C, C.getTranslationUnitDecl(), SourceLocation(), SourceLocation(), II,
-  FunctionTy, nullptr, SC_Static, false, false);
 
   setBlockHelperAttributesVisibility(blockInfo.CapturesNonExternalType, Fn, FI,
  CGM);
-  // This is necessary to avoid inheriting the previous line number.
-  FD->setImplicit();
-  StartFunction(FD, ReturnTy, Fn, FI, args);
+  StartFunction(GlobalDecl(), ReturnTy, Fn, FI, args);
   markAsIgnoreThreadCheckingAtRuntime(Fn);
 
   auto AL = ApplyDebugLocation::CreateArtificial(*this);
@@ -2395,21 +2378,13 @@
 llvm::Function::Create(LTy, llvm::GlobalValue::InternalLinkage,
"__Block_byref_object_copy_", &CGF.CGM.getModule());
 
-  IdentifierInfo *II
-= &Context.Idents.get("__Block_byref_object_copy_");
-
   SmallVector ArgTys;
   ArgTys.push_back(Context.VoidPt

[PATCH] D102730: [clang-format] Support custom If macros

2021-06-22 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks accepted this revision.
HazardyKnusperkeks added a comment.
This revision is now accepted and ready to land.

Seems to be okay for me.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102730

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


[clang] f4c06bc - [CodeGen] Don't create fake FunctionDecls when generating block/byref

2021-06-22 Thread Akira Hatanaka via cfe-commits

Author: Akira Hatanaka
Date: 2021-06-22T11:42:53-07:00
New Revision: f4c06bcb67a1eba13a7f164961586dddaf8ebd5f

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

LOG: [CodeGen] Don't create fake FunctionDecls when generating block/byref
copy/dispose helper functions

We found out that these fake functions would cause clang to crash if the
changes proposed in https://reviews.llvm.org/D98799 were made.

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

Added: 


Modified: 
clang/lib/CodeGen/CGBlocks.cpp
clang/test/CodeGenCXX/debug-info-blocks.cpp
clang/test/CodeGenObjC/debug-info-block-helper.m
clang/test/CodeGenObjC/debug-info-blocks.m

Removed: 




diff  --git a/clang/lib/CodeGen/CGBlocks.cpp b/clang/lib/CodeGen/CGBlocks.cpp
index 9956d125d514e..1326c26e60eb9 100644
--- a/clang/lib/CodeGen/CGBlocks.cpp
+++ b/clang/lib/CodeGen/CGBlocks.cpp
@@ -1948,21 +1948,13 @@ CodeGenFunction::GenerateCopyHelperFunction(const 
CGBlockInfo &blockInfo) {
   if (CGM.supportsCOMDAT())
 Fn->setComdat(CGM.getModule().getOrInsertComdat(FuncName));
 
-  IdentifierInfo *II = &C.Idents.get(FuncName);
-
   SmallVector ArgTys;
   ArgTys.push_back(C.VoidPtrTy);
   ArgTys.push_back(C.VoidPtrTy);
-  QualType FunctionTy = C.getFunctionType(ReturnTy, ArgTys, {});
 
-  FunctionDecl *FD = FunctionDecl::Create(
-  C, C.getTranslationUnitDecl(), SourceLocation(), SourceLocation(), II,
-  FunctionTy, nullptr, SC_Static, false, false);
   setBlockHelperAttributesVisibility(blockInfo.CapturesNonExternalType, Fn, FI,
  CGM);
-  // This is necessary to avoid inheriting the previous line number.
-  FD->setImplicit();
-  StartFunction(FD, ReturnTy, Fn, FI, args);
+  StartFunction(GlobalDecl(), ReturnTy, Fn, FI, args);
   auto AL = ApplyDebugLocation::CreateArtificial(*this);
 
   llvm::Type *structPtrTy = blockInfo.StructureType->getPointerTo();
@@ -2143,21 +2135,12 @@ CodeGenFunction::GenerateDestroyHelperFunction(const 
CGBlockInfo &blockInfo) {
   if (CGM.supportsCOMDAT())
 Fn->setComdat(CGM.getModule().getOrInsertComdat(FuncName));
 
-  IdentifierInfo *II = &C.Idents.get(FuncName);
-
   SmallVector ArgTys;
   ArgTys.push_back(C.VoidPtrTy);
-  QualType FunctionTy = C.getFunctionType(ReturnTy, ArgTys, {});
-
-  FunctionDecl *FD = FunctionDecl::Create(
-  C, C.getTranslationUnitDecl(), SourceLocation(), SourceLocation(), II,
-  FunctionTy, nullptr, SC_Static, false, false);
 
   setBlockHelperAttributesVisibility(blockInfo.CapturesNonExternalType, Fn, FI,
  CGM);
-  // This is necessary to avoid inheriting the previous line number.
-  FD->setImplicit();
-  StartFunction(FD, ReturnTy, Fn, FI, args);
+  StartFunction(GlobalDecl(), ReturnTy, Fn, FI, args);
   markAsIgnoreThreadCheckingAtRuntime(Fn);
 
   auto AL = ApplyDebugLocation::CreateArtificial(*this);
@@ -2395,21 +2378,13 @@ generateByrefCopyHelper(CodeGenFunction &CGF, const 
BlockByrefInfo &byrefInfo,
 llvm::Function::Create(LTy, llvm::GlobalValue::InternalLinkage,
"__Block_byref_object_copy_", &CGF.CGM.getModule());
 
-  IdentifierInfo *II
-= &Context.Idents.get("__Block_byref_object_copy_");
-
   SmallVector ArgTys;
   ArgTys.push_back(Context.VoidPtrTy);
   ArgTys.push_back(Context.VoidPtrTy);
-  QualType FunctionTy = Context.getFunctionType(ReturnTy, ArgTys, {});
-
-  FunctionDecl *FD = FunctionDecl::Create(
-  Context, Context.getTranslationUnitDecl(), SourceLocation(),
-  SourceLocation(), II, FunctionTy, nullptr, SC_Static, false, false);
 
   CGF.CGM.SetInternalFunctionAttributes(GlobalDecl(), Fn, FI);
 
-  CGF.StartFunction(FD, ReturnTy, Fn, FI, args);
+  CGF.StartFunction(GlobalDecl(), ReturnTy, Fn, FI, args);
 
   if (generator.needsCopy()) {
 llvm::Type *byrefPtrType = byrefInfo.Type->getPointerTo(0);
@@ -2471,20 +2446,12 @@ generateByrefDisposeHelper(CodeGenFunction &CGF,
"__Block_byref_object_dispose_",
&CGF.CGM.getModule());
 
-  IdentifierInfo *II
-= &Context.Idents.get("__Block_byref_object_dispose_");
-
   SmallVector ArgTys;
   ArgTys.push_back(Context.VoidPtrTy);
-  QualType FunctionTy = Context.getFunctionType(R, ArgTys, {});
-
-  FunctionDecl *FD = FunctionDecl::Create(
-  Context, Context.getTranslationUnitDecl(), SourceLocation(),
-  SourceLocation(), II, FunctionTy, nullptr, SC_Static, false, false);
 
   CGF.CGM.SetInternalFunctionAttributes(GlobalDecl(), Fn, FI);
 
-  CGF.StartFunction(FD, R, Fn, FI, args);
+  CGF.StartFunction(GlobalDecl(), R, Fn, FI, args);
 
   if (generator.needsDispose()) {
 Address addr = CGF.GetAddrOfLocalVar(&Src);

diff  --git a/clang/test/CodeGenCXX/debug-info-blocks.cpp 
b/clang/

[PATCH] D104082: [CodeGen] Don't create a fake FunctionDecl when generating block/block_byref copy/dispose helper functions

2021-06-22 Thread Akira Hatanaka 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 rGf4c06bcb67a1: [CodeGen] Don't create fake FunctionDecls 
when generating block/byref (authored by ahatanak).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104082

Files:
  clang/lib/CodeGen/CGBlocks.cpp
  clang/test/CodeGenCXX/debug-info-blocks.cpp
  clang/test/CodeGenObjC/debug-info-block-helper.m
  clang/test/CodeGenObjC/debug-info-blocks.m

Index: clang/test/CodeGenObjC/debug-info-blocks.m
===
--- clang/test/CodeGenObjC/debug-info-blocks.m
+++ clang/test/CodeGenObjC/debug-info-blocks.m
@@ -25,9 +25,9 @@
 // CHECK: ret {{.*}}, !dbg ![[DESTROY_LINE]]
 
 // CHECK-DAG: [[DBG_LINE]] = !DILocation(line: 0, scope: ![[COPY_SP:[0-9]+]])
-// CHECK-DAG: [[COPY_SP]] = distinct !DISubprogram(name: "__copy_helper_block_
+// CHECK-DAG: [[COPY_SP]] = distinct !DISubprogram(linkageName: "__copy_helper_block_
 // CHECK-DAG: [[DESTROY_LINE]] = !DILocation(line: 0, scope: ![[DESTROY_SP:[0-9]+]])
-// CHECK-DAG: [[DESTROY_SP]] = distinct !DISubprogram(name: "__destroy_helper_block_
+// CHECK-DAG: [[DESTROY_SP]] = distinct !DISubprogram(linkageName: "__destroy_helper_block_
 typedef unsigned int NSUInteger;
 
 @protocol NSObject
Index: clang/test/CodeGenObjC/debug-info-block-helper.m
===
--- clang/test/CodeGenObjC/debug-info-block-helper.m
+++ clang/test/CodeGenObjC/debug-info-block-helper.m
@@ -2,7 +2,7 @@
 // RUN: %clang_cc1 -emit-llvm -fblocks -debug-info-kind=limited -triple x86_64-apple-darwin10 -fobjc-runtime=macosx-fragile-10.5 %s -o - | FileCheck %s
 extern void foo(void(^)(void));
 
-// CHECK: !DISubprogram(name: "__destroy_helper_block_8_32o40r48r"
+// CHECK: !DISubprogram(linkageName: "__destroy_helper_block_8_32o40r48r"
 
 @interface NSObject {
   struct objc_object *isa;
Index: clang/test/CodeGenCXX/debug-info-blocks.cpp
===
--- clang/test/CodeGenCXX/debug-info-blocks.cpp
+++ clang/test/CodeGenCXX/debug-info-blocks.cpp
@@ -12,9 +12,7 @@
   ^{ (void)a; };
 }
 
-// CHECK: !DISubprogram(name: "__Block_byref_object_copy_",
-// CHECK-SAME:  line: 11,
+// CHECK: !DISubprogram(linkageName: "__Block_byref_object_copy_",
 // CHECK-SAME:  DISPFlagLocalToUnit | DISPFlagDefinition
-// CHECK: !DISubprogram(name: "__Block_byref_object_dispose_",
-// CHECK-SAME:  line: 11,
+// CHECK: !DISubprogram(linkageName: "__Block_byref_object_dispose_",
 // CHECK-SAME:  DISPFlagLocalToUnit | DISPFlagDefinition
Index: clang/lib/CodeGen/CGBlocks.cpp
===
--- clang/lib/CodeGen/CGBlocks.cpp
+++ clang/lib/CodeGen/CGBlocks.cpp
@@ -1948,21 +1948,13 @@
   if (CGM.supportsCOMDAT())
 Fn->setComdat(CGM.getModule().getOrInsertComdat(FuncName));
 
-  IdentifierInfo *II = &C.Idents.get(FuncName);
-
   SmallVector ArgTys;
   ArgTys.push_back(C.VoidPtrTy);
   ArgTys.push_back(C.VoidPtrTy);
-  QualType FunctionTy = C.getFunctionType(ReturnTy, ArgTys, {});
 
-  FunctionDecl *FD = FunctionDecl::Create(
-  C, C.getTranslationUnitDecl(), SourceLocation(), SourceLocation(), II,
-  FunctionTy, nullptr, SC_Static, false, false);
   setBlockHelperAttributesVisibility(blockInfo.CapturesNonExternalType, Fn, FI,
  CGM);
-  // This is necessary to avoid inheriting the previous line number.
-  FD->setImplicit();
-  StartFunction(FD, ReturnTy, Fn, FI, args);
+  StartFunction(GlobalDecl(), ReturnTy, Fn, FI, args);
   auto AL = ApplyDebugLocation::CreateArtificial(*this);
 
   llvm::Type *structPtrTy = blockInfo.StructureType->getPointerTo();
@@ -2143,21 +2135,12 @@
   if (CGM.supportsCOMDAT())
 Fn->setComdat(CGM.getModule().getOrInsertComdat(FuncName));
 
-  IdentifierInfo *II = &C.Idents.get(FuncName);
-
   SmallVector ArgTys;
   ArgTys.push_back(C.VoidPtrTy);
-  QualType FunctionTy = C.getFunctionType(ReturnTy, ArgTys, {});
-
-  FunctionDecl *FD = FunctionDecl::Create(
-  C, C.getTranslationUnitDecl(), SourceLocation(), SourceLocation(), II,
-  FunctionTy, nullptr, SC_Static, false, false);
 
   setBlockHelperAttributesVisibility(blockInfo.CapturesNonExternalType, Fn, FI,
  CGM);
-  // This is necessary to avoid inheriting the previous line number.
-  FD->setImplicit();
-  StartFunction(FD, ReturnTy, Fn, FI, args);
+  StartFunction(GlobalDecl(), ReturnTy, Fn, FI, args);
   markAsIgnoreThreadCheckingAtRuntime(Fn);
 
   auto AL = ApplyDebugLocation::CreateArtificial(*this);
@@ -2395,21 +2378,13 @@
 llvm::Function::Create(LTy, llvm::GlobalValue::InternalLinkage,
"__Block_byref_object_copy_", &CGF.CGM.getModule());
 
-  IdentifierInf

[PATCH] D104058: ThinLTO: Fix inline assembly references to static functions with CFI

2021-06-22 Thread Nico Weber via Phabricator via cfe-commits
thakis added a comment.

Looks like this breaks check-llvm on mac, see 
http://45.33.8.238/mac/32814/summary.html

Please take a look and revert for now if it takes a while to fix.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104058

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


[clang] bc768aa - [OpenMP] Remove OpenMP CUDA Target Parallel compiler flag

2021-06-22 Thread via cfe-commits

Author: Joseph Huber
Date: 2021-06-22T15:10:19-04:00
New Revision: bc768aac2e4ebc3613f1e5601b15f663a6385044

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

LOG: [OpenMP] Remove OpenMP CUDA Target Parallel compiler flag

Summary:
The changes introduced in D97680 turns this command line option into a no-op so
it can be removed entirely.

Reviewed By: tianshilei1992

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

Added: 


Modified: 
clang/include/clang/Basic/LangOptions.def
clang/include/clang/Driver/Options.td
clang/lib/Driver/ToolChains/Clang.cpp
clang/lib/Frontend/CompilerInvocation.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/LangOptions.def 
b/clang/include/clang/Basic/LangOptions.def
index fff5fe23dc80d..32429f019064d 100644
--- a/clang/include/clang/Basic/LangOptions.def
+++ b/clang/include/clang/Basic/LangOptions.def
@@ -237,7 +237,6 @@ LANGOPT(OpenMPCUDANumSMs  , 32, 0, "Number of SMs for CUDA 
devices.")
 LANGOPT(OpenMPCUDABlocksPerSM  , 32, 0, "Number of blocks per SM for CUDA 
devices.")
 LANGOPT(OpenMPCUDAReductionBufNum , 32, 1024, "Number of the reduction records 
in the intermediate reduction buffer used for the teams reductions.")
 LANGOPT(OpenMPOptimisticCollapse  , 1, 0, "Use at most 32 bits to represent 
the collapsed loop nest counter.")
-LANGOPT(OpenMPCUDATargetParallel, 1, 0, "Support parallel execution of target 
region on Cuda-based devices.")
 LANGOPT(RenderScript  , 1, 0, "RenderScript")
 
 LANGOPT(CUDAIsDevice  , 1, 0, "compiling for CUDA device")

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index ede7405964ff3..016a565e77a57 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -2363,12 +2363,6 @@ def fopenmp_cuda_teams_reduction_recs_num_EQ : 
Joined<["-"], "fopenmp-cuda-teams
 defm openmp_optimistic_collapse : BoolFOption<"openmp-optimistic-collapse",
   LangOpts<"OpenMPOptimisticCollapse">, DefaultFalse,
   PosFlag, NegFlag, 
BothFlags<[NoArgumentUnused, HelpHidden]>>;
-def fopenmp_cuda_parallel_target_regions : Flag<["-"], 
"fopenmp-cuda-parallel-target-regions">, Group,
-  Flags<[CC1Option, NoArgumentUnused, HelpHidden]>,
-  HelpText<"Support parallel execution of target regions on Cuda-based 
devices.">;
-def fno_openmp_cuda_parallel_target_regions : Flag<["-"], 
"fno-openmp-cuda-parallel-target-regions">, Group,
-  Flags<[NoArgumentUnused, HelpHidden]>,
-  HelpText<"Support only serial execution of target regions on Cuda-based 
devices.">;
 def static_openmp: Flag<["-"], "static-openmp">,
   HelpText<"Use the static host OpenMP runtime while linking.">;
 def fno_optimize_sibling_calls : Flag<["-"], "fno-optimize-sibling-calls">, 
Group;

diff  --git a/clang/lib/Driver/ToolChains/Clang.cpp 
b/clang/lib/Driver/ToolChains/Clang.cpp
index f6e3447eccb02..eafe5de8eedb8 100644
--- a/clang/lib/Driver/ToolChains/Clang.cpp
+++ b/clang/lib/Driver/ToolChains/Clang.cpp
@@ -5714,13 +5714,6 @@ void Clang::ConstructJob(Compilation &C, const JobAction 
&JA,
options::OPT_fno_openmp_cuda_mode, /*Default=*/false))
 CmdArgs.push_back("-fopenmp-cuda-mode");
 
-  // When in OpenMP offloading mode with NVPTX target, forward
-  // cuda-parallel-target-regions flag
-  if (Args.hasFlag(options::OPT_fopenmp_cuda_parallel_target_regions,
-   options::OPT_fno_openmp_cuda_parallel_target_regions,
-   /*Default=*/true))
-CmdArgs.push_back("-fopenmp-cuda-parallel-target-regions");
-
   // When in OpenMP offloading mode with NVPTX target, check if full 
runtime
   // is required.
   if (Args.hasFlag(options::OPT_fopenmp_cuda_force_full_runtime,

diff  --git a/clang/lib/Frontend/CompilerInvocation.cpp 
b/clang/lib/Frontend/CompilerInvocation.cpp
index 54904443958ac..5bbb954c7d4d7 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -3475,9 +3475,6 @@ void CompilerInvocation::GenerateLangArgs(const 
LangOptions &Opts,
   if (Opts.OpenMPCUDAMode)
 GenerateArg(Args, OPT_fopenmp_cuda_mode, SA);
 
-  if (Opts.OpenMPCUDATargetParallel)
-GenerateArg(Args, OPT_fopenmp_cuda_parallel_target_regions, SA);
-
   if (Opts.OpenMPCUDAForceFullRuntime)
 GenerateArg(Args, OPT_fopenmp_cuda_force_full_runtime, SA);
 
@@ -3910,12 +3907,6 @@ bool CompilerInvocation::ParseLangArgs(LangOptions 
&Opts, ArgList &Args,
   Opts.OpenMPCUDAMode = Opts.OpenMPIsDevice && (T.isNVPTX() || T.isAMDGCN()) &&
 Args.hasArg(options::OPT_fopenmp_cuda_mode);
 
-  // Set CUDA support for parallel execution of target regions for OpenMP 
target
-  // NVPTX/AMDGCN if specified in options.
-  Opts.O

[PATCH] D102940: [OpenMP] Remove OpenMP CUDA Target Parallel compiler flag

2021-06-22 Thread Joseph Huber via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rGbc768aac2e4e: [OpenMP] Remove OpenMP CUDA Target Parallel 
compiler flag (authored by jhuber6).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102940

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp


Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -3475,9 +3475,6 @@
   if (Opts.OpenMPCUDAMode)
 GenerateArg(Args, OPT_fopenmp_cuda_mode, SA);
 
-  if (Opts.OpenMPCUDATargetParallel)
-GenerateArg(Args, OPT_fopenmp_cuda_parallel_target_regions, SA);
-
   if (Opts.OpenMPCUDAForceFullRuntime)
 GenerateArg(Args, OPT_fopenmp_cuda_force_full_runtime, SA);
 
@@ -3910,12 +3907,6 @@
   Opts.OpenMPCUDAMode = Opts.OpenMPIsDevice && (T.isNVPTX() || T.isAMDGCN()) &&
 Args.hasArg(options::OPT_fopenmp_cuda_mode);
 
-  // Set CUDA support for parallel execution of target regions for OpenMP 
target
-  // NVPTX/AMDGCN if specified in options.
-  Opts.OpenMPCUDATargetParallel =
-  Opts.OpenMPIsDevice && (T.isNVPTX() || T.isAMDGCN()) &&
-  Args.hasArg(options::OPT_fopenmp_cuda_parallel_target_regions);
-
   // Set CUDA mode for OpenMP target NVPTX/AMDGCN if specified in options
   Opts.OpenMPCUDAForceFullRuntime =
   Opts.OpenMPIsDevice && (T.isNVPTX() || T.isAMDGCN()) &&
Index: clang/lib/Driver/ToolChains/Clang.cpp
===
--- clang/lib/Driver/ToolChains/Clang.cpp
+++ clang/lib/Driver/ToolChains/Clang.cpp
@@ -5714,13 +5714,6 @@
options::OPT_fno_openmp_cuda_mode, /*Default=*/false))
 CmdArgs.push_back("-fopenmp-cuda-mode");
 
-  // When in OpenMP offloading mode with NVPTX target, forward
-  // cuda-parallel-target-regions flag
-  if (Args.hasFlag(options::OPT_fopenmp_cuda_parallel_target_regions,
-   options::OPT_fno_openmp_cuda_parallel_target_regions,
-   /*Default=*/true))
-CmdArgs.push_back("-fopenmp-cuda-parallel-target-regions");
-
   // When in OpenMP offloading mode with NVPTX target, check if full 
runtime
   // is required.
   if (Args.hasFlag(options::OPT_fopenmp_cuda_force_full_runtime,
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -2363,12 +2363,6 @@
 defm openmp_optimistic_collapse : BoolFOption<"openmp-optimistic-collapse",
   LangOpts<"OpenMPOptimisticCollapse">, DefaultFalse,
   PosFlag, NegFlag, 
BothFlags<[NoArgumentUnused, HelpHidden]>>;
-def fopenmp_cuda_parallel_target_regions : Flag<["-"], 
"fopenmp-cuda-parallel-target-regions">, Group,
-  Flags<[CC1Option, NoArgumentUnused, HelpHidden]>,
-  HelpText<"Support parallel execution of target regions on Cuda-based 
devices.">;
-def fno_openmp_cuda_parallel_target_regions : Flag<["-"], 
"fno-openmp-cuda-parallel-target-regions">, Group,
-  Flags<[NoArgumentUnused, HelpHidden]>,
-  HelpText<"Support only serial execution of target regions on Cuda-based 
devices.">;
 def static_openmp: Flag<["-"], "static-openmp">,
   HelpText<"Use the static host OpenMP runtime while linking.">;
 def fno_optimize_sibling_calls : Flag<["-"], "fno-optimize-sibling-calls">, 
Group;
Index: clang/include/clang/Basic/LangOptions.def
===
--- clang/include/clang/Basic/LangOptions.def
+++ clang/include/clang/Basic/LangOptions.def
@@ -237,7 +237,6 @@
 LANGOPT(OpenMPCUDABlocksPerSM  , 32, 0, "Number of blocks per SM for CUDA 
devices.")
 LANGOPT(OpenMPCUDAReductionBufNum , 32, 1024, "Number of the reduction records 
in the intermediate reduction buffer used for the teams reductions.")
 LANGOPT(OpenMPOptimisticCollapse  , 1, 0, "Use at most 32 bits to represent 
the collapsed loop nest counter.")
-LANGOPT(OpenMPCUDATargetParallel, 1, 0, "Support parallel execution of target 
region on Cuda-based devices.")
 LANGOPT(RenderScript  , 1, 0, "RenderScript")
 
 LANGOPT(CUDAIsDevice  , 1, 0, "compiling for CUDA device")


Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -3475,9 +3475,6 @@
   if (Opts.OpenMPCUDAMode)
 GenerateArg(Args, OPT_fopenmp_cuda_mode, SA);
 
-  if (Opts.OpenMPCUDATargetParallel)
-GenerateArg(Args, OPT_fopenmp_cuda_parallel_target_regions, SA);
-
   if (Opts.OpenMPCUDAForceFullRuntime)
 GenerateArg(Args, OPT_fopen

[PATCH] D104342: [IR] convert warn-stack-size from module flag to fn attr

2021-06-22 Thread Nick Desaulniers via Phabricator via cfe-commits
nickdesaulniers added a comment.

In D104342#2831738 , @dblaikie wrote:

>> In D104342#2831717 , @dblaikie 
>> wrote:
>>
>>> Probably worth at least writing up the risk/instability in the docs for the 
>>> warning (in clang) and attribute (in llvm). (don't mind if that's in this 
>>> patch or a follow-up).

I would think 
https://clang.llvm.org/docs/DiagnosticsReference.html#wframe-larger-than would 
be an appropriate place to document this for `-Wframe-larger-than=`, but it 
seems this whole page is generated via TableGen. It's not clear to me how we 
could insert such a note.

Langref changes: https://reviews.llvm.org/D104736.

> At least then we could probably say it's an ODR violation (the two function 
> definitions would be not the same if the user wrote the attribute differently 
> for two definitions of the inline function in two different translation 
> units) to have the function declared with different values for the attribute 
> within the same program (so you could still compile two different files (that 
> include a common header with a common function with the attribute specified 
> there) with different values for the command line flag - because the function 
> would get a consistent attribute value for the warning) - and then the linker 
> could actually reject it on mismatch. But with the attribute currently coming 
> from the command line, that's not feasible.




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104342

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


[PATCH] D104677: [OpenMP][AMDGCN] Apply fix for isnan, isinf and isfinite for amdgcn.

2021-06-22 Thread Jon Chesterfield via Phabricator via cfe-commits
JonChesterfield added a comment.

Looks like the __OPENMP_AMDGCN__ guard is sound to me, but can't really argue 
against having more tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104677

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


[PATCH] D102094: [AIX][PowerPC] Remove error when specifying mabi=vec-default on AIX

2021-06-22 Thread Zarko Todorovski via Phabricator via cfe-commits
ZarkoCA updated this revision to Diff 353748.
ZarkoCA marked 2 inline comments as done.
ZarkoCA added a comment.

- Updated test case


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102094

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/altivec.c
  clang/test/Driver/aix-vec-extabi.c
  clang/test/Preprocessor/aix-vec_extabi.c

Index: clang/test/Preprocessor/aix-vec_extabi.c
===
--- clang/test/Preprocessor/aix-vec_extabi.c
+++ clang/test/Preprocessor/aix-vec_extabi.c
@@ -2,11 +2,11 @@
 // RUN:   | FileCheck %s -check-prefix=EXTABI
 // RUN: %clang  -target powerpc64-ibm-aix-xcoff -mcpu=pwr8 -E -dM -maltivec -mabi=vec-extabi %s -o - 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=EXTABI
-// RUN: not %clang  -target powerpc-ibm-aix-xcoff -mcpu=pwr8 -E -dM -maltivec -mabi=vec-default %s 2>&1 \
+// RUN: %clang  -target powerpc-ibm-aix-xcoff -mcpu=pwr8 -E -dM -maltivec -mabi=vec-default %s 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=DFLTABI
-// RUN: not %clang -target powerpc64-ibm-aix-xcoff -mcpu=pwr8 -E -dM -maltivec -mabi=vec-default %s 2>&1 \
+// RUN: %clang -target powerpc64-ibm-aix-xcoff -mcpu=pwr8 -E -dM -maltivec -mabi=vec-default %s 2>&1 \
 // RUN:   | FileCheck %s -check-prefix=DFLTABI
 
 
-// EXTABI:  #define __EXTABI__
-// DFLTABI: The default Altivec ABI on AIX is not yet supported, use '-mabi=vec-extabi' for the extended Altivec ABI
+// EXTABI:  #define __EXTABI__
+// DFLTABI-NOT: #define __EXTABI__
Index: clang/test/Driver/aix-vec-extabi.c
===
--- clang/test/Driver/aix-vec-extabi.c
+++ clang/test/Driver/aix-vec-extabi.c
@@ -1,10 +1,18 @@
+// RUN:  %clang -### -target powerpc-unknown-aix -S %s 2>&1 | \
+// RUN:  FileCheck %s --check-prefix=NOEXTABI
+// RUN:  %clang -### -target powerpc-unknown-aix -S -maltivec %s 2>&1 | \
+// RUN:  FileCheck %s --check-prefix=NOEXTABI
+// RUN:  %clang -### -target powerpc-unknown-aix -S -maltivec -mabi=vec-default %s 2>&1 | \
+// RUN:  FileCheck %s --check-prefix=DFLTABI
+// RUN:  %clang -### -target powerpc-unknown-aix -S -mabi=vec-extabi %s 2>&1 | \
+// RUN:  FileCheck %s --check-prefix=EXTABI
 // RUN:  %clang -### -target powerpc-unknown-aix -S -maltivec -mabi=vec-extabi %s 2>&1 | \
-// RUN:  FileCheck %s
-
-// CHECK: "-cc1"
-// CHECK-SAME: "-mabi=vec-extabi"
+// RUN:  FileCheck %s --check-prefix=EXTABI
+/
+// NOEXTABI-NOT: "-mabi=vec-extabi"
 
-// RUN:  %clang -### -target powerpc-unknown-aix -S -maltivec -mabi=vec-default %s 2>&1 | \
-// RUN:  FileCheck %s --check-prefix=ERROR
+// EXTABI:   "-cc1"
+// EXTABI-SAME:  "-mabi=vec-extabi"
 
-// ERROR: The default Altivec ABI on AIX is not yet supported, use '-mabi=vec-extabi' for the extended Altivec ABI
+// DFLTABI:  "-cc1"
+// DFLTABI-SAME: "-mabi=vec-default"
Index: clang/test/CodeGen/altivec.c
===
--- clang/test/CodeGen/altivec.c
+++ clang/test/CodeGen/altivec.c
@@ -4,12 +4,12 @@
 // RUN: %clang_cc1 -target-feature +altivec -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-LE
 // RUN: %clang_cc1 -target-feature +altivec -mabi=vec-extabi -target-cpu pwr8 -triple powerpc-unknown-aix -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-BE
 // RUN: %clang_cc1 -target-feature +altivec -mabi=vec-extabi -target-cpu pwr8 -triple powerpc64-unknown-aix -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-BE
-// RUN: not %clang_cc1 -target-feature +altivec -mabi=vec-default -target-cpu pwr8 -triple powerpc-unknown-aix -emit-llvm %s 2>&1 | FileCheck %s --check-prefix=AIX-ERROR
-// RUN: not %clang_cc1 -target-feature +altivec -mabi=vec-default -target-cpu pwr8 -triple powerpc64-unknown-aix -emit-llvm %s 2>&1 | FileCheck %s --check-prefix=AIX-ERROR
-// RUN: %clang -S -emit-llvm -maltivec -mabi=vec-extabi -mcpu=pwr8 -target powerpc-unknown-aix %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-BE
-// RUN: %clang -S -emit-llvm -maltivec -mabi=vec-extabi -mcpu=pwr8 -target powerpc64-unknown-aix %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-BE
-// RUN: not %clang -S -emit-llvm -maltivec -mabi=vec-default -mcpu=pwr8 -triple powerpc-unknown-aix -emit-llvm %s 2>&1 | FileCheck %s --check-prefix=AIX-ERROR
-// RUN: not %clang -S -emit-llvm -maltivec -mabi=vec-default -mcpu=pwr8 -triple powerpc64-unknown-aix -emit-llvm %s 2>&1 | FileCheck %s --check-prefix=AIX-ERROR
+// RUN: %clang_cc1 -target-feature +altivec -mabi=vec-default -target-cpu pwr8 -triple powerpc-unknown-aix -emit-llvm %s -o - | FileCheck %s --check-prefixes=CHECK,CHECK-BE
+// RUN: %clang_cc1 -target-feature +altivec -mabi=vec-default -target-cpu pwr8 -triple powerpc64-unknown-aix -emit-llvm %s -o

[PATCH] D102094: [AIX][PowerPC] Remove error when specifying mabi=vec-default on AIX

2021-06-22 Thread Zarko Todorovski via Phabricator via cfe-commits
ZarkoCA added inline comments.



Comment at: clang/test/Driver/aix-vec-extabi.c:3
+// RUN:  FileCheck %s --check-prefix=EXTABI
 // RUN:  %clang -### -target powerpc-unknown-aix -S -maltivec 
-mabi=vec-default %s 2>&1 | \
+// RUN:  FileCheck %s --check-prefix=DFLTABI

jsji wrote:
> How about RUN line without `-mabi`? 
> and without `-maltivec`?
> and `-mabi=vec-extabi` without `-maltivec`?
Thanks, added those. Since `-mabi-vec-extabi` is a codegen option I think it 
makes sense to make sure it's not active when only `-maltivec` or nothing is 
specified on the command line. Does that work? 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102094

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


[PATCH] D102094: [AIX][PowerPC] Remove error when specifying mabi=vec-default on AIX

2021-06-22 Thread Jinsong Ji via Phabricator via cfe-commits
jsji accepted this revision as: jsji.
jsji added a comment.
This revision is now accepted and ready to land.

LGTM.




Comment at: clang/test/Driver/aix-vec-extabi.c:12
+/
+// NOEXTABI-NOT: "-mabi=vec-extabi"
 

Why not use `--implicit-check-not`?



Comment at: clang/test/Driver/aix-vec-extabi.c:3
+// RUN:  FileCheck %s --check-prefix=EXTABI
 // RUN:  %clang -### -target powerpc-unknown-aix -S -maltivec 
-mabi=vec-default %s 2>&1 | \
+// RUN:  FileCheck %s --check-prefix=DFLTABI

ZarkoCA wrote:
> jsji wrote:
> > How about RUN line without `-mabi`? 
> > and without `-maltivec`?
> > and `-mabi=vec-extabi` without `-maltivec`?
> Thanks, added those. Since `-mabi-vec-extabi` is a codegen option I think it 
> makes sense to make sure it's not active when only `-maltivec` or nothing is 
> specified on the command line. Does that work? 
I think you meant `-vec-extabi` option for llc? So maybe 
`--implicit-check-not=vec-extabi` should be better -- cover both mabi= and llc 
option.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102094

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


[clang] 64cf5eb - [clang-format] Add new LambdaBodyIndentation option

2021-06-22 Thread Björn Schäpers via cfe-commits

Author: Vitali Lovich
Date: 2021-06-22T21:46:16+02:00
New Revision: 64cf5eba06bd4f81954253b1e7a10be6fe92403e

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

LOG: [clang-format] Add new LambdaBodyIndentation option

Currently the lambda body indents relative to where the lambda signature is 
located. This instead lets the user
choose to align the lambda body relative to the parent scope that contains the 
lambda declaration. Thus:

someFunction([] {
  lambdaBody();
});

will always have the same indentation of the body even when the lambda 
signature goes on a new line:

someFunction(
[] {
  lambdaBody();
});

whereas before lambdaBody would be indented 6 spaces.

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

Added: 


Modified: 
clang/docs/ClangFormatStyleOptions.rst
clang/docs/ReleaseNotes.rst
clang/include/clang/Format/Format.h
clang/lib/Format/Format.cpp
clang/lib/Format/UnwrappedLineFormatter.cpp
clang/unittests/Format/FormatTest.cpp

Removed: 




diff  --git a/clang/docs/ClangFormatStyleOptions.rst 
b/clang/docs/ClangFormatStyleOptions.rst
index 0d0c07fa350f..f05e11469a7b 100644
--- a/clang/docs/ClangFormatStyleOptions.rst
+++ b/clang/docs/ClangFormatStyleOptions.rst
@@ -2841,6 +2841,42 @@ the configuration (without a prefix: ``Auto``).
bar();   }
  }
 
+**LambdaBodyIndentation** (``LambdaBodyIndentationKind``)
+  The indentation style of lambda bodies. ``Signature`` (the default)
+  causes the lambda body to be indented one additional level relative to
+  the indentation level of the signature. ``OuterScope`` forces the lambda
+  body to be indented one additional level relative to the parent scope
+  containing the lambda signature. For callback-heavy code, it may improve
+  readability to have the signature indented two levels and to use
+  ``OuterScope``. The KJ style guide requires ``OuterScope`.
+  `KJ style guide
+  `_
+
+  Possible values:
+
+  * ``LBI_Signature`` (in configuration: ``Signature``)
+Align lambda body relative to the lambda signature. This is the default.
+
+.. code-block:: c++
+
+   someMethod(
+   [](SomeReallyLongLambdaSignatureArgument foo) {
+ return;
+   });
+
+  * ``LBI_OuterScope`` (in configuration: ``OuterScope``)
+Align lambda body relative to the indentation level of the outer scope
+the lambda signature resides in.
+
+.. code-block:: c++
+
+   someMethod(
+   [](SomeReallyLongLambdaSignatureArgument foo) {
+ return;
+   });
+
+
+
 **Language** (``LanguageKind``)
   Language, this format style is targeted at.
 

diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index bddaea6e4846..4b432c1f3bb8 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -259,6 +259,12 @@ clang-format
 - Option ``BreakInheritanceList`` gets a new style, ``AfterComma``. It breaks
   only after the commas that separate the base-specifiers.
 
+- Option ``LambdaBodyIndentation`` has been added to control how the body of a
+  lambda is indented. The default ``Signature`` value indents the body one 
level
+  relative to whatever indentation the signature has. ``OuterScope`` lets you
+  change that so that the lambda body is indented one level relative to the 
scope
+  containing the lambda, regardless of where the lambda signature was placed.
+
 - ``git-clang-format`` no longer formats changes to symbolic links. (Fixes
   https://llvm.org/PR46992.)
 

diff  --git a/clang/include/clang/Format/Format.h 
b/clang/include/clang/Format/Format.h
index 164765ca1a1a..d51666fe9a1b 100644
--- a/clang/include/clang/Format/Format.h
+++ b/clang/include/clang/Format/Format.h
@@ -2490,6 +2490,38 @@ struct FormatStyle {
   /// Language, this format style is targeted at.
   LanguageKind Language;
 
+  /// Indentation logic for lambda bodies.
+  enum LambdaBodyIndentationKind : unsigned char {
+/// Align lambda body relative to the lambda signature. This is the 
default.
+/// \code
+///someMethod(
+///[](SomeReallyLongLambdaSignatureArgument foo) {
+///  return;
+///});
+/// \endcode
+LBI_Signature,
+/// Align lambda body relative to the indentation level of the outer scope
+/// the lambda signature resides in.
+/// \code
+///someMethod(
+///[](SomeReallyLongLambdaSignatureArgument foo) {
+///  return;
+///});
+/// \endcode
+LBI_OuterScope,
+  };
+
+  /// The indentation style of lambda bodies. ``Signature`` (the default)
+  /// causes the lambda body to be indented one additional level relative to
+  /// 

[PATCH] D102706: [clang-format] Add new LambdaBodyIndentation option

2021-06-22 Thread Björn Schäpers via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG64cf5eba06bd: [clang-format] Add new LambdaBodyIndentation 
option (authored by vlovich, committed by HazardyKnusperkeks).

Changed prior to commit:
  https://reviews.llvm.org/D102706?vs=347152&id=353753#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D102706

Files:
  clang/docs/ClangFormatStyleOptions.rst
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Format/Format.h
  clang/lib/Format/Format.cpp
  clang/lib/Format/UnwrappedLineFormatter.cpp
  clang/unittests/Format/FormatTest.cpp

Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -18531,6 +18531,7 @@
" aaa;\n"
"});",
getLLVMStyleWithColumns(60));
+
   verifyFormat("SomeFunction({[&] {\n"
"// comment\n"
"  },\n"
@@ -19083,6 +19084,117 @@
"  });\n"
"});",
LLVMWithBeforeLambdaBody);
+
+  // Lambdas with different indentation styles.
+  Style = getLLVMStyleWithColumns(100);
+  EXPECT_EQ("SomeResult doSomething(SomeObject promise) {\n"
+"  return promise.then(\n"
+"  [this, &someVariable, someObject = "
+"std::mv(s)](std::vector evaluated) mutable {\n"
+"return someObject.startAsyncAction().then(\n"
+"[this, &someVariable](AsyncActionResult result) "
+"mutable { result.processMore(); });\n"
+"  });\n"
+"}\n",
+format("SomeResult doSomething(SomeObject promise) {\n"
+   "  return promise.then([this, &someVariable, someObject = "
+   "std::mv(s)](std::vector evaluated) mutable {\n"
+   "return someObject.startAsyncAction().then([this, "
+   "&someVariable](AsyncActionResult result) mutable {\n"
+   "  result.processMore();\n"
+   "});\n"
+   "  });\n"
+   "}\n",
+   Style));
+  Style.LambdaBodyIndentation = FormatStyle::LBI_OuterScope;
+  verifyFormat("test() {\n"
+   "  ([]() -> {\n"
+   "int b = 32;\n"
+   "return 3;\n"
+   "  }).foo();\n"
+   "}",
+   Style);
+  verifyFormat("test() {\n"
+   "  []() -> {\n"
+   "int b = 32;\n"
+   "return 3;\n"
+   "  }\n"
+   "}",
+   Style);
+  verifyFormat("std::sort(v.begin(), v.end(),\n"
+   "  [](const auto &someLongArgumentName, const auto "
+   "&someOtherLongArgumentName) {\n"
+   "  return someLongArgumentName.someMemberVariable < "
+   "someOtherLongArgumentName.someMemberVariable;\n"
+   "});",
+   Style);
+  verifyFormat("test() {\n"
+   "  (\n"
+   "  []() -> {\n"
+   "int b = 32;\n"
+   "return 3;\n"
+   "  },\n"
+   "  foo, bar)\n"
+   "  .foo();\n"
+   "}",
+   Style);
+  verifyFormat("test() {\n"
+   "  ([]() -> {\n"
+   "int b = 32;\n"
+   "return 3;\n"
+   "  })\n"
+   "  .foo()\n"
+   "  .bar();\n"
+   "}",
+   Style);
+  EXPECT_EQ("SomeResult doSomething(SomeObject promise) {\n"
+"  return promise.then(\n"
+"  [this, &someVariable, someObject = "
+"std::mv(s)](std::vector evaluated) mutable {\n"
+"return someObject.startAsyncAction().then(\n"
+"[this, &someVariable](AsyncActionResult result) mutable { "
+"result.processMore(); });\n"
+"  });\n"
+"}\n",
+format("SomeResult doSomething(SomeObject promise) {\n"
+   "  return promise.then([this, &someVariable, someObject = "
+   "std::mv(s)](std::vector evaluated) mutable {\n"
+   "return someObject.startAsyncAction().then([this, "
+   "&someVariable](AsyncActionResult result) mutable {\n"
+   "  result.processMore();\n"
+   "});\n"
+   "  });\n"
+   "}\n",
+   Style));
+  EXPECT_EQ("SomeResult doSomething(SomeObject promise) {\n"
+"  return promise.then([this, &someVariable] {\n"
+"return someObject.startAsyncAction().then(\n"
+"[this,

[PATCH] D104664: [PowerPC][NFC] Clean up builtin sema checks

2021-06-22 Thread Victor Huang via Phabricator via cfe-commits
NeHuang accepted this revision.
NeHuang added a comment.
This revision is now accepted and ready to land.

LGTM. Please give it some time (~24hrs) before commit to wait for the other 
reviewers' comment.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104664

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


[PATCH] D104342: [IR] convert warn-stack-size from module flag to fn attr

2021-06-22 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a subscriber: aaron.ballman.
dblaikie added a comment.

In D104342#2834119 , @nickdesaulniers 
wrote:

> In D104342#2831738 , @dblaikie 
> wrote:
>
>>> In D104342#2831717 , @dblaikie 
>>> wrote:
>>>
 Probably worth at least writing up the risk/instability in the docs for 
 the warning (in clang) and attribute (in llvm). (don't mind if that's in 
 this patch or a follow-up).
>
> I would think 
> https://clang.llvm.org/docs/DiagnosticsReference.html#wframe-larger-than 
> would be an appropriate place to document this for `-Wframe-larger-than=`, 
> but it seems this whole page is generated via TableGen. It's not clear to me 
> how we could insert such a note.

Yeah, I don't think we have a way to add more verbose/custom documentation for 
diagnostics. (@aaron.ballman might have some ideas)

> Langref changes: https://reviews.llvm.org/D104736.

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104342

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


[PATCH] D93528: [clang-format] Add basic support for formatting JSON

2021-06-22 Thread MyDeveloperDay via Phabricator via cfe-commits
MyDeveloperDay marked an inline comment as done.
MyDeveloperDay added a comment.

@HazardyKnusperkeks  thank you for the accept, if there are no objections from 
@curdeius , @krasimir  and @sammccall  I'd like to proceed.


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

https://reviews.llvm.org/D93528

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


[clang] 7942ebd - [clang] Add cc1 option for dumping layout for all complete types

2021-06-22 Thread David Tenty via cfe-commits

Author: David Tenty
Date: 2021-06-22T16:27:26-04:00
New Revision: 7942ebdf01b35fae240cd8a0550a3da9f03615c4

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

LOG: [clang] Add cc1 option for dumping layout for all complete types

This change adds an option which, in addition to dumping the record
layout as is done by -fdump-record-layouts, causes us to compute the
layout for all complete record types (rather than the as-needed basis
which is usually done by clang), so that we will dump them as well.
This is useful if we are looking for layout differences across large
code bases without needing to instantiate every type we are interested in.

Reviewed By: dexonsmith

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

Added: 
clang/test/Layout/dump-complete.cpp

Modified: 
clang/include/clang/Basic/LangOptions.def
clang/include/clang/Driver/Options.td
clang/lib/AST/Decl.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/LangOptions.def 
b/clang/include/clang/Basic/LangOptions.def
index 32429f019064d..b6d9160f89a00 100644
--- a/clang/include/clang/Basic/LangOptions.def
+++ b/clang/include/clang/Basic/LangOptions.def
@@ -265,6 +265,7 @@ BENIGN_LANGOPT(ModulesDebugInfo , 1, 0, "Modules debug 
info")
 BENIGN_LANGOPT(ElideConstructors , 1, 1, "C++ copy constructor elision")
 BENIGN_LANGOPT(DumpRecordLayouts , 1, 0, "dumping the layout of IRgen'd 
records")
 BENIGN_LANGOPT(DumpRecordLayoutsSimple , 1, 0, "dumping the layout of IRgen'd 
records in a simple form")
+BENIGN_LANGOPT(DumpRecordLayoutsComplete , 1, 0, "dumping the AST layout of 
all complete records")
 BENIGN_LANGOPT(DumpVTableLayouts , 1, 0, "dumping the layouts of emitted 
vtables")
 LANGOPT(NoConstantCFStrings , 1, 0, "no constant CoreFoundation strings")
 BENIGN_LANGOPT(InlineVisibilityHidden , 1, 0, "hidden visibility for inline 
C++ methods")

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index 016a565e77a57..cddc924dacd2e 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -5381,10 +5381,13 @@ def stats_file : Joined<["-"], "stats-file=">,
 def fdump_record_layouts_simple : Flag<["-"], "fdump-record-layouts-simple">,
   HelpText<"Dump record layout information in a simple form used for testing">,
   MarshallingInfoFlag>;
+def fdump_record_layouts_complete : Flag<["-"], 
"fdump-record-layouts-complete">,
+  HelpText<"Dump record layout information for all complete types">,
+  MarshallingInfoFlag>;
 def fdump_record_layouts : Flag<["-"], "fdump-record-layouts">,
   HelpText<"Dump record layout information">,
   MarshallingInfoFlag>,
-  ImpliedByAnyOf<[fdump_record_layouts_simple.KeyPath]>;
+  ImpliedByAnyOf<[fdump_record_layouts_simple.KeyPath, 
fdump_record_layouts_complete.KeyPath]>;
 def fix_what_you_can : Flag<["-"], "fix-what-you-can">,
   HelpText<"Apply fix-it advice even in the presence of unfixable errors">,
   MarshallingInfoFlag>;

diff  --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index 27b34d3d16996..0fbe8ec161910 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -4581,6 +4581,13 @@ RecordDecl::field_iterator RecordDecl::field_begin() 
const {
 void RecordDecl::completeDefinition() {
   assert(!isCompleteDefinition() && "Cannot redefine record!");
   TagDecl::completeDefinition();
+
+  ASTContext &Ctx = getASTContext();
+
+  // Layouts are dumped when computed, so if we are dumping for all complete
+  // types, we need to force usage to get types that wouldn't be used 
elsewhere.
+  if (Ctx.getLangOpts().DumpRecordLayoutsComplete)
+(void)Ctx.getASTRecordLayout(this);
 }
 
 /// isMsStruct - Get whether or not this record uses ms_struct layout.

diff  --git a/clang/test/Layout/dump-complete.cpp 
b/clang/test/Layout/dump-complete.cpp
new file mode 100644
index 0..9ccbf477c7052
--- /dev/null
+++ b/clang/test/Layout/dump-complete.cpp
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -emit-llvm-only -fdump-record-layouts-complete %s | 
FileCheck %s
+
+struct a {
+  int x;
+};
+
+struct b {
+  char y;
+} foo;
+
+class c {};
+
+class d;
+
+// CHECK:  0 | struct a
+// CHECK:  0 | struct b
+// CHECK:  0 | class c
+// CHECK-NOT:  0 | class d



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


[PATCH] D104484: [clang] Add cc1 option for dumping layout for all complete types

2021-06-22 Thread David Tenty via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG7942ebdf01b3: [clang] Add cc1 option for dumping layout for 
all complete types (authored by daltenty).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104484

Files:
  clang/include/clang/Basic/LangOptions.def
  clang/include/clang/Driver/Options.td
  clang/lib/AST/Decl.cpp
  clang/test/Layout/dump-complete.cpp


Index: clang/test/Layout/dump-complete.cpp
===
--- /dev/null
+++ clang/test/Layout/dump-complete.cpp
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -emit-llvm-only -fdump-record-layouts-complete %s | 
FileCheck %s
+
+struct a {
+  int x;
+};
+
+struct b {
+  char y;
+} foo;
+
+class c {};
+
+class d;
+
+// CHECK:  0 | struct a
+// CHECK:  0 | struct b
+// CHECK:  0 | class c
+// CHECK-NOT:  0 | class d
Index: clang/lib/AST/Decl.cpp
===
--- clang/lib/AST/Decl.cpp
+++ clang/lib/AST/Decl.cpp
@@ -4581,6 +4581,13 @@
 void RecordDecl::completeDefinition() {
   assert(!isCompleteDefinition() && "Cannot redefine record!");
   TagDecl::completeDefinition();
+
+  ASTContext &Ctx = getASTContext();
+
+  // Layouts are dumped when computed, so if we are dumping for all complete
+  // types, we need to force usage to get types that wouldn't be used 
elsewhere.
+  if (Ctx.getLangOpts().DumpRecordLayoutsComplete)
+(void)Ctx.getASTRecordLayout(this);
 }
 
 /// isMsStruct - Get whether or not this record uses ms_struct layout.
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -5381,10 +5381,13 @@
 def fdump_record_layouts_simple : Flag<["-"], "fdump-record-layouts-simple">,
   HelpText<"Dump record layout information in a simple form used for testing">,
   MarshallingInfoFlag>;
+def fdump_record_layouts_complete : Flag<["-"], 
"fdump-record-layouts-complete">,
+  HelpText<"Dump record layout information for all complete types">,
+  MarshallingInfoFlag>;
 def fdump_record_layouts : Flag<["-"], "fdump-record-layouts">,
   HelpText<"Dump record layout information">,
   MarshallingInfoFlag>,
-  ImpliedByAnyOf<[fdump_record_layouts_simple.KeyPath]>;
+  ImpliedByAnyOf<[fdump_record_layouts_simple.KeyPath, 
fdump_record_layouts_complete.KeyPath]>;
 def fix_what_you_can : Flag<["-"], "fix-what-you-can">,
   HelpText<"Apply fix-it advice even in the presence of unfixable errors">,
   MarshallingInfoFlag>;
Index: clang/include/clang/Basic/LangOptions.def
===
--- clang/include/clang/Basic/LangOptions.def
+++ clang/include/clang/Basic/LangOptions.def
@@ -265,6 +265,7 @@
 BENIGN_LANGOPT(ElideConstructors , 1, 1, "C++ copy constructor elision")
 BENIGN_LANGOPT(DumpRecordLayouts , 1, 0, "dumping the layout of IRgen'd 
records")
 BENIGN_LANGOPT(DumpRecordLayoutsSimple , 1, 0, "dumping the layout of IRgen'd 
records in a simple form")
+BENIGN_LANGOPT(DumpRecordLayoutsComplete , 1, 0, "dumping the AST layout of 
all complete records")
 BENIGN_LANGOPT(DumpVTableLayouts , 1, 0, "dumping the layouts of emitted 
vtables")
 LANGOPT(NoConstantCFStrings , 1, 0, "no constant CoreFoundation strings")
 BENIGN_LANGOPT(InlineVisibilityHidden , 1, 0, "hidden visibility for inline 
C++ methods")


Index: clang/test/Layout/dump-complete.cpp
===
--- /dev/null
+++ clang/test/Layout/dump-complete.cpp
@@ -0,0 +1,18 @@
+// RUN: %clang_cc1 -emit-llvm-only -fdump-record-layouts-complete %s | FileCheck %s
+
+struct a {
+  int x;
+};
+
+struct b {
+  char y;
+} foo;
+
+class c {};
+
+class d;
+
+// CHECK:  0 | struct a
+// CHECK:  0 | struct b
+// CHECK:  0 | class c
+// CHECK-NOT:  0 | class d
Index: clang/lib/AST/Decl.cpp
===
--- clang/lib/AST/Decl.cpp
+++ clang/lib/AST/Decl.cpp
@@ -4581,6 +4581,13 @@
 void RecordDecl::completeDefinition() {
   assert(!isCompleteDefinition() && "Cannot redefine record!");
   TagDecl::completeDefinition();
+
+  ASTContext &Ctx = getASTContext();
+
+  // Layouts are dumped when computed, so if we are dumping for all complete
+  // types, we need to force usage to get types that wouldn't be used elsewhere.
+  if (Ctx.getLangOpts().DumpRecordLayoutsComplete)
+(void)Ctx.getASTRecordLayout(this);
 }
 
 /// isMsStruct - Get whether or not this record uses ms_struct layout.
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -5381,10 +5381,13 @@
 def fdump_record_layouts_simple : Flag<["-"], "

  1   2   >