[PATCH] D115441: [X86][MS] Add 80bit long double support for Windows

[Phoebe Wang via Phabricator via cfe-commits]

pengfei added a comment.

> I have a thought. Why do you need to change the LLVM data layout at all? 
> Clang's record layout is distinct from LLVM's data layout. This is similar to 
> how -malign-double works, which does not affect LLVM's data layout, it is 
> entirely a frontend change.

We have to change LLVM data layout because it's required by the calling 
conversion.

1. We specified the alignment of `f80` on 32 bits to 0: 
https://github.com/llvm/llvm-project/blob/main/llvm/lib/Target/X86/X86CallingConv.td#L869
2. Which means the alignment is actually determined by the data layout: 
https://github.com/llvm/llvm-project/blob/main/llvm/utils/TableGen/CallingConvEmitter.cpp#L200

As far as I understand it, `-malign-double` only affects the alignment of local 
and global variables. It has nothing to do with calling conversion.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115441

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

[PATCH] D115320: Avoid setting tbaa information on store of return type of call to inline assember

[Sindhu Chittireddy via Phabricator via cfe-commits]

schittir added a comment.

https://reviews.llvm.org/harbormaster/unit/view/1536685/ 
Test failure seems unrelated to this patch. Unable to reproduce locally.


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

https://reviews.llvm.org/D115320

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

[PATCH] D115625: [clang-format] add support for cppm files

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay updated this revision to Diff 394161.
MyDeveloperDay added a comment.

Add other support module file types for completeness


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

https://reviews.llvm.org/D115625

Files:
  clang/tools/clang-format/clang-format-diff.py
  clang/tools/clang-format/git-clang-format


Index: clang/tools/clang-format/git-clang-format
===
--- clang/tools/clang-format/git-clang-format
+++ clang/tools/clang-format/git-clang-format
@@ -79,6 +79,7 @@
   'm',  # ObjC
   'mm',  # ObjC++
   'cc', 'cp', 'cpp', 'c++', 'cxx', 'hh', 'hpp', 'hxx',  # C++
+  'ccm', 'cppm', 'cxxm', 'c++m',  # C++ Modules
   'cu', 'cuh',  # CUDA
   # Other languages that clang-format supports
   'proto', 'protodevel',  # Protocol Buffers
Index: clang/tools/clang-format/clang-format-diff.py
===
--- clang/tools/clang-format/clang-format-diff.py
+++ clang/tools/clang-format/clang-format-diff.py
@@ -47,8 +47,8 @@
   help='custom pattern selecting file paths to reformat '
   '(case sensitive, overrides -iregex)')
   parser.add_argument('-iregex', metavar='PATTERN', default=
-  r'.*\.(cpp|cc|c\+\+|cxx|c|cl|h|hh|hpp|hxx|m|mm|inc|js|ts'
-  r'|proto|protodevel|java|cs|json)',
+  
r'.*\.(cpp|cc|c\+\+|cxx|cppm|ccm|cxxm|c\+\+m|c|cl|h|hh|hpp|hxx'
+  r'|m|mm|inc|js|ts|proto|protodevel|java|cs|json)',
   help='custom pattern selecting file paths to reformat '
   '(case insensitive, overridden by -regex)')
   parser.add_argument('-sort-includes', action='store_true', default=False,


Index: clang/tools/clang-format/git-clang-format
===
--- clang/tools/clang-format/git-clang-format
+++ clang/tools/clang-format/git-clang-format
@@ -79,6 +79,7 @@
   'm',  # ObjC
   'mm',  # ObjC++
   'cc', 'cp', 'cpp', 'c++', 'cxx', 'hh', 'hpp', 'hxx',  # C++
+  'ccm', 'cppm', 'cxxm', 'c++m',  # C++ Modules
   'cu', 'cuh',  # CUDA
   # Other languages that clang-format supports
   'proto', 'protodevel',  # Protocol Buffers
Index: clang/tools/clang-format/clang-format-diff.py
===
--- clang/tools/clang-format/clang-format-diff.py
+++ clang/tools/clang-format/clang-format-diff.py
@@ -47,8 +47,8 @@
   help='custom pattern selecting file paths to reformat '
   '(case sensitive, overrides -iregex)')
   parser.add_argument('-iregex', metavar='PATTERN', default=
-  r'.*\.(cpp|cc|c\+\+|cxx|c|cl|h|hh|hpp|hxx|m|mm|inc|js|ts'
-  r'|proto|protodevel|java|cs|json)',
+  r'.*\.(cpp|cc|c\+\+|cxx|cppm|ccm|cxxm|c\+\+m|c|cl|h|hh|hpp|hxx'
+  r'|m|mm|inc|js|ts|proto|protodevel|java|cs|json)',
   help='custom pattern selecting file paths to reformat '
   '(case insensitive, overridden by -regex)')
   parser.add_argument('-sort-includes', action='store_true', default=False,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D115441: [X86][MS] Add 80bit long double support for Windows

[Phoebe Wang via Phabricator via cfe-commits]

pengfei added a comment.

In D115441#3189551 , @JohnReagan 
wrote:

> Does any of this impact the -f128 support?  We use f128 x-float on OpenVMS.  
> We've historically only aligned on 8-byte boundaries for legacy reasons (I'm 
> not opposed to having my own mods to control the record layout and/or data 
> layout)

I don't think so. `f128` has its distinct layout `-f128:xxx`, though I found 
only X86-32 MCU defines it in trunk code: 
https://github.com/llvm/llvm-project/blob/main/clang/lib/Basic/Targets/X86.h#L628


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115441

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

[PATCH] D115647: [clang-format] FixNamespaceComments does not understand namespace aliases

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay updated this revision to Diff 394163.
MyDeveloperDay added a comment.

use endsWith()


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

https://reviews.llvm.org/D115647

Files:
  clang/lib/Format/NamespaceEndCommentsFixer.cpp
  clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp

Index: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
===
--- clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
+++ clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
@@ -1185,6 +1185,82 @@
 "}\n",
 Style));
 }
+
+TEST_F(ShortNamespaceLinesTest, NamespaceAlias) {
+  auto Style = getLLVMStyle();
+
+  EXPECT_EQ("namespace n = nn;\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+fixNamespaceEndComments("namespace n = nn;\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+Style));
+
+  EXPECT_EQ("namespace n = nn; // comment\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+fixNamespaceEndComments("namespace n = nn; // comment\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+Style));
+
+  EXPECT_EQ("namespace n = nn; /* comment */\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+fixNamespaceEndComments("namespace n = nn; /* comment */\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+Style));
+
+  EXPECT_EQ(
+  "namespace n = nn; /* comment */ /* comment2 */\n"
+  "{\n"
+  "  int i;\n"
+  "  int j;\n"
+  "}\n",
+  fixNamespaceEndComments("namespace n = nn; /* comment */ /* comment2 */\n"
+  "{\n"
+  "  int i;\n"
+  "  int j;\n"
+  "}\n",
+  Style));
+
+  EXPECT_EQ("namespace n = nn; {\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+fixNamespaceEndComments("namespace n = nn; {\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+Style));
+  EXPECT_EQ("int foo;\n"
+"namespace n\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}// namespace n\n",
+fixNamespaceEndComments("int foo;\n"
+"namespace n\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+Style));
+}
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: clang/lib/Format/NamespaceEndCommentsFixer.cpp
===
--- clang/lib/Format/NamespaceEndCommentsFixer.cpp
+++ clang/lib/Format/NamespaceEndCommentsFixer.cpp
@@ -180,9 +180,13 @@
   if (NamespaceTok->is(tok::l_brace)) {
 // "namespace" keyword can be on the line preceding '{', e.g. in styles
 // where BraceWrapping.AfterNamespace is true.
-if (StartLineIndex > 0)
+if (StartLineIndex > 0) {
   NamespaceTok = AnnotatedLines[StartLineIndex - 1]->First;
+  if (AnnotatedLines[StartLineIndex - 1]->endsWith(tok::semi))
+return nullptr;
+}
   }
+
   return NamespaceTok->getNamespaceToken();
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D115440: Provide __builtin_alloca*_uninitialized variants

[Marco Elver via Phabricator via cfe-commits]

melver reclaimed this revision.
melver added a comment.

> Let's consult libc's own documentation 
> https://www.gnu.org/software/libc/manual/html_node/Variable-Size-Automatic.html
>
> It states:
>
>> Automatic Storage with Variable Size
>> The function alloca supports a kind of half-dynamic allocation in which 
>> blocks are allocated dynamically but freed automatically.

Thanks for clarifying -- this makes it clear it's "automatic storage". But I 
think we may still get conflicting views because `-ftrivial-auto-var-init` 
speaks about "automatic variables", and strictly speaking `__builtin_alloca()` 
is not a "variable".

> Further, Segher misunderstand the purpose of automatic initialization. The 
> goal is explicitly to change implementation-defined behavior from "the 
> compiler leaves stack and register slots with whatever value it happened to 
> overlap with (potentially leading to info leaks or UaF)" to "the compiler 
> always overwrites previous values that were in stack and register slots 
> before they are reused (preventing a large number of info leaks and UaF)". 
> Saying "the normal behaviour of alloca already" is correct, but it ignores 
> the objective of the flag: to explicitly *change* that behavior. The flag 
> opts-in to that implementation-defined behavior change. And it has a very 
> specific purpose w.r.t. security. This has measurable results in terms of 
> CVEs avoided.
>
> Additionally the flag is not explicitly for small fixed-sized variables, that 
> was stated very clearly when it was committed, and the documentation is 
> unambiguous about this fact. If initialization is too expensive then 
> developers needs to opt-out with mechanisms such as 
> `__attribute__((uninitialized))`. The support for VLAs and `alloca` was done 
> very much on purpose, and if developers turn on variable auto-init then they 
> reasonably expect that all automatic variables are automatically initialized, 
> including VLAs and `alloca`. The patch you propose here is a good idea, 
> because there's currently no way to opt-out for `alloca`. We should adopt a 
> solution such as this one, and synchronize with GCC so that developers can 
> use the same code.

I agree that having alloca() initialized is desirable normally.

The problem is that it is not at all obvious if `-ftrivial-auto-var-init` 
implies "automatic storage" or "automatic variables", only. (I mixed that up 
above as well!)

The latter is what (I think) led GCC folks to claim (and convinced me, too) 
that `__builtin_alloca()` is out-of-scope. That flag talks too much about 
"automatic stack variables".

If, however, you declare that it's the former, that's fine too. We just have to 
be very careful with how we document this -- do we want to replace "automatic 
stack variable" with "automatic stack storage" in documentation? We have to 
admit that this part is too easy to misinterpret, which is how we ended up here.

I'm going to reopen this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115440

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

[PATCH] D115320: Avoid setting tbaa information on store of return type of call to inline assember

[Sindhu Chittireddy via Phabricator via cfe-commits]

schittir updated this revision to Diff 394173.
schittir added a comment.

Rebasing patch to see if the test failure will go away.


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

https://reviews.llvm.org/D115320

Files:
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/avoidTBAAonASMstore.cpp


Index: clang/test/CodeGen/avoidTBAAonASMstore.cpp
===
--- /dev/null
+++ clang/test/CodeGen/avoidTBAAonASMstore.cpp
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -triple i386-unknown-linux-gnu -O2 -disable-llvm-passes 
-fasm-blocks %s -emit-llvm -o - | FileCheck --check-prefix=STORE-LINE %s
+double foo(double z) {
+  // CHECK-LABEL: define{{.*}} double @_Z3food
+  unsigned short ControlWord;
+  __asm { fnstcw word ptr[ControlWord]}
+  ;
+  // STORE-LINE: store i64 %{{.*}}, i64* %{{.*}},
+  // STORE-LINE-NOT: align 4, !tbaa
+  // STORE-LINE-SAME: align 4
+  return z;
+}
Index: clang/lib/CodeGen/CodeGenFunction.h
===
--- clang/lib/CodeGen/CodeGenFunction.h
+++ clang/lib/CodeGen/CodeGenFunction.h
@@ -2504,6 +2504,13 @@
 BaseInfo, TBAAInfo);
   }
 
+  LValue
+  MakeAddrLValueWithoutTBAA(Address Addr, QualType T,
+AlignmentSource Source = AlignmentSource::Type) {
+return LValue::MakeAddr(Addr, T, getContext(), LValueBaseInfo(Source),
+TBAAAccessInfo());
+  }
+
   LValue MakeNaturalAlignPointeeAddrLValue(llvm::Value *V, QualType T);
   LValue MakeNaturalAlignAddrLValue(llvm::Value *V, QualType T);
 
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -2454,7 +2454,7 @@
 const ABIArgInfo &RetAI = CurFnInfo->getReturnInfo();
 if (RetAI.isDirect() || RetAI.isExtend()) {
   // Make a fake lvalue for the return value slot.
-  LValue ReturnSlot = MakeAddrLValue(ReturnValue, FnRetTy);
+  LValue ReturnSlot = MakeAddrLValueWithoutTBAA(ReturnValue, FnRetTy);
   CGM.getTargetCodeGenInfo().addReturnRegisterOutputs(
   *this, ReturnSlot, Constraints, ResultRegTypes, ResultTruncRegTypes,
   ResultRegDests, AsmString, S.getNumOutputs());


Index: clang/test/CodeGen/avoidTBAAonASMstore.cpp
===
--- /dev/null
+++ clang/test/CodeGen/avoidTBAAonASMstore.cpp
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -triple i386-unknown-linux-gnu -O2 -disable-llvm-passes -fasm-blocks %s -emit-llvm -o - | FileCheck --check-prefix=STORE-LINE %s
+double foo(double z) {
+  // CHECK-LABEL: define{{.*}} double @_Z3food
+  unsigned short ControlWord;
+  __asm { fnstcw word ptr[ControlWord]}
+  ;
+  // STORE-LINE: store i64 %{{.*}}, i64* %{{.*}},
+  // STORE-LINE-NOT: align 4, !tbaa
+  // STORE-LINE-SAME: align 4
+  return z;
+}
Index: clang/lib/CodeGen/CodeGenFunction.h
===
--- clang/lib/CodeGen/CodeGenFunction.h
+++ clang/lib/CodeGen/CodeGenFunction.h
@@ -2504,6 +2504,13 @@
 BaseInfo, TBAAInfo);
   }
 
+  LValue
+  MakeAddrLValueWithoutTBAA(Address Addr, QualType T,
+AlignmentSource Source = AlignmentSource::Type) {
+return LValue::MakeAddr(Addr, T, getContext(), LValueBaseInfo(Source),
+TBAAAccessInfo());
+  }
+
   LValue MakeNaturalAlignPointeeAddrLValue(llvm::Value *V, QualType T);
   LValue MakeNaturalAlignAddrLValue(llvm::Value *V, QualType T);
 
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -2454,7 +2454,7 @@
 const ABIArgInfo &RetAI = CurFnInfo->getReturnInfo();
 if (RetAI.isDirect() || RetAI.isExtend()) {
   // Make a fake lvalue for the return value slot.
-  LValue ReturnSlot = MakeAddrLValue(ReturnValue, FnRetTy);
+  LValue ReturnSlot = MakeAddrLValueWithoutTBAA(ReturnValue, FnRetTy);
   CGM.getTargetCodeGenInfo().addReturnRegisterOutputs(
   *this, ReturnSlot, Constraints, ResultRegTypes, ResultTruncRegTypes,
   ResultRegDests, AsmString, S.getNumOutputs());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D115320: Avoid setting tbaa information on store of return type of call to inline assember

[Jeroen Dobbelaere via Phabricator via cfe-commits]

jeroen.dobbelaere added inline comments.



Comment at: clang/test/CodeGen/avoidTBAAonASMstore.cpp:3
+double foo(double z) {
+  // CHECK-LABEL: define{{.*}} double @_Z3food
+  unsigned short ControlWord;

Shouldn't this be `STORE-LINE-LABEL: ...` ?


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

https://reviews.llvm.org/D115320

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

[PATCH] D113237: [RISCV] Support I extension version 2.1

[Shao-Ce SUN via Phabricator via cfe-commits]

achieveartificialintelligence updated this revision to Diff 394174.
achieveartificialintelligence added a comment.

Support both i2p0 and i2p1


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113237

Files:
  clang/lib/Basic/Targets/RISCV.cpp
  clang/test/Driver/riscv-arch.c
  clang/test/Driver/riscv-cpus.c
  llvm/include/llvm/Support/RISCVISAInfo.h
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/AsmParser/RISCVAsmParser.cpp
  llvm/lib/Target/RISCV/MCTargetDesc/RISCVTargetStreamer.cpp
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVInstrInfo.td
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/MC/RISCV/attribute-arch.s
  llvm/test/MC/RISCV/rv32zicsr-invalid.s
  llvm/test/MC/RISCV/rv32zicsr-valid.s
  llvm/test/MC/RISCV/rv32zifencei-valid.s

Index: llvm/test/MC/RISCV/rv32zifencei-valid.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/rv32zifencei-valid.s
@@ -0,0 +1,8 @@
+# RUN: llvm-mc %s -triple=riscv32  -mattr=+zifencei -riscv-no-aliases -show-encoding \
+# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc %s -triple riscv64 -mattr=+zifencei -riscv-no-aliases -show-encoding \
+# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
+
+# CHECK-ASM-AND-OBJ: fence.i
+# CHECK-ASM: encoding: [0x0f,0x10,0x00,0x00]
+fence.i
Index: llvm/test/MC/RISCV/rv32zicsr-valid.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/rv32zicsr-valid.s
@@ -0,0 +1,32 @@
+# RUN: llvm-mc %s -triple=riscv32 -mattr=+zicsr -riscv-no-aliases -show-encoding \
+# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
+# RUN: llvm-mc %s -triple riscv64 -mattr=+zicsr -riscv-no-aliases -show-encoding \
+# RUN: | FileCheck -check-prefixes=CHECK-ASM,CHECK-ASM-AND-OBJ %s
+
+# CHECK-ASM-AND-OBJ: csrrw t0, 4095, t1
+# CHECK-ASM: encoding: [0xf3,0x12,0xf3,0xff]
+csrrw t0, 0xfff, t1
+# CHECK-ASM-AND-OBJ: csrrw s0, 4095, s1
+# CHECK-ASM: encoding: [0x73,0x94,0xf4,0xff]
+csrrw s0, ~(-4096), s1
+# CHECK-ASM-AND-OBJ: csrrw s0, fflags, s1
+# CHECK-ASM: encoding: [0x73,0x94,0x14,0x00]
+csrrw s0, !0, s1
+# CHECK-ASM-AND-OBJ: csrrs s0, cycle, zero
+# CHECK-ASM: encoding: [0x73,0x24,0x00,0xc0]
+csrrs s0, 0xc00, x0
+# CHECK-ASM-AND-OBJ: csrrs s3, fflags, s5
+# CHECK-ASM: encoding: [0xf3,0xa9,0x1a,0x00]
+csrrs s3, 0x001, s5
+# CHECK-ASM-AND-OBJ: csrrc sp, ustatus, ra
+# CHECK-ASM: encoding: [0x73,0xb1,0x00,0x00]
+csrrc sp, 0x000, ra
+# CHECK-ASM-AND-OBJ: csrrwi a5, ustatus, 0
+# CHECK-ASM: encoding: [0xf3,0x57,0x00,0x00]
+csrrwi a5, 0x000, 0
+# CHECK-ASM-AND-OBJ: csrrsi t2, 4095, 31
+# CHECK-ASM: encoding: [0xf3,0xe3,0xff,0xff]
+csrrsi t2, 0xfff, 31
+# CHECK-ASM-AND-OBJ: csrrci t1, sscratch, 5
+# CHECK-ASM: encoding: [0x73,0xf3,0x02,0x14]
+csrrci t1, 0x140, 5
Index: llvm/test/MC/RISCV/rv32zicsr-invalid.s
===
--- /dev/null
+++ llvm/test/MC/RISCV/rv32zicsr-invalid.s
@@ -0,0 +1,44 @@
+# RUN: not llvm-mc -triple riscv32 -mattr=+zicsr < %s 2>&1 | FileCheck %s
+
+# Out of range immediates
+## uimm5
+csrrwi a1, 0x1, -1 # CHECK: :[[@LINE]]:17: error: immediate must be an integer in the range [0, 31]
+csrrsi t1, 999, 32 # CHECK: :[[@LINE]]:17: error: immediate must be an integer in the range [0, 31]
+csrrci x0, 43, -90 # CHECK: :[[@LINE]]:16: error: immediate must be an integer in the range [0, 31]
+
+## uimm12
+csrrw a0, -1, a0 # CHECK: :[[@LINE]]:11: error: immediate must be an integer in the range [0, 4095]
+csrrs a0, 4096, a0 # CHECK: :[[@LINE]]:11: error: immediate must be an integer in the range [0, 4095]
+csrrs a0, -0xf, a0 # CHECK: :[[@LINE]]:11: error: immediate must be an integer in the range [0, 4095]
+csrrc a0, 0x1000, a0 # CHECK: :[[@LINE]]:11: error: immediate must be an integer in the range [0, 4095]
+csrrwi a0, -50, 0 # CHECK: :[[@LINE]]:12: error: immediate must be an integer in the range [0, 4095]
+csrrsi a0, 4097, a0 # CHECK: :[[@LINE]]:12: error: immediate must be an integer in the range [0, 4095]
+csrrci a0, 0x, a0 # CHECK: :[[@LINE]]:12: error: immediate must be an integer in the range [0, 4095]
+
+# Illegal operand modifier
+## uimm5
+csrrwi a1, 0x1, %hi(b) # CHECK: :[[@LINE]]:17: error: immediate must be an integer in the range [0, 31]
+csrrsi t1, 999, %pcrel_hi(3) # CHECK: :[[@LINE]]:17: error: immediate must be an integer in the range [0, 31]
+csrrci x0, 43, %pcrel_hi(c) # CHECK: :[[@LINE]]:16: error: immediate must be an integer in the range [0, 31]
+csrrsi t1, 999, %pcrel_lo(4) # CHECK: :[[@LINE]]:17: error: immediate must be an integer in the range [0, 31]
+csrrci x0, 43, %pcrel_lo(d) # CHECK: :[[@LINE]]:16: error: immediate must be an integer in the range [0, 31]
+
+## uimm12
+csrrw a0, %lo(1), a0 # CHECK: :[[@LINE]]:11: error: immediate must be an integer in the range [0, 4095]
+csrrs a

[PATCH] D115320: Avoid setting tbaa information on store of return type of call to inline assember

[Sindhu Chittireddy via Phabricator via cfe-commits]

schittir updated this revision to Diff 394176.
schittir added a comment.

Change CHECK-LABEL to STORE-LINE-LABEL


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

https://reviews.llvm.org/D115320

Files:
  clang/lib/CodeGen/CGStmt.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGen/avoidTBAAonASMstore.cpp


Index: clang/test/CodeGen/avoidTBAAonASMstore.cpp
===
--- /dev/null
+++ clang/test/CodeGen/avoidTBAAonASMstore.cpp
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -triple i386-unknown-linux-gnu -O2 -disable-llvm-passes 
-fasm-blocks %s -emit-llvm -o - | FileCheck --check-prefix=STORE-LINE %s
+double foo(double z) {
+  // STORE-LINE-LABEL: define{{.*}} double @_Z3food
+  unsigned short ControlWord;
+  __asm { fnstcw word ptr[ControlWord]}
+  ;
+  // STORE-LINE: store i64 %{{.*}}, i64* %{{.*}},
+  // STORE-LINE-NOT: align 4, !tbaa
+  // STORE-LINE-SAME: align 4
+  return z;
+}
Index: clang/lib/CodeGen/CodeGenFunction.h
===
--- clang/lib/CodeGen/CodeGenFunction.h
+++ clang/lib/CodeGen/CodeGenFunction.h
@@ -2504,6 +2504,13 @@
 BaseInfo, TBAAInfo);
   }
 
+  LValue
+  MakeAddrLValueWithoutTBAA(Address Addr, QualType T,
+AlignmentSource Source = AlignmentSource::Type) {
+return LValue::MakeAddr(Addr, T, getContext(), LValueBaseInfo(Source),
+TBAAAccessInfo());
+  }
+
   LValue MakeNaturalAlignPointeeAddrLValue(llvm::Value *V, QualType T);
   LValue MakeNaturalAlignAddrLValue(llvm::Value *V, QualType T);
 
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -2454,7 +2454,7 @@
 const ABIArgInfo &RetAI = CurFnInfo->getReturnInfo();
 if (RetAI.isDirect() || RetAI.isExtend()) {
   // Make a fake lvalue for the return value slot.
-  LValue ReturnSlot = MakeAddrLValue(ReturnValue, FnRetTy);
+  LValue ReturnSlot = MakeAddrLValueWithoutTBAA(ReturnValue, FnRetTy);
   CGM.getTargetCodeGenInfo().addReturnRegisterOutputs(
   *this, ReturnSlot, Constraints, ResultRegTypes, ResultTruncRegTypes,
   ResultRegDests, AsmString, S.getNumOutputs());


Index: clang/test/CodeGen/avoidTBAAonASMstore.cpp
===
--- /dev/null
+++ clang/test/CodeGen/avoidTBAAonASMstore.cpp
@@ -0,0 +1,11 @@
+// RUN: %clang_cc1 -triple i386-unknown-linux-gnu -O2 -disable-llvm-passes -fasm-blocks %s -emit-llvm -o - | FileCheck --check-prefix=STORE-LINE %s
+double foo(double z) {
+  // STORE-LINE-LABEL: define{{.*}} double @_Z3food
+  unsigned short ControlWord;
+  __asm { fnstcw word ptr[ControlWord]}
+  ;
+  // STORE-LINE: store i64 %{{.*}}, i64* %{{.*}},
+  // STORE-LINE-NOT: align 4, !tbaa
+  // STORE-LINE-SAME: align 4
+  return z;
+}
Index: clang/lib/CodeGen/CodeGenFunction.h
===
--- clang/lib/CodeGen/CodeGenFunction.h
+++ clang/lib/CodeGen/CodeGenFunction.h
@@ -2504,6 +2504,13 @@
 BaseInfo, TBAAInfo);
   }
 
+  LValue
+  MakeAddrLValueWithoutTBAA(Address Addr, QualType T,
+AlignmentSource Source = AlignmentSource::Type) {
+return LValue::MakeAddr(Addr, T, getContext(), LValueBaseInfo(Source),
+TBAAAccessInfo());
+  }
+
   LValue MakeNaturalAlignPointeeAddrLValue(llvm::Value *V, QualType T);
   LValue MakeNaturalAlignAddrLValue(llvm::Value *V, QualType T);
 
Index: clang/lib/CodeGen/CGStmt.cpp
===
--- clang/lib/CodeGen/CGStmt.cpp
+++ clang/lib/CodeGen/CGStmt.cpp
@@ -2454,7 +2454,7 @@
 const ABIArgInfo &RetAI = CurFnInfo->getReturnInfo();
 if (RetAI.isDirect() || RetAI.isExtend()) {
   // Make a fake lvalue for the return value slot.
-  LValue ReturnSlot = MakeAddrLValue(ReturnValue, FnRetTy);
+  LValue ReturnSlot = MakeAddrLValueWithoutTBAA(ReturnValue, FnRetTy);
   CGM.getTargetCodeGenInfo().addReturnRegisterOutputs(
   *this, ReturnSlot, Constraints, ResultRegTypes, ResultTruncRegTypes,
   ResultRegDests, AsmString, S.getNumOutputs());
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D115709: [RISCV] Remove Vamo Extention

[Shao-Ce SUN via Phabricator via cfe-commits]

achieveartificialintelligence created this revision.
achieveartificialintelligence added reviewers: kito-cheng, HsiangKai, arcbbb, 
jrtc27, craig.topper.
Herald added subscribers: VincentWu, luke957, vkmr, frasercrmck, jdoerfert, 
evandro, luismarques, apazos, sameer.abuasal, s.egerton, Jim, benna, psnobl, 
jocewei, PkmX, the_o, brucehoult, MartinMosbeck, rogfer01, edward-jones, 
zzheng, niosHD, sabuasal, simoncook, johnrusso, rbar, asb, hiraditya.
achieveartificialintelligence requested review of this revision.
Herald added subscribers: llvm-commits, cfe-commits, MaskRay.
Herald added projects: clang, LLVM.

Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D115709

Files:
  clang/test/Driver/riscv-arch.c
  clang/test/Preprocessor/riscv-target-features.c
  llvm/include/llvm/IR/IntrinsicsRISCV.td
  llvm/lib/Support/RISCVISAInfo.cpp
  llvm/lib/Target/RISCV/RISCV.td
  llvm/lib/Target/RISCV/RISCVInstrFormatsV.td
  llvm/lib/Target/RISCV/RISCVInstrInfoV.td
  llvm/lib/Target/RISCV/RISCVInstrInfoVPseudos.td
  llvm/lib/Target/RISCV/RISCVSchedRocket.td
  llvm/lib/Target/RISCV/RISCVSchedSiFive7.td
  llvm/lib/Target/RISCV/RISCVSubtarget.h
  llvm/test/CodeGen/RISCV/attributes.ll
  llvm/test/CodeGen/RISCV/rvv/vamoadd-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vamoadd-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vamoand-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vamoand-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vamomax-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vamomax-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vamomaxu-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vamomaxu-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vamomin-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vamomin-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vamominu-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vamominu-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vamoor-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vamoor-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vamoswap-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vamoswap-rv64.ll
  llvm/test/CodeGen/RISCV/rvv/vamoxor-rv32.ll
  llvm/test/CodeGen/RISCV/rvv/vamoxor-rv64.ll
  llvm/test/MC/RISCV/attribute-arch-invalid.s
  llvm/test/MC/RISCV/attribute-arch.s
  llvm/test/MC/RISCV/rvv/zvamo.s

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

[PATCH] D115715: [clang-tidy] Fix llvm-header-guard for Windows paths containing drive letter (e.g. C:).

[Marek Kurdej via Phabricator via cfe-commits]

curdeius created this revision.
curdeius added reviewers: aaron.ballman, hokein, bkramer, salman-javed-nz, 
alexfh.
Herald added subscribers: carlosgalvezp, xazax.hun.
curdeius requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

Fixes http://llvm.org/PR52682.

The previous fix (https://reviews.llvm.org/rGb4f6f1c) escaped backslashes, but 
didn't cover colons.

So the check, for a file called e.g. "C:\test\test.h" would suggest the guard 
`C:_TEST_TEST_H` being an invalid name due to the presence of the colon.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D115715

Files:
  clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp
  clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp


Index: clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
@@ -267,6 +267,15 @@
 runHeaderGuardCheck(
 "", 
"?\\C:\\llvm-project\\clang-tools-extra\\clangd\\foo.h",
 StringRef("header is missing header guard")));
+
+  EXPECT_EQ("#ifndef C__TEST_FOO_H\n"
+"#define C__TEST_FOO_H\n"
+"\n"
+"\n"
+"#endif\n",
+runHeaderGuardCheck("", "c:\\test\\foo.h",
+StringRef("header is missing header guard")));
+
 #endif
 }
 
Index: clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp
===
--- clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp
+++ clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp
@@ -54,6 +54,7 @@
   std::replace(Guard.begin(), Guard.end(), '/', '_');
   std::replace(Guard.begin(), Guard.end(), '.', '_');
   std::replace(Guard.begin(), Guard.end(), '-', '_');
+  std::replace(Guard.begin(), Guard.end(), ':', '_');
 
   // The prevalent style in clang is LLVM_CLANG_FOO_BAR_H
   if (StringRef(Guard).startswith("clang"))


Index: clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
===
--- clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
+++ clang-tools-extra/unittests/clang-tidy/LLVMModuleTest.cpp
@@ -267,6 +267,15 @@
 runHeaderGuardCheck(
 "", "?\\C:\\llvm-project\\clang-tools-extra\\clangd\\foo.h",
 StringRef("header is missing header guard")));
+
+  EXPECT_EQ("#ifndef C__TEST_FOO_H\n"
+"#define C__TEST_FOO_H\n"
+"\n"
+"\n"
+"#endif\n",
+runHeaderGuardCheck("", "c:\\test\\foo.h",
+StringRef("header is missing header guard")));
+
 #endif
 }
 
Index: clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp
===
--- clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp
+++ clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp
@@ -54,6 +54,7 @@
   std::replace(Guard.begin(), Guard.end(), '/', '_');
   std::replace(Guard.begin(), Guard.end(), '.', '_');
   std::replace(Guard.begin(), Guard.end(), '-', '_');
