[NPM] Update OptimizedRegAlloc and MachineLateOptimization pipelines (#172795)
1. add the StackSlotColoringPass to default pipeline
2. Introduce MachineLateInstrsCleanupPass at the beginning of
addMachineLateOptimization (matches the legacy default pipeline)
unifdef m_copypack() use
These ifdefs date back to 1990 in CSRG (SCCS rev 7.20).
m_copypack() never existed in CSRG releases as far as I can tell.
ok deraadt@ mvs@
[ProfCheck] Exclude test from e4722c6
This adds in a select that we should probably just mark with unknown
profdata. Exclude for now to get the bot back to green.
[LLVMABI] Implement the ABI Typesystem (#158329)
This PR implements the first part of the LLVM ABI lowering library,
proposed in [this
RFC](https://discourse.llvm.org/t/rfc-an-abi-lowering-library-for-llvm/84495).
It is split out of https://github.com/llvm/llvm-project/pull/140112,
which demonstrates how this is going to be used.
The ABI type system is intended to represent all the type information
that is necessary to make call lowering decisions. As such, it contains
less information than Clang QualTypes, but more information than LLVM IR
types. The current type system has enough information to implement the
x86_64 SysV ABI, but some extensions will likely be needed in the future
for other targets (e.g. unadjusted alignment).
The type system expects layout information (like size, offset and
alignment) to already be computed by the frontend.
The types are constructed using TypeBuilder, which uses a
BumpPtrAllocator. The types themselves are not uniqued -- instead we
cache the QualType -> ABI type translation (in future patches).
rasops_allocattr_mono: fix regression from WSSCREEN_256COL
0xff was never a valid colormap index, but worked by accident
since the previous ATTR_FG implementation clamped the value.
Now it results in black text on black background.
Use named WSCOL_* constants instead.
boost-libs: make boost type_traits build with clang 21
Recent versions of clang made -Wenum-constexpr-conversion errors into a
hard error, as was announced several versions ago.
Boost type_traits has two instances where it attempts to convert
out-of-range enum values, leading to errors similar to:
In file included from ../src/lib/dhcpsrv/csv_lease_file6.cc:9:
In file included from ../src/lib/dhcpsrv/dhcpsrv_log.h:11:
In file included from ../src/lib/log/macros.h:10:
In file included from ../src/lib/log/logger.h:19:
In file included from ../src/lib/log/log_formatter.h:19:
In file included from /usr/local/include/boost/lexical_cast.hpp:33:
In file included from /usr/local/include/boost/lexical_cast/try_lexical_convert.hpp:31:
In file included from /usr/local/include/boost/lexical_cast/detail/converter_numeric.hpp:31:
In file included from /usr/local/include/boost/type_traits/make_unsigned.hpp:14:
/usr/local/include/boost/type_traits/is_signed.hpp:37:25: error: in-class initializer for static data member is not a constant expression
37 | static const no_cv_t minus_one = (static_cast<no_cv_t>(-1));
[58 lines not shown]
boost-libs: make boost type_traits build with clang 21
Recent versions of clang made -Wenum-constexpr-conversion errors into a
hard error, as was announced several versions ago.
Boost type_traits has two instances where it attempts to convert
out-of-range enum values, leading to errors similar to:
In file included from ../src/lib/dhcpsrv/csv_lease_file6.cc:9:
In file included from ../src/lib/dhcpsrv/dhcpsrv_log.h:11:
In file included from ../src/lib/log/macros.h:10:
In file included from ../src/lib/log/logger.h:19:
In file included from ../src/lib/log/log_formatter.h:19:
In file included from /usr/local/include/boost/lexical_cast.hpp:33:
In file included from /usr/local/include/boost/lexical_cast/try_lexical_convert.hpp:31:
In file included from /usr/local/include/boost/lexical_cast/detail/converter_numeric.hpp:31:
In file included from /usr/local/include/boost/type_traits/make_unsigned.hpp:14:
/usr/local/include/boost/type_traits/is_signed.hpp:37:25: error: in-class initializer for static data member is not a constant expression
37 | static const no_cv_t minus_one = (static_cast<no_cv_t>(-1));
[56 lines not shown]
sysutils/mtail: New Port
mtail is a tool for extracting metrics from application logs to be
exported into a timeseries database or timeseries calculator for
alerting and dashboarding.
It fills a monitoring niche by being the glue between applications that
do not export their own internal state (other than via logs) and
existing monitoring systems, such that system operators do not need to
patch those applications to instrument them or writing custom extraction
code for every such application.
curlwp_bind(9): tweak example's markup
`-offset indent` indents less than a literal tab. While here,
untabify the example, groff's PS output is slightly misaligned
otherwise (within the literal display itself).
wifi: mt76: Remove blank line after mt792x firmware version dmesg
An extra blank line gets printed after printing firmware version
because the build date is null terminated. Remove the "\n" from
dev_info() calls to print firmware version and build date to fix
the problem.
Reported-by: Mario Limonciello <superm1 at gmail.com>
Signed-off-by: Shuah Khan <skhan at linuxfoundation.org>
Signed-off-by: Linus Torvalds <torvalds at linux-foundation.org>
ValueTracking: Improve handling of fadd in computeKnownFPClass.
This already recognized that if both inputs are positive, the
result is positive. Extend this to the mirror situation with
negative inputs.
Also special case fadd x, x. Canonically, fmul x, 2 is fadd x, x.
We can tell the sign bit won't change, and 0 will propagate.
ValueTracking: Add more baseline tests for computeKnownPPClass of fadd
Test cases with fadd x, x. Also test cases where both inputs are known
negative.
urndis(4): Attach at usbifif, not usbdevif, in the if_urndis module.
We really ought to have a static type system for config(5) interface
attributes to catch mistakes like this!
Came up while trying to test a fix for:
PR kern/59872: urndis(4): missing support for some devices
urndis(4): Match more interface ids.
There are some others we should consider too, based on what OpenBSD,
FreeBSD, and Linux match, but I haven't tested with these devices:
class subclass protocol
1. 0x02 (CDC) 0x02 (abstract control model) 0xff (? rndis?)
2. 0xef (misc) 0x01 (sync) 0x01 (active)
3. 0xef (misc) 0x04 (rndis) 0x03 (wimax)
4. 0xef (misc) 0x04 (rndis) 0x04 (wwan)
Note: FreeBSD uses `UIPROTO_RNDIS' for (3) even though the USB-IF
registry lists class 0xef, subclass 0x04, protocol 0x04 as `RNDIS
over WiMAX'; likewise `UIPROTO_ACTIVESYNC' for (4) even though it's
listed as `RNDIS over WWAN'. My guess is that for class 0xef
subclass 0x04, _any_ protocol will really be RNDIS, and it was a
mistake for FreeBSD to use those protocol numbers (which context
suggests were supposed to apply to different subclasses).
PR kern/59872: urndis(4): missing support for some devices
