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
> 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: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
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
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
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
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: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
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
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
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)
>
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 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
>
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 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 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 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:
>>> 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 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: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 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 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 (
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 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 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/
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 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-
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 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
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
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
> -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 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
> 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/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
> -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:
> >
> >> --
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
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
> -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:
> -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
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,
> >
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
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
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
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
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
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 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
> 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
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
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
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 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.
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 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
> 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
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
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/
>
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
==
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
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
> 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
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
101 - 168 of 168 matches
Mail list logo
