Airs – Ian Lance Taylor

Compiler Warnings

There is an ongoing issue within gcc as to where warnings should be issued. The question is whether warnings should be issued only by the frontend, or whether it is also OK for the optimizers to issue them.

The advantage of issuing warnings in the frontend are that warnings are independent of optimization level. Also, the warnings are issued much closer to the user’s code, which means that it is easier for the user to understand what they mean, and it is easier to give very good location information.

The advantage of issuing warnings from the optimizers is that some warnings require the data structures built by the optimizers. A good example in gcc is the new strict aliasing warning. This warns about code which may violate the type aliasing restrictions in the language standard. Detecting this requires tracking how pointers are used in the program.

Some other warnings that gcc emits after the frontend are:

  • Warnings about large stack frames.
  • Warnings about optimizations which rely on undefined signed overflow.
  • Warnings about variables which may be changed by setjmp.
  • Some warnings about comparisons which are always true or false.
  • Warnings about unsafe loop optimizations.
  • Warnings about unused values.
  • Warnings about unreachable code.
  • Warnings about uninitialized variables.

The last two in this list are particularly troublesome. They are simple warnings, but whether they are issued changes based on the optimization level and changes from one compiler release to another. This is confusing and frustrating for users: a new compiler release can mean a new set of warnings.

On the other hand, the optimizers can do a better job. For example, the uninitialized variable warning can warn about uninitialized fields in a structure. It can also warn about variables which are passed to an inlined function by address, but are never initialized by that function. It would be possible to do these in the frontend, but harder.

The right choice may be to separate the warnings: do some basic checking in the frontend, and use different options for the warnings issued by the optimizers.

Posted

in

by

Ian Lance Taylor

Tags:

Comments

4 responses to “Compiler Warnings”

  1. ncm Avatar
    ncm

    My problem with Gcc warnings is that Order Matters. E.g., “-Wstrict-overflow=5 -W” is the same as “-W”. IMHO “-W” should never reduce the level of any warning level. The choices above are quibbles in the face of such counterintuitive behavior.

    Uninitialized-variable warnings are a big problem, as noted by some Linux kernel developers. Spurious warnings, for cases like “if (A) b=c; d(); if (A) e(b);” are especially annoying because if you silence them by initializing b with a dummy value, you wipe out a future, smarter compiler’s ability to detect real errors.

  2. Ian Lance Taylor Avatar
    Ian Lance Taylor

    The issue with the order of warning options is a bug. It’s already better in gcc 4.2.3 and 4.3.0. See http://gcc.gnu.org/PR32102.

    I agree that your example of spurious warnings is a problem. Unfortunately that is the kind of problem which is hard to fix if warnings is only emitted by the frontend.

  3. ncm Avatar
    ncm

    It’s good to know that’s acknowledged as a bug.

    I don’t care whether warnings come from the front end or the optimizer. What would be helpful is if we could compile -O0 for comprehensible debugging, and run the optimizer at -O∞ for the warnings but otherwise discard the results. I would run it that way all the time, when developing.

  4. Ian Lance Taylor Avatar
    Ian Lance Taylor

    That is an interesting idea. gcc generally aims -O0 at a combination of easy debugging plus fast compile times. We could have an option to abandon that.

    There would still be the problem that the warnings would change with new gcc releases, though.

Leave a Reply