| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
|
|
|
| |
the type assigned by sema (and is visible with sizeof(__func__) for
example) has nothing to do with what codegen ends up producing.
We should eventually add a method on PredefinedExpr to handle this.
In the meantime, just set up some framework and add some fixme's.
llvm-svn: 69872
|
| |
|
|
| |
llvm-svn: 69775
|
| |
|
|
|
|
|
| |
but crashed codegen. Fix this to report the name of the llvm function.
This fixes rdar://6808051
llvm-svn: 69658
|
| |
|
|
|
|
|
|
| |
when we need them -- which is exactly what some code was already
doing!
- No intended functionality change.
llvm-svn: 69648
|
| |
|
|
| |
llvm-svn: 69641
|
| |
|
|
|
|
| |
- <rdar://problem/6803995>
llvm-svn: 69435
|
| |
|
|
| |
llvm-svn: 69360
|
| |
|
|
|
|
|
|
|
|
|
|
| |
struct S {
S(int, int);
};
void f() {
S s(10, 10);
}
llvm-svn: 69330
|
| |
|
|
| |
llvm-svn: 69055
|
| |
|
|
| |
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
|
| |
|
|
|
|
| |
- No functionality change.
llvm-svn: 68987
|
| |
|
|
| |
llvm-svn: 68652
|
| |
|
|
|
|
| |
GEP is only 32 or 64. So promote index to 32 in such cases.
llvm-svn: 68590
|
| |
|
|
| |
llvm-svn: 68532
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Changed method names to match gcc (categories names still aren't
mangled in).
- Expose correct name for class and metadata symbols (although
-fvisibility=hidden isn't yet correct).
- Remove several things from llvm.used that didn't need to be there
(I suspect this can still be trimmed).
- Don't use asm-prefix extension for _objc_empty_{cache,vtable} (not
needed).
- Hide EH type class info with -fvisibility=hidden
- Change setGlobal[Option]Visibility to not change the visibility of
functions with internal linkage.
llvm-svn: 68510
|
| |
|
|
| |
llvm-svn: 68412
|
| |
|
|
| |
llvm-svn: 67603
|
| |
|
|
|
|
|
|
|
| |
in release-assert builds. For automatic variables, explicitly set
a name with setName that does not make a temporary std::string.
This speeds up -emit-llvm-only -disable-free on PR3810 by 4.6%
llvm-svn: 67459
|
| |
|
|
|
|
| |
more optimistic that it will work (optimizing for the common case).
llvm-svn: 67438
|
| |
|
|
| |
llvm-svn: 67219
|
| |
|
|
|
|
|
| |
There are some more complex cases (_Complex and structs)
that I'm still working on.
llvm-svn: 67218
|
| |
|
|
| |
llvm-svn: 67164
|
| |
|
|
|
|
| |
chosen sub-expression, rather than just evaluating the condition.
llvm-svn: 66018
|
| |
|
|
|
|
|
| |
still give an unsupported error for them due to the fact this is a
work in progress.
llvm-svn: 66007
|
| |
|
|
|
|
|
| |
block literal is causing the problem, instead of the vague reference
to the entire block literal.
llvm-svn: 65798
|
| |
|
|
| |
llvm-svn: 65688
|
| |
|
|
|
|
|
| |
The big difference here is that (like string literal) @encode has
array type, not pointer type.
llvm-svn: 65391
|
| |
|
|
|
|
|
| |
of a pointer to object; This patch does this odd behavior according to
gcc.
llvm-svn: 65334
|
| |
|
|
|
|
|
| |
true a local pointer to objective-c object in generating
write barriers.
llvm-svn: 65290
|
| |
|
|
| |
llvm-svn: 65251
|
| |
|
|
|
|
| |
type.
llvm-svn: 65205
|
| |
|
|
| |
llvm-svn: 65145
|
| |
|
|
|
|
| |
- Remove an unused variant of EmitCallExpr overload.
llvm-svn: 65130
|
| |
|
|
| |
llvm-svn: 65097
|
| |
|
|
| |
llvm-svn: 65077
|
| |
|
|
| |
llvm-svn: 65051
|
| |
|
|
|
|
| |
of objects in objc.
llvm-svn: 64992
|
| |
|
|
| |
llvm-svn: 64984
|
| |
|
|
|
|
| |
ir gen.
llvm-svn: 64954
|
| |
|
|
|
|
| |
objc gc type attributes.
llvm-svn: 64935
|
| |
|
|
|
|
|
|
| |
This make warn-weak-field.m to fail (subject of
a followup patch).
attr-objc-gc.m no passes.
llvm-svn: 64925
|
| |
|
|
| |
llvm-svn: 64779
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- Define pow[lf]?, sqrt[lf]? as builtins.
- Add -fmath-errno option which binds to LangOptions.MathErrno
- Add new builtin flag Builtin::Context::isConstWithoutErrno for
functions which can be marked as const if errno isn't respected for
math functions. Sema automatically marks these functions as const
when they are defined, if MathErrno=0.
- IRgen uses const attribute on sqrt and pow library functions to
decide if it can use the llvm intrinsic.
llvm-svn: 64689
|
| |
|
|
|
|
|
|
|
|
|
| |
emit two volatile loads for:
typedef __attribute__(( ext_vector_type(4) )) float float4;
float test(volatile float4 *P) {
return P->x+P->y;
}
llvm-svn: 64683
|
| |
|
|
|
|
| |
suggestion
llvm-svn: 64681
|
| |
|
|
| |
llvm-svn: 64667
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
about, whether they are builtins or not. Use this to add the
appropriate "format" attribute to NSLog, NSLogv, asprintf, and
vasprintf, and to translate builtin attributes (from Builtins.def)
into actual attributes on the function declaration.
Use the "printf" format attribute on function declarations to
determine whether we should do format string checking, rather than
looking at an ad hoc list of builtins and "known" function names.
Be a bit more careful about when we consider a function a "builtin" in
C++.
llvm-svn: 64561
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
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
|