struct xlref
{
    ushort rwFirst;
    ushort rwLast;
    ubyte colFirst;
    ubyte colLast;
}

struct xlmref
{
    ushort count;
    xlref reflist;
}

Mac OS X (dmd 2.069.0)
===================
dmd  dprob.d
Segmentation fault: 11

Windows (dmd 2.069.2)
==================
dmd -v -m64 dprob.d
binary C:\D\dmd2\windows\bin\dmd.exe
version v2.069.2
config C:\D\dmd2\windows\bin\sc.ini
parse xlcall_wrap2
importall xlcall_wrap2
import object (C:\D\dmd2\windows\bin....\src\druntime\import\object.d)
semantic xlcall_wrap2

object.Error@(0): assert(0) or HLT instruction

0x0040496F
0x00404CF8
0x004CF2B6
0x004565A7
0x0044EAB0
0x004BF99E
0x74F757F9 in MultiByteToWideChar
0x76F2139E in RtlQueryProcessDebugInformation
0x76F21340 in RtlQueryProcessDebugInformation
0x76F21190 in RtlQueryProcessDebugInformation

What gives?

Saurabh

On Wednesday, 16 December 2015 at 09:26:33 UTC, Saurabh Das wrote:
> struct xlref
> {
>     ushort rwFirst;
>     ushort rwLast;
>     ubyte colFirst;
>     ubyte colLast;
> }
>
> struct xlmref
> {
>     ushort count;
>     xlref reflist;
> }
>
> Mac OS X (dmd 2.069.0)
> ===================
> dmd  dprob.d
> Segmentation fault: 11
>
> Windows (dmd 2.069.2)
> ==================
> dmd -v -m64 dprob.d
> binary C:\D\dmd2\windows\bin\dmd.exe
> version v2.069.2
> config C:\D\dmd2\windows\bin\sc.ini
> parse xlcall_wrap2
> importall xlcall_wrap2
> import object (C:\D\dmd2\windows\bin....\src\druntime\import\object.d)
> semantic xlcall_wrap2
>
> object.Error@(0): assert(0) or HLT instruction
>
> 0x0040496F
> 0x00404CF8
> 0x004CF2B6
> 0x004565A7
> 0x0044EAB0
> 0x004BF99E
> 0x74F757F9 in MultiByteToWideChar
> 0x76F2139E in RtlQueryProcessDebugInformation
> 0x76F21340 in RtlQueryProcessDebugInformation
> 0x76F21190 in RtlQueryProcessDebugInformation
>
> What gives?
>
> Saurabh

Any compiler crash is a bug, please report at issues.dlang.org

While you wait for it to be fixed, try swapping reflist and count and you should find it doesn't crash. You should probably do anyway to avoid wasting space in the struct (http://www.catb.org/esr/structure-packing/)

On 12/16/2015 01:26 AM, Saurabh Das wrote:
> struct xlref
> {
>      ushort rwFirst;
>      ushort rwLast;
>      ubyte colFirst;
>      ubyte colLast;
> }
>
> struct xlmref
> {
>      ushort count;
>      xlref reflist;
> }
>
> Mac OS X (dmd 2.069.0)
> ===================
> dmd  dprob.d
> Segmentation fault: 11

Compiler bug. Please report at

  https://issues.dlang.org/

Changing the order of the members of xlmref seems to be a workaround:

struct xlmref
{
    xlref reflist;
    ushort count;
}

Ali

On Wednesday, 16 December 2015 at 09:38:24 UTC, Ali Çehreli wrote:
> On 12/16/2015 01:26 AM, Saurabh Das wrote:
>> struct xlref
>> {
>>      ushort rwFirst;
>>      ushort rwLast;
>>      ubyte colFirst;
>>      ubyte colLast;
>> }
>>
>> struct xlmref
>> {
>>      ushort count;
>>      xlref reflist;
>> }
>>
>> Mac OS X (dmd 2.069.0)
>> ===================
>> dmd  dprob.d
>> Segmentation fault: 11
>
> Compiler bug. Please report at
>
>   https://issues.dlang.org/
>
> Changing the order of the members of xlmref seems to be a workaround:
>
> struct xlmref
> {
>     xlref reflist;
>     ushort count;
> }
>
> Ali

We are using it to communicate with Excel, so swapping it is not an option.

I'll report it as a compiler bug. In the meantime, this is a workaround worked for me:

struct xlref
{
     ushort rwFirst;
     ushort rwLast;
     ubyte[2] cols;
}

