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

[Martin Sebor <msebor at gmail dot com>]

On 09/20/2018 01:29 PM, Jason Merrill wrote:
> On Thu, Sep 20, 2018 at 1:38 PM, Martin Sebor <msebor@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.

Sure, it's expected in the middle-end.  I just don't remember
having seen it in a purely front-end warning.  It also goes
against what I said in my talk (and what has been argued by
some is the main disadvantage of middle-end warnings): that
front-end only warnings are more consistent because they
aren't subject to the effects of optimization.

Martin