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. Richard. > -- > Joseph S. Myers > jos...@codesourcery.com