Re: PATCH: Add PROCESSOR_INTEL

2014-01-11 Thread Uros Bizjak
On Fri, Jan 10, 2014 at 11:29 PM, H.J. Lu wrote: > Hi, > > This patch adds PROCESSOR_INTEL, which is almost identical to > PROCESSOR_SILVERMONT, except that __tune_slm__/__tune_silvermont__ > aren't defined for -mtune=intel. OK for trunk? No, we have said that -mtune=intel is used to tune for *c

Re: [Ping]Two pending IVOPT patches

2014-01-11 Thread Bin.Cheng
On Sat, Jan 11, 2014 at 2:42 PM, Bin.Cheng wrote: > On Wed, Dec 11, 2013 at 4:18 AM, Jeff Law wrote: >> On 12/10/13 00:01, bin.cheng wrote: >>> >>> Emm, some kind of. See the cost of iv candidate set consists of several >>> parts, the representation cost in cost pair; the register pressure cost

Re: [Ping]Two pending IVOPT patches

2014-01-11 Thread Jakub Jelinek
On Sat, Jan 11, 2014 at 05:02:26PM +0800, Bin.Cheng wrote: > > I reduced the case and attached ivopt dumps with/without the patch. > > It seems the patch is doing right thing and choosing better > > candidates, most likely it reveals an existing bug. > > I am looking into this issue, in the meantim

Re: [Ping]Two pending IVOPT patches

2014-01-11 Thread Bin.Cheng
On Sat, Jan 11, 2014 at 5:07 PM, Jakub Jelinek wrote: > On Sat, Jan 11, 2014 at 05:02:26PM +0800, Bin.Cheng wrote: >> > I reduced the case and attached ivopt dumps with/without the patch. >> > It seems the patch is doing right thing and choosing better >> > candidates, most likely it reveals an ex

Re: [Patch, Fortran, committed] PR 59612: iso_fortran_env segfaults with -fdump-fortran-original

2014-01-11 Thread Mikael Morin
Le 09/01/2014 14:33, Janus Weil a écrit : > After noticing that the bug is actually a regression (see PR 57042): > Ok to backport to 4.7 and 4.8? > Sure! Mikael

Re: [Patch, Fortran] PR 58026: Bad error recovery for allocatable component of undeclared type

2014-01-11 Thread Mikael Morin
Le 09/01/2014 16:30, Janus Weil a écrit : > Hi all, > > the attached patch started out as an ICE-on-invalid regression fix, > but after the ICE had been fixed recently by other means, it was > degraded to a mere error-recovery improvement. It removes some rather > 'hackish' code that was added b

Re: [PATCH i386 10/8] [AVX512] Add missing AVX-512ER patterns, intrinsics, tests.

