Re: [Revised patch] Rework MIPS command-line handling

[cgd@broadcom.com]

> GCC patch tested by bootstrapping on mips-sgi-irix6.5.  Also
> tested mips-elf and mips64-elf (in the latter case, both with
> and without the GAS changes).

(Did you run the assembler/linker checks, as well was check-gcc?  I'd
assume so, but just checking.  8-)


> !   first = 1;
>   
>     for (i = 0; mips_cpu_info_table[i].name != NULL; i++)
> !     show (stream, mips_cpu_info_table[i].name, &column, &first);
> !   show (stream, "from-abi", &column, &first);

So, given that there's some duplication of name -> CPU mappings in the
cpu names table (4600 vs.  orion, some of the SB-1 related names hich
i plan to clean up after you commit this), does it make sense to print
out only the first name for a given CPU (since presumably that's the
preferred name)?

It might be nice to have an additional field 'deprecated' to allow old
names to persist a bit, with warnings (and w/o being printed)... but
that can be added later...


> ! -mabi=ABI		create ABI conformant object file for:\n"));
> ! 
> !   first = 1;
> ! 
> !   show (stream, "32", &column, &first);
> !   show (stream, "o64", &column, &first);
> !   show (stream, "n32", &column, &first);
> !   show (stream, "64", &column, &first);
> !   show (stream, "eabi", &column, &first);
> ! 
> !   fputc ('\n', stream);

missing meabi?


> ! Note that the @samp{_MIPS_ARCH} uses processor names given above.  In

macro?


> ! other words, it will have the full prefix, and will not abbreviate

					     ^ kill this comma.  8-)


> ! @samp{000} as @samp{k}.  In the case of @samp{from-abi}, the macro
> ! names the resolved architecture (either @samp{"mips1"} or
> ! @samp{"mips3"}).  It names the default architecture when no
> ! @option{-march} option is given.
> ! 
> ! @item -mtune=@var{arch}
>   @opindex mtune
> ! Optimize for @var{arch}.  Among other things, this option controls
> ! the way instructions are scheduled, and the perceived cost of arithmetic
> ! operations.  The list of @var{arch} values is the same as for
> ! @option{-march}.
>   
> ! When this option is not used, GCC will optimize for the processor
> ! specified by @option{-march}, or (failing that) for the default
> ! processor.  By using @option{-march} and @option{-mtune} together, it is

"failing that"?  Why not just kill ", or ..."?


> ! The default size of ints, longs and pointers depends on the ABI@.
> ! All the supported ABIs use 32-bit ints.  n64 uses 64-bit longs, as does

@samp{n64} ?


> *** config/mips/iris6.h	11 Jul 2002 18:56:56 -0000	1.50
> --- config/mips/iris6.h	19 Jul 2002 18:37:50 -0000
> *************** Boston, MA 02111-1307, USA.  */
> *** 238,244 ****
>      on the mipsX option.  */
>   /* If no mips[3,4] option given, give the appropriate default for mabi=X */
>   #undef SUBTARGET_ASM_SPEC
> ! #define SUBTARGET_ASM_SPEC "%{!mabi*:-n32} %{!mips*: %{!mabi*:-mips3} %{mabi=n32:-mips3} %{mabi=64:-mips4}}"
>   
>   /* Must pass -g0 to the assembler, otherwise it may overwrite our
>      debug info with its own debug info.  */
> --- 238,244 ----
>      on the mipsX option.  */
>   /* If no mips[3,4] option given, give the appropriate default for mabi=X */
>   #undef SUBTARGET_ASM_SPEC
> ! #define SUBTARGET_ASM_SPEC "%{!mabi*:-n32} %{!mips*: %{!mabi*:-mips3} %{mabi=n32|mabi=64:-mips3}}"
> 

Is this change to the existing / historical behaviour desirable?  Or
is it just a necessary side effect of the rest of the changes (i.e.,
consistency)?  Eh, i guess i don't really care.  8-)






chris