I'm having trouble getting OpenMP support in Visual Studio 2015.
I've configured the project options to use /openmp (project->properties->C/C++->language->OpenMP support:yes), the code is as follows (very simple code, to test OpenMP):
#include <iostream>
#include <omp.h>
int main(int argc, char* argv[])
{
int n = 0;
#pragma omp parallel
{
std::cout << std::endl << "Hello World!";
}
return 0;
}
Only one thread runs and "Hello World!" is printed only once.
I was able to compile the program with VS2015 Community Version 14.0 Update 1 on Windows 8.1 64bit with OpenMP support.
Below, follow a list of steps that may help:
After create a new project and paste the source code, go to
Project-> Properties -> C/C++ -> Language
Change Open MP Support to Yes(/openmp)
Click Apply
On the left menu, go to Command Line and confirm that /openmp
appears somewhere at the compiler's options.
If it appears, click Ok and build the project.
Before run the program, put a breakpoint at the line:
int n = 0;
Run the the program by clicking on Local Windows Debugger
When the program stops at the breakpoint, go to Debug -> Windows -> Disassembly
Somewhere, near the breakpoint, look for an assembly line like:
call __vcomp_fork (?????????h)
If you find this line, chances are that openmp is ok and running.
Some other checks that can help:
Get a tool from Windows Sysinternals like Process Explorer (GUI) or ListDLLs (command line).
ListDLLs:
With the program stopped at the breakpoint, open task manager and look for the PID of the process.
Open a command prompt and run the command:
listdlls [PID] | findstr -i vcomp
Should appear something like VCOMP140D.DLL or VCOMP140.DLL or VCOMP????.DLL.
If it not appears, probably the compiler couldn't find the openmp dll so you'll have to see if this library is available at some point on your system.
Two last tips that may save your time:
If you change any configuration (e.g. Debug -> Release or x86 -> x64),
check again if Command Line has the /openmp option set ok.
If you try to force the compiler to C language (instead of C++), maybe the pragma:
#pragma omp parallel for
will not work (Update: Apparently this problem does not happen anymore on VS2017).
It shows me the message:
INTERNAL COMPILER ERROR in 'C:\Program Files (x86)\Microsoft Visual Studio 14.0\VC\bin\CL.exe'
Come back the compiler to C++ language and the parallel for will works ok.
Partial answer: I was not able to get the compiler to accept /openmp through the config/GUI, but compiling in console with cl.exe /openmp works.
Related
I just installed visual studio, (not new to coding) and I keep getting an error that goes like "error: unable to open file C:user...main.obj Error code = 0x80070002"
an Image of the error
this error shows up whenever there is something wrong with my code like for example if i do:
#include <iostream>
int main()
{
std::cout << "Hello World!\n";
}
everything runs normal, but if I make a mistake say:
#include <iostream>
int main()
{
std::cout std::cout << "Hello World!\n";
}
I get the error, it's so annoying I don't want to get that error every time there is something wrong with my code the error list bar is enough, what do I do ?
Could you please tell us what version of Visual Studio are you using?
If you are using vs2017 or later, I suggest you could try to use /DEBUG:FULL property in "Linker/Debugging/Generate Debug Info.
I suggest you could refer to the Doc:
When you specify /DEBUG with no additional options, the linker
defaults to /DEBUG:FULL for command line and make file builds, for
release builds in the Visual Studio IDE, and for both debug and
release builds in Visual Studio 2015 and earlier versions. Beginning
in Visual Studio 2017, the build system in the IDE defaults to
/DEBUG:FASTLINK when you specify the /DEBUG option for debug builds.
Other defaults are unchanged to maintain backward compatibility.
Rebuild the program in a different disk or reinstall the VS could be the final solution I think.
When I single-step with the Visual Studio debugger through the following program, no return value is shown in the "auto" window for any of the istringstream method calls.
It shows the return value for vector::size() though.
#include "stdafx.h"
#include <sstream>
#include <vector>
int main()
{
std::vector<char>{}.size(); //<-- debugger shows return value
std::istringstream{"x"}.get(); //<-- no return value shown
std::istringstream{"x"}.good(); //<-- no return value shown
std::istringstream{"x"}.tellg(); //<-- no return value shown
return 0;
}
Of course I run this in "debug" configuration, so the compiler shouldn't be able to optimize the calls away. I created the project using console application wizard without changing any project settings afterwards.
Should I file a bug?
Edit:
Another possibly related issue: I can't F11-step into any of the above istringstream methods. Debugger just steps over them as if I had pressed F10. Again, it works for vector::size().
It turns out that this was an issue of missing debug symbols when dynamically linking to the VC++ runtime. After a default installation of Visual Studio 2017, for instance, debug symbols for the VC++ runtime are not available.
Possible solutions:
statically link to the VC++ Runtime (project properties > C/C++ > Code Generation > Runtime Library: Multithreaded-Debug)
enable Microsoft symbol server (Extras > Options > Debugging > Symbols > Check "Microsoft Symbol Server" and enter directory for storing symbols in the edit control below)
I think the issue did not occur for std::vector because it is header-only, so the code gets linked directly into the program executable. For the C++ stream library, much of the code actually is inside a VC runtime DLL.
When I use string variables in Eclipse CDT (MinGW compiler) and I run the program, it doesn't show me anything. Here's my code:
#include <iostream>
using namespace std;
int main() {
string hw = "Hello, world!";
cout << hw << endl;
return 0;
}
So that doesn't show anything, but when I just do cout << "Hello, world!" << endl; it does work.
I also tried including <string>, <string.h>, "string" and "string.h" but still no success. The same code does work in VC++ and Codeblocks though.
I can reproduce this problem on my machine. The output does not appear. But it is not an output problem, but actually two problems before you get to main:
The program is failing to launch. If you try double-clicking on it in Windows Explorer, you will get an error message like this:
The program can't start because libgcc_s_dw2-1.dll is missing from
your computer. Try reinstalling the program to fix this problem.
Screenshot of above:
When launched from within Eclipse, this error message is silently swallowed, so how are you supposed to know!
Solutions/Workarounds
You need to get the environment correctly set up to launch the MinGW program because its DLLs are not installed on Windows PATH or other standard places DLLs are searched for.
Add C:\MinGW\bin to your PATH
Launch Eclipse from within a MinGW shell (has basically same effect as 1)
Run the program in debug mode, this causes the program to be launched as a child of GCC and that sets up
Other options (not tried by me) may include statically linking the offending library, see The program can't start because libgcc_s_dw2-1.dll is missing
File a CDT bug about the error message being hidden.
Extra info
If your program compiles, as I am sure it does based on your comments, changing the includes is probably irrelevant.
By adding an infinite loop around the couts I could immediately identify something more than simply an output not being shown was going on. Try the same thing on your machine, and also try running the program from within MinGW shell and from outside it.
I am trying to move the code from a preliminary project to a new project (both made under Visual Studio 2012).
The original one has been made as a console application and I want the new to be a Windows application. I created an empty project and moved the files/set the library paths.
It is a simple OpenGL program with shaders.
EDIT:
It happens that even when I switch back to creating a Console application with the same .vcproj properties, I have a fatal error on Release and Debug.
You can find them below.
Why does my program crash? All the library paths are set just fine because it's the same settings used for a previous project with the same files that DID work (in a different solution).
Errors
Release crash location (outside a #ifdef _DEBUG in the dbghook.c
file)
int _debugger_hook_dummy;
__declspec(noinline)
void __cdecl _CRT_DEBUGGER_HOOK(int _Reserved)
{
/* assign 0 to _debugger_hook_dummy so that the function is not folded in retail */
(_Reserved);
_debugger_hook_dummy = 0;
}
Debug crash location (fread.c) - a pop-up error window appears
(Debug assertion failed):
_VALIDATE_RETURN((stream != NULL), EINVAL, 0);
After cutting my source file in parts, I managed to debug this. The problem was not the port (sorry).
I had minor issues dealing with the location of the executable: Visual Studio puts them by default in SolutionDir/DebugorRelease while I was looking for them in ProjectDir/DebugorRelease.
But the main problem came from a change of function.
There is a side file I use to load textures, which is pretty old and uses fopen to open files.
Following the warnings I got, I changed all the fopen occurrences to fopen_s, with all necessary modifications. That's the precise line where the program crashed.
I put back the fopen version, checked the file locations, and it went back to executing (not in Visual Studio but through command line only, like the original project). That's for the Console Application.
To make it a Windows Application, the following line does the job, and this time, though command-line-only, it works for real.
#pragma comment( linker, "/subsystem:\"windows\" /entry:\"mainCRTStartup\"" )
I wrote this small C++ program and built it(Release)
#include<iostream>
int main(){
std::cout<<"Hello World";
return 0;
}
When I disassemble it, it has a lot of extra code(security cookie etc..). I believe Visual Studio is adding all those. How can I compile this program without any extra information, so that its easy to understand its disassembled code?
I know assembly is comparatively harder, but what I mean is getting a hello world asm code out of a hello world c++ program. Is this possible?
You're starting with a huge code base with <iostream>. What you might want to do is avoid the use of a runtime library entirely. Try something like this:
#include <windows.h>
int main() {
HANDLE stdout = GetStdHandle(STD_OUTPUT_HANDLE);
WriteFile(stdout, "Hello world\n", 12, NULL, NULL);
return 0;
}
Compile that with assembly listing turned on, and that should give you some "raw" Win32 code to start with.
you can generate assembly output in Project Properties -> Configuration Properties -> Output Files -> Assembler Output
This will let you see the assembly for the code you wrote.
Diassembling, you are going to get a bunch of other things that are linked in.
To control visual studio code generation features, rigth click on your project in VS -> properties -> Configuration properties -> c/c++ -> code generation.
Don't forget to select the right build configuration (debug, release, etc...).
The security cookies can be removed by playing with the buffer security check (/GS by default)