type_traits:3280:31: error: expected primary-expression before 'decltype'
type_traits:3280:29: error: expected ';' at end of member declaration
memory:2415:49: error: function 'std::__1::default_delete<_Tp>::default_delete()'
defaulted on its first declaration must not have an exception-specification
memory:2435:49: error: function 'std::__1::default_delete<_Tp []>::default_delete()'
defaulted on its first declaration must not have an exception-specification
The attached patch defines _LIBCPP_HAS_NO_ADVANCED_SFINAE and
_LIBCPP_HAS_NO_DEFAULTED_FUNCTIONS for gcc version < 4.7, making
the library compile with gcc 4.6.4.
llvm-svn: 195431
Some linux headers are broken on older kernels.
Instead of depending on the constants and types from such headers directly,
we provide our own definitions and then verify them with compile-time
assertions. This makes the dependency on the headers test-only and would allow
switching to some other way of testing on older kernels, or even disable the
tests as the last resort (after all, kernel interfaces are supposed to be
stable).
llvm-svn: 195427
can't accidentally be allocated the wrong way (missing prefix data for decls
from AST files, for instance) and simplifies the CreateDeserialized functions a
little. An extra DeclContext* parameter to the not-from-AST-file operator new
allows us to ensure that we don't accidentally call the wrong one when
deserializing (when we don't have a DeclContext), allows some extra checks, and
prepares for some planned modules-related changes to Decl allocation.
No functionality change intended.
llvm-svn: 195426
Diags aren't usually in the first person, and 'windows' isn't the correct
product spelling to use in prose. Sidestep issues completely by making this
error message platform-neutral.
llvm-svn: 195422
This matches other README.txt files in LLVM and makes things more obvious on
Windows where it's likely to be read. CRLFs are retained for the same reason.
Also fix Visual Studio product name.
llvm-svn: 195420
ASTUnit instances are allocated infrequently so it's fine to keep this field
around in all build configurations.
Assigns null to silence -Wunused-private-field in Release.
llvm-svn: 195419
We already have a method for returning one loop latch but for some
reason no one has committed one for returning loop latches in the case
where there are multiple latches.
llvm-svn: 195410
rather than the constructors of passes.
This simplifies the APIs of passes significantly and removes an error
prone pattern where the *same* manager had to be given to every
different layer. With the new API the analysis managers themselves will
have to be cross connected with proxy analyses that allow a pass at one
layer to query for the analysis manager of another layer. The proxy will
both expose a handle to the other layer's manager and it will provide
the invalidation hooks to ensure things remain consistent across layers.
Finally, the outer-most analysis manager has to be passed to the run
method of the outer-most pass manager. The rest of the propagation is
automatic.
I've used SFINAE again to allow passes to completely disregard the
analysis manager if they don't need or want to care. This helps keep
simple things simple for users of the new pass manager.
Also, the system specifically supports passing a null pointer into the
outer-most run method if your pass pipeline neither needs nor wants to
deal with analyses. I find this of dubious utility as while some
*passes* don't care about analysis, I'm not sure there are any
real-world users of the pass manager itself that need to avoid even
creating an analysis manager. But it is easy to support, so there we go.
Finally I renamed the module proxy for the function analysis manager to
the more verbose but less confusing name of
FunctionAnalysisManagerModuleProxy. I hate this name, but I have no idea
what else to name these things. I'm expecting in the fullness of time to
potentially have the complete cross product of types at the proxy layer:
{Module,SCC,Function,Loop,Region}AnalysisManager{Module,SCC,Function,Loop,Region}Proxy
(except for XAnalysisManagerXProxy which doesn't make any sense)
This should make it somewhat easier to do the next phases which is to
build the upward proxy and get its invalidation correct, as well as to
make the invalidation within the Module -> Function mapping pass be more
fine grained so as to invalidate fewer fuction analyses.
After all of the proxy analyses are done and the invalidation working,
I'll finally be able to start working on the next two fun fronts: how to
adapt an existing pass to work in both the legacy pass world and the new
one, and building the SCC, Loop, and Region counterparts. Fun times!
llvm-svn: 195400
Splitting a basic block will create a new ALU clause, so we need to make
sure we aren't moving uses of registers that are local to their
current clause into a new one.
I had a test case for this, but unfortunately unrelated schedule changes
invalidated it, and I wasn't been able to come up with another one.
NOTE: This is a candidate for the 3.4 branch.
llvm-svn: 195399
The legalizer can now do this type of expansion for more
type combinations without loading and storing to and
from the stack.
NOTE: This is a candidate for the 3.4 branch.
llvm-svn: 195398
This patch is a rewrite of the original patch commited in r194542. Instead of
relying on the type legalizer to do the splitting for us, we now peform the
splitting ourselves in the DAG combiner. This is necessary for the case where
the vector mask is a legal type after promotion and still wouldn't require
splitting.
Patch by: Juergen Ributzka
NOTE: This is a candidate for the 3.4 branch.
llvm-svn: 195397
Rework data formatters matching algorithm
What happens now is that, for each category, the FormatNavigator generates all possible matches, and checks them one by one
Since the possible matches do not actually depend on the category (whether a match is accepted or not does, but that check can be shifted at a more convenient time),
it is actually feasible to generate every possible match upfront and then let individual categories just scan through those
This commit changes things by introducing a notion of formatters match candidate, and shifting responsibility for generating all of them given a (ValueObject,DynamicValueType) pair
from the FormatNavigator back to the FormatManager
A list of these candidates is then passed down to each category for matching
Candidates also need to remember whether they were generated by stripping pointers, references, typedefs, since this is something that individual formatters can choose to reject
This check, however, is conveniently only done once a "textual" match has been found, so that the list of candidates is truly category-independent
While the performance benefit is small (mostly, due to caching), this is much cleaner from a design perspective
llvm-svn: 195395
section use the form DW_FORM_data4 whilst in Dwarf 4 and later they
use the form DW_FORM_sec_offset.
This patch updates the places where such attributes are generated to
use the appropriate form depending on the Dwarf version. The DIE entries
affected have the following tags:
DW_AT_stmt_list, DW_AT_ranges, DW_AT_location, DW_AT_GNU_pubnames,
DW_AT_GNU_pubtypes, DW_AT_GNU_addr_base, DW_AT_GNU_ranges_base
It also adds a hidden command line option "--dwarf-version=<uint>"
to llc which allows the version of Dwarf to be generated to override
what is specified in the metadata; this makes it possible to update
existing tests to check the debugging information generated for both
Dwarf 4 (the default) and Dwarf 3 using the same metadata.
Patch (slightly modified) by Keith Walker!
llvm-svn: 195391
AMD's processors family K7, K8, K10, K12, K15 and K16 are known to have SHLD/SHRD instructions with very poor latency. Optimization guides for these processors recommend using an alternative sequence of instructions. For these AMD's processors, I disabled folding (or (x << c) | (y >> (64 - c))) when we are not optimizing for size.
It might be beneficial to disable this folding for some of the Intel's processors. However, since I couldn't find specific recommendations regarding using SHLD/SHRD instructions on Intel's processors, I haven't disabled this peephole for Intel.
llvm-svn: 195383
The new command line flags are -dfsan-ignore-pointer-label-on-store and -dfsan-ignore-pointer-label-on-load. Their default value matches the current labelling scheme.
Additionally, the function __dfsan_union_load is marked as readonly.
Patch by Lorenzo Martignoni!
Differential Revision: http://llvm-reviews.chandlerc.com/D2187
llvm-svn: 195382
- Introduce several new custom glibc wrappers
- Implement some of the not yet implemented wrappers
- Refactor and extend the tests
- Add script to make sure all declare custom glibc wrappers are implemented & tested.
Patch by Lorenzo Martignoni!
Differential Revision: http://llvm-reviews.chandlerc.com/D2234
llvm-svn: 195381
- Allow overriding PACKAGE_VERSION from the command-line
- Use PACKAGE_VERSION to set CPACK_PACKAGE_VERSION (used by the Win installer)
- Don't include the version number in the CPack install dir or registry key.
Differential revision: http://llvm-reviews.chandlerc.com/D2245
llvm-svn: 195379
whose semantic is currently identical to objc_bridge,
but their differences may manifest down the road with
further enhancements. // rdar://15498044
llvm-svn: 195376
Added a new "Host/Debug.h" which contains the pure virtual class definitions for NativeProcessProtocol and NativeThreadProtocol. These classes are host layer classes that, over time, every host that supports debugging will implement once.
Then the new "lldb-gdbserver" binary in the tools directory will be able to make a remote debugging binary from these native classes, and we will also be able to have a new lldb_private::Process class that implements native debugging using these classes.
So as soon as linux and MacOSX switch over to using this layer, everyone will get native and remote debugging.
This check-in is primarily to get the needed code in so that poeple can start trying to implement the NativeProcessProtocol and NativeThreadProtocol and use it in the GDBRemoteCommunicationServer class to implement a GDB server for remote debugging.
llvm-svn: 195369
Evgeniy Stepanov