Danny
Mon Aug 08 08:19:00 CDT 2005
What versions of the compiler have this bug? All of them before VS2005? This
seems like a major problem because this type of operation is used all the
time when checking for wrap with unsigned ints. Just have a look through the
PQOAL timer library functions. Is MS being proactive and cheched shipped PB
code to see where else this bug may have caused issues, or will they only do
something as customers find the bugs for them?
Danny
""Russ Keldorph [MS]"" <russellk@online.microsoft.com> wrote in message
news:UmF216DmFHA.940@TK2MSFTNGXA01.phx.gbl...
> Yes, this is a compiler bug. It's being overzealous when folding the CMP
> into the SUB since it's not legal for the GT condition code. This is
fixed
> in newer compilers such as Visual Studio 2005 Beta 2. One workaround, as
> you found, is to disable optimizations. It might also be possible in some
> instances to refactor the code such that the compiler can't perform the
bad
> transformation.
>
> --
> Russ Keldorph
> russellk@online.microsoft.com (Remove the 'online.' from my address to
> reach me.)
>
> This posting is provided "AS IS" with no warranties, and confers no
rights.
> OR if you wish to include a script sample in your post please add "Use of
> included script samples are subject to the terms specified at
>
http://www.microsoft.com/info/cpyright.htm"
> --------------------
> > From: "Danny" <danny@nospam.com>
> > References: <eANjb13kFHA.2904@tk2msftngp13.phx.gbl>
> <B26A44B6-C293-4DF6-89F8-D88DDC27F2BF@microsoft.com>
> > Subject: Re: ARM compiler bug?
> > Date: Thu, 28 Jul 2005 11:45:39 -0400
> > Lines: 108
> > X-Priority: 3
> > X-MSMail-Priority: Normal
> > X-Newsreader: Microsoft Outlook Express 6.00.2800.1506
> > X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2800.1506
> > Message-ID: <uSrjot4kFHA.2156@TK2MSFTNGP14.phx.gbl>
> > Newsgroups: microsoft.public.windowsce.platbuilder
> > NNTP-Posting-Host: 190.36.220-216.q9.net 216.220.36.190
> > Path: TK2MSFTNGXA01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP14.phx.gbl
> > Xref: TK2MSFTNGXA01.phx.gbl microsoft.public.windowsce.platbuilder:22471
> > X-Tomcat-NG: microsoft.public.windowsce.platbuilder
> >
> > Yes I have verified that.You will notice that I print out the value of z
> and
> > it is 0x7FFFFFFF.
> >
> > Your right that x is unsigned (and is really a very positive number),
but
> > the conditions use by the ldr (ldrgt and ldrle) are signed greater than
> and
> > signed less than or equal. It is going to treat the previous conditions
> > flags as if they where signed values and not unsigned values.
> >
> >
> > "anonymous" <anonymous@discussions.microsoft.com> wrote in message
> > news:B26A44B6-C293-4DF6-89F8-D88DDC27F2BF@microsoft.com...
> > > "static unsigned int x = 0x80000000; // Very negative"
> > >
> > > This is an unsigned number and is +2147483648(dec).
> > >
> > > Have you verified that z is actually 0x7FFFFFFF ?
> > >
> > > "Danny" wrote:
> > >
> > > > Hi All,
> > > >
> > > > The following sample code gives me unexpected results.
> > > >
> > > > void FindBug()
> > > > {
> > > > static unsigned int x = 0x80000000; // Very negative
> > > > static unsigned int y = 1; // Positive
> > > > int z = x - y; // z = 0x7FFFFFFF
> > > > if (z > 0) {
> > > > OALMSG(TRUE, (L"z (0x%X) > 0\r\n", z));
> > > > } else {
> > > > OALMSG(TRUE, (L"z (0x%X) <= 0?\r\n", z));
> > > > }
> > > > }
> > > >
> > > > Looking at this code seems that I should get "z (0x7FFFFFFF) > 0",
> > however,
> > > > I actually get "z (0x7FFFFFFF) <= 0?".
> > > > I have attached the generated assembler file below. I have embedded
> some
> > > > comments in the assembler.
> > > >
> > > > 00000 |FindBug| PROC
> > > >
> > > > ; 37 : {
> > > >
> > > > 00000 |$L14233|
> > > > 00000 e52de004 str lr, [sp, #-4]!
> > > > 00004 |$M14231|
> > > >
> > > > ; 38 : static unsigned int x = 0x80000000; // Very negative
> > > > ; 39 : static unsigned int y = 1; // Positive
> > > > ; 40 : int z = x - y; // z = 0x7FFFFFFF
> > > >
> > > > 00004 e59f3024 ldr r3, [pc, #0x24]
> > > > 00008 e5932004 ldr r2, [r3, #4]
> > > > 0000c e5933000 ldr r3, [r3]
> > > > 00010 e0521003 subs r1, r2, r3
> > > >
> > > > ; 41 : if (z > 0) {
> > > > ; 42 : OALMSG(TRUE, (L"z (0x%X) > 0\r\n", z));
> > > >
> > > > -> At this point z = 0x7FFFFFFF (positive number).
> > > >
> > > > 00014 c59f0010 ldrgt r0, [pc, #0x10]
> > > >
> > > > -> We expect the ldrgt to execute but it does not (ldrle does).
> > > > -> The condition for gt are Z = 0, N==V.
> > > > -> Z = 0 We pass the first condition.
> > > > -> N = 0 (bit 31) and V = 1 (overflow from negative to positive) We
> fail
> > the
> > > > second condition.
> > > > -> Therefore, N != V and the ldrgt (>) does not execute, even though
> > that is
> > > > what we expect.
> > > >
> > > > -> Looks like a compiler bug.
> > > >
> > > > ; 43 : } else {
> > > > ; 44 : OALMSG(TRUE, (L"z (0x%X) <= 0?\r\n", z));
> > > >
> > > > 00018 d59f0008 ldrle r0, [pc, #8]
> > > > 0001c eb000000 bl NKDbgPrintfW
> > > >
> > > > ; 45 : }
> > > > ; 46 : }
> > > >
> > > > 00020 e49de004 ldr lr, [sp], #4
> > > > 00024 e12fff1e bx lr
> > > > 00028 |$L14236|
> > > > 00028 00000000 DCD
> > > >
> >
>
|??_C@_1CC@EMHAJMPE@?$AAz?$AA?5?$AA?$CI?$AA0?$AAx?$AA?$CF?$AAX?$AA?$CJ?$AA?5
> > > > ?$AA?$DM?$AA?$DN?$AA?5?$AA0?$AA?$DP?$AA?$AN?$AA?6?$AA?$AA@|
> > > > 0002c 00000000 DCD
> > > >
> >
>
|??_C@_1BO@FIKAIAKN@?$AAz?$AA?5?$AA?$CI?$AA0?$AAx?$AA?$CF?$AAX?$AA?$CJ?$AA?5
> > > > ?$AA?$DO?$AA?5?$AA0?$AA?$AN?$AA?6?$AA?$AA@|
> > > > 00030 00000000 DCD |?y@?1??FindBug@@9@9|
> > > > 00034 |$M14232|
> > > >
> > > > ENDP ; |FindBug|
> > > >
> > > > Danny
> > > >
> > > >
> > > >
> >
> >
> >
>