I've posted this original question, but since it isn't an issue related to CMake, I'm rephrasing it:
I've this example:
#include <iostream>
#include <string>
int main()
{
std::string a("Text");
std::cout << a.c_str() << std::endl;
return 0;
}
which I'm trying to compile with ICC (icc (ICC) 19.1.1.217 20200306, tested using GCC 4.8, 7, 8 and 9 as base) using this line:
icc -o OUT -pedantic-errors -fmax-errors=1 -march=native -Wall -Werror -Wfatal-errors -Wextra -ftree-vectorize -g -Wl,--exclude-libs,ALL -O3 -DNDEBUG -fPIC -fvisibility=hidden -Wstrict-aliasing -std=gnu++17 main.cpp
But it triggers a warning that results in an error (because of -Werror). This is the output when using GCC 8 gcc (GCC) 8.3.1 20190311 (Red Hat 8.3.1-3) as the base compiler:
icc: warning #10193: -vec is default; use -x and -ax to configure vectorization
/opt/rh/devtoolset-8/root/usr/include/c++/8/bits/basic_string.h(5052) (col. 50): error #2102: violation of ansi-alias rules
compilation aborted for main.cpp (code 4)
So, in order to compile, I must remove the -Wstrict-aliasing check. And just like that, there's a whole set of other checks that triggers a similar behavior (warnings from system include files).
My concern is that I'd really like to have those checks in place for my own code, but obviously, not for libraries over which I've no control.
A suggestion was to use -isystem or -isystem=/opt/rh/devtoolset-8/root/usr/include/c++/8, but that only modifies the error:
icc: warning #10193: -vec is default; use -x and -ax to configure vectorization
/lib/../lib64/crt1.o: In function `_start':
(.text+0x20): undefined reference to `main'
And even CMake discourages explicitly the use of -isystem on system include files.
Any ideas of another flag that turns off those warnings for system include files?
Replacing icc by gcc (g++) fixes the issue.
Thanks for your help.
Related
With this code:
enum class profession
{
doctor,
banker
};
class person
{
profession profession;
};
int main()
{
}
on linux (opensuse 15.4 with gcc 11.2), compilation command
g++ -std=c++20 -pedantic -Wall -Wextra -Werror=return-type -Wshadow=local -Wempty-body -fdiagnostics-color -s -Os -o program_gpp program.cpp
I get the error :
error: declaration of ‘profession person::profession’ changes meaning of ‘profession’ [-fpermissive]
while on windows (windows 10 pro, 21h1) / msys2 / mingw-w64 / gcc 12.1, compilation command:
g++ -std=c++20 -pedantic -Wall -Wextra -Werror=return-type -Wshadow=local -Wempty-body -fdiagnostics-color -s -Os program.cpp -o program_gpp.exe
I don't get any warning or error, nothing.
I had already found somewhere that maybe gcc itself is built with different switches for the two platforms, and so its sensibility to some errors changes among them, and this is ok. But since I would like my code to avoid this error and compile everywhere, which gcc switches can I use to force this error also on the gcc on windows / msys2 ? note : I don't want to disable the error on linux (the compiler already tells me that it can be disabled with -fpermissive), I want gcc on windows to give me the error too so that I can fix it there and it will also compile on linux.
Pass -fno-ms-extensions to MSYS2 GCC. This disables some MSVC-esque extensions.
I'm trying to profile a C++ shared library on Windows 10, in order to find which lines the program is spending most time on. (The code happens to form part of an R package.)
I've previously used
AMD µprof and
Very Sleepy. However, I'm now having trouble compiling the code: all these profilers show is which DLL is being used, rather than which function / line.
I suspect that the problem relates to debugging symbol tables being missing. Per
Enabling debug symbols in shared library using GCC, I've ensured that a -g flag is applied when compiling each file, and that there is no -s flag at the linker stage. What else do I need to do to allow µprof / Very Sleepy to tell me which lines of the code are proving a bottleneck?
Detailed compilation notes
I'm using RBuildTools MinGW-w64 v3 g++ 8.3.0 to compile the code on 64-bit Windows 10.
Here are some sample compile commands, which are being generated by R, using Makevars / Makeconf templates.
g++ -std=gnu++14 -I"<<include paths>>" -DNDEBUG -g -O2 -Wall
-mfpmath=sse -msse2 -mstackrealign
-c source_file.cpp -o source_file.o
g++ -shared -static-libgcc -g -Og
-o PackageName.dll tmp.def source_file.o <<Other files>>
-L<<Library paths>>
I've also tried replacing -g with -gdwarf-2 -g3, and adding -fno-omit-frame-pointer, per Very Sleepy doesn't see function names when capturing MinGW compiled file.
Running without shared library
ssbssa suggested running against a simple executable.
I tried:
#include <chrono>
#include <thread>
#include <iostream>
long sumto(long n) {
if(n > 0) {
std::this_thread::sleep_for(std::chrono::milliseconds(1));
return n + sumto(n - 1);
}
return 1;
}
int main() {
std::cout << sumto(1000) << std::endl;
return 0;
}
>"C:/RBuildTools/4.0/mingw64/bin/"g++ -std=gnu++14 -gdwarf-2 -g3 -Og -c test.cpp
>"C:/RBuildTools/4.0/mingw64/bin/"g++ -std=gnu++14 -gdwarf-2 -g3 -Og -o test test.o
test.exe runs as expected. When I profile test.exe, AMD µprof states "The raw file has no data!", whereas VerySleepy does detect activity in sumto and displays the associated source code.
I have a single C++14 file, my.cpp, and from within it I'm trying to use a C99 library called open62541. For the latter, both full source open62541.c/.h and a library libopen62541.a exist. In my.cpp, where I include the open62541.h, I'm using C++ specific code (e.g. iostream), so technically I'm mixing C and C++.
I can get my.cpp to compile successfully by referencing the libopen62541.a:
gcc -x c++ -std=c++14 -Wall my.cpp -l:libopen62541.a -lstdc++ -o out
This outputs no warnings, and creates an executable out.
However, if I try to compile using source code only:
gcc -x c++ -std=c++14 -Wall my.cpp open62541.c -lstdc++ -o out
I get a lot of ISO C++ warnings (e.g. "ISO C++ forbids converting a string constant to ‘char'*") and some "jump to label" errors originating from within open62541.c, resulting in compilation failure.
I can get compilation to succeed by using the -fpermissive switch:
gcc -x c++ -std=c++14 -Wall my.cpp open62541.c -lstdc++ -fpermissive -o out
which still outputs a lot of warnings, but creates the executable successfully. However, I'm unsure if doing this is a good idea.
Perhaps worth mentioning is that open62541.h considers C++ at the beginning:
#ifdef __cplusplus
extern "C" {
#endif
Given that .a library, which comes bundled with the open62541 library code, is supposedly built from the same source, why are the first two approaches not consistent in terms of warnings and errors generated? Why does one work and the other doesn't?
Should one method - linking .a vs referring to .c - be preferred to another? I was under impression that they should be equivalent, but apparently they aren't.
Is using -fpermissive in this case more of a hack that could mask potential problems, and should thus be avoided?
The error (and warning) you see are compilation errors (and warning) output by a C++ compiler when compiling C code.
For instance, in C "literal" has type char[] while in C++ it has type const char[].
Would you get a C++ compiler build libopen62541.a from open62541.c, you would see the same errors (warnings). But a C compiler might be OK with it (depending on the state of that C source file).
On the other hand, when you compile my.cpp and links it against libopen62541.a, the compiler doesn't see that offending C code, so no errors (warnings).
From here, you basically have two options:
Use the procompiled library if it suits you as is
g++ -std=c++14 -Wall -Wextra -Werror my.cpp -lopen62541.a -o out
Compile the library's code as a first step if you need to modify it
gcc -Wall -Wextra -Werror -c open62541.c
g++ -std=c++14 -Wall -Wextra -Werror -c my.cpp
g++ open62541.o my.o -o out
gcc -x c++ -std=c++14 -Wall my.cpp open62541.c -lstdc++ -o out
This command forces the C code in open62541.c to be compiled as C++. That file apparently contains constructs that are valid in C but not C++.
What you should be doing is compiling each file as its own language and then linking them together:
gcc -std=gnu11 -Wall -c open62541.c
g++ -std=gnu++14 -Wall -c my.cpp
g++ -o out my.o open62541.o
Wrapping up those commands in an easily repeatable package is what Makefiles are for.
If you're wondering why I changed from the strict -std=c++14 to the loose -std=gnu++14 mode, it's because the strict mode is so strict that it may break the system headers! You don't need to deal with that on top of everything else. If you want a more practical additional amount of strictness, try adding -Wextra and -Wpedantic instead ... but be prepared for that to throw lots of warnings that don't actually indicate bugs, on the third-party code.
I'm attempting to compile an R package using the Rcpp11 bindings to use a C++11 binary under the hood. I have successfully compiled and used this package on my Mac (OSX 10.9.5, the compiler is clang++):
Apple LLVM version 6.0 (clang-600.0.51) (based on LLVM 3.5svn)
Target: x86_64-apple-darwin13.4.0
Thread model: posix
However, an attempt to compile under 64-bit Red Hat Linux with the g++ compiler version 4.4.7-4 fails because the header or library or namespace called future cannot be found:
In file included from RcppExports.cpp:4:
/path/to/R-libs/3.1/Rcpp11/include/Rcpp.h:50:18: error: future: No such file or directory
As far as I know, future is part of the C++11 specification. I find it odd that several other namespaces are successfully loaded (we successfully make it to the 50th line of Rcpp.h), but future doesn't. Is this due to using an outdated compiler? For reference, I'll attach the actual call to the g++ compiler that fails:
g++ -m64 -std=c++0x -I/usr/include/R -DNDEBUG -I/usr/local/include -I"/path/to/R-libs/3.1/Rcpp11/include" -fpic -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic -c RcppExports.cpp -o RcppExports.o
When Rcpp11 does not compile, it usually means that the compiler is not a C++11 compiler. Previous versions of Rcpp11 used some compromise on what C++11 means, but the next versions won't compromise. C++11 = C++11, not unfinished C++0x.
What makes C++11 and forward great is how all these pieces fit together.
Having a C++11 compiler is the price to pay to use Rcpp11. I see this as a feature.
I'm using MinGw on Windows 7. The following simple program compiles fine, but the linker complains and I do not understand what's wrong:
#include <iostream>
#include <vector>
using namespace std;
int main()
{
std::vector<int> iv;
iv.push_back(7);
cout << iv.back() << endl;
return 0;
}
the compiler/linker messages look as follows:
mingw32-g++.exe -Wall -fexceptions -std=c++0x -Wall -g -std=c++0x -Wall -g -frepo -IC:\cppbuchincludes\include -IG:\Boost -IG:\Users\thomas\cpp\STLUsage\\include -c G:\Users\thomas\cpp\STLUsage\main.cpp -o obj\Debug\main.o
mingw32-g++.exe -o bin\Debug\STLUsage.exe obj\Debug\main.o G:\Boost\stage\lib\libboost_filesystem-mgw45-mt-d-1_45.dll.a G:\Boost\stage\lib\libboost_regex-mgw45-mt-d-1_45.dll.a G:\Boost\stage\lib\libboost_system-mgw45-mt-d-1_45.dll.a G:\Boost\stage\lib\libboost_thread-mgw45-mt-1_45.dll.a G:\Boost\stage\lib\libboost_unit_test_framework-mgw45-mt-d-1_45.dll.a
collect: recompiling G:\Users\thomas\cpp\STLUsage\main.cpp
collect: relinking
collect2: '_ZNSt12_Vector_baseIiSaIiEEC1Ev' was assigned to 'obj\Debug\main.rpo', but was not defined during recompilation, or vice versa
obj\Debug\main.o: In function `vector':
c:/mingw/bin/../lib/gcc/mingw32/4.5.2/include/c++/bits/stl_vector.h:208: undefined reference to `std::_Vector_base<int, std::allocator<int> >::_Vector_base()'
(...and so on...)
I can use templates I defined myself.
I have that MinGw binary from a book and followed the instructions in that book regarding compiler settings. In particular the references to the Boost libs are taken from there.
This must be a simple thing, I just want to make trivial use of the STL.
Edit following the advice given in an answer, I replaced the binary to be used to compile by g++.exe in the Settings -> Compiler and debugging -> toolchain executables dialog, but I'm getting the same error messages (with mingw32-g++.exe now replaced by g++.exe).
Edit (once more) this has to be problem eith the Code::Blocks settings, since compiling using g++ from the command line works just fine.
Use g++ to compile and link the program. mingw32-g++.exe doesn't do that.
FAQ says,
What's the difference between gcc and mingw32-gcc?
The mingw32-gcc, mingw32-g++, etc. binaries exist as an aid to cross development. They are created in a typical build of gcc. They are therefore distributed as the maintainers of GCC meant them to be. The gcc.exe indicates that the binary produces binaries for a target equal to the build, while the mingw32-gcc binary produces binaries to be executed on the mingw32 target.
So I guess the problem is because of mingw32-g++.exe which you're not supposed to use, for normal build.
Try these:
g++ program.cpp //simple build
g++ program.cpp -Wall //build with all warnings enabled
g++ program.cpp -Wall -O2 //enable warnings and optimization level 2
g++ program.cpp -std=c++0x //use C++11 features
Hope that helps.