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
