| T O P I C R E V I E W |
| BINK Software |
Posted - Nov 04 2009 : 05:58:16 AM
Hi,
We are using Intel Parallel Studio with Visual Studio 2005 for a C++ project that makes use of OpenCASCADE. When the project is set to use Visual C++, VA X is of huge help. It finds everything, making it really easy to navigate through the code. However, when the solution is switched to make use of Intel C++ through Intel Composer, VA X does not gather as much information as before.
It is not like it does not work anymore, it just fails to be as informative as it is when using plain Visual C++.
Is it a known issue, or, even better, is there a known solution?
Thanks,
Paul. |
| 15 L A T E S T R E P L I E S (Newest First) |
| sean |
Posted - Nov 19 2009 : 03:40:32 AM
That's odd. Thanks for experimenting. Could you please generate a log of the load of the solution and send it in? Instructions are here: http://docs.wholetomato.com?W305 |
| BINK Software |
Posted - Nov 19 2009 : 02:43:40 AM
quote:
Originally posted by sean
You previously wrote "When I am NOT using Intel C++, VA shows the correct information in both the context and definition fields for any #include file."
Does the dummy project work when you are not using Intel C++?
That is, does it look like the switch to Intel C++ is breaking the dummy project even though it is not wrapped by an Intel project?
It looks like just the fact that some of the projects are wrapped by an Intel project is enough to make VA fail to find the information for the include paths. I was sure the dummy project was a plain Visual C++ project without being wrapped, but it did not help. I get the reasoning behind the suggestion, but there seems to be something else that makes it fail. Just in case, the dummy project was second in the list (it was preceded by another project that was wrapped).
A couple of minutes later...
I just tried renaming the dummy project to something that would make it the first one, and that seems to do the trick. According to that, VA fails to retrieve the include paths once the first icproj file is reached. |
| sean |
Posted - Nov 19 2009 : 12:45:09 AM
You previously wrote "When I am NOT using Intel C++, VA shows the correct information in both the context and definition fields for any #include file."
Does the dummy project work when you are not using Intel C++?
That is, does it look like the switch to Intel C++ is breaking the dummy project even though it is not wrapped by an Intel project?
|
| BINK Software |
Posted - Nov 17 2009 : 02:07:05 AM
quote:
Originally posted by sean
Are you able to add a dummy standard VC++ project to the solution that is not wrapped by an Intel project? If so, then a workaround would be to specify the additional include directories in that project and have it excluded from the build process.
I added the dummy project with the include paths I need, but VA did not seem to find anything that way. The path was correct as I did not get any errors about not finding the header file I included in a dummy file for that dummy project when trying to compile it, but VA still would not know about it. |
| sean |
Posted - Nov 16 2009 : 8:43:32 PM
Are you able to add a dummy standard VC++ project to the solution that is not wrapped by an Intel project? If so, then a workaround would be to specify the additional include directories in that project and have it excluded from the build process. |
| feline |
Posted - Nov 16 2009 : 6:50:25 PM
I have reproduced this problem here using a trial version of the Intel Parallel Composer:
case=35743
thank you for your clear description of the problem. |
| feline |
Posted - Nov 09 2009 : 12:59:01 PM
I have emailed you about this. |
| BINK Software |
Posted - Nov 09 2009 : 01:41:55 AM
quote:
Originally posted by feline
The context and definition field content shows that VA does not know where to look for this "problem" header file. But I am not sure why. If VA was not parsing the vcproj file then it would not know which files the solution contained.
When you are not using Intel C++ does VA show the correct information in the context and definition fields for this #include line?
If you turn off Intel C++ and go into the project properties, how are you telling the IDE about this additional include directory? Are you just using the standard C++ additional include directories setting in the project settings? Is this done with a simple path, some form of environment variable, or something else?
When I am NOT using Intel C++, VA shows the correct information in both the context and definition fields for any #include file.
The additional include directory is specified in the project properties (C/C++ -> General -> Additional Include Directories). When using Intel C++ it does not change at all. The path with the problematic header files is the first one in there, and it's specified in the form: \\\\SERVER\\PATH\\TO\\OCC\\inc, which works just fine when using Visual C++ as compiler. No environment variables are used for it. |
| feline |
Posted - Nov 06 2009 : 1:34:19 PM
The context and definition field content shows that VA does not know where to look for this "problem" header file. But I am not sure why. If VA was not parsing the vcproj file then it would not know which files the solution contained.
When you are not using Intel C++ does VA show the correct information in the context and definition fields for this #include line?
If you turn off Intel C++ and go into the project properties, how are you telling the IDE about this additional include directory? Are you just using the standard C++ additional include directories setting in the project settings? Is this done with a simple path, some form of environment variable, or something else? |
| BINK Software |
Posted - Nov 06 2009 : 01:45:50 AM
Placing the caret in one of those header files shows the name of the opened file in Context and nothing in Definition. Doing the same thing for <vector> shows vector in Context with the globe icon, and C:\\Program Files\\Microsoft Visual Studio 8\\VC\\include\\vector in Definition.
Could it be that VA is trying to look for that information in the icproj file instead of the vcproj file that it 'includes'?
This is an example of an icproj file:
quote:
<?xml version="1.0" encoding="Windows-1252"?>
<VisualStudioProject
ProjectType="Intel C++ Project"
Version="11.1"
Name="NAME"
ProjectGUID="GUID"
VCNestedProjectGUID="GUID"
VCNestedProjectFileName="NAME.vcproj">
<Configurations>
<Configuration
Name="Debug Unicode|Win32">
<Tool
Name="CppCmplrTool"
Cpp0xSupport="true"/>
</Configuration>
<Configuration
Name="Release Unicode|Win32">
<Tool
Name="CppCmplrTool"
Optimization="1000"
GlobalOptimizations="true"
InterproceduralOptimization="2"
GenerateAlternateCodePaths="2"
Parallelization="true"
UseIntelOptimizedHeaders="true"
Cpp0xSupport="true"/>
</Configuration>
</Configurations>
<Files/>
</VisualStudioProject>
NAME and GUID are of course those of the specific project, and the trick is to read all information from the file specified in the tag <VCNestedProjectFileName>. The icproj file only stores Intel specific information, everything else remains in the vcproj file. |
| feline |
Posted - Nov 05 2009 : 7:47:52 PM
Can you place the caret into the file name on the #include line for one of these header files please. What, if anything, does VA shown in its context and definition fields?
What happens when you place the caret into a "standard" #include file name, e.g.
#include <vector>
VA should show the file name and the full path to the header file. If this information is not displayed then it is probably because VA cannot see / find the setting that tells it about this library include path, which would explain the problems you are seeing. |
| BINK Software |
Posted - Nov 05 2009 : 01:49:58 AM
The number reported by VA is 563 when using Intel C++, which looks about right. If I change to Visual C++, the number is the same.
The problem is not really with the code I've written, but with the one that is included from an external library (OpenCASCADE). When using Intel C++, VA fails to detect many of the declarations from it. However, if I use Visual C++'s "Go To Declaration", VA parses the file once it opens, and all declarations in it become available to VA.
The library is located in a shared network folder, and its path is specified in the settings of those projects that make use of it. The path has been specified using the \\\\server\\path\\to\\include format. It would be hard to argue that that is the reason it has problems finding all the declarations because it actually finds some of them, and, as far as I know, all of them when using Visual C++ only.
Just another thing: if I Ctrl-LeftClick on the filename of a #include for one of OpenCASCADE's header files, nothing happens when using Intel C++. If using Visual C++, it works. That suggests VA is indeed having problems locating those files. |
| feline |
Posted - Nov 04 2009 : 3:21:41 PM
Can you turn on using the Intel Parallel Composer and then restart the IDE.
Now how many files do you have in your solution?
If you open VA's Open File in Solution dialog (Alt-Shift-O) the title bar contains two numbers. The first number is the number of files currently listed, which changes as you filter the list. The second number is the total number of files in the list, which is normally the number of files in your solution. What is this second number? More specifically, is this second number correct?
I suspect VA does not know anything about, or how to parse icproj files, so any information in these is probably invisible to us. But this does not explain why problems start showing up. |
| BINK Software |
Posted - Nov 04 2009 : 09:14:16 AM
quote:
Originally posted by feline
I am not aware of any known problems with Intel Parallel Composer, but I don't recognise this product either.
What are you changing? Where is this option? Are you just changing a project setting, or are you changing something more "basic"?
What sort of problems are you seeing?
It almost sounds like VA can no longer find all of the code that you are working with and on, so it does not parse it. If there is code VA is not parsing, it won't be able to offer you any help with it.
All I am doing is right clicking on the solution, selecting "Intel Parallel Composer" and then "Use Intel C++...". It makes the solution use the icproj files instead. All the tree shows extra is a purple icon as child of the solution and with the Visual C++ project as a child of it (the purple icons represent the icproj file).
After doing that I just set a few Intel specific settings, but all other settings remain exactly the same.
It indeed looks like VA is having problems finding all files, but no new paths are changed in the process or any Visual C++ specific settings.
Maybe you can reproduce the issue by using an evaluation version of Intel Parallel Composer.
The kind of problems I find include: pieces of code underlined in red that are not errors, wrong type solving (specially with the Handle macro from OpenCASCADE), types not being recognized and such. |
| feline |
Posted - Nov 04 2009 : 09:02:00 AM
I am not aware of any known problems with Intel Parallel Composer, but I don't recognise this product either.
What are you changing? Where is this option? Are you just changing a project setting, or are you changing something more "basic"?
What sort of problems are you seeing?
It almost sounds like VA can no longer find all of the code that you are working with and on, so it does not parse it. If there is code VA is not parsing, it won't be able to offer you any help with it. |
|
|
