| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
This reverts commit r205044.
llvm-svn: 205047
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
Responding to Justin's review of r205025.
llvm-svn: 205037
|
| |
|
|
| |
llvm-svn: 205035
|
| |
|
|
|
|
| |
Requested in <rdar://problem/16188740>.
llvm-svn: 205030
|
| |
|
|
| |
llvm-svn: 205025
|
| |
|
|
|
|
|
|
|
|
|
| |
-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
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-u behaviour is apparently not portable between linkers (see cfe-commits
discussions for r204379 and r205012). I've moved the logic to IRGen,
where it should have been in the first place.
I don't have a Linux system to test this on, so it's possible this logic
*still* doesn't pull in the instrumented profiling runtime on Linux.
I'm in the process of getting tests going on the compiler-rt side
(llvm-commits "[PATCH] InstrProf: Add initial compiler-rt test"). Once
we have tests for the full flow there, the runtime logic should get a
whole lot less brittle.
<rdar://problem/16458307>
llvm-svn: 205023
|
| |
|
|
|
|
| |
This reverts commit r205012.
llvm-svn: 205022
|
| |
|
|
| |
llvm-svn: 205021
|
| |
|
|
| |
llvm-svn: 205012
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
#define A \
int i; /*a*/ \
int jjj; /*b*/
After:
#define A \
int i; /*a*/ \
int jjj; /*b*/
llvm-svn: 205011
|
| |
|
|
|
|
| |
Reviewed at http://llvm-reviews.chandlerc.com/D3096
llvm-svn: 205008
|
| |
|
|
| |
llvm-svn: 204998
|
| |
|
|
|
|
| |
We don't want to deviate from clang's standard terminology.
llvm-svn: 204997
|
| |
|
|
| |
llvm-svn: 204990
|
| |
|
|
|
|
|
| |
This should fix the clang-cl tests after the Windows target triple
canonicalization (r204978)
llvm-svn: 204985
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
results, some still have link errors.
llvm-svn: 204974
|
| |
|
|
| |
llvm-svn: 204969
|
| |
|
|
|
|
| |
with non-MSVC compilers.
llvm-svn: 204968
|
| |
|
|
|
|
|
| |
an opt-in option under -Wselector-type-mismatch.
// rdar://16445728
llvm-svn: 204965
|
| |
|
|
|
|
| |
Also, while I'm here, support -nocompress-debug-sections too.
llvm-svn: 204959
|
| |
|
|
| |
llvm-svn: 204955
|
| |
|
|
|
|
|
|
| |
This commit also adds an additional test case for the global destructor warning.
Reviewed in http://llvm-reviews.chandlerc.com/D3205
llvm-svn: 204954
|
| |
|
|
|
|
|
|
| |
irrelevant
Reviewed in http://llvm-reviews.chandlerc.com/D3190
llvm-svn: 204953
|
| |
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
|
|
| |
declarations
Reviewed in http://llvm-reviews.chandlerc.com/D3102
llvm-svn: 204951
|
| |
|
|
|
|
|
| |
Now correctly formats:
foo<true && false>();
llvm-svn: 204950
|
| |
|
|
|
|
| |
for a subprogram DIE.
llvm-svn: 204949
|
| |
|
|
| |
llvm-svn: 204944
|
| |
|
|
|
|
| |
Previously we would only attach comments to the typedef.
llvm-svn: 204942
|
| |
|
|
|
|
|
|
|
| |
cannot be a pointer to the private address space (as clarified
in the OpenCL 1.2 specification).
Patch by Fraser Cormack!
llvm-svn: 204941
|
| |
|
|
|
|
|
| |
r204379 changed the way the profile runtime gets pulled in, but missed
updating non-Darwin targets.
llvm-svn: 204939
|
| |
|
|
| |
llvm-svn: 204938
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
While these might make sense for some rule (e.g. break after multi-line
operand), they generally appear ugly and confusing.
Before:
fffffffffff(R\"x(
multiline raw string literal xxxxxxxxxxxxxx
)x\" + bbbbbb)
After:
fffffffffff(R\"x(
multiline raw string literal xxxxxxxxxxxxxx
)x\" +
bbbbbb)
llvm-svn: 204937
|
| |
|
|
|
|
|
|
|
| |
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
|
| |
|
|
|
|
| |
No functional changes intended.
llvm-svn: 204930
|
| |
|
|
|
|
|
|
| |
Clang-format now correctly formats:
some_type<a * b> v;
template <bool a, bool b> typename enabled_if<a && b>::type f() {}
llvm-svn: 204913
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 204905
|
| |
|
|
|
|
|
|
| |
while I investigate as it seems to be causing issues with the gdb bot.
This reverts commit r204874.
llvm-svn: 204896
|
| |
|
|
|
|
| |
the type of the variable until it's known.
llvm-svn: 204887
|
| |
|
|
|
|
| |
The section __DATA,__data is atomized by the linker and cannot have L symbols.
llvm-svn: 204879
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When parsing MS inline assembly, we note that fpsw is an implicit def of
most x87 FP operations, and add it to the clobber list. However, we
don't recognize fpsw as a gcc register name, and we assert. Clang
always adds an fpsr clobber, which means the same thing to LLVM, so we
can just use that.
This test case was broken by my LLVM change r196939.
Reviewers: echristo
Differential Revision: http://llvm-reviews.chandlerc.com/D2993
llvm-svn: 204878
|
| |
|
|
|
|
|
|
| |
instead of rolling an inefficient version of the function. This
changes some order of emission of metadata nodes, fix up those
testcases and make them more flexible to some changes.
llvm-svn: 204874
|
| |
|
|
| |
llvm-svn: 204872
|