[RFC] PR34389 -Wconversion produces wrong warning

[Joseph S. Myers]

On Sat, 16 Feb 2008, Richard Guenther wrote:

> On Feb 16, 2008 5:52 PM, Manuel López-Ibáñez <lopezibanez@gmail.com> wrote:
> > The following patch  fixes PR 34389 in a ugly way, in my own opinion,
> > but I am not able to come up with any other way to fix this.
> >
> > A more detailed analysis is in the PR. In summary the problem here is
> > that fold_unary converts (T)(x & c) into (T)x & (T)c which in this
> > case is (int) (x & 0x7fff) into ((int)x & 0x7fff). By using
> > get_unwidened, we could handle the first form. However, get_unwidened
> > won't handle the latter. Thus, when Wconversion sees that this
> > expression is assigned to a short, it concludes that there may be a
> > loss of precision.
> >
> > Bootstrapped and regression tested in x86_64-unknown-linux-gnu. This
> > patch only affects Wconversion, which is new in 4.3.
> 
> The correct fix is to not fold expressions in the C frontend before doing
> these kinds of warnings.

I agree with that in principle - but I also think it's useful to avoid 
warning for such cases as short = (int & 0x7fff) when written directly by 
the user (with any non-negative constant in the range of short there).  I 
suppose there are other cases where it may be less likely that the user 
will write the code created by the compiler, but anything affecting 
expressions directly written by the user would still be of some use after 
the front end no longer does the present folding.  (This means there 
should be testcases where the problem expressions are written directly by 
the user, not just the tests where they are compiler-generated.)

-- 
Joseph S. Myers
joseph@codesourcery.com