named warnings & individual warning control

[Mark Mitchell]

Stan Shebs wrote:

> Mark Mitchell wrote:
>
>> [...] I have long argued that only front ends should be permitted to 
>> issue warnings, and that all attempts to use back-end data flow 
>> analysis to issue warnings are mistaken, no matter how clever they seem.
>>
> An interesting point. Continuously we get complaints from our users
> about how uninitialized variable warnings are not available without
> turning on optimizations, to the point that some people want us to
> disable -O0.

Yup.

> So if I understand what you're getting at, it would be to have some
> weaker form of flow analysis in the front end to implement the
> uninitialized warnings, even if that means reporting some false
> positives?

Yes.

The tradeoff is probably that they miss some things that we might catch now.

For example, consider:

  inline bool f() { return true; }

  void g() {
     int i;
     bool b = f();

     if (b) i = 3;
     h(i);
  }

Here, GCC with -O2 will probably not warn about the use of "i", since 
the assignment always takes place.  (The compiler will do inlining, 
constant propagation, remove the branch, etc.)

In most compilers, you will either get a false positive, or no warning.  
(Some compilers say, "I saw a path to here where i was not assigned, 
that might be trouble".  Others will say "I saw a path to here where i 
was assigned, no warning.")  These compilers do not build flow graphs 
for this purpose; they just keep a bit about whether or not they have 
seen initializations for particular variables.) 

Arguably, GCC's behavior is not what people want anyhow; a change to the 
implementation of "f" will cause the code above to become unsafe.  If 
"f" is a library function, for example, you really wanted the compiler 
to check your code without looking inside "f"; you don't want to depend 
on it not changing in some way.  If you really want the GCC-style "what 
actually happens with optimization turned on", you use Purify/Valgrind 
or a compiler that inserts additional checks (ala mudflap).  The logical 
extension of GCC's "I'm taking into optimization into account" point of 
view is "only tell me about functions that I actually run", which is why 
you want to instrument the code, not have the compiler optimizer issue 
warnings.

All of these compilers will catch the common case where you totally 
forget to initialize "i", and none will complain about the common case 
where you initialize "i" in straight-line code after the delcaration and 
before you use it.

> I can go for that; if it takes a complicated analysis to
> determine that a variable really is initialized before use, there's a
> good chance that the code is only working correctly by accident, and
> that minor changes - say, just before going into production use, per
> Murphy - would break it.

Exactly.

-- 
Mark Mitchell
CodeSourcery, LLC
(916) 791-8304
mark@codesourcery.com