Anonymous structures not supported?

Anonymous structures not supported?

Imagen de Peter Chapin

Hello! Thanks for a great product!

I'm on Windows XP, 32-bit, fully patched; VS2010 Ultimate; Parallel Studio 2011 beta. I have a C program (not C++) that makes use of the LARGE_INTEGER type defined in the Windows API. For example:

LARGE_INTEGER *p;

p->LowPart = 0;

This causes the error message, "error: union _LARGE_INTEGER has no field LowPart." The definition of LARGE_INTEGER looks like (in WinNT.h):

typedef union _LARGE_INTEGER {
    struct {
        DWORD LowPart;
        LONG HighPart;
    } DUMMYSTRUCTNAME;
    struct {
        DWORD LowPart;
        LONG HighPart;
    } u;
    LONGLONG QuadPart;
} LARGE_INTEGER;

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.

In case it matters I have C99 support turned on for this project.

publicaciones de 14 / 0 nuevos
Último envío
Para obtener más información sobre las optimizaciones del compilador, consulte el aviso sobre la optimización.
Imagen de Jennifer J. (Intel)

If the compiler finds the "LARGE_INTEGER" define as youshow, it shouldn't be a problem.

Use "ctrl+j" to see where the .h is coming from. or use "goto definition" to see where the compiler finds it.

As I tried with simple test in a mfc program, it compiles ok.

Jennifer

Imagen de Peter Chapin

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.

Imagen de Jennifer J. (Intel)

Could you paste the header "#include" section of the a.c here? Or the a.c

Jennifer

Imagen de Peter Chapin

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: 

AdjuntoTamaño
Descargar timer.c5.69 KB
Descargar timer.h3.23 KB
Imagen de Peter Chapin

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.

Imagen de sleibman@gmail.com

Hi Peter,

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.

set the WINDOWSSDKDIR environment variable to: "C:\Program Files\Microsoft SDKs\Windows\v6.0A"

and make sure that your include path contains:
C:\Program Files\Microsoft SDKs\Windows\v6.0A\include

Whiich I do by setting my "INCLUDE" environment variable to the following, but your required procedure may differ:

"C:\Program Files (x86)\Intel\Compiler\11.1\054\mkl\include;C:\Program Files (x86)\Intel\Compiler\11.1\054\tbb\include;C:\Program Files (x86)\Intel\Compiler\11.1\054\Include;C:\Program Files (x86)\Intel\Compiler\11.1\054\Include\Intel64;c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\ATLMFC\INCLUDE;c:\Program Files (x86)\Microsoft Visual Studio 9.0\VC\INCLUDE;C:\Program Files\Microsoft SDKs\Windows\v6.0A\include;C:\Program Files (x86)\Intel\Compiler\11.1\054\ipp\em64t\include"

If this works for you, let me know, and I can explain in more detail exactly what's going on....

Steve Leibman
sleibman@alum.mit.edu

Imagen de sleibman@gmail.com

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):

typedef union _LARGE_INTEGER {

struct {

DWORD LowPart;

LONG HighPart;

} s;

struct {

DWORD LowPart;

LONG HighPart;

} u;

LONGLONG QuadPart;

} LARGE_INTEGER;

Imagen de Jennifer J. (Intel)

Thanks Steve for the info about 7.0A\winnt.h.

I used a test program (mfc) to includethecode below:

#include    
#include   

int foo(LARGE_INTEGER *p)
{
	p->LowPart = 10;
	return 1;
}

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.h
1> 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.

So it depends on the compile option you used. I'm using followings:

/Zi /W2 /MP /O2 /Oi /Ot /Oy /D "WIN32" /D "_WINDOWS" /D "NDEBUG" /D "_MBCS" /EHsc /MD /GS /arch:SSE2 /fp:precise /Zc:wchar_t /Zc:forScope /Gd /showIncludes

Jennifer

Imagen de Jennifer J. (Intel)

Correction. the test program is a win32 program, not mfc.

Jennifer

Imagen de Peter Chapin

I am able to get it to compile if I explicity define _MSC_EXTENSIONS. Here are the options being used as reported by VS2010:

/I".." /I"C:\lib\pthread-win32" /Zi /nologo /W3 /O2 /Oi /Qipo /D "_CRT_SECURE_NO_WARNINGS" /D "WIN32" /D "_WINDOWS" /D "_MSC_EXTENSIONS" /D "_UNICODE" /D "UNICODE" /EHsc /MD /GS /Gy /fp:precise /Zc:wchar_t /Zc:forScope /Qstd=c99 /Fp"Release\Gaussian.pch" /Fa"Release" /Fo"Release" /Gd

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:

void gaussian_solve(
    int size, floating_type a[size][size], floating_type *b, int *error, int processor_count );

The error was only transient and I can't reproduce it, but it adds some validity, I think, to the idea that there might be a code browsing issue.

Imagen de Peter Chapin

In a previous post I mentioned that doing

icl /c timer.c

at the command line compiled without error. However, I see that doing

icl /Qstd=c99 /c timer.c

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.

Imagen de sleibman@gmail.com

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.

Cheers,
-Steve

Imagen de Peter Chapin

I'm using the Windows SDK v7.0A. I believe it was installed with VS 2010.

Inicie sesión para dejar un comentario.