-Wimplicit-fallthrough in GCC 7

In C and C++, the cases of a switch statement are in fact labels, and the switch is essentially a go to that jumps to the desired label. Since labels do not change the flow of control, one case block falls through to the following case block, unless terminated by a return, a break, a no return call or similar. In the example below, “case 1” falls through to “case 2“:

switch (cond)
   {
   case 1:
     a = 1;
   case 2:
     a = 2;
     break;
   /* ... */
   }

Continue reading “-Wimplicit-fallthrough in GCC 7”

Share

Testing GCC in the wild

Currently, the GCC testsuite contains more than fifty thousand tests which make up to two million lines of code. Since we, the GCC developers, try hard to avoid regressions in the compiler, almost every change to the compiler or to a related library requires a new test or a set of tests to be added. Hence the internal testsuite keeps growing at a rapid pace. It goes without saying that a new change should not break any existing test.

Despite all this effort, new bugs still creep in. Because it is best to discover as many bugs as possible before a particular version of the compiler is released, many distribution maintainers try to rebuild all the packages in the distro with a still unreleased compiler. They file bug reports if they find any bugs to the upstream Bugzilla so that the compiler is up to snuff when it is released. This rebuild typically happens once a year in regression fixes-only stage of the development, i.e. a stage when no new features are being introduced and the development revolves around fixing bugs.

While a new version of GCC is usually released in April, the Fedora project performs a mass rebuild of all the Fedora packages in January or February. Due to limited resources, this mass rebuild is only done on x86_64 architecture.
Since the point is to test GCC, this is a mass rebuild of so-called first order.

We are looking for several classes of bugs here. These include:

Continue reading “Testing GCC in the wild”

Share

GCC Undefined Behavior Sanitizer – ubsan

Not every software bug has as serious consequences as seen in the Ariane 5 rocket crash. Notwithstanding that, bugs cost software companies a lot of money every year and upset customers, users, and developers. Some bugs happen as a result of undefined behavior occurring in the program. Undefined behavior is a concept known especially in the C and C++ languages which means that the semantics of certain operations is undefined and the compiler presumes that such operations never happen. For instance, using non-static variable before it has been initialized is undefined. If an undefined behavior occurs, the compiler is free to do anything. The application can produce wrong results, crash, or print the complete text of Proust’s oeuvre.gnu logo

Luckily, there are ways to detect at least some of the undefined behavior in a program. The compiler can issue a warning at compile time, but only in case it can statically detect some kind of wrongdoing.  Often this is not the case and the checking has to take place at run time.

Enter ubsan

Continue reading “GCC Undefined Behavior Sanitizer – ubsan”

Share