On Mon, Jan 05, 2015 at 10:23:57PM +0100, Jakub Jelinek wrote:
> On Mon, Jan 05, 2015 at 03:16:46PM -0500, John David Anglin wrote:
> > I think there may be one situation after reload that's not handled
> > by the above. frame_read is only used for const calls. What about
> > the situation where
On Mon, Jan 05, 2015 at 03:16:46PM -0500, John David Anglin wrote:
> I think there may be one situation after reload that's not handled
> by the above. frame_read is only used for const calls. What about
> the situation where we have a non const sibcall and the frame pointer
> isn't eliminated?
On 1/5/2015 1:51 PM, Jakub Jelinek wrote:
So isn't the right replacement for the target hook H.J. wanted to add
the HARD_FRAME_POINTER_IS_ARG_POINTER macro?
If argp is not hfp, then the stores through argp are not considered
to be based on the frame pointer, if it is the same thing, such as on PA
On Mon, Jan 05, 2015 at 07:19:33AM -0700, Jeff Law wrote:
> On 01/04/15 10:16, Richard Biener wrote:
> >>>
> >>>But either your new hook or the original fix makes no sense.
> >>
> >>All I want is to restore the old behavior on x86. If the original fix
> >>makes no sense, should it be reverted?
> >
On 01/04/15 10:16, Richard Biener wrote:
But either your new hook or the original fix makes no sense.
All I want is to restore the old behavior on x86. If the original fix
makes no sense, should it be reverted?
I think the original fix is too conservative
Perhaps. Neither John nor I felt i
On January 4, 2015 3:57:07 PM CET, "H.J. Lu" wrote:
>On Sun, Jan 4, 2015 at 3:37 AM, Richard Biener
> wrote:
>> On January 3, 2015 10:48:47 PM CET, "H.J. Lu"
>wrote:
>>>On Sat, Jan 3, 2015 at 12:58 PM, John David Anglin
>>> wrote:
On 2015-01-03, at 3:18 PM, H.J. Lu wrote:
> On Sat,
On Sun, Jan 4, 2015 at 3:37 AM, Richard Biener
wrote:
> On January 3, 2015 10:48:47 PM CET, "H.J. Lu" wrote:
>>On Sat, Jan 3, 2015 at 12:58 PM, John David Anglin
>> wrote:
>>> On 2015-01-03, at 3:18 PM, H.J. Lu wrote:
>>>
On Sat, Jan 3, 2015 at 12:10 PM, John David Anglin
>> wrote:
> On
On January 3, 2015 10:48:47 PM CET, "H.J. Lu" wrote:
>On Sat, Jan 3, 2015 at 12:58 PM, John David Anglin
> wrote:
>> On 2015-01-03, at 3:18 PM, H.J. Lu wrote:
>>
>>> On Sat, Jan 3, 2015 at 12:10 PM, John David Anglin
> wrote:
On 2015-01-03, at 2:48 PM, H.J. Lu wrote:
> On Sat, Jan 3,
On Sat, Jan 3, 2015 at 12:58 PM, John David Anglin wrote:
> On 2015-01-03, at 3:18 PM, H.J. Lu wrote:
>
>> On Sat, Jan 3, 2015 at 12:10 PM, John David Anglin
>> wrote:
>>> On 2015-01-03, at 2:48 PM, H.J. Lu wrote:
>>>
On Sat, Jan 3, 2015 at 9:35 AM, John David Anglin
wrote:
> On W
On 2015-01-03, at 3:18 PM, H.J. Lu wrote:
> On Sat, Jan 3, 2015 at 12:10 PM, John David Anglin
> wrote:
>> On 2015-01-03, at 2:48 PM, H.J. Lu wrote:
>>
>>> On Sat, Jan 3, 2015 at 9:35 AM, John David Anglin
>>> wrote:
On Wed, 31 Dec 2014, H.J. Lu wrote:
> - /* Arguments for
On Sat, Jan 3, 2015 at 12:10 PM, John David Anglin wrote:
> On 2015-01-03, at 2:48 PM, H.J. Lu wrote:
>
>> On Sat, Jan 3, 2015 at 9:35 AM, John David Anglin
>> wrote:
>>> On Wed, 31 Dec 2014, H.J. Lu wrote:
>>>
- /* Arguments for a sibling call that are pushed to memory are passed
On 2015-01-03, at 2:48 PM, H.J. Lu wrote:
> On Sat, Jan 3, 2015 at 9:35 AM, John David Anglin
> wrote:
>> On Wed, 31 Dec 2014, H.J. Lu wrote:
>>
>>> - /* Arguments for a sibling call that are pushed to memory are passed
>>> - using the incoming argument pointer of the current function.
On Sat, Jan 3, 2015 at 9:35 AM, John David Anglin
wrote:
> On Wed, 31 Dec 2014, H.J. Lu wrote:
>
>> - /* Arguments for a sibling call that are pushed to memory are passed
>> - using the incoming argument pointer of the current function. These
>> - may or may not be frame related de
On Wed, 31 Dec 2014, H.J. Lu wrote:
> - /* Arguments for a sibling call that are pushed to memory are passed
> - using the incoming argument pointer of the current function. These
> - may or may not be frame related depending on the target. Since
> - argument pointer related
To fix a wrong code bug on HPPA with sibcall optimization, r219037 changes
DSE to treat sibcall as though it does a wild read. However, it causes
a regression on x86:
FAIL: gcc.dg/pr44194-1.c scan-rtl-dump dse1 "global deletions = (2|3)"
FAIL: gcc.dg/pr44194-1.c scan-rtl-dump-not final "insn[: ][
15 matches
Mail list logo