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
A redeclaration may not add dllimport or dllexport attributes. dllexport is
sticky and can be omitted on redeclarations while dllimport cannot.
llvm-svn: 205197
Clean up the __has_attribute implementation without modifying its behavior.
Replaces the tablegen-driven AttrSpellings.inc, which lived in the lexing layer with AttrHasAttributeImpl.inc, which lives in the basic layer. Updates the preprocessor to call through to this new functionality which can take additional information into account (such as scopes and syntaxes).
Expose the ability for parts of the compiler to ask whether an attribute is supported for a given spelling (including scope), syntax, triple and language options.
llvm-svn: 205181
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
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
llvm-svn: 205100
Taking a hint from -Wparentheses, use an extra '()' as a sigil that
a dead condition is intentionally dead. For example:
if ((0)) { dead }
When this sigil is found, do not emit a dead code warning. When the
analysis sees:
if (0)
it suggests inserting '()' as a Fix-It.
llvm-svn: 205069
Committed this by accident before it was done last time.
Original message:
Rather than rolling our own functions to read little endian data
from a buffer, we can use the support in llvm's Endian.h.
No functional change.
llvm-svn: 205062
Committed this by accident before it was done last time.
Original message:
Rather than rolling our own functions to write little endian data
to an ostream, we can use the support in llvm's EndianStream.h.
No functional change.
llvm-svn: 205061
Rather than rolling our own functions to read little endian data from
a buffer, we can use the support in llvm's Endian.h.
No functional change.
llvm-svn: 205045
Rather than rolling our own functions to write little endian data to
an ostream, we can use the support in llvm's EndianStream.h.
No functional change.
llvm-svn: 205044
-Wselector-type-mismatch default again. After
internal discussions, we think that in most cases
it has helped our developers find hard to detect
undefined behaviors. We are going to provide a syntax
(and fix-it) to suppress the warning in remaining of
false positive cases.
llvm-svn: 205024
This follows the LLVM change to canonicalise the Windows target triple
spellings. Rather than treating each Windows environment as a single entity,
the environments are now modelled properly as an environment. This is a
mechanical change to convert the triple use to reflect that change.
llvm-svn: 204978
Replaces the tablegen-driven AttrSpellings.inc, which lived in the lexing layer with AttrHasAttributeImpl.inc, which lives in the basic layer. Updates the preprocessor to call through to this new functionality which can take additional information into account (such as scopes and syntaxes).
Expose the ability for parts of the compiler to ask whether an attribute is supported for a given spelling (including scope), syntax, triple and language options.
llvm-svn: 204952
correctly order comments in SourceManager::isBeforeInTranslationUnit() order
Unfortunately, this is not as simple as it was implemented previously, and
actually requires doing a merge sort.
llvm-svn: 204936
This produces valid IR now that llvm rejects aliases to weak aliases and warns
the user that the resolution is not changed if the weak alias is overridden.
llvm-svn: 204935
Store the number of clauses and children of OMPExecutableDirective and dynamically compute the locations of corresponding arrays.
http://llvm-reviews.chandlerc.com/D2977
llvm-svn: 204933
These don't seem to have any real point. Let's start with
IndexingContext. I can't come up with any conceivable reason to have
many hundereds of thousands of these alive in an address space which
would make the 4x difference in allocated (but unused) memory for the
string scratch buffer a significant memory usage problem.
The EditedSource one is somewhat more surprising. This is an 8x increase
in the memory allocated (but not used) per editted source file. However,
for this to realistically be a problem, you would need to have over half
a million editted source files in a single address space, and even that
would only really have problems on 32-bit Windows where you really only
have 2gb of virtual address space. And what's more important, the fix to
this if it is actually an issue shouldn't be to shrink the allocator's
size, it is to pass a single allocator into *many* edited source file
objects and let them share the memory.
These were the only two uses of custom sized BumpPtrAllocators
(excluding ones in the JIT using a custom allocation strategy) in all of
LLVM, Clang, LLD, LLDB, or Polly. I don't think we actually need this
complexity in the primary BumpPtrAllocator at all and am planning to
remove it.
llvm-svn: 204910
The main difference between __va_start and __builtin_va_start is that
the address of the va_list has already been taken, and the va_list is
always a char*.
__va_end and __va_arg are not needed.
llvm-svn: 204821
Alexey Samsonov