On 08/20/18 16:54, Jeff Law wrote:
> On 08/20/2018 08:52 AM, Bernd Edlinger wrote:
>> On 08/20/18 16:16, Jeff Law wrote:
>>> On 08/20/2018 07:28 AM, Richard Biener wrote:
On Mon, 20 Aug 2018, Bernd Edlinger wrote:
> On 08/20/18 12:41, Richard Biener wrote:
>> On Sun, 19 Aug 2018,
On 08/20/2018 08:52 AM, Bernd Edlinger wrote:
> On 08/20/18 16:16, Jeff Law wrote:
>> On 08/20/2018 07:28 AM, Richard Biener wrote:
>>> On Mon, 20 Aug 2018, Bernd Edlinger wrote:
>>>
On 08/20/18 12:41, Richard Biener wrote:
> On Sun, 19 Aug 2018, Bernd Edlinger wrote:
>
>> Hi!
On 08/20/18 16:16, Jeff Law wrote:
> On 08/20/2018 07:28 AM, Richard Biener wrote:
>> On Mon, 20 Aug 2018, Bernd Edlinger wrote:
>>
>>> On 08/20/18 12:41, Richard Biener wrote:
On Sun, 19 Aug 2018, Bernd Edlinger wrote:
> Hi!
>
>
> This fixes a wrong code issue in expand_e
On 08/20/2018 07:28 AM, Richard Biener wrote:
> On Mon, 20 Aug 2018, Bernd Edlinger wrote:
>
>> On 08/20/18 12:41, Richard Biener wrote:
>>> On Sun, 19 Aug 2018, Bernd Edlinger wrote:
>>>
Hi!
This fixes a wrong code issue in expand_expr_real_1 which happens because
a negat
On Mon, 20 Aug 2018, Bernd Edlinger wrote:
> On 08/20/18 12:41, Richard Biener wrote:
> > On Sun, 19 Aug 2018, Bernd Edlinger wrote:
> >
> >> Hi!
> >>
> >>
> >> This fixes a wrong code issue in expand_expr_real_1 which happens because
> >> a negative bitpos is actually able to reach extract_bit_f
On 08/20/18 12:41, Richard Biener wrote:
> On Sun, 19 Aug 2018, Bernd Edlinger wrote:
>
>> Hi!
>>
>>
>> This fixes a wrong code issue in expand_expr_real_1 which happens because
>> a negative bitpos is actually able to reach extract_bit_field which
>> does all computations with poly_uint64, thus t
On Sun, 19 Aug 2018, Bernd Edlinger wrote:
> Hi!
>
>
> This fixes a wrong code issue in expand_expr_real_1 which happens because
> a negative bitpos is actually able to reach extract_bit_field which
> does all computations with poly_uint64, thus the offset 0x1ff0.
>
> To avoid that
Hi!
This fixes a wrong code issue in expand_expr_real_1 which happens because
a negative bitpos is actually able to reach extract_bit_field which
does all computations with poly_uint64, thus the offset 0x1ff0.
To avoid that I propose to use Jakub's r20 patch from the expand_assig