RE: [Patch, i386] PR 59422 - Support more targets for function multi versioning

2013-12-25 Thread Gopalasubramanian, Ganesh
Hi, >> (get_amd_cpu): Handle AMD_BOBCAT, AMD_JAGUAR, AMDFAM15H_BDVER2 and >> AMDFAM15H_BDVER3. As mentioned earlier, we would like to stick with BTVER1 and BTVER2 instead of using BOBCAT or JAGUAR. Attached patch does the changes. Regards Ganesh NameChange.patch Description: NameChang

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

2013-12-25 Thread H.J. Lu
On Wed, Dec 25, 2013 at 3:09 PM, H.J. Lu wrote: > On Wed, Dec 25, 2013 at 2:26 PM, Uros Bizjak wrote: >> On Wed, Dec 25, 2013 at 8:02 PM, Allan Sandfeld Jensen >> wrote: >>> On Wednesday 25 December 2013, Uros Bizjak wrote: On Tue, Dec 24, 2013 at 4:17 PM, Allan Sandfeld Jensen w

Re: [patch] powerpc64 FreeBSD support for boehm-gc

2013-12-25 Thread Andreas Tobler
On 21.12.13 18:27, Andrew Haley wrote: > On 12/20/2013 10:15 PM, Andreas Tobler wrote: >> Ok for gcc trunk? > > OK, thanks. > May I get this one down to 4.8 too? Not really needed, but for completeness. Results will follow... Thanks, Andreas

[PATCH, i386]: Add some missing cache entries to i386-driver.c

2013-12-25 Thread Uros Bizjak
Hello! 2013-12-26 Uros Bizjak * config/i386/driver-i386.c (decode_caches_intel): Add missing entries. Tested on x86_64-pc-linux-gnu and committed to mainline and 4.8 branch. Uros. Index: driver-i386.c === --- driver-i386.c

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

2013-12-25 Thread H.J. Lu
On Wed, Dec 25, 2013 at 2:26 PM, Uros Bizjak wrote: > On Wed, Dec 25, 2013 at 8:02 PM, Allan Sandfeld Jensen > wrote: >> On Wednesday 25 December 2013, Uros Bizjak wrote: >>> On Tue, Dec 24, 2013 at 4:17 PM, Allan Sandfeld Jensen >>> >>> wrote: >>> >> Will libgcc/config/i386/cpuinfo.c update be

Re: PATCH: PR target/59587: cpu_names in i386.c is accessed with wrong index

2013-12-25 Thread Uros Bizjak
On Wed, Dec 25, 2013 at 10:31 PM, H.J. Lu wrote: >> cpu_names in i386.c is only used by ix86_function_specific_print >> which >> accesses it with enum processor_type index. But cpu_names is >> defined as >> array with enum target_cpu_default index.

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

2013-12-25 Thread Uros Bizjak
On Wed, Dec 25, 2013 at 8:02 PM, Allan Sandfeld Jensen wrote: > On Wednesday 25 December 2013, Uros Bizjak wrote: >> On Tue, Dec 24, 2013 at 4:17 PM, Allan Sandfeld Jensen >> >> wrote: >> >> Will libgcc/config/i386/cpuinfo.c update be a separate patch? >> >> Should we use a single definition for

Re: PATCH: PR target/59587: cpu_names in i386.c is accessed with wrong index

2013-12-25 Thread H.J. Lu
On Wed, Dec 25, 2013 at 10:03:45PM +0100, Uros Bizjak wrote: > On Wed, Dec 25, 2013 at 10:02 PM, H.J. Lu wrote: > > On Wed, Dec 25, 2013 at 12:49 PM, Uros Bizjak wrote: > >> On Tue, Dec 24, 2013 at 7:03 PM, H.J. Lu wrote: > >> > cpu_names in i386.c is only used by ix86_function_specific

Re: PATCH: PR target/59587: cpu_names in i386.c is accessed with wrong index

2013-12-25 Thread Uros Bizjak
On Wed, Dec 25, 2013 at 10:02 PM, H.J. Lu wrote: > On Wed, Dec 25, 2013 at 12:49 PM, Uros Bizjak wrote: >> On Tue, Dec 24, 2013 at 7:03 PM, H.J. Lu wrote: >> cpu_names in i386.c is only used by ix86_function_specific_print which accesses it with enum processor_type index. But c

Re: PATCH: PR target/59587: cpu_names in i386.c is accessed with wrong index

2013-12-25 Thread H.J. Lu
On Wed, Dec 25, 2013 at 12:49 PM, Uros Bizjak wrote: > On Tue, Dec 24, 2013 at 7:03 PM, H.J. Lu wrote: > >>> cpu_names in i386.c is only used by ix86_function_specific_print which >>> accesses it with enum processor_type index. But cpu_names is defined as >>> array with enum target_cp

Re: PATCH: PR target/59587: cpu_names in i386.c is accessed with wrong index

2013-12-25 Thread Uros Bizjak
On Tue, Dec 24, 2013 at 7:03 PM, H.J. Lu wrote: >> cpu_names in i386.c is only used by ix86_function_specific_print which >> accesses it with enum processor_type index. But cpu_names is defined as >> array with enum target_cpu_default index. This patch adds processor >> names to

PATCH: PR libitm/53113: Build fails in x86_avx.cc if AVX disabled by -mno-avx

2013-12-25 Thread H.J. Lu
Hi, In libitm, x86_sse.cc must be compiled with -msse and x86_avx.cc must be compiled with -mavx. We need to make sure that -msse/-mavx is appended at the end of compiler options. This patch appends -msse/-mavx to CXXFLAGS, instead of appending them to XCFLAGS. Tested with CXXFLAGS="-g -O2 -mno

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

2013-12-25 Thread Allan Sandfeld Jensen
On Wednesday 25 December 2013, Uros Bizjak wrote: > On Tue, Dec 24, 2013 at 4:17 PM, Allan Sandfeld Jensen > > wrote: > >> Will libgcc/config/i386/cpuinfo.c update be a separate patch? > >> Should we use a single definition for both i386.c and libgcc? > > > > Currently they need to be in the sam

Re: [Patch, i386] PR 59422 - Support more targets for function multi versioning

2013-12-25 Thread Uros Bizjak
On Tue, Dec 24, 2013 at 4:17 PM, Allan Sandfeld Jensen wrote: >> Will libgcc/config/i386/cpuinfo.c update be a separate patch? >> Should we use a single definition for both i386.c and libgcc? > > Currently they need to be in the same patch. But yes, moving the definition > out to a common header

Re: [PATCH] Enable multiple duplicated blocks on threading path

2013-12-25 Thread H.J. Lu
On Thu, Nov 21, 2013 at 7:59 AM, H.J. Lu wrote: > On Tue, Nov 19, 2013 at 9:11 PM, Jeff Law wrote: >> On 11/19/13 19:33, David Malcolm wrote: >>> >>> >>> FWIW, it looks like you attached the whitespace cleanup patch again, >>> rather than the one you discuss above. >>> >>> For the archives, it lo

Re: [PATCH] -fuse-caller-save - Implement TARGET_FN_OTHER_HARD_REG_USAGE hook for MIPS

2013-12-25 Thread Tom de Vries
On 07-12-13 16:07, Tom de Vries wrote: Richard, This patch implements the target hook TARGET_FN_OTHER_HARD_REG_USAGE (posted here: http://gcc.gnu.org/ml/gcc-patches/2013-03/msg01318.html) for MIPS, to address the issue that $6 is sometimes used in split calls. Build and reg-tested on MIPS. OK