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!
Related
The musl C library has only an approximative implementation of symbol versioning. This can result in symbols being bound together that have different symbol versions, something which would not happen in a full implementation. Projects which expect to be built with musl are therefore better off with avoiding symbol versioning altogether. (Not supporting symbol versioning is by itself not necessarily a bad choice for a toolchain; it all depends on the target audience.)
However, the Alpine Linux toolchain compiles binutils with full symbol versioning support: GAS suppports the .symver directive, and the link editor handles version scripts and assigns symbol versions (just as it would on GNU/Linux). A simple compiler/assembler or linker check shows that symbol versioning is supported. As a result, some of the shared objects which Alpine Linux includes in the distribution do in fact use symbol versioning, although the musl dynamic loader will ignore this data. (The data just bloats the binaries.)
In some cases, software fails to run (after building just fine) because it uses compatibility symbols (symbols without a default version) in ways that are not supported by the musl dynamic linker. Here's a small example of what does not work:
cat > symver.c <<EOF
void
compat_function (void)
{
}
__asm__ (".symver compat_function,compat_function#SYMVER");
void
call_compat_function (void)
{
return compat_function ();
}
EOF
echo "SYMVER { };" > symver.map
cat > main.c <<EOF
extern void call_compat_function (void);
int
main (void)
{
call_compat_function ();
}
EOF
gcc -fpic -shared -o symver.so -Wl,--version-script=symver.map symver.c
gcc -Wl,--rpath=. -o main main.c symver.so
./main
Execution fails with Error relocating ./symver.so: compat_function: symbol not found. It runs successfully without the .symver directive.
How is this combination of binutils support for symbol versioning in combination with a dynamic linker that does not support it supposed to work in practice? Should projects check for a *-musl target triplet and disable symbol versioning?
A run-time check for dynamic linker support would do the job, but it would break cross-compiling. Should this be fixed in Alpine Linux itself, by disabling symbol versioning support in binutils?
I'm working on GCC112 from the compile farm, which is a Linux ppc64-le machine. I'm testing IBM XL C/C++ and catching a compile failure on some AES code that uses POWER8. The code has worked for the last couple of years. The failure is new.
The compile failure is:
$ CXX=xlC make aes-simd.o
xlC -DNDEBUG -g2 -O3 -qrtti -qpic -qarch=pwr8 -qaltivec -c aes-simd.cpp
In file included from aes-simd.cpp:29:
./ppc-simd.h:443:16: error: use of undeclared identifier
'__builtin_crypto_vcipher'; did you mean '__builtin_vec_vcipher'?
return (T1)__builtin_crypto_vcipher((uint64x2_p)state, (uint64x2_p)key);
__builtin_crypto_vcipher is a GCC builtin. The only way to get into that path is if __xlc__ and __xlC__ are not defined:
template <class T1, class T2>
inline T1 VectorEncrypt(const T1& state, const T2& key)
{
#if defined(__xlc__) || defined(__xlC__)
return (T1)__vcipher((uint8x16_p)state, (uint8x16_p)key);
#elif defined(__GNUC__)
return (T1)__builtin_crypto_vcipher((uint64x2_p)state, (uint64x2_p)key);
#else
_ASSERT(0);
#endif
}
Checking preprocessor macros:
$ xlC -qshowmacros -qarch=pwr8 -qaltivec -E aes-simd.cpp | grep -i xlc
#define __XLC_BUILTIN_VAARG__ 1
It looks like nearly all the preprocessor macros have disappeared. A single macro of __XLC_BUILTIN_VAARG__ is not correct.
What happened to the IBM XL C/C++ preprocessor macros, and how do I get them back?
$ xlC -qversion
IBM XL C/C++ for Linux, V13.1.6 (Community Edition)
Version: 13.01.0006.0001
/opt/ibm/xlC/13.1.6/bin/.orig/xlC
IBM XL C/C++ for Linux V13.1.6 does not define __xlc__ or __xlC__ by default, but you can get the compiler to define them by using -qxlcompatmacros. You may be able to make use of the other macros it defines like __ibmxl__; see this Knowledge Center page for more information.
I know the GCC compile farm admins recently upgraded to 13.1.6 at the request of one of XL's other users, but I believe IBM XL C/C++ for Linux (for little endian distributions) has always had this same behaviour.
IBM XL C/C++ for Linux (for big endian distributions) and IBM XL C/C++ for AIX behave differently and define __xlc__ or __xlC__ by default.
My goal has been to create multi-threading programs, and I can not even get a simple thread
to execute ON ECLIPSE CDT. my Tools:
ECLIPSE 3.8.1 CDT
Ubuntu 13.10
I have noticed very similar issues regarding mine. I have tried those other solutions but I could not get them to work for me.
When I type the code in Eclipse CDT, Eclipse does not 'resolve' the symbols 'thread', however, It can find the header file 'thread'. 'Mutex' also does not resolve. Furthermore, after building, I run the program, eclipse returns :
"terminate called after throwing an instance of 'std::system_error'
what(): Enable multithreading to use std::thread: Operation not permitted"
Some additional notes:
I can compile and execute the code in the terminal using:
'clang++ c.cpp -pthread -std=c++11'
but...
'g++ c.cpp -pthread -std=c++11' compiles and
produces the same error as quoted above. So it looks like it's a compiler issue. I did
start to write the code in a new project within Eclipse CDT with the clang++ compiler and now that gives the same non-resolved 'thread' and produces the error as quoted above. So now I think I have some wrong settings, paths or flags set in Eclipse.
include <iostream>
include <thread>
using namespace std;
void p1(){
cout<<"process 1 is processing"<<endl;
}
int main() {
thread t1(&p1);
cout<<"Hello from main()"<<endl;
t1.join();
return 0;
}
I have been struggling with the very same issue and I finally resolved it. Here is what I did:
1) Add -std=c++11 for c++ build. To do that right-click your project, select properties and then: C/C++ Build -> Settings -> GCC C++ Compiler -> Miscellaneous(last option)
In other flags append -std=c++11. My Other flags now looks like: -c -fmessage-length=0 -std=c++11 but yours may be a bit different.
2) Add some linker options. In the same view(C/C++ Build -> Settings) as above select the GCC C++ Linker option and from there go to Miscellaneous(second to last option). Add the following Linker flags(the field was empty for me): -Wl,--no-as-needed -pthread. Hit apply.
3) Add a macro. Again from the project properties menu(project->right click->properties). Navigate to C/C++ General -> Paths and symbols -> Symbols. Select GNU C++. Add a symbol with the name __GXX_EXPERIMENTAL_CXX0X__ and no value. Again hit apply.
4) Navigate to C/C++ General -> Preprocessor Include paths.. Select the providers tab. In this tab leave only the following two options checked: CDT GCC Built-in Compiler Settings and CDT Managed Build Setting Entries. Select CDT GCC Built-in Compiler Settings uncheck the checkbox Share setting entries between projects(global provider) and now the text box labeled Command to get compiler specs should be enabled. In this text box append the good old -std=c++11. The text now looks like this for me ${COMMAND} -E -P -v -dD ${INPUTS} -std=c++11. Hit apply one last time.
5) Rebuild the index for the project. To do that right click the project->Index->Rebuild
Following these steps I was able to compile a c++11 multithreaded program, execute it and also Eclipse CDT did not report any errors and was helpful with the autocompletion. Unfortunately this setting has to be done separately for Release and Debug(or at least I have not found a way to share it). Hope this helps.
I am trying to get started using Rccp and decided to use Eclipse as a development environment since I already use StatEt for R. I am having trouble getting even a simple program to compile and run though, and would appreciate some help!
Briefly I tried to follow the instructions on the blog: http://blog.fellstat.com/?p=170 exactly for setting up Rcpp, RInside and Eclipse, and for the example program. I am running on Mountain Lion, and installed g++ using the command line options in XCode. I think I've faithfully followed all the steps in the blog, but cannot get the program to compile. I think the problem is in the way the header files are included, as indicated from the snippet of the output below. As far as I can tell, line 52 of /usr/include/c++/4.2.1/cstring is an include statement for <string.h> and the compiler includes Rccp/include/string.h instead of the string.h from std that is found earlier on the include path.
I am a novice in C++ so I'd really appreciate some pointers on how to proceed.
-Krishna
16:22:38 **** Incremental Build of configuration Debug for project MyTestRCppPackage ****
Info: Internal Builder is used for build
g++ -DINSIDE -I/Library/Frameworks/R.framework/Versions/2.15/Resources/include -I/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include -I/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp -I/Library/Frameworks/R.framework/Versions/2.15/Resources/library/RInside/include -O0 -g3 -Wall -c -fmessage-length=0 -arch x86_64 -v -o src/main.o ../src/main.cpp
Using built-in specs.
Target: i686-apple-darwin11
Configured with: /private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/src/configure --disable-checking --enable-werror --prefix=/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2 --mandir=/share/man --enable-languages=c,objc,c++,obj-c++ --program-prefix=llvm- --program-transform-name=/^[cg][^.-]*$/s/$/-4.2/ --with-slibdir=/usr/lib --build=i686-apple-darwin11 --enable-llvm=/private/var/tmp/llvmgcc42/llvmgcc42-2336.11~182/dst-llvmCore/Developer/usr/local --program-prefix=i686-apple-darwin11- --host=x86_64-apple-darwin11 --target=i686-apple-darwin11 --with-gxx-include-dir=/usr/include/c++/4.2.1
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00)
/usr/llvm-gcc-4.2/bin/../libexec/gcc/i686-apple-darwin11/4.2.1/cc1plus -quiet -v -I/Library/Frameworks/R.framework/Versions/2.15/Resources/include -I/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include -I/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp -I/Library/Frameworks/R.framework/Versions/2.15/Resources/library/RInside/include -imultilib x86_64 -iprefix /usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/ -dD -D__DYNAMIC__ -DINSIDE ../src/main.cpp -fPIC -quiet -dumpbase main.cpp -mmacosx-version-min=10.8.3 -m64 -mtune=core2 -auxbase-strip src/main.o -g3 -O0 -Wall -version -fmessage-length=0 -D__private_extern__=extern -o /var/folders/hc/vqp48jt56_v332kc3dqyf5780000gn/T//ccqdmOKI.s
ignoring nonexistent directory "/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/../../../../i686-apple-darwin11/include"
ignoring nonexistent directory "/usr/include/c++/4.2.1/i686-apple-darwin11/x86_64"
ignoring nonexistent directory "/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/../../../../i686-apple-darwin11/include"
#include "..." search starts here:
#include <...> search starts here:
/Library/Frameworks/R.framework/Versions/2.15/Resources/include
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/RInside/include
/usr/llvm-gcc-4.2/bin/../lib/gcc/i686-apple-darwin11/4.2.1/include
/usr/include/c++/4.2.1
/usr/include/c++/4.2.1/backward
/usr/local/include
/Applications/Xcode.app/Contents/Developer/usr/llvm-gcc-4.2/lib/gcc/i686-apple-darwin11/4.2.1/include
/usr/include
/System/Library/Frameworks (framework directory)
/Library/Frameworks (framework directory)
End of search list.
GNU C++ version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00) (i686-apple-darwin11)
compiled by GNU C version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00).
GGC heuristics: --param ggc-min-expand=150 --param ggc-min-heapsize=65536
Compiler executable checksum: b37fef824b01c0a99fb2679acf3b04f1
In file included from /usr/include/c++/4.2.1/cstring:52,
from /usr/include/c++/4.2.1/bits/stl_algobase.h:66,
from /usr/include/c++/4.2.1/memory:53,
from /usr/include/c++/4.2.1/tr1/hashtable:56,
from /usr/include/c++/4.2.1/tr1/unordered_map:37,
from /Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/platform/compiler.h:158,
from /Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/RcppCommon.h:26,
from /Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp.h:27,
from ../src/main.cpp:8:
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:52: error: 'internal' has not been declared
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:52: error: typedef name may not be a nested-name-specifier
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:52: error: expected ';' before '<' token
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:65: error: expected `)' before 'charsxp'
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:70: error: expected ',' or '...' before '&' token
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:75: error: expected unqualified-id before '&' token
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:75: error: expected ',' or '...' before '&' token
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:75: error: 'Rcpp::String::String()' cannot be overloaded
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:55: error: with 'Rcpp::String::String()'
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:85: error: 'Rcpp::String::String(int)' cannot be overloaded
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:70: error: with 'Rcpp::String::String(int)'
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:88: error: expected `)' before 'x'
/Library/Frameworks/R.framework/Versions/2.15/Resources/library/Rcpp/include/Rcpp/string.h:89: error: expected `)' before 'x'
There are two entirely separate issues here:
Get all you need for Rcpp installed. OS X aspects should be documented on the relevant page maintained by Simon. If you have the tools, and have Rcpp install, then you should be able to do cppFunction('double nPi(int x) { return x*M_PI; }') which is uses functions supplied with Rcpp to create a callable C++ functions accessible to you as nPi() -- and nPi(2) should return a value.
Your choice of IDE and its settings. This is has little to do with 1. apart from requiring it to work to.
So I would work on 1. and see if I got that sorted out first, and only then turn to 2.
To summarize, the issue I faced was that include files in Rcpp with the sames names as those in std were in conflict. In particular, string.h from Rcpp was being included at a point where string.h from std was the right choice, and, as far as I could tell, this was due to the fact that paths specified via the -I directive are searched prior to the default paths.
I tried many different alternatives to solve this, including removing and re-installing XCode and the associated Command Line tools, as well as installing another g++ compiler using macports. None of these resolved the issue. I then used the -idirafter directive instead of the -I directive for the search path for include files for Rcpp and R. I got this hint from gcc include order broken?. This worked since these directories are now searched after the default paths. This precludes (at least so far!) the possibility that string.h from std and string.h from Rcpp come into conflict.
To get step 5 of http://blog.fellstat.com/?p=170 to work I had to set the -idirafter paths in PKG_CPPFLAGS in the file Makevars.
Thanks to everyone for your suggestions.
You simply have to remove include
/Library/Frameworks/R.framework/Resources/library/Rcpp/include/Rcpp
because it is:
unnecessary, as all R imports are in form <Rcpp/XXX>
causes this issue, as compiler looks for string.h in Rcpp directory (when it shouldn't).
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.