On Mon, Jun 3, 2019 at 12:38 PM Eric Botcazou wrote:
>
> > Hmm, ISTR we had such mitigations in place (or have) elsewhere keying
> > on the most significant bit set instead of power-of-two. But your case
> > likely recurses and runs into the extract_multiv limiting to eventually
> > stop, even fo
> Hmm, ISTR we had such mitigations in place (or have) elsewhere keying
> on the most significant bit set instead of power-of-two. But your case
> likely recurses and runs into the extract_multiv limiting to eventually
> stop, even for (N + 4) * 8, right? If so shouldn't we prevent this
> even fo
> Hmm, ISTR we had such mitigations in place (or have) elsewhere keying
> on the most significant bit set instead of power-of-two.
fold_plusminus_mult_expr only factors out for power-of-two:
if (exact_log2 (absu_hwi (int11)) > 0 && int01 % int11 == 0
/* The remainder should not be
On Fri, May 31, 2019 at 11:56 AM Eric Botcazou wrote:
>
> Hi,
>
> this is a regression present for 32-bit targets on mainline and 9 branch only,
> but the underlying issue dates back from the removal of the TYPE_IS_SIZETYPE
> machinery. Since the removal of this machinery, there is an internal co
Hi,
this is a regression present for 32-bit targets on mainline and 9 branch only,
but the underlying issue dates back from the removal of the TYPE_IS_SIZETYPE
machinery. Since the removal of this machinery, there is an internal conflict
for sizetype: it's an unsigned type so with wrap-around
