Import compiler-rt r147467.
Vendor import of llvm release_31 final r156748:
http://llvm.org/svn/llvm-project/llvm/tags/RELEASE_31/final@156748
Vendor import of clang release_31 final r156748:
http://llvm.org/svn/llvm-project/cfe/tags/RELEASE_31/final@156748
Vendor import of llvm release_31 r156863 (the actual 3.1 release):
http://llvm.org/svn/llvm-project/llvm/branches/release_31@156863
Vendor import of clang release_31 r156863 (the actual 3.1 release):
http://llvm.org/svn/llvm-project/cfe/branches/release_31@156863
Import compiler-rt r160957.
The assertion that I added in r238889 could legitimately fail when a
debugger creates a breakpoint.  Replace that assertion with a narrower
one that still achieves my objective.

Reported and tested by:	kib
Import compiler-rt r160957.

This is mostly a no-op other than for ARM where it adds missing
__aeabi_mem* and __aeabi_*divmod functions. Even on ARM these will remain
unused until the rest of the ARM EABI code is merged.
Round displayed pps (instead of truncating)
Clarify comments about number of tx / rx rings
Fix whitespace (missing newline)
Fix an incorrect comment.
More rototilling with target mode in an attemp to get multiple
CCB at a time outstanding reliable. It's not there yet, but this
is the direction to go in so might as well commit. So far,
multiple at a time CCBs work (see ISP_INTERNAL_TARGET test mode),
but it fails if there are more downstream than the SIM wants
to handle and SRR is sort of confused when this happens, plus
it is not entirely quite clear what one does if a CCB/CTIO fails
and you have more in flight (that don't fail, say) and more queued
up at the SIM level that haven't been started yet.

Some of this is driven because there apparently is no flow control
to requeue XPT_CONTINUE_IO requests like there are for XPT_SCSI_IO
requests. It is also more driven in that the few target mode
periph drivers there are are not really set up for handling pushback-
heck most of them don't even check for errors (and what would they
really do with them anyway? It's the initiator's problem, really....).

The data transfer arithmetic has been worked over again to handle
multiple outstanding commands, so you have a notion of what's been
moved already as well as what's currently in flight. It turns that
this led to uncovering a REPORT_LUNS bug in the ISP_INTERNAL_TARGET
code which was sending back 24 bytes of rpl data instead of the
specified 16. What happened furthermore here is that sending back
16 bytes and reporting an overrun of 8 bytes made the initiator
(running FC-Tape aware f/w) mad enough to request, and keep
requesting, another FCP response (I guess it didn't like the answer
so kept asking for it again).

Sponsored by: Spectralogic
MFC after:	1 month
Be more descriptive about poll error / timeout when transmitting.
Improve lock and unlock symmetry

- Move destruction of per-ring locks to netmap_dtor_locked to mirror the
initialization that happens in NIOCREGIF.  Otherwise unloading a netmap-
capable interface that was never put into netmap mode would try to
mtx_destroy an uninitialized mutex, and panic.

- Destroy core_lock in netmap_detach, mirroring init in netmap_attach.

- Also comment out the knlist_destroy for now as there is currently no
knlist_init.

Sponsored by:   ADARA Networks
Reviewed by:    luigi@
nftw(): Do not check the maxfds argument against OPEN_MAX.

Apart from the fact that nothing should have OPEN_MAX as a limit (as opposed
to RLIMIT_NOFILE from getrlimit() or _SC_OPEN_MAX from sysconf()), POSIX
does not require us to check this.

PR:		95239
Submitted by:	Todd Miller
ftw(): Do not check the maxfds argument against OPEN_MAX.

Apart from the fact that nothing should have OPEN_MAX as a limit (as opposed
to RLIMIT_NOFILE from getrlimit() or _SC_OPEN_MAX from sysconf()), POSIX
does not require us to check this. POSIX does have a requirement on the
application that maxfds not exceed {OPEN_MAX}, but does not require the
implementation to check it ("may fail").

PR:		95239
Merge r132141 and r111272 from amd64/i386:
  Reduce the size of a PV entry by eliminating pv_ptem.  There is no need
  to store a pointer to the page table page in the PV entry because it is
  easily computed during the walk down the page table.

  Eliminate the ptphint from the pmap.  Long, long ago, page table pages
  belonged to a vm object, and we would look up page table pages based
  upon their offset within this vm object.  In those days, this hint may
  have had tangible benefits.

Tested by:	jchandra
SCHED_4BSD scheduling quantum mechanism appears to be broken for some time.
With switchticks variable being reset each time thread preempted (that is
done regularly by interrupt threads) scheduling quantum may never expire.
It was not noticed in time because several other factors still regularly
trigger context switches.

Handle the problem by replacing that mechanism with its equivalent from
SCHED_ULE called time slice. It is effectively the same, just measured in
context of stathz instead of hz. Some unification is probably not bad.
Refresh with OpenBSD RCS ID changes to reflect that we now have essentionally
the same file.