`-Wall` on clang-cl is equivalent to `-Weverything` on clang. We already add the correct warning flag depending whether we are in an MSVC-like environment, so just remove it from the list of flags that get passed unconditionally.
Spies: libcxx-commits
Differential Revision: https://reviews.llvm.org/D146378
Before this patch we would demangle abi-tagged structures as follows:
```
$ c++filt -n _ZN1SB5OuterC2Ev
S[abi:Outer]:()
$ c++filt -n _ZN1SB5OuterD2Ev
S[abi:Outer]::~()
```
This is because `Node::getBaseName` was unimplemented for the
`AbiTagAttr` node, which meant that when we tried printing `CtorDtorName`
where its `Basename` `Node` was an `AbiTagAttr`, we'd drop the
name.
Addresses https://github.com/llvm/llvm-project/issues/61213
Differential Revision: https://reviews.llvm.org/D145492
This changes all `__enable_if`s inside `<string>` to a common pattern. Specifically, it's always inside the `template <>` and uses the `, int> = 0` style.
Reviewed By: ldionne, #libc
Spies: mikhail.ramalho, EricWF, libcxx-commits
Differential Revision: https://reviews.llvm.org/D144568
The original `__dynamic_cast` implementation does not use the ABI-provided `src2dst_offset` parameter which helps improve performance on the hot paths. This patch improves the performance on the hot paths in `__dynamic_cast` by leveraging hints provided by the `src2dst_offset` parameter. This patch also includes a performance benchmark suite for the `__dynamic_cast` implementation.
Reviewed By: philnik, ldionne, #libc, #libc_abi, avogelsgesang
Spies: mikhail.ramalho, avogelsgesang, xingxue, libcxx-commits
Differential Revision: https://reviews.llvm.org/D138005
An #elif SANITIZER_SOLARIS clause was removed in D120048, but it also
removed the #else clause for the error fallback, causing the build to
fail on NetBSD.
Differential Revision: https://reviews.llvm.org/D146316
Enable Scudo on RISCV64 on both clang side and compiler-rt side.
Reviewers: cryptoad, eugenis, vitalybuka, luismarques, hiraditya
Reviewed By: vitalybuka, luismarques
Differential Revision: https://reviews.llvm.org/D137397
When checking a C file, enum tags are of type `int` instead of the enum
type as in C++.
So the checker was using `i` as the prefix for enum tags instead of main
letters of the enum type name (for example `rt` for `enum REV_TYPE`).
This commit fixes this divergence and makes the behavior the same between
C and C++ files.
For example, `enum REV_TYPE { rtRevValid };` won't be reported as badly
named when in a C file. Previously, it would have proposed a rename to
`iRevValid`.
This commit also add a file to test the hungarian notation checker with C
files.
The test file was made from identifier-naming-hungarian-notation.cpp
with C++-only features removed.
Reviewed By: carlosgalvezp
Differential Revision: https://reviews.llvm.org/D144912
This patch adds patterns to reduce redundant mov and sel instructions
for shift intrinsics with FalseLanesZero mode, when
FeatureExperimentalZeroingPseudosis supported.
For example, before:
mov z1.b, #0
sel z0.b, p0, z0.b, z1.b
asr z0.b, p0/m, z0.b, #7
After:
movprfx z0.b, p0/z, z0.b
asr z0.b, p0/m, z0.b, #7
Reviewed By: paulwalker-arm
Differential Revision: https://reviews.llvm.org/D145551
By default ELFLinkGraphBuilder will now create LinkGraph sections with NoAlloc
lifetime for debug info sections in the original object. Debug sections are not
kept alive by default, and will be dead-stripped unless some plugin marks them
as live in the pre-prune phase.
The function doesn't use anything from VPRecipeBuilder, so move the
definition to where it is actually used and turn it into a simple static
function.
It also makes the VPRecipeBuilder argument for createAndOptimizeReplicateRegions
unnecessary.
SymbolFile::ParseAllLanguages allows collecting the languages of the
extra compile units a SymbolFileDWARFDebugMap may have, which can't
be accessed otherwise. For every other symbol file type, it should
behave exactly the same as ParseLanguage.
rdar://97610458
Differential Revision: https://reviews.llvm.org/D146265
This reapplies 2cc64df0bd, which was reverted in
5379c46d49 due to bot failures.
The new patch contains fixes to ELFLinkGraphBuilder.h to better handle
non-SHT_ALLOC sections (these were being accidentally skipped in the previous
patch), and to skip SHT_NULL sections.
Correct issue when incorrectly matched bitfield loop
variable would still be considered valid and equal to
base type, because check didnt compare size of bitfield.
Fixes issue introduced in: D142587
Reviewed By: carlosgalvezp
Differential Revision: https://reviews.llvm.org/D145958
ASMPrinter was relying on feature bits to setup extra SGRPs in the knerel
descriptor for the xnack_mask. This was broken for the dynamic XNACK "any" TID
setting which could cause user SGPRs to be clobbered if the number of SGPRs
reserved was near a granulated block boundary.
When XNACK was enabled this worked correctly in the ASMParser which meant some
kernels were only failing without "-save-temps".
Fixes: SWDEV-382764
Reviewed By: kzhuravl
Differential Revision: https://reviews.llvm.org/D145401
This speeds up section lookup by name.
This change was motivated by poor performance of a testcase while trying to fix
the NoAlloc lifetime patch that was originally landed as 2cc64df0bd. The
NoAlloc lifetime patch causes ELF non-SHF_ALLOC sections to be given a JITLink
Section (previously they were skipped), and the
llvm/test/ExecutionEngine/JITLink/X86/ELF_shndex.s testcase creates > 64k
non-SHF_ALLOC sections, each of which now needs to be checked to ensure that its
name does not clash. Moving to a DenseMap allows us to implement this check
efficiently.
This adds debug info support for
- `thread_local` global variables, both in non-PIC and PIC modes
- (non-thread_local) Global variables in PIC mode
The former needs to read the value from an offset relative to
`__tls_base` and the latter an offset from `__memory_base`. The code for
doing this overlaps with some of the existing code to add
`__stack_pointer` global, so this adds a new member function to add a
a global in `TI_GLOBAL_RELOC` mode and use it in all three places.
Split DWARF support is currently patchy at best, because the index for
`__tls_base` is not fixed after dynamic linking. The preexisting split
DWARF support for `__stack_pointer` relies on that in practice it is
always index 0. This does similar hardcoding for `__tls_base` and
`__memory_base`, but `__tls_base`'s index in dynamic linking is not
fixed now (See
19afbfe331/lld/wasm/Driver.cpp (L786-L823)
for details), TLS + dynamic linking will not work at the moment.
Fixes https://bugs.chromium.org/p/chromium/issues/detail?id=1416702.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D145626
We have a good comment on `TEE` transformation in `RegStackify`:
547e345666/llvm/lib/Target/WebAssembly/WebAssemblyRegStackify.cpp (L613-L632)
And I think it can be helpful to have some more comments on how the
`TEE`s created in `RegStackify` are converted into `LOCAL_TEE`s.
Variable `OldReg` is changed to `DefReg` to be consistent with
`RegStackify`'s comment.
Reviewed By: tlively
Differential Revision: https://reviews.llvm.org/D146084
When making `DBG_VALUE`/`DBG_VALUE_LIST` instructions undefined, there
is a method that takes care of it so we don't need to do it manually.
This changes the test because previously we are converting
`DBG_VALUE_LIST`s into `DBG_VALUE $noreg` but now we leave
`DBG_VALUE_LIST` but set it to undef by turning all its register
operands `$noreg`. The effect is the same.
Reviewed By: dschuff
Differential Revision: https://reviews.llvm.org/D145998
The current implementation output the LLVM formatted heading for group
sections, which was not valid JSON. This patch provides two small
customization points that allow the heading to vary between the two
implementations, and another that allows the section members to be
output as valid JSON objects.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D137095
Prior to this patch, the JSON output would emit an invalid key from the
shared LLVM implementation. This caused llvm-readobj to output invalid
JSON. This patch introduces a small helper function to print the
relocation information differently between the LLVM and JSON formats.
Before this patch:
```
"Relocations": [Section (2) .rel.text {
{
"Relocation": {
"Offset": 0,
"Type": {
"Value": "R_X86_64_NONE",
"RawValue": 0
},
"Symbol": {
"Value": "rel_0",
"RawValue": 1
}
}
},
...
```
After this patch:
```
"Relocations": [
{
"SectionIdx": 2,
"Relocs": [
{
"Relocation": {
"Offset": 0,
"Type": {
"Name": "R_X86_64_NONE",
"Value": 0
},
"Symbol": {
"Name": "rel_0",
"Value": 1
}
}
},
...
```
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D137094
A previous change [1] moved retrieval of the caller PC
(`__builtin_return_address(0)` via `CALLERPC`) from an
interface-boundary function into a shared helper function
`ExternalAccess`. If this function does not get inlined, we fail to
collect the appropriate caller PC for the "TSan interface boundary".
[1] https://reviews.llvm.org/D32360
rdar://78489600
Differential Revision: https://reviews.llvm.org/D146264
Today the JSON uses `Value` and `RawValue` when printing `Flags`, when really
the `Value` field is always the name of an Enum variant, and `RawValue` is its
underlying numeric value. Similarly, we rename the `RawFlags` key to `Value`,
to match the new scheme. This also allows JSON parsing to use consistent logic
for `Flag` types.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D137091
The existing JSON incorrectly outputs line breaks and other invalid JSON.
Example Before this patch:
```
...
"Relocations":[Section (9) .rela.dyn {
0xA3B0 R_X86_64_RELATIVE - 0x43D0
0xA3B8 R_X86_64_RELATIVE - 0x4A30
...
```
Example After this patch:
```
...
"Relocations":[Section (9) .rela.dyn {
{"Relocation":{"Offset":41904,"Type":{"Value":"R_X86_64_RELATIVE","RawValue":8},
"Symbol":{"Value":"","RawValue":0},"Addend":17360}},
{"Relocation":{"Offset":41912,"Type":{"Value":"R_X86_64_RELATIVE","RawValue":8},
"Symbol":{"Value":"","RawValue":0},"Addend":18992}},
{"Relocation":{"Offset":41920,"Type":{"Value":"R_X86_64_RELATIVE","RawValue":8},
"Symbol":{"Value":"","RawValue":0},"Addend":17440}},
...
```
Note there are still issues with the Section, but each Relocation is
now a valid JSON object that can be parsed. Future patches will address
the issues regarding JSON output for the Section.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D137089
Today, the LLVM output uses special handling when the Other field is 0.
This output makes sense for a command line utility that a human will
read, but JSON is a machine readable format, so being consistent is more
important. Prior to this change, any consumer of the JSON output would
need to handle the Other field specially, since the structure of the
JSON would no longer be consistent.
Changes to JSON output when Other flag == 0:
```
"Other": 0, -> "Other": {
"RawFlags": 0,
"Flags": []
},
```
There are no changes to when Other flag != 0:
```
"Other": { -> "Other": {
"RawFlags": 1, "RawFlags": 1,
"Flags": [ "Flags": [
... ...
] ]
}, },
```
This patch adds a overload for the JSONELFDumper's printSymbol() method,
that uses consistent output formatting, regardless of the value of the
Other field.
Depends on D137092
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D137088
Since all ELFDumper implementations will require the same logic when
dealing with Other Flags, we move the logic into a helper so that it can
be easily reused across implementations.
Reviewed By: jhenderson
Differential Revision: https://reviews.llvm.org/D137092
There were two major problems with the tests.
First, with the pointer size being 32 bit and the original IVs also being 32 bit, almost all of the positive tests were actually unsound. An upcoming change will add the appropriate safety check, but the test diffs are really hard to understand without switching the tests to 64 bit pointers first.
Second, checking debug messages for failures is a major bad practice. This should not have been accepted in review at all. The reason is that it makes the *order* of legality checks visibile and modifying any of them becomes annoying and tedious.
