* [Bug c++/11331] [Regression 3.4] ld: BFD 2.14.90 20030602 internal error
2003-06-26 16:38 [Bug c++/11331] New: [Regression 3.4] ld: BFD 2.14.90 20030602 internal error danglin at gcc dot gnu dot org
@ 2003-06-26 19:49 ` pinskia at physics dot uc dot edu
2003-06-26 20:14 ` dave at hiauly1 dot hia dot nrc dot ca
` (11 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: pinskia at physics dot uc dot edu @ 2003-06-26 19:49 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331
------- Additional Comments From pinskia at physics dot uc dot edu 2003-06-26 19:49 -------
I think this is related to bug 11297 which is for ppc but they look like the same bug. This
is a gcc (and a ld bug since ld has a internal error).
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug c++/11331] [Regression 3.4] ld: BFD 2.14.90 20030602 internal error
2003-06-26 16:38 [Bug c++/11331] New: [Regression 3.4] ld: BFD 2.14.90 20030602 internal error danglin at gcc dot gnu dot org
2003-06-26 19:49 ` [Bug c++/11331] " pinskia at physics dot uc dot edu
@ 2003-06-26 20:14 ` dave at hiauly1 dot hia dot nrc dot ca
2003-06-26 20:32 ` jakub at gcc dot gnu dot org
` (10 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2003-06-26 20:14 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331
------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2003-06-26 20:14 -------
Subject: Re: [Regression 3.4] ld: BFD 2.14.90 20030602 interna
> ------- Additional Comments From pinskia at physics dot uc dot edu
> 2003-06-26 19:49 -------
> I think this is related to bug 11297 which is for ppc but they look like
> the same bug. This
> is a gcc (and a ld bug since ld has a internal error).
Yes, looks like the same bug. I'm in the process of trying to rewrite
pa_asm_output_mi_thunk to work around the problem. If it works, the
thunk code will be improved. However, what we had before was perfectly
functional :(
Dave
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug c++/11331] [Regression 3.4] ld: BFD 2.14.90 20030602 internal error
2003-06-26 16:38 [Bug c++/11331] New: [Regression 3.4] ld: BFD 2.14.90 20030602 internal error danglin at gcc dot gnu dot org
2003-06-26 19:49 ` [Bug c++/11331] " pinskia at physics dot uc dot edu
2003-06-26 20:14 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2003-06-26 20:32 ` jakub at gcc dot gnu dot org
2003-06-27 1:00 ` dave at hiauly1 dot hia dot nrc dot ca
` (9 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu dot org @ 2003-06-26 20:32 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331
------- Additional Comments From jakub at gcc dot gnu dot org 2003-06-26 20:32 -------
Well, if you want to leave current inefficient thunk, I could certainly add
aname = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (function));
DECL_ATTRIBUTES (alias)
= build_tree_list (build_identifier ("alias"),
build_tree_list (NULL,
build_string (strlen (aname) + 1,
aname)));
to make_alias_for_thunk and you can then look up alias attribute in pa_asm_output_thunk and call that instead of the alias. But IMHO it is better
to just optimize the thunks.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug c++/11331] [Regression 3.4] ld: BFD 2.14.90 20030602 internal error
2003-06-26 16:38 [Bug c++/11331] New: [Regression 3.4] ld: BFD 2.14.90 20030602 internal error danglin at gcc dot gnu dot org
` (2 preceding siblings ...)
2003-06-26 20:32 ` jakub at gcc dot gnu dot org
@ 2003-06-27 1:00 ` dave at hiauly1 dot hia dot nrc dot ca
2003-06-27 9:36 ` jakub at gcc dot gnu dot org
` (8 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2003-06-27 1:00 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331
------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2003-06-27 01:00 -------
Subject: Re: [Regression 3.4] ld: BFD 2.14.90 20030602 internal error
> ------- Additional Comments From jakub at gcc dot gnu dot org 2003-06-26 20:32 -------
> Well, if you want to leave current inefficient thunk, I could certainly add
> aname = IDENTIFIER_POINTER (DECL_ASSEMBLER_NAME (function));
> DECL_ATTRIBUTES (alias)
> = build_tree_list (build_identifier ("alias"),
> build_tree_list (NULL,
> build_string (strlen (aname) + 1,
> aname)));
> to make_alias_for_thunk and you can then look up alias attribute in pa_asm_output_thunk and call that instead of the alias. But IMHO it is better
> to just optimize the thunks.
This solution is not optimal on the PA. After a considerable
amount of study, I have concluded that I must request that your patch
be reverted. Placing the thunk in the same linkonce section as the
method will force us to generate a long branch to the method. This
will cause worse code to be generated than now.
Before your patch, it was possible to use a one instruction pc-relative
branch from a thunk when the thunk could be in its own section. If a
long branch was needed, the linker would add automatically a long branch
stub. When you place the thunk into the same linkonce section as the
method, we can no longer be certain that a pc-relative branch will have
the range to reach its target, nor will it be guaranteed that it can reach
a long branch stub.
Placement of thunks before the method is preferable on the PA. This
allows at least twenty thousand thunks before a long branch is needed
to reach the method. With thunks after the method, we might need long
branches from all thunks if the method is large.
It's not clear from your original posting, but it does not appear that
your change actually provided improved code efficiency on x86 and x86_64
where it was tested. If this is beneficial on these and other ports,
then I suggest that some additional define be required to enable
the change so that ports that would prefer the old implementation
would still have that option (I understand that this change also
likely broke the powerpc port).
Dave
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug c++/11331] [Regression 3.4] ld: BFD 2.14.90 20030602 internal error
2003-06-26 16:38 [Bug c++/11331] New: [Regression 3.4] ld: BFD 2.14.90 20030602 internal error danglin at gcc dot gnu dot org
` (3 preceding siblings ...)
2003-06-27 1:00 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2003-06-27 9:36 ` jakub at gcc dot gnu dot org
2003-06-27 16:40 ` dave at hiauly1 dot hia dot nrc dot ca
` (7 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: jakub at gcc dot gnu dot org @ 2003-06-27 9:36 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331
------- Additional Comments From jakub at gcc dot gnu dot org 2003-06-27 09:36 -------
I admit I know nothing about PA assembly, but I find it very surprising
a branch (even if long branch) is more expensive than short branch to .plt
and call through that or load from .got and indirect jump to that.
As to what advantages does it bring on other arches, I'll mention just a few,
others have similar advantages:
ia32, -fpic -O2 before the patch:
movl 4(%esp), %eax
movl (%eax), %ecx
addl -12(%ecx), %eax
movl %eax, 4(%esp)
call .L85
.L85: popl %ecx
addl $_GLOBAL_OFFSET_TABLE_+[.-.L85], %ecx
movl _ZN1CD1Ev@GOT(%ecx), %ecx
jmp *%ecx
ia32, -fpic -O2 after the patch (plus likely one less dynamic relocation):
movl 4(%esp), %eax
movl (%eax), %ecx
addl -12(%ecx), %eax
movl %eax, 4(%esp)
jmp .LTHUNK0
amd64, -fpic -O2 before:
movq (%rdi), %r10
addq -24(%r10), %rdi
jmp *_ZN1CD1Ev@GOTPCREL(%rip)
amd64, -fpic -O2 after:
movq (%rdi), %r10
addq -24(%r10), %rdi
jmp .LTHUNK0
s390, -fPIC -O2 before:
lhi %r1,-12
a %r1,0(%r2)
a %r2,0(%r1)
basr %r1,0
.L96: l %r0,.L97-4-.L96(%r1)
a %r1,.L97-.L96(%r1)
ar %r1,%r0
l %r1,0(%r1)
br %r1
.align 4
.long _ZN1CD1Ev@GOT
.L97: .long _GLOBAL_OFFSET_TABLE_-.L96
s390, -fPIC -O2 after:
lhi %r1,-12
a %r1,0(%r2)
a %r2,0(%r1)
basr %r1,0
.L96: a %r1,.L97-.L96(%r1)
br %r1
.align 4
.L97: .long .LTHUNK0-.L96
s390x, -fpic -O2 before:
lghi %r1,-24
ag %r1,0(%r2)
ag %r2,0(%r1)
jg _ZN1CD1Ev@PLT
# Where in the better case resolved plt slot looks like:
larl %r1,XX@GOTENT
lg %r1,0(%r1)
bcr %r15,%r1
s390x, -fpic -O2 after:
lghi %r1,-24
ag %r1,0(%r2)
ag %r2,0(%r1)
jg .LTHUNK0
ppc32, -fpic -O2 before:
lwz 9,0(3)
lwz 0,-12(9)
add 3,3,0
b _ZN1CD1Ev@plt
# Where plt slot after resolving will likely be a relative branch
ppc32, -fpic -O2 after:
lwz 9,0(3)
lwz 0,-12(9)
add 3,3,0
b .LTHUNK0@local
Also, what is totally unclear to me is why simple short branch is acceptable
on hppa without -fpic but i not with -fpic. Do you have different size limitations for shared libraries and binaries?
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug c++/11331] [Regression 3.4] ld: BFD 2.14.90 20030602 internal error
2003-06-26 16:38 [Bug c++/11331] New: [Regression 3.4] ld: BFD 2.14.90 20030602 internal error danglin at gcc dot gnu dot org
` (4 preceding siblings ...)
2003-06-27 9:36 ` jakub at gcc dot gnu dot org
@ 2003-06-27 16:40 ` dave at hiauly1 dot hia dot nrc dot ca
2003-07-20 13:20 ` [Bug target/11331] " pinskia at physics dot uc dot edu
` (6 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2003-06-27 16:40 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331
------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2003-06-27 16:40 -------
Subject: Re: [Regression 3.4] ld: BFD 2.14.90 20030602 internal error
> ------- Additional Comments From jakub at gcc dot gnu dot org 2003-06-27 09:36 -------
> I admit I know nothing about PA assembly, but I find it very surprising
> a branch (even if long branch) is more expensive than short branch to .plt
> and call through that or load from .got and indirect jump to that.
Indirect calls are done somewhat differently on the PA. The forms that
you mention don't exist on the PA.
Have you looked at PR 11297? It looks as if there is a similar problem
on powerpc-unknown-linux-gnu. See comment #8 by Matt Kraai.
While I believe that it's possible to avoid the above problem using
various flavors of pc-relative branches for the jump, this requires
a significant amount of time to implement and test given the varying
capabilities of the different assemblers and linkers on the various
PA ports.
As I previously stated, the principal objection to your patch is
the placement of the thunk in the same section as the method. We have
more flexibility in the selection of branch type on the linux port if
this is not done. It's better if the thunk is in its own section when
-ffunction-sections is specified. In this case, we can generate a
short pc-relative branch and be certain that it can reach its target.
Dave
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug target/11331] [Regression 3.4] ld: BFD 2.14.90 20030602 internal error
2003-06-26 16:38 [Bug c++/11331] New: [Regression 3.4] ld: BFD 2.14.90 20030602 internal error danglin at gcc dot gnu dot org
` (5 preceding siblings ...)
2003-06-27 16:40 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2003-07-20 13:20 ` pinskia at physics dot uc dot edu
2003-08-04 0:45 ` pinskia at physics dot uc dot edu
` (5 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: pinskia at physics dot uc dot edu @ 2003-07-20 13:20 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331
pinskia at physics dot uc dot edu changed:
What |Removed |Added
----------------------------------------------------------------------------
Component|c++ |target
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug target/11331] [Regression 3.4] ld: BFD 2.14.90 20030602 internal error
2003-06-26 16:38 [Bug c++/11331] New: [Regression 3.4] ld: BFD 2.14.90 20030602 internal error danglin at gcc dot gnu dot org
` (6 preceding siblings ...)
2003-07-20 13:20 ` [Bug target/11331] " pinskia at physics dot uc dot edu
@ 2003-08-04 0:45 ` pinskia at physics dot uc dot edu
2003-08-09 16:51 ` [Bug target/11331] [3.4 Regression] " pinskia at gcc dot gnu dot org
` (4 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: pinskia at physics dot uc dot edu @ 2003-08-04 0:45 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331
pinskia at physics dot uc dot edu changed:
What |Removed |Added
----------------------------------------------------------------------------
Keywords| |wrong-code
Priority|P3 |P1
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug target/11331] [3.4 Regression] ld: BFD 2.14.90 20030602 internal error
2003-06-26 16:38 [Bug c++/11331] New: [Regression 3.4] ld: BFD 2.14.90 20030602 internal error danglin at gcc dot gnu dot org
` (7 preceding siblings ...)
2003-08-04 0:45 ` pinskia at physics dot uc dot edu
@ 2003-08-09 16:51 ` pinskia at gcc dot gnu dot org
2003-08-09 19:08 ` dave at hiauly1 dot hia dot nrc dot ca
` (3 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2003-08-09 16:51 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Summary|[Regression 3.4] ld: BFD |[3.4 Regression] ld: BFD
|2.14.90 20030602 internal |2.14.90 20030602 internal
|error |error
------- Additional Comments From pinskia at gcc dot gnu dot org 2003-08-09 16:51 -------
Does this still exists on the mainline any more?
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug target/11331] [3.4 Regression] ld: BFD 2.14.90 20030602 internal error
2003-06-26 16:38 [Bug c++/11331] New: [Regression 3.4] ld: BFD 2.14.90 20030602 internal error danglin at gcc dot gnu dot org
` (8 preceding siblings ...)
2003-08-09 16:51 ` [Bug target/11331] [3.4 Regression] " pinskia at gcc dot gnu dot org
@ 2003-08-09 19:08 ` dave at hiauly1 dot hia dot nrc dot ca
2003-08-09 19:47 ` dave at hiauly1 dot hia dot nrc dot ca
` (2 subsequent siblings)
12 siblings, 0 replies; 14+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2003-08-09 19:08 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331
------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2003-08-09 19:08 -------
Subject: Re: [3.4 Regression] ld: BFD 2.14.90 20030602 inte
> PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
>
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331
>
>
> pinskia at gcc dot gnu dot org changed:
>
> What |Removed |Added
> ----------------------------------------------------------------------------
> Summary|[Regression 3.4] ld: BFD |[3.4 Regression] ld: BFD
> |2.14.90 20030602 internal |2.14.90 20030602 internal
> |error |error
>
>
> ------- Additional Comments From pinskia at gcc dot gnu dot org 2003-08-09
> 16:51 -------
> Does this still exists on the mainline any more?
I guess this is now fixed. The hppa-linux port is bootstrapping again.
I fixed a typo in pa_asm_output_mi_thunk this morning which caused a
problem on hppa2.0-hp-hpux11.11.
We now use alternate call sequences to work around the linker problem.
The length returned by attr_length_call in pa.c still does not reflect
reality and needs more work. So far, the thunk/call rewrite has taken
about three weeks work and I'm not sure what we have is correct yet.
I'm thinking we should be using `(*targetm.binds_local_p)' to check
for local calls. Currently, I'm just checking TREE_PUBLIC.
Dave
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug target/11331] [3.4 Regression] ld: BFD 2.14.90 20030602 internal error
2003-06-26 16:38 [Bug c++/11331] New: [Regression 3.4] ld: BFD 2.14.90 20030602 internal error danglin at gcc dot gnu dot org
` (9 preceding siblings ...)
2003-08-09 19:08 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2003-08-09 19:47 ` dave at hiauly1 dot hia dot nrc dot ca
2003-08-11 15:12 ` pinskia at gcc dot gnu dot org
2003-08-11 15:21 ` pinskia at gcc dot gnu dot org
12 siblings, 0 replies; 14+ messages in thread
From: dave at hiauly1 dot hia dot nrc dot ca @ 2003-08-09 19:47 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331
------- Additional Comments From dave at hiauly1 dot hia dot nrc dot ca 2003-08-09 19:47 -------
Subject: Re: [3.4 Regression] ld: BFD 2.14.90 20030602 internal error
> I guess this is now fixed. The hppa-linux port is bootstrapping again.
Correction, all languages except for ada now build under hppa-linux.
Dave
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug target/11331] [3.4 Regression] ld: BFD 2.14.90 20030602 internal error
2003-06-26 16:38 [Bug c++/11331] New: [Regression 3.4] ld: BFD 2.14.90 20030602 internal error danglin at gcc dot gnu dot org
` (10 preceding siblings ...)
2003-08-09 19:47 ` dave at hiauly1 dot hia dot nrc dot ca
@ 2003-08-11 15:12 ` pinskia at gcc dot gnu dot org
2003-08-11 15:21 ` pinskia at gcc dot gnu dot org
12 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2003-08-11 15:12 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331
pinskia at gcc dot gnu dot org changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |RESOLVED
Resolution| |FIXED
------- Additional Comments From pinskia at gcc dot gnu dot org 2003-08-11 15:12 -------
Can you report the Ada bootstrap problem in a different bug.
Closing as this is fixed.
^ permalink raw reply [flat|nested] 14+ messages in thread* [Bug target/11331] [3.4 Regression] ld: BFD 2.14.90 20030602 internal error
2003-06-26 16:38 [Bug c++/11331] New: [Regression 3.4] ld: BFD 2.14.90 20030602 internal error danglin at gcc dot gnu dot org
` (11 preceding siblings ...)
2003-08-11 15:12 ` pinskia at gcc dot gnu dot org
@ 2003-08-11 15:21 ` pinskia at gcc dot gnu dot org
12 siblings, 0 replies; 14+ messages in thread
From: pinskia at gcc dot gnu dot org @ 2003-08-11 15:21 UTC (permalink / raw)
To: gcc-bugs
PLEASE REPLY TO gcc-bugzilla@gcc.gnu.org ONLY, *NOT* gcc-bugs@gcc.gnu.org.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=11331
------- Additional Comments From pinskia at gcc dot gnu dot org 2003-08-11 15:21 -------
I found the Ada was already reported in bug 11414, no need to file another one.
^ permalink raw reply [flat|nested] 14+ messages in thread