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 PR middle-end/56474


On Mon, Apr 15, 2013 at 12:04 PM, Eric Botcazou <ebotcazou@adacore.com> wrote:
>> I think I already rejected this and asked you to fix the users (like
>> layout_type is a user).
>
> Yes, but that would be a pain, there are too many users in the Ada front-end.

Users that care about the special casing of  0 - 1 and overflow detection?
For the C family I found exactly one - the layout_type case, and fixed
it in the FEs by making empty arrays use [1, 0] domains or signed domains
(I don't remember exactly).  I believe the layout_type change was to make
Ada happy.

>> Clearly 0 - 1 in unsigned arithmetic overflows.  Not indicating this may
>> cause bugs elsewhere as easily as it fixes code not dealing with this fact.
>
> !?? There is no overflow in unsigned arithmetics.  Instead size_binop forces
> overflows artificially and I don't see the problem in deciding that 0 - 1 is a
> special case, like [0, -1] is a special case for layout_type.  And note that
> this was the historical behavior, before the latest sizetype changes.

Historically sizetype didn't overflow because it was supposed to never overflow.
Well, unless we check for overflow.

It may be that enabling overflow detection for even unsigned sizetype was
because of Ada as well.  After all only Ada changed its sizetype sign recently.

I don't like special casing 0 - 1 in a general compute function.  Maybe
you want to use size_diffop for the computation?  That would result in
a signed result and thus no overflow for 0 - 1.

The other option is to for example disable overflow handling for _all_
constants and MINUS_EXPR (and then please PLUS_EXPR as well)
in size_binop.  Maybe it's only the MULT_EXPR overflow we want to
know (byte-to-bit conversion / element size scaling IIRC).

Richard.

> --
> Eric Botcazou


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