Compiling Eigen library with nvcc (CUDA) - c++

I tried to compile following program (main.cu) with the nvcc (CUDA 5.0 RC):
#include <Eigen/Core>
#include <iostream>
int main( int argc, char** argv )
{
std::cout << "Pure CUDA" << std::endl;
}
Unfortunately, I get a bunch of warnings and errors I can only explain using nvcc instead of the Microsoft compile.
Is this assumption right?
Is there any way to compile Eigen with nvcc? (I actually don´t want to transfer Eigen matrices to the GPU, just access their members)?
If it should not work to compile Eigen with nvcc, is there a nice guide/tutorial about clever ways to seperate host and device code?
I am using CUDA 5.0 RC, Visual Studio 2008, Eigen 3.0.5. To compile the .cu file I used both, the rules file included in CUDA, aswell as the custom build step produced by CMake. Using the CUDA rule file, I targeted the build at compute capability 3.0.
Thanks for your advice.
PS: If I compile the same code with the host compiler it works perfectly.

NVCC invokes the normal host compiler but not before it has done some preprocessing, so it's likely that NVCC is struggling to parse the Eigen code correctly (especially if it uses C++11 features, but that's unlikely since you say VS2008 works).
I usually advise separating the device code and wrappers into the .cu files and leaving the rest of your application in normal .c/.cpp files to be handled by the host compiler directly. See this answer for some tips on getting this set up with VS2008.

It looks like one of the core contributors to Eigen is porting it to be compatible with CUDA. The idea would be to call it from kernel code.

Starting with Eigen 3.3, nvcc (7.5) succeeds in passing Eigen code to cl (MSVC 2013) (almost?) correctly. For example, the following code produces only 11 warnings:
#include <Eigen/Core>
#include <iostream>
int main()
{
std::cout << "Hello Eigen\t";
std::cout << EIGEN_WORLD_VERSION << "." << EIGEN_MAJOR_VERSION << "." << EIGEN_MINOR_VERSION << "\n";
std::cout << "Hello nvcc\t";
std::cout << __CUDACC_VER_MAJOR__ << "." << __CUDACC_VER_MINOR__ << "." << __CUDACC_VER_BUILD__ << "\n";
return 0;
}
Output as expected (Eigen 3.3rc1):
Hello Eigen 3.2.94
Hello nvcc 7.5.17
But a long list of warnings (see post history if you actually want to see them).
Update:
Unfortunately, using CUDA 8.0 & VS2015 (with both Eigen 3.2.9 & Eigen 3.3rc1) results in compilation errors again:
"operator=" has already been declared in the current scope eigen\src\Core\Block.h 111
"operator=" has already been declared in the current scope eigen\src\Core\Ref.h 89
So close...
Update 2:
This has been fixed in commit 59db051 and is available by either using the development branch or waiting for v3.3 (or 3.3rc2) to actually come out.

Related

Linker hangs when compiling a simple eigen3 program on Win10

I am using the build tools provided by Rtools.
gcc version 8.3.0 x86_64-w64-mingw32 (Built by Jeronen for the R-project)
GNU ld version 2.33.1
eigen version 3.4.0
I have been testing various functions of the eigen package, and when I calculated the singular values using the BDCSVD object, the linker just hangs with full cpu usage. The following line is causing the trouble:
BDCSVD<MatrixXd> svd(m, ComputeThinU | ComputeThinV);
This line of code compiles fine. Just the particular linker does not return. I have waited a few minutes for the linker, but it just won't return.
On the other hand, when I used the latest gcc from the Windows Linux subsystem. Everything worked fine. So is this a known issue? Can it be easily fixed (but still using the build system provided by Rtools in Windows)?
PS: I have encounted this issue several times before, but the cpp files were much more complex, so I wasn't sure back then what caused the hanging linker.
Update:
A code sample is provided below. I configured my Windows copy of eigen3 using the "Unix Makefiles" option, since I do not have Visual Studio and don't want to download it.
Here is the cpp file:
#include <iostream>
#include <Eigen/Dense>
using namespace std;
using namespace Eigen;
int main()
{
double data[9];
for (int i = 0; i < 9; i++)
{
data[i] = i;
}
Map<MatrixXd> m(data, 3, 3);
BDCSVD<MatrixXd> svd(m, ComputeThinU | ComputeThinV);
auto v = svd.singularValues();
cout << "condition #: " << v.maxCoeff() / v.minCoeff() << endl;
}
I was trying to calculate the condition number of a singular matrix here.
Compiled using command line:
g++ -I"my eigen lib" t.cpp -o t.exe
where g++ comes from Rtools, "my eigen lib" is the eigen include directory, t.cpp the cpp file, and t.exe the build target.
Surprisingly or not, when I changed the algo from BDCSVD to JacobSVD, the compilation would succeed, even though BDCSVD defaults to JacobSVD for small matrices.
cc1plus and as both returned normally. ld keeps running forever, it seems.
Edits:
It's been awhile, but I am still looking for an answer.

