"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
Patch by H.J. Lu
```
typedef unsigned int gcc_word __attribute__((mode(word)));
```
and
```
typedef unsigned int gcc_unwind_word __attribute__((mode(unwind_word)));
```
define the largest unsigned integer types which can be stored in a
general purpose register, which may not be the pointer type. For x32,
they aren't pointer nor unsigned long. We should
1. Make getUnwindWordWidth and getRegisterWidth virtual,
2. Override them for x32, similar to hasInt128Type.
3. Use getRegisterWidth for __attribute__((mode(word)));
This fixes PR 24706.
Reviewers: rnk
Differential Revision: http://reviews.llvm.org/D16779
llvm-svn: 259383
Switch the evaluation from isIntegerConstantExpr to EvaluateAsInt.
EvaluateAsInt will evaluate more types of expressions than
isIntegerConstantExpr.
Move one case from -Wsign-conversion to -Wconstant-conversion. The case is:
1) Source and target types are signed
2) Source type is wider than the target type
3) The source constant value is positive
4) The conversion will store the value as negative in the target.
llvm-svn: 259271
In OpenCL, `bool` vectors are a reserved type, and are therefore
illegal.
Outside of OpenCL, if we try to make an extended vector of N `bool`s,
Clang will lower it to an `[N x i1]`. LLVM has no ABI for bitvectors, so
lots of operations on such vectors are thoroughly broken. As a result,
this patch makes them illegal in everything else, as well. :)
Differential Revision: http://reviews.llvm.org/D15721
llvm-svn: 259011
Tag and specifier printing can be suppressed in Decl::printGroup, but these suppressions leak into the initializers. Thus
int *x = ((void *)0), *y = ((void *)0);
gets printed as
int *x = ((void *)0), *y = ((*)0);
And
struct { struct Z z; } z = {(struct Z){}};
gets printed as
struct { struct Z z; } z = {(){}};
The stops the suppressions from leaking into the initializers.
Patch by Nick Sumner!
Differential Revision: http://reviews.llvm.org/D16438
llvm-svn: 258679
Allow "mode" attribute to be applied to VarDecl, not ValueDecl (which includes FunctionDecl and EnumConstantDecl), emit an error if this attribute is used with function declarations and enum constants.
Differential Revision: http://reviews.llvm.org/D16112
llvm-svn: 257868
This attribute may be attached to a function definition and instructs the backend to generate appropriate function entry/exit code so that
it can be used directly as an interrupt handler.
The IRET instruction, instead of the RET instruction, is used to return from interrupt or exception handlers. All registers, except for the EFLAGS register which is restored by the IRET instruction, are preserved by the compiler.
Any interruptible-without-stack-switch code must be compiled with -mno-red-zone since interrupt handlers can and will, because of the hardware design, touch
the red zone.
interrupt handler must be declared with a mandatory pointer argument:
struct interrupt_frame;
__attribute__ ((interrupt))
void f (struct interrupt_frame *frame) {
...
}
and user must properly define the structure the pointer pointing to.
exception handler:
The exception handler is very similar to the interrupt handler with a different mandatory function signature:
#ifdef __x86_64__
typedef unsigned long long int uword_t;
#else
typedef unsigned int uword_t;
#endif
struct interrupt_frame;
__attribute__ ((interrupt))
void f (struct interrupt_frame *frame, uword_t error_code) {
...
}
and compiler pops the error code off stack before the IRET instruction.
The exception handler should only be used for exceptions which push an error code and all other exceptions must use the interrupt handler.
The system will crash if the wrong handler is used.
Differential Revision: http://reviews.llvm.org/D15709
llvm-svn: 257867
redeclares an existing tag but are creating a new declaration anyway (because
it has attributes or changes the visibility of the name), don't warn that it
won't be visible outside the current scope. That's not true.
Also narrow down the set of cases where we create these extra declarations when
building modules; previously, all tag declarations but the first in a module
header would get this treatment if -fmodules-local-submodule-visibility. (This
isn't a functional change, but we try to avoid creating these extra
declarations whenever we can.)
llvm-svn: 257403
Given an expression like `(&Foo)();`, we perform overload resolution as
if we are calling `Foo` directly. This causes problems if `Foo` is a
function that can't have its address taken. This patch teaches overload
resolution to ignore functions that can't have their address taken in
such cases.
Differential Revision: http://reviews.llvm.org/D15590
llvm-svn: 257016
Summary:
There are a number of files in the tree which have been accidentally checked in with DOS line endings. Convert these to native line endings.
There are also a few files which have DOS line endings on purpose, and I have set the svn:eol-style property to 'CRLF' on those.
Reviewers: joerg, aaron.ballman
Subscribers: aaron.ballman, cfe-commits
Differential Revision: http://reviews.llvm.org/D15849
llvm-svn: 256704
If there are two pointers passed to an atomic Builtin,
Clang doesn't allow the second (non-atomic) one to be qualified
with an address space.
Remove this restriction by recording the address space of passed pointers
in atomics type diagnostics.
llvm-svn: 256243
Given the following code:
int *_Nullable ptr;
int *_Nonnull nn = ptr;
...In C, clang will warn you about `nn = ptr`, because you're assigning
a nonnull pointer to a nullable pointer. In C++, clang issues no such
warning. This patch helps ensure that clang doesn't ever miss an
opportunity to complain about C++ code.
N.B. Though this patch has a differential revision link, the actual
review took place over email.
Differential Revision: http://reviews.llvm.org/D14938
llvm-svn: 255556
Currently, we emit warnings in some cases where nonnull function
parameters are compared against null. This patch extends this support
to warn when comparing the result of `returns_nonnull` functions
against null.
More specifically, we will now warn cases like:
int *foo() __attribute__((returns_nonnull));
int main() {
if (foo() == NULL) {} // warning: will always evaluate to false
}
Differential Revision: http://reviews.llvm.org/D15324
llvm-svn: 255058
variables in C, in the cases where we can constant-fold it to a value
regardless (such as floating-point division by zero and signed integer
overflow). Strictly enforcing this rule breaks too much code.
llvm-svn: 254992
The introduction of pass_object_size fixed a few bugs related to taking
the address of a function with enable_if attributes. This patch adds
tests for the cases that were fixed.
llvm-svn: 254646
These additions were meant to go in as a part of r254554; while it's
certainly nice to have new functionality, it's nicer if we have tests to
go with it. :)
llvm-svn: 254632
This reverts commit r254143 which introduces a crash on the following input:
f(char *);
g(char *);
#pragma weak f = g
int g(char *p) {}
llvm-svn: 254605
This CL is for discussion how to better fix bit-filed layout compatibility issue with GCC (see PR25575 for test case and more details). Current clang behavior is compatible with GCC 4.1-4.3 series but it was fixed in 4.4+. Ignoring packed attribute looks very odd and because it was also fixed in GCC 4.4+, it makes sense also fix it in clang.
Differential Revision: http://reviews.llvm.org/D14872
llvm-svn: 254596
side-effect, so that we don't allow speculative evaluation of such expressions
during code generation.
This caused a diagnostic quality regression, so fix constant expression
diagnostics to prefer either the first "can't be constant folded" diagnostic or
the first "not a constant expression" diagnostic depending on the kind of
evaluation we're doing. This was always the intent, but didn't quite work
correctly before.
This results in certain initializers that used to be constant initializers to
no longer be; in particular, things like:
float f = 1e100;
are no longer accepted in C. This seems appropriate, as such constructs would
lead to code being executed if sanitizers are enabled.
llvm-svn: 254574
Summary: This patch adds support for the interrupt attribute for mips32r2+.
Patch by Simon Dardis.
Reviewers: dsanders, aaron.ballman
Subscribers: aaron.ballman, cfe-commits
Differential Revision: http://reviews.llvm.org/D10802
llvm-svn: 254205
Summary: This patch adds support for the interrupt attribute for mips32r2+.
Reviewers: dsanders, aaron.ballman
Subscribers: aaron.ballman, cfe-commits
Differential Revision: http://reviews.llvm.org/D10802
llvm-svn: 254203
For MCU only C calling convention is allowed, all other calling conventions are not supported.
Differential Revision: http://reviews.llvm.org/D14864
llvm-svn: 254063
Summary: 's' is used to specify sgprs and 'v' is used to specify vgprs.
Reviewers: arsenm, echristo
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D14307
llvm-svn: 253610
Add support for vector mode attributes like "attribute((mode(V4SF)))". Also add warning about deprecated vector modes like GCC does.
Differential Revision: http://reviews.llvm.org/D14744
llvm-svn: 253551
Currently, when there is a global register variable in a program that
is bound to an invalid register, clang/llvm prints an error message that
is not very user-friendly.
This commit improves the diagnostic and moves the check that used to be
in the backend to Sema. In addition, it makes changes to error out if
the size of the register doesn't match the declared variable size.
e.g., volatile register int B asm ("rbp");
rdar://problem/23084219
Differential Revision: http://reviews.llvm.org/D13834
llvm-svn: 253405
Clang tries to figure out if a call to abs is suspicious by looking
through implicit casts to look at the underlying, implicitly converted
type.
Interestingly, C has implicit conversions from pointer-ish types like
function to less exciting types like int. This trips up our 'abs'
checker because it doesn't know which variant of 'abs' is appropriate.
Instead, diagnose 'abs' called on function types upfront. This sort of
thing is highly suspicious and is likely indicative of a missing
pointer dereference/function call/array index operation.
This fixes PR25532.
llvm-svn: 253156
The ``disable_tail_calls`` attribute instructs the backend to not
perform tail call optimization inside the marked function.
For example,
int callee(int);
int foo(int a) __attribute__((disable_tail_calls)) {
return callee(a); // This call is not tail-call optimized.
}
Note that this attribute is different from 'not_tail_called', which
prevents tail-call optimization to the marked function.
rdar://problem/8973573
Differential Revision: http://reviews.llvm.org/D12547
llvm-svn: 252986
https://gcc.gnu.org/onlinedocs/gcc/Typeof.html
Differences from the GCC extension:
* __auto_type is also permitted in C++ (but only in places where
it could appear in C), allowing its use in headers that might
be shared across C and C++, or used from C++98
* __auto_type can be combined with a declarator, as with C++ auto
(for instance, "__auto_type *p")
* multiple variables can be declared in a single __auto_type
declaration, with the C++ semantics (the deduced type must be
the same in each case)
This patch also adds a missing restriction on applying typeof to
a bit-field, which GCC has historically rejected in C (due to
lack of clarity as to whether the operand should be promoted).
The same restriction also applies to __auto_type in C (in both
GCC and Clang).
This also fixes PR25449.
Patch by Nicholas Allegra!
llvm-svn: 252690
The attrubite is applicable to functions and variables and changes
the linkage of the subject to internal.
This is the same functionality as C-style "static", but applicable to
class methods; and the same as anonymouns namespaces, but can apply
to individual methods of a class.
Following the proposal in
http://lists.llvm.org/pipermail/cfe-dev/2015-October/045580.html
llvm-svn: 252648
This attribute is used to prevent tail-call optimizations to the marked
function. For example, in the following piece of code, foo1 will not be
tail-call optimized:
int __attribute__((not_tail_called)) foo1(int);
int foo2(int a) {
return foo1(a); // Tail-call optimization is not performed.
}
The attribute has effect only on statically bound calls. It has no
effect on indirect calls. Also, virtual functions and objective-c
methods cannot be marked as 'not_tail_called'.
rdar://problem/22667622
Differential Revision: http://reviews.llvm.org/D12922
llvm-svn: 252369
GCC has a warning called -Wdouble-promotion, which warns you when
an implicit conversion increases the width of a floating point type.
This is useful when writing code for architectures that can perform
hardware FP ops on floats, but must fall back to software emulation for
larger types (i.e. double, long double).
This fixes PR15109 <https://llvm.org/bugs/show_bug.cgi?id=15109>.
Thanks to Carl Norum for the patch!
llvm-svn: 251588
1. Make the warning more strict in C mode. r172696 added code to suppress
warnings from macro expansions in system headers, which checks
`SourceMgr.isMacroBodyExpansion(E->IgnoreParens()->getExprLoc())`. Consider
this snippet:
#define FOO(x) (x)
void f(int a) {
FOO(a);
}
In C, the line `FOO(a)` is an `ImplicitCastExpr(ParenExpr(DeclRefExpr))`,
while it's just a `ParenExpr(DeclRefExpr)` in C++. So in C++,
`E->IgnoreParens()` returns the `DeclRefExpr` and the check tests the
SourceLoc of `a`. In C, the `ImplicitCastExpr` has the effect of checking the
SourceLoc of `FOO`, which is a macro body expansion, which causes the
diagnostic to be skipped. It looks unintentional that clang does different
things for C and C++ here, so use `IgnoreParenImpCasts` instead of
`IgnoreParens` here. This has the effect of the warning firing more often
than previously in C code – it now fires as often as it fires in C++ code.
2. Suppress the warning if it would warn on `UNREFERENCED_PARAMETER`.
`UNREFERENCED_PARAMETER` is a commonly used macro on Windows and it happens
to uselessly trigger -Wunused-value. As discussed in the thread
"rfc: winnt.h's UNREFERENCED_PARAMETER() vs clang's -Wunused-value" on
cfe-dev, fix this by special-casing this specific macro. (This costs a string
comparison and some fast-path lexing per warning, but the warning is emitted
rarely. It fires once in Windows.h itself, so this code runs at least once
per TU including Windows.h, but it doesn't run hundreds of times.)
http://reviews.llvm.org/D13969
llvm-svn: 251441
Previously, our logic when taking the address of an overloaded function
would not consider enable_if attributes, so long as all of the enable_if
conditions on a given candidate were true. So, two functions with
identical signatures (one with enable_if attributes, the other without),
would be considered equally good overloads. If we were calling the
function instead of taking its address, then the function with enable_if
attributes would be preferred.
This patch makes us prefer the candidate with enable_if regardless of if
we're calling or taking the address of an overloaded function.
Differential Revision: http://reviews.llvm.org/D13795
llvm-svn: 250486
This fixes a bug where one can take the address of a conditionally
enabled function to drop its enable_if guards. For example:
int foo(int a) __attribute__((enable_if(a > 0, "")));
int (*p)(int) = &foo;
int result = p(-1); // compilation succeeds; calls foo(-1)
Overloading logic has been updated to reflect this change, as well.
Functions with enable_if attributes that are always true are still
allowed to have their address taken.
Differential Revision: http://reviews.llvm.org/D13607
llvm-svn: 250090
C allows for some implicit conversions that C++ does not, e.g. void* ->
char*. This patch teaches clang that these conversions are okay when
dealing with overloads in C.
Differential Revision: http://reviews.llvm.org/D13604
llvm-svn: 249995
Summary:
Currently when a function annotated with __attribute__((nonnull)) is called in an unevaluated context with a null argument a -Wnonnull warning is emitted.
This warning seems like a false positive unless the call expression is potentially evaluated. Change this behavior so that the non-null warnings use DiagRuntimeBehavior so they wont emit when they won't be evaluated.
Reviewers: majnemer, rsmith
Subscribers: mclow.lists, cfe-commits
Differential Revision: http://reviews.llvm.org/D13408
llvm-svn: 249787
consider the following:
enum E *p;
enum E { e };
The above snippet is not ANSI C because 'enum E' has not bee defined
when we are processing the declaration of 'p'; however, it is a popular
extension to make the above work. This would fail using the Microsoft
enum semantics because the definition of 'E' would implicitly have a
fixed underlying type of 'int' which would trigger diagnostic messages
about a mismatch between the declaration and the definition.
Instead, treat fixed underlying types as not fixed for the purposes of
the diagnostic.
llvm-svn: 249674
Our self hosting buildbots found a few more tests which weren't updated
to reflect that the enum semantics are part of the Microsoft ABI.
llvm-svn: 249670
Enums without an explicit, fixed, underlying type are implicitly given a
fixed 'int' type for ABI compatibility with MSVC. However, we can
enforce the standard-mandated rules on these types as-if we didn't know
this fact if the tag is not part of a definition.
llvm-svn: 249667
These test updates almost exclusively around the change in behavior
around enum: enums without a definition are considered incomplete except
when targeting MSVC ABIs. Since these tests are interested in the
'incomplete-enum' behavior, restrict them to %itanium_abi_triple.
llvm-svn: 249660
Diagnose when a pointer to const T is used as the first argument in at atomic
builtin unless that builtin is a load operation. This is already checked for
C11 atomics builtins but not for __atomic ones.
This patch was given the LGTM by rsmith when it was part
of a larger review. (See http://reviews.llvm.org/D10407)
llvm-svn: 249252
Prior to this patch, -Wtautological-overlap-compare would only warn us
if there was a sketchy logical comparison between variables and
IntegerLiterals. This patch makes -Wtautological-overlap-compare aware
of EnumConstantDecls, so it can apply the same logic to them.
llvm-svn: 249053
Several inputs may not refer to one output constraint in inline assembler
insertions, clang was failing on assertion on such test case.
llvm-svn: 248158
Summary:
This change adds support for `__builtin_ms_va_list`, a GCC extension for
variadic `ms_abi` functions. The existing `__builtin_va_list` support is
inadequate for this because `va_list` is defined differently in the Win64
ABI vs. the System V/AMD64 ABI.
Depends on D1622.
Reviewers: rsmith, rnk, rjmccall
CC: cfe-commits
Differential Revision: http://reviews.llvm.org/D1623
llvm-svn: 247941
Previously, in certain cases lax vector conversions could occur between scalar floating-point values and ExtVector types; these conversions would be simple bitcasts. We need to allow them with other vector types to support some common headers, but we don't need them for ExtVector. Preventing them here makes them behave like other operations involving scalars and ExtVectors.
llvm-svn: 247643
We were crashing in CodeGen given input like this:
int self_alias(void) __attribute__((weak, alias("self_alias")));
such a self-alias is invalid, but instead of diagnosing the situation, we'd
proceed to produce IR for both the function declaration and the alias. Because
we already had a function named 'self_alias', the alias could not be named the
same thing, and so LLVM would pick a different name ('self_alias1' for example)
for that value. When we later called CodeGenModule::checkAliases, we'd look up
the IR value corresponding to the alias name, find the function declaration
instead, and then assert in a cast to llvm::GlobalAlias. The easiest way to prevent
this is simply to avoid creating the wrongly-named alias value in the first
place and issue the diagnostic there (instead of in checkAliases). We detect a
related cycle case in CodeGenModule::EmitAliasDefinition already, so this just
adds a second such check.
Even though the other test cases for this 'alias definition is part of a cycle'
diagnostic are in test/Sema/attr-alias-elf.c, I've added a separate regression
test for this case. This is because I can't add this check to
test/Sema/attr-alias-elf.c without disturbing the other test cases in that
file. In order to avoid construction of the bad IR values, this diagnostic
is emitted from within CodeGenModule::EmitAliasDefinition (and the relevant
declaration is not added to the Aliases vector). The other cycle checks are
done within the CodeGenModule::checkAliases function based on the Aliases
vector, called from CodeGenModule::Release. However, if there have been errors
earlier, HandleTranslationUnit does not call Release, and so checkAliases is
never called, and so none of the other diagnostics would be produced.
Fixes PR23509.
llvm-svn: 246882
They might technically have external linkage, but it still doesn't make sense
for the user to try and export such variables. This matches MSVC's and MinGW's
behaviour.
llvm-svn: 246864
We cannot tell if an object is past-the-end if its type is incomplete.
Zero sized objects satisfy past-the-end criteria and our object might
turn out to be such an object.
This fixes PR24622.
llvm-svn: 246359
The problem is that the arguments are of TheCall are reset later
to the ones in Args, making TypoExpr put back. Some TypoExpr that have
already been diagnosed and will assert later in Sema::getTypoExprState
llvm-svn: 245560
alignment is ignored, and they always allocate a complete
storage unit.
Also, change the dumping of AST record layouts: use the more
readable C++-style dumping even in C, include bitfield offset
information in the dump, and don't print sizeof/alignof
information for fields of record type, since we don't do so
for bases or other kinds of field.
rdar://22275433
llvm-svn: 245514
Remove the assumption of a Boolean type by checking if an expression is known
to have a boolean value. Disable warning in two other tests.
llvm-svn: 245507
__builtin_object_size would return incorrect answers for many uses where
type=3. This fixes the inaccuracy by making us emit 0 instead of LLVM's
objectsize intrinsic.
Additionally, there are many cases where we would emit suboptimal (but
correct) answers, such as when arrays are involved. This patch fixes
some of these cases (please see new tests in test/CodeGen/object-size.c
for specifics on which cases are improved)
Resubmit of r245323 with PR24493 fixed.
Patch mostly by Richard Smith.
Differential Revision: http://reviews.llvm.org/D12000
This fixes PR15212.
llvm-svn: 245403
__builtin_object_size would return incorrect answers for many uses where
type=3. This fixes the inaccuracy by making us emit 0 instead of LLVM's
objectsize intrinsic.
Additionally, there are many cases where we would emit suboptimal (but
correct) answers, such as when arrays are involved. This patch fixes
some of these cases (please see new tests in test/CodeGen/object-size.c
for specifics on which cases are improved)
Patch mostly by Richard Smith.
Differential Revision: http://reviews.llvm.org/D12000
This fixes PR15212.
llvm-svn: 245323
So, we now reject that. We also warn for any external-linkage global
variable named main in C, because it results in undefined behavior.
PR: 24309
Differential Revision: http://reviews.llvm.org/D11658
Reviewed by: rsmith
llvm-svn: 245051
Compiler crashed when vector elements / global register vars were used in inline assembler with "m" restriction. This patch fixes this.
Differential Revision: http://reviews.llvm.org/D10476
llvm-svn: 243870
The z13 vector facility has an associated language extension,
closely modeled on AltiVec/VSX. The main differences are:
- vector long, vector float and vector pixel are not supported
- vector long long and vector double are supported (like VSX)
- comparison operators return a vector rather than a scalar integer
- shift operators behave like the OpenCL shift operators
- vector bool is only supported as argument to certain operators;
some operators allow mixing a bool with a non-bool vector
This patch adds clang support for the extension. It is closely modelled
on the AltiVec support. Similarly to the -faltivec option, there's a
new -fzvector option to enable the extensions (as well as an -mzvector
alias for compatibility with GCC). There's also a separate LangOpt.
The extension as implemented here is intended to be compatible with
the -mzvector extension recently implemented by GCC.
Based on a patch by Richard Sandiford.
Differential Revision: http://reviews.llvm.org/D11001
llvm-svn: 243642
There is currently no support in MSVC for using i128 as an integer
literal suffix. In fact, there appears to be no evidence that they have
ever supported this feature in any of their compilers. This was an over
generalization of their actual feature and is a nasty source of bugs.
Why is it a source of bugs? Because most code in clang expects that
evaluation of an integer constant expression won't give them something
that 'long long' can't represent. Instead of providing a meaningful
feature, i128 gives us cute ways of exploding the compiler.
llvm-svn: 243243
to consider the storage size of the vector instead of its
sizeof. In other words, ban <3 x int> to <4 x int> casts,
which produced invalid IR anyway.
Also, attempt to be a little more rigorous, or at least
explicit, about when enums are allowed in these casts.
rdar://21901132
llvm-svn: 243069
can be different from the normal variable maximum.
Add an error diagnostic for when TLS variables exceed maximum TLS alignment.
Currenty only PS4 sets an explicit maximum TLS alignment.
Patch by Charles Li!
llvm-svn: 242198
We referred to all declaration in definitions in our diagnostic messages
which is can be inaccurate. Instead, classify the declaration and emit
an appropriate diagnostic for the new declaration and an appropriate
note pointing to the old one.
This fixes PR24116.
llvm-svn: 242190
Attribute names usually support an alternate spelling that uses double
underscores before and after the attribute name, like e.g. attribute
((__aligned__)) for attribute ((aligned)). This is necessary to allow
use of attributes in system headers without polluting the name space.
However, for attribute ((enable_if)) that alternate spelling does not
work correctly. This is because of code in Parser::ParseGNUAttributeArgs
(ParseDecl.cpp) that specifically checks for the "enable_if" spelling
without allowing the alternate spelling.
Similar code in ParseDecl.cpp uses the normalizeAttrName helper to allow
both spellings. This patch adds use of that helper for the "enable_if"
check as well, which fixes attribute ((__enable_if__)).
Differential Revision: http://reviews.llvm.org/D11142
llvm-svn: 242029
This matches the implementation of the gcc support for the same
feature, including checking the values set up by libgcc at runtime.
The structure looks like this:
unsigned int __cpu_vendor;
unsigned int __cpu_type;
unsigned int __cpu_subtype;
unsigned int __cpu_features[1];
with a set of enums to match various fields that are field out after
parsing the output of the cpuid instruction.
This also adds a set of errors checking for valid input (and cpu).
compiler-rt support for this and the other builtins in this family
(__builtin_cpu_init and __builtin_cpu_is) are forthcoming.
llvm-svn: 240994
Several tests wouldn't pass when executed on an armv7a_pc_linux triple
due to the non-default arm_aapcs calling convention produced on the
function definitions in the IR output. Account for this with the
application of a little regex.
Patch by Ying Yi.
llvm-svn: 240971
Addresses a conflict with glibc's __nonnull macro by renaming the type
nullability qualifiers as follows:
__nonnull -> _Nonnull
__nullable -> _Nullable
__null_unspecified -> _Null_unspecified
This is the major part of rdar://problem/21530726, but does not yet
provide the Darwin-specific behavior for the old names.
llvm-svn: 240596
The ARM _MoveToCoprocessor and _MoveFromCoprocessor builtins require
integer constants for most arguments, but clang was not checking that.
With this change, we now report meaningful errors instead of crashing
in the backend.
llvm-svn: 240463
Regular function calls (such as to cabs()) run into the same problem
with handling dependent exprs, not just builtins with custom type
checking.
Fixes PR23775.
llvm-svn: 240443
This generalizes the checking of null arguments to also work with
values of pointer-to-function, reference-to-function, and block
pointer type, using the nullability information within the underling
function prototype to extend non-null checking, and diagnoses returns
of 'nil' within a function with a __nonnull return type.
Note that we don't warn about nil returns from Objective-C methods,
because it's common for Objective-C methods to mimic the nil-swallowing
behavior of the receiver by checking ostensibly non-null parameters
and returning nil from otherwise non-null methods in that
case.
It also diagnoses (via a separate flag) conversions from nullable to
nonnull pointers. It's a separate flag because this warning can be noisy.
llvm-svn: 240153
Introduces the type specifiers __nonnull, __nullable, and
__null_unspecified that describe the nullability of the pointer type
to which the specifier appertains. Nullability type specifiers improve
on the existing nonnull attributes in a few ways:
- They apply to types, so one can represent a pointer to a non-null
pointer, use them in function pointer types, etc.
- As type specifiers, they are syntactically more lightweight than
__attribute__s or [[attribute]]s.
- They can express both the notion of 'should never be null' and
also 'it makes sense for this to be null', and therefore can more
easily catch errors of omission where one forgot to annotate the
nullability of a particular pointer (this will come in a subsequent
patch).
Nullability type specifiers are maintained as type sugar, and
therefore have no effect on mangling, encoding, overloading,
etc. Nonetheless, they will be used for warnings about, e.g., passing
'null' to a method that does not accept it.
This is the C/C++ part of rdar://problem/18868820.
llvm-svn: 240146
Base type of attribute((mode)) can actually be a vector type.
The patch is to distinguish between base type and base element type.
This fixes http://llvm.org/PR17453.
Differential Revision: http://reviews.llvm.org/D10058
llvm-svn: 240125
in section 10.1, __arm_{w,r}sr{,p,64}.
This includes arm_acle.h definitions with builtins and codegen to support
these, the intrinsics are implemented by generating read/write_register calls
which get appropriately lowered in the backend based on the register string
provided. SemaChecking is also implemented to fault invalid parameters.
Differential Revision: http://reviews.llvm.org/D9697
llvm-svn: 239737
Since we're ignoring the tune= and fpmath= attributes go ahead
and add a warning alerting people to the fact that we're going
to ignore that part of it during code generation and tie it to
the attribute warning set.
llvm-svn: 239583
Modeled after the gcc attribute of the same name, this feature
allows source level annotations to correspond to backend code
generation. In llvm particular parlance, this allows the adding
of subtarget features and changing the cpu for a particular function
based on source level hints.
This has been added into the existing support for function level
attributes without particular verification for any target outside
of whether or not the backend will support the features/cpu given
(similar to section, etc).
llvm-svn: 239579
Based on previous discussion on the mailing list, clang currently lacks support
for C99 partial re-initialization behavior:
Reference: http://lists.cs.uiuc.edu/pipermail/cfe-dev/2013-April/029188.html
Reference: http://www.open-std.org/jtc1/sc22/wg14/www/docs/dr_253.htm
This patch attempts to fix this problem.
Given the following code snippet,
struct P1 { char x[6]; };
struct LP1 { struct P1 p1; };
struct LP1 l = { .p1 = { "foo" }, .p1.x[2] = 'x' };
// this example is adapted from the example for "struct fred x[]" in DR-253;
// currently clang produces in l: { "\0\0x" },
// whereas gcc 4.8 produces { "fox" };
// with this fix, clang will also produce: { "fox" };
Differential Review: http://reviews.llvm.org/D5789
llvm-svn: 239446
Summary:
This modifies Clang to reflect that under pre-C99 ISO C, decimal
constants may have type `unsigned long` even if they do not contain `u`
or `U` in their suffix (C90 subclause 6.1.3.2 paragraph 5). The same is
done for C++ without C++11 which--because of undefined behaviour--allows
for behaviour compatible with ISO C90 in the case of an unsuffixed
decimal literal and is otherwise identical to C90 in its treatment of
integer literals (C++03 subclause 2.13.1 [lex.icon] paragraph 2).
Messages are added to the `c99-compat` and `c++11-compat` groups to warn
on such literals, since they behave differently under the newer
standards.
Fixes PR 16678.
Test Plan:
A new test file is added to exercise both pre-C99/C++11 and C99/C++11-up
on decimal literals with no suffix or suffixes `l`/`L` for both 32-bit
and 64-bit `long`.
In the file, 2^31 (being `INT_MAX+1`) is tested for the expected type
using `__typeof__` and multiple declarations of the same entity. 2^63
is similarly tested when it is within the range of `unsigned long`.
Preprocessor arithmetic tests are added to ensure consistency given
that Clang (like GCC) uses greater than 32 bits for preprocessor
arithmetic even when `long` and `unsigned long` is 32 bits and a
pre-C99/C++11 mode is in effect.
Tests added:
test/Sema/PR16678.c
Reviewers: fraggamuffin, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D9794
llvm-svn: 239356
input / output with memory constraint.
One generally can't get address of a bit field, so the general solution is to
error on such cases. GCC does the same.
Patch by Andrey Bokhanko
Differential Revision: http://reviews.llvm.org/D10086
llvm-svn: 239153
Allows StmtPrinter to print old style field designators in
initializers, fixing an issue where we would print the following
invalid code:
struct A a = {b: = 3, .c = 4};
Patch by Nick Sumner. Thanks!
llvm-svn: 238517
Note: __declspec is also temporarily enabled when compiling for a CUDA target because there are implementation details relying on __declspec(property) support currently. When those details change, __declspec should be disabled for CUDA targets.
llvm-svn: 238238
An AtomicType might be hidden behind arbitrary levels of typedefs.
getAs<> will reliably walk through the sugar to get the underlying
AtomicType.
This fixes PR23638.
llvm-svn: 238083
Add a check for bool-like conversions for the condition expression of
conditional operators. This is similiar to the checking of condition
expressions of if statements, for-loops, while-loops, and do-while loops.
Specificially, this is to fix the problem of assert("message") not triggering
-Wstring-conversion when the assert macro uses a conditional operator.
llvm-svn: 237856
VerifyBitField must be called if we are to form a bitfield FieldDecl.
We will not verify the bitfield if the decl is known to be malformed in
other ways; pretend that we don't have a bitfield if this happens.
llvm-svn: 235816
Don't assume it's always is. This prevents a crash in Sema while
trying to merge return type for a builtin w/out function prototype.
PR: 23086
Differential Revision: http://reviews.llvm.org/D9235
Reviewed by: rsmith
llvm-svn: 235806
The GCC construct __attribute__((aligned)) is defined to set alignment
to "the default alignment for the target architecture" according to
the GCC documentation:
The default alignment is sufficient for all scalar types, but may not be
enough for all vector types on a target that supports vector operations.
The default alignment is fixed for a particular target ABI.
clang currently hard-coded an alignment of 16 bytes for that construct,
which is correct on some platforms (including X86), but wrong on others
(including SystemZ). Since this value is ABI-relevant, it is important
to get correct for compatibility purposes.
This patch adds a new TargetInfo member "DefaultAlignForAttributeAligned"
that targets can set to the appropriate default __attribute__((aligned))
value.
Note that I'm deliberately *not* using the existing "SuitableAlign"
value, which is used to set the pre-defined macro __BIGGEST_ALIGNMENT__,
since those two values may not be the same on all platforms. In fact,
on X86, __attribute__((aligned)) always uses 16-byte alignment, while
__BIGGEST_ALIGNMENT__ may be larger if AVX-2 or AVX-512 are supported.
(This is actually not yet correctly implemented in clang either.)
The patch provides a value for DefaultAlignForAttributeAligned only for
SystemZ, and leaves the default for all other targets at 16, which means
no visible change in behavior on all other targets. (The value is still
wrong for some other targets, but I'd prefer to leave it to the target
maintainers for those platforms to fix.)
llvm-svn: 235397
SystemZ prefers to align all global variables to two bytes, which is
implemented by setting the TargetInfo member MinGlobalAlign.
However, for compatibility with existing compilers this should *not*
change the ABI alignment value as retrieved via __alignof__, which
it currently does.
This patch fixes the issue by having ASTContext::getDeclAlign ignore
the MinGlobalAlign setting in the ForAlignof case.
Since SystemZ is the only platform setting MinGlobalAlign, this should
cause no change for any other target.
llvm-svn: 235395
We already check that statement expressions are in a function or block,
but we didn't do anything with that information. Now we use that
DeclContext for the duration of the statement expression. Otherwise,
we'd treat statement expression locals as static data members and go
into the weeds.
llvm-svn: 235335
Previously, many error messages would simply be "read-only variable is not
assignable" This change provides more information about why the variable is
not assignable, as well as note to where the const is located.
Differential Revision: http://reviews.llvm.org/D4479
llvm-svn: 234677
Alexey Bataev