[PATCH] D145238: [NVPTX] Expose LDU builtins

[Jakub Chlanda via Phabricator via cfe-commits]

jchlanda updated this revision to Diff 503644.
jchlanda added a comment.

`append` -> `+`


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145238

Files:
  clang/include/clang/Basic/BuiltinsNVPTX.def
  clang/lib/CodeGen/CGBuiltin.cpp
  clang/test/CodeGen/builtins-nvptx-native-half-type-err.c
  clang/test/CodeGen/builtins-nvptx-native-half-type.c
  clang/test/CodeGen/builtins-nvptx.c
  llvm/test/CodeGen/NVPTX/ldu-ldg.ll

Index: llvm/test/CodeGen/NVPTX/ldu-ldg.ll
===
--- llvm/test/CodeGen/NVPTX/ldu-ldg.ll
+++ llvm/test/CodeGen/NVPTX/ldu-ldg.ll
@@ -3,7 +3,13 @@
 
 
 declare i8 @llvm.nvvm.ldu.global.i.i8.p1(ptr addrspace(1) %ptr, i32 %align)
+declare i16 @llvm.nvvm.ldu.global.i.i16.p1(ptr addrspace(1) %ptr, i32 %align)
 declare i32 @llvm.nvvm.ldu.global.i.i32.p1(ptr addrspace(1) %ptr, i32 %align)
+declare i64 @llvm.nvvm.ldu.global.i.i64.p1(ptr addrspace(1) %ptr, i32 %align)
+declare float @llvm.nvvm.ldu.global.f.f32.p1(ptr addrspace(1) %ptr, i32 %align)
+declare double @llvm.nvvm.ldu.global.f.f64.p1(ptr addrspace(1) %ptr, i32 %align)
+declare half @llvm.nvvm.ldu.global.f.f16.p1(ptr addrspace(1) %ptr, i32 %align)
+declare <2 x half> @llvm.nvvm.ldu.global.f.v2f16.p1(ptr addrspace(1) %ptr, i32 %align)
 
 declare i8 @llvm.nvvm.ldg.global.i.i8.p1(ptr addrspace(1) %ptr, i32 %align)
 declare i16 @llvm.nvvm.ldg.global.i.i16.p1(ptr addrspace(1) %ptr, i32 %align)
@@ -16,70 +22,112 @@
 
 ; CHECK: test_ldu_i8
 define i8 @test_ldu_i8(ptr addrspace(1) %ptr) {
-; ldu.global.u8
+  ; CHECK: ldu.global.u8
   %val = tail call i8 @llvm.nvvm.ldu.global.i.i8.p1(ptr addrspace(1) %ptr, i32 4)
   ret i8 %val
 }
 
+; CHECK: test_ldu_i16
+define i16 @test_ldu_i16(ptr addrspace(1) %ptr) {
+  ; CHECK: ldu.global.u16
+  %val = tail call i16 @llvm.nvvm.ldu.global.i.i16.p1(ptr addrspace(1) %ptr, i32 2)
+  ret i16 %val
+}
+
 ; CHECK: test_ldu_i32
 define i32 @test_ldu_i32(ptr addrspace(1) %ptr) {
-; ldu.global.u32
+  ; CHECK: ldu.global.u32
   %val = tail call i32 @llvm.nvvm.ldu.global.i.i32.p1(ptr addrspace(1) %ptr, i32 4)
   ret i32 %val
 }
 
