[PATCH] Avoid introducing TREE_OVERFLOWs in (T)(x&cst) -> (T)x & (T)cst optimization (PR middle-end/19857)

[Roger Sayle]

On Tue, 15 Feb 2005, Jakub Jelinek wrote:
> On Tue, Feb 15, 2005 at 06:37:27AM -0700, Roger Sayle wrote:
> > However, a slight improvement on your fold change would be:
> >
> >
> > >  	  if (change)
> > > +	    {
> >               tem = build_int_cst_wide (type, TREE_INT_CST_LOW (and1),
> >                                         TREE_INT_CST_HIGH (and1));
> >               tem = force_fit_type (tem, 0, false, false);
> > > +	      return fold (build2 (BIT_AND_EXPR, type,
> > > +				   fold_convert (type, and0), tem));
> > > +	    }
> > >  	}
> >
> > This allows us to force conversion of integer constants without worrying
> > about overflow.  The obvious benefit is that we can continue to optimize
> > the testcase in the PR.
>
> Will do.  Just I'm not sure whether it shouln't be in that case:
> if (TREE_OVERFLOW (and1))
>   tem = fold_convert (type, and1);
> else
>   {
>     tem = build_int_cst_wide (type, TREE_INT_CST_LOW (and1),
> 			      TREE_INT_CST_HIGH (and1));
>     tem = force_fit_type (tem, 0, false, false);
>   }
>
> because otherwise it would eat already present overflows (if any).

The same can be achieved by passing TREE_OVERFLOW (and1) and
TREE_CONSTANT_OVERFLOW (and1) instead of false and false as the
last two arguments to force_fit_type.

However, I believe that all of these problems will go away in
the near future, once the middle-end stops setting TREE_OVERFLOW
and TREE_CONSTANT_OVERFLOW in fold_const.  I've already posted a
patch at http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00030.html
The only thing blocking that patch was that a C front-end maintainer
wanted me to write an extensive set of C test cases to check that
the C front-end would generate all the required diagnostics.


I'm increasingly of the opinion that poor testsuite coverage for a
front-end diagnostics shouldn't really be enough reason to continue
to keep serious wrong-code bugs in the compiler across all languages.

Sod it.  Could you check whether my patch above resovles PR 19857?
If so, and there are no testsuite regressions, then as middle-end
maintainer I'll commit the patch to a middle-end source file, fixing
a middle-end regression in 4.0, and any hypothetical latent bugs
in poorly written/tested front-ends can be their own problem.

Any objections?  This is clearly the way we want to go, and if a
problem is discovered it can always be filed as a PR (in the
appropriate component) like any other unknown latent bug.

Roger
--