This is the mail archive of the gcc-patches@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]

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?

Roger
--


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]