https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81936
--- Comment #4 from Tom de Vries <vries at gcc dot gnu.org> --- (In reply to Richard Biener from comment #2) > How do I reproduce, aka configure gcc? The ICE is actually in the host compiler, but it doesn't seem to reproduce in a non-offloading setup. Host compiler: OFFLOAD_TARGET_NAMES=nvptx-none Target: x86_64-none-linux-gnu Configured with: configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=x86_64-none-linux-gnu --enable-threads --disable-libmudflap --disable-libstdcxx-pch --disable-multilib --disable-libsanitizer --disable-libcc1 --enable-checking=yes,rtl --with-gnu-as --with-gnu-ld --enable-languages=c,c++,fortran --enable-shared --enable-lto --disable-nls --prefix=prefix --enable-offload-targets=nvptx-none --with-sysroot=libc --with-build-sysroot=libc --with-gmp=usr --with-mpfr=usr --with-mpc=usr --with-isl=usr --with-cuda-driver-include=cuda-runtime/include --with-cuda-driver-lib=cuda-driver/lib --enable-libgomp --disable-libitm --enable-libatomic --disable-libssp --disable-libcc1 --with-python-dir=python --with-build-time-tools=bin Offloading compiler: Target: nvptx-none Configured with: configure --build=x86_64-linux-gnu --host=x86_64-linux-gnu --target=nvptx-none --enable-threads --disable-libmudflap --disable-libstdcxx-pch --disable-multilib --disable-libsanitizer --disable-libcc1 --enable-checking=yes,rtl --with-gnu-as --with-gnu-ld --enable-languages=c,c++,fortran --enable-shared --enable-lto --disable-nls --prefix=prefix --with-headers=yes --enable-languages=c,lto,fortran --disable-sjlj-exceptions --disable-lto --without-gnu-ld --without-gnu-as --with-newlib --enable-multilib --enable-as-accelerator-for=x86_64-none-linux-gnu --with-sysroot=nvptx-none --with-build-sysroot=nvptx-none --with-gmp=usr --with-mpfr=usr --with-mpc=usr --with-isl=usr --with-cuda-driver-include=include --with-cuda-driver-lib=cuda-driver/lib --enable-libgomp --disable-libitm --disable-libatomic --disable-libssp --disable-libcc1 --with-python-dir=python --with-build-time-tools=bin --- Comment #5 from rguenther at suse dot de <rguenther at suse dot de> --- On Wed, 23 Aug 2017, vries at gcc dot gnu.org wrote: > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=81936 > > --- Comment #3 from Tom de Vries <vries at gcc dot gnu.org> --- > ICE is due to assert: > ... > at gcc/dwarf2out.c:5542 > 5542 gcc_assert (die->die_tag == DW_TAG_compile_unit > 5543 && die->die_id.die_symbol != NULL); > ... > > The assert triggers because die->die_id.die_symbol is NULL: > ... > (gdb) p die->die_tag > $3 = DW_TAG_compile_unit > (gdb) p die->die_id.die_symbol > $4 = 0x0 > ... > > If we go up we see we're trying to find a die_ref for 'expr': > ... > (gdb) up > #7 0x0000000000b9d804 in lto_write_tree_1 (ob=0x2771d30, expr=0x7ffff7521180, > ref_p=Unhandled dwarf expression opcode 0xf3) > at gcc/lto-streamer-out.c:422 > 422 && debug_hooks->die_ref_for_decl (expr, &sym, &off)) > ... > > and expr is: > ... > (gdb) call debug_generic_expr (expr) > .omp_data_i > ... The assert says that if we have a DIE at stream-in time then it should refer to early debug. What created the DIE for .omp_data_i and/or what failed to properly set its parent?
