[llvm-dev] builds are failing

[Itaru Kitayama via llvm-dev]

Johannes, Roman,

Thanks for responding to my report.

```
[2492/4583] Building CXX object
tools/clang/lib/ARCMigrate/CMakeFiles/obj.clangARCMigrate.dir/TransAutoreleasePool.cpp.o
[2493/4583] Building AMDGPUGenGlobalISel.inc...
FAILED: lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc
cd /slurm/scratch/10996/202008301514 &&
/slurm/scratch/10996/202008301514/bin/llvm-tblgen -gen-global-isel -I
/tmp/llvm-project/llvm/lib/Target/AMDGPU -I
/home/users/itaru.kitayama/projects/spack/opt/spack/linux-centos8-thunderx2/gcc-8.3.1/libxml2-2.9.10-urehecrjmaks7z77mdgi33msmcuxudm5/include/libxml2
-I /slurm/scratch/10996/202008301514/include -I
/tmp/llvm-project/llvm/include -I /tmp/llvm-project/llvm/lib/Target
/tmp/llvm-project/llvm/lib/Target/AMDGPU/AMDGPUGISel.td
--write-if-changed -o lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d
lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d
PLEASE submit a bug report to https://bugs.llvm.org/ and include the
crash backtrace.
Stack dump:
0. Program arguments:
/slurm/scratch/10996/202008301514/bin/llvm-tblgen -gen-global-isel -I
/tmp/llvm-project/llvm/lib/Target/AMDGPU -I
/home/users/itaru.kitayama/projects/spack/opt/spack/linux-centos8-thunderx2/gcc-8.3.1/libxml2-2.9.10-urehecrjmaks7z77mdgi33msmcuxudm5/include/libxml2
-I /slurm/scratch/10996/202008301514/include -I
/tmp/llvm-project/llvm/include -I /tmp/llvm-project/llvm/lib/Target
/tmp/llvm-project/llvm/lib/Target/AMDGPU/AMDGPUGISel.td
--write-if-changed -o lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc -d
lib/Target/AMDGPU/AMDGPUGenGlobalISel.inc.d
#0 0x000000000044d07c PrintStackTraceSignalHandler(void*)
(/slurm/scratch/10996/202008301514/bin/llvm-tblgen+0x44d07c)
[2494/4583] Building CXX object
lib/Target/MSP430/CMakeFiles/LLVMMSP430CodeGen.dir/MSP430MCInstLower.cpp.o
```

I'm building LLVM on ThunderX2, if CMake configuration is needed, I'll
post it as well.

On Sun, Aug 30, 2020 at 3:13 PM Roman Lebedev <lebedev.ri at gmail.com> wrote:
>
> Without seeing more details it's impossible to tell, but it might have been me.
>
> https://github.com/llvm/llvm-project/commit/6102310d814ad73eab60a88b21dd70874f7a056f#diff-0f9a49c4e31c311a0010e126cd785f08
> changed PHI node equality check, but there were some users that
> implicitly depended
> on the old definition of the PHI equality, and didn't verify their
> implicit assumptions with reality,
> which eventually manifested as stage2-stage3 clang mismatches.
>
> This was finally fixed in
> https://github.com/llvm/llvm-project/commit/5ec2b757cc7d37ff0d03b36ee863b0962fe78108
> and they have been taught to check with reality in
> https://github.com/llvm/llvm-project/commit/961483a5ea7c0e628c025187287d1658457ffcb3
> so this should be caught earlier next time.
>
> Roman
>
> On Sun, Aug 30, 2020 at 5:53 AM Johannes Doerfert via llvm-dev
> <llvm-dev at lists.llvm.org> wrote:
> >
> > Hi Itaru,
> >
> > (this time with the list CC'ed)
> >
> > I am not sure what failure you see but our buildbots look mostly green:
> > http://lab.llvm.org:8011/waterfall
> >
> > Please provide more details as it is hard to determine if this is an
> > LLVM issue or not.
> >
> > Thanks,
> >    Johannes
> >
> >
> > On 8/29/20 6:40 PM, Itaru Kitayama via llvm-dev wrote:
> > > I am seeing in the last couples of days llvm plus other projects builds are
> > > failing, is this being worked on?
> > > _______________________________________________
> > > LLVM Developers mailing list
> > > llvm-dev at lists.llvm.org
> > > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> > _______________________________________________
> > LLVM Developers mailing list
> > llvm-dev at lists.llvm.org
> > https://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev