Jump to page: 1 2
Thread overview
GDC 9 and ARM Cortex-M
May 19, 2019
Timo Sintonen
May 19, 2019
Johannes Pfau
May 19, 2019
Timo Sintonen
May 19, 2019
Mike Franklin
May 19, 2019
Timo Sintonen
May 19, 2019
Iain Buclaw
May 19, 2019
Timo Sintonen
May 19, 2019
Iain Buclaw
May 20, 2019
Timo Sintonen
May 20, 2019
Iain Buclaw
May 23, 2019
Timo Sintonen
May 23, 2019
Iain Buclaw
Jun 08, 2019
Timo Sintonen
Jul 07, 2019
Timo Sintonen
Jul 07, 2019
Iain Buclaw
Jul 07, 2019
Timo Sintonen
Jul 07, 2019
Iain Buclaw
May 19, 2019
I am updating my toolset and libraries to GCC/GDC 9.1 release. First impression is that druntime needs more work than with previous versions. Many places to change and even compiler crashes when compiling some files.

Before I look further I want to ask if there has been any testing with this target (cross compiler linux->arm-eabi). Is it expected to work, not to work or not tested at all.

May 19, 2019
Am Sun, 19 May 2019 06:54:14 +0000 schrieb Timo Sintonen:

> I am updating my toolset and libraries to GCC/GDC 9.1 release. First impression is that druntime needs more work than with previous versions. Many places to change and even compiler crashes when compiling some files.
> 
> Before I look further I want to ask if there has been any testing with this target (cross compiler linux->arm-eabi). Is it expected to work, not to work or not tested at all.

Cross-compilers in general are expected to work, but only basic testing
has been done. Bare-metal targets have some basic betterC testing, but we
only test without druntime. We never tested druntime or stripped-down
druntime on baremetal targets. Compiler crashes are certainly bugs and
should be reported.
Druntime requiring more changes now is sad, but not really unexpected as
I don't think anyone in the druntime team focuses on embedded targets. I
guess most people working on bare-metal completely reimplement a custom
runtime or use betterC with the C runtime only.

-- 
Johannes
May 19, 2019
On Sunday, 19 May 2019 at 06:54:14 UTC, Timo Sintonen wrote:
> I am updating my toolset and libraries to GCC/GDC 9.1 release. First impression is that druntime needs more work than with previous versions. Many places to change and even compiler crashes when compiling some files.
>
> Before I look further I want to ask if there has been any testing with this target (cross compiler linux->arm-eabi). Is it expected to work, not to work or not tested at all.

