This is the mail archive of the mailing list for the GCC project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: warning: conversion from ‘int’ to ‘char’ may change value

On 9/20/18, Martin Sebor <> 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.  Delaying
> the warning until a later stage (e.g., until folding as Jason
> suggested) would make it more consistent.  It wouldn't solve
> all problems (e.g., it would still be prone to false positives
> in unreachable code), but solving those by delaying it even
> further could easily lead to others.
> Martin

I think this is bug 40752:
(or some of the bugs related to it, or marked as duplicates of it)

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]