This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [patch] Fix PR middle-end/56474
- From: Eric Botcazou <ebotcazou at adacore dot com>
- To: Richard Biener <richard dot guenther at gmail dot com>
- Cc: gcc-patches at gcc dot gnu dot org
- Date: Fri, 19 Apr 2013 23:01 +0200
- Subject: Re: [patch] Fix PR middle-end/56474
- References: <1630485 dot 0zg5rbKfGZ at polaris> <22774122 dot QJzaNXD29q at polaris> <CAFiYyc2-vkVHWFQfjxATzbjfxb_HFMJu+G9vCZVE9kfJAw4GqA at mail dot gmail dot com>
> Maybe we should detect overflow as if the input and output were signed
> while computing an unsigned result. As far as I can see int_const_binop_1
> does detect overflow as if operations were signed (it passes 'false' as
> uns to all double-int operations rather than TYPE_UNSIGNED).
> For example sub_with_overflow simply does
>
> neg_double (b.low, b.high, &ret.low, &ret.high);
> add_double (low, high, ret.low, ret.high, &ret.low, &ret.high);
> *overflow = OVERFLOW_SUM_SIGN (ret.high, b.high, high);
>
> which I believe is wrong. Shouldn't it be
>
> neg_double (b.low, b.high, &ret.low, &ret.high);
> HOST_WIDE_INT tem = ret.high;
> add_double (low, high, ret.low, ret.high, &ret.low, &ret.high);
> *overflow = OVERFLOW_SUM_SIGN (ret.high, tem, high);
>
> ? Because we are computing a + (-b) and thus OVERFLOW_SUM_SIGN
> expects the sign of a and -b, not a and b to verify against the
> sign of ret.
But int_const_binop_1 is called from int_const_binop, so why would we want to
introduce any overflow for unsigned types other than sizetypes?
> I'm sceptical. Where do you compute the size expression for variable-sized
> arrays? I suppose with the testcase in the initial patch I can then inspect
> myself what actually happens?
Sure, but we already went through this in the PR. It's because of the formula
used for the length of variable-sized arrays, which needs to handle the case
of superflat arrays.
--
Eric Botcazou