This is the mail archive of the
mailing list for the GCC project.
Re: [PATCH] Fix a fallout of PR14179 fix (3.3/3.4/4.0 regression)
- From: Roger Sayle <roger at eyesopen dot com>
- To: Richard Kenner <kenner at vlsi1 dot ultra dot nyu dot edu>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Wed, 29 Dec 2004 10:21:05 -0700 (MST)
- Subject: Re: [PATCH] Fix a fallout of PR14179 fix (3.3/3.4/4.0 regression)
On Wed, 29 Dec 2004, Richard Kenner wrote:
> Right, but that's what we're talking about.
> I'm not sure what you're saying; we may well be agreeing.
Hmm... I think we may be. I was about to argue that force_fit_type
shouldn't concern itself with overflow, but that int_fits_type_p should.
Looking at the actual code, you're right, the two are interlinked for
no good reason. Perhaps we'd be in even stronger agreement if we
rewrote int_fits_type_p as:
< c = copy_node (c);
< TREE_TYPE (c) = type;
< c = force_fit_type (c, -1, false, false);
< return !TREE_OVERFLOW (c);
> tree n = copy_node (c);
> TREE_TYPE (n) = type;
> n = force_fit_type (n, -1, false, false);
> return TREE_INT_CST_HIGH (n) == TREE_INT_CST_HIGH (c)
> && TREE_INT_CST_LOW (n) == TREE_INT_CST_LOW (c);
i.e. force_fit_type no longer *needs* to set TREE_OVERFLOW, just to
enable int_fits_type_p to do the right thing.
My apologies for being confused/confusing previously. This is clearly
one case where the middle-end is using TREE_OVERFLOW, but one where it
clearly doesn't actually need to.
Does anyone have any objections to the above change?