+  std::replace(Guard.begin(), Guard.end(), ':', '_');
 
   // The prevalent style in clang is LLVM_CLANG_FOO_BAR_H
   if (StringRef(Guard).startswith("clang"))
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D115149: [analyzer][solver] Fix assertion on (NonLoc, Op, Loc) expressions

[Gabor Marton via Phabricator via cfe-commits]

martong added a comment.

In D115149#3188743 , @ASDenysPetrov 
wrote:

>> @steakhal
>> I don't get this one. I've provided a bunch of tests, even annotated with 
>> `no-crash` comments where we crashed prior to this change.
>
> I wasn't able to catch any crashes with your tests file 
> //(symbol-simplification-nonloc-loc.cpp)// on the baseline before your patch 
> (D115149#3180005 ). So I ask you to 
> provide the concrete example you've caught which promted you to do this patch.

Denis, you can see in the `Revision Contents` that Diff 3 has the baseline 
commit `63a6348`. When I check out `63a6348` then the newly added test file 
triggers the assertion about `BO_Add`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115149

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

[PATCH] D115715: [clang-tidy] Fix llvm-header-guard for Windows paths containing drive letter (e.g. C:).

[Stephan Bergmann via Phabricator via cfe-commits]

sberg added a comment.

> So the check, for a file called e.g. "C:\test\test.h" would suggest the guard 
> C:_TEST_TEST_H being an invalid name due to the presence of the colon.

...though the new suggestion `C__TEST_TEST_H` isn't ideal either, in that it 
uses an identifier that is reserved for the implementation (due to the double 
underscore)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115715

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

[PATCH] D114639: Raise the minimum Visual Studio version to VS2019

[Simon Pilgrim via Phabricator via cfe-commits]

RKSimon added a comment.

@rnk @stella.stamenova How long do you think it will be before you can update 
your buildbots to VS2019 or VS2022 please?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114639

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

[PATCH] D115715: [clang-tidy] Fix llvm-header-guard for Windows paths containing drive letter (e.g. C:).

[Salman Javed via Phabricator via cfe-commits]

salman-javed-nz added a comment.

The problem at the root of all this is that llvm-header-guard isn't written 
flexible enough to support non-LLVM project structures.

See 
https://github.com/llvm/llvm-project/blob/main/clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp#L44

For a path like `C:\llvm-project\path\to\file`, the `llvm-project` portion is 
replaced with `llvm` to give `C:\llvm\path\to\file`, then a `substr()` call 
strips everything up to and including `lvm`, resulting in `path\to\file`.
The path separators and replaced with underscores, resulting in `PATH_TO_FILE`.

The whole check falls apart if it can't find strings like "llvm-project" in the 
path.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115715

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

[PATCH] D115716: [Analyzer][BugReporter] Replace the example bug report with the one used to generate PathDiagnostic

[Ella Ma via Phabricator via cfe-commits]

OikawaKirie created this revision.
OikawaKirie added reviewers: NoQ, steakhal, vsavchenko, ASDenysPetrov.
OikawaKirie added a project: clang.
Herald added subscribers: manas, martong, dkrupp, donat.nagy, Szelethus, 
mikhail.ramalho, a.sidorin, szepet, baloghadamsoftware, xazax.hun.
OikawaKirie requested review of this revision.
Herald added a subscriber: cfe-commits.

In function `BugReporter::FlushReport`, function 
`PathSensitiveBugReporter::generatePathDiagnostics` will re-select one report 
from the equivalence class to construct the `PathDiagnostic`. It makes the 
report used to generate `PathDiagnostic` may be different from the one used in 
function `BugReporter::FlushReport`. Changes to the bug report via a 
`BugReporterVisitor` may not be reflected when generating report notes or 
fix-hints.

This patch tries to fix this problem by resetting the pointer to the example 
report selected in function `BugReporter::FlushReport` with the one used to 
generate `PathDiagnostic`.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D115716

Files:
  clang/include/clang/StaticAnalyzer/Core/BugReporter/BugReporter.h
  clang/lib/StaticAnalyzer/Core/BugReporter.cpp
  clang/test/Analysis/keychainAPI.m
  clang/test/Analysis/malloc-plist.c
  clang/test/Analysis/stream.c

Index: clang/test/Analysis/stream.c
===
--- clang/test/Analysis/stream.c
+++ clang/test/Analysis/stream.c
@@ -261,9 +261,7 @@
   if (!F1)
 return;
   if (Test == 1) {
-return; // no warning
+return; // expected-warning {{Opened stream never closed. Potential resource leak}}
   }
   rewind(F1);
-} // expected-warning {{Opened stream never closed. Potential resource leak}}
-// FIXME: This warning should be placed at the `return` above.
-// See https://reviews.llvm.org/D83120 about details.
+} // no warning
Index: clang/test/Analysis/malloc-plist.c
===
--- clang/test/Analysis/malloc-plist.c
+++ clang/test/Analysis/malloc-plist.c
@@ -135,8 +135,8 @@
 static void function_with_leak3(int y) {
 char *x = (char*)malloc(12);
 if (y)
-y++;
-}//expected-warning{{Potential leak}}
+y++;//expected-warning{{Potential leak}}
+}
 void use_function_with_leak3(int y) {
 function_with_leak3(y);
 }
Index: clang/test/Analysis/keychainAPI.m
===
--- clang/test/Analysis/keychainAPI.m
+++ clang/test/Analysis/keychainAPI.m
@@ -402,10 +402,10 @@
 OSStatus st = 0;
 void *outData = my_AllocateReturn(&st); 
 if (x) {
-  consumeChar(*(char*)outData); // expected-warning{{Allocated data is not released:}}
+  consumeChar(*(char*)outData);
   return;
 } else {
-  consumeChar(*(char*)outData);
+  consumeChar(*(char*)outData); // expected-warning{{Allocated data is not released:}}
 }
 return;
 }
Index: clang/lib/StaticAnalyzer/Core/BugReporter.cpp
===
--- clang/lib/StaticAnalyzer/Core/BugReporter.cpp
+++ clang/lib/StaticAnalyzer/Core/BugReporter.cpp
@@ -244,6 +244,9 @@
   std::unique_ptr
   generate(const PathDiagnosticConsumer *PDC) const;
 
+  /// Get the bug report used to generate the PathDiagnostic.
+  const PathSensitiveBugReport *getBugReport() const { return R; }
+
 private:
   void updateStackPiecesWithMessage(PathDiagnosticPieceRef P,
 const CallWithEntryStack &CallStack) const;
@@ -271,8 +274,6 @@
   PathDiagnosticLocation
   ExecutionContinues(llvm::raw_string_ostream &os,
  const PathDiagnosticConstruct &C) const;
-
-  const PathSensitiveBugReport *getBugReport() const { return R; }
 };
 
 } // namespace
@@ -2874,6 +2875,7 @@
 
 std::unique_ptr
 PathSensitiveBugReporter::generatePathDiagnostics(
+const BugReport *&exampleReport,
 ArrayRef consumers,
 ArrayRef &bugReports) {
   assert(!bugReports.empty());
@@ -2889,6 +2891,7 @@
 (*Out)[PC] = std::move(PD);
   }
 }
+exampleReport = PDB->getBugReport();
   }
 
   return Out;
@@ -3062,7 +3065,7 @@
 
 void BugReporter::FlushReport(BugReportEquivClass& EQ) {
   SmallVector bugReports;
-  BugReport *report = findReportInEquivalenceClass(EQ, bugReports);
+  const BugReport *report = findReportInEquivalenceClass(EQ, bugReports);
   if (!report)
 return;
 
@@ -3200,7 +3203,8 @@
 
 std::unique_ptr
 BugReporter::generateDiagnosticForConsumerMap(
-BugReport *exampleReport, ArrayRef consumers,
+const BugReport *&exampleReport,
+ArrayRef consumers,
 ArrayRef bugReports) {
   auto *basicReport = cast(exampleReport);
   auto Out = std::make_unique();
@@ -3272,11 +3276,10 @@
   }
 }
 
-
-
 std::unique_ptr
 PathSensitiveBugReporter::generateDiagnosticForConsumerMap(
-BugReport *exampleReport, ArrayRef consumers,
+const BugReport *&exampleReport,
+ArrayRef consumers,
 Arr

[clang] 47eec78 - [clang][deps] Remove hard-coded resource directory from tests

[Jan Svoboda via cfe-commits]

Author: Jan Svoboda
Date: 2021-12-14T10:59:47+01:00
New Revision: 47eec789ed9cc7d4cb9f1eaa0cafe3e509af015c

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

LOG: [clang][deps] Remove hard-coded resource directory from tests

Dependency scanner test for resource directory deduction doesn't account for 
LLVM builds with custom `CLANG_RESOURCE_DIR`.

This patch ensures we don't hardcode the default behavior into the test and 
take into account the actual value. This is done by running `%clang 
-print-resource-dir` and using that as the expected value in test assertions.
New comment also clarifies this is different from running that command as part 
of the dependency scan.

Reviewed By: mgorny

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

Added: 


Modified: 
clang/test/ClangScanDeps/resource_directory.c

Removed: 
clang/test/ClangScanDeps/Inputs/resource_directory/compiler



diff  --git a/clang/test/ClangScanDeps/Inputs/resource_directory/compiler 
b/clang/test/ClangScanDeps/Inputs/resource_directory/compiler
deleted file mode 100755
index edeb2a2fd0009..0
--- a/clang/test/ClangScanDeps/Inputs/resource_directory/compiler
+++ /dev/null
@@ -1,3 +0,0 @@
-#!/bin/sh
-
-echo "/custom/compiler/resources"

diff  --git a/clang/test/ClangScanDeps/resource_directory.c 
b/clang/test/ClangScanDeps/resource_directory.c
index 6912aa9a19952..55d5d90bbcdea 100644
--- a/clang/test/ClangScanDeps/resource_directory.c
+++ b/clang/test/ClangScanDeps/resource_directory.c
@@ -5,21 +5,42 @@
 
 // Deduce the resource directory from the compiler path.
 //
-// RUN: sed -e "s|CLANG|/our/custom/bin/clang|g" -e "s|DIR|%/t|g" \
+// With `%clang-scan-deps --resource-dir-recipe modify-compiler-path`, the
+// resource directory should be identical to `%clang -print-resource-dir`.
+// (Assuming both binaries are built from the same Git checkout.)
+// Here we get the expected path by running `%clang -print-resource-dir` and
+// then verify `%clang-scan-deps` arrives at the same path by calling the
+// `Driver::GetResourcesPath` function.
+//
+// RUN: EXPECTED_RESOURCE_DIR=`%clang -print-resource-dir`
+// RUN: sed -e "s|CLANG|%clang|g" -e "s|DIR|%/t|g" \
 // RUN:   %S/Inputs/resource_directory/cdb.json.template > %t/cdb_path.json
+//
 // RUN: clang-scan-deps -compilation-database %t/cdb_path.json --format 
experimental-full \
 // RUN:   --resource-dir-recipe modify-compiler-path > %t/result_path.json
-// RUN: cat %t/result_path.json | sed 's:\?:/:g' | FileCheck %s 
--check-prefix=CHECK-PATH
+// RUN: cat %t/result_path.json | sed 's:\?:/:g' \
+// RUN:   | FileCheck %s --check-prefix=CHECK-PATH 
-DEXPECTED_RESOURCE_DIR="$EXPECTED_RESOURCE_DIR"
 // CHECK-PATH:  "-resource-dir"
-// CHECK-PATH-NEXT: "/our/custom/lib{{.*}}"
+// CHECK-PATH-NEXT: "[[EXPECTED_RESOURCE_DIR]]"
 
 // Run the compiler and ask it for the resource directory.
 //
+// With `%clang-scan-deps --resource-dir-recipe invoke-compiler`, the resource
+// directory should be identical to ` -print-resource-dir`, where 

+// is an arbitrary version of Clang. (This configuration is not really 
supported.)
+// Here we hard-code the expected path into `%t/compiler` and then verify
+// `%clang-scan-deps` arrives at the path by actually running the executable.
+//
+// RUN: EXPECTED_RESOURCE_DIR="/custom/compiler/resources"
+// RUN: echo "#!/bin/sh"  > %t/compiler
+// RUN: echo "echo '$EXPECTED_RESOURCE_DIR'" >> %t/compiler
 // RUN: chmod +x %t/compiler
 // RUN: sed -e "s|CLANG|%/t/compiler|g" -e "s|DIR|%/t|g" \
 // RUN:   %S/Inputs/resource_directory/cdb.json.template > 
%t/cdb_invocation.json
+//
 // RUN: clang-scan-deps -compilation-database %t/cdb_invocation.json --format 
experimental-full \
 // RUN:   --resource-dir-recipe invoke-compiler > %t/result_invocation.json
-// RUN: cat %t/result_invocation.json | sed 's:\?:/:g' | FileCheck %s 
--check-prefix=CHECK-INVOCATION
+// RUN: cat %t/result_invocation.json | sed 's:\?:/:g' \
+// RUN:   | FileCheck %s --check-prefix=CHECK-PATH 
-DEXPECTED_RESOURCE_DIR="$EXPECTED_RESOURCE_DIR"
 // CHECK-INVOCATION:  "-resource-dir"
-// CHECK-INVOCATION-NEXT: "/custom/compiler/resources"
+// CHECK-INVOCATION-NEXT: "[[EXPECTED_RESOURCE_DIR]]"



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

[PATCH] D115628: [clang][deps] Remove hard-coded resource directory from tests

[Jan Svoboda 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 rG47eec789ed9c: [clang][deps] Remove hard-coded resource 
directory from tests (authored by jansvoboda11).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115628

Files:
  clang/test/ClangScanDeps/Inputs/resource_directory/compiler
  clang/test/ClangScanDeps/resource_directory.c


Index: clang/test/ClangScanDeps/resource_directory.c
===
--- clang/test/ClangScanDeps/resource_directory.c
+++ clang/test/ClangScanDeps/resource_directory.c
@@ -5,21 +5,42 @@
 
 // Deduce the resource directory from the compiler path.
 //
-// RUN: sed -e "s|CLANG|/our/custom/bin/clang|g" -e "s|DIR|%/t|g" \
+// With `%clang-scan-deps --resource-dir-recipe modify-compiler-path`, the
+// resource directory should be identical to `%clang -print-resource-dir`.
+// (Assuming both binaries are built from the same Git checkout.)
+// Here we get the expected path by running `%clang -print-resource-dir` and
+// then verify `%clang-scan-deps` arrives at the same path by calling the
+// `Driver::GetResourcesPath` function.
+//
+// RUN: EXPECTED_RESOURCE_DIR=`%clang -print-resource-dir`
+// RUN: sed -e "s|CLANG|%clang|g" -e "s|DIR|%/t|g" \
 // RUN:   %S/Inputs/resource_directory/cdb.json.template > %t/cdb_path.json
+//
 // RUN: clang-scan-deps -compilation-database %t/cdb_path.json --format 
experimental-full \
 // RUN:   --resource-dir-recipe modify-compiler-path > %t/result_path.json
-// RUN: cat %t/result_path.json | sed 's:\?:/:g' | FileCheck %s 
--check-prefix=CHECK-PATH
+// RUN: cat %t/result_path.json | sed 's:\?:/:g' \
+// RUN:   | FileCheck %s --check-prefix=CHECK-PATH 
-DEXPECTED_RESOURCE_DIR="$EXPECTED_RESOURCE_DIR"
 // CHECK-PATH:  "-resource-dir"
-// CHECK-PATH-NEXT: "/our/custom/lib{{.*}}"
+// CHECK-PATH-NEXT: "[[EXPECTED_RESOURCE_DIR]]"
 
 // Run the compiler and ask it for the resource directory.
 //
+// With `%clang-scan-deps --resource-dir-recipe invoke-compiler`, the resource
+// directory should be identical to ` -print-resource-dir`, where 

+// is an arbitrary version of Clang. (This configuration is not really 
supported.)
+// Here we hard-code the expected path into `%t/compiler` and then verify
+// `%clang-scan-deps` arrives at the path by actually running the executable.
+//
+// RUN: EXPECTED_RESOURCE_DIR="/custom/compiler/resources"
+// RUN: echo "#!/bin/sh"  > %t/compiler
+// RUN: echo "echo '$EXPECTED_RESOURCE_DIR'" >> %t/compiler
 // RUN: chmod +x %t/compiler
 // RUN: sed -e "s|CLANG|%/t/compiler|g" -e "s|DIR|%/t|g" \
 // RUN:   %S/Inputs/resource_directory/cdb.json.template > 
%t/cdb_invocation.json
+//
 // RUN: clang-scan-deps -compilation-database %t/cdb_invocation.json --format 
experimental-full \
 // RUN:   --resource-dir-recipe invoke-compiler > %t/result_invocation.json
-// RUN: cat %t/result_invocation.json | sed 's:\?:/:g' | FileCheck %s 
--check-prefix=CHECK-INVOCATION
+// RUN: cat %t/result_invocation.json | sed 's:\?:/:g' \
+// RUN:   | FileCheck %s --check-prefix=CHECK-PATH 
-DEXPECTED_RESOURCE_DIR="$EXPECTED_RESOURCE_DIR"
 // CHECK-INVOCATION:  "-resource-dir"
-// CHECK-INVOCATION-NEXT: "/custom/compiler/resources"
+// CHECK-INVOCATION-NEXT: "[[EXPECTED_RESOURCE_DIR]]"
Index: clang/test/ClangScanDeps/Inputs/resource_directory/compiler
===
--- clang/test/ClangScanDeps/Inputs/resource_directory/compiler
+++ /dev/null
@@ -1,3 +0,0 @@
-#!/bin/sh
-
-echo "/custom/compiler/resources"


Index: clang/test/ClangScanDeps/resource_directory.c
===
--- clang/test/ClangScanDeps/resource_directory.c
+++ clang/test/ClangScanDeps/resource_directory.c
@@ -5,21 +5,42 @@
 
 // Deduce the resource directory from the compiler path.
 //
-// RUN: sed -e "s|CLANG|/our/custom/bin/clang|g" -e "s|DIR|%/t|g" \
+// With `%clang-scan-deps --resource-dir-recipe modify-compiler-path`, the
+// resource directory should be identical to `%clang -print-resource-dir`.
+// (Assuming both binaries are built from the same Git checkout.)
+// Here we get the expected path by running `%clang -print-resource-dir` and
+// then verify `%clang-scan-deps` arrives at the same path by calling the
+// `Driver::GetResourcesPath` function.
+//
+// RUN: EXPECTED_RESOURCE_DIR=`%clang -print-resource-dir`
+// RUN: sed -e "s|CLANG|%clang|g" -e "s|DIR|%/t|g" \
 // RUN:   %S/Inputs/resource_directory/cdb.json.template > %t/cdb_path.json
+//
 // RUN: clang-scan-deps -compilation-database %t/cdb_path.json --format experimental-full \
 // RUN:   --resource-dir-recipe modify-compiler-path > %t/result_path.json
-// RUN: cat %t/result_path.json | sed 's:\?:/:g' | FileCheck %s --check-prefix=CHECK-PAT

[PATCH] D115440: Provide __builtin_alloca*_uninitialized variants

[Marco Elver via Phabricator via cfe-commits]

melver added a subscriber: tstellar.
melver added a comment.

@tstellar , we were told maybe you have some input.

TLDR;

- Clang and GCC appear to behave differently wrt `-ftrivial-auto-var-init=` on 
`__builtin_alloca()` (and VLAs?)
- Clang's behavior is (per @jfb above) correct;
- How to document that better, so that this confusion can be avoided, and GCC 
can match Clang's behaviour.

Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115440

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

[PATCH] D115715: [clang-tidy] Fix llvm-header-guard for Windows paths containing drive letter (e.g. C:).

[Salman Javed via Phabricator via cfe-commits]

salman-javed-nz added inline comments.



Comment at: clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp:57
   std::replace(Guard.begin(), Guard.end(), '-', '_');
+  std::replace(Guard.begin(), Guard.end(), ':', '_');
 

Are there other characters we should be sanitising here?
(Lest keep revisiting this code to add more characters to the list)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115715

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

[PATCH] D115715: [clang-tidy] Fix llvm-header-guard for Windows paths containing drive letter (e.g. C:).

[Salman Javed via Phabricator via cfe-commits]

salman-javed-nz added inline comments.



Comment at: clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp:57
   std::replace(Guard.begin(), Guard.end(), '-', '_');
+  std::replace(Guard.begin(), Guard.end(), ':', '_');
 

salman-javed-nz wrote:
> Are there other characters we should be sanitising here?
> (Lest keep revisiting this code to add more characters to the list)
Typo:
*Lest **we** keep revisiting


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115715

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

[PATCH] D115630: [CodeGen] Require use of Address::invalid() for invalid address

