Re: [RFC] PR 51712 -Wtype-limits should not trigger for enum constants

[Gabriel Dos Reis <gdr at integrable-solutions dot net>]

On Tue, May 15, 2012 at 4:06 AM, Richard Guenther
<richard.guenther@gmail.com> wrote:
> On Mon, May 14, 2012 at 8:47 PM, Joseph S. Myers
> <joseph@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