Re: gcc-64 on HP-UX 11.00

[law at redhat dot com]

In message <200204151646.g3FGkEtp008502@hiauly1.hia.nrc.ca>, "John David Anglin
" writes:
 > >  > The patch has passed bootstrap and regression testing.  However, I want
 > >  > to study the matter further as it possible this can happen on any PA2.0
 > >  > machine, and not just TARGET_64BIT machines.
 > > Hmm, my question would be why didn't we use a general register as the
 > > destination?  I guess it's technically possible to get into the 
 > > situation you're trying to fix, but it may be happening due to problems
 > > elsewhere.
 > 
 > The error is caused by allowing symbolic LO_SUM addresses for PA2.0
 > (GO_IF_LEGITIMATE_ADDRESS), the T constraint which accepts LO_SUM
 > addresses, and an output template that can't print these addresses.
Yes, I know that.

[ ... ]
 > The same error occurs in 32bit mode with these options using gas:
 > 
 > # gcc -O -mpa-risc-2-0 -fPIC -S gv.i
 > gv.c: In function `Perl_amagic_call':
 > gv.c:1774: output_operand: invalid expression as operand
 > Please submit a full bug report,
 > with preprocessed source if appropriate.
 > See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.
 > 
 > As far as I can tell, the address form used in the patch is ok
 > in PA2.0 code and it saves one instruction over forcing the address
 > to a register.  However, we need to fix the 32 bit pattern(s) as
 > well.
This isn't what I'm looking for.

Based on the information I saw in the patch, you're loading something out of
the DLT into a floating point register.  That's an exceedingly bad thing to
do, and while I don't doubt it can happen, I'd like to know more about why
it happened.  What caused us to do something that dumb.

jeff