This is the 5th Lit test patch.
Expanded expected diagnostics to vary by C++ dialect.
Expanded RUN line to: default, C++98/03 and C++11.
llvm-svn: 255196
std::initializer_list<T> type. Instead, the list must contain a single element
and the type is deduced from that.
In Clang 3.7, we warned by default on all the cases that would change meaning
due to this change. In Clang 3.8, we will support only the new rules -- per
the request in N3922, this change is applied as a Defect Report against earlier
versions of the C++ standard.
This change is not entirely trivial, because for lambda init-captures we
previously did not track the difference between direct-list-initialization and
copy-list-initialization. The difference was not previously observable, because
the two forms of initialization always did the same thing (the elements of the
initializer list were always copy-initialized regardless of the initialization
style used for the init-capture).
llvm-svn: 252688
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
the "" and the suffix; that breaks names such as 'operator""if'. For symmetry,
also remove the space between the 'operator' and the '""'.
llvm-svn: 249641
- Remove virtual SC_OpenCLWorkGroupLocal storage type specifier
as it conflicts with static local variables now and prevents
diagnosing static local address space variables correctly.
- Allow static local and global variables (OpenCL2.0 s6.8 and s6.5.1).
- Improve diagnostics of allowed ASes for variables in different scopes:
(i) Global or static local variables have to be in global
or constant ASes (OpenCL1.2 s6.5, OpenCL2.0 s6.5.1);
(ii) Non-kernel function variables can't be declared in local
or constant ASes (OpenCL1.1 s6.5.2 and s6.5.3).
http://reviews.llvm.org/D13105
llvm-svn: 248906
Applied restrictions from OpenCL v2.0 s6.13.11.8
that mainly disallow operations on atomic types (except for taking their address - &).
The patch is taken from SPIR2.0 provisional branch, contributed by Guy Benyei!
llvm-svn: 248896
Summary:
MSDN says that fastcall, stdcall, thiscall, and vectorcall are all
accepted but ignored on ARM and X64.
https://msdn.microsoft.com/en-us/library/984x0h58.aspx
MSDN also says cdecl is also accepted and typically ignored
This patch brings ARM in line with how we ignore them for X64
Reviewers: rnk
Subscribers: compnerd, cfe-commits
Differential Revision: http://reviews.llvm.org/D12034
llvm-svn: 245076
This change adds the new unroll metadata "llvm.loop.unroll.enable" which directs
the optimizer to unroll a loop fully if the trip count is known at compile time, and
unroll partially if the trip count is not known at compile time. This differs from
"llvm.loop.unroll.full" which explicitly does not unroll a loop if the trip count is not
known at compile time
With this change "#pragma unroll" generates "llvm.loop.unroll.enable" rather than
"llvm.loop.unroll.full" metadata. This changes the semantics of "#pragma unroll" slightly
to mean "unroll aggressively (fully or partially)" rather than "unroll fully or not at all".
The motivating example for this change was some internal code with a loop marked
with "#pragma unroll" which only sometimes had a compile-time trip count depending
on template magic. When the trip count was a compile-time constant, everything works
as expected and the loop is fully unrolled. However, when the trip count was not a
compile-time constant the "#pragma unroll" explicitly disabled unrolling of the loop(!).
Removing "#pragma unroll" caused the loop to be unrolled partially which was desirable
from a performance perspective.
llvm-svn: 244467
Clang used to silently ignore __declspec(novtable). It is implemented
now, but leaving the vtable uninitialized does not work when using the
Itanium ABI, where the class layout for complex class hierarchies is
stored in the vtable. It might be possible to honor the novtable
attribute in some simple cases and either report an error or ignore
it in more complex situations, but it’s not clear if that would be
worthwhile. There is also value in having a simple and predictable
behavior, so this changes clang to simply ignore novtable when not using
the Microsoft C++ ABI.
llvm-svn: 242730
This reverts commit r239846 and r239879. They caused clang's
-fms-extensions behavior to incorrectly parse lambdas and includes a
testcase to ensure we don't regress again.
This issue was found in PR24027.
llvm-svn: 241668
Teach C++'s tentative parsing to handle specializations of Objective-C
class types (e.g., NSArray<NSString *>) as well as Objective-C
protocol qualifiers (id<NSCopying>) by extending type-annotation
tokens to handle this case. As part of this, remove Objective-C
protocol qualifiers from the declaration specifiers, which never
really made sense: instead, provide Sema entry points to make them
part of the type annotation token. Among other things, this properly
diagnoses bogus types such as "<NSCopying> id" which should have been
written as "id <NSCopying>".
Implements template instantiation support for, e.g., NSArray<T>*
in C++. Note that parameterized classes are not templates in the C++
sense, so that cannot (for example) be used as a template argument for
a template template parameter. Part of rdar://problem/6294649.
llvm-svn: 241545
Objective-C type arguments can be provided in angle brackets following
an Objective-C interface type. Syntactically, this is the same
position as one would provide protocol qualifiers (e.g.,
id<NSCopying>), so parse both together and let Sema sort out the
ambiguous cases. This applies both when parsing types and when parsing
the superclass of an Objective-C class, which can now be a specialized
type (e.g., NSMutableArray<T> inherits from NSArray<T>).
Check Objective-C type arguments against the type parameters of the
corresponding class. Verify the length of the type argument list and
that each type argument satisfies the corresponding bound.
Specializations of parameterized Objective-C classes are represented
in the type system as distinct types. Both specialized types (e.g.,
NSArray<NSString *> *) and unspecialized types (NSArray *) are
represented, separately.
llvm-svn: 241542
Produce type parameter declarations for Objective-C type parameters,
and attach lists of type parameters to Objective-C classes,
categories, forward declarations, and extensions as
appropriate. Perform semantic analysis of type bounds for type
parameters, both in isolation and across classes/categories/extensions
to ensure consistency.
Also handle (de-)serialization of Objective-C type parameter lists,
along with sundry other things one must do to add a new declaration to
Clang.
Note that Objective-C type parameters are typedef name declarations,
like typedefs and C++11 type aliases, in support of type erasure.
Part of rdar://problem/6294649.
llvm-svn: 241541
Summary: This change adds parsing for the concept keyword in a
declaration and tracks the location. Diagnostic testing added for
invalid use of concept keyword.
Reviewers: faisalv, fraggamuffin, rsmith, hubert.reinterpretcast
Reviewed By: rsmith, hubert.reinterpretcast
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10528
Patch by Nathan Wilson!
llvm-svn: 241060
Summary:
This change implements parse-only acceptance of the optional
requires-clause in a template-declaration. Diagnostic testing is added
for cases where the grammar is ambiguous with the expectation that the
longest token sequence which matches the syntax of a
constraint-expression is consumed without backtracking.
Reviewers: faisalv, fraggamuffin, rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D10462
llvm-svn: 240611
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
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
MS attributes do not permit empty attribute blocks. Correctly diagnose those.
We continue to parse to ensure that we recover correctly. Because the block is
empty, we do not need to skip any tokens.
Bonus: tweak the comment that I updated but forgot to remove the function name
in a previous commit.
llvm-svn: 239846
Switch to using BalancedDelimiterTracker to get better diagnostics for
unbalanced delimiters. This still does not handle any of the attributes, simply
improves the parsing.
llvm-svn: 239758
Specifying #pragma clang loop vectorize(assume_safety) on a loop adds the
mem.parallel_loop_access metadata to each load/store operation in the loop. This
metadata tells loop access analysis (LAA) to skip memory dependency checking.
llvm-svn: 239572
When pragma clang loop unroll() is specified without an argument the diagnostic message should inform that user that 'full' and 'disable' are valid arguments (not 'enable').
llvm-svn: 239363
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
Previously, if a semi-colon is unexpectedly added before a closing ')', ']' or
'}', two errors and one note would emitted, and the parsing would get confused
to which scope it was in. This change consumes the semi-colon, recovers
parsing better, and emits only one error with a fix-it.
llvm-svn: 237192
Empty assembly string will not introduce assembly code in the output
binary and it is often used as a trick in the header to disable
optimizations. It doesn't conflict with the purpose of the option so it
is allowed with -fno-gnu-inline-asm flag.
llvm-svn: 237073
Summary:
AsmLabel is heavily used in system level and firmware to redirect
function and access platform specific labels. They are also extensively
used in system headers which makes this option unusable for many
users. Since AsmLabel doesn't introduce any assembly code into the
output binary, it shouldn't be considered as inline-asm.
Reviewers: bob.wilson, rnk
Reviewed By: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D9679
llvm-svn: 237048
And thereby stop asserting.
In ObjC++ modes, we tentatively parse the lambda introducer twice: once
to disambiguate designators, which we also do in C++, and a second time
to disambiguate objc message expressions. During the second tentative
parse, the last cached token will be the annotation token we built in
the first parse. So use getLastLoc() to get the correct end location
for the rebuilt annotation.
llvm-svn: 236246
Summary:
FileScopeAsm should be treated the same as funcion level inline asm.
-fno-gnu-inline-asm should trigger an error if file scope asm is used.
I missed this case from r226340. This should not affect ms-extension
because it is not allowed in the file scope.
Reviewers: bob.wilson, rnk
Reviewed By: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D9328
llvm-svn: 236044
__declspec(align(...)) is unlike all other attributes in that it is not
applied to a variable if it appears before the class-key. If the
tag in question isn't part of a variable declaration, it is not ignored.
Instead, the alignment attribute is applied to the tag.
This fixes PR18024.
llvm-svn: 235272
OpenCL C Spec v2.0 Section 6.13.11
- Made c11 _Atomic being not accepted for OpenCL
- Implemented CL2.0 atomics by aliasing them to the corresponding c11 atomic types using implicit typedef
- Added diagnostics for atomics Khronos extension enabling
llvm-svn: 232631
OpenCL C Spec v2.0 Section 6.13.11
- Made c11 _Atomic being accepted only for c11 compilations
- Implemented CL2.0 atomics by aliasing them to the corresponding c11 atomic types using implicit typedef
- Added diagnostics for atomics Khronos extension enabling
llvm-svn: 231932
There are two test case updates for very basic testing. While I was editing cxx-altivec.cpp I also updated it to better match some other changes in altivec.c.
Note: "vector bool long" was not also added because its use is considered deprecated.
http://reviews.llvm.org/D7235
llvm-svn: 231118
We'd diagnose an __assume expression which contained a function call.
This would result in us wrongly returning ExprError, causing mysterious
failures later on.
llvm-svn: 230597
the presence of an abstract declarator with a ptr-operator as proof that a
construct cannot parse as an expression to improve diagnostics along error
recovery paths.
llvm-svn: 230261
The deprecated attribute was adopted as part of the C++14, however, there is a
GNU version available in C++11. When using C++ earlier than C++14, diagnose the
use of the attribute without the GNU scope, but only when using the generalised
attribute syntax.
llvm-svn: 229447
The first part of that line doesn't parse correctly and ParseClassSpecifier() for
some reason skips to tok::comma to recover, and then
ParseDeclarationSpecifiers() sees the next struct and calls
ParseClassSpecifier() again with the same DeclSpec object.
However, the first call already called ActOnCXXGlobalScopeSpecifier() on the
DeclSpec's CXXScopeSpec, and sema gets confused when this gets called again.
As a fix, let ParseClassSpecifier() (and ParseEnumSpecifier()) call
ParseOptionalCXXScopeSpec() with a temporary CXXScopeSpec object, and only
copy it into the DeclSpec if things work out. (This is also how all the other
functions that set the DeclSpec's TypeSpecScope set it.)
Found by SLi's bot.
llvm-svn: 229293
The first part of that line doesn't parse correctly and ParseClassSpecifier() for
some reason skips to tok::comma to recover, and then
ParseDeclarationSpecifiers() sees the next struct and calls
ParseClassSpecifier() again with the same DeclSpec object.
However, the first call already called ActOnCXXGlobalScopeSpecifier() on the
DeclSpec's CXXScopeSpec, and sema gets confused when this gets called again.
As a fix, let ParseClassSpecifier() (and ParseEnumSpecifier()) call
ParseOptionalCXXScopeSpec() with a temporary CXXScopeSpec object, and only
copy it into the DeclSpec if things work out. (This is also how all the other
functions that set the DeclSpec's TypeSpecScope set it.)
Found by SLi's bot.
llvm-svn: 229288
(or of a lambda init-capture, which is sort-of such a variable). The semantics
of such constructs will change when we implement N3922, so we intend to warn on
this in Clang 3.6 then change the semantics in Clang 3.7.
llvm-svn: 228792
PrettyStackTrace now requires the ENABLE_BACKTRACES option. We need to check for that here or these tests fail llvm-lit.
Reviewed by chandlerc
llvm-svn: 228735
__declspec(restrict) and __attribute(malloc) are both handled
identically by clang: they are allowed to the noalias LLVM attribute.
Seeing as how noalias models the C99 notion of 'restrict', rename the
internal clang attribute to Restrict from Malloc.
llvm-svn: 228120
It is common for COM interface classes to be marked as 'novtable' to
tell the compiler that constructors and destructors should not reference
virtual function tables.
This commit implements this feature in clang.
llvm-svn: 227796
This used to crash, complaining "ObjectType and scope specifier cannot coexist":
struct A { } b = b.~A::A <int>;
The only other caller of ParseOptionalCXXScopeSpecifier() that passes in a
non-empty ObjectType clears the ObjectType of the scope specifier comes back
non-empty (see the tok::period case in Parser::ParsePostfixExpressionSuffix()),
so do that here too.
Found by SLi's bot.
llvm-svn: 227781
Even with r227555, this still crashed:
struct S {
int A;
~A::A() {}
};
That's because ParseOptionalCXXScopeSpecifier()'s call to
ActOnCXXNestedNameSpecifier() doesn't mark the scope spec as invalid if sema
thought it's a good idea to fixit-correct "::" to ":". For the diagnostic
improvement done in r217302, we never want :: to be interpreted as :, so fix
this by setting ColonSacred to false temporarily.
Found by SLi's bot.
llvm-svn: 227581
Previously if an enumeration was used in a nested name specifier in pre-C++11
language dialect, error message was 'XXX is not a class, namespace, or scoped
enumeration'. This patch removes the word 'scoped' as in C++11 any enumeration
may be used in this context.
llvm-svn: 226410
Clang currently crashes on
class C {
C() = default;
C() = delete;
};
My cunning plan for fixing this was to change the `if (!FnD)` in
Parser::ParseCXXInlineMethodDef() to `if (!FnD || FnD->isInvalidDecl)` – but
alas, the second constructor decl wasn't marked as invalid. This lets
Sema::MergeFunctionDecl() return true on function redeclarations, which leads
to them being marked invalid.
This also improves error messages when functions are redeclared.
llvm-svn: 226365
Summary:
This patch add a new option to dis-allow all inline asm.
Any GCC style inline asm will be reported as an error.
Reviewers: rnk, echristo
Reviewed By: rnk, echristo
Subscribers: bob.wilson, rnk, echristo, rsmith, cfe-commits
Differential Revision: http://reviews.llvm.org/D6870
llvm-svn: 226340
We'd crash trying to make the SourceRange for the tokens we'd like to
highlight. Don't assume there is more than one token makes up the
default argument.
llvm-svn: 225774
Mark the end of the method body with an EOF token, collect it once we
expect to be done with method body parsing. No functionality change
intended.
llvm-svn: 225765
It is not correct to let it consume the cxx_defaultarg_end token. I'm
starting to wonder if it makes more sense to stop SkipUntil from
consuming such tokens.
llvm-svn: 225615
Recovery from malformed lambda introducers would find us consuming the
synthetic default argument token, which is bad. Instead, stop right
before that token.
llvm-svn: 225613
Parser::ParseNamespace can get a little confused when it found itself
inside a compound statement inside of a non-static data member
initializer.
Try to determine that the statement expression's scope makes sense
before trying to parse it's contents.
llvm-svn: 225514
Sema::CheckParmsForFunctionDef can't cope with a null TypeSourceInfo.
Don't let the AST contain the malformed lambda.
This fixes PR22122.
llvm-svn: 225505
This is a follow-up to r224915. This adds a bit more line noise to the tests
added in that revision to make sure the parser is ready for a toplevel decl
after each incorrect line. Use this to move the tests up to where they belong.
This uncovered that the early return was missing a call to
ActOnTagDefinitionError(), so add that. (Also fixes at least one of the crashes
on SLi's bot.)
llvm-svn: 224958
r168626 added nicer diagnostics for attributes in the wrong places, such as
after the `final` on a class. To do this, it added code that did high-level
pattern matching for e.g. 'final' 'alignas' '(' and then skipped until the
closing ')'. If it saw that, it then went down the regular class parsing
path and then called MaybeParseCXX11Attributes() to parse the attribute after
the 'final' using real attribute parsing code. On invalid attributes, the
real attribute parsing code could eat more tokens than the pattern matching
code and for example skip past the '{' starting the class, which would then
lead to an assert. To prevent this, check for a good state after calling
MaybeParseCXX11Attributes() (which morphed into CheckMisplacedCXX11Attribute()
in r175575) and bail out if things look bleak.
Found by SLi's afl bot.
llvm-svn: 224915
Fixes this snippet from SLi's afl fuzzer output:
class {
i (x = <, enum
This parsed i as a function, x as a paramter, and the stuff after < as a
template list. This then called TryConsumeDeclarationSpecifier() which
called TryAnnotateCXXScopeToken() without checking the preconditions of
this function. Check them before calling, like all other callers of
TryAnnotateCXXScopeToken() do.
A more readable reproducer that causes the same crash is
class {
void i(int x = MyTemplateClass<int, union int>::foo());
};
The reduced version used an eof token as surprising token, but kw_int works
just as well to repro and is easier to insert into a test file.
llvm-svn: 224906
isDeclarationSpecifier performs error recovers which jostles the token
stream. Specifically, TryAnnotateTypeOrScopeToken will end up consuming
a typename token which will confuse the attribute parsing machinery as
we no-longer have something identifier-like.
llvm-svn: 224903
ParseCXXNonStaticMemberInitializer stashes away all the tokens for the
initializer and an additional EOF token to denote where the initializer
ends. However, it is possible for ParseLexedMemberInitializer to get
its hands on the "real" EOF token; since the two tokens are
indistinguishable, we end up consuming the EOF and descend into madness.
Instead, make it possible to tell which EOF token we are looking at.
This fixes PR21872.
llvm-svn: 224505
So, place warning about property getter should not be used for side-effect
under its own group so warning can be turned off.
rdar://19137815
llvm-svn: 224479
The parser can only be tricked into parsing a function template
definition by inserting a typename keyword before the function template
declaration. This used to make us crash, and now it's fixed.
While here, remove an unneeded boolean parameter from ParseDeclGroup.
This boolean always corresponded to non-typedef declarators at file
scope. ParseDeclGroup already has precise diagnostics for the function
definition typedef case, so we can let that through.
Fixes PR21839.
llvm-svn: 224287
We would exit Sema::ActOnFinishSwitchStmt early if we didn't have a
body. This would leave an extra SwitchStmt on the SwitchStack.
This fixes PR21841.
llvm-svn: 224237
Sema::handleAnnotateAttr expects that some basic validation is done on
the given AttributeList. However, ProcessAccessDeclAttributeList called
it directly. Instead, pass the list to ProcessDeclAttribute.
This fixes PR21847.
llvm-svn: 224204
We would crash trying to treat a property member as a field. These
shoudl be forbidden anyway, reject programs which contain them.
This fixes PR21840.
llvm-svn: 224193
While we would correctly handle asm("foo") and reject asm(L"bar"), we
weren't careful to handle cases where an ascii literal could be
concatenated with a wide literal.
This fixes PR21822.
llvm-svn: 223992
This allows 'namespace A::B { ... }' as a shorthand for 'namespace A {
namespace B { ... } }'. We already supported this correctly for error recovery;
promote that support to a full implementation.
This is not the right implementation: we do not maintain source fidelity
because we desugar the nested namespace definition in the parser. This is
tricky to avoid, since the definition genuinely does inject one named
entity per level in the namespace name.
llvm-svn: 221574
This is a new form of expression of the form:
(expr op ... op expr)
where one of the exprs is a parameter pack. It expands into
(expr1 op (expr2onwards op ... op expr))
(and likewise if the pack is on the right). The non-pack operand can be
omitted; in that case, an empty pack gives a fallback value or an error,
depending on the operator.
llvm-svn: 221573
Now that we have initial support for VSX, we can begin adding
intrinsics for programmer access to VSX instructions. This patch
performs the necessary enablement in the front end, and tests it by
implementing intrinsics for minimum and maximum using the vector
double data type.
The main change in the front end is to no longer disallow "vector" and
"double" in the same declaration (lib/Sema/DeclSpec.cpp), but "vector"
and "long double" must still be disallowed. The new intrinsics are
accessed via vec_max and vec_min with changes in
lib/Headers/altivec.h. Note that for v4f32, we already access
corresponding VMX builtins, but with VSX enabled we should use the
forms that allow all 64 vector registers.
The new built-ins are defined in include/clang/Basic/BuiltinsPPC.def.
I've added a new test in test/CodeGen/builtins-ppc-vsx.c that is
similar to, but much smaller than, builtins-ppc-altivec.c. This
allows us to test VSX IR generation without duplicating CHECK lines
for the existing bazillion Altivec tests.
Since vector double is now legal when VSX is available, I've modified
the error message, and changed where we test for it and for vector
long double, since the target machine isn't visible in the old place.
This serendipitously removed a not-pertinent warning about 'long'
being deprecated when used with 'vector', when "vector long double" is
encountered and we just want to issue an error. The existing tests
test/Parser/altivec.c and test/Parser/cxx-altivec.cpp have been
updated accordingly, and I've added test/Parser/vsx.c to verify that
"vector double" is now legitimate with VSX enabled.
There is a companion patch for LLVM.
llvm-svn: 220989
This is long-since overdue, and matches GCC 5.0. This should also be
backwards-compatible, because we already supported all of C11 as an extension
in C99 mode.
llvm-svn: 220244
Previously loop hints such as #pragma loop vectorize_width(#) required a constant. This patch allows a constant expression to be used as well. Such as a non-type template parameter or an expression (2 * c + 1).
Reviewed by Richard Smith
llvm-svn: 219589
This CL has caused bootstrap failures on Linux and OSX buildbots running with -Werror.
Example report from http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux/builds/13183/steps/bootstrap%20clang/logs/stdio:
================================================================
[ 91%] Building CXX object tools/clang/tools/diagtool/CMakeFiles/diagtool.dir/ShowEnabledWarnings.cpp.o
In file included from /home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/AMDGPUISelDAGToDAG.cpp:20:
In file included from /home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/SIISelLowering.h:19:
/home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/lib/Target/R600/SIInstrInfo.h:71:8: error: 'getLdStBaseRegImmOfs' overrides a member function but is not marked 'override' [-Werror,-Winconsistent-missing-override]
bool getLdStBaseRegImmOfs(MachineInstr *LdSt,
^
/home/dtoolsbot/build/sanitizer-x86_64-linux/build/llvm/include/llvm/Target/TargetInstrInfo.h:815:16: note: overridden virtual function is here
virtual bool getLdStBaseRegImmOfs(MachineInstr *LdSt,
^
================================================================
llvm-svn: 218969
for an overriding method if class has at least one
'override' specified on one of its methods.
Reviewed by Doug Gregor. rdar://18295240
(I have already checked in all llvm files with missing 'override'
methods and Bob Wilson has fixed a TableGen of FastISel so
no warnings are expected from build of llvm after this patch.
I have already verified this).
llvm-svn: 218925
lexer, add the token buffer underneath the caching lexer where possible and
push the tokens directly into the caching lexer otherwise. We previously
put the lexer into a corrupted state where we could not guarantee to provide
the tokens in the right order and would sometimes assert.
llvm-svn: 218333
Summary:
This fixes PR20023. In order to implement this scoping rule, we piggy
back on the existing LabelDecl machinery, by creating LabelDecl's that
will carry the "internal" name of the inline assembly label, which we
will rewrite the asm label to.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4589
llvm-svn: 218230
feature is c11 about nested struct declarations must have
struct-declarator-list. Without this change, code
which was meant for c99 breaks. rdar://18125536
llvm-svn: 216469
__vector long is deprecated, but __vector long long is not. As a result, we
cannot check for __vector long (to issue the deprecation warning) as we parse
the type because we need to know how many 'long's we have first.
DeclSpec::Finish seems like a more-appropriate place to perform the check
(which places it with several other similar Altivec vector checks).
Fixes PR20720.
llvm-svn: 216342
Fixes build for SPEC 2000 CPU. MSVC disables these aliases under /Za,
which enables stricter standards compliance. We don't currently have any
way to disable them.
Patch by Kevin Smith!
llvm-svn: 216270
it. Diagnose with recovery if it appears after a function parameter that was
obviously supposed to be a parameter pack. Otherwise, warn if it immediately
follows a function parameter pack, because the user most likely didn't intend
to write a parameter pack followed by a C-style varargs ellipsis.
This warning can be syntactically disabled by using ", ..." instead of "...".
llvm-svn: 215408
We had two bugs:
- We wouldn't properly warn when a struct/union/enum was mentioned
inside of a record definition if no declarator was provided. We
should have mentioned that this declaration declares nothing.
- We didn't properly support Microsoft's extension where certain
declspecs without declarators would act as anonymous structs/unions.
* We completely ignored the case where such a declspec could be a
union.
* We didn't properly handle the case where a record was defined inside
another record:
struct X {
int a;
struct Y {
int b;
};
};
llvm-svn: 215347
Array declarators involving the static keyword take on two forms:
D[ static type-qualifier-listopt assignment-expression ]
D[ type-qualifier-list static assignment-expression ]
Raise a diagnostic if the assignment-expression is missing.
This fixes PR20584.
llvm-svn: 215187
This patch is necessary to support constant expressions which replaces the integer value in the loop hint attribute with an expression. The integer value was also storing the pragma’s state for options like vectorize(enable/disable) and the pragma unroll and nounroll directive. The state variable is introduced to hold the state of those options/pragmas. This moves the validation of the state (keywords) from SemaStmtAttr handler to the loop hint annotation token handler.
Resubmit with changes to try to fix the build-bot issue.
Reviewed by Aaron Ballman
llvm-svn: 214432
This patch is necessary to support constant expressions which replaces the integer value in the loop hint attribute with an expression. The integer value was also storing the pragma’s state for options like vectorize(enable/disable) and the pragma unroll and nounroll directive. The state variable is introduced to hold the state of those options/pragmas. This moves the validation of the state (keywords) from SemaStmtAttr handler to the loop hint annotation token handler.
Reviewed by Aaron Ballman
llvm-svn: 214333
Parser::ParseDeclarationSpecifiers eagerly updates the source range of
the DeclSpec with the current token position. However, it might not
consume any more tokens.
Fix this by only setting the start of the range, not the end. This way
the SourceRange will be invalid if we don't consume any more tokens.
This fixes PR20413.
Differential Revision: http://reviews.llvm.org/D4646
llvm-svn: 214018
Summary:
This patch extends the __asm parser to make it keep parsing input tokens
as inline assembly if a single-line __asm line is followed by another line
starting with __asm too. It also makes sure that we correctly keep
matching braces in such situations by separating the notions of how many
braces we are matching and whether we are in single-line asm block mode.
Reviewers: rnk
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4598
llvm-svn: 213916
We've decided to make the core rewriter class and PP rewriters mandatory.
They're only a few hundred lines of code in total and not worth supporting as a
distinct build configuration, especially since doing so disables key compiler
features.
This reverts commit r213150.
Revert "clang/test: Introduce the feature "rewriter" for --enable-clang-rewriter."
This reverts commit r213148.
Revert "Move clang/test/Frontend/rewrite-*.c to clang/test/Frontend/Rewriter/"
This reverts commit r213146.
llvm-svn: 213159
Summary:
Without this, we would not consume the closing brace which would cause
the parser to start consuming C++ and bad things would happen.
Reviewers: majnemer
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4505
llvm-svn: 213032
Otherwise, multiple errors such as having unknown identifiers for two
arguments won't be diagnosed properly (e.g. only the first one would
have a diagnostic message if typo correction fails even though both
would be diagnosed if typo correction suggests a replacement).
llvm-svn: 213003
Summary:
This gives us back the test coverage we lost when I made
MicrosoftExtensions.c x86-only.
Reviewers: majnemer
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4401
llvm-svn: 212414
This is a follow-up to David's r211677. For the following code,
we would end up referring to 'foo' in the initializer for 'arr',
and then fail to link, because 'foo' is dllimport and needs to be
accessed through the __imp_?foo.
__declspec(dllimport) extern const char foo[];
const char* f() {
static const char* const arr[] = { foo };
return arr[0];
}
Differential Revision: http://reviews.llvm.org/D4299
llvm-svn: 211736
Rather than having kw___if_exists be a special case of
ParseCompoundStatementBody, we can look for kw___if_exists in the big
switch over for valid statement tokens in ParseStatementOrDeclaration.
Nested __if_exists blocks are used in the DECLARE_REGISTRY_RESOURCEID
macro from atlcom.h.
llvm-svn: 211654
MSVC does not create a new scope for the body of an __if_exists compound
statement. Clang already gets this right today, but it was untested.
llvm-svn: 211650
When a user types:
int [4] foo;
assume that the user means:
int foo[4];
Update the information for 'foo' to prevent additional errors, and provide
a fix-it hint to move the brackets to the correct location.
Additionally, suggest parens for types that require it, such as:
int [4] *foo;
to:
int (*foo)[4];
llvm-svn: 211641
This patch fixes a crash when handling malformed arguments to loop pragmas such
as: "#pragma clang loop vectorize(()". Essentially any argument which is not an
identifier or constant resulted in a crash. This patch also changes a couple of
the error messages which weren't quite correct. New behavior with this patch vs
old behavior:
#pragma clang loop vectorize(1)
OLD: error: missing keyword; expected 'enable' or 'disable'
NEW: error: invalid argument; expected 'enable' or 'disable'
#pragma clang loop vectorize()
OLD: error: expected ')'
NEW: error: missing argument to loop pragma 'vectorize'
#pragma clang loop vectorize_width(bad)
OLD: error: missing value; expected a positive integer value
NEW: error: invalid argument; expected a positive integer value
#pragma clang loop vectorize(bad)
OLD: invalid keyword 'bad'; expected 'enable' or 'disable'
NEW: error: invalid argument; expected 'enable' or 'disable'
http://reviews.llvm.org/D4197
Patch by Mark Heffernan
llvm-svn: 211292
There are several Altivec tests that formerly ran only on big-endian
targets (and in some cases only on 32-bit targets). It is useful to
verify these on little-endian targets as well.
While testing these, I discovered a typo in <altivec.h>. This is also
fixed by this patch.
llvm-svn: 210928
With recent changes, this is now a compatible language extension and can be
safely enabled with -ms-extensions instead of requiring the full
-ms-compatibility MSVC drop-in mode. As such we can now also emit an extension
warning under -Wmicrosoft to help users port their code.
llvm-svn: 209978
This patch implements support for selectively disabling optimizations on a
range of function definitions through a pragma. The implementation is that
all function definitions in the range are decorated with attribute
'optnone'.
#pragma clang optimize off
// All function definitions in here are decorated with 'optnone'.
#pragma clang optimize on
// Compilation resumes as normal.
llvm-svn: 209510
class template member classes (PR19613)
Also improve this code in general by implementing suggestions
from Richard.
Differential Revision: http://reviews.llvm.org/D3555?id=9020
llvm-svn: 207822
We never aka vector types because our attributed syntax for it is less
comprehensible than the typedefs. This leaves the user in the dark when
the typedef isn't named that well.
Example:
v2s v; v4f w;
w = v;
The naming in this cases isn't even that bad, but the error we give is
useless without looking up the actual typedefs.
t.c:6:5: error: assigning to 'v4f' from incompatible type 'v2s'
Now:
t.c:6:5: error: assigning to 'v4f' (vector of 4 'float' values) from
incompatible type 'v2s' (vector of 2 'int' values)
We do this for all diagnostics that print a vector type.
llvm-svn: 207267
Parse of nested name spacifier is modified so that it properly recovers
if colon is mistyped as double colon in case statement.
This patch fixes PR15133.
Differential Revision: http://llvm-reviews.chandlerc.com/D2870
llvm-svn: 206135
This introduces the definitions needed for the Windows on ARM target. Add
target definitions for both the MSVC environment and the MSVC + Itanium C++ ABI
environment. The Visual Studio definitions correspond to the definitions
provided by Visual Studio 2012.
llvm-svn: 205650
For namespaces, this is consistent with mangling and GCC's debug info
behavior. For structs, GCC uses <anonymous struct> but we prefer
consistency between all anonymous entities but don't want to confuse
them with template arguments, etc, so we'll just go with parens in all
cases.
llvm-svn: 205398
This removes a diagnostic that is no longer required (the semantic engine now properly handles attribute syntax so __declspec and __attribute__ spellings no longer get mismatched). This caused several testcases to need updating for a slightly different wording.
llvm-svn: 205234
Summary:
Declaring a function as inline after it has been defined is in violation
of [dcl.fct.spec]p4. The program would get a strong definition instead
of getting a function with linkonce_odr linkage.
Reviewers: rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3220
llvm-svn: 205129
Charles Li