I work at Red Hat on GCC, the GNU Compiler Collection.
My main focus for the last year has been on making GCC easier to use, so I thought I'd write about some of the C and C++ improvements I've made that are in the next major release of GCC, GCC 8. You can easily install GCC 8 on Red Hat Enterprise Linux 6 and 7 using Red Hat Developer Toolset (DTS). GCC 8 is the default compiler in Red Hat Enterprise Linux 8 Beta. GCC 8 is also available in Fedora 28 and later.
Helping you fix silly mistakes
Quick quiz #1
Quick - find the mistake in the following:
int test(void)
{
return 42
}
In earlier releases of gcc, we printed the rather unhelpful:
$ gcc t.c t.c: In function ‘test’: t.c:4:1: error: expected ‘;’ before ‘}’ token } ^
For gcc 8, I've fixed things so that the location of the missing semicolon is properly highlighted:
$ gcc t.c t.c: In function ‘test’: t.c:3:12: error: expected ‘;’ before ‘}’ token return 42 ^ ; } ~
In particular, the error message is now showing the correct line. It also now suggests inserting the missing semicolon via a "fix-it hint", so that an IDE which supports them can offer to fix the issue for you (for example, Eclipse's CDT).
Quick quiz #2
Find the syntax error in:
double MIN = 68.0;
double MAX = 72.0;
int logging_enabled;
extern void write_to_log(double);
extern int check_range(void);
void log_when_out_of_range(double temperature)
{
if (logging_enabled && check_range ()
&& (temperature < MIN || temperature > MAX) {
write_to_log (temperature);
}
}
Older versions of gcc printed:
$ gcc unclosed.c unclosed.c: In function ‘log_when_out_of_range’: unclosed.c:12:51: error: expected ‘)’ before ‘{’ token && (temperature < MIN || temperature > MAX) { ^ unclosed.c:15:1: error: expected expression before ‘}’ token } ^
It's complaining about a missing close-parenthesis, but which open-parenthesis does it correspond to?
gcc 8 now highlights the relevant opening parenthesis:
$ gcc unclosed.c unclosed.c: In function ‘log_when_out_of_range’: unclosed.c:12:50: error: expected ‘)’ before ‘{’ token && (temperature < MIN || temperature > MAX) { ^~ ) unclosed.c:11:6: note: to match this ‘(’ if (logging_enabled && check_range () ^ unclosed.c:15:1: error: expected expression before ‘}’ token } ^
and provides a fix-it hint so that IDEs can offer to automate the fix. (Sadly, I wasn't able to fix that stray extra "expected expression before '}' token" error for gcc 8).
If they're on the same line, it highlights it much more compactly:
$ gcc unclosed-2.c unclosed-2.c: In function ‘test’: unclosed-2.c:8:45: error: expected ‘)’ before ‘{’ token if (temperature < MIN || temperature > MAX { ~ ^~ ) unclosed-2.c:11:1: error: expected expression before ‘}’ token } ^
I've also fixed how we handle:
int i
int j;
for which earlier gcc releases used to print this inscrutable diagnostic:
$ gcc q.c q.c:2:1: error: expected ‘=’, ‘,’, ‘;’, ‘asm’ or ‘__attribute__’ before ‘int’ int j; ^
which was particularly bad if the two lines spanned two different header files.
With gcc 8 it puts the error in the right place, and now prints:
$ gcc q.c q.c:1:6: error: expected ‘;’ before ‘int’ int i ^ ; int j; ~~~
which I find much easier to figure out.
A trick question?
What's wrong with the following code?
const char *test(void)
{
FILE *f;
int limit = INT_MAX;
/* etc */
return NULL;
}
This is a trick question - the code is fine, but, as is common with fragments of code seen on random websites, it's missing #include directives. If you simply copy this into a new file and try to compile it as-is, it fails.
This can be frustrating when copying and pasting examples - off the top of your head, which header files are needed by the above? - so for gcc 8 I've added hints telling you which header files are missing (for the most common cases):
$ gcc incomplete.c incomplete.c: In function ‘test’: incomplete.c:3:5: error: unknown type name ‘FILE’ FILE *f; ^~~~ incomplete.c:3:5: note: ‘FILE’ is defined in header ‘<stdio.h>’; did you forget to ‘#include <stdio.h>’? incomplete.c:1:1: +#include <stdio.h> const char *test(void) incomplete.c:3:5: FILE *f; ^~~~ incomplete.c:4:17: error: ‘INT_MAX’ undeclared (first use in this function) int limit = INT_MAX; ^~~~~~~ incomplete.c:4:17: note: ‘INT_MAX’ is defined in header ‘<limits.h>’; did you forget to ‘#include <limits.h>’? incomplete.c:1:1: +#include <limits.h> const char *test(void) incomplete.c:4:17: int limit = INT_MAX; ^~~~~~~ incomplete.c:4:17: note: each undeclared identifier is reported only once for each function it appears in incomplete.c:8:12: error: ‘NULL’ undeclared (first use in this function) return NULL; ^~~~ incomplete.c:8:12: note: ‘NULL’ is defined in header ‘<stddef.h>’; did you forget to ‘#include <stddef.h>’? incomplete.c:1:1: +#include <stddef.h> const char *test(void) incomplete.c:8:12: return NULL; ^~~~
As before these fix-it hints can be made machine-readable (for use by an IDE) via -fdiagnostics-parseable-fixits, or you can use -fdiagnostics-generate-patch to have gcc emit:
--- incomplete.c
+++ incomplete.c
@@ -1,3 +1,6 @@
+#include <stdio.h>
+#include <limits.h>
+#include <stddef.h>
const char *test (void)
{
FILE *f;
Similarly, for C++, gcc now emits hints for missing "std" includes:
std::string s("hello world");
$ gcc incomplete.cc incomplete.cc:1:6: error: ‘string’ in namespace ‘std’ does not name a type std::string s("hello world"); ^~~~~~ incomplete.cc:1:1: note: ‘std::string’ is defined in header ‘<string>’; did you forget to ‘#include <string>’? +#include <string> std::string s("hello world"); ^~~
Parameter type mismatches
I find a lot of my time is spent trying to call APIs, and dealing with silly mistakes like in the following:
extern int callee(int one, const char *two, float three);
int caller(int first, int second, float third)
{
return callee(first, second, third);
}
Older versions of GCC weren't very helpful when describing the problem:
$ gcc arg-type-mismatch.cc arg-type-mismatch.cc: In function ‘int caller(int, int, float)’: arg-type-mismatch.cc:5:37: error: invalid conversion from ‘int’ to ‘const char*’ [-fpermissive] return callee(first, second, third); ^ arg-type-mismatch.cc:1:12: error: initializing argument 2 of ‘int callee(int, const char*, float)’ [-fpermissive] extern int callee(int one, const char *two, float three); ^
You were told the argument number, but then had to count commas in the source.
For gcc 8, it prints this:
$ gcc arg-type-mismatch.cc arg-type-mismatch.cc: In function ‘int caller(int, int, float)’: arg-type-mismatch.cc:5:24: error: invalid conversion from ‘int’ to ‘const char*’ [-fpermissive] return callee(first, second, third); ^~~~~~ arg-type-mismatch.cc:1:40: note: initializing argument 2 of ‘int callee(int, const char*, float)’ extern int callee(int one, const char *two, float three); ~~~~~~~~~~~~^~~
which I hope you agree is much more readable: the compiler underlines both the problematic argument at the callsite and the corresponding parameter at the declaration of the callee, so you can immediately see the mismatch.
Implementing this turned out to be much harder than you might expect. In particular, GCC's internal representation of expressions didn't make a distinction between the declaration of a parameter vs uses of that parameter, so there was no natural place to store the source location of the use of second in the example above. So I had to do a fair amount of work "under the hood" to make this happen.
How do I get at some private field?
I often find myself trying to get at a field of a C++ object, knowing the fieldname, but finding it's private, and then trying to remember the name of the accessor - was it get_foo, getFoo, read_foo, or just foo?
So for GCC 8 I've added hints to the "field is private" error, showing how to use an accessor to get at the field in question, if one exists:
For example, given:
class foo
{
public:
double get_ratio() const { return m_ratio; }
private:
double m_ratio;
};
void test(foo *ptr)
{
if (ptr->m_ratio >= 0.5)
;// etc
}
the compiler now gives this hint when complaining about the direct access:
$ gcc accessor.cc accessor.cc: In function ‘void test(foo*)’: accessor.cc:12:12: error: ‘double foo::m_ratio’ is private within this context if (ptr->m_ratio >= 0.5) ^~~~~~~ accessor.cc:7:10: note: declared private here double m_ratio; ^~~~~~~ accessor.cc:12:12: note: field ‘double foo::m_ratio’ can be accessed via ‘double foo::get_ratio() const’ if (ptr->m_ratio >= 0.5) ^~~~~~~ get_ratio()
Template type differences
Compiler errors involving C++ templates have a reputation for being difficult to read. Here's what an older version of gcc emitted for a simple example:
$ gcc templates.cc templates.cc: In function ‘void test()’: templates.cc:9:25: error: could not convert ‘vector<double>()’ from ‘vector<double>’ to ‘vector<int>’ fn_1(vector<double> ()); ^ templates.cc:10:26: error: could not convert ‘map<int, double>()’ from ‘map<int, double>’ to ‘map<int, int>’ fn_2(map<int, double>()); ^
In even this simple case, I find there's something of a "wall of text" problem where my eyes start to glaze over.
For gcc 8 I've borrowed some good ideas from clang to improve such template diagnostics. I've added color to the messages, so that the mismatching parts of the template type are highlighted in green. Also, we now elide the parameters that are common between two mismatching templates, printing [...] instead:
$ gcc templates.cc templates.cc: In function ‘void test()’: templates.cc:9:8: error: could not convert ‘vector<double>()’ from ‘vector<double>’ to ‘vector<int>’ fn_1(vector<double> ()); ^~~~~~~~~~~~~~~~~ templates.cc:10:8: error: could not convert ‘map<int, double>()’ from ‘map<[...],double>’ to ‘map<[...],int>’ fn_2(map<int, double>()); ^~~~~~~~~~~~~~~~~~
Those [...] elided parameters can be seen using -fno-elide-type:
$ gcc templates.cc -fno-elide-type templates.cc: In function ‘void test()’: templates.cc:9:8: error: could not convert ‘vector<double>()’ from ‘vector<double>’ to ‘vector<int>’ fn_1(vector<double> ()); ^~~~~~~~~~~~~~~~~ templates.cc:10:8: error: could not convert ‘map<int, double>()’ from ‘map<int,double>’ to ‘map<int,int>’ fn_2(map<int, double>()); ^~~~~~~~~~~~~~~~~~
For more complicated errors, I implemented -fdiagnostics-show-template-tree, which visualizes the mismatching templates in a hierarchical form (for this rather contrived example):
$ gcc templates-2.cc -fdiagnostics-show-template-tree templates-2.cc: In function ‘void test()’: templates-2.cc:9:8: error: could not convert ‘vector<double>()’ from ‘vector<double>’ to ‘vector<int>’ vector< [double != int]> fn_1(vector<double> ()); ^~~~~~~~~~~~~~~~~ templates-2.cc:10:8: error: could not convert ‘map<map<int, vector<double> >, vector<double> >()’ from ‘map<map<[...],vector<double>>,vector<double>>’ to ‘map<map<[...],vector<float>>,vector<float>>’ map< map< [...], vector< [double != float]>>, vector< [double != float]>> fn_2(map<map<int, vector<double>>, vector<double>> ()); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
which again works with -fno-elide-type:
$ gcc templates-2.cc -fdiagnostics-show-template-tree -fno-elide-type templates-2.cc: In function ‘void test()’: templates-2.cc:9:8: error: could not convert ‘vector<double>()’ from ‘vector<double>’ to ‘vector<int>’ vector< [double != int]> fn_1(vector<double> ()); ^~~~~~~~~~~~~~~~~ templates-2.cc:10:8: error: could not convert ‘map<map<int, vector<double> >, vector<double> >()’ from ‘map<map<int,vector<double>>,vector<double>>’ to ‘map<map<int,vector<float>>,vector<float>>’ map< map< int, vector< [double != float]>>, vector< [double != float]>> fn_2(map<map<int, vector<double>>, vector<double>> ()); ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Plus a bunch of other stuff...
The C++ frontend can now give you a hint if you use a macro before it was defined
(e.g. if you mess up the order of your #includes):
$ gcc ordering.cc ordering.cc:2:24: error: expected ‘;’ at end of member declaration virtual void clone() const OVERRIDE { } ^~~~~ ; ordering.cc:2:30: error: ‘OVERRIDE’ does not name a type virtual void clone() const OVERRIDE { } ^~~~~~~~ ordering.cc:2:30: note: the macro ‘OVERRIDE’ had not yet been defined In file included from ordering.cc:5: c++11-compat.h:2: note: it was later defined here #define OVERRIDE override
I added fix-it hints to the C++ frontend's -Wold-style-cast diagnostic, telling you whether you can use a static_cast, const_cast, reinterpret_cast etc:
$ gcc -c old-style-cast-fixits.cc -Wold-style-cast old-style-cast-fixits.cc: In function ‘void test_1(void*)’: old-style-cast-fixits.cc:5:19: warning: use of old-style cast to ‘struct foo*’ [-Wold-style-cast] foo *f = (foo *)ptr; ^~~ ---------- static_cast<foo *> (ptr)
...and so on.
Trying it out
See How to install GCC 8 on Red Hat Enterprise Linux 7. You can also try GCC 8 in RHEL 8 Beta. GCC 8 is also available in Fedora 28 and later.
Alternatively, for simple code examples, you can play around with the new gcc at https://godbolt.org/.
Have fun!
You might also want to check out:
Last updated: March 8, 2019