Re: [PATCH] Avoid invoking ranlib on libbackend.a

2016-07-16 Thread Patrick Palka
On Sat, Jul 16, 2016 at 6:35 PM, Andrew Pinski wrote: > On Sat, Jul 16, 2016 at 3:13 PM, Patrick Palka wrote: >> On Sat, 16 Jul 2016, Patrick Palka wrote: >> >>> This patch makes the 0.5GB libbackend.a get built via "ar rcs" instead >>> of via "ar rc" +

Re: RFA: new pass to warn on questionable uses of alloca() and VLAs

2016-07-16 Thread Martin Sebor
I forgot to ask, Aldy: Have you tried using LTO with the warning? I haven't managed to get it to warn even though I expected it to. The test I used is below. [...more testing...] After some more testing I discovered that LTO somehow seems to suppress this and other warnings (including the new

Re: [PATCH] Avoid invoking ranlib on libbackend.a

2016-07-16 Thread Andrew Pinski
On Sat, Jul 16, 2016 at 3:13 PM, Patrick Palka wrote: > On Sat, 16 Jul 2016, Patrick Palka wrote: > >> This patch makes the 0.5GB libbackend.a get built via "ar rcs" instead >> of via "ar rc" + "ranlib", if possible. The problem with the latter is >> that it's about twice

Re: [PATCH] Avoid invoking ranlib on libbackend.a

2016-07-16 Thread Patrick Palka
On Sat, 16 Jul 2016, Patrick Palka wrote: > This patch makes the 0.5GB libbackend.a get built via "ar rcs" instead > of via "ar rc" + "ranlib", if possible. The problem with the latter is > that it's about twice as slow as the former and it makes libbackend.a > get written twice which is

Re: RFA: new pass to warn on questionable uses of alloca() and VLAs

2016-07-16 Thread Martin Sebor
Done. -Walloca and -Wvla warn on any use of alloca and VLAs accordingly, with or without optimization. I sorry() on the bounded cases. I think it's an improvement though I suspect we each have a slightly different understanding of what the sorry message is meant to be used for. It's

[PATCH] Avoid invoking ranlib on libbackend.a

2016-07-16 Thread Patrick Palka
This patch makes the 0.5GB libbackend.a get built via "ar rcs" instead of via "ar rc" + "ranlib", if possible. The problem with the latter is that it's about twice as slow as the former and it makes libbackend.a get written twice which is wasteful. On my machine this optimization reduces rebuild

Re: [PATCH GCC]Remove support for -funsafe-loop-optimizations

2016-07-16 Thread NightStrike
On Fri, Jul 15, 2016 at 1:07 PM, Bin Cheng wrote: > Hi, > This patch removes support for -funsafe-loop-optimizations, as well as > -Wunsafe-loop-optimizations. By its name, this option does unsafe > optimizations by assuming all loops must terminate and doesn't wrap. >

Re: [v3 PATCH] Implement P0307R2, Making Optional Greater Equal Again.

2016-07-16 Thread Daniel Krügler
2016-07-13 20:32 GMT+02:00 Ville Voutilainen : > On 13 July 2016 at 21:25, Daniel Krügler wrote: >> How would you feel about the introduction of an internal trait >> __is_boolean_testable, that would test both is_convertible> bool> and

Re: [committed] Improve profile support on hppa

2016-07-16 Thread John David Anglin
Oops, here is patch. Dave -- John David Anglin dave.ang...@bell.net 2016-07-16 John David Anglin * config/pa/pa.c (hppa_profile_hook): Allocate stack space for register parameters. Remove code to initialize argument pointer on

[committed] Improve profile support on hppa

2016-07-16 Thread John David Anglin
The attached patch implements a suggestion from Helge Deller to optimize profile support. When _mcount is reachable using a pc-relative branch, we can use the delay slot of the branch to compute the selfpc argument of _mcount. In working on this change, I noticed a couple of problems with the

Re: [PATCH] Add constexpr to iterator adaptors, array and range access

2016-07-16 Thread Ville Voutilainen
On 16 July 2016 at 18:38, Ville Voutilainen wrote: > I think it's reasonable to make the functions constexpr even when the standard > doesn't allow it, and if c++17 allows them to be constexpr, make the functions > constexpr in other standard modes as well. We could

Re: [PATCH] Add constexpr to iterator adaptors, array and range access

2016-07-16 Thread Ville Voutilainen
> This patch implements http://wg21.link/p0031 which adds constexpr to > most operations on std::reverse_iterator, std::move_iterator, > std::array, as well as std::advance, std::distance, and the > range-access functions std::begin, std::rbegin etc. > > Strictly speaking, those functions should

[patch, Fortran] Fix some string temporaries

2016-07-16 Thread Thomas Koenig
Hello world, this fixes PR 71902. The recent fix for PR 71783 introduced a performance and code size regression a string temporary was created for the test case when it was not actually needed. I also took the opportunity of renaming the misnomed temporary variable. Regression-tested. OK for

Re: [PATCH] Add constexpr to iterator adaptors, array and range access

2016-07-16 Thread Daniel Krügler
2016-07-16 1:09 GMT+02:00 Jonathan Wakely : > This patch implements http://wg21.link/p0031 which adds constexpr to > most operations on std::reverse_iterator, std::move_iterator, > std::array, as well as std::advance, std::distance, and the > range-access functions std::begin,

Re: Importing gnulib into the gcc tree

2016-07-16 Thread ayush goel
Hi, Thanks for the feedbacks. —> I’m already configuring gcc with multiple languages and multilib enabled —> The changes have been bootstrapped and regression tested (complete check,  make -k -j20 check). —> As mentioned, I have locally removed obstack.[ch] from libiberty and built and tested

Re: [PATCH] c++/58796 Make nullptr match exception handlers of pointer type

2016-07-16 Thread Andreas Schwab
* g++.dg/cpp0x/nullptr35.C (caught): Fix typo. diff --git a/gcc/testsuite/g++.dg/cpp0x/nullptr35.C b/gcc/testsuite/g++.dg/cpp0x/nullptr35.C index 2f93ce1..c84966f 100644 --- a/gcc/testsuite/g++.dg/cpp0x/nullptr35.C +++ b/gcc/testsuite/g++.dg/cpp0x/nullptr35.C @@ -11,7 +11,7 @@ int

Re: [PATCH] c++/58796 Make nullptr match exception handlers of pointer type

2016-07-16 Thread Jakub Jelinek
On Fri, Jul 15, 2016 at 11:14:03PM +0100, Jonathan Wakely wrote: > On 15/07/16 22:53 +0100, Jonathan Wakely wrote: > >On 15/07/16 23:36 +0200, Jakub Jelinek wrote: > >>On Fri, Jul 15, 2016 at 10:07:03PM +0100, Jonathan Wakely wrote: > + if (typeid (*this) == typeid(__pointer_type_info)) >