These patches cause us to miscompile and/or reject code with static
function-local variables in an extern-C context. Previously, we were
papering over this as long as the variables are within the same
translation unit, and had not seen any failures in the wild. We still
need a proper fix, which involves mangling static locals inside of an
extern-C block (as GCC already does), but this patch causes pretty
widespread regressions. Firefox, and many other applications no longer
build.
Lots of test cases have been posted to the list in response to this
commit, so there should be no problem reproducing the issues.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153768 91177308-0d34-0410-b5e6-96231b3b80d8
section. A 'normal' string will go into the __TEXT,__const section, but this
isn't good for UTF16 strings. The __ustring section allows for coalescing, among
other niceties (such as allowing the linker to easily split up strings).
Instead of outputting the UTF16 string as a series of bytes, output it as a
series of shorts. The back-end will then nicely place the UTF16 string into the
correct section, because it's a mensch.
<rdar://problem/10655949>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@153710 91177308-0d34-0410-b5e6-96231b3b80d8
The member variable is always "LangOpts" and the member function is always "getLangOpts".
Reviewed by Chris Lattner
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152536 91177308-0d34-0410-b5e6-96231b3b80d8
In the included testcase, soma thinks that we already have a definition after we
see the out of line decl. Codegen puts it in a deferred list, to be output if
a use is seen. This would break when we saw an explicit template instantiation
definition, since codegen would not be notified.
This patch adds a method to the consumer interface so that soma can notify
codegen that this decl is now required.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@152024 91177308-0d34-0410-b5e6-96231b3b80d8
scalar emission of DeclRefExprs to const bools: emit scalar bools as i1,
not as i8.
In addition to the extra unit testing, this has successfully bootstrapped.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151955 91177308-0d34-0410-b5e6-96231b3b80d8
This emits a backing array with internal linkage and fills it with data,
then has the initializer_list point at the array. Dynamic initialization
and global destructors are correctly supported.
What doesn't work is nested initializer_lists. I have no idea how to
get them to work, either. However, these should be very rare, and so
I'll just call it a known bug and declare generalized initializers
DONE!
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@151457 91177308-0d34-0410-b5e6-96231b3b80d8
emit less than complete types on purpose on occasion and so
our caches aren't useful for this kind of lazy emitting.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150856 91177308-0d34-0410-b5e6-96231b3b80d8
as constants.
Refactor and simplify all the separate checks for whether a type can be
emitted as a constant.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150793 91177308-0d34-0410-b5e6-96231b3b80d8
1) It has a const-qualified type, and
2) It has no mutable members, and
3) It has no dynamic initialization, and
4) It has trivial destruction.
Remove the unnecessary requirement that the type be POD. This allows us to
mark all constexpr objects with no mutable members as 'constant'.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150792 91177308-0d34-0410-b5e6-96231b3b80d8
optional argument passed through the variadic ellipsis)
potentially affects how we need to lower it. Propagate
this information down to the various getFunctionInfo(...)
overloads on CodeGenTypes. Furthermore, rename those
overloads to clarify their distinct purposes, and make
sure we're calling the right one in the right place.
This has a nice side-effect of making it easier to construct
a function type, since the 'variadic' bit is no longer
separable.
This shouldn't really change anything for our existing
platforms, with one minor exception --- we should now call
variadic ObjC methods with the ... in the "right place"
(see the test case), which I guess matters for anyone
running GNUStep on MIPS. Mostly it's just a substantial
clean-up.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150788 91177308-0d34-0410-b5e6-96231b3b80d8
-fno-objc-arc-exceptions. This will allow the optimizer to perform
optimizations which are only safe under that flag.
This is a part of rdar://10803830.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150644 91177308-0d34-0410-b5e6-96231b3b80d8
constructor, and that constructor is used to initialize an object of static
storage duration such that all members and bases are initialized by constant
expressions, constant initialization is performed. In this case, the object
can still have a non-trivial destructor, and if it does, we must emit a dynamic
initializer which performs no initialization and instead simply registers that
destructor.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@150419 91177308-0d34-0410-b5e6-96231b3b80d8
(I was going to fix the TODO about DenseMap too, but
that would break self-host right now. See PR11922.)
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149799 91177308-0d34-0410-b5e6-96231b3b80d8
commit 149470. This fixes test/CodeGen/PR3589-freestanding-libcalls.c.
Original log:
ConstantArray::get() (for strings) is going away, use
ConstantDataArray::getString instead.
Many instances of ConstantArray::get() could be moved to
use more efficient ConstantDataArray methods that avoid a ton
of intermediate Constant*'s for each element (e.g.
GetConstantArrayFromStringLiteral). I don't plan on doing this
in the short-term though.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149477 91177308-0d34-0410-b5e6-96231b3b80d8
ConstantDataArray::getString instead.
Many instances of ConstantArray::get() could be moved to
use more efficient ConstantDataArray methods that avoid a ton
of intermediate Constant*'s for each element (e.g.
GetConstantArrayFromStringLiteral). I don't plan on doing this
in the short-term though.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@149363 91177308-0d34-0410-b5e6-96231b3b80d8
address safety analysis (such as e.g. AddressSanitizer or SAFECode) for a specific function.
When building with AddressSanitizer, add AddressSafety function attribute to every generated function
except for those that have __attribute__((no_address_safety_analysis)).
With this patch we will be able to
1. disable AddressSanitizer for a particular function
2. disable AddressSanitizer-hostile optimizations (such as some cases of load widening) when AddressSanitizer is on.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148842 91177308-0d34-0410-b5e6-96231b3b80d8
we have a redeclarable type, and only use the new virtual versions
(getPreviousDeclImpl() and getMostRecentDeclImpl()) when we don't have
that type information. This keeps us from penalizing users with strict
type information (and is the moral equivalent of a "final" method).
Plus, settle on the names getPreviousDecl() and getMostRecentDecl()
throughout.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148187 91177308-0d34-0410-b5e6-96231b3b80d8
APValue::Array and APValue::MemberPointer. All APValue values can now be emitted
as constants.
Add new CGCXXABI entry point for emitting an APValue MemberPointer. The other
entrypoints dealing with constant member pointers are no longer necessary and
will be removed in a later change.
Switch codegen from using EvaluateAsRValue/EvaluateAsLValue to
VarDecl::evaluateValue. This performs caching and deals with the nasty cases in
C++11 where a non-const object's initializer can refer indirectly to
previously-initialized fields within the same object.
Building the intermediate APValue object incurs a measurable performance hit on
pathological testcases with huge initializer lists, so we continue to build IR
directly from the Expr nodes for array and record types outside of C++11.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@148178 91177308-0d34-0410-b5e6-96231b3b80d8
CFStrings writable.
The strings (both Unicode and ASCII) should reside in a read-only section. E.g.,
__TEXT,__cstring instead of __DATA,__data. This is done by making the global
variable created for the strings constant despite the value of that flag.
<rdar://problem/10657500>
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@147845 91177308-0d34-0410-b5e6-96231b3b80d8
itself via an asm label.
available_externally functions are supposed to correspond to an external
function, and that is not the case in the examples in pr9614.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@143049 91177308-0d34-0410-b5e6-96231b3b80d8
Start handling debug line and scope information better:
Migrate most of the location setting within the larger API in CGDebugInfo and
update a lot of callers.
Remove the existing file/scope change machinery in UpdateLineDirectiveRegion
and replace it with DILexicalBlockFile usage.
Finishes off the rest of rdar://10246360
after fixing a few bugs that were exposed in gdb testsuite testing.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141893 91177308-0d34-0410-b5e6-96231b3b80d8
Migrate most of the location setting within the larger API in CGDebugInfo and
update a lot of callers.
Remove the existing file/scope change machinery in UpdateLineDirectiveRegion
and replace it with DILexicalBlockFile usage.
Finishes off the rest of rdar://10246360
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141732 91177308-0d34-0410-b5e6-96231b3b80d8
This frontend-only flag is used by the IR generator to determine
whether to filter CUDA declarations for the host or for the device.
git-svn-id: https://llvm.org/svn/llvm-project/cfe/trunk@141301 91177308-0d34-0410-b5e6-96231b3b80d8