| Commit message (Collapse) | Author | Age | Files | Lines | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
'(strong)'
property attribute.
llvm-svn: 144078
 | 
| | 
| 
| 
|  | 
llvm-svn: 144077
 | 
| | 
| 
| 
|  | 
llvm-svn: 144076
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
The Neon load/store intrinsics need to be implemented as macros to avoid
hiding alignment attributes on the pointer arguments, and the macros can
only evaluate those pointer arguments once (in case they have side effects),
so it has been hard to get the right type checking for those pointers.
I tried various alternatives in the arm_neon.h header, but it's much more
straightforward to just check directly in Sema.
llvm-svn: 144075
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
whether a given address is in an executable region of memory or
not.  I haven't written the lldb side that will use this packet it
hasn't been tested yet but it's a simple enough bit of code.
I want to have this feature available for the unwinder code.  When
we're stopped at an address with no valid symbol context, there are
a number of questions I'd like to ask --
  is the current pc value in an executable region (e.g. did they
  jump to unallocated/unexecutable memory?  we know how to unwind
  from here if so.)
  Is the stack pointer or the frame pointer the correct register
  to use to find the caller's saved pc value?
Once we're past the first frame we can trust things like eh_frame
and ABI unwind schemes but the first frame is challenging and having
a way to check potential addresses to see if they're executable or
not would help narrow down the possibilities a lot.
llvm-svn: 144074
 | 
| | 
| 
| 
|  | 
llvm-svn: 144073
 | 
| | 
| 
| 
| 
| 
|  | 
Based on work by Dmitry Sokolov!
llvm-svn: 144072
 | 
| | 
| 
| 
|  | 
llvm-svn: 144071
 | 
| | 
| 
| 
| 
| 
| 
|  | 
-std=gnu89 -pedantic.
FIXME: Should configure detect one?
llvm-svn: 144070
 | 
| | 
| 
| 
| 
| 
| 
|  | 
doesn't handle bitfields in eFormatChar's correctly, only eFormatUnsigned.
Fix DataExtractor::Dump to dump the bitfield eFormatChars correctly.
llvm-svn: 144069
 | 
| | 
| 
| 
| 
| 
|  | 
Passing packed value is not compatible on Win32 x64.
llvm-svn: 144068
 | 
| | 
| 
| 
|  | 
llvm-svn: 144067
 | 
| | 
| 
| 
| 
| 
|  | 
see some suboptimal frame (%ebp) emission on certain hosts. Possible [PR11031]
llvm-svn: 144066
 | 
