MIPS16: AS wouldn't assemble gcc output.

[Dmitri Makarov]

> Actually, it really is a PC relative load from a different section.
> The instruction is in the section
>     .gnu.linkonce.t.__vc__t9RWTBitVec1i17Ui
> I don't know what the section the string is in.

I wouldn't completely agree.  LA $4, addr insn itself is supposed to be a macro
that for MIPS ISA unfolds into 2 insn lui $at, hi (addr) and addi $4, $at, lo (addr)
But whether this is PC realtive load on MIPS16 depends on implementation of
LA macro.  I would assume that addr (32-bit value) is placed right before the function
that being assembled and thus the whole issue of sections would be irrelevant.
Then indeed addr could be placed into $4 by a PC relative load.  I don't know
how LA macro is implemented in GAS now.  Unfortunatly just now I can't check
it yet.  However, please note. It doesn't matter where addr actually is, because
for la $4, 'addr' you store whole 32-bit of 'addr' in some temporary memory location,
AS cannot complain about PC relative load, it's not addr you trying to reach
pc relatively, but the place where you hold it... wrong?

> 
> gcc is supposed to avoid this.  It is supposed to put the string
> constant in the same section as the function.  I'm not sure why that
> isn't working in your case.

Maybe I could give something very approximate explanation, without actually
explaining the reasons for the compiler behaviour. It happens that gcc
places every class member operator definition into a section of itself.
But all the string constants are placed before the operator definitions.
I don't know why this is needed, but this is how the string pointer to which
is in different section than the use of the pointer in LA insn is.

Thank you very much for quick response and valuable comment. I'll continue
working on this.