Age | Commit message (Collapse) | Author | Files | Lines |
|
Note the implementation of
zoned_time& operator=(const local_time<Duration>& lt);
is not correct; however the wording cannot be easily implemented. It could
be if the object caches the local_time assigned. However this does not
seem to intended. The current implementation matches MSVC STL and
libstdc++.
Implements parts of:
- P0355 Extending to chrono Calendars and Time Zones
|
|
Completes
- LWG3225 zoned_time converting constructor shall not be noexcept
- LWG3226 zoned_time constructor from string_view should accept zoned_time<Duration2, TimeZonePtr2>
Implements parts of:
- P0355 Extending to chrono Calendars and Time Zones
|
|
This implements the class, its non-templated constructors and its getters to
verify the construction.
Completes
- LWG3224 zoned_time constructor from TimeZonePtr does not specify initialization of tp_
Implements parts of:
- P0355 Extending chrono to Calendars and Time Zones
|
|
This moves the files to libcxx/src/experimental/ as discussed in #90394.
Fixes: https://github.com/llvm/llvm-project/issues/94902
|
|
If more than one disassembler is created for a context then allow reuse
of existing constants.
Warn if constants values do not match.
|
|
The noexcept specifiers of dependent lambdas would be transformed and
rebuilt, where the map of instantiation should also contain captured
variables in case they are used from the noexcept specifier.
I also uncovered another assertion failure while at it. However, I
decided to leave it as-is because 1) that doesn't appear to be the case
in the release version and 2) fixing that might lead to ABI breakage.
Anyhow, the case has been added to the test comment.
Fixes https://github.com/llvm/llvm-project/issues/95735
|
|
Reverts llvm/llvm-project#97924
|
|
Headers for https://github.com/llvm/llvm-project/pull/97504
|
|
|
|
|
|
This defines the OutlinedHashTree class.
It contains sequences of stable hash values of instructions that have
been outlined. This OutlinedHashTree can be used to track the outlined
instruction sequences across modules. A trie structure is used in its
implementation, allowing for a compact sharing of common prefixes.
This is a patch for
https://discourse.llvm.org/t/rfc-enhanced-machine-outliner-part-2-thinlto-nolto/78753.
|
|
|
|
|
|
Adds `dlopen` and friends. This is needed as part of the effort to
compile `libunwind` + `libc` without baremetal mode. This is part of
https://github.com/llvm/llvm-project/issues/97191. This should still be
spec compliant, since `dlopen` always returns `NULL` and `dlerror`
always returns an error message.
> If dlopen() fails for any reason, it returns NULL.
> The function dlclose() returns 0 on success, and nonzero on error.
> Since the value of the symbol could actually be NULL (so that a NULL
return from dlsym() need not indicate an error), the correct way to test
for an error is to call dlerror() to clear any old error conditions,
then call dlsym(), and then call dlerror() again, saving its return
value into a variable, and check whether this saved value is not NULL.
See:
- https://linux.die.net/man/3/dlopen
|
|
This PR fixes linting issues discovered by `cppcheck`.
Fixes: https://github.com/llvm/llvm-project/issues/96863
|
|
|
|
|
|
by placing `Operation` next to a 4-byte member.
Refactor the union representation so that it is easy to add a pointer
member for .cfi_label support without increasing the total size. There
are two primary forms (RI and RR) and RIA for AMDGPU-specific
.cfi_llvm_def_aspace_cfa.
|
|
LAA doesn't keep references to IR outside the loop or references to
SCEVs that may be invalidated, unless runtime checks are needed (either
memory or SCEV predicates). For the current LAA users, it should be
sufficient to invalidate entries for loops that require runtime checks,
thus avoiding analyzing loops again unnecessarily.
This helps reduce compile-time, in particular when removing the
restrictions added in 234cc40adc6.
https://llvm-compile-time-tracker.com/compare.php?from=73894dba2cdbcc00678d0c13a6b61765675f60b4&to=05c6bdc41b5f63696ebeb7116325725fa94f66d6&stat=instructions:u
|
|
https://cplusplus.github.io/CWG/issues/2137.html
This change was previously made as part of
924701311aa79180e86ad8ce43d253f27d25ec7d (#77768) and later reverted in
6e4930c67508a90bdfd756f6e45417b5253cd741
This change is still needed because the comment is still true: A
standards-conformant compiler is currently supposed to fail this test.
This also means that any future work on CWG2137 with Clang would not
need to modify the libc++ test suite
|
|
This makes the test suite forward-compatible with future versions of macOS.
Previously, the Lit features were built in a way that they would assume
that any newer macOS version doesn't contain any version of LLVM, which
doesn't make sense.
|
|
targetting Windows"
This reverts commit 593f708118aef792f434185547f74fedeaf51dd4.
|
|
ToT targetting Windows"
This reverts commit 10e1b935e5d9017067207d62ababa733df088ecd.
|
|
targetting Windows"
This reverts commit cf1ded3ac248ad4feeed7b4dd20c60b7e3c40339.
|
|
GCC 14 has been released a while ago. We've updated the CI to use GCC 14
now. This removes any old annotations in the tests and updates the
documentation to reflect the updated version requirements.
|
|
|
|
When `-fixup_chains`/`-init_offsets` is used, a different section,
`__init_offsets` is synthesized from `__mod_init_func`. If there are any
symbols defined inside `__mod_init_func`, they are added to the symbol
table unconditionally while processing the input files. Later, when
querying these symbols' addresses (when constructing the symtab or
exports trie), we crash with a null deref, as there is no output section
assigned to them.
Just making the symbols point to `__init_offsets` is a bad idea, as the
new section stores 32-bit integers instead of 64-bit pointers; accessing
the symbols would not do what the programmer intended. We should
entirely omit them from the output. This is what ld64 and ld-prime do.
This patch uses the same mechanism as dead-stripping to mark these
symbols as not needed in the output. There might be nicer fixes than the
workaround, this is discussed in #97155.
Fixes https://github.com/llvm/llvm-project/pull/79894#issuecomment-1944092892
Fixes #94716
|
|
|
|
Outlining these patterns has a significant impact on the overall stack
frame size of llvm::UpgradeIntrinsicCall. This is helpful for scenarios
where compilation threads are stack-constrained. The overall impact is
low when using clang as the host compiler, but very pronounced when
using MSVC 2022 with release builds.
Clang: 1,624 -> 824 bytes
MSVC: 23,560 -> 6,120 bytes
|
|
rounding modes (#97464)
I also fixed a comment in sinpif.cpp in the first commit. Should this be
included in this PR?
All tests were passed, including the exhaustive test.
CC: @lntue
|
|
As discussed before with @cor3ntin before
(https://github.com/llvm/llvm-project/pull/94752) here is the
simplification of the release note written for the previously mentioned
PR and the removal of a comment that is no longer useful.
(Sorry for creating this PR this late.)
Co-authored-by: Gabor Spaits <Gabor.Spaits@hightec-rt.com>
|
|
Reuse the APInt::BitWidth to eliminate DynamicAPInt::HoldsLarge, cutting
the size of DynamicAPInt by four bytes. This is implemented by making
DynamicAPInt a friend of SlowDynamicAPInt and APInt, so it can directly
access SlowDynamicAPInt::Val and APInt::BitWidth.
We get a speedup of 4% with this patch.
|
|
This patch adds `CXXPre26Compat` and `CXXPre26CompatPedantic` groups
(which are concerned with new features not available in older language
modes) to `CXX98Compat`, etc. This way, if user has `-Wc++20-compat` and
they use pack indexing, they will be warned.
Ideally this should have been done when C++26 groups were created, but
we shipped two releases of Clang since then.
|
|
(#97887)
This reverts commit 88b26293a24bdd85fce2b2f7191cc0a5bc0cecfe due to
failures of
CodeGen/AArch64/speculation-hardening-sls-blra.mir
|
|
Make SLS Hardening pass handle BLRA* instructions the same way it
handles BLR. The thunk names have the form
__llvm_slsblr_thunk_xN for BLR thunks
__llvm_slsblr_thunk_(aaz|abz)_xN for BLRAAZ and BLRABZ thunks
__llvm_slsblr_thunk_(aa|ab)_xN_xM for BLRAA and BLRAB thunks
Now there are about 1800 possible thunk names, so do not rely on linear
thunk function's name lookup and parse the name instead.
|
|
#96207 was reverted but the improvements to the documentation of the
dialect conversion are still useful.
|
|
Elements in nested namespaces in the std namespace do not use fully
qualified names in libc++. This adjusts a few cases found.
|
|
In #90373 size deallocation was enabled by default. Some test were
disabled to propagate the clang changes to the libc++ CI. These changes
have been propagated so the test filter can be updated.
|
|
reverts https://github.com/llvm/llvm-project/pull/97540
which broke clangs standalone build
|
|
(#97146)
fixes https://github.com/llvm/llvm-project/issues/96670
The cause is that we might return a lvalue here at
https://github.com/llvm/llvm-project/blob/3e53c97d33210db68188e731e93ee48dbaeeae32/clang/lib/AST/ExprConstant.cpp#L15861-L15865
This PR will make sure we return a rvalue in `FastEvaluateAsRValue`.
|
|
|
|
When using Clang as a compiler, use Clang to normalize the triple that's
used to construct path for runtime library build and install paths. This
ensures that paths are consistent and avoids the issue where the build
uses a different triple spelling.
Differential Revision: https://reviews.llvm.org/D140925
|
|
|
|
(#78565)
We currently don't fold a vmerge if it has an implicit-def passthru and
its true operand also has a passthru (i.e. tied dest).
This restriction was added in https://reviews.llvm.org/D151596, back
whenever we had separate TU/TA pseudos. It looks like it was added
because the policy might not have been handled correctly.
However the policy should be set correctly if we relax this restriction
today, since we compute the policy differently now that we have removed
the TU/TA distinction in our pseudos.
We use a TUMU policy, and relax it to TAMU iff the vmerge's passthru is
implicit-def.
The reasoning behind this being that the tail elements always come from
the vmerge's passthru[^1], so if vmerge's passthru is implicit-def then
the tail is also implicit-def. So a tail agnostic policy is OK.
[^1]: unless the VL was shrunk, but in this case which case we
conservatively use TUMU.
|
|
|
|
We're creating a load and a splat. The splat doesn't use the extended
bits so it doesn't matter what extend we use.
|
|
This fixes:
```
MASM : warning A4018:invalid command-line option : -U_GLIBCXX_ASSERTIONS
```
|
|
Windows
|
|
targetting Windows
|
|
targetting Windows
|