[Nikita Popov 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 rGb8d121eb1d61: [CodeGen] Require use of Address::invalid() 
for invalid address (NFC) (authored by nikic).
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115630

Files:
  clang/lib/CodeGen/Address.h
  clang/lib/CodeGen/CGCall.cpp
  clang/lib/CodeGen/CGCleanup.h
  clang/lib/CodeGen/CGExprAgg.cpp
  clang/lib/CodeGen/CGValue.h

Index: clang/lib/CodeGen/CGValue.h
===
--- clang/lib/CodeGen/CGValue.h
+++ clang/lib/CodeGen/CGValue.h
@@ -470,13 +470,11 @@
 /// An aggregate value slot.
 class AggValueSlot {
   /// The address.
-  llvm::Value *Addr;
+  Address Addr;
 
   // Qualifiers
   Qualifiers Quals;
 
-  unsigned Alignment;
-
   /// DestructedFlag - This is set to true if some external code is
   /// responsible for setting up a destructor for the slot.  Otherwise
   /// the code which constructs it should push the appropriate cleanup.
@@ -520,6 +518,14 @@
   /// them.
   bool SanitizerCheckedFlag : 1;
 
+  AggValueSlot(Address Addr, Qualifiers Quals, bool DestructedFlag,
+   bool ObjCGCFlag, bool ZeroedFlag, bool AliasedFlag,
+   bool OverlapFlag, bool SanitizerCheckedFlag)
+  : Addr(Addr), Quals(Quals), DestructedFlag(DestructedFlag),
+ObjCGCFlag(ObjCGCFlag), ZeroedFlag(ZeroedFlag),
+AliasedFlag(AliasedFlag), OverlapFlag(OverlapFlag),
+SanitizerCheckedFlag(SanitizerCheckedFlag) {}
+
 public:
   enum IsAliased_t { IsNotAliased, IsAliased };
   enum IsDestructed_t { IsNotDestructed, IsDestructed };
@@ -553,22 +559,8 @@
   Overlap_t mayOverlap,
   IsZeroed_t isZeroed = IsNotZeroed,
IsSanitizerChecked_t isChecked = IsNotSanitizerChecked) {
-AggValueSlot AV;
-if (addr.isValid()) {
-  AV.Addr = addr.getPointer();
-  AV.Alignment = addr.getAlignment().getQuantity();
-} else {
-  AV.Addr = nullptr;
-  AV.Alignment = 0;
-}
-AV.Quals = quals;
-AV.DestructedFlag = isDestructed;
-AV.ObjCGCFlag = needsGC;
-AV.ZeroedFlag = isZeroed;
-AV.AliasedFlag = isAliased;
-AV.OverlapFlag = mayOverlap;
-AV.SanitizerCheckedFlag = isChecked;
-return AV;
+return AggValueSlot(addr, quals, isDestructed, needsGC, isZeroed, isAliased,
+mayOverlap, isChecked);
   }
 
   static AggValueSlot
@@ -609,19 +601,19 @@
   }
 
   llvm::Value *getPointer() const {
-return Addr;
+return Addr.getPointer();
   }
 
   Address getAddress() const {
-return Address(Addr, getAlignment());
+return Addr;
   }
 
   bool isIgnored() const {
-return Addr == nullptr;
+return !Addr.isValid();
   }
 
   CharUnits getAlignment() const {
-return CharUnits::fromQuantity(Alignment);
+return Addr.getAlignment();
   }
 
   IsAliased_t isPotentiallyAliased() const {
Index: clang/lib/CodeGen/CGExprAgg.cpp
===
--- clang/lib/CodeGen/CGExprAgg.cpp
+++ clang/lib/CodeGen/CGExprAgg.cpp
@@ -301,7 +301,7 @@
   if (!UseTemp)
 return;
 
-  assert(Dest.getPointer() != Src.getAggregatePointer());
+  assert(Dest.isIgnored() || Dest.getPointer() != Src.getAggregatePointer());
   EmitFinalDestCopy(E->getType(), Src);
 
   if (!RequiresDestruction && LifetimeStartInst) {
Index: clang/lib/CodeGen/CGCleanup.h
===
--- clang/lib/CodeGen/CGCleanup.h
+++ clang/lib/CodeGen/CGCleanup.h
@@ -242,7 +242,7 @@
 
   /// An optional i1 variable indicating whether this cleanup has been
   /// activated yet.
-  llvm::AllocaInst *ActiveFlag;
+  Address ActiveFlag;
 
   /// Extra information required for cleanups that have resolved
   /// branches through them.  This has to be allocated on the side
@@ -290,7 +290,8 @@
  EHScopeStack::stable_iterator enclosingEH)
   : EHScope(EHScope::Cleanup, enclosingEH),
 EnclosingNormal(enclosingNormal), NormalBlock(nullptr),
-ActiveFlag(nullptr), ExtInfo(nullptr), FixupDepth(fixupDepth) {
+ActiveFlag(Address::invalid()), ExtInfo(nullptr),
+FixupDepth(fixupDepth) {
 CleanupBits.IsNormalCleanup = isNormal;
 CleanupBits.IsEHCleanup = isEH;
 CleanupBits.IsActive = true;
@@ -320,13 +321,13 @@
   bool isLifetimeMarker() const { return CleanupBits.IsLifetimeMarker; }
   void setLifetimeMarker() { CleanupBits.IsLifetimeMarker = true; }
 
-  bool hasActiveFlag() const { return ActiveFlag != nullptr; }
+  bool hasActiveFlag() const { return ActiveFlag.isValid(); }
   Address getActiveFlag() const {
-return Address(ActiveFlag, CharUnits::One());
+return ActiveFlag;
   }

[clang] b8d121e - [CodeGen] Require use of Address::invalid() for invalid address (NFC)

[Nikita Popov via cfe-commits]

Author: Nikita Popov
Date: 2021-12-14T12:06:05+01:00
New Revision: b8d121eb1d619adca637bfd926d08a095c93b117

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

LOG: [CodeGen] Require use of Address::invalid() for invalid address (NFC)

This no longer allows creating an invalid Address through the regular
constructor. There were only two places that did this (AggValueSlot
and EHCleanupScope) which did this by converting a potential nullptr
into an Address. I've fixed both of these by directly storing an
Address instead.

This is intended as a bit of preliminary cleanup for D103465.

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

Added: 


Modified: 
clang/lib/CodeGen/Address.h
clang/lib/CodeGen/CGCall.cpp
clang/lib/CodeGen/CGCleanup.h
clang/lib/CodeGen/CGExprAgg.cpp
clang/lib/CodeGen/CGValue.h

Removed: 




diff  --git a/clang/lib/CodeGen/Address.h b/clang/lib/CodeGen/Address.h
index 6a8e57f8db33d..0403a89b8ce61 100644
--- a/clang/lib/CodeGen/Address.h
+++ b/clang/lib/CodeGen/Address.h
@@ -24,14 +24,18 @@ namespace CodeGen {
 class Address {
   llvm::Value *Pointer;
   CharUnits Alignment;
+
+protected:
+  Address(nullptr_t) : Pointer(nullptr) {}
+
 public:
   Address(llvm::Value *pointer, CharUnits alignment)
   : Pointer(pointer), Alignment(alignment) {
-assert((!alignment.isZero() || pointer == nullptr) &&
-   "creating valid address with invalid alignment");
+assert(pointer != nullptr && "Pointer cannot be null");
+assert(!alignment.isZero() && "Alignment cannot be zero");
   }
 
-  static Address invalid() { return Address(nullptr, CharUnits()); }
+  static Address invalid() { return Address(nullptr); }
   bool isValid() const { return Pointer != nullptr; }
 
   llvm::Value *getPointer() const {
@@ -72,12 +76,14 @@ class Address {
 /// A specialization of Address that requires the address to be an
 /// LLVM Constant.
 class ConstantAddress : public Address {
+  ConstantAddress(nullptr_t) : Address(nullptr) {}
+
 public:
   ConstantAddress(llvm::Constant *pointer, CharUnits alignment)
 : Address(pointer, alignment) {}
 
   static ConstantAddress invalid() {
-return ConstantAddress(nullptr, CharUnits());
+return ConstantAddress(nullptr);
   }
 
   llvm::Constant *getPointer() const {

diff  --git a/clang/lib/CodeGen/CGCall.cpp b/clang/lib/CodeGen/CGCall.cpp
index b0b64328b84ed..76d3cffbe6593 100644
--- a/clang/lib/CodeGen/CGCall.cpp
+++ b/clang/lib/CodeGen/CGCall.cpp
@@ -4308,11 +4308,8 @@ void CodeGenFunction::EmitCallArg(CallArgList &args, 
const Expr *E,
   type->castAs()->getDecl()->isParamDestroyedInCallee()) {
 // If we're using inalloca, use the argument memory.  Otherwise, use a
 // temporary.
-AggValueSlot Slot;
-if (args.isUsingInAlloca())
-  Slot = createPlaceholderSlot(*this, type);
-else
-  Slot = CreateAggTemp(type, "agg.tmp");
+AggValueSlot Slot = args.isUsingInAlloca()
+? createPlaceholderSlot(*this, type) : CreateAggTemp(type, "agg.tmp");
 
 bool DestroyedInCallee = true, NeedsEHCleanup = true;
 if (const auto *RD = type->getAsCXXRecordDecl())

diff  --git a/clang/lib/CodeGen/CGCleanup.h b/clang/lib/CodeGen/CGCleanup.h
index 1b54c0018d27c..76f3a48f32f34 100644
--- a/clang/lib/CodeGen/CGCleanup.h
+++ b/clang/lib/CodeGen/CGCleanup.h
@@ -242,7 +242,7 @@ class alignas(8) EHCleanupScope : public EHScope {
 
   /// An optional i1 variable indicating whether this cleanup has been
   /// activated yet.
-  llvm::AllocaInst *ActiveFlag;
+  Address ActiveFlag;
 
   /// Extra information required for cleanups that have resolved
   /// branches through them.  This has to be allocated on the side
@@ -290,7 +290,8 @@ class alignas(8) EHCleanupScope : public EHScope {
  EHScopeStack::stable_iterator enclosingEH)
   : EHScope(EHScope::Cleanup, enclosingEH),
 EnclosingNormal(enclosingNormal), NormalBlock(nullptr),
-ActiveFlag(nullptr), ExtInfo(nullptr), FixupDepth(fixupDepth) {
+ActiveFlag(Address::invalid()), ExtInfo(nullptr),
+FixupDepth(fixupDepth) {
 CleanupBits.IsNormalCleanup = isNormal;
 CleanupBits.IsEHCleanup = isEH;
 CleanupBits.IsActive = true;
@@ -320,13 +321,13 @@ class alignas(8) EHCleanupScope : public EHScope {
   bool isLifetimeMarker() const { return CleanupBits.IsLifetimeMarker; }
   void setLifetimeMarker() { CleanupBits.IsLifetimeMarker = true; }
 
-  bool hasActiveFlag() const { return ActiveFlag != nullptr; }
+  bool hasActiveFlag() const { return ActiveFlag.isValid(); }
   Address getActiveFlag() const {
-return Address(ActiveFlag, CharUnits::One());
+return ActiveFlag;
   }
   void setActiveFlag(Address Var) {
 assert(Var.getAlignment().isOne());
-ActiveFlag = ca

[PATCH] D115715: [clang-tidy] Fix llvm-header-guard for Windows paths containing drive letter (e.g. C:).

[Marek Kurdej via Phabricator via cfe-commits]

curdeius added a comment.

In D115715#3191742 , @sberg wrote:

>> So the check, for a file called e.g. "C:\test\test.h" would suggest the 
>> guard C:_TEST_TEST_H being an invalid name due to the presence of the colon.
>
> ...though the new suggestion `C__TEST_TEST_H` isn't ideal either, in that it 
> uses an identifier that is reserved for the implementation (due to the double 
> underscore)

Indeed, I hadn't thought about it. We *might* change all `__+` into a single 
`_`, but that seems an overkill to me (or at least something for another patch).
Also, the problem is not limited to `:`. A file could be named `a--b.h` and it 
would get a guard `A__B_H` with a double underscore.

In D115715#3191767 , @salman-javed-nz 
wrote:

> The problem at the heart of all this is that llvm-header-guard isn't written 
> flexible enough to support non-LLVM project structures.

I know, but this check is still useful outside of LLVM.
From my point of view, there's not much missing flexibility to use it outside 
LLVM (for basic stuff), only such small edge cases like this one.
Of course, one would wish to be able to set "root" names other than 
"llvm-project" and so on, but that's out of scope here.

> Edit: I'm assume you're seeing this problem outside of the LLVM project?

Yes, in the bug report, it is used outside of LLVM.




Comment at: clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp:57
   std::replace(Guard.begin(), Guard.end(), '-', '_');
+  std::replace(Guard.begin(), Guard.end(), ':', '_');
 

salman-javed-nz wrote:
> salman-javed-nz wrote:
> > Are there other characters we should be sanitising here?
> > (Lest keep revisiting this code to add more characters to the list)
> Typo:
> *Lest **we** keep revisiting
Well, difficult to say. On Windows, there are pretty many allowed characters in 
filenames, but I don't think we should care about it.
I think we should just care about what is sometimes called "POSIX Fully 
portable filenames" (which contains: A-Z a-z 0-9 . _ -).
Colon `:` is special (similarly to slashes `/` and `\`) as it may appear in the 
path.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115715

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

[clang] b81450a - [CodeGen] Add std:: qualifier

[Nikita Popov via cfe-commits]

Author: Nikita Popov
Date: 2021-12-14T12:17:55+01:00
New Revision: b81450afb6529cd4d1eece46e9945caa5de51c11

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

LOG: [CodeGen] Add std:: qualifier

Hopefully addresses the buildbot failures.

Added: 


Modified: 
clang/lib/CodeGen/Address.h

Removed: 




diff  --git a/clang/lib/CodeGen/Address.h b/clang/lib/CodeGen/Address.h
index 0403a89b8ce6..2196c6bf1161 100644
--- a/clang/lib/CodeGen/Address.h
+++ b/clang/lib/CodeGen/Address.h
@@ -26,7 +26,7 @@ class Address {
   CharUnits Alignment;
 
 protected:
-  Address(nullptr_t) : Pointer(nullptr) {}
+  Address(std::nullptr_t) : Pointer(nullptr) {}
 
 public:
   Address(llvm::Value *pointer, CharUnits alignment)
@@ -76,7 +76,7 @@ class Address {
 /// A specialization of Address that requires the address to be an
 /// LLVM Constant.
 class ConstantAddress : public Address {
-  ConstantAddress(nullptr_t) : Address(nullptr) {}
+  ConstantAddress(std::nullptr_t) : Address(nullptr) {}
 
 public:
   ConstantAddress(llvm::Constant *pointer, CharUnits alignment)



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

[PATCH] D115566: Quote some more destination paths with variables

[John Ericson 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 rGddcc02dbcc47: Quote some more destination paths with 
variables (authored by Ericson2314).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115566

Files:
  clang/tools/scan-build/CMakeLists.txt
  libclc/CMakeLists.txt
  libcxx/include/CMakeLists.txt
  lldb/cmake/modules/FindLibEdit.cmake
  llvm/cmake/modules/AddSphinxTarget.cmake
  openmp/runtime/src/CMakeLists.txt

Index: openmp/runtime/src/CMakeLists.txt
===
--- openmp/runtime/src/CMakeLists.txt
+++ openmp/runtime/src/CMakeLists.txt
@@ -358,9 +358,9 @@
   set(LIBOMP_ALIASES "libiomp5md")
   foreach(alias IN LISTS LIBOMP_ALIASES)
 install(CODE "execute_process(COMMAND \"\${CMAKE_COMMAND}\" -E copy \"${LIBOMP_LIB_FILE}\"
-  \"${alias}${LIBOMP_LIBRARY_SUFFIX}\" WORKING_DIRECTORY \${CMAKE_INSTALL_PREFIX}/bin)")
+  \"${alias}${LIBOMP_LIBRARY_SUFFIX}\" WORKING_DIRECTORY \"\${CMAKE_INSTALL_PREFIX}/bin\")")
 install(CODE "execute_process(COMMAND \"\${CMAKE_COMMAND}\" -E copy \"${LIBOMP_IMP_LIB_FILE}\"
-  \"${alias}${CMAKE_STATIC_LIBRARY_SUFFIX}\" WORKING_DIRECTORY \${CMAKE_INSTALL_PREFIX}/${OPENMP_INSTALL_LIBDIR})")
+  \"${alias}${CMAKE_STATIC_LIBRARY_SUFFIX}\" WORKING_DIRECTORY \"\${CMAKE_INSTALL_PREFIX}/${OPENMP_INSTALL_LIBDIR}\")")
   endforeach()
 else()
 
@@ -372,7 +372,7 @@
 foreach(alias IN LISTS LIBOMP_ALIASES)
   install(CODE "execute_process(COMMAND \"\${CMAKE_COMMAND}\" -E create_symlink \"${LIBOMP_LIB_FILE}\"
 \"${alias}${LIBOMP_LIBRARY_SUFFIX}\" WORKING_DIRECTORY
-\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/${OPENMP_INSTALL_LIBDIR})")
+\"\$ENV{DESTDIR}\${CMAKE_INSTALL_PREFIX}/${OPENMP_INSTALL_LIBDIR}\")")
 endforeach()
   endif()
 endif()
Index: llvm/cmake/modules/AddSphinxTarget.cmake
===
--- llvm/cmake/modules/AddSphinxTarget.cmake
+++ llvm/cmake/modules/AddSphinxTarget.cmake
@@ -74,7 +74,7 @@
 if (NOT LLVM_INSTALL_TOOLCHAIN_ONLY)
   if (builder STREQUAL man)
 if (CMAKE_INSTALL_MANDIR)
-  set(INSTALL_MANDIR ${CMAKE_INSTALL_MANDIR}/)
+  set(INSTALL_MANDIR "${CMAKE_INSTALL_MANDIR}/")
 else()
   set(INSTALL_MANDIR share/man/)
 endif()
Index: lldb/cmake/modules/FindLibEdit.cmake
===
--- lldb/cmake/modules/FindLibEdit.cmake
+++ lldb/cmake/modules/FindLibEdit.cmake
@@ -25,14 +25,14 @@
 HINTS
   ${PC_LIBEDIT_INCLUDEDIR}
   ${PC_LIBEDIT_INCLUDE_DIRS}
-  ${CMAKE_INSTALL_FULL_INCLUDEDIR})
+  "${CMAKE_INSTALL_FULL_INCLUDEDIR}")
   find_library(LibEdit_LIBRARIES
NAMES
  edit libedit
HINTS
  ${PC_LIBEDIT_LIBDIR}
  ${PC_LIBEDIT_LIBRARY_DIRS}
- ${CMAKE_INSTALL_FULL_LIBDIR})
+ "${CMAKE_INSTALL_FULL_LIBDIR}")
 
   if(LibEdit_INCLUDE_DIRS AND EXISTS "${LibEdit_INCLUDE_DIRS}/histedit.h")
 file(STRINGS "${LibEdit_INCLUDE_DIRS}/histedit.h"
Index: libcxx/include/CMakeLists.txt
===
--- libcxx/include/CMakeLists.txt
+++ libcxx/include/CMakeLists.txt
@@ -531,7 +531,7 @@
   foreach(file ${files})
 get_filename_component(dir ${file} DIRECTORY)
 install(FILES ${file}
-  DESTINATION ${LIBCXX_INSTALL_INCLUDE_DIR}/${dir}
+  DESTINATION "${LIBCXX_INSTALL_INCLUDE_DIR}/${dir}"
   COMPONENT cxx-headers
   PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
 )
@@ -539,7 +539,7 @@
 
   # Install the generated __config_site.
   install(FILES ${LIBCXX_GENERATED_INCLUDE_TARGET_DIR}/__config_site
-DESTINATION ${LIBCXX_INSTALL_INCLUDE_TARGET_DIR}
+DESTINATION "${LIBCXX_INSTALL_INCLUDE_TARGET_DIR}"
 PERMISSIONS OWNER_READ OWNER_WRITE GROUP_READ WORLD_READ
 COMPONENT cxx-headers)
 
Index: libclc/CMakeLists.txt
===
--- libclc/CMakeLists.txt
+++ libclc/CMakeLists.txt
@@ -183,8 +183,8 @@
 
 # pkg-config file
 configure_file( libclc.pc.in libclc.pc @ONLY )
-install( FILES ${CMAKE_CURRENT_BINARY_DIR}/libclc.pc DESTINATION ${CMAKE_INSTALL_DATADIR}/pkgconfig )
-install( DIRECTORY generic/include/clc DESTINATION ${CMAKE_INSTALL_INCLUDEDIR} )
+install( FILES ${CMAKE_CURRENT_BINARY_DIR}/libclc.pc DESTINATION "${CMAKE_INSTALL_DATADIR}/pkgconfig" )
+install( DIRECTORY generic/include/clc DESTINATION "${CMAKE_INSTALL_INCLUDEDIR}" )
 
 if( ENABLE_RUNTIME_SUBNORMAL )
 	add_library( subnormal_use_default STATIC
@@ -192,7 +192,7 @@
 	add_library( subnormal_disable STATIC
 		generic/lib/subnormal_disable.ll )
 	install( TARGETS subnorm

Re: [clang] 9791b58 - [C++20 Modules] Don't create global module fragment for extern linkage declaration in GMF already

[chuanqi.xcq via cfe-commits]

Hi Richard,

   Sorry for disturbing. I sent https://reviews.llvm.org/D115610 to try to fix 
this. 

BTW, the example you posted might not work with libstdc++, here is a bug I 
reported: https://github.com/llvm/llvm-project/issues/51873

Thanks,
Chuanqi



--
From:chuanqi.xcq 
Send Time:2021年12月13日(星期一) 10:14
To:Chuanqi Xu ; Richard Smith 
Cc:cfe-commits 
Subject:Re: [clang] 9791b58 - [C++20 Modules] Don't create global module 
fragment for extern linkage declaration in GMF already

Hi Richard,

Thanks for reporting this! I found the reason that why it didn't get tested 
previously is that we didn't use `extern "C"/"C++"` actually since we 
implemented partitions internally. Sorry for confusing. I would try to work on 
it.

Thanks,
Chuanqi

--
From:Richard Smith 
Send Time:2021年12月11日(星期六) 08:28
To:Chuanqi Xu ; Chuanqi Xu 
Cc:cfe-commits 
Subject:Re: [clang] 9791b58 - [C++20 Modules] Don't create global module 
fragment for extern linkage declaration in GMF already

On Wed, 8 Dec 2021 at 21:56, Chuanqi Xu via cfe-commits 
 wrote:

 Author: Chuanqi Xu
 Date: 2021-12-09T13:55:15+08:00
 New Revision: 9791b589516b644a6273607b46a9c6661993d667

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

 LOG: [C++20 Modules] Don't create global module fragment for extern linkage 
declaration in GMF already

 Previously we would create global module fragment for extern linkage
 declaration which is alreday in global module fragment. However, it is
 clearly redundant to do so. This patch would check if the extern linkage
 declaration are already in GMF before we create a GMF for it.

I'm still seeing some problems even after this patch -- linkage spec 
declarations within the purview of the module still create new global module 
fragments, and then the serialization code seems to sometimes get confused 
because we have multiple submodules with the same name "". Perhaps we 
should reuse an existing global module fragment if there is one, even when 
inside the purview of the module?

Here's an example end-to-end testcase for which I'm seeing an assertion 
failure; I've not got a reduced testcase yet:

$ cat say_hello.cppm
module;
#include 
#include 
export module Hello;
export void SayHello
  (std::string_view const &name)
{
  std::cout << "Hello " << name << "!\n";
}

$ cat hello.cpp
#include 
import Hello;
int main() {
  SayHello("world");
  return 0;
}

$ ./build/bin/clang++ say_hello.cppm --precompile -o say_hello.pcm -std=c++20
$ ./build/bin/clang++ say_hello.cppm hello.cpp -fmodule-file=say_hello.pcm 
-std=c++20

 Added: 
 clang/test/CXX/module/module.unit/p7/Inputs/h7.h
 clang/test/CXX/module/module.unit/p7/t7.cpp

 Modified: 
 clang/include/clang/Sema/Sema.h
 clang/lib/Sema/SemaDeclCXX.cpp

 Removed: 



 

 diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
 index a12dd4db66c13..73c5ad1dd7acf 100644
 --- a/clang/include/clang/Sema/Sema.h
 +++ b/clang/include/clang/Sema/Sema.h
 @@ -,6 +,12 @@ class Sema final {
  return ModuleScopes.empty() ? nullptr : ModuleScopes.back().Module;
}

 +  /// Helper function to judge if we are in module purview.
 +  /// Return false if we are not in a module.
 +  bool isCurrentModulePurview() const {
 +return getCurrentModule() ? getCurrentModule()->isModulePurview() : false;
 +  }
 +
/// Enter the scope of the global module.
Module *PushGlobalModuleFragment(SourceLocation BeginLoc, bool IsImplicit);
/// Leave the scope of the global module.

 diff  --git a/clang/lib/Sema/SemaDeclCXX.cpp b/clang/lib/Sema/SemaDeclCXX.cpp
 index 4a0eda2a700fe..3f6bde1b9ed6a 100644
 --- a/clang/lib/Sema/SemaDeclCXX.cpp
 +++ b/clang/lib/Sema/SemaDeclCXX.cpp
 @@ -16153,7 +16153,10 @@ Decl *Sema::ActOnStartLinkageSpecification(Scope *S, 
SourceLocation ExternLoc,
///   - ...
///   - appears within a linkage-specification,
///   it is attached to the global module.
 -  if (getLangOpts().CPlusPlusModules && getCurrentModule()) {
 +  ///
 +  /// If the declaration is already in global module fragment, we don't
 +  /// need to attach it again.
 +  if (getLangOpts().CPlusPlusModules && isCurrentModulePurview()) {
  Module *GlobalModule =
  PushGlobalModuleFragment(ExternLoc, /*IsImplicit=*/true);
  D->setModuleOwnershipKind(Decl::ModuleOwnershipKind::ModulePrivate);
 @@ -16177,7 +16180,11 @@ Decl *Sema::ActOnFinishLinkageSpecification(Scope *S,
  LSDecl->setRBraceLoc(RBraceLoc);
}

 -  if (getLangOpts().CPlusPlusModules && getCurrentModule())
 +  // If the current module doesn't has Parent, it implies that the
 +  // LinkageSpec isn't in the module created 

[PATCH] D115425: [clangd] Generate ConfigFragment/YAML/docs from one tablegen source

[Sam McCall via Phabricator via cfe-commits]

sammccall added a comment.

In D115425#3190740 , @nridge wrote:

> In D115425#3190698 , @sammccall 
> wrote:
>
>>> there's perhaps a matter of principle where clangd should try to avoid 
>>> using code patterns (here, non-self-contained files) in its implementation 
>>> code that it does not support
>>
>> Agree. However the counterargument is putting such patterns in front of our 
>> face all the time might encourage us to add some level of support!
>
> Apologies if this is veering off topic (we can continue in a Github 
> Discussion if you'd like), but I got the impression that clangd's lack of 
> support for non-self-contained files was at least partly an opinionated 
> statement that code patterns involving such files are not an important part 
> of modern C++ development.

I think "at least partly" is fair. But this is more a statement of priorities 
and effort - I think if the feature were free or cheap, everyone would be happy 
to have it.

(FWIW I do find LLVM's reliance on preprocessor tricks to be not great. Between 
wanting to fit in with existing infrastructure, and not being able to easily 
add dependencies, it doesn't seem worth fighting. But this is just another way 
to say "sure, there are circumstances where it's reasonable to use such 
patterns")

> If that impression is mistaken, and it's just a matter of no one having 
> gotten around to implementing such support

It's definitely more than implementation, the design needs to solve some hard 
constraints:

- There needs to be a clear scope and idea of how it'll solve the problems. For 
instance:
  - does it support files with parse context (e.g. snippets of class bodies 
like ConfigFragment.inc), or just PP context? If parse context, how is this 
persisted or recreated? (PCH can't do this today). How does this interact with 
preambles?
  - how is the file-that-provides-context identified? Is the existing index 
actually good/available enough for this?
- it needs to not add _too much_ complexity, or at least isolate the complexity 
to a few places. "Priorities and effort" also means this can't become a 
maintenance timesink.
- it needs to be useful/powerful enough to justify the complexity that adds. 
(This ~certainly means it needs to be safe to turn on by default eventually)

I'm not certain it's possible to satisfy all these, but it seems like it might 
be possible.

> perhaps we could clarify that in https://github.com/clangd/clangd/issues/45 
> (and maybe put out a "help wanted" / "contributions welcome" announcement 
> somewhere)?

Agreed. I'll post a version of this here.
I'm a little worried that people will expect that if someone makes an honest 
attempt and gets anywhere then it'll be merged. But I should be less paranoid.
I'm also aware that I & others haven't been a model of working on designs 
collaboratively in public, we're pretty reliant on getting in a room. So it may 
be unfair to expect others to do better.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115425

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

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

[Florian Hahn via Phabricator via cfe-commits]

fhahn added a comment.

ping :)

Any additional thoughts? Since the original concerns were raised both 
@manojgupta  and myself tried to share a bit of additional background on the 
motivation and to clarify the difference between `-mXXX` and `-march`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113779

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

[PATCH] D115630: [CodeGen] Require use of Address::invalid() for invalid address

[Bing Yu via Phabricator via cfe-commits]

yubing added inline comments.



Comment at: clang/lib/CodeGen/Address.h:79
 class ConstantAddress : public Address {
+  ConstantAddress(nullptr_t) : Address(nullptr) {}
+

Has anyone encountered buildfail due to missing "std" before nullptr_t?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115630

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

[PATCH] D110618: [HIPSPV][2/4] Add HIPSPV tool chain

[Henry Linjamäki via Phabricator via cfe-commits]

linjamaki updated this revision to Diff 394208.
linjamaki added a comment.

Rebase.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110618

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/lib/Driver/ToolChains/HIPSPV.cpp
  clang/lib/Driver/ToolChains/HIPSPV.h

Index: clang/lib/Driver/ToolChains/HIPSPV.h
===
--- /dev/null
+++ clang/lib/Driver/ToolChains/HIPSPV.h
@@ -0,0 +1,103 @@
+//===--- HIPSPV.h - HIP ToolChain Implementations ---*- C++ -*-===//
+//
+// 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
+//
+//===--===//
+
+#ifndef LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_HIPSPV_H
+#define LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_HIPSPV_H
+
+#include "SPIRV.h"
+#include "clang/Driver/Tool.h"
+#include "clang/Driver/ToolChain.h"
+
+namespace clang {
+namespace driver {
+namespace tools {
+namespace HIPSPV {
+
+// Runs llvm-link/opt/llc/lld, which links multiple LLVM bitcode, together with
+// device library, then compiles it to SPIR-V in a shared object.
+class LLVM_LIBRARY_VISIBILITY Linker : public Tool {
+public:
+  Linker(const ToolChain &TC) : Tool("HIPSPV::Linker", "hipspv-link", TC) {}
+
+  bool hasIntegratedCPP() const override { return false; }
+
+  void ConstructJob(Compilation &C, const JobAction &JA,
+const InputInfo &Output, const InputInfoList &Inputs,
+const llvm::opt::ArgList &TCArgs,
+const char *LinkingOutput) const override;
+
+private:
+  void constructLinkAndEmitSpirvCommand(Compilation &C, const JobAction &JA,
+const InputInfoList &Inputs,
+const InputInfo &Output,
+const llvm::opt::ArgList &Args) const;
+};
+
+} // namespace HIPSPV
+} // namespace tools
+
+namespace toolchains {
+
+class LLVM_LIBRARY_VISIBILITY HIPSPVToolChain final : public ToolChain {
+public:
+  HIPSPVToolChain(const Driver &D, const llvm::Triple &Triple,
+  const ToolChain &HostTC, const llvm::opt::ArgList &Args);
+
+  const llvm::Triple *getAuxTriple() const override {
+return &HostTC.getTriple();
+  }
+
+  void
+  addClangTargetOptions(const llvm::opt::ArgList &DriverArgs,
+llvm::opt::ArgStringList &CC1Args,
+Action::OffloadKind DeviceOffloadKind) const override;
+  void addClangWarningOptions(llvm::opt::ArgStringList &CC1Args) const override;
+  CXXStdlibType GetCXXStdlibType(const llvm::opt::ArgList &Args) const override;
+  void
+  AddClangSystemIncludeArgs(const llvm::opt::ArgList &DriverArgs,
+llvm::opt::ArgStringList &CC1Args) const override;
+  void AddClangCXXStdlibIncludeArgs(
+  const llvm::opt::ArgList &Args,
+  llvm::opt::ArgStringList &CC1Args) const override;
+  void AddIAMCUIncludeArgs(const llvm::opt::ArgList &DriverArgs,
+   llvm::opt::ArgStringList &CC1Args) const override;
+  void AddHIPIncludeArgs(const llvm::opt::ArgList &DriverArgs,
+ llvm::opt::ArgStringList &CC1Args) const override;
+  llvm::SmallVector
+  getHIPDeviceLibs(const llvm::opt::ArgList &Args) const override;
+
+  SanitizerMask getSupportedSanitizers() const override;
+
+  VersionTuple
+  computeMSVCVersion(const Driver *D,
+ const llvm::opt::ArgList &Args) const override;
+
+  void adjustDebugInfoKind(codegenoptions::DebugInfoKind &DebugInfoKind,
+   const llvm::opt::ArgList &Args) const override;
+  bool IsIntegratedAssemblerDefault() const override { return true; }
+  bool IsMathErrnoDefault() const override { return false; }
+  bool useIntegratedAs() const override { return true; }
+  bool isCrossCompiling() const override { return true; }
+  bool isPICDefault() const override { return false; }
+  bool isPIEDefault(const llvm::opt::ArgList &Args) const override {
+return false;
+  }
+  bool isPICDefaultForced() const override { return false; }
+  bool SupportsProfiling() const override { return false; }
+
+  const ToolChain &HostTC;
+
+protected:
+  Tool *buildLinker() const override;
+};
+
+} // end namespace toolchains
+} // end namespace driver
+} // end namespace clang
+
+#endif // LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_HIPSPV_H
Index: clang/lib/Driver/ToolChains/HIPSPV.cpp
===
--- /dev/null
+++ clang/lib/Driver/ToolChains/HIPSPV.cpp
@@ -0,0 +1,292 @@
+//===--- HIPSPV.cpp - HIPSPV ToolChain Implement

[PATCH] D115673: [clang-format] C# switch expression formatting differs from normal switch formatting

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

In D115673#3191408 , @curdeius wrote:

> LGTM. AFAIK (which is very limited when it comes to C#), the cases can have 
> also other expressions, not only ints and _. But that can be left for a 
> different patch.
> Example from 
> https://docs.microsoft.com/en-us/dotnet/csharp/fundamentals/functional/pattern-matching
>
>   public State PerformOperation(Operation command) =>
>  command switch
>  {
>  Operation.SystemTest => RunDiagnostics(),
>  Operation.Start => StartSystem(),
>  Operation.Stop => StopSystem(),
>  Operation.Reset => ResetToReady(),
>  _ => throw new ArgumentException("Invalid enum value for command", 
> nameof(command)),
>  };

I thought that would be the case but actually I tried a load from the Microsoft 
docs and most where good, it seems to be the numerical ones that seems to be 
struggling.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115673

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

[PATCH] D115630: [CodeGen] Require use of Address::invalid() for invalid address

[Nikita Popov via Phabricator via cfe-commits]

nikic added inline comments.



Comment at: clang/lib/CodeGen/Address.h:79
 class ConstantAddress : public Address {
+  ConstantAddress(nullptr_t) : Address(nullptr) {}
+

yubing wrote:
> Has anyone encountered buildfail due to missing "std" before nullptr_t?
Yeah, this broke a lot of buildbots and should be fixed by 
https://github.com/llvm/llvm-project/commit/b81450afb6529cd4d1eece46e9945caa5de51c11.
 Please tell me if you still see a build failure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115630

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

[PATCH] D113779: [Clang] Add mfp16, mfp16fml and mdotprod flags for ARM target features.

[Sjoerd Meijer via Phabricator via cfe-commits]

SjoerdMeijer added a comment.

Ok, fair enough, perhaps adding features is a valid use-case.

I will refrain from commenting on "things are terribly broken".  I agree it is 
broken, but in a different way than suggested in previous comments. 
If others also think this makes sense, then here a few follow up remarks from 
my side:

- First of all, this (really) sets precedent for setting options in a different 
way. This needs documentation and release noting.
- If we are going to do this, this should be the first patch in a series to fix 
this for all features. We can't just do a few of them.
- There was a suggestion to allow adding features with -march=+feature. Was 
this dismissed in favour of how things works for x86 and be consistent with 
that?
- It would be really good if we keep options consistent/compatible across the 
GCC and Clang toolchains. Any possibility to check with GCC community if they 
are open for this?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113779

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

[PATCH] D110618: [HIPSPV][2/4] Add HIPSPV tool chain

[Henry Linjamäki via Phabricator via cfe-commits]

linjamaki added a comment.

This patch should be ready to land. @tra, could you please commit this to the 
LLVM for us. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110618

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

[PATCH] D113237: [RISCV] Support I extension version 2.1

[Alex Bradbury via Phabricator via cfe-commits]

asb added a comment.

@kito-cheng

In D113237#3183969 , @kito-cheng 
wrote:

> Here is a long discussion[1] at 2019, at that moment I think we all agree 
> -misa-spec is a good solution,
>
> However it's kind of awkward for this scheme is ISA spec changing the version 
> scheme again after `20191213` release,
> it's become NO formal release for long time, just bunch of draft release.
>
> That's means NO `-misa-spec` version can cover vector, crypto and bit 
> manipulation.

Thanks for writing all of that up Kito.

I just wanted to check my understanding on this point. It's certainly true that 
there hasn't been a new ISA manual release for a long time. Are you saying that 
there won't be a new ISA manual release (using whatever naming scheme) that 
incorporates the ratified versions of bitmanip, crypto, vector etc?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113237

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

[PATCH] D113107: Support of expression granularity for _Float16.

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam updated this revision to Diff 394224.

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

https://reviews.llvm.org/D113107

Files:
  clang/docs/LanguageExtensions.rst
  clang/docs/ReleaseNotes.rst
  clang/lib/Basic/Targets/X86.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/CodeGen/X86/Float16-arithmetic.c
  clang/test/CodeGen/X86/avx512fp16-abi.c
  clang/test/CodeGen/X86/avx512fp16-complex-abi.c
  clang/test/CodeGen/X86/avx512fp16-complex.c
  clang/test/CodeGen/X86/fp16-abi.c
  clang/test/CodeGen/X86/fp16-complex-abi.c
  clang/test/CodeGen/X86/fp16-complex.c
  clang/test/Sema/Float16.c
  clang/test/Sema/conversion-target-dep.c
  clang/test/SemaCXX/Float16.cpp

Index: clang/test/SemaCXX/Float16.cpp
===
--- clang/test/SemaCXX/Float16.cpp
+++ clang/test/SemaCXX/Float16.cpp
@@ -1,7 +1,8 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s -DHAVE
 // RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
 // RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
 // RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple i386-pc-linux-gnu %s
 
 #ifdef HAVE
 // expected-no-diagnostics
Index: clang/test/Sema/conversion-target-dep.c
===
--- clang/test/Sema/conversion-target-dep.c
+++ clang/test/Sema/conversion-target-dep.c
@@ -6,7 +6,7 @@
 
 long double ld;
 double d;
-_Float16 f16; // x86-error {{_Float16 is not supported on this target}}
+_Float16 f16;
 
 int main() {
   ld = d; // x86-warning {{implicit conversion increases floating-point precision: 'double' to 'long double'}}
Index: clang/test/Sema/Float16.c
===
--- clang/test/Sema/Float16.c
+++ clang/test/Sema/Float16.c
@@ -1,8 +1,9 @@
-// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s
+// RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc %s  -DHAVE
 // RUN: %clang_cc1 -fsyntax-only -verify -triple x86_64-linux-pc -target-feature +avx512fp16 %s -DHAVE
 // RUN: %clang_cc1 -fsyntax-only -verify -triple spir-unknown-unknown %s -DHAVE
 // RUN: %clang_cc1 -fsyntax-only -verify -triple armv7a-linux-gnu %s -DHAVE
 // RUN: %clang_cc1 -fsyntax-only -verify -triple aarch64-linux-gnu %s -DHAVE
+// RUN: %clang_cc1 -fsyntax-only -verify -triple i386-pc-linux-gnu %s
 
 #ifndef HAVE
 // expected-error@+2{{_Float16 is not supported on this target}}
Index: clang/test/CodeGen/X86/fp16-complex.c
===
--- clang/test/CodeGen/X86/fp16-complex.c
+++ clang/test/CodeGen/X86/fp16-complex.c
@@ -1,4 +1,5 @@
 // RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -target-feature +avx512fp16 -o - | FileCheck %s --check-prefix=X86
+// RUN: %clang_cc1 %s -O0 -emit-llvm -triple x86_64-unknown-unknown -o - | FileCheck %s --check-prefixes=X86
 
 _Float16 _Complex add_half_rr(_Float16 a, _Float16 b) {
   // X86-LABEL: @add_half_rr(
Index: clang/test/CodeGen/X86/fp16-abi.c
===
--- clang/test/CodeGen/X86/fp16-abi.c
+++ clang/test/CodeGen/X86/fp16-abi.c
@@ -1,5 +1,7 @@
 // RUN: %clang_cc1 -triple x86_64-linux -emit-llvm  -target-feature +avx512fp16 < %s | FileCheck %s --check-prefixes=CHECK,CHECK-C
+// RUN: %clang_cc1 -triple x86_64-linux -emit-llvm  < %s | FileCheck %s --check-prefixes=CHECK,CHECK-C
 // RUN: %clang_cc1 -triple x86_64-linux -emit-llvm  -target-feature +avx512fp16 -x c++ -std=c++11 < %s | FileCheck %s --check-prefixes=CHECK,CHECK-CPP
+// RUN: %clang_cc1 -triple x86_64-linux -emit-llvm -x c++ -std=c++11 < %s | FileCheck %s --check-prefixes=CHECK,CHECK-CPP
 
 struct half1 {
   _Float16 a;
Index: clang/test/CodeGen/X86/Float16-arithmetic.c
===
--- /dev/null
+++ clang/test/CodeGen/X86/Float16-arithmetic.c
@@ -0,0 +1,71 @@
+// RUN: %clang_cc1 -triple  x86_64-unknown-unknown -emit-llvm  \
+// RUN: < %s  | FileCheck %s --check-prefixes=CHECK
+
+_Float16 add1(_Float16 a, _Float16 b) {
+  // CHECK-LABEL: define {{.*}} half @add1
+  // CHECK: alloca half
+  // CHECK: alloca half
+  // CHECK: store half {{.*}}, half*
+  // CHECK: store half {{.*}}, half*
+  // CHECK: load half, half*
+  // CHECK: fpext half {{.*}} to float
+  // CHECK: load half, half* {{.*}}
+  // CHECK: fpext half {{.*}} to float
+  // CHECK: fadd float {{.*}}, {{.*}}
+  // CHECK: fptrunc float {{.*}} to half
+  // CHECK: ret half
+  return a + b;
+}
+
+_Float16 add2(_Float16 a, _Float16 b, _Float16 c) {
+  // CHECK-LABEL: define dso_local half @add2
+  // CHECK: alloca half
+  // CHECK: alloca half
+  // CHECK: alloca half
+  // CHECK: store half {{.*}}, half*
+  // CHECK: store half {{.*

[PATCH] D108560: [clang-tidy] Add support for `NOLINTBEGIN` ... `NOLINTEND` comments

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

Hi @salman-javed-nz !

Thanks for the great work and working on the performance improvements. Just 
FYI, we are also disabling this in clangd's clang-tidy integration as it is 
increasing the latency of diagnostic generation.
It would be great if you also provided some updates to the call-sites once your 
performance fix lands. See https://reviews.llvm.org/D115650 for an example.

Also I am not sure what kind of timelines you have in mind for the performance 
improvements, but I think it would be great to have them before LLVM-14 
release, as otherwise we might have some (extra) discrepancies between 
clang-tidy CLI vs clangd integration, which would be unfortunate.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108560

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

[PATCH] D115715: [clang-tidy] Fix llvm-header-guard for Windows paths containing drive letter (e.g. C:).

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D115715#3191842 , @curdeius wrote:

> In D115715#3191742 , @sberg wrote:
>
>>> So the check, for a file called e.g. "C:\test\test.h" would suggest the 
>>> guard C:_TEST_TEST_H being an invalid name due to the presence of the colon.
>>
>> ...though the new suggestion `C__TEST_TEST_H` isn't ideal either, in that it 
>> uses an identifier that is reserved for the implementation (due to the 
>> double underscore)
>
> Indeed, I hadn't thought about it. We *might* change all `__+` into a single 
> `_`, but that seems an overkill to me (or at least something for another 
> patch).

Fixit suggestions should not produce incorrect code and double underscores will 
introduce undefined behavior in C++ code.

> In D115715#3191767 , 
> @salman-javed-nz wrote:
>
>> The problem at the heart of all this is that llvm-header-guard isn't written 
>> flexible enough to support non-LLVM project structures.
>
> I know, but this check is still useful outside of LLVM.

It could be made to be useful outside of LLVM, but as it stands today, the 
check is only intended to be useful for LLVM. If we want to make it useful 
outside of LLVM, that's fine, but there's a bit more to do (for example, the 
check should be exposed outside of the `llvm` module) and that includes 
generalizing the check.




Comment at: clang-tools-extra/clang-tidy/llvm/HeaderGuardCheck.cpp:57
   std::replace(Guard.begin(), Guard.end(), '-', '_');
+  std::replace(Guard.begin(), Guard.end(), ':', '_');
 

curdeius wrote:
> salman-javed-nz wrote:
> > salman-javed-nz wrote:
> > > Are there other characters we should be sanitising here?
> > > (Lest keep revisiting this code to add more characters to the list)
> > Typo:
> > *Lest **we** keep revisiting
> Well, difficult to say. On Windows, there are pretty many allowed characters 
> in filenames, but I don't think we should care about it.
> I think we should just care about what is sometimes called "POSIX Fully 
> portable filenames" (which contains: A-Z a-z 0-9 . _ -).
> Colon `:` is special (similarly to slashes `/` and `\`) as it may appear in 
> the path.
Huh, I thought we had covered colons as part of the previous review -- sorry 
for missing that! FWIW, there are other characters that may appear as part of a 
path. `/` and `\` are both path separators, but `?` can appear in file 
namespace paths (which means `.` can then appear as part of the file name 
rather than a separator).

> I think we should just care about what is sometimes called "POSIX Fully 
> portable filenames" (which contains: A-Z a-z 0-9 . _ -)

I'd be pretty opposed to anything that takes non-ASCII characters and converts 
them to `_` as that will wind up with header guards like `` for some 
users.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115715

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

[PATCH] D115650: [clangd] Disable support for clang-tidy suppression blocks (NOLINTBEGIN)

[Kadir Cetinkaya via Phabricator via cfe-commits]

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

I am a little worried about the discrepancy we'll get here, but (un)fortunately 
it won't be the first with clang-tidy.

Also gave the author a headsup in https://reviews.llvm.org/D108560#3192081, 
looks like they're already working on some improvements. Let's hope that we can 
have this landed with LLVM-14 otherwise I think we should also document this in 
https://clangd.llvm.org/features#clang-tidy-checks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115650

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

[PATCH] D115670: Correct behavior of Vector boolean-operations, implement vector operator-

[Erich Keane via Phabricator via cfe-commits]

erichkeane updated this revision to Diff 394230.
erichkeane added a comment.

Enable __int128 vectors, and fix the issue of the >64 bit vectors for negation. 
 Also add a test for these.


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

https://reviews.llvm.org/D115670

Files:
  clang/lib/AST/ExprConstant.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/SemaCXX/constexpr-vectors.cpp

Index: clang/test/SemaCXX/constexpr-vectors.cpp
===
--- clang/test/SemaCXX/constexpr-vectors.cpp
+++ clang/test/SemaCXX/constexpr-vectors.cpp
@@ -11,12 +11,15 @@
 using FourLongLongsVecSize __attribute__((vector_size(32))) = long long;
 using FourFloatsVecSize __attribute__((vector_size(16))) = float;
 using FourDoublesVecSize __attribute__((vector_size(32))) = double;
+using FourI128VecSize __attribute__((vector_size(64))) = __int128;
 
 using FourCharsExtVec __attribute__((ext_vector_type(4))) = char;
 using FourIntsExtVec __attribute__((ext_vector_type(4))) = int;
 using FourLongLongsExtVec __attribute__((ext_vector_type(4))) = long long;
 using FourFloatsExtVec __attribute__((ext_vector_type(4))) = float;
 using FourDoublesExtVec __attribute__((ext_vector_type(4))) = double;
+using FourI128ExtVec __attribute__((ext_vector_type(4))) = __int128;
+
 
 // Next a series of tests to make sure these operations are usable in
 // constexpr functions. Template instantiations don't emit Winvalid-constexpr,
@@ -204,35 +207,35 @@
 
   constexpr auto w = FourCharsVecSize{1, 2, 3, 4} <
  FourCharsVecSize{4, 3, 2, 1};
-  // CHECK: store <4 x i8> 
+  // CHECK: store <4 x i8> 
   constexpr auto x = FourCharsVecSize{1, 2, 3, 4} >
  FourCharsVecSize{4, 3, 2, 1};
-  // CHECK: store <4 x i8> 
+  // CHECK: store <4 x i8> 
   constexpr auto y = FourCharsVecSize{1, 2, 3, 4} <=
  FourCharsVecSize{4, 3, 3, 1};
-  // CHECK: store <4 x i8> 
+  // CHECK: store <4 x i8> 
   constexpr auto z = FourCharsVecSize{1, 2, 3, 4} >=
  FourCharsVecSize{4, 3, 3, 1};
-  // CHECK: store <4 x i8> 
+  // CHECK: store <4 x i8> 
   constexpr auto A = FourCharsVecSize{1, 2, 3, 4} ==
  FourCharsVecSize{4, 3, 3, 1};
-  // CHECK: store <4 x i8> 
+  // CHECK: store <4 x i8> 
   constexpr auto B = FourCharsVecSize{1, 2, 3, 4} !=
  FourCharsVecSize{4, 3, 3, 1};
-  // CHECK: store <4 x i8> 
+  // CHECK: store <4 x i8> 
 
   constexpr auto C = FourCharsVecSize{1, 2, 3, 4} < 3;
-  // CHECK: store <4 x i8> 
+  // CHECK: store <4 x i8> 
   constexpr auto D = FourCharsVecSize{1, 2, 3, 4} > 3;
-  // CHECK: store <4 x i8> 
+  // CHECK: store <4 x i8> 
   constexpr auto E = FourCharsVecSize{1, 2, 3, 4} <= 3;
-  // CHECK: store <4 x i8> 
+  // CHECK: store <4 x i8> 
   constexpr auto F = FourCharsVecSize{1, 2, 3, 4} >= 3;
-  // CHECK: store <4 x i8> 
+  // CHECK: store <4 x i8> 
   constexpr auto G = FourCharsVecSize{1, 2, 3, 4} == 3;
-  // CHECK: store <4 x i8> 
+  // CHECK: store <4 x i8> 
   constexpr auto H = FourCharsVecSize{1, 2, 3, 4} != 3;
-  // CHECK: store <4 x i8> 
+  // CHECK: store <4 x i8> 
 
   constexpr auto I = FourCharsVecSize{1, 2, 3, 4} &
  FourCharsVecSize{4, 3, 2, 1};
@@ -277,10 +280,12 @@
   constexpr auto Y = CmpSub(a, b);
   // CHECK: store <4 x i8> 
 
-  constexpr auto Z = CmpLSH(a, H);
+  constexpr auto InvH = -H;
+  // CHECK: store <4 x i8> 
+  constexpr auto Z = CmpLSH(a, InvH);
   // CHECK: store <4 x i8> 
 
-  constexpr auto aa = CmpRSH(a, H);
+  constexpr auto aa = CmpRSH(a, InvH);
   // CHECK: store <4 x i8> 
 
   constexpr auto ab = CmpBinAnd(a, b);
@@ -348,35 +353,35 @@
 
   constexpr auto w = FourCharsExtVec{1, 2, 3, 4} <
  FourCharsExtVec{4, 3, 2, 1};
-  // CHECK: store <4 x i8> 
+  // CHECK: store <4 x i8> 
   constexpr auto x = FourCharsExtVec{1, 2, 3, 4} >
  FourCharsExtVec{4, 3, 2, 1};
-  // CHECK: store <4 x i8> 
+  // CHECK: store <4 x i8> 
   constexpr auto y = FourCharsExtVec{1, 2, 3, 4} <=
  FourCharsExtVec{4, 3, 3, 1};
-  // CHECK: store <4 x i8> 
+  // CHECK: store <4 x i8> 
   constexpr auto z = FourCharsExtVec{1, 2, 3, 4} >=
  FourCharsExtVec{4, 3, 3, 1};
-  // CHECK: store <4 x i8> 
+  // CHECK: store <4 x i8> 
   constexpr auto A = FourCharsExtVec{1, 2, 3, 4} ==
  FourCharsExtVec{4, 3, 3, 1};
-  // CHECK: store <4 x i8> 
+  // CHECK: store <4 x i8> 
   constexpr auto B = FourCharsExtVec{1, 2, 3, 4} !=
  FourCharsExtVec{4, 3, 3, 1};
-  // CHECK: store <4 x i8> 
+  // CHECK: store <4 x i8> 
 
   constexpr auto C = FourCharsExtVec{1, 2, 3, 4} < 3;
-  // CHECK: store <4 x i8> 
+  // CHECK: store <4 x i8> 
   constexpr auto D = FourCharsExtVec{1, 2, 3, 4} > 3;
-  // CHECK: store <4 x i8> 
+  // CHECK: store <4 x i8> 
   constexpr auto E = FourCharsExtVec{1, 2, 3, 4} <= 3;
-  // CHECK: store <4 x i8> 
+  //

[PATCH] D115253: [C2x] Support the *_WIDTH macros in limits.h and stdint.h

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Ping


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

https://reviews.llvm.org/D115253

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

[PATCH] D114080: [SYCL] Diagnose uses of zero length arrays

[Mariya Podchishchaeva via Phabricator via cfe-commits]

Fznamznon added a comment.

Ping.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114080

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

[PATCH] D115728: [mlir][linalg] Replace LinalgOps.h and LinalgTypes.h by a single header.

[Tobias Gysi via Phabricator via cfe-commits]

gysit created this revision.
Herald added subscribers: sdasgup3, wenzhicui, wrengr, Chia-hungDuan, 
armkevincheng, jsmolens, eric-k256, dcaballe, cota, mravishankar, teijeong, 
rdzhabarov, tatianashp, ThomasRaoux, AlexeySotkin, msifontes, jurahul, Kayjukh, 
grosul1, Joonsoo, liufengdb, aartbik, lucyrfox, mgester, arpith-jacob, 
antiagainst, shauheen, rriddle, mehdi_amini, mgorny.
Herald added a reviewer: antiagainst.
Herald added a reviewer: aartbik.
Herald added a reviewer: ftynse.
Herald added a reviewer: aartbik.
Herald added a reviewer: sjarus.
gysit requested review of this revision.
Herald added a reviewer: nicolasvasilache.
Herald added subscribers: cfe-commits, limo1996, stephenneuendorffer, 
nicolasvasilache.
Herald added projects: clang, MLIR.

After removing the range type, Linalg does not define any type. The revision 
thus consolidates the LinalgOps.h and LinalgTypes.h into a single Linalg.h 
header. Additionally, LinalgTypes.cpp is renamed to LinalgDialect.cpp to follow 
the convention adopted by other dialects such as the tensor dialect.

Depends On D115727 


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D115728

Files:
  clang/docs/tools/clang-formatted-files.txt
  mlir/include/mlir/Conversion/LinalgToStandard/LinalgToStandard.h
  mlir/include/mlir/Dialect/Linalg/Analysis/DependenceAnalysis.h
  mlir/include/mlir/Dialect/Linalg/IR/Linalg.h
  mlir/include/mlir/Dialect/Linalg/IR/LinalgOps.h
  mlir/include/mlir/Dialect/Linalg/IR/LinalgTypes.h
  mlir/include/mlir/Dialect/Linalg/Utils/Utils.h
  mlir/include/mlir/Dialect/SparseTensor/Utils/Merger.h
  mlir/include/mlir/InitAllDialects.h
  mlir/lib/CAPI/Dialect/Linalg.cpp
  mlir/lib/Conversion/LinalgToLLVM/LinalgToLLVM.cpp
  mlir/lib/Conversion/LinalgToSPIRV/LinalgToSPIRV.cpp
  mlir/lib/Conversion/LinalgToStandard/LinalgToStandard.cpp
  mlir/lib/Conversion/TosaToLinalg/TosaToLinalg.cpp
  mlir/lib/Conversion/TosaToLinalg/TosaToLinalgPass.cpp
  mlir/lib/Dialect/Linalg/Analysis/DependenceAnalysis.cpp
  mlir/lib/Dialect/Linalg/ComprehensiveBufferize/LinalgInterfaceImpl.cpp
  mlir/lib/Dialect/Linalg/IR/CMakeLists.txt
  mlir/lib/Dialect/Linalg/IR/LinalgDialect.cpp
  mlir/lib/Dialect/Linalg/IR/LinalgOps.cpp
  mlir/lib/Dialect/Linalg/IR/LinalgTypes.cpp
  mlir/lib/Dialect/Linalg/Transforms/Bufferize.cpp
  mlir/lib/Dialect/Linalg/Transforms/Detensorize.cpp
  mlir/lib/Dialect/Linalg/Transforms/DropUnitDims.cpp
  mlir/lib/Dialect/Linalg/Transforms/ElementwiseOpFusion.cpp
  mlir/lib/Dialect/Linalg/Transforms/ElementwiseToLinalg.cpp
  mlir/lib/Dialect/Linalg/Transforms/Fusion.cpp
  mlir/lib/Dialect/Linalg/Transforms/FusionOnTensors.cpp
  mlir/lib/Dialect/Linalg/Transforms/Generalization.cpp
  mlir/lib/Dialect/Linalg/Transforms/HoistPadding.cpp
  mlir/lib/Dialect/Linalg/Transforms/Hoisting.cpp
  mlir/lib/Dialect/Linalg/Transforms/InlineScalarOperands.cpp
  mlir/lib/Dialect/Linalg/Transforms/Interchange.cpp
  mlir/lib/Dialect/Linalg/Transforms/LinalgStrategyPasses.cpp
  mlir/lib/Dialect/Linalg/Transforms/Loops.cpp
  mlir/lib/Dialect/Linalg/Transforms/Promotion.cpp
  mlir/lib/Dialect/Linalg/Transforms/Tiling.cpp
  mlir/lib/Dialect/Linalg/Transforms/Transforms.cpp
  mlir/lib/Dialect/Linalg/Transforms/Vectorization.cpp
  mlir/lib/Dialect/Linalg/Utils/Utils.cpp
  mlir/lib/Dialect/SparseTensor/Transforms/Sparsification.cpp
  mlir/lib/Dialect/Vector/VectorTransforms.cpp
  mlir/test/lib/Dialect/Linalg/TestComprehensiveBufferize.cpp
  mlir/test/lib/Dialect/Linalg/TestLinalgCodegenStrategy.cpp
  mlir/test/lib/Dialect/Linalg/TestLinalgDistribution.cpp
  mlir/test/lib/Dialect/Linalg/TestLinalgHoisting.cpp
  mlir/test/lib/Dialect/Linalg/TestLinalgTransforms.cpp
  mlir/test/lib/Dialect/Test/TestDialect.h
  mlir/test/lib/Dialect/Vector/TestVectorTransforms.cpp
  mlir/test/lib/IR/TestSlicing.cpp
  utils/bazel/llvm-project-overlay/mlir/BUILD.bazel

Index: utils/bazel/llvm-project-overlay/mlir/BUILD.bazel
===
--- utils/bazel/llvm-project-overlay/mlir/BUILD.bazel
+++ utils/bazel/llvm-project-overlay/mlir/BUILD.bazel
@@ -6569,11 +6569,10 @@
 name = "LinalgOps",
 srcs = [
 "lib/Dialect/Linalg/IR/LinalgOps.cpp",
-"lib/Dialect/Linalg/IR/LinalgTypes.cpp",
+"lib/Dialect/Linalg/IR/LinalgDialect.cpp",
 ],
 hdrs = [
-"include/mlir/Dialect/Linalg/IR/LinalgOps.h",
-"include/mlir/Dialect/Linalg/IR/LinalgTypes.h",
+"include/mlir/Dialect/Linalg/IR/Linalg.h"
 ],
 includes = ["include"],
 deps = [
Index: mlir/test/lib/IR/TestSlicing.cpp
===
--- mlir/test/lib/IR/TestSlicing.cpp
+++ mlir/test/lib/IR/TestSlicing.cpp
@@ -11,7 +11,7 @@
 //===--===//
 
 #include "mlir/Analysis/SliceAnalysis.h"
-#include "mlir/Dialect/Linalg/IR/LinalgOps.h"
+#include "mlir/Dialect/Linalg/IR/Linalg.h"
 #

[PATCH] D115728: [mlir][linalg] Replace LinalgOps.h and LinalgTypes.h by a single header.

[Tobias Gysi via Phabricator via cfe-commits]

gysit added a comment.

After removing the last Linalg Type in https://reviews.llvm.org/D115727, I 
think it would make sense to merge the LinalgTypes.h and LinalgOp.h headers. 
However, this causes quite of header fixes in downstream projects. We can also 
abandon this revision if preferred.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115728

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

[PATCH] D108694: [RISCV] Add the zvl extension according to the v1.0 spec

[Fraser Cormack via Phabricator via cfe-commits]

frasercrmck added inline comments.



Comment at: clang/test/Preprocessor/riscv-target-features.c:230
+// RUN: | FileCheck --check-prefix=CHECK-V-MINVLEN %s
+// CHECK-V-MINVLEN: __riscv_v_min_vlen 128

Are we able to test non-default values of `__riscv_v_min_vlen` here?



Comment at: llvm/lib/Target/RISCV/RISCVSubtarget.cpp:119
+  if (ZvlLen > RVVVectorBitsMax)
+return 0;
+  // FIXME: Change to >= 32 when VLEN = 32 is supported

Is this intuitive behaviour? If the user supplies `RVVVectorBitsMax` and it's 
less than `ZvlLen`, should it silently return? Or do we instead see 
`RVVVectorBitsMax` as a user-guided limit //on top// of the architecture? Which 
means it can be less but not more? I'm not sure.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108694

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

[clang] 6482383 - [clang-format] FixNamespaceComments does not understand namespace aliases

[via cfe-commits]

Author: mydeveloperday
Date: 2021-12-14T14:53:04Z
New Revision: 6482383e50a4f02e337e7ce61a471e6295f008e4

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

LOG: [clang-format] FixNamespaceComments does not understand namespace aliases

https://github.com/llvm/llvm-project/issues/35876

Ensure a namespace alias doesn't get incorrectly identifier as a namespace

Reviewed By: HazardyKnusperkeks, curdeius, owenpan

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

Fixes: #35876

Added: 


Modified: 
clang/lib/Format/NamespaceEndCommentsFixer.cpp
clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp

Removed: 




diff  --git a/clang/lib/Format/NamespaceEndCommentsFixer.cpp 
b/clang/lib/Format/NamespaceEndCommentsFixer.cpp
index def551f863cd..38ab5b9df76d 100644
--- a/clang/lib/Format/NamespaceEndCommentsFixer.cpp
+++ b/clang/lib/Format/NamespaceEndCommentsFixer.cpp
@@ -180,9 +180,13 @@ getNamespaceToken(const AnnotatedLine *Line,
   if (NamespaceTok->is(tok::l_brace)) {
 // "namespace" keyword can be on the line preceding '{', e.g. in styles
 // where BraceWrapping.AfterNamespace is true.
-if (StartLineIndex > 0)
+if (StartLineIndex > 0) {
   NamespaceTok = AnnotatedLines[StartLineIndex - 1]->First;
+  if (AnnotatedLines[StartLineIndex - 1]->endsWith(tok::semi))
+return nullptr;
+}
   }
+
   return NamespaceTok->getNamespaceToken();
 }
 

diff  --git a/clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp 
b/clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
index 9b0301930d21..3afe35e7ea34 100644
--- a/clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
+++ b/clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
@@ -1185,6 +1185,82 @@ TEST_F(ShortNamespaceLinesTest, MultipleUnwrappedLine) {
 "}\n",
 Style));
 }
+
+TEST_F(ShortNamespaceLinesTest, NamespaceAlias) {
+  auto Style = getLLVMStyle();
+
+  EXPECT_EQ("namespace n = nn;\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+fixNamespaceEndComments("namespace n = nn;\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+Style));
+
+  EXPECT_EQ("namespace n = nn; // comment\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+fixNamespaceEndComments("namespace n = nn; // comment\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+Style));
+
+  EXPECT_EQ("namespace n = nn; /* comment */\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+fixNamespaceEndComments("namespace n = nn; /* comment */\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+Style));
+
+  EXPECT_EQ(
+  "namespace n = nn; /* comment */ /* comment2 */\n"
+  "{\n"
+  "  int i;\n"
+  "  int j;\n"
+  "}\n",
+  fixNamespaceEndComments("namespace n = nn; /* comment */ /* comment2 
*/\n"
+  "{\n"
+  "  int i;\n"
+  "  int j;\n"
+  "}\n",
+  Style));
+
+  EXPECT_EQ("namespace n = nn; {\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+fixNamespaceEndComments("namespace n = nn; {\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+Style));
+  EXPECT_EQ("int foo;\n"
+"namespace n\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}// namespace n\n",
+fixNamespaceEndComments("int foo;\n"
+"namespace n\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+Style));
+}
 } // end namespace
 } // end namespace format
 } // end namespace clang



___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/

[PATCH] D115647: [clang-format] FixNamespaceComments does not understand namespace aliases

[MyDeveloperDay 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 rG6482383e50a4: [clang-format] FixNamespaceComments does not 
understand namespace aliases (authored by MyDeveloperDay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115647

Files:
  clang/lib/Format/NamespaceEndCommentsFixer.cpp
  clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp

Index: clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
===
--- clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
+++ clang/unittests/Format/NamespaceEndCommentsFixerTest.cpp
@@ -1185,6 +1185,82 @@
 "}\n",
 Style));
 }
+
+TEST_F(ShortNamespaceLinesTest, NamespaceAlias) {
+  auto Style = getLLVMStyle();
+
+  EXPECT_EQ("namespace n = nn;\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+fixNamespaceEndComments("namespace n = nn;\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+Style));
+
+  EXPECT_EQ("namespace n = nn; // comment\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+fixNamespaceEndComments("namespace n = nn; // comment\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+Style));
+
+  EXPECT_EQ("namespace n = nn; /* comment */\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+fixNamespaceEndComments("namespace n = nn; /* comment */\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+Style));
+
+  EXPECT_EQ(
+  "namespace n = nn; /* comment */ /* comment2 */\n"
+  "{\n"
+  "  int i;\n"
+  "  int j;\n"
+  "}\n",
+  fixNamespaceEndComments("namespace n = nn; /* comment */ /* comment2 */\n"
+  "{\n"
+  "  int i;\n"
+  "  int j;\n"
+  "}\n",
+  Style));
+
+  EXPECT_EQ("namespace n = nn; {\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+fixNamespaceEndComments("namespace n = nn; {\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+Style));
+  EXPECT_EQ("int foo;\n"
+"namespace n\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}// namespace n\n",
+fixNamespaceEndComments("int foo;\n"
+"namespace n\n"
+"{\n"
+"  int i;\n"
+"  int j;\n"
+"}\n",
+Style));
+}
 } // end namespace
 } // end namespace format
 } // end namespace clang
Index: clang/lib/Format/NamespaceEndCommentsFixer.cpp
===
--- clang/lib/Format/NamespaceEndCommentsFixer.cpp
+++ clang/lib/Format/NamespaceEndCommentsFixer.cpp
@@ -180,9 +180,13 @@
   if (NamespaceTok->is(tok::l_brace)) {
 // "namespace" keyword can be on the line preceding '{', e.g. in styles
 // where BraceWrapping.AfterNamespace is true.
-if (StartLineIndex > 0)
+if (StartLineIndex > 0) {
   NamespaceTok = AnnotatedLines[StartLineIndex - 1]->First;
+  if (AnnotatedLines[StartLineIndex - 1]->endsWith(tok::semi))
+return nullptr;
+}
   }
+
   return NamespaceTok->getNamespaceToken();
 }
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] cea81e9 - [clang-format] add support for cppm files

[via cfe-commits]

Author: mydeveloperday
Date: 2021-12-14T14:55:38Z
New Revision: cea81e95b05f92d1dd24547e086ec97b9510634a

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

LOG: [clang-format] add support for cppm files

C++20 Modules current style is to assign a new file suffix .cppm.

https://github.com/llvm/llvm-project/issues/52658

Ensure git-clang-format can handle that as a default extension

Reviewed By: ChuanqiXu, HazardyKnusperkeks, curdeius

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

Fixes: #52658

Added: 


Modified: 
clang/tools/clang-format/clang-format-diff.py
clang/tools/clang-format/git-clang-format

Removed: 




diff  --git a/clang/tools/clang-format/clang-format-
diff .py b/clang/tools/clang-format/clang-format-
diff .py
index 28ac0275615c..1f6ff0fe295f 100755
--- a/clang/tools/clang-format/clang-format-
diff .py
+++ b/clang/tools/clang-format/clang-format-
diff .py
@@ -47,8 +47,8 @@ def main():
   help='custom pattern selecting file paths to reformat '
   '(case sensitive, overrides -iregex)')
   parser.add_argument('-iregex', metavar='PATTERN', default=
-  r'.*\.(cpp|cc|c\+\+|cxx|c|cl|h|hh|hpp|hxx|m|mm|inc|js|ts'
-  r'|proto|protodevel|java|cs|json)',
+  
r'.*\.(cpp|cc|c\+\+|cxx|cppm|ccm|cxxm|c\+\+m|c|cl|h|hh|hpp|hxx'
+  r'|m|mm|inc|js|ts|proto|protodevel|java|cs|json)',
   help='custom pattern selecting file paths to reformat '
   '(case insensitive, overridden by -regex)')
   parser.add_argument('-sort-includes', action='store_true', default=False,

diff  --git a/clang/tools/clang-format/git-clang-format 
b/clang/tools/clang-format/git-clang-format
index bb5b5546d6a5..7838fd82c1dd 100755
--- a/clang/tools/clang-format/git-clang-format
+++ b/clang/tools/clang-format/git-clang-format
@@ -79,6 +79,7 @@ def main():
   'm',  # ObjC
   'mm',  # ObjC++
   'cc', 'cp', 'cpp', 'c++', 'cxx', 'hh', 'hpp', 'hxx',  # C++
+  'ccm', 'cppm', 'cxxm', 'c++m',  # C++ Modules
   'cu', 'cuh',  # CUDA
   # Other languages that clang-format supports
   'proto', 'protodevel',  # Protocol Buffers



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

[PATCH] D115625: [clang-format] add support for cppm files

[MyDeveloperDay 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 rGcea81e95b05f: [clang-format] add support for cppm files 
(authored by MyDeveloperDay).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115625

Files:
  clang/tools/clang-format/clang-format-diff.py
  clang/tools/clang-format/git-clang-format


Index: clang/tools/clang-format/git-clang-format
===
--- clang/tools/clang-format/git-clang-format
+++ clang/tools/clang-format/git-clang-format
@@ -79,6 +79,7 @@
   'm',  # ObjC
   'mm',  # ObjC++
   'cc', 'cp', 'cpp', 'c++', 'cxx', 'hh', 'hpp', 'hxx',  # C++
+  'ccm', 'cppm', 'cxxm', 'c++m',  # C++ Modules
   'cu', 'cuh',  # CUDA
   # Other languages that clang-format supports
   'proto', 'protodevel',  # Protocol Buffers
Index: clang/tools/clang-format/clang-format-diff.py
===
--- clang/tools/clang-format/clang-format-diff.py
+++ clang/tools/clang-format/clang-format-diff.py
@@ -47,8 +47,8 @@
   help='custom pattern selecting file paths to reformat '
   '(case sensitive, overrides -iregex)')
   parser.add_argument('-iregex', metavar='PATTERN', default=
-  r'.*\.(cpp|cc|c\+\+|cxx|c|cl|h|hh|hpp|hxx|m|mm|inc|js|ts'
-  r'|proto|protodevel|java|cs|json)',
+  
r'.*\.(cpp|cc|c\+\+|cxx|cppm|ccm|cxxm|c\+\+m|c|cl|h|hh|hpp|hxx'
+  r'|m|mm|inc|js|ts|proto|protodevel|java|cs|json)',
   help='custom pattern selecting file paths to reformat '
   '(case insensitive, overridden by -regex)')
   parser.add_argument('-sort-includes', action='store_true', default=False,


Index: clang/tools/clang-format/git-clang-format
===
--- clang/tools/clang-format/git-clang-format
+++ clang/tools/clang-format/git-clang-format
@@ -79,6 +79,7 @@
   'm',  # ObjC
   'mm',  # ObjC++
   'cc', 'cp', 'cpp', 'c++', 'cxx', 'hh', 'hpp', 'hxx',  # C++
+  'ccm', 'cppm', 'cxxm', 'c++m',  # C++ Modules
   'cu', 'cuh',  # CUDA
   # Other languages that clang-format supports
   'proto', 'protodevel',  # Protocol Buffers
Index: clang/tools/clang-format/clang-format-diff.py
===
--- clang/tools/clang-format/clang-format-diff.py
+++ clang/tools/clang-format/clang-format-diff.py
@@ -47,8 +47,8 @@
   help='custom pattern selecting file paths to reformat '
   '(case sensitive, overrides -iregex)')
   parser.add_argument('-iregex', metavar='PATTERN', default=
-  r'.*\.(cpp|cc|c\+\+|cxx|c|cl|h|hh|hpp|hxx|m|mm|inc|js|ts'
-  r'|proto|protodevel|java|cs|json)',
+  r'.*\.(cpp|cc|c\+\+|cxx|cppm|ccm|cxxm|c\+\+m|c|cl|h|hh|hpp|hxx'
+  r'|m|mm|inc|js|ts|proto|protodevel|java|cs|json)',
   help='custom pattern selecting file paths to reformat '
   '(case insensitive, overridden by -regex)')
   parser.add_argument('-sort-includes', action='store_true', default=False,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D115501: [clang][ARM] Emit warnings when PACBTI-M is used with unsupported architectures

[Momchil Velikov via Phabricator via cfe-commits]

chill added inline comments.



Comment at: clang/lib/Basic/Targets/AArch64.h:70
 
-  bool validateBranchProtection(StringRef, BranchProtectionInfo &,
+  bool validateBranchProtection(StringRef, StringRef, BranchProtectionInfo &,
 StringRef &) const override;

Would be nice to have parameter names, like in the adjacent declarations.



Comment at: clang/lib/Basic/Targets/ARM.cpp:375-379
+  if (ArchKind != llvm::ARM::ArchKind::ARMV8_1MMainline &&
+  ArchKind != llvm::ARM::ArchKind::ARMV8MMainline &&
+  ArchKind != llvm::ARM::ArchKind::ARMV7M &&
+  ArchKind != llvm::ARM::ArchKind::ARMV7EM)
+return false;





Comment at: clang/lib/Basic/Targets/ARM.cpp:381
+
+  return true;
+}





Comment at: clang/lib/Basic/Targets/ARM.cpp:391-392
 
+  if (!Arch.empty() && !isBranchProtectionSupportedArch(Arch))
+return false;
+

On empty `Arch` it'd continue down the function, but we'd like to return 
failure.



Comment at: clang/lib/Basic/Targets/ARM.h:128
 
-  bool validateBranchProtection(StringRef, BranchProtectionInfo &,
+  bool isBranchProtectionSupportedArch(StringRef) const override;
+  bool validateBranchProtection(StringRef, StringRef, BranchProtectionInfo &,

Likewise.



Comment at: clang/test/CodeGen/arm_acle.c:1530
 // AArch64-NEXT:ret i32 [[TMP0]]
 //
 uint32_t test_crc32cd(uint32_t a, uint64_t b) {

These look like random changes for the untrained eye


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115501

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

[PATCH] D115685: [NFC] Fix typos in release notes

[Louis Dionne via Phabricator via cfe-commits]

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

Thank you!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115685

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

[PATCH] D115738: [clang-format] Code following C# Lambda Expressions has wrong formatting

[Peter Stys via Phabricator via cfe-commits]

peterstys created this revision.
peterstys added a reviewer: MyDeveloperDay.
peterstys requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

The alignment fix introduced by https://reviews.llvm.org/D104388 caused a 
regression whereby formatting of code that follows the lambda block is 
incorrect i.e. separate expressions are put on the same line.

For example:

  public void Test() {
while (true) {
  preBindEnumerators.RemoveAll(enumerator => !enumerator.MoveNext());
  CodeThatFollowsLambda();
  IsWellAligned(); 
  }

will be formatted as:

  public void Test() {
while (true) {
  preBindEnumerators.RemoveAll(enumerator => !enumerator.MoveNext());
  CodeThatFollowsLambda(); IsWellAligned(); 
  }

The problem is that the "Fat arrow" token parsing inside the parseParens() 
function uses parseStructuralElement() which does not like to be called inside 
the parenthesis. It seems that code that follows is considered part of the 
parenthesis block.

As a fix, parseStructuralElement parser inside the parseParens() was replaced 
with parseChildBlock() if the following token was a "left brace" and 
nextToken() otherwise. Added few new unit tests to demonstrate the regressions.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D115738

Files:
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/unittests/Format/FormatTestCSharp.cpp

Index: clang/unittests/Format/FormatTestCSharp.cpp
===
--- clang/unittests/Format/FormatTestCSharp.cpp
+++ clang/unittests/Format/FormatTestCSharp.cpp
@@ -759,6 +759,122 @@
GoogleStyle);
 }
 
+TEST_F(FormatTestCSharp, CSharpLambdasDontBreakFollowingCodeAlignment) {
+  FormatStyle GoogleStyle = getGoogleStyle(FormatStyle::LK_CSharp);
+  FormatStyle MicrosoftStyle = getMicrosoftStyle(FormatStyle::LK_CSharp);
+
+  verifyFormat(R"(//
+public class Sample {
+  public void Test() {
+while (true) {
+  preBindEnumerators.RemoveAll(enumerator => !enumerator.MoveNext());
+  CodeThatFollowsLambda();
+  IsWellAligned();
+}
+  }
+})", GoogleStyle);
+
+  verifyFormat(R"(//
+public class Sample
+{
+public void Test()
+{
+while (true)
+{
+preBindEnumerators.RemoveAll(enumerator => !enumerator.MoveNext());
+CodeThatFollowsLambda();
+IsWellAligned();
+}
+}
+})", MicrosoftStyle);
+}
+
+TEST_F(FormatTestCSharp, CSharpLambdasComplexLambdasDontBreakAlignment) {
+  FormatStyle GoogleStyle = getGoogleStyle(FormatStyle::LK_CSharp);
+  FormatStyle MicrosoftStyle = getMicrosoftStyle(FormatStyle::LK_CSharp);
+
+  verifyFormat(R"(//
+public class Test
+{
+private static void ComplexLambda(BuildReport protoReport)
+{
+allSelectedScenes =
+veryVeryLongCollectionNameThatPutsTheLineLenghtAboveTheThresholds.Where(scene => scene.enabled)
+.Select(scene => scene.path)
+.ToArray();
+if (allSelectedScenes.Count == 0)
+{
+return;
+}
+Functions();
+AreWell();
+Aligned();
+AfterLambdaBlock();
+}
+})", MicrosoftStyle);
+
+  verifyFormat(R"(//
+public class Test {
+  private static void ComplexLambda(BuildReport protoReport) {
+allSelectedScenes = veryVeryLongCollectionNameThatPutsTheLineLenghtAboveTheThresholds
+.Where(scene => scene.enabled)
+.Select(scene => scene.path)
+.ToArray();
+if (allSelectedScenes.Count == 0) {
+  return;
+}
+Functions();
+AreWell();
+Aligned();
+AfterLambdaBlock();
+  }
+})", GoogleStyle);
+}
+
+TEST_F(FormatTestCSharp, CSharpLambdasMulipleLambdasDontBreakAlignment) {
+  FormatStyle GoogleStyle = getGoogleStyle(FormatStyle::LK_CSharp);
+  FormatStyle MicrosoftStyle = getMicrosoftStyle(FormatStyle::LK_CSharp);
+
+  verifyFormat(R"(//
+public class Test
+{
+private static void MultipleLambdas(BuildReport protoReport)
+{
+allSelectedScenes =
+veryVeryLongCollectionNameThatPutsTheLineLenghtAboveTheThresholds.Where(scene => scene.enabled)
+.Select(scene => scene.path)
+.ToArray();
+preBindEnumerators.RemoveAll(enumerator => !enumerator.MoveNext());
+if (allSelectedScenes.Count == 0)
+{
+return;
+}
+Functions();
+AreWell();
+Aligned();
+AfterLambdaBlock();
+}
+})", MicrosoftStyle);
+
+  verifyFormat(R"(//
+public class Test {
+  private static void MultipleLambdas(BuildReport protoReport) {
+allSelectedScenes = veryVeryLongCollectionNameThatPutsTheLineLenghtAboveTheThresholds
+.Where(scene => scene.enabled)
+.Select(scene => scene.path)
+.ToArray();
+preBindEnumerators.Remov

[PATCH] D115685: [NFC] Fix typos in release notes

[Mark de Wever via Phabricator via cfe-commits]

Mordante accepted this revision.
Mordante added a comment.

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115685

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

[PATCH] D115320: Avoid setting tbaa information on store of return type of call to inline assember

[Jeroen Dobbelaere via Phabricator via cfe-commits]

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

LGTM


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

https://reviews.llvm.org/D115320

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

[PATCH] D115492: [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO

[Mingming Liu via Phabricator via cfe-commits]

luna marked 5 inline comments as done.
luna added inline comments.



Comment at: llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp:396
+  }
+  // Identifies a function as unreachable if and only if
+  // 1) All summaries are live.

tejohnson wrote:
> Actually I think we can safely ignore any summaries that are not not 
> functions - a non-function could have the same GUID in some rare cases, but 
> these are irrelevant to the handling of the functions.
> 
> I'm not sure we need all copies to be live, but in general I believe either 
> all will be live or all will be dead. I think we want at least one live 
> function here because the alternative could mean that the prevailing copy was 
> not in IR, in which case we can't make any assumptions. So you could either 
> leave the liveness handling as is, or just ignore any non-live summaries and 
> only return true if we have at least one live summary. In practice both 
> should be the same so it may just be simpler to be conservative if we see any 
> non-live function summaries.
Done by
1) ignoring any summaries that are not functions 
2) returning false if any summary is not live
3) merging "if (!TheFnVI)" and "if (TheFnVI.getSummaryList().empty())"
and added a few lines of comment.



Comment at: 
llvm/test/ThinLTO/X86/devirt_hybrid_after_filtering_unreachable.ll:103
+  %0 = bitcast i8* %call to %class.Derived*
+  invoke void @_ZN7DerivedC2Ev(%class.Derived* nonnull align 8 
dereferenceable(8) %0)
+  to label %invoke.cont unwind label %lpad

tejohnson wrote:
> Is it possible to simplify this test case so that the methods in this file 
> and the other input file don't have all the EH code in them?
I generate the IR by "clang -fvisibility=hidden -fwhole-program-vtables -flto 
-fsplit-lto-unit -fno-exceptions -S -emit-llvm  -o file.ll" now, and 
the EH symbols and basic blocks are simplified away.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115492

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

[PATCH] D115492: [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO

[Mingming Liu via Phabricator via cfe-commits]

luna updated this revision to Diff 394281.
luna marked 2 inline comments as done.
luna added a comment.

Revise based on comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115492

Files:
  clang/test/CodeGen/thinlto-distributed-cfi-devirt.ll
  clang/test/CodeGen/thinlto-distributed-cfi.ll
  clang/test/CodeGen/thinlto-funcattr-prop.ll
  llvm/include/llvm/AsmParser/LLToken.h
  llvm/include/llvm/IR/ModuleSummaryIndex.h
  llvm/lib/Analysis/ModuleSummaryAnalysis.cpp
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/ModuleSummaryIndex.cpp
  llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp
  llvm/test/Assembler/thinlto-summary.ll
  llvm/test/Bitcode/thinlto-function-summary-refgraph.ll
  llvm/test/Bitcode/thinlto-type-vcalls.ll
  llvm/test/ThinLTO/X86/Inputs/devirt_hybrid_after_filtering_unreachable_lib.ll
  llvm/test/ThinLTO/X86/devirt_hybrid_after_filtering_unreachable.ll
  llvm/test/ThinLTO/X86/dot-dumper.ll
  llvm/test/ThinLTO/X86/dot-dumper2.ll
  llvm/test/ThinLTO/X86/funcattrs-prop-maythrow.ll
  llvm/test/ThinLTO/X86/funcimport_alwaysinline.ll

Index: llvm/test/ThinLTO/X86/funcimport_alwaysinline.ll
===
--- llvm/test/ThinLTO/X86/funcimport_alwaysinline.ll
+++ llvm/test/ThinLTO/X86/funcimport_alwaysinline.ll
@@ -23,4 +23,4 @@
 }
 
 attributes #0 = { alwaysinline nounwind uwtable }
-; CHECK2: ^2 = gv: (guid: {{.*}}, summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 1, dsoLocal: 1, canAutoHide: 0), insts: 1, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 1, noUnwind: 1, mayThrow: 0, hasUnknownCall: 0
+; CHECK2: ^2 = gv: (guid: {{.*}}, summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 1, dsoLocal: 1, canAutoHide: 0), insts: 1, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 1, noUnwind: 1, mayThrow: 0, hasUnknownCall: 0, mustBeUnreachable: 0
Index: llvm/test/ThinLTO/X86/funcattrs-prop-maythrow.ll
===
--- llvm/test/ThinLTO/X86/funcattrs-prop-maythrow.ll
+++ llvm/test/ThinLTO/X86/funcattrs-prop-maythrow.ll
@@ -48,9 +48,9 @@
 ; CHECK-DAG: attributes [[ATTR_NOUNWIND]] = { norecurse nounwind }
 ; CHECK-DAG: attributes [[ATTR_MAYTHROW]] = { norecurse }
 
-; SUMMARY-DAG: = gv: (name: "cleanupret", summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), insts: 4, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 0, noUnwind: 0, mayThrow: 1, hasUnknownCall: 0), calls: ((callee: ^{{.*}})), refs: (^{{.*}}
-; SUMMARY-DAG: = gv: (name: "resume", summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), insts: 4, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 0, noUnwind: 0, mayThrow: 1, hasUnknownCall: 0), calls: ((callee: ^{{.*}})), refs: (^{{.*}}
-; SUMMARY-DAG: = gv: (name: "catchret", summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), insts: 5, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 0, noUnwind: 0, mayThrow: 1, hasUnknownCall: 0), calls: ((callee: ^{{.*}})), refs: (^{{.*}}
+; SUMMARY-DAG: = gv: (name: "cleanupret", summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), insts: 4, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 0, noUnwind: 0, mayThrow: 1, hasUnknownCall: 0, mustBeUnreachable: 0), calls: ((callee: ^{{.*}})), refs: (^{{.*}}
+; SUMMARY-DAG: = gv: (name: "resume", summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), insts: 4, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 0, noUnwind: 0, mayThrow: 1, hasUnknownCall: 0, mustBeUnreachable: 0), calls: ((callee: ^{{.*}})), refs: (^{{.*}}
+; SUMMARY-DAG: = gv: (name: "catchret", summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), insts: 5, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 0, noUnwind: 0, mayT

[PATCH] D115492: [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO

[Teresa Johnson via Phabricator via cfe-commits]

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

lgtm after adding a description to test as noted below.




Comment at: llvm/test/ThinLTO/X86/devirt_hybrid_after_filtering_unreachable.ll:1
+; Generate split module with summary for hybrid Thin/Regular LTO WPD
+; RUN: opt -thinlto-bc -thinlto-split-lto-unit %s -o %t-main.bc

Add a brief description at the top as to what this test is for.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115492

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

[PATCH] D114718: [analyzer] Implement a new checker for Strict Aliasing Rule.

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov updated this revision to Diff 394290.
ASDenysPetrov added a comment.

Changed handler `check::` functions. Reworked. Covered more cases.

Several cases left (marked as FIXME in the test file). For the glance some of 
them we can't handle because of (possibly) wrong symbolic modeling.

WIP.


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

https://reviews.llvm.org/D114718

Files:
  clang/include/clang/StaticAnalyzer/Checkers/Checkers.td
  clang/lib/StaticAnalyzer/Checkers/CMakeLists.txt
  clang/lib/StaticAnalyzer/Checkers/StrictAliasingChecker.cpp
  clang/test/Analysis/Checkers/StrictAliasingChecker/strict-aliasing.cpp

Index: clang/test/Analysis/Checkers/StrictAliasingChecker/strict-aliasing.cpp
===
--- /dev/null
+++ clang/test/Analysis/Checkers/StrictAliasingChecker/strict-aliasing.cpp
@@ -0,0 +1,811 @@
+// RUN: %clang_cc1 -std=c++20 -analyze -analyzer-config eagerly-assume=false -analyzer-checker=debug.ExprInspection,alpha.core.StrictAliasing -verify %s
+// NOTE: -relaxed-aliasing flag disables StrictAliasing checker.
+
+template 
+void clang_analyzer_dump(T x);
+void clang_analyzer_eval(int);
+
+namespace std {
+enum class byte : unsigned char {};
+enum class OtherByte : unsigned char {};
+}; // namespace std
+enum class EnumInt : int {};
+
+union UnionUchar {
+  unsigned char x;
+  char y;
+};
+union UnionInt {
+  int x;
+};
+class Class {};
+class ClassInt {
+public:
+  int x;
+};
+class Base {
+public:
+  int x;
+};
+struct AnotherBase {
+  int y;
+};
+class Derived : public AnotherBase, public Base {
+  int z;
+};
+class MostDerived : public Derived {
+  int w;
+};
+
+using AliasedStdByte = std::byte;
+using AliasedChar = char;
+using AliasedSChar = const signed char;
+using AliasedInt = int;
+using AliasedUInt = const unsigned int;
+using AliasedULong = unsigned long;
+using AliasedBase = Base;
+using AliasedAnotherBase = AnotherBase;
+
+namespace ns1 {
+
+void int_casts() {
+  using MyInt = int;
+  MyInt x = {};
+  // int to records
+  {
+auto *ptr = (Class *)&x;
+auto y = *ptr; // expected-warning{{Undefined behavior}}
+  }
+  {
+auto *ptr = (ClassInt *)&x;
+auto y = ptr[0]; // expected-warning{{Undefined behavior}}
+  }
+  {
+auto *ptr = (UnionUchar *)&x;
+ptr->x = 42; // expected-warning{{Undefined behavior}}
+  }
+  {
+auto *ptr = (UnionInt *)&x;
+ptr->x = 42; // expected-warning{{Undefined behavior}}
+  }
+  // int to records
+  {
+auto *ptr = (std::byte *)&x;
+auto y = *ptr; // no-warning
+  }
+  {
+auto *ptr = (std::OtherByte *)&x;
+auto y = *ptr; // expected-warning{{Undefined behavior. Attempting to access the stored value of type}}
+  }
+  {
+auto *ptr = (EnumInt *)&x;
+auto y = ptr[0]; // expected-warning{{Undefined behavior}}
+  }
+  // int to scalars
+  {
+auto *ptr = (const char *)&x;
+auto y = *ptr; // no-warning
+  }
+  {
+auto *ptr = (unsigned char *)&x;
+auto y = *ptr; // no-warning
+  }
+  {
+auto *ptr = (signed char *)&x;
+auto y = *ptr; // expected-warning{{Undefined behavior}}
+  }
+  {
+auto *ptr = (short *)&x;
+auto y = ptr[0]; // expected-warning{{Undefined behavior}}
+  }
+  {
+auto *ptr = (unsigned short *)&x;
+ptr[0] = 42; // expected-warning{{Undefined behavior}}
+  }
+  {
+auto *ptr = (signed short *)&x;
+auto y = *ptr; // expected-warning{{Undefined behavior}}
+  }
+  {
+auto *ptr = (int *)&x;
+ptr[0] = 42; // no-warning
+  }
+  {
+auto *ptr = (const volatile unsigned int *)&x;
+auto y = *ptr; // no-warning
+  }
+  {
+auto *ptr = (signed int *)&x;
+*ptr = 24; // no-warning
+  }
+  {
+auto *ptr = (long *)&x;
+auto y = *ptr; // expected-warning{{Undefined behavior}}
+  }
+  {
+auto *ptr = (unsigned long *)&x;
+auto y = *ptr; // expected-warning{{Undefined behavior}}
+  }
+  {
+auto *ptr = (signed long *)&x;
+auto y = *ptr; // expected-warning{{Undefined behavior}}
+  }
+  {
+auto *ptr = (long long *)&x;
+auto y = ptr[0]; // expected-warning{{Undefined behavior}}
+  }
+  {
+auto *ptr = (unsigned long long *)&x;
+auto y = *ptr; // expected-warning{{Undefined behavior}}
+  }
+  {
+auto *ptr = (signed long long *)&x;
+auto y = *ptr; // expected-warning{{Undefined behavior}}
+  }
+  {
+auto *ptr = (float *)&x;
+auto y = *ptr; // expected-warning{{Undefined behavior}}
+  }
+  {
+auto *ptr = (double *)&x;
+auto y = *ptr; // expected-warning{{Undefined behavior}}
+  }
+  {
+auto *ptr = (long double *)&x;
+auto y = *ptr; // expected-warning{{Undefined behavior}}
+  }
+  // int to aliases
+  {
+auto *ptr = (AliasedStdByte *)&x;
+auto y = ptr[0]; // no-warning
+  }
+  {
+auto *ptr = (AliasedChar *)&x;
+auto y = *ptr; // no-warning
+  }
+  {
+auto *ptr = (AliasedSChar *)&x;
+auto y = *ptr; // expected-warning{{Undefined behavior}}
+  }
+  {
+auto *ptr = (Aliased

[PATCH] D115253: [C2x] Support the *_WIDTH macros in limits.h and stdint.h

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman updated this revision to Diff 394291.
aaron.ballman added a reviewer: joerg.
aaron.ballman added a comment.

Updating based on off-list review feedback and adding a new reviewer.


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

https://reviews.llvm.org/D115253

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Headers/limits.h
  clang/lib/Headers/stdint.h
  clang/test/Headers/limits.cpp
  clang/test/Headers/stdint.c
  clang/test/Preprocessor/init-aarch64.c
  clang/test/Preprocessor/init.c
  clang/www/c_status.html

Index: clang/www/c_status.html
===
--- clang/www/c_status.html
+++ clang/www/c_status.html
@@ -715,11 +715,7 @@
 
   Two's complement sign representation
   http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf";>N2412
-  
-Partial
-  Lacking width macros in limits.h and stdint.h
-
-  
+  Clang 14
 
 
   Adding the u8 character prefix
Index: clang/test/Preprocessor/init.c
===
--- clang/test/Preprocessor/init.c
+++ clang/test/Preprocessor/init.c
@@ -1519,6 +1519,7 @@
 // WEBASSEMBLY-NEXT:#define __ATOMIC_RELEASE 3
 // WEBASSEMBLY-NEXT:#define __ATOMIC_SEQ_CST 5
 // WEBASSEMBLY-NEXT:#define __BIGGEST_ALIGNMENT__ 16
+// WEBASSEMBLY-NEXT:#define __BOOL_WIDTH__ 8
 // WEBASSEMBLY-NEXT:#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
 // WEBASSEMBLY-NEXT:#define __CHAR16_TYPE__ unsigned short
 // WEBASSEMBLY-NEXT:#define __CHAR32_TYPE__ unsigned int
@@ -1608,21 +1609,25 @@
 // WEBASSEMBLY-NEXT:#define __INT16_FMTi__ "hi"
 // WEBASSEMBLY-NEXT:#define __INT16_MAX__ 32767
 // WEBASSEMBLY-NEXT:#define __INT16_TYPE__ short
+// WEBASSEMBLY-NEXT:#define __INT16_WIDTH__ 16
 // WEBASSEMBLY-NEXT:#define __INT32_C_SUFFIX__
 // WEBASSEMBLY-NEXT:#define __INT32_FMTd__ "d"
 // WEBASSEMBLY-NEXT:#define __INT32_FMTi__ "i"
 // WEBASSEMBLY-NEXT:#define __INT32_MAX__ 2147483647
 // WEBASSEMBLY-NEXT:#define __INT32_TYPE__ int
+// WEBASSEMBLY-NEXT:#define __INT32_WIDTH__ 32
 // WEBASSEMBLY-NEXT:#define __INT64_C_SUFFIX__ LL
 // WEBASSEMBLY-NEXT:#define __INT64_FMTd__ "lld"
 // WEBASSEMBLY-NEXT:#define __INT64_FMTi__ "lli"
 // WEBASSEMBLY-NEXT:#define __INT64_MAX__ 9223372036854775807LL
 // WEBASSEMBLY-NEXT:#define __INT64_TYPE__ long long int
+// WEBASSEMBLY-NEXT:#define __INT64_WIDTH__ 64
 // WEBASSEMBLY-NEXT:#define __INT8_C_SUFFIX__
 // WEBASSEMBLY-NEXT:#define __INT8_FMTd__ "hhd"
 // WEBASSEMBLY-NEXT:#define __INT8_FMTi__ "hhi"
 // WEBASSEMBLY-NEXT:#define __INT8_MAX__ 127
 // WEBASSEMBLY-NEXT:#define __INT8_TYPE__ signed char
+// WEBASSEMBLY-NEXT:#define __INT8_WIDTH__ 8
 // WEBASSEMBLY-NEXT:#define __INTMAX_C_SUFFIX__ LL
 // WEBASSEMBLY-NEXT:#define __INTMAX_FMTd__ "lld"
 // WEBASSEMBLY-NEXT:#define __INTMAX_FMTi__ "lli"
@@ -1640,34 +1645,42 @@
 // WEBASSEMBLY-NEXT:#define __INT_FAST16_FMTi__ "hi"
 // WEBASSEMBLY-NEXT:#define __INT_FAST16_MAX__ 32767
 // WEBASSEMBLY-NEXT:#define __INT_FAST16_TYPE__ short
+// WEBASSEMBLY-NEXT:#define __INT_FAST16_WIDTH__ 16
 // WEBASSEMBLY-NEXT:#define __INT_FAST32_FMTd__ "d"
 // WEBASSEMBLY-NEXT:#define __INT_FAST32_FMTi__ "i"
 // WEBASSEMBLY-NEXT:#define __INT_FAST32_MAX__ 2147483647
 // WEBASSEMBLY-NEXT:#define __INT_FAST32_TYPE__ int
+// WEBASSEMBLY-NEXT:#define __INT_FAST32_WIDTH__ 32
 // WEBASSEMBLY-NEXT:#define __INT_FAST64_FMTd__ "lld"
 // WEBASSEMBLY-NEXT:#define __INT_FAST64_FMTi__ "lli"
 // WEBASSEMBLY-NEXT:#define __INT_FAST64_MAX__ 9223372036854775807LL
 // WEBASSEMBLY-NEXT:#define __INT_FAST64_TYPE__ long long int
+// WEBASSEMBLY-NEXT:#define __INT_FAST64_WIDTH__ 64
 // WEBASSEMBLY-NEXT:#define __INT_FAST8_FMTd__ "hhd"
 // WEBASSEMBLY-NEXT:#define __INT_FAST8_FMTi__ "hhi"
 // WEBASSEMBLY-NEXT:#define __INT_FAST8_MAX__ 127
 // WEBASSEMBLY-NEXT:#define __INT_FAST8_TYPE__ signed char
+// WEBASSEMBLY-NEXT:#define __INT_FAST8_WIDTH__ 8
 // WEBASSEMBLY-NEXT:#define __INT_LEAST16_FMTd__ "hd"
 // WEBASSEMBLY-NEXT:#define __INT_LEAST16_FMTi__ "hi"
 // WEBASSEMBLY-NEXT:#define __INT_LEAST16_MAX__ 32767
 // WEBASSEMBLY-NEXT:#define __INT_LEAST16_TYPE__ short
+// WEBASSEMBLY-NEXT:#define __INT_LEAST16_WIDTH__ 16
 // WEBASSEMBLY-NEXT:#define __INT_LEAST32_FMTd__ "d"
 // WEBASSEMBLY-NEXT:#define __INT_LEAST32_FMTi__ "i"
 // WEBASSEMBLY-NEXT:#define __INT_LEAST32_MAX__ 2147483647
 // WEBASSEMBLY-NEXT:#define __INT_LEAST32_TYPE__ int
+// WEBASSEMBLY-NEXT:#define __INT_LEAST32_WIDTH__ 32
 // WEBASSEMBLY-NEXT:#define __INT_LEAST64_FMTd__ "lld"
 // WEBASSEMBLY-NEXT:#define __INT_LEAST64_FMTi__ "lli"
 // WEBASSEMBLY-NEXT:#define __INT_LEAST64_MAX__ 9223372036854775807LL
 // WEBASSEMBLY-NEXT:#define __INT_LEAST64_TYPE__ long long int
+// WEBASSEMBLY-NEXT:#define __INT_LEAST64_WIDTH__ 64
 // WEBASSEMBLY-NEXT:#define __INT_LEAST8_FMTd__ "hhd"
 // WEBASSEMBLY-NEXT:#define __INT_LEAST8_FMTi__ "hhi"
 // WEBASSEMBLY-NEXT:#define __INT_LE

[PATCH] D115253: [C2x] Support the *_WIDTH macros in limits.h and stdint.h

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D115253#3192652 , @aaron.ballman 
wrote:

> Updating based on off-list review feedback and adding a new reviewer.

This added `DefineTypeSizeAndWidth()` as a helper for setting the `_MAX` and 
`_WIDTH` macros as a pair and it introduces some more testing for the width's 
relationship to `sizeof` and `CHAR_BIT`.


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

https://reviews.llvm.org/D115253

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

[PATCH] D115492: [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO

[Mingming Liu via Phabricator via cfe-commits]

luna updated this revision to Diff 394293.
luna added a comment.

Describe what the test case devirt_hybrid_after_filtering_unreachable.ll is for.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115492

Files:
  clang/test/CodeGen/thinlto-distributed-cfi-devirt.ll
  clang/test/CodeGen/thinlto-distributed-cfi.ll
  clang/test/CodeGen/thinlto-funcattr-prop.ll
  llvm/include/llvm/AsmParser/LLToken.h
  llvm/include/llvm/IR/ModuleSummaryIndex.h
  llvm/lib/Analysis/ModuleSummaryAnalysis.cpp
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/ModuleSummaryIndex.cpp
  llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp
  llvm/test/Assembler/thinlto-summary.ll
  llvm/test/Bitcode/thinlto-function-summary-refgraph.ll
  llvm/test/Bitcode/thinlto-type-vcalls.ll
  llvm/test/ThinLTO/X86/Inputs/devirt_hybrid_after_filtering_unreachable_lib.ll
  llvm/test/ThinLTO/X86/devirt_hybrid_after_filtering_unreachable.ll
  llvm/test/ThinLTO/X86/dot-dumper.ll
  llvm/test/ThinLTO/X86/dot-dumper2.ll
  llvm/test/ThinLTO/X86/funcattrs-prop-maythrow.ll
  llvm/test/ThinLTO/X86/funcimport_alwaysinline.ll

Index: llvm/test/ThinLTO/X86/funcimport_alwaysinline.ll
===
--- llvm/test/ThinLTO/X86/funcimport_alwaysinline.ll
+++ llvm/test/ThinLTO/X86/funcimport_alwaysinline.ll
@@ -23,4 +23,4 @@
 }
 
 attributes #0 = { alwaysinline nounwind uwtable }
-; CHECK2: ^2 = gv: (guid: {{.*}}, summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 1, dsoLocal: 1, canAutoHide: 0), insts: 1, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 1, noUnwind: 1, mayThrow: 0, hasUnknownCall: 0
+; CHECK2: ^2 = gv: (guid: {{.*}}, summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 1, dsoLocal: 1, canAutoHide: 0), insts: 1, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 1, noUnwind: 1, mayThrow: 0, hasUnknownCall: 0, mustBeUnreachable: 0
Index: llvm/test/ThinLTO/X86/funcattrs-prop-maythrow.ll
===
--- llvm/test/ThinLTO/X86/funcattrs-prop-maythrow.ll
+++ llvm/test/ThinLTO/X86/funcattrs-prop-maythrow.ll
@@ -48,9 +48,9 @@
 ; CHECK-DAG: attributes [[ATTR_NOUNWIND]] = { norecurse nounwind }
 ; CHECK-DAG: attributes [[ATTR_MAYTHROW]] = { norecurse }
 
-; SUMMARY-DAG: = gv: (name: "cleanupret", summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), insts: 4, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 0, noUnwind: 0, mayThrow: 1, hasUnknownCall: 0), calls: ((callee: ^{{.*}})), refs: (^{{.*}}
-; SUMMARY-DAG: = gv: (name: "resume", summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), insts: 4, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 0, noUnwind: 0, mayThrow: 1, hasUnknownCall: 0), calls: ((callee: ^{{.*}})), refs: (^{{.*}}
-; SUMMARY-DAG: = gv: (name: "catchret", summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), insts: 5, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 0, noUnwind: 0, mayThrow: 1, hasUnknownCall: 0), calls: ((callee: ^{{.*}})), refs: (^{{.*}}
+; SUMMARY-DAG: = gv: (name: "cleanupret", summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), insts: 4, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 0, noUnwind: 0, mayThrow: 1, hasUnknownCall: 0, mustBeUnreachable: 0), calls: ((callee: ^{{.*}})), refs: (^{{.*}}
+; SUMMARY-DAG: = gv: (name: "resume", summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), insts: 4, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 0, noUnwind: 0, mayThrow: 1, hasUnknownCall: 0, mustBeUnreachable: 0), calls: ((callee: ^{{.*}})), refs: (^{{.*}}
+; SUMMARY-DAG: = gv: (name: "catchret", summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), insts: 5, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 0, n

[PATCH] D115492: [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO

[Mingming Liu via Phabricator via cfe-commits]

luna added a comment.

In D115492#3192624 , @tejohnson wrote:

> lgtm after adding a description to test as noted below.

Done. Thanks for review and feedback!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115492

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

[PATCH] D115715: [clang-tidy] Fix llvm-header-guard for Windows paths containing drive letter (e.g. C:).

[Salman Javed via Phabricator via cfe-commits]

salman-javed-nz added a comment.

In D115715#3192085 , @aaron.ballman 
wrote:

> It could be made to be useful outside of LLVM, but as it stands today, the 
> check is only intended to be useful for LLVM. If we want to make it useful 
> outside of LLVM, that's fine, but there's a bit more to do (for example, the 
> check should be exposed outside of the `llvm` module) and that includes 
> generalizing the check.

There is https://reviews.llvm.org/D61508 which tries to generalise the 
llvm-header-guard check. Might be good to build on top of this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115715

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

[PATCH] D115253: [C2x] Support the *_WIDTH macros in limits.h and stdint.h

[James Y Knight via Phabricator via cfe-commits]

jyknight added inline comments.



Comment at: clang/lib/Frontend/InitPreprocessor.cpp:900-903
+  Builder.defineMacro("__USHRT_WIDTH__", Twine(TI.getShortWidth()));
+  Builder.defineMacro("__UINT_WIDTH__", Twine(TI.getIntWidth()));
+  Builder.defineMacro("__ULONG_WIDTH__", Twine(TI.getLongWidth()));
+  Builder.defineMacro("__ULLONG_WIDTH__", Twine(TI.getLongLongWidth()));

This seems odd? We define `__LONG_LONG_MAX__` but not `__LONG_LONG_WIDTH__`, 
for signed long long, and we define `__ULLONG_WIDTH__` but not 
`__ULLONG_MAX__`, for unsigned long long?



Comment at: clang/lib/Headers/stdint.h:728
+   in C2x mode; switch to the correct values once they've been published. */
+#if __STDC_VERSION__ >= 202000L
+/* NB: The C standard requires that these be the same value, but the compiler

Why are these conditioned on `__STDC_VERSION__` but the ones above, e.g. 
UINT64_WIDTH, are not?


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

https://reviews.llvm.org/D115253

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

[PATCH] D115149: [analyzer][solver] Fix assertion on (NonLoc, Op, Loc) expressions

[Denys Petrov via Phabricator via cfe-commits]

ASDenysPetrov added a comment.

@martong wrote:

> Denis, you can see in the `Revision Contents` that Diff 3 has the baseline 
> commit `63a6348`. When I check out `63a6348` then the newly added test file 
> triggers the assertion about `BO_Add`.

Yes is see it:
F21029827: image.png 
I don't get this feature. Is it a parent or something? Please explain how to 
interpret this table. And how can I use it myself and when?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115149

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

[PATCH] D115738: [clang-format] Code following C# Lambda Expressions has wrong formatting

[Peter Stys via Phabricator via cfe-commits]

peterstys updated this revision to Diff 394299.
peterstys added a comment.

Applied clang-formatting.


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

https://reviews.llvm.org/D115738

Files:
  clang/lib/Format/UnwrappedLineParser.cpp
  clang/unittests/Format/FormatTestCSharp.cpp

Index: clang/unittests/Format/FormatTestCSharp.cpp
===
--- clang/unittests/Format/FormatTestCSharp.cpp
+++ clang/unittests/Format/FormatTestCSharp.cpp
@@ -759,6 +759,128 @@
GoogleStyle);
 }
 
+TEST_F(FormatTestCSharp, CSharpLambdasDontBreakFollowingCodeAlignment) {
+  FormatStyle GoogleStyle = getGoogleStyle(FormatStyle::LK_CSharp);
+  FormatStyle MicrosoftStyle = getMicrosoftStyle(FormatStyle::LK_CSharp);
+
+  verifyFormat(R"(//
+public class Sample {
+  public void Test() {
+while (true) {
+  preBindEnumerators.RemoveAll(enumerator => !enumerator.MoveNext());
+  CodeThatFollowsLambda();
+  IsWellAligned();
+}
+  }
+})",
+   GoogleStyle);
+
+  verifyFormat(R"(//
+public class Sample
+{
+public void Test()
+{
+while (true)
+{
+preBindEnumerators.RemoveAll(enumerator => !enumerator.MoveNext());
+CodeThatFollowsLambda();
+IsWellAligned();
+}
+}
+})",
+   MicrosoftStyle);
+}
+
+TEST_F(FormatTestCSharp, CSharpLambdasComplexLambdasDontBreakAlignment) {
+  FormatStyle GoogleStyle = getGoogleStyle(FormatStyle::LK_CSharp);
+  FormatStyle MicrosoftStyle = getMicrosoftStyle(FormatStyle::LK_CSharp);
+
+  verifyFormat(R"(//
+public class Test
+{
+private static void ComplexLambda(BuildReport protoReport)
+{
+allSelectedScenes =
+veryVeryLongCollectionNameThatPutsTheLineLenghtAboveTheThresholds.Where(scene => scene.enabled)
+.Select(scene => scene.path)
+.ToArray();
+if (allSelectedScenes.Count == 0)
+{
+return;
+}
+Functions();
+AreWell();
+Aligned();
+AfterLambdaBlock();
+}
+})",
+   MicrosoftStyle);
+
+  verifyFormat(R"(//
+public class Test {
+  private static void ComplexLambda(BuildReport protoReport) {
+allSelectedScenes = veryVeryLongCollectionNameThatPutsTheLineLenghtAboveTheThresholds
+.Where(scene => scene.enabled)
+.Select(scene => scene.path)
+.ToArray();
+if (allSelectedScenes.Count == 0) {
+  return;
+}
+Functions();
+AreWell();
+Aligned();
+AfterLambdaBlock();
+  }
+})",
+   GoogleStyle);
+}
+
+TEST_F(FormatTestCSharp, CSharpLambdasMulipleLambdasDontBreakAlignment) {
+  FormatStyle GoogleStyle = getGoogleStyle(FormatStyle::LK_CSharp);
+  FormatStyle MicrosoftStyle = getMicrosoftStyle(FormatStyle::LK_CSharp);
+
+  verifyFormat(R"(//
+public class Test
+{
+private static void MultipleLambdas(BuildReport protoReport)
+{
+allSelectedScenes =
+veryVeryLongCollectionNameThatPutsTheLineLenghtAboveTheThresholds.Where(scene => scene.enabled)
+.Select(scene => scene.path)
+.ToArray();
+preBindEnumerators.RemoveAll(enumerator => !enumerator.MoveNext());
+if (allSelectedScenes.Count == 0)
+{
+return;
+}
+Functions();
+AreWell();
+Aligned();
+AfterLambdaBlock();
+}
+})",
+   MicrosoftStyle);
+
+  verifyFormat(R"(//
+public class Test {
+  private static void MultipleLambdas(BuildReport protoReport) {
+allSelectedScenes = veryVeryLongCollectionNameThatPutsTheLineLenghtAboveTheThresholds
+.Where(scene => scene.enabled)
+.Select(scene => scene.path)
+.ToArray();
+preBindEnumerators.RemoveAll(enumerator => !enumerator.MoveNext());
+if (allSelectedScenes.Count == 0) {
+  return;
+}
+Functions();
+AreWell();
+Aligned();
+AfterLambdaBlock();
+  }
+})",
+   GoogleStyle);
+}
+
 TEST_F(FormatTestCSharp, CSharpObjectInitializers) {
   FormatStyle Style = getGoogleStyle(FormatStyle::LK_CSharp);
 
Index: clang/lib/Format/UnwrappedLineParser.cpp
===
--- clang/lib/Format/UnwrappedLineParser.cpp
+++ clang/lib/Format/UnwrappedLineParser.cpp
@@ -2001,9 +2001,15 @@
   }
   break;
 case tok::equal:
-  if (Style.isCSharp() && FormatTok->is(TT_FatArrow))
-parseStructuralElement();
-  else
+  if (Style.isCSharp() && FormatTok->is(TT_FatArrow)) {
+nextToken();
+if (FormatTok->is(tok::l_brace)) {
+  if (Style.isCSharp() && Style.BraceWrapping.AfterFunction == true) {
+FormatTok->MustBreakBefore = true;
+  }
+  parseChildBlock();
+}
+  } else

[PATCH] D108560: [clang-tidy] Add support for `NOLINTBEGIN` ... `NOLINTEND` comments

[Salman Javed via Phabricator via cfe-commits]

salman-javed-nz added a comment.

In D108560#3192081 , @kadircet wrote:

> Hi @salman-javed-nz !
> Also I am not sure what kind of timelines you have in mind for the 
> performance improvements, but I think it would be great to have them before 
> LLVM-14 release, as otherwise we might have some (extra) discrepancies 
> between clang-tidy CLI vs clangd integration, which would be unfortunate.

Hi @kadircet. Today I fixed the last of the bugs in my caching implementation. 
I still need to run some tests to quantify what the performance improvement is 
before submitting the code for a review.

> Also I am not sure what kind of timelines you have in mind for the 
> performance improvements, but I think it would be great to have them before 
> LLVM-14 release, as otherwise we might have some (extra) discrepancies 
> between clang-tidy CLI vs clangd integration, which would be unfortunate.

Definitely before Clang 14. The patch is a few days away, not weeks or months 
away.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D108560

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

[PATCH] D113372: [Driver] Add CLANG_DEFAULT_PIE_ON_LINUX to emulate GCC --enable-default-pie

[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 rG1042de90589c: [Driver] Add CLANG_DEFAULT_PIE_ON_LINUX to 
emulate GCC --enable-default-pie (authored by MaskRay).

Changed prior to commit:
  https://reviews.llvm.org/D113372?vs=394015&id=394301#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113372

Files:
  clang/CMakeLists.txt
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Config/config.h.cmake
  clang/lib/Driver/ToolChains/Linux.cpp
  clang/test/Driver/fsanitize.c
  clang/test/Driver/linux-default-pie.c
  clang/test/Driver/linux-ld.c
  clang/test/lit.cfg.py
  clang/test/lit.site.cfg.py.in
  llvm/utils/gn/secondary/clang/include/clang/Config/BUILD.gn
  utils/bazel/llvm-project-overlay/clang/include/clang/Config/config.h

Index: utils/bazel/llvm-project-overlay/clang/include/clang/Config/config.h
===
--- utils/bazel/llvm-project-overlay/clang/include/clang/Config/config.h
+++ utils/bazel/llvm-project-overlay/clang/include/clang/Config/config.h
@@ -22,6 +22,9 @@
 /* Bug report URL. */
 #define BUG_REPORT_URL "https://bugs.llvm.org/";
 
+/* Default to -fPIE and -pie on Linux. */
+#define CLANG_DEFAULT_PIE_ON_LINUX 0
+
 /* Default linker to use. */
 #define CLANG_DEFAULT_LINKER ""
 
Index: llvm/utils/gn/secondary/clang/include/clang/Config/BUILD.gn
===
--- llvm/utils/gn/secondary/clang/include/clang/Config/BUILD.gn
+++ llvm/utils/gn/secondary/clang/include/clang/Config/BUILD.gn
@@ -9,6 +9,7 @@
   output = "$target_gen_dir/config.h"
   values = [
 "BUG_REPORT_URL=https://bugs.llvm.org/";,
+"CLANG_DEFAULT_PIE_ON_LINUX=0",
 "CLANG_DEFAULT_LINKER=",
 "CLANG_DEFAULT_STD_C=",
 "CLANG_DEFAULT_STD_CXX=",
Index: clang/test/lit.site.cfg.py.in
===
--- clang/test/lit.site.cfg.py.in
+++ clang/test/lit.site.cfg.py.in
@@ -22,6 +22,7 @@
 config.llvm_use_sanitizer = "@LLVM_USE_SANITIZER@"
 config.have_zlib = @LLVM_ENABLE_ZLIB@
 config.clang_arcmt = @CLANG_ENABLE_ARCMT@
+config.clang_default_pie_on_linux = "@CLANG_DEFAULT_PIE_ON_LINUX@"
 config.clang_default_cxx_stdlib = "@CLANG_DEFAULT_CXX_STDLIB@"
 config.clang_staticanalyzer = @CLANG_ENABLE_STATIC_ANALYZER@
 config.clang_staticanalyzer_z3 = "@LLVM_WITH_Z3@"
Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -121,6 +121,9 @@
 if config.has_plugins and config.llvm_plugin_ext:
 config.available_features.add('plugins')
 
+if config.clang_default_pie_on_linux == '1':
+config.available_features.add('default-pie-on-linux')
+
 # Set available features we allow tests to conditionalize on.
 #
 if config.clang_default_cxx_stdlib != '':
Index: clang/test/Driver/linux-ld.c
===
--- clang/test/Driver/linux-ld.c
+++ clang/test/Driver/linux-ld.c
@@ -1,4 +1,4 @@
-// UNSUPPORTED: system-windows
+// UNSUPPORTED: system-windows, default-pie-on-linux
 // General tests that ld invocations on Linux targets sane. Note that we use
 // sysroot to make these tests independent of the host system.
 //
Index: clang/test/Driver/linux-default-pie.c
===
--- /dev/null
+++ clang/test/Driver/linux-default-pie.c
@@ -0,0 +1,7 @@
+// REQUIRES: default-pie-on-linux
+/// Test -DCLANG_DEFAULT_PIE_ON_LINUX=on.
+
+// RUN: %clang -### --target=aarch64-linux-gnu %s 2>&1 | FileCheck %s --check-prefix=PIE2
+
+// PIE2: "-mrelocation-model" "pic" "-pic-level" "2" "-pic-is-pie"
+// PIE2: "-pie"
Index: clang/test/Driver/fsanitize.c
===
--- clang/test/Driver/fsanitize.c
+++ clang/test/Driver/fsanitize.c
@@ -1,3 +1,4 @@
+// UNSUPPORTED: default-pie-on-linux
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=undefined -fsanitize-trap=undefined %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-TRAP
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=undefined -fsanitize-trap=undefined -fno-sanitize-trap=signed-integer-overflow %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-TRAP2
 // RUN: %clang -target x86_64-linux-gnu -fsanitize=undefined -fsanitize-undefined-trap-on-error %s -### 2>&1 | FileCheck %s --check-prefix=CHECK-UNDEFINED-TRAP
Index: clang/lib/Driver/ToolChains/Linux.cpp
===
--- clang/lib/Driver/ToolChains/Linux.cpp
+++ clang/lib/Driver/ToolChains/Linux.cpp
@@ -663,8 +663,8 @@
 }
 
 bool Linux::isPIEDefault(const llvm::opt::ArgList &Args) const {
-  return getTriple().isAndroid() || getTriple().isMusl() ||
- getSanitizerArgs(Args).req

[clang] 0419242 - [Clang][ScanDeps] Use the virtual path for module maps

[Michael Spencer via cfe-commits]

Author: Michael Spencer
Date: 2021-12-14T11:21:42-07:00
New Revision: 04192422c4e3b730c580498b8e948088cb15580b

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

LOG: [Clang][ScanDeps] Use the virtual path for module maps

Make clang-scan-deps use the virtual path for module maps instead of the on disk
path. This is needed so that modulemap relative lookups are done correctly in
the actual module builds. The file dependencies still use the on disk path as
that's what matters for build invalidation.

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

Added: 
clang/test/ClangScanDeps/modulemap-via-vfs.m

Modified: 
clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp

Removed: 




diff  --git a/clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp 
b/clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
index 9229c67c41787..086215e7a573d 100644
--- a/clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
+++ b/clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
@@ -237,7 +237,13 @@ ModuleID ModuleDepCollectorPP::handleTopLevelModule(const 
Module *M) {
.getHeaderSearchInfo()
.getModuleMap()
.getModuleMapFileForUniquing(M);
-  MD.ClangModuleMapFile = std::string(ModuleMap ? ModuleMap->getName() : "");
+
+  if (ModuleMap) {
+StringRef Path = ModuleMap->tryGetRealPathName();
+if (Path.empty())
+  Path = ModuleMap->getName();
+MD.ClangModuleMapFile = std::string(Path);
+  }
 
   serialization::ModuleFile *MF =
   MDC.ScanInstance.getASTReader()->getModuleManager().lookup(

diff  --git a/clang/test/ClangScanDeps/modulemap-via-vfs.m 
b/clang/test/ClangScanDeps/modulemap-via-vfs.m
new file mode 100644
index 0..cc152b63f4831
--- /dev/null
+++ b/clang/test/ClangScanDeps/modulemap-via-vfs.m
@@ -0,0 +1,56 @@
+// RUN: rm -rf %t.dir
+// RUN: split-file %s %t.dir
+// RUN: sed -e "s|DIR|%/t.dir|g" %t.dir/build/compile-commands.json.in > 
%t.dir/build/compile-commands.json
+// RUN: sed -e "s|DIR|%/t.dir|g" %t.dir/build/vfs.yaml.in > 
%t.dir/build/vfs.yaml
+// RUN: clang-scan-deps -compilation-database 
%t.dir/build/compile-commands.json -j 1 -format experimental-full \
+// RUN:   -mode preprocess-minimized-sources -generate-modules-path-args > 
%t.db
+// RUN: %python %S/../../utils/module-deps-to-rsp.py %t.db --module-name=A > 
%t.A.cc1.rsp
+// RUN: cat %t.A.cc1.rsp | sed 's:\?:/:g' | FileCheck %s
+
+// CHECK-NOT: build/module.modulemap
+// CHECK: A/module.modulemap
+
+//--- build/compile-commands.json.in
+
+[
+{
+  "directory": "DIR",
+  "command": "clang DIR/main.m -Imodules/A -fmodules 
-fmodules-cache-path=module-cache -fimplicit-modules -fimplicit-module-maps 
-ivfsoverlay build/vfs.yaml",
+  "file": "DIR/main.m"
+}
+]
+
+//--- build/module.modulemap
+
+module A {
+  umbrella header "A.h"
+}
+
+//--- modules/A/A.h
+
+typedef int A_t;
+
+//--- build/vfs.yaml.in
+
+{
+  "version": 0,
+  "case-sensitive": "false",
+  "roots": [
+  {
+ "contents": [
+ {
+"external-contents": "DIR/build/module.modulemap",
+"name": "module.modulemap",
+"type": "file"
+ }],
+ "name": "DIR/modules/A",
+ "type": "directory"
+  }
+  ]
+}
+
+//--- main.m
+
+@import A;
+
+A_t a = 0;



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

[PATCH] D114206: [Clang][ScanDeps] Use the virtual path for module maps

[Michael Spencer 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 rG04192422c4e3: [Clang][ScanDeps] Use the virtual path for 
module maps (authored by Bigcheese).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114206

Files:
  clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
  clang/test/ClangScanDeps/modulemap-via-vfs.m


Index: clang/test/ClangScanDeps/modulemap-via-vfs.m
===
--- /dev/null
+++ clang/test/ClangScanDeps/modulemap-via-vfs.m
@@ -0,0 +1,56 @@
+// RUN: rm -rf %t.dir
+// RUN: split-file %s %t.dir
+// RUN: sed -e "s|DIR|%/t.dir|g" %t.dir/build/compile-commands.json.in > 
%t.dir/build/compile-commands.json
+// RUN: sed -e "s|DIR|%/t.dir|g" %t.dir/build/vfs.yaml.in > 
%t.dir/build/vfs.yaml
+// RUN: clang-scan-deps -compilation-database 
%t.dir/build/compile-commands.json -j 1 -format experimental-full \
+// RUN:   -mode preprocess-minimized-sources -generate-modules-path-args > 
%t.db
+// RUN: %python %S/../../utils/module-deps-to-rsp.py %t.db --module-name=A > 
%t.A.cc1.rsp
+// RUN: cat %t.A.cc1.rsp | sed 's:\?:/:g' | FileCheck %s
+
+// CHECK-NOT: build/module.modulemap
+// CHECK: A/module.modulemap
+
+//--- build/compile-commands.json.in
+
+[
+{
+  "directory": "DIR",
+  "command": "clang DIR/main.m -Imodules/A -fmodules 
-fmodules-cache-path=module-cache -fimplicit-modules -fimplicit-module-maps 
-ivfsoverlay build/vfs.yaml",
+  "file": "DIR/main.m"
+}
+]
+
+//--- build/module.modulemap
+
+module A {
+  umbrella header "A.h"
+}
+
+//--- modules/A/A.h
+
+typedef int A_t;
+
+//--- build/vfs.yaml.in
+
+{
+  "version": 0,
+  "case-sensitive": "false",
+  "roots": [
+  {
+ "contents": [
+ {
+"external-contents": "DIR/build/module.modulemap",
+"name": "module.modulemap",
+"type": "file"
+ }],
+ "name": "DIR/modules/A",
+ "type": "directory"
+  }
+  ]
+}
+
+//--- main.m
+
+@import A;
+
+A_t a = 0;
Index: clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
===
--- clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
+++ clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
@@ -237,7 +237,13 @@
.getHeaderSearchInfo()
.getModuleMap()
.getModuleMapFileForUniquing(M);
-  MD.ClangModuleMapFile = std::string(ModuleMap ? ModuleMap->getName() : "");
+
+  if (ModuleMap) {
+StringRef Path = ModuleMap->tryGetRealPathName();
+if (Path.empty())
+  Path = ModuleMap->getName();
+MD.ClangModuleMapFile = std::string(Path);
+  }
 
   serialization::ModuleFile *MF =
   MDC.ScanInstance.getASTReader()->getModuleManager().lookup(


Index: clang/test/ClangScanDeps/modulemap-via-vfs.m
===
--- /dev/null
+++ clang/test/ClangScanDeps/modulemap-via-vfs.m
@@ -0,0 +1,56 @@
+// RUN: rm -rf %t.dir
+// RUN: split-file %s %t.dir
+// RUN: sed -e "s|DIR|%/t.dir|g" %t.dir/build/compile-commands.json.in > %t.dir/build/compile-commands.json
+// RUN: sed -e "s|DIR|%/t.dir|g" %t.dir/build/vfs.yaml.in > %t.dir/build/vfs.yaml
+// RUN: clang-scan-deps -compilation-database %t.dir/build/compile-commands.json -j 1 -format experimental-full \
+// RUN:   -mode preprocess-minimized-sources -generate-modules-path-args > %t.db
+// RUN: %python %S/../../utils/module-deps-to-rsp.py %t.db --module-name=A > %t.A.cc1.rsp
+// RUN: cat %t.A.cc1.rsp | sed 's:\?:/:g' | FileCheck %s
+
+// CHECK-NOT: build/module.modulemap
+// CHECK: A/module.modulemap
+
+//--- build/compile-commands.json.in
+
+[
+{
+  "directory": "DIR",
+  "command": "clang DIR/main.m -Imodules/A -fmodules -fmodules-cache-path=module-cache -fimplicit-modules -fimplicit-module-maps -ivfsoverlay build/vfs.yaml",
+  "file": "DIR/main.m"
+}
+]
+
+//--- build/module.modulemap
+
+module A {
+  umbrella header "A.h"
+}
+
+//--- modules/A/A.h
+
+typedef int A_t;
+
+//--- build/vfs.yaml.in
+
+{
+  "version": 0,
+  "case-sensitive": "false",
+  "roots": [
+  {
+ "contents": [
+ {
+"external-contents": "DIR/build/module.modulemap",
+"name": "module.modulemap",
+"type": "file"
+ }],
+ "name": "DIR/modules/A",
+ "type": "directory"
+  }
+  ]
+}
+
+//--- main.m
+
+@import A;
+
+A_t a = 0;
Index: clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
===
--- clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
+++ clang/lib/Tooling/DependencyScanning/ModuleDepCollector.cpp
@@ -237,7 +237,13 @@
.getHeaderSearchInfo()
.getModuleMap()

[clang] 4e94cba - [HIPSPV][2/4] Add HIPSPV tool chain

[Artem Belevich via cfe-commits]

Author: Henry Linjamäki
Date: 2021-12-14T10:22:38-08:00
New Revision: 4e94cba5b4e431794026085b89a34112b2d9ac0d

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

LOG: [HIPSPV][2/4] Add HIPSPV tool chain

This patch adds a new tool chain, HIPSPVToolChain, for emitting HIP
device code as SPIR-V binary. The SPIR-V binary is emitted by using an
external tool, SPIRV-LLVM-Translator, temporarily. We intend to switch
the translator to the llc tool when the SPIR-V backend lands on LLVM
and proves to work well on HIP implementations which consume SPIR-V.

Before the SPIR-V emission the tool chain loads an optional external
pass plugin, either automatically from a HIP installation or from a
path pointed by --hipspv-pass-plugin, and runs passes that are meant
to expand/lower HIP features that do not have direct counterpart in
SPIR-V (e.g. dynamic shared memory).

Code emission for SPIR-V will be enabled and HIPSPVToolChain tests
will be added in the follow up patch part 3.

Other changes: New option ‘-nohipwrapperinc’ is added to exclude HIP
include wrappers. The reason for the addition is that they cause
compile errors when compiling HIP sources for the host side for HIPCL
and HIPLZ implementations. New option is added to avoid this issue.

Reviewed By: tra

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

Added: 
clang/lib/Driver/ToolChains/HIPSPV.cpp
clang/lib/Driver/ToolChains/HIPSPV.h

Modified: 
clang/include/clang/Basic/DiagnosticDriverKinds.td
clang/include/clang/Driver/Options.td
clang/lib/Driver/CMakeLists.txt
clang/lib/Driver/ToolChains/AMDGPU.cpp

Removed: 




diff  --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td 
b/clang/include/clang/Basic/DiagnosticDriverKinds.td
index 3638d07cc3b35..c01ee11d2ce24 100644
--- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -74,6 +74,14 @@ def err_drv_no_hip_runtime : Error<
   "cannot find HIP runtime; provide its path via '--rocm-path', or pass "
   "'-nogpuinc' to build without HIP runtime">;
 
+def err_drv_no_hipspv_device_lib : Error<
+  "cannot find HIP device library%select{| for %1}0; provide its path via "
+  "'--hip-path' or '--hip-device-lib-path', or pass '-nogpulib' to build "
+  "without HIP device library">;
+def err_drv_hipspv_no_hip_path : Error<
+  "'--hip-path' must be specified when offloading to "
+  "SPIR-V%select{| unless %1 is given}0.">;
+
 def err_drv_undetermined_amdgpu_arch : Error<
   "cannot determine AMDGPU architecture: %0; consider passing it via "
   "'--march'">;

diff  --git a/clang/include/clang/Driver/Options.td 
b/clang/include/clang/Driver/Options.td
index e9c3ece3d1634..9e0832822a0dd 100644
--- a/clang/include/clang/Driver/Options.td
+++ b/clang/include/clang/Driver/Options.td
@@ -985,6 +985,9 @@ defm hip_fp32_correctly_rounded_divide_sqrt : 
BoolFOption<"hip-fp32-correctly-ro
   BothFlags<[], " that single precision floating-point divide and sqrt used in 
"
   "the program source are correctly rounded (HIP device compilation only)">>,
   ShouldParseIf;
+def hipspv_pass_plugin_EQ : Joined<["--"], "hipspv-pass-plugin=">,
+  Group, MetaVarName<"">,
+  HelpText<"path to a pass plugin for HIP to SPIR-V passes.">;
 defm gpu_allow_device_init : BoolFOption<"gpu-allow-device-init",
   LangOpts<"GPUAllowDeviceInit">, DefaultFalse,
   PosFlag, NegFlag,
@@ -3763,6 +3766,8 @@ def nobuiltininc : Flag<["-"], "nobuiltininc">, 
Flags<[CC1Option, CoreOption]>,
   MarshallingInfoNegativeFlag>;
 def nogpuinc : Flag<["-"], "nogpuinc">, HelpText<"Do not add include paths for 
CUDA/HIP and"
   " do not include the default CUDA/HIP wrapper headers">;
+def nohipwrapperinc : Flag<["-"], "nohipwrapperinc">,
+  HelpText<"Do not include the default HIP wrapper headers and include paths">;
 def : Flag<["-"], "nocudainc">, Alias;
 def nogpulib : Flag<["-"], "nogpulib">,
   HelpText<"Do not link device library for CUDA/HIP device compilation">;

diff  --git a/clang/lib/Driver/CMakeLists.txt b/clang/lib/Driver/CMakeLists.txt
index 3083cae8ad096..78e8fd1852841 100644
--- a/clang/lib/Driver/CMakeLists.txt
+++ b/clang/lib/Driver/CMakeLists.txt
@@ -55,6 +55,7 @@ add_clang_library(clangDriver
   ToolChains/Haiku.cpp
   ToolChains/HIPUtility.cpp
   ToolChains/HIPAMD.cpp
+  ToolChains/HIPSPV.cpp
   ToolChains/Hexagon.cpp
   ToolChains/Hurd.cpp
   ToolChains/Linux.cpp

diff  --git a/clang/lib/Driver/ToolChains/AMDGPU.cpp 
b/clang/lib/Driver/ToolChains/AMDGPU.cpp
index b5eaf1adca6b5..43ce33750ebac 100644
--- a/clang/lib/Driver/ToolChains/AMDGPU.cpp
+++ b/clang/lib/Driver/ToolChains/AMDGPU.cpp
@@ -478,7 +478,8 @@ void RocmInstallationDetector::print(raw_ostream &OS) const 
{
 
 void RocmInstallationDetector::AddHIPIncludeArgs(const ArgList &Dri

[PATCH] D110618: [HIPSPV][2/4] Add HIPSPV tool chain

[Artem Belevich 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 rG4e94cba5b4e4: [HIPSPV][2/4] Add HIPSPV tool chain (authored 
by linjamaki, committed by tra).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D110618

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/CMakeLists.txt
  clang/lib/Driver/ToolChains/AMDGPU.cpp
  clang/lib/Driver/ToolChains/HIPSPV.cpp
  clang/lib/Driver/ToolChains/HIPSPV.h

Index: clang/lib/Driver/ToolChains/HIPSPV.h
===
--- /dev/null
+++ clang/lib/Driver/ToolChains/HIPSPV.h
@@ -0,0 +1,103 @@
+//===--- HIPSPV.h - HIP ToolChain Implementations ---*- C++ -*-===//
+//
+// 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
+//
+//===--===//
+
+#ifndef LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_HIPSPV_H
+#define LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_HIPSPV_H
+
+#include "SPIRV.h"
+#include "clang/Driver/Tool.h"
+#include "clang/Driver/ToolChain.h"
+
+namespace clang {
+namespace driver {
+namespace tools {
+namespace HIPSPV {
+
+// Runs llvm-link/opt/llc/lld, which links multiple LLVM bitcode, together with
+// device library, then compiles it to SPIR-V in a shared object.
+class LLVM_LIBRARY_VISIBILITY Linker : public Tool {
+public:
+  Linker(const ToolChain &TC) : Tool("HIPSPV::Linker", "hipspv-link", TC) {}
+
+  bool hasIntegratedCPP() const override { return false; }
+
+  void ConstructJob(Compilation &C, const JobAction &JA,
+const InputInfo &Output, const InputInfoList &Inputs,
+const llvm::opt::ArgList &TCArgs,
+const char *LinkingOutput) const override;
+
+private:
+  void constructLinkAndEmitSpirvCommand(Compilation &C, const JobAction &JA,
+const InputInfoList &Inputs,
+const InputInfo &Output,
+const llvm::opt::ArgList &Args) const;
+};
+
+} // namespace HIPSPV
+} // namespace tools
+
+namespace toolchains {
+
+class LLVM_LIBRARY_VISIBILITY HIPSPVToolChain final : public ToolChain {
+public:
+  HIPSPVToolChain(const Driver &D, const llvm::Triple &Triple,
+  const ToolChain &HostTC, const llvm::opt::ArgList &Args);
+
+  const llvm::Triple *getAuxTriple() const override {
+return &HostTC.getTriple();
+  }
+
+  void
+  addClangTargetOptions(const llvm::opt::ArgList &DriverArgs,
+llvm::opt::ArgStringList &CC1Args,
+Action::OffloadKind DeviceOffloadKind) const override;
+  void addClangWarningOptions(llvm::opt::ArgStringList &CC1Args) const override;
+  CXXStdlibType GetCXXStdlibType(const llvm::opt::ArgList &Args) const override;
+  void
+  AddClangSystemIncludeArgs(const llvm::opt::ArgList &DriverArgs,
+llvm::opt::ArgStringList &CC1Args) const override;
+  void AddClangCXXStdlibIncludeArgs(
+  const llvm::opt::ArgList &Args,
+  llvm::opt::ArgStringList &CC1Args) const override;
+  void AddIAMCUIncludeArgs(const llvm::opt::ArgList &DriverArgs,
+   llvm::opt::ArgStringList &CC1Args) const override;
+  void AddHIPIncludeArgs(const llvm::opt::ArgList &DriverArgs,
+ llvm::opt::ArgStringList &CC1Args) const override;
+  llvm::SmallVector
+  getHIPDeviceLibs(const llvm::opt::ArgList &Args) const override;
+
+  SanitizerMask getSupportedSanitizers() const override;
+
+  VersionTuple
+  computeMSVCVersion(const Driver *D,
+ const llvm::opt::ArgList &Args) const override;
+
+  void adjustDebugInfoKind(codegenoptions::DebugInfoKind &DebugInfoKind,
+   const llvm::opt::ArgList &Args) const override;
+  bool IsIntegratedAssemblerDefault() const override { return true; }
+  bool IsMathErrnoDefault() const override { return false; }
+  bool useIntegratedAs() const override { return true; }
+  bool isCrossCompiling() const override { return true; }
+  bool isPICDefault() const override { return false; }
+  bool isPIEDefault(const llvm::opt::ArgList &Args) const override {
+return false;
+  }
+  bool isPICDefaultForced() const override { return false; }
+  bool SupportsProfiling() const override { return false; }
+
+  const ToolChain &HostTC;
+
+protected:
+  Tool *buildLinker() const override;
+};
+
+} // end namespace toolchains
+} // end namespace driver
+} // end namespace clang
+
+#endif // LLVM_CLANG_LIB_DRIVER_TOOLCHAINS_HIPSPV_H
Index: clang/lib/Driver/ToolChains/HIPSPV.cpp
==

[PATCH] D115253: [C2x] Support the *_WIDTH macros in limits.h and stdint.h

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Frontend/InitPreprocessor.cpp:900-903
+  Builder.defineMacro("__USHRT_WIDTH__", Twine(TI.getShortWidth()));
+  Builder.defineMacro("__UINT_WIDTH__", Twine(TI.getIntWidth()));
+  Builder.defineMacro("__ULONG_WIDTH__", Twine(TI.getLongWidth()));
+  Builder.defineMacro("__ULLONG_WIDTH__", Twine(TI.getLongLongWidth()));

jyknight wrote:
> This seems odd? We define `__LONG_LONG_MAX__` but not `__LONG_LONG_WIDTH__`, 
> for signed long long, and we define `__ULLONG_WIDTH__` but not 
> `__ULLONG_MAX__`, for unsigned long long?
> This seems odd?

Yeah, this stuff is a bit twisty.

> We define __LONG_LONG_MAX__ but not __LONG_LONG_WIDTH__, for signed long long,

Correct.

> and we define __ULLONG_WIDTH__ but not __ULLONG_MAX__, for unsigned long long?

Correct.

The basic approach I took was: for types with signed/unsigned pairs, define the 
`unsigned` variants with an underscore name and use them to define the `signed` 
variants in the header file because the width of signed and unsigned has to be 
the same per spec ("The macro blah_WIDTH represents the width of the type blah 
and shall expand to the same value as Ublah_WIDTH.") So that's why you 
generally only see the "unsigned" width variants added here with a double 
underscore name. I could expose the signed versions as well (like we do for 
many of the MAX macros), but that makes the preprocessor slower for no real 
benefit as we want the users to use the non-underscore versions of these macros 
whenever possible.



Comment at: clang/lib/Headers/stdint.h:728
+   in C2x mode; switch to the correct values once they've been published. */
+#if __STDC_VERSION__ >= 202000L
+/* NB: The C standard requires that these be the same value, but the compiler

jyknight wrote:
> Why are these conditioned on `__STDC_VERSION__` but the ones above, e.g. 
> UINT64_WIDTH, are not?
Good catch, that's a think-o on my part! And it's even a think-o in the test 
files!
```
#if defined(INT64_MAX)
_Static_assert(INT64_WIDTH == 64, "");
_Static_assert(UINT64_WIDTH == INT64_WIDTH, "");
_Static_assert(INT64_WIDTH / __CHAR_BIT__ == sizeof(int64_t), "");
_Static_assert(UINT64_WIDTH / __CHAR_BIT__ == sizeof(uint64_t), "");
#else
int INT64_WIDTH, UINT64_WIDTH; /* None of these are defined. */
#endif
```
That predicate is wrong; it should be testing the standard version *and* the 
presence of the type, not just the presence of the type alone. (We always have 
the 8, 16, 32, and 64 types, so the test for "none of these are defined" is 
never run.)


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

https://reviews.llvm.org/D115253

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

[PATCH] D114639: Raise the minimum Visual Studio version to VS2019

[Stella Stamenova via Phabricator via cfe-commits]

stella.stamenova added a comment.

In D114639#3191752 , @RKSimon wrote:

> @rnk @stella.stamenova How long do you think it will be before you can update 
> your buildbots to VS2019 or VS2022 please?

The mlir buildbot was updated already. The lldb buildbot will be done this week 
- there's a test change that needs to happen in lldb before we can update the 
buildbot. I'll let you know once it's done.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D114639

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

[PATCH] D115503: [DebugInfo][Clang] record the access flag for class/struct/union types.

[David Blaikie via Phabricator via cfe-commits]

dblaikie added a comment.

In D115503#3191156 , @Esme wrote:

> In D115503#3188302 , @dblaikie 
> wrote:
>
>> Got any data on how much this (combined with the LLVM patch) increases debug 
>> info size of, say, a clang self-host build? I assume not much, but wouldn't 
>> hurt to know.
>
>
>
> | section   | before | after  |
> | .debug_loc| 929821 | 929821 |
> | .debug_abbrev | 5885289  | 5971547  |
> | .debug_info   | 497613455  | 498122074  |
> | .debug_ranges | 45731664  | 45731664  |
> | .debug_str| 233842595  | 233839388  |
> | .debug_line   | 149773166  | 149764583  |
> |
>
> I built two self-host Clangs with and without the two patches and got the 
> results shown in the table, and I think the increase of size is acceptable?
>
>> (does GCC produce this sort of debug info, or does it skip the access 
>> specifiers on nested types?)
>
> Yes, GCC also emits the access attribute for nested types when the access 
> level doesn't equal to the default.

Thanks for the data - looks good to me. Maybe include some of that data 
(summary of total binary size change/total debug info size change - and if you 
could include the flags (was this an -O0 -g build? Optimized (at what level)? 
Compressed debug info (-gz)? etc) that'd be helpful to better understand the 
comparison.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115503

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

[PATCH] D115253: [C2x] Support the *_WIDTH macros in limits.h and stdint.h

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman updated this revision to Diff 394320.
aaron.ballman added a comment.

Updated based on review feedback. This protects all of the _WIDTH macros in 
stdint.h, which was a previous oversight. It also corrects the test case to 
actually test the scenario we care about (which requires that we look at the 
standard version).


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

https://reviews.llvm.org/D115253

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Frontend/InitPreprocessor.cpp
  clang/lib/Headers/limits.h
  clang/lib/Headers/stdint.h
  clang/test/Headers/limits.cpp
  clang/test/Headers/stdint.c
  clang/test/Preprocessor/init-aarch64.c
  clang/test/Preprocessor/init.c
  clang/www/c_status.html

Index: clang/www/c_status.html
===
--- clang/www/c_status.html
+++ clang/www/c_status.html
@@ -715,11 +715,7 @@
 
   Two's complement sign representation
   http://www.open-std.org/jtc1/sc22/wg14/www/docs/n2412.pdf";>N2412
-  
-Partial
-  Lacking width macros in limits.h and stdint.h
-
-  
+  Clang 14
 
 
   Adding the u8 character prefix
Index: clang/test/Preprocessor/init.c
===
--- clang/test/Preprocessor/init.c
+++ clang/test/Preprocessor/init.c
@@ -1519,6 +1519,7 @@
 // WEBASSEMBLY-NEXT:#define __ATOMIC_RELEASE 3
 // WEBASSEMBLY-NEXT:#define __ATOMIC_SEQ_CST 5
 // WEBASSEMBLY-NEXT:#define __BIGGEST_ALIGNMENT__ 16
+// WEBASSEMBLY-NEXT:#define __BOOL_WIDTH__ 8
 // WEBASSEMBLY-NEXT:#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
 // WEBASSEMBLY-NEXT:#define __CHAR16_TYPE__ unsigned short
 // WEBASSEMBLY-NEXT:#define __CHAR32_TYPE__ unsigned int
@@ -1608,21 +1609,25 @@
 // WEBASSEMBLY-NEXT:#define __INT16_FMTi__ "hi"
 // WEBASSEMBLY-NEXT:#define __INT16_MAX__ 32767
 // WEBASSEMBLY-NEXT:#define __INT16_TYPE__ short
+// WEBASSEMBLY-NEXT:#define __INT16_WIDTH__ 16
 // WEBASSEMBLY-NEXT:#define __INT32_C_SUFFIX__
 // WEBASSEMBLY-NEXT:#define __INT32_FMTd__ "d"
 // WEBASSEMBLY-NEXT:#define __INT32_FMTi__ "i"
 // WEBASSEMBLY-NEXT:#define __INT32_MAX__ 2147483647
 // WEBASSEMBLY-NEXT:#define __INT32_TYPE__ int
+// WEBASSEMBLY-NEXT:#define __INT32_WIDTH__ 32
 // WEBASSEMBLY-NEXT:#define __INT64_C_SUFFIX__ LL
 // WEBASSEMBLY-NEXT:#define __INT64_FMTd__ "lld"
 // WEBASSEMBLY-NEXT:#define __INT64_FMTi__ "lli"
 // WEBASSEMBLY-NEXT:#define __INT64_MAX__ 9223372036854775807LL
 // WEBASSEMBLY-NEXT:#define __INT64_TYPE__ long long int
+// WEBASSEMBLY-NEXT:#define __INT64_WIDTH__ 64
 // WEBASSEMBLY-NEXT:#define __INT8_C_SUFFIX__
 // WEBASSEMBLY-NEXT:#define __INT8_FMTd__ "hhd"
 // WEBASSEMBLY-NEXT:#define __INT8_FMTi__ "hhi"
 // WEBASSEMBLY-NEXT:#define __INT8_MAX__ 127
 // WEBASSEMBLY-NEXT:#define __INT8_TYPE__ signed char
+// WEBASSEMBLY-NEXT:#define __INT8_WIDTH__ 8
 // WEBASSEMBLY-NEXT:#define __INTMAX_C_SUFFIX__ LL
 // WEBASSEMBLY-NEXT:#define __INTMAX_FMTd__ "lld"
 // WEBASSEMBLY-NEXT:#define __INTMAX_FMTi__ "lli"
@@ -1640,34 +1645,42 @@
 // WEBASSEMBLY-NEXT:#define __INT_FAST16_FMTi__ "hi"
 // WEBASSEMBLY-NEXT:#define __INT_FAST16_MAX__ 32767
 // WEBASSEMBLY-NEXT:#define __INT_FAST16_TYPE__ short
+// WEBASSEMBLY-NEXT:#define __INT_FAST16_WIDTH__ 16
 // WEBASSEMBLY-NEXT:#define __INT_FAST32_FMTd__ "d"
 // WEBASSEMBLY-NEXT:#define __INT_FAST32_FMTi__ "i"
 // WEBASSEMBLY-NEXT:#define __INT_FAST32_MAX__ 2147483647
 // WEBASSEMBLY-NEXT:#define __INT_FAST32_TYPE__ int
+// WEBASSEMBLY-NEXT:#define __INT_FAST32_WIDTH__ 32
 // WEBASSEMBLY-NEXT:#define __INT_FAST64_FMTd__ "lld"
 // WEBASSEMBLY-NEXT:#define __INT_FAST64_FMTi__ "lli"
 // WEBASSEMBLY-NEXT:#define __INT_FAST64_MAX__ 9223372036854775807LL
 // WEBASSEMBLY-NEXT:#define __INT_FAST64_TYPE__ long long int
+// WEBASSEMBLY-NEXT:#define __INT_FAST64_WIDTH__ 64
 // WEBASSEMBLY-NEXT:#define __INT_FAST8_FMTd__ "hhd"
 // WEBASSEMBLY-NEXT:#define __INT_FAST8_FMTi__ "hhi"
 // WEBASSEMBLY-NEXT:#define __INT_FAST8_MAX__ 127
 // WEBASSEMBLY-NEXT:#define __INT_FAST8_TYPE__ signed char
+// WEBASSEMBLY-NEXT:#define __INT_FAST8_WIDTH__ 8
 // WEBASSEMBLY-NEXT:#define __INT_LEAST16_FMTd__ "hd"
 // WEBASSEMBLY-NEXT:#define __INT_LEAST16_FMTi__ "hi"
 // WEBASSEMBLY-NEXT:#define __INT_LEAST16_MAX__ 32767
 // WEBASSEMBLY-NEXT:#define __INT_LEAST16_TYPE__ short
+// WEBASSEMBLY-NEXT:#define __INT_LEAST16_WIDTH__ 16
 // WEBASSEMBLY-NEXT:#define __INT_LEAST32_FMTd__ "d"
 // WEBASSEMBLY-NEXT:#define __INT_LEAST32_FMTi__ "i"
 // WEBASSEMBLY-NEXT:#define __INT_LEAST32_MAX__ 2147483647
 // WEBASSEMBLY-NEXT:#define __INT_LEAST32_TYPE__ int
+// WEBASSEMBLY-NEXT:#define __INT_LEAST32_WIDTH__ 32
 // WEBASSEMBLY-NEXT:#define __INT_LEAST64_FMTd__ "lld"
 // WEBASSEMBLY-NEXT:#define __INT_LEAST64_FMTi__ "lli"
 // WEBASSEMBLY-NEXT:#define __INT_LEAST64_MAX__ 9223372036854775807LL
 // WEBASSEMBLY-NEXT:#define __INT_LEAST64_TYPE__ long long int
+// WEBASSEMBLY-NEXT:#define __INT_LEAST64_WIDTH__ 64
 // W

[PATCH] D113245: [Sema] Mark explicit specialization declaration in a friend invalid

[Yuanfang Chen via Phabricator via cfe-commits]

ychen added a comment.

ping:-)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113245

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

[PATCH] D113245: [Sema] Mark explicit specialization declaration in a friend invalid

[Yuanfang Chen via Phabricator via cfe-commits]

ychen added a comment.

Hi @aaron.ballman, does this make sense to you? Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113245

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

[clang] bc5f2d1 - [clang] diagnose_as_builtin attribute for Fortify diagnosing like builtins.

[Michael Benfield via cfe-commits]

Author: Michael Benfield
Date: 2021-12-14T19:42:23Z
New Revision: bc5f2d12cadce765620efc56a1ca815221db47af

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

LOG: [clang] diagnose_as_builtin attribute for Fortify diagnosing like builtins.

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

Added: 
clang/test/Sema/attr-diagnose-as-builtin.c

Modified: 
clang/include/clang/Basic/Attr.td
clang/include/clang/Basic/AttrDocs.td
clang/include/clang/Basic/DiagnosticSemaKinds.td
clang/include/clang/Sema/ParsedAttr.h
clang/lib/Sema/SemaChecking.cpp
clang/lib/Sema/SemaDeclAttr.cpp
clang/test/Misc/pragma-attribute-supported-attributes-list.test

Removed: 




diff  --git a/clang/include/clang/Basic/Attr.td 
b/clang/include/clang/Basic/Attr.td
index fab3f3edfb831..10c5c7f1b879a 100644
--- a/clang/include/clang/Basic/Attr.td
+++ b/clang/include/clang/Basic/Attr.td
@@ -3865,6 +3865,14 @@ def ReleaseHandle : InheritableParamAttr {
   let Documentation = [ReleaseHandleDocs];
 }
 
+def DiagnoseAsBuiltin : InheritableAttr {
+  let Spellings = [Clang<"diagnose_as_builtin">];
+  let Args = [DeclArgument,
+  VariadicUnsignedArgument<"ArgIndices">];
+  let Subjects = SubjectList<[Function]>;
+  let Documentation = [DiagnoseAsBuiltinDocs];
+}
+
 def Builtin : InheritableAttr {
   let Spellings = [];
   let Args = [UnsignedArgument<"ID">];

diff  --git a/clang/include/clang/Basic/AttrDocs.td 
b/clang/include/clang/Basic/AttrDocs.td
index b005284eb492e..8a7424a88c9f8 100644
--- a/clang/include/clang/Basic/AttrDocs.td
+++ b/clang/include/clang/Basic/AttrDocs.td
@@ -5984,6 +5984,50 @@ attribute requires a string literal argument to identify 
the handle being releas
   }];
 }
 
+def DiagnoseAsBuiltinDocs : Documentation {
+  let Category = DocCatFunction;
+  let Content = [{
+The ``diagnose_as_builtin` attribute indicates that Fortify diagnostics are to
+be applied to the declared function as if it were the function specified by the
+attribute. The builtin function whose diagnostics are to be mimicked should be
+given. In addition, the order in which arguments should be applied must also
+be given.
+
+For example, the attribute can be used as follows.
+
+  .. code-block:: c
+
+__attribute__((diagnose_as_builtin(__builtin_memset, 3, 2, 1)))
+void *mymemset(int n, int c, void *s) {
+  // ...
+}
+
+This indicates that calls to ``mymemset`` should be diagnosed as if they were
+calls to ``__builtin_memset``. The arguments ``3, 2, 1`` indicate by index the
+order in which arguments of ``mymemset`` should be applied to
+``__builtin_memset``. The third argument should be applied first, then the
+second, and then the first. Thus (when Fortify warnings are enabled) the call
+``mymemset(n, c, s)`` will diagnose overflows as if it were the call
+``__builtin_memset(s, c, n)``.
+
+For variadic functions, the variadic arguments must come in the same order as
+they would to the builtin function, after all normal arguments. For instance,
+to diagnose a new function as if it were `sscanf`, we can use the attribute as
+follows.
+
+  .. code-block:: c
+  __attribute__((diagnose_as_builtin(sscanf, 1, 2)))
+  int mysscanf(const char *str, const char *format, ...)  {
+// ...
+  }
+
+Then the call `mysscanf("abc def", "%4s %4s", buf1, buf2)` will be diagnosed as
+if it were the call `sscanf("abc def", "%4s %4s", buf1, buf2)`.
+
+This attribute cannot be applied to non-static member functions.
+}];
+}
+
 def ArmSveVectorBitsDocs : Documentation {
   let Category = DocCatType;
   let Content = [{

diff  --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 29d389ee0b0d7..038067521559c 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -2956,6 +2956,17 @@ def err_attribute_invalid_argument : Error<
 def err_attribute_wrong_number_arguments : Error<
   "%0 attribute %plural{0:takes no arguments|1:takes one argument|"
   ":requires exactly %1 arguments}1">;
+def err_attribute_wrong_number_arguments_for : Error <
+  "%0 attribute references function %1, which %plural{0:takes no 
arguments|1:takes one argument|"
+  ":takes exactly %2 arguments}2">;
+def err_attribute_bounds_for_function : Error<
+  "%0 attribute references parameter %1, but the function %2 has only %3 
parameters">;
+def err_attribute_no_member_function : Error<
+  "%0 attribute cannot be applied to non-static member functions">;
+def err_attribute_parameter_types : Error<
+  "%0 attribute parameter types do not match: parameter %1 of function %2 has 
type %3, "
+  "but parameter %4 of function %5 has type %6">;
+
 def err_attribute_too_many_arguments : Error<
   "%0 attribute takes

[PATCH] D112024: [clang] diagnose_as attribute for Fortify diagnosing like builtins.

[Michael Benfield 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 rGbc5f2d12cadc: [clang] diagnose_as_builtin attribute for 
Fortify diagnosing like builtins. (authored by mbenfield).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D112024

Files:
  clang/include/clang/Basic/Attr.td
  clang/include/clang/Basic/AttrDocs.td
  clang/include/clang/Basic/DiagnosticSemaKinds.td
  clang/include/clang/Sema/ParsedAttr.h
  clang/lib/Sema/SemaChecking.cpp
  clang/lib/Sema/SemaDeclAttr.cpp
  clang/test/Misc/pragma-attribute-supported-attributes-list.test
  clang/test/Sema/attr-diagnose-as-builtin.c

Index: clang/test/Sema/attr-diagnose-as-builtin.c
===
--- /dev/null
+++ clang/test/Sema/attr-diagnose-as-builtin.c
@@ -0,0 +1,118 @@
+// RUN: %clang_cc1 -Wfortify-source -triple x86_64-apple-macosx10.14.0 %s -verify
+// RUN: %clang_cc1 -Wfortify-source -xc++ -triple x86_64-apple-macosx10.14.0 %s -verify
+
+typedef unsigned long size_t;
+
+__attribute__((diagnose_as_builtin(__builtin_memcpy, 3, 1, 2))) int x; // expected-warning {{'diagnose_as_builtin' attribute only applies to functions}}
+
+void *test_memcpy(const void *src, size_t c, void *dst) __attribute__((diagnose_as_builtin(__builtin_memcpy, 3, 1, 2))) {
+  return __builtin_memcpy(dst, src, c);
+}
+
+void call_test_memcpy() {
+  char bufferA[10];
+  char bufferB[11];
+  test_memcpy(bufferB, 10, bufferA);
+  test_memcpy(bufferB, 11, bufferA); // expected-warning {{'memcpy' will always overflow; destination buffer has size 10, but size argument is 11}}
+}
+
+void failure_function_doesnt_exist() __attribute__((diagnose_as_builtin(__function_that_doesnt_exist))) {} // expected-error {{use of undeclared identifier '__function_that_doesnt_exist'}}
+
+void not_a_builtin() {}
+
+void failure_not_a_builtin() __attribute__((diagnose_as_builtin(not_a_builtin))) {} // expected-error {{'diagnose_as_builtin' attribute requires parameter 1 to be a builtin function}}
+
+void failure_too_many_parameters(void *dst, const void *src, size_t count, size_t nothing) __attribute__((diagnose_as_builtin(__builtin_memcpy, 1, 2, 3, 4))) {} // expected-error {{'diagnose_as_builtin' attribute references function '__builtin_memcpy', which takes exactly 3 arguments}}
+
+void failure_too_few_parameters(void *dst, const void *src) __attribute__((diagnose_as_builtin(__builtin_memcpy, 1, 2))) {} // expected-error{{'diagnose_as_builtin' attribute references function '__builtin_memcpy', which takes exactly 3 arguments}}
+
+void failure_not_an_integer(void *dst, const void *src, size_t count) __attribute__((diagnose_as_builtin(__builtin_memcpy, "abc", 2, 3))) {} // expected-error{{'diagnose_as_builtin' attribute requires parameter 2 to be an integer constant}}
+
+void failure_not_a_builtin2() __attribute__((diagnose_as_builtin("abc"))) {} // expected-error{{'diagnose_as_builtin' attribute requires parameter 1 to be a builtin function}}
+
+void failure_parameter_index_bounds(void *dst, const void *src) __attribute__((diagnose_as_builtin(__builtin_memcpy, 1, 2, 3))) {} // expected-error{{'diagnose_as_builtin' attribute references parameter 3, but the function 'failure_parameter_index_bounds' has only 2 parameters}}
+
+void failure_parameter_types(double dst, const void *src, size_t count) __attribute__((diagnose_as_builtin(__builtin_memcpy, 1, 2, 3))) {} // expected-error{{'diagnose_as_builtin' attribute parameter types do not match: parameter 1 of function 'failure_parameter_types' has type 'double', but parameter 1 of function '__builtin_memcpy' has type 'void *'}}
+
+void to_redeclare(void *dst, const void *src, size_t count);
+
+void use_to_redeclare() {
+  char src[10];
+  char dst[9];
+  // We shouldn't get an error yet.
+  to_redeclare(dst, src, 10);
+}
+
+void to_redeclare(void *dst, const void *src, size_t count) __attribute((diagnose_as_builtin(__builtin_memcpy, 1, 2, 3)));
+
+void error_to_redeclare() {
+  char src[10];
+  char dst[9];
+  // Now we get an error.
+  to_redeclare(dst, src, 10); // expected-warning {{'memcpy' will always overflow; destination buffer has size 9, but size argument is 10}}
+}
+
+// Make sure this works even with extra qualifiers and the pass_object_size attribute.
+void *memcpy2(void *const dst __attribute__((pass_object_size(0))), const void *src, size_t copy_amount) __attribute((diagnose_as_builtin(__builtin_memcpy, 1, 2, 3)));
+
+void call_memcpy2() {
+  char buf1[10];
+  char buf2[11];
+  memcpy2(buf1, buf2, 11); // expected-warning {{'memcpy' will always overflow; destination buffer has size 10, but size argument is 11}}
+}
+
+// We require the types to be identical, modulo canonicalization and qualifiers.
+// Maybe this could be relaxed if it proves too restrictive.
+void failure_type(void *dest, char val, size_t n) __attribute__((diagno

[PATCH] D115661: [clang][amdgpu] - Choose when to promote VarDecl to address space 4.

[Ethan Stewart via Phabricator via cfe-commits]

estewart08 added a comment.

In D115661#3190477 , @yaxunl wrote:

> This may cause perf regressions for HIP.

Do you have a test that would show such a regression? Emitting a store to 
address space (4) in a constructor seems the wrong thing to do.




Comment at: clang/test/CodeGenCXX/cxx11-extern-constexpr.cpp:10
 // X86: @_ZN1A3FooE ={{.*}} constant i32 123, align 4
-// AMD: @_ZN1A3FooE ={{.*}} addrspace(4) constant i32 123, align 4
+// AMD: @_ZN1A3FooE ={{.*}} addrspace(1) constant i32 123, align 4
 const int *p = &A::Foo; // emit available_externally

yaxunl wrote:
> Do you know why this is not treated as constant initialization?
> 
There is no initialization here:
```
const int A::Foo;
```

It seems the compiler ignores the 123 in the struct.

I see address space (4) when the test is written like this:
```
struct A {
  static const int Foo;
};
const int A::Foo = 123;
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115661

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

[PATCH] D113245: [Sema] Mark explicit specialization declaration in a friend invalid

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

Thanks for the fix for this -- I think the changes look like they're correct, 
but the test coverage needs a bit of work.




Comment at: clang/lib/Sema/SemaDecl.cpp:9191
 << FixItHint::CreateInsertion(InsertLoc, "<>");
+  NewFD->setInvalidDecl();
 }

Alternatively, we could set `Invalid = true;` here and let the code on 9207 do 
its thing. We do both in this function, and I believe either approach is 
equivalent for this specific code path.



Comment at: clang/test/CXX/temp/temp.spec/temp.expl.spec/p20.cpp:16-28
+template
 struct PR41792 {
   // expected-error@+1{{cannot declare an explicit specialization in a friend}}
-  template <> friend void f<>(int);
+  template <> friend void f<>(int) {}
 
   // expected-error@+2{{template specialization declaration cannot be a 
friend}}
   // expected-error@+1{{too few template arguments for class template 'A'}}

I don't think you should coop the existing test for an unrelated bug; can you 
add a new test to either SemaCXX or SemaTemplate?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113245

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

[PATCH] D109981: [Diagnostics] Don't drop a statically set NoWarningAsError flag during option processing

[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.




Comment at: clang/test/Lexer/pragma-message.c:14
 #define STRING(x) STRING2(x)
-#pragma message(":O I'm a message! " STRING(__LINE__)) // expected-warning 
{{:O I'm a message! 13}}
-#pragma message ":O gcc accepts this! " STRING(__LINE__) // expected-warning 
{{:O gcc accepts this! 14}}
+#pragma message(":O I'm a message! " STRING(__LINE__)) // expected-warning 
{{:O I'm a message! 14}}
+#pragma message ":O gcc accepts this! " STRING(__LINE__) // expected-warning 
{{:O gcc accepts this! 15}}

Might be nice to delete a blank line above to avoid triggering all these line 
number changes. (That said, I don't really understand why they're listed at 
all, given that `-verify` handles line numbers... maybe we want to be sure the 
macros work in this context?)


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

https://reviews.llvm.org/D109981

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

[PATCH] D115346: [clang][deps] Squash caches for original and minimized files

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

dexonsmith added inline comments.



Comment at: 
clang/include/clang/Tooling/DependencyScanning/DependencyScanningFilesystem.h:106-108
+  std::unique_ptr OriginalContents;
+  std::unique_ptr MinimizedContents;
   PreprocessorSkippedRangeMapping PPSkippedRangeMapping;

jansvoboda11 wrote:
> dexonsmith wrote:
> > jansvoboda11 wrote:
> > > dexonsmith wrote:
> > > > I'm finding it a bit subtle detecting if there are races on access / 
> > > > setting of these, but I think it's correct.
> > > > - I think I verified that they are "set once".
> > > > - All the setters are guarded by locks.
> > > > - The first getter per "local" cache is guarded by a lock.
> > > > - Subsequent getters are not.
> > > > 
> > > > The key question: are the subsequent getters ONLY used when the first 
> > > > getter was successful?
> > > > 
> > > > One way to make it more obvious:
> > > > ```
> > > > lang=c++
> > > >   struct ContentWithPPRanges {
> > > > std::unique_ptr Content;
> > > > PreprocessorSkippedRangeMapping PPSkippedRangeMapping;
> > > >   };
> > > > 
> > > > private:
> > > >   // Always accessed,mutated under a lock. Not mutated after they 
> > > > escape.
> > > >   std::unique_ptr Original;
> > > >   std::unique_ptr Minimized;
> > > >   PreprocessorSkippedRangeMapping PPSkippedRangeMapping;
> > > > 
> > > >   // Used in getters. Pointed-at memory immutable after these are set.
> > > >   std::atomic OriginalAccess;
> > > >   std::atomic MinimizedAccess;
> > > >   std::atomic PPRangesAccess;
> > > > ```
> > > > I don't think this is the only approach though.
> > > > 
> > > I think there are no races on the original contents. The pointer is 
> > > unconditionally set on creation of `CachedFileSystemEntry` under a lock 
> > > that no threads get past without having set the pointer (or failing and 
> > > never accessing the pointer).
> > > 
> > > For minimized contents, the latest revision adds check at the beginning 
> > > of the main function (`needsMinimization`) outside the critical section. 
> > > There are three paths I can think of:
> > > * The check returns `true` in thread A (pointer is `null`), thread A 
> > > enters critical section, minimizes the contents and initializes the 
> > > pointer.
> > > * The check returns `true` in thread A, but thread B entered the critical 
> > > section, minimized contents and initialized the pointer. When thread A 
> > > enters the critical section, it performs the check again, figures that 
> > > out and skips minimization.
> > > * The check returns `false` and the local cache entry is returned.
> > > 
> > > So there definitely is a race here, but I believe it's benign. Do you 
> > > agree? Do you think it's worth addressing?
> > I don't trust myself to evaluate whether it's benign, but if there's no 
> > atomic mutation, then I think it's possible that when the setter changes a 
> > value from "x" to "y" then the racing reader can see a third value "z". You 
> > might gain some confidence by using `-fsanitize=thread` on a workload 
> > that's going to include this sort of thing -- probably hard to exercise: 
> > PCH already exists, try minimizing something that uses the PCH, and then 
> > try minimizing something that doesn't.
> > 
> > I'd rather just avoid the race entirely so we don't need to guess though.
> Interesting...
> 
> After reading up on this a bit, my understanding is that reads of 
> `MinimizedContents` cannot be torn, because it's pointers-sized and aligned. 
> So we should never see a third value "z". Am I wrong?
> 
> The potential data race is IMO somewhat independent from the read tearing 
> aspect and is avoided by defensively checking `MinimizedContents` again under 
> lock.
> 
> To confirm, I ran the following test case with and without thread sanitizer, 
> never seeing data races or incorrect results.
> 
> {F20978137}
> 
> I'm happy to use the `std::atomic` pattern you suggested, but I want to be 
> sure I understand why that's necessary.
Heh, I don't know what can and cannot tear (especially on different 
architectures/etc.), I'm just wary. I'll trust your homework, but please add a 
comment documenting why it's thread-safe to read without atomics/locks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115346

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

[PATCH] D115751: [clang] Use usual lit pattern for CLANG_DEFAULT_PIE_ON_LINUX and LLVM_WITH_Z3

[Nico Weber via Phabricator via cfe-commits]

thakis created this revision.
thakis added a reviewer: MaskRay.
Herald added subscribers: mikhail.ramalho, mgorny.
thakis requested review of this revision.

See D28294  for context.


https://reviews.llvm.org/D115751

Files:
  clang/test/CMakeLists.txt
  clang/test/lit.cfg.py
  clang/test/lit.site.cfg.py.in


Index: clang/test/lit.site.cfg.py.in
===
--- clang/test/lit.site.cfg.py.in
+++ clang/test/lit.site.cfg.py.in
@@ -22,10 +22,10 @@
 config.llvm_use_sanitizer = "@LLVM_USE_SANITIZER@"
 config.have_zlib = @LLVM_ENABLE_ZLIB@
 config.clang_arcmt = @CLANG_ENABLE_ARCMT@
-config.clang_default_pie_on_linux = "@CLANG_DEFAULT_PIE_ON_LINUX@"
+config.clang_default_pie_on_linux = @CLANG_DEFAULT_PIE_ON_LINUX@
 config.clang_default_cxx_stdlib = "@CLANG_DEFAULT_CXX_STDLIB@"
 config.clang_staticanalyzer = @CLANG_ENABLE_STATIC_ANALYZER@
-config.clang_staticanalyzer_z3 = "@LLVM_WITH_Z3@"
+config.clang_staticanalyzer_z3 = @LLVM_WITH_Z3@
 config.clang_examples = @CLANG_BUILD_EXAMPLES@
 config.enable_shared = @ENABLE_SHARED@
 config.enable_backtrace = @ENABLE_BACKTRACES@
Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -98,7 +98,7 @@
 config.available_features.add('staticanalyzer')
 tools.append('clang-check')
 
-if config.clang_staticanalyzer_z3 == '1':
+if config.clang_staticanalyzer_z3:
 config.available_features.add('z3')
 
 check_analyzer_fixit_path = os.path.join(
@@ -121,7 +121,7 @@
 if config.has_plugins and config.llvm_plugin_ext:
 config.available_features.add('plugins')
 
-if config.clang_default_pie_on_linux == '1':
+if config.clang_default_pie_on_linux:
 config.available_features.add('default-pie-on-linux')
 
 # Set available features we allow tests to conditionalize on.
Index: clang/test/CMakeLists.txt
===
--- clang/test/CMakeLists.txt
+++ clang/test/CMakeLists.txt
@@ -11,6 +11,7 @@
 
 llvm_canonicalize_cmake_booleans(
   CLANG_BUILD_EXAMPLES
+  CLANG_DEFAULT_PIE_ON_LINUX
   CLANG_ENABLE_ARCMT
   CLANG_ENABLE_STATIC_ANALYZER
   CLANG_SPAWN_CC1
@@ -19,7 +20,9 @@
   LLVM_ENABLE_ZLIB
   LLVM_ENABLE_PER_TARGET_RUNTIME_DIR
   LLVM_ENABLE_PLUGINS
-  LLVM_ENABLE_THREADS)
+  LLVM_ENABLE_THREADS
+  LLVM_WITH_Z3
+  )
 
 configure_lit_site_cfg(
   ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.py.in


Index: clang/test/lit.site.cfg.py.in
===
--- clang/test/lit.site.cfg.py.in
+++ clang/test/lit.site.cfg.py.in
@@ -22,10 +22,10 @@
 config.llvm_use_sanitizer = "@LLVM_USE_SANITIZER@"
 config.have_zlib = @LLVM_ENABLE_ZLIB@
 config.clang_arcmt = @CLANG_ENABLE_ARCMT@
-config.clang_default_pie_on_linux = "@CLANG_DEFAULT_PIE_ON_LINUX@"
+config.clang_default_pie_on_linux = @CLANG_DEFAULT_PIE_ON_LINUX@
 config.clang_default_cxx_stdlib = "@CLANG_DEFAULT_CXX_STDLIB@"
 config.clang_staticanalyzer = @CLANG_ENABLE_STATIC_ANALYZER@
-config.clang_staticanalyzer_z3 = "@LLVM_WITH_Z3@"
+config.clang_staticanalyzer_z3 = @LLVM_WITH_Z3@
 config.clang_examples = @CLANG_BUILD_EXAMPLES@
 config.enable_shared = @ENABLE_SHARED@
 config.enable_backtrace = @ENABLE_BACKTRACES@
Index: clang/test/lit.cfg.py
===
--- clang/test/lit.cfg.py
+++ clang/test/lit.cfg.py
@@ -98,7 +98,7 @@
 config.available_features.add('staticanalyzer')
 tools.append('clang-check')
 
-if config.clang_staticanalyzer_z3 == '1':
+if config.clang_staticanalyzer_z3:
 config.available_features.add('z3')
 
 check_analyzer_fixit_path = os.path.join(
@@ -121,7 +121,7 @@
 if config.has_plugins and config.llvm_plugin_ext:
 config.available_features.add('plugins')
 
-if config.clang_default_pie_on_linux == '1':
+if config.clang_default_pie_on_linux:
 config.available_features.add('default-pie-on-linux')
 
 # Set available features we allow tests to conditionalize on.
Index: clang/test/CMakeLists.txt
===
--- clang/test/CMakeLists.txt
+++ clang/test/CMakeLists.txt
@@ -11,6 +11,7 @@
 
 llvm_canonicalize_cmake_booleans(
   CLANG_BUILD_EXAMPLES
+  CLANG_DEFAULT_PIE_ON_LINUX
   CLANG_ENABLE_ARCMT
   CLANG_ENABLE_STATIC_ANALYZER
   CLANG_SPAWN_CC1
@@ -19,7 +20,9 @@
   LLVM_ENABLE_ZLIB
   LLVM_ENABLE_PER_TARGET_RUNTIME_DIR
   LLVM_ENABLE_PLUGINS
-  LLVM_ENABLE_THREADS)
+  LLVM_ENABLE_THREADS
+  LLVM_WITH_Z3
+  )
 
 configure_lit_site_cfg(
   ${CMAKE_CURRENT_SOURCE_DIR}/lit.site.cfg.py.in
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D115738: [clang-format] Code following C# Lambda Expressions has wrong formatting

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay accepted this revision.
MyDeveloperDay added a comment.

LGTM


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

https://reviews.llvm.org/D115738

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

[PATCH] D115738: [clang-format] Code following C# Lambda Expressions has wrong formatting

[MyDeveloperDay via Phabricator via cfe-commits]

MyDeveloperDay added a comment.

I tested this on the original code that made me make the original change, and I 
like your fix much better ;-)

Thank you for this patch, interested on working on other C# clang-format issues?


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

https://reviews.llvm.org/D115738

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

[clang] 09a704c - [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO.

[via cfe-commits]

Author: Mingming Liu
Date: 2021-12-14T20:18:04Z
New Revision: 09a704c5efba2c07af5b457bf3afc5eb746f22c2

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

LOG: [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO.

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

Added: 

llvm/test/ThinLTO/X86/Inputs/devirt_hybrid_after_filtering_unreachable_lib.ll
llvm/test/ThinLTO/X86/devirt_hybrid_after_filtering_unreachable.ll

Modified: 
clang/test/CodeGen/thinlto-distributed-cfi-devirt.ll
clang/test/CodeGen/thinlto-distributed-cfi.ll
clang/test/CodeGen/thinlto-funcattr-prop.ll
llvm/include/llvm/AsmParser/LLToken.h
llvm/include/llvm/IR/ModuleSummaryIndex.h
llvm/lib/Analysis/ModuleSummaryAnalysis.cpp
llvm/lib/AsmParser/LLLexer.cpp
llvm/lib/AsmParser/LLParser.cpp
llvm/lib/Bitcode/Reader/BitcodeReader.cpp
llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
llvm/lib/IR/ModuleSummaryIndex.cpp
llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp
llvm/test/Assembler/thinlto-summary.ll
llvm/test/Bitcode/thinlto-function-summary-refgraph.ll
llvm/test/Bitcode/thinlto-type-vcalls.ll
llvm/test/ThinLTO/X86/dot-dumper.ll
llvm/test/ThinLTO/X86/dot-dumper2.ll
llvm/test/ThinLTO/X86/funcattrs-prop-maythrow.ll
llvm/test/ThinLTO/X86/funcimport_alwaysinline.ll

Removed: 




diff  --git a/clang/test/CodeGen/thinlto-distributed-cfi-devirt.ll 
b/clang/test/CodeGen/thinlto-distributed-cfi-devirt.ll
index 151f3fba304ed..e02b30b392e17 100644
--- a/clang/test/CodeGen/thinlto-distributed-cfi-devirt.ll
+++ b/clang/test/CodeGen/thinlto-distributed-cfi-devirt.ll
@@ -36,7 +36,7 @@
 ; Round trip it through llvm-as
 ; RUN: llvm-dis %t.o.thinlto.bc -o - | llvm-as -o - | llvm-dis -o - | 
FileCheck %s --check-prefix=CHECK-DIS
 ; CHECK-DIS: ^0 = module: (path: 
"{{.*}}thinlto-distributed-cfi-devirt.ll.tmp.o", hash: ({{.*}}, {{.*}}, {{.*}}, 
{{.*}}, {{.*}}))
-; CHECK-DIS: ^1 = gv: (guid: 8346051122425466633, summaries: (function: 
(module: ^0, flags: (linkage: external, visibility: default, 
notEligibleToImport: 0, live: 1, dsoLocal: 0, canAutoHide: 0), insts: 18, 
funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, 
noInline: 0, alwaysInline: 0, noUnwind: 0, mayThrow: 0, hasUnknownCall: 1), 
typeIdInfo: (typeTests: (^2), typeCheckedLoadVCalls: (vFuncId: (^2, offset: 8), 
vFuncId: (^2, offset: 0))
+; CHECK-DIS: ^1 = gv: (guid: 8346051122425466633, summaries: (function: 
(module: ^0, flags: (linkage: external, visibility: default, 
notEligibleToImport: 0, live: 1, dsoLocal: 0, canAutoHide: 0), insts: 18, 
funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, 
noInline: 0, alwaysInline: 0, noUnwind: 0, mayThrow: 0, hasUnknownCall: 1, 
mustBeUnreachable: 0), typeIdInfo: (typeTests: (^2), typeCheckedLoadVCalls: 
(vFuncId: (^2, offset: 8), vFuncId: (^2, offset: 0))
 ; CHECK-DIS: ^2 = typeid: (name: "_ZTS1A", summary: (typeTestRes: (kind: 
allOnes, sizeM1BitWidth: 7), wpdResolutions: ((offset: 0, wpdRes: (kind: 
branchFunnel)), (offset: 8, wpdRes: (kind: singleImpl, singleImplName: 
"_ZN1A1nEi") ; guid = 7004155349499253778
 
 ; RUN: %clang_cc1 -triple x86_64-grtev4-linux-gnu \

diff  --git a/clang/test/CodeGen/thinlto-distributed-cfi.ll 
b/clang/test/CodeGen/thinlto-distributed-cfi.ll
index 26b5ac762204c..f5dde2d32a42d 100644
--- a/clang/test/CodeGen/thinlto-distributed-cfi.ll
+++ b/clang/test/CodeGen/thinlto-distributed-cfi.ll
@@ -24,7 +24,7 @@
 ; Round trip it through llvm-as
 ; RUN: llvm-dis %t.o.thinlto.bc -o - | llvm-as -o - | llvm-dis -o - | 
FileCheck %s --check-prefix=CHECK-DIS
 ; CHECK-DIS: ^0 = module: (path: "{{.*}}thinlto-distributed-cfi.ll.tmp.o", 
hash: ({{.*}}, {{.*}}, {{.*}}, {{.*}}, {{.*}}))
-; CHECK-DIS: ^1 = gv: (guid: 8346051122425466633, summaries: (function: 
(module: ^0, flags: (linkage: external, visibility: default, 
notEligibleToImport: 0, live: 1, dsoLocal: 0, canAutoHide: 0), insts: 7, 
funcFlags: (readNone: 0, readOnly: 0, noRecurse: 1, returnDoesNotAlias: 0, 
noInline: 0, alwaysInline: 0, noUnwind: 1, mayThrow: 0, hasUnknownCall: 0), 
typeIdInfo: (typeTests: (^2)
+; CHECK-DIS: ^1 = gv: (guid: 8346051122425466633, summaries: (function: 
(module: ^0, flags: (linkage: external, visibility: default, 
notEligibleToImport: 0, live: 1, dsoLocal: 0, canAutoHide: 0), insts: 7, 
funcFlags: (readNone: 0, readOnly: 0, noRecurse: 1, returnDoesNotAlias: 0, 
noInline: 0, alwaysInline: 0, noUnwind: 1, mayThrow: 0, hasUnknownCall: 0, 
mustBeUnreachable: 0), typeIdInfo: (typeTests: (^2)
 ; CHECK-DIS: ^2 = typeid: (name: "_ZTS1A", summary: (typeTestRes: (kind: 
single, sizeM1BitWidth: 0))) ; guid = 7004155349499253778
 
 ; RUN: %clang_cc1 -triple x86_64-grtev4-linux-gnu \

diff  --gi

[PATCH] D115492: [LTO] Ignore unreachable virtual functions in WPD in hybrid LTO

[Mingming Liu 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 rG09a704c5efba: [LTO] Ignore unreachable virtual functions in 
WPD in hybrid LTO. (authored by luna).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115492

Files:
  clang/test/CodeGen/thinlto-distributed-cfi-devirt.ll
  clang/test/CodeGen/thinlto-distributed-cfi.ll
  clang/test/CodeGen/thinlto-funcattr-prop.ll
  llvm/include/llvm/AsmParser/LLToken.h
  llvm/include/llvm/IR/ModuleSummaryIndex.h
  llvm/lib/Analysis/ModuleSummaryAnalysis.cpp
  llvm/lib/AsmParser/LLLexer.cpp
  llvm/lib/AsmParser/LLParser.cpp
  llvm/lib/Bitcode/Reader/BitcodeReader.cpp
  llvm/lib/Bitcode/Writer/BitcodeWriter.cpp
  llvm/lib/IR/ModuleSummaryIndex.cpp
  llvm/lib/Transforms/IPO/WholeProgramDevirt.cpp
  llvm/test/Assembler/thinlto-summary.ll
  llvm/test/Bitcode/thinlto-function-summary-refgraph.ll
  llvm/test/Bitcode/thinlto-type-vcalls.ll
  llvm/test/ThinLTO/X86/Inputs/devirt_hybrid_after_filtering_unreachable_lib.ll
  llvm/test/ThinLTO/X86/devirt_hybrid_after_filtering_unreachable.ll
  llvm/test/ThinLTO/X86/dot-dumper.ll
  llvm/test/ThinLTO/X86/dot-dumper2.ll
  llvm/test/ThinLTO/X86/funcattrs-prop-maythrow.ll
  llvm/test/ThinLTO/X86/funcimport_alwaysinline.ll

Index: llvm/test/ThinLTO/X86/funcimport_alwaysinline.ll
===
--- llvm/test/ThinLTO/X86/funcimport_alwaysinline.ll
+++ llvm/test/ThinLTO/X86/funcimport_alwaysinline.ll
@@ -23,4 +23,4 @@
 }
 
 attributes #0 = { alwaysinline nounwind uwtable }
-; CHECK2: ^2 = gv: (guid: {{.*}}, summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 1, dsoLocal: 1, canAutoHide: 0), insts: 1, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 1, noUnwind: 1, mayThrow: 0, hasUnknownCall: 0
+; CHECK2: ^2 = gv: (guid: {{.*}}, summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 1, dsoLocal: 1, canAutoHide: 0), insts: 1, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 1, noUnwind: 1, mayThrow: 0, hasUnknownCall: 0, mustBeUnreachable: 0
Index: llvm/test/ThinLTO/X86/funcattrs-prop-maythrow.ll
===
--- llvm/test/ThinLTO/X86/funcattrs-prop-maythrow.ll
+++ llvm/test/ThinLTO/X86/funcattrs-prop-maythrow.ll
@@ -48,9 +48,9 @@
 ; CHECK-DAG: attributes [[ATTR_NOUNWIND]] = { norecurse nounwind }
 ; CHECK-DAG: attributes [[ATTR_MAYTHROW]] = { norecurse }
 
-; SUMMARY-DAG: = gv: (name: "cleanupret", summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), insts: 4, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 0, noUnwind: 0, mayThrow: 1, hasUnknownCall: 0), calls: ((callee: ^{{.*}})), refs: (^{{.*}}
-; SUMMARY-DAG: = gv: (name: "resume", summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), insts: 4, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 0, noUnwind: 0, mayThrow: 1, hasUnknownCall: 0), calls: ((callee: ^{{.*}})), refs: (^{{.*}}
-; SUMMARY-DAG: = gv: (name: "catchret", summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), insts: 5, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 0, noUnwind: 0, mayThrow: 1, hasUnknownCall: 0), calls: ((callee: ^{{.*}})), refs: (^{{.*}}
+; SUMMARY-DAG: = gv: (name: "cleanupret", summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), insts: 4, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 0, noUnwind: 0, mayThrow: 1, hasUnknownCall: 0, mustBeUnreachable: 0), calls: ((callee: ^{{.*}})), refs: (^{{.*}}
+; SUMMARY-DAG: = gv: (name: "resume", summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), insts: 4, funcFlags: (readNone: 0, readOnly: 0, noRecurse: 0, returnDoesNotAlias: 0, noInline: 0, alwaysInline: 0, noUnwind: 0, mayThrow: 1, hasUnknownCall: 0, mustBeUnreachable: 0), calls: ((callee: ^{{.*}})), refs: (^{{.*}}
+; SUMMARY-DAG: = gv: (name: "catchret", summaries: (function: (module: ^0, flags: (linkage: external, visibility: default, notEligibleToImport: 0, live: 0, dsoLocal: 0, canAutoHide: 0), insts: 5, funcF

[PATCH] D113245: [Sema] Mark explicit specialization declaration in a friend invalid

[Yuanfang Chen via Phabricator via cfe-commits]

ychen updated this revision to Diff 394351.
ychen added a comment.

- Address Aaron's comments.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113245

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/CXX/temp/temp.spec/temp.expl.spec/p20-2.cpp


Index: clang/test/CXX/temp/temp.spec/temp.expl.spec/p20-2.cpp
===
--- /dev/null
+++ clang/test/CXX/temp/temp.spec/temp.expl.spec/p20-2.cpp
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+template
+void f(T);
+
+template
+struct A {
+  // expected-error@+1{{cannot declare an explicit specialization in a friend}}
+  template <> friend void f<>(int) {}
+};
+
+// Makes sure implicit instantiation here does not trigger
+// the assertion "Member specialization must be an explicit specialization"
+void foo(void) {
+A a;
+}
\ No newline at end of file
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -9195,6 +9195,7 @@
 << Name << RemoveRange
 << FixItHint::CreateRemoval(RemoveRange)
 << FixItHint::CreateInsertion(InsertLoc, "<>");
+  Invalid = true;
 }
   }
 } else {


Index: clang/test/CXX/temp/temp.spec/temp.expl.spec/p20-2.cpp
===
--- /dev/null
+++ clang/test/CXX/temp/temp.spec/temp.expl.spec/p20-2.cpp
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+template
+void f(T);
+
+template
+struct A {
+  // expected-error@+1{{cannot declare an explicit specialization in a friend}}
+  template <> friend void f<>(int) {}
+};
+
+// Makes sure implicit instantiation here does not trigger
+// the assertion "Member specialization must be an explicit specialization"
+void foo(void) {
+A a;
+}
\ No newline at end of file
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -9195,6 +9195,7 @@
 << Name << RemoveRange
 << FixItHint::CreateRemoval(RemoveRange)
 << FixItHint::CreateInsertion(InsertLoc, "<>");
+  Invalid = true;
 }
   }
 } else {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113245: [Sema] Mark explicit specialization declaration in a friend invalid

[Yuanfang Chen via Phabricator via cfe-commits]

ychen updated this revision to Diff 394352.
ychen added a comment.

- format


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113245

Files:
  clang/lib/Sema/SemaDecl.cpp
  clang/test/CXX/temp/temp.spec/temp.expl.spec/p20-2.cpp


Index: clang/test/CXX/temp/temp.spec/temp.expl.spec/p20-2.cpp
===
--- /dev/null
+++ clang/test/CXX/temp/temp.spec/temp.expl.spec/p20-2.cpp
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+template
+void f(T);
+
+template
+struct A {
+  // expected-error@+1{{cannot declare an explicit specialization in a friend}}
+  template <> friend void f<>(int) {}
+};
+
+// Makes sure implicit instantiation here does not trigger
+// the assertion "Member specialization must be an explicit specialization"
+void foo(void) {
+A a;
+}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -9195,6 +9195,7 @@
 << Name << RemoveRange
 << FixItHint::CreateRemoval(RemoveRange)
 << FixItHint::CreateInsertion(InsertLoc, "<>");
+  Invalid = true;
 }
   }
 } else {


Index: clang/test/CXX/temp/temp.spec/temp.expl.spec/p20-2.cpp
===
--- /dev/null
+++ clang/test/CXX/temp/temp.spec/temp.expl.spec/p20-2.cpp
@@ -0,0 +1,15 @@
+// RUN: %clang_cc1 -fsyntax-only -verify %s
+template
+void f(T);
+
+template
+struct A {
+  // expected-error@+1{{cannot declare an explicit specialization in a friend}}
+  template <> friend void f<>(int) {}
+};
+
+// Makes sure implicit instantiation here does not trigger
+// the assertion "Member specialization must be an explicit specialization"
+void foo(void) {
+A a;
+}
Index: clang/lib/Sema/SemaDecl.cpp
===
--- clang/lib/Sema/SemaDecl.cpp
+++ clang/lib/Sema/SemaDecl.cpp
@@ -9195,6 +9195,7 @@
 << Name << RemoveRange
 << FixItHint::CreateRemoval(RemoveRange)
 << FixItHint::CreateInsertion(InsertLoc, "<>");
+  Invalid = true;
 }
   }
 } else {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D113917: Add infrastructure to support matcher names.

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang/ASTMatchers/ASTMatchersInternal.h:88
+/// can be useful for cases like debugging matchers.
+template  std::string makeMatcherNameFromType() {
+  return "Matcher";

ymandel wrote:
> Please note in the comments that this function template is specialized below 
> to cover most (all) of the AST. So, the default string here should only very 
> rarely (never?) be used.
Should we be asserting that we never use it so that we can have 100% coverage 
up front and rely on the assertion to catch later issues?



Comment at: clang/include/clang/ASTMatchers/ASTMatchersInternal.h:90
+/// here should rarely be used.
+template  std::string makeMatcherNameFromType() {
+  return "Matcher";

Does the return type need to be `std::string` instead of `StringRef`? It looks 
like everything is returning a string literal.



Comment at: clang/include/clang/ASTMatchers/ASTMatchersInternal.h:578
+  /// If the name is already set, then \c MatcherName overrides it.
+  DynTypedMatcher withMatcherName(std::string MatcherName) const;
+

Is there a need for this to accept a `std::string` as opposed to `StringRef`?



Comment at: clang/lib/ASTMatchers/ASTMatchersInternal.cpp:131
 private:
+  const std::string MatcherName;
   std::vector InnerMatchers;

FWIW, this is the only place I was expecting to see a std::string (places where 
it's needed for long-term storage).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D113917

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

[PATCH] D115751: [clang] Use usual lit pattern for CLANG_DEFAULT_PIE_ON_LINUX and LLVM_WITH_Z3

[Fangrui Song via Phabricator via cfe-commits]

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

Looks great!


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

https://reviews.llvm.org/D115751

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

[PATCH] D115661: [clang][amdgpu] - Choose when to promote VarDecl to address space 4.

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D115661#3192983 , @estewart08 
wrote:

> In D115661#3190477 , @yaxunl wrote:
>
>> This may cause perf regressions for HIP.
>
> Do you have a test that would show such a regression? Emitting a store to 
> address space (4) in a constructor seems the wrong thing to do.

The two lit tests which changed from addr space 4 to 1 demonstrated that. In 
alias analysis, if a variable is in addr space 4, the backend knows that it is 
constant and can do optimizations on it. After changing to addr space 1, those 
optimizations are gone.

I am not objecting to putting variables like `const float x=log2(y)` to addr 
space 1. However, the lit tests indicate the condition check is too restrictive.




Comment at: clang/test/CodeGenCXX/cxx11-extern-constexpr.cpp:10
 // X86: @_ZN1A3FooE ={{.*}} constant i32 123, align 4
-// AMD: @_ZN1A3FooE ={{.*}} addrspace(4) constant i32 123, align 4
+// AMD: @_ZN1A3FooE ={{.*}} addrspace(1) constant i32 123, align 4
 const int *p = &A::Foo; // emit available_externally

estewart08 wrote:
> yaxunl wrote:
> > Do you know why this is not treated as constant initialization?
> > 
> There is no initialization here:
> ```
> const int A::Foo;
> ```
> 
> It seems the compiler ignores the 123 in the struct.
> 
> I see address space (4) when the test is written like this:
> ```
> struct A {
>   static const int Foo;
> };
> const int A::Foo = 123;
> ```
In this case, there are two Decl's for `A::Foo` and the initializer of `A::Foo` 
is on the first initializer whereas `hasConstantInitialization` only checks the 
final Decl, which does not have an initializer. Therefore 
hasConstantInitialization may conservatively return false for a variable with a 
constant initializer in a previous decl.

clang codegen calls VarDecl::getAnyInitializer to checks all Decls of a 
variable when emitting its initializer in LLVM IR

https://github.com/llvm/llvm-project/blob/5336befe8c3cde08cec020583700b4d2ba25ac16/clang/lib/AST/Decl.cpp#L2277

I would suggest calling getAnyInitializer to get the initializer, then check 
whether it is constant expr to determine whether the variable will have a 
constant initializer in IR. I think hasConstantInitialization does not do that 
because it has multiple usages, not just for clang codegen, therefore it does 
not check all decls.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115661

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

[PATCH] D115661: [clang][amdgpu] - Choose when to promote VarDecl to address space 4.

[Matt Arsenault via Phabricator via cfe-commits]

arsenm added a comment.

In D115661#3193152 , @yaxunl wrote:

> In D115661#3192983 , @estewart08 
> wrote:
>
>> In D115661#3190477 , @yaxunl wrote:
>>
>>> This may cause perf regressions for HIP.
>>
>> Do you have a test that would show such a regression? Emitting a store to 
>> address space (4) in a constructor seems the wrong thing to do.
>
> The two lit tests which changed from addr space 4 to 1 demonstrated that. In 
> alias analysis, if a variable is in addr space 4, the backend knows that it 
> is constant and can do optimizations on it. After changing to addr space 1, 
> those optimizations are gone.

The backend also knows because the constant flag is set on the global variable. 
Addrspace(4) is a kludge which is largely redundant with other mechanisms for 
indicating constants


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115661

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

[PATCH] D112410: [SPIR-V] Add a toolchain for SPIR-V in clang

[Anastasia Stulova via Phabricator via cfe-commits]

Anastasia updated this revision to Diff 394353.
Anastasia added a comment.

Addressed review comments from Sven:

- Improved docs and code comments;
- Simplified tests;
- Added warning in a group.
- Aligned with translator PRs after merge.

Note, that this change now references documentation from PR 
https://github.com/KhronosGroup/SPIRV-LLVM-Translator/pull/1342


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

https://reviews.llvm.org/D112410

Files:
  clang/docs/UsersManual.rst
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Tool.h
  clang/include/clang/Driver/ToolChain.h
  clang/lib/Driver/Driver.cpp
  clang/lib/Driver/ToolChain.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Driver/ToolChains/Clang.h
  clang/lib/Driver/ToolChains/SPIRV.cpp
  clang/lib/Driver/ToolChains/SPIRV.h
  clang/test/Driver/spirv-toolchain.cl

Index: clang/test/Driver/spirv-toolchain.cl
===
--- /dev/null
+++ clang/test/Driver/spirv-toolchain.cl
@@ -0,0 +1,65 @@
+// Check object emission.
+// RUN: %clang -### -no-canonical-prefixes -target spirv64 -x cl -c %s 2>&1 | FileCheck --check-prefix=SPV64 %s
+// RUN: %clang -### -target spirv64 %s 2>&1 | FileCheck --check-prefix=SPV64 %s
+// RUN: %clang -### -no-canonical-prefixes -target spirv64 -x ir -c %s 2>&1 | FileCheck --check-prefix=SPV64 %s
+// RUN: %clang -### -no-canonical-prefixes -target spirv64 -x clcpp -c %s 2>&1 | FileCheck --check-prefix=SPV64 %s
+// RUN: %clang -### -no-canonical-prefixes -target spirv64 -x c -c %s 2>&1 | FileCheck --check-prefix=SPV64 %s
+
+// SPV64: clang{{.*}} "-cc1" "-triple" "spirv64"
+// SPV64-SAME: "-o" [[BC:".*bc"]]
+// SPV64: {{llvm-spirv.*"}} [[BC]] "-o" {{".*o"}}
+
+// RUN: %clang -### -no-canonical-prefixes -target spirv32 -x cl -c %s 2>&1 | FileCheck --check-prefix=SPV32 %s
+// RUN: %clang -### -target spirv32 %s 2>&1 | FileCheck --check-prefix=SPV32 %s
+// RUN: %clang -### -no-canonical-prefixes -target spirv32 -x ir -c %s 2>&1 | FileCheck --check-prefix=SPV32 %s
+// RUN: %clang -### -no-canonical-prefixes -target spirv32 -x clcpp -c %s 2>&1 | FileCheck --check-prefix=SPV32 %s
+// RUN: %clang -### -no-canonical-prefixes -target spirv32 -x c -c %s 2>&1 | FileCheck --check-prefix=SPV32 %s
+
+// SPV32: clang{{.*}} "-cc1" "-triple" "spirv32"
+// SPV32-SAME: "-o" [[BC:".*bc"]]
+// SPV32: {{llvm-spirv.*"}} [[BC]] "-o" {{".*o"}}
+
+//-
+// Check Assembly emission.
+// RUN: %clang -### -no-canonical-prefixes -target spirv64 -x cl -S %s 2>&1 | FileCheck --check-prefix=SPT64 %s
+// RUN: %clang -### -no-canonical-prefixes -target spirv64 -x ir -S %s 2>&1 | FileCheck --check-prefix=SPT64 %s
+// RUN: %clang -### -no-canonical-prefixes -target spirv64 -x clcpp -c %s 2>&1 | FileCheck --check-prefix=SPV64 %s
+// RUN: %clang -### -no-canonical-prefixes -target spirv64 -x c -S %s 2>&1 | FileCheck --check-prefix=SPT64 %s
+
+// SPT64: clang{{.*}} "-cc1" "-triple" "spirv64"
+// SPT64-SAME: "-o" [[BC:".*bc"]]
+// SPT64: {{llvm-spirv.*"}} [[BC]] "--spirv-tools-dis" "-o" {{".*s"}}
+
+// RUN: %clang -### -no-canonical-prefixes -target spirv32 -x cl -S %s 2>&1 | FileCheck --check-prefix=SPT32 %s
+// RUN: %clang -### -no-canonical-prefixes -target spirv32 -x ir -S %s 2>&1 | FileCheck --check-prefix=SPT32 %s
+// RUN: %clang -### -no-canonical-prefixes -target spirv32 -x clcpp -c %s 2>&1 | FileCheck --check-prefix=SPV32 %s
+// RUN: %clang -### -no-canonical-prefixes -target spirv32 -x c -S %s 2>&1 | FileCheck --check-prefix=SPT32 %s
+
+// SPT32: clang{{.*}} "-cc1" "-triple" "spirv32"
+// SPT32-SAME: "-o" [[BC:".*bc"]]
+// SPT32: {{llvm-spirv.*"}} [[BC]] "--spirv-tools-dis" "-o" {{".*s"}}
+
+//-
+// Check assembly input -> object output
+// RUN: %clang -### -no-canonical-prefixes -target spirv64 -x assembler -c %s 2>&1 | FileCheck --check-prefix=ASM %s
+// RUN: %clang -### -no-canonical-prefixes -target spirv32 -x assembler -c %s 2>&1 | FileCheck --check-prefix=ASM %s
+// ASM: {{llvm-spirv.*"}} {{".*"}} "-to-binary" "-o" {{".*o"}}
+
+//-
+// Check --save-temps.
+// RUN: %clang -### -no-canonical-prefixes -target spirv64 -x cl -c %s --save-temps 2>&1 | FileCheck --check-prefix=TMP %s
+
+// TMP: clang{{.*}} "-cc1" "-triple" "spirv64"
+// TMP-SAME: "-E"
+// TMP-SAME: "-o" [[I:".*i"]]
+// TMP: clang{{.*}} "-cc1" "-triple" "spirv64"
+// TMP-SAME: "-o" [[BC:".*bc"]]
+// TMP-SAME: [[I]]
+// TMP: {{llvm-spirv.*"}} [[BC]] "--spirv-tools-dis" "-o" [[S:".*s"]]
+// TMP: {{llvm-spirv.*"}} [[S]] "-to-binary" "-o" {{".*o"}}
+
+//-
+// Check that warning occurs if multiple input files are passed.
+// RUN: %clang -### -target spirv64 %s %s 2>&1 | FileCheck --check-pr

[PATCH] D115661: [clang][amdgpu] - Choose when to promote VarDecl to address space 4.

[Jon Chesterfield via Phabricator via cfe-commits]

JonChesterfield added a comment.

Changing the has-constant-initialiser check to a more precise/robust one sounds 
reasonable to me.

In D115661#3193157 , @arsenm wrote:

> The backend also knows because the constant flag is set on the global 
> variable. Addrspace(4) is a kludge which is largely redundant with other 
> mechanisms for indicating constants

There's an interesting edge case here - we might want variables that are 
assigned to from a global ctor and subsequently constant, in which case they 
are not 'constant' as far as IR is concerned, but they are amenable to scalar 
loads and will be invariant once loaded. Some tables of data that are computed 
once in a .ctor kernel launch and then read by other kernels. I'm not totally 
sure how to express that pattern in IR though.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115661

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

[PATCH] D115738: [clang-format] Code following C# Lambda Expressions has wrong formatting

[Owen Pan via Phabricator via cfe-commits]

owenpan added inline comments.



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:2007
+if (FormatTok->is(tok::l_brace)) {
+  if (Style.isCSharp() && Style.BraceWrapping.AfterFunction == true) {
+FormatTok->MustBreakBefore = true;

You already tested for C# on line 2004.



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:2009
+FormatTok->MustBreakBefore = true;
+  }
+  parseChildBlock();

Remove braces.



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:2012
+}
+  } else
 nextToken();

Add braces after `else` to match `if`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D115738

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