| Commit message (Collapse) | Author | Age | Files | Lines |
... | |
|
|
|
|
|
|
|
| |
dtor for non-trivial types."
Seems g++-4.8 (eg. Ubuntu 14.04) doesn't like this.
llvm-svn: 317077
|
|
|
|
|
|
|
|
|
| |
types.
This makes uses of Optional more transparent to the compiler (and
clang-tidy) and generates slightly smaller code.
llvm-svn: 317019
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Apple's iOS, tvOS and watchOS simulator platforms have never been clearly
distinguished in the target triples. Even though they are intended to
behave similarly to the corresponding device platforms, they have separate
SDKs and are really separate platforms from the compiler's perspective.
Clang now defines a macro when building for one of these simulator platforms
(r297866) but that relies on the very indirect mechanism of checking to see
which option was used to specify the minimum deployment target. That is not
so great. Swift would also like to distinguish these simulator platforms in
a similar way, but unlike Clang, Swift does not use a separate option to
specify the minimum deployment target -- it uses a -target option to
specify the target triple directly, including the OS version number.
Using a different target triple for the simulator platforms is a much
more direct and obvious way to specify this. Putting the "simulator" in
the environment component of the triple means the OS values can stay the
same and existing code the looks at the OS field will not be affected.
https://reviews.llvm.org/D39143
rdar://problem/34729432
llvm-svn: 316380
|
|
|
|
| |
llvm-svn: 316158
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
The method IEEEFloat::convertFromStringSpecials() does not recognize
the "+Inf" and "-Inf" strings but these strings are printed for
the double Infinities by the IEEEFloat::toString().
This patch adds the "+Inf" and "-Inf" strings to the list of recognized
patterns in IEEEFloat::convertFromStringSpecials().
Reviewers: sberg, bogner, majnemer, timshen, rnk, skatkov, gottesmm, bkramer, scanon
Reviewed By: skatkov
Subscribers: apilipenko, reames, llvm-commits
Differential Revision: https://reviews.llvm.org/D38030
llvm-svn: 316156
|
|
|
|
| |
llvm-svn: 316079
|
|
|
|
|
|
|
|
|
|
| |
This reverts commit 4e4ee1c507e2707bb3c208e1e1b6551c3015cbf5.
This is failing due to some code that isn't built on MSVC
so I didn't catch. Not immediately obvious how to fix this
at first glance, so I'm reverting for now.
llvm-svn: 315536
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
There's a lot of misuse of Twine scattered around LLVM. This
ranges in severity from benign (returning a Twine from a function
by value that is just a string literal) to pretty sketchy (storing
a Twine by value in a class). While there are some uses for
copying Twines, most of the very compelling ones are confined
to the Twine class implementation itself, and other uses are
either dubious or easily worked around.
This patch makes Twine's copy constructor private, and fixes up
all callsites.
Differential Revision: https://reviews.llvm.org/D38767
llvm-svn: 315530
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This operating system type represents the AMDGPU PAL runtime, and will
be required by the AMDGPU backend in order to generate correct code for
this runtime.
Currently it generates the same code as not specifying an OS at all.
That will change in future commits.
Patch from Tim Corringham.
Subscribers: arsenm, nhaehnle
Differential Revision: https://reviews.llvm.org/D37380
llvm-svn: 314500
|
|
|
|
|
|
|
| |
Triples like mips64-linux-gnuabin32 are documented in this article:
https://wiki.debian.org/Multiarch/Tuples
llvm-svn: 313231
|
|
|
|
| |
llvm-svn: 313160
|
|
|
|
| |
llvm-svn: 311875
|
|
|
|
|
|
|
|
|
|
|
|
| |
Reviewers: mehdi_amini, dexonsmith, dblaikie, davide, chandlerc, davidxl, echristo, efriedma
Reviewed By: dblaikie
Subscribers: rsmith, mgorny, emaste, llvm-commits
Differential Revision: https://reviews.llvm.org/D35043
llvm-svn: 311730
|
|
|
|
|
|
|
|
| |
Previously, we would just assert instead.
Differential Revision: https://reviews.llvm.org/D36961
llvm-svn: 311351
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This adds the OS check for the Haiku operating system, as it was
missing in the Triple class. Tests for x86_64-unknown-haiku and
i586-pc-haiku were also added.
These patches only affect Haiku and are completely harmless for
other platforms.
Patch by Calvin Hill <calvin@hakobaito.co.uk>
llvm-svn: 311153
|
|
|
|
|
|
| |
This test pretty clearly should be calling 'maxnum' here. =]
llvm-svn: 307519
|
|
|
|
|
|
|
|
|
|
| |
by a valid octal digit.
The length argument shows that this was in fact the intent.
This was pointed out in IRC, thanks to eddyb!
llvm-svn: 307496
|
|
|
|
|
|
|
|
|
|
| |
The internal representation has a natural way to handle this and it
seems nicer than having to wrap this in an optional (with its own
separate flag).
This also matches how std::function works.
llvm-svn: 307490
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Ananas is a home-brew operating system, mainly for amd64 machines. After
using GCC for quite some time, it has switched to clang and never looked
back - yet, having to manually patch things is annoying, so it'd be much
nicer if this was in the official tree.
More information:
https://github.com/zhmu/ananas/
https://rink.nu/projects/ananas.html
Submitted by: Rink Springer
Differential Revision: https://reviews.llvm.org/D32937
llvm-svn: 306237
|
|
|
|
| |
llvm-svn: 306101
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
The function matches the interface of llvm::to_integer, but as we are
calling out to a C library function, I let it take a Twine argument, so
we can avoid a string copy at least in some cases.
I add a test and replace a couple of existing uses of strtod with this
function.
Reviewers: zturner
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D34518
llvm-svn: 306096
|
|
|
|
| |
llvm-svn: 305643
|
|
|
|
| |
llvm-svn: 305642
|
|
|
|
|
|
| |
braces to avoid ambiguous 'else'. NFC.
llvm-svn: 305506
|
|
|
|
|
|
|
| |
On some compilers, __used__ can only be applied to variables
or functions.
llvm-svn: 305188
|
|
|
|
| |
llvm-svn: 305168
|
|
|
|
| |
llvm-svn: 305166
|
|
|
|
|
|
|
|
|
| |
They're unused with recent versions of libstdc++ but older ones
(e.g. libstdc++ 4.9 still requires them). Maybe we should bump
the requirements on the minimum version to make GCC 7 happy, but
in the meanwhile we need to live with the warning.
llvm-svn: 305158
|
|
|
|
| |
llvm-svn: 305157
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This prevents the iterator overrides from being selected in
the case where non-iterator types are used as arguments, which
is of particular importance in cases where other overrides with
identical types exist.
Reviewers: dblaikie, bkramer, rafael
Subscribers: llvm-commits, efriedma
Differential Revision: https://reviews.llvm.org/D33919
llvm-svn: 305105
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
clang-format (https://reviews.llvm.org/D33932) to keep primary headers
at the top and handle new utility headers like 'gmock' consistently with
other utility headers.
No other change was made. I did no manual edits, all of this is
clang-format.
This should allow other changes to have more clear and focused diffs,
and is especially motivated by moving some headers into more focused
libraries.
llvm-svn: 304786
|
|
|
|
|
|
|
| |
SUSE treats "gnueabi" as "gnueabihf" so make sure that we normalise the
environment.
llvm-svn: 304670
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This might give a few better opportunities to optimize these to memcpy
rather than loops - also a few minor cleanups (StringRef-izing,
templating (to avoid std::function indirection), etc).
The SmallVector::assign(iter, iter) could be improved with the use of
SFINAE, but the (iter, iter) ctor and append(iter, iter) need it to and
don't have it - so, workaround it for now rather than bothering with the
added complexity.
(also, as noted in the added FIXME, these assign ops could potentially
be optimized better at least for non-trivially-copyable types)
llvm-svn: 304566
|
|
|
|
|
|
|
|
|
|
|
|
| |
The intent of the test is to check that array lengths greater than
UINT_MAX work properly. Change the test to stress that scenario, without
triggering pointer overflow UB.
Caught by a WIP pointer overflow checker in clang.
Differential Revision: https://reviews.llvm.org/D33149
llvm-svn: 304353
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary:
This patch adds udiv/sdiv/urem/srem/udivrem/sdivrem methods that can divide by a uint64_t. This makes division consistent with all the other arithmetic operations.
This modifies the interface of the divide helper method to work on raw arrays instead of APInts. This way we can pass the uint64_t in for the RHS without wrapping it in an APInt. This required moving all the Quotient and Remainder allocation handling up to the callers. For udiv/urem this was as simple as just creating the Quotient/Remainder with the right size when they were declared. For udivrem we have to rely on reallocate not changing the contents of the variable LHS or RHS is aliased with the Quotient or Remainder APInts. We also have to zero the upper bits of Remainder and Quotient that divide doesn't write to if lhsWords/rhsWords is smaller than the width.
I've update the toString method to use the new udivrem.
Reviewers: hans, dblaikie, RKSimon
Reviewed By: RKSimon
Subscribers: llvm-commits
Differential Revision: https://reviews.llvm.org/D33310
llvm-svn: 303431
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
A lot of code is duplicated between the first_last and the
next / prev methods. All of this code can be shared if they
are implemented in terms of find_first_in(Begin, End) etc,
in which case find_first = find_first_in(0, Size) and find_next
is find_first_in(Prev+1, Size), with similar reductions for
the other methods.
Differential Revision: https://reviews.llvm.org/D33104
llvm-svn: 303269
|
|
|
|
|
|
| |
Differential revision: https://reviews.llvm.org/D32060
llvm-svn: 303227
|
|
|
|
|
|
| |
This makes multiply similar to add, sub, xor, and, and or.
llvm-svn: 302402
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
This almost completes the matrix of all possible find
functions.
*EXISTING*
----------
find_first
find_first_unset
find_next
find_next_unset
find_last
find_last_unset
*NEW*
----
find_prev
*STILL MISSING*
---------------
find_prev_unset
Differential Revision: https://reviews.llvm.org/D32885
llvm-svn: 302254
|
|
|
|
|
|
|
| |
Fixes some spelling mistakes, uses a helper function, and
adds an additional test case.
llvm-svn: 302208
|
|
|
|
|
|
|
|
| |
This features isn't used anywhere in tree. It's existence seems to be preventing selfhost builds from inlining any of the setBits methods including setLowBits, setHighBits, and setBitsFrom. This is because the code makes the method recursive.
If anyone needs this feature in the future we could consider adding a setBitsWithWrap method. This way only the calls that need it would pay for it.
llvm-svn: 301769
|
|
|
|
|
|
|
|
|
|
| |
We already have a function toHex that will convert a string like
"\xFF\xFF" to the string "FFFF", but we do not have one that goes
the other way - i.e. to convert a textual string representing a
sequence of hexadecimal characters into the corresponding actual
bytes. This patch adds such a function.
llvm-svn: 301356
|
|
|
|
|
|
|
|
|
|
|
|
| |
ashrInPlace.
This patch adds an in place version of ashr to match lshr and shl which were recently added.
I've tried to make this similar to the lshr code with additions to handle the sign extension. I've also tried to do this with less if checks than the current ashr code by sign extending the original result to a word boundary before doing any of the shifting. This removes a lot of the complexity of determining where to fill in sign bits after the shifting.
Differential Revision: https://reviews.llvm.org/D32415
llvm-svn: 301198
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Summary: SUSE's ARM triples end with -gnueabi even though they are hard-float. This requires special handling of SUSE ARM triples. Hence we need a way to differentiate the SUSE as vendor. This CL adds that.
Reviewers: chandlerc, compnerd, echristo, rengolin
Reviewed By: rengolin
Subscribers: aemerson, rengolin, llvm-commits
Differential Revision: https://reviews.llvm.org/D32426
llvm-svn: 301174
|
|
|
|
|
|
|
|
| |
multi word.
Previously single word would always return 0 regardless of the original sign. Multi word would return all 0s or all 1s based on the original sign. Now single word takes into account the sign as well.
llvm-svn: 301159
|
|
|
|
|
|
|
|
| |
constructor mask off any excess bits.
The current code is trying to be clever with shifts to avoid needing to clear unused bits. But it looks like the compiler is unable to optimize out the unused bit handling in the APInt constructor. Given this its better to just use SignExtend64 and have more readable code.
llvm-svn: 301133
|
|
|
|
|
|
|
|
|
|
| |
a bug in the shift by BitWidth handling."
This reverts commit r301094, as it broke all ARM self-hosting bots.
PR32754.
llvm-svn: 301110
|
|
|
|
|
|
|
|
| |
in the shift by BitWidth handling.
For single word, shift by BitWidth was always returning 0, but for multiword it was based on original sign. Now single word matches multi word.
llvm-svn: 301094
|
|
|
|
|
|
| |
Differential Revision: https://reviews.llvm.org/D32302
llvm-svn: 301014
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
snprinf
This should fix the bug https://bugs.llvm.org/show_bug.cgi?id=12906
To print the FP constant AsmWriter does the following:
1) convert FP value to String (actually using snprintf function which is locale dependent).
2) Convert String back to FP Value
3) Compare original and got FP values. If they are not equal just dump as hex.
The problem happens on the 2nd step when APFloat does not expect group delimiter or
fraction delimiter other than period symbol and so on, which can be produced on the
first step if LLVM library is used in an environment with corresponding locale set.
To fix this issue the locale independent APFloat:toString function is used.
However it prints FP values slightly differently than snprintf does. Specifically
it suppress trailing zeros in significant, use capital E and so on.
It results in 117 test failures during make check.
To avoid this I've also updated APFloat.toString a bit to pass make check at least.
Reviewers: sberg, bogner, majnemer, sanjoy, timshen, rnk
Reviewed By: timshen, rnk
Subscribers: rnk, llvm-commits
Differential Revision: https://reviews.llvm.org/D32276
llvm-svn: 300943
|