2014-10-28 15:47 GMT+03:00 Georg-Johann Lay :
> Am 10/28/2014 01:34 PM, schrieb Georg-Johann Lay:
>>
>> Middle-end might come up with hard registers as operands for expanders
>> which
>> clobber respective hard regs. This patch uses freshly created pseudos for
>> respective expander operands and e
2014-10-29 13:42 GMT+03:00 Jan-Benedict Glaw :
>
> 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
>
> Hmm, can't the insns themselves properly clobber/use memory?
The transactions don't really use the memory. They just guard it,
like a lock.
So the intrinsic doesn't know what memory is used inside the transaction,
but the accesses still cannot be moved out.
I think a barrier is the only sen
On 10/15/14 11:54, Ilya Enkovich wrote:
Thanks for review! I see no more patches not reviewed at all. I see
4 more patches requiring approve before I can start a merge.
Two of them are parts of split #14 (Passes): #14.3 (Helper functions)
and #14.16 (Reduce bounds lifetime)
These are fine. W
On 10/26/14 19:53, Zhenqiang Chen wrote:
Hi,
Function noce_try_store_flag_mask converts "if (test) x = 0;" to "x &=
-(test == 0);"
But from code size view, "x &= -(test == 0);" might have more instructions
than "if (test) x = 0;". The patch checks the cost to determine the
conversion is valuabl
On 10/29/14 04:28, Jakub Jelinek wrote:
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
For the first time in over a decade, I'm going to poke a bit at the PA
port. Basically I want to use Bin's work to do insn fusion to generate
fmpyadd and fmpysub instructions on the PA -- doing so ought to answer
most of my questions about the implementation.
Ultimately that'll be throw-aw
On 10/27/14 14:47, Jakub Jelinek wrote:
Hi!
The following testcase is miscompiled in 4.8+ on x86_64 at -O2+,
because REE widens for ZERO_EXTEND mode on
(set (reg:QI ax) (const_int -1)) instruction to SImode, but doesn't
adjust REG_EQUAL note of (const_int -1) also to (const_int 0xff)
like it cha
On 10/28/14 06:23, Jakub Jelinek wrote:
On Tue, Oct 28, 2014 at 11:47:31AM +, Phil Muldoon wrote:
I think I have a solution. Though my automake fu is very weak. Does
this patch work for you? I'm really not sure how to deal with the
three possible versions of libiberty any other way.
Tha
On 09/11/14 07:24, Bernd Schmidt wrote:
The nvptx backend is somewhat unusual in that call insns set a pseudo.
The combiner is surprised by this and allows combining them into other
insns, which remain as INSN rather than CALL_INSN. Aborts ensue.
Bootstrapped and tested on x86_64-linux, together
On 10/29/14 17:48, Bernd Schmidt wrote:
On 09/11/2014 05:58 PM, Steven Bosscher wrote:
On Thu, Sep 11, 2014 at 3:27 PM, Bernd Schmidt wrote:
It turns out that we're calling eliminate_regs for global variables
which
can't possibly have eliminable regs in their decl. At that point,
reg_eliminate
On 10/29/14 17:55, Bernd Schmidt wrote:
Thanks! I've pinged some of the preliminary patches that went unapproved
up to this point.
Thanks.
One leftover issue, discussed in the [0/11] mail - what amount of
documentation is appropriate for this, given that we don't want to
support using this a
On Tue, 2014-10-21 at 15:24 -0400, David Malcolm wrote:
> On Tue, 2014-10-21 at 18:15 +0200, Gerald Pfeifer wrote:
> > On Monday 2014-10-20 15:19, David Malcolm wrote:
> > > +@item Sphinx (any working version)
> >
> > As opposed to "any non-working version"? ;-) I'd just omit
> > "working" from
On 10/30/2014 12:35 AM, Jeff Law wrote:
A "nit" -- Richard S. recently removed the need to include the "enum"
for "enum machine_mode". I believe he had a script to handle the
mundane parts of that change. Please make sure to update the nvptx port
to conform to that new convention, obviously fee
James Greenhalgh wrote:
> 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
> apprecia
On 09/11/2014 05:58 PM, Steven Bosscher wrote:
On Thu, Sep 11, 2014 at 3:27 PM, Bernd Schmidt wrote:
It turns out that we're calling eliminate_regs for global variables which
can't possibly have eliminable regs in their decl. At that point,
reg_eliminate can be NULL. This patch avoids unnecessar
On 09/11/2014 03:24 PM, Bernd Schmidt wrote:
The nvptx backend is somewhat unusual in that call insns set a pseudo.
The combiner is surprised by this and allows combining them into other
insns, which remain as INSN rather than CALL_INSN. Aborts ensue.
Bootstrapped and tested on x86_64-linux, tog
On Wed, Oct 29, 2014 at 5:50 PM, Joseph S. Myers
wrote:
> On Wed, 29 Oct 2014, Kyrill Tkachov wrote:
>
>> Hi all,
>>
>> This fixes an arm build failure due to removing the 'enum' keyword from
>> machine_mode.
>> Since libgcc2 is compiled with C rather than C++ we need it there for the
>> definitio
On 10/28/14 08:56, Bernd Schmidt wrote:
I have patches that expose all the address spaces to the middle-end
through a lower-as pass that runs early. The preliminary patches for
that ran into some resistance and into general brokenness of our address
space support, so I decided to rip all that ou
On 10/28/14 08:49, Bernd Schmidt wrote:
On 10/22/2014 08:12 PM, Jeff Law wrote:
Yea, let's keep your approach. Just wanted to explore a bit since the
PA seems to have a variety of similar characteristics.
Here's an updated version of the patch. I experimented a little with ptx
calling convent
On 10/28/14 10:38, Ilya Enkovich wrote:
Hi,
After recent merge with trunk I found that new IPA pass ICF requires few
modifications for instrumented code:
- instrumentation thunk existence means we cannot merge function into another
one and should generate thunk instead
- thunk generation s
On 10/29/14 04:49, James Greenhalgh wrote:
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
On 10/29/14 04:50, James Greenhalgh wrote:
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.
* sys
On 10/29/14 04:50, James Greenhalgh wrote:
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 mu
On 10/29/14 04:48, James Greenhalgh wrote:
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 sen
On 10/29/14 04:46, James Greenhalgh wrote:
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 woul
On 10/29/14 07:21, Wilco Dijkstra wrote:
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
On 10/29/14 10:28, Martin Liška wrote:
PR63574.changelog
gcc/testsuite/ChangeLog:
2014-10-29 Martin Liska
* g++.dg/ipa/pr63574.C: New test.
gcc/ChangeLog:
2014-10-29 Martin Liska
* ipa-icf-gimple.c (func_checker::compare_variable_decl):
(func_checker::parse_lab
On 10/29/14 08:32, Phil Muldoon wrote:
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
On Wed, Oct 29, 2014 at 11:45:51AM +0100, 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
> > >
On Wed, Oct 29, 2014 at 07:57:46PM +, Marcus Shawcroft wrote:
> On 29 October 2014 10:05, Kyrill Tkachov wrote:
> > 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 d
On 29 October 2014 10:05, Kyrill Tkachov wrote:
> 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?
OK once the 4.9 fix is committed. /Marcus
On 29 October 2014 10:05, Kyrill Tkachov wrote:
> 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
> -Original Message-
> From: Matthew Fortune [mailto:matthew.fort...@imgtec.com]
> Sent: Tuesday, October 28, 2014 1:13 PM
> To: Moore, Catherine; 'gcc-patches@gcc.gnu.org' (gcc-
> patc...@gcc.gnu.org); Eric Christopher (echri...@gmail.com)
> Cc: Richard Sandiford; Rich Fuhler; Rozycki, M
On 29 October 2014 10:03, Kyrill Tkachov wrote:
> 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
On Wed, Oct 29, 2014 at 1:28 PM, Evgeny Stupachenko wrote:
> The test passes now. So let's remove xfail.
>
> 2014-10-29 Evgeny Stupachenko
>
> gcc/testsuite
> * gcc.target/i386/pr23098.c: Remove xfail.
OK.
Thanks,
Uros.
Hi!
On Tue, 28 Oct 2014 17:00:38 +0100, I wrote:
> Committed in r216804:
>
> commit 4f9566b3e2954218c0d9ce3c585e14e539f0c1af
> Author: tschwinge
> Date: Tue Oct 28 15:57:48 2014 +
>
> libgomp: Don't refer to CUDA installation in /opt/nvidia/cuda-5.5/.
>
> libgomp/
> *
gcc/ChangeLog.gimple-classes:
* gimple.h (gimple_omp_parallel_combined_p): Strengthen param from
const_gimple to const gomp_parallel *.
(gimple_omp_parallel_clauses): Likewise.
(gimple_omp_parallel_set_combined_p): Strengthen param from gimple
to gomp_paralle
gcc/ChangeLog.gimple-classes:
* coretypes.h (struct gpredict): Add forward declaration.
* doc/gimple.texi (Class hierarchy of GIMPLE statements): Add
gpredict.
* gimple-pretty-print.c (pp_gimple_stmt_1): Within case
GIMPLE_PREDICT, add local "predict_stmt" vi
Ping?
On Mon, Oct 20, 2014 at 10:31 AM, Cary Coutant wrote:
> This patch adds support for the mips target in gold.
>
> OK to commit?
>
> -cary
>
>
> 2014-10-20 Cary Coutant
>
> * configure (--enable-gold): Add mips*-*-*.
> * configure.ac: Regenerate.
>
>
> Index: configure
> ==
gcc/ChangeLog.gimple-classes:
* gimple.h (struct gimple_statement_omp_return): Rename to...
(struct gomp_return): ...this.
(is_a_helper ::test): Rename to...
(is_a_helper ::test): ...this.
(is_a_helper ::test): Rename to...
(is_a_helper ::test): ...th
gcc/ChangeLog.gimple-classes:
* gimple.h (gimple_omp_single_clauses): Strengthen param from
const_gimple to const gomp_single *.
(gimple_omp_single_clauses_ptr): Strengthen param from gimple to
gomp_single *.
* gimple-walk.c (walk_gimple_op): Add checked cas
gcc/ChangeLog.gimple-classes:
* gimple.h (gimple_omp_sections_clauses): Strengthen param from
const_gimple to const gomp_sections *.
(gimple_omp_sections_control): Likewise.
(gimple_omp_sections_clauses_ptr): Strengthen param from gimple to
gomp_sections *.
gcc/ChangeLog.gimple-classes:
* gimple.h (gimple_omp_for_kind): Strengthen param from
const_gimple to const gomp_for *.
(gimple_omp_for_combined_p): Likewise.
(gimple_omp_for_combined_into_p): Likewise.
(gimple_omp_for_clauses): Likewise.
(gimple_omp_
gcc/ChangeLog.gimple-classes:
* gimple.h (gimple_omp_target_clauses): Strengthen param from
const_gimple to const gomp_target *.
(gimple_omp_target_kind): Likewise.
(gimple_omp_target_clauses_ptr): Strengthen param from gimple to
gomp_target *.
* gim
gcc/ChangeLog.gimple-classes:
* gimple.h (gimple_eh_filter_types): Strengthen param from
const_gimple to const geh_filter *.
(gimple_eh_filter_types_ptr): Strengthen param from gimple to
geh_filter *.
(gimple_eh_filter_failure_ptr): Likewise.
(gimple_
gcc/ChangeLog.gimple-classes:
* gimple.h (gimple_omp_task_clauses): Strengthen param from
const_gimple to const gomp_task *.
(gimple_omp_task_child_fn): Likewise.
(gimple_omp_task_data_arg): Likewise.
(gimple_omp_task_copy_fn): Likewise.
(gimple_omp_t
I've pushed the following ten patches to the git branch
"dmalcolm/gimple-classes".
Successfully bootstrapped®rtested the combination of the ten
patches upon the branch on x86_64-unknown-linux-gnu (Fedora 20) -
same results relative to an unpatched control bootstrap of trunk's
r216746.
David Malco
gcc/ChangeLog.gimple-classes:
* gimple.h (gimple_omp_teams_clauses): Strengthen param from
const_gimple to const gomp_teams *.
(gimple_omp_teams_clauses_ptr): Strengthen param from gimple to
gomp_teams *.
* gimple-walk.c (walk_gimple_op): Add checked cast.
As pointed out in http://stackoverflow.com/q/26543242/981959 our
std::function does more copying/moving than necessary. The solution is
to use perfect forwarding for the internal invoker functions, even if
functioncommit 9c733bb92dd60c416731c049ee58ae56c7e0117f
Author: Jonathan Wakely
Date: Wed
The first patch adds the following from Library Fundamentals v1:
std::experimental::sample
std::experimental::search
std::experimental::default_searcher
std::experimental::make_default_searcher
std::experimental::boyer_moore_searcher
std::experimental::make_boyer_moore_searcher
std::experi
On Wed, 29 Oct 2014, Kyrill Tkachov wrote:
> Hi all,
>
> This fixes an arm build failure due to removing the 'enum' keyword from
> machine_mode.
> Since libgcc2 is compiled with C rather than C++ we need it there for the
> definition of CUMULATIVE_ARGS.
But why is CUMULATIVE_ARGS needed for libg
Hi Julian!
On Tue, 28 Oct 2014 11:16:19 +, Julian Brown
wrote:
> 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
Thanks. Part of the problem is that the m68k max alignment is 16
bits, but the godump test expects it to be at least 64 bits. This is
BIGGEST_ALIGNMENT in config/m68k/m68k.h. Another part of the problem
seems to be that structs are sometimes aligned to 16 bits although
there is no obvious reason
On Wed, Oct 29, 2014 at 9:24 AM, Richard Biener
wrote:
> Because only genmatch calls functions from libstdc++. Btw, why
> would genmatch miscompile an empty function or the call to it?
I tried bootstrapping with libstdc++ built without the AIX ld "-G"
flag and that is succeeding.
"-G" produces
On Sat, 25 Oct 2014, Marek Polacek wrote:
> + pp_c_ws_string (cpp, "aka");
That should be _("aka"), as it's an English word, not a C syntax
construct.
OK with that change.
--
Joseph S. Myers
jos...@codesourcery.com
On Wed, Oct 29, 2014 at 4:31 PM, Kyrill Tkachov wrote:
> Hi all,
>
> This fixes an arm build failure due to removing the 'enum' keyword from
> machine_mode.
> Since libgcc2 is compiled with C rather than C++ we need it there for the
> definition of CUMULATIVE_ARGS.
>
> Another place where machine_
On 29/10/14 16:34, Kyrill Tkachov wrote:
Hi all,
This is similar to the arm patch
(https://gcc.gnu.org/ml/gcc-patches/2014-10/msg03104.html),
it adds back the enum keyword to machine_mode in the definition of MACHMODE.
This allows the aarch64* build to succeed.
Ok for trunk?
I've committed
_VERSION__ = "5.0.0 20141029 (experimental)"
const ___linux__ = 1
const ___SCHAR_MAX__ = 0x7f
const ___GLIBC_MINOR__ = 18
const ___ATOMIC_ACQ_REL = 4
const ___DEC64_MAX__ = 9.999E384
const _INT_FAST16_MIN = (-2147483647-1)
const __SVID_SOURCE = 1
const ___WORDSIZE = 32
On Tue, 28 Oct 2014, Martin Uecker wrote:
> attached is a revised and extended patch. Changes with respect
> to the previous patch are:
Thanks for the revised patch. I've moved this to gcc-patches as the more
appropriate mailing list for discussion of specific patches as opposed to
more gener
On 10/29/2014 05:47 AM, Thomas Preud'homme wrote:
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
On Wed, Oct 29, 2014 at 9:38 AM, Andreas Schwab wrote:
> I'm getting these test failures on m68k-linux:
Can you send the file BUILDDIR/gcc/testsuite/gcc/godump-1.out?
Ian
I'm getting these test failures on m68k-linux:
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_anon_pad1 struct { c
uint[0-9]*; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_anon_pad5 struct { c
uint[0-9]*; }$
FAIL: gcc.misc-tests/godump-1.c scan-file (?n)^type _tsbf_pad
On 29 October 2014 17:31, Kyrill Tkachov wrote:
> Hi all,
>
> This fixes an arm build failure due to removing the 'enum' keyword from
> machine_mode.
> Since libgcc2 is compiled with C rather than C++ we need it there for the
> definition of CUMULATIVE_ARGS.
>
> Another place where machine_mode is
Hi all,
This is similar to the arm patch
(https://gcc.gnu.org/ml/gcc-patches/2014-10/msg03104.html),
it adds back the enum keyword to machine_mode in the definition of MACHMODE.
This allows the aarch64* build to succeed.
Ok for trunk?
Thanks,
Kyrill
2014-10-28 Kyrylo Tkachov
* confi
> Ok. For the branch please wait until after 4.9.2 is out.
Thanks! Committed to trunk.
Hi all,
This fixes an arm build failure due to removing the 'enum' keyword from
machine_mode.
Since libgcc2 is compiled with C rather than C++ we need it there for
the definition of CUMULATIVE_ARGS.
Another place where machine_mode is used is machine_function which is
not needed for libgcc2
On 10/29/2014 03:07 PM, Ilya Enkovich wrote:
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 t
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
>
>
> 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 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
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 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
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 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
On 10/29/2014 03:29 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:28 AM, Zhenqiang Chen wrote:
> Thanks! Patch is updated.
Ok.
r~
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 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
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~
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 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
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 10/29/2014 03:31 AM, Zhenqiang Chen wrote:
> Patch is updated.
Looks good.
r~
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
> 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 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="
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 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
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 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
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
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
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
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
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
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
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
1 - 100 of 168 matches
Mail list logo
