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
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: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
... 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
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*
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
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
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/
> + /* 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
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
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
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
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.
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 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
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
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
> 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
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
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:
>
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 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;
> > -
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 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
101 - 124 of 124 matches
Mail list logo
