Re: Wrong optimisation in Visual C++.net Release Build
From: Michael K. O'Neill (MikeAThon2000_at_nospam.hotmail.com)
Date: 02/04/05
- Next message: Drew Myers: "Maximum size for allocating memory"
- Previous message: Norm Dresner: "Re: Looking for code that can parse C-language declarations to create special data files"
- In reply to: Steffen Bendel: "Re: Wrong optimisation in Visual C++.net Release Build"
- Next in thread: Larry Brasfield: "Re: Wrong optimisation in Visual C++.net Release Build"
- Reply: Larry Brasfield: "Re: Wrong optimisation in Visual C++.net Release Build"
- Messages sorted by: [ date ] [ thread ]
Date: Fri, 4 Feb 2005 13:22:32 -0800
It's not a compiler bug; it's bad code that relies on undefined behavior.
The C++ standard is very clear in not specifying any particular order for
evaluation of arguments for a function call. In fact, function arguments
may generally be evaluated in any order, including interleaved. That's one
reason why you see things like __stdcall and __cdecl (which are attempts to
define ordering).
So, your code is relying on behavior that's simply undefined. You can't
blame the compiler.
See this "Got-cha of the Week" for one of nearly countless articles that
explain this: http://www.gotw.ca/gotw/056.htm
Mike
"Steffen Bendel" <SteffenBendel@discussions.microsoft.com> wrote in message
news:707128AF-962D-4D40-BA23-80A87ED4466D@microsoft.com...
> Cool, thank you.
> There is no need for a workaround, because I do not use this code. (It was
> written for a test 3 years ago. And I was wondering, why my random colors
are
> ever grey). so I will test in in one year again.
>
> "Larry Brasfield" wrote:
>
> > "Steffen Bendel" <SteffenBendel@discussions.microsoft.com> wrote in
> > message news:ED807FE4-7BBD-43BD-8103-E7E856929DFB@microsoft.com...
> > > for the above testing code I created a new Win32 Console Project and
used the
> > > default settings.
> > >
> > > Next try. Now it should compile! (I had forgotten to insert the
includes
> > > coming from the automatically created stdfx.h)
> > >
> > > #include <iostream>
> > > #include <tchar.h>
> > >
> > > int getvalue()
> > > {
> > > static int value=0;
> > >
> > > value += 1;
> > > if (value > 100)
> > > value-=100;
> > >
> > > return(value);
> > > }
> > >
> > > void print(int f1, int f2, int f3)
> > > {
> > > printf("%d %d %d", f1, f2, f3);
> > > }
> > >
> > > int _tmain(int argc, _TCHAR* argv[])
> > > {
> > > print(getvalue(), getvalue(), getvalue());
> > > while(true) {}
> > > return 0;
> > > }
> >
> > Here is the assembler output with /Ox (full) optimization:
> > ========= begin excerpt =====================
> > PUBLIC ?getvalue@@YAHXZ ; getvalue
> > ; COMDAT ?value@?1??getvalue@@YAHXZ@4HA
> > ; File c:\documents and settings\larry\my documents\visual studio
projects\fff\f
> > _BSS SEGMENT
> > ?value@?1??getvalue@@YAHXZ@4HA DD 01H DUP (?) ;
`getvalue'::`2'::value
> > ; Function compile flags: /Ogty
> > _BSS ENDS
> > _TEXT SEGMENT
> > ?getvalue@@YAHXZ PROC NEAR ; getvalue
> >
> > ; 8 : static int value=0;
> > ; 9 :
> > ; 10 : value += 1;
> >
> > mov eax, DWORD PTR ?value@?1??getvalue@@YAHXZ@4HA
> > inc eax
> >
> > ; 11 : if (value > 100)
> >
> > cmp eax, 100 ; 00000064H
> > mov DWORD PTR ?value@?1??getvalue@@YAHXZ@4HA, eax
> > jle SHORT $L13083
> >
> > ; 12 : value-=100;
> >
> > sub eax, 100 ; 00000064H
> > mov DWORD PTR ?value@?1??getvalue@@YAHXZ@4HA, eax
> > $L13083:
> >
> > ; 13 :
> > ; 14 : return(value);
> > ; 15 : }
> >
> > ret 0
> > ?getvalue@@YAHXZ ENDP ; getvalue
> > _TEXT ENDS
> > ========= end excerpt =====================
> >
> > Notice how the conditional branch bypasses saving eax
> > back into 'value', even though that should always be done.
> > This is clearly a bug. This occurred also with the /Ot (time)
> > optimazation, but not with the /Os (space) optimization.
> >
> > The bug is absent in the current beta compiler, so I do not
> > see much point in posting a bug report. The fix might be
> > fixed in a service release of the v7.1 product, someday.
> >
> > Meanwhile, I suggest you use /Os optimization, at least
> > for that function. That is often a better setting for whole
> > programs, even from a speed standpoint once cache
> > (or pagefile) effects are fully operative.
> >
> > --
> > --Larry Brasfield
> > email: donotspam_larry_brasfield@hotmail.com
> > Above views may belong only to me.
> >
> >
> >
- Next message: Drew Myers: "Maximum size for allocating memory"
- Previous message: Norm Dresner: "Re: Looking for code that can parse C-language declarations to create special data files"
- In reply to: Steffen Bendel: "Re: Wrong optimisation in Visual C++.net Release Build"
- Next in thread: Larry Brasfield: "Re: Wrong optimisation in Visual C++.net Release Build"
- Reply: Larry Brasfield: "Re: Wrong optimisation in Visual C++.net Release Build"
- Messages sorted by: [ date ] [ thread ]
Relevant Pages
|
