This is the mail archive of the gcc@gcc.gnu.org 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] |
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
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |