rdar://problem/11283401
Example:
Collected 1 test
1: test_with_dwarf (TestCallStdStringFunction.ExprCommandCallFunctionTestCase)
Test calling std::String member function. ... FAIL
======================================================================
FAIL: test_with_dwarf (TestCallStdStringFunction.ExprCommandCallFunctionTestCase)
Test calling std::String member function.
----------------------------------------------------------------------
Traceback (most recent call last):
File "/Volumes/data/lldb/svn/ToT/test/lldbtest.py", line 427, in wrapper
return func(self, *args, **kwargs)
File "/Volumes/data/lldb/svn/ToT/test/expression_command/call-function/TestCallStdStringFunction.py", line 34, in test_with_dwarf
self.call_function()
File "/Volumes/data/lldb/svn/ToT/test/expression_command/call-function/TestCallStdStringFunction.py", line 48, in call_function
substrs = ['Hello world'])
File "/Volumes/data/lldb/svn/ToT/test/lldbtest.py", line 1235, in expect
msg if msg else EXP_MSG(str, exe))
AssertionError: False is not True : 'Hello world' returns expected result
Config=i386-clang
----------------------------------------------------------------------
Ran 1 test in 1.148s
FAILED (failures=1)
llvm-svn: 155157
when the set bits aren't the same for both args of the xor.
This transformation is in the function TargetLowering::SimplifyDemandedBits
in the file lib/CodeGen/SelectionDAG/TargetLowering.cpp.
I have tested this test using a previous version of llc which the defect and
the a version of llc which does not. I got the expected fail and pass,
respectively.
This test goes with rdar://11195364 and the check in with the fix: svn r154955
llvm-svn: 155156
llvm-ld is no longer useful and causes confusion and so it is being removed.
* Does not work very well on Windows because it must call a gcc like driver to
assemble and link.
* Has lots of hard coded paths which are wrong on many systems.
* Does not understand most of ld's options.
* Can be partially replaced by llvm-link | opt | {llc | as, llc -filetype=obj} |
ld, or fully replaced by Clang.
I know of no production use of llvm-ld, and hacking use should be
replaced by Clang's driver.
llvm-svn: 155147
The shl instruction is used to represent multiplication by a constant
power of two as well as bitwise left shifts. Some InstCombine
transformations would turn an shl instruction into a bit mask operation,
making it difficult for later analysis passes to recognize the
constsnt multiplication.
Disable those shl transformations, deferring them to DAGCombine time.
An 'shl X, C' instruction is now treated mostly the same was as 'mul X, C'.
These transformations are deferred:
(X >>? C) << C --> X & (-1 << C) (When X >> C has multiple uses)
(X >>? C1) << C2 --> X << (C2-C1) & (-1 << C2) (When C2 > C1)
(X >>? C1) << C2 --> X >>? (C1-C2) & (-1 << C2) (When C1 > C2)
The corresponding exact transformations are preserved, just like
div-exact + mul:
(X >>?,exact C) << C --> X
(X >>?,exact C1) << C2 --> X << (C2-C1)
(X >>?,exact C1) << C2 --> X >>?,exact (C1-C2)
The disabled transformations could also prevent the instruction selector
from recognizing rotate patterns in hash functions and cryptographic
primitives. I have a test case for that, but it is too fragile.
llvm-svn: 155136
- Work in progress, this is mostly important because it lets us incrementally migrate the remaining documentation.
- Lots of styling, editing, and integration work yet to come…
- PR12589
llvm-svn: 155133
which are checked in the parser, and analysis warnings that require the
full analysis. This allows attribute syntax to be checked independently
of the full thread safety analysis. Also introduces a new warning for the
case where a string is used as a lock expression; this allows the analysis
to gracefully handle expressions that would otherwise cause a parse error.
llvm-svn: 155129
This fixes the included testcase and lets us simplify the code a bit. It
does require using mergeWithMin when merging class information to its
members. Expand the comments to explain why that works.
llvm-svn: 155103
an explicit default one. This means that with -fvisibility hidden we
now produce a hidden symbol for
template <typename T>
class DEFAULT foo {
void bar() {}
};
class zed {};
template class foo<zed>;
This matches the behaviour of gcc 4.7.
llvm-svn: 155102
there is no need for mergeVisibily to ever increase the visibility. Not
doing so lets us replace an incorrect use of mergeVisibilityWithMin. The
testcase
struct HIDDEN RECT {
int top;
};
DEFAULT RECT foo = {0};
shows that we should give preference to one of the attributes instead of
keeping the minimum. We still get this testcase wrong because mergeVisibily
handles two explicit visibilities incorrectly, but this is a step in the
right direction.
llvm-svn: 155101
the current implementation this should be a nop as explicit visibility
takes precedence in mergeVisibility.
The location chosen is such that attributes checked above it can force
a symbol to be default. For example, an attribute is the variable or function.
Attributes checked after this point, can only make the visibility more
restrictive. An attribute in a type for example.
llvm-svn: 155098
currently a nop as those users are the first merge or are a merge
of a hidden explicit visibility, which always wins in the current
implementation.
llvm-svn: 155095
out of the box on Linux systems. If you're building against libc++abi, you
still need to make sure it can find <cxxabi.h> so it knows not to export
symbols which libc++abi provides.
llvm-svn: 155091
at the moment, but they allow these tests to be used to test clang against
libstdc++. Add myself to the credits file, as suggested by Howard.
llvm-svn: 155085
Fariborz Jahanian