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
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
All, Following up on my report, it was due to the CUDA Toolkit built with Spack. Rebuilding it with the CentOS 8's default GCC 8.3.1, the build went fine again with the CMake configuration I've been using it. On Sun, Aug 30, 2020 at 3:21 PM Itaru Kitayama <itaru.kitayama at gmail.com> wrote:> > 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