MIPS gas option confusion

[Ian Lance Taylor <ian at wasabisystems dot com>]

There is some confusion in the options which are accepted by the MIPS
assembler.

This change:

2001-06-08  H.J. Lu  <hjl@gnu.org>

	* config/tc-mips.c (warn_nops): New variable. Set to 0 to
	disable warning about all NOPS that the assembler generates.
	(macro): Warn NOPS generated only if warn_nops is not 0.
	(md_shortopts): Add `n'.
	(md_parse_option): Set warn_nops to 1 for `n'.

added 'n' to md_shortopts.

Here is the patch in the mailing list:
    http://sources.redhat.com/ml/binutils/2001-06/msg00101.html
Here is a message reporting the checkin:
    http://sources.redhat.com/ml/binutils/2001-06/msg00203.html
although I don't see any evidence that it was approved by any
actual maintainers.

Unfortunately, even at the time of this patch, the assembler already
supported an option -non_shared.  Moreover, the -non_shared option is
used by gcc on Linux.  If you compile with -fno-pic or -fno-PIC, gcc
will pass -non_shared to the assembler.  See SUBTARGET_ASM_SPEC in
gcc/config/mips/linux.h and gcc/config/mips/linux64.h.

When 'n' was added to md_shortopts, -non_shared stopped working as
intended.  It started being treated as equivalent to `-n -o n_shared'.
As it happens, gcc will always pass a -o option to the assembler, and
it will always pass it after the -non_shared option.  So the -o part
of -non_shared was overridden, and -non_shared became effectively
equivalent to -n.  This of course makes no sense at all.

Also, the documentation for -n is wrong.  as --help says "warn about
NOPs generated from macros".  The documentation says:

@item -n
When this option is used, @code{@value{AS}} will issue a warning every
time it generates a nop instruction from a macro.

But all that the option actually does is issue a warning if a
conditional branch is used with a condition which is always false
(e.g., when using 32 bit registers, "bgt $2,-0x80000001,foo") and is
therefore replaced by a nop instruction.  This is not the only case in
which the assembler will generate a nop from a macro.  In fact, there
are many other cases.


So this whole thing was done in a very slipshod manner, and we should
probably discard the -n option entirely.  Interestingly, though, when
I tried that, I got a couple of testsuite failures.  The ldstla-n64
and ldstla-n64-shared tests in gas/testsuite/gas/mips pass the option
-n64 to gas.  This is currently equivalent to passing -n -64.

These tests were added fairly recently, with this ChangeLog entry:

2003-10-01  Thiemo Seufer <seufer@csv.ica.uni-stuttgart.de>

	* gas/mips/ldstla-32-shared.d: New file.
	* gas/mips/ldstla-32.d: New file.
	* gas/mips/ldstla-32.s: New file.
	* gas/mips/ldstla-n32-shared.d: New file.
	* gas/mips/ldstla-n32.d: New file.
	* gas/mips/ldstla-n32.s: New file.
	* gas/mips/ldstla-n64-shared.d: New file.
	* gas/mips/ldstla-n64.d: New file.
	* gas/mips/ldstla-n64.s: New file.
	* gas/mips/mips.exp: Add ld-st-la tests.

Here is the e-mail message:
    http://sources.redhat.com/ml/binutils/2003-09/msg00418.html


Anyhow, to recover from the current ludicrous state of affairs, I
propose that we simply remove the -n option from the MIPS assembler,
and we change these two test cases to pass -64 instead of -n64.  I
propose that we change the assembler to simply never warn about
converting a conditional branch which is always false into a nop.

In my opinion, while this warning could be useful (that's why I wrote
in in the first place), it is quite useless when the warning is off by
default, because nobody will ever bother to use the option which turns
it on.  As far as I know, nobody has complained about the absence of
the warning, so I don't think we need it.

Does anybody object to this course of action?

Ian