ping: fix listing test cases when scapy is not installed
The ATF-python test program was attempting to list test cases that
require scapy. But it attempted to import the scapy module before the
test cases had been listed, resulting in an ImportError that kyua
interpreted as a test program crash.
Fix this behavior by handling that ImportError well enough to list test
cases, but not run them. If scapy isn't present, Kyua will refuse to
run the test cases. But it needs to be able to list them in order to
know to skip them.
Sponsored by: ConnectWise
MFC after: 2 weeks
Reviewed by: maxim
Differential Revision: https://reviews.freebsd.org/D56765
[NFCI][IR] Add DataLayout pointer to zero and null value related APIs
When the semantics of `ConstantPointerNull` change to represent a semantic null
pointer in the future, a null value won't necessarily be a zero value anymore.
Because of that, the entire LLVM constant infrastructure will need to change. As
a first step, this PR adds an optional data layout pointer to `isNullValue`,
`isZeroValue`, `getNullValue`, and `getZeroValue`. It isn't used yet, since a
null value is still a zero value right now.
lib/msun: Replaced pattern to force exception in _num families
Replaced the old pattern of using a ternary to force addition
(raising exceptions for sNaN's) with a new one using a volatile
variable. The _mag_num family was already implemented with this pattern
PR: 294719
Reviewed by: fuz, kargl
MFC after: 1 month
gcc-15 failed to build on arm(v7) because it didn't know what a bool was in
an MD specific file. Add the header, so gcc-15 builds again.
Does not affect any other architecture.
OK pascal@
OK for -release naddy@ sthen@
Improve CPU identification and hwcap for riscv64.
On riscv64 we currently only expose a fixed hwcap value (G + C) and do not
actually report any of what the CPUs provide via extensions. This means
that userland cannot detect and make use of additional instructions that
exist.
Rework cpu_identify() so that we build hwcap/hwcap2, then use this to select
the correct functions/support to use if we're on the primary CPU (rather
than doing this for every CPU). Check that the secondary CPUs have the same
features as the primary CPU (although this is coming from the DTB and not
the actual hardware).
Finally report available extensions via hwcap/hwcap2 so that we can
make use of these instructions in userland.
ok kettenis@ jca@
[ValueTracking] Add CharWidth argument to getConstantStringInfo (NFC)
The method assumes that host chars and target chars have the same width.
Add a CharWidth argument so that it can bail out if the requested char
width differs from the host char width.
Alternatively, the check could be done at call sites, but this is more
error-prone.
In the future, this method will be replaced with a different one that
allows host/target chars to have different widths. The prototype will
be the same except that StringRef is replaced with something that is
byte width agnostic. Adding CharWidth argument now reduces the future
diff.
[IR] Account for byte width in m_PtrAdd
The method has few uses yet, so just pass DL argument to it. The change
follows m_PtrToIntSameSize, and I don't see a better way of delivering
the byte width to the method.
[IRBuilder] Add getByteTy and use it in CreatePtrAdd
The change requires DataLayout instance to be available, which, in turn,
requires insertion point to be set. In-tree tests detected only one case
when the function was called without setting an insertion point, it was
changed to create a constant expression directly.
[SimplifyLibCalls] Add initial support for non-8-bit bytes
The patch makes CharWidth argument of `getStringLength` mandatory
and ensures the correct values are passed in most cases.
This is *not* a complete support for unusual byte widths in
SimplifyLibCalls since `getConstantStringInfo` returns false for those.
The code guarded by `getConstantStringInfo` returning true is unchanged
because the changes are currently not testable.
[ValueTracking] Make isBytewiseValue byte width agnostic
This is a simple change to show how easy it can be to support unusual
byte widths in the middle end.
[IR] Make @llvm.memset prototype byte width dependent
This patch changes the type of the value argument of @llvm.memset and
similar intrinsics from i8 to iN, where N is the byte width specified
in data layout string.
Note that the argument still has fixed type (not overloaded), but type
checker will complain if the type does not match the byte width.
Ideally, the type of the argument would be dependent on the address
space of the pointer argument. It is easy to do this (and I did it
downstream as a PoC), but since data layout string doesn't currently
allow different byte widths for different address spaces, I refrained
from doing it now.
[DataLayout] Add byte specification
This patch adds byte specification to data layout string.
The specification is `b:<size>`, where `<size>` is the size of a byte
in bits (later referred to as "byte width").
Limitations:
* The only values allowed for byte width are 8, 16, and 32.
16-bit bytes are popular, and my downstream target has 32-bit bytes.
These are the widths I'm going to add tests for in follow-up patches,
so this restriction only exists because other widths are untested.
* It is assumed that bytes are the same in all address spaces.
Supporting different byte widths in different address spaces would
require adding an address space argument to all DataLayout methods
that query ABI / preferred alignments because they return *byte*
alignments, and those will be different for different address spaces.
This is too much effort, but it can be done in the future if the need
arises, the specification reserves address space number before ':'.
Prevent memory leaks from json_getstr.
json_getstr returns the result of strdup (or NULL) to the caller so
the caller has to free the memory.
While here, setting order->finalize to NULL once is enough.
From Jan Schreiber (jes AT posteo.de), with input from tb.
OK tb (some time ago)
