Hi Marcus,
Thanks for reviewing the patch and your comments.
>> I'm not sure how good the coverage is from these test cases
The shift instructions are not generated with the test case since
multiply patterns are generated for the same. Its the same case with
other add and sub instructions which
> Thanks, here is a version taking into account all your comments, and which
> still passes bootstrap+testsuite on x86_64-linux-gnu. I am not completely
> sure if there is a point checking !side_effects_p (op1) after rtx_equal_p
> (op0, op1), but I am still doing it as it seems safe.
It's also don
On Tue, 2 Apr 2013, Eric Botcazou wrote:
Thanks, here is a version taking into account all your comments, and which
still passes bootstrap+testsuite on x86_64-linux-gnu. I am not completely
sure if there is a point checking !side_effects_p (op1) after rtx_equal_p
(op0, op1), but I am still doing
> By the way, shouldn't this be:
>
> unsigned HOST_WIDE_INT mask = ((unsigned HOST_WIDE_INT) 2 << (n_elts - 1)) -
> 1;
>
> so it doesn't cause undefined behavior for V64QI?
You're right, but I think that we'd rather write:
if (n_elts == HOST_BITS_PER_WIDE_INT)
mask = -1;
else
mask =
> Well, the goal was to have arbitrary canonicalization for all cases where
> precise rules are not already provided. In (a<<8)|(b>>24), there is no
> obvious reason why lshift should have higher or lower priority than
> rshift, but we don't want to have to write patterns with both orders in
> the
On Sun, Mar 31, 2013 at 10:01:21PM +0200, Manuel López-Ibáñez wrote:
> The following patch implements an option that allows printing the
> diagnostics markers ("error:", "warning:", "note:") in different
> colors (red, magenta, and green, respectively).
Thanks for working on that.
> I followed th
> Using set_block_for_insn instead of using BLOCK_FOR_INSN is the "proper"
> way.
Yes, but BLOCK_FOR_INSN as accessor around INSN_BASIC_BLOCK is ugly and a bit
misleading. Either keep BLOCK_FOR_INSN or make the full change (the number of
occurrences of BLOCK_FOR_INSN in the back-ends is surpris
On Fri, Mar 29, 2013 at 1:05 PM, Steven Bosscher wrote:
> Hello,
>
> It looks like there are places in the middle end that use remove_insn
> on insns that are not actually emitted. This breaks the assert I added
> in df_insn_delete. The patch disables the assert for now. The comment
> before the a
On Fri, Mar 29, 2013 at 6:02 PM, Gabriel Dos Reis wrote:
> Paolo Carlini writes:
>
> | Hi,
> |
> | On 03/29/2013 04:59 PM, Gabriel Dos Reis wrote:
> | > This patch introduces the predicate VAR_P and use it in place of direct
> | >
> | > TREE_CODE (t) == VAR_DECL
> | >
> | > It improves reada
On Tue, Apr 2, 2013 at 4:14 AM, Jakub Jelinek wrote:
> Yeah, IMHO we definitely want to support GCC_COLORS env var or similar, with
> same syntax as e.g. GREP_COLORS, but with different names of the (two
> letter?) color names.
Agreed.
>> This patch only allows two options enable/disable colors
On Tue, Apr 2, 2013 at 4:26 AM, Richard Biener
wrote:
> On Fri, Mar 29, 2013 at 6:02 PM, Gabriel Dos Reis wrote:
>> Paolo Carlini writes:
>>
>> | Hi,
>> |
>> | On 03/29/2013 04:59 PM, Gabriel Dos Reis wrote:
>> | > This patch introduces the predicate VAR_P and use it in place of direct
>> | >
>>
On Tue, Apr 2, 2013 at 11:17 AM, Eric Botcazou wrote:
>> Using set_block_for_insn instead of using BLOCK_FOR_INSN is the "proper"
>> way.
>
> Yes, but BLOCK_FOR_INSN as accessor around INSN_BASIC_BLOCK is ugly and a bit
> misleading.
True, I don't like that bit very much myself, either. But I expe
On Tue, Apr 02, 2013 at 04:26:37AM -0500, Gabriel Dos Reis wrote:
> > IMO we also want that autodetection and default to auto.
>
> I disagree.
> For this release, I think the default should be off. We need more
I think a year is plenty of time to agree on the default color scheme
(and yes, the d
On Sun, Mar 31, 2013 at 7:20 PM, Marc Glisse wrote:
> On Sun, 31 Mar 2013, Andrew Pinski wrote:
>
>> On Sun, Mar 31, 2013 at 6:31 AM, Marc Glisse wrote:
>>>
>>> Hello,
>>>
>>> this adds constant folding of VEC_COND_EXPR at the tree level by
>>> forwarding
>>> to the VEC_PERM_EXPR code (a merge is
On Sun, Mar 31, 2013 at 7:51 PM, Kenneth Zadeck
wrote:
> richard,
>
> I was able to add everything except for the checking asserts.While I
> think that this is a reasonable idea, it is difficult to add that to a
> function that is defined in hwint.h because of circular includes. I could
> mo
On Mon, Apr 1, 2013 at 12:19 AM, Lawrence Crowl wrote:
> Remove unused symbols related to ivtype_map. This map does not appear to
> exist and I see no evidence of its removal in the ChangeLog.
>
> Tested on x86_64.
>
> Okay for trunk?
Ok.
Thanks,
Richard.
>
> Index: gcc/ChangeLog
>
> 2013-03-3
Hi,
On 04/02/2013 11:30 AM, Gabriel Dos Reis wrote:
[]
Sorry for chiming in late - but VAR_P loses the fact that we are checking
for a decl ... VAR_DECL_P would be more like following existing practice
(otherwise we can shorten VAR_OR_FUNCTION_DECL_P to
VAR_OR_FUNCTION_P for example). As for f
> True, I don't like that bit very much myself, either. But I expected
> more resistance for the full change ;-)
Possibly. You might really want to wait until the end of the week. :-)
> Right. OK if I call it get_block_for_insn() and make the replacements?
get_block_for_insn will break formatti
Hi,
According to Vladimir Makarov's analysis, the root cause of PR target/54338
is that ALL_REGS doesn't contain IWMMXT_GR_REGS in REG_CLASS_CONTENTS.
It seems there is no reason to exclude the IWMMXT_GR_REGS from ALL_REGS as
IWMMXT_GR_REGS are the real registers.
This patch simply makes AL
On 04/02/13 10:40, Xinyu Qi wrote:
Hi,
According to Vladimir Makarov's analysis, the root cause of PR target/54338
is that ALL_REGS doesn't contain IWMMXT_GR_REGS in REG_CLASS_CONTENTS.
It seems there is no reason to exclude the IWMMXT_GR_REGS from ALL_REGS as
IWMMXT_GR_REGS are the real
On Tue, Apr 2, 2013 at 4:44 AM, Paolo Carlini wrote:
> Hi,
>
> On 04/02/2013 11:30 AM, Gabriel Dos Reis wrote:
>
> []
>
>> Sorry for chiming in late - but VAR_P loses the fact that we are checking
>> for a decl ... VAR_DECL_P would be more like following existing practice
>> (otherwise we can shor
Ping.
On 21 March 2013 14:58, Zhenqiang Chen wrote:
> Hi,
>
> When shrink-wrap is enabled, the "returns" from simple-return path and
> normal return path can be merged. The code is like:
>
> tst ...
> / \
> | push ...
> | ...
> | pop ...
> \ /
> bx lr
>
> If t
On Thu, Mar 21, 2013 at 7:03 AM, Zhenqiang Chen
wrote:
> Hi,
>
> The patch is to enable shrink-wrap for TARGET_ARM and TARGET_THUMB2.
>
> Bootstrapped and no make check regression.
> All previous Linaro shrink-wrap bugs (http://goo.gl/6fGg5) are verified.
>
> Is it OK?
The tests should be part of
On Mon, Apr 1, 2013 at 7:07 PM, Pavel Chupin wrote:
> On Android pthread is integrated into libc.
> Attached patch fixes configures for this case by trying to build test
> without -pthread -lpthread.
>
> 2013-04-01 Pavel Chupin
>
> Fix libatomic and libgomp configure for systems without
Hello,
This idiom: "if (GET_CODE (body) == ASM_INPUT || asm_noperands (body)
>= 0)" appears in multiple places. There's even one place where the
idiom above is used in reverse (making the GET_CODE... check
redundant). A few more places to the equivalent by checking
extract_asm_operands != NULL.
I
On Thu, Mar 28, 2013 at 03:55:38PM +0100, Paolo Carlini wrote:
> .. oops, the patch I attached has a typo. This is the right one.
This regressed
FAIL: obj-c++.dg/try-catch-13.mm -fgnu-runtime (test for errors, line 12)
Can you please adjust that testcase too?
Jakub
On Thu, Mar 21, 2013 at 6:09 PM, Kyrylo Tkachov wrote:
> Hi all,
>
> This patch adds a splitter variant of the minmax_arithsi pattern for when
> the operator
> is non-commutative (MINUS) and the ordering of the operands is not
> canonical.
>
> That is, it will trigger for:
> #define MAX(a, b) (a >
On 04/02/2013 12:03 PM, Jakub Jelinek wrote:
On Thu, Mar 28, 2013 at 03:55:38PM +0100, Paolo Carlini wrote:
.. oops, the patch I attached has a typo. This is the right one.
This regressed
FAIL: obj-c++.dg/try-catch-13.mm -fgnu-runtime (test for errors, line 12)
Can you please adjust that testc
Hello!
>> .. oops, the patch I attached has a typo. This is the right one.
>
> This regressed
> FAIL: obj-c++.dg/try-catch-13.mm -fgnu-runtime (test for errors, line 12)
> Can you please adjust that testcase too?
Tested patch is at [1].
[1] http://gcc.gnu.org/ml/gcc-patches/2013-04/msg00013.htm
On Tue, 2 Apr 2013, Eric Botcazou wrote:
I am not sure about adding just a few rules. If I just say that lshift is
stronger than rshift, the relation is not an order (transitive) anymore.
Why? Can't you give them precedences in commutative_operand_precedence that
preserve the transitivity?
> This idiom: "if (GET_CODE (body) == ASM_INPUT || asm_noperands (body)
>
> >= 0)" appears in multiple places. There's even one place where the
>
> idiom above is used in reverse (making the GET_CODE... check
> redundant). A few more places to the equivalent by checking
> extract_asm_operands !=
Ping (second try)
Sorry if you received it twice, it seems that my gmail account
switched in text/html mode :(
Many thanks,
Yvan
On 2 April 2013 11:21, Yvan Roux wrote:
>
> Ping
>
>
> On 17 March 2013 21:34, Yvan Roux wrote:
>>
>> Hi,
>>
>> this is a backport from gc mainline of the basic AArc
> I can, but then I am giving lshift higher priority than every other
> operation, not just rshift. And if I want to give (vec_select x 0) a
> higher precedence than (vec_select x 1) but lower than (vec_select
> (vec_concat a b) 1), the weights may become complicated, whereas the
> comparison funct
Hi!
Jason's http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949#c12
patch attempts to emit a clobber for *this at the end of the destructor,
so that we can DSE stores into the object when the object is dead, but
so far only VAR_DECLs have been allowed on the lhs of gimple_clobber_p
stmts.
This incre
Hi!
The patch I've just posted wasn't enough, because stmt_kills_ref_p_1
only did something if base == ref->base, but in the case of the dtors
base and ref->base are often MEM_REFs, which aren't equal, but they
just operand_equal_p. And, for MEM_REFs, we don't even need to require
that the two ME
Hi!
As discussed in the PR, when __builtin_constant_p is used in the first
argument of __builtin_choose_expr, as we require a constant value
immediately, we'd better force folding of __builtin_constant_p immediately,
as if we don't, and it isn't 1 known immediately, we won't end up with a
constant
Hi,
This patch adds support for the Cortex-A53. Tested with a simple build
of arm-none-eabi for no regressions on a version before the builds broke
with PR56809. We have been carrying this internally for quite some time
now - so I'm ok with it's stability.
The default tuning for -march=armv8
On Tue, 2 Apr 2013, Jakub Jelinek wrote:
> Hi!
>
> Jason's http://gcc.gnu.org/bugzilla/show_bug.cgi?id=34949#c12
> patch attempts to emit a clobber for *this at the end of the destructor,
> so that we can DSE stores into the object when the object is dead, but
> so far only VAR_DECLs have been al
Hi!
On the (undefined behavior) testcase below, we end up with
then_bb ending with __builtin_unreachable () at the tree level, therefore
no successor at the RTL level, and else_bb being EXIT_BLOCK_PTR (i.e.
conditional return before a bb with undefined behavior at the end).
Trying to optimize that
On Tue, 2 Apr 2013, Jakub Jelinek wrote:
> Hi!
>
> The patch I've just posted wasn't enough, because stmt_kills_ref_p_1
> only did something if base == ref->base, but in the case of the dtors
> base and ref->base are often MEM_REFs, which aren't equal, but they
> just operand_equal_p. And, for M
This backports a fix to fix PR56768.
Bootstrapped on the 4.7 branch, testing in progress.
Richard.
2013-04-02 Richard Biener
PR middle-end/56768
Backport from mainline
2012-05-16 Richard Guenther
* tree-inline.c (declare_return_variable): Properly handle
On Tue, Apr 02, 2013 at 01:44:46PM +0200, Richard Biener wrote:
> > @@ -412,7 +412,8 @@ get_mem_ref_of_assignment (const gimple
> > {
> >gcc_assert (gimple_assign_single_p (assignment));
> >
> > - if (gimple_store_p (assignment))
> > + if (gimple_store_p (assignment)
> > + && !gimple_
This patch is for GCC 4.8 and 4.9.
libcpp/ChangeLog
2013-04-02 Sebastian Huber
* configure.ac: Require 64-bit int for arm*-*-rtems*.
* configure: Regenerate.
---
libcpp/configure|1 +
libcpp/configure.ac |1 +
2 files changed, 2 insertions(+), 0 deletions(-)
diff
On Tue, 2 Apr 2013, Jakub Jelinek wrote:
> On Tue, Apr 02, 2013 at 01:44:46PM +0200, Richard Biener wrote:
> > > @@ -412,7 +412,8 @@ get_mem_ref_of_assignment (const gimple
> > > {
> > >gcc_assert (gimple_assign_single_p (assignment));
> > >
> > > - if (gimple_store_p (assignment))
> > > +
On Mon, Apr 1, 2013 at 5:52 PM, Marc Glisse wrote:
> On Sat, 30 Mar 2013, Marc Glisse wrote:
>
>> * tree-flow-inline.h (get_addr_base_and_unit_offset_1): Handle
>> BIT_FIELD_REF.
>
>
> I wrote a safer version of this for PR52436:
That variant is ok - please test and commit separat
On Sat, Mar 30, 2013 at 5:14 PM, Marc Glisse wrote:
> On Tue, 29 Jan 2013, Richard Biener wrote:
>
>> So yes, handling BIT_FIELD_REF in the vectorizer looks like the correct
>> way to do - but mind that you should constrain the BIT_FIELD_REFs you
>> allow (I suppose in the end that's properly done
On Tue, 2 Apr 2013, Jakub Jelinek wrote:
> Hi!
>
> On the (undefined behavior) testcase below, we end up with
> then_bb ending with __builtin_unreachable () at the tree level, therefore
> no successor at the RTL level, and else_bb being EXIT_BLOCK_PTR (i.e.
> conditional return before a bb with u
could someone please review and commit if it is OK?
I don't have commit access.
Regards,
Pitchumani
On 4/1/2013 4:30 PM, Pitchumani Sivanupandi wrote:
Fix test case sra-13.c that assumed int is always 4 bytes.
Regards,
Pitchumani
2013-04-01 Pitchumani Sivanupandi
testsuite
* gcc.dg/
On Wed, Mar 27, 2013 at 01:56:48PM +0400, Kirill Yukhin wrote:
> >
> > Otherwise OK.
> >
> > Thanks,
>
> Hi, chacked into trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-03/msg00785.html
This leads to:
../../gcc/config/t-linux-android:22: warning: overriding recipe for target
`linux-android.o'
../../
Ping ^2
- Original Message -
> From: "Kai Tietz"
> To: "GCC Patches"
> Cc: "Richard Henderson"
> Sent: Thursday, March 28, 2013 2:35:15 PM
> Subject: Re: [patch i386 windows]: Fix PR/52790 also required for workig
> upcoming cygwin x64 target
>
> Ping
>
On Tue, Apr 02, 2013 at 02:57:13PM +0200, Richard Biener wrote:
> On Tue, 2 Apr 2013, Jakub Jelinek wrote:
> > On the (undefined behavior) testcase below, we end up with
> > then_bb ending with __builtin_unreachable () at the tree level, therefore
> > no successor at the RTL level, and else_bb bein
Hi,
I think this is my last obvious clean-up for now. I'm going to commit it
when testing on x86_64-linux completes.
Thanks,
Paolo.
//
2013-04-02 Paolo Carlini
* friend.c (do_friend): Use COMPLETE_OR_OPEN_TYPE_P.
* pt.c (find_parameter_packs_r): Use TYP
On Tue, 2 Apr 2013, Jakub Jelinek wrote:
> On Tue, Apr 02, 2013 at 02:57:13PM +0200, Richard Biener wrote:
> > On Tue, 2 Apr 2013, Jakub Jelinek wrote:
> > > On the (undefined behavior) testcase below, we end up with
> > > then_bb ending with __builtin_unreachable () at the tree level, therefore
>
Richard,
did everything that you asked here. bootstrapped and regtested on
x86-64. ok to commit?
kenny
On 04/02/2013 05:38 AM, Richard Biener wrote:
On Sun, Mar 31, 2013 at 7:51 PM, Kenneth Zadeck
wrote:
richard,
I was able to add everything except for the checking asserts.While I
t
Yep.. we missed that:
t-linux-android was added here:
# Add Android userspace support to Linux targets.
case $target in
*linux*)
tm_p_file="${tm_p_file} linux-protos.h"
tmake_file="${tmake_file} t-linux-android"
tm_file="$tm_file linux-android.h"
extra_options="$ext
On Tue, Apr 02, 2013 at 06:24:06PM +0400, Alexander Ivchenko wrote:
> --- a/gcc/ChangeLog
> +++ b/gcc/ChangeLog
> @@ -1,3 +1,7 @@
> +2013-04-02 Alexander Ivchenko
> +
> + * config.gcc (arm*-*-linux-*): Remove duplicate t-linux-android.
> +
> 2013-04-02 Richard Biener
>
> PR tr
Hi,
>> is it ok?
>
> Yes.
Checked into trunk: http://gcc.gnu.org/ml/gcc-cvs/2013-04/msg00066.html
Thanks, K
LAST_UPDATED: Mon Apr 1 18:01:32 UTC 2013 (revision 197313)
Native configuration is powerpc-ibm-aix7.1.0.0
=== g++ tests ===
Running target unix
FAIL: tmpdir-g++.dg-struct-layout-1/t024
cp_compat_x_tst.o-cp_compat_y_tst.o execute
FAIL: tmpdir-g++.dg-struct-layout-1/t026
cp_compat_x_tst
On Tue, Apr 2, 2013 at 8:34 AM, Paolo Carlini wrote:
> Hi,
>
> I think this is my last obvious clean-up for now. I'm going to commit it
> when testing on x86_64-linux completes.
thanks.
-- Gaby
On Tue, Apr 2, 2013 at 3:49 PM, Kenneth Zadeck wrote:
> Richard,
>
> did everything that you asked here. bootstrapped and regtested on x86-64.
> ok to commit?
diff --git a/gcc/hwint.c b/gcc/hwint.c
index 330b42c..7e5b85c 100644
--- a/gcc/hwint.c
+++ b/gcc/hwint.c
@@ -204,3 +204,33 @@ least_commo
On Wed, Feb 27, 2013 at 2:59 AM, Kenneth Zadeck
wrote:
> This patch contains a large number of the changes requested by Richi. It
> does not contain any of the changes that he requested to abstract the
> storage layer. That suggestion appears to be quite unworkable.
I of course took this clai
This patch is for GCC 4.6 and 4.7.
libcpp/ChangeLog
2013-04-02 Sebastian Huber
PR target/56771
* configure.ac: Require 64-bit int for arm*-*-rtems[.0-9]*.
* configure: Regenerate.
---
libcpp/configure|1 +
libcpp/configure.ac |1 +
2 files changed, 2 insert
This patch is for GCC 4.8 and 4.9.
v2: Fix ChangeLog.
libcpp/ChangeLog
2013-04-02 Sebastian Huber
PR target/56771
* configure.ac: Require 64-bit int for arm*-*-rtems*.
* configure: Regenerate.
---
libcpp/configure|1 +
libcpp/configure.ac |1 +
2 files cha
On 15 March 2013 08:55, Jakub Jelinek wrote:
> On Thu, Feb 28, 2013 at 08:32:02AM -0700, Tom Tromey wrote:
>> 2013-02-27 Tom Tromey
>>
>> * libsupc++/unwind-cxx.h: Include sys/sdt.h if detected.
>> (PROBE2): New macro.
>> * libsupc++/eh_throw.cc (__cxa_throw, __cxa_rethrow): A
On 04/02/2013 04:54 AM, Eric Botcazou wrote:
I wonder if those issues might in most cases be bugs in the back-ends
(optimizations missed depending on the order), that the canonicalization
would make more noticable (and thus easier to fix).
There are certainly such issues in the back-ends (and e
On Tue, 2 Apr 2013, Jonathan Wakely wrote:
On 15 March 2013 08:55, Jakub Jelinek wrote:
On Thu, Feb 28, 2013 at 08:32:02AM -0700, Tom Tromey wrote:
2013-02-27 Tom Tromey
* libsupc++/unwind-cxx.h: Include sys/sdt.h if detected.
(PROBE2): New macro.
* libsupc++/eh_throw.cc
> From: Ramana Radhakrishnan [mailto:ramana@googlemail.com]
> Sent: 02 April 2013 11:10
> To: Kyrylo Tkachov
> Cc: gcc-patches@gcc.gnu.org; Richard Earnshaw; Ramana Radhakrishnan
> Subject: Re: [PATCH][ARM] minmax_arithsi for non-canonical operand
> order with MINUS operator
>
> On Thu, Mar 21
Hi Richard,
I've now updated this patch. How does this version look?
Catherine
2013-04-02 Catherine Moore
* config/mips/micromips.md (jraddiusp): New pattern.
* config/mips/mips.c (mips_expand_epilogue): Use the JRADDIUSP
instruction if possible.
> -Original Messa
This patch updates the C_LOC checking fixes for array. In particular:
Fortran 2003 allows:
"(1) have interoperable type and type parameters and be
(a) a variable that has the TARGET attribute and is interoperable,
(b) an allocated allocatable variable that has the TARGET attribute
and i
On Tue, Apr 2, 2013 at 5:00 AM, Jeff Law wrote:
> On 04/01/2013 01:47 PM, Eric Botcazou wrote:
>>>
>>> I'm not sure what this is supposed to do. How is pat == target ever
>>> going to be true when ANY_RETURN_P (pat) is true? Isn't target supposed
>>> to be a CODE_LABEL or NULL? What am I missing
On 2013-03-22 02:27, Kai Tietz wrote:
Hi,
this patch fixes PR/52790 and supports for x64 Windows targets the use
of large and medium code-model.
This feature is required for upcoming new cygwin x64 target, which
uses full 48-bit available address-space of x64 Windows.
The cygwin-target depends o
Hello!
2013-04-02 Uros Bizjak
* config/i386/i386.md (*testqi_ext_3): Merge with *testqi_ext_3_rex64
using SWI48 mode attribute.
Tested on x86_64-pc-linux-gnu {,-m32} and committed to mainline SVN.
Uros.
Index: config/i386/i386.md
==
On Apr 2, 2013, at 5:59 AM, Pitchumani Sivanupandi
wrote:
> could someone please review
Ok.
> and commit if it is OK?
Committed revision 197366.
Yes, I agree that you win the challenge that it can be done.What you
have always failed to address is why anyone would want to do this. Or
how this would at all be desirable.But I completely agree that from
a purely abstract point of view you can add a storage model.
Now here is why w
On Tue, Apr 02, 2013 at 02:41:07PM +0200, Richard Biener wrote:
> I've just come along 56787 and decided that not collecting
> CLOBBERs during data-reference gathering would be wrong.
> Thus changing gimple_store_p would be wrong, too. So in the
> end the above hunk looks ok and we shouldn't chang
On Tue, Apr 02, 2013 at 01:52:16PM +0200, Richard Biener wrote:
> in all relevant cases operand zero of the MEM_REFs are SSA names
> and thus can be compared for equality using == (exception are
> integer constant pointers where the type could be theoretically
> different).
...
Here is what I've c
Build and regtested on x86-64-gnu-linux.
OK for the trunk?
Tobias
2013-04-02 Tobias Burnus
PR fortran/56810
* io/list_read.c (check_type): Fix kind checking for COMPLEX.
2013-04-02 Tobias Burnus
PR fortran/56810
* gfortran.dg/read_repeat_2.f90: New.
diff --git a/libgfortran/io/list_
this time for sure.
kenny
On 04/02/2013 10:54 AM, Richard Biener wrote:
On Tue, Apr 2, 2013 at 3:49 PM, Kenneth Zadeck wrote:
Richard,
did everything that you asked here. bootstrapped and regtested on x86-64.
ok to commit?
diff --git a/gcc/hwint.c b/gcc/hwint.c
index 330b42c..7e5b85c 100644
First round of results for gcc 4.8.x.
-tgc
Testresults for 4.8.0
arm-unknown-linux-gnueabi
hppa2.0w-hp-hpux11.00
hppa2.0w-hp-hpux11.11
hppa64-hp-hpux11.11
i386-apple-darwin10.8.0
i386-pc-solaris2.9
i386-pc-solaris2.10
i386-pc-solaris2.11
mipsel-unknown-linux-gnu
powerpc-apple-
On Tue, Apr 2, 2013 at 12:34 PM, Eric Botcazou wrote:
>> This idiom: "if (GET_CODE (body) == ASM_INPUT || asm_noperands (body)
>>
>> >= 0)" appears in multiple places. There's even one place where the
>>
>> idiom above is used in reverse (making the GET_CODE... check
>> redundant). A few more place
On 2 April 2013 16:39, Marc Glisse wrote:
> On Tue, 2 Apr 2013, Jonathan Wakely wrote:
>> Should we update the prerequisites documentation to say that if
>> Systemtap is installed it needs to be at least version X?
>
>
> I thought you were going to suggest enhancing the configure test so it fails
>
On 4/2/13, Richard Biener wrote:
> On Mon, Apr 1, 2013 at 12:19 AM, Lawrence Crowl wrote:
>> Remove unused symbols related to ivtype_map. This map does not appear to
>> exist and I see no evidence of its removal in the ChangeLog.
>>
>> Tested on x86_64.
>>
>> Okay for trunk?
>
> Ok.
Committed.
Now that Jakub has checked in support for MEM_REF clobbers, we can use
that to let the front end tell the back end that nothing in an object is
interesting after the destructor is complete. This should allow us to
optimize away assignments to vtable pointers if the destructor doesn't
use them,
On Tue, 2 Apr 2013, Jakub Jelinek wrote:
> The following patch folds it there immediately too. Bootstrapped/regtested
> on x86_64-linux and i686-linux, ok for trunk?
OK.
> BTW, in the PR I've also mentioned what has been reported to the Red Hat
> bugzilla about __builtin_constant_p in array bou
On Tue, 2 Apr 2013, Ramana Radhakrishnan wrote:
> 2013-04-02 Ian Caulfield
> Ramana Radhakrishnan
>
> * config/arm/arm-arches.def (armv8-a): Default to cortex-a53.
> * config/arm/t-arm (MD_INCLUDES): Depend on cortex-a53.md.
> * config/arm/cortex-a53.md: New f
This patch implements
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3189.htm
The function pointer holding the current new handler was exposed as an
extern variable, which is unnecessary now there's an accessor for it.
Atomic operations are used to set and retrieve the handlers to avoid
Hi,
When I look into code of auto-inc-dec.c in GCC, I found this typo in rtl.h,
as
#if (defined (HAVE_PRE_INCREMENT) || defined (HAVE_PRE_DECREMENT) \
|| defined (HAVE_POST_INCREMENT) || defined (HAVE_POST_DECREMENT) \
|| defined (HAVE_PRE_MODIFY_DISP) || defined (HAVE_PRE_MODIFY_DISP) \
> -Original Message-
> From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-ow...@gcc.gnu.org]
On
> Behalf Of Bin Cheng
> Sent: Wednesday, April 03, 2013 9:38 AM
> To: gcc-patches@gcc.gnu.org
> Subject: [PATCH GCC]Fix typo in definition of macro AUTO_INC_DEC in rtl.h
>
> Hi,
> When I
I remember thinking that I'd need to deal with mangling for
ref-qualifiers, but somehow it slipped my mind. This patch implements
it. Having to mess with re-adding the ref-qualifier after
TYPE_MAIN_VARIANT makes me more determined to deal with giving
ref-qualified types their own TYPE_MAIN_VA
On 2 April 2013 17:55, Ramana Radhakrishnan wrote:
> On Thu, Mar 21, 2013 at 7:03 AM, Zhenqiang Chen
> wrote:
>> Hi,
>>
>> The patch is to enable shrink-wrap for TARGET_ARM and TARGET_THUMB2.
>>
>> Bootstrapped and no make check regression.
>> All previous Linaro shrink-wrap bugs (http://goo.gl/6
90 matches
Mail list logo
