The ARM TargetParser would construct invalid StringRefs. This would cause
asserts to trigger. Add some tests in LLVM to ensure that we dont regress on
this in the future. Although there is a test for this in clang, this ensures
that the changes would get caught in the same repository.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@262790 91177308-0d34-0410-b5e6-96231b3b80d8
This extracts the type name from __PRETTY_FUNCTION__ for compilers that
support it (I've opted Clang, GCC, and ICC into this as I've tested that
they work) and from __FUNCSIG__ which is very similar on MSVC. The
routine falls back gracefully on a stub "UNKNOWN_TYPE" string with
compilers or formats it doesn't understand.
This should be enough for a lot of common cases in LLVM where the real
goal is just to log or print a type name as a debugging aid, and save
a ton of boilerplate in the process. Notably, I'm planning to use this
to remove all the getName() boiler plate from the new pass manager.
The design and implementation is based on a bunch of advice and
discussion with Richard Smith and experimenting with most versions of
Clang and GCC. David Majnemer also provided excellent advice on how best
to do this with MSVC. Richard also checked that ICC does something
reasonable and I'll watch the build bots for other compilers. It'd be
great if someone could contribute logic for xlC and/or other toolchains.
Differential Revision: http://reviews.llvm.org/D17565
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@261819 91177308-0d34-0410-b5e6-96231b3b80d8
compiler-specific issues. Instead, repeat an 'operator delete' definition in
each derived class that is actually deleted, and give up on the static type
safety of an error when sized delete is accidentally used on a type derived
from TrailingObjects.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@260190 91177308-0d34-0410-b5e6-96231b3b80d8
This fixes undefined behavior in C++14 due to the size of the object being
deleted being different from sizeof(dynamic type) when it is allocated with
trailing objects.
MSVC seems to have several bugs around using-declarations changing the access
of a member inherited from a base class, so use forwarding functions instead of
using-declarations to make TrailingObjects::operator delete accessible where
desired.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@260180 91177308-0d34-0410-b5e6-96231b3b80d8
The Windows bots have been failing for the last two days, with:
FAILED: C:\PROGRA~2\MICROS~1.0\VC\bin\amd64\cl.exe -c LLVMContextImpl.cpp
D:\buildslave\clang-x64-ninja-win7\llvm\lib\IR\LLVMContextImpl.cpp(137) :
error C2248: 'llvm::TrailingObjects<llvm::AttributeSetImpl,
llvm::IndexAttrPair>::operator delete' :
cannot access private member declared in class 'llvm::AttributeSetImpl'
TrailingObjects.h(298) : see declaration of
'llvm::TrailingObjects<llvm::AttributeSetImpl,
llvm::IndexAttrPair>::operator delete'
AttributeImpl.h(213) : see declaration of 'llvm::AttributeSetImpl'
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@260053 91177308-0d34-0410-b5e6-96231b3b80d8
-fsized-deallocation. Disable sized deallocation for all objects derived from
TrailingObjects, as we expect the storage allocated for these objects to be
larger than the size of their dynamic type.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259942 91177308-0d34-0410-b5e6-96231b3b80d8
Unfortunately, ProgramInfo::ProcessId is signed on Unix and unsigned on
Windows, breaking the standard fix of using '0U' in the gtest
expectation.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@259704 91177308-0d34-0410-b5e6-96231b3b80d8
at least as big as the mach header to be identified as a Mach-O file and
make sure smaller files are not identified as a Mach-O files but as
unknown files. Also fix identify_magic() so it looks at all 4 bytes of
the filetype field when determining the type of the Mach-O file.
Then fix the macho-invalid-header test case to check that it is an
unknown file and make sure it does not get the error for
object_error::parse_failed. And also update the unit tests.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258883 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This patch is provided in preparation for removing autoconf on 1/26. The proposal to remove autoconf on 1/26 was discussed on the llvm-dev thread here: http://lists.llvm.org/pipermail/llvm-dev/2016-January/093875.html
"I felt a great disturbance in the [build system], as if millions of [makefiles] suddenly cried out in terror and were suddenly silenced. I fear something [amazing] has happened."
- Obi Wan Kenobi
Reviewers: chandlerc, grosbach, bob.wilson, tstellarAMD, echristo, whitequark
Subscribers: chfast, simoncook, emaste, jholewinski, tberghammer, jfb, danalbert, srhines, arsenm, dschuff, jyknight, dsanders, joker.eph, llvm-commits
Differential Revision: http://reviews.llvm.org/D16471
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258861 91177308-0d34-0410-b5e6-96231b3b80d8
Using an array instead of ArrayRef would allow type inference, but
(short of using C99) one would still need to write
typedef uint16_t VT[];
LE.write(VT{0x1234, 0x5678});
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@258535 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Add SaturatingMultiplyAdd convenience function template since A + (X * Y) comes up frequently when doing weighted arithmetic.
Reviewers: davidxl, silvas
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15385
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@257532 91177308-0d34-0410-b5e6-96231b3b80d8
...and mark it as merely an input_iterator rather than a forward_iterator,
since it is destructive. And then rewrite == to take advantage of that.
Patch by Alex Denisov!
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256913 91177308-0d34-0410-b5e6-96231b3b80d8
This is necessary to use them as part of pointer traits and is generally
useful. I've added unit test coverage to isolate and ensure this works
correctly.
I'll watch the build bots to try to see if any compilers can't tolerate
this bit of magic (and much credit goes to Richard Smith for coming up
with this magical production!) but give a shout if you see issues.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256553 91177308-0d34-0410-b5e6-96231b3b80d8
Previously, the code enforced non-decreasing alignment of each trailing
type. However, it's easy enough to allow for realignment as needed, and
thus avoid the developer having to think about the possiblilities for
alignment requirements on all architectures.
(E.g. on Linux/x86, a struct with an int64 member is 4-byte aligned,
while on other 32-bit archs -- and even with other OSes on x86 -- it has
8-byte alignment. This sort of thing is irritating to have to manually
deal with.)
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256533 91177308-0d34-0410-b5e6-96231b3b80d8
Remove all checks that required main thread to run faster than tasks in
ThreadPool, and yields which are now unnecessary. This should fix some
bot failures.
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256056 91177308-0d34-0410-b5e6-96231b3b80d8
- Automatic alignment of the base type for the alignment requirements
of the trailing types.
- Support for an arbitrary numbers of trailing types, instead of only
1 or 2, by using a variadic template implementation.
Upcoming commits to clang will take advantage of both of these features.
Differential Revision: http://reviews.llvm.org/D12439
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@256054 91177308-0d34-0410-b5e6-96231b3b80d8
The current BranchProbability::normalizeProbabilities() forbids known and
unknown probabilities to coexist in the list. This was once used to help
capture probability exceptions but has caused some reported build
failures (https://llvm.org/bugs/show_bug.cgi?id=25838).
This patch removes this restriction by evenly distributing the complement
of the sum of all known probabilities to unknown ones. We could still
treat this as an abnormal behavior, but it is better to emit warnings in
our future profile validator.
Differential revision: http://reviews.llvm.org/D15548
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255934 91177308-0d34-0410-b5e6-96231b3b80d8
This is a very simple implementation of a thread pool using C++11
thread. It accepts any std::function<void()> for asynchronous
execution. Individual task can be synchronize using the returned
future, or the client can block on the full queue completion.
In case LLVM is configured with Threading disabled, it falls back
to sequential execution using std::async with launch:deferred.
This is intended to support parallelism for ThinLTO processing in
linker plugin, but is generic enough for any other uses.
This is a recommit of r255444 ; trying to workaround a bug in the
MSVC 2013 standard library. I think I was hit by:
http://connect.microsoft.com/VisualStudio/feedbackdetail/view/791185/std-packaged-task-t-where-t-is-void-or-a-reference-class-are-not-movable
Recommit of r255589, trying to please g++ as well.
Differential Revision: http://reviews.llvm.org/D15464
From: mehdi_amini <mehdi_amini@91177308-0d34-0410-b5e6-96231b3b80d8>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255593 91177308-0d34-0410-b5e6-96231b3b80d8
This is a very simple implementation of a thread pool using C++11
thread. It accepts any std::function<void()> for asynchronous
execution. Individual task can be synchronize using the returned
future, or the client can block on the full queue completion.
In case LLVM is configured with Threading disabled, it falls back
to sequential execution using std::async with launch:deferred.
This is intended to support parallelism for ThinLTO processing in
linker plugin, but is generic enough for any other uses.
This is a recommit of r255444 ; trying to workaround a bug in the
MSVC 2013 standard library. I think I was hit by:
http://connect.microsoft.com/VisualStudio/feedbackdetail/view/791185/std-packaged-task-t-where-t-is-void-or-a-reference-class-are-not-movable
Differential Revision: http://reviews.llvm.org/D15464
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255589 91177308-0d34-0410-b5e6-96231b3b80d8
This is a very simple implementation of a thread pool using C++11
thread. It accepts any std::function<void()> for asynchronous
execution. Individual task can be synchronize using the returned
future, or the client can block on the full queue completion.
In case LLVM is configured with Threading disabled, it falls back
to sequential execution using std::async with launch:deferred.
This is intended to support parallelism for ThinLTO processing in
linker plugin, but is generic enough for any other uses.
Differential Revision: http://reviews.llvm.org/D15464
From: Mehdi Amini <mehdi.amini@apple.com>
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255444 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
Improve SaturatingAdd()/SaturatingMultiply() to use bool * to optionally return overflow result.
This should make it clearer that the value is returned at callsites and reduces the size of the implementation.
Reviewers: davidxl, silvas
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D15219
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@255128 91177308-0d34-0410-b5e6-96231b3b80d8
Summary: Adds the ability for callers to detect when saturation occurred on the result of saturating addition/multiplication.
Reviewers: davidxl, silvas, rsmith
Subscribers: llvm-commits
Differential Revision: http://reviews.llvm.org/D14931
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253921 91177308-0d34-0410-b5e6-96231b3b80d8
Summary:
This change fixes the SaturatingMultiply<T>() function template to not cause undefined behavior with T=uint16_t.
Thanks to Richard Smith's contribution, it also no longer requires an integer division.
Patch by Richard Smith.
Reviewers: silvas, davidxl
Subscribers: rsmith, davidxl, llvm-commits
Differential Revision: http://reviews.llvm.org/D14845
git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk@253870 91177308-0d34-0410-b5e6-96231b3b80d8