Several months ago, I used this script (https://github.com/JinShil/native-gdc/blob/master/native-gdc.sh) to build a native GDC compiler.  I then used that compiler by way of this script (https://github.com/JinShil/arm-none-eabi-gdc/blob/master/arm-none-eabi-gdc.sh) to build an arm-none-eabi cross-compiler from head.

I then used that cross-compiler to build this ARM Cortex-M project (https://github.com/JinShil/stm32f42_discovery_demo). Everything worked fine.

I don't know if that helps, but that's my experience for whatever it's worth.

Mike
May 19, 2019
On Sunday, 19 May 2019 at 09:34:55 UTC, Johannes Pfau wrote:
> Am Sun, 19 May 2019 06:54:14 +0000 schrieb Timo Sintonen:
>
>> I am updating my toolset and libraries to GCC/GDC 9.1 release. First impression is that druntime needs more work than with previous versions. Many places to change and even compiler crashes when compiling some files.
>> 
>> Before I look further I want to ask if there has been any testing with this target (cross compiler linux->arm-eabi). Is it expected to work, not to work or not tested at all.
>
> Cross-compilers in general are expected to work, but only basic testing
> has been done. Bare-metal targets have some basic betterC testing, but we
> only test without druntime. We never tested druntime or stripped-down
> druntime on baremetal targets. Compiler crashes are certainly bugs and
> should be reported.
> Druntime requiring more changes now is sad, but not really unexpected as
> I don't think anyone in the druntime team focuses on embedded targets. I
> guess most people working on bare-metal completely reimplement a custom
> runtime or use betterC with the C runtime only.

It looks like there is an ice with several files in rt/typeinfo.
I'll make a bug report when I know more.

May 19, 2019
On Sunday, 19 May 2019 at 10:49:51 UTC, Mike Franklin wrote:
> On Sunday, 19 May 2019 at 06:54:14 UTC, Timo Sintonen wrote:
>> I am updating my toolset and libraries to GCC/GDC 9.1 release. First impression is that druntime needs more work than with previous versions. Many places to change and even compiler crashes when compiling some files.
>>
>> Before I look further I want to ask if there has been any testing with this target (cross compiler linux->arm-eabi). Is it expected to work, not to work or not tested at all.
>
> Several months ago, I used this script (https://github.com/JinShil/native-gdc/blob/master/native-gdc.sh) to build a native GDC compiler.  I then used that compiler by way of this script (https://github.com/JinShil/arm-none-eabi-gdc/blob/master/arm-none-eabi-gdc.sh) to build an arm-none-eabi cross-compiler from head.
>
> I then used that cross-compiler to build this ARM Cortex-M project (https://github.com/JinShil/stm32f42_discovery_demo). Everything worked fine.
>
> I don't know if that helps, but that's my experience for whatever it's worth.
>
> Mike

As we know there is always three possible sources of failure:
- the compiler sources may have a bug
- my local tools (gcc binutils etc) may build a buggy compiler
- my use of the built compiler is wrong (compiler flags etc)

This is what I currently use to build the compiler. C compilers built with this are used in production.

cat >file <<EOF
MULTILIB_OPTIONS  += mcpu=cortex-m0/mcpu=cortex-m0plus/mcpu=cortex-m3/mcpu=cortex-m4/mcpu=cortex-m7  mfloat-abi=hard mfpu=fpv4-sp-d16 mfpu=fpv5-sp-d16
MULTILIB_DIRNAMES += cortex-m0 cortex-m0plus cortex-m3 cortex-m4 cortex-m7 hardfp fpv4 fpv5
MULTILIB_REQUIRED += mcpu=cortex-m0
MULTILIB_REQUIRED += mcpu=cortex-m0plus
MULTILIB_REQUIRED += mcpu=cortex-m3
MULTILIB_REQUIRED += mcpu=cortex-m4/mfloat-abi=hard/mfpu=fpv4-sp-d16
MULTILIB_REQUIRED += mcpu=cortex-m7/mfloat-abi=hard/mfpu=fpv5-sp-d16
MULTILIB_EXTRA_OPTS += mthumb

EOF
cp file gcc/gcc/config/arm/t-arm-elf

rm -rf build-gcc
mkdir build-gcc
cd build-gcc

../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

May 19, 2019
On Sun, 19 May 2019 at 16:00, Timo Sintonen via D.gnu <d.gnu@puremagic.com> wrote:
>
> On Sunday, 19 May 2019 at 10:49:51 UTC, Mike Franklin wrote:
> > On Sunday, 19 May 2019 at 06:54:14 UTC, Timo Sintonen wrote:
> >> I am updating my toolset and libraries to GCC/GDC 9.1 release. First impression is that druntime needs more work than with previous versions. Many places to change and even compiler crashes when compiling some files.
> >>
> >> Before I look further I want to ask if there has been any testing with this target (cross compiler linux->arm-eabi). Is it expected to work, not to work or not tested at all.
> >
> > Several months ago, I used this script
> > (https://github.com/JinShil/native-gdc/blob/master/native-gdc.sh) to build a native GDC compiler.  I then used that compiler by way of this script (https://github.com/JinShil/arm-none-eabi-gdc/blob/master/arm-none-eabi-gdc.sh) to build an arm-none-eabi cross-compiler from head.
> >
> > I then used that cross-compiler to build this ARM Cortex-M project (https://github.com/JinShil/stm32f42_discovery_demo). Everything worked fine.
> >
> > I don't know if that helps, but that's my experience for whatever it's worth.
> >
> > Mike
>
> As we know there is always three possible sources of failure:
> - the compiler sources may have a bug
> - my local tools (gcc binutils etc) may build a buggy compiler
> - my use of the built compiler is wrong (compiler flags etc)
>
> This is what I currently use to build the compiler. C compilers built with this are used in production.
>
> cat >file <<EOF
> MULTILIB_OPTIONS  +=
> mcpu=cortex-m0/mcpu=cortex-m0plus/mcpu=cortex-m3/mcpu=cortex-m4/mcpu=cortex-m7  mfloat-abi=hard mfpu=fpv4-sp-d16 mfpu=fpv5-sp-d16
> MULTILIB_DIRNAMES += cortex-m0 cortex-m0plus cortex-m3 cortex-m4
> cortex-m7 hardfp fpv4 fpv5
> MULTILIB_REQUIRED += mcpu=cortex-m0
> MULTILIB_REQUIRED += mcpu=cortex-m0plus
> MULTILIB_REQUIRED += mcpu=cortex-m3
> MULTILIB_REQUIRED +=
> mcpu=cortex-m4/mfloat-abi=hard/mfpu=fpv4-sp-d16
> MULTILIB_REQUIRED +=
> mcpu=cortex-m7/mfloat-abi=hard/mfpu=fpv5-sp-d16
> MULTILIB_EXTRA_OPTS += mthumb
>
> EOF
> cp file gcc/gcc/config/arm/t-arm-elf
>
> rm -rf build-gcc
> mkdir build-gcc
> cd build-gcc
>
> ../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
>

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

I don't really expect any part of druntime to build on bare metal. Too much depends on libc being available.

-- 
Iain

May 19, 2019
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)

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
0x65327d TemplateInstance::appendToModuleMember()
	../../gcc/gcc/d/dmd/dtemplate.c:7444
0x656e92 TemplateInstance::semantic(Scope*, Array<Expression*>*)
	../../gcc/gcc/d/dmd/dtemplate.c:6123
0x657b74 functionResolve(Match*, Dsymbol*, Loc, Scope*, Array<RootObject*>*, Type*, Array<Expression*>*)
	../../gcc/gcc/d/dmd/dtemplate.c:2582
0x68e3af resolveFuncCall(Loc, Scope*, Dsymbol*, Array<RootObject*>*, Type*, Array<Expression*>*, int)
	../../gcc/gcc/d/dmd/func.c:3485
0x684622 ExpressionSemanticVisitor::visit(CallExp*)
	../../gcc/gcc/d/dmd/expressionsem.c:3330
0x673425 semantic(Expression*, Scope*)
	../../gcc/gcc/d/dmd/expressionsem.c:8158
0x6f30d0 StatementSemanticVisitor::visit(ReturnStatement*)
	../../gcc/gcc/d/dmd/statementsem.c:2489
0x6f179a semantic(Statement*, Scope*)
	../../gcc/gcc/d/dmd/statementsem.c:3498
0x6f179a StatementSemanticVisitor::visit(CompoundStatement*)
	../../gcc/gcc/d/dmd/statementsem.c:139
0x6edbd5 semantic(Statement*, Scope*)
	../../gcc/gcc/d/dmd/statementsem.c:3498
0x694bde FuncDeclaration::semantic3(Scope*)
	../../gcc/gcc/d/dmd/func.c:1696
0x64406f AggregateDeclaration::semantic3(Scope*)
	../../gcc/gcc/d/dmd/dstruct.c:292
0x63a8bf Module::semantic3(Scope*)
	../../gcc/gcc/d/dmd/dmodule.c:814
0x72d7bd d_parse_file()
	../../gcc/gcc/d/d-lang.cc:1201


May 19, 2019
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.
May 20, 2019
On Sunday, 19 May 2019 at 18:58:09 UTC, Iain Buclaw wrote:

>
> 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.

It is in the dump above (even two times ;)

>> 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

I'll try to update to 9.1 and test again


May 20, 2019
On Mon, 20 May 2019 at 20:05, Timo Sintonen via D.gnu <d.gnu@puremagic.com> wrote:
>
> On Sunday, 19 May 2019 at 18:58:09 UTC, Iain Buclaw wrote:
>
> >
> > 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.
>
> It is in the dump above (even two times ;)
>
> >> 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
>
> I'll try to update to 9.1 and test again
>

Or even just 8.3, I guess.

-- 
Iain
« First   ‹ Prev
1 2