FreeBSD_HEAD_amd64_gcc4.9 - Build #673 - Failure
Bryan Drewery
bdrewery at FreeBSD.org
Sat Oct 17 15:57:21 UTC 2015
On 10/17/2015 12:09 AM, NGie Cooper wrote:
>
>> On Oct 16, 2015, at 23:38, NGie Cooper <yaneurabeya at gmail.com> wrote:
>>
>>> On Oct 16, 2015, at 23:26, NGie Cooper <yaneurabeya at gmail.com> wrote:
>>>
>>>> On Oct 16, 2015, at 22:33, Bryan Drewery <bdrewery at 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freebsd.org/pipermail/freebsd-current/attachments/20151017/4a91fc07/attachment.bin>
More information about the freebsd-current
mailing list