[PATCH] D144943: [clang][Interp] Implement bitcasts (WIP)

2023-02-27 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder added inline comments.



Comment at: clang/lib/AST/Interp/ByteCodeExprGen.cpp:92
+  // FIXME: Diagnostics.
+  if (*ToT == PT_Ptr)
+return false;

One of the problems here is that right now, //all// diagnostics are emitted 
during interpretation time.



Comment at: clang/lib/AST/Interp/Interp.h:1366
+  size_t BuffSize = APFloat::semanticsSizeInBits(*Sem) / 8;
+  std::byte Buff[BuffSize];
+

This is a variable sized array. That needs to go of course, but is the best way 
to heap allocate? Or can we actually use `alloca` in clang code?



Comment at: clang/lib/AST/Interp/InterpBuiltin.cpp:33
 
+struct Foo {
+  std::byte *Buff;

This needs to be renamed obviously, but I was wondering if this already exists 
somewhere in the llvm/clang codebase...



Comment at: clang/lib/AST/Interp/InterpBuiltin.cpp:81
+/// Rotate things around for big endian targets.
+static void fiddleMemory(std::byte *M, size_t N) {
+  for (size_t I = 0; I != (N / 2); ++I)

Same here, I feel like this should already be available?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144943

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


[PATCH] D144943: [clang][Interp] Implement bitcasts (WIP)

2023-02-27 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder created this revision.
tbaeder added reviewers: aaron.ballman, erichkeane, tahonermann, shafi.ahmad.
Herald added a project: All.
tbaeder requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This implements bitcasts by traversing the pointer fields at 
interpretation-time, copying them into a buffer and then either creating a new 
primitive value from the buffer, or traversing the destination pointer and 
reading the field values from that buffer.

This is a bit non-idiomatic to the new interpreter since we do so much work at 
interpretation time instead of doing it at compile-time.
I can imagine ways to change this, but it would require bytecode instructions 
that are rather awkward, I think. So this is my attempt at
doing it this way instead.

It's also missing all the eligibility checks for bitcasts of course.
I have also not tested this on a big-endian host, which I definitely need to do 
(is the bit rotation needed if the host is BE //and// the target is BE?).

I'll try to leave a few comments in the diff.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D144943

Files:
  clang/lib/AST/Interp/Boolean.h
  clang/lib/AST/Interp/ByteCodeExprGen.cpp
  clang/lib/AST/Interp/ByteCodeExprGen.h
  clang/lib/AST/Interp/Descriptor.h
  clang/lib/AST/Interp/Floating.h
  clang/lib/AST/Interp/Integral.h
  clang/lib/AST/Interp/Interp.h
  clang/lib/AST/Interp/InterpBuiltin.cpp
  clang/lib/AST/Interp/Opcodes.td
  clang/lib/AST/Interp/Pointer.cpp
  clang/lib/AST/Interp/Pointer.h
  clang/lib/AST/Interp/PrimType.h
  clang/test/AST/Interp/builtin-bit-cast.cpp

Index: clang/test/AST/Interp/builtin-bit-cast.cpp
===
--- /dev/null
+++ clang/test/AST/Interp/builtin-bit-cast.cpp
@@ -0,0 +1,228 @@
+// RUN: %clang_cc1 -fexperimental-new-constant-interpreter -verify -std=c++2a -fsyntax-only %s
+// RUN: %clang_cc1 -verify=ref -std=c++2a -fsyntax-only %s
+// RUN: %clang_cc1 -verify -std=c++2a -fsyntax-only -triple aarch64_be-linux-gnu -fexperimental-new-constant-interpreter %s
+// RUN: %clang_cc1 -verify -std=c++2a -fsyntax-only -triple aarch64_be-linux-gnu -fexperimental-new-constant-interpreter %s
+
+
+/// ref-no-diagnostics
+
+
+/// FIXME: This is a version of clang/test/SemaCXX/builtin-bit-cast.cpp with
+///   the currently supported subset of operations. They should *all* be
+///   supported though.
+
+
+#if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+#  define LITTLE_END 1
+#elif __BYTE_ORDER__ == __ORDER_BIG_ENDIAN__
+#  define LITTLE_END 0
+#else
+#  error "huh?"
+#endif
+
+template  struct is_same {
+  static constexpr bool value = false;
+};
+template  struct is_same {
+  static constexpr bool value = true;
+};
+
+static_assert(sizeof(int) == 4);
+static_assert(sizeof(long long) == 8);
+
+template 
+constexpr To bit_cast(const From ) {
+  static_assert(sizeof(To) == sizeof(From));
+  return __builtin_bit_cast(To, from);
+}
+
+template 
+constexpr bool round_trip(const Init ) {
+  return bit_cast(bit_cast(init)) == init;
+}
+
+static_assert(round_trip((int)-1));
+static_assert(round_trip((int)0x12345678));
+static_assert(round_trip((int)0x87654321));
+static_assert(round_trip((int)0x0C05FEFE));
+static_assert(round_trip((int)0x0C05FEFE));
+
+constexpr unsigned char input[] = {0xCA, 0xFE, 0xBA, 0xBE};
+constexpr unsigned expected = LITTLE_END ? 0xBEBAFECA : 0xCAFEBABE;
+static_assert(bit_cast(input) == expected);
+
+constexpr short S[] = {10, 20};
+constexpr int I = __builtin_bit_cast(int, S);
+static_assert(I == (LITTLE_END ? 1310730 : 655380));
+
+
+struct int_splicer {
+  unsigned x;
+  unsigned y;
+
+  constexpr int_splicer() : x(1), y(2) {}
+  constexpr int_splicer(unsigned x, unsigned y) : x(x), y(y) {}
+
+  constexpr bool operator==(const int_splicer ) const {
+return other.x == x && other.y == y;
+  }
+};
+
+constexpr int_splicer splice(0x0C05FEFE, 0xCAFEBABE);
+
+static_assert(bit_cast(splice) == (LITTLE_END
+   ? 0xCAFEBABE0C05FEFE
+   : 0x0C05FEFECAFEBABE));
+
+constexpr int_splicer IS = bit_cast(0xCAFEBABE0C05FEFE);
+static_assert(bit_cast(0xCAFEBABE0C05FEFE).x == (LITTLE_END
+  ? 0x0C05FEFE
+  : 0xCAFEBABE));
+
+static_assert(round_trip(splice));
+static_assert(round_trip(splice));
+
+struct base2 {
+};
+
+struct base3 {
+  unsigned z;
+  constexpr base3() : z(3) {}
+};
+
+struct bases : int_splicer, base2, base3 {
+  unsigned doublez;
+  constexpr bases() : doublez(4) {}
+};
+
+struct tuple4 {
+  unsigned x, y, z, doublez;
+
+  constexpr bool operator==(tuple4 const ) const {
+return x == other.x && y == other.y &&
+   z == other.z && doublez == other.doublez;
+  }
+};
+constexpr bases b;// = {{1, 2}, {}, {3}, 4};

[PATCH] D144853: [Clang][RISCV] Add CMake options to configure default CPU

2023-02-27 Thread Tom Stellard via Phabricator via cfe-commits
tstellar added a comment.

Would this make more sense in a config file rather than a CMake option?  
@MaskRay


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144853

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


[PATCH] D144853: [Clang][RISCV] Add CMake options to configure default CPU

2023-02-27 Thread Wang Pengcheng via Phabricator via cfe-commits
pcwang-thead added a comment.

In D144853#4155482 , @asb wrote:

> If this is a useful thing to have, would it make more sense as a 
> target-independent option?

Yes, I agree.

I need to do some researches here to figure out if all targets have the same 
behavior for CPU `generic` and some other stuffs.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144853

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


[PATCH] D144853: [Clang][RISCV] Add CMake options to configure default CPU

2023-02-27 Thread Wang Pengcheng via Phabricator via cfe-commits
pcwang-thead updated this revision to Diff 501035.
pcwang-thead added a comment.

Simplify code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144853

Files:
  clang/CMakeLists.txt
  clang/include/clang/Config/config.h.cmake
  clang/lib/Driver/ToolChains/Arch/RISCV.cpp


Index: clang/lib/Driver/ToolChains/Arch/RISCV.cpp
===
--- clang/lib/Driver/ToolChains/Arch/RISCV.cpp
+++ clang/lib/Driver/ToolChains/Arch/RISCV.cpp
@@ -10,6 +10,7 @@
 #include "../Clang.h"
 #include "ToolChains/CommonArgs.h"
 #include "clang/Basic/CharInfo.h"
+#include "clang/Config/config.h"
 #include "clang/Driver/Driver.h"
 #include "clang/Driver/DriverDiagnostic.h"
 #include "clang/Driver/Options.h"
@@ -308,7 +309,8 @@
 
 std::string riscv::getRISCVTargetCPU(const llvm::opt::ArgList ,
  const llvm::Triple ) {
-  std::string CPU;
+  std::string CPU = Triple.isRISCV64() ? CLANG_RISCV64_DEFAULT_CPU
+   : CLANG_RISCV32_DEFAULT_CPU;
   // If we have -mcpu, use that.
   if (const Arg *A = Args.getLastArg(options::OPT_mcpu_EQ))
 CPU = A->getValue();
@@ -317,8 +319,5 @@
   if (CPU == "native")
 CPU = llvm::sys::getHostCPUName();
 
-  if (!CPU.empty())
-return CPU;
-
-  return Triple.isRISCV64() ? "generic-rv64" : "generic-rv32";
+  return CPU;
 }
Index: clang/include/clang/Config/config.h.cmake
===
--- clang/include/clang/Config/config.h.cmake
+++ clang/include/clang/Config/config.h.cmake
@@ -32,6 +32,10 @@
 /* Default architecture for SystemZ. */
 #define CLANG_SYSTEMZ_DEFAULT_ARCH "${CLANG_SYSTEMZ_DEFAULT_ARCH}"
 
+/* Default CPU for RISCV. */
+#define CLANG_RISCV32_DEFAULT_CPU "${CLANG_RISCV32_DEFAULT_CPU}"
+#define CLANG_RISCV64_DEFAULT_CPU "${CLANG_RISCV64_DEFAULT_CPU}"
+
 /* Multilib basename for libdir. */
 #define CLANG_INSTALL_LIBDIR_BASENAME "${CLANG_INSTALL_LIBDIR_BASENAME}"
 
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -247,6 +247,9 @@
 
 set(CLANG_SYSTEMZ_DEFAULT_ARCH "z10" CACHE STRING "SystemZ Default Arch")
 
+set(CLANG_RISCV32_DEFAULT_CPU "generic-rv32" CACHE STRING "RISCV32 Default 
CPU")
+set(CLANG_RISCV64_DEFAULT_CPU "generic-rv64" CACHE STRING "RISCV64 Default 
CPU")
+
 set(CLANG_VENDOR ${PACKAGE_VENDOR} CACHE STRING
   "Vendor-specific text for showing with version information.")
 


Index: clang/lib/Driver/ToolChains/Arch/RISCV.cpp
===
--- clang/lib/Driver/ToolChains/Arch/RISCV.cpp
+++ clang/lib/Driver/ToolChains/Arch/RISCV.cpp
@@ -10,6 +10,7 @@
 #include "../Clang.h"
 #include "ToolChains/CommonArgs.h"
 #include "clang/Basic/CharInfo.h"
+#include "clang/Config/config.h"
 #include "clang/Driver/Driver.h"
 #include "clang/Driver/DriverDiagnostic.h"
 #include "clang/Driver/Options.h"
@@ -308,7 +309,8 @@
 
 std::string riscv::getRISCVTargetCPU(const llvm::opt::ArgList ,
  const llvm::Triple ) {
-  std::string CPU;
+  std::string CPU = Triple.isRISCV64() ? CLANG_RISCV64_DEFAULT_CPU
+   : CLANG_RISCV32_DEFAULT_CPU;
   // If we have -mcpu, use that.
   if (const Arg *A = Args.getLastArg(options::OPT_mcpu_EQ))
 CPU = A->getValue();
@@ -317,8 +319,5 @@
   if (CPU == "native")
 CPU = llvm::sys::getHostCPUName();
 
-  if (!CPU.empty())
-return CPU;
-
-  return Triple.isRISCV64() ? "generic-rv64" : "generic-rv32";
+  return CPU;
 }
Index: clang/include/clang/Config/config.h.cmake
===
--- clang/include/clang/Config/config.h.cmake
+++ clang/include/clang/Config/config.h.cmake
@@ -32,6 +32,10 @@
 /* Default architecture for SystemZ. */
 #define CLANG_SYSTEMZ_DEFAULT_ARCH "${CLANG_SYSTEMZ_DEFAULT_ARCH}"
 
+/* Default CPU for RISCV. */
+#define CLANG_RISCV32_DEFAULT_CPU "${CLANG_RISCV32_DEFAULT_CPU}"
+#define CLANG_RISCV64_DEFAULT_CPU "${CLANG_RISCV64_DEFAULT_CPU}"
+
 /* Multilib basename for libdir. */
 #define CLANG_INSTALL_LIBDIR_BASENAME "${CLANG_INSTALL_LIBDIR_BASENAME}"
 
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -247,6 +247,9 @@
 
 set(CLANG_SYSTEMZ_DEFAULT_ARCH "z10" CACHE STRING "SystemZ Default Arch")
 
+set(CLANG_RISCV32_DEFAULT_CPU "generic-rv32" CACHE STRING "RISCV32 Default CPU")
+set(CLANG_RISCV64_DEFAULT_CPU "generic-rv64" CACHE STRING "RISCV64 Default CPU")
+
 set(CLANG_VENDOR ${PACKAGE_VENDOR} CACHE STRING
   "Vendor-specific text for showing with version information.")
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org

[clang] e76e3a0 - [NFC] Add a test about template pack for C++20 Modules

2023-02-27 Thread Chuanqi Xu via cfe-commits

Author: Chuanqi Xu
Date: 2023-02-28T14:38:46+08:00
New Revision: e76e3a091961ee4e5b01825527832f05234011d6

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

LOG: [NFC] Add a test about template pack for C++20 Modules

I found the issue in a donwstream project. But the case looks fine in
the upstream. Add the test to make sure that it wouldn't happen in the
upstream.

Added: 
clang/test/Modules/template-pack.cppm

Modified: 


Removed: 




diff  --git a/clang/test/Modules/template-pack.cppm 
b/clang/test/Modules/template-pack.cppm
new file mode 100644
index 0..eca17f31f015e
--- /dev/null
+++ b/clang/test/Modules/template-pack.cppm
@@ -0,0 +1,51 @@
+// RUN: rm -rf %t
+// RUN: mkdir -p %t
+// RUN: split-file %s %t
+//
+// RUN: %clang_cc1 -std=c++20 -emit-module-interface %t/a.cppm -o %t/a.pcm
+// RUN: %clang_cc1 -std=c++20 %t/b.cppm -fprebuilt-module-path=%t 
-fsyntax-only -verify
+
+//--- foo.h
+
+namespace std
+{
+template
+void operator &&(_Dom1 __v, _Dom1 __w)
+{ 
+return;
+}
+}
+
+//--- bar.h
+namespace std 
+{
+  template
+struct _Traits
+{
+  static constexpr bool _S_copy_ctor =
+   (__is_trivial(_Types) && ...);
+};
+
+  template
+struct variant
+{
+  void
+  swap(variant& __rhs)
+  noexcept((__is_trivial(_Types) && ...))
+  {
+  }
+};
+}
+
+//--- a.cppm
+module;
+#include "foo.h"
+#include "bar.h"
+export module a;
+
+//--- b.cppm
+// expected-no-diagnostics
+module;
+#include "bar.h"
+export module b;
+import a;



___
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

2023-02-27 Thread Igor Kushnir via Phabricator via cfe-commits
vedgy added inline comments.



Comment at: clang/tools/c-index-test/c-index-test.c:79
+Opts.PreambleStoragePath = NULL;
+Opts.InvocationEmissionPath = 
getenv("CINDEXTEST_INVOCATION_EMISSION_PATH");
+

aaron.ballman wrote:
> vedgy wrote:
> > When a libclang user needs to override a single option in `CXIndexOptions`, 
> > [s]he has to set every member of the struct explicitly. When new options 
> > are added, each libclang user needs to update the code that sets the 
> > options under `CINDEX_VERSION_MINOR` `#if`s. Accidentally omitting even one 
> > member assignment risks undefined or wrong behavior. How about adding an 
> > `inline` helper function `CXIndexOptions clang_getDefaultIndexOptions()`, 
> > which assigns default values to all struct members? Libclang users can then 
> > call this function to obtain the default configuration, then tweak only the 
> > members they want to override.
> > 
> > If this suggestion is to be implemented, how to deal with 
> > [[https://stackoverflow.com/questions/68004269/differences-of-the-inline-keyword-in-c-and-c|the
> >  differences of the inline keyword in C and C++]]?
> By default, `0` should give you the most reasonable default behavior for most 
> of the existing options (and new options should follow the same pattern). 
> Ideally, users should be able to do:
> ```
> CXIndexOptions Opts;
> memset(, 0, sizeof(Opts));
> Opts.Size = sizeof(Opts);
> Opts.Whatever = 12;
> CXIndex Idx = clang_createIndexWithOptions();
> ```
> Global options defaulting to 0 is fine (uses regular thread priorities), we 
> don't think want to default to excluding declarations from PCH, and we want 
> to use the default preamble and invocation emission paths (if any). The only 
> option that nonzero as a default *might* make sense for is displaying 
> diagnostics, but even that seems reasonable to expect the developer to 
> manually enable.
> 
> So I don't know that we need a function to get us default indexing options as 
> `0` should be a reasonable default for all of the options. As we add new 
> options, we need to be careful to add them in backwards compatible ways where 
> `0` means "do the most likely thing".
> 
> WDYT?
The disadvantages of committing to defaulting to `0`:
1. The usage you propose is still more verbose and error-prone than
```
CXIndexOptions Opts = clang_getDefaultIndexOptions();
Opts.Whatever = 12;
CXIndex Idx = clang_createIndexWithOptions();
```
2. The `memset` would look very unclean in modern C++ code.
3. The `0` commitment may force unnatural naming of a future option to invert 
its meaning.

The advantages:
1. No need to implement the inline function now.
2. Faster, but I am sure this performance difference doesn't matter. Even a 
non-inline function call itself (even if it did nothing) to 
`clang_createIndexWithOptions()` should take longer than assigning a few values 
to built-in-typed members.

Another advantage of not having to remember to update the inline function's 
implementation when new options are added is counterbalanced by the need to be 
careful to add new options in backwards compatible way where `0` is the default.

Any other advantages of the `0` that I miss? Maybe there are some advantages 
for C users, but I suspect most libclang users are C++.



Comment at: clang/tools/c-index-test/c-index-test.c:2079
+  if (!Idx)
+return -1;
 

aaron.ballman wrote:
> vedgy wrote:
> > Not sure `-1` is the right value to return here. This return value becomes 
> > the exit code of the `c-index-test` executable.
> I think `-1` is fine -- the important thing is a nonzero return code so it's 
> logged as an error rather than a valid result.
I have noticed that these functions sometimes return `-1` and sometimes `1` on 
different errors. I thought that perhaps there is some difference in these two 
return values, but I couldn't figure out what it might be. Since telling the 
difference is not straightforward, you are probably right that there is //no// 
meaningful difference.



Comment at: clang/tools/libclang/CIndex.cpp:3701-3702
+CXIndex clang_createIndexWithOptions(const CXIndexOptions *options) {
+  if (options->Size != sizeof(CXIndexOptions))
+return NULL;
+  CIndexer *CIdxr = clang_createIndex_Impl(options->ExcludeDeclarationsFromPCH,

aaron.ballman wrote:
> I think we want this to be `>` and not `!=`, maybe.
> 
> If the sizes are equal, we're on the happy path.
> 
> If the options from the caller are smaller than the options we know about, 
> that should be okay because we won't attempt read the options not provided 
> and instead rely on the default behavior being reasonable.
> 
> If the options from the caller are larger than the options we know about, we 
> have to assume the user set an option we can't handle, and thus failing the 
> request is reasonable.
> 
> So the way I'm envisioning us reading the options is:
> ```
> if 

[PATCH] D144272: [clang][Interp] Ignore StaticAssertDecls

2023-02-27 Thread Timm Bäder via Phabricator via cfe-commits
tbaeder added a comment.

Ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144272

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


[PATCH] D144853: [Clang][RISCV] Add CMake options to configure default CPU

2023-02-27 Thread Craig Topper via Phabricator via cfe-commits
craig.topper added inline comments.



Comment at: clang/lib/Driver/ToolChains/Arch/RISCV.cpp:324
 
-  return Triple.isRISCV64() ? "generic-rv64" : "generic-rv32";
+  std::string DefaultCPU = Triple.isRISCV64() ? CLANG_RISCV64_DEFAULT_CPU
+  : CLANG_RISCV32_DEFAULT_CPU;

Can we initialize `CPU` to the default CPU at the top? Remove the `CPU.empty()` 
check. Then we don't need a second `"native"` check.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144853

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


[PATCH] D144940: [clang][ExtractAPI] Handle platform specific unavailability correctly

2023-02-27 Thread Ankur Saini via Phabricator via cfe-commits
Arsenic created this revision.
Herald added a reviewer: ributzka.
Herald added a project: All.
Arsenic edited the summary of this revision.
Arsenic added reviewers: dang, zixuw.
Arsenic published this revision for review.
Arsenic added inline comments.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.



Comment at: clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp:546
+  Record, API, [Lang, ](const PathComponent ) {
+ParentContexts.push_back(serializeParentContext(PC, Lang));
+  });

These changes seems to have added by clang-format. 
Is there a way to not let clang format edit the code that I haven't touched ?


This Patch gives ExtractAPI the ability to emit correct availability 
information for symbols marked as unavailable on a specific platform ( PR#60954 
)


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D144940

Files:
  clang/include/clang/ExtractAPI/AvailabilityInfo.h
  clang/lib/ExtractAPI/AvailabilityInfo.cpp
  clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp


Index: clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
===
--- clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
+++ clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
@@ -171,12 +171,16 @@
   for (const auto  : Availabilities) {
 Object Availability;
 Availability["domain"] = AvailInfo.Domain;
-serializeObject(Availability, "introducedVersion",
-serializeSemanticVersion(AvailInfo.Introduced));
-serializeObject(Availability, "deprecatedVersion",
-serializeSemanticVersion(AvailInfo.Deprecated));
-serializeObject(Availability, "obsoletedVersion",
-serializeSemanticVersion(AvailInfo.Obsoleted));
+if (AvailInfo.Unavailable)
+  Availability["isUnconditionallyUnavailable"] = true;
+else {
+  serializeObject(Availability, "introducedVersion",
+  serializeSemanticVersion(AvailInfo.Introduced));
+  serializeObject(Availability, "deprecatedVersion",
+  serializeSemanticVersion(AvailInfo.Deprecated));
+  serializeObject(Availability, "obsoletedVersion",
+  serializeSemanticVersion(AvailInfo.Obsoleted));
+}
 AvailabilityArray.emplace_back(std::move(Availability));
   }
 
@@ -537,11 +541,10 @@
 Array generateParentContexts(const RecordTy , const APISet ,
  Language Lang) {
   Array ParentContexts;
-  generatePathComponents(Record, API,
- [Lang, ](const PathComponent ) {
-   ParentContexts.push_back(
-   serializeParentContext(PC, Lang));
- });
+  generatePathComponents(
+  Record, API, [Lang, ](const PathComponent ) {
+ParentContexts.push_back(serializeParentContext(PC, Lang));
+  });
 
   // The last component would be the record itself so let's remove it.
   if (!ParentContexts.empty())
Index: clang/lib/ExtractAPI/AvailabilityInfo.cpp
===
--- clang/lib/ExtractAPI/AvailabilityInfo.cpp
+++ clang/lib/ExtractAPI/AvailabilityInfo.cpp
@@ -42,8 +42,8 @@
   Availability->Obsoleted = Attr->getObsoleted();
   } else {
 Availabilities.emplace_back(Domain, Attr->getIntroduced(),
-Attr->getDeprecated(),
-Attr->getObsoleted());
+Attr->getDeprecated(), 
Attr->getObsoleted(),
+Attr->getUnavailable());
   }
 }
   }
Index: clang/include/clang/ExtractAPI/AvailabilityInfo.h
===
--- clang/include/clang/ExtractAPI/AvailabilityInfo.h
+++ clang/include/clang/ExtractAPI/AvailabilityInfo.h
@@ -33,17 +33,19 @@
   VersionTuple Introduced;
   VersionTuple Deprecated;
   VersionTuple Obsoleted;
+  bool Unavailable;
 
   AvailabilityInfo() = default;
 
   AvailabilityInfo(StringRef Domain, VersionTuple I, VersionTuple D,
-   VersionTuple O)
-  : Domain(Domain), Introduced(I), Deprecated(D), Obsoleted(O) {}
+   VersionTuple O, bool U)
+  : Domain(Domain), Introduced(I), Deprecated(D), Obsoleted(O),
+Unavailable(U) {}
 };
 
 class AvailabilitySet {
 private:
-  using AvailabilityList = llvm::SmallVector;
+  using AvailabilityList = llvm::SmallVector;
   AvailabilityList Availabilities;
 
   bool UnconditionallyDeprecated = false;


Index: clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
===
--- clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
+++ clang/lib/ExtractAPI/Serialization/SymbolGraphSerializer.cpp
@@ -171,12 +171,16 @@
   for 

[PATCH] D144680: [Coroutines] Avoid creating conditional cleanup markers in suspend block

2023-02-27 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu accepted this revision.
ChuanqiXu added a comment.
This revision is now accepted and ready to land.

LGTM, then.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144680

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


[PATCH] D144934: [clang] drop buggy use of `-serialize-diagnostics` flag

2023-02-27 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu accepted this revision.
ChuanqiXu added a comment.
This revision is now accepted and ready to land.

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144934

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


[PATCH] D140794: [ASTMatcher] Add coroutineBodyStmt matcher

2023-02-27 Thread Chris Cotter via Phabricator via cfe-commits
ccotter updated this revision to Diff 500996.
ccotter added a comment.

fix bad 'arc diff'


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140794

Files:
  clang/docs/ReleaseNotes.rst
  clang/include/clang/ASTMatchers/ASTMatchers.h
  clang/lib/ASTMatchers/ASTMatchersInternal.cpp
  clang/lib/ASTMatchers/Dynamic/Registry.cpp
  clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
  clang/unittests/ASTMatchers/Dynamic/ParserTest.cpp

Index: clang/unittests/ASTMatchers/Dynamic/ParserTest.cpp
===
--- clang/unittests/ASTMatchers/Dynamic/ParserTest.cpp
+++ clang/unittests/ASTMatchers/Dynamic/ParserTest.cpp
@@ -364,7 +364,8 @@
 "to build matcher: mapAnyOf.",
 ParseWithError("mapAnyOf(\"foo\")"));
   EXPECT_EQ("Input value has unresolved overloaded type: "
-"Matcher",
+"Matcher",
 ParseMatcherWithError("hasBody(stmt())"));
   EXPECT_EQ(
   "1:1: Error parsing argument 1 for matcher decl.\n"
Index: clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
===
--- clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
+++ clang/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
@@ -678,6 +678,48 @@
   EXPECT_TRUE(matchesConditionally(CoYieldCode, 
coyieldExpr(isExpansionInMainFile()), 
true, {"-std=c++20", "-I/"}, M));
+
+  StringRef NonCoroCode = R"cpp(
+#include 
+void non_coro_function() {
+}
+)cpp";
+
+  EXPECT_TRUE(matchesConditionally(CoReturnCode, coroutineBodyStmt(), true,
+   {"-std=c++20", "-I/"}, M));
+  EXPECT_TRUE(matchesConditionally(CoAwaitCode, coroutineBodyStmt(), true,
+   {"-std=c++20", "-I/"}, M));
+  EXPECT_TRUE(matchesConditionally(CoYieldCode, coroutineBodyStmt(), true,
+   {"-std=c++20", "-I/"}, M));
+
+  EXPECT_FALSE(matchesConditionally(NonCoroCode, coroutineBodyStmt(), true,
+{"-std=c++20", "-I/"}, M));
+
+  StringRef CoroWithDeclCode = R"cpp(
+#include 
+void coro() {
+  int thevar;
+  co_return 1;
+}
+)cpp";
+  EXPECT_TRUE(matchesConditionally(
+  CoroWithDeclCode,
+  coroutineBodyStmt(hasBody(compoundStmt(
+  has(declStmt(containsDeclaration(0, varDecl(hasName("thevar",
+  true, {"-std=c++20", "-I/"}, M));
+
+  StringRef CoroWithTryCatchDeclCode = R"cpp(
+#include 
+void coro() try {
+  int thevar;
+  co_return 1;
+} catch (...) {}
+)cpp";
+  EXPECT_TRUE(matchesConditionally(
+  CoroWithTryCatchDeclCode,
+  coroutineBodyStmt(hasBody(cxxTryStmt(has(compoundStmt(has(
+  declStmt(containsDeclaration(0, varDecl(hasName("thevar")),
+  true, {"-std=c++20", "-I/"}, M));
 }
 
 TEST(Matcher, isClassMessage) {
Index: clang/lib/ASTMatchers/Dynamic/Registry.cpp
===
--- clang/lib/ASTMatchers/Dynamic/Registry.cpp
+++ clang/lib/ASTMatchers/Dynamic/Registry.cpp
@@ -175,6 +175,7 @@
   REGISTER_MATCHER(containsDeclaration);
   REGISTER_MATCHER(continueStmt);
   REGISTER_MATCHER(coreturnStmt);
+  REGISTER_MATCHER(coroutineBodyStmt);
   REGISTER_MATCHER(coyieldExpr);
   REGISTER_MATCHER(cudaKernelCallExpr);
   REGISTER_MATCHER(cxxBaseSpecifier);
Index: clang/lib/ASTMatchers/ASTMatchersInternal.cpp
===
--- clang/lib/ASTMatchers/ASTMatchersInternal.cpp
+++ clang/lib/ASTMatchers/ASTMatchersInternal.cpp
@@ -910,6 +910,8 @@
 const internal::VariadicDynCastAllOfMatcher caseStmt;
 const internal::VariadicDynCastAllOfMatcher defaultStmt;
 const internal::VariadicDynCastAllOfMatcher compoundStmt;
+const internal::VariadicDynCastAllOfMatcher
+coroutineBodyStmt;
 const internal::VariadicDynCastAllOfMatcher cxxCatchStmt;
 const internal::VariadicDynCastAllOfMatcher cxxTryStmt;
 const internal::VariadicDynCastAllOfMatcher cxxThrowExpr;
Index: clang/include/clang/ASTMatchers/ASTMatchers.h
===
--- clang/include/clang/ASTMatchers/ASTMatchers.h
+++ clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -2450,6 +2450,17 @@
 extern const internal::VariadicDynCastAllOfMatcher
 coyieldExpr;
 
+/// Matches coroutine body statements.
+///
+/// coroutineBodyStmt() matches the coroutine below
+/// \code
+///   generator gen() {
+/// co_return;
+///   }
+/// \endcode
+extern const internal::VariadicDynCastAllOfMatcher
+coroutineBodyStmt;
+
 /// Matches nullptr literal.
 extern const internal::VariadicDynCastAllOfMatcher
 cxxNullPtrLiteralExpr;
@@ -5460,9 +5471,10 @@
   return false;
 }
 
-/// Matches a 'for', 'while', 'do' statement or a function definition that has
-/// a given body. Note that in 

[PATCH] D140794: [ASTMatcher] Add coroutineBodyStmt matcher

2023-02-27 Thread Chris Cotter via Phabricator via cfe-commits
ccotter updated this revision to Diff 500995.
ccotter added a comment.

- update release note, rebase


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140794

Files:
  clang/include/clang/ASTMatchers/ASTMatchers.h


Index: clang/include/clang/ASTMatchers/ASTMatchers.h
===
--- clang/include/clang/ASTMatchers/ASTMatchers.h
+++ clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -5495,13 +5495,11 @@
 /// with compoundStmt()
 ///   matching '{}'
 ///   but does not match 'void f();'
-AST_POLYMORPHIC_MATCHER_P(hasBody,
-  AST_POLYMORPHIC_SUPPORTED_TYPES(DoStmt, ForStmt,
-  WhileStmt,
-  CXXForRangeStmt,
-  FunctionDecl,
-  CoroutineBodyStmt),
-  internal::Matcher, InnerMatcher) {
+AST_POLYMORPHIC_MATCHER_P(
+hasBody,
+AST_POLYMORPHIC_SUPPORTED_TYPES(DoStmt, ForStmt, WhileStmt, 
CXXForRangeStmt,
+FunctionDecl, CoroutineBodyStmt),
+internal::Matcher, InnerMatcher) {
   if (Finder->isTraversalIgnoringImplicitNodes() && isDefaultedHelper())
 return false;
   const Stmt *const Statement = internal::GetBodyMatcher::get(Node);


Index: clang/include/clang/ASTMatchers/ASTMatchers.h
===
--- clang/include/clang/ASTMatchers/ASTMatchers.h
+++ clang/include/clang/ASTMatchers/ASTMatchers.h
@@ -5495,13 +5495,11 @@
 /// with compoundStmt()
 ///   matching '{}'
 ///   but does not match 'void f();'
-AST_POLYMORPHIC_MATCHER_P(hasBody,
-  AST_POLYMORPHIC_SUPPORTED_TYPES(DoStmt, ForStmt,
-  WhileStmt,
-  CXXForRangeStmt,
-  FunctionDecl,
-  CoroutineBodyStmt),
-  internal::Matcher, InnerMatcher) {
+AST_POLYMORPHIC_MATCHER_P(
+hasBody,
+AST_POLYMORPHIC_SUPPORTED_TYPES(DoStmt, ForStmt, WhileStmt, CXXForRangeStmt,
+FunctionDecl, CoroutineBodyStmt),
+internal::Matcher, InnerMatcher) {
   if (Finder->isTraversalIgnoringImplicitNodes() && isDefaultedHelper())
 return false;
   const Stmt *const Statement = internal::GetBodyMatcher::get(Node);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D144894: [clang] Documents clang-scan-deps requirements.

2023-02-27 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu accepted this revision.
ChuanqiXu 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/D144894/new/

https://reviews.llvm.org/D144894

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


[PATCH] D72820: [FPEnv] Add pragma FP_CONTRACT support under strict FP.

2023-02-27 Thread Allen zhong via Phabricator via cfe-commits
Allen added inline comments.
Herald added a project: All.



Comment at: clang/lib/CodeGen/CGExprScalar.cpp:3386
+FMulAdd = Builder.CreateConstrainedFPCall(
+CGF.CGM.getIntrinsic(llvm::Intrinsic::experimental_constrained_fmuladd,
+ Addend->getType()),

Sorry, I'm not familiar with the optimization of the clang front end. 
I'd like to ask, is this optimization supposed to assume that all the backends 
have instructions like Fmuladd?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D72820

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


[PATCH] D143877: [NFC] [clang] Forward forwarding reference

2023-02-27 Thread Chris Cotter via Phabricator via cfe-commits
ccotter added a comment.

Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143877

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


[PATCH] D144889: [C2x] Support in freestanding

2023-02-27 Thread James Y Knight via Phabricator via cfe-commits
jyknight added a comment.

In D144889#4156974 , @rsmith wrote:

> Likely because of GCC's perspective on this, the set of C headers provided by 
> GCC, Clang, ICC, etc. has included the complete list of freestanding headers 
> and more or less no others, with some libc implementations providing the full 
> set and some providing just the non-freestanding ones. If we're moving away 
> from that, we'll presumably need a new agreement between compiler folks and 
> libc folks about which headers are provided by whom (and I expect it'll be 
> "compilers provide what the C standard said before this change to 
> freestanding and we pretend the change never happened").

Yeah...this seems like a pretty big divergence from the historical view 
compilers have for "freestanding" mode, and I think the implementation should 
be more along the lines of a "micro-libc", than something built into clang. 
Especially considering the potential future additions e.g. `errno.h`. If we 
look at this as a specification for what to provide in a "micro-libc", having 
such global state is not a major issue, but if we look at this as a "compiler 
builtin" sort of thing (ala traditional freestanding), then it's quite a 
problem.

So, I think the correct solution here is to just document what parts of a 
C2x-conforming "freestanding" Clang provides itself, and what remains for an 
external "mini-libc" implementation to provide.

It probably makes sense for one such external implementation to be provided by 
llvm-libc in the future -- I suspect it should have a separate "freestanding" 
target mode, which would omit all the runtime features like memory allocation 
and threads, and provide just the pure library functionality. But I'd also 
expect such an llvm-libc freestanding mode would also provide a lot more 
functionality than just the minimum requirements -- there's a whole lot more 
"pure library" functions in C than just the ones required in the new 
"freestanding" standard.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144889

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


[PATCH] D144626: [C++20] [Modules] Trying to compare the trailing require clause of the primary template when performing ODR checking

2023-02-27 Thread Chuanqi Xu via Phabricator via cfe-commits
ChuanqiXu added a comment.

This is another revision (https://reviews.llvm.org/D144707) which shouldn't be 
related with libcxx's modular build. So the failures should be irrelevant with 
the revision. @erichkeane @royjacobson Do you think it makes sense to land this 
revision in this case?


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

https://reviews.llvm.org/D144626

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


[clang] abafc86 - [AArch64] Use isSVESizelessBuiltinType instead of isSizelessBuiltinType in SVE specific code.

2023-02-27 Thread Craig Topper via cfe-commits

Author: Craig Topper
Date: 2023-02-27T17:39:50-08:00
New Revision: abafc869cb656a81ac35a4002627045a6fb37ff2

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

LOG: [AArch64] Use isSVESizelessBuiltinType instead of isSizelessBuiltinType in 
SVE specific code.

isSizelessBuiltinType includes RISC-V vector and WebAssembly reference
types. This code is not applicable to those types.

Added: 


Modified: 
clang/lib/Sema/SemaExpr.cpp

Removed: 




diff  --git a/clang/lib/Sema/SemaExpr.cpp b/clang/lib/Sema/SemaExpr.cpp
index d870ce4a7942e..73ecaa6c01e72 100644
--- a/clang/lib/Sema/SemaExpr.cpp
+++ b/clang/lib/Sema/SemaExpr.cpp
@@ -7937,7 +7937,7 @@ bool Sema::isValidSveBitcast(QualType srcTy, QualType 
destTy) {
   assert(srcTy->isVectorType() || destTy->isVectorType());
 
   auto ValidScalableConversion = [](QualType FirstType, QualType SecondType) {
-if (!FirstType->isSizelessBuiltinType())
+if (!FirstType->isSVESizelessBuiltinType())
   return false;
 
 const auto *VecTy = SecondType->getAs();



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


[PATCH] D129700: [clang] Don't emit type tests for dllexport/import classes

2023-02-27 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks updated this revision to Diff 500987.
aeubanks added a comment.

move HasHiddenLTOVisibility DLL code to AlwaysHasLTOVisibilityPublic


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129700

Files:
  clang/lib/CodeGen/CGVTables.cpp
  clang/test/CodeGenCXX/lto-visibility-inference.cpp


Index: clang/test/CodeGenCXX/lto-visibility-inference.cpp
===
--- clang/test/CodeGenCXX/lto-visibility-inference.cpp
+++ clang/test/CodeGenCXX/lto-visibility-inference.cpp
@@ -74,10 +74,10 @@
   // MS: type.test{{.*}}!"?AUC2@@"
   c2->f();
   // ITANIUM: type.test{{.*}}!"_ZTS2C3"
-  // MS: type.test{{.*}}!"?AUC3@@"
+  // MS-NOT: type.test{{.*}}!"?AUC3@@"
   c3->f();
   // ITANIUM: type.test{{.*}}!"_ZTS2C4"
-  // MS: type.test{{.*}}!"?AUC4@@"
+  // MS-NOT: type.test{{.*}}!"?AUC4@@"
   c4->f();
   // ITANIUM-NOT: type.test{{.*}}!"_ZTS2C5"
   // MS-NOT: type.test{{.*}}!"?AUC5@@"
Index: clang/lib/CodeGen/CGVTables.cpp
===
--- clang/lib/CodeGen/CGVTables.cpp
+++ clang/lib/CodeGen/CGVTables.cpp
@@ -1211,7 +1211,8 @@
 }
 
 bool CodeGenModule::AlwaysHasLTOVisibilityPublic(const CXXRecordDecl *RD) {
-  if (RD->hasAttr() || RD->hasAttr())
+  if (RD->hasAttr() || RD->hasAttr() ||
+  RD->hasAttr() || RD->hasAttr())
 return true;
 
   if (!getCodeGenOpts().LTOVisibilityPublicStd)
@@ -1238,13 +1239,9 @@
   if (!isExternallyVisible(LV.getLinkage()))
 return true;
 
-  if (getTriple().isOSBinFormatCOFF()) {
-if (RD->hasAttr() || RD->hasAttr())
-  return false;
-  } else {
-if (LV.getVisibility() != HiddenVisibility)
-  return false;
-  }
+  if (!getTriple().isOSBinFormatCOFF() &&
+  LV.getVisibility() != HiddenVisibility)
+return false;
 
   return !AlwaysHasLTOVisibilityPublic(RD);
 }


Index: clang/test/CodeGenCXX/lto-visibility-inference.cpp
===
--- clang/test/CodeGenCXX/lto-visibility-inference.cpp
+++ clang/test/CodeGenCXX/lto-visibility-inference.cpp
@@ -74,10 +74,10 @@
   // MS: type.test{{.*}}!"?AUC2@@"
   c2->f();
   // ITANIUM: type.test{{.*}}!"_ZTS2C3"
-  // MS: type.test{{.*}}!"?AUC3@@"
+  // MS-NOT: type.test{{.*}}!"?AUC3@@"
   c3->f();
   // ITANIUM: type.test{{.*}}!"_ZTS2C4"
-  // MS: type.test{{.*}}!"?AUC4@@"
+  // MS-NOT: type.test{{.*}}!"?AUC4@@"
   c4->f();
   // ITANIUM-NOT: type.test{{.*}}!"_ZTS2C5"
   // MS-NOT: type.test{{.*}}!"?AUC5@@"
Index: clang/lib/CodeGen/CGVTables.cpp
===
--- clang/lib/CodeGen/CGVTables.cpp
+++ clang/lib/CodeGen/CGVTables.cpp
@@ -1211,7 +1211,8 @@
 }
 
 bool CodeGenModule::AlwaysHasLTOVisibilityPublic(const CXXRecordDecl *RD) {
-  if (RD->hasAttr() || RD->hasAttr())
+  if (RD->hasAttr() || RD->hasAttr() ||
+  RD->hasAttr() || RD->hasAttr())
 return true;
 
   if (!getCodeGenOpts().LTOVisibilityPublicStd)
@@ -1238,13 +1239,9 @@
   if (!isExternallyVisible(LV.getLinkage()))
 return true;
 
-  if (getTriple().isOSBinFormatCOFF()) {
-if (RD->hasAttr() || RD->hasAttr())
-  return false;
-  } else {
-if (LV.getVisibility() != HiddenVisibility)
-  return false;
-  }
+  if (!getTriple().isOSBinFormatCOFF() &&
+  LV.getVisibility() != HiddenVisibility)
+return false;
 
   return !AlwaysHasLTOVisibilityPublic(RD);
 }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D143877: [NFC] [clang] Forward forwarding reference

2023-02-27 Thread David Blaikie via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG58ec6e09abe8: [NFC] [clang] Forward forwarding reference 
(authored by ccotter, committed by dblaikie).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143877

Files:
  clang/include/clang/AST/IgnoreExpr.h
  clang/unittests/AST/ASTExprTest.cpp
  clang/unittests/AST/CMakeLists.txt


Index: clang/unittests/AST/CMakeLists.txt
===
--- clang/unittests/AST/CMakeLists.txt
+++ clang/unittests/AST/CMakeLists.txt
@@ -7,6 +7,7 @@
 
 add_clang_unittest(ASTTests
   ASTContextParentMapTest.cpp
+  ASTExprTest.cpp
   ASTImporterFixtures.cpp
   ASTImporterTest.cpp
   ASTImporterObjCTest.cpp
Index: clang/unittests/AST/ASTExprTest.cpp
===
--- /dev/null
+++ clang/unittests/AST/ASTExprTest.cpp
@@ -0,0 +1,58 @@
+//===- unittests/AST/ASTExprTest.cpp --- AST Expr tests 
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file contains tests for AST Expr related methods.
+//
+//===--===//
+
+#include "ASTPrint.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/Expr.h"
+#include "clang/AST/IgnoreExpr.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Tooling/Tooling.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+
+TEST(ASTExpr, IgnoreExprCallbackForwarded) {
+  constexpr char Code[] = "";
+  auto AST = tooling::buildASTFromCodeWithArgs(Code, /*Args=*/{"-std=c++20"});
+  ASTContext  = AST->getASTContext();
+
+  auto createIntLiteral = [&](uint32_t Value) -> IntegerLiteral * {
+const int numBits = 32;
+return IntegerLiteral::Create(Ctx, llvm::APInt(numBits, Value),
+  Ctx.UnsignedIntTy, {});
+  };
+
+  struct IgnoreParens {
+Expr *operator()(Expr *E) & { return nullptr; }
+Expr *operator()(Expr *E) && {
+  if (auto *PE = dyn_cast(E)) {
+return PE->getSubExpr();
+  }
+  return E;
+}
+  };
+
+  {
+auto *IntExpr = createIntLiteral(10);
+ParenExpr *PE =
+new (Ctx) ParenExpr(SourceLocation{}, SourceLocation{}, IntExpr);
+EXPECT_EQ(IntExpr, IgnoreExprNodes(PE, IgnoreParens{}));
+  }
+
+  {
+IgnoreParens CB{};
+auto *IntExpr = createIntLiteral(10);
+ParenExpr *PE =
+new (Ctx) ParenExpr(SourceLocation{}, SourceLocation{}, IntExpr);
+EXPECT_EQ(nullptr, IgnoreExprNodes(PE, CB));
+  }
+}
Index: clang/include/clang/AST/IgnoreExpr.h
===
--- clang/include/clang/AST/IgnoreExpr.h
+++ clang/include/clang/AST/IgnoreExpr.h
@@ -23,7 +23,8 @@
 inline Expr *IgnoreExprNodesImpl(Expr *E) { return E; }
 template 
 Expr *IgnoreExprNodesImpl(Expr *E, FnTy &, FnTys &&... Fns) {
-  return IgnoreExprNodesImpl(Fn(E), std::forward(Fns)...);
+  return IgnoreExprNodesImpl(std::forward(Fn)(E),
+ std::forward(Fns)...);
 }
 } // namespace detail
 


Index: clang/unittests/AST/CMakeLists.txt
===
--- clang/unittests/AST/CMakeLists.txt
+++ clang/unittests/AST/CMakeLists.txt
@@ -7,6 +7,7 @@
 
 add_clang_unittest(ASTTests
   ASTContextParentMapTest.cpp
+  ASTExprTest.cpp
   ASTImporterFixtures.cpp
   ASTImporterTest.cpp
   ASTImporterObjCTest.cpp
Index: clang/unittests/AST/ASTExprTest.cpp
===
--- /dev/null
+++ clang/unittests/AST/ASTExprTest.cpp
@@ -0,0 +1,58 @@
+//===- unittests/AST/ASTExprTest.cpp --- AST Expr tests ---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file contains tests for AST Expr related methods.
+//
+//===--===//
+
+#include "ASTPrint.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/Expr.h"
+#include "clang/AST/IgnoreExpr.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Tooling/Tooling.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+
+TEST(ASTExpr, IgnoreExprCallbackForwarded) {
+  constexpr char Code[] = "";
+  auto AST = tooling::buildASTFromCodeWithArgs(Code, /*Args=*/{"-std=c++20"});
+  ASTContext  = AST->getASTContext();
+
+  auto createIntLiteral = [&](uint32_t 

[clang] 58ec6e0 - [NFC] [clang] Forward forwarding reference

2023-02-27 Thread David Blaikie via cfe-commits

Author: Chris Cotter
Date: 2023-02-28T01:27:21Z
New Revision: 58ec6e09abe8083709802833572bca931b2d15d9

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

LOG: [NFC] [clang] Forward forwarding reference

Update function bodies to forward forwarding references.
I spotted this while authoring a clang-tidy tool for CppCoreGuideline F.19

Reviewed By: dblaikie

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

Added: 
clang/unittests/AST/ASTExprTest.cpp

Modified: 
clang/include/clang/AST/IgnoreExpr.h
clang/unittests/AST/CMakeLists.txt

Removed: 




diff  --git a/clang/include/clang/AST/IgnoreExpr.h 
b/clang/include/clang/AST/IgnoreExpr.h
index a7e9b07bef6c4..f8d2d6c7d00c0 100644
--- a/clang/include/clang/AST/IgnoreExpr.h
+++ b/clang/include/clang/AST/IgnoreExpr.h
@@ -23,7 +23,8 @@ namespace detail {
 inline Expr *IgnoreExprNodesImpl(Expr *E) { return E; }
 template 
 Expr *IgnoreExprNodesImpl(Expr *E, FnTy &, FnTys &&... Fns) {
-  return IgnoreExprNodesImpl(Fn(E), std::forward(Fns)...);
+  return IgnoreExprNodesImpl(std::forward(Fn)(E),
+ std::forward(Fns)...);
 }
 } // namespace detail
 

diff  --git a/clang/unittests/AST/ASTExprTest.cpp 
b/clang/unittests/AST/ASTExprTest.cpp
new file mode 100644
index 0..ec75492ccff8e
--- /dev/null
+++ b/clang/unittests/AST/ASTExprTest.cpp
@@ -0,0 +1,58 @@
+//===- unittests/AST/ASTExprTest.cpp --- AST Expr tests 
---===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+//
+// This file contains tests for AST Expr related methods.
+//
+//===--===//
+
+#include "ASTPrint.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/AST/Expr.h"
+#include "clang/AST/IgnoreExpr.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Tooling/Tooling.h"
+#include "gtest/gtest.h"
+
+using namespace clang;
+
+TEST(ASTExpr, IgnoreExprCallbackForwarded) {
+  constexpr char Code[] = "";
+  auto AST = tooling::buildASTFromCodeWithArgs(Code, /*Args=*/{"-std=c++20"});
+  ASTContext  = AST->getASTContext();
+
+  auto createIntLiteral = [&](uint32_t Value) -> IntegerLiteral * {
+const int numBits = 32;
+return IntegerLiteral::Create(Ctx, llvm::APInt(numBits, Value),
+  Ctx.UnsignedIntTy, {});
+  };
+
+  struct IgnoreParens {
+Expr *operator()(Expr *E) & { return nullptr; }
+Expr *operator()(Expr *E) && {
+  if (auto *PE = dyn_cast(E)) {
+return PE->getSubExpr();
+  }
+  return E;
+}
+  };
+
+  {
+auto *IntExpr = createIntLiteral(10);
+ParenExpr *PE =
+new (Ctx) ParenExpr(SourceLocation{}, SourceLocation{}, IntExpr);
+EXPECT_EQ(IntExpr, IgnoreExprNodes(PE, IgnoreParens{}));
+  }
+
+  {
+IgnoreParens CB{};
+auto *IntExpr = createIntLiteral(10);
+ParenExpr *PE =
+new (Ctx) ParenExpr(SourceLocation{}, SourceLocation{}, IntExpr);
+EXPECT_EQ(nullptr, IgnoreExprNodes(PE, CB));
+  }
+}

diff  --git a/clang/unittests/AST/CMakeLists.txt 
b/clang/unittests/AST/CMakeLists.txt
index 13b945df3b589..b664b64070328 100644
--- a/clang/unittests/AST/CMakeLists.txt
+++ b/clang/unittests/AST/CMakeLists.txt
@@ -7,6 +7,7 @@ set(LLVM_LINK_COMPONENTS
 
 add_clang_unittest(ASTTests
   ASTContextParentMapTest.cpp
+  ASTExprTest.cpp
   ASTImporterFixtures.cpp
   ASTImporterTest.cpp
   ASTImporterObjCTest.cpp



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


[PATCH] D144931: DebugInfo: Disable ctor homing for types with only deleted (non copy/move) ctors

2023-02-27 Thread David Blaikie 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 rGd8a1a559f300: DebugInfo: Disable ctor homing for types with 
only deleted (non copy/move) ctors (authored by dblaikie).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144931

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGenCXX/debug-info-limited-ctor.cpp


Index: clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
===
--- clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
+++ clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
@@ -68,6 +68,21 @@
 };
 void f(K k) {}
 
+// CHECK-DAG: !DICompositeType({{.*}}name: 
"DeletedCtors",{{.*}}DIFlagTypePassBy
+struct NonTrivial {
+  NonTrivial();
+};
+struct DeletedCtors {
+  DeletedCtors() = delete;
+  DeletedCtors(const DeletedCtors &) = default;
+  void f1();
+  NonTrivial t;
+};
+
+const NonTrivial (const DeletedCtors ) {
+  return D.t;
+}
+
 // Test that we don't use constructor homing on lambdas.
 // CHECK-DAG: ![[L:.*]] ={{.*}}!DISubprogram({{.*}}name: "L"
 // CHECK-DAG: !DICompositeType({{.*}}scope: ![[L]], {{.*}}DIFlagTypePassByValue
@@ -89,3 +104,4 @@
 }
 
 // ITANIUM-DAG: !DICompositeType({{.*}}name: "VTableAndCtor", {{.*}}flags: 
DIFlagFwdDecl
+
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -2489,9 +2489,18 @@
   if (isClassOrMethodDLLImport(RD))
 return false;
 
-  return !RD->isLambda() && !RD->isAggregate() &&
- !RD->hasTrivialDefaultConstructor() &&
- !RD->hasConstexprNonCopyMoveConstructor();
+  if (RD->isLambda() || RD->isAggregate() ||
+  RD->hasTrivialDefaultConstructor() ||
+  RD->hasConstexprNonCopyMoveConstructor())
+return false;
+
+  for (const CXXConstructorDecl *Ctor : RD->ctors()) {
+if (Ctor->isCopyOrMoveConstructor())
+  continue;
+if (!Ctor->isDeleted())
+  return true;
+  }
+  return false;
 }
 
 static bool shouldOmitDefinition(codegenoptions::DebugInfoKind DebugKind,


Index: clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
===
--- clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
+++ clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
@@ -68,6 +68,21 @@
 };
 void f(K k) {}
 
+// CHECK-DAG: !DICompositeType({{.*}}name: "DeletedCtors",{{.*}}DIFlagTypePassBy
+struct NonTrivial {
+  NonTrivial();
+};
+struct DeletedCtors {
+  DeletedCtors() = delete;
+  DeletedCtors(const DeletedCtors &) = default;
+  void f1();
+  NonTrivial t;
+};
+
+const NonTrivial (const DeletedCtors ) {
+  return D.t;
+}
+
 // Test that we don't use constructor homing on lambdas.
 // CHECK-DAG: ![[L:.*]] ={{.*}}!DISubprogram({{.*}}name: "L"
 // CHECK-DAG: !DICompositeType({{.*}}scope: ![[L]], {{.*}}DIFlagTypePassByValue
@@ -89,3 +104,4 @@
 }
 
 // ITANIUM-DAG: !DICompositeType({{.*}}name: "VTableAndCtor", {{.*}}flags: DIFlagFwdDecl
+
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -2489,9 +2489,18 @@
   if (isClassOrMethodDLLImport(RD))
 return false;
 
-  return !RD->isLambda() && !RD->isAggregate() &&
- !RD->hasTrivialDefaultConstructor() &&
- !RD->hasConstexprNonCopyMoveConstructor();
+  if (RD->isLambda() || RD->isAggregate() ||
+  RD->hasTrivialDefaultConstructor() ||
+  RD->hasConstexprNonCopyMoveConstructor())
+return false;
+
+  for (const CXXConstructorDecl *Ctor : RD->ctors()) {
+if (Ctor->isCopyOrMoveConstructor())
+  continue;
+if (!Ctor->isDeleted())
+  return true;
+  }
+  return false;
 }
 
 static bool shouldOmitDefinition(codegenoptions::DebugInfoKind DebugKind,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] d8a1a55 - DebugInfo: Disable ctor homing for types with only deleted (non copy/move) ctors

2023-02-27 Thread David Blaikie via cfe-commits

Author: David Blaikie
Date: 2023-02-28T01:25:22Z
New Revision: d8a1a559f3009a31c517f864156db91d2ae3012c

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

LOG: DebugInfo: Disable ctor homing for types with only deleted (non copy/move) 
ctors

Such a type is never going to have a ctor home, and may be used for type
punning or other ways of creating objects.

May be a more generally acceptable solution in some cases compared to
attributing with [[clang::standalone_debug]].

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

Added: 


Modified: 
clang/lib/CodeGen/CGDebugInfo.cpp
clang/test/CodeGenCXX/debug-info-limited-ctor.cpp

Removed: 




diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 4dab595ada76b..126b239042ee1 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -2489,9 +2489,18 @@ static bool canUseCtorHoming(const CXXRecordDecl *RD) {
   if (isClassOrMethodDLLImport(RD))
 return false;
 
-  return !RD->isLambda() && !RD->isAggregate() &&
- !RD->hasTrivialDefaultConstructor() &&
- !RD->hasConstexprNonCopyMoveConstructor();
+  if (RD->isLambda() || RD->isAggregate() ||
+  RD->hasTrivialDefaultConstructor() ||
+  RD->hasConstexprNonCopyMoveConstructor())
+return false;
+
+  for (const CXXConstructorDecl *Ctor : RD->ctors()) {
+if (Ctor->isCopyOrMoveConstructor())
+  continue;
+if (!Ctor->isDeleted())
+  return true;
+  }
+  return false;
 }
 
 static bool shouldOmitDefinition(codegenoptions::DebugInfoKind DebugKind,

diff  --git a/clang/test/CodeGenCXX/debug-info-limited-ctor.cpp 
b/clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
index ac53cace075cd..18adfdeed0480 100644
--- a/clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
+++ b/clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
@@ -68,6 +68,21 @@ class K {
 };
 void f(K k) {}
 
+// CHECK-DAG: !DICompositeType({{.*}}name: 
"DeletedCtors",{{.*}}DIFlagTypePassBy
+struct NonTrivial {
+  NonTrivial();
+};
+struct DeletedCtors {
+  DeletedCtors() = delete;
+  DeletedCtors(const DeletedCtors &) = default;
+  void f1();
+  NonTrivial t;
+};
+
+const NonTrivial (const DeletedCtors ) {
+  return D.t;
+}
+
 // Test that we don't use constructor homing on lambdas.
 // CHECK-DAG: ![[L:.*]] ={{.*}}!DISubprogram({{.*}}name: "L"
 // CHECK-DAG: !DICompositeType({{.*}}scope: ![[L]], {{.*}}DIFlagTypePassByValue
@@ -89,3 +104,4 @@ VTableAndCtor::VTableAndCtor() {
 }
 
 // ITANIUM-DAG: !DICompositeType({{.*}}name: "VTableAndCtor", {{.*}}flags: 
DIFlagFwdDecl
+



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


[PATCH] D144934: [clang] drop buggy use of `-serialize-diagnostics` flag

2023-02-27 Thread Ashay Rane via Phabricator via cfe-commits
ashay-github created this revision.
ashay-github added reviewers: ChuanqiXu, jansvoboda11, ben.boeckel.
Herald added a project: All.
ashay-github requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

The `-serialize-diagnostics` flag requires a filename to be passed
immediately after it, but the filename argument was skipped in the
P1689 .cppm clang test.  This caused the code 
to incorrectly consume the
argument that followed as the dignostics file.

Since the `-serialize-diagnostics` flag isn't needed for this test to
work, this patch removes it instead of passing a file argument.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D144934

Files:
  clang/test/ClangScanDeps/P1689.cppm


Index: clang/test/ClangScanDeps/P1689.cppm
===
--- clang/test/ClangScanDeps/P1689.cppm
+++ clang/test/ClangScanDeps/P1689.cppm
@@ -40,7 +40,7 @@
 //
 // Check that we can mix the use of -format=p1689 and -fmodules.
 // RUN: clang-scan-deps -format=p1689 \
-// RUN:   -- %clang++ -std=c++20 -fmodules -fimplicit-module-maps 
-fmodules-cache-path=%t/cache -serialize-diagnostics -c %t/impl_part.cppm -o 
%t/impl_part.o \
+// RUN:   -- %clang++ -std=c++20 -fmodules -fimplicit-module-maps 
-fmodules-cache-path=%t/cache -c %t/impl_part.cppm -o %t/impl_part.o \
 // RUN:   | FileCheck %t/impl_part.cppm -DPREFIX=%/t
 
 //--- P1689.json.in


Index: clang/test/ClangScanDeps/P1689.cppm
===
--- clang/test/ClangScanDeps/P1689.cppm
+++ clang/test/ClangScanDeps/P1689.cppm
@@ -40,7 +40,7 @@
 //
 // Check that we can mix the use of -format=p1689 and -fmodules.
 // RUN: clang-scan-deps -format=p1689 \
-// RUN:   -- %clang++ -std=c++20 -fmodules -fimplicit-module-maps -fmodules-cache-path=%t/cache -serialize-diagnostics -c %t/impl_part.cppm -o %t/impl_part.o \
+// RUN:   -- %clang++ -std=c++20 -fmodules -fimplicit-module-maps -fmodules-cache-path=%t/cache -c %t/impl_part.cppm -o %t/impl_part.o \
 // RUN:   | FileCheck %t/impl_part.cppm -DPREFIX=%/t
 
 //--- P1689.json.in
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D144931: DebugInfo: Disable ctor homing for types with only deleted (non copy/move) ctors

2023-02-27 Thread Amy Huang via Phabricator via cfe-commits
akhuang accepted this revision.
akhuang added a comment.
This revision is now accepted and ready to land.

Thanks for adding this!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144931

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


[PATCH] D143877: [NFC] [clang] Forward forwarding reference

2023-02-27 Thread Chris Cotter via Phabricator via cfe-commits
ccotter added a comment.

I don't have commit access - could you use `Author: Chris Cotter 
`? Thanks!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143877

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


[PATCH] D144931: DebugInfo: Disable ctor homing for types with only deleted (non copy/move) ctors

2023-02-27 Thread David Blaikie via Phabricator via cfe-commits
dblaikie created this revision.
dblaikie added a reviewer: akhuang.
Herald added a project: All.
dblaikie requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Such a type is never going to have a ctor home, and may be used for type
punning or other ways of creating objects.

May be a more generally acceptable solution in some cases compared to
attributing with [[clang::standalone_debug]].


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D144931

Files:
  clang/lib/CodeGen/CGDebugInfo.cpp
  clang/test/CodeGenCXX/debug-info-limited-ctor.cpp


Index: clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
===
--- clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
+++ clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
@@ -68,6 +68,21 @@
 };
 void f(K k) {}
 
+// CHECK-DAG: !DICompositeType({{.*}}name: 
"DeletedCtors",{{.*}}DIFlagTypePassBy
+struct NonTrivial {
+  NonTrivial();
+};
+struct DeletedCtors {
+  DeletedCtors() = delete;
+  DeletedCtors(const DeletedCtors &) = default;
+  void f1();
+  NonTrivial t;
+};
+
+const NonTrivial (const DeletedCtors ) {
+  return D.t;
+}
+
 // Test that we don't use constructor homing on lambdas.
 // CHECK-DAG: ![[L:.*]] ={{.*}}!DISubprogram({{.*}}name: "L"
 // CHECK-DAG: !DICompositeType({{.*}}scope: ![[L]], {{.*}}DIFlagTypePassByValue
@@ -89,3 +104,4 @@
 }
 
 // ITANIUM-DAG: !DICompositeType({{.*}}name: "VTableAndCtor", {{.*}}flags: 
DIFlagFwdDecl
+
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -2489,9 +2489,18 @@
   if (isClassOrMethodDLLImport(RD))
 return false;
 
-  return !RD->isLambda() && !RD->isAggregate() &&
- !RD->hasTrivialDefaultConstructor() &&
- !RD->hasConstexprNonCopyMoveConstructor();
+  if (RD->isLambda() || RD->isAggregate() ||
+  RD->hasTrivialDefaultConstructor() ||
+  RD->hasConstexprNonCopyMoveConstructor())
+return false;
+
+  for (const CXXConstructorDecl *Ctor : RD->ctors()) {
+if (Ctor->isCopyOrMoveConstructor())
+  continue;
+if (!Ctor->isDeleted())
+  return true;
+  }
+  return false;
 }
 
 static bool shouldOmitDefinition(codegenoptions::DebugInfoKind DebugKind,


Index: clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
===
--- clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
+++ clang/test/CodeGenCXX/debug-info-limited-ctor.cpp
@@ -68,6 +68,21 @@
 };
 void f(K k) {}
 
+// CHECK-DAG: !DICompositeType({{.*}}name: "DeletedCtors",{{.*}}DIFlagTypePassBy
+struct NonTrivial {
+  NonTrivial();
+};
+struct DeletedCtors {
+  DeletedCtors() = delete;
+  DeletedCtors(const DeletedCtors &) = default;
+  void f1();
+  NonTrivial t;
+};
+
+const NonTrivial (const DeletedCtors ) {
+  return D.t;
+}
+
 // Test that we don't use constructor homing on lambdas.
 // CHECK-DAG: ![[L:.*]] ={{.*}}!DISubprogram({{.*}}name: "L"
 // CHECK-DAG: !DICompositeType({{.*}}scope: ![[L]], {{.*}}DIFlagTypePassByValue
@@ -89,3 +104,4 @@
 }
 
 // ITANIUM-DAG: !DICompositeType({{.*}}name: "VTableAndCtor", {{.*}}flags: DIFlagFwdDecl
+
Index: clang/lib/CodeGen/CGDebugInfo.cpp
===
--- clang/lib/CodeGen/CGDebugInfo.cpp
+++ clang/lib/CodeGen/CGDebugInfo.cpp
@@ -2489,9 +2489,18 @@
   if (isClassOrMethodDLLImport(RD))
 return false;
 
-  return !RD->isLambda() && !RD->isAggregate() &&
- !RD->hasTrivialDefaultConstructor() &&
- !RD->hasConstexprNonCopyMoveConstructor();
+  if (RD->isLambda() || RD->isAggregate() ||
+  RD->hasTrivialDefaultConstructor() ||
+  RD->hasConstexprNonCopyMoveConstructor())
+return false;
+
+  for (const CXXConstructorDecl *Ctor : RD->ctors()) {
+if (Ctor->isCopyOrMoveConstructor())
+  continue;
+if (!Ctor->isDeleted())
+  return true;
+  }
+  return false;
 }
 
 static bool shouldOmitDefinition(codegenoptions::DebugInfoKind DebugKind,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D140794: [ASTMatcher] Add coroutineBodyStmt matcher

2023-02-27 Thread Sam McCall via Phabricator via cfe-commits
sammccall added a comment.

It seems pretty weird to me that the two child edges from functiondecl -> 
coroutinebodystmt -> compoundstmt are both called "body".

However that *is* what they're called in the AST today, and having the matchers 
correspond to the AST's names seems important.
So this seems OK to me (renaming the inner "body" edge to something else seems 
like a good idea, but is out of scope here).


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140794

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


[PATCH] D94627: [PowerPC][PC Rel] Implement option to omit Power10 instructions from stubs

2023-02-27 Thread Fangrui Song via Phabricator via cfe-commits
MaskRay added a comment.
Herald added a project: All.

The used code sequence has 2 bugs so the output will crash. I fixed them in 
7198c87f42f6c15d76b127c1c63530e9b4d5dd39 
 and added 
my notes to https://maskray.me/blog/2023-02-26-linker-notes-on-power-isa


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D94627

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


[PATCH] D143803: [clang][alias|ifunc]: Add a diagnostic for mangled names

2023-02-27 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

I think "mangled name" is probably the closest without being overly verbose for 
the average user.

We do use "mangled name" in a few places already, some which look not too 
unrelated to this one:

  clang/include/clang/Basic/DiagnosticSemaKinds.td:  "mangled name of %0 will 
change in C++17 due to non-throwing exception "
  clang/include/clang/Basic/DiagnosticSemaKinds.td-  "specification in function 
signature">, InGroup;
  clang/include/clang/Basic/DiagnosticSemaKinds.td-
  --
  clang/include/clang/Basic/DiagnosticSemaKinds.td:def 
err_hip_invalid_args_builtin_mangled_name : Error<
  clang/include/clang/Basic/DiagnosticSemaKinds.td-"invalid argument: 
symbol must be a device-side function or global variable">;
  --
  clang/include/clang/Basic/DiagnosticFrontendKinds.td:def 
err_duplicate_mangled_name : Error<
  clang/include/clang/Basic/DiagnosticFrontendKinds.td:  "definition with same 
mangled name '%0' as another definition">;


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143803

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


[PATCH] D144680: [Coroutines] Avoid creating conditional cleanup markers in suspend block

2023-02-27 Thread Wei Wang via Phabricator via cfe-commits
weiwang updated this revision to Diff 500958.
weiwang edited the summary of this revision.
weiwang added a comment.

add test case and some comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144680

Files:
  clang/lib/CodeGen/CGCoroutine.cpp
  clang/lib/CodeGen/CGExpr.cpp
  clang/lib/CodeGen/CodeGenFunction.h
  clang/test/CodeGenCoroutines/pr59181.cpp

Index: clang/test/CodeGenCoroutines/pr59181.cpp
===
--- /dev/null
+++ clang/test/CodeGenCoroutines/pr59181.cpp
@@ -0,0 +1,58 @@
+// Test for PR59181. Tests that no conditional cleanup is created around await_suspend.
+
+// RUN: %clang_cc1 -emit-llvm %s -o - -std=c++20 -disable-llvm-passes -fsanitize-address-use-after-scope | FileCheck %s
+
+#include "Inputs/coroutine.h"
+
+struct Task {
+  int value_;
+  struct promise_type {
+Task get_return_object() {
+  return Task{0};
+}
+
+std::suspend_never initial_suspend() noexcept {
+  return {};
+}
+
+std::suspend_never final_suspend() noexcept {
+  return {};
+}
+
+void return_value(Task t) noexcept {}
+void unhandled_exception() noexcept {}
+
+auto await_transform(Task t) {
+  struct Suspension {
+auto await_ready() noexcept { return false;}
+auto await_suspend(std::coroutine_handle<> coro) {
+  coro.destroy();
+}
+
+auto await_resume() noexcept {
+  return 0;
+}
+  };
+  return Suspension{};
+}
+  };
+};
+
+Task bar(bool cond) {
+  co_return cond ? Task{ co_await Task{}}: Task{};
+}
+
+void foo() {
+  bar(true);
+}
+
+// CHECK: cleanup.cont:{{.*}}
+// CHECK-NEXT: load i8
+// CHECK-NEXT: trunc
+// CHECK-NEXT: store i1 false
+// CHECK-NEXT: call void @llvm.lifetime.start.p0(i64 8, ptr [[REF:%ref.tmp[0-9]+]])
+
+// CHECK: await.suspend:{{.*}}
+// CHECK-NOT: call void @llvm.lifetime.start.p0(i64 8, ptr [[REF]])
+// CHECK: call void @_ZZN4Task12promise_type15await_transformES_EN10Suspension13await_suspendESt16coroutine_handleIvE
+// CHECK-NEXT: call void @llvm.lifetime.end.p0(i64 8, ptr [[REF]])
Index: clang/lib/CodeGen/CodeGenFunction.h
===
--- clang/lib/CodeGen/CodeGenFunction.h
+++ clang/lib/CodeGen/CodeGenFunction.h
@@ -333,6 +333,7 @@
   // in this header.
   struct CGCoroInfo {
 std::unique_ptr Data;
+bool InSuspendBlock = false;
 CGCoroInfo();
 ~CGCoroInfo();
   };
@@ -342,6 +343,10 @@
 return CurCoro.Data != nullptr;
   }
 
+  bool inSuspendBlock() const {
+return isCoroutine() && CurCoro.InSuspendBlock;
+  }
+
   /// CurGD - The GlobalDecl for the current function being compiled.
   GlobalDecl CurGD;
 
Index: clang/lib/CodeGen/CGExpr.cpp
===
--- clang/lib/CodeGen/CGExpr.cpp
+++ clang/lib/CodeGen/CGExpr.cpp
@@ -541,13 +541,17 @@
   // Avoid creating a conditional cleanup just to hold an llvm.lifetime.end
   // marker. Instead, start the lifetime of a conditional temporary earlier
   // so that it's unconditional. Don't do this with sanitizers which need
-  // more precise lifetime marks.
+  // more precise lifetime marks. However when inside an "await.suspend"
+  // block, we should always avoid conditional cleanup because it creates
+  // boolean marker that lives across await_suspend, which can destroy coro
+  // frame.
   ConditionalEvaluation *OldConditional = nullptr;
   CGBuilderTy::InsertPoint OldIP;
   if (isInConditionalBranch() && !E->getType().isDestructedType() &&
-  !SanOpts.has(SanitizerKind::HWAddress) &&
-  !SanOpts.has(SanitizerKind::Memory) &&
-  !CGM.getCodeGenOpts().SanitizeAddressUseAfterScope) {
+  ((!SanOpts.has(SanitizerKind::HWAddress) &&
+!SanOpts.has(SanitizerKind::Memory) &&
+!CGM.getCodeGenOpts().SanitizeAddressUseAfterScope) ||
+   inSuspendBlock())) {
 OldConditional = OutermostConditional;
 OutermostConditional = nullptr;
 
Index: clang/lib/CodeGen/CGCoroutine.cpp
===
--- clang/lib/CodeGen/CGCoroutine.cpp
+++ clang/lib/CodeGen/CGCoroutine.cpp
@@ -198,7 +198,9 @@
   auto *NullPtr = llvm::ConstantPointerNull::get(CGF.CGM.Int8PtrTy);
   auto *SaveCall = Builder.CreateCall(CoroSave, {NullPtr});
 
+  CGF.CurCoro.InSuspendBlock = true;
   auto *SuspendRet = CGF.EmitScalarExpr(S.getSuspendExpr());
+  CGF.CurCoro.InSuspendBlock = false;
   if (SuspendRet != nullptr && SuspendRet->getType()->isIntegerTy(1)) {
 // Veto suspension if requested by bool returning await_suspend.
 BasicBlock *RealSuspendBlock =
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D143877: [NFC] [clang] Forward forwarding reference

2023-02-27 Thread David Blaikie via Phabricator via cfe-commits
dblaikie accepted this revision.
dblaikie added a comment.
This revision is now accepted and ready to land.

Looks good, thanks!

Can you commit this yourself, or would you like me to commit it on your behalf? 
(what name/email address would you like it attributed to?)


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143877

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


[PATCH] D143553: [Clang][CMake] Use perf-training for Clang-BOLT

2023-02-27 Thread Amir Ayupov via Phabricator via cfe-commits
Amir added a comment.

Ping @phosek


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143553

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


[PATCH] D143553: [Clang][CMake] Use perf-training for Clang-BOLT

2023-02-27 Thread Amir Ayupov via Phabricator via cfe-commits
Amir updated this revision to Diff 500956.
Amir added a comment.

Rebase, reduce changes


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143553

Files:
  clang/CMakeLists.txt
  clang/cmake/caches/BOLT.cmake
  clang/utils/perf-training/CMakeLists.txt
  clang/utils/perf-training/bolt.lit.cfg
  clang/utils/perf-training/bolt.lit.site.cfg.in

Index: clang/utils/perf-training/bolt.lit.site.cfg.in
===
--- /dev/null
+++ clang/utils/perf-training/bolt.lit.site.cfg.in
@@ -0,0 +1,14 @@
+@LIT_SITE_CFG_IN_HEADER@
+
+import sys
+
+config.clang_tools_dir = lit_config.substitute("@CURRENT_TOOLS_DIR@")
+config.perf_helper_dir = "@CMAKE_CURRENT_SOURCE_DIR@"
+config.test_exec_root = "@CMAKE_CURRENT_BINARY_DIR@"
+config.test_source_root = "@CLANG_PGO_TRAINING_DATA@"
+config.target_triple = "@LLVM_TARGET_TRIPLE@"
+config.python_exe = "@Python3_EXECUTABLE@"
+config.clang_obj_root = path(r"@CLANG_BINARY_DIR@")
+
+# Let the main config do the real work.
+lit_config.load_config(config, "@CLANG_SOURCE_DIR@/utils/perf-training/bolt.lit.cfg")
Index: clang/utils/perf-training/bolt.lit.cfg
===
--- /dev/null
+++ clang/utils/perf-training/bolt.lit.cfg
@@ -0,0 +1,20 @@
+# -*- Python -*-
+
+from lit import Test
+import lit.formats
+import lit.util
+import os
+import subprocess
+
+config.clang = os.path.realpath(lit.util.which('clang-bolt.inst', config.clang_tools_dir)).replace('\\', '/')
+
+config.name = 'Clang Perf Training'
+config.suffixes = ['.c', '.cc', '.cpp', '.m', '.mm', '.cu', '.ll', '.cl', '.s', '.S', '.modulemap', '.test']
+
+use_lit_shell = os.environ.get("LIT_USE_INTERNAL_SHELL")
+config.test_format = lit.formats.ShTest(use_lit_shell == "0")
+config.substitutions.append( ('%clang_cpp_skip_driver', ' %s --driver-mode=g++ ' % (config.clang)))
+config.substitutions.append( ('%clang_cpp', ' %s --driver-mode=g++ ' % (config.clang)))
+config.substitutions.append( ('%clang_skip_driver', ' %s ' % (config.clang)))
+config.substitutions.append( ('%clang', ' %s ' % (config.clang) ) )
+config.substitutions.append( ('%test_root', config.test_exec_root ) )
Index: clang/utils/perf-training/CMakeLists.txt
===
--- clang/utils/perf-training/CMakeLists.txt
+++ clang/utils/perf-training/CMakeLists.txt
@@ -61,3 +61,26 @@
 COMMENT "Generating order file"
 DEPENDS generate-dtrace-logs)
 endif()
+
+if(CLANG_BOLT_INSTRUMENT AND NOT LLVM_BUILD_INSTRUMENTED)
+  configure_lit_site_cfg(
+${CMAKE_CURRENT_SOURCE_DIR}/bolt.lit.site.cfg.in
+${CMAKE_CURRENT_BINARY_DIR}/bolt-fdata/lit.site.cfg
+)
+
+  add_lit_testsuite(generate-bolt-fdata "Generating BOLT profile for Clang"
+${CMAKE_CURRENT_BINARY_DIR}/bolt-fdata/
+EXCLUDE_FROM_CHECK_ALL
+DEPENDS clang-instrumented clear-bolt-fdata
+)
+
+  add_custom_target(clear-bolt-fdata
+COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py clean ${CMAKE_CURRENT_BINARY_DIR} fdata
+COMMENT "Clearing old BOLT fdata")
+
+  # Merge profiles into one using merge-fdata
+  add_custom_target(clang-bolt-profile
+COMMAND "${Python3_EXECUTABLE}" ${CMAKE_CURRENT_SOURCE_DIR}/perf-helper.py merge-fdata $ ${CMAKE_CURRENT_BINARY_DIR}/prof.fdata ${CMAKE_CURRENT_BINARY_DIR}
+COMMENT "Merging BOLT fdata"
+DEPENDS merge-fdata generate-bolt-fdata)
+endif()
Index: clang/cmake/caches/BOLT.cmake
===
--- clang/cmake/caches/BOLT.cmake
+++ clang/cmake/caches/BOLT.cmake
@@ -1,9 +1,6 @@
 set(CMAKE_BUILD_TYPE Release CACHE STRING "")
 set(CLANG_BOLT_INSTRUMENT ON CACHE BOOL "")
-set(CLANG_BOLT_INSTRUMENT_PROJECTS "llvm" CACHE STRING "")
-set(CLANG_BOLT_INSTRUMENT_TARGETS "count" CACHE STRING "")
 set(CMAKE_EXE_LINKER_FLAGS "-Wl,--emit-relocs,-znow" CACHE STRING "")
-set(CLANG_BOLT_INSTRUMENT_EXTRA_CMAKE_FLAGS "" CACHE STRING "")
 
 set(LLVM_ENABLE_PROJECTS "bolt;clang" CACHE STRING "")
 set(LLVM_TARGETS_TO_BUILD Native CACHE STRING "")
Index: clang/CMakeLists.txt
===
--- clang/CMakeLists.txt
+++ clang/CMakeLists.txt
@@ -861,9 +861,8 @@
 
 if (CLANG_BOLT_INSTRUMENT AND NOT LLVM_BUILD_INSTRUMENTED)
   set(CLANG_PATH ${LLVM_RUNTIME_OUTPUT_INTDIR}/clang)
-  set(CLANGXX_PATH ${CLANG_PATH}++)
   set(CLANG_INSTRUMENTED ${CLANG_PATH}-bolt.inst)
-  set(CLANGXX_INSTRUMENTED ${CLANGXX_PATH}-bolt.inst)
+  set(BOLT_FDATA ${CMAKE_CURRENT_BINARY_DIR}/utils/perf-training/prof.fdata)
 
   # Instrument clang with BOLT
   add_custom_target(clang-instrumented
@@ -873,73 +872,11 @@
 DEPENDS clang llvm-bolt
 COMMAND llvm-bolt ${CLANG_PATH} -o ${CLANG_INSTRUMENTED}
   -instrument --instrumentation-file-append-pid
-  --instrumentation-file=${CMAKE_CURRENT_BINARY_DIR}/prof.fdata
+  

[PATCH] D129700: [clang] Don't emit type tests for dllexport/import classes

2023-02-27 Thread Peter Collingbourne via Phabricator via cfe-commits
pcc added a comment.

Can't the code in CodeGenModule::HasHiddenLTOVisibility be moved here instead 
of duplicating it?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129700

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


[PATCH] D144309: [HLSL] add max/min library functions

2023-02-27 Thread Xiang Li via Phabricator via cfe-commits
python3kgae added a comment.

In D144309#4156971 , @bob80905 wrote:

> add int support for max/min.

Sorry didn't check more :(.

Now i16/u16/i32/u32/i64/u64/f16/f32/f64 are all supported for min/max in hlsl.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144309

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


[PATCH] D144889: [C2x] Support in freestanding

2023-02-27 Thread Richard Smith - zygoloid via Phabricator via cfe-commits
rsmith added a comment.

Do we know what GCC intends to do about this C change? Per their documentation 
, they intend for GCC to be 
/ eventually become a complete freestanding implementation without need for a 
separate libc:

> GCC aims towards being usable as a conforming freestanding implementation, or 
> as the compiler for a conforming hosted implementation.
> GCC does not provide the library facilities required only of hosted 
> implementations, nor **yet** all the facilities required by C99 of 
> freestanding implementations on all platforms.

(Emphasis mine.) Likely because of GCC's perspective on this, the set of C 
headers provided by GCC, Clang, ICC, etc. has included the complete list of 
freestanding headers and more or less no others, with some libc implementations 
providing the full set and some providing just the non-freestanding ones. If 
we're moving away from that, we'll presumably need a new agreement between 
compiler folks and libc folks about which headers are provided by whom (and I 
expect it'll be "compilers provide what the C standard said before this change 
to freestanding and we pretend the change never happened").


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144889

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


[PATCH] D144309: [HLSL] add max/min library functions

2023-02-27 Thread Joshua Batista via Phabricator via cfe-commits
bob80905 updated this revision to Diff 500953.
bob80905 added a comment.

add int support for max/min.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144309

Files:
  clang/lib/Headers/hlsl/hlsl_intrinsics.h
  clang/test/CodeGenHLSL/builtins/max.hlsl
  clang/test/CodeGenHLSL/builtins/min.hlsl

Index: clang/test/CodeGenHLSL/builtins/min.hlsl
===
--- /dev/null
+++ clang/test/CodeGenHLSL/builtins/min.hlsl
@@ -0,0 +1,77 @@
+// RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -fnative-half-type \
+// RUN:   -emit-llvm -disable-llvm-passes -O3 -o - | FileCheck %s
+// RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -emit-llvm -disable-llvm-passes \
+// RUN:   -D__HLSL_ENABLE_16_BIT -o - | FileCheck %s --check-prefix=NO_HALF
+
+// CHECK: define noundef half @
+// CHECK: call half @llvm.minnum.f16(
+// NO_HALF: define noundef float @"?test_min_half@@YA$halff@$halff@0@Z"(
+// NO_HALF: call float @llvm.minnum.f32(
+half test_min_half ( half p0, half p1 ) {
+  return min ( p0, p1 );
+}
+// CHECK: define noundef <2 x half> @
+// CHECK: call <2 x half> @llvm.minnum.v2f16
+// NO_HALF: define noundef <2 x float> @"?test_min_float2@@YAT?$__vector@M$01@__clang@@T12@0@Z"(
+// NO_HALF: call <2 x float> @llvm.minnum.v2f32(
+half2 test_min_half2 ( half2 p0, half2 p1 ) {
+  return min ( p0, p1 );
+}
+// CHECK: define noundef <3 x half> @
+// CHECK: call <3 x half> @llvm.minnum.v3f16
+// NO_HALF: define noundef <3 x float> @"?test_min_float3@@YAT?$__vector@M$02@__clang@@T12@0@Z"(
+// NO_HALF: call <3 x float> @llvm.minnum.v3f32(
+half3 test_min_half3 ( half3 p0, half3 p1 ) {
+  return min ( p0, p1 );
+}
+// CHECK: define noundef <4 x half> @
+// CHECK: call <4 x half> @llvm.minnum.v4f16
+// NO_HALF: define noundef <4 x float> @"?test_min_float4@@YAT?$__vector@M$03@__clang@@T12@0@Z"(
+// NO_HALF: call <4 x float> @llvm.minnum.v4f32(
+half4 test_min_half4 ( half4 p0, half4 p1 ) {
+  return min ( p0, p1 );
+}
+
+// CHECK: define noundef float @
+// CHECK: call float @llvm.minnum.f32(
+float test_min_float ( float p0, float p1 ) {
+  return min ( p0, p1 );
+}
+// CHECK: define noundef <2 x float> @
+// CHECK: call <2 x float> @llvm.minnum.v2f32
+float2 test_min_float2 ( float2 p0, float2 p1 ) {
+  return min ( p0, p1 );
+}
+// CHECK: define noundef <3 x float> @
+// CHECK: call <3 x float> @llvm.minnum.v3f32
+float3 test_min_float3 ( float3 p0, float3 p1 ) {
+  return min ( p0, p1 );
+}
+// CHECK: define noundef <4 x float> @
+// CHECK: call <4 x float> @llvm.minnum.v4f32
+float4 test_min_float4 ( float4 p0, float4 p1) {
+  return min ( p0, p1 );
+}
+
+// CHECK: define noundef i32 @
+// CHECK: call i32 @llvm.smin.i32(
+int test_min_int ( int p0, int p1 ) {
+  return min ( p0, p1 );
+}
+// CHECK: define noundef <2 x i32> @
+// CHECK: call <2 x i32> @llvm.smin.v2i32
+int2 test_min_int2 ( int2 p0, int2 p1 ) {
+  return min ( p0, p1 );
+}
+// CHECK: define noundef <3 x i32> @
+// CHECK: call <3 x i32> @llvm.smin.v3i32
+int3 test_min_int3 ( int3 p0, int3 p1 ) {
+  return min ( p0, p1 );
+}
+// CHECK: define noundef <4 x i32> @
+// CHECK: call <4 x i32> @llvm.smin.v4i32
+int4 test_min_int4 ( int4 p0, int4 p1) {
+  return min ( p0, p1 );
+}
Index: clang/test/CodeGenHLSL/builtins/max.hlsl
===
--- /dev/null
+++ clang/test/CodeGenHLSL/builtins/max.hlsl
@@ -0,0 +1,77 @@
+// RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -fnative-half-type \
+// RUN:   -emit-llvm -disable-llvm-passes -O3 -o - | FileCheck %s
+// RUN: %clang_cc1 -std=hlsl2021 -finclude-default-header -x hlsl -triple \
+// RUN:   dxil-pc-shadermodel6.3-library %s -emit-llvm -disable-llvm-passes \
+// RUN:   -D__HLSL_ENABLE_16_BIT -o - | FileCheck %s --check-prefix=NO_HALF
+
+// CHECK: define noundef half @
+// CHECK: call half @llvm.maxnum.f16(
+// NO_HALF: define noundef float @"?test_max_half@@YA$halff@$halff@0@Z"(
+// NO_HALF: call float @llvm.maxnum.f32(
+half test_max_half ( half p0, half p1 ) {
+  return max ( p0, p1 );
+}
+// CHECK: define noundef <2 x half> @
+// CHECK: call <2 x half> @llvm.maxnum.v2f16
+// NO_HALF: define noundef <2 x float> @"?test_max_float2@@YAT?$__vector@M$01@__clang@@T12@0@Z"(
+// NO_HALF: call <2 x float> @llvm.maxnum.v2f32(
+half2 test_max_half2 ( half2 p0, half2 p1 ) {
+  return max ( p0, p1 );
+}
+// CHECK: define noundef <3 x half> @
+// CHECK: call <3 x half> @llvm.maxnum.v3f16
+// NO_HALF: define noundef <3 x float> @"?test_max_float3@@YAT?$__vector@M$02@__clang@@T12@0@Z"(
+// NO_HALF: call <3 x float> @llvm.maxnum.v3f32(
+half3 test_max_half3 ( half3 p0, half3 p1 ) {
+  return max ( p0, p1 );
+}
+// CHECK: define noundef <4 

[PATCH] D129700: [clang] Don't emit type tests for dllexport/import classes

2023-02-27 Thread Arthur Eubanks via Phabricator via cfe-commits
aeubanks added a comment.

ping


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D129700

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


[PATCH] D144889: [C2x] Support in freestanding

2023-02-27 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

> perhaps because they did char buf[256] = {0} though

Right, we need memcpy and memset to emit reasonable code for struct/array 
initialization and assignment.

We don't provide any library that includes memcpy/memset/memmove because of a 
combination of legacy, and that writing well-optimized versions is hard.  
Ideally, it probably makes sense.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144889

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


[PATCH] D144672: [Sanitizers] Error when attempting to use `static-lsan` with `TSan` or `Asan` on darwin

2023-02-27 Thread Dave MacLachlan via Phabricator via cfe-commits
dmaclach added a comment.

Updated with buildable patch.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144672

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


[PATCH] D144926: darwin platforms do not support static-lsan with TSan or ASan but were "silently failing" in that they would just ignore the flag and link in the dynamic runtimes instead.

2023-02-27 Thread Dave MacLachlan via Phabricator via cfe-commits
dmaclach abandoned this revision.
dmaclach added a comment.

Accidentally uploaded


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144926

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


[PATCH] D144672: [Sanitizers] Error when attempting to use `static-lsan` with `TSan` or `Asan` on darwin

2023-02-27 Thread Dave MacLachlan via Phabricator via cfe-commits
dmaclach updated this revision to Diff 500942.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144672

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/test/Driver/sanitizer-ld.c

Index: clang/test/Driver/sanitizer-ld.c
===
--- clang/test/Driver/sanitizer-ld.c
+++ clang/test/Driver/sanitizer-ld.c
@@ -457,6 +457,18 @@
 // RUN:   | FileCheck --check-prefix=CHECK-UBSAN-STATIC-DARWIN %s
 // CHECK-UBSAN-STATIC-DARWIN: {{.*}}error: static UndefinedBehaviorSanitizer runtime is not supported on darwin
 
+// RUN: %clang -fsanitize=address -### %s 2>&1 \
+// RUN: --target=x86_64-apple-darwin -fuse-ld=ld -static-libsan \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-ASAN-STATIC-DARWIN %s
+// CHECK-ASAN-STATIC-DARWIN: {{.*}}error: static AddressSanitizer runtime is not supported on darwin
+
+// RUN: %clang -fsanitize=thread -### %s 2>&1 \
+// RUN: --target=x86_64-apple-darwin -fuse-ld=ld -static-libsan \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-TSAN-STATIC-DARWIN %s
+// CHECK-TSAN-STATIC-DARWIN: {{.*}}error: static ThreadSanitizer runtime is not supported on darwin
+
 // RUN: %clang -fsanitize=address,undefined -### %s 2>&1 \
 // RUN: --target=i386-unknown-linux -fuse-ld=ld \
 // RUN: -resource-dir=%S/Inputs/resource_dir \
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -1426,24 +1426,42 @@
 
   const SanitizerArgs  = getSanitizerArgs(Args);
 
-  if (!Sanitize.needsSharedRt() && Sanitize.needsUbsanRt()) {
-getDriver().Diag(diag::err_drv_unsupported_static_ubsan_darwin);
-return;
+  if (!Sanitize.needsSharedRt()) {
+const char *sanitizer = nullptr;
+if (Sanitize.needsUbsanRt()) {
+  sanitizer = "UndefinedBehaviorSanitizer";
+} else if (Sanitize.needsAsanRt()) {
+  sanitizer = "AddressSanitizer";
+} else if (Sanitize.needsTsanRt()) {
+  sanitizer = "ThreadSanitizer";
+}
+if (sanitizer) {
+  getDriver().Diag(diag::err_drv_unsupported_static_sanitizer_darwin)
+  << sanitizer;
+  return;
+}
   }
 
   if (Sanitize.linkRuntimes()) {
-if (Sanitize.needsAsanRt())
+if (Sanitize.needsAsanRt()) {
+  assert(Sanitize.needsSharedRt() &&
+ "Static sanitizer runtimes not supported");
   AddLinkSanitizerLibArgs(Args, CmdArgs, "asan");
+}
 if (Sanitize.needsLsanRt())
   AddLinkSanitizerLibArgs(Args, CmdArgs, "lsan");
 if (Sanitize.needsUbsanRt()) {
-  assert(Sanitize.needsSharedRt() && "Static sanitizer runtimes not supported");
-  AddLinkSanitizerLibArgs(Args, CmdArgs,
-  Sanitize.requiresMinimalRuntime() ? "ubsan_minimal"
-: "ubsan");
+  assert(Sanitize.needsSharedRt() &&
+ "Static sanitizer runtimes not supported");
+  AddLinkSanitizerLibArgs(
+  Args, CmdArgs,
+  Sanitize.requiresMinimalRuntime() ? "ubsan_minimal" : "ubsan");
 }
-if (Sanitize.needsTsanRt())
+if (Sanitize.needsTsanRt()) {
+  assert(Sanitize.needsSharedRt() &&
+ "Static sanitizer runtimes not supported");
   AddLinkSanitizerLibArgs(Args, CmdArgs, "tsan");
+}
 if (Sanitize.needsFuzzer() && !Args.hasArg(options::OPT_dynamiclib)) {
   AddLinkSanitizerLibArgs(Args, CmdArgs, "fuzzer", /*shared=*/false);
 
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1215,7 +1215,7 @@
 def shared_libsan : Flag<["-"], "shared-libsan">,
   HelpText<"Dynamically link the sanitizer runtime">;
 def static_libsan : Flag<["-"], "static-libsan">,
-  HelpText<"Statically link the sanitizer runtime">;
+  HelpText<"Statically link the sanitizer runtime (Not supported for ASan, TSan or UBSan on darwin)">;
 def : Flag<["-"], "shared-libasan">, Alias;
 def fasm : Flag<["-"], "fasm">, Group;
 
Index: clang/include/clang/Basic/DiagnosticDriverKinds.td
===
--- clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -220,8 +220,8 @@
   "malformed sanitizer coverage ignorelist: '%0'">;
 def err_drv_malformed_sanitizer_metadata_ignorelist : Error<
   "malformed sanitizer metadata ignorelist: '%0'">;
-def err_drv_unsupported_static_ubsan_darwin : Error<
-  "static 

[PATCH] D144926: darwin platforms do not support static-lsan with TSan or ASan but were "silently failing" in that they would just ignore the flag and link in the dynamic runtimes instead.

2023-02-27 Thread Dave MacLachlan via Phabricator via cfe-commits
dmaclach created this revision.
Herald added a project: All.
dmaclach requested review of this revision.
Herald added subscribers: cfe-commits, MaskRay.
Herald added a project: clang.

This matches the pre-existing UBSan failure path.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D144926

Files:
  clang/include/clang/Basic/DiagnosticDriverKinds.td
  clang/include/clang/Driver/Options.td
  clang/lib/Driver/ToolChains/Darwin.cpp
  clang/test/Driver/sanitizer-ld.c

Index: clang/test/Driver/sanitizer-ld.c
===
--- clang/test/Driver/sanitizer-ld.c
+++ clang/test/Driver/sanitizer-ld.c
@@ -457,6 +457,18 @@
 // RUN:   | FileCheck --check-prefix=CHECK-UBSAN-STATIC-DARWIN %s
 // CHECK-UBSAN-STATIC-DARWIN: {{.*}}error: static UndefinedBehaviorSanitizer runtime is not supported on darwin
 
+// RUN: %clang -fsanitize=address -### %s 2>&1 \
+// RUN: --target=x86_64-apple-darwin -fuse-ld=ld -static-libsan \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-ASAN-STATIC-DARWIN %s
+// CHECK-ASAN-STATIC-DARWIN: {{.*}}error: static AddressSanitizer runtime is not supported on darwin
+
+// RUN: %clang -fsanitize=thread -### %s 2>&1 \
+// RUN: --target=x86_64-apple-darwin -fuse-ld=ld -static-libsan \
+// RUN: --sysroot=%S/Inputs/basic_linux_tree \
+// RUN:   | FileCheck --check-prefix=CHECK-TSAN-STATIC-DARWIN %s
+// CHECK-TSAN-STATIC-DARWIN: {{.*}}error: static ThreadSanitizer runtime is not supported on darwin
+
 // RUN: %clang -fsanitize=address,undefined -### %s 2>&1 \
 // RUN: --target=i386-unknown-linux -fuse-ld=ld \
 // RUN: -resource-dir=%S/Inputs/resource_dir \
Index: clang/lib/Driver/ToolChains/Darwin.cpp
===
--- clang/lib/Driver/ToolChains/Darwin.cpp
+++ clang/lib/Driver/ToolChains/Darwin.cpp
@@ -1426,24 +1426,42 @@
 
   const SanitizerArgs  = getSanitizerArgs(Args);
 
-  if (!Sanitize.needsSharedRt() && Sanitize.needsUbsanRt()) {
-getDriver().Diag(diag::err_drv_unsupported_static_ubsan_darwin);
-return;
+  if (!Sanitize.needsSharedRt()) {
+const char *sanitizer = nullptr;
+if (Sanitize.needsUbsanRt()) {
+  sanitizer = "UndefinedBehaviorSanitizer";
+} else if (Sanitize.needsAsanRt()) {
+  sanitizer = "AddressSanitizer";
+} else if (Sanitize.needsTsanRt()) {
+  sanitizer = "ThreadSanitizer";
+}
+if (sanitizer) {
+  getDriver().Diag(diag::err_drv_unsupported_static_sanitizer_darwin)
+  << sanitizer;
+  return;
+}
   }
 
   if (Sanitize.linkRuntimes()) {
-if (Sanitize.needsAsanRt())
+if (Sanitize.needsAsanRt()) {
+  assert(Sanitize.needsSharedRt() &&
+ "Static sanitizer runtimes not supported");
   AddLinkSanitizerLibArgs(Args, CmdArgs, "asan");
+}
 if (Sanitize.needsLsanRt())
   AddLinkSanitizerLibArgs(Args, CmdArgs, "lsan");
 if (Sanitize.needsUbsanRt()) {
-  assert(Sanitize.needsSharedRt() && "Static sanitizer runtimes not supported");
-  AddLinkSanitizerLibArgs(Args, CmdArgs,
-  Sanitize.requiresMinimalRuntime() ? "ubsan_minimal"
-: "ubsan");
+  assert(Sanitize.needsSharedRt() &&
+ "Static sanitizer runtimes not supported");
+  AddLinkSanitizerLibArgs(
+  Args, CmdArgs,
+  Sanitize.requiresMinimalRuntime() ? "ubsan_minimal" : "ubsan");
 }
-if (Sanitize.needsTsanRt())
+if (Sanitize.needsTsanRt()) {
+  assert(Sanitize.needsSharedRt() &&
+ "Static sanitizer runtimes not supported");
   AddLinkSanitizerLibArgs(Args, CmdArgs, "tsan");
+}
 if (Sanitize.needsFuzzer() && !Args.hasArg(options::OPT_dynamiclib)) {
   AddLinkSanitizerLibArgs(Args, CmdArgs, "fuzzer", /*shared=*/false);
 
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -1215,7 +1215,7 @@
 def shared_libsan : Flag<["-"], "shared-libsan">,
   HelpText<"Dynamically link the sanitizer runtime">;
 def static_libsan : Flag<["-"], "static-libsan">,
-  HelpText<"Statically link the sanitizer runtime">;
+  HelpText<"Statically link the sanitizer runtime (Not supported for ASan, TSan or UBSan on darwin)">;
 def : Flag<["-"], "shared-libasan">, Alias;
 def fasm : Flag<["-"], "fasm">, Group;
 
Index: clang/include/clang/Basic/DiagnosticDriverKinds.td
===
--- clang/include/clang/Basic/DiagnosticDriverKinds.td
+++ clang/include/clang/Basic/DiagnosticDriverKinds.td
@@ -220,8 +220,8 @@
   "malformed sanitizer coverage ignorelist: '%0'">;
 def err_drv_malformed_sanitizer_metadata_ignorelist : Error<
   "malformed sanitizer metadata ignorelist: '%0'">;
-def 

[PATCH] D143877: [NFC] [clang] Forward forwarding reference

2023-02-27 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

In D143877#4156769 , @dblaikie wrote:

>> Although we may not agree such ideas, we should offer an option for the 
>> users to give them the right to choose.
>
> I think @iains was bemoaning the large number of module flags recently - 
> perhaps he'd have some thoughts on this, but mine are that we should be more 
> prescriptive - figure out what a good solution is for most users and 
> implement that, rather than giving people lots of knobs to tune.
>
> For this issue - honestly I think it might be a better/safer default to not 
> import external module definitions at all/ever. Leave it to LTO to do that 
> kind of cross-module optimization, as we have in the past/non-modular builds.
>
> At least until/unless we implement something more like what the bug describes 
> - doing IR level optimizations first and importing the optimized IR, rather 
> than reoptimizing these external definitions in every user.

Huh, this ended up on quite the wrong review... fascinating.

Sorry about that. Disregard. I'll follow up with on-topic review feedback here 
shortly.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143877

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


[PATCH] D144912: [clang-tidy] readability-identifier-naming: fix hungarian enum prefix in C

2023-02-27 Thread Piotr Zegar via Phabricator via cfe-commits
PiotrZSL added inline comments.



Comment at: clang-tools-extra/docs/ReleaseNotes.rst:181-187
+- Changed hungarian prefixes for enums in C files to match C++ files (ie.
+  always use the enum type letters, for example `rt` prefix for enum tags of
+  `enum REV_TYPE`) in :doc:`readability-identifier-naming
+  ` check.
+  If you need `i` as the prefix for enum tags (to keep the previous behavior),
+  set `EnumConstantPrefix` to `i` instead of enabling
+  `EnumConstantHungarianPrefix`.

consider making it shorter (fit in 4/5 lines)...

maybe:
```
Updated the Hungarian prefixes for enums in C files to match those used in C++ 
files for improved readability, as checked by 
:doc:`readability-identifier-naming
`. To preserve the previous
behavior of using `i` as the prefix for enum tags, set the EnumConstantPrefix 
option to `i` instead of using EnumConstantHungarianPrefix.
```




Comment at: 
clang-tools-extra/test/clang-tidy/checkers/readability/identifier-naming-hungarian-notation-c-language.c:4
+// clang-format off
+typedef signed char int8_t; // NOLINT
+typedef short   int16_t;// NOLINT

those typedefs looks to be duplicated already in 
identifier-naming-hungarian-notation.cpp and 
identifier-naming-hungarian-notation-cfgfile.cpp, move them to separate header 
file


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144912

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


[PATCH] D143877: [NFC] [clang] Forward forwarding reference

2023-02-27 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a subscriber: iains.
dblaikie added a comment.

> Although we may not agree such ideas, we should offer an option for the users 
> to give them the right to choose.

I think @iains was bemoaning the large number of module flags recently - 
perhaps he'd have some thoughts on this, but mine are that we should be more 
prescriptive - figure out what a good solution is for most users and implement 
that, rather than giving people lots of knobs to tune.

For this issue - honestly I think it might be a better/safer default to not 
import external module definitions at all/ever. Leave it to LTO to do that kind 
of cross-module optimization, as we have in the past/non-modular builds.

At least until/unless we implement something more like what the bug describes - 
doing IR level optimizations first and importing the optimized IR, rather than 
reoptimizing these external definitions in every user.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143877

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


[PATCH] D144864: [Flang][Driver][MLIR] Add -fopenmp-is-device to Flang and link to an omp.is_device attribute

2023-02-27 Thread Johannes Doerfert via Phabricator via cfe-commits
jdoerfert added a comment.

Tests?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144864

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


[PATCH] D144870: [Clang][DebugInfo] Emit zero size bitfields in the debug info to delimit bitfields in different allocation units.

2023-02-27 Thread David Blaikie via Phabricator via cfe-commits
dblaikie added a comment.

Haven't followed the patch in detail - but why does this require changes to the 
RecordLayout code? (I'd expect this to only require charnges to the debug info 
code - maybe with a shared helper utility function that both the AMDGPU ABI 
implementation, and the debug info can use to observe this property, if it's 
non-trivial code to duplicate in both places? (but doesn't look like it's 
sharing code with the ABI implementation, or moving the logic out of the ABI 
implementation into the record layout code for reuse there))


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144870

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


[PATCH] D144285: [Clang] Implement CWG2518 - static_assert(false)

2023-02-27 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 500928.
cor3ntin added a comment.

Remove the #error / #warning tests


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144285

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/CXX/drs/dr25xx.cpp
  clang/test/SemaCXX/access-base-class.cpp
  clang/test/SemaCXX/coroutines-exp-namespace.cpp
  clang/test/SemaCXX/coroutines.cpp
  clang/test/SemaCXX/static-assert.cpp
  clang/test/SemaTemplate/instantiate-var-template.cpp
  clang/test/SemaTemplate/instantiation-dependence.cpp
  clang/www/cxx_dr_status.html

Index: clang/www/cxx_dr_status.html
===
--- clang/www/cxx_dr_status.html
+++ clang/www/cxx_dr_status.html
@@ -14915,7 +14915,7 @@
 https://wg21.link/cwg2518;>2518
 review
 Conformance requirements and #error/#warning
-Not resolved
+Clang 17
   
   
 https://wg21.link/cwg2519;>2519
Index: clang/test/SemaTemplate/instantiation-dependence.cpp
===
--- clang/test/SemaTemplate/instantiation-dependence.cpp
+++ clang/test/SemaTemplate/instantiation-dependence.cpp
@@ -37,8 +37,8 @@
   template using indirect_void_t = typename indirect_void_t_imp::type;
 
   template void foo() {
-static_assert(!__is_void(indirect_void_t)); // "ok", dependent
-static_assert(!__is_void(void_t)); // expected-error {{failed}}
+int check1[__is_void(indirect_void_t) == 0 ? 1 : -1]; // "ok", dependent
+int check2[__is_void(void_t) == 0 ? 1 : -1]; // expected-error {{array with a negative size}}
   }
 }
 
Index: clang/test/SemaTemplate/instantiate-var-template.cpp
===
--- clang/test/SemaTemplate/instantiate-var-template.cpp
+++ clang/test/SemaTemplate/instantiate-var-template.cpp
@@ -31,9 +31,9 @@
   static_assert(b == 1, ""); // expected-note {{in instantiation of}}
 
   template void f() {
-static_assert(a == 0, ""); // expected-error {{static assertion failed due to requirement 'a == 0'}} \
-   // expected-note {{evaluates to '1 == 0'}}
+int check[a == 0 ? 1 : -1]; // expected-error {{array with a negative size}}
   }
+
 }
 
 namespace PR24483 {
Index: clang/test/SemaCXX/static-assert.cpp
===
--- clang/test/SemaCXX/static-assert.cpp
+++ clang/test/SemaCXX/static-assert.cpp
@@ -52,9 +52,11 @@
 
 template struct AlwaysFails {
   // Only give one error here.
-  static_assert(false, ""); // expected-error {{static assertion failed}}
+  static_assert(false, ""); // expected-error 2{{static assertion failed}}
 };
-AlwaysFails alwaysFails;
+AlwaysFails alwaysFails; // expected-note {{instantiation}}
+AlwaysFails alwaysFails2; // expected-note {{instantiation}}
+
 
 template struct StaticAssertProtected {
   static_assert(__is_literal(T), ""); // expected-error {{static assertion failed}}
@@ -217,6 +219,23 @@
 
 static_assert(1 , "") // expected-error {{expected ';' after 'static_assert'}}
 
+namespace DependentAlwaysFalse {
+template 
+struct S {
+  static_assert(false); // expected-error{{static assertion failed}} \
+// expected-warning {{C++17 extension}}
+};
+
+template 
+struct T {
+  static_assert(false, "test"); // expected-error{{static assertion failed: test}}
+};
+
+int f() {
+  S s; //expected-note {{in instantiation of template class 'DependentAlwaysFalse::S' requested here}}
+  T t; //expected-note {{in instantiation of template class 'DependentAlwaysFalse::T' requested here}}
+}
+}
 
 namespace Diagnostics {
   /// No notes for literals.
Index: clang/test/SemaCXX/coroutines.cpp
===
--- clang/test/SemaCXX/coroutines.cpp
+++ clang/test/SemaCXX/coroutines.cpp
@@ -1309,7 +1309,7 @@
   }
 };
 
-template struct DepTestType; // expected-note {{requested here}}
+template struct DepTestType; // expected-note 2{{requested here}}
 template CoroMemberTag DepTestType::test_member_template(long, const char *) const &&;
 
 template CoroMemberTag DepTestType::test_static_template(const char *volatile &, unsigned);
Index: clang/test/SemaCXX/coroutines-exp-namespace.cpp
===
--- clang/test/SemaCXX/coroutines-exp-namespace.cpp
+++ clang/test/SemaCXX/coroutines-exp-namespace.cpp
@@ -1288,7 +1288,7 @@
   }
 };
 
-template struct DepTestType; // expected-note {{requested here}}
+template struct DepTestType; // expected-note 2{{requested here}}
 template CoroMemberTag DepTestType::test_member_template(long, const char *) const &&;
 
 template CoroMemberTag DepTestType::test_static_template(const char *volatile &, unsigned);
Index: clang/test/SemaCXX/access-base-class.cpp

Re: [clang] 6ed67cc - [Coroutines] Remove -fcoroutines-ts

2023-02-27 Thread Bruno Cardoso Lopes via cfe-commits
> I understand that the name "coroutines-ts" isn't meaningful these
> days, but it also sounds like this commit does more than remove the
> flag, it caps useful functionality. How are users supposed to use
> c++17 with coroutines now? It's very common in our codebase and we
> have users relying on it.

Looks like I misread your patch, sorry! If my understanding now is
right, `-std=c++17 -fcoroutines` should work, right? We should
probably add an extra test in `clang/test/Driver/coroutines.cpp` that
just test that (we currently just test when it's not).

Cheers,

-- 
Bruno Cardoso Lopes
http://www.brunocardoso.cc
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D144285: [Clang] Implement CWG2518 - static_assert(false)

2023-02-27 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/test/CXX/drs/dr25xx.cpp:5-14
+#error one
+// expected-error@-1 {{one}}
+#if 0
+#error skip
+#warning skip // expected-error {{skip}}
+#endif
+#error two

cor3ntin wrote:
> aaron.ballman wrote:
> > What do these tests have to do with this DR?
> This dr is wild 
> https://wiki.edg.com/pub/Wg21issaquah2023/StrawPolls/p2796r0.html
> CWG merged the static_assert PR in the DR asserting that error should produce 
> a diagnostics - note that there will probably be some follow ups
> https://lists.isocpp.org/core/2023/02/13915.php
> 
> Here I'm testing a warning is emitted even if the build was already failed.
Ah, yeah, CWG2700 is sort of included in here.

I wonder if we should back out the `#error`/`#warning` tests and handle that 
explicitly as part of CWG2700 as that's going to supersede the changes from 
CWG2518.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144285

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


[PATCH] D144889: [C2x] Support in freestanding

2023-02-27 Thread Ben Craig via Phabricator via cfe-commits
bcraig added a comment.

> 1. A normal operating system target with a "hosted" libc.
> 2. A baremetal target with an "embedded" libc; basically a stripped down libc 
> which only includes stuff that doesn't require an operating system.  What 
> exactly this includes varies; may include some form of "malloc", some "POSIX" 
> APIs, semihosting, etc.
> 3. A baremetal target with no libc, using custom implementations for 
> everything.  This is what we conventionally referred to as "freestanding", 
> and what -ffreestanding implements.  The user provides memcpy/memmove/memset, 
> and uses the compiler-provided "builtins" lib if neceessary, but nothing we 
> would traditionally call "libc".

In my committee work, I'm targeting option 2.  I think that's what should be 
considered when talking about freestanding in a standards context.

Option 3 is valuable and should continue to exist, but it is non-conforming 
pre-C23 and post-C23.  The standards don't have any provision for requiring the 
user to implement mem* functions that the implementation chooses to invoke 
without the user ever spelling that function call (perhaps because they did 
`char buf[256] = {0}` though).  Post-C23, it doesn't provide enough.  The C 
library authors will likely need this mode to author the C library itself 
though.  I'll suggest calling this mode something like "nodefaultlibs".


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144889

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


[PATCH] D144914: [Clang][Driver] Add -mcpu=help to clang

2023-02-27 Thread Philip Reames via Phabricator via cfe-commits
reames accepted this revision.
reames 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/D144914/new/

https://reviews.llvm.org/D144914

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


[PATCH] D144914: [Clang][Driver] Add -mcpu=help to clang

2023-02-27 Thread Michael Maitland via Phabricator via cfe-commits
michaelmaitland added a comment.

In D144914#4156567 , @reames wrote:

> Code and description appear out of sync.  (help != list)  Personally, I like 
> the help naming a lot better.

Thanks for catching this. I meant to write `help` instead of `list`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144914

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


[PATCH] D144914: [Clang][Driver] Add -mcpu=help to clang

2023-02-27 Thread Michael Maitland via Phabricator via cfe-commits
michaelmaitland updated this revision to Diff 500907.
michaelmaitland added a comment.

Change `list` -> `help`.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144914

Files:
  clang/docs/CommandGuide/clang.rst
  clang/include/clang/Driver/Options.td
  clang/test/Driver/print-supported-cpus.c


Index: clang/test/Driver/print-supported-cpus.c
===
--- clang/test/Driver/print-supported-cpus.c
+++ clang/test/Driver/print-supported-cpus.c
@@ -13,6 +13,13 @@
 // RUN: %clang --target=x86_64-unknown-linux-gnu -mtune=? -fuse-ld=dummy 2>&1 
| \
 // RUN:   FileCheck %s --check-prefix=CHECK-X86
 
+// Test -mcpu=help and -mtune=help alises.
+// RUN: %clang --target=x86_64-unknown-linux-gnu -mcpu=help 2>&1 | \
+// RUN:   FileCheck %s --check-prefix=CHECK-X86
+
+// RUN: %clang --target=x86_64-unknown-linux-gnu -mtune=help -fuse-ld=dummy 
2>&1 | \
+// RUN:   FileCheck %s --check-prefix=CHECK-X86
+
 // CHECK-NOT: warning: argument unused during compilation
 // CHECK-X86: Target: x86_64-unknown-linux-gnu
 // CHECK-X86: corei7
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -4347,6 +4347,8 @@
   MarshallingInfoFlag>;
 def mcpu_EQ_QUESTION : Flag<["-"], "mcpu=?">, Alias;
 def mtune_EQ_QUESTION : Flag<["-"], "mtune=?">, Alias;
+def mcpu_EQ_help : Flag<["-"], "mcpu=help">, Alias;
+def mtune_EQ_help : Flag<["-"], "mtune=help">, Alias;
 def time : Flag<["-"], "time">,
   HelpText<"Time individual commands">;
 def traditional_cpp : Flag<["-", "--"], "traditional-cpp">, Flags<[CC1Option]>,
Index: clang/docs/CommandGuide/clang.rst
===
--- clang/docs/CommandGuide/clang.rst
+++ clang/docs/CommandGuide/clang.rst
@@ -373,6 +373,10 @@
 
   Acts as an alias for :option:`--print-supported-cpus`.
 
+.. option:: -mcpu=help, -mtune=help
+
+  Acts as an alias for :option:`--print-supported-cpus`.
+
 .. option:: -march=
 
   Specify that Clang should generate code for a specific processor family


Index: clang/test/Driver/print-supported-cpus.c
===
--- clang/test/Driver/print-supported-cpus.c
+++ clang/test/Driver/print-supported-cpus.c
@@ -13,6 +13,13 @@
 // RUN: %clang --target=x86_64-unknown-linux-gnu -mtune=? -fuse-ld=dummy 2>&1 | \
 // RUN:   FileCheck %s --check-prefix=CHECK-X86
 
+// Test -mcpu=help and -mtune=help alises.
+// RUN: %clang --target=x86_64-unknown-linux-gnu -mcpu=help 2>&1 | \
+// RUN:   FileCheck %s --check-prefix=CHECK-X86
+
+// RUN: %clang --target=x86_64-unknown-linux-gnu -mtune=help -fuse-ld=dummy 2>&1 | \
+// RUN:   FileCheck %s --check-prefix=CHECK-X86
+
 // CHECK-NOT: warning: argument unused during compilation
 // CHECK-X86: Target: x86_64-unknown-linux-gnu
 // CHECK-X86: corei7
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -4347,6 +4347,8 @@
   MarshallingInfoFlag>;
 def mcpu_EQ_QUESTION : Flag<["-"], "mcpu=?">, Alias;
 def mtune_EQ_QUESTION : Flag<["-"], "mtune=?">, Alias;
+def mcpu_EQ_help : Flag<["-"], "mcpu=help">, Alias;
+def mtune_EQ_help : Flag<["-"], "mtune=help">, Alias;
 def time : Flag<["-"], "time">,
   HelpText<"Time individual commands">;
 def traditional_cpp : Flag<["-", "--"], "traditional-cpp">, Flags<[CC1Option]>,
Index: clang/docs/CommandGuide/clang.rst
===
--- clang/docs/CommandGuide/clang.rst
+++ clang/docs/CommandGuide/clang.rst
@@ -373,6 +373,10 @@
 
   Acts as an alias for :option:`--print-supported-cpus`.
 
+.. option:: -mcpu=help, -mtune=help
+
+  Acts as an alias for :option:`--print-supported-cpus`.
+
 .. option:: -march=
 
   Specify that Clang should generate code for a specific processor family
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D144912: [clang-tidy] readability-identifier-naming: fix hungarian enum prefix in C

2023-02-27 Thread Alexis Murzeau via Phabricator via cfe-commits
amurzeau updated this revision to Diff 500905.
amurzeau added a comment.

Update the release notes too, to notify of this changes with C files.

Suggest the user to use `EnumConstantPrefix` instead of
`EnumConstantHungarianPrefix` to keep the previous behavior of using `i` for
all enum tags.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144912

Files:
  clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp
  clang-tools-extra/docs/ReleaseNotes.rst
  
clang-tools-extra/test/clang-tidy/checkers/readability/identifier-naming-hungarian-notation-c-language.c

Index: clang-tools-extra/test/clang-tidy/checkers/readability/identifier-naming-hungarian-notation-c-language.c
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/readability/identifier-naming-hungarian-notation-c-language.c
@@ -0,0 +1,586 @@
+// RUN: %check_clang_tidy %s readability-identifier-naming %t -- --config-file=%S/Inputs/identifier-naming/hungarian-notation1/.clang-tidy
+
+// clang-format off
+typedef signed char int8_t; // NOLINT
+typedef short   int16_t;// NOLINT
+typedef longint32_t;// NOLINT
+typedef long long   int64_t;// NOLINT
+typedef unsigned char   uint8_t;// NOLINT
+typedef unsigned short  uint16_t;   // NOLINT
+typedef unsigned long   uint32_t;   // NOLINT
+typedef unsigned long long  uint64_t;   // NOLINT
+#ifndef _WIN32
+typedef unsigned long long  size_t; // NOLINT
+#endif
+typedef longintptr_t;   // NOLINT
+typedef unsigned long   uintptr_t;  // NOLINT
+typedef long intptrdiff_t;  // NOLINT
+typedef unsigned char   BYTE;   // NOLINT
+typedef unsigned short  WORD;   // NOLINT
+typedef unsigned long   DWORD;  // NOLINT
+typedef int BOOL;   // NOLINT
+typedef int BOOLEAN;// NOLINT
+typedef float   FLOAT;  // NOLINT
+typedef int INT;// NOLINT
+typedef unsigned intUINT;   // NOLINT
+typedef unsigned long   ULONG;  // NOLINT
+typedef short   SHORT;  // NOLINT
+typedef unsigned short  USHORT; // NOLINT
+typedef charCHAR;   // NOLINT
+typedef unsigned char   UCHAR;  // NOLINT
+typedef signed char INT8;   // NOLINT
+typedef signed shortINT16;  // NOLINT
+typedef signed int  INT32;  // NOLINT
+typedef signed long longINT64;  // NOLINT
+typedef unsigned char   UINT8;  // NOLINT
+typedef unsigned short  UINT16; // NOLINT
+typedef unsigned intUINT32; // NOLINT
+typedef unsigned long long  UINT64; // NOLINT
+typedef longLONG;   // NOLINT
+typedef signed int  LONG32; // NOLINT
+typedef unsigned intULONG32;// NOLINT
+typedef uint64_tULONG64;// NOLINT
+typedef unsigned intDWORD32;// NOLINT
+typedef uint64_tDWORD64;// NOLINT
+typedef uint64_tULONGLONG;  // NOLINT
+typedef void*   PVOID;  // NOLINT
+typedef void*   HANDLE; // NOLINT
+typedef void*   FILE;   // NOLINT
+typedef _Bool   bool;   // NOLINT
+typedef __WCHAR_TYPE__  wchar_t;// NOLINT
+#define true1   // NOLINT
+#define false   0   // NOLINT
+#define NULL(0) // NOLINT
+// clang-format on
+
+// clang-format off
+//===--===//
+// Cases to CheckOptions
+//===--===//
+const int GlobalConstantCase = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:11: warning: invalid case style for global constant 'GlobalConstantCase' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}const int iGlobalConstantCase = 0;
+
+const int* GlobalConstantPointerCase = NULL;
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: invalid case style for global pointer 'GlobalConstantPointerCase' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}const int* piGlobalConstantPointerCase = NULL;
+
+int* GlobalPointerCase = NULL;
+// CHECK-MESSAGES: :[[@LINE-1]]:6: warning: invalid case style for global pointer 'GlobalPointerCase' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}int* piGlobalPointerCase = NULL;
+
+int GlobalVariableCase = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:5: warning: invalid case style for global variable 'GlobalVariableCase' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}int iGlobalVariableCase = 0;
+
+void Func1(){
+  int const LocalConstantCase = 3;
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: invalid case style for local constant 'LocalConstantCase' [readability-identifier-naming]
+  // CHECK-FIXES: 

[PATCH] D144864: [Flang][Driver][MLIR] Add -fopenmp-is-device to Flang and link to an omp.is_device attribute

2023-02-27 Thread Kiran Chandramohan via Phabricator via cfe-commits
kiranchandramohan added a comment.

Could you update the discourse thread 
(https://discourse.llvm.org/t/rfc-omp-module-and-omp-function-vs-dialect-attributes-to-encode-openmp-properties/67998)
 with the chosen approach and reasons before proceeding?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144864

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


[PATCH] D144914: [Clang][Driver] Add -mcpu=help to clang

2023-02-27 Thread Philip Reames via Phabricator via cfe-commits
reames added a comment.

Code and description appear out of sync.  (help != list)  Personally, I like 
the help naming a lot better.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144914

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


[PATCH] D144914: [Clang][Driver] Add -mcpu=help to clang

2023-02-27 Thread Michael Maitland via Phabricator via cfe-commits
michaelmaitland created this revision.
michaelmaitland added reviewers: craig.topper, reames.
Herald added a project: All.
michaelmaitland requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

Clang currently uses `-mcpu=?`. The `?` causes errors on some shells such as zsh
since it is a special character. In order for it to work on shells such as zsh,
the option must be passed in quotes or escaped. This patch adds `-mcpu=help` as
another alias for `--print-supported-cpus`. In llc, `-mcpu=help` an alias to
print supported cpus.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D144914

Files:
  clang/docs/CommandGuide/clang.rst
  clang/include/clang/Driver/Options.td
  clang/test/Driver/print-supported-cpus.c


Index: clang/test/Driver/print-supported-cpus.c
===
--- clang/test/Driver/print-supported-cpus.c
+++ clang/test/Driver/print-supported-cpus.c
@@ -13,6 +13,13 @@
 // RUN: %clang --target=x86_64-unknown-linux-gnu -mtune=? -fuse-ld=dummy 2>&1 
| \
 // RUN:   FileCheck %s --check-prefix=CHECK-X86
 
+// Test -mcpu=list and -mtune=list alises.
+// RUN: %clang --target=x86_64-unknown-linux-gnu -mcpu=list 2>&1 | \
+// RUN:   FileCheck %s --check-prefix=CHECK-X86
+
+// RUN: %clang --target=x86_64-unknown-linux-gnu -mtune=list -fuse-ld=dummy 
2>&1 | \
+// RUN:   FileCheck %s --check-prefix=CHECK-X86
+
 // CHECK-NOT: warning: argument unused during compilation
 // CHECK-X86: Target: x86_64-unknown-linux-gnu
 // CHECK-X86: corei7
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -4347,6 +4347,8 @@
   MarshallingInfoFlag>;
 def mcpu_EQ_QUESTION : Flag<["-"], "mcpu=?">, Alias;
 def mtune_EQ_QUESTION : Flag<["-"], "mtune=?">, Alias;
+def mcpu_EQ_list : Flag<["-"], "mcpu=list">, Alias;
+def mtune_EQ_list : Flag<["-"], "mtune=list">, Alias;
 def time : Flag<["-"], "time">,
   HelpText<"Time individual commands">;
 def traditional_cpp : Flag<["-", "--"], "traditional-cpp">, Flags<[CC1Option]>,
Index: clang/docs/CommandGuide/clang.rst
===
--- clang/docs/CommandGuide/clang.rst
+++ clang/docs/CommandGuide/clang.rst
@@ -373,6 +373,10 @@
 
   Acts as an alias for :option:`--print-supported-cpus`.
 
+.. option:: -mcpu=list, -mtune=list
+
+  Acts as an alias for :option:`--print-supported-cpus`.
+
 .. option:: -march=
 
   Specify that Clang should generate code for a specific processor family


Index: clang/test/Driver/print-supported-cpus.c
===
--- clang/test/Driver/print-supported-cpus.c
+++ clang/test/Driver/print-supported-cpus.c
@@ -13,6 +13,13 @@
 // RUN: %clang --target=x86_64-unknown-linux-gnu -mtune=? -fuse-ld=dummy 2>&1 | \
 // RUN:   FileCheck %s --check-prefix=CHECK-X86
 
+// Test -mcpu=list and -mtune=list alises.
+// RUN: %clang --target=x86_64-unknown-linux-gnu -mcpu=list 2>&1 | \
+// RUN:   FileCheck %s --check-prefix=CHECK-X86
+
+// RUN: %clang --target=x86_64-unknown-linux-gnu -mtune=list -fuse-ld=dummy 2>&1 | \
+// RUN:   FileCheck %s --check-prefix=CHECK-X86
+
 // CHECK-NOT: warning: argument unused during compilation
 // CHECK-X86: Target: x86_64-unknown-linux-gnu
 // CHECK-X86: corei7
Index: clang/include/clang/Driver/Options.td
===
--- clang/include/clang/Driver/Options.td
+++ clang/include/clang/Driver/Options.td
@@ -4347,6 +4347,8 @@
   MarshallingInfoFlag>;
 def mcpu_EQ_QUESTION : Flag<["-"], "mcpu=?">, Alias;
 def mtune_EQ_QUESTION : Flag<["-"], "mtune=?">, Alias;
+def mcpu_EQ_list : Flag<["-"], "mcpu=list">, Alias;
+def mtune_EQ_list : Flag<["-"], "mtune=list">, Alias;
 def time : Flag<["-"], "time">,
   HelpText<"Time individual commands">;
 def traditional_cpp : Flag<["-", "--"], "traditional-cpp">, Flags<[CC1Option]>,
Index: clang/docs/CommandGuide/clang.rst
===
--- clang/docs/CommandGuide/clang.rst
+++ clang/docs/CommandGuide/clang.rst
@@ -373,6 +373,10 @@
 
   Acts as an alias for :option:`--print-supported-cpus`.
 
+.. option:: -mcpu=list, -mtune=list
+
+  Acts as an alias for :option:`--print-supported-cpus`.
+
 .. option:: -march=
 
   Specify that Clang should generate code for a specific processor family
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D144889: [C2x] Support in freestanding

2023-02-27 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

In D144889#4156120 , @bcraig wrote:

> A freestanding implementation doesn't necessarily mean that everything is 
> header-only.  It's fine to require linking against a (freestanding) C runtime 
> library.  All header-only is fine too though, if you want to make that work.
>
> Architecturally, I don't feel it is required that Clang be the location of 
> all the freestanding headers for C.  I think that's fine for the C library in 
> the final toolchain to own those headers.  I'm not super familiar with what 
> interface contracts you have between the clang-provided C headers and the 
> C-library provided C headers though.

In practice, there are basically three ways people can use clang:

1. A normal operating system target with a "hosted" libc.
2. A baremetal target with an "embedded" libc; basically a stripped down libc 
which only includes stuff that doesn't require an operating system.  What 
exactly this includes varies; may include some form of "malloc", some "POSIX" 
APIs, semihosting, etc.
3. A baremetal target with no libc, using custom implementations for 
everything.  This is what we conventionally referred to as "freestanding", and 
what -ffreestanding implements.  The user provides memcpy/memmove/memset, and 
uses the compiler-provided "builtins" lib if neceessary, but nothing we would 
traditionally call "libc".

We could just refuse to provide any APIs outside of our conventional notion of 
"freestanding", I guess, and say users that want a C23 freestanding environment 
need to find their own mini-libc. Or just provide the header, and say users are 
responsible for providing implementations, like they currently are for memcpy 
etc.  That doesn't really align with what the committee was hoping for, 
though...

Maybe eventually we can come up with some way to use implementations provided 
by LLVM libc, but I'm not sure what exactly that looks like.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144889

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


[PATCH] D144912: [clang-tidy] readability-identifier-naming: fix hungarian enum prefix in C

2023-02-27 Thread Alexis Murzeau via Phabricator via cfe-commits
amurzeau created this revision.
amurzeau added reviewers: njames93, alexfh, kazu, dougpuob, aaron.ballman, 
carlosgalvezp.
Herald added a subscriber: xazax.hun.
Herald added a project: All.
amurzeau requested review of this revision.
Herald added a project: clang-tools-extra.
Herald added a subscriber: cfe-commits.

When checking a C file, enum tags are of type `int` instead of the enum
type as in C++.
So the checker was using `i` as the prefix for enum tags instead of main
letters of the enum type name (for example `rt` for `enum REV_TYPE`).

This commit fixes this divergence and makes the behavior the same between
C and C++ files.

For example, `enum REV_TYPE { rtRevValid };` won't be reported as badly
named when in a C file. Previously, it would have proposed a rename to
`iRevValid`.

This commit also add a file to test the hungarian notation checker with C
files.
The test file was made from identifier-naming-hungarian-notation.cpp
with C++-only features removed.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D144912

Files:
  clang-tools-extra/clang-tidy/readability/IdentifierNamingCheck.cpp
  
clang-tools-extra/test/clang-tidy/checkers/readability/identifier-naming-hungarian-notation-c-language.c

Index: clang-tools-extra/test/clang-tidy/checkers/readability/identifier-naming-hungarian-notation-c-language.c
===
--- /dev/null
+++ clang-tools-extra/test/clang-tidy/checkers/readability/identifier-naming-hungarian-notation-c-language.c
@@ -0,0 +1,586 @@
+// RUN: %check_clang_tidy %s readability-identifier-naming %t -- --config-file=%S/Inputs/identifier-naming/hungarian-notation1/.clang-tidy
+
+// clang-format off
+typedef signed char int8_t; // NOLINT
+typedef short   int16_t;// NOLINT
+typedef longint32_t;// NOLINT
+typedef long long   int64_t;// NOLINT
+typedef unsigned char   uint8_t;// NOLINT
+typedef unsigned short  uint16_t;   // NOLINT
+typedef unsigned long   uint32_t;   // NOLINT
+typedef unsigned long long  uint64_t;   // NOLINT
+#ifndef _WIN32
+typedef unsigned long long  size_t; // NOLINT
+#endif
+typedef longintptr_t;   // NOLINT
+typedef unsigned long   uintptr_t;  // NOLINT
+typedef long intptrdiff_t;  // NOLINT
+typedef unsigned char   BYTE;   // NOLINT
+typedef unsigned short  WORD;   // NOLINT
+typedef unsigned long   DWORD;  // NOLINT
+typedef int BOOL;   // NOLINT
+typedef int BOOLEAN;// NOLINT
+typedef float   FLOAT;  // NOLINT
+typedef int INT;// NOLINT
+typedef unsigned intUINT;   // NOLINT
+typedef unsigned long   ULONG;  // NOLINT
+typedef short   SHORT;  // NOLINT
+typedef unsigned short  USHORT; // NOLINT
+typedef charCHAR;   // NOLINT
+typedef unsigned char   UCHAR;  // NOLINT
+typedef signed char INT8;   // NOLINT
+typedef signed shortINT16;  // NOLINT
+typedef signed int  INT32;  // NOLINT
+typedef signed long longINT64;  // NOLINT
+typedef unsigned char   UINT8;  // NOLINT
+typedef unsigned short  UINT16; // NOLINT
+typedef unsigned intUINT32; // NOLINT
+typedef unsigned long long  UINT64; // NOLINT
+typedef longLONG;   // NOLINT
+typedef signed int  LONG32; // NOLINT
+typedef unsigned intULONG32;// NOLINT
+typedef uint64_tULONG64;// NOLINT
+typedef unsigned intDWORD32;// NOLINT
+typedef uint64_tDWORD64;// NOLINT
+typedef uint64_tULONGLONG;  // NOLINT
+typedef void*   PVOID;  // NOLINT
+typedef void*   HANDLE; // NOLINT
+typedef void*   FILE;   // NOLINT
+typedef _Bool   bool;   // NOLINT
+typedef __WCHAR_TYPE__  wchar_t;// NOLINT
+#define true1   // NOLINT
+#define false   0   // NOLINT
+#define NULL(0) // NOLINT
+// clang-format on
+
+// clang-format off
+//===--===//
+// Cases to CheckOptions
+//===--===//
+const int GlobalConstantCase = 0;
+// CHECK-MESSAGES: :[[@LINE-1]]:11: warning: invalid case style for global constant 'GlobalConstantCase' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}const int iGlobalConstantCase = 0;
+
+const int* GlobalConstantPointerCase = NULL;
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: invalid case style for global pointer 'GlobalConstantPointerCase' [readability-identifier-naming]
+// CHECK-FIXES: {{^}}const int* piGlobalConstantPointerCase = NULL;
+
+int* GlobalPointerCase = NULL;
+// CHECK-MESSAGES: :[[@LINE-1]]:6: 

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

2023-02-27 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

This seems to cause precommit CI failures that should be addressed, and it 
should also have a release note about the fix.

Also, should this cover things like `clang -U__cplusplus -D__STDC__=1 foo.cpp` 
as well?


Repository:
  rG LLVM Github Monorepo

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] D144889: [C2x] Support in freestanding

2023-02-27 Thread Ben Craig via Phabricator via cfe-commits
bcraig added a comment.

> Okay, so this is potentially ignorance on my part. I was under the impression 
> that folks using freestanding mode did not want any library to be linked in. 
> Are there freestanding libc implementations out there that the user would 
> link in instead that we defer to (same as we defer hosted C standard library 
> interfaces to the CRT)? Basically, do we need to do nothing in Clang to 
> support N2524?

Oh, and I forgot GPUs.  GPUs do like having everything be header-only, but in 
my opinion, that's still a requirement / request for C library authors rather 
than the compiler.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144889

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


[PATCH] D144889: [C2x] Support in freestanding

2023-02-27 Thread Ben Craig via Phabricator via cfe-commits
bcraig added a comment.

> Okay, so this is potentially ignorance on my part. I was under the impression 
> that folks using freestanding mode did not want any library to be linked in. 
> Are there freestanding libc implementations out there that the user would 
> link in instead that we defer to (same as we defer hosted C standard library 
> interfaces to the CRT)? Basically, do we need to do nothing in Clang to 
> support N2524?

Well, people want all sorts of things :)

(Gross generalizations coming) The compiler writer view of freestanding that 
I've heard in the past is that the compiler writer views freestanding as the 
necessary parts of the library needed to support the language.  This is mostly 
accurate when describing freestanding prior to C++23 and C23.  Most of that is 
either header-only, in libc++abi, or in compiler-rt.  This makes testing the 
compiler a bit easier, as you don't need a full stdlib.  That's not a design 
goal of freestanding post C/C++23 though.  It's fine for Clang to provide half 
of a stdlib for internal testing or integration with other C libraries, so long 
as the final toolchain has everything.

One challenge for some customers will be that they like to build with 
`-nodefaultlibs`, but that's not a deal breaker here, it just means that they 
would need to manually put their C library on the link line.  Alternatively, 
they could start passing other linker flags, like `-nostartfiles` instead, but 
that will be use case dependent.  These kinds of hoops have historically been 
needed because a customer may use a "stock" ARM Clang, but not want to use the 
libc that came with that toolchain, so the big linker flags would come out to 
give the user control.

I don't think that Clang-the-compiler needs to do anything to support the new 
C/C++ freestanding features.  The main caveat being that you still need to be 
able to ensure the provided memcpy gets used instead of a codegenned (possibly 
vectorized) memcpy, but I think -ffreestanding already forces the compiler to 
generate calls and not use in-compiler codegen.

> FWIW, WG14 is having a second round of CD ballot comments. If you'd like, I'm 
> happy to file a comment asking to remove strtok from the required set for 
> freestanding conformance.

That would be much appreciated.  I can try to get my INCITS / ISO status 
squared away so that I can represent that issue at the appropriate meeting.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144889

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


[PATCH] D140760: [clang-tidy] Support begin/end free functions in modernize-loop-convert

2023-02-27 Thread Piotr Zegar via Phabricator via cfe-commits
PiotrZSL added a comment.

consider adding testcase like this:

  for (auto I = Obj.begin(5), E = obj.end(5); I != E; ++I) {
...
  }


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140760

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


[PATCH] D144309: [HLSL] add max/min library functions

2023-02-27 Thread Xiang Li via Phabricator via cfe-commits
python3kgae added a comment.

max/min does work on integers in HLSL.
And __builtin_elementwise_max/min support both integers and floats.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144309

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


[PATCH] D127259: [CodeGen] guarantee templated static variables are initialized in the reverse instantiation order

2023-02-27 Thread Erich Keane via Phabricator via cfe-commits
erichkeane accepted this revision.
erichkeane added a comment.

I don't see much compile-time concerns myself, and this seems to fix a pretty 
serious regression, I think this is acceptable once Aaron and the author think 
so as well.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D127259

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


[PATCH] D144884: [clang-format] Only add pragma continuation indentation for 'omp' clauses

2023-02-27 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 updated this revision to Diff 500872.
jhuber6 added a comment.

Add test for case in https://github.com/llvm/llvm-project/issues/59473


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144884

Files:
  clang/lib/Format/ContinuationIndenter.cpp
  clang/unittests/Format/FormatTest.cpp


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -20560,6 +20560,21 @@
 "(including parentheses).",
 format("#pragmamark   Any non-hyphenated or hyphenated string "
"(including parentheses)."));
+
+  EXPECT_EQ("#pragma mark Any non-hyphenated or hyphenated string "
+"(including parentheses).",
+format("#pragmamark   Any non-hyphenated or hyphenated string "
+   "(including parentheses)."));
+
+  EXPECT_EQ(
+  "#pragma comment(linker,\\\n"
+  "\"argument\" \\\n"
+  "\"argument\"",
+  format("#pragma comment(linker,  \\\n"
+ " \"argument\" \\\n"
+ " \"argument\"",
+ getStyleWithColumns(
+ getChromiumStyle(FormatStyle::LanguageKind::LK_Cpp), 32)));
 }
 
 TEST_F(FormatTest, UnderstandsPragmaOmpTarget) {
Index: clang/lib/Format/ContinuationIndenter.cpp
===
--- clang/lib/Format/ContinuationIndenter.cpp
+++ clang/lib/Format/ContinuationIndenter.cpp
@@ -1273,8 +1273,13 @@
 return ContinuationIndent;
   }
 
-  if (State.Line->InPragmaDirective)
-return CurrentState.Indent + Style.ContinuationIndentWidth;
+  // OpenMP clauses want to get additional indentation when they are pushed 
onto
+  // the next line.
+  if (State.Line->InPragmaDirective) {
+FormatToken *PragmaType = State.Line->First->Next->Next;
+if (PragmaType && PragmaType->TokenText.equals("omp"))
+  return CurrentState.Indent + Style.ContinuationIndentWidth;
+  }
 
   // This ensure that we correctly format ObjC methods calls without inputs,
   // i.e. where the last element isn't selector like: [callee method];


Index: clang/unittests/Format/FormatTest.cpp
===
--- clang/unittests/Format/FormatTest.cpp
+++ clang/unittests/Format/FormatTest.cpp
@@ -20560,6 +20560,21 @@
 "(including parentheses).",
 format("#pragmamark   Any non-hyphenated or hyphenated string "
"(including parentheses)."));
+
+  EXPECT_EQ("#pragma mark Any non-hyphenated or hyphenated string "
+"(including parentheses).",
+format("#pragmamark   Any non-hyphenated or hyphenated string "
+   "(including parentheses)."));
+
+  EXPECT_EQ(
+  "#pragma comment(linker,\\\n"
+  "\"argument\" \\\n"
+  "\"argument\"",
+  format("#pragma comment(linker,  \\\n"
+ " \"argument\" \\\n"
+ " \"argument\"",
+ getStyleWithColumns(
+ getChromiumStyle(FormatStyle::LanguageKind::LK_Cpp), 32)));
 }
 
 TEST_F(FormatTest, UnderstandsPragmaOmpTarget) {
Index: clang/lib/Format/ContinuationIndenter.cpp
===
--- clang/lib/Format/ContinuationIndenter.cpp
+++ clang/lib/Format/ContinuationIndenter.cpp
@@ -1273,8 +1273,13 @@
 return ContinuationIndent;
   }
 
