This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

[Bug c++/11331] [Regression 3.4] ld: BFD 2.14.90 20030602 internal error


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]