g++ and clang++ report compilation errors with the first erroneous line encountered at the top of their output. That is, the first line clang/g++ print on a compilation error are the one you usually care about. As I'm sure we have all experienced, you have to scroll up (often a lot) to see what the nasty error is. Is there any compilation flag (in clang++ or in g++) that presents compilation errors in reverse order?
I saw this question which asked the same thing I'm asking, but about GHC and thought about how much of a useful option this would be for C++ projects. I've never heard of this for clang++ or g++, and I couldn't find anything online nor on their man pages.
Related
Is it possible to 'tell' compiler that if total number of warnings (while compiling a C++ program) are more than say 10 then stop compiling further, and emit an error?
Or is it possible to hack a compiler like clang to provide this functionality.
GCC has two options together would achieve this, from gnu online docs:
-Werror
Make all warnings into errors.
-fmax-errors=n
Limits the maximum number of error messages to n, at which point GCC bails out rather than attempting to continue processing the source
code.
This would make a build with any warnings fail though, the options just define when to stop parsing.
I haven't seen this kind of feature in gcc or clang. You can certainly try to patch it into either of them, both are open source. There is also -Werror (accepted by both compilers) which simply treats warnings as errors.
How about using -Werror to make warnings into errors and -fmax-errors=n to set the limit.
(Also, perhaps making your code completely warning free would be a good thing).
I am compiling a project under VS2012 and GCC (CodeBlocks) for Windows.
On VS2012 everything works perfect. Under GCC I am obtaining the following compiling error:
C:\Users\Piotrek\AppData\Local\Temp\ccfdl0Ye.s|164|Error: invalid use of register|
C:\Users\Piotrek\AppData\Local\Temp\ccfdl0Ye.s|166|Error: invalid use of register|
C:\Users\Piotrek\AppData\Local\Temp\ccfdl0Ye.s|221|Error: invalid use of register|
||=== Build finished: 3 errors, 14 warnings (0 minutes, 0 seconds) ===|
I am using the compiler option -fpermissive - It should have nothing to do with the error.
I just can't understand why is it pointing to a temporary file under the Local Temp folder, and saying that I am using a wrong register??
Does anybody have any idea on what's happening?
It looks like you've encountered a bug in the compiler. The
error messages (judging from the "source" file name) are from
the assembler. The only time the assembler should generate an
error message is when there is something illegal in the
assembler, and the C++ compiler should never generate illegal
assembler; if it can't generate legal assembler, it should
output an error message and fail.
The real problem, when you get this sort of message, is to
figure out what in your code is triggering it. g++ has an
option which tells it to not delete any of the intermediate
files. Use this, then try and see what is going on in the
assember files at these lines. (When you ask g++ to output
assembler, it puts nice comments in to help finding the
corresponding source. I don't know if it also does this when
generating assembler as an intermediate file.) And then try
cutting code (if worse comes to worse, using binary search)
until you can get the error for a program of one or two lines.
Try to guess what's special about them, and change them to do
the same thing, in a different way.
And don't fail to report the error to g++.
Thanks to James Kanze's recommendation, I decided to tell to the compiler not to delete temporary files. This is done by the flag:
-save-temps
As James said, the assembler generates some nice comments which inform exactly which line on our C++ code is throwing the error. In my case, it looks like it is not accepting such instruction:
asm
(
".intel_syntax noprefix\n"
"lock dec [DWORD PTR eax]\n"
".att_syntax \n"
:
: "a" (data)
:
);
I don't know why he is not accepting Intel Syntax anymore, since it was working with previous GCC version, and now that I updated it it doesn't anymore.
Anyway, the solution for such problems is the one mentioned by James: Just dont delete intermediate files so that you can spy directly into Assembly code what's wrong.
About the problem of the INTEL syntax, any idea why it doesn't work anymore?
I want to find out what code causes slow compilation times in gcc. I previously had a code being compiled slowly and someone told me the command-line switch that makes gcc to print each step that it compiles, including each function/variable/symbol and so on. That helped a lot (I could literally see in console where gcc chokes), but I forgot what was the switch.
I found it (from the gcc man page):
-Q
Makes the compiler print out each function name as it is compiled, and print some statistics about each pass when it finishes.
See also this answer to a quite similar question.
You very probably want to invoke GCC with -time or more probably -ftime-report which gives you the time spent by cc1 or cc1plus ... (the compiler proper started by the gcc or g++command) which shows the time spent in each internal phases or passes of the GCC compiler. Don't forget also optimizations, debugging, and warnings flags (e.g. -Wall -O -g); they all slow down the compilation.
You'll learn that for C programs, parsing is a small fraction of the compilation time, as soon as you ask for some optimization, e.g. -O1 or -O2. (This is less true for C++, when parsing can take half of the time, notably since template expansion is considered as parsing).
Empirically, what slows down GCC are very long function bodies. Better have 50 functions of 1000 lines each than one single function of 50000 lines (and this could happen in programs generating some of their C++ code, e.g. RefPerSys or perhaps -in spring 2021- Bismon).
Try the -v (verbose) compilation.
See this link:
http://www.network-theory.co.uk/docs/gccintro/gccintro_75.html
edit:
I understand. Maybe this will help:
gcc -fdump-tree-all -fdump-rtl-all
and the like (-fdump-passes). See here: http://fizz.phys.dal.ca/~jordan/gcc-4.0.1/gcc/Debugging-Options.html
I am trying to compile a c++ program in Linux, using the command in the shell
$ g++ -Wall *.cpp -o prog
and for some reason it keeps on giving me a weird error:
g++: Internal error: Bus error (program cc1plus) Please submit a full
bug report. See for
instructions.
I searched the net for this bus error, and it says that it has to do with something about accessing illegal memory.
Can someone maybe clarify things a bit more for me?
This error message is telling you that there's a bug in the g++ compiler itself.
Try to narrow it down by removing bits and pieces of your source file until the problem goes away. You're not trying to fix your program, you're just trying to find the part that is breaking the compiler. Once you've found it, you can either give a better bug description or you can change your code to work around it.
Or just download the latest version of the g++ compiler and hope that it's already fixed.
Your problem is not in your code, is the compiler (g++) that is crashing and producing that Bus Error, it's possible you have an outdated version of such compiler and need to update, or you're lucky and found a real bug in g++.
I would try compiling each source file separately, to check what part of the source code triggers the error.
Is it possible to instruct GNU c++ compiler to stop after 5 errors found? Can't find this in documentation.
The command-line option -fmax-errors=N directs the compiler to give up after N errors. This option is present in GCC 4.6 and later.
The command-line option -Wfatal-errors directs the compiler to give up after one error. This option is present in GCC 4.0 and later.
In both cases, warnings do not count toward the limit unless you also specify -Werror.
You can use gcc option:
-fmax-errors=5
for this purpose.
I would welcome such an option as well. For now, I'm using the following workaround to get the first five errors:
<make> 2>&1|grep error|head -5
I have to ask why you would want to do this. Sometimes the error that exists in the code is not the first or even found in the first five errors. Sometimes it's beyond that and only is recognizable once you scroll down the list. A better method might be to break up your code and place it into smaller libraries if you're bothered by compile times. Or if you're concerned with things scrolling off the screen of a command line, using the '>>' operator to pipe the messages into a file.