| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
Recommit of r223114, reverted in r223120.
llvm-svn: 224012
|
| |
|
|
| |
llvm-svn: 223999
|
| |
|
|
|
|
|
|
|
|
| |
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
|
| |
|
|
| |
llvm-svn: 223987
|
| |
|
|
|
|
|
| |
Eventually we'll diagnose them on different declarations, but let's
get this part out of the way first.
llvm-svn: 223985
|
| |
|
|
| |
llvm-svn: 223984
|
| |
|
|
|
|
| |
Review feedback from recent changes to GetSVN.cmake.
llvm-svn: 223980
|
| |
|
|
| |
llvm-svn: 223977
|
| |
|
|
|
|
|
|
| |
can change the backend to be the same default. Leave the
modified/new testcases with the exception of the default behavior
since it increases our testing footprint.
llvm-svn: 223976
|
| |
|
|
|
|
|
|
|
|
|
| |
getLVForNamespaceScopeDecl believed that it wasn't possible for it to
ever see an IndirectFieldDecl. However, this can occur when determining
whether or not something is a redeclaration of a member of an anonymous
static union.
This fixes PR21858.
llvm-svn: 223975
|
| |
|
|
|
|
| |
Thanks to Nico Weber for spotting this.
llvm-svn: 223966
|
| |
|
|
| |
llvm-svn: 223937
|
| |
|
|
|
|
| |
No functional changes intended.
llvm-svn: 223936
|
| |
|
|
|
|
|
| |
NS_ENUM/NS_OPTIONS use the underlying type if there is
no associated type. rdar://19198042
llvm-svn: 223934
|
| |
|
|
|
|
|
| |
They are against the LLVM coding conventions. No functional changes
intended.
llvm-svn: 223930
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
arithmetic relaxation flags:
-cl-no-signed-zeros
-cl-unsafe-math-optimizations
-cl-finite-math-only
-cl-fast-relaxed-math
Propagate the info to FP instruction flags as well
as function attributes where they are available.
llvm-svn: 223928
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This is a temporary workaround while MIPS64 has not yet fully supported
128-bit integers. But declaration of int128 type is necessary even though
`__SIZEOF_INT128__` is undefined because c++ standard header files like
`limits` throw error message if `__int128` is not available.
Patch by Sagar Thakur.
Differential Revision: http://reviews.llvm.org/D6402
llvm-svn: 223927
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Original commit message:
[modules] Add experimental -fmodule-map-file-home-is-cwd flag to -cc1.
For files named by -fmodule-map-file=, and files found by 'extern module'
directives, this flag specifies that we should resolve filenames relative to
the current working directory rather than relative to the directory in which
the module map file resides. This is aimed at fixing path handling, in
particular for relative -I paths, when building modules that represent
components of the current project (rather than libraries installed on the
current system, which the current project has as dependencies, where we'd
typically expect the module map files to be looked up implicitly).
llvm-svn: 223913
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
To ensure that we don't import duplicates, the ASTImporter often
checks the DeclContext for a Decl before importing it to see if
a Decl with the same name is already present.
This is problematic if the Decl is inside a transparent context
like an extern "C" block. Lookup isn't allowed on such contexts,
and in fact they assert() if you do that. So instead we look at
the redeclaration context -- the containing context that can be
used safely for these kinds of checks -- instead.
llvm-svn: 223912
|
| |
|
|
|
|
| |
variable array type.
llvm-svn: 223902
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
SourceLocations. LLDB rarely has the same files
mapped into the target AST context as the source
AST context, so the ASTImporter shouldn't expect
to see those files there.
This started to become a problem when importing
entities from modules -- these have proper source
locations, in contrast to all the ASTs LLDB
creates which have empty ones.
llvm-svn: 223900
|
| |
|
|
| |
llvm-svn: 223897
|
| |
|
|
|
|
|
| |
Especially relevant to ASan when dealing with complex expressions
containing multiple array accesses. See PR21737.
llvm-svn: 223872
|
| |
|
|
| |
llvm-svn: 223871
|
| |
|
|
|
|
|
|
| |
This way, the step generating SVNVersion.inc gets rerun every time someone
changes GetSVN.cmake (which is the file that decides how the contents of
SVNVersion.inc look). This makes hacking on GetSVN.cmake a bit easier.
llvm-svn: 223861
|
| |
|
|
|
|
|
|
|
| |
LinkageSpecDecls. This is relevant when LLDB
wants to import Decls from non-C++ modules,
since many declarations are in extern "C"
blocks.
llvm-svn: 223860
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
in debugger mode) to accept @import declarations
and pass them to the debugger.
In the preprocessor, accept import declarations
if the debugger is enabled, but don't actually
load the module, just pass the import path on to
the preprocessor callbacks.
In the Objective-C parser, if it sees an import
declaration in statement context (usual for LLDB),
ignore it and return a NullStmt.
llvm-svn: 223855
|
| |
|
|
| |
llvm-svn: 223854
|
| |
|
|
|
|
|
|
| |
Zero sized objects may overlap with each other or any other object.
This fixes PR21786.
llvm-svn: 223852
|
| |
|
|
|
|
|
| |
property-dot-syntax when receiver is 'super'.
rdar://19140267
llvm-svn: 223846
|
| |
|
|
| |
llvm-svn: 223842
|
| |
|
|
| |
llvm-svn: 223839
|
| |
|
|
| |
llvm-svn: 223835
|
| |
|
|
| |
llvm-svn: 223828
|
| |
|
|
|
|
| |
Especially useful for sanitizer reports.
llvm-svn: 223825
|
| |
|
|
| |
llvm-svn: 223814
|
| |
|
|
|
|
| |
Match LLVM API changes from r223802.
llvm-svn: 223803
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
basic microarchitecture names, and add support (with tests) for parsing
all of the masic microarchitecture names for CPUs documented to be
accepted by GCC with -march. I didn't go back through the 32-bit-only
old microarchitectures, but this at least brings the recent architecture
names up to speed. This is essentially the follow-up to the LLVM commit
r223769 which did similar cleanups for the LLVM CPUs.
One particular benefit is that you can now use -march=westmere in Clang
and get the LLVM westmere processor which is a different ISA variant (!)
and so quite significant.
Much like with r223769, I would appreciate the Intel folks carefully
thinking about the macros defined, names used, etc for the atom chips
and newest primary x86 chips. The current patterns seem quite strange to
me, especially here in Clang.
Note that I haven't replicated the per-microarchitecture macro defines
provided by GCC. I'm really opposed to source code using these rather
than using ISA feature macros.
llvm-svn: 223776
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit r223753. It broke the Green Dragon build for a few
hours:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/2259/
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/2259/consoleFull#43901905849ba4694-19c4-4d7e-bec5-911270d8a58c
I suspect `clang-tools-extra` just needs a follow-up for an API change,
but I'm not the right one to look into it.
llvm-svn: 223759
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
For files named by -fmodule-map-file=, and files found by 'extern module'
directives, this flag specifies that we should resolve filenames relative to
the current working directory rather than relative to the directory in which
the module map file resides. This is aimed at fixing path handling, in
particular for relative -I paths, when building modules that represent
components of the current project (rather than libraries installed on the
current system, which the current project has as dependencies, where we'd
typically expect the module map files to be looked up implicitly).
llvm-svn: 223753
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
elements
This particularly helps the fidelity of ASan reports (which can occur
even in these examples - if, for example, one uses placement new over a
buffer of insufficient size - now ASan will correctly identify which
member's initialization went over the end of the buffer).
This doesn't cover all types of members - more coming.
llvm-svn: 223726
|
| |
|
|
|
|
| |
complain that the contained modules are defined twice.
llvm-svn: 223724
|
| |
|
|
|
|
|
|
| |
This reverts commit r223455. It's been succesfully argued that
-fexceptions (at the driver level) is a misnomer and has little to do
with -fobjc-exceptions.
llvm-svn: 223723
|
| |
|
|
|
|
|
| |
Includes a new test case since none of the existing tests were hitting
this code path.
llvm-svn: 223705
|
| |
|
|
|
|
| |
of the assignment expression
llvm-svn: 223699
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This only applies when not aligning after the return itself (which is
commonly done for C++.
Before:
return aaaaaaaaaa
? bbbbbbbbbb(
bbbbbb) // This is indented relative to aaaaaaaaaa.
: b;
After:
return aaaaaaaaaa
? bbbbbbbbbb(
bbbbbb)
: b;
llvm-svn: 223694
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Before:
@Mock DataLoader loooooooooooooooooooooooader =
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;
After:
@Mock
DataLoader loooooooooooooooooooooooader =
aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa;
llvm-svn: 223688
|
| |
|
|
|
|
|
|
| |
The logic for lowering profiling counters has been moved to an LLVM
pass. Emit the intrinsics rather than duplicating the whole pass in
clang.
llvm-svn: 223683
|
| |
|
|
|
|
|
|
|
|
| |
Before:
auto next_pair = [](A * a) -> pair<A*, A*>{};
After:
auto next_pair = [](A* a) -> pair<A*, A*>{};
llvm-svn: 223652
|
| |
|
|
|
|
|
|
| |
considers the sign to be.
Should fix the clang-hexagon-elf bot.
llvm-svn: 223642
|