BumpPtrAllocator::Allocate() is marked __attribute__((returns_nonnull)) when the
compiler supports it, which makes it UB to return null.
When there have been no allocations yet, the current slab is [nullptr, nullptr).
A zero-sized allocation fits in this range, and so Allocate(0, 1) returns null.
There's no explicit docs whether Allocate(0) is valid. I think we have to assume
that it is:
- the implementation tries to support it (e.g. >= tests instead of >)
- malloc(0) is allowed
- requiring each callsite to do a check is bug-prone
- I found real LLVM code that makes zero-sized allocations
Differential Revision: https://reviews.llvm.org/D125040
It turns out clang::expandUCNs only works on tokens that contain valid UCNs
and no other random escapes, and clang only uses it on raw_identifiers.
Currently we can hit an assertion by creating tokens with stray non-valid-UCN
backslashes in them.
Fortunately, expanding UCNs in raw_identifiers is actually all we need.
Most tokens (keywords, punctuation) can't have them. UCNs in literals can be
treated as escape sequences like \n even this isn't the standard's
interpretation. This more or less matches how clang works.
(See https://isocpp.org/files/papers/P2194R0.pdf which points out that the
standard's description of how UCNs work is misaligned with real implementations)
Differential Revision: https://reviews.llvm.org/D125049
Currently if a lexically-valid UCN encodes an invalid codepoint, then we
diagnose that, and then hit an assertion while trying to decode it.
Since there isn't anything preventing us reaching this state, remove the
assertion. expandUCNs("X\UAAAAAAAAY") will produce "XY".
Differential Revision: https://reviews.llvm.org/D125059
Re-materialize for debug instructions would cause a different code
generated if we enabled `-g`. This is bad. So we disable to
re-materialize for debug instructions.
On arm64 targets, when the crashing pc is 0, the caller
frame can be found by looking at $lr, but the crash
reports don't use that trick to show the actual crashing
frame. This patch adds that stack frame that lldb shows.
Also fix an issue where some register names were printed
as having a prefix of 'None'.
Differential Revision: https://reviews.llvm.org/D125042
rdar://92631787
A large DenseElementsAttr of i1could trigger a bug in printer/parser roundtrip.
Ex. A DenseElementsAttr of i1 with 200 elements will print as Hex format of length 400 before the fix. However, when parsing the printed text, an error will be triggered. After fix, the printed length will be 50.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D122925
The globals are better expressed as members of the Symbolizer, and all
functions operating on it should be methods instead.
Also using the standard idiom of wrapping the main code in
`if __name__ == '__main__'`.
Reviewed By: eugenis
Differential Revision: https://reviews.llvm.org/D125032
The patch adds SPIR-V specific intrinsics required to keep information
critical to SPIR-V consistency (types, constants, etc.) during translation
from IR to MIR.
Two related passes (SPIRVEmitIntrinsics and SPIRVPreLegalizer) and several
LIT tests (passed with this change) have also been added.
It also fixes the issue with opaque pointers in SPIRVGlobalRegistry.cpp
and the mismatch of the data layout between the SPIR-V backend and clang
(Issue #55122).
Differential Revision: https://reviews.llvm.org/D124416
Co-authored-by: Aleksandr Bezzubikov <zuban32s@gmail.com>
Co-authored-by: Michal Paszkowski <michal.paszkowski@outlook.com>
Co-authored-by: Andrey Tretyakov <andrey1.tretyakov@intel.com>
Co-authored-by: Konrad Trifunovic <konrad.trifunovic@intel.com>
This reverts commit f6dff93641.
This diagnostic is also in the -Wcomment group, which is in the -Wall
group, so the diagnostic is enabled in a wider context than GCC does.
That turns out to be disruptive for the Linux kernel builds still using
-std=gnu89 because the kernel requires C source files to start with //
comments: https://kernel.org/doc/html/v5.18-rc5/process/license-rules.html#license-identifier-syntax
Although we now have semi-rings to deal with arbitrary ops,
it is still good to convey zero-preserving semantics of
ops to the sparse compiler.
Reviewed By: bixia
Differential Revision: https://reviews.llvm.org/D125043
If a programmer is able to compile and link a program that contains types that
are not yet supported by the runtime, it must be because they're not yet
implemented.
This change will make it easier to find unimplemented code in tests.
Differential Revision: https://reviews.llvm.org/D125046
The fallback attribute parse path is parsing a Type attribute, but this results
in a really unintuitive error message: `expected non-function type`, which
doesn't really hint at tall that we were trying to parse an attribute. This
commit fixes this by trying to optionally parse a type, and on failure
emitting an error that we were expecting an attribute.
Differential Revision: https://reviews.llvm.org/D124870
Compared to the old implementation:
* In C++, we only recurse into aggregate classes.
* Unnamed bit-fields are not printed.
* Constant evaluation is supported.
* Proper conversion is done when passing arguments through `...`.
* Additional arguments are supported and are injected prior to the
format string; this directly supports use with `fprintf`, for example.
* An arbitrary callable can be passed rather than only a function
pointer. In particular, in C++, a function template or overload set is
acceptable.
* All text generated by Clang is printed via `%s` rather than directly;
this avoids issues where Clang's pretty-printing output might itself
contain a `%` character.
* Fields of types that we don't know how to print are printed with a
`"*%p"` format and passed by address to the print function.
* No return value is produced.
Reviewed By: aaron.ballman, erichkeane, yihanaa
Differential Revision: https://reviews.llvm.org/D124221
The ShouldShiftBeAdded lambda checks if extra space should be
added before the wrapped part of a braced list. If the first
element of the list is wrapped, no extra space should be added.
Fixes#55161.
Differential Revision: https://reviews.llvm.org/D124956
When picking the UnwindPlan row to use to backtrace,
off of the zeroth frame, decrement the return pc so
we're in the address range of the call instruction.
If this is a noretrun function call, the instruction
at the "return address" is likely an entirely different
basic block with possibly very different unwind rules,
and this can cause the backtrace to be incorrect.
Differential Revision: https://reviews.llvm.org/D124957
rdar://84651805
The names of the functions that are supposed to be exported do not match the implementations. This is due in part to cac7aabbd8.
This change makes the implementations and declarations match and adds a couple missing declarations.
The new names follow the pattern of the existing `verify` functions where the prefix is maintained as `_mlir_ciface_` but the suffix follows the new naming convention.
Reviewed By: rriddle
Differential Revision: https://reviews.llvm.org/D124891
A follow-up to 62b2a47 to centralize the logic that skips expressions
that the CFG does not emit. This allows client code to avoid
sprinkling this logic everywhere.
Add redirects in the transfer function to similarly skip such
expressions by forwarding the visit to the sub-expression.
Differential Revision: https://reviews.llvm.org/D124965
This test only fails on x86_64 clang-cl, not for i386.
(The root cause is still not explored, thus the FIXME is still
relevant.)
Differential Revision: https://reviews.llvm.org/D124994
On Windows on i386, C++ member functions use a different calling
convention (`__thiscall`) than the default one for regular functions
(`__cdecl`). (On Windows on architectures other than i386, both calling
convention attributes are no-ops.)
This matches how libstdc++ declares these types.
This fixes the std/thread/futures/futures.{shared,unique}_future/dtor.pass.cpp
tests on i386 mingw.
Differential Revision: https://reviews.llvm.org/D124990
All current Windows architectures (i386, x86_64, arm, arm64) get
the full_size() behaviour here. x86_64 (the only one tested in CI
currently) is handled by the first ifdef at the top, but handle
Windows in general on all other architectures later.
Differential Revision: https://reviews.llvm.org/D124989
In the common case of converting an ExecutorAddr to a function pointer type,
this eliminates the need for the '(*)' boilerplate to explicitly specify a
function pointer. E.g.:
auto *F = A.toPtr<int(*)()>();
can now be written as
auto *F = A.toPtr<int()>();
We needed something that would delay the creation of the undef until after the rem-by-constant expansion, so I used a SSE shift of undef by zero which will expand to undef.
This patch adds a new feature to bolt heatmap to print the hotness of each section in terms of the percentage of samples within that section.
Sample output generated for the clang binary:
Section Name, Begin Address, End Address, Percentage Hotness
.text, 0x1a7b9b0, 0x20a2cc0, 1.4709
.init, 0x20a2cc0, 0x20a2ce1, 0.0001
.fini, 0x20a2ce4, 0x20a2cf2, 0.0000
.text.unlikely, 0x20a2d00, 0x431990c, 0.3061
.text.hot, 0x4319910, 0x4bc6927, 97.2197
.text.startup, 0x4bc6930, 0x4c10c89, 0.0058
.plt, 0x4c10c90, 0x4c12010, 0.9974
Reviewed By: rafauler
Differential Revision: https://reviews.llvm.org/D124412
GCC warns with a pedantic warning when -std=gnu89, but Clang would only
diagnose in -std=c89 mode. Clang now matches the GCC behavior in both
modes.
Fixes#18427
Currently, debugserver has a test to check if it was launched in
translation. The intent was to cover the case where an x86_64
debugserver attempts to control an arm64/arm64e process, returning
an error. However, this check also covers the case where users
are attaching to an x86_64 process, exiting out before attempting
to hand off control to the translated debugserver at
`/Library/Apple/usr/libexec/oah/debugserver`.
This diff delays the debugserver translation check until after
determining whether to hand off control to
`/Library/Apple/usr/libexec/oah/debugserver`. Only when the
process is not translated and thus has not been handed off do we
check if the debugserver is translated, erroring out in that case.
Reviewed By: jasonmolenda
Differential Revision: https://reviews.llvm.org/D124814
Discovered in a large object that would need a 64 bit index (but the
cu/tu index format doesn't include a 64 bit offset/length mode in
DWARF64 - a spec bug) but instead binutils dwp overflowed the offsets
causing overlapping regions.
Sam McCall