On Mon, Sep 12, 2016 at 10:30:56AM -0600, Jeff Law wrote:
> On 09/10/2016 01:17 AM, Segher Boessenkool wrote:
> >On Fri, Sep 09, 2016 at 04:40:12PM -0600, Jeff Law wrote:
> >>Right now the dataflow is conservatively correct WRT the return register.
> >
> >And conservatively incorrect wrt all other
On Wed, Sep 14, 2016 at 1:30 AM, Mark Wielaard wrote:
> On Wed, 2016-09-14 at 00:00 -0400, Jason Merrill wrote:
>> I wonder about spelling the options as
>> -Wshadow={local,compatible-local} rather than with a dash, but
>> otherwise the patch looks fine.
>
> That is a much nicer
On 6 September 2016 at 12:15, Jonathan Wakely wrote:
> On 02/09/16 14:17 +0100, Matthew Wahab wrote:
>>
>> Hello,
>>
>> Tests in the libstdc++-v3 testsuite were recently changed to use { dg-do
>> .. { target c++11 } } instead of using a dg-options to set -std
>>
On Mon, Sep 12, 2016 at 10:49:46AM -0600, Jeff Law wrote:
> On 09/09/2016 02:56 PM, Segher Boessenkool wrote:
> >On Fri, Sep 09, 2016 at 12:57:32PM -0600, Jeff Law wrote:
> >>I think the lack of test coverage is something we'll want to address.
> >
> >Building and running the compiler, the various
On 9/14/16, Jason Merrill wrote:
> On Mon, Sep 12, 2016 at 1:38 PM, Jim Meyering wrote:
>> On Mon, Sep 12, 2016 at 7:05 AM, Eric Gallager
>> wrote:
>>> On 9/11/16, Manuel López-Ibáñez wrote:
On 11/09/16
On 14/09/16 11:33 +0100, Jonathan Wakely wrote:
We need to get better at documenting things. The interaction between
the different namespaces in Debug Mode, Parallel Mode etc is already
confusing, and I think this patch would make it worse. The namespaces
used for the math special functions
On 13/09/16 11:02 -0700, Cong Wang wrote:
In !_GLIBCXX_USE_CXX11_ABI implementation, string::clear() calls
_M_mutate(), which could allocate memory as we do COW. This hurts
performance when string::clear() is on the hot path.
This patch improves it by using _S_empty_rep directly when
On Tue, Aug 23, 2016 at 4:11 AM, Kugan Vivekanandarajah
wrote:
> Hi,
>
> On 19 August 2016 at 21:41, Richard Biener wrote:
>> On Tue, Aug 16, 2016 at 9:45 AM, kugan
>> wrote:
>>> Hi Richard,
>>>
On Wed, 2016-09-14 at 05:39 -0700, Ian Lance Taylor wrote:
> On Wed, Sep 14, 2016 at 1:30 AM, Mark Wielaard wrote:
> > On Wed, 2016-09-14 at 00:00 -0400, Jason Merrill wrote:
> >> I wonder about spelling the options as
> >> -Wshadow={local,compatible-local} rather than with a
On Mon, Sep 12, 2016 at 11:24:01AM -0600, Jeff Law wrote:
> >sel-sched-ir.c says
> >
> >/* Certain instructions cannot be cloned, and frame related insns and
> > the insn adjacent to NOTE_INSN_EPILOGUE_BEG cannot be moved out of
> > their block. */
> >if
On Mon, Sep 12, 2016 at 12:02:50PM -0600, Jeff Law wrote:
> >>>As a final optimisation, if a block needs a prologue and its immediate
> >>>dominator has the block as a post-dominator, the dominator gets the
> >>>prologue as well.
> >>So why not just put it in the idom and not in the dominated
On 14 September 2016 at 15:27, Jonathan Wakely wrote:
> On 14/09/16 15:17 +0200, Christophe Lyon wrote:
>>
>> It seems some tests still have dg-require or dg-skip before dg-do.
>> The attached patch fixes that, the only effect is that
>>
On Sep 13 2016, Jason Merrill wrote:
> On Tue, Sep 13, 2016 at 9:03 AM, Andreas Schwab wrote:
>> On Sep 13 2016, Jason Merrill wrote:
>>
>>> Does this help?
>>
>> Unfortunatly no.
>
> It occurs to me that this function doesn't need to
On Mon, Aug 22, 2016 at 4:58 PM, Robin Dapp wrote:
>> if !inner_ovf (just set that to false if !check_inner_ovf to simplify
>> checks please).
>> you know it's valid to transform the op to (T)@0 innerop (T)@1 outerop @2
>> (if T is wider than the inner type which I think
On Mon, Sep 12, 2016 at 10:33:22AM -0600, Jeff Law wrote:
> The answer is to debug the problem, and yes it may be painful.
Yes, the three weeks pretty much full-time I spent on that already attest
to that.
> I'd
> probably start by fixing the dataflow issues and see if that fixes the
>
On 14/09/16 15:17 +0200, Christophe Lyon wrote:
It seems some tests still have dg-require or dg-skip before dg-do.
The attached patch fixes that, the only effect is that
25_algorithms/lower_bound/debug/irreflexive.cc
is now UNSUPPORTED instead of PASS on arm* and aarch64* targets.
I'm not sure
On Wed, Sep 14, 2016 at 03:08:21PM +0200, Bernd Schmidt wrote:
> On 09/14/2016 03:04 PM, Segher Boessenkool wrote:
> >Then rs6000 (and many other ports probably) will just turn it off again.
> >It is actively harmful.
>
> The data that was posted showed a code size decrease on a number of
>
Hi Jonathan,
>>* For 64-bit, I get
>>
>>+FAIL: g++.dg/cpp1z/aligned-new5.C -std=gnu++11 execution test
>>+FAIL: g++.dg/cpp1z/aligned-new5.C -std=gnu++14 execution test
>>+FAIL: g++.dg/cpp1z/aligned-new5.C -std=gnu++98 execution test
>>
>> which fails like this:
>>
>>terminate called after
In an attempt to get this patch merged (as I still think that its
correct) I've investigated, and documented a little more about how I
think things currently work. I'm sure most people reading this will
already know this, but hopefully, if my understanding is wrong someone
can point it out.
I've
On Wed, Sep 14, 2016 at 02:00:48PM +0100, Andrew Burgess wrote:
> In an attempt to get this patch merged (as I still think that its
> correct) I've investigated, and documented a little more about how I
> think things currently work. I'm sure most people reading this will
> already know this, but
On Tue, Sep 6, 2016 at 8:52 PM, Bin Cheng wrote:
> Hi,
> This is the main patch improving control flow graph for vectorized loop. It
> generally rewrites loop peeling stuff in vectorizer. As described in patch,
> for a typical loop to be vectorized like:
>
>
I promised I'd do the int -> bool conversion for build_unary_op (and so
even for cp_build_unary_op), so here it is.
Bootstrapped/regtested on x86_64-linux and ppc64-linux, ok for trunk?
2016-09-14 Marek Polacek
* c-common.c (c_common_truthvalue_conversion): Use
On Wed, Sep 14, 2016 at 3:28 PM, Marek Polacek wrote:
> On Wed, Sep 14, 2016 at 03:24:18PM +0200, Richard Biener wrote:
>> > PING.
>> >
>> > https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01837.html
>>
>> (that was a ping for the C FE maintainers)
>>
>> Prasad, can you update
On Fri, Sep 2, 2016 at 10:09 AM, Kugan Vivekanandarajah
wrote:
> Hi Richard,
>
> On 25 August 2016 at 22:24, Richard Biener wrote:
>> On Thu, Aug 11, 2016 at 1:09 AM, kugan
>> wrote:
>>> Hi,
>>>
On Tue, Sep 13, 2016 at 08:45:25PM -0400, David Malcolm wrote:
> We warn about uses of uninitialized variables from the middle end, via
> warn_uninit.
>
> This patch adds the ability for such warnings to contain fix-it hints,
> showing the user how to zero-initialize the relevant variables.
>
On Fri, Sep 9, 2016 at 12:38 PM, Prasad Ghangal
wrote:
> On 26 August 2016 at 14:28, Richard Biener wrote:
>> On Fri, Aug 26, 2016 at 5:08 AM, Prasad Ghangal
>> wrote:
>>> On 24 August 2016 at 15:32, Richard Biener
Committed revision 240134.
---
Fritz Reese
On Tue, Sep 13, 2016 at 10:52 AM, Jerry DeLisle wrote:
> On 09/13/2016 07:33 AM, Fritz Reese wrote:
>>
>> Jim,
>>
>> While the test exhibits no particular regression, IMVHO I don't see
>> any reason not to add it. None of my
On Wed, Sep 14, 2016 at 03:24:18PM +0200, Richard Biener wrote:
> > PING.
> >
> > https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01837.html
>
> (that was a ping for the C FE maintainers)
>
> Prasad, can you update the git branch with the changes from the last patch you
> sent out? I don't think
On Tue, Sep 13, 2016 at 2:36 PM, Wilco Dijkstra wrote:
> Richard Biener wrote:
>> On Wed, May 18, 2016 at 2:29 PM, Wilco Dijkstra
>> wrote:
>>> Richard Biener wrote:
>>>
Yeah ;) I'm currently
On Tue, Sep 13, 2016 at 01:55:56PM -0600, Martin Sebor wrote:
> > - /* Forbid using -- on `bool'. */
> > + /* Forbid using -- or ++ in C++17 on `bool'. */
> > if (TREE_CODE (declared_type) == BOOLEAN_TYPE)
> > {
> > if (code == POSTDECREMENT_EXPR || code ==
On 09/14/2016 03:04 PM, Segher Boessenkool wrote:
Then rs6000 (and many other ports probably) will just turn it off again.
It is actively harmful.
The data that was posted showed a code size decrease on a number of
targets. I'm really not sure where this irrational hate for regrename
comes
On Wed, Sep 14, 2016 at 07:46:13AM -0500, Peter Bergner wrote:
> On 9/14/16 5:35 AM, Segher Boessenkool wrote:
> > (I hope the wording is strong enough).
> Maybe s/New ports should use LRA/New ports must use LRA/ ?
Yeah maybe. Does anyone else have an opinion on this? Cc:ing gcc@...
> >+ New
On 09/14/2016 02:45 AM, David Malcolm wrote:
In combination with -fdiagnostics-generate-patch this can generate output
like this:
--- ../../src/gcc/testsuite/c-c++-common/fix-missing-initializer-1.c
+++ ../../src/gcc/testsuite/c-c++-common/fix-missing-initializer-1.c
@@ -2,7 +2,7 @@
On 9/14/16 5:35 AM, Segher Boessenkool wrote:
On Tue, Sep 13, 2016 at 02:38:54PM -0600, Jeff Law wrote:
I believe a doc update of some kind is in order. With the doc update
the entire series is OK.
Good catch, thanks. My tests finished, all results identical. I'll add
the following patch
On Wed, Sep 14, 2016 at 03:41:33PM +0200, Richard Biener wrote:
> > We've seen several different proposals for where/how to do this
> > simplification, why did you
> > say strlenopt is best? It would be an unconditional strchr (a, 0) -> a +
> > strlen (a) rewrite,
> > ie. completely unrelated to
On Wed, Sep 14, 2016 at 9:08 AM, Marek Polacek wrote:
> On Tue, Sep 13, 2016 at 01:55:56PM -0600, Martin Sebor wrote:
>> > - /* Forbid using -- on `bool'. */
>> > + /* Forbid using -- or ++ in C++17 on `bool'. */
>> > if (TREE_CODE (declared_type) == BOOLEAN_TYPE)
>>
On Wed, Sep 14, 2016 at 9:22 AM, Marek Polacek wrote:
> * c-common.h (build_unary_op): Change a parameter type to bool.
> (build_unary_op): Change a parameter type to bool, use true/false
> (cp_build_unary_op): Change a parameter type to bool. Use true
On Wed, Sep 14, 2016 at 10:54:35AM -0400, Jason Merrill wrote:
> Martin's point, which I agree with, is that for C++ we want to use
> "bool" rather than either of those.
Sure, I'm testing another version of this patch which has this fixed.
Marek
On 09.08.2016 15:43, kugan wrote:
Hi,
The test-case in PR72835 is failing with -O2 and passing with
-fno-tree-reassoc. It also passes with -O2 -fno-tree-vrp.
diff of .115t.dse2 and .116t.reassoc1 for the c++ testcase is as follows, which
looks OK.
+ unsigned int _16;
+ unsigned int _17;
+
On 09/14/2016 03:55 PM, Segher Boessenkool wrote:
On Wed, Sep 14, 2016 at 03:08:21PM +0200, Bernd Schmidt wrote:
The data that was posted showed a code size decrease on a number of
targets. I'm really not sure where this irrational hate for regrename
comes from.
It increases the number of
On Wed, Sep 14, 2016 at 10:58:39AM -0400, Jason Merrill wrote:
> On Wed, Sep 14, 2016 at 9:22 AM, Marek Polacek wrote:
> > * c-common.h (build_unary_op): Change a parameter type to bool.
> > (build_unary_op): Change a parameter type to bool, use true/false
> >
On Tue, Sep 13, 2016 at 11:37:20PM -0400, Jason Merrill wrote:
> On Tue, Sep 13, 2016 at 3:55 PM, Martin Sebor wrote:
> > Having said all that, since this is C++ the message could and
> > arguably should refer to a bool expression (or type) instead
> > and avoid having to deal
I've committed this backport to the gcc-6 branch. I'll commit the new testcase
to trunk, so we don't regress in future.
nathan
2016-09-14 Nathan Sidwell
cp/
PR c++/77539
* constexpr.c (get_fundef_copy): Use the original function for
non-recursive evaluations.
On Wed, Sep 14, 2016 at 4:06 AM, Jonathan Wakely wrote:
> On 13/09/16 11:02 -0700, Cong Wang wrote:
>>
>> In !_GLIBCXX_USE_CXX11_ABI implementation, string::clear() calls
>> _M_mutate(), which could allocate memory as we do COW. This hurts
>> performance when string::clear()
Hi!
On Tue, 13 Sep 2016 16:27:39 +0200, Bernd Schmidt wrote:
> On 09/13/2016 04:24 PM, Jason Merrill wrote:
>
> > But we could define TARGET_ABSOLUTE_BIGGEST_ALIGNMENT on nvptx instead
> > of on x86; is this OK?
>
> That's what I had in mind. It would be good if Thomas or
On Wed, Sep 14, 2016 at 12:10 PM, Bernd Edlinger
wrote:
> The other false positive was in dwarf2out, where we have this:
>
> ../../gcc-trunk/gcc/dwarf2out.c:26166:35: error: ?: using integer
> constants in boolean context [-Werror=int-in-bool-context]
>if
Attached is an updated patch that does away with the "overlapping"
warning and instead issues the same warnings as the C front end
(though with more context).
In struct flexmems_t I've retained the NEXT array even though only
the first element is used to diagnose problems. The second element
is
On 09/14/16 18:37, Jason Merrill wrote:
> On Wed, Sep 14, 2016 at 12:10 PM, Bernd Edlinger
> wrote:
>> The other false positive was in dwarf2out, where we have this:
>>
>> ../../gcc-trunk/gcc/dwarf2out.c:26166:35: error: ?: using integer
>> constants in boolean context
On 09/14/2016 07:55 AM, Segher Boessenkool wrote:
On Wed, Sep 14, 2016 at 03:08:21PM +0200, Bernd Schmidt wrote:
On 09/14/2016 03:04 PM, Segher Boessenkool wrote:
Then rs6000 (and many other ports probably) will just turn it off again.
It is actively harmful.
The data that was posted showed
On 14 September 2016 at 14:11, Andreas Schwab wrote:
> On Sep 13 2016, Jason Merrill wrote:
>
>> On Tue, Sep 13, 2016 at 9:03 AM, Andreas Schwab
>> wrote:
>>> On Sep 13 2016, Jason Merrill wrote:
>>>
Does
Hi Bernd,
On Wed, Sep 14, 2016 at 04:01:34PM +0200, Bernd Schmidt wrote:
> On 09/14/2016 03:55 PM, Segher Boessenkool wrote:
> >On Wed, Sep 14, 2016 at 03:08:21PM +0200, Bernd Schmidt wrote:
> >>The data that was posted showed a code size decrease on a number of
> >>targets. I'm really not sure
On 09/14/2016 07:21 AM, Richard Biener wrote:
On Tue, Sep 6, 2016 at 8:52 PM, Bin Cheng wrote:
Hi,
This is the main patch improving control flow graph for vectorized loop. It
generally rewrites loop peeling stuff in vectorizer. As described in patch,
for a typical loop
Richard Biener writes:
> On Tue, Sep 13, 2016 at 6:01 PM, Joseph Myers wrote:
>> On Tue, 13 Sep 2016, Moritz Klammler wrote:
>>
>>> I have made an actual diff now, containing also the checksum files.
>>> I
>>
>> I don't think checksums of
The following patch corrects a problem with setting the probability on the pred
edge instead of the newly created fallthru succ edge.
Bootstrap/regtest on powerpc64le with no new regressions. Committed as obvious.
-Pat
2016-09-14 Pat Haugen
* loop-unroll.c
OK, thanks.
On Wed, Sep 14, 2016 at 3:43 AM, Jakub Jelinek wrote:
> On Tue, Sep 13, 2016 at 11:46:52PM -0400, Jason Merrill wrote:
>> On Tue, Sep 13, 2016 at 3:26 PM, Jakub Jelinek wrote:
>> >for (tree t = lvl->names; t; t = TREE_CHAIN (t))
>> > {
>>
On 14/09/16 09:09 -0700, Cong Wang wrote:
On Wed, Sep 14, 2016 at 4:06 AM, Jonathan Wakely wrote:
On 13/09/16 11:02 -0700, Cong Wang wrote:
In !_GLIBCXX_USE_CXX11_ABI implementation, string::clear() calls
_M_mutate(), which could allocate memory as we do COW. This hurts
Joseph Myers writes:
> On Wed, 14 Sep 2016, Moritz Klammler wrote:
>
>> be cleaner to only include those checksums that are actually needed. On
>> the other hand, it means an increased maintenance burden each time the
>> version of the dependency is changed. In order
On Wed, Sep 14, 2016 at 1:37 PM, Bernd Edlinger
wrote:
> On 09/14/16 18:37, Jason Merrill wrote:
>> On Wed, Sep 14, 2016 at 12:10 PM, Bernd Edlinger
>> wrote:
>>> The other false positive was in dwarf2out, where we have this:
>>>
>>>
Hi Jeff,
it turned out, that the changed symmetric condition in the warning hit
at several places, but also caused two false positives which I had to
address first. I tried also building a recent glibc, which hit a false
positive when using __builtin_isinf_sign in boolean context, which
is used
uses exceptions. These examples worked for DJGPP as expected with
today
build of gcc-7.0.0-20160914. ZCX_By_Default in system-djgpp.ads had value true as in last version
of patch.
Andris
On 09/14/2016 05:34 AM, Bernd Schmidt wrote:
On 09/14/2016 02:45 AM, David Malcolm wrote:
In combination with -fdiagnostics-generate-patch this can generate output
like this:
--- ../../src/gcc/testsuite/c-c++-common/fix-missing-initializer-1.c
+++
[ Another patch I'd started working through, but hadn't completed... ]
On 09/14/2016 07:05 AM, Richard Biener wrote:
On Mon, Aug 22, 2016 at 4:58 PM, Robin Dapp wrote:
if !inner_ovf (just set that to false if !check_inner_ovf to simplify
checks please).
you know it's
On Wed, 14 Sep 2016, Moritz Klammler wrote:
> be cleaner to only include those checksums that are actually needed. On
> the other hand, it means an increased maintenance burden each time the
> version of the dependency is changed. In order to mitigate this and
I really don't see it as an
On Wed, Sep 14, 2016 at 10:28 AM, Jonathan Wakely wrote:
> On 14/09/16 09:09 -0700, Cong Wang wrote:
>>
>> On Wed, Sep 14, 2016 at 4:06 AM, Jonathan Wakely
>> wrote:
>>>
>>> If I understand the purpose of the change correctly, it's similar to
>>>
On 09/14/16 19:40, Steve Kargl wrote:
> On Wed, Sep 14, 2016 at 04:10:46PM +, Bernd Edlinger wrote:
>>
>> fortran:
>> 2016-09-14 Bernd Edlinger
>>
>> PR c++/77434
>> * simplify.c (gfc_simplify_repeat): Fix a warning.
>>
>> Index: gcc/fortran/simplify.c
On 09/14/2016 07:04 AM, Segher Boessenkool wrote:
I'd
probably start by fixing the dataflow issues and see if that fixes the
regrename thing as a side effect.
Have you seen https://gcc.gnu.org/ml/gcc-patches/2016-07/msg00091.html ?
I missed it. My interpretation
The uses at each
On 14/09/16 14:45, Jakub Jelinek wrote:
> I think for the middle-end, using strchr (a, 0) as canonical instead of a +
> strlen (a)
> is better, and at expansion time we can decide what to use (a + strlen (a)
> if you'd expand strlen inline, rather than as a function call, or
> __rawmemchr (which
OK, thanks.
On Wed, Sep 14, 2016 at 11:28 AM, Marek Polacek wrote:
> On Tue, Sep 13, 2016 at 11:37:20PM -0400, Jason Merrill wrote:
>> On Tue, Sep 13, 2016 at 3:55 PM, Martin Sebor wrote:
>> > Having said all that, since this is C++ the message could and
>>
On Wed, Sep 14, 2016 at 12:08 PM, Christophe Lyon
wrote:
> On 14 September 2016 at 14:11, Andreas Schwab wrote:
>> On Sep 13 2016, Jason Merrill wrote:
>>
>>> On Tue, Sep 13, 2016 at 9:03 AM, Andreas Schwab
On Wed, Sep 14, 2016 at 04:10:46PM +, Bernd Edlinger wrote:
>
> fortran:
> 2016-09-14 Bernd Edlinger
>
> PR c++/77434
> * simplify.c (gfc_simplify_repeat): Fix a warning.
>
> Index: gcc/fortran/simplify.c
>
On Wed, 14 Sep 2016, Moritz Klammler wrote:
> Ok, I didn't know about the workflow. Do you think I should dike the
> `--strip-sums` option out again then?
I don't see any use for such an option. Anyone changing the versions
should always have a copy of the new tarball (obtained securely if
On 09/14/2016 08:01 AM, Bernd Schmidt wrote:
On 09/14/2016 03:55 PM, Segher Boessenkool wrote:
On Wed, Sep 14, 2016 at 03:08:21PM +0200, Bernd Schmidt wrote:
The data that was posted showed a code size decrease on a number of
targets. I'm really not sure where this irrational hate for
On 09/14/2016 01:03 PM, Segher Boessenkool wrote:
(There is no return insn at those exits; these are exits *without*
successor block, not the exit block).
Hmm, I thought these were return blocks, but you're saying they're
no-return blocks? I missed that.
In that case, aren't the restores
From: Trevor Saunders
gcc/ChangeLog:
2016-09-13 Trevor Saunders
* emit-rtl.c (next_nonnote_insn): Change argument type to
rtx_insn *.
(prev_nonnote_insn): Likewise.
* jump.c
From: Trevor Saunders
gcc/ChangeLog:
2016-09-06 Trevor Saunders
* config/arc/arc-protos.h (arc_label_align): Change type of
variables from rtx to rtx_insn *.
* config/arc/arc.c (arc_label_align): Likewise.
From: Trevor Saunders
gcc/ChangeLog:
2016-09-13 Trevor Saunders
* emit-rtl.c (next_nondebug_insn): Change argument type to
rtx_insn *.
(prev_nondebug_insn): Likewise.
* loop-doloop.c
This patch allows the -mabi=n32 and -mabi=64 options to
automatically infer the of a 64-bit architecture in the mips-mti-*
and mips-img-* triplets. The default 64-bit architecture is
mips64r2 for MTI and mips64r6 for IMG.
Thanks,
Matthew
gcc/
* config.gcc (mips*-mti-elf*,
From: Trevor Saunders
gcc/ChangeLog:
2016-09-14 Trevor Saunders
* config/cris/cris.c (cris_asm_output_case_end): Change argument
type to rtx_insn *.
* emit-rtl.c (next_nonnote_nondebug_insn): Likewise.
From: Trevor Saunders
gcc/ChangeLog:
2016-09-14 Trevor Saunders
* emit-rtl.c (next_cc0_user): Make argument type rtx_insn *.
* rtl.h: Adjust prototype.
---
gcc/emit-rtl.c | 4 +---
gcc/rtl.h | 2 +-
2 files changed,
On 09/14/2016 01:03 PM, Segher Boessenkool wrote:
If you think about it, conceptually we want the return insn to make the
callee saved registers "used" so that DCE, regrename and friends don't
muck with them. The fact that we don't is as much never having to care
all that much until recently.
From: Trevor Saunders
gcc/ChangeLog:
2016-09-13 Trevor Saunders
* emit-rtl.c (prev_real_insn): Change argument type to rtx_insn *.
* rtl.h: Adjust prototype.
* config/sh/sh.md: Adjust.
* dwarf2out.c
From: Trevor Saunders
gcc/ChangeLog:
2016-09-14 Trevor Saunders
* emit-rtl.c (next_active_insn): Change argument type to
rtx_insn *.
(prev_active_insn): Likewise.
(active_insn_p): Likewise.
*
On Wed, Sep 14, 2016 at 12:11:50PM -0600, Jeff Law wrote:
> On 09/14/2016 07:04 AM, Segher Boessenkool wrote:
> >>I'd
> >>probably start by fixing the dataflow issues and see if that fixes the
> >>regrename thing as a side effect.
> >
> >Have you seen
On Wed, Sep 14, 2016 at 11:52:02AM -0600, Jeff Law wrote:
> Yea, it'll certainly do that and I can imagine a design which would have
> that property. And there's other designs which benefit from spreading
> across the register file as much as possible.
>
> Which argues there needs to be a way
On 09/14/2016 01:10 PM, Segher Boessenkool wrote:
On Wed, Sep 14, 2016 at 11:52:02AM -0600, Jeff Law wrote:
Yea, it'll certainly do that and I can imagine a design which would have
that property. And there's other designs which benefit from spreading
across the register file as much as
From: Trevor Saunders
Hi,
Basically $subject. First change variable's type to rtx_insn * where possible.
Then change the functions and fixup callers where it is still necessary to
cast.
patches bootstrapped and regtested individually on x86_64-linux-gnu, and the
From: Trevor Saunders
gcc/ChangeLog:
2016-09-06 Trevor Saunders
* bb-reorder.c (fix_crossing_unconditional_branches): Make type
of jump_insn rtx_jump_insn *.
* reorg.c (steal_delay_list_from_target): Make type of
... resent, because message apparently bounced.
On 09/14/16 21:22, Bernd Edlinger wrote:
> On 09/14/16 20:11, Jason Merrill wrote:
>>>
>>> Yes. The reasoning I initially had was that it is completely
>>> pointless to have something of the form "if (x ? 1 : 2)" or
>>> "if (x ? 0 : 0)" because the
On 14/09/2016 11:00, Jonathan Wakely wrote:
On 13/09/16 22:37 +0200, François Dumont wrote:
Hi
When I proposed to change std::hash for pointers my plan was to
use this approach for the debug containers. So here is the patch
leveraging on this technique to avoid going through _Hash_impl to
This patch fixes a typo in libgo/configure.ac (PCQUANTUm ->
PCQUANTUM). Bootstrapped on x86_64-pc-linux-gnu. Committed to
mainline.
Ian
Index: gcc/go/gofrontend/MERGE
===
--- gcc/go/gofrontend/MERGE (revision 240083)
+++
> + /* Visit PHI stmts and discover any new VRs possible. */
> + gimple_stmt_iterator gsi;
> + for (gphi_iterator gpi = gsi_start_phis (bb);
> + !gsi_end_p (gpi); gsi_next ())
> +{
> + gphi *phi = gpi.phi ();
> + tree lhs = PHI_RESULT (phi);
> + value_range vr_result =
On Sep 14, 2016, at 1:19 PM, Moritz Klammler wrote:
>
> Joseph Myers writes:
>
>> On Wed, 14 Sep 2016, Moritz Klammler wrote:
>>
>>> Ok, I didn't know about the workflow. Do you think I should dike the
>>> `--strip-sums` option out again then?
>>
The attached patch appears to fix PR fortran/77420 without
causing regressions. The problem raised by Andrew Benson at
https://gcc.gnu.org/ml/fortran/2016-09/msg00039.html
contained in pr77420_3.f90 and pr77420_4.f90. The original
testcase from the PR is in pr77420_1.f90 and a variation
on that
Joseph Myers writes:
> On Wed, 14 Sep 2016, Moritz Klammler wrote:
>
>> Ok, I didn't know about the workflow. Do you think I should dike the
>> `--strip-sums` option out again then?
>
> I don't see any use for such an option. Anyone changing the versions
> should
On Thu, Sep 08, 2016 at 08:30:47PM -0400, David Malcolm wrote:
> We have a lot of global state in our code. Ideally we'd reduce the
> amount of such global state, but a prerequisite for sane refactoring
> is having automated testing in place to ensure that the refactoring
> doesn't break
On Thu, Sep 8, 2016 at 5:29 AM, Kugan Vivekanandarajah
wrote:
> Hi Richard,
>
> On 7 September 2016 at 19:35, Richard Biener
> wrote:
>> On Wed, Sep 7, 2016 at 2:21 AM, Kugan Vivekanandarajah
>>
On Thu, Sep 8, 2016 at 1:43 PM, Thomas Schwinge wrote:
> Hi!
>
> On Wed, 7 Sep 2016 14:23:18 +0200, Richard Biener
> wrote:
>> On Wed, Sep 7, 2016 at 1:52 PM, Thomas Schwinge
>> wrote:
>> > I trimmed the CC list --
On 09/13/2016 01:15 PM, Bernd Schmidt wrote:
On 09/12/2016 08:57 PM, David Malcolm wrote:
I'm not sure I follow - this sounds like a dedicated target for
selftesting.
Would it be a separate configuration i.e. something like:
../src/configure --target=rtl-selftest
or somesuch?
The way I
On Sat, Sep 10, 2016 at 8:04 AM, Yuan, Pengfei wrote:
> Hi,
>
> Previously I have sent a patch on profile based option tuning:
> https://gcc.gnu.org/ml/gcc-patches/2014-07/msg01377.html
>
> According to Richard Biener's advice, I try investigating where the code size
> reduction
On 06/09/16 22:26 +0200, François Dumont wrote:
Hi
Any final decision regarding this patch ?
Note that __std_a namespace is optional, I can remove this change
from the patch if you want.
Can you describe what difference that would make? Would it avoid all
the changes to Parallel Mode?
1 - 100 of 125 matches
Mail list logo