From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 783 invoked by alias); 9 Aug 2003 19:08:15 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 772 invoked by alias); 9 Aug 2003 19:08:15 -0000 Date: Sat, 09 Aug 2003 19:08:00 -0000 Message-ID: <20030809190815.771.qmail@sources.redhat.com> From: "dave at hiauly1 dot hia dot nrc dot ca" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20030626163810.11331.danglin@gcc.gnu.org> References: <20030626163810.11331.danglin@gcc.gnu.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug target/11331] [3.4 Regression] ld: BFD 2.14.90 20030602 internal error X-Bugzilla-Reason: CC X-SW-Source: 2003-08/txt/msg01225.txt.bz2 List-Id: 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