GCC expands the pointer type in this conditional expression even for
template types _Up that are not arrays. This raises an error when
std::decay<> is used with reference types (as is done in LLVM's
sources). Using add_pointer<> causes GCC to only instantiate a
pointer type for array types.
A similar change to this commit (albeit reworked due to upstream
changes) has been merged to libc++ in commit
26068c6e60324ed866a1ca2afb5cb5eb0aaf015b.
In file included from /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/__compare/ordering.h:13,
from /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/__compare/common_comparison_category.h:12,
from /usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/tuple:168,
from /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMapInfo.h:20,
from /usr/src/contrib/llvm-project/llvm/include/llvm/ADT/DenseMap.h:17,
from /usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/GVNHoist.cpp:36:
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/type_traits: In instantiation of 'struct std::__1::__decay<llvm::CHIArg&, true>':
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/type_traits:1591:89: required from 'struct std::__1::decay<llvm::CHIArg&&>'
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/__utility/pair.h:132:16: required by substitution of 'template<class _Tuple, typename std::__1::enable_if<typename std::__1::conditional<(std::__1::__tuple_like_with_size<_Tuple, 2, typename std::__1::__uncvref<_Tp>::type>::value && (! std::__1::is_same<typename std::__1::decay<_Tp>::type, std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> > >::value)), std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> >::_CheckTupleLikeConstructor, std::__1::__check_tuple_constructor_fail>::type::__enable_implicit<_Tuple>(), void>::type* <anonymous> > constexpr std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> >::pair(_Tuple&&) [with _Tuple = llvm::CHIArg&&; typename std::__1::enable_if<typename std::__1::conditional<(std::__1::__tuple_like_with_size<_Tuple, 2, typename std::__1::__uncvref<_Tp>::type>::value && (! std::__1::is_same<typename std::__1::decay<_Tp>::type, std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> > >::value)), std::__1::pair<llvm::BasicBlock*, llvm::SmallVector<llvm::CHIArg, 2> >::_CheckTupleLikeConstructor, std::__1::__check_tuple_constructor_fail>::type::__enable_implicit<_Tuple>(), void>::type* <anonymous> = <missing>]'
/usr/src/contrib/llvm-project/llvm/lib/Transforms/Scalar/GVNHoist.cpp:892:51: required from here
/usr/obj/usr/src/amd64.amd64/tmp/usr/include/c++/v1/type_traits:1582:30: error: forming pointer to reference type 'std::__1::remove_extent<llvm::CHIArg&>::type' {aka 'llvm::CHIArg&'}
1582 | >::type type;
| ^~~~
Reviewed by: dim
Differential Revision: https://reviews.freebsd.org/D36898
This appears to be a leftover from the time we used a less-capable VCS.
Reviewed by: delphij
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D37368
Intel Control-flow Enforcement Technology (CET) provides new
instructions `endbr32/64` for the indirect branch control.
They are NOPs on i686 and new targets. We need to check for that
in case it crashes on older targets.
PR: 264497
Reviewed by: dim
MFC after: 1 week
Obtained from: LLVM commit 52516782972730ff065a34123a9d8876da08c254
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37268
Summary:
The current OFED code allows binding server to IPv6 address. It was added back in 91fc39561d
Sponsored by: Intel Corporation
MFC after: 3 days
Reviewers: hselasky
Subscribers: imp
Differential Revision: https://reviews.freebsd.org/D37196
Apply patch extracted from sendmail-8-17.1.9 snapshot by dinoex@.
PR: 262935
Reviewed by: gshapiro
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D37119
buf is a char ** and *buf is the allocated buffer.
PR: 267050
Reported by: Robert Morris <rtm@lcs.mit.edu>
MFC after: 3 days
Sponsored by: The FreeBSD Foundation
The noted argument is wrong - if it's already been deleted then the id we
have for it is invalid.
Because we don't track deletions to the ruleset, working it out is
problematic at best.
Instead, if we have already added the rule treat it as a non-op.
This is a valid use case because we might receive a burst of messages
in the downstream application for the same address and process them
one by one. It's not the job of the downstream application to track
blacklistd state.
Obtained from: 959b18a604
If input mail does not have a newline on the last line dma must add
one. This was broken by the addition of long-line splitting, with the
switch from strlen(line) to linelen returned by getline().
PR: 266629
Reviewed by: bapt, Mikko Lehto
Tested by: Mikko Lehto
MFC after: 1 week
Fixes: b0b2d05fd0 ("Split body of mails not respecting...")
Sponsored by: The FreeBSD Foundation
Differential Revision: https://reviews.freebsd.org/D36763
Mostly remove from the SEE ALSO section, adding a mention of the port
where not removed. Elsewhere, remove as appropriate and change from .Xr
to .Nm where a mention of telnetd continues to make sense (or removing
it would require significant reworking of the surrounding text).
Reviewed by: imp, delphij, emaste
Differential Revision: https://reviews.freebsd.org/D36785
Merge commit 307ace7f20d5 from llvm git (by David Sherwood):
[LoopVectorize] Ensure the VPReductionRecipe is placed after all it's inputs
When vectorising ordered reductions we call a function
LoopVectorizationPlanner::adjustRecipesForReductions to replace the
existing VPWidenRecipe for the fadd instruction with a new
VPReductionRecipe. We attempt to insert the new recipe in the same
place, but this is wrong because createBlockInMask may have
generated new recipes that VPReductionRecipe now depends upon. I
have changed the insertion code to append the recipe to the
VPBasicBlock instead.
Added a new RUN with tail-folding enabled to the existing test:
Transforms/LoopVectorize/AArch64/scalable-strict-fadd.ll
Differential Revision: https://reviews.llvm.org/D129550
Reported by: yuri
PR: 264834
MFC after: 3 days
Improvements and changes to integrate bsddialog(1) with scripts in BASE.
Overview:
* New options. --and-widget, --keep-tite, --calendar.
* Change output format. Menus and --print-maxsize.
* Redefine sizing. Fixed rows, cols and menurows became at the most.
* Add DIAGNOSTICS. Error messages for bad arguments and options.
* Add keys. Space for --menu, fast keys for --msgbox and --yesno.
* Text. Change default text modification, add --cr-wrap.
See /usr/src/contrib/bsddialog/CHANGELOG '2022-09-24 Version 0.4'
for more detailed information.
Merge commit '9f24fda5a8e7ab8243e71473c7e2dc98b4877e64'
The telnetd codebase is old, unmaintained, and has a number of quality
issues. Users wishing to provide telnetd service should find a
maintained implementation. The telnet client is NOT deprecated as it
is lower risk.
Reviewed by: pauamma, kevans, kp, melifaro
MFC After: 3 days
Differential Revision: https://reviews.freebsd.org/D36619
instead ifdef-ing out the return statement.
Reported by: Mark Millard <marklmi@yahoo.com>
Fixes: 87384c51e0
Sponsored by: The FreeBSD Foundation
MFC after: 2 weeks
The localtime(3) function returns a NULL pointer, if the passed in-time
translates to a year that will not fit in an integer type. It is stricly
recommended to check the return value to avoid garage output.
Reported by: mckusick
Reviewed by: mckusick, imp, rpokala
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D36515
The main changes this brings in are:
- Improves the performance of memcmp
- Adds SVE implementation of memcpy
- Uses the MTE version of some str* functions as they are faster
Sponsored by: The FreeBSD Foundation