Check file existence with fstream using x86_64-w64-mingw32-g++ for cross compilation

I have a program that is written in C & C++ and I'm rewriting some parts to improve it. This program has to work with files, but I am not able to check if a file exists on Windows with a cross-compiled exe.
To check if my code was the problem, I have created this simple example:
#include <fstream>
#include <iostream>
int main(){
std::fstream in_file("test.noexists", std::ios::in|std::ios::binary);
if (in_file) {
std::cout << "File exists" << std::endl;
}
else {
std::cout << "File doesn't exists" << std::endl;
}
}
Compiling this code using "x86_64-w64-mingw32-g++", version 8.3-win32 on Debian 10, I'm unable to check if a file exists because it always returns "true". To verify it I have compiled the same program on Linux using g++, and on Windows using mingw64, and both were working so looks like a problem building the project on Debian 10 mingw32.
I don't know if my problem is a bug on Debian version or I am doing something wrong. Anyone knows anything about it?
The only difference I have seen between both, is the version (8.1 on Windows vs 8.3 on Debian), and of course the SO.
Thanks!.
EDIT:
I have upgraded to Debian 11 which has the x86_64-w64-mingw32-g++ v10 and same behavior. I forgot to say that I am using Debian 11 on WSL, not a real Debian distribution. I don't think it matters.
EDIT2:
I have already seen the suggested thread, but the problem is that I want to use streams to manage the files and the only option in that thread also fails. Using any of the other three ways will be like a hack that will not help too much. I think that is not the best way to check the file presence with another example, and then reopen the file later to work with it.
Is supposed that the fstream class have boolean conversion as I have read in several threads and that is why I'm using this example. The Linux version works perfectly, so the function is working as expected. The problem is the Windows version compiled in Linux (cross compiled EXE).
I have tested in_file.good(), in_file.is_open(), in_file.bad(), just in_file... all of them returns like the file was open correctly. Also I have tried ifstream, but same behaviour.
Rest a bit always helps... I have found a workaround to my problem just reading 0 bytes.
#include <fstream>
#include <iostream>
int main(){
std::fstream in_file("test.noexists", std::ios::in|std::ios::binary);
char dummy;
if (in_file.read(&dummy, 0)) {
std::cout << "File exists " << in_file.tellg() << std::endl;
}
else {
std::cout << "File doesn't exists" << std::endl;
}
}
With this, even the cross compiled EXE works without problems.
I still thinking why only fails with the cross compiled EXE, but I was not able to find any info about it and how to fix it. At least this solution is working.
Best regards.

How to properly include Armadillo in CLion (without having false errors)?

When I use the header-only Armadillo C++ library in CLion, the IDE indicates (highlights) multiple (false) errors in the code, however the usage of Armadillo is valid and the code builds and runs without any errors.
For example, in a very simple Armadillo test project, the IDE indicates 3 errors, as written in the comments:
#include <iostream>
#include "armadillo"
using namespace std;
using namespace arma;
int main() {
cout << "Armadillo version: " << arma_version::as_string() << endl;
// Returns 5.0.1 (Ankle Biter)
mat A(2,3); // Error: Too many arguments, expected 0
A.fill(99);
A(1,2) += 101.0; // Error: Called object is not a function
A.print("A = ");
A.set_size(4,5); // Error: Too many arguments, expected 1
A.fill(77);
A.print("A = ");
return 0;
}
Since Armadillo is header-only, I did not modify the default CMakeLists.txt file, only included the main header in main.cpp and copied armadillo_bits to the project directory.
I've tried to configure Armadillo with CMake, but on Windows it seems Armadillo's bundled CMakeLists.txt just copies the includes and creates a config.hpp in my working dir.
Is there a way to index symbols in header-only libraries?
CLion version is 1.0 (141.353), Armadillo version is 5.0.1.
My platform is Windows 8.1 x64, and I'm using MinGW v64 4.9.2 (x86_64-4.9.2-win32-seh-rt_v4-rev2)
The CLion project is available in this repository.
Thanks to anyone trying to investigate this issue.

std::endl crashes Windows 8, compiled using MinGW

