If you create a toolchain with the target alphaev68-unknown-linux-gnu, gcc
will use the -mcpu=ev67 by default when compiling.  Some software packages
(like gmp) will use this target info to decide that it may freely use
assembly code that targets ev67+.  The trouble comes in when trying to
compile that pure assembly code.

While gcc will use -mcpu=ev67 just fine, it will invoke gas without an
-mev67 option, so the assembler will default to the lowest common
denominator -- ev4 in this case.  Inline assembly in C code is normally
just peachy because gcc's assembler output will start with ".arch <cpu>"
and the assembler will accept that.  But if the hand coded assembly code
lacks that .arch, you easily end up with errors like so:
	opcode `cttz' not supported for target <all>

While the assembly code could/should be fixed to explicitly output the
.arch directive, I think it's reasonable to expect this to work:
	echo 'cttz $20,$21' | gcc -x assembler -c - -o /dev/null -mcpu=ev67

This simple patch implements that, although I guess it is a bit redundant
in the default case where gcc outputs .arch.  Perhaps that should all be
punted in favor of a specs-only approach.  Considering gas respects .arch
in the code over the command line, it should also make things more natural.
The command line is processed in the standard/expected way -- gcc defaults
the -m option while user's custom -mcpu/-Wa,-m options come after, and the
guy writing the assembly code is free to use .arch to override everything
else.

From-SVN: r223888