GDC 9 and ARM Cortex-M

[Iain Buclaw]

On Sun, 19 May 2019 at 18:20, Timo Sintonen via D.gnu
<d.gnu at 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.