| | 
| 
| 
|  | 
llvm-svn: 144065
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
running again (except you have to ignore
cases where the breakpoint runs expressions, those don't count as really "running again").
llvm-svn: 144064
 | 
| | 
| 
| 
| 
| 
|  | 
Membarth, test case by myself.
llvm-svn: 144063
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
written, instead of the resolved storage class, which might not be
legal to specify on the declaration (such as out-of-line definitions
of static class members in C++, and __local variables in OpenCL).
Initial patch by Richard Membarth.
llvm-svn: 144062
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
be in the target. All of the environment, args, stdin/out/err files, etc have
all been moved. Also re-enabled the ability to launch a process in a separate
terminal on MacOSX.
llvm-svn: 144061
 | 
| | 
| 
| 
|  | 
llvm-svn: 144060
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
__unsafe_unretained
later on, or we will end up with a redundant '__unsafe_unretained'.
llvm-svn: 144059
 | 
| | 
| 
| 
| 
| 
|  | 
(TIL: -Wnon-virtual-dtor is not in -Wall.)
llvm-svn: 144058
 | 
| | 
| 
| 
|  | 
llvm-svn: 144057
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
expression evaluation:
 - When folding a non-value-dependent expression, we may try to use the
   initializer of a value-dependent variable. If that happens, give up.
 - In C++98, actually check that a const, non-volatile DeclRefExpr inside an ICE
   is of integral or enumeration type (a reference isn't OK!)
 - In C++11, DeclRefExprs for objects of const literal type initialized with
   value-dependent expressions are themselves value-dependent.
 - So are references initialized with value-dependent expressions (though this
   case is missing from the C++11 standard, along with many others).
llvm-svn: 144056
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
doesn't get confused by CSE later on.  Fixes PR11318.
Re-commit of r144034, with an extra fix so that RemoveDeadNode doesn't blow up.
llvm-svn: 144055
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
This patch just adds a simple NeonTypeFlags class to replace the various
hardcoded constants that had been used until now.  Unfortunately I couldn't
figure out a good way to avoid duplicating that class between clang and
TableGen, but since it's small and rarely changes, that's not so bad.
llvm-svn: 144054
 | 
| | 
| 
| 
|  | 
llvm-svn: 144053
 | 
| | 
| 
| 
| 
| 
|  | 
_mm_loadl_pi(). rdar://10134392, rdar://10050222
llvm-svn: 144052
 | 
| | 
| 
| 
|  | 
llvm-svn: 144051
 | 
| | 
| 
| 
|  | 
llvm-svn: 144050
 | 
| | 
| 
| 
|  | 
llvm-svn: 144049
 | 
| | 
| 
| 
|  | 
llvm-svn: 144048
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
callee's responsibility to sign or zero-extend the return value.  The additional
test case just checks to make sure the calls are selected (i.e., -fast-isel-abort
doesn't assert).
llvm-svn: 144047
 | 
| | 
| 
| 
|  | 
llvm-svn: 144046
 | 
| | 
| 
| 
| 
| 
|  | 
LLDB_DISABLE_PYTHON so it doesn't show up in builds where it is supposed to be disabled.
llvm-svn: 144045
 | 
| | 
| 
| 
|  | 
llvm-svn: 144044
 | 
| | 
| 
| 
| 
| 
|  | 
Delete!
llvm-svn: 144043
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
which will in the future allow expressions to be
compiled as C, C++, and Objective-C instead of the
current default Objective-C++.  This feature requires
some additional support from Clang -- specifically, it
requires reference types in the parser regardless of
language -- so it is not yet exposed to the user.
llvm-svn: 144042
 | 
| | 
| 
| 
| 
| 
|  | 
imported variables.
llvm-svn: 144041
 | 
| | 
| 
| 
|  | 
llvm-svn: 144040
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
since the initial version
dated 2010-21-15.  The test started failure recently probably due to work done on the command parsing.
Anyway, the specific test sequence is invalid and is fixed now.
llvm-svn: 144039
 | 
| | 
| 
| 
|  | 
llvm-svn: 144038
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
DomainValues that are only used by "don't care" instructions are now
collapsed to the first possible execution domain after all basic blocks
have been processed.  This typically means the PS domain on x86.
For example, the vsel_i64 and vsel_double functions in sse2-blend.ll are
completely collapsed to the PS domain instead of containing a mix of
execution domains created by isel.
llvm-svn: 144037
 | 
| | 
| 
| 
| 
| 
|  | 
Fixes r8429
llvm-svn: 144036
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
| 
| 
| 
|  | 
a) adds a new --synchronicity (-s) setting for "command script add" that allows the user to decide if scripted commands should run synchronously or asynchronously (which can make a difference in how events are handled)
 b) clears up several error messages
 c) adds a new --allow-reload (-r) setting for "command script import" that allows the user to reload a module even if it has already been imported before
 d) allows filename completion for "command script import" (much like what happens for "target create")
 e) prevents "command script add" from replacing built-in commands with scripted commands
 f) changes AddUserCommand() to take an std::string instead of a const char* (for performance reasons)
plus, it fixes an issue in "type summary add" command handling which caused several test suite errors
llvm-svn: 144035
 | 
| | 
| 
| 
| 
| 
|  | 
doesn't get confused by CSE later on.  Fixes PR11318.
llvm-svn: 144034
 | 
| | 
| 
| 
|  | 
llvm-svn: 144032
 | 
| | 
| 
| 
| 
| 
| 
| 
| 
|  | 
doesn't duplicate, but they all surface as implicit
properties.  It's also a useful optimization to not
duplicate the implicit getter lookup.  So, trust the
getter lookup that was already done in these cases.
llvm-svn: 144031
 | 
| | 
| 
| 
| 
| 
| 
|  | 
in "/System/Library/PrivateFrameworks", and also have "lldb" in the Xcode.app
and the LLDB.framework in Xcode.app as well.
llvm-svn: 144030
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
scan-build ignores clang failures in some cases, which might lead to
silent failure suppression. For example, if clang command line
argument is wrong. (Addresses radar://10406598)
llvm-svn: 144029
 | 
| | 
| 
| 
| 
| 
| 
| 
|  | 
initializer; all other constexpr variables are merely required to be
initialized. In particular, a user-provided constexpr default constructor can be
used for such initialization.
llvm-svn: 144028
 |