| Commit message (Collapse) | Author | Age | Files | Lines |
| ... | |
| |
|
|
| |
llvm-svn: 69387
|
| |
|
|
|
|
|
| |
the functional change here is changing ConvertType -> ConvertTypeForMem
so that we handle i1 fields properly as memory.
llvm-svn: 69361
|
| |
|
|
| |
llvm-svn: 69360
|
| |
|
|
|
|
| |
by anything yet.
llvm-svn: 69343
|
| |
|
|
|
|
|
| |
- <rdar://problem/6800351> clang not producing correct large struct
return code for Blocks
llvm-svn: 69337
|
| |
|
|
|
|
|
|
|
|
|
|
| |
struct S {
S(int, int);
};
void f() {
S s(10, 10);
}
llvm-svn: 69330
|
| |
|
|
| |
llvm-svn: 69328
|
| |
|
|
| |
llvm-svn: 69315
|
| |
|
|
|
|
| |
match gcc's.
llvm-svn: 69305
|
| |
|
|
|
|
|
|
|
|
|
| |
conversion constructors.
Remove an atrocious amount of trailing whitespace in the overloaded operator mangler. Sorry, couldn't help myself.
Change the DeclType parameter of Sema::CheckReferenceInit to be passed by value instead of reference. It wasn't changed anywhere.
Let the parser handle C++'s irregular grammar around assignment-expression and conditional-expression.
And finally, the reason for all this stuff: implement C++ semantics for the conditional operator. The implementation is complete except for determining lvalueness.
llvm-svn: 69299
|
| |
|
|
|
|
| |
when generating a common definition.
llvm-svn: 69287
|
| |
|
|
| |
llvm-svn: 69232
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- PR3980.
- <rdar://problem/6762287> [irgen] crash when generating tentative
definition of incomplete structure
- This also avoids creating common definitions for things which are
later overwritten.
- XFAIL'ed external-defs.c, it isn't completing types properly yet.
llvm-svn: 69231
|
| |
|
|
| |
llvm-svn: 69228
|
| |
|
|
|
|
| |
code for.
llvm-svn: 69222
|
| |
|
|
|
|
|
|
| |
- This was particularly bad since I fixed one instance of this name
and not another, meaning we got an LLVM module with the same
effective name in two different globals!
llvm-svn: 69205
|
| |
|
|
| |
llvm-svn: 69199
|
| |
|
|
| |
llvm-svn: 69198
|
| |
|
|
| |
llvm-svn: 69170
|
| |
|
|
| |
llvm-svn: 69168
|
| |
|
|
|
|
| |
at you, Doug)
llvm-svn: 69150
|
| |
|
|
| |
llvm-svn: 69137
|
| |
|
|
| |
llvm-svn: 69134
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Set alignment on property lists.
- 32-bit:
o Set section on property lists.
o Fix section name for category class methods.
o Fix symbol name for property lists.
o Fix section name for class method.
o Set alignment and section on class extension structure.
o Set alignment on a number of things: instance variables, methods,
method descriptions, the symbols structure.
- 64-bit:
o Fix section flags for protocol list.
I doubt most of these were problems in practice, but it is nice to
match llvm-gcc.
llvm-svn: 69132
|
| |
|
|
|
|
| |
llvm-gcc).
llvm-svn: 69097
|
| |
|
|
| |
llvm-svn: 69093
|
| |
|
|
| |
llvm-svn: 69091
|
| |
|
|
| |
llvm-svn: 69070
|
| |
|
|
|
|
|
|
| |
C99 mode. This is a regression from an earlier patch of mine.
This also simplifies the linkage enums a bit.
llvm-svn: 69069
|
| |
|
|
|
|
| |
This will match gcc's behavior in the arena.
llvm-svn: 69061
|
| |
|
|
| |
llvm-svn: 69055
|
| |
|
|
| |
llvm-svn: 69053
|
| |
|
|
| |
llvm-svn: 69050
|
| |
|
|
|
|
|
|
| |
pulling some attribute munging stuff into GetLinkageForFunction.
This should fix PR3986
llvm-svn: 69045
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Pull out SetCommonAttributes, which handles the things common to
aliases, methods, functions, and variables.
- Pull out SetLLVMFunctionAttributesForDefinition, which handles the
LLVM attributes which we only want to apply to a definition (like
noinline and alwaysinline).
- Kill SetGVDeclarationAttributes (inlined into SetFunctionAttributes
and specialized).
- Kill SetFunctionAttributesForDefinition (inlined into sole caller).
- Inline SetGVDefinitionAttributes into SetMethodAttributes and
specialize.
- Rename SetGVDefinitionAttributes to SetFunctionDefinitionAttributes.
This is supposed to be a no functionality change commit, but I may
have made a mistake.
llvm-svn: 69036
|
| |
|
|
|
|
| |
- No functionality change.
llvm-svn: 69035
|
| |
|
|
|
|
|
| |
disambiguate it.
- No functionality change.
llvm-svn: 69034
|
| |
|
|
| |
llvm-svn: 69033
|
| |
|
|
|
|
| |
not in c89 mode).
llvm-svn: 69032
|
| |
|
|
|
|
|
| |
inlined for some reason, then we don't want a strong or even weak
definition.
llvm-svn: 69031
|
| |
|
|
| |
llvm-svn: 69030
|
| |
|
|
| |
llvm-svn: 69029
|
| |
|
|
| |
llvm-svn: 69028
|
| |
|
|
| |
llvm-svn: 69027
|
| |
|
|
| |
llvm-svn: 69026
|
| |
|
|
| |
llvm-svn: 69025
|
| |
|
|
| |
llvm-svn: 69021
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Exposed quite a few Sema issues and a CodeGen crash.
- See FIXMEs in test case, and in SemaDecl.cpp (PR3983).
I'm skeptical that __private_extern__ should actually be a storage
class value. I think that __private_extern__ basically amounts to
extern A __attribute__((visibility("hidden")))
and would be better off handled (a) as that, or (b) with an extra bit
in the VarDecl.
llvm-svn: 69020
|
| |
|
|
| |
llvm-svn: 69010
|
| |
|
|
|
|
| |
implies an all-zero bit pattern.
llvm-svn: 68994
|