Summary:
MSVC always emits inline functions marked with the extern storage class
specifier. The result is something similar to the opposite of
__attribute__((gnu_inline)).
This extension is also available in C.
This fixes PR19264.
Reviewers: rnk, rsmith
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D3207
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205485 91177308-0d34-0410-b5e6-96231b3b80d8
Clang implements the part of the ARM ABI saying that certain functions
(e.g., constructors and destructors) return "this", but Apple's version of
gcc and llvm-gcc did not. The libstdc++ dylib on iOS 5 was built with
llvm-gcc, which means that clang cannot safely assume that code from the C++
runtime will correctly follow the ABI. It is also possible to run into this
problem when linking with other libraries built with gcc or llvm-gcc. Even
though there is no way to reliably detect that situation, it is most likely
to come up when targeting older versions of iOS. Disabling the optimization
for any code targeting iOS 5 solves the libstdc++ problem and has a reasonably
good chance of fixing the issue for other older libraries as well.
<rdar://problem/16377159>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205272 91177308-0d34-0410-b5e6-96231b3b80d8
This adds Clang support for the ARM64 backend. There are definitely
still some rough edges, so please bring up any issues you see with
this patch.
As with the LLVM commit though, we think it'll be more useful for
merging with AArch64 from within the tree.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205100 91177308-0d34-0410-b5e6-96231b3b80d8
The peculiarities of C99 create scenario where an LLVM IR function
declaration may need to be replaced with a definition baring a different
type because the prototype and definition are not required to agree.
However, we were not properly deferring this when it occurred.
This fixes PR19280.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@205099 91177308-0d34-0410-b5e6-96231b3b80d8
This produces valid IR now that llvm rejects aliases to weak aliases and warns
the user that the resolution is not changed if the weak alias is overridden.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204935 91177308-0d34-0410-b5e6-96231b3b80d8
COFF doesn't have mergeable sections so LLVM/clang's normal tactics for
string deduplication will not have any effect.
To remedy this we place each string inside it's own section and mark
the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the
string has an external name that we can generate from it's contents.
To be compatible with MSVC, we must use their scheme. Otherwise identical
strings in translation units from clang may not be deduplicated with
translation units in MSVC.
This fixes PR18248.
N.B. We will not attempt to do anything with a string literal which is not of
type 'char' or 'wchar_t' because their compiler does not support unicode
string literals as of this date. Further, we avoid doing this if
either -fwritable-strings or -fsanitize=address are present.
This reverts commit r204596.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204675 91177308-0d34-0410-b5e6-96231b3b80d8
This commit cleans up a few accidents:
- Do not rely on the order in which StringLiteral lays out bytes.
- Use a more efficient mechanism for handling so-called
"special-mappings" when mangling string literals.
- There is no need to allocate a copy of the mangled name.
- Add the test written for r204562.
Thanks to Richard Smith for pointing these out!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204586 91177308-0d34-0410-b5e6-96231b3b80d8
COFF doesn't have mergeable sections so LLVM/clang's normal tactics for
string deduplication will not have any effect.
To remedy this we place each string inside it's own section and mark
the section as IMAGE_COMDAT_SELECT_ANY. However, we can only do this if the
string has an external name that we can generate from it's contents.
To be compatible with MSVC, we must use their scheme. Otherwise identical
strings in translation units from clang may not be deduplicated with
translation units in MSVC.
This fixes PR18248.
N.B. We will not attempt to do anything with a string literal which is not of
type 'char' or 'wchar_t' because their compiler does not support unicode
string literals as of this date.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@204562 91177308-0d34-0410-b5e6-96231b3b80d8
I've clearly done something wrong with how to get this to link
correctly. Reverting for now.
This reverts commit r203711.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203712 91177308-0d34-0410-b5e6-96231b3b80d8
This updates CodeGenPGO to use the ProfileDataReader introduced to
llvm in r203703 and the new API for writing out the profile introduced
to compiler-rt in r203710.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203711 91177308-0d34-0410-b5e6-96231b3b80d8
r203364: what was use_iterator is now user_iterator, and there is
a use_iterator for directly iterating over the uses.
This also switches to use the range-based APIs where appropriate.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203365 91177308-0d34-0410-b5e6-96231b3b80d8
LLVM currently has a hack (shouldEmitUsedDirectiveFor) that causes it to not
print no_dead_strip for symbols starting with 'l' or 'L'. These are exactly the
ones that the clang's objc codegen is producing. The net result, is that it is
equivalent to llvm.compiler.used.
The need for putting the private symbol in llvm.compiler.used should be clear
(the objc runtime uses them). The reason for also putting the weak symbols in
it is for LTO: ld64 will not ask us to preserve the it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@203172 91177308-0d34-0410-b5e6-96231b3b80d8
We should only have this optimization fire when the explicit
instantiation definition would cause at least one member function to be
emitted, thus ensuring that even a compiler not performing this
optimization would still emit the full type information elsewhere.
But we should also pessimize output still by always emitting the
definition when the explicit instantiation definition appears so that at
some point in the future we can depend on that information even when no
code had to be emitted in that TU. (this shouldn't happen very often,
since people mostly use explicit spec decl/defs to reduce code size -
but perhaps one day they could use it to explicitly reduce debug info
size too)
This was worth about 2% for Clang and LLVM - so not a huge win, but a
win. It looks really great for simple STL programs (include <string> and
just declare a string - 14k -> 1.4k of .dwo)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202769 91177308-0d34-0410-b5e6-96231b3b80d8
The __forceinline keyword's semantics are now recast as AlwaysInline and
the kw___forceinline token has its language mode set for KEYMS.
This preserves the semantics of the previous implementation but with
less duplication of code.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@202131 91177308-0d34-0410-b5e6-96231b3b80d8
Xcore target ABI requires const data that is externally visible
to be handled differently if it has C-language linkage rather than
C++ language linkage.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@201142 91177308-0d34-0410-b5e6-96231b3b80d8
Replace the last incorrect uses and templatize the function to require a
compile-time constant string preventing further misuse.
The diagnostic formatter expects well-formed input and has undefined behaviour
with arbitrary input or crafted user strings in source files. Accepting user
input would also have caused unbounded generation of new diagnostic IDs which
can be problematic in long-running sessions or language bindings.
This completes the work to fix several incorrect callers that passed user
input or raw messages to the diagnostics engine where a constant format string
was expected.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@200132 91177308-0d34-0410-b5e6-96231b3b80d8
Without them they can be merged with non unnamed_addr constants during LTO.
The resulting constant is not unnamed_addr and goes in a different section,
which causes ld64 to crash.
A testcase that would crash before:
* file1.mm:
void g(id notification) {
[notification valueForKey:@"name"];
}
* file2.cpp:
extern const char js_name_str[] = "name";
* file3.cpp
extern bool JS_GetProperty(const char *name);
extern const char js_name_str[];
bool js_ReportUncaughtException() { JS_GetProperty(js_name_str); }
run
clang file1.mm -o file1.o -c -w -emit-llvm
clang file2.cpp -o file2.o -c -w -emit-llvm
clang file3.cpp -o file3.o -c -w
ld -dylib -o XUL file1.o file2.o file3.o -undefined dynamic_lookup.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199688 91177308-0d34-0410-b5e6-96231b3b80d8
With the old linkage types removed, set the linkage to external for both
dllimport and dllexport to reflect what's currently supported.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@199220 91177308-0d34-0410-b5e6-96231b3b80d8
encodes the canonical rules for LLVM's style. I noticed this had drifted
quite a bit when cleaning up LLVM, so wanted to clean up Clang as well.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198686 91177308-0d34-0410-b5e6-96231b3b80d8
'create' functions conventionally return a pointer, not a reference.
Also use an OwningPtr to get replace the delete of a reference member.
No functional change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@198126 91177308-0d34-0410-b5e6-96231b3b80d8
We were mistakengly giving linkonce_odr linkage instead of internal
linkage to the deleting and complete destructor thunks for classes in
anonymous namespaces.
Fixes PR17273.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@197060 91177308-0d34-0410-b5e6-96231b3b80d8
Thread an optional GV down to EmitGlobalFunctionDefinition so that it can
avoid the lookup when we already know the corresponding llvm global value.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196789 91177308-0d34-0410-b5e6-96231b3b80d8
We can reuse it to avoid a DenseMap+StringMap lookup to find if it was already
emitted or not.
This fixes a 2010 TODO.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196785 91177308-0d34-0410-b5e6-96231b3b80d8
Before this patch GetOrCreateLLVMFunction would add a decl to
DeferredDeclsToEmit even when it was being called by the function trying to
emit that decl.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@196753 91177308-0d34-0410-b5e6-96231b3b80d8
The original decls are created when used. The replacements are created at the
end of the TU in reverse order.
This makes the original order far better for testing. This is particularly
important since the replacement logic could be used even when
-mconstructor-aliases is not used, but that would make many tests hard to read.
This is a fixed version of r194357 which handles replacing a destructor with
another which is an alias to a third one.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194452 91177308-0d34-0410-b5e6-96231b3b80d8
The original decls are created when used. The replacements are created at the
end of the TU in reverse order.
This makes the original order far better for testing. This is particularly
important since the replacement logic could be used even when
-mconstructor-aliases is not used, but that would make many tests hard to read.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194357 91177308-0d34-0410-b5e6-96231b3b80d8
This is a small optimization on linux, but should help more on windows
where msvc only outputs one destructor if there would be two identical ones.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194095 91177308-0d34-0410-b5e6-96231b3b80d8
deallocation function (and the corresponding unsized deallocation function has
been declared), emit a weak discardable definition of the function that
forwards to the corresponding unsized deallocation.
This allows a C++ standard library implementation to provide both a sized and
an unsized deallocation function, where the unsized one does not just call the
sized one, for instance by putting both in the same object file within an
archive.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@194055 91177308-0d34-0410-b5e6-96231b3b80d8
This is a fixed version of r193161. In order to handle
void foo() __attribute__((alias("bar")));
void bar() {}
void zed() __attribute__((alias("foo")));
it is not enough to delay aliases to the end of the TU, we have to do two
passes over them to find if they are defined or not.
This can be implemented by producing alias as we go and just doing the second
pass at the end. This has the advantage that other parts of clang that were
expecting alias to be processed in order don't have to be changed.
This patch also handles cyclic aliases.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193188 91177308-0d34-0410-b5e6-96231b3b80d8
This reverts commit r193161.
It broke
void foo() __attribute__((alias("bar")));
void bar() {}
void zed() __attribute__((alias("foo")));
Looks like we have to fix pr17639 first :-(
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193162 91177308-0d34-0410-b5e6-96231b3b80d8
names. For example, with this patch we now reject
void f1(void) __attribute__((alias("g1")));
This patch is implemented in CodeGen. It is quiet a bit simpler and more
compatible with gcc than implementing it in Sema. The downside is that the
errors only fire during -emit-llvm.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@193161 91177308-0d34-0410-b5e6-96231b3b80d8
An updated version of r191586 with bug fix.
Struct-path aware TBAA generates tags to specify the access path,
while scalar TBAA only generates tags to scalar types.
We should not generate a TBAA tag with null being the first field. When
a TBAA type node is null, the tag should be null too. Make sure we
don't decorate an instruction with a null TBAA tag.
Added a testing case for the bug reported by Richard with -relaxed-aliasing
and -fsanitizer=thread.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@192145 91177308-0d34-0410-b5e6-96231b3b80d8
Struct-path aware TBAA generates tags to specify the access path,
while scalar TBAA only generates tags to scalar types.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@191586 91177308-0d34-0410-b5e6-96231b3b80d8
A quirk of AST representation leads to class template static data member
definitions being visited twice during Clang IRGen resulting in
duplicate (benign) initializers.
Discovered while investigating a possibly-related debug info bug tickled
by the duplicate emission of these members & their associated debug
info.
With thanks to Richard Smith for help investigating, understanding, and
helping with the fix.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@189996 91177308-0d34-0410-b5e6-96231b3b80d8
Refactor the underlying code a bit to remove unnecessary calls to
"hasErrorOccurred" & make them consistently at all the entry points to
the IRGen ASTConsumer.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188707 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
We would crash in CodeGen::CodeGenModule::EmitUuidofInitializer
because our attempt to enter CodeGen::CodeGenModule::EmitConstantValue
will be foiled: the type of the constant value is incomplete.
Instead, create an unnamed type with the proper layout on all platforms.
Punt the problem of wrongly defined struct _GUID types to the user.
(It's impossible because the TU may never get to see the type and thus
we can't verify that it is suitable.)
This fixes PR16856.
Reviewers: rsmith, rnk, thakis
Reviewed By: rnk
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1375
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188481 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
It seems that __uuidof introduces a global extern "C" declaration of
type __s_GUID. However, our implementation of __uuidof does not provide
such a declaration and thus must open-code the mangling for __uuidof in
template parameters.
This allows us to codegen scoped COM pointers and other such things.
This fixes PR16836.
Depends on D1356.
Reviewers: rnk, cdavis5x, rsmith
Reviewed By: rnk
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1357
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188252 91177308-0d34-0410-b5e6-96231b3b80d8
We mangled them like:
L___uuid_12345678-1234-1234-1234-123456789abc
We should've mangled them like:
__GUID_12345678_1234_1234_1234_123456789abc
Furthermore, they are external symbols.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@188053 91177308-0d34-0410-b5e6-96231b3b80d8
Based on Peter Collingbourne's destructor patches.
Prior to this change, clang was considering ?1 to be the complete
destructor and the base destructor, which was wrong. This lead to
crashes when clang tried to emit two LLVM functions with the same name.
In this ABI, TUs with non-inline dtors might not emit a complete
destructor. They are emitted as inline thunks in TUs that need them,
and they always delegate to the base dtors of the complete class and its
virtual bases. This change uses the DeferredDecls machinery to emit
complete dtors as needed.
Currently in clang try body destructors can catch exceptions thrown by
virtual base destructors. In the Microsoft C++ ABI, clang may not have
the destructor definition, in which case clang won't wrap the virtual
virtual base destructor calls in a try-catch. Diagnosing this in user
code is TODO.
Finally, for classes that don't use virtual inheritance, MSVC always
calls the base destructor (?1) directly. This is a useful code size
optimization that avoids emitting lots of extra thunks or aliases.
Implementing it also means our existing tests continue to pass, and is
consistent with MSVC's output.
We can do the same for Itanium by tweaking GetAddrOfCXXDestructor, but
it will require further testing.
Reviewers: rjmccall
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D1066
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186828 91177308-0d34-0410-b5e6-96231b3b80d8
optimize, to follow the permissions granted in N3664. Under those rules, only
calls generated by new-expressions and delete-expressions are permitted to be
optimized, and direct calls to ::operator new and ::operator delete must be
treated as normal calls.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@186799 91177308-0d34-0410-b5e6-96231b3b80d8
The key insight here is that weak linkage for a static local variable
should always mean linkonce_odr, because every file that needs it will
generate a definition. We don't actually care about the precise linkage
of the parent context. I feel a bit silly that I didn't realize this before.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185381 91177308-0d34-0410-b5e6-96231b3b80d8
Blocks, like lambdas, can be written in contexts which are required to be
treated as the same under ODR. Unlike lambdas, it isn't possible to actually
take the address of a block, so the mangling of the block itself doesn't
matter. However, objects like static variables inside a block do need to
be mangled in a consistent way.
There are basically three components here. One, block literals need a
consistent numbering. Two, objects/types inside a block literal need
to be mangled using it. Three, objects/types inside a block literal need
to have their linkage computed correctly.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185372 91177308-0d34-0410-b5e6-96231b3b80d8
This allows clang to use the backend parameter attribute 'returned' when generating 'this'-returning constructors and destructors in ARM and MSVC C++ ABIs.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@185291 91177308-0d34-0410-b5e6-96231b3b80d8
These options will add a module flag with name "Dwarf Version".
The behavior flag is currently set to Warning, so when two values disagree,
a warning will be emitted.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184276 91177308-0d34-0410-b5e6-96231b3b80d8
The backend will now use the generic 'returned' attribute to form tail calls where possible, as well as avoid save-restores of 'this' in some cases (specifically the cases that matter for the ARM C++ ABI).
This patch also reverts a prior front-end only partial implementation of these optimizations, since it's no longer required.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@184205 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce CXXStdInitializerListExpr node, representing the implicit
construction of a std::initializer_list<T> object from its underlying array.
The AST representation of such an expression goes from an InitListExpr with a
flag set, to a CXXStdInitializerListExpr containing a MaterializeTemporaryExpr
containing an InitListExpr (possibly wrapped in a CXXBindTemporaryExpr).
This more detailed representation has several advantages, the most important of
which is that the new MaterializeTemporaryExpr allows us to directly model
lifetime extension of the underlying temporary array. Using that, this patch
*drastically* simplifies the IR generation of this construct, provides IR
generation support for nested global initializer_list objects, fixes several
bugs where the destructors for the underlying array would accidentally not get
invoked, and provides constant expression evaluation support for
std::initializer_list objects.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183872 91177308-0d34-0410-b5e6-96231b3b80d8
handle temporaries which have been lifetime-extended to static storage duration
within constant expressions. This correctly handles nested lifetime extension
(through reference members of aggregates in aggregate initializers) but
non-constant-expression emission hasn't yet been updated to do the same.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@183283 91177308-0d34-0410-b5e6-96231b3b80d8
This removes a FIXME in CodeGenModule::SetLLVMFunctionAttributesForDefinition.
When a function is declared cold we can now generate the IR attribute in
addition to marking the function to be optimized for size.
I tried adding a separate CHECK in the existing test, but it was
failing. I suppose CHECK matches one line exactly once? This would be
a problem if the attributes are listed in a different order, though they
seem to be sorted.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182666 91177308-0d34-0410-b5e6-96231b3b80d8
This resolves the last of the PR14606 failures in the GDB 7.5 test
suite. (but there are still unresolved issues in the imported_decl case
- we need to implement optional/lazy decls for functions & variables
like we already do for types)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182329 91177308-0d34-0410-b5e6-96231b3b80d8
selectany only applies to externally visible global variables. It has
the effect of making the data weak_odr.
The MSDN docs suggest that unused definitions can only be dropped at
linktime, so Clang uses weak instead of linkonce. MSVC optimizes away
references to constant selectany data, so it must assume that there is
only one definition, hence weak_odr.
Reviewers: espindola
Differential Revision: http://llvm-reviews.chandlerc.com/D814
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@182266 91177308-0d34-0410-b5e6-96231b3b80d8
This patch renames getLinkage to getLinkageInternal. Only code that
needs to handle UniqueExternalLinkage specially should call this.
Linkage, as defined in the c++ standard, is provided by
getFormalLinkage. It maps UniqueExternalLinkage to ExternalLinkage.
Most places in the compiler actually want isExternallyVisible, which
handles UniqueExternalLinkage as internal.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181677 91177308-0d34-0410-b5e6-96231b3b80d8
Adding attributes to a uniqued set has become expensive, don't do it more often
than necessary. No functionality change.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181662 91177308-0d34-0410-b5e6-96231b3b80d8
for C++ constructors.
If the DIType for a class was generated by
CGDebugInfo::createContextChain(), the cache contains only a
limited DIType wihtout any declarations. Since EmitFunctionStart()
needs to find the canonical declaration for each method, we
construct the complete type before emitting any method.
rdar://problem/13116508
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181561 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Most of this change is wiring the pragma all the way through from the
lexer, parser, and sema to codegen. I considered adding a Decl AST node
for this, but it seemed too heavyweight.
Mach-O already uses a metadata flag called "Linker Options" to do this
kind of auto-linking. This change follows that pattern.
LLVM knows how to forward the "Linker Options" metadata into the COFF
.drectve section where these flags belong. ELF support is not
implemented, but possible.
This is related to auto-linking, which is http://llvm.org/PR13016.
CC: cfe-commits
Differential Revision: http://llvm-reviews.chandlerc.com/D723
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181426 91177308-0d34-0410-b5e6-96231b3b80d8
This patch adds a new common code feature that allows platform code to
request minimum alignment of global symbols. The background for this is
that on SystemZ, the most efficient way to load addresses of global symbol
is the LOAD ADDRESS RELATIVE LONG (LARL) instruction. This instruction
provides PC-relative addressing, but only to *even* addresses. For this
reason, existing compilers will guarantee that global symbols are always
aligned to at least 2. [ Since symbols would otherwise already use a
default alignment based on their type, this will usually only affect global
objects of character type or character arrays. ] GCC also allows creating
symbols without that extra alignment by using explicit "aligned" attributes
(which then need to be used on both definition and each use of the symbol).
To enable support for this with Clang, this patch adds a
TargetInfo::MinGlobalAlign variable that provides a global minimum for the
alignment of every global object (unless overridden via explicit alignment
attribute), and adds code to respect this setting. Within this patch, no
platform actually sets the value to anything but the default 1, resulting
in no change in behaviour on any existing target.
This version of the patch incorporates feedback from reviews by
Eric Christopher and John McCall. Thanks to all reviewers!
Patch by Richard Sandiford.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181210 91177308-0d34-0410-b5e6-96231b3b80d8
I was not able to find a case (other than the fix in r181163) where this
makes a difference, but it is a more obviously correct API to have.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@181165 91177308-0d34-0410-b5e6-96231b3b80d8
After some discussion, it was decided to use the Itanium ABI for thread_local on
Darwin OS X platforms. This involved a couple of changes. First, we use
"_tlv_atexit" instead of "__cxa_thread_atexit". Secondly, the global variables
are marked with 'internal' linkage, because we want all access to be calls to
the Itanium-specific entry point, which has normal linkage.
<rdar://problem/13733006>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180941 91177308-0d34-0410-b5e6-96231b3b80d8
Original commit message:
Emit the TLS intialization functions into a list.
Add the TLS initialization functions to a list of initialization functions. The
back-end takes this list and places the function pointers into the correct
section. This way they're called before `main().'
<rdar://problem/13733006>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180809 91177308-0d34-0410-b5e6-96231b3b80d8
Add the TLS initialization functions to a list of initialization functions. The
back-end takes this list and places the function pointers into the correct
section. This way they're called before `main().'
<rdar://problem/13733006>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@180739 91177308-0d34-0410-b5e6-96231b3b80d8
- There is no reason to have a modules specific flag for disabling
autolinking. Instead, convert the existing flag into -fno-autolink (which
should cover other autolinking code generation paths like #pragmas if and
when we support them).
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179612 91177308-0d34-0410-b5e6-96231b3b80d8
for caching couple of global symbols used
for generation of CF/NS string meta-data
so they are not released prematuely in certain
corner cases. // rdar:// 13598026.
Reviewed by John M.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179599 91177308-0d34-0410-b5e6-96231b3b80d8
non-constant constructors or non-trivial destructors. Plus bugfixes for
thread_local references bound to temporaries (the temporaries themselves are
lifetime-extended to become thread_local), and the corresponding case for
std::initializer_list.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179496 91177308-0d34-0410-b5e6-96231b3b80d8
For struct-path aware TBAA, we used to use scalar type node as the scalar tag,
which has an incompatible format with the struct path tag. We now use the same
format: base type, access type and offset.
We also uniformize the scalar type node and the struct type node: name, a list
of pairs (offset + pointer to MDNode). For scalar type, we have a single pair.
These are to make implementaiton of aliasing rules easier.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@179335 91177308-0d34-0410-b5e6-96231b3b80d8
linkage specification, and is marked as __attribute__((used)), try to also give
it the unmangled name (by emitting an internal linkage alias) if nothing else
within the translation unit would use that name. This allows inline asm in that
translation unit to use the entity via its unmangled name, which people
apparently rely on.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178950 91177308-0d34-0410-b5e6-96231b3b80d8
Added TBAABaseType and TBAAOffset in LValue. These two fields are initialized to
the actual type and 0, and are updated in EmitLValueForField.
Path-aware TBAA tags are enabled for EmitLoadOfScalar and EmitStoreOfScalar.
Added command line option -struct-path-tbaa.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178797 91177308-0d34-0410-b5e6-96231b3b80d8
For variables and functions clang used to store two storage classes. The one
"as written" in the code and a patched one, which, for example, propagates
static to the following decls.
This apparently is from the days clang lacked linkage computation. It is now
redundant and this patch removes it.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@178663 91177308-0d34-0410-b5e6-96231b3b80d8
calls and declarations.
LLVM has a default CC determined by the target triple. This is
not always the actual default CC for the ABI we've been asked to
target, and so we sometimes find ourselves annotating all user
functions with an explicit calling convention. Since these
calling conventions usually agree for the simple set of argument
types passed to most runtime functions, using the LLVM-default CC
in principle has no effect. However, the LLVM optimizer goes
into histrionics if it sees this kind of formal CC mismatch,
since it has no concept of CC compatibility. Therefore, if this
module happens to define the "runtime" function, or got LTO'ed
with such a definition, we can miscompile; so it's quite
important to get this right.
Defining runtime functions locally is quite common in embedded
applications.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176286 91177308-0d34-0410-b5e6-96231b3b80d8
Everything that cares about visibility also cares about linkage, so I just
moved it to Visibility.h instead of creating a new .h.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176155 91177308-0d34-0410-b5e6-96231b3b80d8
These are two related changes (one in llvm, one in clang).
LLVM:
- rename address_safety => sanitize_address (the enum value is the same, so we preserve binary compatibility with old bitcode)
- rename thread_safety => sanitize_thread
- rename no_uninitialized_checks -> sanitize_memory
CLANG:
- add __attribute__((no_sanitize_address)) as a synonym for __attribute__((no_address_safety_analysis))
- add __attribute__((no_sanitize_thread))
- add __attribute__((no_sanitize_memory))
for S in address thread memory
If -fsanitize=S is present and __attribute__((no_sanitize_S)) is not
set llvm attribute sanitize_S
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@176076 91177308-0d34-0410-b5e6-96231b3b80d8
just using ASTConsumer::HandleCXXStaticMemberVarInstantiation(), don't pass it with
ASTConsumer::HandleTopLevelDecl.
ASTConsumer::HandleTopLevelDecl is intended for user-written top-level decls;
a consumer can treat an instantiated static data member however it wants of course.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175976 91177308-0d34-0410-b5e6-96231b3b80d8
Introduce a new AST Decl node "EmptyDecl" to model empty-declaration. Have attributes from attribute-declaration appertain
to the EmptyDecl node by creating the AST representations of these attributes and attach them to the EmptyDecl node so these
attributes can be sema checked just as attributes attached to "normal" declarations.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175900 91177308-0d34-0410-b5e6-96231b3b80d8
control the visibility of a type for the purposes of RTTI
and template argument restrictions independently of how
visibility propagates to its non-type member declarations.
Also fix r175326 to not ignore template argument visibility
on a template explicit instantiation when a member has
an explicit attribute but the instantiation does not.
The type_visibility work is rdar://11880378
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175587 91177308-0d34-0410-b5e6-96231b3b80d8
The code generation stuff is going to set attributes on the functions it
generates. To do that it needs the target options. Pass them through.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@175141 91177308-0d34-0410-b5e6-96231b3b80d8
Nearly all of these changes are one-to-one replacements; the few that
aren't have to do with custom identifier validation.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174768 91177308-0d34-0410-b5e6-96231b3b80d8
In cooperation with the LLVM patch, this should implement all scalar front-end
parts of the C and C++ ABIs for AArch64.
This patch excludes the NEON support also reviewed due to an outbreak of
batshit insanity in our legal department. That will be committed soon bringing
the changes to precisely what has been approved.
Further reviews would be gratefully received.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174055 91177308-0d34-0410-b5e6-96231b3b80d8
Several places were still treating the Attribute object as respresenting
multiple attributes. Those places now use the AttributeSet to represent
multiple attributes.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@174004 91177308-0d34-0410-b5e6-96231b3b80d8
In the future, AttributeWithIndex won't be used anymore. Besides, it exposes the
internals of the AttributeSet to outside users, which isn't goodness.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@173605 91177308-0d34-0410-b5e6-96231b3b80d8