Re: CCP propagating conditional expression constants

[Ian Lance Taylor <iant at google dot com>]

Mark Mitchell <mark@codesourcery.com> writes:

> I think we should just accept lower fidelity warnings, emitted from the
> front end.  I think we should warn about the obvious cases that front
> ends can detect, and not try to emit warnings based on more complex
> anlaysis.  That will result in missing some useful warnings, but may
> also reduce false positives.  It will eliminate the -g vs. -O2
> differences and match what most other compilers do.

Since I've been worrying about it recently, I want to mention that
there is a large class of important warnings which simply can not be
issued from the frontend: warnings about cases where the compiler is
relying on undefined behaviour.  We can't issue decent alias analysis
warnings or undefined overflow warnings or unsafe loop transform
warnings in the frontends.  Perhaps not warnings about variables
clobbered by setjmp/vfork, either.

> If we want to keep the optimizer-based warnings, I think we should
> segregate them into a separate category, rather than enabling them as
> part of the usual warnings.  The optimizer-based warnings are more like
> "lint" or other, more sophisticated, source-based analysis tool
> warnings, like Insure++.  It makes sense to build some of that
> technology into the compiler, but I think it's unfortunate that there
> are things we don't warn about at -O0, and that our warning behavior
> varies from target to target, release to release, optimization levels, etc.

These things don't bother me though maybe I am just used to them.  I
certainly wouldn't object to moving warnings like "unreachable code"
into the front end.

Ian