Uros Bizjak schrieb:
On Thu, Aug 23, 2012 at 10:46 PM, Georg-Johann Lay a...@gjlay.de 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
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. :)
Regards,
chenwj
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
On Sat, Aug 25, 2012 at 11:55 AM, Georg-Johann Lay a...@gjlay.de 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_RTX.
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 (abstract
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 ubiz...@gmail.com
* target.def (reject_combined_insn): New target hook.
* doc/tm.texi.in
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 not
On 08/24/2012 11:46 PM, Richard Sandiford wrote:
Andrew Pinskipins...@gmail.com writes:
On Fri, Aug 24, 2012 at 10:08 PM, Andrew Pinskipins...@gmail.com wrote:
On Wed, Aug 22, 2012 at 7:15 PM, Sandra Loosemore
san...@codesourcery.com wrote:
On 08/21/2012 02:23 PM, Richard Sandiford wrote:
On Sat, Aug 25, 2012 at 8:31 AM, H.J. Lu hjl.to...@gmail.com 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]: ***
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 ubiz...@gmail.com
* target.def (reject_combined_insn): New target hook.
*
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
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 ubiz...@gmail.com
* config/i386/i386.h (FP_REG_P): Remove macro.
(FP_REGNO_P): Ditto.
(HARD_REGNO_NREGS): Use STACK_REGNO_P
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 ubiz...@gmail.com
* target.def (reject_combined_insn): New target
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
On Sat, Aug 25, 2012 at 7:22 PM, Hans-Peter Nilsson h...@bitrange.com 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 ubiz...@gmail.com
* target.def
Uros Bizjak schrieb:
On Sat, Aug 25, 2012 at 6:54 PM, Georg-Johann Lay a...@gjlay.de 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 ubiz...@gmail.com
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'.
Reject?
PR libstdc++/54248
* include/bits/concept_check.h: Replace references to boost
namespace.
Committed to trunk.
commit c545fcbc54ee0a5990c5c9cf84116b55ab07475a
Author: Jonathan Wakely jwakely@gmail.com
Date: Sat Aug 25 19:49:10 2012 +0100
PR libstdc++/54248
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
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, I walk
On Sat, Aug 25, 2012 at 11:21 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Sat, Aug 25, 2012 at 7:22 PM, Hans-Peter Nilsson h...@bitrange.com wrote:
v2 patch differences:
- moves hook description text to target.def
- fixes error path to clear clobbers, as expected by recog_for_combine
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 for
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
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
The current random 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
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. One has:
if
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 giecr...@stegny.2a.pl
*
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
Ian Lance Taylor schrieb:
On Sat, Aug 25, 2012 at 11:21 AM, Uros Bizjak ubiz...@gmail.com wrote:
On Sat, Aug 25, 2012 at 7:22 PM, Hans-Peter Nilsson h...@bitrange.com wrote:
v2 patch differences:
- moves hook description text to target.def
- fixes error path to clear clobbers, as expected by
On Sat, 25 Aug 2012, Uros Bizjak wrote:
On Sat, Aug 25, 2012 at 7:22 PM, Hans-Peter Nilsson h...@bitrange.com 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
On Sat, Aug 25, 2012 at 8:52 AM, Sandra Loosemore
san...@codesourcery.com wrote:
On 08/24/2012 11:46 PM, Richard Sandiford wrote:
Andrew Pinskipins...@gmail.com writes:
On Fri, Aug 24, 2012 at 10:08 PM, Andrew Pinskipins...@gmail.com
wrote:
On Wed, Aug 22, 2012 at 7:15 PM, Sandra
Hi,
(please remember to CC libstdc++ for discussions involving the library)
On 08/25/2012 10:31 PM, Ulrich Drepper wrote:
The current random 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()
.. 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.
Hello,
This one makes system.h pull in cstdlib when compiling as C++.
It fixes issues when e.g. including algorithm.
Tested on my SH cross compiler config with 'make all-gcc', after
including the following std headers in one of the RTL passes:
algorithm limits bitset cassert cctype cerrno cfloat
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 jimenezr...@gmail.com
*
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
*
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
On Sat, Aug 25, 2012 at 5:42 PM, Paolo Carlini paolo.carl...@oracle.com 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
On 26 August 2012 00:33, Ulrich Drepper drep...@gmail.com wrote:
On Sat, Aug 25, 2012 at 5:42 PM, Paolo Carlini paolo.carl...@oracle.com
wrote:
Personally, assuming the name itself is already reserved / used elsewhere,
That was my thinking as well. There shouldn't be any further namespace
On Sat, Aug 25, 2012 at 7:37 PM, Jonathan Wakely jwakely@gmail.com 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
On Wed, 6 Jun 2012, Steven Bosscher wrote:
The attached patch removes the -fconserve-space flag, as discussed last
week. Bootstrappedtested 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
2012-08-26 Jonathan Wakely jwakely@gmail.com
Geoff Romer gro...@google.com
PR libstdc++/54351
* include/bits/unique_ptr.h (unique_ptrT::~unique_ptr): Do not use
reset().
(unique_ptrT[]::~unique_ptr()): Likewise.
*
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
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:
Ulrich Drepper drep...@gmail.com 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
On Sat, Aug 25, 2012 at 7:28 PM, Gerald Pfeifer ger...@pfeifer.com 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
I had a nagging feeling there was a patch I didn't commit.
Patch approval link, having link to the patch:
http://gcc.gnu.org/ml/gcc-patches/2009-03/msg01509.html
(modulo obvious adjustments to copyright line)
brgds, H-P
On Saturday 25 August 2012 18:31:32 H.J. Lu wrote:
On Sat, Aug 25, 2012 at 3:27 PM, Mike Frysinger vap...@gentoo.org 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 hjl.to...@gmail.com wrote:
Hi,
Setting
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
[dropping the bogus address I accidentally typed on the command line]
On Sat, Aug 25, 2012 at 7:08 PM, Cary Coutant ccout...@google.com 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
On 08/25/2012 07:39 PM, Ulrich Drepper wrote:
On Sat, Aug 25, 2012 at 7:37 PM, Jonathan Wakely jwakely@gmail.com 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
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 r...@verizon.net wrote:
diff --git a/fixincludes/fixinc.in b/fixincludes/fixinc.in
index e73aed9..de7be35 100755
--- a/fixincludes/fixinc.in
+++ b/fixincludes/fixinc.in
@@
On Sat, Aug 25, 2012 at 8:29 PM, Paolo Carlini paolo.carl...@oracle.com 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:
templatetypename _RealType = double
class
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
54 matches
Mail list logo
