GCC 4.8 seems to have added Clang-like error message display, e.g. like this:
player.c:725:9: warning: variable ‘delta’ set but not used [-Wunused-but-set-variable]
int delta, rdelta;
^
I guess some people find this useful, but I find it superfluous, and it makes every error message use three lines of screen-space instead of one, where more error messages could be displayed instead.
Is there any way to turn it off? I've been reading through the GCC documentation, but haven't found it yet, at least. In particular, is there a way to turn it off "by default", so that I don't have to specify some -fno-error-caret or similar option to everything I compile?
It seems I still had the GCC 4.7 documentation installed, so that's why I didn't find the -fno-diagnostics-show-caret option to turn it off.
However, that still doesn't answer the question of how to turn it off by default, so I'll keep this question unanswered for quite a while in case anyone has information on that.
Related
I just compiled code using the compiler option "-frecord-gcc-switches" to see which options the compiler selects automatically. Now I can see the options in section .GCC.command.line. There are several plausible compiler options but also one I cannot find any documentation about. What does -auxbase-strip png.o mean. Obviously it does something with png.o, but what does it do exactly?
Google search shows:
Hei Chan:
I am trying to find the document for auxbase and auxbase-strip,
but I can't find any.
Ian Lance Taylor:
They are internal options used to support the -fcompare-debug options.
They are not intended to be used by end users.
So, if you really want to know what this option does, you'll need to read GCC source (but you shouldn't care).
How does one get gcc to not stop compiling after the first error. Is there a compiler flag that will do this?
Basically I'm wanting to remove a class, but i'm not sure how much of an impact that will have, so i'm wanting to determine how many classes would have provblems if i, say, remove the class from the makefile.
Is there a better way to determine this impact?
There's a GCC compiler option -Wfatal-errors to stop after the first error:
-Wfatal-errors
This option causes the compiler to abort compilation on the first error occurred rather than trying to keep going and printing further
error messages
You can also use -Werror if you want to treat warnings as errors so that you'll catch any warning that might be generated when you remove your class.
Is there a better way to determine this impact?
Use the refactoring support, built-in in many IDEs. For example, with NetBeans, you can choose to rename a class and preview all affected places.
Without an IDE, you can rename the class/method/field, instead of deleting it and gradually, with several compilation runs, change all usages of the old name, where the compiler gives an error. Then grep for the new name.
I'm using GCC 4.7.2. My code is rather heavy on template, STL and boost usage. When I compile and there is an error in some class or function that is derived from or uses some boost/STL functionality, I get error messages showing spectacularly hideous return types and/or function arguments for my classes/function.
My question:
Is there a prettyprint type of thing for GCC warnings/errors containing boost/STL types, so that the return types shown in error messages correspond to what I've typed in the code, or at least, become more intelligible?
I have briefly skimmed through this question, however, that is about GDB rather than GCC...
I've also come across this pretty printer in Haskell, but that just seems to add structure, not take away (mostly) unneeded detail...
Any other suggestions?
I asked a similar question, where someone suggested I try gccfilter. It's a Perl script that re-formats the output of g++ and colorizes it, shortens it, hides full pathnames, and lots more.
Actually, that suggestion answers this question really well too: it's capable of hiding unneeded detail and pretty-printing both STL and boost types. So: I'll leave this here as an answer too.
The only drawback I could see is that g++ needs to be called from within the script (i.e., piping to it is not possible at the time). I suspect that's easily fixed, and in any case, it's a relatively minor issue.
You could try STLfilt as mentioned in 'C++ Template Metaprogramming' by David Abrahms & Alesky Gurtovoy.
The book contains a chapter on template message diagnostics. It suggests using the STLFilt /showback:N to eliminate compiler backtrace material in order to get simplified output.
This question already has answers here:
Selectively disable GCC warnings for only part of a translation unit
(4 answers)
Selectively remove a warning message using GCC
(4 answers)
Closed 3 years ago.
On Microsoft compilers, specific warnings can be disabled with a #pragma, without disabling other warnings. This is an extremely useful feature if the compiler warns over something that "has to be done".
Does GCC at this point have a similar feature? It seems like an obvious enough feature that it’s unimaginable that it wouldn't have this feature yet, but older information on the web suggests this feature doesn't exist.
What is one to use in GCC?
Specifically, I like to use multi-character constants, like 'abc'. These evaluate effectively as a base 256 number - a very handy feature, but it triggers a warning. It’s very handy for switching on four character strings in a case statement.
From the GCC manual:
Many options have long names starting with -f or with -W---for example,
-fforce-mem, -fstrength-reduce, -Wformat and so on. Most of these have
both positive and negative forms; the negative form of -ffoo would be
-fno-foo. This manual documents only one of these two forms, whichever
one is not the default.
But if you're asking whether there is a source-level warning disable, I'm not aware if that feature exists in GCC.
-Wno-multichar:
Do not warn if a multicharacter constant ('FOOF') is used. Usually they indicate a typo in
the user's code, as they have implementation-defined values, and should not be used in
portable code.
More information.
Inside the source code, write:
#pragma GCC diagnostic ignored "-Wno-multichar"
// Code with warnings, but they won’t be displayed now...
This question HAS had to be asked before, so it kills me to ask it again, but I can't find it for all of my google and searching stackoverflow.
I'm porting a bunch of linux code to windows, and a good chunk of it makes the assumption that everything is automatically initialized to zero or null.
int whatever;
char* something;
...and then immediately doing something that may leave 'something' null, and testing against 'something'
if(something == NULL)
{
.......
}
I would REALLY like not to have to go back throughout this code and say:
int whatever = 0;
char* something = NULL;
Even though that is the proper way to deal with it. It's just very time consuming.
Otherwise, I declare a variable, and it's initialized to something crazy if I don't set it myself.
This option doesn't exist in MSVC, and honestly, whoever coded your application made a big mistake. That code is not portable, as C/C++ say that uninitialized variables have an undefined value. I suggest setting the "treat warnings as errors" option and recompiling; MSVC should give you a warning every time a variable is used without being initialized.
No - there's no option to do that in MSVC.
Debug builds will initialize them with something else (0xcc I think), but not zero. Unfortunately, your code is bugged and needs fixed (of course this applies only to automatic variables -for statics and globals it's fine to assume they're zero initialized). I'm surprised there was any compiler that supported that behavior - if there's an option to do that in GCC, I haven't heard of it (but I'm no expert in the dusty corners of GCC).
You may hear that an earlier version of MSVC would init variables to zero in debug builds (similar to the way 0xcc is used in VS 2005), but as far as I know that's untrue.
edit ----------
Well, I'll be damned - GCC does (or did?) have the -finit-local-zero option. Looks like it's there mostly for Fortran support, I think.
I'd suggest using compiler warnings about using uninitialized variables to help you catch 99% of your problems. I know it's not a great bit of work, but it should be done if at all possible.
Interestingly, MSVC now does have the ability to do this. The Microsoft Security team wrote a blog post about it here, and there's a CppCon talk here.
Unfortunately, it doesn't seem like this option is exposed to the public. This page lists a bunch of 'hidden MSVC flags', and it includes an option called -initall, so that might be it.
What I ended-up doing was switching to /w4. At this level, it caught most of the "yeah, that's going to be an issue" areas of initialization. Otherwise, there's nothing that can change everything from being 0xcccccccc on initialization to 0x00000000 that I saw.
Massive thanks to everyone for answering this, and yes, we will tighten it up in the future.