There's a bug in the optimizer whereby it can fail to correctly execute loops like this:

for (int i=1; --i) {}

The problem appears to be in the code-scheduling, whereby the assignment to 'i' and the subsequent test for zero are seperated by instructions that alter the outcome of the assignment (the Z flag, in this instance).

Here's a sample, with the important parts highlighted:

00402E64   push        ebp
00402E65   mov         ebp,esp
00402E67   mov         edx,0Ah
00402E6C   sub         esp,1000h
00402E72   test        dword ptr [esp],esp
00402E75   dec         edx
00402E76   jne         _Dmain+8 (00402e6c)
00402E78   sub         esp,47Ch
00402E7E   mov         ecx,2710h
00402E83   mov         eax,0FFFFFFFFh
27:           char[40000] output;
00402E88   push        ebx
00402E89   push        esi
00402E8A   push        edi
22:   {
23:           //auto f = new Foo;
24:          // f + new Bar(1);
25:
26:           uint x;
00402E8B   lea         edi,[output]
00402E91   mov         dword ptr [x],0
00402E9B   rep stos    dword ptr [edi]
28:           wchar[1000] input = ' ';
00402E9D   lea         ecx,[input]
00402EA3   push        3E8h
00402EA8   push        20h
00402EAA   push        ecx
00402EAB   call        __memset16 (00408408)
29:           ulong ms = System.getMillisecs();
00402EB0   call        _D5mango3sys6System6System12getMillisecsFZm
(00405b1c)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
00402EB5   xor         ebx,ebx     ** assignment to i
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
00402EB7   mov         dword ptr [ms],eax
00402EBA   mov         dword ptr [ebp-54h],edx
30:           for (int i=1; --i;)
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
00402EBD   add         esp,0Ch    ** resets the Z flag! *BOGUS*
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
00402EC0   je          _Dmain+9Bh (00402eff)  ** testing for ebx == 0
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
31:                Utf.toUtf8 (input, output, &x);
00402EC2   mov         esi,9C40h
00402EC7   lea         edx,[output]
00402ECD   mov         dword ptr [ebp-0A478h],esi
00402ED3   mov         dword ptr [ebp-0A474h],edx
00402ED9   lea         eax,[input]
00402EDF   push        eax
00402EE0   lea         eax,[x]
00402EE6   push        3E8h
00402EEB   push        dword ptr [ebp-0A474h]
00402EF1   push        dword ptr [ebp-0A478h]
00402EF7   call        _D5mango7convert3Utf3Utf6toUtf8FAuAaPkZAa (00403498)
00402EFC   dec         ebx
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
00402EFD   jne         _Dmain+75h (00402ed9)    **  unit.max iterations
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

This is very similar to a codegen problem reported last year. Is it the same one?

I need a reproducible code example so I can fix it. -Walter

I did try to,Walter, but couldn't get a small self-contained example to exhibit the bug.

Having said that, you can see quite plainly there's a codegen issue there in the disassembly. The only example I have is using Mango and Ares ~ would you like that one?


"Walter Bright" <newshound@digitalmars.com> wrote in message news:dmohvf$34a$1@digitaldaemon.com...
>I need a reproducible code example so I can fix it. -Walter
>
> 

I've also had problems with -O. My programs exhibit really weird behaviour when compiled with -O. I guess in my case it might be related to tons of floating point calculations.



Kris wrote:
> I did try to,Walter, but couldn't get a small self-contained example to exhibit the bug.
> 
> Having said that, you can see quite plainly there's a codegen issue there in the disassembly. The only example I have is using Mango and Ares ~ would you like that one?
> 
> 
> "Walter Bright" <newshound@digitalmars.com> wrote in message news:dmohvf$34a$1@digitaldaemon.com...
> 
>>I need a reproducible code example so I can fix it. -Walter


-- 
Tomasz Stachowiak  /+ a.k.a. h3r3tic +/

"Kris" <fu@bar.com> wrote in message news:dmoru6$aqs$1@digitaldaemon.com...
> I did try to,Walter, but couldn't get a small self-contained example to exhibit the bug.

The first thing to try is delete all the function bodies but the one in question, replacing them with declarations.

"Tom S" <h3r3tic@remove.mat.uni.torun.pl> wrote in message news:dmpr0v$1uh7$1@digitaldaemon.com...
> I've also had problems with -O. My programs exhibit really weird behaviour when compiled with -O. I guess in my case it might be related to tons of floating point calculations.

I can't fix it without a reproducible sample.

Walter Bright schrieb:

> I can't fix it without a reproducible sample.
This might help: digitalmars.D.bugs/5643

-- 
Tiago Gasiba (M.Sc.) - http://www.gasiba.de
Everything should be made as simple as possible, but not simpler.

"Tiago Gasiba" <tiago.gasiba@gmail.com> wrote in message news:dmpug5$245d$1@digitaldaemon.com...
> This might help: digitalmars.D.bugs/5643

And that's a bug report I can deal with! Thanks.