On 10/19/20 6:36 AM, Aldy Hernandez wrote:
The test is trying to shift by 129, but the underlying type is 128 bits.
This causes low_bits to wrap around to -1 and things go bad really
quick.
Attached is my proposed solution.
Andrew, do you have a preference on how to fix this?
If we know we ar
On 10/19/20 1:01 PM, Jakub Jelinek wrote:
On Mon, Oct 19, 2020 at 12:55:38PM +0200, Aldy Hernandez wrote:
Shifts are undefined already when the shift count is equal to the precision.
And arbitrarily choosing one of the values as the shift count seems risky to
me (and even when used, the most
On Mon, Oct 19, 2020 at 12:55:38PM +0200, Aldy Hernandez wrote:
> > Shifts are undefined already when the shift count is equal to the precision.
> > And arbitrarily choosing one of the values as the shift count seems risky to
> > me (and even when used, the most natural would be truncating the exce
On Mon, Oct 19, 2020 at 12:44 PM Jakub Jelinek wrote:
>
> On Mon, Oct 19, 2020 at 12:36:24PM +0200, Aldy Hernandez via Gcc-patches
> wrote:
> > The test is trying to shift by 129, but the underlying type is 128 bits.
> > This causes low_bits to wrap around to -1 and things go bad really
> > quick
On Mon, Oct 19, 2020 at 12:36:24PM +0200, Aldy Hernandez via Gcc-patches wrote:
> The test is trying to shift by 129, but the underlying type is 128 bits.
> This causes low_bits to wrap around to -1 and things go bad really
> quick.
>
> Attached is my proposed solution.
>
> Andrew, do you have a
The test is trying to shift by 129, but the underlying type is 128 bits.
This causes low_bits to wrap around to -1 and things go bad really
quick.
Attached is my proposed solution.
Andrew, do you have a preference on how to fix this?
gcc/ChangeLog:
PR tree-optimization/97488
* r
