Re: std::forward_list optim for always equal allocator

2017-09-11 7:12 GMT+02:00 François Dumont : > When user declare a container iterator like that: > > std::forward_list::iterator it; > > There is no reason to initialize it with a null node pointer. It is just an > uninitialized iterator which is invalid to use except to

Re: Improve int<->FP conversions

On Sun, Sep 10, 2017 at 9:50 PM, Michael Collison wrote: > This patch improves the latency of code by eliminating two FP <-> integer > register transfers. > > An example: > > float f1(float x) > { > int y = x; > return (float)y; > } > > Trunk generates: > > f1: >

Re: std::forward_list optim for always equal allocator

On 08/09/2017 18:19, Jonathan Wakely wrote: On 28/08/17 21:09 +0200, François Dumont wrote: Hi Any news for this patch ? It does remove a constructor: -_Fwd_list_impl(const _Node_alloc_type& __a) -: _Node_alloc_type(__a), _M_head() It was already unused before the

Improve int<->FP conversions

This patch improves the latency of code by eliminating two FP <-> integer register transfers. An example: float f1(float x) { int y = x; return (float)y; } Trunk generates: f1: fcvtzs w0, s0 scvtf s0, w0 ret With the patch we can use the neon scalar

[PATCH] PR target/82166: Update preferred stack boundary for leaf functions

preferred_stack_boundary may not be the minimum stack alignment. For leaf functions without TLS access, max_used_stack_slot_alignment may be smaller. We should update preferred_stack_boundary for leaf functions. Tested on i686 and x86-64. OK for trunk? H.J. --- gcc/ PR target/82166

Re: Ping on MIPS specific patch adds `short_call` synonym for `near` attribute

bootstrap and regtested on mips64el-unknown-linux-gnu. On Sat, Sep 9, 2017 at 2:34 PM, Simon Atanasyan wrote: > Hi Paul, > > Probably the patch in the original message is broken somehow. Anyway I > attach updated patch to this mail. > > $ svn up > Updating '.': > At

Re: [PATCH][PR sanitizer/77631] Support separate debug info in libbacktrace

On Sat, Jul 29, 2017 at 1:42 PM, Denis Khalikov wrote: > > Hello Ian, > thanks for review. > I've updated the patch, can you please take a look. Apologies again for the length of time it took to reply. I've had a hard time understanding the patch. It's quite

[patch, fortran, RFC] warn about out-of-bounds errors in DO loops

Hello world, the attached patch warns about certain cases where out-of-bound array accesses can be detected at compile time. This was inspired by an out-of-bound access in Polyhedron. A preliminary version of this patch has already found one error in the testsuite. The problem is what to warn

Re: [C++ Patch] PR 70621 ("[6/7/8 Regression] ICE on invalid code at -O1 and above on x86_64-linux-gnu in record_reference, at cgraphbuild.c:64")

OK. On Tue, Aug 29, 2017 at 11:33 AM, Paolo Carlini wrote: > Hi, > > in this error recovery regression, we ICE only when optimizing, while > building the cgraph. Avoiding the reported problem seems easy, just check > the return value of duplicate_decls in start_decl and

Re: [PATCH] Remove output_die_symbol

On Tue, Aug 22, 2017 at 1:13 PM, Richard Biener wrote: > > This addresses one postponed feedback from the early LTO debug time > by simply removing output_die_symbol from output_die as we have no > ! die->comdat_type_p symbols left apart from the CU one produced by > LTO debug

C++ PATCH to reduced_constant_expression for partially-initialized objects

A few months back I queued this patch to bring back for GCC 8. Unfortunately I don't remember the context that it came up in, but it affects for instance cases of self-assignment, which can't have a constant value if there is no previous initialization. Tested x86_64-pc-linux-gnu, applying to