[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]
[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.
