On September 14, 2016 11:36:16 PM GMT+02:00, Jan Hubicka wrote:
>> + /* 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 (&gpi))
>> +{
>> + gphi *phi = gpi.phi
Trevor Saunders wrote:
>> This hunk results several new failures for tree-profile tests on SH.
>> If the line "if (JUMP_P (cur_insn))" is restored, those failures
>> go away.
>
> That's interesting because dyn_cast should include that check. What is
> the error?
Here is a typical log:
spawn -i
On Thu, Sep 15, 2016 at 01:04:04PM +0900, Kaz Kojima wrote:
> tbsaunde+...@tbsaunde.org wrote:
> > @@ -2201,8 +2201,7 @@ fix_crossing_unconditional_branches (void)
> > {
> > if (!BARRIER_P (cur_insn))
> > BLOCK_FOR_INSN (cur_insn) = cur_bb;
> > -
tbsaunde+...@tbsaunde.org wrote:
> @@ -2201,8 +2201,7 @@ fix_crossing_unconditional_branches (void)
> {
> if (!BARRIER_P (cur_insn))
> BLOCK_FOR_INSN (cur_insn) = cur_bb;
> - if (JUMP_P (cur_insn))
> - jump_insn = cur_ins
On 14 September 2016 at 18:54, Richard Biener
wrote:
> 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
wrote:
>
On 09/14/2016 02:49 PM, Steve Kargl wrote:
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
> I think the approach is reasonable though it might still have
> interesting effects on
> optimization for very small growth. So for further experimenting it
> would be nice
Test it on SPEC CPU with FDO enabled?
> to have a separate PARAM_EARLY_FDO_INLINING_INSNS or maybe simply
> adjust the PA
Richard Sandiford writes:
> Prathamesh Kulkarni writes:
>> Hi,
>> I would like to ping the following patch:
>> https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01015.html
>>
>> While implementing divmod transform:
>> https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01757.html
>>
>> I ran into an issue
Prathamesh Kulkarni writes:
> Hi,
> I would like to ping the following patch:
> https://gcc.gnu.org/ml/gcc-patches/2016-08/msg01015.html
>
> While implementing divmod transform:
> https://gcc.gnu.org/ml/gcc-patches/2016-05/msg01757.html
>
> I ran into an issue with optab_libfunc().
> It appears o
On Wed, Sep 14, 2016 at 01:35:57PM -0600, Jeff Law wrote:
> 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
On Wed, Sep 14, 2016 at 01:33:04PM -0600, Jeff Law wrote:
> 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
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 anything.
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 t
Hi!
I'd like to ping a couple of patches:
C++
===
http://gcc.gnu.org/ml/gcc-patches/2016-08/msg01995.html
- PR77375 - wrong-code with mutable members in base classes
http://gcc.gnu.org/ml/gcc-patches/2016-08/msg01998.html
- PR77338 - fix constexpr ICE on PARM_DECL with incomplete type
http
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?
>>
>> I don't see any use for such an option. A
> + /* 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 (&gpi))
> +{
> + gphi *phi = gpi.phi ();
> + tree lhs = PHI_RESULT (phi);
> + value_range vr_resul
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)
+++ gcc/go/
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 always have a copy of the new
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 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*, mips*-mti-linux*
... 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 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 dea
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.
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 possible
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 (add_var_loc_to_decl): Likewise.
---
gcc/config/sh/sh.md | 3
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.
* rtl.h: Adjust prototypes.
* cfgcleanup.c (merge_bloc
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, 2 insertions(+), 4 deletions(-)
diff --git a/gcc/emit
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.
(prev_nonnote_nondebug_insn): Likewise.
* config/cris/cris
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 (reversed_comparison_code_parts): Likewise.
(reversed_comparison): 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 (doloop_condition_get): Likewise.
* rtl.h: Adjust prototype.
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.
* config/arm/arm.c (any_sibcall_could_use_r3): Likewis
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 insn
rtx_jump_insn *.
(follow_jumps): M
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
series was run through config-l
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 t
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 https://gcc.gnu.org/ml/gcc-patches/2016-07/msg0
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 regrename
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:
>>>
>>> ../../gcc-trunk/gcc/dwarf2out.c:26166:35: error: ?: using integ
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 "strange
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
po
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))
>> > {
>> > + /* OVERLOADs or decls from
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
>>> https://gcc.gnu.org/ml/gcc-patches/2014-06/msg0027
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: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 a
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
> ===
>
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
>> > arguably should refer to a bool expr
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 [-Werror=int-in-bool-context
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 to mitigate this and
>
> I
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
performance when strin
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 increa
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 (unroll_loop_runtime_iter
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 i
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
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 lots of miscellaneous files should be
>> included, just t
[ 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 valid to transform the op
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 to be vectorized like
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 (s->refcount
>== ((DEBUG_STR_S
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 Nathan could
> give t
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
>>> wrote:
On Sep 13 2016, Jason Merrill wrote:
> Does this help?
>
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 wh
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
+++ ../../src/gcc/testsuite/c-c++-common/fix-mi
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 e
ples which 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 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() is on the hot path.
>>
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 this help?
>>>
>>> Unfortunatly no.
>>
>> It occurs to me that this function doesn't
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 with this altogether
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
> > (cp_build_una
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
> instead
>
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
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.
(save_fundef_copy): Always
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 acti
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;
+ u
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
> targe
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 p
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 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 bootstrapping/testing the patch that makes it
possible to
write all this in match.pd.
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 block
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
>> 25_algorithms/lower_bound/debug/irreflexive.cc
>> is now UNS
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 the git branch with th
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 y
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 i
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
>>> wrote:
On Mon, Aug 22, 2016 at 8:40 PM, Prasad Ghangal
wrote:
>>
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 (prologue_epilogue_cont
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 false instead of 0.
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:
>
>preheader:
> LOOP:
>
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 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
>> (https://gcc.gnu.org/ml/libstdc++/2
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 == PREDECREMENT_EXPR
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 fr
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 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
> regrenam
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 you should check and
>> wh
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, 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 dash, but
> >> otherw
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 fo
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 way to write the o
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
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 previous testcases include
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 14:02, Mark Wielaard wrote:
> -Wshadow-local which warns if a local variable shad
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 restrict types at
> all. I'm checking this in; hopefully it
1 - 100 of 124 matches
Mail list logo
