Re: [PATCH] Fix PR middle-end/26635

[Roger Sayle <roger at eyesopen dot com>]

On Fri, 31 Mar 2006, Eric Botcazou wrote:
> 2006-03-31  Eric Botcazou  <ebotcazou@adacore.com>
>
> 	PR middle-end/26635
> 	* common.opt (fmodv): New switch.
> 	* doc/invoke.texi (Code Generation Options): Document it.
> 	* c-common.c (c_common_nodes_and_builtins): Set flag_modv to 1.
> 	* convert.c (convert_to_integer): Don't narrow the type of a
>         PLUS_EXPR or MINUS_EXPR if !flag_modv and the unwidened type
>         is signed.

Alas, I can't approve the c-common.c hunk, but if its OK with you I'd
like to request a minor modification to this solution.  As you know
I've been working towards cleaning up many of these TREE_OVERFLOW
annoyances, and one of the patches I have completely removes the setting
of TREE_OVERFLOW in fold_convert_const_int_from_int.  Unfortunately,
although I believe this is the better long term solution, it isn't
suitable for the regression in 4.0 and 4.1.

Hence I agree that your approach is the more practical immediate
fix for PR middle-end/26635.  The only aspect that I don't like is
the way we're introducing a new user-visible and documented command
line option, which we'd like to deprecate for 4.2 and will certainly
be gone for 4.3.  If it's OK with the other maintainers I'd prefer
this to just be a simple global variable, like flag_evaluation_order
in flags.h rather than new command line option.  It should be have
identically, can get for C/C++ in the same way, and provides the
same less intrusive workaround for the release branches.

This greatly reduces the effort of removing it, once a more permanent
solution is committed.

Does this sound reasonable?


For those interested, my plan for TREE_OVERFLOW is a three pronged
attack; (i) The middle-end's setting of TREE_OVERFLOW is restricted
to recording the overflow of arithmetic operations (conversion of
constants no longer causes this flag to become set, just preserved),
(ii) The middle-end transitions to treating TREE_OVERFLOW as a write-only
field, preserving and setting it for the convenience of the front-ends
and checking the overflow status of a calculation but ignoring it
completely in most situations and (iii) unification of TREE_OVERFLOW
and TREE_CONSTANT_OVERFLOW to a single field.

Unfortunately, the process of auditing the numerous uses of
TREE_OVERFLOW and TREE_CONSTANT_OVERFLOW in the middle-end and
front-ends is a slow process.  But examples, of the incremental
preparations can be seen in previous patches, such as:

http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01712.html
http://gcc.gnu.org/ml/gcc-patches/2005-12/msg00130.html

To see where things are going, I believe the patch for PR19100
that I posted below would resolve Eric's current failure?
http://gcc.gnu.org/ml/gcc-patches/2005-01/msg00030.html

Thoughts?


Roger
--