blocklist: blacklist: Chase recent upstream changes
Upstream fixed a couple of bugs:
1. Only attempt to restore the blocking rules if the database file
exists. Otherwise, when the service starts for the first time, it
fails (PR 258411).
2. Revert a commit that removed a call to close(bi->bi_fd), preventing
the descriptor from being deleted.
PR: 258411
PR: 291680
MFC after: 1 week
(cherry picked from commit 9c844b6110b3768a4fc3ce47cd9d1b30915213ec)
blocklist: Add vendor import instructions
Add vendor import instructions for blocklist.
It includes a "freebsd-changes.sh" script that takes care of adapting
paths and functions into FreeBSD.
Reviewed by: emaste
MFC after: 1 week
Differential Revision: https://reviews.freebsd.org/D49510
(cherry picked from commit 715cc257137099e022c7eecea4cd6995bb7604a3)
[clang][CodeGen] Promote point of GRO(CWG2563) (#151067)
This patch implement piece of the proposed solution to
[CWG2563](https://cplusplus.github.io/CWG/issues/2563.html):
> [9.6.4 dcl.fct.def.coroutine.p8] This return exits the scope of gro.
It exits the scope of promise only if the coroutine completed without
suspending.
If a coroutine completes without suspending, it does not exit the scope
of the promise until GRO conversion is done, because GRO conversion is
considered part of the coroutine execution. The current behavior
performs conversion after coroutine state cleanup, which does not
conform to the standard:
``` LLVM
before.cleanup:
; ...
br label %coro.cleanup
[43 lines not shown]
[SLP] Skip MMRA metadata if instruction can't have it (#173319)
Exposed by recent commit in e644f06c2ffc, but the wrong propagation
might be applied in other situations too.
Without this, we will get verification errors with e644f06c2ffc.
!mmra metadata attached to unexpected instruction kind
%3 = fmul <2 x float> %2, <float 1.000000e+00, float 0.000000e+00>,
!mmra !1
[llvm][CMake] Remove -fno-lifetime-dse (#173322)
Now that #24952 has been fixed by #170575, we no longer need to specify
-fno-lifetime-dse when building with gcc.
[PtrAuth] Add ConstantPtrAuth comparator to FunctionComparator.cpp (#159480)
When building rustc std for arm64e, core fails to compile successfully
with the error:
```
Constant ValueID not recognized.
UNREACHABLE executed at rust/src/llvm-project/llvm/lib/Transforms/Utils/FunctionComparator.cpp:523!
```
This is a result of function merging so I modified
FunctionComparator.cpp as the ConstantPtrAuth value would go unchecked
in the switch statement.
The test case is a reduction from the failure in core and fails on main
with:
```
********************
FAIL: LLVM :: Transforms/MergeFunc/ptrauth-const-compare.ll (59809 of 59995)
******************** TEST 'LLVM :: Transforms/MergeFunc/ptrauth-const-compare.ll' FAILED ********************
[39 lines not shown]
Update to use jdk 17 and latest tanukiwrapper
* Dont build the installer - we dont install or use it
* Dont read /proc/cpuinfo and set opt to ARMV8 on aarch64
* Update config to use corrected tanukiwrapper dir name
and remove no longer supported stripquotes option
ok sthen@ pascal@ ian@
Update to 3.6.3 and use jdk 11 to build
* fix misspelled directory name
* clean up patches
* intentionally remove jdk RUN_DEPENDS, applications that use this will
have a RUN_DEPENDS on a jdk
ok sthen@ pascal@ ian@
[IR] Fix User use-after-destroy by zapping in ~User (#170575)
First, this moves the removal of operands from use lists from
`User::operator delete` to `User::~User`. This is straightforward, and
nothing blocks that.
Second, this makes LLVM more compatible with bug finding tools like
MSan, GCC `-flifetime-dse`, and forthcoming enhancements to Clang itself
through `dead_on_return` annotations.
However, the complication is that `User::operator delete` needs to
recover the start of the allocation, and it needs to recover that
information somehow without examining the fields of the `User` object.
The natural way to handle this is for the destructor to return an
adjusted `this` pointer, and that's in fact how deleting destructors are
often implemented, but it requires making assumptions about the C++ ABI.
Another solution to this problem in C++20 would be to use [destroying
delete](https://en.cppreference.com/w/cpp/memory/new/destroying_delete_t),
[19 lines not shown]
Mips: Improve MipsAsmParser::expandDivRem (#172967)
Fixes: #172965
In fact MipsAsmParser::expandDivRem is in a so bad status:
1. Div may not execute at all in most case
```
.set reorder
bnez $3, $tmp0
div $zero, $2, $3
break 7
$tmp0:
```
`.set reorder` may insert a nop after bnez, which will skip `div` if $3
is not zero.
2. `break 6` is wrong here.
multimedia/ffmpegthumbnailer: Update 2.2.3 => 2.3.0, take maintainership
Changelog:
https://github.com/dirkvdb/ffmpegthumbnailer/blob/v2.3.0/ChangeLog
Port changes:
- Upstream switched to 'v' version suffix so add it.
- New release contains the remote patch already so remove it.
- Upstream switched to c++14 standart from 11.
- Add new build option similar to current one.
- Remove USES=pathfix.
- Fix warnings from portclippy.
PR: 291861
multimedia/ffmpegthumbnailer: Update 2.2.3 => 2.3.0, take maintainership
Changelog:
https://github.com/dirkvdb/ffmpegthumbnailer/blob/v2.3.0/ChangeLog
Port changes:
- Upstream switched to 'v' version suffix so add it.
- New release contains the remote patch already so remove it.
- Upstream switched to c++14 standart from 11.
- Add new build option similar to current one.
- Remove USES=pathfix.
- Fix warnings from portclippy.
PR: 291861
[CI] Fix printing of test report in summary view (#173314)
ffe973a3e76eab1f19cfd58418891ffa24f6ad46 changed some of the internal
APIs to return a tuple instead of just the report. This callsite was
never updated which resulted in the tuple being printed to the summary
view when we only wanted the report.
[IR] Value::setNameImpl: fix use-after-free when new name aliases old storage (#173258)
When setName() is called with a StringRef derived from the current name,
it results in a use-after-free error reported by AddressSanitizer.
A newly added test ValueTest.setNameShrink demonstrates the issue
(configure LLVM with -DLLVM_USE_SANITIZER=Address).
Fix by creating the new ValueName before removing/destroying the old one.
