On Tue, May 15, 2012 at 4:06 AM, Richard Guenther <richard.guent...@gmail.com> wrote: > On Mon, May 14, 2012 at 8:47 PM, Joseph S. Myers > <jos...@codesourcery.com> wrote: >> On Mon, 14 May 2012, Manuel López-Ibáñez wrote: >> >>> PING: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg00383.html >> >> The general idea of checking this information in shorten_compare seems >> reasonable. (shorten_compare's optimization function is one that really >> ought to be done in generic code, but the warning function is reasonable >> enough.) >> >>> And on a general note, what is the opinion of the C/C++ maintainers >>> about tracking the original source code more faithfully than currently >>> done? >> >> I consider it a good idea to do so - moving more to an explicit lowering >> step / conversion from front-end to middle-end internal representation. >> >> There are some places where c_fully_fold is called to avoid false positive >> warnings. A first approach for eliminating those would be to make the >> internal representation contain relevant information such as "this is an >> implicit conversion" so that the warnings can be generated later in >> c_fully_fold when it has the extra information from folding operands. >> Another possibility would be to have IR that says "give this warning, if >> this condition can occur", and options to evaluate the condition early >> (with predictability but false positives) or late (fewer false positives, >> less predictability). Or you could lower as needed but carry around both >> lowered and unlowered versions of an expression (so front-end IR would >> include a pointer to lowered IR if lowering has taken place on-demand). > > I suppose it would be possible to use a new CONST_EXPR <> with > two operands - the fully folded result (and thus constant) and the original > expression which is unfolded. At the time we lower to GENERIC we can > simply drop CONST_EXPR <> in favor of its constant operand.
Note however that certain expressions are deemed constant only for the purpose of static initialization, not because they really are values -- they may still remain expressions. Address constants are prime examples. -- Gaby
