Fwd: [patch] regex_traits implementation

On Sat, Jun 29, 2013 at 2:39 PM, Paolo Carlini wrote: > Ah, now I see, Catherine told me you would mentor it. Excellent. Then please > properly format the code, adjust the ChangeLog entry (no libstdc++ at the > beginning of each line because the svn diff is invoked inside it) and then we > can

Re: [PATCH, x86] Use vector moves in memmove expanding

On Tue, Jun 25, 2013 at 3:36 PM, Michael Zolotukhin wrote: > Ping. > > On 20 June 2013 20:56, Michael Zolotukhin > wrote: >> It seems that one of the tests needed a small fix. >> Attached is a corrected version. Jan, do you plan to review this patch? It touches the area that you worked on extens

Re: [PATCH, x86] Use vector moves in memmove expanding

> On Tue, Jun 25, 2013 at 3:36 PM, Michael Zolotukhin > wrote: > > Ping. > > > > On 20 June 2013 20:56, Michael Zolotukhin > > wrote: > >> It seems that one of the tests needed a small fix. > >> Attached is a corrected version. > > Jan, do you plan to review this patch? It touches the area that

Re: [patch,i386] Cannot inline sse*.* functions into avx functions

On Sat, Jun 29, 2013 at 12:55 AM, Sriraman Tallam wrote: > Inlining sse* functions into avx is broken? Here is an example: > > __attribute__((always_inline,target("sse3"))) > inline int callee () > { > return 0; > } > > __attribute__((target("avx"))) > inline int caller () > { > return calle

Re: [patch,i386] Cannot inline sse*.* functions into avx functions

> On Sat, Jun 29, 2013 at 12:55 AM, Sriraman Tallam wrote: > > > Inlining sse* functions into avx is broken? Here is an example: > > > > __attribute__((always_inline,target("sse3"))) > > inline int callee () > > { > > return 0; > > } > > > > __attribute__((target("avx"))) > > inline int caller

Re: [patch,i386] Cannot inline sse*.* functions into avx functions

> > What target flags are enabled by AVX? Assumming that all target flags are > positive seems incorrect to me (like -mno-red-zone function can not be inlined > into -mred-zone). Does those conditionally enabled AVX codegen flags have any Actually -mred-zone seems right, but stuff like -msseregp

Re: [patch,i386] Cannot inline sse*.* functions into avx functions

On Sun, Jun 30, 2013 at 11:47 AM, Jan Hubicka wrote: >> >> What target flags are enabled by AVX? Assumming that all target flags are >> positive seems incorrect to me (like -mno-red-zone function can not be >> inlined >> into -mred-zone). Does those conditionally enabled AVX codegen flags have

Re: Fwd: [PATCH] Attribute for unused warning for variables of non-trivial types

Sorry, this has disappeared off my radar for a while. On Wednesday 21 of November 2012, Jason Merrill wrote: > On 11/20/2012 10:39 AM, Lubos Lunak wrote: > >if (TREE_CODE (exp) == VAR_DECL || TREE_CODE (exp) == PARM_DECL) > > -/* Just know that we've seen something for this node. */ > >

[v3] Update container::insert / emplace members to take const_iterator(s) (Part 2)

Hi, this completes the work on std::deque and std::vector. Next: std::list and ext/vstring. Tested x86_64-linux, normal/debug/profile. Thanks, Paolo. / 2013-06-30 Paolo Carlini * include/bits/stl_deque.h (deque<>::insert(iterator, size_type, const

Re: [PATCH, x86] Use vector moves in memmove expanding

On Sun, Jun 30, 2013 at 11:06:47AM +0200, Jan Hubicka wrote: > > On Tue, Jun 25, 2013 at 3:36 PM, Michael Zolotukhin > > wrote: > > > Ping. > > > > > > On 20 June 2013 20:56, Michael Zolotukhin > > > wrote: > > >> It seems that one of the tests needed a small fix. > > >> Attached is a corrected v

unordered containers: reuse nodes on assignment

Hi Here is a patch to reuse nodes on assignment. I took the time to make _ReuseOrAllocNode more flexible in order to remove _MoveReuseOrAllocNode and to use it for the insertion. Note that the friend declaration for _ReuseOrAllocNode used to be wrong because I had left a template par

Re: unordered containers: reuse nodes on assignment

Hi, > Note that the friend declaration for _ReuseOrAllocNode used to be >wrong because I had left a template parameter on the friend declaration > >that I finally removed on the definition. But gcc didn't complained and > >use it as a valid friend declaration, should it be reported as a gcc

Re: unordered containers: reuse nodes on assignment

.. looks like PR39269, but please double check. Paolo.

[patch 0/4] reimplement -fstrict-volatile-bitfields, v3

Here is my third attempt at cleaning up -fstrict-volatile-bitfields. Part 1 removes the warnings and packedp flag. It is the same as in the last version, and has already been approved. I'll skip reposting it since the patch is here already: http://gcc.gnu.org/ml/gcc-patches/2013-06/msg00908

[patch 4/4] -fstrict-volatile-bitfields cleanup v3: remove from defaults on all targets

Since my previous idea of resolving conflicts between -fstrict-volatile-bitfields behavior and the new C/C++ memory model depending on the selected -std= option was shot down http://gcc.gnu.org/ml/gcc-patches/2013-06/msg01163.html it appears that the only way to make -fstrict-volatile-bitfield

[patch 2/4] fix -fstrict-volatile-bitfields bugs, v3

This patch is a rewrite of parts 2, 3, and 4 of the last version of the patch series. It tries to address Bernd Edlinger's comments about the last version in PR56997 and my own dissatisfaction with how messy this code was! The particular problem Bernd pointed out was that, upon finding an un

Re: [patch 4/4] -fstrict-volatile-bitfields cleanup v3: remove from defaults on all targets

Given how much trouble I went through to make it the default, I'd rather not revert all that work... especially since the flag is *required* for proper operation of the hardware on many of these targets. This patch will, or course, silently and obscurely break existing code.