Re: svn commit: r336299 - in head: include lib/msun lib/msun/ld128 lib/msun/ld80 lib/msun/man lib/msun/src
On Thu, 20 Sep 2018, John Baldwin wrote:
On 9/20/18 2:43 PM, Li-Wen Hsu wrote:
...
I suspect this. Each build is in a fresh created jail with the latest
branch of packages from pkg.freebsd.org.
At the beginning of (warning: 56MB file)
https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/7262/consoleText
There is:
New packages to be INSTALLED:
amd64-xtoolchain-gcc: 0.4_1
amd64-gcc: 6.4.0_2
mpfr: 4.0.1
gmp: 6.1.2
mpc: 1.1.0_1
amd64-binutils: 2.30_5,1
Number of packages to be installed: 6
Or is there a newer version of devel/amd64-gcc I am not aware?
That has the change Mark Millard is thinking of:
https://svnweb.freebsd.org/ports?view=revision=475290
However, I suspect this is due to a different issue. I still have some
patches that I need to get an i386 world to build with external GCC that
I'm not sure of and haven't posted for review yet. I bet these also matter
for the -m32 build:
This is more broken than before.
Index: lib/libc/tests/stdio/printfloat_test.c
===
--- lib/libc/tests/stdio/printfloat_test.c (revision 338373)
+++ lib/libc/tests/stdio/printfloat_test.c (working copy)
@@ -315,7 +315,7 @@
testfmt("0x1p-1074", "%a", 0x1p-1074);
testfmt("0x1.2345p-1024", "%a", 0x1.2345p-1024);
-#if (LDBL_MANT_DIG == 64)
+#if (LDBL_MANT_DIG == 64) && !defined(__i386__)
testfmt("0x1.921fb54442d18468p+1", "%La", 0x3.243f6a8885a308dp0L);
testfmt("0x1p-16445", "%La", 0x1p-16445L);
testfmt("0x1.30ecap-16381", "%La", 0x9.8765p-16384L);
This is further loss of test coverage for i386. I don't know why this
wasn't already turned off. Perhaps because the test is broken, but clang
is compatibly broken. On i386, the default rounding precision is supposed
to be 53 bits, so 64-bit hex constants can only work if their 11 lowest bits
are all zero, but the first one in this ifdef only has the 2 lowest digits
all zero.
I don't like the method used in these tests and haven't looked at them much.
I would never write ld80 long doubles in the hex used format above. This
makes them unreadable by putting 1 bit to the left of the decimal point so
63 to the right. They have to be shifted left by 1 to decrypt the low bits.
Shiftung 8468 gives 4234. The low 12 bits are 234, but correct rounding
would give 000 (800 for some other values). This is an easy case since
there are no carries.
Index: sys/x86/include/float.h
===
--- sys/x86/include/float.h (revision 338373)
+++ sys/x86/include/float.h (working copy)
@@ -86,10 +86,18 @@
#define LDBL_EPSILON1.0842021724855044340E-19L
#define LDBL_DIG18
#define LDBL_MIN_EXP(-16381)
+#if defined(__i386__)
+#define LDBL_MIN 33621031431120935
+#else
#define LDBL_MIN33621031431120935063
+#endif
#define LDBL_MIN_10_EXP (-4931)
#define LDBL_MAX_EXP16384
+#if defined(__i386__)
+#defineLDBL_MAX1.1897314953572316e+4932L
+#else
#define LDBL_MAX1.1897314953572317650E+4932L
+#endif
#define LDBL_MAX_10_EXP 4932
#if __ISO_C_VISIBLE >= 2011
#define LDBL_TRUE_MIN 3.6451995318824746025E-4951L
I already pointed out that it is difficult to write these values in
decimal, since clang will round to 64 bits.
Note that these values must be written in decimal to support C90.
Testing shows that clang produces the following wrong values from the
new limits:
For LDBL_MAX, with 64-bit precision the lower 3 nybbles would be FFF;
rounding 53 bits should change these nybbles to 800, but with the new
value above clang gives 600.
Actually, it is not very hard to write the correct value in decimal.
Simply print 0x0.f800p16384 in decimal with enough digits.
"enough" is DECIMAL_DIG = 21. The main error in the above is that it
misrounds by discarding 4 decimal digits (from DECIMAL_DIG = 21 digits
down to DBL_DECIMAL_DIG = 17). Since clang will round to 64 binary
digits, 21 decimal digits are still needed.
Correct value from this:
#define LDBL_MAX1.1897314953572316330E+4932L
(This uses only 20 decimal digits, since 21 is rarely needed and is never
needed in float.h and float.h now uses 20.)
For LDBL_MIN, the result 16 ulps below the largest denormal which is
already 1 ulp too small (on a different ulp scale).
No ifdef is needed for LDBL_MIN, since all bits except the highest bit
in its mantissa are 0, so rounding to any nonzero number of bits doesn't
change anything.
C11 added LDBL_TRUE_MIN and friends (for the denormal limit). No ifdef
was added for it, and none is needed, as above
With the old limits, the values produced are:
For LDBL_MIN and LDBL_TRUE_MIN: correct in all cases.
For LDBL_MAX: gigo (+Inf) with gcc. gigo (LDBL_MAX for non-default 64-bit
precision) with clang.
The clang bug breaks sanity tests and is easy to test for. E.g., when
x == LDBL_MAX, then x + 0 should be x,
Re: svn commit: r336299 - in head: include lib/msun lib/msun/ld128 lib/msun/ld80 lib/msun/man lib/msun/src
[I've got a historical WERROR= used in my amd64-gcc based builds.]
On 2018-Sep-20, at 6:05 PM, Mark Millard wrote:
> Li-Wen Hsu lwhsu at freebsd.org wrote on
> Thu Sep 20 22:10:19 UTC 2018 :
>
>> On Thu, Sep 20, 2018 at 10:06 PM Mark Johnston wrote:
>>>
>>> On Thu, Sep 20, 2018 at 09:39:24AM -0700, John Baldwin wrote:
On 9/20/18 8:54 AM, Mark Johnston wrote:
> On Sun, Jul 15, 2018 at 12:23:11AM +, Matt Macy wrote:
>> Author: mmacy
>> Date: Sun Jul 15 00:23:10 2018
>> New Revision: 336299
>> URL: https://svnweb.freebsd.org/changeset/base/336299
>>
>> Log:
>> msun: add ld80/ld128 powl, cpow, cpowf, cpowl from openbsd
>>
>> This corresponds to the latest status (hasn't changed in 9+
>> years) from openbsd of ld80/ld128 powl, and source cpowf, cpow,
>> cpowl (the complex power functions for float complex, double
>> complex, and long double complex) which are required for C99
>> compliance and were missing from FreeBSD. Also required for
>> some numerical codes using complex numbered Hamiltonians.
>>
>> Thanks to jhb for tracking down the issue with making
>> weak_reference compile on powerpc.
>>
>> When asked to review, bde said "I don't like it" - but
>> provided no actionable feedback or superior implementations.
>>
>> Discussed with: jhb
>> Submitted by: jmd
>> Differential Revision: https://reviews.freebsd.org/D15919
>
> This seems to have broken the gcc build:
> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/
>
> /workspace/src/lib/msun/ld80/e_powl.c:275:1: error: floating constant
> exceeds range of 'long double' [-Werror=overflow]
> if( y >= LDBL_MAX )
> ^~
Which architecture? i386 doesn't get build with i386-xtoolchain-gcc
pending
some patches I haven't yet posted for review related to the weirdness we do
with floating point on i386.
>>>
>>> This is the -m32 build on amd64. I haven't tested it myself, but Mark
>>> Millard noted that the issue might be fixed by a gcc update.
>>>
>>
>> I suspect this. Each build is in a fresh created jail with the latest
>> branch of packages from pkg.freebsd.org.
>>
>> At the beginning of (warning: 56MB file)
>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/7262/consoleText
>>
>> There is:
>>
>> New packages to be INSTALLED:
>>amd64-xtoolchain-gcc: 0.4_1
>>amd64-gcc: 6.4.0_2
>>mpfr: 4.0.1
>>gmp: 6.1.2
>>mpc: 1.1.0_1
>>amd64-binutils: 2.30_5,1
>>
>> Number of packages to be installed: 6
>>
>> Or is there a newer version of devel/amd64-gcc I am not aware?
>
> I wonder when ci.freebsd.org started using "amd64-gcc: 6.4.0_2".
> Looking: https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6665/consoleText
> from back on 2018-Jul-26. This suggests being based on
> -r475319 (2018-Jul-25) for devel/powerpc-gcc (the master
> port).
>
> Looks like -r475290 (the float.h removal) is the first version
> with PORT_REVISION being 2, as are all later versions at
> this point. Technically -r476273 (2018-Aug-2) removed a typo from
> -r475290 but at the time the typo seemed to not make an operational
> difference. Still, ci.freebsd.org seems to not be
> using the version with the typo fixed.
>
> Looks like system head being built was -r338831. (I'm only at
> -r338675 so far.)
>
> I've started a buildworld buildkernel based -on head -r3338675
> and based on master port:
>
> # svnlite diff /usr/ports/devel/powerpc64-gcc/ | more
> Index: /usr/ports/devel/powerpc64-gcc/Makefile
> ===
> --- /usr/ports/devel/powerpc64-gcc/Makefile (revision 480180)
> +++ /usr/ports/devel/powerpc64-gcc/Makefile (working copy)
> @@ -16,7 +16,8 @@
> LIB_DEPENDS= libgmp.so:math/gmp \
>libmpfr.so:math/mpfr \
>libmpc.so:math/mpc
> -BUILD_DEPENDS= ${BU_PREFIX}-as:devel/${PKGNAMEPREFIX}binutils
> +BUILD_DEPENDS= ${BU_PREFIX}-as:devel/${PKGNAMEPREFIX}binutils \
> + objdump:devel/binutils
> RUN_DEPENDS= ${BU_PREFIX}-as:devel/${PKGNAMEPREFIX}binutils
>
> USES= gmake iconv libtool tar:xz makeinfo compiler
>
> which does not have -r478209 involved ( un-breaking
> devel/aarch64-none-elf-gcc ).
>
> # svnlite diff /usr/ports/devel/amd64-gcc/ | more
> #
>
> So no differences there (relative to -r480180).
>
>
> (The objdump is from having built systems based on
> WITHOUT_BINUTILS and WITHOUT_BINUTILS_BOOTSTRAP at times
> but some devel/*-gcc builds trying to use objdump in the
> configuration part of gcc's build.)
>
> My past builds using at or after -r475290 for various system
> head revisions have completed without being stopped by an
> error but it has been a while. I will see for this one, but
> it is only into building lib32 so far.
>
> (Note: My port builds are via devel/poudriere-devel tied to
> my /usr/ports/ and to my
>
Re: svn commit: r336299 - in head: include lib/msun lib/msun/ld128 lib/msun/ld80 lib/msun/man lib/msun/src
Li-Wen Hsu lwhsu at freebsd.org wrote on
Thu Sep 20 22:10:19 UTC 2018 :
> On Thu, Sep 20, 2018 at 10:06 PM Mark Johnston wrote:
> >
> > On Thu, Sep 20, 2018 at 09:39:24AM -0700, John Baldwin wrote:
> > > On 9/20/18 8:54 AM, Mark Johnston wrote:
> > > > On Sun, Jul 15, 2018 at 12:23:11AM +, Matt Macy wrote:
> > > >> Author: mmacy
> > > >> Date: Sun Jul 15 00:23:10 2018
> > > >> New Revision: 336299
> > > >> URL: https://svnweb.freebsd.org/changeset/base/336299
> > > >>
> > > >> Log:
> > > >> msun: add ld80/ld128 powl, cpow, cpowf, cpowl from openbsd
> > > >>
> > > >> This corresponds to the latest status (hasn't changed in 9+
> > > >> years) from openbsd of ld80/ld128 powl, and source cpowf, cpow,
> > > >> cpowl (the complex power functions for float complex, double
> > > >> complex, and long double complex) which are required for C99
> > > >> compliance and were missing from FreeBSD. Also required for
> > > >> some numerical codes using complex numbered Hamiltonians.
> > > >>
> > > >> Thanks to jhb for tracking down the issue with making
> > > >> weak_reference compile on powerpc.
> > > >>
> > > >> When asked to review, bde said "I don't like it" - but
> > > >> provided no actionable feedback or superior implementations.
> > > >>
> > > >> Discussed with: jhb
> > > >> Submitted by: jmd
> > > >> Differential Revision: https://reviews.freebsd.org/D15919
> > > >
> > > > This seems to have broken the gcc build:
> > > > https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/
> > > >
> > > > /workspace/src/lib/msun/ld80/e_powl.c:275:1: error: floating constant
> > > > exceeds range of 'long double' [-Werror=overflow]
> > > > if( y >= LDBL_MAX )
> > > > ^~
> > >
> > > Which architecture? i386 doesn't get build with i386-xtoolchain-gcc
> > > pending
> > > some patches I haven't yet posted for review related to the weirdness we
> > > do
> > > with floating point on i386.
> >
> > This is the -m32 build on amd64. I haven't tested it myself, but Mark
> > Millard noted that the issue might be fixed by a gcc update.
> >
>
> I suspect this. Each build is in a fresh created jail with the latest
> branch of packages from pkg.freebsd.org.
>
> At the beginning of (warning: 56MB file)
> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/7262/consoleText
>
> There is:
>
> New packages to be INSTALLED:
> amd64-xtoolchain-gcc: 0.4_1
> amd64-gcc: 6.4.0_2
> mpfr: 4.0.1
> gmp: 6.1.2
> mpc: 1.1.0_1
> amd64-binutils: 2.30_5,1
>
> Number of packages to be installed: 6
>
> Or is there a newer version of devel/amd64-gcc I am not aware?
I wonder when ci.freebsd.org started using "amd64-gcc: 6.4.0_2".
Looking: https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6665/consoleText
from back on 2018-Jul-26. This suggests being based on
-r475319 (2018-Jul-25) for devel/powerpc-gcc (the master
port).
Looks like -r475290 (the float.h removal) is the first version
with PORT_REVISION being 2, as are all later versions at
this point. Technically -r476273 (2018-Aug-2) removed a typo from
-r475290 but at the time the typo seemed to not make an operational
difference. Still, ci.freebsd.org seems to not be
using the version with the typo fixed.
Looks like system head being built was -r338831. (I'm only at
-r338675 so far.)
I've started a buildworld buildkernel based -on head -r3338675
and based on master port:
# svnlite diff /usr/ports/devel/powerpc64-gcc/ | more
Index: /usr/ports/devel/powerpc64-gcc/Makefile
===
--- /usr/ports/devel/powerpc64-gcc/Makefile (revision 480180)
+++ /usr/ports/devel/powerpc64-gcc/Makefile (working copy)
@@ -16,7 +16,8 @@
LIB_DEPENDS= libgmp.so:math/gmp \
libmpfr.so:math/mpfr \
libmpc.so:math/mpc
-BUILD_DEPENDS= ${BU_PREFIX}-as:devel/${PKGNAMEPREFIX}binutils
+BUILD_DEPENDS= ${BU_PREFIX}-as:devel/${PKGNAMEPREFIX}binutils \
+ objdump:devel/binutils
RUN_DEPENDS= ${BU_PREFIX}-as:devel/${PKGNAMEPREFIX}binutils
USES= gmake iconv libtool tar:xz makeinfo compiler
which does not have -r478209 involved ( un-breaking
devel/aarch64-none-elf-gcc ).
# svnlite diff /usr/ports/devel/amd64-gcc/ | more
#
So no differences there (relative to -r480180).
(The objdump is from having built systems based on
WITHOUT_BINUTILS and WITHOUT_BINUTILS_BOOTSTRAP at times
but some devel/*-gcc builds trying to use objdump in the
configuration part of gcc's build.)
My past builds using at or after -r475290 for various system
head revisions have completed without being stopped by an
error but it has been a while. I will see for this one, but
it is only into building lib32 so far.
(Note: My port builds are via devel/poudriere-devel tied to
my /usr/ports/ and to my
/usr/obj/DESTDIRs/clang-amd64-installworld-poud/ that is installed
from the same build that I install and boot from, just with
distrib-dirs distribution DB_FROM_SRC=1 also
Re: svn commit: r336299 - in head: include lib/msun lib/msun/ld128 lib/msun/ld80 lib/msun/man lib/msun/src
On 9/20/18 2:43 PM, Li-Wen Hsu wrote:
> On Thu, Sep 20, 2018 at 10:06 PM Mark Johnston wrote:
>>
>> On Thu, Sep 20, 2018 at 09:39:24AM -0700, John Baldwin wrote:
>>> On 9/20/18 8:54 AM, Mark Johnston wrote:
On Sun, Jul 15, 2018 at 12:23:11AM +, Matt Macy wrote:
> Author: mmacy
> Date: Sun Jul 15 00:23:10 2018
> New Revision: 336299
> URL: https://svnweb.freebsd.org/changeset/base/336299
>
> Log:
> msun: add ld80/ld128 powl, cpow, cpowf, cpowl from openbsd
>
> This corresponds to the latest status (hasn't changed in 9+
> years) from openbsd of ld80/ld128 powl, and source cpowf, cpow,
> cpowl (the complex power functions for float complex, double
> complex, and long double complex) which are required for C99
> compliance and were missing from FreeBSD. Also required for
> some numerical codes using complex numbered Hamiltonians.
>
> Thanks to jhb for tracking down the issue with making
> weak_reference compile on powerpc.
>
> When asked to review, bde said "I don't like it" - but
> provided no actionable feedback or superior implementations.
>
> Discussed with: jhb
> Submitted by: jmd
> Differential Revision: https://reviews.freebsd.org/D15919
This seems to have broken the gcc build:
https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/
/workspace/src/lib/msun/ld80/e_powl.c:275:1: error: floating constant
exceeds range of 'long double' [-Werror=overflow]
if( y >= LDBL_MAX )
^~
>>>
>>> Which architecture? i386 doesn't get build with i386-xtoolchain-gcc pending
>>> some patches I haven't yet posted for review related to the weirdness we do
>>> with floating point on i386.
>>
>> This is the -m32 build on amd64. I haven't tested it myself, but Mark
>> Millard noted that the issue might be fixed by a gcc update.
>>
>
> I suspect this. Each build is in a fresh created jail with the latest
> branch of packages from pkg.freebsd.org.
>
> At the beginning of (warning: 56MB file)
> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/7262/consoleText
>
> There is:
>
> New packages to be INSTALLED:
> amd64-xtoolchain-gcc: 0.4_1
> amd64-gcc: 6.4.0_2
> mpfr: 4.0.1
> gmp: 6.1.2
> mpc: 1.1.0_1
> amd64-binutils: 2.30_5,1
>
> Number of packages to be installed: 6
>
> Or is there a newer version of devel/amd64-gcc I am not aware?
That has the change Mark Millard is thinking of:
https://svnweb.freebsd.org/ports?view=revision=475290
However, I suspect this is due to a different issue. I still have some
patches that I need to get an i386 world to build with external GCC that
I'm not sure of and haven't posted for review yet. I bet these also matter
for the -m32 build:
Index: lib/libc/tests/stdio/printfloat_test.c
===
--- lib/libc/tests/stdio/printfloat_test.c (revision 338373)
+++ lib/libc/tests/stdio/printfloat_test.c (working copy)
@@ -315,7 +315,7 @@
testfmt("0x1p-1074", "%a", 0x1p-1074);
testfmt("0x1.2345p-1024", "%a", 0x1.2345p-1024);
-#if (LDBL_MANT_DIG == 64)
+#if (LDBL_MANT_DIG == 64) && !defined(__i386__)
testfmt("0x1.921fb54442d18468p+1", "%La", 0x3.243f6a8885a308dp0L);
testfmt("0x1p-16445", "%La", 0x1p-16445L);
testfmt("0x1.30ecap-16381", "%La", 0x9.8765p-16384L);
Index: sys/x86/include/float.h
===
--- sys/x86/include/float.h (revision 338373)
+++ sys/x86/include/float.h (working copy)
@@ -86,10 +86,18 @@
#define LDBL_EPSILON 1.0842021724855044340E-19L
#define LDBL_DIG 18
#define LDBL_MIN_EXP (-16381)
+#if defined(__i386__)
+#define LDBL_MIN 3.3621031431120935e-4932L
+#else
#define LDBL_MIN 3.3621031431120935063E-4932L
+#endif
#define LDBL_MIN_10_EXP(-4931)
#define LDBL_MAX_EXP 16384
+#if defined(__i386__)
+#defineLDBL_MAX1.1897314953572316e+4932L
+#else
#define LDBL_MAX 1.1897314953572317650E+4932L
+#endif
#define LDBL_MAX_10_EXP4932
#if __ISO_C_VISIBLE >= 2011
#defineLDBL_TRUE_MIN 3.6451995318824746025E-4951L
--
John Baldwin
___
svn-src-head@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/svn-src-head
To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336299 - in head: include lib/msun lib/msun/ld128 lib/msun/ld80 lib/msun/man lib/msun/src
On Thu, Sep 20, 2018 at 10:06 PM Mark Johnston wrote: > > On Thu, Sep 20, 2018 at 09:39:24AM -0700, John Baldwin wrote: > > On 9/20/18 8:54 AM, Mark Johnston wrote: > > > On Sun, Jul 15, 2018 at 12:23:11AM +, Matt Macy wrote: > > >> Author: mmacy > > >> Date: Sun Jul 15 00:23:10 2018 > > >> New Revision: 336299 > > >> URL: https://svnweb.freebsd.org/changeset/base/336299 > > >> > > >> Log: > > >> msun: add ld80/ld128 powl, cpow, cpowf, cpowl from openbsd > > >> > > >> This corresponds to the latest status (hasn't changed in 9+ > > >> years) from openbsd of ld80/ld128 powl, and source cpowf, cpow, > > >> cpowl (the complex power functions for float complex, double > > >> complex, and long double complex) which are required for C99 > > >> compliance and were missing from FreeBSD. Also required for > > >> some numerical codes using complex numbered Hamiltonians. > > >> > > >> Thanks to jhb for tracking down the issue with making > > >> weak_reference compile on powerpc. > > >> > > >> When asked to review, bde said "I don't like it" - but > > >> provided no actionable feedback or superior implementations. > > >> > > >> Discussed with: jhb > > >> Submitted by: jmd > > >> Differential Revision: https://reviews.freebsd.org/D15919 > > > > > > This seems to have broken the gcc build: > > > https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/ > > > > > > /workspace/src/lib/msun/ld80/e_powl.c:275:1: error: floating constant > > > exceeds range of 'long double' [-Werror=overflow] > > > if( y >= LDBL_MAX ) > > > ^~ > > > > Which architecture? i386 doesn't get build with i386-xtoolchain-gcc pending > > some patches I haven't yet posted for review related to the weirdness we do > > with floating point on i386. > > This is the -m32 build on amd64. I haven't tested it myself, but Mark > Millard noted that the issue might be fixed by a gcc update. > I suspect this. Each build is in a fresh created jail with the latest branch of packages from pkg.freebsd.org. At the beginning of (warning: 56MB file) https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/7262/consoleText There is: New packages to be INSTALLED: amd64-xtoolchain-gcc: 0.4_1 amd64-gcc: 6.4.0_2 mpfr: 4.0.1 gmp: 6.1.2 mpc: 1.1.0_1 amd64-binutils: 2.30_5,1 Number of packages to be installed: 6 Or is there a newer version of devel/amd64-gcc I am not aware? -- Li-Wen Hsu https://lwhsu.org ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336299 - in head: include lib/msun lib/msun/ld128 lib/msun/ld80 lib/msun/man lib/msun/src
On Thu, Sep 20, 2018 at 09:39:24AM -0700, John Baldwin wrote: > On 9/20/18 8:54 AM, Mark Johnston wrote: > > On Sun, Jul 15, 2018 at 12:23:11AM +, Matt Macy wrote: > >> Author: mmacy > >> Date: Sun Jul 15 00:23:10 2018 > >> New Revision: 336299 > >> URL: https://svnweb.freebsd.org/changeset/base/336299 > >> > >> Log: > >> msun: add ld80/ld128 powl, cpow, cpowf, cpowl from openbsd > >> > >> This corresponds to the latest status (hasn't changed in 9+ > >> years) from openbsd of ld80/ld128 powl, and source cpowf, cpow, > >> cpowl (the complex power functions for float complex, double > >> complex, and long double complex) which are required for C99 > >> compliance and were missing from FreeBSD. Also required for > >> some numerical codes using complex numbered Hamiltonians. > >> > >> Thanks to jhb for tracking down the issue with making > >> weak_reference compile on powerpc. > >> > >> When asked to review, bde said "I don't like it" - but > >> provided no actionable feedback or superior implementations. > >> > >> Discussed with: jhb > >> Submitted by: jmd > >> Differential Revision: https://reviews.freebsd.org/D15919 > > > > This seems to have broken the gcc build: > > https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/ > > > > /workspace/src/lib/msun/ld80/e_powl.c:275:1: error: floating constant > > exceeds range of 'long double' [-Werror=overflow] > > if( y >= LDBL_MAX ) > > ^~ > > Which architecture? i386 doesn't get build with i386-xtoolchain-gcc pending > some patches I haven't yet posted for review related to the weirdness we do > with floating point on i386. This is the -m32 build on amd64. I haven't tested it myself, but Mark Millard noted that the issue might be fixed by a gcc update. ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336299 - in head: include lib/msun lib/msun/ld128 lib/msun/ld80 lib/msun/man lib/msun/src
On Thu, 20 Sep 2018, John Baldwin wrote: On 9/20/18 8:54 AM, Mark Johnston wrote: On Sun, Jul 15, 2018 at 12:23:11AM +, Matt Macy wrote: Author: mmacy Date: Sun Jul 15 00:23:10 2018 New Revision: 336299 URL: https://svnweb.freebsd.org/changeset/base/336299 Log: msun: add ld80/ld128 powl, cpow, cpowf, cpowl from openbsd This corresponds to the latest status (hasn't changed in 9+ years) from openbsd of ld80/ld128 powl, and source cpowf, cpow, cpowl (the complex power functions for float complex, double complex, and long double complex) which are required for C99 compliance and were missing from FreeBSD. Also required for some numerical codes using complex numbered Hamiltonians. Thanks to jhb for tracking down the issue with making weak_reference compile on powerpc. When asked to review, bde said "I don't like it" - but provided no actionable feedback or superior implementations. Discussed with: jhb Submitted by: jmd Differential Revision: https://reviews.freebsd.org/D15919 This seems to have broken the gcc build: https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/ /workspace/src/lib/msun/ld80/e_powl.c:275:1: error: floating constant exceeds range of 'long double' [-Werror=overflow] if( y >= LDBL_MAX ) ^~ Which architecture? i386 doesn't get build with i386-xtoolchain-gcc pending some patches I haven't yet posted for review related to the weirdness we do with floating point on i386. It can only be i386, since only amd64 and i386 use this file (or anything in ld80)0, and amd64 doesn't have the problem. The powl() is completely broken on i386 (even worse than the previous imprecise misimplementation). It depends on bugs in clang to work. i386 still uses a default rounding precision of 53 bits. gcc supports this and rounds long double constants to 53 bits. This breaks most of the constants in this file, since they are only correct when rounded to 64 bits. This loses even more than 11 bits of accuracy since the bits are lost at a more critical stage than in the imprecise version. clang is too incompatible to do correct default rounding. gcc's technically correct rounding is inconvenient, but all other files in ld80 are carefully written to use either 53-bit (double) constants or spell the long double constants in binary (best done using the LD80C() macro) so that they work with either gcc or clang. 53-bit constants are also faster. Not all other files in ld80 arei careful to switch the rounding precision at runtime (best done using the ENTERI() macro), so callers must do the switch in general. Even for the functions that switch internally, this gives a null internal switch which is faster, and the external switch should be around multiple FP operations both for efficiency and so that the external operations are actually in 64-bit precision too. LDBL_MAX has always been broken on i386. Before 2002, it was DBL_MAX. Then its precision was correct (53 bits) but its exponent range was wrong. Now its precision is wrong (64 bits) but its exponent range is correct. Thus it is unusable in libm (except in ld128 where there are no i386 parts). gcc detects its brokenness, and this already caused problems in catrigl.c. I tested catrigl.c a lot, but apparently I without enoygh warning flags, so catrigl.c was committed before this was fixed. LDBL_MAX is not ifdefed in x86/float.h. If it had the correctly rounded value, then clang would detect this problem too. Correct rounding for clang would require it to be a hex constant, since it is to hard to represent binary precision 53 in decimal precision when the compiler will round to binary precision 64. The correctly rounded LDBL_MAX would be inconsistent with incorrectly rounded other constants. clang has the following partly related bugs near x86/float.h: - the declarations of float_t and double_t (these are in math.h) are not ifdefed, but clang does the dubious optimization of using SSE[2] for floats and [doubles] if -march is used at compile time to indicate that SSE[2] is usable at runtime. float_t and double_t don't vary, so are only correct when the i387 is used for all precisions. The misdeclarations as long double are only efficiency bugs. Optimal code should use float_t and double_t a lot, but this guarantees that the dubious optimizations are negative when float_t and double_t are wider than necessary (negative optimizations then result from extra conversions). - the predefined value of FLT_EVAL_METHOD is wrong. This varies with the SSE optimization, but is always wrong since clang doesn't understand that the default long double precision is only 53. Only a value of -1 (indeterminate) means that the evaluation method is very context-dependent. Since indeterminate can be almost anything, it may even allow incorrect rounding at compile time, and it certainly allows the differences given by the SSE optimizations. Hopefully you fixed all these problems in gcc
Re: svn commit: r336299 - in head: include lib/msun lib/msun/ld128 lib/msun/ld80 lib/msun/man lib/msun/src
John Baldwin jhb at FreeBSD.org wrote on Thu Sep 20 16:39:27 UTC 2018 : > On 9/20/18 8:54 AM, Mark Johnston wrote: > > On Sun, Jul 15, 2018 at 12:23:11AM +, Matt Macy wrote: > >> Author: mmacy > >> Date: Sun Jul 15 00:23:10 2018 > >> New Revision: 336299 > >> URL: https://svnweb.freebsd.org/changeset/base/336299 > >> > >> Log: > >> msun: add ld80/ld128 powl, cpow, cpowf, cpowl from openbsd > >> > >> This corresponds to the latest status (hasn't changed in 9+ > >> years) from openbsd of ld80/ld128 powl, and source cpowf, cpow, > >> cpowl (the complex power functions for float complex, double > >> complex, and long double complex) which are required for C99 > >> compliance and were missing from FreeBSD. Also required for > >> some numerical codes using complex numbered Hamiltonians. > >> > >> Thanks to jhb for tracking down the issue with making > >> weak_reference compile on powerpc. > >> > >> When asked to review, bde said "I don't like it" - but > >> provided no actionable feedback or superior implementations. > >> > >> Discussed with: jhb > >> Submitted by: jmd > >> Differential Revision: https://reviews.freebsd.org/D15919 > > > > This seems to have broken the gcc build: > > https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/ > > > > /workspace/src/lib/msun/ld80/e_powl.c:275:1: error: floating constant > > exceeds range of 'long double' [-Werror=overflow] > > if( y >= LDBL_MAX ) > > ^~ > > Which architecture? i386 doesn't get build with i386-xtoolchain-gcc pending > some patches I haven't yet posted for review related to the weirdness we do > with floating point on i386. Looking at: https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/7260/consoleText (the most recent completed build attempt when I looked) It is the same as the 2018-Jun-28 list report about lib32 failing to build in the amd64 build (that lead to your ports' head -r475290): --- lib/msun__L --- --- e_powl.o --- /usr/local/bin/x86_64-unknown-freebsd11.1-gcc -DCOMPAT_32BIT -march=i686 -mmmx -msse -msse2 -m32 -L/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 --sysroot=/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp -B/usr/local/x86_64-unknown-freebsd11.1/bin/ -B/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/lib32 -O2 -pipe -I/workspace/src/lib/msun/x86 -I/workspace/src/lib/msun/ld80 -I/workspace/src/lib/msun/i387 -I/workspace/src/lib/msun/src -I/workspace/src/lib/libc/include -I/workspace/src/lib/libc/i386 -g -MD -MF.depend.e_powl.o -MTe_powl.o -std=gnu99 -fstack-protector-strong -Wsystem-headers -Werror -Wno-pointer-sign -Wno-error=address -Wno-error=array-bounds -Wno-error=attributes -Wno-error=bool-compare -Wno-error=cast-align -Wno-error=clobbered -Wno-error=enum-compare -Wno-error=extra -Wno-error=inline -Wno-error=logical-not-parentheses -Wno-error=strict-aliasing -Wno-error=uninitialized -Wno-error=unused-but-set-variable -Wno-error=unused-func tion -Wno-error=unused-value -Wno-error=misleading-indentation -Wno-error=nonnull-compare -Wno-error=shift-negative-value -Wno-error=tautological-compare -Wno-error=unused-const-variable -Wno-unknown-pragmas -c /workspace/src/lib/msun/ld80/e_powl.c -o e_powl.o --- secure/lib/libcrypto__L --- . . . --- lib/msun__L --- /workspace/src/lib/msun/ld80/e_powl.c: In function 'powl': /workspace/src/lib/msun/ld80/e_powl.c:275:1: error: floating constant exceeds range of 'long double' [-Werror=overflow] if( y >= LDBL_MAX ) ^~ /workspace/src/lib/msun/ld80/e_powl.c:286:1: error: floating constant exceeds range of 'long double' [-Werror=overflow] if( y <= -LDBL_MAX ) ^~ /workspace/src/lib/msun/ld80/e_powl.c:297:1: error: floating constant exceeds range of 'long double' [-Werror=overflow] if( x >= LDBL_MAX ) ^~ /workspace/src/lib/msun/ld80/e_powl.c:321:1: error: floating constant exceeds range of 'long double' [-Werror=overflow] if( x <= -LDBL_MAX ) ^~ /workspace/src/lib/msun/ld80/e_powl.c: In function 'powil': /workspace/src/lib/msun/ld80/e_powl.c:577:3: error: floating constant exceeds range of 'long double' [-Werror=overflow] return( LDBL_MAX ); ^~ Your ports' head -r475290 does avoid the problem and allow such builds but ci.freebsd.org has not updated to some version with the changes as I understand. === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336299 - in head: include lib/msun lib/msun/ld128 lib/msun/ld80 lib/msun/man lib/msun/src
On 9/20/18 8:54 AM, Mark Johnston wrote: > On Sun, Jul 15, 2018 at 12:23:11AM +, Matt Macy wrote: >> Author: mmacy >> Date: Sun Jul 15 00:23:10 2018 >> New Revision: 336299 >> URL: https://svnweb.freebsd.org/changeset/base/336299 >> >> Log: >> msun: add ld80/ld128 powl, cpow, cpowf, cpowl from openbsd >> >> This corresponds to the latest status (hasn't changed in 9+ >> years) from openbsd of ld80/ld128 powl, and source cpowf, cpow, >> cpowl (the complex power functions for float complex, double >> complex, and long double complex) which are required for C99 >> compliance and were missing from FreeBSD. Also required for >> some numerical codes using complex numbered Hamiltonians. >> >> Thanks to jhb for tracking down the issue with making >> weak_reference compile on powerpc. >> >> When asked to review, bde said "I don't like it" - but >> provided no actionable feedback or superior implementations. >> >> Discussed with: jhb >> Submitted by: jmd >> Differential Revision: https://reviews.freebsd.org/D15919 > > This seems to have broken the gcc build: > https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/ > > /workspace/src/lib/msun/ld80/e_powl.c:275:1: error: floating constant exceeds > range of 'long double' [-Werror=overflow] > if( y >= LDBL_MAX ) > ^~ Which architecture? i386 doesn't get build with i386-xtoolchain-gcc pending some patches I haven't yet posted for review related to the weirdness we do with floating point on i386. -- John Baldwin ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336299 - in head: include lib/msun lib/msun/ld128 lib/msun/ld80 lib/msun/man lib/msun/src
Mark Johnston markj at freebsd.org wrote on Thu Sep 20 15:54:08 UTC 2018 : > On Sun, Jul 15, 2018 at 12:23:11AM +, Matt Macy wrote: > > Author: mmacy > > Date: Sun Jul 15 00:23:10 2018 > > New Revision: 336299 > > URL: https://svnweb.freebsd.org/changeset/base/336299 > > > > Log: > > msun: add ld80/ld128 powl, cpow, cpowf, cpowl from openbsd > > > > This corresponds to the latest status (hasn't changed in 9+ > > years) from openbsd of ld80/ld128 powl, and source cpowf, cpow, > > cpowl (the complex power functions for float complex, double > > complex, and long double complex) which are required for C99 > > compliance and were missing from FreeBSD. Also required for > > some numerical codes using complex numbered Hamiltonians. > > > > Thanks to jhb for tracking down the issue with making > > weak_reference compile on powerpc. > > > > When asked to review, bde said "I don't like it" - but > > provided no actionable feedback or superior implementations. > > > > Discussed with: jhb > > Submitted by: jmd > > Differential Revision: https://reviews.freebsd.org/D15919 > > This seems to have broken the gcc build: > https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/ > > /workspace/src/lib/msun/ld80/e_powl.c:275:1: error: floating constant exceeds > range of 'long double' [-Werror=overflow] > if( y >= LDBL_MAX ) Building with a more recent vintage of the devel/amd64-gcc port does not do this (devel/powerpc64-=gcc master port). I've built locally multiple-times since the below that has by John Baldwin: QUOTE Revision 475290 - Directory Listing Modified Wed Jul 25 00:50:53 2018 UTC (8 weeks, 1 day ago) by jhb Drop builtin float.h for amd64-gcc. GCC's builtin header is not compatible with sys/x86/include/float.h. Drop the builtin header for now. If at some point GCC's notion of floating point constants for i386 can converge with sys/x86/include/float.h this can be restored. Reviewed by:bapt Differential Revision: https://reviews.freebsd.org/D16073 END QUOTE Until ci.freebsd.org updates to be based on a version that includes the change the issue will exists there. There was activity on svn-src-head and freebsd-current starting back on 2018-Jun-28 that reported the issue and lead to the change, with subject: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
Re: svn commit: r336299 - in head: include lib/msun lib/msun/ld128 lib/msun/ld80 lib/msun/man lib/msun/src
On Sun, Jul 15, 2018 at 12:23:11AM +, Matt Macy wrote: > Author: mmacy > Date: Sun Jul 15 00:23:10 2018 > New Revision: 336299 > URL: https://svnweb.freebsd.org/changeset/base/336299 > > Log: > msun: add ld80/ld128 powl, cpow, cpowf, cpowl from openbsd > > This corresponds to the latest status (hasn't changed in 9+ > years) from openbsd of ld80/ld128 powl, and source cpowf, cpow, > cpowl (the complex power functions for float complex, double > complex, and long double complex) which are required for C99 > compliance and were missing from FreeBSD. Also required for > some numerical codes using complex numbered Hamiltonians. > > Thanks to jhb for tracking down the issue with making > weak_reference compile on powerpc. > > When asked to review, bde said "I don't like it" - but > provided no actionable feedback or superior implementations. > > Discussed with: jhb > Submitted by: jmd > Differential Revision: https://reviews.freebsd.org/D15919 This seems to have broken the gcc build: https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/ /workspace/src/lib/msun/ld80/e_powl.c:275:1: error: floating constant exceeds range of 'long double' [-Werror=overflow] if( y >= LDBL_MAX ) ^~ ___ svn-src-head@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/svn-src-head To unsubscribe, send any mail to "svn-src-head-unsubscr...@freebsd.org"
svn commit: r336299 - in head: include lib/msun lib/msun/ld128 lib/msun/ld80 lib/msun/man lib/msun/src
Author: mmacy
Date: Sun Jul 15 00:23:10 2018
New Revision: 336299
URL: https://svnweb.freebsd.org/changeset/base/336299
Log:
msun: add ld80/ld128 powl, cpow, cpowf, cpowl from openbsd
This corresponds to the latest status (hasn't changed in 9+
years) from openbsd of ld80/ld128 powl, and source cpowf, cpow,
cpowl (the complex power functions for float complex, double
complex, and long double complex) which are required for C99
compliance and were missing from FreeBSD. Also required for
some numerical codes using complex numbered Hamiltonians.
Thanks to jhb for tracking down the issue with making
weak_reference compile on powerpc.
When asked to review, bde said "I don't like it" - but
provided no actionable feedback or superior implementations.
Discussed with: jhb
Submitted by: jmd
Differential Revision: https://reviews.freebsd.org/D15919
Added:
head/lib/msun/ld128/e_powl.c (contents, props changed)
head/lib/msun/ld80/e_powl.c (contents, props changed)
head/lib/msun/man/cpow.3 (contents, props changed)
head/lib/msun/src/polevll.c (contents, props changed)
head/lib/msun/src/s_cpow.c (contents, props changed)
head/lib/msun/src/s_cpowf.c (contents, props changed)
head/lib/msun/src/s_cpowl.c (contents, props changed)
Modified:
head/include/complex.h
head/lib/msun/Makefile
head/lib/msun/Symbol.map
head/lib/msun/man/complex.3
head/lib/msun/src/e_pow.c
head/lib/msun/src/imprecise.c
head/lib/msun/src/math_private.h
Modified: head/include/complex.h
==
--- head/include/complex.h Sat Jul 14 23:53:51 2018(r336298)
+++ head/include/complex.h Sun Jul 15 00:23:10 2018(r336299)
@@ -109,6 +109,10 @@ double complex conj(double complex) __pure2;
float complex conjf(float complex) __pure2;
long double complex
conjl(long double complex) __pure2;
+float complex cpowf(float complex, float complex);
+double complex cpow(double complex, double complex);
+long double complex
+ cpowl(long double complex, long double complex);
float complex cprojf(float complex) __pure2;
double complex cproj(double complex) __pure2;
long double complex
Modified: head/lib/msun/Makefile
==
--- head/lib/msun/Makefile Sat Jul 14 23:53:51 2018(r336298)
+++ head/lib/msun/Makefile Sun Jul 15 00:23:10 2018(r336299)
@@ -56,6 +56,7 @@ COMMON_SRCS= b_exp.c b_log.c b_tgamma.c \
imprecise.c \
k_cos.c k_cosf.c k_exp.c k_expf.c k_rem_pio2.c k_sin.c k_sinf.c \
k_tan.c k_tanf.c \
+ polevll.c \
s_asinh.c s_asinhf.c s_atan.c s_atanf.c s_carg.c s_cargf.c s_cargl.c \
s_cbrt.c s_cbrtf.c s_ceil.c s_ceilf.c s_clog.c s_clogf.c \
s_copysign.c s_copysignf.c s_cos.c s_cosf.c \
@@ -98,7 +99,7 @@ COMMON_SRCS+= s_copysignl.c s_fabsl.c s_llrintl.c s_lr
COMMON_SRCS+= catrigl.c \
e_acoshl.c e_acosl.c e_asinl.c e_atan2l.c e_atanhl.c \
e_coshl.c e_fmodl.c e_hypotl.c \
- e_lgammal.c e_lgammal_r.c \
+ e_lgammal.c e_lgammal_r.c e_powl.c \
e_remainderl.c e_sinhl.c e_sqrtl.c \
invtrig.c k_cosl.c k_sinl.c k_tanl.c \
s_asinhl.c s_atanl.c s_cbrtl.c s_ceill.c \
@@ -115,6 +116,7 @@ COMMON_SRCS+= catrig.c catrigf.c \
s_ccosh.c s_ccoshf.c s_cexp.c s_cexpf.c \
s_cimag.c s_cimagf.c s_cimagl.c \
s_conj.c s_conjf.c s_conjl.c \
+ s_cpow.c s_cpowf.c s_cpowl.c \
s_cproj.c s_cprojf.c s_creal.c s_crealf.c s_creall.c \
s_csinh.c s_csinhf.c s_ctanh.c s_ctanhf.c
@@ -134,7 +136,7 @@ INCS+= fenv.h math.h
MAN= acos.3 acosh.3 asin.3 asinh.3 atan.3 atan2.3 atanh.3 \
ceil.3 cacos.3 ccos.3 ccosh.3 cexp.3 \
- cimag.3 clog.3 copysign.3 cos.3 cosh.3 csqrt.3 erf.3 \
+ cimag.3 clog.3 copysign.3 cos.3 cosh.3 cpow.3 csqrt.3 erf.3 \
exp.3 fabs.3 fdim.3 \
feclearexcept.3 feenableexcept.3 fegetenv.3 \
fegetround.3 fenv.3 floor.3 \
@@ -172,6 +174,7 @@ MLINKS+=clog.3 clogf.3 clog.3 clogl.3
MLINKS+=copysign.3 copysignf.3 copysign.3 copysignl.3
MLINKS+=cos.3 cosf.3 cos.3 cosl.3
MLINKS+=cosh.3 coshf.3 cosh.3 coshl.3
+MLINKS+=cpow.3 cpowf.3 cpow.3 cpowl.3
MLINKS+=csqrt.3 csqrtf.3 csqrt.3 csqrtl.3
MLINKS+=erf.3 erfc.3 erf.3 erff.3 erf.3 erfcf.3 erf.3 erfl.3 erf.3 erfcl.3
MLINKS+=exp.3 expm1.3 exp.3 expm1f.3 exp.3 expm1l.3 exp.3 pow.3 exp.3 powf.3 \
Modified: head/lib/msun/Symbol.map
==
--- head/lib/msun/Symbol.mapSat Jul 14 23:53:51 2018(r336298)
+++ head/lib/msun/Symbol.mapSun Jul 15 00:23:10 2018(r336299)
@@ -274,10 +274,10 @@ FBSD_1.3 {
log1pl;
log2l;
logl;
+ powl;
sinhl;
tanhl;
/* Implemented as weak aliases for imprecise versions */
