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
projects / thirdparty / gcc.git / commitdiff
