467,877 Members | 1,124 Online
Bytes | Developer Community
New Post

Home Posts Topics Members FAQ

Post your question to a community of 467,877 developers. It's quick & easy.

Inline function that return static data bug

There seems to be a bug in de VS .net C++ compiler (optimization) when using
inline functions that return static data.

The following code demonstrates this (Win32 console app with ATL support):

#include "stdafx.h"
#include <atltime.h>

int _tmain(int argc, _TCHAR* argv[])
{
CTime nov(2004, 11, 1, 0, 0, 0, 0);
CTime dec(2004, 12, 1, 0, 0, 0 ,0);

printf("nov_month = %d, dec_month = %d\n",
nov.GetMonth(), dec.GetMonth());

return 0;
}

When compiled without optimization the output is:
nov_month = 11, dec_month = 12

But when compiled with optimization the output is:
nov_month = 11, dec_month = 11

Msdn only reports that a comparable bug existed in Visual Studio 6 en not in
Visual Studio .Net but thats not correct I think.
Nov 17 '05 #1
  • viewed: 1710
Share:
5 Replies

"Bert Jansen" <Bert Ja****@discussions.microsoft.com> wrote in message
news:88**********************************@microsof t.com...
There seems to be a bug in de VS .net C++ compiler (optimization) when using inline functions that return static data.

The following code demonstrates this (Win32 console app with ATL support):

#include "stdafx.h"
#include <atltime.h>

int _tmain(int argc, _TCHAR* argv[])
{
CTime nov(2004, 11, 1, 0, 0, 0, 0);
CTime dec(2004, 12, 1, 0, 0, 0 ,0);

printf("nov_month = %d, dec_month = %d\n",
nov.GetMonth(), dec.GetMonth());

return 0;
}

When compiled without optimization the output is:
nov_month = 11, dec_month = 12

But when compiled with optimization the output is:
nov_month = 11, dec_month = 11

Msdn only reports that a comparable bug existed in Visual Studio 6 en not in Visual Studio .Net but thats not correct I think.


Out of curiosity, where's the inline function, and where's the static data?

Jeff F
Nov 17 '05 #2
The ATL CTime implementation uses inline functions and static data.
"Jeff F" wrote:

"Bert Jansen" <Bert Ja****@discussions.microsoft.com> wrote in message
news:88**********************************@microsof t.com...
There seems to be a bug in de VS .net C++ compiler (optimization) when

using
inline functions that return static data.

The following code demonstrates this (Win32 console app with ATL support):

#include "stdafx.h"
#include <atltime.h>

int _tmain(int argc, _TCHAR* argv[])
{
CTime nov(2004, 11, 1, 0, 0, 0, 0);
CTime dec(2004, 12, 1, 0, 0, 0 ,0);

printf("nov_month = %d, dec_month = %d\n",
nov.GetMonth(), dec.GetMonth());

return 0;
}

When compiled without optimization the output is:
nov_month = 11, dec_month = 12

But when compiled with optimization the output is:
nov_month = 11, dec_month = 11

Msdn only reports that a comparable bug existed in Visual Studio 6 en not

in
Visual Studio .Net but thats not correct I think.


Out of curiosity, where's the inline function, and where's the static data?

Jeff F

Nov 17 '05 #3
"Jeff F" wrote:
Out of curiosity, where's the inline function, and where's the static data?

Jeff F

I used the CTime class because that class caused te trouble in my
application ( ATL CTime uses inline functions and static data ).
But maybe the following code demonstrates more directly the effect:

#include "stdafx.h"

static int iStatic;

class CBuggy
{
public:
CBuggy(int iValue);
inline int GetValue();
private:
int _iValue;
};

CBuggy::CBuggy(int iValue) : _iValue(iValue) { }

int CBuggy::GetValue()
{
return (iStatic = _iValue);
}

int _tmain(int argc, _TCHAR* argv[])
{
CBuggy b1(1);
CBuggy b2(2);

printf("b1 = %d, b2 = %d\n", b1.GetValue(), b2.GetValue());
return 0;
}
---
Output is:
b1 = 1, b2 = 1 (but one would expect that b2 = 2).

When the GetValue() function is not inline all goes well.

The only thing that helps is disabling the inline function. The compiler
generates wrong code (even without optimization it seems ).

Assembly output when the function is inline:
mov eax, DWORD PTR _b2$[ebp]
mov DWORD PTR _iStatic, eax
mov ecx, DWORD PTR _b1$[ebp]
mov DWORD PTR _iStatic, ecx
mov edx, DWORD PTR _iStatic
push edx
mov eax, DWORD PTR _iStatic
push eax
push OFFSET FLAT:$SG71576
call _printf

