| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
| |
llvm-svn: 220644
|
|
|
|
| |
llvm-svn: 220640
|
|
|
|
| |
llvm-svn: 220639
|
|
|
|
|
|
|
| |
Refactor the path search into a helper function to avoid duplicating the path
handling for the search. NFC.
llvm-svn: 220628
|
|
|
|
|
|
|
|
|
| |
Rather than asserting that the target is unsupported, make a guess at what the
tree for a port would look like and use that for the search path.
Addresses review comments from Ried Kleckner for SVN r220547.
llvm-svn: 220624
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
We would crash because we used operator[] to access past the end of a
SmallString. This occured because our token had length zero.
Instead, form the pointer using .data() and arithmetic. This is safe
because this forms a one-past-the-end pointer and it is only used to
compare with another one-past-the-end pointer.
This fixes PR21379.
llvm-svn: 220614
|
|
|
|
| |
llvm-svn: 220609
|
|
|
|
|
|
|
|
|
|
|
| |
The MS linker cannot do anything interesting with these, it doesn't make
sense to emit them.
This fixes PR21373.
Differential Revision: http://reviews.llvm.org/D5986
llvm-svn: 220595
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Avoid an assertion when materializing a lifetime type aggregate temporary. When
performing CodeGen for ObjC++, we could generate a lifetime-only aggregate
temporary by using an initializer list (which is effectively an array). We
would reach through the temporary expression, fishing out the inner expression.
If this expression was a lifetime expression, we would attempt to emit this as a
scalar. This would eventually result in an assertion as the emission would
eventually assert that the expression being emitted has a scalar evaluation
kind.
Add a case to handle the aggregate expressions. Use the EmitAggExpr to emit the
aggregate expression rather than the EmitScalarInit.
Addresses PR21347.
llvm-svn: 220590
|
|
|
|
| |
llvm-svn: 220589
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Template template parameters weren't added to the list of substitutions.
This would make the substitution map contain inaccurate mappings,
leading to Clang violating the Itanium ABI and breaking compatibility
with GCC.
This fixes PR21351.
Differential Revision: http://reviews.llvm.org/D5959
llvm-svn: 220588
|
|
|
|
|
|
| |
Switch to a range-based for loop. NFC.
llvm-svn: 220587
|
|
|
|
|
|
|
|
| |
This fixes a corner-case where __uuidof as a template argument would
result in us trying to emit a GLValue as an RValue. This would lead to
a crash down the road.
llvm-svn: 220585
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Wire it through everywhere we have support for fastcall, essentially.
This allows us to parse the MSVC "14" CTP headers, but we will
miscompile them because LLVM doesn't support __vectorcall yet.
Reviewed By: Aaron Ballman
Differential Revision: http://reviews.llvm.org/D5808
llvm-svn: 220573
|
|
|
|
| |
llvm-svn: 220572
|
|
|
|
|
|
| |
The control flow and ownership is weird enough so unique_ptr doesn't help here :(
llvm-svn: 220569
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This allows us to easily identify them in the backend which in turn allows us
to handle them correctly for big-endian targets (where they must be shifted
into the upper bits of the register).
Depends on D5961
Reviewers: atanasyan
Reviewed By: atanasyan
Subscribers: cfe-commits, theraven
Differential Revision: http://reviews.llvm.org/D5962
llvm-svn: 220566
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Ensure all integral/enumeration types are appropriately annotated with
signext/zeroext. In particular, i32 now has these attributes when using the
N32/N64 ABI. This paves the way for accurately representing the way the
N32/N64 ABI's promotes integer arguments to i64.
Reviewers: atanasyan
Reviewed By: atanasyan
Subscribers: cfe-commits, theraven
Differential Revision: http://reviews.llvm.org/D5961
llvm-svn: 220563
|
|
|
|
|
|
|
|
|
|
|
| |
This fixes a crash in the RecursiveASTVisitor on such code
__typeof__(struct F*) var[invalid];
The UnderlyingTInfo of a TypeOfTypeLoc was left uninitialized when
created from ASTContext::getTrivialTypeSourceInfo
This lead to a crash in RecursiveASTVisitor when trying to access it.
llvm-svn: 220562
|
|
|
|
| |
llvm-svn: 220560
|
|
|
|
| |
llvm-svn: 220559
|
|
|
|
|
|
| |
paths. Fixed PR14620.
llvm-svn: 220557
|
|
|
|
|
|
|
|
| |
'char' is unsigned on all ARM and Thumb architectures. Clang gets this
right for ARM, and for thumb when using and arm triple and the -mthumb
option, but gets it wrong for thumb triples. This fixes that.
llvm-svn: 220555
|
|
|
|
|
|
| |
clang::Stmt::printPretty().
llvm-svn: 220549
|
|
|
|
| |
llvm-svn: 220547
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This is a very basic toolchain. It supports cross-compiling Windows (primarily
inspired by the WoA target). It is meant to use clang with the LLVM IAS and a
binutils ld-compatible interface for the linker (eventually to be lld). It does
not perform any "standard" GCC lookup, nor does it perform any special
adjustments given that it is expected to be used in an environment where the
user is using MSVCRT (and as such Visual Studio headers) and the Windows SDK.
The primary runtime library is expected to be compiler-rt and the C++
implementation to be libc++.
It also expects that a sysroot has been setup given the usual Unix semantics
(standard C headers in /usr/include, all the import libraries available in
/usr/lib). It also expects that an entry point stub is present in /usr/lib
(crtbegin.obj for executables, crtbeginS.obj for shared libraries).
The entry point stub is responsible for running any GNU constructors.
llvm-svn: 220546
|
|
|
|
| |
llvm-svn: 220543
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(PR21355)
Clang would previously assert on the following code when targeting MinGW:
struct __declspec(dllimport) S {
virtual ~S();
};
S::~S() {}
Because ~S is a key function and the class is dllimport, we would try to emit a
strong definition of the vtable, with dllimport - which is a conflict. We
should not emit strong vtable definitions for imported classes.
Differential Revision: http://reviews.llvm.org/D5944
llvm-svn: 220532
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently, when --serialize-diagnostics is passed this only includes
the diagnostics from clang -cc1, and driver diagnostics are
dropped. This causes issues for tools that use the serialized
diagnostics, since stderr is lost and these diagnostics aren't seen at
all.
We handle this by merging the diagnostics from the CC1 process and the
driver diagnostics into a single file when the driver invokes CC1.
Fixes rdar://problem/10585062
llvm-svn: 220525
|
|
|
|
|
|
| |
against changes to record order.
llvm-svn: 220524
|
|
|
|
|
|
| |
change.
llvm-svn: 220521
|
|
|
|
|
|
|
|
|
|
| |
Before:
bool a = 2 <::SomeFunction();
After:
bool a = 2 < ::SomeFunction();
llvm-svn: 220505
|
|
|
|
|
|
| |
clangAST.
llvm-svn: 220502
|
|
|
|
|
|
|
|
| |
nonnull attribute when comparison is always
true/false. Patch by Steven Wu with few fixes and minor
refactoring and adding tests by me. rdar://18712242
llvm-svn: 220496
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Since the order of the IDs in the AST file (e.g. DeclIDs, SelectorIDs)
is not stable, it is not safe to load an AST file that depends on
another AST file that has been rebuilt since the importer was built,
even if "nothing changed". We previously used size and modtime to check
this, but I've seen cases where a module rebuilt quickly enough to foil
this check and caused very hard to debug build errors.
To save cycles when we're loading the AST, we just generate a random
nonce value and check that it hasn't changed when we load an imported
module, rather than actually hash the whole file.
This is slightly complicated by the fact that we need to verify the
signature inside addModule, since we might otherwise consider that a
mdoule is "OutOfDate" when really it is the importer that is out of
date. I didn't see any regressions in module load time after this
change.
llvm-svn: 220493
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
variable definitions.
The previous IR representation used the non-lexical decl context, which
placed the definitions in the same scope as the declarations (ie: within
the class) - this was hidden by the fact that LLVM currently doesn't
respect the context of global variable definitions at all, and always
puts them at the top level (as direct children of the compile_unit).
Having the correct lexical scope improves source fidelity and simplify
backend global variable emission (with changes coming shortly).
Doing something similar for non-member global variables would help
simplify/cleanup things further (see FIXME in the commit) and provide
similar source fidelity benefits to the final debug info.
llvm-svn: 220488
|
|
|
|
|
|
|
|
|
| |
This was not a real header role, and was never exposed to clients of ModuleMap.
Remove the enumeration value for it and track it as marking the header as
'known' rather than creating an extra KnownHeader entry that *every single*
client ignores.
llvm-svn: 220460
|
|
|
|
| |
llvm-svn: 220456
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
-nostdlib/-nodefaultlibs is provided.
This is a sad thing to do, but all the alternatives look ugly.
Looks like there are legitimate cases when users may want to link
with sanitizer runtimes *and* -nodefaultlibs (and ensure they provide
replacements for system libraries). For example, this happens in libc++
test suite.
"-nodefaultlibs" is told to link only the libraries explicitly provided
by the user, and providing "-fsanitize=address" is a clear indication of
intention to link with ASan runtime.
We can't easily introduce analogue of "-print-libgcc-name": linking with
sanitizers runtimes is not trivial: some runtimes are split into several
archive libraries, which are required to be wrapped in
-whole-archive/-no-whole-archive.
If "-fsanitize=whatever" and "-nodefaultlibs" are provided, system library
dependencies of sanitizer runtimes (-lc/-ldl/-lpthread/-lrt) will *not* be
linked, and user would have to link them in manually. Note that this can
cause problems, as failing to provide "-lrt" might lead to crashes in runtime
during ASan initialization. But looks like we should bite this bullet.
See r218541 review thread for the discussion.
llvm-svn: 220455
|
|
|
|
|
|
|
|
| |
This allows a module to specify that it logically contains a file, but that
said file is non-modular and intended for textual inclusion. This allows
layering checks to work properly in the presence of such files.
llvm-svn: 220448
|
|
|
|
| |
llvm-svn: 220434
|
|
|
|
|
|
| |
This fixes PR21337.
llvm-svn: 220429
|
|
|
|
|
|
| |
their only use was with the AST reader, and friendship can be used to handle that. Drive-by rename of "Brac" to "Brace" for the private data members. NFC.
llvm-svn: 220428
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
When a user has not configured a standard Visual Studio environment
by running vcvarsall, clang tries its best to find Visual Studio
include files and executables anyway. This patch makes clang also
try to find system and Windows SDK libraries for linking against,
as well.
Reviewed by: Hans Wennborg
Differential Revision: http://reviews.llvm.org/D5873
llvm-svn: 220425
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This resubmits change r220226. That change broke the chromium
build bots because chromium it ships an hermetic MSVC toolchain
that it expects clang to fallback to by finding it on the path.
This patch fixes the issue by bumping up the prioritization of PATH
when looking for MSVC binaries.
Reviewed by: Hans Wennborg, Reid Kleckner
Differential Revision: http://reviews.llvm.org/D5892
llvm-svn: 220424
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
Add support for profiling the matchers used.
This will be connected with clang-tidy to generate a report to determine
and debug slow checks.
Reviewers: alexfh
Subscribers: klimek, cfe-commits
Differential Revision: http://reviews.llvm.org/D5911
llvm-svn: 220418
|
|
|
|
|
|
| |
Patch by Brad King!
llvm-svn: 220413
|
|
|
|
|
|
|
|
|
|
|
| |
It's not clear how this would be tested - I imagine we should have an
ASTImporter test that RAVs the new AST and checks that all the elements
in it are from this ASTContext and not the foreign one... but I know
little about the ASTImporter and how/where that testing might be done.
(post-commit review feedback from Richard Smith on r219900)
llvm-svn: 220411
|
|
|
|
|
|
|
| |
I haven't done any actual impact analysis of this change as it's a
strict improvement, but I'd be curious to know how much it helps.
llvm-svn: 220408
|
|
|
|
|
|
|
|
|
| |
SanitizerBlacklist.
This also handles the case where function name (not its body)
is obtained from macro expansion.
llvm-svn: 220407
|