InitializationSequence. Fixes the -fsyntax-only failure in
llvm/lib/Transforms/Scalar/InstructionCombining.cpp.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91921 91177308-0d34-0410-b5e6-96231b3b80d8
a size, check whether the transformed type is itself an array type. If
so, take the major array bound as the size to allocate. Fixes PR5833.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91907 91177308-0d34-0410-b5e6-96231b3b80d8
InitializationSequence (when a FunctionDecl is present). This required
a few small fixes to initialization sequences:
- Make sure to use the adjusted parameter type for initialization of
function parameters.
- Implement transparent union calling semantics in C
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91902 91177308-0d34-0410-b5e6-96231b3b80d8
With this seemingly insignificant fix, we are now able to build and link clang using clang itself! (LLVM still has to be built with gcc for the time being).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91893 91177308-0d34-0410-b5e6-96231b3b80d8
integer.
- This is consistent, but may not be correct. I will revisit x86_64 ABI handling for C++ as a whole at some point.
- PR5831.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91874 91177308-0d34-0410-b5e6-96231b3b80d8
this was useful, and on review Doug and I decided it was probably on the level
of a bug in the standard and therefore not worth a warning even in -pedantic.
If someone disagrees and urgently wants clang++ to warn about this in strict
c++98 mode, we can talk about it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91868 91177308-0d34-0410-b5e6-96231b3b80d8
constructor call, the conversion is only a standard conversion
sequence if that constructor is a copy constructor. This fixes PR5834
in a semi-lame way, because the "real" fix will be to move over to
InitializationSequence. That will happen "soonish", but not now.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91861 91177308-0d34-0410-b5e6-96231b3b80d8
sure to fill in the initialized member of a union when a member was
explicitly designated. Fixes PR5843.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91858 91177308-0d34-0410-b5e6-96231b3b80d8
- Correctly is in quotes, because we are following what I interpreted as GCC's
intent (which diverges from practice, naturally).
- Also, fix the arch define for arm1136jf-s.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91855 91177308-0d34-0410-b5e6-96231b3b80d8
explicitly-specified template arguments are enough to determine the
instantiation, and either template argument deduction fails or is not
performed in that context, we can resolve the template-id down to a
function template specialization (so sayeth C++0x
[temp.arg.explicit]p3). Fixes PR5811.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91852 91177308-0d34-0410-b5e6-96231b3b80d8
not deduce an "overload" type. Such a deduction indicates a failure in
semantic analysis (e.g., PR5811) that currently isn't caught until
code-generation time. This assertions makes it clearer that this
particular issue is a semantic-analysis problem, not a code-gen problem.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91844 91177308-0d34-0410-b5e6-96231b3b80d8
recursing in CGDebugInfo::CreateTypeNode, teach
CanonicalizeTypeForDebugInfo---now called UnwrapTypeForDebugInfo---to
keep unwrapping the type until we hit something that can be
represented by debug information. Thanks to Anders for pointing this out!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91840 91177308-0d34-0410-b5e6-96231b3b80d8
ElaboratedType, QualifiedNameType, and SubstTemplateTypeParmType type
nodes. Also, produce an "unsupported" diagnostic for C++0x type nodes
and "typeof" nodes, rather than asserting nondescriptly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91837 91177308-0d34-0410-b5e6-96231b3b80d8
Sema::getTypeName.
"LookupNestedNameSpecifierName" isn't quite the right kind of lookup, though;
it doesn't ignore namespaces. Someone more familiar with the lookup code
should fix this properly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@91809 91177308-0d34-0410-b5e6-96231b3b80d8