732 Commits

Author SHA1 Message Date
Luís Marques
c111fe46a1 [Support] Implement findModulesAndOffsets on Apple 64-bit platforms
To have line number information in stack traces (per stack frame) it's
necessary to implement findModulesAndOffsets.

Differential Revision: https://reviews.llvm.org/D142282
2023-03-05 12:20:47 +00:00
Luís Marques
6190356914 Revert "[Support] Implement findModulesAndOffsets on Apple 64-bit platforms"
This reverts commit b8b8aa6f06458212193c4202291c9f68364b2025.
It broke AIX.
2023-03-02 21:44:34 +00:00
Luís Marques
b8b8aa6f06 [Support] Implement findModulesAndOffsets on Apple 64-bit platforms
To have line number information in stack traces (per stack frame) it's
necessary to implement findModulesAndOffsets.

Differential Revision: https://reviews.llvm.org/D142282
2023-03-02 10:58:56 +00:00
Fangrui Song
1c417da0f0 Remove uses of ATOMIC_VAR_INIT
ATOMIC_VAR_INIT has a trivial definition `#define ATOMIC_VAR_INIT(value) (value)`,
is deprecated in C17/C++20, and will be removed in newer standards.
2023-02-24 13:43:12 -08:00
Alex Brachet
3e57aa304f [llvm-driver] Reinvoke clang as described by llvm driver extra args
Differential Revision: https://reviews.llvm.org/D137800
2023-02-10 19:42:32 +00:00
Owen Anderson
e4e0f93307 Remove the ThreadLocal template from LLVM.
This has been obsoleted by C++ thread_local for a long time.
As far as I know, Xcode was the last supported toolchain to add
support for C++ thread_local in 2016.

As a precaution, use LLVM_THREAD_LOCAL which provides even greater
backwards compatibility, allowing this to function even pre-C++11
versions of GCC.

Reviewed By: nikic

Differential Revision: https://reviews.llvm.org/D141349
2023-01-10 21:07:52 -07:00
Owen Anderson
ef9aa34f02 Revert "Remove the ThreadLocal template from LLVM."
This reverts commit 54d78b639b9c18b42abd4fac5c6e76105f06b3ef.
2023-01-09 21:21:38 -07:00
Owen Anderson
54d78b639b Remove the ThreadLocal template from LLVM.
This has been obsoleted by C++ thread_local for a long time.
As far as I know, Xcode was the last supported toolchain to add
support for C++ thread_local in 2016.

As a precaution, use LLVM_THREAD_LOCAL which provides even greater
backwards compatibility, allowing this to function even pre-C++11
versions of GCC.

Reviewed By: majnemer

Differential Revision: https://reviews.llvm.org/D141347
2023-01-09 21:12:27 -07:00
Matt Arsenault
24e3086c89 Support: Fix broken C++ marker 2022-12-22 14:40:50 -05:00
Matt Arsenault
eb93b8774e Support: Add polling option to sys::Wait
Currently the process is terminated after the timeout. Add an option
to let the process resume after the timeout instead.

https://reviews.llvm.org/D138952
2022-12-22 12:38:59 -05:00
Archibald Elliott
f09cf34d00 [Support] Move TargetParsers to new component
This is a fairly large changeset, but it can be broken into a few
pieces:
- `llvm/Support/*TargetParser*` are all moved from the LLVM Support
  component into a new LLVM Component called "TargetParser". This
  potentially enables using tablegen to maintain this information, as
  is shown in https://reviews.llvm.org/D137517. This cannot currently
  be done, as llvm-tblgen relies on LLVM's Support component.
- This also moves two files from Support which use and depend on
  information in the TargetParser:
  - `llvm/Support/Host.{h,cpp}` which contains functions for inspecting
    the current Host machine for info about it, primarily to support
    getting the host triple, but also for `-mcpu=native` support in e.g.
    Clang. This is fairly tightly intertwined with the information in
    `X86TargetParser.h`, so keeping them in the same component makes
    sense.
  - `llvm/ADT/Triple.h` and `llvm/Support/Triple.cpp`, which contains
    the target triple parser and representation. This is very intertwined
    with the Arm target parser, because the arm architecture version
    appears in canonical triples on arm platforms.
