Re: [PATCH v2, middle-end]: Introduce TARGET_REJECT_COMBINED_INSN target hook

On Sun, Aug 26, 2012 at 8:11 AM, Uros Bizjak wrote: >> What if we just add a global variable during_combine, and the insn >> predicates can check that variable? Then we wouldn't need a new >> target hook, one that seems slightly obscure to me. > > No, in x86 case we need to look at operand const

Re: [PATCH v2, middle-end]: Introduce TARGET_REJECT_COMBINED_INSN target hook

On Sat, Aug 25, 2012 at 9:40 PM, Ian Lance Taylor wrote: v2 patch differences: - moves hook description text to target.def - fixes error path to clear clobbers, as expected by recog_for_combine callers 2012-08-25 Uros Bizjak * target.def (reject_c

Re: C++ PATCH for default template argument access control SFINAE

On 08/25/2012 01:09 PM, Paolo Carlini wrote: suppose it's unintended, I can fix that at the first occasion... (also, the testcase itself has a few a little mysterious commented out lines, but I'm not going to insist ;) ;) Right, I forgot to uncomment those. Fixed, thanks. Jason

Re: random numbers in bulk

On Sat, Aug 25, 2012 at 8:29 PM, Paolo Carlini wrote: > Understood, but you do *not* loose performance by having those fill functions > templates, Let's see. The prototypes will then be something like this: template class normal_distribution { template void fil

Re: VxWorks Patches Back from the Dead!

On 8/24/2012 4:59 PM, Bruce Korb wrote: Hi Robert, If you are going to defer, then: On Fri, Aug 24, 2012 at 1:20 PM, rbmj wrote: diff --git a/fixincludes/fixinc.in b/fixincludes/fixinc.in index e73aed9..de7be35 100755 --- a/fixincludes/fixinc.in +++ b/fixincludes/fixinc.in @@ -128,6 +128,18 @

Re: random numbers in bulk

On 08/25/2012 07:39 PM, Ulrich Drepper wrote: On Sat, Aug 25, 2012 at 7:37 PM, Jonathan Wakely wrote: But iterators don't have to imply non-sequential storage. Using iterators instead of pointers would allow you to store them in a std::deque, for example, or in a std::vector using std::back_ins

Re: [google/gcc-4_7, trunk] Fix problem with -fdebug-types-section and template instantiations

[dropping the bogus address I accidentally typed on the command line] On Sat, Aug 25, 2012 at 7:08 PM, Cary Coutant wrote: > This patch is for trunk and the google/gcc-4_7 branch. > > When a class template instantiation is moved into a separate type unit, > it can bring along a lot of other refer

[google/gcc-4_7, trunk] Fix problem with -fdebug-types-section and template instantiations

This patch is for trunk and the google/gcc-4_7 branch. When a class template instantiation is moved into a separate type unit, it can bring along a lot of other referenced types into the type unit, especially if the template is derived from another (large) type that does not have an actually have

Re: PATCH: Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes

On Saturday 25 August 2012 18:31:32 H.J. Lu wrote: > On Sat, Aug 25, 2012 at 3:27 PM, Mike Frysinger wrote: > > On Saturday 25 August 2012 11:58:08 H.J. Lu wrote: > >> On Sat, Aug 25, 2012 at 8:31 AM, H.J. Lu wrote: > >> > Hi, > >> > > >> > Setting HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes causes:

Committed: old patch to btest-gcc.sh: Add libmudflap.sum, if it exists.

I had a nagging feeling there was a patch I didn't commit. Patch approval link, having link to the patch: (modulo obvious adjustments to copyright line) brgds, H-P

Re: Patches to enable -ftrack-macro-expansion by default

On Sat, Aug 25, 2012 at 7:28 PM, Gerald Pfeifer wrote: > On Mon, 30 Apr 2012, Dodji Seketeli wrote: >> I have finally applied this series of 14 patches to the mainline today. >> The SVN revisions are from r186965 to r186978. > > Shouldn't we document this in the release notes? > > What do you guys

Re: random numbers in bulk

Ulrich Drepper ha scritto: >Yes, and this is already trivial to do with the operator() interface. > >The fill() interface is needed for performance, everything else is >taken care by the operator() interface. Understood, but you do *not* loose performance by having those fill functions template

Re: Patches to enable -ftrack-macro-expansion by default

