[PATCH] Fix PR c++/59638

2014-01-05 Thread Adam Butcher
* cp/parser.c (cp_parser_init_declarator): Undo fully implicit template parameter list when declarator is not a function. * g++.dg/cpp1y/pr59638.C: New testcase. --- gcc/cp/parser.c | 8 gcc/testsuite/g++.dg/cpp1y/pr59638.C | 16 +

libgo patch committed: Remove unused variables

2014-01-05 Thread Ian Lance Taylor
Dominik Vogt pointed out that libgo has some unused variables. They are copied from the gc repository, where they are used, but they make no sense for gccgo. This patch removes them. Bootstrapped on x86_64-unknown-linux-gnu, committed to mainline. Ian diff -r e55673d1a916 libgo/runtime/runtime

[PATCH] Fix PR c++/59629

2014-01-05 Thread Adam Butcher
* cp/parser.c (cp_parser_lambda_expression): Save/reset/restore auto_is_implicit_function_template_parm_p around lambda body. * g++.dg/cpp1y/pr59629.C: New testcase. --- gcc/cp/parser.c | 5 + gcc/testsuite/g++.dg/cpp1y/pr59629.C | 7 +++ 2 fil

[Patch, committed, Darwin] fix pr bootstrap/59541

2014-01-05 Thread Iain Sandoe
I've applied the attached patch as r206348 to fix this bootstrap problem after discussion with Honza last week on irc. Thanks to Dominique for helping with testing across the platform variants. Happy New Year! Iain gcc: PR bootstrap/59541 * config/darwin.c (darwin_function_secti

Re: [Patch] libgcov.c re-factoring

2014-01-05 Thread Jan Hubicka
> 2014-01-03 Rong Xu > > * gcc/gcov-io.c (gcov_var): Move from gcov-io.h. > (gcov_position): Ditto. > (gcov_is_error): Ditto. > (gcov_rewrite): Ditto. > * gcc/gcov-io.h: Refactor. Move gcov_var to gcov-io.h, and libgcov > only part to libgcc/libgc

[committed] Skip run/compile on hppa*-*-* for various tests that fail with a branch of one

2014-01-05 Thread John David Anglin
This change adds hppa*-*-* to the lists of targets that fail in these tests. The tests fail with the PA7XXX scheduling models that have a branch cost pf 1. Tested on hppa1.1-hp-hpux11.11, hppa2.0-hp-hpux11.11 and hppa64-hp- hpux11.11. Dave -- John David Anglin dave.ang...@bell.net 2

Re: [Patch, bfin/c6x] Fix ICE for backends that rely on reorder_loops.

2014-01-05 Thread Teresa Johnson
On Sun, Jan 5, 2014 at 3:39 AM, Bernd Schmidt wrote: > On 01/05/2014 12:35 PM, Felix Yang wrote: >> >> Ping? >> Cheers, > > > I have a different patch which I'll submit next week after some more > testing. The assert in cfgrtl is unnecessarily broad and really only needs > to trigger if -freorder-

Re: How to generate AVX512 instructions now (just to look at them).

2014-01-05 Thread Toon Moene
On 01/03/2014 10:11 PM, Jakub Jelinek wrote: Hi! On Fri, Jan 03, 2014 at 08:58:30PM +0100, Toon Moene wrote: I don't doubt that would work, what I'm interested in, is (cat verintlin.f): Well, you need gather loads for that and there you hit PR target/59617. I tried your patch, and the effe

Re: [Patch, bfin/c6x] Fix ICE for backends that rely on reorder_loops.

2014-01-05 Thread Bernd Schmidt
On 01/05/2014 12:35 PM, Felix Yang wrote: Ping? Cheers, I have a different patch which I'll submit next week after some more testing. The assert in cfgrtl is unnecessarily broad and really only needs to trigger if -freorder-blocks-and-partition; there's nothing wrong with entering cfglayout

Re: [Patch, SMS] Fix a potential bug of schedule_reg_moves of SMS

2014-01-05 Thread Felix Yang
Ping ? Cheers, Felix On Thu, Jan 2, 2014 at 9:07 PM, Felix Yang wrote: > Hello Vladimir, > This patch fixes a trivial bug of SMS: distance1_uses needs to be > initialized if newly allocated. > Since the original author of SMS is not active for a very long time, > it would be nice if you can

Re: [Patch, bfin/c6x] Fix ICE for backends that rely on reorder_loops.

2014-01-05 Thread Felix Yang
Ping? Cheers, Felix On Thu, Jan 2, 2014 at 10:13 PM, Felix Yang wrote: > Hi Bernd, > > It's easy to reproduce this error: > step1: Build gcc for c6x from gcc code of latest trunk, say > c6x-uclinux-gcc for example > step2: Using the newly built c6x gcc compiler to comiple this small case:

Re: wide-int, rtl

2014-01-05 Thread Eric Botcazou
> the fast path is not any faster. that was why we did not do it. And by > the time you add the tests it would be slower.The thing is that on > the inside of the so called fast path, you are still converting the tree > to wide-int first and that conversion still is checking the rest of > thes