- I moved the relevant unittests to their own directory.

And so, we end up with a single component that has all the information
about the following, which to me seems like a unified component:
- Triples that LLVM Knows about
- Architecture names and CPUs that LLVM knows about
- CPU detection logic for LLVM

Given this, I have also moved `RISCVISAInfo.h` into this component, as
it seems to me to be part of that same set of functionality.

If you get link errors in your components after this patch, you likely
need to add TargetParser into LLVM_LINK_COMPONENTS in CMake.

Differential Revision: https://reviews.llvm.org/D137838
2022-12-20 11:05:50 +00:00
Fangrui Song
b1df3a2c0b [Support] llvm::Optional => std::optional
https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-16 08:49:10 +00:00
Matt Arsenault
7fb7c78c46 Support: Try to fix msan error in sys::Wait 2022-12-14 14:09:34 -05:00
Matt Arsenault
15a6e3c636 Support: Make Wait's SecondsToWait be std::optional [NFC]
I found the interaction between SecondsToWait and
WaitUntilChildTerminates confusing. Rather than have a boolean to
ignore the value of SecondsToWait, combine these into one Optional
parameter.
2022-12-14 09:56:10 -05:00
Krzysztof Parzyszek
3c255f679c Process: convert Optional to std::optional
This applies to GetEnv and FindInEnvPath.
2022-12-06 09:56:14 -08:00
Kazu Hirata
aadaaface2 [llvm] Use std::nullopt instead of None (NFC)
This patch mechanically replaces None with std::nullopt where the
compiler would warn if None were deprecated.  The intent is to reduce
the amount of manual work required in migrating from Optional to
std::optional.

This is part of an effort to migrate from llvm::Optional to
std::optional:

https://discourse.llvm.org/t/deprecating-llvm-optional-x-hasvalue-getvalue-getvalueor/63716
2022-12-02 21:11:44 -08:00
Jan Svoboda
abf0c6c0c0 Use CTAD on llvm::SaveAndRestore
Reviewed By: dblaikie

Differential Revision: https://reviews.llvm.org/D139229
2022-12-02 15:36:12 -08:00
Matt Arsenault
e748db0f7f Support: Convert Program APIs to std::optional 2022-12-01 17:00:44 -05:00
Archibald Elliott
3c97f6cab9 [Support] Move getHostNumPhysicalCores to Threading.h
This change is focussed on simplifying `Support/Host.h` to only do
target detection. In this case, this function is close in usage to
existing functions in `Support/Threading.h`, so I moved it into there.
The function is also renamed to `llvm::get_physical_cores()` to match
the style of threading's functions.

The big change here is that now if you have threading disabled,
`llvm::get_physical_cores()` will return -1, as if it had not been able
to work out the right info. This is due to how Threading.cpp includes
OS-specific code/headers. This seems ok, as if threading is disabled,
LLVM should not need to know the number of physical cores.

Differential Revision: https://reviews.llvm.org/D137836
2022-11-29 13:14:13 +00:00
Alexandre Ganea
f1aa7348d3 [Support] Apply clang-format on .inc files. NFC.
Apply clang-format on llvm/lib/Support/Windows/ and llvm/lib/Support/Unix/ since .inc files in these folders aren't picked up by default. Eventually we need to add this extension in the monorepo .clang-format file.

Differential Revision: https://reviews.llvm.org/D138714
2022-11-26 09:36:43 -05:00
Fangrui Song
875adb4007 Host: Internalize computeHostNumPhysicalCores/computeHostNumHardwareThreads
Windows computeHostNumPhysicalCores is defined by Threading.cpp. Leave it
unchanged.
2022-11-23 21:09:45 -08:00
Fangrui Song
93b553e3f2 Revert "Host: Internalize computeHostNumPhysicalCores/computeHostNumHardwareThreads"
This reverts commit 9969ceb36b440eaafa17c486f29a69c7a7da3b3b.

On Windows:

lld-link: error: undefined symbol: int __cdecl computeHostNumPhysicalCores(void)
>>> referenced by LLVMSupport.lib(Support.Host.obj):(int __cdecl llvm::sys::getHostNumPhysicalCores(void))
2022-11-23 20:12:16 -08:00
Fangrui Song
9969ceb36b Host: Internalize computeHostNumPhysicalCores/computeHostNumHardwareThreads 2022-11-23 17:44:04 -08:00
Bill Wendling
4787efa380 Revert "Reapply: Add an error message to the default SIGPIPE handler"
This patch is spamming compiles with unhelpful and confusing messages.
E.g. the Linux kernel uses "grep -q" in several places. It's meant to
quit with a return code of zero when the first match is found. This can
cause a SIGPIPE signal, but that's expected, and there's no way to turn
this error message off to avoid spurious error messages.

UNIX03 apparently doesn't require printing an error message on SIGPIPE,
but specifically when there's an error on the stdout stream in a normal
program flow, e.g. when SIGPIPE trap is disabled.

A separate patch is planned to address the specific case we care most
about (involving llvm-nm).

This reverts commit b89bcefa6202e310eb3167dd1c37f1807377ec8d.

Link: https://github.com/llvm/llvm-project/issues/59037
Link: https://github.com/ClangBuiltLinux/linux/issues/1651

Differential Revision: https://reviews.llvm.org/D138244
2022-11-18 11:17:25 -08:00
Yabin Cui
22339e52da [Support] Use thread safe version of getpwuid and getpwnam.
OpenGroup specification doesn't require getpwuid and getpwnam
to be thread-safe. And musl libc has a not thread-safe implementation.
When building clang with musl, this can make clang-scan-deps crash.

Reviewed By: pirama

Differential Revision: https://reviews.llvm.org/D137864
2022-11-14 17:48:44 +00:00
Fangrui Song
6c927f2a86 Canonicalize PowerPC detection macros to __powerpc__ 2022-11-06 17:29:45 -08:00
raghavmedicherla
5d3cf8267f Revert "Support: Add mapped_file_region::sync(), equivalent to msync"
This reverts commit 142f51fc2f448845f6a32e767ffaa2b665eea11f.

This shouldn't be committed, it got committed accidentally.
2022-09-08 12:49:52 -04:00
Joe Loser
5e96cea1db [llvm] Use std::size instead of llvm::array_lengthof
LLVM contains a helpful function for getting the size of a C-style
array: `llvm::array_lengthof`. This is useful prior to C++17, but not as
helpful for C++17 or later: `std::size` already has support for C-style
arrays.

Change call sites to use `std::size` instead.

Differential Revision: https://reviews.llvm.org/D133429
2022-09-08 09:01:53 -06:00
raghavmedicherla
142f51fc2f Support: Add mapped_file_region::sync(), equivalent to msync
Add mapped_file_region::sync(), equivalent to POSIX msync,
synchronizing written content to disk without unmapping the region.
Asserts if the mode is not mapped_file_region::readwrite.

Note that I don't have access to a Windows machine, so I can't
easily run those unit tests.

Change by dexonsmith

Differential Revision: https://reviews.llvm.org/D95494
2022-09-06 16:46:37 -04:00
Ben Langmuir
79f34ae7fe [llvm] Fix assertion when stat fails in remove_directories
We were dereferencing an empty Optional if IgnoreErrors was true and the
stat failed.

rdar://60887887

Differential Revision: https://reviews.llvm.org/D131791
2022-08-12 11:32:04 -07:00
Nicolai Hähnle
ede600377c ManagedStatic: remove many straightforward uses in llvm
(Reapply after revert in e9ce1a588030d8d4004f5d7e443afe46245e9a92 due to
Fuchsia test failures. Removed changes in lib/ExecutionEngine/ other
than error categories, to be checked in more detail and reapplied
separately.)

Bulk remove many of the more trivial uses of ManagedStatic in the llvm
directory, either by defining a new getter function or, in many cases,
moving the static variable directly into the only function that uses it.

Differential Revision: https://reviews.llvm.org/D129120
2022-07-10 10:29:15 +02:00
Nicolai Hähnle
e9ce1a5880 Revert "ManagedStatic: remove many straightforward uses in llvm"
This reverts commit e6f1f062457c928c18a88c612f39d9e168f65a85.

