This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: [warnings] attribs.c


On Wed, 4 May 2005, DJ Delorie wrote:

> Or a pair of tests, one explicitly enabling the warning and one
> explicitly disabling the warning?  Or three tests?  Do we care more
> about the action of the switch, or the default?

Three tests is best; we care about both the action of the switch and the 
default; in principle at least three tests for everywhere the warning flag 
is tested, and in principle test each diagnostic for each attribute for 
which it can arise so the testsuite asserts exactly which attributes 
require types, require function types, etc., and that -Wno-attributes has 
the proper effect on all those diagnostics.  When I added 
-Wno-int-to-pointer-cast and -Wno-pointer-to-int-cast each got three 
tests.

> I wasn't trying to fix the code, just control the warnings.  What I'd
> *like* to see is to have all "errors" which gcc can tolerate turned
> into warnings, with the "warning as error" flag enabled *for those
> warnings*, so the only things the user can't control (warn, error,
> ignore) are errors that cause gcc to be unable to compile at all.

I'd rather see more mandatory pedwarns (and probably some 
pedwarns-if-pedantic) turned into unconditional hard errors that GCC 
doesn't try to tolerate in order to simplify the possible range of trees 
for invalid programs for which GCC might try to generate code.  I don't 
think adding tolerance of hard errors is generally desirable; it breaks an 
invariant that beyond a certain point GCC need not deal with the 
datastructures for code erroneous in a certain way and so adds complexity 
and requires an audit of all of GCC which might be complicated by the new 
invalid code for which semantics have been defined.  As is, for errors we 
can freely insert error_mark_node or whatever is convenient in the 
datastructures to continue processing within the front end, and can freely 
change what we use for those datastructures; if the error can be disabled 
we need defined and documented semantics.

(Allowing a per-warning flag for whether a warning is an error is however 
desirable - we should get rid of the -Werror-implicit-function-declaration 
special case in favour of such options in general.)

-- 
Joseph S. Myers               http://www.srcf.ucam.org/~jsm28/gcc/
    jsm@polyomino.org.uk (personal mail)
    joseph@codesourcery.com (CodeSourcery mail)
    jsm28@gcc.gnu.org (Bugzilla assignments and CCs)


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]