In #165604, a test was skipped on Windows, because the native PDB plugin
didn't set sizes on symbols. While the test isn't compiled with debug
info, it's linked with `-gdwarf`, causing a PDB to be created on
Windows. This PDB will only contain the public symbols (written by the
linker) and section information. The symbols themselves don't have a
size, however the DIA SDK sets a size for them.
It seems like, for these data symbols, the size given from DIA is the
distance to the next symbol (or the section end).
This PR implements the naive approach for the native plugin. The main
difference is in function/code symbols. There, DIA searches for a
corresponding `S_GPROC32` which have a "code size" that is sometimes
slightly smaller than the difference to the next symbol.
If an instruction at the high end of the 32-bit address space branches
to one at the low end, then the branch can be within range for a B or BL
instruction, and doesn't need a veneer. `ARM::inBranchRange` was failing
to detect this because it calculated the offset as an int64_t, so that
the offset was a small value ± 2^32 instead of just the small value.
Fixes#165211.
Prior to this change, the data layout calculation would not account for
explicitly set `-mabi=elfv2` on `powerpc64-unknown-linux-gnu`, a target
that defaults to `elfv1`.
This is loosely inspired by the equivalent ARM / RISC-V code.
`make check-llvm` passes fine for me, though AFAICT all the tests
specify the data layout manually so there isn't really a test for this
and I am not really sure what the best way to go about adding one would
be.
Signed-off-by: Jens Reidel <adrian@travitia.xyz>
This PR preserves the InBounds flag (#162477) where possible in PTRADD-related
DAGCombines. We can't preserve them in all the cases that we could in the
analogous GISel change (#152495) because SDAG usually represents pointers as
integers, which means that pointer provenance is not preserved between PTRADD
operations (see the discussion at PR #162477 for more details). This PR marks
the places in the DAGCombiner where this is relevant explicitly.
For SWDEV-516125.
In ELF file, there is a possible extended header for those phnum, shnum,
and shstrndx larger than the maximum of 16 bits. This extended header
use section 0 to record these fields in 32 bits.
We implment this feature so that programs rely on
ELFFile::program_headers() can get the
correct number of segments. Also, the consumers don't have to check the
section 0 themselve, insteead, they can use the getPhNum() as an
alternative.
There were a couple of quirks with this parameter:
1. It wasn't being set consistently. E.g., vector types would be of
count `1` but complex types would be `2`. Hence, it wasn't clear what
count was referring to.
2. `count` was not being set if the input type was invalid, possibly
leaving the input reference uninitialized.
3. Only one callsite actually made use of `count`, and that in itself
seems like it could be improved (added a FIXME).
If we ever need a "how many elements does this type represent", we can
implement one with a new `TypeSystem` API that does exactly that.
Cherry-picks this fix from the Apple LLDB fork. Ever since we upstreamed
https://github.com/llvm/llvm-project/pull/164011, this test is failing
on our pre-DWARFv5 bots:
```
13:47:54 ======================================================================
13:47:54 FAIL: test_frame_var_after_stop_at_implementation_dsym (TestRealDefinition.TestRealDefinition)
13:47:54 Test that we can find the implementation for an objective C type
13:47:54 ----------------------------------------------------------------------
13:47:54 Traceback (most recent call last):
13:47:54 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1804, in test_method
13:47:54 return attrvalue(self)
13:47:54 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/test/API/lang/objc/real-definition/TestRealDefinition.py", line 60, in test_frame_var_after_stop_at_implementation
13:47:54 self.expect(
13:47:54 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 2416, in expect
13:47:54 self.runCmd(
13:47:54 File "/Users/ec2-user/jenkins/workspace/llvm.org/lldb-cmake-matrix/llvm-project/lldb/packages/Python/lldbsuite/test/lldbtest.py", line 1006, in runCmd
13:47:54 self.assertTrue(self.res.Succeeded(), msg + output)
13:47:54 AssertionError: False is not true : Variable(s) displayed correctly
13:47:54 Error output:
13:47:54 error: <user expression 0>:1:12: "_hidden_ivar" is not a member of "(id) _bar"
13:47:54 1 | foo->_bar->_hidden_ivar
13:47:54 | ^
```
Original commit message:
For a while, tests were run with `target.prefer-dynamic-value`
overridden to `no-dynamic-values` – but the override was removed in
[D132382](https://reviews.llvm.org/D132382). At that time, tests that
failed were individually opted in to `no-dynamic-values`.
I don't recall specifics about `TestRealDefinition`, but it currently
fails with `no-dynamic-values`, and that is correct behavior. This
change removes the `no-dynamic-values` override.
Fix missed `return` when folding splat ConstantOp, it could work well
probably because of good compatibility of
`foldExtractStridedSliceNonSplatConstant`.
These tests are currently failing on some CI macOS instances due to an
issue with the system symbolizer.
This patch marks the tests unsupported on Darwin while we wait for all
CI machines to be updated to a newer OS.
rdar://160410051
All of the tests should work with the internal shell now, at least on
x86 Linux. Enable it by default for the performance/debuggability
advantages.
Reviewers: vitalybuka, fmayer
Reviewed By: fmayer, vitalybuka
Pull Request: https://github.com/llvm/llvm-project/pull/165148
`<wchar.h>` should at least include the forward declaration of `struct tm`,
since it's needed for the `wcsftime` declaration (also, see
https://man7.org/linux/man-pages/man0/wchar.h.0p.html).
Even though we don't yet have `wcsftime`, some downstream users (notably
- libcxx) expects to see `struct tm` declaration there, to re-declare it under
`std` namespace:
c46bfed1a4/libcxx/include/cwchar (L135)
So, add this type declaration to llvm-libc version of `wchar.h` now.
Previously, when the text in selected range was different from the
decl's name, `name` returned an invalid range, which could cause crashes
if `name` was nested in other range selectors that assumed always valid
ranges. With this change, `name` returns an `Error` if it can't get the
range.
The default config is too large for arm64 Android devices, which are
typically configured with 39-bit address space. This change brings it
inline with sanitizer_allocator_test.cpp.
The [previous patch](https://github.com/llvm/llvm-project/pull/163418)
has added a check to prevent adding an entry point into a constant
island, but only for successfully disassembled functions.
Because scanExternalRefs() is also called when a function fails to be
disassembled or is skipped, it can still attempt to add an entry point
at constant islands. The same issue may occur if without a check for it
So, this patch complements the 'constant island' check in
scanExternalRefs().
NOTE: For simplicity and convenience, `v2i64/v4i64` types on LA32 is not
optimized. If hoping to implement this in the future, special handling
for `bitcast` and `build_vector` is needed.
This patch contains several changes to `deallocate_size.pass.cpp`:
1. `static_cast`-ing some parameters to `size_t` to avoid narrowing.
2. Changing the type of loop variable `i` to `unsigned int` avoid
signedness mismatch with the constructor parameter.
3. Separately counting allocations and deallocations in variables
`allocated_` and `deallocated_`, and changing their type to `uint64_t`.
4. Avoiding `assert`-ing count of allocations when a `basic_string` is
allocated, just `assert`-ing after destruction instead.
This reverts commit 39f08eb997.
This was causing buildbot failures because we were using an explicit
python call instead of the python substitution. This leads to failures
on platforms that do not have a binary called python.
160058fc19 broke the Solaris bots because
they do not support RLIMIT_FSIZE despite it being in POSIX 2004. Disable
it there for now as the loss of test coverage should not be significant.
Currently this is being calculated incorrectly and will result in
incorrect index offsets in more complicated array slices. This PR tries
to address it by refactoring and changing the calculation to be more
correct.
We don't have the resources to test this and the builds are very
expensive. If someone is interested in providing x86_64 macOS they can
submit this as third-party binaries or provide resources to test the
builds.
The MappableType interface currently defines a `generateAccBounds`
method which examines a variable and generates `acc.bounds` operations
that encode its dimensions. The implementation can extract bounds
information in various ways: either from the MLIR type itself or by
analyzing the IR to find dimension information from defining operations.
However, we need to distinguish between cases where dimensional
information is not directly available from the type itself. This new
`hasUnknownDimensions` API returns true when the MLIR type does not
encode dimensional information and there is no associated descriptor or
metadata that would make this information extractable from the visible
ssa value the represents the variable. The expected use case is calling
`generateAccBounds` only when this returns true, as it indicates that
bounds must be extracted from the IR (by walking back from current
variable to its defining spots or its descriptor).
This supports cases such as raw references to arrays with non-constant
bounds (e.g., explicit-shape arrays in Fortran where bounds are passed
as arguments). This functionality could also be leveraged for CIR VLA
support in the future.
For FIR types:
- Box types return false (descriptor encodes dimensions)
- Reference types check if the pointee has dynamic size using
fir::hasDynamicSize()
Unfortunately this adds two more "no"s to cxx_dr_status for 232 and
2823.
---------
Co-authored-by: Vlad Serebrennikov <serebrennikov.vladislav@gmail.com>
Update getSCEVExprForVPValue to handle more complex expressions, to use
it in VPReplicateRecipe::comptueCost.
In particular, it supports construction SCEV expressions for
GetElementPtr VPReplicateRecipes, with operands that are
VPScalarIVStepsRecipe, VPDerivedIVRecipe and VPCanonicalIVRecipe. If we
hit a sub-expression we don't support yet, we return
SCEVCouldNotCompute.
Note that the SCEV expression is valid VF = 1: we only support
construction AddRecs for VPCanonicalIVRecipe, which is an AddRec
starting at 0 and stepping by 1. The returned SCEV expressions could be
converted to a VF specific one, by rewriting the AddRecs to ones with
the appropriate step.
Note that the logic for constructing SCEVs for GetElementPtr was
directly ported from ScalarEvolution.cpp.
Another thing to note is that we construct SCEV expression purely by
looking at the operation of the recipe and its translated operands, w/o
accessing the underlying IR (the exception being getting the source
element type for GEPs).
PR: https://github.com/llvm/llvm-project/pull/161276
the function signature for `GetStopDescription` is
`lldb::SBThread::GetStopDescription(char *dst_or_null, size_t len)`.
To get a description you need to call the function first time to get the
buffer size. a second time to get the description.
This is little worse from the python size as the signature is
`lldb.SBThread.GetStopDescription(int: len) -> list[str]` the user has
to pass the max size as possible with no way of checking if it is
enough.
This patch adds a new api
`lldb.SBThread.GetStopDescription(desc: lldb.SBStream()) -> bool` `bool
lldb::SBThread::GetStopDescription(lldb::SBStream &description)` which
handles this case.
Adds new Test case for lua.
Most of the cases were where a C++ file was being compiled with the C substitution.
There were a few cases of the opposite though.
LLDB seems to be the only real culprit in the LLVM codebase for these mismatches.
Rest of the LLVM presumably sticks at least language-specific options in the common substitutions
making the mistakes immediately apparent.
I found these by using Clang frontend configuration files containing language-specific options for
both C and C++ (e.g. `-std=c2y` and `-std=c++26`).
