[Bug target/49746] Generated PA-RISC2.0w code cannot be assembled by GNU as-2.21.1

["dave.anglin at bell dot net" <gcc-bugzilla at gcc dot gnu dot org>]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746

--- Comment #6 from dave.anglin at bell dot net 2011-07-15 14:41:19 UTC ---
On 7/15/2011 4:37 AM, h.m.brand at xs4all dot nl wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746
>
> --- Comment #5 from H.Merijn Brand<h.m.brand at xs4all dot nl>  2011-07-15 08:34:49 UTC ---
> On Thu, 14 Jul 2011 22:07:10 +0000, "dave.anglin at bell dot net"
> <gcc-bugzilla@gcc.gnu.org>  wrote:
>
> $ gcc64 -v
> Reading specs from
> /wrk/pa20_64-4.6.1/bin/../lib/gcc/hppa64-hp-hpux11.11/3.4.6/specs
> Configured with: ../src/configure --enable-languages=c,c++
> --prefix=/usr/local/pa20_64 --with-local-prefix=/usr/local/pa20_64
> --with-gnu-as --with-as=/usr/local/pa20_64/bin/as --without-gnu-ld
> --with-ld=/usr/ccs/bin/ld --disable-shared --disable-nls
> --host=hppa64-hp-hpux11.11
> Thread model: single
> gcc version 3.4.6
>
This looks ok.

>> If you add -save-temps to the failing compile, this will save the
>> assembler output.  This will allow inspection of the problematic
>> instructions.  I would guess we are dealing with a bl or b instruction.
>> A b,l instruction would have a 21-bit range.
To see what's wrong, the assembly code needs to be looked at.  The range 
that you
showed is characteristic of a 17-bit pc-relative branch.  In PA 2.0, 
calls use 21-bit
pc-relative branches.  If the .level directive is correct for the file, 
then the problem must
be due to an unconditional jump with an incorrect branch distance 
calculation.  I don't
believe there are any major problems with the branch distance 
calculations in 4.3 and
latter (last releases).

You might try working around this problem as follows:

1) Manually compile object that's failing with -O2.  This will reduce 
function sizes and
probably avoid the out of range error.  Then, restart bootstrap.  If 
build suceeds, install
new compiler and recheck that you can sucessfully bootstrap.  I suggest 
-O2 since
various reorg bugs appear at -O1.  This is simplest work around.

2) The other alternative is to abandon your gcc64 and build a new 
boostrap compiler
with HP aCC or C (ANSI).  I haven't tried this in some time.

3) I could provide you with a working bootstrap compiler. 
  Unfortunately, I can't make the file
publicly available.

If you get a working compiler going, it would be great if you could post 
it on the net as
you have done for some other builds.  Option 2 isn't that easy.

Dave