| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
|
| |
Release notes for llvm:
http://llvm.org/releases/3.2/docs/ReleaseNotes.html
Release notes for clang:
http://llvm.org/releases/3.2/tools/clang/docs/ReleaseNotes.html
MFC after: 2 weeks
|
| |
|
|
|
| |
branch. This is effectively llvm/clang 3.2 RC2; the 3.2 release is
coming soon.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
1. Don't do upgrade_checks when using bmake. As long as we have WITH_BMAKE,
there's a bootstrap complication in ths respect. Avoid it. Make the
necessary changes to have upgrade_checks work wth bmake anyway.
2. Remove the use of -E. It's not needed in our build because we use ?= for
the respective variables, which means that we'll take the environment
value (if any) anyway.
3. Properly declare phony targets as phony as bmake is a lot smarter (and
thus agressive) about build avoidance.
4. Make sure CLEANFILES is complete and use it on .NOPATH. bmake is a lot
smarter about build avoidance and should not find files we generate in
the source tree. We should not have files in the repository we want to
generate, but this is an easier way to cross this hurdle.
5. Have behavior under bmake the same as it is under make with respect to
halting when sub-commands fail. Add "set -e" to compound commands so
that bmake is informed when sub-commands fail.
6. Make sure crunchgen uses the same make as the rest of the build. This
is important when the make utility isn't called make (but bmake for
example).
7. While here, add support for using MAKEOBJDIR to set the object tree
location. It's the second alternative bmake looks for when determining
the actual object directory (= .OBJDIR).
Submitted by: Simon Gerraty <sjg@juniper.net>
Submitted by: John Van Horne <jvanhorne@juniper.net>
|
| |
|
|
|
|
|
|
|
|
| |
to be a wrapper for the canonical system header file. Unfortunately, we do
not have one (yet) and some times it is causing weird failures when clang
is used for building ports. More complete and correct file will come from
libcxxrt in the future.
Discussed with: dim, kib, theraven
MFC after: 1 week
|
| |
|
|
| |
previous import.
|
| |
|
|
| |
Benjamin Kramer and Joerg Sonnenberger for their input and fixes.
|
| |
|
|
|
|
| |
found at: http://llvm.org/releases/3.1/docs/ReleaseNotes.html
MFC after: 3 days
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
in the last import. They are sometimes needed when you want to use
advanced instructions.
Also, add clang's internal stdalign.h header to ObsoleteFiles.inc, since
it is redundant: we already have a stdalign.h header in /usr/include.
Pointy hat to: dim
PR: kern/167574
Submitted by: jkim
Reported by: Oliver Hartmann <ohartman@zedat.fu-berlin.de>
MFC after: 2 weeks
|
| |
|
|
|
|
|
| |
branch. This brings us very close to the 3.1 release, which is planned
for May 14th.
MFC after: 2 weeks
|
| |
|
|
|
|
|
| |
upcoming 3.1 release (expected in a few weeks). Preliminary release
notes can be found at: <http://llvm.org/docs/ReleaseNotes.html>
MFC after: 2 weeks
|
| |
|
|
|
|
|
| |
The r145546 revision is from branches/release_30, the r145349 revision
is from tags/RELEASE_30/final.
MFC after: 1 week
|
| |
|
|
|
|
| |
found at: http://llvm.org/releases/3.0/docs/ReleaseNotes.html
MFC after: 1 week
|
| |
|
|
|
|
|
|
|
|
|
| |
allow the built-in operations to be redefined, at least not without
excessive force).
Instead, just disable LLVM's support for atomic operations for now.
Nothing in either clang or the tablegen tools currently depends on it.
This still allows users of head built before r198344 to upgrade to
top-of-head seamlessly.
|
| |
|
|
|
|
|
|
|
|
|
| |
to be gcc's default before r198344, calls to atomic builtins will not be
expanded inline. Instead, they will be generated as calls to external
functions (e.g. __sync_fetch_and_add_N), leading to linking errors later
on.
Put in a seatbelt that disables use of atomic builtins in libstdc++ and
llvm, when tuning specifically for the real i386 CPU. This does not
protect against all possible issues, but it is better than nothing.
|
| |
|
|
|
|
|
| |
branch. This brings us very close to the 3.0 release, which is expected
in a week or two.
MFC after: 1 week
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
There are several bugfixes in this update, but the most important one is
to ensure __start_ and __stop_ symbols for linker sets and kernel module
metadata are always emitted in object files:
http://llvm.org/bugs/show_bug.cgi?id=9292
Before this fix, if you compiled kernel modules with clang, they would
not be properly processed by kldxref, and if they had any dependencies,
the kernel would fail to load those. Another problem occurred when
attempting to mount a tmpfs filesystem, which would result in 'operation
not supported by device'.
|
| |
|
|
|
| |
and test appropriately. Otherwise it might erroneously pick up some
pthread primitives, and fail to link.
|
| |
|
|
| |
a regular autoconf-based build. More cosmetic than functional changes.
|
| |
|
|
|
| |
This contains many improvements, primarily better C++ support, an
integrated assembler for x86 and support for -pg.
|
| |
|
|
|
|
| |
http://llvm.org/releases/2.8/docs/ReleaseNotes.html
Approved by: rpaulo (mentor)
|
| |
|
|
| |
Approved-by: rpaulo (mentor)
|
| |
|
|
|
|
|
|
|
| |
This commit merges the latest LLVM sources from the vendor space. It
also updates the build glue to match the new sources. Clang's version
number is changed to match LLVM's, which means /usr/include/clang/2.0
has been renamed to /usr/include/clang/2.8.
Obtained from: projects/clangbsd
|
| |
|
|
|
|
|
|
|
| |
Even though it's nice to use posix_spawn() instead of manually using
fork()/exec(), it's better to disable this. FreeBSD 7 doesn't support
this interface. When enabled, we can't build tblgen, which prevents us
from building FreeBSD 9 on 7.
Tested by: raj
|
| |
|
|
|
| |
This ensures that the Clang binary doesn't change checksums every time
it's built.
|
|
|
Approved by: ed (mentor)
|
