History log of /dragonfly/lib/libc/x86_64/gen/signbitl.c (Results 1 – 5 of 5)
Revision (<<< Hide revision tags) (Show revision tags >>>) Date Author Comments
Revision tags: v6.2.1, v6.2.0, v6.3.0, v6.0.1, v6.0.0, v6.0.0rc1, v6.1.0, v5.8.3, v5.8.2, v5.8.1, v5.8.0, v5.9.0, v5.8.0rc1, v5.6.3, v5.6.2, v5.6.1, v5.6.0, v5.6.0rc1, v5.7.0, v5.4.3, v5.4.2, v5.4.1, v5.4.0, v5.5.0, v5.4.0rc1, v5.2.2, v5.2.1, v5.2.0, v5.3.0, v5.2.0rc, v5.0.2, v5.0.1, v5.0.0, v5.0.0rc2, v5.1.0, v5.0.0rc1, v4.8.1, v4.8.0, v4.6.2, v4.9.0, v4.8.0rc, v4.6.1, v4.6.0, v4.6.0rc2, v4.6.0rc, v4.7.0, v4.4.3, v4.4.2, v4.4.1, v4.4.0, v4.5.0, v4.4.0rc, v4.2.4, v4.3.1
# be0c75e8 13-Jul-2015 John Marino <draco@marino.st>

Replace hybrid libm with OpenBSD libm on vendor branch

In order to gain full c++11 support on GCC, we had to import a number
of long double functions from NetBSD, once again converting libm into
a h

Replace hybrid libm with OpenBSD libm on vendor branch

In order to gain full c++11 support on GCC, we had to import a number
of long double functions from NetBSD, once again converting libm into
a hybrid library from a mixture of sources. As of today, FreeBSD still
doesn't have the missing functions and the PR on broken c++11 has been
lingering for months.

The OpenBSD libm is complete and maintained[1][2]. It's unmodified
sources are in vendor/OPENBSD_LIBM branch with local modifications (to
squelch gcc warnings and adjust for OS differences mainly) are applied
to the master for easy diff generation.

A dports bulk build was executing using the new math library and the
result is the ports built normally.

[1] The final two "imprecise" functions were replaced by proper long
double versions. The imprecise versions remain as older symbols
(libm has symbol versioning) so this source is additional to what
is provided in the vendor branch. (powl, tgammal)

[2] There were several DF306.0 symbols that are not present in OpenLIBM,
partially because they've been moved to libc or were always there.
In order to maintain backwards capability, copies of these functions
with new names are built into libm, and given DF306.0 versions only.
Without the version suffix, these past functions will not link to
new programs.

show more ...


Revision tags: v4.2.3, v4.2.1, v4.2.0, v4.0.6, v4.3.0, v4.2.0rc, v4.0.5, v4.0.4, v4.0.3, v4.0.2, v4.0.1, v4.0.0, v4.0.0rc3, v4.0.0rc2, v4.0.0rc, v4.1.0, v3.8.2, v3.8.1, v3.6.3, v3.8.0, v3.8.0rc2, v3.9.0, v3.8.0rc, v3.6.2, v3.6.1, v3.6.0, v3.7.1, v3.6.0rc, v3.7.0, v3.4.3, v3.4.2, v3.4.0, v3.4.1, v3.4.0rc, v3.5.0, v3.2.2, v3.2.1, v3.2.0, v3.3.0, v3.0.3
# 6f93d55f 14-Apr-2012 Sascha Wildner <saw@online.de>

Remove some unnecessary inclusions of <sys/cdefs.h> across the tree.


Revision tags: v3.0.2, v3.0.1, v3.1.0, v3.0.0
# 86d7f5d3 26-Nov-2011 John Marino <draco@marino.st>

Initial import of binutils 2.22 on the new vendor branch

Future versions of binutils will also reside on this branch rather
than continuing to create new binutils branches for each new version.


Revision tags: v2.12.0, v2.13.0, v2.10.1, v2.11.0, v2.10.0, v2.9.1, v2.8.2, v2.8.1, v2.8.0, v2.9.0, v2.6.3, v2.7.3, v2.6.2, v2.7.2, v2.7.1, v2.6.1, v2.7.0, v2.6.0
# b2b3ffcd 04-Nov-2009 Simon Schubert <corecode@dragonflybsd.org>

rename amd64 architecture to x86_64

The rest of the world seems to call amd64 x86_64. Bite the bullet and
rename all of the architecture files and references. This will
hopefully make pkgsrc build

rename amd64 architecture to x86_64

The rest of the world seems to call amd64 x86_64. Bite the bullet and
rename all of the architecture files and references. This will
hopefully make pkgsrc builds less painful.

Discussed-with: dillon@

show more ...


# c1543a89 04-Nov-2009 Simon Schubert <corecode@dragonflybsd.org>

rename amd64 architecture to x86_64

The rest of the world seems to call amd64 x86_64. Bite the bullet and
rename all of the architecture files and references. This will
hopefully make pkgsrc build

rename amd64 architecture to x86_64

The rest of the world seems to call amd64 x86_64. Bite the bullet and
rename all of the architecture files and references. This will
hopefully make pkgsrc builds less painful.

Discussed-with: dillon@

show more ...