I have 3 computers, two of which use Windows 8. Using the latest version of MinGW's g++ (4.8.1-4) my hello world program freezes whenever I compile and run on the Windows 8 computers but not in Windows 7.
#include <iostream>
int main()
{
std::cout << "Hello, World!" <<std::endl;
return 0;
}
This compiles just fine in g++ but running a.exe will display "Hello, World!" then a window will pop up and say "a.exe has stopped working, Windows can check online for a solution to the program...." etc.
Has anybody seen this problem.
Also, I tried "std::cout << "Hello, World!\n" << std::flush;" and this has the same problem. It seems that every function that flushes the buffer causes a crash.
Following Eric's advice, I recompiled the program and ran it in gdb and got the following output:
Program received signal SIGILL, Illegal instruction.
0x00405065 in _Jv_RegisterClasses ()
In the second instance, the '\n' should cause an output flush in any case, although in Windows I believe console output is immediate (or perhaps automatic after a short timeout) in any case without an explicit flush.
I suggest the following experiments:
1) See if it is specific to the C++ library by using the C library (in MinGW Microsoft's C runtime is used rather than glibc):
#include <stdio.h>
int main()
{
printf( "Hello, World!\n" ) ;
return 0;
}
2) Eliminate the exit code by:
int main()
{
return 0;
}
3) No newline at all:
#include <iostream>
int main()
{
std::cout << "Hello, World! ;
return 0;
}
4) Try different compiler options such as optimisation levels, or -fno-builtin for example, or as suggested here: -static-libgcc -static-libstdc++ (although I doubt ``-static-libgcc` will itself have any effect since MinGW uses Microsoft's C runtime DLL and the static library is only available with Microsoft's tools).
I had the same issue and found after a long painful search that I had multiple versions of the mingw provided libstdc++-6.dll on my computer. One was part of the mingw installation the others were part of other installation packages (gnuplot and GIMP). As I had gnuplot in my PATH the compiled mingw exe it would use an older, incompatible version of this dll and crash with the described symptoms. I can, therefore, confirm Dietmar Kühl's suspicion. As suggested above linking the library statically obviously helps in this case as the library functions are included in the exe at compile time.

How do I get PCRE to work with C++?

This is a newbie question but I hope I can express my question as clearly as possible.
I'm trying to do pattern matching in C++.
I've downloaded the Win32 version of PCRE from here and I've placed the downloaded pcre3.dll and pcreposix3.dll files into the folder of Dev-CPP's lib folder (I'm using Bloodshed Dev-C++ 4.9.9 IDE).
I've also downloaded a pcrecpp.h header file and have it in the same directory I'm writing the following code (not writing actually. I'm coping example code from a PDF tutorial named PCRE- Perl Compatible Regular Express).
But I can't get it to work. The code is as follows:
#include <iostream>
#include <string>
#include <pcrecpp.h>
using namespace std;
int main()
{
int i;
string s;
pcrecpp::RE re("(\\w+):(\\d+)");
if (re.error().length() > 0) {
cout << "PCRE compilation failed with error: " << re.error() << "\n";
}
if (re.PartialMatch("root:1234", &s, &i))
cout << s << " : " << i << "\n";
}
When I compile the code, Dev-C++ gives me a lot of errors including: "`pcrecpp' has not been declared" and "RE" undeclared.
How should I deal with the downloaded files and fix my problem? Or is there something obvious that I'm missing?
If you specify the file for #include with angle brackets (<>), then the compiler will only look for that header in the locations for external libraries, in so far as the compiler is aware of them.
If you instead use quotation marks (""), then the compiler will also look in the locations for the current project, which typically includes the current directory.
The quick fix for your current problem is to use
#include "pcrecpp.h"
The alternative is to tell the compiler where it can find the headers of the PCRE library.
You will have to tell the compiler where it can find the headers of the PCRE library.
How to do this differs from build system to build system, but if you are using an IDE, then there should be an option somewhere to specify the 'Include directories'. This is where you add the directory of the PCRE headers (with full path).
As a side-note: When the compiler gives you a large number of errors and warnings, always start with fixing the first one. I would guess that in this case it was something like "unable to find header: pcrecpp.h".
It is often the case that, if the compiler tries to continue after encountering a problem, more problems are found that are follow-on problems of the first one. When the first problem is fixed, these also magically disappear.
g++ -lpcrecpp ......
you need to add '-lpcrecpp' to g++ command
cout << “PCRE compilation failed with error: “ << re.error() << “\n”;
I just copied your code and tried to compile it. I got the same error as you reported.
The problem is that string you put to cout is not properly started/ended. You should use real " instead of marks which looks like double quotes (") but it is not. If you fix it, your code should compile w/o any error.
You have included
#include <pcrecpp.h>
1st point to check But is file in the inlcude path of your code. Did you download the installable ? Check where it has been installed on your machine.
2nd point is to check do you have the library paths defined, so that they can be resolved during compiling and linking.