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 overzealous folding


On Fri, May 16, 2008 at 11:48 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> The problem seems to be caused by adjust_range_with_scev (after applying
>> the patch I posted).  If I remove that from VRP the test is retained.
>
>  D.1367_13 = (boolean) i_29;
>
> i_29 is an iv running from 1 to 10 so SCEV computes that D.1367_13 >= 1.
>
> When the statement is passed to extract_range_from_unary_expr, it detects a
> truncation so sets the range to VARYING.  But extract_range_from_expr decides
> that it can do better and calls set_value_range_to_nonnegative to set it to
> [0, TYPE_MAX_VALUE], i.e. [0,1].  Therefore D.1367_13 is computed as being 1.
>
> All of this is entirely consistent within SCEV and VRP, but incompatible with
> the folding made by fold_unary.  I presume the C family of languages doesn't
> see the problem because of the guard for BOOLEAN_TYPE.  Extending it further
> to ENUMERAL_TYPE seems quite harmless and safe...

Sure, I just think it doesn't fix the real problem ;)  Basically any time VRP or
someone else derives a value-range using TYPE_MIN/MAX_VALUE that doesn't
match the TYPE_PRECISION things can go wrong.  IMHO this TYPE_MIN/MAX_VALUE
should not be used by the middle-end at all.

But well, let's go with the fold patch for now.  Thanks for your patience.

Richard.

>
> --
> Eric Botcazou
>


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