On 2/13/18 5:51 PM, Segher Boessenkool wrote:
> We can backport without having a failing testcase. Let's do that for 7
> at least?
Ok, the backport tested clean, so I committed it. Thanks.
Peter
On 2/13/18 5:51 PM, Segher Boessenkool wrote:
> On Tue, Feb 13, 2018 at 05:07:26PM -0600, Peter Bergner wrote:
>> It's up to you whether you want the backport because you don't trust
>> me being able to create a failing test case. :-)
>
> We can backport without having a failing testcase. Let's
On Tue, Feb 13, 2018 at 05:07:26PM -0600, Peter Bergner wrote:
> On 2/13/18 4:34 PM, Segher Boessenkool wrote:
> >> This patch passed bootstrap and retesting on powerpc64le-linux with
> >> no regressions. Ok for mainline?
> >
> > Okay, thanks! Does this need backports?
>
> Committed with your
On 2/13/18 4:34 PM, Segher Boessenkool wrote:
>> This patch passed bootstrap and retesting on powerpc64le-linux with
>> no regressions. Ok for mainline?
>
> Okay, thanks! Does this need backports?
Committed with your suggested change below. Thanks!
It'd be easy to backport and should be
Hi!
On Mon, Feb 12, 2018 at 09:34:30PM -0600, Peter Bergner wrote:
> PR84279 is a similar problem to PR83399, in that we generate an altivec
> load/store through an explicit call to the altivec_{l,st}vx_v4si_2op
> pattern and then due to spilling, we end up calling recog() and we match
> an
