Hello,
> This
> + /* Skip instructions that do not set a register. */
> + if (set && !REG_P (SET_DEST (set)))
> + continue;
> is ok. Can you also prevent !set insns from having reg_moves? (To be updated
> once auto_inc insns will be supported, if they'll deserve reg_moves too.)
Hello,
> OK, with the following comments:
>
> Make sure reg_moves are generated for the correct (result, not addr)
> register, in generate_reg_moves().
>
> "been">>"being" (multiple appearances).
>
> Add a note that autoinc_var_is_used_p (rtx def_insn, rtx use_insn)
> doesn't need to consider the
On Sep 29, 2011, at 5:54 PM, Basile Starynkevitch wrote:
> On Thu, 29 Sep 2011 17:10:26 +0200
> Tristan Gingold wrote:
>
>> Hi,
>>
>> DEC-C, the DEC compiler provided on VMS, has added to ANSI-C at least one
>> extension that is difficult to work-around as it is used in the system
>> headers
On Thu, 29 Sep 2011, Jakub Jelinek wrote:
> Hi!
>
> On Mon, Sep 26, 2011 at 06:41:10PM +0200, Jakub Jelinek wrote:
> > which would be invalid to call with foo (a, 32); given the above, but
> > it isn't obvious to the compiler what value y has. With -DWORKAROUND
> > the PT decls in (restr) look c
I tried to add the 'siam' instruction too but that one is really
difficult because it influences the behavior of every float operation
and I couldnt' find an easy way to express those dependencies. I
tried a few easy approaches but I couldn't reliably keep the compiler
from moving 'siam' across f
On Thu, Sep 29, 2011 at 5:57 PM, Tom de Vries wrote:
> Richard,
>
> in gimplify_vla_decl, the alloca argument seems to be the size of the vla in
> units:
> ...
> t = build_call_expr (t, 1, DECL_SIZE_UNIT (decl));
> ...
>
> I wonder why we are going through this 8 vs. BITS_PER_UNIT conversion her
"Jiangning Liu" writes:
>> -Original Message-
>> From: Jakub Jelinek [mailto:ja...@redhat.com]
>> Sent: Thursday, September 29, 2011 6:14 PM
>> To: Jiangning Liu
>> Cc: 'Richard Guenther'; Andrew Pinski; gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH] Fix stack red zone bug (PR38644)
>>
>
On Thu, Sep 29, 2011 at 11:17 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch teaches PTA/aliasing about strdup/strndup (that the passed in
> string is just read and doesn't escape in any way, and that otherwise it
> acts as malloc or other allocation calls.
> Bootstrapped/regtested on x86_64-linux
On Fri, Sep 30, 2011 at 8:17 AM, Jakub Jelinek wrote:
> Hi!
>
> GCC on the following testcase warns
> warning: use of memory input without lvalue in asm operand 0 is deprecated
> [enabled by default]
> starting with 4.6, but the source actually had an lvalue there (I don't
> think we should forbi
On Fri, Sep 30, 2011 at 09:50:09AM +0200, Richard Guenther wrote:
> Hmm, in fwprop can you limit your change to non-invariant addresses?
> That is, we do want to propagate invariant addresses over
> restrict casts, because that will give us _more_ precise alias info
> than restrict.
Will it?
I'd
Dear all,
with the following change in 4.5, the -Walign-commons warning got disabled:
"The |COMMON| default padding has been changed – instead of adding the
padding before a variable it is now added afterwards, which increases
the compatibility with other vendors and helps to obtain the correc
This patch fixes performance regression with -mtune=atom. Changing
atom cost removes regression in several tests of EEMBC and spec2000.
Bootstrap amd make check Ok for both with and witout -mtune-atom.
OK for trunk?
2011-09-30 Yakovlev Vladimir vladimir.b.yakov...@intel.com
* gcc/config/i
Hi!
On Fri, Sep 30, 2011 at 10:34:28AM +0200, Richard Guenther wrote:
> Hmm, I don't think this change is ok. We rely on maybe_fold_reference
> to re-fold mem-refs to valid gimple form (from propagating say
> &a.b.c to MEM[p, 4] which first gives the invalid MEM[&a.b.c, 4] and
> then the folding
On Fri, 30 Sep 2011, Jakub Jelinek wrote:
> On Fri, Sep 30, 2011 at 09:50:09AM +0200, Richard Guenther wrote:
> > Hmm, in fwprop can you limit your change to non-invariant addresses?
> > That is, we do want to propagate invariant addresses over
> > restrict casts, because that will give us _more_
On Fri, Sep 30, 2011 at 10:56 AM, Jakub Jelinek wrote:
> Hi!
>
> On Fri, Sep 30, 2011 at 10:34:28AM +0200, Richard Guenther wrote:
>> Hmm, I don't think this change is ok. We rely on maybe_fold_reference
>> to re-fold mem-refs to valid gimple form (from propagating say
>> &a.b.c to MEM[p, 4] whic
On Thu, Sep 29, 2011 at 10:10 AM, Tristan Gingold wrote:
> Hi,
>
> DEC-C, the DEC compiler provided on VMS, has added to ANSI-C at least one
> extension that is difficult to work-around as it is used in the system
> headers: varargs without named argument. It makes sense on VMS because of
> it
On Sep 30, 2011, at 11:10 AM, Gabriel Dos Reis wrote:
> On Thu, Sep 29, 2011 at 10:10 AM, Tristan Gingold wrote:
>> Hi,
>>
>> DEC-C, the DEC compiler provided on VMS, has added to ANSI-C at least one
>> extension that is difficult to work-around as it is used in the system
>> headers: varargs
On Thu, Sep 29, 2011 at 11:15 PM, Jakub Jelinek wrote:
> Hi!
>
> This patch implements a fold_range_test like optimization on GIMPLE, inside
> tree-ssa-reassoc and tweaks fold-const.c so that most of the code can be
> shared in between the two.
> The advantage of the reassoc optimization is that i
On 29/09/11 12:27, Richard Guenther wrote:
On Thu, Sep 29, 2011 at 12:00 PM, Richard Guenther
wrote:
On Wed, Sep 28, 2011 at 4:23 PM, Richard Guenther
wrote:
On Mon, Sep 26, 2011 at 5:43 PM, Richard Guenther
wrote:
On Mon, Sep 26, 2011 at 4:25 PM, Richard Guenther
wrote:
On Wed, Sep 7
On Fri, Sep 30, 2011 at 00:09, Andi Kleen wrote:
> gcc/lto/:
>
> 2011-09-29 H.J. Lu
> Andi Kleen
>
> PR lto/50568
> * lto.c (lto_splay_tree_delete_id): New.
> (lto_splay_tree_compare_ids): Likewise.
> (lto_splay_tree_lookup): Likewise.
> (lto_spl
Okay, seems maintainers have no objections
Could anybody please commit that to wwwdocs?
Thanks, K
On Tue, Sep 27, 2011 at 8:19 PM, Gerald Pfeifer wrote:
> On Tue, 27 Sep 2011, Kirill Yukhin wrote:
>> So, if you are ok, let's wait a couple of days for maintainers inputs.
>
> Yep, looks good. Un
On Fri, Sep 30, 2011 at 12:33:07PM +0200, Richard Guenther wrote:
> > + low = build_int_cst (TREE_TYPE (exp), 0);
> > + high = low;
> > + in_p = 0;
> > + strict_overflow_p = false;
> > + is_bool = TREE_CODE (TREE_TYPE (exp)) == BOOLEAN_TYPE;
>
> Effective boolean are also TYPE_PRECISION () ==
On Fri, Sep 30, 2011 at 10:03 AM, Revital Eres wrote:
> Hello,
>
>> This
>> + /* Skip instructions that do not set a register. */
>> + if (set && !REG_P (SET_DEST (set)))
>> + continue;
>> is ok. Can you also prevent !set insns from having reg_moves? (To be updated
>> once auto_i
This is so that use of symbols referenced in these asm()-s can be
properly tracked by the compiler, just like is the case for all other
asm()-s. I'm particularly looking forward to use this in the Linux
kernel. It is certainly not very useful in PIC code, at least not with
some extra care.
Changes
Split out LTO's writing of top level asm nodes in preparation of extending
what needs to be written out when top level asm-s get enhanced to accept a
limited set of input operands.
gcc/
2011-09-30 Jan Beulich
* lto-cgraph.c (output_cgraph): Remove processing of 'cgraph_asm_nodes',
This is so that use of symbols referenced in these asm()-s can be
properly tracked by the compiler, just like is the case for all other
asm()-s. I'm particularly looking forward to use this in the Linux
kernel. It is certainly not very useful in PIC code, at least not with
some extra care.
gcc/
20
> -Original Message-
> From: Richard Sandiford [mailto:rdsandif...@googlemail.com]
> Sent: Friday, September 30, 2011 4:15 PM
> To: Jiangning Liu
> Cc: 'Jakub Jelinek'; 'Richard Guenther'; Andrew Pinski; gcc-
> patc...@gcc.gnu.org
> Subject: Re: [PATCH] Fix stack red zone bug (PR38644)
>
I intent to commit the attached patch in the next days.
Do you have suggestions for a better wording or other items which should
be listed?
For the current version, see http://gcc.gnu.org/gcc-4.7/changes.html#fortran
Tobias
Index: changes.html
=
This adds log output to avr_address_cost.
Ok for trunk?
Johann
PR target/50566
* config/avr/avr-protos.h (avr_log_t): New field address_cost.
* config/avr/avr.c (avr_address_cost): Use it.
* config/avr/avr-log.c (avr_log_set_avr_log): Initialize it.
(avr_l
On Fri, Sep 30, 2011 at 1:11 PM, Jakub Jelinek wrote:
> On Fri, Sep 30, 2011 at 12:33:07PM +0200, Richard Guenther wrote:
>> > + low = build_int_cst (TREE_TYPE (exp), 0);
>> > + high = low;
>> > + in_p = 0;
>> > + strict_overflow_p = false;
>> > + is_bool = TREE_CODE (TREE_TYPE (exp)) == BOOL
On Fri, Sep 30, 2011 at 1:43 PM, Jan Beulich wrote:
> Split out LTO's writing of top level asm nodes in preparation of extending
> what needs to be written out when top level asm-s get enhanced to accept a
> limited set of input operands.
Ok with ...
> gcc/
> 2011-09-30 Jan Beulich
>
>
On Fri, Sep 30, 2011 at 1:43 PM, Jan Beulich wrote:
> This is so that use of symbols referenced in these asm()-s can be
> properly tracked by the compiler, just like is the case for all other
> asm()-s. I'm particularly looking forward to use this in the Linux
> kernel. It is certainly not very us
On Fri, Sep 30, 2011 at 02:26:40PM +0200, Richard Guenther wrote:
> > It is boolean only in some testcases, the is_bool stuff discussed at the
> > beginning above was originally just an early return
> > if (TREE_CODE (TREE_TYPE (exp)) != BOOLEAN_TYPE)
> > return;
> > before the loop, but it tur
"Jiangning Liu" writes:
>> You seem to feel strongly about this because it's a wrong-code bug that
>> is very easy to introduce and often very hard to detect. And I
>> defintely
>> sympathise with that. If we were going to to do it in a target-
>> independent
>> way, though, I think it would be
On Fri, Sep 30, 2011 at 12:43:54PM +0100, Jan Beulich wrote:
> This is so that use of symbols referenced in these asm()-s can be
> properly tracked by the compiler, just like is the case for all other
> asm()-s. I'm particularly looking forward to use this in the Linux
> kernel. It is certainly not
>>> On 30.09.11 at 14:47, Jakub Jelinek wrote:
> On Fri, Sep 30, 2011 at 12:43:54PM +0100, Jan Beulich wrote:
>> This is so that use of symbols referenced in these asm()-s can be
>> properly tracked by the compiler, just like is the case for all other
>> asm()-s. I'm particularly looking forward t
On Fri, Sep 30, 2011 at 2:46 PM, Richard Sandiford
wrote:
> "Jiangning Liu" writes:
>>> You seem to feel strongly about this because it's a wrong-code bug that
>>> is very easy to introduce and often very hard to detect. And I
>>> defintely
>>> sympathise with that. If we were going to to do it
>>> On 30.09.11 at 14:42, Richard Guenther wrote:
> On Fri, Sep 30, 2011 at 1:43 PM, Jan Beulich wrote:
>> This is so that use of symbols referenced in these asm()-s can be
>> properly tracked by the compiler, just like is the case for all other
>> asm()-s. I'm particularly looking forward to use
Richard Sandiford writes:
> In contrast, after the tree optimisers have handed off the initial IL,
um, I meant frontend :-)
> the tree optimisers are more or less in full control.
Richard
On Fri, Sep 30, 2011 at 2:44 PM, Jakub Jelinek wrote:
> On Fri, Sep 30, 2011 at 02:26:40PM +0200, Richard Guenther wrote:
>> > It is boolean only in some testcases, the is_bool stuff discussed at the
>> > beginning above was originally just an early return
>> > if (TREE_CODE (TREE_TYPE (exp)) !=
On Fri, Sep 30, 2011 at 01:54:16PM +0100, Jan Beulich wrote:
> >>> On 30.09.11 at 14:47, Jakub Jelinek wrote:
> > On Fri, Sep 30, 2011 at 12:43:54PM +0100, Jan Beulich wrote:
> >> This is so that use of symbols referenced in these asm()-s can be
> >> properly tracked by the compiler, just like is
Hi Dave,
The nit-picky bit - There are still a number of formatting issues with
your patch . Could you run your patch through
contrib/check_GNU_style.sh and correct these. These are typically
around problems with the number of spaces between a full stop and the
end of comment, lines with trailing
On Thu, Sep 29, 2011 at 3:15 PM, Tom de Vries wrote:
> On 09/28/2011 11:53 AM, Richard Guenther wrote:
>> On Wed, Sep 28, 2011 at 11:34 AM, Tom de Vries
>> wrote:
>>> Richard,
>>>
>>> I got a patch for PR50527.
>>>
>>> The patch prevents the alignment of vla-related allocas to be set to
>>> BIGG
This fixes PR50574, we shouldn't compare vector mode sizes because
vectors can have BLKmode in gimple.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied to trunk.
Richard.
2011-09-30 Richard Guenther
PR middle-end/50574
* tree-cfg.c (verify_gimple_comparison): Com
> -Original Message-
> From: Georg-Johann Lay [mailto:a...@gjlay.de]
> Sent: Friday, September 30, 2011 6:18 AM
> To: gcc-patches@gcc.gnu.org
> Cc: Denis Chertykov; Weddington, Eric
> Subject: Re: [Patch,AVR]: PR50566: Better log output with -mdeb/-mlog=
> [3/n]
>
> This adds log output
On 29 Sep 2011, at 15:37, Arnaud Charlet wrote:
No functional change, just factor out the common LIBGNAT_TARGET_PAIRS
across the port.
OK for trunk?
OK
regrettably, I'd allowed my ppc and x86 trees to get out of sync, and
the applied patch was not correct on powerpc.
corrected by a parti
On 11-09-27 13:23 , Jan Hubicka wrote:
sync and pr34850 tests doesn't pass with slim LTO. The reason is that they
excpects diagnostics that is output too late in compilation (usually at
expansion time). These should be probably fixed as QOI issue but they are not
real bug - the diagnostics will
This is the patch to add log output to LEGITIMIZE_RELOAD_ADDRESS.
The code is moved from macro in avr.h to a new function in avr.c.
Functionality is the same, but IMO it's more convenient to have it as function
than as a quite long macro.
Ok for trunk?
PR target/50566
* config/a
It seems that the following three tests don't fail anymore anywhere for
some time, so the following patch removes the three xfail's to avoid the
noise from XPASSes.
Tested with the approrpriate runtest invocation on i386-pc-solaris2.11.
Ok for mainline?
Rainer
2011-09-30 Rainer Orth
On Tue, Sep 27, 2011 at 04:26:47PM -0300, Alexandre Oliva wrote:
> On Sep 20, 2011, Jakub Jelinek wrote:
>
> > For NOTE_INSN_CALL_ARG_LOCATION, the locations aren't location lists, but
> > a single location at the point of the call. They are independent of
> > all other locations, so any kind of
On Mon, 26 Sep 2011, Jakub Jelinek wrote:
> Hi!
>
> Adding Joseph and Jason to CC.
>
> On Mon, Sep 26, 2011 at 04:56:20PM +0200, Richard Guenther wrote:
> > Let's see what kind of fallout we get ;) For example, if the
> > following is valid C code I expect we will vectorize the second
> > loop
On Fri, 30 Sep 2011 09:24:03 +0200
Tristan Gingold wrote:
>
> On Sep 29, 2011, at 5:54 PM, Basile Starynkevitch wrote:
> > I believe that such an extension is useful on other systems, even when
> > their ABI don't
> > pass the number of arguments.
> >
> > The use case I would have in mind is w
On Thu, 29 Sep 2011, Tristan Gingold wrote:
> Hi,
>
> DEC-C, the DEC compiler provided on VMS, has added to ANSI-C at least
> one extension that is difficult to work-around as it is used in the
> system headers: varargs without named argument. It makes sense on VMS
> because of its ABI which
On Sep 30, 2011, at 4:43 PM, Joseph S. Myers wrote:
> On Thu, 29 Sep 2011, Tristan Gingold wrote:
>
>> Hi,
>>
>> DEC-C, the DEC compiler provided on VMS, has added to ANSI-C at least
>> one extension that is difficult to work-around as it is used in the
>> system headers: varargs without name
>>> On 30.09.11 at 14:34, Richard Guenther wrote:
> On Fri, Sep 30, 2011 at 1:43 PM, Jan Beulich wrote:
>> Split out LTO's writing of top level asm nodes in preparation of extending
>> what needs to be written out when top level asm-s get enhanced to accept a
>> limited set of input operands.
>
Artem Shinkarov schrieb:
> Here is a new version of the patch which considers the changes from
> 2011-09-02 Richard Guenther
>
>
> ChangeLog
>
> 20011-09-06 Artjoms Sinkarovs
>
>gcc/
>* fold-const.c (constant_boolean_node): Adjust the meaning
>of boolean for vector typ
On Fri, Sep 30, 2011 at 03:14:12PM +0200, Richard Guenther wrote:
> Ah, indeed. I'll have a look at the updated patch.
Here is what I've committed after bootstrapping/regtesting it on
x86_64-linux and i686-linux and Richard's approval on IRC.
2011-09-30 Jakub Jelinek
PR tree-optimiza
On Fri, Sep 30, 2011 at 10:57:25AM +0200, Richard Guenther wrote:
> Definitely. Seeing a decl will enable better offset-based
> disambiguation.
Ok, here is an updated patch. Bootstrapped/regtested on x86_64-linux
and i686-linux, ok for trunk?
2011-09-30 Jakub Jelinek
* fold-const.c
On Fri, Sep 30, 2011 at 4:01 PM, Georg-Johann Lay wrote:
> Artem Shinkarov schrieb:
>> Here is a new version of the patch which considers the changes from
>> 2011-09-02 Richard Guenther
>>
>>
>> ChangeLog
>>
>> 20011-09-06 Artjoms Sinkarovs
>>
>> gcc/
>> * fold-const.c (constant_bo
On Fri, Sep 30, 2011 at 12:35:49PM +0200, Richard Guenther wrote:
> On Fri, Sep 30, 2011 at 12:23 PM, Jakub Jelinek wrote:
> > On Fri, Sep 30, 2011 at 10:25:35AM +0200, Richard Guenther wrote:
> >> > This patch teaches PTA/aliasing about strdup/strndup (that the passed in
> >> > string is just rea
On Fri, 30 Sep 2011, Tristan Gingold wrote:
> If you prefer a target hook, I'm fine with that. I will write such a patch.
>
> I don't think it must be restricted to system headers, as it is possible
> that the user 'imports' such a function (and define it in one of VMS
> favorite languages suc
Ping.
The following RTL patches need reviews:
[PATCH 4/9] Move the SMS pass earlier
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01811.html
[PATCH 7/9] New assertion in rtl_lv_add_condition_to_bb
http://gcc.gnu.org/ml/gcc-patches/2011-07/msg01808.html
[PATCH 8/9] Extend simple_rhs_p
http://gcc.gnu.
2011/7/22 Richard Sandiford :
> zhr...@ispras.ru writes:
>> This patch fixes the compiler segfault found while regtesting trunk with SMS
>> on
>> IA64 platform. Segfault happens on test gcc.dg/pr45259.c with -fmodulo-sched
>> enabled. The following jump instruction is given as argument for
>> do
Hi Bernd,
Experiments show that the
existing multi-if-block support isn't terribly effective on FRV;
before-after comparisons show that by turning it off, there are three
spots in gcc that are meaningfully changed, and below 20 in the C
benchmarks of SPEC2k.
FRV also doesn't build in mainline,
On 09/29/2011 05:21 PM, Dodji Seketeli wrote:
+ When the token is /not/ an argument for a macro, xI is the same
+ location as yI. Otherwise, xI is either the virtual location of
+ that argument token if it comes from a macro expansion itself, or
+ its spelling location.
I think
Hi Nick,
>> Experiments show that the
>> existing multi-if-block support isn't terribly effective on FRV;
>> before-after comparisons show that by turning it off, there are three
>> spots in gcc that are meaningfully changed, and below 20 in the C
>> benchmarks of SPEC2k.
>>
>> FRV also doesn't bu
Artem Shinkarov schrieb:
> On Fri, Sep 30, 2011 at 4:01 PM, Georg-Johann Lay wrote:
>> Artem Shinkarov schrieb:
>>> Here is a new version of the patch which considers the changes from
>>> 2011-09-02 Richard Guenther
>>>
>>>
>>> ChangeLog
>>>
>>> 20011-09-06 Artjoms Sinkarovs
>>>
>>>gcc/
On Fri, Sep 30, 2011 at 05:36:47PM +0200, Georg-Johann Lay wrote:
> >> The target has
> >>
> >> 2 = sizeof (short)
> >> 2 = sizeof (int)
> >> 4 = sizeof (long int)
> >> 8 = sizeof (long long int)
> >>
> >> Could you fix that? I.e. parametrize sizeof(int) out or skip the test by
> >> means of
> >>
On Fri, Sep 30, 2011 at 4:43 PM, Jakub Jelinek wrote:
> On Fri, Sep 30, 2011 at 05:36:47PM +0200, Georg-Johann Lay wrote:
>> >> The target has
>> >>
>> >> 2 = sizeof (short)
>> >> 2 = sizeof (int)
>> >> 4 = sizeof (long int)
>> >> 8 = sizeof (long long int)
>> >>
>> >> Could you fix that? I.e. par
On Fri, Sep 30, 2011 at 04:48:41PM +0100, Artem Shinkarov wrote:
> Most likely we can. The question is what do we really want to check
> with this test. My intention was to check that a programmer can
> statically get correspondence of the types, in a sense that sizeof
> (float) == sizeof (int) and
On Fri, Sep 30, 2011 at 4:11 AM, Kirill Yukhin wrote:
> Okay, seems maintainers have no objections
>
> Could anybody please commit that to wwwdocs?
>
Your patch can't be applied. Please provide a proper patch.
Thanks.
--
H.J.
The main purpose of this patch is to move some declarations to a new
file, regrename.h, and make regrename_analyze and do_replace callable
from elsewhere. The second patch will add code to c6x.c to make use of
this from the modulo-scheduling code.
This also adds a small amount of new functionality
On Fri, Sep 30, 2011 at 4:54 PM, Jakub Jelinek wrote:
> On Fri, Sep 30, 2011 at 04:48:41PM +0100, Artem Shinkarov wrote:
>> Most likely we can. The question is what do we really want to check
>> with this test. My intention was to check that a programmer can
>> statically get correspondence of the
This is the final piece which makes use of all the previous regrename
patches, and transforms this loop (which occurs in a popular embedded
benchmark):
sploop 2
.L4:
ldh .d1t1 *A6++[1], A7
ldh .d1t1 *++A5[1], A8
nop 4
Hi,
I checked in this patch as an obvious fix.
H.J.
---
Index: doc/extend.texi
===
--- doc/extend.texi (revision 179396)
+++ doc/extend.texi (working copy)
@@ -6722,8 +6722,8 @@ return the new value. That is,
builtin as @co
On 26 July 2011 10:01, Dr. David Alan Gilbert wrote:
>
> +
> +extern unsigned int __write(int fd, const void *buf, unsigned int count);
Why are we using __write instead of write?
A comment elaborating that this file should only be in the static
libgcc and never in the dynamic libgcc would be use
On Fri, Sep 16, 2011 at 01:08:13AM +0200, Mikael Morin wrote:
>
> OK for trunk?
>
> Mikael
>
> patchset layout:
> - patches 1..4:
> Preliminary cleanups.
> Those are quite independant on the rest.
> Patch 4 is optional.
>
> - patches 5..13:
> Step by step move from s
On 09/27/2011 02:02 PM, Bernd Schmidt wrote:
> Here's a new version of the entire shrink-wrapping patch with the
> trap_if test replaced by the outgoing_edges_match change, the condjump_p
> bug fixed, and the dump output and testcase adjusted a bit. Bootstrapped
> and tested on i686-linux and mips-
On Fri, Sep 30, 2011 at 9:45 AM, Ramana Radhakrishnan
wrote:
> On 26 July 2011 10:01, Dr. David Alan Gilbert
> wrote:
>>
>> +
>> +extern unsigned int __write(int fd, const void *buf, unsigned int count);
>
> Why are we using __write instead of write?
>
> A comment elaborating that this file shou
Artem Shinkarov schrieb:
On Fri, Sep 30, 2011 at 4:54 PM, Jakub Jelinek wrote:
On Fri, Sep 30, 2011 at 04:48:41PM +0100, Artem Shinkarov wrote:
Most likely we can. The question is what do we really want to check
with this test. My intention was to check that a programmer can
statically get c
Patch http://gcc.gnu.org/ml/gcc-patches/2010-12/msg00625.html was
approved by Jason last December but I never got around to checking
it in. Paolo Carlini said in PR44473 that it was already approved
and doesn't need a new approval, so I checked it in after a
bootstrap and regtest of c,c++ for i686
Diego asked me what this flag was for; I looked, and found it to be a
write-only flag. So out it goes.
Tested x86_64-pc-linux-gnu, applied to trunk.
commit 59817b6e5fa3fafbce5fa2b1a111b2aa37eea091
Author: Jason Merrill
Date: Tue Sep 27 10:45:07 2011 -0400
* cp-tree.h (TREE_NEGATED_INT)
On Fri, Sep 30, 2011 at 05:17:00PM +0200, Jakub Jelinek wrote:
> Here is the updated patch, bootstrapped/regtested on x86_64-linux and
> i686-linux, committed to trunk. Will work on 4.6 backport of the str{,n}cat
> part.
And here is the backport I've just committed. 4.6 doesn't handle
BUILT_IN_*
> I hope that the new version looks a little bit better.
Nearly ok. Some trivial fixes, and then please commit.
> + rtx_v0 = expand_normal (v0);
> + rtx_mask = expand_normal (mask);
> +
> + create_output_operand (&ops[0], target, mode);
> + create_input_operand (&ops[3], rtx_mask, mode);
> +
On 09/30/2011 09:08 AM, Bernd Schmidt wrote:
> gcc/
> * regrename.h: New file.
> * regrename.c: Include it. Also include "emit-rtl.h".
> (struct du_head, struct du_chain, du_head_p DEF_VEC and
> DEF_VEC_ALLOC_P): Move to regrename.h.
> (do_replace): Remove decla
On 09/29/2011 06:13 PM, Jiangning Liu wrote:
>
>
>> -Original Message-
>> From: Jakub Jelinek [mailto:ja...@redhat.com]
>> Sent: Thursday, September 29, 2011 6:14 PM
>> To: Jiangning Liu
>> Cc: 'Richard Guenther'; Andrew Pinski; gcc-patches@gcc.gnu.org
>> Subject: Re: [PATCH] Fix stack re
On Fri, 30 Sep 2011, Ramana Radhakrishnan wrote:
> On 26 July 2011 10:01, Dr. David Alan Gilbert
> wrote:
> >
> > +
> > +extern unsigned int __write(int fd, const void *buf, unsigned int count);
>
> Why are we using __write instead of write?
Because plain write is in the user's namespace in IS
On 30/09/2011, at 6:56 PM, Maxim Kuvyrkov wrote:
> On 30/09/2011, at 4:02 PM, Maxim Kuvyrkov wrote:
>
>> On 24/09/2011, at 2:19 AM, Martin Jambor wrote:
>>
>>> However, both of these are really 4.8 material and since the patches
>>> probably need only minor updates, it might be worthwhile to do
On 09/30/2011 11:28 AM, Jason Merrill wrote:
+linemap_location_before_p (struct line_maps *set,
+ source_location pre,
+ source_location post)
+{
+ bool pre_from_macro_p, post_from_macro_p;
+
+ if (pre == post)
+return false;
+
+ pre_from_
Disable running of callgraph-profiles.C is section attribute "e" is not
supported.
Index: lib/target-supports-dg.exp
===
--- lib/target-supports-dg.exp (revision 179400)
+++ lib/target-supports-dg.exp (working copy)
@@ -100,6 +100,
On 11-09-30 16:44 , Sriraman Tallam wrote:
Disable running of callgraph-profiles.C is section attribute "e" is not
supported.
OK with a ChangeLog entry.
Was the original patch sent to trunk? I don't recall.
Diego.
ChangeLog entry:
* testsuite/g++.dg/tree-prof/callgraph-profiles/C: Add
dg-require-section-exclude. * testsuite/lib/target-supports.exp
(check_ifunc_available): New proc. *
testsuite/lib/target-supports-dg.exp (dg-require-section-exclude): New
proc.
On Fri, Sep 30, 20
On Fri, Sep 30, 2011 at 1:48 PM, Diego Novillo wrote:
> On 11-09-30 16:44 , Sriraman Tallam wrote:
>>
>> Disable running of callgraph-profiles.C is section attribute "e" is not
>> supported.
>
> OK with a ChangeLog entry.
>
> Was the original patch sent to trunk? I don't recall.
This was only se
On 11-09-30 16:50 , Sriraman Tallam wrote:
ChangeLog entry:
* testsuite/g++.dg/tree-prof/callgraph-profiles/C: Add
dg-require-section-exclude. * testsuite/lib/target-supports.exp
(check_ifunc_available): New proc. *
testsuite/lib/target-supports-dg.exp (dg-require-section-
On Fri, Sep 30, 2011 at 1:51 PM, Diego Novillo wrote:
> On 11-09-30 16:50 , Sriraman Tallam wrote:
>>
>> ChangeLog entry:
>>
>>
>> * testsuite/g++.dg/tree-prof/callgraph-profiles/C: Add
>> dg-require-section-exclude. * testsuite/lib/target-supports.exp
>> (check_ifunc_available): N
On 09/30/2011 12:59 AM, David Miller wrote:
>
> I tried to add the 'siam' instruction too but that one is really
> difficult because it influences the behavior of every float operation
> and I couldnt' find an easy way to express those dependencies. I
> tried a few easy approaches but I couldn't
* testsuite/gcc.dg/builtin_target.c: Specify target as ix86 or
x86_64.
Index: gcc.dg/builtin_target.c
===
--- gcc.dg/builtin_target.c (revision 179400)
+++ gcc.dg/builtin_target.c (working copy)
@@ -1,6 +1,6 @@
On 30/09/2011, at 6:56 PM, Maxim Kuvyrkov wrote:
> On 30/09/2011, at 4:02 PM, Maxim Kuvyrkov wrote:
>
>> On 24/09/2011, at 2:19 AM, Martin Jambor wrote:
>>
>>> However, both of these are really 4.8 material and since the patches
>>> probably need only minor updates, it might be worthwhile to do
On 09/30/2011 12:14 PM, Artem Shinkarov wrote:
> Ok, in the attachment there is a patch which fixes mentioned errors.
The changes are ok. I would have committed it for you, only the patch
isn't against mainline. There are 4 rejects.
r~
This is now submitted.
Thanks,
-Sri.
On Fri, Sep 30, 2011 at 2:09 PM, Sriraman Tallam wrote:
> * testsuite/gcc.dg/builtin_target.c: Specify target as ix86 or
> x86_64.
>
> Index: gcc.dg/builtin_target.c
> ===
> --- gcc
1 - 100 of 113 matches
Mail list logo
