the same as lrint() except it returns int instead of long. Though the
extern lrint() is fairly fast on these arches, it still takes about
12 cycles longer than the inline version, and 12 cycles is a lot in
applications where [li]rint() is used to avoid slow conversions that
are only a couple of times slower.
This is only for internal use. The libm versions of *rint*() should
also be inline, but that would take would take more header engineering.
Implementing irint() instead of lrint() also avoids a conflict with
the extern declaration of the latter.
on i386 (A64), 5 cycles on amd64 (A64), and 3 cycles on ia64). gcc
tends to generate very bad code for accessing floating point values
as bits except when the integer accesses have the same width as the
floating point values, and direct accesses to bit-fields (as is common
only for long double precision) always gives such accesses. Use the
expsign access method, which is good for 80-bit long doubles and
hopefully no worse for 128-bit long doubles. Now the generated code
is less bad. There is still unnecessary copying of the arg on amd64
and i386 and mysterious extra slowness on amd64.
Check that only MREMAP_FIXED and MREMAP_MAYMOVE flags are specified.
Check for the page alignment of the addr argument.
Submitted by: rdivacky
MFC after: 1 week
- Added loose RX MTU functionality to allow frames larger than 1500 bytes
to be accepted even though the interface MTU is set to 1500.
- Implemented new TCP header splitting/jumbo frame support which uses
two chains for receive traffic rather than the original single recevie
chain.
- Added additional debug support code.
binutils ar and ranlib to gar and granlib, respectively.
* Introduce a temporary variable WITH_GNUAR as a safety net.
When buildworld with -DWITH_GNUAR, GNU binutils ar and ranlib
will install as default ones and 'BSD' ar will be disabled.
* Bump __FreeBSD_version to reflect the import of 'BSD' ar(1).
Approved by: jkoshy (mentor)
Reviewed by: jkoshy
Approved by: jkoshy (mentor)
Tested by: erwin (ports build test on pointyhat)
Sponsored by: Google Summer of Code 2007
Reviewed by (earlier version): Jaakko Heinonen <jh[AT]saunalahti.fi>
Tested by (earlier version): Steve Kargl <sgk[AT]troutmask.apl.washington.edu>
Tested by (earlier version): Martin Voros <martin_voros[AT]yahoo.com>
Tested by (earlier version): swell.k[AT]gmail.com
Tested by (earlier version): joel
Tested by (earlier version): Alexey Shuvaev <shuvaev[AT]physik.uni-wuerzburg.de>
Tested by (earlier version): Arjan van Leeuwen <avleeuwen[AT]gmail.com>
Thanks to gabor@ for building ports for it.
Thanks to erwin@ and kris@ for scheduling the ports build test on pointyhat.
And thanks to many others for their feedback.
a bogus partition table and puts the file system on the whole
partition. geom_part doesn't expose the 'c' partition as it's an
artifact of the BSD label and not to be used. Secondly, gpart(8)
is the preferred tool for partitioning disks on ia64.
find the corresponding AS for that IP (-a switch).
We can also choose a different whois server with the -A switch. The
default is whois.radb.net.
Obtained from: NetBSD
Reviewed by: bms, njl (mentor)
Approved by: njl (mentor)
1) Use [AP]F_LOCAL rather than [AP]F_UNIX.
2) When copying a pipe's name, use f->f_un.f_pipe.f_pname, not f->f_un.f_fname.
PR: 20889
Submitted by: Damieon Stark
PR: 116642
Submitted by: Jim Pirzyk
Reviewed by: md5
The logical disks will appear as /dev/lvm/<vol group>-<logical vol>, for
instance /dev/lvm/vg0-home. G_LINUX_LVM currently supports linear stripes with
segments on multiple physical disks. The metadata is read only, logical
volumes can not be allocated or resized.
Reviewed by: Ivan Voras
Previously known as geom_lvm(4), rename requested by des, phk.
pi/4 <= |x| <= 3pi/4. Use the same branch ladder as for float precision.
Remove the optimization for |x| near pi/2 and don't do it near the
multiples of pi/2 in the newly optimized range, since it requires
fairly large code to handle only relativley few cases. Ifdef out
optimization for |x| <= pi/4 since this case can't occur because it
is done in callers.
On amd64 (A64), for cos() and sin() with uniformly distributed args,
no cache misses, some parallelism in the caller, and good but not great
CC and CFLAGS, etc., this saves about 40 cycles or 38% in the newly
optimized range, or about 27% on average across the range |x| <= 2pi
(~65 cycles for most args, while the A64 hardware fcos and fsin take
~75 cycles for half the args and 125 cycles for the other half). The
speedup for tan() is much smaller, especially relatively. The speedup
on i386 (A64) is slightly smaller, especially relatively. i386 is
still much slower than amd64 here (unlike in the float case where it
is slightly faster).
saves an average of about 8 cycles or 5% on A64 (amd64 and i386 --
more in cycles but about the same percentage on i386, and more with
old versions of gcc) with good CFLAGS and some parallelism in the
caller. As usual, it takes a couple more multiplications so it will
be slower on old machines.
Convert to __FBSDID().
Maybe. In the meantime, my workarounds for trying to coax UTC without
timegm() are getting uglier and uglier. Apparently, some systems
don't support setenv()/unsetenv(), so you can't set the TZ env var and
hope thereby to coax mktime() into generating UTC. Without that, I
don't see a really good alternative to just giving up and converting to
localtime with mktime(). (I suppose I should research the Perl library
approach for computing an inverse function to gmtime(); that might
actually be simpler than this growing list of hacks.)
