On Thumb, the displacement computation hardware uses the address of the
current instruction rouned down to a multiple of 4. Include this
rounding in the UserOffset we compute for each instruction.
When inline asm is present, the instruction alignment may not be known.
Constrain the maximum displacement instead in that case.
This makes it possible for CreateNewWater() and OffsetIsInRange() to
agree about the valid displacements. When they disagree, infinite
looping happens.
As always, test cases for this stuff are insane.
<rdar://problem/10660175>
llvm-svn: 147825
- reject definitions of enums within friend declarations
- require 'enum', not 'enum class', for non-declaring references to scoped
enumerations
llvm-svn: 147824
source file. Otherwise -g -save-temps will error out on the compile
of any .c file.
Fixes about 4000 of the errors in the clang-tests gdb test suite.
llvm-svn: 147819
functions that can create file descriptors and close them. It will warn when
there close file descriptor call that returns with EBADF and show the
corresponding stack backtraces that caused the issue. It will also log all
file descriptor create and delete calls. See the comments at the top of
FDInterposing.cpp for all of the details.
llvm-svn: 147816
After collecting chains, check if any should be materialized. If so,
hide the chained IV users from the LSR solver. LSR will only solve for
the head of the chain. GenerateIVChains will then materialize the
chained IV users by computing the IV relative to its previous value in
the chain.
In theory, chained IV users could be exposed to LSR's solver. This
would be considerably complicated to implement and I'm not aware of a
case where we need it. In practice it's more important to
intelligently prune the search space of nontrivial loops before
running the solver, otherwise the solver is often forced to prune the
most optimal solutions. Hiding the chained users does this well, so
that LSR is more likely to find the best IV for the chain as a whole.
llvm-svn: 147801
This collects a set of IV uses within the loop whose values can be
computed relative to each other in a sequence. Following checkins will
make use of this information.
llvm-svn: 147797
it was checked in as:
virtual bool ABI::FixCodeAddress (lldb::addr_t pc);
when it should have been:
virtual lldb::addr_t ABI::FixCodeAddress (lldb::addr_t pc);
llvm-svn: 147790
the anonymous namespace to its parent. Semantically, this means that
the anonymous namespaces defined in one module are distinct from the
anonymous namespaces defined in another module.
llvm-svn: 147782
modules. Teach name lookup into namespaces to search in each of the
merged DeclContexts as well as the (now-primary) DeclContext. This
supports the common case where two different modules put something
into the same namespace.
llvm-svn: 147778
is important because it's fairly common for headers (especially system
headers) to want to provide only those typedefs needed for that
particular header, based on some guard macro, e.g.,
#ifndef _SIZE_T
#define _SIZE_T
typedef long size_t;
#endif
which is repeated in a number of headers. The guard macro protects
against duplicate definitions. However, this means that only the first
occurrence of this pattern actually defines size_t, so the submodule
corresponding to this header has the only visible definition. If a
user then imports a different submodule from the same module, size_t
will be known but not visible, and therefore cannot be used.
By allowing redefinition of typedefs, each header that wants to define
size_t can do so independently, so it will be available in the
corresponding submodules.
llvm-svn: 147775
this substraction will result in small negative numbers at worst which
become very large positive numbers on assignment and are thus caught by
the <=4 check on the next line. The >0 check clearly intended to catch
these as negative numbers.
Spotted by inspection, and impossible to trigger given the shift widths
that can be used.
llvm-svn: 147773
Jakob Stoklund Olesen