| Commit message (Collapse) | Author | Age | Files | Lines |
| |
|
|
|
|
| |
which is what N32/64 does.
llvm-svn: 148875
|
| |
|
|
|
|
| |
lvalue-to-rvalue conversion.
llvm-svn: 148874
|
| |
|
|
|
|
| |
Builtins.
llvm-svn: 148873
|
| |
|
|
| |
llvm-svn: 148872
|
| |
|
|
| |
llvm-svn: 148871
|
| |
|
|
|
|
|
|
|
| |
an error along with its boolean result. The
expression parser reports this error if the
interpreter fails and the expression could not be
run in the target.
llvm-svn: 148870
|
| |
|
|
| |
llvm-svn: 148869
|
| |
|
|
|
|
| |
(Uses the functionality which has been in CmpRuns long before.)
llvm-svn: 148868
|
| |
|
|
|
|
| |
diagnostic message).
llvm-svn: 148867
|
| |
|
|
|
|
| |
uncaught_exception() from cxa_vector.cpp. libc++abi is very nearly a self-contained (though not complete) library now.
llvm-svn: 148866
|
| |
|
|
|
|
|
|
| |
When not using subsections via symbols, the assembler can resolve
symbol differences (including pcrel references) to non-local
labels at assembly time, not just those in the same atom.
llvm-svn: 148865
|
| |
|
|
|
|
| |
instructions, for intel syntax.
llvm-svn: 148864
|
| |
|
|
|
|
| |
testing purposes. We've agreed to simply rename fallback_malloc.cpp to fallback_malloc.ipp. Thanks Marshall.
llvm-svn: 148863
|
| |
|
|
| |
llvm-svn: 148862
|
| |
|
|
|
|
|
|
| |
for forward references of classes and protocols, this breaks libclang API usage.
rdar://10747438.
llvm-svn: 148861
|
| |
|
|
|
|
| |
under #DEBUG (again).
llvm-svn: 148860
|
| |
|
|
|
|
| |
Fixes PR 9466.
llvm-svn: 148859
|
| |
|
|
| |
llvm-svn: 148858
|
| |
|
|
|
|
|
| |
allocator to construct an object which declares more alignment than the default
allocator actually provides. Fixes PR9527!
llvm-svn: 148857
|
| |
|
|
| |
llvm-svn: 148856
|
| |
|
|
|
|
| |
header. I've manually included it into the only place it is used: cxa_exception.cpp.
llvm-svn: 148854
|
| |
|
|
| |
llvm-svn: 148853
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
of the target triple to stand in for the "host" triple.
Thanks to a great conversation with Richard Smith, I'm now much more
confident in how this is proceeding. In all of the places where we
currently reason about the "host" architecture or triple, what we really
want to reason about in the detected GCC installation architecture or
triple, and the ways in which that differs from the target. When we find
a GCC installation with a different triple from our target *but capable
of targeting our target* through an option such as '-m64', we want to
detect *that* case and change the paths within the GCC installation (and
libstdc++ installation) to reflect this difference.
This patch makes one function do this correctly. Subsequent commits will
hoist the logic used here into the GCCInstallation utility, and then
reuse it through the rest of the toolchains to fix the remaining places
where this is currently happening.
llvm-svn: 148852
|
| |
|
|
|
|
| |
Thanks for the suggestion Doug. The use is consistent with how the same header is used in llvm/lib/Support/PrettyStackTrace.cpp (though there autoconfig is used instead of __has_include).
llvm-svn: 148851
|
| |
|
|
| |
llvm-svn: 148850
|
| |
|
|
| |
llvm-svn: 148849
|
| |
|
|
|
|
|
|
|
| |
forward reference, do give an interface or protocol cursor back, don't give
an 'UnexposedDecl' one.
rdar://10743193
llvm-svn: 148848
|
| |
|
|
|
|
| |
an objc object in any abi mode.
llvm-svn: 148847
|
| |
|
|
| |
llvm-svn: 148846
|
| |
|
|
| |
llvm-svn: 148844
|
| |
|
|
|
|
|
|
|
|
| |
inside of GCCInstallation to be a proper llvm::Triple. This is still
a touch ugly because we have to use it as a string in so many places,
but I think on the whole the more structured representation is better.
Comments of course welcome if this tradeoff isn't working for folks.
llvm-svn: 148843
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
will allow to disable
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.
llvm-svn: 148842
|
| |
|
|
|
|
|
|
| |
I can't read Java-style 'Gcc' acronyms. ;]
No functionality changed.
llvm-svn: 148840
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
function. The logic for this, and I want to emphasize that this is the
logic for computing the *target* triple, is currently scattered
throughout various different HostInfo classes ToolChain factoring
functions. Best part, it is largely *duplicated* there. The goal is to
hoist all of that up to here where we can deal with it once, and in
a consistent manner.
Unfortunately, this uncovers more fun problems: the ToolChains assume
that the *actual* target triple is the one passed into them by these
factory functions, while the *host* triple is the one in the driver.
This already was a lie, and a damn lie, when the '-target' flag was
specified. It only really worked when the difference stemmed from '-m32'
and '-m64' flags. I'll have to fix that (and remove all the FIXMEs I've
introduced here to document the problem) before I can finish hoisting
the target-calculation logic.
It's bugs all the way down today it seems...
llvm-svn: 148839
|
| |
|
|
|
|
|
|
|
|
| |
pointer to incomplete type from an ExtWarn to an error. We put the
ExtWarn in place as part of a workaround for Boost (PR6527), but it
(1) doesn't actually match a GCC extension and (2) has been fixed for
two years in Boost, and (3) causes us to emit code that fails badly at
run time, so it's a bad idea to keep it. Fixes PR11803.
llvm-svn: 148838
|
| |
|
|
| |
llvm-svn: 148836
|
| |
|
|
|
|
| |
accomodate every target I can think of offhand.
llvm-svn: 148833
|
| |
|
|
| |
llvm-svn: 148832
|
| |
|
|
|
|
| |
in the definition as well.
llvm-svn: 148831
|
| |
|
|
|
|
| |
default_terminate_handler. Recovered the equivalent functionality at a lower level.
llvm-svn: 148830
|
| |
|
|
|
|
| |
kOurDependentExceptionClass from source to header so that they can be used in multiple sources. This is a private header, these constants are not publicly exposed.
llvm-svn: 148829
|
| |
|
|
|
|
| |
header so that they can be used in multiple sources. This is a private header, these constants are not publicly exposed.
llvm-svn: 148827
|
| |
|
|
| |
llvm-svn: 148825
|
| |
|
|
|
|
| |
This will interleave the elements from two or more lists.
llvm-svn: 148824
|
| |
|
|
|
|
| |
// rdar://10731065
llvm-svn: 148823
|
| |
|
|
|
|
|
| |
dealing in the host triple, be honest about it and document the decision
to default the target triple to the host triple unless overridden.
llvm-svn: 148822
|
| |
|
|
| |
llvm-svn: 148821
|
| |
|
|
| |
llvm-svn: 148820
|
| |
|
|
| |
llvm-svn: 148819
|
| |
|
|
| |
llvm-svn: 148818
|