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

["h.m.brand at xs4all dot nl" <gcc-bugzilla at gcc dot gnu dot org>]

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:

> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746
> 
> --- Comment #3 from dave.anglin at bell dot net 2011-07-14 22:06:49 UTC ---
> On 7/14/2011 4:35 PM, sje at cup dot hp.com wrote:
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=49746
> >
> > --- Comment #2 from Steve Ellcey<sje at cup dot hp.com>  2011-07-14 20:34:28 UTC ---
> > Are you trying to use a 32 bit GCC to bootstrap a 64 bit GCC?  I see you have
> > CC set to gcc64 which makes me think that you are using a 64 bit GCC to do the
> > bootstrap but you have -mpa-risc-2-0 in CFLAGS, which I think means the 32 bit
> > 2.0 instruction set and I don't think it should be used for 64 bit builds.
> >
> > Can you bootstrap if you leave off the -mpa-risc-2-0 flag
>
> The flag shouldn't matter.  hppa64 is always PA 2.0.  hppa64 is also 
> always PIC, so -fPIC is also redundant.
> 
> The issue is with the bootstrap compiler gcc64.  Is it actually 3.4.6 
> (gcc64 -v)?

Yes, as I said in my OP

$ 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

> Did gmp and mpfr compile and check ok with it?

Yes, as I said in my OP

> These need to be 64-bit.

They are

$ file /usr/local/pa20_64/lib/libmpfr.sl
/usr/local/pa20_64/lib/libmpfr.sl:      ELF-64 shared object file - PA-RISC 2.0
(LP64)
$ file /usr/local/pa20_64/lib/libmpc.sl
/usr/local/pa20_64/lib/libmpc.sl:       ELF-64 shared object file - PA-RISC 2.0
(LP64)
$ file /usr/local/pa20_64/lib/libgmp.sl
/usr/local/pa20_64/lib/libgmp.sl:       ELF-64 shared object file - PA-RISC 2.0
(LP64)

> The 64-bit 3.X versions of hppa64 were somewhat buggy and there were 
> also some buggy distributions.

I build it myself from scratch. I never managed to build a gcc-4.x.x on
PA-RISC: All 64bit versions did not pass the perl compile test

> If your gcc64 compiled gmp and mpfr ok, I would suggest trying to build 
> a early 4.X release, then jump to 4.6.

I've tried and tried but always failed to get a reliable working 4.x

> This may avoid the out of range field.

So in fact you suggest to build an unreliable 4.x, then use it to build
4.6.1 hoping *that* would be reliable?

> I think that you also need a separate 64-bit version of gas.  I'm not 
> sure SOM and ELF can be supported with a single gas binary.

All binaries in /usr/local/pa20_64/bin are 64bit:

$ file /usr/local/pa20_64/bin/*as
/usr/local/pa20_64/bin/as:      ELF-64 executable object file - PA-RISC 2.0
(LP64)
/usr/local/pa20_64/bin/gas:     ELF-64 executable object file - PA-RISC 2.0
(LP64)

> HP uses a wrapper.  I always compiler two separate versions of binutils.

I do so too

> GCC on PA-RISC can't easily support both 32 and 64-bit targets because 
> of the differences between SOM and ELF.

I know

> This is not a blocker since the bug is in the bootstrap compiler.
> 
> 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.
> 
> Dave