This PR introduces alpha.webkit.UncheckedLocalVarsChecker which detects
a raw reference or a raw pointer local, static, or global variable to a
CheckedPtr capable object without a guardian variable in an outer scope.
update_mc_test_check script handle the "error case testline" wrong in
three cases:
1. when user select "--llvm-mc-binary" with a path, the script does not
add "not" on top of the "--llvm-mc-binary" and thus getting non-zero
exit code and failed.
2. When "not" is presented in runline while not all testlines are
expected to fail, the script need to check if the "not" is needed when
it execute llvm-mc line by line. Otherwise the script will fail on
testline which is passing.
3. When there are multiple runlines, the error checkline need to use
correct line offset for "[[LINE-X]]"
This patch solve these three issues
Whilst in upstream LLVM iPTRAny is only ever an integer, essentially an
alias for iPTR, this is not true in CHERI LLVM, where it gets used to
mean "iPTR or cPTR", i.e. either an integer address or a capability
(with cPTR and cN being the capability equivalents of iPTR and iN).
Moreover, iPTRAny is already not itself regarded as an integer (calling
isInteger() will give false), so the "i" prefix is misleading, and it
stands out as different from all the other xAny that have a single
letter prefix denoting their type.
Thus, rename it to pAny, reflecting that it is an overloaded pointer
type, which could end up being specialised to an integer type, but does
not have to be.
This has been verified to have no effect on the generated files for LLVM
itself or any in-tree target beyond the replacement of the identifier
iPTRAny with pAny in GenVT.inc.
Reviewers: arsenm
Reviewed By: arsenm
Pull Request: https://github.com/llvm/llvm-project/pull/113733
We've already called EnforceInteger on Types[0], and iPTRAny isn't
regarded as an integer type (note that TableGen special-cases iPTR here
to include that, though), so we cannot possibly still have an iPTRAny by
this point. Delete the check, and let getFixedSizeInBits catch it along
with all the other overloaded types if that ever becomes false. Also
document why we have this check whilst here.
Reviewers: arsenm
Reviewed By: arsenm
Pull Request: https://github.com/llvm/llvm-project/pull/113732
The former is a wrapper for the latter with two differences: Other is
mapped to "UNKNOWN" (rather than "MVT::Other"), and iPTR(Any) are mapped
to "TLI.getPointerTy()" rather than "MVT::iPTR(Any)".
The only uses are in FastISelMap::printFunctionDefinitions. Most of
these uses are just a form of name mangling to ensure uniqueness, so the
actual string isn't important (and, in the case of MVT::iPTR(Any), were
both to be used, they would clash). Two uses are for a case statement,
which requires the expression to be a constant (of the right type), but
neither UNKNOWN nor TLI.getPointerTy() are constants, so would not work
there. The remaining uses are where an expression is needed, so UNKNOWN
similarly doesn't work, though TLI.getPointerTy() could in this case.
However, neither iPTR nor iPTRAny are supposed to make it this far
through TableGen, and should instead have been replaced with concrete
types, so this case should not be hit. Moreover, for almost all of these
uses, the name is passed to getLegalCName, which will strip an MVT::
prefix but will leave TLI.getPointerTy() unchanged, which is not a valid
C identifier, nor component thereof.
Thus, delete this unnecessary, and mostly-broken, wrapper and just use
the underlying getEnumName. This has been verified to have no effect on
the generated files for any in-tree target, including experimental ones.
Reviewers: arsenm
Reviewed By: arsenm
Pull Request: https://github.com/llvm/llvm-project/pull/113731
This PR deprecates `<ccomplex>`, `<cstdbool>`, `<ctgmath>`, and
`<ciso646>` in C++17 and "removes" them in C++20 by special deprecation
warnings.
`<cstdalign>` is previously missing. This PR also tries to add them, and
then deprecates and "removes" `<cstdalign>`.
Papers:
- https://wg21.link/P0063R3
- https://wg21.link/P0619R4Closes#99985.
---------
Co-authored-by: Louis Dionne <ldionne.2@gmail.com>
Code cleanups for TableGen files, changes includes function names,
variable names and unused imports.
---------
Co-authored-by: Matt Arsenault <Matthew.Arsenault@amd.com>
add a unique and a sort option to the update_mc_test_check script.
These mc asm/dasm files are usually large in number of lines, and these
lines are mostly similar to each other. These options can be useful when
maintainer is merging or resolving conflicts by making the file
identifical
Also fixed a small issue in asm/dasm such that the auto generated header
line is
1. asm using ";" instead of "//" as comment marker
2. dasm using ";" instead of "#" as comment marker
fixes#112974
partially fixes#70103
### Changes
- Added new tablegen based way of lowering dx intrinsics to DXIL ops.
- Added int_dx_group_memory_barrier_with_group_sync intrinsic in
IntrinsicsDirectX.td
- Added expansion for int_dx_group_memory_barrier_with_group_sync in
DXILIntrinsicExpansion.cpp`
- Added DXIL backend test case
### Related PRs
* [[clang][HLSL] Add GroupMemoryBarrierWithGroupSync intrinsic
#111883](https://github.com/llvm/llvm-project/pull/111883)
* [[SPIRV] Add GroupMemoryBarrierWithGroupSync intrinsic
#111888](https://github.com/llvm/llvm-project/pull/111888)
This is to address the latest lit regressions
https://lab.llvm.org/buildbot/#/builders/64/builds/1285 caused by using
the internal lit shell. This change will limit using the internal lit
shell to TableGen on AIX so we do not hit these regressions.
Bots are now failing check-hwasan with
llvm-lit: .../llvm/utils/lit/lit/llvm/subst.py:133: fatal: Did not find
hwasan_symbolize in .../out/gn/stage2_unix/bin
This time it's the right fix for sure!
Bots are currently failing check-hwasan with
llvm-lit: .../llvm/utils/lit/lit/llvm/subst.py:133: fatal: Did not find
hwasan_symbolize in /.../out/gn/lib/clang/20/lib/linux
Maybe this fixes that.
See also llvm/utils/gn/secondary/compiler-rt/lib/hwasan/scripts/BUILD.gn.
