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 forbid for input operands const qualified memory).
On m (1) in the
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.)
I added
Hello,
OK, with the following comments:
Make sure reg_moves are generated for the correct (result, not addr)
register, in generate_reg_moves().
beenbeing (multiple appearances).
Add a note that autoinc_var_is_used_p (rtx def_insn, rtx use_insn)
doesn't need to consider the specific
On Sep 29, 2011, at 5:54 PM, Basile Starynkevitch wrote:
On Thu, 29 Sep 2011 17:10:26 +0200
Tristan Gingold ging...@adacore.com 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
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 correct,
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
On Thu, Sep 29, 2011 at 5:57 PM, Tom de Vries tom_devr...@mentor.com 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
Jiangning Liu jiangning@arm.com 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
On Thu, Sep 29, 2011 at 11:17 PM, Jakub Jelinek ja...@redhat.com 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
On Fri, Sep 30, 2011 at 8:17 AM, Jakub Jelinek ja...@redhat.com 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
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
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
*
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 ja...@redhat.com 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,
On Thu, Sep 29, 2011 at 10:10 AM, Tristan Gingold ging...@adacore.com 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
On Thu, Sep 29, 2011 at 11:15 PM, Jakub Jelinek ja...@redhat.com 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
On 29/09/11 12:27, Richard Guenther wrote:
On Thu, Sep 29, 2011 at 12:00 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Wed, Sep 28, 2011 at 4:23 PM, Richard Guenther
richard.guent...@gmail.com wrote:
On Mon, Sep 26, 2011 at 5:43 PM, Richard Guenther
richard.guent...@gmail.com
On Fri, Sep 30, 2011 at 00:09, Andi Kleen a...@linux.intel.com wrote:
gcc/lto/:
2011-09-29 H.J. Lu hongjiu...@intel.com
Andi Kleen a...@linux.intel.com
PR lto/50568
* lto.c (lto_splay_tree_delete_id): New.
(lto_splay_tree_compare_ids): Likewise.
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 ger...@pfeifer.com 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,
On Fri, Sep 30, 2011 at 10:03 AM, Revital Eres revital.e...@linaro.org 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
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.
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 jbeul...@suse.com
* lto-cgraph.c (output_cgraph): Remove processing of
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/
-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.
On Fri, Sep 30, 2011 at 1:11 PM, Jakub Jelinek ja...@redhat.com 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)) ==
On Fri, Sep 30, 2011 at 1:43 PM, Jan Beulich jbeul...@suse.com 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 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 turned out
Jiangning Liu jiangning@arm.com 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
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 ja...@redhat.com 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
On Fri, Sep 30, 2011 at 2:46 PM, Richard Sandiford
richard.sandif...@linaro.org wrote:
Jiangning Liu jiangning@arm.com 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
On 30.09.11 at 14:42, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Sep 30, 2011 at 1:43 PM, Jan Beulich jbeul...@suse.com 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
Richard Sandiford richard.sandif...@linaro.org 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 ja...@redhat.com 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
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
On Thu, Sep 29, 2011 at 3:15 PM, Tom de Vries tom_devr...@mentor.com wrote:
On 09/28/2011 11:53 AM, Richard Guenther wrote:
On Wed, Sep 28, 2011 at 11:34 AM, Tom de Vries tom_devr...@mentor.com
wrote:
Richard,
I got a patch for PR50527.
The patch prevents the alignment of vla-related
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 rguent...@suse.de
PR middle-end/50574
* tree-cfg.c
-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 to
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
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
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
*
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 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 ging...@adacore.com 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
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 pass
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 named argument.
On 30.09.11 at 14:34, Richard Guenther richard.guent...@gmail.com wrote:
On Fri, Sep 30, 2011 at 1:43 PM, Jan Beulich jbeul...@suse.com 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
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 artyom.shinkar...@gmail.com
gcc/
* fold-const.c (constant_boolean_node): Adjust the meaning
of
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 ja...@redhat.com
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 ja...@redhat.com
On Fri, Sep 30, 2011 at 4:01 PM, Georg-Johann Lay a...@gjlay.de 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 artyom.shinkar...@gmail.com
gcc/
*
On Fri, Sep 30, 2011 at 12:35:49PM +0200, Richard Guenther wrote:
On Fri, Sep 30, 2011 at 12:23 PM, Jakub Jelinek ja...@redhat.com 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
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 such as
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
2011/7/22 Richard Sandiford richard.sandif...@linaro.org:
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
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
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 build in
Artem Shinkarov schrieb:
On Fri, Sep 30, 2011 at 4:01 PM, Georg-Johann Lay a...@gjlay.de 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 artyom.shinkar...@gmail.com
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 ja...@redhat.com 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. parametrize
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 kirill.yuk...@gmail.com 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.
On Fri, Sep 30, 2011 at 4:54 PM, Jakub Jelinek ja...@redhat.com 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
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
On 26 July 2011 10:01, Dr. David Alan Gilbert david.gilb...@linaro.org 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
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
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
On Fri, Sep 30, 2011 at 9:45 AM, Ramana Radhakrishnan
ramana.radhakrish...@linaro.org wrote:
On 26 July 2011 10:01, Dr. David Alan Gilbert david.gilb...@linaro.org
wrote:
+
+extern unsigned int __write(int fd, const void *buf, unsigned int count);
Why are we using __write instead of write?
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
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 ja...@redhat.com
Date: Tue Sep 27 10:45:07 2011 -0400
* cp-tree.h
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
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);
+
+ if
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 declaration.
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 red zone bug
On Fri, 30 Sep 2011, Ramana Radhakrishnan wrote:
On 26 July 2011 10:01, Dr. David Alan Gilbert david.gilb...@linaro.org
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
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 that so
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;
+
+
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
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,
On Fri, Sep 30, 2011 at 1:48 PM, Diego Novillo dnovi...@google.com 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
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
On Fri, Sep 30, 2011 at 1:51 PM, Diego Novillo dnovi...@google.com 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
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 that so
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 tmsri...@google.com wrote:
* testsuite/gcc.dg/builtin_target.c: Specify target as ix86 or
x86_64.
Index: gcc.dg/builtin_target.c
On 09/30/2011 02: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.dg/builtin_target.c (revision 179400)
+++
Moving test gcc.target/i386
* testsuite/gcc.dg/builtin_target.c: Remove.
* testsuite/gcc.target/i386/builtin_target.c: New file.
On Fri, Sep 30, 2011 at 2:33 PM, Richard Henderson r...@redhat.com wrote:
On 09/30/2011 02:09 PM, Sriraman Tallam wrote:
*
On Fri, 30 Sep 2011, Richard Henderson wrote:
Specifically, in-compiler support for #pragma STDC FENV_ACCESS and the
various fenv.h routines. We ought to be able to track the rounding
mode (and other relevant parameters) on a per-expression basis, tagging
each floating-point operation with
From: Richard Henderson r...@redhat.com
Date: Fri, 30 Sep 2011 14:03:52 -0700
(3) Use optimize-mode-switching to minimize the number of changes
to the global state. This includes the use of SIAM vs %fsr,
especially when a subroutine call could have changed the
global
On 09/28/2011 07:34 AM, Nick Clifton wrote:
-(define_insn smaxsi3
- [(set (match_operand:SI 0 register_operand =r,r,r,r,r,r)
- (smax:SI (match_operand:SI 1 register_operand %0,0,0,0,0,0)
- (match_operand:SI 2 rx_source_operand
-
This patch disables early inlining when --coverage option is
specified. This improves coverage data in presence of other
optimizations, specially with -O2 where early inlining changes the
control flow graph sufficiently enough to generate seemingly very odd
source coverage.
Bootstrapped okay and
1 - 100 of 104 matches
Mail list logo
