Thread overview
Strange error in DGC for Arm (2.0.59 with gcc 4.7.2)
Aug 06, 2013
Timofei Bolshakov
Aug 23, 2013
Johannes Pfau
Aug 24, 2013
Johannes Pfau
August 06, 2013
Hello!

I got strange problem.
When I am trying to send a message containing a struct of size 30 I am getting a strange exception:

core.exception.AssertError@/home/tbolshakov/x-tools/arm-unknown-linux-gnueabi-gdc/lib/gcc/arm-unknown-linux-gnueabi/4.7.2/include/d/std/variant.d(280): target must be non-null

The code looks like:
//         enum ove the byte     string     string                    uint ushort    struct
send( tid, MessageTag.SPTRecord, gwmac_str, mac2HexString(t[0].idup), utc, ms, aStruct );

Does anybody have an idea why? Does anybody have an idea hw to fix it?

I have DGC version 2.0.59 made with gcc 4.7.2 (crosstool-ng 1.18.0).
August 23, 2013
Am Wed, 07 Aug 2013 00:05:35 +0200
schrieb "Timofei Bolshakov" <tbolsh@gmail.com>:

> Hello!
> 
> I got strange problem.
> When I am trying to send a message containing a struct of size 30
> I am getting a strange exception:
> 
> core.exception.AssertError@/home/tbolshakov/x-tools/arm-unknown-linux-gnueabi-gdc/lib/gcc/arm-unknown-linux-gnueabi/4.7.2/include/d/std/variant.d(280): target must be non-null
> 
> The code looks like:
> //         enum ove the byte     string     string
>      uint ushort    struct
> send( tid, MessageTag.SPTRecord, gwmac_str,
> mac2HexString(t[0].idup), utc, ms, aStruct );
> 
> Does anybody have an idea why? Does anybody have an idea hw to fix it?
> 
> I have DGC version 2.0.59 made with gcc 4.7.2 (crosstool-ng 1.18.0).

There are bugs in std.variant on ARM.

But in this case it might have a different cause: std.concurrency stores data in a Variant (see std.variant). A variant can only store things with a maximum size of creal.sizeof. On x86 creal is a pair of 2 reals, so 12/16bytes + alignment = 32 bytes.

On ARM real == double = 8 bytes, so creal.sizeof is 16 bytes. So the max size of a struct which can be stored in a Variant is 16 on ARM. This is basically a problem in Variant's design, it's not really meant to support struct types. It's for basic types only. This is why VariantN exists where you can define your own max size. But you can't access that functionality through std.concurrency.

I'd say file a bug report on std.concurrency that big structs are not supported and mention the issue that on non-x86 the max size is 16 byte only.
August 24, 2013
Am Fri, 23 Aug 2013 09:46:13 +0200
schrieb Johannes Pfau <nospam@example.com>:

> Am Wed, 07 Aug 2013 00:05:35 +0200
> schrieb "Timofei Bolshakov" <tbolsh@gmail.com>:
> 
> > Hello!
> > 
> > I got strange problem.
> > When I am trying to send a message containing a struct of size 30
> > I am getting a strange exception:
> > 
> > core.exception.AssertError@/home/tbolshakov/x-tools/arm-unknown-linux-gnueabi-gdc/lib/gcc/arm-unknown-linux-gnueabi/4.7.2/include/d/std/variant.d(280): target must be non-null
> > 
> > The code looks like:
> > //         enum ove the byte     string     string
> >      uint ushort    struct
> > send( tid, MessageTag.SPTRecord, gwmac_str,
> > mac2HexString(t[0].idup), utc, ms, aStruct );
> > 
> > Does anybody have an idea why? Does anybody have an idea hw to fix it?
> > 
> > I have DGC version 2.0.59 made with gcc 4.7.2 (crosstool-ng 1.18.0).
> 
> There are bugs in std.variant on ARM.
> 
> But in this case it might have a different cause: std.concurrency stores data in a Variant (see std.variant). A variant can only store things with a maximum size of creal.sizeof. On x86 creal is a pair of 2 reals, so 12/16bytes + alignment = 32 bytes.
> 
> On ARM real == double = 8 bytes, so creal.sizeof is 16 bytes. So the max size of a struct which can be stored in a Variant is 16 on ARM. This is basically a problem in Variant's design, it's not really meant to support struct types. It's for basic types only. This is why VariantN exists where you can define your own max size. But you can't access that functionality through std.concurrency.
> 
> I'd say file a bug report on std.concurrency that big structs are not supported and mention the issue that on non-x86 the max size is 16 byte only.

http://d.puremagic.com/issues/show_bug.cgi?id=10740