+; CHECK: test_ldu_i64
+define i64 @test_ldu_i64(ptr addrspace(1) %ptr) {
+  ; CHECK: ldu.global.u64
+  %val = tail call i64 @llvm.nvvm.ldu.global.i.i64.p1(ptr addrspace(1) %ptr, i32 8)
+  ret i64 %val
+}
+
+; CHECK: test_ldu_f32
+define float @test_ldu_f32(ptr addrspace(1) %ptr) {
+  ; CHECK: ldu.global.f32
+  %val = tail call float @llvm.nvvm.ldu.global.f.f32.p1(ptr addrspace(1) %ptr, i32 4)
+  ret float %val
+}
+
+; CHECK: test_ldu_f64
+define double @test_ldu_f64(ptr addrspace(1) %ptr) {
+  ; CHECK: ldu.global.f64
+  %val = tail call double @llvm.nvvm.ldu.global.f.f64.p1(ptr addrspace(1) %ptr, i32 8)
+  ret double %val
+}
+
+; CHECK: test_ldu_f16
+define half @test_ldu_f16(ptr addrspace(1) %ptr) {
+  ; CHECK: ldu.global.b16
+  %val = tail call half @llvm.nvvm.ldu.global.f.f16.p1(ptr addrspace(1) %ptr, i32 2)
+  ret half %val
+}
+
+; CHECK: test_ldu_v2f16
+define <2 x half> @test_ldu_v2f16(ptr addrspace(1) %ptr) {
+  ; CHECK: ldu.global.b32
+  %val = tail call <2 x half> @llvm.nvvm.ldu.global.f.v2f16.p1(ptr addrspace(1) %ptr, i32 4)
+  ret <2 x half> %val
+}
+
 ; CHECK: test_ldg_i8
 define i8 @test_ldg_i8(ptr addrspace(1) %ptr) {
-; ld.global.nc.u8
+  ; CHECK: ld.global.nc.u8
   %val = tail call i8 @llvm.nvvm.ldg.global.i.i8.p1(ptr addrspace(1) %ptr, i32 4)
   ret i8 %val
 }
 
 ; CHECK: test_ldg_i16
 define i16 @test_ldg_i16(ptr addrspace(1) %ptr) {
-; ld.global.nc.u16
-  %val = tail call i16 @llvm.nvvm.ldg.global.i.i16.p1(ptr addrspace(1) %ptr, i32 4)
+  ; CHECK: ld.global.nc.u16
+  %val = tail call i16 @llvm.nvvm.ldg.global.i.i16.p1(ptr addrspace(1) %ptr, i32 2)
   ret i16 %val
 }
 
 ; CHECK: test_ldg_i32
 define i32 @test_ldg_i32(ptr addrspace(1) %ptr) {
-; ld.global.nc.u32
+  ; CHECK: ld.global.nc.u32
   %val = tail call i32 @llvm.nvvm.ldg.global.i.i32.p1(ptr addrspace(1) %ptr, i32 4)
   ret i32 %val
 }
 
 ; CHECK: test_ldg_i64
 define i64 @test_ldg_i64(ptr addrspace(1) %ptr) {
-; ld.global.nc.u64
+  ; CHECK: ld.global.nc.u64
   %val = tail call i64 @llvm.nvvm.ldg.global.i.i64.p1(ptr addrspace(1) %ptr, i32 8)
   ret i64 %val
 }
 
 ; CHECK: test_ldg_f32
 define float @test_ldg_f32(ptr addrspace(1) %ptr) {
-; ld.global.nc.u64
+  ; CHECK: ld.global.nc.f32
   %val = tail call float @llvm.nvvm.ldg.global.f.f32.p1(ptr addrspace(1) %ptr, i32 4)
   ret float %val
 }
 
 ; CHECK: test_ldg_f64
 define double @test_ldg_f64(ptr addrspace(1) %ptr) {
-; ld.global.nc.u64
+  ; CHECK: ld.global.nc.f64
   %val = tail call double @llvm.nvvm.ldg.global.f.f64.p1(ptr addrspace(1) %ptr, i32 8)
   ret double %val
 }
 
 ; CHECK: test_ldg_f16
 define half @test_ldg_f16(ptr addrspace(1) %ptr) {
-; ld.global.nc.b16
-  %val = tail call half @llvm.nvvm.ldg.global.f.f16.p1(ptr addrspace(1) %ptr, i32 4)
+  ; CHECK: ld.global.nc.b16
+  %val = tail call half @llvm.nvvm.ldg.global.f.f

[PATCH] D145238: [NVPTX] Expose LDU builtins

[Jakub Chlanda via Phabricator via cfe-commits]

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



Comment at: clang/lib/CodeGen/CGBuiltin.cpp:18267-18271
+auto HalfSupport = HasHalfSupport(BuiltinID);
+if (!HalfSupport.first) {
+  CGM.Error(E->getExprLoc(),
+HalfSupport.second.append(" requires native half type 
support.")
+.c_str());

tra wrote:
> jchlanda wrote:
> > tra wrote:
> > > I think we can simplify it all further.
> > > 
> > > ```
> > > auto HasHalfSupport = [&](unsigned BuiltinID) {
> > > auto &Context = getContext();
> > > return Context.getLangOpts().NativeHalfType || 
> > > !Context.getTargetInfo().useFP16ConversionIntrinsics();
> > > }
> > > ...
> > > 
> > > if (!HasHalfSupport(BuiltinID)) {
> > >   CGM.Error(E->getExprLoc(),   
> > > getContext().BuiltinInfo.getName(BuiltinID) + " requires native half type 
> > > support.");
> > > 
> > > ```
> > Done, although we need a string append there, StringRef and Twine would not 
> > work.
> We don't really need `append()`.
> `CGM.Error(E->getExprLoc(),   
> getContext().BuiltinInfo.getName(BuiltinID).str() + " requires native half 
> type support.");` works.
> 
Done.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145238

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

[PATCH] D145553: [Tooling/Inclusion] Add missing placerholder _1 symbols.

[Haojian Wu via Phabricator via cfe-commits]

hokein updated this revision to Diff 503653.
hokein marked an inline comment as done.
hokein added a comment.

address comment: add more _N symbol up to _29.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145553

Files:
  clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
  clang/tools/include-mapping/gen_std.py


Index: clang/tools/include-mapping/gen_std.py
===
--- clang/tools/include-mapping/gen_std.py
+++ clang/tools/include-mapping/gen_std.py
@@ -245,9 +245,8 @@
   # We don't index std literal operators (e.g.
   # std::literals::chrono_literals::operator""d), these symbols can't be
   # accessed by std::.
-  # FIXME: index std::placeholders symbols, placeholders.html page is
-  # different (which contains one entry for _1, _2, ..., _N), we need 
special
-  # handling.
+  #
+  # std::placeholders symbols are handled manually in 
StdSpecialSymbolMap.inc
   (symbol_index_root, "chrono.html", "std::chrono::"),
   (symbol_index_root, "filesystem.html", "std::filesystem::"),
   (symbol_index_root, "pmr.html", "std::pmr::"),
Index: clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
===
--- clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -254,6 +254,40 @@
 SYMBOL(make_index_sequence, std::, )
 SYMBOL(make_integer_sequence, std::, )
 
+// The std::placeholder symbols (_1, ..., _N) are listed in the cppreference
+// placeholder.html, but the index only contains a single entry with "_1, _2, 
..., _N"
+// text, which are not handled by the script.
+// N is an implementation-defined number (10 for libc++; 29 for libstdc++).
+SYMBOL(_1, std::placeholders::, )
+SYMBOL(_2, std::placeholders::, )
+SYMBOL(_3, std::placeholders::, )
+SYMBOL(_4, std::placeholders::, )
+SYMBOL(_5, std::placeholders::, )
+SYMBOL(_6, std::placeholders::, )
+SYMBOL(_7, std::placeholders::, )
+SYMBOL(_8, std::placeholders::, )
+SYMBOL(_9, std::placeholders::, )
+SYMBOL(_10, std::placeholders::, )
+SYMBOL(_11, std::placeholders::, )
+SYMBOL(_12, std::placeholders::, )
+SYMBOL(_13, std::placeholders::, )
+SYMBOL(_14, std::placeholders::, )
+SYMBOL(_15, std::placeholders::, )
+SYMBOL(_16, std::placeholders::, )
+SYMBOL(_17, std::placeholders::, )
+SYMBOL(_18, std::placeholders::, )
+SYMBOL(_19, std::placeholders::, )
+SYMBOL(_20, std::placeholders::, )
+SYMBOL(_21, std::placeholders::, )
+SYMBOL(_22, std::placeholders::, )
+SYMBOL(_23, std::placeholders::, )
+SYMBOL(_24, std::placeholders::, )
+SYMBOL(_25, std::placeholders::, )
+SYMBOL(_26, std::placeholders::, )
+SYMBOL(_27, std::placeholders::, )
+SYMBOL(_28, std::placeholders::, )
+SYMBOL(_29, std::placeholders::, )
+
 // Macros
 SYMBOL(NULL, None, )
 SYMBOL(NULL, None, )


Index: clang/tools/include-mapping/gen_std.py
===
--- clang/tools/include-mapping/gen_std.py
+++ clang/tools/include-mapping/gen_std.py
@@ -245,9 +245,8 @@
   # We don't index std literal operators (e.g.
   # std::literals::chrono_literals::operator""d), these symbols can't be
   # accessed by std::.
-  # FIXME: index std::placeholders symbols, placeholders.html page is
-  # different (which contains one entry for _1, _2, ..., _N), we need special
-  # handling.
+  #
+  # std::placeholders symbols are handled manually in StdSpecialSymbolMap.inc
   (symbol_index_root, "chrono.html", "std::chrono::"),
   (symbol_index_root, "filesystem.html", "std::filesystem::"),
   (symbol_index_root, "pmr.html", "std::pmr::"),
Index: clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
===
--- clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -254,6 +254,40 @@
 SYMBOL(make_index_sequence, std::, )
 SYMBOL(make_integer_sequence, std::, )
 
+// The std::placeholder symbols (_1, ..., _N) are listed in the cppreference
+// placeholder.html, but the index only contains a single entry with "_1, _2, ..., _N"
+// text, which are not handled by the script.
+// N is an implementation-defined number (10 for libc++; 29 for libstdc++).
+SYMBOL(_1, std::placeholders::, )
+SYMBOL(_2, std::placeholders::, )
+SYMBOL(_3, std::placeholders::, )
+SYMBOL(_4, std::placeholders::, )
+SYMBOL(_5, std::placeholders::, )
+SYMBOL(_6, std::placeholders::, )
+SYMBOL(_7, std::placeholders::, )
+SYMBOL(_8, std::placeholders::, )
+SYMBOL(_9, std::placeholders::, )
+SYMBOL(_10, std::placeholders::, )
+SYMBOL(_11, std::placeholders::, )
+SYMBOL(_12, std::placeholders::, )
+SYMBOL(_13, std::placeholders::, )
+SYMBOL(_14, std::placeholders::, )
+SYMBOL(_15, std::placeholder

[PATCH] D145659: [clang] Add AVR specific inline assembly escaped characters

[Ben Shi via Phabricator via cfe-commits]

benshi001 created this revision.
benshi001 added reviewers: jacquesguan, aykevl.
Herald added subscribers: Jim, dylanmckay.
Herald added a project: All.
benshi001 requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Fixes https://github.com/llvm/llvm-project/issues/60204


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D145659

Files:
  clang/lib/Basic/Targets/AVR.cpp
  clang/lib/Basic/Targets/AVR.h
  clang/test/CodeGen/avr/avr-inline-asm-constraints.c


Index: clang/test/CodeGen/avr/avr-inline-asm-constraints.c
===
--- clang/test/CodeGen/avr/avr-inline-asm-constraints.c
+++ clang/test/CodeGen/avr/avr-inline-asm-constraints.c
@@ -1,5 +1,10 @@
 // REQUIRES: avr-registered-target
-// RUN: %clang_cc1 -triple avr-unknown-unknown -emit-llvm -o - %s | FileCheck 
%s
+// RUN: %clang_cc1 -x c -triple avr -target-cpu at90s8515 -emit-llvm -o - %s \
+// RUN: | FileCheck --check-prefixes=CHECK,AVR25 %s
+// RUN: %clang_cc1 -x c -triple avr -target-cpu atmega328 -emit-llvm -o - %s \
+// RUN: | FileCheck --check-prefixes=CHECK,AVR51 %s
+// RUN: %clang_cc1 -x c -triple avr -target-cpu atmega2560 -emit-llvm -o - %s \
+// RUN: | FileCheck --check-prefixes=CHECK,AVR6 %s
 
 int data;
 
@@ -122,3 +127,23 @@
   // CHECK: call addrspace(0) i16 asm "subi r30, $0", "=ra"()
   asm("subi r30, %0" : "=ra"(data));
 }
+
+void escapeChar(void) {
+  asm("_foo:");
+  // AVR25: call addrspace(0) void asm sideeffect "rcall _foo"
+  // AVR51: call addrspace(0) void asm sideeffect "call _foo"
+  // AVR6:  call addrspace(0) void asm sideeffect "call _foo"
+  asm("%~call _foo" ::);
+  // AVR25: call addrspace(0) void asm sideeffect "rjmp _foo"
+  // AVR51: call addrspace(0) void asm sideeffect "jmp _foo"
+  // AVR6:  call addrspace(0) void asm sideeffect "jmp _foo"
+  asm("%~jmp _foo" ::);
+  // AVR25: call addrspace(0) void asm sideeffect "icall"
+  // AVR51: call addrspace(0) void asm sideeffect "icall"
+  // AVR6:  call addrspace(0) void asm sideeffect "eicall"
+  asm("%!icall" ::);
+  // AVR25: call addrspace(0) void asm sideeffect "ijmp"
+  // AVR51: call addrspace(0) void asm sideeffect "ijmp"
+  // AVR6:  call addrspace(0) void asm sideeffect "eijmp"
+  asm("%!ijmp" ::);
+}
Index: clang/lib/Basic/Targets/AVR.h
===
--- clang/lib/Basic/Targets/AVR.h
+++ clang/lib/Basic/Targets/AVR.h
@@ -170,6 +170,7 @@
   bool isValidCPUName(StringRef Name) const override;
   void fillValidCPUList(SmallVectorImpl &Values) const override;
   bool setCPU(const std::string &Name) override;
+  std::optional handleAsmEscapedChar(char EscChar) const override;
   StringRef getABI() const override { return ABI; }
 
 protected:
Index: clang/lib/Basic/Targets/AVR.cpp
===
--- clang/lib/Basic/Targets/AVR.cpp
+++ clang/lib/Basic/Targets/AVR.cpp
@@ -428,6 +428,24 @@
   return false;
 }
 
+std::optional
+AVRTargetInfo::handleAsmEscapedChar(char EscChar) const {
+  char C;
+  switch (EscChar) {
+  // "%~" represents for 'r' depends on the device has long jump/call.
+  case '~':
+return ArchHasJMPCALL(Arch) ? std::string("") : std::string(1, 'r');
+
+  // "%!" represents for 'e' depends on the PC register size.
+  case '!':
+return ArchHas3BytePC(Arch) ? std::string(1, 'e') : std::string("");
+
+  // This is an invalid escape character for AVR.
+  default:
+return std::nullopt;
+  }
+}
+
 void AVRTargetInfo::getTargetDefines(const LangOptions &Opts,
  MacroBuilder &Builder) const {
   Builder.defineMacro("AVR");


Index: clang/test/CodeGen/avr/avr-inline-asm-constraints.c
===
--- clang/test/CodeGen/avr/avr-inline-asm-constraints.c
+++ clang/test/CodeGen/avr/avr-inline-asm-constraints.c
@@ -1,5 +1,10 @@
 // REQUIRES: avr-registered-target
-// RUN: %clang_cc1 -triple avr-unknown-unknown -emit-llvm -o - %s | FileCheck %s
+// RUN: %clang_cc1 -x c -triple avr -target-cpu at90s8515 -emit-llvm -o - %s \
+// RUN: | FileCheck --check-prefixes=CHECK,AVR25 %s
+// RUN: %clang_cc1 -x c -triple avr -target-cpu atmega328 -emit-llvm -o - %s \
+// RUN: | FileCheck --check-prefixes=CHECK,AVR51 %s
+// RUN: %clang_cc1 -x c -triple avr -target-cpu atmega2560 -emit-llvm -o - %s \
+// RUN: | FileCheck --check-prefixes=CHECK,AVR6 %s
 
 int data;
 
@@ -122,3 +127,23 @@
   // CHECK: call addrspace(0) i16 asm "subi r30, $0", "=ra"()
   asm("subi r30, %0" : "=ra"(data));
 }
+
+void escapeChar(void) {
+  asm("_foo:");
+  // AVR25: call addrspace(0) void asm sideeffect "rcall _foo"
+  // AVR51: call addrspace(0) void asm sideeffect "call _foo"
+  // AVR6:  call addrspace(0) void asm sideeffect "call _foo"
+  asm("%~call _foo" ::);
+  // AVR25: call addrspace(0) void asm sideeffect "rjmp _foo"
+  // AVR51: call a

[clang] 1c33c41 - [doc] Deprecate the '-fmodule-file==' for named modules in the document

[Chuanqi Xu via cfe-commits]

Author: Chuanqi Xu
Date: 2023-03-09T16:20:01+08:00
New Revision: 1c33c419e41e412a1b2476e9979034a42b8dda56

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

LOG: [doc] Deprecate the '-fmodule-file==' for named 
modules in the document

The option '-fmodule-file==' is already
deprecated now. This patch mentions it in the document.

Added: 


Modified: 
clang/docs/StandardCPlusPlusModules.rst

Removed: 




diff  --git a/clang/docs/StandardCPlusPlusModules.rst 
b/clang/docs/StandardCPlusPlusModules.rst
index 816199052f2bc..bcf2c4470c521 100644
--- a/clang/docs/StandardCPlusPlusModules.rst
+++ b/clang/docs/StandardCPlusPlusModules.rst
@@ -200,7 +200,7 @@ Then we are able to compile the example by the following 
command:
   $ clang++ -std=c++20 interface_part.cppm --precompile -o M-interface_part.pcm
   $ clang++ -std=c++20 impl_part.cppm --precompile -fprebuilt-module-path=. -o 
M-impl_part.pcm
   $ clang++ -std=c++20 M.cppm --precompile -fprebuilt-module-path=. -o M.pcm
-  $ clang++ -std=c++20 Impl.cpp -fmodule-file=M.pcm -c -o Impl.o
+  $ clang++ -std=c++20 Impl.cpp -fmodule-file=M=M.pcm -c -o Impl.o
 
   # Compiling the user
   $ clang++ -std=c++20 User.cpp -fprebuilt-module-path=. -c -o User.o
@@ -332,7 +332,7 @@ How to specify the dependent BMIs
 There are 3 methods to specify the dependent BMIs:
 
 * (1) ``-fprebuilt-module-path=``.
-* (2) ``-fmodule-file=``.
+* (2) ``-fmodule-file=`` (Deprecated).
 * (3) ``-fmodule-file==``.
 
 The option ``-fprebuilt-module-path`` tells the compiler the path where to 
search for dependent BMIs.
@@ -348,7 +348,8 @@ The option ``-fmodule-file==`` 
tells the compiler to l
 for the module specified by  when necessary. The main 
diff erence is that
 ``-fmodule-file=`` will load the BMI eagerly, whereas
 ``-fmodule-file==`` will only load the BMI lazily, 
which is similar
-with ``-fprebuilt-module-path``.
+with ``-fprebuilt-module-path``. The option ``-fmodule-file=`` 
for named modules is deprecated
+and is planning to be removed in future versions.
 
 In case all ``-fprebuilt-module-path=``, 
``-fmodule-file=`` and
 ``-fmodule-file==`` exist, the 
``-fmodule-file=`` option
@@ -372,7 +373,6 @@ the above example could be rewritten into:
 
 .. code-block:: console
 
-  $ clang++ -std=c++20 M.cppm --precompile -fmodule-file=M-interface_part.pcm 
-fmodule-file=M-impl_part.pcm -o M.pcm
   $ clang++ -std=c++20 M.cppm --precompile 
-fmodule-file=M:interface_part=M-interface_part.pcm 
-fmodule-file=M:impl_part=M-impl_part.pcm -o M.pcm
 
 ``-fprebuilt-module-path`` is more convenient and ``-fmodule-file`` is faster 
since
@@ -486,7 +486,7 @@ source files. For example:
 
   $ clang++ -std=c++20 M.cppm --precompile -o M.pcm
   $ rm M.cppm
-  $ clang++ -std=c++20 Use.cpp -fmodule-file=M.pcm
+  $ clang++ -std=c++20 Use.cpp -fmodule-file=M=M.pcm
 
 The compiler would reject the example since the compiler failed to find the 
source file to check the consistency.
 So the following example would be rejected too.
@@ -495,7 +495,7 @@ So the following example would be rejected too.
 
   $ clang++ -std=c++20 M.cppm --precompile -o M.pcm
   $ echo "int i=0;" >> M.cppm
-  $ clang++ -std=c++20 Use.cpp -fmodule-file=M.pcm
+  $ clang++ -std=c++20 Use.cpp -fmodule-file=M=M.pcm
 
 The compiler would reject it too since the compiler detected the file was 
changed.
 
@@ -506,7 +506,7 @@ But it is OK to move the BMI as long as the source files 
remain:
   $ clang++ -std=c++20 M.cppm --precompile -o M.pcm
   $ mkdir -p tmp
   $ mv M.pcm tmp/M.pcm
-  $ clang++ -std=c++20 Use.cpp -fmodule-file=tmp/M.pcm
+  $ clang++ -std=c++20 Use.cpp -fmodule-file=M=tmp/M.pcm
 
 The above example would be accepted.
 
@@ -517,7 +517,7 @@ the user could try to use ``-Xclang 
-fmodules-embed-all-files`` when producing B
 
   $ clang++ -std=c++20 M.cppm --precompile -Xclang -fmodules-embed-all-files 
-o M.pcm
   $ rm M.cppm
-  $ clang++ -std=c++20 Use.cpp -fmodule-file=M.pcm
+  $ clang++ -std=c++20 Use.cpp -fmodule-file=M=M.pcm
 
 Now the compiler would accept the above example.
 Important note: Xclang options are intended to be used by compiler internally 
and its semantics
@@ -553,7 +553,7 @@ Then it is problematic if we remove ``foo.h`` before import 
`foo` module.
   $ clang++ -std=c++20 foo.cppm --precompile  -o foo.pcm
   $ mv foo.h foo.orig.h
   # The following one is rejected
-  $ clang++ -std=c++20 Use.cpp -fmodule-file=foo.pcm -c
+  $ clang++ -std=c++20 Use.cpp -fmodule-file=foo=foo.pcm -c
 
 The above case will rejected. And we're still able to workaround it by 
``-Xclang -fmodules-embed-all-files`` option:
 
@@ -561,7 +561,7 @@ The above case will rejected. And we're still able to 
workaround it by ``-Xclang
 
   $ clang++ -std=c++20 foo.cppm --precompile  -Xclang 
-fmodules-embed-a

[clang] 404b1b2 - [Tooling/Inclusion] Add missing placerholder _1 symbols.

[Haojian Wu via cfe-commits]

Author: Haojian Wu
Date: 2023-03-09T09:20:42+01:00
New Revision: 404b1b2ed42f6138a0e91b337150a90108c1b155

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

LOG: [Tooling/Inclusion] Add missing placerholder _1 symbols.

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

Added: 


Modified: 
clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
clang/tools/include-mapping/gen_std.py

Removed: 




diff  --git a/clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc 
b/clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
index ecdcfee35128b..aa2227b646774 100644
--- a/clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ b/clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -254,6 +254,40 @@ SYMBOL(index_sequence_for, std::, )
 SYMBOL(make_index_sequence, std::, )
 SYMBOL(make_integer_sequence, std::, )
 
+// The std::placeholder symbols (_1, ..., _N) are listed in the cppreference
+// placeholder.html, but the index only contains a single entry with "_1, _2, 
..., _N"
+// text, which are not handled by the script.
+// N is an implementation-defined number (10 for libc++; 29 for libstdc++).
+SYMBOL(_1, std::placeholders::, )
+SYMBOL(_2, std::placeholders::, )
+SYMBOL(_3, std::placeholders::, )
+SYMBOL(_4, std::placeholders::, )
+SYMBOL(_5, std::placeholders::, )
+SYMBOL(_6, std::placeholders::, )
+SYMBOL(_7, std::placeholders::, )
+SYMBOL(_8, std::placeholders::, )
+SYMBOL(_9, std::placeholders::, )
+SYMBOL(_10, std::placeholders::, )
+SYMBOL(_11, std::placeholders::, )
+SYMBOL(_12, std::placeholders::, )
+SYMBOL(_13, std::placeholders::, )
+SYMBOL(_14, std::placeholders::, )
+SYMBOL(_15, std::placeholders::, )
+SYMBOL(_16, std::placeholders::, )
+SYMBOL(_17, std::placeholders::, )
+SYMBOL(_18, std::placeholders::, )
+SYMBOL(_19, std::placeholders::, )
+SYMBOL(_20, std::placeholders::, )
+SYMBOL(_21, std::placeholders::, )
+SYMBOL(_22, std::placeholders::, )
+SYMBOL(_23, std::placeholders::, )
+SYMBOL(_24, std::placeholders::, )
+SYMBOL(_25, std::placeholders::, )
+SYMBOL(_26, std::placeholders::, )
+SYMBOL(_27, std::placeholders::, )
+SYMBOL(_28, std::placeholders::, )
+SYMBOL(_29, std::placeholders::, )
+
 // Macros
 SYMBOL(NULL, None, )
 SYMBOL(NULL, None, )

diff  --git a/clang/tools/include-mapping/gen_std.py 
b/clang/tools/include-mapping/gen_std.py
index 291946ef5378b..45ae60fc6f000 100755
--- a/clang/tools/include-mapping/gen_std.py
+++ b/clang/tools/include-mapping/gen_std.py
@@ -245,9 +245,8 @@ def main():
   # We don't index std literal operators (e.g.
   # std::literals::chrono_literals::operator""d), these symbols can't be
   # accessed by std::.
-  # FIXME: index std::placeholders symbols, placeholders.html page is
-  # 
diff erent (which contains one entry for _1, _2, ..., _N), we need special
-  # handling.
+  #
+  # std::placeholders symbols are handled manually in 
StdSpecialSymbolMap.inc
   (symbol_index_root, "chrono.html", "std::chrono::"),
   (symbol_index_root, "filesystem.html", "std::filesystem::"),
   (symbol_index_root, "pmr.html", "std::pmr::"),



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

[PATCH] D145553: [Tooling/Inclusion] Add missing placerholder _1 symbols.

[Haojian Wu 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 rG404b1b2ed42f: [Tooling/Inclusion] Add missing placerholder 
_1 symbols. (authored by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145553

Files:
  clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
  clang/tools/include-mapping/gen_std.py


Index: clang/tools/include-mapping/gen_std.py
===
--- clang/tools/include-mapping/gen_std.py
+++ clang/tools/include-mapping/gen_std.py
@@ -245,9 +245,8 @@
   # We don't index std literal operators (e.g.
   # std::literals::chrono_literals::operator""d), these symbols can't be
   # accessed by std::.
-  # FIXME: index std::placeholders symbols, placeholders.html page is
-  # different (which contains one entry for _1, _2, ..., _N), we need 
special
-  # handling.
+  #
+  # std::placeholders symbols are handled manually in 
StdSpecialSymbolMap.inc
   (symbol_index_root, "chrono.html", "std::chrono::"),
   (symbol_index_root, "filesystem.html", "std::filesystem::"),
   (symbol_index_root, "pmr.html", "std::pmr::"),
Index: clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
===
--- clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -254,6 +254,40 @@
 SYMBOL(make_index_sequence, std::, )
 SYMBOL(make_integer_sequence, std::, )
 
+// The std::placeholder symbols (_1, ..., _N) are listed in the cppreference
+// placeholder.html, but the index only contains a single entry with "_1, _2, 
..., _N"
+// text, which are not handled by the script.
+// N is an implementation-defined number (10 for libc++; 29 for libstdc++).
+SYMBOL(_1, std::placeholders::, )
+SYMBOL(_2, std::placeholders::, )
+SYMBOL(_3, std::placeholders::, )
+SYMBOL(_4, std::placeholders::, )
+SYMBOL(_5, std::placeholders::, )
+SYMBOL(_6, std::placeholders::, )
+SYMBOL(_7, std::placeholders::, )
+SYMBOL(_8, std::placeholders::, )
+SYMBOL(_9, std::placeholders::, )
+SYMBOL(_10, std::placeholders::, )
+SYMBOL(_11, std::placeholders::, )
+SYMBOL(_12, std::placeholders::, )
+SYMBOL(_13, std::placeholders::, )
+SYMBOL(_14, std::placeholders::, )
+SYMBOL(_15, std::placeholders::, )
+SYMBOL(_16, std::placeholders::, )
+SYMBOL(_17, std::placeholders::, )
+SYMBOL(_18, std::placeholders::, )
+SYMBOL(_19, std::placeholders::, )
+SYMBOL(_20, std::placeholders::, )
+SYMBOL(_21, std::placeholders::, )
+SYMBOL(_22, std::placeholders::, )
+SYMBOL(_23, std::placeholders::, )
+SYMBOL(_24, std::placeholders::, )
+SYMBOL(_25, std::placeholders::, )
+SYMBOL(_26, std::placeholders::, )
+SYMBOL(_27, std::placeholders::, )
+SYMBOL(_28, std::placeholders::, )
+SYMBOL(_29, std::placeholders::, )
+
 // Macros
 SYMBOL(NULL, None, )
 SYMBOL(NULL, None, )


Index: clang/tools/include-mapping/gen_std.py
===
--- clang/tools/include-mapping/gen_std.py
+++ clang/tools/include-mapping/gen_std.py
@@ -245,9 +245,8 @@
   # We don't index std literal operators (e.g.
   # std::literals::chrono_literals::operator""d), these symbols can't be
   # accessed by std::.
-  # FIXME: index std::placeholders symbols, placeholders.html page is
-  # different (which contains one entry for _1, _2, ..., _N), we need special
-  # handling.
+  #
+  # std::placeholders symbols are handled manually in StdSpecialSymbolMap.inc
   (symbol_index_root, "chrono.html", "std::chrono::"),
   (symbol_index_root, "filesystem.html", "std::filesystem::"),
   (symbol_index_root, "pmr.html", "std::pmr::"),
Index: clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
===
--- clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -254,6 +254,40 @@
 SYMBOL(make_index_sequence, std::, )
 SYMBOL(make_integer_sequence, std::, )
 
+// The std::placeholder symbols (_1, ..., _N) are listed in the cppreference
+// placeholder.html, but the index only contains a single entry with "_1, _2, ..., _N"
+// text, which are not handled by the script.
+// N is an implementation-defined number (10 for libc++; 29 for libstdc++).
+SYMBOL(_1, std::placeholders::, )
+SYMBOL(_2, std::placeholders::, )
+SYMBOL(_3, std::placeholders::, )
+SYMBOL(_4, std::placeholders::, )
+SYMBOL(_5, std::placeholders::, )
+SYMBOL(_6, std::placeholders::, )
+SYMBOL(_7, std::placeholders::, )
+SYMBOL(_8, std::placeholders::, )
+SYMBOL(_9, std::placeholders::, )
+SYMBOL(_10, std::placeholders::, )
+SYMBOL(_11, std::placeholders::, )
+SYMBOL(_12, std::placeholders::, )
+SYMBOL(_13, std:

[clang] 22c0ce9 - [Tooling/Inclusion] Add atomic family symbols

[Haojian Wu via cfe-commits]

Author: Haojian Wu
Date: 2023-03-09T09:21:18+01:00
New Revision: 22c0ce96912f55f48ba4535800bacc0c48fe9832

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

LOG: [Tooling/Inclusion] Add atomic family symbols

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

Added: 


Modified: 
clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc

Removed: 




diff  --git a/clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc 
b/clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
index aa2227b64677..13a8d310a95b 100644
--- a/clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ b/clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -242,6 +242,107 @@ SYMBOL(abs, None, )
 SYMBOL(abs, None, )
 SYMBOL(abs, None, )
 
+// Only add headers for the generic atomic template.
+// Ignore variants (std::weak_ptr, std::shared_ptr).
+SYMBOL(atomic, std::, )
+// atomic_* family symbols.  is for C compatibility.
+SYMBOL(atomic_bool, std::, )
+SYMBOL(atomic_bool, None, )
+SYMBOL(atomic_char, std::, )
+SYMBOL(atomic_char, None, )
+SYMBOL(atomic_char16_t, std::, )
+SYMBOL(atomic_char16_t, None, )
+SYMBOL(atomic_char32_t, std::, )
+SYMBOL(atomic_char32_t, None, )
+SYMBOL(atomic_char8_t, std::, )
+SYMBOL(atomic_char8_t, None, )
+SYMBOL(atomic_int, std::, )
+SYMBOL(atomic_int, None, )
+SYMBOL(atomic_int16_t, std::, )
+SYMBOL(atomic_int16_t, None, )
+SYMBOL(atomic_int32_t, std::, )
+SYMBOL(atomic_int32_t, None, )
+SYMBOL(atomic_int64_t, std::, )
+SYMBOL(atomic_int64_t, None, )
+SYMBOL(atomic_int8_t, std::, )
+SYMBOL(atomic_int8_t, None, )
+SYMBOL(atomic_int_fast16_t, std::, )
+SYMBOL(atomic_int_fast16_t, None, )
+SYMBOL(atomic_int_fast32_t, std::, )
+SYMBOL(atomic_int_fast32_t, None, )
+SYMBOL(atomic_int_fast64_t, std::, )
+SYMBOL(atomic_int_fast64_t, None, )
+SYMBOL(atomic_int_fast8_t, std::, )
+SYMBOL(atomic_int_fast8_t, None, )
+SYMBOL(atomic_int_least16_t, std::, )
+SYMBOL(atomic_int_least16_t, None, )
+SYMBOL(atomic_int_least32_t, std::, )
+SYMBOL(atomic_int_least32_t, None, )
+SYMBOL(atomic_int_least64_t, std::, )
+SYMBOL(atomic_int_least64_t, None, )
+SYMBOL(atomic_int_least8_t, std::, )
+SYMBOL(atomic_int_least8_t, None, )
+SYMBOL(atomic_intmax_t, std::, )
+SYMBOL(atomic_intmax_t, None, )
+SYMBOL(atomic_intptr_t, std::, )
+SYMBOL(atomic_intptr_t, None, )
+SYMBOL(atomic_llong, std::, )
+SYMBOL(atomic_llong, None, )
+SYMBOL(atomic_long, std::, )
+SYMBOL(atomic_long, None, )
+SYMBOL(atomic_ptr
diff _t, std::, )
+SYMBOL(atomic_ptr
diff _t, None, )
+SYMBOL(atomic_schar, std::, )
+SYMBOL(atomic_schar, None, )
+SYMBOL(atomic_short, std::, )
+SYMBOL(atomic_short, None, )
+SYMBOL(atomic_signed_lock_free, std::, )
+SYMBOL(atomic_signed_lock_free, None, )
+SYMBOL(atomic_size_t, std::, )
+SYMBOL(atomic_size_t, None, )
+SYMBOL(atomic_uchar, std::, )
+SYMBOL(atomic_uchar, None, )
+SYMBOL(atomic_uint, std::, )
+SYMBOL(atomic_uint, None, )
+SYMBOL(atomic_uint16_t, std::, )
+SYMBOL(atomic_uint16_t, None, )
+SYMBOL(atomic_uint32_t, std::, )
+SYMBOL(atomic_uint32_t, None, )
+SYMBOL(atomic_uint64_t, std::, )
+SYMBOL(atomic_uint64_t, None, )
+SYMBOL(atomic_uint8_t, std::, )
+SYMBOL(atomic_uint8_t, None, )
+SYMBOL(atomic_uint_fast16_t, std::, )
+SYMBOL(atomic_uint_fast16_t, None, )
+SYMBOL(atomic_uint_fast32_t, std::, )
+SYMBOL(atomic_uint_fast32_t, None, )
+SYMBOL(atomic_uint_fast64_t, std::, )
+SYMBOL(atomic_uint_fast64_t, None, )
+SYMBOL(atomic_uint_fast8_t, std::, )
+SYMBOL(atomic_uint_fast8_t, None, )
+SYMBOL(atomic_uint_least16_t, std::, )
+SYMBOL(atomic_uint_least16_t, None, )
+SYMBOL(atomic_uint_least32_t, std::, )
+SYMBOL(atomic_uint_least32_t, None, )
+SYMBOL(atomic_uint_least64_t, std::, )
+SYMBOL(atomic_uint_least64_t, None, )
+SYMBOL(atomic_uint_least8_t, std::, )
+SYMBOL(atomic_uint_least8_t, None, )
+SYMBOL(atomic_uintmax_t, std::, )
+SYMBOL(atomic_uintmax_t, None, )
+SYMBOL(atomic_uintptr_t, std::, )
+SYMBOL(atomic_uintptr_t, None, )
+SYMBOL(atomic_ullong, std::, )
+SYMBOL(atomic_ullong, None, )
+SYMBOL(atomic_ulong, std::, )
+SYMBOL(atomic_ulong, None, )
+SYMBOL(atomic_unsigned_lock_free, std::, )
+SYMBOL(atomic_unsigned_lock_free, None, )
+SYMBOL(atomic_ushort, std::, )
+SYMBOL(atomic_ushort, None, )
+SYMBOL(atomic_wchar_t, std::, )
+SYMBOL(atomic_wchar_t, None, )
+
 // std::get has a few variants for 
diff erent types (tuple, array, pair etc)
 // which is tricky to disambiguate without type information.
 // Don't set any header for it, as it comes with the type header.



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

[PATCH] D145557: [Tooling/Inclusion] Add atomic family symbols

[Haojian Wu via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG22c0ce96912f: [Tooling/Inclusion] Add atomic family symbols 
(authored by hokein).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145557

Files:
  clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc

Index: clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
===
--- clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
+++ clang/lib/Tooling/Inclusions/Stdlib/StdSpecialSymbolMap.inc
@@ -242,6 +242,107 @@
 SYMBOL(abs, None, )
 SYMBOL(abs, None, )
 
+// Only add headers for the generic atomic template.
+// Ignore variants (std::weak_ptr, std::shared_ptr).
+SYMBOL(atomic, std::, )
+// atomic_* family symbols.  is for C compatibility.
+SYMBOL(atomic_bool, std::, )
+SYMBOL(atomic_bool, None, )
+SYMBOL(atomic_char, std::, )
+SYMBOL(atomic_char, None, )
+SYMBOL(atomic_char16_t, std::, )
+SYMBOL(atomic_char16_t, None, )
+SYMBOL(atomic_char32_t, std::, )
+SYMBOL(atomic_char32_t, None, )
+SYMBOL(atomic_char8_t, std::, )
+SYMBOL(atomic_char8_t, None, )
+SYMBOL(atomic_int, std::, )
+SYMBOL(atomic_int, None, )
+SYMBOL(atomic_int16_t, std::, )
+SYMBOL(atomic_int16_t, None, )
+SYMBOL(atomic_int32_t, std::, )
+SYMBOL(atomic_int32_t, None, )
+SYMBOL(atomic_int64_t, std::, )
+SYMBOL(atomic_int64_t, None, )
+SYMBOL(atomic_int8_t, std::, )
+SYMBOL(atomic_int8_t, None, )
+SYMBOL(atomic_int_fast16_t, std::, )
+SYMBOL(atomic_int_fast16_t, None, )
+SYMBOL(atomic_int_fast32_t, std::, )
+SYMBOL(atomic_int_fast32_t, None, )
+SYMBOL(atomic_int_fast64_t, std::, )
+SYMBOL(atomic_int_fast64_t, None, )
+SYMBOL(atomic_int_fast8_t, std::, )
+SYMBOL(atomic_int_fast8_t, None, )
+SYMBOL(atomic_int_least16_t, std::, )
+SYMBOL(atomic_int_least16_t, None, )
+SYMBOL(atomic_int_least32_t, std::, )
+SYMBOL(atomic_int_least32_t, None, )
+SYMBOL(atomic_int_least64_t, std::, )
+SYMBOL(atomic_int_least64_t, None, )
+SYMBOL(atomic_int_least8_t, std::, )
+SYMBOL(atomic_int_least8_t, None, )
+SYMBOL(atomic_intmax_t, std::, )
+SYMBOL(atomic_intmax_t, None, )
+SYMBOL(atomic_intptr_t, std::, )
+SYMBOL(atomic_intptr_t, None, )
+SYMBOL(atomic_llong, std::, )
+SYMBOL(atomic_llong, None, )
+SYMBOL(atomic_long, std::, )
+SYMBOL(atomic_long, None, )
+SYMBOL(atomic_ptrdiff_t, std::, )
+SYMBOL(atomic_ptrdiff_t, None, )
+SYMBOL(atomic_schar, std::, )
+SYMBOL(atomic_schar, None, )
+SYMBOL(atomic_short, std::, )
+SYMBOL(atomic_short, None, )
+SYMBOL(atomic_signed_lock_free, std::, )
+SYMBOL(atomic_signed_lock_free, None, )
+SYMBOL(atomic_size_t, std::, )
+SYMBOL(atomic_size_t, None, )
+SYMBOL(atomic_uchar, std::, )
+SYMBOL(atomic_uchar, None, )
+SYMBOL(atomic_uint, std::, )
+SYMBOL(atomic_uint, None, )
+SYMBOL(atomic_uint16_t, std::, )
+SYMBOL(atomic_uint16_t, None, )
+SYMBOL(atomic_uint32_t, std::, )
+SYMBOL(atomic_uint32_t, None, )
+SYMBOL(atomic_uint64_t, std::, )
+SYMBOL(atomic_uint64_t, None, )
+SYMBOL(atomic_uint8_t, std::, )
+SYMBOL(atomic_uint8_t, None, )
+SYMBOL(atomic_uint_fast16_t, std::, )
+SYMBOL(atomic_uint_fast16_t, None, )
+SYMBOL(atomic_uint_fast32_t, std::, )
+SYMBOL(atomic_uint_fast32_t, None, )
+SYMBOL(atomic_uint_fast64_t, std::, )
+SYMBOL(atomic_uint_fast64_t, None, )
+SYMBOL(atomic_uint_fast8_t, std::, )
+SYMBOL(atomic_uint_fast8_t, None, )
+SYMBOL(atomic_uint_least16_t, std::, )
+SYMBOL(atomic_uint_least16_t, None, )
+SYMBOL(atomic_uint_least32_t, std::, )
+SYMBOL(atomic_uint_least32_t, None, )
+SYMBOL(atomic_uint_least64_t, std::, )
+SYMBOL(atomic_uint_least64_t, None, )
+SYMBOL(atomic_uint_least8_t, std::, )
+SYMBOL(atomic_uint_least8_t, None, )
+SYMBOL(atomic_uintmax_t, std::, )
+SYMBOL(atomic_uintmax_t, None, )
+SYMBOL(atomic_uintptr_t, std::, )
+SYMBOL(atomic_uintptr_t, None, )
+SYMBOL(atomic_ullong, std::, )
+SYMBOL(atomic_ullong, None, )
+SYMBOL(atomic_ulong, std::, )
+SYMBOL(atomic_ulong, None, )
+SYMBOL(atomic_unsigned_lock_free, std::, )
+SYMBOL(atomic_unsigned_lock_free, None, )
+SYMBOL(atomic_ushort, std::, )
+SYMBOL(atomic_ushort, None, )
+SYMBOL(atomic_wchar_t, std::, )
+SYMBOL(atomic_wchar_t, None, )
+
 // std::get has a few variants for different types (tuple, array, pair etc)
 // which is tricky to disambiguate without type information.
 // Don't set any header for it, as it comes with the type header.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D130303: Handle template parameter-dependent bit field widths in libclang

[Igor Kushnir via Phabricator via cfe-commits]

vedgy added a comment.

Please update the commit message (there is no 
`clang_isFieldDeclBitWidthDependent` anymore) and update the revision with `arc 
diff --verbatim @~`.




Comment at: clang/include/clang-c/Index.h:3552
+ * If the cursor does not reference a bit field declaration or if the bit
+ * field's width does not depend on template parameters, 0 is returned.
+ */

collinbaker wrote:
> vedgy wrote:
> > vedgy wrote:
> > > collinbaker wrote:
> > > > vedgy wrote:
> > > > > I just thought how the new API could be used in KDevelop. Currently 
> > > > > when `clang_getFieldDeclBitWidth()` is positive, e.g. 2, KDevelop 
> > > > > shows  ` : 2` after the data member name in a tooltip. Ideally a 
> > > > > template-param-dependent expression (actual code) would be displayed 
> > > > > after the colon. If that's difficult to implement, `: 
> > > > > [tparam-dependent]` or `: ?` could be displayed instead. But it would 
> > > > > be more convenient and efficient to get this information by a single 
> > > > > call to `clang_getFieldDeclBitWidth()` instead of calling 
> > > > > `clang_isFieldDeclBitWidthDependent()` each time 
> > > > > `clang_getFieldDeclBitWidth()` returns `-1`. So how about returning 
> > > > > `-2` or `0` from `clang_getFieldDeclBitWidth()` instead of adding 
> > > > > this new API?
> > > > I understand the motivation but I don't think requiring an extra call 
> > > > is asking too much of libclang clients, and it's one extra call that 
> > > > doesn't do much work and will be called rarely so I don't see 
> > > > efficiency concerns. Without strong reasons otherwise I think it's 
> > > > better to be explicit here.
> > > KDevelop calls `clang_getFieldDeclBitWidth()` for each encountered class 
> > > member declaration. `clang_isFieldDeclBitWidthDependent()` would have to 
> > > be called each time `clang_getFieldDeclBitWidth()` returns `-1`, which 
> > > would be most of the time, because few class members are bit-fields. The 
> > > work this new function does is the same as that of 
> > > `clang_getFieldDeclBitWidth()`  (repeated).
> > > 
> > > If the concern about returning `-2` from `clang_getFieldDeclBitWidth()` 
> > > is cryptic return codes, an `enum` with named constants can be introduced.
> > > 
> > > If the concern is breaking backward compatibility for users that relied 
> > > on the returned value being positive or `-1`, then a replacement for 
> > > `clang_getFieldDeclBitWidth()` with the most convenient API should be 
> > > introduced and `clang_getFieldDeclBitWidth()` itself - deprecated.
> > > 
> > > KDevelop simply stores the value returned by 
> > > `clang_getFieldDeclBitWidth()` in an `int16_t m_bitWidth` data member and 
> > > uses it later. So if `-2` is returned, the only place in code to adjust 
> > > would be the use of this data member. With the current 
> > > `clang_isFieldDeclBitWidthDependent()` implementation, this function 
> > > would have to be called, `-2` explicitly stored in `m_bitWidth` and the 
> > > use of `m_bitWidth` would have to be adjusted just the same.
> > > 
> > > Have you considered potential usage of the added API in your project? 
> > > Which alternative would be more convenient to use?
> > One more API alternative is to replace 
> > `clang_isFieldDeclBitWidthDependent()` with `clang_isBitFieldDecl()`. The 
> > usage would be more straightforward and efficient: first call 
> > `clang_isBitFieldDecl()`; if it returns true (should be rare enough), call 
> > `clang_getFieldDeclBitWidth()`; if that returns `-1`, then the bit-field 
> > width must be unknown (dependent on template parameters). Such usage would 
> > still be less convenient and efficient compared to 
> > `clang_getFieldDeclBitWidth()` returning `-2` though.
> Implemented as `clang_isBitFieldDecl` rather than magic return value
Thanks. That's good enough for me.



Comment at: clang/tools/libclang/CXType.cpp:13
 
+#include "CXType.h"
 #include "CIndexer.h"

collinbaker wrote:
> vedgy wrote:
> > I guess //clang-format// did this include reordering. But it certainly 
> > looks out of place and the include order becomes wrong. So I think it 
> > should be reverted.
> I don't agree, it's pretty standard for a source file to have its associated 
> header include at the top.
You are right, I haven't realized the header-source association. The diff is 
still unrelated to the patch. But I'm no longer sure what's right, so won't 
insist on anything.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130303

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

[PATCH] D145579: [Flang][AMDGPU][OpenMP] Save target features in OpenMP MLIR dialect

[Dominik Adamski via Phabricator via cfe-commits]

domada updated this revision to Diff 503672.
domada added a comment.

Fixed formatting


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

https://reviews.llvm.org/D145579

Files:
  clang/lib/Basic/Targets/AMDGPU.cpp
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/lib/Driver/ToolChains/Flang.cpp
  flang/include/flang/Frontend/FrontendActions.h
  flang/lib/Frontend/FrontendActions.cpp
  flang/test/Driver/target-cpu-features.f90
  flang/test/Lower/OpenMP/target_cpu_features.f90
  llvm/include/llvm/TargetParser/TargetParser.h
  llvm/lib/TargetParser/TargetParser.cpp
  mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
  mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp

Index: mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
===
--- mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
+++ mlir/lib/Dialect/OpenMP/IR/OpenMPDialect.cpp
@@ -1437,6 +1437,39 @@
   return false;
 }
 
+// Set the omp.target_cpu attribute on the module with the specified string
+void OpenMPDialect::setTargetCpu(Operation *module, llvm::StringRef cpu) {
+  module->setAttr(mlir::StringAttr::get(module->getContext(),
+llvm::Twine{"omp.target_cpu"}),
+  mlir::StringAttr::get(module->getContext(), cpu));
+}
+
+// Return the value of the omp.target_cpu attribute stored in the module if it
+// exists, otherwise return empty by default
+std::string OpenMPDialect::getTargetCpu(Operation *module) {
+  if (Attribute targetCpu = module->getAttr("omp.target_cpu"))
+if (targetCpu.isa())
+  return targetCpu.dyn_cast().getValue().str();
+  return llvm::Twine{""}.str();
+}
+
+// Set the omp.target_cpu_features attribute on the module with
+// the specified string
+void OpenMPDialect::setTargetCpuFeatures(Operation *module,
+ llvm::StringRef cpuFeatures) {
+  module->setAttr(mlir::StringAttr::get(module->getContext(),
+llvm::Twine{"omp.target_cpu_features"}),
+  mlir::StringAttr::get(module->getContext(), cpuFeatures));
+}
+
+// Return the value of the omp.target_cpu_features attribute stored in the
+// module if it exists, otherwise return empty by default
+std::string OpenMPDialect::getTargetCpuFeatures(Operation *module) {
+  if (Attribute targetCpu = module->getAttr("omp.target_cpu_features"))
+if (targetCpu.isa())
+  return targetCpu.dyn_cast().getValue().str();
+  return llvm::Twine{""}.str();
+}
 #define GET_ATTRDEF_CLASSES
 #include "mlir/Dialect/OpenMP/OpenMPOpsAttributes.cpp.inc"
 
Index: mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
===
--- mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
+++ mlir/include/mlir/Dialect/OpenMP/OpenMPOps.td
@@ -36,6 +36,21 @@
 // Return the value of the omp.is_device attribute stored in the module if it
 // exists, otherwise return false by default
 static bool getIsDevice(Operation* module);
+
+// Set the omp.target_cpu attribute on the module with the specified string
+static void setTargetCpu(Operation* module, StringRef cpu);
+
+// Return the value of the omp.target_cpu attribute stored in the module if it
+// exists, otherwise return empty by default
+static std::string getTargetCpu(Operation* module);
+
+// Set the omp.target_cpu_features attribute on the module with
+// the specified string
+static void setTargetCpuFeatures(Operation* module, StringRef cpuFeatures);
+
+// Return the value of the omp.target_cpu_features attribute stored in
+// the module if it exists, otherwise return empty by default
+static std::string getTargetCpuFeatures(Operation* module);
   }];
 }
 
Index: llvm/lib/TargetParser/TargetParser.cpp
===
--- llvm/lib/TargetParser/TargetParser.cpp
+++ llvm/lib/TargetParser/TargetParser.cpp
@@ -251,3 +251,212 @@
 
   return T.isAMDGCN() ? getArchNameAMDGCN(ProcKind) : getArchNameR600(ProcKind);
 }
+
+void AMDGPU::fillAMDGPUFeatureMap(StringRef GPU, const Triple &T,
+  StringMap &Features) {
+  // XXX - What does the member GPU mean if device name string passed here?
+  if (T.isAMDGCN()) {
+switch (parseArchAMDGCN(GPU)) {
+case GK_GFX1103:
+case GK_GFX1102:
+case GK_GFX1101:
+case GK_GFX1100:
+  Features["ci-insts"] = true;
+  Features["dot5-insts"] = true;
+  Features["dot7-insts"] = true;
+  Features["dot8-insts"] = true;
+  Features["dot9-insts"] = true;
+  Features["dot10-insts"] = true;
+  Features["dl-insts"] = true;
+  Features["16-bit-insts"] = true;
+  Features["dpp"] = true;
+  Features["gfx8-insts"] = true;
+  Features["gfx9-insts"] = true;
+  Features["gfx10-insts"] = true;
+  Features["gfx10-3-insts"] = true;
+  Features["gfx11-insts"] = true;
+  break;
+case

[PATCH] D145671: [clang] Remove legacy -m(no)-code-object-v3 options

[Pierre van Houtryve via Phabricator via cfe-commits]

Pierre-vh created this revision.
Pierre-vh added reviewers: arsenm, foad, kzhuravl, rampitec.
Herald added subscribers: kosarev, StephenFan, kerbowa, jvesely.
Herald added a project: All.
Pierre-vh requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay, wdng.
Herald added a project: clang.

Code object V2 and V3 have been deprecated for a long time.
They're now scheduled to be removed completely from LLVM in the coming 
weeks/months.

There is no reason to support those legacy options anymore as they've
also been deprecated for a long time.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D145671

Files:
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/CommonArgs.cpp
  clang/test/Driver/amdgpu-features-as.s
  clang/test/Driver/amdgpu-features.c
  clang/test/Driver/hip-code-object-version.hip

Index: clang/test/Driver/hip-code-object-version.hip
===
--- clang/test/Driver/hip-code-object-version.hip
+++ clang/test/Driver/hip-code-object-version.hip
@@ -2,27 +2,16 @@
 
 // Check bundle ID for code object v2.
 
-// RUN: %clang -### --target=x86_64-linux-gnu \
-// RUN:   -mno-code-object-v3 \
-// RUN:   --offload-arch=gfx906 -nogpulib \
-// RUN:   %s 2>&1 | FileCheck -check-prefixes=V2,V2-WARN %s
-
 // RUN: %clang -### --target=x86_64-linux-gnu \
 // RUN:   -mcode-object-version=2 \
 // RUN:   --offload-arch=gfx906 -nogpulib \
 // RUN:   %s 2>&1 | FileCheck -check-prefix=V2 %s
 
-// V2-WARN: warning: argument '-mno-code-object-v3' is deprecated, use '-mcode-object-version=2' instead [-Wdeprecated]
 // V2: "-mllvm" "--amdhsa-code-object-version=2"
 // V2: "-targets=host-x86_64-unknown-linux,hip-amdgcn-amd-amdhsa--gfx906"
 
 // Check bundle ID for code object v3.
 
-// RUN: %clang -### --target=x86_64-linux-gnu \
-// RUN:   -mcode-object-v3 \
-// RUN:   --offload-arch=gfx906 -nogpulib \
-// RUN:   %s 2>&1 | FileCheck -check-prefixes=V3,V3-WARN %s
-
 // RUN: %clang -### --target=x86_64-linux-gnu \
 // RUN:   -mcode-object-version=3 \
 // RUN:   --offload-arch=gfx906 -nogpulib \
@@ -33,7 +22,6 @@
 // RUN:   --offload-arch=gfx906 -nogpulib \
 // RUN:   %s 2>&1 | FileCheck -check-prefix=V3 %s
 
-// V3-WARN: warning: argument '-mcode-object-v3' is deprecated, use '-mcode-object-version=3' instead [-Wdeprecated]
 // V3: "-mcode-object-version=3"
 // V3: "-mllvm" "--amdhsa-code-object-version=3"
 // V3: "-targets=host-x86_64-unknown-linux,hip-amdgcn-amd-amdhsa--gfx906"
@@ -95,14 +83,3 @@
 // RUN:   %s 2>&1 | FileCheck -check-prefix=CC1NEG %s
 
 // CC1NEG-NOT: "-cc1as" {{.*}}"-mcode-object-version=5"
-
-// Check warnings are emitted for legacy options before -mcode-object-version options.
-// Check warnings are emitted only once.
-
-// RUN: %clang -### --target=x86_64-linux-gnu \
-// RUN:   -mno-code-object-v3 -mcode-object-v3 -mcode-object-version=4 \
-// RUN:   --offload-arch=gfx906 -nogpulib \
-// RUN:   %s 2>&1 | FileCheck -check-prefixes=WARN %s
-// WARN: warning: argument '-mno-code-object-v3' is deprecated, use '-mcode-object-version=2' instead [-Wdeprecated]
-// WARN: warning: argument '-mcode-object-v3' is deprecated, use '-mcode-object-version=3' instead [-Wdeprecated]
-// WARN-NOT: warning: argument {{.*}} is deprecated
Index: clang/test/Driver/amdgpu-features.c
===
--- clang/test/Driver/amdgpu-features.c
+++ clang/test/Driver/amdgpu-features.c
@@ -1,15 +1,3 @@
-// RUN: %clang -### -target amdgcn-amd-amdhsa -mcpu=gfx700 -mcode-object-v3 %s 2>&1 | FileCheck --check-prefix=CODE-OBJECT-V3 %s
-// CODE-OBJECT-V3: warning: argument '-mcode-object-v3' is deprecated, use '-mcode-object-version=3' instead [-Wdeprecated]
-// CODE-OBJECT-V3: "-mllvm" "--amdhsa-code-object-version=3"
-
-// RUN: %clang -### -target amdgcn-amd-amdhsa amdgcn -mcpu=gfx700 -mno-code-object-v3 %s 2>&1 | FileCheck --check-prefix=NO-CODE-OBJECT-V3 %s
-// NO-CODE-OBJECT-V3: warning: argument '-mno-code-object-v3' is deprecated, use '-mcode-object-version=2' instead [-Wdeprecated]
-// NO-CODE-OBJECT-V3: "-mllvm" "--amdhsa-code-object-version=2"
-
-// RUN: %clang -### -target amdgcn-amd-amdhsa -mcpu=gfx700 -mcode-object-v3 -mno-code-object-v3 -mcode-object-v3 %s 2>&1 | FileCheck --check-prefix=MUL-CODE-OBJECT-V3 %s
-// MUL-CODE-OBJECT-V3: warning: argument '-mcode-object-v3' is deprecated, use '-mcode-object-version=3' instead [-Wdeprecated]
-// MUL-CODE-OBJECT-V3: "-mllvm" "--amdhsa-code-object-version=3"
-
 // RUN: %clang -### -target amdgcn-amdhsa -mcpu=gfx900:xnack+ %s 2>&1 | FileCheck --check-prefix=XNACK %s
 // XNACK: "-target-feature" "+xnack"
 
Index: clang/test/Driver/amdgpu-features-as.s
===
--- clang/test/Driver/amdgpu-features-as.s
+++ /dev/null
@@ -1,11 +0,0 @@
-// RUN: %clang -### -target amdgcn-amd-amdhsa -mcpu=gfx900 -mcode-object-v3 %s 2>&1 | FileCheck --check-prefix=CODE-OBJECT-V

[PATCH] D145519: [SanitizerBinaryMetadata] Do not add to GPU code

[Marco Elver via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rG61ed64954b97: [SanitizerBinaryMetadata] Do not add to GPU 
code (authored by melver).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145519

Files:
  clang/lib/Driver/SanitizerArgs.cpp
  llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp


Index: llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
===
--- llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
+++ llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
@@ -131,6 +131,8 @@
 IRB(M.getContext()) {
 // FIXME: Make it work with other formats.
 assert(TargetTriple.isOSBinFormatELF() && "ELF only");
+assert(!(TargetTriple.isNVPTX() || TargetTriple.isAMDGPU()) &&
+   "Device targets are not supported");
   }
 
   bool run();
Index: clang/lib/Driver/SanitizerArgs.cpp
===
--- clang/lib/Driver/SanitizerArgs.cpp
+++ clang/lib/Driver/SanitizerArgs.cpp
@@ -1100,13 +1100,16 @@
   // NVPTX doesn't currently support sanitizers.  Bailing out here means
   // that e.g. -fsanitize=address applies only to host code, which is what we
   // want for now.
-  //
-  // AMDGPU sanitizer support is experimental and controlled by -fgpu-sanitize.
-  if (TC.getTriple().isNVPTX() ||
-  (TC.getTriple().isAMDGPU() &&
-   !Args.hasFlag(options::OPT_fgpu_sanitize, options::OPT_fno_gpu_sanitize,
- true)))
+  if (TC.getTriple().isNVPTX())
 return;
+  // AMDGPU sanitizer support is experimental and controlled by -fgpu-sanitize.
+  bool GPUSanitize = false;
+  if (TC.getTriple().isAMDGPU()) {
+if (!Args.hasFlag(options::OPT_fgpu_sanitize, 
options::OPT_fno_gpu_sanitize,
+  true))
+  return;
+GPUSanitize = true;
+  }
 
   // Translate available CoverageFeatures to corresponding clang-cc1 flags.
   // Do it even if Sanitizers.empty() since some forms of coverage don't 
require
@@ -1143,20 +1146,22 @@
   addSpecialCaseListOpt(Args, CmdArgs, "-fsanitize-coverage-ignorelist=",
 CoverageIgnorelistFiles);
 
-  // Translate available BinaryMetadataFeatures to corresponding clang-cc1
-  // flags. Does not depend on any other sanitizers.
-  const std::pair BinaryMetadataFlags[] = {
-  std::make_pair(BinaryMetadataCovered, "covered"),
-  std::make_pair(BinaryMetadataAtomics, "atomics"),
-  std::make_pair(BinaryMetadataUAR, "uar")};
-  for (const auto &F : BinaryMetadataFlags) {
-if (BinaryMetadataFeatures & F.first)
-  CmdArgs.push_back(
-  Args.MakeArgString("-fexperimental-sanitize-metadata=" + F.second));
+  if (!GPUSanitize) {
+// Translate available BinaryMetadataFeatures to corresponding clang-cc1
+// flags. Does not depend on any other sanitizers. Unsupported on GPUs.
+const std::pair BinaryMetadataFlags[] = {
+std::make_pair(BinaryMetadataCovered, "covered"),
+std::make_pair(BinaryMetadataAtomics, "atomics"),
+std::make_pair(BinaryMetadataUAR, "uar")};
+for (const auto &F : BinaryMetadataFlags) {
+  if (BinaryMetadataFeatures & F.first)
+CmdArgs.push_back(
+Args.MakeArgString("-fexperimental-sanitize-metadata=" + 
F.second));
+}
+addSpecialCaseListOpt(Args, CmdArgs,
+  "-fexperimental-sanitize-metadata-ignorelist=",
+  BinaryMetadataIgnorelistFiles);
   }
-  addSpecialCaseListOpt(Args, CmdArgs,
-"-fexperimental-sanitize-metadata-ignorelist=",
-BinaryMetadataIgnorelistFiles);
 
   if (TC.getTriple().isOSWindows() && needsUbsanRt()) {
 // Instruct the code generator to embed linker directives in the object 
file


Index: llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
===
--- llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
+++ llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
@@ -131,6 +131,8 @@
 IRB(M.getContext()) {
 // FIXME: Make it work with other formats.
 assert(TargetTriple.isOSBinFormatELF() && "ELF only");
+assert(!(TargetTriple.isNVPTX() || TargetTriple.isAMDGPU()) &&
+   "Device targets are not supported");
   }
 
   bool run();
Index: clang/lib/Driver/SanitizerArgs.cpp
===
--- clang/lib/Driver/SanitizerArgs.cpp
+++ clang/lib/Driver/SanitizerArgs.cpp
@@ -1100,13 +1100,16 @@
   // NVPTX doesn't currently support sanitizers.  Bailing out here means
   // that e.g. -fsanitize=address applies only to host code, which is what we
   // want for no

[clang] 61ed649 - [SanitizerBinaryMetadata] Do not add to GPU code

[Marco Elver via cfe-commits]

Author: Marco Elver
Date: 2023-03-09T10:15:28+01:00
New Revision: 61ed64954b979df0d5bfdfbe54a7c27e20be9001

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

LOG: [SanitizerBinaryMetadata] Do not add to GPU code

SanitizerBinaryMetadata should only apply to to host code, and not GPU
code. Recently AMD GPU target code has experimental sanitizer support.

If we're compiling a mixed host/device source file, only add sanitizer
metadata to host code.

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

Added: 


Modified: 
clang/lib/Driver/SanitizerArgs.cpp
llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp

Removed: 




diff  --git a/clang/lib/Driver/SanitizerArgs.cpp 
b/clang/lib/Driver/SanitizerArgs.cpp
index 390faef0dbdf1..299d4adfa 100644
--- a/clang/lib/Driver/SanitizerArgs.cpp
+++ b/clang/lib/Driver/SanitizerArgs.cpp
@@ -1100,13 +1100,16 @@ void SanitizerArgs::addArgs(const ToolChain &TC, const 
llvm::opt::ArgList &Args,
   // NVPTX doesn't currently support sanitizers.  Bailing out here means
   // that e.g. -fsanitize=address applies only to host code, which is what we
   // want for now.
-  //
-  // AMDGPU sanitizer support is experimental and controlled by -fgpu-sanitize.
-  if (TC.getTriple().isNVPTX() ||
-  (TC.getTriple().isAMDGPU() &&
-   !Args.hasFlag(options::OPT_fgpu_sanitize, options::OPT_fno_gpu_sanitize,
- true)))
+  if (TC.getTriple().isNVPTX())
 return;
+  // AMDGPU sanitizer support is experimental and controlled by -fgpu-sanitize.
+  bool GPUSanitize = false;
+  if (TC.getTriple().isAMDGPU()) {
+if (!Args.hasFlag(options::OPT_fgpu_sanitize, 
options::OPT_fno_gpu_sanitize,
+  true))
+  return;
+GPUSanitize = true;
+  }
 
   // Translate available CoverageFeatures to corresponding clang-cc1 flags.
   // Do it even if Sanitizers.empty() since some forms of coverage don't 
require
@@ -1143,20 +1146,22 @@ void SanitizerArgs::addArgs(const ToolChain &TC, const 
llvm::opt::ArgList &Args,
   addSpecialCaseListOpt(Args, CmdArgs, "-fsanitize-coverage-ignorelist=",
 CoverageIgnorelistFiles);
 
-  // Translate available BinaryMetadataFeatures to corresponding clang-cc1
-  // flags. Does not depend on any other sanitizers.
-  const std::pair BinaryMetadataFlags[] = {
-  std::make_pair(BinaryMetadataCovered, "covered"),
-  std::make_pair(BinaryMetadataAtomics, "atomics"),
-  std::make_pair(BinaryMetadataUAR, "uar")};
-  for (const auto &F : BinaryMetadataFlags) {
-if (BinaryMetadataFeatures & F.first)
-  CmdArgs.push_back(
-  Args.MakeArgString("-fexperimental-sanitize-metadata=" + F.second));
+  if (!GPUSanitize) {
+// Translate available BinaryMetadataFeatures to corresponding clang-cc1
+// flags. Does not depend on any other sanitizers. Unsupported on GPUs.
+const std::pair BinaryMetadataFlags[] = {
+std::make_pair(BinaryMetadataCovered, "covered"),
+std::make_pair(BinaryMetadataAtomics, "atomics"),
+std::make_pair(BinaryMetadataUAR, "uar")};
+for (const auto &F : BinaryMetadataFlags) {
+  if (BinaryMetadataFeatures & F.first)
+CmdArgs.push_back(
+Args.MakeArgString("-fexperimental-sanitize-metadata=" + 
F.second));
+}
+addSpecialCaseListOpt(Args, CmdArgs,
+  "-fexperimental-sanitize-metadata-ignorelist=",
+  BinaryMetadataIgnorelistFiles);
   }
-  addSpecialCaseListOpt(Args, CmdArgs,
-"-fexperimental-sanitize-metadata-ignorelist=",
-BinaryMetadataIgnorelistFiles);
 
   if (TC.getTriple().isOSWindows() && needsUbsanRt()) {
 // Instruct the code generator to embed linker directives in the object 
file

diff  --git a/llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp 
b/llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
index 563d3e4039a9b..a1309a4ec0f45 100644
--- a/llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
+++ b/llvm/lib/Transforms/Instrumentation/SanitizerBinaryMetadata.cpp
@@ -131,6 +131,8 @@ class SanitizerBinaryMetadata {
 IRB(M.getContext()) {
 // FIXME: Make it work with other formats.
 assert(TargetTriple.isOSBinFormatELF() && "ELF only");
+assert(!(TargetTriple.isNVPTX() || TargetTriple.isAMDGPU()) &&
+   "Device targets are not supported");
   }
 
   bool run();



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

[PATCH] D143467: [PowerPC] Add target feature requirement to builtins

[ChenZheng via Phabricator via cfe-commits]

shchenz added a comment.

I think this is a good direction. For example we can avoid the crash in 
https://github.com/llvm/llvm-project/issues/60959 and give a clear diagnostic 
message.

However, manually adding the required target feature seems a little mistakable, 
like the one below. I guess we can not get the required feature in the LLVM 
instruction TDs(if the builtin is mapped to a IR intrinsic and the intrinsic is 
selected inside the instruction TD) because this is done in CLANG? 
Really need to way to make sure that the instruction are marked with the 
accurate target feature, if not possible to do this inside the compiler, an 
offline script maybe? Checking the instruction one by one is a little 
time-consuming.




Comment at: clang/include/clang/Basic/BuiltinsPPC.def:491
+TARGET_BUILTIN(__builtin_altivec_vabsduh, "V8UsV8UsV8Us", "", "altivec")
+TARGET_BUILTIN(__builtin_altivec_vabsduw, "V4UiV4UiV4Ui", "", "altivec")
 

These builtins `vabsdub`, `vabsduh`, `vabsduw`  should require ISA3.0 which is 
not altivec or vsx. Do we have a reasonable feature for Power9 instructions, 
`power9-vector` maybe?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143467

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

[PATCH] D143467: [PowerPC] Add target feature requirement to builtins

[Qiu Chaofan via Phabricator via cfe-commits]

qiucf added a comment.

> However, manually adding the required target feature seems a little 
> mistakable, like the one below. I guess we can not get the required feature 
> in the LLVM instruction TDs(if the builtin is mapped to a IR intrinsic and 
> the intrinsic is selected inside the instruction TD) because this is done in 
> CLANG?

Yes, this is how clang builtin definitions work. They are independent from LLVM 
definitions in tablegen files.

> Really need to way to make sure that the instruction are marked with the 
> accurate target feature, if not possible to do this inside the compiler, an 
> offline script maybe? Checking the instruction one by one is a little 
> time-consuming.

I actually don't think we need extra script to maintain this. They're rather 
static (not willing to change after written), independent (one changed won't 
affect another) and human-readable.




Comment at: clang/include/clang/Basic/BuiltinsPPC.def:491
+TARGET_BUILTIN(__builtin_altivec_vabsduh, "V8UsV8UsV8Us", "", "altivec")
+TARGET_BUILTIN(__builtin_altivec_vabsduw, "V4UiV4UiV4Ui", "", "altivec")
 

shchenz wrote:
> These builtins `vabsdub`, `vabsduh`, `vabsduw`  should require ISA3.0 which 
> is not altivec or vsx. Do we have a reasonable feature for Power9 
> instructions, `power9-vector` maybe?
Thanks. I'll update then. `power9-vector` is good option. But I'm curious 
what's the different pratical usages from `power9-vector` and 
`isa-v30-instructions`. Maybe cc @nemanjai 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143467

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

[clang] db987b9 - [Modules] Remove unnecessary check when generating name lookup table in ASTWriter

[Chuanqi Xu via cfe-commits]

Author: Chuanqi Xu
Date: 2023-03-09T17:29:36+08:00
New Revision: db987b9589be1eb604fcb74c85b410469e31485f

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

LOG: [Modules] Remove unnecessary check when generating name lookup table in 
ASTWriter

Close https://github.com/llvm/llvm-project/issues/61065.

We will avoid writing the names from external AST naturally. But
currently its check is often false positive since we may have already
marked the declarations as external but
DeclContext::hasNeedToReconcileExternalVisibleStorage would be false
after reconciling.

Tested with libcxx's modular build.

This patch can improve 8% compilation time in an internal workloads.

Added: 
clang/test/Modules/pr61065.cppm

Modified: 
clang/include/clang/Serialization/ASTWriter.h
clang/lib/Serialization/ASTWriter.cpp

Removed: 




diff  --git a/clang/include/clang/Serialization/ASTWriter.h 
b/clang/include/clang/Serialization/ASTWriter.h
index 09ee1744e8945..d31fa38b93825 100644
--- a/clang/include/clang/Serialization/ASTWriter.h
+++ b/clang/include/clang/Serialization/ASTWriter.h
@@ -514,7 +514,6 @@ class ASTWriter : public ASTDeserializationListener,
   void WriteTypeAbbrevs();
   void WriteType(QualType T);
 
-  bool isLookupResultExternal(StoredDeclsList &Result, DeclContext *DC);
   bool isLookupResultEntirelyExternal(StoredDeclsList &Result, DeclContext 
*DC);
 
   void GenerateNameLookupTable(const DeclContext *DC,

diff  --git a/clang/lib/Serialization/ASTWriter.cpp 
b/clang/lib/Serialization/ASTWriter.cpp
index c1afdeb6007db..5f8f5d38932a5 100644
--- a/clang/lib/Serialization/ASTWriter.cpp
+++ b/clang/lib/Serialization/ASTWriter.cpp
@@ -3849,12 +3849,6 @@ class ASTDeclContextNameLookupTrait {
 
 } // namespace
 
-bool ASTWriter::isLookupResultExternal(StoredDeclsList &Result,
-   DeclContext *DC) {
-  return Result.hasExternalDecls() &&
- DC->hasNeedToReconcileExternalVisibleStorage();
-}
-
 bool ASTWriter::isLookupResultEntirelyExternal(StoredDeclsList &Result,
DeclContext *DC) {
   for (auto *D : Result.getLookupResult())
@@ -3897,8 +3891,7 @@ ASTWriter::GenerateNameLookupTable(const DeclContext 
*ConstDC,
 // don't need to write an entry for the name at all. If we can't
 // write out a lookup set without performing more deserialization,
 // just skip this entry.
-if (isLookupResultExternal(Result, DC) &&
-isLookupResultEntirelyExternal(Result, DC))
+if (isLookupResultEntirelyExternal(Result, DC))
   continue;
 
 // We also skip empty results. If any of the results could be external and

diff  --git a/clang/test/Modules/pr61065.cppm b/clang/test/Modules/pr61065.cppm
new file mode 100644
index 0..44fa3679974ad
--- /dev/null
+++ b/clang/test/Modules/pr61065.cppm
@@ -0,0 +1,55 @@
+// From https://github.com/llvm/llvm-project/issues/61065
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+//
+// RUN: %clang_cc1 -std=c++20 %t/a.cppm -emit-module-interface -o %t/a.pcm
+// RUN: %clang_cc1 -std=c++20 %t/b.cppm -emit-module-interface -o %t/b.pcm \
+// RUN: -fprebuilt-module-path=%t
+// RUN: %clang_cc1 -std=c++20 %t/c.cppm -emit-module-interface -o %t/c.pcm \
+// RUN: -fprebuilt-module-path=%t
+// RUN: %clang_cc1 -std=c++20 %t/d.cpp -fsyntax-only -verify 
-fprebuilt-module-path=%t
+
+//--- a.cppm
+export module a;
+
+struct base {
+   base(int) {}
+};
+
+export struct a : base {
+   using base::base;
+};
+
+//--- b.cppm
+export module b;
+
+import a;
+
+a b() {
+   return a(1);
+}
+
+//--- c.cppm
+export module c;
+
+import a;
+import b;
+
+struct noncopyable {
+   noncopyable(noncopyable const &) = delete;
+noncopyable() = default;
+};
+
+export struct c {
+   noncopyable c0;
+   a c1 = 43;
+c() = default;
+};
+
+//--- d.cpp
+// expected-no-diagnostics
+import c;
+void d() {
+c _;
+}



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

[PATCH] D145639: [Coroutines] Fix premature conversion of return object

[Chuanqi Xu via Phabricator via cfe-commits]

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

This is basically a reverting of https://reviews.llvm.org/D117087. So it should 
be good according to our previous talk.




Comment at: clang/include/clang/AST/StmtCXX.h:410-414
   Expr *getReturnValue() const {
 assert(getReturnStmt());
 auto *RS = cast(getReturnStmt());
 return RS->getRetValue();
   }

Maybe we can delete this.



Comment at: clang/lib/Sema/SemaCoroutine.cpp:1752
 
-  StmtResult ReturnStmt = S.BuildReturnStmt(Loc, ReturnValue);
+  // StmtResult ReturnStmt = S.BuildReturnStmt(Loc, ReturnValue);
+  auto *GroDecl = VarDecl::Create(

Let's remove this one.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145639

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

[PATCH] D143751: [clang][analyzer][NFC] Refactor code of StdLibraryFunctionsChecker.

[Kristóf Umann via Phabricator via cfe-commits]

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

LGTM


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143751

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

[PATCH] D144878: __builtin_FILE_NAME()

[Ilya Karapsin via Phabricator via cfe-commits]

karapsinie updated this revision to Diff 503696.
karapsinie added a comment.

Removed the spurious whitespace changes.


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

https://reviews.llvm.org/D144878

Files:
  clang/include/clang/AST/Expr.h
  clang/include/clang/Basic/TokenKinds.def
  clang/include/clang/Lex/Preprocessor.h
  clang/lib/AST/Expr.cpp
  clang/lib/Lex/PPMacroExpansion.cpp
  clang/lib/Parse/ParseExpr.cpp
  clang/lib/Sema/SemaExpr.cpp
  clang/test/Preprocessor/feature_tests.c
  clang/test/Preprocessor/feature_tests.cpp
  clang/test/Sema/source_location.c
  clang/test/SemaCXX/Inputs/source-location-file.h
  clang/test/SemaCXX/source_location.cpp
  clang/unittests/AST/ASTImporterTest.cpp

Index: clang/unittests/AST/ASTImporterTest.cpp
===
--- clang/unittests/AST/ASTImporterTest.cpp
+++ clang/unittests/AST/ASTImporterTest.cpp
@@ -259,6 +259,10 @@
  Lang_CXX03, Verifier,
  functionDecl(hasDescendant(
  sourceLocExpr(hasBuiltinStr("__builtin_FILE");
+  testImport("void declToImport() { (void)__builtin_FILE_NAME(); }", Lang_CXX03,
+ "", Lang_CXX03, Verifier,
+ functionDecl(hasDescendant(
+ sourceLocExpr(hasBuiltinStr("__builtin_FILE_NAME");
   testImport("void declToImport() { (void)__builtin_COLUMN(); }", Lang_CXX03,
  "", Lang_CXX03, Verifier,
  functionDecl(hasDescendant(
Index: clang/test/SemaCXX/source_location.cpp
===
--- clang/test/SemaCXX/source_location.cpp
+++ clang/test/SemaCXX/source_location.cpp
@@ -84,6 +84,7 @@
 static_assert(is_same);
 static_assert(is_same);
 static_assert(is_same);
+static_assert(is_same);
 static_assert(is_same);
 static_assert(is_same);
 
@@ -91,6 +92,7 @@
 static_assert(noexcept(__builtin_LINE()));
 static_assert(noexcept(__builtin_COLUMN()));
 static_assert(noexcept(__builtin_FILE()));
+static_assert(noexcept(__builtin_FILE_NAME()));
 static_assert(noexcept(__builtin_FUNCTION()));
 static_assert(noexcept(__builtin_source_location()));
 
@@ -346,6 +348,54 @@
 
 } // namespace test_file
 
+//===--===//
+//__builtin_FILE_NAME()
+//===--===//
+
+namespace test_file_name {
+constexpr const char *test_file_name_simple(
+  const char *__f = __builtin_FILE_NAME()) {
+  return __f;
+}
+void test_function() {
+#line 900
+  static_assert(is_equal(test_file_name_simple(), __FILE_NAME__));
+  static_assert(is_equal(SLF::test_function_filename(), __FILE_NAME__), "");
+  static_assert(is_equal(SLF::test_function_filename_template(42),
+ __FILE_NAME__), "");
+
+  static_assert(is_equal(SLF::test_function_filename_indirect(),
+ SLF::global_info_filename), "");
+  static_assert(is_equal(SLF::test_function_filename_template_indirect(42),
+ SLF::global_info_filename), "");
+
+  static_assert(test_file_name_simple() != nullptr);
+  static_assert(is_equal(test_file_name_simple(), "source_location.cpp"));
+}
+
+void test_class() {
+#line 315
+  using SLF::TestClass;
+  constexpr TestClass Default;
+  constexpr TestClass InParam{42};
+  constexpr TestClass Template{42, 42};
+  constexpr auto *F = Default.info_file_name;
+  constexpr auto Char = F[0];
+  static_assert(is_equal(Default.info_file_name, SLF::FILE_NAME), "");
+  static_assert(is_equal(InParam.info_file_name, SLF::FILE_NAME), "");
+  static_assert(is_equal(InParam.ctor_info_file_name, __FILE_NAME__), "");
+}
+
+void test_aggr_class() {
+  using Agg = SLF::AggrClass<>;
+  constexpr Agg Default{};
+  constexpr Agg InitOne{42};
+  static_assert(is_equal(Default.init_info_file_name, __FILE_NAME__), "");
+  static_assert(is_equal(InitOne.init_info_file_name, __FILE_NAME__), "");
+}
+
+} // namespace test_file_name
+
 //===--===//
 //__builtin_FUNCTION()
 //===--===//
@@ -487,6 +537,7 @@
 #line 44 "test_file.c"
 static_assert(is_equal("test_file.c", __FILE__));
 static_assert(is_equal("test_file.c", __builtin_FILE()));
+static_assert(is_equal("test_file.c", __builtin_FILE_NAME()));
 static_assert(is_equal("test_file.c", SL::current().file()));
 static_assert(is_equal("test_file.c", SLF::test_function().file()));
 static_assert(is_equal(SLF::FILE, SLF::test_function_indirect().file()));
Index: clang/test/SemaCXX/Inputs/source-location-file.h
===
--- clang/test/SemaCXX/Inputs/source-location-file.h
+++ clang/test/SemaCXX/Inputs/source-location-file.h
@@ -4,8 +4,10 @@
 namespace source_location_file {
 
 constexpr const char

[PATCH] D145641: [Coroutines] Implement fix for cwg2563 issue and enable RVO under certain conditions

[Chuanqi Xu via Phabricator via cfe-commits]

ChuanqiXu added inline comments.



Comment at: clang/lib/CodeGen/CGCoroutine.cpp:475
   const CoroutineBodyStmt &S;
+  bool DirectEmit = false;
 

nit. Rewords it if you like.



Comment at: clang/lib/CodeGen/CGCoroutine.cpp:483-499
+// The call to get_­return_­object is sequenced before the call to
+// initial_­suspend and is invoked at most once, but there are caveats
+// regarding on whether the prvalue result object may be initialized
+// directly/eager or delayed, depending on the types involved.
+//
+// The general cases:
+// 1. Same type of get_return_object and coroutine return type (direct

I'll feel better if we can attach the conclusion and links from the wg21.



Comment at: clang/lib/CodeGen/CGCoroutine.cpp:500-508
+DirectEmit = [&]() {
+  auto *RVI = S.getReturnValueInit();
+  if (!RVI || CGF.FnRetTy->isVoidType())
+return true;
+  auto GroType = RVI->getType();
+  if (GroType->isVoidType())
+return true;

What's the case about returning void and the return_object type is different 
from the returning type?



Comment at: clang/lib/Sema/SemaCoroutine.cpp:1733
 
+  bool GroMatchesRetType = GroType == FnRetType;
+

Let's have some comments here.



Comment at: clang/test/SemaCXX/coroutine-no-move-ctor.cpp:24-26
 invoker f() {
   co_return;
 }

How about adding a failing case that the types are not matched?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145641

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

[PATCH] D145591: [clang][HIP][OpenMP] Add warning if mixed HIP / OpenMP offloading

[Michael Halkenhäuser via Phabricator via cfe-commits]

mhalk added a comment.

In D145591#4179144 , @tra wrote:

> How is this different from compiling a C++ file with opemnp directives in it? 
> AFAICT neither clang nor gcc issue anywarnings: 
> https://godbolt.org/z/5Me3dnTdr
>
> What makes the warnings necessary for HIP?

When using HIP target offloading it will "take precedence" over OpenMP target 
offloading.
That is, there is a use case which compiles "successfully" / without warning 
but will not execute code within OpenMP target directives.

For example: when using `-x hip -fopenmp --offload-arch=...` (+ other 
reasonable parameters) a HIP program with OpenMP target directives will compile 
without warning / error.
But only host-related OpenMP code will be executed properly.

Another hint that HIP and OpenMP target offloading do not work concurrently ATM 
is that when compiling with `-x hip --fopenmp-targets=...` clang will throw an 
error.

Hence, we want to signal this issue to users, whorun into problems and then 
have to debug their programs to find out about this.
AFAIK this issue can be alleviated by refactoring / splitting up your code, 
then linking it back togehter -- but you have to know about this.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145591

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

[PATCH] D143418: [libclang] Add API to override preamble storage path

[Igor Kushnir via Phabricator via cfe-commits]

vedgy added inline comments.



Comment at: clang/include/clang-c/Index.h:365
+   */
+  int ExcludeDeclarationsFromPCH : 1;
+  /**

Assigning `true` to `int : 1` bit-fields in C++ code produces a GCC warning:
```
warning: overflow in conversion from ‘int’ to ‘signed char:1’ changes value 
from ‘1’ to ‘-1’ [-Woverflow]
```

Following a suggestion in a comment to 
https://github.com/llvm/llvm-project/issues/53253, I replaced this `int` with 
`unsigned` and the warning disappeared. Same for `int DisplayDiagnostics : 1`. 
Should this type change be included in the upcoming `StorePreamblesInMemory` 
revision?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143418

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

[PATCH] D130303: Handle template parameter-dependent bit field widths in libclang

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

dexonsmith added inline comments.



Comment at: clang/tools/libclang/CXType.cpp:13
 
+#include "CXType.h"
 #include "CIndexer.h"

vedgy wrote:
> collinbaker wrote:
> > vedgy wrote:
> > > I guess //clang-format// did this include reordering. But it certainly 
> > > looks out of place and the include order becomes wrong. So I think it 
> > > should be reverted.
> > I don't agree, it's pretty standard for a source file to have its 
> > associated header include at the top.
> You are right, I haven't realized the header-source association. The diff is 
> still unrelated to the patch. But I'm no longer sure what's right, so won't 
> insist on anything.
This is correct behaviour from clang-format.

Given that there were no functional changes to includes, typically we’d omit 
clang-format cleanups. (I know there was a change below originally, but that 
was reverted.)

I’m fine leaving the header clean-up in, or separating it out to different NFC 
commit (ideal; could be done when pushing), or skipping it entirely. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130303

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

[clang] 4cb843d - [OpenCL] Add builtin header TableGen emitter

[Sven van Haastregt via cfe-commits]

Author: Sven van Haastregt
Date: 2023-03-09T10:20:04Z
New Revision: 4cb843d099422e5d77d0f7e16cbb18ee64d457a5

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

LOG: [OpenCL] Add builtin header TableGen emitter

Add an emitter to produce something similar to opencl-c.h from the
OpenCL builtin descriptions in OpenCLBuiltins.td

This only adds the emitter, without any direct use of it.  This allows
opencl-c.h additions to be generated from the builtin descriptions by
manually invoking `clang-tblgen -gen-clang-opencl-builtin-header`.

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

Added: 


Modified: 
clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
clang/utils/TableGen/TableGen.cpp
clang/utils/TableGen/TableGenBackends.h

Removed: 




diff  --git a/clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp 
b/clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
index da5d1fdc2eae3..c3ffa3f72f76d 100644
--- a/clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
+++ b/clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
@@ -324,6 +324,18 @@ class OpenCLBuiltinTestEmitter : public 
OpenCLBuiltinFileEmitterBase {
   void emit() override;
 };
 
+// OpenCL builtin header generator.  This class processes the same TableGen
+// input as BuiltinNameEmitter, but generates a .h file that contains a
+// prototype for each builtin function described in the .td input.
+class OpenCLBuiltinHeaderEmitter : public OpenCLBuiltinFileEmitterBase {
+public:
+  OpenCLBuiltinHeaderEmitter(RecordKeeper &Records, raw_ostream &OS)
+  : OpenCLBuiltinFileEmitterBase(Records, OS) {}
+
+  // Entrypoint to generate the header.
+  void emit() override;
+};
+
 } // namespace
 
 void BuiltinNameEmitter::Emit() {
@@ -1260,11 +1272,76 @@ void OpenCLBuiltinTestEmitter::emit() {
   }
 }
 
+void OpenCLBuiltinHeaderEmitter::emit() {
+  emitSourceFileHeader("OpenCL Builtin declarations", OS);
+
+  emitExtensionSetup();
+
+  OS << R"(
+#define __ovld __attribute__((overloadable))
+#define __conv __attribute__((convergent))
+#define __purefn __attribute__((pure))
+#define __cnfn __attribute__((const))
+
+)";
+
+  // Iterate over all builtins; sort to follow order of definition in .td file.
+  std::vector Builtins = Records.getAllDerivedDefinitions("Builtin");
+  llvm::sort(Builtins, LessRecord());
+
+  for (const auto *B : Builtins) {
+StringRef Name = B->getValueAsString("Name");
+
+std::string OptionalExtensionEndif = emitExtensionGuard(B);
+std::string OptionalVersionEndif = emitVersionGuard(B);
+
+SmallVector, 4> FTypes;
+expandTypesInSignature(B->getValueAsListOfDefs("Signature"), FTypes);
+
+for (const auto &Signature : FTypes) {
+  StringRef OptionalTypeExtEndif = emitTypeExtensionGuards(Signature);
+
+  // Emit function declaration.
+  OS << Signature[0] << " __ovld ";
+  if (B->getValueAsBit("IsConst"))
+OS << "__cnfn ";
+  if (B->getValueAsBit("IsPure"))
+OS << "__purefn ";
+  if (B->getValueAsBit("IsConv"))
+OS << "__conv ";
+
+  OS << Name << "(";
+  if (Signature.size() > 1) {
+for (unsigned I = 1; I < Signature.size(); I++) {
+  if (I != 1)
+OS << ", ";
+  OS << Signature[I];
+}
+  }
+  OS << ");\n";
+
+  OS << OptionalTypeExtEndif;
+}
+
+OS << OptionalVersionEndif;
+OS << OptionalExtensionEndif;
+  }
+
+  OS << "\n// Disable any extensions we may have enabled previously.\n"
+"#pragma OPENCL EXTENSION all : disable";
+}
+
 void clang::EmitClangOpenCLBuiltins(RecordKeeper &Records, raw_ostream &OS) {
   BuiltinNameEmitter NameChecker(Records, OS);
   NameChecker.Emit();
 }
 
+void clang::EmitClangOpenCLBuiltinHeader(RecordKeeper &Records,
+ raw_ostream &OS) {
+  OpenCLBuiltinHeaderEmitter HeaderFileGenerator(Records, OS);
+  HeaderFileGenerator.emit();
+}
+
 void clang::EmitClangOpenCLBuiltinTests(RecordKeeper &Records,
 raw_ostream &OS) {
   OpenCLBuiltinTestEmitter TestFileGenerator(Records, OS);

diff  --git a/clang/utils/TableGen/TableGen.cpp 
b/clang/utils/TableGen/TableGen.cpp
index 6864ba2040ef9..a67e1d1af5d75 100644
--- a/clang/utils/TableGen/TableGen.cpp
+++ b/clang/utils/TableGen/TableGen.cpp
@@ -65,6 +65,7 @@ enum ActionType {
   GenClangCommentCommandInfo,
   GenClangCommentCommandList,
   GenClangOpenCLBuiltins,
+  GenClangOpenCLBuiltinHeader,
   GenClangOpenCLBuiltinTests,
   GenArmNeon,
   GenArmFP16,
@@ -200,6 +201,9 @@ cl::opt Action(
"documentation comments"),
 clEnumValN(GenClangOpenCLBuiltins, "gen-clang-opencl-builtins",
"Generate OpenCL builtin declaration handlers"),
+clEnumValN(GenClangOpenCL

[PATCH] D104040: [OpenCL] Add TableGen emitter for OpenCL builtin header

[Sven van Haastregt via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG4cb843d09942: [OpenCL] Add builtin header TableGen emitter 
(authored by svenvh).
Herald added a subscriber: mgrang.

Changed prior to commit:
  https://reviews.llvm.org/D104040?vs=417678&id=503704#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D104040

Files:
  clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
  clang/utils/TableGen/TableGen.cpp
  clang/utils/TableGen/TableGenBackends.h

Index: clang/utils/TableGen/TableGenBackends.h
===
--- clang/utils/TableGen/TableGenBackends.h
+++ clang/utils/TableGen/TableGenBackends.h
@@ -124,6 +124,8 @@
 
 void EmitClangOpenCLBuiltins(llvm::RecordKeeper &Records,
  llvm::raw_ostream &OS);
+void EmitClangOpenCLBuiltinHeader(llvm::RecordKeeper &Records,
+  llvm::raw_ostream &OS);
 void EmitClangOpenCLBuiltinTests(llvm::RecordKeeper &Records,
  llvm::raw_ostream &OS);
 
Index: clang/utils/TableGen/TableGen.cpp
===
--- clang/utils/TableGen/TableGen.cpp
+++ clang/utils/TableGen/TableGen.cpp
@@ -65,6 +65,7 @@
   GenClangCommentCommandInfo,
   GenClangCommentCommandList,
   GenClangOpenCLBuiltins,
+  GenClangOpenCLBuiltinHeader,
   GenClangOpenCLBuiltinTests,
   GenArmNeon,
   GenArmFP16,
@@ -200,6 +201,9 @@
"documentation comments"),
 clEnumValN(GenClangOpenCLBuiltins, "gen-clang-opencl-builtins",
"Generate OpenCL builtin declaration handlers"),
+clEnumValN(GenClangOpenCLBuiltinHeader,
+   "gen-clang-opencl-builtin-header",
+   "Generate OpenCL builtin header"),
 clEnumValN(GenClangOpenCLBuiltinTests, "gen-clang-opencl-builtin-tests",
"Generate OpenCL builtin declaration tests"),
 clEnumValN(GenArmNeon, "gen-arm-neon", "Generate arm_neon.h for clang"),
@@ -384,6 +388,9 @@
   case GenClangOpenCLBuiltins:
 EmitClangOpenCLBuiltins(Records, OS);
 break;
+  case GenClangOpenCLBuiltinHeader:
+EmitClangOpenCLBuiltinHeader(Records, OS);
+break;
   case GenClangOpenCLBuiltinTests:
 EmitClangOpenCLBuiltinTests(Records, OS);
 break;
Index: clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
===
--- clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
+++ clang/utils/TableGen/ClangOpenCLBuiltinEmitter.cpp
@@ -324,6 +324,18 @@
   void emit() override;
 };
 
+// OpenCL builtin header generator.  This class processes the same TableGen
+// input as BuiltinNameEmitter, but generates a .h file that contains a
+// prototype for each builtin function described in the .td input.
+class OpenCLBuiltinHeaderEmitter : public OpenCLBuiltinFileEmitterBase {
+public:
+  OpenCLBuiltinHeaderEmitter(RecordKeeper &Records, raw_ostream &OS)
+  : OpenCLBuiltinFileEmitterBase(Records, OS) {}
+
+  // Entrypoint to generate the header.
+  void emit() override;
+};
+
 } // namespace
 
 void BuiltinNameEmitter::Emit() {
@@ -1260,11 +1272,76 @@
   }
 }
 
+void OpenCLBuiltinHeaderEmitter::emit() {
+  emitSourceFileHeader("OpenCL Builtin declarations", OS);
+
+  emitExtensionSetup();
+
+  OS << R"(
+#define __ovld __attribute__((overloadable))
+#define __conv __attribute__((convergent))
+#define __purefn __attribute__((pure))
+#define __cnfn __attribute__((const))
+
+)";
+
+  // Iterate over all builtins; sort to follow order of definition in .td file.
+  std::vector Builtins = Records.getAllDerivedDefinitions("Builtin");
+  llvm::sort(Builtins, LessRecord());
+
+  for (const auto *B : Builtins) {
+StringRef Name = B->getValueAsString("Name");
+
+std::string OptionalExtensionEndif = emitExtensionGuard(B);
+std::string OptionalVersionEndif = emitVersionGuard(B);
+
+SmallVector, 4> FTypes;
+expandTypesInSignature(B->getValueAsListOfDefs("Signature"), FTypes);
+
+for (const auto &Signature : FTypes) {
+  StringRef OptionalTypeExtEndif = emitTypeExtensionGuards(Signature);
+
+  // Emit function declaration.
+  OS << Signature[0] << " __ovld ";
+  if (B->getValueAsBit("IsConst"))
+OS << "__cnfn ";
+  if (B->getValueAsBit("IsPure"))
+OS << "__purefn ";
+  if (B->getValueAsBit("IsConv"))
+OS << "__conv ";
+
+  OS << Name << "(";
+  if (Signature.size() > 1) {
+for (unsigned I = 1; I < Signature.size(); I++) {
+  if (I != 1)
+OS << ", ";
+  OS << Signature[I];
+}
+  }
+  OS << ");\n";
+
+  OS << OptionalTypeExtEndif;
+}
+
+OS << OptionalVersionEndif;
+OS << OptionalExtensionEndif;
+  }
+
+  OS << "\n// Disable any extensions we may have enabled previously.\n"
+"#

[PATCH] D145517: MSVC: support version preference with search

[Hans Wennborg via Phabricator via cfe-commits]

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

lgtm

I wish the way clang-cl finds system libraries was better documented though. 
Since you've been digging through this code, would you be up for writing 
something in the https://clang.llvm.org/docs/UsersManual.html#clang-cl section?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145517

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

[PATCH] D129951: adds `__disable_adl` attribute

[Corentin Jabot via Phabricator via cfe-commits]

cor3ntin added a subscriber: lewissbaker.
cor3ntin added a comment.

In D129951#4179596 , @cjdb wrote:

> In D129951#4179481 , @ldionne wrote:
>
>> In D129951#4179467 , @cjdb wrote:
>>
>>> I'm deeply disappointed that libc++ moved away from using 
>>> `__function_like`: that was an important part of preventing niebloid 
>>> misuse. It isn't conforming to treat niebloids as function objects, which 
>>> is what `__function_like` prevented (I just checked `std::ranges::next` and 
>>> it seems that `__function_like` was completely removed).
>>
>> Oops, it seems like my reply got into a race condition with yours. I am 
>> curious though, why is it non-conforming to treat niebloids as function 
>> objects? It is certainly more lax than required by the Standard, however we 
>> are allowed to make those copyable, aren't we? Does the Standard say that we 
>> *have* to make them non-usable as objects? That would change things for sure 
>> (not with this patch, but we'd probably want to try re-introducing 
>> `__function_like`, and we'd file a bug report against libstdc++ to do the 
>> same).
>
> "isn't conforming" is a bit too harsh in retrospect (this applies to 
> //every// conversation I've brought this up in, although I meant that it 
> allows users to write "non-conforming code"). A more accurate way to put this 
> is: it is conforming on a per-implementation basis, but is //non-portable// 
> due to namespace.std/p6 . For 
> example, a user who wants to use Microsoft/STL won't ever be able to take 
> advantage of using `std::ranges::next` as a higher-order function (and could 
> potentially have migration issues if they're porting to Windows), because 
> their niebloids 
>  are 
> derived from _Not_quite_object 
> . 
> `_Not_quite_object`'s predecessor in cmcstl2 was the inspiration for 
> `__function_like`.
>
> As for a refresher on why this is the reason, it's because the functions in 
> `std::ranges` //should// be functions, but we lack the technology to make 
> them functions.
>
> In D129951#4179474 , @ldionne wrote:
>
>> This is a really neat attribute! FWIW, I think we would most likely have 
>> used it in `` if it were available back then. Assuming that GCC 
>> implemented it, I think we could consider changing to use this attribute. 
>> However:
>
> Thanks, glad you like it :-)
> (I think the "however" bit got addressed above.)
>
>> FWIW, my main thought is that I would like to see this proposed as a WG21 
>> proposal. This might end up an attribute or something else, I'm not sure. 
>> But it would address the issue of not all implementations providing the 
>> functionality. IMO this patch and the data gathered in it would be a great 
>> motivation for WG21 to do something (I also know there are other proposals 
>> in this domain).
>
> I don't attend WG21 anymore, but could probably work with someone who is 
> motivated enough to see it from Evolution through plenary. My preference is a 
> specifier, rather than an attribute. For better, or for worse, most 
> attributes are ignorable; this is certainly a property that should never be 
> ignored.

@lewissbaker is the person you want to chat with!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129951

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

[PATCH] D145567: [Driver] Rename multilib flags to tags

[Simon Tatham via Phabricator via cfe-commits]

simon_tatham added a comment.

But it was useful to have it separate at least for review purposes, since it 
made it much easier when Michael asked me to proofread the change from 'flags' 
to 'tags'!




Comment at: clang/docs/Multilib.rst:66
``--target=armv7m-none-eabi`` are equivalent. Clang can also accept many
-   independent pieces of information within a single flag - for example
+   independent pieces of information within a single option - for example
``-march=armv8.1m.main+fp+mve`` specifies the architecture and two

An "option" here seems to be the same thing as an "argument" elsewhere in this 
paragraph. Since the terminology is already confusing, perhaps simplify by 
using the same word consistently throughout? I think "option" is more precise, 
because //positional// clang arguments like input files definitely //don't// 
play a part in this mechanism.



Comment at: clang/docs/Multilib.rst:182
   # List of multilib variants. Required.
   # The ordering of Variants is important if more than one variant can match
+  # the same set of tags. See the docs on multilib layering for more info.

That capital V looks unintentional to me, and is potentially confusing – 
someone might go looking for a formal definition of it somewhere.



Comment at: clang/include/clang/Driver/Multilib.h:64-65
+  /// Get the set of tags that indicate this multilib's use.
+  /// Tags are arbitrary strings although typically they will look similar to
+  /// command line options. A multilib is considered compatible if its tags are
+  /// a subset of the tags derived from the Clang command line options.

Tags are arbitrary strings, some of which are derived from command-line options 
and look similar to them, and others can be defined by a particular 
multilib.yaml


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145567

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

[PATCH] D144903: [X86] Drop single use check for freeze(undef) in LowerAVXCONCAT_VECTORS

[Manuel Brito via Phabricator via cfe-commits]

ManuelJBrito added inline comments.



Comment at: clang/test/CodeGen/X86/avx-cast-builtins.c:1
 // RUN: %clang_cc1 %s -O3 -flax-vector-conversions=none -ffreestanding %s 
-triple=x86_64-unknown-unknown -target-feature +avx -target-feature +avx512f  
-target-feature +avx512fp16 -S -o - | FileCheck %s
 

aqjune wrote:
> aqjune wrote:
> > This line contains `%s` twice, which seems to cause the crash.
> > 
> > Would removing one of `%s` resolve the crash issue? On my machine removing 
> > one of those worked well; with two `%s`; it crashed.
> Actually, with FileCheck's argument counted there are three `%s`, but it 
> isn't important; I meant two `%s` in clang_cc1's arguments.
Oops .. I should have noticed that...
I will try to commit again with this fix . Thanks for looking at this aqjune!!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144903

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

[clang] 353155a - [clang][analyzer][NFC] Refactor code of StdLibraryFunctionsChecker.

[Balázs Kéri via cfe-commits]

Author: Balázs Kéri
Date: 2023-03-09T11:54:52+01:00
New Revision: 353155a1a507e2d04edf227b8665a6360b354762

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

LOG: [clang][analyzer][NFC] Refactor code of StdLibraryFunctionsChecker.

The code was difficult to maintain (big internal class definitions
with long inline functions, other functions of the same class at
different location far away, irregular ordering of classes and
function definitions). It is now improved to some extent.
New functions are added to RangeConstraint to remove code repetition,
these are useful for planned new features too.
Comments are improved.

Reviewed By: Szelethus

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

Added: 


Modified: 
clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp

Removed: 




diff  --git a/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp 
b/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
index b36f72f2653c7..98f5540cef709 100644
--- a/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ b/clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -65,47 +65,68 @@ class StdLibraryFunctionsChecker
   class Summary;
 
   /// Specify how much the analyzer engine should entrust modeling this 
function
-  /// to us. If he doesn't, he performs additional invalidations.
-  enum InvalidationKind { NoEvalCall, EvalCallAsPure };
+  /// to us.
+  enum InvalidationKind {
+/// No \c eval::Call for the function, it can be modeled elsewhere.
+/// This checker checks only pre and post conditions.
+NoEvalCall,
+/// The function is modeled completely in this checker.
+EvalCallAsPure
+  };
 
-  // The universal integral type to use in value range descriptions.
-  // Unsigned to make sure overflows are well-defined.
+  /// Given a range, should the argument stay inside or outside this range?
+  enum RangeKind { OutOfRange, WithinRange };
+
+  static RangeKind negateKind(RangeKind K) {
+switch (K) {
+case OutOfRange:
+  return WithinRange;
+case WithinRange:
+  return OutOfRange;
+}
+llvm_unreachable("Unknown range kind");
+  }
+
+  /// The universal integral type to use in value range descriptions.
+  /// Unsigned to make sure overflows are well-defined.
   typedef uint64_t RangeInt;
 
-  /// Normally, describes a single range constraint, eg. {{0, 1}, {3, 4}} is
-  /// a non-negative integer, which less than 5 and not equal to 2. For
-  /// `ComparesToArgument', holds information about how exactly to compare to
-  /// the argument.
+  /// Describes a single range constraint. Eg. {{0, 1}, {3, 4}} is
+  /// a non-negative integer, which less than 5 and not equal to 2.
   typedef std::vector> IntRangeVector;
 
   /// A reference to an argument or return value by its number.
   /// ArgNo in CallExpr and CallEvent is defined as Unsigned, but
   /// obviously uint32_t should be enough for all practical purposes.
   typedef uint32_t ArgNo;
+  /// Special argument number for specifying the return value.
   static const ArgNo Ret;
 
   using DescString = SmallString<96>;
+
   /// Returns the string representation of an argument index.
   /// E.g.: (1) -> '1st arg', (2) - > '2nd arg'
   static SmallString<8> getArgDesc(ArgNo);
   /// Append textual description of a numeric range [RMin,RMax] to the string
-  /// 'Out'.
+  /// \p Out.
   static void appendInsideRangeDesc(llvm::APSInt RMin, llvm::APSInt RMax,
 QualType ArgT, BasicValueFactory &BVF,
 DescString &Out);
   /// Append textual description of a numeric range out of [RMin,RMax] to the
-  /// string 'Out'.
+  /// string \p Out.
   static void appendOutOfRangeDesc(llvm::APSInt RMin, llvm::APSInt RMax,
QualType ArgT, BasicValueFactory &BVF,
DescString &Out);
 
   class ValueConstraint;
 
-  // Pointer to the ValueConstraint. We need a copyable, polymorphic and
-  // default initialize able type (vector needs that). A raw pointer was good,
-  // however, we cannot default initialize that. unique_ptr makes the Summary
-  // class non-copyable, therefore not an option. Releasing the copyability
-  // requirement would render the initialization of the Summary map infeasible.
+  /// Pointer to the ValueConstraint. We need a copyable, polymorphic and
+  /// default initializable type (vector needs that). A raw pointer was good,
+  /// however, we cannot default initialize that. unique_ptr makes the Summary
+  /// class non-copyable, therefore not an option. Releasing the copyability
+  /// requirement would render the initialization of the Summary map 
infeasible.
+  /// Mind that a pointer to a

[PATCH] D143751: [clang][analyzer][NFC] Refactor code of StdLibraryFunctionsChecker.

[Balázs Kéri via Phabricator via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rG353155a1a507: [clang][analyzer][NFC] Refactor code of 
StdLibraryFunctionsChecker. (authored by balazske).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143751

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

Index: clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
===
--- clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
+++ clang/lib/StaticAnalyzer/Checkers/StdLibraryFunctionsChecker.cpp
@@ -65,47 +65,68 @@
   class Summary;
 
   /// Specify how much the analyzer engine should entrust modeling this function
-  /// to us. If he doesn't, he performs additional invalidations.
-  enum InvalidationKind { NoEvalCall, EvalCallAsPure };
+  /// to us.
+  enum InvalidationKind {
+/// No \c eval::Call for the function, it can be modeled elsewhere.
+/// This checker checks only pre and post conditions.
+NoEvalCall,
+/// The function is modeled completely in this checker.
+EvalCallAsPure
+  };
 
-  // The universal integral type to use in value range descriptions.
-  // Unsigned to make sure overflows are well-defined.
+  /// Given a range, should the argument stay inside or outside this range?
+  enum RangeKind { OutOfRange, WithinRange };
+
+  static RangeKind negateKind(RangeKind K) {
+switch (K) {
+case OutOfRange:
+  return WithinRange;
+case WithinRange:
+  return OutOfRange;
+}
+llvm_unreachable("Unknown range kind");
+  }
+
+  /// The universal integral type to use in value range descriptions.
+  /// Unsigned to make sure overflows are well-defined.
   typedef uint64_t RangeInt;
 
-  /// Normally, describes a single range constraint, eg. {{0, 1}, {3, 4}} is
-  /// a non-negative integer, which less than 5 and not equal to 2. For
-  /// `ComparesToArgument', holds information about how exactly to compare to
-  /// the argument.
+  /// Describes a single range constraint. Eg. {{0, 1}, {3, 4}} is
+  /// a non-negative integer, which less than 5 and not equal to 2.
   typedef std::vector> IntRangeVector;
 
   /// A reference to an argument or return value by its number.
   /// ArgNo in CallExpr and CallEvent is defined as Unsigned, but
   /// obviously uint32_t should be enough for all practical purposes.
   typedef uint32_t ArgNo;
+  /// Special argument number for specifying the return value.
   static const ArgNo Ret;
 
   using DescString = SmallString<96>;
+
   /// Returns the string representation of an argument index.
   /// E.g.: (1) -> '1st arg', (2) - > '2nd arg'
   static SmallString<8> getArgDesc(ArgNo);
   /// Append textual description of a numeric range [RMin,RMax] to the string
-  /// 'Out'.
+  /// \p Out.
   static void appendInsideRangeDesc(llvm::APSInt RMin, llvm::APSInt RMax,
 QualType ArgT, BasicValueFactory &BVF,
 DescString &Out);
   /// Append textual description of a numeric range out of [RMin,RMax] to the
-  /// string 'Out'.
+  /// string \p Out.
   static void appendOutOfRangeDesc(llvm::APSInt RMin, llvm::APSInt RMax,
QualType ArgT, BasicValueFactory &BVF,
DescString &Out);
 
   class ValueConstraint;
 
-  // Pointer to the ValueConstraint. We need a copyable, polymorphic and
-  // default initialize able type (vector needs that). A raw pointer was good,
-  // however, we cannot default initialize that. unique_ptr makes the Summary
-  // class non-copyable, therefore not an option. Releasing the copyability
-  // requirement would render the initialization of the Summary map infeasible.
+  /// Pointer to the ValueConstraint. We need a copyable, polymorphic and
+  /// default initializable type (vector needs that). A raw pointer was good,
+  /// however, we cannot default initialize that. unique_ptr makes the Summary
+  /// class non-copyable, therefore not an option. Releasing the copyability
+  /// requirement would render the initialization of the Summary map infeasible.
+  /// Mind that a pointer to a new value constraint is created when the negate
+  /// function is used.
   using ValueConstraintPtr = std::shared_ptr;
 
   /// Polymorphic base class that represents a constraint on a given argument
@@ -122,35 +143,12 @@
   public:
 ValueConstraint(ArgNo ArgN) : ArgN(ArgN) {}
 virtual ~ValueConstraint() {}
+
 /// Apply the effects of the constraint on the given program state. If null
 /// is returned then the constraint is not feasible.
 virtual ProgramStateRef apply(ProgramStateRef State, const CallEvent &Call,
   const Summary &Summary,
   CheckerContext &C) const = 0;
-virtual ValueConstraintPtr negate() const 

[PATCH] D145567: [Driver] Rename multilib flags to tags

[Simon Tatham via Phabricator via cfe-commits]

simon_tatham added inline comments.



Comment at: clang/docs/Multilib.rst:71
+   arguments into a standard set of simpler "tags". In many cases these tags
will look like a command line argument with the leading ``-`` stripped off,
+   but where a suitable form for the tag doesn't exist in command line

This is a particular case where "option" seems like a better word. Not every 
//argument// has a leading `-` in the first place. But every //option// does.

(Or, at least, in the default Unix / gcc style of clang options. I suppose in 
`clang-cl` even that is not true, because options can have a leading `/` in 
Windows style. I assume that in that situation the options are normalised to 
their GNU representation before converting into multilib selection tags?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145567

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

[clang] e281793 - [X86] Drop single use check for freeze(undef) in LowerAVXCONCAT_VECTORS

[via cfe-commits]

Author: ManuelJBrito
Date: 2023-03-09T11:01:09Z
New Revision: e2817933fdd4417673eb7f96a2842ae2dca8fc59

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

LOG: [X86] Drop single use check for freeze(undef) in LowerAVXCONCAT_VECTORS

Ignoring freeze(undef) if it has multiple uses in LowerAVXCONCAT_VECTORS
causes the custom INSERT_SUBVECTOR for vector widening to be ignored.

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

Added: 
clang/test/CodeGen/X86/avx-cast-builtins.c

Modified: 
llvm/lib/Target/X86/X86ISelLowering.cpp
llvm/test/CodeGen/X86/avx512-intrinsics.ll
llvm/test/CodeGen/X86/avx512fp16-intrinsics.ll

Removed: 




diff  --git a/clang/test/CodeGen/X86/avx-cast-builtins.c 
b/clang/test/CodeGen/X86/avx-cast-builtins.c
new file mode 100644
index 0..edf64b83fe9cc
--- /dev/null
+++ b/clang/test/CodeGen/X86/avx-cast-builtins.c
@@ -0,0 +1,100 @@
+// RUN: %clang_cc1 -O3 -flax-vector-conversions=none -ffreestanding %s 
-triple=x86_64-unknown-unknown -target-feature +avx -target-feature +avx512f  
-target-feature +avx512fp16 -S -o - | FileCheck %s
+
+
+#include 
+
+__m256d test_mm256_castpd128_pd256(__m128d A) {
+  // CHECK-LABEL: test_mm256_castpd128_pd256
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $ymm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm256_castpd128_pd256(A);
+}
+
+__m256 test_mm256_castps128_ps256(__m128 A) {
+  // CHECK-LABEL: test_mm256_castps128_ps256
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $ymm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm256_castps128_ps256(A);
+}
+
+__m256i test_mm256_castsi128_si256(__m128i A) {
+  // CHECK-LABEL: test_mm256_castsi128_si256
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $ymm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm256_castsi128_si256(A);
+}
+
+__m256h test_mm256_castph128_ph256(__m128h A) {
+  // CHECK-LABEL: test_mm256_castph128_ph256
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $ymm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm256_castph128_ph256(A);
+}
+
+__m512h test_mm512_castph128_ph512(__m128h A) {
+  // CHECK-LABEL: test_mm512_castph128_ph512
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $zmm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm512_castph128_ph512(A);
+}
+
+__m512h test_mm512_castph256_ph512(__m256h A) {
+  // CHECK-LABEL: test_mm512_castph256_ph512
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $ymm0 killed $ymm0 def $zmm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm512_castph256_ph512(A);
+}
+
+__m512d test_mm512_castpd256_pd512(__m256d A){
+  // CHECK-LABEL: test_mm512_castpd256_pd512
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $ymm0 killed $ymm0 def $zmm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm512_castpd256_pd512(A);
+}
+
+__m512 test_mm512_castps256_ps512(__m256 A){
+  // CHECK-LABEL: test_mm512_castps256_ps512
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $ymm0 killed $ymm0 def $zmm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm512_castps256_ps512(A);
+}
+
+__m512d test_mm512_castpd128_pd512(__m128d A){
+  // CHECK-LABEL: test_mm512_castpd128_pd512
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $zmm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm512_castpd128_pd512(A);
+}
+
+__m512 test_mm512_castps128_ps512(__m128 A){
+  // CHECK-LABEL: test_mm512_castps128_ps512
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $zmm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm512_castps128_ps512(A);
+}
+
+__m512i test_mm512_castsi128_si512(__m128i A){
+  // CHECK-LABEL: test_mm512_castsi128_si512
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $zmm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm512_castsi128_si512(A);
+}
+
+__m512i test_mm512_castsi256_si512(__m256i A){
+  // CHECK-LABEL: test_mm512_castsi256_si512
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $ymm0 killed $ymm0 def $zmm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm512_castsi256_si512(A);
+}

diff  --git a/llvm/lib/Target/X86/X86ISelLowering.cpp 
b/llvm/lib/Target/X86/X86ISelLowering.cpp
index 4a59bba3fddf8..355c5be568b36 100644
--- a/llvm/lib/Target/X86/X86ISelLowering.cpp
+++ b/llvm/lib/Target/X86/X86ISelLowering.cpp
@@ -11656,7 +11656,7 @@ static SDValue LowerAVXCONCAT_VECTORS(SDValue Op, 
SelectionDAG &DAG,
 SDValue SubVec = Op.getOperand(i);
 if (SubVec.isUndef())
   continue;
-if (ISD::isFreezeUndef(SubVec.getNode()) && SubVec.hasOneUse())
+if (ISD::isFreezeUndef(SubVec.ge

[PATCH] D144903: [X86] Drop single use check for freeze(undef) in LowerAVXCONCAT_VECTORS

[Manuel Brito 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 rGe2817933fdd4: [X86] Drop single use check for freeze(undef) 
in LowerAVXCONCAT_VECTORS (authored by ManuelJBrito).

Changed prior to commit:
  https://reviews.llvm.org/D144903?vs=501079&id=503711#toc

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144903

Files:
  clang/test/CodeGen/X86/avx-cast-builtins.c
  llvm/lib/Target/X86/X86ISelLowering.cpp
  llvm/test/CodeGen/X86/avx512-intrinsics.ll
  llvm/test/CodeGen/X86/avx512fp16-intrinsics.ll

Index: llvm/test/CodeGen/X86/avx512fp16-intrinsics.ll
===
--- llvm/test/CodeGen/X86/avx512fp16-intrinsics.ll
+++ llvm/test/CodeGen/X86/avx512fp16-intrinsics.ll
@@ -1231,10 +1231,7 @@
 define <32 x half> @test_mm512_castph128_ph512_freeze(<8 x half> %a0) nounwind {
 ; CHECK-LABEL: test_mm512_castph128_ph512_freeze:
 ; CHECK:   # %bb.0:
-; CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $ymm0
-; CHECK-NEXT:vinsertf128 $1, %xmm0, %ymm0, %ymm1
-; CHECK-NEXT:vinsertf128 $1, %xmm0, %ymm0, %ymm0
-; CHECK-NEXT:vinsertf64x4 $1, %ymm1, %zmm0, %zmm0
+; CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $zmm0
 ; CHECK-NEXT:retq
   %a1 = freeze <8 x half> poison
   %res = shufflevector <8 x half> %a0, <8 x half> %a1, <32 x i32> 
Index: llvm/test/CodeGen/X86/avx512-intrinsics.ll
===
--- llvm/test/CodeGen/X86/avx512-intrinsics.ll
+++ llvm/test/CodeGen/X86/avx512-intrinsics.ll
@@ -7495,10 +7495,7 @@
 define <8 x double> @test_mm256_castpd128_pd256_freeze(<2 x double> %a0) nounwind {
 ; CHECK-LABEL: test_mm256_castpd128_pd256_freeze:
 ; CHECK:   # %bb.0:
-; CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $ymm0
-; CHECK-NEXT:vinsertf128 $1, %xmm0, %ymm0, %ymm1
-; CHECK-NEXT:vinsertf128 $1, %xmm0, %ymm0, %ymm0
-; CHECK-NEXT:vinsertf64x4 $1, %ymm1, %zmm0, %zmm0
+; CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $zmm0
 ; CHECK-NEXT:ret{{[l|q]}}
   %a1 = freeze <2 x double> poison
   %res = shufflevector <2 x double> %a0, <2 x double> %a1, <8 x i32> 
@@ -7520,10 +7517,7 @@
 define <16 x float> @test_mm256_castps128_ps512_freeze(<4 x float> %a0) nounwind {
 ; CHECK-LABEL: test_mm256_castps128_ps512_freeze:
 ; CHECK:   # %bb.0:
-; CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $ymm0
-; CHECK-NEXT:vinsertf128 $1, %xmm0, %ymm0, %ymm1
-; CHECK-NEXT:vinsertf128 $1, %xmm0, %ymm0, %ymm0
-; CHECK-NEXT:vinsertf64x4 $1, %ymm1, %zmm0, %zmm0
+; CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $zmm0
 ; CHECK-NEXT:ret{{[l|q]}}
   %a1 = freeze <4 x float> poison
   %res = shufflevector <4 x float> %a0, <4 x float> %a1, <16x i32> 
@@ -7545,10 +7539,7 @@
 define <8 x i64> @test_mm512_castsi128_si512_freeze(<2 x i64> %a0) nounwind {
 ; CHECK-LABEL: test_mm512_castsi128_si512_freeze:
 ; CHECK:   # %bb.0:
-; CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $ymm0
-; CHECK-NEXT:vinsertf128 $1, %xmm0, %ymm0, %ymm1
-; CHECK-NEXT:vinsertf128 $1, %xmm0, %ymm0, %ymm0
-; CHECK-NEXT:vinsertf64x4 $1, %ymm1, %zmm0, %zmm0
+; CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $zmm0
 ; CHECK-NEXT:ret{{[l|q]}}
   %a1 = freeze <2 x i64> poison
   %res = shufflevector <2 x i64> %a0, <2 x i64> %a1, <8 x i32> 
Index: llvm/lib/Target/X86/X86ISelLowering.cpp
===
--- llvm/lib/Target/X86/X86ISelLowering.cpp
+++ llvm/lib/Target/X86/X86ISelLowering.cpp
@@ -11656,7 +11656,7 @@
 SDValue SubVec = Op.getOperand(i);
 if (SubVec.isUndef())
   continue;
-if (ISD::isFreezeUndef(SubVec.getNode()) && SubVec.hasOneUse())
+if (ISD::isFreezeUndef(SubVec.getNode()))
   ++NumFreezeUndef;
 else if (ISD::isBuildVectorAllZeros(SubVec.getNode()))
   ++NumZero;
Index: clang/test/CodeGen/X86/avx-cast-builtins.c
===
--- /dev/null
+++ clang/test/CodeGen/X86/avx-cast-builtins.c
@@ -0,0 +1,100 @@
+// RUN: %clang_cc1 -O3 -flax-vector-conversions=none -ffreestanding %s -triple=x86_64-unknown-unknown -target-feature +avx -target-feature +avx512f  -target-feature +avx512fp16 -S -o - | FileCheck %s
+
+
+#include 
+
+__m256d test_mm256_castpd128_pd256(__m128d A) {
+  // CHECK-LABEL: test_mm256_castpd128_pd256
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $ymm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm256_castpd128_pd256(A);
+}
+
+__m256 test_mm256_castps128_ps256(__m128 A) {
+  // CHECK-LABEL: test_mm256_castps128_ps256
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $ymm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm256_castps128_ps256(A);
+}
+
+__m256i test_mm256_castsi128_si256(__

[PATCH] D141307: Add -f[no-]loop-versioning option

[Tom Eccles via Phabricator via cfe-commits]

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

Looks good to me


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D141307

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

[clang] 6836714 - Revert "[clang-format] Add -j to clang-format-diff to speed up formatting"

[Nikita Popov via cfe-commits]

Author: Nikita Popov
Date: 2023-03-09T12:32:10+01:00
New Revision: 68367141dd91ee71f50418f28ea358519cd6613d

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

LOG: Revert "[clang-format] Add -j to clang-format-diff to speed up formatting"

This reverts commit d14e7ee3d17cfa60d44256d742c10e9949a6048f.

Makes clang_format_diff.py always fail with:

Traceback (most recent call last):
  File 
"/home/npopov/repos/llvm-project/clang/tools/clang-format/clang-format-diff.py",
 line 177, in 
main()
  File 
"/home/npopov/repos/llvm-project/clang/tools/clang-format/clang-format-diff.py",
 line 174, in main
process_subprocess_result(proc, args)
  File 
"/home/npopov/repos/llvm-project/clang/tools/clang-format/clang-format-diff.py",
 line 42, in process_subprocess_result
with open(filename) as f:
  
NameError: name 'filename' is not defined

Added: 


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

Removed: 




diff  --git a/clang/tools/clang-format/clang-format-
diff .py b/clang/tools/clang-format/clang-format-
diff .py
index ce971e414e3d4..1dcc8689d5fef 100755
--- a/clang/tools/clang-format/clang-format-
diff .py
+++ b/clang/tools/clang-format/clang-format-
diff .py
@@ -34,21 +34,6 @@
 else:
 from io import BytesIO as StringIO
 
-def process_subprocess_result(proc, args):
-  stdout, stderr = proc.communicate()
-  if proc.returncode != 0:
-sys.exit(proc.returncode)
-  if not args.i:
-with open(filename) as f:
-  code = f.readlines()
-formatted_code = StringIO(stdout).readlines()
-
diff  = 
diff lib.unified_
diff (code, formatted_code,
-filename, filename,
-'(before formatting)',
-'(after formatting)')
-
diff _string = ''.join(
diff )
-if len(
diff _string) > 0:
-  sys.stdout.write(
diff _string)
 
 def main():
   parser = argparse.ArgumentParser(description=__doc__,
@@ -80,9 +65,6 @@ def main():
   'file to use.')
   parser.add_argument('-binary', default='clang-format',
   help='location of binary to use for clang-format')
-  parser.add_argument('-j', default=1, type=int, metavar='N',
-  help='number of concurrent clang-format processes to 
spawn in '
-  'parallel')
   args = parser.parse_args()
 
   # Extract changed lines for each file.
@@ -124,54 +106,46 @@ def main():
   ['-lines', str(start_line) + ':' + str(end_line)])
 
   # Reformat files containing changes in place.
-  lbf = list(lines_by_file.items())
-  procs = [None for i in range(args.j)]
-  while lbf:
-spawned_one = False
-for i, proc in enumerate(procs):
-  if not lbf:
-break
-  if proc is not None and proc.poll() is not None:
-process_subprocess_result(proc, args)
-# Set to None to flag the slot as free to start a new process
-procs[i] = None
-proc = None
-  if proc is None:
-filename, lines = lbf.pop()
-spawned_one = True
-if args.i and args.verbose:
-  print('Formatting {}'.format(filename))
-command = [args.binary, filename]
-if args.i:
-  command.append('-i')
-if args.sort_includes:
-  command.append('-sort-includes')
-command.extend(lines)
-if args.style:
-  command.extend(['-style', args.style])
-if args.fallback_style:
-  command.extend(['-fallback-style', args.fallback_style])
-try:
-  procs[i] = subprocess.Popen(command,
-  stdout=subprocess.PIPE,
-  stderr=None,
-  stdin=subprocess.PIPE,
-  universal_newlines=True)
-except OSError as e:
-  # Give the user more context when clang-format isn't
-  # found/isn't executable, etc.
-  raise RuntimeError(
-  'Failed to run "%s" - %s"' % (" ".join(command), e.strerror))
-# If we didn't spawn a single process after iterating through the whole
-# list, wait on one of them to finish until we iterate through again, to
-# prevent spinning in the case where we have a small number of jobs.
-if not spawned_one:
-  procs[0].wait()
-  # Be sure not to leave any stray processes when exiting.
-  for proc in procs:
-if proc:
-  proc.wait()
-  process_subprocess_result(proc, args)
+  for filename, lines in lines_by_file.items():
+if args.i and args.verbose:
+  print('Formatting {}'.format(filename))
+command = [args.binary, filename]
+if args.i:
+  command.append('-i')
+   

[clang] 85e6617 - Revert "[X86] Drop single use check for freeze(undef) in LowerAVXCONCAT_VECTORS"

[via cfe-commits]

Author: ManuelJBrito
Date: 2023-03-09T11:56:08Z
New Revision: 85e6617b604a45f0ae5fc08f6cc2c4f6eb3d84a7

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

LOG: Revert "[X86] Drop single use check for freeze(undef) in 
LowerAVXCONCAT_VECTORS"

This reverts commit e2817933fdd4417673eb7f96a2842ae2dca8fc59.

Added: 


Modified: 
llvm/lib/Target/X86/X86ISelLowering.cpp
llvm/test/CodeGen/X86/avx512-intrinsics.ll
llvm/test/CodeGen/X86/avx512fp16-intrinsics.ll

Removed: 
clang/test/CodeGen/X86/avx-cast-builtins.c



diff  --git a/clang/test/CodeGen/X86/avx-cast-builtins.c 
b/clang/test/CodeGen/X86/avx-cast-builtins.c
deleted file mode 100644
index edf64b83fe9cc..0
--- a/clang/test/CodeGen/X86/avx-cast-builtins.c
+++ /dev/null
@@ -1,100 +0,0 @@
-// RUN: %clang_cc1 -O3 -flax-vector-conversions=none -ffreestanding %s 
-triple=x86_64-unknown-unknown -target-feature +avx -target-feature +avx512f  
-target-feature +avx512fp16 -S -o - | FileCheck %s
-
-
-#include 
-
-__m256d test_mm256_castpd128_pd256(__m128d A) {
-  // CHECK-LABEL: test_mm256_castpd128_pd256
-  // CHECK: # %bb.0:
-  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $ymm0
-  // CHECK-NEXT:ret{{[l|q]}}
-  return _mm256_castpd128_pd256(A);
-}
-
-__m256 test_mm256_castps128_ps256(__m128 A) {
-  // CHECK-LABEL: test_mm256_castps128_ps256
-  // CHECK: # %bb.0:
-  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $ymm0
-  // CHECK-NEXT:ret{{[l|q]}}
-  return _mm256_castps128_ps256(A);
-}
-
-__m256i test_mm256_castsi128_si256(__m128i A) {
-  // CHECK-LABEL: test_mm256_castsi128_si256
-  // CHECK: # %bb.0:
-  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $ymm0
-  // CHECK-NEXT:ret{{[l|q]}}
-  return _mm256_castsi128_si256(A);
-}
-
-__m256h test_mm256_castph128_ph256(__m128h A) {
-  // CHECK-LABEL: test_mm256_castph128_ph256
-  // CHECK: # %bb.0:
-  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $ymm0
-  // CHECK-NEXT:ret{{[l|q]}}
-  return _mm256_castph128_ph256(A);
-}
-
-__m512h test_mm512_castph128_ph512(__m128h A) {
-  // CHECK-LABEL: test_mm512_castph128_ph512
-  // CHECK: # %bb.0:
-  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $zmm0
-  // CHECK-NEXT:ret{{[l|q]}}
-  return _mm512_castph128_ph512(A);
-}
-
-__m512h test_mm512_castph256_ph512(__m256h A) {
-  // CHECK-LABEL: test_mm512_castph256_ph512
-  // CHECK: # %bb.0:
-  // CHECK-NEXT:# kill: def $ymm0 killed $ymm0 def $zmm0
-  // CHECK-NEXT:ret{{[l|q]}}
-  return _mm512_castph256_ph512(A);
-}
-
-__m512d test_mm512_castpd256_pd512(__m256d A){
-  // CHECK-LABEL: test_mm512_castpd256_pd512
-  // CHECK: # %bb.0:
-  // CHECK-NEXT:# kill: def $ymm0 killed $ymm0 def $zmm0
-  // CHECK-NEXT:ret{{[l|q]}}
-  return _mm512_castpd256_pd512(A);
-}
-
-__m512 test_mm512_castps256_ps512(__m256 A){
-  // CHECK-LABEL: test_mm512_castps256_ps512
-  // CHECK: # %bb.0:
-  // CHECK-NEXT:# kill: def $ymm0 killed $ymm0 def $zmm0
-  // CHECK-NEXT:ret{{[l|q]}}
-  return _mm512_castps256_ps512(A);
-}
-
-__m512d test_mm512_castpd128_pd512(__m128d A){
-  // CHECK-LABEL: test_mm512_castpd128_pd512
-  // CHECK: # %bb.0:
-  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $zmm0
-  // CHECK-NEXT:ret{{[l|q]}}
-  return _mm512_castpd128_pd512(A);
-}
-
-__m512 test_mm512_castps128_ps512(__m128 A){
-  // CHECK-LABEL: test_mm512_castps128_ps512
-  // CHECK: # %bb.0:
-  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $zmm0
-  // CHECK-NEXT:ret{{[l|q]}}
-  return _mm512_castps128_ps512(A);
-}
-
-__m512i test_mm512_castsi128_si512(__m128i A){
-  // CHECK-LABEL: test_mm512_castsi128_si512
-  // CHECK: # %bb.0:
-  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $zmm0
-  // CHECK-NEXT:ret{{[l|q]}}
-  return _mm512_castsi128_si512(A);
-}
-
-__m512i test_mm512_castsi256_si512(__m256i A){
-  // CHECK-LABEL: test_mm512_castsi256_si512
-  // CHECK: # %bb.0:
-  // CHECK-NEXT:# kill: def $ymm0 killed $ymm0 def $zmm0
-  // CHECK-NEXT:ret{{[l|q]}}
-  return _mm512_castsi256_si512(A);
-}

diff  --git a/llvm/lib/Target/X86/X86ISelLowering.cpp 
b/llvm/lib/Target/X86/X86ISelLowering.cpp
index a93eb810cdf8c..5280dfaf7f89c 100644
--- a/llvm/lib/Target/X86/X86ISelLowering.cpp
+++ b/llvm/lib/Target/X86/X86ISelLowering.cpp
@@ -11656,7 +11656,7 @@ static SDValue LowerAVXCONCAT_VECTORS(SDValue Op, 
SelectionDAG &DAG,
 SDValue SubVec = Op.getOperand(i);
 if (SubVec.isUndef())
   continue;
-if (ISD::isFreezeUndef(SubVec.getNode()))
+if (ISD::isFreezeUndef(SubVec.getNode()) && SubVec.hasOneUse())
   ++NumFreezeUndef;
 else if (ISD::isBuildVectorAllZeros(SubVec.getNode()))
   ++NumZero;

diff  --gi

[PATCH] D143466: [clang][Interp] Fix initializing base class members

[Timm Bäder via Phabricator via cfe-commits]

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

The tests you proposed need https://reviews.llvm.org/D143480 first so we can 
cast up more than one level.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143466

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

[PATCH] D145642: [clang-format] Annotate lambdas with requires clauses.

[Björn Schäpers via Phabricator via cfe-commits]

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



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:3393
+break;
+  } else {
+return;

don't need `else` after `break`.
In fact I would negate the condition and return, and keep the remainder out of 
any `if` or `else`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145642

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

[PATCH] D145435: Choose style (file) from within code for use in IDEs

[Björn Schäpers via Phabricator via cfe-commits]

HazardyKnusperkeks added a comment.

In D145435#4179662 , @owenpan wrote:

> In D145435#4179308 , @bersbersbers 
> wrote:
>
>> In D145435#4173875 , @owenpan 
>> wrote:
>>
>>> Please refer to D125171#4167866  
>>> to make the case that such a feature should be added.
>>>
>>> - have a publicly accessible style guide
>>
>> I am not sure what a "style guide" might be in my case, and I'd be happy 
>> about any clarification. Might that simply be documentation?
>
> An example of publicly accessible style guides would be 
> https://google.github.io/styleguide/cppguide.html#Formatting. Nevertheless, 
> it's unlikely your proposed new feature is covered by any style guides.
>
>> In D145435#4176279 , @owenpan 
>> wrote:
>>
>>> I don't understand why anyone wants to do this. [...] If I lock down the 
>>> style for the files I created as this requested feature allows, what would 
>>> happen if others need to maintain these files down the road?
>>
>> I see a number of settings where people might want this:
>>
>> - Teams not (fully) agreeing on a common style, with different people using 
>> different styles (such as `BS_Allman` vs `BS_Attach`). Not saying that 
>> should be allowed in every project, but I can easily see how allowing it can 
>> avoid conflicts if users can just impose their own style on the files they 
>> maintain. (Note that this is already possible, but only by moving each 
>> user's file into a separate directory. The proposed patch will just make it 
>> easier.)
>
> I don't think the purpose of supporting per-directory config files is to 
> allow different users to have different styles within the same codebase.
>
>> - If the previous point sounds like opening the code base for style chaos 
>> (in fact, your final question appears to suggest that a per-file style will 
>> always be incompatible with the directory style), note there can be very 
>> benign examples. A team may have agreed on a 120 column limit, but they have 
>> a file that is diffed very often and for which it makes sense to have an 80 
>> column limit. With the proposed style comment, you can enforce that locally. 
>> Note that such a file does not go against the 120 column limit, so no one is 
>> breaking any agreed-upon rules, and no other maintainer should have a 
>> problem with that file. Another example is `MaxEmptyLinesToKeep`: a team may 
>> have agreed on 3 (or no limit at all), but one maintainer likes to keep 
>> their code vertically short at works using `MaxEmptyLinesToKeep: 1`. That 
>> file will still be compliant with the agreed-upon style.
>> - Code and style are self-contained in a single file. If you move a file 
>> from one directory to another, it will continue to use the same style, even 
>> if the two folders use different .clang-format files. (Not saying this has 
>> to be done, but it's nice to have the option.) If you email/scp/... the file 
>> to someone, the recipient knows the format and can easily format after 
>> making changes.
>
> Are the settings above hypothetical or are they real-world use cases?
>
> IMO, if people really want to have per-file configurations, they can do so 
> outside of clang-format, e.g. using grep in a shell script.

Although I don't think I will use that feature, I still think it might be 
useful and doesn't really hurt anyone. I can't give you any examples right now, 
but more than once I wished I could change the style **within** the file, right 
now I just do `// clang-format off` or accept that the code doesn't look like I 
want to.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145435

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

[clang] 9aa54db - Revert "Disable test for __builtin_set_flt_rounds to avoid breaking PPC buildbot"

[Aaron Ballman via cfe-commits]

Author: Aaron Ballman
Date: 2023-03-09T08:01:55-05:00
New Revision: 9aa54db44c5b057669d507c0cd4689062750487e

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

LOG: Revert "Disable test for __builtin_set_flt_rounds to avoid breaking PPC 
buildbot"

This reverts commit d4fcc692ee15b2c6d249daabe31208d6a5afa025.

(This change removed all test coverage from a previous change, also to be 
reverted.)

Added: 


Modified: 
clang/test/CodeGen/builtins.c

Removed: 




diff  --git a/clang/test/CodeGen/builtins.c b/clang/test/CodeGen/builtins.c
index 1281c5e13ae3e..d523d3100c04c 100644
--- a/clang/test/CodeGen/builtins.c
+++ b/clang/test/CodeGen/builtins.c
@@ -278,6 +278,8 @@ void test_float_builtins(__fp16 *H, float F, double D, long 
double LD) {
 
   res = __builtin_flt_rounds();
   // CHECK: call i32 @llvm.get.rounding(
+  __builtin_set_flt_rounds(1);
+  // CHECK: call void @llvm.set.rounding(i32 1)
 }
 
 // CHECK-LABEL: define{{.*}} void @test_float_builtin_ops



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

[clang] feec067 - Revert "Add __builtin_set_flt_rounds"

[Aaron Ballman via cfe-commits]

Author: Aaron Ballman
Date: 2023-03-09T08:02:31-05:00
New Revision: feec067982abd806c2cf444956446b604bf7cf4c

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

LOG: Revert "Add __builtin_set_flt_rounds"

This reverts commit 24b823554acd25009731b2519880aa18c7263550.

These changes broke the PPC build bot.

Added: 


Modified: 
clang/include/clang/Basic/Builtins.def
clang/lib/CodeGen/CGBuiltin.cpp
clang/lib/Sema/SemaChecking.cpp
clang/test/CodeGen/builtins.c

Removed: 




diff  --git a/clang/include/clang/Basic/Builtins.def 
b/clang/include/clang/Basic/Builtins.def
index e7c483bee7193..478eb59bb7712 100644
--- a/clang/include/clang/Basic/Builtins.def
+++ b/clang/include/clang/Basic/Builtins.def
@@ -397,7 +397,6 @@ BUILTIN(__builtin_truncf16, "hh", "Fnc")
 
 // Access to floating point environment
 BUILTIN(__builtin_flt_rounds, "i", "n")
-BUILTIN(__builtin_set_flt_rounds, "vi", "n")
 
 // C99 complex builtins
 BUILTIN(__builtin_cabs, "dXd", "Fne")

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index a8e937ad66c18..cea4727422c0b 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -3375,14 +3375,6 @@ RValue CodeGenFunction::EmitBuiltinExpr(const GlobalDecl 
GD, unsigned BuiltinID,
 return RValue::get(Result);
   }
 
-  case Builtin::BI__builtin_set_flt_rounds: {
-Function *F = CGM.getIntrinsic(Intrinsic::set_rounding);
-
-Value *V = EmitScalarExpr(E->getArg(0));
-Builder.CreateCall(F, V);
-return RValue::get(nullptr);
-  }
-
   case Builtin::BI__builtin_fpclassify: {
 CodeGenFunction::CGFPOptionsRAII FPOptsRAII(*this, E);
 // FIXME: for strictfp/IEEE-754 we need to not trap on SNaN here.

diff  --git a/clang/lib/Sema/SemaChecking.cpp b/clang/lib/Sema/SemaChecking.cpp
index 2e7a2e3c57594..485351f157fde 100644
--- a/clang/lib/Sema/SemaChecking.cpp
+++ b/clang/lib/Sema/SemaChecking.cpp
@@ -2146,14 +2146,6 @@ Sema::CheckBuiltinFunctionCall(FunctionDecl *FDecl, 
unsigned BuiltinID,
   return ExprError();
 break;
 
-  case Builtin::BI__builtin_set_flt_rounds:
-if (CheckBuiltinTargetInSupported(*this, BuiltinID, TheCall,
-  {llvm::Triple::x86, llvm::Triple::x86_64,
-   llvm::Triple::arm, llvm::Triple::thumb,
-   llvm::Triple::aarch64}))
-  return ExprError();
-break;
-
   case Builtin::BI__builtin_isgreater:
   case Builtin::BI__builtin_isgreaterequal:
   case Builtin::BI__builtin_isless:

diff  --git a/clang/test/CodeGen/builtins.c b/clang/test/CodeGen/builtins.c
index d523d3100c04c..1281c5e13ae3e 100644
--- a/clang/test/CodeGen/builtins.c
+++ b/clang/test/CodeGen/builtins.c
@@ -278,8 +278,6 @@ void test_float_builtins(__fp16 *H, float F, double D, long 
double LD) {
 
   res = __builtin_flt_rounds();
   // CHECK: call i32 @llvm.get.rounding(
-  __builtin_set_flt_rounds(1);
-  // CHECK: call void @llvm.set.rounding(i32 1)
 }
 
 // CHECK-LABEL: define{{.*}} void @test_float_builtin_ops



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

Re: [clang] d4fcc69 - Disable test for __builtin_set_flt_rounds to avoid breaking PPC buildbot

[Aaron Ballman via cfe-commits]

On Wed, Mar 8, 2023 at 11:57 PM via cfe-commits
 wrote:
>
>
> Author: jinge90
> Date: 2023-03-09T13:14:36+08:00
> New Revision: d4fcc692ee15b2c6d249daabe31208d6a5afa025
>
> URL: 
> https://github.com/llvm/llvm-project/commit/d4fcc692ee15b2c6d249daabe31208d6a5afa025
> DIFF: 
> https://github.com/llvm/llvm-project/commit/d4fcc692ee15b2c6d249daabe31208d6a5afa025.diff
>
> LOG: Disable test for __builtin_set_flt_rounds to avoid breaking PPC buildbot

Hello! I reverted this change along with
24b823554acd25009731b2519880aa18c7263550 because this follow-up
removed all test coverage from the original change. Typically, we
don't disable tests in response to failing bots; it's too easy for the
test to accidentally never get enabled again, and then we have both a
bug and a lack of test coverage. Instead, either the breakage is fixed
in a quick follow-up or the original patch should be reverted. Sorry
for any hassle from the reverts!

~Aaron

>
> Signed-off-by: jinge90 
>
> Added:
>
>
> Modified:
> clang/test/CodeGen/builtins.c
>
> Removed:
>
>
>
> 
> diff  --git a/clang/test/CodeGen/builtins.c b/clang/test/CodeGen/builtins.c
> index d523d3100c04c..1281c5e13ae3e 100644
> --- a/clang/test/CodeGen/builtins.c
> +++ b/clang/test/CodeGen/builtins.c
> @@ -278,8 +278,6 @@ void test_float_builtins(__fp16 *H, float F, double D, 
> long double LD) {
>
>res = __builtin_flt_rounds();
>// CHECK: call i32 @llvm.get.rounding(
> -  __builtin_set_flt_rounds(1);
> -  // CHECK: call void @llvm.set.rounding(i32 1)
>  }
>
>  // CHECK-LABEL: define{{.*}} void @test_float_builtin_ops
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D142914: [MLIR][OpenMP] Added OMPIRBuilder support for Target Data directives.

[Akash Banerjee via Phabricator via cfe-commits]

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



Comment at: 
mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp:1357
+/// Process MapOperands for Target Data directives.
+static LogicalResult processMapOperand(
+llvm::IRBuilderBase &builder, LLVM::ModuleTranslation &moduleTranslation,

kiranchandramohan wrote:
> TIFitis wrote:
> > kiranchandramohan wrote:
> > > TIFitis wrote:
> > > > kiranchandramohan wrote:
> > > > > Isn't it possible to sink this whole function into the 
> > > > > OpenMPIRBuilder by passing it a list of `mapOpValue` and 
> > > > > `mapTypeFlags`?
> > > > > `lvm::Value *mapOpValue = moduleTranslation.lookupValue(mapOp);`
> > > > > 
> > > > > Did i miss something? Or is this in anticipation of more processing 
> > > > > required for other types?
> > > > I'm not fully sure but we might need more MLIR related things when 
> > > > supporting types other than LLVMPointerType. Also there is a call to 
> > > > mlir::LLVM::createMappingInformation.
> > > > 
> > > > I guess it might still be possible to move most of it to the IRBuilder, 
> > > > would you like me to do that?
> > > Callbacks are useful when there is frontend-specific handling that is 
> > > required. If more types require to be handled then it is better to have 
> > > the callback. We can revisit this after all types are handled. I assume, 
> > > the current handling is for scalars and arrays of known-size.
> > I am a novice at FORTRAN so I'm not aware of all  the types and scenarios.
> > 
> > I've tested the following cases and they work end-to-end:
> > 
> > **Fortran:**
> > ```
> > subroutine openmp_target_data_region(a)
> > real :: a(*)
> > integer :: b(1024)
> > character :: c
> > integer, pointer :: p
> > !$omp target enter data map(to: a, b, c, p)
> > end subroutine openmp_target_data_region
> > ```
> > 
> > **LLVM IR(** `flang-new -fc1 -emit-llvm -fopenmp test.f90 -o test.ll`** ):**
> > 
> > ```
> > ; ModuleID = 'FIRModule'
> > source_filename = "FIRModule"
> > target datalayout = 
> > "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
> > target triple = "x86_64-unknown-linux-gnu"
> > 
> > %struct.ident_t = type { i32, i32, i32, i32, ptr }
> > 
> > @0 = private unnamed_addr constant [13 x i8] c"loc(unknown)\00", align 1
> > @1 = private unnamed_addr constant [56 x i8] 
> > c";/home/akash/Documents/scratch/test2.f90;unknown;3;16;;\00", align 1
> > @2 = private unnamed_addr constant [56 x i8] 
> > c";/home/akash/Documents/scratch/test2.f90;unknown;4;18;;\00", align 1
> > @3 = private unnamed_addr constant [56 x i8] 
> > c";/home/akash/Documents/scratch/test2.f90;unknown;5;25;;\00", align 1
> > @4 = private unnamed_addr constant [23 x i8] c";unknown;unknown;0;0;;\00", 
> > align 1
> > @5 = private unnamed_addr constant %struct.ident_t { i32 0, i32 2, i32 0, 
> > i32 22, ptr @4 }, align 8
> > @.offload_maptypes = private unnamed_addr constant [4 x i64] [i64 1, i64 1, 
> > i64 1, i64 1]
> > @.offload_mapnames = private constant [4 x ptr] [ptr @0, ptr @1, ptr @2, 
> > ptr @3]
> > 
> > declare ptr @malloc(i64)
> > 
> > declare void @free(ptr)
> > 
> > define void @openmp_target_data_region_(ptr %0) {
> >   %2 = alloca [4 x ptr], align 8
> >   %3 = alloca [4 x ptr], align 8
> >   %4 = alloca [4 x i64], align 8
> >   %5 = alloca [1024 x i32], i64 1, align 4
> >   %6 = alloca [1 x i8], i64 1, align 1
> >   %7 = alloca { ptr, i64, i32, i8, i8, i8, i8 }, i64 1, align 8
> >   %8 = alloca ptr, i64 1, align 8
> >   store ptr null, ptr %8, align 8
> >   br label %entry
> > 
> > entry:; preds = %1
> >   %9 = getelementptr inbounds [4 x ptr], ptr %2, i32 0, i32 0
> >   store ptr %0, ptr %9, align 8
> >   %10 = getelementptr inbounds [4 x ptr], ptr %3, i32 0, i32 0
> >   store ptr %0, ptr %10, align 8
> >   %11 = getelementptr inbounds [4 x i64], ptr %4, i32 0, i32 0
> >   store i64 ptrtoint (ptr getelementptr (ptr, ptr null, i32 1) to i64), ptr 
> > %11, align 8
> >   %12 = getelementptr inbounds [4 x ptr], ptr %2, i32 0, i32 1
> >   store ptr %5, ptr %12, align 8
> >   %13 = getelementptr inbounds [4 x ptr], ptr %3, i32 0, i32 1
> >   store ptr %5, ptr %13, align 8
> >   %14 = getelementptr inbounds [4 x i64], ptr %4, i32 0, i32 1
> >   store i64 ptrtoint (ptr getelementptr (ptr, ptr null, i32 1) to i64), ptr 
> > %14, align 8
> >   %15 = getelementptr inbounds [4 x ptr], ptr %2, i32 0, i32 2
> >   store ptr %6, ptr %15, align 8
> >   %16 = getelementptr inbounds [4 x ptr], ptr %3, i32 0, i32 2
> >   store ptr %6, ptr %16, align 8
> >   %17 = getelementptr inbounds [4 x i64], ptr %4, i32 0, i32 2
> >   store i64 ptrtoint (ptr getelementptr (ptr, ptr null, i32 1) to i64), ptr 
> > %17, align 8
> >   %18 = getelementptr inbounds [4 x ptr], ptr %2, i32 0, i32 3
> >   store ptr %7, ptr %18, align 8
> >   %19 = getelementptr inbounds [4 x ptr], ptr %3, i32 0, i32 3
> >   store ptr 

[PATCH] D130303: Handle template parameter-dependent bit field widths in libclang

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman accepted this revision.
aaron.ballman added a comment.

Found some minor cleanups but otherwise LGTM (feel free to fix when landing if 
you'd like).




Comment at: clang/tools/libclang/CXType.cpp:380-384
 if (const FieldDecl *FD = dyn_cast_or_null(D)) {
   if (FD->isBitField())
+return 1;
+}
+  }

The conversion is always going to do the right thing: 
https://eel.is/c++draft/conv#integral-2.sentence-2



Comment at: clang/tools/libclang/CXType.cpp:395
+
+if (const FieldDecl *FD = dyn_cast_or_null(D)) {
+  if (FD->isBitField() && !FD->getBitWidth()->isValueDependent())





Comment at: clang/tools/libclang/CXType.cpp:13
 
+#include "CXType.h"
 #include "CIndexer.h"

dexonsmith wrote:
> vedgy wrote:
> > collinbaker wrote:
> > > vedgy wrote:
> > > > I guess //clang-format// did this include reordering. But it certainly 
> > > > looks out of place and the include order becomes wrong. So I think it 
> > > > should be reverted.
> > > I don't agree, it's pretty standard for a source file to have its 
> > > associated header include at the top.
> > You are right, I haven't realized the header-source association. The diff 
> > is still unrelated to the patch. But I'm no longer sure what's right, so 
> > won't insist on anything.
> This is correct behaviour from clang-format.
> 
> Given that there were no functional changes to includes, typically we’d omit 
> clang-format cleanups. (I know there was a change below originally, but that 
> was reverted.)
> 
> I’m fine leaving the header clean-up in, or separating it out to different 
> NFC commit (ideal; could be done when pushing), or skipping it entirely. 
+1 -- FWIW, we usually ask for formatting changes to be separated out into a 
separate commit because it makes git blame more useful when we're doing code 
archeology later, but this is minor enough to be unlikely to cause an issue, so 
I don't feel strongly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D130303

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

[PATCH] D142914: [MLIR][OpenMP] Added OMPIRBuilder support for Target Data directives.

[Akash Banerjee via Phabricator via cfe-commits]

TIFitis updated this revision to Diff 503741.
TIFitis added a comment.

Added names for offload mapper variables.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D142914

Files:
  clang/lib/CodeGen/CGOpenMPRuntime.cpp
  llvm/include/llvm/Frontend/OpenMP/OMPConstants.h
  llvm/include/llvm/Frontend/OpenMP/OMPIRBuilder.h
  llvm/lib/Frontend/OpenMP/OMPIRBuilder.cpp
  llvm/unittests/Frontend/OpenMPIRBuilderTest.cpp
  mlir/include/mlir/Target/LLVMIR/Dialect/OpenMPCommon.h
  mlir/lib/Target/LLVMIR/CMakeLists.txt
  mlir/lib/Target/LLVMIR/Dialect/OpenACC/OpenACCToLLVMIRTranslation.cpp
  mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp
  mlir/lib/Target/LLVMIR/Dialect/OpenMPCommon.cpp
  mlir/test/Target/LLVMIR/omptarget-llvm.mlir

Index: mlir/test/Target/LLVMIR/omptarget-llvm.mlir
===
--- /dev/null
+++ mlir/test/Target/LLVMIR/omptarget-llvm.mlir
@@ -0,0 +1,176 @@
+// RUN: mlir-translate -mlir-to-llvmir -split-input-file %s | FileCheck %s
+
+llvm.func @_QPopenmp_target_data() {
+  %0 = llvm.mlir.constant(1 : i64) : i64
+  %1 = llvm.alloca %0 x i32 {bindc_name = "i", in_type = i32, operand_segment_sizes = array, uniq_name = "_QFopenmp_target_dataEi"} : (i64) -> !llvm.ptr
+  omp.target_data   map((tofrom -> %1 : !llvm.ptr)) {
+%2 = llvm.mlir.constant(99 : i32) : i32
+llvm.store %2, %1 : !llvm.ptr
+omp.terminator
+  }
+  llvm.return
+}
+
+// CHECK: @.offload_maptypes = private unnamed_addr constant [1 x i64] [i64 3]
+// CHECK-LABEL: define void @_QPopenmp_target_data() {
+// CHECK: %[[VAL_0:.*]] = alloca [1 x ptr], align 8
+// CHECK: %[[VAL_1:.*]] = alloca [1 x ptr], align 8
+// CHECK: %[[VAL_2:.*]] = alloca [1 x i64], align 8
+// CHECK: %[[VAL_3:.*]] = alloca i32, i64 1, align 4
+// CHECK: br label %[[VAL_4:.*]]
+// CHECK:   entry:; preds = %[[VAL_5:.*]]
+// CHECK: %[[VAL_6:.*]] = getelementptr inbounds [1 x ptr], ptr %[[VAL_0]], i32 0, i32 0
+// CHECK: store ptr %[[VAL_3]], ptr %[[VAL_6]], align 8
+// CHECK: %[[VAL_7:.*]] = getelementptr inbounds [1 x ptr], ptr %[[VAL_1]], i32 0, i32 0
+// CHECK: store ptr %[[VAL_3]], ptr %[[VAL_7]], align 8
+// CHECK: %[[VAL_8:.*]] = getelementptr inbounds [1 x i64], ptr %[[VAL_2]], i32 0, i32 0
+// CHECK: store i64 ptrtoint (ptr getelementptr (ptr, ptr null, i32 1) to i64), ptr %[[VAL_8]], align 4
+// CHECK: %[[VAL_9:.*]] = getelementptr inbounds [1 x ptr], ptr %[[VAL_0]], i32 0, i32 0
+// CHECK: %[[VAL_10:.*]] = getelementptr inbounds [1 x ptr], ptr %[[VAL_1]], i32 0, i32 0
+// CHECK: %[[VAL_11:.*]] = getelementptr inbounds [1 x i64], ptr %[[VAL_2]], i32 0, i32 0
+// CHECK: call void @__tgt_target_data_begin_mapper(ptr @2, i64 -1, i32 1, ptr %[[VAL_9]], ptr %[[VAL_10]], ptr %[[VAL_11]], ptr @.offload_maptypes, ptr @.offload_mapnames, ptr null)
+// CHECK: br label %[[VAL_12:.*]]
+// CHECK:   omp.data.region:  ; preds = %[[VAL_4]]
+// CHECK: store i32 99, ptr %[[VAL_3]], align 4
+// CHECK: br label %[[VAL_13:.*]]
+// CHECK:   omp.region.cont:  ; preds = %[[VAL_12]]
+// CHECK: %[[VAL_14:.*]] = getelementptr inbounds [1 x ptr], ptr %[[VAL_0]], i32 0, i32 0
+// CHECK: %[[VAL_15:.*]] = getelementptr inbounds [1 x ptr], ptr %[[VAL_1]], i32 0, i32 0
+// CHECK: %[[VAL_16:.*]] = getelementptr inbounds [1 x i64], ptr %[[VAL_2]], i32 0, i32 0
+// CHECK: call void @__tgt_target_data_end_mapper(ptr @2, i64 -1, i32 1, ptr %[[VAL_14]], ptr %[[VAL_15]], ptr %[[VAL_16]], ptr @.offload_maptypes, ptr @.offload_mapnames, ptr null)
+// CHECK: ret void
+
+// -
+
+llvm.func @_QPopenmp_target_data_region(%1 : !llvm.ptr>) {
+  omp.target_data   map((from -> %1 : !llvm.ptr>)) {
+%2 = llvm.mlir.constant(99 : i32) : i32
+%3 = llvm.mlir.constant(1 : i64) : i64
+%4 = llvm.mlir.constant(1 : i64) : i64
+%5 = llvm.mlir.constant(0 : i64) : i64
+%6 = llvm.getelementptr %1[0, %5] : (!llvm.ptr>, i64) -> !llvm.ptr
+llvm.store %2, %6 : !llvm.ptr
+omp.terminator
+  }
+  llvm.return
+}
+
+// CHECK: @.offload_maptypes = private unnamed_addr constant [1 x i64] [i64 2]
+// CHECK-LABEL: define void @_QPopenmp_target_data_region
+// CHECK: (ptr %[[ARG_0:.*]]) {
+// CHECK: %[[VAL_0:.*]] = alloca [1 x ptr], align 8
+// CHECK: %[[VAL_1:.*]] = alloca [1 x ptr], align 8
+// CHECK: %[[VAL_2:.*]] = alloca [1 x i64], align 8
+// CHECK: br label %[[VAL_3:.*]]
+// CHECK:   entry:; preds = %[[VAL_4:.*]]
+// CHECK: %[[VAL_5:.*]] = getelementptr inbounds [1 x ptr], ptr %[[VAL_0]], i32 0, i32 0
+// CHECK: store ptr %[

[PATCH] D145369: Emit const globals with constexpr destructor as constant LLVM values

[Ilya Biryukov via Phabricator via cfe-commits]

ilya-biryukov added a comment.

I don't have a lot of experience in codegen, so will let Aaron and Richard do 
the review.

However, still wanted to share one observation. The actual check that avoids 
emitting the destructors for variables seems more involved than just checking 
if the destructor is `constexpr`.
Is it safe to rely solely on the type for codegen? E.g. I would have expected 
checks that look at `HasConstantDestruction` for variables with non-trivial 
constructors.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145369

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

[PATCH] D143418: [libclang] Add API to override preamble storage path

[Igor Kushnir via Phabricator via cfe-commits]

vedgy marked an inline comment as not done.
vedgy added inline comments.



Comment at: clang/include/clang-c/Index.h:365
+   */
+  int ExcludeDeclarationsFromPCH : 1;
+  /**

vedgy wrote:
> Assigning `true` to `int : 1` bit-fields in C++ code produces a GCC warning:
> ```
> warning: overflow in conversion from ‘int’ to ‘signed char:1’ changes value 
> from ‘1’ to ‘-1’ [-Woverflow]
> ```
> 
> Following a suggestion in a comment to 
> https://github.com/llvm/llvm-project/issues/53253, I replaced this `int` with 
> `unsigned` and the warning disappeared. Same for `int DisplayDiagnostics : 
> 1`. Should this type change be included in the upcoming 
> `StorePreamblesInMemory` revision?
Or should this change be done in a separate revision, on which the 
`StorePreamblesInMemory` would be based?

I also implemented two other changes to the `struct CXIndexOptions` (mostly 
documentation/comments). Should these all be in separate revisions or combined 
into one?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143418

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

[PATCH] D143418: [libclang] Add API to override preamble storage path

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D143418#4175887 , @vedgy wrote:

> In D143418#4175628 , @aaron.ballman 
> wrote:
>
>> Hmmm, don't relaxed loads and stores still have the potential to be racey? I 
>> thought you needed a release on the store and an acquire on the load (or 
>> sequential consistency), but this is definitely not my area of expertise.
>
> The acquire/release semantics is needed if the atomic variable guards access 
> to another non-atomic variable or the atomic pointer guards access to its 
> non-atomic pointed-to value. The relaxed order means no guarantees about this 
> variable's interaction with other atomic or non-atomic variables. But even 
> the relaxed order prevents data races on the variable itself, which is 
> sufficient here.

Ah, thank you for the explanation!

>>> The option can also be added to `CXIndexOptions` in order to allow setting 
>>> its initial value reliably (not worrying whether it could be used before 
>>> the setter gets called after index construction).
>>>
>>> Is adding both the setter and the `CXIndexOptions` member OK or would you 
>>> prefer only one of these two?
>>
>> It's a bit odd to me that we're deprecating the global option setters to 
>> turn around and add a new global option setter. The old interfaces are not 
>> thread safe and the new one is thread safe, so I get why the desire exists 
>> and is reasonable, but (personally) I'd like to get rid of the option state 
>> setters entirely someday.
>
> I also thought about the deprecated old interfaces today. 
> `clang_CXIndex_setGlobalOptions()` could be undeprecated by similarly making 
> `CIndexer::Options` atomic. Safely setting `std::string` members would 
> require a mutex.

Yeah, we could make it thread safe, but I still don't think setters are a good 
design approach. To me, these global options should be ones that are set when 
creating the index and be immutable from there on. (This mirrors how language 
options work in Clang itself -- we have a ton of language options, but they get 
set up by the compiler frontend and are (generally) immutable from there on. 
When we need to allow for different options, the interface accepts a 
`LangOptions` object, as in: 
https://github.com/llvm/llvm-project/blob/main/clang/include/clang/Analysis/CFG.h#L1081)

>> What I was envisioning was that the index creation would get global options 
>> and if we wanted per-TU options, we'd add an interface akin to 
>> `clang_parseTranslationUnit()` which takes another options struct for per-TU 
>> options. (Perhaps the default values for those options come from the global 
>> options -- e.g., `DisplayDiagnostics` is set at the global level but could 
>> be overridden for a single TU). Do you have thoughts about that approach?
>
> This would allow to specify whether to store each individual preamble in 
> memory, which is more specific than necessary for my use case. This would 
> shift the burden of passing around the `StorePreamblesInMemory` value to 
> libclang users. Certainly more difficult to implement both in libclang and in 
> KDevelop.
>
> Advantages of getting rid of the option state setters entirely and passing 
> options to per-TU APIs:
>
> 1. More flexibility (per-TU option specification).
> 2. Possibly more efficient (no need for atomics and mutexes).
> 3. Clearer to API users which TUs the modified options apply to and which TUs 
> (created earlier) keep the original options.
> 4. Less risk of inconsistencies and bugs in libclang. Such as somehow passing 
> a new option value to an old TU with unpredictable consequences.
>
> Do the listed advantages explain your preference?

Yes, thank you! #3/#4 are really the biggest advantages, to me. By passing in 
the options explicitly to the TU instead of having setters, we reduce the 
complexity of the interface because it no longer becomes possible for an option 
to change mid-parse. This in turn makes testing far easier because we don't 
have to come up with test coverage for "what if the option was X and it got 
switched to Y before calling this function" kind of situations.

> I am not sure what I would prefer from a hypothetical standpoint of a 
> libclang maintainer. And you definitely have more experience in this area. So 
> I won't argue for the index option state setters.
>
> I'll probably implement the uncontroversial `CXIndexOptions` member first. 
> And then, if I think implementing it is worth the effort, continue discussing 
> `clang_parseTranslationUnitWithOptions()`.

I think that's a good approach. You are a consumer of libclang, so having your 
perspective about what makes the interface easier for you to use is also really 
helpful in figuring out a good design. Thank you for being willing to share 
your experiences with using libclang on KDevelop!




Comment at: clang/include/clang-c/Index.h:365
+   */
+  int ExcludeDeclarationsFromPCH : 1;
+  

[PATCH] D143418: [libclang] Add API to override preamble storage path

[Igor Kushnir via Phabricator via cfe-commits]

vedgy marked an inline comment as not done.
vedgy added inline comments.



Comment at: clang/include/clang-c/Index.h:365
+   */
+  int ExcludeDeclarationsFromPCH : 1;
+  /**

vedgy wrote:
> aaron.ballman wrote:
> > vedgy wrote:
> > > Assigning `true` to `int : 1` bit-fields in C++ code produces a GCC 
> > > warning:
> > > ```
> > > warning: overflow in conversion from ‘int’ to ‘signed char:1’ changes 
> > > value from ‘1’ to ‘-1’ [-Woverflow]
> > > ```
> > > 
> > > Following a suggestion in a comment to 
> > > https://github.com/llvm/llvm-project/issues/53253, I replaced this `int` 
> > > with `unsigned` and the warning disappeared. Same for `int 
> > > DisplayDiagnostics : 1`. Should this type change be included in the 
> > > upcoming `StorePreamblesInMemory` revision?
> > > Assigning true to int : 1 bit-fields in C++ code produces a GCC warning:
> > >
> > > `warning: overflow in conversion from ‘int’ to ‘signed char:1’ changes 
> > > value from ‘1’ to ‘-1’ [-Woverflow]`
> > 
> > Ugh, I forgot that the C standard allows that. (C2x 6.7.2.1p12: "A 
> > bit-field member is interpreted as having a signed or unsigned integer type 
> > consisting of the specified number of bits" -- GCC decided to turn our 
> > `int` into `signed char` which is nice for packing data together, but not 
> > as nice when it comes to boolean-like bit-fields.)
> > 
> > > Should this type change be included in the upcoming 
> > > StorePreamblesInMemory revision?
> > 
> > It'd probably be the cleanest to fix that separately. Given that it's NFC 
> > and you don't have commit privileges, I can make the change on your behalf 
> > and land it today if that's what you'd like.
> Or should this change be done in a separate revision, on which the 
> `StorePreamblesInMemory` would be based?
> 
> I also implemented two other changes to the `struct CXIndexOptions` (mostly 
> documentation/comments). Should these all be in separate revisions or 
> combined into one?
Yes, I agree that such changes should be in separate commits. But I don't want 
to burden you with committing them all separately. So if 4 is too much, I can 
request the commit access for myself. If this burden is not too heavy, I am 
fine with you making the change on my behalf.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143418

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

[PATCH] D142914: [MLIR][OpenMP] Added OMPIRBuilder support for Target Data directives.

[Akash Banerjee via Phabricator via cfe-commits]

TIFitis added inline comments.



Comment at: 
mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp:1357
+/// Process MapOperands for Target Data directives.
+static LogicalResult processMapOperand(
+llvm::IRBuilderBase &builder, LLVM::ModuleTranslation &moduleTranslation,

TIFitis wrote:
> kiranchandramohan wrote:
> > TIFitis wrote:
> > > kiranchandramohan wrote:
> > > > TIFitis wrote:
> > > > > kiranchandramohan wrote:
> > > > > > Isn't it possible to sink this whole function into the 
> > > > > > OpenMPIRBuilder by passing it a list of `mapOpValue` and 
> > > > > > `mapTypeFlags`?
> > > > > > `lvm::Value *mapOpValue = moduleTranslation.lookupValue(mapOp);`
> > > > > > 
> > > > > > Did i miss something? Or is this in anticipation of more processing 
> > > > > > required for other types?
> > > > > I'm not fully sure but we might need more MLIR related things when 
> > > > > supporting types other than LLVMPointerType. Also there is a call to 
> > > > > mlir::LLVM::createMappingInformation.
> > > > > 
> > > > > I guess it might still be possible to move most of it to the 
> > > > > IRBuilder, would you like me to do that?
> > > > Callbacks are useful when there is frontend-specific handling that is 
> > > > required. If more types require to be handled then it is better to have 
> > > > the callback. We can revisit this after all types are handled. I 
> > > > assume, the current handling is for scalars and arrays of known-size.
> > > I am a novice at FORTRAN so I'm not aware of all  the types and scenarios.
> > > 
> > > I've tested the following cases and they work end-to-end:
> > > 
> > > **Fortran:**
> > > ```
> > > subroutine openmp_target_data_region(a)
> > > real :: a(*)
> > > integer :: b(1024)
> > > character :: c
> > > integer, pointer :: p
> > > !$omp target enter data map(to: a, b, c, p)
> > > end subroutine openmp_target_data_region
> > > ```
> > > 
> > > **LLVM IR(** `flang-new -fc1 -emit-llvm -fopenmp test.f90 -o test.ll`** 
> > > ):**
> > > 
> > > ```
> > > ; ModuleID = 'FIRModule'
> > > source_filename = "FIRModule"
> > > target datalayout = 
> > > "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
> > > target triple = "x86_64-unknown-linux-gnu"
> > > 
> > > %struct.ident_t = type { i32, i32, i32, i32, ptr }
> > > 
> > > @0 = private unnamed_addr constant [13 x i8] c"loc(unknown)\00", align 1
> > > @1 = private unnamed_addr constant [56 x i8] 
> > > c";/home/akash/Documents/scratch/test2.f90;unknown;3;16;;\00", align 1
> > > @2 = private unnamed_addr constant [56 x i8] 
> > > c";/home/akash/Documents/scratch/test2.f90;unknown;4;18;;\00", align 1
> > > @3 = private unnamed_addr constant [56 x i8] 
> > > c";/home/akash/Documents/scratch/test2.f90;unknown;5;25;;\00", align 1
> > > @4 = private unnamed_addr constant [23 x i8] 
> > > c";unknown;unknown;0;0;;\00", align 1
> > > @5 = private unnamed_addr constant %struct.ident_t { i32 0, i32 2, i32 0, 
> > > i32 22, ptr @4 }, align 8
> > > @.offload_maptypes = private unnamed_addr constant [4 x i64] [i64 1, i64 
> > > 1, i64 1, i64 1]
> > > @.offload_mapnames = private constant [4 x ptr] [ptr @0, ptr @1, ptr @2, 
> > > ptr @3]
> > > 
> > > declare ptr @malloc(i64)
> > > 
> > > declare void @free(ptr)
> > > 
> > > define void @openmp_target_data_region_(ptr %0) {
> > >   %2 = alloca [4 x ptr], align 8
> > >   %3 = alloca [4 x ptr], align 8
> > >   %4 = alloca [4 x i64], align 8
> > >   %5 = alloca [1024 x i32], i64 1, align 4
> > >   %6 = alloca [1 x i8], i64 1, align 1
> > >   %7 = alloca { ptr, i64, i32, i8, i8, i8, i8 }, i64 1, align 8
> > >   %8 = alloca ptr, i64 1, align 8
> > >   store ptr null, ptr %8, align 8
> > >   br label %entry
> > > 
> > > entry:; preds = %1
> > >   %9 = getelementptr inbounds [4 x ptr], ptr %2, i32 0, i32 0
> > >   store ptr %0, ptr %9, align 8
> > >   %10 = getelementptr inbounds [4 x ptr], ptr %3, i32 0, i32 0
> > >   store ptr %0, ptr %10, align 8
> > >   %11 = getelementptr inbounds [4 x i64], ptr %4, i32 0, i32 0
> > >   store i64 ptrtoint (ptr getelementptr (ptr, ptr null, i32 1) to i64), 
> > > ptr %11, align 8
> > >   %12 = getelementptr inbounds [4 x ptr], ptr %2, i32 0, i32 1
> > >   store ptr %5, ptr %12, align 8
> > >   %13 = getelementptr inbounds [4 x ptr], ptr %3, i32 0, i32 1
> > >   store ptr %5, ptr %13, align 8
> > >   %14 = getelementptr inbounds [4 x i64], ptr %4, i32 0, i32 1
> > >   store i64 ptrtoint (ptr getelementptr (ptr, ptr null, i32 1) to i64), 
> > > ptr %14, align 8
> > >   %15 = getelementptr inbounds [4 x ptr], ptr %2, i32 0, i32 2
> > >   store ptr %6, ptr %15, align 8
> > >   %16 = getelementptr inbounds [4 x ptr], ptr %3, i32 0, i32 2
> > >   store ptr %6, ptr %16, align 8
> > >   %17 = getelementptr inbounds [4 x i64], ptr %4, i32 0, i32 2
> > >   store i64 ptrtoint (ptr getelementptr (ptr, ptr null, i32 1) to i64), 
> > > ptr %17, align 8
> > >

[PATCH] D145369: Emit const globals with constexpr destructor as constant LLVM values

[Hans Wennborg via Phabricator via cfe-commits]

hans added a comment.

In D145369#4181296 , @ilya-biryukov 
wrote:

> I don't have a lot of experience in codegen, so will let Aaron and Richard do 
> the review.

Thanks for checking! I don't have a lot of experience here either, so any 
review is much appreciated.

> However, still wanted to share one observation. The actual check that avoids 
> emitting the destructors for variables seems more involved than just checking 
> if the destructor is `constexpr`.
> Is it safe to rely solely on the type for codegen? E.g. I would have expected 
> checks that look at `HasConstantDestruction` for variables with non-trivial 
> constructors.

Right, codegen is also factoring in the check about emitting destructors when 
deciding about marking the LLVM value constant or not:

  in CodeGenModule::EmitGlobalVarDefinition()
  
bool NeedsGlobalDtor =
!IsDefinitionAvailableExternally &&
D->needsDestruction(getContext()) == QualType::DK_cxx_destructor;
  
  ...
  
// If it is safe to mark the global 'constant', do so now.
GV->setConstant(!NeedsGlobalCtor && !NeedsGlobalDtor &&
isTypeConstant(D->getType(), true));

So I *think* this is correct, and that the `hasConstexprDestructor()` case was 
just missing from `isTypeConstant()` because constexpr destructors were added 
later. But again, not super familiar with this stuff :)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145369

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

[PATCH] D145034: [Clang][Sema] Preparations to fix handling of out-of-line definitions of constrained templates

[Alexander Shaposhnikov via Phabricator via cfe-commits]

alexander-shaposhnikov updated this revision to Diff 503750.
alexander-shaposhnikov added a comment.

Address comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145034

Files:
  clang/include/clang/Parse/Parser.h
  clang/include/clang/Sema/DeclSpec.h
  clang/lib/Parse/ParseDecl.cpp
  clang/lib/Parse/ParseDeclCXX.cpp
  clang/lib/Sema/SemaCXXScopeSpec.cpp
  
clang/test/CXX/temp/temp.decls/temp.class.spec/temp.class.spec.mfunc/p1-neg.cpp
  clang/test/SemaTemplate/concepts-out-of-line-def.cpp

Index: clang/test/SemaTemplate/concepts-out-of-line-def.cpp
===
--- /dev/null
+++ clang/test/SemaTemplate/concepts-out-of-line-def.cpp
@@ -0,0 +1,129 @@
+// RUN: %clang_cc1 -std=c++20 -verify %s
+// expected-no-diagnostics
+
+static constexpr int PRIMARY = 0;
+static constexpr int SPECIALIZATION_CONCEPT = 1;
+static constexpr int SPECIALIZATION_REQUIRES = 2;
+
+template 
+concept Concept = (sizeof(T) >= 2 * sizeof(int));
+
+struct XY {
+  int x;
+  int y;
+};
+
+namespace members {
+
+template  struct S {
+  static constexpr int primary();
+};
+
+template  constexpr int S::primary() {
+  return PRIMARY;
+};
+
+template  struct S {
+  static constexpr int specialization();
+};
+
+template 
+  requires(sizeof(T) == sizeof(int))
+struct S {
+  static constexpr int specialization();
+};
+
+template  constexpr int S::specialization() {
+  return SPECIALIZATION_CONCEPT;
+}
+
+template 
+  requires(sizeof(T) == sizeof(int))
+constexpr int S::specialization() {
+  return SPECIALIZATION_REQUIRES;
+}
+
+static_assert(S::primary() == PRIMARY);
+static_assert(S::specialization() == SPECIALIZATION_CONCEPT);
+static_assert(S::specialization() == SPECIALIZATION_REQUIRES);
+
+} // namespace members
+
+namespace enumerations {
+
+template  struct S {
+  enum class E : int;
+};
+
+template  enum class S::E { Value = PRIMARY };
+
+template  struct S {
+  enum class E : int;
+};
+
+template 
+enum class S::E {
+  Value = SPECIALIZATION_CONCEPT
+};
+
+template 
+  requires(sizeof(T) == sizeof(int))
+struct S {
+  enum class E : int;
+};
+
+template 
+  requires(sizeof(T) == sizeof(int))
+enum class S::E {
+  Value = SPECIALIZATION_REQUIRES
+};
+
+static_assert(static_cast(S::E::Value) == PRIMARY);
+static_assert(static_cast(S::E::Value) ==
+  SPECIALIZATION_CONCEPT);
+static_assert(static_cast(S::E::Value) ==
+  SPECIALIZATION_REQUIRES);
+
+} // namespace  enumerations
+
+namespace multiple_template_parameter_lists {
+
+template 
+struct S {
+  template 
+  static constexpr int primary(Inner);
+};
+
+template 
+template 
+constexpr int S::primary(Inner) {
+  return PRIMARY;
+};
+
+template 
+struct S {
+  template 
+  static constexpr int specialization(Inner);
+};
+
+template 
+template 
+constexpr int S::specialization(Inner) { return SPECIALIZATION_CONCEPT; }
+
+template 
+  requires(sizeof(Outer) == sizeof(int))
+struct S {
+  template 
+  static constexpr int specialization(Inner);
+};
+
+template 
+  requires(sizeof(Outer) == sizeof(int))
+template 
+constexpr int S::specialization(Inner) { return SPECIALIZATION_REQUIRES; }
+
+static_assert(S::primary("str") == PRIMARY);
+static_assert(S::specialization("str") == SPECIALIZATION_CONCEPT);
+static_assert(S::specialization("str") == SPECIALIZATION_REQUIRES);
+
+} // namespace multiple_template_parameter_lists
Index: clang/test/CXX/temp/temp.decls/temp.class.spec/temp.class.spec.mfunc/p1-neg.cpp
===
--- clang/test/CXX/temp/temp.decls/temp.class.spec/temp.class.spec.mfunc/p1-neg.cpp
+++ clang/test/CXX/temp/temp.decls/temp.class.spec/temp.class.spec.mfunc/p1-neg.cpp
@@ -3,7 +3,7 @@
 template
 struct A;
 
-template // expected-note{{previous template declaration}}
+template
 struct A {
   void f0();
   void f1();
@@ -15,11 +15,10 @@
   void g0();
 };
 
-// FIXME: We should probably give more precise diagnostics here, but the
-// diagnostics we give aren't terrible.
-// FIXME: why not point to the first parameter that's "too many"?
-template // expected-error{{too many template parameters}}
-void A::f0() { }
+// FIXME: We should produce diagnostics pointing out the
+// non-matching candidates.
+template
+void A::f0() { } // expected-error{{does not refer into a class, class template or class template partial specialization}}
 
 template
 void A::f1() { } // expected-error{{out-of-line definition}}
Index: clang/lib/Sema/SemaCXXScopeSpec.cpp
===
--- clang/lib/Sema/SemaCXXScopeSpec.cpp
+++ clang/lib/Sema/SemaCXXScopeSpec.cpp
@@ -99,34 +99,52 @@
 if (ClassTemplateDecl *ClassTemplate
   = dyn_cast_or_null(
 SpecType->getTemplateName().getAsTemplateDecl())) {
-  QualType ContextType
-= Context.getCanonicalType(QualType(SpecType, 0

[clang] dbde7cc - Switch from int to unsigned int; NFC

[Aaron Ballman via cfe-commits]

Author: Aaron Ballman
Date: 2023-03-09T09:29:00-05:00
New Revision: dbde7cc17c3a5b6a35e5ec598ba7eaba6f75d90b

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

LOG: Switch from int to unsigned int; NFC

This silences a GCC conversion diagnostic about assigning `1` to a
1-bit signed bit-field changing the value from `1` to `-1`.

Co-authored-by: Igor Kushnir 

Added: 


Modified: 
clang/include/clang-c/Index.h

Removed: 




diff  --git a/clang/include/clang-c/Index.h b/clang/include/clang-c/Index.h
index 152f65c9028e..b986d2923590 100644
--- a/clang/include/clang-c/Index.h
+++ b/clang/include/clang-c/Index.h
@@ -362,11 +362,11 @@ typedef struct CXIndexOptions {
   /**
* \see clang_createIndex()
*/
-  int ExcludeDeclarationsFromPCH : 1;
+  unsigned ExcludeDeclarationsFromPCH : 1;
   /**
* \see clang_createIndex()
*/
-  int DisplayDiagnostics : 1;
+  unsigned DisplayDiagnostics : 1;
   /**
* The path to a directory, in which to store temporary PCH files. If null or
* empty, the default system temporary directory is used. These PCH files are



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

[PATCH] D143418: [libclang] Add API to override preamble storage path

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/include/clang-c/Index.h:365
+   */
+  int ExcludeDeclarationsFromPCH : 1;
+  /**

vedgy wrote:
> vedgy wrote:
> > aaron.ballman wrote:
> > > vedgy wrote:
> > > > Assigning `true` to `int : 1` bit-fields in C++ code produces a GCC 
> > > > warning:
> > > > ```
> > > > warning: overflow in conversion from ‘int’ to ‘signed char:1’ changes 
> > > > value from ‘1’ to ‘-1’ [-Woverflow]
> > > > ```
> > > > 
> > > > Following a suggestion in a comment to 
> > > > https://github.com/llvm/llvm-project/issues/53253, I replaced this 
> > > > `int` with `unsigned` and the warning disappeared. Same for `int 
> > > > DisplayDiagnostics : 1`. Should this type change be included in the 
> > > > upcoming `StorePreamblesInMemory` revision?
> > > > Assigning true to int : 1 bit-fields in C++ code produces a GCC warning:
> > > >
> > > > `warning: overflow in conversion from ‘int’ to ‘signed char:1’ changes 
> > > > value from ‘1’ to ‘-1’ [-Woverflow]`
> > > 
> > > Ugh, I forgot that the C standard allows that. (C2x 6.7.2.1p12: "A 
> > > bit-field member is interpreted as having a signed or unsigned integer 
> > > type consisting of the specified number of bits" -- GCC decided to turn 
> > > our `int` into `signed char` which is nice for packing data together, but 
> > > not as nice when it comes to boolean-like bit-fields.)
> > > 
> > > > Should this type change be included in the upcoming 
> > > > StorePreamblesInMemory revision?
> > > 
> > > It'd probably be the cleanest to fix that separately. Given that it's NFC 
> > > and you don't have commit privileges, I can make the change on your 
> > > behalf and land it today if that's what you'd like.
> > Or should this change be done in a separate revision, on which the 
> > `StorePreamblesInMemory` would be based?
> > 
> > I also implemented two other changes to the `struct CXIndexOptions` (mostly 
> > documentation/comments). Should these all be in separate revisions or 
> > combined into one?
> Yes, I agree that such changes should be in separate commits. But I don't 
> want to burden you with committing them all separately. So if 4 is too much, 
> I can request the commit access for myself. If this burden is not too heavy, 
> I am fine with you making the change on my behalf.
No worries, this was a trivial one -- I landed it in 
dbde7cc17c3a5b6a35e5ec598ba7eaba6f75d90b, so you should be able to fetch and 
rebase on top of that.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143418

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

[PATCH] D145642: [clang-format] Annotate lambdas with requires clauses.

[Emilia Dreamer via Phabricator via cfe-commits]

rymiel updated this revision to Diff 503753.
rymiel added a comment.

Improve code flow in parseConstraintExpression


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145642

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

Index: clang/unittests/Format/TokenAnnotatorTest.cpp
===
--- clang/unittests/Format/TokenAnnotatorTest.cpp
+++ clang/unittests/Format/TokenAnnotatorTest.cpp
@@ -1263,6 +1263,102 @@
   EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
   EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
   EXPECT_TOKEN(Tokens[7], tok::l_brace, TT_LambdaLBrace);
+
+  // Lambdas with a requires-clause
+  Tokens = annotate("[]  (T t) requires Bar {}");
+  ASSERT_EQ(Tokens.size(), 18u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[10], tok::kw_requires, TT_RequiresClause);
+  EXPECT_TRUE(Tokens[14]->ClosesRequiresClause);
+  EXPECT_TOKEN(Tokens[15], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[]  (T &&t) requires Bar {}");
+  ASSERT_EQ(Tokens.size(), 19u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[8], tok::ampamp, TT_PointerOrReference);
+  EXPECT_TOKEN(Tokens[11], tok::kw_requires, TT_RequiresClause);
+  EXPECT_TRUE(Tokens[15]->ClosesRequiresClause);
+  EXPECT_TOKEN(Tokens[16], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[]  (T t) requires Foo || Bar {}");
+  ASSERT_EQ(Tokens.size(), 23u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[10], tok::kw_requires, TT_RequiresClause);
+  EXPECT_TRUE(Tokens[19]->ClosesRequiresClause);
+  EXPECT_TOKEN(Tokens[20], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[]  (T t) -> T requires Bar {}");
+  ASSERT_EQ(Tokens.size(), 20u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[10], tok::arrow, TT_LambdaArrow);
+  EXPECT_TOKEN(Tokens[12], tok::kw_requires, TT_RequiresClause);
+  EXPECT_TRUE(Tokens[16]->ClosesRequiresClause);
+  EXPECT_TOKEN(Tokens[17], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[]  requires Bar (T t) {}");
+  ASSERT_EQ(Tokens.size(), 18u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[6], tok::kw_requires, TT_RequiresClause);
+  EXPECT_TRUE(Tokens[10]->ClosesRequiresClause);
+  EXPECT_TOKEN(Tokens[15], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[]  requires Bar (T &&t) {}");
+  ASSERT_EQ(Tokens.size(), 19u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[6], tok::kw_requires, TT_RequiresClause);
+  EXPECT_TRUE(Tokens[10]->ClosesRequiresClause);
+  EXPECT_TOKEN(Tokens[13], tok::ampamp, TT_PointerOrReference);
+  EXPECT_TOKEN(Tokens[16], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[]  requires Foo || Bar (T t) {}");
+  ASSERT_EQ(Tokens.size(), 23u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[6], tok::kw_requires, TT_RequiresClause);
+  EXPECT_TRUE(Tokens[15]->ClosesRequiresClause);
+  EXPECT_TOKEN(Tokens[20], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[]  requires Bar {}");
+  ASSERT_EQ(Tokens.size(), 14u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[6], tok::kw_requires, TT_RequiresClause);
+  EXPECT_TRUE(Tokens[10]->ClosesRequiresClause);
+  EXPECT_TOKEN(Tokens[11], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[]  requires Bar noexcept {}");
+  ASSERT_EQ(Tokens.size(), 15u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[6], tok::kw_requires, TT_RequiresClause);
+  EXPECT_TRUE(Tokens[10]->ClosesRequiresClause);
+  EXPECT_TOKEN(Tokens[12], tok::l_brace, TT_LambdaLBrace);
+
+  Tokens = annotate("[]  requires Bar -> T {}");
+  ASSERT_EQ(Tokens.size(), 16u) << Tokens;
+  EXPECT_TOKEN(Tokens[0], tok::l_square, TT_LambdaLSquare);
+  EXPECT_TOKEN(Tokens[2], tok::less, TT_TemplateOpener);
+  EXPECT_TOKEN(Tokens[6], tok::kw_requires, TT_RequiresClause);
+  EXPECT_TRUE(Tokens[10]->ClosesRequiresClause);
+  EXPECT_TOKEN(Tokens[11], tok::arrow, TT_LambdaArrow);
+  EXPECT_TOKEN(Tokens[13], tok::l_brace, TT_LambdaLBrace);
+
+  

[PATCH] D145034: [Clang][Sema] Start fixing handling of out-of-line definitions of constrained templates

[Alexander Shaposhnikov via Phabricator via cfe-commits]

alexander-shaposhnikov added inline comments.



Comment at: clang/lib/Sema/SemaCXXScopeSpec.cpp:141
+  ClassTemplate->getInjectedClassNameSpecialization();
+  if (Context.hasSameType(Injected, ContextType))
+return ClassTemplate->getTemplatedDecl();

rsmith wrote:
> This should also be guarded by a check that `TemplateParameterListsAreEqual` 
> between `ClassTemplate->getTemplateParameters()` and the template parameter 
> list we picked out of the given array of template parameter lists.
> 
> (With that check in place, we can move this back before the search for 
> partial specializations.)
The problem is that currently the template parameter list (the one which we are 
supposed to pick above) is not always present,
thus the fallback and this check are both still necessary. It happens e.g. for 
invalid code and if i remove the fallback it triggers more changes to the 
diagnostic output, other than that there might be more cases where we currently 
don't set TemplateParamLists for CXXScopeSpec, i kinda wanted to move 
incrementally.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145034

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

[clang] 1a4d0eb - [X86] Drop single use check for freeze(undef) in LowerAVXCONCAT_VECTORS

[via cfe-commits]

Author: ManuelJBrito
Date: 2023-03-09T14:32:30Z
New Revision: 1a4d0eb866be909fe16da5ebffe4122aa0693d8c

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

LOG: [X86] Drop single use check for freeze(undef) in LowerAVXCONCAT_VECTORS

Ignoring freeze(undef) if it has multiple uses in LowerAVXCONCAT_VECTORS
causes the custom INSERT_SUBVECTOR for vector widening to be ignored.

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

Added: 
clang/test/CodeGen/X86/avx-cast-builtins.c

Modified: 
llvm/lib/Target/X86/X86ISelLowering.cpp
llvm/test/CodeGen/X86/avx512-intrinsics.ll
llvm/test/CodeGen/X86/avx512fp16-intrinsics.ll

Removed: 




diff  --git a/clang/test/CodeGen/X86/avx-cast-builtins.c 
b/clang/test/CodeGen/X86/avx-cast-builtins.c
new file mode 100644
index ..8b941c4287b9
--- /dev/null
+++ b/clang/test/CodeGen/X86/avx-cast-builtins.c
@@ -0,0 +1,101 @@
+// REQUIRES: x86-registered-target
+// RUN: %clang_cc1 -O3 -flax-vector-conversions=none -ffreestanding %s 
-triple=x86_64-unknown-unknown -target-feature +avx -target-feature +avx512f  
-target-feature +avx512fp16 -S -o - | FileCheck %s
+
+
+#include 
+
+__m256d test_mm256_castpd128_pd256(__m128d A) {
+  // CHECK-LABEL: test_mm256_castpd128_pd256
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $ymm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm256_castpd128_pd256(A);
+}
+
+__m256 test_mm256_castps128_ps256(__m128 A) {
+  // CHECK-LABEL: test_mm256_castps128_ps256
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $ymm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm256_castps128_ps256(A);
+}
+
+__m256i test_mm256_castsi128_si256(__m128i A) {
+  // CHECK-LABEL: test_mm256_castsi128_si256
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $ymm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm256_castsi128_si256(A);
+}
+
+__m256h test_mm256_castph128_ph256(__m128h A) {
+  // CHECK-LABEL: test_mm256_castph128_ph256
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $ymm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm256_castph128_ph256(A);
+}
+
+__m512h test_mm512_castph128_ph512(__m128h A) {
+  // CHECK-LABEL: test_mm512_castph128_ph512
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $zmm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm512_castph128_ph512(A);
+}
+
+__m512h test_mm512_castph256_ph512(__m256h A) {
+  // CHECK-LABEL: test_mm512_castph256_ph512
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $ymm0 killed $ymm0 def $zmm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm512_castph256_ph512(A);
+}
+
+__m512d test_mm512_castpd256_pd512(__m256d A){
+  // CHECK-LABEL: test_mm512_castpd256_pd512
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $ymm0 killed $ymm0 def $zmm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm512_castpd256_pd512(A);
+}
+
+__m512 test_mm512_castps256_ps512(__m256 A){
+  // CHECK-LABEL: test_mm512_castps256_ps512
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $ymm0 killed $ymm0 def $zmm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm512_castps256_ps512(A);
+}
+
+__m512d test_mm512_castpd128_pd512(__m128d A){
+  // CHECK-LABEL: test_mm512_castpd128_pd512
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $zmm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm512_castpd128_pd512(A);
+}
+
+__m512 test_mm512_castps128_ps512(__m128 A){
+  // CHECK-LABEL: test_mm512_castps128_ps512
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $zmm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm512_castps128_ps512(A);
+}
+
+__m512i test_mm512_castsi128_si512(__m128i A){
+  // CHECK-LABEL: test_mm512_castsi128_si512
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $xmm0 killed $xmm0 def $zmm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm512_castsi128_si512(A);
+}
+
+__m512i test_mm512_castsi256_si512(__m256i A){
+  // CHECK-LABEL: test_mm512_castsi256_si512
+  // CHECK: # %bb.0:
+  // CHECK-NEXT:# kill: def $ymm0 killed $ymm0 def $zmm0
+  // CHECK-NEXT:ret{{[l|q]}}
+  return _mm512_castsi256_si512(A);
+}

diff  --git a/llvm/lib/Target/X86/X86ISelLowering.cpp 
b/llvm/lib/Target/X86/X86ISelLowering.cpp
index a8c37db67f4d..864ef264e92d 100644
--- a/llvm/lib/Target/X86/X86ISelLowering.cpp
+++ b/llvm/lib/Target/X86/X86ISelLowering.cpp
@@ -11656,7 +11656,7 @@ static SDValue LowerAVXCONCAT_VECTORS(SDValue Op, 
SelectionDAG &DAG,
 SDValue SubVec = Op.getOperand(i);
 if (SubVec.isUndef())
   continue;
-if (ISD::isFreezeUndef(SubVec.getNode()) && SubVec.hasOneUse())
+

[PATCH] D145642: [clang-format] Annotate lambdas with requires clauses.

[Emilia Dreamer via Phabricator via cfe-commits]

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



Comment at: clang/lib/Format/UnwrappedLineParser.cpp:3393
+break;
+  } else {
+return;

HazardyKnusperkeks wrote:
> don't need `else` after `break`.
> In fact I would negate the condition and return, and keep the remainder out 
> of any `if` or `else`.
Thank you! I clearly wasn't thinking clearly there


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145642

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

[PATCH] D145605: Revert two patches to fix GH58452 regression

[Erich Keane via Phabricator via cfe-commits]

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

clang-format fixes, going to make sure this passes CI, then commit


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

https://reviews.llvm.org/D145605

Files:
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Sema/SemaInternal.h
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/lib/Sema/SemaTemplateVariadic.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp
  clang/test/SemaTemplate/cxx1z-fold-expressions.cpp
  clang/test/SemaTemplate/pack-deduction.cpp

Index: clang/test/SemaTemplate/pack-deduction.cpp
===
--- clang/test/SemaTemplate/pack-deduction.cpp
+++ clang/test/SemaTemplate/pack-deduction.cpp
@@ -134,14 +134,14 @@
   template struct tuple {};
   template struct A {
 template static pair, tuple> f(pair ...p);
-// expected-note@-1 {{[with U = ]: pack expansion contains parameter packs 'T' and 'U' that have different lengths (2 vs. 3)}}
+// expected-note@-1 {{[with U = ]: pack expansion contains parameter pack 'U' that has a different length (2 vs. 3) from outer parameter packs}}
 // expected-note@-2 {{[with U = ]: pack expansion contains parameter pack 'U' that has a different length (at least 3 vs. 2) from outer parameter packs}}
 
 template static pair, tuple> g(pair ...p, ...);
-// expected-note@-1 {{[with U = ]: pack expansion contains parameter packs 'T' and 'U' that have different lengths (2 vs. 3)}}
+// expected-note@-1 {{[with U = ]: pack expansion contains parameter pack 'U' that has a different length (2 vs. 3) from outer parameter packs}}
 
 template static tuple h(tuple..., pair>);
-// expected-note@-1 {{[with U = ]: pack expansion contains parameter packs 'T' and 'U' that have different lengths (2 vs. 1)}}
+// expected-note@-1 {{[with U = ]: pack expansion contains parameter pack 'U' that has a different length (2 vs. 1) from outer parameter packs}}
   };
 
   pair, tuple> k1 = A().f(pair(), pair());
Index: clang/test/SemaTemplate/cxx1z-fold-expressions.cpp
===
--- clang/test/SemaTemplate/cxx1z-fold-expressions.cpp
+++ clang/test/SemaTemplate/cxx1z-fold-expressions.cpp
@@ -97,7 +97,7 @@
   template  struct Constant {};
 
   template  struct Sum {
-template  using type = Constant<((Is + Js) + ... + 0)>; // expected-error {{pack expansion contains parameter packs 'Is' and 'Js' that have different lengths (1 vs. 2)}}
+template  using type = Constant<((Is + Js) + ... + 0)>; // expected-error {{pack expansion contains parameter pack 'Js' that has a different length (1 vs. 2) from outer parameter packs}}
   };
 
   Sum<1>::type<1, 2> x; // expected-note {{instantiation of}}
Index: clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp
===
--- clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp
+++ clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp
@@ -473,51 +473,45 @@
 }
 }
 
-namespace pr56094 {
-template  struct D {
-  template  using B = int(int (*...p)(T, U));
-  // expected-error@-1 {{pack expansion contains parameter packs 'T' and 'U' that have different lengths (1 vs. 2)}}
-  template  D(B *);
-  // expected-note@-1 {{in instantiation of template type alias 'B' requested here}}
+namespace GH58452 {
+template  struct A {
+  template  using B = void(As...(Bs));
 };
-using t1 = D::B;
-// expected-note@-1 {{in instantiation of template class 'pr56094::D' requested here}}
-
-template  struct F {};
-template  struct G {};
-template  struct E {
-  template  using B = G...>;
-  // expected-error@-1 {{pack expansion contains parameter packs 'I' and 'U' that have different lengths (1 vs. 2)}}
-  template  E(B *);
-  // expected-note@-1 {{in instantiation of template type alias 'B' requested here}}
+
+template  struct C {
+template  using D = typename A::template B;
 };
-using t2 = E::B;
-// expected-note@-1 {{in instantiation of template class 'pr56094::E' requested here}}
-} // namespace pr56094
-
-namespace GH56094 {
-#if __cplusplus >= 201402L
-template  struct A; // expected-note {{template is declared here}}
-template  using B = char;
-template  int C{ A>{}... }; // expected-error {{implicit instantiation of undefined template}}
-#endif
-} // namespace GH56094
 
-namespace GH58679 {
-#if __cplusplus >= 201402L
-template  constexpr int A = 1;
+using t1 = C::template D;
 
-template  struct B;
-template <> struct B<1> { using b1 = void; };
+template 
+using ConditionalRewrite = B;
 
-template  using C = char;
+template 
+using SignatureType = int;
 
-template  int D{ B>>{}... };
+template 
+struct Type1 {
+template 
+using Return = SignatureType...)>;
 
-struct E {
-  template >::b1> E(E1);
 };
 
-template  int F{ E(C{})... };
-#endif
-} // namespace GH58679
+template 
+struct Type2 {
+using T1 = Type

[PATCH] D145509: [HIP] Fix temporary files

[Yaxun Liu via Phabricator via cfe-commits]

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



Comment at: clang/include/clang/Driver/Driver.h:630
 
   // Creates a temp file with $Prefix-%%.$Suffix
   const char *CreateTempFile(Compilation &C, StringRef Prefix, StringRef 
Suffix,

tra wrote:
> The comment should probably be updated to reflect the effect of the optional 
> arguments.
will do


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

https://reviews.llvm.org/D145509

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

[PATCH] D145671: [clang] Remove legacy -m(no)-code-object-v3 options

[Artem Tamazov via Phabricator via cfe-commits]

artem.tamazov accepted this revision as: artem.tamazov.
artem.tamazov added a comment.
This revision is now accepted and ready to land.

No objections from MIOpen side.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145671

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

[PATCH] D143436: [clangd] Move standard options adaptor to CommandMangler

[Kadir Cetinkaya via Phabricator via cfe-commits]

kadircet added a comment.

> @kadircet it is obvious that there is something in this diff that causes this 
> hesitancy in accepting it. I'm ready to keep iterating on the solution but I 
> need a clue what needs the improvement. Please comment.

sorry for the late reply, i was on vacation and just started catching up with 
things. this looks great, thanks!




Comment at: clang-tools-extra/clangd/CompileCommands.cpp:199
+  // use/change working directory, which ExpandResponseFiles doesn't).
+  FS = llvm::vfs::getRealFileSystem();
+}

getting real filesystem is cheap, no need to make this part of the state, just 
inline it into `tooling::addExpandedResponseFiles` call.



Comment at: clang-tools-extra/clangd/CompileCommands.cpp:222
+  tooling::addExpandedResponseFiles(Cmd, Command.Directory, Tokenizer, *FS);
+  tooling::addTargetAndModeForProgramName(Cmd, Cmd.front());
   auto &OptTable = clang::driver::getDriverOptTable();

nridge wrote:
> DmitryPolukhin wrote:
> > nridge wrote:
> > > DmitryPolukhin wrote:
> > > > nridge wrote:
> > > > > nridge wrote:
> > > > > > The target needs to be added **after** the call to 
> > > > > > `SystemIncludeExtractor` later in this function (this is what 
> > > > > > D138546 is trying to fix). The reason is that 
> > > > > > `SystemIncludeExtractor` includes any `--target` flag in the 
> > > > > > compiler driver being queried for system includes, which may be 
> > > > > > gcc, which does not support `--target`.
> > > > > (I guess we could make that change separately in D138546, but if 
> > > > > we're changing the place where the `--target` is added in this patch, 
> > > > > I figure we might as well move it directly to the desired place.)
> > > > I think there are order problems here:
> > > > - we need `--driver-mode=cl` injected here to make check on line #229 
> > > > work as expected
> > > > - if we don't inject it driver mode here, command line edits won't see 
> > > > the change; see how I modified test 
> > > > clangd/unittests/CompileCommandsTests.cpp line #203, with D138546 edits 
> > > > were not applied properly to driver mode
> > > > 
> > > > I'll double check how it works on Windows but I expect that moving it 
> > > > after SystemIncludeExtractor will break proper driver mode detection.
> > > > I think there are order problems here:
> > > > - we need `--driver-mode=cl` injected here to make check on line #229 
> > > > work as expected
> > > 
> > > Looking at the [line in 
> > > question](https://searchfox.org/llvm/rev/0cbb8ec030e23c0e13331b5d54155def8c901b36/clang-tools-extra/clangd/CompileCommands.cpp#213),
> > >  it calls `driver::getDriverMode()` which [falls back on extracting the 
> > > driver 
> > > mode](https://searchfox.org/llvm/rev/0cbb8ec030e23c0e13331b5d54155def8c901b36/clang/lib/Driver/Driver.cpp#6407)
> > >  from the program name anyways -- so I think that should be fine.
> > > 
> > > > - if we don't inject it driver mode here, command line edits won't see 
> > > > the change; see how I modified test 
> > > > clangd/unittests/CompileCommandsTests.cpp line #203, with D138546 edits 
> > > > were not applied properly to driver mode
> > > 
> > > I'm not following the motivation for this test. Is there any real-world 
> > > use case which requires the command line edits seeing the `--driver-mode` 
> > > parameter?
> > > I'm not following the motivation for this test. Is there any real-world 
> > > use case which requires the command line edits seeing the `--driver-mode` 
> > > parameter?
> > 
> > @nridge, it will break existing behaviour when user was able to remove 
> > these inserted options like this `CompileFlags: {Remove: 
> > ['--driver-mode=*', '--target=*']}`. If I move call of 
> > `addTargetAndModeForProgramName` after `SystemIncludeExtractor`r, inserted 
> > options will stay in list. User may only override it with 
> > `CompileFlags.Compiler` but it will override all compilers. I don't know is 
> > it real problem or not so if you think I should still move it after 
> > `SystemIncludeExtractor`, I'll do it.
> > @nridge, it will break existing behaviour when user was able to remove 
> > these inserted options like this `CompileFlags: {Remove: 
> > ['--driver-mode=*', '--target=*']}`.
> 
> Thanks. I'll leave the final word to @kadircet here but in my opinion, being 
> able to remove those flags via `Remove` is not important; as you say, the 
> user can change the `Compiler` to influence the driver mode if needed.
agreed. `addTargetAndModeForProgramName` will add these flags only when they're 
not present. deleting --driver-mode or --target, without providing a fixed 
replacement doesn't sound like a real use case.



Comment at: 
clang-tools-extra/clangd/test/Inputs/did-change-configuration-params.args:1
+-Wpedantic

you can test `expandResponseFile` behaviour through unittests as well, see 
https://github.com/llvm/llvm-project/blob/main/clang-t

[PATCH] D83906: [CodeGen] Emit a call instruction instead of an invoke if the called llvm function is marked nounwind

[Akira Hatanaka via Phabricator via cfe-commits]

ahatanak added a comment.

clang marks the called function `foo` in p1.cpp as nounwind here: 
https://github.com/llvm/llvm-project/blob/main/clang/lib/CodeGen/CodeGenFunction.cpp#L1284

clang can also mark a function declaration as nounwind based on the information 
in the source code, for example, when it is annotated with 
`__attribute__((pure))`.

I haven't read everything discussed in https://reviews.llvm.org/D18634 yet, but 
it seems like it's safe to do this optimization when the called function is 
`linkonce_odr`. If clang or llvm's optimization determines one version of the 
function doesn't throw, then other versions of the same function can't throw 
either.

But it looks like clang doesn't do the right thing when the `foo` is weak. 
clang emits a call instead of an invoke when it compiles the following code:

  int foo() __attribute__((weak, pure));
  int bar() noexcept { return foo();};


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83906

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

[clang] 0041f08 - [clang][Interp][NFC] Take a const Descriptor* in dtor,move,ctorFns

[Timm Bäder via cfe-commits]

Author: Timm Bäder
Date: 2023-03-09T16:08:59+01:00
New Revision: 0041f081962c60a96d45d9a3a964c2d00216c16d

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

LOG: [clang][Interp][NFC] Take a const Descriptor* in dtor,move,ctorFns

We are not mutating the descriptors here.

Added: 


Modified: 
clang/lib/AST/Interp/Descriptor.cpp
clang/lib/AST/Interp/Descriptor.h

Removed: 




diff  --git a/clang/lib/AST/Interp/Descriptor.cpp 
b/clang/lib/AST/Interp/Descriptor.cpp
index e9fe159eccd4b..212311cfa2ae6 100644
--- a/clang/lib/AST/Interp/Descriptor.cpp
+++ b/clang/lib/AST/Interp/Descriptor.cpp
@@ -17,30 +17,32 @@ using namespace clang;
 using namespace clang::interp;
 
 template 
-static void ctorTy(Block *, char *Ptr, bool, bool, bool, Descriptor *) {
+static void ctorTy(Block *, char *Ptr, bool, bool, bool, const Descriptor *) {
   new (Ptr) T();
 }
 
-template  static void dtorTy(Block *, char *Ptr, Descriptor *) {
+template 
+static void dtorTy(Block *, char *Ptr, const Descriptor *) {
   reinterpret_cast(Ptr)->~T();
 }
 
 template 
-static void moveTy(Block *, char *Src, char *Dst, Descriptor *) {
+static void moveTy(Block *, char *Src, char *Dst, const Descriptor *) {
   auto *SrcPtr = reinterpret_cast(Src);
   auto *DstPtr = reinterpret_cast(Dst);
   new (DstPtr) T(std::move(*SrcPtr));
 }
 
 template 
-static void ctorArrayTy(Block *, char *Ptr, bool, bool, bool, Descriptor *D) {
+static void ctorArrayTy(Block *, char *Ptr, bool, bool, bool,
+const Descriptor *D) {
   for (unsigned I = 0, NE = D->getNumElems(); I < NE; ++I) {
 new (&reinterpret_cast(Ptr)[I]) T();
   }
 }
 
 template 
-static void dtorArrayTy(Block *, char *Ptr, Descriptor *D) {
+static void dtorArrayTy(Block *, char *Ptr, const Descriptor *D) {
   InitMap *IM = *reinterpret_cast(Ptr);
   if (IM != (InitMap *)-1)
 free(IM);
@@ -52,7 +54,7 @@ static void dtorArrayTy(Block *, char *Ptr, Descriptor *D) {
 }
 
 template 
-static void moveArrayTy(Block *, char *Src, char *Dst, Descriptor *D) {
+static void moveArrayTy(Block *, char *Src, char *Dst, const Descriptor *D) {
   for (unsigned I = 0, NE = D->getNumElems(); I < NE; ++I) {
 auto *SrcPtr = &reinterpret_cast(Src)[I];
 auto *DstPtr = &reinterpret_cast(Dst)[I];
@@ -61,7 +63,7 @@ static void moveArrayTy(Block *, char *Src, char *Dst, 
Descriptor *D) {
 }
 
 static void ctorArrayDesc(Block *B, char *Ptr, bool IsConst, bool IsMutable,
-  bool IsActive, Descriptor *D) {
+  bool IsActive, const Descriptor *D) {
   const unsigned NumElems = D->getNumElems();
   const unsigned ElemSize =
   D->ElemDesc->getAllocSize() + sizeof(InlineDescriptor);
@@ -86,7 +88,7 @@ static void ctorArrayDesc(Block *B, char *Ptr, bool IsConst, 
bool IsMutable,
   }
 }
 
-static void dtorArrayDesc(Block *B, char *Ptr, Descriptor *D) {
+static void dtorArrayDesc(Block *B, char *Ptr, const Descriptor *D) {
   const unsigned NumElems = D->getNumElems();
   const unsigned ElemSize =
   D->ElemDesc->getAllocSize() + sizeof(InlineDescriptor);
@@ -101,7 +103,7 @@ static void dtorArrayDesc(Block *B, char *Ptr, Descriptor 
*D) {
   }
 }
 
-static void moveArrayDesc(Block *B, char *Src, char *Dst, Descriptor *D) {
+static void moveArrayDesc(Block *B, char *Src, char *Dst, const Descriptor *D) 
{
   const unsigned NumElems = D->getNumElems();
   const unsigned ElemSize =
   D->ElemDesc->getAllocSize() + sizeof(InlineDescriptor);
@@ -123,7 +125,7 @@ static void moveArrayDesc(Block *B, char *Src, char *Dst, 
Descriptor *D) {
 }
 
 static void ctorRecord(Block *B, char *Ptr, bool IsConst, bool IsMutable,
-   bool IsActive, Descriptor *D) {
+   bool IsActive, const Descriptor *D) {
   const bool IsUnion = D->ElemRecord->isUnion();
   auto CtorSub = [=](unsigned SubOff, Descriptor *F, bool IsBase) {
 auto *Desc = reinterpret_cast(Ptr + SubOff) - 1;
@@ -146,7 +148,7 @@ static void ctorRecord(Block *B, char *Ptr, bool IsConst, 
bool IsMutable,
 CtorSub(V.Offset, V.Desc, /*isBase=*/true);
 }
 
-static void dtorRecord(Block *B, char *Ptr, Descriptor *D) {
+static void dtorRecord(Block *B, char *Ptr, const Descriptor *D) {
   auto DtorSub = [=](unsigned SubOff, Descriptor *F) {
 if (auto Fn = F->DtorFn)
   Fn(B, Ptr + SubOff, F);
@@ -159,7 +161,7 @@ static void dtorRecord(Block *B, char *Ptr, Descriptor *D) {
 DtorSub(F.Offset, F.Desc);
 }
 
-static void moveRecord(Block *B, char *Src, char *Dst, Descriptor *D) {
+static void moveRecord(Block *B, char *Src, char *Dst, const Descriptor *D) {
   for (const auto &F : D->ElemRecord->fields()) {
 auto FieldOff = F.Offset;
 auto FieldDesc = F.Desc;

diff  --git a/clang/lib/AST/Interp/Descriptor.h 
b

[PATCH] D145567: [Driver] Rename multilib flags to tags

[Michael Platings via Phabricator via cfe-commits]

michaelplatings added a comment.

Thanks @MaskRay for taking a look and thanks @simon_tatham for the review of 
the change. This change affects existing code so I think it deserves its own 
commit, but I'll move it down the stack to before D142932 
 so that later changes use the new names 
immediately, and I'll incorporate Simon's suggestions into those.




Comment at: clang/docs/Multilib.rst:66
``--target=armv7m-none-eabi`` are equivalent. Clang can also accept many
-   independent pieces of information within a single flag - for example
+   independent pieces of information within a single option - for example
``-march=armv8.1m.main+fp+mve`` specifies the architecture and two

simon_tatham wrote:
> An "option" here seems to be the same thing as an "argument" elsewhere in 
> this paragraph. Since the terminology is already confusing, perhaps simplify 
> by using the same word consistently throughout? I think "option" is more 
> precise, because //positional// clang arguments like input files definitely 
> //don't// play a part in this mechanism.
I'll incorporate this into D143587.



Comment at: clang/docs/Multilib.rst:71
+   arguments into a standard set of simpler "tags". In many cases these tags
will look like a command line argument with the leading ``-`` stripped off,
+   but where a suitable form for the tag doesn't exist in command line

simon_tatham wrote:
> This is a particular case where "option" seems like a better word. Not every 
> //argument// has a leading `-` in the first place. But every //option// does.
> 
> (Or, at least, in the default Unix / gcc style of clang options. I suppose in 
> `clang-cl` even that is not true, because options can have a leading `/` in 
> Windows style. I assume that in that situation the options are normalised to 
> their GNU representation before converting into multilib selection tags?)
I'll incorporate this into D143587.



Comment at: clang/docs/Multilib.rst:182
   # List of multilib variants. Required.
   # The ordering of Variants is important if more than one variant can match
+  # the same set of tags. See the docs on multilib layering for more info.

simon_tatham wrote:
> That capital V looks unintentional to me, and is potentially confusing – 
> someone might go looking for a formal definition of it somewhere.
I'll incorporate this into D143587.



Comment at: clang/include/clang/Driver/Multilib.h:64-65
+  /// Get the set of tags that indicate this multilib's use.
+  /// Tags are arbitrary strings although typically they will look similar to
+  /// command line options. A multilib is considered compatible if its tags are
+  /// a subset of the tags derived from the Clang command line options.

simon_tatham wrote:
> Tags are arbitrary strings, some of which are derived from command-line 
> options and look similar to them, and others can be defined by a particular 
> multilib.yaml
I'll move this change to earlier in the stack before multilib.yaml is a thing, 
but then I'll update the comment with your suggestion in D142932.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145567

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

[PATCH] D144006: [DebugMetadata][DwarfDebug] Support function-local types in lexical block scopes (5/7)

[Juan Manuel Martinez Caamaño via Phabricator via cfe-commits]

jmmartinez added a comment.

Just a few minor comments. Everything else seems good to me.




Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp:698
+  // an inlined function: if a local variable has a templated type with
+  // a function-local type as a template parameter. See PR55680 for details.
+  if (!Scope->isAbstractScope() && !Scope->getInlinedAt()) {

I cannot find the link to PR55680. Would you mind sharing it?

You could also reference `local-type-as-template-parameter.ll`, your test 
depicts the issue very clearly.



Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp:700-701
+  if (!Scope->isAbstractScope() && !Scope->getInlinedAt()) {
+if (LexicalBlockDIEs.count(DS)) {
+  ScopeDIE = LexicalBlockDIEs[DS];
+  assert(!ScopeDIE->findAttribute(dwarf::DW_AT_low_pc) &&

NIT: You could use `find` to avoid searching in `LexicalBlockDIEs` twice.



Comment at: llvm/lib/CodeGen/AsmPrinter/DwarfCompileUnit.cpp:712-714
+  assert(!getAbstractScopeDIEs().count(DS) &&
+ "Abstract DIE for this scope exists!");
+  getAbstractScopeDIEs()[DS] = ScopeDIE;

NIT: You could use `insert/try_emplace` instead of using `count` and 
`operator[]`. The assertion would become something like:
```
auto Inserted = getAbstractScopeDIEs().try_emplace(DS, ScopeDIE);
assert(Inserted.second && "Abstract DIE for this scope exists!");
return ScopeDIE;
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144006

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

[PATCH] D144654: [Lex] Warn when defining or undefining any builtin macro

[John Brawn via Phabricator via cfe-commits]

john.brawn added a comment.

D145691  should fix the libc++ CI failures.


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

https://reviews.llvm.org/D144654

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

[PATCH] D145671: [clang] Remove legacy -m(no)-code-object-v3 options

[Yaxun Liu via Phabricator via cfe-commits]

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

Did you go through the deprecation process for this option? We need to send a 
documentation team first so that it is announced to the users. Then in the next 
release we can deprecate it.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145671

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

[PATCH] D141714: Fix ast print of variables with attributes

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D141714#4175942 , 
@giulianobelinassi wrote:

> Hi, Aron.
>
> Just to make myself clear: What I need to do is that the clang dumps for C 
> files are also accepted by GCC as input.

FWIW, that's not a supported use for `-ast-print`. We've never had a 
requirement that `-ast-print` be useful for anything more than debugging 
scenarios and so the printing functionality *frequently* produces incorrect 
output, especially on newer language constructs. We fix up the functionality in 
an ad hoc manner as people find a reason to care about a particular situation.

If your goal is so that `-ast-print` reliably produces compilable code, I think 
that requires buy-in from the Clang community because that's a bit of a heavy 
lift for the community to support. Traditionally, we've pointed users to other 
tools that are usually better-suited to the task trying to be solved (like 
`clang-format` for pretty printing or stencils for performing source to source 
transformations, etc).

> Here is why I wanted to output the attribute on middle:
>
> https://godbolt.org/z/6aPc6aWcz
>
> As you can see, GCC complains of `__attributes__` output on the right side of 
> functions with bodies.
>
> But overall, perhaps what should be output in the dumps are the following 
> (please check if you agree with me):
>
> 1- Attributes in variables should be output to the right side, as it was done 
> before. That is:
>
>   int var __attribute__((unused)) = 0;

Agreed. FWIW, I don't mind if that winds up producing:

  int var1 __attribute__((unused)) = 0, var2 __attribute__((unused)) = 0;

instead of:

  __attribute__((unused)) int var1 = 0, var2 = 0;



> 2- Variables or functions declared with __declspec attributes should go to 
> the left side, as does MSVC says is recommended. That is:
>
>   __declspec(thread) int var = 0;
>   __declspec(noinline) int f(void);
>   __declspec(noinline) int f(void) { return 0; }

Agreed.

> 3- Functions __prototypes__ should have its attributes output to the right 
> side, that means:
>
>   int f(void) __attribute__((unused));

So long as this doesn't change program meaning for any attributes, that seems 
reasonable enough.

> 4- But attributes specified in function declaration __with body__ should go 
> to the __left__ side __because GCC rejects outputing them on the right 
> side__, as:
>
>   __attribute__((unused)) int f(void) { return 0; }

This will break code for folks compiling with Clang, though, so it has to be 
done on a case-by-case basis. Any attribute accepting an expression argument 
that appears on the right of the function needs to continue to appear to the 
right of the function the expression refers to a parameter name. The same is 
true for use with lambdas.

> -
>
> The result of this choice would be that the following K&R function __as 
> input__ (notice how it is not clear where the __attribute__ is being applied 
> to:
>
>   int f(i)
>__attribute__((unused)) int i;
>   { return 0; }
>
> would be dumped as:
>
>   __attribute__((unused)) int f(i)
>   int i;
>   { return 0; }
>
> But in practical terms, GCC would accept it without problems and it is clear 
> where the __attribute__ is being applied to. Outputting to the right side has 
> some ambiguity here, which is what I want to avoid.

Again, this only works for some attributes. Consider: 
https://godbolt.org/z/3YreGY1G4

There's another case to think about, which are tag types: 
https://godbolt.org/z/KjKn7rz89

And finally, there's `[[]]` attributes where changing the position from what's 
in source will potentially change what the attribute appertains to and also 
break code. So I think to achieve the goal you're after, there's actually quite 
a bit of work to be done. However, so long as the output doesn't get *worse* 
for other situations, I think any incremental progress here is acceptable. 
e.g., fixing this kind of nonsense is a good incremental step even if we do 
nothing else:

  // MS-EXT-NEXT: int x = 3 __declspec(thread);
  int __declspec(thread) x = 3;


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D141714

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

[PATCH] D144654: [Lex] Warn when defining or undefining any builtin macro

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/Lex/PPDirectives.cpp:3189-3192
+if ((MI->isBuiltinMacro() ||
+ SourceMgr.isWrittenInBuiltinFile(MI->getDefinitionLoc())) &&
+!(getLangOpts().ObjC && isObjCProtectedMacro(II)))
+  Diag(MacroNameTok, diag::ext_pp_undef_builtin_macro);

Should this diagnostic be suppressed in a system header on the assumption that 
system headers are part of the implementation and thus free to 
undefine/redefine macros at will?


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

https://reviews.llvm.org/D144654

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

[PATCH] D122677: [prototype] include-cleaner library

[Piotr Zegar via Phabricator via cfe-commits]

PiotrZSL added inline comments.



Comment at: clang-tools-extra/clang-tidy/misc/MiscTidyModule.cpp:62
 "misc-unused-alias-decls");
+CheckFactories.registerCheck("misc-unused-includes");
 CheckFactories.registerCheck(

Missing tests & documentation for this check.



Comment at: clang-tools-extra/clang-tidy/misc/UnusedIncludesCheck.cpp:38
+  Finder->addMatcher(
+  translationUnitDecl(forEach(decl(isExpansionInMainFile()).bind("top"))),
+  this);

why not just:
```
Finder->addMatcher(decl(isExpansionInMainFile()).bind("top"))
```



Comment at: clang-tools-extra/clang-tidy/misc/UnusedIncludesCheck.h:35
+  std::unique_ptr RecordedPP;
+  std::vector Top;
+};

There are going to be manny reallocations of this std::vector, we got manny 
declarations, consider using std::deque.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D122677

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

[PATCH] D143480: [clang][Interp] Fix derived-to-base casts for >1 levels

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added inline comments.



Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:1949
+  // Pointer of derived type is already on the stack.
+  const CXXRecordDecl *FinalDecl = cast(BaseType->getDecl());
+  const RecordDecl *CurDecl = DerivedType->getDecl();





Comment at: clang/test/AST/Interp/records.cpp:266
 };
 #endif
 

I think it'd be good to add test coverage for cases like: 
https://godbolt.org/z/GnPnP4z76


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143480

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

[PATCH] D143466: [clang][Interp] Fix initializing base class members

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

In D143466#4181191 , @tbaeder wrote:

> The tests you proposed need https://reviews.llvm.org/D143480 first so we can 
> cast up more than one level.

Okay, how about we land that one first then come back to this one? I left some 
comments on the other review.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143466

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

[PATCH] D144190: [AIX][clang] Storage Locations for Constant Pointers

[Qiongsi Wu via Phabricator via cfe-commits]

qiongsiwu1 updated this revision to Diff 503796.
qiongsiwu1 added a comment.

Rename the `ReadOnlyPointers` option in the source to `XCOFFReadOnlyPointers`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144190

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/Basic/CodeGenOptions.def
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/CodeGen/BackendUtil.cpp
  clang/lib/Driver/ToolChains/AIX.cpp
  clang/lib/Driver/ToolChains/Clang.cpp
  clang/lib/Frontend/CompilerInvocation.cpp
  clang/test/CodeGen/PowerPC/aix-roptr.c
  clang/test/Driver/ppc-roptr.c

Index: clang/test/Driver/ppc-roptr.c
===
--- /dev/null
+++ clang/test/Driver/ppc-roptr.c
@@ -0,0 +1,33 @@
+// RUN: %clang -### -target powerpc-ibm-aix-xcoff -mroptr %s 2>&1 | FileCheck %s
+// RUN: %clang -### -target powerpc-ibm-aix-xcoff -c -mroptr %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=ROPTR
+// RUN: %clang -### -target powerpc-ibm-aix-xcoff -S -mroptr %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=ROPTR
+// RUN: %clang -### -target powerpc-ibm-aix-xcoff -mroptr -mno-roptr %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=NO_ROPTR
+// RUN: %clang -### -target powerpc64-ibm-aix-xcoff -mroptr %s 2>&1 | FileCheck %s
+// RUN: %clang -### -target powerpc64-ibm-aix-xcoff -c -mroptr %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=ROPTR
+// RUN: %clang -### -target powerpc64-ibm-aix-xcoff -S -mroptr %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=ROPTR
+// RUN: %clang -### -target powerpc64-ibm-aix-xcoff -mroptr -mno-roptr %s 2>&1 | \
+// RUN: FileCheck %s --check-prefix=NO_ROPTR
+
+// RUN: %clang -### -target powerpc64le-unknown-linux-gnu -mroptr \
+// RUN: %s 2>&1 | FileCheck %s --check-prefix=TARGET_ROPTR_ERR
+// RUN: %clang -### -target powerpc64le-unknown-linux-gnu -mno-roptr \
+// RUN: %s 2>&1 | FileCheck %s --check-prefix=TARGET_NOROPTR_ERR
+// RUN: %clang -### -target powerpc-ibm-aix-xcoff -mroptr -shared \
+// RUN: %s 2>&1 | FileCheck %s --check-prefix=SHARED_ERR
+// RUN: %clang -### -target powerpc64-ibm-aix-xcoff -mroptr -shared \
+// RUN: %s 2>&1 | FileCheck %s --check-prefix=SHARED_ERR
+
+// CHECK: "-mroptr"
+// CHECK: "-bforceimprw"
+// ROPTR: "-mroptr"
+// NO_ROPTR-NOT: "-mroptr"
+// NO_ROPTR-NOT: "-bforceimprw"
+
+// TARGET_ROPTR_ERR: error: unsupported option '-mroptr' for target 'powerpc64le-unknown-linux-gnu'
+// TARGET_NOROPTR_ERR: error: unsupported option '-mno-roptr' for target 'powerpc64le-unknown-linux-gnu'
+// SHARED_ERR: error: -mroptr is not suppored with -shared
Index: clang/test/CodeGen/PowerPC/aix-roptr.c
===
--- /dev/null
+++ clang/test/CodeGen/PowerPC/aix-roptr.c
@@ -0,0 +1,27 @@
+// RUN: %clang_cc1 -triple=powerpc-ibm-aix-xcoff -mroptr -fdata-sections \
+// RUN: -S <%s | FileCheck %s --check-prefix=CHECK32
+// RUN: %clang_cc1 -triple=powerpc64-ibm-aix-xcoff -mroptr -fdata-sections \
+// RUN: -S <%s | FileCheck %s --check-prefix=CHECK64
+// RUN: not %clang_cc1 -triple=powerpc-ibm-aix-xcoff -mroptr \
+// RUN: -S <%s 2>&1 | FileCheck %s --check-prefix=DATA_SECTION_ERR
+// RUN: not %clang_cc1 -triple=powerpc64-ibm-aix-xcoff -mroptr \
+// RUN: -S <%s 2>&1 | FileCheck %s --check-prefix=DATA_SECTION_ERR
+
+char c1 = 10;
+char c2 = 20;
+char* const c1_ptr = &c1;
+// CHECK32: .csect c1_ptr[RO],2
+// CHECK32-NEXT:	.globl	c1_ptr[RO]
+// CHECK32-NEXT:	.align	2
+// CHECK32-NEXT:	.vbyte	4, c1[RW]
+
+// CHECK64: .csect c1_ptr[RO],3
+// CHECK64-NEXT:	.globl	c1_ptr[RO]
+// CHECK64-NEXT:	.align	3
+// CHECK64-NEXT:	.vbyte	8, c1[RW]
+
+// DATA_SECTION_ERR: error: -mroptr is supported only with -fdata-sections
+
+int main() {
+*(char**)&c1_ptr = &c2;
+}
Index: clang/lib/Frontend/CompilerInvocation.cpp
===
--- clang/lib/Frontend/CompilerInvocation.cpp
+++ clang/lib/Frontend/CompilerInvocation.cpp
@@ -1560,6 +1560,9 @@
   if (Opts.EnableAIXExtendedAltivecABI)
 GenerateArg(Args, OPT_mabi_EQ_vec_extabi, SA);
 
+  if (Opts.XCOFFReadOnlyPointers)
+GenerateArg(Args, OPT_mroptr, SA);
+
   if (!Opts.OptRecordPasses.empty())
 GenerateArg(Args, OPT_opt_record_passes, Opts.OptRecordPasses, SA);
 
@@ -1949,6 +1952,25 @@
 Opts.EnableAIXExtendedAltivecABI = O.matches(OPT_mabi_EQ_vec_extabi);
   }
 
+  if (Arg *A = Args.getLastArg(OPT_mroptr)) {
+if (!T.isOSAIX())
+  Diags.Report(diag::err_drv_unsupported_opt_for_target)
+  << A->getSpelling() << T.str();
+
+// Since the stroage mapping class is specified per csect,
+// without using data sections, it is ambiguous what exactly should
+// be done for the read-only pointers. Using read-only pointers may cause
+// other RO variables in the same csect 

[PATCH] D83906: [CodeGen] Emit a call instruction instead of an invoke if the called llvm function is marked nounwind

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

There are *some* properties we can still assume about `linkonce_odr` functions 
despite them being replaceable at link time.  The high-level language guarantee 
we're starting from is that the source semantics of all versions of the 
function are identical.  The version of the function we're looking at has been 
transformed from the original source — it is, after all, now LLVM IR, not C/C++ 
— but it has presumably faithfully preserved the source semantics.  We can 
therefore rely on any properties of the semantics that are required to be 
preserved by transformation, which includes things like "does it terminate", 
"what value does it return", "what side effects does it perform", and so on.  
What we can't rely on are properties of the implementation that are not 
required to be preserved by transformation, like whether or not it uses a 
certain argument — transformations are permitted to change that.

The output-stability argument is an interesting one.  The critical thing here 
is to avoid instability on the same source.  When the source is different, I 
mean, it'd be nice to make a best effort at stability, but even putting 
optimization aside, things like header processing order or template 
instantiation order are necessarily going to affect things like order in the 
functions lists.  That's going to affect output, at the very least in terms of 
object file order, but also in that we can't realistically promise that 
function processing order in the optimization will *never* have any impact.  
Our interprocedural passes generally try to work in call-dependency order, but 
that's not a perfect tree, and function order inevitably comes into it.

With all that said, I don't feel strongly that we need to preserve this 
frontend optimization if it's causing real problems.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D83906

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

[clang] acecf68 - Revert two patches to fix GH58452 regression

[Erich Keane via cfe-commits]

Author: Erich Keane
Date: 2023-03-09T09:16:53-08:00
New Revision: acecf68c8b7c3c625cfa00f00f8ddc8f15baae44

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

LOG: Revert two patches to fix GH58452 regression

GH58452 is a regression in the 16.0 release branch caused by both:
b8a1b698afb2fc84819c7596090aabf4d826b436 and
3a0309c53674be56b5cfce038d78a0c2c6e2a98c

This patch reverts both of those to make the 'valid' code stop
diagnosing
at the expense of crashes on invalid + unclear diagnostics.

This patch also adds the tests from GH58452 to prevent any
re-application from breaking this again.

Revert "[clang] Improve diagnostics for expansion length mismatch"
This reverts commit 3a0309c53674be56b5cfce038d78a0c2c6e2a98c.
Revert "[clang] fix missing initialization of original number of expansions"
This reverts commit b8a1b698afb2fc84819c7596090aabf4d826b436.

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

Added: 


Modified: 
clang/include/clang/Sema/Sema.h
clang/include/clang/Sema/SemaInternal.h
clang/lib/Sema/SemaTemplateDeduction.cpp
clang/lib/Sema/SemaTemplateVariadic.cpp
clang/lib/Sema/TreeTransform.h
clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp
clang/test/SemaTemplate/cxx1z-fold-expressions.cpp
clang/test/SemaTemplate/pack-deduction.cpp

Removed: 




diff  --git a/clang/include/clang/Sema/Sema.h b/clang/include/clang/Sema/Sema.h
index d1342876f85dc..a492721f77bfa 100644
--- a/clang/include/clang/Sema/Sema.h
+++ b/clang/include/clang/Sema/Sema.h
@@ -238,11 +238,9 @@ namespace threadSafety {
 
 // FIXME: No way to easily map from TemplateTypeParmTypes to
 // TemplateTypeParmDecls, so we have this horrible PointerUnion.
-using UnexpandedParameterPack = std::pair<
-llvm::PointerUnion<
-const TemplateTypeParmType *, const SubstTemplateTypeParmPackType *,
-const SubstNonTypeTemplateParmPackExpr *, const NamedDecl *>,
-SourceLocation>;
+typedef std::pair,
+  SourceLocation>
+UnexpandedParameterPack;
 
 /// Describes whether we've seen any nullability information for the given
 /// file.

diff  --git a/clang/include/clang/Sema/SemaInternal.h 
b/clang/include/clang/Sema/SemaInternal.h
index 4eca50919dc7e..842eec099540c 100644
--- a/clang/include/clang/Sema/SemaInternal.h
+++ b/clang/include/clang/Sema/SemaInternal.h
@@ -62,7 +62,7 @@ inline InheritableAttr *getDLLAttr(Decl *D) {
 }
 
 /// Retrieve the depth and index of a template parameter.
-inline std::pair getDepthAndIndex(const NamedDecl *ND) {
+inline std::pair getDepthAndIndex(NamedDecl *ND) {
   if (const auto *TTP = dyn_cast(ND))
 return std::make_pair(TTP->getDepth(), TTP->getIndex());
 
@@ -79,7 +79,7 @@ getDepthAndIndex(UnexpandedParameterPack UPP) {
   if (const auto *TTP = UPP.first.dyn_cast())
 return std::make_pair(TTP->getDepth(), TTP->getIndex());
 
-  return getDepthAndIndex(UPP.first.get());
+  return getDepthAndIndex(UPP.first.get());
 }
 
 class TypoCorrectionConsumer : public VisibleDeclConsumer {

diff  --git a/clang/lib/Sema/SemaTemplateDeduction.cpp 
b/clang/lib/Sema/SemaTemplateDeduction.cpp
index 9e48a2a35a344..1fe2d3fac6859 100644
--- a/clang/lib/Sema/SemaTemplateDeduction.cpp
+++ b/clang/lib/Sema/SemaTemplateDeduction.cpp
@@ -756,11 +756,8 @@ class PackDeductionScope {
   SmallVector Unexpanded;
   S.collectUnexpandedParameterPacks(Pattern, Unexpanded);
   for (unsigned I = 0, N = Unexpanded.size(); I != N; ++I) {
-UnexpandedParameterPack U = Unexpanded[I];
-if (U.first.is() ||
-U.first.is())
-  continue;
-auto [Depth, Index] = getDepthAndIndex(U);
+unsigned Depth, Index;
+std::tie(Depth, Index) = getDepthAndIndex(Unexpanded[I]);
 if (Depth == Info.getDeducedDepth())
   AddPack(Index);
   }

diff  --git a/clang/lib/Sema/SemaTemplateVariadic.cpp 
b/clang/lib/Sema/SemaTemplateVariadic.cpp
index 01a435668d883..86268b504cbb3 100644
--- a/clang/lib/Sema/SemaTemplateVariadic.cpp
+++ b/clang/lib/Sema/SemaTemplateVariadic.cpp
@@ -89,23 +89,6 @@ namespace {
   return true;
 }
 
-bool
-VisitSubstTemplateTypeParmPackTypeLoc(SubstTemplateTypeParmPackTypeLoc TL) 
{
-  Unexpanded.push_back({TL.getTypePtr(), TL.getNameLoc()});
-  return true;
-}
-
-bool VisitSubstTemplateTypeParmPackType(SubstTemplateTypeParmPackType *T) {
-  Unexpanded.push_back({T, SourceLocation()});
-  return true;
-}
-
-bool
-VisitSubstNonTypeTemplateParmPackExpr(SubstNonTypeTemplateParmPackExpr *E) 
{
-  Unexpanded.push_back({E, E->getParameterPackLocation()});
-  return true;
-}
-
 /// Record occurrences of function and non-type template
 /// parameter packs in an expression.
 bool Visit

[PATCH] D145605: Revert two patches to fix GH58452 regression

[Erich Keane via Phabricator via cfe-commits]

This revision was not accepted when it landed; it landed in state "Needs 
Review".
This revision was automatically updated to reflect the committed changes.
Closed by commit rGacecf68c8b7c: Revert two patches to fix GH58452 regression 
(authored by erichkeane).
Herald added a project: clang.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145605

Files:
  clang/include/clang/Sema/Sema.h
  clang/include/clang/Sema/SemaInternal.h
  clang/lib/Sema/SemaTemplateDeduction.cpp
  clang/lib/Sema/SemaTemplateVariadic.cpp
  clang/lib/Sema/TreeTransform.h
  clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp
  clang/test/SemaTemplate/cxx1z-fold-expressions.cpp
  clang/test/SemaTemplate/pack-deduction.cpp

Index: clang/test/SemaTemplate/pack-deduction.cpp
===
--- clang/test/SemaTemplate/pack-deduction.cpp
+++ clang/test/SemaTemplate/pack-deduction.cpp
@@ -134,14 +134,14 @@
   template struct tuple {};
   template struct A {
 template static pair, tuple> f(pair ...p);
-// expected-note@-1 {{[with U = ]: pack expansion contains parameter packs 'T' and 'U' that have different lengths (2 vs. 3)}}
+// expected-note@-1 {{[with U = ]: pack expansion contains parameter pack 'U' that has a different length (2 vs. 3) from outer parameter packs}}
 // expected-note@-2 {{[with U = ]: pack expansion contains parameter pack 'U' that has a different length (at least 3 vs. 2) from outer parameter packs}}
 
 template static pair, tuple> g(pair ...p, ...);
-// expected-note@-1 {{[with U = ]: pack expansion contains parameter packs 'T' and 'U' that have different lengths (2 vs. 3)}}
+// expected-note@-1 {{[with U = ]: pack expansion contains parameter pack 'U' that has a different length (2 vs. 3) from outer parameter packs}}
 
 template static tuple h(tuple..., pair>);
-// expected-note@-1 {{[with U = ]: pack expansion contains parameter packs 'T' and 'U' that have different lengths (2 vs. 1)}}
+// expected-note@-1 {{[with U = ]: pack expansion contains parameter pack 'U' that has a different length (2 vs. 1) from outer parameter packs}}
   };
 
   pair, tuple> k1 = A().f(pair(), pair());
Index: clang/test/SemaTemplate/cxx1z-fold-expressions.cpp
===
--- clang/test/SemaTemplate/cxx1z-fold-expressions.cpp
+++ clang/test/SemaTemplate/cxx1z-fold-expressions.cpp
@@ -97,7 +97,7 @@
   template  struct Constant {};
 
   template  struct Sum {
-template  using type = Constant<((Is + Js) + ... + 0)>; // expected-error {{pack expansion contains parameter packs 'Is' and 'Js' that have different lengths (1 vs. 2)}}
+template  using type = Constant<((Is + Js) + ... + 0)>; // expected-error {{pack expansion contains parameter pack 'Js' that has a different length (1 vs. 2) from outer parameter packs}}
   };
 
   Sum<1>::type<1, 2> x; // expected-note {{instantiation of}}
Index: clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp
===
--- clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp
+++ clang/test/CXX/temp/temp.decls/temp.variadic/p5.cpp
@@ -473,51 +473,45 @@
 }
 }
 
-namespace pr56094 {
-template  struct D {
-  template  using B = int(int (*...p)(T, U));
-  // expected-error@-1 {{pack expansion contains parameter packs 'T' and 'U' that have different lengths (1 vs. 2)}}
-  template  D(B *);
-  // expected-note@-1 {{in instantiation of template type alias 'B' requested here}}
+namespace GH58452 {
+template  struct A {
+  template  using B = void(As...(Bs));
 };
-using t1 = D::B;
-// expected-note@-1 {{in instantiation of template class 'pr56094::D' requested here}}
-
-template  struct F {};
-template  struct G {};
-template  struct E {
-  template  using B = G...>;
-  // expected-error@-1 {{pack expansion contains parameter packs 'I' and 'U' that have different lengths (1 vs. 2)}}
-  template  E(B *);
-  // expected-note@-1 {{in instantiation of template type alias 'B' requested here}}
+
+template  struct C {
+template  using D = typename A::template B;
 };
-using t2 = E::B;
-// expected-note@-1 {{in instantiation of template class 'pr56094::E' requested here}}
-} // namespace pr56094
-
-namespace GH56094 {
-#if __cplusplus >= 201402L
-template  struct A; // expected-note {{template is declared here}}
-template  using B = char;
-template  int C{ A>{}... }; // expected-error {{implicit instantiation of undefined template}}
-#endif
-} // namespace GH56094
 
-namespace GH58679 {
-#if __cplusplus >= 201402L
-template  constexpr int A = 1;
+using t1 = C::template D;
 
-template  struct B;
-template <> struct B<1> { using b1 = void; };
+template 
+using ConditionalRewrite = B;
 
-template  using C = char;
+template 
+using SignatureType = int;
 
-template  int D{ B>>{}... };
+template 
+struct Type1 {
+template 
+using

[PATCH] D145671: [clang] Remove legacy -m(no)-code-object-v3 options

[Konstantin Zhuravlyov via Phabricator via cfe-commits]

kzhuravl added a comment.

In D145671#4181568 , @yaxunl wrote:

> Did you go through the deprecation process for this option? We need to send a 
> documentation team first so that it is announced to the users. Then in the 
> next release we can deprecate it.

Yes, it went through deprecation process. V2 has been deprecated in full for 
more than a year now.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145671

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

[clang] 9dcf6b1 - [PS4/PS5] Remove C_INCLUDE_DIRS handling

[Paul Robinson via cfe-commits]

Author: Paul Robinson
Date: 2023-03-09T09:26:50-08:00
New Revision: 9dcf6b19daf8980a02a5b9206126b3eff7a37e01

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

LOG: [PS4/PS5] Remove C_INCLUDE_DIRS handling

We don't configure this way and don't intend to.

Added: 


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

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/PS4CPU.cpp 
b/clang/lib/Driver/ToolChains/PS4CPU.cpp
index fc5d46bc25605..b3e14618f307e 100644
--- a/clang/lib/Driver/ToolChains/PS4CPU.cpp
+++ b/clang/lib/Driver/ToolChains/PS4CPU.cpp
@@ -304,19 +304,6 @@ void toolchains::PS4PS5Base::AddClangSystemIncludeArgs(
   if (DriverArgs.hasArg(options::OPT_nostdlibinc))
 return;
 
-  // Add dirs specified via 'configure --with-c-include-dirs'.
-  StringRef CIncludeDirs(C_INCLUDE_DIRS);
-  if (!CIncludeDirs.empty()) {
-SmallVector dirs;
-CIncludeDirs.split(dirs, ":");
-for (StringRef dir : dirs) {
-  StringRef Prefix =
-llvm::sys::path::is_absolute(dir) ? StringRef(D.SysRoot) : "";
-  addExternCSystemInclude(DriverArgs, CC1Args, Prefix + dir);
-}
-return;
-  }
-
   addExternCSystemInclude(DriverArgs, CC1Args,
   SDKRootDir + "/target/include");
   addExternCSystemInclude(DriverArgs, CC1Args,



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

[PATCH] D145671: [clang] Remove legacy -m(no)-code-object-v3 options

[Yaxun Liu via Phabricator via cfe-commits]

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

LGTM. Thanks.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145671

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

[PATCH] D145517: MSVC: support version preference with search

[Saleem Abdulrasool via Phabricator via cfe-commits]

compnerd added a comment.

Sure thing, I can try to write up some details about that @hans!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145517

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

[PATCH] D142914: [MLIR][OpenMP] Added OMPIRBuilder support for Target Data directives.

[Kiran Chandramohan via Phabricator via cfe-commits]

kiranchandramohan added inline comments.



Comment at: 
mlir/lib/Target/LLVMIR/Dialect/OpenMP/OpenMPToLLVMIRTranslation.cpp:1357
+/// Process MapOperands for Target Data directives.
+static LogicalResult processMapOperand(
+llvm::IRBuilderBase &builder, LLVM::ModuleTranslation &moduleTranslation,

TIFitis wrote:
> TIFitis wrote:
> > kiranchandramohan wrote:
> > > TIFitis wrote:
> > > > kiranchandramohan wrote:
> > > > > TIFitis wrote:
> > > > > > kiranchandramohan wrote:
> > > > > > > Isn't it possible to sink this whole function into the 
> > > > > > > OpenMPIRBuilder by passing it a list of `mapOpValue` and 
> > > > > > > `mapTypeFlags`?
> > > > > > > `lvm::Value *mapOpValue = moduleTranslation.lookupValue(mapOp);`
> > > > > > > 
> > > > > > > Did i miss something? Or is this in anticipation of more 
> > > > > > > processing required for other types?
> > > > > > I'm not fully sure but we might need more MLIR related things when 
> > > > > > supporting types other than LLVMPointerType. Also there is a call 
> > > > > > to mlir::LLVM::createMappingInformation.
> > > > > > 
> > > > > > I guess it might still be possible to move most of it to the 
> > > > > > IRBuilder, would you like me to do that?
> > > > > Callbacks are useful when there is frontend-specific handling that is 
> > > > > required. If more types require to be handled then it is better to 
> > > > > have the callback. We can revisit this after all types are handled. I 
> > > > > assume, the current handling is for scalars and arrays of known-size.
> > > > I am a novice at FORTRAN so I'm not aware of all  the types and 
> > > > scenarios.
> > > > 
> > > > I've tested the following cases and they work end-to-end:
> > > > 
> > > > **Fortran:**
> > > > ```
> > > > subroutine openmp_target_data_region(a)
> > > > real :: a(*)
> > > > integer :: b(1024)
> > > > character :: c
> > > > integer, pointer :: p
> > > > !$omp target enter data map(to: a, b, c, p)
> > > > end subroutine openmp_target_data_region
> > > > ```
> > > > 
> > > > **LLVM IR(** `flang-new -fc1 -emit-llvm -fopenmp test.f90 -o test.ll`** 
> > > > ):**
> > > > 
> > > > ```
> > > > ; ModuleID = 'FIRModule'
> > > > source_filename = "FIRModule"
> > > > target datalayout = 
> > > > "e-m:e-p270:32:32-p271:32:32-p272:64:64-i64:64-f80:128-n8:16:32:64-S128"
> > > > target triple = "x86_64-unknown-linux-gnu"
> > > > 
> > > > %struct.ident_t = type { i32, i32, i32, i32, ptr }
> > > > 
> > > > @0 = private unnamed_addr constant [13 x i8] c"loc(unknown)\00", align 1
> > > > @1 = private unnamed_addr constant [56 x i8] 
> > > > c";/home/akash/Documents/scratch/test2.f90;unknown;3;16;;\00", align 1
> > > > @2 = private unnamed_addr constant [56 x i8] 
> > > > c";/home/akash/Documents/scratch/test2.f90;unknown;4;18;;\00", align 1
> > > > @3 = private unnamed_addr constant [56 x i8] 
> > > > c";/home/akash/Documents/scratch/test2.f90;unknown;5;25;;\00", align 1
> > > > @4 = private unnamed_addr constant [23 x i8] 
> > > > c";unknown;unknown;0;0;;\00", align 1
> > > > @5 = private unnamed_addr constant %struct.ident_t { i32 0, i32 2, i32 
> > > > 0, i32 22, ptr @4 }, align 8
> > > > @.offload_maptypes = private unnamed_addr constant [4 x i64] [i64 1, 
> > > > i64 1, i64 1, i64 1]
> > > > @.offload_mapnames = private constant [4 x ptr] [ptr @0, ptr @1, ptr 
> > > > @2, ptr @3]
> > > > 
> > > > declare ptr @malloc(i64)
> > > > 
> > > > declare void @free(ptr)
> > > > 
> > > > define void @openmp_target_data_region_(ptr %0) {
> > > >   %2 = alloca [4 x ptr], align 8
> > > >   %3 = alloca [4 x ptr], align 8
> > > >   %4 = alloca [4 x i64], align 8
> > > >   %5 = alloca [1024 x i32], i64 1, align 4
> > > >   %6 = alloca [1 x i8], i64 1, align 1
> > > >   %7 = alloca { ptr, i64, i32, i8, i8, i8, i8 }, i64 1, align 8
> > > >   %8 = alloca ptr, i64 1, align 8
> > > >   store ptr null, ptr %8, align 8
> > > >   br label %entry
> > > > 
> > > > entry:; preds = %1
> > > >   %9 = getelementptr inbounds [4 x ptr], ptr %2, i32 0, i32 0
> > > >   store ptr %0, ptr %9, align 8
> > > >   %10 = getelementptr inbounds [4 x ptr], ptr %3, i32 0, i32 0
> > > >   store ptr %0, ptr %10, align 8
> > > >   %11 = getelementptr inbounds [4 x i64], ptr %4, i32 0, i32 0
> > > >   store i64 ptrtoint (ptr getelementptr (ptr, ptr null, i32 1) to i64), 
> > > > ptr %11, align 8
> > > >   %12 = getelementptr inbounds [4 x ptr], ptr %2, i32 0, i32 1
> > > >   store ptr %5, ptr %12, align 8
> > > >   %13 = getelementptr inbounds [4 x ptr], ptr %3, i32 0, i32 1
> > > >   store ptr %5, ptr %13, align 8
> > > >   %14 = getelementptr inbounds [4 x i64], ptr %4, i32 0, i32 1
> > > >   store i64 ptrtoint (ptr getelementptr (ptr, ptr null, i32 1) to i64), 
> > > > ptr %14, align 8
> > > >   %15 = getelementptr inbounds [4 x ptr], ptr %2, i32 0, i32 2
> > > >   store ptr %6, ptr %15, align 8
> > > >   %16 = getelementptr inbounds [4 x ptr], ptr 

[PATCH] D83906: [CodeGen] Emit a call instruction instead of an invoke if the called llvm function is marked nounwind

[Hongtao Yu via Phabricator via cfe-commits]

hoy added a comment.



In D83906#4180435 , @dexonsmith wrote:

> Oh, de-refining is pretty nifty / evil. This patch has background:
> https://reviews.llvm.org/D18634
>
> Since 2016, the optimizer is not allowed to do IPA on functions that can be 
> de-refined (such as `linkonce_odr` functions).
>
> Here's a hypothetical problematic scenario for the optimizer:
>
> - original IR for B has a `throw` somewhere
> - function A invokes function B
> - in this TU, B is optimized and removes exceptions, and gets marked 
> `nounwind`
> - function A leverages the `nounwind` to turn the `invoke` into a `call`
> - function B is de-refined at link/load time: linker chooses a *different* 
> function B which still has a `throw`
> - "evil magic" happens (see the discussions around the patch linked above)
> - a crash is introduced
>
> At first blush, it sounds like this could only be a problem if the code has 
> UB in it. However, read the above patch (and follow-ups, and related 
> discussion) for a variety of examples of non-UB cases where IPA on 
> de-refineable functions introduces crashes. I don't know for sure this could 
> be a problem for `nounwind` specifically, but in general the LLVM optimizer 
> doesn't look at attributes of de-refineable functions.
>
> (Note that if you're doing LTO (like AutoFDO), this usually won't block 
> optimization, since at LTO time there are very few de-refineable functions 
> (most `linkonce_odr` functions are internalized, and not exported as weak). 
> So if we added a `-cc1` flag to prefer "stable IR" over "frontend peepholes", 
> it would make sense for `-flto` to imply it.)
>
> On the other hand, the frontend knows the token sequence from the source 
> language. It knows whether function `B` is inherently `nounwind` based on its 
> ODR token sequence; in which case, it's safe to use the attribute for an IPA 
> peephole.
>
> 
>
> BTW, I'm not personally against removing this peephole from the frontend 
> (even without a flag), or limiting it somehow to cases where it doesn't make 
> IR output unstable. I like the idea of stable IRGen output.
>
> Nevertheless, it feels like removing IPA-based peepholes from Clang in the 
> name of stable IRGen output is a change in direction, which might deserve a 
> discussion in the forums rather than in a particular patch review.



In D83906#4181876 , @rjmccall wrote:

> There are *some* properties we can still assume about `linkonce_odr` 
> functions despite them being replaceable at link time.  The high-level 
> language guarantee we're starting from is that the source semantics of all 
> versions of the function are identical.  The version of the function we're 
> looking at has been transformed from the original source — it is, after all, 
> now LLVM IR, not C/C++ — but it has presumably faithfully preserved the 
> source semantics.  We can therefore rely on any properties of the semantics 
> that are required to be preserved by transformation, which includes things 
> like "does it terminate", "what value does it return", "what side effects 
> does it perform", and so on.  What we can't rely on are properties of the 
> implementation that are not required to be preserved by transformation, like 
> whether or not it uses a certain argument — transformations are permitted to 
> change that.
>
> The output-stability argument is an interesting one.  The critical thing here 
> is to avoid instability on the same source.  When the source is different, I 
> mean, it'd be nice to make a best effort at stability, but even putting 
> optimization aside, things like header processing order or template 
> instantiation order are necessarily going to affect things like order in the 
> functions lists.  That's going to affect output, at the very least in terms 
> of object file order, but also in that we can't realistically promise that 
> function processing order in the optimization will *never* have any impact.  
> Our interprocedural passes generally try to work in call-dependency order, 
> but that's not a perfect tree, and function order inevitably comes into it.
>
> With all that said, I don't feel strongly that we need to preserve this 
> frontend optimization if it's causing real problems.

Thanks for the detailed explanation about de-refining!

I feel a bit confused about `linkonce_odr`. From the LLVM IR reference I see 
the definition of

  linkonce_odr, weak_odr
  Some languages allow differing globals to be merged, such as two functions 
with different semantics. Other languages, such as C++, ensure that only 
equivalent globals are ever merged (the “one definition rule” — “ODR”). Such 
languages can use the linkonce_odr and weak_odr linkage types to indicate that 
the global will only be merged with equivalent globals. These linkage types are 
otherwise the same as their non-odr versions.

It sounds to me that at link time only equivalent symbols can repla

[PATCH] D143287: [Clang][X86] Change X86 cast intrinsics to use __builtin_nondeterministic_value

[Manuel Brito via Phabricator via cfe-commits]

ManuelJBrito updated this revision to Diff 503819.
ManuelJBrito added a comment.

Rebase

`avx-cast-builtins.c` was moved to D144903 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143287

Files:
  clang/lib/Headers/avx512fintrin.h
  clang/lib/Headers/avx512fp16intrin.h
  clang/lib/Headers/avxintrin.h
  clang/test/CodeGen/X86/avx-builtins.c
  clang/test/CodeGen/X86/avx512f-builtins.c
  clang/test/CodeGen/X86/avx512fp16-builtins.c

Index: clang/test/CodeGen/X86/avx512fp16-builtins.c
===
--- clang/test/CodeGen/X86/avx512fp16-builtins.c
+++ clang/test/CodeGen/X86/avx512fp16-builtins.c
@@ -325,19 +325,22 @@
 
 __m256h test_mm256_castph128_ph256(__m128h __a) {
   // CHECK-LABEL: test_mm256_castph128_ph256
-  // CHECK: shufflevector <8 x half> %{{.*}}, <8 x half> %{{.*}}, <16 x i32> 
+  // CHECK: [[A:%.*]] = freeze <8 x half> poison 
+  // CHECK: shufflevector <8 x half> %{{.*}}, <8 x half> [[A]], <16 x i32> 
   return _mm256_castph128_ph256(__a);
 }
 
 __m512h test_mm512_castph128_ph512(__m128h __a) {
   // CHECK-LABEL: test_mm512_castph128_ph512
-  // CHECK: shufflevector <8 x half> %{{.*}}, <8 x half> %{{.*}}, <32 x i32> 
+  // CHECK: [[A:%.*]] = freeze <8 x half> poison 
+  // CHECK: shufflevector <8 x half> %{{.*}}, <8 x half> [[A]], <32 x i32> 
   return _mm512_castph128_ph512(__a);
 }
 
 __m512h test_mm512_castph256_ph512(__m256h __a) {
   // CHECK-LABEL: test_mm512_castph256_ph512
-  // CHECK: shufflevector <16 x half> %{{.*}}, <16 x half> %{{.*}}, <32 x i32> 
+  // CHECK: [[A:%.*]] = freeze <16 x half> poison 
+  // CHECK: shufflevector <16 x half> %{{.*}}, <16 x half> [[A]], <32 x i32> 
   return _mm512_castph256_ph512(__a);
 }
 
Index: clang/test/CodeGen/X86/avx512f-builtins.c
===
--- clang/test/CodeGen/X86/avx512f-builtins.c
+++ clang/test/CodeGen/X86/avx512f-builtins.c
@@ -8987,13 +8987,15 @@
 
 __m512 test_mm512_castps128_ps512(__m128 __A) {
   // CHECK-LABEL: @test_mm512_castps128_ps512
-  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> %{{.*}}, <16 x i32> 
+  // CHECK: [[A:%.*]] = freeze <4 x float> poison 
+  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> [[A]], <16 x i32> 
   return _mm512_castps128_ps512(__A); 
 }
 
 __m512d test_mm512_castpd128_pd512(__m128d __A) {
   // CHECK-LABEL: @test_mm512_castpd128_pd512
-  // CHECK: shufflevector <2 x double> %{{.*}}, <2 x double> %{{.*}}, <8 x i32> 
+  // CHECK: [[A:%.*]] = freeze <2 x double> poison 
+  // CHECK: shufflevector <2 x double> %{{.*}}, <2 x double> [[A]], <8 x i32> 
   return _mm512_castpd128_pd512(__A); 
 }
 
@@ -9086,7 +9088,8 @@
 __m512d test_mm512_castpd256_pd512(__m256d a)
 {
   // CHECK-LABEL: @test_mm512_castpd256_pd512
-  // CHECK: shufflevector <4 x double> {{.*}} 
+  // CHECK: [[A:%.*]] = freeze <4 x double> poison 
+  // CHECK: shufflevector <4 x double> {{.*}}, <4 x double> [[A]], 
   return _mm512_castpd256_pd512(a);
 }
 
@@ -9112,13 +9115,15 @@
 }
 __m512i test_mm512_castsi128_si512(__m128i __A) {
   // CHECK-LABEL: @test_mm512_castsi128_si512
-  // CHECK: shufflevector <2 x i64> %{{.*}}, <2 x i64> %{{.*}}, <8 x i32> 
+  // CHECK: [[A:%.*]] = freeze <2 x i64> poison 
+  // CHECK: shufflevector <2 x i64> %{{.*}}, <2 x i64> [[A]], <8 x i32> 
   return _mm512_castsi128_si512(__A); 
 }
 
 __m512i test_mm512_castsi256_si512(__m256i __A) {
   // CHECK-LABEL: @test_mm512_castsi256_si512
-  // CHECK: shufflevector <4 x i64> %{{.*}}, <4 x i64> %{{.*}}, <8 x i32> 
+  // CHECK: [[A:%.*]] = freeze <4 x i64> poison 
+  // CHECK: shufflevector <4 x i64> %{{.*}}, <4 x i64> [[A]], <8 x i32> 
   return _mm512_castsi256_si512(__A); 
 }
 
Index: clang/test/CodeGen/X86/avx-builtins.c
===
--- clang/test/CodeGen/X86/avx-builtins.c
+++ clang/test/CodeGen/X86/avx-builtins.c
@@ -143,7 +143,8 @@
 
 __m256d test_mm256_castpd128_pd256(__m128d A) {
   // CHECK-LABEL: test_mm256_castpd128_pd256
-  // CHECK: shufflevector <2 x double> %{{.*}}, <2 x double> %{{.*}}, <4 x i32> 
+  // CHECK: [[A:%.*]] = freeze <2 x double> poison
+  // CHECK: shufflevector <2 x double> %{{.*}}, <2 x double> [[A]], <4 x i32> 
   return _mm256_castpd128_pd256(A);
 }
 
@@ -165,7 +166,8 @@
 
 __m256 test_mm256_castps128_ps256(__m128 A) {
   // CHECK-LABEL: test_mm256_castps128_ps256
-  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> %{{.*}}, <8 x i32> 
+  // CHECK: [[A:%.*]] = freeze <4 x float> poison
+  // CHECK: shufflevector <4 x float> %{{.*}}, <4 x float> [[A]], <8 x i32> 
   return _mm256_castps128_ps256(A);
 }
 
@@ -177,7 +179,8 @@
 
 __m256i test_mm256_castsi128_si256(__m128i A) {
   // CHECK-LABEL: test_mm256_castsi128_si256
-  // CHECK: shufflevector <2 x i64> %{{.*}}, <2 x i64> %{{.*}}, <4 x i32> 
+  // CHECK: [[A:%.*]] = freeze <

[PATCH] D145509: [HIP] Fix temporary files

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl updated this revision to Diff 503826.
yaxunl marked an inline comment as done.
yaxunl added a comment.

fix comments and tests


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

https://reviews.llvm.org/D145509

Files:
  clang/include/clang/Driver/Driver.h
  clang/lib/Driver/Driver.cpp
  clang/test/Driver/hip-link-bc-to-bc.hip
  clang/test/Driver/hip-temps-linux.hip
  clang/test/Driver/hip-temps-windows.hip

Index: clang/test/Driver/hip-temps-windows.hip
===
--- /dev/null
+++ clang/test/Driver/hip-temps-windows.hip
@@ -0,0 +1,18 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: amdgpu-registered-target
+// REQUIRES: system-windows
+
+// Check no temporary files or directores are left after compilation.
+// RUN: rm -rf %t/mytmp
+// RUN: mkdir -p %t/mytmp
+// RUN: env TMP="%t/mytmp" %clang --target=x86_64-pc-windows-msvc -nogpulib -nogpuinc \
+// RUN:   --rocm-path=%S/Inputs/rocm -nostdinc -nostdlib -c \
+// RUN:   --offload-arch=gfx1030 -emit-llvm -v %s 2>&1 | \
+// RUN:   FileCheck -check-prefixes=CHECK %s
+// RUN: ls %t/mytmp >%t/mytmp.txt 2>&1
+// RUN: touch %t/empty.txt
+// RUN: diff %t/mytmp.txt %t/empty.txt
+
+// CHECK: -o {{.*}}mytmp{{[|/]}}hip-temps-windows-gfx1030-{{.*}}.bc
+
+int main() {}
Index: clang/test/Driver/hip-temps-linux.hip
===
--- /dev/null
+++ clang/test/Driver/hip-temps-linux.hip
@@ -0,0 +1,18 @@
+// REQUIRES: x86-registered-target
+// REQUIRES: amdgpu-registered-target
+// REQUIRES: system-linux
+
+// Check no temporary files or directores are left after compilation.
+// RUN: rm -rf %t/mytmp
+// RUN: mkdir -p %t/mytmp
+// RUN: env TMPDIR="%t/mytmp" %clang --target=x86_64-linux-gnu -nogpulib -nogpuinc \
+// RUN:   --rocm-path=%S/Inputs/rocm -nostdinc -nostdlib -c \
+// RUN:   --offload-arch=gfx1030 -emit-llvm -v %s 2>&1 | \
+// RUN:   FileCheck -check-prefixes=CHECK %s
+// RUN: ls %t/mytmp >%t/mytmp.txt 2>&1
+// RUN: touch %t/empty.txt
+// RUN: diff %t/mytmp.txt %t/empty.txt
+
+// CHECK: -o {{.*}}/mytmp/hip-temps-linux-gfx1030-{{.*}}.bc
+
+int main() {}
Index: clang/test/Driver/hip-link-bc-to-bc.hip
===
--- clang/test/Driver/hip-link-bc-to-bc.hip
+++ clang/test/Driver/hip-link-bc-to-bc.hip
@@ -11,10 +11,10 @@
 // RUN:   2>&1 | FileCheck -check-prefix=BITCODE %s
 
 // BITCODE: "{{.*}}clang-offload-bundler" "-type=bc" "-targets=host-x86_64-unknown-linux-gnu,hip-amdgcn-amd-amdhsa-gfx906" "-input={{.*}}bundle1.bc" "-output=[[B1HOST:.*\.bc]]" "-output=[[B1DEV1:.*\.bc]]" "-unbundle" "-allow-missing-bundles"
-// BITCODE: "{{.*}}clang{{.*}}" "-o" "[[B1DEV2:.*bundle1-gfx906.bc]]" "-x" "ir" "[[B1DEV1]]"
+// BITCODE: "{{.*}}clang{{.*}}" "-o" "[[B1DEV2:.*bundle1-gfx906-.*\.bc]]" "-x" "ir" "[[B1DEV1]]"
 
 // BITCODE: "{{.*}}clang-offload-bundler" "-type=bc" "-targets=host-x86_64-unknown-linux-gnu,hip-amdgcn-amd-amdhsa-gfx906" "-input={{.*}}bundle2.bc" "-output=[[B2HOST:.*\.bc]]" "-output=[[B2DEV1:.*\.bc]]" "-unbundle" "-allow-missing-bundles"
-// BITCODE: "{{.*}}clang{{.*}}" "-o" "[[B2DEV2:.*bundle2-gfx906.bc]]" "-x" "ir" "[[B2DEV1]]"
+// BITCODE: "{{.*}}clang{{.*}}" "-o" "[[B2DEV2:.*bundle2-gfx906-.*\.bc]]" "-x" "ir" "[[B2DEV1]]"
 
 // BITCODE: "{{.*}}llvm-link" "-o" "bundle1-hip-amdgcn-amd-amdhsa-gfx906.bc" "[[B1DEV2]]" "[[B2DEV2]]"
 
Index: clang/lib/Driver/Driver.cpp
===
--- clang/lib/Driver/Driver.cpp
+++ clang/lib/Driver/Driver.cpp
@@ -5545,7 +5545,8 @@
 
 const char *Driver::CreateTempFile(Compilation &C, StringRef Prefix,
StringRef Suffix, bool MultipleArchs,
-   StringRef BoundArch) const {
+   StringRef BoundArch,
+   bool NeedUniqueDirectory) const {
   SmallString<128> TmpName;
   Arg *A = C.getArgs().getLastArg(options::OPT_fcrash_diagnostics_dir);
   std::optional CrashDirectory =
@@ -5565,9 +5566,15 @@
 }
   } else {
 if (MultipleArchs && !BoundArch.empty()) {
-  TmpName = GetTemporaryDirectory(Prefix);
-  llvm::sys::path::append(TmpName,
-  Twine(Prefix) + "-" + BoundArch + "." + Suffix);
+  if (NeedUniqueDirectory) {
+TmpName = GetTemporaryDirectory(Prefix);
+llvm::sys::path::append(TmpName,
+Twine(Prefix) + "-" + BoundArch + "." + Suffix);
+  } else {
+TmpName =
+GetTemporaryPath((Twine(Prefix) + "-" + BoundArch).str(), Suffix);
+  }
+
 } else {
   TmpName = GetTemporaryPath(Prefix, Suffix);
 }
@@ -5683,7 +5690,16 @@
 StringRef Name = llvm::sys::path::filename(BaseInput);
 std::pair Split = Name.split('.');
 const char *Suffix = types::getTypeTempSuffix(JA.getType(), IsCLMode());
-return CreateTempFile(C, Split.first, 

[PATCH] D145591: [clang][HIP][OpenMP] Add warning if mixed HIP / OpenMP offloading

[Artem Belevich via Phabricator via cfe-commits]

tra added a subscriber: jhuber6.
tra added a comment.

In D145591#4180908 , @mhalk wrote:

> For example: when using `-x hip -fopenmp --offload-arch=...` (+ other 
> reasonable parameters) a HIP program with OpenMP target directives will 
> compile without warning / error.
> But only host-related OpenMP code will be executed properly.
>
> Another hint that HIP and OpenMP target offloading do not work concurrently 
> ATM is that when compiling with `-x hip -fopenmp -fopenmp-targets=...` clang 
> will throw an error.

It sounds like what we want is to make `-x hip` and `-fopenmp` mutually 
exclusive, with a hard error when both are used. If you look at the problem as 
"-fopenmp completely breaks HIP compilation", a warning is a bit too weak of a 
measure, IMO.

We can restate it all as "mixing offloading modes is not supported" and 
generalize it to both CUDA and HIP.

@jhuber6 - WDYT?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145591

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

[PATCH] D145704: Revert "Set FLT_EVAL_METHOD to -1 when fast-math is enabled."

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam created this revision.
zahiraam added reviewers: andrew.w.kaylor, aaron.ballman.
Herald added a subscriber: pengfei.
Herald added a project: All.
zahiraam requested review of this revision.
Herald added a project: clang.

Setting __FLT_EVAL_METHOD__ to -1 with fast-math will set 
__GLIBC_FLT_EVAL_METHOD to 2 and long double ends up being used for
float_t and double_t. This creates some ABI breakage with various C libraries.

See details here: https://github.com/llvm/llvm-project/issues/60781

This reverts commit bbf0d1932a3c1be970ed8a580e51edf571b80fd5 
.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D145704

Files:
  clang/include/clang/Lex/Preprocessor.h
  clang/lib/Lex/PPMacroExpansion.cpp
  clang/lib/Lex/Preprocessor.cpp
  clang/lib/Sema/SemaAttr.cpp
  clang/test/CodeGen/X86/fexcess-precision.c
  clang/test/CodeGen/eval-method-fast-math.cpp
  clang/test/Preprocessor/flt_eval_macro.cpp

Index: clang/test/Preprocessor/flt_eval_macro.cpp
===
--- clang/test/Preprocessor/flt_eval_macro.cpp
+++ clang/test/Preprocessor/flt_eval_macro.cpp
@@ -17,7 +17,7 @@
 // RUN:   %s -o - | FileCheck %s  -strict-whitespace
 
 // RUN: %clang_cc1 -E -dM -triple=x86_64-apple-macos13.0 -ffast-math \
-// RUN:   %s -o - | FileCheck %s -check-prefix=CHECK-MINUS-ONE -strict-whitespace
+// RUN:   %s -o - | FileCheck %s -check-prefix=CHECK -strict-whitespace
 
 // RUN: %clang_cc1 -E -dM -triple i386-pc-windows -target-cpu pentium4 %s -o - \
 // RUN:   | FileCheck %s  -strict-whitespace
Index: clang/test/CodeGen/eval-method-fast-math.cpp
===
--- clang/test/CodeGen/eval-method-fast-math.cpp
+++ /dev/null
@@ -1,117 +0,0 @@
-// RUN: %clang_cc1 -fexperimental-strict-floating-point  \
-// RUN: -triple x86_64-linux-gnu -emit-llvm -o - %s  \
-// RUN: | FileCheck %s -check-prefixes=CHECK
-
-// RUN: %clang_cc1 -triple i386--linux -emit-llvm -o - %s \
-// RUN: | FileCheck %s -check-prefixes=CHECK-EXT
-
-// RUN: %clang_cc1 -fexperimental-strict-floating-point  \
-// RUN: -mreassociate -freciprocal-math -ffp-contract=fast \
-// RUN: -ffast-math -triple x86_64-linux-gnu \
-// RUN: -emit-llvm -o - %s \
-// RUN: | FileCheck %s -check-prefixes=CHECK-FAST
-
-// RUN: %clang_cc1 -triple i386--linux -mreassociate -freciprocal-math \
-// RUN: -ffp-contract=fast -ffast-math -emit-llvm -o - %s \
-// RUN: | FileCheck %s -check-prefixes=CHECK-FAST
-
-float a = 1.0f, b = 2.0f, c = 3.0f;
-#pragma float_control(precise, off)
-float res2 = a + b + c;
-int val3 = __FLT_EVAL_METHOD__;
-#pragma float_control(precise, on)
-float res3 = a + b + c;
-int val4 = __FLT_EVAL_METHOD__;
-
-// CHECK: @val3 = global i32 -1
-// CHECK: @val4 = global i32 0
-
-// CHECK-EXT: @val3 = global i32 -1
-// CHECK-EXT: @val4 = global i32 2
-
-// CHECK-FAST: @val3 = global i32 -1
-// CHECK-FAST: @val4 = global i32 -1
-
-float res;
-int add(float a, float b, float c) {
-  // CHECK: fadd float
-  // CHECK: load float, ptr
-  // CHECK: fadd float
-  // CHECK: store float
-  // CHECK: ret i32 0
-  res = a + b + c;
-  return __FLT_EVAL_METHOD__;
-}
-
-int add_precise(float a, float b, float c) {
-#pragma float_control(precise, on)
-  // CHECK: fadd float
-  // CHECK: load float, ptr
-  // CHECK: fadd float
-  // CHECK: store float
-  // CHECK: ret i32 0
-  res = a + b + c;
-  return __FLT_EVAL_METHOD__;
-}
-
-#pragma float_control(push)
-#pragma float_control(precise, on)
-int add_precise_1(float a, float b, float c) {
-  // CHECK: fadd float
-  // CHECK: load float, ptr
-  // CHECK: fadd float
-  // CHECK: store float
-  // CHECK: ret i32 0
-  res = a + b + c;
-  return __FLT_EVAL_METHOD__;
-}
-#pragma float_control(pop)
-
-int add_not_precise(float a, float b, float c) {
-  // Fast-math is enabled with this pragma.
-#pragma float_control(precise, off)
-  // CHECK: fadd fast float
-  // CHECK: load float, ptr
-  // CHECK: fadd fast float
-  // CHECK: float {{.*}}, ptr
-  // CHECK: ret i32 -1
-  res = a + b + c;
-  return __FLT_EVAL_METHOD__;
-}
-
-#pragma float_control(push)
-// Fast-math is enabled with this pragma.
-#pragma float_control(precise, off)
-int add_not_precise_1(float a, float b, float c) {
-  // CHECK: fadd fast float
-  // CHECK: load float, ptr
-  // CHECK: fadd fast float
-  // CHECK: float {{.*}}, ptr
-  // CHECK: ret i32 -1
-  res = a + b + c;
-  return __FLT_EVAL_METHOD__;
-}
-#pragma float_control(pop)
-
-int getFPEvalMethod() {
-  // CHECK: ret i32 0
-  return __FLT_EVAL_METHOD__;
-}
-
-float res1;
-int whatever(float a, float b, float c) {
-#pragma float_control(precise, off)
-  // CHECK: load float, ptr
-  // CHECK: fadd fast float
-  // CHECK: store float {{.*}}, ptr
-  // CHECK: store i32 -1
-  // CHECK: store i32 0
-  // CHECK: ret i32 -1
-  res1 = a + b + c;
-  int val1 = __FLT_EVAL_METHOD__;
-  {
-#pragma float_control(precise, on)
-int v

[PATCH] D145270: Add codegen for llvm exp/exp2 elementwise builtins

[Florian Hahn via Phabricator via cfe-commits]

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

LGTM, thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145270

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

[PATCH] D145704: Revert "Set FLT_EVAL_METHOD to -1 when fast-math is enabled."

[Zahira Ammarguellat via Phabricator via cfe-commits]

zahiraam added subscribers: Wilco1, kito-cheng, bjope.
zahiraam added a comment.

Tagging @davemgreen, @kito-cheng, @bjope and @Wilco1 for awareness.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145704

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

[PATCH] D145591: [clang][HIP][OpenMP] Add warning if mixed HIP / OpenMP offloading

[Yaxun Liu via Phabricator via cfe-commits]

yaxunl added a comment.

In D145591#4182016 , @tra wrote:

> It sounds like what we want is to make `-x hip` and `-fopenmp` mutually 
> exclusive, with a hard error when both are used. If you look at the problem 
> as "-fopenmp completely breaks HIP compilation", a warning is a bit too weak 
> of a measure, IMO.
>
> We can restate it all as "mixing offloading modes is not supported" and 
> generalize it to both CUDA and HIP.

-x hip and -fopenmp has been a valid combination. -fopenmp with -x hip allows 
non-offloading OpenMP directives in host code in HIP. It just ignores the 
offloading directives.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145591

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

[PATCH] D145644: [memprof] Add scripts to automate testdata regeneration.

[Snehasish Kumar via Phabricator via cfe-commits]

snehasish updated this revision to Diff 503850.
snehasish added a comment.

Update the script for Transforms/PGOProfile/memprof.ll.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145644

Files:
  clang/test/CodeGen/Inputs/memprof.exe
  clang/test/CodeGen/Inputs/memprof.memprofraw
  clang/test/CodeGen/Inputs/update_memprof_inputs.sh
  clang/test/CodeGen/memprof.cpp
  llvm/test/Transforms/PGOProfile/Inputs/memprof.exe
  llvm/test/Transforms/PGOProfile/Inputs/memprof.memprofraw
  llvm/test/Transforms/PGOProfile/Inputs/memprof_pgo.profraw
  llvm/test/Transforms/PGOProfile/Inputs/update_memprof_inputs.sh
  llvm/test/Transforms/PGOProfile/memprof.ll
  llvm/test/tools/llvm-profdata/Inputs/basic.memprofexe
  llvm/test/tools/llvm-profdata/Inputs/basic.memprofraw
  llvm/test/tools/llvm-profdata/Inputs/inline.memprofexe
  llvm/test/tools/llvm-profdata/Inputs/inline.memprofraw
  llvm/test/tools/llvm-profdata/Inputs/memprof-inline.exe
  llvm/test/tools/llvm-profdata/Inputs/multi.memprofexe
  llvm/test/tools/llvm-profdata/Inputs/multi.memprofraw
  llvm/test/tools/llvm-profdata/Inputs/pic.memprofexe
  llvm/test/tools/llvm-profdata/Inputs/pic.memprofraw
  llvm/test/tools/llvm-profdata/Inputs/update_memprof_inputs.sh
  llvm/test/tools/llvm-profdata/memprof-basic.test
  llvm/test/tools/llvm-profdata/memprof-inline.test
  llvm/test/tools/llvm-profdata/memprof-merge.test
  llvm/test/tools/llvm-profdata/memprof-multi.test
  llvm/test/tools/llvm-profdata/memprof-pic.test

Index: llvm/test/tools/llvm-profdata/memprof-pic.test
===
--- llvm/test/tools/llvm-profdata/memprof-pic.test
+++ llvm/test/tools/llvm-profdata/memprof-pic.test
@@ -1,40 +1,12 @@
 REQUIRES: x86_64-linux
 
-This test ensures that llvm-profdata fails with a descriptive error message
-when invoked on a memprof profiled binary which was built with position
-independent code.
-
-The input raw profile test has been generated from the following source code:
-
-```
-#include 
-#include 
-int main(int argc, char **argv) {
-  char *x = (char *)malloc(10);
-  memset(x, 0, 10);
-  free(x);
-  x = (char *)malloc(10);
-  memset(x, 0, 10);
-  free(x);
-  return 0;
-}
-```
-
-The following commands were used to compile the source to a memprof instrumented
-executable and collect a raw binary format profile. Since the profile contains
-virtual addresses for the callstack, we do not expect the raw binary profile to
-be deterministic. The summary should be deterministic apart from changes to
-the shared libraries linked in which could change the number of segments
+Since the profile contains virtual addresses for the callstack,
+we do not expect the raw binary profile to be deterministic. The
+summary should be deterministic apart from changes to the shared
+libraries linked in which could change the number of segments
 recorded.
 
-```
-clang -fuse-ld=lld -Wl,--no-rosegment -gmlt -fdebug-info-for-profiling \
-  -fmemory-profile -mno-omit-leaf-frame-pointer -fno-omit-frame-pointer \
-  -fno-optimize-sibling-calls -m64 -Wl,-build-id -pie \
-  source.c -o pic.memprofexe
-
-env MEMPROF_OPTIONS=log_path=stdout ./pic.memprofexe > pic.memprofraw
-```
-
+To update the inputs used below run Inputs/update_memprof_inputs.sh /path/to/updated/clang
 RUN: not llvm-profdata show --memory %p/Inputs/pic.memprofraw --profiled-binary %p/Inputs/pic.memprofexe -o - 2>&1 | FileCheck %s
+
 CHECK: Unsupported position independent code
Index: llvm/test/tools/llvm-profdata/memprof-multi.test
===
--- llvm/test/tools/llvm-profdata/memprof-multi.test
+++ llvm/test/tools/llvm-profdata/memprof-multi.test
@@ -1,39 +1,6 @@
 REQUIRES: x86_64-linux
 
-The input raw profile test has been generated from the following source code:
-
-```
-#include 
-#include 
-#include 
-int main(int argc, char **argv) {
-  char *x = (char *)malloc(10);
-  memset(x, 0, 10);
-  free(x);
-  __memprof_profile_dump();
-  x = (char *)malloc(10);
-  memset(x, 0, 10);
-  free(x);
-  return 0;
-}
-```
-
-The following commands were used to compile the source to a memprof instrumented
-executable and collect a raw binary format profile. Since the profile contains
-virtual addresses for the callstack, we do not expect the raw binary profile to
-be deterministic. The summary should be deterministic apart from changes to
-the shared libraries linked in which could change the number of segments
-recorded.
-
-```
-clang -fuse-ld=lld -Wl,--no-rosegment -gmlt -fdebug-info-for-profiling \
-  -fmemory-profile -mno-omit-leaf-frame-pointer -fno-omit-frame-pointer \
-  -fno-optimize-sibling-calls -m64 -Wl,-build-id -no-pie \
-  source.c -o multi.memprofexe
-
-env MEMPROF_OPTIONS=log_path=stdout ./multi.memprofexe > multi.memprofraw
-```
-
+To update the inputs used below run Inputs/update_memprof_inputs.sh /path/to/upd

[PATCH] D145644: [memprof] Add scripts to automate testdata regeneration.

[Snehasish Kumar via Phabricator via cfe-commits]

snehasish added inline comments.



Comment at: llvm/test/Transforms/PGOProfile/Inputs/update_memprof_inputs.sh:63
+  delete[] f;
+
+  // Loop ensures the two calls to recurse have stack contexts that only differ

@tejohnson Turns out the LLVM IR matching issue was due to a difference in the 
code from which the IR was generated. The one in the comments has a line offset 
of 30 from `main` to the callsite of `recurse` whereas the memprof.ll IR 
expects a line offset of 31. Perhaps a comment or blank line was omitted? I 
added a blank line here and added a comment in the update script too. 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145644

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

[PATCH] D145644: [memprof] Add scripts to automate testdata regeneration.

[Teresa Johnson via Phabricator via cfe-commits]

tejohnson added a comment.

Generally lgtm, but why did the raw profiles change size from what is currently 
committed?




Comment at: llvm/test/Transforms/PGOProfile/Inputs/update_memprof_inputs.sh:63
+  delete[] f;
+
+  // Loop ensures the two calls to recurse have stack contexts that only differ

snehasish wrote:
> @tejohnson Turns out the LLVM IR matching issue was due to a difference in 
> the code from which the IR was generated. The one in the comments has a line 
> offset of 30 from `main` to the callsite of `recurse` whereas the memprof.ll 
> IR expects a line offset of 31. Perhaps a comment or blank line was omitted? 
> I added a blank line here and added a comment in the update script too. 
Hmm, yeah its definitely possible that when the code got copied in a blank line 
was inadvertently cut.



Comment at: llvm/test/tools/llvm-profdata/Inputs/update_memprof_inputs.sh:14
+
+read -r -d '' SRC1 << EOF
+#include 

Maybe name these more clearly, like BASIC instead of SRC1, etc?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145644

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

[PATCH] D145704: Revert "Set FLT_EVAL_METHOD to -1 when fast-math is enabled."

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a subscriber: tstellar.
aaron.ballman added a comment.

Thank you for working on this! Because this is fixing an ABI break, if we can 
land this in time for the release candidate I think we should try to add this 
to 16.0 to limit damage. CC @tstellar for his opinion.

This doesn't seem to fully revert bbf0d1932a3c1be970ed8a580e51edf571b80fd5 
; that 
commit changed `clang/lib/Sema/Sema.cpp` but this commit does not back those 
changes out. Is that intentional?




Comment at: clang/test/Preprocessor/flt_eval_macro.cpp:66-68
   // CHECK: #define Name "One"
   // CHECK-MINUS-ONE: #define Name "MinusOne"
   // EXT: #define Name "Three"

This line is no longer needed because it will never be checked.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145704

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

[PATCH] D83906: [CodeGen] Emit a call instruction instead of an invoke if the called llvm function is marked nounwind

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

dexonsmith added a comment.

In D83906#4181981 , @hoy wrote:

> That said, the LLVM optimizer does not strictly subsume the front-end because 
> of how it fails to handle `linkonce_odr` functions as in 
> https://reviews.llvm.org/D18634. I'm wondering how common the `linkonce_odr` 
> linkage is for C++. In @wlei's example, none of the functions there is 
> `linkonce_odr`. Is there a particular source-level annotate that specifies 
> functions to be `linkonce_odr`?

In C++, you get `linkonce_odr` all over the place. It's basically all functions 
that are defined in C++ headers that are available for inlining.

- any function marked `inline`
- any function in a class/struct whose declaration is its definition 
(approximately all templated code)

A few exceptions:

- If a function is explicitly instantiated (e.g., member functions of `T` 
if `template class T;`), it gets `weak_odr`, which IIRC cannot be 
de-refined?
- If a function has local linkage (like free functions with `static inline`), 
it gets `internal`, which cannot be de-refined.
- If a function is marked `inline` inside an `extern "C"` block, it gets 
`available_externally`. This can also be de-refined (but without ODR, you 
wouldn't be tempted to optimize based on its attributes anyway).



> It sounds to me that at link time only equivalent symbols can replace each 
> other. Then de-refining some of those equivalent symbols should not affect 
> their semantics as far as nothrow is concerned? Just as @rjmccall pointed 
> out, the C++ language guarantee we're starting from is that the source 
> semantics of all versions of the function are identical.

The rule is subtly different. Only symbols that are source-equivalent can 
replace each other. But they aren't necessarily equivalent to the function you 
see, which may have been refined by optimization.

Here's a concrete example. Say we have function `maybe_nounwind` that is not 
`nounwind` at the source level, and a `catch_all` function that wraps it.

  // Defined in header.
  extern std::atomic Global;
  
  // LLVM: linkonce_odr
  inline int maybe_nounwind(int In) {
int Read1 = Global;
int Read2 = Global;
if (Read1 != Read2)
  throw 0;
  
return /* Big, non-inlineable computation on In */;
  }
  
  // Defined in source.
  // LLVM: nounwind
  int catch_all(int In) {
try {
  return maybe_nounwind(In);
} catch (...) {
  return -1;
}
  }

There's no UB here, since comparing two atomic loads is allowed. In rare cases, 
an unoptimized `maybe_nounwind` could throw, if another thread is changing the 
value of `Global` between the two loads.

But the optimizer will probably CSE the two atomic loads since it's allowed to 
assume that both loads happen at the same time. This refines `maybe_nounwind`. 
It'll turn into IR equivalent to:

  // Defined in header. Then optimized.
  // LLVM: linkonce_odr nounwind readnone
  inline int maybe_nounwind(int In) {
return /* Big, non-inlineable computation on In */;
  }
  
  // Defined in source. Then optimized.
  // LLVM: nounwind
  int catch_all(int In) {
try {
  return maybe_nounwind(In);
} catch (...) {
  return -1;
}
  }

It's important that `catch_all` is NOT optimized based on `maybe_nounwind`'s 
new `nounwind` attribute. At link time, it's possible for the linker to choose 
an unoptimized copy of `maybe_nounwind`. Just in case it does, `catch_all` 
needs to keep its `try/catch` block, since unoptimized `maybe_nounwind` can 
throw. Similarly, `catch_all` should not be marked `readnone`, even though the 
refined/optimized `maybe_nounwind` is `readnone`, since a de-refined copy reads 
from memory.

In D83906#4181876 , @rjmccall wrote:

> There are *some* properties we can still assume about `linkonce_odr` 
> functions despite them being replaceable at link time.  The high-level 
> language guarantee we're starting from is that the source semantics of all 
> versions of the function are identical.  The version of the function we're 
> looking at has been transformed from the original source — it is, after all, 
> now LLVM IR, not C/C++ — but it has presumably faithfully preserved the 
> source semantics.  We can therefore rely on any properties of the semantics 
> that are required to be preserved by transformation, which includes things 
> like "does it terminate", "what value does it return", "what side effects 
> does it perform", and so on.  What we can't rely on are properties of the 
> implementation that are not required to be preserved by transformation, like 
> whether or not it uses a certain argument — transformations are permitted to 
> change that.



- At IRGen time, you know the LLVM attributes have not been adjusted after the 
optimized refined the function's behaviour. It should be safe to have IPA 
peepholes, as long as IRGen's other peepholes don't refine behaviour and add 
attributes based on that.
-

[PATCH] D145644: [memprof] Add scripts to automate testdata regeneration.

[Snehasish Kumar via Phabricator via cfe-commits]

snehasish updated this revision to Diff 503859.
snehasish added a comment.

Update the script in test/tool/llvm-profdata/Inputs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D145644

Files:
  clang/test/CodeGen/Inputs/memprof.exe
  clang/test/CodeGen/Inputs/memprof.memprofraw
  clang/test/CodeGen/Inputs/update_memprof_inputs.sh
  clang/test/CodeGen/memprof.cpp
  llvm/test/Transforms/PGOProfile/Inputs/memprof.exe
  llvm/test/Transforms/PGOProfile/Inputs/memprof.memprofraw
  llvm/test/Transforms/PGOProfile/Inputs/memprof_pgo.profraw
  llvm/test/Transforms/PGOProfile/Inputs/update_memprof_inputs.sh
  llvm/test/Transforms/PGOProfile/memprof.ll
  llvm/test/tools/llvm-profdata/Inputs/basic.memprofexe
  llvm/test/tools/llvm-profdata/Inputs/basic.memprofraw
  llvm/test/tools/llvm-profdata/Inputs/inline.memprofexe
  llvm/test/tools/llvm-profdata/Inputs/inline.memprofraw
  llvm/test/tools/llvm-profdata/Inputs/memprof-inline.exe
  llvm/test/tools/llvm-profdata/Inputs/multi.memprofexe
  llvm/test/tools/llvm-profdata/Inputs/multi.memprofraw
  llvm/test/tools/llvm-profdata/Inputs/pic.memprofexe
  llvm/test/tools/llvm-profdata/Inputs/pic.memprofraw
  llvm/test/tools/llvm-profdata/Inputs/update_memprof_inputs.sh
  llvm/test/tools/llvm-profdata/memprof-basic.test
  llvm/test/tools/llvm-profdata/memprof-inline.test
  llvm/test/tools/llvm-profdata/memprof-merge.test
  llvm/test/tools/llvm-profdata/memprof-multi.test
  llvm/test/tools/llvm-profdata/memprof-pic.test

Index: llvm/test/tools/llvm-profdata/memprof-pic.test
===
--- llvm/test/tools/llvm-profdata/memprof-pic.test
+++ llvm/test/tools/llvm-profdata/memprof-pic.test
@@ -1,40 +1,12 @@
 REQUIRES: x86_64-linux
 
-This test ensures that llvm-profdata fails with a descriptive error message
-when invoked on a memprof profiled binary which was built with position
-independent code.
-
-The input raw profile test has been generated from the following source code:
-
-```
-#include 
-#include 
-int main(int argc, char **argv) {
-  char *x = (char *)malloc(10);
-  memset(x, 0, 10);
-  free(x);
-  x = (char *)malloc(10);
-  memset(x, 0, 10);
-  free(x);
-  return 0;
-}
-```
-
-The following commands were used to compile the source to a memprof instrumented
-executable and collect a raw binary format profile. Since the profile contains
-virtual addresses for the callstack, we do not expect the raw binary profile to
-be deterministic. The summary should be deterministic apart from changes to
-the shared libraries linked in which could change the number of segments
+Since the profile contains virtual addresses for the callstack,
+we do not expect the raw binary profile to be deterministic. The
+summary should be deterministic apart from changes to the shared
+libraries linked in which could change the number of segments
 recorded.
 
-```
-clang -fuse-ld=lld -Wl,--no-rosegment -gmlt -fdebug-info-for-profiling \
-  -fmemory-profile -mno-omit-leaf-frame-pointer -fno-omit-frame-pointer \
-  -fno-optimize-sibling-calls -m64 -Wl,-build-id -pie \
-  source.c -o pic.memprofexe
-
-env MEMPROF_OPTIONS=log_path=stdout ./pic.memprofexe > pic.memprofraw
-```
-
+To update the inputs used below run Inputs/update_memprof_inputs.sh /path/to/updated/clang
 RUN: not llvm-profdata show --memory %p/Inputs/pic.memprofraw --profiled-binary %p/Inputs/pic.memprofexe -o - 2>&1 | FileCheck %s
+
 CHECK: Unsupported position independent code
Index: llvm/test/tools/llvm-profdata/memprof-multi.test
===
--- llvm/test/tools/llvm-profdata/memprof-multi.test
+++ llvm/test/tools/llvm-profdata/memprof-multi.test
@@ -1,39 +1,6 @@
 REQUIRES: x86_64-linux
 
-The input raw profile test has been generated from the following source code:
-
-```
-#include 
-#include 
-#include 
-int main(int argc, char **argv) {
-  char *x = (char *)malloc(10);
-  memset(x, 0, 10);
-  free(x);
-  __memprof_profile_dump();
-  x = (char *)malloc(10);
-  memset(x, 0, 10);
-  free(x);
-  return 0;
-}
-```
-
-The following commands were used to compile the source to a memprof instrumented
-executable and collect a raw binary format profile. Since the profile contains
-virtual addresses for the callstack, we do not expect the raw binary profile to
-be deterministic. The summary should be deterministic apart from changes to
-the shared libraries linked in which could change the number of segments
-recorded.
-
-```
-clang -fuse-ld=lld -Wl,--no-rosegment -gmlt -fdebug-info-for-profiling \
-  -fmemory-profile -mno-omit-leaf-frame-pointer -fno-omit-frame-pointer \
-  -fno-optimize-sibling-calls -m64 -Wl,-build-id -no-pie \
-  source.c -o multi.memprofexe
-
-env MEMPROF_OPTIONS=log_path=stdout ./multi.memprofexe > multi.memprofraw
-```
-
+To update the inputs used below run Inputs/update_memprof_inputs.sh /path/to/update

[PATCH] D145715: Remove -lower-global-dtors-via-cxa-atexit

[Julian Lettner via Phabricator via cfe-commits]

yln created this revision.
Herald added subscribers: ormris, hiraditya.
Herald added a project: All.
yln requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

Remove the `-lower-global-dtors-via-cxa-atexit` escape hatch introduced
in D121736  [1], which switched the default 
lowering of global
destructors on MachO to use `__cxa_atexit()` to avoid emitting
deprecated `__mod_term_func` sections.

I added this flag as an escape hatch in case the switch causes any
problems.  We didn't discover any problems so now we can remove it.

[1] https://reviews.llvm.org/D121736

rdar://90277838


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D145715

Files:
  clang/lib/CodeGen/BackendUtil.cpp
  llvm/include/llvm/CodeGen/CommandFlags.h
  llvm/include/llvm/Target/TargetOptions.h
  llvm/lib/CodeGen/CommandFlags.cpp
  llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
  llvm/lib/CodeGen/TargetPassConfig.cpp
  llvm/test/CodeGen/ARM/ctors_dtors.ll

Index: llvm/test/CodeGen/ARM/ctors_dtors.ll
===
--- llvm/test/CodeGen/ARM/ctors_dtors.ll
+++ llvm/test/CodeGen/ARM/ctors_dtors.ll
@@ -1,5 +1,4 @@
 ; RUN: llc < %s -mtriple=arm-apple-darwin  | FileCheck %s -check-prefix=DARWIN
-; RUN: llc < %s -mtriple=arm-apple-darwin -lower-global-dtors-via-cxa-atexit=false  | FileCheck %s -check-prefix=DARWIN-OLD
 ; RUN: llc < %s -mtriple=arm-linux-gnu -target-abi=apcs  | FileCheck %s -check-prefix=ELF
 ; RUN: llc < %s -mtriple=arm-linux-gnueabi | FileCheck %s -check-prefix=GNUEABI
 
@@ -8,9 +7,6 @@
 ; DARWIN: .section	__DATA,__mod_init_func,mod_init_funcs
 ; DARWIN-NOT: __mod_term_func
 
-; DARWIN-OLD: .section	__DATA,__mod_init_func,mod_init_funcs
-; DARWIN-OLD: .section	__DATA,__mod_term_func,mod_term_funcs
-
 ; ELF: .section .ctors,"aw",%progbits
 ; ELF: .section .dtors,"aw",%progbits
 
Index: llvm/lib/CodeGen/TargetPassConfig.cpp
===
--- llvm/lib/CodeGen/TargetPassConfig.cpp
+++ llvm/lib/CodeGen/TargetPassConfig.cpp
@@ -878,8 +878,7 @@
 
   // For MachO, lower @llvm.global_dtors into @llvm.global_ctors with
   // __cxa_atexit() calls to avoid emitting the deprecated __mod_term_func.
-  if (TM->getTargetTriple().isOSBinFormatMachO() &&
-  TM->Options.LowerGlobalDtorsViaCxaAtExit)
+  if (TM->getTargetTriple().isOSBinFormatMachO())
 addPass(createLowerGlobalDtorsLegacyPass());
 
   // Make sure that no unreachable blocks are instruction selected.
Index: llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
===
--- llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
+++ llvm/lib/CodeGen/TargetLoweringObjectFileImpl.cpp
@@ -1202,11 +1202,7 @@
 
 MCSection *TargetLoweringObjectFileMachO::getStaticDtorSection(
 unsigned Priority, const MCSymbol *KeySym) const {
-  // TODO(yln): Remove -lower-global-dtors-via-cxa-atexit fallback flag
-  // (LowerGlobalDtorsViaCxaAtExit) and always issue a fatal error here.
-  if (TM->Options.LowerGlobalDtorsViaCxaAtExit)
-report_fatal_error("@llvm.global_dtors should have been lowered already");
-  return StaticDtorSection;
+  report_fatal_error("@llvm.global_dtors should have been lowered already");
 }
 
 void TargetLoweringObjectFileMachO::emitModuleMetadata(MCStreamer &Streamer,
Index: llvm/lib/CodeGen/CommandFlags.cpp
===
--- llvm/lib/CodeGen/CommandFlags.cpp
+++ llvm/lib/CodeGen/CommandFlags.cpp
@@ -81,7 +81,6 @@
 CGOPT(bool, StackRealign)
 CGOPT(std::string, TrapFuncName)
 CGOPT(bool, UseCtors)
-CGOPT(bool, LowerGlobalDtorsViaCxaAtExit)
 CGOPT(bool, RelaxELFRelocations)
 CGOPT_EXP(bool, DataSections)
 CGOPT_EXP(bool, FunctionSections)
@@ -349,12 +348,6 @@
 cl::init(false));
   CGBINDOPT(UseCtors);
 
-  static cl::opt LowerGlobalDtorsViaCxaAtExit(
-  "lower-global-dtors-via-cxa-atexit",
-  cl::desc("Lower llvm.global_dtors (global destructors) via __cxa_atexit"),
-  cl::init(true));
-  CGBINDOPT(LowerGlobalDtorsViaCxaAtExit);
-
   static cl::opt RelaxELFRelocations(
   "relax-elf-relocations",
   cl::desc(
@@ -538,7 +531,6 @@
   Options.GuaranteedTailCallOpt = getEnableGuaranteedTailCallOpt();
   Options.StackSymbolOrdering = getStackSymbolOrdering();
   Options.UseInitArray = !getUseCtors();
-  Options.LowerGlobalDtorsViaCxaAtExit = getLowerGlobalDtorsViaCxaAtExit();
   Options.RelaxELFRelocations = getRelaxELFRelocations();
   Options.DataSections =
   getExplicitDataSections().value_or(TheTriple.hasDefaultDataSections());
Index: llvm/include/llvm/Target/TargetOptions.h
===
--- llvm/include/llvm/Target/TargetOptions.h
+++ llvm/include/llvm/Target/TargetOptions.h
@@ -130,7 +130,7 @@
   HonorSignDependent

[clang] 8da99b4 - Revert "Revert "Add map info for dereference pointer.""

[Jennifer Yu via cfe-commits]

Author: Jennifer Yu
Date: 2023-03-09T10:59:59-08:00
New Revision: 8da99b44b6a5a2c9033e38828858cbadad425204

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

LOG: Revert "Revert "Add map info for dereference pointer.""

This reverts commit 8cf85a0cadb033fed3d96aa5283deb4bfbbaf2c8.

This is add back change of "Add map info for dereference pointer."

In addition turn off test run on amdgpu, since I don't know the way to
reprodue the problem.

Added: 
clang/test/OpenMP/target_map_deref_array_codegen.cpp
openmp/libomptarget/test/mapping/target_derefence_array_pointrs.cpp

Modified: 
clang/lib/CodeGen/CGOpenMPRuntime.cpp
clang/lib/Sema/SemaOpenMP.cpp
clang/test/OpenMP/target_update_codegen.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGOpenMPRuntime.cpp 
b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
index ff2e9423b6b2e..60e03320a391c 100644
--- a/clang/lib/CodeGen/CGOpenMPRuntime.cpp
+++ b/clang/lib/CodeGen/CGOpenMPRuntime.cpp
@@ -7163,6 +7163,7 @@ class MappableExprsHandler {
 // double d;
 // int i[100];
 // float *p;
+// int **a = &i;
 //
 // struct S1 {
 //   int i;
@@ -7196,6 +7197,14 @@ class MappableExprsHandler {
 // in unified shared memory mode or for local pointers
 // p, &p[1], 24*sizeof(float), TARGET_PARAM | TO | FROM
 //
+// map((*a)[0:3])
+// &(*a), &(*a), sizeof(pointer), TARGET_PARAM | TO | FROM
+// &(*a), &(*a)[0], 3*sizeof(int), PTR_AND_OBJ | TO | FROM
+//
+// map(**a)
+// &(*a), &(*a), sizeof(pointer), TARGET_PARAM | TO | FROM
+// &(*a), &(**a), sizeof(int), PTR_AND_OBJ | TO | FROM
+//
 // map(s)
 // &s, &s, sizeof(S2), TARGET_PARAM | TO | FROM
 //
@@ -7488,7 +7497,9 @@ class MappableExprsHandler {
   bool IsMemberReference = isa(I->getAssociatedExpression()) &&
MapDecl &&
MapDecl->getType()->isLValueReferenceType();
-  bool IsNonDerefPointer = IsPointer && !UO && !BO && !IsNonContiguous;
+  bool IsNonDerefPointer = IsPointer &&
+   !(UO && UO->getOpcode() != UO_Deref) && !BO &&
+   !IsNonContiguous;
 
   if (OASE)
 ++DimSize;

diff  --git a/clang/lib/Sema/SemaOpenMP.cpp b/clang/lib/Sema/SemaOpenMP.cpp
index b87732ac195a2..e193fa3d19d5c 100644
--- a/clang/lib/Sema/SemaOpenMP.cpp
+++ b/clang/lib/Sema/SemaOpenMP.cpp
@@ -2203,11 +2203,14 @@ bool Sema::isOpenMPCapturedByRef(const ValueDecl *D, 
unsigned Level,
   ++EI;
   if (EI == EE)
 return false;
-
-  if (isa(EI->getAssociatedExpression()) ||
-  isa(EI->getAssociatedExpression()) ||
+  auto Last = std::prev(EE);
+  const auto *UO =
+  dyn_cast(Last->getAssociatedExpression());
+  if ((UO && UO->getOpcode() == UO_Deref) ||
+  isa(Last->getAssociatedExpression()) ||
+  isa(Last->getAssociatedExpression()) ||
   isa(EI->getAssociatedExpression()) ||
-  isa(EI->getAssociatedExpression())) {
+  isa(Last->getAssociatedExpression())) {
 IsVariableAssociatedWithSection = true;
 // There is nothing more we need to know about this variable.
 return true;

diff  --git a/clang/test/OpenMP/target_map_deref_array_codegen.cpp 
b/clang/test/OpenMP/target_map_deref_array_codegen.cpp
new file mode 100644
index 0..40b3b5f1a6f2c
--- /dev/null
+++ b/clang/test/OpenMP/target_map_deref_array_codegen.cpp
@@ -0,0 +1,315 @@
+// NOTE: Assertions have been autogenerated by utils/update_cc_test_checks.py 
UTC_ARGS: --function-signature --include-generated-funcs --replace-value-regex 
"__omp_offloading_[0-9a-z]+_[0-9a-z]+" "reduction_size[.].+[.]" 
"pl_cond[.].+[.|,]" --prefix-filecheck-ir-name _
+// RUN: %clang_cc1 -verify -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu 
-x c++ -triple powerpc64le-unknown-unknown -emit-llvm %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ 
-std=c++11 -triple powerpc64le-unknown-unknown -emit-pch -o %t %s
+// RUN: %clang_cc1 -fopenmp -fopenmp-targets=powerpc64le-ibm-linux-gnu -x c++ 
-triple powerpc64le-unknown-unknown -std=c++11 -include-pch %t -verify %s 
-emit-llvm -o - | FileCheck %s
+
+// expected-no-diagnostics
+#ifndef HEADER
+#define HEADER
+
+extern void *malloc (int __size) throw () __attribute__ ((__malloc__));
+
+void foo(int **t1d)
+{
+  *t1d = (int *) malloc(3 * sizeof(int));
+  for (int j=0; j < 3; j++)
+(*t1d)[j] = 1;
+  #pragma omp target map(to: (*t1d)[0:3])
+(*t1d)[2] = 2;
+  #pragma omp target map(tofrom : (**t1d))
+(*t1d)[0] = 3;
+  int a = 0, b = 0;
+  #pragma omp target map(tofrom : (*(*(t1d+a)+