llvm-svn: 193823

llvm-svn: 193822

Workaround the DWARF info is anticipating the derived class assignment issue in this test case for now

llvm-svn: 193821

llvm-svn: 193820

llvm-svn: 193819

Further fixes to the dynamic type system prompted by ObjCDataFormatterTestCase.test_nserror_with_dsym_and_run_command

llvm-svn: 193818

llvm-svn: 193817

llvm-svn: 193816

This change makes Module::buildVisibleModulesCache() collect exported modules
recursively.

While computing a set of exports, getExportedModules() iterates over the set of
imported modules and filters it.  But it does not consider the set of exports
of those modules -- it is the responsibility of the caller to do this.

Here is a certain instance of this issue.  Module::isModuleVisible says that
CoreFoundation.CFArray submodule is not visible from Cocoa.  Why?

- Cocoa imports Foundation.
- Foundation has an export restriction: "export *".
- Foundation imports CoreFoundation.  (Just the top-level module.)
- CoreFoundation exports CoreFoundation.CFArray.

To decide which modules are visible from Cocoa, we collect all exported modules
from immediate imports in Cocoa:

> visibleModulesFro(Cocoa) = exported(Foundation) + exported(CoreData) + exported(AppKit)

To find out which modules are exported, we filter imports according to
restrictions:

> exported(Foundation) = filterByModuleMapRestrictions(imports(Foundation))

Because Foundation imports CoreFoundation (not CoreFoundation.CFArray), the
CFArray submodule is considered not exported from Foundation, and is not
visible from Cocoa (according to Module::isModuleVisible).

llvm-svn: 193815

LWG issue 2341; Make the two variants of basic_ostream::seekp and basic_istream::seekg behave consistently; update tests to make sure

llvm-svn: 193814

llvm-svn: 193813

llvm-svn: 193812

Originally implemented by Lang Hames.

llvm-svn: 193811

llvm-svn: 193810

llvm-svn: 193809

Given that backend does not handle "invoke asm" correctly ("invoke asm" will be
handled by SelectionDAGBuilder::visitInlineAsm, which does not have the right
setup for LPadToCallSiteMap) and we already made the assumption that inline asm
does not throw in InstCombiner::visitCallSite, we are going to make the same
assumption in Inliner to make sure we don't convert "call asm" to "invoke asm".

If it becomes necessary to add support for "invoke asm" later on, we will need
to modify the backend as well as remove the assumptions that inline asm does
not throw.

Fix rdar://15317907

llvm-svn: 193808

Summary:
TSan and MSan need to know if interceptor was called by the
user code or by the symbolizer and use pre- and post-symbolization hooks
for that. Make Symbolizer class responsible for calling these hooks instead.
This would ensure the hooks are only called when necessary (during
in-process symbolization, they are not needed for out-of-process) and
save specific sanitizers from tracing all places in the code where symbolization
will be performed.

Reviewers: eugenis, dvyukov

Reviewed By: eugenis

CC: llvm-commits

Differential Revision: http://llvm-reviews.chandlerc.com/D2067

llvm-svn: 193807

llvm-svn: 193806

llvm-svn: 193805

llvm-svn: 193804

QualType with a SourceLocation stashed alongside.

llvm-svn: 193803

llvm-svn: 193802

llvm-svn: 193801

There are two ways one could implement hiding of linkonce_odr symbols in LTO:
* LLVM tells the linker which symbols can be hidden if not used from native
  files.
* The linker tells LLVM which symbols are not used from other object files,
  but will be put in the dso symbol table if present.

GOLD's API is the second option. It was implemented almost 1:1 in llvm by
passing the list down to internalize.

LLVM already had partial support for the first option. It is also very similar
to how ld64 handles hiding these symbols when *not* doing LTO.

This patch then
* removes the APIs for the DSO list.
* marks LTO_SYMBOL_SCOPE_DEFAULT_CAN_BE_HIDDEN all linkonce_odr unnamed_addr
  global values and other linkonce_odr whose address is not used.
* makes the gold plugin responsible for handling the API mismatch.

llvm-svn: 193800

llvm-svn: 193799

llvm-svn: 193798

llvm-svn: 193797

llvm-svn: 193796

llvm-svn: 193795

llvm-svn: 193794

llvm-svn: 193793

llvm-svn: 193792

llvm-svn: 193791

llvm-svn: 193790

llvm-svn: 193789

llvm-svn: 193788

That way the test won't start faililng when someone adds a new attribute
and wants to use the next logical enum (38) for bitcode.  The new
bitcode file tries to use the number 48 as an attribute instead.

llvm-svn: 193787

SBValue::GetValueAsUnsigned()/GetValueAsSigned() should not replicate the Scalar manipulation logic found in ValueObject, but rather just call down to it

llvm-svn: 193786

llvm-svn: 193785

Added more details on the exact version of the cxa_demangle.cpp file for the built in demangler. This will help us track when we need to update this file.

llvm-svn: 193784