This is the mail archive of the
mailing list for the GCC project.
Re: [patch] Fix PR middle-end/56474
- From: Richard Biener <richard dot guenther at gmail dot com>
- To: Eric Botcazou <ebotcazou at adacore dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Mon, 15 Apr 2013 14:26:43 +0200
- Subject: Re: [patch] Fix PR middle-end/56474
- References: <1630485 dot 0zg5rbKfGZ at polaris> <CAFiYyc2H_=fCKGZ3yDG+RoTQWXkCDJ9=HY_Kttr_LKPtdjDTpw at mail dot gmail dot com> <4747807 dot yAnva0Zvtb at polaris>
On Mon, Apr 15, 2013 at 12:04 PM, Eric Botcazou <email@example.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
>> 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).
> Eric Botcazou