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
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
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
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
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
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
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
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
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
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
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
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
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
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
