| Age | Commit message (Collapse) | Author |
|---|
|
category or protocol.
llvm-svn: 67450
|
|
very simple places, reimplement the deferred decl emission logic to not be O(N^2),
fixing PR3810.
llvm-svn: 67447
|
|
function definition.
llvm-svn: 67446
|
|
code path.
llvm-svn: 67445
|
|
GetAddrOfFunction. This is simpler and more efficient.
llvm-svn: 67444
|
|
CreateFunctionPrototypeIR, though my next patch will eliminate
it entirely.
llvm-svn: 67443
|
|
1. it wasn't applying to definitions, only declarations, e.g. int x __asm("foo")
2. multiple definitions were conflicting, they weren't getting merged.
3. the code was duplicated in several places.
llvm-svn: 67442
|
|
llvm-svn: 67441
|
|
llvm-svn: 67440
|
|
llvm-svn: 67439
|
|
more optimistic that it will work (optimizing for the common case).
llvm-svn: 67438
|
|
llvm-svn: 67437
|
|
type).
llvm-svn: 67436
|
|
speeding up PR3810
by ~2%.
llvm-svn: 67434
|
|
speeding up the testcase in PR3810 by 60%.
llvm-svn: 67431
|
|
- PR3818.
llvm-svn: 67297
|
|
whose sema decl is at the translation unit.
llvm-svn: 67249
|
|
llvm-svn: 66691
|
|
llvm-svn: 66652
|
|
module symbol table. The root problem inspiring this was fixed in
r66316 (and again in r66506).
llvm-svn: 66512
|
|
reuse the prior one.
llvm-svn: 66408
|
|
This is a bit cleaner, and also "fixes" bad code that compares the
addresses of the string constants.
llvm-svn: 66346
|
|
they are all
correct, but an extra set of ObjC eyes would be good.
llvm-svn: 66342
|
|
CodeGenModule::CreateRuntimeVariable.
- No real functionality change; although we now assert on silly
things like:
--
int objc_exception_throw;
void f0() { @throw(@"A"); }
--
instead of accepting it.
llvm-svn: 66292
|
|
- <rdar://problem/6652110> clang should support weak_import
llvm-svn: 66270
|
|
- For one thing, this adds unneeded overhead; for another, this
routine can be used to emit unnamed decls which we shouldn't try to
mangle.
llvm-svn: 66212
|
|
return/argument types. (The generated IR isn't ideal, but we can't
really do better in general.)
llvm-svn: 66132
|
|
llvm-svn: 66046
|
|
BlockModule. No functionality change. This should help people that
don't want to know anything about blocks not be confused by the
overloaded use of the term block or nor want to see all the blocks
goop.
llvm-svn: 66042
|
|
- PR3698.
llvm-svn: 66038
|
|
llvm-svn: 65806
|
|
llvm-svn: 65782
|
|
llvm-svn: 65749
|
|
we ensure that things added to the module can be found even when they
are not in GlobalDeclMap. The later is for increased flexibility,
should someone want to do something tricky like extern "Ada" in the
same module.
llvm-svn: 65657
|
|
llvm-svn: 65611
|
|
llvm-svn: 65582
|
|
The big difference here is that (like string literal) @encode has
array type, not pointer type.
llvm-svn: 65391
|
|
- PR3629.
llvm-svn: 65203
|
|
error, so we don't crash.
llvm-svn: 65099
|
|
llvm-svn: 65056
|
|
- <rdar://problem/6584606> clang/x86-64 - too many reg saves
llvm-svn: 65032
|
|
situation where a tentative decl was emitted *after* the actual
initialization. This occurs in some rare situations with static decls.
- PR3613.
- I'm not particularly happy with this fix, but I don't see a simpler
or more elegant solution yet.
llvm-svn: 65018
|
|
llvm-svn: 64984
|
|
llvm-svn: 64969
|
|
llvm-svn: 64944
|
|
we can define builtins such as fprintf, vfprintf, and
__builtin___fprintf_chk. Give a nice error message when we need to
implicitly declare a function like fprintf.
llvm-svn: 64526
|
|
etc.) when we perform name lookup on them. This ensures that we
produce the correct signature for these functions, which has two
practical impacts:
1) When we're supporting the "implicit function declaration" feature
of C99, these functions will be implicitly declared with the right
signature rather than as a function returning "int" with no
prototype. See PR3541 for the reason why this is important (hint:
GCC always predeclares these functions).
2) If users attempt to redeclare one of these library functions with
an incompatible signature, we produce a hard error.
This patch does a little bit of work to give reasonable error
messages. For example, when we hit case #1 we complain that we're
implicitly declaring this function with a specific signature, and then
we give a note that asks the user to include the appropriate header
(e.g., "please include <stdlib.h> or explicitly declare 'malloc'"). In
case #2, we show the type of the implicit builtin that was incorrectly
declared, so the user can see the problem. We could do better here:
for example, when displaying this latter error message we say
something like:
'strcpy' was implicitly declared here with type 'char *(char *, char
const *)'
but we should really print out a fake code line showing the
declaration, like this:
'strcpy' was implicitly declared here as:
char *strcpy(char *, char const *)
This would also be good for printing built-in candidates with C++
operator overloading.
The set of C library functions supported by this patch includes all
functions from the C99 specification's <stdlib.h> and <string.h> that
(a) are predefined by GCC and (b) have signatures that could cause
codegen issues if they are treated as functions with no prototype
returning and int. Future work could extend this set of functions to
other C library functions that we know about.
llvm-svn: 64504
|
|
llvm-svn: 64500
|
|
- PR3566
llvm-svn: 64492
|
|
- Fix emission of static functions with constructor attribute while I
was here.
<rdar://problem/6140899> [codegen] "static" and attribute-constructor interact poorly
llvm-svn: 64488
|
