| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
identifying beginning of function body. Instead, create new location to attach with llvm.dbg.declare. This location is only used to find the context of the variable by the code generator, and it is not used to emit line number info.
llvm-svn: 86862
|
| |
|
|
| |
llvm-svn: 86861
|
| |
|
|
|
|
| |
add debug info location to an instruction.
llvm-svn: 86859
|
| |
|
|
|
|
| |
folded into target icmp instructions.
llvm-svn: 86858
|
| |
|
|
| |
llvm-svn: 86857
|
| |
|
|
| |
llvm-svn: 86856
|
| |
|
|
| |
llvm-svn: 86855
|
| |
|
|
|
|
| |
the numbers mean.
llvm-svn: 86854
|
| |
|
|
| |
llvm-svn: 86853
|
| |
|
|
| |
llvm-svn: 86852
|
| |
|
|
| |
llvm-svn: 86851
|
| |
|
|
| |
llvm-svn: 86850
|
| |
|
|
|
|
| |
initializer list. Fixes PR5463.
llvm-svn: 86849
|
| |
|
|
| |
llvm-svn: 86848
|
| |
|
|
| |
llvm-svn: 86847
|
| |
|
|
| |
llvm-svn: 86846
|
| |
|
|
|
|
| |
was commented out.
llvm-svn: 86845
|
| |
|
|
|
|
|
|
|
| |
template<typename T>
struct X {
template<template<T Value> class Y> struct Inner;
};
llvm-svn: 86844
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
nested-name-specifiers so that they don't gobble the template name (or
operator-function-id) unless there is also a
template-argument-list. For example, given
T::template apply
we would previously consume both "template" and "apply" as part of
parsing the nested-name-specifier, then error when we see that there
is no "<" starting a template argument list. Now, we parse such
constructs tentatively, and back off if the "<" is not present. This
allows us to parse dependent template names as one would use them for,
e.g., template template parameters:
template<typename T, template<class> class X = T::template apply>
struct MetaSomething;
Also, test default arguments for template template parameters.
llvm-svn: 86841
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
llvm.invariant.start to be used without necessarily being paired with a call
to llvm.invariant.end. If you run the entire optimization pipeline then such
calls are in fact deleted (adce does it), but that's actually a good thing since
we probably do want them to be zapped late in the game. There should really be
an integration test that checks that the llvm.invariant.start call lasts long
enough that all passes that do interesting things with it get to do their stuff
before it is deleted. But since no passes do anything interesting with it yet
this will have to wait for later.
llvm-svn: 86840
|
| |
|
|
| |
llvm-svn: 86837
|
| |
|
|
| |
llvm-svn: 86836
|
| |
|
|
|
|
| |
Now only one test case is XFAIL'ed.
llvm-svn: 86834
|
| |
|
|
|
|
|
|
| |
explicitly.
Fix 80-col violations.
llvm-svn: 86833
|
| |
|
|
| |
llvm-svn: 86830
|
| |
|
|
| |
llvm-svn: 86829
|
| |
|
|
|
|
| |
clang-cc/Options.cpp
llvm-svn: 86828
|
| |
|
|
|
|
| |
mode.
llvm-svn: 86827
|
| |
|
|
|
|
| |
InitializeCompileOptions.
llvm-svn: 86826
|
| |
|
|
| |
llvm-svn: 86825
|
| |
|
|
| |
llvm-svn: 86824
|
| |
|
|
| |
llvm-svn: 86823
|
| |
|
|
| |
llvm-svn: 86822
|
| |
|
|
| |
llvm-svn: 86821
|
| |
|
|
| |
llvm-svn: 86820
|
| |
|
|
| |
llvm-svn: 86819
|
| |
|
|
| |
llvm-svn: 86818
|
| |
|
|
|
|
| |
move to libFrontend.
llvm-svn: 86817
|
| |
|
|
|
|
|
| |
Also, inline InitializeLanguageStandard into InitializeLangOptions; this code
needs to be refactored but the current division doesn't make any sense.
llvm-svn: 86816
|
| |
|
|
| |
llvm-svn: 86815
|
| |
|
|
| |
llvm-svn: 86814
|
| |
|
|
|
|
| |
determine if a pointer is casted to a struct pointer. This fixes an observed false positive when a value is casted to a union.
llvm-svn: 86813
|
| |
|
|
|
|
| |
resetting the flag indicating that the current Decl* has not yet been displayed. Also move this out of AnalysisManager, since AnalysisManager should not handle text output to the user.
llvm-svn: 86812
|
| |
|
|
| |
llvm-svn: 86811
|
| |
|
|
| |
llvm-svn: 86810
|
| |
|
|
|
|
| |
BadCallChecker, making their implementations completely private.
llvm-svn: 86809
|
| |
|
|
|
|
| |
PCH/-E and PCH/not--E cases.
llvm-svn: 86808
|
| |
|
|
|
|
| |
by default).
llvm-svn: 86807
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
the front-end (as far as the preprocessor goes), follow the usual logic of
inserting the (original include path) name into the predefines buffer. This
pushes the responsibility for handling this to PCH instead of the front-end. In
PCH this requires being a little more clever when we diff the predefines
buffers.
Neither of these solutions are particularly great, I think what we eventually
should do is something like gcc where we insert a special marker to indicate the
PCH file, but then run the preprocessor as usual. This would be clearer and
would allow us to drop the overly clever predefines handling.
llvm-svn: 86806
|
| |
|
|
| |
llvm-svn: 86805
|