This allows IDEs to render LLDB expression diagnostics to their liking
without relying on characterprecise ASCII art from LLDB. It is exposed
as a versioned SBStructuredData object, since it is expected that this
may need to be tweaked based on actual usage.
This patch implements the UnscheduledSuccs counter in DGNode. It counts
the number of unscheduled successors and is used by the scheduler to
determine when a node is ready.
As discussed in https://github.com/llvm/llvm-project/pull/109284
Copied msan tests from 64-bit platforms to following 32-bit platforms:
* MIPS
* ARM
* RISCV
* PowerPC
* i386
Most of the tests have been copied form mips64.
Target triple and test contents have not been changed: to be done in
next PR.
---------
Co-authored-by: Kamil Kashapov <kashapov@ispras.ru>
This reverts commit a89e01634fe2e6ce0b967ead24280b6693b523dc.
This is being reverted because it broke the test:
Unwind/trap_frame_sym_ctx.test
/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake/llvm-project/lldb/test/Shell/Unwind/trap_frame_sym_ctx.test:21:10: error: CHECK: expected string not found in input
CHECK: frame #2: {{.*}}`main
c.srli(64) and c.srai(64) are encoded differently than c.slli(64). The
former have a 3-bit register, while the latter has a 5-bit register.
c.srli and c.srai already use RVInst16CB.
The "let Inst{11-10} =" prevented this from causing any functional
issues by dropping the upper 2 bits of the register. The ins/outs list
uses GPRC so the register class is constrained.
After https://github.com/llvm/llvm-project/pull/80007 Fuchsia builds are
now always building cxx_shared for arm64 and x64 Linux. Ultimately, this
is because the LIBCXX_ENABLE_SHARED is not used in compiler-rt to select
the correct libc++ target, and because cxx_shared is now always defined,
it is selected as a dependency when building runtimes tests.
---------
Co-authored-by: Petr Hosek <phosek@google.com>
Fixes https://github.com/llvm/llvm-project/issues/110122
- Create remap_file_pages.h/.cpp wrapper for the linux sys call.
- Add UnitTests for remap_file_pages
- Add function to libc/spec/linux.td
- Add Function spec to mman.yaml
When NewInterval is below DAGInterval we used to revisit instructions
already visited. This patch fixes this by separating the scan in two:
1. The full scan of the NewInterval, and
2. The cross-interval scan for DAGInterval.
This is further explained in the new description.
Ensures that struct padding is not skipped, as it may contain actual
data if the struct is really a union.
The patch originated from a discussion on #53710Fixes#53710
This is a follow-up to https://github.com/llvm/llvm-project/pull/108344.
The original bailout check was overly strict, causing it to miss cases
like the vector(initializer_list, allocator) constructor. This patch
relaxes the check to address that issue.
Fix#111680
This change is identical to
26800a2c7e7996dc773b4e990dd5cca41c45e1a9 ("[sanitizer] Undef
_TIME_BITS along with _FILE_OFFSET_BITS on Linux"), but for
sanitizer_procmaps_solaris.cpp.
Indeed, even though sanitizer_procmaps_solaris.cpp is Solaris
specific, it also gets built on Linux platforms. It also includes
sanitizer_platform.h, which also ends up including features-time64.h,
causing a build failure on 32-bit Linux platforms on which 64-bit
time_t is enabled by setting _TIME_BITS=64.
To fix this, we do the same change: undefine _TIME_BITS, which anyway
will cause no harm as the rest of this file is inside a
SANITIZER_SOLARIS compile-time conditional.
Fixes:
In file included from /home/thomas/buildroot/buildroot/output/host/i686-buildroot-linux-gnu/sysroot/usr/include/features.h:394,
from ../../../../libsanitizer/sanitizer_common/sanitizer_platform.h:25,
from ../../../../libsanitizer/sanitizer_common/sanitizer_procmaps_solaris.cpp:14:
/home/thomas/buildroot/buildroot/output/host/i686-buildroot-linux-gnu/sysroot/usr/include/features-time64.h:26:5: error: #error "_TIME_BITS=64 is al
lowed only with _FILE_OFFSET_BITS=64"
26 | # error "_TIME_BITS=64 is allowed only with _FILE_OFFSET_BITS=64"
| ^~~~~
Signed-off-by: Thomas Petazzoni <thomas.petazzoni@bootlin.com>
Closes: https://github.com/llvm/llvm-project/pull/99699
For the block smaller than a page size, one block is unlikely to
introduce more unused pages (at most 2 if it acrosses the page boundary
and both touched pages are unused). So it's better to apply the
threshold to reduce the time of scanning groups that can't release any
new pages.
Currently, WebAssembly/WASI target does not provide direct support for
code coverage.
This patch set fixes several issues to unlock the feature. The main
changes are:
1. Port `compiler-rt/lib/profile` to WebAssembly/WASI.
2. Adjust profile metadata sections for Wasm object file format.
- [CodeGen] Emit `__llvm_covmap` and `__llvm_covfun` as custom sections
instead of data segments.
- [lld] Align the interval space of custom sections at link time.
- [llvm-cov] Copy misaligned custom section data if the start address is
not aligned.
- [llvm-cov] Read `__llvm_prf_names` from data segments
3. [clang] Link with profile runtime libraries if requested
See each commit message for more details and rationale.
This is part of the effort to add code coverage support in Wasm target
of Swift toolchain.
Refer: 7.3.1 from [ISO
SPEC](https://www.open-std.org/jtc1/sc22/wg14/www/docs/n3220.pdf)
I have added complex variants of F16 and F128 in libc doc but have
omitted support for them since we will have to first investigate how
their support matrix for clang and gcc looks like, and then add header
guards for them accordingly. Planning to add them in follow up PRs once
this gets landed.
Check invoked tool with `starts_with`.
Addresses the issue where `perf2bolt` invoked using a distro symlink
`perf2bolt-16` fails to run in perf2bolt mode and runs in llvm-bolt mode
instead.
The issue is mentioned in https://vondra.me/posts/playing-with-bolt-and-postgres/
Test Plan:
```
ln -sf perf2bolt perf2bolt-20
perf2bolt-20 clang -p perf.data -o fdata.clang -w yaml.clang
...
PERF2BOLT: wrote 188593 objects and 0 memory objects to fdata.clang
```
Reviewers: ayermolo, rafaelauler, dcci, maksfb
Reviewed By: maksfb
Pull Request: https://github.com/llvm/llvm-project/pull/111072
Currently, our unwinder assumes that the functions are continuous (or at
least, that there are no functions which are "in the middle" of other
functions). Neither of these assumptions is true for functions optimized
by tools like propeller and (probably) bolt.
While there are many things that go wrong for these functions, the
biggest damage is caused by the unwind plan caching code, which
currently takes the maximalist extent of the function and assumes that
the unwind plan we get for that is going to be valid for all code inside
that range. If a part of the function has been moved into a "cold"
section, then the range of the function can be many megabytes, meaning
that any function within that range will probably fail to unwind.
We end up with this maximalist range because the unwinder asks for the
Function object for its range. This is only one of the strategies for
determining the range, but it is the first one -- and also the most
incorrect one. The second choice would is asking the eh_frame section
for the range of the function, and this one returns something reasonable
here (the address range of the current function fragment) -- which it
does because each fragment gets its own eh_frame entry (it has to,
because they have to be continuous).
With this in mind, this patch moves the eh_frame (and debug_frame) to
the front of the queue. I think that preferring this range makes sense
because eh_frame is one of the unwind plans that we return, and some
others (augmented eh_frame) are based on it. In theory this could break
some functions, where the debug info and eh_frame disagree on the extent
of the function (and eh_frame is the one who's wrong), but I don't know
of any such scenarios.
Closes#107985.
LanguageExtensions.rst states that `__builtin_shufflevector` and
`__builtin_convertvector` can be evaluated as constants, but this is not
reflected in Butiltins.td. This patch aligns these two.
The worker clause specifies iterations of the loop/ that are executed in
parallel by distributing the iterations among the multiple works within
a single gang.
The sema rules for this type are simply that it cannot be combined with
a `kernel` construct with a `num_workers` clause, child `loop` clauses
cannot contain a `gang` or `worker` clause, and that the argument is oly
allowed when associated with a `kernel`.
Bug fix: `@autoreleasepool`, `@synchronized`, and `@finally` were not
being noticed and treated as function effect violations.
---------
Co-authored-by: Doug Wyatt <dwyatt@apple.com>
This paper adds 'i' and 'j' as suffixes for forming a _Complex constant.
This feature has been supported in Clang since at least Clang 3.0, so
only test coverage is needed.
It does remove -Wgnu-imaginary-constant in C mode (still used in C++
mode) because the feature is now a C2y feature rather than a GNU one.
This is part of the effort to support for enabling plugins on windows by
adding better support for building llvm and clang as a DLL. These macros
are similar to the ones i added in #96630, but are for clang.
Added explicit symbol visibility macros definitions that are defined in
a new header and will be used to for shared library builds of clang to
export
symbols.
Updated clang cmake to define a macro to enable the symbol visibility
macros and explicitly disable them for clang tools that always use
static linking.
---------
Co-authored-by: Aaron Ballman <aaron@aaronballman.com>
The underlying issue was caused by a file included in two different
places which resulted in duplicate definition errors when linking
individual shared libraries. This was fixed in c3201ddaeac02a2c86a38b
[#109874].
