On Tue, Oct 28, 2014 at 10:30:08AM -0700, Ian Taylor wrote:
On Tue, Oct 28, 2014 at 7:31 AM, Dominik Vogt v...@linux.vnet.ibm.com wrote:
The attached patch contains all the discussed changes.
I made a few formatting changes. I patched the test to work on x86,
by making the char types accept
Patch updated to remove conflicts with changed tests in patch 7.
Ciao
Dominik ^_^ ^_^
--
Dominik Vogt
IBM Germany
From e81ca934b619cad8b3872f28edbf3d2d0afeeec9 Mon Sep 17 00:00:00 2001
From: Dominik Vogt v...@linux.vnet.ibm.com
Date: Fri, 5 Sep 2014 07:31:01 +0100
Subject: [PATCH 8/9] Gccgo
2014-10-28 Richard Biener rguent...@suse.de
PR tree-optimization/63665
* tree-vect-slp.c (vect_get_mask_element): Properly handle
accessing out-of-bound elements.
Does fix it the assertion failure on the attached testcase? If so, would you
mind committing the testcase
I will commit the following change in MAINTAINERS.
Tristan.
2014-10-29 Tristan Gingold ging...@adacore.com
* MAINTAINERS: Change my email address.
--- MAINTAINERS (revision 216822)
+++ MAINTAINERS (working copy)
@@ -136,7 +136,7 @@
RTEMS PortsJoel Sherrill
Patch with the fixes:
Bootstrap, gcc make check and spec2000 with -p passed.
2014-10-29 Evgeny Stupachenko evstu...@gmail.com
gcc/testsuite
PR target/63534
* gcc.target/i386/mcount_pic.c: New.
gcc/
PR target/63534
* config/i386/i386.c (ix86_init_pic_reg): Emit
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2014-10-29 Richard Biener rguent...@suse.de
* tree-ssa-sccvn.c (try_to_simplify): Allow
gimple_fold_stmt_to_constant_1 to follow SSA use-def chains.
(visit_use): Likewise.
Index:
On Wed, Oct 29, 2014 at 12:21:15PM +0300, Evgeny Stupachenko wrote:
Patch with the fixes:
Bootstrap, gcc make check and spec2000 with -p passed.
2014-10-29 Evgeny Stupachenko evstu...@gmail.com
gcc/testsuite
PR target/63534
* gcc.target/i386/mcount_pic.c: New.
gcc/
Hi all,
This is a simple patch to fix ICE in comment 2 of PR61529:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61529
Bound checking code is added to make sure the frequency is within legal
range.
As far as I have observed, r215830 patch fixes the glibc building ICE.
And this patch should
From: Jakub Jelinek [mailto:ja...@redhat.com]
Sent: Tuesday, October 28, 2014 12:27 PM
Thomas, you know the code better, can you from the fix figure out
a testcase that current trunk miscompiles or doesn't optimize
because of this bug?
Here you are (see attachment).
Best regards,
Thomas
On Tue, Oct 28, 2014 at 5:14 PM, Ilya Enkovich enkovich@gmail.com wrote:
Hi,
This patch fixes PR63664 and PR63574. Problem is in NULL types for labels
not handled by ICF properly. I assume it is OK for labels to have NULL type
and added check into ICF rather then fixed label
Bummer. Why didn't my MUA warned me on this one?
Here you are.
Best regards,
Thomas
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Thomas Preud'homme
Sent: Wednesday, October 29, 2014 9:33 AM
To: 'Jakub Jelinek'; Richard
On Wed, Oct 29, 2014 at 4:31 AM, Andi Kleen a...@firstfloor.org wrote:
From: Andi Kleen a...@linux.intel.com
xbegin/xend/xabort were missing memory barriers. This can
lead to memory operations being moved out of transactions, which would
cause unexpected races.
Always generate implicit
Delorie d...@redhat.com
* gcc.dg/20141029-1.c: New.
Index: expmed.c
===
--- expmed.c(revision 216811)
+++ expmed.c(working copy)
@@ -454,13 +454,13 @@ strict_volatile_bitfield_p (rtx op0, uns
bitnum
On Wed, Oct 29, 2014 at 10:04 AM, Eric Botcazou ebotca...@adacore.com wrote:
2014-10-28 Richard Biener rguent...@suse.de
PR tree-optimization/63665
* tree-vect-slp.c (vect_get_mask_element): Properly handle
accessing out-of-bound elements.
Does fix it the assertion
On Wed, Oct 29, 2014 at 09:36:02AM -, Thomas Preud'homme wrote:
Bummer. Why didn't my MUA warned me on this one?
I think this is ok for trunk with proper ChangeLog entry.
Jakub
On Wed, Oct 29, 2014 at 10:20 AM, Richard Sandiford
richard.sandif...@arm.com wrote:
In https://gcc.gnu.org/ml/gcc/2014-10/msg00206.html I asked:
I have some plans to clean up the machine_mode handling and perhaps
make it hierarchical, so that functions that can only handle scalar
From: Nathan Sidwell [mailto:nat...@codesourcery.com]
Sent: Thursday, October 09, 2014 2:30 PM
On 10/09/14 09:25, Jason Merrill wrote:
I would think we want to handle this up in the existing defaulted_int
block:
my thought was to at least put it next to the explicit_int = -1 above.
It
Hi all,
This patch fixes an issue with the final_prescan workaround for the
Cortex-A53 erratum 835769
where calling recog_memoized could modify the recog data for the
multiply-accumulate instruction
when looking at a preceding asm block. This can lead to wrong code
generation.
The solution
Hi all,
This is the 4.8 backport of the trunk patch
(https://gcc.gnu.org/ml/gcc-patches/2014-10/msg03019.html).
Tested similarly.
Ok for that branch?
Thanks,
Kyrill
2014-10-28 Kyrylo Tkachov kyrylo.tkac...@arm.com
* config/aarch64/aarch64.c (aarch64_madd_needs_nop): Restore
recog
Hi all,
This is the backport of the trunk patch posted at
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg03019.html.
It is essentially the same content (only the diff context differs).
Jakub, this is a regression fix so, if ok'd, can we get this into 4.9.2
please?
Bootstrapped and regtested
On 26/08/14 13:36, Richard Earnshaw wrote:
On 29/07/14 15:49, Jiong Wang wrote:
test done
===
no regression on the full toolchain test on arm-none-eabi.
ok to install?
Hmm, I think this is wrong for DF mode. The principle the patch works
on is by tying the output to the value containing
PR52769 reports a bug that has been fixed in 4.7, but the test case
was never added. So I'd like to put this test in and close PR52769.
Ok?
2014-10-29 Marek Polacek pola...@redhat.com
PR c/52769
* gcc.dg/pr52769.c: New test.
diff --git gcc/testsuite/gcc.dg/pr52769.c
Hello Richard, Jan,
On 16 Oct 13:22, Jakub Jelinek wrote:
On Thu, Oct 16, 2014 at 03:17:36PM +0400, Ilya Verbin wrote:
The rest LGTM, but please run it through LTO review (Richard/Honza) too.
Ping?
--
Thanks, k
Jakub
Hi,
The patch enhances ifcvt to allow_cc_mode if HAVE_cbranchcc4.
Bootstrap and no make check regression on X86-64.
Will add new test cases after ccmp is enabled.
Ok for trunk?
Thanks!
-Zhenqiang
ChangeLog:
2014-10-29 Zhenqiang Chen zhenqiang.c...@arm.com
* ifcvt.c
On Tue, Oct 28, 2014 at 05:36:50PM +, Phil Muldoon wrote:
On 28/10/14 13:19, Joseph S. Myers wrote:
I'm seeing a different bootstrap failure from those already discussed:
In file included from
/scratch/jmyers/fsf/gcc-mainline/libcc1/../gcc/gcc-plugin.h:28:0,
from
-Original Message-
From: Richard Henderson [mailto:r...@redhat.com]
Sent: Monday, October 27, 2014 10:56 PM
To: Zhenqiang Chen
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [Ping] [PATCH, 1/10] two hooks for conditional compare (ccmp)
On 10/27/2014 12:47 AM, Zhenqiang Chen wrote:
+
Hello Richard, Jan,
On 08 Oct 11:23, Jakub Jelinek wrote:
On Tue, Sep 30, 2014 at 06:53:20PM +0400, Ilya Verbin wrote:
Bootstrapped and regtested on top of patch 2. Is it OK for trunk?
LGTM, with the requested var/section renames.
Would like if Honza and/or Richard had a look at the
-Original Message-
From: Richard Henderson [mailto:r...@redhat.com]
Sent: Monday, October 27, 2014 11:14 PM
To: Zhenqiang Chen
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [Ping] [PATCH, 2/10] prepare ccmp
On 10/27/2014 12:48 AM, Zhenqiang Chen wrote:
On 09/22/2014 11:43 PM,
Patch is rebased and merged with other changes according to comments.
Thanks!
-Zhenqiang
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Zhenqiang Chen
Sent: Tuesday, September 23, 2014 2:44 PM
To: gcc-patches@gcc.gnu.org
It would be nice to have libcc1 built just once, not bootstrap it, but
it is a build module, is that possible?
In toplevel configure.ac I'm seeing:
host_tools=texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim gdb
gprof etc expect dejagnu m4 utils guile fastjar gnattools libcc1
-Original Message-
From: Richard Henderson [mailto:r...@redhat.com]
Sent: Monday, October 27, 2014 11:20 PM
To: Zhenqiang Chen
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [Ping] [PATCH, 6/10] aarch64: add ccmp CC mode
On 10/27/2014 12:48 AM, Zhenqiang Chen wrote:
-Original
On 10/10/14 15:48, David Sherwood wrote:
Hi,
I have a fix (originally written by Tejas Belagod) for the following bug:
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59810
Could someone take a look please?
Thanks!
David Sherwood.
ChangeLog:
gcc/:
2014-10-10 David Sherwood
From: Jakub Jelinek [mailto:ja...@redhat.com]
Sent: Wednesday, October 29, 2014 9:41 AM
I think this is ok for trunk with proper ChangeLog entry.
Done with following ChangeLog entry:
2014-10-29 Thomas Preud'homme thomas.preudho...@arm.com
* gcc.dg/optimize-bswapsi-1.c
On 10/29/2014 11:31 AM, Jakub Jelinek wrote:
It would be nice to have libcc1 built just once, not bootstrap it, but
it is a build module, is that possible?
In toplevel configure.ac I'm seeing:
host_tools=texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim
gdb gprof etc
-Original Message-
From: gcc-patches-ow...@gcc.gnu.org [mailto:gcc-patches-
ow...@gcc.gnu.org] On Behalf Of Richard Henderson
Sent: Monday, October 27, 2014 11:47 PM
To: Zhenqiang Chen
Cc: gcc-patches@gcc.gnu.org
Subject: Re: [Ping] [PATCH, 8/10] aarch64: ccmp insn patterns
On
On 10/29/2014 11:28 AM, Jakub Jelinek wrote:
If this passes bootstrap/regtest, is it ok for trunk (should fix
two bootstrap issues)? Is the
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02936.html
patch ok too (that one already tested; another bootstrap issue)?
Both seem okay, though I'd
On Wed, 2014-10-29 02:23:31 +0100, Jan-Benedict Glaw jbg...@lug-owl.de wrote:
On Wed, 2014-10-08 18:50:32 +0100, Joern Rennecke
joern.renne...@embecosm.com wrote:
Attached is the GCC patch for the basic device package infrastructure.
OK to apply?
There's some fallout on config-list.mk
Hi,
As discussed in the thread starting at:
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02359.html
it would be useful to completely remove MOVE_BY_PIECES_P, rather
than leaving it half-dead.
This patch series has a small respin of the patch approved in that
thread, followed by patches for each
Hi,
This is a very minor respin of the patch at:
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg02359.html
dropping the dependency on the refactor in:
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01925.html
The patch is otherwise unmodified from what was approved in
September.
Is this still
On Wed, Oct 29, 2014 at 11:37:26AM +0100, Paolo Bonzini wrote:
On 10/29/2014 11:31 AM, Jakub Jelinek wrote:
shouldn't libcc1 be in build_tools instead?
I mean, it is a library meant to be dlopened by gdb and gcc
plugin that uses that library, so in canadian-cross should be
for the build
Hi,
This patch moves s390 to TARGET_MOVE_BY_PIECES_PROFITABLE_P.
I tried building a compiler and there were no fires, but otherwise,
I have no reasonable way to test this patch. If one of the s390
maintainers wants to pick it up and test it, that would be much
appreciated.
Ok?
James
---
Hi,
This patch moves arc to TARGET_MOVE_BY_PIECES_PROFITABLE_P.
While I am there, arc defines a macro CAN_MOVE_BY_PIECES, which is
unused, so clean that up too.
I tried building a compiler but no amount of fiddling with target
strings got me to a sensible result, so this patch is completely
Hi,
This patch moves sh to TARGET_MOVE_BY_PIECES_PROFITABLE_P.
I tried building a compiler and there were no fires, but otherwise,
I have no reasonable way to test this patch. If one of the sh
maintainers wants to pick it up and test it, that would be much
appreciated.
Thanks,
James
---
gcc/
On 10/29/2014 11:45 AM, Jakub Jelinek wrote:
On Wed, Oct 29, 2014 at 11:37:26AM +0100, Paolo Bonzini wrote:
On 10/29/2014 11:31 AM, Jakub Jelinek wrote:
shouldn't libcc1 be in build_tools instead?
I mean, it is a library meant to be dlopened by gdb and gcc
plugin that uses that library, so
Hi,
This patch moves mips to TARGET_MOVE_BY_PIECES_PROFITABLE_P.
I tried building a compiler and there were no fires, I don't have access
to any MIPS hardware, so if one of the MIPS maintainers wanted to pick
this up and test it, that would be very much appreciated.
OK?
Thanks,
James
---
Hi,
This final patch gets rid of MOVE_BY_PIECES_P.
Bootstrapped on x86_64, ARM and AArch64.
Thanks,
James
---
gcc/
2014-10-28 James Greenhalgh james.greenha...@arm.com
* doc/tm.texi.in (MOVE_BY_PIECES_P): Remove.
* doc/tm.texi: Regenerate.
* system.h: Poison
On Wed, Oct 29, 2014 at 11:37:42AM +0100, Paolo Bonzini wrote:
On 10/29/2014 11:28 AM, Jakub Jelinek wrote:
If this passes bootstrap/regtest, is it ok for trunk (should fix
two bootstrap issues)? Is the
https://gcc.gnu.org/ml/gcc-patches/2014-10/msg02936.html
patch ok too (that one
On 10/29/2014 11:51 AM, Jakub Jelinek wrote:
On Wed, Oct 29, 2014 at 11:37:42AM +0100, Paolo Bonzini wrote:
On 10/29/2014 11:28 AM, Jakub Jelinek wrote:
If this passes bootstrap/regtest, is it ok for trunk (should fix
two bootstrap issues)? Is the
On 29/10/14 10:31, Jakub Jelinek wrote:
It would be nice to have libcc1 built just once, not bootstrap it, but
it is a build module, is that possible?
In toplevel configure.ac I'm seeing:
host_tools=texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim
gdb gprof etc expect
On Wed, Oct 29, 2014 at 11:53:28AM +0100, Paolo Bonzini wrote:
2) why is GMPLIB not handled in the same way?
The only problem is that system.h includes gmp.h, so we need a way
to find that header. I think libcc1 doesn't use any functions from gmp
itself, so if gmp.h can be included,
On 29/10/14 10:53, Paolo Bonzini wrote:
2) why is GMPLIB not handled in the same way?
The only problem is that system.h includes gmp.h, so we need a way
to find that header. I think libcc1 doesn't use any functions from gmp
itself, so if gmp.h can be included, GMPLIB isn't really needed.
On 10/29/2014 11:58 AM, Phil Muldoon wrote:
My archaeology into the source repository has not revealed why
we needed bootstrap. Perhaps we included it out of a sense of
paranoia for testing. I've CC'd Tom on this, so he may have an
opinion or insight. From my point of view, I see no value
On 29/10/14 10:53, Paolo Bonzini wrote:
On 10/29/2014 11:51 AM, Jakub Jelinek wrote:
On Wed, Oct 29, 2014 at 11:37:42AM +0100, Paolo Bonzini wrote:
On 10/29/2014 11:28 AM, Jakub Jelinek wrote:
If this passes bootstrap/regtest, is it ok for trunk (should fix
two bootstrap issues)? Is the
On 29/10/14 10:31, Jakub Jelinek wrote:
It would be nice to have libcc1 built just once, not bootstrap it, but
it is a build module, is that possible?
In toplevel configure.ac I'm seeing:
host_tools=texinfo flex bison binutils gas ld fixincludes gcc cgen sid sim
gdb gprof etc expect
Hi James,
I think you have a bug in the following hunk where you pass
STORE_MAX_PIECES in place of the optimise for speed flag. I guess you
would need an extra argument to pass a different *_MAX_PIECES value
in.
thanks,
Matthew
@@ -192,8 +184,7 @@ static void write_complex_part (rtx, rtx,
On Wed, Oct 29, 2014 at 11:24 AM, Marek Polacek pola...@redhat.com wrote:
PR52769 reports a bug that has been fixed in 4.7, but the test case
was never added. So I'd like to put this test in and close PR52769.
Ok?
Ok everywhere.
Thanks,
Richard.
2014-10-29 Marek Polacek
The test passes now. So let's remove xfail.
2014-10-29 Evgeny Stupachenko evstu...@gmail.com
gcc/testsuite
* gcc.target/i386/pr23098.c: Remove xfail.
diff --git a/gcc/testsuite/gcc.target/i386/pr23098.c
b/gcc/testsuite/gcc.target/i386/pr23098.c
index 7f118dc..7f118bb 100644
---
On Fri, 24 Oct 2014, David Edelsohn wrote:
genmatch is hanging when bootstrapping on AIX (gcc111). When I attach
to the process:
#0 0x1007efac in std::basic_stringchar, std::char_traitschar,
std::allocatorchar ::basic_string ()
#1 0x1000e6b0 in _ZN6parser13parse_captureEP7operand
Hi Renlin,
Are the incoming edge counts or probabilities insane in this case? I
guess the patch is ok if we need to do this to handle those incoming
insanitiles. But I can't approve patches myself.
However, this is a fix to code (r215739) committed after the ICE in
the original bug report and in
Continuing the cleanups of libgcc soft-fp configuration for
powerpc*-*-linux* in preparation for implementing
TARGET_ATOMIC_ASSIGN_EXPAND_FENV for soft-float and e500, this patch
optimizes the choice of which functions to build for the e500 cases.
For e500v2, use of hardfp is generally right,
On Wed, Oct 29, 2014 at 8:54 AM, Joseph S. Myers
jos...@codesourcery.com wrote:
Continuing the cleanups of libgcc soft-fp configuration for
powerpc*-*-linux* in preparation for implementing
TARGET_ATOMIC_ASSIGN_EXPAND_FENV for soft-float and e500, this patch
optimizes the choice of which
This patch adds the TARGET_SCHED_REASSOCIATION_WIDTH hook. Separate settings
for integer, floating
point and vector modes are supported via the CPU tuning parameters. Setting the
FP reassociation
width to 4 improves FP performance on SPEC2000 by ~1.3%.
OK for commit?
ChangeLog:
2014-10-29
genmatch segfaults if user-defined operator is not specified.
eg:
(for (oper1 oper2...)
pattern)
* genmatch.c
(parser::parse_for): Call peek instead of peek_ident.
Thanks,
Prathamesh
Index: genmatch.c
===
--- genmatch.c
On Wed, Oct 29, 2014 at 8:26 AM, Richard Biener rguent...@suse.de wrote:
On Fri, 24 Oct 2014, David Edelsohn wrote:
genmatch is hanging when bootstrapping on AIX (gcc111). When I attach
to the process:
#0 0x1007efac in std::basic_stringchar, std::char_traitschar,
std::allocatorchar
This patch adjusts the spill cost of literal pool loads to reduce the chance of
them being
caller-saved (which is inefficient). Such loads should be rematerialized and
thus should not include
the cost of a spill store. This was done only on constants for which
legitimate_constant_p is true,
Hi,
Following discussions after Thomas's patches improving bswap support
https://gcc.gnu.org/ml/gcc-patches/2014-09/msg01279.html
I noticed that:
* the associated tests weren't executed on aarch64_be
* ARM targets older than v6 do not support the needed instructions.
The attached patch changes
On Wed, Oct 29, 2014 at 2:10 PM, David Edelsohn dje@gmail.com wrote:
On Wed, Oct 29, 2014 at 8:26 AM, Richard Biener rguent...@suse.de wrote:
On Fri, 24 Oct 2014, David Edelsohn wrote:
genmatch is hanging when bootstrapping on AIX (gcc111). When I attach
to the process:
#0 0x1007efac
From: Richard Biener [mailto:richard.guent...@gmail.com]
Sent: Wednesday, October 08, 2014 8:27 AM
I wouldn't worry about that too much. Indeed the question would be
what
should be canonical on GIMPLE (expanders should choose the optimal
vairant from both). I think a tree code should be
On Wed, Oct 29, 2014 at 2:01 PM, Prathamesh Kulkarni
bilbotheelffri...@gmail.com wrote:
genmatch segfaults if user-defined operator is not specified.
eg:
(for (oper1 oper2...)
pattern)
* genmatch.c
(parser::parse_for): Call peek instead of peek_ident.
Thanks - applied.
Richard.
Hello,
This is new patch version in which reported issue is fixed.
Also, patch is rebased to the revision 216452 and some minor code clean-up is
done.
--
Lowering is applied
On 29 Oct 10:34, Richard Biener wrote:
On Tue, Oct 28, 2014 at 5:14 PM, Ilya Enkovich enkovich@gmail.com wrote:
Hi,
This patch fixes PR63664 and PR63574. Problem is in NULL types for labels
not handled by ICF properly. I assume it is OK for labels to have NULL
type and added
On 10/29/2014 02:45 PM, Ilya Enkovich wrote:
On 29 Oct 10:34, Richard Biener wrote:
On Tue, Oct 28, 2014 at 5:14 PM, Ilya Enkovich enkovich@gmail.com wrote:
Hi,
This patch fixes PR63664 and PR63574. Problem is in NULL types for labels not
handled by ICF properly. I assume it is OK for
gcc/ChangeLog.gimple-classes:
* gimple.h (gimple_try_kind): Strengthen param from const_gimple
to const gtry *.
(gimple_try_catch_is_cleanup): Likewise.
(gimple_try_eval_ptr): Strengthen param from gimple gtry *.
(gimple_try_eval): Likewise.
I've pushed the following three patches to the git branch
dmalcolm/gimple-classes.
Successfully bootstrappedregrtested the combination of the three
patches on x86_64-unknown-linux-gnu (Fedora 20) - same results
relative to an unpatched control bootstrap of trunk's r216746.
David Malcolm (3):
gcc/ChangeLog.gimple-classes:
* doc/gimple.texi (Class hierarchy of GIMPLE statements): Update
for renaming of gimple_statement_wce to gwce.
* gimple-walk.c (walk_gimple_stmt): Add checked cast to gwce *
within case GIMPLE_WITH_CLEANUP_EXPR.
* gimple.c
2014-10-29 17:01 GMT+03:00 Martin Liška mli...@suse.cz:
On 10/29/2014 02:45 PM, Ilya Enkovich wrote:
On 29 Oct 10:34, Richard Biener wrote:
On Tue, Oct 28, 2014 at 5:14 PM, Ilya Enkovich enkovich@gmail.com
wrote:
Hi,
This patch fixes PR63664 and PR63574. Problem is in NULL types for
Hello.
Following patch fixes PR63587, where we put DECL_RESULT in
cgraph_node::expand_thunk to local_decls.
Patch has been tested on x86_64-linux-pc without any regression and boostrap
works correctly.
Ready for thunk?
Thanks,
Martin
gcc/testsuite/ChangeLog:
2014-10-29 Martin Liska
On 10/29/14 02:47, Thomas Preud'homme wrote:
It seems more sensible to keep it in this block as the existing
defaulted_int block is for types for which it is not an error to omit the
int type specifier.
It's not an error to omit it for complex - but of course means something
different. IMHO
This merges a set of conversion patterns and removes the corresponding
code from both fold-const.c and tree-ssa-forwprop.c.
fold-const.c| 36
match.pd| 42 +
tree-ssa-forwprop.c | 65
On 29/10/14 11:24, Phil Muldoon wrote:
On 29/10/14 10:31, Jakub Jelinek wrote:
It would be nice to have libcc1 built just once, not bootstrap it, but
it is a build module, is that possible?
In toplevel configure.ac I'm seeing:
host_tools=texinfo flex bison binutils gas ld fixincludes gcc
On 10/29/2014 03:37 AM, Zhenqiang Chen wrote:
It's my fault. %m/%M work well in the new patch.
And I add a check
aarch64_ccmp_mode_to_code (GET_MODE (operands[1])) == GET_CODE (operands[5])
on the patterns to make sure that the compare and CC mode are aligned.
Looks good.
r~
On 29/10/14 14:26, Phil Muldoon wrote:
On 29/10/14 11:24, Phil Muldoon wrote:
On 29/10/14 10:31, Jakub Jelinek wrote:
It would be nice to have libcc1 built just once, not bootstrap it, but
it is a build module, is that possible?
In toplevel configure.ac I'm seeing:
host_tools=texinfo flex
From: Nathan Sidwell [mailto:nathanmsidw...@gmail.com] On Behalf Of
Nathan Sidwell
It's not an error to omit it for complex - but of course means something
different. IMHO it would be confusing to set type to integer_type_node
when
that's definitely wrong. But then setting
On 10/29/14 07:32, Thomas Preud'homme wrote:
From: Nathan Sidwell [mailto:nathanmsidw...@gmail.com] On Behalf Of
Oh in that case the patch is incomplete. Currently a complex alone gives
an error at compilation which is why I added -fpermissive to the testcase.
The patch don't change this
On 10/29/2014 03:31 AM, Zhenqiang Chen wrote:
Patch is updated.
Looks good.
r~
On Wed, Oct 01, 2014 at 05:38:12PM +0100, James Greenhalgh wrote:
On Fri, Sep 26, 2014 at 10:11:13AM +0100, Richard Biener wrote:
On Thu, Sep 25, 2014 at 4:57 PM, James Greenhalgh
james.greenha...@arm.com wrote:
Given the special value to note the default for the new --params is
zero a
On Wed, Oct 29, 2014 at 3:14 PM, Martin Liška mli...@suse.cz wrote:
Hello.
Following patch fixes PR63587, where we put DECL_RESULT in
cgraph_node::expand_thunk to local_decls.
Patch has been tested on x86_64-linux-pc without any regression and boostrap
works correctly.
Ready for thunk?
Hi all,
This patch is an attempt to fix bug PR ipa/63576, corrected according
to note made by Jiong Wang:
On 27.10.2014 18:41, Jiong Wang wrote:
how about using early exit for above code, something like:
if (!e-speculative
|| profile_status_for_fn (DECL_STRUCT_FUNCTION (dst-decl))
On 10/29/2014 03:27 AM, Zhenqiang Chen wrote:
ChangeLog:
2014-10-29 Zhenqiang Chen zhenqiang.c...@arm.com
* ifcvt.c (noce_emit_cmove, noce_get_alt_condition,
noce_get_condition):
Allow CC mode if HAVE_cbranchcc4.
Ok.
r~
On 10/29/2014 11:59 AM, Jakub Jelinek wrote:
Ah, got it. Is it hard to move the inclusion to the actual users?
I think it is hard. I think it has been moved to system.h very much
intentionally, as including gmp.h only in selected headers was causing lots
of troubles, e.g. because of #pragma
gcc/ChangeLog.gimple-classes:
* gimple.h (gimple_goto_dest): Strengthen param from const_gimple to
const ggoto *.
* cfgexpand.c (expand_gimple_stmt_1): Add checked cast to ggoto *
within case GIMPLE_GOTO.
* gimple-walk.c (walk_stmt_load_store_addr_ops): Add
On 10/29/2014 03:28 AM, Zhenqiang Chen wrote:
Thanks! Patch is updated.
Ok.
r~
On Wed, Oct 29, 2014 at 12:01 AM, Dominik Vogt v...@linux.vnet.ibm.com wrote:
Patch updated to remove conflicts with changed tests in patch 7.
Thanks. Approved and committed.
Ian
On 10/29/2014 03:29 AM, Zhenqiang Chen wrote:
Thanks! Patch is updated.
Ok.
r~
On Tue, 28 Oct 2014 11:16:19 +
Julian Brown jul...@codesourcery.com wrote:
Hi,
This patch rationalises TLS support by moving all thread-local
variables into a single structure. Because this meant interfering with
how per-thread/per-device initialisation was done, I took the
opportunity
Hi,
In PR61153, the vbic and vorn tests fail because when compiled at -O0
the expected Neon instructions are not generated, making
scan-assembler fail.
This patch:
- replaces -O0 by -O2
- moves the declaration of local variables used as intrinsics
parameters and results to global declarations,
On Wed, Oct 29, 2014 at 3:26 PM, Christophe Lyon
christophe.l...@linaro.org wrote:
Hi,
In PR61153, the vbic and vorn tests fail because when compiled at -O0
the expected Neon instructions are not generated, making
scan-assembler fail.
This patch:
- replaces -O0 by -O2
- moves the
On Wed, Oct 29, 2014 at 11:42:06AM +, Matthew Fortune wrote:
Hi James,
I think you have a bug in the following hunk where you pass
STORE_MAX_PIECES in place of the optimise for speed flag. I guess you
would need an extra argument to pass a different *_MAX_PIECES value
in.
Yup, good
On 10/27/14 9:42, Chen Gang wrote:
On 10/27/14 2:22, Michael Eager wrote:
Microblaze-sim provides basic instruction set architecture and memory
simulation.
There is no operating system support. (It's also quite old. I'm not sure
which version of the MB architecture it models, but it is
The question remains, are the decls all you need from the traversal (i.e.
what you need to act upon)? From my earlier skim of the original code that
wasn't that obvious.
You can have in decl_map at least also BLOCKs, perhaps types too, what
else?
Jakub,
Seems the BLOCKs are the only
1 - 100 of 166 matches
Mail list logo
