strtr wrote:
> strtr Wrote:
> 
>> dmd(1.048/55/56) crashed on me:
>> AppName: dmd.exe	 AppVer: 0.0.0.0	 ModName: unknown
>> ModVer: 0.0.0.0	 Offset: 00000002
>> There is a lot of crash data but I do not know where to start looking.
>> I've also tried finding which part of the code is responsible, but I haven't found it yet.
> 
> Everything is working again and I have found this piece of code which chokes the compiler.
> 
> module main;
> 
> //Digital Mars D Compiler v1.056
> //bud_win_3.04.exe -full -cleanup
> 
> enum ENUM
> {
> 	N0 = 1, //N0 = x; crashes for some values of x, ie. 1 and 10. and not for others ie. 3.
> 	N1,
> 	N2,
> 	N3,
> 	N4,
> 	N5,
> 	N6,
> 	N7,
> 	N8,
> 	N9,
> 	N10,
> 	N11,
> 	N12,
> 	N13,
> 	N14, 	N15, 	N16,
> 	N17,
> 	N18
> } 
> 
> 
> const char[][ ENUM.max + 1 ] ENUM_NAME = 	[
> 		ENUM.N0 : "N0",
> 	];
> 
> void main()
> {
> 	char[] text = `Hi`;
> 	
> 	switch(text)
> 	{
> 		//case `N0`:				//this works
> 		case ENUM_NAME[ENUM.N0]:	//this doesn't
> 			//return ENUM.N0;
> 		default:
> 			break;
> 	}
> }
> 
> I will post it together with my previous reported enum incomprehensibility bug if it can't be further minimized.

Excellent! I can reproduce it.
The D2 version of this code (char[] text = `Hi`.dup;) segfaults in Expression::arraySyntaxCopy() in expression.c, with evidence of memory corruption. The D1 version does *not* segfault there. In fact the code compiles with the debug version of DMD1!
I think the array literal isn't getting initialized properly.

Don wrote:
> strtr wrote:
>> strtr Wrote:
>>
>>> dmd(1.048/55/56) crashed on me:
>>> AppName: dmd.exe     AppVer: 0.0.0.0     ModName: unknown
>>> ModVer: 0.0.0.0     Offset: 00000002
>>> There is a lot of crash data but I do not know where to start looking.
>>> I've also tried finding which part of the code is responsible, but I haven't found it yet.
>>
>> Everything is working again and I have found this piece of code which chokes the compiler.
>>
>> module main;
>>
>> //Digital Mars D Compiler v1.056
>> //bud_win_3.04.exe -full -cleanup
>>
>> enum ENUM
>> {
>>     N0 = 1, //N0 = x; crashes for some values of x, ie. 1 and 10. and not for others ie. 3.
>>     N1,
>>     N2,
>>     N3,
>>     N4,
>>     N5,
>>     N6,
>>     N7,
>>     N8,
>>     N9,
>>     N10,
>>     N11,
>>     N12,
>>     N13,
>>     N14,     N15,     N16,
>>     N17,
>>     N18
>> }
>>
>> const char[][ ENUM.max + 1 ] ENUM_NAME =     [
>>         ENUM.N0 : "N0",
>>     ];
>>
>> void main()
>> {
>>     char[] text = `Hi`;
>>         switch(text)
>>     {
>>         //case `N0`:                //this works
>>         case ENUM_NAME[ENUM.N0]:    //this doesn't
>>             //return ENUM.N0;
>>         default:
>>             break;
>>     }
>> }
>>
>> I will post it together with my previous reported enum incomprehensibility bug if it can't be further minimized.
> 
> Excellent! I can reproduce it.
> The D2 version of this code (char[] text = `Hi`.dup;) segfaults in Expression::arraySyntaxCopy() in expression.c, with evidence of memory corruption. The D1 version does *not* segfault there. In fact the code compiles with the debug version of DMD1!
> I think the array literal isn't getting initialized properly.
> 
And it's a regression, introduced in DMD1.046. It worked in 1.045.

Don Wrote:
> Excellent! I can reproduce it.
> The D2 version of this code (char[] text = `Hi`.dup;) segfaults in
> Expression::arraySyntaxCopy() in expression.c, with evidence of memory
> > corruption. The D1 version does *not* segfault there. In fact the code
> compiles with the debug version of DMD1!
I'd love there to be a built debug version in the zip.

> I think the array literal isn't getting initialized properly.
What is up with the specific length of the enum? If you remove one element it compiles just fine.

> > 
> And it's a regression, introduced in DMD1.046. It worked in 1.045.
 1.048 wasn't far enough back :)

> I'd love there to be a built debug version in the zip.
>

Building is straightforward. Just run make -f*youros*.mak.
Works flawlessly out of the box for me with dmc on windows.

Trass3r Wrote:
> 
> Building is straightforward. Just run make -f*youros*.mak.
Should I be offended ?

> Works flawlessly out of the box for me with dmc on windows.
Took me only a few minutes, thanks.
But I had to install a compiler to a different language ;)

> Should I be offended ?
>

Nope. I just mentioned it cause I experience it very seldom that something compiles that painlessly out of the box.

Trass3r Wrote:
> > Building is straightforward. Just run make -f*youros*.mak.
> Should I be offended ? ;)
> 
> > Nope. I just mentioned it cause I experience it very seldom that something compiles that painlessly out of the box.

Sorry, it was a lame joke. At first glance it looked like self-censoring.

strtr wrote:
> Don Wrote:
>> Excellent! I can reproduce it.
>> The D2 version of this code (char[] text = `Hi`.dup;) segfaults in Expression::arraySyntaxCopy() in expression.c, with evidence of memory 
>>> corruption. The D1 version does *not* segfault there. In fact the code 
>> compiles with the debug version of DMD1!
> I'd love there to be a built debug version in the zip.
> 
>> I think the array literal isn't getting initialized properly.
> What is up with the specific length of the enum? If you remove one element it compiles just fine.

Bugzilla 3769. Very nasty.

Don wrote:
> strtr wrote:
>> Don Wrote:
>>> Excellent! I can reproduce it.
>>> The D2 version of this code (char[] text = `Hi`.dup;) segfaults in Expression::arraySyntaxCopy() in expression.c, with evidence of memory
>>>> corruption. The D1 version does *not* segfault there. In fact the code 
>>> compiles with the debug version of DMD1!
>> I'd love there to be a built debug version in the zip.
>>
>>> I think the array literal isn't getting initialized properly.
>> What is up with the specific length of the enum? If you remove one element it compiles just fine.
> 
> Bugzilla 3769. Very nasty.
And it's fixed in svn. Will be in the next release.