On Mon, 30 Apr 2012, Dodji Seketeli wrote: > I have finally applied this series of 14 patches to the mainline today. > The SVN revisions are from r186965 to r186978. Shouldn't we document this in the release notes? What do you guys think about the following? Suggestions welcome. Gerald Index:

Re: [v3] correction to C++11 status table

On 23 August 2012 09:38, Jonathan Wakely wrote: > PR libstdc++/54354 > * doc/xml/manual/status_cxx2011.xml: Note missing manipulators. > * doc/html/*: Regenerate. > > Committed to trunk. I forgot to attach the patch, here it is. diff --git a/libstdc++-v3/doc/xml/manual/stat

[v3] fix PR 54351

2012-08-26 Jonathan Wakely Geoff Romer PR libstdc++/54351 * include/bits/unique_ptr.h (unique_ptr::~unique_ptr): Do not use reset(). (unique_ptr::~unique_ptr()): Likewise. * testsuite/20_util/unique_ptr/54351.cc: New. * testsuite/20_

Re: [patch] Remove -fconserve-space

On Wed, 6 Jun 2012, Steven Bosscher wrote: > The attached patch removes the -fconserve-space flag, as discussed last > week. Bootstrapped&tested on powerpc64-unknown-linux-gnu. OK for trunk? How about the following for the release notes? (Happy to use a different/better rationale. This one's bo

Re: random numbers in bulk

On Sat, Aug 25, 2012 at 7:37 PM, Jonathan Wakely wrote: > But iterators don't have to imply non-sequential storage. Using > iterators instead of pointers would allow you to store them in a > std::deque, for example, or in a std::vector using > std::back_insert_iterator. Yes, and this is already t

Re: random numbers in bulk

On 26 August 2012 00:33, Ulrich Drepper wrote: > On Sat, Aug 25, 2012 at 5:42 PM, Paolo Carlini > wrote: >> Personally, assuming the name itself is already reserved / used elsewhere, > > That was my thinking as well. There shouldn't be any further namespace > problem. > > >> .. another prelimi

Re: random numbers in bulk

On Sat, Aug 25, 2012 at 5:42 PM, Paolo Carlini wrote: > Personally, assuming the name itself is already reserved / used elsewhere, That was my thinking as well. There shouldn't be any further namespace problem. > .. another preliminary comment of mine: why not using iterators to specify > thos

Fix PR rtl-optimization/54088

This is a regression present on mainline and 4.7 branch and a variant of: http://gcc.gnu.org/ml/gcc-patches/2012-05/msg01076.html The difference is that there is a barrier between the CALL_INSN and the CALL_ARG_LOCATION note (delete_related_insns is called from reorg.c and the dbr pass is run a

[v3] fix PR 54297 - segfaults with std::async

This fixes a stupid mistake I made where the functor and asynchronous result can go out of scope before the async thread is joined. The _Async_state_common destructor still needs to be exported from the library, which is what the macro hack is for. PR libstdc++/54297 * include/std

Re: [PATCH] Trivial typo: remove extra whitespace from doc

On Thu, 26 Apr 2012, Ricardo Catalinas Jiménez wrote: > Remove extra whitespace from doc. Thank you, Ricardo. I created a ChangeLog entry and committed your patch. Sorry that it took us a bit to get to it. Gerald 2012-08-26 Ricardo Catalinas Jiménez * doc/extend.texi (__atomic Buil

Re: PATCH: Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes

On Sat, Aug 25, 2012 at 3:27 PM, Mike Frysinger wrote: > On Saturday 25 August 2012 11:58:08 H.J. Lu wrote: >> On Sat, Aug 25, 2012 at 8:31 AM, H.J. Lu wrote: >> > Hi, >> > >> > Setting HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes causes: >> > >> > as: error while loading shared libraries: >> > /build

Re: PATCH: Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes

On Saturday 25 August 2012 11:58:08 H.J. Lu wrote: > On Sat, Aug 25, 2012 at 8:31 AM, H.J. Lu wrote: > > Hi, > > > > Setting HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes causes: > > > > as: error while loading shared libraries: > > /builddir/build/BUILD/binutils/./opcodes/.libs/libopcodes-2.23.51.0.2

C++ conversion - pull in cstdlib

Hello, This one makes system.h pull in when compiling as C++. It fixes issues when e.g. including . Tested on my SH cross compiler config with 'make all-gcc', after including the following std headers in one of the RTL passes: e e . My host GCC is: g

Re: random numbers in bulk

.. another preliminary comment of mine: why not using iterators to specify those ranges, instead of plain pointers? Aren't the forward iterators generally Ok, like for std::fill itself? Paolo.

Re: random numbers in bulk

Hi, (please remember to CC libstdc++ for discussions involving the library) On 08/25/2012 10:31 PM, Ulrich Drepper wrote: The current interface as defined in the standard is not well suited for heavy users such as simulations. The only way to get a number is using the operator() one-by-one.

Re: [PATCH, MIPS] fix MIPS16 jump table overflow

On Sat, Aug 25, 2012 at 8:52 AM, Sandra Loosemore wrote: > On 08/24/2012 11:46 PM, Richard Sandiford wrote: >> >> Andrew Pinski writes: >>> >>> On Fri, Aug 24, 2012 at 10:08 PM, Andrew Pinski >>> wrote: On Wed, Aug 22, 2012 at 7:15 PM, Sandra Loosemore wrote: > > On 08/21

Re: [PATCH v2, middle-end]: Introduce TARGET_REJECT_COMBINED_INSN target hook

On Sat, 25 Aug 2012, Uros Bizjak wrote: > On Sat, Aug 25, 2012 at 7:22 PM, Hans-Peter Nilsson wrote: > > Maybe mention that the default is to allow all combinations for > > which a pattern match? And that the reason to disallow them can > > be that they're known to result in suboptimal code? Or

Re: [PATCH v2, middle-end]: Introduce TARGET_REJECT_COMBINED_INSN target hook

Ian Lance Taylor schrieb: On Sat, Aug 25, 2012 at 11:21 AM, Uros Bizjak wrote: On Sat, Aug 25, 2012 at 7:22 PM, Hans-Peter Nilsson wrote: v2 patch differences: - moves hook description text to target.def - fixes error path to clear clobbers, as expected by recog_for_combine callers 2012-08-

combine vec_perm_expr with constructor

Hello, this patch (bootstrapped and regtested on x86_64) deals with the same issue as the one at: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg00205.html that is combining a shuffle of a constructor into a constructor, but at the tree-ssa level. An advantage is that it works with any size of

Re: Let INSTALL/README mention the instructions on line

On Wed, 15 Feb 2012, Křištof Želechovski wrote: > Please consider the following patch: Thank you, Křištof! I made some small tweaks, created a ChangeLog entry and applied the variation of your patch that is included below. Gerald 2012-08-25 Křištof Želechovski * INSTALL/README: Also

Re: [Fortran] PR37336 - FIINAL patch [1/n]: Implement the finalization wrapper subroutine

On 25/08/2012 22:06, Tobias Burnus wrote: If comp has finalizable subcomponents, it has a finalization wrapper, which is (or should be) caught above, so this branch is (or should be) unreachable. >>> I probably miss something, but I don't see why this branch should >>> be unreachable

random numbers in bulk

The current interface as defined in the standard is not well suited for heavy users such as simulations. The only way to get a number is using the operator() one-by-one. This can lead to significant overhead and, perhaps more importantly, prevents optimizations from being applied. For instance,

another wrong-code problem with -fstrict-volatile-bitfields

While I was grovelling around trying to swap in more state on the bitfield store/extract code for the patch rewrite being discussed here: http://gcc.gnu.org/ml/gcc-patches/2012-08/msg01546.html I found a reference to PR23623 and found that it is broken again, but in a different way. On ARM EA

Re: [Fortran] PR37336 - FIINAL patch [1/n]: Implement the finalization wrapper subroutine

Mikael Morin wrote: What if only comp's subcomponents are finalizable, the finalization wrapper should still be called, shouldn't it? Well, that's handled in the "else" branch. There, I walk all subcomponents. I do not need to walk them in case there is a finalizer as the called finalization wra

Re: [Patch, fortran] [0/5] PR 45586: restrict vs. non-restrict type compatibility hell

On 25/08/2012 20:00, Dominique Dhumieres wrote: > Dear Mikael, > > Your set of patches works as defined, i.e., it fixes pr45586 without > regression on the test suite. However, If the test suite is run with > -flto, there are still some failures depending on the way gcc is > configured. Thanks

Re: [PATCH v2, middle-end]: Introduce TARGET_REJECT_COMBINED_INSN target hook

On Sat, Aug 25, 2012 at 11:21 AM, Uros Bizjak wrote: > On Sat, Aug 25, 2012 at 7:22 PM, Hans-Peter Nilsson wrote: > >>> v2 patch differences: >>> - moves hook description text to target.def >>> - fixes error path to clear clobbers, as expected by recog_for_combine >>> callers >>> >>> 2012-08-25

Re: [Fortran] PR37336 - FIINAL patch [1/n]: Implement the finalization wrapper subroutine

On 25/08/2012 17:21, Tobias Burnus wrote: > (And nonallocatble, nonpointer > components do not exist.) I missed that indeed. >> What if only comp's subcomponents are finalizable, the finalization >> wrapper should still be called, shouldn't it? > > Well, that's handled in the "else" branch. There

Re: [PATCH v2, middle-end]: Introduce TARGET_REJECT_COMBINED_INSN target hook

Oleg Endo schrieb: On Sat, 2012-08-25 at 20:25 +0200, Georg-Johann Lay wrote: BTW: while I typed the lines above I find it more natural to return "true" for good patterns and "false" for bad patterns and not vice versa. But that's just a matter of taste. But then that won't fit with 'reject_

[v3] fix PR 54248

PR libstdc++/54248 * include/bits/concept_check.h: Replace references to boost namespace. Committed to trunk. commit c545fcbc54ee0a5990c5c9cf84116b55ab07475a Author: Jonathan Wakely Date: Sat Aug 25 19:49:10 2012 +0100 PR libstdc++/54248 * include/bits/c

Re: [PATCH v2, middle-end]: Introduce TARGET_REJECT_COMBINED_INSN target hook

On Sat, 2012-08-25 at 20:25 +0200, Georg-Johann Lay wrote: > BTW: while I typed the lines above I find it more natural to > return "true" for good patterns and "false" for bad patterns > and not vice versa. But that's just a matter of taste. But then that won't fit with 'reject_combined_insn'. R

Re: [PATCH v2, middle-end]: Introduce TARGET_REJECT_COMBINED_INSN target hook

Uros Bizjak schrieb: On Sat, Aug 25, 2012 at 6:54 PM, Georg-Johann Lay wrote: Hello! v2 patch differences: - moves hook description text to target.def - fixes error path to clear clobbers, as expected by recog_for_combine callers 2012-08-25 Uros Bizjak * target.def (reject_combin

Re: [PATCH v2, middle-end]: Introduce TARGET_REJECT_COMBINED_INSN target hook

On Sat, Aug 25, 2012 at 7:22 PM, Hans-Peter Nilsson wrote: >> v2 patch differences: >> - moves hook description text to target.def >> - fixes error path to clear clobbers, as expected by recog_for_combine >> callers >> >> 2012-08-25 Uros Bizjak >> >> * target.def (reject_combined_insn):

Re: [Patch, fortran] [0/5] PR 45586: restrict vs. non-restrict type compatibility hell

Dear Mikael, Your set of patches works as defined, i.e., it fixes pr45586 without regression on the test suite. However, If the test suite is run with -flto, there are still some failures depending on the way gcc is configured. Configured with: ../p_work/configure --prefix=/opt/gcc/gcc4.8p-190

Re: [PATCH v2, middle-end]: Introduce TARGET_REJECT_COMBINED_INSN target hook

On Sat, Aug 25, 2012 at 6:54 PM, Georg-Johann Lay wrote: >> Hello! >> >> v2 patch differences: >> - moves hook description text to target.def >> - fixes error path to clear clobbers, as expected by recog_for_combine >> callers >> >> 2012-08-25 Uros Bizjak >> >> * target.def (reject_com

Re: [PATCH v2, middle-end]: Introduce TARGET_REJECT_COMBINED_INSN target hook

On Sat, 25 Aug 2012, Uros Bizjak wrote: > Hello! > > v2 patch differences: > - moves hook description text to target.def > - fixes error path to clear clobbers, as expected by recog_for_combine callers > > 2012-08-25 Uros Bizjak > > * target.def (reject_combined_insn): New target hook. >

[PATCH, i386]: Remove FP_REG_P and FP_REGNO_P

Hello! These macros are the same as STACK_REG_P and STACK_REGNO_P. Also changes one instance that leaked to reg-stack.c 2012-08-25 Uros Bizjak * config/i386/i386.h (FP_REG_P): Remove macro. (FP_REGNO_P): Ditto. (HARD_REGNO_NREGS): Use STACK_REGNO_P instead of FP_REGNO

Re: C++ PATCH for default template argument access control SFINAE

On 08/25/2012 05:29 AM, Jason Merrill wrote: I noticed that the earlier work on access control SFINAE didn't handle default template arguments; we weren't checking their access against the right declarations at all. In order to do that, we need to generate the DECL to compare against in fn_typ

Re: [PATCH v2, middle-end]: Introduce TARGET_REJECT_COMBINED_INSN target hook

Uros Bizjak schrieb: Hello! v2 patch differences: - moves hook description text to target.def - fixes error path to clear clobbers, as expected by recog_for_combine callers 2012-08-25 Uros Bizjak * target.def (reject_combined_insn): New target hook. * doc/tm.texi.in (TARGET_

PATCH: Don't set HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes

On Sat, Aug 25, 2012 at 8:31 AM, H.J. Lu wrote: > Hi, > > Setting HOST_LIB_PATH_bfd/HOST_LIB_PATH_opcodes causes: > > as: error while loading shared libraries: > /builddir/build/BUILD/binutils/./opcodes/.libs/libopcodes-2.23.51.0.2-0.1.fc17.so: > file too short > make[4]: *** [gold-threads.o] Erro

Re: [PATCH, MIPS] fix MIPS16 jump table overflow

On 08/24/2012 11:46 PM, Richard Sandiford wrote: Andrew Pinski writes: On Fri, Aug 24, 2012 at 10:08 PM, Andrew Pinski wrote: On Wed, Aug 22, 2012 at 7:15 PM, Sandra Loosemore wrote: On 08/21/2012 02:23 PM, Richard Sandiford wrote: Would be nice to add a compile test for -mabi=64 just t

Re: [Fortran] PR37336 - FIINAL patch [1/n]: Implement the finalization wrapper subroutine

Dear Mikael, dear all, Mikael Morin wrote: the patch mixes deallocation and finalization, which are treated separately in the standard. First, I want to remark that the standard - in many cases - does not require memory freeing ("deallocation"), it "merely" makes it possible that one does no

[PATCH v2, middle-end]: Introduce TARGET_REJECT_COMBINED_INSN target hook

Hello! v2 patch differences: - moves hook description text to target.def - fixes error path to clear clobbers, as expected by recog_for_combine callers 2012-08-25 Uros Bizjak * target.def (reject_combined_insn): New target hook. * doc/tm.texi.in (TARGET_REJECT_COMBINED_INSN):

Re: [Fortran] PR37336 - FIINAL patch [1/n]: Implement the finalization wrapper subroutine

On 19/08/2012 19:50, Tobias Burnus wrote: > Dear all, > > attached is a slightly updated patch: > > * Call finalizers of nonallocatable, nonpointer components > * Generate FINAL wrapper for abstract types which have a finalizer. (The > allocatable components are deallocated in the first type (ab

Re: [PATCH, middle-end]: Introduce TARGET_REJECT_COMBINED_INSN target hook

On Sat, Aug 25, 2012 at 11:55 AM, Georg-Johann Lay wrote: >>> For the hook in question, it would be the same effort as far as >>> the hook is concerned: Ir really makes no difference if you >>> >>> - Pass X to the hook and return true or false >>> >>> - Pass X to the hook and return X or NULL_RT

Re: Another ping: Reorganized documentation for warnings -- attempt 2

On Fri, 24 Aug 2012, Diego Novillo wrote: > You say that you have sent your copyright paperwork. Is the whole > process finished? Only when the final paperwork is filed with the > FSF can we start accepting significant changes. I see that David Stone is listed with a note of "Assigns Past and F

Re: [doc] Fix typo in gty.texi

On Fri, Aug 24, 2012 at 10:05:06AM -0400, Diego Novillo wrote: > On 2012-08-23 06:55 , 陳韋任 (Wei-Ren Chen) wrote: > > >I think this is much clear than before. The word "modes" in "CFG takes > > various different modes" means different forms, GIMPLE or RTL, right? > > Right. Thanks. :) Rega

Re: [PATCH, middle-end]: Introduce TARGET_REJECT_COMBINED_INSN target hook

Uros Bizjak schrieb: On Thu, Aug 23, 2012 at 10:46 PM, Georg-Johann Lay wrote: For the hook in question, it would be the same effort as far as the hook is concerned: Ir really makes no difference if you - Pass X to the hook and return true or false - Pass X to the hook and return X or NULL_