Remove obsolete BUGS section from zgrep(1) man page, add test
I forgot to check/update the man page with D54217. While here add
a test for multiple -e flags.
Reviewed by: markj
Approved by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54632
(cherry picked from commit da5d94d29a5ec29817476c39ae2b2ad1666c3f06)
Remove obsolete BUGS section from zgrep(1) man page, add test
I forgot to check/update the man page with D54217. While here add
a test for multiple -e flags.
Reviewed by: markj
Approved by: markj
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D54632
(cherry picked from commit da5d94d29a5ec29817476c39ae2b2ad1666c3f06)
[flang][debug] Generate DWARF debug info using fir.use_stmt. (#168541)
This patch uses the fir.use_stmt operations to generate correct debug
metadata for use statement when `only` and `=>` are used. The debug flow
is changed a bit where we process the module globals first so that we
have the global variables when we start to process `fir.use_stmt`.
Fixes #160923.
[Clang][CIR] Implement CIRGen logic for __builtin_bit_cast
NOTE: This patch merely upstreams code from
* https://github.com/llvm/clangir.
This Op was originally implemented by Sirui Mu in #762 Further
modification were made by other ClangIR contributors.
co-authored-by: Sirui Mu <msrlancern at gmail.com>
AArch64: Use LibcallLoweringInfo in MachineSMEABI pass
In context this could probably just hardcode the libcall impls,
though that would be inconvenient for the arm64ec case (which I don't
see evidence of being a tested / supported combination).
interfaces: generalise the dhcp6c_script using the new IFNAME variable #7647
The file was conceptually created in d36f0f4f62557 and before was a single
command line script... so add appropriate copyrights from that time onward.
Many thanks to Martin for pinoeering this back in the day!
interfaces: show the prefix shift in the log message
Move the other force message to the respective if which is more or
less what we had before. This is important for making clear what
the impact of #9521 to renewals actually is.
interfaces: missed script path via @cm-rudolph
interfaces: multi-dhcp6c support and custom PD association #7647
This splits off rtsold and dhcp6c into separate processes
which frees us from the restrictions of faked iterative IDs
for PD associations. For NA we simply default to 0 now.
I'm not entirely sure why we settled for a single deamon of
dhcp6c back in the day, but there are certianly downsides to
it and I don't see something that wasn't fixed in the meantime
that makes this not work.
Add two debugging files which still need to be steered via the
debug setting.
[clang-tidy] Warn on use of std::get_temporary_buffer (#176191)
The STL function `std::get_temporary_buffer` was originally designed
with the intent of providing a more efficient implementation than the
general-purpose operator new, but no such implementation was created and
the API was deprecated (in C++17) and removed (in C++20).
As this function is difficult to use and provides no advantages, I think
(or at least hope) that nobody actually uses it; but given that it was
present in the official standard, I think tidy should be able to report
its bugprone nature. (It returns uninitialized memory, which can cause
subtle bugs, e.g. as in the last code example of the SEI CERT rule
EXP54-CPP.)
FreeBSD: Remove references to DEBUG_VFS_LOCKS
This option is removed upstream in favour of plain INVARIANTS.
VNASSERT is always defined so I see no reason to use it conditionally.
Reviewed-by: Brian Behlendorf <behlendorf1 at llnl.gov>
Reviewed-by: Alexander Motin <alexander.motin at TrueNAS.com>
Signed-off-by: Mark Johnston <markj at FreeBSD.org>
Closes #18136
[mlir][LLVM] Speed up `extractvalue(insertvalue)` canonicalization (#176478)
The current `ExtractValueOp::fold` implementation traverses the entire
chain of `InsertValueOp`s leading up to it. This can be extremely slow
if there are a huge number of `ExtractValueOp`s using values from the
same chain.
This PR improves this significantly in cases where a large number of the
`ExtractValueOp`s are actually reading from the same `InsertValueOp`.
That is, for patterns like:
```
%i0 = llvm.insertvalue %v0, %undef[0]
%i1 = llvm.insertvalue %v1, %0[1]
...
%i999 = llvm.insertvalue %v999, %998[999]
%e0 = llvm.extractvalue %i999[0]
%e1 = llvm.extractvalue %i999[1]
...
[17 lines not shown]
