- Apr 23, 2011
-
-
Francois Pichet authored
Add -fdelayed-template-parsing option. Using this option all templated function definitions are parsed at the end of the translation unit only if it is required by an actual instantiation. As such all the symbols of the TU are available during name lookup. Using this flag is necessary for compatibility with Microsoft template code. This also provides some parsing speed improvement. llvm-svn: 130022
-
- Apr 22, 2011
-
-
Nick Lewycky authored
compile time) and .gcda emission (at runtime). --coverage enables both. This does not yet add the profile_rt library to the link step if -fprofile-arcs is enabled when linking. llvm-svn: 129956
-
- Apr 21, 2011
-
-
Jay Foad authored
llvm-svn: 129929
-
- Apr 19, 2011
-
-
Daniel Dunbar authored
llvm-svn: 129823
-
- Apr 13, 2011
-
-
Daniel Dunbar authored
there is no reason to align them higher. - This roughly matches llvm-gcc's r126913. - It is an open question whether or not we should do this for cstring's in general (code size vs optimization potential), for now we just match llvm-gcc until someone wants to run some experiments. llvm-svn: 129410
-
- Apr 12, 2011
-
-
John McCall authored
weak linkage. Also, fix a problem where global weak variables with non-trivial initializers were getting guard variables, or at least were checking for them and then crashing. llvm-svn: 129342
-
John McCall authored
llvm-svn: 129337
-
John McCall authored
for __unknown_anytype resolution to destructively modify the AST. So that's what it does now, which significantly simplifies some of the implementation. Normal member calls work pretty cleanly now, and I added support for propagating unknown-ness through &. llvm-svn: 129331
-
- Apr 09, 2011
-
-
Chris Lattner authored
llvm-svn: 129202
-
- Apr 07, 2011
-
-
John McCall authored
The idea is that you can create a VarDecl with an unknown type, or a FunctionDecl with an unknown return type, and it will still be valid to access that object as long as you explicitly cast it at every use. I'm still going back and forth about how I want to test this effectively, but I wanted to go ahead and provide a skeletal implementation for the LLDB folks' benefit and because it also improves some diagnostic goodness for placeholder expressions. llvm-svn: 129065
-
- Apr 06, 2011
-
-
Peter Collingbourne authored
llvm-svn: 129000
-
- Mar 26, 2011
-
-
Douglas Gregor authored
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
-
- Mar 23, 2011
-
-
Devang Patel authored
Radar 9168773 llvm-svn: 128150
-
Douglas Gregor authored
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
-
- Mar 22, 2011
-
-
David Chisnall authored
Simplify Mac runtime selection - it's the factory function's job to select which class to produce, not CodeGenModule's. llvm-svn: 128109
-
John McCall authored
conditioned on whether it has any destructible ivars, not on whether it has any non-trivial class-object initializers. llvm-svn: 128074
-
- Mar 18, 2011
-
-
Peter Collingbourne authored
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
-
John McCall authored
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
-
- Mar 17, 2011
-
-
David Chisnall authored
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
-
- Mar 14, 2011
-
-
Rafael Espindola authored
llvm-svn: 127622
-
Rafael Espindola authored
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
-
- Mar 09, 2011
-
-
John McCall authored
recomputation. llvm-svn: 127322
-
John McCall authored
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
-
- Mar 07, 2011
-
-
Devang Patel authored
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
-
Devang Patel authored
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
-
- Mar 05, 2011
-
-
Benjamin Kramer authored
llvm-svn: 127082
-
- Feb 22, 2011
-
-
John McCall authored
llvm-svn: 126189
-
- Feb 19, 2011
-
-
John McCall authored
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
-
- Feb 15, 2011
-
-
John McCall authored
- 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
-
- Feb 11, 2011
-
-
Rafael Espindola authored
llvm-svn: 125321
-
- Feb 09, 2011
-
-
Douglas Gregor authored
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
-
- Feb 08, 2011
-
-
John McCall authored
Block{Function,Module} base class. Minor other refactorings. Fixed a few address-space bugs while I was there. llvm-svn: 125085
-
- Feb 05, 2011
-
-
Anders Carlsson authored
We now emit everything except unused implicit virtual member functions when building the vtable. llvm-svn: 124935
-
- Feb 04, 2011
-
-
Fariborz Jahanian authored
llvm-svn: 124837
-
Fariborz Jahanian authored
llvm-svn: 124835
-
Fariborz Jahanian authored
abi. llvm-svn: 124834
-
- Feb 03, 2011
-
-
Rafael Espindola authored
This reopens PR99114, but that one at least can be avoided with an #include. PR9130 cannot. llvm-svn: 124780
-
Anders Carlsson authored
is not defined in the current translation unit. Doing so lead to compile errors such as PR9114. Instead, when CodeGen is building the vtable, don't try to emit a definition for functions that aren't marked used in the current translation unit. Fixes PR9114. llvm-svn: 124768
-
- Feb 01, 2011
-
-
Rafael Espindola authored
llvm-svn: 124651
-
Rafael Espindola authored
* llvm-link would complains about mismatched visibility * If we produce a relocation with an available_externally, it is good to know that it is hidden. llvm-svn: 124633
-