[Lldb-commits] [mlir] [lldb] [clang-tools-extra] [llvm] [flang] [libcxx] [openmp] [libc] [compiler-rt] [clang] [clang-tidy] Add performance-move-smart-pointer-contents check. (PR #66139)

2023-12-06 Thread Piotr Zegar via lldb-commits

PiotrZSL wrote:

Personally I think that check for move out of std::unique_ptr, and check for 
overall heavy moves could be implemented as an separate one, not related to 
unique_ptr. Easiest way to detect heavy moves is to check size of object, and 
above some threshold mark them as heavy. But thats a separate problem. Maybe 
this PR should be abandoned.

https://github.com/llvm/llvm-project/pull/66139
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Fix a stall in running `quit` while a live process is running (PR #74687)

2023-12-06 Thread Med Ismail Bennani via lldb-commits

https://github.com/medismailben approved this pull request.

LGTM!

https://github.com/llvm/llvm-project/pull/74687
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

2023-12-06 Thread Greg Clayton via lldb-commits


@@ -2225,7 +2225,8 @@ void ObjectFileMachO::ParseSymtab(Symtab ) {
   const char *file_name = file.GetFilename().AsCString("");
   LLDB_SCOPED_TIMERF("ObjectFileMachO::ParseSymtab () module = %s", file_name);
   LLDB_LOG(log, "Parsing symbol table for {0}", file_name);
-  Progress progress(llvm::formatv("Parsing symbol table for {0}", file_name));
+  Progress progress(llvm::formatv("Parsing symbol table for {0}", file_name),
+Progress::ProgressReportType::eAggregateProgressReport);

clayborg wrote:

> Adding a string to represent the category (one of a possible vector of 
> strings for each operation even?) looks like a good idea though.

Seems to me that a `category` string that could be anything ("Parsing symbol 
tables" or "Indexing DWARF" or "Parsing DWARF") would allow us to group similar 
notifications together in an IDE better than a single 
`ProgressReportType::eAggregateProgressReport` vs 
`ProgressReportType::eNonAggregateProgressReport` enum value. With this 
solution, does this mean that all notifications that with `is_aggregate == 
true` would show up in one area and `is_aggregate == false` would show up 
another area? If we use a `category` string, any concurrent notifications that 
share the same `category` could show up under some UI that displayed the 
`category` string and allowed it to be expanded


https://github.com/llvm/llvm-project/pull/69516
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Fix a stall in running `quit` while a live process is running (PR #74687)

2023-12-06 Thread via lldb-commits

github-actions[bot] wrote:




:warning: C/C++ code formatter, clang-format found issues in your code. 
:warning:



You can test this locally with the following command:


``bash
git-clang-format --diff c6dc9cd1fbfcb47aa193f16cb02b97876643e1fe 
64505f573341c16a62eda786c4710d3a7233cecc -- 
lldb/test/API/driver/quit_speed/main.c lldb/include/lldb/Target/Process.h 
lldb/source/Core/Debugger.cpp 
lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp 
lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp 
lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp 
lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp 
lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp 
lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp 
lldb/source/Target/Process.cpp lldb/source/Target/ProcessTrace.cpp 
lldb/source/Target/Target.cpp
``





View the diff from clang-format here.


``diff
diff --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index 889f553f89..d0f054dd54 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -3085,7 +3085,7 @@ protected:
   // When we are "Finalizing" we need to do some cleanup.  But if the Finalize
   // call is coming in the Destructor, we can't do any actual work in the
   // process because that is likely to call "shared_from_this" which crashes
-  // if run while destructing.  We use this flag to determine that.   
+  // if run while destructing.  We use this flag to determine that.
   std::atomic m_destructing;
 
   /// Mask for code an data addresses. The default value (0) means no mask is
diff --git a/lldb/source/Target/Process.cpp b/lldb/source/Target/Process.cpp
index 23f72645e8..aa3b04c43c 100644
--- a/lldb/source/Target/Process.cpp
+++ b/lldb/source/Target/Process.cpp
@@ -1418,7 +1418,7 @@ StateType Process::GetPrivateState() { return 
m_private_state.GetValue(); }
 
 void Process::SetPrivateState(StateType new_state) {
   // Use m_destructing not m_finalizing here.  If we are finalizing a process
-  // that we haven't started tearing down, we'd like to be able to nicely 
+  // that we haven't started tearing down, we'd like to be able to nicely
   // detach if asked, but that requires the event system be live.  That will
   // not be true for an in-the-middle-of-being-destructed Process, since the
   // event system relies on Process::shared_from_this, which may have already
diff --git a/lldb/test/API/driver/quit_speed/main.c 
b/lldb/test/API/driver/quit_speed/main.c
index fd041a4fe9..7daea6fe52 100644
--- a/lldb/test/API/driver/quit_speed/main.c
+++ b/lldb/test/API/driver/quit_speed/main.c
@@ -1,9 +1,7 @@
 #include 
 
-int 
-main (int argc, char **argv)
-{
-  while(1)
+int main(int argc, char **argv) {
+  while (1)
 usleep(5);
 
   return 0;

``




https://github.com/llvm/llvm-project/pull/74687
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] Fix a stall in running `quit` while a live process is running (PR #74687)

2023-12-06 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-lldb

Author: None (jimingham)


Changes

We need to generate events when finalizing, or we won't know that we succeeded 
in stopping the process to detach/kill.  Instead, we stall and then after our 
20 interrupt timeout, we kill the process (even if we were supposed to detach) 
and exit.

OTOH, we have to not generate events when the Process is being destructed 
because shared_from_this has already been torn down, and using it will cause 
crashes.

---
Full diff: https://github.com/llvm/llvm-project/pull/74687.diff


14 Files Affected:

- (modified) lldb/include/lldb/Target/Process.h (+9-1) 
- (modified) lldb/source/Core/Debugger.cpp (+1-1) 
- (modified) lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp (+1-1) 
- (modified) lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp (+1-1) 
- (modified) lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp (+1-1) 
- (modified) lldb/source/Plugins/Process/mach-core/ProcessMachCore.cpp (+1-1) 
- (modified) lldb/source/Plugins/Process/minidump/ProcessMinidump.cpp (+1-1) 
- (modified) lldb/source/Plugins/Process/scripted/ScriptedProcess.cpp (+1-1) 
- (modified) lldb/source/Target/Process.cpp (+11-3) 
- (modified) lldb/source/Target/ProcessTrace.cpp (+1-1) 
- (modified) lldb/source/Target/Target.cpp (+1-1) 
- (added) lldb/test/API/driver/quit_speed/Makefile (+3) 
- (added) lldb/test/API/driver/quit_speed/TestQuitWithProcess.py (+34) 
- (added) lldb/test/API/driver/quit_speed/main.c (+10) 


``diff
diff --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index 4646e3070cf14..889f553f897f5 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -558,7 +558,10 @@ class Process : public 
std::enable_shared_from_this,
   ///
   /// Subclasses that override this method should always call this superclass
   /// method.
-  virtual void Finalize();
+  /// If you are running Finalize in your Process subclass Destructor, pass
+  /// \btrue.  If we are in the destructor, shared_from_this will no longer
+  /// work, so we have to avoid doing anything that might trigger that.
+  virtual void Finalize(bool destructing);
 
   /// Return whether this object is valid (i.e. has not been finalized.)
   ///
@@ -3079,6 +3082,11 @@ void PruneThreadPlans();
   /// This is set at the beginning of Process::Finalize() to stop functions
   /// from looking up or creating things during or after a finalize call.
   std::atomic m_finalizing;
+  // When we are "Finalizing" we need to do some cleanup.  But if the Finalize
+  // call is coming in the Destructor, we can't do any actual work in the
+  // process because that is likely to call "shared_from_this" which crashes
+  // if run while destructing.  We use this flag to determine that.   
+  std::atomic m_destructing;
 
   /// Mask for code an data addresses. The default value (0) means no mask is
   /// set.  The bits set to 1 indicate bits that are NOT significant for
diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 21f71e449ca5e..d0b362045e801 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -930,7 +930,7 @@ void Debugger::Clear() {
 for (TargetSP target_sp : m_target_list.Targets()) {
   if (target_sp) {
 if (ProcessSP process_sp = target_sp->GetProcessSP())
-  process_sp->Finalize();
+  process_sp->Finalize(false);
 target_sp->Destroy();
   }
 }
diff --git a/lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp 
b/lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
index 70bb9aa7a833c..4ab6c8cf1959d 100644
--- a/lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
+++ b/lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
@@ -164,7 +164,7 @@ ProcessKDP::~ProcessKDP() {
   // make sure all of the broadcaster cleanup goes as planned. If we destruct
   // this class, then Process::~Process() might have problems trying to fully
   // destroy the broadcaster.
-  Finalize();
+  Finalize(true);
 }
 
 Status ProcessKDP::DoWillLaunch(Module *module) {
diff --git a/lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp 
b/lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
index aedc43a015ff1..24d5fdebd4bd5 100644
--- a/lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
+++ b/lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
@@ -108,7 +108,7 @@ ProcessElfCore::~ProcessElfCore() {
   // make sure all of the broadcaster cleanup goes as planned. If we destruct
   // this class, then Process::~Process() might have problems trying to fully
   // destroy the broadcaster.
-  Finalize();
+  Finalize(true);
 }
 
 lldb::addr_t ProcessElfCore::AddAddressRangeFromLoadSegment(
diff --git a/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp 
b/lldb/source/Plugins/Process/gdb-remote/ProcessGDBRemote.cpp
index b04319703b946..b9ce4198471a0 100644
--- 

[Lldb-commits] [lldb] Fix a stall in running `quit` while a live process is running (PR #74687)

2023-12-06 Thread via lldb-commits

https://github.com/jimingham created 
https://github.com/llvm/llvm-project/pull/74687

We need to generate events when finalizing, or we won't know that we succeeded 
in stopping the process to detach/kill.  Instead, we stall and then after our 
20 interrupt timeout, we kill the process (even if we were supposed to detach) 
and exit.

OTOH, we have to not generate events when the Process is being destructed 
because shared_from_this has already been torn down, and using it will cause 
crashes.

>From 64505f573341c16a62eda786c4710d3a7233cecc Mon Sep 17 00:00:00 2001
From: Jim Ingham 
Date: Wed, 6 Dec 2023 17:01:06 -0800
Subject: [PATCH] We need to generate events when finalizing, or we won't know
 that we succeeded in stopping the process to detach/kill.  Instead, we stall
 and then after our 20 interrupt timeout, we kill the process (even if we were
 supposed to detach) and exit.

OTOH, we have to not generate events when the Process is being destructed
because shared_from_this has already been torn down, and using it will
cause crashes.
---
 lldb/include/lldb/Target/Process.h| 10 +-
 lldb/source/Core/Debugger.cpp |  2 +-
 .../Process/MacOSX-Kernel/ProcessKDP.cpp  |  2 +-
 .../Process/elf-core/ProcessElfCore.cpp   |  2 +-
 .../Process/gdb-remote/ProcessGDBRemote.cpp   |  2 +-
 .../Process/mach-core/ProcessMachCore.cpp |  2 +-
 .../Process/minidump/ProcessMinidump.cpp  |  2 +-
 .../Process/scripted/ScriptedProcess.cpp  |  2 +-
 lldb/source/Target/Process.cpp| 14 ++--
 lldb/source/Target/ProcessTrace.cpp   |  2 +-
 lldb/source/Target/Target.cpp |  2 +-
 lldb/test/API/driver/quit_speed/Makefile  |  3 ++
 .../driver/quit_speed/TestQuitWithProcess.py  | 34 +++
 lldb/test/API/driver/quit_speed/main.c| 10 ++
 14 files changed, 76 insertions(+), 13 deletions(-)
 create mode 100644 lldb/test/API/driver/quit_speed/Makefile
 create mode 100644 lldb/test/API/driver/quit_speed/TestQuitWithProcess.py
 create mode 100644 lldb/test/API/driver/quit_speed/main.c

diff --git a/lldb/include/lldb/Target/Process.h 
b/lldb/include/lldb/Target/Process.h
index 4646e3070cf14..889f553f897f5 100644
--- a/lldb/include/lldb/Target/Process.h
+++ b/lldb/include/lldb/Target/Process.h
@@ -558,7 +558,10 @@ class Process : public 
std::enable_shared_from_this,
   ///
   /// Subclasses that override this method should always call this superclass
   /// method.
-  virtual void Finalize();
+  /// If you are running Finalize in your Process subclass Destructor, pass
+  /// \btrue.  If we are in the destructor, shared_from_this will no longer
+  /// work, so we have to avoid doing anything that might trigger that.
+  virtual void Finalize(bool destructing);
 
   /// Return whether this object is valid (i.e. has not been finalized.)
   ///
@@ -3079,6 +3082,11 @@ void PruneThreadPlans();
   /// This is set at the beginning of Process::Finalize() to stop functions
   /// from looking up or creating things during or after a finalize call.
   std::atomic m_finalizing;
+  // When we are "Finalizing" we need to do some cleanup.  But if the Finalize
+  // call is coming in the Destructor, we can't do any actual work in the
+  // process because that is likely to call "shared_from_this" which crashes
+  // if run while destructing.  We use this flag to determine that.   
+  std::atomic m_destructing;
 
   /// Mask for code an data addresses. The default value (0) means no mask is
   /// set.  The bits set to 1 indicate bits that are NOT significant for
diff --git a/lldb/source/Core/Debugger.cpp b/lldb/source/Core/Debugger.cpp
index 21f71e449ca5e..d0b362045e801 100644
--- a/lldb/source/Core/Debugger.cpp
+++ b/lldb/source/Core/Debugger.cpp
@@ -930,7 +930,7 @@ void Debugger::Clear() {
 for (TargetSP target_sp : m_target_list.Targets()) {
   if (target_sp) {
 if (ProcessSP process_sp = target_sp->GetProcessSP())
-  process_sp->Finalize();
+  process_sp->Finalize(false);
 target_sp->Destroy();
   }
 }
diff --git a/lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp 
b/lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
index 70bb9aa7a833c..4ab6c8cf1959d 100644
--- a/lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
+++ b/lldb/source/Plugins/Process/MacOSX-Kernel/ProcessKDP.cpp
@@ -164,7 +164,7 @@ ProcessKDP::~ProcessKDP() {
   // make sure all of the broadcaster cleanup goes as planned. If we destruct
   // this class, then Process::~Process() might have problems trying to fully
   // destroy the broadcaster.
-  Finalize();
+  Finalize(true);
 }
 
 Status ProcessKDP::DoWillLaunch(Module *module) {
diff --git a/lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp 
b/lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
index aedc43a015ff1..24d5fdebd4bd5 100644
--- a/lldb/source/Plugins/Process/elf-core/ProcessElfCore.cpp
+++ 

[Lldb-commits] [llvm] [lldb] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

2023-12-06 Thread Kevin Frei via lldb-commits

kevinfrei wrote:

> This change broke building against LLVM dylib:
> 
> ```
> /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: 
> cannot find -lLLVMDebuginfod: No such file or directory
> collect2: error: ld returned 1 exit status
> samu: subcommand failed
> ```
> 
> Full build log: 
> [dev-util:lldb-18.0.0_pre20231206:20231206-163149.log](https://github.com/llvm/llvm-project/files/13588891/dev-util.lldb-18.0.0_pre20231206.20231206-163149.log)

@mgorny Can you please point me at where to find all the configuration for 
those builds? I'm stuck on a weirdo CentOS build (or MacOS) and can't manage to 
get my CMake configuration stuff to let me build a dylib/so. I'll get on this 
first thing tomorrow.

https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [llvm] [lldb] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

2023-12-06 Thread Kevin Frei via lldb-commits

kevinfrei wrote:

> This change broke building against LLVM dylib:
> 
> ```
> /usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: 
> cannot find -lLLVMDebuginfod: No such file or directory
> collect2: error: ld returned 1 exit status
> samu: subcommand failed
> ```
> 
> Full build log: 
> [dev-util:lldb-18.0.0_pre20231206:20231206-163149.log](https://github.com/llvm/llvm-project/files/13588891/dev-util.lldb-18.0.0_pre20231206.20231206-163149.log)

Sounds like I get to dig in deeper to LLVM's build, now. Hooray 藍 

https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [lld] [clang-tools-extra] [lldb] [libcxxabi] [mlir] [compiler-rt] [libc] [openmp] [llvm] [libcxx] [flang] [llvm] Support IFuncs on Darwin platforms (PR #73686)

2023-12-06 Thread Jon Roelofs via lldb-commits

https://github.com/jroelofs updated 
https://github.com/llvm/llvm-project/pull/73686

>From bc152095691b32d1ad8539dfd60f5089df5eed8d Mon Sep 17 00:00:00 2001
From: Jon Roelofs 
Date: Tue, 28 Nov 2023 10:39:44 -0800
Subject: [PATCH 1/9] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20in?=
 =?UTF-8?q?itial=20version?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Created using spr 1.3.4
---
 llvm/docs/LangRef.rst |   7 +-
 llvm/include/llvm/CodeGen/AsmPrinter.h|   6 +-
 llvm/lib/CodeGen/GlobalISel/CallLowering.cpp  |   7 +-
 llvm/lib/IR/Verifier.cpp  |  12 +-
 llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp | 308 ++
 llvm/lib/Target/X86/X86AsmPrinter.cpp |  28 ++
 llvm/lib/Target/X86/X86AsmPrinter.h   |   1 +
 .../AArch64/GlobalISel/call-lowering-ifunc.ll |  37 +++
 llvm/test/CodeGen/AArch64/addrsig-macho.ll|   4 +-
 llvm/test/CodeGen/AArch64/ifunc-asm.ll|  82 +
 llvm/test/CodeGen/X86/ifunc-asm.ll|  28 +-
 llvm/test/Verifier/ifunc-macho.ll |  42 +++
 12 files changed, 539 insertions(+), 23 deletions(-)
 create mode 100644 llvm/test/CodeGen/AArch64/GlobalISel/call-lowering-ifunc.ll
 create mode 100644 llvm/test/CodeGen/AArch64/ifunc-asm.ll
 create mode 100644 llvm/test/Verifier/ifunc-macho.ll

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index e448c5ed5c5d9..cb222e979db29 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -934,10 +934,11 @@ IFuncs
 ---
 
 IFuncs, like as aliases, don't create any new data or func. They are just a new
-symbol that dynamic linker resolves at runtime by calling a resolver function.
+symbol that is resolved at runtime by calling a resolver function.
 
-IFuncs have a name and a resolver that is a function called by dynamic linker
-that returns address of another function associated with the name.
+On ELF platforms, IFuncs are resolved by the dynamic linker at load time. On
+MachO platforms, they are lowered in terms of ``.symbol_resolver``s, which
+lazily resolve the callee the first time they are called.
 
 IFunc may have an optional :ref:`linkage type ` and an optional
 :ref:`visibility style `.
diff --git a/llvm/include/llvm/CodeGen/AsmPrinter.h 
b/llvm/include/llvm/CodeGen/AsmPrinter.h
index 2731ef452c79c..48fa6c478464c 100644
--- a/llvm/include/llvm/CodeGen/AsmPrinter.h
+++ b/llvm/include/llvm/CodeGen/AsmPrinter.h
@@ -882,7 +882,11 @@ class AsmPrinter : public MachineFunctionPass {
 
   GCMetadataPrinter *getOrCreateGCPrinter(GCStrategy );
   void emitGlobalAlias(Module , const GlobalAlias );
-  void emitGlobalIFunc(Module , const GlobalIFunc );
+
+protected:
+  virtual void emitGlobalIFunc(Module , const GlobalIFunc );
+
+private:
 
   /// This method decides whether the specified basic block requires a label.
   bool shouldEmitLabelForBasicBlock(const MachineBasicBlock ) const;
diff --git a/llvm/lib/CodeGen/GlobalISel/CallLowering.cpp 
b/llvm/lib/CodeGen/GlobalISel/CallLowering.cpp
index 2527b14312896..e0080b145d4f9 100644
--- a/llvm/lib/CodeGen/GlobalISel/CallLowering.cpp
+++ b/llvm/lib/CodeGen/GlobalISel/CallLowering.cpp
@@ -144,7 +144,12 @@ bool CallLowering::lowerCall(MachineIRBuilder , 
const CallBase ,
   // Try looking through a bitcast from one function type to another.
   // Commonly happens with calls to objc_msgSend().
   const Value *CalleeV = CB.getCalledOperand()->stripPointerCasts();
-  if (const Function *F = dyn_cast(CalleeV))
+  if (const GlobalIFunc *IF = dyn_cast(CalleeV);
+  IF && MF.getTarget().getTargetTriple().isOSBinFormatMachO()) {
+// ld64 requires that .symbol_resolvers to be called via a stub, so these
+// must always be a diret call.
+Info.Callee = MachineOperand::CreateGA(IF, 0);
+  } else if (const Function *F = dyn_cast(CalleeV))
 Info.Callee = MachineOperand::CreateGA(F, 0);
   else
 Info.Callee = MachineOperand::CreateReg(GetCalleeReg(), false);
diff --git a/llvm/lib/IR/Verifier.cpp b/llvm/lib/IR/Verifier.cpp
index 5560c037aa3ee..94e76a43bf38d 100644
--- a/llvm/lib/IR/Verifier.cpp
+++ b/llvm/lib/IR/Verifier.cpp
@@ -959,6 +959,7 @@ void Verifier::visitGlobalIFunc(const GlobalIFunc ) {
   GlobalIFunc::getResolverFunctionType(GI.getValueType());
   Check(ResolverTy == ResolverFuncTy->getPointerTo(GI.getAddressSpace()),
 "IFunc resolver has incorrect type", );
+
 }
 
 void Verifier::visitNamedMDNode(const NamedMDNode ) {
@@ -2239,13 +2240,10 @@ void Verifier::verifyFunctionAttrs(FunctionType *FT, 
AttributeList Attrs,
   }
 
   // Check EVEX512 feature.
-  if (MaxParameterWidth >= 512 && Attrs.hasFnAttr("target-features")) {
-Triple T(M.getTargetTriple());
-if (T.isX86()) {
-  StringRef TF = Attrs.getFnAttr("target-features").getValueAsString();
-  Check(!TF.contains("+avx512f") || !TF.contains("-evex512"),
-"512-bit vector arguments require 'evex512' for AVX512", V);
-}
+  

[Lldb-commits] [compiler-rt] [llvm] [openmp] [libc] [lldb] [libcxx] [libcxxabi] [libunwind] [lld] [clang-tools-extra] [clang] [flang] [mlir] [Clang][Sema] Don't say "is declared here" for invalid temp

2023-12-06 Thread Justin Bogner via lldb-commits

https://github.com/bogner closed https://github.com/llvm/llvm-project/pull/71264
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [openmp] [libcxxabi] [clang] [compiler-rt] [libc] [mlir] [flang] [libcxx] [llvm] [lldb] [lld] [clang-tools-extra] [libunwind] [Clang][Sema] Don't say "is declared here" for invalid temp

2023-12-06 Thread Justin Bogner via lldb-commits

https://github.com/bogner updated 
https://github.com/llvm/llvm-project/pull/71264

>From cab6bcd73081fcbe9807adbf60b345f8d9e654e4 Mon Sep 17 00:00:00 2001
From: Justin Bogner 
Date: Fri, 3 Nov 2023 18:59:49 -0700
Subject: [PATCH] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20initia?=
 =?UTF-8?q?l=20version?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Created using spr 1.3.5
---
 clang/lib/Sema/SemaDecl.cpp   |   2 +-
 clang/lib/Sema/SemaDeclCXX.cpp|   3 +-
 clang/lib/Sema/SemaInit.cpp   |   3 +-
 clang/lib/Sema/SemaLambda.cpp |   3 +-
 clang/lib/Sema/SemaTemplate.cpp   | 123 --
 clang/lib/Sema/SemaType.cpp   |   3 +-
 .../test/SemaHLSL/BuiltIns/vector-errors.hlsl |   5 -
 7 files changed, 89 insertions(+), 53 deletions(-)

diff --git a/clang/lib/Sema/SemaDecl.cpp b/clang/lib/Sema/SemaDecl.cpp
index 396566a8f10a9..a86c428c9121a 100644
--- a/clang/lib/Sema/SemaDecl.cpp
+++ b/clang/lib/Sema/SemaDecl.cpp
@@ -5929,7 +5929,7 @@ Sema::GetNameFromUnqualifiedId(const UnqualifiedId ) 
{
   Diag(Name.StartLocation,
diag::err_deduction_guide_name_not_class_template)
 << (int)getTemplateNameKindForDiagnostics(TN) << TN;
-  if (Template)
+  if (Template && Template->getLocation().isValid())
 Diag(Template->getLocation(), diag::note_template_decl_here);
   return DeclarationNameInfo();
 }
diff --git a/clang/lib/Sema/SemaDeclCXX.cpp b/clang/lib/Sema/SemaDeclCXX.cpp
index 397b7a00e4531..de5cc07f5d428 100644
--- a/clang/lib/Sema/SemaDeclCXX.cpp
+++ b/clang/lib/Sema/SemaDeclCXX.cpp
@@ -11462,7 +11462,8 @@ bool Sema::CheckDeductionGuideDeclarator(Declarator , 
QualType ,
   GuidedTemplateDecl->getDeclContext()->getRedeclContext())) {
 Diag(D.getIdentifierLoc(), diag::err_deduction_guide_wrong_scope)
   << GuidedTemplateDecl;
-Diag(GuidedTemplateDecl->getLocation(), diag::note_template_decl_here);
+if (GuidedTemplateDecl->getLocation().isValid())
+  Diag(GuidedTemplateDecl->getLocation(), diag::note_template_decl_here);
   }
 
   auto  = D.getMutableDeclSpec();
diff --git a/clang/lib/Sema/SemaInit.cpp b/clang/lib/Sema/SemaInit.cpp
index ed02d3580f34f..0952b065d56b5 100644
--- a/clang/lib/Sema/SemaInit.cpp
+++ b/clang/lib/Sema/SemaInit.cpp
@@ -10575,7 +10575,8 @@ QualType 
Sema::DeduceTemplateSpecializationFromInitializer(
  diag::err_deduced_non_class_template_specialization_type)
   << (int)getTemplateNameKindForDiagnostics(TemplateName) << TemplateName;
 if (auto *TD = TemplateName.getAsTemplateDecl())
-  Diag(TD->getLocation(), diag::note_template_decl_here);
+  if (TD->getLocation().isValid())
+Diag(TD->getLocation(), diag::note_template_decl_here);
 return QualType();
   }
 
diff --git a/clang/lib/Sema/SemaLambda.cpp b/clang/lib/Sema/SemaLambda.cpp
index ca09b0481bcac..603b7465323e2 100644
--- a/clang/lib/Sema/SemaLambda.cpp
+++ b/clang/lib/Sema/SemaLambda.cpp
@@ -1444,7 +1444,8 @@ void Sema::ActOnStartOfLambdaDefinition(LambdaIntroducer 
,
   for (const auto  : Intro.Captures) {
 if (Capture.Id == TP->getIdentifier()) {
   Diag(Capture.Loc, diag::err_template_param_shadow) << Capture.Id;
-  Diag(TP->getLocation(), diag::note_template_param_here);
+  if (TP->getLocation().isValid())
+Diag(TP->getLocation(), diag::note_template_param_here);
 }
   }
 }
diff --git a/clang/lib/Sema/SemaTemplate.cpp b/clang/lib/Sema/SemaTemplate.cpp
index ee35486221280..1a6eaa196db09 100644
--- a/clang/lib/Sema/SemaTemplate.cpp
+++ b/clang/lib/Sema/SemaTemplate.cpp
@@ -872,7 +872,7 @@ bool Sema::DiagnoseUninstantiableTemplate(SourceLocation 
PointOfInstantiation,
   Note = diag::note_explicit_instantiation_here;
 }
   }
-  if (Note) // Diagnostics were emitted.
+  if (Note && Pattern->getLocation().isValid()) // Diagnostics were emitted.
 Diag(Pattern->getLocation(), *Note);
 
   // In general, Instantiation isn't marked invalid to get more than one
@@ -899,7 +899,8 @@ void Sema::DiagnoseTemplateParameterShadow(SourceLocation 
Loc, Decl *PrevDecl) {
   unsigned DiagId = getLangOpts().MSVCCompat ? diag::ext_template_param_shadow
  : diag::err_template_param_shadow;
   Diag(Loc, DiagId) << cast(PrevDecl)->getDeclName();
-  Diag(PrevDecl->getLocation(), diag::note_template_param_here);
+  if (PrevDecl->getLocation().isValid())
+Diag(PrevDecl->getLocation(), diag::note_template_param_here);
 }
 
 /// AdjustDeclIfTemplate - If the given decl happens to be a template, reset
@@ -4434,7 +4435,8 @@ static void checkMoreSpecializedThanPrimary(Sema , 
PartialSpecDecl *Partial) {
   << SFINAEArgString;
   }
 
-  S.Diag(Template->getLocation(), diag::note_template_decl_here);
+  if (Template->getLocation().isValid())
+S.Diag(Template->getLocation(), 

[Lldb-commits] [lldb] 71be8f3 - [lldb] Un-xfail test after commit revert

2023-12-06 Thread Felipe de Azevedo Piovezan via lldb-commits

Author: Felipe de Azevedo Piovezan
Date: 2023-12-06T14:35:34-08:00
New Revision: 71be8f3c23497e28c86f1135f564b16106d8d6fb

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

LOG: [lldb] Un-xfail test after commit revert

These tests started passing after this PR landed:
https://github.com/llvm/llvm-project/pull/74580

Added: 


Modified: 

lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py

Removed: 




diff  --git 
a/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
 
b/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
index e6325eb18b39f..60e116b422077 100644
--- 
a/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
+++ 
b/lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py
@@ -120,9 +120,6 @@ def check_global_var(self, name: str, expect_type, 
expect_val):
 self.assertEqual(varobj.type.name, expect_type)
 self.assertEqual(varobj.value, expect_val)
 
-# clang doesn't emit static data members without locations into the Names
-# table, preventing LLDB from finding them.
-@expectedFailureAll()
 def test_inline_static_members(self):
 self.build()
 lldbutil.run_to_source_breakpoint(
@@ -170,7 +167,6 @@ def test_class_with_only_constexpr_static(self):
 "ClassWithEnumAlias::enum_alias_alias", 
result_value="scoped_enum_case1"
 )
 
-@expectedFailureAll()
 def test_shadowed_static_inline_members(self):
 """Tests that the expression evaluator and SBAPI can both
 correctly determine the requested inline static variable



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


[Lldb-commits] [lldb] 4db54e6 - [clang][DebugInfo] Revert "emit definitions for constant-initialized static data-members" (#74580)

2023-12-06 Thread via lldb-commits

Author: Michael Buch
Date: 2023-12-06T22:13:54Z
New Revision: 4db54e659763401dbf2e5b1f90e9a3391e311e50

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

LOG: [clang][DebugInfo] Revert "emit definitions for constant-initialized 
static data-members" (#74580)

This commit reverts the changes in
https://github.com/llvm/llvm-project/pull/71780 and all of its follow-up
patches.

We got reports of the `.debug_names/.debug_gnu_pubnames/gdb_index/etc.`
sections growing by a non-trivial amount for some large projects. While
GCC emits definitions for static data member constants into the Names
index, they do so *only* for explicitly `constexpr` members. We were
indexing *all* constant-initialized const-static members, which is
likely where the significant size difference comes from. However, only
emitting explicitly `constexpr` variables into the index doesn't seem
like a good way forward, since from clang's perspective `const`-static
integrals are `constexpr` too, and that shouldn't be any different in
the debug-info component. Also, as new code moves to `constexpr` instead
of `const` static for constants, such solution would just delay the
growth of the Names index.

To prevent the size regression we revert to not emitting definitions for
static data-members that have no location.

To support access to such constants from LLDB we'll most likely have to
have to make LLDB find the constants by looking at the containing class
first.

Added: 


Modified: 
clang/lib/CodeGen/CGDebugInfo.cpp
clang/lib/CodeGen/CGDebugInfo.h
clang/test/CodeGenCXX/debug-info-class.cpp
clang/test/CodeGenCXX/debug-info-static-member.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp
lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h

lldb/test/API/lang/cpp/const_static_integral_member/TestConstStaticIntegralMember.py

Removed: 
clang/test/CodeGenCXX/debug-info-static-inline-member.cpp



diff  --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 602e325e560f9..7cf661994a29c 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -69,29 +69,6 @@ static uint32_t getDeclAlignIfRequired(const Decl *D, const 
ASTContext ) {
   return D->hasAttr() ? D->getMaxAlignment() : 0;
 }
 
-/// Given a VarDecl corresponding to either the definition or
-/// declaration of a C++ static data member, if it has a constant
-/// initializer and is evaluatable, return the evaluated value.
-/// Returns std::nullopt otherwise.
-static std::optional
-evaluateConstantInitializer(const clang::VarDecl *VD,
-const clang::ASTContext ) {
-  assert(VD != nullptr);
-
-  if (!VD->isStaticDataMember())
-return std::nullopt;
-
-  if (!VD->isUsableInConstantExpressions(Ctx))
-return std::nullopt;
-
-  auto const *InitExpr = VD->getAnyInitializer();
-  Expr::EvalResult Result;
-  if (!InitExpr->EvaluateAsConstantExpr(Result, Ctx))
-return std::nullopt;
-
-  return Result.Val;
-}
-
 CGDebugInfo::CGDebugInfo(CodeGenModule )
 : CGM(CGM), DebugKind(CGM.getCodeGenOpts().getDebugInfo()),
   DebugTypeExtRefs(CGM.getCodeGenOpts().DebugTypeExtRefs),
@@ -1724,7 +1701,6 @@ CGDebugInfo::CreateRecordStaticField(const VarDecl *Var, 
llvm::DIType *RecordTy,
   llvm::DIDerivedType *GV = DBuilder.createStaticMemberType(
   RecordTy, VName, VUnit, LineNumber, VTy, Flags, C, Tag, Align);
   StaticDataMemberCache[Var->getCanonicalDecl()].reset(GV);
-  StaticDataMemberDefinitionsToEmit.push_back(Var->getCanonicalDecl());
   return GV;
 }
 
@@ -5628,41 +5604,6 @@ void CGDebugInfo::EmitGlobalVariable(const ValueDecl 
*VD, const APValue ) {
   TemplateParameters, Align));
 }
 
-void CGDebugInfo::EmitGlobalVariable(const VarDecl *VD) {
-  assert(CGM.getCodeGenOpts().hasReducedDebugInfo());
-  if (VD->hasAttr())
-return;
-
-  const auto CacheIt = DeclCache.find(VD);
-  if (CacheIt != DeclCache.end())
-return;
-
-  const auto InitVal = evaluateConstantInitializer(VD, CGM.getContext());
-  if (!InitVal)
-return;
-
-  llvm::DIFile *Unit = nullptr;
-  llvm::DIScope *DContext = nullptr;
-  unsigned LineNo;
-  StringRef DeclName, LinkageName;
-  QualType T;
-  llvm::MDTuple *TemplateParameters = nullptr;
-  collectVarDeclProps(VD, Unit, LineNo, T, DeclName, LinkageName,
-  TemplateParameters, DContext);
-
-  auto Align = getDeclAlignIfRequired(VD, CGM.getContext());
-  llvm::DINodeArray Annotations = CollectBTFDeclTagAnnotations(VD);
-  llvm::DIExpression *InitExpr = createConstantValueExpression(VD, *InitVal);
-
-  // Omit linkage name for variable definitions that represent constants.
-  // There hasn't been a need from consumers yet to have it attached.
-  

[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Revert "emit definitions for constant-initialized static data-members" (PR #74580)

2023-12-06 Thread Michael Buch via lldb-commits

https://github.com/Michael137 closed 
https://github.com/llvm/llvm-project/pull/74580
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Revert "emit definitions for constant-initialized static data-members" (PR #74580)

2023-12-06 Thread Michael Buch via lldb-commits

Michael137 wrote:

> > To support access to such constants from LLDB we'll most likely have to 
> > have to make LLDB find the constants by looking at the containing class 
> > first.
> 
> Tangentially related to: 
> https://discourse.llvm.org/t/rfc-improve-dwarf-5-debug-names-type-lookup-parsing-speed/74151/31?u=dblaikie
> 
> Clang/LLVM do know the difference between type-invariant members and type 
> variant ones (type invariant members are in the `members` list of the 
> `DICompositeType` and variant members have a `scope` that refers to the type 
> but don't appear in the `members` list) - would it be reasonable to not 
> include the invariant members in the accelerator table, but only include the 
> variant ones? Invariant ones can be found by finding any instance of the type 
> in the index, then looking at its members - and for variant members it'd be 
> useful to have them in the index. (though, honestly, I'm not sure how lldb 
> and gdb handle that situation - last time I tested it with gdb, it just saw 
> two different copies of the type and didn't try to unify/aggregate all the 
> variant members... but lldb only creates one copy of the type, so don't know 
> what it does if you've got, say, two member function template instantiations 
> for different template parameters in two different translation units/compile 
> units)

I'll merge the PR for now to unblock and address this later

https://github.com/llvm/llvm-project/pull/74580
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Revert "emit definitions for constant-initialized static data-members" (PR #74580)

2023-12-06 Thread Martin Storsjö via lldb-commits

mstorsjo wrote:

Could we please land this now?

https://github.com/llvm/llvm-project/pull/74580
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Revert "emit definitions for constant-initialized static data-members" (PR #74580)

2023-12-06 Thread David Blaikie via lldb-commits

dwblaikie wrote:

> To support access to such constants from LLDB we'll most likely have to have 
> to make LLDB find the constants by looking at the containing class first.

Tangentially related to: 
https://discourse.llvm.org/t/rfc-improve-dwarf-5-debug-names-type-lookup-parsing-speed/74151/31?u=dblaikie

Clang/LLVM do know the difference between type-invariant members and type 
variant ones (type invariant members are in  the `members` list of the 
`DICompositeType` and variant members have a `scope` that refers to the type 
but don't appear in the `members` list) - would it be reasonable to not include 
the invariant members in the accelerator table, but only include the variant 
ones? Invariant ones can be found by finding any instance of the type in the 
index, then looking at its members - and for variant members it'd be useful to 
have them in the index. (though, honestly, I'm not sure how lldb and gdb handle 
that situation - last time I tested it with gdb, it just saw two different 
copies of the type and didn't try to unify/aggregate all the variant members... 
but lldb only creates one copy of the type, so don't know what it does if 
you've got, say, two member function template instantiations for different 
template parameters in two different translation units/compile units)

https://github.com/llvm/llvm-project/pull/74580
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [compiler-rt] [lldb] [libc] [clang] [lld] [mlir] [llvm] [libcxxabi] [clang-tools-extra] [flang] [libcxx] [llvm] Support IFuncs on Darwin platforms (PR #73686)

2023-12-06 Thread Jon Roelofs via lldb-commits

https://github.com/jroelofs updated 
https://github.com/llvm/llvm-project/pull/73686

>From bc152095691b32d1ad8539dfd60f5089df5eed8d Mon Sep 17 00:00:00 2001
From: Jon Roelofs 
Date: Tue, 28 Nov 2023 10:39:44 -0800
Subject: [PATCH 1/9] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20in?=
 =?UTF-8?q?itial=20version?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Created using spr 1.3.4
---
 llvm/docs/LangRef.rst |   7 +-
 llvm/include/llvm/CodeGen/AsmPrinter.h|   6 +-
 llvm/lib/CodeGen/GlobalISel/CallLowering.cpp  |   7 +-
 llvm/lib/IR/Verifier.cpp  |  12 +-
 llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp | 308 ++
 llvm/lib/Target/X86/X86AsmPrinter.cpp |  28 ++
 llvm/lib/Target/X86/X86AsmPrinter.h   |   1 +
 .../AArch64/GlobalISel/call-lowering-ifunc.ll |  37 +++
 llvm/test/CodeGen/AArch64/addrsig-macho.ll|   4 +-
 llvm/test/CodeGen/AArch64/ifunc-asm.ll|  82 +
 llvm/test/CodeGen/X86/ifunc-asm.ll|  28 +-
 llvm/test/Verifier/ifunc-macho.ll |  42 +++
 12 files changed, 539 insertions(+), 23 deletions(-)
 create mode 100644 llvm/test/CodeGen/AArch64/GlobalISel/call-lowering-ifunc.ll
 create mode 100644 llvm/test/CodeGen/AArch64/ifunc-asm.ll
 create mode 100644 llvm/test/Verifier/ifunc-macho.ll

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index e448c5ed5c5d9..cb222e979db29 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -934,10 +934,11 @@ IFuncs
 ---
 
 IFuncs, like as aliases, don't create any new data or func. They are just a new
-symbol that dynamic linker resolves at runtime by calling a resolver function.
+symbol that is resolved at runtime by calling a resolver function.
 
-IFuncs have a name and a resolver that is a function called by dynamic linker
-that returns address of another function associated with the name.
+On ELF platforms, IFuncs are resolved by the dynamic linker at load time. On
+MachO platforms, they are lowered in terms of ``.symbol_resolver``s, which
+lazily resolve the callee the first time they are called.
 
 IFunc may have an optional :ref:`linkage type ` and an optional
 :ref:`visibility style `.
diff --git a/llvm/include/llvm/CodeGen/AsmPrinter.h 
b/llvm/include/llvm/CodeGen/AsmPrinter.h
index 2731ef452c79c..48fa6c478464c 100644
--- a/llvm/include/llvm/CodeGen/AsmPrinter.h
+++ b/llvm/include/llvm/CodeGen/AsmPrinter.h
@@ -882,7 +882,11 @@ class AsmPrinter : public MachineFunctionPass {
 
   GCMetadataPrinter *getOrCreateGCPrinter(GCStrategy );
   void emitGlobalAlias(Module , const GlobalAlias );
-  void emitGlobalIFunc(Module , const GlobalIFunc );
+
+protected:
+  virtual void emitGlobalIFunc(Module , const GlobalIFunc );
+
+private:
 
   /// This method decides whether the specified basic block requires a label.
   bool shouldEmitLabelForBasicBlock(const MachineBasicBlock ) const;
diff --git a/llvm/lib/CodeGen/GlobalISel/CallLowering.cpp 
b/llvm/lib/CodeGen/GlobalISel/CallLowering.cpp
index 2527b14312896..e0080b145d4f9 100644
--- a/llvm/lib/CodeGen/GlobalISel/CallLowering.cpp
+++ b/llvm/lib/CodeGen/GlobalISel/CallLowering.cpp
@@ -144,7 +144,12 @@ bool CallLowering::lowerCall(MachineIRBuilder , 
const CallBase ,
   // Try looking through a bitcast from one function type to another.
   // Commonly happens with calls to objc_msgSend().
   const Value *CalleeV = CB.getCalledOperand()->stripPointerCasts();
-  if (const Function *F = dyn_cast(CalleeV))
+  if (const GlobalIFunc *IF = dyn_cast(CalleeV);
+  IF && MF.getTarget().getTargetTriple().isOSBinFormatMachO()) {
+// ld64 requires that .symbol_resolvers to be called via a stub, so these
+// must always be a diret call.
+Info.Callee = MachineOperand::CreateGA(IF, 0);
+  } else if (const Function *F = dyn_cast(CalleeV))
 Info.Callee = MachineOperand::CreateGA(F, 0);
   else
 Info.Callee = MachineOperand::CreateReg(GetCalleeReg(), false);
diff --git a/llvm/lib/IR/Verifier.cpp b/llvm/lib/IR/Verifier.cpp
index 5560c037aa3ee..94e76a43bf38d 100644
--- a/llvm/lib/IR/Verifier.cpp
+++ b/llvm/lib/IR/Verifier.cpp
@@ -959,6 +959,7 @@ void Verifier::visitGlobalIFunc(const GlobalIFunc ) {
   GlobalIFunc::getResolverFunctionType(GI.getValueType());
   Check(ResolverTy == ResolverFuncTy->getPointerTo(GI.getAddressSpace()),
 "IFunc resolver has incorrect type", );
+
 }
 
 void Verifier::visitNamedMDNode(const NamedMDNode ) {
@@ -2239,13 +2240,10 @@ void Verifier::verifyFunctionAttrs(FunctionType *FT, 
AttributeList Attrs,
   }
 
   // Check EVEX512 feature.
-  if (MaxParameterWidth >= 512 && Attrs.hasFnAttr("target-features")) {
-Triple T(M.getTargetTriple());
-if (T.isX86()) {
-  StringRef TF = Attrs.getFnAttr("target-features").getValueAsString();
-  Check(!TF.contains("+avx512f") || !TF.contains("-evex512"),
-"512-bit vector arguments require 'evex512' for AVX512", V);
-}
+  

[Lldb-commits] [libc] [lld] [libcxxabi] [clang-tools-extra] [llvm] [clang] [flang] [compiler-rt] [lldb] [libcxx] [mlir] [llvm] Support IFuncs on Darwin platforms (PR #73686)

2023-12-06 Thread Jon Roelofs via lldb-commits

https://github.com/jroelofs updated 
https://github.com/llvm/llvm-project/pull/73686

>From bc152095691b32d1ad8539dfd60f5089df5eed8d Mon Sep 17 00:00:00 2001
From: Jon Roelofs 
Date: Tue, 28 Nov 2023 10:39:44 -0800
Subject: [PATCH 1/9] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20in?=
 =?UTF-8?q?itial=20version?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Created using spr 1.3.4
---
 llvm/docs/LangRef.rst |   7 +-
 llvm/include/llvm/CodeGen/AsmPrinter.h|   6 +-
 llvm/lib/CodeGen/GlobalISel/CallLowering.cpp  |   7 +-
 llvm/lib/IR/Verifier.cpp  |  12 +-
 llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp | 308 ++
 llvm/lib/Target/X86/X86AsmPrinter.cpp |  28 ++
 llvm/lib/Target/X86/X86AsmPrinter.h   |   1 +
 .../AArch64/GlobalISel/call-lowering-ifunc.ll |  37 +++
 llvm/test/CodeGen/AArch64/addrsig-macho.ll|   4 +-
 llvm/test/CodeGen/AArch64/ifunc-asm.ll|  82 +
 llvm/test/CodeGen/X86/ifunc-asm.ll|  28 +-
 llvm/test/Verifier/ifunc-macho.ll |  42 +++
 12 files changed, 539 insertions(+), 23 deletions(-)
 create mode 100644 llvm/test/CodeGen/AArch64/GlobalISel/call-lowering-ifunc.ll
 create mode 100644 llvm/test/CodeGen/AArch64/ifunc-asm.ll
 create mode 100644 llvm/test/Verifier/ifunc-macho.ll

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index e448c5ed5c5d9..cb222e979db29 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -934,10 +934,11 @@ IFuncs
 ---
 
 IFuncs, like as aliases, don't create any new data or func. They are just a new
-symbol that dynamic linker resolves at runtime by calling a resolver function.
+symbol that is resolved at runtime by calling a resolver function.
 
-IFuncs have a name and a resolver that is a function called by dynamic linker
-that returns address of another function associated with the name.
+On ELF platforms, IFuncs are resolved by the dynamic linker at load time. On
+MachO platforms, they are lowered in terms of ``.symbol_resolver``s, which
+lazily resolve the callee the first time they are called.
 
 IFunc may have an optional :ref:`linkage type ` and an optional
 :ref:`visibility style `.
diff --git a/llvm/include/llvm/CodeGen/AsmPrinter.h 
b/llvm/include/llvm/CodeGen/AsmPrinter.h
index 2731ef452c79c..48fa6c478464c 100644
--- a/llvm/include/llvm/CodeGen/AsmPrinter.h
+++ b/llvm/include/llvm/CodeGen/AsmPrinter.h
@@ -882,7 +882,11 @@ class AsmPrinter : public MachineFunctionPass {
 
   GCMetadataPrinter *getOrCreateGCPrinter(GCStrategy );
   void emitGlobalAlias(Module , const GlobalAlias );
-  void emitGlobalIFunc(Module , const GlobalIFunc );
+
+protected:
+  virtual void emitGlobalIFunc(Module , const GlobalIFunc );
+
+private:
 
   /// This method decides whether the specified basic block requires a label.
   bool shouldEmitLabelForBasicBlock(const MachineBasicBlock ) const;
diff --git a/llvm/lib/CodeGen/GlobalISel/CallLowering.cpp 
b/llvm/lib/CodeGen/GlobalISel/CallLowering.cpp
index 2527b14312896..e0080b145d4f9 100644
--- a/llvm/lib/CodeGen/GlobalISel/CallLowering.cpp
+++ b/llvm/lib/CodeGen/GlobalISel/CallLowering.cpp
@@ -144,7 +144,12 @@ bool CallLowering::lowerCall(MachineIRBuilder , 
const CallBase ,
   // Try looking through a bitcast from one function type to another.
   // Commonly happens with calls to objc_msgSend().
   const Value *CalleeV = CB.getCalledOperand()->stripPointerCasts();
-  if (const Function *F = dyn_cast(CalleeV))
+  if (const GlobalIFunc *IF = dyn_cast(CalleeV);
+  IF && MF.getTarget().getTargetTriple().isOSBinFormatMachO()) {
+// ld64 requires that .symbol_resolvers to be called via a stub, so these
+// must always be a diret call.
+Info.Callee = MachineOperand::CreateGA(IF, 0);
+  } else if (const Function *F = dyn_cast(CalleeV))
 Info.Callee = MachineOperand::CreateGA(F, 0);
   else
 Info.Callee = MachineOperand::CreateReg(GetCalleeReg(), false);
diff --git a/llvm/lib/IR/Verifier.cpp b/llvm/lib/IR/Verifier.cpp
index 5560c037aa3ee..94e76a43bf38d 100644
--- a/llvm/lib/IR/Verifier.cpp
+++ b/llvm/lib/IR/Verifier.cpp
@@ -959,6 +959,7 @@ void Verifier::visitGlobalIFunc(const GlobalIFunc ) {
   GlobalIFunc::getResolverFunctionType(GI.getValueType());
   Check(ResolverTy == ResolverFuncTy->getPointerTo(GI.getAddressSpace()),
 "IFunc resolver has incorrect type", );
+
 }
 
 void Verifier::visitNamedMDNode(const NamedMDNode ) {
@@ -2239,13 +2240,10 @@ void Verifier::verifyFunctionAttrs(FunctionType *FT, 
AttributeList Attrs,
   }
 
   // Check EVEX512 feature.
-  if (MaxParameterWidth >= 512 && Attrs.hasFnAttr("target-features")) {
-Triple T(M.getTargetTriple());
-if (T.isX86()) {
-  StringRef TF = Attrs.getFnAttr("target-features").getValueAsString();
-  Check(!TF.contains("+avx512f") || !TF.contains("-evex512"),
-"512-bit vector arguments require 'evex512' for AVX512", V);
-}
+  

[Lldb-commits] [lldb] [libunwind] [clang] [mlir] [libcxx] [clang-tools-extra] [libcxxabi] [lld] [libc] [openmp] [llvm] [flang] [Clang][Sema] Don't say "is declared here" for invalid template locations

2023-12-06 Thread Erich Keane via lldb-commits

https://github.com/erichkeane approved this pull request.

I think this is a very positive change, and see nothing besides Aaron's nit to 
comment on.  Thanks!

https://github.com/llvm/llvm-project/pull/71264
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [llvm] [lldb] [mlir] [libcxx] [openmp] [flang] [libcxxabi] [compiler-rt] [clang] [AMDGPU] Add GFX12 encoding for VINTERP instructions (PR #74616)

2023-12-06 Thread Jay Foad via lldb-commits

https://github.com/jayfoad updated 
https://github.com/llvm/llvm-project/pull/74616

>From 69580e5f77514fecf0aabe2a80c98881f9bd7288 Mon Sep 17 00:00:00 2001
From: Jay Foad 
Date: Tue, 7 Feb 2023 16:27:27 +
Subject: [PATCH 1/2] [AMDGPU] Add GFX12 encoding for VINTERP instructions

---
 .../Disassembler/AMDGPUDisassembler.cpp   |   6 +-
 llvm/lib/Target/AMDGPU/VINTERPInstructions.td |  38 ++-
 llvm/test/MC/AMDGPU/gfx11_asm_vinterp.s   | 187 ++---
 .../AMDGPU/gfx12_dasm_vinterp.txt | 251 ++
 4 files changed, 378 insertions(+), 104 deletions(-)
 create mode 100644 llvm/test/MC/Disassembler/AMDGPU/gfx12_dasm_vinterp.txt

diff --git a/llvm/lib/Target/AMDGPU/Disassembler/AMDGPUDisassembler.cpp 
b/llvm/lib/Target/AMDGPU/Disassembler/AMDGPUDisassembler.cpp
index 3175f6358a045..c37af739e2019 100644
--- a/llvm/lib/Target/AMDGPU/Disassembler/AMDGPUDisassembler.cpp
+++ b/llvm/lib/Target/AMDGPU/Disassembler/AMDGPUDisassembler.cpp
@@ -782,9 +782,13 @@ DecodeStatus AMDGPUDisassembler::convertEXPInst(MCInst 
) const {
 
 DecodeStatus AMDGPUDisassembler::convertVINTERPInst(MCInst ) const {
   if (MI.getOpcode() == AMDGPU::V_INTERP_P10_F16_F32_inreg_gfx11 ||
+  MI.getOpcode() == AMDGPU::V_INTERP_P10_F16_F32_inreg_gfx12 ||
   MI.getOpcode() == AMDGPU::V_INTERP_P10_RTZ_F16_F32_inreg_gfx11 ||
+  MI.getOpcode() == AMDGPU::V_INTERP_P10_RTZ_F16_F32_inreg_gfx12 ||
   MI.getOpcode() == AMDGPU::V_INTERP_P2_F16_F32_inreg_gfx11 ||
-  MI.getOpcode() == AMDGPU::V_INTERP_P2_RTZ_F16_F32_inreg_gfx11) {
+  MI.getOpcode() == AMDGPU::V_INTERP_P2_F16_F32_inreg_gfx12 ||
+  MI.getOpcode() == AMDGPU::V_INTERP_P2_RTZ_F16_F32_inreg_gfx11 ||
+  MI.getOpcode() == AMDGPU::V_INTERP_P2_RTZ_F16_F32_inreg_gfx12) {
 // The MCInst has this field that is not directly encoded in the
 // instruction.
 insertNamedMCOperand(MI, MCOperand::createImm(0), AMDGPU::OpName::op_sel);
diff --git a/llvm/lib/Target/AMDGPU/VINTERPInstructions.td 
b/llvm/lib/Target/AMDGPU/VINTERPInstructions.td
index 7d03150bf5b11..fc563b7493adf 100644
--- a/llvm/lib/Target/AMDGPU/VINTERPInstructions.td
+++ b/llvm/lib/Target/AMDGPU/VINTERPInstructions.td
@@ -10,7 +10,7 @@
 // VINTERP encoding
 
//===--===//
 
-class VINTERPe_gfx11  op, VOPProfile P> : Enc64 {
+class VINTERPe  : Enc64 {
   bits<8> vdst;
   bits<4> src0_modifiers;
   bits<9> src0;
@@ -31,7 +31,6 @@ class VINTERPe_gfx11  op, VOPProfile P> : Enc64 {
   let Inst{13}= !if(P.HasOpSel, src2_modifiers{2}, 0); // op_sel(2)
   let Inst{14}= !if(P.HasOpSel, src0_modifiers{3}, 0); // op_sel(3)
   let Inst{15}= clamp;
-  let Inst{22-16} = op;
   let Inst{40-32} = src0;
   let Inst{49-41} = src1;
   let Inst{58-50} = src2;
@@ -40,6 +39,14 @@ class VINTERPe_gfx11  op, VOPProfile P> : Enc64 {
   let Inst{63}= src2_modifiers{0}; // neg(2)
 }
 
+class VINTERPe_gfx11  op, VOPProfile P> : VINTERPe {
+  let Inst{22-16} = op;
+}
+
+class VINTERPe_gfx12  op, VOPProfile P> : VINTERPe {
+  let Inst{20-16} = op{4-0};
+}
+
 
//===--===//
 // VOP3 VINTERP
 
//===--===//
@@ -171,17 +178,28 @@ defm : VInterpF16Pat op> {
+multiclass VINTERP_Real_gfx11  op> {
+  let AssemblerPredicate = isGFX11Only, DecoderNamespace = "GFX11" in {
 def _gfx11 :
   VINTERP_Real(NAME), SIEncodingFamily.GFX11>,
   VINTERPe_gfx11(NAME).Pfl>;
   }
 }
 
-defm V_INTERP_P10_F32_inreg  : VINTERP_Real_gfx11<0x000>;
-defm V_INTERP_P2_F32_inreg  : VINTERP_Real_gfx11<0x001>;
-defm V_INTERP_P10_F16_F32_inreg  : VINTERP_Real_gfx11<0x002>;
-defm V_INTERP_P2_F16_F32_inreg  : VINTERP_Real_gfx11<0x003>;
-defm V_INTERP_P10_RTZ_F16_F32_inreg  : VINTERP_Real_gfx11<0x004>;
-defm V_INTERP_P2_RTZ_F16_F32_inreg  : VINTERP_Real_gfx11<0x005>;
+multiclass VINTERP_Real_gfx12  op> {
+  let AssemblerPredicate = isGFX12Only, DecoderNamespace = "GFX12" in {
+def _gfx12 :
+  VINTERP_Real(NAME), SIEncodingFamily.GFX12>,
+  VINTERPe_gfx12(NAME).Pfl>;
+  }
+}
+
+multiclass VINTERP_Real_gfx11_gfx12  op> :
+  VINTERP_Real_gfx11, VINTERP_Real_gfx12;
+
+defm V_INTERP_P10_F32_inreg : VINTERP_Real_gfx11_gfx12<0x000>;
+defm V_INTERP_P2_F32_inreg : VINTERP_Real_gfx11_gfx12<0x001>;
+defm V_INTERP_P10_F16_F32_inreg : VINTERP_Real_gfx11_gfx12<0x002>;
+defm V_INTERP_P2_F16_F32_inreg : VINTERP_Real_gfx11_gfx12<0x003>;
+defm V_INTERP_P10_RTZ_F16_F32_inreg : VINTERP_Real_gfx11_gfx12<0x004>;
+defm V_INTERP_P2_RTZ_F16_F32_inreg : VINTERP_Real_gfx11_gfx12<0x005>;
diff --git a/llvm/test/MC/AMDGPU/gfx11_asm_vinterp.s 
b/llvm/test/MC/AMDGPU/gfx11_asm_vinterp.s
index e2e53776783f3..fdfbf65c0e3cf 100644
--- a/llvm/test/MC/AMDGPU/gfx11_asm_vinterp.s
+++ b/llvm/test/MC/AMDGPU/gfx11_asm_vinterp.s
@@ -1,277 +1,278 @@
-// RUN: llvm-mc -triple=amdgcn -mcpu=gfx1100 -show-encoding %s | FileCheck 

[Lldb-commits] [llvm] [libcxxabi] [lld] [clang-tools-extra] [clang] [openmp] [libc] [libcxx] [libunwind] [lldb] [mlir] [flang] [Clang][Sema] Don't say "is declared here" for invalid template locations

2023-12-06 Thread Aaron Ballman via lldb-commits


@@ -898,8 +895,9 @@ void Sema::DiagnoseTemplateParameterShadow(SourceLocation 
Loc, Decl *PrevDecl) {
   // Make this a warning when MSVC compatibility is requested.
   unsigned DiagId = getLangOpts().MSVCCompat ? diag::ext_template_param_shadow
  : diag::err_template_param_shadow;
-  Diag(Loc, DiagId) << cast(PrevDecl)->getDeclName();
-  Diag(PrevDecl->getLocation(), diag::note_template_param_here);
+  NamedDecl *ND = cast(PrevDecl);

AaronBallman wrote:

```suggestion
  const auto *ND = cast(PrevDecl);
```

https://github.com/llvm/llvm-project/pull/71264
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [llvm] [lldb] [mlir] [libc] [libcxx] [openmp] [libunwind] [clang-tools-extra] [flang] [libcxxabi] [lld] [clang] [Clang][Sema] Don't say "is declared here" for invalid template locations

2023-12-06 Thread Aaron Ballman via lldb-commits

https://github.com/AaronBallman approved this pull request.

I like the behavior of this and the changes LGTM, but please give @ErichKeane a 
chance to weigh in as templates code owner before landing.

https://github.com/llvm/llvm-project/pull/71264
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [libcxxabi] [libc] [mlir] [clang] [libunwind] [libcxx] [clang-tools-extra] [openmp] [lldb] [lld] [llvm] [flang] [Clang][Sema] Don't say "is declared here" for invalid template locations

2023-12-06 Thread Aaron Ballman via lldb-commits

https://github.com/AaronBallman edited 
https://github.com/llvm/llvm-project/pull/71264
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [libcxxabi] [compiler-rt] [libunwind] [clang-tools-extra] [lldb] [libcxx] [clang] [lld] [libc] [flang] [mlir] [llvm] [libc++] Implement ranges::contains (PR #65148)

2023-12-06 Thread via lldb-commits

https://github.com/ZijunZhaoCCK updated 
https://github.com/llvm/llvm-project/pull/65148

>From 02e9afd761228f401df4d9f8dfaaca44ffae0c6e Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Thu, 31 Aug 2023 20:08:32 +
Subject: [PATCH 01/18] [libc++] Implement ranges::contains

Differential Revision: https://reviews.llvm.org/D159232
---
 libcxx/include/CMakeLists.txt |   1 +
 libcxx/include/__algorithm/ranges_contains.h  |  60 ++
 libcxx/include/algorithm  |   9 +
 ...obust_against_copying_projections.pass.cpp |   4 +
 .../alg.contains/ranges.contains.pass.cpp | 190 ++
 .../niebloid.compile.pass.cpp |   1 +
 6 files changed, 265 insertions(+)
 create mode 100644 libcxx/include/__algorithm/ranges_contains.h
 create mode 100644 
libcxx/test/std/algorithms/alg.nonmodifying/alg.contains/ranges.contains.pass.cpp

diff --git a/libcxx/include/CMakeLists.txt b/libcxx/include/CMakeLists.txt
index 77a7269121ec1..024aa8959fb72 100644
--- a/libcxx/include/CMakeLists.txt
+++ b/libcxx/include/CMakeLists.txt
@@ -104,6 +104,7 @@ set(files
   __algorithm/ranges_any_of.h
   __algorithm/ranges_binary_search.h
   __algorithm/ranges_clamp.h
+  __algorithm/ranges_contains.h
   __algorithm/ranges_copy.h
   __algorithm/ranges_copy_backward.h
   __algorithm/ranges_copy_if.h
diff --git a/libcxx/include/__algorithm/ranges_contains.h 
b/libcxx/include/__algorithm/ranges_contains.h
new file mode 100644
index 0..647b7ea34be34
--- /dev/null
+++ b/libcxx/include/__algorithm/ranges_contains.h
@@ -0,0 +1,60 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
+#define _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
+
+#include <__algorithm/in_in_result.h>
+#include <__algorithm/ranges_find.h>
+#include <__config>
+#include <__functional/identity.h>
+#include <__functional/ranges_operations.h>
+#include <__functional/reference_wrapper.h>
+#include <__iterator/concepts.h>
+#include <__iterator/indirectly_comparable.h>
+#include <__iterator/projected.h>
+#include <__ranges/access.h>
+#include <__ranges/concepts.h>
+#include <__utility/move.h>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+
+#if _LIBCPP_STD_VER >= 23
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+namespace ranges {
+namespace __contains {
+struct __fn {
+  template  _Sent, class _Type, 
class _Proj = identity>
+requires indirect_binary_predicate, const _Type*>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool
+  operator()(_Iter __first, _Sent __last, const _Type& __value, _Proj __proj = 
{}) const {
+return ranges::find(std::move(__first), std::move(__last), __value, 
std::ref(__proj)) != __last;
+  }
+
+  template 
+requires indirect_binary_predicate, _Proj>, const _Type*>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool
+  operator()(_Range&& __range, const _Type& __value, _Proj __proj = {}) const {
+return ranges::find(ranges::begin(__range), ranges::end(__range), __value, 
std::ref(__proj)) != ranges::end(__range);
+  }
+};
+} // namespace __contains
+inline namespace __cpo {
+inline constexpr auto contains = __contains::__fn{};
+} // namespace __cpo
+} // namespace ranges
+
+_LIBCPP_END_NAMESPACE_STD
+
+#endif // _LIBCPP_STD_VER >= 23
+
+#endif // _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
diff --git a/libcxx/include/algorithm b/libcxx/include/algorithm
index 76e0d22bf73ef..003bf132b38b4 100644
--- a/libcxx/include/algorithm
+++ b/libcxx/include/algorithm
@@ -226,6 +226,14 @@ namespace ranges {
   template
 using copy_backward_result = in_out_result;
 // since C++20
 
+  template S, class T, class Proj = identity>
+requires indirect_binary_predicate, 
const T*>
+constexpr bool ranges::contains(I first, S last, const T& value, Proj proj 
= {});   // since C++23
+
+  template
+requires indirect_binary_predicate, Proj>, const T*>
+constexpr bool ranges::contains(R&& r, const T& value, Proj proj = {});
 // since C++23
+
   template S, weakly_incrementable O>
 requires indirectly_copyable
 constexpr ranges::copy_result ranges::copy(I first, S last, O 
result);// since C++20
@@ -1827,6 +1835,7 @@ template 
 #include <__algorithm/ranges_any_of.h>
 #include <__algorithm/ranges_binary_search.h>
 #include <__algorithm/ranges_clamp.h>
+#include <__algorithm/ranges_contains.h>
 #include <__algorithm/ranges_copy.h>
 #include <__algorithm/ranges_copy_backward.h>
 #include <__algorithm/ranges_copy_if.h>
diff --git 

[Lldb-commits] [clang] [flang] [libunwind] [libcxxabi] [lld] [clang-tools-extra] [libc] [lldb] [mlir] [libcxx] [compiler-rt] [llvm] [libc++] Implement ranges::contains (PR #65148)

2023-12-06 Thread via lldb-commits

https://github.com/ZijunZhaoCCK updated 
https://github.com/llvm/llvm-project/pull/65148

>From 02e9afd761228f401df4d9f8dfaaca44ffae0c6e Mon Sep 17 00:00:00 2001
From: zijunzhao 
Date: Thu, 31 Aug 2023 20:08:32 +
Subject: [PATCH 01/17] [libc++] Implement ranges::contains

Differential Revision: https://reviews.llvm.org/D159232
---
 libcxx/include/CMakeLists.txt |   1 +
 libcxx/include/__algorithm/ranges_contains.h  |  60 ++
 libcxx/include/algorithm  |   9 +
 ...obust_against_copying_projections.pass.cpp |   4 +
 .../alg.contains/ranges.contains.pass.cpp | 190 ++
 .../niebloid.compile.pass.cpp |   1 +
 6 files changed, 265 insertions(+)
 create mode 100644 libcxx/include/__algorithm/ranges_contains.h
 create mode 100644 
libcxx/test/std/algorithms/alg.nonmodifying/alg.contains/ranges.contains.pass.cpp

diff --git a/libcxx/include/CMakeLists.txt b/libcxx/include/CMakeLists.txt
index 77a7269121ec1..024aa8959fb72 100644
--- a/libcxx/include/CMakeLists.txt
+++ b/libcxx/include/CMakeLists.txt
@@ -104,6 +104,7 @@ set(files
   __algorithm/ranges_any_of.h
   __algorithm/ranges_binary_search.h
   __algorithm/ranges_clamp.h
+  __algorithm/ranges_contains.h
   __algorithm/ranges_copy.h
   __algorithm/ranges_copy_backward.h
   __algorithm/ranges_copy_if.h
diff --git a/libcxx/include/__algorithm/ranges_contains.h 
b/libcxx/include/__algorithm/ranges_contains.h
new file mode 100644
index 0..647b7ea34be34
--- /dev/null
+++ b/libcxx/include/__algorithm/ranges_contains.h
@@ -0,0 +1,60 @@
+//===--===//
+//
+// Part of the LLVM Project, under the Apache License v2.0 with LLVM 
Exceptions.
+// See https://llvm.org/LICENSE.txt for license information.
+// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception
+//
+//===--===//
+
+#ifndef _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
+#define _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
+
+#include <__algorithm/in_in_result.h>
+#include <__algorithm/ranges_find.h>
+#include <__config>
+#include <__functional/identity.h>
+#include <__functional/ranges_operations.h>
+#include <__functional/reference_wrapper.h>
+#include <__iterator/concepts.h>
+#include <__iterator/indirectly_comparable.h>
+#include <__iterator/projected.h>
+#include <__ranges/access.h>
+#include <__ranges/concepts.h>
+#include <__utility/move.h>
+
+#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
+#  pragma GCC system_header
+#endif
+
+#if _LIBCPP_STD_VER >= 23
+
+_LIBCPP_BEGIN_NAMESPACE_STD
+
+namespace ranges {
+namespace __contains {
+struct __fn {
+  template  _Sent, class _Type, 
class _Proj = identity>
+requires indirect_binary_predicate, const _Type*>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool
+  operator()(_Iter __first, _Sent __last, const _Type& __value, _Proj __proj = 
{}) const {
+return ranges::find(std::move(__first), std::move(__last), __value, 
std::ref(__proj)) != __last;
+  }
+
+  template 
+requires indirect_binary_predicate, _Proj>, const _Type*>
+  _LIBCPP_NODISCARD_EXT _LIBCPP_HIDE_FROM_ABI constexpr bool
+  operator()(_Range&& __range, const _Type& __value, _Proj __proj = {}) const {
+return ranges::find(ranges::begin(__range), ranges::end(__range), __value, 
std::ref(__proj)) != ranges::end(__range);
+  }
+};
+} // namespace __contains
+inline namespace __cpo {
+inline constexpr auto contains = __contains::__fn{};
+} // namespace __cpo
+} // namespace ranges
+
+_LIBCPP_END_NAMESPACE_STD
+
+#endif // _LIBCPP_STD_VER >= 23
+
+#endif // _LIBCPP___ALGORITHM_RANGES_CONTAINS_H
diff --git a/libcxx/include/algorithm b/libcxx/include/algorithm
index 76e0d22bf73ef..003bf132b38b4 100644
--- a/libcxx/include/algorithm
+++ b/libcxx/include/algorithm
@@ -226,6 +226,14 @@ namespace ranges {
   template
 using copy_backward_result = in_out_result;
 // since C++20
 
+  template S, class T, class Proj = identity>
+requires indirect_binary_predicate, 
const T*>
+constexpr bool ranges::contains(I first, S last, const T& value, Proj proj 
= {});   // since C++23
+
+  template
+requires indirect_binary_predicate, Proj>, const T*>
+constexpr bool ranges::contains(R&& r, const T& value, Proj proj = {});
 // since C++23
+
   template S, weakly_incrementable O>
 requires indirectly_copyable
 constexpr ranges::copy_result ranges::copy(I first, S last, O 
result);// since C++20
@@ -1827,6 +1835,7 @@ template 
 #include <__algorithm/ranges_any_of.h>
 #include <__algorithm/ranges_binary_search.h>
 #include <__algorithm/ranges_clamp.h>
+#include <__algorithm/ranges_contains.h>
 #include <__algorithm/ranges_copy.h>
 #include <__algorithm/ranges_copy_backward.h>
 #include <__algorithm/ranges_copy_if.h>
diff --git 

[Lldb-commits] [libcxx] [mlir] [clang-tools-extra] [lld] [libc] [openmp] [flang] [compiler-rt] [llvm] [clang] [lldb] [MLIR] Enable GPU Dialect to SYCL runtime integration (PR #71430)

2023-12-06 Thread Fabian Mora via lldb-commits


@@ -0,0 +1,31 @@
+//===- SPIRVToLLVMIRTranslation.cpp - Translate SPIRV to LLVM IR 
--===//
+//
+// 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 implements a translation between the MLIR SPIRV dialect and
+// LLVM IR.
+//
+//===--===//
+
+#include "mlir/Target/LLVMIR/Dialect/SPIRV/SPIRVToLLVMIRTranslation.h"
+#include "mlir/Dialect/SPIRV/IR/SPIRVDialect.h"
+#include "mlir/IR/BuiltinAttributes.h"
+#include "mlir/IR/Operation.h"
+#include "mlir/Target/LLVMIR/ModuleTranslation.h"
+
+using namespace mlir;
+using namespace mlir::LLVM;
+
+void mlir::registerSPIRVDialectTranslation(DialectRegistry ) {
+  registry.insert();

fabianmcg wrote:

I'm sorry I missed these. I had the same concern, the alternative was adding an 
inline registration call. However, I then realized that adding `#include 
"mlir/Dialect/SPIRV/IR/SPIRVDialect.h"` to `mlir/Target/LLVMIR/Dialect/All.h` 
was needed , which seemed even more undesirable thus I changed my mind and 
agreed on the current scheme. 
One way to clean it, is removing inline function from 
`mlir/Target/LLVMIR/Dialect/All.h` and creating a `MLIRToLLVMIR` library.

https://github.com/llvm/llvm-project/pull/71430
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] Correctly check and report error states in StackFrame.cpp (PR #74414)

2023-12-06 Thread Adrian Prantl via lldb-commits

https://github.com/adrian-prantl approved this pull request.


https://github.com/llvm/llvm-project/pull/74414
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [compiler-rt] [lldb] [libcxxabi] [clang-tools-extra] [libcxx] [mlir] [libc] [llvm] [clang] [lld] [flang] [llvm] Support IFuncs on Darwin platforms (PR #73686)

2023-12-06 Thread Jon Roelofs via lldb-commits

https://github.com/jroelofs updated 
https://github.com/llvm/llvm-project/pull/73686

>From bc152095691b32d1ad8539dfd60f5089df5eed8d Mon Sep 17 00:00:00 2001
From: Jon Roelofs 
Date: Tue, 28 Nov 2023 10:39:44 -0800
Subject: [PATCH 1/9] =?UTF-8?q?[=F0=9D=98=80=F0=9D=97=BD=F0=9D=97=BF]=20in?=
 =?UTF-8?q?itial=20version?=
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

Created using spr 1.3.4
---
 llvm/docs/LangRef.rst |   7 +-
 llvm/include/llvm/CodeGen/AsmPrinter.h|   6 +-
 llvm/lib/CodeGen/GlobalISel/CallLowering.cpp  |   7 +-
 llvm/lib/IR/Verifier.cpp  |  12 +-
 llvm/lib/Target/AArch64/AArch64AsmPrinter.cpp | 308 ++
 llvm/lib/Target/X86/X86AsmPrinter.cpp |  28 ++
 llvm/lib/Target/X86/X86AsmPrinter.h   |   1 +
 .../AArch64/GlobalISel/call-lowering-ifunc.ll |  37 +++
 llvm/test/CodeGen/AArch64/addrsig-macho.ll|   4 +-
 llvm/test/CodeGen/AArch64/ifunc-asm.ll|  82 +
 llvm/test/CodeGen/X86/ifunc-asm.ll|  28 +-
 llvm/test/Verifier/ifunc-macho.ll |  42 +++
 12 files changed, 539 insertions(+), 23 deletions(-)
 create mode 100644 llvm/test/CodeGen/AArch64/GlobalISel/call-lowering-ifunc.ll
 create mode 100644 llvm/test/CodeGen/AArch64/ifunc-asm.ll
 create mode 100644 llvm/test/Verifier/ifunc-macho.ll

diff --git a/llvm/docs/LangRef.rst b/llvm/docs/LangRef.rst
index e448c5ed5c5d9..cb222e979db29 100644
--- a/llvm/docs/LangRef.rst
+++ b/llvm/docs/LangRef.rst
@@ -934,10 +934,11 @@ IFuncs
 ---
 
 IFuncs, like as aliases, don't create any new data or func. They are just a new
-symbol that dynamic linker resolves at runtime by calling a resolver function.
+symbol that is resolved at runtime by calling a resolver function.
 
-IFuncs have a name and a resolver that is a function called by dynamic linker
-that returns address of another function associated with the name.
+On ELF platforms, IFuncs are resolved by the dynamic linker at load time. On
+MachO platforms, they are lowered in terms of ``.symbol_resolver``s, which
+lazily resolve the callee the first time they are called.
 
 IFunc may have an optional :ref:`linkage type ` and an optional
 :ref:`visibility style `.
diff --git a/llvm/include/llvm/CodeGen/AsmPrinter.h 
b/llvm/include/llvm/CodeGen/AsmPrinter.h
index 2731ef452c79c..48fa6c478464c 100644
--- a/llvm/include/llvm/CodeGen/AsmPrinter.h
+++ b/llvm/include/llvm/CodeGen/AsmPrinter.h
@@ -882,7 +882,11 @@ class AsmPrinter : public MachineFunctionPass {
 
   GCMetadataPrinter *getOrCreateGCPrinter(GCStrategy );
   void emitGlobalAlias(Module , const GlobalAlias );
-  void emitGlobalIFunc(Module , const GlobalIFunc );
+
+protected:
+  virtual void emitGlobalIFunc(Module , const GlobalIFunc );
+
+private:
 
   /// This method decides whether the specified basic block requires a label.
   bool shouldEmitLabelForBasicBlock(const MachineBasicBlock ) const;
diff --git a/llvm/lib/CodeGen/GlobalISel/CallLowering.cpp 
b/llvm/lib/CodeGen/GlobalISel/CallLowering.cpp
index 2527b14312896..e0080b145d4f9 100644
--- a/llvm/lib/CodeGen/GlobalISel/CallLowering.cpp
+++ b/llvm/lib/CodeGen/GlobalISel/CallLowering.cpp
@@ -144,7 +144,12 @@ bool CallLowering::lowerCall(MachineIRBuilder , 
const CallBase ,
   // Try looking through a bitcast from one function type to another.
   // Commonly happens with calls to objc_msgSend().
   const Value *CalleeV = CB.getCalledOperand()->stripPointerCasts();
-  if (const Function *F = dyn_cast(CalleeV))
+  if (const GlobalIFunc *IF = dyn_cast(CalleeV);
+  IF && MF.getTarget().getTargetTriple().isOSBinFormatMachO()) {
+// ld64 requires that .symbol_resolvers to be called via a stub, so these
+// must always be a diret call.
+Info.Callee = MachineOperand::CreateGA(IF, 0);
+  } else if (const Function *F = dyn_cast(CalleeV))
 Info.Callee = MachineOperand::CreateGA(F, 0);
   else
 Info.Callee = MachineOperand::CreateReg(GetCalleeReg(), false);
diff --git a/llvm/lib/IR/Verifier.cpp b/llvm/lib/IR/Verifier.cpp
index 5560c037aa3ee..94e76a43bf38d 100644
--- a/llvm/lib/IR/Verifier.cpp
+++ b/llvm/lib/IR/Verifier.cpp
@@ -959,6 +959,7 @@ void Verifier::visitGlobalIFunc(const GlobalIFunc ) {
   GlobalIFunc::getResolverFunctionType(GI.getValueType());
   Check(ResolverTy == ResolverFuncTy->getPointerTo(GI.getAddressSpace()),
 "IFunc resolver has incorrect type", );
+
 }
 
 void Verifier::visitNamedMDNode(const NamedMDNode ) {
@@ -2239,13 +2240,10 @@ void Verifier::verifyFunctionAttrs(FunctionType *FT, 
AttributeList Attrs,
   }
 
   // Check EVEX512 feature.
-  if (MaxParameterWidth >= 512 && Attrs.hasFnAttr("target-features")) {
-Triple T(M.getTargetTriple());
-if (T.isX86()) {
-  StringRef TF = Attrs.getFnAttr("target-features").getValueAsString();
-  Check(!TF.contains("+avx512f") || !TF.contains("-evex512"),
-"512-bit vector arguments require 'evex512' for AVX512", V);
-}
+  

[Lldb-commits] [lldb] [lldb][progress] Add discrete boolean flag to progress reports (PR #69516)

2023-12-06 Thread Chelsea Cassanova via lldb-commits


@@ -55,6 +55,11 @@ namespace lldb_private {
 
 class Progress {
 public:
+  /// Enum that indicates the type of progress report
+  enum class ProgressReportType {
+eAggregateProgressReport,
+eNonAggregateProgressReport

chelcassanova wrote:

To my understanding something like symbol table parsing can happen multiple 
times per session if new symbol tables need to be parsed due to new libraries 
being added. We want to send the progress events to the IDE team who can then 
filter the events based on this enum.

https://github.com/llvm/llvm-project/pull/69516
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb][SymbolFileDWARF][NFC] Remove unnecessary calls to GetDWARFDeclContext (PR #74523)

2023-12-06 Thread Felipe de Azevedo Piovezan via lldb-commits

https://github.com/felipepiovezan closed 
https://github.com/llvm/llvm-project/pull/74523
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] 9982f8e - [lldb][SymbolFileDWARF][NFC] Remove unnecessary calls to GetDWARFDeclContext (#74523)

2023-12-06 Thread via lldb-commits

Author: Felipe de Azevedo Piovezan
Date: 2023-12-06T10:42:42-08:00
New Revision: 9982f8ee02be7aa82b88001e509a1b41d57eb1dc

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

LOG: [lldb][SymbolFileDWARF][NFC] Remove unnecessary calls to 
GetDWARFDeclContext (#74523)

The function FindDefinitionTypeForDWARFDeclContext loops over all DIEs
corresponding to types with a certain name and compares the context of
each found DIE with the context of a target DIE. However, the target DIE
never changes throughout this search, and yet we recompute its
DeclContext on every iteration of the search. This is wasteful because
the method is not exactly free (see
DWARFDebugInfoEntry::GetDWARFDeclContextStatic).

Added: 


Modified: 
lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp

Removed: 




diff  --git a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp 
b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
index 142d092e6d2ee..d4cc26a3c329b 100644
--- a/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
+++ b/lldb/source/Plugins/SymbolFile/DWARF/SymbolFileDWARF.cpp
@@ -3120,7 +3120,8 @@ 
SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext(const DWARFDIE ) {
 template_params = dwarf_ast->GetDIEClassTemplateParams(die);
 }
 
-m_index->GetTypes(GetDWARFDeclContext(die), [&](DWARFDIE type_die) {
+const DWARFDeclContext die_dwarf_decl_ctx = GetDWARFDeclContext(die);
+m_index->GetTypes(die_dwarf_decl_ctx, [&](DWARFDIE type_die) {
   // Make sure type_die's language matches the type system we are
   // looking for. We don't want to find a "Foo" type from Java if we
   // are looking for a "Foo" type for C, C++, ObjC, or ObjC++.
@@ -3184,7 +3185,7 @@ 
SymbolFileDWARF::FindDefinitionTypeForDWARFDeclContext(const DWARFDIE ) {
   }
 
   // Make sure the decl contexts match all the way up
-  if (GetDWARFDeclContext(die) != type_dwarf_decl_ctx)
+  if (die_dwarf_decl_ctx != type_dwarf_decl_ctx)
 return true;
 
   Type *resolved_type = ResolveType(type_die, false);



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


[Lldb-commits] [lldb] [lldb][SymbolFileDWARF][NFC] Remove unnecessary calls to GetDWARFDeclContext (PR #74523)

2023-12-06 Thread Alex Langford via lldb-commits

https://github.com/bulbazord approved this pull request.


https://github.com/llvm/llvm-project/pull/74523
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB] Add more helper functions to CompilerType class (second try). (PR #73472)

2023-12-06 Thread via lldb-commits


@@ -194,6 +192,54 @@ class CompilerType {
   bool IsTypedefType() const;
 
   bool IsVoidType() const;
+
+  bool IsSmartPtrType() const;
+
+  bool IsInteger() const;
+
+  bool IsFloat() const;
+
+  bool IsEnumerationType() const;
+
+  bool IsUnscopedEnumerationType() const;
+
+  bool IsIntegerOrUnscopedEnumerationType() const;
+
+  bool IsSigned() const;
+
+  bool IsNullPtrType() const;
+
+  bool IsBoolean() const;
+
+  bool IsEnumerationIntegerTypeSigned() const;
+
+  bool IsScalarOrUnscopedEnumerationType() const;
+
+  bool IsPromotableIntegerType() const;
+
+  bool IsPointerToVoid() const;
+
+  bool IsRecordType() const;
+
+  bool IsVirtualBase(CompilerType target_base, CompilerType *virtual_base,
+ bool carry_virtual = false) const;
+
+  bool IsContextuallyConvertibleToBool() const;
+
+  bool IsBasicType() const;
+
+  std::string TypeDescription();
+
+  bool CompareTypes(CompilerType rhs) const;
+
+  const char *GetTypeTag();
+
+  uint32_t GetNumberOfNonEmptyBaseClasses();
+
+  CompilerType GetTemplateArgumentType(uint32_t idx);
+
+  CompilerType GetSmartPtrPointeeType();

cmtice wrote:

Ok, I've removed them now. 

https://github.com/llvm/llvm-project/pull/73472
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [LLDB] Add more helper functions to CompilerType class (second try). (PR #73472)

2023-12-06 Thread via lldb-commits

https://github.com/cmtice updated 
https://github.com/llvm/llvm-project/pull/73472

>From a063ebd8ee8bbd491fff3449bc20d663d2e501ea Mon Sep 17 00:00:00 2001
From: Caroline Tice 
Date: Sun, 26 Nov 2023 17:24:39 -0800
Subject: [PATCH 1/4] [LLDB] Add more helper functions to CompilerType class
 (second try).

This adds 23 new helper functions to LLDB's CompilerType class, things
like IsSmartPtrType, IsPromotableIntegerType,
GetNumberofNonEmptyBaseClasses, and GetTemplateArgumentType (to name a
few).

It also has run clang-format on the files CompilerType.{h,cpp}.

These helper functions are needed as part of the implementation for
the Data Inspection Language, (see
https://discourse.llvm.org/t/rfc-data-inspection-language/69893).
---
 lldb/include/lldb/Symbol/CompilerType.h |  56 -
 lldb/source/Symbol/CompilerType.cpp | 285 ++--
 2 files changed, 320 insertions(+), 21 deletions(-)

diff --git a/lldb/include/lldb/Symbol/CompilerType.h 
b/lldb/include/lldb/Symbol/CompilerType.h
index 0a9533a1ac0ef..a3331ad3269c0 100644
--- a/lldb/include/lldb/Symbol/CompilerType.h
+++ b/lldb/include/lldb/Symbol/CompilerType.h
@@ -112,9 +112,7 @@ class CompilerType {
 
   /// Tests.
   /// \{
-  explicit operator bool() const {
-return m_type_system.lock() && m_type;
-  }
+  explicit operator bool() const { return m_type_system.lock() && m_type; }
 
   bool IsValid() const { return (bool)*this; }
 
@@ -194,6 +192,54 @@ class CompilerType {
   bool IsTypedefType() const;
 
   bool IsVoidType() const;
+
+  bool IsSmartPtrType() const;
+
+  bool IsInteger() const;
+
+  bool IsFloat() const;
+
+  bool IsEnumerationType() const;
+
+  bool IsUnscopedEnumerationType() const;
+
+  bool IsIntegerOrUnscopedEnumerationType() const;
+
+  bool IsSigned() const;
+
+  bool IsNullPtrType() const;
+
+  bool IsBoolean() const;
+
+  bool IsEnumerationIntegerTypeSigned() const;
+
+  bool IsScalarOrUnscopedEnumerationType() const;
+
+  bool IsPromotableIntegerType() const;
+
+  bool IsPointerToVoid() const;
+
+  bool IsRecordType() const;
+
+  bool IsVirtualBase(CompilerType target_base, CompilerType *virtual_base,
+ bool carry_virtual = false) const;
+
+  bool IsContextuallyConvertibleToBool() const;
+
+  bool IsBasicType() const;
+
+  std::string TypeDescription();
+
+  bool CompareTypes(CompilerType rhs) const;
+
+  const char *GetTypeTag();
+
+  uint32_t GetNumberOfNonEmptyBaseClasses();
+
+  CompilerType GetTemplateArgumentType(uint32_t idx);
+
+  CompilerType GetSmartPtrPointeeType();
+
   /// \}
 
   /// Type Completion.
@@ -436,8 +482,8 @@ class CompilerType {
  ExecutionContextScope *exe_scope);
 
   /// Dump to stdout.
-  void DumpTypeDescription(lldb::DescriptionLevel level =
-   lldb::eDescriptionLevelFull) const;
+  void DumpTypeDescription(
+  lldb::DescriptionLevel level = lldb::eDescriptionLevelFull) const;
 
   /// Print a description of the type to a stream. The exact implementation
   /// varies, but the expectation is that eDescriptionLevelFull returns a
diff --git a/lldb/source/Symbol/CompilerType.cpp 
b/lldb/source/Symbol/CompilerType.cpp
index 78cc8dad94a9c..854d6cab01b50 100644
--- a/lldb/source/Symbol/CompilerType.cpp
+++ b/lldb/source/Symbol/CompilerType.cpp
@@ -54,7 +54,7 @@ bool CompilerType::IsArrayType(CompilerType 
*element_type_ptr, uint64_t *size,
   if (IsValid())
 if (auto type_system_sp = GetTypeSystem())
   return type_system_sp->IsArrayType(m_type, element_type_ptr, size,
-  is_incomplete);
+ is_incomplete);
 
   if (element_type_ptr)
 element_type_ptr->Clear();
@@ -157,7 +157,8 @@ bool CompilerType::IsBlockPointerType(
 CompilerType *function_pointer_type_ptr) const {
   if (IsValid())
 if (auto type_system_sp = GetTypeSystem())
-  return type_system_sp->IsBlockPointerType(m_type, 
function_pointer_type_ptr);
+  return type_system_sp->IsBlockPointerType(m_type,
+function_pointer_type_ptr);
   return false;
 }
 
@@ -249,7 +250,7 @@ bool CompilerType::IsPossibleDynamicType(CompilerType 
*dynamic_pointee_type,
   if (IsValid())
 if (auto type_system_sp = GetTypeSystem())
   return type_system_sp->IsPossibleDynamicType(m_type, 
dynamic_pointee_type,
-check_cplusplus, check_objc);
+   check_cplusplus, 
check_objc);
   return false;
 }
 
@@ -302,6 +303,256 @@ bool CompilerType::IsBeingDefined() const {
   return false;
 }
 
+bool CompilerType::IsSmartPtrType() const {
+  // These regular expressions cover shared, unique and weak pointers both from
+  // stdlibc++ and libc+++.
+
+  static llvm::Regex k_libcxx_std_unique_ptr_regex(
+  "^std::__[[:alnum:]]+::unique_ptr<.+>(( )?&)?$");
+  static llvm::Regex k_libcxx_std_shared_ptr_regex(
+  

[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-06 Thread Jonas Devlieghere via lldb-commits
=?utf-8?q?Jos=C3=A9?= L. Junior ,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 
<23100...@lums.edu.pk>,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 <23100...@lums.edu.pk>,
=?utf-8?q?Jos=C3=A9?= L. Junior ,
=?utf-8?q?Jos=C3=A9?= L. Junior 
Message-ID:
In-Reply-To: 



@@ -70,6 +72,32 @@ size_t Stream::PutCString(llvm::StringRef str) {
   return bytes_written;
 }
 
+void Stream::PutCStringColorHighlighted(llvm::StringRef text,
+llvm::StringRef pattern,
+llvm::StringRef prefix,
+llvm::StringRef suffix) {
+  // If there is no pattern to match, we should not use color
+  if (pattern.empty()) {
+PutCString(text);
+return;
+  }

JDevlieghere wrote:

If the prefix and suffix are empty, we can also take this shortcut, right? 

https://github.com/llvm/llvm-project/pull/69422
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-06 Thread Jonas Devlieghere via lldb-commits
=?utf-8?q?José?= L. Junior ,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 
<23100...@lums.edu.pk>,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 <23100...@lums.edu.pk>,
=?utf-8?q?José?= L. Junior ,
=?utf-8?q?José?= L. Junior 
Message-ID:
In-Reply-To: 


https://github.com/JDevlieghere edited 
https://github.com/llvm/llvm-project/pull/69422
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-06 Thread Jonas Devlieghere via lldb-commits
=?utf-8?q?José?= L. Junior ,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 
<23100...@lums.edu.pk>,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 <23100...@lums.edu.pk>,
=?utf-8?q?José?= L. Junior ,
=?utf-8?q?José?= L. Junior 
Message-ID:
In-Reply-To: 


https://github.com/JDevlieghere approved this pull request.

I didn't realize it was going to be so tedious to pass the prefix and suffix 
down, but I still think it's the right thing to do, so thanks for making that 
work. It would be awesome if we can make the `optional` work, but that's 
not a blocker so this LGTM.  

https://github.com/llvm/llvm-project/pull/69422
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Revert "emit definitions for constant-initialized static data-members" (PR #74580)

2023-12-06 Thread Michael Buch via lldb-commits

https://github.com/Michael137 edited 
https://github.com/llvm/llvm-project/pull/74580
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Revert "emit definitions for constant-initialized static data-members" (PR #74580)

2023-12-06 Thread Michael Buch via lldb-commits

Michael137 wrote:

> Do you need me to merge that for you?

Was going to wait until some more people had the chance to look. But if urgent, 
I don't think there should be any trouble merging this sooner

https://github.com/llvm/llvm-project/pull/74580
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [llvm] [lldb] DEBUGINFOD based DWP acquisition for LLDB (PR #70996)

2023-12-06 Thread Michał Górny via lldb-commits

mgorny wrote:

This change broke building against LLVM dylib:

```
/usr/lib/gcc/x86_64-pc-linux-gnu/13/../../../../x86_64-pc-linux-gnu/bin/ld: 
cannot find -lLLVMDebuginfod: No such file or directory
collect2: error: ld returned 1 exit status
samu: subcommand failed
```

Full build log: 
[dev-util:lldb-18.0.0_pre20231206:20231206-163149.log](https://github.com/llvm/llvm-project/files/13588891/dev-util.lldb-18.0.0_pre20231206.20231206-163149.log)


https://github.com/llvm/llvm-project/pull/70996
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-06 Thread José Lira Junior via lldb-commits

junior-jl wrote:

Addressed @JDevlieghere suggestions.

- A new debugger option was created for custom colors.
- The test needed some adaptation and we added a new case to test for other 
color option.
- The `SymbolContext` situtation is working as discussed with David: no color 
when there is no target.
- The recent changes are using `StringRef` for `pattern`. @taalhaataahir0102 is 
trying to make it work with `std::optional`.
- Some missing comments were added.

https://github.com/llvm/llvm-project/pull/69422
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-06 Thread José Lira Junior via lldb-commits


@@ -70,6 +72,31 @@ size_t Stream::PutCString(llvm::StringRef str) {
   return bytes_written;
 }
 
+void Stream::PutCStringColorHighlighted(llvm::StringRef text,
+const char *pattern) {
+  if (!pattern) {
+PutCString(text);
+return;
+  }
+
+  // If pattern is not nullptr, we should use color
+  llvm::Regex reg_pattern(pattern);
+  llvm::SmallVector matches;
+  llvm::StringRef remaining = text;
+  std::string format_str = lldb_private::ansi::FormatAnsiTerminalCodes(
+  "${ansi.fg.red}%.*s${ansi.normal}");

junior-jl wrote:

![image](https://github.com/llvm/llvm-project/assets/69206952/a9c34f6f-b671-4fc2-bc6c-abf8d9d489d2)

This is how it is working now. Basically no color for SymbolContext. IMO, it is 
a little weird, but the alternative option of forcing red color when no target 
is available could be weirder when the color was changed by the user.

https://github.com/llvm/llvm-project/pull/69422
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-06 Thread José Lira Junior via lldb-commits

https://github.com/junior-jl updated 
https://github.com/llvm/llvm-project/pull/69422

From c416443a93f7113a7f57d337682ec4862438522d Mon Sep 17 00:00:00 2001
From: =?UTF-8?q?Jos=C3=A9=20L=2E=20Junior?= 
Date: Tue, 7 Nov 2023 16:57:18 -0300
Subject: [PATCH 1/8] [lldb] colorize symbols in image lookup

This creates the method PutCStringColorHighlighted for Stream class,
which highlights searched symbols in red color for the image lookup command.

A new shell test was added to verify functionality. Relevant methods were
updated to accept the searched pattern/symbol as a parameter.

Co-authored-by: Talha 
---
 lldb/include/lldb/Core/Address.h  |  4 +-
 lldb/include/lldb/Symbol/Symbol.h |  4 +-
 lldb/include/lldb/Symbol/SymbolContext.h  |  8 ++--
 lldb/include/lldb/Utility/Stream.h| 16 
 lldb/source/Commands/CommandObjectTarget.cpp  | 16 +---
 lldb/source/Core/Address.cpp  | 21 ++
 lldb/source/Symbol/Symbol.cpp | 18 ++---
 lldb/source/Symbol/SymbolContext.cpp  | 16 +---
 lldb/source/Utility/Stream.cpp| 28 +
 .../Commands/command-image-lookup-color.test  | 39 +++
 10 files changed, 138 insertions(+), 32 deletions(-)
 create mode 100644 lldb/test/Shell/Commands/command-image-lookup-color.test

diff --git a/lldb/include/lldb/Core/Address.h b/lldb/include/lldb/Core/Address.h
index b19e694427546..c3f2832be424e 100644
--- a/lldb/include/lldb/Core/Address.h
+++ b/lldb/include/lldb/Core/Address.h
@@ -246,8 +246,8 @@ class Address {
   /// \see Address::DumpStyle
   bool Dump(Stream *s, ExecutionContextScope *exe_scope, DumpStyle style,
 DumpStyle fallback_style = DumpStyleInvalid,
-uint32_t addr_byte_size = UINT32_MAX,
-bool all_ranges = false) const;
+uint32_t addr_byte_size = UINT32_MAX, bool all_ranges = false,
+const char *pattern = nullptr) const;
 
   AddressClass GetAddressClass() const;
 
diff --git a/lldb/include/lldb/Symbol/Symbol.h 
b/lldb/include/lldb/Symbol/Symbol.h
index 44a2d560010fe..0e41cd95e0ef1 100644
--- a/lldb/include/lldb/Symbol/Symbol.h
+++ b/lldb/include/lldb/Symbol/Symbol.h
@@ -174,8 +174,8 @@ class Symbol : public SymbolContextScope {
 
   void SetFlags(uint32_t flags) { m_flags = flags; }
 
-  void GetDescription(Stream *s, lldb::DescriptionLevel level,
-  Target *target) const;
+  void GetDescription(Stream *s, lldb::DescriptionLevel level, Target *target,
+  const char *pattern = nullptr) const;
 
   bool IsSynthetic() const { return m_is_synthetic; }
 
diff --git a/lldb/include/lldb/Symbol/SymbolContext.h 
b/lldb/include/lldb/Symbol/SymbolContext.h
index b0f5ffead2a16..9567c3f4384c1 100644
--- a/lldb/include/lldb/Symbol/SymbolContext.h
+++ b/lldb/include/lldb/Symbol/SymbolContext.h
@@ -150,8 +150,8 @@ class SymbolContext {
   bool DumpStopContext(Stream *s, ExecutionContextScope *exe_scope,
const Address _addr, bool show_fullpaths,
bool show_module, bool show_inlined_frames,
-   bool show_function_arguments,
-   bool show_function_name) const;
+   bool show_function_arguments, bool show_function_name,
+   const char *pattern = nullptr) const;
 
   /// Get the address range contained within a symbol context.
   ///
@@ -217,8 +217,8 @@ class SymbolContext {
   /// The symbol that was found, or \b nullptr if none was found.
   const Symbol *FindBestGlobalDataSymbol(ConstString name, Status );
 
-  void GetDescription(Stream *s, lldb::DescriptionLevel level,
-  Target *target) const;
+  void GetDescription(Stream *s, lldb::DescriptionLevel level, Target *target,
+  const char *pattern = nullptr) const;
 
   uint32_t GetResolvedMask() const;
 
diff --git a/lldb/include/lldb/Utility/Stream.h 
b/lldb/include/lldb/Utility/Stream.h
index 1a5fd343e4df0..8e3fd48dfe705 100644
--- a/lldb/include/lldb/Utility/Stream.h
+++ b/lldb/include/lldb/Utility/Stream.h
@@ -231,6 +231,22 @@ class Stream {
   /// The string to be output to the stream.
   size_t PutCString(llvm::StringRef cstr);
 
+  /// Output a C string to the stream with color highlighting.
+  ///
+  /// Print a C string \a text to the stream, applying red color highlighting 
to
+  /// the portions of the string that match the regex pattern \a pattern. The
+  /// pattern is matched as many times as possible throughout the string. If \a
+  /// pattern is nullptr, then no highlighting is applied.
+  ///
+  /// \param[in] text
+  /// The string to be output to the stream.
+  ///
+  /// \param[in] pattern
+  /// The regex pattern to match against the \a text string. Portions of \a
+  /// text matching this pattern will be colorized. If this parameter is
+  /// nullptr, highlighting is not performed.
+  void 

[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Revert "emit definitions for constant-initialized static data-members" (PR #74580)

2023-12-06 Thread via lldb-commits

cor3ntin wrote:

See https://github.com/llvm/llvm-project/issues/74070

https://github.com/llvm/llvm-project/pull/74580
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Revert "emit definitions for constant-initialized static data-members" (PR #74580)

2023-12-06 Thread via lldb-commits

https://github.com/cor3ntin approved this pull request.

Do you need me to merge that for you?

https://github.com/llvm/llvm-project/pull/74580
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [flang] [llvm] [libcxx] [libcxxabi] [compiler-rt] [lldb] [libunwind] [mlir] [clang-tools-extra] [lld] [libc] [openmp] [clang] [C23] Implement N3018: The constexpr specifier for object d

2023-12-06 Thread Mariya Podchishchaeva via lldb-commits


@@ -1914,6 +1914,17 @@ class StringLiteral final
 llvm_unreachable("Unsupported character width!");
   }
 
+  // Get code unit but preserve sign info.
+  int64_t getCodeUnitS(size_t I, uint64_t ByteWidth) const {

Fznamznon wrote:

It is a number of bits in byte, but ok

https://github.com/llvm/llvm-project/pull/73099
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [flang] [llvm] [libcxx] [libcxxabi] [compiler-rt] [lldb] [libunwind] [mlir] [clang-tools-extra] [lld] [libc] [openmp] [clang] [C23] Implement N3018: The constexpr specifier for object d

2023-12-06 Thread Mariya Podchishchaeva via lldb-commits


@@ -14270,6 +14318,113 @@ StmtResult Sema::ActOnCXXForRangeIdentifier(Scope *S, 
SourceLocation IdentLoc,
   : IdentLoc);
 }
 
+static ImplicitConversionKind GetConversionKind(QualType FromType,
+QualType ToType) {
+  if (ToType->isIntegerType()) {
+if (FromType->isComplexType())
+  return ICK_Complex_Real;
+if (FromType->isFloatingType())
+  return ICK_Floating_Integral;
+if (FromType->isIntegerType())
+  return ICK_Integral_Conversion;
+  }
+
+  if (ToType->isFloatingType()) {
+if (FromType->isComplexType())
+  return ICK_Complex_Real;
+if (FromType->isFloatingType())
+  return ICK_Floating_Conversion;
+if (FromType->isIntegerType())
+  return ICK_Floating_Integral;
+  }
+
+  return ICK_Identity;
+}
+
+static bool CheckC23ConstexprInitConversion(Sema , const Expr *Init) {
+  assert(S.getLangOpts().C23);
+  const Expr *InitNoCast = Init->IgnoreParenImpCasts();
+  StandardConversionSequence SCS;
+  SCS.setAsIdentityConversion();
+  auto FromType = InitNoCast->getType();
+  auto ToType = Init->getType();
+  SCS.setToType(0, FromType);
+  SCS.setToType(1, ToType);
+  SCS.Second = GetConversionKind(FromType, ToType);
+
+  APValue Value;
+  QualType PreNarrowingType;
+  // Reuse C++ narrowing check.
+  switch (SCS.getNarrowingKind(S.Context, Init, Value, PreNarrowingType,
+   /*IgnoreFloatToIntegralConversion*/ false)) {
+  // The value doesn't fit.
+  case NK_Constant_Narrowing:
+S.Diag(Init->getBeginLoc(), diag::err_c23_constexpr_init_not_representable)
+<< Value.getAsString(S.Context, PreNarrowingType) << ToType;
+return true;
+
+  // Conversion to a narrower type.
+  case NK_Type_Narrowing:
+S.Diag(Init->getBeginLoc(), diag::err_c23_constexpr_init_type_mismatch)
+<< ToType << FromType;
+return true;
+
+  // Since we only reuse narrowing check for C23 constexpr variables here, 
we're
+  // not really interested in these cases.
+  case NK_Dependent_Narrowing:
+  case NK_Variable_Narrowing:
+  case NK_Not_Narrowing:
+return false;
+  }
+  llvm_unreachable("unhandled case in switch");
+}
+
+static bool CheckC23ConstexprInitStringLiteral(const StringLiteral *SE,
+   Sema ,
+   SourceLocation Loc) {
+  assert(SemaRef.getLangOpts().C23);
+  // String literals have the target type attached but underneath may contain
+  // values that don't really fit into the target type. Check that every
+  // character fits.
+  const ConstantArrayType *CAT =
+  SemaRef.Context.getAsConstantArrayType(SE->getType());
+  QualType CharType = CAT->getElementType();
+  uint32_t BitWidth = SemaRef.Context.getTypeSize(CharType);
+  bool isUnsigned = CharType->isUnsignedIntegerType();
+  llvm::APSInt Value(BitWidth, isUnsigned);
+  for (unsigned I = 0, N = SE->getLength(); I != N; ++I) {
+int64_t C = SE->getCodeUnitS(I, SemaRef.Context.getCharWidth());
+Value = C;
+if (Value != C) {
+  SemaRef.Diag(Loc, diag::err_c23_constexpr_init_not_representable)

Fznamznon wrote:

Yeah why not. Looks better this way

https://github.com/llvm/llvm-project/pull/73099
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [flang] [llvm] [libcxx] [libcxxabi] [compiler-rt] [lldb] [libunwind] [mlir] [clang-tools-extra] [lld] [libc] [openmp] [clang] [C23] Implement N3018: The constexpr specifier for object d

2023-12-06 Thread Mariya Podchishchaeva via lldb-commits

https://github.com/Fznamznon updated 
https://github.com/llvm/llvm-project/pull/73099

>From 1d70b7726e7d1f11622a6d5c8246b0737e024c8d Mon Sep 17 00:00:00 2001
From: "Podchishchaeva, Mariya" 
Date: Tue, 19 Sep 2023 08:37:18 -0700
Subject: [PATCH 1/8] [C23] Implement N3018: The constexpr specifier for object
 definitions

The implementation mostly reuses C++ code paths where possible,
including narrowing check in order to provide diagnostic messages in
case initializer for constexpr variable is not exactly representable in
target type.

The following won't work due to lack of support for other features:
- Diagnosing of underspecified declarations involving constexpr
- Constexpr attached to compound literals

Also due to lack of support for char8_t some of examples with utf-8
strings don't work properly.
---
 clang/docs/ReleaseNotes.rst   |   1 +
 .../clang/Basic/DiagnosticSemaKinds.td|  16 +
 clang/include/clang/Basic/TokenKinds.def  |   2 +-
 clang/lib/AST/Decl.cpp|  16 +-
 clang/lib/AST/ExprConstant.cpp|  17 +-
 clang/lib/Parse/ParseDecl.cpp |   2 +
 clang/lib/Sema/SemaDecl.cpp   | 204 +++--
 clang/lib/Sema/SemaOverload.cpp   |  36 ++-
 clang/test/C/C2x/n3018.c  |  86 ++
 clang/test/Parser/c23-constexpr.c |   6 +
 clang/test/Sema/constexpr.c   | 275 ++
 clang/www/c_status.html   |   2 +-
 12 files changed, 627 insertions(+), 36 deletions(-)
 create mode 100644 clang/test/C/C2x/n3018.c
 create mode 100644 clang/test/Parser/c23-constexpr.c
 create mode 100644 clang/test/Sema/constexpr.c

diff --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index b65106b9106d4..cae1707f3e30f 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -208,6 +208,7 @@ C23 Feature Support
 
 - Clang now supports  which defines several macros for 
performing
   checked integer arithmetic. It is also exposed in pre-C23 modes.
+- Clang now supports ``N3018 The constexpr specifier for object definitions``.
 
 - Completed the implementation of
   `N2508 `_. We
diff --git a/clang/include/clang/Basic/DiagnosticSemaKinds.td 
b/clang/include/clang/Basic/DiagnosticSemaKinds.td
index 990692c06d7d3..11f24583dc55a 100644
--- a/clang/include/clang/Basic/DiagnosticSemaKinds.td
+++ b/clang/include/clang/Basic/DiagnosticSemaKinds.td
@@ -2932,6 +2932,22 @@ def warn_private_extern : Warning<
 def note_private_extern : Note<
   "use __attribute__((visibility(\"hidden\"))) attribute instead">;
 
+// C23 constexpr
+def err_c23_thread_local_constexpr : Error<
+  "thread-local storage is not allowed with constexpr">;
+def err_c23_extern_constexpr : Error<
+  "extern specifier is not allowed with constexpr">;
+def err_c23_constexpr_not_variable : Error<
+  "constexpr is only allowed in variable declarations">;
+def err_c23_constexpr_invalid_type : Error<
+  "constexpr variable cannot have type %0">;
+def err_c23_constexpr_init_not_representable : Error<
+  "constexpr initializer evaluates to %0 which is not exactly representable in 
type %1">;
+def err_c23_constexpr_init_type_mismatch : Error<
+  "constexpr initializer for type %0 is of type %1">;
+def err_c23_constexpr_pointer_not_null : Error<
+  "constexpr pointer initializer is not null">;
+
 // C++ Concepts
 def err_concept_decls_may_only_appear_in_global_namespace_scope : Error<
   "concept declarations may only appear in global or namespace scope">;
diff --git a/clang/include/clang/Basic/TokenKinds.def 
b/clang/include/clang/Basic/TokenKinds.def
index 3ab420821d82b..e9e8f59247662 100644
--- a/clang/include/clang/Basic/TokenKinds.def
+++ b/clang/include/clang/Basic/TokenKinds.def
@@ -393,7 +393,7 @@ CXX11_KEYWORD(alignas   , KEYC23)
 CXX11_UNARY_EXPR_OR_TYPE_TRAIT(alignof, AlignOf, KEYC23)
 CXX11_KEYWORD(char16_t  , KEYNOMS18)
 CXX11_KEYWORD(char32_t  , KEYNOMS18)
-CXX11_KEYWORD(constexpr , 0)
+CXX11_KEYWORD(constexpr , KEYC23)
 CXX11_KEYWORD(decltype  , 0)
 CXX11_KEYWORD(noexcept  , 0)
 CXX11_KEYWORD(nullptr   , KEYC23)
diff --git a/clang/lib/AST/Decl.cpp b/clang/lib/AST/Decl.cpp
index c5c2edf1bfe3a..678a366ed29ad 100644
--- a/clang/lib/AST/Decl.cpp
+++ b/clang/lib/AST/Decl.cpp
@@ -2461,7 +2461,7 @@ bool VarDecl::mightBeUsableInConstantExpressions(const 
ASTContext ) const {
 
   // OpenCL permits const integral variables to be used in constant
   // expressions, like in C++98.
-  if (!Lang.CPlusPlus && !Lang.OpenCL)
+  if (!Lang.CPlusPlus && !Lang.OpenCL && !Lang.C23)
 return false;
 
   // Function parameters are never usable in constant expressions.
@@ -2485,12 +2485,12 @@ bool VarDecl::mightBeUsableInConstantExpressions(const 
ASTContext ) const {
 
   // In C++, const, non-volatile 

[Lldb-commits] [lldb] [clang] [clang][DebugInfo] Revert "emit definitions for constant-initialized static data-members" (PR #74580)

2023-12-06 Thread Michael Buch via lldb-commits

https://github.com/Michael137 updated 
https://github.com/llvm/llvm-project/pull/74580

>From fe9624fdf898a2a629bb34f070d0e084f6dc0aa9 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Tue, 5 Dec 2023 14:52:00 +
Subject: [PATCH 1/2] [clang][DebugInfo] Revert "emit variable definitions for
 constant-initialized static data-members"

This commit reverts the changes in 
https://github.com/llvm/llvm-project/pull/71780
and all of its follow-up patches.

We got reports of the `.debug_names/.debug_gnu_pubnames/gdb_index/etc.`
sections growing by a non-trivial amount for some large projects. While
GCC does index definitions for static data member constants, they
do so *only* for explicitly `constexpr` members. We were indexing
*all* constant-initialized const-static members, which is likely where
the significant size difference comes from. However, only emitting explicitly
`constexpr` variables into the index doesn't seem like a good way
forward, since from clang's perspective `const`-static integrals
are `constexpr` too, and that shouldn't be any different in the debug-info
component. Also, as new code moves to `constexpr` instead of `const` static
for constants, such solution would just delay the growth of the Names index.

To prevent the size regression we revert to not emitting definitions for
static data-members that have no location.

To support access to such constants from LLDB we'll most likely have to
have to make LLDB find the constants by looking at the containing class
first.
---
 clang/lib/CodeGen/CGDebugInfo.cpp |  73 
 clang/lib/CodeGen/CGDebugInfo.h   |   6 -
 clang/test/CodeGenCXX/debug-info-class.cpp|  12 +-
 .../debug-info-static-inline-member.cpp   | 104 --
 .../CodeGenCXX/debug-info-static-member.cpp   |  20 +---
 .../SymbolFile/DWARF/DWARFASTParserClang.cpp  |  64 +--
 .../SymbolFile/DWARF/DWARFASTParserClang.h|  11 --
 7 files changed, 10 insertions(+), 280 deletions(-)
 delete mode 100644 clang/test/CodeGenCXX/debug-info-static-inline-member.cpp

diff --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 602e325e560f9..7cf661994a29c 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -69,29 +69,6 @@ static uint32_t getDeclAlignIfRequired(const Decl *D, const 
ASTContext ) {
   return D->hasAttr() ? D->getMaxAlignment() : 0;
 }
 
-/// Given a VarDecl corresponding to either the definition or
-/// declaration of a C++ static data member, if it has a constant
-/// initializer and is evaluatable, return the evaluated value.
-/// Returns std::nullopt otherwise.
-static std::optional
-evaluateConstantInitializer(const clang::VarDecl *VD,
-const clang::ASTContext ) {
-  assert(VD != nullptr);
-
-  if (!VD->isStaticDataMember())
-return std::nullopt;
-
-  if (!VD->isUsableInConstantExpressions(Ctx))
-return std::nullopt;
-
-  auto const *InitExpr = VD->getAnyInitializer();
-  Expr::EvalResult Result;
-  if (!InitExpr->EvaluateAsConstantExpr(Result, Ctx))
-return std::nullopt;
-
-  return Result.Val;
-}
-
 CGDebugInfo::CGDebugInfo(CodeGenModule )
 : CGM(CGM), DebugKind(CGM.getCodeGenOpts().getDebugInfo()),
   DebugTypeExtRefs(CGM.getCodeGenOpts().DebugTypeExtRefs),
@@ -1724,7 +1701,6 @@ CGDebugInfo::CreateRecordStaticField(const VarDecl *Var, 
llvm::DIType *RecordTy,
   llvm::DIDerivedType *GV = DBuilder.createStaticMemberType(
   RecordTy, VName, VUnit, LineNumber, VTy, Flags, C, Tag, Align);
   StaticDataMemberCache[Var->getCanonicalDecl()].reset(GV);
-  StaticDataMemberDefinitionsToEmit.push_back(Var->getCanonicalDecl());
   return GV;
 }
 
@@ -5628,41 +5604,6 @@ void CGDebugInfo::EmitGlobalVariable(const ValueDecl 
*VD, const APValue ) {
   TemplateParameters, Align));
 }
 
-void CGDebugInfo::EmitGlobalVariable(const VarDecl *VD) {
-  assert(CGM.getCodeGenOpts().hasReducedDebugInfo());
-  if (VD->hasAttr())
-return;
-
-  const auto CacheIt = DeclCache.find(VD);
-  if (CacheIt != DeclCache.end())
-return;
-
-  const auto InitVal = evaluateConstantInitializer(VD, CGM.getContext());
-  if (!InitVal)
-return;
-
-  llvm::DIFile *Unit = nullptr;
-  llvm::DIScope *DContext = nullptr;
-  unsigned LineNo;
-  StringRef DeclName, LinkageName;
-  QualType T;
-  llvm::MDTuple *TemplateParameters = nullptr;
-  collectVarDeclProps(VD, Unit, LineNo, T, DeclName, LinkageName,
-  TemplateParameters, DContext);
-
-  auto Align = getDeclAlignIfRequired(VD, CGM.getContext());
-  llvm::DINodeArray Annotations = CollectBTFDeclTagAnnotations(VD);
-  llvm::DIExpression *InitExpr = createConstantValueExpression(VD, *InitVal);
-
-  // Omit linkage name for variable definitions that represent constants.
-  // There hasn't been a need from consumers yet to have it attached.
-  DeclCache[VD].reset(DBuilder.createGlobalVariableExpression(
-  TheCU, DeclName, /* LinkageName */ {}, Unit, 

[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Revert "emit definitions for constant-initialized static data-members" (PR #74580)

2023-12-06 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-clang

Author: Michael Buch (Michael137)


Changes

This commit reverts the changes in 
https://github.com/llvm/llvm-project/pull/71780 and all of its follow-up 
patches.

We got reports of the `.debug_names/.debug_gnu_pubnames/gdb_index/etc.` 
sections growing by a non-trivial amount for some large projects. While GCC 
does index definitions for static data member constants, they do so *only* for 
explicitly `constexpr` members. We were indexing *all* constant-initialized 
const-static members, which is likely where the significant size difference 
comes from. However, only emitting explicitly `constexpr` variables into the 
index doesn't seem like a good way forward, since from clang's perspective 
`const`-static integrals are `constexpr` too, and that shouldn't be any 
different in the debug-info component. Also, as new code moves to `constexpr` 
instead of `const` static for constants, such solution would just delay the 
growth of the Names index.

To prevent the size regression we revert to not emitting definitions for static 
data-members that have no location.

To support access to such constants from LLDB we'll most likely have to have to 
make LLDB find the constants by looking at the containing class first.

---
Full diff: https://github.com/llvm/llvm-project/pull/74580.diff


7 Files Affected:

- (modified) clang/lib/CodeGen/CGDebugInfo.cpp (-73) 
- (modified) clang/lib/CodeGen/CGDebugInfo.h (-6) 
- (modified) clang/test/CodeGenCXX/debug-info-class.cpp (+4-8) 
- (removed) clang/test/CodeGenCXX/debug-info-static-inline-member.cpp (-104) 
- (modified) clang/test/CodeGenCXX/debug-info-static-member.cpp (+4-16) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
(+2-62) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h (-11) 


``diff
diff --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 602e325e560f9..7cf661994a29c 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -69,29 +69,6 @@ static uint32_t getDeclAlignIfRequired(const Decl *D, const 
ASTContext ) {
   return D->hasAttr() ? D->getMaxAlignment() : 0;
 }
 
-/// Given a VarDecl corresponding to either the definition or
-/// declaration of a C++ static data member, if it has a constant
-/// initializer and is evaluatable, return the evaluated value.
-/// Returns std::nullopt otherwise.
-static std::optional
-evaluateConstantInitializer(const clang::VarDecl *VD,
-const clang::ASTContext ) {
-  assert(VD != nullptr);
-
-  if (!VD->isStaticDataMember())
-return std::nullopt;
-
-  if (!VD->isUsableInConstantExpressions(Ctx))
-return std::nullopt;
-
-  auto const *InitExpr = VD->getAnyInitializer();
-  Expr::EvalResult Result;
-  if (!InitExpr->EvaluateAsConstantExpr(Result, Ctx))
-return std::nullopt;
-
-  return Result.Val;
-}
-
 CGDebugInfo::CGDebugInfo(CodeGenModule )
 : CGM(CGM), DebugKind(CGM.getCodeGenOpts().getDebugInfo()),
   DebugTypeExtRefs(CGM.getCodeGenOpts().DebugTypeExtRefs),
@@ -1724,7 +1701,6 @@ CGDebugInfo::CreateRecordStaticField(const VarDecl *Var, 
llvm::DIType *RecordTy,
   llvm::DIDerivedType *GV = DBuilder.createStaticMemberType(
   RecordTy, VName, VUnit, LineNumber, VTy, Flags, C, Tag, Align);
   StaticDataMemberCache[Var->getCanonicalDecl()].reset(GV);
-  StaticDataMemberDefinitionsToEmit.push_back(Var->getCanonicalDecl());
   return GV;
 }
 
@@ -5628,41 +5604,6 @@ void CGDebugInfo::EmitGlobalVariable(const ValueDecl 
*VD, const APValue ) {
   TemplateParameters, Align));
 }
 
-void CGDebugInfo::EmitGlobalVariable(const VarDecl *VD) {
-  assert(CGM.getCodeGenOpts().hasReducedDebugInfo());
-  if (VD->hasAttr())
-return;
-
-  const auto CacheIt = DeclCache.find(VD);
-  if (CacheIt != DeclCache.end())
-return;
-
-  const auto InitVal = evaluateConstantInitializer(VD, CGM.getContext());
-  if (!InitVal)
-return;
-
-  llvm::DIFile *Unit = nullptr;
-  llvm::DIScope *DContext = nullptr;
-  unsigned LineNo;
-  StringRef DeclName, LinkageName;
-  QualType T;
-  llvm::MDTuple *TemplateParameters = nullptr;
-  collectVarDeclProps(VD, Unit, LineNo, T, DeclName, LinkageName,
-  TemplateParameters, DContext);
-
-  auto Align = getDeclAlignIfRequired(VD, CGM.getContext());
-  llvm::DINodeArray Annotations = CollectBTFDeclTagAnnotations(VD);
-  llvm::DIExpression *InitExpr = createConstantValueExpression(VD, *InitVal);
-
-  // Omit linkage name for variable definitions that represent constants.
-  // There hasn't been a need from consumers yet to have it attached.
-  DeclCache[VD].reset(DBuilder.createGlobalVariableExpression(
-  TheCU, DeclName, /* LinkageName */ {}, Unit, LineNo,
-  getOrCreateType(T, Unit), true, true, InitExpr,
-  getOrCreateStaticDataMemberDeclarationOrNull(VD), TemplateParameters,
-  Align, Annotations));
-}
-
 void 

[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Revert "emit definitions for constant-initialized static data-members" (PR #74580)

2023-12-06 Thread via lldb-commits

llvmbot wrote:




@llvm/pr-subscribers-debuginfo

Author: Michael Buch (Michael137)


Changes

This commit reverts the changes in 
https://github.com/llvm/llvm-project/pull/71780 and all of its follow-up 
patches.

We got reports of the `.debug_names/.debug_gnu_pubnames/gdb_index/etc.` 
sections growing by a non-trivial amount for some large projects. While GCC 
does index definitions for static data member constants, they do so *only* for 
explicitly `constexpr` members. We were indexing *all* constant-initialized 
const-static members, which is likely where the significant size difference 
comes from. However, only emitting explicitly `constexpr` variables into the 
index doesn't seem like a good way forward, since from clang's perspective 
`const`-static integrals are `constexpr` too, and that shouldn't be any 
different in the debug-info component. Also, as new code moves to `constexpr` 
instead of `const` static for constants, such solution would just delay the 
growth of the Names index.

To prevent the size regression we revert to not emitting definitions for static 
data-members that have no location.

To support access to such constants from LLDB we'll most likely have to have to 
make LLDB find the constants by looking at the containing class first.

---
Full diff: https://github.com/llvm/llvm-project/pull/74580.diff


7 Files Affected:

- (modified) clang/lib/CodeGen/CGDebugInfo.cpp (-73) 
- (modified) clang/lib/CodeGen/CGDebugInfo.h (-6) 
- (modified) clang/test/CodeGenCXX/debug-info-class.cpp (+4-8) 
- (removed) clang/test/CodeGenCXX/debug-info-static-inline-member.cpp (-104) 
- (modified) clang/test/CodeGenCXX/debug-info-static-member.cpp (+4-16) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.cpp 
(+2-62) 
- (modified) lldb/source/Plugins/SymbolFile/DWARF/DWARFASTParserClang.h (-11) 


``diff
diff --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 602e325e560f9..7cf661994a29c 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -69,29 +69,6 @@ static uint32_t getDeclAlignIfRequired(const Decl *D, const 
ASTContext ) {
   return D->hasAttr() ? D->getMaxAlignment() : 0;
 }
 
-/// Given a VarDecl corresponding to either the definition or
-/// declaration of a C++ static data member, if it has a constant
-/// initializer and is evaluatable, return the evaluated value.
-/// Returns std::nullopt otherwise.
-static std::optional
-evaluateConstantInitializer(const clang::VarDecl *VD,
-const clang::ASTContext ) {
-  assert(VD != nullptr);
-
-  if (!VD->isStaticDataMember())
-return std::nullopt;
-
-  if (!VD->isUsableInConstantExpressions(Ctx))
-return std::nullopt;
-
-  auto const *InitExpr = VD->getAnyInitializer();
-  Expr::EvalResult Result;
-  if (!InitExpr->EvaluateAsConstantExpr(Result, Ctx))
-return std::nullopt;
-
-  return Result.Val;
-}
-
 CGDebugInfo::CGDebugInfo(CodeGenModule )
 : CGM(CGM), DebugKind(CGM.getCodeGenOpts().getDebugInfo()),
   DebugTypeExtRefs(CGM.getCodeGenOpts().DebugTypeExtRefs),
@@ -1724,7 +1701,6 @@ CGDebugInfo::CreateRecordStaticField(const VarDecl *Var, 
llvm::DIType *RecordTy,
   llvm::DIDerivedType *GV = DBuilder.createStaticMemberType(
   RecordTy, VName, VUnit, LineNumber, VTy, Flags, C, Tag, Align);
   StaticDataMemberCache[Var->getCanonicalDecl()].reset(GV);
-  StaticDataMemberDefinitionsToEmit.push_back(Var->getCanonicalDecl());
   return GV;
 }
 
@@ -5628,41 +5604,6 @@ void CGDebugInfo::EmitGlobalVariable(const ValueDecl 
*VD, const APValue ) {
   TemplateParameters, Align));
 }
 
-void CGDebugInfo::EmitGlobalVariable(const VarDecl *VD) {
-  assert(CGM.getCodeGenOpts().hasReducedDebugInfo());
-  if (VD->hasAttr())
-return;
-
-  const auto CacheIt = DeclCache.find(VD);
-  if (CacheIt != DeclCache.end())
-return;
-
-  const auto InitVal = evaluateConstantInitializer(VD, CGM.getContext());
-  if (!InitVal)
-return;
-
-  llvm::DIFile *Unit = nullptr;
-  llvm::DIScope *DContext = nullptr;
-  unsigned LineNo;
-  StringRef DeclName, LinkageName;
-  QualType T;
-  llvm::MDTuple *TemplateParameters = nullptr;
-  collectVarDeclProps(VD, Unit, LineNo, T, DeclName, LinkageName,
-  TemplateParameters, DContext);
-
-  auto Align = getDeclAlignIfRequired(VD, CGM.getContext());
-  llvm::DINodeArray Annotations = CollectBTFDeclTagAnnotations(VD);
-  llvm::DIExpression *InitExpr = createConstantValueExpression(VD, *InitVal);
-
-  // Omit linkage name for variable definitions that represent constants.
-  // There hasn't been a need from consumers yet to have it attached.
-  DeclCache[VD].reset(DBuilder.createGlobalVariableExpression(
-  TheCU, DeclName, /* LinkageName */ {}, Unit, LineNo,
-  getOrCreateType(T, Unit), true, true, InitExpr,
-  getOrCreateStaticDataMemberDeclarationOrNull(VD), TemplateParameters,
-  Align, Annotations));
-}
-
 void 

[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Revert "emit definitions for constant-initialized static data-members" (PR #74580)

2023-12-06 Thread Michael Buch via lldb-commits

https://github.com/Michael137 edited 
https://github.com/llvm/llvm-project/pull/74580
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [clang] [lldb] [clang][DebugInfo] Revert "emit variable definitions for constant-initialized static data-members" (PR #74580)

2023-12-06 Thread Michael Buch via lldb-commits

https://github.com/Michael137 created 
https://github.com/llvm/llvm-project/pull/74580

This commit reverts the changes in 
https://github.com/llvm/llvm-project/pull/71780 and all of its follow-up 
patches.

We got reports of the `.debug_names/.debug_gnu_pubnames/gdb_index/etc.` 
sections growing by a non-trivial amount for some large projects. While GCC 
does index definitions for static data member constants, they do so *only* for 
explicitly `constexpr` members. We were indexing *all* constant-initialized 
const-static members, which is likely where the significant size difference 
comes from. However, only emitting explicitly `constexpr` variables into the 
index doesn't seem like a good way forward, since from clang's perspective 
`const`-static integrals are `constexpr` too, and that shouldn't be any 
different in the debug-info component. Also, as new code moves to `constexpr` 
instead of `const` static for constants, such solution would just delay the 
growth of the Names index.

To prevent the size regression we revert to not emitting definitions for static 
data-members that have no location.

To support access to such constants from LLDB we'll most likely have to have to 
make LLDB find the constants by looking at the containing class first.

>From fe9624fdf898a2a629bb34f070d0e084f6dc0aa9 Mon Sep 17 00:00:00 2001
From: Michael Buch 
Date: Tue, 5 Dec 2023 14:52:00 +
Subject: [PATCH] [clang][DebugInfo] Revert "emit variable definitions for
 constant-initialized static data-members"

This commit reverts the changes in 
https://github.com/llvm/llvm-project/pull/71780
and all of its follow-up patches.

We got reports of the `.debug_names/.debug_gnu_pubnames/gdb_index/etc.`
sections growing by a non-trivial amount for some large projects. While
GCC does index definitions for static data member constants, they
do so *only* for explicitly `constexpr` members. We were indexing
*all* constant-initialized const-static members, which is likely where
the significant size difference comes from. However, only emitting explicitly
`constexpr` variables into the index doesn't seem like a good way
forward, since from clang's perspective `const`-static integrals
are `constexpr` too, and that shouldn't be any different in the debug-info
component. Also, as new code moves to `constexpr` instead of `const` static
for constants, such solution would just delay the growth of the Names index.

To prevent the size regression we revert to not emitting definitions for
static data-members that have no location.

To support access to such constants from LLDB we'll most likely have to
have to make LLDB find the constants by looking at the containing class
first.
---
 clang/lib/CodeGen/CGDebugInfo.cpp |  73 
 clang/lib/CodeGen/CGDebugInfo.h   |   6 -
 clang/test/CodeGenCXX/debug-info-class.cpp|  12 +-
 .../debug-info-static-inline-member.cpp   | 104 --
 .../CodeGenCXX/debug-info-static-member.cpp   |  20 +---
 .../SymbolFile/DWARF/DWARFASTParserClang.cpp  |  64 +--
 .../SymbolFile/DWARF/DWARFASTParserClang.h|  11 --
 7 files changed, 10 insertions(+), 280 deletions(-)
 delete mode 100644 clang/test/CodeGenCXX/debug-info-static-inline-member.cpp

diff --git a/clang/lib/CodeGen/CGDebugInfo.cpp 
b/clang/lib/CodeGen/CGDebugInfo.cpp
index 602e325e560f9..7cf661994a29c 100644
--- a/clang/lib/CodeGen/CGDebugInfo.cpp
+++ b/clang/lib/CodeGen/CGDebugInfo.cpp
@@ -69,29 +69,6 @@ static uint32_t getDeclAlignIfRequired(const Decl *D, const 
ASTContext ) {
   return D->hasAttr() ? D->getMaxAlignment() : 0;
 }
 
-/// Given a VarDecl corresponding to either the definition or
-/// declaration of a C++ static data member, if it has a constant
-/// initializer and is evaluatable, return the evaluated value.
-/// Returns std::nullopt otherwise.
-static std::optional
-evaluateConstantInitializer(const clang::VarDecl *VD,
-const clang::ASTContext ) {
-  assert(VD != nullptr);
-
-  if (!VD->isStaticDataMember())
-return std::nullopt;
-
-  if (!VD->isUsableInConstantExpressions(Ctx))
-return std::nullopt;
-
-  auto const *InitExpr = VD->getAnyInitializer();
-  Expr::EvalResult Result;
-  if (!InitExpr->EvaluateAsConstantExpr(Result, Ctx))
-return std::nullopt;
-
-  return Result.Val;
-}
-
 CGDebugInfo::CGDebugInfo(CodeGenModule )
 : CGM(CGM), DebugKind(CGM.getCodeGenOpts().getDebugInfo()),
   DebugTypeExtRefs(CGM.getCodeGenOpts().DebugTypeExtRefs),
@@ -1724,7 +1701,6 @@ CGDebugInfo::CreateRecordStaticField(const VarDecl *Var, 
llvm::DIType *RecordTy,
   llvm::DIDerivedType *GV = DBuilder.createStaticMemberType(
   RecordTy, VName, VUnit, LineNumber, VTy, Flags, C, Tag, Align);
   StaticDataMemberCache[Var->getCanonicalDecl()].reset(GV);
-  StaticDataMemberDefinitionsToEmit.push_back(Var->getCanonicalDecl());
   return GV;
 }
 
@@ -5628,41 +5604,6 @@ void CGDebugInfo::EmitGlobalVariable(const ValueDecl 
*VD, const APValue ) {
  

[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-06 Thread David Spickett via lldb-commits
=?utf-8?q?José?= L. Junior ,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 
<23100...@lums.edu.pk>,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 <23100...@lums.edu.pk>,
=?utf-8?q?José?= L. Junior 
Message-ID:
In-Reply-To: 



@@ -246,8 +246,8 @@ class Address {
   /// \see Address::DumpStyle
   bool Dump(Stream *s, ExecutionContextScope *exe_scope, DumpStyle style,
 DumpStyle fallback_style = DumpStyleInvalid,
-uint32_t addr_byte_size = UINT32_MAX,
-bool all_ranges = false) const;
+uint32_t addr_byte_size = UINT32_MAX, bool all_ranges = false,
+const char *pattern = nullptr) const;

DavidSpickett wrote:

I can't speak for Jonas here so just my interpretation - 

If you pass this as llvm::Regex, you're using the type system to signal to 
anyone reading this code that this is a regex pattern. Whereas using `const 
char*` and a comment that it is a regex could be missed by the reader.

test_func3 is the ideal here (though you may have to remove const, you'll find 
that out later). Deleting the copy constructor is usually done when you have a 
move only type, which is usually something that contains a resource where 
copying it doesn't make sense.

I think something like `test_func3(strm, std::move(regex2));` might fix it. At 
least, that's the obvious way to try to move construct the regex inside the 
optional.

Can you pass `std::make_optional(name)` to func3 maybe?

If all this is too much hassle in the end, using a pointer is the fallback 
option. As long as the lifetimes are ok which I'm guessing they are. By which I 
mean, nothing earlier in the callstack is going to destroy the pattern before 
you end up using it.

https://github.com/llvm/llvm-project/pull/69422
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-06 Thread via lldb-commits
=?utf-8?q?José?= L. Junior ,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 
<23100...@lums.edu.pk>,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 <23100...@lums.edu.pk>,
=?utf-8?q?José?= L. Junior 
Message-ID:
In-Reply-To: 


https://github.com/taalhaataahir0102 edited 
https://github.com/llvm/llvm-project/pull/69422
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-06 Thread via lldb-commits
=?utf-8?q?José?= L. Junior ,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 
<23100...@lums.edu.pk>,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 <23100...@lums.edu.pk>,
=?utf-8?q?José?= L. Junior 
Message-ID:
In-Reply-To: 


https://github.com/taalhaataahir0102 edited 
https://github.com/llvm/llvm-project/pull/69422
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-06 Thread via lldb-commits
=?utf-8?q?José?= L. Junior ,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 
<23100...@lums.edu.pk>,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 <23100...@lums.edu.pk>,
=?utf-8?q?José?= L. Junior 
Message-ID:
In-Reply-To: 



@@ -246,8 +246,8 @@ class Address {
   /// \see Address::DumpStyle
   bool Dump(Stream *s, ExecutionContextScope *exe_scope, DumpStyle style,
 DumpStyle fallback_style = DumpStyleInvalid,
-uint32_t addr_byte_size = UINT32_MAX,
-bool all_ranges = false) const;
+uint32_t addr_byte_size = UINT32_MAX, bool all_ranges = false,
+const char *pattern = nullptr) const;

taalhaataahir0102 wrote:

Hi @DavidSpickett . Tried this incremental approach:

```
static void test_func1(Stream , llvm::Regex *regex_param = nullptr) {
  strm.Printf("Inside test_func1\n");
}

static void test_func2(Stream , llvm::Regex _param) {
  strm.Printf("Inside test_func2\n");
}

static void test_func3(Stream , const std::optional 
regex_param = std::nullopt) {
  strm.Printf("Inside test_func3\n");
}

static void test_func4(Stream , const std::optional 
_param = std::nullopt) {
  strm.Printf("Inside test_func4\n");
}

static uint32_t LookupSymbolInModule(CommandInterpreter ,
 Stream , Module *module,
 const char *name, bool name_is_regex,
 bool verbose, bool all_ranges) {
  llvm::Regex regex1(name);
  std::optional regex2 = std::make_optional(name);

  test_func1(strm, );
  test_func2(strm, regex1);
  // test_func3(strm, regex2);
  test_func4(strm, regex2);
  ...
  ...
  }
```

In test1, used the same logic like used previously i.e., function accepting 
pointer to `llvm::Regex` and default value is null pointer. 
In test2 passed `llvm::regex` by reference but could not give a default value. 
In test 3 used the `std::optional` but was getting the error 
mentioned above i.e., use of deleted functions. The exact error is:
```
error: use of deleted function ‘std::optional::optional(const 
std::optional&)’
 1611 |   test_func3(strm, regex2)
```
I believe it's due to the deletion of copy constructor which you mentioned. 
In test 4 passing the reference of `std::optional` to the function 
which is working fine as expected. Will use this one to pass the pattern now.
I'm a little confused. Right now, we're passing the pattern as 
`llvm::StringRef`, and finally when we reach `PutCStringColorHighlighted` we 
convert it to llvm::Regex:
`llvm::Regex reg_pattern(pattern);`
What will be the benefit of converting `const char* name` to 
`std::optional`  from the very beginning and than passing it till 
we reach `PutCStringColorHighlighted`? 樂

https://github.com/llvm/llvm-project/pull/69422
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-06 Thread via lldb-commits
=?utf-8?q?José?= L. Junior ,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 
<23100...@lums.edu.pk>,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 <23100...@lums.edu.pk>,
=?utf-8?q?José?= L. Junior 
Message-ID:
In-Reply-To: 


https://github.com/taalhaataahir0102 edited 
https://github.com/llvm/llvm-project/pull/69422
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits


[Lldb-commits] [lldb] [lldb] colorize symbols in image lookup with a regex pattern (PR #69422)

2023-12-06 Thread David Spickett via lldb-commits
=?utf-8?q?José?= L. Junior ,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 
<23100...@lums.edu.pk>,taalhaataahir0102
 <23100...@lums.edu.pk>,taalhaataahir0102 <23100...@lums.edu.pk>,
=?utf-8?q?José?= L. Junior 
Message-ID:
In-Reply-To: 



@@ -70,6 +72,31 @@ size_t Stream::PutCString(llvm::StringRef str) {
   return bytes_written;
 }
 
+void Stream::PutCStringColorHighlighted(llvm::StringRef text,
+const char *pattern) {
+  if (!pattern) {
+PutCString(text);
+return;
+  }
+
+  // If pattern is not nullptr, we should use color
+  llvm::Regex reg_pattern(pattern);
+  llvm::SmallVector matches;
+  llvm::StringRef remaining = text;
+  std::string format_str = lldb_private::ansi::FormatAnsiTerminalCodes(
+  "${ansi.fg.red}%.*s${ansi.normal}");

DavidSpickett wrote:

I assume if we have no target set we won't know whether to colour anything, so 
we'd default to no colours. Which means the prefix/suffix can default to empty 
string. Which is exactly what you've suggested.

Worst case in some situation it doesn't highlight and if the user cares they 
can open an issue for it.

I expect the SymbolContext can live without a target in some scenario, if you 
want to find out what, find somewhere in SymbolContext that null checks target, 
remove the check and see what tests fail.

https://github.com/llvm/llvm-project/pull/69422
___
lldb-commits mailing list
lldb-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/lldb-commits