Reverting due to a failure on the fuchsia-x86_64-linux buildbot.
2022-07-10 09:54:30 +02:00
Nicolai Hähnle
e6f1f06245 ManagedStatic: remove many straightforward uses in llvm
Bulk remove many of the more trivial uses of ManagedStatic in the llvm
directory, either by defining a new getter function or, in many cases,
moving the static variable directly into the only function that uses it.

Differential Revision: https://reviews.llvm.org/D129120
2022-07-10 09:15:08 +02:00
Tim Northover
b89bcefa62 Reapply: Add an error message to the default SIGPIPE handler
UNIX03 conformance requires utilities to flush stdout before exiting and raise
an error if writing fails. Flushing already happens on a call to exit
and thus automatically on a return from main. Write failure is then
detected by LLVM's default SIGPIPE handler. The handler already exits with
a non-zero code, but conformance additionally requires an error message.

First reapply attempt I hadn't noticed the test had changed, hopefully this
goes better.
2022-06-09 20:13:45 +01:00
Tim Northover
4badd4d40d Revert "Add an error message to the default SIGPIPE handler"
It broke PPC bots.
2022-06-09 19:01:28 +01:00
Tim Northover
51b557adc1 Add an error message to the default SIGPIPE handler
UNIX03 conformance requires utilities to flush stdout before exiting and raise
an error if writing fails. Flushing already happens on a call to exit
and thus automatically on a return from main. Write failure is then
detected by LLVM's default SIGPIPE handler. The handler already exits with
a non-zero code, but conformance additionally requires an error message.
2022-06-08 16:34:12 +01:00
Reid Kleckner
b1c7889f32 [config] Remove RETSIGTYPE from config.h.cmake, NFC
This doesn't need to be configurable. It was hardcoded to void in all
LLVM build systems.
2022-06-07 11:35:25 -07:00
Chris Bieneman
f06abbb393 LLVM Driver Multicall tool
This patch adds an llvm-driver multicall tool that can combine multiple
LLVM-based tools. The build infrastructure is enabled for a tool by
adding the GENERATE_DRIVER option to the add_llvm_executable CMake
call, and changing the tool's main function to a canonicalized
tool_name_main format (i.e. llvm_ar_main, clang_main, etc...).

As currently implemented llvm-driver contains dsymutil, llvm-ar,
llvm-cxxfilt, llvm-objcopy, and clang (if clang is included in the
build).

llvm-driver can be enabled from builds by setting
LLVM_TOOL_LLVM_DRIVER_BUILD=On.

There are several limitations in the current implementation, which can
be addressed in subsequent patches:

(1) the multicall binary cannot currently properly handle
multi-dispatch tools. This means symlinking llvm-ranlib to llvm-driver
will not properly result in llvm-ar's main being called.
(2) the multicall binary cannot be comprised of tools containing
conflicting cl::opt options as the global cl::opt option list cannot
contain duplicates.

These limitations can be addressed in subsequent patches.

Differential revision: https://reviews.llvm.org/D109977
2022-06-06 04:27:32 +00:00
Med Ismail Bennani
b3718bc467 [llvm/Support] Fallback to $TERM if terminfo has no "colors" capability
It can happen on macOS that terminal doesn't report the "colors"
capability in the terminfo database, in which case `tigetnum` returns -1.

This doesn't mean however that the terminal doesn't supports color, it
just means that the capability is absent from the terminal description.

In that case, we should still fallback to the checking the $TERM
environment variable to see if it supports ANSI escapes codes.

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

Signed-off-by: Med Ismail Bennani <medismail.bennani@gmail.com>
2022-05-18 18:22:46 -07:00
stk
9902a0945d Add ThreadPriority::Low, and use QoS class Utility on Mac
On Apple Silicon Macs, using a Darwin thread priority of PRIO_DARWIN_BG seems to
map directly to the QoS class Background. With this priority, the thread is
confined to efficiency cores only, which makes background indexing take forever.

Introduce a new ThreadPriority "Low" that sits in the middle between Background
and Default, and maps to QoS class "Utility" on Mac. Make this new priority the
default for indexing. This makes the thread run on all cores, but still lowers
priority enough to keep the machine responsive, and not interfere with
user-initiated actions.

