On Wed, 28 Oct 2015 at 18:14 PM, H.J. Lu wrote:
> On Wed, Oct 28, 2015 at 6:11 PM, Bernd Schmidt wrote:
>> On 10/29/2015 02:10 AM, H.J. Lu wrote:
>>>
>>> On Wed, Oct 28, 2015 at 5:23 PM, Jeff Law wrote:
So I'll ask again, why did you commit a patch which you clearly knew did
n
On 10/29/2015 03:25 AM, Ramana Radhakrishnan wrote:
Actually this is even worse than I thought because it sounds like you're
saying you knowingly checked something in while being aware it would break
another port.
Only when -fno-plt was used.
So, that's a target independent feature in GCC !
On 10/28/2015 07:14 PM, H.J. Lu wrote:
On Wed, Oct 28, 2015 at 6:11 PM, Bernd Schmidt wrote:
On 10/29/2015 02:10 AM, H.J. Lu wrote:
On Wed, Oct 28, 2015 at 5:23 PM, Jeff Law wrote:
So I'll ask again, why did you commit a patch which you clearly knew did
not
meet the conditions Bernd set f
On 10/28/2015 07:10 PM, H.J. Lu wrote:
You didn't answer my question.
I asked why you committed a patch given it didn't meet the conditions Bernd
set forth for approval. I didn't ask anything about the bug itself.
So I'll ask again, why did you commit a patch which you clearly knew did not
me
On 29/10/15 01:47, H.J. Lu wrote:
> On Wed, Oct 28, 2015 at 6:21 PM, Bernd Schmidt wrote:
>> On 10/29/2015 02:14 AM, H.J. Lu wrote:
>>>
>>> On Wed, Oct 28, 2015 at 6:11 PM, Bernd Schmidt
>>> wrote:
On 10/29/2015 02:10 AM, H.J. Lu wrote:
>
>
> On Wed, Oct 28, 2015 at 5:23 P
On Wed, Oct 28, 2015 at 6:21 PM, Bernd Schmidt wrote:
> On 10/29/2015 02:14 AM, H.J. Lu wrote:
>>
>> On Wed, Oct 28, 2015 at 6:11 PM, Bernd Schmidt
>> wrote:
>>>
>>> On 10/29/2015 02:10 AM, H.J. Lu wrote:
On Wed, Oct 28, 2015 at 5:23 PM, Jeff Law wrote:
>
>
>
> So
On 10/29/2015 02:14 AM, H.J. Lu wrote:
On Wed, Oct 28, 2015 at 6:11 PM, Bernd Schmidt wrote:
On 10/29/2015 02:10 AM, H.J. Lu wrote:
On Wed, Oct 28, 2015 at 5:23 PM, Jeff Law wrote:
So I'll ask again, why did you commit a patch which you clearly knew did
not
meet the conditions Bernd set f
On Wed, Oct 28, 2015 at 6:11 PM, Bernd Schmidt wrote:
> On 10/29/2015 02:10 AM, H.J. Lu wrote:
>>
>> On Wed, Oct 28, 2015 at 5:23 PM, Jeff Law wrote:
>>>
>>>
>>> So I'll ask again, why did you commit a patch which you clearly knew did
>>> not
>>> meet the conditions Bernd set forth for approval?
On 10/29/2015 02:10 AM, H.J. Lu wrote:
On Wed, Oct 28, 2015 at 5:23 PM, Jeff Law wrote:
So I'll ask again, why did you commit a patch which you clearly knew did not
meet the conditions Bernd set forth for approval?
I believed that aarch64 backend didn't properly handle -fno-plt,
which should
On Wed, Oct 28, 2015 at 5:23 PM, Jeff Law wrote:
> On 10/27/2015 12:54 PM, H.J. Lu wrote:
HJ, Thanks for committing the change even when we were discussing the
change
>>>
>>>
>>> This is what I'm primarily concerned about.
>>>
>>> Bernd's message was pretty clear in my mind:
>>>
>>>
On 10/27/2015 12:54 PM, H.J. Lu wrote:
HJ, Thanks for committing the change even when we were discussing the
change
This is what I'm primarily concerned about.
Bernd's message was pretty clear in my mind:
https://gcc.gnu.org/ml/gcc-patches/2015-10/msg02861.html
It was conditional approval ba
>
> This thread seems destined to cause typos and finger slips...
>
> if (!REG_P (callee)
> && ((GET_CODE (callee) != SYMBOL_REF)
>|| aarch64_is_noplt_call_p (callee)))
>
> Obviously :).
Sigh, Yeah it is one of those patches. Applied to trunk with the changes.
Ramana
On Wed, Oct 28, 2015 at 11:01:15AM +, James Greenhalgh wrote:
> On Wed, Oct 28, 2015 at 10:13:07AM +, Ramana Radhakrishnan wrote:
> >
> >
> > On 27/10/15 20:57, Jeff Law wrote:
> > >> a
> > >>
> > >> * config/aarch64/aarch64.md (call, call_value): Handle noplt.
> > > FWIW -ENOPATCH.
> > >
On Wed, Oct 28, 2015 at 10:13:07AM +, Ramana Radhakrishnan wrote:
>
>
> On 27/10/15 20:57, Jeff Law wrote:
> >> a
> >>
> >> * config/aarch64/aarch64.md (call, call_value): Handle noplt.
> > FWIW -ENOPATCH.
> >
> > jeff
>
>
> Bah - finger trouble. Sorry about that. Here it is and also handl
On 27/10/15 20:57, Jeff Law wrote:
>> a
>>
>> * config/aarch64/aarch64.md (call, call_value): Handle noplt.
> FWIW -ENOPATCH.
>
> jeff
Bah - finger trouble. Sorry about that. Here it is and also handling sibcall
patterns. Tested aarch64-none-elf with no regressions.
2015-10-28 Ramana Radh
On 10/27/2015 09:42 AM, Ramana Radhakrishnan wrote:
On 27/10/15 14:50, H.J. Lu wrote:
On Tue, Oct 27, 2015 at 7:34 AM, Ramana Radhakrishnan
wrote:
OK, then it's fairly x86-64 specific optimization, because we can't do "call
*mem" in
aarch64 and some other targets.
It is a fairly x86_64
On Tue, Oct 27, 2015 at 10:44 AM, Jeff Law wrote:
> On 10/27/2015 09:42 AM, Ramana Radhakrishnan wrote:
>>
>>
>>
>> On 27/10/15 14:50, H.J. Lu wrote:
>>>
>>> On Tue, Oct 27, 2015 at 7:34 AM, Ramana Radhakrishnan
>>> wrote:
>
> OK, then it's fairly x86-64 specific optimization, b
On 10/27/2015 09:26 AM, Jiong Wang wrote:
On 27/10/15 14:50, H.J. Lu wrote:
On Tue, Oct 27, 2015 at 7:34 AM, Ramana Radhakrishnan
wrote:
OK, then it's fairly x86-64 specific optimization, because we can't
do "call *mem" in
aarch64 and some other targets.
It is a fairly x86_64 specific optim
On 10/27/2015 09:42 AM, Ramana Radhakrishnan wrote:
On 27/10/15 14:50, H.J. Lu wrote:
On Tue, Oct 27, 2015 at 7:34 AM, Ramana Radhakrishnan
wrote:
OK, then it's fairly x86-64 specific optimization, because we can't do "call
*mem" in
aarch64 and some other targets.
It is a fairly x86_64
On 27/10/15 14:50, H.J. Lu wrote:
> On Tue, Oct 27, 2015 at 7:34 AM, Ramana Radhakrishnan
> wrote:
>>
>>>
>>> OK, then it's fairly x86-64 specific optimization, because we can't do
>>> "call *mem" in
>>> aarch64 and some other targets.
>>
>> It is a fairly x86_64 specific optimization and doesn
On Tue, Oct 27, 2015 at 8:26 AM, Jiong Wang wrote:
>
>
> On 27/10/15 14:50, H.J. Lu wrote:
>>
>> On Tue, Oct 27, 2015 at 7:34 AM, Ramana Radhakrishnan
>> wrote:
OK, then it's fairly x86-64 specific optimization, because we can't do
"call *mem" in
aarch64 and some other targets
On 27/10/15 14:50, H.J. Lu wrote:
On Tue, Oct 27, 2015 at 7:34 AM, Ramana Radhakrishnan
wrote:
OK, then it's fairly x86-64 specific optimization, because we can't do "call
*mem" in
aarch64 and some other targets.
It is a fairly x86_64 specific optimization and doesn't apply to AArch64.
The
On Tue, Oct 27, 2015 at 7:34 AM, Ramana Radhakrishnan
wrote:
>
>>
>> OK, then it's fairly x86-64 specific optimization, because we can't do "call
>> *mem" in
>> aarch64 and some other targets.
>
> It is a fairly x86_64 specific optimization and doesn't apply to AArch64.
>
> The question really is
>
> OK, then it's fairly x86-64 specific optimization, because we can't do "call
> *mem" in
> aarch64 and some other targets.
It is a fairly x86_64 specific optimization and doesn't apply to AArch64.
The question really is what impact does removing the generic code handling have
on aarch64 -
On 27/10/15 13:06, H.J. Lu wrote:
On Tue, Oct 27, 2015 at 5:52 AM, Jiong Wang wrote:
On 27/10/15 11:37, H.J. Lu wrote:
On Tue, Oct 27, 2015 at 4:20 AM, Bernd Schmidt
wrote:
On 10/19/2015 09:55 PM, H.J. Lu wrote:
* calls.c (prepare_call_address): Don't handle -fno-plt here.
I
On Tue, Oct 27, 2015 at 5:52 AM, Jiong Wang wrote:
>
>
> On 27/10/15 11:37, H.J. Lu wrote:
>>
>> On Tue, Oct 27, 2015 at 4:20 AM, Bernd Schmidt
>> wrote:
>>>
>>> On 10/19/2015 09:55 PM, H.J. Lu wrote:
* calls.c (prepare_call_address): Don't handle -fno-plt here.
>>>
>>>
>>> Is
On 27/10/15 11:37, H.J. Lu wrote:
On Tue, Oct 27, 2015 at 4:20 AM, Bernd Schmidt wrote:
On 10/19/2015 09:55 PM, H.J. Lu wrote:
* calls.c (prepare_call_address): Don't handle -fno-plt here.
Is any other target using -fno-plt? If not, and if that's really just a
aarch64 is the onl
On Tue, Oct 27, 2015 at 12:37 PM, H.J. Lu wrote:
> On Tue, Oct 27, 2015 at 4:20 AM, Bernd Schmidt wrote:
>> On 10/19/2015 09:55 PM, H.J. Lu wrote:
>>>
>>> * calls.c (prepare_call_address): Don't handle -fno-plt here.
>>
>>
>> Is any other target using -fno-plt? If not, and if that's real
On Tue, Oct 27, 2015 at 4:20 AM, Bernd Schmidt wrote:
> On 10/19/2015 09:55 PM, H.J. Lu wrote:
>>
>> * calls.c (prepare_call_address): Don't handle -fno-plt here.
>
>
> Is any other target using -fno-plt? If not, and if that's really just a
aarch64 is the only target which checks -fno-pl
On 10/19/2015 09:55 PM, H.J. Lu wrote:
* calls.c (prepare_call_address): Don't handle -fno-plt here.
Is any other target using -fno-plt? If not, and if that's really just a
revert I'll approve it on the condition that the x86 maintainers are
happy with the rest of the changes.
Your
-- Forwarded message --
From: H.J. Lu
Date: Wed, Sep 9, 2015 at 3:02 PM
Subject: [PATCH] PR target/67215: -fno-plt needs improvements for x86
To: gcc-patches@gcc.gnu.org
prepare_call_address in calls.c is the wrong place to handle -fno-plt.
We shoudn't force function address into
31 matches
Mail list logo
