This is the mail archive of the
gcc-patches@gcc.gnu.org
mailing list for the GCC project.
Re: [PATCH] Document Sparc64 configuration
> From: Rainer Orth <ro@TechFak.Uni-Bielefeld.DE>
>
> Since config.gcc deals with canonical names anyway, I think it makes much
> more sense to continue accepting the alias forms and standardize on a
> single canonical form (be that sparcv9 or sparc64). This requires some
> modification to config.sub. I think the testsuite deals with canonical
> names only, not with the target alias the user chose.
I don't seem to feel as strongly about this as you do. Since this
appears to be controversial, I won't make any changes. If you want to
modify config.sub or whatever, please go ahead.
> Because they are used to this form for years, and I don't think it's
> appropriate for gcc to unilaterally obsolete it, while it is still valid
> (or even required) for other packages. I'm referring to
> $libdir/gcc-lib/$target_alias because this contains the configuration name
> in a user-visible form (e.g. in gcc -v output), be it
> sparcv9-sun-solaris2.8 or whatever the user chose at configure time.
> Rainer
I'm wondering whether these other packages actually support sparcv9-*,
sparc64-*, both or neither. :-)
I seem to recall that gdb at least didn't support 64-bit sparc
(whatever you call it.) Perhaps that's changed, I don't know.
If binutils and gdb either support both names, or neither, then
showing deference to other packages may be a red herring. It's only
if they support sparcv9-* only, where we'd have a conflict.
--Kaveh
--
Kaveh R. Ghazi ghazi@caip.rutgers.edu