This excludes some builtins that take argument types not yet handled
by the `-fdeclare-opencl-builtins` machinery, and also excludes
builtins that are already defined in `Builtins.def`.
MCTargetOptionsCommandFlags.inc and CommandFlags.inc are headers which contain
cl::opt with static storage.
These headers are meant to be incuded by tools to make it easier to parametrize
codegen/mc.
However, these headers are also included in at least two libraries: lldCommon
and handle-llvm. As a result, when creating DYLIB, clang-cpp holds a reference
to the options, and lldCommon holds another reference. Linking the two in a
single executable, as zig does[0], results in a double registration.
This patch explores an other approach: the .inc files are moved to regular
files, and the registration happens on-demand through static declaration of
options in the constructor of a static object.
[0] https://bugzilla.redhat.com/show_bug.cgi?id=1756977#c5
Differential Revision: https://reviews.llvm.org/D75579
Sizeless types can't be used with "new", so it doesn't make sense
to use them with "delete" either. The SVE ACLE therefore doesn't
allow that.
This is slightly stronger than for normal incomplete types, since:
struct S;
void f(S *s) { delete s; }
is (by necessity) just a default-on warning rather than an error.
Differential Revision: https://reviews.llvm.org/D76219
Summary:
Currently, ValueRange is very hard to extend with new kind of constraints.
For instance, it forcibly encapsulates relations between arguments and the
return value (ComparesToArgument) besides handling the regular value
ranges (OutOfRange, WithinRange).
ValueRange in this form is not suitable to add new constraints on
arguments like "not-null".
This refactor introduces a new base class ValueConstraint with an
abstract apply function. Descendants must override this. There are 2
descendants: RangeConstraint and ComparisonConstraint. In the following
patches I am planning to add the NotNullConstraint, and additional
virtual functions like `negate()` and `warning()`.
Reviewers: NoQ, Szelethus, balazske, gamesh411, baloghadamsoftware, steakhal
Subscribers: whisperity, xazax.hun, szepet, rnkovacs, a.sidorin, mikhail.ramalho, donat.nagy, dkrupp, Charusso, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D74973
new-expressions for a type T require sizeof(T) to be computable,
so the SVE ACLE does not allow them for sizeless types. At the moment:
auto f() { return new __SVInt8_t; }
creates a call to operator new with a zero size:
%call = call noalias nonnull i8* @_Znwm(i64 0)
This patch reports an appropriate error instead.
Differential Revision: https://reviews.llvm.org/D76218
The error_stream and result parameter were inconsistently checked for
being null, so we might as well make them references instead of crashing
in case someone passes a nullptr and hits one of the code paths that are
currently not doing a nullptr check on those parameters. Also change
output_stream for consistency.
This flag is used by avr-gcc (starting with v10) to set the width of the
double type. The double type is by default interpreted as a 32-bit
floating point number in avr-gcc instead of a 64-bit floating point
number as is common on other architectures. Starting with GCC 10, a new
option has been added to control this behavior:
https://gcc.gnu.org/wiki/avr-gcc#Deviations_from_the_Standard
This commit keeps the default double at 32 bits but adds support for the
-mdouble flag (-mdouble=32 and -mdouble=64) to control this behavior.
Differential Revision: https://reviews.llvm.org/D76181
I believe the actual opcode does not matter because the AVR architecture
is a Harvard architecture that does not support writing to program
memory. Therefore, debuggers and emulators provide hardware breakpoints.
But for some reason, this opcode must be defined or else LLDB will crash
with an assertion error.
Differential Revision: https://reviews.llvm.org/D74255
With -fstack-protector-strong we check if a non-array variable has its address
taken in a way that could cause a potential out-of-bounds access. However what
we don't catch is when the address is directly used to create an out-of-bounds
memory access.
Fix this by examining the offsets of GEPs that are ultimately derived from
allocas and checking if the resulting address is out-of-bounds, and by checking
that any memory operations using such addresses are not over-large.
Fixes PR43478.
Differential revision: https://reviews.llvm.org/D75695
In the current SVE ACLE spec, the usual rules for throwing and
catching incomplete types also apply to sizeless types. However,
throwing pointers to sizeless types should not pose any real difficulty,
so as an extension, the clang implementation allows that.
This patch enforces these rules for catch statements.
Differential Revision: https://reviews.llvm.org/D76090
A memref argument is converted into a pointer-to-struct argument
of type `{T*, T*, i64, i64[N], i64[N]}*` in the wrapper function,
where T is the converted element type and N is the memref rank.
Differential Revision: https://reviews.llvm.org/D76059
Summary:
The same rules for throwing and catching incomplete types also apply
to sizeless types. This patch enforces that for throw statements.
It also make sure that we use "sizeless type" rather "incomplete type"
in the associated message. (Both are correct, but "sizeless type" is
more specific and hopefully more user-friendly.)
The SVE ACLE simply extends the rule for incomplete types to
sizeless types. However, throwing pointers to sizeless types
should not pose any real difficulty, so as an extension,
the clang implementation allows that.
Reviewers: sdesmalen, efriedma, rovka, rjmccall
Subscribers: tschuett, rkruppe, psnobl, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D76088
This was previously crashing due to a missing nullptr check (see
e2d8aa6bf7 ). This just adds a test that should
make sure this doesn't crash in case a user ends up in this strange setup.
In the current SVE ACLE spec, the usual rules for throwing and
catching incomplete types also apply to sizeless types. However,
throwing pointers to sizeless types should not pose any real difficulty,
so as an extension, the clang implementation allows that.
This patch enforces these rules for explicit exception specs.
Differential Revision: https://reviews.llvm.org/D76087
This patch completes a trio of changes related to arrays of
sizeless types. It rejects various forms of arithmetic on
pointers to sizeless types, in the same way as for other
incomplete types.
Differential Revision: https://reviews.llvm.org/D76086
clang currently accepts:
__SVInt8_t &foo1(__SVInt8_t *x) { return *x; }
__SVInt8_t &foo2(__SVInt8_t *x) { return x[1]; }
The first function is valid ACLE code and generates correct LLVM IR
(and assembly code). But the second function is invalid for the
same reason that arrays of sizeless types are. Trying to code-generate
the function leads to:
llvm/include/llvm/Support/TypeSize.h:126: uint64_t llvm::TypeSize::getFixedSize() const: Assertion `!IsScalable && "Request for a fixed size on a s
calable object"' failed.
Another problem is that:
template<typename T>
constexpr __SIZE_TYPE__ f(T *x) { return &x[1] - x; }
typedef int arr1[f((int *)0) - 1];
typedef int arr2[f((__SVInt8_t *)0) - 1];
produces:
a.cpp:2:48: warning: subtraction of pointers to type '__SVInt8_t' of zero size has undefined behavior [-Wpointer-arith]
constexpr __SIZE_TYPE__ f(T *x) { return &x[1] - x; }
~~~~~ ^ ~
a.cpp:4:18: note: in instantiation of function template specialization 'f<__SVInt8_t>' requested here
typedef int arr2[f((__SVInt8_t *)0) - 1];
This patch reports an appropriate diagnostic instead.
Differential Revision: https://reviews.llvm.org/D76084
This patch makes `Relocation::Addend` to be `ELFYAML::YAMLIntUInt` and not `int64_t`.
`ELFYAML::YAMLIntUInt` it is a new type and it has the following benefits/features:
1) For an 64-bit object any hex/decimal addends
in the range [INT64_MIN, UINT64_MAX] is accepted.
2) For an 32-bit object any hex/decimal addends
in range [INT32_MIN, UINT32_MAX] is accepted.
3) Negative hex numbers like -0xffffffff are not accepted.
4) It is printed as decimal. I.e. obj2yaml will print
something like "Addend: 125", this matches the current behavior.
This fixes all FIXMEs in `relocation-addend.yaml`.
Differential revision: https://reviews.llvm.org/D75527
Summary:
Adds the constraints described below to ensure that we
can tie variables of SVE ACLE types to operands in inline-asm:
- y: SVE registers Z0-Z7
- Upl: One of the low eight SVE predicate registers (P0-P7)
- Upa: Full range of SVE predicate registers (P0-P15)
Reviewers: sdesmalen, huntergr, rovka, cameron.mcinally, efriedma, rengolin
Reviewed By: efriedma
Subscribers: miyuki, tschuett, rkruppe, psnobl, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D75690
Summary:
Move them into MCTargetDesc to follow other architectures (a263aa2).
Reviewed By: simoll
Differential Revision: https://reviews.llvm.org/D76270
This test uses a precompiled object and duplicates
the functionality of a modern elf-no-symtab.yaml test that
uses yaml2obj for producing inputs.
Differential revision: https://reviews.llvm.org/D76217
This is a follow-up for D75608.
The `Offset` property is unused and can be removed to reduce tests.
This patch does nothing with `reloc-types-elf-i386.test` which has a different
structure and kind of tests the `Offset`. I think we might want to split it probably.
Differential revision: https://reviews.llvm.org/D76195
To group the code in one place, simplify it and make it easier to add
the containsErrors bit and find existing bugs.
Reviewers: sammccall
Reviewed By: sammccall
Tags: #clang
Differential Revision: https://reviews.llvm.org/D73638
According to LangRef:
If len is not a positive integer multiple of element_size, then the behaviour of the intrinsic is undefined.
Add InstCombine rule to transform intrinsic to undef operation.
This is a follow-up for D76116.
Reviewers: reames
Reviewed By: reames
Subscribers: hiraditya, jfb, dantrushin, llvm-commits
Differential Revision: https://reviews.llvm.org/D76215
Summary: This adds bitfields that map to the dialect attribute verifier hooks. This also moves over the Test dialect to have its declaration generated.
Differential Revision: https://reviews.llvm.org/D76254
Currently, when building with the Unix support library and `isatty` does
not exist for the target platform (i.e. `HAVE_ISATTY` is false),
compilation of the file `raw_ostream.cpp` will fail due to direct use of
`isatty` in the function `raw_fd_ostream::preferred_buffer_size()`.
Use is_displayed() to fix the problem.
Reviewed By: probinson, MaskRay
Differential Revision: https://reviews.llvm.org/D75278
This fails an assert because the type is marked in the calling
convention td file as needing promotion, but the code doesn't know
how to do it.
It also much more complicated because we try to pass these in
xmm/ymm/zmm registers. As of a few weeks ago we do this promotion
from getRegisterTypeForCallingConv before the td file generated
code gets involved.
Summary: PatternState was a mechanism to pass state between the match and rewrite calls of a RewritePattern. With the rise of matchAndRewrite, this class is unused and unnecessary. This revision removes PatternState and simplifies PatternMatchResult to just be a LogicalResult. A future revision will replace all usages of PatternMatchResult/matchSuccess/matchFailure with LogicalResult equivalents.
Differential Revision: https://reviews.llvm.org/D76202
Alexey Bataev