[libc++][test][NFC] Remove implementation-detail noise from _BitInt test comments (#206666)
Several `_BitInt` test comments named the builtin the code lowers to,
restated macro equivalences, or pointed at another test file's
internals. They read as machine-generated and do not help a reader. This
rewords them across the `_BitInt` tests touched by #203876, where the
pattern was flagged in review.
Assisted-by: Claude (Anthropic)
Co-authored-by: Claude Opus 4.6 <noreply at anthropic.com>
citrus/HZ: Be more careful about encoding buffer.
1. Use unsigned char for chlen, since it's never negative and only
needs to be big enough for the ch array.
2. Expand the ch array by space for two escape sequences, each of
which is two characters.
I don't think it is currently possible with the i18n data we ship
for it to emit two escape sequences in a row -- there is a code
path to do this, but I don't think it can be reached without
setting escape sequences for variable 1 and extending this in some
way. Nevertheless, let's err on the side of safety.
3. Sprinkle assertions everywhere.
PR 59019: various iconv issues
iconv(3): Fix printing bytes on test failure.
Don't sign-extend to a 32-bit quantity causing the left to be padded
with f's; just print the 8-bit quantity.
PR 59019: various iconv issues
[lldb] Create a BSS section for WebAssembly object files (#206840)
Zero-initialized globals (BSS) live in a module's linear memory above
the initialized data segments, but wasm-ld emits no data segment for
them, so ObjectFileWasm created no section covering their addresses.
Reading those global without a running process fails with "unable to
resolve the module for file address", because the address resolved to no
section. Live reads did work because they go through process memory.
Synthesize a zero-fill section spanning from the end of the initialized
data to the linear memory's minimum size, and map it into linear memory
like the data segments. Live reads keep going through process memory
while zero-fill reads return zero.
Downgrade a very recently added math/cadical to 2.1.3.
Version 3.0.0 isn't supported by cvc5:
https://github.com/cvc5/cvc5/issues/12611
Make other changes to help cvc5 find cadical in /usr/pkg:
- add tracer.hpp
- move headers to include/cadical
[lldb][Windows] Fix "Invalid register name" for eax on x86_64 attach (#203498)
On Windows, when attaching to a process with no pre-existing target,
lldb reports "Invalid register name" for sub-registers like eax.
This is due to a bug in `ABIX86::AugmentRegisterInfo`, which determines
the GPR base size by reading
`Target::GetArchitecture().GetAddressByteSize()`. During attach, the
target's architecture has not yet been set when `AugmentRegisterInfo`
runs, so the lookup returns 0, the process is treated as 32-bit, and the
x86_64 sub-registers are never added.
This patch removes the dependency on the target's architecture: the X86
ABI plugins already know their own bitness, so `ABIX86_64` and
`ABIX86_i386` now report it directly via a new `Is64Bit()` virtual.
This patch fixes
`TestRegisters::test_convenience_registers_with_process_attach` and
`TestRegisters::test_convenience_registers_16bit_with_process_attach` on
[2 lines not shown]
[flang][openacc] Fix DEFAULT(NONE) errors for array sections (#204248)
ResolveAccObject skipped DSA registration when
GetDesignatorNameIfDataRef returned nullptr (i.e. for subscripted
designators like copyin(a(1:n))). The DEFAULT(NONE) post-visitor then
found the base variable unregistered and emitted a false error even
though it was explicitly listed in a data clause.
Unify the path using GetFirstName, which extracts the base symbol from
both bare data references and array sections. Continue not registering component references. This will need to be followed up with more accurate designator checking in the near future.
