I finally got a GDC cross-compiler built for the ARM Cortex-M, and it seems to generated executable code (code that can be executed).  I'm working on getting a *very* minimal D runtime so I can run a simple semihosted hello world program as I did with LDC here (http://wiki.dlang.org/Extremely_minimal_semihosted_%22Hello_World%22).  Please see the code there if you would like more context.

In my program, on this statement...

uint[3] message =
      [
	2, 			      //stderr
	cast(uint)"hello\r\n".ptr,    //ptr to string
	7                             //size of string
      ];

...GDC seems to generate a call to _d_arraycopy, which I've implemented, and another call to _d_arrayliteralTX, which I don't want to implement because it does a dynamic memory allocation.

I argue that this code should call neither _d_arraycopy, nor _d_arrayliteralTX because I believe everything should be known at compile time.

Is this a bug, by design, a temporary convenience?  Please advise and offer your suggestions?

Host: ArchLinux 64
arm-none-eabi-gdc (GCC) 4.8.2

Compilation: arm-none-eabi-gdc -march=armv7e-m -mcpu=cortex-m4 -mtune=cortex-m4 -mthumb -fno-emit-moduleinfo -c -ffunction-sections -fno-exceptions -fdata-sections start.d object.d
Link: arm-none-eabi-ld -nodefaultlibs -nostdlib -nophoboslib -nostartfiles --gc-sections object.o start.o -o start.elf

Thanks,
Mike

> Is this a bug, by design, a temporary convenience?  Please advise and offer your suggestions?

IMHO it is not a bug. Even static arrays are dynamically allocated and then convert to static.

You can write this:

uint[3] message;
message[0] = 2;
message[1] = cast(uint)"hello\r\n".ptr;
message[2] = 7;

On 18 December 2013 14:14, Mike <none@none.com> wrote:
> I finally got a GDC cross-compiler built for the ARM Cortex-M, and it seems to generated executable code (code that can be executed).  I'm working on getting a *very* minimal D runtime so I can run a simple semihosted hello world program as I did with LDC here (http://wiki.dlang.org/Extremely_minimal_semihosted_%22Hello_World%22). Please see the code there if you would like more context.
>
> In my program, on this statement...
>
> uint[3] message =
>       [
>         2,                            //stderr
>         cast(uint)"hello\r\n".ptr,    //ptr to string
>         7                             //size of string
>       ];
>
> ...GDC seems to generate a call to _d_arraycopy, which I've implemented, and another call to _d_arrayliteralTX, which I don't want to implement because it does a dynamic memory allocation.
>
> I argue that this code should call neither _d_arraycopy, nor _d_arrayliteralTX because I believe everything should be known at compile time.
>
> Is this a bug, by design, a temporary convenience?  Please advise and offer your suggestions?
>
> Host: ArchLinux 64
> arm-none-eabi-gdc (GCC) 4.8.2
>
> Compilation: arm-none-eabi-gdc -march=armv7e-m -mcpu=cortex-m4
> -mtune=cortex-m4 -mthumb -fno-emit-moduleinfo -c -ffunction-sections
> -fno-exceptions -fdata-sections start.d object.d
> Link: arm-none-eabi-ld -nodefaultlibs -nostdlib -nophoboslib -nostartfiles
> --gc-sections object.o start.o -o start.elf
>
> Thanks,
> Mike

Hi Mike,

This has been fixed to not call any library routines, but has not been backported to the 4.8 branch yet.

This is something that will be done before New Years (if my list of things to do does not grow even more...)

On 18 December 2013 14:29, Daniel Kozak <kozzi11@gmail.com> wrote:
>
>> Is this a bug, by design, a temporary convenience?  Please advise and offer your suggestions?
>
>
> IMHO it is not a bug. Even static arrays are dynamically allocated and then convert to static.
>

Not anymore, they are not.  It makes no sense to dynamically allocate static arrays as they are passed around by value anyway...

> IMHO it is not a bug. Even static arrays are dynamically allocated and then convert to static.

I mean everytime when you write [something, something else, ...] even if all members are known at compile time, it will create dynamic array.

On Wednesday, 18 December 2013 at 14:31:31 UTC, Iain Buclaw wrote:
> On 18 December 2013 14:29, Daniel Kozak <kozzi11@gmail.com> wrote:
>>
>>> Is this a bug, by design, a temporary convenience?  Please advise and
>>> offer your suggestions?
>>
>>
>> IMHO it is not a bug. Even static arrays are dynamically allocated and then
>> convert to static.
>>
>
> Not anymore, they are not.  It makes no sense to dynamically allocate
> static arrays as they are passed around by value anyway...


Wow, I miss this change :). Good to know.

Am Wed, 18 Dec 2013 14:29:57 +0000
schrieb Iain Buclaw <ibuclaw@gdcproject.org>:

> 
> Hi Mike,
> 
> This has been fixed to not call any library routines, but has not been backported to the 4.8 branch yet.
> 
> This is something that will be done before New Years (if my list of things to do does not grow even more...)

