I want to remove a compiler flag for a praticular file in my project. How to do this using #pragma?
Sorry that this is late, but I just ran into the same issue on my project.
I couldn't find a #pragma to modify the list of compiler flags, but I could use GNU Make's ability to modify make variables on a per-target basis.
One of my files was taking forever to compile with -fvar-tracking-assignments (which was added to -O2 a few releases back). I was looking for a way to turn that off for one file; after looking (in vain) for an appropriate pragma, I simply added this line to my makefile to modify CXXFLAGS when compiling and linking those specific files:
ObtuseObj.o ObtuseObjTest.o ObtuseObjTest : CXXFLAGS += -fno-var-tracking-assignments
Hopefully this will be helpful to others!
Only flags that control warnings can be overridden using #pragma, see the diagnostic pragmas documentation page.
For instance, you could do:
#pragma GCC diagnostic ignored "-Wformat"
To make GCC ignore the warnings generated by mismatched formatting strings.
I'm not sure if gcc has such pragmas. I can't find any on the gcc page for pragmas.
If you are asking a question related to gcc next time, tag it under gcc as well. I would tag it but I can't. Tagging under gcc would get you many more responses.
Related
I just restarted working on a project which has been on hold for a few months. Last time I compiled it it was working just fine, without any error nor warning.
Yet when I tried to compile it earlier today I got this warning
attention : ‘template<class _Operation> class std::binder2nd’ is deprecated [-Wdeprecated-declarations]
This warning literally appears hundreds of time when including Eigen/Geometry, which I use all over my project
In file included from [...]/include/Eigen/src/Core/ArrayBase.h:109:0,
from [...]/include/Eigen/Core:350,
from [...]/include/Eigen/Geometry:4,
from [...]/include/[myproject]/types.hh:8,
from [...]/include/[myproject]/voronoi.hh:8
Since then I haven't updated Eigen (is used 3.2.4 which is still the last update today).
However, since last time I compiled it, GCC has been updated to 5.1.0 (I'm using archlinux)
Question:
Is there an issue with gcc 5.1.0 telling me std::binder2nd is deprecated
Should Eigen be updated ?
How can I silent those specific warning without loosing the verbosity of my build ?
ANSWER
I appreas that std::bind2nd is really deprecated and that a commit has been done to solve that in Eigen. This commit is however not yet merged with the master branch :/ (and doesn't solve the issue as some std::bind2nd are still present in Eigen's code)
Bottom line is: Eigen's last stable version is deprecated
Is there an issue with gcc 5.1.0 telling me std::binder2nd is deprecated
No, the C++ standard says it's deprecated in C++11, so if you compile in C++11 mode then it is supposed to be deprecated.
Should Eigen be updated ?
Yes. if it wants to be C++17 compatible, as std::bind2nd doesn't exist post-C++14 at all.
How can I silent those specific warning without loosing the verbosity of my build ?
Suppress the warning. Either compile with -Wno-deprecated-declarations on the command-line or do it in the source when including the Eigen headers:
#pragma GCC diagnostic push
#pragma GCC diagnostic ignored "-Wdeprecated-declarations"
#include <eigen/whatever.h>
#pragma GCC diagnostic pop
Or, as the other answer says, tell GCC to treat the Eigen headers as system headers, which happens automatically if they are in /usr/include, or are included with -isystem, or are included from another header that does:
#pragma GCC system_header
#include <eigen/whatever.h>
How can I silent those specific warning without loosing the verbosity ?
Edit the CMakeLists.txt file. Add this line somewhere after CMAKE_CXX_FLAGS is set.
SET(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wno-deprecated-declarations")
Previous answer mentioned adding this to #pragma or to command line. I am biased against #pragma because I find it hard later on to remember where I put it. So as general practice, I try to avoid #pragma. Adding to command line means you have to remember to type this everytime you recompile.
Instead of using the -I flag to include files use -isystem to include Eigen headers:
g++-5 -isystem/usr/include/eigen3 source_file_here.cpp
This flag is intended for system headers that don't conform to C standards but are considered false positives when warnings are generated. Eigen headers are used much like system headers and thus for most users the warnings are not helpful but merely an annoying false positive.
Credit goes to Ilya Popov's comment in the original question.
I'm interested in answers, approaches, and ideas out of the box. At a high level, the main page is pretty sparse and they mainly list -g, with one level, suggesting that -O0 is also either very helpful or essential.
But I'm wondering what other clang flags can be given to give maximum debugging. Is there an equivalent to gcc's -ggdb3 which includes some of the source or annotations directly in the object output? Or could there be? Is it possible and helpful to recompile the OS and its original libraries to have debugging (and if so, if I'm using Debian, can I have it write the debugging into the main .deb package instead of putting a separate debugged .deb package which stores debugging data in /usr/lib/debug?)? Will a static build of a binary affect the ability to see a good stacktrace? And is there anything that needs to be done to ensure that addr2line works well? Is it needed to compile all libraries (even glibc) with clang to get the maximum debugging benefit? I note that there is a project to recompile Debian with clang, and otherwise am open to a distribution that does so or otherwise places emphasis on debugging.
On Linux there are also options like an LD_PRELOAD set to /lib/libSegFault.so, or a set of LD_LIBRARY_PATH reassignments to /usr/lib/debug instead of the usual /usr/lib location (including redirecting libc itself to the debugged version). Is there a central place or external sources for answers to this question of how to enhance debuggability of a binary? The bigger mystery is clang, since I see in the long gcc man page that there are various options which can increase debugging (or reduce optimisations), but on the other hand the documentation for clang only shows a smaller set. It's possible that clang will accept more options than given, including gcc flags (which may either translate to a no-op or to more debugging - hard to tell without a canonical source of information).
Also from a package build perspective, since an external package may not respect CFLAGS, I've redirected /usr/bin/strip to be a no-op command that always succeeds, but other ideas on ensuring compliance are suggested (I believe that pkgsrc does a good job of wrapping gcc and the linker in shell scripts - useful to insert mandatory flags). Also there may be various ld options that can be passed to increase debugging of the outputted target. Also, it's quite possible that BSD (including FreeBSD 10, based upon clang) may have a different linking architecture which could make it easier to request and find debugged symbols in the generated libraries and executables.
To take debugging more broadly defined, I've set LD_WARN=yes, LD_DEBUG=unused, SEGFAULT_SIGNALS="all", LD_PRELOAD=.../libSegFault.so (as mentioned above), and LD_BIND_NOW=yes. Also I believe I can prefer that gcc search for libraries in /usr/lib/debug - above the standard search paths using strategic -Bs. Also, using --whole-archive for a static build might ensure that more objects are included in the linked output. There's also ulimit -c unlimited, and on Linux a nice way to differentiate core files like:
sysctl -w kernel.core_pattern="core.%t.SIG-%s.PID-%p.ID-%g-%u.%h.%E"
For gcc I've used and seen flags like: -O0 -fno-omit-frame-pointer -fverbose-asm -ggdb3 -mno-omit-leaf-frame-pointer -mtune=generic -fvar-tracking -D_GLIBCXX_DEBUG=1 -frecord-gcc-switches -femit-class-debug-always -fmath-errno -fno-eliminate-unused-debug-symbols -fno-eliminate-unused-debug-types -fno-merge-debug-strings -mieee-fp -mtune=generic -static-libgcc -fexceptions -fvar-tracking -fbounds-check -rdynamic -UNDEBUG -DDEBUG=1 (-ffreestanding -static-libgcc -pass-exit-codes) -fno-stack-check (since I believe I've read that the latter can interfere with debugging)
Other flags are there for other reasons but the emphasis is to be on maximum debugging. With all or most of the above, it's unclear to what extent clang would support or use there, or whether there are other options.
Clang does not support the -ggdb3 flag, only -g, as you have noticed. If you try to use it, you'll get the message:
clang: warning: argument unused during compilation: '-ggdb3'
so you can run your entire command line through Clang and it will tell you which of those GCC flags it supports and which it does not, some will print warnings, others may error out, but Clang will not silently ignore them. Here are the ones that Clang rejected when I tried your long command: -static-libgcc and -pass-exit-codes.
As pointed out in another SO answer, clang -cc1 --help can be used to list supported compilation flags, where we see the following which may be of interest to you:
-disable-llvm-optzns: Don't run LLVM optimization passes
-fno-elide-constructors: Disable C++ copy constructor elision
-mdisable-fp-elim: Disable frame pointer elimination optimization
I'm new to automake, but found my way through the docs and have everything building as I like. However, I currently have CFLAGS="-Wall -Werror" turned on. While this is great for gcc, I'm assuming that someone is going to build my code with a non-gcc compiler. What's the correct way to detect whether GCC is being used and to only set those flags for GCC?
Edit
The solution looks like this:
Download http://www.gnu.org/software/autoconf-archive/ax_check_compile_flag.html and place the macro in your project's ./m4/ directory.
Add the following lines to your configure.ac:
AX_CHECK_COMPILE_FLAG([-Wall], [CFLAGS="$CFLAGS -Wall"], [], [])
AX_CHECK_COMPILE_FLAG([-Werror], [CFLAGS="$CFLAGS -Werror"], [], [])
Edit 2
This macro might also be more useful than -Wall since it does the same for multiple compilers: http://www.gnu.org/software/autoconf-archive/ax_cflags_warn_all.html
You could check whether each flag is supported using an Autoconf macro such as AX_CHECK_COMPILE_FLAG.
Where can I find a list of all available warning and error flags I can set in clang and gcc? I've looked all over both of their respective documentation sites, and I can't find anything.
gcc --help=warnings,seperate
gcc --help=warnings,joined
gcc --help=warnings,undocumented
gcc --help=warnings
seperate flags are like boolean values; they are either on or off.
-Wflag means on. -Wno-flag means off.
joined flags are flags that require a value.
-Wflag=value
by typing gcc --help=warnings you will recieve all the warning options provided by your compiler.
EDIT:
looking at GNU Documentation, these warnings messages have existed since GCC 4.3.6
GCC: http://gcc.gnu.org/onlinedocs/gcc/Option-Summary.html#Option-Summary.
For Clang, there is -Weverything, which enables all warning flags.
The classic: man gcc. clang's manpage is not that populated yet, but since it mimics gcc's behavior anyway, many of gcc's -W options also work with clang.
If the question is just to find the list of all possible GCC diagnostic (error, warning, ...) messages, you could use the catalog of messages for localization utilities. With the GCC source tar ball, look inside gcc/po/ or libcpp/po/ or libstdc++-v3/po/ etc.
If you just ask about the options used to get these messages, follow the link in the answer by Oli Charlesworth
I am trying to build a pass using llvm and I have finished building llvm and its associated components. However, when I run make after following all the steps to build a pass including the makefile, I get the following
relocation R_X86_64_32 against `a local symbol' can not be used when making a shared object; recompile with -fPIC
After tyring to find a fix by googling the error message, I came to know that this is not specific to llvm. A few solutions suggested that I should use "--enable-shared" while running configure but that didn't help my case. Now I want to re-build llvm using fPIC, as the error says. But how do I do this using the makefile?
Looks like you could add the -fPIC (for position-independent code, something you want for a shared library that could be loaded at any address) by setting shell variables:
export CFLAGS="$CFLAGS -fPIC"
export CXXFLAGS="$CXXFLAGS -fPIC"
Looking at Makefile.rules, these will be picked up and used. Seems strange that it wasn't there to begin with.
EDIT:
Actually, reading more in the makefiles, I found this link to the LLVM Makefile Guide. From Makefile.rules, setting either SHARED_LIBRARY=1 or LOADABLE_MODULE=1 (which implies SHARED_LIBRARY) in Makefile will put -fPIC in the compiler flags.
If you are moderately convinced that you should use '-fPIC' everywhere (or '-m32' or '-m64', which I need more frequently), then you can use the 'trick':
CC="gcc -fPIC" ./configure ...
This assumes a Bourne/Korn/POSIX/Bash shell and sets the environment variable CC to 'gcc -fPIC' before running the configure script. This (usually) ensures that all compilations are done with the specified flags. For setting the correct 'bittiness' of the compilation, this sometimes works better than the various other mechanisms you find - it is hard for a compilation to wriggle around it except by completely ignoring the fact you specified the C compiler to use.
Another option is to pass -fPIC directly to make in the following way:
make CFLAGS='-fPIC' CXXFLAGS='-fPIC'