Re: FreeBSD_HEAD_amd64_gcc4.9 - Build #673 - Failure

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