I found the race condition in:
ScriptInterpreter *CommandInterpreter::GetScriptInterpreter(bool can_create);
More than one "ScriptInterpreter *" was being returned due to the race which caused any clients with the first one to now be pointing to freed memory and we would quickly crash.
Added a test to catch this so we don't regress.
<rdar://problem/28356584>
llvm-svn: 289169
Rewriter tests rewrite Objective-C++ to C++, and then compile the
result. The rewritten result sometimes doesn't work with C++11. As
we want to allow Clang's default dialect to become C++11, we need to
make sure the tests will still pass.
llvm-svn: 289167
This just hoists the check for declarations up a layer which allows
various sets used in the walk to be smaller. Also moves the relevant
comments to match, and catches a few other cleanups in this code.
llvm-svn: 289163
This patch removes libc++'s tuple extension which allowed it to be
constructed from fewer initializers than elements; with the remaining
elements being default constructed. However the implicit version of
this extension breaks conforming code. For example:
int fun(std::string);
int fun(std::tuple<std::string, int>);
int x = fun("hello"); // ambigious
Because existing code may already depend on this extension it can be re-enabled
by defining _LIBCPP_ENABLE_TUPLE_IMPLICIT_REDUCED_ARITY_EXTENSION.
Note that the explicit version of this extension is still supported,
although it's somewhat less useful than the implicit one.
llvm-svn: 289158
Improved doxygen comments for fxsrintrin.h and mmintrin.h intrinsics by taagging parameter names with \a doxygen command to display parameters in italics.
Formatted comments to fit into 80 chars.
llvm-svn: 289154
Supporting them properly is a reasonably complex chunk of work, so to allow bot
testing before then we should at least be able to fall back to DAG ISel.
llvm-svn: 289150
linkerscript.s is the first test file for linker script, and at the moment
it contains all tests for linker scripts. Now that test file doesn't make
sense.
linkerscript2.s was just badly named. Renamed searchdir.s.
llvm-svn: 289148
Summary: I see crashes on this check when some reports are being generated.
Reviewers: eugenis
Subscribers: kubabrecka, llvm-commits
Differential Revision: https://reviews.llvm.org/D27574
llvm-svn: 289145
test/std/input.output/iostream.format/input.streams/istream.unformatted/get.pass.cpp
Add static_cast<char> because basic_istream::get() returns int_type (N4606 27.7.2.3 [istream.unformatted]/4).
test/std/input.output/iostream.format/output.streams/ostream.formatted/ostream.inserters.arithmetic/minus1.pass.cpp
Add static_cast<char> because toupper() returns int (C11 7.4.2.2/1).
test/std/iterators/stream.iterators/ostream.iterator/ostream.iterator.ops/assign_t.pass.cpp
This test is intentionally writing doubles to ostream_iterator<int>.
It's silencing -Wliteral-conversion for Clang, so I'm adding C4244 silencing for MSVC.
test/std/language.support/support.limits/limits/numeric.limits.members/infinity.pass.cpp
Given `extern float zero;`, the expression `1./zero` has type double, which emits a truncation warning
when being passed to test<float>() taking float. The fix is to say `1.f/zero` which has type float.
test/std/numerics/complex.number/cmplx.over/arg.pass.cpp
test/std/numerics/complex.number/cmplx.over/norm.pass.cpp
These tests were constructing std::complex<double>(x, 0), emitting truncation warnings when x is long long.
Saying static_cast<double>(x) avoids this.
test/std/numerics/rand/rand.eng/rand.eng.lcong/seed_result_type.pass.cpp
This was using `int s` to construct and seed a linear_congruential_engine<T, stuff>, where T is
unsigned short/unsigned int/unsigned long/unsigned long long. That emits a truncation warning in the
unsigned short case. Because the range [0, 20) is tiny and we aren't doing anything else with the index,
we can just iterate with `T s`.
test/std/re/re.traits/value.pass.cpp
regex_traits<wchar_t>::value()'s first parameter is wchar_t (N4606 28.7 [re.traits]/13). This loop is
using int to iterate through ['g', 0xFFFF), emitting a truncation warning from int to wchar_t
(which is 16-bit for some of us). Because the bound is exclusive, we can just iterate with wchar_t.
test/std/strings/basic.string/string.cons/size_char_alloc.pass.cpp
This test is a little strange. It's trying to verify that basic_string's (InIt, InIt) range constructor
isn't confused by "N copies of C" when N and C have the same integral type. To do this, it was
testing (100, 65), but that eventually emits truncation warnings from int to char. There's a simple way
to avoid this - passing (static_cast<char>(100), static_cast<char>(65)) also exercises the disambiguation.
(And 100 is representable even when char has a signed range.)
test/std/strings/string.view/string.view.hash/string_view.pass.cpp
Add static_cast<char_type> because `'0' + i` has type int.
test/std/utilities/function.objects/bind/func.bind/func.bind.bind/nested.pass.cpp
What's more horrible than nested bind()? pow() overloads! This operator()(T a, T b) was assuming that
std::pow(a, b) can be returned as T. (In this case, T is int.) However, N4606 26.9.1 [cmath.syn]/2
says that pow(int, int) returns double, so this was truncating double to int.
Adding static_cast<T> silences this.
test/std/utilities/function.objects/unord.hash/integral.pass.cpp
This was iterating `for (int i = 0; i <= 5; ++i)` and constructing `T t(i);` but that's truncating
when T is short. (And super truncating when T is bool.) Adding static_cast<T> silences this.
test/std/utilities/utility/exchange/exchange.pass.cpp
First, this was exchanging 67.2 into an int, but that's inherently truncating.
Changing this to static_cast<short>(67) avoids the truncation while preserving the
"what if T and U are different" test coverage.
Second, this was exchanging {} with the explicit type float into an int, and that's also
inherently truncating. Specifying short is just as good.
test/std/utilities/utility/pairs/pairs.spec/make_pair.pass.cpp
Add static_cast<short>. Note that this affects template argument deduction for make_pair(),
better fulfilling the test's intent. For example, this was saying
`typedef std::pair<int, short> P1; P1 p1 = std::make_pair(3, 4);` but that was asking
make_pair() to return pair<int, int>, which was then being converted to pair<int, short>.
(pair's converting constructors are tested elsewhere.)
Now, std::make_pair(3, static_cast<short>(4)) actually returns pair<int, short>.
(There's still a conversion from pair<nullptr_t, short> to pair<unique_ptr<int>, short>.)
Fixes D27544.
llvm-svn: 289111
test/std/algorithms/alg.modifying.operations/alg.random.shuffle/random_shuffle_rand.pass.cpp
(Affects 64-bit architectures.) Include <cstddef> so we can take/return std::ptrdiff_t
(instead of int) in random_shuffle()'s RNG. (C++14 D.12 [depr.alg.random.shuffle]/2 says that
difference_type is used, and we're shuffling a plain array.)
test/std/algorithms/alg.sorting/alg.sort/sort/sort.pass.cpp
test/std/algorithms/alg.sorting/alg.sort/stable.sort/stable_sort.pass.cpp
(Affects 64-bit architectures.) Include <iterator> because we're already using iterator_traits.
Then, store the result of subtracting two RanIts as difference_type instead of long
(which truncates on LLP64 architectures like MSVC x64).
test/std/containers/sequences/forwardlist/forwardlist.ops/splice_after_flist.pass.cpp
test/std/containers/sequences/forwardlist/forwardlist.ops/splice_after_one.pass.cpp
(Affects 64-bit architectures.) Include <cstddef> so we can store the result of
subtracting two pointers as std::ptrdiff_t (instead of int).
test/std/input.output/iostream.format/input.streams/istream.unformatted/ignore_0xff.pass.cpp
(Affects 32-bit architectures.) Sometimes, size_t is too small. That's the case here,
where tellg() returns pos_type (N4606 27.7.2.3 [istream.unformatted]/39). Implementations can
have 64-bit pos_type (to handle large files) even when they have 32-bit size_t.
Fixes D27543.
llvm-svn: 289110
Instead of storing double in double and then truncating to int, store int in long
and then widen to long long. This preserves test coverage (as these tests are
interested in various tuple conversions) while avoiding truncation warnings.
test/std/utilities/tuple/tuple.tuple/tuple.cnstr/const_pair.pass.cpp
Since we aren't physically truncating anymore, t1 is equal to p0.
test/std/utilities/tuple/tuple.tuple/tuple.cnstr/convert_copy.pass.cpp
One edit is different from the usual pattern. Previously, we were storing
double in double and then converting to A, which has an implicitly converting
constructor from int. Now, we're storing int in int and then converting to A,
avoiding the truncation.
Fixes D27542.
llvm-svn: 289109
Change char to long and remove some char casts. This preserves test coverage for tuple's
heterogeneous comparisons, while avoiding int-to-char truncation warnings.
Fixes D27541.
llvm-svn: 289108
These tests for some guy's transparent operator functors were needlessly truncating their
double results to int. Preserving the doubleness makes compilers happier. I'm following
existing practice by adding an "// exact in binary" comment when the result isn't a whole number.
(The changes from 6 to 6.0 and so forth are stylistic, not critical.)
Fixes D27539.
llvm-svn: 289106
Given `std::basic_streambuf<CharT>::int_type __c`, `std::basic_string<CharT> str_`,
and having checked `__c != std::basic_streambuf<CharT>::traits_type::eof()` (substituting typedefs
for clarity), the line `str_.push_back(__c);` is safe according to humans, but truncates according
to compilers. `str_.push_back(static_cast<CharT>(__c));` avoids that problem.
Fixes D27538.
llvm-svn: 289105
Summary:
D27549 (partial fix for PR26619) emits a constant value in the debug
metadata for a floating-point static const that does not exceed 64
bits in size. The regression test accompanying that fix assumes that
a long double exceeds 64 bits in size and hence does not get a
constant value in the debug metadata. However, for some targets --
such as "--target=hexagon-unknown-elf" -- a long double does not
exceed 64 bits in size, and hence the test fails.
As a temporary fix, modify the regression test to no longer inspect
the debug metadata for a long double.
Reviewers: cfe-commits, probinson
Differential Revision: https://reviews.llvm.org/D27589
llvm-svn: 289103
We were falsely claiming that we had an LSDA for the relevant EH
personality before this change, which could lead to the EH machinery
interpreting random adjacent data as an LSDA.
Fixes PR31317
This change is safe because cleanups can't contain exception handlers
today. We do these things to maintain that invariant:
- C++ destructors are naturally out-of-line
- __finally blocks are outlined in clang
- LLVM's inliner will not inline EH constructs into cleanups
llvm-svn: 289101
ThreadList had an assignment operator that didn't lock the "rhs" thread list object. This means a thread list can be mutated while it is being copied.
The copy constructor calls the assignment operator as well. So this fixes the unsafe threaded access to ThreadList which we believe is responsible for a lot of crashes.
<rdar://problem/28075793>
llvm-svn: 289100
This was exposed by some code that used more than one level of sub-
registers. There is no testcase, because there is no such code in the
Hexagon backend.
llvm-svn: 289099
Craig Topper