[WebAssembly] Reapply "[WebAssembly] Incorporate SCCs into WebAssemblyFixIrreducibleControlFlow" (#181755) (#184441)
Re-application of #181755.
Includes fixes to issues found after the original's merge.
[lldb] Use "assemble" instead of "compile" in formatter_bytecode.py (#184714)
Replace "compile" with "assemble" in formatter_bytecode. This is in
preparation for the addition of a Python to formatter bytecode compiler.
It will be more clear to have one meaning for "compile".
[Hexagon] Add missing early architecture features to V81 processor (#183499)
V81 was missing ArchV5, ArchV55, ArchV60, and ArchV62 in its feature
list, causing instructions requiring these architecture versions to fail
during compilation.
(cherry picked from commit 6f736e2cd9933aed1c8b72f2fe370f7d60bd3709)
libc/quad: narrow list of symbols exposed for 32-bit arm
lld doesn't notice, but ld.bfd complains.
Reviewed by: brooks
Differential Revision: https://reviews.freebsd.org/D55657
libc/quad: Switch to per-arch lists of symbols
This more closely mirrors libc/quad/Makefile.inc and is easier to
read.
Reviewed by: brooks
Differential Revision: https://reviews.freebsd.org/D55658
bsd.linker.mk: Sort list of linker features
Reindent the features as well to be friendly to long feature names.
Reviewed by: emaste
Differential Revision: https://reviews.freebsd.org/D55656
acpi: Don't attach a "wake" sysctl node to devices without the ACPI flags IVAR
Not all bus drivers for ACPI-aware devices implement the ACPI flags
IVAR used by the acpi_wake_set_sysctl handler. In some cases this may
be a feature as some new-bus devices share the same ACPI handle (e.g.
a pcibX device and its child pciY device) which can lead to confusing
results (e.g. setting the sysctl on pciY changes the behavior of the
parent pcibX device, but the "wake" sysctl for pcibX won't reflect the
new behavior, or reflect the device's state).
Reviewed by: obiwac, ngie, imp
Differential Revision: https://reviews.freebsd.org/D55562
[lld][Hexagon] Fix findMaskR8 missing duplex support (#183936)
findMaskR8() lacked an isDuplex() check, unlike findMaskR6(),
findMaskR11(), and findMaskR16() which all handle duplex instructions.
When the assembler generates R_HEX_8_X on a duplex SA1_addi instruction
(e.g. `{ r0 = add(r0, ##target); memw(r1+#0) = r2 }`), the wrong mask
0x00001fe0 placed relocation bits at [12:5] instead of [25:20],
corrupting the low sub-instruction (e.g. memw became memb).
Add the isDuplex() check returning 0x03f00000, and add a comprehensive
test covering all duplex instruction x relocation type combinations
across findMaskR6, findMaskR8, findMaskR11, and findMaskR16.
(cherry picked from commit 9105d9c24949d8cf9b740cb874027351e7230e70)
Fix incorrect syntax for some shells
In a world long vanished, the ascii char set did not have the |
character (0x7c) as a standard member, and could not be relied
upon existing. In systems only found today in archaeological digs,
that was handled by making '^' be the sh symbol for a pipe.
That meant that the regular expression notation for negating a
character class ([^stuff]) couldn't be used in shell patterns,
and so ! was used there instead of the ^. The ^ did not bother
use in REs as those almost always need to be quoted when included
in a shell command anyway - but quoting of shell patterns would
defeat their use as a pattern, so couldn't be used there.
In more modern times, this excuse for the difference has long gone,
^ isn't the pipe symbol in any shell that is likely to be encountered,
and so most shells allow either ^ or ! to represent negation of a
character class - ^ for compat with REs, and ! for compat with old
scripts.
[6 lines not shown]
[Clang] Ensure child classes export inherited constructors from base classes (#182706)
Inherited constructors in `dllexport` classes are now exported for ABI-compatible cases,
matching MSVC behavior. Constructors with variadic arguments or callee-cleanup
parameters are not yet supported and produce a warning.
This aims to partially resolve https://github.com/llvm/llvm-project/issues/162640.
Assisted by : Cursor // Claude Opus 4.6
Fix a bug in the watchpoint callback - in one case we weren't
returning anything from the callback. Fixing this on the off
chance that is what is causing the linux-only failure in this test
after PR:
https://github.com/llvm/llvm-project/pull/184272
witness: report a thread that can't sleep in WITNESS_WARN
Although this is not related to locking, but seems to be the right
place to catch violators, given that WITNESS_WARN is already used
widely in the kernel.
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D55316
witness: report a thread that can't sleep in WITNESS_WARN
Although this is not related to locking, but seems to be the right
place to catch violators, given that WITNESS_WARN is already used
widely in the kernel.
Reviewed by: kib, markj
Differential Revision: https://reviews.freebsd.org/D55316
[clang] Don't use `VarDecl` of local variables as `ManglingContextDecl` for lambdas (#179035)
Currently, in a C++20 modules context, a `VarDecl` of a local variable
can wrongly end up as a `ManglingContextDecl` for a lambda.
Fix this by removing `ContextKind::NonInlineInModulePurview` in
`Sema::getCurrentMangleNumberContext` and add
`IsExternallyVisibleInModulePurview` checks in the appropriate places:
- For externally visible functions defined in a module purview, add a
check to `isInInlineFunction`, renaming it to
`IsInFunctionThatRequiresMangling`
- For externally visible variables defined in a module purview, add a
new `ContextKind::ExternallyVisibleVariableInModulePurview` and an
appropriate check to the `VarDecl` case
Fixes #178893
---------
[4 lines not shown]
[C++20] [Modules] Set ManglingContextDecl when we need to mangle a lambda but it's nullptr (#177899)
Close https://github.com/llvm/llvm-project/issues/177385
The root cause of the problem is, when we decide to mangle a lamdba in a
module interface while the ManglingContextDecl is nullptr, we didn't
update ManglingContextDecl. So that the following use of
ManglingContextDecl is an invalid value.
(cherry picked from commit 772b15b3be153b1d2df910057af17926ea227243)
[flang][OpenMP] Utilities to get uppercase directive/clause names
It is a convention to use uppercase names of directives and clauses in
diagnostic messages, but getting such names is somewhat cumbersome:
```
parser::ToUpperCaseLetters(llvm::omp::getOpenMPDirectiveName(dirId));
parser::ToUpperCaseLetters(llvm::omp::getOpenMPClauseName(clauseId));
```
Implement `GetUpperName` (overloaded for clauses and directives) to
shorten it to
```
GetUpperName(dirId, version);
GetUpperName(clauseId, version);
```
This patch replaces existing instances of this pattern, adding the
use of OpenMP version where it was previously missing.
