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" + "ranlib", if possible. The problem with th
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 -
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 as slow as the former an
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 wasteful
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 documente
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
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.
> Unfortunately, it's not
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 is_constructible for now, so that we could
>> reuse that at pl
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 TARGET_64BIT. Optimize call to _m
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 cu
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 of course ask whether
> LWG tho
> 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 on
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 t
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, std::rbegin etc.
>
>
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 t
* 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 result
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))
>
17 matches
Mail list logo