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
Date: Fri, 5 Sep 2014 07:31:01 +0100
Subject: [PATCH 8/9] Gccgo port to s390[x] -- part
> 2014-10-28 Richard Biener
>
> 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 with the patc
I will commit the following change in MAINTAINERS.
Tristan.
2014-10-29 Tristan Gingold
* MAINTAINERS: Change my email address.
--- MAINTAINERS (revision 216822)
+++ MAINTAINERS (working copy)
@@ -136,7 +136,7 @@
RTEMS PortsJoel Sherrill
RTEMS Ports
Patch with the fixes:
Bootstrap, gcc make check and spec2000 with "-p" passed.
2014-10-29 Evgeny Stupachenko
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 SET_GOT to
Bootstrapped and tested on x86_64-unknown-linux-gnu, applied.
Richard.
2014-10-29 Richard Biener
* tree-ssa-sccvn.c (try_to_simplify): Allow
gimple_fold_stmt_to_constant_1 to follow SSA use-def chains.
(visit_use): Likewise.
Index: gcc/tree-ssa-sccvn.c
==
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
>
> 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,
Th
On Tue, Oct 28, 2014 at 5:14 PM, Ilya Enkovich 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 generation.
>
> Bootstrappe
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'; Ric
On Wed, Oct 29, 2014 at 4:31 AM, Andi Kleen wrote:
> From: Andi Kleen
>
> 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 memory barriers for these intrinsics.
off-by-one error.
>
> 2014-10-29 DJ Delorie
>
> * gcc.dg/20141029-1.c: New.
>
>
> Index: expmed.c
> ===
> --- expmed.c(revision 216811)
> +++ expmed.c(working copy)
> @@ -45
On Wed, Oct 29, 2014 at 10:04 AM, Eric Botcazou wrote:
>> 2014-10-28 Richard Biener
>>
>> 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
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
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
> integer modes (say) will
> 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.
I
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 i
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
* config/aarch64/aarch64.c (aarch64_madd_needs_nop): Restore
recog state after aarch64_pr
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 the
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
PR c/52769
* gcc.dg/pr52769.c: New test.
diff --git gcc/testsuite/gcc.dg/pr52769.c gcc/testsuite/gcc.dg/pr5276
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
* ifcvt.c (noce_emit_cmove, noce_get_alt_conditio
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,
> >
> -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 wro
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 c
> -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:
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.o
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"
s
> -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:
> >
> >> --
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
* gcc.dg/optimize-bswapsi-1.c (swap32_e): New bswap test.
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 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'
On Wed, 2014-10-29 02:23:31 +0100, Jan-Benedict Glaw wrote:
> On Wed, 2014-10-08 18:50:32 +0100, Joern Rennecke
> wrote:
> > Attached is the GCC patch for the basic device package infrastructure.
> > OK to apply?
>
> There's some fallout on config-list.mk builds:
>
> g++ -c -g -O2 -DIN_GCC
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 OK
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
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
---
2014-
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
unt
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 l
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
---
gcc/
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
* doc/tm.texi.in (MOVE_BY_PIECES_P): Remove.
* doc/tm.texi: Regenerate.
* system.h: Poison MOVE_BY_PIECES_P.
* tar
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 (
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
>>> https://gcc.gnu.org/ml/gc
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 d
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 in
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 n
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 valu
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 bootst
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 d
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, bool)
On Wed, Oct 29, 2014 at 11:24 AM, Marek Polacek 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
>
> PR c/52769
>
The test passes now. So let's remove xfail.
2014-10-29 Evgeny Stupachenko
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
--- a/gcc/testsuite/gcc.targe
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_string,
> std::allocator >::basic_string ()
> #1 0x1000e6b0 in _ZN6parser13parse_captureEP7operand (this=0x300594b8,
> op=0x0)
>
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, exce
On Wed, Oct 29, 2014 at 8:54 AM, Joseph S. Myers
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 functions to build for th
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 Wilc
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 (revisio
On Wed, Oct 29, 2014 at 8:26 AM, Richard Biener 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_string,
>> std::allocator >::basic_string ()
>> #1 0x1000e6b0 in _Z
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,
howe
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 c
On Wed, Oct 29, 2014 at 2:10 PM, David Edelsohn wrote:
> On Wed, Oct 29, 2014 at 8:26 AM, Richard Biener 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_stri
> 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 shou
On Wed, Oct 29, 2014 at 2:01 PM, Prathamesh Kulkarni
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.
> Thanks,
> Prathamesh
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
On 29 Oct 10:34, Richard Biener wrote:
> On Tue, Oct 28, 2014 at 5:14 PM, Ilya Enkovich 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
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 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 typ
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.
(gimple_t
I've pushed the following three patches to the git branch
"dmalcolm/gimple-classes".
Successfully bootstrapped®rtested 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):
St
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 (gimpl
2014-10-29 17:01 GMT+03:00 Martin Liška :
> 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
>>> wrote:
Hi,
This patch fixes PR63664 and PR63574. Problem is in NULL types for
l
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 fixinclude
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="
> 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 'default
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 behav
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
> > wrote:
> > Given the special value to note the default for the new --params is
> > zero a user cannot disabl
On Wed, Oct 29, 2014 at 3:14 PM, Martin Liška 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?
Ok.
Than
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
>
> * 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 #p
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 c
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 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 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 to tidy up a coup
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, to
On Wed, Oct 29, 2014 at 3:26 PM, Christophe Lyon
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 declaration of local varia
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, goo
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, bu
>
>
> 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 o
On 22 Oct 23:21, Ilya Verbin wrote:
> On 22 Oct 10:54, Jakub Jelinek wrote:
> > On Tue, Oct 21, 2014 at 09:20:34PM +0400, Ilya Verbin wrote:
> > > This patch contains liboffloadmic library.
> > >
> > > It is used by ICC for offloading. The sources are imported from upstream
> > > ( https://www.op
1 - 100 of 168 matches
Mail list logo
