Re: named warnings & individual warning control

[Mark Mitchell <mark at codesourcery dot com>]

DJ Delorie wrote:


> > I'm not sure what to say about the problem in the last paragraph; that's 
> > clearly a serious user interface issue.  This is part of why 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.
>
>
> Barring huge changes in the design of the internals of gcc, I'm happy
> with documenting that such pragmas should come before any functions in
> the source or else they may not apply.  That's in line with the "the
> user shouldn't be doing this unless they absolutely have to" theory.

This is an issue, however, that causes me to worry that we'll disappoint 
our users.  As a user, I find software features that only sort-of work 
to me much more disappointing than features that aren't there at all.

If we're going to say that these #pragmas have to come at the start of 
the file, then I'd suggest a different tack: add a #pragma that allows 
you to pass additional command-line options, so that you could put 
almost any option (including, say, "-fno-strength-reduce") into a 
#pragma at the top of your file, rather than on the command-line.

That, of course, is getting far away from your original intent.  But, I 
think that your discovery (about warnings coming from the optimizers) 
suggests that if you want to accomplish the original goal, you may need 
to store warning information on a per-function/per-line basis -- which 
is certainly possible -- or get consensus on pulling these warnings out 
of the optimizers.  (I know of no other compiler that does 
platform-dependent, optimization-flag dependent stuff to figure out 
whether or not to issue used-before-set warnings.  I've always felt that 
the increased resolution available that way is in no way worth the user 
interface oddities.)

--
Mark Mitchell
CodeSourcery, LLC
mark@codesourcery.com