break mixed form dialogs in conjunction with the FreeBSD termcap, making
the bsdinstall partition editor Add dialog, among other things, completely
nonfunctional. This restores dialog 20110707.
There is a bug in gcc (GCC/35998) where dwarf reports
sizes of unsigned -1 (0xffffffff).
On NetBSD this generated a faulty CTF entry which then
caused a segfault in ctfmerge. The issue was worked
around in NetBSD's Dtrace but since the issue originated
in gcc, it seems reasonable to fix it here.
Upstream gcc has been slow to react to this issue and
the author that submitted the patch is not interested
in licensing the change to us, so I did an independent
workaround for the issue.
MFC after: 1 week
should never do so. This can cause global constructors and destructors
to not be executed at run-time, resulting in crashes and other strange
behaviour.
Reported by: rene
MFC after: 1 week
Fix another SROA crasher, PR14601.
This was a silly oversight, we weren't pruning allocas which were used
by variable-length memory intrinsics from the set that could be widened
and promoted as integers. Fix that.
This should fix the following assertion failure:
Assertion failed: (CanSROA), function visitUsers, file
/usr/src/lib/clang/libllvmscalaropts/../../../contrib/llvm/lib/Transforms/Scalar/SROA.cpp,
line 2395.
Reported by: gerald
towards replacing our mtree.
Sponsored by: DARPA, AFRL
Thanks to: cristos@NetBSD for reviewing and committing my patches
wiz@NetBSD for fixing typos in my patches
NetBSD's. This output size limited versions of vis and unvis functions
as well as a set of vis variants that allow arbitrary characters to be
specified for encoding.
Finally, MIME Quoted-Printable encoding as described in RFC 2045 is
supported.
built with clang. When these are defined the lists are defined similar to:
asm(".section .ctors");
STATIC func_ptr __CTOR_LIST__[1] = { (func_ptr) (-1) };
asm(".section .dtors");
STATIC func_ptr __DTOR_LIST__[1] = { (func_ptr) (-1) };
The problem is clang will move the two arrays out of the .ctors and .dtors
sections causing these sections to contain a single null address. By not
defining these macros we use the version of the code that places the arrays
is their sections by using __attribute__((section(".ctors"))) and similar
for .dtors.
Submitted by: Daisuke Aoyama <aoyama AT peach.ne.jp>
included various upstreamed patches from the FreeBSD base to make OpenBSM
compile more easily with bmake, higher warning levels, clang, and several
other loose ends.
Obtained from: TrustedBSD Project
Security Fixes
Prevents named from aborting with a require assertion failure
on servers with DNS64 enabled. These crashes might occur as a
result of specific queries that are received.
New Features
* Elliptic Curve Digital Signature Algorithm keys and signatures in
DNSSEC are now supported per RFC 6605. [RT #21918]
Feature Changes
* Improves OpenSSL error logging [RT #29932]
* nslookup now returns a nonzero exit code when it is unable to get
an answer. [RT #29492]
Other critical bug fixes are included.
Approved by: delphij (mentor)
MFC after: 3 days
Security: CVE-2012-5688
Sponsored by: DK Hostmaster A/S
share/mk/sys.mk instead.
This is part of a medium term project to permit deterministic builds of
FreeBSD.
Submitted by: Erik Cederstrand <erik@cederstrand.dk>
Reviewed by: imp, toolchain@
Approved by: cperciva
MFC after: 2 weeks
When using libc++ headers on FreeBSD, in combination with -std=c++98,
-ansi or -std=c++03, the long long type is not supported. So in this
case, several functions and types, like lldiv_t, strtoll(), are not
declared.
This should make it possible to use the libc++ headers in c++98 mode.
Note: libc++ is originally designed as a c++0x or higher library, so you
should still take care when using it with c++98 or c++03.
Noted by: Yamaya Takashi <yamayan@kbh.biglobe.ne.jp>
MFC after: 1 week
This improves GDB usability when debugging code compiled with
optimization.
Upstream GDB revision f0031b6d3ae9b164b3747986ab898190bd4dcf8c (prior
to GDB's switch to GPLv3), with frame_debug_got_null_frame expanded
inline.
| 2004-12-12 Andrew Cagney <cagney@gnu.org>
|
| * frame.c (get_prev_frame): When unwinding normal frames, check
| that the PC isn't zero.
Sponsored by: ADARA Networks
MFC After: 1 month
X86: fcmov doesn't handle all possible EFLAGS, fall back to a branch
for the others.
Otherwise it will try to use SSE patterns and fail horribly if sse is
disabled.
Fixes PR14035.
This should fix the following assertion failure:
Assertion failed: (Reg >= X86::FP0 && Reg <= X86::FP6 && "Expected FP
register!"), function getFPReg, file
contrib/llvm/lib/Target/X86/X86FloatingPoint.cpp, line 330.
which can show up when compiling contrib/compiler-rt, using -march=i686
through -march=pentium3 (CPU's which do support fcmov, but don't support
SSE2).
MFC after: 1 week
Add a new warning -Wmissing-variable-declarations, to warn about variables
defined without a previous declaration. This is similar to
-Wmissing-prototypes, but for variables instead of functions.
Make sure always-inline functions get inlined. <rdar://problem/12423986>
Without this change, when the estimated cost for inlining a function with
an "alwaysinline" attribute was lower than the inlining threshold, the
getInlineCost function was returning that estimated cost rather than the
special InlineCost::AlwaysInlineCost value. That is fine in the normal
inlining case, but it can fail when the inliner considers the opportunity
cost of inlining into an internal or linkonce-odr function. It may decide
not to inline the always-inline function in that case. The fix here is just
to make getInlineCost always return the special value for always-inline
functions. I ran into this building clang with libc++. Tablegen failed to
link because of an always-inline function that was not inlined. I have been
unable to reduce the testcase down to a reasonable size.
This should fix the link errors that were reported when atf-run was
compiled with clang -stdlib=libc++. In this case, at -O3 optimization,
some calls to basic_ios::clear() were not inlined, even when the
function was marked __always_inline__.
Reported by: Jan Beich <jbeich@tormail.org>
MFC after: 1 week
