"exotic case" here can be reffered to gcc internal code generation.
Almost all arithmetic insns use 'indexed with postincrement' for an array
element if possible with later index restore if necessary. For example:
mov @r15+, r10
mov @r15+, r11
If r15 being used and not set afterwards, gcc issues.
sub #4, r15
This is better than
mov @r15, r10
mov 2(r15), r11
cause we win one cycle and 2 bytes in first case.
In the code below the first pattern being used in cmpSI just before jump insn.
the r15 sould be dead or set after jump insn, but gcc does set such a flag to
the register cause of end of function. So, sub #4, r15 being issued just
before jump insn, which clobbers SR.
~d
On Friday 27 September 2002 04:35, Alexey Zaparovanny wrote:
> Thanks for fixing it Dmitry!
>
> Why is that case so special that you called it "exotic case" ?:)
>
> Best regards!
>
> > From: "Alexey Zaparovanny" <[email protected]>
> > To: <[email protected]>
> > Date: Thu, 26 Sep 2002 01:20:07 -0400
> > Subject: [Mspgcc-users] Looks like compiler bug
> > Reply-To: [email protected]
> >
> > 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 <[email protected]>
> > Organization: EIS
> > To: [email protected]
> > Subject: Re: [Mspgcc-users] Looks like compiler bug
> > Date: Thu, 26 Sep 2002 11:16:51 +0400
> > Reply-To: [email protected]
> >
> > 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
>
> -------------------------------------------------------
> This sf.net email is sponsored by:ThinkGeek
> Welcome to geek heaven.
> http://thinkgeek.com/sf
> _______________________________________________
> Mspgcc-users mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/mspgcc-users
--
/********************************************************************
("`-''-/").___..--''"`-._ (\ Dimmy the Wild UA1ACZ
`6_ 6 ) `-. ( ).`-.__.`) Enterprise Information Sys
(_Y_.)' ._ ) `._ `. ``-..-' Nevsky prospekt, 20 / 44
_..`--'_..-_/ /--'_.' ,' Saint Petersburg, Russia
(il),-'' (li),' ((!.-' +7 (812) 3468202, 5585314
********************************************************************/
