| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
|
|
|
|
|
| |
statement.
A little test case simplification - this could be simplified further,
though there are certainly interesting connections to the if/else
construct so I'm hesitant to remove that entirely though it does appear
somewhat unrelated.
(similar fix to r215766, related to PR19864)
llvm-svn: 215768
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
loop, to the start of the loop.
This avoids debuggers stepping to strange places (like the last
statement in the loop body, or the first statement in the if).
This is not the whole answer, though - similar bugs no doubt exist in
other loops (patches to follow) and attributing exception handling code
to the correct line is also tricky (based on the previous fix to
PR19864, exception handling is still erroneously attributed to the 'if'
line).
llvm-svn: 215766
|
|
|
|
| |
llvm-svn: 215764
|
|
|
|
|
|
| |
They can be compared for identity.
llvm-svn: 215745
|
|
|
|
| |
llvm-svn: 215738
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It fits better with LLVM's memory model to try to do this in the
backend. Specifically, narrowing wide loads in the backends should be
relatively straightforward and is generally valuable, whereas widening
loads tends to be very constrained.
Discussion here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20140811/112581.html
This reverts commit r215614.
llvm-svn: 215648
|
|
|
|
|
|
| |
auroraux.org is not resolving.
llvm-svn: 215644
|
|
|
|
|
|
| |
address spaces.
llvm-svn: 215629
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Currently when laying out bitfields that don't need any padding, we
represent them as a wide enough int to contain all of the bits. This
can be hard on the backend since we'll do things like represent stores
to a few bits as loading an i144, masking it with a large constant,
and storing it back.
This turns up in less pathological cases where we load and mask 64 bit
word on a 32 bit platform when we actually only need to access 32 bits.
This leads to bad code being generated in most of our 32 bit backends.
In practice, there are often natural breaks in bitfields, and it's a
fairly simple and effective heuristic to split these fields into legal
integer sized chunks when it will be equivalent (ie, it won't force us
to add any extra padding).
llvm-svn: 215614
|
|
|
|
| |
llvm-svn: 215606
|
|
|
|
|
|
|
|
| |
recursively within the emission of another inline function. This ultimately
led to us emitting the same inline function definition twice, which we then
rejected because we believed we had a mangled name conflict.
llvm-svn: 215579
|
|
|
|
| |
llvm-svn: 215571
|
|
|
|
| |
llvm-svn: 215569
|
|
|
|
| |
llvm-svn: 215568
|
|
|
|
|
|
| |
Modifications made by clang-tidy with minor tweaks.
llvm-svn: 215557
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds a runtime check verifying that functions
annotated with "returns_nonnull" attribute do in fact return nonnull pointers.
It is based on suggestion by Jakub Jelinek:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20140623/223693.html.
Test Plan: regression test suite
Reviewers: rsmith
Reviewed By: rsmith
Subscribers: cfe-commits
Differential Revision: http://reviews.llvm.org/D4849
llvm-svn: 215485
|
|
|
|
|
|
|
|
| |
variable in block is over-aligned with an align
attribute causing block metadata size not be multiple
of alignment. rdar://17878679
llvm-svn: 215449
|
|
|
|
|
|
|
|
| |
DW_TAG_unspecified_parameter.
Fixes rdar://13690847
llvm-svn: 215423
|
|
|
|
|
|
| |
use microsoft's ABI
llvm-svn: 215371
|
|
|
|
| |
llvm-svn: 215365
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
unique_ptr around a non-owning raw_ostream in CodeGenAction::CreateASTConsumer"
It cannot be compiled on Visual Studio 2012.
clang\include\clang/Frontend/CompilerInstance.h(153):
error C2248: 'std::unique_ptr<_Ty>::unique_ptr' : cannot access private member declared in class 'std::unique_ptr<_Ty>'
with
[
_Ty=llvm::raw_ostream
]
D:\Program Files (x86)\Microsoft Visual Studio 11.0\VC\include\memory(1447) : see declaration of 'std::unique_ptr<_Ty>::unique_ptr'
with
[
_Ty=llvm::raw_ostream
]
This diagnostic occurred in the compiler generated function 'clang::CompilerInstance::OutputFile::OutputFile(const clang::CompilerInstance::OutputFile &)'
llvm-svn: 215346
|
|
|
|
|
|
| |
a non-owning raw_ostream in CodeGenAction::CreateASTConsumer
llvm-svn: 215331
|
|
|
|
|
|
| |
that's causing GCC on some buildbots some confusion.
llvm-svn: 215327
|
|
|
|
|
|
|
|
| |
After post-commit review and community discussion, this seems like a
reasonable direction to continue, making ownership semantics explicit in
the source using the type system.
llvm-svn: 215323
|
|
|
|
|
|
| |
Differential Revision: http://reviews.llvm.org/D4799
llvm-svn: 215258
|
|
|
|
|
|
|
|
|
|
|
|
| |
the debug info argument numbering.
Due to the possible presence of return-by-out parameters, using the LLVM
argument number count when numbering debug info arguments can end up
off-by-one. This could produce two arguments with the same number, which
would in turn cause LLVM to emit only one of those arguments (whichever
it found last) or assert (r215157).
llvm-svn: 215227
|
|
|
|
|
|
|
|
|
| |
MSVC doesn't decide what the inheritance model for a returned member
pointer *until* a call expression returns it.
This fixes PR20017.
llvm-svn: 215164
|
|
|
|
|
|
|
|
| |
There are no vtable offset offsets in the MS ABI, but vbtable offsets
are analogous. There are no consumers of this information yet, but at
least we don't crash now.
llvm-svn: 215149
|
|
|
|
|
|
|
| |
to use non-retain/autorelease API variants of ObjC objects. wip.
rdar://17554063
llvm-svn: 215146
|
|
|
|
|
|
|
|
|
| |
This reverts commit r215137.
This doesn't work at all, an offset-offset is probably different than an
offset. I'm scared that this passed our normal test suite.
llvm-svn: 215141
|
|
|
|
|
|
|
|
|
| |
This fixes an assertion when generating full debug info in the MS ABI
for classes with virtual bases.
Fixes PR20579.
llvm-svn: 215137
|
|
|
|
|
|
|
| |
for Objective-C's array and dictionary literals.
rdar://17554063. This is wip.
llvm-svn: 214983
|
|
|
|
|
|
|
|
|
| |
to instruct the code generator to not enforce a higher alignment
than the given number (of bytes) when accessing memory via an opaque
pointer or reference. Patch reviewed by John McCall (with post-commit
review pending). rdar://16254558
llvm-svn: 214911
|
|
|
|
| |
llvm-svn: 214869
|
|
|
|
|
|
|
| |
int __declspec(align(16)) foo; is a tentative definition but the storage
for that variable should not have CommonLinkage.
llvm-svn: 214828
|
|
|
|
|
|
| |
It was always set to ".", which was duplicated in a few places.
llvm-svn: 214792
|
|
|
|
| |
llvm-svn: 214786
|
|
|
|
| |
llvm-svn: 214759
|
|
|
|
| |
llvm-svn: 214758
|
|
|
|
| |
llvm-svn: 214757
|
|
|
|
|
|
|
|
|
|
| |
This patch adds the '-fcoverage-mapping' option which
allows clang to generate the coverage mapping information
that can be used to provide code coverage analysis using
the execution counts obtained from the instrumentation
based profiling (-fprofile-instr-generate).
llvm-svn: 214752
|
|
|
|
|
|
| |
involved.
llvm-svn: 214606
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Instead of creating global variables for source locations and global names,
just create metadata nodes and strings. They will be transformed into actual
globals in the instrumentation pass (if necessary). This approach is more
flexible:
1) we don't have to ensure that our custom globals survive all the optimizations
2) if globals are discarded for some reason, we will simply ignore metadata for them
and won't have to erase corresponding globals
3) metadata for source locations can be reused for other purposes: e.g. we may
attach source location metadata to alloca instructions and provide better descriptions
for stack variables in ASan error reports.
No functionality change.
llvm-svn: 214604
|
|
|
|
|
|
|
|
|
|
|
|
| |
We've added support for a multiple functions with the same name in
LLVM's profile data, so the lookup returning the function hash it
found doesn't make sense anymore. Update to pass in the hash we
expect.
This also adds a test that the version 1 format is still readable,
since the new API is expected to handle that.
llvm-svn: 214586
|
|
|
|
|
|
| |
emitting everything, rather than potentially doing this reentrantly.
llvm-svn: 214582
|
|
|
|
| |
llvm-svn: 214579
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It is responsible for generating metadata consumed by sanitizer instrumentation
passes in the backend. Move several methods from CodeGenModule to SanitizerMetadata.
For now the class is stateless, but soon it won't be the case.
Instead of creating globals providing source-level information to ASan, we will create
metadata nodes/strings which will be turned into actual global variables in the
backend (if needed).
No functionality change.
llvm-svn: 214564
|
|
|
|
|
|
|
|
|
| |
Original message:
Fix iterator invalidation issues that are breaking my modules buildbot's
bootstrap.
llvm-svn: 214555
|
|
|
|
| |
llvm-svn: 214549
|
|
|
|
|
|
| |
bootstrap.
llvm-svn: 214547
|