I have inherited code, trying to compile with gcc on Linux.
what library am I looking for that has __builtin_ia32_stmxcsr ?
apologies -- i was too fast to submit; running gcc inside of Nvidia Eclipse. actual error message is "Functuion . . . could not be resolved" so i jumped the conclusion i needed to reference some lib. As the offending lines hav a :#if defined(SSE) I take it to mean that the -msse2 switch is present although i cannot seem to find a copyh of the compile command line. [just learning this Eclipse tool -- very new!]
You don't need to link with anything - the "builtin" in the name is a clue that it's a gcc built-in (intrinsic) compiler function.
However you do need to be compiling for an x86 target with SSE enabled for this to be recognised, e.g. gcc -msse2 ....
Note that you can use the _mm_getcsr intrinsic from <xmmintrin.h> instead of __builtin_ia32_stmxcsr - this would be a little more portable.
This is a bug in eclipses indexer with gcc's __builtin* functions. The bug report is at https://bugs.eclipse.org/bugs/show_bug.cgi?id=352537
The problem is that even the glibc/gcc libraries themselves use these __builtin* functions, so eclipse complains about a faulty xmmintrin.h etc., which is of course nonsense.
There is a workaround given in the bug report, you can add the function prototypes as user defined macros for the indexer, but of course this becomes tedious if there are a few more and some type checking abilities are lost.
Related
Good old disconnect between what the compiler deems valid and what the IDE thinks... Before you introduce duplicate questions / answers, I must stress that everything available on the issue here and elsewhere I have already tried and distilled to this setup:
install latest eclipse CDT - Oxygen 4.7.2 / build id 20171218-0600
gcc 6.1 only compiler visible in system path - defaults to c++14 standard without the need for explicit -std flag
Checking the log for compiler settings discovery, it's configured correctly for C++14:
03:51:39 **** Running scanner discovery: CDT GCC Built-in Compiler Settings MinGW ****
g++ -E -P -v -dD C:/dev/eclipse-oxy-cpp/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C
Using built-in specs.
COLLECT_GCC=g++
Target: x86_64-w64-mingw32
Configured with: ../../../src/gcc-6.1.0/configure --host=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --target=x86_64-w64-mingw32 --prefix=/mingw64 --with-sysroot=/c/mingw610/x86_64-610-posix-seh-rt_v5/mingw64 --enable-shared --enable-static --disable-multilib --enable-languages=c,c++,fortran,lto --enable-libstdcxx-time=yes --enable-threads=posix --enable-libgomp --enable-libatomic --enable-lto --enable-graphite --enable-checking=release --enable-fully-dynamic-string --enable-version-specific-runtime-libs --enable-libstdcxx-filesystem-ts=yes --disable-isl-version-check --disable-libstdcxx-pch --disable-libstdcxx-debug --enable-bootstrap --disable-rpath --disable-win32-registry --disable-nls --disable-werror --disable-symvers --with-gnu-as --with-gnu-ld --with-arch=nocona --with-tune=core2 --with-libiconv --with-system-zlib --with-gmp=/c/mingw610/prerequisites/x86_64-w64-mingw32-static --with-mpfr=/c/mingw610/prerequisites/x86_64-w64-mingw32-static --with-mpc=/c/mingw610/prerequisites/x86_64-w64-mingw32-static --with-isl=/c/mingw610/prerequisites/x86_64-w64-mingw32-static --with-pkgversion='x86_64-posix-seh, Built by MinGW-W64 project' --with-bugurl=http://sourceforge.net/projects/mingw-w64 CFLAGS='-O2 -pipe -I/c/mingw610/x86_64-610-posix-seh-rt_v5/mingw64/opt/include -I/c/mingw610/prerequisites/x86_64-zlib-static/include -I/c/mingw610/prerequisites/x86_64-w64-mingw32-static/include' CXXFLAGS='-O2 -pipe -I/c/mingw610/x86_64-610-posix-seh-rt_v5/mingw64/opt/include -I/c/mingw610/prerequisites/x86_64-zlib-static/include -I/c/mingw610/prerequisites/x86_64-w64-mingw32-static/include' CPPFLAGS= LDFLAGS='-pipe -L/c/mingw610/x86_64-610-posix-seh-rt_v5/mingw64/opt/lib -L/c/mingw610/prerequisites/x86_64-zlib-static/lib -L/c/mingw610/prerequisites/x86_64-w64-mingw32-static/lib '
Thread model: posix
gcc version 6.1.0 (x86_64-posix-seh, Built by MinGW-W64 project)
COLLECT_GCC_OPTIONS='-E' '-P' '-v' '-dD' '-shared-libgcc' '-mtune=core2' '-march=nocona'
C:/mingw64/bin/../libexec/gcc/x86_64-w64-mingw32/6.1.0/cc1plus.exe -E -quiet -v -P -iprefix C:/mingw64/bin/../lib/gcc/x86_64-w64-mingw32/6.1.0/ -D_REENTRANT C:/dev/eclipse-oxy-cpp/.metadata/.plugins/org.eclipse.cdt.managedbuilder.core/spec.C -mtune=core2 -march=nocona -dD
#define __STDC__ 1
#define __cplusplus 201402L
(etc)
The following snippet compiles (with unused variable warning but nonetheless), but eclipse highlights issues with resolving test in int main:
auto test (auto N) {return N;}
int main () {
auto z = test( 3U );
return 0;
}
The parser log gives:
Unresolved names:
Attempt to use symbol failed: test in file ...
The IDE shows this in problems:
Invalid arguments '
Candidates are:
? test(?)
'
For all intents and purposes eclipse is in fact seeing the correct gcc binary, and is using the correct c++ standard, but still not conforming to the compiler per evidence above (unless I missed something?).
Any ideas how to make eclipse behave with syntax parsing given it's already got the right c++ standard version?
I get the feeling it's an issue with the indexer rather than the parser, since it has no trouble figuring out the number of arguments or the declaration but can't seem to make sense of functions with auto return type that depends on an auto-typed argument.
UPDATE
It may be related to this bug (looks to be fixed) and this followup bug (still ongoing, test case given is similar to mine).
However, this version of test does not give me problems, so I'm unsure if it's the same bug or something else...
template< typename T > auto test (T N) {return N;}
auto in the parameter type of a function (as opposed to a lambda) is not standard C++14.
It's supported by the Concepts TS (which is supported by GCC >= 6 with the -fconcepts flag), and accepted by GCC >= 4.9 even without -fconcepts as an extension, but it's not standard. (It may become standard in C++20, along with some other parts of the Concepts TS.)
For example, here's what Clang (which does not support this extension) says about your code in C++14 mode:
test.cpp:1:12: error: 'auto' not allowed in function prototype
auto test (auto N) {return N;}
^~~~
Eclipse CDT does not currently implement this extension either. I filed bug 532085 to track adding support for it; contributions are welcome!
does anyone know if there is a way to print the compiler (and its version) that is used when I use the Fortran magic and Cython magic in IPython
For example, like the compiler that was used to build Python: platform.python_compiler()
There are probably better ways to do this, but here are two quick ones.
For Cython, the first thing that came to mind was to make a Cython file that passes the Cython compiler and causes an error at the C level.
Here's a simple one.
cdef extern from "nosuchheader.h":
void myfakefunction(int a, double b)
On my computer IPython shows an error from distutils saying that "gcc failed with exit status 1".
I don't currently use the %%fortran magic, but you should be able to see what f2py is doing based on its output.
f2py usually shows which compiler it is using, both when it searches for a compiler, and when it actually calls the Fortran compiler.
To figure that out, I'd recommend compiling some snippet of Fortran code via f2py and looking at the output.
On my windows machine it shows the output as f2py searches for a Fortran compiler, and prints the lines
'Found executable C:\\mingw64\\bin\\gfortran.exe',
'Found executable C:\\mingw64\\bin\\gfortran.exe',
This tells me it is using gfortran.
Further down in the output it also shows the commands used to build the Fortran source code.
The documentation for the fortran magic mentions how to get verbose output.
If you pass the flag -vvv to the fortran magic, it will print the output from f2py.
You could also try looking at the %fortran_config magic mentioned in the documentation.
I recently followed the instruction on this thread for compiling BLAS and LAPACK as pre-requisites to a SciPy installation. First I got a gfortran error at some point, which recommended that I re-compile LAPACK with -fPIC. So I did this by replacing the -frecursive with -fPIC in makefile.inc (which, I assume is some file the Makefile reads for different compile options) and the error was gone.
Can someone explain more generally what the difference is in compiling something with -fPIC and -frecursive, and how it helped fix the error in my case.
Thanks!
As Soren already commented: -fPIC is totally unrelated to -frecursive. PIC influences how machine code can be positioned inside memory. If you want to compile a library code must be compiled to be relocatable. In other words the code must be able to run regardless of where it is loaded in memory. This question deals with this in more detail.
The -frecursive indeed should be specified if possible. Older implementations of gfortran, e.g. gfortran 4.1.2 on RedHat 5 do not support this option. Currently I haven't seen a workaround, so you have to remove it.
The gfortran documentation describes it as
Allow indirect recursion by forcing all local arrays to be allocated on the stack
In the thread you mentioned, for compilation of the LAPACK library the option -frecursive can be removed. Then the library compiles.
If it works without this feature remains to be seen. Haven't tested yet.
I am using Eclipse Juno with GCC compiler for C code. I am trying to use gcno plugin to get code coverage.
of course I added -ftest-coverage -fprofile-arcs to the compiler and the linker flags.
But, when I click on profiling tools for code coverage I get the error in the image below:
"Recompile at least one of your C/C++ source files with the
"-fprofile-arcs" and "-ftest-coverage" options and link your
executable with "-lgcov". If you compile and link in a single gcc
call, you can use the gcc "--coverage" option. "
Please I need help with this error.
In order to use the gcov code coverage results you must not only compile with the compiler and linker flags you mentions, but you must also either run a unit test or run your program to gather the data. Gcov gathers the data as the points in your code are reached. If you do not run the program you will not generate any data.
Normally with gcc you can specify the level of debugging information with -g and if you use -g3 it will include preprocessor macro definitions in the executable which debuggers like gdb can read and allow you to use during debugging. I would like to do this with nvcc for debugging CUDA programs.
I am currently working by modifying the template program in the SDK so I'm using the default Makefile and common.mk included from the Makefile. In common.mk within the 'ifeq ($(dbg), 1)' block, I have tried the following:
put -g3 under COMMONFLAGS
put -g3 under NVCCFLAGS
put -g3 under CXXFLAGS and CFLAGS
put --compiler-options -g3 under NVCCFLAGS.
The first two give an unrecognized option error. The second two do not seem to do the trick because when I debug using cuda-gdb I don't get the macro information.
The reason I would like to do this is because I would like to inspect some memory using the same macros the program itself uses to access that memory. For example,
#define ARROW(state, arrow) ((c_arrow_t *)(&((state)->arrows) + (arrow) * sizeof(c_arrow_t)))
#define STATE(nfa, state) ((c_state_t *)(&((nfa)->states) + (state) * sizeof(c_state_t)))
are some macros I use to access states and arrows of a non-deterministic finite state automaton.
Thank you for your help!
You probably need to pass both -g to nvcc to set it to build with host debugging, and also pass -g3 to the host compiler via the -Xcompiler (or --compiler-options).
Just an observation, but you really shouldn't be using that SDK makefile for anything. It is truly evil - a crude broken hack on some autotools generated make statements, which is both unnecessarily complex and very inflexible. Even the NVIDIA developers I interact with warn not to use it.