From owner-freebsd-current@freebsd.org Sat Jun 30 19:53:02 2018 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 96875FD5DA7 for ; Sat, 30 Jun 2018 19:53:02 +0000 (UTC) (envelope-from marklmi@yahoo.com) Received: from sonic313-20.consmr.mail.gq1.yahoo.com (sonic313-20.consmr.mail.gq1.yahoo.com [98.137.65.83]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 099D98A65C for ; Sat, 30 Jun 2018 19:53:01 +0000 (UTC) (envelope-from marklmi@yahoo.com) X-YMail-OSG: NXGhhtwVM1n4_uoSr6_P_DdcqOlvMf0178FElPlm.ZnpSLskbfHPmt4ZtgdP6aI U3zY0434R4mWFdi.5GbAGV9eJaz8B8qrISShix5fqqHsOUnjof0S1IAaH.ab7RloL2Y_WkJF9QXi MbOdQNoYcr37j6ATqSNKOhLnLi.mWWbSrK41VDYkX5od7RsIahaJqrZEPEFB_aEWlcwB.jOEGEXZ xkDEHUP4Yfu00ZDsvW4wt7VHKq2LfWgvuIXrqOFXSrDuebhhJ05JrCJYq7bwUQppXBk_zCHZGQ7I 0R7PGahDhp.bHAWxkcmhOsWJ32.44sCayLt9_niAjS58OThCourzbb9gssT1_.M5U.YzAj5MM3dM qgibMC5CYh5.heu25Nd.nNB9NUJVvbIeo9Evn2GySQCcaUUFFcv9uCSZiRJzZ0w4bycXh1EUB2aV JlZTsdn7ZGez1JWlOq6rodYREyswosTpsOCREgbYxFki5W0z4kRkuksAxNfQTllQINnr_R5JfHXR HMeABCWtLBJ70vXC0QpA.IZnDKQRG1u9fJ6Yeomc1P6B6fUVmdCrgMqOnxjDf0CXiHW_cxIHr5AZ W2qjXXU79sSXNEzBXEuH_9qwKftl3ieONydtGOWAdNy_jRmA6JhTq_vBdFM2z010EGpXSM_qDVXi TmrPoRN90dlvG.zQCIJb2JtJYWCmLVOMj6sqLuMOjxjX3LBb0YURr2CzI.30ss4ieIWuSkb59rgH RSODvLhr0I0ze2BY4XWRg6DQVvkajSTu_MJXXpm7lQIwvjIGBMqENwr5uli9QBnDBTA_iCOQG6lU jXN1HRgQQCVhyYIgtxtZONCaRQ4W9HT3qZezqhpgapGLk5NYIJKW9FtxMKowSyzlhf2EFhppc8_Q PHQiY3X55x185A5HxWu3XLrTZXjRCMT5cnJZQn7c4aESXYPCaegwuPArsqql.dIdWIKeFTrUufqP RKq1hzZPROn9c9JpChKuorxYIN6MBSY1e.g-- Received: from sonic.gate.mail.ne1.yahoo.com by sonic313.consmr.mail.gq1.yahoo.com with HTTP; Sat, 30 Jun 2018 19:52:54 +0000 Received: from ip70-189-131-151.lv.lv.cox.net (EHLO [192.168.0.105]) ([70.189.131.151]) by smtp405.mail.gq1.yahoo.com (Oath Hermes SMTP Server) with ESMTPA ID 5aa676cfba08ebfdb7125dd985a49388; Sat, 30 Jun 2018 19:52:50 +0000 (UTC) Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 11.4 \(3445.8.2\)) Subject: Re: head -r335782 (?) broke ci.freebsd.org's FreeBSD-head-amd64-gcc build (lib32 part of build) From: Mark Millard In-Reply-To: Date: Sat, 30 Jun 2018 12:52:48 -0700 Cc: Dimitry Andric , Bryan Drewery , svn-src-head@freebsd.org, FreeBSD Current Content-Transfer-Encoding: quoted-printable Message-Id: References: <00D1127A-1F0E-4E0E-B86C-1C5AA5B2E085@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> <49BF6569-96A9-4104-BDE6-8BB94C0D9626@yahoo.com> To: John Baldwin X-Mailer: Apple Mail (2.3445.8.2) X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.27 Precedence: list List-Id: Discussions about the use of FreeBSD-current List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 30 Jun 2018 19:53:02 -0000 On 2018-Jun-30, at 11:53 AM, John Baldwin wrote: > On 6/30/18 10:19 AM, Mark Millard wrote: >=20 >=20 > On 2018-Jun-30, at 10:04 AM, Mark Millard = wrote: >=20 >> On 2018-Jun-30, at 9:29 AM, John Baldwin wrote: >>=20 >>> On 6/30/18 9:17 AM, Mark Millard wrote: >>>> On 2018-Jun-30, at 7:51 AM, John Baldwin = 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 instead of >>> 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 >>> 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 = , > etc. headers used for SSE on x86 that are always provided by the = compiler. > However, this header is '' not '' 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 > 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 = /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 /usr/src/sys/powerpc/booke/spe.c:#include /usr/src/sys/powerpc/powermac/platform_powermac.c:#include = /* For save_vec() */ /usr/src/sys/powerpc/powerpc/altivec.c:#include /usr/src/sys/powerpc/powerpc/elf32_machdep.c:#include = /usr/src/sys/powerpc/powerpc/elf64_machdep.c:#include = /usr/src/sys/powerpc/powerpc/exec_machdep.c:#include /usr/src/sys/powerpc/powerpc/machdep.c:#include /usr/src/sys/powerpc/powerpc/ptrace_machdep.c:#include = /usr/src/sys/powerpc/powerpc/trap.c:#include 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)