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 ad
prepare_call_address in calls.c is the wrong place to handle -fno-plt.
We shoudn't force function address into register and hope that load
function address via GOT and indirect call via register will be folded
into indirect call via GOT, which doesn't always happen. Also non-PIC
case can only be h
On Mon, Aug 17, 2015 at 10:17:00AM -0700, H.J. Lu wrote:
> On Mon, Aug 17, 2015 at 10:08 AM, Alexander Monakov
> wrote:
> >> >> Perhaps add a comment that GOT slots are 64-bit on x32?
> >> >>
> >> >
> >> > Good idea. I will update my patch.
> >> >
> >>
> >> How about this?
> >>
> >>
> >> diff --
On Mon, Aug 17, 2015 at 10:08 AM, Alexander Monakov wrote:
>> >> Perhaps add a comment that GOT slots are 64-bit on x32?
>> >>
>> >
>> > Good idea. I will update my patch.
>> >
>>
>> How about this?
>>
>>
>> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
>> index bf8a21d..216dee6 10
> >> Perhaps add a comment that GOT slots are 64-bit on x32?
> >>
> >
> > Good idea. I will update my patch.
> >
>
> How about this?
>
>
> diff --git a/gcc/config/i386/i386.c b/gcc/config/i386/i386.c
> index bf8a21d..216dee6 100644
> --- a/gcc/config/i386/i386.c
> +++ b/gcc/config/i386/i386.c
>
On Sun, Aug 16, 2015 at 12:39 PM, H.J. Lu wrote:
> On Sun, Aug 16, 2015 at 12:24 PM, Alexander Monakov
> wrote:
>
>>> + if (!TARGET_64BIT
>>> + || (ix86_cmodel == CM_LARGE_PIC
>>> + && DEFAULT_ABI != MS_ABI))
>>> + {
>>> + use_r
On Sun, Aug 16, 2015 at 12:24 PM, Alexander Monakov wrote:
> On Sun, 16 Aug 2015, H.J. Lu wrote:
>
>> prepare_call_address in calls.c is the wrong place to handle -fno-plt.
>> We shoudn't force function address into register and hope that load
>> function address via GOT and indirect call via regi
On Sun, 16 Aug 2015, H.J. Lu wrote:
> prepare_call_address in calls.c is the wrong place to handle -fno-plt.
> We shoudn't force function address into register and hope that load
> function address via GOT and indirect call via register will be folded
> into indirect call via GOT, which doesn't al
prepare_call_address in calls.c is the wrong place to handle -fno-plt.
We shoudn't force function address into register and hope that load
function address via GOT and indirect call via register will be folded
into indirect call via GOT, which doesn't always happen. Allso non-PIC
case can only be
39 matches
Mail list logo
