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

Reply via email to