2014-01-11 Thread Uros Bizjak
On Fri, Jan 10, 2014 at 5:24 PM, Jakub Jelinek wrote: > On Fri, Jan 10, 2014 at 07:20:38PM +0300, Kirill Yukhin wrote: >> @@ -28920,6 +28927,7 @@ static const struct builtin_description >> bdesc_special_args[] = >>{ OPTION_MASK_ISA_AVX512F, CODE_FOR_avx512f_movntv16sf, >> "__builtin_ia32_mov

Re: [Patch, fortran] PR58007: unresolved fixup hell

2014-01-11 Thread Mikael Morin
Le 04/01/2014 16:35, Janus Weil a écrit : > Hi Mikael, > >> this patch fixes PR58007, where the compiler was not able to relate a >> component pointer to any loaded derived type symbol. >> The problem came from an optimization avoiding loading again a symbol >> which had already been loaded, skip

Re: PR 59712 patch

2014-01-11 Thread François Dumont
On 01/09/2014 11:49 PM, Jonathan Wakely wrote: On 9 January 2014 21:55, François Dumont wrote: All unordered_* tests run under Linux x86_64. Please make sure you run the entire testsuite, not just the parts that seem relevant. Done and no failure, ok to commit ? François

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

2014-01-11 Thread H.J. Lu
On Wed, Dec 25, 2013 at 12:41 PM, H.J. Lu wrote: > 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

[Patch, libgfortran] PR59700 and PR59764 Misleading/buggy runtime error message

2014-01-11 Thread Jerry DeLisle
The attached patch fixes both these bugs, combining Steve's patch and mine. Recent fixes of memory leaks placed the free_line before the generation of the error messages rather than after, The item_count which identifies the read list item involved with the error was getting cleared, resulting in

[PATCH, rs6000] Change rs6000 into SWITCHABLE_TARGET

2014-01-11 Thread Peter Bergner
After Jakub changed i?386/x86_64 to use SWITCHABLE_TARGET, he asked me to look at changing rs6000 too. Here's the rs6000 patch, which is basically identical to the i386.[hc] change Jakub made. This passed bootstrap and regtesting on powerpc64-linux with no regressions. Ok for mainline? Peter

RE: [PATCH] Fix PR58115

2014-01-11 Thread Peter Bergner
On Thu, 2014-01-09 at 10:36 +0100, Bernd Edlinger wrote: > On Thu, 9 Jan 2014 10:28:43, Jakub Jelinek wrote: > > Yeah, if i386 is changed into SWITCHABLE_TARGET, then I'd strongly encourage > > rs6000 and nios folks to follow the suit. > > Ok for me. Hope they read this thread... The rs600 patch

Re: [Patch, libgfortran] PR59700 and PR59764 Misleading/buggy runtime error message

2014-01-11 Thread Jerry DeLisle
My apologies please. I forgot to mention Dominiq for his superb assistance with this patch and testing. Many thanks! On 01/11/2014 09:13 AM, Jerry DeLisle wrote: > The attached patch fixes both these bugs, combining Steve's patch and mine. > Recent fixes of memory leaks placed the free_line befor

Re: [PATCH, rs6000] Change rs6000 into SWITCHABLE_TARGET

2014-01-11 Thread David Edelsohn
On Sat, Jan 11, 2014 at 12:16 PM, Peter Bergner wrote: > After Jakub changed i?386/x86_64 to use SWITCHABLE_TARGET, he asked me to > look at changing rs6000 too. Here's the rs6000 patch, which is basically > identical to the i386.[hc] change Jakub made. This passed bootstrap and > regtesting on

Re: [Patch, libgfortran] PR59700 and PR59764 Misleading/buggy runtime error message

2014-01-11 Thread Steve Kargl
On Sat, Jan 11, 2014 at 09:27:44AM -0800, Jerry DeLisle wrote: > My apologies please. I forgot to mention Dominiq for his > superb assistance with this patch and testing. Many thanks! > Add Dominiq to the ChangeLog entry. I think the patch is OK. -- Steve

[PATCH, committed] rs6000 builtins for FPSCR

2014-01-11 Thread David Edelsohn
This patch adds builtins to load and store the PowerPC floating point status and control register. * config/rs6000/rs6000.c (rs6000_expand_mtfsf_builtin): New. (rs6000_expand_builtin): Handle mffs and mtfsf. (rs6000_init_builtins): Define mffs and mtfsf. * config/rs

Re: [patch] make the libstdc++ pretty printers compatible with both Python 2 and Python3

2014-01-11 Thread Jonathan Wakely
On 31 October 2013 16:46, Tom Tromey wrote: >> "Matthias" == Matthias Klose writes: > > Matthias> Starting with gdb 7.6, gdb can be linked with both Python 2.x > Matthias> and Python 3.x. Therefore the pretty printers should be > Matthias> compatible with both Python versions. > > Thanks for

Re: [Patch, Fortran, committed] PR 59612: iso_fortran_env segfaults with -fdump-fortran-original

2014-01-11 Thread Janus Weil
2014/1/11 Mikael Morin : > Le 09/01/2014 14:33, Janus Weil a écrit : >> After noticing that the bug is actually a regression (see PR 57042): >> Ok to backport to 4.7 and 4.8? >> > Sure! Thanks. Committed to 4.8 as r206556. Will do 4.7 soon. Cheers, Janus

Re: [Patch, fortran] PR58007: unresolved fixup hell

2014-01-11 Thread Janus Weil
Hi, >>> this patch fixes PR58007, where the compiler was not able to relate a >>> component pointer to any loaded derived type symbol. >>> The problem came from an optimization avoiding loading again a symbol >>> which had already been loaded, skipping by the way the association of >>> component p

[AARCH64][PATCH] PR59695

2014-01-11 Thread Kugan
Hi, aarch64_build_constant incorrectly truncates the immediate when constants are generated with MOVN. This causes coinor-osi tests to fail (tracked also in https://bugs.launchpad.net/gcc-linaro/+bug/1263576) Attached patch fixes this. Also attaching a reduced testcase that reproduces this. Teste