On Sun, 19 May 2019 at 18:20, Timo Sintonen via D.gnu <d.gnu@puremagic.com> wrote: > > On Sunday, 19 May 2019 at 14:17:05 UTC, Iain Buclaw wrote: > > > > I don't really expect any part of druntime to build on bare > > metal. Too much depends on libc being available. > > I have done this several times so I mostly know what I am doing > and I do understand that this may also be something in my local > setup. > > > You could also use the new binaries I uploaded to compiler > > explorer for cross-checking whether the ICE is independently > > reproducible. > > > > https://explore.dgnu.org/z/WKKMCg > > > Cannot reproduce there. If you do not mind I include the long > version here. There is a failure in about 10 files and the others > pass. It seems it is the first function in the file. I do not > know if it is just because it is the first or is there something > inside that function. > (btw why the gdc title is printed twice) >
I wouldn't know, I don't have any control over that bit. > arm-eabi-gdc -Wall -Wfatal-errors -O2 -frelease > -fversion=NoSystem -fno-bounds-check > -Wa,-ahls=rt/typeinfo/ti_Aint.o.l --verbose > -fno-moduleinfo -fversion=GNU_ARM_EABI_Unwinder > -fversion=STM32F4 -mcpu=cortex-m4 -mthumb -mfpu=fpv4-sp-d16 > -mfloat-abi=hard -c rt/typeinfo/ti_Aint.d -o > rt/typeinfo/ti_Aint.o > Using built-in specs. > COLLECT_GCC=arm-eabi-gdc > Target: arm-eabi > Configured with: ../gcc/configure --disable-bootstrap > --disable-nls --disable-werror --target=arm-eabi > --enable-languages=c,d --without-isl --without-cloog > --enable-multilib --disable-libphobos --disable-libstdcxx > --disable-libssp --disable-libquadmath --without-headers > --with-newlib --with-system-zlib > Thread model: single > gcc version 9.1.0 (GCC) > COLLECT_GCC_OPTIONS='-Wall' '-Wfatal-errors' '-O2' '-frelease' > '-fversion=NoSystem' '-fno-bounds-check' '-v' '-fno-moduleinfo' > '-fversion=GNU_ARM_EABI_Unwinder' '-fversion=STM32F4' > '-mcpu=cortex-m4' '-mthumb' '-mfpu=fpv4-sp-d16' > '-mfloat-abi=hard' '-c' '-o' 'rt/typeinfo/ti_Aint.o' > '-march=armv7e-m+fp' > /usr/local/libexec/gcc/arm-eabi/9.1.0/d21 rt/typeinfo/ti_Aint.d > -quiet -dumpbase ti_Aint.d -mcpu=cortex-m4 -mthumb > -mfpu=fpv4-sp-d16 -mfloat-abi=hard -march=armv7e-m+fp > -auxbase-strip rt/typeinfo/ti_Aint.o -O2 -Wall -Wfatal-errors > -version -frelease -fversion=NoSystem -fno-bounds-check > -fno-moduleinfo -fversion=GNU_ARM_EABI_Unwinder -fversion=STM32F4 > -imultilib cortex-m4/hardfp/fpv4 -v -o /tmp/ccuXKTnJ.s > GNU D (GCC) version 9.1.0 (arm-eabi) > compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version > 4.0.1, MPC version 1.1.0, isl version none > GGC heuristics: --param ggc-min-expand=100 --param > ggc-min-heapsize=131072 > GNU D (GCC) version 9.1.0 (arm-eabi) > compiled by GNU C version 8.2.0, GMP version 6.1.2, MPFR version > 4.0.1, MPC version 1.1.0, isl version none > GGC heuristics: --param ggc-min-expand=100 --param > ggc-min-heapsize=131072 > binary /usr/local/libexec/gcc/arm-eabi/9.1.0/d21 > version v2.076.1 > predefs NoSystem GNU_ARM_EABI_Unwinder STM32F4 GNU D_Version2 > LittleEndian GNU_StackGrowsDown GNU_InlineAsm D_NoBoundsChecks > D_ModuleInfo D_Exceptions D_TypeInfo all ARM Thumb ARM_Thumb > ARM_HardFloat D_HardFloat CppRuntime_Gcc > parse ti_Aint > importall ti_Aint > import object (object.d) > import core.internal.hash (core/internal/hash.d) > import core.internal.traits (core/internal/traits.d) > import core.internal.convert (core/internal/convert.d) > import core.stdc.string (core/stdc/string.d) > semantic ti_Aint > semantic2 ti_Aint > semantic3 ti_Aint > d21: internal compiler error: Segmentation fault > 0xb1b98f crash_signal > ../../gcc/gcc/toplev.c:326 > 0x65327d Module::isRoot() > ../../gcc/gcc/d/dmd/module.h:143 Backtrace says that the 'this' pointer for Module is NULL. > 0x65327d TemplateInstance::appendToModuleMember() > ../../gcc/gcc/d/dmd/dtemplate.c:7444 Thereby, mi->importedFrom is NULL. It's not really obvious how that happens. Unless this is a module that managed to somehow not have semantic run on it, I would initially infer that some memory corruption had happened. What's the system compiler version you are using? I've tested with both gcc-9.1 and gcc-8.3, not able to reproduce. I've ignored the t-arm-elf modification for now, as that should not have any effect on the front-end. -- Iain.