On Wednesday, 16 December 2015 at 10:07:38 UTC, Saurabh Das wrote:
> On Wednesday, 16 December 2015 at 09:38:24 UTC, Ali Çehreli wrote:
>> On 12/16/2015 01:26 AM, Saurabh Das wrote:
>>> struct xlref
>>> {
>>>      ushort rwFirst;
>>>      ushort rwLast;
>>>      ubyte colFirst;
>>>      ubyte colLast;
>>> }
>>>
>>> struct xlmref
>>> {
>>>      ushort count;
>>>      xlref reflist;
>>> }
>>>
>>> Mac OS X (dmd 2.069.0)
>>> ===================
>>> dmd  dprob.d
>>> Segmentation fault: 11
>>
>> Compiler bug. Please report at
>>
>>   https://issues.dlang.org/
>>
>> Changing the order of the members of xlmref seems to be a workaround:
>>
>> struct xlmref
>> {
>>     xlref reflist;
>>     ushort count;
>> }
>>
>> Ali
>
> We are using it to communicate with Excel, so swapping it is not an option.
>
> I'll report it as a compiler bug. In the meantime, this is a workaround worked for me:
>
> struct xlref
> {
>      ushort rwFirst;
>      ushort rwLast;
>      ubyte[2] cols;
> }

Filed: https://issues.dlang.org/show_bug.cgi?id=15455

Under OS, I've selected Mac OS X since only 1 OS selection is allowed. Is the convention to select 'Other' in cases where ICEs are observed in multiple OSes?

Thanks,
Saurabh

On Wednesday, 16 December 2015 at 10:15:49 UTC, Saurabh Das wrote:
> On Wednesday, 16 December 2015 at 10:07:38 UTC, Saurabh Das wrote:
>> On Wednesday, 16 December 2015 at 09:38:24 UTC, Ali Çehreli wrote:
>>> On 12/16/2015 01:26 AM, Saurabh Das wrote:
>>>> struct xlref
>>>> {
>>>>      ushort rwFirst;
>>>>      ushort rwLast;
>>>>      ubyte colFirst;
>>>>      ubyte colLast;
>>>> }
>>>>
>>>> struct xlmref
>>>> {
>>>>      ushort count;
>>>>      xlref reflist;
>>>> }
>>>>
>>>> Mac OS X (dmd 2.069.0)
>>>> ===================
>>>> dmd  dprob.d
>>>> Segmentation fault: 11
>>>
>>> Compiler bug. Please report at
>>>
>>>   https://issues.dlang.org/
>>>
>>> Changing the order of the members of xlmref seems to be a workaround:
>>>
>>> struct xlmref
>>> {
>>>     xlref reflist;
>>>     ushort count;
>>> }
>>>
>>> Ali
>>
>> We are using it to communicate with Excel, so swapping it is not an option.
>>
>> I'll report it as a compiler bug. In the meantime, this is a workaround worked for me:
>>
>> struct xlref
>> {
>>      ushort rwFirst;
>>      ushort rwLast;
>>      ubyte[2] cols;
>> }
>
> Filed: https://issues.dlang.org/show_bug.cgi?id=15455
>
> Under OS, I've selected Mac OS X since only 1 OS selection is allowed. Is the convention to select 'Other' in cases where ICEs are observed in multiple OSes?
>
> Thanks,
> Saurabh

I think it's more normal to select 'all' once it affects more than one. OS X only bugs are likely to get less attention because developers don't necessarily have the necessary machines to quickly test on. 'other' might be interpreted as something obscure. I'd say list it as 'all', chances are it crashes the same on linux as well.

I use dpaste to test compilation on linux.

On 2015-12-16 11:51, John Colvin wrote:

> I'd say list it as 'all', chances are it crashes the same on linux as well.

If it's an ICE, it's very likely it applies to all platforms. Unless you get an assert/crash in a platform specific file in DMD.

-- 
/Jacob Carlborg

I tested it on linux (64-bit distro), and it segfaults as well:

-----

$ echo "struct S { ushort a, b; ubyte c, d; } struct T { ushort e; S s; }" > test.d

$ dmd -v test.d
binary    dmd
version   v2.069.0
config    /etc/dmd.conf
parse     test
importall test
import    object	(/usr/include/dmd/druntime/import/object.d)
semantic  test
Segmentation fault

$ uname -r
3.13.0-37-generic

$ cat /etc/issue
Linux Mint 17.1 Rebecca \n \l

$ dmd --version
DMD64 D Compiler v2.069.0
Copyright (c) 1999-2015 by Digital Mars written by Walter Bright

-----

It doesn't crash if compiled in 32-bit:

-----

$ dmd -v -m32 test.d
binary    dmd
version   v2.069.0
config    /etc/dmd.conf
parse     test
importall test
import    object	(/usr/include/dmd/druntime/import/object.d)
semantic  test
semantic2 test
semantic3 test
code      test
gcc test.o -o test -m32 -L/usr/lib/i386-linux-gnu -Xlinker --export-dynamic -Xlinker -Bstatic -lphobos2 -Xlinker -Bdynamic -lpthread -lm -lrt -ldl
/usr/lib/gcc/x86_64-linux-gnu/4.8/../../../../lib32/crt1.o: In function `_start':
(.text+0x18): undefined reference to `main'
collect2: error: ld returned 1 exit status
--- errorlevel 1

-----

Using ubyte[2] or swapping the fields also solve the issue as mentioned above.

I also reproduce the issue using DMD v2.069.2.

So it may be good to add that information in the bug-report.