On Sun, Apr 28, 2013 at 11:43 PM, Jakub Jelinek wrote:
> 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 inste
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
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 trun
On 04/28/2013 11:31 AM, Janne Blomqvist wrote:
> PING
>
> On Fri, Apr 19, 2013 at 1:30 PM, Janne Blomqvist
> 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
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 (different
OK.
Jason
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 confu
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. Boots
> 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 :-)
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; a
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
* intrinsics/system_clock (gf_gettime_mo
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 the
On Apr 26, 2013, at 8:17 AM, Michael Zolotukhin
wrote:
> This patch allows to use attributes inside other attributes in MD-files.
Sweet, I like it…
On Apr 26, 2013, at 4:05 AM, Bernd Schmidt 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 given such a setup
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 wi
The patch looks good to me.
Jason
PING
On Fri, Apr 19, 2013 at 1:30 PM, Janne Blomqvist
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. With
> the patch, we us
Hi,
committed the patch below as obvious:
Index: ChangeLog
===
--- ChangeLog (revision 198377)
+++ ChangeLog (working copy)
@@ -1,3 +1,8 @@
+2013-04-28 Janne Blomqvist
+
+ * intrinsics/system_clock.c (system_clock_4): Fi
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 difficul
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
- Original Message -
From: "Michael Meissner"
To: "Vladimir Makarov"
Cc: "Michael Meissner" , "David Edelsohn"
, "gcc-patches" , "Peter Bergner"
, aavru...@redhat.com
Sent: Friday, April 26, 2013 7:13:55 PM
Subject: Re: RFA: enable LRA for rs6000
On Fri, Apr 26, 2013 at 07:00:37PM -0
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 tested
> -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 progre
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
GI
* 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
Date: Sun Apr 28 12:49:20 2013
On 26/04/13 16:27, Tom de Vries wrote:
> On 25/04/13 16:19, Richard Biener wrote:
>
>> 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 sug
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 a
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-teste
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 just
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 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
PR fortr
31 matches
Mail list logo
