On 15 May 2012 11:06, 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.
I think that would be probably the best for the long term. But it will also require a lot of work. More work than I can dedicate to this. This seems a chicken and egg dilemma. Current full-time contributors don't have interest or time for this kind of infrastructure work. And potential contributors who have interest in using (and perhaps improving) this infrastructure prefer to invest their effort in other compilers that already has the infrastructure in place. Well, maybe someone will be brave enough to tackle this for GSoC 2013... (Did GCC get any projects for GSoC 2012?) Cheers, Manuel.
