Fixed the DWARF plug-in such that when it gets all attributes for a DIE, that
it omits the DW_AT_sibling and DW_AT_declaration when getting attributes
from a DW_AT_abstract_origin or DW_AT_specification DIE.
llvm-svn: 118654
invoke the test driver to rerun the very same test. Example output:
/Volumes/data/lldb/svn/trunk/test $ tail 2010-11-09-14_51_34/ExpectedFailure-TestSettings.SettingsCommandTestCase.test_set_output_path.log
Traceback (most recent call last):
File "/Volumes/data/lldb/svn/trunk/test/settings/TestSettings.py", line 136, in test_set_output_path
"'stdout.txt' exists due to target.process.output-path.")
AssertionError: False is not True : 'stdout.txt' exists due to target.process.output-path.
To rerun this test, issue the following command from the 'test' directory:
./dotest.py -v -t -f SettingsCommandTestCase.test_set_output_path
llvm-svn: 118646
It is only supported for ARM code. Normally Thumb2 code would use DMB instead,
but depending on how the compiler is invoked (e.g., -mattr=-db) that might be
disabled. This prevents a "cannot select MEMBARRIER_MCR" error in that
situation. Radar 8644195
llvm-svn: 118642
* LDM, et al, uses a bit mask to indicate the register list.
* VLDM, et al, uses a base register plus number.
The LDM instructions may be non-contiguous, but the VLDM ones must be
contiguous. Those are semantic checks that should be done later in the
compiler. Also postpone the creation of the bit mask until it's needed.
llvm-svn: 118640
own subcategory, -Wconstant-conversion, which is on by default.
Tweak the constant folder to give better results in the invalid
case of a negative shift amount.
Implements rdar://problem/6792488
llvm-svn: 118636
@unittest2.skip("rdar://problem/8641483 ./dotest.py -v -t -w forward seg faults")
and add a @skip decorator for test_with_dwarf_and_run_command() method:
@unittest2.skip("rdar://problem/8648070 'expression *bar_ptr' seg faults")
llvm-svn: 118632
That bug concerned the well-formedness of code such as (&ovl)(a, b,
c). GCC rejects the code, while EDG accepts it. On further study of the
standard, I see no support for EDG's position: in particular, C++
[over.over] does not list this as a context where we can take the
address of an overloaded function, C++ [over.call.func] does not
reference the address-of operator at any point, and C++ [expr.call]
claims that the function argument in a call is either a function
lvalue or a pointer-to-function; (&ovl) is neither.
llvm-svn: 118620
Bill Wendling