On Wed, 3 Apr 2013, Richard Biener wrote:
On Wed, Apr 3, 2013 at 4:15 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
I am not 100% convinced that it is always better to fold to a MEM_REF, but
that's what the PR asks for.
bootstrap+testsuite on x86_64-linux-gnu.
2013-04-03 Marc Glisse
On Wed, 3 Apr 2013, Matthew Gretton-Dann wrote:
Would it be possible for this patch and the others Kyrylo has recently done
for the new ARMv8 AArch32 instructions to be backported to 4.8?
In particular I'm refering to:
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00994.html (trunk
Janus Weil wrote:
Ok, here is the follow-up patch, which removes the warning on
(alternate) RETURN statements, in order to avoid double diagnostics.
(In altreturn_5.f90 there apparently were some superfluous control
characters, which were removed by my editor.)
As my editor shows, that file
On Thu, Apr 4, 2013 at 9:23 AM, Marc Glisse marc.gli...@inria.fr wrote:
On Wed, 3 Apr 2013, Richard Biener wrote:
On Wed, Apr 3, 2013 at 4:15 PM, Marc Glisse marc.gli...@inria.fr wrote:
Hello,
I am not 100% convinced that it is always better to fold to a MEM_REF,
but
that's what the PR
On Wed, Apr 3, 2013 at 6:13 PM, David Malcolm dmalc...@redhat.com wrote:
I'm working on my first gcc contribution, but it's a large patch, and I
wanted to sound things out on this list.
I want to eliminate/minimize global state within gcc, since I think
doing so is a key part of making gcc
On Thu, 4 Apr 2013, Richard Biener wrote:
+ if ((handled_component_p (arg0) || TREE_CODE (arg0) == MEM_REF)
This check means the optimization is not performed for
BIT_FIELD_REF[a, *, CST] which I see no particularly good reason for.
Er, are you trying to get rid of all
On 3 April 2013 12:59, Paolo Carlini wrote:
On 04/03/2013 01:53 PM, Jonathan Wakely wrote:
On 3 April 2013 12:45, Paolo Carlini wrote:
On 04/03/2013 02:09 AM, Jonathan Wakely wrote:
This patch implements
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3189.htm
Thanks Jon. I'm
Hi,
On 04/04/2013 10:56 AM, Jonathan Wakely wrote:
On 3 April 2013 12:59, Paolo Carlini wrote:
On 04/03/2013 01:53 PM, Jonathan Wakely wrote:
On 3 April 2013 12:45, Paolo Carlini wrote:
On 04/03/2013 02:09 AM, Jonathan Wakely wrote:
This patch implements
On Wed, Apr 3, 2013 at 6:16 PM, Kenneth Zadeck zad...@naturalbridge.com wrote:
On 04/03/2013 09:53 AM, Richard Biener wrote:
On Wed, Apr 3, 2013 at 2:05 PM, Kenneth Zadeck zad...@naturalbridge.com
wrote:
On 04/03/2013 05:17 AM, Richard Biener wrote:
In the end you will have a variable-size
On Thu, Apr 4, 2013 at 10:53 AM, Marc Glisse marc.gli...@inria.fr wrote:
On Thu, 4 Apr 2013, Richard Biener wrote:
+ if ((handled_component_p (arg0) || TREE_CODE (arg0) == MEM_REF)
This check means the optimization is not performed for
BIT_FIELD_REF[a, *, CST] which I see no
-Original Message-
From: Richard Biener [mailto:rguent...@suse.de]
Sent: 04 April 2013 08:46
To: Matthew Gretton-Dann
Cc: gcc-patches@gcc.gnu.org; Kyrylo Tkachov; Ramana Radhakrishnan;
Richard Earnshaw
Subject: Re: [PATCH][ARM] use vsel instruction for floating point
conditional
On 04/04/13 08:46, Richard Biener wrote:
On Wed, 3 Apr 2013, Matthew Gretton-Dann wrote:
Would it be possible for this patch and the others Kyrylo has recently done
for the new ARMv8 AArch32 instructions to be backported to 4.8?
In particular I'm refering to:
On Thu, 4 Apr 2013, Richard Biener wrote:
On Thu, Apr 4, 2013 at 10:53 AM, Marc Glisse marc.gli...@inria.fr wrote:
On Thu, 4 Apr 2013, Richard Biener wrote:
+ if ((handled_component_p (arg0) || TREE_CODE (arg0) == MEM_REF)
This check means the optimization is not performed for
Le 04/04/2013 00:56, Tobias Burnus a écrit :
Am 04.04.2013 00:27, schrieb Mikael Morin:
Le 02/04/2013 19:19, Tobias Burnus a écrit :
{
snprintf (message, MSGLEN,
Read kind %d %s where kind %d is required for item %d,
- dtp-u.p.saved_length, type_name
I'm about to backport one patch (a fix for PR48189) to 4.6 branch.
Bootstrapped/regtested on x86_64-linux, acked by Jakub on IRC.
Will commit soon.
ChangeLog:
2013-04-04 Marek Polacek pola...@redhat.com
Backported from mainline
2013-01-09 Steven Bosscher ste...@gcc.gnu.org
On Thu, 4 Apr 2013, Ramana Radhakrishnan wrote:
On 04/04/13 08:46, Richard Biener wrote:
On Wed, 3 Apr 2013, Matthew Gretton-Dann wrote:
Would it be possible for this patch and the others Kyrylo has recently
done
for the new ARMv8 AArch32 instructions to be backported to 4.8?
This fixes PR56837, memset recognition should verify that constants
really cover all of their representation. Esp. all-ones ones.
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2013-04-04 Richard Biener rguent...@suse.de
PR tree-optimization/56837
*
Hi all,
Can I backport the patch at
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00652.html
to 4.8?
It fixes PR 56720 on arm-*-* targets.
The trunk commits for this are r197040 and r197041.
It applies cleanly to 4.8 and regtests cleanly on arm-none-eabi.
Thanks,
Kyrill
There is no longer a good reason to restrict the memory references
we perform strided loads on during vectorization. In particular
a bug(?) in the current restriction makes it not apply for
array loads from decls (as opposed to array loads from pointers
which happens for fortran or VLA pointer
This fixes the testcase in PR56826, the underlying issue being
that a SLP group load with a gap is detected as supported while
it is not because we compute ncopies incorrectly. The following
patch makes us compute ncopies more correctly.
Bootstrap and regtest pending on
On Thu, Apr 4, 2013 at 12:11 PM, Marc Glisse marc.gli...@inria.fr wrote:
On Thu, 4 Apr 2013, Richard Biener wrote:
On Thu, Apr 4, 2013 at 10:53 AM, Marc Glisse marc.gli...@inria.fr wrote:
On Thu, 4 Apr 2013, Richard Biener wrote:
+ if ((handled_component_p (arg0) || TREE_CODE (arg0) ==
OK /Marcus
On 3 April 2013 14:35, Tejas Belagod tbela...@arm.com wrote:
Hi,
The attached patch fixes duplication in a test case for gcc.target/aarch64/.
Tested on aarch64-none-elf. OK for trunk and branch?
Thanks,
Tejas Belagod
ARM.
2013-04-03 Tejas Belagod tejas.bela...@arm.com
On 04/04/13 11:55, Kyrylo Tkachov wrote:
Hi all,
Can I backport the patch at
http://gcc.gnu.org/ml/gcc-patches/2013-03/msg00652.html
to 4.8?
It fixes PR 56720 on arm-*-* targets.
The trunk commits for this are r197040 and r197041.
It applies cleanly to 4.8 and regtests cleanly on
~/src/qemu/qemu-git/arm-linux-user/qemu-arm -cpu cortex-a9 -R 0 -L
/home/lyon/src/GCC/builds/gcc-fsf-asan-arm-none-linux-gnueabihf/sysroot
./heap-overflow-1.arm
On 28 March 2013 15:33, Christophe Lyon christophe.l...@linaro.org wrote:
- libsanitizer detects if its output is a tty, and when GCC
Hi,
This backports the fix for PR48308 something that's slipped through the
cracks. I wrote the backport and then noticed that Mikael had a similar
solution - the only difference being around this guarded for HAVE_cc0
targets.
Tested cross arm-none-linux-gnueabi - no regressions.
On Thu, Apr 04, 2013 at 02:11:39PM +0100, Ramana Radhakrishnan wrote:
This backports the fix for PR48308 something that's slipped through
the cracks. I wrote the backport and then noticed that Mikael had a
similar solution - the only difference being around this guarded for
HAVE_cc0 targets.
Another case where we got a SIGFPE if HOT_BB_FREQUENCY_FRACTION
is 0 - in that case we divide by zero.
Regtested/bootstrapped on x86_64-linux, ok for trunk/4.8?
2013-04-04 Marek Polacek pola...@redhat.com
PR tree-optimization/48186
* predict.c (maybe_hot_frequency_p): Return
This fixes an ICE in case we use weirdo --param value for
PARAM_ALIGN_THRESHOLD. The patch is by Andrew; I added CL, testcase
and tested.
Bootstrapped/regtested on x86_64-linux, ok for trunk? And what about other
branches?
2013-04-04 Marek Polacek pola...@redhat.com
Andrew
On Thu, Apr 04, 2013 at 04:00:48PM +0200, Marek Polacek wrote:
--- gcc/predict.c.mp 2013-04-04 15:04:29.925685185 +0200
+++ gcc/predict.c 2013-04-04 15:04:33.123696281 +0200
@@ -122,6 +122,8 @@ maybe_hot_frequency_p (struct function *
if (node-frequency == NODE_FREQUENCY_EXECUTED_ONCE
Hi Richard,
You slightly change behavior of find_base_term, namely before your fix
we have the following code:
if (REG_P (tmp1) REG_POINTER (tmp1))
{
rtx base = find_base_term (tmp1);
if (base)
return base;
}
but in your fix you added the following checks on base:
tmp1 =
On Thu, Apr 4, 2013 at 3:33 PM, Yuri Rumyantsev ysrum...@gmail.com wrote:
Hi Richard,
You slightly change behavior of find_base_term, namely before your fix we
have the following code:
if (REG_P (tmp1) REG_POINTER (tmp1))
{
rtx base = find_base_term (tmp1);
if (base)
return
On Thu, Apr 04, 2013 at 04:06:35PM +0200, Jakub Jelinek wrote:
In this second hunk the division is done only for flag_guess_branch_prob,
so shouldn't it be
if (flag_guess_branch_prob)
{
if (PARAM_VALUE (HOT_BB_FREQUENCY_FRACTION) == 0
|| edge-frequency = (CGRAPH_FREQ_BASE
On Thu, 4 Apr 2013, Richard Biener wrote:
This fixes the testcase in PR56826, the underlying issue being
that a SLP group load with a gap is detected as supported while
it is not because we compute ncopies incorrectly. The following
patch makes us compute ncopies more correctly.
Which
On Thu, Apr 04, 2013 at 04:20:36PM +0200, Marek Polacek wrote:
On Thu, Apr 04, 2013 at 04:06:35PM +0200, Jakub Jelinek wrote:
In this second hunk the division is done only for flag_guess_branch_prob,
so shouldn't it be
if (flag_guess_branch_prob)
{
if (PARAM_VALUE
On Thu, Apr 04, 2013 at 04:29:34PM +0200, Marek Polacek wrote:
On Thu, Apr 04, 2013 at 04:20:36PM +0200, Marek Polacek wrote:
On Thu, Apr 04, 2013 at 04:06:35PM +0200, Jakub Jelinek wrote:
In this second hunk the division is done only for flag_guess_branch_prob,
so shouldn't it be
if
On Thu, 2013-04-04 at 10:42 +0200, Richard Biener wrote:
Thanks for looking at this; comments inline throughout.
On Wed, Apr 3, 2013 at 6:13 PM, David Malcolm dmalc...@redhat.com wrote:
I'm working on my first gcc contribution, but it's a large patch, and I
wanted to sound things out on
On Wed, Apr 03, 2013 at 03:23:36PM +0200, Richard Biener wrote:
Status
==
The GCC 4.7 branch is ready for a release candidate of GCC 4.7.3
which I will do tomorrow if no serious issue shows up until then.
The branch is frozen now, all changes require release manager approval
until
On Thu, 4 Apr 2013, Jack Howarth wrote:
On Wed, Apr 03, 2013 at 03:23:36PM +0200, Richard Biener wrote:
Status
==
The GCC 4.7 branch is ready for a release candidate of GCC 4.7.3
which I will do tomorrow if no serious issue shows up until then.
The branch is frozen now, all
On Thu, Apr 04, 2013 at 10:42:47AM +0200, Richard Biener wrote:
I originally thought of using namespaces to fend off pass-specific globals,
but eventually moving it all to a pass specific class would work, too.
Note that there are some passes that have global data that is allocated
and
On Apr 2, 2013, at 1:55 AM, Eric Botcazou ebotca...@adacore.com wrote:
The question is: do we really need to canonicalize everything?
The fear (at least mine) is that, by canonicalizing everything, you will make
changes behind the back of back-ends that could disable some of their
patterns
On 04/04/13 14:16, Jakub Jelinek wrote:
On Thu, Apr 04, 2013 at 02:11:39PM +0100, Ramana Radhakrishnan wrote:
This backports the fix for PR48308 something that's slipped through
the cracks. I wrote the backport and then noticed that Mikael had a
similar solution - the only difference being
On Apr 4, 2013, at 1:07 AM, Tobias Burnus bur...@net-b.de wrote:
As my editor shows, that file uses DOS line endings (\r\n) in some lines and
UNIX ones (\n) in others. In principle, I am for keeping such files to test
the parser.
If one keeps them, please put them into a file that tests for
Hello,
This patch removes a dbr_schedule() call from the sparc back end, and
plugs in a sparc-specific pass that needs the insn chain in
delayed-branch scheduled form after pass_delay_slots. This is
essentially the same patch as the one I posted yesterday
As my editor shows, that file uses DOS line endings (\r\n) in some lines and
UNIX ones (\n) in others. In principle, I am for keeping such files to test
the parser.
If one keeps them, please put them into a file that tests for that feature
exclusively, as we often find turds, oops, I mean
On 2013-04-04 13:47 , Jing Yu wrote:
I found that google/gcc-4_8 has the same problem. OK for google/gcc-4_8?
Yes. Thanks.
Diego.
Hi!
The vt3.C testcase (from PR34949) ICEd, because sink_clobbers sunk a
MEM_REF[SSA_NAME] clobber from a landing pad which that SSA_NAME definition
dominated to an outer one which wasn't dominated by the definition.
As the ehcleanup nor ehdisp passes keep dominance info current and perform
Hi!
As discussed on IRC, this patch allows as to recognize more patterns as
memset, see the testcase for what it can do.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2013-04-04 Jakub Jelinek ja...@redhat.com
* tree-loop-distribution.c
Jakub Jelinek ja...@redhat.com wrote:
Hi!
As discussed on IRC, this patch allows as to recognize more patterns as
memset, see the testcase for what it can do.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
Can you factor out a function that returns
A proper qimode value
On Apr 4, 2013, at 10:26 AM, Robert Dewar de...@adacore.com wrote:
I must say though that Apple choosing to use CR only was simply
perverse :-)
Apple uses the posix standard for line endings, just like unix. :-P
On Thu, Apr 04, 2013 at 08:37:47PM +0200, Richard Biener wrote:
Can you factor out a function that returns
A proper qimode value if possible or null and
Use it in both places?
Like this?
2013-04-04 Jakub Jelinek ja...@redhat.com
* tree-loop-distribution.c
Hello,
Just some things I've had in my tree for a while now, ChangeLog says it all:
* bb-reorder.c (fix_crossing_unconditional_branches): Remove a
set-but-unused variable.
* cgraph.c (cgraph_release_function_body): Clear cfun-cfg to make
basic blocks of released
Hi,
The following patches were bootstrapped and regtested on
x86_64-unknown-linux-gnu without new regressions.
They fix a few problems i faced when building against uClibc.
Ok for trunk and, in a week or two, the 4.8 branch?
PS:
I would like to ask the libstdc++ folks to advise on the tmpnam
uClibc can be built without fenv support, extend the configure check for
decimal floating point to probe the existance of fenv.h, too.
libgcc/ChangeLog:
2013-03-24 Bernhard Reutner-Fischer al...@gcc.gnu.org
* configure.ac (libgcc_cv_dfp): Extend check to probe fenv.h
uClibc can be built without Largefile support, add the corresponding
guards. uClibc does not have __libc_malloc()/__libc_free(), add guard.
libsanitizer/ChangeLog
2013-03-24 Bernhard Reutner-Fischer al...@gcc.gnu.org
* sanitizer_common/sanitizer_allocator.cc (libc_malloc,
Bootstrapped and regtested on x86_64-unknown-linux-gnu and
x86_64-mine-linux-uclibc without regressions, ok for trunk?
fixincludes/ChangeLog:
2013-04-04 Bernhard Reutner-Fischer al...@gcc.gnu.org
Makefile.in: Use $(FI) instead of fixincl@EXEEXT@.
Cleanup whitespace while at
On 04/04/2013 01:49 PM, Steven Bosscher wrote:
Hello,
Just some things I've had in my tree for a while now, ChangeLog says it all:
* bb-reorder.c (fix_crossing_unconditional_branches): Remove a
set-but-unused variable.
* cgraph.c (cgraph_release_function_body):
On Thu, Apr 4, 2013 at 2:53 PM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
POSIX.1-2008 (SUSv4) marks tmpnam() as obsolescent. As such it is not
available in uClibc unless SUSv4 legacy stuff is enabled.
libstdc++-v3/ChangeLog
2013-03-24 Bernhard Reutner-Fischer al...@gcc.gnu.org
Except as noted below, fine by me.
On 04/04/13 12:56, Bernhard Reutner-Fischer wrote:
Bootstrapped and regtested on x86_64-unknown-linux-gnu and
x86_64-mine-linux-uclibc without regressions, ok for trunk?
fixincludes/ChangeLog:
2013-04-04 Bernhard Reutner-Fischer al...@gcc.gnu.org
On Thu, Apr 4, 2013 at 12:53 PM, Bernhard Reutner-Fischer
rep.dot@gmail.com wrote:
2013-03-24 Bernhard Reutner-Fischer al...@gcc.gnu.org
* configure.ac (libgcc_cv_dfp): Extend check to probe fenv.h
availability.
* configure: Regenerate
This is OK.
Thanks.
Ian
This is a minor nit on the C++ reference qualifiers.
Obviously, ref quals are not a sequence.
Adding multiple ref quals did error out but this patch cleans up the
error from a few unexpected tokens to one root cause.
Also _seq is removed from te cp_parser function name.
builds and passes all
On Mon, Apr 1, 2013 at 2:27 PM, Rong Xu x...@google.com wrote:
On Fri, Mar 29, 2013 at 1:06 PM, Teresa Johnson tejohn...@google.com
wrote:
On Fri, Mar 29, 2013 at 11:16 AM, Jan Hubicka hubi...@ucw.cz wrote:
Hi,
currently we use Theresa's code to determine hot/cold decisions based on
Hi,
in the audit trail of c++/56815 Manuel noticed that, inconsistently with
the documentation, a LangEnabledBy was missing for -Wpointer-arith vs
-Wpedantic.
Then I noticed that a clean up was possible in the actual pedwarn calls,
which, in fact, also fixes a bug: we don't want to actually
Hi Balaji.
This is a patch against, the [cilkplus] branch (not the [cilkplus-merge]
branch). I have taken the liberty to start cleaning up the #pragma
simd stuff on your development branch, while the array notation
patchset is being reviewed by Joseph.
Herein lies a potpourri of fixes,
Hi,
Current Makefile.in does not match Makefile.def. Regenerate it by
autogen Makefile.def.
Tested the patched google/gcc-4_8 with crosstool-validate.py
--testers=crosstool.
OK for google/gcc-4_8?
Thanks,
Jing
Index: Makefile.in
Hi!
Re-visiting this patch/commit after a mere ten years, ha, ha. :-) Surely
everyone must still be having context on this issue... (MIPS and soft-fp
maintainers CCed.)
On 01 Apr 2003 18:44:53 -0300, Alexandre Oliva aoliva at redhat dot com wrote:
Index: gcc/ChangeLog
from Alexandre Oliva
OK, thanks.
Jason
The C++ changes are OK.
Jason
From: Zhouyi Zhou yizhouz...@ict.ac.cn
Sender: Zhouyi Zhou yizhouz...@ict.ac.cn
To: gcc-patches@gcc.gnu.org
Subject: [PATCH] inline fail reporting: reporting inline fail caused by
overwritable function
When inline failed because of callee is overwritable, gcc will not report it
in dump
This patch updates the gcc docs on programming language standards to
mention the Go 1 standard. Bootstrapped on x86_64-unknown-linux-gnu.
Committed to mainline and 4.8 branch.
Ian
2013-04-04 Ian Lance Taylor i...@google.com
* doc/standards.texi (Standards): The Go frontend supports
69 matches
Mail list logo
