Comment # 1 on bug 215 from
OK, found the problem:

We should never set DECL_OFFSET_ALIGN to 0. The backend divides by
DECL_OFFSET_ALIGN. If it divides by zero the result is a null tree which will
then likely lead to a segfault.

In *t)) we set TYPE_SIZE, TYPE_ALIGN etc. But for the
union in the test case 'structsize' and 'alignsize' are 0. This is probably
because of the string mixin in the union? I guess setting TYPE_SIZE and
TYPE_ALIGN to 0 could not cause other issues as well.

Anyway, we then have a struct with this union as a field. For this struct we
call layout_aggregate_type which calls layout_aggregate_members,
layout_aggregate_members again and finally insert_aggregate_field. There we set


Always fascinating how such issues only show up on some architectures. It's
clearly not architecture specific code, it just seems to be different
optimizations can completely hide such problems.

@Iain would be great if you could have a look at this. Once this is fixed we'll
have master/ updated gdc-5 working 100% on ARM again.

 <field_decl 0x769baf00 D.3859
    type <union_type 0x769bade0 ._1 type_1 BLK
        size <integer_cst 0x7686b240 constant 0>
        unit size <integer_cst 0x7686b1e0 constant 0>
        align 0 symtab 0 alias set -1 canonical type 0x769bade0
        fields <field_decl 0x769baea0 y type <pointer_type 0x76876a20>
            unsigned SI file ../../test.d line 5 col 7
            size <integer_cst 0x7686b1b0 constant 32>
            unit size <integer_cst 0x7686b1c8 constant 4>
            align 32 offset_align 32 offset <integer_cst 0x7686b1e0 0> bit
offset <integer_cst 0x7686b240 0> context <union_type 0x769bade0 ._1>> context
<record_type 0x769bac00>
        chain <type_decl 0x769bae40 ._1>>
    VOID file (null) line 0 col 0
    align 1 offset_align 0 context <record_type 0x769bac00>>

#0  insert_aggregate_field (loc=..., type=0x769bac00, field=0x769baf00,
    at ../../gcc-5.3.0/gcc/d/
#1  0x002ccaa4 in layout_aggregate_members (members=0x7683ec38,
context=0x769bac00, inherited_p=false)
    at ../../gcc-5.3.0/gcc/d/
#2  0x002ccbcc in layout_aggregate_members (members=0x7676e918,
context=0x769bac00, inherited_p=false)
    at ../../gcc-5.3.0/gcc/d/
#3  0x002ccf2c in layout_aggregate_type (decl=0x7676e7b8, type=0x769bac00,
    at ../../gcc-5.3.0/gcc/d/
#4  0x002fb548 in TypeVisitor::visit (this=<optimized out>, t=0x7676e8c8)
    at ../../gcc-5.3.0/gcc/d/
#5  0x002fb11c in build_ctype (t=0x7676e8c8) at
#6  0x002ba89c in AggregateDeclaration::toInitializer
    at ../../gcc-5.3.0/gcc/d/
#7  0x002d3894 in StructDeclaration::toObjFile (this=0x7676e7b8) at
#8  0x002d8668 in Module::genobjfile (this=this@entry=0x7676e218) at
#9  0x002b8288 in d_parse_file () at ../../gcc-5.3.0/gcc/d/
#10 0x00772c34 in compile_file () at ../../gcc-5.3.0/gcc/toplev.c:594
#11 0x0019e148 in do_compile () at ../../gcc-5.3.0/gcc/toplev.c:2067
#12 toplev::main (this=this@entry=0x7efff284, argc=0, argc@entry=13,
argv=0x7efff5b8, argv@entry=0x7efff3f4)
    at ../../gcc-5.3.0/gcc/toplev.c:2165
#13 0x0019ed68 in main (argc=13, argv=0x7efff3f4) at

You are receiving this mail because: