cc1plus assembler output for HP-UX 10.20

[Marco Franzen <Marco dot Franzen at Thyron dot com>]

On Wed, 29 Mar 2000, I wrote:
> I will try a new bootstrap after removing the generated fixinc.sh script.
After fixing that and setting some missing execute permissions, the fixincludes
issues seem to be resolved now. Thanks, Bruce.

However, then I bumped against the following code generation issues to chose
between.


1. ) --with-gnu-as, using binutils-2.9.1

Snapshot gcc_ss_2000_03_13, configured --with-gnu-as (but not --with-gnu-ld)
on HP-UX 10.20, generates code that the latest released (1997) version
of gas rejects. Release 2.95.2 did not have this problem. This will be known
already and may go away when I try some unreleased binutils snapshot. (It
should be documented in some install/ file for release, anyway.)

More specifically, cc1plus now emits `.weak' pseudo-ops, which gas-2.9.1 does
not recognise (at least not in this configuration).  

Weak symbols sounds like a useful new feature for template instantiation
folding.  Can I, however, turn this feature off, on platforms where as/ld do
not support it, to get the benefit of the other improvements in gcc?  (Even GNU
as and ld may not support this on all platforms, or they may not be available
at all for some platforms.)  Ideally, configure would provide an option or
might even figure it out itself.  (But BOOT_CFLAGS would be fine, too.)

Nevertheless, I will try with a newer, unreleased binutils snapshot, as soon as
I have managed to build it. (Is --with-gnu-ld recommended now for HP-UX
10.20?)

2.) --without-gnu-as, no binutils installed

Configured --without-gnu-as (and actually not using gas), bootstrapping fails
too (no, not on comparing stages, but on the first invocation of xgcc): The
label `gcc2_compiled.' uses the wrong syntax for the vendor's assembler.  After
manually removing the trailing colon, /usr/ccs/bin/as accepts it.  This should
be easy to fix for someone who knows the code and the platform ramifications.

====================================================================
bash-2.03$ /usr/ccs/bin/as -o dummy.o dummy.s
as: "dummy.s", line 10: error 1051: Illegal symbol in opcode position - :

bash-2.03$ /usr/gnu/bin/as-o dummy.o dummy.s
bash-2.03$ cat dummy.s
        .LEVEL 1.1
        .SPACE $PRIVATE$
        .SUBSPA $DATA$,QUAD=1,ALIGN=8,ACCESS=31
        .SUBSPA $BSS$,QUAD=1,ALIGN=8,ACCESS=31,ZERO,SORT=82
        .SPACE $TEXT$
        .SUBSPA $LIT$,QUAD=0,ALIGN=8,ACCESS=44
        .SUBSPA $CODE$,QUAD=0,ALIGN=8,ACCESS=44,CODE_ONLY
        .IMPORT $global$,DATA
        .IMPORT $$dyncall,MILLICODE
gcc2_compiled.:
        .SPACE $TEXT$
        .SUBSPA $CODE$

        .align 4
        .EXPORT __foo,ENTRY,PRIV_LEV=3
__foo
        .PROC
        .CALLINFO FRAME=64,NO_CALLS,SAVE_SP,ENTRY_GR=3
        .ENTRY
        copy %r3,%r1
        copy %r30,%r3
        stwm %r1,64(%r30)
        ldo 64(%r3),%r30
        ldwm -64(%r30),%r3
        bv,n %r0(%r2)
        .EXIT
        .PROCEND
bash-2.03$ 
====================================================================

Not using gas is only the second best option, mainly because still
	cc1: warning: -g is only supported when using GAS on this processor
and probably because of the known timestamps issue with `make compare'
(unless make compare manages to work around it now).

I am trying to bootstrap configuring --without-gnu-as, but actually using gas
anyway (in parallel to building newer binutils for my other option).

Cheers,

-- Marco
{please ignore any confidentiality clause that might be appended}
-----------------------------------------------------------------
This email is confidential and intended solely for the use of the
individual to whom it is addressed.
Any views or opinions presented are solely those of the author
and do not necessarily represent those of Thyron Limited.
If you are not the intended recipient then please be advised
that you have received this email in error and that any use,
dissemination, forwarding, printing or copying of this email
is strictly prohibited.
If you have received this email in error, please notify the
Thyron IT Administrator on +44 (0)1923 236 050 or
send an email to mail-admin@thyron.com.
Thank You