Jump to page: 1 2
Thread overview
May 19
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
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
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
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
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
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
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
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
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
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