I already have a personal branch with 2.064 backported to the gcc-4.8 branch:

https://github.com/jpf91/GDC/commits/arm-old

The changes are minimal, 3 commits reverted and this: https://github.com/jpf91/GDC/commit/43e258300e8cecb961013630544027ab4bc5dd60

The main question is if we can simply use mark_decl_referenced as I did
there. If you think that's OK I can update the gcc-4.8 branch (of
course without the revert commits and instead doing proper
merges.)

On 18 December 2013 15:17, Johannes Pfau <nospam@example.com> wrote:
> Am Wed, 18 Dec 2013 14:29:57 +0000
> schrieb Iain Buclaw <ibuclaw@gdcproject.org>:
>
>>
>> Hi Mike,
>>
>> This has been fixed to not call any library routines, but has not been backported to the 4.8 branch yet.
>>
>> This is something that will be done before New Years (if my list of things to do does not grow even more...)
>
> I already have a personal branch with 2.064 backported to the gcc-4.8 branch:
>
> https://github.com/jpf91/GDC/commits/arm-old
>
> The changes are minimal, 3 commits reverted and this: https://github.com/jpf91/GDC/commit/43e258300e8cecb961013630544027ab4bc5dd60
>
> The main question is if we can simply use mark_decl_referenced as I did
> there. If you think that's OK I can update the gcc-4.8 branch (of
> course without the revert commits and instead doing proper
> merges.)

Maybe set force_output (instead of forced_by_abi) manually.

On 18 December 2013 15:17, Johannes Pfau <nospam@example.com> wrote:
> Am Wed, 18 Dec 2013 14:29:57 +0000
> schrieb Iain Buclaw <ibuclaw@gdcproject.org>:
>
>>
>> Hi Mike,
>>
>> This has been fixed to not call any library routines, but has not been backported to the 4.8 branch yet.
>>
>> This is something that will be done before New Years (if my list of things to do does not grow even more...)
>
> I already have a personal branch with 2.064 backported to the gcc-4.8 branch:
>
> https://github.com/jpf91/GDC/commits/arm-old
>

Some remarks.

From: https://github.com/jpf91/GDC/commit/f49267938b870f2c3e1712689db730a7ca6695b5

You probably want to keep the change:

#undef DEF_FUNCTION_TYPE_7

From: https://github.com/jpf91/GDC/commit/f4f7a7d770836f83a798dea6bc134f8dd270a516

Only the changes to d-system.h (and possibly d-lang.cc) broke the build on gcc-4.8.  The rest are non-breaking changes that are backwards compatible.

Regards
Iain

On Wednesday, 18 December 2013 at 15:17:34 UTC, Johannes Pfau wrote:
>
> I already have a personal branch with 2.064 backported to the gcc-4.8
> branch:
>
> https://github.com/jpf91/GDC/commits/arm-old
>

Thanks Iain and Johannes,

I've built Johannes's arm-old branch, but I can't yet get to the linker stage to test my original problem.  Instead, I'm now getting a new set of strange errors.  See below:

object.d:10: error: class Object only object.d can define this reserved class name
object.d:46: error: class TypeInfo only object.d can define this reserved class name
object.d:51: error: class TypeInfo_Array only object.d can define this reserved class name
object.d:61: error: class TypeInfo_Class only object.d can define this reserved class name
object.d:114: error: class TypeInfo_Interface only object.d can define this reserved class name
object.d:119: error: class TypeInfo_Struct only object.d can define this reserved class name
object.d:146: error: class TypeInfo_Pointer only object.d can define this reserved class name
object.d:151: error: class TypeInfo_Const only object.d can define this reserved class name
object.d:156: error: class TypeInfo_Typedef only object.d can define this reserved class name
object.d:163: error: class TypeInfo_Enum only object.d can define this reserved class name
object.d:10: error: class Object only object.d can define this reserved class name
object.d:46: error: class TypeInfo only object.d can define this reserved class name
object.d:51: error: class TypeInfo_Array only object.d can define this reserved class name
object.d:61: error: class TypeInfo_Class only object.d can define this reserved class name
object.d:114: error: class TypeInfo_Interface only object.d can define this reserved class name
object.d:119: error: class TypeInfo_Struct only object.d can define this reserved class name
object.d:146: error: class TypeInfo_Pointer only object.d can define this reserved class name
object.d:151: error: class TypeInfo_Const only object.d can define this reserved class name
object.d:156: error: class TypeInfo_Typedef only object.d can define this reserved class name
object.d:163: error: class TypeInfo_Enum only object.d can define this reserved class name

Two questions:
1) These are defined in my object.d, so why is it saying only object.d can define these types?
2) Why is there exactly two instances of each error message?

Again, here's my build line:
arm-none-eabi-gdc -march=armv7e-m -mcpu=cortex-m4 -mtune=cortex-m4 -mthumb -fno-emit-moduleinfo -c -ffunction-sections -fno-exceptions -fdata-sections start.d object.d