Date: Sat, 30 Jun 2018 12:52:48 -0700 From: Mark Millard <marklmi@yahoo.com> To: John Baldwin <jhb@freebsd.org> Cc: Dimitry Andric <dim@FreeBSD.org>, Bryan Drewery <bdrewery@FreeBSD.org>, svn-src-head@freebsd.org, FreeBSD Current <freebsd-current@freebsd.org> Subject: Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build) Message-ID: <AA1986CC-E407-4085-BAF9-0C54D6FFB2F4@yahoo.com> In-Reply-To: <d9385d5b-85a7-3012-3024-c6d9ae8c6705@FreeBSD.org> References: <00D1127A-1F0E-4E0E-B86C-1C5AA5B2E085@yahoo.com> <CF0230A1-1384-4F0F-A96A-5AB555FD17AC@yahoo.com> <7A845F2C-C994-4828-823D-33A97B7B6EB0@yahoo.com> <72081b02-cf23-82ec-32df-7f5793c35f57@FreeBSD.org> <003509F0-F2F4-4A43-82FE-3F6FC23D19D4@yahoo.com> <65b19cc4-eaf0-13ed-43e6-9f04a1f7f196@FreeBSD.org> <FF369ACC-D496-49AF-BB41-406936E433B0@yahoo.com> <edcd2126-3554-f444-6ba0-3da94d887dfe@FreeBSD.org> <49BF6569-96A9-4104-BDE6-8BB94C0D9626@yahoo.com> <F60AE252-CB8E-429E-97BF-812CC4012A90@yahoo.com> <d9385d5b-85a7-3012-3024-c6d9ae8c6705@FreeBSD.org>
next in thread | previous in thread | raw e-mail | index | archive | help
On 2018-Jun-30, at 11:53 AM, John Baldwin <jhb at freebsd.org> wrote: > On 6/30/18 10:19 AM, Mark Millard wrote: >=20 >=20 > On 2018-Jun-30, at 10:04 AM, Mark Millard <marklmi at yahoo.com> = wrote: >=20 >> On 2018-Jun-30, at 9:29 AM, John Baldwin <jhb at FreeBSD.org> wrote: >>=20 >>> On 6/30/18 9:17 AM, Mark Millard wrote: >>>> On 2018-Jun-30, at 7:51 AM, John Baldwin <jhb at FreeBSD.org> = wrote: >>>>=20 >>>>> 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 .] >>>>>=20 >>>>> 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. >>>>=20 >>>> I was correct about the search order for include files being >>>> different before -r335782 vs. -r335782 and later: >>>=20 >>> 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 <machine/stdarg.h> instead of >>> <stdarg.h> in userland that was breaking the use of the = toolchain-provided >>> stdarg.h (both GCC and clang). >>>=20 >>>> Might this reversal have other effects even for >>>> architectures for which the code does compile >>>> via devel/*-gcc ? >>>=20 >>> It depends on the header. This particular failure is due to a quirk = of >>> <float.h> 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. >>=20 >> 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. >>=20 >> 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.] >>=20 >> (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=3D206123 has more = about >> that.) >=20 > Looks like my being nervous is justified: there is a conflicting = altivec.h > that has nothing to do with C/C++ language standards: >=20 > # ls /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include/ > altivec.h htmxlintrin.h ppc-asm.h = spe.h stdarg.h stddef.h = stdint.h varargs.h > float.h iso646.h ppu_intrinsics.h = spu2vmx.h stdatomic.h stdfix.h = stdnoreturn.h vec_types.h > htmintrin.h paired.h si2vmx.h = stdalign.h stdbool.h stdint-gcc.h = tgmath.h >=20 > I've not checked for other name conflicts vs. FreeBSD. I just happen > to recognize altivec.h . There is: >=20 > = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/tmp/usr/include/machine/altivec.h >=20 > = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/tmp/usr/lib/clang/6.0.0/include/altivec.h >=20 > = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/obj-lib32/tmp/usr/include/machine/altivec.h >=20 > Actually, that is a compiler intrinsincs header similar to the = <emmintrin.h>, > etc. headers used for SSE on x86 that are always provided by the = compiler. > However, this header is '<altivec.h>' not '<machine/altivec.h>' so it = won't conflict. >=20 > (On x86, these headers provide the _mm_* functions documented in = Intel's > SDM as the official C bindings for vector extensions, and <altivec.h> > 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 <altivec.h> 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 = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/tmp/usr/include/machine/altivec.h = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/tmp/usr/lib/clang/6.0.0/include/altivec.h = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/obj-lib32/tmp/usr/include/machine/altivec.h If I read the below right the gcc altivec.h will be found by the above #include when building system clang via a modern gcc. The Lex_Lexer.o.meta shows (note the lack of include in some of the = paths compared to the above places where altivec.h files actually are --and = other path mismatches): ignoring nonexistent directory = "/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.p= owerpc64/tmp/usr/include/c++/v1//powerpc64-unknown-freebsd12.0" ignoring nonexistent directory = "/usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.p= owerpc64/tmp/usr/include/c++/v1//backward" ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include-fixed" ignoring nonexistent directory = "/usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/../../../../powerp= c64-unknown-freebsd12.0/include" #include "..." search starts here: #include <...> search starts here: = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/lib/clang/libclang = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/lib/clang/libllvm /usr/src/contrib/llvm/tools/clang/lib/Basic /usr/src/contrib/llvm/tools/clang/lib/Driver /usr/src/contrib/llvm/tools/clang/include /usr/src/lib/clang/include /usr/src/contrib/llvm/include = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/tmp/usr/include/c++/v1/ /usr/local/lib/gcc/powerpc64-unknown-freebsd12.0/6.4.0/include = /usr/obj/powerpc64vtsc_xtoolchain-gcc/powerpc.powerpc64/usr/src/powerpc.po= werpc64/tmp/usr/include End of search list. But the old order would have found the FreeBSD one, not the clang one, for its different order if I understand right. So it is not clear that before -r335782 was right either. But is is now different from what I can tell. What the consequences might be I do not (yet) know. Just for completeness . . . There are also uses of machine/altivec.h : /usr/src/sys/powerpc/aim/aim_machdep.c:#include <machine/altivec.h> /usr/src/sys/powerpc/booke/spe.c:#include <machine/altivec.h> /usr/src/sys/powerpc/powermac/platform_powermac.c:#include = <machine/altivec.h> /* For save_vec() */ /usr/src/sys/powerpc/powerpc/altivec.c:#include <machine/altivec.h> /usr/src/sys/powerpc/powerpc/elf32_machdep.c:#include = <machine/altivec.h> /usr/src/sys/powerpc/powerpc/elf64_machdep.c:#include = <machine/altivec.h> /usr/src/sys/powerpc/powerpc/exec_machdep.c:#include <machine/altivec.h> /usr/src/sys/powerpc/powerpc/machdep.c:#include <machine/altivec.h> /usr/src/sys/powerpc/powerpc/ptrace_machdep.c:#include = <machine/altivec.h> /usr/src/sys/powerpc/powerpc/trap.c:#include <machine/altivec.h> I'd wish that the file names for the 3 contexts had been made distinct = to avoid all potential aliasing problems. =3D=3D=3D Mark Millard marklmi at yahoo.com ( dsl-only.net went away in early 2018-Mar)
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?AA1986CC-E407-4085-BAF9-0C54D6FFB2F4>