makes it easier to build head on stable/9, where libstdc++ is still the
default. We can revisit this when somebody will try to build base with
gcc 4.8.1 or higher, and its included libstdc++.
Reported by: rpaulo
[X86] Convert esp-relative movs of function arguments to pushes, step 2
This moves the transformation introduced in r223757 into a separate MI pass.
This allows it to cover many more cases (not only cases where there must be a
reserved call frame), and perform rudimentary call folding. It still doesn't
have a heuristic, so it is enabled only for optsize/minsize, with stack
alignment <= 8, where it ought to be a fairly clear win.
(Re-commit of r227728)
Differential Revision: http://reviews.llvm.org/D6789
This helps to get sys/boot/i386/boot2 below the required size again,
when optimizing with -Oz.
these in $LIBDIR/clang/$VERSION/include, instead of our previous custom
location in /usr/include/clang/$VERSION. This allows us to drop yet
another FreeBSD-specific patch.
to ease any rework of how clang is built to take arm64 in to account.
Submitted by: andrew
Reviewed by: andrew, emaste
Differential Revision: https://reviews.freebsd.org/D1446
the oabi is still in the tree, but it is expected this will be removed
as developers work on surrounding code.
With this commit the ARM EABI is the only supported supported ABI by
FreeBSD on ARMa 32-bit processors.
X-MFC after: never
Relnotes: yes
Differential Revision: https://reviews.freebsd.org/D876
This includes:
o All directories named *ia64*
o All files named *ia64*
o All ia64-specific code guarded by __ia64__
o All ia64-specific makefile logic
o Mention of ia64 in comments and documentation
This excludes:
o Everything under contrib/
o Everything under crypto/
o sys/xen/interface
o sys/sys/elf_common.h
Discussed at: BSDcan
source files could be passed to tblgen or clang-tblgen, leading to a
"Too many positional arguments specified" error message. Fix this by
replacing the too-generic ${.ALLSRC} sources with explicit paths.
Reported by: rysto32@gmail.com, rodrigc
MFC after: 3 days
and 3.4 to generate dependency files for the '.inc.h' files generated
from .td files, and .sinclude those dependency files in clang.build.mk.
This will make future incremental builds of lib/clang and usr.bin/clang
work correctly, whenever any of the .td files get modified.
Note that this will not fix any problems with incremental builds from
*before* this revision, since there will not yet be any generated
dependency files. A quick workaround is to run the following:
find /usr/obj -type f -name '*.inc.h' | xargs rm
and then a regular incremental buildworld (e.g. with -DNO_CLEAN).
MFC after: 3 days
and MK_LLDB=no, so set those explicitly (now that we can do
that). Simplify tests for these variables as well, since we know they
will always be defined regardless of the phase of the build.
all the SUBDIR entries in parallel, instead of serially. Apply this
option to a selected number of Makefiles, which can greatly speed up the
build on multi-core machines, when using make -j.
This can be extended to more Makefiles later on, whenever they are
verified to work correctly with parallel building.
I tested this on a 24-core machine, with make -j48 buildworld (N = 6):
before stddev after stddev
======= ====== ======= ======
real time 1741.1 16.5 959.8 2.7
user time 12468.7 16.4 14393.0 16.8
sys time 1825.0 54.8 2110.6 22.8
(user+sys)/real 8.2 17.1
E.g. the build was approximately 45% faster in real time. On machines
with less cores, or with lower -j settings, the speedup will not be as
impressive. But at least you can now almost max out a machine with
buildworld!
Submitted by: jilles
MFC after: 2 weeks
This targets the existing ARMv6 and ARMv7 SoCs that contain a VFP unit.
This is an optional coprocessors may not be present in all devices, however
it appears to be in all current SoCs we support.
armv6hf targets the VFP variant of the ARM EABI and our copy of gcc is too
old to support this. Because of this there are a number of WITH/WITHOUT
options that are unsupported and must be left as the default value. The
options and their required value are:
* WITH_ARM_EABI
* WITHOUT_GCC
* WITHOUT_GNUCXX
In addition, without an external toolchain, the following need to be left
as their default:
* WITH_CLANG
* WITH_CLANG_IS_CC
As there is a different method of passing float and double values to
functions the ABI is incompatible with existing armv6 binaries. To use
this a full rebuild of world is required. Because no floating point values
are passed into the kernel an armv6 kernel with VFP enabled will work with
an armv6hf userland and vice versa.
all of the features in the current working draft of the upcoming C++
standard, provisionally named C++1y.
The code generator's performance is greatly increased, and the loop
auto-vectorizer is now enabled at -Os and -O2 in addition to -O3. The
PowerPC backend has made several major improvements to code generation
quality and compile time, and the X86, SPARC, ARM32, Aarch64 and SystemZ
backends have all seen major feature work.
Release notes for llvm and clang can be found here:
<http://llvm.org/releases/3.4/docs/ReleaseNotes.html>
<http://llvm.org/releases/3.4/tools/clang/docs/ReleaseNotes.html>
MFC after: 1 month
This is in the process of being submitted to the upstream LLDB
repository. The thread list functionality is modelled in part on
GDBRemoteCommunicationClient.
LLDB bug pr16696 and code review D2267
Sponsored by: DARPA, AFRL
ludes minor changes relative to upstream, for compatibility with
FreeBSD's in-tree LLVM 3.3:
- Reverted LLDB r191806, restoring use of previous API.
- Reverted part of LLDB r189317, restoring previous enum names.
- Work around missing LLVM r192504, using previous registerEHFrames API
(limited functionality).
- Removed PlatformWindows header include and init/terminate calls.
Sponsored by: DARPA, AFRL
This connects LLDB to the build, but it is disabled by default. Add
WITH_LLDB= to src.conf to build it.
Note that LLDB requires a C++11 compiler so is disabled on platforms
using GCC.
Approved by: re (gjb)
Sponsored by: DARPA, AFRL
clang on head between r239347 and r245428.
The former revision introduced CLOCK_PROCESS_CPUTIME_ID as a clock id
for the clock_gettime() function and friends, but it was only added in
<sys/time.h>, not in <time.h>. Any program including <time.h> would
therefore not be able to use CLOCK_PROCESS_CPUTIME_ID, even though the
value of _POSIX_CPUTIME indicates its existence. The latter revision
synchronized the defines again.
Work around this problem by defining the id on the command line for the
particular .cpp file that needs it. If the id ever changes value, this
hack will need to be updated.
