Ping^2.
Thanks!
-Zhenqiang
On 2 April 2013 17:54, Zhenqiang Chen zhenqiang.c...@linaro.org wrote:
Ping.
On 21 March 2013 14:58, Zhenqiang Chen zhenqiang.c...@linaro.org wrote:
Hi,
When shrink-wrap is enabled, the returns from simple-return path and
normal return path can be merged. The
Ping.
Thanks!
-Zhenqiang
On 3 April 2013 14:50, Zhenqiang Chen zhenqiang.c...@linaro.org wrote:
On 2 April 2013 17:55, Ramana Radhakrishnan ramana@googlemail.com wrote:
On Thu, Mar 21, 2013 at 7:03 AM, Zhenqiang Chen
zhenqiang.c...@linaro.org wrote:
Hi,
The patch is to enable
Hello world,
the attached patch does some optimization on
power using ishft and iand, as discussed in the PR.
I have left out handling real numbers, that should be left
to the middle-end (PR 57073).
Regression-tested. OK for trunk?
Thomas
2013-04-28 Thomas Koenig
Am 28.04.2013 10:32, schrieb Thomas Koenig:
the attached patch does some optimization on
power using ishft and iand, as discussed in the PR.
I have left out handling real numbers, that should be left
to the middle-end (PR 57073).
Regression-tested. OK for trunk?
OK - thanks for the patch.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'gcc' has been submitted
by the Swedish team of translators. The file is available at:
http://translationproject.org/latest/gcc/sv.po
(This file, 'gcc-4.8.0.sv.po', has
On Sun, Apr 28, 2013 at 10:32:28AM +0200, Thomas Koenig wrote:
Hello world,
the attached patch does some optimization on
power using ishft and iand, as discussed in the PR.
I have left out handling real numbers, that should be left
to the middle-end (PR 57073).
Regression-tested. OK
This fixes shared_ptr to allow 'final' allocators to be used.
As an added bonus it also reduces the memory footprint of the
shared_ptr control block when constructing a shared_ptr with an empty
deleter or when using make_shared/allocate_shared.
I decided not to use std::tuple here, because it's
On 26/04/13 16:27, Tom de Vries wrote:
On 25/04/13 16:19, Richard Biener wrote:
SNIP
and compared to the previous patch changed the tree-ssa-tailmerge.c
part to deal with merging of loop latch and loop preheader (even
if that's a really bad idea) to not regress gcc.dg/pr50763.c.
Any
* include/bits/hashtable_policy.h (_Hashtable_ebo_helper): Fix
comment.
* include/std/mutex (__recursive_mutex_base): Likewise.
Tested x86_64-linux, committed to trunk.
commit eebe0bf329438168c002754c4a0d5b7e1b59e6f5
Author: Jonathan Wakely jwakely@gmail.com
Date:
Am 28.04.2013 12:10, schrieb Tobias Burnus:
OK - thanks for the patch.
I wonder whether one should also handle:
1**k == 1
Committed, thanks for the review!
I will do 1**k as a followup patch which should be quite obvious :-)
Regarding PR 57073, the real case - I have never worked with
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Aldy Hernandez
Sent: Saturday, April 27, 2013 1:30 PM
To: Iyer, Balaji V
Cc: Jakub Jelinek; Richard Henderson; gcc-patches@gcc.gnu.org
Subject: Re: [gomp4] Some progress on
On 04/27/2013 02:59 AM, Jakub Jelinek wrote:
On Sat, Apr 27, 2013 at 01:03:17AM -0400, Ed Smith-Rowland wrote:
In htdocs/projects/cxx1y.html it says no for support of binary
literals. I think that's a Yes actually.
Here is a little patchlet.
Am I missing something?
So yes... ;-) I had
- Original Message -
From: Michael Meissner meiss...@linux.vnet.ibm.com
To: Vladimir Makarov vmaka...@redhat.com
Cc: Michael Meissner meiss...@linux.vnet.ibm.com, David Edelsohn
dje@gmail.com, gcc-patches gcc-patches@gcc.gnu.org, Peter Bergner
berg...@vnet.ibm.com,
It's a minor regression present on mainline and 4.8 branch: the size functions
are output as (no-fn) in the .original dump file.
Bootstrapped/regtested on x86_64-suse-linux, applied on the mainline and 4.8
branch as obvious (this only affects the Ada compiler).
2013-04-28 Eric Botcazou
Thomas Koenig wrote:
Regarding PR 57073, the real case - I have never worked with
GIMPLE, so I have no real idea how to start this.
Any volunteers? Or should we handle this in the Fortran front
end after all?
I think one should do it in the middle end. Actually, it shouldn't be
that
Hi,
committed the patch below as obvious:
Index: ChangeLog
===
--- ChangeLog (revision 198377)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2013-04-28 Janne Blomqvist j...@gcc.gnu.org
+
+ * intrinsics/system_clock.c
PING
On Fri, Apr 19, 2013 at 1:30 PM, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
Hi,
the attached patch improves the performance for unformatted and
unbuffered files. Currently unbuffered unformatted really means that
we don't buffer anything and use the POSIX I/O syscalls directly.
The patch looks good to me.
Jason
On 04/27/2013 05:17 PM, Paolo Carlini wrote:
Assuming as obvious that we don't want to crash on it, the interesting
issue is whether we want the static_asserts to both fail or succeed: in
practice, a rather recent ICC I have at hand fails both; a rather recent
clang++ passes both (consistently
On Apr 26, 2013, at 4:05 AM, Bernd Schmidt ber...@codesourcery.com wrote:
On 04/24/2013 09:14 PM, DJ Delorie wrote:
24 bits stored as three bytes, or four? How does this affect vtable
layout? I would have expected the C++ frontend and libsupc++ to
currently be inconsistent with each other
On Apr 26, 2013, at 8:17 AM, Michael Zolotukhin
michael.v.zolotuk...@gmail.com wrote:
This patch allows to use attributes inside other attributes in MD-files.
Sweet, I like it…
The problem is a bit nested but the solution is obvious:
The type (TREE_TYPE) of an array is an array type - and one needs to
drill one level deeper to get the element type. For allocatable scalar
coarrays, one has an array descriptor to handle the bounds (and, with
-fcoarray=lib, to store
Hi,
while looking at system_clock due to the recent Windows patches, it
occurred to me that the Unix versions can be simplified somewhat. The
attached patch does this.
Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
2013-04-28 Janne Blomqvist j...@gcc.gnu.org
*
Hi,
On 04/28/2013 09:10 PM, Jason Merrill wrote:
On 04/27/2013 05:17 PM, Paolo Carlini wrote:
Assuming as obvious that we don't want to crash on it, the interesting
issue is whether we want the static_asserts to both fail or succeed: in
practice, a rather recent ICC I have at hand fails both;
I have patches to let one specify a precision for partial int types,
easy enough to do, and the rest of the compiler plays nicely for the
most part with it...
If you can make size_t truly be a 24-bit value, I'd be very happy :-)
On Sat, Apr 27, 2013 at 11:07:50AM +0200, Uros Bizjak wrote:
Yes, please add a new predicate, the pattern is much more descriptive
this way. (Without the predicate, it looks like an expander that
generates a RTX fragment, used instead of gen_RTX... sequences).
Ok, updated patch below.
On 04/28/2013 11:13 PM, DJ Delorie wrote:
I have patches to let one specify a precision for partial int types,
easy enough to do, and the rest of the compiler plays nicely for the
most part with it...
If you can make size_t truly be a 24-bit value, I'd be very happy :-)
This confuses me a
OK.
Jason
For m32c chips, The address space is a flat 24-bit address space.
Address registers are 24 bits (i.e. they cannot hold an SImode) but
size_t is 16 bits originally because there aren't enough 24-bit math
ops and 32-bit math is too expensive. I've tried to use PSImode for
size_t recently
On 04/28/2013 11:31 AM, Janne Blomqvist wrote:
PING
On Fri, Apr 19, 2013 at 1:30 PM, Janne Blomqvist
blomqvist.ja...@gmail.com wrote:
Hi,
the attached patch improves the performance for unformatted and
unbuffered files. Currently unbuffered unformatted really means that
we don't buffer
On 04/28/2013 01:16 PM, Janne Blomqvist wrote:
Hi,
while looking at system_clock due to the recent Windows patches, it
occurred to me that the Unix versions can be simplified somewhat. The
attached patch does this.
Regtested on x86_64-unknown-linux-gnu, Ok for trunk?
OK for trunk.
Greetings from South Korea
I have a proposition for you to the tune of Fifty Million EUR, if interested,
kindly reply for specifics
Regards,
Shin Eon-seong
32 matches
Mail list logo
