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

[Martin Sebor <msebor at gmail dot com>]

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;
>
> typecast the expression like "n& = (char)~n1" and warning goes away .
>
> and when we investigated the gcc source and warning coming from
> unsafe_conversion_p@ gcc/c-family/c-common.c:1226
>
> if (TYPE_PRECISION (type) < TYPE_PRECISION (expr_type))
> give_warning = UNSAFE_OTHER;
>
> where TYPE_PRECISION (type) is 8  for char and TYPE_PRECISION
> (expr_type) is 32  as expected for int .
>
> is that expected behavior of gcc ?

It looks like a bug to me.

Declaring n1 const avoids the warning at -O2 but in C but not
at -O0.  That doesn't seem quite right -- GCC determines the
type of the bitwise AND expression to be different between
the optimization levels.  In C++, declaring n1 const avoids
the warning regardless of optimization levels.

A bug report about these inconsistencies would be useful to
help us determine whether they are the expected result of
constant folding or whether there is, in fact, a subtle bug
(the difference  is introduced in shorten_binary_op).

This is all quite interesting to me because is shows how even
fairly simple warnings fully implemented in the front-end and
so theoretically immune from false positives and negatives
can be fragile and prone to such problems, just like warnings
implemented in the middle-end.  (I discussed some of these
issues in my talk on Implementing Static Analysis Checkers
In the GCC Middle-End at the last Cauldron.)

Martin