Thanks for fixing it Dmitry!

Why is that case so special that you called it "exotic case" ?:)

Best regards!

> From: "Alexey Zaparovanny" <azapa...@gis.net>
> To: <mspgcc-users@lists.sourceforge.net>
> Date: Thu, 26 Sep 2002 01:20:07 -0400
> Subject: [Mspgcc-users] Looks like compiler bug
> Reply-To: mspgcc-users@lists.sourceforge.net
>
> Hello,
>
> Looks like compiler generated buggy code when it handles "unsigned long
int"
> types:
>
> Following simplified c code produces incorrect comparison code on line
> marked with "**--->"
>
>  while(1) {
>   if(cThreadIndex == cLastThreadIndex) {
>    cThreadIndex = 0;
>   } else {
>    cThreadIndex++;
>   }
>   if((threads[cThreadIndex].m_cThreadFlags & THREAD_FLAG_SLEEPING) == 0) {
>    break;
> **--->  } else if(threads[cThreadIndex].m_dwWakeupTime <= dwCurrentTime) {
>    break;
>   }
>  }
> ------
> Here is the assembly output: (this "restore r15 at the third line from the
> bottom upsets the flag register")
>
> .L6:
>  cmp.b &cLastThreadIndex, &cThreadIndex
>  jne .L9
>  mov.b #llo(0), &cThreadIndex
>  jmp .L10
> .L9:
>  add.b #llo(1), &cThreadIndex
> .L10:
>  mov.b &cThreadIndex, r14
>  mov r14, r15
>  rla r15
>  rla r15
>  add r14, r15
>  rla r15
>  add #threads+8, r15
>  mov.b @r15, r15
>  and.b #llo(1), r15
>  tst.b r15
>  jne .L11
>  jmp .L7
> .L11:
>  mov.b &cThreadIndex, r14
>  mov r14, r15
>  rla r15
>  rla r15
>  add r14, r15
>  rla r15
>  add #threads, r15
>  mov &dwCurrentTime, r13
>  mov &dwCurrentTime+2, r14
>  sub @r15+, r13
>  subc @r15+, r14
>  sub #4,    r15 ; restore r15
>  jlo .L6
> .L7:
>
>
>
> --__--__--
>
> Message: 2
> From: Dmitry <di...@eis.ru>
> Organization: EIS
> To: mspgcc-users@lists.sourceforge.net
> Subject: Re: [Mspgcc-users] Looks like compiler bug
> Date: Thu, 26 Sep 2002 11:16:51 +0400
> Reply-To: mspgcc-users@lists.sourceforge.net
>
> Thanks for reporting this.
> Fixed.
> Please update sources and recompile gcc.
>
> Actually, very exotic case :)
>
> And yesterday, I commited a binutils update. New section ".noinit" added.=
> =2E.
> Vars in this section will not be inited during system start-up.
>
>
> ~d



Reply via email to