After the instruction that moves eax to address _iStatic, the value of eax
should have been pushed on the stack. But the compiler delays this
instruction until after the second inline function. And than it's too late
because the value of iStatic has already changed again.
Nov 17 '05 #4
Bert Jansen wrote:
"Jeff F" wrote:
Out of curiosity, where's the inline function, and where's the
static data?

Jeff F

I used the CTime class because that class caused te trouble in my
application ( ATL CTime uses inline functions and static data ).
But maybe the following code demonstrates more directly the effect:


Simple repros that don't depend on any libraries are always best.

This bug is fixed in the VC++ 2005 beta.

-cd
Nov 17 '05 #5
I verified that the issue is actually fixed in VC 2005. FYI, I have also
logged this as issue# 583186 for future references.

--------------------
| Thread-Topic: Inline function that return static data bug
| thread-index: AcTZUdo9ajJL33QDTcGYcRwpqfNkVQ==
| X-WBNR-Posting-Host: 195.109.94.235
| From: "=?Utf-8?B?QmVydCBKYW5zZW4=?="
<Be********@discussions.microsoft.com>
| References: <88**********************************@microsoft.co m>
<u8**************@TK2MSFTNGP15.phx.gbl>
| Subject: Re: Inline function that return static data bug
| Date: Fri, 3 Dec 2004 08:05:05 -0800
| Lines: 62
| Message-ID: <01**********************************@microsoft.co m>
| MIME-Version: 1.0
| Content-Type: text/plain;
| charset="Utf-8"
| Content-Transfer-Encoding: 7bit
| X-Newsreader: Microsoft CDO for Windows 2000
| Content-Class: urn:content-classes:message
| Importance: normal
| Priority: normal
| X-MimeOLE: Produced By Microsoft MimeOLE V6.00.3790.0
| Newsgroups: microsoft.public.dotnet.languages.vc
| NNTP-Posting-Host: TK2MSFTNGXA03.phx.gbl 10.40.1.29
| Path:
cpmsftngxa10.phx.gbl!TK2MSFTFEED02.phx.gbl!TK2MSFT NGP08.phx.gbl!TK2MSFTNGXA0
3.phx.gbl
| Xref: cpmsftngxa10.phx.gbl microsoft.public.dotnet.languages.vc:42868
| X-Tomcat-NG: microsoft.public.dotnet.languages.vc
|
| "Jeff F" wrote:
| > Out of curiosity, where's the inline function, and where's the static
data?
| >
| > Jeff F
| >
| I used the CTime class because that class caused te trouble in my
| application ( ATL CTime uses inline functions and static data ).
| But maybe the following code demonstrates more directly the effect:
|
| #include "stdafx.h"
|
| static int iStatic;
|
| class CBuggy
| {
| public:
| CBuggy(int iValue);
| inline int GetValue();
| private:
| int _iValue;
| };
|
| CBuggy::CBuggy(int iValue) : _iValue(iValue) { }
|
| int CBuggy::GetValue()
| {
| return (iStatic = _iValue);
| }
|
| int _tmain(int argc, _TCHAR* argv[])
| {
| CBuggy b1(1);
| CBuggy b2(2);
|
| printf("b1 = %d, b2 = %d\n", b1.GetValue(), b2.GetValue());
| return 0;
| }
| ---
| Output is:
| b1 = 1, b2 = 1 (but one would expect that b2 = 2).
|
| When the GetValue() function is not inline all goes well.
|
| The only thing that helps is disabling the inline function. The compiler
| generates wrong code (even without optimization it seems ).
|
| Assembly output when the function is inline:
| mov eax, DWORD PTR _b2$[ebp]
| mov DWORD PTR _iStatic, eax
| mov ecx, DWORD PTR _b1$[ebp]
| mov DWORD PTR _iStatic, ecx
| mov edx, DWORD PTR _iStatic
| push edx
| mov eax, DWORD PTR _iStatic
| push eax
| push OFFSET FLAT:$SG71576
| call _printf
|
| After the instruction that moves eax to address _iStatic, the value of
eax
| should have been pushed on the stack. But the compiler delays this
| instruction until after the second inline function. And than it's too
late
| because the value of iStatic has already changed again.
|
--
Ayman Shoukry, Visual C++ Team
This posting is provided AS IS with no warranties, and confers no rights.

Nov 17 '05 #6

This discussion thread is closed

Replies have been disabled for this discussion.

Similar topics

47 posts views Thread by Richard Hayden | last post: by
20 posts views Thread by Grumble | last post: by
5 posts views Thread by Martin Vorbrodt | last post: by
5 posts views Thread by Ondrej Spanel | last post: by
13 posts views Thread by jamihuq | last post: by
14 posts views Thread by Frederick Gotham | last post: by
2 posts views Thread by Nagrik | last post: by
1 post views Thread by christian.bau | last post: by
reply views Thread by jack112 | last post: by
By using this site, you agree to our Privacy Policy and Terms of Use.