-  if (State.Line->InPragmaDirective)
-return CurrentState.Indent + Style.ContinuationIndentWidth;
+  // OpenMP clauses want to get additional indentation when they are pushed onto
+  // the next line.
+  if (State.Line->InPragmaDirective) {
+FormatToken *PragmaType = State.Line->First->Next->Next;
+if (PragmaType && PragmaType->TokenText.equals("omp"))
+  return CurrentState.Indent + Style.ContinuationIndentWidth;
+  }
 
   // This ensure that we correctly format ObjC methods calls without inputs,
   // i.e. where the last element isn't selector like: [callee method];
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[PATCH] D141008: [Clang][SPIR-V] Emit target extension types for OpenCL types on SPIR-V.

2023-02-27 Thread Joshua Cranmer via Phabricator via cfe-commits
jcranmer-intel added a comment.

Friendly review ping?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D141008

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


[PATCH] D140760: [clang-tidy] Support begin/end free functions in modernize-loop-convert

2023-02-27 Thread Piotr Zegar via Phabricator via cfe-commits
PiotrZSL added inline comments.



Comment at: clang-tools-extra/clang-tidy/modernize/LoopConvertCheck.cpp:871
+return false;
+} else if (Nodes.getNodeAs(EndCallName)) {
+  return true;

ccotter wrote:
> PiotrZSL wrote:
> > ``else return Nodes.getNodeAs(EndCallName) != nullptr;``
> Is this in the style guide? NotNullTerminatedResultCheck.cpp, 
> SignedCharMisuseCheck.cpp, UnconventionalAssignOperatorCheck.cpp have 
> equivalent conditionals that do not check against `nullptr`.
its not about checking for nullptr, its about simplifying if else if else, you 
dont need to explicitly compare to nullptr, I'm just used to it.
You can easily depend on implicit bool conversion here, its fine.
Simply you got if something return true else return false, you can write just 
return something.



Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D140760

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


[PATCH] D144889: [C2x] Support in freestanding

2023-02-27 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added a comment.

In D144889#4156068 , @efriedma wrote:

> Historically, the required functions for a "freestanding" C implementation 
> were very restricted.  Freestanding headers didn't export library functions, 
> just constants and types.



> As a practical matter, we actually do need a few functions to support code 
> generation for C even if they don't include any standard library headers.  We 
> expect "freestanding" users to provide the three functions memcpy, memmove, 
> and memset.  Other misc. functions like large integer operations and floating 
> point are provided by compiler-rt.builtins (which is ABI-compatible with 
> libgcc).
>
> Note that we can't easily expand the API surface of compiler-rt.builtins; see 
> https://discourse.llvm.org/t/proposal-split-built-ins-from-the-rest-of-compiler-rt/67978
>  .

Oof.

>> was that the first one is lowered to a potential library call while the 
>> second one is is lowered to a backend implementation that performs the work
>
> The difference is really that the __builtin_* functions are recognized as 
> builtins even if the the user is using -fno-builtin/-ffreestanding.  It 
> doesn't mean we actually have dedicated codegen support.

Ah, that's good to know. Thanks!

>> We do not currently have builtins for memccpy, memset_explicit, or strtok
>
> I'm not sure it makes sense to provide a "freestanding" strtok; it requires 
> global state.

I'm happy to file a CD2 comment to this effect.

In D144889#4156120 , @bcraig wrote:

> A freestanding implementation doesn't necessarily mean that everything is 
> header-only.  It's fine to require linking against a (freestanding) C runtime 
> library.  All header-only is fine too though, if you want to make that work.
>
> Architecturally, I don't feel it is required that Clang be the location of 
> all the freestanding headers for C.  I think that's fine for the C library in 
> the final toolchain to own those headers.  I'm not super familiar with what 
> interface contracts you have between the clang-provided C headers and the 
> C-library provided C headers though.

Okay, so this is potentially ignorance on my part. I was under the impression 
that folks using freestanding mode did not want any library to be linked in. 
Are there freestanding libc implementations out there that the user would link 
in instead that we defer to (same as we defer hosted C standard library 
interfaces to the CRT)? Basically, do we need to do nothing in Clang to support 
N2524?

>> I'm not sure it makes sense to provide a "freestanding" strtok; it requires 
>> global state.
>
> I agree with this, but the C committee felt otherwise.  C++26 freestanding is 
> most likely including strtok too, to stay consistent with C (the freestanding 
> C library paper is through LWG and awaiting a C++26 plenary vote).  It 
> shouldn't be hard to implement in an OS-independent way, but it will be a low 
> quality implementation with cross-thread races.

FWIW, WG14 is having a second round of CD ballot comments. If you'd like, I'm 
happy to file a comment asking to remove `strtok` from the required set for 
freestanding conformance.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144889

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


[PATCH] D144218: [Clang] [AVR] Fix USHRT_MAX for 16-bit int.

2023-02-27 Thread Daniel Thornburgh 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 rG0fecac18ffad: [Clang] [AVR] Fix USHRT_MAX for 16-bit int. 
(authored by mysterymath).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144218

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Headers/limits.h
  clang/test/Headers/limits.cpp

Index: clang/test/Headers/limits.cpp
===
--- clang/test/Headers/limits.cpp
+++ clang/test/Headers/limits.cpp
@@ -3,14 +3,40 @@
 // RUN: %clang_cc1 -std=c++11 -ffreestanding -fsyntax-only -verify %s
 // RUN: %clang_cc1 -std=c17 -ffreestanding -fsyntax-only -verify -x c %s
 // RUN: %clang_cc1 -std=c2x -ffreestanding -fsyntax-only -verify -x c %s
+
+// Specifically test 16-bit int platforms.
+// RUN: %clang_cc1 -triple=avr -ffreestanding -fsyntax-only -verify -x c %s
+// RUN: %clang_cc1 -triple=avr -std=c++11 -ffreestanding -fsyntax-only -verify %s
+
 // expected-no-diagnostics
 
 #include 
 
+#if __cplusplus
+#define EXPR_TYPE_IS(EXPR, TYP) __is_same(__typeof(EXPR), TYP)
+#else
+#define EXPR_TYPE_IS(EXPR, TYP) _Generic(EXPR, TYP: 1, default: 0)
+#endif
+
 _Static_assert(SCHAR_MAX == -(SCHAR_MIN+1), "");
+_Static_assert(EXPR_TYPE_IS(SCHAR_MAX, int), "");
+#if SCHAR_MAX
+#endif
+
 _Static_assert(SHRT_MAX == -(SHRT_MIN+1), "");
+_Static_assert(EXPR_TYPE_IS(SHRT_MAX, int), "");
+#if SHRT_MAX
+#endif
+
 _Static_assert(INT_MAX == -(INT_MIN+1), "");
+_Static_assert(EXPR_TYPE_IS(INT_MAX, int), "");
+#if INT_MAX
+#endif
+
 _Static_assert(LONG_MAX == -(LONG_MIN+1L), "");
+_Static_assert(EXPR_TYPE_IS(LONG_MAX, long), "");
+#if LONG_MAX
+#endif
 
 _Static_assert(SCHAR_MAX == UCHAR_MAX/2, "");
 _Static_assert(SHRT_MAX == USHRT_MAX/2, "");
@@ -18,26 +44,84 @@
 _Static_assert(LONG_MAX == ULONG_MAX/2, "");
 
 _Static_assert(SCHAR_MIN == -SCHAR_MAX-1, "");
+_Static_assert(EXPR_TYPE_IS(SCHAR_MIN, int), "");
+#if SCHAR_MIN
+#endif
+
 _Static_assert(SHRT_MIN == -SHRT_MAX-1, "");
+_Static_assert(EXPR_TYPE_IS(SHRT_MIN, int), "");
+#if SHRT_MIN
+#endif
+
 _Static_assert(INT_MIN == -INT_MAX-1, "");
+_Static_assert(EXPR_TYPE_IS(INT_MIN, int), "");
+#if INT_MIN
+#endif
+
 _Static_assert(LONG_MIN == -LONG_MAX-1L, "");
+_Static_assert(EXPR_TYPE_IS(LONG_MIN, long), "");
+#if LONG_MIN
+#endif
 
 _Static_assert(UCHAR_MAX == (unsigned char)~0ULL, "");
+_Static_assert(UCHAR_MAX <= INT_MAX ?
+ EXPR_TYPE_IS(UCHAR_MAX, int) :
+ EXPR_TYPE_IS(UCHAR_MAX, unsigned int), "");
+#if UCHAR_MAX
+#endif
+
 _Static_assert(USHRT_MAX == (unsigned short)~0ULL, "");
+_Static_assert(USHRT_MAX <= INT_MAX ?
+ EXPR_TYPE_IS(USHRT_MAX, int) :
+ EXPR_TYPE_IS(USHRT_MAX, unsigned int), "");
+#if USHRT_MAX
+#endif
+
 _Static_assert(UINT_MAX == (unsigned int)~0ULL, "");
+_Static_assert(EXPR_TYPE_IS(UINT_MAX, unsigned int), "");
+#if UINT_MAX
+#endif
+
 _Static_assert(ULONG_MAX == (unsigned long)~0ULL, "");
+_Static_assert(EXPR_TYPE_IS(ULONG_MAX, unsigned long), "");
+#if ULONG_MAX
+#endif
 
 _Static_assert(MB_LEN_MAX >= 1, "");
+#if MB_LEN_MAX
+#endif
 
 _Static_assert(CHAR_BIT >= 8, "");
+#if CHAR_BIT
+#endif
 
 _Static_assert(CHAR_MIN == (((char)-1 < (char)0) ? -CHAR_MAX-1 : 0), "");
+_Static_assert(EXPR_TYPE_IS(CHAR_MIN, int), "");
+#if CHAR_MIN
+#endif
+
 _Static_assert(CHAR_MAX == (((char)-1 < (char)0) ? -(CHAR_MIN+1) : (char)~0ULL), "");
+_Static_assert(CHAR_MAX <= INT_MAX ?
+ EXPR_TYPE_IS(CHAR_MAX, int) :
+ EXPR_TYPE_IS(CHAR_MAX, unsigned int), "");
+#if CHAR_MAX
+#endif
 
 #if __STDC_VERSION__ >= 199901 || __cplusplus >= 201103L
 _Static_assert(LLONG_MAX == -(LLONG_MIN+1LL), "");
+_Static_assert(EXPR_TYPE_IS(LLONG_MAX, long long), "");
+#if LLONG_MAX
+#endif
+
 _Static_assert(LLONG_MIN == -LLONG_MAX-1LL, "");
+#if LLONG_MIN
+#endif
+_Static_assert(EXPR_TYPE_IS(LLONG_MIN, long long), "");
+
 _Static_assert(ULLONG_MAX == (unsigned long long)~0ULL, "");
+_Static_assert(EXPR_TYPE_IS(ULLONG_MAX, unsigned long long), "");
+#if ULLONG_MAX
+#endif
 #else
 int LLONG_MIN, LLONG_MAX, ULLONG_MAX; // Not defined.
 #endif
@@ -47,35 +131,61 @@
 #if __STDC_VERSION__ >= 202000L
 /* Validate the standard requirements. */
 _Static_assert(BOOL_WIDTH >= 1);
+#if BOOL_WIDTH
+#endif
 
 _Static_assert(CHAR_WIDTH == CHAR_BIT);
 _Static_assert(CHAR_WIDTH / CHAR_BIT == sizeof(char));
+#if CHAR_WIDTH
+#endif
 _Static_assert(SCHAR_WIDTH == CHAR_BIT);
 _Static_assert(SCHAR_WIDTH / CHAR_BIT == sizeof(signed char));
+#if SCHAR_WIDTH
+#endif
 _Static_assert(UCHAR_WIDTH == CHAR_BIT);
 _Static_assert(UCHAR_WIDTH / CHAR_BIT == sizeof(unsigned char));
+#if UCHAR_WIDTH
+#endif
 
 _Static_assert(USHRT_WIDTH >= 16);
 _Static_assert(USHRT_WIDTH / CHAR_BIT == sizeof(unsigned short));
+#if USHRT_WIDTH
+#endif
 _Static_assert(SHRT_WIDTH == USHRT_WIDTH);
 _Static_assert(SHRT_WIDTH 

[clang] 0fecac1 - [Clang] [AVR] Fix USHRT_MAX for 16-bit int.

2023-02-27 Thread Daniel Thornburgh via cfe-commits

Author: Daniel Thornburgh
Date: 2023-02-27T12:04:26-08:00
New Revision: 0fecac18ffad476b5a4682770f6d8b1f0f176b40

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

LOG: [Clang] [AVR] Fix USHRT_MAX for 16-bit int.

For AVR, the definition of USHRT_MAX overflows.

Reviewed By: aaron.ballman, #clang-language-wg

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

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/Headers/limits.h
clang/test/Headers/limits.cpp

Removed: 




diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index b4c64c4e6051..1cc9e4efac1f 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -237,6 +237,13 @@ AIX Support
 WebAssembly Support
 ^^^
 
+AVR Support
+^^^
+- The definition of ``USHRT_MAX`` in the freestanding  no longer
+  overflows on AVR (where ``sizeof(int) == sizeof(unsigned short)``).  The type
+  of ``USHRT_MAX`` is now ``unsigned int`` instead of ``int``, as required by
+  the C standard.
+
 DWARF Support in Clang
 --
 

diff  --git a/clang/lib/Headers/limits.h b/clang/lib/Headers/limits.h
index 32cc901b26be..354e031a9d7b 100644
--- a/clang/lib/Headers/limits.h
+++ b/clang/lib/Headers/limits.h
@@ -52,7 +52,11 @@
 #define LONG_MIN  (-__LONG_MAX__ -1L)
 
 #define UCHAR_MAX (__SCHAR_MAX__*2  +1)
-#define USHRT_MAX (__SHRT_MAX__ *2  +1)
+#if __SHRT_WIDTH__ < __INT_WIDTH__
+#define USHRT_MAX (__SHRT_MAX__ * 2 + 1)
+#else
+#define USHRT_MAX (__SHRT_MAX__ * 2U + 1U)
+#endif
 #define UINT_MAX  (__INT_MAX__  *2U +1U)
 #define ULONG_MAX (__LONG_MAX__ *2UL+1UL)
 

diff  --git a/clang/test/Headers/limits.cpp b/clang/test/Headers/limits.cpp
index 730a73982631..fbf6ed0f751c 100644
--- a/clang/test/Headers/limits.cpp
+++ b/clang/test/Headers/limits.cpp
@@ -3,14 +3,40 @@
 // RUN: %clang_cc1 -std=c++11 -ffreestanding -fsyntax-only -verify %s
 // RUN: %clang_cc1 -std=c17 -ffreestanding -fsyntax-only -verify -x c %s
 // RUN: %clang_cc1 -std=c2x -ffreestanding -fsyntax-only -verify -x c %s
+
+// Specifically test 16-bit int platforms.
+// RUN: %clang_cc1 -triple=avr -ffreestanding -fsyntax-only -verify -x c %s
+// RUN: %clang_cc1 -triple=avr -std=c++11 -ffreestanding -fsyntax-only -verify 
%s
+
 // expected-no-diagnostics
 
 #include 
 
+#if __cplusplus
+#define EXPR_TYPE_IS(EXPR, TYP) __is_same(__typeof(EXPR), TYP)
+#else
+#define EXPR_TYPE_IS(EXPR, TYP) _Generic(EXPR, TYP: 1, default: 0)
+#endif
+
 _Static_assert(SCHAR_MAX == -(SCHAR_MIN+1), "");
+_Static_assert(EXPR_TYPE_IS(SCHAR_MAX, int), "");
+#if SCHAR_MAX
+#endif
+
 _Static_assert(SHRT_MAX == -(SHRT_MIN+1), "");
+_Static_assert(EXPR_TYPE_IS(SHRT_MAX, int), "");
+#if SHRT_MAX
+#endif
+
 _Static_assert(INT_MAX == -(INT_MIN+1), "");
+_Static_assert(EXPR_TYPE_IS(INT_MAX, int), "");
+#if INT_MAX
+#endif
+
 _Static_assert(LONG_MAX == -(LONG_MIN+1L), "");
+_Static_assert(EXPR_TYPE_IS(LONG_MAX, long), "");
+#if LONG_MAX
+#endif
 
 _Static_assert(SCHAR_MAX == UCHAR_MAX/2, "");
 _Static_assert(SHRT_MAX == USHRT_MAX/2, "");
@@ -18,26 +44,84 @@ _Static_assert(INT_MAX == UINT_MAX/2, "");
 _Static_assert(LONG_MAX == ULONG_MAX/2, "");
 
 _Static_assert(SCHAR_MIN == -SCHAR_MAX-1, "");
+_Static_assert(EXPR_TYPE_IS(SCHAR_MIN, int), "");
+#if SCHAR_MIN
+#endif
+
 _Static_assert(SHRT_MIN == -SHRT_MAX-1, "");
+_Static_assert(EXPR_TYPE_IS(SHRT_MIN, int), "");
+#if SHRT_MIN
+#endif
+
 _Static_assert(INT_MIN == -INT_MAX-1, "");
+_Static_assert(EXPR_TYPE_IS(INT_MIN, int), "");
+#if INT_MIN
+#endif
+
 _Static_assert(LONG_MIN == -LONG_MAX-1L, "");
+_Static_assert(EXPR_TYPE_IS(LONG_MIN, long), "");
+#if LONG_MIN
+#endif
 
 _Static_assert(UCHAR_MAX == (unsigned char)~0ULL, "");
+_Static_assert(UCHAR_MAX <= INT_MAX ?
+ EXPR_TYPE_IS(UCHAR_MAX, int) :
+ EXPR_TYPE_IS(UCHAR_MAX, unsigned int), "");
+#if UCHAR_MAX
+#endif
+
 _Static_assert(USHRT_MAX == (unsigned short)~0ULL, "");
+_Static_assert(USHRT_MAX <= INT_MAX ?
+ EXPR_TYPE_IS(USHRT_MAX, int) :
+ EXPR_TYPE_IS(USHRT_MAX, unsigned int), "");
+#if USHRT_MAX
+#endif
+
 _Static_assert(UINT_MAX == (unsigned int)~0ULL, "");
+_Static_assert(EXPR_TYPE_IS(UINT_MAX, unsigned int), "");
+#if UINT_MAX
+#endif
+
 _Static_assert(ULONG_MAX == (unsigned long)~0ULL, "");
+_Static_assert(EXPR_TYPE_IS(ULONG_MAX, unsigned long), "");
+#if ULONG_MAX
+#endif
 
 _Static_assert(MB_LEN_MAX >= 1, "");
+#if MB_LEN_MAX
+#endif
 
 _Static_assert(CHAR_BIT >= 8, "");
+#if CHAR_BIT
+#endif
 
 _Static_assert(CHAR_MIN == (((char)-1 < (char)0) ? -CHAR_MAX-1 : 0), "");
+_Static_assert(EXPR_TYPE_IS(CHAR_MIN, int), "");
+#if CHAR_MIN
+#endif
+
 _Static_assert(CHAR_MAX == (((char)-1 < (char)0) ? -(CHAR_MIN+1) : 
(char)~0ULL), "");

[PATCH] D144291: [clang-format-diff] Correctly parse start-of-file diffs

2023-02-27 Thread Leonard Chan via Phabricator via cfe-commits
This revision was automatically updated to reflect the committed changes.
Closed by commit rG50563944ab96: [clang-format-diff] Correctly parse 
start-of-file diffs (authored by tamird, committed by leonardchan).

Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144291

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


Index: clang/tools/clang-format/clang-format-diff.py
===
--- clang/tools/clang-format/clang-format-diff.py
+++ clang/tools/clang-format/clang-format-diff.py
@@ -84,12 +84,19 @@
   if not re.match('^%s$' % args.iregex, filename, re.IGNORECASE):
 continue
 
-match = re.search(r'^@@.*\+(\d+)(,(\d+))?', line)
+match = re.search(r'^@@.*\+(\d+)(?:,(\d+))?', line)
 if match:
   start_line = int(match.group(1))
   line_count = 1
-  if match.group(3):
-line_count = int(match.group(3))
+  if match.group(2):
+line_count = int(match.group(2))
+# The input is something like
+#
+# @@ -1, +0,0 @@
+#
+# which means no lines were added.
+if line_count == 0:
+  continue
   # Also format lines range if line_count is 0 in case of deleting
   # surrounding statements.
   end_line = start_line


Index: clang/tools/clang-format/clang-format-diff.py
===
--- clang/tools/clang-format/clang-format-diff.py
+++ clang/tools/clang-format/clang-format-diff.py
@@ -84,12 +84,19 @@
   if not re.match('^%s$' % args.iregex, filename, re.IGNORECASE):
 continue
 
-match = re.search(r'^@@.*\+(\d+)(,(\d+))?', line)
+match = re.search(r'^@@.*\+(\d+)(?:,(\d+))?', line)
 if match:
   start_line = int(match.group(1))
   line_count = 1
-  if match.group(3):
-line_count = int(match.group(3))
+  if match.group(2):
+line_count = int(match.group(2))
+# The input is something like
+#
+# @@ -1, +0,0 @@
+#
+# which means no lines were added.
+if line_count == 0:
+  continue
   # Also format lines range if line_count is 0 in case of deleting
   # surrounding statements.
   end_line = start_line
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


[clang] 5056394 - [clang-format-diff] Correctly parse start-of-file diffs

2023-02-27 Thread Leonard Chan via cfe-commits

Author: Tamir Duberstein
Date: 2023-02-27T20:02:51Z
New Revision: 50563944ab962b58a1e00763ce16d8c712965c6d

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

LOG: [clang-format-diff] Correctly parse start-of-file diffs

Handle the case where the diff is a pure removal of lines. Before this
change start_line would end up as 0 which is rejected by clang-format.

Submitting on behalf of @tamird.

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

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 1f6ff0fe295f..1dcc8689d5fe 100755
--- a/clang/tools/clang-format/clang-format-
diff .py
+++ b/clang/tools/clang-format/clang-format-
diff .py
@@ -84,12 +84,19 @@ def main():
   if not re.match('^%s$' % args.iregex, filename, re.IGNORECASE):
 continue
 
-match = re.search(r'^@@.*\+(\d+)(,(\d+))?', line)
+match = re.search(r'^@@.*\+(\d+)(?:,(\d+))?', line)
 if match:
   start_line = int(match.group(1))
   line_count = 1
-  if match.group(3):
-line_count = int(match.group(3))
+  if match.group(2):
+line_count = int(match.group(2))
+# The input is something like
+#
+# @@ -1, +0,0 @@
+#
+# which means no lines were added.
+if line_count == 0:
+  continue
   # Also format lines range if line_count is 0 in case of deleting
   # surrounding statements.
   end_line = start_line



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


[PATCH] D144232: [PowerPC] Correctly use ELFv2 ABI on FreeBSD/powerpc64

2023-02-27 Thread Brad Smith via Phabricator via cfe-commits
brad added a comment.

In D144232#4155966 , @adalava wrote:

> I agree with D144321 , sorry for the late 
> reply.  @pkubaj and @brad , thanks for pushing it. I think D144232 
>  can be abandoned, right?

Correct.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144232

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


[PATCH] D144285: [Clang] Implement CWG2518 - static_assert(false)

2023-02-27 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin added inline comments.



Comment at: clang/test/CXX/drs/dr25xx.cpp:5-14
+#error one
+// expected-error@-1 {{one}}
+#if 0
+#error skip
+#warning skip // expected-error {{skip}}
+#endif
+#error two

aaron.ballman wrote:
> What do these tests have to do with this DR?
This dr is wild 
https://wiki.edg.com/pub/Wg21issaquah2023/StrawPolls/p2796r0.html
CWG merged the static_assert PR in the DR asserting that error should produce a 
diagnostics - note that there will probably be some follow ups
https://lists.isocpp.org/core/2023/02/13915.php

Here I'm testing a warning is emitted even if the build was already failed.



Comment at: clang/test/CXX/drs/dr25xx.cpp:9
+#error skip
+#warning skip // expected-error {{skip}}
+#endif

aaron.ballman wrote:
> Why do we expect an error on this line in a `#if 0` block??
Oups, we don't 


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144285

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


[PATCH] D141008: [Clang][SPIR-V] Emit target extension types for OpenCL types on SPIR-V.

2023-02-27 Thread Ilia Diachkov via Phabricator via cfe-commits
iliya-diyachkov added inline comments.



Comment at: clang/lib/CodeGen/CGOpenCLRuntime.cpp:100-112
+llvm::Type *CGOpenCLRuntime::getSamplerType(const Type *T) {
+  if (!SamplerTy) {
+if (llvm::Type *TransTy = CGM.getTargetCodeGenInfo().getOpenCLType(
+CGM, CGM.getContext().OCLSamplerTy.getTypePtr()))
+  SamplerTy = TransTy;
+else
+  SamplerTy = llvm::PointerType::get(

Perhaps use early exits like this, or even removing 'else' clause.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D141008

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


[PATCH] D144285: [Clang] Implement CWG2518 - static_assert(false)

2023-02-27 Thread Corentin Jabot via Phabricator via cfe-commits
cor3ntin updated this revision to Diff 500866.
cor3ntin marked an inline comment as done.
cor3ntin added a comment.

Address Aaron's comments


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144285

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Sema/SemaDeclCXX.cpp
  clang/test/CXX/drs/dr25xx.cpp
  clang/test/SemaCXX/access-base-class.cpp
  clang/test/SemaCXX/coroutines-exp-namespace.cpp
  clang/test/SemaCXX/coroutines.cpp
  clang/test/SemaCXX/static-assert.cpp
  clang/test/SemaTemplate/instantiate-var-template.cpp
  clang/test/SemaTemplate/instantiation-dependence.cpp
  clang/www/cxx_dr_status.html

Index: clang/www/cxx_dr_status.html
===
--- clang/www/cxx_dr_status.html
+++ clang/www/cxx_dr_status.html
@@ -14915,7 +14915,7 @@
 https://wg21.link/cwg2518;>2518
 review
 Conformance requirements and #error/#warning
-Not resolved
+Clang 17
   
   
 https://wg21.link/cwg2519;>2519
Index: clang/test/SemaTemplate/instantiation-dependence.cpp
===
--- clang/test/SemaTemplate/instantiation-dependence.cpp
+++ clang/test/SemaTemplate/instantiation-dependence.cpp
@@ -37,8 +37,8 @@
   template using indirect_void_t = typename indirect_void_t_imp::type;
 
   template void foo() {
-static_assert(!__is_void(indirect_void_t)); // "ok", dependent
-static_assert(!__is_void(void_t)); // expected-error {{failed}}
+int check1[__is_void(indirect_void_t) == 0 ? 1 : -1]; // "ok", dependent
+int check2[__is_void(void_t) == 0 ? 1 : -1]; // expected-error {{array with a negative size}}
   }
 }
 
Index: clang/test/SemaTemplate/instantiate-var-template.cpp
===
--- clang/test/SemaTemplate/instantiate-var-template.cpp
+++ clang/test/SemaTemplate/instantiate-var-template.cpp
@@ -31,9 +31,9 @@
   static_assert(b == 1, ""); // expected-note {{in instantiation of}}
 
   template void f() {
-static_assert(a == 0, ""); // expected-error {{static assertion failed due to requirement 'a == 0'}} \
-   // expected-note {{evaluates to '1 == 0'}}
+int check[a == 0 ? 1 : -1]; // expected-error {{array with a negative size}}
   }
+
 }
 
 namespace PR24483 {
Index: clang/test/SemaCXX/static-assert.cpp
===
--- clang/test/SemaCXX/static-assert.cpp
+++ clang/test/SemaCXX/static-assert.cpp
@@ -52,9 +52,11 @@
 
 template struct AlwaysFails {
   // Only give one error here.
-  static_assert(false, ""); // expected-error {{static assertion failed}}
+  static_assert(false, ""); // expected-error 2{{static assertion failed}}
 };
-AlwaysFails alwaysFails;
+AlwaysFails alwaysFails; // expected-note {{instantiation}}
+AlwaysFails alwaysFails2; // expected-note {{instantiation}}
+
 
 template struct StaticAssertProtected {
   static_assert(__is_literal(T), ""); // expected-error {{static assertion failed}}
@@ -217,6 +219,23 @@
 
 static_assert(1 , "") // expected-error {{expected ';' after 'static_assert'}}
 
+namespace DependentAlwaysFalse {
+template 
+struct S {
+  static_assert(false); // expected-error{{static assertion failed}} \
+// expected-warning {{C++17 extension}}
+};
+
+template 
+struct T {
+  static_assert(false, "test"); // expected-error{{static assertion failed: test}}
+};
+
+int f() {
+  S s; //expected-note {{in instantiation of template class 'DependentAlwaysFalse::S' requested here}}
+  T t; //expected-note {{in instantiation of template class 'DependentAlwaysFalse::T' requested here}}
+}
+}
 
 namespace Diagnostics {
   /// No notes for literals.
Index: clang/test/SemaCXX/coroutines.cpp
===
--- clang/test/SemaCXX/coroutines.cpp
+++ clang/test/SemaCXX/coroutines.cpp
@@ -1309,7 +1309,7 @@
   }
 };
 
-template struct DepTestType; // expected-note {{requested here}}
+template struct DepTestType; // expected-note 2{{requested here}}
 template CoroMemberTag DepTestType::test_member_template(long, const char *) const &&;
 
 template CoroMemberTag DepTestType::test_static_template(const char *volatile &, unsigned);
Index: clang/test/SemaCXX/coroutines-exp-namespace.cpp
===
--- clang/test/SemaCXX/coroutines-exp-namespace.cpp
+++ clang/test/SemaCXX/coroutines-exp-namespace.cpp
@@ -1288,7 +1288,7 @@
   }
 };
 
-template struct DepTestType; // expected-note {{requested here}}
+template struct DepTestType; // expected-note 2{{requested here}}
 template CoroMemberTag DepTestType::test_member_template(long, const char *) const &&;
 
 template CoroMemberTag DepTestType::test_static_template(const char *volatile &, unsigned);
Index: clang/test/SemaCXX/access-base-class.cpp

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

2023-02-27 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/include/clang-c/Index.h:319
+   */
+  size_t Size;
+  /**

vedgy wrote:
> The type is `size_t` instead of the agreed upon `unsigned`, because the 
> addition of `unsigned GlobalOptions` below means that `unsigned Size` no 
> longer reduces the overall struct's size.
SGTM, thanks for the explanation



Comment at: clang/include/clang-c/Index.h:353
+ */
+CINDEX_LINKAGE unsigned clang_getDefaultGlobalOptions();
+

Don't want this to be a K C interface in pre-C2x modes.



Comment at: clang/tools/c-index-test/c-index-test.c:79
+Opts.PreambleStoragePath = NULL;
+Opts.InvocationEmissionPath = 
getenv("CINDEXTEST_INVOCATION_EMISSION_PATH");
+

vedgy wrote:
> When a libclang user needs to override a single option in `CXIndexOptions`, 
> [s]he has to set every member of the struct explicitly. When new options are 
> added, each libclang user needs to update the code that sets the options 
> under `CINDEX_VERSION_MINOR` `#if`s. Accidentally omitting even one member 
> assignment risks undefined or wrong behavior. How about adding an `inline` 
> helper function `CXIndexOptions clang_getDefaultIndexOptions()`, which 
> assigns default values to all struct members? Libclang users can then call 
> this function to obtain the default configuration, then tweak only the 
> members they want to override.
> 
> If this suggestion is to be implemented, how to deal with 
> [[https://stackoverflow.com/questions/68004269/differences-of-the-inline-keyword-in-c-and-c|the
>  differences of the inline keyword in C and C++]]?
By default, `0` should give you the most reasonable default behavior for most 
of the existing options (and new options should follow the same pattern). 
Ideally, users should be able to do:
```
CXIndexOptions Opts;
memset(, 0, sizeof(Opts));
Opts.Size = sizeof(Opts);
Opts.Whatever = 12;
CXIndex Idx = clang_createIndexWithOptions();
```
Global options defaulting to 0 is fine (uses regular thread priorities), we 
don't think want to default to excluding declarations from PCH, and we want to 
use the default preamble and invocation emission paths (if any). The only 
option that nonzero as a default *might* make sense for is displaying 
diagnostics, but even that seems reasonable to expect the developer to manually 
enable.

So I don't know that we need a function to get us default indexing options as 
`0` should be a reasonable default for all of the options. As we add new 
options, we need to be careful to add them in backwards compatible ways where 
`0` means "do the most likely thing".

WDYT?



Comment at: clang/tools/c-index-test/c-index-test.c:2079
+  if (!Idx)
+return -1;
 

vedgy wrote:
> Not sure `-1` is the right value to return here. This return value becomes 
> the exit code of the `c-index-test` executable.
I think `-1` is fine -- the important thing is a nonzero return code so it's 
logged as an error rather than a valid result.



Comment at: clang/tools/libclang/CIndex.cpp:3691
 
+unsigned clang_getDefaultGlobalOptions() {
+  unsigned GlobalOptions = CXGlobalOpt_None;





Comment at: clang/tools/libclang/CIndex.cpp:3701-3702
+CXIndex clang_createIndexWithOptions(const CXIndexOptions *options) {
+  if (options->Size != sizeof(CXIndexOptions))
+return NULL;
+  CIndexer *CIdxr = clang_createIndex_Impl(options->ExcludeDeclarationsFromPCH,

I think we want this to be `>` and not `!=`, maybe.

If the sizes are equal, we're on the happy path.

If the options from the caller are smaller than the options we know about, that 
should be okay because we won't attempt read the options not provided and 
instead rely on the default behavior being reasonable.

If the options from the caller are larger than the options we know about, we 
have to assume the user set an option we can't handle, and thus failing the 
request is reasonable.

So the way I'm envisioning us reading the options is:
```
if (options->Size >= offsetof(CXIndexOptions, FieldWeCareAbout))
  do_something(options->FieldWeCareAbout);
```


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] D144884: [clang-format] Only add pragma continuation indentation for 'omp' clauses

2023-02-27 Thread Joseph Huber via Phabricator via cfe-commits
jhuber6 added inline comments.



Comment at: clang/lib/Format/ContinuationIndenter.cpp:1279
+  if (State.Line->InPragmaDirective) {
+FormatToken *PragmaType = State.Line->First->Next->Next;
+if (PragmaType && PragmaType->TokenText.equals("omp"))

HazardyKnusperkeks wrote:
> Do we know that the first `Next` is never null?
The line should only have `InPragmaDirective` if it found `pragma`, so it 
should look something like this if you go through the tokens. I checked the 
final `Next` because someone could do `#pragma`.
```
#
pragma
comment
```


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144884

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


[PATCH] D144884: [clang-format] Only add pragma continuation indentation for 'omp' clauses

2023-02-27 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks added inline comments.



Comment at: clang/lib/Format/ContinuationIndenter.cpp:1279
+  if (State.Line->InPragmaDirective) {
+FormatToken *PragmaType = State.Line->First->Next->Next;
+if (PragmaType && PragmaType->TokenText.equals("omp"))

Do we know that the first `Next` is never null?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144884

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


[PATCH] D144884: [clang-format] Only add pragma continuation indentation for 'omp' clauses

2023-02-27 Thread Björn Schäpers via Phabricator via cfe-commits
HazardyKnusperkeks added a comment.

In D144884#4155739 , @jhuber6 wrote:

> In D144884#4155730 , @jdoerfert 
> wrote:
>
>> I'm assuming they have tests?
>
> I could add a test for the comment case in the bug report.

Yes please.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144884

___
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

2023-02-27 Thread Manuel Brito via Phabricator via cfe-commits
ManuelJBrito created this revision.
ManuelJBrito added a reviewer: RKSimon.
Herald added subscribers: pengfei, hiraditya.
Herald added a project: All.
ManuelJBrito requested review of this revision.
Herald added projects: clang, LLVM.
Herald added subscribers: llvm-commits, cfe-commits.

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

For example in https://godbolt.org/z/7hacPe1KM extra vinsertf128 instructions 
are introduced.

This is necessary to lower `mm512_cast*128` intel intrinsics as no-op 
intrinsics.


Repository:
  rG LLVM Github Monorepo

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
===
--- clang/test/CodeGen/X86/avx-cast-builtins.c
+++ clang/test/CodeGen/X86/avx-cast-builtins.c
@@ -1,4 +1,4 @@
-// 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
+// RUN: %clang_cc1 %s -O3  -ffreestanding %s -triple=x86_64-unknown-unknown -target-feature +avx -target-feature +avx512f  -target-feature +avx512fp16 -S -o - | FileCheck %s
 
 
 #include 
@@ -38,10 +38,7 @@
 __m512h test_mm512_castph128_ph512(__m128h A) {
   // CHECK-LABEL: test_mm512_castph128_ph512
   // CHECK: # %bb.0:
-  // 

[PATCH] D144218: [Clang] [AVR] Fix USHRT_MAX for 16-bit int.

2023-02-27 Thread Daniel Thornburgh via Phabricator via cfe-commits
mysterymath added a comment.

Thanks for your help in getting this right!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144218

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


[PATCH] D144218: [Clang] [AVR] Fix USHRT_MAX for 16-bit int.

2023-02-27 Thread Daniel Thornburgh via Phabricator via cfe-commits
mysterymath updated this revision to Diff 500861.
mysterymath marked an inline comment as done.
mysterymath added a comment.

Add C++ version of test for AVR.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144218

Files:
  clang/docs/ReleaseNotes.rst
  clang/lib/Headers/limits.h
  clang/test/Headers/limits.cpp

Index: clang/test/Headers/limits.cpp
===
--- clang/test/Headers/limits.cpp
+++ clang/test/Headers/limits.cpp
@@ -3,14 +3,40 @@
 // RUN: %clang_cc1 -std=c++11 -ffreestanding -fsyntax-only -verify %s
 // RUN: %clang_cc1 -std=c17 -ffreestanding -fsyntax-only -verify -x c %s
 // RUN: %clang_cc1 -std=c2x -ffreestanding -fsyntax-only -verify -x c %s
+
+// Specifically test 16-bit int platforms.
+// RUN: %clang_cc1 -triple=avr -ffreestanding -fsyntax-only -verify -x c %s
+// RUN: %clang_cc1 -triple=avr -std=c++11 -ffreestanding -fsyntax-only -verify %s
+
 // expected-no-diagnostics
 
 #include 
 
+#if __cplusplus
+#define EXPR_TYPE_IS(EXPR, TYP) __is_same(__typeof(EXPR), TYP)
+#else
+#define EXPR_TYPE_IS(EXPR, TYP) _Generic(EXPR, TYP: 1, default: 0)
+#endif
+
 _Static_assert(SCHAR_MAX == -(SCHAR_MIN+1), "");
+_Static_assert(EXPR_TYPE_IS(SCHAR_MAX, int), "");
+#if SCHAR_MAX
+#endif
+
 _Static_assert(SHRT_MAX == -(SHRT_MIN+1), "");
+_Static_assert(EXPR_TYPE_IS(SHRT_MAX, int), "");
+#if SHRT_MAX
+#endif
+
 _Static_assert(INT_MAX == -(INT_MIN+1), "");
+_Static_assert(EXPR_TYPE_IS(INT_MAX, int), "");
+#if INT_MAX
+#endif
+
 _Static_assert(LONG_MAX == -(LONG_MIN+1L), "");
+_Static_assert(EXPR_TYPE_IS(LONG_MAX, long), "");
+#if LONG_MAX
+#endif
 
 _Static_assert(SCHAR_MAX == UCHAR_MAX/2, "");
 _Static_assert(SHRT_MAX == USHRT_MAX/2, "");
@@ -18,26 +44,84 @@
 _Static_assert(LONG_MAX == ULONG_MAX/2, "");
 
 _Static_assert(SCHAR_MIN == -SCHAR_MAX-1, "");
+_Static_assert(EXPR_TYPE_IS(SCHAR_MIN, int), "");
+#if SCHAR_MIN
+#endif
+
 _Static_assert(SHRT_MIN == -SHRT_MAX-1, "");
+_Static_assert(EXPR_TYPE_IS(SHRT_MIN, int), "");
+#if SHRT_MIN
+#endif
+
 _Static_assert(INT_MIN == -INT_MAX-1, "");
+_Static_assert(EXPR_TYPE_IS(INT_MIN, int), "");
+#if INT_MIN
+#endif
+
 _Static_assert(LONG_MIN == -LONG_MAX-1L, "");
+_Static_assert(EXPR_TYPE_IS(LONG_MIN, long), "");
+#if LONG_MIN
+#endif
 
 _Static_assert(UCHAR_MAX == (unsigned char)~0ULL, "");
+_Static_assert(UCHAR_MAX <= INT_MAX ?
+ EXPR_TYPE_IS(UCHAR_MAX, int) :
+ EXPR_TYPE_IS(UCHAR_MAX, unsigned int), "");
+#if UCHAR_MAX
+#endif
+
 _Static_assert(USHRT_MAX == (unsigned short)~0ULL, "");
+_Static_assert(USHRT_MAX <= INT_MAX ?
+ EXPR_TYPE_IS(USHRT_MAX, int) :
+ EXPR_TYPE_IS(USHRT_MAX, unsigned int), "");
+#if USHRT_MAX
+#endif
+
 _Static_assert(UINT_MAX == (unsigned int)~0ULL, "");
+_Static_assert(EXPR_TYPE_IS(UINT_MAX, unsigned int), "");
+#if UINT_MAX
+#endif
+
 _Static_assert(ULONG_MAX == (unsigned long)~0ULL, "");
+_Static_assert(EXPR_TYPE_IS(ULONG_MAX, unsigned long), "");
+#if ULONG_MAX
+#endif
 
 _Static_assert(MB_LEN_MAX >= 1, "");
+#if MB_LEN_MAX
+#endif
 
 _Static_assert(CHAR_BIT >= 8, "");
+#if CHAR_BIT
+#endif
 
 _Static_assert(CHAR_MIN == (((char)-1 < (char)0) ? -CHAR_MAX-1 : 0), "");
+_Static_assert(EXPR_TYPE_IS(CHAR_MIN, int), "");
+#if CHAR_MIN
+#endif
+
 _Static_assert(CHAR_MAX == (((char)-1 < (char)0) ? -(CHAR_MIN+1) : (char)~0ULL), "");
+_Static_assert(CHAR_MAX <= INT_MAX ?
+ EXPR_TYPE_IS(CHAR_MAX, int) :
+ EXPR_TYPE_IS(CHAR_MAX, unsigned int), "");
+#if CHAR_MAX
+#endif
 
 #if __STDC_VERSION__ >= 199901 || __cplusplus >= 201103L
 _Static_assert(LLONG_MAX == -(LLONG_MIN+1LL), "");
+_Static_assert(EXPR_TYPE_IS(LLONG_MAX, long long), "");
+#if LLONG_MAX
+#endif
+
 _Static_assert(LLONG_MIN == -LLONG_MAX-1LL, "");
+#if LLONG_MIN
+#endif
+_Static_assert(EXPR_TYPE_IS(LLONG_MIN, long long), "");
+
 _Static_assert(ULLONG_MAX == (unsigned long long)~0ULL, "");
+_Static_assert(EXPR_TYPE_IS(ULLONG_MAX, unsigned long long), "");
+#if ULLONG_MAX
+#endif
 #else
 int LLONG_MIN, LLONG_MAX, ULLONG_MAX; // Not defined.
 #endif
@@ -47,35 +131,61 @@
 #if __STDC_VERSION__ >= 202000L
 /* Validate the standard requirements. */
 _Static_assert(BOOL_WIDTH >= 1);
+#if BOOL_WIDTH
+#endif
 
 _Static_assert(CHAR_WIDTH == CHAR_BIT);
 _Static_assert(CHAR_WIDTH / CHAR_BIT == sizeof(char));
+#if CHAR_WIDTH
+#endif
 _Static_assert(SCHAR_WIDTH == CHAR_BIT);
 _Static_assert(SCHAR_WIDTH / CHAR_BIT == sizeof(signed char));
+#if SCHAR_WIDTH
+#endif
 _Static_assert(UCHAR_WIDTH == CHAR_BIT);
 _Static_assert(UCHAR_WIDTH / CHAR_BIT == sizeof(unsigned char));
+#if UCHAR_WIDTH
+#endif
 
 _Static_assert(USHRT_WIDTH >= 16);
 _Static_assert(USHRT_WIDTH / CHAR_BIT == sizeof(unsigned short));
+#if USHRT_WIDTH
+#endif
 _Static_assert(SHRT_WIDTH == USHRT_WIDTH);
 _Static_assert(SHRT_WIDTH / CHAR_BIT == sizeof(signed short));
+#if SHRT_WIDTH
+#endif
 
 

[PATCH] D144889: [C2x] Support in freestanding

2023-02-27 Thread Ben Craig via Phabricator via cfe-commits
bcraig added a comment.

A freestanding implementation doesn't necessarily mean that everything is 
header-only.  It's fine to require linking against a (freestanding) C runtime 
library.  All header-only is fine too though, if you want to make that work.

Architecturally, I don't feel it is required that Clang be the location of all 
the freestanding headers for C.  I think that's fine for the C library in the 
final toolchain to own those headers.  I'm not super familiar with what 
interface contracts you have between the clang-provided C headers and the 
C-library provided C headers though.

> I'm not sure it makes sense to provide a "freestanding" strtok; it requires 
> global state.

I agree with this, but the C committee felt otherwise.  C++26 freestanding is 
most likely including strtok too, to stay consistent with C (the freestanding C 
library paper is through LWG and awaiting a C++26 plenary vote).  It shouldn't 
be hard to implement in an OS-independent way, but it will be a low quality 
implementation with cross-thread races.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144889

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


Re: [clang] 6ed67cc - [Coroutines] Remove -fcoroutines-ts

2023-02-27 Thread Bruno Cardoso Lopes via cfe-commits
Hi Chuanqi,

I know the warning mentions it to be removed in clang-17, but a heads
up "landing in a week" or so would have been great :)

I understand that the name "coroutines-ts" isn't meaningful these
days, but it also sounds like this commit does more than remove the
flag, it caps useful functionality. How are users supposed to use
c++17 with coroutines now? It's very common in our codebase and we
have users relying on it.

Thanks,

On Wed, Feb 22, 2023 at 10:44 PM Chuanqi Xu via cfe-commits
 wrote:
>
>
> Author: Chuanqi Xu
> Date: 2023-02-23T14:40:58+08:00
> New Revision: 6ed67ccba7e4699e9e42302f2f9b7653444258ba
>
> URL: 
> https://github.com/llvm/llvm-project/commit/6ed67ccba7e4699e9e42302f2f9b7653444258ba
> DIFF: 
> https://github.com/llvm/llvm-project/commit/6ed67ccba7e4699e9e42302f2f9b7653444258ba.diff
>
> LOG: [Coroutines] Remove -fcoroutines-ts
>
> Since we decided to remove the support for `-fcoroutines-ts` in
> clang/llvm17 and the clang16/llvm16 is branched. So we're going to
> remove the `-fcoroutines-ts` option.
>
> Added:
> clang/test/Parser/cxx20-coroutines.cpp
>
> Modified:
> clang/docs/ReleaseNotes.rst
> clang/include/clang/AST/Stmt.h
> clang/include/clang/Basic/DiagnosticDriverKinds.td
> clang/include/clang/Basic/DiagnosticGroups.td
> clang/include/clang/Basic/StmtNodes.td
> clang/include/clang/Basic/TokenKinds.def
> clang/include/clang/Driver/Options.td
> clang/include/clang/Sema/Sema.h
> clang/lib/AST/StmtPrinter.cpp
> clang/lib/Driver/ToolChains/Clang.cpp
> clang/lib/Sema/TreeTransform.h
> clang/test/AST/Inputs/std-coroutine-exp-namespace.h
> clang/test/AST/Inputs/std-coroutine.h
> clang/test/CodeGen/no-skipped-passes-O0-opt-bisect.c
> clang/test/CodeGenCoroutines/coro-builtins-err.c
> clang/test/CodeGenCoroutines/coro-builtins.c
> clang/test/CodeGenCoroutines/coro-gro2.cpp
> clang/test/CodeGenCoroutines/coro-params.cpp
> clang/test/CoverageMapping/coroutine.cpp
> clang/test/Driver/coroutines.c
> clang/test/Driver/coroutines.cpp
> clang/test/Index/coroutines.cpp
> clang/test/Lexer/coroutines.cpp
> clang/test/Lexer/cxx-features.cpp
> clang/test/Modules/requires-coroutines.mm
> clang/test/PCH/coroutines.cpp
> clang/test/SemaCXX/coroutine-builtins.cpp
> clang/test/SemaCXX/thread-safety-coro.cpp
>
> Removed:
> clang/test/Parser/cxx1z-coroutines.cpp
> clang/test/SemaCXX/Inputs/std-coroutine-exp-namespace.h
>
>
> 
> diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
> index 9c89bbc0d1786..be3ea5ff63cde 100644
> --- a/clang/docs/ReleaseNotes.rst
> +++ b/clang/docs/ReleaseNotes.rst
> @@ -115,6 +115,8 @@ Removed Compiler Flags
>  -
>  - The deprecated flag `-fmodules-ts` is removed. Please use ``-std=c++20``
>or higher to use standard C++ modules instead.
> +- The deprecated flag `-fcoroutines-ts` is removed. Please use ``-std=c++20``
> +  or higher to use standard C++ coroutines instead.
>
>  Attribute Changes in Clang
>  --
>
> diff  --git a/clang/include/clang/AST/Stmt.h b/clang/include/clang/AST/Stmt.h
> index b70cf3aec5d6c..45010f19b69b2 100644
> --- a/clang/include/clang/AST/Stmt.h
> +++ b/clang/include/clang/AST/Stmt.h
> @@ -978,7 +978,7 @@ class alignas(void *) Stmt {
>  SourceLocation RequiresKWLoc;
>};
>
> -  //===--- C++ Coroutines TS bitfields classes ---===//
> +  //===--- C++ Coroutines bitfields classes ---===//
>
>class CoawaitExprBitfields {
>  friend class CoawaitExpr;
> @@ -1082,7 +1082,7 @@ class alignas(void *) Stmt {
>  LambdaExprBitfields LambdaExprBits;
>  RequiresExprBitfields RequiresExprBits;
>
> -// C++ Coroutines TS expressions
> +// C++ Coroutines expressions
>  CoawaitExprBitfields CoawaitBits;
>
>  // Obj-C Expressions
>
> diff  --git a/clang/include/clang/Basic/DiagnosticDriverKinds.td 
> b/clang/include/clang/Basic/DiagnosticDriverKinds.td
> index 77fb1e00585a0..4c922650e100f 100644
> --- a/clang/include/clang/Basic/DiagnosticDriverKinds.td
> +++ b/clang/include/clang/Basic/DiagnosticDriverKinds.td
> @@ -637,11 +637,6 @@ def warn_drv_libstdcxx_not_found : Warning<
>"command line to use the libc++ standard library instead">,
>InGroup>;
>
> -def warn_deperecated_fcoroutines_ts_flag : Warning<
> -  "the '-fcoroutines-ts' flag is deprecated and it will be removed in Clang 
> 17; "
> -  "use '-std=c++20' or higher to use standard C++ coroutines instead">,
> -  InGroup;
> -
>  def err_drv_cannot_mix_options : Error<"cannot specify '%1' along with 
> '%0'">;
>
>  def err_drv_invalid_object_mode : Error<
>
> diff  --git a/clang/include/clang/Basic/DiagnosticGroups.td 
> b/clang/include/clang/Basic/DiagnosticGroups.td
> index 17fdcffa2d427..d56aba34ac0a3 100644
> --- a/clang/include/clang/Basic/DiagnosticGroups.td
> +++ 

[PATCH] D144680: [Coroutines] Avoid creating conditional cleanup markers in suspend block

2023-02-27 Thread Wei Wang via Phabricator via cfe-commits
weiwang added a comment.

In D144680#4149149 , @ChuanqiXu wrote:

> BTW, what is the conclusion for the concern about sanitizers? Would change 
> make sanitizers to perform false positive diagnostics?

This change is limited to the `await.suspend` block, which only does codegen 
for `awaiter.await_suspend(coroutine_handle::from_promise(p))`. In this 
case, I think the only asan check removed by the change is the conditional 
marker for cleanup the temporary `coroutine_handler` used as the parameter of 
`await_suspend`, so my understanding is that it shouldn't affect asan 
diagnostic.

To show the difference it makes to the source from issue #59181

Before:

  %ref.tmp25 = alloca %"struct.std::__1::coroutine_handle.6", align 8
  ...
  // asan check inserted here
  bool cond_cleanup_marker = false;
  
  if (cond) {
  // get awaiter
  ...
  
  if (!awaiter.await_ready()) {
  call void @llvm.lifetime.start.p0(i64 8, ptr %ref.tmp25)
  
  // asan check inserted here
cond_cleanup_marker = true;

  // store handler to %ref.tmp25
...

  awaiter.await_suspend();
  
  // asan check inserted here
if (cond_cleanup_marker)
call void @llvm.lifetime.end.p0(i64 8, ptr %ref.tmp25)
  call i8 @llvm.coro.suspend(...)
...
  }
  ...
  } else {
  ... 
  }
  ...
  lpad:
  ...
  // asan check inserted here
  if (cond_cleanup_marker)
  call void @llvm.lifetime.end.p0(i64 8, ptr %ref.tmp25)

The issue is only reproduced in `-O0`, because ``cond_cleanup_marker` is 
optimized away in `-O1` or up opt level.

After:

  %ref.tmp25 = alloca %"struct.std::__1::coroutine_handle.6", align 8
  ...
  
  call void @llvm.lifetime.start.p0(i64 8, ptr %ref.tmp25)
  
  if (cond) {
  ...
  if (!awaiter.await_ready()) {
  // store handler to %ref.tmp25
...
  
awaiter.await_suspend();
call void @llvm.lifetime.end.p0(i64 8, ptr %ref.tmp25)
call i8 @llvm.coro.suspend(...)
...
  }
  ...
  } else {
  ... 
  }
  ...
  lpad:
  call void @llvm.lifetime.end.p0(i64 8, ptr %ref.tmp25)

This also matches with the IR without asan.




Comment at: clang/lib/CodeGen/CGExpr.cpp:544
   // so that it's unconditional. Don't do this with sanitizers which need
   // more precise lifetime marks.
   ConditionalEvaluation *OldConditional = nullptr;

ChuanqiXu wrote:
> We should add comment to explain why we add a forward path for coroutines.
Will do



Comment at: clang/lib/CodeGen/CodeGenFunction.h:336
 std::unique_ptr Data;
+bool InSuspendBlock = false;
 CGCoroInfo();

bruno wrote:
> Should this live inside CGCoroData instead?
`CGCoroData` is forward declared here, so it does not know what's inside.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144680

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


[PATCH] D144889: [C2x] Support in freestanding

2023-02-27 Thread Eli Friedman via Phabricator via cfe-commits
efriedma added a comment.

Historically, the required functions for a "freestanding" C implementation were 
very restricted.  Freestanding headers didn't export library functions, just 
constants and types.

As a practical matter, we actually do need a few functions to support code 
generation for C even if they don't include any standard library headers.  We 
expect "freestanding" users to provide the three functions memcpy, memmove, and 
memset.  Other misc. functions like large integer operations and floating point 
are provided by compiler-rt.builtins (which is ABI-compatible with libgcc).

Note that we can't easily expand the API surface of compiler-rt.builtins; see 
https://discourse.llvm.org/t/proposal-split-built-ins-from-the-rest-of-compiler-rt/67978
 .

> was that the first one is lowered to a potential library call while the 
> second one is is lowered to a backend implementation that performs the work

The difference is really that the __builtin_* functions are recognized as 
builtins even if the the user is using -fno-builtin/-ffreestanding.  It doesn't 
mean we actually have dedicated codegen support.

> We do not currently have builtins for memccpy, memset_explicit, or strtok

I'm not sure it makes sense to provide a "freestanding" strtok; it requires 
global state.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144889

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


[PATCH] D144285: [Clang] Implement CWG2518 - static_assert(false)

2023-02-27 Thread Aaron Ballman via Phabricator via cfe-commits
aaron.ballman added inline comments.



Comment at: clang/lib/Sema/SemaDeclCXX.cpp:16824-16841
   if (InnerCond && isa(InnerCond)) {
 // Drill down into concept specialization expressions to see why they
 // weren't satisfied.
 Diag(StaticAssertLoc, diag::err_static_assert_failed)
   << !AssertMessage << Msg.str() << AssertExpr->getSourceRange();
 ConstraintSatisfaction Satisfaction;
 if (!CheckConstraintSatisfaction(InnerCond, Satisfaction))

cor3ntin wrote:
> aaron.ballman wrote:
> > cor3ntin wrote:
> > > rsmith wrote:
> > > > I wonder if it's worth adding a custom diagnostic (eg, "this template 
> > > > cannot be instantiated: %0") for the case where we're in template 
> > > > instantiation and the expression is the bool literal `false`.
> > > I'm not sure i see the motivation. Why would we want to special case 
> > > `false`? The expression could also be an always false, never dependent 
> > > expression
> > Richard may have different ideas in mind, but the motivation to me is code 
> > like: 
> > ```
> > template 
> > struct S {
> >   static_assert(false, "you have to use one of the valid specializations, 
> > not the primary template");
> > };
> > 
> > template <>
> > struct S {
> > };
> > 
> > template <>
> > struct S {
> > };
> > 
> > int main() {
> >   S s1;
> >   S s2;
> >   S s3;
> > }
> > ```
> > Rather than telling the user the static_assert failed because false is not 
> > true, having a custom diagnostic might read better for users. GCC doesn't 
> > produce a custom diagnostic -- the behavior isn't terrible, but the "false 
> > evaluates to false" note is effectively just noise, too: 
> > https://godbolt.org/z/456bzWG7c
> OH. That makes sense now,  thanks. I think I agree.
> Interestingly, in gcc immediate calls are really immediate :) 
> https://godbolt.org/z/b3vrzf4sj 
I think you should add this case as a test in dr25xx.cpp to show we get the 
behavior correct with specializations.



Comment at: clang/test/CXX/drs/dr25xx.cpp:5-14
+#error one
+// expected-error@-1 {{one}}
+#if 0
+#error skip
+#warning skip // expected-error {{skip}}
+#endif
+#error two

What do these tests have to do with this DR?



Comment at: clang/test/CXX/drs/dr25xx.cpp:9
+#error skip
+#warning skip // expected-error {{skip}}
+#endif

Why do we expect an error on this line in a `#if 0` block??



Comment at: clang/test/SemaCXX/static-assert.cpp:235-236
+int f() {
+  S s; //expected-note{{in instantiation of template class 
'DependentAlwaysFalse::S' requested here}}
+  T t; //expected-note{{in instantiation of template class 
'DependentAlwaysFalse::T' requested here}}
+}




Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144285

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


[PATCH] D144218: [Clang] [AVR] Fix USHRT_MAX for 16-bit int.

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

LGTM with a small change to the test coverage.




Comment at: clang/test/Headers/limits.cpp:8
+// Specifically test 16-bit int platforms.
+// RUN: %clang_cc1 -triple=avr -ffreestanding -fsyntax-only -verify -x c %s
+

Might as well add a C++ RUN as well to make sure we cover both language modes.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144218

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


[PATCH] D143415: LibclangTest: remove libclang-test-* tmp dir reliably

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

LGTM!


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D143415

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


[PATCH] D144232: [PowerPC] Correctly use ELFv2 ABI on FreeBSD/powerpc64

2023-02-27 Thread Alfredo Dal'Ava Júnior via Phabricator via cfe-commits
adalava added a comment.

In D144232#4137367 , @dim wrote:

> In D144232#4136787 , @brad wrote:
>
>> I noticed this review. I have provided a more complete diff for review at 
>> D144321 .
>
> Yeah I think that is probably the better option, hope @pkubaj and @adalava 
> agree with that?
>
> As Brad's version covers both FreeBSD and OpenBSD, and also updates a bunch 
> of unit tests, which this review appears to break (see the Unit Tests 
> https://reviews.llvm.org/harbormaster/unit/214420/).

I agree with D144321 , sorry for the late 
reply.  @pkubaj and @brad , thanks for pushing it. I think D144232 
 can be abandoned, right?


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144232

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


[PATCH] D144878: __builtin_FILE_NAME()

2023-02-27 Thread Shafik Yaghmour via Phabricator via cfe-commits
shafik added inline comments.



Comment at: clang/lib/AST/Expr.cpp:2283
+  case SourceLocExpr::FileName: {
+SmallString<256> Path;
+// builtin_FILE_NAME() is a Clang-specific extension that expands to the

It looks like a copy of the code from `ExpandBuiltinMacro` since we are already 
calling `processPathForFileMacro` from that same file why not factor out this 
code? If we can avoid code duplication we should to prevent possible future 
refactors only updating one copy of the code.


Repository:
  rG LLVM Github Monorepo

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

https://reviews.llvm.org/D144878

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


[PATCH] D143524: Make the -Wunused-template default.

2023-02-27 Thread Louis Dionne via Phabricator via cfe-commits
ldionne added inline comments.



Comment at: clang/test/SemaCXX/warn-func-not-needed.cpp:13
 namespace test1_template {
-template  static void f() {}
+template  static void f() {} // expected-warning {{unused function 
template}}
 template <> void f() {} // expected-warning {{function 'f' is not 
needed and will not be emitted}}

aaron.ballman wrote:
> v.g.vassilev wrote:
> > aaron.ballman wrote:
> > > v.g.vassilev wrote:
> > > > aaron.ballman wrote:
> > > > > Why is this unused? `f()` in `foo()` should cause this to be 
> > > > > used, right?
> > > > > 
> > > > > How should a user silence this diagnostic without disabling it 
> > > > > entirely?
> > > > Nobody uses `foo`.
> > > Ah, good point on `foo` not being used, but the question still stands -- 
> > > how does the user silence this diagnostic? It's not at all uncommon to 
> > > have a primary template with specializations where the TU only uses 
> > > either the primary or a specialization, but not both (and certainly not 
> > > all specializations).
> > @philnik used `[[maybe_unused]]` which seemed reasonable to me for 
> > silencing the diagnostic. Maybe take a look at the changes done here: 
> > https://reviews.llvm.org/D144667
> That's reasonable if the interface is one the user controls, such as one 
> within a .cpp file. But the situation I'm worried about is where the primary 
> template and specializations live in a header file that's shared between 
> multiple TUs. I don't think it's reasonable to expect users to put 
> `[[maybe_unused]]` on the primary template and all specializations in that 
> situation.
Don't y'all find it weird to have to use `[[maybe_unused]]` on something that 
is only a declaration like those CTAD guides? And I agree with @aaron.ballman 
here: we provide headers that are used in various TUs, and we obviously never 
expect that the entirety of our headers is going to be used by every single TU.

In other words, we totally expect that those deduction guides will be unused in 
some cases, since it's entirely fine for a user not to use them but for us to 
still provide them. If I understood this correctly, this seems like a flaw in 
the warning that we should fix in Clang.


Repository:
  rC Clang

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

https://reviews.llvm.org/D143524

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


[PATCH] D144894: [clang] Documents clang-scan-deps requirements.

2023-02-27 Thread Mark de Wever via Phabricator via cfe-commits
Mordante created this revision.
Mordante added a reviewer: ChuanqiXu.
Herald added a project: All.
Mordante requested review of this revision.
Herald added a project: clang.
Herald added a subscriber: cfe-commits.

This was discussed in https://llvm.org/PR61006.


Repository:
  rG LLVM Github Monorepo

https://reviews.llvm.org/D144894

Files:
  clang/docs/StandardCPlusPlusModules.rst


Index: clang/docs/StandardCPlusPlusModules.rst
===
--- clang/docs/StandardCPlusPlusModules.rst
+++ clang/docs/StandardCPlusPlusModules.rst
@@ -1033,6 +1033,12 @@
 
   $ clang-scan-deps -format=p1689 -- /clang++ 
-std=c++20 impl_part.cppm -c -o impl_part.o
 
+.. warning::
+
+   The ``/clang++`` should point to the real
+   binary and not to a symlink. If it points to a symlink the include paths
+   will not be correctly resolved.
+
 And we'll get:
 
 .. code-block:: text


Index: clang/docs/StandardCPlusPlusModules.rst
===
--- clang/docs/StandardCPlusPlusModules.rst
+++ clang/docs/StandardCPlusPlusModules.rst
@@ -1033,6 +1033,12 @@
 
   $ clang-scan-deps -format=p1689 -- /clang++ -std=c++20 impl_part.cppm -c -o impl_part.o
 
+.. warning::
+
+   The ``/clang++`` should point to the real
+   binary and not to a symlink. If it points to a symlink the include paths
+   will not be correctly resolved.
+
 And we'll get:
 
 .. code-block:: text
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


  1   2   >