[JTS] Correctly handle all zero profile values in VP metadata (#193402)
We can end up with cases where the VP metadata only has zero profile
values, for example if all of the functions end up being external and
uninstrumented. This caused fixes an assertion failure on the BOLT
builder that came up last time we tried to turn the pass on by default.
[lldb] Fix potential TestAlwaysRunThreadNames flakiness (#193405)
Change the stepped function to spin on a flag until the helper thread
advances the counter, so the step-over can only complete if the helper
thread actually ran.
Fixes #193398
Tools/scripts: Add report-outdated-for-maintainer.py
report-outdated-for-maintainer.py checks Repology and GitHub
and produces a categorized report of outdated ports.
It produces a better report than Repology produces:
it produces 3 tables:
* Majorly outdated ports
* Moderately outdated ports
* Slightly outdated ports
and it sorts outdated ports by how much are they outdated.
There are still minor bugs. This is WIP.
[llvm-mc][AsmMatcherEmitter] Fix the minimum ConversionTable entry size (#191977)
When working on a target with fully customized instruction
conversion method, there's a build failure due to the case that in the
target's generated asm matcher, the size of `ConversionTable` entry is 2
(i.e., the minimum size defined in `AsmMatcherEmitter` TableGen
backend).
However, for a target that has customized conversion method for all
instructions, a `ConversionTable` entry should be looking like: `{
CVT_<the-custom-conversion-method>, <the-position-of-operand>, CVT_Done
}`, where the position of operand for custom conversion is by-default 0.
This commit includes a test case to illustrate this scenario, along with
a little fix.
mail/spamassassin*: Ensure process name is renamed even in debug mode
Some customers run spamassassin in debug mode. This breaks rc's ability
to manage the process because the process name is unexpectedly "perl".
When in debug mode, also set the process name to spamd.
Reported by: Dan Mahoney <danm at prime.gushi.org>
Upstream bug: https://bz.apache.org/SpamAssassin/show_bug.cgi?id=8384
AMDGPU: Back-propagate wqm for sources of side-effect instruction
For readfirstlane instruction, as it would get undefined value if exec
is zero. To handle the case that only helper lanes execute the parent
block, we let the readfirstlane to execute under wqm. But this is not
enough. If the parent block was also executed by non-helper lanes, we
also need to make sure its sources were calculated under wqm. Otherwise,
if the instruction that generate the source of readfirstlane was
executed under exact mode, the value would contain garbage data in help
lane. The garbage data in helper lane maybe returned by the
readfirstlane running under wqm.
To fix this issue, we need to enforce the back-propagation of wqm for
instructions like readfirstlane. This was only done if the instruction
was possibly in the middle of wqm region (by checking OutNeeds).
