This is the mail archive of the gcc@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: handling of warnings


On Wed, 2003-08-13 at 21:18, Andrew Pinski wrote:


> You could something like autoconf (or write you own configure program)
> to find out if the warnings exist in your customers computers.

I could, but i never will use that kind of disaster :-)

> Every other compilers, ICC, Portland's, I know errors out on unknown 
> options also.

Just because they're all sheep doesn't mean gcc has to follow.

But please note: I'm only talking about *warning control options*
here, not general options. I agree, if a semantic or model
control option is wrong, the compiler should error out.
However for gcc, warning control options are clearly flagged

	-Woption

and I'm *only* talking about the set of values for 'option'
in this case.

I think it makes sense to provide a wide class of diagnostics,
and allow the user to turn them on and off -- static error
detection is a much better technique the debugging or testing.

But to enable that, and allow many new checks to be added,
and perhaps even remove some options, from version to version,
it is important not to give an error on an option that
happens not be recognised in this particular version of the
compiler, and that is because scripts need to select
options corresponding to what the author of the script
has access to at the time, and the nature of the
program written.

Backward compatibility is NOT enough here, since some
clients of the program could be running an older
compiler.. and some could be running a newer one.

The same argument could be applied to specific
optimisation switches. The set of optimisations should
be considered mutable, and if a particular optimisation
isn't available, the option to select it is just ignored
(or at worst an warning printed).

In both these cases the semantics and target coding
model are not affected, so there is no reason to be
strict about the options, and every reason not to be.




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