History log of /llvm-project-15.0.7/clang/lib/CodeGen/CodeGenModule.cpp (Results 1301 – 1325 of 1864)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
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


1...<<51525354555657585960>>...75