Hi,
> -Original Message-
> From: gcc-ow...@gcc.gnu.org [mailto:gcc-ow...@gcc.gnu.org] On Behalf Of
> NightStrike
> Sent: Monday, May 2, 2016 1:55 AM
> To: gcc@gcc.gnu.org
> Cc: Jan Hubicka ; Jakub Jelinek
> Subject: option -mprfchw on 2 different Opteron cpus
>
> Reposting from here:
>
This is a cross-post from gcc-help as there haven't been any replies on
gcc-help since two days ago. Hope someone could help.
```
I have built GCC from gcc-6-branch in MSYS2 with mingw-w64 CRT on Windows today.
Now I have a relocation problem:
Assuming mingw-w64 headers are located in the follow
I made some investigation yesterday and here is the result:
```
Diff'ing gcc/libstdc++-v3/include/c_global/cstdlib from gcc-5-branch and
gcc-6-branch gives the following result:
(git diff gcc-5-branch gcc-6-branch -- libstdc++-v3/include/c_global/cstdlib)
```
@@ -69,7 +69,11 @@ namespace std
#
On Mon, May 2, 2016 at 5:55 AM, Kumar, Venkataramanan
wrote:
>> If I compile on a k8 Opteron 248 with -march=native, I do not see -mprfchw
>> listed in the options in -fverbose-asm. In the assembly, I see this:
>>
>> prefetcht0 (%rax) # ivtmp.1160
>> prefetcht0 304(%rcx) #
>> pre
On 04/29/2016 07:54 AM, Liu Woon Yung wrote:
I've done something like that, but GCC still doesn't select the pattern to use:
(define_insn "vec_cmp"
Because you've used the wrong name. The patterns are:
OPTAB_CD(vec_cmp_optab, "vec_cmp$a$b")
OPTAB_CD(vec_cmpu_optab, "vec_cmpu$a$b")
I see
Hi Jan,
I just noticed the compilation errors in the attached file with
the latest trunk. It seems as though your recent patch below may
be incomplete:
commit 46e5dccc6f188bd0fd5af4e9778f547ab63c9cae
Author: hubicka
Date: Mon May 2 16:55:56 2016 +
The following change causes compila
On Mon, 2016-05-02 at 11:50 -0600, Martin Sebor wrote:
> Hi Jan,
>
> I just noticed the compilation errors in the attached file with
> the latest trunk. It seems as though your recent patch below may
> be incomplete:
>
>commit 46e5dccc6f188bd0fd5af4e9778f547ab63c9cae
>Author: hubicka
>
So, my first cut at the function to select reassociation width for
power was modeled after what I saw i386 and aarch64 doing, which is to
return something based on the number of that kind of op we can do at
the same time:
static int
rs6000_reassociation_width (unsigned int opc, enum machine_mode m
> On Mon, 2016-05-02 at 11:50 -0600, Martin Sebor wrote:
> > Hi Jan,
> >
> > I just noticed the compilation errors in the attached file with
> > the latest trunk. It seems as though your recent patch below may
> > be incomplete:
> >
> >commit 46e5dccc6f188bd0fd5af4e9778f547ab63c9cae
> >A
On Mon, Apr 25, 2016 at 11:04:01AM -0600, Jeff Law wrote:
> On 04/21/2016 01:53 PM, Michael Meissner wrote:
> >As I start to allow integer modes into vector registers, I need to revisit
> >MODES_TIEABLE_P. I'm wondering if MODES_TIEABLE_P is transitive?
> I don't recall a need for it to be transiti
Hi
> -Original Message-
> From: NightStrike [mailto:nightstr...@gmail.com]
> Sent: Monday, May 2, 2016 10:31 PM
> To: Kumar, Venkataramanan
> Cc: Uros Bizjak (ubiz...@gmail.com) ;
> lopeziba...@gmail.com; Jan Hubicka ; Jakub Jelinek
> ; gcc@gcc.gnu.org
> Subject: Re: option -mprfchw on 2
11 matches
Mail list logo
