This commit teaches clang that is has to emit a warning when NULL is passed
as the 'expected' pointer parameter into an atomic compare exchange call.
rdar://18926650
Differential Revision: https://reviews.llvm.org/D26978
llvm-svn: 287776
Summary:
This is a simple sema check patch for arguments of `__builtin_arm_rsr` and the related builtins, which currently do not allow special registers with indexes >7.
Some of the possible register name formats these builtins accept are:
```
{c}p<coprocessor>:<op1>:c<CRn>:c<CRm>:<op2>
```
```
o0:op1:CRn:CRm:op2
```
where `op1` / `op2` are integers in the range [0, 7] and `CRn` / `CRm` are integers in the range [0, 15].
The current sema check does not allow `CRn` > 7 and accepts `op2` up to 15.
Reviewers: LukeCheeseman, rengolin
Subscribers: asl, aemerson, rengolin, cfe-commits
Differential Revision: https://reviews.llvm.org/D26464
llvm-svn: 287378
ExpectedFunctionGlobalVarMethodOrProperty
would previously say "functions and global variables"
instead of "functions, methods, properties, and global variables"
The newly added ExpectedFunctionOrGlobalVariable
says "functions and global variables"
Differential Revision: https://reviews.llvm.org/D26459
llvm-svn: 286599
Since array parameters decay to pointers, '_Nullable' and friends
should be available for use there as well. This is especially
important for parameters that are typedefs of arrays. The unsugared
syntax for this follows the syntax for 'static'-sized arrays in C:
void test(int values[_Nullable]);
This syntax was previously accepted but the '_Nullable' (and any other
attributes) were silently discarded. However, applying '_Nullable' to
a typedef was previously rejected and is now accepted; therefore, it
may be necessary to test for the presence of this feature:
#if __has_feature(nullability_on_arrays)
One important change here is that DecayedTypes don't always
immediately contain PointerTypes anymore; they may contain an
AttributedType instead. This only affected one place in-tree, so I
would guess it's not likely to cause problems elsewhere.
This commit does not change -Wnullability-completeness just yet. I
want to think about whether it's worth doing something special to
avoid breaking existing clients that compile with -Werror. It also
doesn't change '#pragma clang assume_nonnull' behavior, which
currently treats the following two declarations as equivalent:
#pragma clang assume_nonnull begin
void test(void *pointers[]);
#pragma clang assume_nonnull end
void test(void * _Nonnull pointers[]);
This is not the desired behavior, but changing it would break
backwards-compatibility. Most likely the best answer is going to be
adding a new warning.
Part of rdar://problem/25846421
llvm-svn: 286519
the body of a function for the purposes of computing its storage
duration and deciding whether its initializer must be constant.
There are a number of problems in our current treatment of compound
literals. C specifies that a compound literal yields an l-value
referring to an object with either static or automatic storage
duration, depending on where it was written; in the latter case,
the literal object has a lifetime tied to the enclosing scope (much
like an ObjC block), not the enclosing full-expression. To get these
semantics fully correct in our current design, we would need to
collect compound literals on the ExprWithCleanups, just like we do
with ObjC blocks; we would probably also want to identify literals
like we do with materialized temporaries. But it gets stranger;
GCC adds compound literals to C++ as an extension, but makes them
r-values, which are generally assumed to have temporary storage
duration. Ignoring destructor ordering, the difference only matters
if the object's address escapes the full-expression, which for an
r-value can only happen with reference binding (which extends
temporaries) or array-to-pointer decay (which does not). GCC then
attempts to lock down on array-to-pointer decay in ad hoc ways.
Arguably a far superior language solution for C++ (and perhaps even
array r-values in C, which can occur in other ways) would be to
propagate lifetime extension through array-to-pointer decay, so
that initializing a pointer object to a decayed r-value array
extends the lifetime of the complete object containing the array.
But this would be a major change in semantics which arguably ought
to be blessed by the committee(s).
Anyway, I'm not fixing any of that in this patch; I did try, but
it got out of hand.
Fixes rdar://28949016.
llvm-svn: 285643
The second argument to __builtin_alloca_with_align is supposed to be in
bits, not bytes. Using alignof there would be indicative of a bug.
llvm-svn: 285609
__builtin_alloca always uses __BIGGEST_ALIGNMENT__ for the alignment of
the allocation. __builtin_alloca_with_align allows the programmer to
specify the alignment of the allocation.
This fixes PR30658.
llvm-svn: 285544
If we pass a header to libclang, e.g. because it's open in an editor in
an IDE, warnings about unused const vars are not useful: other files
that include the header might use those constants. So when -x *-header
is passed as command-line option, suppress this warning.
llvm-svn: 285386
Warnings generated by -Wdocumentation-unknown-command did only have a
start location, not a full source range. This resulted in only the
"carret" being show in messages, and IDEs highlighting only the single
initial character.
llvm-svn: 285056
Gcc prints error if elements of left and right parts of a shift have different
sizes. This patch is provided the GCC compatibility.
Patch by Vladimir Yakovlev.
Differential Revision: https://reviews.llvm.org/D24669
llvm-svn: 284579
swift_error/swift_context parameter
We need to be able to decelare witness functions which append the self type and
the self witness tables at the end of the parameter list.
rdar://28720996
llvm-svn: 283933
This commit fixes a crash that happens when clang is analyzing a
transparent_union attribute on a union which has a field with incomplete type.
rdar://28630028
Differential Revision: https://reviews.llvm.org/D25273
llvm-svn: 283432
This commit improves the packed member warning by showing the name of the
anonymous structure/union when it was defined within a typedef declaration.
rdar://28498901
Differential Revision: https://reviews.llvm.org/D25106
llvm-svn: 283304
Summary: We need x86-64-specific builtins if we want to implement some of the MS intrinsics - winnt.h contains definitions of some functions for i386, but not for x86-64 (for example _InterlockedOr64), which means that we cannot treat them as builtins for both i386 and x86-64, because then we have definitions of builtin functions in winnt.h on i386.
Reviewers: thakis, majnemer, hans, rnk
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24598
llvm-svn: 283264
Support lax convertions on compound assignment expressions like:
typedef __attribute__((vector_size(8))) double float64x1_t;
typedef __attribute__((vector_size(16))) double float64x2_t;
float64x1_t vget_low_f64(float64x2_t __p0);
double c = 3.0;
float64x2_t v = {0.0, 1.0};
c += vget_low_f64(v);
This restores one more valid behavior pre r266366, and is a incremental
follow up from work committed in r274646.
While here, make the check more strict, add FIXMEs, clean up variable
names to match what they can actually be and update testcases to reflect
that. We now reject:
typedef float float2 __attribute__ ((vector_size (8)));
double d;
f2 += d;
which doesn't fit as a direct bitcast anyway.
Differential Revision: https://reviews.llvm.org/D24472
rdar://problem/28033929
llvm-svn: 282968
The backend can't encode all possible values of the argument and will fail isel. Checking in the frontend presents a friendlier experience to the user.
I started with builtins that can only take _MM_CUR_DIRECTION or _MM_NO_EXC. More builtins coming in the future.
llvm-svn: 282228
Summary:
The diagnostic did not handle ~ well. An expression such as ~0 is often used when 'all ones' is needed.
Differential Revision: https://reviews.llvm.org/D24232
llvm-svn: 282156
Summary:
The warning for a format string not being a string literal and therefore
being potentially insecure is overly strict for indices into string
literals. This fix checks if the index into the string literal is
precomputable. If that's the case it will check if the suffix of that
string literal is a valid format string string literal. It will still
issue the aforementioned warning for out of range indices into the
string literal.
Patch by Meike Baumgärtner (meikeb)
Reviewers: rsmith
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D24584
llvm-svn: 281686
r278501 inadvertently introduced a bug in which it disallowed shifting
scalar operands by vector operands when not compiling for OpenCL. This
commit fixes it.
Patch by Vladimir Yakovlev.
Differential Revision: https://reviews.llvm.org/D24467
llvm-svn: 281669
The underlying type for an enumeration in C is either char, signed int, or unsigned int. In the case the underlying type is chosen to be char (such as when passing -fshort-enums or using __attribute__((packed)) on the enum declaration), the enumeration can result in undefined behavior. However, when the underlying type is signed int or unsigned int (or long long as an extension), there is no undefined behavior because the types are compatible. This patch silences diagnostics for the latter while retaining the diagnostics for the former.
This patch addresses PR29140.
llvm-svn: 281632
The ARM-specific C attributes (currently just interrupt) need to check
for both the big- and little-endian versions of the triples, so that
they are accepted for both big and little endian targets.
TargetWindows and TargetMicrosoftCXXABI also only use the little-endian
triples, but this is correct as windows is not supported on big-endian
ARM targets (and this is asserted in lib/Basic/Targets.cpp).
Differential Revision: https://reviews.llvm.org/D24245
llvm-svn: 281596
Summary: This reverts r281527 because I messed up the attribution.
Reviewers: srhines
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D24579
llvm-svn: 281530
Summary:
The warning for a format string not being a sting literal and therefore
being potentially insecure is overly strict for indecies into sting
literals. This fix checks if the index into the string literal is
precomputable. If thats the case it will check if the suffix of that
sting literal is a valid format string string literal. It will still
issue the aforementioned warning for out of range indecies into the
string literal.
Reviewers: rsmith
Subscribers: srhines, cfe-commits
Differential Revision: https://reviews.llvm.org/D23820
llvm-svn: 281527
Some Windows SDK classes, for example
Windows::Storage::Streams::IBufferByteAccess, use the ATL way of spelling
attributes:
[uuid("....")] class IBufferByteAccess {};
To be able to use __uuidof() to grab the uuid off these types, clang needs to
support uuid as a Microsoft attribute. There was already code to skip Microsoft
attributes, extend that to look for uuid and parse it. Use the new "Microsoft"
attribute type added in r280575 (and r280574, r280576) for this.
Final part of https://reviews.llvm.org/D23895
llvm-svn: 280578
This patch allows us to perform incompatible pointer conversions when
resolving overloads in C. So, the following code will no longer fail to
compile (though it will still emit warnings, assuming the user hasn't
opted out of them):
```
void foo(char *) __attribute__((overloadable));
void foo(int) __attribute__((overloadable));
void callFoo() {
unsigned char bar[128];
foo(bar); // selects the char* overload.
}
```
These conversions are ranked below all others, so:
A. Any other viable conversion will win out
B. If we had another incompatible pointer conversion in the example
above (e.g. `void foo(int *)`), we would complain about
an ambiguity.
Differential Revision: https://reviews.llvm.org/D24113
llvm-svn: 280553
Emit proper diagnostics when -Wdocumentation is used with constructs such as:
template<typename T>
using fn = int(T aaa, int ccc);
Previously clang wouldn't recognize the function and complain with
'comment that is not attached to a function declaration'.
Differential Revision: https://reviews.llvm.org/D23860
rdar://problem/27300695
llvm-svn: 279754
Give appropriate warnings with -Wdocumentation for @param comments
that refer to function aliases defined with 'using'. Very similar
to typedef's behavior. This does not add support for
TypeAliasTemplateDecl yet.
Differential Revision: https://reviews.llvm.org/D23783
rdar://problem/27300695
llvm-svn: 279662
This is valid in GNU C, which allows pointers to incomplete enums. GCC
just pretends that the underlying type is 'int' in those cases, follow
that behavior.
llvm-svn: 279374
In C, 'extern' is typically used to avoid tentative definitions when
declaring variables in headers, but adding an intializer makes it a
defintion. This is somewhat confusing, so GCC and Clang both warn on it.
In C++, 'extern' is often used to give implictly static 'const'
variables external linkage, so don't warn in that case. If selectany is
present, this might be header code intended for C and C++ inclusion, so
apply the C++ rules.
llvm-svn: 279116
This commit adds a traversal of the AST after Sema of a function that diagnoses
unguarded references to declarations that are partially available (based on
availability attributes). This traversal is only done when we would otherwise
emit -Wpartial-availability.
This commit is part of a feature I proposed here:
http://lists.llvm.org/pipermail/cfe-dev/2016-July/049851.html
Differential revision: https://reviews.llvm.org/D23003
llvm-svn: 278826
This fixes an error in type checking of shift of vector values.
Patch by Vladimir Yakovlev.
Differential Revision: https://reviews.llvm.org/D21678
llvm-svn: 278501
Currently, when trying to evaluate an enable_if condition, we try to
evaluate all arguments a user passes to a function. Given that we can't
use variadic arguments from said condition anyway, not converting them
is a reasonable thing to do. So, this patch makes us ignore any varargs
when attempting to check an enable_if condition.
We'd crash because, in order to convert an argument, we need its
ParmVarDecl. Variadic arguments don't have ParmVarDecls.
llvm-svn: 278471
Summary:
Based on a patch by Michael Mueller.
This attribute specifies that a function can be hooked or patched. This
mechanism was originally devised by Microsoft for hotpatching their
binaries (which they're constantly updating to stay ahead of crackers,
script kiddies, and other ne'er-do-wells on the Internet), but it's now
commonly abused by Windows programs that want to hook API functions. It
is for this reason that this attribute was added to GCC--hence the name,
`ms_hook_prologue`.
Depends on D19908.
Reviewers: rnk, aaron.ballman
Subscribers: cfe-commits
Differential Revision: https://reviews.llvm.org/D19909
llvm-svn: 278050
Silence the -Wbitfield-constant-conversion warning for when -1 or other
negative values are assigned to unsigned bitfields, provided that the bitfield
is wider than the minimum number of bits needed to encode the negative value.
llvm-svn: 277796
Summary:
This patch enables .rgba accessors to ext_vector_type types and adds
tests for syntax validation and code generation.
'a' and 'b' can appear either in the point access mode or the numeric
access mode (for indices 10 and 11). To disambiguate between the two
usages, the accessor type is explicitly passed to relevant methods.
Reviewers: rsmith
Subscribers: Anastasia, bader, srhines, cfe-commits
Differential Revision: http://reviews.llvm.org/D20602
llvm-svn: 276455
rewriteBuiltinFunctionDecl can encounter errors when performing
DefaultFunctionArrayLvalueConversion. These errors were not handled
which led to a null pointer dereference.
This fixes PR28651.
llvm-svn: 276352
nullabilities of its operands.
This patch defines a function to compute the nullability of conditional
expressions, which enables Sema to precisely detect implicit conversions
of nullable conditional expressions to nonnull pointers.
rdar://problem/25166556
Differential Revision: https://reviews.llvm.org/D22392
llvm-svn: 276076
Give incompatible function pointer warning its own diagnostic group
but still leave it as a subgroup of incompatible-pointer-types. This is in
preparation to promote -Wincompatible-function-pointer-types to error on
darwin.
Differential Revision: https://reviews.llvm.org/D22248
rdar://problem/12907612
llvm-svn: 275907
Extend the __declspec(dll*) attribute to cover ObjC interfaces. This was
requested by Microsoft for their ObjC support. Cover both import and export.
This only adds the semantic analysis portion of the support, code-generation
still remains outstanding. Add some basic initial documentation on the
attributes that were previously empty. Tweak the previous tests to use the
relative expected-warnings to make the tests easier to read.
llvm-svn: 275610
This patch implements PR#22821.
Taking the address of a packed member is dangerous since the reduced
alignment of the pointee is lost. This can lead to memory alignment
faults in some architectures if the pointer value is dereferenced.
This change adds a new warning to clang emitted when taking the address
of a packed member. A packed member is either a field/data member
declared as attribute((packed)) or belonging to a struct/class
declared as such. The associated flag is -Waddress-of-packed-member.
Conversions (either implicit or via a valid casting) to pointer types
with lower or equal alignment requirements (e.g. void* or char*)
silence the warning.
This change also adds a new error diagnostic when the user attempts to
bind a reference to a packed member, regardless of the alignment.
Differential Revision: https://reviews.llvm.org/D20561
llvm-svn: 275417
-fxray-instrument: enables XRay annotation of IR
-fxray-instruction-threshold: configures the threshold for function size (looking at IR instructions), and allow LLVM to decide whether to add the nop sleds later on in the process.
Also implements the related xray_always_instrument and xray_never_instrument function attributes.
Patch by Dean Michael Berris.
llvm-svn: 275330
Before r266366, clang used to support constructs like:
typedef __attribute__((vector_size(8))) double float64x1_t;
typedef __attribute__((vector_size(16))) double float64x2_t;
float64x1_t vget_low_f64(float64x2_t __p0);
double y = 3.0 + vget_low_f64(v);
But it would reject:
double y = vget_low_f64(v) + 3.0;
It also always rejected assignments:
double y = vget_low_f64(v);
This patch: (a) revivies the behavior of `3.0 + vget_low_f64(v)` prior to
r266366, (b) add support for `vget_low_f64(v) + 3.0` and (c) add support for
assignments.
These vector semantics have never really been tied up but it seems
odd that we used to support some binop froms but do not support
assignment. If we did support scalar for the purposes of arithmetic, we
should probably be able to reinterpret as scalar for the purposes of
assignment too.
Differential Revision: http://reviews.llvm.org/D21700
rdar://problem/26093791
llvm-svn: 274646
We continue accepting "macosx" but canonicalize it to "macos", When emitting
diagnostics, we use "macOS" instead of "OS X".
The PlatformName in TargetInfo is changed from "macosx" to "macos" so we can
directly compare the Platform in AvailabilityAttr with the PlatformName
in TargetInfo.
rdar://26795172
rdar://26800775
llvm-svn: 274064
This fixes a crash in code like:
```
struct A {
struct B b;
char c[1];
}
int foo(struct A* a) { return __builtin_object_size(a->c, 0); }
```
We wouldn't check whether the structs we were examining were invalid,
and getting the layout of an invalid struct is (unsurprisingly) A Bad
Thing. With this patch, we'll always return conservatively if we see an
invalid struct, since I'm assuming the presence of an invalid struct
means that our compilation failed (so having a conservative result isn't
such a big deal).
llvm-svn: 273911
Reapplying patch in r272777 which was reverted
because the llvm patch which added support
for generating the mcrr/mcrr2 instructions
from the intrinsic was causing an assertion
failure. This has now been fixed in llvm.
llvm-svn: 272983
Parameters and non-static members of aggregates are still excluded,
and probably should remain that way.
Differential Revision: http://reviews.llvm.org/D19754
llvm-svn: 272859
Patch adds intrinsics for mrrc/mrrc2. The
intrinsics for mrrc/mrrc2 return a single
uint64_t to represent two 32 bit values.
The mcrr/mcrr2 intrinsic was changed to
accept a single uint64_t instead of two
32 bit values as the input for consistency.
Differential Revision: http://reviews.llvm.org/D21179
llvm-svn: 272777
ActOnBinOp corrects delayed typos when in C mode; don't correct them in that
case. Fixes PR26700.
Differential Revision: http://reviews.llvm.org/D20490
llvm-svn: 272587
This patch implements PR#22821.
Taking the address of a packed member is dangerous since the reduced
alignment of the pointee is lost. This can lead to memory alignment
faults in some architectures if the pointer value is dereferenced.
This change adds a new warning to clang emitted when taking the address
of a packed member. A packed member is either a field/data member
declared as attribute((packed)) or belonging to a struct/class
declared as such. The associated flag is -Waddress-of-packed-member
Differential Revision: http://reviews.llvm.org/D20561
llvm-svn: 272552
Summary:
Create a new Frontend LangOpt to specify the renderscript language. It
is enabled by the "-x renderscript" option from the driver.
Add a "kernel" function attribute only for RenderScript (an "ignored
attribute" warning is generated otherwise).
Make the NativeHalfType and NativeHalfArgsAndReturns LangOpts be implied
by the RenderScript LangOpt.
Reviewers: rsmith
Subscribers: cfe-commits, srhines
Differential Revision: http://reviews.llvm.org/D21198
llvm-svn: 272342
This implements support for MS-specific __unaligned qualifier in functions and
makes the following test case both compile and mangle correctly:
struct S {
void f() __unaligned;
};
void S::f() __unaligned {
}
Differential Revision: http://reviews.llvm.org/D20437
llvm-svn: 270834
If we have some function with dllimport attribute and then we have the function
definition in the same module but without dllimport attribute we should add
dllexport attribute to this function definition.
The same should be done for variables.
Example:
struct __declspec(dllimport) C3 {
~C3();
};
C3::~C3() {;} // we should export this definition.
Patch by Andrew V. Tischenko
Differential revision: http://reviews.llvm.org/D18953
llvm-svn: 270686
- Fixed cdp intrinsic to only accept compile time
constant values previously you could pass in a
variable to the builtin which would result in
illegal llvm assembly output
Differential Revision: http://reviews.llvm.org/D20394
llvm-svn: 270058
licensees actually see in the toolchain we deliver to them. This will
reduce the set of local patches we have to maintain. The triple is
not changing. (The term ORBIS is an internal code name for PS4.)
llvm-svn: 269671
This patch implements __unaligned (MS extension) as a proper type qualifier
(before that, it was implemented as an ignored attribute).
It also fixes PR27367 and PR27666.
Differential Revision: http://reviews.llvm.org/D20103
llvm-svn: 269220
Summary:
This only warns on casts of the address of a function defined in the
current TU. In this case, the fix is likely to be local and the warning
useful.
Here are some things we could experiment with in the future:
- Fire on declarations as well as definitions
- Limit the warning to non-void function prototypes
- Limit the warning to mismatches of caller and callee cleanup CCs
This warning is currently off by default while we study its usefulness.
Reviewers: thakis, rtrieu
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D17348
llvm-svn: 269116
This patch corresponds to reviews:
http://reviews.llvm.org/D15120http://reviews.llvm.org/D19125
It adds support for the __float128 keyword, literals and target feature to
enable it. Based on the latter of the two aforementioned reviews, this feature
is enabled on Linux on i386/X86 as well as SystemZ.
This is also the second attempt in commiting this feature. The first attempt
did not enable it on required platforms which caused failures when compiling
type_traits with -std=gnu++11.
If you see failures with compiling this header on your platform after this
commit, it is likely that your platform needs to have this feature enabled.
llvm-svn: 268898
When inferring availability attributes for tvos, watchos from ios, we
use the same source location and set the implicit bit to true.
So when emitting diagnostics on inferred attributes, we have a source
location.
rdar://25893544
llvm-svn: 268793
Sometimes, the declaration we found has inherited availability
attributes, attaching the note to it does not tell us where the
availability attributes are in the source.
Go through the redecl chain to find the declaration with actual
availability attributes.
rdar://25221771
llvm-svn: 268786
This patch implements __unaligned (MS extension) as a proper type qualifier
(before that, it was implemented as an ignored attribute).
It also fixes PR27367.
Differential Revision: http://reviews.llvm.org/D19654
llvm-svn: 268727
This patch adds coverage for additional cases where implicit conversion can
occur (assignment and return). It also adds tests for some cases where a
warning should occur but none is produced. These are marked as FIXME.
Differential Revision: http://reviews.llvm.org/D16298
llvm-svn: 268075
The 'nodebug' attribute had hand-coded constraints; replace those with
a Subjects line in Attr.td.
Also add a missing test to verify the attribute is okay on an
Objective-C method.
Differential Revision: http://reviews.llvm.org/D19689
llvm-svn: 268065
Summary:
Conversions between float and half are only available when the
taraget has the half-precision extension. Guard these intrinsics
so that they don't cause crashes in the backend.
Fixes PR27550.
Reviewers: rengolin, t.p.northover
Subscribers: cfe-commits, aemerson, t.p.northover, rengolin
Differential Revision: http://reviews.llvm.org/D19665
llvm-svn: 268047
Summary:
According to the ACLE spec, "__ARM_FEATURE_FMA is defined to 1 if
the hardware floating-point architecture supports fused floating-point
multiply-accumulate".
This changes clang's behaviour from emitting this macro for v7-A and v7-R
cores to only emitting it when the target has VFPv4 (and therefore support
for the floating point multiply-accumulate instruction).
Fixes PR27216
Reviewers: t.p.northover, rengolin
Subscribers: aemerson, rengolin, cfe-commits
Differential Revision: http://reviews.llvm.org/D18963
llvm-svn: 267869
Since this patch provided support for the __float128 type but disabled it
on all platforms by default, some platforms can't compile type_traits with
-std=gnu++11 since there is a specialization with __float128.
This reverts the patch until D19125 is approved (i.e. we know which platforms
need this support enabled).
llvm-svn: 266460
This patch implements __unaligned as a type qualifier; before that, it was
modeled as an attribute. Proper mangling of __unaligned is implemented as well.
Some OpenCL code/tests are tangenially affected, as they relied on existing
number and sizes of type qualifiers.
Differential Revision: http://reviews.llvm.org/D18596
llvm-svn: 266415
Although all the registers are actually 32-bits, I think we have to assume the
high 32-bits could be RES0 (the ARM ARM is unclear). If so, reading as a 32-bit
register can require extra zero extension operations.
llvm-svn: 266212
This patch corresponds to review:
http://reviews.llvm.org/D15120
It adds support for the __float128 keyword, literals and a target feature to
enable it. This support is disabled by default on all targets and any target
that has support for this type is free to add it.
Based on feedback that I've received from target maintainers, this appears to
be the right thing for most targets. I have not heard from the maintainers of
X86 which I believe supports this type. I will subsequently investigate the
impact of enabling this on X86.
llvm-svn: 266186
Add a triple to the run lines so that integers will the same sizes across runs.
Also add a compile time check to ensure the assumptions about sizes are met.
llvm-svn: 265991
This patch add support for GCC attribute((ifunc("resolver"))) for
targets that use ELF as object file format. In general ifunc is a
special kind of function alias with type @gnu_indirect_function. LLVM
patch http://reviews.llvm.org/D15525
Differential Revision: http://reviews.llvm.org/D15524
llvm-svn: 265917
In some cases, when we encounter a direct function call with an
incorrect number of arguments, we'll emit a diagnostic, and pretend that
the call to the function was valid. For example, in C:
int foo();
int a = foo(1);
Prior to this patch, we'd get an ICE if foo had an enable_if attribute,
because CheckEnableIf assumes that the number of arguments it gets
passed is valid for the function it's passed. Now, we check that the
number of args looks valid prior to checking enable_if conditions.
This fix was not done inside of CheckEnableIf because the problem
presently can only occur in one caller of CheckEnableIf (ActOnCallExpr).
Additionally, checking inside of CheckEnableIf would make us emit
multiple diagnostics for the same error (one "enable_if failed", one
"you gave this function the wrong number of arguments"), which seems
worse than just complaining about the latter.
llvm-svn: 264975
Summary:
__atomic_load's allows it's first argument to be a pointer to a const type. However the second argument is an output parameter and must be a pointer to non-const.
This patch fixes the signature of __atomic_load generated by clang so that it respects the above requirements.
Reviewers: rsmith, majnemer
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D13420
llvm-svn: 264967
Also includes a minor ``enable_if`` docs update.
Currently, our address-of overload machinery will only allow implicit
conversions of overloaded functions to void* in C. For example:
```
void f(int) __attribute__((overloadable));
void f(double) __attribute__((overloadable, enable_if(0, "")));
void *fp = f; // OK. This is C and the target is void*.
void (*fp2)(void) = f; // Error. This is C, but the target isn't void*.
```
This patch makes the assignment of `fp2` select the `f(int)` overload,
rather than emitting an error (N.B. you'll still get a warning about the
`fp2` assignment if you use -Wincompatible-pointer-types).
Differential Revision: http://reviews.llvm.org/D13704
llvm-svn: 264132
clang -cc1 -ast-print put the struct
definition in the wrong place, like this:
struct {} typedef S;
The reason that this happens is that the printing code
first prints the struct definition, and then tells the next
declaration to leave out the type. This behavior
is correct for simple variable declarations, but fails for
typedefs (or extern, mutable, etc).
The patch address this problem by skipping the struct
declaration when we first see it, and then telling the first
subsequent declaration that it needs to print out the full
struct definition.
Differential Revision: http://reviews.llvm.org/D17285
llvm-svn: 263836
Till now, preserve_mostcc/preserve_allcc calling convention attributes were only
available at the LLVM IR level. This patch adds attributes for
preserve_mostcc/preserve_allcc calling conventions to the C/C++ front-end.
The code was mostly written by Juergen Ributzka.
I just added support for the AArch64 target and tests.
Differential Revision: http://reviews.llvm.org/D18025
llvm-svn: 263647
r263299 added a fixit for the -Wformat-security warning, but that runs
into complications with our guideline that error recovery should be done
as-if the fixit had been applied. Putting the fixit on a note avoids that.
llvm-svn: 263584
This is a follow-up to r261512, which made the 'strict' availability
attribute flag behave like 'unavailable'. However, that fix was
insufficient. The following case would (erroneously) error when the
deployment target was older than 10.9:
struct __attribute__((availability(macosx,strict,introduced=10.9))) A;
__attribute__((availability(macosx,strict,introduced=10.9))) void f(A*);
The use of A* in the argument list for f is valid here, since f and A
have the same availability.
The fix is to return AR_Unavailable from DeclBase::getAvailability
instead of AR_NotYetIntroduced. This also reverts the special handling
added in r261163, instead relying on the well-tested logic for
AR_Unavailable.
rdar://problem/23791325
llvm-svn: 262915
Sema allows max values up to 2**28, use unsigned instead of unsiged
short to hold values that large.
Differential Revision: http://reviews.llvm.org/D17248
Patch by Don Hinton!
llvm-svn: 262466
Summary:
The printf/scanf format checker is a little over-zealous in handling the conditional operator. This patch reduces work by not checking code-paths that are never used and reduces false positives regarding uncovered arguments, for example in the code fragment:
printf(minimal ? "%i\n" : "%i: %s\n", code, msg);
Reviewers: rtrieu
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D15636
llvm-svn: 262025
Use "strict" instead of "nopartial". Also make strictly not-introduced
share the same diagnostics as Obsolete and Unavailable.
rdar://23791325
llvm-svn: 261512
"aligned", by Vladimir Yakovlev
Fix clang/gcc incompatibility of bitfields layout in the presence of
pragma packed and attributes aligned and packed.
Differential Revision: http://reviews.llvm.org/D17023
llvm-svn: 261321
Clang implements an enable_if attribute as an extension. Hook up `-Wpedantic`
to issue an extension usage warning when __enable_if__ is used.
llvm-svn: 261192
An optional nopartial can be placed after the platform name.
int bar() __attribute__((availability(macosx,nopartial,introduced=10.12))
When deploying back to a platform version prior to when the declaration was
introduced, with 'nopartial', Clang emits an error specifying that the function
is not introduced yet; without 'nopartial', the behavior stays the same: the
declaration is `weakly linked`.
A member is added to the end of AttributeList to save the location of the
'nopartial' keyword. A bool member is added to AvailabilityAttr.
The diagnostics for 'nopartial' not-yet-introduced is handled in the same way as
we handle unavailable cases.
Reviewed by Doug Gregor and Jordan Rose.
rdar://23791325
llvm-svn: 261163
In my previous commit (rL260881) I forget to svn add tests. This commit adds
them.
Differential Revision: http://reviews.llvm.org/D16846
llvm-svn: 260882
This patch is to upgrade FunctionTypeUnwrapper for correct processing of
AttributedType. Fixes PR25786.
Patch by Alexander Makarov.
Differential Revision: http://reviews.llvm.org/D15373
llvm-svn: 260373
r257357 fixed clang to warn on integer overflow in struct initializers.
However, it didn't warn when a struct had a nested initializer. This
commit makes changes in Sema::CheckForIntOverflow to handle nested
initializers.
For example:
struct s {
struct t {
unsigned x;
} t;
} s = {
{
.x = 4 * 1024 * 1024 * 1024
}
};
rdar://problem/23526454
llvm-svn: 260360
Sometimes, char arrays are used as bit storage, with no difference made between
signed and unsigned char. Thus, it is reasonable to use 0 to 255 instead of
-128 to 127 and not trigger this warning.
llvm-svn: 259947
Defined the new AVX512 registers in clang inline asm.
Fixed a bug in the MC subtarget info creation during the parsing of MS asm statement - now it receives the actual CPU and target features information.
Differential Revision: http://reviews.llvm.org/D16757
llvm-svn: 259639
The main purpose here is that vfma/vfms should be symmetric, and they are
supported on most v7 cores.
The new ArchGuard is suggested by ACLE but prophylactic for us. Almost all CPUs
with NEON *will* have vfma, and the few exceptions I know of (e.g. Cortex-A8)
are incorrectly modelled by Clang so can't trigger a test.
Fortunately, they're getting rarer. But if we ever do support them properly
arm_neon.h should now do the right thing.
llvm-svn: 259537
Allow "mode" attribute for enum types, except for vector modes, for compatibility with GCC.
Support "mode" attribute with dependent types.
Differential Revision: http://reviews.llvm.org/D16219
llvm-svn: 259497
Richard Smith