|
Revision tags: llvmorg-2.9.0 |
|
| #
eafa4e4b |
| 06-Apr-2011 |
Peter Collingbourne <[email protected]> |
If this is an intrinsic function, set the function's attributes to the intrinsic's attributes.
llvm-svn: 129000
|
|
Revision tags: llvmorg-2.9.0-rc3 |
|
| #
1baf38f5 |
| 26-Mar-2011 |
Douglas Gregor <[email protected]> |
On Mac OS X, the presence of an 'availability' attribute for that platform implies default visibility. To achieve these, refactor our lookup of explicit visibility so that we search for both an expli
On Mac OS X, the presence of an 'availability' attribute for that platform implies default visibility. To achieve these, refactor our lookup of explicit visibility so that we search for both an explicit VisibilityAttr and an appropriate AvailabilityAttr, favoring the VisibilityAttr if it is present.
llvm-svn: 128336
show more ...
|
|
Revision tags: llvmorg-2.9.0-rc2 |
|
| #
945b8aed |
| 23-Mar-2011 |
Devang Patel <[email protected]> |
Update type cache when a type is completed. Radar 9168773
llvm-svn: 128150
|
| #
20b2ebd7 |
| 23-Mar-2011 |
Douglas Gregor <[email protected]> |
Implement a new 'availability' attribute, that allows one to specify which versions of an OS provide a certain facility. For example,
void foo() __attribute__((availability(macosx,introduced=10.
Implement a new 'availability' attribute, that allows one to specify which versions of an OS provide a certain facility. For example,
void foo() __attribute__((availability(macosx,introduced=10.2,deprecated=10.4,obsoleted=10.6)));
says that the function "foo" was introduced in 10.2, deprecated in 10.4, and completely obsoleted in 10.6. This attribute ties in with the deployment targets (e.g., -mmacosx-version-min=10.1 specifies that we want to deploy back to Mac OS X 10.1). There are several concrete behaviors that this attribute enables, as illustrated with the function foo() above:
- If we choose a deployment target >= Mac OS X 10.4, uses of "foo" will result in a deprecation warning, as if we had placed attribute((deprecated)) on it (but with a better diagnostic) - If we choose a deployment target >= Mac OS X 10.6, uses of "foo" will result in an "unavailable" warning (in C)/error (in C++), as if we had placed attribute((unavailable)) on it - If we choose a deployment target prior to 10.2, foo() is weak-imported (if it is a kind of entity that can be weak imported), as if we had placed the weak_import attribute on it.
Naturally, there can be multiple availability attributes on a declaration, for different platforms; only the current platform matters when checking availability attributes.
The only platforms this attribute currently works for are "ios" and "macosx", since we already have -mxxxx-version-min flags for them and we have experience there with macro tricks translating down to the deprecated/unavailable/weak_import attributes. The end goal is to open this up to other platforms, and even extension to other "platforms" that are really libraries (say, through a #pragma clang define_system), but that hasn't yet been designed and we may want to shake out more issues with this narrower problem first.
Addresses <rdar://problem/6690412>.
As a drive-by bug-fix, if an entity is both deprecated and unavailable, we only emit the "unavailable" diagnostic.
llvm-svn: 128127
show more ...
|
| #
067f0ed4 |
| 22-Mar-2011 |
David Chisnall <[email protected]> |
Simplify Mac runtime selection - it's the factory function's job to select which class to produce, not CodeGenModule's.
llvm-svn: 128109
|
| #
6a4fa52b |
| 22-Mar-2011 |
John McCall <[email protected]> |
The emission of an Objective-C++'s class .cxx_destruct method should be conditioned on whether it has any destructible ivars, not on whether it has any non-trivial class-object initializers.
llvm-sv
The emission of an Objective-C++'s class .cxx_destruct method should be conditioned on whether it has any destructible ivars, not on whether it has any non-trivial class-object initializers.
llvm-svn: 128074
show more ...
|
| #
599cb8e4 |
| 18-Mar-2011 |
Peter Collingbourne <[email protected]> |
Add support for language-specific address spaces. On top of that, add support for the OpenCL __private, __local, __constant and __global address spaces, as well as the __read_only, _read_write and _
Add support for language-specific address spaces. On top of that, add support for the OpenCL __private, __local, __constant and __global address spaces, as well as the __read_only, _read_write and __write_only image access specifiers. Patch originally by ARM; language-specific address space support by myself.
llvm-svn: 127915
show more ...
|
| #
7ef5cb30 |
| 18-Mar-2011 |
John McCall <[email protected]> |
The Darwin kernel does not provide useful guard variable support. Issue this as an IR-gen error; it's not really worthwhile doing this "right", i.e. in Sema, because IR gen knows a lot of tricks bey
The Darwin kernel does not provide useful guard variable support. Issue this as an IR-gen error; it's not really worthwhile doing this "right", i.e. in Sema, because IR gen knows a lot of tricks beyond what the constant evaluator knows.
llvm-svn: 127854
show more ...
|
| #
a9e5460f |
| 17-Mar-2011 |
David Chisnall <[email protected]> |
Remove code that was intentionally generating bad code on the GNU runtime for no reason (failing to emit .cxx_constructor / .cxx_destructor methods).
llvm-svn: 127806
|
| #
0c1f0982 |
| 14-Mar-2011 |
Rafael Espindola <[email protected]> |
Switch from internal to linker_private linkage, it is sufficient to please the new linker.
llvm-svn: 127622
|
| #
7a6cf018 |
| 14-Mar-2011 |
Rafael Espindola <[email protected]> |
Fix link of libxul with LTO and the linker in xcode4. It is not clear if this is working around a bug in ld or if the new linker has a reasonable reason for wanting the string constant to be linker v
Fix link of libxul with LTO and the linker in xcode4. It is not clear if this is working around a bug in ld or if the new linker has a reasonable reason for wanting the string constant to be linker visible.
llvm-svn: 127594
show more ...
|
| #
46288eff |
| 09-Mar-2011 |
John McCall <[email protected]> |
Fix three of the four places where I left breadcrumbs to avoid unnecessary recomputation.
llvm-svn: 127322
|
| #
a738c25f |
| 09-Mar-2011 |
John McCall <[email protected]> |
Use the "undergoes default argument promotion" bit on parameters to simplify the logic of initializing function parameters so that we don't need both a variable declaration and a type in FunctionArgL
Use the "undergoes default argument promotion" bit on parameters to simplify the logic of initializing function parameters so that we don't need both a variable declaration and a type in FunctionArgList. This also means that we need to propagate the CGFunctionInfo down in a lot of places rather than recalculating it from the FAL. There's more we can do to eliminate redundancy here, and I've left FIXMEs behind to do it.
llvm-svn: 127314
show more ...
|
|
Revision tags: llvmorg-2.9.0-rc1 |
|
| #
d6ffebb0 |
| 07-Mar-2011 |
Devang Patel <[email protected]> |
DebugInfo can be enabled or disabled at function level (e.g. using an attribute). However, at module level it is determined by command line option and the state of command line option does not change
DebugInfo can be enabled or disabled at function level (e.g. using an attribute). However, at module level it is determined by command line option and the state of command line option does not change during compilation. Make this layering explicit and fix accidental cases where the code generator was checking whether module has debug info enabled instead of checking whether debug info is enabled for this function or not.
llvm-svn: 127165
show more ...
|
| #
e65982c8 |
| 07-Mar-2011 |
Devang Patel <[email protected]> |
Do not emit stop point for CXXDefaultArgExpr. It results in suboptimial user experience.
21 int main() { 22 A a;
For example, here user would expect to stop at line 22, even if A's constructor le
Do not emit stop point for CXXDefaultArgExpr. It results in suboptimial user experience.
21 int main() { 22 A a;
For example, here user would expect to stop at line 22, even if A's constructor leads to a call through CXXDefaultArgExpr.
This fixes ostream-defined.exp regression from gdb testsuite.
llvm-svn: 127164
show more ...
|
| #
0cd19fbf |
| 05-Mar-2011 |
Benjamin Kramer <[email protected]> |
StringRefify.
llvm-svn: 127082
|
| #
c533cb70 |
| 22-Feb-2011 |
John McCall <[email protected]> |
Reorganize the emission of local variables.
llvm-svn: 126189
|
| #
83779675 |
| 19-Feb-2011 |
John McCall <[email protected]> |
Warn about code that uses variables and functions with internal linkage without defining them. This should be an error, but I'm paranoid about "uses" that end up not actually requiring a definition.
Warn about code that uses variables and functions with internal linkage without defining them. This should be an error, but I'm paranoid about "uses" that end up not actually requiring a definition. I'll revisit later.
Also, teach IR generation to not set internal linkage on variable declarations, just for safety's sake. Doing so produces an invalid module if the variable is not ultimately defined.
Also, fix several places in the test suite where we were using internal functions without definitions.
llvm-svn: 126016
show more ...
|
| #
e3dc1707 |
| 15-Feb-2011 |
John McCall <[email protected]> |
Assorted cleanup: - Have CGM precompute a number of commonly-used types - Have CGF copy that during initialization instead of recomputing them - Use TBAA info when initializing a parameter vari
Assorted cleanup: - Have CGM precompute a number of commonly-used types - Have CGF copy that during initialization instead of recomputing them - Use TBAA info when initializing a parameter variable - Refactor the scalar ++/-- code
llvm-svn: 125562
show more ...
|
| #
ac00f5dd |
| 10-Feb-2011 |
Rafael Espindola <[email protected]> |
Use raw_svector_ostream in more places in the mangler.
llvm-svn: 125321
|
| #
2575631c |
| 09-Feb-2011 |
Douglas Gregor <[email protected]> |
When IRgen refers to a function declaration that is not a definition, and we later find the definition, make sure that we add the definition (not the declaration) to the list of deferred definitions
When IRgen refers to a function declaration that is not a definition, and we later find the definition, make sure that we add the definition (not the declaration) to the list of deferred definitions to emit. Fixes PR8864.
Thanks to Nick Lewycky for testing this patch out
llvm-svn: 125157
show more ...
|
| #
ad7c5c16 |
| 08-Feb-2011 |
John McCall <[email protected]> |
Reorganize CodeGen{Function,Module} to eliminate the unfortunate Block{Function,Module} base class. Minor other refactorings.
Fixed a few address-space bugs while I was there.
llvm-svn: 125085
|
| #
3c239484 |
| 05-Feb-2011 |
Anders Carlsson <[email protected]> |
Re-land r124768, with a fix for PR9130.
We now emit everything except unused implicit virtual member functions when building the vtable.
llvm-svn: 124935
|
| #
e28342c4 |
| 04-Feb-2011 |
Fariborz Jahanian <[email protected]> |
minor refactoring of -fapple-kext stuff.
llvm-svn: 124837
|
| #
7cadb2f6 |
| 04-Feb-2011 |
Fariborz Jahanian <[email protected]> |
What was I thinking?
llvm-svn: 124835
|