On 3/22/18 6:03 PM, Segher Boessenkool wrote:
> On Wed, Mar 21, 2018 at 09:10:38PM -0500, Peter Bergner wrote:
>> If you're asking about whether we also need to backport to GCC 6, I
>> believe Kaushik said in the bugzilla that he only encountered the
>> ICE on GCC 7 and trunk, so I don't think we n
On Wed, Mar 21, 2018 at 09:10:38PM -0500, Peter Bergner wrote:
> On 3/21/18 7:37 PM, Segher Boessenkool wrote:
> > On Wed, Mar 21, 2018 at 12:47:41PM -0500, Peter Bergner wrote:
> >> I'll note that GCC 7 does not need any of the changes to rs6000-p8swap.c,
> >> since that file doesn't exist and doe
On 3/21/18 12:47 PM, Peter Bergner wrote:
> Kaushik confirmed this is broken on GCC 7 as well. Ok to backport
> this patch to GCC 7, assuming regtesting is clean?
FYI, bootstrap and regtesting on both powerpc64le-linux and
powerpc64-linux (testsuite run in both 32-bit and 64-bit modes)
were clean
On 3/21/18 7:37 PM, Segher Boessenkool wrote:
> On Wed, Mar 21, 2018 at 12:47:41PM -0500, Peter Bergner wrote:
>> I'll note that GCC 7 does not need any of the changes to rs6000-p8swap.c,
>> since that file doesn't exist and doesn't need to exist in GCC 7, so I've
>> left those changes out.
>
> Di
On Wed, Mar 21, 2018 at 12:47:41PM -0500, Peter Bergner wrote:
> On 3/20/18 12:27 PM, Peter Bergner wrote:
> > On 3/20/18 11:42 AM, Segher Boessenkool wrote:
> >> On Mon, Mar 19, 2018 at 09:12:08PM -0500, Peter Bergner wrote:
> >>> Looking at mu build dirs insn-modes.h, I don't see HAVE_V8HFmode be
On 3/20/18 12:27 PM, Peter Bergner wrote:
> On 3/20/18 11:42 AM, Segher Boessenkool wrote:
>> On Mon, Mar 19, 2018 at 09:12:08PM -0500, Peter Bergner wrote:
>>> Looking at mu build dirs insn-modes.h, I don't see HAVE_V8HFmode being
>>> defined on either my LE or BE builds. What am I missing?
>>
>>
On 3/20/18 11:42 AM, Segher Boessenkool wrote:
> On Mon, Mar 19, 2018 at 09:12:08PM -0500, Peter Bergner wrote:
>> Looking at mu build dirs insn-modes.h, I don't see HAVE_V8HFmode being
>> defined on either my LE or BE builds. What am I missing?
>
> Nothing, I just was confused (we always define
On Mon, Mar 19, 2018 at 09:12:08PM -0500, Peter Bergner wrote:
> On 3/12/18 1:55 PM, Segher Boessenkool wrote:
> >> #ifdef HAVE_V8HFmode
> >> - else if (mode == V8HFmode)
> >> - stvx = TARGET_64BIT
> >> -? gen_altivec_stvx_v8hf_1op (src_exp, memory_address)
> >> -: gen_altivec_stvx_v
On 3/12/18 1:55 PM, Segher Boessenkool wrote:
> On Sun, Mar 11, 2018 at 10:23:02AM -0500, Peter Bergner wrote:
>> +; The following patterns embody what lvx should usually look like.
>> +(define_expand "altivec_lvx_"
>> + [(set (match_operand:VM2 0 "register_operand" "")
>> +(match_operand:VM2
To: Peter Bergner
Cc: GCC Patches ; Kaushik Phatak
; Bill Schmidt
Subject: Re: [PATCH, rs6000] Fix PR83789: __builtin_altivec_lvx fails for
powerpc for altivec-4.c
Hi!
On Sun, Mar 11, 2018 at 10:23:02AM -0500, Peter Bergner wrote:
> PR83789 shows a problem in the builtin expansion code
Hi!
On Sun, Mar 11, 2018 at 10:23:02AM -0500, Peter Bergner wrote:
> PR83789 shows a problem in the builtin expansion code not calling the correct
> define_insn, given the correct mode (32-bit versus 64-bit). One could add
> tests in this code to call the correct pattern, but it's easier to creat
PR83789 shows a problem in the builtin expansion code not calling the correct
define_insn, given the correct mode (32-bit versus 64-bit). One could add
tests in this code to call the correct pattern, but it's easier to create
a common define_expand which everyone can call that does the right thing
12 matches
Mail list logo
