On 20/12/2019 08:56, Adhemerval Zanella wrote:
>
>
> On 20/12/2019 01:43, John McCall wrote:
>> On 19 Dec 2019, at 16:27, Adhemerval Zanella wrote:
>>
>> On 19/12/2019 14:41, Adhemerval Zanella wrote:
>>
>> On 18/12/2019 14:24, John McCall wrote:
>>
>> On 18 Dec 2019, at 6:48, Adhemerval Zanella wrote:
>>
>> On 18/12/2019 04:16, John McCall wrote:
>>
>> There’s been an ongoing failure on the
>> clang-cmake-armv8-selfhost builder for the last day or so; see e.g.:
>>
>> http://lab.llvm.org:8011/builders/clang-cmake-armv7-selfhost/builds/2827/
>>
>> This list is recorded as the contact information for
>> that builder.
>>
>> It is apparently crashing in a tblgen backend that I
>> just added:
>>
>> ```
>> Stack dump:
>> 0. Program arguments:
>> /home/buildslave/buildslave/clang-cmake-armv7-selfhost/stage1/bin/clang-tblgen
>> -gen-clang-type-writer -I
>> /home/buildslave/buildslave/clang-cmake-armv7-selfhost/llvm/clang/include -I
>> /home/buildslave/buildslave/clang-cmake-armv7-selfhost/llvm/clang/include/clang/AST
>> -I /home/buildslave/buildslave/clang-cmake-armv7-selfhost/llvm/llvm/include
>> /home/buildslave/buildslave/clang-cmake-armv7-selfhost/llvm/clang/include/clang/AST/TypeProperties.td
>> --write-if-changed -o
>> /home/buildslave/buildslave/clang-cmake-armv7-selfhost/stage1/tools/clang/include/clang/AST/AbstractTypeWriter.inc
>> Segmentation fault (core dumped)
>> ```
>>
>> I would like to fix this, but I have no ability to
>> reproduce it, and the crash information in the log is quite minimal. Is
>> there a way I can get a shell on a system that can reproduce this, or at the
>> very least get a line number for where exactly it is crashing?
>>
>> John.
>>
>> Hi John,
>>
>> I am the one responsible for babysitting the bots this week
>> and I will
>> take a look at this issue. I will let you know what I found.
>>
>> Thanks.
>>
>> John.
>>
>> Hi John,
>>
>> I couldn't reproduce the issue on the bot with
>> 2f932b57296a573454d29893eedbeaa6901c2a68,
>> both stage1 and stage2 build fine and check showed no regression. I
>> restarted the bot
>> and I will let you know how the results of the next iterations comes
>> out.
>>
>> Hi again John,
>>
>> I was looking at a different bot, so the results were for the one
>> running on armv7
>> instead the one that is failing which runs on armv8.
>>
>> The problem seems to be in fact a compiler issue on the container we use
>> to run
>> buildbot. It is an ubuntu 16.04, but we don't use the default compiler
>> (gcc 5.4.0),
>> but instead an updated one (gcc 7.4.0) provided by ubuntu test ppa [1].
>>
>> If I build clang-tblgen with gcc 7.4.0 on Release mode it generates a
>> segmentation
>> fault. It does not occur with RelWithDebugInfo neither if I used gcc
>> 5.4.0 on
>> Release mode.
>>
>> Trying to analyse the core generated does not really give us much
>> information, it
>> shows a recursive call on visitASTNodeHierarchyImpl:
>>
>> #0 __GI_memcmp (s1=<optimized out>, s2=<optimized out>, len=<optimized
>> out>) at memcmp.c:352
>> #1 0x0001dab8 in
>> clang::tblgen::visitASTNodeHierarchyImpl(llvm::RecordKeeper&,
>> llvm::StringRef, llvm::function_ref<void (clang::tblgen::ASTNode,
>> clang::tblgen::ASTNode)>) ()
>> [...]
>>
>> gdb can't show the bottom of the stack.
>>
>> This memcmp must be from |StringRef::operator<|. If that were getting
>> consistently miscompiled, I think we’d be having serious problems throughout
>> the compiler. But there could be something specific to this function that’s
>> either provoking a miscompile or just violating language rules; I don’t see
>> what that would be, though.
>>
>> John.
>
> My guess this is specific issue that in fact might be fixed on gcc-7 (I need
> to check which version the ppa repository actually use). I test with gcc 5.4
> and now I am testing with gcc 8. Most likely we will update the stage1
> compiler
> on this bot.
>
HI John,
I am not hitting another issue that I am not sure it is related to recent
table-gen changes, but it seems to be happen only on arm 32-bit bots. The
llvm-tblgen generates an invalid ./lib/Target/AArch64/AArch64GenGICombiner.inc
with this:
110 bool AArch64GenPreLegalizerCombinerHelper::tryCombineAll(
111 GISelChangeObserver &Observer,
112 MachineInstr &MI,
113 MachineIRBuilder &B,
114 CombinerHelper &Helper) const {
115 MachineBasicBlock *MBB = MI.getParent();
116 MachineFunction *MF = MBB->getParent();
117 MachineRegisterInfo &MRI = MF->getRegInfo();
118 (void)MBB; (void)MF; (void)MRI;
119
120 // Match data
121 PreferredTuple MatchData0;
122 IndexedLoadStoreMatchInfo MatchData0;
123
With both variables with same name. It does not happen with aarch64 bots.
I am trying to find why this is happening.
_______________________________________________
linaro-toolchain mailing list
linaro-toolchain@lists.linaro.org
https://lists.linaro.org/mailman/listinfo/linaro-toolchain
