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

["dave at hiauly1 dot hia dot nrc dot ca" <gcc-bugzilla@gcc.gnu.org>]

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