where DUMMYSTRUCTNAME is a macro that expands to empty text. Thus LowPart is a member of an anonymous structure. I realize that anonymous structures are not standard C (or C++). However, this program did compile using the previous version of Parallel Studio on VS 2008. I wondered if there was an option I needed to set to activate this extension but after browsing around in the project property sheets I did not see anything.

This is not a big deal for me. I can work around it, of course, by using the union member "u" as in p->u.LowPart. However, I'm wondering if this is an intentional change, or if I'm missing something.

Yes I did use the "Goto Definition" feature of Visual Studio. That's how I located the definition I mentioned earlier... and how I know the macro DUMMYSTRUCTNAME expands to empty text.

You mentioned that you made a simple MFC test program. Note that in my case I'm using plain C, not C++. By this I mean the file I'm compiling has a .c extension. Furthermore I have support for C99 turned on.

The file in question supports a timer abstract type (in C). It has a fairly simply sequence of #include directives. In particular:

#include
#include

I can attach the source file and its header to this message. Note that the file is intended to support mutliple operating systems. However, for purposes of this test I removed an #include related to that support and manually defined appropriate macros. Note also that I previously changed my code to use the 'u' member of the LARGE_INTEGER structure so that it would compile. To illustrate the error I reverted lines 183 and 184 in timer.c to use the anonymous structure. I am getting the "union _LARGE_INTEGER has no field XXX" error on those lines.

As far as options go I don't have anything too unusual activated other than C99 support, as I mentioned. But there are a lot of options so I could be overlooking something. I did check my "Disable Language Extensions" setting and it is set to "No."

Adjuntos:

BTW, I just tried compiling timer.c from the command prompt using a command such as

icl /c timer.c

It compiled fine without the errors I mentioned above. So the issue appears to be related in some way to how I have my project configured. This did work with the earlier version of Parallel Studio + VS2008; when I upgraded to VS2010 and installed Parallel Studio 2011 beta, I just tried rebuilding this project to see what would happen. I don't recall making any changes to any settings at that time.

I may be able to help you, since I encountered similar symptoms while attempting to build PARPACK with the Intel compilers.

In my case, the issue was due to the way that the _LARGE_INTEGER struct is defined in version 7.0 of the Windows SDK (in WinNT.h). Switching back to v6.0A of the Windows SDK was an effective workaround.

Another way to test whether you have the same problem that I ran into (and successfully worked around) is to run the compiler with the -E switch. This will run the source code through the preprocessor, picking up all the include files. Check the result and see whether the definition of _LARGE_INTEGER that you actually pick up ends up looking like this (notice the newly added "s" after the initial struct in the union, as compared with what you would have found in older versions of WinNT.h):

and it compiles ok for me. With /showIncludes, I see that the following files are include. 1> Note: including file: c:\Program Files\Microsoft SDKs\Windows\v7.0A\include\windef.h1> Note: including file: c:\Program Files\Microsoft SDKs\Windows\v7.0A\include\winnt.h

Checking the 7.0A\winnt.h, the "DUMMYSTRUCTNAME" is "empty" if "_MSC_EXTENSIONS" is defined.

If I remove the /D "_MSC_EXTENSIONS" but keep everything else the same, I get the error.

To the earlier poster... I don't have the 6.0A SDK installed on this machine (anymore) so I can't easily test that. Also attempts to compile my code outside of VS2010 (using the command line compiler) seem to work fine so I assume the use of -E would not be too enlightening there. VS2010's "Goto definition" feature reports that DUMMYSTRUCTNAME is blank... even when I'm getting the error. However, perhaps I am being mislead there. Could it be that there is a problem with the interaction between Parallel Studio and VS2010's code browsing features?

Interestingly during my tinkering with the problem just now I got an error from VS2010 that said something like "Intellisense: parameter not allowed." However the error disappeared after a few moments (and I may not be remembering the wording correctly). It was objecting to this C99 declaration:

produces the error under discussion here. I thought I tried that as well, but apparently I was confused. This result suggests an explaination: The use of /Qstd=c99 is disabling support for microsoft extensions (in this case by not defining _MSC_EXTENSIONS). On the face of it that seems like a reasonable thing since I'm asking for a specific standard. However, this behavior is different than before. My project was compiling using VS2008 and the earlier version of Parallel Studio, all with /Qstd=c99 and without expliciting defining _MSC_EXTENSIONS. I wonder... is the older Windows SDK sensitive to _MSC_EXTENSIONS?

In addition it appears that VS2010 is unaware of the significance of /Qstd=c99 since it its code browsing features are acting as if _MSC_EXTENSIONS is defined when, in fact, it isn't.

I don't have a problem with the "new" behavior of /Qstd=c99, although it might be nice to have a way of activating C99 features without simultaneously disabling extensions. It's a little more bothersome to me that VS2010 doesn't seem to know what /Qstd=c99 does.

To Peter's latest comments, "I am able to get it to compile if I explicity define _MSC_EXTENSIONS ... If I remove the /D "_MSC_EXTENSIONS" but keep everything else the same, I get the error."

Yes, this is exactly the behavior I see with Windows SDK v7.0, and if I run through the preprocessor with this version of include files, defining _MSC_EXTENSIONS triggers DUMMYSTRUCTNAME toexpand toan empty string, while omitting a definition for _MSC_EXTENSIONS causes DUMMYSTRUCTNAME to expand to the letter s.

Based on Jennifer Jiang's comment, it may be fixed in SDK v7.0A (as opposed to v7.0), but I haven't tried it yet. Looks like the latest download available today is v7.1 (which I haven't yet tried either).

I was reluctant to suggest defining _MSC_EXTENSIONS, because I didn't look to see what other side effects it might have.