This patch makes cfgcleanup optimize jumps to returns. There are three
cases this handles:
-- A jump to a return; this is simplified to just that return.
-- A conditional branch to a return; simplified to a conditional return.
-- A conditional branch that falls through to a return. This is simpl
Now that cfgcleanup knows how to optimize with return statements, the
epilogue insertion code doesn't have to deal with it itself anymore.
2016-05-03 Segher Boessenkool
* function.c (emit_use_return_register_into_block): Delete.
(gen_return_pattern): Delete.
(emit_retu
This series teaches cfgcleanup how to optimize jumps and branches to and
around return statements, after which the shrink-wrap code doesn't have
to deal with it anymore. The simplified code also catches a few more
cases.
Tested on powerpc64-linux (-m32 and -m64, all languages), and also on
x86_64
If the jump_block here contains just a return, we will crash later
in invert_jump. Don't allow that case.
2016-05-03 Segher Boessenkool
* cfgcleanup.c (try_simplify_condjump): Don't try to simplify a
branch to a return.
---
gcc/cfgcleanup.c | 1 +
1 file changed, 1 insertio
On 2 May 2016 at 19:01, Jan Hubicka wrote:
>> On Thu, 21 Apr 2016, Jan Hubicka wrote:
>>
>> > Hi,
>> > this patch implements the long promised logic to inline across -ffast-math
>> > boundary when eitehr caller or callee has no fp operations in it. This is
>> > needed to resolve code quality regr
On Tue, 3 May 2016, Christophe Lyon wrote:
> On 2 May 2016 at 19:01, Jan Hubicka wrote:
> >> On Thu, 21 Apr 2016, Jan Hubicka wrote:
> >>
> >> > Hi,
> >> > this patch implements the long promised logic to inline across
> >> > -ffast-math
> >> > boundary when eitehr caller or callee has no fp ope
On Wed, 27 Apr 2016, Jeff Law wrote:
> On 04/21/2016 06:55 AM, Richard Biener wrote:
> >
> > The following patch makes us not allocate decls but SSA names for
> > temporaries required during gimplification. This is basically the
> > same thing as we do when calling the gimplifier on GENERIC expr
On Mon, 2 May 2016, Jeff Law wrote:
> On 04/29/2016 05:36 AM, Richard Biener wrote:
> > On Thu, 28 Apr 2016, Jeff Law wrote:
> >
> > > On 04/28/2016 02:49 AM, Richard Biener wrote:
> > > >
> > > > The following prototype patch re-uses cc1-checksum.c from the
> > > > previous stage when compiling
> It seems to me that the issue in the end is that where we compute
> alignment from is the pieces gathered by get_inner_reference
> instead of computing it alongside of that information in
> get_inner_reference, taking advantage of DECL_OFFSET_ALIGN
> and the array element type alignment there. T
> On 29 Apr 2016, at 12:42, Olivier Hainque wrote:
>
> I'll discuss with the compiler-rt folks.
The change just went in upstream. http://reviews.llvm.org/D19799.
Olivier
On Mon, May 2, 2016 at 10:02 AM, Richard Biener
wrote:
> On Fri, Apr 29, 2016 at 5:51 PM, Bin.Cheng wrote:
>> On Thu, Apr 28, 2016 at 10:18 AM, Richard Biener
>> wrote:
>>> On Wed, Apr 27, 2016 at 5:49 PM, Bin Cheng wrote:
Hi,
Currently tree if-conversion only supports PHIs with no mo
PR 70687 reports a case where combine.c mishandles integer modes
wider than unsigned HOST_WIDE_INT. I don't have a testcase since
the PR is just pointing out the hole.
Also, I think a ZERO_EXTEND of a vector mode could in principle satisfy
the subreg condition but wouldn't be equivalent to an AND
On Fri, Apr 29, 2016 at 12:56 PM, marxin wrote:
> Hello.
>
> As profile-guided optimization can provide very useful information
> about basic block frequencies within a loop, following patch set leverages
> that information. It speeds up a single benchmark from upcoming SPECv6
> suite by 20% (-O2
Hi!
On Wed, 13 Apr 2016 18:01:09 +0200, I wrote:
> On Fri, 08 Apr 2016 11:36:03 +0200, I wrote:
> > On Thu, 10 Dec 2015 09:08:35 +0100, Jakub Jelinek wrote:
> > > On Wed, Dec 09, 2015 at 06:23:22PM +0100, Bernd Schmidt wrote:
> > > > On 12/09/2015 05:24 PM, Thomas Schwinge wrote:
> > > > >how abo
On 05/03/2016 11:11 AM, Richard Sandiford wrote:
PR 70687 reports a case where combine.c mishandles integer modes
wider than unsigned HOST_WIDE_INT. I don't have a testcase since
the PR is just pointing out the hole.
Also, I think a ZERO_EXTEND of a vector mode could in principle satisfy
the su
On Mon, May 2, 2016 at 10:00 AM, Richard Biener
wrote:
> On Fri, Apr 29, 2016 at 5:05 PM, Bin.Cheng wrote:
>> On Fri, Apr 29, 2016 at 12:16 PM, Richard Biener
>> wrote:
>>> On Thu, Apr 28, 2016 at 2:56 PM, Bin Cheng wrote:
Hi,
Tree if-conversion sometimes cannot convert conditional ar
On Mon, May 2, 2016 at 9:25 PM, H.J. Lu wrote:
> On Sat, Apr 30, 2016 at 2:28 PM, Patrick Palka wrote:
>> `On Fri, Apr 29, 2016 at 3:15 PM, Jeff Law wrote:
>>> On 04/19/2016 11:50 AM, Patrick Palka wrote:
>>>
1. This patch introduces a "regression" in gcc.dg/tree-ssa/ssa-thread-11.c
in
On Tue, May 3, 2016 at 12:01 PM, Bin.Cheng wrote:
> On Mon, May 2, 2016 at 10:00 AM, Richard Biener
> wrote:
>> On Fri, Apr 29, 2016 at 5:05 PM, Bin.Cheng wrote:
>>> On Fri, Apr 29, 2016 at 12:16 PM, Richard Biener
>>> wrote:
On Thu, Apr 28, 2016 at 2:56 PM, Bin Cheng wrote:
> Hi,
>>>
cpplib-6.1.0.nl.po.gz
Description: Binary data
The Translation Project robot, in the
name of your translation coordinator.
Hello, gentle maintainer.
This is a message from the Translation Project robot.
A revised PO file for textual domain 'cpplib' has been submitted
by the Dutch team of translators. The file is available at:
http://translationproject.org/latest/cpplib/nl.po
(This file, 'cpplib-6.1.0.nl.po', h
On Tue, 3 May 2016, Richard Biener wrote:
> On Mon, 2 May 2016, Jeff Law wrote:
>
> > On 04/29/2016 05:36 AM, Richard Biener wrote:
> > > On Thu, 28 Apr 2016, Jeff Law wrote:
> > >
> > > > On 04/28/2016 02:49 AM, Richard Biener wrote:
> > > > >
> > > > > The following prototype patch re-uses cc
Hi Nathan!
On Fri, 29 Apr 2016 10:00:43 -0400, Nathan Sidwell wrote:
> currently automatic loop partitioning assigns from the innermost loop
> outwards
> -- that was the simplest thing to implement. A better algorithm is to assign
> the outermost loop to the outermost available axis, and then
My r235660 ira.c change results in some single def/single ref cases
moving the def insn to just before the ref insn, that were not
previously moved. Unfortunately doing so resulted in a reload
problem.
The following shows a series of ia64 insns after ira, with insn 2078
(wasn't previously moved)
* Claudiu Zissulescu [2016-05-02 09:02:16
+]:
> Please also consider to address also the following warnings introduced:
>
> mainline/gcc/gcc/config/arc/arc.md:888: warning: source missing a mode?
> mainline/gcc/gcc/config/arc/arc.md:906: warning: source missing a mode?
> mainline/gcc/gcc/co
On Mon, May 02, 2016 at 11:01:02PM +0200, Uros Bizjak wrote:
> Please don't use operands[N] without corresponding (match_dup N) in
> the RTL pattern. Tthe "operands" array is only as long as the last
> operand number from the pattern. Just grep the pattern name from
> generated insn-emit.c and you
On Tue, May 3, 2016 at 8:36 AM, Marc Glisse wrote:
> This removes the duplication. I also removed the case (A&B)&(A&C) which is
> handled by reassoc. And I need 2 NOP checks, for the case where @0 is a
> constant (that couldn't happen before my patch because canonicalization
> would put the consta
On Tue, 3 May 2016, Jakub Jelinek wrote:
> On Mon, May 02, 2016 at 11:01:02PM +0200, Uros Bizjak wrote:
> > Please don't use operands[N] without corresponding (match_dup N) in
> > the RTL pattern. Tthe "operands" array is only as long as the last
> > operand number from the pattern. Just grep the
On 05/03/2016 12:45 PM, Alan Modra wrote:
PR rtl-optimization/70890
* ira.c (combine_and_move_insns): When moving def_insn, remove
equivs on use_insn.
I'm not sure yet, but it looks to me like this tweaks the wrong place.
diff --git a/gcc/ira.c b/gcc/ira.c
index a38e67
On Tue, May 3, 2016 at 1:04 PM, Richard Biener wrote:
> On Tue, 3 May 2016, Jakub Jelinek wrote:
>
>> On Mon, May 02, 2016 at 11:01:02PM +0200, Uros Bizjak wrote:
>> > Please don't use operands[N] without corresponding (match_dup N) in
>> > the RTL pattern. Tthe "operands" array is only as long as
Hi!
As the testcase shows, in some truncations we weren't unnecessarily allowing
xmm16-xmm31 regs. But VCVTSD2SS is already in AVX512F ISA, and the rest are
just splitters that use movs that are also in AVX512F.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2016-05-03 Ja
On Mon, May 02, 2016 at 01:34:30PM -0400, Jason Merrill wrote:
> On 05/02/2016 12:41 PM, Marek Polacek wrote:
> > On Fri, Apr 29, 2016 at 04:04:13PM -0400, Jason Merrill wrote:
> > > On 04/28/2016 11:59 AM, Marek Polacek wrote:
> > > > 3) for the C++ FE I used a macro so that I don't have to change
Hi all,
When building the arm backend genrecog complains that the probe_stack set
expression
doesn't specify any modes. This patch adds the SI mode annotation and fixes
the warning
Bootstrapped and tested on arm-none-linux-gnueabihf.
Ok for trunk?
Thanks,
Kyrill
2016-05-03 Kyrylo Tkachov
Hi!
Another insn where we can just unconditionally use v constraint instead of x
- for V2DImode HARD_REGNO_MODE_OK will only allow it for AVX512VL for the
ext regs, the insn is actually already available in AVX512F, but probably
not worth spending too much time on this to allow it even for xmm16-x
On Tue, May 3, 2016 at 4:07 AM, Patrick Palka wrote:
> This patch
>
> 1. changes the need_assert_for bitmap into an sbitmap since its size is
> known to be at most num_ssa_names
But then it is redundant anyway as we have asserts_for[num_ssa_names],
initialized to NULL. So bitmap_bit_p (need_asse
Hi!
We ICE on the following testcase. There are multiple issues, this patch
fixes just the ICE part; INTEGER_CST rhs1 is completely valid on COND_EXPR,
though of course a sign of missed optimization earlier; so we don't need
to spend too much time on it, but shouldn't ICE.
Bootstrapped/regtested
rev 235672 (git cffc0b35) changed the condition for SAVE_MULTIPLE/
STORE_MULTIPLE, wrongly allowing a single reg. Bootstrapped and
regression tested powerpc64-linux. OK to apply?
Incidentally, the added testcase function shows a regression in -m32
-Os code quality that I'll fix sometime soon.
g
Hi!
This allows us to better fold the COND_EXPR, so that _1 = 1 ? &foo : _2;
is folded to _1 = &foo. There is another bug, the 1 in this case is wrong,
but it could appear on some other code too.
Bootstrapped/regtested on x86_64-linux and i686-linux, ok for trunk?
2016-05-03 Jakub Jelinek
On Tue, 3 May 2016, Jakub Jelinek wrote:
> Hi!
>
> We ICE on the following testcase. There are multiple issues, this patch
> fixes just the ICE part; INTEGER_CST rhs1 is completely valid on COND_EXPR,
> though of course a sign of missed optimization earlier; so we don't need
> to spend too much
On Tue, 3 May 2016, Jakub Jelinek wrote:
> Hi!
>
> This allows us to better fold the COND_EXPR, so that _1 = 1 ? &foo : _2;
> is folded to _1 = &foo. There is another bug, the 1 in this case is wrong,
> but it could appear on some other code too.
>
> Bootstrapped/regtested on x86_64-linux and i
On Fri, Apr 01, 2016 at 08:29:17PM +0200, Uros Bizjak wrote:
> > Bootstrapped/regtested on x86_64-linux and i686-linux, ok for stage1
> > (while the previous patch looks simple enough that I'd like to see it in
> > 6.x, this one IMHO can wait).
>
> Yes, please. This is not a regression.
>
> > 201
On Tue, May 3, 2016 at 1:25 PM, Jakub Jelinek wrote:
> Hi!
>
> As the testcase shows, in some truncations we weren't unnecessarily allowing
> xmm16-xmm31 regs. But VCVTSD2SS is already in AVX512F ISA, and the rest are
> just splitters that use movs that are also in AVX512F.
>
> Bootstrapped/regte
On Tue, May 03, 2016 at 09:02:26PM +0930, Alan Modra wrote:
> rev 235672 (git cffc0b35) changed the condition for SAVE_MULTIPLE/
> STORE_MULTIPLE, wrongly allowing a single reg. Bootstrapped and
> regression tested powerpc64-linux. OK to apply?
Yes, this is okay for trunk, thanks for fixing it.
On 3 May 2016 at 10:09, Richard Biener wrote:
> On Tue, 3 May 2016, Christophe Lyon wrote:
>
>> On 2 May 2016 at 19:01, Jan Hubicka wrote:
>> >> On Thu, 21 Apr 2016, Jan Hubicka wrote:
>> >>
>> >> > Hi,
>> >> > this patch implements the long promised logic to inline across
>> >> > -ffast-math
>>
Hi Ilya,
> On Fri, Apr 29, 2016 at 10:58:25 +0200, Rainer Orth wrote:
>> > On 04/26/2016 08:04 AM, Rainer Orth wrote:
>> >> When working on a couple of Cilk Plus issues lately (PRs target/60290,
>> >> target/68945), I noticed that you have to modify the libcilkplus sources
>> >> to enable various
Hi Balaji,
> I suspected that much. It would be good to have a libcilkrts/README.gcc
> describing the rules which changes can go into the gcc tree directly, which
> need to go upstream first, and how. libo and libsanitizer already have
> this.
>
> Hi Rainer,
> It is mentioned under the "CO
On Tue, 3 May 2016, Richard Biener wrote:
> On Wed, 27 Apr 2016, Jeff Law wrote:
>
> > On 04/21/2016 06:55 AM, Richard Biener wrote:
> > >
> > > The following patch makes us not allocate decls but SSA names for
> > > temporaries required during gimplification. This is basically the
> > > same t
On Tue, May 03, 2016 at 07:03:45AM -0500, Segher Boessenkool wrote:
> On Tue, May 03, 2016 at 09:02:26PM +0930, Alan Modra wrote:
> > Incidentally, the added testcase function shows a regression in -m32
> > -Os code quality that I'll fix sometime soon.
>
> Could you tell more please?
This
12d
On 05/03/2016 02:20 PM, Alan Modra wrote:
diff --git a/gcc/ira.c b/gcc/ira.c
index a38e67e..cf5be35 100644
--- a/gcc/ira.c
+++ b/gcc/ira.c
@@ -3742,6 +3742,16 @@ combine_and_move_insns (void)
if (use_insn == BB_HEAD (use_bb))
BB_HEAD (use_bb) = new_insn;
+ /* Sinc
On 04/25/2016 04:17 PM, Trevor Saunders wrote:
On Mon, Apr 25, 2016 at 03:55:15PM +0200, Bernd Schmidt wrote:
On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote:
-/* Remove INSN from queue. */
+/* Remove INSN at idx from queue. */
+static void
+queue_remove (unsigned int q, unsigned int
ENOPATCH
On 1 May 2016 at 15:21, Eelis wrote:
> Sorry, forgot to include the libstdc++ list.
>
> On 2016-05-01 16:18, Eelis wrote:
>>
>> Hi,
>>
>> The attached patch optimizes std::shuffle for the very common case
>> where the generator range is large enough that a single invocation
>> can produc
On Tue, 3 May 2016, Christophe Lyon wrote:
> On 3 May 2016 at 10:09, Richard Biener wrote:
> > On Tue, 3 May 2016, Christophe Lyon wrote:
> >
> >> On 2 May 2016 at 19:01, Jan Hubicka wrote:
> >> >> On Thu, 21 Apr 2016, Jan Hubicka wrote:
> >> >>
> >> >> > Hi,
> >> >> > this patch implements the
On 05/03/2016 08:59 AM, Segher Boessenkool wrote:
This series teaches cfgcleanup how to optimize jumps and branches to and
around return statements, after which the shrink-wrap code doesn't have
to deal with it anymore. The simplified code also catches a few more
cases.
Tested on powerpc64-li
On Tue, May 03, 2016 at 02:36:55PM +0200, Bernd Schmidt wrote:
> On 04/25/2016 04:17 PM, Trevor Saunders wrote:
> > On Mon, Apr 25, 2016 at 03:55:15PM +0200, Bernd Schmidt wrote:
> > > On 04/20/2016 08:22 AM, tbsaunde+...@tbsaunde.org wrote:
> > > > -/* Remove INSN from queue. */
> > > > +/* Remov
Hello,
On 28/04/16 16:49, Joseph Myers wrote:
On Thu, 28 Apr 2016, Matthew Wahab wrote:
The ARM target supports the half-precision floating point type __fp16 but does
not allow its use as a function return or parameter type. This patch removes
that restriction and defines the ACLE macro __ARM_
Hello,
The target hooks TARGET_INVALID_PARAMETER_TYPE and
TARGET_INVALID_RETURN_TYPE were only used by the ARM backend and
are no longer used. This patch removes them.
Tested for arm-none-linux-gnueabihf with native bootstrap and make check
and for and x86_64-none-linux native bootstrap and chec
On Tue, May 03, 2016 at 02:33:36PM +0200, Bernd Schmidt wrote:
> On 05/03/2016 02:20 PM, Alan Modra wrote:
> >>
> >>>diff --git a/gcc/ira.c b/gcc/ira.c
> >>>index a38e67e..cf5be35 100644
> >>>--- a/gcc/ira.c
> >>>+++ b/gcc/ira.c
> >>>@@ -3742,6 +3742,16 @@ combine_and_move_insns (void)
> >>> if
On Tue, 3 May 2016, Richard Biener wrote:
On Tue, May 3, 2016 at 8:36 AM, Marc Glisse wrote:
This removes the duplication. I also removed the case (A&B)&(A&C) which is
handled by reassoc. And I need 2 NOP checks, for the case where @0 is a
constant (that couldn't happen before my patch because
On Tue, May 03, 2016 at 02:53:42PM +0200, Bernd Schmidt wrote:
> >This series teaches cfgcleanup how to optimize jumps and branches to and
> >around return statements, after which the shrink-wrap code doesn't have
> >to deal with it anymore. The simplified code also catches a few more
> >cases.
>
On 04/27/2016 09:55 AM, Dominik Vogt wrote:
gcc/ChangeLog
* config/s390/s390.md ("*rsbg__sll")
("*rsbg__srl"): New define_insns.
("*rsbg__srl_bitmask"): Renamed by adding "_bitmask".
("*rsbg__sll_bitmask"): Likewise.
gcc/testsuite/ChangeLog
* gcc.target/s39
On Tue, May 3, 2016 at 3:26 PM, Marc Glisse wrote:
> On Tue, 3 May 2016, Richard Biener wrote:
>
>> On Tue, May 3, 2016 at 8:36 AM, Marc Glisse wrote:
>>>
>>> This removes the duplication. I also removed the case (A&B)&(A&C) which
>>> is
>>> handled by reassoc. And I need 2 NOP checks, for the ca
On 05/03/2016 03:31 PM, Segher Boessenkool wrote:
If not, are you set up to test arm in
any way? Ideally you'd want to run that as well.
Good plan. There is arm64 in the cfarm; I'll see if I can build 32-bit
as well.
Simulator testing should work, but if ppc exercises this code there's
prob
On 21/04/16 12:45, Jan Hubicka wrote:
> this patch implements the long promised logic to inline across -ffast-math
> boundary when eitehr caller or callee has no fp operations in it. This is
> needed to resolve code quality regression on Firefox with LTO where
> -O3/-O2/-Ofast flags are combined a
On 05/03/2016 03:24 PM, Alan Modra wrote:
Err, is loop depth accurate in 254r.sched1?
In the ira dump, I see them all at loop depth 1.
So I expect that DF doesn't see the death because we're in a loop.
looks like we should have a death note? I could see how such a move would
create a new deat
> On 21/04/16 12:45, Jan Hubicka wrote:
> > this patch implements the long promised logic to inline across -ffast-math
> > boundary when eitehr caller or callee has no fp operations in it. This is
> > needed to resolve code quality regression on Firefox with LTO where
> > -O3/-O2/-Ofast flags are
Hello,
Under specific circumstances for Ada programs, such as in the testcase
this change adds, the DWARF back-end currently crashes because of
inconsistent internal state. This is due to a typo: a local variable is
called frame_offset_ but resolve_args_picking_1 wrongly modifies
emit-rtl.h's fram
Version two of the patch including a test case.
On Mon, May 02, 2016 at 09:10:25AM -0600, Jeff Law wrote:
> On 04/29/2016 04:12 PM, Dominik Vogt wrote:
> >The attached patch removes excess stack space allocation with
> >alloca in some situations. Plese check the commit message in the
> >patch for
On Tue, 3 May 2016, Szabolcs Nagy wrote:
> On 21/04/16 12:45, Jan Hubicka wrote:
> > this patch implements the long promised logic to inline across -ffast-math
> > boundary when eitehr caller or callee has no fp operations in it. This is
> > needed to resolve code quality regression on Firefox wi
On Tue, 3 May 2016, Jan Hubicka wrote:
> > On 21/04/16 12:45, Jan Hubicka wrote:
> > > this patch implements the long promised logic to inline across -ffast-math
> > > boundary when eitehr caller or callee has no fp operations in it. This is
> > > needed to resolve code quality regression on Fire
On 05/03/2016 10:20 AM, Richard Biener wrote:
On Tue, 3 May 2016, Jan Hubicka wrote:
On 21/04/16 12:45, Jan Hubicka wrote:
this patch implements the long promised logic to inline across -ffast-math
boundary when eitehr caller or callee has no fp operations in it. This is
needed to resolve cod
See comments added below. Bootstrapped and regression tested
powerpc64le-linux. OK to apply?
PR testsuite/70826
* gcc.target/powerpc/savres.c: Compile with -fno-rename-registers.
diff --git a/gcc/testsuite/gcc.target/powerpc/savres.c
b/gcc/testsuite/gcc.target/powerpc/savres.c
Hi,
This fixes four access violations
(https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70926).
Two of these first read the value of a length variable len from the mangled
string, then strncpy len characters from the mangled string; more than
necessary.
The other two read the value of an array in
On Tue, May 03, 2016 at 03:51:11PM +0200, Bernd Schmidt wrote:
> If that is all ok and we just have a really odd cfg, then your patch is ok
> with a better comment as to which situations can cause the problem.
Thanks, committed rev 235825.
diff --git a/gcc/ira.c b/gcc/ira.c
index a38e67e..269a190
Ah, thanks, I forgot to re-attach when I sent to include the libstdc++ list.
On 2016-05-03 14:38, Jonathan Wakely wrote:
ENOPATCH
On 1 May 2016 at 15:21, Eelis wrote:
Sorry, forgot to include the libstdc++ list.
On 2016-05-01 16:18, Eelis wrote:
Hi,
The attached patch optimizes std::shuff
On 16-04-18 15:04:58, Markus Trippelsdorf wrote:
> A nice follow-up patch would be to set SOURCE_DATE_EPOCH to the current
> time during -fcompare-debug. This would avoid false positives like:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70679
I've been working on a patch to implement that, but
Fixes an ICE found when using odd options. Bootstrapped and
regression tested both powerpc64-linux and powerpc64le-linux. OK to
apply?
gcc/
PR target/70866
* config/rs6000/rs6000.c (rs6000_stack_info): Don't set cr_save_p
when cr2,3,4 are all fixed regs.
gcc/testsuite/
On 2016.05.03 at 16:42 +0200, Dhole wrote:
> On 16-04-18 15:04:58, Markus Trippelsdorf wrote:
> > A nice follow-up patch would be to set SOURCE_DATE_EPOCH to the current
> > time during -fcompare-debug. This would avoid false positives like:
> > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70679
>
Hi Segher,
On 03/05/16 07:59, Segher Boessenkool wrote:
This series teaches cfgcleanup how to optimize jumps and branches to and
around return statements, after which the shrink-wrap code doesn't have
to deal with it anymore. The simplified code also catches a few more
cases.
Tested on powerpc
On Wed, May 04, 2016 at 12:22:24AM +0930, Alan Modra wrote:
> Fixes an ICE found when using odd options. Bootstrapped and
> regression tested both powerpc64-linux and powerpc64le-linux. OK to
> apply?
>
> gcc/
> PR target/70866
> * config/rs6000/rs6000.c (rs6000_stack_info): Don't se
On May 3, 2016 4:05:40 PM GMT+02:00, Pierre-Marie de Rodat
wrote:
>Hello,
>
>Under specific circumstances for Ada programs, such as in the testcase
>this change adds, the DWARF back-end currently crashes because of
>inconsistent internal state. This is due to a typo: a local variable is
>called f
This PR points out that we emit bad column number when validating builtin
functions arguments and this patch fixes this deficiency for the C part,
where I can simply use the vector of argument locations.
You'll see that I introduced expansion_point_location function. The reason
for that is that f
On 05/03/2016 05:41 PM, Richard Biener wrote:
This change fixes this typo. Bootstrapped and regtested on x86_64-linux
successfuly. Ok to commit? Thank you in advance!
OK also for branches.
Comitted to trunk and gcc-6-branch. Thank you!
--
Pierre-Marie de Rodat
On 02/05/16 16:15, Jeff Law wrote:
On 05/02/2016 03:47 AM, Richard Sandiford wrote:
Kyrill Tkachov writes:
Hi all,
I'm getting a warning when building genrecog that 'label' may be used
uninitialised in:
uint64_t label = 0;
if (d->test.kind == rtx_test::CODE
&& d->if_st
On Tue, 3 May 2016, Marek Polacek wrote:
> 2016-05-03 Marek Polacek
>
> PR c/70859
> * input.c (expansion_point_location): New function.
> * input.h (expansion_point_location): Declare.
>
> * c-common.c (builtin_function_validate_nargs): Add location
> parameter.
Hi,
On 13/04/2016 17:27, Jason Merrill wrote:
On 04/13/2016 11:05 AM, Paolo Carlini wrote:
As it happens, anyway, the below exceedingly trivial patch avoids the
ICE in resolve_typename_type and appears to pass testing (is already
past g++.dg/tm/tm.exp...). Should I apply it instead together wit
Hi,
call_stmt_cannot_inline_p ultimately translated into setting inline_failed
to CIF_MISMATCHED_ARGUMENTS. This is not always accurate because the flag
is set for multiple reasons. THis patch makes it possible to simply set
inline_failed to any of the CIF_FATAL_ERROR codes and inliner won't try t
Hi!
As mentioned in the PR and on IRC, the initial problem on the testcase
from this PR is that if-conv mistakenly assumes that some bb predicates
are true predicates, when they really should not be.
The problem is if we have a loop (perhaps finite) inside of some infinite
loop, when computing pos
Hi!
While working on a patch I'm going to post momentarily, I've noticed that
we sometimes emit AVX512DQ specific instructions even when avx512dq is not
enabled (in particular, EVEX andnps and andnpd are AVX512DQ plus if
they have 128-bit or 256-bit arguments, also AVX512VL).
I'm not 100% happy a
2016-05-03 Uros Bizjak
* config/i386/predicates.md (x87nonimm_ssenomem_operand): Rename
from nonimm_ssenomem_operand.
(nonimm_ssenomem_operand): New predicate.
* config/i386/i386.md (extendsfdf2): Use nonimm_ssenomem_operand
as operand 0 predicate.
(*extendsfdf2): Merge
Hi!
This patch improves code generation e.g. on the first attached testcase
and allows accepting the second one.
I've noticed we don't allow TFmode or V1TImode in xmm16+ regs at all,
while they are allowed in xmm0-xmm15, so IMHO should be ok even with
AVX512VL.
Wonder if it wouldn't be better to
On May 3, 2016 8:16:18 PM GMT+02:00, Jakub Jelinek wrote:
>Hi!
>
>As mentioned in the PR and on IRC, the initial problem on the testcase
>from this PR is that if-conv mistakenly assumes that some bb predicates
>are true predicates, when they really should not be.
>The problem is if we have a loop
Hi,
the code path handling the case where callee is missing return statement but
calle
statement has LHS is broken in tree-inline since anonymous SSA_NAMEs was
introduced.
This code is not not used because all those inlines are disabled by
gimple_check_call_matching_types, but since I would like
On 05/03/2016 01:15 PM, Paolo Carlini wrote:
Hi,
On 13/04/2016 17:27, Jason Merrill wrote:
On 04/13/2016 11:05 AM, Paolo Carlini wrote:
As it happens, anyway, the below exceedingly trivial patch avoids the
ICE in resolve_typename_type and appears to pass testing (is already
past g++.dg/tm/tm.e
Jeff Law writes:
> On 05/02/2016 02:40 PM, Carlos O'Donell wrote:
>>
>> However, in the end, I think that yet-another-document is not the
>> solution we want. What we actually need is a program that just formats
>> your source according to the GNU Coding Style and that way you can always
>> tell y
On 28.04.2016 09:09, Richard Biener wrote:
>
> As said elsewhere the main reason for all of this is to make the
> in-tree builds work better for newer archs that are not happy with
> the versions provided by download_prerequesites. This should come
> with a documentation adjustment that the only t
On 05/03/2016 03:59 PM, Richard Sandiford wrote:
> Jeff Law writes:
>> On 05/02/2016 02:40 PM, Carlos O'Donell wrote:
>>>
>>> However, in the end, I think that yet-another-document is not the
>>> solution we want. What we actually need is a program that just formats
>>> your source according to th
On Tue, May 3, 2016 at 8:59 AM, Segher Boessenkool wrote:
> If the jump_block here contains just a return, we will crash later
> in invert_jump. Don't allow that case.
But if jump_block contains a return, then it isn't the EXIT_BLOCK for
the function.
Is the conditional jump a conditional return
On Tue, May 03, 2016 at 10:28:37PM +0200, Steven Bosscher wrote:
> On Tue, May 3, 2016 at 8:59 AM, Segher Boessenkool wrote:
> > If the jump_block here contains just a return, we will crash later
> > in invert_jump. Don't allow that case.
>
> But if jump_block contains a return, then it isn't the
On Fri, Apr 29, 2016 at 10:21 AM, Richard Biener
wrote:
> On April 29, 2016 3:48:37 PM GMT+02:00, David Edelsohn
> wrote:
>>On Fri, Apr 29, 2016 at 9:44 AM, Bernd Schmidt
>>wrote:
>>>
>>>
>>> On 04/29/2016 03:42 PM, David Edelsohn wrote:
On Fri, Apr 29, 2016 at 9:32 AM, Bernd Schmidt
On Tue, 3 May 2016, Richard Sandiford wrote:
> And sometimes there are multiple acceptable ways of writing the same code.
> Which wins is an aesthetic choice, which tools tend to be bad at handling.
> E.g. if a parameter list is too long for a line, there's often a choice
> of how to balance the p
On 05/03/2016 09:59 PM, Richard Sandiford wrote:
And sometimes there are multiple acceptable ways of writing the same code.
Which wins is an aesthetic choice, which tools tend to be bad at handling.
E.g. if a parameter list is too long for a line, there's often a choice
of how to balance the par
1 - 100 of 116 matches
Mail list logo