On Thu, Sep 20, 2018 at 1:38 PM, Martin Sebor <mse...@gmail.com> wrote:
> On 09/20/2018 08:08 AM, Vincent Lefevre wrote:
>>
>> On 2018-09-17 10:03:48 -0600, Martin Sebor wrote:
>>>
>>> On 09/17/2018 06:00 AM, Umesh Kalappa wrote:
>>>>
>>>> Hi All,
>>>>
>>>> When we try to compile the below case from trunk gcc we get the below
>>>> warning (-Wconversion) i.e
>>>>
>>>> void start(void) {
>>>> char n = 1;
>>>> char n1 = 0x01;
>>>> n &= ~n1;
>>>> }
>>>>
>>>> $xgcc -S warn.c -nostdinc -Wconversion
>>>> warning: conversion from ‘int’ to ‘char’ may change value
>>>> [-Wconversion]
>>>> n &= ~n1;
>>
>> [...]
>>>
>>> It looks like a bug to me.
>>>
>>> Declaring n1 const avoids the warning at -O2 but in C but not
>>> at -O0.
>>
>>
>> Perhaps at some optimization level, GCC determines that the
>> expression is safe (thus no longer emits the warning), i.e.
>> that n & ~n1 is necessarily representable in a char.
>>
>>> That doesn't seem quite right -- GCC determines the
>>> type of the bitwise AND expression to be different between
>>> the optimization levels.
>>
>>
>> No, the type of this AND expression is always int. The question
>> is whether this int is necessarily representable in a char.
>>
>>> In C++, declaring n1 const avoids the warning regardless of
>>> optimization levels.
>>
>>
>> If the constant propagation is done at -O0, this could explain
>> the behavior.
>>
>> Or do you mean that GCC remembers the type the data come from,
>> i.e. assuming char is signed, if n1 is of type char, then ~n1
>> is necessarily representable in a char, thus can be regarded
>> as of being of type char in its analysis?
>
>
> What I'm saying is that the type that determines whether or
> not to issue a warning in this case is computed in
> the shorten_binary_op() function. The function is passed
> the operands of the &= expression and returns the expression's
> "new" type. When n1's value is known (i.e., when it's const
> and with -O2) and fits in char, and when n's type is the char
> (or under a bunch of other conditions), the function returns
> the type char. Comments in the code indicate it's
> an optimization. That may be fine as far as code correctness
> goes but it doesn't seem quite right or robust to me because
> it makes the warning appear inconsistent, both between
> languages, and in C, between optimization levels.
Lots of warnings vary between optimization levels, because
optimizations make more information available. I don't think that's
avoidable in general unless we want to more frequently enable some
optimization passes when certain warnings are enabled.
Jason
