Date: Sat, 17 Oct 2015 08:57:15 -0700 From: Bryan Drewery <bdrewery@FreeBSD.org> To: NGie Cooper <yaneurabeya@gmail.com> Cc: jenkins-admin@FreeBSD.org, ngie@FreeBSD.org, freebsd-current@FreeBSD.org Subject: Re: FreeBSD_HEAD_amd64_gcc4.9 - Build #673 - Failure Message-ID: <56226FDB.70800@FreeBSD.org> In-Reply-To: <78883694-7B54-4AC3-9B5B-D715D5DA1F88@gmail.com> References: <1743862498.27.1445058611319.JavaMail.jenkins@jenkins-9.freebsd.org> <5621D9F1.9080707@FreeBSD.org> <5621DDB1.8020807@FreeBSD.org> <31F4FEC4-B677-4EA1-BD67-F2DC458A99E4@gmail.com> <2B9A4B89-6D0D-4549-B249-FB30A8117DDF@gmail.com> <78883694-7B54-4AC3-9B5B-D715D5DA1F88@gmail.com>
next in thread | previous in thread | raw e-mail | index | archive | help
[-- Attachment #1 --] On 10/17/2015 12:09 AM, NGie Cooper wrote: > >> On Oct 16, 2015, at 23:38, NGie Cooper <yaneurabeya@gmail.com> wrote: >> >>> On Oct 16, 2015, at 23:26, NGie Cooper <yaneurabeya@gmail.com> wrote: >>> >>>> On Oct 16, 2015, at 22:33, Bryan Drewery <bdrewery@FreeBSD.org> wrote: >>> >>> ... >>> >>>>> I don't see how these changes cause this and I'm unable to reproduce >>>>> here. Is anyone else hitting this? >>>>> >>>> >>>> https://jenkins.freebsd.org/job/FreeBSD_HEAD_sparc64/lastBuild/consoleText >>>> >>>> The sparc64 build is past this. I don't think it was due to my changes, >>>> which were largely a NOP. Woops, that does not use clang :) >>>> >>>> I'm going to bed now, will look more tomorrow. >>> >>> I just hit it on my 10.2-RELEASE host with dual-SSDs and gobs of RAM. It’s a race somewhere in the clang build… just not sure where yet. >>> Thanks, >>> -NGie >>> >>> --- arm_neon.h --- >>> clang-tblgen -gen-arm-neon -d arm_neon.d -o arm_neon.h /home/ngie/git/freebsd/src/lib/clang/include/../../../contrib/llvm/tools/clang/include/clang/Basic/arm_neon.td >>> /home/ngie/git/freebsd/src/lib/clang/include/../../../contrib/llvm/tools/clang/include/clang/Basic/arm_neon.td:701:1: error: Record `VMOVL' does not have a field named `Operand'! >>> >>> def VMOVL : SInst<"vmovl", "wd", "csiUcUsUi">; >>> >>> *** [arm_neon.h] Error code 1 >> >> And… FWIW I’m not sure your last set of changes caused this. Needs more investigation. >> Thanks! >> -NGie > > Hmm… it’s the only generated header: > > 67 GENINCS= arm_neon.h > 68 CLEANFILES= ${GENINCS} ${GENINCS:C/\.h$/.d/} > > Well, lookie here: > > $ make clean > rm -f arm_neon.h arm_neon.d > $ make arm_neon.h > clang-tblgen -gen-arm-neon -d arm_neon.d -o arm_neon.h /home/ngie/git/freebsd/src/lib/clang/include/../../../contrib/llvm/tools/clang/include/clang/Basic/arm_neon.td > /home/ngie/git/freebsd/src/lib/clang/include/../../../contrib/llvm/tools/clang/include/clang/Basic/arm_neon.td:701:1: error: Record `VMOVL' does not have a field named `Operand'! > > def VMOVL : SInst<"vmovl", "wd", "csiUcUsUi">; > ^ > *** Error code 1 > > Stop. > make: stopped in /home/ngie/git/freebsd/src/lib/clang/include > > The important thing to note is the Jenkins servers are running stable/10 code too (IIRC), so it might be a mismatch in the tools. > It's actually 10.1-RELEASE. > Also, this logic looks troublesome: > > 42 .if empty(TOOLSDIR) || !exists(${TOOLSDIR}/usr/bin/clang-tblgen) > 43 .if ${MACHINE} == "host" && defined(BOOTSTRAPPING_TOOLS) > 44 .if !empty(LEGACY_TOOLS) && exists(${LEGACY_TOOLS}/usr/bin/tblgen) > 45 TOOLSDIR= ${LEGACY_TOOLS} > 46 .endif > 47 .endif > 48 .if ${MK_STAGING} == "yes" && exists(${STAGE_HOST_OBJTOP:Uno}/usr/bin/tblgen) > 49 TOOLSDIR= ${STAGE_HOST_OBJTOP} > 50 .endif > 51 .if exists(${LEGACY_TOOLS:Uno}/usr/bin/tblgen) > 52 TOOLSDIR= ${LEGACY_TOOLS} > 53 .endif > 54 .endif > 55 TOOLSDIR?= > 56 .if !empty(TOOLSDIR) && exists(${TOOLSDIR}/usr/bin/clang-tblgen) > 57 TBLGEN= ${TOOLSDIR}/usr/bin/tblgen > 58 CLANG_TBLGEN= ${TOOLSDIR}/usr/bin/clang-tblgen > 59 .endif > 60 TBLGEN?= tblgen > 61 CLANG_TBLGEN?= clang-tblgen > > This kind of complexity matched something that I simplified at $work due to build races… > None of this is used outside of META_MODE though. TOOLSDIR and LEGACY_TOOLS and MK_STAGING will all be empty or "no" here. There was a bug in some meta-mode-only code that didn't handle an empty TOOLSDIR properly, but all of these cases do. The only possible bad case I see is the LEGACY_TOOLS:Uno, if somehow that feature didn't work right on 10.1's bmake but I really doubt that. I've conditionalized the whole block on MK_META_MODE now anyhow. > Guess what happens when I use a proper clang-tblgen? > > $ make all > /usr/obj/home/ngie/git/freebsd/src/usr.bin/clang/clang-tblgen/clang-tblgen -gen-arm-neon -d arm_neon.d -o arm_neon.h /home/ngie/git/freebsd/src/lib/clang/include/../../../contrib/llvm/tools/clang/include/clang/Basic/arm_neon.td > $ > > Voila. > > So this is happening because it’s using clang-tblgen from the build host somehow, which is not able to process the .td files. > Perhaps PATH got set wrong somehow. Note that the build log does not have an absolute path for clang-tblgen, as the above code would cause. It is just using the default PATH as other builds do. There seems to be more going on here. After a clean buildworld, doing a -DNO_CLEAN incremental results in this file being regenerated. Doing a 2nd -DNO_CLEAN (hitting ctrl+t soon after this file is generated) does not regenerate it again. Something is making it stale during the build. -- Regards, Bryan Drewery [-- Attachment #2 --] -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBAgAGBQJWIm/bAAoJEDXXcbtuRpfPEjwIALJUaMHz9TDDNcFcRS7FxGm9 8ZYdP5Yh3+aABWMOWUfOqzlGpQUwYdetWg5iMJ5hHyji0zwZ5ssiEpkr/CoRmtia a4dVqXauBbCoDacKkNT1+1OQ3WFNbouUothiRF2cAlDAQv08ey6+zne4tE+mi6MO TtNOUrrmW9njCDzFCp/LOjgC+WrPwsiTO85Y5+VWXCAY7lRYxcvBW2iXK97CD2fF 8btt8VhKcZBCUsZyY6JA1vN5ivZs+xqlA2t+enBLPBIL1/NQVCAVWnuj7mG7z1vX P6LahdyX543NtdoyBo9AnnCzAO4QTZHSBQn6hT16NQvOWv/Zw4MvnWzqydGoPoY= =OfJr -----END PGP SIGNATURE-----
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?56226FDB.70800>