I didn't change the implementations for Windows and Linux; on these systems,
both ThreadPriority::Background and ThreadPriority::Low map to the same thread
priority. This could be changed as a followup (e.g. by using SCHED_BATCH for Low
on Linux).

See also https://github.com/clangd/clangd/issues/1119.

Reviewed By: sammccall, dgoldman

Differential Revision: https://reviews.llvm.org/D124715
2022-05-16 10:01:49 +02:00
Tim Northover
7b53a45e14 Revert "Add an error message to the default SIGPIPE handler"
It broke a PPC bot, for not immediately obvious reasons.
2022-05-12 08:31:20 +01:00
Tim Northover
e845f899e6 Add an error message to the default SIGPIPE handler
UNIX03 conformance requires utilities to flush stdout before exiting and raise
an error if writing fails. Flushing already happens on a call to exit
and thus automatically on a return from main. Write failure is then
detected by LLVM's default SIGPIPE handler. The handler already exits with
a non-zero code, but conformance additionally requires an error message.
2022-05-12 08:00:06 +01:00
Fangrui Song
d351f54a07 [Support] Remove unused/uncompilable !HAVE_PTHREAD_GETSPECIFIC code path
lib/Support/ThreadLocal.cpp has been uncompilable since rL158346 (2012-06) when
`data` became a char array. The error looks like
```
...llvm/lib/Support/Unix/ThreadLocal.inc:66:57: error: array type 'char[8]' is not assignable
void ThreadLocalImpl::setInstance(const void* d) { data = const_cast<void*>(d);}
```
2022-04-11 14:20:33 -07:00
Mateusz Guzik
1a6d571174 [Support] Skip attempts to access /proc/self/fd on FreeBSD
In contrast to Linux it does not provide entries which can be readlinked
-- these are just regular files, not giving the expected outcome. That's
on top of procfs not being mounted by default to begin with.

This is probably the case on other BSDs as well, so I expect there will
be more ifdefs added down the road.

Reviewed By: emaste, dim

Differential Revision: https://reviews.llvm.org/D122545
2022-03-27 20:19:41 +02:00
serge-sans-paille
fbbc41f8dd Cleanup include: TableGen
This also includes a few cleanup from Support.

Discourse thread: https://discourse.llvm.org/t/include-what-you-use-include-cleanup
Differential Revision: https://reviews.llvm.org/D121331
2022-03-11 11:41:32 +01:00
Nikita Popov
b66b3247f5 [Support] Use posix_madvise() if available
This is a followup to D119695 using the suggestion by joerg. Rather
than manually declaring madvise() on __sun__, this uses
posix_madvise() if available, which does get declared properly on
Illumos.

Differential Revision: https://reviews.llvm.org/D119856
2022-02-16 09:36:41 +01:00
Nikita Popov
8f55cd0178 [Support] Fix build on illumos
D116366 added a call to madvise() in Path.inc. Unfortunately,
Illumos does not declare this function if _XOPEN_SOURCE is defined
(which it is by default) and we need to provide the declaration
manually. This is the same workaround used in sanitizers:
ee423d93ea/compiler-rt/lib/sanitizer_common/sanitizer_solaris.cpp (L77-L85)

Differential Revision: https://reviews.llvm.org/D119695
2022-02-15 09:42:40 +01:00
Kazu Hirata
3a3cb929ab [llvm] Use = default (NFC) 2022-02-06 22:18:35 -08:00
Benjamin Kramer
f15014ff54 Revert "Rename llvm::array_lengthof into llvm::size to match std::size from C++17"
This reverts commit ef8206320769ad31422a803a0d6de6077fd231d2.

- It conflicts with the existing llvm::size in STLExtras, which will now
  never be called.
- Calling it without llvm:: breaks C++17 compat
2022-01-26 16:55:53 +01:00
serge-sans-paille
ef82063207 Rename llvm::array_lengthof into llvm::size to match std::size from C++17
As a conquence move llvm::array_lengthof from STLExtras.h to
STLForwardCompat.h (which is included by STLExtras.h so no build
breakage expected).
2022-01-26 16:17:45 +01:00