From owner-freebsd-current@freebsd.org Sat Oct 17 15:57:21 2015 Return-Path: Delivered-To: freebsd-current@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id DF9ADA17871 for ; Sat, 17 Oct 2015 15:57:20 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from freefall.freebsd.org (freefall.freebsd.org [IPv6:2001:1900:2254:206c::16:87]) by mx1.freebsd.org (Postfix) with ESMTP id C42DA1556; Sat, 17 Oct 2015 15:57:20 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [IPv6:::1]) by freefall.freebsd.org (Postfix) with ESMTP id B868511C8; Sat, 17 Oct 2015 15:57:20 +0000 (UTC) (envelope-from bdrewery@FreeBSD.org) Received: from mail.xzibition.com (localhost [172.31.3.2]) by mail.xzibition.com (Postfix) with ESMTP id 793F114E79; Sat, 17 Oct 2015 15:57:20 +0000 (UTC) X-Virus-Scanned: amavisd-new at mail.xzibition.com Received: from mail.xzibition.com ([172.31.3.2]) by mail.xzibition.com (mail.xzibition.com [172.31.3.2]) (amavisd-new, port 10026) with LMTP id w7SEkShuMlTI; Sat, 17 Oct 2015 15:57:17 +0000 (UTC) Subject: Re: FreeBSD_HEAD_amd64_gcc4.9 - Build #673 - Failure DKIM-Filter: OpenDKIM Filter v2.9.2 mail.xzibition.com BC21A14E74 To: NGie Cooper 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> Cc: jenkins-admin@FreeBSD.org, ngie@FreeBSD.org, freebsd-current@FreeBSD.org From: Bryan Drewery Openpgp: id=F9173CB2C3AAEA7A5C8A1F0935D771BB6E4697CF; url=http://www.shatow.net/bryan/bryan2.asc X-Enigmail-Draft-Status: N1110 Organization: FreeBSD Message-ID: <56226FDB.70800@FreeBSD.org> Date: Sat, 17 Oct 2015 08:57:15 -0700 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:38.0) Gecko/20100101 Thunderbird/38.3.0 MIME-Version: 1.0 In-Reply-To: <78883694-7B54-4AC3-9B5B-D715D5DA1F88@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha1; protocol="application/pgp-signature"; boundary="5fRQnkmPQ6CgKVVuD0RCsaAPdtfArU6BF" X-BeenThere: freebsd-current@freebsd.org X-Mailman-Version: 2.1.20 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, 17 Oct 2015 15:57:21 -0000 This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --5fRQnkmPQ6CgKVVuD0RCsaAPdtfArU6BF Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 10/17/2015 12:09 AM, NGie Cooper wrote: >=20 >> On Oct 16, 2015, at 23:38, NGie Cooper wrote: >> >>> On Oct 16, 2015, at 23:26, NGie Cooper wrote:= >>> >>>> On Oct 16, 2015, at 22:33, Bryan Drewery wrot= e: >>> >>> ... >>> >>>>> I don't see how these changes cause this and I'm unable to reproduc= e >>>>> here. Is anyone else hitting this? >>>>> >>>> >>>> https://jenkins.freebsd.org/job/FreeBSD_HEAD_sparc64/lastBuild/conso= leText >>>> >>>> The sparc64 build is past this. I don't think it was due to my chang= es, >>>> 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=92s a race somewhere in the clang build=85 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/g= it/freebsd/src/lib/clang/include/../../../contrib/llvm/tools/clang/includ= e/clang/Basic/arm_neon.td >>> /home/ngie/git/freebsd/src/lib/clang/include/../../../contrib/llvm/to= ols/clang/include/clang/Basic/arm_neon.td:701:1: error: Record `VMOVL' do= es not have a field named `Operand'! >>> >>> def VMOVL : SInst<"vmovl", "wd", "csiUcUsUi">; >>> >>> *** [arm_neon.h] Error code 1 >> >> And=85 FWIW I=92m not sure your last set of changes caused this. Needs= more investigation. >> Thanks! >> -NGie >=20 > Hmm=85 it=92s the only generated header: >=20 > 67 GENINCS=3D arm_neon.h > 68 CLEANFILES=3D ${GENINCS} ${GENINCS:C/\.h$/.d/} >=20 > Well, lookie here: >=20 > $ 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/tool= s/clang/include/clang/Basic/arm_neon.td:701:1: error: Record `VMOVL' does= not have a field named `Operand'! >=20 > def VMOVL : SInst<"vmovl", "wd", "csiUcUsUi">; > ^ > *** Error code 1 >=20 > Stop. > make: stopped in /home/ngie/git/freebsd/src/lib/clang/include >=20 > The important thing to note is the Jenkins servers are running stable/1= 0 code too (IIRC), so it might be a mismatch in the tools. >=20 It's actually 10.1-RELEASE. > Also, this logic looks troublesome: >=20 > 42 .if empty(TOOLSDIR) || !exists(${TOOLSDIR}/usr/bin/clang-tblgen) > 43 .if ${MACHINE} =3D=3D "host" && defined(BOOTSTRAPPING_TOOLS) > 44 .if !empty(LEGACY_TOOLS) && exists(${LEGACY_TOOLS}/usr/bin/tblgen) > 45 TOOLSDIR=3D ${LEGACY_TOOLS} > 46 .endif > 47 .endif > 48 .if ${MK_STAGING} =3D=3D "yes" && exists(${STAGE_HOST_OBJTOP:Uno}/u= sr/bin/tblgen) > 49 TOOLSDIR=3D ${STAGE_HOST_OBJTOP} > 50 .endif > 51 .if exists(${LEGACY_TOOLS:Uno}/usr/bin/tblgen) > 52 TOOLSDIR=3D ${LEGACY_TOOLS} > 53 .endif > 54 .endif > 55 TOOLSDIR?=3D > 56 .if !empty(TOOLSDIR) && exists(${TOOLSDIR}/usr/bin/clang-tblgen) > 57 TBLGEN=3D ${TOOLSDIR}/usr/bin/tblgen > 58 CLANG_TBLGEN=3D ${TOOLSDIR}/usr/bin/clang-tblgen > 59 .endif > 60 TBLGEN?=3D tblgen > 61 CLANG_TBLGEN?=3D clang-tblgen >=20 > This kind of complexity matched something that I simplified at $work du= e to build races=85 >=20 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? >=20 > $ make all > /usr/obj/home/ngie/git/freebsd/src/usr.bin/clang/clang-tblgen/clang-tbl= gen -gen-arm-neon -d arm_neon.d -o arm_neon.h /home/ngie/git/freebsd/sr= c/lib/clang/include/../../../contrib/llvm/tools/clang/include/clang/Basic= /arm_neon.td > $ >=20 > Voila. >=20 > So this is happening because it=92s using clang-tblgen from the build h= ost somehow, which is not able to process the .td files. >=20 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. --=20 Regards, Bryan Drewery --5fRQnkmPQ6CgKVVuD0RCsaAPdtfArU6BF Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----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----- --5fRQnkmPQ6CgKVVuD0RCsaAPdtfArU6BF--