[lld-macho] Make category merging symbol names match ld64 (#90864)
When generating symbols for various category constructs, make sure the
symbol names match the format of those generated by ld64 when it does
category merging.
[lld-macho][NFC] Simplify category merging code (#90856)
We modify category merging code to simplify it, as follows:
- We can simplify InfoWriteSection to not be templated - this is not
really necessary.
- We remove PointerListInfo::categoryOffset as it is not used.
[lldb] [debugserver] address preprocessor warning, extra arg (#90808)
In DNBArchImplARM64.cpp I'm doing
```
#if __has_feature(ptrauth_calls) && defined(__LP64__)
```
And the preprocessor warns that this is not defined behavior. This
checks if ptrauth_calls is available and if this is being compiled
64-bit (i.e. arm64e), and defines a single DEBUGSERVER_IS_ARM64E when
those are both true.
I did have to duplicate one DNBLogThreaded() call which itself is a
macro, and using an ifdef in the middle of macro arguments also got me a
warning from the preprocessor.
While testing this for all the different targets, I found a DNBError
initialization that accepts a c-string but I'm passing in a printf-style
formatter c-string and an argument. Create the string before the call
and pass in the constructed string.
rdar://127129242
[clang][PGO] Apply artificial DebugLoc to llvm.instrprof.increment instructions (#90717)
Prior to this change the debug-location for the
`llvm.instrprof.increment` intrinsic was set to whatever the current
DIBuilder's current debug location was set to. This meant that for
switch-statements, a counter's location was set to the previous case's
debug-location, causing confusing stepping behaviour in debuggers. This
patch makes sure we attach a dummy debug-location for the increment
instructions.
rdar://123050737
[HLSL] Cleanup TargetInfo handling (#90694)
We had some odd places where we set target behaviors. We were setting
the long size in target-specific code, but it should be language-based.
We were not setting the Half float type semantics correctly, and instead
were overriding the query in the AST context.
This change it moves existing code to the right places in the Target so
that as we continue working on target and language feature they are
controlled in the right places.
It also fixes a bug where the size of `half` was computed incorrectly
when native half types are not supported.
Bump actions runner image used for libc++'s builders.
The builders are not producing warnings about the runner version being
out of date. This is an attempt to fix that.
[flang][cuda] Lower device/managed/unified allocation to cuda ops (#90623)
Lower locals allocation of cuda device, managed and unified variables to
fir.cuda_alloc. Add fir.cuda_free in the function context finalization.
@vzakhari For some reason the PR #90526 has been closed when I merged PR
#90525. Just reopening one.
[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;
}
[17 lines not shown]
[llvm][GraphWriter] Resize std::string, instead of reassigning to substr (NFC)
* Don't call substr which creates a new string instance
* Only call string method if string length is larger than 140
Closes #90324
[clang][CodeGen] Fix in codegen for __builtin_popcountg/ctzg/clzg (#90845)
Make sure that the result from the popcnt/ctlz/cttz intrinsics is
unsigned casted to int, rather than casted as a signed value, when
expanding the __builtin_popcountg/__builtin_ctzg/__builtin_clzg
builtins.
An example would be
unsigned _BitInt(1) x = ...;
int y = __builtin_popcountg(x);
which previously was incorrectly expanded to
%1 = call i1 @llvm.ctpop.i1(i1 %0)
%cast = sext i1 %1 to i32
Since the input type is generic for those "g" versions of the builtins
the intrinsic call may return a value for which the sign bit is set
(that could typically for BitInt of size 1 and 2). So we need to emit a
zext rather than a sext to avoid negative results.
