| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
|
|
| |
Fixes PR16292.
llvm-svn: 184581
|
| |
|
|
| |
llvm-svn: 184578
|
| |
|
|
| |
llvm-svn: 184577
|
| |
|
|
|
|
| |
Make that option the default for LLVM style.
llvm-svn: 184563
|
| |
|
|
|
|
|
|
|
|
| |
Per review from Anna, this really should have been two commits, and besides
it's causing problems on our internal buildbot. Reverting until these have
been worked out.
This reverts r184511 / 98123284826bb4ce422775563ff1a01580ec5766.
llvm-svn: 184561
|
| |
|
|
|
|
|
|
|
| |
a system module.
This prevents -pedantic from causing warnings in the system headers
used to create modules. Fixes <rdar://problem/14201171>.
llvm-svn: 184560
|
| |
|
|
| |
llvm-svn: 184559
|
| |
|
|
|
|
| |
the right polymorphic overload to use.
llvm-svn: 184558
|
| |
|
|
|
|
|
| |
MSVC's debug runtime prints assertion failures in wide characters, which
gtest doesn't understand.
llvm-svn: 184544
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Itanium destroys them in the caller at the end of the full expression,
but MSVC destroys them in the callee. This is further complicated by
the need to emit EH-only destructor cleanups in the caller.
This should help clang compile MSVC's debug iterators more correctly.
There is still an outstanding issue in PR5064 of a memcpy emitted by the
LLVM backend, which is not correct for C++ records.
Fixes PR16226.
Reviewers: rjmccall
Differential Revision: http://llvm-reviews.chandlerc.com/D929
llvm-svn: 184543
|
| |
|
|
| |
llvm-svn: 184538
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
and add '[def]' for non-decl tag types
This is to make test cases looking for definitions more legible by
making the definition explicit rather than just the absence of '[fwd]'.
This allowed the debug-info-record tests to be rephrased - and in the
interests of reducing the number of individual test cases/invocations we
have, I merged them into one file, separated them with namespaces (&
then moved them to C++ because namespaces are great). If they need to
remain 'C' only tests, they can be moved back. (I didn't group them with
'debug-info-class.cpp' because these tests only apply to
-fno-limit-debug-info)
I removed the pieces of code that would cause these tests to pass under
-flimit-debug-info to ensure the tests remain relevant to their fixes
should we ever improve -flimit-debug-info to catch that kind of code.
This commit is version locked with the corresponding change to
DebugInfo.h in LLVM. Except some transient buildbot fallout.
llvm-svn: 184524
|
| |
|
|
| |
llvm-svn: 184520
|
| |
|
|
| |
llvm-svn: 184519
|
| |
|
|
| |
llvm-svn: 184518
|
| |
|
|
| |
llvm-svn: 184517
|
| |
|
|
| |
llvm-svn: 184516
|
| |
|
|
| |
llvm-svn: 184515
|
| |
|
|
| |
llvm-svn: 184512
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Certain expressions can cause a constructor invocation to zero-initialize
its object even if the constructor itself does no initialization. The
analyzer now handles that before evaluating the call to the constructor,
using the same "default binding" mechanism that calloc() uses, rather
than simply ignoring the zero-initialization flag.
As a bonus, trivial default constructors are now no longer inlined; they
are instead processed explicitly by ExprEngine. This has a (positive)
effect on the generated path edges: they no longer stop at a default
constructor call unless there's a user-provided implementation.
<rdar://problem/14212563>
llvm-svn: 184511
|
| |
|
|
|
|
| |
No functionality change.
llvm-svn: 184510
|
| |
|
|
|
|
|
|
|
|
|
| |
This just seems a bit tidier/more principled. Based on a patch provided
by Adrian - with the only minor tweak that it needed to use
"getTypeOrNull" rather than "getCompletedTypeOrNull" since we don't
store declarations in the CompletedTypes cache.
No intended functionality change.
llvm-svn: 184509
|
| |
|
|
| |
llvm-svn: 184505
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
As an optimization, we only kept declared methods with distinct
signatures in the global method pool, to keep the method lists
small. Under modules, however, one could have two different methods
with the same signature that occur in different (sub)modules. If only
the later submodule is important, message sends to 'id' with that
selector would fail because the first method (the only one that got
into the method pool) was hidden. When building a module, keep *all*
of the declared methods.
I did a quick check of both module build time and uses of modules, and
found no performance regression despite this causing us to keep more
methods in the global method pool. Fixes <rdar://problem/14148896>.
llvm-svn: 184504
|
| |
|
|
|
|
| |
(FixIts yet to be tested.)
llvm-svn: 184503
|
| |
|
|
| |
llvm-svn: 184501
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
directory for programs used by the driver is actually the standard
behavior we want to be compatible with GCC cross compilers -- it isn't
specific to SUSE or any other distro.
Also start fleshing out testing of the different cross compilation
patterns, both with a new very bare-bones tree of cross compilers and by
extending the multilib trees. Currently, we don't correctly model doing
a cross compile using the non-triple target of a bi-arch GCC install,
but I'll add support for that (and tests) next.
llvm-svn: 184499
|
| |
|
|
| |
llvm-svn: 184498
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
checked-arithmetic in c.
This will enable users in security critical applications to perform
checked-arithmetic in a fast safe manner that is amenable to c.
Tests/an update to Language Extensions is included as well.
rdar://13421498.
llvm-svn: 184497
|
| |
|
|
| |
llvm-svn: 184496
|
| |
|
|
| |
llvm-svn: 184495
|
| |
|
|
| |
llvm-svn: 184494
|
| |
|
|
| |
llvm-svn: 184493
|
| |
|
|
|
|
|
| |
operations in the case where evaluating a subexpression fails. No functionality
change, but test/Sema/many-logical-ops.c gets ~100x faster with this change.
llvm-svn: 184489
|
| |
|
|
|
|
| |
This is needed to parse libstdc++ 4.7's type_traits, see PR13530.
llvm-svn: 184476
|
| |
|
|
|
|
|
|
|
|
| |
r174939-40 caused us to do this in the canonical terminate lpad,
but when the EH stack has other cleanups on it we use the
terminate handler block, which wasn't doing this.
Fixes the rest of rdar://11904428 given appropriate stdlib support.
llvm-svn: 184475
|
| |
|
|
|
|
|
|
|
|
| |
limited debug info.
This is another small addendum to r184252.
rdar://problem/14101097
llvm-svn: 184473
|
| |
|
|
| |
llvm-svn: 184472
|
| |
|
|
|
|
|
| |
headers may be included from within the module, but not from outside
the module.
llvm-svn: 184471
|
| |
|
|
| |
llvm-svn: 184470
|
| |
|
|
| |
llvm-svn: 184466
|
| |
|
|
| |
llvm-svn: 184465
|
| |
|
|
| |
llvm-svn: 184463
|
| |
|
|
|
|
|
|
|
|
| |
The simplify-libcalls pass has been removed from LLVM. Thus
'PMBuilder.DisableSimplifyLibCalls' does not exist anymore.
The disabling/enabling of library call simplifications is
done through the TargetLibraryInfo which is already wired
up in Clang.
llvm-svn: 184458
|
| |
|
|
| |
llvm-svn: 184454
|
| |
|
|
| |
llvm-svn: 184453
|
| |
|
|
|
|
| |
to be confused by strange (& currently broken) Windows ABI
llvm-svn: 184442
|
| |
|
|
|
|
|
|
|
|
| |
On Windows, it looks like FlagIndirectVariable is being set in Flags for
DIBuilder::createLocalVariable(), giving us an i32 of 8192 instead of 0,
as on Linux.
Fixes breakage from r184367.
llvm-svn: 184438
|
| |
|
|
| |
llvm-svn: 184432
|
| |
|
|
|
|
|
|
|
| |
- Added conversion routines and checks in Matcher<T> that take a DynTypedMatcher.
- Added type information on the error messages for the marshallers.
- Allows future work on Polymorphic/overloaded matchers. We should be
able to disambiguate at runtime and choose the appropriate overload.
llvm-svn: 184429
|