On Tue, May 15, 2012 at 4:49 AM, Manuel López-Ibáñez <lopeziba...@gmail.com> wrote: > 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.
The disjunctive is slamming two different things in the same bucket, and that should not be. When I was implementing constexpr, I occasionally ran in frustration with the compiler because it did not explicitly represent certain concepts (e.g. lvalueness, implicit conversions, etc.) systematically. Certainly the desire was there; only the time needed to get them in the release time schedule wasn't there. Well, eventually, the definition of constexpr evolved and those matters became less pressing, not that they were no longer needed. I seem to remember having discussed the idea of using a bit flag to represent expressions we know for sure are constant expressions, but I believe Jason felt otherwise at the time. So, we ended up with a predicate which was the compromised solution. -- Gaby
