when i build, using this line:
g++ -g -O2 -std=gnu++0x -static *.cpp
And my script had some other options like:
#pragma GCC optimize("O3")
#pragma comment(linker, ”/STACK:36777216“)
__attribute__((optimize("O3"))) void my_func()
{some code}
what will happen ? which one will be kept ?
Attributes or pragmas inside file take priority - so if you mark function with
__attribute__((optimize("O3")))
it will be compiled as if you compile it with -O3 regardless what you passed to gcc e.g. -O0.
Related
If the compiler has some command-line flags and the code has some pragmas that are incompatible with those flags, which one will be used?
To be clearer: I am compiling with g++ -g -O2 -std=gnu++17 -static {files} – GCC version g++ (Ubuntu 9.3.0-10ubuntu2) 9.3.0.
If I write in my code #pragma GCC optimize("Ofast"), will the final code be compiled with -O2 or with -Ofast?
That depends on if it's above or below the pragma.
void this_will_be_compiled_with_O2() { stuff(); }
#pragma GCC optimize("Ofast")
void this_will_be_compiled_with_Ofast() { stuff(); }
Although not explicitly mentioned in the documentation, the description of the #pragma GCC reset_options directive implies that any #pragma GCC optimize directive will override the command line option(s):
#pragma GCC reset_options
This pragma clears the current #pragma GCC target and #pragma GCC optimize to use the default switches as specified on the command line.
I am trying to compile a C++ project and have been asked to use GCC. This works fine and compiles without any problems, but the code generated by GCC is around ten times slower than that produced by G++ even with full optimizations.
Is this because GCC is meant for c-programs or can I do something to make the compiler optimize more?
This is the content in my makefile:
CFLAGS = -std=c++11 -lstdc++ -O3
SRC_PATH=Loki
FILES=bench.cpp bitboard.cpp evaluation.cpp magics.cpp main.cpp misc.cpp move.cpp movegen.cpp
perft.cpp position.cpp psqt.cpp search.cpp thread.cpp transposition.cpp uci.cpp
SOURCES=$(FILES:%.cpp=$(SRC_PATH)/%.cpp)
OUTFILE=Loki.exe
all:
gcc ${SOURCES} -o $(OUTFILE) ${CFLAGS}
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 using GCC version 4.7.2. I create a static library having two files "ctest1.cpp" and "ctest2.cpp".
ctest1.cpp
#include <stdio.h>
#include "ctest2.h"
void ctest1()
{
printf("In ctest1");
ctest2();
}
ctest2.cpp
#include <stdio.h>
void ctest2()
{
printf("In ctest2");
}
The header file "ctest2.h" is,
void ctest2();
And similarly the file "ctest1.h",
void ctest1();
This static library is linked to the following main file "in_test.cpp",
in_test.cpp
#include <stdio.h>
#include "ctest1.h"
using namespace std;
int main()
{
ctest1();
printf("InMain\n");
return 0;
}
I was expecting that after providing proper feedback and enabling -flto, the compiler should have inlined the function call ctest2() in file "ctest1.cpp"(and even call ctest1() in "in_test.cpp"), but it doesn't. Following are the compilation steps that I follow:
g++ -Wall -c -g -O3 -fprofile-generate -ftest-coverage ctest2.cpp ctest1.cpp
ar -rcsv libtest.a ctest2.o ctest1.o
g++ -Wall -g -O3 -fprofile-generate -ftest-coverage in_test.cpp -o checking libtest.a
For training I run the executable n times, then
g++ -Wall -c -g -O3 -flto -fwhole-program -fprofile-use ctest2.cpp ctest1.cpp
ar -rcsv libtest.a ctest2.o ctest1.o
g++ -Wall -g -O3 -flto -fwhole-program -fprofile-use in_test.cpp -o checking libtest.a
I have also tried -fuse-linker-plugin where I gave the path to the gold linker in the compilation command, but the functions were not inlined. I would also like to bring to your notice that when I try this experiment without creation of a static library (with flto and feedback), the compiler inlines the function calls. In that case, I just create one executable out of all the files. This is the reason I was expecting it to work in case of static libraries.
Can someone please tell me what's going wrong here ?
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.