Feel free to edit the hook scripts to do this.
On Sat, Sep 6, 2008 at 1:26 PM, Joseph S. Myers <[EMAIL PROTECTED]> wrote:
> On Sat, 6 Sep 2008, Manuel López-Ibáñez wrote:
>
>> Well, that is a property change and it is surprising that the log
>> shows the diff of the change. Normally logs only sho
H.J. Lu wrote:
On Sat, Sep 6, 2008 at 11:24 AM, Luis Machado
<[EMAIL PROTECTED]> wrote:
On Sat, 2008-09-06 at 07:49 -0700, H.J. Lu wrote:
On Sat, Sep 6, 2008 at 7:05 AM, Luis Machado <[EMAIL PROTECTED]> wrote:
On Fri, 2008-09-05 at 10:34 -0700, H.J. Lu wrote:
On Fri, S
On Sat, Sep 6, 2008 at 11:24 AM, Luis Machado
<[EMAIL PROTECTED]> wrote:
>
> On Sat, 2008-09-06 at 07:49 -0700, H.J. Lu wrote:
>> On Sat, Sep 6, 2008 at 7:05 AM, Luis Machado <[EMAIL PROTECTED]> wrote:
>> >
>> > On Fri, 2008-09-05 at 10:34 -0700, H.J. Lu wrote:
>> >> On Fri, Sep 5, 2008 at 10:24 AM
On Sat, 2008-09-06 at 07:49 -0700, H.J. Lu wrote:
> On Sat, Sep 6, 2008 at 7:05 AM, Luis Machado <[EMAIL PROTECTED]> wrote:
> >
> > On Fri, 2008-09-05 at 10:34 -0700, H.J. Lu wrote:
> >> On Fri, Sep 5, 2008 at 10:24 AM, Vladimir Makarov <[EMAIL PROTECTED]>
> >> wrote:
> >> >
> >> > H.J. Lu keeps
On Sat, 6 Sep 2008, Manuel López-Ibáñez wrote:
> Well, that is a property change and it is surprising that the log
> shows the diff of the change. Normally logs only show what has been
> changed but not the diff. Neither John, nor I expected this behaviour.
Changes to *revision* properties delibe
On Sat, Sep 6, 2008 at 8:30 AM, Andreas Tobler <[EMAIL PROTECTED]> wrote:
> H.J. Lu wrote:
>>
>> On Fri, Sep 5, 2008 at 2:57 PM, Andreas Tobler <[EMAIL PROTECTED]>
>> wrote:
>>>
>>> H.J. Lu wrote:
>>>
>> It is a temporary branch, branches/ira-merge, to track
>> IRA related problems.
>>
H.J. Lu wrote:
On Fri, Sep 5, 2008 at 2:57 PM, Andreas Tobler <[EMAIL PROTECTED]> wrote:
H.J. Lu wrote:
It is a temporary branch, branches/ira-merge, to track
IRA related problems.
Same issue.
Does trunk bootstrap with revision 139589?
No, gcc version 4.4.0 20080905 (experimental) [trunk
On Sat, Sep 6, 2008 at 7:05 AM, Luis Machado <[EMAIL PROTECTED]> wrote:
>
> On Fri, 2008-09-05 at 10:34 -0700, H.J. Lu wrote:
>> On Fri, Sep 5, 2008 at 10:24 AM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>> >
>> > H.J. Lu keeps ira-branch merge more fresh than trunk. But the lag is only
>>
>> I
On Sat, Sep 6, 2008 at 12:47 AM, Richard Sandiford
<[EMAIL PROTECTED]> wrote:
> "H.J. Lu" <[EMAIL PROTECTED]> writes:
>> On Fri, Sep 5, 2008 at 10:24 AM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>>> 1-3 days usually because gcc community and RA reviewers are very responsive.
>>> So I don't see
On Fri, 2008-09-05 at 10:34 -0700, H.J. Lu wrote:
> On Fri, Sep 5, 2008 at 10:24 AM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
> >
> > H.J. Lu keeps ira-branch merge more fresh than trunk. But the lag is only
>
> I won't apply any non-IRA related patches to ira-merge branch so
> that you can g
>> In case of cris, the predicate goes into general_operand, which does
>>
>> if (CONSTANT_P (op))
>> return ((GET_MODE (op) == VOIDmode || GET_MODE (op) == mode
>> || mode == VOIDmode)
>> && (! flag_pic || LEGITIMATE_PIC_OPERAND_P (op))
>> && LEGITIMATE_
> Date: Sat, 06 Sep 2008 12:50:18 +0200
> From: Paolo Bonzini <[EMAIL PROTECTED]>
> Still, having a new target hook for this seems overkill.
But it's better than abusing an old macro with a slightly
different use.
> For example,
> since ports do have to deal with complicated constants when they
> if plus_constant _knows_ that something can be wrapped in a CONST,
> simplify_binary_operation should have given us the CONST to begin with.
> Also, the only cases that plus_constant can handle are CONST,
> SYMBOL_REF and LABEL_REF, all of which satisfy CONSTANT_P.
> So the new form ought to be
2008/9/6 Christopher Faylor <[EMAIL PROTECTED]>:
>
>--- svn:log (original)
>+++ svn:log Fri Sep 5 14:39:56 2008
>@@ -1,19740 +1,1 @@
>-Merged revisions
> 136194,136196,136200,136209,136215-136217,136221-136222,1=
>
> 36229,136235-136239,136242,136247,136249,136251-136254,13626
Paolo Bonzini <[EMAIL PROTECTED]> writes:
>> I'm not sure about this bit. Couldn't [snip cse.c code]
>> simply be replaced by:
>>
>> /* We can't simplify extension ops unless we know the
>> original mode. */
>> if ((code == ZERO_EXTEND || code == SIGN_EXTEND)
>>&& mode_a
> I'm not sure about this bit. Couldn't [snip cse.c code]
> simply be replaced by:
>
> /* We can't simplify extension ops unless we know the
>original mode. */
> if ((code == ZERO_EXTEND || code == SIGN_EXTEND)
> && mode_arg0 == VOIDmode)
> break;
>
> new
Paolo Bonzini <[EMAIL PROTECTED]> writes:
> Index: cse.c
> ===
> --- cse.c (revision 134435)
> +++ cse.c (working copy)
> @@ -3161,10 +3161,8 @@ fold_rtx (rtx x, rtx insn)
> FIXME: those ports should be fixed. */
>
Paolo Bonzini wrote:
> Hans-Peter Nilsson wrote:
>>> Date: Fri, 5 Sep 2008 14:57:00 +0200
>>> From: Hans-Peter Nilsson <[EMAIL PROTECTED]>
>>> Maybe as part of a change from target macro to target hook, with
>>> LEGITIMATE_CONSTANT_P as a default would fit, even at this
>>> stage?
>> Sorry, I mean
Hans-Peter Nilsson wrote:
>> Date: Fri, 5 Sep 2008 14:57:00 +0200
>> From: Hans-Peter Nilsson <[EMAIL PROTECTED]>
>
>> Maybe as part of a change from target macro to target hook, with
>> LEGITIMATE_CONSTANT_P as a default would fit, even at this
>> stage?
>
> Sorry, I mean CONSTANT_P, not LEGITIM
"H.J. Lu" <[EMAIL PROTECTED]> writes:
> On Fri, Sep 5, 2008 at 10:24 AM, Vladimir Makarov <[EMAIL PROTECTED]> wrote:
>> 1-3 days usually because gcc community and RA reviewers are very responsive.
>> So I don't see a big difference in using ira-merge and trunk. I'd only
>> recommend to apply patc
20 matches
Mail list logo
