On Mon, Sep 17, 2018 at 12:03 PM, Martin Sebor <mse...@gmail.com> 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;
>>
>> 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.)
Indeed, whether this sort of warning is a false positive depends on
values, which the optimizers can always do better with. We could
build some logic into the front end, e.g. recognize that a &
expression will always fit in the smallest of its operand types, but
on the other hand that duplicates things that other parts of the
compiler already deal with, so there's a question of how to share
these rules between front and middle end, like we're doing more of
with constant folding. Perhaps we could use the folder somehow.
Jason
