within class templates when they are necessary to complete the type of
the member. The canonical example is code like:

  template <typename T> struct S {
    static const int arr[];
    static const int x;
    static int f();
  };

  template <typename T> const int S<T>::arr[] = { 1, 2, 3 };
  template <typename T> const int S<T>::x = sizeof(arr) / sizeof(arr[0]);
  template <typename T> int S<T>::f() { return x; }

  int x = S<int>::f();

We need to instantiate S<T>::arr's definition to pick up its initializer
and complete the array type. This involves new code to specially handle
completing the type of an expression where the type alone is
insufficient. It also requires *updating* the expression with the newly
completed type. Fortunately, all the other infrastructure is already in
Clang to do the instantiation, do the completion, and prune out the
unused bits of code that result from this instantiation.

This addresses the initial bug in PR10001, and will be a step to
fleshing out other cases where we need to work harder to complete an
expression's type. Who knew we still had missing C++03 "features"?

llvm-svn: 132172

parameter types to be ill-formed. However, it relies on the
completeness of method parameter types when producing metadata, e.g.,
for a protocol, leading IR generating to crash in such cases.

Since there's no real way to tighten down the semantics of Objective-C
here without breaking existing code, do something safe but lame:
suppress the generation of metadata when this happens.

Fixes <rdar://problem/9123036>.

llvm-svn: 132171

One more debug line number miss in instcombine (although the code in question isn't actually in instcombine).

llvm-svn: 132170

llvm-svn: 132168

Final step of instcombine debuginfo; switch a couple more places over to InsertNewInstWith, and use setDebugLoc for the cases which can't be easily handled by the automated mechanisms.

llvm-svn: 132167

This looks like it flagged an actual bug. Devang, please review. I added
the parentheses that change behavior, but make the behavior more closely
match commit log's intent.

llvm-svn: 132165

llvm-svn: 132164

crc32.[8|16|32] have been renamed to .crc32.32.[8|16|32] and
crc64.[8|16|32] have been renamed to .crc32.64.[8|64].

llvm-svn: 132163

llvm-svn: 132162

llvm-svn: 132161

llvm-svn: 132160

llvm-svn: 132152

If llvm.dbg.value and the value instruction it refers to are far apart then iSel may not be able to find corresponding Node for llvm.dbg.value during DAG construction. Make iSel's life easier by removing this distance between llvm.dbg.value and its value instruction.

llvm-svn: 132151

llvm-svn: 132150

llvm-svn: 132149

llvm-svn: 132148

llvm-svn: 132147

llvm-svn: 132146

Change the include stack of "instantiated from" notes to fall under the control of f/fno-diagnostics-show-note-include-stack flags.  This should help with reducing diagnostic spew from macros instantiations.

llvm-svn: 132143

llvm-svn: 132141

a function has any function calls.

llvm-svn: 132140

Add a fix-it and better error recovery for improperly nested namespaces.  This will give a better error message for cases such as "namespace foo::bar::baz {}" and a suggested fix-it of "namespace foo { namespace bar { namespace baz {} } }"

llvm-svn: 132138

llvm-svn: 132137

llvm-svn: 132136

Make few ExecutionEngine tests XFAIL for ARM, since ExecutionEngine is broken for ARM, please remove the following XFAIL when it will be fixed.

llvm-svn: 132135

llvm-svn: 132134

llvm-svn: 132132

llvm-svn: 132131

llvm-svn: 132130

llvm-svn: 132129

llvm-svn: 132128

llvm-svn: 132127

llvm-svn: 132126

llvm-svn: 132125

llvm-svn: 132123

llvm-svn: 132120

provide re-usable forms of the rest of the custom validation done here.
Still no functionality changed here.

With this it should be possible to have an expression-centric code path
and a type-centric code path which don't duplicate logic.

llvm-svn: 132118

information in the previous comment which was preserved and moved with
the vec_step implementation code.

llvm-svn: 132117

It has little overlap with other traits' requirements, so the resulting
code is actually simpler.

llvm-svn: 132116

traits which uses the information embedded in the expression. Use this
to simplify several interfaces which repeated information embedded in
the expression through explicit arguments. I added an assertion that the
only extra piece of data to come in from the parser matches what is
stored in the expression. No functionality change intended here.

Also cleaned up the doxygen comments for some of these methods and some
formatting oddities.

llvm-svn: 132115