[libc++][NFC] Rewrite function call on two lines for clarity (#79141)
Previously, there was a ternary conditional with a less-than comparison
appearing inside a template argument, which was really confusing because
of the <...> of the function template. This patch rewrites the same
statement on two lines for clarity.
Merge commit d129ea8d2fa3 from llvm-project (by Vitaly Buka):
[libcxx] Align `__recommend() + 1` by __endian_factor (#90292)
This is detected by asan after #83774
Allocation size will be divided by `__endian_factor` before storing. If
it's not aligned,
we will not be able to recover allocation size to pass into
`__alloc_traits::deallocate`.
we have code like this
```
auto __allocation = std::__allocate_at_least(__alloc(), __recommend(__sz) + 1);
__p = __allocation.ptr;
__set_long_cap(__allocation.count);
void __set_long_cap(size_type __s) _NOEXCEPT {
__r_.first().__l.__cap_ = __s / __endian_factor;
__r_.first().__l.__is_long_ = true;
}
size_type __get_long_cap() const _NOEXCEPT {
return __r_.first().__l.__cap_ * __endian_factor;
}
inline ~basic_string() {
__annotate_delete();
if (__is_long())
__alloc_traits::deallocate(__alloc(), __get_long_pointer(), __get_long_cap());
}
```
1. __recommend() -> even size
2. `std::__allocate_at_least(__alloc(), __recommend(__sz) + 1)` - > not
even size
3. ` __set_long_cap() `- > lose one bit of size for __endian_factor == 2
(see `/ __endian_factor`)
4. `__alloc_traits::deallocate(__alloc(), __get_long_pointer(),
__get_long_cap())` -> uses even size (see `__get_long_cap`)
This should fix incorrect deallocation sizes for some instances of
std::string. Memory profiling or debugging tools like AddressSanitizer,
LeakSanitizer or TCMalloc could then complain about the the size passed
to a deallocation not matching the size originally passed to the
allocation.
Reported by: Aliaksei Kandratsenka <alkondratenko@gmail.com>
PR: 279560
MFC after: 3 days
[PPCMergeStringPool] Only replace constant once (#92996)
In #88846 I changed this code to use RAUW to perform the replacement
instead of manual updates -- but kept the outer loop, which means we try
to perform RAUW once per user. However, some of the users might be freed
by the RAUW operation, resulting in use-after-free.
The case where this happens is constant users where the replacement
might result in the destruction of the original constant.
Fixes https://github.com/llvm/llvm-project/issues/92991.
This fixes a possible crash when building crypto/openssh/sshkey.c for
PowerPC targets.
Reported by: cperciva
PR: 276104
MFC after: 3 days
[X86] Add slow div64 tuning flag to Nehalem target (#91129)
This appears to have been missed because later cpus don't inherit from Nehalem tuning much.
Noticed while cleaning up for #90985
Merge commit 8b400de79eff from llvm-project (by Simon Pilgrim):
[X86] Enable TuningSlowDivide64 on Barcelona/Bobcat/Bulldozer/Ryzen Families (#91277)
Despite most AMD cpus having a lower latency for i64 divisions that converge early, we are still better off testing for values representable as i32 and performing a i32 division if possible.
All AMD cpus appear to have been missed when we added the "idivq-to-divl" attribute - this patch now matches Intel cpu behaviour (and the x86-64/v2/3/4 levels).
Unfortunately the difference in code scheduling means I've had to stop using the update_llc_test_checks script and just use old-fashioned CHECK-DAG checks for divl/divq pairs.
Fixes#90985
This fixes possibly worse runtime performance on AMD Zen hardware, when
using -march=znver4 (or any other znver), as opposed to -march=x86-64-v4
or the baseline -march=x86-64. A similar fix is applied for Nehalem.
PR: 278908
MFC after: 3 days
[X86][Driver] Do not add `-evex512` for `-march=native` when the target doesn't support AVX512 (#91694)
This prevents problems with ports that fail to build with
CPUTYPE=native, if the native CPU supports AVX512F, resulting in errors
like:
/wrkdirs/usr/ports/archivers/libdeflate/work/libdeflate-1.20/lib/x86/adler32_template.h:197:21: error: always_inline function '_mm512_set1_epi8' requires target feature 'evex512', but would be inlined into function 'adler32_x86_avx512_vl512_vnni' that is compiled without support for 'evex512'
197 | const vec_t ones = VSET1_8(1);
| ^
/wrkdirs/usr/ports/archivers/libdeflate/work/libdeflate-1.20/lib/x86/adler32_template.h:116:23: note: expanded from macro 'VSET1_8'
116 | # define VSET1_8(a) _mm512_set1_epi8(a)
| ^
/wrkdirs/usr/ports/archivers/libdeflate/work/libdeflate-1.20/lib/x86/adler32_template.h:197:21: error: AVX vector return of type '__m512i' (vector of 8 'long long' values) without 'evex512' enabled changes the ABI
/wrkdirs/usr/ports/archivers/libdeflate/work/libdeflate-1.20/lib/x86/adler32_template.h:116:23: note: expanded from macro 'VSET1_8'
116 | # define VSET1_8(a) _mm512_set1_epi8(a)
| ^
Ports known to be affected are: archivers/libdeflate, devel/highway,
www/node20, and lang/rust.
(For rust itself there is also a similar issue reported at
https://github.com/rust-lang/rust/pull/121088).
PR: 276104
Reported by: netchild
MFC after: 3 days
[OpenMP] Fix child processes to use affinity_none (#91391)
When a child process is forked with OpenMP already initialized, the
child process resets its affinity mask and sets proc-bind-var to false
so that the entire original affinity mask is used. This patch corrects
an issue with the affinity initialization code setting affinity to
compact instead of none for this special case of forked children.
The test trying to catch this only testing explicit setting of
KMP_AFFINITY=none. Add test run for no KMP_AFFINITY setting.
Fixes: #91098
This should fix OpenMP processes sometimes getting stuck on a single CPU
core.
PR: 278845
Reported by: Cassidy B. Larson <cbl@cbl.us>
MFC after: 3 days
[OpenMP] Fix re-locking hang found in issue 86684 (#88539)
This was initially reported here (including stacktraces):
https://stackoverflow.com/questions/78183545/does-compiling-imagick-with-openmp-enabled-in-freebsd-13-2-cause-sched-yield
If `__kmp_register_library_startup()` detects that another instance of
the library is present, `__kmp_is_address_mapped()` is eventually
called. which uses `kmpc_alloc()` to allocate memory. This function
calls `__kmp_entry_thread()` to access the thread-local memory pool,
which is a bad idea during initialization. This macro internally calls
`__kmp_get_global_thread_id_reg()` which sets the bootstrap lock at the
beginning (before calling `__kmp_register_library_startup()`).
The fix is to use `KMP_INTERNAL_MALLOC()`/`KMP_INTERNAL_FREE()` instead
of `kmpc_malloc()`/`kmpc_free()`. `KMP_INTERNAL_MALLOC` and
`KMP_INTERNAL_FREE` do not use any bootstrap locks. They just translate
to `malloc()`/`free()` and are meant to be used during library
initialization before other library-specific allocators have been
initialized.
Fixes: #86684
This should fix OpenMP processes sometimes getting locked with 100% CPU
usage, endlessly calling sched_yield(2).
PR: 278845
Reported by: Cassidy B. Larson <cbl@cbl.us>
MFC after: 3 days
[sanitizer_symbolizer] Cast arguments for format strings in markup (#89815)
When compiling the common sanitizer libraries, there are many warnings
about format specifiers, similar to:
compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_markup.cpp:31:32: warning: format specifies type 'void *' but the argument has type 'uptr' (aka 'unsigned long') [-Wformat]
31 | buffer->AppendF(kFormatData, DI->start);
| ~~~~~~~~~~~ ^~~~~~~~~
compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_markup_constants.h:33:46: note: format string is defined here
33 | constexpr const char *kFormatData = "{{{data:%p}}}";
| ^~
| %lu
compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_markup.cpp:46:43: warning: format specifies type 'void *' but the argument has type 'uptr' (aka 'unsigned long') [-Wformat]
46 | buffer->AppendF(kFormatFrame, frame_no, address);
| ~~~~~~~~~~~~ ^~~~~~~
compiler-rt/lib/sanitizer_common/sanitizer_symbolizer_markup_constants.h:36:48: note: format string is defined here
36 | constexpr const char *kFormatFrame = "{{{bt:%u:%p}}}";
| ^~
| %lu
...
This is because `uptr` is dependent on the platform, and can be either
`unsigned long long`, `unsigned long`, or `unsigned int`.
To fix the warnings, cast the arguments to the expected type of the
format strings.
PR: 276104
Reported by: pstef
MFC after: 3 days
[SimplifyCFG] Fix crash when there is unreachable large index (#88616)
The large case index out of scope is dead code, but it is still be
created for TableContents in SwitchLookupTable::SwitchLookupTable,
so make sure the table size after growing should not get smaller.
Fix https://github.com/llvm/llvm-project/issues/88607
This should fix "Assertion failed: (idx < size()), function operator[]"
when building the science/dynare port.
PR: 276104, 278320
Reported by: yuri
MFC after: 1 month
After libsys was introduced, linking sanitized programs started failing
with:
# c++ -fsanitize=address main.cc
ld: error: undefined symbol: __elf_aux_vector
>>> referenced by sanitizer_linux_libcdep.cpp:950 (/usr/src/contrib/llvm-project/compiler-rt/lib/sanitizer_common/sanitizer_linux_libcdep.cpp:950)
>>> sanitizer_linux_libcdep.o:(__sanitizer::ReExec()) in archive /usr/lib/clang/17/lib/freebsd/libclang_rt.asan-x86_64.a
c++: error: linker command failed with exit code 1 (use -v to see invocation)
Mark __elf_aux_vector as weak in the internal sanitizer declaration, so
the linker will accept it at link time. The dynamic linker will then
take care of the symbol at run time.
Suggestion by: brooks
PR: 276104, 277393
MFC after: 1 month
[libc++] Simplify is_convertible
GCC 13 has added __is_convertible(), so we don't need to keep the fallback implementation around.
Reviewed By: #libc, Mordante
Spies: Mordante, libcxx-commits
Differential Revision: https://reviews.llvm.org/D157939
This should allow buildworld with gcc 12 to work again.
PR: 276104
MFC after: 1 month
[X86][AVX512BF16] Add a few missing insert/extract patterns
These are really the same as the f16 (and i16) instructions, but we need
them for any type that can occur.
Merge commit 2e4e04c59043 from llvm-project (by Phoebe Wang):
[X86][BF16] Do not lower to VCVTNEPS2BF16 without AVX512VL (#86395)
Fixes: #86305
These should fix "fatal error: error in backend: Cannot select: t71:
v32bf16 = insert_subvector t67, t64, Constant:i32<16>" when building the
misc/ncnn port.
PR: 278305
Reported by: yuri
MFC after: 1 month
[Clang][Sema] Fix a crash in lambda instantiation (#85565)
Fix https://github.com/llvm/llvm-project/issues/85343
When build lambda expression in lambda instantiation, `ThisType` is
required in `Sema::CheckCXXThisCapture` to build `this` capture. Set
`this` type by import `Sema::CXXThisScopeRAII` and it will be used later
in lambda expression transformation.
Co-authored-by: huqizhi <836744285@qq.com>
This fixes 'Assertion failed: (!isNull() && "Cannot retrieve a NULL type
pointer"), function getCommonPtr" when building the x11-wm/wayfire port.
PR: 276104
MFC after: 1 month
[libc++] Re-enable std::pair trivial copy constructor for FreeBSD >= 14
After many years of using the really old std::pair ABI which did not yet
have a trivial copy constructor, FreeBSD 14 and later will finally get
rid of it. Only use the old ABI for FreeBSD 13 and earlier.
Note: on the FreeBSD side, we will bump our libc++.so version for this,
and keep an old compatibility library in a separate package.
Differential Revision: https://reviews.llvm.org/D126462
This ABI change can cause crashes when binaries compiled against older
libc++ versions are run against binaries compiled against this libc++
version.
For example, lang/ldc uses a precompiled bootstrap ldc2 binary that was
compiled against the old libc++, but also links against libLLVM-15.so.
If libLLVM-15.so is compiled against the new libc++ version, the ABI
mismatch results in segfaults or even stack overflows.
Note: we can only re-enable the std::pair trivial copy constructors
again when the official libc++ ABI version is bumped to 2.
PR: 276104
MFC after: 1 month
As of 4d20cfcf4eb08217ed37c4d4c38dc395d7a66d26, `__bit_reference`
contains a template `__fill_n` with a bool `_FillValue` parameter.
Unfortunately there is a relatively widely used piece of scientific
software called NetCDF, which exposes a (C) macro `_FillValue` in its
public headers.
When building the NetCDF C++ bindings, this quickly leads to compilation
errors when the macro interferes with the template in `__bit_reference`.
Rename the parameter to `_FillVal` to avoid the conflict.
PR: 276104
MFC after: 1 month
[Clang][AST] Fix a crash on attaching doc comments (#78716)
This crash is basically caused by calling
`ASTContext::getRawCommentForDeclNoCacheImp` with its input arguments
`RepresentativeLocForDecl` and `CommentsInTheFile` refering to different
files. A reduced reproducer is provided in this patch.
After the source locations for instantiations of funtion template are
corrected in the commit 256a0b298c68b89688b80350b034daf2f7785b67, the
variable `CommitsInThisFile` in the function
`ASTContext::attachCommentsToJustParsedDecls` would refer to the source
file rather than the header file for implicit function template
instantiation. Therefore, in the first loop in
`ASTContext::attachCommentsToJustParsedDecls`, `D` should also be
adjusted for relevant scenarios like the second loop.
Fixes#67979Fixes#68524Fixes#70550
This should fix a segfault when compiling graphics/gdal.
PR: 276104
MFC after: 1 month
Revert "[SemaCXX] Implement CWG2137 (list-initialization from objects of the same type) (#77768)"
This reverts commit 924701311aa79180e86ad8ce43d253f27d25ec7d. Causes compilation
errors on valid code, see
https://github.com/llvm/llvm-project/pull/77768#issuecomment-1908062472.
In particular, this fixes bogus "call to constructor of 'SomeType' is
ambiguous" errors.
PR: 276104
MFC after: 1 month
This updates llvm, clang, compiler-rt, libc++, libunwind, lld, lldb and
openmp to llvm-project main llvmorg-18-init-18359-g93248729cfae, the
last commit before the upstream release/18.x branch was created.
PR: 276104
MFC after: 1 month
* Remove osreldate include because _LIBCPP_HAS_NO_GETS has disappeared
* Instead, add direct major __FreeBSD__ check for using ::gets declaration
* Mark EINTEGRITY values as FreeBSD customization
* Reformat _LIBCPP_TYPE_VISIBILITY_DEFAULT customization
PR: 276104
MFC after: 1 month
This is intended to better support ports usage of older clang versions:
* Add _LIBCPP_ENABLE_COMPILER_VERSION_CHECKS block around compiler
version checks, to avoid any warnings about support. This makes some
ports that use -Werror fall over.
* When using clang < 15.0, avoid using a type visibility attribute on
the std namespace, as older versions of clang do not support this.
PR: 276104
MFC after: 1 month
[libcxx] Re-include <osreldate.h> in __config for FreeBSD
In 0a97720d0197 some changes were made to `__config` for assuming that
`__BYTE_ORDER__` is always present.
However, this deleted a `<osreldate.h>` include for FreeBSD, which is
required to get the value of `__FreeBSD_version`, and that is used later
in the file to determine whether `_LIBCPP_C_HAS_NO_GETS` needs to be
enabled.
Include `<osreldate.h>` just after the other includes used for feature
detection, to fix this.
Note that when FreeBSD 13 is EOLed, this can be removed, as then all
supported FreeBSD versions will no longer have `gets()`.
PR: 276104
MFC after: 1 month
Reapply "RegisterCoalescer: Add implicit-def of super register when coalescing SUBREG_TO_REG"
This reverts commit c398fa009a47eb24f88383d5e911e59e70f8db86.
PPC backend was fixed in 2f82662ce901c6666fceb9c6c5e0de216a1c9667
Since it causes an assertion failure building /sys/dev/fb/vga.c:
https://github.com/llvm/llvm-project/issues/76416
PR: 276104
MFC after: 1 month
[DSE] Remove malloc from EarliestEscapeInfo before removing. (#84157)
Not removing the malloc from earliest escape info leaves stale entries
in the cache.
Fixes https://github.com/llvm/llvm-project/issues/84051.
PR: https://github.com/llvm/llvm-project/pull/84157
This fixes a crash in clang (usually a bus error, but can also be
another memory error) when compiling the science/siconos port.
PR: 278174
Reported by: yuri
MFC after: 3 days
[PEI] Don't zero out noreg operands
A tail call may have $noreg operands.
Fixes a crash.
Reviewed By: xgupta
Differential Revision: https://reviews.llvm.org/D156485
This should fix an assertion failure building qemu, specifically those
parts using -fzero-call-used-regs.
Reported by: Daniel Berrangé <dan-freebsd@berrange.com>
PR: 277474
MFC after: 3 days
[sanitizer][msan] fix AArch64 vararg support for KMSAN (#70660)
Cast StackSaveAreaPtr, GrRegSaveAreaPtr, VrRegSaveAreaPtr to pointers to
fix assertions in getShadowOriginPtrKernel().
Fixes: https://github.com/llvm/llvm-project/issues/69738
Patch by Mark Johnston.
Requested by: markj
MFC after: 3 days
[libc++] Fix filesystem::remove_all() on FreeBSD (#79540)
remove_all_impl() opens the target path with O_NOFOLLOW, which fails if
the target is a symbolic link. On FreeBSD, rather than returning ELOOP,
openat() returns EMLINK. This is unlikely to change for compatibility
reasons, see https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=214633 .
Thus, check for EMLINK as well.
Reported by: markj
PR: 276632
MFC after: 3 days
[compiler-rt] remove hexdump interception. (#79378)
a freebsd dev member reported a symbol conflict and intercepting this
had little value anyway.
This is one part of fixing the WITH_ASAN build. Some executables in the
base system define their own hexdump() symbol, which would otherwise
conflict with the ASan-intercepted one.
Reported by: markj
PR: 276597
MFC after: 3 days
Signal blocking originally showed up in 51c2afc4b65b2782 ("Support:
Don't call close again if we get EINTR"), but it was overzealous --
there are systems where the error is known to be fine.
This commit elides signal blocking for said systems (the list is
incomplete though).
Note close() can still fail for other reasons (like ENOSPC), in which
case an error will be returned while the fd slot is cleared up.
Reviewed by: dim
Differential Revision: https://reviews.freebsd.org/D42984
In commit 88640c0e8b the new EINTEGRITY errno value was added, and
this caused us to carry a patch for upstream libc++ since that time.
Because it can cause merge conflicts when importing libc++ code from
upstream, I have submitted an upstream pull request to get most of that
patch integrated.
It turns out that we do not need the errno.h part of it at all, since
all supported FreeBSD versions define EOWNERDEAD and ENOTRECOVERABLE,
and therefore the block that juggles with ELAST values is never used in
FreeBSD. At the moment it only applies to older versions of Linux, or
possibly other platforms.
Therefore the only part that needs to stay is the definition of a enum
errc value for EINTEGRITY, and this is made optional upon EINTEGRITY
being defined, to make it suitable for upstreaming.
No functional change is intended.
MFC after: 1 week
[Clang] Do not change the type of captured vars when checking lambda constraints
When checking the constraint of a lambda, we need to respect the constness
of the call operator when establishing the type of capture variables.
In D124351, this was done by adding const to the captured variable...
However, that would change the type of the variable outside of the scope
of the lambda, which is clearly not the desired outcome.
Instead, to ensure const-correctness, we need to populate
a LambdaScopeInfo with the capture variables before checking the
constraints of a generic lambda.
There is no changelog as I'd like to tentatively propose we backport
this change to RC3 as it is a regression introduced in the Clang 17
cycle.
Fixes#61267
Reviewed By: aaron.ballman, #clang-language-wg
Differential Revision: https://reviews.llvm.org/D158433
Merge commit 3ed9e9e3ace6 from llvm git (by Corentin Jabot):
[Clang] Add captures to the instantiation scope of lambda call operators
Like concepts checking, a trailing return type of a lambda
in a dependent context may refer to captures in which case
they may need to be rebuilt, so the map of local decl
should include captures.
This patch reveal a pre-existing issue.
`this` is always recomputed by TreeTransform.
`*this` (like all captures) only become `const`
after the parameter list.
However, if try to recompute the value of `this` (in a parameter)
during template instantiation while determining the type of the call operator,
we will determine it to be const (unless the lambda is mutable).
There is no good way to know at that point that we are in a parameter
or not, the easiest/best solution is to transform the type of this.
Note that doing so break a handful of HLSL tests.
So this is a prototype at this point.
Fixes#65067Fixes#63675
Reviewed By: erichkeane
Differential Revision: https://reviews.llvm.org/D159126
This fixes 'Assertion failed: (isa<LabelDecl>(D) && "declaration not
instantiated in this scope"), function findInstantiationOf' error when
building databases/mongodb44.
PR: 273753
MFC after: 1 month
