| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
| |
which is wrong here.
llvm-svn: 170721
|
|
|
|
|
|
| |
single attribute in the future.
llvm-svn: 170500
|
|
|
|
| |
llvm-svn: 169713
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
uncovered.
This required manually correcting all of the incorrect main-module
headers I could find, and running the new llvm/utils/sort_includes.py
script over the files.
I also manually added quite a few missing headers that were uncovered by
shuffling the order or moving headers up to be main-module-headers.
llvm-svn: 169237
|
|
|
|
|
|
| |
modes. Test cases included.
llvm-svn: 169191
|
|
|
|
| |
llvm-svn: 169187
|
|
|
|
| |
llvm-svn: 169114
|
|
|
|
| |
llvm-svn: 168047
|
|
|
|
|
|
|
|
|
|
| |
type as written from the ParmVarDecl; it's unclear whether the standard
(C99 6.9.1p10) requires this, but we're following the precedent set by gcc,
and hopefully nobody will ever ask about this again.
PR9559 / <rdar://problem/12621983>.
llvm-svn: 167985
|
|
|
|
|
|
|
| |
checks to enable. Remove frontend support for -fcatch-undefined-behavior,
-faddress-sanitizer and -fthread-sanitizer now that they don't do anything.
llvm-svn: 167413
|
|
|
|
| |
llvm-svn: 167261
|
|
|
|
| |
llvm-svn: 166684
|
|
|
|
| |
llvm-svn: 166497
|
|
|
|
|
|
|
|
|
|
|
| |
if (CGM.getModuleDebugInfo())
DebugInfo = CGM.getModuleDebugInfo()
into a call:
maybeInitializeDebugInfo();
This is a simplification for a possible future fix of PR13942.
llvm-svn: 166019
|
|
|
|
|
|
| |
fails to return a value, to make debugging this issue easier.
llvm-svn: 165914
|
|
|
|
|
|
| |
attribute object and add it appropriately. No functionality change.
llvm-svn: 165596
|
|
|
|
| |
llvm-svn: 165584
|
|
|
|
|
|
| |
non-positive value.
llvm-svn: 165583
|
|
|
|
|
|
| |
of the checks fails.
llvm-svn: 165536
|
|
|
|
| |
llvm-svn: 165395
|
|
|
|
|
|
|
|
| |
- outside C++, return undef (behavior is not undefined unless the value is used)
- in C++, with -fcatch-undefined-behavior, perform an appropriate trap
- in C++, produce an 'unreachable' (behavior is undefined immediately)
llvm-svn: 165273
|
|
|
|
|
|
| |
APSInt::isSameValue() when comparing different sized APSInt's.
llvm-svn: 160641
|
|
|
|
| |
llvm-svn: 160238
|
|
|
|
|
|
|
|
| |
flag as noted in the OpenCL Spec.
Includes a test case.
llvm-svn: 160092
|
|
|
|
| |
llvm-svn: 159965
|
|
|
|
|
|
|
|
|
|
|
|
| |
literal helper functions. All helper functions (global
and locals) use block_invoke as their prefix. Local literal
helper names are prefixed by their enclosing mangled function
names. Blocks in non-local initializers (e.g. a global variable
or a C++11 field) are prefixed by their mangled variable name.
The descriminator number added to end of the name starts off
with blank (for first block) and _<N> (for the N+2-th block).
llvm-svn: 159206
|
|
|
|
|
|
|
|
| |
* Escaped Objective-C @keywords in Doxygen comments;
* Documented more accurate \params;
* Exposed some more summaries using \brief.
llvm-svn: 158559
|
|
|
|
| |
llvm-svn: 157262
|
|
|
|
|
|
|
|
| |
When enabled, clang generates bounds checks for array and pointers dereferences. Work to follow in LLVM's backend.
OK'ed by Chad; thanks for the review.
llvm-svn: 156431
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
It reduces the amount of emitted debug information:
1) DIEs in .debug_info have types DW_TAG_compile_unit, DW_TAG_subprogram,
DW_TAG_inlined_subroutine (for opt builds) and DW_TAG_lexical_block only.
2) .debug_str contains only function names.
3) No debug data for types/namespaces/variables is emitted.
4) The data in .debug_line is enough to produce valid stack traces with
function names and line numbers.
Reviewed by Eric Christopher.
llvm-svn: 156160
|
|
|
|
|
|
|
| |
type llvm::ArrayType -- sometimes we emit them as packed structs. Don't assert
if such a global array has an element type with a non-trivial destructor.
llvm-svn: 155305
|
|
|
|
| |
llvm-svn: 154851
|
|
|
|
|
|
| |
up to this yet.
llvm-svn: 154835
|
|
|
|
| |
llvm-svn: 154789
|
|
|
|
|
|
|
|
|
|
|
| |
-fno-inline-functions.
This behaves much like -fno-inline in gcc, but based on a discussion with
Daniel it was decided that -fno-inline-functions should subsume -fno-inline.
Please speak up if you object. The -fno-inline flag remains ignored.
Final part of rdar://10972766
llvm-svn: 152754
|
|
|
|
|
|
|
|
|
|
| |
(Lex to AST).
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
llvm-svn: 152536
|
|
|
|
|
|
|
|
| |
generated block literal for lambdas which are immediately converted to block pointer type. This simplifies the AST, avoids an unnecessary copy of the lambda and makes it much easier to avoid copying the result onto the heap.
Note that this transformation has a substantial semantic effect outside of ARC: it gives the converted lambda lifetime semantics similar to a block literal. With ARC, the effect is much less obvious because the lifetime of blocks is already managed.
llvm-svn: 151797
|
|
|
|
|
|
| |
implement the retain+autorelease outside of ARC, and there's a bug that causes the generated code to crash in ARC (which I think is unrelated to my code, although I'm not completely sure).
llvm-svn: 151428
|
|
|
|
| |
llvm-svn: 150855
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
conversion to function pointer. Rather than having IRgen synthesize
the body of this function, we instead introduce a static member
function "__invoke" with the same signature as the lambda's
operator() in the AST. Sema then generates a body for the conversion
to function pointer which simply returns the address of __invoke. This
approach makes it easier to evaluate a call to the conversion function
as a constant, makes the linkage of the __invoke function follow the
normal rules for member functions, and may make life easier down the
road if we ever want to constexpr'ify some of lambdas.
Note that IR generation is responsible for filling in the body of
__invoke (Sema just adds a dummy body), because the body can't
generally be expressed in C++.
Eli, please review!
llvm-svn: 150783
|
|
|
|
| |
llvm-svn: 150649
|
|
|
|
| |
llvm-svn: 150459
|
|
|
|
|
|
| |
examples seem to work. Tests coming up soon.
llvm-svn: 150293
|
|
|
|
|
|
|
|
| |
other users.
While at it make it value-initializable to get rid of static ctors.
llvm-svn: 150070
|
|
|
|
|
|
| |
CodeGenModule.
llvm-svn: 149943
|
|
|
|
| |
llvm-svn: 147933
|
|
|
|
| |
llvm-svn: 147730
|
|
|
|
|
|
| |
clients. No functionality change.
llvm-svn: 147318
|
|
|
|
|
|
|
|
|
|
|
|
| |
full-expression. Naturally they're inactive before we enter
the block literal expression. This restores the intended
behavior that blocks belong to their enclosing scope.
There's a useful -O0 / compile-time optimization that we're
missing here with activating cleanups following straight-line
code from their inactive beginnings.
llvm-svn: 144268
|
|
|
|
|
|
|
|
| |
implicitly perform an lvalue-to-rvalue conversion if used on an lvalue
expression. Also improve the documentation of Expr::Evaluate* to indicate which
of them will accept expressions with side-effects.
llvm-svn: 143263
|