Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 7/16/18 11:27 PM, Mark Millard wrote:
> On 2018-Jul-1, at 6:34 AM, Mark Millard wrote:
>
>> My brain finally engaged for showing exactly what files are included
>> for the gcc builds: the .meta files include that information explicitly
>> (along with other files that are opened during the operation).
>>
>> amd64 is as I reported, just one header file from gcc: float.h .
>>
>> powerpc64 builds Lex/Lexer.cpp without defining __ALTIVEC__ and so
>> is not including . Building without __ALTIVEC__ might
>> be an error itself but would be a workaround for the altivec.h
>> file name aliasing vs. search-path problem.
>>
>> . . .
>
> Going in a different direction, what of the unchanged Makefile.inc1
> code block:
>
> .if ${WANT_COMPILER_TYPE} == gcc || \
> (defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc)
> # GCC requires -isystem and -L when using a cross-compiler. --sysroot
> # won't set header path and -L is used to ensure the base library path
> # is added before the port PREFIX library path.
> CD2CFLAGS+= -isystem ${XDDESTDIR}/usr/include -L${XDDESTDIR}/usr/lib
> # GCC requires -B to find /usr/lib/crti.o when using a cross-compiler
> # combined with --sysroot.
> CD2CFLAGS+= -B${XDDESTDIR}/usr/lib
> # Force using libc++ for external GCC.
> .if defined(X_COMPILER_TYPE) && \
> ${X_COMPILER_TYPE} == gcc && ${X_COMPILER_VERSION} >= 40800
> CD2CXXFLAGS+= -isystem ${XDDESTDIR}/usr/include/c++/v1 -std=c++11 \
> -nostdinc++
> .endif
> .endif
>
> Why is that pair of -isystem uses that gives the old search order
> okay? Or was the block just missed? (Similarly for other options
> listed above.)
Just missed. They should probably also be removed.
> Note: Locally I've reverted the -r335782 changes in order for my use
> of devel/*-gcc as cross compilers to work where they used to (hopefully:
> still building), restoring the historical search order for the
> directories for now.
I finally got the approval 2 days ago to remove float.h from amd64-gcc so
you shouldn't need this reverted anymore once the OFED thing is
straightened out.
--
John Baldwin
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 2018-Jul-1, at 6:34 AM, Mark Millard wrote:
> My brain finally engaged for showing exactly what files are included
> for the gcc builds: the .meta files include that information explicitly
> (along with other files that are opened during the operation).
>
> amd64 is as I reported, just one header file from gcc: float.h .
>
> powerpc64 builds Lex/Lexer.cpp without defining __ALTIVEC__ and so
> is not including . Building without __ALTIVEC__ might
> be an error itself but would be a workaround for the altivec.h
> file name aliasing vs. search-path problem.
>
> . . .
Going in a different direction, what of the unchanged Makefile.inc1
code block:
.if ${WANT_COMPILER_TYPE} == gcc || \
(defined(X_COMPILER_TYPE) && ${X_COMPILER_TYPE} == gcc)
# GCC requires -isystem and -L when using a cross-compiler. --sysroot
# won't set header path and -L is used to ensure the base library path
# is added before the port PREFIX library path.
CD2CFLAGS+= -isystem ${XDDESTDIR}/usr/include -L${XDDESTDIR}/usr/lib
# GCC requires -B to find /usr/lib/crti.o when using a cross-compiler
# combined with --sysroot.
CD2CFLAGS+= -B${XDDESTDIR}/usr/lib
# Force using libc++ for external GCC.
.if defined(X_COMPILER_TYPE) && \
${X_COMPILER_TYPE} == gcc && ${X_COMPILER_VERSION} >= 40800
CD2CXXFLAGS+= -isystem ${XDDESTDIR}/usr/include/c++/v1 -std=c++11 \
-nostdinc++
.endif
.endif
Why is that pair of -isystem uses that gives the old search order
okay? Or was the block just missed? (Similarly for other options
listed above.)
Note: Locally I've reverted the -r335782 changes in order for my use
of devel/*-gcc as cross compilers to work where they used to (hopefully:
still building), restoring the historical search order for the
directories for now.
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
My brain finally engaged for showing exactly what files are included for the gcc builds: the .meta files include that information explicitly (along with other files that are opened during the operation). amd64 is as I reported, just one header file from gcc: float.h . powerpc64 builds Lex/Lexer.cpp without defining __ALTIVEC__ and so is not including . Building without __ALTIVEC__ might be an error itself but would be a workaround for the altivec.h file name aliasing vs. search-path problem. The details from the .meta files for the amd64 float.h failure and the powerpc64 altivec.h issue follow. For the -r335782+ amd64 context: E 73559 /bin/sh R 73559 /etc/libmap.conf R 73559 /var/run/ld-elf.so.hints R 73559 /lib/libedit.so.7 R 73559 /lib/libc.so.7 R 73559 /lib/libncursesw.so.8 F 73559 73560 E 73560 /usr/local/bin/x86_64-unknown-freebsd12.0-gcc R 73560 /etc/libmap.conf R 73560 /var/run/ld-elf.so.hints R 73560 /usr/lib/libc++.so.1 R 73560 /lib/libcxxrt.so.1 R 73560 /lib/libm.so.5 R 73560 /lib/libc.so.7 R 73560 /lib/libgcc_s.so.1 F 73560 73561 E 73561 /usr/local/libexec/gcc/x86_64-unknown-freebsd12.0/6.4.0/cc1 R 73561 /etc/libmap.conf R 73561 /var/run/ld-elf.so.hints R 73561 /usr/local/lib/libmpc.so.3 R 73561 /usr/local/lib/libmpfr.so.6 R 73561 /usr/local/lib/libgmp.so.10 R 73561 /lib/libz.so.6 R 73561 /usr/lib/libc++.so.1 R 73561 /lib/libcxxrt.so.1 R 73561 /lib/libm.so.5 R 73561 /lib/libc.so.7 R 73561 /lib/libgcc_s.so.1 R 73561 /dev/urandom R 73561 /usr/src/lib/msun/src/catrigl.c F 73560 73562 E 73562 /usr/local/bin/x86_64-unknown-freebsd12.0-as R 73562 /etc/libmap.conf R 73562 /var/run/ld-elf.so.hints R 73562 /lib/libc.so.7 R 73562 catrigl.o W 73562 catrigl.o R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/cdefs.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/complex.h R 73561 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include/float.h R 73561 /usr/src/lib/msun/ld80/invtrig.h R 73561 /usr/src/lib/libc/include/fpmath.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/endian.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/_types.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/machine/_types.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/x86/_types.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/machine/_limits.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/x86/_limits.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/machine/endian.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/x86/endian.h R 73561 /usr/src/lib/libc/i386/_fpmath.h R 73561 /usr/src/lib/msun/src/math.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/machine/_limits.h R 73561 /usr/src/lib/msun/src/math_private.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/types.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/machine/endian.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/_pthreadtypes.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/_stdint.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/select.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/_sigset.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/_timeval.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/timespec.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/sys/_timespec.h R 73561 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include/machine/endian.h R 73561 /usr/src/lib/msun/src/catrigl.c X 73562 0 0 X 73561 1 0 D 73560 catrigl.o X 73560 1 0 X 73559 1 0 Note that only one one file (float.h) comes from gcc. It would have to not be a file of a related set of files (very independent) for such to be coherent. As for my pre-existing powerpc64 build under -r335782+: It did not include altivec.h at all according to its Lex_Lexer.o.meta file. Apparently __ALTIVEC__ is not defined, as the code for the #include in Lex/Lexer.cpp is: #ifdef __SSE2__ #include #elif __ALTIVEC__ #include #undef bool #endif It did open the 3 files with /gcc/ in the path (2 being headers):
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 2018-Jun-30, at 11:53 AM, John Baldwin wrote: > On 6/30/18 10:19 AM, Mark Millard wrote: > > > On 2018-Jun-30, at 10:04 AM, Mark Millard wrote: > >> On 2018-Jun-30, at 9:29 AM, John Baldwin wrote: >> >>> On 6/30/18 9:17 AM, Mark Millard wrote: On 2018-Jun-30, at 7:51 AM, John Baldwin wrote: > On 6/29/18 2:37 PM, Mark Millard wrote: >> [I expect this is more than just amd64-gcc related but that is all >> that ci.freebsd.org normally builds via a devel/*-gcc .] > > As indicated by my other mail, this is i386 and amd64 specific as it > only matters for float.h on i386 due to the disagreement on > LDBL_MANT_DIG. I was correct about the search order for include files being different before -r335782 vs. -r335782 and later: >>> >>> Yes, but this is kind of a feature, not a bug, and the issue there is that >>> as much as possible we should allow FreeBSD to work with the standard >>> headers >>> that are supposed to be part of the language (and thus provided by the >>> toolchain). Right now we don't ship any of the 'std*.h' headers clang >>> provides for example in our base system clang, though a few months ago I >>> fixed the one place that was using instead of >>> in userland that was breaking the use of the toolchain-provided >>> stdarg.h (both GCC and clang). >>> Might this reversal have other effects even for architectures for which the code does compile via devel/*-gcc ? >>> >>> It depends on the header. This particular failure is due to a quirk of >>> on FreeBSD/i386. I have built other platforms with external >>> GCC just fine. To the extent that we encounter any other issues we >>> should try to make our source more conformant with C and only fall back to >>> axeing the toolchain-provided language headers as a last resort. >> >> It is too bad that the review https://reviews.freebsd.org/D16055 did not >> catch the change in what headers are used by buildworld and buildkernel. >> I'd view such switching of long established header bindings as a >> fairly big deal, possibly even warranting being explicitly proposed and >> debated. >> >> I'm not claiming my opinion on which search order that I have is >> actually relevant. I'm just now nervous about my powerpc64-gcc based >> builds having unexpected differences, for example. [I sometimes explore >> the status of powerpc family builds via more modern toolchains.] >> >> (But lib32 for powerpc64 via modern gcc's is messed up anyway, >> generating code in crtbeginS.o for the wrong ABI: using R30 incorrectly. >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206123 has more about >> that.) > > Looks like my being nervous is justified: there is a conflicting altivec.h > that has nothing to do with C/C++ language standards: > > # ls /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/ > altivec.h htmxlintrin.h ppc-asm.h spe.h > stdarg.hstddef.hstdint.h > varargs.h > float.h iso646.hppu_intrinsics.h > spu2vmx.h stdatomic.h stdfix.h > stdnoreturn.h vec_types.h > htmintrin.h paired.hsi2vmx.h > stdalign.h stdbool.h stdint-gcc.h > tgmath.h > > I've not checked for other name conflicts vs. FreeBSD. I just happen > to recognize altivec.h . There is: > > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/include/machine/altivec.h > > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/lib/clang/6.0.0/include/altivec.h > > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/obj-lib32/tmp/usr/include/machine/altivec.h > > Actually, that is a compiler intrinsincs header similar to the , > etc. headers used for SSE on x86 that are always provided by the compiler. > However, this header is '' not '' so it won't > conflict. > > (On x86, these headers provide the _mm_* functions documented in Intel's > SDM as the official C bindings for vector extensions, and > probably plays a similar role in providing the vendor-specified C > bindings for altivec instructions.) [This is based on a -r335812 build still.] If I have a modern gcc build a system that includes building the system clang, I do not expect it is that simple. There is: /usr/src/contrib/llvm/tools/clang/lib/Lex/Lexer.cpp:#include and altivec.h files around: /usr/lib/clang/6.0.0/include/altivec.h /usr/src/contrib/llvm/tools/clang/lib/Headers/altivec.h /usr/src/contrib/gcc/config/rs6000/altivec.h /usr/src/sys/powerpc/include/altivec.h /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/altivec.h
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 6/30/18 10:19 AM, Mark Millard wrote: > > > On 2018-Jun-30, at 10:04 AM, Mark Millard wrote: > >> On 2018-Jun-30, at 9:29 AM, John Baldwin wrote: >> >>> On 6/30/18 9:17 AM, Mark Millard wrote: On 2018-Jun-30, at 7:51 AM, John Baldwin wrote: > On 6/29/18 2:37 PM, Mark Millard wrote: >> [I expect this is more than just amd64-gcc related but that is all >> that ci.freebsd.org normally builds via a devel/*-gcc .] > > As indicated by my other mail, this is i386 and amd64 specific as it > only matters for float.h on i386 due to the disagreement on > LDBL_MANT_DIG. I was correct about the search order for include files being different before -r335782 vs. -r335782 and later: >>> >>> Yes, but this is kind of a feature, not a bug, and the issue there is that >>> as much as possible we should allow FreeBSD to work with the standard >>> headers >>> that are supposed to be part of the language (and thus provided by the >>> toolchain). Right now we don't ship any of the 'std*.h' headers clang >>> provides for example in our base system clang, though a few months ago I >>> fixed the one place that was using instead of >>> in userland that was breaking the use of the toolchain-provided >>> stdarg.h (both GCC and clang). >>> Might this reversal have other effects even for architectures for which the code does compile via devel/*-gcc ? >>> >>> It depends on the header. This particular failure is due to a quirk of >>> on FreeBSD/i386. I have built other platforms with external >>> GCC just fine. To the extent that we encounter any other issues we >>> should try to make our source more conformant with C and only fall back to >>> axeing the toolchain-provided language headers as a last resort. >> >> It is too bad that the review https://reviews.freebsd.org/D16055 did not >> catch the change in what headers are used by buildworld and buildkernel. >> I'd view such switching of long established header bindings as a >> fairly big deal, possibly even warranting being explicitly proposed and >> debated. >> >> I'm not claiming my opinion on which search order that I have is >> actually relevant. I'm just now nervous about my powerpc64-gcc based >> builds having unexpected differences, for example. [I sometimes explore >> the status of powerpc family builds via more modern toolchains.] >> >> (But lib32 for powerpc64 via modern gcc's is messed up anyway, >> generating code in crtbeginS.o for the wrong ABI: using R30 incorrectly. >> https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206123 has more about >> that.) > > Looks like my being nervous is justified: there is a conflicting altivec.h > that has nothing to do with C/C++ language standards: > > # ls /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/ > altivec.h htmxlintrin.h ppc-asm.h spe.h > stdarg.hstddef.hstdint.h > varargs.h > float.h iso646.hppu_intrinsics.h > spu2vmx.h stdatomic.h stdfix.h > stdnoreturn.h vec_types.h > htmintrin.h paired.hsi2vmx.h > stdalign.h stdbool.h stdint-gcc.h > tgmath.h > > I've not checked for other name conflicts vs. FreeBSD. I just happen > to recognize altivec.h . There is: > > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/include/machine/altivec.h > > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/lib/clang/6.0.0/include/altivec.h > > /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/obj-lib32/tmp/usr/include/machine/altivec.h Actually, that is a compiler intrinsincs header similar to the , etc. headers used for SSE on x86 that are always provided by the compiler. However, this header is '' not '' so it won't conflict. (On x86, these headers provide the _mm_* functions documented in Intel's SDM as the official C bindings for vector extensions, and probably plays a similar role in providing the vendor-specified C bindings for altivec instructions.) -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 2018-Jun-30, at 10:04 AM, Mark Millard wrote: > On 2018-Jun-30, at 9:29 AM, John Baldwin wrote: > >> On 6/30/18 9:17 AM, Mark Millard wrote: >>> On 2018-Jun-30, at 7:51 AM, John Baldwin wrote: >>> On 6/29/18 2:37 PM, Mark Millard wrote: > [I expect this is more than just amd64-gcc related but that is all > that ci.freebsd.org normally builds via a devel/*-gcc .] As indicated by my other mail, this is i386 and amd64 specific as it only matters for float.h on i386 due to the disagreement on LDBL_MANT_DIG. >>> >>> I was correct about the search order for include files being >>> different before -r335782 vs. -r335782 and later: >> >> Yes, but this is kind of a feature, not a bug, and the issue there is that >> as much as possible we should allow FreeBSD to work with the standard headers >> that are supposed to be part of the language (and thus provided by the >> toolchain). Right now we don't ship any of the 'std*.h' headers clang >> provides for example in our base system clang, though a few months ago I >> fixed the one place that was using instead of >> in userland that was breaking the use of the toolchain-provided >> stdarg.h (both GCC and clang). >> >>> Might this reversal have other effects even for >>> architectures for which the code does compile >>> via devel/*-gcc ? >> >> It depends on the header. This particular failure is due to a quirk of >> on FreeBSD/i386. I have built other platforms with external >> GCC just fine. To the extent that we encounter any other issues we >> should try to make our source more conformant with C and only fall back to >> axeing the toolchain-provided language headers as a last resort. > > It is too bad that the review https://reviews.freebsd.org/D16055 did not > catch the change in what headers are used by buildworld and buildkernel. > I'd view such switching of long established header bindings as a > fairly big deal, possibly even warranting being explicitly proposed and > debated. > > I'm not claiming my opinion on which search order that I have is > actually relevant. I'm just now nervous about my powerpc64-gcc based > builds having unexpected differences, for example. [I sometimes explore > the status of powerpc family builds via more modern toolchains.] > > (But lib32 for powerpc64 via modern gcc's is messed up anyway, > generating code in crtbeginS.o for the wrong ABI: using R30 incorrectly. > https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206123 has more about > that.) Looks like my being nervous is justified: there is a conflicting altivec.h that has nothing to do with C/C++ language standards: # ls /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/ altivec.h htmxlintrin.h ppc-asm.h spe.h stdarg.hstddef.hstdint.h varargs.h float.h iso646.hppu_intrinsics.h spu2vmx.h stdatomic.h stdfix.h stdnoreturn.h vec_types.h htmintrin.h paired.hsi2vmx.h stdalign.h stdbool.h stdint-gcc.htgmath.h I've not checked for other name conflicts vs. FreeBSD. I just happen to recognize altivec.h . There is: /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/include/machine/altivec.h /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/tmp/usr/lib/clang/6.0.0/include/altivec.h /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.powerpc64/obj-lib32/tmp/usr/include/machine/altivec.h === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 2018-Jun-30, at 9:29 AM, John Baldwin wrote: > On 6/30/18 9:17 AM, Mark Millard wrote: >> On 2018-Jun-30, at 7:51 AM, John Baldwin wrote: >> >>> On 6/29/18 2:37 PM, Mark Millard wrote: [I expect this is more than just amd64-gcc related but that is all that ci.freebsd.org normally builds via a devel/*-gcc .] >>> >>> As indicated by my other mail, this is i386 and amd64 specific as it >>> only matters for float.h on i386 due to the disagreement on >>> LDBL_MANT_DIG. >> >> I was correct about the search order for include files being >> different before -r335782 vs. -r335782 and later: > > Yes, but this is kind of a feature, not a bug, and the issue there is that > as much as possible we should allow FreeBSD to work with the standard headers > that are supposed to be part of the language (and thus provided by the > toolchain). Right now we don't ship any of the 'std*.h' headers clang > provides for example in our base system clang, though a few months ago I > fixed the one place that was using instead of > in userland that was breaking the use of the toolchain-provided > stdarg.h (both GCC and clang). > >> Might this reversal have other effects even for >> architectures for which the code does compile >> via devel/*-gcc ? > > It depends on the header. This particular failure is due to a quirk of > on FreeBSD/i386. I have built other platforms with external > GCC just fine. To the extent that we encounter any other issues we > should try to make our source more conformant with C and only fall back to > axeing the toolchain-provided language headers as a last resort. It is too bad that the review https://reviews.freebsd.org/D16055 did not catch the change in what headers are used by buildworld and buildkernel. I'd view such switching of long established header bindings as a fairly big deal, possibly even warranting being explicitly proposed and debated. I'm not claiming my opinion on which search order that I have is actually relevant. I'm just now nervous about my powerpc64-gcc based builds having unexpected differences, for example. [I sometimes explore the status of powerpc family builds via more modern toolchains.] (But lib32 for powerpc64 via modern gcc's is messed up anyway, generating code in crtbeginS.o for the wrong ABI: using R30 incorrectly. https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=206123 has more about that.) === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 6/30/18 9:17 AM, Mark Millard wrote: > On 2018-Jun-30, at 7:51 AM, John Baldwin wrote: > >> On 6/29/18 2:37 PM, Mark Millard wrote: >>> [I expect this is more than just amd64-gcc related but that is all >>> that ci.freebsd.org normally builds via a devel/*-gcc .] >> >> As indicated by my other mail, this is i386 and amd64 specific as it >> only matters for float.h on i386 due to the disagreement on >> LDBL_MANT_DIG. > > I was correct about the search order for include files being > different before -r335782 vs. -r335782 and later: Yes, but this is kind of a feature, not a bug, and the issue there is that as much as possible we should allow FreeBSD to work with the standard headers that are supposed to be part of the language (and thus provided by the toolchain). Right now we don't ship any of the 'std*.h' headers clang provides for example in our base system clang, though a few months ago I fixed the one place that was using instead of in userland that was breaking the use of the toolchain-provided stdarg.h (both GCC and clang). > Might this reversal have other effects even for > architectures for which the code does compile > via devel/*-gcc ? It depends on the header. This particular failure is due to a quirk of on FreeBSD/i386. I have built other platforms with external GCC just fine. To the extent that we encounter any other issues we should try to make our source more conformant with C and only fall back to axeing the toolchain-provided language headers as a last resort. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 2018-Jun-30, at 7:51 AM, John Baldwin wrote: > On 6/29/18 2:37 PM, Mark Millard wrote: >> [I expect this is more than just amd64-gcc related but that is all >> that ci.freebsd.org normally builds via a devel/*-gcc .] > > As indicated by my other mail, this is i386 and amd64 specific as it > only matters for float.h on i386 due to the disagreement on > LDBL_MANT_DIG. I was correct about the search order for include files being different before -r335782 vs. -r335782 and later: head -r335812 uses the gcc headers (and fails): ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include-fixed" ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/../../../../x86_64-unknown-freebsd12.0/include" #include "..." search starts here: #include <...> search starts here: /usr/src/lib/msun/x86 /usr/src/lib/msun/ld80 /usr/src/lib/msun/i387 /usr/src/lib/msun/src /usr/src/lib/libc/include /usr/src/lib/libc/i386 /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include End of search list. head -r335245 uses the FreeBSD headers and works: ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include-fixed" ignoring nonexistent directory "/usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/../../../../x86_64-unknown-freebsd12.0/include" ignoring duplicate directory "/usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include" #include "..." search starts here: #include <...> search starts here: /usr/src/lib/msun/x86 /usr/src/lib/msun/ld80 /usr/src/lib/msun/i387 /usr/src/lib/msun/src /usr/src/lib/libc/include /usr/src/lib/libc/i386 /usr/obj/amd64_xtoolchain-gcc/amd64.amd64/usr/src/amd64.amd64/obj-lib32/tmp/usr/include /usr/local/lib/gcc/x86_64-unknown-freebsd12.0/6.4.0/include End of search list. Might this reversal have other effects even for architectures for which the code does compile via devel/*-gcc ? === Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar) ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 6/29/18 2:37 PM, Mark Millard wrote: > [I expect this is more than just amd64-gcc related but that is all > that ci.freebsd.org normally builds via a devel/*-gcc .] As indicated by my other mail, this is i386 and amd64 specific as it only matters for float.h on i386 due to the disagreement on LDBL_MANT_DIG. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
[Re-sending from my subscription address, sorry for the spam] On Fri, Jun 29, 2018 at 1:26 PM, John Baldwin wrote: > On 6/28/18 7:54 PM, Mark Millard wrote: >> On 2018-Jun-28, at 6:04 PM, Mark Millard wrote: >> >>> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote: >>> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed) for FreeBSD-head-amd64-gcc. It looked to me like the most likely breaking-change was the following but I've not tried personal builds to confirm. ] > > So this is a bit complicated and I'm not sure what the correct fix is. > > What is happening is that the shipped with GCC is now being used > after this change instead of sys/x86/include/float.h. A sledgehammer approach > would be to remove float.h from the GCC package (we currently don't install > the float.h for the base system clang either). However, looking at this > in more detail, it seems that x86/include/float.h is also busted in some > ways. > > First, the #error I don't understand how it is happening. The GCC float.h > defines LDBL_MAX_EXP to the __LDBL_MAX_EXP__ builtin which is 16384 just > like the x86 float.h: > > # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | grep LDBL_MAX_EXP > #define __LDBL_MAX_EXP__ 16384 > > I even hacked catrigl.c to add the following lines before the #error > check: > > LDBL_MAX_EXP_ = LDBL_MAX_EXP > LDBL_MANT_DIG_ = LDBL_MANT_DIG > > #if LDBL_MAX_EXP != 0x4000 > #error "Unsupported long double format" > #endif > > And the -E output is: > > DBL_MAX_EXP_ = 16384 > LDBL_MANT_DIG_ = 53 > > # 51 "/zoo/jhb/zoo/jhb/git/freebsd/lib/msun/src/catrigl.c:93:2: error: #error > "U > nsupported long double format" > #error "Unsupported long double format" > ^ > > Yet clearly, 16384 == 0x4000 assuming it is doing a numeric comparison (which > it must be since the x86 float.h uses '16384' not '0x4000' as the value). > Isn't this just the unsupported LDBL_MANT_DIG you're hitting here? Note line 93. I reused the same error message for LDBL_MAX_EXP :/ > However, LDBL_MANT_DIG of 53 is a bit more fun. We have a comment about the > initial FPU control word in sys/amd64/include/fpu.h that reads thus: > > /* > * The hardware default control word for i387's and later coprocessors is > * 0x37F, giving: > * > * round to nearest > * 64-bit precision > * all exceptions masked. > * > * FreeBSD/i386 uses 53 bit precision for things like fadd/fsub/fsqrt etc > * because of the difference between memory and fpu register stack arguments. > * If its using an intermediate fpu register, it has 80/64 bits to work > * with. If it uses memory, it has 64/53 bits to work with. However, > * gcc is aware of this and goes to a fair bit of trouble to make the > * best use of it. > * > * This is mostly academic for AMD64, because the ABI prefers the use > * SSE2 based math. For FreeBSD/amd64, we go with the default settings. > */ > #define __INITIAL_FPUCW__ 0x037F > #define __INITIAL_FPUCW_I386__ 0x127F > #define __INITIAL_NPXCW__ __INITIAL_FPUCW_I386__ > #define __INITIAL_MXCSR__ 0x1F80 > #define __INITIAL_MXCSR_MASK__ 0xFFBF > > GCC is indeed aware of this in gcc/config/i386/freebsd.h which results in > __LDBL_MANT_DIG__ being set to 53 instead of 64: > > /* FreeBSD sets the rounding precision of the FPU to 53 bits. Let the >compiler get the contents of and std::numeric_limits correct. */ > #undef TARGET_96_ROUND_53_LONG_DOUBLE > #define TARGET_96_ROUND_53_LONG_DOUBLE (!TARGET_64BIT) > > clang seems unaware of this as it reports all the same values for > LDBL_MIN/MAX for both amd64 and i386 (values that match GCC for amd64 > but not i386): > > # cc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.18973149535723176502e+4932L > #define __LDBL_MIN__ 3.36210314311209350626e-4932L > # cc -dM -E empty.c -m32 | egrep 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.18973149535723176502e+4932L > #define __LDBL_MIN__ 3.36210314311209350626e-4932L > # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.18973149535723176502e+4932L > #define __LDBL_MIN__ 3.36210314311209350626e-4932L > # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | egrep > 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.1897314953572316e+4932L > #define __LDBL_MIN__ 3.3621031431120935e-4932L > > The x86/include/float.h header though reports the MIN/MAX values somewhere > in between the two ranges for both amd64 and i386 while reporting an > LDBL_MANT_DIG of 64: > > #define LDBL_MANT_DIG 64 > #define LDBL_MIN3.3621031431120935063E-4932L > #define LDBL_MAX1.1897314953572317650E+4932L > > I guess for now I will remove float.h from the amd64-gcc pkg-plist, but we > should really be fixing our tree to work with compiler-provided language > headers when at all possible. It's not clear to me if amd64 should be > using the compiler provided values of things like LDBL_MIN/MAX either btw. > >
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 2018-Jun-29, at 2:37 PM, Mark Millard wrote: > [I expect this is more than just amd64-gcc related but that is all > that ci.freebsd.org normally builds via a devel/*-gcc .] > > On 2018-Jun-29, at 10:38 AM, John Baldwin wrote: > >> On 6/28/18 7:54 PM, Mark Millard wrote: >>> On 2018-Jun-28, at 6:04 PM, Mark Millard wrote: >>> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote: . . . Later below expand the failing and previoly good commands, one option per line. The summary of the distinction in content is a one line difference, the working example ( -r335773 )had the option: -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include but the failing one did not. Working ( -r335773 ) is shown first. --- catrigl.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 -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include -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 . . . --- catrigl.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 . . . >>> >>> >>> For the report: >>> The xtoolchain GCC packages have not required these flags since ports commits r465416 and r466701 >>> >>> Looking at >>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6331/consoleText >>> there is: >>> Updating FreeBSD repository catalogue... FreeBSD repository is up to date. All repositories are up to date. The following 6 package(s) will be affected (of 0 checked): New packages to be INSTALLED: amd64-xtoolchain-gcc: 0.4_1 amd64-gcc: 6.4.0 mpfr: 4.0.1 gmp: 6.1.2 mpc: 1.1.0_1 amd64-binutils: 2.30_3,1 >>> >>> and amd64-gcc being 6.4.0 (via powerpc64-gcc) is from -r466834 >>> (via looking up in https://svnweb.freebsd.org/ports/head/devel/ ). >>> >>> This indicates that -r465416 and -r466701 did not cause: >>> >>> --sysroot=/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp >>> >>> to lead to include files being looked up in: >>> >>> /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >>> >>> Thus there appears to still be a need for: >>> >>> -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include >>> >>> unless more is done to the devel/*-gcc to make them look >>> in that additional place automatically (based on --sysroot). >> >> --sysroot does work, and you can verify it by doing the following: >> >> % touch empty.c >> % x86_64-unknown-freebsd11.2-gcc -c -v empty.c >> Using built-in specs. >> COLLECT_GCC=x86_64-unknown-freebsd11.2-gcc >> Target: x86_64-unknown-freebsd11.2 >> ... >> ignoring nonexistent directory >> "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include-fixed" >> ignoring nonexistent directory >> "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/../../../../x86_64-unknown-freebsd11.2/include" >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include >> /usr/include >> End of search list. >> ... >> % x86_64-unknown-freebsd11.2-gcc -c -v empty.c --sysroot=/foo >> Using built-in specs. >> COLLECT_GCC=x86_64-unknown-freebsd11.2-gcc >> Target: x86_64-unknown-freebsd11.2 >> ... >> ignoring nonexistent directory >> "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include-fixed" >> ignoring nonexistent directory >> "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/../../../../x86_64-unknown-freebsd11.2/include" >> ignoring nonexistent directory "/foo/usr/include" >> #include "..." search starts here: >> #include <...> search starts here: >> /usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include >> End of search list. >> >> I will see if I can reproduce the failure locally. > > The: > > ignoring nonexistent directory "/foo/usr/include" > >
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On Fri, Jun 29, 2018 at 1:26 PM, John Baldwin wrote: > On 6/28/18 7:54 PM, Mark Millard wrote: >> On 2018-Jun-28, at 6:04 PM, Mark Millard wrote: >> >>> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote: >>> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed) for FreeBSD-head-amd64-gcc. It looked to me like the most likely breaking-change was the following but I've not tried personal builds to confirm. ] > > So this is a bit complicated and I'm not sure what the correct fix is. > > What is happening is that the shipped with GCC is now being used > after this change instead of sys/x86/include/float.h. A sledgehammer approach > would be to remove float.h from the GCC package (we currently don't install > the float.h for the base system clang either). However, looking at this > in more detail, it seems that x86/include/float.h is also busted in some > ways. > > First, the #error I don't understand how it is happening. The GCC float.h > defines LDBL_MAX_EXP to the __LDBL_MAX_EXP__ builtin which is 16384 just > like the x86 float.h: > > # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | grep LDBL_MAX_EXP > #define __LDBL_MAX_EXP__ 16384 > > I even hacked catrigl.c to add the following lines before the #error > check: > > LDBL_MAX_EXP_ = LDBL_MAX_EXP > LDBL_MANT_DIG_ = LDBL_MANT_DIG > > #if LDBL_MAX_EXP != 0x4000 > #error "Unsupported long double format" > #endif > > And the -E output is: > > DBL_MAX_EXP_ = 16384 > LDBL_MANT_DIG_ = 53 > > # 51 "/zoo/jhb/zoo/jhb/git/freebsd/lib/msun/src/catrigl.c:93:2: error: #error > "U > nsupported long double format" > #error "Unsupported long double format" > ^ > > Yet clearly, 16384 == 0x4000 assuming it is doing a numeric comparison (which > it must be since the x86 float.h uses '16384' not '0x4000' as the value). > Isn't this just the unsupported LDBL_MANT_DIG you're hitting here? Note line 93. I reused the same error message for LDBL_MAX_EXP :/ > However, LDBL_MANT_DIG of 53 is a bit more fun. We have a comment about the > initial FPU control word in sys/amd64/include/fpu.h that reads thus: > > /* > * The hardware default control word for i387's and later coprocessors is > * 0x37F, giving: > * > * round to nearest > * 64-bit precision > * all exceptions masked. > * > * FreeBSD/i386 uses 53 bit precision for things like fadd/fsub/fsqrt etc > * because of the difference between memory and fpu register stack arguments. > * If its using an intermediate fpu register, it has 80/64 bits to work > * with. If it uses memory, it has 64/53 bits to work with. However, > * gcc is aware of this and goes to a fair bit of trouble to make the > * best use of it. > * > * This is mostly academic for AMD64, because the ABI prefers the use > * SSE2 based math. For FreeBSD/amd64, we go with the default settings. > */ > #define __INITIAL_FPUCW__ 0x037F > #define __INITIAL_FPUCW_I386__ 0x127F > #define __INITIAL_NPXCW__ __INITIAL_FPUCW_I386__ > #define __INITIAL_MXCSR__ 0x1F80 > #define __INITIAL_MXCSR_MASK__ 0xFFBF > > GCC is indeed aware of this in gcc/config/i386/freebsd.h which results in > __LDBL_MANT_DIG__ being set to 53 instead of 64: > > /* FreeBSD sets the rounding precision of the FPU to 53 bits. Let the >compiler get the contents of and std::numeric_limits correct. */ > #undef TARGET_96_ROUND_53_LONG_DOUBLE > #define TARGET_96_ROUND_53_LONG_DOUBLE (!TARGET_64BIT) > > clang seems unaware of this as it reports all the same values for > LDBL_MIN/MAX for both amd64 and i386 (values that match GCC for amd64 > but not i386): > > # cc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.18973149535723176502e+4932L > #define __LDBL_MIN__ 3.36210314311209350626e-4932L > # cc -dM -E empty.c -m32 | egrep 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.18973149535723176502e+4932L > #define __LDBL_MIN__ 3.36210314311209350626e-4932L > # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.18973149535723176502e+4932L > #define __LDBL_MIN__ 3.36210314311209350626e-4932L > # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | egrep > 'LDBL_(MIN|MAX)__' > #define __LDBL_MAX__ 1.1897314953572316e+4932L > #define __LDBL_MIN__ 3.3621031431120935e-4932L > > The x86/include/float.h header though reports the MIN/MAX values somewhere > in between the two ranges for both amd64 and i386 while reporting an > LDBL_MANT_DIG of 64: > > #define LDBL_MANT_DIG 64 > #define LDBL_MIN3.3621031431120935063E-4932L > #define LDBL_MAX1.1897314953572317650E+4932L > > I guess for now I will remove float.h from the amd64-gcc pkg-plist, but we > should really be fixing our tree to work with compiler-provided language > headers when at all possible. It's not clear to me if amd64 should be > using the compiler provided values of things like LDBL_MIN/MAX either btw. > > -- > John Baldwin >
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
[I expect this is more than just amd64-gcc related but that is all
that ci.freebsd.org normally builds via a devel/*-gcc .]
On 2018-Jun-29, at 10:38 AM, John Baldwin wrote:
> On 6/28/18 7:54 PM, Mark Millard wrote:
>> On 2018-Jun-28, at 6:04 PM, Mark Millard wrote:
>>
>>> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote:
>>>
>>> . . .
>>> Later below expand the failing and previoly good commands, one
>>> option per line. The summary of the distinction in content is
>>> a one line difference, the working example ( -r335773 )had the
>>> option:
>>>
>>> -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include
>>>
>>> but the failing one did not. Working ( -r335773 ) is shown first.
>>>
>>> --- catrigl.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
>>> -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include
>>> -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
>>> . . .
>>>
>>> --- catrigl.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
>>> . . .
>>
>>
>> For the report:
>>
>>> The xtoolchain GCC packages have not required these flags since ports
>>> commits r465416 and r466701
>>
>> Looking at https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6331/consoleText
>> there is:
>>
>>> Updating FreeBSD repository catalogue...
>>> FreeBSD repository is up to date.
>>> All repositories are up to date.
>>> The following 6 package(s) will be affected (of 0 checked):
>>>
>>> New packages to be INSTALLED:
>>> amd64-xtoolchain-gcc: 0.4_1
>>> amd64-gcc: 6.4.0
>>> mpfr: 4.0.1
>>> gmp: 6.1.2
>>> mpc: 1.1.0_1
>>> amd64-binutils: 2.30_3,1
>>
>> and amd64-gcc being 6.4.0 (via powerpc64-gcc) is from -r466834
>> (via looking up in https://svnweb.freebsd.org/ports/head/devel/ ).
>>
>> This indicates that -r465416 and -r466701 did not cause:
>>
>> --sysroot=/workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp
>>
>> to lead to include files being looked up in:
>>
>> /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include
>>
>> Thus there appears to still be a need for:
>>
>> -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include
>>
>> unless more is done to the devel/*-gcc to make them look
>> in that additional place automatically (based on --sysroot).
>
> --sysroot does work, and you can verify it by doing the following:
>
> % touch empty.c
> % x86_64-unknown-freebsd11.2-gcc -c -v empty.c
> Using built-in specs.
> COLLECT_GCC=x86_64-unknown-freebsd11.2-gcc
> Target: x86_64-unknown-freebsd11.2
> ...
> ignoring nonexistent directory
> "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include-fixed"
> ignoring nonexistent directory
> "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/../../../../x86_64-unknown-freebsd11.2/include"
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include
> /usr/include
> End of search list.
> ...
> % x86_64-unknown-freebsd11.2-gcc -c -v empty.c --sysroot=/foo
> Using built-in specs.
> COLLECT_GCC=x86_64-unknown-freebsd11.2-gcc
> Target: x86_64-unknown-freebsd11.2
> ...
> ignoring nonexistent directory
> "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include-fixed"
> ignoring nonexistent directory
> "/usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/../../../../x86_64-unknown-freebsd11.2/include"
> ignoring nonexistent directory "/foo/usr/include"
> #include "..." search starts here:
> #include <...> search starts here:
> /usr/local/lib/gcc/x86_64-unknown-freebsd11.2/6.4.0/include
> End of search list.
>
> I will see if I can reproduce the failure locally.
The:
ignoring nonexistent directory "/foo/usr/include"
means that the order of the search alternatives was not shown
("search starts here"). That is what I expect is different.
It will take a while before I'll have a build from either
before or after the
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 6/28/18 7:54 PM, Mark Millard wrote: > On 2018-Jun-28, at 6:04 PM, Mark Millard wrote: > >> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote: >> >>> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed) >>> for FreeBSD-head-amd64-gcc. It looked to me like the most likely >>> breaking-change was the following but I've not tried personal >>> builds to confirm. >>> ] So this is a bit complicated and I'm not sure what the correct fix is. What is happening is that the shipped with GCC is now being used after this change instead of sys/x86/include/float.h. A sledgehammer approach would be to remove float.h from the GCC package (we currently don't install the float.h for the base system clang either). However, looking at this in more detail, it seems that x86/include/float.h is also busted in some ways. First, the #error I don't understand how it is happening. The GCC float.h defines LDBL_MAX_EXP to the __LDBL_MAX_EXP__ builtin which is 16384 just like the x86 float.h: # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | grep LDBL_MAX_EXP #define __LDBL_MAX_EXP__ 16384 I even hacked catrigl.c to add the following lines before the #error check: LDBL_MAX_EXP_ = LDBL_MAX_EXP LDBL_MANT_DIG_ = LDBL_MANT_DIG #if LDBL_MAX_EXP != 0x4000 #error "Unsupported long double format" #endif And the -E output is: DBL_MAX_EXP_ = 16384 LDBL_MANT_DIG_ = 53 # 51 "/zoo/jhb/zoo/jhb/git/freebsd/lib/msun/src/catrigl.c:93:2: error: #error "U nsupported long double format" #error "Unsupported long double format" ^ Yet clearly, 16384 == 0x4000 assuming it is doing a numeric comparison (which it must be since the x86 float.h uses '16384' not '0x4000' as the value). However, LDBL_MANT_DIG of 53 is a bit more fun. We have a comment about the initial FPU control word in sys/amd64/include/fpu.h that reads thus: /* * The hardware default control word for i387's and later coprocessors is * 0x37F, giving: * * round to nearest * 64-bit precision * all exceptions masked. * * FreeBSD/i386 uses 53 bit precision for things like fadd/fsub/fsqrt etc * because of the difference between memory and fpu register stack arguments. * If its using an intermediate fpu register, it has 80/64 bits to work * with. If it uses memory, it has 64/53 bits to work with. However, * gcc is aware of this and goes to a fair bit of trouble to make the * best use of it. * * This is mostly academic for AMD64, because the ABI prefers the use * SSE2 based math. For FreeBSD/amd64, we go with the default settings. */ #define __INITIAL_FPUCW__ 0x037F #define __INITIAL_FPUCW_I386__ 0x127F #define __INITIAL_NPXCW__ __INITIAL_FPUCW_I386__ #define __INITIAL_MXCSR__ 0x1F80 #define __INITIAL_MXCSR_MASK__ 0xFFBF GCC is indeed aware of this in gcc/config/i386/freebsd.h which results in __LDBL_MANT_DIG__ being set to 53 instead of 64: /* FreeBSD sets the rounding precision of the FPU to 53 bits. Let the compiler get the contents of and std::numeric_limits correct. */ #undef TARGET_96_ROUND_53_LONG_DOUBLE #define TARGET_96_ROUND_53_LONG_DOUBLE (!TARGET_64BIT) clang seems unaware of this as it reports all the same values for LDBL_MIN/MAX for both amd64 and i386 (values that match GCC for amd64 but not i386): # cc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__' #define __LDBL_MAX__ 1.18973149535723176502e+4932L #define __LDBL_MIN__ 3.36210314311209350626e-4932L # cc -dM -E empty.c -m32 | egrep 'LDBL_(MIN|MAX)__' #define __LDBL_MAX__ 1.18973149535723176502e+4932L #define __LDBL_MIN__ 3.36210314311209350626e-4932L # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c | egrep 'LDBL_(MIN|MAX)__' #define __LDBL_MAX__ 1.18973149535723176502e+4932L #define __LDBL_MIN__ 3.36210314311209350626e-4932L # x86_64-unknown-freebsd12.0-gcc -dM -E empty.c -m32 | egrep 'LDBL_(MIN|MAX)__' #define __LDBL_MAX__ 1.1897314953572316e+4932L #define __LDBL_MIN__ 3.3621031431120935e-4932L The x86/include/float.h header though reports the MIN/MAX values somewhere in between the two ranges for both amd64 and i386 while reporting an LDBL_MANT_DIG of 64: #define LDBL_MANT_DIG 64 #define LDBL_MIN3.3621031431120935063E-4932L #define LDBL_MAX1.1897314953572317650E+4932L I guess for now I will remove float.h from the amd64-gcc pkg-plist, but we should really be fixing our tree to work with compiler-provided language headers when at all possible. It's not clear to me if amd64 should be using the compiler provided values of things like LDBL_MIN/MAX either btw. -- John Baldwin ___ freebsd-current@freebsd.org mailing list https://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 6/28/18 7:54 PM, Mark Millard wrote:
> On 2018-Jun-28, at 6:04 PM, Mark Millard wrote:
>
>> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote:
>>
>>> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed)
>>> for FreeBSD-head-amd64-gcc. It looked to me like the most likely
>>> breaking-change was the following but I've not tried personal
>>> builds to confirm.
>>> ]
>>>
>>> It looks to me that:
>>>
Author: jhb
Date: Thu Jun 28 21:26:14 2018
New Revision: 335782
URL:
https://svnweb.freebsd.org/changeset/base/335782
Log:
Remove the various build flag hacks for GCC cross-compile.
The xtoolchain GCC packages have not required these flags since ports
commits r465416 and r466701. The in-tree GCC 4.2.1 has also been patched
in r335716 and r335717 to correctly honor --sysroot when looking for
includes and libraries.
Reviewed by: bdrewery
Sponsored by: DARPA / AFRL
Differential Revision:
https://reviews.freebsd.org/D16055
>>> . . .
>>>
>>> broke ci.freebsd.org's FreeBSD-head-amd64-gcc build.
>>>
>>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6331/consoleText shows:
>>>
>>> --- catrigl.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.catrigl.o -MTcatrigl.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=unuse
d-function -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/src/catrigl.c -o catrigl.o
>>> /workspace/src/lib/msun/src/catrigl.c:90:2: error: #error "Unsupported long
>>> double format"
>>> #error "Unsupported long double format"
>>> ^
>>> /workspace/src/lib/msun/src/catrigl.c: In function 'casinhl':
>>> /workspace/src/lib/msun/src/catrigl.c:190:35: error: 'm_ln2' undeclared
>>> (first use in this function)
>>> w = clog_for_large_values(z) + m_ln2;
>>> ^
>>> /workspace/src/lib/msun/src/catrigl.c:190:35: note: each undeclared
>>> identifier is reported only once for each function it appears in
>>> /workspace/src/lib/msun/src/catrigl.c:202:11: error: 'SQRT_6_EPSILON'
>>> undeclared (first use in this function)
>>> if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4)
>>> ^~
>>> /workspace/src/lib/msun/src/catrigl.c: In function 'cacosl':
>>> /workspace/src/lib/msun/src/catrigl.c:250:20: error: 'm_ln2' undeclared
>>> (first use in this function)
>>> ry = creall(w) + m_ln2;
>>> ^
>>> /workspace/src/lib/msun/src/catrigl.c:261:11: error: 'SQRT_6_EPSILON'
>>> undeclared (first use in this function)
>>> if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4)
>>> ^~
>>> In file included from /workspace/src/lib/msun/src/catrigl.c:45:0:
>>> /workspace/src/lib/msun/src/catrigl.c: In function 'clog_for_large_values':
>>> /workspace/src/lib/msun/src/catrigl.c:316:34: error: 'm_e' undeclared
>>> (first use in this function)
>>> return (CMPLXL(logl(hypotl(x / m_e, y / m_e)) + 1,
>>> ^
>>> /workspace/src/lib/msun/src/catrigl.c:316:11: error: '__builtin_complex'
>>> operand not of real binary floating-point type
>>> return (CMPLXL(logl(hypotl(x / m_e, y / m_e)) + 1,
>>> ^
>>> /workspace/src/lib/msun/src/catrigl.c: In function 'catanhl':
>>> /workspace/src/lib/msun/src/catrigl.c:390:11: error: 'SQRT_3_EPSILON'
>>> undeclared (first use in this function)
>>> if (ax < SQRT_3_EPSILON / 2 && ay < SQRT_3_EPSILON / 2) {
>>> ^~
>>> /workspace/src/lib/msun/src/catrigl.c:396:9: error: 'm_ln2' undeclared
>>> (first use in this function)
>>> rx = (m_ln2 - logl(ay)) / 2;
>>>^
>>> *** [catrigl.o] Error code 1
>>
>> Later below expand the failing and previoly good commands, one
>> option per line. The summary of the distinction in content is
>> a one line difference, the working example (
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 2018-Jun-28, at 6:04 PM, Mark Millard wrote:
> On 2018-Jun-28, at 5:39 PM, Mark Millard wrote:
>
>> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed)
>> for FreeBSD-head-amd64-gcc. It looked to me like the most likely
>> breaking-change was the following but I've not tried personal
>> builds to confirm.
>> ]
>>
>> It looks to me that:
>>
>>> Author: jhb
>>> Date: Thu Jun 28 21:26:14 2018
>>> New Revision: 335782
>>> URL:
>>> https://svnweb.freebsd.org/changeset/base/335782
>>>
>>>
>>> Log:
>>> Remove the various build flag hacks for GCC cross-compile.
>>>
>>> The xtoolchain GCC packages have not required these flags since ports
>>> commits r465416 and r466701. The in-tree GCC 4.2.1 has also been patched
>>> in r335716 and r335717 to correctly honor --sysroot when looking for
>>> includes and libraries.
>>>
>>> Reviewed by:bdrewery
>>> Sponsored by: DARPA / AFRL
>>> Differential Revision:
>>> https://reviews.freebsd.org/D16055
>> . . .
>>
>> broke ci.freebsd.org's FreeBSD-head-amd64-gcc build.
>>
>> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6331/consoleText shows:
>>
>> --- catrigl.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.catrigl.o -MTcatrigl.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
-function -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/src/catrigl.c -o catrigl.o
>> /workspace/src/lib/msun/src/catrigl.c:90:2: error: #error "Unsupported long
>> double format"
>> #error "Unsupported long double format"
>> ^
>> /workspace/src/lib/msun/src/catrigl.c: In function 'casinhl':
>> /workspace/src/lib/msun/src/catrigl.c:190:35: error: 'm_ln2' undeclared
>> (first use in this function)
>> w = clog_for_large_values(z) + m_ln2;
>> ^
>> /workspace/src/lib/msun/src/catrigl.c:190:35: note: each undeclared
>> identifier is reported only once for each function it appears in
>> /workspace/src/lib/msun/src/catrigl.c:202:11: error: 'SQRT_6_EPSILON'
>> undeclared (first use in this function)
>> if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4)
>> ^~
>> /workspace/src/lib/msun/src/catrigl.c: In function 'cacosl':
>> /workspace/src/lib/msun/src/catrigl.c:250:20: error: 'm_ln2' undeclared
>> (first use in this function)
>> ry = creall(w) + m_ln2;
>> ^
>> /workspace/src/lib/msun/src/catrigl.c:261:11: error: 'SQRT_6_EPSILON'
>> undeclared (first use in this function)
>> if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4)
>> ^~
>> In file included from /workspace/src/lib/msun/src/catrigl.c:45:0:
>> /workspace/src/lib/msun/src/catrigl.c: In function 'clog_for_large_values':
>> /workspace/src/lib/msun/src/catrigl.c:316:34: error: 'm_e' undeclared (first
>> use in this function)
>> return (CMPLXL(logl(hypotl(x / m_e, y / m_e)) + 1,
>> ^
>> /workspace/src/lib/msun/src/catrigl.c:316:11: error: '__builtin_complex'
>> operand not of real binary floating-point type
>> return (CMPLXL(logl(hypotl(x / m_e, y / m_e)) + 1,
>> ^
>> /workspace/src/lib/msun/src/catrigl.c: In function 'catanhl':
>> /workspace/src/lib/msun/src/catrigl.c:390:11: error: 'SQRT_3_EPSILON'
>> undeclared (first use in this function)
>> if (ax < SQRT_3_EPSILON / 2 && ay < SQRT_3_EPSILON / 2) {
>> ^~
>> /workspace/src/lib/msun/src/catrigl.c:396:9: error: 'm_ln2' undeclared
>> (first use in this function)
>> rx = (m_ln2 - logl(ay)) / 2;
>>^
>> *** [catrigl.o] Error code 1
>
> Later below expand the failing and previoly good commands, one
> option per line. The summary of the distinction in content is
> a one line difference, the working example ( -r335773 )had the
> option:
>
> -isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include
>
> but the failing one
Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
On 2018-Jun-28, at 5:39 PM, Mark Millard wrote:
> [ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed)
> for FreeBSD-head-amd64-gcc. It looked to me like the most likely
> breaking-change was the following but I've not tried personal
> builds to confirm.
> ]
>
> It looks to me that:
>
>> Author: jhb
>> Date: Thu Jun 28 21:26:14 2018
>> New Revision: 335782
>> URL:
>> https://svnweb.freebsd.org/changeset/base/335782
>>
>>
>> Log:
>> Remove the various build flag hacks for GCC cross-compile.
>>
>> The xtoolchain GCC packages have not required these flags since ports
>> commits r465416 and r466701. The in-tree GCC 4.2.1 has also been patched
>> in r335716 and r335717 to correctly honor --sysroot when looking for
>> includes and libraries.
>>
>> Reviewed by:bdrewery
>> Sponsored by: DARPA / AFRL
>> Differential Revision:
>> https://reviews.freebsd.org/D16055
> . . .
>
> broke ci.freebsd.org's FreeBSD-head-amd64-gcc build.
>
> https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6331/consoleText shows:
>
> --- catrigl.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.catrigl.o -MTcatrigl.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-
function -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/src/catrigl.c -o catrigl.o
> /workspace/src/lib/msun/src/catrigl.c:90:2: error: #error "Unsupported long
> double format"
> #error "Unsupported long double format"
> ^
> /workspace/src/lib/msun/src/catrigl.c: In function 'casinhl':
> /workspace/src/lib/msun/src/catrigl.c:190:35: error: 'm_ln2' undeclared
> (first use in this function)
>w = clog_for_large_values(z) + m_ln2;
> ^
> /workspace/src/lib/msun/src/catrigl.c:190:35: note: each undeclared
> identifier is reported only once for each function it appears in
> /workspace/src/lib/msun/src/catrigl.c:202:11: error: 'SQRT_6_EPSILON'
> undeclared (first use in this function)
> if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4)
> ^~
> /workspace/src/lib/msun/src/catrigl.c: In function 'cacosl':
> /workspace/src/lib/msun/src/catrigl.c:250:20: error: 'm_ln2' undeclared
> (first use in this function)
> ry = creall(w) + m_ln2;
>^
> /workspace/src/lib/msun/src/catrigl.c:261:11: error: 'SQRT_6_EPSILON'
> undeclared (first use in this function)
> if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4)
> ^~
> In file included from /workspace/src/lib/msun/src/catrigl.c:45:0:
> /workspace/src/lib/msun/src/catrigl.c: In function 'clog_for_large_values':
> /workspace/src/lib/msun/src/catrigl.c:316:34: error: 'm_e' undeclared (first
> use in this function)
> return (CMPLXL(logl(hypotl(x / m_e, y / m_e)) + 1,
> ^
> /workspace/src/lib/msun/src/catrigl.c:316:11: error: '__builtin_complex'
> operand not of real binary floating-point type
> return (CMPLXL(logl(hypotl(x / m_e, y / m_e)) + 1,
> ^
> /workspace/src/lib/msun/src/catrigl.c: In function 'catanhl':
> /workspace/src/lib/msun/src/catrigl.c:390:11: error: 'SQRT_3_EPSILON'
> undeclared (first use in this function)
> if (ax < SQRT_3_EPSILON / 2 && ay < SQRT_3_EPSILON / 2) {
> ^~
> /workspace/src/lib/msun/src/catrigl.c:396:9: error: 'm_ln2' undeclared (first
> use in this function)
> rx = (m_ln2 - logl(ay)) / 2;
> ^
> *** [catrigl.o] Error code 1
Later below expand the failing and previoly good commands, one
option per line. The summary of the distinction in content is
a one line difference, the working example ( -r335773 )had the
option:
-isystem /workspace/obj/workspace/src/amd64.amd64/obj-lib32/tmp/usr/include
but the failing one did not. Working ( -r335773 ) is shown first.
--- catrigl.o ---
/usr/local/bin/x86_64-unknown-freebsd11.1-gcc
-DCOMPAT_32BIT
-march=i686
head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build)
[ ci.free.bsd.org jumped from -r335773 (built) to -r335784 (failed)
for FreeBSD-head-amd64-gcc. It looked to me like the most likely
breaking-change was the following but I've not tried personal
builds to confirm.
]
It looks to me that:
> Author: jhb
> Date: Thu Jun 28 21:26:14 2018
> New Revision: 335782
> URL:
> https://svnweb.freebsd.org/changeset/base/335782
>
>
> Log:
> Remove the various build flag hacks for GCC cross-compile.
>
> The xtoolchain GCC packages have not required these flags since ports
> commits r465416 and r466701. The in-tree GCC 4.2.1 has also been patched
> in r335716 and r335717 to correctly honor --sysroot when looking for
> includes and libraries.
>
> Reviewed by:bdrewery
> Sponsored by: DARPA / AFRL
> Differential Revision:
> https://reviews.freebsd.org/D16055
. . .
broke ci.freebsd.org's FreeBSD-head-amd64-gcc build.
https://ci.freebsd.org/job/FreeBSD-head-amd64-gcc/6331/consoleText shows:
--- catrigl.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.catrigl.o -MTcatrigl.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-fu
nction -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/src/catrigl.c -o catrigl.o
/workspace/src/lib/msun/src/catrigl.c:90:2: error: #error "Unsupported long
double format"
#error "Unsupported long double format"
^
/workspace/src/lib/msun/src/catrigl.c: In function 'casinhl':
/workspace/src/lib/msun/src/catrigl.c:190:35: error: 'm_ln2' undeclared (first
use in this function)
w = clog_for_large_values(z) + m_ln2;
^
/workspace/src/lib/msun/src/catrigl.c:190:35: note: each undeclared identifier
is reported only once for each function it appears in
/workspace/src/lib/msun/src/catrigl.c:202:11: error: 'SQRT_6_EPSILON'
undeclared (first use in this function)
if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4)
^~
/workspace/src/lib/msun/src/catrigl.c: In function 'cacosl':
/workspace/src/lib/msun/src/catrigl.c:250:20: error: 'm_ln2' undeclared (first
use in this function)
ry = creall(w) + m_ln2;
^
/workspace/src/lib/msun/src/catrigl.c:261:11: error: 'SQRT_6_EPSILON'
undeclared (first use in this function)
if (ax < SQRT_6_EPSILON / 4 && ay < SQRT_6_EPSILON / 4)
^~
In file included from /workspace/src/lib/msun/src/catrigl.c:45:0:
/workspace/src/lib/msun/src/catrigl.c: In function 'clog_for_large_values':
/workspace/src/lib/msun/src/catrigl.c:316:34: error: 'm_e' undeclared (first
use in this function)
return (CMPLXL(logl(hypotl(x / m_e, y / m_e)) + 1,
^
/workspace/src/lib/msun/src/catrigl.c:316:11: error: '__builtin_complex'
operand not of real binary floating-point type
return (CMPLXL(logl(hypotl(x / m_e, y / m_e)) + 1,
^
/workspace/src/lib/msun/src/catrigl.c: In function 'catanhl':
/workspace/src/lib/msun/src/catrigl.c:390:11: error: 'SQRT_3_EPSILON'
undeclared (first use in this function)
if (ax < SQRT_3_EPSILON / 2 && ay < SQRT_3_EPSILON / 2) {
^~
/workspace/src/lib/msun/src/catrigl.c:396:9: error: 'm_ln2' undeclared (first
use in this function)
rx = (m_ln2 - logl(ay)) / 2;
^
*** [catrigl.o] Error code 1
===
Mark Millard
marklmi at yahoo.com
( dsl-only.net went
away in early 2018-Mar)
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"
